Управление уязвимостями: процесс, а не запуск сканера

Пятница, 17:30. Сканер выгрузил отчёт: четырнадцать тысяч находок, из них больше двух тысяч — «критические». PDF на девятьсот страниц уходит письмом в ИТ-⁠отдел с пометкой «устранить». Через месяц повторное сканирование показывает ещё больше находок. Все заняты, все устали, а риск не снизился.

Так выглядит ситуация, когда сканирование путают с управлением уязвимостями. Сканер отвечает на вопрос «что не так», но не говорит, что чинить первым, кто это сделает, к какому сроку и исправлено ли на самом деле. Vulnerability Management — это как раз ответы на эти вопросы.

Процесс управления уязвимостями: шесть шагов цикла

Зрелый процесс — это цикл, который крутится непрерывно, а не проект, который заканчивается отчётом.

1. 01

   Инвентаризация

   Нельзя просканировать то, о чём не знаешь. Список активов с владельцами и критичностью — вход всего процесса. Подробнее — в статье об управлении ИТ-⁠активами.

2. 02

   Сканирование

   Регулярное, по расписанию, с учётными данными там, где это возможно: аутентифицированное сканирование видит установленные версии ПО, а не только то, что торчит наружу.

3. 03

   Анализ

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

4. 04

   Приоритизация

   Решение, что устранять первым, с учётом не только оценки CVSS, но и контекста: критичности актива, доступности, эксплуатируемости.

5. 05

   Устранение

   Обновление, изменение конфигурации, компенсирующая мера или осознанное принятие риска — всегда с исполнителем и сроком.

6. 06

   Проверка

   Повторное сканирование подтверждает, что уязвимость действительно закрыта, а не просто «задача переведена в статус выполнено».

Слабое звено обычно не сканер, а стыки между шагами. Отчёт не превращается в задачи, задачи не связаны с активами, а закрытие никто не проверяет.

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

Почему CVSS недостаточно

CVSS (Common Vulnerability Scoring System) — отраслевой стандарт оценки тяжести уязвимости. Базовая оценка от 0 до 10 описывает саму уязвимость: как её эксплуатировать, нужны ли привилегии и действия пользователя, что пострадает — конфиденциальность, целостность или доступность.

Формально в CVSS есть и контекстные метрики — группа environmental позволяет учесть требования к конкретному активу. Но на практике почти все используют базовую оценку из бюллетеня или отчёта сканера, а окружение не заполняет никто: это ручная работа по каждой находке.

Это полезная, но «лабораторная» величина: она ничего не знает о вашей инфраструктуре. Если приоритизировать только по CVSS, получается как в начале статьи — тысячи одинаково срочных находок. Реальный риск определяют ещё как минимум три фактора:

• Критичность актива. Сервер с платёжными данными и тестовая виртуалка разработчика — очень разные последствия при компрометации.
• Доступность для атакующего. Уязвимость на периметре, открытом в интернет, и та же уязвимость в изолированном сегменте без маршрута извне — разные истории.
• Наличие эксплойта и признаки эксплуатации. Публичный рабочий эксплойт резко сокращает время, которое у вас есть. Здесь помогают EPSS (Exploit Prediction Scoring System) — вероятностная оценка того, что уязвимость начнут эксплуатировать в ближайшее время, — и каталоги уже эксплуатируемых уязвимостей, например KEV от американского агентства CISA.

Если уязвимость активно эксплуатируется, логично связать VM с реагированием на инциденты: алерт SIEM на уязвимом критичном хосте должен получать повышенный приоритет, а сценарий SOAR — учитывать, что атака может быть не ложной тревогой.

Приоритизация уязвимостей на примере

Возьмём две находки из одного отчёта.

По «голому» CVSS первой в работу ушла бы уязвимость B. По здравому смыслу — A, и как можно скорее. Такую логику нельзя держать в голове одного аналитика: её нужно зашить в правила. Матрица «тяжесть × критичность актива × доступность × эксплуатируемость» даёт итоговый приоритет, а приоритет — срок устранения.

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

А если критичность активов ещё не проставлена? Не ждите идеального реестра. Начните с грубого деления: периметр и всё, что доступно из интернета; системы с персональными и платёжными данными; инфраструктурное ядро — контроллеры домена, почта, системы резервного копирования; всё остальное. Даже такая четырёхуровневая разметка за неделю сделает приоритизацию заметно точнее, чем один CVSS, а уточнять её можно по мере работы.

SLA на устранение: сроки, которые можно выполнить

Приоритет без срока — пожелание. SLA на устранение фиксирует, за какое время уязвимость каждого уровня должна быть закрыта или получить компенсирующую меру. Конкретные сроки каждая организация выбирает сама — исходя из риск-⁠аппетита, окон обслуживания и требований регуляторов. Логика обычно такая:

