Защита без модели угроз превращается в набор разрозненных средств, купленных по совету интегратора. Управление рисками отвечает, что защищать в первую очередь и до какого предела. Только потом имеет смысл разговор про меры.

аналитический центр информационной безопасности, на большом экране абстрактная карта рисков с узлами и связями, специалисты за рабочими станциями

Ниже методология целиком: от модели угроз по методике ФСТЭК до оценки по FAIR и стратегий обработки.

Управление рисками информационной безопасности: философия и место в стратегии СМИБ

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

ISO/IEC 27001:2022 требует определить критерии риска и оценивать его через запланированные интервалы. Оценка связывает контекст организации с составом мер из Приложения А, где перечислены 93 контроля.

Что такое управление рисками информационной безопасности и почему без него невозможна защита

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

Процесс по ISO/IEC 27005:2022 — шесть шагов: контекст и критерии, идентификация, анализ, оценивание, обработка, мониторинг. Сквозные активности — коммуникация и документирование.

цикл управления рисками ИБ по ISO 27005 — контекст, идентификация, анализ, оценивание, обработка, мониторинг с обратными связями между этапами

Риск-ориентированный подход (Risk-Based Approach): отличие от compliance-ориентированного

Риск-ориентированный подход (Risk-Based Approach, RBA) исходит из значимости последствий, compliance-ориентированный — из перечня требований регулятора. Первый отвечает, что навредит сильнее всего, второй — что спросят на проверке.

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

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

> Типовая ошибка. Модель угроз пишется под аттестацию, а система рисков живет отдельно в реестре у риск-менеджеров. Документы не связаны, поэтому актуализация одного не влечет пересмотра другого.

Риски безопасности информационных систем: связь с бизнес-рисками и финансовой устойчивостью

Риски безопасности информационных систем становятся управляемыми после перевода в деньги: прямые потери, недополученная выручка, штрафы, стоимость восстановления. Формулировка «эксплуатация уязвимости в подсистеме» на уровне правления не работает.

Перевод делается через владельцев процессов. Владелец называет допустимое время простоя и цену часа остановки, служба ИБ добавляет вероятность и сценарий.

Подходы к оценке зрелости разбирались в исследовании АФТ, связь ИБ с экономикой — в материале про ИБ организации и финансового сектора.

Модель угроз информационной безопасности: фундамент защиты

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

Базовый документ в России — Методика оценки угроз безопасности информации ФСТЭК 2021 года. Она задает три этапа: негативные последствия, объекты воздействия, возможность реализации.

Модель угроз информационной безопасности: определение, цели и жизненный цикл

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

Жизненный цикл — разработка, утверждение, плановый пересмотр, внеплановая актуализация. Плановый привязывают к году, внеплановый проводят при изменении архитектуры, после инцидента, при обновлении БДУ или по замечаниям проверяющих.

Лицензия ФСТЭК для разработки модели под собственные нужды не требуется. Она нужна при оказании таких услуг другим и при оценке соответствия по ГОСТ Р 57580 в рамках технической защиты информации.

Модель информационной безопасности систем: связь с архитектурой и бизнес-процессами

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

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

связь модели угроз с архитектурой — уровни сеть, платформа, приложение, данные и привязка угроз к компонентам бизнес-процесса

Модели информационной безопасности: типы, эволюция и интеграция с MITRE ATT&CK

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

Современный подход дополняет перечень угроз описанием поведения атакующих: кто действует (threat actor) и какими тактиками, техниками и процедурами (TTPs). Стандарт де-факто — MITRE ATT&CK, где угроза раскладывается на шаги, поддающиеся обнаружению.

Важное изменение 2026 года. ATT&CK v19 вышел 28 апреля 2026 с крупнейшей за годы структурной правкой: тактика Defense Evasion разделена на Stealth и Defense Impairment. Матрица Enterprise содержит 15 тактик, 222 техники и 475 подтехник. Модели угроз с привязкой к прежней структуре расходятся с фреймворком, пока их не пересобрали.

Связка с БДУ строится через сопоставление: угроза раскладывается на техники ATT&CK, техники — на меры и правила мониторинга.

сопоставление угрозы из БДУ ФСТЭК с тактиками и техниками MITRE ATT&CK и переход к мерам защиты

Классификация угроз: систематизация векторов атак

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

