За последние пару лет я участвовал примерно в десятке разборов «почему наш ИБ работает не так, как обещал вендор». Сценарий почти всегда один: компания приходит с запросом «нам нужен SIEM», «нам нужен WAF», «нам нужен EDR». На вопрос, от кого и от чего защищаемся, звучит «ну, от хакеров». Дальше — тендер, внедрение по мануалу, 40 тысяч событий в сутки и тихое отключение через год, потому что «слишком шумно». Деньги потрачены, уровень защищённости не изменился. Причина одна: команда начала с инструмента, а не с модели угроз.
Ниже — что это такое, из чего состоит, какие методологии действительно применяются и как встроить процесс так, чтобы он не превратился в очередной мёртвый документ.
Что такое модель угроз
Модель угроз (threat model) — это структурированное описание того, что вы защищаете, от кого, каким способом это можно сломать и что вы с этим собираетесь делать. Не артефакт для аудитора, а рабочая схема, по которой принимаются инженерные решения: где ставить аутентификацию, что логировать, какую фичу выпускать без дополнительных контролей, а какую — нет.
Классическая формулировка Адама Шостака сводит всё к четырём вопросам:
- Что мы создаём? — архитектура, данные, границы доверия.
- Что может пойти не так? — сценарии злоупотребления.
- Что мы собираемся с этим делать? — контроли и их приоритет.
- Хорошо ли мы это сделали? — проверка модели и её актуальности.
Чем модель угроз не является
- Это не список всех CVE в вашем стеке — этим занимается сканер уязвимостей и работа с зависимостями.
- Это не 200-страничный том, который достают раз в год перед проверкой. Если документ никто не открывает при проектировании спринта, он бесполезен.
- Это не замена пентесту. Модель отвечает на вопрос «что нас волнует», пентест — «получилось ли у нас это закрыть на практике».
- Это не одноразовое мероприятие. Архитектура меняется каждые две недели, модель должна ехать вместе с ней.
Зачем это бизнесу: три эффекта, за которые платят
1. Приоритизация. Без модели все уязвимости выглядят одинаково важными, и команда кидается закрывать то, что первым попалось в отчёте сканера. С моделью вы знаете, что публичный API с платежами и внутренний сервис отчётов имеют разную цену ошибки, — и чините по порядку.
2. Сдвиг влево. Найти проблему на этапе RFC (Request for Comments, документ с описанием архитектурного решения) стоит час обсуждения. Переделать аутентификацию в проде после инцидента — недели работы и репутационные потери. Разница в стоимости исправления обычно измеряется порядками.
3. Аргумент в разговоре о бюджете. «Купите WAF» — это разговор про цену. «У нас три сценария с высоким риском на публичном контуре, WAF закрывает два из них, вот что остаётся» — это разговор про риск. Второй вариант гораздо чаще заканчивается согласованием.
Из чего состоит модель: пять блоков
- Активы. Данные, сервисы, деньги, репутация, доступы. Начните с того, утечка или простой чего действительно больно бьёт по бизнесу, а не с «у нас есть серверы».
- Архитектура и границы доверия. Потоки данных, точки входа, места, где трафик переходит из недоверенной зоны в доверенную (интернет → DMZ → внутренняя сеть → база). Именно на границах происходит большинство интересного.
- Нарушители. Внешний атакующий без доступа, внешний с доступом к чужой учётной записи, инсайдер, подрядчик, автоматический сканер, шифровальщик. Для каждого — свои мотивация, возможности и цена входа.
- Сценарии. «Что может пойти не так» в формате «нарушитель + способ + последствие». Формулируйте на уровне механики, а не пошаговой инструкции.
- Контроли и остаточный риск. На каждый значимый сценарий — либо мера защиты или обнаружения, либо осознанно принятый риск с подписью владельца. Третьего не дано.
Мини-пример для интернет-магазина
- Актив: база заказов с персональными данными покупателей.
- Граница доверия: публичный API корзины → внутренний сервис заказов.
- Сценарий: нарушитель перебирает чужие идентификаторы заказов и получает доступ к данным других покупателей (broken object level authorization).
- Контроли: проверка владельца объекта на уровне сервиса, а не клиента; лимиты на перебор; логирование аномальных обращений одного пользователя к разным объектам; алерт в SIEM.
- Остаточный риск: низкий, принят владельцем продукта.
Такой блок на одну страницу полезнее, чем сто страниц общих слов про «комплексную систему информационной безопасности».
Методологии: что реально работает
Методологий много, но в ежедневной работе приживаются три-четыре. Не пытайтесь внедрить всё сразу.
STRIDE
Самая практичная отправная точка для разработки. Шесть категорий угроз: подмена идентичности (Spoofing), изменение данных (Tampering), отказ от авторства (Repudiation), раскрытие информации (Information disclosure), отказ в обслуживании (Denial of service), повышение привилегий (Elevation of privilege). Проходите по каждому элементу диаграммы потоков данных и спрашиваете: «может ли здесь случиться S, T, R, I, D, E?» Работает быстро, не требует экзамена по ИБ и хорошо ложится на ревью архитектуры.
PASTA и LINDDUN
PASTA (Process for Attack Simulation and Threat Analysis) — семишаговый процесс, который стартует от бизнес-целей и заканчивается симуляцией атак. Хорош для критичных систем, где цена ошибки высока, но требует заметно больше времени и участия бизнеса. LINDDUN — специализация под приватность: полезно, если вы обрабатываете персональные данные по 152-ФЗ и вам нужно обосновать минимизацию и защиту данных, а не только «закрыть периметр».
БДУ ФСТЭК и российская специфика
Для компаний, работающих под требованиями регулятора, отправной точкой часто становится Банк данных угроз безопасности информации ФСТЭК России (БДУ) и методический документ «Методология оценки угроз безопасности информации» 2021 года. Практический смысл: если вы попадаете под 152-ФЗ или отраслевые требования, модель угроз — это не «хорошая практика», а документ, который у вас спросят. Хорошая новость в том, что его можно сделать рабочим инструментом, а не формальностью: структура «объект воздействия → источник угрозы → способ реализации → последствия» вполне годится как основа для инженерной работы. Плохая — в том, что переписывать модель под каждое изменение архитектуры мало кто выдерживает, поэтому на практике её обновляют перед проверками, а инженерные решения принимают по более лёгкой рабочей версии.
MITRE ATT&CK
ATT&CK — это не совсем методология моделирования, а база техник атакующих. Её удобно применять на выходе: когда модель угроз уже описывает, что для вас критично, посмотрите, какие техники из ATT&CK соответствуют вашим сценариям, и проверьте, есть ли у вас детект хотя бы на часть из них.
Рабочая связка, к которой я прихожу чаще всего: STRIDE для дизайна → ATT&CK для детекта → БДУ ФСТЭК для документа, который устроит регулятора.
Как построить модель угроз за один день
- Соберите правильных людей на 90 минут. Архитектор, тимлид сервиса, DevSecOps или ИБ, владелец продукта. Без владельца продукта вы не сможете принимать риски, только жаловаться на них.
- Нарисуйте диаграмму потоков данных. Пять-десять прямоугольников и стрелок достаточно. Цель — не документация, а общее понимание.
- Отметьте границы доверия. Где заканчивается зона, которой вы управляете, и начинается что-то чужое: интернет, внешняя интеграция, ноутбук сотрудника, контейнер без сетевых политик.
- Выпишите активы, которые реально важны. Данные, доступы, деньги, возможность остановить сервис.
- Пройдите по элементам с чек-листом STRIDE. Пятнадцать минут на компонент, не больше. Всё, что «может быть», записывайте; всё, что «точно нет», тоже — с обоснованием.
- Отранжируйте сценарии. Простая матрица «вероятность × ущерб» на три уровня работает лучше любой экселевской модели с восемью параметрами.
- Назначьте меры и владельцев. Каждая мера — это задача или тикет, а не строчка «рекомендуется усилить». Каждый принятый риск — с фамилией того, кто его принял.
- Поставьте дату пересмотра. Триггеры: новый внешний интерфейс, новая интеграция, смена модели доступа, крупный инцидент в вашей отрасли.
Как встроить это в разработку, а не в ежегодный отчёт
- Практика «threat modeling as code». Инструменты вроде OWASP Threat Dragon или pytm позволяют держать модель в репозитории рядом с кодом и обновлять её в том же pull request, что и архитектуру.
- Чек-лист в шаблоне RFC. Пять вопросов про границы доверия, аутентификацию, данные, логирование и отказоустойчивость, на которые автор обязан ответить до обсуждения.
- Угрозы как часть Definition of Done. Не «мы подумали о безопасности», а «сценарий X закрыт контролем Y, подтверждено тестом».
- Обновление по триггерам. Модель — живой артефакт. Если её не трогали полгода, а релизы шли каждую неделю, она уже врёт.
- Связка с детектом. У каждого сценария с высоким риском должен быть хоть какой-то признак в логах, по которому его можно заметить. Иначе вы обнаружите атаку на этапе звонка из банка.
Частые ошибки
- Начать с продукта. «Купим X, он и будет нашей моделью угроз» — так не работает. Инструмент не заменяет решение о том, что для вас важно.
- Сделать документ вместо процесса. Модель, которую нельзя применить на ревью дизайна, — это отчёт, а не защита.
- Моделировать всё. Если у вас 40 сервисов, не начинайте с 40. Возьмите три самых критичных по деньгам и данным.
- Забыть про инсайдера и подрядчика. Большинство моделей уходят в защиту от внешнего атакующего, хотя доступ подрядчика к инфраструктуре — часто куда более короткий путь.
- Не назначить владельца риска. Риск без владельца не «принят», он просто забыт до инцидента.
- Игнорировать остаточный риск. Идеально закрытых систем не бывает; важно честно ответить, что осталось и почему это приемлемо.
Чек-лист: с чего начать на этой неделе
- Выберите одну систему — ту, где деньги, персональные данные или публичный доступ.
- Соберите диаграмму потоков данных на один лист и отметьте границы доверия.
- Выпишите пять-семь активов, простой или утечка которых действительно больно бьёт.
- Пройдите по компонентам с вопросами STRIDE и запишите все сценарии, включая спорные.
- Отранжируйте по вероятности и ущербу, оставьте верхние пять-семь.
- На каждый сценарий — мера защиты или обнаружения, срок и ответственный.
- Для каждого принятого риска — фамилия владельца и дата пересмотра.
- Проверьте, что для двух верхних сценариев есть сигнал в логах и алерт.
- Добавьте пять вопросов о безопасности в шаблон RFC, чтобы процесс не умер после первого раза.
Модель угроз не сделает вашу систему неуязвимой и не заменит ни сканер, ни пентест, ни дежурного в SOC. Она делает другое — превращает «мы что-то купили и что-то настроили» в понятный список того, от чего вы защищаетесь, что уже закрыто и что вы осознанно не закрываете. Это редкий случай, когда полтора часа у белой доски экономят месяцы работы и стоимость одного инцидента.
