? Это часть 7 серии “Управление уязвимостями для самых маленьких” - практического руководства по VM с нуля. Главы самостоятельны, но если хочется по порядку - оглавление и все части серии тут.

Самый большой отчет об уязвимостях, который я держал в руках, был на 1819 страниц. Та же выгрузка в Excel - 2,2 миллиона строк. Excel ее не открыл: у листа лимит 1 048 576 строк, и файл просто не пролез.

Отдельная ирония в том, что сканер отработал прекрасно. Он нашел все, что было, и все это выгрузил. Проблема началась ровно в тот момент, когда результат надо было передать людям, которые будут с ним что-то делать.

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

Напомню состав процесса: выявление уязвимостей, их анализ и приоритизация, разработка мер по устранению, устранение и контроль устранения. Приоритизации посвящена отдельная глава - она того стоит, там и CVSS, и EPSS, и KEV, и методика ФСТЭК. Технике сканирования тоже отведена своя глава. А здесь сосредоточимся на том, что происходит с уязвимостью после того, как ее нашли, и на том, как понять, работает процесс или только выглядит работающим.

Выявление: сколько у вас на самом деле времени

При выявлении уязвимостей важны три вещи:

1. получать максимально достоверную информацию из всех источников

2. получать ее как можно быстрее

3. оперативно проверять, есть ли эти уязвимости в системах, и переходить к устранению

Вручную это невозможно: ушло бы слишком много людей и времени. Поэтому и придумали сканеры защищенности, есть кстати хорошая статья на эту тему “Как превратить тысячи найденных уязвимостей в понятный план действий”. Чтобы сканирование было осмысленным, задаем параметры:

• Область сканирования - какие активы сканируем.

• Периодичность - как часто. Приказ ФСТЭК № 117 для госсистем требует сканировать не реже раза в месяц [1], но для периметра разумная периодичность - гораздо чаще, вплоть до ежедневной. Тут еще можно задать философский вопрос: “А нужно ли часто сканировать, есть инфраструктура не меняется, а система рассчитывает уязвимости по предыдущему слепку?”

• Профили сканирования - режим и технические условия: выделенная учетная запись, сетевая доступность, тех окна.

Сведения об уязвимостях берем от вендоров средств защиты, ОС и прикладного ПО, а также из общедоступных источников - NVD, БДУ ФСТЭК и др.

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

Времени мало, и с каждым годом меньше. По совместному исследованию BI.ZONE и Сбера, показатель Time-to-Exploit - срок от публикации уязвимости до начала ее эксплуатации - за два с половиной года сократился примерно в двадцать раз и к концу 2025-го опустился ниже 40 дней [3]. Это средняя температура. Для пограничных устройств все гораздо жестче: по данным Verizon DBIR, медиана времени от раскрытия уязвимости edge-устройства из каталога KEV до массовой эксплуатации равна нулю дней [4]. Ноль, карл, НОЛЬ! Не “быстро”, а сразу.

И вишенка. Qualys в марте 2026 года опубликовал разбор более миллиарда записей об устранении KEV-уязвимостей по десяти с лишним тысячам организаций. Один из выводов: 85% уязвимых активов оставались непропатченными на момент раскрытия уязвимости [5]. То есть в момент, когда мир узнает о дыре, подавляющее большинство систем уже уязвимы и еще не защищены. Гонка начинается не с нуля, а с проигранной позиции.

Отсюда рекомендации к этапу выявления:

• процедура должна быть непрерывной и структурированной, а не “раз в квартал, когда вспомним”

• область сканирования должна покрывать всю инфраструктуру, включая shadow IT

• технологические окна согласуйте с владельцами и администраторами систем заранее, а не в момент запуска задачи

• периметр и все, что смотрит наружу, выделите в отдельный контур с отдельной, гораздо более частой периодичностью. Внутренний файловый сервер и VPN-шлюз живут в разных временных рамках

Пропускная способность: почему закрыть все нельзя

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

Закрыть все уязвимости невозможно. Не потому что вы плохо работаете, а потому что арифметика такая. Ну и не даром же в обиход идет новый термин “Exposure Management”

Классическое исследование Cyentia Institute и Kenna Security (серия “Prioritization to Prediction”, третий выпуск) дало цифру, которая с тех пор кочует по всей отрасли: типичная организация - независимо от размера - способна устранять примерно одну из десяти открытых уязвимостей в месяц [6]. Причем зависимость оказалась почти линейной: чем больше у вас открытых уязвимостей, тем больше вы закрываете, но доля остается той же. Крупная компания с сотней тысяч уязвимостей закрывает десять тысяч в месяц и остается с девяноста. Маленькая с тысячей закрывает сотню. Пропорция не меняется.

Исследование, из которого она взята, датируется 2019 годом. Более свежего прямого пересчета этой метрики в открытых источниках я не нашел - но не нашел и опровержения. Косвенно ее подтверждает свежая статистика Qualys: число закрытых уязвимостей в мире выросло примерно в 6,5 раза за четыре года (с 73 млн в 2022-м до 473 млн в 2025-м), и при этом доля критических уязвимостей, остающихся открытыми через 7 дней, за тот же период не упала, а выросла - с 56% до 63% [5]. Мы стали закрывать в разы больше и при этом отстаем сильнее, чем раньше. Ну и если говорить про то что вижу у многих клиентов, то количество уязвимостей растет кратно, если 5 лет назад 10к уязвимостей это много, это сейчас это ничто, а вот 2 млн уязвимостей - это проблема(пока).

