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

Компании часто покупают сканер уязвимостей, запускают его раз в квартал, получают отчёт на триста страниц, и на этом всё останавливается. Сканирование само по себе не снижает риск. Снижает его процесс: приоритизация находок, назначение ответственных, отслеживание сроков исправления. Без этого сканер просто дорогой генератор PDF-файлов.

Почему разовое сканирование не работает

Отчёт со списком из трёхсот уязвимостей без приоритизации парализует, помочь он не помогает. Непонятно, с чего начинать, у кого есть время закрывать находки, и что вообще критично прямо сейчас. Через квартал происходит новое сканирование, и старые находки либо забыты, либо перемешаны с новыми в такой же неструктурированный список. Компания годами платит за сканер, но реальный уровень риска почти не меняется.

Из чего состоит рабочий процесс

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

Сканер находит уязвимости. Процесс управления уязвимостями решает, какие из них закрывать в первую очередь, кто это делает и как проверяется результат. Первое товар, который продают вендоры. Второе реально снижает риск, и его нужно строить самостоятельно.

Как приоритизировать без хаоса

Практичный подход комбинирует техническую критичность (CVSS), эксплуатируемость (есть ли публичный эксплойт) и бизнес-контекст (насколько критична система для компании). Уязвимость с высоким баллом на изолированном тестовом сервере может подождать. Уязвимость со средним баллом, но с публичным эксплойтом на системе, обрабатывающей платежи, ждать не может. Формальный балл без контекста систематически приводит к неверным приоритетам.

Частая организационная ошибка

Процесс управления уязвимостями часто буксует из-за отсутствия реальных полномочий у того, кто отвечает за приоритизацию. Инструментов при этом обычно хватает. Если специалист по ИБ находит критичную уязвимость, а команда разработки не считает её приоритетом и ничем не рискует, откладывая исправление, процесс существует только на бумаге. Реальный процесс требует эскалации через руководство. Бесконечные напоминания в почте тут не работают.

Управление уязвимостями это не инструмент. Это дисциплина: регулярность, приоритизация, ответственность, проверка результата. Сканер только первый шаг в этой цепочке. Компании, которые останавливаются на нём, получают иллюзию контроля вместо реального снижения риска.