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

Практическое руководство для ИБ-команд, CISO и всех, кто хочет превратить сканирование в зрелый процесс

Почему управление уязвимостями перестало быть задачей «раз в квартал»

Представьте: сканер выдаёт 15 000 уязвимостей. Из них 60% помечены как «критические» или «высокие». Команда смотрит на список и понимает, что закрыть их все за разумное время физически невозможно. Приоритизации нет. Владельцев систем нет. SLA не установлены. Аудит на пороге.

Именно в такой ситуации оказывается большинство российских компаний, судя по материалам itsec.ru и Anti-Malware: процесс управления уязвимостями либо существует формально, либо сводится к периодическому сканированию без дальнейших действий [6].

При этом угроза реальна и нарастает. По данным центра мониторинга «Спикател», в 2025 году число кибератак на российский бизнес увеличилось на 42% и достигло 22 тысяч ИТ-инцидентов [2]. Каждая четвёртая атака имела серьёзные последствия — финансовые потери или длительный операционный сбой. По данным компании F6, суммарный объём утечек данных за 2025 год превысил 767 миллионов строк с персональными данными россиян [7].

Регулятор отреагировал жёстко. Приказ ФСТЭК России № 117 от 11 апреля 2025 года ввёл конкретные временны́е рамки для устранения уязвимостей в государственных информационных системах [3]. Федеральный закон № 420-ФЗ от ноября 2024 года ужесточил ответственность за утечки персональных данных: оборотные штрафы составляют 1–3% годовой выручки при повторных нарушениях, но не менее 20 миллионов и не более 500 миллионов рублей [8].

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

Часть I. Что такое управление уязвимостями и зачем нужен процесс

1.1 Определение и место в ИБ-архитектуре

Управление уязвимостями (Vulnerability Management, VM) — это непрерывный, повторяемый процесс обнаружения, приоритизации, устранения и верификации слабостей в программном и аппаратном обеспечении организации. Ключевое слово здесь — «непрерывный»: разовая проверка раз в год уже давно не соответствует темпу появления новых угроз.

NIST SP 800-40 Rev. 4 рассматривает управление патчами как обязательную часть операционного обслуживания инфраструктуры, сопоставимую с техническим обслуживанием оборудования [9]. Без него организации не снижают риск, а лишь накапливают «технический долг» в сфере безопасности.

ФСТЭК России в Руководстве по организации процесса управления уязвимостями (17 мая 2023 года) выделяет пять ключевых этапов процесса:

1. Выявление уязвимостей из источников: Банк данных угроз ФСТЭК (БДУ), базы CVE/NVD, данные производителей ПО.
2. Оценка уровня критичности по методике ФСТЭК.
3. Определение способов и сроков устранения.
4. Устранение уязвимостей или применение компенсирующих мер.
5. Контроль устранения и улучшение процесса [10].

Это пятиэтапная схема перекликается с международными подходами, в частности с ISO/IEC 27002 (Control 8.8 — Management of Technical Vulnerabilities) [11], что важно для организаций, сертифицирующихся по международным стандартам параллельно с выполнением требований ФСТЭК.

1.2 Чем управление уязвимостями отличается от сканирования

Частая ошибка: отождествлять VM со сканером. Сканер — лишь инструмент обнаружения. Управление уязвимостями — это:

• Актуальный инвентарь активов с привязкой к владельцам.
• Контекст критичности: где актив расположен, какие данные обрабатывает, доступен ли из интернета.
• Приоритизированная очередь задач с назначенными ответственными.
• SLA на устранение с механизмом эскалации.
• Верификация исправлений и ретестирование.
• Метрики и отчётность для разных аудиторий — от технических команд до совета директоров.

Именно отсутствие этих элементов превращает сканирование в «отчёт ради отчёта».

Часть II. Пятиэтапный жизненный цикл: как устроен зрелый процесс

Большинство фреймворков — от NIST до ФСТЭК — описывают схожий жизненный цикл. Ниже — его практическая интерпретация.

Этап 1. Инвентаризация и создание базы активов

