Security Wine (бывший - DevSecOps Wine)

Channel photo updated

В эти дни проходит конференция Coop-Days 2023, организованная компанией «РАД КОП». Сегодня в повестке доклады по ИТ и ИБ.

Ознакомиться с программой и посмотреть трансляцию можно по ссылке на сайте культурно-просветительского центра АРХЭ.

Докладчики уже выступают, присоединяйтесь, будет интересно!

#Конференция #CoopDays

Прямо сейчас в прямом эфире третья конференция Coop-Days. В программе доклады посвящённые не только AppSec и DevSecOps, но и выступления на темы построения карьеры в ИБ, процессного управления и перспектив развития искусственного интеллекта.

Прямая трансляции доступна по ссылке: https://youtu.be/E2__QfNtwwI (будет доступна в записи).

Программа конференции в сообщении ниже.

Про стандартизацию ФСТЭК и сертификацию процессов безопасной разработки

Помните один из первых постов этого канала? https://t.me/sec_devops/20 Отечественная стандартизация безопасной разработки продолжает набирать обороты. В пятницу ФСТЭК России опубликовал на regulation.gov Порядок сертификации процессов безопасной разработки программного обеспечения средств защиты информации :

https://regulation.gov.ru/Regulation/Npa/PublicView?npaID=143132

Главная идея, стоящая за проектом проста. Примирить требования регуляторики и Agile. Позволить разработчикам не отправлять каждый релиз на согласование в испытательную лабораторию, а доказав надежность своей CI/CD и пройдя её сертификацию, утверждать - что все продукты этой сертифицированной CI/CD заслуживают доверия.

Цитата из пояснительной записки к проекту:

"Сертификация процессов безопасной разработки программного обеспечения средств защиты информации является добровольной и позволит разработчикам и производителям сертифицированных средств защиты информации в случае проведения данной сертификации проводить испытания средств защиты информации, обусловленные внесением изменений в программное обеспечение средства защиты информации, самостоятельно без привлечения испытательной лаборатории. Что позволит сократить сроки проведения испытаний и затраты разработчиков и производителей сертифицированных средств защиты информации на проведение указанных испытаний средств защиты информации и, как следствие, снизить себестоимость средств защиты информации, применяемых в государственных информационных системах и на объектах критической информационной инфраструктуры."

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

В частности с февраля 2022 года Банк России в последней редакции своего Профиля защиты*, в разделе 7.4 рассказывает о требованиях к безопасности жизненного цикла. По мнению регулятора (оставим за скобками ряд правовых и технических нюансов) это позволяет избежать оценок соответствия или сертификации каждого релиза ДБО, т.е. по целям является аналогичным проекту ФСТЭК:

https://www.cbr.ru/content/document/file/132666/inf_note_feb_0422.pdf

*Профиль защиты является де-факто стандартом требований регулятора к банковским ДБО, личным кабинетам финансовых организаций, другим приложениям, связанным с финансовыми операциями (не являющимися средствами защиты по ФСТЭК России).

#dev #ops #law

How Secrets Leak in CI/CD Pipelines

Truffle Security, небезызвестные своими способностями отлавливать секреты, решили осветить вопросы их утечки в пайпланах:
https://trufflesecurity.com/blog/secrets-leak-in-ci-cd/

Тема поднималась уже не раз, но давайте систематизируем затронутые сценарии:

1. Раскрытие секретов в логах CI/CD. Сценарии, когда из-за особенностей синтаксиса заданий платформы CI/CD, хранения секретов в формате JSON или использования кодировок в духе base-64 секреты "проходят мимо" систем маскирования и становятся доступными в лог-файлах CI/CD после отработки соответствующих заданий;

2. Утечка секретов второго порядка. Сценарии, когда "утекают" секреты используемые для доступа к зашифрованным файлам репозиториев или к API хранилищ секретов (Hashicorp Vault, etc.);

3. Публикация артефактов в публичных репозиториях. Сценарии, когда ошибочно допущенная команда (например, npm publish) публикует в репозитории файл конфигурации с секретами в открытом виде.

Как защититься от этих сценариев?

Помимо стандартных рекомендаций и следований принципам "наименьших привилегий" и "уменьшения поверхности атаки" вот кое-что еще :

1. Один из вариантов, предлагаемых Truffle Security, это натравить truflehog на логи CI/CD (в частности в Circle CI)

2. Использовать стандартные workflow вместо кастомных. Например, автор приводит в пример CircleCI "orbs", pre-built задания, которые из коробки безопасно работают с секретами. Подобное есть и у GitHub Actions.

