С виду все просто: дали пентестерам доступ в сеть, они пошарились по серверам, нашли пару уязвимостей, написали отчет. Профит. Но на деле плохо подготовленная проверка легко превращается в хаотичный квест с непредсказуемым финалом.

В лучшем случае вы получите бесполезный список из сотни мелких «дыр» в принтерах и кофемашинах. В худшем — пентестеры случайно обрушат производственную линию или устроят DDoS на Active Directory. А между этими крайностями лежит целый спектр проблем: от юридических рисков, если в документе не очертить скоуп и команда выйдет за рамки дозволенного, до банального несовпадения ожиданий и результатов.

Однако всех этих неприятностей легко избежать, если подойти к планированию внутреннего пентеста основательно. В этой статье разберем, почему техническое задание — не формальность, а жизненно важный документ, и покажем, как его правильно составить. Кто-то возразит, что это утопия, и в реальности все работают иначе, но нам бы хотелось это изменить. Поверьте: оно того стоит. 

Почему без ТЗ — никуда

Внутренний пентест — это симуляция действий злоумышленника, который уже находится внутри корпоративной сети. Его главные цели — латеральное перемещение (Lateral Movement), повышение привилегий и доступ к критичным данным.

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

Размытые границы тестирования

Главная проблема — неясный скоуп. Когда не прописано, что можно трогать, а что находится под строгим запретом, пентест может неожиданно задеть критически важную часть инфраструктуры. Например, команда «замахнется на святое»: системы АСУ ТП (ICS/SCADA) или другую промышленную автоматику, вместе с которой «приляжет отдохнуть» все производство.

Бывает и хуже: безобидное внутреннее тестирование превращается в DDoS-атаку. Классический пример — агрессивный перебор паролей в Active Directory. Сеть уходит в отказ, пользователи не могут войти в свои учетные записи, а SOC-центр просыпается от лавины алертов.

Конечно, при «блэкбоксе» весь скоуп априори не указывается. Однако критичные сервисы, которые должны остаться под запретом для пентестеров, стоит зафиксировать в любом случае.

Несовпадение ожиданий и результата

Допустим, бизнес и ИБ-служба рассчитывают на глубокую проверку внутренних сервисов. А пентестеры за пару часов получают Domain Admin и спешно пишут отчет. Для них проект выглядит успешным, но заказчик разочарован. 

Проблема в том, что стороны заранее не зафиксировали ожидаемые результаты. Какая задача ставится перед пентестерами: взломать домен или разобрать возможные способы атаки? 

Зачастую цели проекта обсуждаются лишь в первом приближении еще до заключения договора — команде ведь нужно хотя бы примерно прикинуть трудозатраты. Но самые бледные чернила лучше самой хорошей памяти. Устные договоренности могут выпасть из фокуса внимания пентестеров или заказчиков.

Юридические риски

Внутренний пентест предполагает работу с чувствительными корпоративными данными. Без ТЗ команда пентеста рискует перейти грань дозволенного или, точнее, санкционированного. 

Можно случайно затронуть базы с персональными данными, что уже чревато неприятностями с регуляторами. Или вот другой сценарий: пентестер находит уязвимость в 1С, для демонстрации угрозы копирует фрагмент финансовой базы в отчет и провоцирует конфликт с корпоративными юристами. 

Пустая трата ресурсов

Хорошо, когда пентестерам дают доступ и понятную цель — захват домена, но если бесцельно бродить по инфраструктуре и тестировать все подряд, то получится бесполезный отчет с SQL-инъекцией в меню столовой и десятками других малозначимых уязвимостей. Опасные же проблемы вроде слабых паролей админов в действительно важных для бизнеса сервисах останутся незамеченными — просто потому, что никто не обозначил приоритеты. 

Что должно быть в ТЗ для внутреннего пентеста

Так каким же должно быть содержание документа, чтобы он действительно решал описанные выше проблемы? Правильное ТЗ — это полноценная дорожная карта проекта. Обычно оно включает восемь ключевых разделов.

1. Цели тестирования

Целеполагание из серии «захватить мир всю инфраструктуру» не подойдет. В этом разделе технического задания нужно максимально подробно ответить на вопрос «зачем проводится тест?».

Примеры емких и корректных формулировок:

• определить возможность компрометации домена Active Directory с учетной записи рядового сотрудника;

• проверить устойчивость внутренней сети к латеральному перемещению между сегментами;

• оценить риск несанкционированного доступа к финансовым системам (1С, ERP).

Без подобной детализации неопытные пентестеры могут сфокусироваться, скажем, на сканировании принтеров, а реальные угрозы останутся в тени. Но к проблеме целеполагания мы еще вернемся.

