Мне кажется, многие компании переоценивают качество своих планов реагирования на киберинциденты.

Документ может быть подробным. Ответственные — назначенными. Схема эскалации — согласованной. Контакты подрядчиков — актуальными.

Но реальная готовность проверяется не наличием документа.

Она проверяется в тот момент, когда руководству приходится выбирать между несколькими плохими вариантами.

Например:

ИБ рекомендует немедленно отключить критическую систему, чтобы остановить распространение атаки.

IT предупреждает, что аварийное отключение может повредить данные. Владелец бизнес-процесса сообщает, что простой приведёт к нарушению обязательств перед клиентами.

Кто принимает решение?

CISO? CIO? Владелец процесса? Генеральный директор? Кризисный комитет? Формулировка «решение принимает кризисный комитет» сама по себе не решает проблему. Комитет не является субъектом ответственности. Внутри него всё равно должен быть человек, обладающий полномочиями принять конкретный риск.

Поэтому tabletop exercise для руководства не должен превращаться в коллективное чтение IR-плана.

Он должен проверять:

— распределение полномочий; — способность принимать решения при неполной информации; — конфликт между безопасностью и непрерывностью бизнеса; — готовность юридической и коммуникационной функций; — зависимость от подрядчиков и внешних провайдеров; — критерии безопасного восстановления; — способность фиксировать решения и основания для них.

Слабое учение обычно проходит слишком гладко.

Участники заранее знают сценарий. События развиваются последовательно. Каждая функция рассказывает, что должна сделать по регламенту. В конце команда успешно «локализует атаку».

Настоящий инцидент так не выглядит.

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

Хорошее учение должно постепенно разрушать удобные предположения.

Решили восстановить систему из резервной копии? Следующий вводный сигнал показывает, что злоумышленник мог находиться в инфраструктуре несколько месяцев.

Решили пока не комментировать ситуацию? Журналист направляет запрос с образцами похищенных документов.

Решили продолжить работу системы? Аналитики обнаруживают дальнейшее перемещение злоумышленника по инфраструктуре.

Задача ведущего — не помочь участникам «победить». Его задача — показать, где организация теряет способность управлять ситуацией.

На мой взгляд, результат хорошего tabletop exercise должен быть немного неудобным.

После него может выясниться, что: — два руководителя считают себя владельцами одного решения; — решение об остановке системы некому принять ночью; — ИБ и юристы по-разному определяют существенный инцидент; — бизнес не согласовал допустимую продолжительность простоя; — восстановление технически возможно, но критерии безопасного запуска отсутствуют; — критический подрядчик не обязан помогать в нужный срок.

Это не провал учений. Это их ценность.

Успешное учение — не то, где команда справилась со сценарием.

Успешное учение — то, после которого компания изменила свою систему принятия решений.

А что чаще проверяют на tabletop-учениях в ваших компаниях: реальную готовность руководства или знание заранее написанного регламента?