Нельзя защитить то, о чём не знаешь. Отсутствие актуального инвентаря активов — самая распространённая причина провалов VM-программ [12]. Активы без владельцев, забытые серверы, теневое ИТ, устаревшие сервисы — всё это создаёт слепые зоны.

Правильно выстроенный реестр активов должен содержать:

1. Тип и наименование актива (сервер, рабочая станция, сетевое устройство, приложение, API, БД).
2. Владелец (конкретное подразделение или ФИО ответственного).
3. Уровень критичности бизнес-процессов, которые зависят от актива.
4. Тип данных: обрабатывает ли система персональные данные, коммерческую тайну, данные КИИ.
5. Сетевая доступность: интернет-периметр, внутренняя сеть, изолированный сегмент.
6. Текущий статус защищённости: дата последнего сканирования, количество открытых уязвимостей.

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

Этап 2. Обнаружение и сканирование уязвимостей

На этом этапе используются:

1. Автоматизированные сканеры (MaxPatrol VM, OpenVAS, Tenable Nessus — для сертифицированных решений применительно к ФСТЭК) с периодическим или агентным сканированием.
2. Базы данных уязвимостей: БДУ ФСТЭК, CVE/NVD, CISA KEV (Known Exploited Vulnerabilities — эталонный список активно эксплуатируемых уязвимостей, который в 2025 году вырос на 20% и достиг 1 484 записей [13]).
3. Уведомления от производителей ПО и служб реагирования на угрозы.
4. Результаты внутренних и внешних пентестов, анализа защищённости.

В российском контексте важная особенность: российские разработчики ПО редко публикуют сведения об обнаруженных уязвимостях, тогда как после получения сертификата ФСТЭК некоторые из них считают продукт «неуязвимым» [6]. Это требует более активного аудита и собственного тестирования, особенно в части отечественного ПО после импортозамещения.

Этап 3. Приоритизация

Именно здесь VM-программы чаще всего «ломаются»: команды либо пытаются закрыть всё подряд (что невозможно), либо расставляют приоритеты только по оценке CVSS, игнорируя реальный контекст.

Зрелый подход к приоритизации учитывает несколько факторов одновременно:

1. Уровень опасности уязвимости. Методика ФСТЭК (обновлена 30 июня 2025 года) и международная шкала CVSS (0–10). Критические и высокие уязвимости — обязательное устранение; для средних и низких — экспертная оценка возможности эксплуатации [14].
2. Эксплуатируемость в реальной среде. EPSS (Exploit Prediction Scoring System) — модель, оценивающая вероятность эксплуатации уязвимости в течение следующих 30 дней на основе глобальных данных [15]. Уязвимость со средним CVSS, но высоким EPSS опаснее «теоретической» критической уязвимости без публичного эксплойта.
3. Присутствие в CISA KEV или БДУ ФСТЭК. Факт активной эксплуатации — немедленный приоритет.
4. Критичность актива и бизнес-контекст. По данным опроса AM Live 2024, 58% российских специалистов ставят критичность актива на первое место при приоритизации, 19% — наличие эксплойта [16].
5. Сетевая экспозиция. Уязвимость на интернет-доступном VPN-концентраторе несравнимо опаснее той же уязвимости на изолированном тестовом стенде.

Важное предупреждение: по данным Verizon DBIR 2025, атаки на периметровые устройства через уязвимости выросли почти восьмикратно — с 3% до 22% от всех инцидентов [4]. Для новых критических уязвимостей в этих устройствах медианное время между публикацией и началом массовой эксплуатации составило 0 дней. Это делает скорость реагирования на периметре задачей первостепенной важности.

Этап 4. Устранение или компенсирующие меры

Устранение — не всегда немедленный патч. Возможные стратегии:

1. Установка обновления / патча (предпочтительный вариант).
2. Виртуальный патч — правило IPS/WAF, блокирующее эксплуатацию до выхода патча.
3. Компенсирующие меры: сегментация сети, ограничение доступа, отключение уязвимого сервиса.
4. Принятие риска — документированное решение не устранять, основанное на оценке вероятности и ущерба. Используется для низкоприоритетных уязвимостей при ресурсных ограничениях.

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

Этап 5. Верификация и контроль

