Как читать отчёт о тестировании на проникновение

Из чего состоит хороший отчёт

Большинство профессиональных отчётов имеют предсказуемую структуру, и знание её позволяет быстро находить нужное. Резюме для руководства пишется для управленцев: границы, общий уровень риска и две-три главные темы. Раздел методологии указывает, какому стандарту следовал тест — чаще всего OWASP Web Security Testing Guide (WSTG) для веб-приложений, OWASP ASVS как базу верификации и PTES для хода всего проекта — а также даты, окружение и ограничения. Раздел находок — рабочее ядро: одна запись на проблему, каждая с уровнем критичности, вектором CVSS, доказательствами и способом исправления. Приложение обычно содержит детали границ, инструменты и элементы вне области работ.

• Резюме для руководства — для лиц, принимающих решения, без жаргона, общий риск и темы
• Границы и правила проведения — что именно тестировалось, когда и что было под запретом
• Методология — применённый стандарт (OWASP WSTG/ASVS, PTES, NIST SP 800-115)
• Находки — ранжированный список действий, в котором вы проведёте больше всего времени
• Приложения — доказательства, вывод инструментов и детали воспроизведения

Что на самом деле означают оценки CVSS v3.1

CVSS (Common Vulnerability Scoring System) v3.1 превращает набор характеристик в число 0.0–10.0 и соответствующий уровень критичности. Базовая оценка (Base) отвечает на вопрос «насколько плоха эта уязвимость в принципе» с помощью метрик, которые вы видите в векторе, например CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H (оценка 9.8). Читайте вектор, а не только число: Attack Vector (Network/Adjacent/Local/Physical), Attack Complexity, Privileges Required, User Interaction, Scope и влияние на Confidentiality/Integrity/Availability.

• 0.0 = None, 0.1–3.9 = Low, 4.0–6.9 = Medium, 7.0–8.9 = High, 9.0–10.0 = Critical
• AV:N (доступна по сети) намного срочнее, чем AV:L (нужен локальный доступ)
• PR:N + UI:N означает отсутствие входа и действий жертвы — считайте опаснее
• S:C (Scope: Changed) означает, что уязвимость выходит за пределы своего компонента и влияет на другие
• Базовая оценка вне контекста; хороший отчёт добавляет контекст окружения сверху

Уровень критичности — отправная точка, а не вся картина

Базовая оценка CVSS намеренно вне контекста — она не знает, что находка «High» находится на внутреннем административном инструменте, доступном только через VPN, или что «Medium» — на вашей публичной странице оплаты. Поэтому CVSS определяет также метрики окружения (Environmental), корректирующие оценку под ваше развёртывание (ценность актива, имеющиеся меры, экспозиция). Зрелый отчёт либо применяет эту корректировку, либо даёт бизнес-контекст, чтобы вы сделали это сами. Практическое правило: используйте уровень критичности от исполнителя для первичной сортировки, а затем переранжируйте по ценности актива и тому, кто может до него добраться.

• Medium на доступном из интернета неаутентифицированном эндпоинте может превзойти High на изолированной машине
• Компенсирующие меры (WAF, сегментация сети, MFA) реально снижают риск
• Цепочки находок важны: два Medium, складывающиеся в захват аккаунта, — это фактически Critical
• Попросите тестировщика объяснить любую оценку, с которой вы не согласны — обоснование должно быть прозрачным

Приоритизация устранения: риск × трудозатраты

Нельзя исправить всё сразу, и не нужно пытаться. Разместите каждую находку по двум осям: риск (критичность с поправкой на ваше окружение) и трудозатраты на устранение (часы, радиус влияния, риск развёртывания). Порядок, который защищает быстрее всего: сначала пункты высокого риска и низких затрат — быстрые победы, дёшево убирающие реальную экспозицию (отсутствующий заголовок безопасности, учётные данные по умолчанию, устаревшая зависимость с доступным патчем). Затем пункты высокого риска и высоких затрат получают запланированный проект и временную компенсирующую меру. Проблемы низкого риска и низких затрат объединяются в плановое обслуживание. Пункты низкого риска и высоких затрат — кандидаты на документированное принятие риска.

• Квадрант 1 — высокий риск, низкие затраты: делайте сейчас, это ваши срочные патчи
• Квадрант 2 — высокий риск, высокие затраты: планируйте и выделяйте ресурсы, добавьте временную меру
• Квадрант 3 — низкий риск, низкие затраты: включите в ближайшее окно обслуживания
• Квадрант 4 — низкий риск, высокие затраты: формально примите риск или отложите с владельцем и датой
• Назначьте каждой находке владельца и срок — находка без владельца никогда не будет исправлена

Proof of concept: доказательство, которому можно доверять

Proof of concept (PoC) — это демонстрация тестировщиком того, что уязвимость реальна и эксплуатируема, а не теоретична. Обычно он включает точный запрос или шаги, ответ или результат, доказывающий воздействие, и достаточно деталей, чтобы разработчики воспроизвели это в безопасной среде. Хороший PoC — это разница между «сканер это отметил» и «мы извлекли данные другого клиента этим запросом». Воспроизведите PoC сами на стенде до и после исправления — так вы подтверждаете и проблему, и решение, а не верите ни одному отчёту на слово.