Из этого следует ровно один практический вывод: задача процесса - не закрыть все, а закрыть правильное. Очередь всегда будет непустой. Вопрос не в том, дойдете ли вы до конца списка (не дойдете), а в том, что окажется в его начале.

Насколько это важно, показывает еще одна цифра. Компания Hadrian в отчете 2026 года по итогам анализа трехсот инфраструктур утверждает: реально эксплуатируемыми на практике оказываются 0,47% находок сканеров уязвимостей [7]. Меньше половины процента. Все остальное - технически верные записи, которые в конкретной вашей инфраструктуре ни к чему не ведут: сервис не смотрит наружу, уязвимая функция не используется, вектор перекрыт другой мерой.

Это не значит, что сканер врет. Это значит, что между “сканер нашел” и “надо срочно чинить” лежит целый этап работы, и называется он приоритизацией. Ему посвящена отдельная глава - там и CVSS 4.0, и EPSS, и KEV, и трендовые уязвимости, и методика ФСТЭК. Здесь я только фиксирую: если вы отдаете в ИТ все, что выдал сканер, вы отдаете им 0,47% полезного сигнала и 99,53% шума. И удивляетесь, что они не спешат.

Как передать результат, чтобы его прочитали

Вернемся к отчету на 1819 страниц.

Что с ним не так? Формально - ничего. Там есть все: описания уязвимостей, ссылки на бюллетени, уровни критичности, перечни затронутых хостов. Технически это качественный документ. Пахаххаха вы бы видели эту стопку бумаги, да да, его распечатали)

Практически - он бесполезен, потому что у него нет читателя.

Представьте администратора веб-серверов. Он открывает этот том и понимает, что его позиций там штук пятьдесят. Пятьдесят из нескольких тысяч. Прежде чем что-то сделать, ему надо их найти: пролистать, отфильтровать, выписать. Это час-полтора работы до начала работы. Потом он должен сгруппировать их по хостам и по пакетам обновлений, потому что ставить он будет не “уязвимость CVE-2023-XXXX”, а конкретный пакет на конкретную группу машин.

И вот здесь происходит развилка, которая определяет судьбу всего вашего процесса. Если этот час-полтора администратор тратит каждый раз - он начнет откладывать. Не из вредности, а потому что у него есть задачи, где работа начинается сразу.

Правило первое: отчет и реестр - разные документы, и нужны оба.

Подробный отчет - это доказательная база. Он нужен для аудита, для разбора спорных случаев, для истории. Его читают редко и по делу.

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

Как выглядит нормальный реестр:

Пять колонок. Никаких CVSS-векторов, никаких абзацев из описания уязвимости - если администратору понадобятся детали, он откроет отчет или спросит. В реестре его интересует действие.

Правило второе: адресность.

Отчеты направляйте персонально, чтобы каждый получал только то, что в его зоне ответственности. Администратор веб-серверов получает свои веб-серверы, администратор баз данных - свои базы, сетевики - свое сетевое оборудование. Общая рассылка “всем от ИБ” - это способ гарантировать, что не сделает никто: у документа без адресата нет и ответственного.

Правило третье: думайте не CVE, а задачами.

Есть типовая ошибка, которой процесс убивают из лучших побуждений. Настраивают автоматическое создание задач в трекере - по одной на каждую уязвимость. Формально безупречно: каждая уязвимость отслеживается, ничего не теряется, статистика красивая. По факту в ИТ за одну ночь прилетают сотни тикетов, половина из которых закрывается одним и тем же действием, а отношения между командами портятся надолго.

Администратор не устраняет CVE. Он ставит пакет обновлений на группу хостов. Один пакет закрывает десяток CVE разом. Значит, и задача должна быть одна: “обновить nginx до 1.26.2 на семи фронтах”, а внутри нее - перечень закрываемых уязвимостей справочно.

Что должно быть в задаче:

• исполнитель - конкретный человек или команда, а не абстрактное “ИТ”

• действие - что именно поставить или изменить, с версией

• область - перечень хостов или группа активов

• срок - из SLA для этой группы активов, а не “как получится”

• обоснование в одну строку - почему это здесь и сейчас (периметр, трендовая уязвимость, значимый актив)

• критерий закрытия - и вот это самое интересное

Критерий закрытия задачи не должен звучать как “исполнитель нажал кнопку Готово”. Он должен звучать как “уязвимость не обнаруживается при следующем сканировании”. Если ваш VM-инструмент умеет закрывать задачи автоматически по результатам пересканирования - настройте это в первую очередь.

Три законных исхода

После приоритизации переходим к устранению. И здесь важно зафиксировать простую вещь: у найденной уязвимости есть ровно три законных исхода. “Мы про нее забыли” в этот список не входит.

