Как внедрить Vulnerability Management: пошаговый план
Почему большинство VM-программ не работают
Vulnerability Management — одна из самых распространённых практик в корпоративной ИБ. И одна из самых часто имитируемых. В большинстве компаний процесс выглядит примерно так: раз в квартал запускают сканер, получают отчёт на несколько тысяч строк, пересылают его ИТ-команде — и ждут. ИТ патчит то, что успевает. Через квартал картина почти не меняется.
Это не Vulnerability Management. Это периодическое сканирование, замаскированное под управление рисками. Разница принципиальная: VM — это непрерывный, структурированный процесс с чёткими ролями, SLA, метриками и интеграцией в общий ИБ-контур. Не инструмент. Не отчёт. Процесс.
Внедрение VM проваливается по нескольким типичным причинам: нет инвентаря активов — сканер «не видит» половину инфраструктуры; нет приоритизации — команда тонет в тысячах CVE одинакового приоритета; нет ответственных за ремедиацию — тикеты висят без движения; нет верификации — «исправлено» в комментарии к тикету не означает реального закрытия уязвимости. Эта статья — пошаговый разбор того, как выстроить VM-программу, которая реально работает.
💡 По данным Recorded Future, более 60% успешных кибератак в 2025 году использовали уязвимости, для которых патч существовал более 30 дней. Проблема не в отсутствии патчей — проблема в отсутствии процесса их своевременного применения.
Что нужно сделать до первого сканирования
Самая частая ошибка при запуске VM — начать с установки сканера. Логично? На первый взгляд. Но сканер, запущенный без инвентаря и без назначенных ответственных, сгенерирует тысячи строк, которые некому разбирать. Первые два шага — организационные, и именно от них зависит, взлетит ли программа.
Шаг 1: определите скоуп и назначьте владельцев
VM затрагивает сразу три команды: ИБ, ИТ и разработку. Без явного спонсорства на уровне CISO или CTO команда ИБ будет бесконечно «просить» коллег ставить патчи — без реального SLA и ответственности. Это нежизнеспособная модель.
Зафиксируйте на старте три вещи. Первое — скоуп первой итерации: не берите сразу всю инфраструктуру, начните с internet-facing активов — они несут наибольший риск и дают быстрый результат. Второе — матрицу владельцев: для каждой группы активов должен быть назначен ответственный за ремедиацию. Без этого тикеты будут висеть вечно. Третье — SLA на исправление: зафиксируйте до запуска, а не после. P1 — 72 часа, P2 — 30 дней, P3 — 90 дней. Конкретные цифры согласуйте с бизнесом.
💡 Без спонсора на уровне топ-менеджмента VM превращается в «рекомендации», которые никто не обязан выполнять. Это не техническая проблема — это проблема управления. Решается до первого сканирования, а не после.
Шаг 2: проведите инвентаризацию активов
Нельзя защитить то, о чём не знаешь. Нельзя просканировать то, чего нет в реестре. Инвентаризация — фундамент всей VM-программы: «слепые зоны» инвентаря автоматически становятся неуправляемыми рисками.
В скоуп инвентаризации входят: физические серверы и виртуальные машины, контейнеры и Kubernetes-кластеры, облачные ресурсы (AWS EC2, Azure VM, GCP), рабочие станции и ноутбуки, сетевые устройства, веб-приложения и API, сторонние SaaS-платформы. Инструменты сбора — CMDB-системы (ServiceNow, Jira Service Management), агенты на хостах (Tenable, Qualys Cloud Agent), облачные API (AWS Config, Azure Resource Graph), пассивное обнаружение через сетевой трафик.
Параллельно с традиционной инвентаризацией стоит подключить EASM-инструменты для обнаружения внешней поверхности атаки. EASM находит теневые активы, забытые поддомены и внешние сервисы, которых нет в CMDB — именно они чаще всего становятся точками входа для атакующих.
Как запустить процесс сканирования
Шаг 3: выберите инструмент и настройте credentialed-сканирование
Рынок VM-инструментов широк — от бесплатных open-source решений до enterprise-платформ. Выбор зависит от размера инфраструктуры, бюджета и зрелости команды. Ключевые игроки на 2026 год:
Tenable Nessus / Tenable.io — один из самых распространённых коммерческих сканеров. Глубокое credentialed-сканирование, интеграция с ServiceNow и SIEM-системами, приоритизация по VPR. Qualys VMDR — облачная платформа с акцентом на автоматизации полного цикла: обнаружение, оценка, приоритизация, оркестрация патчей, встроенная интеграция с CISA KEV и EPSS. MaxPatrol VM от Positive Technologies — российское решение с акцентом на покрытие отечественной инфраструктуры и соответствие требованиям ФСТЭК. Microsoft Defender Vulnerability Management — нативное решение для Microsoft-сред без дополнительных агентов. Для небольших команд — OpenVAS / Greenbone (open-source) и Trivy для контейнерной среды.
💡 Сканирование без учётных данных пропускает в среднем 40–60% уязвимостей на хосте. Credentialed-сканирование на порядок точнее — оно видит установленные пакеты, версии ПО и конфигурации. Настройка сервисных аккаунтов для сканера — обязательный шаг, который нельзя пропускать.
Шаг 4: выстройте расписание и покрытие
Ежедневно NVD публикует 50–70 новых CVE. Инфраструктура меняется с той же скоростью: DevOps разворачивает новые сервисы, облачные ресурсы создаются по запросу, конфигурации дрейфуют. Снимок состояния месячной давности не отражает реальности — только непрерывное сканирование даёт актуальную картину рисков.
Практические рекомендации по расписанию: internet-facing активы — сканировать еженедельно или при каждом изменении конфигурации; внутренние критичные системы (продакшн, базы данных, AD) — еженедельно; некритичные внутренние активы — ежемесячно. Параллельно настройте непрерывный мониторинг через агенты — он позволяет обнаруживать новые уязвимости сразу после публикации CVE, не дожидаясь планового скана. Метрику Scan Coverage — долю инфраструктуры, покрытой сканированием — отслеживайте как базовый KPI программы.
Приоритизация: от 10 000 CVE к списку на сегодня
Первый скан почти всегда шокирует. Тысячи уязвимостей, сотни Critical — и ощущение, что инфраструктура разрушена. На самом деле это нормальное стартовое состояние для большинства организаций. Задача приоритизации — не испугаться этих цифр, а отделить реально опасные уязвимости от шума.
Шаг 5: применяйте CVSS + EPSS + KEV вместе
Три метрики работают в связке — каждая добавляет отдельное измерение риска. Подробный разбор каждой из них — в статье «CVSS, EPSS и KEV: как приоритизировать уязвимости правильно». Здесь — практическая логика применения.
CVSS (Common Vulnerability Scoring System) — базовая оценка тяжести уязвимости от 0 до 10. Описывает уязвимость «в вакууме»: вектор атаки, сложность эксплуатации, влияние на CIA. Главное ограничение: CVSS не говорит, эксплуатируется ли уязвимость в реальных атаках прямо сейчас. EPSS (Exploit Prediction Scoring System) от FIRST.org — вероятность эксплуатации в ближайшие 30 дней, обновляется ежедневно на основе ML. Лишь около 5% всех CVE имеют EPSS выше 0,1% — это и есть та группа риска, на которой стоит сосредоточиться. CISA KEV (Known Exploited Vulnerabilities) — каталог CVE с подтверждённой эксплуатацией в реальных атаках. Это не вероятность, а факт. Если ваш актив затронут CVE из KEV и доступен из интернета — это экстренная задача.
Шаг 6: учитывайте контекст инфраструктуры
Метрики без контекста дают неполную картину. CVSS 9.8 на уязвимость в RDP не критична, если RDP закрыт на периметре и доступен только через VPN с MFA. CVSS 7.2 на уязвимость в публично доступном web-сервере без WAF — это P1, который нельзя откладывать. При приоритизации учитывайте: критичность актива (продакшн vs тестовая среда, есть ли клиентские данные), наличие компенсирующих контролей (WAF, сегментация, MFA), blast radius — насколько компрометация актива влияет на смежные системы.
💡 Практическое правило приоритизации: P1 — CVE из KEV на internet-facing активе без компенсирующих контролей (устранить за 72 часа). P2 — KEV с барьерами или высокий EPSS на критичном активе (7–14 дней). P3 — высокий CVSS без KEV/EPSS (30–90 дней). Остальное — плановая ремедиация или осознанное принятие риска.
Ремедиация: как превратить тикет в закрытую уязвимость
Приоритизация без ремедиации — красиво оформленный список проблем, которые никуда не делись. Ремедиация — самый «трудный» этап VM не технически, а организационно: она требует координации между ИБ, ИТ и разработкой, а значит — чётких ролей, инструментов и контроля.
Шаг 7: настройте ITSM-интеграцию и SLA
Каждая приоритизированная уязвимость должна превращаться в тикет в ITSM-системе (Jira, ServiceNow) с конкретным содержанием: CVE-идентификатор и его описание простым языком, затронутый актив и его владелец, рекомендация — установить патч версии X, изменить конфигурацию Y, закрыть порт Z, дедлайн по SLA, ссылка на CVE в NVD и, если применимо, KEV-статус.
Для массового патчинга используют инструменты автоматизации: Ansible, Puppet, Chef — для серверной инфраструктуры; Microsoft Intune, WSUS — для рабочих станций Windows; встроенные patch management модули Tenable и Qualys. В контексте DevSecOps-процессов VM-проверки встраиваются прямо в CI/CD: SCA-сканирование зависимостей при каждом коммите, сканирование контейнерных образов перед деплоем — уязвимости находятся до попадания в продакшн.
Шаг 8: compensating controls — когда патч невозможен
Бывают ситуации, когда быстрое применение патча невозможно: legacy-система без поддержки вендора, критичный бизнес-процесс с запретом на изменения, патч ещё не выпущен. В таких случаях применяют compensating controls — компенсирующие меры, снижающие риск эксплуатации: правила WAF для блокировки известных эксплойт-паттернов, IP-ограничения и сегментация сети, отключение уязвимого сервиса или компонента, дополнительный мониторинг и алертинг через SIEM.
💡 Compensating control — это временная мера, а не закрытие тикета. Срок действия меры должен быть зафиксирован и контролироваться: если через 90 дней ничего не изменилось — это сигнал либо к эскалации, либо к пересмотру архитектурного решения.
Верификация и метрики: как доказать результат
«Исправлено» в комментарии к тикету — не равно закрытой уязвимости. Реальность такова: патчи объявляются применёнными, но не применяются; откат конфигурации возвращает уязвимость через неделю; новые уязвимости появляются ровно там, где только что починили. Верификация — повторное сканирование, подтверждающее факт устранения — это единственный способ закрыть цикл.
После верификации данные агрегируются в метрики — язык VM для руководства. Без метрик программа невидима для бизнеса. Ключевые KPI VM-программы:
MTTR (Mean Time to Remediation) — среднее время от обнаружения до устранения, в разбивке по P1/P2/P3. Показывает скорость реакции. % уязвимостей, закрытых в SLA — дисциплина процесса: насколько команды соблюдают договорённые сроки. Exposure Window — среднее время жизни критичной уязвимости в инфраструктуре. KEV Coverage — доля активов, проверенных на наличие уязвимостей из CISA KEV. Scan Coverage — процент инфраструктуры, охваченной сканированием. Recurrence Rate — доля уязвимостей, появляющихся повторно: признак системных проблем с конфигурационным управлением или патч-менеджментом.
💡 Начните с трёх метрик: MTTR по P1, % закрытых в SLA и Scan Coverage. Этого достаточно для первого квартального отчёта руководству и для понимания узких мест программы. Сложные дашборды добавляйте по мере зрелости процесса.
VM и смежные процессы: интеграция в ИБ-программу
Vulnerability Management не существует в изоляции. В зрелой ИБ-программе он интегрирован с несколькими смежными дисциплинами — и именно эти связи делают VM по-настоящему эффективным, а не просто «ещё одним источником тикетов».
VM и EASM. Управление внешней поверхностью атаки решает вопрос «что сканировать». EASM обнаруживает теневые активы и внешние сервисы, которых нет в CMDB, — и передаёт их как входные данные для VM. Без EASM сканер покрывает только «известные» активы, пропуская самые уязвимые точки входа.
VM и SOC. Для SOC-аналитиков данные VM — важный контекст при расследовании инцидентов: знание о незакрытых уязвимостях на скомпрометированном хосте резко ускоряет определение вектора атаки. Events о новых критичных CVE могут автоматически создавать инциденты в SIEM и запускать SOAR-плейбуки. VM и DevSecOps. В зрелой DevSecOps-программе VM-проверки встроены в CI/CD: SCA-сканирование при каждом коммите, анализ контейнерных образов перед деплоем. Уязвимости находятся до попадания в продакшн — это кратно дешевле, чем устранять их в эксплуатации.
VM и Threat Intelligence. Данные TI обогащают приоритизацию: CVE, активно используемые в текущих ransomware-кампаниях, повышают приоритет автоматически — ещё до появления в CISA KEV. Это даёт выигрыш в несколько дней, который в случае атаки может стать решающим.
Курсы по Vulnerability Management
Освоить VM только в теории недостаточно — профессиональные навыки приходят на реальных инструментах и задачах. Ниже — программы с практическим уклоном: от системного погружения в процесс до работы с конкретными платформами.
Управление уязвимостями: процесс и инструменты
INSECA
Vulnerability Management (управление уязвимостями)
70% программы — практические задания, каждое из которых симулирует реальные задачи VM-специалиста: поиск уязвимостей в открытых источниках, настройка и запуск сканирования, анализ результатов, заведение заявок на устранение. Отдельный блок посвящён приоритизации с учётом контекста инфраструктуры и риск-ориентированного подхода, а также выстраиванию VM-процесса в организации совместно с ИТ-отделом. Есть бесплатный демодоступ.
Positive Technologies
Управление уязвимостями: от теории к практике
Асинхронный практикум от разработчика MaxPatrol VM, который проводит весь цикл управления уязвимостями: от инвентаризации активов и настройки политик значимости — до приоритизации угроз, организации ремедиации и выстраивания взаимодействия между командами ИБ и ИТ. В программе — видеоуроки, симуляции и воркшопы с разбором реальных кейсов; материалы доступны для скачивания и применения в рабочей практике.
Работа с конкретными инструментами
Информзащита
MaxPatrol 8: установка, настройка и управление уязвимостями
Авторизованный курс по MaxPatrol 8 от Positive Technologies: архитектура, методология сканирования, настройка политик и автоматизация задач управления уязвимостями в корпоративной сети.