Закрытый тикет не означает устранённую уязвимость. Обязательный шаг — ретестирование после применения патча и повторное сканирование актива. Это позволяет:

• Убедиться, что исправление сработало корректно.
• Зафиксировать факт устранения для аудиторского следа.
• Выявить «возвращающиеся» уязвимости, сигнализирующие о системных проблемах в конфигурации.

Часть III. Как установить SLA: от теории к цифрам

SLA (Service Level Agreement) на устранение уязвимостей — это задокументированные соглашения о том, в какой срок уязвимость определённого класса должна быть закрыта. Без SLA невозможно измерить и улучшить процесс [17].

3.1 Российские нормативные требования к срокам

Приказ ФСТЭК России № 117 (вступает в силу 1 марта 2026 года) устанавливает следующие обязательные сроки для государственных информационных систем [3]:

1. Критический уровень опасности — не более 24 часов.
2. Высокий уровень опасности — не более 7 календарных дней.

Для систем с более низкими классами защищённости (ИС 2 и 3 класса) контроль уровня защищённости должен проводиться не реже одного раза в 2 года, а отчёты о результатах направляться в ФСТЭК России в течение 5 рабочих дней [3].

3.2 Международные ориентиры для корпоративного сектора

В отсутствие жёсткого регуляторного требования большинство зрелых организаций ориентируются на следующие тайм-фреймы [18]:

1. Критические уязвимости (CVSS 9.0–10.0, особенно на периметре или с публичным эксплойтом) — от 24 часов до 7 дней.
2. Уязвимости высокого уровня (CVSS 7.0–8.9) — от 14 до 30 дней.
3. Уязвимости среднего уровня (CVSS 4.0–6.9) — от 60 до 90 дней.
4. Низкий уровень (CVSS 0.1–3.9) — 90–180 дней или по плановому циклу.

Отраслевой контекст имеет значение: финансовый сектор и медицина традиционно устанавливают более жёсткие SLA в силу требований PCI DSS, ФЗ-152 и других регуляторных стандартов [17].

3.3 Принцип дифференциации SLA по активам

Один из ключевых инсайтов: SLA должны различаться не только по уровню уязвимости, но и по критичности актива. Один и тот же CVSS 7.5 на интернет-доступном ERP требует иного срока, чем на изолированном тестовом стенде [19].

Пример многоуровневой матрицы:

1. Критический актив (интернет-периметр, финансовые системы, КИИ) + критическая уязвимость = 24–48 часов.
2. Критический актив + высокая уязвимость = 7 дней.
3. Стандартный актив + критическая уязвимость = 7–14 дней.
4. Стандартный актив + высокая уязвимость = 30 дней.
5. Любой актив + средняя уязвимость = 60–90 дней.
6. Любой актив + низкая уязвимость = 180 дней или по плановому циклу.

3.4 Как сделать SLA достижимыми, а не демотивирующими

Агрессивные SLA перегружают команды и ведут к выгоранию; слишком мягкие — оставляют организацию уязвимой. Практические рекомендации [20]:

1. Оцените текущий базовый MTTR (Mean Time to Remediate) перед установкой SLA — нельзя требовать 7 дней, если медиана сейчас 45.
2. Начните с реалистичных целей и ужесточайте постепенно.
3. Включите в SLA время на тестирование патча, чтобы избежать поспешных изменений, ломающих системы.
4. Согласуйте SLA с ИТ-командами, а не навязывайте их сверху — только тогда возникнет ответственность.
5. Предусмотрите процедуру исключений: для систем, которые невозможно патчить без длительного техномслуживания, должна быть задокументированная альтернатива (компенсирующие меры + план устранения).

Часть IV. Ключевые метрики: что и как измерять

Метрики — язык, на котором безопасность разговаривает с бизнесом. Без измеримых показателей невозможно ни улучшить процесс, ни обосновать инвестиции, ни пройти аудит [21].

4.1 Операционные метрики для ИБ-команды

