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

Законодательство

Решил я тут раскрыть чуть больше краткую заметку в своем 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, а можно и что-то другое.

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

Оцените статью
Бизнес без опасности
Есть что добавить? Добавьте!

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

  1. Maxim

    Очень нужная в настоящий момент тема.
    Учитывая включение БРПО в Приказ 239.
    А есть реальные примеры модели угроз в рамках безопасной разработки при сертификации ПО во ФСТЭК?

    Ответить
  2. Алексей

    У разработчиков есть.

    Ответить
  3. Алексей Лукацкий

    Maxim: я не видел таких моделей, но говорят у разработчиков есть. Вопрос в том, на основе какой методологии разработчики пишут свои модели?

    Ответить
  4. Алексей

    Модель разрабатывается по ГОСТ 58412. В приложении А ГОСТ (таблица А.1) каждой угрозе соответствует своя мера из ГОСТ Р 56939-2016. Разработчик у себя реализует меры из ГОСТ Р 56939-2016.

    Ответить
  5. Алексей Лукацкий

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

    Ответить
  6. Алексей

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

    Ответить
  7. Алексей Лукацкий

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

    Ответить
    1. Алексей

      Ещё раз. В ГОСТ в таблице А.1 есть перечень мер защиты. Каждый разработчик указывает, какую угрозу какой мерой он закроет. Что не так? Что мешает принять все высокоуровневые угрозы за актуальные и принять меры, которые уже есть в ГОСТ? Для чего выдумывать что-то ещё? Добавление новых угроз ГОСТ позволяет, как и убрать неактуальные. Вам не кажется странным делать замечания в процесс моделирования угроз не сделав самому ни одну модель угроз при сертификации ПО?

      Ответить
  8. Maxim

    Выдержка из ГОСТ 56939
    п.5.2.3.1

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

    П р и м е ч а н и е — входными данными для процесса моделирования угроз безопасности информации являются в первую очередь сведения о проекте архитектуры программы (предполагаемых компонентах программы, их интерфейсах и концепции их совместного выполнения), а том числе информация о заимствованных у сторонних разработчиков ПО компонентах и информация из открытых источников (например, из банка данных угроз безопасности информации Федеральной службы по техническому и экспортному контролю (ФСТЗК России)], связанная с типовыми сценариями компьютерных атак и угрозами безопасности информации….. "

    И соответственно вопрос, как ГОСТ 58412 может быть методикой для этих требований?
    Есть где-нибудь описание, как это все сопоставить?

    Ответить
    1. Алексей

      По этому вопросу проще всего обратиться в ИЛ ФСТЭК. Если нет возможности, можно взять все 19 угроз из ГОСТ 58412, выбрать актуальные (для меня актуальными были все). Потом в таблице А.1 из ГОСТ Вы сопоставляете угрозы с мерами, которые реализованы у Вас. Типовые меры есть в таблице А.1. Каждую угрозу будет закрывать несколько мер защиты. Всё.

      Ответить
  9. Maxim

    А как объяснить, что одна из мер по ГОСТ 58412 Приложение А и есть моделирование УБИ согласно ГОСТ 56939?
    И где последовательность моделирования в ГОСТ 58412? Или описания "входными данными для процесса моделирования угроз безопасности в первую очередь сведения о проекте архитектуры программы…. " достаточно??? Где действительно низкоуровневое описание процесса моделирования?

    Ответить
  10. Алексей

    Максим, я описал Вам как моделировал УБИ по этому ГОСТ. У регулятора, ИЛ и ОС при сертификации вопросов и замечаний не было. Почему ГОСТ именно такой, лучше спросить у его разработчиков — ФСТЭК России и компании "Эшелон". Я там не работаю, поэтому комментировать полученный результат не могу.

    Ответить
  11. Алексей Лукацкий

    Алексей, так поэтому я в заметке и написал, что у ФСТЭК нет процесса моделирования угроз. Требование есть. Список угроз есть. А процесса моделирования нет. То, что ИЛ, ОС, ФСТЭК не обращают на это внимание — это отдельный вопрос.

    Ответить
    1. Алексей

      Да, Вы правы. Имеем, что есть.

      Ответить