Методика управления уязвимостями ФСТЭК: этапы, сроки, автоматизация

ФСТЭК России разработала руководство по организации процесса управления уязвимостями, которое стало обязательным ориентиром для операторов ГИС, ИСПДн, объектов КИИ и АСУ ТП. Документ превращает разрозненные практики сканирования и патчинга в системный процесс с чёткими этапами, ролями и сроками. Однако на практике большинство организаций внедряют лишь первый этап — сканирование, — оставляя без внимания оценку, приоритизацию, контроль устранения и метрики.

В этой статье разберём методику управления уязвимостями ФСТЭК целиком: от назначения документа и пяти этапов процесса до конкретных сроков устранения, источников данных, метрик эффективности и подхода к автоматизации через SGRC. Материал рассчитан на CISO, руководителей ИБ-подразделений и аналитиков, которые выстраивают или совершенствуют VM-процесс в соответствии с требованиями регулятора.

О документе: Руководство ФСТЭК по управлению уязвимостями

Что это за документ

Руководство по организации процесса управления уязвимостями — нормативно-методический документ ФСТЭК России, который определяет единый порядок выявления, оценки и устранения уязвимостей в информационных системах и ИТ-инфраструктуре. Документ не подменяет приказы ФСТЭК (№117, №21, №31, №239), а дополняет их, раскрывая процессную сторону: как именно должен быть организован цикл работы с уязвимостями.

До выхода руководства требования к управлению уязвимостями были рассредоточены по отдельным приказам и методическим рекомендациям. Операторы информационных систем получали набор обязанностей (сканировать, устранять, документировать), но не единую методику процесса. Руководство закрыло этот пробел, предложив пятиэтапную модель, описание ролей и ориентиры по срокам реагирования.

На кого распространяется

Руководство обязательно для организаций, эксплуатирующих:

• Государственные информационные системы (ГИС) — приказ ФСТЭК №117.
• Информационные системы персональных данных (ИСПДн) — приказ ФСТЭК №21.
• Значимые объекты критической информационной инфраструктуры (КИИ) — 187-ФЗ, приказ ФСТЭК №239.
• Автоматизированные системы управления технологическими процессами (АСУ ТП) — приказ ФСТЭК №31.

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

⚠️ Важно: Для ГИС, ИСПДн и значимых объектов КИИ Руководство ФСТЭК по управлению уязвимостями — не методическая рекомендация, а обязательный нормативный документ. Отсутствие формализованного VM-процесса фиксируется как несоответствие при аттестации и плановых проверках регулятора.

Место в системе нормативных актов

Руководство дополняет экосистему документов ФСТЭК:

• Методика оценки угроз (2021) — определяет порядок разработки модели угроз с использованием БДУ ФСТЭК.
• Приказы №117/21/31/239 — устанавливают требования к защите информации, включая меры по анализу уязвимостей.
• БДУ ФСТЭК (bdu.fstec.ru) — государственная база данных угроз и уязвимостей, основной источник данных для VM-процесса. Подробнее о структуре базы — в статье БДУ ФСТЭК России: руководство по базе угроз.
• Руководство по VM — описывает, как выстроить непрерывный процесс работы с данными из БДУ и сканеров.

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

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

Руководство ФСТЭК определяет циклический процесс из пяти этапов. Каждый этап имеет определённый вход, выход и ответственного. Ниже — подробный разбор каждого этапа с акцентом на практику внедрения.

Этап 1. Мониторинг уязвимостей и оценка применимости

Первый этап отвечает на вопрос: какие уязвимости существуют и затрагивают ли они нашу инфраструктуру.

Активное сканирование. Сканеры уязвимостей (MaxPatrol VM, RedCheck, Nessus, Qualys) проверяют хосты по базам известных уязвимостей. Сканирование бывает агентным (агент установлен на хосте) и безагентным (сетевое обращение). Агентное сканирование точнее для серверов и рабочих станций, безагентное — удобнее для сетевого оборудования и legacy-систем.

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

Оценка применимости. Не каждая опубликованная уязвимость затрагивает конкретную инфраструктуру. Аналитик или автоматизированная система проверяет: установлено ли уязвимое ПО, какой версии, в какой конфигурации. Уязвимость в Apache Struts не применима к организации, использующей только nginx.

Результат этапа — перечень подтверждённых уязвимостей с привязкой к конкретным активам. Каждая запись содержит идентификатор (CVE/BDU), затронутый компонент, версию и дату обнаружения.

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

На втором этапе каждой подтверждённой уязвимости присваивается числовая оценка критичности по стандарту CVSS v3.1 (Common Vulnerability Scoring System).

Аналитик ИБ выполняет три действия:

1. Фиксирует базовую оценку CVSS из БДУ ФСТЭК или NVD. Базовая оценка отражает технические характеристики уязвимости: вектор атаки, сложность, требуемые привилегии, влияние на конфиденциальность, целостность и доступность.

2. Уточняет временные метрики. Доступен ли публичный эксплойт (Exploit Code Maturity)? Выпущен ли официальный патч (Remediation Level)? Подтверждена ли уязвимость несколькими источниками (Report Confidence)? Эти параметры могут повысить или понизить итоговую оценку.

3. Применяет контекстные метрики. Доступен ли актив из интернета? Обрабатывает ли он персональные данные? Защищён ли WAF или сетевой сегментацией? Контекст организации корректирует «голую» цифру CVSS.

Важно: оценка критичности — это не механическое копирование CVSS Base Score. Уязвимость с базовой оценкой 7.5 на изолированном тестовом сервере объективно менее критична, чем уязвимость с оценкой 5.5 на публичном веб-сервере с ПДн, доступном из интернета.

Этап 3. Определение методов и приоритетов устранения

Третий этап переводит техническую оценку в план действий. Факторы приоритизации:

• Оценка CVSS с учётом контекста — итоговый балл после применения временных и контекстных метрик.
• Класс актива — продуктивный сервер КИИ, рабочая станция, тестовая среда.
• Наличие эксплойта — PoC в открытом доступе, рабочий эксплойт в Metasploit, включение в каталог CISA KEV (активная эксплуатация).
• Бизнес-зависимости — затронутый компонент используется другими системами, каскадный эффект при простое.
• Компенсирующие меры — наличие WAF, IPS-правил, микросегментации снижает срочность, но не отменяет необходимость устранения.

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

На выходе — ранжированный backlog уязвимостей с назначенным SLA на устранение и указанием ответственного подразделения.

Этап 4. Устранение уязвимостей

Четвёртый этап — техническая реализация. Подразделение ИТ выполняет работы по устранению в соответствии с приоритетами и SLA, установленными на предыдущем этапе.

Патчинг. Основной способ. Перед установкой обновления на продуктивные системы — обязательное тестирование на staging-среде. Для объектов КИИ и АСУ ТП тестирование критически важно: некорректный патч может нарушить технологический процесс.

Компенсирующие меры. Применяются, когда патч недоступен (вендор ещё не выпустил), патч нельзя установить без остановки критичного сервиса, или обновление конфликтует с другим ПО. Варианты: правила WAF/IPS для блокировки вектора атаки, отключение уязвимого компонента или протокола, сетевая изоляция (VLAN, ACL, микросегментация), ограничение привилегий учётных записей.

Документирование. Каждое действие фиксируется: кто, когда, что сделал, какой метод устранения применил. Это необходимо для прохождения аудита ИБ и проверок регулятора. Без аудитопригодного журнала действий процесс VM формально не выполняется даже при технически корректном патчинге.

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

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

1. Повторное сканирование целевого актива тем же инструментом, который обнаружил уязвимость.
2. Ручная верификация — для критических уязвимостей (CVSS 9.0+) аналитик проверяет: версия компонента обновлена, эксплойт не воспроизводится, компенсирующая мера активна.
3. Закрытие тикета — фиксация способа устранения, даты верификации, ответственного в системе управления задачами.

Если повторное сканирование выявляет уязвимость повторно, тикет возвращается на этап устранения. Цикл повторяется до полного закрытия.

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

После верификации цикл замыкается — начинается следующая итерация мониторинга.

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

Руководство ФСТЭК определяет чёткое разделение ролей. Без формализации ответственности процесс буксует: ИБ выявляет уязвимости, ИТ не устраняет, потому что «не было задачи», владелец системы не знает о проблеме.

Подразделение информационной безопасности

Организует весь VM-процесс. Конкретные функции:

• Настройка и запуск регулярного сканирования.
• Оценка и приоритизация уязвимостей (этапы 2–3).
• Назначение SLA и контроль его соблюдения.
• Верификация устранения (этап 5).
• Формирование отчётности для руководства и регулятора.
• Эскалация при нарушении SLA.

Подразделение информационных технологий

Отвечает за техническую реализацию устранения (этап 4):

• Установка патчей и обновлений на серверы, рабочие станции, сетевое оборудование.
• Настройка компенсирующих мер (WAF, IPS, ACL).
• Тестирование патчей на staging-среде перед развёртыванием в продуктив.
• Информирование ИБ о завершении работ для запуска верификации.

Владельцы информационных систем

Принимают решения на стыке техники и бизнеса:

• Утверждение SLA для своих систем совместно с CISO.
• Согласование окон обслуживания для установки обновлений.
• Принятие остаточного риска (при невозможности устранения — с документированным обоснованием).
• Выделение ресурсов (бюджет, люди, время) на устранение уязвимостей.

Руководство организации

Обеспечивает процесс на стратегическом уровне:

• Утверждение политики и регламента управления уязвимостями.
• Выделение бюджета на средства сканирования, SGRC-платформу, обучение.
• Контроль ключевых метрик (MTTR, SLA Compliance) на уровне дашборда CISO.

Разделение ролей формализуется через RACI-матрицу: кто выполняет (Responsible), кто утверждает (Accountable), кого консультируют (Consulted), кого информируют (Informed). Без RACI процесс зависает на согласованиях, а при инцидентах невозможно определить зону ответственности.

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

Приказы ФСТЭК устанавливают обязательные сроки устранения уязвимостей. Они зависят от двух параметров: критичности уязвимости по CVSS v3.1 и применимого нормативного документа.

Обязательные сроки устранения по приказам ФСТЭК

💡 Подсказка: Начните с бесплатного ScanOVAL — официального сканера ФСТЭК. HTML-отчёт импортируется в КиберОснова, где дедлайны рассчитываются автоматически по нужному приказу — ИТ сразу видит SLA без ручного расчёта.

Поправочные коэффициенты

Базовые сроки корректируются в зависимости от контекста:

• Публичный эксплойт. При наличии рабочего эксплойта (Exploit Code Maturity = Functional или High) SLA сокращается на один уровень вверх. Пример: высокая уязвимость (CVSS 7.8) с публичным эксплойтом обрабатывается как критическая — 24 часа вместо 168 (для КИИ по №239) или вместо 72 часов (для ГИС по №117).
• Активная эксплуатация. Если уязвимость включена в каталог CISA KEV или зафиксирована НКЦКИ как активно эксплуатируемая — устранение в режиме P0, вне очереди.
• Доступность из интернета. Периметровые активы (DMZ, публичные веб-серверы) — сроки сокращаются в 1.5--2 раза по сравнению с внутренними системами.
• Обработка ПДн. Системы, обрабатывающие специальные категории персональных данных, получают повышенный приоритет.

Компенсирующие меры и отсрочка

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

Порядок действий при невозможности патчинга:

1. Применить компенсирующую меру (WAF-правило, IPS-сигнатура, ACL, отключение протокола) в рамках базового SLA.
2. Задокументировать причину невозможности патчинга и описание компенсирующей меры.
3. Установить контрольную дату повторной проверки (не более 30 дней).
4. После выхода патча — установить в рамках стандартного SLA для данного уровня критичности.

Отсчёт SLA начинается с момента подтверждения применимости уязвимости (после этапов 1--2), а не с момента публикации в БДУ. SLA включает время на устранение и верификацию.

Источники информации об уязвимостях

Руководство ФСТЭК предписывает использовать множественные источники данных. Опора на единственный источник создаёт слепые зоны: ни одна база не содержит 100% всех уязвимостей.

БДУ ФСТЭК (bdu.fstec.ru)

Основной источник для российских организаций. Содержит более 85 000 уязвимостей с оценками CVSS, перекрёстными ссылками на CVE и рекомендациями по устранению. БДУ ФСТЭК включает уязвимости российского ПО (Astra Linux, РЕДОС, КриптоПро, Kaspersky), которые могут отсутствовать в международных базах. Модуль БДУ в SGRC-платформе автоматизирует загрузку обновлений и сопоставление с реестром активов. Бесплатный реестр БДУ ФСТЭК онлайн с поиском, CVSS v4.0 и SLA по приказу №117 доступен без регистрации.

NVD и CVE/MITRE

National Vulnerability Database (NVD) — международная база, ведомая NIST. Каждая уязвимость имеет идентификатор CVE (Common Vulnerabilities and Exposures), описание, оценку CVSS и ссылки на патчи. NVD обеспечивает покрытие международного ПО и часто публикует данные раньше БДУ для иностранных продуктов.

CERT и бюллетени вендоров

• НКЦКИ / ГосСОПКА — национальный координационный центр по компьютерным инцидентам. Публикует предупреждения об активно эксплуатируемых уязвимостях в российском сегменте.
• CISA KEV (Known Exploited Vulnerabilities) — каталог уязвимостей с подтверждённой эксплуатацией. Включение в KEV — сигнал к немедленному устранению.
• Бюллетени вендоров — Microsoft Patch Tuesday (MSRC), Red Hat Errata, Debian Security Advisories, Cisco Security Advisories. Основной источник информации о патчах.

Сканеры уязвимостей

Сканеры — технический инструмент активного обнаружения:

• ScanOVAL (АЛТЭКС-СОФТ / ФСТЭК) — бесплатный локальный сканер. Скачивает OVAL-контент с bdu.fstec.ru, проверяет один хост, формирует HTML-отчёт. Не имеет сертификата ФСТЭК как СЗИ, не масштабируется на инфраструктуру. Полезен как точка входа или для промежуточных проверок. HTML-отчёт ScanOVAL можно загрузить в личный кабинет КиберОснова — платформа обогатит каждую уязвимость из БДУ и рассчитает SLA-дедлайны.
• MaxPatrol VM (Positive Technologies) — российский сертифицированный сканер с поддержкой БДУ ФСТЭК. Включает asset management.
• RedCheck (АЛТЭКС-СОФТ) — сертифицированный ФСТЭК, интеграция с БДУ, поддержка Astra Linux и РЕДОС.
• Nessus (Tenable) — широкая база плагинов, агентное и безагентное сканирование.
• Qualys VMDR — облачный сканер с модулем приоритизации на основе threat intelligence.

Подробное сравнение сертифицированных сканеров: MaxPatrol VM, RedCheck, XSpider, ScanFactory →

Оптимальный подход — комбинация сертифицированного сканера (для покрытия требований регулятора) и БДУ ФСТЭК через SGRC-платформу (для пассивного мониторинга и корреляции). Данные из обоих источников агрегируются в единое пространство для оценки и приоритизации.

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

Без метрик VM-процесс превращается в формальность: уязвимости обнаруживаются, но неизвестно, насколько быстро устраняются, какая доля инфраструктуры охвачена и соблюдаются ли SLA. Руководство ФСТЭК подразумевает мониторинг эффективности процесса — метрики являются его инструментом.

Ключевые показатели VM-процесса

Интерпретация и пороговые значения

MTTR — главная метрика зрелости VM-процесса. Отслеживайте MTTR отдельно по уровням критичности: общий MTTR маскирует проблемы. Организация с MTTR Critical = 48 часов и MTTR Low = 25 дней — в целом зрелая. Организация с MTTR Critical = 20 дней — имеет системную проблему.

Покрытие сканирования ниже 80% означает, что пятая часть инфраструктуры — слепая зона. Shadow IT, неучтённые виртуальные машины, забытые dev-серверы — именно из этих «невидимых» активов чаще всего начинаются инциденты. Без полной инвентаризации активов покрытие не поднять.

SLA Compliance ниже 70% — красный флаг. Возможные причины: нереалистичные SLA, нехватка ресурсов ИТ, неработающий процесс согласования окон обслуживания, отсутствие эскалации. Необходим анализ корневых причин, а не давление на ИТ.

Backlog Aging в динамике показывает, справляется ли организация с потоком уязвимостей. Растущий backlog при стабильном потоке обнаружений означает, что темп устранения ниже темпа обнаружения — нужны дополнительные ресурсы или пересмотр приоритизации.

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

📋 MTTR как главная метрика зрелости: Целевое значение по методике ФСТЭК — MTTR Critical < 24 ч, High < 168 ч. Отслеживайте MTTR раздельно по уровням критичности: общий показатель маскирует реальные проблемы. Организация с MTTR Critical = 48 ч — имеет системную проблему, даже если общий MTTR выглядит приемлемо.

Автоматизация процесса: SGRC + VM (КиберОснова)

Почему ручной процесс не масштабируется

В организации с 500+ активами один цикл сканирования генерирует тысячи записей об уязвимостях. Без автоматизации типичная картина:

• Результаты сканирования экспортируются в Excel и вручную распределяются между администраторами.
• Привязка уязвимостей к конкретным активам и их владельцам выполняется по памяти.
• SLA отслеживается в календаре (или не отслеживается).
• Верификация пропускается из-за нехватки времени.
• Отчёт для руководства и регулятора собирается неделями.

Руководство ФСТЭК подразумевает непрерывность процесса. Непрерывность и ручной труд — взаимоисключающие понятия при любом нетривиальном масштабе инфраструктуры.

Автоматизируйте управление уязвимостями: КиберОснова рассчитывает SLA по приказу ФСТЭК, назначает ответственных и формирует отчёты — без Excel. Запросить демо →

SGRC как оркестратор VM по методике ФСТЭК

SGRC (Security Governance, Risk and Compliance) — класс платформ, объединяющих управление рисками, комплаенсом и операционными процессами ИБ. В контексте методики ФСТЭК SGRC-платформа покрывает все пять этапов:

• Этап 1 (мониторинг). Автоматическая загрузка данных из БДУ ФСТЭК и результатов сканеров. Дедупликация, нормализация, сопоставление с реестром активов.
• Этап 2 (оценка). Расчёт контекстной оценки CVSS с учётом класса актива, расположения в сети, обрабатываемых данных.
• Этап 3 (приоритизация). Автоматическое ранжирование на основе многофакторной модели: CVSS + класс актива + наличие эксплойта + компенсирующие меры. Назначение SLA.
• Этап 4 (устранение). Создание задач с привязкой к ответственным, контроль дедлайнов, автоматические уведомления и эскалации.
• Этап 5 (контроль). Запуск повторного сканирования, сверка результатов, автоматическое закрытие тикетов при подтверждении устранения.

КиберОснова: реализация методики на практике

Платформа КиберОснова реализует VM в рамках SGRC-подхода:

• Модуль БДУ ФСТЭК — автоматическая загрузка и актуализация базы уязвимостей и угроз. Обновления поступают по мере публикации ФСТЭК. Каждая уязвимость автоматически сопоставляется с активами в реестре.
• Инвентаризация активов — единый реестр ИТ-активов с классификацией по критичности, привязкой к владельцам и информационным системам. Без актуального реестра невозможно ни оценить применимость уязвимости, ни рассчитать приоритет.
• Контроль SLA — автоматическое отслеживание сроков устранения. Уведомления ответственным при приближении к дедлайну. Автоэскалация при нарушении SLA.
• Аудит ИБ — полный журнал действий: кто обнаружил, кто оценил, кто устранил, когда верифицировал. Аудитопригодный trail для проверок регулятора.
• Дашборды и метрики — MTTR, SLA Compliance, покрытие, backlog — в реальном времени на экране CISO.
• Связь с управлением рисками — уязвимости привязываются к угрозам из БДУ и реестру рисков. VM перестаёт существовать в вакууме и становится частью общей системы управления ИБ.

Результат: вместо разрозненных инструментов и Excel-таблиц — единая платформа, в которой весь VM-процесс прозрачен, измерим и аудитопригоден. Запросить демо и увидеть реализацию методики ФСТЭК в КиберОснова можно на сайте.

Практические рекомендации по внедрению

С чего начать

Внедрение VM-процесса по методике ФСТЭК — не проект на одну неделю. Реалистичный подход — поэтапное развёртывание.

Шаг 1. Инвентаризация. Невозможно управлять уязвимостями без знания инфраструктуры. Начните с полной инвентаризации активов: серверы, рабочие станции, сетевое оборудование, СУБД, веб-приложения. Присвойте каждому активу класс критичности и владельца. Это фундамент всего процесса.

Шаг 2. Регулярное сканирование. Запустите сканер на 100% инвентаризированных активов. Частота: критичные серверы — еженедельно, рабочие станции — ежемесячно, тестовые среды — ежеквартально. Обеспечьте покрытие выше 95%.

Шаг 3. SLA и роли. Утвердите SLA-матрицу (таблица выше). Зафиксируйте роли в RACI-матрице. Доведите до ИТ-подразделения и владельцев систем.

Шаг 4. Процесс устранения. Выстройте поток: сканирование → оценка → задача в системе управления → устранение → верификация. Начните с критических уязвимостей — они формируют привычку и дают быстрый результат.

Шаг 5. Метрики и отчётность. Начните с трёх метрик: MTTR, SLA Compliance, покрытие сканирования. Ежемесячный отчёт руководству. Расширяйте набор метрик по мере роста зрелости.

Шаг 6. Автоматизация. Внедрите SGRC-платформу для оркестрации процесса. Ручное управление допустимо для инфраструктуры до 50 хостов. При 100+ хостах — автоматизация обязательна.

Типичные ошибки при внедрении

1. Сканирование без устранения. Запустить сканер и получить отчёт — не значит внедрить VM. Без процесса устранения сканирование создаёт иллюзию контроля и юридическую ответственность: организация знает об уязвимостях, но не устраняет их.

2. Приоритизация только по CVSS Base Score. Контекст важнее голой цифры. Критическая уязвимость на изолированном dev-сервере без данных менее срочна, чем высокая уязвимость на периметровом веб-приложении с ПДн.

3. Нереалистичные SLA. «Все критические — за 4 часа» при штате ИТ в два человека — гарантия 0% SLA Compliance. Начинайте с достижимых сроков и сокращайте их по мере роста зрелости.

4. VM в отрыве от управления рисками. Управление уязвимостями — часть системы управления рисками ИБ, а не изолированный процесс. Если VM не связан с моделью угроз, реестром рисков и комплаенсом, организация теряет целостную картину.

5. Игнорирование покрытия. Сканирование 60% инфраструктуры оставляет 40% в слепой зоне. Именно незнаемые, неучтённые активы становятся точками входа для атакующих.

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

7. Ручной сбор метрик. Если MTTR считается в Excel раз в квартал — это не метрика, а археология. Метрики должны быть автоматическими и доступными в реальном времени.

Чек-лист готовности VM-процесса по методике ФСТЭК

• Реестр активов актуален, охват > 95%, у каждого актива есть владелец и класс критичности.
• Регулярное сканирование настроено на 100% инвентаризированных активов.
• SLA-матрица утверждена руководством, доведена до ИТ-подразделения.
• Роли зафиксированы в RACI-матрице, ответственные назначены.
• Процесс оценки и приоритизации учитывает CVSS + контекст актива + наличие эксплойта.
• Задачи на устранение создаются автоматически с привязкой к ответственным и SLA.
• Верификация (повторное сканирование) выполняется после каждого устранения.
• Журнал действий ведётся и доступен для аудита.
• Метрики (MTTR, SLA Compliance, покрытие) формируются автоматически.
• Ежемесячный отчёт по метрикам VM предоставляется руководству.
• VM-процесс интегрирован с управлением рисками и моделью угроз.
• Регламент VM-процесса документирован и пересматривается ежегодно.

Детальный разбор пяти этапов VM-цикла с практическими примерами и CVSS-таблицами: Процесс управления уязвимостями. Сравнение платформ для автоматизации полного цикла: Системы управления уязвимостями: обзор и сравнение.

Методика ФСТЭК по управлению уязвимостями — не формальность для прохождения проверки. Это рабочий фреймворк, который при правильном внедрении превращает хаотичное «патчим по возможности» в измеримый, контролируемый и аудитопригодный процесс. VM-процесс является частью автоматизации ИБ организации — наряду с учётом СКЗИ, управлением рисками и комплаенсом. Начните с инвентаризации и SLA, автоматизируйте через SGRC — и покажите регулятору не отчёт на 200 страниц, а живой процесс с метриками. Запросите демо КиберОснова и оцените, как платформа реализует методику ФСТЭК от мониторинга до контроля устранения.