Когда это становится задачей руководства
Управление уязвимостями становится управленческой задачей, когда у компании уже есть сканер, отчеты, критичные CVE и регулярные совещания, но непонятно, что чинить первым, кто владелец актива, какие сроки реалистичны и какой риск остается для бизнеса.
Эта страница для директора по ИБ, ИТ-директора, руководителя инфраструктуры, SOC, DevSecOps, владельцев критичных систем, проектного офиса и закупок. Особенно полезна банкам, промышленности, госсектору, ритейлу, телекому и компаниям с большим количеством серверов, рабочих мест, веб-сервисов, облачных ресурсов, подрядчиков и регулируемых контуров.
Что такое управление уязвимостями
VM означает Vulnerability Management, то есть управление уязвимостями. В зрелом корпоративном контуре это постоянный процесс: знать свои активы, регулярно находить уязвимости, понимать реальную опасность, назначать владельцев, контролировать устранение, перепроверять результат и показывать руководству динамику риска.
Сканер дает технические находки. Управление уязвимостями отвечает на другие вопросы: какие находки реально угрожают важному бизнес-процессу, что уже эксплуатируется злоумышленниками, где есть компенсирующие меры, где патч нельзя поставить сразу и какое решение нужно принять ответственному владельцу.
Термины без тумана
| Термин | Расшифровка | Что означает в проекте |
|---|---|---|
| VM | Vulnerability Management - управление уязвимостями. | Процесс, который связывает сканирование, активы, приоритизацию, задачи, сроки, исключения и отчетность. |
| CVE | Common Vulnerabilities and Exposures - публичный идентификатор известной уязвимости. | Общий язык для ИБ, ИТ, вендоров и подрядчиков при обсуждении конкретной уязвимости. |
| CVSS | Common Vulnerability Scoring System - система оценки технической тяжести уязвимости. | Базовая оценка серьезности, которую нужно дополнять контекстом актива, угроз и эксплуатации. |
| EPSS | Exploit Prediction Scoring System - прогноз вероятности эксплуатации CVE. | Помогает понять, какие уязвимости вероятнее будут использованы в ближайшем горизонте. |
| KEV | Known Exploited Vulnerabilities - каталог уязвимостей, которые уже эксплуатировались. | Сильный сигнал для ускоренного устранения, особенно для публичных и критичных систем. |
| ASM / EASM | Attack Surface Management / External Attack Surface Management - управление поверхностью атаки, в том числе внешней. | Помогает видеть домены, поддомены, IP, публичные сервисы, тестовые стенды и облачные точки доступа. |
| SLA | Service Level Agreement - согласованный срок выполнения. | В VM задает сроки устранения или обработки риска для разных классов активов и уязвимостей. |
| SIEM / SOAR | Сбор и корреляция событий ИБ / автоматизация реагирования. | Используются для связи уязвимостей, событий, инцидентов, плейбуков и отчетности SOC. |
| EDR / XDR | Обнаружение и реагирование на конечных устройствах / расширенная корреляция. | Показывают, где уязвимый хост реально подвергается активности и какие компенсирующие меры есть. |
| SCA / SBOM | Software Composition Analysis / Software Bill of Materials - анализ зависимостей и перечень компонентов ПО. | Нужны для DevSecOps, чтобы видеть уязвимые библиотеки, контейнеры и компоненты приложений. |
| ITSM / CMDB | Управление ИТ-сервисами / база конфигурационных единиц. | Помогают назначать владельцев, создавать задачи, связывать уязвимости с сервисами и контролировать статусы. |
Как работает процесс в крупной организации
Активы
Собираем серверы, рабочие станции, приложения, базы данных, сетевые устройства, облачные ресурсы, внешние сервисы, контейнеры и владельцев.
Сканирование
Настраиваем источники данных: внутренние и внешние сканеры, AppSec, SCA, endpoint, SIEM, CMDB, облака и ручные проверки.
Обогащение
Добавляем бизнес-критичность, экспозицию в интернет, наличие эксплуатации, CVSS, EPSS, KEV, компенсирующие меры и зависимости.
Приоритеты
Отделяем действительно срочные риски от шума: не все Critical одинаково важны, и не все Medium можно спокойно отложить.
Задачи
Создаем задачи в ITSM или очередь задач команды, фиксируем владельца, срок, вариант исправления, риск исключения и контрольную дату.
Проверка
Проводим повторное сканирование, сверяем фактическое устранение, закрываем ложные срабатывания и обновляем отчетность.
Отчетность
Показываем руководству динамику: что исправлено, что просрочено, где риск принят, какие системы требуют отдельного решения.
Приоритизация: что закрывать первым
Классическая ошибка VM-процесса - пытаться закрыть все уязвимости по техническому баллу. В реальности у ИТ ограниченные окна обновлений, есть legacy-системы, бизнес-критичные сервисы, подрядчики и регуляторные контуры. Поэтому приоритет должен учитывать и техническую тяжесть, и вероятность эксплуатации, и ценность актива.
| Сигнал | Как использовать |
|---|---|
| Критичность актива | Система платежей, личный кабинет, ГИС, КИИ, ERP, база с ПДн или публичный API получают больший вес, чем изолированный тестовый стенд. |
| Доступность из интернета | Внешний сервис с уязвимостью требует более жесткой реакции, чем внутренний узел без маршрута от пользователя или атакующего. |
| KEV и эксплуатация | Если уязвимость уже используется в реальных атаках, ее нельзя оставлять в общем списке ожидания. |
| EPSS | Помогает отличать уязвимости, которые вероятнее будут эксплуатироваться, от большого массива технических находок. |
| Компенсирующие меры | WAF, сегментация, EDR, отключенный компонент или ограниченный доступ могут изменить срочность, но не отменяют необходимости решения. |
| Стоимость исправления | Иногда быстрый конфигурационный фикс снижает риск сильнее, чем долгий проект по сложному патчу. |
Мировые практики и российский контур
В международной практике управление уязвимостями тесно связано с управлением обновлениями. NIST SP 800-40 Rev. 4 рассматривает управление обновлениями как предупредительное обслуживание: нужно выявлять, приоритизировать, получать, устанавливать и проверять обновления по всей организации. Это хороший ориентир для разговора с ИТ: патчи не являются чужой задачей ИБ, они часть надежной эксплуатации.
FIRST CVSS полезен как общий стандарт технической тяжести, но его нельзя использовать в одиночку. FIRST EPSS добавляет вероятность эксплуатации, а CISA KEV помогает выделять уязвимости, которые уже были замечены в атаках. CIS Controls дает практический язык для базовой кибергигиены: инвентаризация активов, контроль конфигураций, управление доступом, журналирование и устранение уязвимостей.
В российском контуре VM нужно связывать с требованиями ФСТЭК, КИИ, ГИС, ИСПДн, внутренними политиками и доказательной базой для проверок. Для известных уязвимостей полезен Банк данных угроз безопасности информации ФСТЭК России. В регулируемых проектах важно не только закрывать CVE, но и показывать управляемость процесса: кто отвечает, какие меры применены, какие риски приняты и как это подтверждается документами и журналами.
Как ИИ помогает VM-процессу
ИИ не должен сам принимать решение, какой риск допустим для бизнеса. Но он может заметно ускорить работу команды, если встроен в контролируемый контур с источниками, ролями и журналами.
Дедупликация находок
ИИ помогает объединять повторяющиеся результаты сканеров, разные названия одной проблемы и шум от нескольких источников.
Объяснение для владельца
Владелец системы получает не сухой CVE, а понятное описание: что уязвимо, чем это грозит, какие варианты исправления есть и почему срок важен.
Черновики задач
AI может подготовить описание задачи для ITSM, Jira или очередь задач: затронутые активы, версия, шаги исправления, проверка и критерий закрытия.
Связь с документами
Модуль сопоставляет уязвимости с политиками, моделью угроз, требованиями КИИ/ГИС/ИСПДн и пакет доказательств для комплаенса.
Отчетность
ИИ помогает собрать краткое резюме для директора по ИБ, ИТ-директора и комитета: тренды, просрочки, принятые риски, проблемные владельцы и быстрые меры.
Контроль ограничений
Специалист остается в контуре принятия решений: AI готовит варианты, а ответственный эксперт подтверждает риск, исключение, срок и финальный статус.
Где РЕСТАРТ дает ценность
РЕСТАРТ полезен там, где управление уязвимостями нужно не как отдельная консоль, а как рабочий процесс между ИБ, ИТ, разработкой, эксплуатацией, закупками и владельцами систем. Мы связываем аудит, внешний периметр, конечные устройства, DevSecOps, SIEM/SOAR/SGRC, ITSM, CMDB, вендорские решения и регуляторные требования.
Наш подход: сначала понять активы и процессы, затем выбрать инструменты и правила. Иначе легко получить дорогую платформу, которая генерирует тысячи находок, но не помогает бизнесу быстрее снижать риск.
Внешний периметр, конечные устройства и DevSecOps
Внешний периметр
Публичные домены, поддомены, IP, VPN, веб/API и тестовые стенды должны попадать в VM-процесс как отдельный источник риска. То, что видно из интернета, часто требует другой скорости реакции.
Аудит внешнего периметраКонечные устройства и серверы
Рабочие станции, серверы, VDI и привилегированные устройства дают реальную картину: версии ОС, установленное ПО, агенты защиты, локальные права и готовность к обновлению.
Endpoint SecurityDevSecOps и приложения
SAST, DAST, SCA, контейнеры и SBOM показывают уязвимости в коде и зависимостях до промышленного релиза. Это снижает поток проблем в продуктивный контур.
DevSecOps и AppSecSOC и GRC
SIEM, SOAR и SGRC связывают уязвимости с событиями, инцидентами, задачами, контролями, исключениями и доказательной базой.
SIEM, SOAR, SGRCАртефакты результата
| Артефакт | Для чего нужен |
|---|---|
| Карта активов и источников | Показывает, какие системы, хосты, приложения, облака, внешние сервисы и сканеры входят в процесс. |
| Модель приоритизации | Фиксирует правила: CVSS, EPSS, KEV, критичность актива, интернет-доступность, компенсирующие меры и регуляторный контур. |
| Матрица SLA | Задает сроки обработки и устранения для разных типов активов, уязвимостей, исключений и критичных систем. |
| RACI и владельцы | Определяет, кто отвечает за актив, исправление, принятие риска, проверку и управленческую отчетность. |
| Очередь задач на устранение | Переводит находки в понятные задачи для ИТ, DevSecOps, владельцев систем и подрядчиков. |
| Реестр исключений | Фиксирует случаи, когда исправление невозможно сразу: причина, компенсирующая мера, владелец, срок пересмотра и остаточный риск. |
| Интеграционная схема | Показывает связку VM-платформы со сканерами, SIEM/SOAR/SGRC, ITSM, CMDB, конечными устройствами, AppSec и отчетностью. |
| Отчет для руководства | Показывает динамику риска, просрочки, критичные системы, быстрые победы, проблемные зоны и план развития. |
Поставка и внедрение VM-инструментов
Средства управления уязвимостями, сканеры, EASM, контроль конфигураций, SCA и SGRC-платформы должны быть связаны с активами, приоритизацией, эксплуатацией, DevSecOps и отчетностью. РЕСТАРТ помогает подобрать и поставить такие решения как часть управляемого процесса, а не как отдельную покупку лицензий.
Частые вопросы
Чем управление уязвимостями отличается от пентеста?
Пентест проверяет практические сценарии атаки в согласованных границах. VM - постоянный процесс, который регулярно находит, приоритизирует и контролирует устранение уязвимостей. Эти подходы дополняют друг друга: пентест показывает путь атаки, VM удерживает процесс исправления и повторной проверки.
Почему нельзя исправлять только критические уязвимости?
Потому что технический балл без контекста может обмануть. Уязвимость среднего уровня на публичном сервисе с эксплуатацией в реальном мире может быть опаснее, чем критическая уязвимость на изолированном тестовом узле. Нужна модель приоритизации.
Что делать, если патч нельзя поставить?
Фиксируется исключение: причина, владелец, срок пересмотра, компенсирующие меры, остаточный риск и решение ответственного лица. Это лучше, чем молчаливое игнорирование находки.
Можно ли начать без внедрения новой платформы?
Да. Часто первый этап - это диагностика процесса: активы, источники данных, текущие сканеры, правила приоритизации, владельцы, SLA, отчетность и быстрые улучшения. После этого понятнее, нужен ли новый продукт.
Как связать VM с SOC и DevSecOps?
SOC получает контекст активов и уязвимостей для расследования инцидентов. DevSecOps закрывает уязвимые зависимости, контейнеры и код до релиза. VM объединяет эти потоки в общий реестр риска и задач.
ИИ может закрывать уязвимости автоматически?
В большинстве enterprise-контуров нет. ИИ может подготовить анализ, черновик задачи, объяснение и отчет, но исправление, принятие риска и изменение продуктивных систем должны проходить через ответственных специалистов и процесс изменений.
Обсудим ваш контур
Опишите задачу, текущие системы, ограничения и ожидаемый результат. Мы предложим первый практичный шаг: диагностику, пилот, аудит, дорожную карту или проектную команду.