Исход первый - патч. Самый честный путь: вендор выпустил обновление, ИТ его протестировало и раскатало. Именно так должно закрываться большинство уязвимостей, и именно так устроен зрелый процесс: основная масса уходит в регулярные плановые обновления, а трендовые и беспатчевые - внепланово по согласованию с ИБ.

Исход второй - компенсирующая мера. Патча нет, или он есть, но встать не может. Сертифицированная сборка, которую нельзя обновлять без потери сертификата. Legacy-приложение, которое падает на новой версии библиотеки. Вендор, ушедший с рынка. Оборудование в АСУ ТП, где окно на обслуживание бывает раз в год. В этих случаях мы снижаем не саму уязвимость, а возможность до нее дотянуться.

Исход третий - принятие риска. Мы посмотрели, оценили и осознанно решили ничего не делать. Актив выводится из эксплуатации через два месяца. Уязвимость эксплуатируется только локально, а локальный доступ к этой машине есть у двух человек. Стоимость устранения выше стоимости возможного ущерба.

Про третий исход стоит сказать отдельно, потому что в реальности он существует всегда, а в регламентах - почти никогда. И тогда он превращается в тот самый четвертый, незаконный вариант: уязвимость просто висит, все про нее знают, никто ничего не делает, и формально она числится “в работе” третий год.

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

• кто принял решение (это должен быть владелец актива или бизнеса, а не безопасник)

• на каком основании - чем обоснована оценка

• какие компенсирующие меры при этом применены, если применены

• до какой даты действует решение

• когда пересматриваем

На последнем пункте держится все остальное. Принятие риска без срока пересмотра - способ красиво списать проблему, а не управленческое решение. Уязвимость, которую год назад сочли безопасной, за это время могла стать трендовой и обзавестись публичным эксплойтом. Обстановка меняется, решение надо перепроверять.

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

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

И формально он прав: файл действительно лежит на месте. Но им ничего не пользуется - ни один процесс его не загружает, ни один сервис на него не ссылается. Администратор смотрит на это и говорит: у меня этого софта нет. Безопасник смотрит на отчет и говорит: вот же он.

Строго говоря, это даже не ложное срабатывание - находка верна, неверна только ее интерпретация. И правильный ответ здесь не “признать ложным и закрыть глаза”, а вычистить хвосты. Мертвая библиотека на диске - вечная строка в отчете. И заодно готовый уязвимый код, который тот, кто до этой машины доберется, вполне может подгрузить своим процессом. Дешевле удалить, чем каждый квартал обсуждать заново.

В остальном важно завести процедуру и не превращать каждый случай в спор. У ИТ появится соблазн объявлять ложным срабатыванием все неудобное, у ИБ - не верить никому. Работающая схема простая: администратор заявляет ложное срабатывание с обоснованием (вывод команды, содержимое changelog вендора, отсутствие процесса, использующего библиотеку), безопасник проверяет и либо соглашается, либо нет. Решение фиксируется в системе с обоснованием - чтобы через полгода при следующем сканировании не разбирать то же самое заново.

Компенсирующие меры

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

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

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

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

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

И еще одно, о чем забывают в девяти случаях из десяти. У компенсирующей меры должен быть срок жизни. Она не устраняет уязвимость, она покупает время. Если вы поставили WAF-правило и на этом успокоились, через год у вас будет 100500 WAF-правил, половина из которых прикрывает уязвимости, для которых патч вышел одиннадцать месяцев назад. Каждая мера должна быть привязана к дате пересмотра ровно так же, как принятие риска.

Верификация: закрывает не тикет, а рескан

Самое опасное состояние процесса - когда все считают, что уязвимость устранена, а она нет.

Возьмем три реальных случая, каждый из которых стоил кому-то очень дорого.

Zerologon (CVE-2020-1472). Критическая уязвимость в протоколе Netlogon, позволяющая захватить контроллер домена. Microsoft выпустил патч 11 августа 2020 года, все его поставили, галочку поставили тоже. Но патч работал в два этапа. Августовское обновление закрывалао основной вектор, но для сторонних не-Windows устройств только включало логирование и позволяло перейти в защищенный режим, а по умолчанию продолжало пропускать уязвимые подключения ради совместимости. Принудительный режим для всех вариантов включился отдельным обновлением 9 февраля 2021 года, а до этого его надо было активировать вручную через ключ реестра. Полгода тысячи компаний жили с “установленным патчем” и открытой уязвимостью.

Citrix Bleed (CVE-2023-4966). Уязвимость отдавала атакующему сессионные токены в обход пароля и двухфакторной аутентификации. Citrix выпустил патч, компании обновились. Проблема в том, что патч закрывал возможность украсть новые токены, а те, что уже утекли, оставались валидными. Citrix пришлось отдельным бюллетенем объяснять: после обновления обязательно принудительно завершите все активные и сохраненные сессии. Кто прочитал только первую строчку про “обновитесь” - обновился и был взломан через ранее украденную сессию.

Log4Shell (CVE-2021-44228). Здесь неполным оказался сам патч. Версия 2.15.0, выпущенная как исправление, закрывала уязвимость не во всех конфигурациях - появился CVE-2021-45046, потом 2.16.0, потом 2.17.0 после находки DoS-вектора, потом 2.17.1.

К этому добавьте бытовую классику, которая случается каждую неделю у всех:

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

