Документ v0365500-11, поточна редакція — Прийняття від 03.03.2011

                    НАЦІОНАЛЬНИЙ БАНК УКРАЇНИ 
Департамент інформатизації
Л И С Т
03.03.2011 N 24-112/365
Банкам України

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

ЗАТВЕРДЖЕНО
В.о. заступника Голови
Ричаківська В.І. _____________
01.03.2011

МЕТОДИЧНІ РЕКОМЕНДАЦІЇ
щодо впровадження системи управління
інформаційною безпекою та методики
оцінки ризиків відповідно до стандартів
Національного банку України

1. Вступ
Система управління інформаційною безпекою є сучасним процесом
забезпечення безпеки інформаційних ресурсів організації, яка
побудована на кращих світових практиках. Стандарти Національного
банку України основані на міжнародних стандартах ISO 27001 та ISO
27002 з додаванням вимог із захисту інформації, зумовлених
конкретними потребами сфери банківської діяльності і правовими
вимогами, які вже висунуто в нормативних документах Національного
банку України. Відповідність системи управління інформаційною безпекою
стандартам Національного банку України СОУ Н НБУ 65.1 СУІБ
1.0:2010 та СОУ Н НБУ 65.1 СУІБ 2.0:2010 гарантує банку
відповідність міжнародним стандартам ISO 27001 та ISO 27002 і
надає можливість отримати відповідний сертифікат. Необхідність впровадження в банках України стандартів з
управління інформаційною безпекою продиктована вимогами
Базельського комітету Basel II з управління та зменшення
операційних ризиків банків. Впровадження в банках України стандартів з управління
інформаційною безпекою дозволить: - оптимізувати вартість побудови та підтримання системи
інформаційної безпеки; - постійно відслідковувати та оцінювати ризики з урахуванням
цілей бізнесу; - ефективно виявляти найбільш критичні ризики та знижати
ймовірність їх реалізації; - розробити ефективну політику інформаційної безпеки та
забезпечити її якісне виконання; - ефективно розробляти, впроваджувати та тестувати плани
відновлення бізнесу; - забезпечити розуміння питань інформаційної безпеки
керівництвом та всіма працівниками банку; - забезпечити підвищення репутації та ринкової привабливості
банків; - знизити ризики рейдерських та інших шкідливих для банку
атак; - тощо. Слід зазначити, що наведені вище переваги не будуть досягнуті
шляхом лише "формального" підходу до розроблення, впровадження,
функціонування системи управління інформаційною безпекою та
незацікавленості керівництва і працівників банку в підвищенні
рівня інформаційної безпеки.
2. Загальні положення
Ці Методичні рекомендації щодо впровадження системи
управління інформаційною безпекою розроблені на основі
міжнародного стандарту ISO/IEC 27003:2010 "Information
technology - Security techniques - Information security management
system implementation guidance" (Настанова з впровадження системи
управління інформаційною безпекою) з урахуванням особливостей
банківської діяльності, стандартів та вимог Національного банку
України з питань інформаційної безпеки. Впровадження стандартів з питань управління інформаційною
безпекою не може бути разовою акцією. Це фактично є безперервним
процесом розроблення, впровадження, функціонування, моніторингу,
перегляду, підтримування та вдосконалення системи управління
інформаційною безпекою (СУІБ). Для процесів СУІБ застосована
модель ПВПД (плануй - виконуй - перевіряй - дій), наведена у
вступі до стандарту СОУ Н НБУ 65.1 СУІБ 1.0:2010. Зрозуміло, що для проведення цих робіт потрібні ресурси, у
тому числі наявність фахівців з питань інформаційної безпеки,
наявність з боку керівництва банку повної підтримки та контролю, а
також розуміння проблем, що виникають. Система інформаційної безпеки повинна забезпечити безпечність
та надійність функціонування бізнес-процесів / банківських
продуктів банку. Впровадження та функціонування СУІБ стосується
всіх підрозділів банку і, у першу чергу, керівників підрозділів -
власників бізнес-процесів / банківських продуктів. Тому ці
відповідальні особи повинні брати участь у вирішенні питань, що
належать до сфери їх відповідальності, під час упровадження та
функціонування СУІБ. Цілі СУІБ та заходи безпеки, що вже існують і ті, що будуть
додатково впроваджені в разі необхідності, а також відповідна
документація, що описує функціонування СУІБ, повинні бути
зрозумілими для всіх, кого це стосується. Тому обов'язковою умовою
успішного функціонування СУІБ є також проведення відповідних
навчань з питань інформаційної безпеки.
3. Підготовка до впровадження СУІБ
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. Опис існуючої інфраструктури та заходів безпеки
4.1. Класифікація інформації
Відповідно до Закону України "Про інформацію" ( 2657-12 ) вся
інформація з обмеженим доступом повинна бути надійно захищена.
Відповідно до законів України "Про захист інформації в
інформаційно-телекомунікаційних системах" ( 80/94-ВР ), "Про банки
і банківську діяльність" ( 2121-14 ), "Про захист персональних
даних" ( 2297-17 ) у банках можна визначити такі категорії
інформації з обмеженим доступом: - банківська таємниця; - комерційна таємниця; - персональні дані; - інша конфіденційна інформація. Банк має створити максимально докладний та зрозумілий перелік
відомостей, які відносяться до інформації з обмеженим доступом. У
цьому переліку повинні бути описані види інформації, які
відносяться до кожної з категорій інформації з обмеженим доступом,
що надасть можливість полегшити працівнику банку визначення
відношення певної інформації до відповідної категорії. Відповідно до Правил зберігання, захисту, використання та
розкриття банківської таємниці, затверджених постановою Правління
Національного банку України від 14.07.2006 N 267 ( z0935-06 ),
зареєстрованих в Міністерстві юстиції України 03.08.2006 за
N 935/12809, працівники банку під час прийому на роботу повинні
власноруч підписувати зобов'язання щодо збереження банківської
таємниці. Ці зобов'язання банк може поширити на всі категорії
інформації з обмеженим доступом. Банк зобов'язаний у внутрішніх положеннях встановити
спеціальний порядок поводження та ведення діловодства з
документами, що містять інформацію з обмеженим доступом, зокрема
визначити порядок підготовки і реєстрації вихідних документів,
роботи з документами, відправлення та зберігання документів, а
також особливості роботи з електронними документами, які містять
інформацію з обмеженим доступом, зокрема з урахуванням вимог, що
викладені в наведеному вище нормативно-правовому акті
Національного банку України. Особливу увагу слід звернути на маркування документів з
обмеженим доступом. Скорочені позначки грифу інформації з
обмеженим доступом повинні бути загально відомими, наприклад,
банківська таємниця - БТ, комерційна таємниця - КТ тощо. Не
рекомендується використовувати інші літери для скорочених позначок
грифу інформації, які не пов'язані із повною назвою грифу та не є
інтуїтивно зрозумілими.
4.2. Опис критичних бізнес-процесів
та програмно-технічних комплексів,
які забезпечують їх функціонування
Відповідно до вимог стандартів Національного банку України
сферою застосування СУІБ, яка має бути впроваджена, є банк у
цілому. Тому дуже важливо чітко визначити бізнес-процеси /
банківські продукти, які працюють з інформацією з обмеженим
доступом і повинні бути захищеними. Відповідно до Положення про організацію операційної
діяльності в банках України, затвердженого постановою Правління
Національного банку України від 18.06.2003 N 254 ( z0559-03 ),
банківський продукт-це стандартизовані процедури, що забезпечують
виконання банками операцій, згрупованих за відповідними типами та
ознаками. Поняття бізнес-процесу є багатозначним і не існує загально
прийнятого його визначення. Під бізнес-процесом у широкому
значенні розуміється структурована послідовність дій з виконання
певного виду діяльності на всіх етапах життєвого циклу предмета
діяльності. Кожен бізнес-процес має початок (вхід), вихід та
послідовність процедур, які забезпечують виконання операцій,
згрупованих за відповідними типами. Не існує стандартного набору бізнес-процесів/банківських
продуктів для будь-якого банку. Тому банк має самостійно визначити
відповідні бізнес-процеси/банківські продукти, які
використовуються всередині банку. Для визначення бізнес-процесів/банківських продуктів, які має
охоплювати СУІБ, необхідно проаналізувати всі бізнес-процеси/
банківські продукти банку та створити перелік критичних процесів,
функціонування яких має великий вплив на успішну роботу банку.
Оскільки в банку бізнес-процеси/банківські продукти
взаємопов'язані, то рекомендується створити їх блок-схему з
визначенням усіх взаємозв'язків. Така візуалізація значно
спростить розуміння всього обсягу робіт, що виконуються банком. Банк повинен створити перелік критичних бізнес-процесів/
банківських продуктів, які обробляють інформацію з обмеженим
доступом, розголошення якої може нанести шкоду банку. До цього
переліку повинні бути включеними всі бізнес-процеси/банківські
продукти, що обробляють: - платіжні документи, - внутрішні платіжні документи, - кредитні документи, - документи на грошові перекази, - персональні дані клієнтів та працівників банку, - статистичні звіти, - інші документи, які містять інформацію з обмеженим
доступом. Для кожного критичного бізнес-процесу/банківського продукту
рекомендується надати перелік бізнес-процесів/банківських
продуктів, з якими взаємодіє цей бізнес-процес/банківський
продукт. Перелік критичних бізнес-процесів/банківських продуктів
повинен супроводжуватися коротким описом кожного бізнес-процесу/
банківського продукту з наданням інформації про програмно-технічні
комплекси, які забезпечують його функціонування. Короткий опис кожного бізнес-процесу/банківського продукту
повинен містити таку інформацію: - назва бізнес-процесу/банківського продукту; - цілі бізнес-процесу/банківського продукту; - гриф інформації з обмеженим доступом, яка обробляється
бізнес-процесом/банківським продуктом; - власник бізнес-процесу/банківського продукту; - підрозділи банку, які забезпечують функціонування
бізнес-процесу/банківського продукту; - наявність зобов'язань перед третіми сторонами (угоди на
розроблення, доопрацювання, супроводження та технічне
обслуговування); - вхідні та вихідні дані бізнес-процесу/банківського
продукту; - перелік процедур бізнес-процесу та блок-схема послідовності
їх виконання з визначенням взаємозв'язків (у тому числі додаткової
вхідної інформації з інших бізнес-процесів); - вимоги щодо забезпечення безперервності бізнес-процесу/
банківського продукту (максимально допустимий час простою); - типи ролей (груп) для бізнес-процесу/банківського продукту; - існування забороненого суміщення типів ролей; - програмно-технічний(ні) комплекс(и), що забезпечує(ють)
функціонування бізнес-процесу; - кількість користувачів програмно-технічного комплексу; - архітектура і технологія роботи (зокрема, файловий обмін
або режим реального часу, в тому числі й для обміну інформацією з
іншими програмно-технічними комплексами в разі наявності); - операційна система та тип бази даних програмно-технічного
комплексу, які використовуються для функціонування
бізнес-процесу/банківського продукту; - географічне розміщення (серверів та робочих місць)
програмно-технічного комплексу; - засоби захисту, які вже існують у програмно-технічному
комплексі; - взаємодія з іншими програмно-технічними комплексами; - принципи резервування обладнання та інформації
програмно-технічного комплексу (за наявності окремих принципів для
цього програмно-технічного комплексу). Зазначимо деякі аспекти формування цієї інформації. Дуже важливо визначити власника бізнес-процесу / банківського
продукту, який повинен також бути власником програмно-технічного
комплексу. Саме власник бізнес-процесу / банківського продукту /
програмно-технічного комплексу повинен приймати рішення щодо
надання доступу до інформації, яка обробляється в цьому
бізнес-процесі / банківському продукту / програмно-технічному
комплексі. Власником програмно-технічного комплексу не може бути
підрозділ банку, який відповідає за інформаційні технології і
забезпечує технічну підтримку роботи комплексу. Перелік процедур бізнес-процесу та блок-схема послідовності
їх виконання з визначенням взаємозв'язків (у тому числі додаткової
вхідної інформації з інших бізнес-процесів) буде дуже корисним під
час аналізу та визначення вразливостей, притаманних цьому
бізнес-процесу / банківському продукту. Цей перелік та блок-схема
мають бути у достатньому ступені узагальненими. Дуже детальний
перелік може призвести до ускладнення під час визначення
вразливостей. Однак, якщо цей перелік та блок-схема будуть занадто
узагальненими, то це може призвести до пропуску небезпечних
вразливостей, які можуть створювати великі ризики. У разі якщо функціонування одного бізнес-процесу /
банківського продукту забезпечується декількома
програмно-технічними комплексами, тоді короткі описи кожного
комплексу та їх взаємозв'язків повинні також бути надані. У разі якщо один програмно-технічний комплекс забезпечує
функціонування декількох бізнес-процесів / банківських продуктів,
тоді визначається єдиний власник програмно-технічного комплексу
(але не підрозділ, який відповідає за інформаційні технології) або
група власників бізнес-процесів, які надають та контролюють доступ
до інформації, що обробляється різними модулями комплексу. У разі відсутності централізованих програмно-технічних
комплексів мають бути надані короткі описи програмно-технічних
комплексів у структурних підрозділах банку (обласних дирекціях,
філіях тощо) та описаний взаємозв'язок між ними. Для більшого розуміння зв'язків між бізнес-процесами /
банківськими продуктами / програмно-технічними комплексами
рекомендується створити блок-схему цих зв'язків із додаванням
структурних підрозділів банку, які забезпечують ці
бізнес-процеси / банківські продукти / програмно-технічні
комплекси вхідною інформацією, та підрозділів банку, які
використовують вихідні дані. Типи ролей (груп) для бізнес-процесу / банківського продукту
фактично означають різні рівні доступу до інформації, яка
обробляється цим бізнес-процесом / банківським продуктом. При
цьому слід пам'ятати про необхідність надання мінімальних прав
доступу, необхідних для виконання службових обов'язків.
Обов'язковим також є визначення заборонених суміщень прав доступу
(ініціювання та подальше виконання операції) для запобігання
підготовки фальсифікованих банківських документів або
несанкціонованої модифікації документів. Наприклад, для платіжних
документів забороненим є суміщення обов'язків операціоніста та
бухгалтера.
4.3. Опис організаційної структури
банку, яку охоплює СУІБ
На основі вихідних документів попереднього пункту банк має
визначити всі підрозділи, які відносяться до сфери застосування
СУІБ. Це підрозділи, які є власниками та учасниками критичних
бізнес-процесів, підрозділи, які супроводжують та забезпечують
технічну підтримку програмно-технічних комплексів, користувачі
програмно-технічних комплексів, служба безпеки, яка забезпечує
фізичну безпеку приміщень банку, тощо. Наявність такого переліку
підрозділів дозволить чітко визначити обов'язки та
відповідальності всіх причетних до виконання вимог безпеки сторін
та планувати їх навчання у разі необхідності. Такий перелік може
створюватися на основі структурної схеми підрозділів банку. Окрім того, у разі наявності передавання частини послуг, що
пов'язані з критичними бізнес-процесами / банківськими
продуктами/програмно-технічними комплексами, третім сторонам, ці
організації також повинні бути включені до опису організаційної
структури банку з поміткою, що вони не є структурними підрозділами
банку.
4.4. Опис структури мережі банку
Для подальшого аналізу захищеності мережі банку необхідно
зробити опис структури мережі банку, засобів захисту та
управління, які вже існують. Банк повинен мати внутрішнє положення
про мережу банку, у якому надається така інформація: - принципи побудови мережі з описом принципів резервування
мережевого обладнання; - принципи розподілу мережі на сегменти (підмережі) - за
наявності; - принципи розподілу адресного простору; - система управління мережею; - побудова вузла доступу до ресурсів мережі Інтернет; - принципи доступу до мереж інших організацій - за наявності; - наявність та правила роботи через канали зв'язку зовнішніх
провайдерів телекомунікаційних послуг, у тому числі опис принципів
резервування каналів зв'язку; - засоби захисту мережі від зовнішнього та внутрішнього
несанкціонованого доступу, у тому числі антивірусного захисту; - принципи надання доступу працівникам банку до мережі та
ресурсів мережі Інтернет; - принципи та процедура надання віддаленого доступу
працівникам банку до мережі банку - за наявності; - принципи та процедура надання бездротового доступу до
мережі банку - за наявності; - принципи резервного копіювання інформації. Для спрощення розуміння особливостей побудови мережі банку
рекомендується створити окремі внутрішні положення (політики) за
різними питаннями управління мережею, а в загальному положенні про
мережу описати основні принципи побудови та функціонування мережі
з наданням посилань на окремі політики.
4.5. Опис фізичного середовища
Питання захисту інфраструктури банку також входять до СУІБ. Банк повинен мати такі документи: - опис географічного та територіального розташування
приміщень банку, включаючи відокремлені підрозділи банку (обласні
дирекції, філії, відділення тощо) для визначення загроз з боку
навколишнього середовища; - опис принципів пропускного режиму; - наказ із визначення приміщень з обмеженим доступом та опис
відповідного захисту цих приміщень із забезпеченням контролю
доступу до таких приміщень; - опис принципів побудови систем відео спостереження; - опис системи електроживлення та заземлення; - опис охоронної та пожежної сигналізації; - опис умов зберігання магнітних, оптомагнітних, паперових та
інших носіїв інформації, у тому числі електронних архівів. Вимоги до приміщень банків наведені у Правилах технічного
захисту приміщень банків, де обробляються електронні банківські
документи, затверджені постановою Правління Національного банку
України від 04.07.2007 N 243 ( z0955-07 ), зареєстрованою в
Міністерстві юстиції України 17.08.2007 за N 955/14222, та інших
нормативно-правових актах Національного банку України.
4.6. Опис принципів
забезпечення безперервності роботи
Однією з основних функцій банку є забезпечення безперервності
його роботи. Основні вимоги до банку з цього питання викладені у
Положенні про забезпечення безперервного функціонування
інформаційних систем Національного банку України та банків
України, затвердженому постановою Правління Національного банку
України від 17.06.2004 N 265 ( z0857-04 ), зареєстрованою в
Міністерстві юстиції України 09.07.2004 за N 857/9456. Банк повинен мати опис принципів та заходів щодо забезпечення
безперервності роботи, в якому надати опис процедур та обладнання,
а також обов'язків працівників банку, в тому числі методи
резервування інформації для відновлення роботи в разі виникнення
надзвичайних ситуацій. У цьому документі повинні бути визначені
терміни відновлення роботи банку та необхідні ресурси (зокрема
програмно-технічні засоби, обладнання, резервне електроживлення
тощо). Банк повинен регулярно проводити тестування всіх складових,
що потрібні для виконання плану забезпечення безперервної
діяльності та дій у разі виникнення надзвичайних ситуацій, у тому
числі можливість відновлення резервної інформації, яка
зберігається у віддаленому резервному пункті.
5. Аналіз ризиків
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. Оцінка ризиків
6.1. Методологія оцінювання ризиків
Аналіз ризиків може бути виконаний з різним ступенем
деталізації в залежності від критичності ресурсів СУІБ /
бізнес-процесів / банківських продуктів, відомих вразливостей і
попередніх інцидентів інформаційної безпеки. Методологія оцінки
ризиків може бути кількісною або якісною, або їх комбінацією. На
практиці якісна оцінка часто використовується спочатку для
визначення загального рівня ризику і визначення основних ризиків.
Далі може виникнути необхідність виконання більш специфічного або
кількісного аналізу стосовно основних ризиків. Кількісна оцінка
ризиків є більш складною та потребує більше часу та ресурсів.
Однак така оцінка буде дуже корисною у випадках, коли рішення щодо
оброблення ризиків буде залежати від вартості заходів безпеки, які
можуть бути більшими, ніж фінансові втрати інциденту інформаційної
безпеки. Якісна методика оцінки ризиків використовує шкалу атрибутів
для опису величини потенціальних наслідків реалізації загроз і
вірогідність того, що такі наслідки виникнуть. Перевагою якісної
методики є її простота розуміння всім персоналом; недоліком такої
методики є залежність від суб'єктивного вибору шкали атрибутів. Для отримання якісної оцінки ризиків необхідно розглянути
оцінки наслідків реалізації загроз разом із вразливостями, з
використанням яких ці загрози можуть реалізуватися, та оцінки
ймовірності їх реалізації для кожного бізнес-процесу /
банківського продукту, мережі, обладнання, програмного
забезпечення, які забезпечують функціонування цього
бізнес-процесу / банківського продукту, мережі банку в цілому,
фізичного середовища, персоналу тощо, як описано в додатку 2, з
урахуванням попереднього аналізу. Для виконання оцінки ризиків необхідно визначити шкалу для
різних параметрів: оцінки величини наслідків реалізації загрози на
сервіси безпеки (цілісність, конфіденційність, доступність,
спостережність), оцінки ймовірності реалізації загрози. Загальний
рівень оцінки величини наслідків реалізації кожної загрози на
сервіси безпеки визначається як максимальна величина з окремих
оцінок впливу на цілісність, конфіденційність, доступність,
спостережність. Звертаємо увагу на те, що оцінка ймовірності не є
математичною величиною вірогідності, яка не може перевищувати 1. Рівень ризику за окремою парою загроза/вразливість, яка може
використовуватися для реалізації цієї загрози, визначається
перемноженням загального рівня оцінки величини наслідків на оцінку
ймовірності реалізації загрози. Загальний рівень ризику для бізнес-процесу / банківського
продукту, персоналу, фізичного середовища тощо дорівнює
максимальної величині з усіх ризиків за кожною парою
загроза/вразливість. Рекомендується використовувати такі шкали для оцінки ризиків: Для оцінки ймовірності реалізації загроз:
------------------------------------------------------------------ |Оцінка ймовірності| Опис | |------------------+---------------------------------------------| | 1 |Виникнення інциденту практично неможливо | |------------------+---------------------------------------------| | 2 |Виникнення інциденту малоймовірне (не частіше| | |ніж 1 раз на 1 рік) | |------------------+---------------------------------------------| | 3 |Виникнення інциденту ймовірне до 1 разу на | | |3 місяці | |------------------+---------------------------------------------| | 4 |Виникнення інциденту ймовірне до 1 разу на | | |тиждень | |------------------+---------------------------------------------| | 5 |Виникнення інциденту ймовірне до 1 разу на | | |добу | ------------------------------------------------------------------
Для величини наслідків реалізації загрози: вплив на
цілісність:
------------------------------------------------------------------ |Оцінка рівня наслідків| Опис | |----------------------+-----------------------------------------| | 1 |Практично не призводить до наслідків з | | |фінансовими втратами | |----------------------+-----------------------------------------| | 2 |Призводить до незначних фінансових втрат | | |(визначити суму) та має незначний вплив | | |на репутацію банку | |----------------------+-----------------------------------------| | 3 |Призводить до значних фінансових втрат | | |(визначити суму) та має значний вплив на | | |репутацію банку | |----------------------+-----------------------------------------| | 4 |Призводить до великих фінансових втрат | | |(визначити суму), має значний вплив на | | |репутацію банку і може призвести до | | |зупинки роботи бізнес-процесу / | | |банківського продукту | |----------------------+-----------------------------------------| | 5 |Призводить до зупинки бізнес-процесу / | | |банківського продукту і порушує | | |законодавство України | ------------------------------------------------------------------
Для величини наслідків реалізації загрози: вплив на
конфіденційність:
------------------------------------------------------------------ |Оцінка рівня наслідків| Опис | |----------------------+-----------------------------------------| | 1 |Практично не призводить до розкриття | | |конфіденційної інформації | |----------------------+-----------------------------------------| | 2 |Призводить до розкриття окремих | | |документів, які відносяться до | | |"банківської таємниці", "комерційної | | |таємниці", персональних даних і не | | |призводить до фінансових втрат | |----------------------+-----------------------------------------| | 3 |Призводить до розкриття окремих | | |документів, які відносяться до | | |"банківської таємниці", "комерційної | | |таємниці", персональних даних і | | |призводить до незначних фінансових втрат | | |(визначити суму) | |----------------------+-----------------------------------------| | 4 |Призводить до розкриття документів, які | | |відносяться до "банківської таємниці", | | |"комерційної таємниці", персональних | | |даних і призводить до значних фінансових | | |втрат (визначити суму), має значний вплив| | |на репутацію банку і може призвести до | | |зупинки роботи бізнес-процесу / | | |банківського продукту | |----------------------+-----------------------------------------| | 5 |Призводить до зупинки бізнес-процесу / | | |банківського продукту і порушує | | |законодавство України | ------------------------------------------------------------------


Якщо Ви побачили помилку в тексті, виділіть її мишкою та натисніть Ctrl-Enter. Будемо вдячні!

вгору