Пентест — это проверка заранее согласованного контура. Им может быть веб‑приложение, API, внешний периметр, внутренняя инфраструктура, беспроводная сеть или другой объект, который стороны включили в scope.
Команда пытается обойти механизмы защиты и проверить, можно ли использовать обнаруженные недостатки для проникновения, повышения привилегий, доступа к данным или развития атаки внутри согласованного контура.
Из этого следует ограничение, которое полезно зафиксировать до закупки: результаты относятся только к тому, что реально тестировалось. Если в scope входило одно веб‑приложение, выводы нельзя автоматически переносить на всю инфраструктуру. Если мобильное приложение или часть API исключены, они остаются вне оценки.
Пентест также не заменяет анализ уязвимостей, проверку конфигураций, анализ исходного кода или оценку архитектуры. В конкретном проекте эти работы могут дополнять друг друга, но отвечают на разные вопросы.
scope = объекты + функции + интерфейсы + роли + ограничения
результат пентеста = выводы только в пределах согласованного scope
Количество IP — слабая единица измерения
На предварительной оценке логично спросить число доменов, IP‑адресов, приложений, API и сетевых сегментов. Проблема возникает, когда эти числа становятся единственным способом оценить трудоемкость.
За одним IP может находиться небольшой ресурс без авторизации. За другим — платформа с личными кабинетами, административной панелью, загрузкой файлов, десятками методов API, интеграциями и несколькими типами пользователей.
Формально в обоих случаях объект можно описать как «один сайт» или «один IP». Но число сценариев, которые придется проверить вручную, будет различаться.
Поэтому на объем работ сильнее влияет поверхность атаки: совокупность компонентов, функций и интерфейсов, через которые нарушитель потенциально может воздействовать на систему. При ее оценке учитываются не только узлы, но и связи между ними: веб‑приложения, API, сервисы авторизации, интеграции, облачные компоненты и другие точки взаимодействия.
Пользовательские роли быстро увеличивают число сценариев
Для системы с авторизацией мало проверить, что пользователь может войти. Нужно убедиться, что после входа он способен выполнять только разрешенные действия.
Предположим, в сервисе есть клиент, оператор, руководитель подразделения и администратор. Тогда появляется отдельная группа проверок разграничения доступа: может ли обычный пользователь вызвать административную функцию, открыть чужой профиль или получить данные другой организации.
Часть таких проблем автоматический сканер не обнаружит, потому что они проявляются в бизнес‑логике и последовательности действий. Чем больше ролей, функций и комбинаций прав, тем больше ручных сценариев приходится исследовать.
Именно поэтому две системы с похожим внешним периметром могут значительно различаться по объему тестирования.
Black Box, Grey Box и White Box отвечают на разные вопросы
Еще один параметр оценки — объем исходной информации, которую получает команда. Black Box, Grey Box и White Box иногда воспринимают как три уровня «качества» проверки, но это некорректно. Формат выбирают под модель нарушителя и задачу.
Нельзя сказать, что White Box всегда «лучше» Black Box. Если задача — смоделировать внешний доступ без исходных сведений, Black Box точнее соответствует вопросу. Если нужно проверить действия пользователя с определенными правами, команде могут предоставить тестовые учетные записи и часть информации о системе — такой подход соответствует Grey Box. Внешний или внутренний характер пентеста при этом определяется отдельно исходя из стартовой позиции моделируемого нарушителя.
В одном проекте форматы могут комбинироваться: например, внешний периметр исследуется с минимумом исходной информации, а внутренний — с использованием предоставленных учетных записей.
Глубина проверки определяется не количеством найденных CVE
Фраза «проверить сайт на уязвимости» может описывать очень разный объем работ. В одном случае речь идет о поиске очевидных технических недостатков, в другом — о ручном исследовании бизнес‑логики и построении цепочек атаки.
Отдельная уязвимость может выглядеть умеренно опасной, но несколько недостатков способны последовательно дать более серьезный сценарий: сначала компрометацию учетной записи, затем повышение привилегий и доступ к закрытым данным.
Проверка таких связок требует ручного анализа. Специалисту нужно не только увидеть отдельную находку, но и установить, можно ли связать ее с другими недостатками в реализуемый сценарий.
При этом цель пентеста — подтвердить риск, а не нанести системе максимальный ущерб. Для демонстрации последствий обычно не требуется выгружать большой массив реальных данных, нарушать доступность системы или доводить эксплуатацию до максимально возможного результата. Допустимую глубину проверки согласуют заранее.
Rules of Engagement нужно согласовать до начала тестирования
Пентест активен по своей природе, поэтому до начала стороны определяют Rules of Engagement: что разрешено делать с системой и где проходит граница допустимого воздействия.
В правилах фиксируются периметр, разрешенные методы, временные окна, ограничения по нагрузке, порядок экстренной остановки и действия при обнаружении критичной уязвимости.
Для чувствительной системы ограничения могут быть жестче: часть методов запрещается, потенциально опасные действия требуют отдельного согласования, тестирование допускается только в определенные периоды.
Это снижает эксплуатационный риск, но одновременно влияет на методику и организационную трудоемкость. Команда уже не может действовать так же свободно, как реальный нарушитель, и должна строить сценарии в заданных границах.
Особенно осторожно планируется работа с продуктивной средой. Тестовый контур уменьшает часть рисков, но полезен только если достаточно точно воспроизводит значимые свойства рабочей системы.
В качестве ориентиров при планировании технических проверок можно использовать NIST SP 800–115 и OWASP Web Security Testing Guide. При этом программа конкретного пентеста должна учитывать архитектуру и функции проверяемого объекта.
Распределенная инфраструктура добавляет организационные зависимости
В распределенной инфраструктуре одинаковые по назначению системы в филиалах могут отличаться конфигурацией, подключением и уровнем доступа. Поэтому scope приходится описывать не только списком узлов, но и по площадкам.
До оценки такого проекта нужно определить, какие системы и площадки входят в периметр, кто предоставляет доступы, какие работы выполняются удаленно, а где требуется присутствие на площадке, в какие окна допустимо тестирование и как отзываются выданные учетные записи.
Отдельно согласуются формат отчетности и порядок уведомления о критичных уязвимостях. Для распределенной компании внешний и внутренний пентест могут охватывать разные площадки и требовать отдельного согласования границ.
Внешний и внутренний пентест моделируют разные стартовые позиции
Внешний пентест показывает, какие сценарии доступны со стороны публичного периметра. Внутренний моделирует действия нарушителя, который уже получил доступ к корпоративной сети или находится в заданной позиции внутри инфраструктуры.
Это различие влияет и на scope, и на исходные данные, и на способы доступа к тестируемым системам. Поэтому предложение «проверить инфраструктуру» без указания стартовой позиции нарушителя остается слишком неопределенным для корректной оценки.
Отчет — часть результата, которая тоже стоит времени
Иногда коммерческие предложения сравнивают по количеству часов непосредственного тестирования. Но после завершения проекта заказчику нужен не список технических находок, а воспроизводимый результат.
Техническая команда должна понимать, где обнаружена проблема, при каких условиях она воспроизводится и что требуется изменить. Руководству нужен другой срез: какие сценарии наиболее опасны, на какие процессы они влияют и что исправлять в первую очередь.
Полноценный отчет обычно включает:
· область, сроки и ограничения проверки;
· использованную модель нарушителя;
· подтвержденные уязвимости и доказательства;
· возможные сценарии и последствия;
· оценку критичности и, при необходимости, приоритет для конкретной организации;
· рекомендации по устранению;
· описание выявленных цепочек атак;
· ограничения, которые повлияли на полноту результатов.
Для оценки уязвимостей может использоваться CVSS. Но базовый балл CVSS не является готовой оценкой риска для конкретной организации: при приоритизации исправлений дополнительно учитываются контекст системы, актуальные угрозы и возможные последствия.
Ретест нужно согласовать до старта
После исправления уязвимостей проводится ретест: повторная проверка подтверждает, что ранее выявленная проблема устранена и исходный сценарий больше не воспроизводится в согласованном объеме.
Ретест обычно не равен новому полному пентесту. Он сосредоточен на ранее найденных недостатках. Но в коммерческом предложении важно заранее увидеть, входит ли он в стоимость, сколько циклов предусмотрено и в какой срок может быть проведен.
Если одно предложение включает ретест и помощь с разбором результатов, а другое заканчивается передачей первичного отчета, сравнение только итоговых сумм не показывает, какое предложение фактически объемнее.
Срочность меняет организацию работ, но не отменяет последовательность анализа
Календарная длительность проекта состоит не только из технического тестирования. До начала работ нужно выдать доступы, подготовить тестовые учетные записи, согласовать ответственных и зафиксировать Rules of Engagement.
При жестком сроке подрядчику может потребоваться больше специалистов и параллельное выполнение части этапов. При этом сложную бизнес‑логику и цепочки воздействия не всегда можно безопасно распараллелить.
Есть и обратная ситуация: технический объем невелик, но проект растягивается из‑за задержек с доступами или согласованием действий. Поэтому трудоемкость и календарную продолжительность полезно оценивать раздельно.
Как привести предложения подрядчиков к одной системе координат
Чтобы разброс цен стал объяснимым, перед запросом оценки имеет смысл подготовить единое описание задачи. Это не полноценная программа пентеста, а минимальный набор вводных, который позволяет подрядчикам считать один и тот же проект.
1. Перечень приложений, адресов, API и сетевых сегментов, которые входят в scope.
2. Пользовательские роли и доступы, которые нужно проверить.
3. Наличие тестовой среды и ее соответствие рабочей системе.
4. Функции и данные, которые считаются критичными.
5. Модель нарушителя: внешний, внутренний или другой согласованный сценарий.
6. Запрещенные действия и иные ограничения Rules of Engagement.
7. Требования к отчету и оперативному уведомлению о критичных находках.
8. Необходимость ретеста и число согласованных циклов.
После этого можно отдельно сравнивать долю ручных проверок, подход к валидации результатов сканеров, квалификацию команды, методику тестирования, порядок защиты полученных доступов и данных.
Автоматические инструменты полезны для поиска типовых технических проблем, но не заменяют ручную проверку бизнес‑логики, разграничения прав и сложных цепочек воздействия. Поэтому количество запущенных сканеров само по себе не является метрикой качества пентеста.
Что в итоге определяет стоимость пентеста
Стоимость проекта складывается из объема фактической работы, а не из одного формального показателя. На цену влияют периметр, число функций и пользовательских ролей, формат Black/Grey/White Box, глубина ручного анализа, ограничения Rules of Engagement, состав отчета, ретест и организационные условия проекта.
Это объясняет, почему два предложения на «пентест одной системы» могут существенно различаться и при этом оба быть обоснованными: исполнители могли оценить разные scope, модели нарушителя и глубину проверки.
Практический критерий сравнения простой: до обсуждения цены нужно привести предложения к одинаковым четырем вопросам — что именно проверяется, из какой стартовой позиции действует нарушитель, насколько глубоко разрешено идти и какой результат должен получить заказчик.
Пока эти параметры не совпадают, сравниваются не цены на один и тот же пентест, а разные технические проекты с одинаковым названием.
ссылка на оригинал статьи https://habr.com/ru/articles/1091142/