Threat Modeling - Подборка статей и курсов
Решил запустить серию постов с подборкой материала по каждому этапу DevSecOps. Начнем с Design/Plan, а именно подборки статей и курсов по Threat Modeling (моделирование угроз) - процессу, ориентированному на выявление угроз, определение атак, анализ сокращения и устранение угроз. Выявляя потенциальные угрозы на протяжении всего жизненного цикла разработки программного обеспечения, безопасность становится приоритетом, а не запоздалой мыслью, экономя время и деньги групп безопасности и разработчиков.
Статьи:
What Is Security Threat Modeling? by Lawrence C. Miller, Peter H. Gregory
Threat-modeling CheatSheet by OWASP
Threat Modeling in the Enterprise, Part
1: Understanding the Basics by Stiliyana Simeonova
Threat Modeling: What, Why, and How? By Adam Shostack
Threat Modeling blog by Security Innovation
Threat Modeling: 6 Mistakes You’re Probably Making by Jeff Petters
How to Create a Threat Model for Cloud Infrastructure Security by Pat Cable
Why You Should Care About Threat Modelling by Suresh Marisetty
Курсы:
Threat Modeling, or Architectural Risk Analysis by Coursera
Threat Modeling Workshop by Robert Hurlbut
#threatmodeling #article #dev #ops
Решил запустить серию постов с подборкой материала по каждому этапу DevSecOps. Начнем с Design/Plan, а именно подборки статей и курсов по Threat Modeling (моделирование угроз) - процессу, ориентированному на выявление угроз, определение атак, анализ сокращения и устранение угроз. Выявляя потенциальные угрозы на протяжении всего жизненного цикла разработки программного обеспечения, безопасность становится приоритетом, а не запоздалой мыслью, экономя время и деньги групп безопасности и разработчиков.
Статьи:
What Is Security Threat Modeling? by Lawrence C. Miller, Peter H. Gregory
Threat-modeling CheatSheet by OWASP
Threat Modeling in the Enterprise, Part
1: Understanding the Basics by Stiliyana Simeonova
Threat Modeling: What, Why, and How? By Adam Shostack
Threat Modeling blog by Security Innovation
Threat Modeling: 6 Mistakes You’re Probably Making by Jeff Petters
How to Create a Threat Model for Cloud Infrastructure Security by Pat Cable
Why You Should Care About Threat Modelling by Suresh Marisetty
Курсы:
Threat Modeling, or Architectural Risk Analysis by Coursera
Threat Modeling Workshop by Robert Hurlbut
#threatmodeling #article #dev #ops
dummies
What Is Security Threat Modeling? - dummies
Threat modeling is a type of risk analysis used to identify security defects in the design phase of an information system. Threat modeling is most often applied
Threat Modeling - Подборка инструментов
Продолжаем говорить о процессе моделирования угроз в DevOps на этапе Design/Plan. На этот раз это подборка инструментов.
Бесплатные:
OWASP Threat Dragon - онлайн-приложение для моделирования угроз, включающее возможность построения диаграмм и механизм правил для автоматической генерации угроз / мер по снижению риска.
Microsoft Threat Modeling Tool - средство, помогающее находить угрозы на этапе разработки программных проектов.
Owasp-threat-dragon-gitlab - Этот проект является вилкой оригинального веб-приложения OWASP Threat Dragon Майка Гудвина с интеграцией Gitlab вместо Github. Вы можете использовать его с Gitlab.com или вашим собственным экземпляром Gitlab.
raindance - проект, призванный сделать «карты атак» частью разработки программного обеспечения за счет сокращения времени, необходимого для их завершения.
threatspec - проект с открытым исходным кодом, который нацелен на устранение разрыва между разработкой и безопасностью путем внедрения моделирования угроз в процесс разработки.
Enterpise:
Irius risk - инструмент моделирования угроз с адаптивной анкетой, управляемой экспертной системой, которая направляет пользователя через простые вопросы о технической архитектуре, планируемых функциях и контексте безопасности приложения.
SD elements - автоматизируйте моделирование угроз с помощью элементов SD
Foreseeti - SecuriCAD Vanguard - это сервис SaaS для моделирования атак и автоматического моделирования угроз, который позволяет автоматически моделировать атаки на виртуальную модель среды AWS.
#threatmodeling #tools #dev #ops
Продолжаем говорить о процессе моделирования угроз в DevOps на этапе Design/Plan. На этот раз это подборка инструментов.
Бесплатные:
OWASP Threat Dragon - онлайн-приложение для моделирования угроз, включающее возможность построения диаграмм и механизм правил для автоматической генерации угроз / мер по снижению риска.
Microsoft Threat Modeling Tool - средство, помогающее находить угрозы на этапе разработки программных проектов.
Owasp-threat-dragon-gitlab - Этот проект является вилкой оригинального веб-приложения OWASP Threat Dragon Майка Гудвина с интеграцией Gitlab вместо Github. Вы можете использовать его с Gitlab.com или вашим собственным экземпляром Gitlab.
raindance - проект, призванный сделать «карты атак» частью разработки программного обеспечения за счет сокращения времени, необходимого для их завершения.
threatspec - проект с открытым исходным кодом, который нацелен на устранение разрыва между разработкой и безопасностью путем внедрения моделирования угроз в процесс разработки.
Enterpise:
Irius risk - инструмент моделирования угроз с адаптивной анкетой, управляемой экспертной системой, которая направляет пользователя через простые вопросы о технической архитектуре, планируемых функциях и контексте безопасности приложения.
SD elements - автоматизируйте моделирование угроз с помощью элементов SD
Foreseeti - SecuriCAD Vanguard - это сервис SaaS для моделирования атак и автоматического моделирования угроз, который позволяет автоматически моделировать атаки на виртуальную модель среды AWS.
#threatmodeling #tools #dev #ops
Docs
Microsoft Threat Modeling Tool overview - Azure
Overview of the Microsoft Threat Modeling Tool, containing information on getting started with the tool, including the Threat Modeling process.
threat_modeling_designing_for_security.epub
6.4 MB
"Threat Modeling: Designing for Security." by Adam Shostack
Адам Шостак отвечает за моделирование угроз SDLC в Microsoft и является одним из немногих экспертов по моделированию угроз в мире. Он подробно описывает, как с самого начала встроить безопасность в проектирование систем и ПО, объясняет различные подходы к моделированию угроз, предоставляет методы, которые были проверены в Microsoft и предлагает практические советы, не связанные с каким-либо конкретным программным обеспечением, операционной системой или языком программирования.
#literature #threatmodeling #dev #ops
Адам Шостак отвечает за моделирование угроз SDLC в Microsoft и является одним из немногих экспертов по моделированию угроз в мире. Он подробно описывает, как с самого начала встроить безопасность в проектирование систем и ПО, объясняет различные подходы к моделированию угроз, предоставляет методы, которые были проверены в Microsoft и предлагает практические советы, не связанные с каким-либо конкретным программным обеспечением, операционной системой или языком программирования.
#literature #threatmodeling #dev #ops
MITRE ATT&CK for DevOps
MITRE ATT&CK - фреймворк для описания поведения злоумышленника на разных стадиях реализации атаки. Фреймворк позволяет описать, какие цели и способы реализации атаки есть у злоумышленника на ту или иную систему.
MITRE ATT&CK Cloud martix:
- AWS
- GCP
- Azure
- Azure AD
- SaaS
MITRE ATT&CK Kubernetes
Интересно то, что в блоге компании Sysdig можно найти пост с матрицей атак, направленных на контейнеры во время их исполнения (run-time). Кликнув на конкретный способ, сайт переводит на правила инструмента Falco на GitHub и конкретную строку кода, которая отвечает за защиту от этой атаки. -
MITRE ATT&CK Container Runtime
А еще есть такие инструменты как METTA, RTA, Atomic-red-team. Они позволяют выполнять тесты безопасности в формате MITRE ATT&CK. Пример для Linux.
#tools #threatmodeling #dev #ops #attack
MITRE ATT&CK - фреймворк для описания поведения злоумышленника на разных стадиях реализации атаки. Фреймворк позволяет описать, какие цели и способы реализации атаки есть у злоумышленника на ту или иную систему.
MITRE ATT&CK Cloud martix:
- AWS
- GCP
- Azure
- Azure AD
- SaaS
MITRE ATT&CK Kubernetes
Интересно то, что в блоге компании Sysdig можно найти пост с матрицей атак, направленных на контейнеры во время их исполнения (run-time). Кликнув на конкретный способ, сайт переводит на правила инструмента Falco на GitHub и конкретную строку кода, которая отвечает за защиту от этой атаки. -
MITRE ATT&CK Container Runtime
А еще есть такие инструменты как METTA, RTA, Atomic-red-team. Они позволяют выполнять тесты безопасности в формате MITRE ATT&CK. Пример для Linux.
#tools #threatmodeling #dev #ops #attack
bookface.gif
56.9 MB
Materialize threats tool
materialize_threats - любопытный open-source инструмент для моделирования угроз на базе STRIDE.
Сценарий работы с ним следующий:
1. Создание диаграммы взаимодействия компонентов в .drawio, согласно вашему data flow
2. Выделение доверенных зон на диаграмме, согласно Rapid Threat Model Prototyping methodology (в readme есть пояснение)
3. Сохранение файла .drawio
4. Запуск materialize.py с импортом файла .drawio
5. Получение сценария реалзиации угроз в формате Gherkin
Пока что инструмент для прода не пригоден, но внимания определенно заслуживает. Похожая схема моделирования угроз работает в Enterpise решении irius risks.
#tools #threatmodeling #dev #ops
materialize_threats - любопытный open-source инструмент для моделирования угроз на базе STRIDE.
Сценарий работы с ним следующий:
1. Создание диаграммы взаимодействия компонентов в .drawio, согласно вашему data flow
2. Выделение доверенных зон на диаграмме, согласно Rapid Threat Model Prototyping methodology (в readme есть пояснение)
3. Сохранение файла .drawio
4. Запуск materialize.py с импортом файла .drawio
5. Получение сценария реалзиации угроз в формате Gherkin
Пока что инструмент для прода не пригоден, но внимания определенно заслуживает. Похожая схема моделирования угроз работает в Enterpise решении irius risks.
#tools #threatmodeling #dev #ops
Risk8s Business: Risk Analysis of Kubernetes Clusters
Mark Manning, автор статей и докладов про атаки на kubernetes, совместно с Clint Fiber, автором блога по AppSec/DevSecOps, выпустили раздел про анализ рисков k8s.
Анализ рисков состоит из двух важных этапов:
- Сбор информации об окружении. Сюда входит сбор всевозможных ресурсов k8s и оценка его сложности, способ его развертывания, используемые CNI, логи, RBAC-правила, сторонние сервисы (CI/CD, registry, vault)
- Анализ возможных рисков. На основе собранной информации, выявляются риски, связанные с мисконфигурацией - доступные сервисы, уязвимости кластера и хостов по итогам проверки CIS, некорректные NP, доступность директорий из подов и так далее.
Было также упомянуто много интересных статей и утилит, которые я опишу в последующих постах.
#k8s #attack #threatmodeling #ops
Mark Manning, автор статей и докладов про атаки на kubernetes, совместно с Clint Fiber, автором блога по AppSec/DevSecOps, выпустили раздел про анализ рисков k8s.
Анализ рисков состоит из двух важных этапов:
- Сбор информации об окружении. Сюда входит сбор всевозможных ресурсов k8s и оценка его сложности, способ его развертывания, используемые CNI, логи, RBAC-правила, сторонние сервисы (CI/CD, registry, vault)
- Анализ возможных рисков. На основе собранной информации, выявляются риски, связанные с мисконфигурацией - доступные сервисы, уязвимости кластера и хостов по итогам проверки CIS, некорректные NP, доступность директорий из подов и так далее.
Было также упомянуто много интересных статей и утилит, которые я опишу в последующих постах.
#k8s #attack #threatmodeling #ops
Shifting Threat Modeling Left: Automated Threat Modeling Using Terraform
Статья + видео о том, как применять моделирование угроз в разрезе облачной инфраструктуры на базе AWS и Terraform. В качестве примера рассматривается уязвимый проект KaiMonkey. Для выявления уязвимостей и compliance-рисков применяется инструмент Terrascan.
В продолжение этой темы предлагаю также посмотреть сравнение инструментов для сканирования Terraform.
- Shifting Cloud Security Left — Scanning Infrastructure as Code for Security Issues
#ops #terraform #threatmodeling #aws
Статья + видео о том, как применять моделирование угроз в разрезе облачной инфраструктуры на базе AWS и Terraform. В качестве примера рассматривается уязвимый проект KaiMonkey. Для выявления уязвимостей и compliance-рисков применяется инструмент Terrascan.
В продолжение этой темы предлагаю также посмотреть сравнение инструментов для сканирования Terraform.
- Shifting Cloud Security Left — Scanning Infrastructure as Code for Security Issues
#ops #terraform #threatmodeling #aws
HashiCorp
Shifting Threat Modeling Left: Automated Threat Modeling Using Terraform
Learn how automated threat modeling can be performed just by looking at Terraform code.
Kubernetes Threat Modeling Simulator
Kubernetes Threat Modeling Simulator - тестовый стенд, разворачиваемый с помощью Terraform в AWS, на котором можно попрактиковать различные сценарии атаки и защиты в k8s. Сюда входят атаки на секреты, rbac, etcd и многое другое. В случае, если что-то не получается, можно воспользоваться хинтами.
Чтобы получить какую-то теоретическую базу, можно ознакомиться с K8s Attack Tree. Это набор сценариев различных атак в виде деревьев на базе методологии STRIDE.
Ну и не забываем про известный проект ATT&CK Matrix Kubernetes.
#k8s #attack #threatmodeling #ops
Kubernetes Threat Modeling Simulator - тестовый стенд, разворачиваемый с помощью Terraform в AWS, на котором можно попрактиковать различные сценарии атаки и защиты в k8s. Сюда входят атаки на секреты, rbac, etcd и многое другое. В случае, если что-то не получается, можно воспользоваться хинтами.
Чтобы получить какую-то теоретическую базу, можно ознакомиться с K8s Attack Tree. Это набор сценариев различных атак в виде деревьев на базе методологии STRIDE.
Ну и не забываем про известный проект ATT&CK Matrix Kubernetes.
#k8s #attack #threatmodeling #ops
Redefining Threat Modeling: Security team goes on vacation
Статья от компании Segment о том, что такое Threat Modeling и как они сделали так, чтобы разработчики сами его выполняли. Данную активность они назвали символично "Utopia". Сам по себе процесс участия безопасников в данном случае они сделали опциональным. Также команда Segment поделилась опытом обучения разработчиков моделированию угроз, включая презентации.
Данную идею я, кстати, встречаю не в первый раз. В качестве примера можно почитать "Appsec Development: Keeping it all together at scale" об опыте в Snowflake.
Если у вас в закромах сохраненок есть подобные статьи про опыт самостоятельного триажа разработчиками, с удовольствием бы почитал.
#threatmodeling
Статья от компании Segment о том, что такое Threat Modeling и как они сделали так, чтобы разработчики сами его выполняли. Данную активность они назвали символично "Utopia". Сам по себе процесс участия безопасников в данном случае они сделали опциональным. Также команда Segment поделилась опытом обучения разработчиков моделированию угроз, включая презентации.
Данную идею я, кстати, встречаю не в первый раз. В качестве примера можно почитать "Appsec Development: Keeping it all together at scale" об опыте в Snowflake.
Если у вас в закромах сохраненок есть подобные статьи про опыт самостоятельного триажа разработчиками, с удовольствием бы почитал.
#threatmodeling
Application Threat Modeling или чего не хватает вашим приложениям
На подкасте упоминал про процесс моделирования угроз, который по-хорошему должен стоять в начале формирования требований безопасности к любой системе и приложению, в том числе Kubernetes. Тем не менее только сейчас нашел статью, которую хотел зашарить еще в пятницу в чат (в дополнение к тем, которыми уже поделился) - "Application Threat Modeling или чего не хватает вашим приложениям". Это небольшая статья от @icyberdeveloper о процессе моделирования угроз с применением методик STRIDE/DRIDE на примере простого приложения.
Основные шаги при моделировании угроз:
1. Декомпозиция приложения на объекты под угрозой.
2. Определение опасностей, грозящих системе.
3. Построение деревьев угроз.
4. Оценка риска безопасности для каждого дерева.
5. Сортировка опасностей в порядке убывания степени их серьезности.
6. Выбор методов борьбы с опасностями.
7. Отбор технологий для выбранных методов борьбы с опасностями.
Кстати, про все это вас будут спрашивать, если вы захотите пройти собеседование в иностранные компании на позицию AppSec или DevSecOps, поэтому однозначно стоит добавить в свой roadmap.
#dev #ops #threatmodeling
На подкасте упоминал про процесс моделирования угроз, который по-хорошему должен стоять в начале формирования требований безопасности к любой системе и приложению, в том числе Kubernetes. Тем не менее только сейчас нашел статью, которую хотел зашарить еще в пятницу в чат (в дополнение к тем, которыми уже поделился) - "Application Threat Modeling или чего не хватает вашим приложениям". Это небольшая статья от @icyberdeveloper о процессе моделирования угроз с применением методик STRIDE/DRIDE на примере простого приложения.
Основные шаги при моделировании угроз:
1. Декомпозиция приложения на объекты под угрозой.
2. Определение опасностей, грозящих системе.
3. Построение деревьев угроз.
4. Оценка риска безопасности для каждого дерева.
5. Сортировка опасностей в порядке убывания степени их серьезности.
6. Выбор методов борьбы с опасностями.
7. Отбор технологий для выбранных методов борьбы с опасностями.
Кстати, про все это вас будут спрашивать, если вы захотите пройти собеседование в иностранные компании на позицию AppSec или DevSecOps, поэтому однозначно стоит добавить в свой roadmap.
#dev #ops #threatmodeling
Threat Modelling & Supply-Chain (Part 1: Assets)
Безопасность разработки стала весьма широким доменом в плане охватываемых проблемных зон и инструментов. За последние полгода в одну из решаемых задач попала митигация рисков, связанных с атаками на цепочку поставок (supply-chain attack). Для тех, кто следит за новостями, сразу вспоминаются атаки на SolarWinds (хотя в реальности примеров подобных атак значительно больше). Тем не менее, как связать примеры подобных атак с собственной инфраструктурой и цепочкой поставок не всегда очевидно (чем активно пользуются производители решений SCA).
Чтобы понять, как мы можем защититься от атак на цепочку поставок, требуется декомпозировать задачу, а именно прибегнуть к процессу моделирования угроз: определить защищаемые активы, действия над этими активами, пользователей и потенциальные угрозы, связанные с этими действиями.
Активами могут стать код, зависимости и итоговый артефакт, то есть те компоненты, которые участвуют в цепочке поставок. Также в качестве активов нередко рассматривают сами системы, которые участвуют в процессе сборки артефактов и их развертывания (CI и CD системы).
Раскидывая все процессы разработки на схеме (мне нравится обычный draw.io с плагином dfd) мы имеем архитектуру нашего сборочного конвейера совместно с этапом раскатки. Детализация схемы зависит от вашего погружения вместе с DevOps командами. Модель угроз можно декомпозировать вплоть до всех компонентов Kubernetes. Чтобы точно убедиться, что мы ничего не пропустили, мы можем расписать процессы отдельно:
#threatmodeling #dev #ops #talks
Безопасность разработки стала весьма широким доменом в плане охватываемых проблемных зон и инструментов. За последние полгода в одну из решаемых задач попала митигация рисков, связанных с атаками на цепочку поставок (supply-chain attack). Для тех, кто следит за новостями, сразу вспоминаются атаки на SolarWinds (хотя в реальности примеров подобных атак значительно больше). Тем не менее, как связать примеры подобных атак с собственной инфраструктурой и цепочкой поставок не всегда очевидно (чем активно пользуются производители решений SCA).
Чтобы понять, как мы можем защититься от атак на цепочку поставок, требуется декомпозировать задачу, а именно прибегнуть к процессу моделирования угроз: определить защищаемые активы, действия над этими активами, пользователей и потенциальные угрозы, связанные с этими действиями.
Активами могут стать код, зависимости и итоговый артефакт, то есть те компоненты, которые участвуют в цепочке поставок. Также в качестве активов нередко рассматривают сами системы, которые участвуют в процессе сборки артефактов и их развертывания (CI и CD системы).
Раскидывая все процессы разработки на схеме (мне нравится обычный draw.io с плагином dfd) мы имеем архитектуру нашего сборочного конвейера совместно с этапом раскатки. Детализация схемы зависит от вашего погружения вместе с DevOps командами. Модель угроз можно декомпозировать вплоть до всех компонентов Kubernetes. Чтобы точно убедиться, что мы ничего не пропустили, мы можем расписать процессы отдельно:
CI Master:
- Вызов сборки
- Конфигурация сборки
- Получение секретов git из встроенного хранилища секретов
- ....
К каждому процессу подписываются защищаемыми нами активы:A01: секреты git
A02: код бизнес-приложения
A03: итоговый артефакт
A04: зависимость
...
Совместно с определением процессов и активов рекомендуется определить так называемые доверенные зоны (trusted zones). Они помогают определить логические границы, за которых ответственны те или иные администраторы систем, а также поверхности атаки злоумышленника в случае, если он окажется внутри инфраструктуры.#threatmodeling #dev #ops #talks
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
Следующим этапом определим пользователей наших процессов. Эти же пользователи будут нашими потенциальными нарушителями (threat actors). Рассматривая атаки на цепочки поставок это могут быть внутренние нарушители (разработчики, администраторы CI и CD систем, администраторы кластера, сопровождение ОС и так далее) и внешние (пользователь, который может повилять на общедоступные репозитории).Также на этом этапе мы понимаем, где еще могут использоваться наши защищаемые активы (секреты и код на рабочих станциях).
Далее переходим к главному и самому сложному - раскидывание угроз. Сложность заключается в том, чтобы определить для себя исчерпывающий перечень угроз. В лучшем случаем вам может помочь банк угроз (например MITRE), в худшем случае придется опираться на собственный опыт и известные кейсы.
На помощь могут придти методологии вроде STRIDE (она поможет нам раскидать угрозы по заранее определенным классам), а также деревья атак (поиск атак для реализации угроз посредством их зависимостей друг с другом).
На этом этапе мы можем получить уже множество интересных открытий. Например, оказывается, что разработчик имеет возможность изменять пайплайн развертывания подменяя источник артефактов, внедряя backdoor или малварь. На этом же этапе мы можем определить у себя возможность реализации Dependency Confusion при скачивании зависимости разработчиком из Artifactory и многое другое.
В следующих постах мы поговорим про приоритизацию угроз и формирование требований ИБ по результатам модели угроз. Если вы уже хотите попрактиковаться, то можете почитать пример моделирования угроз для облачного приложения в AWS с использованием STRIDE. Хорошим материалом является также Threat Modeling Training от компании Segment, где есть простые и понятные слайды по всем этапам моделирования угроз.
#threatmodeling #dev #ops #talks
Threat Modelling & Supply-Chain (Part 3: Security Controls)
В прошлых постах [1,2] мы определили угрозы, которые, как нам кажется, более или менее полно покрывают перечень действий, определенных нами в рамках процессов над активами.
Следующее, что нам нужно сделать - определить меры безопасности (security controls). Здесь два варианта - начать указывать их на каждом процессе или потоке данных в рамках схемы, либо выписать отдельной табличкой напротив каждой нашей угрозы (чтобы убедиться, что мы закрываемся от всего, что сами для себя определили). Говоря более предметно, давайте вернемся к supply chain атакам. В частности возьмем за основу упоминаемый ранее фреймворк SLSA и рассмотрим угрозу компрометации CI/CD системы.
Когда мы говорим про компрометацию системы, то речь, как правило, заходит о полноценности hardening'а этой системы, а именно о таких доменах, как
Вот примеры реализации hardening'а для разных решений CI/CD систем:
- Security Practices in GitLab
- Managing Security of Jenkins
- Securing Jenkins CI Systems
- Security hardening for GitHub Actions
- TeamCity Security Notes (лучше всего на мой взгляд сделано здесь)
- CircleCI Security
К мерам защиты CI/CD может относиться ролевая модель, отсутствие анонимной аутентификации, обязательная интеграция с identity-провайдером, запрет на доступ в Интернет для сборки, требование к изолированности агентов от агентов развертывания и обязательному логированию с последующей отправкой в SIEM-систему. Конечный список требований зависит исключительно от возможностей вашей CI/CD системы.
Рассматривая компрометацию системы хранения кода (Gitlab/Bitbucket) и артефактов (Nexus Repo, Artifactory) формируем требования безопасности по аналогии из тех же доменов.
Если мы говорим про supply chain атаки, то помимо компрометации самих систем, участвующих в процессе разработки, отдельное внимание надо уделить угрозе нарушения целостности перемещаемых активов, а именно коду и артефактов. Здесь я советую снова обратиться к SLSA-фреймворку.
Примеры угроз,
В помощь сюда приходят проекты вроде Notary или Sigstore. Кто-то реализует это посредством подписи SBOM на всех этапах разработки, кто-то ограничивается тэгированием артефактов без возможности перезаписи разработчиком. Неплохим требованием безопасности будет обязательный merge-approval для всех бизнесовых репозиториев, чтобы избежать нарушения целостности master/release ветки при компрометации УЗ разработчика.
#dev #ops #threatmodeling
В прошлых постах [1,2] мы определили угрозы, которые, как нам кажется, более или менее полно покрывают перечень действий, определенных нами в рамках процессов над активами.
Следующее, что нам нужно сделать - определить меры безопасности (security controls). Здесь два варианта - начать указывать их на каждом процессе или потоке данных в рамках схемы, либо выписать отдельной табличкой напротив каждой нашей угрозы (чтобы убедиться, что мы закрываемся от всего, что сами для себя определили). Говоря более предметно, давайте вернемся к supply chain атакам. В частности возьмем за основу упоминаемый ранее фреймворк SLSA и рассмотрим угрозу компрометации CI/CD системы.
Когда мы говорим про компрометацию системы, то речь, как правило, заходит о полноценности hardening'а этой системы, а именно о таких доменах, как
аутентификация, авторизация, сетевая безопасность, конфигурация, логирование и безопасная работа с секретами. Соответственно в этих доменах и пробуем определить полный перечень мер безопасности.Вот примеры реализации hardening'а для разных решений CI/CD систем:
- Security Practices in GitLab
- Managing Security of Jenkins
- Securing Jenkins CI Systems
- Security hardening for GitHub Actions
- TeamCity Security Notes (лучше всего на мой взгляд сделано здесь)
- CircleCI Security
К мерам защиты CI/CD может относиться ролевая модель, отсутствие анонимной аутентификации, обязательная интеграция с identity-провайдером, запрет на доступ в Интернет для сборки, требование к изолированности агентов от агентов развертывания и обязательному логированию с последующей отправкой в SIEM-систему. Конечный список требований зависит исключительно от возможностей вашей CI/CD системы.
Рассматривая компрометацию системы хранения кода (Gitlab/Bitbucket) и артефактов (Nexus Repo, Artifactory) формируем требования безопасности по аналогии из тех же доменов.
Если мы говорим про supply chain атаки, то помимо компрометации самих систем, участвующих в процессе разработки, отдельное внимание надо уделить угрозе нарушения целостности перемещаемых активов, а именно коду и артефактов. Здесь я советую снова обратиться к SLSA-фреймворку.
Примеры угроз,
реализуемых внутренним нарушителем:- Публикация вредоносного кода в релизную ветку от имени скомпрометированной УЗ разработчика
- Указание в системе сборки кода из чужой системы хранения кода
- Указание в системе развертывания артефакта из чужой системы хранения артефактов
- Загрузка в Artifactory артефакта не прошедшего систему сборки
Обратите внимание, что при отсутствии проверки целостности и прохождения дополнительной аутентификации между системами сборки, хранения кода и артефактов нам необязательно получать полный доступ над системами. Например, достаточно указать неверные входные значения (сторонний git-репозиторий) в качестве параметров сборки, либо опубликовать артефакт в Artifactory вручную через CLI минуя security-проверки в рамках централизованного процесса сборки. Ещё один пример - изменить скрипт развёртывания так, чтобы установить вредоносный дистрибутив в прод вместо проверенного security-сканерами.В помощь сюда приходят проекты вроде Notary или Sigstore. Кто-то реализует это посредством подписи SBOM на всех этапах разработки, кто-то ограничивается тэгированием артефактов без возможности перезаписи разработчиком. Неплохим требованием безопасности будет обязательный merge-approval для всех бизнесовых репозиториев, чтобы избежать нарушения целостности master/release ветки при компрометации УЗ разработчика.
#dev #ops #threatmodeling
Telegram
DevSecOps Wine
Threat Modelling & Supply-Chain (Part 1: Assets)
Безопасность разработки стала весьма широким доменом в плане охватываемых проблемных зон и инструментов. За последние полгода в одну из решаемых задач попала митигация рисков, связанных с атаками на цепочку…
Безопасность разработки стала весьма широким доменом в плане охватываемых проблемных зон и инструментов. За последние полгода в одну из решаемых задач попала митигация рисков, связанных с атаками на цепочку…
AI-Driven Threat Modelling with GPT
Сегодня в центре внимания проект STRIDE GPT — инструмент для моделирования угроз с помощью AI. В качестве ввода инструмент принимает описание приложения в свободной форме и несколько параметров, таких как аутентификация и классификация приложения. В результате инструмент выдает угрозы по методологии STRIDE, рекомендации, граф attack tree и тестовые кейсы. STRIDE GPT можно развернуть локально или запустить через веб-интерфейс.
В основе проекта лежит OpenAI Platform и несколько небольших скриптов на Python. Для работы со STRIDE GPT требуется OpenAI токен аккаунта с положительным балансом (оплата производится отдельно от ChatGPT в зависимости от количества отправленных запросов в API). Все промпты можно посмотреть там же в скриптах. Красивые графы attack tree генерируются с помощью визуализации Mermaid, которая интерпретирует и отображает схемы, сгенерированные GPT. Специально обученной модели для моделирования угроз здесь нет. Вместо OpenAI можно использовать Google AI, Mistral AI или Azure OpenAI service.
Конечно, результат работы можно получить, используя пользовательский аккаунт ChatGPT и без Python-скриптов, однако, если ознакомиться с целями инструмента из презентации, становится ясно, что две из них направлены на повышение знаний экспертов, не связанных с безопасностью. Таким образом, если в организации используется, например, Azure OpenAI для внутренних нужд, то команда AppSec может предоставить красивый интерфейс STRIDE GPT тем же разработчикам, который будет выдавать ожидаемый и в целом устраивающий результат для повышения уровня осведомленности и культуры безопасности.
Можно дописать интеграцию с отечественными аналогами вроде YandexGPT и использовать в РФ 😃
А как вы относитесь к использованию подобных технологий в рамках собственных проектов? Давайте соберем немного опыта и мудроты в комментариях.
Еще немного полезных ссылок на тему AI и TM:
Threat Modeling Example with ChatGPT
More on GPT-3 and threat modeling
Leveraging LLMs for Threat Modeling - GPT-3.5 vs Claude 2 vs GPT-4
DiagramGPT
#threatmodeling #ai
Сегодня в центре внимания проект STRIDE GPT — инструмент для моделирования угроз с помощью AI. В качестве ввода инструмент принимает описание приложения в свободной форме и несколько параметров, таких как аутентификация и классификация приложения. В результате инструмент выдает угрозы по методологии STRIDE, рекомендации, граф attack tree и тестовые кейсы. STRIDE GPT можно развернуть локально или запустить через веб-интерфейс.
В основе проекта лежит OpenAI Platform и несколько небольших скриптов на Python. Для работы со STRIDE GPT требуется OpenAI токен аккаунта с положительным балансом (оплата производится отдельно от ChatGPT в зависимости от количества отправленных запросов в API). Все промпты можно посмотреть там же в скриптах. Красивые графы attack tree генерируются с помощью визуализации Mermaid, которая интерпретирует и отображает схемы, сгенерированные GPT. Специально обученной модели для моделирования угроз здесь нет. Вместо OpenAI можно использовать Google AI, Mistral AI или Azure OpenAI service.
Конечно, результат работы можно получить, используя пользовательский аккаунт ChatGPT и без Python-скриптов, однако, если ознакомиться с целями инструмента из презентации, становится ясно, что две из них направлены на повышение знаний экспертов, не связанных с безопасностью. Таким образом, если в организации используется, например, Azure OpenAI для внутренних нужд, то команда AppSec может предоставить красивый интерфейс STRIDE GPT тем же разработчикам, который будет выдавать ожидаемый и в целом устраивающий результат для повышения уровня осведомленности и культуры безопасности.
Можно дописать интеграцию с отечественными аналогами вроде YandexGPT и использовать в РФ 😃
А как вы относитесь к использованию подобных технологий в рамках собственных проектов? Давайте соберем немного опыта и мудроты в комментариях.
Еще немного полезных ссылок на тему AI и TM:
Threat Modeling Example with ChatGPT
More on GPT-3 and threat modeling
Leveraging LLMs for Threat Modeling - GPT-3.5 vs Claude 2 vs GPT-4
DiagramGPT
#threatmodeling #ai
👍10🔥5👎3
Devici Threat Modeling Tool
Если вы хотя бы немного следите за интернациональным аппсек-комьюнити, то вы наверняка сталкивались с материалами Криса Ромео (Chris Romeo). У Криса за плечами огромное количество докладов на конференциях, включая RSA Conference и OWASP Global AppSec, подкастов, блогов и исследований, значительная часть которых посвящена моделированию угроз.
Недавно Крис основал собственный стартап Devici для автоматизации моделирования угроз. Поскольку Devici поддерживает 3 модели угроз бесплатно и практически без ограничений для команд до 10 человек, а у Криса безупречная репутация, мы с командой не могли пройти мимо и решили попробовать этот сервис.
Идея следующая:
- Создается модель угроз в виде сущности, которая может иметь различные статусы, частоту обновлений, критичность и даже время, потраченное на моделирование.
- Команда совместно составляет архитектуру приложения, где для каждого компонента назначается атрибут в свободной форме, например, Database, API, WAF, User, Admin, MySQL, RDS, CloudTrail и т.д. В этом помогает небольшой AI, который подбирает нужные атрибуты по запросу пользователя.
- На основе выбранных атрибутов инструмент назначает список угроз. Связь осуществляется через преднастроенную библиотеку угроз, привязанных к атрибутам. Также к каждой угрозе прилагается рекомендация по устранению.
- Далее команда анализирует все назначенные угрозы по всем компонентам, в результате чего формируется to-do лист, назначаемый конкретным ответственным.
За исключением местами непродуманного UX и не всегда мгновенных откликов, инструмент выглядит интересным и перспективным. Индивидуальные исследователи могут использовать инструмент для поиска идей для своих моделей угроз, а команды, работающие за рубежом, могут рассмотреть Devici в качестве дополнения к своим процессам. Авторы также экспериментируют с инновациями и представили новый класс инструментов Design-SAST, который позволяет формировать модель угроз на основе анализированного кода. В будущем возможна генерация списка угроз с помощью AI на базе назначенных атрибутов.
#threatmodeling
Если вы хотя бы немного следите за интернациональным аппсек-комьюнити, то вы наверняка сталкивались с материалами Криса Ромео (Chris Romeo). У Криса за плечами огромное количество докладов на конференциях, включая RSA Conference и OWASP Global AppSec, подкастов, блогов и исследований, значительная часть которых посвящена моделированию угроз.
Недавно Крис основал собственный стартап Devici для автоматизации моделирования угроз. Поскольку Devici поддерживает 3 модели угроз бесплатно и практически без ограничений для команд до 10 человек, а у Криса безупречная репутация, мы с командой не могли пройти мимо и решили попробовать этот сервис.
Идея следующая:
- Создается модель угроз в виде сущности, которая может иметь различные статусы, частоту обновлений, критичность и даже время, потраченное на моделирование.
- Команда совместно составляет архитектуру приложения, где для каждого компонента назначается атрибут в свободной форме, например, Database, API, WAF, User, Admin, MySQL, RDS, CloudTrail и т.д. В этом помогает небольшой AI, который подбирает нужные атрибуты по запросу пользователя.
- На основе выбранных атрибутов инструмент назначает список угроз. Связь осуществляется через преднастроенную библиотеку угроз, привязанных к атрибутам. Также к каждой угрозе прилагается рекомендация по устранению.
- Далее команда анализирует все назначенные угрозы по всем компонентам, в результате чего формируется to-do лист, назначаемый конкретным ответственным.
За исключением местами непродуманного UX и не всегда мгновенных откликов, инструмент выглядит интересным и перспективным. Индивидуальные исследователи могут использовать инструмент для поиска идей для своих моделей угроз, а команды, работающие за рубежом, могут рассмотреть Devici в качестве дополнения к своим процессам. Авторы также экспериментируют с инновациями и представили новый класс инструментов Design-SAST, который позволяет формировать модель угроз на основе анализированного кода. В будущем возможна генерация списка угроз с помощью AI на базе назначенных атрибутов.
#threatmodeling
Devici
Devici | Smart Threat Modeling Tool
Welcome to Devici. Simple, Scalable, Actionable Threat Modeling.
👍16