»
Как проводить моделирование угроз программного обеспечения
Моделирование угроз — это систематический процесс выявления, оценки и документирования потенциальных атак на систему. Цель — не просто составить список уязвимостей, а понять, как злоумышленник может использовать архитектуру приложения для достижения своих целей. Это позволяет проектировать защиту не наугад, а на основе вероятных сценариев.
Что такое моделирование угроз
Моделирование угроз — это не поиск багов в коде. Это анализ дизайна системы с точки зрения атакующего. Вы смотрите на схему взаимодействия компонентов и задаёте вопросы: «Что, если злоумышленник окажется здесь?», «Какую цепочку действий он может выстроить, чтобы получить доступ туда?». Результат — не отчёт о сканировании, а документ, описывающий, какие части системы наиболее уязвимы и как их можно укрепить.
Это не формальность для отдела безопасности. Это инструмент для архитекторов и разработчиков, который помогает принимать решения о структуре данных, выборе протоколов и границах доверия между модулями.
Зачем нужно моделирование угроз
Без моделирования угроз защита строится реактивно: находят дыру — латают. Это дорого и неэффективно. Моделирование переводит безопасность в проактивный режим. Вы заранее находите слабые места до того, как код написан или система запущена. Это снижает стоимость исправлений и уменьшает вероятность дорогостоящих инцидентов.
В контексте российского регулирования, особенно 152-ФЗ и требований ФСТЭК, моделирование угроз — это не рекомендация, а обязательная часть процесса проектирования для систем, обрабатывающих персональные данные. Это не просто «хорошая практика», а требование стандартов, таких как ГОСТ Р 57580.1-2017, который прямо предписывает анализ угроз на этапе проектирования.
Основные этапы моделирования угроз
1. Определение границ анализа
Сначала нужно решить, что именно вы анализируете. Это может быть вся система, отдельный модуль или конкретный API. Важно зафиксировать, что входит в область рассмотрения, а что — нет. Например, вы можете исключить из анализа инфраструктуру хостинга, если она управляется провайдером и сертифицирована по требованиям.
2. Создание модели системы
Нарисуйте схему взаимодействия компонентов. Это не UML для разработчиков, а диаграмма потоков данных и доверия. Покажите, где хранятся данные, как они передаются, какие внешние сервисы используются. Не нужно детализировать каждую функцию, важны границы и пути.
3. Идентификация угроз
Используйте структурированные методики, чтобы не упустить важное. Самый распространённый подход — STRIDE, который классифицирует угрозы по шести типам:
| Тип угрозы | Что нарушает | Пример для веб-приложения |
|---|---|---|
| Spoofing (подмена) | Аутентификацию | Фишинг, поддельные сессии, подмена IP-адреса. |
| Spoofing | Спойфинг | Спойфинг |
Это не полный список. Для каждого компонента на схеме нужно пройтись по каждому элементу STRIDE и задать вопрос: «Может ли злоумышленник сделать это здесь?». Например, для базы данных: «Может ли злоумышленник подменить соединение с БД?» (Spoofing), «Может ли он поднять свои привилегии в СУБД?» (Elevation of Privilege).
4. Оценка рисков
Не все угрозы одинаково опасны. Оцените каждую по двум параметрам: вероятность реализации и потенциальный ущерб. Часто используют матрицу рисков или метод DREAD для количественной оценки. Это помогает расставить приоритеты: на что реагировать в первую очередь, а что можно отложить.
5. Разработка контрмер
Для каждой угрозы с высоким уровнем риска нужно определить, как её устранить или снизить вероятность. Это может быть изменение архитектуры, добавление шифрования, внедрение строгой валидации входных данных. Важно не просто закрыть дыру, а понять, почему она возникла, и исправить сам подход.
Методологии моделирования угроз
Существует несколько подходов, каждый со своей логикой. Выбор зависит от контекста и целей.
| Методология | Суть | Когда использовать |
|---|---|---|
| STRIDE | Анализ по шести типам угроз (подмена, фальсификация, отказ в обслуживании и др.). | На этапе проектирования, для систематического поиска уязвимостей в архитектуре. |
| PASTA | Семиэтапный процесс, связывающий бизнес-цели с техническими контрмерами. | Для крупных проектов, где безопасность должна быть привязана к бизнес-процессам. |
| LINDDUN | Фокус на конфиденциальности и защите персональных данных. | При проектировании систем, обрабатывающих ПДн, для соответствия 152-ФЗ. |
| OCTAVE | Оценка рисков на уровне организации, а не только технологии. | Для комплексного анализа, когда нужно учесть не только технические, но и организационные угрозы. |
STRIDE — это основа, но она не учитывает контекст бизнеса. PASTA и OCTAVE добавляют этот контекст, но требуют больше времени. LINDDUN — это специализированный инструмент для проектов, где главное — приватность, а не целостность системы.
Практический пример
Рассмотрим упрощённый сервис для обработки заявок. Пользователь через веб-интерфейс отправляет данные, которые сохраняются в базе. Администратор получает уведомление и может просмотреть заявки.
Схема: браузер → веб-сервер → база данных. Отдельно — сервис отправки уведомлений.
Применяем STRIDE к точке «браузер → веб-сервер»:
- Spoofing: можно ли отправить запрос от имени другого пользователя? Да, если сессионный токен перехвачен или подделан.
- Tampering: можно ли изменить данные в запросе? Да, если нет проверки подлинности на стороне сервера.
- Repudiation: может ли пользователь отрицать свои действия? Да, если нет детального журнала аудита.
- Information Disclosure: можно ли получить доступ к данным другого пользователя? Да, если есть уязвимость IDOR.
- Denial of Service: можно ли перегрузить сервер? Да, если нет ограничений на частоту запросов.
- Elevation of Privilege: можно ли получить права администратора? Да, если есть уязвимость в логике управления доступом.
Для угрозы «Spoofing» на этом участке контрмерой будет использование защищённых сессионных токенов с коротким временем жизни, строгая привязка сессии к IP-адресу и обязательная двухфакторная аутентификация для критичных операций.
Инструменты для моделирования угроз
Процесс можно автоматизировать. Некоторые инструменты помогают создавать диаграммы и систематизировать данные.
- Microsoft Threat Modeling Tool: бесплатный инструмент для создания диаграмм DFD и анализа угроз по STRIDE. Работает с шаблонами.
- OWASP Threat Dragon: веб-приложение для моделирования угроз, интегрируется с GitHub.
- IriusRisk: платформа для управления рисками безопасности на протяжении всего жизненного цикла разработки.
- Threagile: инструмент с открытым кодом для моделирования угроз на основе YAML.
Эти инструменты не заменяют мышление. Они структурируют процесс, помогают не забыть компоненты и угрозы. Но без понимания атакующего и архитектуры они бесполезны.
Типичные ошибки
- Формальный подход: заполнение шаблонов без реального анализа. Угрозы становятся абстрактными, а контрмеры — общими.
- Игнорирование контекста: анализ только технических компонентов без учёта бизнес-процессов и организационных рисков.
- Отсутствие приоритизации: попытка закрыть все угрозы сразу, что приводит к распылению ресурсов.
- Одноразовое действие: моделирование угроз проводят один раз при проектировании и забывают. Система меняется, появляются новые компоненты и угрозы.
Как внедрить процесс в разработку
Моделирование угроз должно быть частью жизненного цикла, а не разовой акцией. Его нужно проводить на этапе проектирования, при внесении значительных изменений в архитектуру и периодически для всей системы.
Создайте простой шаблон для документирования угроз. Включите в него: компонент, тип угрозы (STRIDE), описание атаки, вероятность, ущерб, уровень риска, предлагаемая контрмера, статус реализации.
Проводите сессии с участием архитектора, ведущего разработчика и специалиста по безопасности. Фиксируйте результаты в системе управления задачами. Обновляйте модель при каждом крупном изменении.
Заключение
Моделирование угроз — это не отчёт, а способ мышления. Это не поиск уязвимостей, а проектирование системы, которая изначально устойчива к атакам. Это не формальность, а практика, которая экономит время и деньги. В условиях требований 152-ФЗ и ФСТЭК это не выбор, а обязательный этап. Результат — не список для аудита, а архитектурные решения, которые делают атаку невыгодной или технически невозможной.