Почему нужен план реагирования на киберинциденты
Последние годы характерны тем, что в Украине и мире появляются новые законодательные инициативы в сфере информационной безопасности.
Наиболее резонансным стал регламент ЕС по защите персональных данных 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). Главная цель оценки эффективности, как в классических подходах проектного менеджмента – это определить слабые места в работе Команды реагирования и разработать соответствующие меры, чтобы сделать ее более эффективной.
Итак, пошаговый организайционый план Реагирования на инциденты информационной безопасности выглядит так:
- Определение инцидента информационной безопасности.
- Классификация инцидентов ИБ по степени риска.
- Согласно классификации разработка максимально четкого и понятного плана реагирования на инцидент.
- Создание Команды реагирования и ознакомление ее с Планом реагирования.
- Постоянная оценка эффективности работы этой схемы и ее совершенствование.
- Ведение документации по всем проведенным расследованиям.
В результате компания получит соответствие ряда нормативных и организационных требований. В частности доказательную базу в случае выявления несанкционированного доступа к данным (data breach) согласно GDPR, а также соответствие требованиям раздела №4 Постановления №95 НБУ. По организационным преимуществам, то в долгосрочном периоде компания получит экономию финансовых, человеческих и временных ресурсов, а также снижение рисков материальных и нематериальных потерь от киберинцидентов.
