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

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

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

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

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

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

Что такое модель угроз ИС и почему без нее невозможна адекватная защита

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

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

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

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

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

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

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

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

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

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

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

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

Основные риски информационной безопасности: от внешних APT-группировок до внутренних инсайдеров

Основные риски информационной безопасности распределяются между тремя источниками: целевые группировки, массовое мошенничество и внутренние нарушители. По данным «Лаборатории Касперского», число выявленных инцидентов в первом квартале 2026 года выросло на 68 процентов год к году; «Бастион» оценивает годовой рост числа атак в четверть.

APT-группировки (Advanced Persistent Threat — устойчивая целевая угроза) отличаются от массовых атак не техниками, а временем присутствия: закрепление измеряется месяцами. Сценарий в модели не заканчивается проникновением — он включает боковое перемещение, закрепление и вывод данных.

Внутренние нарушители недооценены: только 24 процента компаний выявляют такие инциденты до появления ущерба.

Типология угроз для различных типов ИС (ГИС, ИСПДн, КИИ, АБС, ERP)

Тип системы определяет нормативный минимум и профиль актуальных угроз: одна техника дает разные последствия в государственной информационной системе и в системе управления производством.

ГИС — приоритет конфиденциальности и целостности, Приказ ФСТЭК № 117, действующий с 1 марта 2026 года взамен № 17
ИСПДн — угрозы утечки, Приказ № 21, тяжесть последствий зависит от числа субъектов и категории данных
Значимые объекты КИИ — приоритет доступности и целостности, Приказ № 239, высокий потенциал нарушителя обосновывается чаще
АБС и системы ДБО — финансово мотивированный нарушитель, требования Банка России и ГОСТ Р 57580, ключевой сценарий — несанкционированный перевод
ERP и производственные системы — угрозы через избыточные права и интеграции, остановка процесса дороже утечки

Категорирование объектов КИИ закрывает услуга по безопасности объектов КИИ, защиту персональных данных — работы по 152-ФЗ.

Анатомия угрозы: факторы и составляющие

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

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

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

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

Семь факторов, которые заметнее всего меняют картину в 2025–2026 годах:

Фактор	В чем проявляется	Что делать в модели
Удаленный доступ	Рабочие места вне зоны, личные устройства	Сценарии компрометации сессии и учетных данных
Облачная миграция	Инфраструктура вне периметра, SaaS-прослойка	Провайдер в перечне источников
ИИ-генерация фишинга	Уникальные письма без типовых признаков	Пересмотр вероятности социальной инженерии
Дипфейки	Подмена голоса и видео в реальном времени	Сценарий обхода голосовой верификации
Устаревшее ПО	Неустранимые уязвимости, нет поддержки	Обоснование компенсирующих мер
Цепочки поставок	Доверенный канал подрядчика, обновления ПО	Отдельный класс сценариев, не пункт перечня
Дефицит кадров	Задержка реакции, неполный разбор событий	Реалистичное время обнаружения

Два фактора требуют цифр. Для клонирования голоса моделям хватает записи в три–пять секунд, источником служат публичные выступления руководителей. По данным Threat Zone 2026, 64 процента целевых атак на компании России и СНГ начинаются с фишингового письма, а отличить сгенерированное письмо от легитимного классические фильтры не могут: грамматика правильная, шаблон уникальный. Рыночный контекст — в нашем прогнозе рынка кибербезопасности на 2026 год.

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

Составляющие угрозы информационной безопасности описывают сценарий целиком: кто действует (threat agent), через какую слабость (vulnerability), каким способом (attack vector), на что направлено и чем заканчивается. Пропуск любого элемента делает угрозу непроверяемой.

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

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

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

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

Три источника таких сценариев:

Новые технологии. Контейнеризация, ИИ-сервисы, интеграции с внешними API. Угрозы контейнеризации появились в БДУ в июне 2025 года (УБИ.223–227), раздел угроз искусственного интеллекта обновлен в декабре 2025
Инциденты у других. Публично разобранная атака в отрасли — готовый сценарий для проверки своей инфраструктуры
Результаты тестирования на проникновение. Показывают реализуемые цепочки, о которых модель не знала

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

Методологии и источники для моделирования

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

Работа с Банком данных угроз (БДУ) ФСТЭК России: структура карточки угрозы и практическое применение

БДУ ФСТЭК — основной источник исходных данных по методике 2021 года. На 5 августа 2026 года банк содержит 227 угроз и более 92 тысяч уязвимостей, раздел уязвимостей пополняется почти ежедневно.

