Оператор на проекте для финтеха зашёл на эндпоинт платёжного шлюза, начал фаззить параметры и на два часа уронил песочницу провайдера. В Rules of Engagement про третьи стороны не было ни строчки. Итог — претензия от платёжной системы и урок дороже контракта.
ROE это не формальность для подшивки к договору. Он отделяет авторизованную операцию от реальных проблем с законом.
🔹 Договор — юридическая рамка: стороны, стоимость, сроки
🔹 Scope of Work — что тестируем: IP, домены, приложения
🔹 ROE — как тестируем: какие тактики разрешены, а какие нет
Главная ловушка в scope — не то, что перечислили, а то, что забыли. ROE делит активы на четыре категории: в scope, вне scope, серая зона и третьи стороны. Последние и приводят к инцидентам: доступ к приложению клиента не даёт права трогать его хостинг-провайдера.
Ещё ошибка — формулировки вроде «оценить защищённость». Рабочая цель звучит конкретно: определить, может ли внешний атакующий без инсайдерского доступа получить доступ к базе клиентов PCI DSS за 10 рабочих дней. Тип операции, сроки и критерий успеха заданы сразу.
В полной статье — готовая структура ROE с примерами формулировок, разбор запрещённых тактик, маппинг на MITRE ATT&CK и рекомендации NIST: https://clck.su/bpgAT
Полная статья: https://clck.su/bpgAT