• пакет обновлен, но сервис работает из памяти со старой версией библиотеки и не перезапускался

• обновили не тот компонент: закрыли библиотеку в системном пути, а приложение тащит свою копию внутри jar-архива

• обновление встало с ошибкой, откатилось, и об этом никто не узнал, потому что никто не смотрел

Вывод из всего этого один и он должен быть записан в вашем регламенте буквально:

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

Отсюда практика: после планового окна обновлений - контрольное сканирование затронутых активов. Расхождения между “ИТ закрыл задачу” и “сканер все еще видит” не нужно воспринимать как обвинение в адрес ИТ. В большинстве случаев это не халатность, а один из сценариев выше. Но разобрать расхождение надо всегда: пока вы этого не сделали, актив у вас числится закрытым, а на деле открыт, и все дальнейшие цифры считаются от неверной картины.

Почему уязвимости возвращаются

Есть отдельный жанр расхождений, который заслуживает своего раздела. Уязвимость устранили, проверили, закрыли. Через месяц она снова в отчете.

Показательный механизм - ProxyLogon (CVE-2021-26855) в Microsoft Exchange, уязвимость, через которую в марте 2021 года ломали всех подряд.

Обновления безопасности Exchange привязаны к конкретной сборке накопительного обновления и при переходе на другую сборку не переносятся. Microsoft тогда объясняла это на конкретных примерах: поставили мартовский патч на Exchange 2019 CU7, потом обновились до CU8 - ставьте патч заново. Перешли в Exchange 2016 с CU18 на CU19 - то же самое.

Причина не в том, что накопительное обновление старше или новее по номеру, а в дате его сборки. Накопительные выходят примерно раз в полгода, экстренные патчи - когда прижмет. Поэтому очередной CU по графику почти всегда собран раньше, чем вышел свежий аварийный патч, и просто не содержит его внутри. Мартовский фикс приехал “из коробки” только в Exchange 2019 CU9 и 2016 CU20, которые вышли уже после 2 марта.

Итог: ИТ выполняет плановое обслуживание, все делает правильно с точки зрения жизненного цикла продукта - и своими руками возвращает критическую уязвимость на периметр. Публичных разборов инцидентов, где кого-то повторно взломали именно так, я не нашел. Но Microsoft сочла нужным предупредить об этом отдельным пунктом, а для совсем старых сборок написала прямо: установите этот патч, а потом накатите более поздний CU - и сервер снова станет уязвим.

У той же истории есть второе дно и тут Microsoft высказалась совсем прямо: установка мартовских обновлений критична, чтобы предотвратить повторное заражение, но она не выселит злоумышленника, который уже скомпрометировал ваш сервер. Веб-шеллы, размещенные до обновления, продолжают работать.

Дальше арифметика простая. Сканер уязвимостей смотрит на версию сборки и наличие патча - и после обновления честно показывает зеленый статус. Веб-шелл лежит в файловой системе, и к версии сборки он отношения не имеет. Поэтому Microsoft выпускала под эту задачу отдельные инструменты: обновленный MSERT, который искал известные веб-шеллы, скрипт Test-ProxyLogon для анализа логов и EOMT, разом применявший временные меры и запускавший проверку. Отсюда общее правило: если уязвимость на периметре провисела достаточно долго, устранение обязано сопровождаться проверкой на компрометацию.

Помимо истории с накопительными обновлениями, есть еще три типовых механизма возврата, и все они об одном:

• Необновленный золотой образ. Хост развернули из шаблона, в шаблоне старые пакеты. Пропатчили. Через месяц из того же шаблона развернули пять новых хостов - уязвимость вернулась впятером.

• Откат снапшота. Виртуалку откатили на состояние до обновления, потому что что-то сломалось. Вместе с поломкой откатили и патч.

• Конвейер сборки. Контейнер собирается из базового образа, базовый образ не обновлялся полгода. Пропатчить работающий контейнер бессмысленно: при следующем деплое приедет старая версия.

Последний пункт сейчас самый массовый. По данным исследования ActiveState за 2026 год, 83% руководителей ИБ называют устаревшие базовые образы главной причиной уязвимостей в своих системах [8]. А опрос Mondoo показал, что 40% респондентов сталкиваются с повторным появлением уже устраненных уязвимостей более чем в 5% случаев [9].

Отсюда правило, которое экономит больше всего сил:

Если уязвимость вернулась - чините не хост, а конвейер.

Уязвимость на живом хосте - симптом. Причина находится выше по течению: в шаблоне виртуальной машины, в базовом образе контейнера, в дистрибутиве, из которого разворачивают. Пока не обновлен источник, вы будете закрывать одну и ту же уязвимость бесконечно, и ваши метрики “устранено за месяц” будут расти при полной неизменности реального положения дел.

Практическое следствие: заведите золотые образы и базовые образы как отдельные объекты процесса VM. Они должны сканироваться, у них должен быть SLA, у них должен быть владелец. Один обновленный шаблон закрывает уязвимость на всех будущих хостах разом - это лучшее соотношение усилий к результату во всем процессе.

Контроль устранения

Следующий этап - контроль. Нужно регулярно проверять, что обнаруженные уязвимости устраняются в согласованные сроки.

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