2. Задачи тестирования

На этом уровне формулируется, что именно предстоит сделать. Например:

• выявить уязвимости и недостатки в конфигурации Active Directory и связанных сервисов;

• проверить устойчивость ИТ-инфраструктуры к атакам на повышение привилегий;

• оценить эффективность механизмов обнаружения атак;

•  оценить устойчивость паролей к перебору;

• разработать рекомендации по устранению уязвимостей и недостатков;

• достичь дополнительных целей, связанных с недопустимыми событиями или симуляцией сценария. 

3. Границы тестирования (Scope) и контекст бизнес-процессов 

Scope дословно переводится как «масштаб» тестирования. Здесь устанавливаются ограничения на:

• сети и подсети: например, «192.168.1.0/24, кроме VLAN 30»;

• системы: Active Directory, файловые серверы, базы данных, внутренние веб-приложения;

• типы тестов: например, разрешены Passive Reconnaissance и Exploitation, но запрещена социальная инженерия.

Чаще всего из скоупа исключают промышленные системы (ICS/SCADA), серверы резервного копирования с критичной нагрузкой и телекоммуникационное оборудование (VoIP, IP-телефония). Словом, любые сервисы, атаки на которые могут привести к остановке бизнес-процессов или нарушению законодательства, остаются для пентестеров табу.

Что касается контекста бизнес-процессов, то сюда относятся:

• критически важные для бизнеса процессы (например, финансовая отчетность, включая 1С, банк-клиенты и документооборот);

• приоритизация векторов атак (например, высокий приоритет — системы, обеспечивающие жизнеспособность бизнеса; низкий приоритет — вспомогательные системы). 

Четкие границы и бизнес-контекст делают тестирование максимально полезным и безопасным, помогая правильно распределить время и ресурсы команды.

4. Исходные условия и модель нарушителя 

Это как стартовая позиция в шахматной задаче. Можно начать с классического дебюта, методично развивая фигуры и борясь за центр. А можно сразу получить ферзя в центре доски и несколько линий атак на выбор. От стартовых условий зависит весь план действий.

Примеры моделей нарушителя:

• внутренний злоумышленник (недовольный сотрудник);

• внешний хакер, получивший первоначальный доступ через фишинг;

• подрядчик/контрагент с ограниченным доступом. 

Уровень доступа на старте:

• прямой доступ посредством подключения к VPN;

• доступ через джамп-хост посредством подключения к VPN;

• обычный пользователь (Domain User);

• локальный администратор на рабочей станции;

• доступ к одной конкретной системе (например, уязвимому веб-приложению).

 Данные для доступа (для тестов типа White и Gray Box):

• логины;

• пароли;

• VPN-ключи.

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

5. Методы и ограничения

Этот раздел технического задания очерчивает границы предоставляемой пентестерам информации, а также отвечает на два вопроса: «что можно?» и «что нельзя?». Приведем примеры. 

Что можно:

• использовать инструменты Mimikatz, BloodHound, Cobalt Strike;

• эксплуатировать уязвимости (но без DoS-эффекта);

• перебирать пароли (но не блокировать учетные записи).

Что нельзя:

• атаковать системы вне очерченного scope (даже если они «соседствуют» с тестируемыми сервисами);

• использовать социальную инженерию без отдельного согласования;

• менять конфигурации (например, добавлять себя в группу админов);

• блокировать учетные данные пользователей. 

Методология тестирования:

• Black Box: пентестеры не имеют предварительной информации об инфраструктуре;

• Gray Box: предоставляются начальные учетные данные, но инфраструктура не раскрывается;

• White Box: полное раскрытие архитектуры, документации и учетных данных. 

Без этого раздела и соответствующих исключений в СЗИ администраторы заказчика рискуют утонуть в алертах от SIEM, словно жадный раджа из мультфильма «Золотая антилопа» — в монетах. Да, SOC, как правило, в курсе работ, и заказчик всегда может уточнить у исполнителя, его ли активность зафиксирована, но порой предупреждений так много, что в них может затеряться нечто важное.

6. Критерии успеха

В разделе определяются условия, когда тест считается успешно завершенным. Например:

• получение прав Domain Admin за три шага или меньше;

• получение доступа к определенным конфиденциальным данным;

• захват управления конкретными системами, которые явно обозначены в техническом задании.

Не стоит забывать и об оборотной стороне медали — fail-факторах, например:

• невозможность перемещения между сегментами сети из-за избыточной сегментации; 

• недостаточность изначальных предоставленных прав доступа для старта тестирования;

