Зачем нужно моделирование угроз

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

Оно отвечает на четыре основных вопроса:

• Что мы создаем?
• Что может пойти не так?
• Что мы будем с этим делать?
• Хорошо ли мы справились?

Моделирование угроз воплощает принцип переноса мер безопасности на ранние этапы: нужно заниматься безопасностью в начале жизненного цикла разработки, а не после развертывания.

Чем позже обнаруживается дефект, тем сильнее растет стоимость его исправления:

• Этап проектирования — изменить схему, почти бесплатно
• Разработка — переписать часть кода
• Рабочая среда — экстренное исправление, инцидент, возможная компрометация

Обнаружить дефект проектирования до написания единой строки кода — самый дешевый из возможных способов исправления.

Моделирование угроз заставляет осознанно изменить образ мыслей: перестать думать о том, как система должна работать, и начать думать о том, как ее можно использовать во вред.

Защитники естественным образом сосредоточены на функциях и штатных сценариях. Злоумышленники ищут:

• Входные данные, которые не проверяются
• Допущения о доверии, которые можно нарушить
• Шаги, которые можно пропустить или воспроизвести
• Данные, которые должны быть защищены, но не защищены

Моделирование превращает такое противоборствующее мышление в системный, а не случайный процесс.

Три понятия лежат в основе каждой модели угроз. Не смешивайте их:

• Ресурс — нечто ценное, что стоит защищать (данные клиентов, учетные данные, доступность)
• Угроза — потенциально вредоносное событие или субъект (злоумышленник, крадущий данные)
• Уязвимость — слабое место, позволяющее угрозе реализоваться (отсутствующая проверка доступа)

Риск возникает, когда угроза может использовать уязвимость против ценного ресурса.

Нельзя защитить то, что не определено. Начинайте каждую модель угроз с перечисления того, что важно.

Распространенные категории ресурсов:

Моделирование угроз наиболее полезно в определенные моменты, а не как разовое мероприятие:

• При проектировании новой системы или функции
• При внесении существенного изменения в архитектуру
• При добавлении новой границы доверия (новой интеграции или внешнего программного интерфейса)
• После инцидента безопасности для поиска связанных пробелов

Зрелые команды рассматривают это как постоянно действующий процесс и пересматривают модель по мере развития системы.

Моделирование угроз — это командная работа. Модель, созданная одним человеком, упускает слишком много контекста.

В эффективной сессии участвуют:

• Разработчики, знающие, как система работает на самом деле
• Архитекторы, понимающие замысел проектирования
• Инженеры по безопасности, знакомые с методами атак
• Владельцы продукта, понимающие влияние на бизнес

Именно сочетание разных точек зрения помогает обнаружить угрозы, которые не увидел бы никто, выполняющий одну роль.

Существует несколько структурированных методологий; при необходимости их можно сочетать:

• STRIDE — классифицирует угрозы по типу; отлично подходит для технических проектов (рассматривается на следующем уроке)
• PASTA — ориентирована на риски и связывает угрозы с влиянием на бизнес
• Деревья атак — моделируют цели и пути злоумышленника
• DREAD — модель оценки для определения приоритетности рисков

STRIDE — наиболее распространённая отправная точка в обучении, поскольку этот подход систематичен и доступен для понимания.

Модель угроз полезна только в том случае, если она приводит к конкретным действиям. Обычно результаты включают:

• диаграмму системы и её границ доверия
• список выявленных угроз, распределённых по категориям
• оценку риска для каждой угрозы
• меры защиты или решения о принятии риска
• Задачи, назначенные ответственным

Если моделирование угроз заканчивается документом, по которому никто не предпринимает действий, оно провалилось.

Попытки моделировать угрозы часто проваливаются по предсказуемым причинам. Избегайте следующих ловушек:

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

Ограничьте область моделирования, установите сроки и свяжите его с реальными задачами.

Если вы никогда не проводили моделирование угроз, начните с небольшого и простого плана:

• Нарисуйте простую диаграмму системы и потоков данных
• Отметьте места, где данные пересекают границу доверия
• Для каждой границы спросите, что может сделать злоумышленник
• Запишите основные угрозы и меру защиты для каждой из них
• Назначьте ответственных и вернитесь к этому позже

Даже 30-минутная сессия у доски выявляет проблемы, которые иначе дошли бы до рабочей среды.

Проверьте, насколько хорошо вы усвоили основы моделирования угроз.

Вы узнали, почему моделирование угроз важно:

• Моделирование угроз позволяет системно определить, что может пойти не так, прежде чем это обнаружат злоумышленники
• Оно переносит работу по обеспечению безопасности на более ранние этапы, благодаря чему исправления обходятся гораздо дешевле
• Различайте активы, угрозы и уязвимости; риск возникает на их пересечении
• Проводите моделирование на этапе проектирования и при значительных изменениях, привлекая межфункциональную команду
• Избегайте таких ошибок, как попытка объять необъятное и отсутствие доведения до конца; всегда получайте результаты, ведущие к конкретным действиям

Далее вы изучите фреймворк STRIDE для классификации угроз.