Обсуждаемые, малострессовые симуляции, в ходе которых ИТ-специалисты, юристы и другие ключевые руководители рассматривают теоретические сценарии для проверки готовности к киберинцидентам, являются популярным и весьма полезным инструментом. Однако если тренировки в формате настольных учений проводятся неправильно, результаты могут вводить в заблуждение и потенциально наносить ущерб.
Когда обучение реагированию на инциденты в вашей организации постоянно не достигает поставленных целей, это открывает путь к целому ряду часто непредвиденных угроз. К счастью, проведение эффективных настольных учений не так сложно, как реагирование на реальную ситуацию. Вот обзор семи наиболее распространенных ошибок при проведении настольных учений, которых следует избегать.
Отсутствие четкого набора целей
Самая большая ошибка — проводить настольные учения без четких, измеримых целей, связанных с реалистичными бизнес-решениями, говорит Шэрон Чанд, руководитель направления киберзащиты и устойчивости в Deloitte США.
«На практике это обычно проявляется в виде общего сценария с программами-вымогателями или инсайдерской угрозой, сопровождаемого расплывчатыми целями и отсутствием твердого согласия относительно того, как на самом деле выглядит „хороший“ результат», — объясняет она. «Это приводит к тому, что учения теряют фокус, поощряя уверенную импровизацию вместо реального качества процессов, и оставляет руководителей неспособными определить, действительно ли план реагирования на инциденты работает».
Вместо этого Чанд советует ИТ-руководителям и специалистам по кибербезопасности предоставлять четкие ориентиры и директивы относительно того, чего должны достичь настольные учения.
«Когда руководители рассматривают сессию как „давайте пройдемся по сценарию взлома“, а не как „давайте протестируем эскалацию, юридическое уведомление, права на принятие решений руководством и приоритеты восстановления“, учения быстро вырождаются в дискуссионный театр, а не в проверку готовности», — говорит она.
Тестирование сценариев, с которыми вы уже умеете справляться
Аюш Радж Джха, старший инженер-программист в Oracle Health, вспоминает случай, когда он участвовал в настольных учениях, где каждый инцидент представлял собой чистый, четко определенный случай программы-вымогателя с очевидными точками принятия решений.
«Все отлично справились, но через три месяца у нас произошел реальный частичный сбой в нашей многорегиональной системе аварийного восстановления (DR), где сбой был неоднозначным», — говорит он. Две системы сообщали противоречивые данные о своем состоянии, и никто не мог договориться, произошел ли фактический отказ или нет. «Такого сценария, — говорит Джха, — никогда не было ни в одних настольных учениях».
Ущерб заключается не в том, что люди паникуют; а в том, что они замирают, потому что реальный инцидент не похож на тренировочный, говорит Джха, который рекомендует изначально делать сценарий намеренно неоднозначным.
«Предоставьте людям неполную информацию и противоречивые сигналы и посмотрите, как они принимают решения в условиях неопределенности», — советует он. «Потому что именно так выглядят реальные инциденты».
Неспособность разработать опасности, релевантные для бизнеса
Многие ИТ-руководители рассматривают регулярные настольные учения как рутинное обязательство, а не как важнейшую задачу по обеспечению безопасности, говорит Джейсон Стейдинг, директор исследовательской и консалтинговой фирмы ISG. Снижая важность учений, эти люди не разрабатывают сценарии с учетом реальных рисков, точек принятия решений и персонала своей организации.
«На практике это обычно проявляется в двух формах: выбор сценария, который не является реалистичным или актуальным для организации, и неучастие в учениях нужных заинтересованных сторон», — говорит он.
Когда безразличный сценарий не затрагивает реальные опасности организации, участники часто застревают на обсуждении того, может ли что-то произойти, вместо того чтобы сосредоточиться на том, что им следует делать дальше, говорит Стейдинг. Лучший подход, по его словам, — это вдумчивое совместное планирование, проводимое до начала учений.
«Сценарий должен строиться вокруг фактической среды организации, ее приоритетов в бизнесе, прошлых инцидентов и реалистичных угроз, наблюдаемых в отрасли», — рекомендует Стейдинг.
В список участников должны входить все, кто был бы задействован в реальном событии: безопасность, ИТ, юристы, коммуникации, отдел кадров, операционные службы и, возможно, даже высшее руководство.
«После каждых учений руководители должны фиксировать, где застопорилось принятие решений, где была неясна ответственность и чьи голоса отсутствовали, а затем использовать эти уроки для улучшения следующего сценария», — говорит он.
Потеря поддержки заинтересованных сторон из-за нехватки технических деталей
Ключевые заинтересованные стороны часто не участвуют в тренировочных симуляциях, поскольку считают цепочку атак непрактичной или маловероятной, учитывая некачественную архитектуру и среду проекта.
«Заинтересованные стороны просто считают это занятие пустой тратой времени», — отмечает Блейк Сифелли, старший консультант по консультированию в области реагирования на инциденты в компании GuidePoint Security. «Все, что представлено в симуляции, должно иметь технический смысл и логически связываться друг с другом», — советует он.
«В настольных учениях, как и в любой другой оценке, вы получаете столько, сколько вкладываете», — говорит Сифелли. «Если вы рассматриваете учения как галочку для соблюдения требований и вкладываете лишь минимальные усилия в настройку и участие, вы достигнете базового уровня безопасности, но ваша команда реагирования и программа получат от этого мало пользы».
Акцент на запоминании вместо принятия решений
Распространенная ошибка — рассматривать настольные учения как сценарии, основанные на скриптах и соблюдении требований, а не как реалистичные симуляции, основанные на принятии решений, говорит Энсар Секер, CISO в фирме SOCRadar, занимающейся разработкой ПО для мониторинга угроз и цифровых рисков.
«Многие организации разрабатывают сценарии с заранее определенным „счастливым путем“, по которому участники тонко направляются к ожидаемым ответам, вместо того чтобы заставлять их справляться с неопределенностью, противоречивыми сигналами и неполной информацией — условиями, которые определяют реальные инциденты», — говорит он.
Такой подход может создать ложное чувство готовности, говорит Секер. «Команды могут выглядеть скоординированными во время учений, но когда происходит реальный инцидент, они испытывают трудности с неопределенностью, временем эскалации и межфункциональной коммуникацией», — отмечает он. «По сути, организация проверяет запоминание процесса, а не принятие решений под давлением, что и является причиной большинства сбоев».
Предпочтение концептуального перед практическим
Мишель Сахьюн, главный архитектор решений в компании NopalCyber, предоставляющей услуги управляемой кибербезопасности, предостерегает от создания настольных сценариев, которые слишком теоретизированы и лишены богатых, реальных деталей.
«Например, учения могут быть построены вокруг инцидента с программой-вымогателем, но при этом содержать очень мало конкретных деталей», — говорит он. Это часто приводит к тому, что участники склонны отвечать абстрактными, высокоуровневыми терминами, вместо того чтобы вникать в конкретные действия и решения, необходимые при реальном реагировании на инцидент.
Высокодетализированные сценарии могут создавать те самые точки трения, которые необходимо проверить, говорит Сахьюн, отмечая, что когда модератор вводит специфику, например, скомпрометированный контроллер домена, зашифрованные файловые ресурсы, связанные с финансами, или оповещение, сработавшее в 2:00 ночи в праздничные выходные, команды могут прийти в замешательство.
«Столкнувшись с такой ситуацией, участники должны бороться с неполной информацией, конкурирующими приоритетами и нехваткой времени», — советует он. «Именно здесь начинают проявляться пробелы в инструментарии, неясная ответственность и сбои в коммуникации».
Основная проблема подхода, основанного на теории, заключается в том, что он создает ложное чувство готовности, говорит Сахьюн. Команда может прийти к очень сложному решению, но все равно потеряться в деталях. Какие системы изолируются в первую очередь? Кто имеет право их отключать? Что произойдет, если эти системы поддерживают критически важные бизнес-функции? Кто составляет сообщение для заинтересованных сторон и как быстро его можно утвердить?
«Без этих деталей участники на самом деле не проверяют свою готовность; они просто подтверждают, что понимают план действий на концептуальном уровне», — говорит Сахьюн.
Игнорирование взаимосвязанного характера реагирования на инциденты
Апарна Химматрамка согласна с тем, что общие сценарии создают ложную уверенность. Но менеджер по разработке систем безопасности Amazon добавляет, что ложная уверенность также возникает из-за того, что не проверяются на прочность передачи ответственности и взаимозависимости, характерные для вашего бизнеса.
«Ваша команда безопасности уходит с мыслью, что сможет справиться с инцидентом, но на самом деле она ни разу не практиковалась в навигации по конкретным зависимостям, цепочкам связи и системным взаимосвязям, которые будут задействованы во время реального взлома в вашей среде», — говорит она.
Что же происходит, когда случается реальный инцидент? «План реагирования рушится именно в тех точках, которых никогда не касались настольные учения — например, при передаче ответственности между вашей облачной командой и центром оперативного управления безопасностью (SOC), при эскалации, когда скомпрометирована среда интеграции слияний и поглощений (M&A), или при дереве решений, когда точкой входа является сторонний поставщик», — говорит она. «Вы обучили свою команду сценарию, которого не существует в вашей компании».
Химматрамка советует конструировать сценарий на основе вашего реального реестра рисков. «Определите три-пять основных угроз, специфичных для вашей организации, сопоставьте их с вашей реальной архитектурой и структурой команды и постройте учения вокруг них», — говорит она.
Подробнее о настольных учениях:
- Настольные учения: Объяснение, примеры и цели
- Как проводить настольные учения
- 4 настольных учения, которые должна провести каждая команда безопасности
- Сценарии настольных учений: 3 примера из реальной жизни
- 6 советов по проведению эффективных настольных учений
- Симуляции безопасности: Это всего лишь тест
Всегда имейте в виду, что редакции могут придерживаться предвзятых взглядов в освещении новостей.
Автор – John Edwards
