Threat Modelling & Supply-Chain (Part 2: Threats & Threat Actors)

Следующим этапом определим пользователей наших процессов. Эти же пользователи будут нашими потенциальными нарушителями (threat actors). Рассматривая атаки на цепочки поставок это могут быть внутренние нарушители (разработчики, администраторы CI и CD систем, администраторы кластера, сопровождение ОС и так далее) и внешние (пользователь, который может повилять на общедоступные репозитории).Также на этом этапе мы понимаем, где еще могут использоваться наши защищаемые активы (секреты и код на рабочих станциях).

Далее переходим к главному и самому сложному - раскидывание угроз. Сложность заключается в том, чтобы определить для себя исчерпывающий перечень угроз. В лучшем случаем вам может помочь банк угроз (например MITRE), в худшем случае придется опираться на собственный опыт и известные кейсы.

На помощь могут придти методологии вроде STRIDE (она поможет нам раскидать угрозы по заранее определенным классам), а также деревья атак (поиск атак для реализации угроз посредством их зависимостей друг с другом).

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

В следующих постах мы поговорим про приоритизацию угроз и формирование требований ИБ по результатам модели угроз. Если вы уже хотите попрактиковаться, то можете почитать пример моделирования угроз для облачного приложения в AWS с использованием STRIDE. Хорошим материалом является также Threat Modeling Training от компании Segment, где есть простые и понятные слайды по всем этапам моделирования угроз.

#threatmodeling #dev #ops #talks