Поиски «швейцарского ножа» или Обзор инструментов моделирования угроз

Меня зовут Антон Станкевичус, я старший специалист по тестированию безопасности программного обеспечения в компании «Гарда».

Моделирование угроз (Threat modeling) — уже давно не задача из серии «если дойдут руки», а важное требование по безопасности для российских разработчиков ПО. Мы тоже подходим к такой работе максимально тщательно.

Недавно я выбирал инструмент для автоматизации Threat modeling. Было важно, чтобы он соответствовал ГОСТу по защите информации. Требовалось предоставить руководству обзор рынка и доступных решений, чтобы согласовать оптимальный вариант.

Забегая вперед, Threat modeling редко выполняется единственным инструментом. Одни решения помогают формализовать архитектуру, другие — автоматически находить уязвимости, третьи удобно встраиваются в конвейер CI/CD. Для наглядности я решил не только сравнить между собой рассматриваемое ПО и подходы, но и оценить, насколько каждое из них соответствует требованиям регулятора, а также разложить их по функциональным группам.

Итак, поехали!

Семь главных требований к инструментам Threat modeling 

Прежде чем переходить к инструментам, обрисую в общих чертах требования. В конце 2024 года вступила в силу новая редакция стандарта «Защита информации. Разработка безопасного программного обеспечения. Общие требования», которая заменила предыдущую версию 2016 года. Если раньше моделированию угроз посвящался небольшой раздел с обобщенным описанием данного процесса, то теперь этой теме отведен целый раздел с указанными конкретными требованиями и итоговыми артефактами.

В стандарте зафиксированы две основные цели:

• снижение количества недостатков, связанных с архитектурой ПО, и выработка мер по нейтрализации связанных с ней угроз (код 5.7.1.1);

• уточнение модели угроз и описания поверхности атаки по результатам разработки кода и его изменений (код 5.7.1.2).

Еще в разделе прописаны семь требований к выполнению Threat modeling и семь конкретных артефактов. Всё это служит отправной точкой при подборе конкретных рабочих инструментов.

Если у вас возник вопрос, куда же делись остальные шесть артефактов, — поздравляю, вы прошли тест на внимательность. Дело в том, что все они зеркально повторяют смысл соответствующих требований из списка (если инструмент закрывает первичное моделирование, он же дает и артефакт «модель угроз»). Лишь у одного включенного в нашу таблицу артефакта нет прямого «требования-двойника» — поэтому он и указывается отдельно.

Так или иначе, у разработчиков ПО больше не выйдет отделаться нарисованной «на коленке» диаграммой по основным уязвимостям. Модель угроз должна закрывать целый ряд требований и обновляться вместе с кодом.

Соответствие инструментов требованиям ГОСТа

С основными требованиями стандарта в общих чертах разобрались — пришло время взглянуть на сами решения для моделирования угроз. Выборка получилась небольшой — всего 16 инструментов исключительно в открытом доступе. К сожалению, собственный рынок подобных решений в нашей стране пока находится на начальном этапе формирования, и судя по анализу решений отечественных вендоров, нет ни одного коммерческого продукта, нацеленного именно на процесс моделирования угроз. Хотя сам процесс является одной из составляющих больших комплексных продуктов и решений. Зарубежные же коммерческие решения недоступны для практического использования в России. Но, как говорится, чем богаты…

О функциональности и подходах изученных решений к задачам моделирования угроз (далее — МУ) расскажу подробнее чуть позже. Пока же делюсь результатами проверки соответствия рассмотренных инструментов ГОСТу. Сразу хочется отметить, что выставленные оценки соответствия — это субъективный взгляд, так как каждый инструмент имеет свои нюансы и особенности реализации.

Что же до лидеров нашего условного рейтинга, то это, конечно, инструменты, где создается структурированная модель угроз уже «на входе». И неважно, рисуется ли она мышью в виде диаграммы (OWASP Threat Dragon, Microsoft TMT) или описывается текстом в YAML и коде (Threagile, TiCTaaC, PyTM). Главное, чтобы модель хранилась в машиночитаемом виде, и ее можно было переиспользовать.

Среди отстающих — инструменты, изначально заточенные не на МУ, а на другие задачи. Например, PlantUML и отчасти drawio-threatmodeling. Они хороши для визуализации, но хуже подходят для выполнения анализа рисков.

Типы инструментов для моделирования угроз

Как и обещал, перехожу от требований ГОСТа и критериев выбора к техническим и функциональным особенностям инструментов из нашего обзора. Далее приведем описание каждого из инструментов, поговорим о технологиях, на которых они строятся, разберем сильные стороны и ограничения решений, а также разобьем их на функциональные группы.

Диаграммные и визуальные GUI-инструменты

Это нестареющая классика, как Моцарт или Шекспир. С них в свое время начиналась автоматизация процессов моделирования угроз. Работа стартует с отрисовки схемы потоков данных, а GUI-инструмент подсказывает угрозы по встроенным шаблонам.

Главное преимущество подобных решений — низкий порог входа. Толковый архитектор или аналитик сможет быстро разобраться в интерфейсе и принципах работы такого инструмента. К тому же визуальные схемы и диаграммы легче воспринимаются не погруженными в тематику специалистами (например, менеджерами проектов или тестировщиками), чем текстовые описания и профильные технические документы.