Если уязвимость не устранена в срок, причин всего две: либо ею никто не занимался, либо что-то сделали, но без результата. Второй вариант мы разбирали в предыдущих двух разделах, и он встречается чаще, чем принято думать. Чтобы понять, какой из двух случаев перед вами, ибэшник связывается с администратором актива и обязательно фиксирует статус и дальнейшие шаги. Разговор без фиксации не считается: через две недели никто не вспомнит, о чем договорились.

Теперь про масштаб проблемы, чтобы понимать, где вы находитесь относительно рынка.

По данным “Информзащиты” за первый квартал 2025 года, российские компании своевременно устраняют лишь 56% уязвимостей, найденных по итогам пентестов. Для критических уязвимостей, где нормативный срок - 24 часа, не укладывается в срок 28%. Для высоких, где норматив 7 дней, - тоже 28%. Уязвимости среднего уровня при рекомендованных 14 днях устраняются в среднем за 35 дней. Хуже всего дела в образовании и здравоохранении: там не устраняется вовремя более 70% [10].

Мировая картина не лучше. По Verizon DBIR полностью устраняется лишь около четверти уязвимостей из каталога активно эксплуатируемых, а медиана времени устранения измеряется неделями [4]. Bitsight в своем исследовании каталога KEV насчитал средний срок устранения критических KEV в 137 дней, а высоких - в 238 дней [11]. Четыре с половиной и почти восемь месяцев соответственно - для уязвимостей, про которые официально известно, что их эксплуатируют прямо сейчас.

Зачем эти цифры в главе про контроль? Затем, что они задают правильную реакцию на просрочки.

Если у вас систематически не соблюдается SLA, первый рефлекс - пойти ругаться с ИТ. Он почти всегда неправильный. Систематическое несоблюдение сроков - явное основание пересмотреть SLA, а не наказать исполнителя. Возможно, он изначально был нереалистичным: 24 часа на критическую уязвимость выглядят прекрасно в регламенте и невыполнимо, если обновление требует тестирования на трех стендах и согласования простоя с бизнесом.

Различать эти две ситуации несложно. Смотрите на распределение просрочек:

• просрочки размазаны по всем командам и всем типам активов - проблема в SLA

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

• просрочки выросли скачком в конкретный месяц - ищите событие: сменился ответственный, ушел человек, сломалась интеграция с трекером, и задачи месяц падали в никуда

Третий сценарий, к слову, самый частый и самый обидный. Он лечится за один разговор, но только если вы вообще смотрите на динамику, а не на абсолютное число.

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

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

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

Договорились - сделали - посмотрели, что вышло - поправили договоренности.

Первые два шага мы уже разобрали: договоренности - это SLA, роли и регламенты из предыдущей главы, выполнение - это все, о чем шла речь выше. Остаются два последних.

Посмотрели, что вышло. Собрали данные о результатах, сверили с показателями, нашли отклонения, разобрались в причинах. Не “число уязвимостей выросло, все плохо”, а “число просроченных выросло вдвое, причем весь рост дала одна группа активов”.

Поправили. В учебнике это называется управленческим воздействием, а на практике выглядит как разговор и как правка документа. Просрочки выросли вдвое - идем разбираться. Выяснилось, что у ИТ сменился ответственный и три недели задачи падали в никуда. Чиним не уязвимости - чиним маршрут задач и заводим уведомление о задачах без исполнителя. Это и есть четвертая буква в PDCA: не найти виноватых, а убрать причину, из-за которой цифра поехала.

Важно, что цикл именно цикл. Поправленные договоренности становятся входом для следующего витка: новый SLA - новое выполнение - новый замер. Процесс VM не строится один раз, он подкручивается постоянно.

Способы контроля

Контролировать процесс можно тремя способами, и работают они вместе, а не вместо друг друга:

• по показателям эффективности

• через дашборды

• через отчеты

Показатели. Для каждого этапа определяем показатели и целевые значения: что хорошо, что плохо. Хорошая практика - задавать не одно значение, а пороги: какие значения нормальные, какие допустимые, какие критические. Тогда становится понятно, когда надо просто присмотреться, а когда - бежать.

Дашборды. Дашборд - набор визуализаций, объединенных бизнес-логикой. Глаза безопасника. Хорошо, когда VM-инструмент дает собирать их из накопленных данных как вам надо, а не показывает три штуки, зашитые вендором, ну или хотя-бы дает возможность вытащить информацию через API.

Отчеты показывают результаты выполнения процедур. Форматы и состав отчетности согласовывайте со всеми заинтересованными сторонами: ИТ, владельцами активов, при необходимости - управлением рисками.

Дашборды под аудиторию

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

Стратегический дашборд - для руководства, включая директора по ИБ. Минимум информации, крупные цифры, быстрый обзор. Меняется редко. Что на нем разумно держать:

• доля значимых активов с критичными уязвимостями и ее динамика за квартал

• соответствие нормативным срокам устранения (укладываемся или нет, в процентах)

• покрытие инфраструктуры процессом VM

• статус по трендовым уязвимостям: сколько появилось, сколько закрыто, сколько в работе

Четыре-пять виджетов, не больше. Если руководителю приходится скроллить, дашборд не работает.

