Департамент інформатизації на виконання пункту 2 постанови Правління Національного банку України від 28.10.2010 N 474 "Про набрання чинності стандартами з управління інформаційною безпекою в банківській системі України" розробив і надсилає для роботи Методичні рекомендації щодо впровадження системи управління інформаційною безпекою та методики оцінки ризиків відповідно до стандартів Національного банку України.

Система управління інформаційною безпекою є сучасним процесом забезпечення безпеки інформаційних ресурсів організації, яка побудована на кращих світових практиках. Стандарти Національного банку України основані на міжнародних стандартах ISO 27001 та ISO 27002 з додаванням вимог із захисту інформації, зумовлених конкретними потребами сфери банківської діяльності і правовими вимогами, які вже висунуто в нормативних документах Національного банку України.

Відповідність системи управління інформаційною безпекою стандартам Національного банку України СОУ Н НБУ 65.1 СУІБ 1.0:2010 та СОУ Н НБУ 65.1 СУІБ 2.0:2010 гарантує банку відповідність міжнародним стандартам ISO 27001 та ISO 27002 і надає можливість отримати відповідний сертифікат.

Необхідність впровадження в банках України стандартів з управління інформаційною безпекою продиктована вимогами Базельського комітету Basel II з управління та зменшення операційних ризиків банків.

Впровадження в банках України стандартів з управління інформаційною безпекою дозволить:

- оптимізувати вартість побудови та підтримання системи інформаційної безпеки;

- постійно відслідковувати та оцінювати ризики з урахуванням цілей бізнесу;

- ефективно виявляти найбільш критичні ризики та знижати ймовірність їх реалізації;

- розробити ефективну політику інформаційної безпеки та забезпечити її якісне виконання;

- ефективно розробляти, впроваджувати та тестувати плани відновлення бізнесу;

- забезпечити розуміння питань інформаційної безпеки керівництвом та всіма працівниками банку;

- забезпечити підвищення репутації та ринкової привабливості банків;

- знизити ризики рейдерських та інших шкідливих для банку атак;

- тощо.

Слід зазначити, що наведені вище переваги не будуть досягнуті шляхом лише "формального" підходу до розроблення, впровадження, функціонування системи управління інформаційною безпекою та незацікавленості керівництва і працівників банку в підвищенні рівня інформаційної безпеки.

Ці Методичні рекомендації щодо впровадження системи управління інформаційною безпекою розроблені на основі міжнародного стандарту ISO/IEC 27003:2010 "Information technology - Security techniques - Information security management system implementation guidance" (Настанова з впровадження системи управління інформаційною безпекою) з урахуванням особливостей банківської діяльності, стандартів та вимог Національного банку України з питань інформаційної безпеки.

Впровадження стандартів з питань управління інформаційною безпекою не може бути разовою акцією. Це фактично є безперервним процесом розроблення, впровадження, функціонування, моніторингу, перегляду, підтримування та вдосконалення системи управління інформаційною безпекою (СУІБ). Для процесів СУІБ застосована модель ПВПД (плануй - виконуй - перевіряй - дій), наведена у вступі до стандарту СОУ Н НБУ 65.1 СУІБ 1.0:2010.

Зрозуміло, що для проведення цих робіт потрібні ресурси, у тому числі наявність фахівців з питань інформаційної безпеки, наявність з боку керівництва банку повної підтримки та контролю, а також розуміння проблем, що виникають.

Система інформаційної безпеки повинна забезпечити безпечність та надійність функціонування бізнес-процесів / банківських продуктів банку. Впровадження та функціонування СУІБ стосується всіх підрозділів банку і, у першу чергу, керівників підрозділів - власників бізнес-процесів / банківських продуктів. Тому ці відповідальні особи повинні брати участь у вирішенні питань, що належать до сфери їх відповідальності, під час упровадження та функціонування СУІБ.

Цілі СУІБ та заходи безпеки, що вже існують і ті, що будуть додатково впроваджені в разі необхідності, а також відповідна документація, що описує функціонування СУІБ, повинні бути зрозумілими для всіх, кого це стосується. Тому обов'язковою умовою успішного функціонування СУІБ є також проведення відповідних навчань з питань інформаційної безпеки.

3.1. Зобов'язання керівництва щодо управління інформаційною безпекою

Відповідно до розділу 5 стандарту СОУ Н НБУ 65.1 СУІБ 1.0:2010 та пункту 6.1.1 стандарту СОУ Н НБУ 65.1 СУІБ 2.0:2010 керівництво банку повинно забезпечити визначення завдань інформаційної безпеки, їх відповідність вимогам законодавства України, нормативно-правових актів Національного банку України та банку, інтегрованість у відповідні бізнес-процеси/банківські продукти, переглядати ефективність впровадження та функціонування СУІБ, надавати ресурси, які потрібні для інформаційної безпеки та навчання персоналу з питань інформаційної безпеки.

Для вирішення цих завдань необхідно визначити організаційну структуру управління інформаційною безпекою, повноваження та відповідальність щодо розроблення, впровадження та функціонування СУІБ.

Керівництво СУІБ може здійснювати керівник банку або його заступник, або існуючий керівний орган, наприклад, рада з питань інформатизації з обов'язковим включенням до складу спеціалістів з питань інформаційної безпеки. В залежності від розміру банку ці обов'язки можуть бути покладені на створений спеціальний керівний орган з питань інформаційної безпеки з керівників підрозділів, відповідальних за критичні бізнес-процеси та банківські продукти. Формування такого керівного органу тільки з фахівців з питань інформаційної безпеки є недоцільним, оскільки в такому випадку питання інформаційної безпеки будуть за межами уваги керівників, відповідальних за критичні бізнес-процеси, або питання інформаційної безпеки будуть вирішуватися окремо для кожного бізнес-процесу, що створить додаткові умови для несанкціонованого доступу до інформації та порушення конфіденційності, а також призведуть до додаткових фінансових витрат. У разі необхідності до роботи з окремих питань в цьому керівному органі можуть долучатися зовнішні спеціалісти з питань інформаційної безпеки за умови підписання угоди про конфіденційність.

Відповідно до пункту 6.1.2 стандарту СОУ Н НБУ 65.1 СУІБ 2.0:2010 діяльність щодо інформаційної безпеки повинна бути узгоджена між представниками різних підрозділів банку, які відповідають та забезпечують функціонування критичних бізнес-процесів / банківських продуктів. Банки мають створювати єдину систему інформаційної безпеки для всіх бізнес-процесів та координувати дії різних підрозділів для забезпечення виконання загальних вимог щодо інформаційної безпеки. Для виконання цих обов'язків може бути створена окрема група з перехресними функціями з фахівців різних підрозділів. Якщо банк не створює окрему групу з перехресними функціями, то ці обов'язки повинні виконуватися спеціальним керівним органом або окремим керівником.