Есть и «ложка дегтя»: модель угроз существует отдельно от кода приложения и обновляется вручную, а все ее последующие уточнения требуют четкого регламента и конкретного ответственного исполнителя.

Инструменты с model-as-code подходом

В этих решениях модель угроз хранится в виде текста — прямо в аннотациях к коду, в YAML-формате или в виде Python-скрипта. Такую модель можно удобно версионировать и при желании настроить автоматическую или авторизированную ее пересборку при изменении исходников и аннотаций. Это значительно упрощает выполнение требования ГОСТа по периодическому уточнению угроз и описанию поверхности атаки. Правда, узким местом становится дисциплина команды и отлаженность процессов. Стоит перестать обновлять описание вместе с исходниками, и модель угроз теряет актуальность.

Инструменты на основе карт и деревьев атак

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

Инструменты на базе ИИ и экосистемы

В таких решениях языковая модель генерирует первичный список угроз, анализируя представленные описания функциональности, архитектуры и назначения ПО. Подобный подход значительно ускоряет начальный этап Threat modeling. Однако полученные результаты требуют тщательной верификации, поскольку нейронки часто ошибаются, придумывают несуществующие угрозы или, наоборот, пропускают актуальные. Словом, на ИИ надейся, но и сам не плошай. 

Инструменты и форматы вне функциональных групп

Теперь рассмотрим несколько подходов к моделированию угроз, которые выбиваются из нашей стройной классификации и не относятся ни к одной из перечисленных технологических групп. 

Комплексные платформы

В эту категорию попал всего один инструмент — CAIRIS. Хотя слово «инструмент» здесь не совсем уместно — скорее, это целая «коробка» утилит для развертывания среды разработки и тестирования веб-приложений на Python. CAIRIS охватывает МУ, анализ рисков, управление требованиями безопасности, моделирование архитектуры и т. д. У платформы есть API для интеграций, а также она поддерживает импорт/экспорт данных. 

Недостатки такого «швейцарского ножа» — высокий порог входа и сложный интерфейс. CAIRIS в основном ориентирован на масштабную академическую и исследовательскую среду, для небольшого же проекта его функциональность может оказаться избыточной.

Инструменты геймификации

Игровые форматы не претендуют на соответствие ГОСТу — их можно рассматривать лишь как забавное дополнение к ранее описанным базовым решениям. 

Яркий пример такой геймификации — Elevation of Privilege (EoP). Это игра с открытым исходным кодом, которая помогает разработчикам выявлять уязвимости на ранних этапах жизненного цикла ПО. Команды используют карты с мастями, соответствующими пунктам методологии STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege), чтобы моделировать угрозы для новых сервисов. После такой сессии доска пестрит угрозами, а команда вместо скучающих взглядов демонстрирует живой интерес: споры о подмене токенов и утечках логов становятся нормой.

Другая популярная карточная игра для моделирования угроз — OWASP Cornucopia, где масти соответствуют отдельным направлениям безопасности (например, аутентификации, криптографии, управлению доступом, защите данных). Большинство таких инструментов доступно как в физическом, так и в онлайн-формате, что удобно для территориально распределенных команд и дистанционных встреч. Если процесс моделирования угроз уже налажен и отвечает требованиям ГОСТа, то почему бы не добавить немного «игры» в обсуждение уязвимостей?

Инструменты, которые нельзя отнести к другим категориям

Есть еще парочка инструментов (Materialize Threats и MAL), которые сложно отнести к ранее описанным категориям, поэтому я решил оставить для них отдельное место в статье. 

Вместо заключения

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

Ниже представлю таблицу дополнительных критериев соответствия инструментов: 

Сопоставление инструментов по отдельным критериям вовсе не означает, что нужно выбрать один из них. Считаю, что важны не отдельные инструменты и подходы, а их комбинации. Выбор рабочей связки зависит от конкретных задач и особенностей ПО.

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

А чем моделируете угрозы вы, и что оказалось решающим при выборе: покрытие требований госстандарта или удобство команды? Получается ли поддерживать модель угроз в актуальном состоянии при активной разработке, и кто в команде за это отвечает? Наконец, какое из семи требований ГОСТа по МУ оказалось сложнее всего выполнить? Не стесняйтесь и делитесь своим опытом в комментариях.

Ссылки на полезные ресурсы

• ГОСТ Р 56939-2024: Разработка безопасного программного обеспечения. Общие требования

• Банк данных угроз ФСТЭК России: https://bdu.fstec.ru/

• ГОСТ Р 58412-2019: Угрозы безопасности информации при разработке программного обеспечения

• Awesome Threat Modeling: https://github.com/hysnsec/awesome-threat-modelling

• Threat Modeling Manifesto: https://www.threatmodelingmanifesto.org

• CAPEC (Common Attack Pattern Enumeration and Classification): https://capec.mitre.org/

• MITRE ATT&CK: https://attack.mitre.org/

• CWE (Common Weakness Enumeration): https://cwe.mitre.org/