Чому потрібен план реагування на кіберінциденти

25 травня 2018, 13:00
Вы также можете прочесть этот материал на русском языке

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

Найбільш резонансним став регламент ЄС із захисту персональних даних GDPR, що набуває чинності 25 травня 2018 року і є обов’язковим для усіх, хто збирає, обробляє та зберігає персональні дані громадян країн ЄС. Тим часом, 1 березня набула чинності Постанова №95 НБУ, яка є обов’язковою для виконання українськими банками. Що є спільного між цими ініціативами?

Відео дня

По-перше, державні органи намагаються скоротити відстань між професійними рівнями двох сторін: кіберзлочинців (bad guys) та відділу Інформаційної Безпеки (ІБ) (good guys). В реаліях України остання сторона досить часто представлена в особі однієї людини, яка являється водночас і Chief Information Security Officer (CISO), і відділом інформаційної безпеки - це у випадку, якщо існує відділ ІБ. Але у більшості компаній функцію ІБ виконує взагалі ІТ-відділ.

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

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

Задача №1. Визначаємо поняття

В першу чергу, CISO/керівник відділу інформаційної безпеки має визначитись із поняттям "інцидент інформаційної безпеки". Це допоможе встановити межі відповідальності відділу та класифікувати інциденти за пріоритетами їх критичності. Єдиного поняття терміну “інцидент інформаційної безпеки” немає, але описати його можна через супутні складові — це подія, яка відповідає наступним вимогам:

  • здійснена особою або групою осіб;
  • використано комп’ютерні ресурси;
  • потенційно/реально несе шкоду інформаційно-комунікаційній системі.

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

Задача №2. Розробляємо план реагування на інцидент (Incident Response Plan) і формуємо команду реагування (Incident Response Team).

Якщо знову повернутися до аналогії з будівлею та її протипожежним захистом, то План Реагування можна порівняти з інструкцією при пожежі, а Команду Реагування – з рятівною службою. Відповідно, план повинен бути чітким і зрозумілим для всіх, а команда реагування повинна бути готовою 24/7, тому найкраще, якщо це буде включено до їхніх посадових обов’язків.

Отже, почнемо з плану реагування на інцидент. Процес обробки інциденту зображено на схемі:

Рис 1. Життєвий цикл інциденту інформаційної безпеки

Система моніторингу (Monitoring) виявляє проблему (Issue). Після цього запускається процес інформування керівника команди реагування (Notification). Він, у свою чергу, ініціює План реагування та підключає Команду реагування (Response). Під час роботи команди важливо документувати увесь хід розслідування.

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

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

Після закінчення процесу розв’язання інциденту (Resolution) запускається процес оцінки ефективності Команди реагування (AAR/After Action Review). Головна мета оцінки ефективності, як у класичних підходах проектного менеджменту – це визначити слабкі місця у роботі Команди реагування і розробити відповідні заходи, щоб зробити її більш ефективною.

Отже, покроковий організайційний план Реагування на інциденти інформаційної безпеки виглядає так:

  1. Визначення інциденту інформаційної безпеки.
  2. Класифікація інцидентів ІБ за ступенем ризику.
  3. Згідно класифікації розробка максимально чіткого та зрозумілого Плану реагування на інцидент.
  4. Створення Команди реагування і ознайомлення її з Планом реагування.
  5. Постійна оцінка ефективності роботи цієї схеми та її вдосконалення.
  6. Ведення документації по всіх проведеним розслідуванням.

В результаті компанія отримає відповідність ряду нормативних та організаційних вимог. Зокрема доказову базу у разі виявлення несанкціонованого доступу до даних (data breach) згідно GDPR, а також відповідність вимогам Розділу №4 Постанови №95 НБУ. Щодо організаційних переваг, то у довгостроковому терміні компанія отримає економію фінансових, людських і часових ресурсів, а також зниження ризиків матеріальних та нематеріальних втрат від кіберінцидентів.

Приєднуйтесь до нас у соцмережах Facebook, Telegram та Instagram.

poster
Картина ділового тижня

Щотижнева розсилка головних новин бізнесу і фінансів

Розсилка відправляється по суботах

Показати ще новини
Радіо НВ
X