Сканер выдал сотню уязвимостей, у трёх десятков CVSS выше 7.0, и все они формально «высокие». С чего начинать? Ответ на этот вопрос ФСТЭК дала формулой: методический документ от 30 июня 2025 года устанавливает порядок расчёта уровня критичности уязвимости применительно к конкретной информационной системе. Одна и та же уязвимость получает разный уровень на периметровом сервере и на изолированном рабочем месте. Сроки устранения тоже разойдутся.
Документ заменил методику от 28 октября 2022 года. Главное отличие от привычного CVSS в том, что базовый балл здесь только половина расчёта. Вторую половину дают характеристики вашей инфраструктуры.
Разберём методику оценки критичности уязвимостей по первоисточнику: кто обязан применять, как устроена формула, что подставлять в таблицу весов, три сценария расчёта на одних и тех же входных данных и почему без инвентаризации активов посчитать не получится.
Что это за документ и кого он обязывает
Методика оценки уровня критичности уязвимостей программных, программно-аппаратных средств утверждена ФСТЭК России 30 июня 2025 года. Разработана в соответствии с подпунктом 4 пункта 8 Положения о ФСТЭК, утверждённого Указом Президента РФ от 16 августа 2004 г. № 1085 (пункт 1.1 Методики).
Область действия
Пункт 1.2 определяет предмет: порядок оценки уровня критичности уязвимостей, выявленных в программных и программно-аппаратных средствах информационных систем, информационно-телекоммуникационных сетей, автоматизированных систем управления, в том числе функционирующих на базе инфраструктуры центров обработки данных.
Ключевой здесь пункт 1.3. Он снимает распространённое заблуждение:
Настоящая методика подлежит применению операторами информационных систем при принятии ими мер по устранению уязвимостей программных, программно-аппаратных средств информационных систем в соответствии с требованиями о защите информации, содержащейся в государственных информационных системах, требованиями по обеспечению безопасности значимых объектов критической информационной инфраструктуры Российской Федерации, а также иными нормативными правовыми актами и методическими документами ФСТЭК России.
То есть перед нами обязательная процедура для организации, которая эксплуатирует информационную систему. Не внутренний инструмент регулятора для наполнения БДУ ФСТЭК. Операторы ГИС, владельцы значимых объектов КИИ, все, на кого распространяются требования ФСТЭК.
Пункт 2.3 добавляет, кто именно считает: оценка проводится специалистами по защите информации (информационной безопасности).
Отдельное правило для сертифицированных СЗИ
Пункт 1.4 выделяет средства защиты информации в особую категорию: устранение уязвимостей в сертифицированных программных и программно-аппаратных средствах защиты информации обеспечивается в приоритетном порядке и осуществляется в соответствии с эксплуатационной документацией на них, а также с рекомендациями разработчика. Для этой категории расчёт критичности не отменяется, но очередь устранения определяется вне общей логики приоритизации.
Место в системе документов ФСТЭК
Методика встраивается в процесс, описанный Руководством ФСТЭК по организации процесса управления уязвимостями: руководство задаёт пять этапов цикла, методика детализирует второй и третий: оценку и приоритизацию. Термины берутся из ГОСТ Р 50922-2006, ГОСТ Р 56545-2015 и ГОСТ Р 56546-2015 (пункт 1.5).
Формула: V = Icvss × Iinfr
Пункт 2.5 задаёт расчёт уровня критичности уязвимости в информационной системе:
V = Icvss × Iinfr
Здесь Icvss показывает уровень опасности самой уязвимости, а Iinfr — её влияние на функционирование информационной системы.
Обратите внимание на знак. В формуле стоит умножение. Встречающиеся в отраслевых пересказах варианты со сложением четырёх слагаемых первоисточнику не соответствуют.
Показатель Icvss
Пункт 2.6: Icvss определяется путём расчёта базовых, временных и контекстных метрик применительно к конкретной информационной системе по методике Common Vulnerability Scoring System (CVSS) версии 3.0 или 3.1.
- Базовые метрики — характеристики, не зависящие от времени и среды: вектор атаки, сложность атаки, уровень привилегий, взаимодействие с пользователем, влияние на конфиденциальность, целостность и доступность.
- Временные метрики — меняются со временем, но не зависят от среды: доступность средств эксплуатации, доступность средств устранения, степень доверия к информации об уязвимости.
- Контекстные метрики — зависят от среды функционирования конкретной организации.
Методика прямо указывает: Icvss может быть рассчитан с использованием калькулятора, содержащегося в Банке данных угроз ФСТЭК в разделе «Уязвимости». Наш калькулятор CVSS считает базовый балл по версиям 3.1 и 4.0. Результат по v3.1 и есть Icvss для этой формулы.
Показатель Iinfr
Пункт 2.7 раскрывает вторую половину:
Iinfr = k · K + l · L + p · P
- K — тип компонента информационной системы, подверженного уязвимости;
- L — количество уязвимых компонентов (АРМ, серверов, телекоммуникационного оборудования, СЗИ и других);
- P — влияние уязвимого компонента на защищённость периметра системы;
- k, l, p — весовые коэффициенты показателей.
Перед расчётом пункт 2.4 требует выполнить три шага: определить средства, подверженные уязвимостям; определить место их установки в системе (периметр, внутренний сегмент, участок реализации критических бизнес-процессов); и только затем считать V.
Таблица 1 — веса и оценки
| Показатель | Вес | Значение | Оценка | Итог |
|---|---|---|---|---|
| K — тип компонента | 0,4 | компоненты, обеспечивающие реализацию критических процессов, функций, полномочий | 1 | 0,4 |
| серверы | 0,8 | 0,32 | ||
| телекоммуникационное оборудование, система управления сетью передачи данных | 0,8 | 0,32 | ||
| автоматизированные рабочие места | 0,5 | 0,20 | ||
| другие компоненты | 0,5 | 0,20 | ||
| L — доля уязвимых компонентов | 0,2 | более 70% от общего числа | 1 | 0,2 |
| 50–70% | 0,8 | 0,16 | ||
| 10–50% | 0,6 | 0,12 | ||
| менее 10% | 0,5 | 0,10 | ||
| P — защита периметра | 0,4 | уязвимое средство доступно из сети «Интернет» | 1 | 0,4 |
| недоступно из сети «Интернет» | 0,5 | 0,2 |
Из таблицы следует неочевидное практическое свойство. Максимум Iinfr = 0,4 + 0,2 + 0,4 = 1,0, минимум = 0,20 + 0,10 + 0,20 = 0,5. Значит V всегда лежит в диапазоне от половины базового балла до самого балла:
Методика способна только понизить оценку CVSS, но никогда её не повышает.
Вывод простой. Уязвимость с CVSS ниже 7.0 не получит критический уровень ни при какой инфраструктуре. С CVSS ниже 3.0 она не поднимется выше среднего. Это стоит учитывать, когда бизнес требует «поднять приоритет» уязвимости, которая по базовому баллу его не заслуживает.
Четыре уровня критичности и сроки устранения
Пункт 2.8 задаёт итоговую шкалу (таблица 2):
| Суммарное количество баллов | Уровень критичности | Срок устранения (п. 3.2) |
|---|---|---|
| 7,0 ≤ V ≤ 10,0 | Критичный | в течение часов (до 24 часов) |
| 4,5 ≤ V < 7,0 | Высокий | в течение дней (до 7 дней) |
| 1,5 ≤ V < 4,5 | Средний | в течение недель (до 4 недель) |
| V < 1,5 | Низкий | в течение месяца (до 4 месяцев) |
Формулировки сроков в пункте 3.2 даны через «рекомендуется принять меры». Это ориентиры. Жёсткие требования по срокам для конкретных типов систем задают приказы: № 117 для ГИС, № 239 для значимых объектов КИИ, № 21 для ИСПДн. Методика даёт механику расчёта уровня. Приказы задают обязательность реагирования.
Исходные данные: без инвентаризации расчёт не собрать
Пункт 2.2 перечисляет, что нужно для определения критичности:
- а) база уязвимостей из Банка данных угроз ФСТЭК (bdu.fstec.ru), а также иные источники сведений об известных уязвимостях;
- б) официальные информационные ресурсы разработчиков программного обеспечения и исследователей в области информационной безопасности;
- в) сведения о составе и архитектуре информационных систем, полученные по результатам их инвентаризации и (или) приведённые в документации на системы;
- г) результаты контроля защищённости информационных систем, проведённого оператором.
Методика добавляет: указанные исходные данные могут уточняться или дополняться с учётом особенностей области деятельности организации.
На пункте «в» расчёт чаще всего и останавливается. Показатель K требует знать тип каждого уязвимого компонента и его роль в критических процессах. Показателю L нужна доля уязвимых узлов от общего числа, то есть знаменатель: сколько всего компонентов в системе. Показателю P нужна доступность конкретного узла из сети «Интернет». Ни одну из трёх величин отчёт сканера не даёт. Сканер видит хосты, но не знает, какой из них обслуживает критический бизнес-процесс и сколько всего активов у организации.
Определение места установки — отдельный шаг
Пункт 2.4 разбивает оценку на три действия, и второе из них часто пропускают: определить в информационной системе место установки средств, подверженных уязвимостям. Методика приводит примеры таких мест: периметр системы, внутренний сегмент, участок реализации критических процессов (бизнес-процессов), другие сегменты.
Этот шаг питает сразу два показателя формулы. Место установки на периметре задаёт значение P, то есть доступность из сети «Интернет». Участие компонента в критическом процессе поднимает K с 0,8 до 1,0. Это на четверть увеличивает вклад самого весомого слагаемого. Без сегментной карты оба показателя приходится назначать экспертно, и расчёт теряет воспроизводимость. Два аналитика получат разные уровни критичности для одной и той же уязвимости.
Поэтому инвентаризация ИТ-активов работает как постоянный источник данных для каждого расчёта критичности. Это не разовый подготовительный этап. Реестр активов с типом компонента, привязкой к процессам и признаком доступности из сети «Интернет» превращает формулу из ручного упражнения в автоматический расчёт.
Три сценария на одной уязвимости
Возьмём уязвимость с базовым баллом CVSS 8,5 и посчитаем V для трёх разных мест установки.
Сценарий 1. Сервер, доступный из интернета, единичный узел.
- K: серверы → 0,8 × вес 0,4 = 0,32
- L: менее 10% компонентов → 0,5 × вес 0,2 = 0,10
- P: доступно из интернета → 1 × вес 0,4 = 0,40
- Iinfr = 0,32 + 0,10 + 0,40 = 0,82
- V = 8,5 × 0,82 = 6,97 → Высокий уровень, срок до 7 дней
До критического уровня не хватило трёх сотых балла. Наглядно видно, почему расчёт стоит документировать.
Сценарий 2. Та же уязвимость на изолированном рабочем месте.
- K: АРМ → 0,5 × 0,4 = 0,20
- L: менее 10% → 0,5 × 0,2 = 0,10
- P: недоступно из интернета → 0,5 × 0,4 = 0,20
- Iinfr = 0,50
- V = 8,5 × 0,50 = 4,25 → Средний уровень, срок до 4 недель
Сценарий 3. Компонент критического бизнес-процесса, интернет-доступ, поражено более 70% узлов.
- K: критические процессы → 1 × 0,4 = 0,40
- L: более 70% → 1 × 0,2 = 0,20
- P: доступно из интернета → 1 × 0,4 = 0,40
- Iinfr = 1,0
- V = 8,5 × 1,0 = 8,5 → Критичный уровень, срок до 24 часов
Одна запись из БДУ, один и тот же CVSS. Разброс сроков от суток до месяца. Именно это методика и формализует: приоритет задаёт опасность уязвимости в вашей инфраструктуре.
Устранение, обновления и компенсирующие меры
Раздел 3 методики описывает, что делать после расчёта.
Пункт 3.1: в зависимости от уровня критичности оператор принимает решение о необходимости устранения. Пункт 3.3: уязвимости устраняются установкой обновления либо принятием компенсирующих организационных и технических мер.
Зарубежное и open-source ПО: отдельный порядок. Пункт 3.4: если уязвимость содержится в зарубежных средствах или программном обеспечении с открытым исходным кодом, решение об установке обновления принимается оператором с учётом результатов тестирования этого обновления, проведённого в соответствии с Методикой тестирования обновлений безопасности программных, программно-аппаратных средств, утверждённой ФСТЭК России 28 октября 2022 г., и оценки ущерба от нарушения функционирования системы по результатам установки.
Когда обновиться нельзя. Пункт 3.5: при невозможности получения, установки и тестирования обновлений принимаются компенсирующие меры защиты информации. Пункт 3.6 задаёт их выбор с учётом архитектуры системы и способов эксплуатации уязвимости и приводит перечень:
- изменение конфигурации уязвимых компонентов, в том числе в части доступа к функциям, исполнение которых может способствовать эксплуатации;
- ограничение использования уязвимых средств или перевод их в режим, ограничивающий исполнение уязвимых функций (например, отключение уязвимых служб и сетевых протоколов);
- резервирование компонентов системы, включая серверы, телекоммуникационное оборудование и каналы связи;
- использование сигнатур и решающих правил средств защиты информации, обеспечивающих выявление признаков эксплуатации уязвимостей;
- мониторинг информационной безопасности и выявление событий, связанных с возможностью эксплуатации уязвимостей.
Компенсирующая мера не отменяет уязвимость. Она снижает вероятность эксплуатации до момента полного устранения. Решение и обоснование фиксируйте документально: при проверке регулятор смотрит именно на обоснование выбора меры.
Автоматизация оценки критичности уязвимостей
Поток идёт десятками записей в неделю. Вручную это не считается. Три таблицы на каждую уязвимость съедят рабочий день аналитика. Механика автоматизируется целиком. Все входные данные уже существуют в разных системах, их нужно связать.
В модуле управления уязвимостями платформы КиберОснова расчёт собирается так:
- Icvss — из карточки уязвимости БДУ ФСТЭК, база синхронизируется и содержит оценки CVSS, сведения об эксплойтах и связанные идентификаторы CVE.
- K — из карточки актива в реестре инвентаризации: тип компонента и признак участия в критическом процессе.
- L — отношение числа поражённых активов к общему числу компонентов системы, считается по реестру автоматически.
- P — из атрибута доступности актива из сети «Интернет».
На выходе получается уровень критичности по таблице 2, срок устранения и приоритизированная очередь работ с обоснованием по каждой позиции. Расчёт пересобирается при изменении инфраструктуры: перенесли сервис за периметр, критичность связанных уязвимостей пересчитается.
Отдельная практическая ценность в воспроизводимости. Когда регулятор или внутренний аудит спрашивает, почему уязвимость с CVSS 8,9 устранялась четыре недели, ответом служит сохранённый расчёт: изолированный сегмент, единичный узел, Iinfr 0,5, итоговый V 4,45. Средний уровень, срок соблюдён.
Пять ошибок при расчёте
Методика короткая. Но промахи допускает. Все они меняют итоговый уровень, а значит и срок устранения.
Складывать вместо умножения. Пункт 2.5 задаёт произведение: V = Icvss × Iinfr. В отраслевых пересказах встречается вариант с суммой нескольких слагаемых. При нём максимум показателя перестаёт совпадать со шкалой таблицы 2, и вся приоритизация разъезжается. Сверяйтесь с первоисточником.
Брать CVSS v4.0. Пункт 2.6 называет конкретные версии: CVSS 3.0 или 3.1. Четвёртая версия использует другую модель метрик, поэтому её балл в формулу подставлять нельзя, даже если он есть в карточке уязвимости. Нужен балл v3.x.
Считать L от числа уязвимых компонентов. Показатель L берётся от общего числа компонентов в информационной системе. В знаменателе стоит весь парк компонентов системы, а выборка сканера тут ни при чём. Если найдено 8 уязвимых серверов при 200 компонентах в системе, доля составляет 4%. Это попадает в «менее 10%», оценка 0,5. Ошибка в знаменателе завышает критичность всего потока уязвимостей.
Забывать про пункт 1.4. Уязвимости в сертифицированных средствах защиты информации устраняются в приоритетном порядке по эксплуатационной документации и рекомендациям разработчика, независимо от того, какой уровень дал расчёт. В общую очередь по величине V она не встаёт.
Путать сроки методики со сроками приказов. Пункт 3.2 формулирует сроки как рекомендацию («рекомендуется принять меры»). Обязательность реагирования и собственные сроки для конкретных типов систем устанавливают приказы ФСТЭК: № 117 для ГИС, № 239 для значимых объектов КИИ, № 21 для ИСПДн. Во внутреннем регламенте стоит указывать оба ориентира и применять более жёсткий.
Что делать дальше
Методика ФСТЭК от 30.06.2025 переводит приоритизацию уязвимостей из области экспертного суждения в область арифметики. Три показателя, две таблицы, одно умножение. Уязвимости выстраиваются в очередь с обоснованием, которое можно показать проверяющему.
Отдельно стоит учесть, что методика не отменяет и не заменяет процессные требования. Руководство ФСТЭК по организации процесса управления уязвимостями задаёт цикл целиком: мониторинг, оценку, приоритизацию, устранение и контроль. Расчёт критичности закрывает второй и третий этапы этого цикла. Без налаженного мониторинга уязвимости просто не дойдут до расчёта, а без контроля устранения соблюдение сроков останется на бумаге.
Порядок внедрения:
- Проверить, что реестр активов содержит тип компонента, привязку к критическим процессам и признак доступности из интернета. Без этих трёх атрибутов формула не считается.
- Зафиксировать методику расчёта во внутреннем регламенте управления уязвимостями со ссылкой на документ ФСТЭК.
- Автоматизировать расчёт, чтобы уровень критичности присваивался прямо при загрузке результатов сканирования.
- Настроить пересчёт при изменениях инфраструктуры.
Первый пункт обычно и оказывается самым трудоёмким. Тип компонента, привязка к процессам и доступность из интернета редко лежат в одном месте. В КиберОснова SGRC эти атрибуты живут в реестре активов и подтягиваются в расчёт автоматически вместе с данными БДУ, поэтому уровень критичности присваивается в момент загрузки отчёта сканера. Вручную по трём таблицам считать не приходится.
Посмотреть, как это работает на ваших данных, можно на демонстрации платформы. Покажем полный путь от импорта отчёта сканера до приоритизированного плана устранения со сроками по каждой уязвимости.
