Тестированием на проникновение, или пентестом, называют разрешённую имитацию атаки на систему. Её проводят так, как действовал бы реальный противник, чтобы найти и подтвердить слабые места раньше злоумышленника. Ключевое слово здесь «подтвердить»: пентест доказывает, что проблему можно эксплуатировать, вместо того чтобы лишь отметить её как возможную.
Ключевое отличие, описанное в NIST SP 800-115, в том, что тест на проникновение активно эксплуатирует слабое место, чтобы подтвердить его, а не только сообщает о возможной уязвимости. Поэтому хороший пентест отсекает ложные срабатывания сканера: у каждой находки есть доказательство. Обратная сторона в том, что это ограниченная по времени проверка на конкретный момент. Она отражает систему в том состоянии, в каком её тестировали в согласованный период.
Большинство проектов идут по признанному процессу, например Penetration Testing Execution Standard (PTES) или четырём фазам NIST SP 800-115: планирование, разведка, атака и отчётность. Из фазы атаки работа возвращается к разведке, когда новый доступ открывает новые пути. Начинается всё с определения объёма и правил проведения работ (а у Vexaro ещё и с NDA до любого доступа), а заканчивается отчётом с приоритетами. У нас в работу также входит бесплатное повторное тестирование исправлений в срок, указанный в SoW.
Пентест всегда привязан к цели: веб-приложению (по OWASP Web Security Testing Guide), API (OWASP API Security Top 10), мобильному приложению (OWASP MASVS/MASTG), внутренней или внешней сети или конфигурации облака. Разные цели требуют разных методов (веб-чек-лист, применённый к API, упускает большую часть реального риска), поэтому и услуги разделены по целям.
Тестировщик может работать без предварительных знаний (black-box), с частичными знаниями вроде учётных данных и спецификации (grey-box) или с полными, включая исходный код и архитектуру (white-box). Чем больше информации, тем глубже покрытие за то же время, поэтому выбирать стоит по нужному уровню уверенности, а не по тому, какой вариант звучит серьёзнее. Для большинства работ с приложениями и API экономически разумной нормой остаётся grey-box.
Это авторизованная, симулированная атака, проводимая так, как действовал бы реальный противник, чтобы подтвердить эксплуатируемые слабости, а не просто отметить возможные: по NIST SP 800-115 пентест активно эксплуатирует слабость, чтобы доказать, что она существует. Это ограниченное по времени упражнение, отражающее состояние системы в согласованном окне тестирования.
Большинство проектов идут по признанному процессу, например PTES или четырём фазам NIST SP 800-115: планирование, разведка, атака и отчётность. Всё начинается с определения границ и правил проведения работ (в Vexaro ещё и с NDA до любого доступа) и заканчивается отчётом с приоритизированными находками, а у нас также бесплатным повторным тестом исправлений в срок, указанный в SoW.
Пентест всегда привязан к цели (веб-приложению, API, мобильному приложению, сети или конфигурации облака), потому что разные цели требуют разных методов. Тестировщик может начать без знаний (black-box), с частичными знаниями вроде учётных данных и спецификации (grey-box) или с полным доступом к исходному коду и архитектуре (white-box). Выбор зависит от нужного уровня уверенности, а не от того, какой вариант звучит серьёзнее.