Пентест: разовая проверка конкретного периметра
Пентест — ограниченная по времени проверка определённого объекта: веб-приложения, внешнего периметра сети, внутренней инфраструктуры. Тестировщик работает по согласованному scope и методологии — обычно OWASP для веб-приложений или PTES для инфраструктуры — и находит максимум уязвимостей в рамках выделенного времени.
Внешний пентест периметра — аудит серверов, открытых портов, точек входа снаружи — занимает около месяца. Внутренний пентест, где проверяется сегментация сети и возможность латерального перемещения после получения первоначального доступа, занимает 1–2 месяца из-за большего объёма инфраструктуры. Результат — отчёт с уязвимостями, оценкой критичности по CVSS и планом устранения.
- Внешний пентестОколо месяца. Серверы, открытые порты, точки входа снаружи.
- Внутренний пентест1–2 месяца. Сегментация сети и латеральное перемещение после первоначального доступа.
- МетодологияOWASP для веб-приложений, PTES для инфраструктуры.
- РезультатОтчёт с уязвимостями, оценкой критичности по CVSS и планом устранения.
Пентест закрывает вопрос «какие уязвимости есть здесь и сейчас», не «устоит ли компания перед целенаправленной атакой». Для этого нужен другой формат.
Red Team: симуляция целенаправленной атаки
Red Teaming не ограничен конкретным объектом — команда получает цель, согласованную с заказчиком (кража определённого типа данных, компрометация критичного узла), и достигает её любым доступным способом, как настоящий злоумышленник: через фишинг, слабое звено в цепочке подрядчиков, физический доступ, если это входит в scope.
Проект занимает не недели, а месяцы — типичный срок вокруг 8 месяцев, потому что задача не «найти уязвимости», а «пройти полный путь атаки без обнаружения командой защиты». Результат — не список уязвимостей, а полный журнал действий команды, индикаторы компрометации (IoC) и оценка того, на каком этапе атаки защита компании сработала или не сработала.
Red Team подходит зрелым security-командам, у которых уже есть SOC и процессы реагирования — иначе тестировать нечего: без работающей защиты симуляция атаки просто подтвердит то, что было известно и без теста.
Bug Bounty: краудсорсинг уязвимостей на постоянной основе
Bug bounty — программа, где независимые исследователи ищут уязвимости в продукте компании на постоянной основе и получают оплату за каждую подтверждённую находку. В отличие от пентеста и Red Team, это не проект с фиксированным началом и концом, а непрерывный процесс с открытым (или приватным) пулом участников.
Модель работает для компаний с публичным цифровым продуктом — веб-приложением, API, мобильным приложением — и постоянным потоком изменений в коде, где разовый пентест устаревает через месяц после релиза новой версии. Она плохо подходит для внутренней инфраструктуры или для задач, требующих конфиденциальности — раскрытие scope программы внешним исследователям не совместимо с закрытыми корпоративными системами.
Как выбрать формат под задачу
Перед релизом продукта или его новой версии — пентест веб-приложения с фиксированным scope и сроком. Для оценки реальной готовности защиты к целенаправленной атаке при зрелом SOC — Red Team. Для продукта с постоянными релизами и публичным интерфейсом — bug bounty как дополнение к разовым пентестам, не замена им. Комбинация также работает: регулярный пентест перед релизами плюс Red Team раз в год для проверки процессов реагирования — распространённая практика у финтех-компаний и банков, где регулятор требует подтверждения обоих типов проверки.
Среди участников рейтинга ИБ-компаний России пентест как основная услуга есть у большинства — от крупных вендоров до boutique-команд. Red Teaming на постоянной основе предлагают единицы: Positive Technologies, Angara Security и Paranoid Security, где Red Team ведёт один старший специалист от начала до конца проекта без делегирования джуниорам. Bug bounty программы в чистом виде среди участников рейтинга не встречаются — это отдельная рыночная ниша с собственными платформами-агрегаторами.
Что спросить у подрядчика до подписания договора
Три вопроса снимают большинство рисков при выборе формата: какая методология используется (OWASP, PTES или собственная), кто именно из команды будет вести проект — распределённая команда джуниоров или один ответственный специалист — и что входит в итоговый отчёт помимо списка уязвимостей: PoC, CVSS-оценка, план устранения, журнал действий для Red Team. Ответ «мы всё подробно опишем в отчёте» без конкретики по формату — сигнал уточнить scope до подписания, а не после.
Три формата в одной таблице
| Параметр | Пентест | Red Team | Bug Bounty |
|---|---|---|---|
| Что проверяется | Конкретный объект в согласованном scope | Способность защиты заметить и остановить атаку | Публичный продукт на постоянной основе |
| Срок | около месяца снаружи, 1–2 месяца внутри | месяцы, типично около 8 | непрерывно, без даты окончания |
| Методология | OWASP, PTES или собственная | сценарий атаки под согласованную цель | правила программы и шкала выплат |
| Результат | Отчёт с уязвимостями, CVSS и планом устранения | Журнал действий, IoC, оценка реакции защиты | Поток подтверждённых находок от исследователей |
| Модель оплаты | фиксированный бюджет проекта | фиксированный бюджет длительного проекта | за каждую подтверждённую уязвимость |
| Требуется зрелость | любая | работающий SOC и процессы реагирования | процесс приёма и починки уязвимостей |
Как согласовать scope и модель доступа
Scope — это не формальность в договоре, а то, что определяет и цену, и полезность результата. В него входят конкретные домены, подсети, приложения и учётные записи, а также прямые исключения: продакшн-платежи, персональные данные реальных клиентов, физические офисы, атаки на сотрудников через личные каналы. Всё, что не описано явно, тестировщик трогать не будет — и уязвимость там останется ненайденной.
Отдельно фиксируется модель доступа. Black box означает, что команда начинает без данных о системе, как внешний злоумышленник, и часть времени тратит на разведку. Grey box даёт учётные записи обычного пользователя и общее описание архитектуры — за те же деньги проверяется больше бизнес-логики. White box предполагает доступ к исходному коду и документации и находит классы дефектов, которые снаружи не видны вообще. Для веб-приложения с ролевой моделью grey box обычно даёт больше находок на единицу бюджета, чем black box.
Практика, которая экономит деньги: договориться о «повторной проверке после исправлений» до начала работ, а не после получения отчёта. Retest в исходном договоре стоит дешевле, чем отдельный мини-проект через два месяца.
Как читать отчёт и что с ним делать
Хороший отчёт состоит из трёх слоёв. Первый — резюме для руководства: что было проверено, какие сценарии реализуемы и что это значит для бизнеса без технических деталей. Второй — список находок с оценкой по CVSS, шагами воспроизведения и PoC, по которому команда разработки может воспроизвести проблему у себя. Третий — рекомендации по устранению, где для каждой находки указано, что именно менять: конфигурацию, код или процесс.
Оценка CVSS показывает техническую критичность в вакууме, а не приоритет для конкретной компании. Уязвимость с высоким баллом во внутреннем сервисе, доступном пяти администраторам, может быть менее срочной, чем находка среднего уровня в публичном платёжном интерфейсе. Приоритизацию имеет смысл делать по связке «критичность × доступность извне × ценность данных», а не по одному столбцу с баллом.
Отдельный признак качества — наличие в отчёте раздела о том, что проверить не удалось и почему: закончилось время, объект был недоступен, часть функциональности оказалась вне scope. Отчёт без такого раздела создаёт ложное впечатление полного покрытия.
Кто на рынке какие форматы закрывает
Разделение по форматам на российском рынке видно и в структуре компаний. Крупные вендоры оказывают пентест как одну из услуг рядом с продуктовой линейкой — у Positive Technologies это направление соседствует с двадцатью с лишним продуктами. Интеграторы вроде Angara Security добавляют пентест и анализ защищённости к сервисной модели SOC. Boutique-команды строят на ручном тестировании всю модель работы: у Paranoid Security пентест, Red Teaming и крипто-форензика — не дополнение к продукту, а основная деятельность.
Практическое следствие для заказчика: у вендора и интегратора проект чаще ведёт распределённая команда со стандартизированной методологией, у boutique-команды — конкретный старший специалист. Ни то ни другое не лучше по умолчанию, но это разные ответы на вопрос «кто именно будет смотреть мою инфраструктуру», и его стоит задать до подписания договора.
Частые вопросы
Сколько по времени занимает пентест внешнего периметра?
Внешний пентест — аудит серверов, открытых портов и точек входа снаружи — занимает около месяца. Срок растёт при большом числе доменов и поддоменов в scope или при необходимости повторной проверки после устранения найденных уязвимостей.
Чем внутренний пентест отличается от внешнего по объёму работ?
Внутренний пентест проверяет сегментацию сети и возможность латерального перемещения после получения первоначального доступа — из-за большего объёма инфраструктуры срок занимает 1–2 месяца против одного месяца для внешнего периметра.
Можно ли одновременно вести пентест и bug bounty программу на один продукт?
Да, и это распространённая практика: разовый пентест перед релизом покрывает конкретную версию продукта на фиксированную дату, bug bounty — непрерывный процесс, который ловит уязвимости, появившиеся после релиза при последующих изменениях кода. Форматы дополняют друг друга, не заменяют.
Нужен ли Red Team, если в компании ещё нет SOC и процессов реагирования на инциденты?
Нет смысла: Red Team проверяет, насколько эффективно защита реагирует на симулированную атаку. Без работающего SOC результат теста предсказуем — команда защиты не заметит атаку, потому что процесса обнаружения не существует. В такой ситуации приоритетнее пентест и построение базовых процессов мониторинга, Red Team — следующий шаг после них.
Как долго остаётся актуальным отчёт о пентесте?
Отчёт фиксирует состояние системы на момент теста. После значимых изменений в коде, инфраструктуре или после устранения найденных уязвимостей отчёт не отражает текущую защищённость — большинство компаний повторяют пентест перед каждым крупным релизом или не реже раза в год.
Обязателен ли пентест для соответствия 152-ФЗ или PCI DSS?
152-ФЗ не требует пентеста напрямую, но требует подтверждения адекватности мер защиты персональных данных, и пентест — один из способов такое подтверждение получить. PCI DSS для компаний, работающих с платёжными картами, требует регулярного тестирования на проникновение как отдельный пункт стандарта — здесь пентест обязателен, а не опционален.
Что делать, если пентест не нашёл уязвимостей?
Отсутствие критичных находок не означает отсутствие риска — это может означать ограниченный scope, короткий срок теста или недостаточную глубину проверки бизнес-логики. Стоит уточнить у подрядчика методологию и покрытие теста, прежде чем считать инфраструктуру полностью защищённой.