Управление уязвимостями с нуля: что это, зачем и из каких этапов состоит / Хабр

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

Что такое уязвимости

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

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

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

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

Зачем устранять уязвимости

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

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

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

Где устранять уязвимости

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

Вот динамика по данным CVE Program: в 2023 году опубликовано 28 818 новых CVE, в 2024-м - 39 962 (рост почти на 39%), в 2025-м - 48 185 [1]. Это 133 новые уязвимости каждый день, включая выходные. Российская БДУ ФСТЭК тоже растет и уже перевалила за 89 тысяч записей [2]. Даже если в один прекрасный момент вы устраните все, завтра появится сотня новых.

Где же их искать

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

DMZ, то есть сетевой периметр
ключевые системы (например, внутренний firewall в ядре инфраструктуры, который занимается сегментацией сети)
целевые системы (базы данных, “1С” и все, ради чего хакер, собственно, и приходит)

На эти три области нужно обращать внимание прежде всего.

Где искать информацию об уязвимостях

Поиском уязвимостей далеко не всегда занимаются сами вендоры ПО. Чаще “дыры” находят независимые исследователи безопасности и сообщают о них разработчику. Вендор готовит патч, выпускает его и публикует информацию об уязвимости. Это называется ответственным разглашением.

Но так происходит не всегда. Бывают уязвимости нулевого дня (zero-day), о которых вендор узнает уже после того, как их начали эксплуатировать. О них мы подробно говорим в главе про эксплойты.

Идеальный подход для компании - киберучения и участие в программах багбаунти. Компания выставляет свое ПО на платформу, объявляет вознаграждение за найденные уязвимости и устраняет их. Эта культура уже прижилась и в России: в 2025 году белые хакеры нашли через две крупнейшие российские багбаунти-платформы (Standoff Bug Bounty и BI.ZONE Bug Bounty) почти 14 тысяч уязвимостей, а суммарные выплаты исследователям превысили четверть миллиарда рублей [3]. Чем больше вендор открыт рынку, чем честнее говорит о своих уязвимостях, тем лучше к нему в итоге относятся пользователи. Парадоксально, но факт. Хотя и тут можно поспорить, очень часто “публикацию уязвимостей” принимают за хайповый заголовок с контекстом - все пропало, софтом пользоваться больше нельзя!

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

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

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

Этапы построения процесса управления уязвимостями:

1. Asset management (инвентаризация) и категоризация активов

Чтобы ответить на вопрос “где искать уязвимости”, нужно понимать, из чего состоит инфраструктура. Процесс vulnerability management (VM) всегда опирается на процесс asset management (AM). Инвентаризация, как правило, уже есть в ИТ-департаменте на основе CMDB-систем. Но провести ее должен и департамент ИБ, причем своими глазами: ИТ не всегда делает акцент на системах, важных для безопасности, и, будем честны, не всегда охотно делится информацией с безопасниками (мы еще много будем говорить про взаимодействие между этими двумя отделами и надеюсь, что серией статей получится улучшить их взаимопонимание. Минимум, который нужен: инвентаризация ключевых, целевых систем и периметра.

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

Здесь же формулируется SLA - соглашение с ИТ-департаментом о сроках устранения. Критически опасную уязвимость недопустимо устранять три месяца. А если узел не так важен и уязвимость не самая страшная, можно спокойно дождаться планового обновления: например, для Windows - очередного Patch Tuesday.

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

2. Поиск уязвимостей и их приоритизация

Прежде чем определять SLA, уязвимости нужно найти. Каким способом - вручную, open source инструментами или коммерческими продуктами - не так важно. Главное, получить честную картину слабых мест. А затем категоризировать сами уязвимости: какие из них реально опасны именно в вашей инфраструктуре. Методы оценки и приоритизации мы подробно разберем позже.

3. Как устранить уязвимости

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

4. Устранение уязвимостей, чаще всего это процесс Patch-management

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

5. Контроль устранения и совершенствование процесса

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

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

Типовые проблемы

Не так давно был эфир AM Live по управлению уязвимостями. И в одном из опросов зрители назвали главные препятствия для полноценного управления уязвимостями в их организациях:

Что является главным препятствием для полноценного управления уязвимостями?

А вот какие проблемы выделил бы именно я:

Нет инвентаризации
Уязвимостей слишком много
Некачественные SLA или вообще их отсутствие
Отсутствие категоризации уязвимостей
Нарушение согласованных сроков устранения

Регуляторы, кстати, прекрасно знают об этих проблемах. ФСТЭК в 2022 году выпустила методику оценки критичности уязвимостей (обновлена в июне 2025-го), в мае 2023-го - руководство по организации процесса управления уязвимостями, а приказ № 117 сделал этот процесс обязательным для госсистем [4]. У НКЦКИ есть своя методика принятия решений по обновлениям. Тренд очевиден: управление уязвимостями из “хорошей практики” превращается в требование.

Еще в конце 2022 года (да и другие года не исключения) НКЦКИ в своем докладе называл незакрытые уязвимости на периметре основным путем проникновения злоумышленников во внутреннюю инфраструктуру. Показательный пример - уязвимость ProxyLogon в Microsoft Exchange, опубликованная в 2021 году. Спустя годы после выхода патча мы все еще находили ее в каждом 3 клиенте. Патч существует. Годами. Его просто не ставят. Почему? Да всегда ответ разный, смотрите на скриншот выше, проблем много)

