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

Что такое моделирование угроз — и чем оно не является

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

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

Четыре вопроса

Дисциплина сворачивается до четырёх вопросов, популяризированных Адамом Шостаком и принятых почти дословно Манифестом моделирования угроз. Они обманчиво просты, и их порядок имеет значение.

1. Что мы строим? Нельзя угрожать системе, которую не видишь. Здесь вы рисуете её — обычно как диаграмму потоков данных (DFD): процессы, хранилища данных, внешние сущности, потоки между ними и границы доверия (trust boundaries), которые они пересекают. Граница доверия — это любое место, где данные или управление переходят между зонами с разным уровнем доверия: браузер → сервер, ваш сервис → сторонний API, один микросервис → другой. Угрозы скапливаются на границах, поэтому хорошо их назвать — это бо́льшая часть работы.
2. Что может пойти не так? Теперь вы рассуждаете состязательно, граница за границей. Здесь оправдывают себя структурированные подсказки — STRIDE (Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege) даёт шесть линз, через которые проводят каждый элемент, чтобы воображать не только те атаки, которых вы уже боитесь. Продукт этого шага — набор сценариев злоупотребления (abuse cases): зеркальное отражение пользовательских историй. «Как пользователь, я могу поделиться документом» сопрягается с «как атакующий, я могу повысить ссылку-просмотр до ссылки-редактирования».
3. Что мы будем с этим делать? Каждой правдоподобной угрозе назначается распоряжение: митигировать (добавить контроль), устранить (убрать фичу или границу), передать (переложить риск на провайдера с более сильными гарантиями) или принять (сознательно, с записанным допущением). «Принять» — законный ответ, но только когда он записан, чтобы это было решением, а не случайностью.
4. Достаточно ли хорошо мы сработали? Вы сверяете модель с проектом в том виде, как он построен, подтверждаете, что митигации приземлились, и решаете, терпим ли остаточный риск. Важнее всего — цикл замыкается обратно к первому вопросу: выбранные митигации меняют проект, что может внести новые границы и новые угрозы.

Где это живёт в SDLC и кто в комнате

Вся ценность держится на том, когда это происходит: на этапе проектирования, до кода. Именно это люди называют shift-left — смещением анализа безопасности влево по таймлайну, к требованиям и проектированию, прочь от правого края, где проблемы находят уже в проде. Вы моделируете угрозы, пока фича — это диаграмма и документ, потому что это момент, когда «не стоит строить это так» — дешёвая фраза, а не переархитектура. На практике это значит — на ревью дизайна новой фичи, при изменении архитектуры или когда сдвигается граница доверия (новая сторонняя интеграция, новая модель арендаторов, выставление внутреннего сервиса наружу).

Кто в комнате — важнее, чем какую методологию вы выберете. Инженеры, которые будут это строить, должны присутствовать — они знают реальные потоки данных, а не идеализированные. Грамотный в безопасности фасилитатор поддерживает поток состязательных вопросов. Владельцы продукта или предметной области определяют, что вообще значит «злоупотребление» (в платежах — двойное списание; в здравоохранении — несанкционированный доступ к записи). Манифест здесь прям: он ценит людей и взаимодействие выше процессов, методологий и инструментов. Сессия у доски с правильными четырьмя людьми бьёт сложный инструмент, которым один человек пользуется в одиночку.

Моделирование угроз против пентеста: проектирование-до и поиск-после

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

Этот последний пункт — самая суть. Пентестер может найти SQL-инъекцию, потому что уязвимый эндпоинт существует, чтобы его прощупать. Пентестер обычно не может сказать вам, что в вашем дизайне ссылки-шеринга нет понятия скоупинга прав на конкретную ссылку, — потому что снаружи это выглядит как система, работающая по проекту. Этот изъян невидим для поиска-после именно потому, что это проектное решение, а не дефект. Вы поймаете его, только спросив «что может пойти не так?», пока проект ещё диаграмма. Используйте оба: моделируйте проект до того, как построите, и пентестите результат после того, как выкатите.

Экономика: почему найти рано — это и есть вся суть

Моделирование угроз не бесплатно. Стоящая сессия стоит часа-двух нескольких опытных людей плюс дисциплины держать модель живой, пока проект движется, — назовём это реальным инженерным временем на каждую нетривиальную фичу. Аргумент в пользу того, чтобы за это платить, — это асимметрия стоимости неуплаты. Долго цитируемое отраслевое эмпирическое правило, восходящее к данным, обобщённым в цифрах NIST и IBM Systems Sciences Institute, гласит, что дефект стоит порядка 1 единицы на исправление при проектировании, ~6,5× при реализации, ~15× при тестировании и 30–100× после попадания в прод. Точные множители спорны и разнятся от исследования к исследованию, но форма устойчива и интуитивна: чем позже найден изъян, тем больше кода, данных и нижестоящих решений вокруг него закостенело.

Для проектного изъяна асимметрия хуже, чем для обычного бага, потому что позднее исправление — не однострочный патч, а переархитектура, часто миграция данных, иногда скоординированное изменение в нескольких сервисах, которые уже доверяют сломанному допущению. Сценарий провала, которого стоит бояться, — тот самый из хука: вы пропускаете моделирование, выкатываете проект, чей изъян нельзя пропатчить (отсутствующий скоуп прав, цена, которой доверяют от клиента, неаутентифицированный внутренний эндпоинт, который только что выставили наружу), — и вот вы платите множитель 30–100× и переархитектурите и делаете это под давлением раскрытия или инцидента. Компромисс резок именно потому, что так перекошен: пара опытных часов структурированного пессимизма у доски выкупает вас из целого класса самых дорогих провалов в софте.