Операционный дашборд - для специалистов ИБ и VM. Это то, что открывают утром в понедельник. Здесь нужна динамика и адресность:

• очередь на сегодня: трендовые и критичные на значимых активах

• задачи, у которых истекает срок на этой неделе

• задачи, закрытые исполнителем, но не подтвержденные пересканированием (тот самый список расхождений)

• активы, не сканировавшиеся дольше положенного

• новые активы за период - те, что появились и еще не заведены в процесс.

Аналитический дашборд - для расследований. Открывается тогда, когда операционный показал странное. Здесь важна возможность резать данные по срезам: по подразделениям, по типам ОС, по владельцам активов, по возрасту уязвимости. Задача - найти причину, а не отследить состояние.

Универсального дашборда не существует

Это деление на три типа - схема. В реальности все еще индивидуальнее, и лучше принять это сразу, чем полгода искать правильный набор виджетов.

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

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

Отсюда практический совет, экономящий недели работы: не проектируйте дашборд, пока не поговорили с тем, кто будет на него смотреть. Спросите прямо: какое решение вы принимаете, глядя на этот экран? Если ответа нет - дашборд не нужен, нужен отчет раз в квартал. Если ответ есть - вы уже знаете, какие два-три виджета на нем должны быть.

Общее правило все же работает: у руководства запросы принципиально другие, чем у инженеров. Руководителю нужен ответ на вопрос “у нас все хорошо и что делать дальше”, инженеру - “что чинить сегодня”. Это разные экраны, и попытка их совместить дает документ, бесполезный обоим.

Три способа испортить хороший дашборд

• Светофор без тренда. Зеленый вчера и зеленый сегодня - разные зеленые, если между ними число выросло вдвое, просто не дотянув до порога. Статус без стрелки динамики не значит ничего.

• Средняя температура по больнице. Один MTTR на всю компанию прячет главное: критические тянутся месяцами, а низкие закрываются пачками за час. Режьте по критичности и по значимости активов, всегда.

• Дашборд без читателя. Назовите человека, который открывает этот экран и принимает по нему решения. Не можете назвать - дашборд не нужен. Такой экран отнимает время дважды: сначала когда вы его собираете, потом когда поддерживаете, а смотреть на него все равно никто не приходит.

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

Процесс VM нельзя оценивать по одному показателю. Значения бывают абсолютными (число) и относительными (доля, процент). Рекомендую относительные: абсолютное “10 000 уязвимостей” само по себе мало о чем говорит - это много или мало для инфраструктуры в 20 тысяч хостов? А вот “3% значимых активов содержат критичные уязвимости” - уже информация. И всегда смотрите изменение за период, чтобы видеть тренды.

В первую очередь рекомендую смотреть на критичные уязвимости по методике оценки уровня критичности ФСТЭК (актуальная редакция от 30.06.2025) [2]. Методика учитывает и уровень критичности уязвимости, и значимость актива, на котором она найдена, и доступность эксплойта - то есть дает не абстрактный балл, а оценку с оглядкой на вашу инфраструктуру.

Главный показатель: доля активов с критичными уязвимостями по методике ФСТЭК. Считается как количество активов с критичными уязвимостями, деленное на общее количество активов, умноженное на 100%. Чем меньше, тем лучше.

Тем, кто подпадает под приказ ФСТЭК № 117, метрики теперь не факультативны. Приказ вводит два показателя: Кзи - показатель текущей защищенности информации, рассчитывается не реже раза в шесть месяцев, и Пзи - показатель зрелости процессов защиты информации, рассчитывается не реже раза в два года [1]. Плюс те самые сроки устранения: 24 часа на критические уязвимости, 7 дней на высокие, и сканирование не реже раза в месяц.

Приказ вступил в силу 1 марта 2026 года, и практика применения только формируется - вопросов пока больше, чем разъяснений. Но направление понятно: измеримость процесса стала нормативным требованием, а не хорошим тоном.

Помимо главного показателя, полезен набор метрик по этапам процесса. Разберем их по группам.

Контроль инвентаризации активов

Что считать нормой: покрытие ниже 90% обесценивает все остальные метрики - вы измеряете не инфраструктуру, а ее часть. По периметру и значимым системам цель только 100%, без вариантов. Отдельно следите за знаменателем: если вы делите активы в VM на активы, известные VM, вы всегда получите 100%. Знаменатель обязан приходить из внешнего источника - CMDB, данные ИТ, инвентаризация сети.

Контроль установки политик устранения (SLA)

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

Контроль распространения уязвимостей

Что считать нормой: трендовые уязвимости - единственная строка в этой таблице, где целевое значение равно нулю, и добиваться этого нужно всерьез. Напомню масштаб: за одиннадцать месяцев 2025 года ФСТЭК выделила 63 трендовые уязвимости, и для 47 из них зафиксирована реальная эксплуатация в атаках [12]. Тысячами тут и не пахнет: список вполне обозримый, и отчитываться по нему можно поштучно.

Последние две строки полезно смотреть вместе. Если число активов растет быстрее, чем вы успеваете заводить их в процесс, никакие остальные метрики уже не помогут - вы отстаете от собственной инфраструктуры.