• постоянные падения критических сервисов при попытках эксплуатации; 

• блокировка всех инструментов тестирования системами защиты без возможности обхода. 

С четкими критериями не возникнет ситуаций, когда заказчик ждет «полного взлома» сети, а пентестеры празднуют после первой компрометации домена. Зафиксированные же fail-факторы заранее пресекут споры о результативности тестирования и помогут договориться о SLA. 

7. Отчетность

Структуру отчета тоже лучше продумать заранее. Обычно он включает два документа: Executive Summary для топ-менеджмента и Technical Report для технических специалистов. Первый фокусируется на бизнес-рисках, второй — на деталях уязвимостей и векторах атак.

Укрупненно отчет содержит:

• перечень уязвимостей и их критичность (с оценкой по CVSS и риском для бизнеса);

• пошаговые сценарии атак (kill chain), чтобы их можно было воспроизвести;

• конкретные рекомендации по устранению недостатков;

• приложения с логами команд, результатами сканирований и схемами компрометации.

Документ не должен превращаться в километровый список находок без приоритетов, иначе работа над ошибками будет попросту неэффективной.

8. Сроки и коммуникация

Этот раздел — неформальный календарь проекта. В нем стоит зафиксировать:

• Точные даты и время проведения теста (важно: время на согласование отчета обычно не входит в срок выполнения проекта).

• Рекомендации по срокам (например, малая инфраструктура до 50 хостов — 5–10 дней; средняя, 50-200 хостов — 10–15 дней; крупная, 200+ хостов — 15–25 дней).

• Контактных лиц на случай инцидентов (кто и как быстро сможет поднять упавший сервис).

• Правила эскалации: кто, кому и куда звонит, если что-то пошло не так.

Забудешь что-то важное — и по закону подлости админы начнут чинить сервис или обновлять Active Directory прямо во время пентеста, меняя весь ландшафт уязвимостей. И это было только начало.

Не все ТЗ одинаково полезны 

Мы бы не писали эту статью, если бы во всех компаниях подходили к составлению ТЗ основательно. Увы, на практике все иначе.

Иногда сталкиваешься с тяжелыми случаями, когда ТЗ ограничивается расплывчатым перечнем целей. Проект превращается в квест «пойди туда — не знаю куда», а исполнителям приходится непрерывно засыпать заказчика уточняющими вопросами.

Допустим, в ТЗ стоит цель: «захват всех необходимых систем управления серверов и АРМ». Что значит «всех необходимых»? Какие из тысяч устройств в сети действительно критичны? Хорошо, если заказчика устроит получение прав доменного администратора — это понятная и измеримая цель. Но порой приходится буквально гадать.

Еще сложнее, когда штатная ИБ-служба выделяет контактное лицо, но оно не может ответить на базовые вопросы. «Подскажите IP-адреса критичных серверов?» — «Не знаю, спросите у админов». «Какие системы нужно проверить в первую очередь?» — «Ну, все важные».

Вот несколько простых, но полезных советов, как избежать подобных ситуаций:

1. Прописывайте цели максимально подробно. Да, звучит банально, но это тот случай, когда лучше повторить. Вместо «захватить все необходимые системы» напишите: «получить доступ к контроллерам домена в сегменте 192.168.10.0/24 и файловому серверу с базами 1С».

2. Назначьте компетентное контактное лицо. Даже при идеальном ТЗ у исполнителей будут вопросы. Нет смысла выделять в качестве куратора джуниора, который не знает, к кому обращаться. Это должен быть человек, способный стать полноценной «точкой входа» для команды пентестеров.

3. Готовьте ТЗ совместно с исполнителями (если это возможно и пентест заказывается не через тендер). Пригласите на встречу с командой пентеста не только главу ИБ, но и представителя IT-отдела. Это помогает сразу расставить приоритеты и синхронизировать ожидания.

Специализированные компании по кибербезопасности обладают не только экспертизой, но и насмотренностью. У многих есть шаблоны ТЗ, проверенные десятками проектов. Возьмите их за основу и наполните своей конкретикой.

Разумеется, каждый кейс уникален. Подход к документу может меняться в зависимости от инфраструктуры, зрелости команды и целей проверки. Поэтому, если у вас есть свои практики, шаблоны, «грабли» или, наоборот, удачные решения — расскажите о них в комментариях. Чем больше опыта мы соберем, тем меньше боли и сложностей будет у всех участников процесса.

PURP — телеграм-канал, где кибербезопасность раскрывается с обеих сторон баррикад

t.me/purp_sec — инсайды и инсайты из мира этичного хакинга и бизнес-ориентированной защиты от специалистов Бастиона