Сколько стоит пентест: что входит в проверку и от чего зависит цена

Пентест, или тестирование на проникновение, — это контролируемая проверка защищенности информационной системы, приложения или инфраструктуры с использованием методов, которые могут применять реальные злоумышленники.

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

В терминологии NIST пентест предполагает поиск и проверку возможности использования уязвимостей в программах для компрометации приложения, данных приложения или окружения системы. При этом внимание может уделяться не только отдельным уязвимостям, но и их комбинациям, которые позволяют получить более высокий уровень доступа. Подробнее — в публикации NIST SP 800−12 в разделе penetration testing.

Пентест показывает состояние объектов тестирования в определенный период и при согласованной модели проверки. Он не подтверждает отсутствие всех возможных уязвимостей и не гарантирует, что система останется защищенной после изменений в коде, конфигурации или инфраструктуре.

Автоматическое сканирование и тестирование на проникновение решают связанные, но разные задачи.

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

NIST рассматривает тестирование безопасности как совокупность методов с разными возможностями и ограничениями, а не как одну универсальную процедуру. Рекомендации по планированию, проведению и анализу результатов приведены в публикации NIST SP 800−115, опубликованной в 2008 году.

Объект тестирования определяется до начала работ. В зависимости от задачи в него могут входить:

• внешний сетевой периметр;
• веб-приложения;
• API;
• мобильные приложения;
• внутренняя инфраструктура;
• службы каталогов и доменная инфраструктура;
• беспроводные сети, сетевое оборудование;
• операционные системы и прикладное программное обеспечение;
• отдельные серверы, сервисы и сетевые сегменты;
• механизмы идентификации, аутентификации и разграничения доступа;
• облачная инфраструктура и доступные извне облачные сервисы.

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

Нельзя автоматически распространять результаты проверки одного приложения на всю инфраструктуру компании. Если в область тестирования вошел только конкретный сервис, выводы относятся прежде всего к нему и к согласованным точкам взаимодействия.

Проверка одного веб-приложения и тестирование распределенной инфраструктуры — разные по объему задачи. На трудоемкость влияют:

• количество доменов, IP-адресов и сетевых сегментов;
• число приложений и API;
• наличие мобильных клиентов;
• количество сред и вариантов развертывания;
• состав информационных систем внешнего и внутреннего периметра;
• количество пользовательских ролей.

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

Чем больше функций, ролей и бизнес-процессов необходимо проверить, тем больше сценариев предстоит проанализировать.

Объектами исследования могут являться:

• механизмы регистрации и восстановления доступа;
• ролевой механизм разграничения доступа;
• личные кабинеты;
• административная панель;
• механизмы обработки и загрузки файлов;
• платежные или иные критичные операции;
• интеграции со сторонними системами;
• методы API;
• правила разграничения полномочий.

Совокупность перечисленных и иных объектов исследования формирует оценку сложности приложения.

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

Для веб-приложений ориентиром при формировании программы проверки может выступать OWASP Web Security Testing Guide. Руководство содержит систематизированные сценарии тестирования веб-приложений и веб-сервисов, однако конкретный перечень проверок должен учитывать архитектуру и функции исследуемой системы.

Объем доступной специалистам информации влияет на методику и трудоемкость проекта.

Black Box — тестирование с минимальными исходными сведениями об объекте. Такой формат в большей степени воспроизводит действия внешнего нарушителя, который начинает с доступной из открытых источников информации.

Grey Box — сценарий, предполагающий что специалисты получают часть сведений или ограниченный доступ: например, тестовые учетные записи пользователей с разными ролями. Это позволяет глубже проверить механизмы авторизации, разграничение прав и внутреннюю логику приложения.

White Box — формат, в рамках которого команде предоставляется расширенная информация об архитектуре, конфигурации или реализации системы. В зависимости от задачи могут передаваться схемы взаимодействия, документация, настройки и исходный код.

Эти подходы не являются уровнями качества. Выбор зависит от цели. Иногда в одном проекте используются разные модели: например, внешний периметр проверяют в формате Black Box, а приложение — с тестовыми учетными записями.

Запрос «проверить сайт» может означать разные задачи:

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

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

При этом глубина эксплуатации должна быть ограничена целями проверки. Для подтверждения риска не всегда требуется получать доступ к учетной записи с максимально возможным набором прав или выгружать реальные данные.

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

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

Чем жестче ограничения, тем тщательнее приходится планировать проверку и адаптировать к ним методику.

До начала тестирования обычно определяются Rules of Engagement — правила проведения работ. Согласно определению NIST, такой документ устанавливает ограничения и дает команде полномочия выполнять заранее согласованные действия.

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

На состав и детализацию отчета влияют:

