Публикация MITRE «11 стратегий SOC-центра мирового уровня». Стратегия №11 «Повышайте эффективность путем расширения функционала SOC»

Руслан Рахметов, Security Vision 

Злоумышленники непрерывно совершенствуют свои TTPs, скрывают свою присутствие и разрабатывают новые инструменты, и для эффективного мониторинга и реагирования на киберинциденты SOC-центры должны непрерывно совершенствоваться. Базовые функции по выявлению кибератак, реагированию, аналитике киберугроз могут быть в некоторых случаях недостаточны, поэтому SOC-центр может принять решение о расширении своего функционала, который будет соответствовать актуальным киберугрозам и потребностям заказчика. Таким расширенным функционалом может быть проактивный поиск киберугроз (англ. threat hunting), проведение тестирований Red/Purple Team, использование платформ эмуляции кибератак (BAS-системы) и Deception-решений («ловушки»), использование форензики, проведение штабных киберучений. 

1. Поиск киберугроз (Threat Hunting)

Проактивный поиск киберугроз является одной из главных дополнительных функций SOC, которую можно начать развивать, достигнув зрелости в процессах реагирования на инциденты и в аналитике киберугроз (Cyber Threat Intelligence). Поиск киберугроз фокусируется на поиске новых или ранее невыявленных атакующих, которые уже скрытно присутствуют в инфраструктуре. Иными словами, поиск киберугроз - это проактивный поиск вредоносных или подозрительных действий в сетях, системах, данных, которые не удалось выявить существующими стандартными ИБ-инструментами и способами. При поиске киберугроз аналитики руководствуются принципом "Assumed Breach", который означает буквально: «Считайте, что вас уже взломали». Это подразумевает создание и проверку определенных гипотез о действиях атакующих, которые уже могли ранее незаметно проникнуть в инфраструктуру, на основании опыта аналитиков и известных TTPs киберпреступников, в том числе с применением форензики. Для работы аналитикам по поиску киберугроз потребуется работать с ИБ-данными, которые обрабатывает SOC-центр, контролировать сработки СЗИ и обрабатываемые инциденты ИБ, работать с аналитикой киберугроз, а также понимать контекст и бизнес-процессы заказчика и знать, что является отклонением от штатной работы инфраструктуры и нормальных бизнес-операций.

Для эффективной реализации функции поиска киберугроз SOC-центр должен обладать определенным уровнем зрелости: корректно и оперативно обрабатывать киберинциденты, получать полные и точные данные от сетевых и хостовых устройств, «видеть» всю инфраструктуру. Причинами, по которым SOC-центр может решить начать вести поиск киберугроз, могут быть недостаточность имеющихся средств и способов выявления атак, данные киберразведки об интересе киберпреступников к компании-заказчику, необходимость расширить текущие процедуры реагирования с помощью дополнительной аналитики. Целесообразность инвестиций в поиск киберугроз можно оценить с точки зрения затрат на возможное восстановление «с нуля» всей инфраструктуры компании, если атакующие глубоко закрепились в ней и не были выявлены на более ранних этапах. При этом нужно осознавать, что поиск киберугроз не должен быть бесконечным блужданием по ИБ-данным в надежде обнаружить что-то важное: должны быть обозначены конкретные цели, определена гипотеза, а также разработан план выполнения, включающий в себя подготовку, выполнение, завершение операции по поиску киберугрозы. Кроме того, поиск киберугроз может только дополнить, но не заменить обычное реагирование на киберинцидент. 

1.1. Подготовка к поиску киберугроз:

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

При подготовке к проведению операций по поиску киберугроз следует:

- Разработать гипотезу поиска киберугроз на основе идей и обратной связи от членов команды SOC, используя матрицу MITRE ATT&CK и составляя предположения о целях, TTPs и возможных действиях атакующих;

- Распланировать и приоритизировать активности в зависимости от вероятности реализации киберугроз и задач SOC;

- Определить доступные ресурсы, включая сотрудников, системы, инструменты, а также рассмотреть возможное привлечение партнеров. 

1.2. Выполнение операций по поиску киберугроз:

Каждая операция по поиску киберугроз должна быть структурирована примерно следующим образом:

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

- Получить доступ к данным и собрать необходимую информацию;

