ФСТЭК уязвимости: полный гайд по работе с БДУ

Что такое БДУ ФСТЭК и зачем он нужен

Банк данных угроз безопасности информации ФСТЭК России — это официальный государственный реестр, который содержит сведения о дефектах кода программного обеспечения и актуальных киберугрозах. Портал помогает операторам систем оперативно находить уязвимости в используемых программно-аппаратных средствах. Сайт bdu.fstec.ru служит главным источником верифицированных данных для оценки рисков ИБ в российских ведомствах и коммерческих компаниях.

История создания и нормативная база

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

Приказ ФСТЭК России от 16.02.2015 №9

Этот документ заложил правовую основу БДУ. Приказ ФСТЭК России №9 определил точный порядок ведения реестра. Он обязал разработчиков сертифицированных средств защиты информации (СЗИ) передавать данные о найденных ошибках в единую базу.

Методика оценки угроз безопасности информации от 05.02.2021

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

Отличие БДУ ФСТЭК от международных баз (CVE, NVD)

Российский реестр имеет важные отличия от зарубежных аналогов вроде CVE (Common Vulnerabilities and Exposures) или NVD (National Vulnerability Database):

• Юридический статус. Использование БДУ прямо предписано законами РФ для защиты государственных систем. Международные базы носят информационный характер.

• Специфика ПО. Отечественный реестр содержит уникальные сведения об уязвимостях в российском софте и сертифицированных СЗИ, которых нет в CVE.

• Привязка к SLA. Карточка БДУ интегрирована с российскими нормами права. Это позволяет выстраивать жесткие сроки ликвидации дефектов по требованиям регуляторов.

Автоматизируйте работу с уязвимостями ФСТЭК в DocShell 4.0

Ручной мониторинг обновлений базы bdu.fstec.ru и расчет метрик по новым методикам отнимают у ИБ-отдела слишком много времени. Продукты автоматизации позволяют развернуть полноценный Vulnerability Management внутри компании без расширения ИТ-штата.

Запросить демо по актуальным тарифам DocShell 4.0.

Структура БДУ ФСТЭК: как устроен реестр уязвимостей

Идентификаторы уязвимостей (BDU, CVE, CWE)

Каждая запись в реестре получает уникальный номер формата BDU:YYYY-XXXXX. Для удобства сопоставления карточки содержат кросс-ссылки на международные стандарты. Эксперты ФСТЭК указывают связанные номера CVE, а также классифицируют слабые места кода по типам недостатков CWE (Common Weakness Enumeration).

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

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

Критический уровень

Сюда относятся наиболее опасные бреши. Они позволяют злоумышленнику удаленно запустить произвольный код, вызвать полный отказ в обслуживании (DoS) или получить максимальные привилегии в операционной системе без авторизации.

Высокий уровень

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

Средний уровень

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

Низкий уровень

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

Показатели CVSS v2/v3/v4 в карточке уязвимости

Для математического выражения степени опасности ФСТЭК России использует международную метрику CVSS (Common Vulnerability Scoring System). В карточках уязвимостей БДУ отображаются расчетные баллы по шкале от 0.0 до 10.0. Наряду с классической CVSS v3, регулятор внедрил поддержку актуальной версии CVSS v4, которая точнее учитывает параметры аппаратных компонентов, систем реального времени и специфику промышленной автоматики (АСУ ТП).

Статусы уязвимостей в БДУ

Каждая позиция в реестре имеет статус, определяющий действия оператора ИС:

1. Подтвержденная — дефект безопасности верифицирован экспертами ФАУ "ГНИИИ ПТЗИ ФСТЭК России". Требуются меры защиты.

2. Потенциальная — информация проверяется, анализируются возможные сценарии эксплуатации.

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

4. Отрезвленная (архивная) — статус присваивается, если опасность уязвимости не подтвердилась в ходе детальных исследований.

Кто должен использовать БДУ ФСТЭК

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

• Субъекты критической информационной инфраструктуры (КИИ). Предприятия здравоохранения, науки, транспорта, связи, энергетики, банковской сферы и оборонной промышленности (в рамках 187-ФЗ). Сервис DocShell помогает организовать надежную защиту объектов КИИ.