Значимость процесса VM. Цели и задачи

Ландшафт киберугроз постоянно меняется и не в нашу пользу. По данным Mandiant в отчете M-Trends демонстрируется следующая картина: эксплойты - самый частый способ первоначального заражения (33% инцидентов) [6].

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

Если публичного эксплойта для уязвимости нет, его можно купить. Например, эксплойт для CVE-2022-24086 продавался на хакерских форумах за 30 000 (по данным Sansec, ноябрь 2022). Дорого? Для преступника это инвестиция: платформа распространена, через нее можно красть данные банковских карт (MageCart-атаки) или распространять вредоносное ПО. Затраты отбиваются на первой же жертве, особенно если речь об операторах программ-вымогателей: по данным Palo Alto Networks Unit 42, средняя сумма выкупа еще в 2022 году превышала 900 тысяч долларов [7]. Покупатели на дорогие эксплойты находятся.

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

Основная цель управления уязвимостями - замедлить или в идеале остановить хакера.

Когда хакер достигает периметра и начинает действовать, у нас целый арсенал: firewall для защиты веб-приложений, анализаторы кода, которые ловят ошибки до выхода ПО в продакшен, SIEM-системы для анализа событий, внутренний файрвол для обнаружения разведки в сети. Есть и продукты класса NTA (network traffic analysis): они смотрят в сетевой трафик и видят, проводит ли кто-то разведку или атаку, причем изнутри инфраструктуры, в отличие от классических IDS.

Но все эти средства работают лучше, когда хакеру тяжело. Цель VM - сделать так, чтобы вас не удалось взломать: в первую очередь через известные (1-day) уязвимости на периметре, затем через известные уязвимости во всей инфраструктуре. В идеале - максимально усложнить взлом даже через 0-day за счет анализа кода (SAST, DAST, IAST) и корректной настройки систем. Каждый закрытый путь - это дополнительное время для команды SOC, чтобы обнаружить злоумышленника и остановить его.

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

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

Если прям все подытожить, то мы получаем следующий тезис для специалиста по ИБ: “Меня не должны взломать через эксплуатацию уязвимостей”

Основные задачи управления уязвимостями