Классификация угроз информационной безопасности: по источнику, мотивации, последствию и вероятности

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

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

Тип нарушителя	Мотивация	Типичные векторы	Источники описания
Внешний, низкий потенциал	Финансовая, случайный интерес	Массовый фишинг, известные уязвимости периметра	БДУ, ATT&CK: Initial Access
Внешний, высокий потенциал	Финансовая, шпионаж	Целевые атаки, цепочка поставок, закрепление	ATT&CK: Persistence, Stealth
Внутренний привилегированный	Финансовая, месть	Злоупотребление правами, выгрузка данных	БДУ, ATT&CK: Collection
Пользователь с превышением прав	Удобство, без умысла	Обход регламентов, теневые сервисы	БДУ
Подрядчик с удаленным доступом	Компрометация третьей стороны	Сервисные учетные записи	ATT&CK: Valid Accounts

Виды угроз информационной безопасности: внутренние, внешние, случайные и преднамеренные

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

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

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

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

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

Актуальное состояние банка данных. На 5 августа 2026 года БДУ содержит 227 угроз и более 92 тысяч уязвимостей, раздел уязвимостей пополняется почти ежедневно. За полтора года перечень угроз пополнялся дважды: в июне 2025 добавлены угрозы контейнеризации УБИ.223–227, в декабре 2025 обновлен раздел угроз искусственного интеллекта.

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

Порядок работы с банком данных:

Отобрать применимые угрозы по типу системы и условиям эксплуатации
Исключить неприменимые с письменным обоснованием — его проверяют первым
Сопоставить с объектами воздействия из архитектуры
Сверить перечень со свежей выгрузкой БДУ при пересмотре
Зафиксировать дату выгрузки в документе

карточка угрозы из БДУ ФСТЭК — идентификатор, источник, объект воздействия, нарушаемые свойства, связь с мерами защиты

Модель нарушителя и оценка уязвимостей

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

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

Нарушители классифицируются по положению относительно контролируемой зоны, уровню прав и потенциалу. Методика ФСТЭК выделяет три уровня возможностей: базовый, базовый повышенный и высокий — последний предполагает ресурсы специальных служб.

Практическая ошибка — брать высокий потенциал «на всякий случай»: перечень угроз расширяется, а меры организация не тянет ни по бюджету, ни по эксплуатации. Высокий потенциал обосновывают для значимых объектов КИИ, типовой корпоративной системе хватает базового повышенного.

Легитимный пользователь с превышением прав формально не злоумышленник, но по последствиям сценарий совпадает с действиями инсайдера. В модели он присутствует явно.

модель нарушителя — категории по положению и правам, уровни потенциала, доступные векторы для каждой категории

Связь модели угроз с моделью нарушителя и архитектурой системы

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

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

Источники угроз и оценка уязвимостей как входные данные для риск-анализа

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

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

ISO/IEC 27005:2022 предлагает два подхода. Классический опирается на связку «актив — угроза — уязвимость», событийный отталкивается от сценариев и последствий; второй лучше работает при большом числе активов.

Приоритизация устранения разобрана в статье про уязвимости и утечки, проверка реализуемости сценариев — в услуге тестирования на проникновение.

Оценка рисков информационной безопасности: методологии и фреймворки

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

Оценка рисков информационной безопасности: качественные и количественные методы (FAIR, OCTAVE, ISO 27005, NIST SP 800-30)

Качественные методы оперируют шкалами «низкий, средний, высокий», количественные — деньгами и вероятностями. Формулы: единичные потери SLE равны стоимости актива, умноженной на коэффициент воздействия; годовые потери ALE равны SLE, умноженному на частоту реализации ARO.

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

Методология	Подход	Применимость	Трудозатраты	Требуемая зрелость
ISO/IEC 27005:2022	Смешанный, сценарии риска	База для СМИБ	Средние	Начальная
NIST SP 800-30	Качественный, детальные шкалы	Крупные ИТ-ландшафты	Средние	Средняя
FAIR	Количественный, декомпозиция потерь	Обоснование бюджета	Высокие	Высокая
OCTAVE	Качественный, самооценка	Организации без аналитиков	Низкие	Начальная
ГОСТ Р 57580.3 и 57580.4	Отраслевой, операционные риски	Финансовый сектор	Высокие	Средняя
Методика ФСТЭК 2021	Сценарный, реализуемость угроз	ГИС, ИСПДн, КИИ	Средние	Любая