• Операторы государственных информационных систем (ГИС). Государственные органы, министерства и ведомства всех уровней, выполняющие требования приказа ФСТЭК №17.

• Операторы информационных систем персональных данных (ИСПДн). Организации, обрабатывающие персональные данные граждан, при установлении актуальности угроз данного типа по 152-ФЗ.

• Государственные унитарные предприятия и учреждения. МУПы, ГУПы, казенные учреждения и организации с государственным участием.

Новые требования по управлению уязвимостями с 1 марта 2026 года

Приказ ФСТЭК России №117 от 11.04.2025

С 1 марта 2026 года правила серьезно изменились. Приказ ФСТЭК №117 скорректировал требования приказа №17 и установил жесткие сроки для устранения брешей в безопасности. Проверять сеть раз в год больше нельзя. Теперь действует регламент SLA (Service Level Agreement) на исправление недостатков кода. Подробнее о том, как перестроить работу ИБ-отдела под новые правила, читайте в статье о том, как закрыть требования по защите ГИС.

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

Важно! Срок исправления критических уязвимостей (24 часа) не прерывается на выходные и праздничные дни. Оператор обязан организовать непрерывный мониторинг.

Методика оценки уровня критичности уязвимостей от 30.06.2025

Чтобы компании понимали, какие бреши устранять в первую очередь, ФСТЭК обновила формулу расчета критичности. Вместо слепого копирования базового балла CVSS теперь вычисляют итоговый показатель на основе четырех параметров.

Показатель Icvss (уровень опасности)

Базовый балл уязвимости, взятый из карточки БДУ или рассчитанный экспертами на основе технических параметров самой ошибки в коде.

Показатель Iinfr (влияние на функционирование ИС)

Параметр оценивает, к каким последствиям в архитектуре конкретного предприятия приведет атака. Учитывается класс защищенности ГИС или категория объекта КИИ.

Показатель Iat (возможность эксплуатации)

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

Показатель Iimp (последствия эксплуатации)

Метрика оценивает потенциальный ущерб для бизнес-процессов организации или выполнения государственных функций в случае успешного проведения компьютерной атаки нарушителю.

Методика анализа защищенности от 25.11.2025

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

Методика оценки показателя защищенности от 11.11.2025

Документ ввел математическую модель контроля ИБ на предприятиях. Каждая организация обязана регулярно производить внутренний расчет текущего индекса защищенности ИТ-среды для предоставления отчетов в контролирующие органы.

Как работать с БДУ ФСТЭК на практике

Пошаговая инструкция по использованию реестра

Шаг 1: Инвентаризация программного обеспечения

Составьте полный, актуальный перечень всех используемых в компании операционных систем, СУБД, прикладных программ, сетевых прошивок и средств защиты. Без точной инвентаризации поиск уязвимостей будет неэффективен.

Шаг 2: Поиск уязвимостей в БДУ

Используя официальный сайт bdu.fstec.ru или автоматизированные API-сервисы, сопоставьте ваш реестр ПО с актуальной базой данных уязвимостей. Выделите все активные номера BDU, которые относятся к вашим версиям программных продуктов.

Шаг 3: Оценка критичности по новой методике

Примените формулу ФСТЭК от 30.06.2025 года. Оцените локальные параметры инфраструктуры (показатели $I_{infr}$, $I_{at}$, $I_{imp}$) для каждого найденного BDU-идентификатора, чтобы скорректировать базовый балл $I_{cvss}$.

Шаг 4: Приоритизация устранения

Сформируйте очередь выполнения работ. В первую очередь изолируйте или закройте патчами элементы с критическим уровнем опасности, чтобы уложиться в законное окно 24 часов. Далее переходите к объектам со сроком исправления в 7 дней.

Шаг 5: Применение мер защиты

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

Отбор актуальных угроз для конкретной системы

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

Критерии исключения угроз

Организация имеет право признать угрозу неактуальной, если:

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

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

Обоснование исключений для регулятора

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

Типовые ошибки при работе с БДУ

Копирование всего БДУ в модель угроз

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

Отсутствие обоснований исключения

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

Игнорирование обновлений реестра

Банк данных ФСТЭК обновляется практически ежедневно. Если ваша ИБ-служба проверяет базу вручную раз в квартал, система гарантированно пропустит критические уязвимости нулевого дня, нарушая требования приказа №117.