1. MTTD (Mean Time to Detect) — среднее время от появления уязвимости до её обнаружения сканером. Снижение MTTD сокращает окно риска. По данным CISA, злоумышленники в среднем начинают эксплуатировать уязвимость в течение 15 дней с момента её публикации [22].
2. MTTR (Mean Time to Remediate) — среднее время от обнаружения до закрытия уязвимости. Ключевой показатель скорости и эффективности команды. Verizon DBIR 2025 фиксирует медианное MTTR для периметровых устройств — 32 дня, что катастрофически долго при нулевом «окне» до эксплуатации [4].
3. SLA compliance rate — доля уязвимостей, устранённых в рамках установленного SLA. Если этот показатель ниже 80% для критических уязвимостей — процесс требует пересмотра.
4. Reopen rate (процент повторного открытия) — доля уязвимостей, возобновившихся после закрытия. Высокий reopen rate сигнализирует о проблемах в процессе патчинга или управлении конфигурациями.
5. Vulnerability backlog age — средний возраст открытых уязвимостей в очереди. Рост этого показателя означает накопление «технического долга» в безопасности.
6. Remediation rate — доля критических и высоких уязвимостей, закрытых за определённый период. Отражает производительность команды устранения.

4.2 Метрики для совета директоров и топ-менеджмента

Технические метрики недостаточны для принятия стратегических решений. Руководству важнее [21]:

1. Количество критических открытых уязвимостей в текущий момент (тренд: снижение = прогресс).
2. Процент соответствия SLA по критическим активам — демонстрирует дисциплину процесса.
3. Cost of remediation vs. cost of breach — сравнение затрат на устранение с потенциальным ущербом от инцидента.
4. Compliance score — процент выполненных обязательных требований регуляторов.

Совет: переводите технические данные в бизнес-язык. «Закрыто 120 критических уязвимостей за квартал, MTTR снизился с 45 до 22 дней» — это понятно. «Проведено 340 сканирований» — нет.

4.3 Инструменты сбора и визуализации метрик

Эффективный мониторинг метрик требует интеграции между:

1. Платформой VM / сканером уязвимостей — источник данных о найденных уязвимостях.
2. ITSM-системой (Jira, ServiceNow, российские аналоги) — место жизни задач на устранение.
3. CMDB / реестром активов — контекст критичности.
4. Дашбордом для отчётности — единое «стекло» для всех участников процесса.

Автоматизация связи «уязвимость обнаружена → тикет создан с SLA-датой → владелец получил уведомление» — обязательное условие масштабируемого процесса [15].

Часть V. Доказательство контроля: как пройти аудит без паники

«Аудитор спрашивает — мы открываем дашборд и выгружаем отчёт» — такой сценарий возможен только при правильно выстроенном процессе с непрерывным сбором доказательств.

5.1 Что проверяет аудитор

При проверке соответствия требованиям ФСТЭК, PCI DSS, ISO 27001 аудитор обычно запрашивает:

1. Политику управления уязвимостями (документ с ролями, SLA, процедурами).
2. Реестр активов, подпадающих под область действия.
3. Свидетельства регулярного сканирования (логи, отчёты сканера с датами).
4. Статус устранения уязвимостей с датами обнаружения и закрытия.
5. Доказательства соблюдения SLA по критическим уязвимостям.
6. Записи о проведении ретестирования после патчинга.
7. Описание процедуры эскалации при нарушении SLA.

Согласно Приказу ФСТЭК № 117, отчёт о результатах контроля уровня защищённости должен быть представлен руководителю оператора ИС в течение 3 рабочих дней с даты завершения работ и направлен в ФСТЭК в течение 5 рабочих дней [3].

5.2 Аудиторский след как непрерывный процесс

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

1. Все задачи на устранение создаются в ITSM с атрибутами: ID уязвимости, CVE/BDU-номер, дата обнаружения, SLA-дата, ответственный.
2. Закрытие задачи фиксируется с артефактами: дата патча, версия, результат ретеста.
3. Дашборд показывает в реальном времени статус SLA compliance.
4. Ежемесячные отчёты генерируются автоматически и сохраняются в хранилище.

Такой подход сокращает трудозатраты на подготовку к аудиту с нескольких недель до нескольких часов [21].

5.3 Работа с исключениями

