Rules of Engagement для Red Team: scope и риски

На проекте для одного финтеха оператор red team обнаружил, что тестируемое приложение дёргает API платёжного шлюза. Перешёл по эндпоинту, начал фаззить параметры - и уронил sandbox-среду провайдера на два часа. В ROE не было ни строчки про третьи стороны. Заказчик получил претензию от платёжной системы, а мы - урок, который обошёлся дороже самого контракта. Rules of Engagement - не бумажка для подшивки к договору. Это единственное, что отделяет авторизованную операцию от потенциального уголовного дела.

Чем ROE отличается от scope of work и договора на проведение red team операции​

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

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

Scope of Work (техническое задание на red team) - что именно тестируем: перечень IP-диапазонов, доменов, приложений, физических объектов. По сути - инвентаризация активов, попадающих в периметр проекта.

Rules of Engagement - как тестируем: какие тактики разрешены, какие запрещены, что делать при обнаружении реального инцидента, кому звонить в три часа ночи при срабатывании физической охраны. Согласно NIST Technical Guide to Information Security Testing and Assessment, assessment plan (куда входит ROE) устанавливает правила и границы до начала тестирования, включая системы, авторизованные для проверки, и действия, явно запрещённые.

Специалисты Cobalt.io формулируют так: документ ROE для red team регулирует более динамичную кампанию по сравнению с пентестом. Организационные цели определены (доступ к данным клиентов, эмуляция конкретной APT-группировки), но конкретный путь атаки намеренно оставлен непрозрачным - операторы выбирают подход в зависимости от среды. Именно поэтому ограничения scope пентеста и рамки red team engagement требуют разных подходов к документированию.

Практический вывод прост: SoW отвечает на вопрос "что входит в проект", ROE - на вопрос "что оператор имеет право делать прямо сейчас, стоя перед терминалом". Без ROE оператор принимает решения на лету. Каждое такое решение - юридический риск.

Структура документа ROE пентест и red team​

Executive Summary и цели операции​

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

1. Что тестируем - одно предложение, понятное CISO без технического бэкграунда.
2. Зачем - бизнес-цель: проверка реагирования SOC, оценка возможности эксфильтрации данных, тест физической безопасности.
3. Явные ограничения - что точно делать нельзя.

Формулировка цели влияет на всё остальное. "Оценить защищённость" - бесполезная фраза, которая не ограничивает оператора ничем. Я такие формулировки видел десятки раз, и каждый раз они заканчивались спорами о том, "а это входило или нет". Рабочая цель выглядит иначе: "Определить, может ли внешний атакующий без инсайдерского доступа получить доступ к базе данных клиентов PCI DSS scope за 10 рабочих дней". Она задаёт тип операции (full scope external), time-boxing (10 дней) и критерий успеха (доступ к конкретной базе).

Scope для red team тестирования: четыре категории активов​

Scope в ROE - не просто список IP-адресов. Проблемы возникают не с тем, что перечислено, а с тем, что не перечислено. Поэтому scope должен содержать четыре явные категории:


Последняя строка - именно то, что привело к инциденту из вводного примера. Доступ к приложению заказчика не означает автоматической авторизации на тестирование его хостинг-провайдера, связанных сервисов или других арендаторов на shared-инфраструктуре. В рекомендациях NIST это сформулировано чётко: разрешение на тестирование системы и разрешение на создание файлов или хранение данных на ней - отдельные решения.

Для операций с элементами разведки - Active Scanning (T1595, Reconnaissance), Gather Victim Network Information (T1590, Reconnaissance), Gather Victim Org Information (T1591, Reconnaissance) по MITRE ATT&CK - scope должен явно указывать, разрешён ли OSINT из публичных источников, сканирование портов внешнего периметра и сбор информации о сотрудниках через социальные сети (T1589 Gather Victim Identity Information, Reconnaissance).

Разрешённые и запрещённые TTP в правилах взаимодействия red team​

Тактики прописываются не абстрактными пожеланиями, а как решения, которые оператор применяет в поле. Формулировка "соблюдать осторожность" заставляет разных людей принимать разные решения под давлением. В курсе Grasp.study по engagement rules это сформулировано точно: полезный запрет называет действие и его границу.

Пример рабочих формулировок из реальных ROE (адаптировано):

Разрешено:

• Сканирование портов в диапазоне scope (nmap -sS / TCP connect)
• Эксплуатация уязвимостей веб-приложений (SQLi, XSS, SSRF) без намеренного разрушения данных
• Фишинг для сбора информации (T1598, Reconnaissance) - только корпоративная почта, только согласованные шаблоны, не более 50 писем
• Физическое проникновение (tailgating, social engineering на рецепции) - только в рабочие часы, с authorization letter при себе