декомпозиция риска по FAIR — частота событий потерь и величина потерь с разложением на составляющие

Критерии информационной безопасности: как определить приемлемый уровень риска для бизнеса

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

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

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

Построение матрицы рисков и heat map для Совета директоров

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

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

Картинку сопровождают четыре цифры: число рисков в красной зоне, динамика с прошлого периода, стоимость обработки и срок выхода в приемлемую зону. Без них heat map — просто иллюстрация.

матрица рисков пять на пять с зонами принятия, обработки и недопустимых значений, примеры размещения рисков

Обработка рисков: стратегии и выбор мер защиты

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

Четыре стратегии обработки рисков: снижение, принятие, передача, избегание

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

Стратегия	Когда применяется	Пример	Кто утверждает	Документальное оформление
Снижение	Меры дешевле ожидаемого ущерба	Сегментация, контроль привилегий	CISO, комитет по рискам	План обработки
Принятие	Остаточный риск ниже порога	Сбой некритичного сервиса	Владелец процесса	Реестр с обоснованием
Передача	Ущерб велик, вероятность низкая	Страхование, вынос сервиса подрядчику	Финансовый директор	Договор, полис
Избегание	Риск неприемлем, снижение невозможно	Отказ от избыточных данных	Правление	Решение по процессу

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

Выбор компенсирующих мер и расчет ROI от внедрения СЗИ

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

Возврат инвестиций считается через снижение годовых потерь: из ALE до внедрения вычитается ALE после, из результата — стоимость владения за тот же период.

Пример. Потери от компрометации привилегированных учетных записей оценены в 24 млн рублей, контроль доступа снижает частоту втрое — до 8 млн. При стоимости владения 6 млн эффект составляет 10 млн, окупаемость в первый год.

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

Непрерывный мониторинг рисков и актуализация модели угроз

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

Триггеры актуализации:

Изменение архитектуры: новая система, миграция в облако, новый канал обмена
Обновление БДУ ФСТЭК, затрагивающее применяемые технологии
Структурные изменения ATT&CK, как разделение Defense Evasion в v19
Инцидент у себя или публично разобранный в отрасли
Изменение требований или состава обрабатываемых данных
Замечания проверки или внутреннего аудита

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

процесс актуализации модели угроз — триггеры, этапы пересмотра, утверждение, обновление реестра рисков

Регуляторные требования к риск-менеджменту в РФ

Российские требования распределены между ФСТЭК и Банком России: первый требует модель угроз и обоснование состава мер, второй — встроенный процесс управления операционным риском.

Требования ФСТЭК (Приказы №17, 21, 239) к модели угроз и оценке рисков

Требования ФСТЭК к моделированию угроз содержатся в приказах по видам систем и опираются на методику 2021 года. Модель разрабатывают при проектировании и актуализируют при эксплуатации.

Уточнение по нумерации. Приказ № 17 по государственным информационным системам утратил силу: с 1 марта 2026 года действует Приказ № 117. В нем появились требования к проверке знаний персонала не реже раза в три года и внепланово после инцидента.

Приказ № 21 регулирует защиту персональных данных, задает 15 групп мер и базовый набор по уровню защищенности; оценка эффективности — не реже раза в три года. Приказ № 239 распространяется на значимые объекты КИИ, включает группу мер ЗИС и раздел по защите от DDoS.

Проект изменений в приказы № 235 и № 239 вводит регулярный расчет показателей защищенности и зрелости мер: планируется с 1 сентября 2026 года, но на момент подготовки материала не принят. Категорирование закрывает услуга по безопасности объектов КИИ.

Требования ЦБ РФ (ГОСТ Р 57580, Положения 683-П, 719-П) к управлению рисками ИБ

Банк России встраивает риск информационной безопасности в контур операционного. Профильный документ — Положение № 716-П, где киберриск считается его составной частью.

Номера положений изменились. Положение № 683-П заменено № 851-П с 29 марта 2025 года, Положение № 719-П — № 821-П с 1 апреля 2024 года. В документах и заданиях старые номера встречаются до сих пор.

По 851-П установлена поэтапность: до 31 декабря 2026 года — минимальный уровень защиты с уровнем соответствия не ниже третьего, с 2027 года — стандартный с уровнем не ниже четвертого. Оценку проводит сторонняя организация не реже раза в два года.

