За два года - 18 purple team операций в финтехе, телекоме и промышленности. Результат, который повторяется раз за разом: в двух третях кейсов основная причина пропущенных детектов - не слабые правила в SIEM и не отсутствие EDR, а банальный разрыв коммуникации между атакующей и защитной командами. Red Team отработал технику, Blue Team не увидел - и обе стороны узнали об этом из PDF-отчёта через три недели, когда контекст атаки давно улетучился. Знакомо? Вот про конкретный протокол координации, который превращает каждую выполненную технику в новый детект за часы, а не за месяцы.
Бизнес-логика purple team операции
Классический пентест заканчивается отчётом. Red Team нашёл 15 уязвимостей, описал в PDF, передал заказчику. Blue Team получил этот документ через неделю, потратил ещё две на приоритизацию, месяц на устранение. За это время критический контекст - как именно атакующие обходили детект, какие артефакты оставляли в логах, на каком этапе kill chain SOC ослеп - уже потерян. Отчёт отвечает на вопрос «что сломано», но не на вопрос «почему мы это не увидели». А второй вопрос - дороже.Purple team операция ломает эту модель. По подходу Cymulate, суть - сокращение цикла от обнаружения gap'а до его закрытия с недель до часов. Red Team выполняет конкретную технику из MITRE ATT&CK, Blue Team в реальном времени проверяет, сработал ли алерт, а фасилитатор (purple team lead) фиксирует результат и координирует немедленную доработку детекта.
Бизнес-результат измерим: после каждого цикла растёт покрытие detection coverage map - карта, показывающая, какие техники ATT&CK организация обнаруживает, а какие остаются в слепой зоне. Это не абстрактный «отчёт о зрелости», а артефакт, по которому CISO принимает решения о бюджете на detection engineering и на котором строится диалог с регулятором.
И тут сразу оговорка: purple team - это не третья независимая команда, как часто пишут в обзорных материалах. По данным Praetorian, это модель сотрудничества (collaboration model) между существующими Red и Blue Team. Иногда формализованная в виде выделенной роли, чаще - в виде методологии периодических совместных упражнений. Не надо нанимать ещё десять человек.
Три модели purple teaming по зрелости организации
Не каждая компания готова к непрерывному purple teaming. Выбор модели зависит от зрелости SOC, наличия штатных offensive-специалистов и бюджета на detection engineering. Координация red team и blue team может быть организована тремя способами - и выбор между ними определяет, получите вы реальный процесс или дорогой тренинг.Ad-hoc: ретроспективный разбор после пентеста
Самый простой формат purple team взаимодействия. Red Team проводит стандартный engagement, после завершения - совместная сессия с Blue Team: таймлайн атаки, использованные техники, артефакты. Blue Team сопоставляет с логами SIEM и определяет, что обнаружено, а что пропущено.Предусловия и ограничения: формат работает только при полном лог-покрытии за период пентеста. Если логирование не настроено на нужные источники - Sysmon events, PowerShell ScriptBlock Logging, network flow - ретроспективный анализ невозможен. Типичная ситуация на таких сессиях: Red Team объясняет lateral movement, Blue Team открывает SIEM и видит пустоту, потому что нужные события просто не собирались. В этом случае первый результат ad-hoc сессии - не «какие техники мы пропустили», а «какие источники логов нам вообще нужны». И это тоже результат - только обидный.
Подходит организациям без выделенного SOC или с SOC на ранней стадии зрелости. Компаниям, которые привлекают внешних пентестеров и хотят получить от engagement больше, чем PDF.
Структурированные упражнения по MITRE ATT&CK
Целевой формат для организаций с работающим SOC. Команды заранее выбирают набор техник из матрицы ATT&CK, Red Team последовательно выполняет каждую, Blue Team в реальном времени пытается обнаружить. Результат каждой итерации фиксируется: обнаружено, не обнаружено, обнаружено частично (алерт был, но аналитик не эскалировал).По данным IANS Research, оптимальная длительность - несколько недель на подготовку (цели, scope, выбор техник), несколько дней на симуляции, ещё неделя на remediation и retest.
Предусловия: изолированная среда или чёткие правила engagement в production, согласованные с IT-операциями. Фреймворки автоматизации атак - CALDERA или Atomic Red Team - без них ручное воспроизведение каждой техники занимает непропорционально много времени. Минимум L2-аналитик в SOC, способный интерпретировать результаты в реальном времени.
Подходит средним и крупным организациям с SOC, EDR и SIEM. Финансовый сектор, телеком, критическая инфраструктура.
Continuous purple teaming
Зрелая модель, к которой стремятся организации с выделенной purple team практикой. Операции встроены в операционный ритм: появился свежий threat intelligence (новая APT-кампания, свежий TTP в публичных отчётах) - Red Team немедленно эмулирует технику, Blue Team проверяет детект. Цикл повторяется непрерывно, а не раз в квартал.Предусловия: штатный purple team lead или выделенный фасилитатор, зрелый SOC с L2/L3 аналитиками, автоматизированный pipeline для deployment Sigma-правил в production SIEM, бюджет на содержание offensive-команды или контракт с внешним провайдером adversary emulation. На российском рынке такой уровень зрелости встречается в единичных организациях - преимущественно в банках из первой десятки и крупных телеком-операторах. Остальные пока дорастают.
Протокол координации red team и blue team по шагам
На практике работает гибридный подход: первые 2–3 техники - immediate reveal (калибровка, команды привыкают к формату взаимодействия red team blue team), далее - delayed reveal блоками по 3–5 техник. Я начинаю с immediate - так обе стороны въезжают в ритм и не тратят время на организационные трения.
Формат передачи артефактов от Red к Blue. После каждой техники (или блока техник) Red Team передаёт:
- Таймстамп - точное время начала и завершения (UTC, не «около трёх дня»)
- Техника ATT&CK - ID + название (T1059, Command and Scripting Interpreter)
- Целевой хост - IP или hostname
- Артефакты - созданные файлы, запущенные процессы, установленные сетевые соединения
- Ожидаемые IOC - что Blue Team должен был увидеть в логах при корректной настройке detection
Фаза 3 - ретро: detection coverage map и remediation
После завершения упражнения (или каждого дня при многодневном формате) проводится совместная ретро-сессия.Структура ретро (60–90 минут):
- Обзор результатов (15 минут) - purple team lead показывает сводную таблицу: какие техники обнаружены, пропущены, обнаружены с задержкой.
- Разбор пропущенных (30–40 минут) - для каждой необнаруженной техники определяется корневая причина:
- Логи не собирались → проблема visibility
- Логи были, нет правила → проблема detection engineering
- Правило есть, не сработало → проблема тюнинга или версии продукта
- Правило сработало, аналитик не среагировал → проблема процесса или alert fatigue
- План remediation (15–20 минут) - конкретные задачи с owners и deadlines. Каждый gap = задача в трекере. Без трекера gap'ы остаются «в планах» и не закрываются. Проверено.
- Обновление detection coverage map (10 минут) - визуализация покрытия MITRE ATT&CK до и после упражнения. Этот артефакт - главный результат purple team операции.
Purple team цикл на практике: T1059 Command and Scripting Interpreter
Разберём полный цикл purple teaming на одной технике - T1059 (Command and Scripting Interpreter, тактика Execution). Атакующий запускает команды через встроенные или сторонние интерпретаторы: PowerShell, cmd, bash, а также менее типичные - AutoIt, Python, VBScript.[Применимо: внутренний пентест, Windows-инфраструктура]
Шаг 1 - Red Team выполняет технику. Берём тест из Atomic Red Team: AutoIt Script Execution на Windows. AutoIt - не самый очевидный интерпретатор, и именно поэтому он хорош для adversary emulation: большинство SOC не имеют детекта на процессы AutoIt, хотя этот инструмент активно используется в реальных атаках для автоматизации действий на хосте. SOC ждёт PowerShell - а прилетает AutoIt. Классика слепой зоны.
Код:
# Atomic Red Team: AutoIt Script Execution (T1059)
# Платформа: Windows | Executor: PowerShell
# Предусловия: AutoIt3 установлен или бинарь доставлен
Invoke-AtomicTest T1059 -TestNumbers 1Шаг 2 - Blue Team проверяет детект. SOC-аналитик ищет в SIEM события, связанные с выполнением AutoIt: создание процесса
AutoIt3.exe / AutoIt3_x64.exe, запуск .au3-файлов, сетевая активность от процесса AutoIt. В репозитории SigmaHQ для T1059 - 437 правил, но подавляющее большинство покрывает PowerShell, cmd и bash. AutoIt остаётся в слепой зоне. Это именно тот gap, который выявляет structured purple team exercise.Шаг 3 - Совместное написание детекта. Purple team lead координирует создание Sigma-правила прямо на сессии:
YAML:
# Sigma: Suspicious AutoIt Script Execution
# Пример для демонстрации концепции purple team цикла
title: Suspicious AutoIt Script Execution
status: experimental
logsource:
category: process_creation
product: windows
detection:
selection:
Image|endswith:
- '\AutoIt3.exe'
- '\AutoIt3_x64.exe'
CommandLine|contains: '.au3'
condition: selection
level: medium
tags:
- attack.execution
- attack.t1059При анализе gap'ов полезно сверяться с рекомендациями MITRE D3FEND. Для T1059 рекомендованные контрмеры включают Executable Allowlisting (D3-EAL), Executable Denylisting (D3-EDL), Dynamic Analysis (D3-DA) и Content Filtering (D3-CF). Это подсказка Blue Team: какие классы защит проверить в первую очередь и какие компенсирующие меры внедрить, если Sigma-правило не покрывает все подтехники.
Инструменты для организации purple team операций
| Инструмент | Назначение | Когда использовать | Когда НЕ использовать |
|---|---|---|---|
| Atomic Red Team | Библиотека атомарных тестов по ATT&CK | Структурированные упражнения с фокусом на конкретные техники | Комплексные multi-step сценарии (нет цепочек) |
| CALDERA (MITRE) | Автоматизированная adversary emulation | Continuous purple teaming, полные kill chain | Организации без сервера и навыков настройки |
| Vectr | Трекинг результатов purple team операций | Документирование, визуализация покрытия ATT&CK | Разовые ad-hoc сессии (overhead не оправдан) |
| Cobalt Strike / Sliver | C2-фреймворки для реалистичной эмуляции | Проверка detection на уровне реальной APT | Тестирование изолированных техник (стрельба из пушки по воробьям) |
| SigmaHQ + конвертер | Универсальные detection rules | Создание правил, портируемых между SIEM | Среды без SIEM или с проприетарным форматом |
Для организаций с минимальным бюджетом стартовая связка: Atomic Red Team (открытый код, бесплатно) + SIEM с поддержкой Sigma-конвертации. CALDERA добавляется, когда нужны автоматизированные цепочки. Cobalt Strike или Sliver - когда нужна реалистичность на уровне настоящего C2 с обходом EDR.
По Cymulate, одно из ключевых преимуществ purple teaming - оптимизация существующего стека инструментов: совместная валидация выявляет неправильно настроенные, недоиспользованные и дублирующие решения. Прежде чем покупать новый инструмент - проверьте, корректно ли работают имеющиеся. В реальных проектах мы регулярно находим EDR с отключёнными модулями или SIEM, где половина коннекторов молча сломалась месяц назад.
Ошибки координации, которые убивают эффективность purple team
Red Team не документирует в реальном времени. Самая частая проблема. Атакующие увлекаются процессом, забывают фиксировать таймстампы и артефакты. На ретро Blue Team получает размытый таймлайн и не может сопоставить события с логами. Решение - шаблон в shared doc, куда Red Team вносит данные сразу после каждой техники. Не в конце дня - сразу. Поле «таймстамп» заполняется автоматически через формулу, а не вручную (потому что вручную никто не будет, и мы это знаем).Blue Team воспринимает упражнение как экзамен. Если SOC-аналитики чувствуют, что их оценивают и наказывают за пропущенные детекты - они начинают скрывать пробелы вместо того, чтобы фиксировать. Purple team lead на брифинге должен проговорить: цель - улучшить detection capability организации, а не выставить оценки людям. По Cymulate, замена антагонизма между командами на совместную работу - принципиальное отличие purple teaming от раздельного тестирования. Praetorian формулирует так: purple teaming «приоритизирует обучение над набором очков». Если аналитик боится показать gap - gap никогда не закроется.
Нет follow-up и retest. Упражнение провели, gap'ы нашли, задачи создали - и через месяц никто не проверил, что Sigma-правила задеплоены в production SIEM. Решение - retest через 2–4 недели. Red Team повторяет те же техники, Blue Team подтверждает закрытие gap'ов. Без retest purple team операция - дорогой тренинг, а не процесс continuous security testing.
Выбраны нерелевантные техники. Red Team хочет показать красивый exploit chain или экзотический persistence, хотя threat profile организации - фишинг, макросы, credential theft. Это как тренировать защиту от танков, когда атакуют дронами. Purple team lead приоритизирует техники по актуальности для конкретной организации на основе threat intelligence, а не по «интересности» для атакующих. Обмен данными threat intelligence между командами на этапе планирования снимает эту проблему.
Один раунд в год. По IANS Research, purple team упражнения должны быть итеративными. Один раунд выявляет gap'ы. Второй - проверяет, что они закрыты. Третий - тестирует новые техники из свежего threat landscape. Организации с единственным ежегодным раундом получают snapshot, но не процесс. А без процесса detection coverage map устаревает быстрее, чем его успевают обновить.
Точка зрения
Большинство обсуждений purple teaming в русскоязычном пространстве ограничивается определениями и карьерными советами. Реальная проблема глубже: организации, которые начинают строить purple team методологию, спотыкаются не на выборе инструмента и не на бюджете, а на человеческой координации.Наблюдение из практики: в половине организаций Red Team и Blue Team сидят в разных зданиях, пользуются разными мессенджерами и встречаются только на квартальном review. Purple teaming начинается не с покупки CALDERA, а с того, что два лида садятся за один стол и договариваются о формате обмена данными. Шаблон таблицы в Google Sheets, общий канал в мессенджере, еженедельная синхронизация на 30 минут - этого достаточно для первого раунда. Серьёзно, этого хватает.
Ещё момент, который редко проговаривают: purple team операция выявляет не только технические gap'ы, но организационные. Когда Red Team показывает, что lateral movement остался незамеченным, корневая причина часто не «нет Sigma-правила», а «SOC-аналитик L1 не эскалировал событие, которое было в логах, потому что за смену разгребает 200 алертов и у него alert fatigue». Это нельзя починить новым правилом - это вопрос процесса и штатного расписания.
В ближайшие полтора года purple teaming из «практики для банков топ-10» станет ожидаемым стандартом для любой организации с SOC. Требования к тестированию готовности к инцидентам ужесточаются, и detection coverage map после 4–5 раундов упражнений - документ, который закрывает вопросы аудиторов убедительнее бумажного compliance-отчёта. Если хочется отработать связку «техника ATT&CK - детект - Sigma-правило» на практике - на HackerLab есть задачи, где эта механика собирается end-to-end.