Инвентаризация активов - полный список информационных ресурсов и устройств организации с их атрибутами
Обнаружение уязвимостей - мониторинг источников (бюллетени вендоров, базы данных уязвимостей вроде NVD и БДУ ФСТЭК) и сканирование инфраструктуры специализированными инструментами
Определение уровня опасности - оценка влияния каждой уязвимости на защищенность организации: легкость эксплуатации, реальное воздействие на бизнес
Устранение уязвимостей - патчи, перенастройка, замена софта, усиленный мониторинг, отключения уязвимых компонентов, изменение бизнес процессов в случае принятия рисков или замены уязвимого софта
Контроль своевременного устранения - проверка, что уязвимости действительно закрыты и при этом не появились новые
Постоянное совершенствование - улучшение инструментов и методов, обучение персонала, обмен опытом с сообществом (надеюсь и мои материалы, помогут совершенствоваться)

Процесс VM в терминах результата

Своевременное устранение уязвимостей на периметре и ключевых активах

Времени на раскачку больше нет. По данным Mandiant, среднее время от публикации уязвимости до появления рабочего эксплойта сократилось до 5 дней, а каждая четвертая эксплуатируемая CVE атакуется уже в день публикации [6]. VulnCheck фиксирует еще более жесткую картину: почти 29% уязвимостей, для которых подтверждена эксплуатация, использовались злоумышленниками еще до публичного раскрытия [8]. Сканирование ваших систем начинается через считаные минуты после появления информации об уязвимости в открытом доступе, порой даже раньше, чем готов эксплойт.

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

Оперативное обнаружение и устранение shadow IT

Shadow IT - неофициальные и неконтролируемые части инфраструктуры: сервер, который поднял разработчик “на минуточку” три года назад, забытый тестовый стенд, сервис, заведенный в обход ИТ-отдела. Даже если средствами защиты покрыто 90% систем, взломают вас через оставшиеся 10%, о которых вы не знаете.

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

Уменьшение количества уязвимостей

Поток новых уязвимостей нарастает: 48 тысяч CVE за 2025 год против 25 тысяч за 2022-й [1]. Полностью “вычистить” инфраструктуру нельзя: через секунду после финального патча появится новая уязвимость. Это непрерывный процесс, и это нормально.

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

Понимание, какие уязвимости недопустимы, и мониторинг трендовых

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

Отдельного внимания заслуживают трендовые уязвимости - те, что активно эксплуатируются в атаках прямо сейчас. ФСТЭК помечает такие в БДУ (за 2025 год их набралось более двухсот [9]), вендора производящие системы анализа защищенности помечают у себя такие уязвимости, а в мире аналогичную роль играет каталог CISA KEV. Когда уязвимость попадает в эти списки, счет идет на часы.

А как у вас?

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

Дополнительные материалы:

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

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

Статистика публикации CVE: Jerry Gamblin, CVE Data Review за 2023-2025 годы. https://jerrygamblin.com/2026/01/01/2025-cve-data-review/
БДУ ФСТЭК России. https://bdu.fstec.ru/
Anti-Malware.ru: “В 2025 году белые хакеры нашли 13 690 уязвимостей в российских компаниях”, январь 2026.
Приказ ФСТЭК России от 11.04.2025 № 117 (вступил в силу 01.03.2026); методический документ ФСТЭК “Руководство по организации процесса управления уязвимостями в органе (организации)” от 17.05.2023; методика оценки уровня критичности уязвимостей ФСТЭК (ред. от 30.06.2025). https://fstec.ru/
Verizon Data Breach Investigations Report 2026.
Mandiant (Google Cloud), M-Trends 2025. https://cloud.google.com/blog/topics/threat-intelligence/m-trends-2025
Palo Alto Networks Unit 42, Ransomware Threat Report 2022.
VulnCheck, State of Exploitation Report (данные за 2025 год).
R-Vision, дайджест трендовых уязвимостей за 2025 год. https://rvision.ru/expertise/daydzhest-trendovykh-uyazvimostey-2025-god

Навигация по серии: ⬅️ Предыдущая: Гл. 0. “Да кому я нужен, меня не взломают” · 📑 Оглавление серии · Следующая: Гл. 2. Управление уязвимостями по-русски ➡️

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