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

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

Разбираем по тексту документов, что из этого обязательно, как считать критичность, в какие сроки закрывать уязвимости и какими средствами их выявлять.

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

Руководство адресовано государственным органам и организациям, в том числе субъектам критической информационной инфраструктуры, — операторам систем, которые выполняют требования ФСТЭК к ГИС, к значимым объектам КИИ и другие её требования. Если требования ФСТЭК на компанию не распространяются, руководство ей не предписано, но как готовый каркас регламента подходит любой организации. Что изменил сам приказ № 117, мы разбирали отдельно.

Пять этапов процесса и кто за них отвечает

Руководство делит работу на пять этапов:

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

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

Ведут процесс два подразделения. Со стороны защиты информации — руководитель, аналитик угроз, специалист по оценке защищённости и специалист по внедрению мер защиты; со стороны ИТ — руководитель и специалист. По решению руководителя организации подключают закупки и службу инженерных систем. В небольшой организации роли совмещают — руководство это прямо допускает.

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

Откуда брать сведения об уязвимостях

На первом этапе руководство называет три группы источников:

• внутренние — системы управления ИТ-инфраструктурой, базы данных управления конфигурациями (CMDB), документация на системы, базы знаний организации;
• банк данных угроз безопасности информации ФСТЭК России (БДУ, bdu.fstec.ru) — в нём есть база уязвимостей и калькуляторы CVSS;
• внешние — базы данных известных уязвимостей, официальные ресурсы разработчиков и исследователей.

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

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

Как считать критичность по методике 2025 года

Методика разделяет два понятия. Уровень опасности — это оценка уязвимости по CVSS, одинаковая для всех. Уровень критичности — то, насколько она опасна в конкретной системе. Критичность считают по формуле:

V = Icvss × Iinfr × (Iat + Iimp)

• Icvss — базовая оценка по CVSS 3.1, которую дал разработчик; её берут из БДУ или других баз;
• Iinfr — влияние на систему: какой компонент уязвим (межсетевой экран, сервер, рабочее место и т. д.), какая доля компонентов затронута и доступен ли уязвимый компонент из интернета;
• Iat — возможность эксплуатации: уязвимость используют в реальных атаках, есть эксплойт или сведений нет;
• Iimp — последствия: выполнение произвольного кода, повышение привилегий, обход защиты, отказ в обслуживании и другие.

Пример из самой методики: уязвимость межсетевого экрана с оценкой CVSS 8,8 — высокий уровень опасности. Экран доступен из интернета, уязвимы от 10 до 50 % компонентов, сведений об эксплойте нет. Расчёт даёт V = 8,8 × 0,9 × (0,1 + 0,5) ≈ 4,75 — средний уровень критичности. Появись в открытом доступе эксплойт, значение Iat выросло бы, а с ним и критичность.

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

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

Методика отсчитывает сроки с момента оценки критичности. Приказ № 117 требует устранить уязвимость, которую могут использовать нарушители, или исключить её использование компенсирующими мерами — и говорит при этом об уровне опасности со ссылкой на ГОСТ Р 56545-2015, а не о критичности по методике. Поэтому в регламенте стоит прямо записать, по какому показателю вы отсчитываете обязательные сроки.

Обновление или компенсирующие меры

Устранить уязвимость можно двумя способами: поставить обновление или принять компенсирующие меры.

Решение об установке обновлений зарубежного ПО и ПО с открытым кодом принимают с учётом тестирования по методике тестирования обновлений; если результаты такого тестирования уже есть в БДУ, руководство позволяет опереться на них. Методика ищет недекларированные возможности, включая политические баннеры и призывы, и состоит из шести проверок: сверка идентичности, проверка подлинности, антивирусный контроль, поиск опасных конструкций, мониторинг активности в тестовой среде и ручной анализ. Тестируют на отдельном стенде, в тестовой зоне или в рабочей системе — среду выбирает исследователь, исходя из своих технических возможностей и риска нарушить работу системы. Затем обновление ставят на тестовый сегмент и только после этого распространяют на всю систему.

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