Если вы хотите потренироваться и разобрать в том числе другие сценарии, то можно использовать специальные обучающие инструменты для освоения материала. Например, проект OWASP WorngSecrets, который предлагает 35 упражнений, снабженных подсказками и ликбезами по разным сценариям безопасной работы с секретами (включая K8s и облачных провайдеров). WrongSecrets отлично дополнит программы повышения осведомленности разработчиков, локальные CTF и поможет выращиванию security champions. WrongSecrets может быть запущен как локально в docker, так и онлайн - на платформах herokuapp.com и fly.dev .

#Dev #Ops #Secrets

Что не так с ASVS?

Мой небольшой пост в Linkedin про неправильное использование ASVS и его недостатки для неподготовленного читателя, а именно: перегруженность, большое число заимствований и оторванность от риск-ориентированного подхода. Последнее подразумевает то, что оценка на несоответствие ASVS по сути не означает, что ваша система небезопасна. Она означает несоответствие лучшим практикам, которые, на самом деле, не всегда применимы к вашему приложению и имеют смысл для инвестирования ресурсов. Тем не менее, все еще есть мнение, что ASVS это ready-to-use стандарт, требующий минимум кастомизации. В комментариях, кстати, контрибьютеры ASVS озвучили свои мысли по этому вопросу. Кроме того, оттуда же я узнал об очень классном портале OpenCRE, где агрегированы требования из разных стандартов.

Используете ли вы ASVS в своей организации и как?

P.S. Текст продублирован в комментариях

CI/CD Security — то, без чего DevSecOps не имеет смысла

Спустя год после выступления вышла запись моего доклада с DevOps Conf 2022 про безопасность CI/CD. За год, конечно, тема набрала еще больше популярности, из-за чего многие упомянутые тезисы стали терять смысл освщеения, но я все же осмелюсь опубликовать.

CI/CD Security — то, без чего DevSecOps не имеет смысл

Кстати, также советую посмотреть два других достойных доклада на тему безопасности:
- SOAR в Kubernetes малой кровью
- Современная безопасность контейнерных приложений

#cicd

CIS Software Supply Chain Security Guide

Вот это пушка, конечно, вышла. Набор требований безопасности CIS с разбивкой на код, сборку, зависимости, артефакты и деплоймент.

#dev #ops #cicd

Наиболее распространенные уязвимости в мобильных приложениях

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

Открываем короткую неделю со статьи "Наиболее распространенные уязвимости в мобильных приложениях". Это авторский список уязвимостей на основе опыта их нахождения собственным инструментом динамического анализа мобильных приложений. Здесь есть и примеры небезопасного кода и варианты митигации. Как сам автор пишет, они мало чем отличаются от OWASP, даже не смотря на то, что последняя версия Mobile Top 10 вышла в далеком 2016 году.

#dev #mobile

CI/CD Security - то, без чего DevSecOps не имеет смысла

13 и 14 июня 2022 года в Кампусе Сколково пройдет конференция DevOps Conf & TechLead Conf 2022, где я буду выступать с докладом "CI/CD Security - то, без чего DevSecOps не имеет смысла". Поговорим про безопасность пайплайнов: мисконфигурации CI/CD, небезопасная среда разработки и непроработанная модель угроз для внутренних разработчиков и администраторов. Почему все эти вещи, как итог, приводят к тому, что внедрение DevSecOps перестает нести в себе ценность. Расскажу про наш опыт в Альфа-Банке и постараюсь разобраться, что надо сделать, чтобы занять золотую середину между паранойей и удобством разработки.

#talks

Уязвимость в репозитории NPM, позволяющая добавить сопровождающего без подтверждения

“В репозитории пакетов NPM выявлена проблема с безопасностью, позволяющая владельцу пакета добавить в число сопровождающих любого пользователя, без получения от этого пользователя согласия и без информирования о совершённом действии. Проблема усугубляется тем, что после добавления стороннего пользователя в число сопровождающих, изначальный автор пакета мог удалить себя из списка сопровождающих и сторонний пользователь оставался единственным лицом, отвечающим за пакет.

Проблемой могли воспользоваться создатели вредоносных пакетов для добавления в число сопровождающих известных разработчиков или крупных компаний с целью повышения доверия пользователей и создания иллюзии, что заслуженные разработчики отвечают за пакет, хотя на деле не имеют к нему никакого отношения и даже не знают о его существовании. Например, атакующий мог разместить вредоносный пакет, сменить сопровождающего и пригласить пользователей протестировать новую разработку крупной компании. Уязвимость также могла применяться для очернения репутации определённых разработчиков, представляя их как инициаторов сомнительных акций и вредоносных действий.”

https://opennet.ru/57108/

#dev #news

Securing Developer Tools: Package Managers

Случались ли у вас ситуации, когда антивирусный агент начинает генерировать алерты о вредоносной активности будучи установленным на сборщике? Вероятно, вы столкнулись с вредоносами, описанными в этой статьей - "Securing Developer Tools: Package Managers". Речь пойдет о вредоносных пакетах, запускаемых с помощью Composer, Bundler, Bower, Yarn и других пакетных менеджерах. Приведены также разные меры по митигации.