• Ищите конкретный запрос/payload, наблюдаемый результат и шаги воспроизведения
• Скриншоты или захваченные ответы должны показывать воздействие, а не просто предупреждение инструмента
• PoC — это демонстрация, а не эксплуатация — профессиональный тест останавливается на доказательстве, не вооружая атаку
• Если у находки нет PoC и внятного обоснования, спросите, не false positive ли это

False positive и false negative

False positive — это заявленная проблема, которая в вашем контексте не эксплуатируема, например сканер помечает версию библиотеки как уязвимую, хотя уязвимый путь кода никогда не вызывается, или «отражённый ввод», который безопасно кодируется. Тестирование на проникновение, проводимое человеком, существует во многом для того, чтобы их устранять: реальный тестировщик проверяет каждую машинную подсказку, прежде чем она попадёт в отчёт. Более сложная проблема — false negative, реальная уязвимость, которую тест не нашёл. Ни один тест не доказывает отсутствие всех ошибок; поэтому важны границы, ограничение времени и прозрачность методологии, и поэтому тестирование периодическое, а не разовое.

• False positive = заявлено, но не реально/не эксплуатируемо; в проверенных отчётах их очень мало
• False negative = реальная проблема, которую пропустили; управляется границами, покрытием и повторными тестами
• Если считаете находку false positive, ответьте с доказательствами — тестировщики принимают исправление
• Прохождение без находок — не гарантия безопасности, а лишь того, что охватил этот тест

Ретест и верификация

Исправление находки — это заявление; верификация — доказательство. После устранения тестировщик повторно запускает исходный proof of concept против исправленной системы, чтобы подтвердить, что исправление держится и не просто переместило проблему в другое место. Большинство проектов включают раунд верификации в заданном окне (часто 30–90 дней). Результат — обновлённый отчёт, где каждый исправленный пункт помечен как проверенный/закрытый с датой ретеста, а всё ещё эксплуатируемое переоткрывается. Эта замкнутая запись — найдено, исправлено, перепроверено, закрыто — это именно то, что хотят видеть аудиторы и клиенты.

• Верификация повторяет исходный PoC, а не свежее общее сканирование
• Ожидайте статусы: Open, Remediated (заявлено клиентом), Verified/Closed и Risk Accepted
• Согласуйте окно ретеста до начала работ, чтобы исправления успели в него уложиться
• Частичное исправление должно быть переоткрыто — верификация защищает от регрессий «выглядит исправленным»

Использование отчёта для соответствия требованиям

Один и тот же отчёт поддерживает несколько стандартов, но каждый читает его по-своему. Для SOC 2 пентест — это доказательство для критериев безопасности Trust Services Criteria: аудиторы хотят видеть, что тест состоялся, находки отслеживались, а устранение управлялось. Для ISO 27001 он питает технические меры Приложения A (в частности A.8.8 управление техническими уязвимостями и A.8.25/A.8.29 безопасная разработка и тестирование безопасности в редакции 2022) и ваш процесс обработки риска. Для PCI DSS v4.0 тестирование на проникновение — жёсткое требование в рамках Требования 11.4, с определёнными границами (внешние и внутренние), ежегодной периодичностью, тестированием после значимых изменений и проверкой того, что средства сегментации действительно изолируют среду данных держателей карт.

• SOC 2 — подтверждает критерии безопасности; аудиторы проверяют тест + отслеживание + устранение
• ISO 27001:2022 — поддерживает Приложение A.8.8, A.8.25, A.8.29 и план обработки риска
• PCI DSS v4.0 — Требование 11.4: ежегодные + после изменений тесты, внутренние и внешние, проверка сегментации
• Дайте аудиторам отчёт вместе с трекером устранения и результатами верификации, а не один отчёт
• Сохраните заявление о границах — оно точно определяет, что оценка охватывает, а что нет

Частые ошибки, которых стоит избегать

Точка отказа — не отчёт, а то, что происходит после него. Команды, которые извлекают пользу из пентеста, относятся к находкам как к отслеживаемому бэклогу с владельцами и сроками, проверяют свои исправления и ретестируют по расписанию. Команды, которые этого не делают, обычно исправляют только Critical, подшивают отчёт для аудитора и через год заново открывают то же Medium. Две привычки важнее всего: никогда не позволяйте одному уровню критичности задавать порядок работ без поправки на экспозицию и никогда не помечайте что-либо как исправленное без верификации.

• Не исправляйте только Critical — сцепленные Medium приводят к реальным взломам
• Не относитесь к отчёту как к артефакту соответствия, который подшили и забыли
• Не сертифицируйте исправления сами — проведите их верификацию
• Не игнорируйте принятые риски — пересматривайте их каждый цикл, владелец и контекст меняются

Частые вопросы