Заходишь в компанию, спрашиваешь: «почему у вас стоит вот этот WAF и вот этот EDR?» — а в ответ: «ну, у конкурентов тоже стоит» или «вендор на конференции рассказывал». Знакомо? Именно так и рождается ИБ-бюджет, который растёт, а уверенности не прибавляет. Причина одна: нет ответа на базовый вопрос — от кого и от чего мы, собственно, защищаемся.
Модель угроз — это не документ для галочки и не 40 страниц текста, который никто не читает. Это рабочий инструмент, который превращает хаос из «поставим всё, что продаётся» в приоритизированный план защиты. Ниже разберём, что это такое, как её построить и, главное, как она определяет конкретные технические решения.
Что такое модель угроз простыми словами
Модель угроз (threat model) — структурированное описание того, какие активы есть в вашей системе, кто и каким образом может им навредить, и какие меры защиты соразмерны этим рискам. Ключевое слово здесь — соразмерны.
Классическая формулировка от Адама Шостака сводит всю работу к четырём вопросам:
- Что мы создаём? — архитектура, данные, бизнес-процессы.
- Что может пойти не так? — перечень угроз и правдоподобных сценариев атак.
- Что мы собираемся с этим делать? — меры защиты или осознанное принятие риска.
- Достаточно ли хорошо мы это сделали? — валидация модели и повторный пересмотр.
Важно понимать: модель угроз — это не список уязвимостей. Уязвимость живёт в коде или конфиге, а угроза — это намерение и возможность реализовать атаку. Их легко перепутать: закрыли 200 находок из сканера — а бизнес-логику обошли через API и выкачали данные. Модель угроз смотрит на систему целиком, а не на отдельные строчки в отчёте.
Почему без модели угроз бюджет уходит не туда
Типичная история. Компания покупает один и тот же «джентльменский набор»: антивирус, межсетевой экран, резервное копирование. А реальный инцидент прилетает со стороны, о которой никто не подумал — например, через токен в публичном репозитории или через подрядчика с доступом во внутреннюю сеть.
Модель угроз закрывает три слепые зоны:
- Кто нарушитель. Внешний атакующий — это лишь один из акторов. Есть ещё инсайдер, недовольный сотрудник, случайный подрядчик, конкурент, автоматизированный бот и даже скомпрометированный сервис-партнёр.
- Что именно защищаем. Пока активы не инвентаризированы, любой из них кажется одинаково ценным — и деньги размазываются тонким слоем.
- Где границы доверия. Именно на стыках — между фронтендом и API, между API и базой данных, между компанией и облаком — происходит большинство реальных атак.
Как построить модель угроз пошагово
- Инвентаризация активов. Выпишите, что реально важно: персональные данные, платёжная информация, исходный код, промышленные системы, доступность сервисов. Для каждого актива — владелец и примерная ценность.
- Описание архитектуры и границ доверия. Нарисуйте диаграмму потоков данных (DFD): компоненты, хранилища, каналы связи. Отметьте trust boundaries — точки, где меняется уровень доверия.
- Формулировка угроз. Для каждой границы пройдитесь по типовым категориям (ниже — про STRIDE) и запишите правдоподобные сценарии, а не истории про квантовых хакеров.
- Оценка рисков. Для каждой угрозы оцените вероятность реализации и потенциальный ущерб. Даже грубая шкала «низко/средне/высоко» уже позволяет расставить приоритеты.
- Выбор мер реагирования. По каждой угрозе решите: снижаем (mitigate), передаём (transfer — например, страховка или аутсорс), избегаем (меняем архитектуру) или осознанно принимаем (accept). Последний вариант — тоже валидное решение, если он зафиксирован письменно.
- Валидация и обновление. Модель устаревает в момент любого релиза. Привяжите пересмотр к изменениям архитектуры, а не к календарю.
Методологии: STRIDE, PASTA, ATT&CK
Изобретать таксономию угроз с нуля не нужно — есть проверенные фреймворки.
STRIDE от Microsoft — самый популярный стартовый вариант, шесть категорий:
- Spoofing — подмена идентичности.
- Tampering — изменение данных.
- Repudiation — отрицание авторства действия.
- Information disclosure — раскрытие информации.
- Denial of service — отказ в обслуживании.
- Elevation of privilege — повышение привилегий.
STRIDE хороша тем, что привязывается к элементам DFD: для потоков данных актуальна подмена, для хранилищ — изменение и раскрытие. Быстро и без магии.
PASTA (Process for Attack Simulation and Threat Analysis) — более тяжёлая, зато бизнес-ориентированная методология из семи этапов: от целей бизнеса до симуляции атак. Подходит крупным компаниям, где ИБ нужно согласовывать с бизнесом на языке рисков и денег.
MITRE ATT&CK — база знаний о тактиках и техниках реальных атакующих групп. Её удобно использовать как справочник: после формулировки угроз вы проверяете, какие техники из attack.mitre.org применимы к вашим сегментам, и накрываете их правилами детектирования в SIEM.
Для проектов с персональными данными есть отдельная ветка — LINDDUN, которая фокусируется на приватности: линковка, идентификация, обнаружение, неосведомлённость и так далее.
Российская специфика: ФСТЭК, 152-ФЗ и КИИ
В России модель угроз — не только внутренняя практика, но и нормативное требование. ФСТЭК России выпустил «Методику оценки угроз безопасности информации» (утверждена 5 февраля 2021 года), которая прямо описывает порядок работы: определение объектов воздействия, источников угроз, способов реализации и оценку последствий.
Для операторов персональных данных модель угроз связана с приказом ФСТЭК №21 и уровнями защищённости по 152-ФЗ, для субъектов КИИ — с 187-ФЗ и требованиями по категорированию. Отсюда простой вывод: если вы проходите аудит или аттестацию, модель угроз у вас спросят не как «хорошую практику», а как обязательный артефакт. И лучше её написать под свою систему, а не скачать шаблон.
Частые ошибки при построении модели угроз
- Модель ради галочки. Документ лежит в папке «для регулятора» и ни разу не использовался при проектировании.
- Только технический угол. Нет бизнес-последствий — нет приоритизации. Все угрозы получаются «критичными».
- Один раз и навсегда. Архитектура менялась пять раз, а модель осталась в версии позапрошлого года.
- Слепое копирование STRIDE. Категории есть, привязки к своей системе нет. Получается красивый, но бесполезный список.
- Игнорирование инсайдера. Внутренний нарушитель часто опаснее внешнего, потому что у него уже есть легитимный доступ.
Как модель угроз определяет защиту — конкретно
Здесь и кроется ответ на вопрос из заголовка. Модель угроз — это не самоцель, а фильтр, через который проходят все решения по безопасности.
- Приоритизация инвестиций. Вы видите, что защита от массового фишинга даёт больше, чем покупка ещё одного «умного» сканера, — и деньги идут туда, где реальный риск.
- Выбор конкретных мер. Если в модели есть угроза компрометации секретов в CI/CD, логичное решение — секрет-менеджер и контроль зависимостей, а не WAF перед веб-приложением.
- Аргументация перед бизнесом и аудитом. Вы говорите не «надо купить», а «вот сценарий, вот вероятность, вот ущерб, вот чем закрываем».
- Быстрая реакция на инцидент. Когда модель есть, вы заранее знаете уязвимые каналы и понимаете, что смотреть в логах в первую очередь.
Проще говоря, модель угроз превращает безопасность из набора купленных коробок в управляемый процесс.
Чек-лист: с чего начать на этой неделе
- Соберите список активов и их владельцев — хотя бы в таблице.
- Нарисуйте упрощённую схему системы и отметьте границы доверия.
- Пройдитесь по STRIDE по каждой границе и выпишите правдоподобные угрозы.
- Оцените их по шкале «вероятность × ущерб» и отсортируйте.
- Для топ-5 угроз определите меру: снижаем, передаём, избегаем или принимаем.
- Зафиксируйте триггеры пересмотра: новые интеграции, смена облака, выход в прод.
И главное — не гонитесь за красивым документом на 50 страниц. Работающая модель угроз на одном листе A4, которую команда реально использует, полезнее глянцевого тома, пылящегося на полке. ИБ — это не про количество купленных средств, а про понимание того, от чего именно вы защищаетесь.
