Scope и Rules of Engagement (RoE) — два документа, которые определяют, что пентестеру разрешено делать, на каких системах, в какое время и с какими ограничениями. Без них любая активность на чужой инфраструктуре юридически неотличима от несанкционированного доступа. Даже при устной договорённости отсутствие письменного согласования создаёт риск для обеих сторон: заказчик не защищён от выхода за рамки, а исполнитель — от претензий при обнаружении «лишних» находок.
Scope (область применения) — это исчерпывающий перечень объектов, на которые распространяется разрешение на тестирование. Он отвечает на вопрос «что можно трогать».
Типичные элементы scope:
На практике пентестер часто обнаруживает смежные системы, которые не входят в scope, но технически доступны. Без явного запрета возникает соблазн «проверить и их». Если эти системы принадлежат третьим лицам или другому подразделению заказчика, это уже выход за рамки. Раздел «Исключения» снимает двусмысленность.
RoE — операционные правила, которые описывают «как» проводится тестирование. Если scope определяет границы, то RoE определяет поведение внутри этих границ.
Ключевые пункты RoE:
Окно тестирования защищает бизнес-процессы заказчика. Например, если пентест проводится на production-среде, активная фаза может быть ограничена ночным временем или выходными. Интенсивность определяет глубину: некоторые заказчики разрешают только сканирование без эксплуатации, другие допускают полную цепочку вплоть до повышения привилегий.
Формулировка в документе может выглядеть так:
При обнаружении критической уязвимости (например, RCE на внешнем периметре) пентестер обязан немедленно уведомить контактное лицо заказчика. В RoE фиксируются:
Перед написанием документа необходимо получить от заказчика:
Каждый объект должен быть описан однозначно. Плохая формулировка: «тестирование веб-приложения». Хорошая: «тестирование
Исключения формулируются так же конкретно: «Запрещено тестирование
Scope и RoE — не только технические документы. Они имеют юридическую силу и должны быть подписаны уполномоченным представителем заказчика. В некоторых юрисдикциях для пентеста требуется отдельное разрешение или уведомление регулятора.
Если в ходе работ scope расширяется (заказчик добавляет новый хост), изменение должно быть задокументировано и подписано. Устное расширение не защищает пентестера.
Размытый scope. Формулировки вроде «внешний периметр компании» без конкретного списка IP и доменов приводят к спорам о том, был ли пентестер вправе тестировать обнаруженный поддомен.
Отсутствие раздела исключений. Если не указано, что запрещено, пентестер может случайно затронуть системы третьих лиц.
Нет окна тестирования. Без временных рамок заказчик может предъявить претензии, если сканирование совпало с инцидентом доступности.
Нет правила остановки. Если пентестер обнаруживает компрометацию (например, активный malware на хосте), без заранее согласованного протокола непонятно, продолжать ли работу или останавливаться.
Устное согласование. Любое изменение scope должно фиксироваться письменно. Устная договорённость не имеет доказательной силы.
Ниже — упрощённый шаблон, который можно адаптировать под конкретный проект.
Scope напрямую влияет на выбор методологии. Если в scope только внешние веб-приложения, пентестер фокусируется на OWASP Top 10, логических уязвимостях и проверке авторизации. Если включена внутренняя сеть — добавляются проверки на повышение привилегий, lateral movement, анализ Active Directory.
Для учебных целей и отработки навыков в безопасной среде можно использовать домашнюю лабораторию на Kali Linux со специально уязвимыми приложениями Домашняя лаборатория для пентеста: как безопасно учиться на Kali Linux и специально уязвимых приложениях. Это позволяет тренировать техники без риска выйти за рамки реального scope.
Это одна из самых частых ситуаций на практике. Алгоритм действий:
Никаких «быстрых проверок» до получения разрешения. Даже один запрос к системе вне scope может быть расценён как несанкционированный доступ.
Перед началом активной фазы убедитесь, что:
Что такое scope и зачем он нужен
Scope (область применения) — это исчерпывающий перечень объектов, на которые распространяется разрешение на тестирование. Он отвечает на вопрос «что можно трогать».
Типичные элементы scope:
- Сетевые адреса и подсети. Конкретные IP-диапазоны, CIDR-нотация. Например,
192.168.10.0/24и10.0.5.0/28.
- Домены и поддомены. Явный список:
app.example.com,api.example.com. Формулировка «все поддомены example.com» допустима, но требует отдельного подтверждения, что заказчик владеет всем DNS-пространством.
- Приложения и API. Конкретные эндпоинты, версии, среды (staging, production).
- Физические объекты. Если пентест включает физический доступ — адреса зданий, этажи, зоны.
- Социальная инженерия. Количество целевых сотрудников, допустимые каналы (email, телефон, мессенджеры), запрет на определённые темы.
- Явное исключение. Список того, что запрещено: продакшн-базы данных, конкретные хосты, сторонние сервисы (CDN, облачные провайдеры, SaaS).
Почему важно указывать исключения
На практике пентестер часто обнаруживает смежные системы, которые не входят в scope, но технически доступны. Без явного запрета возникает соблазн «проверить и их». Если эти системы принадлежат третьим лицам или другому подразделению заказчика, это уже выход за рамки. Раздел «Исключения» снимает двусмысленность.
Что такое Rules of Engagement
RoE — операционные правила, которые описывают «как» проводится тестирование. Если scope определяет границы, то RoE определяет поведение внутри этих границ.
Ключевые пункты RoE:
| Пункт | Что описывает |
|---|---|
| Окно тестирования | Даты и время, когда разрешена активная фаза |
| Интенсивность | Уровень агрессивности: только сканирование, эксплуатация, post-exploitation |
| Запрещённые техники | DoS, социальная инженерия, физический доступ, беспроводные атаки |
| Контакты эскалации | Кто и как уведомляется при критической находке |
| Правила остановки | Условия, при которых тестирование немедленно прекращается |
| Обработка данных | Что делать с найденными учётными данными, PII, дампами |
| Отчётность | Формат, сроки, уровень детализации |
Окно тестирования и интенсивность
Окно тестирования защищает бизнес-процессы заказчика. Например, если пентест проводится на production-среде, активная фаза может быть ограничена ночным временем или выходными. Интенсивность определяет глубину: некоторые заказчики разрешают только сканирование без эксплуатации, другие допускают полную цепочку вплоть до повышения привилегий.
Формулировка в документе может выглядеть так:
Код:
Активная фаза: 15.03.2025 22:00 — 17.03.2025 06:00 UTC.
Разрешено: сканирование портов, эксплуатация уязвимостей, горизонтальное перемещение.
Запрещено: DoS-атаки, удаление или модификация данных, социальная инженерия.Контакты эскалации и правила остановки
При обнаружении критической уязвимости (например, RCE на внешнем периметре) пентестер обязан немедленно уведомить контактное лицо заказчика. В RoE фиксируются:
- Имя и телефон ответственного со стороны заказчика.
- Максимальное время до уведомления (например, 30 минут).
- Канал связи (мессенджер, email, телефон).
- Условия полной остановки работ: срабатывание инцидент-процесса, жалоба третьего лица, обнаружение данных, не относящихся к scope.
Как составить scope: пошаговый подход
Шаг 1. Сбор информации от заказчика
Перед написанием документа необходимо получить от заказчика:
- Список всех систем, которые должны быть протестированы.
- Архитектурную схему или хотя бы перечень сред (dev, staging, prod).
- Информацию о сторонних интеграциях (облачные сервисы, CDN, платёжные шлюзы).
- Ограничения со стороны регуляторов или внутренних политик.
Шаг 2. Формулировка включений и исключений
Каждый объект должен быть описан однозначно. Плохая формулировка: «тестирование веб-приложения». Хорошая: «тестирование
https://app.example.com (production, версия 3.2.1) и https://staging.example.com (staging)».Исключения формулируются так же конкретно: «Запрещено тестирование
db-internal.example.com, подсети 10.0.0.0/16, любых систем, не указанных в разделе включений».Шаг 3. Согласование с юридическим отделом
Scope и RoE — не только технические документы. Они имеют юридическую силу и должны быть подписаны уполномоченным представителем заказчика. В некоторых юрисдикциях для пентеста требуется отдельное разрешение или уведомление регулятора.
Шаг 4. Фиксация версий и изменений
Если в ходе работ scope расширяется (заказчик добавляет новый хост), изменение должно быть задокументировано и подписано. Устное расширение не защищает пентестера.
Типичные ошибки при составлении
Размытый scope. Формулировки вроде «внешний периметр компании» без конкретного списка IP и доменов приводят к спорам о том, был ли пентестер вправе тестировать обнаруженный поддомен.
Отсутствие раздела исключений. Если не указано, что запрещено, пентестер может случайно затронуть системы третьих лиц.
Нет окна тестирования. Без временных рамок заказчик может предъявить претензии, если сканирование совпало с инцидентом доступности.
Нет правила остановки. Если пентестер обнаруживает компрометацию (например, активный malware на хосте), без заранее согласованного протокола непонятно, продолжать ли работу или останавливаться.
Устное согласование. Любое изменение scope должно фиксироваться письменно. Устная договорённость не имеет доказательной силы.
Пример структуры документа
Ниже — упрощённый шаблон, который можно адаптировать под конкретный проект.
Код:
1. Общие сведения
- Заказчик, исполнитель, дата подписания.
- Цель тестирования.
2. Scope (включения)
- IP-адреса и подсети.
- Домены и URL.
- Приложения, API, среды.
- Физические объекты (если применимо).
- Социальная инженерия (если применимо).
3. Scope (исключения)
- Явно запрещённые системы, подсети, сервисы.
- Сторонние провайдеры.
4. Rules of Engagement
- Окно тестирования.
- Разрешённые и запрещённые техники.
- Интенсивность и глубина.
- Контакты эскалации.
- Правила остановки.
- Обработка найденных данных.
5. Отчётность
- Формат, сроки, уровень детализации.
- Требования к классификации находок.
6. Юридические положения
- Подписи уполномоченных лиц.
- Ответственность сторон.
- Порядок изменения scope.Связь scope с методологией тестирования
Scope напрямую влияет на выбор методологии. Если в scope только внешние веб-приложения, пентестер фокусируется на OWASP Top 10, логических уязвимостях и проверке авторизации. Если включена внутренняя сеть — добавляются проверки на повышение привилегий, lateral movement, анализ Active Directory.
Для учебных целей и отработки навыков в безопасной среде можно использовать домашнюю лабораторию на Kali Linux со специально уязвимыми приложениями Домашняя лаборатория для пентеста: как безопасно учиться на Kali Linux и специально уязвимых приложениях. Это позволяет тренировать техники без риска выйти за рамки реального scope.
Что делать, если в ходе пентеста обнаружена система вне scope
Это одна из самых частых ситуаций на практике. Алгоритм действий:
- Немедленно прекратить взаимодействие с обнаруженной системой.
- Зафиксировать факт обнаружения (скриншот, лог запроса).
- Уведомить контактное лицо заказчика.
- Дождаться письменного решения: включить систему в scope или подтвердить запрет.
- Продолжить работу только после получения письменного подтверждения.
Никаких «быстрых проверок» до получения разрешения. Даже один запрос к системе вне scope может быть расценён как несанкционированный доступ.
Проверка перед стартом работ
Перед началом активной фазы убедитесь, что:
- Scope подписан уполномоченным лицом заказчика.
- Все объекты в scope однозначно идентифицированы (IP, домен, URL).
- Исключения сформулированы явно.
- RoE содержит окно тестирования, контакты эскалации и правила остановки.
- У вас есть письменное подтверждение на каждую систему, которую вы планируете тестировать.
- Вы знаете, как действовать при обнаружении системы вне scope.
- Юридический отдел заказчика подтвердил, что дополнительных разрешений не требуется.