16. Усунення причин, наслідків інциденту і його розслідування

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

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

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

17. Коректуючі та превентивні дії

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

Ми розглянули всі етапи моделі PDCA стосовно процесу управління інцидентами інформаційної безпеки. Далі, для того щоб процедура виконувалася правильно і ефективно, всі ці етапи повинні безперервно і послідовно повторюватися. Через певний час (як правило, через півроку або рік) необхідно знову переглянути перелік подій, що звуться інцидентами, форму звіту та ін., впровадити оновлену процедуру в інформаційну систему, перевірити її функціонування та ефективність і реалізувати превентивні дії. Таким чином, цикл моделі PDCA буде безперервно повторюватися і гарантувати чітке функціонування процедури управління інцидентами, а головне, її постійне поліпшення.

Процедура управління ІТ-інцидентами регулюється стандартом ISO/IEC 20000:2005, що прийшов на зміну BS 15000:2002, який, у свою чергу, взяв за основу бібліотеку ITIL. Слід зазначити, що всі ISO/IEC серій 9000, 14000, 20000, 27000 та інші стандарти ISO/IEC, що описують правила створення систем управління різними процесами, гармонійно поєднуються один з одним. Всі вони в якості основи управління підконтрольними процесами використовують процесний підхід, який розглядає управління як процес, а саме як набір взаємозв'язаних безперервних дій. Процесний підхід акцентує увагу на досягненні поставлених цілей, а також на ресурсах, витрачених для цього. Окрім цього, стандарти вказаних серій використовують модель PDCA як структуру життєвого циклу всіх процесів системи управління.

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

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

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

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