Плохо подготовленный пентест — это выброшенные деньги. Картина почти всегда одна и та же: компания платит за 10 человеко-дней, из которых четыре уходят на то, чтобы получить доступы, дождаться разрешения от облачного провайдера и выяснить, что вообще тестировать. На сам поиск уязвимостей остаётся половина бюджета. Ниже не банальный список «определите цели», а то, что реально нужно сделать до старта: с цифрами, примерами документов и ошибками, которые дорого обходятся. Всё из практики проведения пентестов.
Что мы на самом деле спрашиваем на scope-звонке
Нормальный пентест начинается с установочного звонка на 30–60 минут. Чем точнее вы ответите на эти вопросы заранее, тем дешевле и полезнее выйдет работа. Вот о чём мы спрашиваем:
- Чего вы боитесь больше всего? Утечка базы клиентов, остановка продаж, доступ к деньгам, компрометация через подрядчика. От ответа зависит, куда мы бьём в первую очередь.
- Что для вас «катастрофа», а что «неприятно»? Так мы калибруем, какие находки для вас критичны, а какие просто фоновый шум.
- Какие две-три системы нельзя потерять ни при каких условиях? Лучше глубоко протестировать критичное, чем поверхностно всё подряд.
- Есть ли системы, которые нельзя трогать? Старый сервер на Windows Server 2008, который «упадёт, если на него дыхнуть», продакшн-платежи, инфраструктура арендодателя.
- Кто знает о тесте? Ваша служба мониторинга (SOC) в курсе? Это отдельное решение, о нём ниже.
- Что уже проверяли и что нашли? Предыдущие отчёты экономят нам время, а вам деньги.
Совет из практики. Приходите на звонок не с «протестируйте нам безопасность», а с одним предложением: «Если хакер уведёт X, нам конец». Эта фраза экономит недели и десятки процентов бюджета, потому что превращает размытый заказ в конкретную цель.
Техническое задание на пентест и границы (scope): как выглядит хороший документ
Scope — это не «наш сайт», а точный письменный перечень целей и правил. Плохой scope («проверьте наш периметр») приводит к спорам и потерянному времени. Хороший выглядит примерно так:
Обратите внимание на строчки, которые чаще всего забывают: что вне границ, окна тестирования и решение по WAF. Именно из-за них потом срываются проекты.
Тестировать с WAF или без — решите заранее
Это развилка, которую мало кто продумывает до старта, а она определяет половину результата. Вариантов два.
- Пентестеры в allow-list, WAF для нас отключён. Тогда мы тестируем само приложение и его код и находим максимум реальных дыр. Это выбор по умолчанию, если вопрос звучит как «насколько безопасно наше приложение».
- WAF включён. Мы тестируем связку «приложение + WAF» как единый рубеж. Реалистичнее имитирует внешнего атакующего, но часть бюджета уходит на обход WAF, а не на поиск уязвимостей в коде. Найденные дыры при этом всё равно останутся в приложении, просто прикрытыми.
Рекомендуем делать оба, но по очереди. Сначала с allow-list, чтобы найти и починить реальные уязвимости. Потом, обычно на ретесте, с WAF, чтобы проверить, насколько он прикрывает то, что не успели закрыть. Тестировать только «через WAF» — значит платить за то, чтобы не узнать о собственных дырах.
Модель доступа: что готовить под black / grey / white
От модели пентеста зависит, что именно вам нужно подготовить.
- Blackbox. Готовить почти нечего, только цель. Но заложите, что часть времени уйдёт на разведку, а не на эксплуатацию.
- Greybox (рекомендуем в большинстве случаев). Заведите учётные записи, и обязательно по два аккаунта на каждую роль. Два обычных пользователя нужны, чтобы проверить, видит ли пользователь A данные пользователя B. Это тест на IDOR, самую частую критичную находку. Одного аккаунта для этого мало.
- Whitebox. Доступ к исходному коду (репозиторий на чтение), схемы архитектуры, конфигурации. Хорошо сочетается с аудитом исходного кода.
Технические доступы и тестовые данные
- Учётные записи нужных ролей (по 2 на роль для greybox), заведённые заранее и проверенные.
- Тестовые данные, которые не жалко. Заведите тестовый заказ, тестового клиента, тестовую карту платёжной системы. Тогда мы безопасно покажем, например, доступ к чужому заказу, не трогая реальных клиентов и не нарушая 152-ФЗ.
- Доступ во внутреннюю сеть для внутреннего пентеста: VPN или, что реалистичнее, наш ноутбук либо агент в вашем сегменте (модель «злоумышленник уже внутри»).
- Стенд или прод. Боитесь за прод? Разверните копию (staging), максимально идентичную боевой. Но помните: разница в конфигурации стенда и прода — источник ложного чувства безопасности. В идеале тестируют прод по аккуратным правилам.
- Allow-list по IP для наших адресов в WAF/IPS, если решили тестировать приложение, а не WAF. Список пришлём заранее.
Юридическая часть: что должно быть в разрешении на тестирование
Пентест без письменного разрешения — это уголовная статья, а не услуга. «Authorization to test» (разрешение на тестирование) — обязательный документ. Проверьте, что в нём есть всё нужное:
- Точные цели — те же домены и IP, что в scope, без «и всё остальное».
- Временное окно с конкретными датами и часами.
- Разрешённые техники: что можно, а что нельзя (DoS, социнженерия, физдоступ).
- Подпись человека, который вправе это разрешить, именно владельца систем, а не «менеджера, который договорился». Тестируете облако? Отдельно проверьте, не нужно ли уведомление или разрешение провайдера: у крупных облаков свои правила пентеста.
- NDA в обе стороны: мы не разглашаем ваши уязвимости, вы — наши методики.
Предупреждать ли свою службу мониторинга (SOC)?
Ещё одно стратегическое решение, и у него два одинаково рабочих варианта.
- Предупредить. Тест пройдёт гладко, без ложных тревог и блокировок. Подходит, когда цель — найти уязвимости.
- Не предупреждать. Заодно проверяете, заметит ли ваша защита реальную атаку. Это уже элемент Purple Team. Ценно, но требует, чтобы один-два доверенных человека знали о тесте. Иначе рискуете получить настоящее инцидент-реагирование против собственных пентестеров.
Три ошибки, которые дорого стоят
1. «Починить всё за неделю до пентеста»
Классика. Компания в спешке патчит и закрывает всё перед тестом, пентест находит мало, отчёт получается «чистый», а через месяц всё возвращается. Вы заплатили за подтверждение временного состояния. Правильно наоборот: тестируйте как есть, чтобы увидеть реальную картину и системные проблемы процесса.
2. «Протестируйте всё»
Размытый scope на «весь периметр без приоритетов» распыляет бюджет тонким слоем. Лучше глубоко пройти две-три критичные системы, чем поверхностно двадцать. Остальное закроет регулярное сканирование.
3. Забыть про сроки и лид-тайм
Пентест — это не «завтра начали». Реалистичный тайминг:
Если тест нужен к дедлайну (тендер, требование заказчика, релиз), начинайте согласование минимум за месяц.
Чек-лист «за день до старта»
- Scope и «что нельзя» зафиксированы письменно, обе стороны согласны.
- Подписаны договор, NDA и разрешение на тестирование.
- Учётные записи заведены и проверены (по 2 на роль для greybox).
- Тестовые данные созданы, критичные системы забэкаплены.
- Решение по WAF принято, наши IP при необходимости в allow-list.
- Окна тестирования и контакты для экстренной связи согласованы.
- Провайдер или хостинг уведомлён, если требуется; SOC — по вашему решению.
Не уверены, что из этого нужно именно вам? В этом и смысл бесплатной консультации: мы проводим scope-звонок, задаём правильные вопросы и сами составляем границы, правила и список доступов. Вам не нужно знать всё заранее, нужно знать, что для вас критично.
Планируете пентест?
Проведём бесплатный scope-звонок, поможем правильно задать цели и границы и проведём тест так, чтобы каждый час бюджета работал на результат.
Читайте также: Что такое пентест, Blackbox, greybox, whitebox, Пентест vs сканирование.
Профильные услуги SecurityLab: тестирование на проникновение · пентест веб-приложений · Аудит облачной безопасности.