Не все уязвимости устраняются в срок по объективным причинам: зависимость от вендора, несовместимость патча, ограничения производственных систем. Для каждого исключения необходима документация:

1. Идентификатор уязвимости и актива.
2. Обоснование исключения.
3. Компенсирующие меры, применённые взамен патча.
4. Срок пересмотра (не позднее следующего квартала для критических).
5. Подпись ответственного руководителя.

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

Часть VI. Типичные ошибки и как их избежать

Ошибка 1. Отсутствие актуального инвентаря активов

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

Последствия: слепые зоны, уязвимости в «неизвестных» системах, нарушения при аудите [12].

Решение: автоматизированное обнаружение активов с интеграцией в CMDB; обязательная регистрация новых систем как часть процесса ввода в эксплуатацию.

Ошибка 2. Приоритизация только по CVSS без учёта контекста

Симптом: команды обрабатывают тысячи «критических» уязвимостей в случайном порядке, игнорируя реальную экспозицию.

Последствия: ресурсы тратятся на теоретически опасные, но фактически труднодоступные уязвимости; реально эксплуатируемые проблемы остаются открытыми [23].

Решение: многофакторная приоритизация с учётом EPSS, CISA KEV, критичности актива и наличия компенсирующих мер.

Ошибка 3. Нет назначенных владельцев задач на устранение

Симптом: отчёты о уязвимостях рассылаются «всем» или просто публикуются в общем чате без конкретного адресата.

Последствия: «ИБ-команда обвиняет ИТ, ИТ-команда обвиняет ИБ» — классический замкнутый круг [24].

Решение: каждый актив имеет зафиксированного владельца; задачи на устранение автоматически назначаются владельцу актива с чёткими SLA и процедурой эскалации.

Ошибка 4. Игнорирование ретестирования

Симптом: тикет закрыт, факт устранения считается доказанным без перепроверки.

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

Решение: верификация — обязательный этап процесса; повторное сканирование после патча фиксируется в системе.

Ошибка 5. SLA существуют в документе, но не контролируются

Симптом: политика с SLA написана, но нет мониторинга соблюдения, нет уведомлений при приближении дедлайна, нет эскалации при нарушении.

Последствия: SLA нарушаются систематически без реакции; процесс не улучшается [19].

Решение: автоматические уведомления ответственным за 72 часа до SLA и в момент нарушения; еженедельный дашборд SLA compliance для руководства; квартальный разбор нарушений с поиском системных причин.

Ошибка 6. Редкое сканирование — «раз в квартал перед аудитом»

Симптом: сканирование воспринимается как задача подготовки к проверке, а не как непрерывный процесс.

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

Решение: ФСТЭК прямо указывает на необходимость регулярного сканирования, а не разовых проверок [25]. Интернет-периметр — ежедневно или еженедельно; внутренние системы — еженедельно или ежемесячно в зависимости от критичности.

Часть VII. CTEM — следующий уровень: от VM к управлению угрозами непрерывно

Gartner в 2023 году ввёл концепцию Continuous Threat Exposure Management (CTEM) — программу, расширяющую традиционный VM до комплексного управления поверхностью атак [5].

CTEM включает пять этапов: Scoping (определение области) → Discovery (обнаружение) → Prioritization (приоритизация) → Validation (валидация эффективности контролей) → Mobilization (координация устранения).

Ключевое отличие от классического VM: на этапе Validation организация активно проверяет, действительно ли существующие средства защиты блокируют выявленные угрозы, а не просто список уязвимостей для закрытия. Это сближает управление уязвимостями с непрерывным тестированием защиты.

По прогнозу Gartner, к 2026 году организации, приоритизирующие инвестиции в безопасность на основе программы CTEM, будут подвергаться взломам в 3 раза реже, чем компании без такого подхода [5]. Другой прогноз Gartner: к 2028 году более половины угроз будут исходить не из технических уязвимостей, а из нетехнических факторов — что требует ещё более широкого взгляда на управление рисками [26].

Для большинства российских компаний CTEM — среднесрочная цель после выстраивания базового VM-процесса. Начинать следует с фундамента: инвентарь, сканирование, SLA, метрики.

