Модель угроз — это не документ «для галочки»
Большинство компаний вспоминают о модели угроз в двух случаях: когда проверяющий требует соответствующую бумагу или когда систему уже взломали. Шаблон скачивают, название подставляют, угрозы переписывают из методички, подписывают — и убирают в сейф до следующего аудита. Проблема в том, что такой документ не защищает ни от чего. Он описывает абстрактные угрозы вообще, а не вашу конкретную систему с её конкретными слабостями.
Ниже — о том, как построить модель угроз, которая реально работает, и зачем её вообще городить, если у вас нет прямого требования регулятора.
Что такое модель угроз и чем она не является
Модель угроз — это структурированное описание того, что вы защищаете, кто и зачем может атаковать и по каким путям это будет делать. По сути, это ответ на три вопроса: что ценно, кто враг и как он пойдёт.
Важно не путать модель угроз с двумя соседними сущностями:
- Список уязвимостей — это результат сканирования, он отвечает на вопрос «где дырка». Модель угроз — про то, куда злоумышленник вообще захочет добраться и почему.
- Перечень мер защиты — это то, что вы уже поставили. Модель угроз строится до выбора мер и определяет, какие из них вообще имеют смысл.
Хорошая модель умещается в пару страниц и одну диаграмму, а не в трёхсотстраничный талмуд на языке канцелярита.
Зачем это нужно: три причины
1. Требование регулятора
Если система относится к ГИС, обрабатывает персональные данные или является значимым объектом КИИ, модель угроз — обязательный элемент. Методический документ ФСТЭК «Методика оценки угроз безопасности информации» (утверждён 5 февраля 2021 года) прямо требует описывать угрозы в привязке к конкретной системе, а не общими словами. Это касается приказов №17, №21 и №31. Поймите правильно: регулятор требует не бумагу, а результат анализа.
2. Экономика защиты
Бюджет на ИБ конечен. Вы не можете поставить WAF, EDR, SIEM, PAM и DLP абсолютно на всё. Модель угроз показывает, где сосредоточено самое ценное и какие пути атаки наиболее вероятны — значит, туда и идут деньги и время команды. Всё остальное — во вторую очередь.
3. Общий язык с бизнесом
Когда безопасник говорит «нам нужен новый инструмент», это ни о чём. Когда он показывает: вот актив, вот нарушитель, вот сценарий, вот риск в деньгах и простое — разговор меняется. Модель угроз превращает хотелки в аргумент.
Методологии и фреймворки
Изобретать свою нотацию не нужно — есть готовые, проверенные решения.
STRIDE
Классика от Microsoft: шесть категорий угроз — Spoofing (подмена), Tampering (изменение данных), Repudiation (отказ от авторства), Information disclosure (утечка), Denial of service (отказ в обслуживании), Elevation of privilege (повышение привилегий). Удобно тем, что каждая категория — подсказка, о чём спросить систему. Для большинства внутренних систем этого хватает с головой.
Дерево атак
Идёт от цели злоумышленника вниз, к способам её достичь. Хорошо работает для приоритизации: вы сразу видите, где нарушитель пойдёт самым дешёвым путём.
MITRE ATT&CK
Каталог реальных техник атак, наблюдаемых в дикой природе. Полезен на этапе проверки, когда непонятно, покрывают ли средства защиты типовые техники, и как основа для построения детектирования.
DREAD и оценка риска
DREAD (вред, воспроизводимость, доступность, обнаруживаемость, воздействие) — попытка оценить риск численно. Сегодня её ругают за субъективность, но как простой способ расставить приоритеты она живёт. На практике чаще берут связку «вероятность × ущерб» и не мудрят.
Как построить модель угроз: пошагово
- Определите границы и активы. Что именно входит в систему, а что снаружи. Какие данные и функции критичны: база ПДн, платёжка, административная панель, интеграции. Не забудьте про то, что «снаружи» тоже может влиять на систему.
- Нарисуйте архитектуру и потоки данных. Схема с компонентами и стрелками, где ходят данные и где проходят границы доверия. Это одно из самых полезных упражнений: на диаграмме сразу видны связки, о которых забыли.
- Сформулируйте предположения. Что считаем защищённым по умолчанию. Их проверка часто вскрывает неприятное.
- Определите нарушителей. Внешний атакующий, недовольный сотрудник, подрядчик, автоматизированные атаки. У каждого свой набор возможностей.
- Выявите угрозы. Пройдитесь по схеме с STRIDE или деревом атак. Фиксируйте не «уязвим к инъекции», а «через форму авторизации можно получить доступ к данным конкретного пользователя». Конкретно и по делу.
- Оцените и приоритезируйте. Вероятность × потенциальный ущерб. Отсеките то, что вам не грозит по вашей же модели нарушителя.
- Подберите меры и владельцев. На каждую значимую угрозу — мера, ответственный и срок. Без этого пункта модель превращается в эссе.
- Поддерживайте актуальность. Внедрили новый сервис, вывели старый, поменяли архитектуру — модель обновляется. Раз в год — ревизия.
Кто и когда этим занимается
Идеально — когда модель строится на этапе проектирования: дешевле заложить защиту, чем переделывать. Но и для уже работающей системы это полезно, хотя бы разово. Собирайте рабочую группу: архитектор, разработчик, DevOps, безопасник. Один человек модель не построит — он просто не знает всех деталей системы.
Регулярность: для систем в стадии активной разработки — в каждой крупной итерации по изменениям архитектуры, для стабильных — раз в год-два или при значимых изменениях.
Типичные ошибки
- Копировать формулировки из методички, не привязывая их к своей системе.
- Моделировать угрозы, которых в вашем контексте не бывает, и игнорировать те, что реальны.
- Строить документ ради регулятора, а не ради понимания.
- Забыть про цепочки поставок, подрядчиков и облака — немалая часть реальных атак приходит оттуда.
- Один раз написать и забыть.
- Уйти в двести страниц теории вместо двух страниц конкретики.
Инструменты
Никакой инструмент не построит модель за вас, но упростить рисование и ведение помогает. Бесплатные: OWASP Threat Dragon, Microsoft Threat Modeling Tool. Есть открытые решения вроде pytm, где модель описывается кодом и хранится в репозитории рядом с архитектурой. Платные платформы (IriusRisk и аналоги) автоматизируют приоритизацию и связку с мерами, но их ценность прямо пропорциональна зрелости процессов. Начните с диаграммы и таблицы, а не с покупки ПО.
Чек-лист: минимальная рабочая модель угроз
- Есть список активов с указанием критичности.
- Есть схема архитектуры с границами доверия.
- Определены типы нарушителей и их возможности.
- Угрозы сформулированы применительно к вашим компонентам.
- У каждой значимой угрозы — оценка риска и приоритет.
- На каждую угрозу назначена мера, владелец и срок.
- Определён регламент пересмотра модели.
- Документ понятен человеку, который не участвовал в его создании.
Вывод
Модель угроз — это не ритуал для проверяющего и не артефакт ради артефакта. Это инструмент, который не даёт тратить силы на защиту от того, чего не будет, и оставлять без внимания то, что действительно опасно. Двух страниц и одной понятной диаграммы обычно достаточно, чтобы принимать решения по безопасности осознанно, а не по интуиции. Начните с малого: опишите активы, нарисуйте схему, задайте системе неудобные вопросы. Остальное — техника.