Запрещено:

• Denial-of-Service любого типа
• Password spraying более 5 попыток на учётную запись (блокировка production-аккаунтов)
• Модификация или удаление данных в production
• Установка persistent implants без согласования с Trusted Agent
• Контакт с сотрудниками за пределами корпоративной среды (личная почта, мессенджеры)
• Сбор реальных персональных данных сверх необходимого для доказательства доступа

Тут есть нюанс, который многие упускают: некоторые запреты требуют разрешённого исключения. "Не эксфильтровать чувствительную информацию" оставляет открытым вопрос - можно ли зафиксировать proof-of-access? Рабочая формулировка: "Оператор может зафиксировать скриншот заголовка документа и первых трёх строк как доказательство доступа, но не вправе копировать, открывать или сохранять содержимое". Разница между "нельзя ничего" и "можно вот это конкретное" - разница между бесполезным отчётом и доказательной базой.

Юридические риски red team и как их закрыть​

Get-out-of-jail-free letter и авторизация на тестирование на проникновение​

Authorization letter - документ, который оператор носит при себе (буквально, в кармане) при физическом проникновении. Письмо подтверждает, что действия оператора авторизованы руководством компании-заказчика и содержит:

• ФИО и должность подписанта (уровень не ниже CISO или генерального директора)
• Контактный телефон для верификации, работающий 24/7 на время операции
• Описание авторизованных действий с датами
• Срок действия документа

Без этого документа задержание охраной превращается из запланированного сценария в реальное разбирательство с полицией. В одном случае оператора задержали при попытке проникновения на объект в нерабочие часы - get-out-of-jail-free letter и работающий телефон подписанта разрешили ситуацию за 40 минут вместо возможного уголовного производства. Работающий телефон - ключевое слово. Мёртвый номер в три ночи равен отсутствию письма.

По шаблону Red Team Guide, ROE должен быть подписан представителями заказчика, владельца системы и red team. Подписание ROE означает признание и одобрение полномочий red team в рамках операции. Уровень подписанта критически важен: подпись менеджера среднего звена, у которого нет полномочий над всеми системами в scope, юридически бесполезна.

Ограничение ответственности и NDA​

Indemnification (возмещение ущерба) - пункт, защищающий red team от претензий за последствия авторизованных действий. Оператор действовал в рамках ROE и случайно вызвал сбой - ответственность на заказчике. Вышел за рамки ROE - на red team. Граница чёткая, и именно поэтому ROE должен быть детальным.

Ключевые формулировки для основного контракта (не ROE):

• Limitation of liability - ограничение ответственности red team суммой контракта
• Indemnification clause - заказчик возмещает ущерб от авторизованных действий
• E&O insurance - страхование профессиональной ответственности

Для российского контекста: устоявшейся судебной практики по red team операциям в РФ пока нет. Каждый пункт ROE должен быть проработан с юристом, знакомым с ФЗ-152 (персональные данные) и УК РФ ст. 272-274 (неправомерный доступ к компьютерной информации). Для финтеха добавляется регулирование ЦБ, для КИИ - требования ФСТЭК. Формулировка авторизации на тестирование на проникновение должна быть достаточно конкретной, чтобы исключить квалификацию действий оператора по ст. 272 УК РФ. Расплывчатая авторизация в суде не стоит бумаги, на которой напечатана.

Обращение с данными фиксируется отдельным блоком ROE:

• Какие типы данных считаются чувствительными (ПДн, финансовые данные, медицинские записи)
• Как хранятся артефакты операции (зашифрованный том, срок хранения, процедура уничтожения)
• Кто имеет доступ к отчёту (поимённый список, не "руководство компании")
• Запрет на использование обнаруженных данных вне контекста проекта

Из шаблона Red Team Guide: "Red Team не будет намеренно компрометировать информацию, защищённую PIA, медицинскую, судебную или религиозную информацию. При случайной компрометации - немедленное уведомление ответственного лица".

Эскалация во время red team операции​

Пауза vs полная остановка: когда и как​

Не каждое нештатное событие требует полной остановки. В материалах Grasp.study по engagement rules and escalation boundaries разделяют два режима, и это разделение на практике экономит кучу нервов:

Локальная пауза:

• Оператор обнаружил систему, не указанную в scope
• Неожиданное поведение приложения без видимого ущерба
• Действие: остановить работу по конкретному вектору, продолжить по другим авторизованным направлениям, уведомить Trusted Agent для классификации актива

Полная остановка (Emergency Stop):