В Golang, кстати, часть проблем supply chain попытались решить архитектурно. Начиная c того, что сборщики не могут ничего поставить за пределами зафиксированных хэшей в go.sum и заканчивая невозможностью запускать код во время сборки. Об этой подробнее в статье "How Go Mitigates Supply Chain Attacks".

#dev

Code Review Hotspots with Semgrep

Автор сегодняшней статьи предлагает поделить сработки на две группы - security и hotspots. Сработки группы security имеют низкий уровень ложных срабатываний и предназначаются для разработчиков, в то время как сработки группы hotspots только свидетельствуют о подрзрении на уязвимость и попадают под ответственность security-инженеров. Вся статья дальше вращается вокруг хотспотов и способов их поиска через инструмент semgrep. К хотспотам относят hardoced secrets, небезопасную криптографию, мисконфиги, переполнения буфера и тд.

Интереснее не сами баги, которые здесь подсвечиваются, а подход в разделении ответственности. Какие правила считать достаточно надежными, чтобы их сработки асайнить сразу на разраба, а не на ИБ?

В теории можно обратиться к последнему отчету Veracode - State of Software Security v12. В отчете приводится разного рода интересная статистика в контексте сканеров класса SAST/DAST/SCA. В частности, здесь есть перечень CWE, которые лучше всего находятся для того или иного класса сканера (картинка приложена к посту выше). Любопытно, что Cryptographic Issues и Credentials Management относятся к категории уязвимостей, которые гораздо чаще находятся именно SAST'ами, в то время как в вышеупомянутой статье они относятся к хотспотам. Что же делать?

Здесь позволю себе высказать собственное мнение, как мы делим сработки на security и hotspots в Альфе. Для многих оно покажется очевидным. Чем больше уязвимость поддается паттернам, а не механизмам data flow, тем лучше она будет находиться через SAST и тем более уверены вы в ней будете. Сюда относятся hardocded credentials, небезопасный CORS, мисконфиги (в т.ч. Docker / Kubernetes) и другие уязвимости, которые можно допустить, указав в коде непрерывный набор строк кода. SQL-инъекции, XSS, SSRF и прочие уязвимости, подразумевающие прием данных от пользователя через request-объекты имеют свойства приобретать сложную логику развития, а значит и более высокую степень FP/FN. Нередко, влияние на правила нахождения таких уязвимостей в контексте data flow стоит вам от 3 непрерывных месяцев работы в codeql/checkmarx в соусе из перегоревших appsec'ов. В это же время паттерновые уязвимости довольно легко корректируются с помощью того же semgrep.

#dev #sast

How Flipkart Reacts to Security Vulnerabilities

Пятница - отличный день, чтобы вернуться к постам после продолжительного перерыва. Начнем мы с несложной темы для восприятия - с организационных процессов.

Команда Flipkart рассказывает, как устроены их AppSec-процессы по обработке уязвимостей: источники уязвимости, как они выглядят в Jira, какие есть роли в процессе по устранению уязвимостей, атрибуты, что такое "иммунизация", из чего состоит их обучение разработчиков.

https://blog.flipkart.tech/how-flipkart-reacts-to-security-vulnerabilities-17dae9b0661e

Данные проблемы можно решать не только через Jira, приводя за собой ее проблемы. Мы, например, в Альфа-Банке пошли по пути реализации собственного инструмента оркестрации AppSec (через "платформизацию"), который выполняет задачи, связанные с запуском необходимых сканеров (вроде, nuclei) и обработкой полученных результатов, решая часть упомянутых проблем.

#dev

Improving Web Vulnerability Management through Automation

Опыт Lyft по периодическому авто-сканированию внутренних веб-приложений с помощью Burp. В принципе, все отражено на схеме. В статье вы можете познакомиться с некоторыми деталями реализации. Со слов автора, благодаря данному подходу им удалось выиграть 3 дополнительных месяца инженера, но, как правильно было отмечено, так как вся информация хранится в Jira, то имеются проблемы с ограничением объема запросов и отслеживанием версий уязвимостей.

#dev #dast

New Argo CD Bug Could Let Hackers Steal Secret Info from Kubernetes Apps

Для тех, кто еще не видел, у ArgoCD вышла CVE-2022-24348 (CVSS score: 7.7), позволяющая дампить секреты из кластера благодаря кастомному helm-чарту. Уязвимость затрагивает все версии и была устранена в 2.3.0, 2.2.4, и 2.1.9.

Reference:
https://apiiro.com/blog/malicious-kubernetes-helm-charts-can-be-used-to-steal-sensitive-information-from-argo-cd-deployments/

#attack #k8s #ops