Использование БДУ без модели нарушителя

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

Интеграция БДУ ФСТЭК с моделью угроз и моделью нарушителя

Связь БДУ с моделью угроз безопасности информации

Результаты мониторинга БДУ должны напрямую влиять на вашу действующую модель угроз. Нахождение новой опасной уязвимости в критически важном софте означает автоматическую актуализацию связанной с ней угрозы безопасности информации. Это требует немедленного пересмотра достаточности внедренных средств защиты информации (СЗИ). Актуальная разработка модели угроз в DocShell 4.0 позволяет автоматизировать этот процесс.

Построение модели нарушителя с учетом БДУ

Тип нарушителя определяет его потенциал (низкий, средний, высокий). При сопоставлении с БДУ эксперты оценивают, достаточно ли условных навыков внешнего нарушителя с низким потенциалом для активации конкретной уязвимости (например, если в открытом доступе опубликован готовый эксплойт). Грамотное построение модели нарушителя исключает появление избыточных требований к системе.

Автоматизация в сервисе DocShell 4.0

Программный комплекс DocShell 4.0 берет на себя рутинную часть интеграции. Система связывает данные инвентаризации с БДУ ФСТЭК, автоматически обновляет модели угроз и выстраивает очередь задач для администраторов ИБ в строгом соответствии с действующим законодательством.

Контроль уровня защищенности и отчетность перед ФСТЭК

Расчет показателей Кзи и Пзи

Согласно методическим документам от 11.11.2025, контроль защищенности выражается через два нормативных индекса:

• $K_{зи}$ (коэффициент защищенности от базового уровня угроз) — отражает, насколько качественно в системе развернуты стандартные, базовые меры ИБ и СЗИ, предписанные приказами регулятора.

• $P_{зи}$ (показатель защищенности от актуального уровня угроз) — динамический параметр, демонстрирующий устойчивость ИТ-инфраструктуры к атакам с использованием уязвимостей из БДУ, актуальных в текущий момент времени.

Периодичность расчета и отчетности

Операторы ГИС и значимых объектов КИИ обязаны проводить перерасчет показателей $K_{зи}$ и $P_{зи}$ не реже одного раза в 6 месяцев. Результаты фиксируются в форме внутренних отчетов и должны быть доступны по первому требованию инспекторов.

Взаимодействие с ГосСОПКА

При обнаружении критических уязвимостей (особенно тех, которые уже эксплуатируются злоумышленниками), субъекты КИИ обязаны не только устранить их в течение 24 часов, но и передать информацию о компьютерном инциденте или угрозе в Главный центр ГосСОПКА (НКЦКИ) в установленные законом сроки (в течение 3–24 часов в зависимости от значимости объекта).

Разработка модели угроз и нарушителя по требованиям ФСТЭК

Чтобы учесть все нюансы новых методик 2025 года и автоматически связать их с Банком данных угроз, воспользуйтесь специализированным модулем ИС DocShell. Система сформирует юридически значимые документы для регулятора в несколько кликов.

Создать модель угроз в соответствии с актуальной базой ФСТЭК.

Автоматизация работы с уязвимостями ФСТЭК

Преимущества автоматизированных систем

Соблюдать SLA приказа №117 (закрытие критических брешей за 24 часа) вручную невозможно. Автоматизация процессов ИБ (SGRC-системы) позволяет:

• Исключить человеческий фактор и ошибки при расчетах метрик.

• Мгновенно сопоставлять результаты инвентаризации ИТ-активов со свежими обновлениями БДУ.

• Своевременно отправлять уведомления ИБ-инженерам и ИТ-департаменту на установку обновлений.

Возможности сервиса DocShell 4.0

Платформа DocShell 4.0 создана специально для автоматизации комплаенса и технической защиты информации по требованиям российских регуляторов.

• Интеграция с БДУ ФСТЭК. Модуль системы непрерывно синхронизируется с государственным реестром, оперативно подтягивая новые карточки дефектов безопасности.

• Автоматическая инвентаризация ПО. Система ведет точный учет версий операционных систем и программного обеспечения на рабочих местах и серверах предприятия.

• Расчет критичности уязвимостей. Встроенный калькулятор автоматически вычисляет показатели $I_{cvss}$, $I_{infr}$, $I_{at}$ и $I_{imp}$ согласно методике от 30.06.2025 года.