Зазвичай, координація інформаційної безпеки повинна стосуватися співробітництва і координації спільної діяльності менеджерів, користувачів, адміністраторів, розробників прикладних програм, аудиторів і персоналу безпеки, а також фахівців у таких галузях, як страхування, правові питання, людські ресурси, управління ІТ або ризиками.

3.2. Призначення відповідальних осіб за впровадження та функціонування СУІБ

Для забезпечення впровадження, функціонування СУІБ та контролю за функціонуванням СУІБ наказом має бути призначений керівник СУІБ відповідно до рекомендацій пункту 3.1, а саме керівник банку або його заступник, який відповідає за питання інформаційної безпеки та в оперативному підпорядкуванні якого знаходиться підрозділ інформаційної безпеки. Керівник СУІБ повинен мати повноваження долучати до впровадження та функціонування СУІБ усіх потрібних фахівців і в першу чергу керівників підрозділів - власників бізнес-процесів / банківських продуктів.

Заступником керівника СУІБ може бути призначений керівник підрозділу, який відповідає за інформаційну безпеку в банку.

У наказі рекомендується зазначити, що керівники підрозділів - власників бізнес-процесів / банківських продуктів мають сприяти впровадженню і функціонуванню СУІБ та своєчасно надавати необхідну інформацію керівникові СУІБ або його заступнику.

3.3. Визначення вимог з інформаційної безпеки банку

Для впровадження та подальшого вдосконалення СУІБ необхідно чітко визначити вимоги з інформаційної безпеки банку.

Джерелами вимог з інформаційної безпеки є:

- закони України;

- нормативно-правові акти Національного банку України;

- вимоги платіжних систем та систем переказу коштів;

- внутрішні нормативні документи банку;

- умови угод та договорів з третіми сторонами тощо.

Слід звернути увагу на те, що вимоги з інформаційної безпеки для платіжних систем та систем переказів коштів висуваються платіжною організацією платіжної системи та системи переказу коштів, тому вони можуть відрізнятися від вимог Національного банку України (крім Системи електронних платежів (СЕП) та Національної системи масових електронних платежів (НСМЕП), платіжними організаціями яких є Національний банк України). Однак, облік коштів повинен здійснюватися в системах автоматизації банку відповідно до вимог нормативно-правових актів Національного банку України.