• необходимость управленческого резюме;
• требования к описанию доказательств;
• детализация сценариев воспроизведения;
• привязка результатов к конкретным системам;
• описание возможных последствий;
• рекомендации по устранению;
• анализ цепочек атак;
• формат оценки серьезности уязвимостей;
• требования внутреннего контроля или регуляторов.

Уязвимостям может присваиваться оценка критичности по CVSS. При этом CVSS, особенно его базовая оценка, характеризует прежде всего тяжесть последствий эксплуатации, а не бизнес-риск для конкретной организации. Поэтому числовой балл следует дополнять контекстом: критичностью системы и данных, существующими защитными мерами, актуальностью угрозы и возможными последствиями для организации.

После устранения обнаруженных недостатков может проводиться ретест. Его задача — подтвердить в согласованном объеме проверки, что ранее выявленные уязвимости устранены и исходный сценарий больше не воспроизводится.

Ретест не следует автоматически приравнивать к новому полному пентесту. Обычно он сосредоточен на ранее выявленных проблемах. Проверка способов обхода исправлений и новых сценариев эксплуатации ранее выявленных уязвимостей зависит от заранее согласованных границ ретеста.

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

Задержка с предоставлением доступа может увеличить календарную продолжительность проекта, даже если технический объем остается прежним.

Точный состав зависит от объекта и согласованной методики, но проект обычно включает несколько этапов.

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

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

Согласовываются:

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

Специалисты изучают доступные компоненты, сервисы, функции и точки входа. Цель этапа — понять устройство исследуемого контура и сформировать релевантные сценарии проверки.

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

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

Результаты систематизируются по объектам и уровню риска. Для каждой подтвержденной уязвимости фиксируются доказательства, условия возникновения, возможные последствия и рекомендации по устранению.

После исправлений проводится повторная проверка согласованных уязвимостей. В итоговых материалах отмечается, какие проблемы устранены, какие сохранились и какие невозможно было проверить повторно.

Полезный отчет по пентесту обычно содержит:

• цели и область тестирования;
• перечень проверенных объектов;
• выбранную модель нарушителя;
• использованную методику;
• сроки и ограничения проверки;
• общее резюме результатов;
• перечень подтвержденных уязвимостей;
• оценку их критичности и, при необходимости, риска для конкретной организации;
• технические доказательства;
• описание возможного влияния;
• рекомендации по устранению;
• сведения о выявленных цепочках атак;
• ограничения, способные повлиять на полноту проверки;
• результаты ретеста, если он проводился.

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

Чтобы получить сопоставимую и обоснованную оценку, полезно заранее сформировать:

1. Цель проверки.
2. Перечень доменов, адресов, приложений, API и сетевых сегментов.
3. Краткое описание архитектуры.
4. Список пользовательских ролей.
5. Количество и назначение тестовых учетных записей.
6. Информацию о тестовой и продуктовой средах.
7. Перечень критичных функций и данных.
8. Предполагаемую модель нарушителя.
9. Разрешенные и запрещенные действия.
10. Требования к отчету.
11. Необходимость ретеста.
12. Желаемый период проведения работ.

Если точная инвентаризация еще не проведена, оценку можно начать с предварительного определения области тестирования. Однако до уточнения границ такая оценка будет ориентировочной.

Перед согласованием пентеста стоит уточнить:

• какие объекты и среды входят в проверку;
• какие объекты исключены;
• по какой методике будет работать команда;
• какие ручные проверки предусмотрены;
• как валидируются результаты сканеров;
• допустима ли проверка цепочек атак;
• как будет оцениваться критичность;
• что войдет в отчет;
• предусмотрено ли управленческое резюме;
• включен ли ретест и какие ограничения у него есть;
• как будут защищаться полученные данные;
• как команда сообщит о критической уязвимости;
• какие действия выполняются после завершения тестирования.

Эти вопросы помогают сравнивать не только итоговую стоимость, но и фактический состав работ.

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

Универсального срока нет. Продолжительность зависит от области проверки, сложности систем, количества ролей, доступности тестовой среды и согласованных ограничений. Календарный срок также может увеличиться из-за подготовки доступов и согласования отдельных действий.

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

Не во всех случаях. При Black Box и Grey Box исходный код обычно не является обязательным условием. В White Box-проверке он может использоваться вместе с архитектурной и технической документацией. Выбор формата зависит от цели тестирования.

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

Нет. Результаты относятся к согласованной области, условиям и времени проведения проверки. Часть объектов или методов может быть исключена, а после обновлений и изменений инфраструктуры могут появиться новые недостатки.

Единой периодичности для всех организаций нет. Решение принимается с учетом рисков, требований регуляторов и контрагентов, критичности систем и характера изменений. Повторная проверка особенно актуальна после существенного изменения архитектуры, появления новых внешних сервисов, крупных обновлений или инцидентов безопасности.

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

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