Модель угроз давно стала обязательной частью документации для информационных систем. Особенно там, где обрабатываются персональные данные или есть требования регулятора.
На практике все не так очевидно. Что именно должно быть в модели? Нужно ли переписывать всю БДУ (Базу данных угроз информационной безопасности от ФСТЭК)? Как понять, какие угрозы действительно актуальны? И главное — как связать их с реальными мерами защиты, а не просто оформить документ «для галочки»?
Попробуем разобраться, что такое модель угроз на самом деле и как писать ее, чтобы она была одновременно:
- инженерно обоснованной,
- пригодной для практики,
- соответствующей требованиям ФСТЭК России (в соответствии с Методикой определения актуальных угроз безопасности информации от 5 февраля 2021 г. и последующими обновлениями, такими как Приказ ФСТЭК России № 117 от 11 апреля 2025 г.).
Что такое модель угроз
Простыми словами, модель угроз — это ответ на три вопроса:
- Что мы защищаем?
- От кого?
- Каким способом это могут атаковать?
В российском нормативном контексте модель угроз — это описание:
- объекта защиты,
- возможных нарушителей,
- условий реализации угроз (уязвимостей и способов реализации),
- самих угроз,
- последствий,
- обоснования применяемых мер защиты.
Важно: модель угроз — это не список угроз из БДУ и не копирование справочника. Это анализ конкретной системы с учетом ее архитектуры и условий эксплуатации.
Из чего состоит модель угроз
Корректная модель включает следующую логическую цепочку:
Актив → Нарушитель → Условия реализации → Угроза → Последствия → Меры защиты
- Активы (объекты защиты). Это описание границ системы, включая сервисы, данные, инфраструктуру, зоны доверия и критичные процессы. То есть это основа для анализа — обозначение того, что именно защищается.
- Нарушители (источники угроз). Классификация по категориям (внешние, внутренние, привилегированные) с оценкой их возможностей, мотивов и ресурсов.
- Условия реализации (сценарии и векторы атак). Описание уязвимостей, тактик и техник, позволяющих реализовать угрозу. Адаптируется из БДУ с учетом специфики системы.
- Угрозы. Перечень актуальных угроз, персонализированный под архитектуру, со ссылками на объекты, нарушителей и условия.
- Последствия. Оценка воздействия на конфиденциальность, целостность и доступность информации, включая потенциальные негативные эффекты.
- Меры защиты. Обоснованный выбор контрмер, напрямую связанных с угрозами, для их нейтрализации или минимизации.
Если в документе отсутствует хотя бы одно звено — он скорее формальный, чем рабочий. Разберем на практике.
Практический пример: модель угроз для ИСПДн
Допустим, есть SaaS-сервис кадрового учета, который:
- работает через веб-интерфейс и API;
- хранит персональные данные сотрудников клиентов;
- размещен в российском облаке;
- использует PostgreSQL;
- формирует резервные копии.
Это информационная система персональных данных (ИСПДн). Следовательно, нужно разработать модель угроз в рамках требований регулятора (Приказ ФСТЭК № 21).
Пойдем по шагам:
1. Описание объекта защиты
Первый шаг — четко описать систему.
Назначение:
Система автоматизирует кадровый учет и обработку персональных данных работников.
Обрабатываемые данные:
- ФИО;
- паспортные данные;
- СНИЛС;
- сведения о трудовой деятельности;
- сведения о заработной плате.
Архитектура:
- интернет;
- WAF;
- веб-сервер;
- backend;
- база данных.
Дополнительно:
- резервные копии в объектном хранилище;
- интеграция с системами заказчика через API.
Ключевой момент: угрозы анализируются в рамках описанной архитектуры, а не абстрактно.
2. Определение нарушителей
Подход, применяемый в практике по требованиям ФСТЭК России, строится вокруг возможностей нарушителя.
Выделим три типа.
Внешний нарушитель:
- действует через интернет;
- не имеет легитимного доступа;
- использует автоматизированные средства атак.
Внутренний нарушитель:
- сотрудник компании;
- имеет учетную запись;
- может злоупотреблять полномочиями.
Привилегированный нарушитель:
- системный администратор;
- DevOps-инженер;
- сотрудник с расширенными правами.
Определение нарушителя критично — от его возможностей зависит актуальность угроз.
3. Определение точек воздействия
Анализируем, где возможна реализация угроз:
- веб-интерфейс;
- API;
- админка;
- база данных;
- система резервного копирования;
- облачная инфраструктура.
Особое внимание — доверительным границам:
- интернет — периметр;
- приложение — БД;
- инфраструктура — администратор.
Именно на границах чаще всего реализуются атаки.
4. Формирование перечня актуальных угроз
Теперь переходим к сути.
Важно: мы не копируем полностью БДУ, а выбираем только угрозы, релевантные архитектуре.
Примеры актуальных угроз:
Угроза 1. Несанкционированный доступ через веб-интерфейс
Источник: внешний нарушитель.
Условие: наличие уязвимости (SQLi, IDOR, XSS).
Последствие: утечка ПДн.
Угроза 2. Повышение привилегий пользователя
Источник: внутренний нарушитель.
Условие: ошибки разграничения доступа.
Последствие: доступ к данным других клиентов.
Угроза 3. Компрометация учетной записи администратора
Источник: внешний нарушитель.
Условие: отсутствие MFA, фишинг.
Последствие: полный контроль над системой.
Угроза 4. Несанкционированный доступ к резервным копиям
Источник: привилегированный нарушитель.
Условие: избыточные права доступа.
Последствие: массовая утечка ПДн.
Угроза 5. Нарушение доступности сервиса
Источник: внешний нарушитель.
Условие: отсутствие защиты от перегрузки.
Последствие: отказ в обслуживании, простой сервиса.
5. Оценка актуальности угроз
В рамках требований регулятора необходимо обосновать, являются ли угрозы актуальными.
Оцениваются:
- возможности нарушителя;
- наличие условий реализации;
- архитектурные особенности;
- последствия.
Пример:
Если сервер размещен в защищенном центре обработки данных (ЦОД) и отсутствует физический доступ посторонних лиц, то эту угрозу можно признать неактуальной.
6. Связь угроз с мерами защиты
Модель угроз должна объяснять, почему применяются те или иные меры.
Пример:
Если меры защиты не закрывают угрозы, то модель угроз становится пустышкой: формально она есть, но на безопасность не влияет.
Частые ошибки при разработке модели угроз
1. Копирование БДУ целиком (без анализа архитектуры).
2. Признание всех угроз актуальными (без обоснования).
3. Игнорирование внутренних нарушителей (фокус только на «хакерах из интернета»).
4. Отсутствие связи с мерами защиты (угрозы перечислены, но не влияют на выбор средств защиты).
5. Отсутствие актуализации (модель написана один раз и больше не пересматривается).
Когда модель нужно пересматривать
Модель угроз — это не статичный документ.
Пересмотр требуется при:
- изменении архитектуры;
- миграции в облако;
- подключении новых интеграций;
- существенном расширении функциональности;
- инцидентах безопасности.
Если система изменилась — модель должна измениться.
Модель угроз: коротко о главном
Правильно разработанная модель угроз:
- описывает конкретную систему;
- учитывает реальные возможности нарушителя;
- обосновывает актуальность угроз;
- логически приводит к выбору мер защиты.
Если убрать формальности, модель угроз — это способ структурировать безопасность системы. И главный критерий качества здесь простой: если модель не помогает принимать инженерные решения, то она написана неправильно. В этом и состоит разница между документом «для галочки» и рабочим инструментом безопасности.