• Критический — считанные дни, вплоть до внеплановых работ, если уязвимость эксплуатируется и актив доступен из интернета;
• Высокий — ближайший цикл обновлений;
• Средний — плановый порядок, в пределах квартала;
• Низкий — по возможности или с осознанным принятием риска.

Важно заранее предусмотреть исключения. Не всё можно обновить: встроенное ПО оборудования, промышленные системы, легаси без поддержки производителя. Для таких случаев процесс должен позволять оформить компенсирующую меру — сегментацию, правило на межсетевом экране, отключение уязвимого компонента — или принятие риска. С обоснованием, владельцем и датой пересмотра.

Ещё два практических момента. Первый — от какой точки считать срок: от публикации уязвимости, от её обнаружения сканером или от создания задачи. Выберите одно и зафиксируйте в регламенте, иначе метрики будут спорными. Второй — эскалация: если срок подходит к концу, об этом должен узнать не только исполнитель, но и владелец актива, а при просрочке — руководитель, который может выделить окно или принять риск.

Конфликт ИТ и ИБ и как его снять

ИБ находит уязвимости, а устраняет их ИТ. Отсюда вечное напряжение. ИБ видит в ИТ тех, кто «тянет с патчами». ИТ видит в ИБ тех, кто присылает PDF на девятьсот страниц и не понимает, что перезагрузка кластера — это окно обслуживания, согласования и риск простоя.

Конфликт снимается не совещаниями, а единым процессом:

• Задачи вместо отчётов. Уязвимость превращается в задачу в ITSM — там, где ИТ и так работает, — с активом, исполнителем, сроком и рекомендацией по устранению.
• Группировка по действию. Сорок CVE, которые закрывает одно обновление ОС, — одна задача, а не сорок.
• Прозрачные правила. Приоритет и SLA считаются по согласованной формуле, а не по настроению аналитика.
• Обратная связь. Закрытие задачи запускает проверку. Если уязвимость осталась, задача возвращается автоматически.
• Общая база знаний. Решения, обходные пути и исключения накапливаются и переиспользуются, когда та же уязвимость всплывает снова.

Хорошая задача на устранение самодостаточна. Инженеру не нужно открывать отчёт сканера и выяснять, о каком сервере речь: в задаче указаны актив и его владелец, список уязвимостей, итоговый приоритет с обоснованием, срок по SLA, рекомендуемое действие (например, обновить пакет до конкретной версии) и ссылка на карточку уязвимости с подробностями. Если есть известные подводные камни — несовместимость обновления, необходимость перезагрузки, — это тоже лучше написать сразу.

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

Метрики vulnerability management

Количество найденных уязвимостей — плохая метрика: оно растёт с каждым новым сканером и расширением охвата. Смотреть стоит на то, как работает процесс.

Тренд важнее абсолютного значения. Если доля устранённых в срок растёт, а время устранения критичных находок сокращается, процесс работает — даже если общее число находок пока велико.

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

Типичные ошибки

Проблемы процесса управления уязвимостями удивительно похожи от компании к компании. Чаще всего встречаются шесть:

1. Сканировать не всё. Без актуальной инвентаризации за пределами охвата остаются ровно те хосты, которые атакуют в первую очередь.
2. Приоритизировать только по CVSS. Команда тонет в «критических» находках и не успевает закрыть действительно опасные.
3. Отправлять отчёты вместо задач. PDF в почте — не процесс: его нельзя отследить и нельзя измерить.
4. Не проверять устранение. «Закрыто» в тикете не означает «исправлено» на хосте.
5. Игнорировать исключения. Без механизма компенсирующих мер неустранимые уязвимости годами висят «просроченными» и обесценивают метрики.
6. Лечить симптомы. Одни и те же уязвимости возвращаются, потому что не исправлены золотые образы, шаблоны виртуальных машин и процессы сборки.

Как это устроено в Versium VM

Versium VM работает поверх сканера и отвечает за устранение. Модуль забирает находки из RedCheck и Kaspersky Security Center, обогащает их данными NVD и БДУ ФСТЭК — включая признак из каталога CISA KEV — и расставляет приоритеты по методике ФСТЭК с учётом конкретного актива.

Дальше — работы и задачи в Jira, Яндекс Трекере, YouGile, Naumen или SimpleOne, а устранение подтверждается повторным сканированием, а не отметкой в тикете. Цепочка «сканер → находка → приоритет → задача → повторный скан» становится единым процессом для ИТ и ИБ.

Приоритизация опирается на критичность активов из модуля Versium AM: платформа одна, поэтому контекст актива не приходится сводить вручную в таблицах. Хотите посмотреть, как ваш реальный отчёт сканера превращается в приоритизированные задачи, — запишитесь на демонстрацию.