Управление уязвимостями по требованиям ФСТЭК и БДУ
Управление уязвимостями по требованиям ФСТЭК — это не «поставить сканер», а выстроить непрерывный процесс: выявление уязвимостей, их сопоставление с Банком данных угроз безопасности информации (БДУ ФСТЭК), оценка опасности, приоритизация и устранение в разумные сроки с фиксацией результата. Для значимых объектов критической информационной инфраструктуры (КИИ) и государственных информационных систем (ГИС) такой процесс прямо вытекает из приказов ФСТЭК по защите информации. **Если коротко:** регулятор ждёт от вас не разового аудита, а управляемого цикла. Уязвимости нужно искать регулярно, сверять с БДУ и реестром сертифицированных средств, ранжировать по опасности и контексту, устранять или компенсировать и документировать каждый шаг. Ниже — роль БДУ, увязка с приказами ФСТЭК, таблица «требование → что обеспечить», подход к срокам и приоритизации и чек-лист соответствия. Сравнить поставщиков по подтверждённым сигналам можно в [рейтинге систем управления уязвимостями](/rating/vulnerability-management).
Визуальный контекст исследования
Изображение помогает быстро считать тему материала: инфраструктура, данные, доступы и контрольные точки, которые важно проверить перед выбором решения.
Рейтинги подрядчиков по теме исследования
Если после чтения нужен короткий список исполнителей, начните с профильных рейтингов cyber-index.ru: в них видны компании, кейсы, интервью, категории экспертизы и доверительный индекс.
Как проверять выводы исследования
Используйте материал как основу для shortlist: сопоставьте выводы с профилями компаний, связанными рейтингами, кейсами, интервью клиентов и источниками. Если в статье есть список источников, начинайте проверку с него; если источников мало, дополнительно запросите у подрядчика методику, baseline и примеры работ.
Что требует ФСТЭК: управление уязвимостями как процесс
В нормативной логике ФСТЭК анализ уязвимостей и управление обновлениями — это меры защиты информации, встроенные в общий контур обеспечения безопасности значимых объектов КИИ, ГИС и других защищаемых систем. Требования формулируются не как «купите продукт X», а как набор функциональных задач, которые организация обязана решать на протяжении всего жизненного цикла системы.
Ключевая идея — непрерывность и доказуемость. Недостаточно один раз просканировать инфраструктуру: нужно периодически выявлять уязвимости, оценивать их применительно к вашим активам, устранять или обоснованно компенсировать и хранить свидетельства того, что процесс работает. Именно поэтому управление уязвимостями (vulnerability management) естественно ложится на требования регулятора: оно как раз и описывает этот замкнутый цикл.
Роль БДУ ФСТЭК в управлении уязвимостями
Банк данных угроз безопасности информации (БДУ ФСТЭК, [bdu.fstec.ru](https://bdu.fstec.ru/)) — это ведущийся регулятором источник сведений об уязвимостях и угрозах. Для процесса VM он играет несколько ролей:
- **Единая система идентификации.** Уязвимости в БДУ имеют собственные идентификаторы, по которым удобно вести учёт и обмен сведениями внутри страны, в дополнение к международным идентификаторам. - **Источник для приоритизации.** БДУ содержит описания уязвимостей и сведения об их опасности, которые помогают понять, насколько критична уязвимость в вашем контексте. - **Опорная точка для соответствия.** Сопоставление выявленных уязвимостей с записями БДУ показывает регулятору и аудитору, что вы опираетесь на признанный национальный источник, а не только на зарубежные базы.
Практический смысл: сканер или система VM должны уметь сопоставлять найденное с БДУ, а не работать исключительно по внешним фидам. Это одно из ключевых отличий «российского» управления уязвимостями от подхода, ориентированного только на международные базы.
Требование регулятора → что обеспечить в процессе VM
| Что ожидает регулятор (обобщённо) | Что нужно обеспечить в процессе VM |
|---|---|
| Регулярное выявление уязвимостей | Периодическое сканирование активов, инвентаризация, охват внешнего и внутреннего периметра |
| Использование признанных источников | Сопоставление найденного с БДУ ФСТЭК и реестром сертифицированных СЗИ |
| Оценка опасности уязвимостей | Скоринг с учётом контекста актива: критичность, доступность извне, наличие эксплойта |
| Своевременное устранение | Процесс установки обновлений и патчей, а где невозможно — компенсирующие меры |
| Приоритизация работ | Ранжирование по опасности и значимости актива, а не «по списку подряд» |
| Документирование и контроль | Журналы сканирований, статусы устранения, отчётность, повторная проверка |
| Доверенные средства защиты | Применение средств из реестра сертифицированных СЗИ, где это требуется для объекта |
Сроки и приоритизация для КИИ и ГИС
Универсального «срока устранения для всех уязвимостей» в законе нет — конкретика зависит от категории объекта, опасности уязвимости и применимых документов. Поэтому правильная тактика — не угадывать единый дедлайн, а выстроить приоритизацию, в которой срок устранения привязан к риску:
- **Критичные и активно эксплуатируемые уязвимости** на доступных извне системах устраняются в первую очередь и в максимально сжатые сроки. - **Высокая опасность на значимых активах** — следующий приоритет; если патч недоступен, вводятся компенсирующие меры (сегментация, ограничение доступа, виртуальный патчинг). - **Средняя и низкая опасность** устраняется планово, в рамках циклов обновления.
Для значимых объектов КИИ и ГИС добавляется требование доказуемости: важно не только устранить, но и зафиксировать, когда уязвимость обнаружена, как оценена её опасность, какое решение принято (устранить/компенсировать) и когда подтверждено закрытие повторной проверкой. Если по конкретному типу объекта установлены нормативные сроки реагирования — их нужно брать из действующих документов ФСТЭК, а не из общих оценок.
Что чаще «проваливает» соответствие в процессах VM
Редакционная оценка частоты типовых пробелов по открытым материалам и практике. Это не официальная статистика ФСТЭК и не заменяет аудит вашей системы.
Управление уязвимостями по ФСТЭК: ориентиры
bdu.fstec.ru — сопоставлять найденное обязательно
Не разовый аудит, а цикл выявления и устранения
Привязка к опасности и значимости актива
reestr.fstec.ru и reestr.digital.gov.ru
Как выбрать средства под требования ФСТЭК
Функционально система управления уязвимостями должна закрывать весь цикл: инвентаризацию активов, выявление уязвимостей, обогащение данными об опасности, приоритизацию, управление устранением и отчётность. Под требования российского регулятора к этому добавляется специфика:
- **Поддержка БДУ ФСТЭК.** Возможность сопоставлять найденное с национальным банком данных, а не только с зарубежными базами. - **Статус в реестрах.** Для значимых объектов КИИ и ГИС важны наличие в реестре российского ПО и, где требуется, сертификат ФСТЭК нужного класса/типа — проверяйте по первоисточникам, а не по словам поставщика. - **Доказательная отчётность.** Журналы, статусы устранения, выгрузки для аудита и регулятора — то, что превращает «мы сканируем» в «мы соответствуем». - **Охват инфраструктуры.** Серверы, рабочие станции, сетевое оборудование, прикладное и отечественное ПО, по возможности — контейнеры и облако.
Конкретные продукты и их подтверждённые внедрения сравнивайте в [рейтинге систем управления уязвимостями](/rating/vulnerability-management): здесь — требования и критерии, там — поставщики по проверяемым сигналам.
Чек-лист соответствия требованиям ФСТЭК
Процесс устранения уязвимости: 6 шагов
-
01
Выявление
Регулярное сканирование активов обнаруживает уязвимость; фиксируется узел, сервис и идентификатор.
-
02
Идентификация и сверка
Уязвимость сопоставляется с БДУ ФСТЭК и зарубежными базами, уточняется описание и опасность.
-
03
Оценка в контексте
Опасность пересчитывается под ваш актив: критичность системы, доступность извне, наличие эксплойта.
-
04
Приоритизация и решение
Определяется срок и способ: установить обновление либо ввести компенсирующие меры, если патч недоступен.
-
05
Устранение
Применяется патч или компенсирующая мера; изменение проводится по процедуре управления обновлениями.
-
06
Проверка и фиксация
Повторное сканирование подтверждает закрытие; результат документируется для отчётности и аудита.
Как мы оцениваем поставщиков
cyber-index.ru не продаёт места в рейтинге. Поставщики сравниваются по проверяемым сигналам: подтверждённые внедрения и кейсы, отзывы и интервью клиентов, внешняя репутация, специализация, прозрачность и свежесть данных. Поэтому статью стоит читать в связке с [рейтингом систем управления уязвимостями](/rating/vulnerability-management): здесь — требования регулятора и критерии, там — сравнение конкретных компаний по подтверждённым фактам.
Следующий шаг
Разобрались с требованиями — переходите к сравнению поставщиков: **[рейтинг систем управления уязвимостями →](/rating/vulnerability-management)**. Полезно прочитать рядом: [что такое управление уязвимостями](/research/chto-takoe-vulnerability-management), [рейтинг российских систем VM 2026](/research/reyting-rossiyskih-vm-2026) и [чем заменить Nessus и Qualys](/research/zamena-nessus-qualys-skanery).
Частые вопросы
Обязательно ли использовать БДУ ФСТЭК в управлении уязвимостями?
Для значимых объектов КИИ и ГИС опора на национальный источник угроз и уязвимостей — естественная часть процесса: сопоставление найденного с БДУ ФСТЭК показывает, что вы работаете по признанной регулятором базе, а не только по зарубежным фидам. Конкретную применимость сверяйте с действующими приказами ФСТЭК под вашу категорию объекта.
Какие сроки устранения уязвимостей требует ФСТЭК?
Единого срока «для всех уязвимостей» в законе нет — он зависит от категории объекта и опасности уязвимости. Правильный подход — приоритизация по риску: критичное и доступное извне устраняется в первую очередь. Если для вашего типа объекта установлены нормативные сроки, берите их из действующих документов ФСТЭК, а не из общих оценок.
Чем управление уязвимостями по ФСТЭК отличается от обычного сканирования?
Сканирование — лишь один шаг. Требования регулятора описывают непрерывный цикл: выявление, сверка с БДУ, оценка опасности, приоритизация, устранение или компенсация и документирование с повторной проверкой. Разовый аудит этому не удовлетворяет.
Нужен ли сертификат ФСТЭК на сам сканер уязвимостей?
Зависит от объекта и состава мер. Для значимых объектов КИИ и ГИС применяемые средства защиты часто должны иметь статус в реестрах и, где требуется, сертификат нужного класса/типа. Проверяйте по реестру сертифицированных СЗИ и реестру российского ПО, а не по словам поставщика.
Что делать, если патча для уязвимости нет?
Вводить компенсирующие меры: сегментацию сети, ограничение доступа, виртуальный патчинг, усиленный мониторинг. Решение и его обоснование фиксируются, а уязвимость остаётся на контроле до появления штатного исправления.
Где сравнить конкретные системы управления уязвимостями?
В рейтинге систем управления уязвимостями — там поставщики ранжированы по подтверждённым сигналам, а не по рекламе.
Источники и метод проверки
Управление уязвимостями по требованиям ФСТЭК — это не «поставить сканер», а выстроить непрерывный процесс: выявление уязвимостей, их сопоставление с Банком данных угроз безопасности информации (БДУ ФСТЭК), оценка опасности, приоритизация и устранение в разумные сроки с фиксацией результата. Для значимых объектов критической информационной инфраструктуры (КИИ) и государственных информационных систем (ГИС) такой процесс прямо вытекает из приказов ФСТЭК по защите информации. **Если коротко:** регулятор ждёт от вас не разового аудита, а управляемого цикла. Уязвимости нужно искать регулярно, сверять с БДУ и реестром сертифицированных средств, ранжировать по опасности и контексту, устранять или компенсировать и документировать каждый шаг. Ниже — роль БДУ, увязка с приказами ФСТЭК, таблица «требование → что обеспечить», подход к срокам и приоритизации и чек-лист соответствия. Сравнить поставщиков по подтверждённым сигналам можно в [рейтинге систем управления уязвимостями](/rating/vulnerability-management).