Контроль устранения уязвимостей

Две строки в этой таблице - “подтверждено пересканированием” и “повторно появившиеся” - в классических наборах метрик обычно отсутствуют, и зря. Первая измеряет качество процесса устранения, вторая - качество процесса в целом. Если у вас 30% заявленных как устраненные не подтверждаются пересканированием, чинить надо не уязвимости, а процедуру. Если уязвимости стабильно возвращаются - смотрите раздел про золотые образы.

MTTR (mean time to remediate) заслуживает отдельного разговора, и он будет в главе про метрики и зрелость: там и разбивка по уровням критичности, и отраслевые бенчмарки, и лестница зрелости. Здесь хватит двух правил. Считайте MTTR раздельно по критичности - общий бесполезен. И считайте его от момента обнаружения, а не от момента создания задачи: между этими двумя точками порой лежат недели, и как раз там прячется самая интересная часть вашего процесса.

Метрики, которые врут

А теперь самый важный раздел этой главы.

У одного клиента KPI подразделений строился на количестве устраненных уязвимостей. Причем не абсолютно, а в сравнении с другими подведомственными организациями: рейтинг, красная зона внизу, и попадание в красную зону означало отсутствие премии. Мотивация была выстроена железно - никто не хотел быть красным, все стремились устранять больше.

И все действительно устраняли больше. Цифры в отчетах росли. Динамика была прекрасная.

Понимаете, в чем подвох? Метрика измеряла количество, а не риск. Закрыть двести низких уязвимостей на тестовом стенде - двести очков. Закрыть одну критическую на контроллере домена, потратив неделю на согласование простоя, - одно очко. Рациональное поведение в такой системе - идти туда, где уязвимости закрываются пачками и без сопротивления. Что все и делали, совершенно честно и добросовестно.

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

MTTR. Исключите из регулярного сканирования пару старых сегментов, где все запущено и ничего быстро не чинится. Средний срок устранения похорошеет уже к следующему отчету. Никто ничего не подделывал - просто поменялся состав измеряемого.

Покрытие. “Покрытие 100%” почти всегда читается как “100% от того, что мы знаем”. Активы, о которых VM не в курсе, в знаменатель не попадают по определению.

Самая типовая дыра здесь - плохо инвентаризованное сетевое оборудование. Коммутаторы прекрасно знают о десятках узлов: они видны в ARP-таблицах, они обмениваются трафиком, они живые. Но в CMDB их нет, в системе VM их нет, никто их не сканирует, и в знаменателе покрытия они не появляются. Дашборд показывает покрытие под сотню процентов, SLA соблюдается, все зеленое.

“Устранено”. Вывели из эксплуатации стеллаж старых серверов - и в отчете красуется “закрыто 10 000 уязвимостей за квартал”. Формально правда. По сути вы не устранили ни одной, вы выключили питание.

Просрочки. А как быстрее всего избавиться от просроченных задач? Смягчить SLA. Наутро после пересмотра просрочек нет. Сам пересмотр бывает полностью оправданным, я про это писал выше. Разница в том, зафиксировали вы его как осознанное решение или тихо поправили цифру накануне отчета.

И универсальная отмычка - ложные срабатывания. Если признание находки ложной не требует ни обоснования, ни проверки, закрыть можно что угодно и в любых количествах.

Как с этим жить? Три приема.

Первый: измеряйте парами. У каждой метрики скорости должна быть метрика качества. Количество устраненных - в паре с долей подтвержденных пересканированием. MTTR - в паре с покрытием (быстрый MTTR по трети инфраструктуры ничего не стоит). Доля просроченных - в паре с числом пересмотров SLA за период.

Второй: не привязывайте KPI к абсолютным числам. Если уж строить мотивацию на метриках, стройте ее на риск-взвешенных показателях: доля значимых активов без критичных уязвимостей, время закрытия трендовых уязвимостей, отсутствие просрочек по критическому контуру. Тогда рациональное поведение сотрудника совпадает с интересами безопасности, а не расходится с ними.

Третий, и самый надежный: периодически проверяйте цифры реальностью.

Как понять, что процесс работает

Выстроенный процесс отвечает нескольким критериям:

• у процесса есть владелец - конкретный человек с полномочиями, а не строчка в регламенте

• роли, функции и зоны ответственности распределены

• участники знают свои обязанности, выполняют их и разбираются каждый в своем

• для автоматизации используются современные технологии, и команда умеет ими пользоваться

• регулярно собираются метрики, по которым видно, в каком состоянии процесс

• у каждой уязвимости есть один из трех законных исходов, и ни одна не висит без статуса

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

А если атакующий - своя red team, внешний пентестер или исследователь на багбаунти - легко доходит до недопустимого события через незакрытую уязвимость, значит, где-то между сканером и дашбордом рвется цепочка.

Зеленые цифры на дашборде могут врать. Успешно отраженная атака - нет. Подробнее о том, как выстроить эту проверку и как выглядит лестница зрелости VM-процесса, - в главе про метрики и зрелость.

Несколько практических советов напоследок

