БДУ ФСТЭК используют, когда готовят модель угроз, выбирают защитные меры, проводят аудит или управляют уязвимостями. База помогает связать угрозы с активами, условиями реализации, последствиями и конкретной защитой, а не просто перечислить УБИ ради формального документа.
Ниже разберём, как искать угрозы в БДУ, читать карточки УБИ, отбирать актуальные риски и связывать базу с реальной инфраструктурой.
Что даёт БДУ ФСТЭК без бумажной имитации
БДУ ФСТЭК, или Банк данных угроз безопасности информации, хранит описания угроз, уязвимостей и справочные материалы по технической защите информации. В разделе угроз каждая запись получает идентификатор УБИ. Формат выглядит сухо, зато в работе экономит время: вместо общей фразы про риск несанкционированного доступа команда ссылается на конкретную угрозу и разбирает применимость к системе.
Главная польза БДУ проявляется при работе с моделью угроз. База помогает описать угрозу, указать объекты воздействия, возможных нарушителей, условия реализации и последствия. Когда организация защищает персональные данные, государственную информационную систему, промышленный сегмент или обычный корпоративный сервис, единый язык снижает хаос. Безопасник не придумывает угрозы из головы, администратор понимает, какие настройки проверять, владелец системы видит связь с деньгами, данными и простоями.
Раздел уязвимостей решает соседнюю задачу. Записи формата BDU:год-номер описывают конкретные ошибки в программном обеспечении, сетевых устройствах, операционных системах и прикладных продуктах. Для управления уязвимостями раздел связывает CVE, бюллетени вендоров, результаты сканера и российский регуляторный контекст. Сканер нашёл проблему, команда ИБ проверила актив, оценила угрозу и назначила приоритет исправления.
БДУ не работает как кнопка «сделать безопасно». База не знает, где лежат резервные копии, кто имеет права администратора, какие порты открыты наружу и кто из подрядчиков до сих пор подключается по старому VPN-профилю. БДУ даёт исходный материал, а специалист проверяет архитектуру, данные, каналы доступа, пользователей, внешние зависимости и последствия инцидента. Справочник лекарств помогает врачу, но диагноз по названию препарата не ставят.
Частые ошибки: где БДУ превращают в бесполезную бумагу
Первая ошибка знакома почти всем, кто видел модели угроз «на вес». Автор выгружает длинный список УБИ, отмечает половину строк как актуальные и добавляет пару общих фраз про меры защиты. Документ выглядит внушительно, но пользы мало. При первом вопросе, почему угроза применима к конкретной системе, обычно начинается неприятная пауза. Лучше выбрать меньше угроз, но дать нормальное обоснование по каждой.
Вторая ошибка: искать угрозы без карты системы. До работы с БДУ нужно описать активы, данные, серверы, рабочие станции, базы, веб-приложения, сетевые сегменты, удалённый доступ, администраторов, подрядчиков и интеграции. Без карты специалист бродит по базе как по энциклопедии. Вроде всё полезно, но непонятно, что брать в модель и как доказывать актуальность.
Третья ошибка: путать угрозу и уязвимость. Угроза описывает нежелательное событие и последствия для системы: утечку, изменение, удаление данных, отказ сервиса, захват учётной записи. Уязвимость показывает конкретную слабость, через которую нарушитель может реализовать угрозу. Например, старая версия VPN-шлюза с критической ошибкой относится к уязвимостям, а компрометация удалённого доступа уже попадает в логику угроз и последствий.
Четвёртая ошибка: писать меры защиты туманными фразами. Формулировка «реализовать организационные и технические меры» звучит официально, но ничего не меняет. Рабочая мера отвечает на конкретные вопросы: что включить, где настроить, кто отвечает, как проверить, где хранится журнал, как часто проводится контроль. Чем точнее мера, тем проще превратить модель угроз в задачи для эксплуатации, разработки и ИБ.
Как искать угрозы в БДУ за 6 шагов
Удобнее начинать не с поиска по ключевым словам, а с короткого описания защищаемой системы. Команда фиксирует состав инфраструктуры, типы данных, внешние интерфейсы, роли пользователей, административный доступ, связи с подрядчиками и критичные бизнес-процессы. После описания системы поиск по БДУ становится предметным. В поле зрения попадают не все страшные угрозы подряд, а записи, связанные с конкретными компонентами.
- Соберите карту активов. Серверы, базы данных, приложения, сетевые зоны, облачные сервисы, рабочие станции, каналы связи, администраторы и тех, кто заходит снаружи.
- Определите важные данные. Персональные данные, коммерческая тайна, платёжная информация, технологические параметры, учётные записи, ключи и журналы событий.
- Найдите угрозы в БДУ. Ищите по объектам воздействия, технологиям, типам доступа, последствиям и ключевым словам.
- Проверьте условия реализации. Нарушителю нужен доступ в сеть, учётная запись, физический доступ, возможность отправлять запросы или запускать код?
- Оцените последствия. Разделите утечку, подмену, удаление, блокировку данных и простой сервиса. Для бизнеса разница огромная.
- Свяжите угрозы с защитой. Напротив каждой актуальной УБИ укажите меры, ответственных, журналы, проверки и сроки доработки.
После первого прохода список угроз нужно почистить. Часть записей не подойдёт по архитектуре, часть потребует условий, которых в системе нет. Например, угроза с физическим доступом к серверу может не подойти облачному сервису без собственного серверного помещения, но станет важной для офиса с открытой серверной. Угроза через учётную запись подрядчика требует проверки договоров, VPN-профилей, MFA, сроков действия доступов и журналов входа.
Хороший рабочий формат выглядит просто: идентификатор УБИ, актив, условие реализации, возможное последствие, действующая защита, остаточный риск и владелец. Такой файл удобно обсуждать с администраторами, разработчиками и владельцами процессов. Люди быстрее отвечают на конкретный вопрос про VPN, API или резервные копии, чем на абстрактный разговор про информационные угрозы.
| Что проверяем | Как помогает БДУ | Что проверить в инфраструктуре |
|---|---|---|
| Удалённый доступ | Подбираем угрозы, связанные с компрометацией учётных записей, подбором паролей, ошибками VPN и перехватом трафика. | MFA, ограничения по IP, журналирование, права администраторов, отключение уволенных сотрудников и подрядчиков. |
| Веб-приложение | Ищем угрозы для ввода данных, сессий, API, загрузки файлов и ошибок бизнес-логики. | Проверка кода, WAF, контроль сессий, безопасная загрузка файлов, ограничения прав и анализ журналов. |
| Базы данных | Отбираем угрозы утечки, подмены, удаления и блокировки информации. | Роли, сетевую изоляцию, резервные копии, шифрование, аудит привилегированных действий и тест восстановления. |
| Виртуализация и контейнеры | Проверяем угрозы для гипервизора, образов, реестров, управляющих интерфейсов и межконтейнерного обмена. | Изоляцию, обновления, хранение секретов, запрет запуска от root, сканирование образов и доступ к панели управления. |
Как читать карточку УБИ и не потерять смысл
Карточка угрозы выглядит сухо только на первый взгляд. Если задавать к каждому полю инженерные вопросы, запись превращается в нормальную подсказку для анализа. Описание отвечает, что может пойти не так. Объект воздействия показывает место проблемы: данные, приложение, сетевой сервис, инфраструктурный компонент или пользовательская среда. Возможный нарушитель помогает понять, кто способен реализовать угрозу: внешний атакующий, сотрудник, администратор, подрядчик или поставщик услуги.
Карточку УБИ лучше читать не как сухую строку из справочника, а как часть моделирования угроз: источник, условия реализации, возможный сценарий и последствия должны сходиться с реальной архитектурой.
Самая ценная часть начинается при проверке условий реализации. Если угроза требует локального доступа, смотрим рабочие станции, права пользователей, запуск программ и контроль устройств. Если нарушителю нужна учётная запись, в фокус попадают MFA, парольная политика, отзыв прав, журналирование и контроль подозрительных входов. Если проблема связана с публичным интерфейсом, важны фильтрация запросов, безопасная разработка, ограничение API и защита от перегрузки.
Механически переносить найденные УБИ в итоговую модель нельзя. Проверяющий быстро видит документы, где автор собрал длинный список и поставил отметку «актуально» напротив слишком многих строк. Рабочая модель объясняет выбор. Почему угроза применима? Какой компонент страдает? Какие последствия получит организация? Какие меры уже закрывают риск? Где остаётся слабое место?
Рядом с каждой угрозой полезно писать короткое пояснение человеческим языком. Не просто УБИ про нарушение доступности, а «личный кабинет может стать недоступен из-за перегрузки публичного API». Не просто угроза утечки, а «оператор с лишними правами может выгрузить персональные данные из административной панели». Такие формулировки помогают владельцам процессов понять риск без перевода с регуляторного языка.
Как связать БДУ с моделью угроз, аудитом и исправлениями
Официальная Методика оценки угроз безопасности информации задаёт порядок анализа и структуру модели. В практической работе БДУ лучше использовать как исходный источник, а не как готовую модель. Сначала команда описывает систему, затем определяет негативные последствия, объекты воздействия, источники угроз, условия реализации и актуальность. Не подгоняйте архитектуру под заранее выбранный список.
После отбора актуальных угроз начинается нормальная инженерная работа. Каждая угроза получает ответ: мера защиты, организационная процедура или аргументированное исключение. Для удалённого доступа подойдут MFA, запрет прямого подключения к административным интерфейсам, ограничение сетевых зон и контроль событий. Для баз данных нужны резервные копии, разграничение ролей, шифрование, мониторинг запросов и регулярная проверка восстановления.
БДУ хорошо ложится на аудит. Вместо общего вопроса «всё ли безопасно» команда проходит по выбранным угрозам и проверяет факты. Включены ли журналы? Кто смотрит события? Где лежат резервные копии? Сколько людей имеют права администратора? Как быстро закрываются критичные уязвимости? Кто принимает остаточный риск, если меру нельзя внедрить быстро? Разговор получается менее приятным, зато гораздо полезнее презентации с зелёными диаграммами.
Для управления уязвимостями БДУ стоит связать со сканерами, реестром активов и процессом установки исправлений. Одна и та же CVE на тестовом стенде без данных и на внешнем шлюзе не должна получать одинаковый приоритет. Команда оценивает актив, доступность эксплуатации, возможную угрозу и последствия для бизнеса. После такой оценки исправления попадают в нормальную очередь, а не в бесконечный список «критично, срочно, когда-нибудь».
Работа с БДУ раскрывается в цикле: система изменилась, модель угроз обновили, меры защиты проверили, остаточные риски зафиксировали. Добавили новый API, переехали в облако, подключили подрядчика, сменили СУБД или открыли удалённый доступ для администраторов, значит, список угроз нужно пересмотреть. Документ, который не обновляют после изменений, быстро превращается в архивную фотографию инфраструктуры.
FAQ по БДУ ФСТЭК
Нужно ли включать в модель все угрозы из БДУ?
Нет. В модель попадают только угрозы, которые соответствуют архитектуре, данным, доступам, нарушителям и реальным условиям эксплуатации.
Что делать, если угроза подходит частично?
Опишите применимую часть, зафиксируйте ограничение и укажите, какие меры уже снижают риск.
Можно ли использовать БДУ без требований регулятора?
Да. БДУ полезна как справочник и чек-лист даже для коммерческих систем без отдельного регуляторного режима.
Кто должен работать с БДУ в компании?
Лучший результат даёт связка ИБ, эксплуатации, разработки и владельца системы. Один безопасник редко видит всю инфраструктуру целиком.
БДУ ФСТЭК приносит пользу не количеством вставленных идентификаторов УБИ, а связью с реальной инфраструктурой. Сначала активы и архитектура, затем угрозы, условия реализации, последствия, меры защиты и регулярный пересмотр. Такой порядок превращает базу из формального справочника в рабочий инструмент для ИБ, эксплуатации и аудита.