Карточка содержит идентификатор вида УБИ.XXX, описание, источник с указанием потенциала нарушителя, объект воздействия и нарушаемые свойства: конфиденциальность, целостность, доступность.

Порядок работы с БДУ:

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

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

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

Интеграция с фреймворком MITRE ATT&CK: тактики, техники и процедуры (TTPs) злоумышленников

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

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

Связка строится в три шага: угроза из БДУ раскладывается на техники ATT&CK, техники — на индикаторы компрометации (IoC) и правила мониторинга, правила — на источники событий. Разрыв означает, что угроза учтена формально, но не обнаруживается.

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

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

Рисками информационной безопасности являются: переход от абстрактных угроз к измеримым рискам (ALE/SLE/ARO)

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

Международный ориентир здесь — ISO/IEC 27005:2022. Стандарт разделяет два подхода к идентификации риска: классический «актив — угроза — уязвимость» и событийный, отталкивающийся от сценариев и последствий. Первый ближе к методике ФСТЭК, второй удобнее при большом числе однотипных активов.

Базовые формулы количественной оценки:

SLE (Single Loss Expectancy) — ущерб от одного инцидента: стоимость актива, умноженная на коэффициент воздействия
ARO (Annual Rate of Occurrence) — ожидаемая частота реализации за год
ALE (Annual Loss Expectancy) — годовые ожидаемые потери: SLE, умноженное на ARO

Пример. Стоимость актива 12 млн рублей при коэффициенте воздействия 0,5 дает SLE 6 млн. При частоте раз в два года ARO равен 0,5, годовые ожидаемые потери — 3 млн. Мера за 1 млн в год, снижающая частоту вдвое, окупается.

Слабое место расчета — источник частоты: отраслевая статистика и свои инциденты работают, оценки вендора нет.

матрица рисков heat map пять на пять с распределением угроз по вероятности и ущербу, зоны принятия и обработки

Практика: построение перечня актуальных угроз для конкретной ИС

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

Пошаговый алгоритм: от инвентаризации активов до верификации модели угроз

Восемь шагов, порядок важен: пропуск обнаруживается на следующем этапе.

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

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

Типовые ошибки при моделировании: избыточность, упущение инсайдеров, игнорирование supply chain

Пять ошибок повторяются в большинстве проектов и хорошо видны аудитору.

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

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

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

Игнорирование цепочки поставок. Supply chain attack — атака через доверенного поставщика — стала массовым вектором, а в моделях остается пунктом общего перечня. По оценке «Бастиона», каждая четвертая успешная атака 2026 года идет через партнеров и подрядчиков; RED Security называет треть расследованных инцидентов против менее чем десяти процентов годом ранее. По данным SOC «Информзащиты» за январь–май 2026 года, 48 процентов инцидентов через поставщиков связаны с уязвимостями, о которых заказчик еще не знал.

Отсутствие связи с реестром рисков. Модель живет отдельно от реестра, и актуализация одного не влечет пересмотра другого. Управление уязвимостями разобрано в статье про уязвимости и утечки.

атака через цепочку поставок — компрометация подрядчика, доверенный канал, проникновение в инфраструктуру заказчика, точки контроля

Чек-лист: 10 критериев качественной модели угроз для прохождения аудита ФСТЭК

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

Указана дата выгрузки из БДУ и она свежая относительно даты утверждения модели
Исключение неприменимых угроз обосновано письменно, а не молча пропущено
Потенциал нарушителя обоснован, а не выбран по максимуму
Объекты воздействия совпадают с архитектурной схемой системы
Негативные последствия описаны в терминах методики: ущерб лицам, организации, государству
Каждой актуальной угрозе сопоставлены меры защиты из применимого приказа
Компенсирующие меры имеют обоснование эквивалентности
Указан порядок и триггеры актуализации документа
Модель связана с реестром рисков организации
Есть подтверждение верификации: пентест, разбор инцидента или экспертная оценка

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

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

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

Чем потенциальная угроза отличается от актуальной, и как доказать актуальность аудитору ФСТЭК?

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

Обязательно ли включать в модель угроз все записи из БДУ ФСТЭК, или можно делать выборку?

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

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

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

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

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

Как учитывать факторы угроз, связанные с искусственным интеллектом и deepfake-атаками?

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

Что делать, если в организации нет ресурсов на регулярную актуализацию модели угроз?

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

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

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

Нужно ли моделировать угрозы для систем, которые не подключены к интернету (air-gapped)?

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