Отчет по пентесту и рекомендации по усилению защиты
Структура отчёта о пентесте
Результаты такого процесса, как Тестирование на проникновение (pentest), оформляются в виде отчёта — документа, который содержит полное описание выполненных работ, обнаруженных недостатков безопасности и рекомендаций по их устранению. Отчёт позволяет заказчику получить объективную картину текущего уровня защищённости информационной системы и принять обоснованные решения по усилению защиты. Методики составления такого документа могут опираться на стандарты PTES, OWASP или NIST, что обеспечивает единообразие структуры и терминологии.
Обязательные разделы отчёта и метрики оценки
Типовой отчёт о пентесте включает несколько обязательных разделов. Первый — исполнительное резюме, где на двух-трёх страницах излагаются ключевые выводы, общая оценка уровня безопасности и самые критичные уязвимости. Второй раздел — методология и объём работ: описываются инструменты, сценарии атак, ограничения тестирования. Далее следует детальная сводка уязвимостей — основной блок, содержащий описание каждой проблемы, её идентификатор, тип, уровень критичности, вектор эксплуатации и возможные последствия. Каждой уязвимости сопоставляется рекомендация по устранению с указанием конкретных шагов. В заключительной части приводятся приложения (логи, скриншоты, списки задействованных хостов) и глоссарий.
Для оценки глубины и полноты проверки используются метрики пентеста: количество обнаруженных уязвимостей, распределение по уровням критичности, процент успешно проэксплуатированных находок, время эксплуатации. В сводке указывается общее число уязвимостей, например, пять критических, двенадцать высокого уровня, двадцать среднего. Эти метрики дают представление об объёме работы и помогают заказчику оценить, насколько полно было проверено приложение или инфраструктура.
| Раздел отчёта | Содержание |
|---|---|
| Исполнительное резюме | Краткая оценка уровня безопасности, перечень ключевых выводов |
| Методология и объём | Сценарии, инструменты, ограничения, перечень протестированных компонентов |
| Сводка уязвимостей | Детальное описание каждой уязвимости с присвоенным баллом CVSS |
| Рекомендации по устранению | Пошаговые инструкции по исправлению каждой уязвимости |
| Приложения | Доказательные материалы, логи, скриншоты, конфигурации |
Как отличить реальную уязвимость от ложного срабатывания
В процессе пентеста некоторые автоматические сканеры могут генерировать индикаторы, не подтверждающиеся при ручной верификации. Чтобы отличить реальную уязвимость от ложного срабатывания, исполнитель проводит многоэтапную проверку. Сначала он воспроизводит атаку по описанному вектору — если эксплуатация проходит успешно, находка считается подтверждённой. Если атака не срабатывает или приводит к непредсказуемым результатам, выполняется анализ контекста: возможно, уязвимость проявляется только в определённых условиях (версия библиотеки, настройки, права доступа). Также проверяется, не является ли результат дубликатом уже обнаруженной проблемы, но с другим индикатором.
- Повторное выполнение атаки с точным следованием шагам, описанным в отчёте.
- Анализ ответов сервера и трафика для подтверждения факта эксплуатации.
- Проверка фактора окружения — версии, конфигурации, временные ограничения.
- Сравнение с другими уязвимостями, чтобы исключить двойной учёт.
Результатом верификации становится маркировка каждой записи: «Истинная уязвимость» или «Ложное срабатывание». В итоговом отчёте ложные срабатывания не включаются в основную сводку, но могут быть перечислены в приложении для сведения.
Оценка критичности уязвимостей: шкалы CVSS и OWASP
Базовый, временной и контекстуальный баллы CVSS
Common Vulnerability Scoring System (CVSS) — индустриальный стандарт количественной оценки опасности уязвимостей. Система использует три группы метрик: базовые, временные и контекстуальные. Базовые метрики описывают неотъемлемые свойства уязвимости — вектор атаки (AV), сложность (AC), требуемые привилегии (PR), взаимодействие с пользователем (UI), область действия (S), влияние на конфиденциальность (C), целостность (I) и доступность (A). По этим характеристикам вычисляется базовый балл от 0 до 10. Например, уязвимость, которая эксплуатируется удалённо через сеть (AV:N) с низкой сложностью (AC:L) и не требует привилегий (PR:N), получает высокий базовый балл.
Временной балл уточняет оценку в зависимости от готовности эксплойта (E), уровня исправления (RL) и уверенности в методике (RC). Если для уязвимости уже существует публичный эксплойт (E:H), временной балл увеличивается. Контекстуальный балл привязывается к конкретной среде заказчика — к требованиям безопасности (CR, IR, AR) и изменённым метрикам (MAV, MAC и т.д.). Итоговая оценка в отчёте указывается в виде вектора CVSS, например CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H, что соответствует базовому баллу 9.8 (критическая уязвимость).
Интерпретация скоринга OWASP Top 10 в контексте отчёта
OWASP Top 10 представляет собой классификацию наиболее распространённых типов уязвимостей веб-приложений, но не даёт точного количественного балла. В отчёте о пентесте скоринг OWASP используется для категоризации уязвимости по семейству (например, A03:2021 — Injection, A06:2021 — Vulnerable and Outdated Components). Каждой находке может быть присвоен риск по методологии OWASP Risk Rating, где оценка вычисляется через вероятность и влияние, но на практике чаще применяют CVSS для единообразия. Тем не менее, ссылка на OWASP Top 10 позволяет заказчику быстро понять, какого класса проблема обнаружена, и соотнести её с известными рекомендациями — например, для предотвращения межсайтового скриптинга (A07:2021 — Cross-Site Scripting) использовать контекстное экранирование вывода.
«Оценка по OWASP Top 10 не заменяет CVSS, но даёт удобную таксономию для группировки уязвимостей по их природе и типовым способам устранения» — из руководства OWASP Testing Guide v4.2.
Планирование устранения уязвимостей и верификация исправлений
Приоритизация уязвимостей и составление плана устранения
После получения отчёта заказчик сталкивается с задачей распределения ресурсов на исправление обнаруженных проблем. Приоритизация основывается не только на балле CVSS, но и на влиянии уязвимости на бизнес-процессы, возможности её эксплуатации в конкретной среде и сложности устранения. Например, критическая уязвимость в ядре платежного шлюза получает высший приоритет, тогда как уязвимость среднего уровня в административной панели, доступ к которой ограничен корпоративной сетью, может быть отложена.
- Разделение уязвимостей на группы критичности: критичные (CVSS 9-10), высокие (7-8.9), средние (4-6.9), низкие (0-3.9).
- Назначение ответственного за каждую уязвимость — администратор базы данных, разработчик, сетевик.
- Установление контрольных сроков: для критических — не позднее 48 часов, для высоких — до 7 дней, для средних — до 30 дней.
- Определение ресурсов — выделение времени на внедрение исправлений, закупку обновлений, тестирование.
План устранения (remediation plan) фиксируется в отдельном документе, где каждой уязвимости сопоставляется конкретный шаг исправления, дата начала и окончания работ, ответственный и статус. Документ регулярно пересматривается — например, на еженедельных совещаниях по безопасности.
Ретест: методика и критерии успешного исправления
Ретест (повторное тестирование) — это процесс верификации того, что заявленное исправление действительно устраняет уязвимость и не создаёт новых проблем. Пентестер воспроизводит точно те же векторы атаки, которые привели к обнаружению уязвимости, а также выполняет несколько дополнительных проверок для исключения неполного исправления. Например, если уязвимость SQL-инъекции закрыта экранированием кавычек, ретест включает попытки обхода фильтра с разными кодировками и синтаксическими конструкциями.
- Воспроизведение атаки по исходному сценарию — уязвимость не должна проявляться.
- Проверка смежных функций — исправление не должно нарушить работу других сервисов.
- Тестирование на наличие новых уязвимостей, которые могли появиться из-за изменений кода или конфигурации.
- Оценка времени восстановления функциональности после инцидента.
Критерии успешного исправления: уязвимость перестаёт эксплуатироваться, все попытки воспроизведения атаки завершаются неудачей, не происходит побочных эффектов, влияющих на безопасность. Результаты ретеста оформляются отдельным протоколом, который прилагается к основному отчёту. Если какая-либо уязвимость не прошла ретест, она остаётся в списке неисправленных с новой датой контрольной проверки.
Проведение ретеста в течение 2-4 недель после завершения исправлений позволяет замкнуть цикл управления уязвимостями и подтвердить, что защита информационной системы усилена в соответствии с рекомендациями внешнего аудитора.