Если обновления нет, его нельзя получить или оно ломает систему, применяют компенсирующие меры. Методика перечисляет:

• изменение конфигурации уязвимых компонентов;
• ограничение использования уязвимого ПО или отключение уязвимых служб и сетевых протоколов;
• резервирование серверов, оборудования и каналов связи;
• сигнатуры и решающие правила средств защиты, которые выявляют попытки эксплуатации;
• мониторинг событий безопасности, связанных с уязвимостью, — как его ведут, разбираем в статье о российских SIEM-системах.

Контроль устранения и показатель Кзи

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

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

• на устройствах и интерфейсах, доступных из интернета, нет критических уязвимостей, обновления или меры для которых опубликованы больше 30 дней назад;
• на рабочих местах и серверах нет критических уязвимостей с обновлением старше 90 дней — не менее чем на 90 % устройств.

В обоих случаях засчитываются реализованные компенсирующие меры. Подтверждают показатели отчётами средства анализа защищённости, причём для интернет-периметра — сканированием не старше 30 дней на дату оценки. Кроме того, управление уязвимостями — одно из 21 направления, по которым оценивают уровень зрелости защиты информации по методике 2026 года.

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

Приказ № 117 требует включить порядок выявления, оценки и устранения уязвимостей во внутренние регламенты. Что именно в нём должно быть, расписывает методический документ «Состав и содержание мероприятий и мер»:

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

Там же перечислены усиления, которые оператор вводит по своему решению: автоматизированная система управления уязвимостями, средства анализа угроз, в том числе TI-платформы, данные CMDB для оценки применимости и контроль устранения по результатам мониторинга безопасности, управления обновлениями или конфигурациями.

Чем выявлять уязвимости: сертифицированные средства

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

Полезно различать два класса решений. Сканер проверяет заданные адреса и выдаёт отчёт с уязвимостями и рекомендациями по устранению. Система управления уязвимостями добавляет к этому процесс: базу активов, пересчёт опасности и контроль сроков. Например, MaxPatrol VM ведёт базу активов сети, после обновления базы знаний определяет опасность новой уязвимости для узлов без повторного сканирования и позволяет задать регламенты сканирования и устранения с контролем сроков на дашбордах.

Сертифицированные средства в нашем каталоге — номера и сроки по государственному реестру ФСТЭК на 26 сентября 2026 года:

Приказ № 117 требует от средств защиты для ГИС первого класса уровень доверия не ниже 4-го, второго — не ниже 5-го, третьего — 6-й (чем меньше номер, тем выше уровень); все средства в таблице этому соответствуют. Как самому проверить сертификат по реестру — в разборе сертификатов ФСТЭК и ФСБ. Различаются они единицей лицензии, режимами проверки и платформой установки — выбирать стоит под свою сеть и требования аттестации.

У XSpider срок сертификата ФСТЭК № 3247 истёк 24 октября 2025 года (сертификат Минобороны № 2910 действует до 24 мая 2028 года), у MaxPatrol 8 сертификат ФСТЭК № 2922 истёк 8 июля 2024 года. Где нужен действующий сертификат ФСТЭК, берут средства из таблицы. Держать под контролем внешний периметр помогает сервис PT EASM: он находит активы, доступные из интернета, и проверяет их на уязвимости и ошибки конфигурации.

Для небольшой компании сканер — один из четырёх продуктов минимального набора против шифровальщиков; остальные три разобраны в статье «Защита от шифровальщиков для малого бизнеса».

Начальная позиция XSpider PRO — режим Pentest на 4 IP-адреса:

Рекомендуем в статье Программное обеспечение XSpider PRO. Лицензия Pentest на 4 IP, срок действия лицензии, включая обновления, 1 (один) год.

PT-XSP-P4

26 366 ₽ НДС не облагается (ст. 149 НК РФ) — позиция в реестре российского ПО

В корзину В корзине Подробнее →

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

Частые вопросы