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)
Безопасность разработки стала весьма широким доменом в плане охватываемых проблемных зон и инструментов. За последние полгода в одну из решаемых задач попала митигация рисков, связанных с атаками на цепочку…
Безопасность разработки стала весьма широким доменом в плане охватываемых проблемных зон и инструментов. За последние полгода в одну из решаемых задач попала митигация рисков, связанных с атаками на цепочку…
Jenkins secrets quiz
Сегодня мы сделаем небольшой квиз. У команды разработки есть Jenkins, используемый для сборки. Jenkins в свою очередь необходимы секреты для получения доступа к сторонним prod-системам (разработчики используют плагин
Ответ будет завтра.
#dev #ops #talks
Сегодня мы сделаем небольшой квиз. У команды разработки есть Jenkins, используемый для сборки. Jenkins в свою очередь необходимы секреты для получения доступа к сторонним prod-системам (разработчики используют плагин
сredentials-binding). Разработчики самостоятельно пишут groovy-скрипты в Jenkins с выданными правами на запись и запуск согласно матрице доступов. Безопасно ли это?Ответ будет завтра.
#dev #ops #talks
Безопасно ли это с точки зрения компрометации секретов?
Anonymous Poll
9%
Да, секреты не будут доступны разработчикам
41%
Да, если используется сторонний Vault
9%
Скорее всего да
42%
Нет (ответ в комментариях)
Jenkins secrets extraction
Возвращаемся к нашему квизу, который вызвал бурные обсуждения в чате. 59% человек посчитало, что схема является безопасной с точки зрения управления секретами. Как итог они оказались неправы. Дело в том, что упомянутый плагин
Так как разработчик имеет доступ к конфигурации сборки и ее запуску в Jenkins, то помимо извлечения секретов может быть поднят reverse shell или вызван DoS всего сборочного конвейера. Все зависит от сетевых доступов и прав на агенте сборки.
Какой же вывод? Как ни странно, то компенсирующей мерой сделать так, чтобы конфигурация джобы тащилась из внешнего Jenkinsfile, который будет расположен в Git, а разработчик мог эту джобу только запустить. Jenkinsfile на стороне Git-репозитория в свою очередь будет защищен принудительным merge approval и другими мерами, которые могут быть реализованы на стороне SCM.
#dev #ops #talks #attack
Возвращаемся к нашему квизу, который вызвал бурные обсуждения в чате. 59% человек посчитало, что схема является безопасной с точки зрения управления секретами. Как итог они оказались неправы. Дело в том, что упомянутый плагин
сredentials-binding может позволить разработчикам извлечь секреты даже если секреты используются во внешнем хранилище Vault. Но дело даже не в плагине, а в самой возможности разработчика влиять на конфигурацию сборки, ведь с тем же успехом можно извлечь секреты напрямую из $JENKINS_HOME/credentials.xml и $JENKINS_HOME/secrets воспользовавшись hudson.util.Secret.decrypt или сторонними инструментами.Так как разработчик имеет доступ к конфигурации сборки и ее запуску в Jenkins, то помимо извлечения секретов может быть поднят reverse shell или вызван DoS всего сборочного конвейера. Все зависит от сетевых доступов и прав на агенте сборки.
Какой же вывод? Как ни странно, то компенсирующей мерой сделать так, чтобы конфигурация джобы тащилась из внешнего Jenkinsfile, который будет расположен в Git, а разработчик мог эту джобу только запустить. Jenkinsfile на стороне Git-репозитория в свою очередь будет защищен принудительным merge approval и другими мерами, которые могут быть реализованы на стороне SCM.
#dev #ops #talks #attack
Threat Hunting with Kubernetes Audit Logs
Небольшая статья (из серии) на тему, на что можно смотреть при разборе логов Kubernetes API, чтобы выявлять подозрительные действия. Здесь же есть примеры правил, которые можно переиспользовать как-то в своих SIEM. Принцип простой - выявляем наиболее частые запросы, где пользователю было недостаточно прав доступа и собираем инфу о том, кто, куда и с каким
Да, это просто и далеко не всегда эффективно, но в качестве первых шагов вполне себе смахивает на меру защиты.
#ops #k8s #attack
Небольшая статья (из серии) на тему, на что можно смотреть при разборе логов Kubernetes API, чтобы выявлять подозрительные действия. Здесь же есть примеры правил, которые можно переиспользовать как-то в своих SIEM. Принцип простой - выявляем наиболее частые запросы, где пользователю было недостаточно прав доступа и собираем инфу о том, кто, куда и с каким
verb. Также предлагается фильтровавать по конкретному verb (например list) и user.username (чтобы отметать системный трафик).Да, это просто и далеко не всегда эффективно, но в качестве первых шагов вполне себе смахивает на меру защиты.
#ops #k8s #attack
Security as code: The best (and maybe only) path to securing cloud applications and systems
Статья на тему, как выстроить "безопасность как код" (SaC) по мнению McKinsey. Обратите внимание на картинку с описанием мер безопасности на каждом этапе процесса разработки
Чего мне не хватает в подобных статьях, так это примеров. Особенно, если говорить про "SaC", то есть то, что вообще нечасто встретишь в enterpise. Для меня, например, одна из реализаций SaC - это внедрение подхода BDD с помощью Gauntlt. У кого-то SaC - это прежде всего "Compliance as Code" в виде Chef InSpec или OpenSCAP. У кого-то это реализация policy engine в виде OPA. Сами McKinsey приводят в качестве примера автоматическое шифрование ПДн, которое "запускается всякий раз, когда разработчик отправляет код."
А что для вас Security as Code?
#dev #ops
Статья на тему, как выстроить "безопасность как код" (SaC) по мнению McKinsey. Обратите внимание на картинку с описанием мер безопасности на каждом этапе процесса разработки
(No developer access to binary artifacts, Deployments must be approved by product owner, ...).Чего мне не хватает в подобных статьях, так это примеров. Особенно, если говорить про "SaC", то есть то, что вообще нечасто встретишь в enterpise. Для меня, например, одна из реализаций SaC - это внедрение подхода BDD с помощью Gauntlt. У кого-то SaC - это прежде всего "Compliance as Code" в виде Chef InSpec или OpenSCAP. У кого-то это реализация policy engine в виде OPA. Сами McKinsey приводят в качестве примера автоматическое шифрование ПДн, которое "запускается всякий раз, когда разработчик отправляет код."
А что для вас Security as Code?
#dev #ops
Cloud_Native_Security.pdf
5.6 MB
Cloud Native Security
Свежая книга по cloud native безопасности (kubernetes, aws) с упоминанием некоторых DevSecOps-подходов (есть даже про "deprecation of PSP"). В основном все строится на практической составляющей с вводом-выводом на консоль и примерами интеграций конкретных инструментов.
#literature #dev #ops #k8s #aws
Свежая книга по cloud native безопасности (kubernetes, aws) с упоминанием некоторых DevSecOps-подходов (есть даже про "deprecation of PSP"). В основном все строится на практической составляющей с вводом-выводом на консоль и примерами интеграций конкретных инструментов.
#literature #dev #ops #k8s #aws
kubescape
Кажется уже все слышали, что NSA (National Security Agency) выпустили Kubernetes Hardening Guidance, но не все знают, что вслед за этим вышел open-source инструмент Kubescape от компании Armo для проверки кластера на соответствие этому гайду. Подобный набор проверок можно встретить в том же kubeaudit, но kubescape отличает тот факт, что правила написаны на языке OPA (Rego). Тут стоит отметить, что речь идет именно о кластере, а не о манифестах, которые хранятся в git, где может подойти любой IaC сканер вроде kics.
UPD. Исходя их сорсов, тула ходит во внешние серверы Armo за правилами. Спасибо @ttffdd
#k8s #ops
Кажется уже все слышали, что NSA (National Security Agency) выпустили Kubernetes Hardening Guidance, но не все знают, что вслед за этим вышел open-source инструмент Kubescape от компании Armo для проверки кластера на соответствие этому гайду. Подобный набор проверок можно встретить в том же kubeaudit, но kubescape отличает тот факт, что правила написаны на языке OPA (Rego). Тут стоит отметить, что речь идет именно о кластере, а не о манифестах, которые хранятся в git, где может подойти любой IaC сканер вроде kics.
UPD. Исходя их сорсов, тула ходит во внешние серверы Armo за правилами. Спасибо @ttffdd
#k8s #ops
Опрос: что вы думаете о DevSecOps?
Коллеги из PT расшифровали доклад с PHDays о применении Security Gym в обучении разработчиков писать безопасный код: "Безопасность для айтишников: как научить разработчиков устранять уязвимости и создавать безопасные приложения". Помимо теории (описания уязвимости в коде), обучение также предполагает написание функциональных и security-тестов, участие в CTF.
Также PT запустили опрос: "Что вы думаете о DevSecOps?", в котором просят пользователей Habr рассказать о том, как обстоят дела с безопасной разработкой в компании. Предлагаю помочь им собрать как можно больше данных для исследования :)
#talks #dev
Коллеги из PT расшифровали доклад с PHDays о применении Security Gym в обучении разработчиков писать безопасный код: "Безопасность для айтишников: как научить разработчиков устранять уязвимости и создавать безопасные приложения". Помимо теории (описания уязвимости в коде), обучение также предполагает написание функциональных и security-тестов, участие в CTF.
Также PT запустили опрос: "Что вы думаете о DevSecOps?", в котором просят пользователей Habr рассказать о том, как обстоят дела с безопасной разработкой в компании. Предлагаю помочь им собрать как можно больше данных для исследования :)
#talks #dev
Threat Hunting with Kubernetes Audit Logs - Part 2
Вторая статья на тему обработки событий с Kubernetes API для поиска аномалий (первую можно прочитать здесь). Событий стало чуть больше и теперь они привязаны к матрице MITRE ATT&CK.
#k8s #ops
Вторая статья на тему обработки событий с Kubernetes API для поиска аномалий (первую можно прочитать здесь). Событий стало чуть больше и теперь они привязаны к матрице MITRE ATT&CK.
#k8s #ops
Square Corner Blog
Threat Hunting with Kubernetes Audit Logs - Part 2
Using the MITRE ATT&CK® Framework to hunt for attackers
Forwarded from CloudSec Wine (Артем Марков)
🔶 KONTRA's AWS Top 10
A series of free interactive security training modules that teach developers how to identify and mitigate security vulnerabilities in their AWS-hosted cloud applications.
https://application.security/free/kontra-aws-clould-top-10
#aws
A series of free interactive security training modules that teach developers how to identify and mitigate security vulnerabilities in their AWS-hosted cloud applications.
https://application.security/free/kontra-aws-clould-top-10
#aws
Kontra
Application Security Training For Developers | Kontra
Kontra is an Application Security Training platform built for modern development teams.
Cloud Security Orienteering
Статья на тему, что нужно делать, чтобы разобраться в безопасности AWS организации, про которую ты ничего не знаешь. Приведено большое количество фреймворков в стиле awesome, такие как AWS Security Maturity Roadmap 2021, The AWS Security Reference Architecture и Cloud Penetration Testing Playbook. Плюс сам автор статьи поделился своим собственным чеклистом.
#aws #ops
Статья на тему, что нужно делать, чтобы разобраться в безопасности AWS организации, про которую ты ничего не знаешь. Приведено большое количество фреймворков в стиле awesome, такие как AWS Security Maturity Roadmap 2021, The AWS Security Reference Architecture и Cloud Penetration Testing Playbook. Плюс сам автор статьи поделился своим собственным чеклистом.
#aws #ops
tl;dr sec
Cloud Security Orienteering
How to orienteer in a cloud environment, dig in to identify the risks that matter, and put together actionable plans that address short, medium, and long term goals.
Yandex Cloud Security Checklist
В продолжение поста про многообразие способов и инструментов аудита AWS я решил выпустить первый чеклист по безопасной конфигурации Яндекс.Облака. В основе лежит агрегация всего, что есть в документации YC на тему безопасности, плюс некоторый свой опыт, выявленный в рамках аудитов. Глобально чеклист разбит на домены сетевой безопасности и контроля доступа.
Основная проблема в том, что почти все механизмы безопасности (Security Groups, Audit Trails), которых и так немного, находятся либо на стадии Preview, либо подключаются по запросу. Остальные механизмы подключаются через маркетплейс из числа сторонних коммерческих решений.
UPD. Кстати, если хотите часть проверок пройти автоматизированными средствами, то рекомендую Cloud Advisor. Там, в частности, пока еще есть возможность провести бесплатное сканирование.
#yandex #ops
В продолжение поста про многообразие способов и инструментов аудита AWS я решил выпустить первый чеклист по безопасной конфигурации Яндекс.Облака. В основе лежит агрегация всего, что есть в документации YC на тему безопасности, плюс некоторый свой опыт, выявленный в рамках аудитов. Глобально чеклист разбит на домены сетевой безопасности и контроля доступа.
Основная проблема в том, что почти все механизмы безопасности (Security Groups, Audit Trails), которых и так немного, находятся либо на стадии Preview, либо подключаются по запросу. Остальные механизмы подключаются через маркетплейс из числа сторонних коммерческих решений.
UPD. Кстати, если хотите часть проверок пройти автоматизированными средствами, то рекомендую Cloud Advisor. Там, в частности, пока еще есть возможность провести бесплатное сканирование.
#yandex #ops
GitHub
GitHub - Vinum-Security/yandex-cloud-security: ⛅️🔐 Security Requirements for Yandex.Cloud configuration: IAM, network access, key…
⛅️🔐 Security Requirements for Yandex.Cloud configuration: IAM, network access, key management, Kubernetes, audit logs. - Vinum-Security/yandex-cloud-security
Forwarded from Технологический Болт Генона
Тут Confluence похекали
CVE-2021-26084 Confluence RCE
https://github.com/httpvoid/writeups/blob/main/Confluence-RCE.md
CVE-2021-26084 Confluence RCE
https://github.com/httpvoid/writeups/blob/main/Confluence-RCE.md
Introduction to OWASP Top 10 2021
OWASP выпустили драфт документа OWASP Top 10 2021!
Из нового, что отсутствовало в последнем Top 10 2017:
- A04:2021-Insecure Design
- A08:2021-Software and Data Integrity Failures
- A10:2021-Server-Side Request Forgery
Также по списку поднялись уязвимости класса A06:2021 – Vulnerable and Outdated Components, что автоматически повышает перспективы инструментов SCA.
В начале этого года Wallarm также представили свою версию Top10, основанную на анализе базы данных Vulners.
#web #dev
OWASP выпустили драфт документа OWASP Top 10 2021!
Из нового, что отсутствовало в последнем Top 10 2017:
- A04:2021-Insecure Design
- A08:2021-Software and Data Integrity Failures
- A10:2021-Server-Side Request Forgery
Также по списку поднялись уязвимости класса A06:2021 – Vulnerable and Outdated Components, что автоматически повышает перспективы инструментов SCA.
В начале этого года Wallarm также представили свою версию Top10, основанную на анализе базы данных Vulners.
#web #dev
ZeroNights 2021
Выложили записи и слайды с Zero Nights 2021. Самое интересное для этого канала находится в секции Defensive Track.
- О метриках с практической точки зрения - доклад про метрики (в частности про те, что были приведены в HP MagicNumbers), а также немного про OWASP SAMM и ASVS.
- Побег из контейнера: Kubernetes - доклад, где название говорит само за себя от автора @k8security. Доклад начинается с вводной части о работе k8s, после чего приводятся способы побега из контейнера через capabilities, маунты и CVE (есть очень много полезных ссылок).
- CVEhound: проверка исходников Linux на известные CVE - доклад про проблемы инструментов SCA и поиск CVE в Linux с помощью CVEhound.
- DevSecOps на Open Source: бурление в стакане - про построение классического процесса на базе gosec, trufflehog, defectdojo, semgrep и т.д. Автор также поделился пайплайнами gitlab в public.
- Атаки на микросервисные приложения: методы и и практические советы - доклад про то, на что надо обращать внимание с точки зрения безопасности, когда речь заходит о микросервисах (как проверять безопасность аутентификации, авторизации, какими инструментами, где брать чеклисты).
- Лезем невидимой рукой аппсека в релизные сборки - доклад про поиск уязвимостей в мобилках и написание своей тулы CheckKarlMarx.
Все слайды можно найти здесь.
#talks #dev #ops
Выложили записи и слайды с Zero Nights 2021. Самое интересное для этого канала находится в секции Defensive Track.
- О метриках с практической точки зрения - доклад про метрики (в частности про те, что были приведены в HP MagicNumbers), а также немного про OWASP SAMM и ASVS.
- Побег из контейнера: Kubernetes - доклад, где название говорит само за себя от автора @k8security. Доклад начинается с вводной части о работе k8s, после чего приводятся способы побега из контейнера через capabilities, маунты и CVE (есть очень много полезных ссылок).
- CVEhound: проверка исходников Linux на известные CVE - доклад про проблемы инструментов SCA и поиск CVE в Linux с помощью CVEhound.
- DevSecOps на Open Source: бурление в стакане - про построение классического процесса на базе gosec, trufflehog, defectdojo, semgrep и т.д. Автор также поделился пайплайнами gitlab в public.
- Атаки на микросервисные приложения: методы и и практические советы - доклад про то, на что надо обращать внимание с точки зрения безопасности, когда речь заходит о микросервисах (как проверять безопасность аутентификации, авторизации, какими инструментами, где брать чеклисты).
- Лезем невидимой рукой аппсека в релизные сборки - доклад про поиск уязвимостей в мобилках и написание своей тулы CheckKarlMarx.
Все слайды можно найти здесь.
#talks #dev #ops
YouTube
ZeroNights X Defensive Track - YouTube