Часть VIII. Практический чек-лист: с чего начать

Если процесса управления уязвимостями нет или он существует формально, начните с этих шагов:

1. Создайте реестр активов. Зафиксируйте все системы, приложения, сетевые устройства с владельцами и уровнями критичности. Приоритет — системы интернет-периметра и обрабатывающие персональные данные/коммерческую тайну.
2. Запустите базовое сканирование. Выберите сканер (для требований ФСТЭК — из реестра отечественного ПО), запустите первичное сканирование всех ключевых активов. Сформируйте «точку отсчёта» — baseline.
3. Разработайте политику VM. Документ с объёмом, ролями, SLA, процедурой эскалации, форматом отчётности. Согласуйте с ИТ-командами и руководством.
4. Установите SLA. Начните с матрицы 4×2 (4 уровня критичности уязвимости × 2 уровня критичности актива). Убедитесь, что SLA достижимы при текущих ресурсах.
5. Автоматизируйте создание задач. Настройте интеграцию сканера с ITSM: уязвимость найдена → тикет создан с ответственным и SLA-датой.
6. Настройте мониторинг SLA compliance. Дашборд с текущим статусом по критическим и высоким уязвимостям — ежедневный инструмент ИБ-команды.
7. Проводите ежемесячный разбор нарушений. Какие SLA нарушены? Почему? Что изменить в процессе?
8. Обеспечьте ретестирование. Добавьте проверку фактического устранения как обязательный шаг перед закрытием тикета.
9. Формируйте регулярные отчёты. Для технической команды — еженедельно, для руководства — ежемесячно или ежеквартально.
10. Улучшайте итеративно. VM — не проект с конечной датой, а непрерывный процесс. Каждый квартал пересматривайте SLA, метрики и инструменты.

Часть IX. Кейсы и практические примеры

Кейс 1. Оператор связи под проверкой ФСТЭК

По данным блога Инфратех, при проверке одного из операторов связи ФСТЭК выявил отсутствие регулярного сканирования уязвимостей. Компания использовала устаревшие версии серверного ПО с критическими уязвимостями (CVSS 9.8). Итог — штраф 200 000 рублей и предписание на устранение нарушений в течение 30 дней [25].

Урок: отсутствие регулярного сканирования — не «экономия времени», а прямой риск регуляторного взыскания.

Кейс 2. Энергетическая компания: уязвимости есть, исправлений нет

В той же публикации описан случай: энергетическая компания выявила 100+ уязвимостей, но ни одна не была устранена в срок. ФСТЭК при аудите предписал закрыть критические за 14 дней и инициировал повторную проверку [25].

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

Кейс 3. Глобальный прецедент — Equifax (2017)

Одна из крупнейших в истории утечек данных (147 миллионов записей) была вызвана незакрытой уязвимостью в Apache Struts, патч для которой был доступен за несколько месяцев до инцидента [27]. Задержка в применении патча обошлась компании более чем в 1,4 млрд долларов прямых затрат плюс ущерб репутации.

Урок: «мы знали, но не успели» — не оправдание ни для регулятора, ни для суда.

Часть X. Тренды и будущее управления уязвимостями

Сжатие окна эксплуатации

По данным Google Threat Intelligence Group 2024, злоумышленники теперь эксплуатируют публично раскрытые уязвимости в среднем через 5 дней — против 32 дней двумя годами ранее [28]. Для периметровых устройств, по данным Verizon DBIR 2025, это окно фактически равно нулю [4]. Это делает скорость обнаружения и реагирования критически важной.

Рост числа CVE

База CVE к концу 2025 года превысила 308 000 записей; только за год добавлено рекордные 48 185 новых CVE — на 20% больше, чем в 2024 году [8]. Ни одна команда не способна закрывать их все — именно поэтому приоритизация становится важнее скорости.

ИИ как инструмент атак и защиты

По данным Cybersecurity Ventures, мировой ущерб от киберпреступности в 2025 году достиг 10,5 триллиона долларов [8]. Генеративный ИИ снижает порог входа для злоумышленников: для создания эксплойта больше не нужны глубокие технические знания. С другой стороны, AI используется для автоматической приоритизации уязвимостей, предиктивного анализа рисков и генерации компенсирующих мер.