- Провести анализ собранной информации, выполнив несколько итераций, записывая полученные результаты в структурированном формате, пригодном для совместной работы;

- Запланировать и проводить периодический анализ данных для обеспечения непрерывного поиска киберугроз с помощью доступного инструментария SOC-центра (например, в SIEM, SOAR, платформе обработки Big Data);

- Произвести реагирование на выявленную киберугрозу или передать данный кейс команде реагирования;

- Регулярно сообщать результаты операций руководителям SOC-центра и синхронизировать действия между собой (внутри команды аналитиков по поиску киберугроз). 

Авторы публикации приводят несколько рекомендаций для успешного выполнения операций по поиску киберугроз:

- Сфокусируйтесь на определенной гипотезе;

- Будьте любопытными и любознательными, обращайте внимание на мелочи;

- Инвестируйте в людей, выделяйте им ресурсы и время на поиск киберугроз;

- Старайтесь воспринимать каждую новую операцию по поиску киберугроз «с чистого листа», не полагаясь только лишь на предыдущий опыт;

- Выстраивайте доверительные отношения с работниками компании-заказчика для получения от них информации и знайте, что является нехарактерным в поведении систем и бизнес-процессов;

- Разрабатывайте гипотезы и сценарии вероятных атак с учетом ранее происходивших инцидентов, данных киберразведки, TTPs из матрицы MITRE ATT&CK, предупреждений и трендов SOC-центра, информации из внешних источников (блоги, социальные сети), а также на основании предположений о потенциальном интересе злоумышленников к определенным активам и данным компании. 

1.3. Завершение операций по поиску киберугроз (пост-поисковые действия, англ. Post-Hunt Activities):

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

2. Red Team тестирования

Еще одним способом проактивного тестирования и улучшения мер защиты в SOC является проведение Red Team тестирований, которые представляют из себя выполнение действий, характерных для атакующих, с использованием соответствующих TTPs, которые применяются в реальных кибератаках, для проверки корректности и эффективности реагирования персонала, процессов, технологий SOC. Отличие Red Team тестирований от тестирований на проникновение в том, что пен-тесты проводятся в отношении какой-либо технологии с применением определенного шаблона, а Red Team тестирования, как правило, более комплексные и ресурсоемкие, поскольку они могут включать в себя отработку нескольких сценариев атак и разные векторы (включая социальную инженерию и проникновение на территорию компании-заказчика). Кроме того, зачастую SOC-центры не оповещаются о проведении Red Team тестирований для соблюдения «чистоты эксперимента», а сами тестирования подразумевают имитацию действий атакующих (включая TTPs APT-группировок) и реальной кибератаки для проверки выявления, анализа, реагирования на неё.

Преимущества проведения Red Team тестирований следующие:

- Повышение качества защиты и мониторинга в результате тестирований, и, как следствие, повышение затрат реальных атакующих на преодоление улучшившейся защиты;

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

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

- Выявление и демонстрация недостатков в обеспечении кибербезопасности. 

При проведении Red Team тестирований можно либо привлекать экспертов SOC-центра, либо воспользоваться услугами сторонней компании. Оба варианта имеют свои преимущества: члены команды SOC-центра смогут по-новому взглянуть на защищаемую инфраструктуру и СЗИ, которые постараются обойти, эмулируя действия продвинутого атакующего, а сотрудники сторонней компании не будут иметь знаний об инфраструктуре и смогут пойти нестандартным путем при проведении тестовой кибератаки. 

В обоих вариантах, важно будет учесть следующее:

- Планирование: выделение ресурсов и времени на проведение Red Team тестирований с учетом возможностей Red Team и SOC-центра, а также с учетом оценки риска причинения реального ущерба инфраструктуре компании в результате тестирования;

- Устранение конфликтов: определение способа отнесения события к настоящему инциденту или к действиям Red Team;

- Эскалация: определение того, как и когда Red Team-инцидент может быть эскалирован на руководителей для управления и выделения ресурсов;

- Выделение ресурсов: выделение достаточных ресурсов для Red Team и для SOC-центра и определение соотношения между ними. 

Для повышения эффективности проведения Red Team тестирований, авторы публикации приводят следующие советы:

- Определите доверенное лицо, которое будет знать о проведении Red Team тестирования: это может быть руководитель SOC-центра или директор по ИТ, который сможет остановить тестирование в случае нанесения ущерба компании или при необходимости перенаправить ресурсы SOC-центра на реагирование на реальный инцидент;

