Как написать отчет об уязвимости, на который компания действительно среагирует?

Большинство уведомлений об уязвимостях умирают в таблице, потому что они написаны для других специалистов по безопасности, а не для того, кто подписывает бюджет. Если в отчете написано «CVE-2023-XXXX, CVSS 9.8, срочно установите патч», вы описали уязвимость, а не риск. Компания не реагирует на уязвимости. Она реагирует на последствия, которые может себе представить.

Почему оценки серьезности сами по себе ничего не меняют

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

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

Строите находку вокруг сценария, а не вывода сканера

Вместо «обнаружена SQL-инъекция на /login», напишите сценарий: «Неаутентифицированный злоумышленник может извлечь полную таблицу клиентов, включая хэшированные пароли и адреса доставки, через форму входа. Эта таблица содержит данные 40 000 активных аккаунтов, и в той же базе данных находится история заказов, относящаяся к PCI-scope.» Теперь читатель не разбирает класс уязвимости, а представляет себе письмо с уведомлением о нарушении и звонок от регулятора.

Полезная структура для каждой находки:

• Что может произойти — путь атаки простым языком, одно-два предложения.
• На что влияет — конкретная система, конкретные данные, конкретный бизнес-процесс.
• Во что обойдется — часы простоя, нормативное воздействие, доверие клиентов, штрафы по контрактам. Используйте реальные цифры, если они есть (штрафы по SLA, стоимость прошлых инцидентов, франшиза по страховке).
• Что нужно для исправления — объем работ, не просто «установите патч». Иногда исправление — это правило WAF сегодня и изменение кода в следующем спринте.
• Кто отвечает за исправление — имя или команда, не просто «IT».

Привяжите находку к метрике, которую компания уже отслеживает

В каждой компании есть метрики, которые отслеживает руководство: SLA по uptime, отток клиентов, результаты аудита из последнего цикла SOC 2, страховые премии, конкретный контракт с клиентом с требованиями по безопасности. Если вы сможете связать вашу находку с одной из этих существующих статей — «это тот же класс проблемы, на который указала наша страховая при последней переаттестации» или «этот поток данных входит в scope SOC 2-аудита на Q3» — вы не просите их озабочиться чем-то новым. Вы показываете им угрозу для того, за что они уже отвечают.

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

Ранжируйте по эксплуатируемости и масштабу воздействия, не только по CVSS

Практичный подход к приоритизации:

1. Доступна ли с интернета или требуется сначала внутренний доступ?
2. Есть ли публичный exploit или это теоретическое предположение?
3. Влияет ли на регулируемые данные (PCI, PHI, PII) или системы критической важности?
4. Какая реальная стоимость и время на исправление против стоимости оставить как есть?

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

Напишите запрос, а не просто проблему

Завершите каждую находку конкретным запросом: статьей бюджета, окном для изменений, исключением из политики для закрытия или необходимым решением с конкретной датой. «Рекомендуем устранить» игнорируют. «Нам нужно четырехчасовое окно обслуживания до 15-го для патча платежного шлюза, иначе мы принимаем остаточный риск в письменной форме» вынуждает принять решение в ту или иную сторону. Предоставление руководству явного варианта принять риск в письменной форме с их подписью часто становится тем, что наконец одобрит исправление.

Если вы хотите потренироваться преобразовывать сырой вывод сканера в находки такого уровня, работайте с Blue Team и Offensive-сегментами Korra Studio параллельно — парность контекста эксплуатации с упражнениями на отчетность — вот где навык действительно закаляется.