• Инвентаризируйте и оценивайте активы поэтапно. Разделите инфраструктуру на сегменты и налаживайте процесс в каждом по очереди, распространяя на новые сегменты процедуры инвентаризации, риск-рейтинга и контроля защищенности. Попытка объять все сразу заканчивается тем, что не сделано нигде.

• Заведите золотые образы в процесс. Один обновленный шаблон закрывает уязвимость на всех будущих хостах. Это лучшее соотношение усилий к результату во всем VM.

• Не забывайте про legacy. Активы, которые вендор больше не поддерживает в части безопасности, требуют отдельного внимания и компенсирующих мер. И отдельного разговора с бизнесом о сроках вывода из эксплуатации.

• Ставьте срок пересмотра на все, что не патч. Компенсирующая мера, принятие риска, признанное ложное срабатывание - у каждого должна быть дата, когда вы вернетесь и перепроверите.

• Используйте результаты анализа для улучшения. Корректируйте сроки SLA, параметры KPI и метрики по накопленному опыту. Процесс VM живой, он должен эволюционировать.

А как у вас?

Каждый ваш ИТ-админ получает только свои уязвимости - или всем прилетает общий отчет на тысячу страниц? И сколько у вас задач, закрытых исполнителем, но не подтвержденных пересканированием - вы вообще смотрите на это расхождение или доверяете статусу в трекере?

А если у вас KPI завязан на количество устраненных уязвимостей - расскажите, куда это в итоге привело. Подозреваю, истории будут узнаваемые.

? Источники и ссылки

Источники главы

1. Приказ ФСТЭК России от 11.04.2025 № 117 (вступил в силу 01.03.2026): сроки устранения (критические - 24 часа, высокие - 7 дней), периодичность сканирования не реже раза в месяц, показатели Кзи (раз в 6 месяцев) и Пзи (раз в 2 года).

2. Методика оценки уровня критичности уязвимостей программных, программно-аппаратных средств, ФСТЭК России (28.10.2022, актуальная редакция от 30.06.2025).

3. Совместное исследование BI.ZONE и Сбера (представлено на BI.ZONE Days 2026): сокращение показателя Time-to-Exploit примерно в 20 раз за два с половиной года, ниже 40 дней к концу 2025 года.

4. Verizon Data Breach Investigations Report (издания 2025 и 2026 годов): медиана времени до массовой эксплуатации edge-KEV - 0 дней; доля полностью устраненных уязвимостей из каталога KEV - около четверти; медиана полного устранения - 43 дня.

5. Qualys Threat Research Unit, “The Broken Physics of Remediation”, март 2026 (анализ более 1 млрд записей об устранении по 10 000+ организаций): 85% уязвимых активов непропатчены на момент раскрытия; доля критических уязвимостей, открытых через 7 дней, выросла с 56% в 2022 г. до 63% в 2025 г.; рост числа закрытых уязвимостей с 73 млн (2022) до 473 млн (2025).

6. Cyentia Institute и Kenna Security, “Prioritization to Prediction, Volume 3: Winning the Remediation Race”, 2019: организация закрывает примерно одну из десяти открытых уязвимостей в месяц. Более свежего прямого пересчета метрики в открытых источниках найти не удалось.

7. Hadrian, “2026 Offensive Security Benchmark Report” (анализ 300 сред): 0,47% находок сканеров уязвимостей реально эксплуатируемы на практике.

8. ActiveState, “2026 State of Vulnerability Management & Remediation Report”: 83% руководителей ИБ называют устаревшие базовые образы главной причиной уязвимостей.

9. Mondoo, “2025 State of Vulnerability Remediation” (опрос): 40% респондентов сталкиваются с повторным появлением устраненных уязвимостей более чем в 5% случаев.

10. “Информзащита”, данные по итогам пентестов за I квартал 2025 года: своевременно устраняется 56% уязвимостей; 28% критических и 28% высоких не укладываются в нормативные сроки; средние уязвимости при рекомендованных 14 днях устраняются в среднем за 35 дней.

11. Bitsight, “A Global View of the CISA KEV Catalog: Prevalence and Remediation”, 2024: более 60% KEV остаются неустраненными после дедлайнов; средний срок устранения критических KEV - 137 дней, высоких - 238 дней.

12. Данные БДУ ФСТЭК за 11 месяцев 2025 года: 63 трендовые уязвимости, для 47 из них зафиксирована реальная эксплуатация в атаках.

13. Технические детали разобранных случаев: бюллетени и рекомендации Microsoft по CVE-2020-1472 (двухэтапное включение защищенного режима Netlogon, принудительный режим с 09.02.2021) и по CVE-2021-26855 (привязка обновлений безопасности Exchange к сборке накопительного обновления; необходимость проверки на компрометацию после патча); бюллетень Citrix по CVE-2023-4966 (необходимость принудительного завершения сессий после обновления); история версий Apache Log4j 2.15.0-2.17.1 и связанные CVE-2021-45046, CVE-2021-45105.

---

Навигация по серии: ⬅️ Предыдущая: Гл. 6. VM ломается не на сканере, а на людях · ? Оглавление серии · Следующая: Гл. 8. Host Discovery, черный и белый ящик ➡️

Если у вас в инфраструктуре что-то устроено иначе - расскажите в комментариях. Зашло - подписывайтесь, чтобы не пропустить следующую часть.