Главная мысль
Для каждой выявленной проблемы назначайте ответственного, срок и подходящий способ проверки. Отличайте принятие риска от исправления, фиксируйте остаточный риск и следующий пересмотр.
1. Оцените
Проводите обнаружение на активах, сетях, приложениях и конечных устройствах только в разрешённом охвате и безопасное время. Проверьте реестр, учётные данные сканирования и ограничения средства. Уточните применимость сигнала к активу и версии, фактическую доступность и дубликаты. Сопоставляйте телеметрию обнаружения и реагирования на конечных устройствах (EDR) с реестром и сканированием уязвимостей: наличие EDR не означает наличие полноценного сканера уязвимостей. Свяжите запись о выявленной проблеме с владельцем, зависимостями сервиса и последними изменениями.
2. Проанализируйте и расставьте приоритеты
Оценивайте техническую серьёзность вместе с доказательствами эксплуатации, доступностью и последствиями для бизнеса. В Common Vulnerability Scoring System (CVSS) v4.0 Base отражает технические характеристики дефекта, Threat — меняющиеся сведения об эксплуатации, Environmental — локальную среду. Балл Base сам по себе не равен бизнес-риску; низкий балл не означает безвредность для чувствительной системы. Учитывайте данные, сервис, финансовые последствия и восстановление, записывайте решение и владельца остаточного риска.
3. Примите меры
Выберите согласованный патч, изменение конфигурации, отключение ненужной службы или временное сетевое ограничение в зависимости от выявленной проблемы. Назначьте владельца, срок и условия проверки. До изменения испытайте совместимость и подготовьте откат. Если исправление откладывается, запишите временный контроль и ограниченное по времени принятие риска владельцем. Принятие риска и дополнительный мониторинг не устраняют дефект: у исключения должны быть срок и следующий пересмотр.
4. Проверьте повторно
После изменения выберите повторное сканирование, проверку версии, конфигурации или доступности в зависимости от выявленной проблемы и подтвердите работоспособность сервиса. Одно изменение версии не доказывает закрытие всех путей атаки. Если проблема сохраняется или возникает снова, выясните причину и верните работу владельцу. Закрывайте запись по техническим доказательствам и решению об остаточном риске, а не только по статусу заявки.
5. Отчитайтесь и улучшайте процесс
В отчёте укажите охват, подтверждённые неустранённые проблемы, приоритеты, владельцев, сроки, исключения, завершённые исправления и доказательства повторной проверки. Повторяющиеся уязвимости могут указывать на первопричину в качестве кода, базовой конфигурации, реестре или процессе изменений. Отслеживайте критичные проблемы с просроченным сроком устранения, среднее время закрытия, повторное открытие и влияние патчей на сервис. Используйте выводы для обновления охвата сканирования, обучения, окна исправлений и автоматизации.
Разница между оценкой и управлением
Оценка уязвимостей исследует найденные слабые места сети, приложения, процесса или конечного устройства и определяет их относительную значимость. Управление уязвимостями — более широкий цикл: инвентаризация, обнаружение, приоритизация, исправление, ответственность, повторная проверка и отчётность. Оценка отвечает на вопрос «что найдено и насколько это важно?», управление — «кто и когда что сделает и как мы это подтвердим?». Оба процесса зависят от полной видимости активов и ясной ответственности.