• SLA-контроль по приказу №117. Платформа запускает таймер обратного отсчета (24 часа / 7 дней) при обнаружении опасных уязвимостей и жестко контролирует сроки исполнения задач ИТ-отделом.

• Генерация документов и отчетов. Автоматическое создание моделей угроз, актов обоснования исключений и расчетов показателей $K_{зи}$, $P_{зи}$ для отправки во ФСТЭК.

Кейсы внедрения DocShell 4.0

Практический опыт эксплуатации платформы подтверждает ее эффективность в государственном и корпоративном секторах:

• ФГУП Почта Крыма — автоматизация контроля ИСПДн и КИИ на распределенной филиальной сети, успешное прохождение надзорных проверок.

• МУП Водоканал г. Сочи — категорирование и построение систем комплексной защиты объектов критической информационной инфраструктуры (КИИ).

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

Ответственность за нарушение требований по управлению уязвимостями

Несоблюдение регламентов ФСТЭК, игнорирование сроков приказа №117 и отсутствие обязательной документации влект за собой серьезные юридические последствия.

Штрафы по КоАП РФ

• Статья 13.12.1 КоАП РФ. Нарушение требований к защите информации в ГИС и ИСПДн влечет наложение административных штрафов на должностных лиц до 20 000 рублей, на юридических лиц — до 100 000 рублей.

• Статья 19.7.15 КоАП РФ. Непредставление или нарушение сроков представления сведений в ГосСОПКА о компьютерных инцидентах и уязвимостях на объектах КИИ грозит штрафами для юрлиц до 500 000 рублей.

Проверки регуляторов (ФСТЭК, Роскомнадзор, НКЦКИ)

Надзорные органы осуществляют как плановый аудит документов, так и внеплановые технические проверки с использованием сканеров безопасности. В случае обнаружения критических уязвимостей, не устраненных в течение 24 часов, регулятор выдает предписание об их немедленной ликвидации. Он имеет право приостановить действие аттестата соответствия ИС или направить материалы в прокуратуру.

Если халатность привела к успешной атаке на критические объекты КИИ с тяжкими последствиями, наступает персональная уголовная ответственность руководителей по ст. 274.1 УК РФ (до 10 лет лишения свободы).

Аудит информационной безопасности и соответствие требованиям ФСТЭК

Не уверены, что ваши ИБ-процессы соответствуют обновленному законодательству 2026 года? Эксперты помогут провести комплексный анализ систем, выявить скрытые уязвимости ИТ-периметра и подготовить организацию к проверкам регуляторов.

Заказать аудит ИБ для вашей ИТ-инфраструктуры.

[[STA:title="Аудит информационной безопасности и соответствие требованиям ФСТЭК",text="Не уверены, что ваши ИБ-процессы соответствуют обновленному законодательству 2026 года? Эксперты помогут провести комплексный анализ систем, выявить скрытые уязвимости ИТ-периметра и подготовить организацию к проверкам регуляторов.",btnName="Заказать аудит ИБ для вашей ИТ-инфраструктуры."]]

Часто задаваемые вопросы (FAQ)

[[FAQArticle]]

Заключение и рекомендации

Работа с уязвимостями ФСТЭК в 2026 году перешла из разряда формального заполнения документов в плоскость ежедневного технического контроля. Новые методические документы регулятора и приказ №117 требуют от операторов КИИ, ГИС и ИСПДн построения непрерывного процесса Vulnerability Management.

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

Источники и полезные ссылки

• Официальный портал Банка данных угроз ФСТЭК России

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

• Как закрыть требования по защите ГИС без раздувания штата

• Официальный сайт разработчика SGRC-решений ООО "АйТи Новация": г. Краснодар, ул. Красная, д. 113. Политика конфиденциальности и соглашение на обработку персональных данных доступны на сайте docshell.ru.

Комплексная защита объектов КИИ и ГИС

Обеспечьте соответствие требованиям законодательства РФ в области защиты критической инфраструктуры. Автоматизируйте аудит, инвентаризацию активов, мониторинг БДУ ФСТЭК и подготовку к проверкам с единой экосистемой DocShell 4.0.

Получить консультацию по защите объектов КИИ.