Импортозамещение и специфика российского рынка

Массовое импортозамещение создаёт специфическую российскую проблему: отечественные разработчики редко публикуют данные об уязвимостях и не всегда оперативно выпускают патчи [6]. Это требует:

1. Активного мониторинга БДУ ФСТЭК (в дополнение к CVE/NVD).
2. Собственного тестирования отечественного ПО.
3. Плотного взаимодействия с производителями по каналам ГосСОПКА и НКЦКИ.
4. Компенсирующих мер как основного инструмента там, где патч недоступен.

Заключение: контроль — это процесс, а не состояние

Управление уязвимостями в 2025–2026 годах — это не разовый проект и не ежеквартальный отчёт. Это непрерывный операционный процесс с чёткими ролями, измеримыми SLA, автоматическим аудиторским следом и регулярным улучшением.

Ключевые выводы:

1. Начните с инвентаря — нельзя защищать то, о чём не знаешь.
2. Приоритизируйте умно — CVSS плюс контекст, а не CVSS в вакууме.
3. Назначайте SLA реалистично — но фиксируйте и контролируйте неукоснительно.
4. Автоматизируйте связку «сканер → ITSM → отчётность» — ручные процессы не масштабируются.
5. Доказывайте контроль непрерывно — аудитор не должен застать вас врасплох.
6. Смотрите в будущее — CTEM и валидация контролей — следующий уровень после базового VM.

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

Пятый фактор: непрерывный контроль ПДн как часть зрелого VM-процесса

Одна из часто упускаемых составляющих управления уязвимостями — контроль того, где именно находятся персональные данные в корпоративной инфраструктуре. Новые поля в базах данных, новые интеграции, новые подрядчики — всё это создаёт «слепые зоны» в инвентаре ПДн, которые невидимы стандартным сканерам уязвимостей.

Именно эту задачу решает Пятый фактор — on-prem платформа для автоматического обнаружения, инвентаризации и контроля персональных данных в корпоративных системах (БД, хранилища, почта, AD/LDAP, CRM, 1С, API).

Принципиальная особенность: система работает только с метаданными, структурой и агрегатами — без передачи и хранения «сырых» ПДн. Это означает, что платформа сама не становится источником риска. В результате компании получают «живую карту ПДн» — где и какие данные есть, кто владелец, что изменилось — и видят новые риски ещё до того, как они превратились в инцидент.

В контексте управления уязвимостями это критически важно: если вы не знаете, где хранятся ПДн, вы не можете правильно оценить критичность актива и назначить адекватный SLA. Именно потому что ИТ-ландшафт постоянно меняется — появляются новые поля в БД, новые сервисы, новые интеграции, — без автоматизированного контроля «карта рисков» устаревает быстрее, чем её успевают обновить вручную.

Источники

[1] Verizon. 2025 Data Breach Investigations Report. — https://www.verizon.com/business/resources/reports/dbir/

[2] CNews. Почти половина кибератак на российский бизнес в 2025 году была успешной. Январь 2026. — https://www.cnews.ru/news/top/2026-01-23_pochti_polovina_kiberatak

[3] Центр по безопасности USSC. Анализ ключевых изменений в требованиях к защите информации согласно Приказу ФСТЭК № 117. Август 2025. — https://sec.ussc.ru/fstec_117

[4] Infosecurity Magazine. Verizon's DBIR Reveals 34% Jump in Vulnerability Exploitation. Апрель 2025. — https://www.infosecurity-magazine.com/news/verizon-dbir-jump-vulnerability/

[5] SimSpace. Gartner's CTEM Trend Explained for Real Security Teams. Ноябрь 2025. — https://simspace.com/blog/gartners-ctem-trend-explained-for-real-security-teams/

[6] IT Security. Управление уязвимостями в 2024 году: что изменилось и как перестроить процесс. — https://www.itsec.ru/articles/upravlenie-uyazvimostyami-v-2024-godu-chto-izmenilos-i-kak-perestroit-process

