Forwarded from Security Wine (бывший - DevSecOps Wine) (Denis Yakimov)
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
Forwarded from Security Wine (бывший - DevSecOps Wine) (Denis Yakimov)
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
Forwarded from Security Wine (бывший - DevSecOps Wine) (Denis Yakimov)
Infrastructure-as-code security tool compare
Сравнение инструментов для анализа конфигурационных файлов IaC: Checkov, Indeni Cloudrail, Kics, Snyk, Terrascan, Tfsec. В качестве тестовой выборки был взят Terraform для AWS. Каждый test-case можно увидеть в репо. Полезно также будет для понимания типовых ошибок.
#terraform #iac #sast #dev #ops
Сравнение инструментов для анализа конфигурационных файлов IaC: Checkov, Indeni Cloudrail, Kics, Snyk, Terrascan, Tfsec. В качестве тестовой выборки был взят Terraform для AWS. Каждый test-case можно увидеть в репо. Полезно также будет для понимания типовых ошибок.
#terraform #iac #sast #dev #ops
Forwarded from Security Wine (бывший - DevSecOps Wine) (Denis Yakimov)
Nuclei and DevSecOps
Если вы сидите в чатиках, посвященных пентестам / уязвимостям веба, то наверняка могли слышать про инструмент Nuclei. Nuclei позиционируется как быстрый сканер уязвимостей в вебе, в котором можно определять шаблоны отправки запросов на базе yaml. Похожий подход используется, как мы знаем, современными SAST (Checkmarx, CodeQL, semgrep). Также, как и в CodeQL, предполагается, что эти же заполненные шаблоны могут быть переданы исследователями безопасности в рамках Bug Bounty. В дальнейшем Nuclei вместе со всеми шаблонами встраивается в CI/CD. У инструмента также есть отдельное репо с готовыми шаблонами на разные случаи жизни (от фаззинга до IoT).
Прилагаю также дополнительный полезный материал на тему Nuclei:
- Exploiting Race conditions with Nuclei
- How to Scan Continuously with Nuclei?
- Nuclei - Fuzz all the things
#dev #ops #attack #dast
Если вы сидите в чатиках, посвященных пентестам / уязвимостям веба, то наверняка могли слышать про инструмент Nuclei. Nuclei позиционируется как быстрый сканер уязвимостей в вебе, в котором можно определять шаблоны отправки запросов на базе yaml. Похожий подход используется, как мы знаем, современными SAST (Checkmarx, CodeQL, semgrep). Также, как и в CodeQL, предполагается, что эти же заполненные шаблоны могут быть переданы исследователями безопасности в рамках Bug Bounty. В дальнейшем Nuclei вместе со всеми шаблонами встраивается в CI/CD. У инструмента также есть отдельное репо с готовыми шаблонами на разные случаи жизни (от фаззинга до IoT).
Прилагаю также дополнительный полезный материал на тему Nuclei:
- Exploiting Race conditions with Nuclei
- How to Scan Continuously with Nuclei?
- Nuclei - Fuzz all the things
#dev #ops #attack #dast
Forwarded from Security Wine (бывший - DevSecOps Wine)
Уязимости веб-приложений.png
765.6 KB
"Безопасность веб-приложений" Эльдар Заитов" - Школа информационной безопасности Яндекс 2018.
Первая лекция из серии уроков Яндекса по безопасности. + Авторский бонусный материал в виде майнд-мапы по серверным и клиентским уязвимостям, а также способам защиты
https://www.youtube.com/watch?v=rSp2cpAI4Tc&list=PLdJo1XilUTZPOJ1kSnoKheT7YSygP9FIO
#web #code #lecture #dev
Первая лекция из серии уроков Яндекса по безопасности. + Авторский бонусный материал в виде майнд-мапы по серверным и клиентским уязвимостям, а также способам защиты
https://www.youtube.com/watch?v=rSp2cpAI4Tc&list=PLdJo1XilUTZPOJ1kSnoKheT7YSygP9FIO
#web #code #lecture #dev
Forwarded from Security Wine (бывший - DevSecOps Wine) (Denis Yakimov)
How to find client-side prototype pollution at scale
Загрязнение прототипа (prototype pollution) - уязвимость, вызванная особенностями JS, позволяющая реализовать XSS и даже RCE. Подробное описание уязвимости было приведено ребятами из Huawei. Сегодня мне хотелось бы поделиться статьей о том, как эту уязвимость искали - "A tale of making internet pollution free"- Exploiting Client-Side Prototype Pollution in the wild". Благодаря selenuim, собственному расширению для браузера и запросу codeql ресерчеры нашли 18 уязвимых библиотек и зарепортили около 80 багов.
Кстати в стандартном паке codeql также есть кое-какие правила для поиска prototype pollution в собственных исходниках.
#dev #sast
Загрязнение прототипа (prototype pollution) - уязвимость, вызванная особенностями JS, позволяющая реализовать XSS и даже RCE. Подробное описание уязвимости было приведено ребятами из Huawei. Сегодня мне хотелось бы поделиться статьей о том, как эту уязвимость искали - "A tale of making internet pollution free"- Exploiting Client-Side Prototype Pollution in the wild". Благодаря selenuim, собственному расширению для браузера и запросу codeql ресерчеры нашли 18 уязвимых библиотек и зарепортили около 80 багов.
Кстати в стандартном паке codeql также есть кое-какие правила для поиска prototype pollution в собственных исходниках.
#dev #sast
Forwarded from Security Wine (бывший - DevSecOps Wine) (Denis Yakimov)
10 Types of Web Vulnerabilities that are Often Missed, OWASP Top 10 Over Time
Сегодня у нас на очереди снова веб, а именно 10 уязвимостей, которые часто упускают.
Среди них:
- HTTP/2 Smuggling
- XXE via Office Open XML Parsers
- SSRF via XSS in PDF Generators
- XSS via SVG Files
- Blind XSS
- Web Cache Deception
- Web Cache Poisoning
- h2c Smuggling
- Second Order Subdomain Takeovers
- postMessage bugs
А на картинке вы, кстати, видете, как менялся OWASP Top 10 с 2004 по 2021 год.
#dev
Сегодня у нас на очереди снова веб, а именно 10 уязвимостей, которые часто упускают.
Среди них:
- HTTP/2 Smuggling
- XXE via Office Open XML Parsers
- SSRF via XSS in PDF Generators
- XSS via SVG Files
- Blind XSS
- Web Cache Deception
- Web Cache Poisoning
- h2c Smuggling
- Second Order Subdomain Takeovers
- postMessage bugs
А на картинке вы, кстати, видете, как менялся OWASP Top 10 с 2004 по 2021 год.
#dev