- Выбирайте реалистичные сценарии тестовых кибератак, учитывая бизнес-процессы и инфраструктуру компании-заказчика, а также ранее случавшиеся реальные кибератаки;

- При развитии функционала Red Team тестирований, начинайте с простых сценариев, постепенно переходя к более сложным;

- Определяйте заранее границы и критерии успеха тестирования, не допускайте размытия границ проекта тестирования, старайтесь формулировать критерии успеха тестирования так, чтобы для демонстрации результата не требовалось выполнять деструктивных действий и наносить реальный ущерб;

- После проведения Red Team тестирования следует устранить его последствия (откатить изменения, удалить артефакты и установленное Red Team-командой ПО и т.д.);

- Выделяйте время на анализ выученных уроков, полученных в результате тестирования, делайте выводы, улучшайте меры защиты. 

3. Purple Team тестирования

При проведении тестирований защищенности компании-заказчика команда Red Team выступает в роли «нападающих», выполняя действия, характерные для TTPs атакующих, а команда Blue Team «защищается», стремясь выявить и предотвратить атаку Red Team. При этом в случае совместной работы членов команд Red Team и Blue Team такое тестирование называется Purple Team, при котором одновременно проводятся мероприятия и по нападению, и по защите, а в результате такой коллаборации и защитники, и нападающие вместе учатся и повышают свои навыки.

Задачей Purple Team тестирования является улучшение защиты компании-заказчика от действий атакующих, включая повышение качества выявления, реагирования, предотвращения киберугроз с помощью обработки обратной связи об эффективности сценариев реагирования и конфигураций средств защиты. При этом следует руководствоваться подходом, обеспечивающим непрерывное проведение Purple Team тестирований, постоянное взаимодействие и обработку обратной связи. В отличие от Red Team, при проведении Purple Team тестирований осуществляется непрерывное взаимодействие членов команд атакующих и защитников (Red и Blue Team), в рамках которого Blue Team точно знает, что, где и как выполняет команда Red Team. При этом авторы публикации рекомендуют при каждом тестировании проверять только один или несколько наборов TTPs атакующих для более точной оценки корректности защитных мер и их донастройки. 

Команды Purple Team могут работать следующим образом:

- Тестирование Red Team одной системы или некоторого сегмента инфраструктуры под наблюдением членов Blue Team для оценки эффективности мер защиты (инструментов, сенсоров, аналитики);

- Члены Blue Team в интерактивном режиме наблюдают за каждым действием, выполняемым членами команды Red Team;

- Открытое проведение оценки наличия уязвимостей и эмуляция действий атакующих, при которых Red Team останавливается на каждом этапе тестирования, а Blue Team анализирует выполненные действия;

- Тестирование систем, находящихся в промышленной эксплуатации, с эмуляцией действий определенной киберпреступной группировки;

- Использование платформ эмуляции кибератак для совместной работы Red Team и Blue Team. 

4. Платформы эмуляции кибератак

Проведение пен-тестов, тестирований Purple Team и Red Team, оценок уязвимостей достаточно ресурсозатратно, при этом многие TTPs атакующих бывает сложно точно воспроизвести. Для проведения регулярных автоматизированных оценок защищенности компании можно использовать решения класса BAS (англ. Breach and Attack Simulation, платформы эмуляции кибератак), обеспечивающие повторяемый, измеримый, масштабируемый процесс тестирования корректности работы мер защиты. Выполнение BAS-тестирований производится в отношении определенных хостов, сетей, систем компании, при этом BAS-платформы должны поддерживать тестирование различных TTPs атакующих в соответствии с матрицей MITRE ATT&CK. Причинами внедрения платформ эмуляции кибератак могут быть отсутствие или недостаточное ресурсное обеспечение Red Team, потребность в автоматизации действий по проведению регулярных тестирований действий атакующих, необходимость оценки охвата матрицы MITRE ATT&CK текущими силами и средствами SOC-центра, необходимость оценки эффективности реализации мер защиты вне SOC (например, ИБ-департаментом). 

Платформы эмуляции кибератак могут обладать следующими характеристиками:

- Охват TTPs атакующих в BAS-системе, например, на основе охвата матрицы MITRE ATT&CK;

- Релевантность, функционал тестирования, частота обновлений: TTPs, заложенные в BAS-решении, должны регулярно обновляться, соответствовать типам активов и систем, которые используются в компании, а сами BAS-платформы должны обладать функционалом тестирования различных типов систем (базы данных, веб-сервера, приложения, облачные сервисы и т.д.);

- Предустановленные сценарии тестирования: BAS-решения должны позволять объединять различные вектора атак и TTPs для более полной проверки, а также позволять эмулировать действия конкретных релевантных APT-групп;

- Прозрачность работы и расширяемость: BAS-решения должны предоставлять полную информацию о выполняемых действиях и применяемых TTPs при эмуляции атак, эти TTPs должны быть кастомизируемыми и должны соответствовать потребностям SOC (например, эмулировать только отдельные действия атакующих или всю цепочки атаки полностью);

- Снижение рисков: должно быть предусмотрено логирование выполняемых BAS-платформой действий, "откат" всех внесенных в рамках атаки изменений в инфраструктуре (например, восстановление настроек систем, учетных записей в исходное состояние), возможность экстренной мгновенной остановки BAS-тестирования, а также должна быть обеспечена надежная защита самой BAS-платформы. 

Авторы публикации приводят следующие рекомендации для успешного внедрения BAS-решения:

- Совместное использование BAS-платформы SOC-центром, командами Red / Blue Team, пен-тестерами;

- Постепенное начало эксплуатации: следует начинать применять BAS-решение с небольшого количества некритичных активов в тестовой среде для проверки надежности и безопасности работы решения;

- Обеспечение безопасности тестирования: следует разработать и утвердить правила проведения и завершения BAS-тестирований, а также порядок обработки нештатных ситуаций;

- Обеспечение релевантности тестовых атак инфраструктуре и актуальным для компании-заказчика киберугрозам: следует выбрать реалистичные сценарии тестирования, подходящие для компании-заказчика, которые обеспечивают проверку реально используемых мер защиты;

- Выбирайте тестовые устройства для проверки средств выявления и предотвращения на них: BAS-решения могут помочь командам SOC-центра, Red Team, Purple Team в настройке средств защиты для реагирования на тестовые атаки, проведенные с помощью BAS;

- Оценивайте применимость полученных результатов ко всей инфраструктуре: проведя BAS-тестирование на ограниченном наборе устройств, следует сделать обоснованные выводы о том, репрезентативны ли данные результаты для всех устройств в инфраструктуре компании-заказчика;

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

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

- BAS-платформы не заменяют членов команд Red Team: некоторые проверки могут быть выполнены только вручную, а BAS-решения лишь автоматизируют определенные действия, не замещая экспертизу сотрудников. 

5. Deception-решения («ловушки»)

Deception-решения («ловушки») применяются для сокрытия реальных объектов инфраструктуры компании, запутывания атакующих и направления их «по ложному следу». Кроме того, можно использовать Deception-платформы для проактивного поиска киберугроз, заманивая атакующих в контролируемую среду и позволяя им «украсть» поддельные данные (приманки), движение которых можно будет затем отследить: например, позволив атакующим «украсть» специально созданные тестовые учетные данные, можно будет затем отследить попытки их применения или публикации и сделать соответствующие выводы. Таким образом, Deception-платформы могут дополнять другие методы обнаружения атак (сигнатурные и на основании выявления аномалий) и предоставлять SOC-центрам ценную информацию для выявления скрытой вредоносной активности. Deception-решения позволяют автоматизированно «раскидать» приманки по инфраструктуре компании, анализировать действия, выполняемые атакующими, контролировать их перемещение между приманками. В отличие от классических Honeypot/Honeynet-технологий, Deception-системы позволяют автоматизировать создание и контроль приманок, направлять по ложному следу атакующих, обеспечивать проактивный поиск и анализ киберугроз. 

Приманки могут представлять их себя:

- Поддельные учетные записи, документы, файловые «шары», размещенные на определенном устройстве;

- Поддельные системы, сервисы, серверы, которые на первый взгляд неотличимы от настоящих, но оснащены технологиями «песочниц» для контроля и анализа действий атакующих;

- Поддельные объекты Active Directory, которые могут заинтересовать атакующих;

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

Авторы публикации подчеркивают, что внедрение Deception-решения может быть оправдано только для зрелых SOC-центров, которые осознают связанные с такими системами риски и сложности: от необходимости настройки Deception-инфраструктуры до возможности захвата Deception-инфраструктуры атакующими и использования ее в качестве плацдарма для дальнейших атак на компанию. Перед внедрением Deception-платформы следует убедиться в общей зрелости и готовности SOC-центра к разумному использованию Deception-решения, выделить соответствующие ресурсы, разработать правила работы с обнаруженными атаками (например, порядок принятия решений о дальнейшем мониторинге действий атакующих или блокировании их действий), а также согласовать внедрение и использование платформы с юридическим блоком и руководителями компании. 

Для успешного внедрения и эксплуатации Deception-платформы следует:

- Четко определить конечные цели применения решения, например, воспользовавшись фреймворком MITRE Engage;

- Выбрать подходящее Deception-решение: авторы публикации рекомендуют использовать коммерческие продукты в целях упрощения создания Deception-инфраструктуры и "приманок", особенно если SOC-центр только начала вести работу в Deception-направлении;

- Стараться воспроизводить близкие к реальным элементы инфраструктуры в рамках Deception-проекта: «приманки» и Deception-объекты должны меняться со временем и создавать видимость работы пользователей с ними, как если бы они были настоящими;

- Обеспечивать контроль и мониторинг созданной Deception-инфраструктуры для предотвращения «побега» атакующих из контролируемой среды. 

6. Анализ ВПО

В своей работе SOC-центры регулярно сталкиваются с подозрительными файлами, которые требуется проанализировать для понимания возможных вредоносных действий и последствий. С ростом зрелости SOC-центра функционал локальных и облачных антивирусов становится недостаточным, поэтому появляется потребность в развитии внутренней функции по анализу ВПО. 

Целями анализа ВПО могут быть:

- Исследование образцов ВПО для понимания вектора атаки и вероятных целей, что может привести аналитиков к уже известным семействам ВПО или киберпреступным группам;

- Исследование функционала ВПО и его поведения, включая методы закрепления и обеспечения скрытности, а также способы связи с командным центром атакующих (сервером "Command and Control", сокращенно C&C или C2-сервером);

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

Анализ ВПО, проводимый силами SOC-центра, повышает вероятность выявления и противодействия атакующим, поскольку результаты анализа специфичны для компании-заказчика. Кроме того, SOC-центр, обладающий хорошими компетенциями по анализу ВПО, может оказывать неоценимую помощь ИБ-сообществу и предоставлять более качественные услуги по расследованию киберинцидентов. 

Глубокий анализ ВПО собственными силами поможет SOC-центру понять следующее:

- Было ли ВПО специально создано для целевой атаки на компанию-заказчика, или это был широко распространенный вирус, использовавшийся против разных целей;

- Осуществляет ли ВПО взаимодействие с C2-сервером атакующих, и если да, то каким образом;

- Какие реквизиты доступа (пароли, сертификаты, ключи) "зашиты" в ВПО, где они используются;

- Написано ли ВПО «с нуля» или использовалась кодовая база уже известного образца ВПО, которое уже ранее где-либо встречалось и уже анализировалось;

- Что именно выполняет ВПО: подгружает ли ВПО дополнительные модули, записывает ли нажатия клавиш пользователем, какие действия выполняет на зараженном устройстве;

- Каковы мотивы атакующих - авторов ВПО, каковы их ресурсы и возможности. 

Для успешной реализации внутренней функции SOC-центра по анализу ВПО, авторы публикации рекомендуют следующее:

- Оцените потребность SOC-центра во внутреннем анализе ВПО, оцените, насколько часто SOC сталкивается с неизвестными и сложными образцами ВПО;

- Оцените уровень возврата инвестиций во внутреннюю функцию анализа ВПО, являющуюся достаточно ресурсоемкой для SOC-центра;

- Наладьте взаимодействие вирусных аналитиков с членами команды реагирования на инциденты, с аналитиками киберугроз и аналитиками Threat Hunting в SOC-центре, а также с другими SOC-центрами и ИБ-сообществом;

- Поддерживайте инициативы по публикации аналитиками статей о результатах исследования ВПО - это поможет не только повысить репутацию SOC-центра среди сообщества и клиентов, но и удержать персонал и привлечь новые таланты;

- Создайте выделенную инфраструктуру для анализа ВПО, обеспечьте ее защиту, а также предоставьте вирусным аналитикам свободу в выборе инструментов и способов анализа;

- Задокументируйте полномочия, общие процедуры и правила анализа ВПО в SOC-центре. 

7. Форензика

Применение форензики (компьютерной криминалистики) в SOC-центре может быть востребовано для проведения расследований киберинцидентов, а также для привлечения нарушителей к ответственности по нормам законодательства. В случае серьезного инцидента следует привлечь юридический отдел для определения необходимости сбора юридически значимых доказательств с использованием строго определенных методов и инструментов. Форензика может производиться с оперативной памятью, жестким диском (анализ операционной системы и файлов), сетевым трафиком, мобильными устройствами, облачными хранилищами, а также данными различного формата. 

Факторами успеха в создании внутренней функции компьютерных криминалистических исследований в SOC-центре, по мнению авторов публикации, являются:

- Оцените цели проведения форензики: будет ли форензика использоваться только для поддержки расследования киберинцидентов внутри SOC-центра или рассматриваются варианты использования собираемых данных в суде;

- Получите необходимые полномочия для проведения форензик-анализа, задокументируйте процессы проведения форензик-анализа;

- Учтите, что исследуемые данные могут содержать нелегальный или травмирующий контент, поэтому минимизируйте возможное негативное влияние полученной информации на аналитика;

- Учтите, что форензика - это нишевый раздел ИБ-экспертизы, поэтому не допускайте формирования точки отказа в виде одного-единственного форензик-аналитика в SOC-центре;

- Приготовьтесь к резкому росту нагрузки на форензик-функцию в случае крупного инцидента: назначьте ответственного за приоритизацию и контроль форензик-анализа, установите разумные границы окончания проведения форензик-анализа, наладьте взаимодействие со сторонними партнерами (MSS-провайдером, другим SOC-центром, интегратором) для возможности быстрого их привлечения. 

8. Проведение штабных киберучений

В условиях ограниченных временных и человеческих ресурсов для проверки готовности к реагированию на киберинциденты можно проводить штабные киберучения (англ. tabletop exercises), на которых присутствующие ответственные члены ИБ-команды пошагово проходят по документам (политикам, сценариям, процедурам реагирования) и проверяют понимание своих действий и готовность к их выполнению. Во время проведения штабных киберучений не проводится полный технический анализ тестового инцидента, проводится умозрительная оценка готовности членов команды к выполнению своих действий (например, к поиску контактов ответственных, к использованию инструментов и средств защиты). 

Проведение штабных киберучений будет полезным для достижения следующих целей:

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

- Повышение и актуализация знаний ответственных лиц о своих ролях и обязанностях;

- Выявление недостатков в процессах реагирования и ресурсном обеспечении (сотрудники, информация, инструменты);

- Выявление возможных сложностей, которые могут возникнуть у участников при реагировании на реальные инциденты. 

Для успешного проведения штабных киберучений следует разработать реалистичные сценарии тестовых кибератак, заранее подготовить план проведения учений, пригласить всех вовлеченных в процесс реагирования сотрудников, а также сделать процесс киберучений интересным и максимально приближенным к боевому реагированию. Проведение штабных киберучений полезно тем, что такие упражнения позволяют всем участникам процесса реагирования, даже тем, кто не погружен в ИБ глубоко (например, юристы, PR, руководители), проверить свои знания и повысить уровень готовности к выполнению действий в случае реальной кибератаки. 

Кроме того, авторы приводят следующие рекомендации для успешного проведения штабных киберучений:

- Следует выбрать ответственного за организацию штабных киберучений (выбор сценариев, приглашенных лиц, выбор места и времени, логистика);

- Следует выбрать ответственного за проведение штабных киберучений (взаимодействие со всеми участниками, запуск сценариев, модерация);

- Давайте участникам штабных киберучений новые вводные по ходу проведения занятия для большей динамичности сценария;

- Определите объем и границы штабных киберучений в зависимости от аудитории, которая будет на них присутствовать, а также контролируйте действия, выполняемые участниками;

- Следует вести протокол и документировать выявленные недостатки и вопросы;

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