[7] SecurityLab. 767 млн украденных записей, 250 взломов и 27 новых APT-групп. Февраль 2026. — https://www.securitylab.ru/news/568827.php

[8] Passwork Blog. Кибератаки 2025: статистика, векторы атак и главные уязвимости. Март 2026. — https://passwork.ru/blog/kiberataki-2026/

[9] NIST. SP 800-40 Rev. 4: Guide to Enterprise Patch Management Planning. Апрель 2022. — https://csrc.nist.gov/pubs/sp/800/40/r4/final

[10] AKTIV.CONSULTING. Руководство ФСТЭК по организации процесса управления уязвимостями. — https://aktiv.consulting/ekspertiza/1194/

[11] IT Security. Управление уязвимостями: ожидание — реальность и рекомендации. — https://www.itsec.ru/articles/upravlenie-uyazvimostyami-ozhidanie-realnost-i-rekomendacii

[12] Strobes. Top 5 Vulnerability Management Mistakes Companies Make. Сентябрь 2024. — https://strobes.co/blog/top-5-vulnerability-management-mistakes-companies-make-plus-a-bonus-mistake-to-avoid/

[13] SecurityWeek. CISA KEV Catalog Expanded 20% in 2025. Январь 2026. — https://www.securityweek.com/cisa-kev-catalog-expanded-20-in-2025-topping-1480-entries/

[14] iTPROTECT. Утверждена новая методика ФСТЭК России для анализа защищённости. Декабрь 2025. — https://itprotect.ru/mediacenter/news/novaya-metodika-fstek/

[15] Hostedscan. Vulnerability Management SLAs: A Guide. — https://hostedscan.com/blog/vulnerability-management-slas-guide

[16] Anti-Malware. Как организовать процесс управления уязвимостями в 2024 году. — https://www.anti-malware.ru/analytics/Technology_Analysis/Vulnerability-Management-2024-AMLive

[17] Anchor Cybersecurity. Setting Realistic SLAs for Vulnerability Remediation. Ноябрь 2024. — https://anchorcybersecurity.com/blog/2024-11-15-realistic-slas/

[18] Anchor Cybersecurity. Vulnerability SLAs Explained: Critical Timelines for Effective Risk Management. Октябрь 2024. — https://anchorcybersecurity.com/blog/2024-10-18-Vulnerability-SLAs/

[19] Nucleus Security. How to Adapt Vulnerability Management SLAs to Team Maturity. Май 2025. — https://nucleussec.com/blog/how-to-adapt-vulnerability-management-service-level-agreements-to-team-maturity/

[20] Device42. Best Practices for Vulnerability Management Metrics. Сентябрь 2025. — https://www.device42.com/vulnerability-management-best-practices/vulnerability-management-metrics/

[21] Strobes. ROI of Vulnerability Management Metrics. Апрель 2025. — https://strobes.co/blog/roi-of-vulnerability-management-metrics/

[22] Tenable. SLAs and Remediation. — https://docs.tenable.com/cyber-exposure-studies/cyber-exposure-insurance/Content/SLARemediation.htm

[23] Picus Security. Why Vulnerability Management Is Failing and What Comes Next. Июнь 2025. — https://www.picussecurity.com/resource/glossary/why-vulnerability-management-is-failing-and-what-comes-next

[24] Infosecurity Magazine. How to Avoid Common Mistakes in Vulnerability Management. — https://www.infosecurity-magazine.com/opinions/howto-mistakes-vulnerability/

[25] Инфратех. Управление уязвимостями ФСТЭК: процесс, требования и примеры. Май 2025. — https://blog.infra-tech.ru/upravlenie-uyazvimostyami-fstek/

[26] Cymulate. Gartner Strategic Roadmap for Continuous Threat Exposure Management. Сентябрь 2025. — https://cymulate.com/report/gartner-strategic-roadmap-ctem/

[27] Motadata. 7 Patch Management Mistakes That Weaken Security. Ноябрь 2025. — https://www.motadata.com/blog/patch-management-mistakes/

[28] Automox. Vulnerability and Patch Management Process: Best Practices Guide. — https://www.automox.com/blog/vulnerability-patch-management-process