Методология оценки закреплена в ГОСТ Р 57580.2, операционная надежность — в 57580.3 и 57580.4. Типовые расхождения — в материале про методику оценки и аудит ИБ.

Гармонизация российских требований с ISO/IEC 27001:2022 и NIST CSF

Российские и международные требования во многом пересекаются, два параллельных процесса не нужны. Практический путь — единый реестр рисков с двойной маркировкой: пункт российского документа и контроль Приложения А ISO/IEC 27001:2022.

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

NIST CSF в версии 2.0, опубликованной 26 февраля 2024 года, добавил к пяти функциям шестую — Govern, посвященную ответственности руководства и стратегии управления риском. Сертификации по CSF не существует, поэтому в российской практике он полезен как каркас отчетности: функции Identify и Govern закрывают то, что регулятор проверяет как организационные меры, остальные четыре — технические.

Поправка ISO/IEC 27001:2022/Amd 1:2024 добавила требование оценить релевантность климатического фактора для контекста организации. Новых контролей она не вводит, но при надзорном аудите вопрос задают. Подготовку к сертификации закрывает услуга по ISO 27001.

Экономика и автоматизация риск-менеджмента

Ручное ведение реестра перестает работать примерно на сотне записей. Дальше растет не трудоемкость оценки, а стоимость поддержания актуальности.

GRC-платформы и автоматизация процесса управления рисками ИБ

GRC-платформы связывают активы, угрозы, риски, меры и требования в одну структуру данных. Ценность — прослеживаемость: от пункта нормативного документа до настройки средства защиты и обратно.

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

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

Стоимость построения функции риск-менеджмента: in-house vs аутсорсинг

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

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

Чаще всего встречается гибрид: методология и первичная модель делаются внешней командой, ведение остается внутри. Для оценки соответствия по ГОСТ Р 57580 внешний исполнитель обязателен по требованию стандарта и должен иметь лицензию ФСТЭК.

Чек-лист: 12 шагов для построения актуальной модели угроз и матрицы рисков в организации

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

Определить границы оценки: системы, процессы, площадки, интерфейсы
Собрать архитектурные данные, зафиксировать объекты воздействия
Определить негативные последствия для лиц, организации, государства
Построить модель нарушителя с обоснованием потенциала
Выгрузить перечень угроз из БДУ и зафиксировать дату выгрузки
Отобрать применимые угрозы, обосновать исключение остальных
Сопоставить угрозы с техниками ATT&CK для связи с мониторингом
Оценить уязвимости сканированием и пентестом
Определить критерии риска, утвердить порог принятия у руководства
Оценить риски выбранным методом, построить матрицу
Выбрать стратегию обработки с ответственным и сроком
Задать триггеры актуализации, назначить владельца процесса

двенадцать шагов построения модели угроз и матрицы рисков с распределением по этапам и ответственным

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

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

Чем модель угроз отличается от модели нарушителя и как они связаны между собой?

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

Как часто нужно актуализировать модель угроз по требованиям ФСТЭК и ISO 27001?

Жесткой периодичности в методике ФСТЭК нет: актуализация привязана к изменениям системы и условий эксплуатации. Рабочая практика — пересмотр раз в год плюс внеплановый по триггерам. ISO/IEC 27001:2022 требует оценивать риски через запланированные интервалы и при существенных изменениях.

Обязательно ли использовать количественные методы оценки рисков (FAIR) или достаточно качественных?

Обязательности нет ни в российских, ни в международных требованиях. Качественных методов хватает для приоритизации и выполнения норм. Количественные нужны, когда риск конкурирует за бюджет с другими инвестициями. Компромисс — считать количественно только топ-10 рисков.

Как определить «приемлемый уровень риска» (Risk Appetite) для Совета директоров?

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

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

Для выполнения требований регулятора достаточно, для реальной защиты — нет. Банк данных описывает угрозы обобщенно и не раскрывает поведение атакующих. Полную картину дает связка БДУ с MITRE ATT&CK, отраслевыми отчетами и данными о своих инцидентах.

Как интегрировать модель угроз ИБ с общей системой риск-менеджмента предприятия (ERM)?

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

Какие типовые ошибки допускают компании при построении модели угроз?

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

Нужно ли согласовывать модель угроз с регулятором (ФСТЭК, ЦБ РФ) или достаточно внутреннего утверждения?

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