Моделирование угроз в процессе разработки ПО

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

А пока можно использовать сторонние источники для моделирования угроз в рамках разработки:

- STRIDE от Microsoft (и Threat Modeling Tool от них же)

- OWASP - (и Threat Dragon Tool от них же)

- Матрица угроз ATT&CK для CI/CD

- Инструмент Materialize Threats Tools

- threatspec

- The Raindance Project

- PyTM

- Meta Attack Language

- Agile Threat Modeling Toolkit"

Коллеги обратили мое внимание, что у ФСТЭК есть разделы в ГОСТах по безопасной разработке, посвященные моделированию угроз. И вот этот момент я бы и хотел прокомментировать. Если мы возьмем ГОСТ Р 56939 "Разработка безопасного ПО. Общие требования", то в разделе 5.2.1 говорится, что разработчик должен провести моделирование угроз, а в разделе 5.2.3.1 этот вопрос раскрывается чуть подробнее, но и в нем не приводится никакой методологии моделирования, а всего лишь уточняется, что она должна быть и что документация разработчика должна содержать описание выбранной методологии, список выявленных угроз и список мер, эти угрозы нейтрализующих.

Эта процедура моделирования из методики Microsoft

Список угроз можно найти в другом стандарте - ГОСТе Р 58412 "Разработка безопасного ПО. Угрозы безопасности информации при разработке ПО", в котором перечислено 19 угроз. Но в нем также нет методологии выбора из перечисленного перечня угроз актуальных. Да и сами угрозы достаточно высокоуровневы и хотелось бы иметь их большую детализацию. Например, огромный пласт угроз для процесса CI/CD или угрозы, реализуемые через репозитории кода, объединяются в одну - угрозу внедрения уязвимостей программы из-за неверного использования инструментальных средств при разработке ПО. Лично мне не хватает в ГОСТ 58412 деталей, - тех же техник и тактик, которые есть в методике ФСТЭК, процедуры выбора угроз, примеров, то есть ровно того, что сделает документ практически полезным в работе.

А, например, угрозы при использовании API куда попадают в рамках упомянутого ГОСТа? А отсутствие шифрования или хотя бы хэширования паролей в разрабатываемых приложениях? А отсутствие контроля вводимых параметров? Или это не угроза, а уязвимость переполнения буфера (хотя SQL Injection это именно угроза)? А угрозы генерации неслучайных чисел в "датчиках случайных чисел"? А работа с памятью, позволяющая выполнять вредоносный код от имени привилегированных пользователей/процессов? А, в конце концов, нарушение правил контроля доступа, которое отвечает за 10 из 30 основных проблем безопасности ПО? Или такой уровень детализации не является предметом регулирования ГОСТ 58412? Вообще, хотелось бы видеть либо что-то аналогичное проекту CAPEC от MITRE (раз уж мы так активно используем концепции этой корпорации у нас), либо ссылку на возможность его использования в том же ГОСТе 58412 (рах уж мы ссылаемся на CAPEC в методике оценки угроз от 5-го февраля).

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

Ее, кстати, нет и в текущей методике оценки угроз, что ставить нас перед непростой задачей - какую из актуальных угроз нейтрализовывать первой, какую второй, какую третьей и т.д. Ровно то, о чем я писал в июне, рассказывая о методике TARA той же MITRE. А применительно к моделированию угроз в рамках безопасной разработке за основу такого метода ранжирования можно взять DREAD от Microsoft, а можно и что-то другое.

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