Почему нужен план реагирования на киберинциденты

1 комментировать

Последние годы характерны тем, что в Украине и мире появляются новые законодательные инициативы в сфере информационной безопасности.

Наиболее резонансным стал регламент ЕС по защите персональных данных 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 НБУ. По организационным преимуществам, то в долгосрочном периоде компания получит экономию финансовых, человеческих и временных ресурсов, а также снижение рисков материальных и нематериальных потерь от киберинцидентов.


Читайте срочные новости и самые интересные истории в Viber и Telegram Нового Времени.

Комментарии

1000

Правила комментирования
Показать больше комментариев
Если Вы хотите вести свой блог на сайте Новое время Бизнес, напишите, пожалуйста, письмо по адресу: kolonka@nv.ua

Эксперты ТОП-10

Читайте на НВ style

Последние новости

опрос

Погода
Погода в Киеве

влажность:

давление:

ветер: