На трёх последних Purple Team активностях в компаниях финансового и промышленного секторов Red Team добирался до домен-контроллера быстрее, чем Blue Team обрабатывал первый критический алерт. Среднее время от фишингового письма (T1566, Initial Access) до захвата AD - четыре часа. Среднее время обнаружения Blue Team - от шести часов до "не обнаружено вовсе". Я видел этот разрыв достаточно раз, чтобы утверждать: он сокращается только у команд, которые проводят киберучения в компании системно - с реалистичными сценариями, чётким распределением ролей и объективным измерением результатов. Остальные тренируются "для галочки" и удивляются, когда реальный инцидент разносит процессы в щепки.
Tabletop, live-fire или BAS: какой формат киберучений выбрать
Прежде чем разрабатывать сценарии киберучений и назначать роли - определитесь с форматом. Три подхода решают разные задачи и требуют разного уровня ресурсов.Tabletop exercise (штабные учения) - обсуждение за столом без живых систем. Фасилитатор зачитывает сценарий, участники проговаривают действия: кому звонить, какой плейбук активировать, кто общается с прессой и регулятором. Tabletop exercise в кибербезопасности тестирует процессы принятия решений, цепочки эскалации и полноту документации. Это единственный формат, который естественно вовлекает топ-менеджмент - руководителям не нужно разбираться в SIEM, чтобы ответить на вопрос "платим ли мы выкуп и кто уведомляет регулятора".
Live-fire exercise (боевые учения на инфраструктуре) - Red Team атакует реальную или виртуализированную инфраструктуру, Blue Team защищается в реальном времени. Это полноценные red team blue team учения, где давление приближено к реальному инциденту. Аналитик парсит алерты в SIEM, пытается отработать плейбук, а атакующие уже перешли к следующему этапу kill chain. Именно live-fire вскрывает разрыв, которого tabletop не покажет: опытные команды замирают, когда SIEM возвращает неожиданные результаты, а плейбуки ломаются, потому что аналитик ни разу не запускал описанные команды руками.
BAS (Breach & Attack Simulation) - автоматизированные платформы прогоняют атомарные техники ATT&CK по расписанию. BAS тестирует технический стек: срабатывают ли правила детекции на конкретные TTP. Но BAS не проверяет, как SOC-команда реагирует на срабатывание. Это инструмент валидации контролей, а не тест готовности людей.
Для команд с минимальным бюджетом, не готовых к коммерческим BAS-решениям, есть бесплатные альтернативы: MITRE Caldera эмулирует adversary profiles по ATT&CK, Atomic Red Team даёт библиотеку атомарных тестов для проверки отдельных техник без выделенной Red Team.
| Критерий | Tabletop | Live-fire | BAS |
|---|---|---|---|
| Тестирует процессы | Да | Да | Нет |
| Тестирует технические навыки | Нет | Да | Нет |
| Участие руководства | Да | Ограниченно (White Team) | Нет |
| Требует Red Team | Нет | Да | Нет |
| Реалистичность давления | Низкая | Высокая | Средняя |
| Стоимость | Низкая (FTE фасилитатора) | Высокая (инфра + Red Team) | Средняя (лицензия платформы) |
| Оптимальная частота | Ежеквартально | 1-2 раза в год | Непрерывно |
| Риск для production | Нулевой | Есть (на живой инфре) | Минимальный |
| Время подготовки | 2-4 недели | 1-2 месяца | Дни (после первичной настройки) |
| Когда использовать | Старт программы, тест коммуникаций, вовлечение бизнеса | Зрелый SOC, проверка под давлением | Непрерывная валидация между учениями |
| Когда НЕ использовать | Если нужно тестировать навыки аналитиков | Если плейбуки ещё не написаны | Если цель - проверить людей, а не инструменты |
Связка для старта программы киберучений: ежеквартальные tabletop + Atomic Red Team или Caldera для автоматизированных проверок детекции между учениями. Live-fire - когда процессы и правила отлажены и пора проверить команду под реальным давлением.
Роли в киберучениях: кто за что отвечает
Деление участников только на "атакующих" и "защитников" - упрощение, которое мешает получить полезные результаты. В зрелых purple team упражнениях задействовано минимум пять групп.
White Team (Control Team). Владеет сценарием, правилами взаимодействия (Rules of Engagement) и стоп-условиями. Решает, когда поставить учения на паузу - если Red Team вышел за scope или возникла угроза для production. Ведёт хронометраж действий обеих сторон: это ключевой артефакт, без которого разбор полётов превращается в спор "мы алерт видели, просто не успели". Роль обычно исполняет руководитель SOC или CISO совместно с внешним фасилитатором.
Red Team. Эмулирует действия реального противника по согласованным TTP. Отличие от пентеста: Red Team действует по сценарию, привязанному к целям учений. Если цель - проверить детект фишинга с эскалацией до AD, Red Team не уходит в эксплуатацию SQLi на периметре. Не потому что не может - а потому что это за рамками scope.
Внутренняя Red Team дешевле и знает инфраструктуру, но знакомство со средой снижает реалистичность. Внешняя - приносит свежий взгляд, но стоит дороже и не знает бизнес-контекста. Оптимальна гибридная модель: внутренняя команда для регулярных учений, внешняя - для ежегодных полномасштабных симуляций.
Blue Team. Работает как при реальном инциденте: SOC-аналитики мониторят алерты, IR-лид принимает решения о containment, threat intelligence подсказывает приоритеты.
Что конкретно тестируется на стороне Blue Team:
- Качество алертов - срабатывают ли правила детекции на действия Red Team
- Mean Time to Detect (MTTD) - время от первого действия атакующего до первой реакции аналитика
- Mean Time to Respond (MTTR) - время от обнаружения до containment
- Работоспособность плейбуков - совпадает ли документация с реальностью (спойлер: обычно нет)
- Цепочки коммуникации - кто кому звонит, по какому каналу, на каком этапе
Наблюдатели (Observers). Фиксируют действия обеих сторон без вмешательства. Скоринг показывает, что команда обнаружила. Наблюдатель фиксирует, как принималось решение - или почему не принималось. На практике данные наблюдателей оказываются ценнее автоматизированных результатов скоринга - именно потому, что фиксируют процесс мышления, а не только итог.
Сценарии киберучений: три готовых шаблона для имитации кибератаки на компанию
Бизнес-логика. Атакующий уже внутри сети (пост-эксплуатация) и перемещается между хостами, используя NTLM-хэши вместо паролей. Цель - критичные серверы: файловые хранилища, базы данных, контроллеры домена.
Предусловия. Работает если: NTLM-аутентификация разрешена, на целевых хостах запущена служба SMB, административные учётные записи переиспользуются между хостами. Не работает если: NTLM отключён в пользу Kerberos-only, включена Credential Guard (Windows 10+), используется LAPS для локальных администраторов.
Формат: Red Team выполняет Pass the Hash с заранее согласованного хоста. Blue Team в реальном времени пытается обнаружить и заблокировать перемещение. Результаты разбираются совместно - это и есть суть purple team подхода.
Детекция в SIEM. В SigmaHQ есть готовые правила. Ключевое -
win_security_pass_the_hash_2.yml, которое ловит EventID 4624 (Logon Type 9 - NewCredentials) с NTLM-аутентификацией:
YAML:
# Sigma: Pass the Hash Activity (упрощённый)
# Источник: SigmaHQ, win_security_pass_the_hash_2.yml
title: Pass the Hash Activity 2
logsource:
product: windows
service: security
detection:
selection:
EventID: 4624
LogonType: 9
AuthenticationPackageName: 'Negotiate'
condition: selection
level: mediumwin_susp_ntlm_auth.yml для мониторинга NTLM-аутентификации с нетипичных источников и win_system_lsasrv_ntlmv1.yml для обнаружения NTLMv1. NTLMv1 - индикатор слабой аутентификации (отдельная угроза downgrade-атаки на NTLM), который дополняет, но не заменяет специфичные PtH-индикаторы.Контрмера по D3FEND: Process Lineage Analysis (D3-PLA) - отслеживание подозрительных цепочек порождения процессов при PTH, когда
cmd.exe или powershell.exe запускаются в контексте, не соответствующем легитимному пользователю.Имитация шифровальщика с деструкцией бэкапов
Бизнес-логика. Шифровальщик - финальный этап многодневной атаки. К моменту развёртывания ransomware атакующий уже контролирует AD, скомпрометировал бэкап-серверы и выгрузил данные. Цель учений - проверить способность организации восстановиться и скорость кризисных коммуникаций.Предусловия. Работает если: бэкапы не изолированы от домена, отсутствует immutable storage, плейбук реагирования и план восстановления не тестировались под давлением. Не работает если: бэкапы на air-gapped storage, реализована стратегия 3-2-1 с immutable копиями, существует отработанный DR-план.
Таймлайн:
- White Team сообщает Blue Team о "подозрительной активности в сети" без деталей. Имитируется начало инцидента.
- Red Team начинает "шифрование" - переименование тестовых файлов на нескольких серверах с записью маркеров вместо реального шифрования.
- Одновременно Red Team "удаляет" снапшоты и бэкапы в тестовой среде.
- Blue Team должна: обнаружить шифрование, изолировать поражённые сегменты, оценить ущерб, инициировать восстановление, активировать коммуникационный план.
Как организовать киберучения: план по этапам
Определение целей и scope (за 4-8 недель)
Начинайте не со сценария, а с вопроса: какую проблему решаем?- Проверить работоспособность плейбука по ransomware (процессная цель)
- Измерить MTTD для конкретных техник ATT&CK (техническая цель)
- Протестировать коммуникации между SOC, IT, юристами и PR (организационная цель)
- Обосновать бюджет на EDR перед руководством (политическая цель - и она не менее важна, чем остальные)
Разработка сценария и подготовка среды (за 2-4 недели)
Сценарий должен быть реалистичным, релевантным для отрасли и гибким. Линейный "шаг 1, шаг 2, шаг 3" ломается при первом отклонении. Если Blue Team обнаружила атаку раньше плана - у Red Team должен быть альтернативный вектор, а не досрочное завершение учений с пометкой молодцы.Привязывайте каждый этап к технике MITRE ATT&CK. Это не формальность - карта покрытия ATT&CK после учений станет главным артефактом для обоснования бюджетных решений.
Требования к окружению для live-fire учений:
- Минимум 2 виртуальных хоста на команду (рабочая станция Windows 10+ и сервер)
- Контроллер домена (Windows Server 2016+)
- SIEM с настроенным сбором Windows Security Event Log: EventID 4624, 4625, 4648, 4672 как минимум
- Изолированный сетевой сегмент (VLAN или отдельная подсеть, не production)
- Канал связи, не зависящий от тестируемой инфраструктуры: отдельный мессенджер или телефонная связь
T1550.002 без выделенной Red Team, проверяя срабатывание Sigma-правил.Брифинг, проведение и разбор полётов
Red Team получает полный сценарий и Rules of Engagement. Blue Team - минимальный контекст: "в ближайшие N часов может произойти инцидент, действуйте по стандартным процедурам". Чем меньше Blue Team знает заранее - тем реалистичнее результаты.Во время учений White Team ведёт таймлайн - журнал всех действий обеих сторон с точным временем. Без него AAR превращается в пересказ по памяти, где каждая сторона помнит свою версию.
After Action Review (проводится в течение 24-48 часов):
- Red Team демонстрирует свой таймлайн с привязкой к техникам ATT&CK
- Blue Team показывает свой: что видели, как реагировали, где застряли
- Совместный разбор расхождений: что прошло незамеченным, какие алерты сработали, но были проигнорированы
- Формирование списка remediation с конкретными владельцами, сроками и критериями закрытия
Критерии оценки Blue Team: метрики эффективности реагирования
Субъективное "команда справилась нормально" - не результат. Нужны измеримые критерии оценки Blue Team, сравнимые между учениями.MTTD (Mean Time to Detect). Время от действия атакующего до начала расследования аналитиком. Не момент алерта в SIEM (это автоматика), а момент, когда человек начал разбираться. Типичные значения для зрелых SOC - 4-24 часа. Для остальных - дни. Иногда - никогда.
MTTR (Mean Time to Respond). Время от начала расследования до containment: подтверждение инцидента, определение scope, изоляция хостов. По данным CrowdStrike, ориентир - формула "1-10-60": обнаружение за 1 минуту, оценка за 10, containment за 60. Для большинства SOC это целевой показатель, а не текущий. Если ваш SOC укладывается - я хочу познакомиться с вашим руководителем.
Покрытие MITRE ATT&CK. Каждой технике из сценария присваивается статус: Detected, Missed, Partially Detected (алерт сработал, но не был обработан). Результат визуализируется как heat map на матрице ATT&CK. По опыту организаторов многокомандных учений, этот артефакт влияет на решения о закупке средств защиты сильнее любого отчёта о рисках.
Скоринговая модель для live-fire учений. Если участвуют несколько Blue Team - балльная система по категориям:
- N баллов за каждую выявленную технику ATT&CK (обнаружение)
- Баллы за скорость изоляции с градацией по времени (containment)
- Штрафные баллы за необоснованное отключение сервисов - чтобы команда не решила "всё выключим, зато безопасно" (availability)
- Баллы за качество и скорость эскалации (отчётность)
Ошибки, которые обесценивают результаты red team blue team учений
Blue Team знает дату и время начала. Если команда заранее усилила мониторинг и посадила на консоль лучших аналитиков - учения тестируют пиковую готовность, а не повседневную. Реальный атакующий расписание не присылает.Сценарий без развилок. Линейный сценарий разваливается при первом отклонении. Blue Team обнаружила атаку раньше плана, а у Red Team нет альтернативного маршрута - учения заканчиваются досрочно без полезного результата. Пустая трата времени и бюджета.
Отсутствие таймлайна. Без хронометража действий обеих сторон AAR превращается в спор. Журнал White Team - единственный источник правды.
Учения на production без стоп-условий. Red Team случайно положил сервис - и учения перетекли в реальный инцидент. Перед началом: чёткие критерии остановки, кодовое слово, ответственный за решение (White Team lead). Без этого - играете с огнём.
Remediation без владельцев. Список проблем, который "ляжет на стол CISO", не работает. Каждый пункт - конкретный владелец, срок, критерий закрытия. Иначе те же gaps всплывут на следующих учениях. И на следующих после них.
Подмена формата. Пентест - не киберучения. BAS-платформа - не киберучения. Оба инструмента полезны, но тестируют технический стек, а не готовность людей и процессов. Если цель - проверить, как SOC работает под давлением, - нужны live-fire учения с живым противником.
Большинство компаний, с которыми я работал, проводят киберучения раз в год - к аудиту или после громкого инцидента у конкурента. По документам всё по процессу: сценарий написан, роли распределены, отчёт подготовлен. На практике - через месяц ни один пункт remediation не закрыт, плейбуки не обновлены, а новые аналитики в SOC даже не знают, что учения проводились. Я убеждён: разовые учения хуже полного отсутствия, потому что создают иллюзию готовности, которая рассыпается при первом реальном инциденте. Настоящая ценность - в системном подходе: ежеквартальные tabletop с ротацией сценариев, ежемесячные прогоны Atomic Red Team по конкретным техникам ATT&CK, и хотя бы одни live-fire в год с внешней Red Team. Причём после каждого раунда - измеримый прогресс: MTTD сократился с 6 до 2 часов, покрытие ATT&CK выросло с 40% до 65%, время восстановления из бэкапов уменьшилось втрое. Без цифр - это не киберучения, а театр безопасности. Если интересно, как другие SOC-команды строят скоринг и разбирают After Action Review, - на форуме codeby есть тред по threat hunting, где обсуждают именно такие форматы.
Последнее редактирование модератором:
