Приоритизация уязвимостей по методике ФСТЭК

Введение

При управлении уязвимостями в реальной инфраструктуре специалист по ИБ почти всегда сталкивается с проблемой объёма: сканирование даже среднего периметра выдаёт сотни и тысячи найденных уязвимостей. Устранить всё и сразу невозможно, а универсальная оценка серьёзности уязвимости (CVSS) не учитывает, насколько важен конкретный актив для инфраструктуры заказчика.

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

В этой статье разбираем, что такое показатель критичности V, как он рассчитывается в Vulns.io Enterprise VM, где отображается и чем отличается от привычного CVSS Score.

Что такое приоритизация по методике ФСТЭК

Приоритизация по методике ФСТЭК — это расчёт показателя критичности уязвимости V, который учитывает не только характеристики самой уязвимости (CVSS и т. п.), но и особенности конкретного актива в инфраструктуре заказчика, на котором она обнаружена.

Показатель используется для:

• расстановки приоритетов при устранении уязвимостей — с учётом реальной значимости актива для инфраструктуры, а не только абстрактной опасности уязвимости;
• соответствия требованиям регулятора (ФСТЭК России) при построении процесса управления уязвимостями;
• актуальности оценки в реальном времени — расчёт производится сразу после сканирования любого актива, без ручного пересчёта.

Важно: Система использует актуальную методику ФСТЭК от 30.06.2025 г. — версия формулы и параметров расчёта адаптирована под неё. Поскольку методика периодически обновляется регулятором, Система следует её актуальной версии — это обеспечивает корректность приоритизации и соответствие требованиям ФСТЭК России без ручного пересчёта со стороны пользователя.

Параметры актива, влияющие на расчёт показателя V

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

В расчёте показателя V участвуют три параметра, которые пользователь задаёт на активе:

1. Важность актива. Отражает значимость актива для инфраструктуры. Возможные значения:

• критическая;
• высокая;
• средняя;
• низкая.

2. Тип актива. Определяет категорию объекта. Базовые типы:

• сервер;
• рабочая станция;
• система хранения данных;
• шлюз;
• другой.

3. Влияние на периметр. Указывает, влияет ли актив на периметр инфраструктуры. Задаётся как признак да/нет.

Перечисленные параметры задаются пользователем вручную при создании или редактировании актива.

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

• изменение важности актива, его типа или признака влияния на периметр приводит к пересмотру

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

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

Как происходит расчёт показателя V

Расчёт уровня критичности уязвимости программных и программно-аппаратных средств в информационной системе выполняется по формуле, приведённой в методическом документе ФСТЭК от 30 июня 2025 г. (стр. 4, п. 12):

V = I_cvss × I_infr × (I_at + I_imp),

где составляющие формулы отражают:

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

Полный текст методики и определение каждого коэффициента доступны в методическом документе ФСТЭК от 30.06.2025 на официальном сайте регулятора.

Где отображается и используется показатель V

Показатель V интегрирован в интерфейс Системы и доступен в нескольких местах, что позволяет использовать его на разных этапах работы с уязвимостями:

• в результатах аудита уязвимостей — в карточке каждой найденной уязвимости;
• в карточке актива;
• в обзоре уязвимостей по всей инфраструктуре;
• в отчётах об уязвимостях;
• как критерий сортировки и приоритизации активов и уязвимостей (наравне с сортировкой по CVSS Score);
• в дашборде уязвимостей — виджеты «Топ-10 уязвимостей по оценке V ФСТЭК» и «Топ-10 хостов по V ФСТЭК»;
• в правилах динамических групп — можно строить группы активов по значению V, важности, типу или влиянию на периметр.

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

Отличие приоритизации по V (ФСТЭК) от CVSS Score

Оба показателя доступны в Системе, и пользователь сам выбирает подход в зависимости от задачи. Ключевое различие — в наличии контекста инфраструктуры.

На практике это означает:

• CVSS Score удобен, когда нужно понять абстрактную опасность уязвимости вне зависимости от того, где она обнаружена — например, при оценке потенциального риска новой CVE.
• Показатель V полезен, когда нужно ответить на вопрос «что чинить в первую очередь именно в моей инфраструктуре» — он поднимает в приоритете уязвимости на критичных активах и активах, влияющих на периметр.

Заключение

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

• соответствует актуальным требованиям регулятора — методике ФСТЭК от 30.06.2025;
• не требует ручных пересчётов — оценка обновляется автоматически при каждом сканировании;
• не заменяет, а дополняет CVSS — обе метрики доступны одновременно, и специалист выбирает нужный подход под конкретную задачу.

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