• Признаки реального инцидента (не связанного с red team)
• Непреднамеренное нарушение работоспособности production-сервиса
• Обнаружение данных, указывающих на преступную деятельность
• Действие: прекратить ВСЕ активности, уведомить Trusted Agent и Engagement Director, не удалять артефакты - удаление может помешать расследованию реального инцидента

Условия остановки - не критерии провала. Остановленный тест может быть возобновлён после разрешения инцидента. Это отдельно фиксируется в ROE: кто принимает решение о возобновлении, какие условия должны быть выполнены.

Trusted Agent - представитель заказчика с полномочиями принимать решения в реальном времени. Требования к этой роли:

• Доступен 24/7 на время операции
• Имеет полномочия остановить или продолжить операцию
• Знает scope и ROE
• Имеет прямой контакт с SOC (если SOC не уведомлён)

Каналы связи фиксируются с резервными вариантами: основной (зашифрованный мессенджер), резервный (телефонный звонок), аварийный (личная встреча при физических операциях). У внутренней red team GitLab, например, рабочая модель такая: выделенный Slack-канал с trusted participants и отдельный приватный канал для верификации "это red team или реальная атака?".

Чек-лист составления Rules of Engagement​

Шаг 8 часто пропускают "ради экономии". На практике три часа работы юриста и red team lead над формулировками серой зоны экономят недели разбирательств. Проверено.

Ошибки в документе ROE, которые стоят дороже контракта​

Размытый scope без обработки серой зоны. "Тестировать веб-приложения заказчика" не отвечает на вопрос, что делать, когда приложение вызывает API партнёра. Решение: явная категория "серая зона" с процедурой эскалации для каждого необозначенного актива.

Отсутствие time-boxing. Операция без временных рамок - бесконечный проект с неконтролируемыми рисками. Фиксировать нужно не только даты начала и окончания, но и рабочие часы. Night operations - отдельное согласование. В GitLab red team не провоцирует on-call инциденты в нерабочие часы без предварительного одобрения. Если цель операции - тест ночных процессов, это фиксируется отдельным пунктом. Не устным согласованием в чате, а пунктом в документе.

SOC не уведомлён, и нет протокола деконфликтации. SOC обнаруживает активность red team, начинает incident response - тратятся ресурсы, ломается ход операции. Решение: определить в ROE, знает ли SOC об операции (assumed breach vs full scope), и если не знает - кто и как разрешает конфликт при обнаружении. По данным Cobalt.io, заказчик обычно назначает Trusted Agent для деконфликтации активности red team и реальных угроз.

Нет процедуры при обнаружении реального инцидента. Во время red team операции можно наткнуться на следы реального APT. Из шаблона Red Team Guide: "Red Team приостанавливает деятельность при обнаружении компьютерных аномалий, которые могут быть несанкционированными вторжениями в сети target of environment". Без этого пункта оператор не знает - продолжать или остановиться, а промедление наносит реальный ущерб. С учётом статистики Mandiant (медианное время нахождения злоумышленника в сети до обнаружения - 11 дней) red team вполне может столкнуться с живым инцидентом. На одном проекте мы так нашли чужой reverse shell, который висел уже неделю. ROE чётко говорил: стоп, звоним.

Копирование шаблона без адаптации. Шаблон ROE (включая тот, что на redteam.guide) - промпт для соглашения, а не готовый документ. Каждый проект уникален: регуляторные требования, зрелость SOC, наличие третьих сторон, тип операции. Шаблон без адаптации под конкретную среду юридически слаб и операционно бесполезен. Это как копировать чужой nmap-скрипт без понимания, что он делает - рано или поздно прилетит.

ROE - документ, который пишется до операции, но живёт во время неё. Каждое решение оператора в поле проверяется вопросом: "могу ли я обосновать это действие конкретным пунктом ROE?" Если ответ "нет" - это сигнал к паузе и эскалации, а не к импровизации.

За несколько лет руководства red team проектами я подписал больше сотни ROE и могу утверждать: самые дорогие ошибки происходят не от технической неграмотности оператора, а от лени на этапе составления документа. Индустрия движется к формализации - фреймворки TIBER-EU и CBEST требуют детальных ROE как обязательный этап, и аналогичные требования для финансового сектора в России - вопрос времени. Но даже без регуляторного давления арифметика простая: три часа совместной работы юриста и red team lead над формулировками серой зоны экономят сотни тысяч рублей потенциального ущерба и месяцы нервов. Кто строит этот навык сейчас - работает спокойно. Кто продолжает копировать шаблоны и подписывать не глядя - рано или поздно окажется в ситуации, где authorization letter нужен был вчера, а формулировка про третьи стороны - позавчера. На WAPT эту механику разбирают на реальных кейсах с разбором формулировок - не теория, а конкретные документы.