Особливу увагу слід звернути на умови угод та договорів з третіми сторонами. Відповідно до пункту 6.2 стандарту СОУ Н НБУ 65.1 СУІБ 2.0:2010 безпека інформації та засобів оброблення інформації банку не повинна знижуватися через уведення в експлуатацію продуктів або послуг зовнішньої сторони. Якщо є бізнес-потреба в роботі із зовнішніми сторонами, яка може вимагати доступу до інформації або засобів оброблення інформації банку, або в отриманні від зовнішньої сторони чи наданні їй продукту та послуги, тоді банк повинен виконувати оцінку ризику для визначення вимог щодо заходів безпеки та наслідків порушення безпеки. Заходи безпеки повинні бути погоджені та визначені в угоді із зовнішньою стороною. Ці питання повинні розглядатися не тільки для договорів про надання послуг клієнтам банку (системи типу "клієнт-банк", інтернет-банкінг, мобільний банкінг тощо), а також при отриманні послуг зовнішніх сторін (розробка та супроводження програмного забезпечення, придбання та технічне обслуговування обладнання, надання послуг зв'язку тощо).

Аналіз вимог з наведених вище джерел допоможе правильно визначити цілі СУІБ та заходи безпеки, які можуть забезпечити зменшення ризиків операційної діяльності банку з урахуванням особливостей роботи банку.

Перелік вимог з інформаційної безпеки повинен бути задокументованим та затвердженим керівництвом банку.

4.1. Класифікація інформації

Відповідно до Закону України "Про інформацію" вся інформація з обмеженим доступом повинна бути надійно захищена. Відповідно до законів України "Про захист інформації в інформаційно-телекомунікаційних системах", "Про банки і банківську діяльність", "Про захист персональних даних" у банках можна визначити такі категорії інформації з обмеженим доступом:

- банківська таємниця;

- комерційна таємниця;

- персональні дані;

- інша конфіденційна інформація.

Банк має створити максимально докладний та зрозумілий перелік відомостей, які відносяться до інформації з обмеженим доступом. У цьому переліку повинні бути описані види інформації, які відносяться до кожної з категорій інформації з обмеженим доступом, що надасть можливість полегшити працівнику банку визначення відношення певної інформації до відповідної категорії.

Відповідно до Правил зберігання, захисту, використання та розкриття банківської таємниці, затверджених постановою Правління Національного банку України від 14.07.2006 N 267, зареєстрованих в Міністерстві юстиції України 03.08.2006 за N 935/12809, працівники банку під час прийому на роботу повинні власноруч підписувати зобов'язання щодо збереження банківської таємниці. Ці зобов'язання банк може поширити на всі категорії інформації з обмеженим доступом.

Банк зобов'язаний у внутрішніх положеннях встановити спеціальний порядок поводження та ведення діловодства з документами, що містять інформацію з обмеженим доступом, зокрема визначити порядок підготовки і реєстрації вихідних документів, роботи з документами, відправлення та зберігання документів, а також особливості роботи з електронними документами, які містять інформацію з обмеженим доступом, зокрема з урахуванням вимог, що викладені в наведеному вище нормативно-правовому акті Національного банку України.

Особливу увагу слід звернути на маркування документів з обмеженим доступом. Скорочені позначки грифу інформації з обмеженим доступом повинні бути загально відомими, наприклад, банківська таємниця - БТ, комерційна таємниця - КТ тощо. Не рекомендується використовувати інші літери для скорочених позначок грифу інформації, які не пов'язані із повною назвою грифу та не є інтуїтивно зрозумілими.

4.2. Опис критичних бізнес-процесів та програмно-технічних комплексів, які забезпечують їх функціонування

Відповідно до вимог стандартів Національного банку України сферою застосування СУІБ, яка має бути впроваджена, є банк у цілому. Тому дуже важливо чітко визначити бізнес-процеси / банківські продукти, які працюють з інформацією з обмеженим доступом і повинні бути захищеними.

Відповідно до Положення про організацію операційної діяльності в банках України, затвердженого постановою Правління Національного банку України від 18.06.2003 N 254, банківський продукт-це стандартизовані процедури, що забезпечують виконання банками операцій, згрупованих за відповідними типами та ознаками.

Поняття бізнес-процесу є багатозначним і не існує загально прийнятого його визначення. Під бізнес-процесом у широкому значенні розуміється структурована послідовність дій з виконання певного виду діяльності на всіх етапах життєвого циклу предмета діяльності. Кожен бізнес-процес має початок (вхід), вихід та послідовність процедур, які забезпечують виконання операцій, згрупованих за відповідними типами.

Не існує стандартного набору бізнес-процесів/банківських продуктів для будь-якого банку. Тому банк має самостійно визначити відповідні бізнес-процеси/банківські продукти, які використовуються всередині банку.

Для визначення бізнес-процесів/банківських продуктів, які має охоплювати СУІБ, необхідно проаналізувати всі бізнес-процеси/ банківські продукти банку та створити перелік критичних процесів, функціонування яких має великий вплив на успішну роботу банку. Оскільки в банку бізнес-процеси/банківські продукти взаємопов'язані, то рекомендується створити їх блок-схему з визначенням усіх взаємозв'язків. Така візуалізація значно спростить розуміння всього обсягу робіт, що виконуються банком.

Банк повинен створити перелік критичних бізнес-процесів/ банківських продуктів, які обробляють інформацію з обмеженим доступом, розголошення якої може нанести шкоду банку. До цього переліку повинні бути включеними всі бізнес-процеси/банківські продукти, що обробляють:

- платіжні документи,

- внутрішні платіжні документи,

- кредитні документи,

- документи на грошові перекази,

- персональні дані клієнтів та працівників банку,

- статистичні звіти,

- інші документи, які містять інформацію з обмеженим доступом.

Для кожного критичного бізнес-процесу/банківського продукту рекомендується надати перелік бізнес-процесів/банківських продуктів, з якими взаємодіє цей бізнес-процес/банківський продукт.

Перелік критичних бізнес-процесів/банківських продуктів повинен супроводжуватися коротким описом кожного бізнес-процесу/ банківського продукту з наданням інформації про програмно-технічні комплекси, які забезпечують його функціонування.

Короткий опис кожного бізнес-процесу/банківського продукту повинен містити таку інформацію:

- назва бізнес-процесу/банківського продукту;

- цілі бізнес-процесу/банківського продукту;

- гриф інформації з обмеженим доступом, яка обробляється бізнес-процесом/банківським продуктом;

- власник бізнес-процесу/банківського продукту;

- підрозділи банку, які забезпечують функціонування бізнес-процесу/банківського продукту;

- наявність зобов'язань перед третіми сторонами (угоди на розроблення, доопрацювання, супроводження та технічне обслуговування);

- вхідні та вихідні дані бізнес-процесу/банківського продукту;

- перелік процедур бізнес-процесу та блок-схема послідовності їх виконання з визначенням взаємозв'язків (у тому числі додаткової вхідної інформації з інших бізнес-процесів);

- вимоги щодо забезпечення безперервності бізнес-процесу/ банківського продукту (максимально допустимий час простою);

- типи ролей (груп) для бізнес-процесу/банківського продукту;

- існування забороненого суміщення типів ролей;

- програмно-технічний(ні) комплекс(и), що забезпечує(ють) функціонування бізнес-процесу;

- кількість користувачів програмно-технічного комплексу;

- архітектура і технологія роботи (зокрема, файловий обмін або режим реального часу, в тому числі й для обміну інформацією з іншими програмно-технічними комплексами в разі наявності);

- операційна система та тип бази даних програмно-технічного комплексу, які використовуються для функціонування бізнес-процесу/банківського продукту;

- географічне розміщення (серверів та робочих місць) програмно-технічного комплексу;

- засоби захисту, які вже існують у програмно-технічному комплексі;

- взаємодія з іншими програмно-технічними комплексами;

- принципи резервування обладнання та інформації програмно-технічного комплексу (за наявності окремих принципів для цього програмно-технічного комплексу).

Зазначимо деякі аспекти формування цієї інформації.

Дуже важливо визначити власника бізнес-процесу / банківського продукту, який повинен також бути власником програмно-технічного комплексу. Саме власник бізнес-процесу / банківського продукту / програмно-технічного комплексу повинен приймати рішення щодо надання доступу до інформації, яка обробляється в цьому бізнес-процесі / банківському продукту / програмно-технічному комплексі. Власником програмно-технічного комплексу не може бути підрозділ банку, який відповідає за інформаційні технології і забезпечує технічну підтримку роботи комплексу.

Перелік процедур бізнес-процесу та блок-схема послідовності їх виконання з визначенням взаємозв'язків (у тому числі додаткової вхідної інформації з інших бізнес-процесів) буде дуже корисним під час аналізу та визначення вразливостей, притаманних цьому бізнес-процесу / банківському продукту. Цей перелік та блок-схема мають бути у достатньому ступені узагальненими. Дуже детальний перелік може призвести до ускладнення під час визначення вразливостей. Однак, якщо цей перелік та блок-схема будуть занадто узагальненими, то це може призвести до пропуску небезпечних вразливостей, які можуть створювати великі ризики.

У разі якщо функціонування одного бізнес-процесу / банківського продукту забезпечується декількома програмно-технічними комплексами, тоді короткі описи кожного комплексу та їх взаємозв'язків повинні також бути надані.

У разі якщо один програмно-технічний комплекс забезпечує функціонування декількох бізнес-процесів / банківських продуктів, тоді визначається єдиний власник програмно-технічного комплексу (але не підрозділ, який відповідає за інформаційні технології) або група власників бізнес-процесів, які надають та контролюють доступ до інформації, що обробляється різними модулями комплексу.

У разі відсутності централізованих програмно-технічних комплексів мають бути надані короткі описи програмно-технічних комплексів у структурних підрозділах банку (обласних дирекціях, філіях тощо) та описаний взаємозв'язок між ними.

Для більшого розуміння зв'язків між бізнес-процесами / банківськими продуктами / програмно-технічними комплексами рекомендується створити блок-схему цих зв'язків із додаванням структурних підрозділів банку, які забезпечують ці бізнес-процеси / банківські продукти / програмно-технічні комплекси вхідною інформацією, та підрозділів банку, які використовують вихідні дані.

Типи ролей (груп) для бізнес-процесу / банківського продукту фактично означають різні рівні доступу до інформації, яка обробляється цим бізнес-процесом / банківським продуктом. При цьому слід пам'ятати про необхідність надання мінімальних прав доступу, необхідних для виконання службових обов'язків. Обов'язковим також є визначення заборонених суміщень прав доступу (ініціювання та подальше виконання операції) для запобігання підготовки фальсифікованих банківських документів або несанкціонованої модифікації документів. Наприклад, для платіжних документів забороненим є суміщення обов'язків операціоніста та бухгалтера.

4.3. Опис організаційної структури банку, яку охоплює СУІБ

На основі вихідних документів попереднього пункту банк має визначити всі підрозділи, які відносяться до сфери застосування СУІБ. Це підрозділи, які є власниками та учасниками критичних бізнес-процесів, підрозділи, які супроводжують та забезпечують технічну підтримку програмно-технічних комплексів, користувачі програмно-технічних комплексів, служба безпеки, яка забезпечує фізичну безпеку приміщень банку, тощо. Наявність такого переліку підрозділів дозволить чітко визначити обов'язки та відповідальності всіх причетних до виконання вимог безпеки сторін та планувати їх навчання у разі необхідності. Такий перелік може створюватися на основі структурної схеми підрозділів банку.

Окрім того, у разі наявності передавання частини послуг, що пов'язані з критичними бізнес-процесами / банківськими продуктами/програмно-технічними комплексами, третім сторонам, ці організації також повинні бути включені до опису організаційної структури банку з поміткою, що вони не є структурними підрозділами банку.

4.4. Опис структури мережі банку

Для подальшого аналізу захищеності мережі банку необхідно зробити опис структури мережі банку, засобів захисту та управління, які вже існують. Банк повинен мати внутрішнє положення про мережу банку, у якому надається така інформація:

- принципи побудови мережі з описом принципів резервування мережевого обладнання;

- принципи розподілу мережі на сегменти (підмережі) - за наявності;

- принципи розподілу адресного простору;

- система управління мережею;

- побудова вузла доступу до ресурсів мережі Інтернет;

- принципи доступу до мереж інших організацій - за наявності;

- наявність та правила роботи через канали зв'язку зовнішніх провайдерів телекомунікаційних послуг, у тому числі опис принципів резервування каналів зв'язку;

- засоби захисту мережі від зовнішнього та внутрішнього несанкціонованого доступу, у тому числі антивірусного захисту;

- принципи надання доступу працівникам банку до мережі та ресурсів мережі Інтернет;

- принципи та процедура надання віддаленого доступу працівникам банку до мережі банку - за наявності;

- принципи та процедура надання бездротового доступу до мережі банку - за наявності;

- принципи резервного копіювання інформації.

Для спрощення розуміння особливостей побудови мережі банку рекомендується створити окремі внутрішні положення (політики) за різними питаннями управління мережею, а в загальному положенні про мережу описати основні принципи побудови та функціонування мережі з наданням посилань на окремі політики.

4.5. Опис фізичного середовища

Питання захисту інфраструктури банку також входять до СУІБ.

Банк повинен мати такі документи:

- опис географічного та територіального розташування приміщень банку, включаючи відокремлені підрозділи банку (обласні дирекції, філії, відділення тощо) для визначення загроз з боку навколишнього середовища;

- опис принципів пропускного режиму;

- наказ із визначення приміщень з обмеженим доступом та опис відповідного захисту цих приміщень із забезпеченням контролю доступу до таких приміщень;

- опис принципів побудови систем відео спостереження;

- опис системи електроживлення та заземлення;

- опис охоронної та пожежної сигналізації;

- опис умов зберігання магнітних, оптомагнітних, паперових та інших носіїв інформації, у тому числі електронних архівів.

Вимоги до приміщень банків наведені у Правилах технічного захисту приміщень банків, де обробляються електронні банківські документи, затверджені постановою Правління Національного банку України від 04.07.2007 N 243, зареєстрованою в Міністерстві юстиції України 17.08.2007 за N 955/14222, та інших нормативно-правових актах Національного банку України.

4.6. Опис принципів забезпечення безперервності роботи

Однією з основних функцій банку є забезпечення безперервності його роботи. Основні вимоги до банку з цього питання викладені у Положенні про забезпечення безперервного функціонування інформаційних систем Національного банку України та банків України, затвердженому постановою Правління Національного банку України від 17.06.2004 N 265, зареєстрованою в Міністерстві юстиції України 09.07.2004 за N 857/9456.

Банк повинен мати опис принципів та заходів щодо забезпечення безперервності роботи, в якому надати опис процедур та обладнання, а також обов'язків працівників банку, в тому числі методи резервування інформації для відновлення роботи в разі виникнення надзвичайних ситуацій. У цьому документі повинні бути визначені терміни відновлення роботи банку та необхідні ресурси (зокрема програмно-технічні засоби, обладнання, резервне електроживлення тощо).

Банк повинен регулярно проводити тестування всіх складових, що потрібні для виконання плану забезпечення безперервної діяльності та дій у разі виникнення надзвичайних ситуацій, у тому числі можливість відновлення резервної інформації, яка зберігається у віддаленому резервному пункті.

5.1. Загальні положення

Методичні рекомендації щодо управління ризиками інформаційної безпеки розроблені на основі міжнародного стандарту ISO/IEC 27005 "Information technology - Security techniques - Information security risk management" (Управління ризиками інформаційної безпеки) з урахуванням особливостей банківської діяльності, стандартів та вимог Національного банку України з питань інформаційної безпеки.

Ризиком інформаційної безпеки вважається ймовірність того, що визначена загроза, впливаючи на вразливості ресурсу або групи ресурсів, може спричинити шкоду банку.

Управління інформаційними ризиками повинно включати:

- аналіз і ідентифікацію ризиків;

- оцінку ризиків з точки зору їх впливу на бізнес та ймовірності їх появи;

- інформування особи, яка вправі приймати рішення та акціонерів банку про ймовірності та впливи цих ризиків; ймовірність і наслідки ризику мають бути зрозумілими;

- встановлення порядку та пріоритетів оброблення ризиків;

- встановлення пріоритетів виконання дій щодо зниження ризиків;

- участь керівництва в процесі прийняття рішень щодо управління ризиками та його поінформованість щодо стану справ в управлінні ризиками;

- ефективний моніторинг та регулярний перегляд ризиків і процесу управління ризиками;

- інформування керівництва та персоналу щодо ризиків і дій щодо управління ними.

Процес управління ризиками інформаційної безпеки повинен здійснюватися для банку в цілому.

Процес управління ризиками інформаційної безпеки є безперервним процесом і до нього може бути застосована модель ПВПД (плануй - виконуй - перевіряй - дій), яка наведена у вступі стандарту СОУ Н НБУ 65.1 СУІБ 1.0:2010.

Порівняння СУІБ та процесу управління ризиками інформаційної безпеки можна описати у вигляді таблиці:

Процес управління ризиками інформаційної безпеки стосується всіх підрозділів банку і, у першу чергу, керівників підрозділів - власників бізнес-процесів / банківських продуктів. Тому ці відповідальні особи повинні брати участь у вирішенні питань, що належать до сфери їх відповідальності.

5.2. Аналіз ресурсів СУІБ та бізнес-процесів / банківських продуктів

Аналіз ресурсів СУІБ та бізнес-процесів / банківських продуктів виконується на основі даних, які були отримані та систематизовані на етапі опису існуючої інфраструктури та заходів безпеки (див. розділ 4). На цьому етапі рекомендується розглянути критичні бізнес-процеси / банківські продукти / програмно-технічні комплекси, які були визначені та описані раніше, з точки зору інформаційної безпеки та можливих втрат у разі порушень інформаційної безпеки. Цей аналіз виконується тільки на якісному рівні, але дозволить в подальшому більш докладно виконати оцінку ризиків та визначити план оброблення ризиків. Для кожного бізнес-процесу / банківського продукту / програмно-технічного комплексу необхідно розглянути наскільки виконуються та як можуть впливати на бізнес основні сервіси інформаційної безпеки: цілісність, конфіденційність, доступність та спостережність. Такий аналіз повинен виконуватися власниками бізнес-процесів / банківських продуктів / програмно-технічних комплексів разом з фахівцями з питань інформаційної безпеки.

Нагадаємо визначення термінів основних сервісів інформаційної безпеки:

конфіденційність (confidentiality) - властивість інформації, яка полягає в тому, що інформація не може бути отримана неавторизованим користувачем і/або процесом;

цілісність (integrity) - властивість інформації, яка полягає в тому, що інформація не може бути модифікована неавторизованим користувачем і/або процесом. Цілісність системи (system integrity) - властивість системи, яка полягає в тому, що жоден її компонент не може бути усунений, модифікований або доданий з порушенням політики безпеки;

доступність (availability) - властивість ресурсу системи, яка полягає в тому, що користувач і/або процес, який володіє відповідними повноваженнями, може використовувати ресурс відповідно до правил, встановлених політикою безпеки, не очікуючи довше заданого (малого) проміжку часу, тобто коли він знаходиться у вигляді, необхідному користувачеві, в місці, необхідному користувачеві, і в той час, коли він йому необхідний;

спостережність (accountability) - властивість системи, що дозволяє фіксувати діяльність користувачів і процесів, використання пасивних об'єктів, а також однозначно установлювати ідентифікатори причетних до певних подій користувачів і процесів з метою запобігання порушення політики безпеки і/або забезпечення відповідальності за певні дії.

Слід зазначити, що для різних бізнес-процесів / банківських продуктів можуть бути виявлені однакові ризики втрати основних сервісів безпеки, що буде свідчити про те, що певним питанням інформаційної безпеки не приділяється необхідної уваги. У такому випадку рекомендується вирішувати питання зменшення ризиків однаково для всіх бізнес-процесів / банківських продуктів банку.

Однак, найбільш поширеним випадком буде наявність в різних бізнес-процесах / банківських продуктах різних за рівнем небезпеки питань, які потребують впровадження конкретних заходів безпеки для конкретного бізнес-процесу / банківського продукту.

Тому докладна оцінка ризиків не може бути загальною для банку в цілому та потребує розгляду як загальних для банку питань, так і конкретних питань для кожного бізнес-процесу / банківського продукту. Крім того, особливу увагу слід приділити розгляду обміну інформацією між різними бізнес-процесами / банківськими продуктами / програмно-технічними комплексами.

Після виконання такого аналізу з точки зору впливу порушень інформаційної безпеки на бізнес-процеси / банківські продукти / програмно-технічні комплекси можна переходити до більш докладної оцінки ризиків інформаційної безпеки.

5.3. Ідентифікація загроз та вразливостей

Загрози потенційно можуть завдати шкоди ресурсам СУІБ, зокрема інформації, персоналу, клієнтам, обладнанню, процесам і програмно-технічним комплексам, бізнес-процесам / банківським продуктам і, відповідно, банку. Загрози можуть мати природні та людські джерела і можуть бути випадковими або навмисними. Повинні бути ідентифіковані як випадкові, так і навмисні джерела загроз. Загрози можуть бути ідентифіковані в загальному вигляді або за типами (наприклад, неавторизовані дії, фізичне пошкодження, технічні пошкодження тощо).

Деякі загрози можуть впливати на декілька ресурсів СУІБ. У такому випадку вони можуть викликати різний вплив на різні ресурси.

До ідентифікації загроз необхідно залучати власників бізнес-процесів/банківських продуктів та користувачів, підрозділи управління персоналом та фізичної безпекою, спеціалістів з інформаційної безпеки, юридичні підрозділи тощо.

Приклади загроз наведені у додатку 1. Цей перелік не є вичерпаним і повинен доповнюватися в залежності від ситуації в банку, технологій, що використовуються, організаційної структури, процедур тощо.

Вразливості, які можуть бути використані загрозами для впливу на ресурси СУІБ / бізнес-процеси / банківські продукти, також повинні бути ретельно розглянути та ідентифіковані.

Вразливості можуть бути ідентифіковані в таких областях:

- банк у цілому;

- процеси та процедури;

- системи управління;

- персонал;

- фізичне середовище;

- конфігурація програмно-технічних комплексів, обладнання, програмне забезпечення або телекомунікаційне обладнання;

- залежність від зовнішніх організацій.

Наявність вразливостей не може впливати на ресурси та бізнес-процеси / банківські продукти самостійно, оскільки має бути наявна загроза, яка буде використовувати ці вразливості. Для вразливості, якій не відповідає відповідна загроза, не потрібно впровадження заходів безпеки, але вона повинна бути ідентифікована та відслідковуватися під час внесення будь-яких змін, які пов'язані з цим ресурсом СУІБ і бізнес-процесом / банківським продуктом.

Некоректно запроваджені чи недієві заходи безпеки є одним з видів вразливостей.

Вразливості можуть бути пов'язаними із властивостями ресурсу СУІБ.

Приклади вразливостей наведені у додатку 2. Цей перелік не є вичерпаним і повинен доповнюватися в залежності від ситуації в банку, технологій, що використовуються, організаційної структури, процедур тощо.

Для виявлення вразливостей в залежності від критичності інформації та бізнес-процесу / банківського продукту, а також від інформаційно-телекомунікаційних технологій можуть використовуватися різні проактивні методи тестування. Такі методи тестування включають:

- спеціальний автоматичний інструментарій для сканування вразливостей;

- тестування та оцінку безпеки;

- тести на проникнення;

- перегляд коду програмно-технічних комплексів;

- аналіз відомих порушень безпеки;

- аналіз відомих вразливостей (наприклад, операційних систем, баз даних, телекомунікаційних технологій та протоколів тощо).

Такі методи допоможуть ідентифікувати вразливості.

Слід зазначити, що іноді ці методи можуть надавати інформацію про вразливості, які не представляють реальної загрози. Тому необхідно чітко задавати параметри програмно-технічних комплексів та їх конфігурацію для тестування.

5.4. Ідентифікація наслідків реалізації загроз

Наслідками реалізації загроз можуть бути втрати ефективності, бізнес-процесів, зниження репутації тощо. Необхідно проаналізувати негативні наслідки для банку, які можуть виникати якщо ідентифіковані загрози будуть використовувати відповідні вразливості або набір вразливостей і призведуть до інциденту інформаційної безпеки. Такий інцидент інформаційної безпеки може впливати на один або більше ресурсів СУІБ / бізнес-процес / банківський продукт. Таким чином, ресурсам СУІБ можуть бути приписані значення їх фінансової вартості, а також бізнес наслідків, якщо ці ресурси будуть пошкоджені або скомпрометовані.

6.1. Методологія оцінювання ризиків

Аналіз ризиків може бути виконаний з різним ступенем деталізації в залежності від критичності ресурсів СУІБ / бізнес-процесів / банківських продуктів, відомих вразливостей і попередніх інцидентів інформаційної безпеки. Методологія оцінки ризиків може бути кількісною або якісною, або їх комбінацією. На практиці якісна оцінка часто використовується спочатку для визначення загального рівня ризику і визначення основних ризиків. Далі може виникнути необхідність виконання більш специфічного або кількісного аналізу стосовно основних ризиків. Кількісна оцінка ризиків є більш складною та потребує більше часу та ресурсів. Однак така оцінка буде дуже корисною у випадках, коли рішення щодо оброблення ризиків буде залежати від вартості заходів безпеки, які можуть бути більшими, ніж фінансові втрати інциденту інформаційної безпеки.

Якісна методика оцінки ризиків використовує шкалу атрибутів для опису величини потенціальних наслідків реалізації загроз і вірогідність того, що такі наслідки виникнуть. Перевагою якісної методики є її простота розуміння всім персоналом; недоліком такої методики є залежність від суб'єктивного вибору шкали атрибутів.

Для отримання якісної оцінки ризиків необхідно розглянути оцінки наслідків реалізації загроз разом із вразливостями, з використанням яких ці загрози можуть реалізуватися, та оцінки ймовірності їх реалізації для кожного бізнес-процесу / банківського продукту, мережі, обладнання, програмного забезпечення, які забезпечують функціонування цього бізнес-процесу / банківського продукту, мережі банку в цілому, фізичного середовища, персоналу тощо, як описано в додатку 2, з урахуванням попереднього аналізу.

Для виконання оцінки ризиків необхідно визначити шкалу для різних параметрів: оцінки величини наслідків реалізації загрози на сервіси безпеки (цілісність, конфіденційність, доступність, спостережність), оцінки ймовірності реалізації загрози. Загальний рівень оцінки величини наслідків реалізації кожної загрози на сервіси безпеки визначається як максимальна величина з окремих оцінок впливу на цілісність, конфіденційність, доступність, спостережність. Звертаємо увагу на те, що оцінка ймовірності не є математичною величиною вірогідності, яка не може перевищувати 1.

Рівень ризику за окремою парою загроза/вразливість, яка може використовуватися для реалізації цієї загрози, визначається перемноженням загального рівня оцінки величини наслідків на оцінку ймовірності реалізації загрози.

Загальний рівень ризику для бізнес-процесу / банківського продукту, персоналу, фізичного середовища тощо дорівнює максимальної величині з усіх ризиків за кожною парою загроза/вразливість.

Рекомендується використовувати такі шкали для оцінки ризиків:

Для оцінки ймовірності реалізації загроз:

Для величини наслідків реалізації загрози: вплив на цілісність:

Для величини наслідків реалізації загрози: вплив на конфіденційність:

Для величини наслідків реалізації загрози: вплив на доступність:

Для величини наслідків реалізації загрози: вплив на спостережність:

Визначення конкретних величин для параметрів оцінки повинно виконуватися з урахуванням досвіду працівників банку, вимог нормативно-правових актів Національного банку України, історії попередніх інцидентів інформаційної безпеки, відомих випадків порушення інформаційної безпеки, досвіду інших фінансових установ тощо.

Рекомендується оцінку ризиків документувати у вигляді таблиці для кожного бізнес-процесу / банківського продукту, приклад якої наданий у додатку 3.

Такий підхід до оцінки ризиків дозволить чітко виявити найбільші ризики у бізнес-процесах / банківських продуктах і найбільш критичні загрози.

6.2. Оброблення ризиків

Відповідно до пункту 4.2.1 стандарту Національного банку України СОУ Н НБУ 65.1 СУІБ 1.0:2010 після виконання оцінки ризиків банк має оцінити альтернативні варіанти оброблення ризиків. Можливими варіантами оброблення ризиків можуть бути:

- зниження ризиків шляхом застосування належних заходів безпеки;

- свідоме та об'єктивне прийняття ризиків за умови, що вони чітко задовольняють політику організації та критерії прийняття ризиків;

- уникнення ризиків;

- перенесення відповідних бізнес-ризиків на інші сторони, наприклад, страхувальників, постачальників.

Для прийняття рішення щодо оброблення конкретних ризиків рекомендується визначити такі критерії стосовно кожного окремого ризику:

- низький ризик - 1 - 6;

- середній ризик - 7 - 14;

- високий ризик - 15 - 25.

Застосування належних заходів безпеки дозволить зменшити ризики. Під час вибору цих додаткових заходів безпеки повинні бути враховані всі вимоги законодавства України, нормативно-правових актів Національного банку України, внутрішніх документів, політики та стратегії банку. Крім того, цей вибір також повинен враховувати вартість додаткових заходів безпеки, час їх впровадження, вплив на технологію операційної роботи, інтерфейс користувача тощо. З урахуванням цих факторів складається план оброблення ризиків. У разі необхідності тривалої підготовки до впровадження додаткових заходів безпеки деякі ризики можуть бути тимчасово прийняти як залишкові з включенням до наступного плану оброблення ризиків після перегляду оцінки ризиків.

Прийняття всіх залишкових ризиків повинно бути задокументовано і затверджено керівництвом банку. Це стосується середніх та високих ризиків і повинно бути ретельно розглянуто. У документах стосовно прийняття залишкових ризиків має бути надана причина прийняття ризику та, за необхідністю, строки впровадження додаткових заходів безпеки для зниження ризику. Наприклад, якщо банком використовується програмно-технічний комплекс із застарілими технологіями, який має великий ризик реалізації однієї або декількох загроз і який планується замінити на новий більш сучасний комплекс протягом 2 років, то ці ризики можуть бути прийняти як тимчасове рішення до заміни цього програмно-технічного комплексу з наданням терміну впровадження нового.

Деякі ризики є властивістю існуючого бізнес-процесу / банківського продукту / програмно-технічного комплексу. Особливу увагу слід звернути на вразливості саме програмно-технічних комплексів, які використовують застарілі або новітні незахищені технології. В деяких випадках слід розглянути питання щодо уникнення ризиків за рахунок зміни операційного середовища, баз даних, програмно-технічного комплексу, технології оброблення та зберігання інформації, оскільки це буде вимагати менших витрат, ніж впровадження додаткових заходів безпеки.

6.3. Визначення цілей додаткових заходів безпеки та плану впровадження заходів безпеки

Після вибору варіанту оброблення ризиків у разі необхідності впровадження додаткових заходів безпеки для зменшення ризиків інформаційної безпеки необхідно обрати цілі цих заходів безпеки відповідно до додатка А стандарту Національного банку України СОУ Н НБУ 65.1 СУІБ 1.0:2010. У разі відсутності відповідних цілій заходів безпеки у стандарті банк повинен їх визначити додатково. Додаток А до стандарту не може розглядатися як вичерпний і може доповнюватися відповідно до конкретних цілей бізнесу та особливостей організації операційної роботи банку.

Банк має розробити план оброблення ризиків із наданням інформації стосовно додаткових заходів безпеки, їх цілей та ризиків, особливо по відношенню до зменшення ризиків.

6.4. Підготовка Положення щодо застосовності

Після завершення розроблення плану оброблення ризиків банк має підготувати Положення щодо застосовності. Це Положення має включати всі заходи безпеки, включаючи додаткові, які використовуються в банку для управління інформаційною безпекою. В цьому Положенні формується перелік цілей заходів безпеки та заходи безпеки відповідно до додатка А стандарту Національного банку України СОУ Н НБУ 65.1 СУІБ 1.0:2010 з додатковими заходами безпеки, і воно повинно включати таку інформацію:

- цілі заходів безпеки і короткий опис заходів безпеки, які впроваджені на теперішній час та обґрунтування їх вибору;

- цілі заходів безпеки і короткий опис заходів безпеки, які планується впровадити з визначенням терміну впровадження та обґрунтування їх вибору;

- будь-які вилучені цілі заходів безпеки і заходи безпеки з тих, що наведено у додатку А, і обґрунтування їх вилучення, що дає можливість перевірки, що жодні заходи безпеки не були випадково пропущені.

Приклад Положення щодо застосовності наданий у додатку 4.

7.1. Загальний опис документації

Під час підготовки до впровадження СУІБ повинні бути створені відповідні документи, перелік яких наданий у додатку 5. За наявності таких документів у банку вони повинні бути переглянути та оновлені в разі необхідності у відповідності до вимог щодо оформлення документів, які наведені далі.

Загальний комплект документів, який повинен бути наявним на момент впровадження СУІБ і який відповідає стандарту ISO 27001. має чотирьохрівневу структуру, а саме:

- адміністративні документи;

- документи верхнього рівня;

- документи середнього рівня;

- документи нижнього рівня.

7.2. Адміністративні документи

Адміністративні документи є обов'язковою начальною точкою підготовки до впровадження СУІБ, як це описано в розділі 3, пунктах 3.1. - 3.2. Ці документи включають:

- наказ про створення спеціального керівного органу з питань інформаційної безпеки (за необхідністю);

- положення про спеціальний керівний орган з питань інформаційної безпеки (за його наявністю);

- у разі відсутності спеціального керівного органу з питань інформаційної безпеки наказ про покладення обов'язків цього органу на існуючий керівний орган;

- наказ про впровадження та функціонування СУІБ;

- наказ про призначення керівника проекту впровадження та функціонування СУІБ;

- положення про службу захисту інформації (підрозділ інформаційної безпеки);

- положення про службу безпеки (охорона, пропускний та внутрішньо-банківський режим тощо);

- посадові інструкції відповідальних за впровадження та функціонування СУІБ осіб;

- організаційна структура банку.

Ці документи оформляються відповідно до правил внутрішнього діловодства банку і можуть бути поєднаними згідно з особливостями роботи банку. Наприклад, якщо підрозділ захисту інформації входить до складу одного структурного підрозділу разом з фахівцями з фізичної безпеки, то потрібно тільки одне положення про підрозділ банківської безпеки. Відповідно назви підрозділів формуються згідно з внутрішніми правилами банку.

Частина описаних документів вже існує в банку, але рекомендується їх переглянути та доповнити відповідними вимогами та наданими повноваженнями щодо впровадження та функціонування СУІБ.

7.3. Документи верхнього рівня

Документи верхнього рівня є фактично основою СУІБ. Їх можна розділити на дві групи.

До першої групи відносяться два основних документа, які визначають стратегію розвитку банку та загальну політику інформаційної безпеки. Стратегія розвитку банку повинна містити основні стратегічні цілі банку, в тому числі й ті, що пов'язані з впровадженням нових бізнес-процесів/банківських продуктів із використанням новітніх технологій, які потребують захисту інформації. Наявність такого документу дозволить забезпечити планування розвитку інфраструктури банку та заходів безпеки, які повинні бути передбачені у СУІБ для зменшення операційних ризиків банку. Політика інформаційної безпеки банку повинна містити основні цілі безпеки та принципи, які мають забезпечувати безпеку банку. Обидва документа мають бути короткими (2-3 стор.), прийнятними для зрозуміння усіма працівниками банку та бути достатньо конкретними. У додатку 6 наведений приклад політики інформаційної безпеки.

До другої групи документів верхнього рівня відносяться документи, які описують основу побудови системи управління інформаційною безпекою:

- цілі СУІБ;

- сфера застосування СУІБ;

- організаційна структура банку, яка охоплюється СУІБ;

- політика управління інформаційною безпекою;

- опис методології оцінки ризиків;

- звіт щодо оцінки ризиків;

- опис методології оброблення ризиків з визначенням критеріїв прийняття залишкових ризиків;

- план оброблення ризиків;

- положення щодо застосовності.

Перші чотири документа можуть бути поєднані в один - політику управління інформаційною безпекою, але з обов'язковим уключенням перших трьох документів у вигляді окремих розділів.

Політика управління інформаційною безпекою може бути розділена на дві політики: зовнішню, яка описує політику управління інформаційною безпекою для зовнішніх зв'язків банку, та внутрішню, яка описує правила інформаційної безпеки для працівників банку.

Для зменшення обсягу політики управління інформаційною безпекою рекомендується окремі питання винести в окремі цільові політики (положення) з наданням відповідних посилань. Зокрема, за бажанням банку можуть бути створені такі окремі документи:

- перелік законодавчих, регуляторних, нормативних вимог з інформаційної безпеки для банку (пункт 3.3) (додаток 7);

- перелік відомостей, що містять інформацію з обмеженим доступом;

- перелік критичних бізнес-процесів/банківських продуктів/програмно-технічних комплексів (пункт 4.2);

- політика визначення критичних бізнес-процесів / банківських продуктів;

- політика надання доступу до інформації;

- політика контролю доступу;

- політика парольного захисту;

- політика антивірусного захисту;

- політика захисту мережі банку;

- політика віддаленого доступу до ресурсів мережі;

- політика ідентифікації та автентифікації ресурсів СУІБ;

- політика криптографічного захисту інформації;

- політика "чистого екрана та чистого стола";

- інші політики (положення) відповідно до технології організації операційної роботи банку.

Слід зазначити, що політика управління інформаційною безпекою має бути створена передостанньою, після завершення аналізу існуючого стану інформаційної безпеки, оцінки ризиків та створення плану оброблення ризиків. Політика управління інформаційною безпекою повинна містити інформацію про існуючі заходи безпеки та плани щодо зменшення ризиків. Існування окремих цільових політик надасть можливість не описувати докладно усі заходи безпеки, а надавати посилання на відповідні політики (положення).

Останнім документом створюється Політика щодо застосовності, де повинні бути наданий перелік заходів безпеки із стандарту Національного банку України з додаванням додаткових заходів безпеки за необхідністю з коротким описом як вони реалізовані або поясненням чому вони не використовуються в банку.

Наданий перелік другої групи документів верхнього рівня є неповним і необов'язковим; він може бути скороченим або доповненим іншими документами. Під час прийняття рішення стосовно переліку цих документів слід мати на увазі, що найбільш ефективним буде створення коротких, чітких та зрозумілих документів, ніж створення одного дуже великого документу, з яким буде дуже важко працювати як працівникам банку, які повинні його виконувати, так і авторам цього документу під час внесення необхідних змін у зв'язку зі змінами інфраструктури банку, технології оброблення інформації та заміни засобів захисту.

Для спрощення опрацювання всіх документів рекомендується ввести єдиний підхід щодо структури документів (пункт 7.6).

7.4. Документи середнього рівня

Документи середнього рівня фактично є технічними документами, які спрямовані на опис способів реалізації заходів безпеки для захисту ресурсів СУІБ від загроз. Саме на цьому рівні повинні бути описаними конкретні операції, які мають виконуватися різними користувачами, описані питання розподілу повноважень та відповідальності по кожної операції, встановлюються строки виконання кожної операції, створюються шаблони угод із зовнішніми сторонами тощо. Ці документи мають створюватися не тільки спеціалістами з інформаційної безпеки, а також спеціалістами відповідних підрозділів за напрямками, а саме: спеціалістами по інформаційним технологіям, по фізичному захисту, по роботі з персоналом, юридичного підрозділу тощо. Основними користувачами документів середнього рівня є керівники відповідних підрозділів, відповідальні особи за окремі ресурси СУІБ, адміністратори.

Наданий нижче перелік документів середнього рівня побудований згідно із Додатком А стандарту Національного банку України СОУ Н НБУ 65.1 СУІБ 1.0:2010:

А.6. Організація інформаційної безпеки:

- Зобов'язання працівників банку щодо збереження інформації з обмеженим доступом;

- Опис процедури управління санкціонуванням використання нових засобів оброблення інформації;

- Опис вимог щодо угод з третіми сторонами щодо доступу, оброблення, передавання або управління інформацією організації або засобами оброблення інформації, або щодо додавання продуктів чи послуг до засобів оброблення інформації.

А.7. Управління ресурсами СУІБ:

- Реєстр ресурсів СУІБ;

- Опис процедури поводження із інформацією з обмеженим доступом.

Реєстр ресурсів СУІБ може складатися з набору декількох документів, зокрема документів, які створюються під час впровадження СУІБ (див. п. 4).

А.8 Безпека людських ресурсів:

- Процедура управління персоналом;

- Критерії прийому персоналу;

- Опис процедури перевірки кандидатів на прийом на роботу (за наявності);

- Опис процедури навчання прийнятих на роботу працівників вимогам щодо інформаційної безпеки;

- Опис процедури підготовки посадових інструкцій;

- Опис дисциплінарного процесу щодо персоналу, який здійснив порушення безпеки;

- Опис процедури звільнення персоналу з точки зору припинення відповідальності, скасування прав доступу та повернення ресурсів СУІБ;

- Програма навчання персоналу.

А.9. Фізична безпека та безпека інфраструктури:

- Опис процедури фізичної безпеки банку, схема периметру фізичної безпеки;

- Опис процедури та правил пропускного режиму;

- Опис процедури захисту від зовнішніх та інфраструктурних загроз;

- Опис процедури захисту обладнання від аварій засобів життєзабезпечення (електроживлення, заземлення, тепловідведення, тощо);

- Опис процедури обслуговування обладнання;

- Опис процедури санкціонування переміщення майна за межі банку.

А.10. Управління комунікаціями та функціонуванням:

- Опис процедур управління змінами у засобах оброблення інформації та телекомунікаційних мережах;

- Опис процедур розроблення, тестування, впровадження та експлуатації програмно-технічних комплексів/ресурсів СУІБ;

- Опис процедур моніторингу, перегляду та внесення змін у послугах третіх сторін;

- Опис процедур захисту від зловмисного та мобільного коду;

- Опис процедур резервного копіювання інформації;

- Опис процедур забезпечення безпеки мережі;

- Опис процедур поводження зі змінними носіями;

- Опис процедур забезпечення безпеки інформації і програмного забезпечення, якими обмінюються в організації та з третіми сторонами;

- Опис процедур виявлення несанкціонованої діяльності з оброблення інформації;

- Опис процедури синхронізації часу.

А.11. Контроль доступу:

- Опис процедури управління доступом користувачів (реєстрація, надання повноважень, перегляд та скасування доступу);

- Опис процедури управління паролем користувача;

- Опис процедури контролю доступу до мережі та автентифікації користувача;

- Опис процедури захисту підключень до мережі (в тому числі зовнішніх та віддалених підключень);

- Опис заходів безпеки щодо маршрутизації в мережі;

- Опис заходів контролю доступу до операційної системи;

- Опис заходів контролю доступу до програмно-технічних комплексів;

- Опис процедури дистанційної роботи.

А.12. Придбання, розроблення та підтримка інформаційних систем:

- Опис процедур внутрішньої безпеки під час обробки інформації в програмно-технічних комплексах (захист баз даних, цілісність даних під час передавання та зберігання, тощо);

- Опис процедур криптографічного захисту інформації;

- Опис процедур управління ключової інформацією;

- Опис процедури забезпечення цілісності програмного забезпечення та системних файлів;

- Опис процедури запобігання можливості витоку інформації;

- Опис вимог щодо аутсорсінгового розроблення програмного забезпечення;

А.13. Управління інцидентами інформаційної безпеки: