State of Exploitation - A Peek into the Last Decade of Vulnerability Exploitation

Я думаю, что ни для кого не секрет, что число уязвимостей с каждым годом только растет. VulnCheck выпустил неутешительную статистику по данному тренду с 2014 по 2024 год:

- Число CVE с известной эксплуатацией увеличивается на 19,7% в год.
- Число раскрытых CVE растет на 14,1% в год.
- Число CVE с публично доступными Proof-of-Concept (PoC) эксплойтами растет на 11,8% в год.

При этом:

31% уязвимостей имеют PoC, но только 1% уязвимостей эксплуатируется в "живой природе".

В данном канале мы также не освещали существующие проблемы NIST и их неспособность обрабатывать очередь из необработанных CVE для добавления в NVD. К февралю таких уязвимостей насчитывалось 11 000, на фоне сокращения бюджета и ухода текущего ключевого подрядчика CISA. К счастью, если вы еще не слышали, месяц назад NIST объявили, что к сентябрю этого года проблема будет решена, так как найден новый подрядчик. История с NVD с самого начала вызвала сильный резонанс. Были даже слышны упоминания о потенциальном "конце света" в мире управления уязвимостями.

На фоне этого хочется поделиться статьей "Dirty Little Secrets of Vulnerability Management". Автор освещает общепринятые мифы управления уязвимостями. В частности, он напоминает, что NVD не является единственным источником CVE. Существует 383 партнёра программы CVE, поддерживающих приём и регистрацию CVE (так называемые CVE Numbering Authority). Среди них есть не только вендоры, такие как Apple, но и независимые исследователи, open source и bug bounty площадки. И даже если вам это не подходит, существуют китайские аналоги CNNVD, число уязвимостей которых превышает NVD, и российская БДУ ФСТЭК🙈. Кстати, про проблему NVD и особенности БДУ подробно осветил Александр Леонов в своём докладе phd2.

#vm #cve

OWASP Authoritative Guide to SBOM

Как может показаться из названия документа, речь пойдет об SBOM (software bill of materials), хотя, на самом деле, документ о многогранном и необъятном использовании BOM и CycloneDX (стандарт OWASP для supply chain). Да, здесь есть и про формат BOM, и про применении в SDLC на разных стадиях, но большинство внимания уделено все же сценариям использования.

Чем это может быть полезно лично для вас и вашей организации? Стандарт затрагивает такие темы как:

- Управление конфигурациями предприятия (CMDB): Отслеживание активов и управление конфигурациями в базе данных.
- Проверка целостности: Обеспечение того, что компоненты программного обеспечения не были изменены с момента их выпуска.
- Аутентичность: Подтверждение подлинности компонентов или самого SBOM.
- Анализ устаревших компонентов: Определение компонентов, которые больше не поддерживаются или устарели.
- Происхождение (Provenance): Отслеживание истории и происхождения компонентов.
- Родословная (Pedigree): Представление информации о происхождении, изменениях и вариациях компонентов.
- Управление поставщиками и рисками: Оценка и управление рисками, связанными с поставщиками и их продукцией.
- Управление цепочкой поставок: Оптимизация процессов управления поставками программных компонентов.
- Полнота состава и "известные неизвестные": Оценка полноты информации в BOM и идентификация элементов с неизвестным статусом.
- Подтверждение и проверка состава: Проверка точности и полноты информации о составе продукта на всех этапах его жизненного цикла.
- Управление криптографическими активами: Управление и отслеживание криптографических ключей, сертификатов и других элементов.
- Идентификация слабых криптографических алгоритмов: Определение и замена устаревших или уязвимых криптографических алгоритмов.
- Готовность к постквантовой криптографии (PQC): Подготовка к эре постквантовых вычислений и обеспечение безопасности криптографических систем перед лицом новых угроз.

Кстати, на сайте Белого Дома в указе от 2021 года о повышении безопасности нации указано о необходимости создания SBOM для всех критически важных программных продуктов, используемых правительственными агентствами. Это далеко не первое упоминание SBOM правительством США. Самое раннее упоминание SBOM можно найти в «Cyber Supply Chain Management and Transparency Act» от 2014 года. В целом подобная документация позволяет отлично понять "куда копать дальше" тем, кто остается работать в РФ и уже выполнил базовые задачи в рамках тематики КИИ и хочет "порешать задачи под звездочкой".

#sbom #owasp

The Open Source Problem

Мы в канале любим статистику, особенно если она хорошо раскрывает глобальные проблемы на примере громких инцидентов. Недавно нам попался интересный ресерч: автор которого взял 5000 pip-пакетов и применил к ним "критерии Цзя Тан", того самого китайского контрибьютора бекдора в xz. Набор критериев простой: права на коммит, китайский часовой пояс и email, в котором сочетается имя и номер. В результате получилось 310 pip-пакетов. Даже у контрибьютеров самого pip есть некий [email protected], соответствующий таким критериям. Дополнительно можно почитать здесь и здесь.

А теперь взглянем на статистику Blackberry из их отчета о безопасности цепочки поставок ПО, составленного по результатам опроса 1000 старших руководителей:

- 51% компаний смогли восстановиться после взлома в течение недели, около 40% потребовалось месяц.
- 74% атак исходили от участников цепочки поставок программного обеспечения, о которых компании не знали или не отслеживали до взлома.
- Хотя 78% компаний отслеживают влияние атак на цепочку поставок, только 65% информируют своих клиентов об этих инцидентах.

Учитывая, что трактовать и ту и другую статистику можно по-разному, выводы делайте сами.

Мы, в свою очередь, подбросим очередную новость о том, как в популярный проект polyfill.js китайцы внедрили вредоносный код на 100k+ сайтов. Здесь, правда, история о том, как развивалась атака, более загадочная, ибо домен и GitHub-репозиторий были переданы китайским мейнтейнерам в феврале этого года одним из разработчиков polyfill, принадлежащей компании Fastly. Поясняем: один из рядовых разработчиков компании, которой принадлежит проект polyfill, просто взял и продал проект новым владельцам (за что, скорее всего, получил хорошие деньги). Есть semgrep правило для поиска и замены вредоносных пакетов. Вот также полезный свежий ресерч.

#supplychain

Enhancing Automated Configuration Security Capabilities with OpenAI Grant Funding

OpenAI рассказала о 8 программах получивших грант Cybersecurity Grant Program, направленный на финансирование активностей по улучшению методик защиты с помощью AI. Здесь есть защита LLM от prompt-инъекций, использование AI для OSINT, автоматизация red team и тд.

Нам лично понравился и показался релевантным к каналу проект CoGuard. В исследовании команда CoGuard продемонстрировала использование OpenAI API для решения проблемы неправильной настройки ПО.

Основные этапы включали:

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

Использование LLM позволило автоматизировать и упростить добавление новых правил и поддержку актуальных конфигураций, значительно повышая эффективность процессов разработки и обслуживания программного обеспечения.

А еще у Cougard есть open-source тула для сканирования конфигурации внутри docker-образов и облачных ресурсов. Среди поддерживаемых Kafka, Tomcat, Kubernetes, MongoDB, MySLA, nginx , postgesql, helm, elasticsearch и другие.

#configuration #ai

В продолжении понедельничного поста...

#Юмор

OWASP Dep-scan

В чате участники нашего сообщества поделились проектом Dep-scan — инструментом поиска уязвимостей в зависимостях "нового поколения" от OWASP. Несмотря на то что инструмент не новый, известен он не так сильно как Dependency-Check и Dependency-Track.

Отличительная особенность данного инструмента — это предоставление возможности по приоритизации уязвимостей. Dep-scan добавляет к каждой уязвимости графу "Insights". Приоритизация осуществляется за счет так называемого Reachability анализа — анализа кода на предмет того, может ли уязвимый пакет быть затронут опасными методами, например, пользовательским вводом с помощью параметров requests или методов safecode. Механизм построен на базе проекта Atom и поддерживает Java, JavaScript, TypeScript и Python.

В проект также добавили режим аудита риска. Этот режим позволяет оценить степень рискованности npm или PyPI-пакетов с помощью заложенной разбивки весов. Баллы риска могут прибавляться, например, если у пакета всего два npm-пользователя, приватный пакет доступен в публичном реестре (привет атаки dependency confusion), либо пакет в принципе достаточно старый.

Среди фич авторы отмечают генерацию SBOM за счет интеграции с cdxgen, быстроту сканирования и количество поддерживаемых языков и форматов (Node.js, Java, PHP, Python, Go, .NET, C/C++, Docker, OCI image, YAML).

А какие SCA используете вы? И есть ли положительный опыт работ с импортозамещенными инструментами? Обсуждаем в комментариях и чате.

#sca

*И иллюстрация к предыдущему посту

2024 AppSec and DevSecOps Keynotes

На рубеже второй половины года мы решили подготовить подборку записей с известных конференций по безопасности, которых стало уже достаточно много. Каждая ссылка ведет на видеозаписи докладов 2024 года. В этом году на всех конференциях наблюдается значительный уклон в сторону безопасности AI и его применения в сфере безопасности на фоне стремительного развития этого направления.

RSA Conference 2024 - одна из крупнейших в мире конференций по ИБ, проводится ежегодно в Сан-Франциско. 300 докладов, включая, конечно же, AppSec и DevSecOps. Чтобы облегчить поиск наиболее релевантных докладов, в чате будут опубликованы ссылки на самые интересные выступления.

BSidesSF 2024. Вторая по известности конференция по безопасности. Совсем немного докладов про AppSec, но кое-что также в разрезе применения AI присутствует.

fwd:cloudsec 2024. Набирающая популярность конференция по безопасности облаков для тех, кому это актуально.

Cloud Native Security Con 2024. Конференция от CNCF охватывает в этом году не только темы безопасности контейнеров и контейнерных сред, но и также безопасность AI/ML, CVE, SBOMы.

phd2 2024. Та самая конференция в России, которая не нуждается в представлении. Кроме отдельного трека по безопасности разработки, есть треки, где так или иначе затрагивается тема AppSec, например, в контексте экономической эффективности.

Также очень ждем доклады от организаторов БеКон 2024 - конференции по безопасности контейнеров и контейнерных сред. Записей пока нет, но есть слайды.

Если вы знаете какие-то конференции релевантные к каналу с доступными записями, присылайте в чат!

#talks

Cloud Threat Landscape

У Wiz, известного вендора занимающегося решениями для безопасности облака, есть вполне достойный внимания ресурс для из изучения - Cloud Threat Landscape.

Что здесь можно найти?

Обновляемый перечень инцидентов с указанием задействуемых инструментов, технологий, группировок, способов получения доступа. Есть отдельная категория для атак на supply chain.

Группировки с ссылкой на инциденты и оперируемые техники.

Техники с ссылкой на ATT&CK тактики. Техники протегированы с разбивкой на облачные атаки, атаки на kubernetes, CI/CD и тд.

Инструменты, используемые при различных ранее известных атаках, упоминаемых в инцидентах, включая названия криптомайнеров, ransomware и тулкитов.

Технологии, на которые нацелены атаки (Docker, Confluence, Redis, Kuberentes и тд), включая способы обнаружения в них уязвимостей (Nuclei, Metaspolit, база CISA KEV)

Данный ресурс мало чем отличается от многочисленных awesome-подборок на github, которые никогда не успевают обновляться в след за появлением огромного количества новых статей, инструментов и техник. В некотором смысла данный ресурс даже хуже, так как полностью поддерживается вендором Wiz без участия сообщества 😅 Тем не менее, обойти данный ресурс мы не могли, ибо он может быть полезен при моделировании угроз для облаков. Кроме того, есть RSS-feed с публикацией атак и инцидентов.

А чем вы пользуйтесь при моделировании угроз?

#cloud

RedFlag

Сегодня на очереди очередной open-source инструмент на стыке AI и AppSec. Цель проекта RedFlag - отдать на AI анализ всех pull requests, чтобы отделить те, которые могут быть проигнорированы, и те, которым команде безопасности нужно уделить особое внимание при ревью. Вот, например, есть набор комитов в проект zed из 29 pull requests (PR), из которых RedFlag отметил 12 в своем отчете. Для одного из коммитов, который добавляет новую команду diagnostics, инструмент предоставил сводку, список измененных файлов, подсветил риск, связанный с модификацией логики обработки путей файлов, и порекомендовал протестировать новую команду на инъекции и directory traversal в рамках тест-кейса.

К инструменту также есть сопутствующая статья. Для того, чтобы инструмент оживить, необходимо подключить языковую модель Claude v3 Sonnet через Amazon Bedrock, а также обеспечить доступ к Jira, чтобы инструмент мог обрабатывать соответствующие тикеты. Далее в статье идет история успеха, где авторы анализировали релиз проекта своей организации, состоящего из 400 PR, из которых было отобрано около 100 PR. Стоимость такого анализа составила всего 8 долларов. В ходе девяти подобных релизов было обнаружено 6 высоких и 8 средних уязвимостей с точностью инструмента около 92%.

Интересен не столько сам инструмент, сколько его идея, простота реализации (это небольшой Python-проект, поддерживаемый двумя мейнтейнерами) и ощутимые результаты.

#ai

#Gartner #Architecture

Binary secret scanning helped us prevent (what might have been) the worst supply chain attack you can imagine

Если история с CrowdStrike – это реализовавшаяся катастрофа в цепочке поставок, то команде JFrog удалось предотвратить атаку, которая потенциально могла бы быть еще более ужасающей. В своей статье команда JFrog Security Research рассказывает, как в одном из публичных репозиториев Docker Hub был обнаружен легаси GitHub токен с админ-правами от репозиториев таких проектов, как python, pypa, psf и pypi. Обладатель данного токена теоретически мог бы скрыть вредоносный код в CPython, который является репозиторием некоторых основных библиотек, составляющих ядро языка программирования Python и скомпилированных из кода на C. Из-за популярности Python, вставка вредоносного кода, который в конечном итоге попадет в дистрибутивы Python, могла бы означать распространение бэкдора на десятки миллионов машин по всему миру.

Токен был найден в бинарном файле .pyc. Как это произошло?

1) Автор добавил авторизационный токен в исходный код.

2) Запустил исходный код (Python-скрипт), который был скомпилирован в бинарный файл .pyc с авторизационным токеном.

3) Удалил авторизационный токен из исходного кода, но не очистил .pyc.

4) Загрузил как очищенный исходный код, так и неочищенный бинарный файл .pyc в Docker-образ.

Какие выводы делают авторы статьи?

- В бинарных файлах тоже могут быть секреты, которые надо искать (отсылка на решение от JFrog).
- Убедитесь, что вы не используете старые GitHub токены (которые были заменены на новые, более безопасные, в 2021 году).
- Предоставляйте доступ к токенам с наименьшими правами.

Отчет об инциденте от самих PyPi можно найти здесь.

#secrets #supplychain

Phantom Secrets: Undetected Secrets Expose Major Corporations

Недавно мы затронули тему появления секретов в неожиданных местах, таких как бинарные файлы. Сегодня мы обсудим обнаружение секретов в удаленных ветках публичных репозиториев. В статье от Aqua исследователи рассказали, как они обнаружили около 18% пропущенных секретов в 50 000 публичных репозиториях, используя команду git clone --mirror вместо стандартного git clone. Авторы подробно объясняют разницу между выполнением этих двух команд и углубляются в нюансы кэширования на платформах управления исходным кодом (SCM).

Почему же ветки на самом деле не удаляются и извлекаются через git clone —mirror?

Если коротко, то удаленные ветки в Git не удаляются полностью, так как они могут быть полезны для восстановления данных или истории изменений. Это связано с тем, что Git, по своему замыслу, должен сохранять максимальную доступность и возможность восстановления данных даже после их удаления на локальном уровне. Когда вы удаляете локальную ветку, удаленные ветки могут оставаться в виде "висячих" ссылок на удаленном репозитории. Эти ссылки могут быть извлечены при использовании команды git clone --mirror, так как она клонирует все ссылки, включая те, которые были удалены локально. У этого явления даже есть оспариваемая CVE-2022-24975 (GitBleed).

Вывод достаточно простой: секрет, который однажды попал в репозиторий, можно считать автоматически скомпрометированным. Для многих использование данного подхода не будет чем-то новым. Соответственно, используйте функции защиты от случайных коммитов (push protection) от ваших SCM и pre-commit хуки, чтобы избегать появления секретов в репозиториях. Если это всё же произошло, то, согласно статье, техподдержка может помочь. Кстати, вслед за статьей Gitleaks и TruffleHog добавили поддержку сканирования через --mirror. Также советуем почитать рекомендации от GitHub - "Best practices for preventing data leaks in your organization".

А как эту проблему решаете Вы?

#secrets

Security Guardrails

Существует термин, введённый Джейсоном Чаном, бывшим директором по информационной безопасности Netflix, который называется "безопасная асфальтированная дорога" (secure paved roads). Этот термин используется в контексте интеграции безопасности таким образом, чтобы она оставалась невидимой. Предположим, разработчики пишут код или администраторы деплоят ресурсы в облако, не осознавая, что делают это безопасно, не придерживаясь при этом множества руководящих принципов.

Звучит как сказка, но в настоящее время это всё чаще обсуждается в контексте реализации так называемых Security Guardrails. Это достаточно общий термин, в рамках которого разработчикам и администраторам по умолчанию предоставляются заведомо безопасные функции, классы, ресурсы и механизмы для повседневной работы. Например, вот авторы статьи предоставили разработчикам кастомные классы Terraform CDK для создания ресурсов RDS. Вместо того чтобы создавать RDS с множеством мисконфигураций, как это обычно происходит, разработчики могут воспользоваться классом DatabaseInstance, в котором уже встроены шифрование, ограничение публичного доступа и другие меры безопасности. Затем они передают класс на исполнение функции generate_databases, и безопасники ликуют.

Развивая данную концепцию, мы приходим к ситуации, когда внутренним пользователям предоставляются исключительно безопасные по умолчанию утилиты, сервисы, механизмы SSO, аутентификации и авторизации, где пользователь заведомо не может сделать что-то неправильно. Это противоречит подходу большинства вендоров, которые стремятся сделать запуск сервисов максимально простым, не зная всех особенностей каждого заказчика. Соответственно, это приводит к поддержке команды безопасности, которая создает Security Guardrails под нужды организации, делая их, при этом, простыми в эксплуатации. Такие команды безопасности обрели название Security Platform Engineers, статьей про которых мы тоже решили поделиться в продолжении повестки. В России развитие таких команд особенно заметно на фоне стремительно появляющихся AppSec платформ, разрабатываемых in-house (привет Альфа-Банк, VK, Yandex и другие).

Это действительно интересная ниша, где видится появление большого количества стартапов. Например, Semgrep даже сделали бесплатный курс про Secure Guardrails, где они объясняют своё видение их применения в контексте своего инструмента.

Немного аналитики от Gartner: с правого края "повзрослевший" DevSecOps; слева "молодые" Policy as Code, AI ассистенты и прочее... Любуемся, прогнозируем, готовимся к выходным.

#Gartner #Hypecycle

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

AppSec != DevSecOps

Нашу команду часто подключают к процессам выстраивания безопасной разработки в компаниях. В свете продолжающихся изменений регуляторики будут ещё чаще. Помимо вопросов относящихся к специфике HR, существует пул hard skills задач, которые начинаются с четкого определения зоны ответственности человека и требуемых компетенций. Сегодняшний пост посвящен рефлексии и размышлениям о разнице между AppSec, DevSecOps и ProdSec на фоне неоднозначного видения этих ролей в компаниях, что часто приводит к недопониманию на интервью и затрудняет подбор подходящего сотрудника.

Все, что вы прочитаете далее, является субъективным рассуждением на основе эмпирики.

AppSec

Цель: Обеспечение безопасности приложения. Это отражено в KPI, включая количество найденных уязвимостей, охват тестируемых приложений и глубину анализа. В задачи входят анализ архитектуры, моделирование угроз, ревью кода и тестирование безопасности. Роль AppSec существует достаточно давно, с начала 2000-х годов, когда появилась организация OWASP. Хотя о результативности этой роли можно порассуждать, подробнее писали в относительно старом посте.

DevSecOps

Цель: Автоматизация процессов безопасности и интеграция безопасности в DevOps. В KPI входит адаптация инструментов безопасности в SDLC и автоматизация проверок безопасности на уровне CI/CD. Сюда часто включается безопасность платформ Kubernetes и облачных сервисов. Концепция DevSecOps начала формироваться в 2012-2014 годах.

Несмотря на явные различия в целях и задачах, часто можно встретить распределение ролей в командах, где AppSec-инженер в крупной компании, способной разделить ответственность, занимается встраиванием инструментов в CI/CD. При этом у инженера явный уклон именно в безопасность веба и мобильных приложений. В итоге мы видим, что внедрение произошло, но нередко оно выполнено неэффективно, не учитывая многие аспекты, к которым приходят опытные DevOps-инженеры. На рынке AppSec также существует множество кандидатов, приходящих на интервью с единственным опытом встраивания сканеров, многие из которых никогда не работали с инструментами вроде Burp Suite.

Product Security

Кто такие Product Security, о которых мы слышим все чаще последние 2-3 года, особенно на интернациональной рынке? Это команды, занимающиеся безопасностью продукта в целом, включая управление уязвимостями продукта и его инфраструктуры, а также облачную безопасность. Некоторые компании даже имеют команды Product Security как единственных специалистов по безопасности. ProdSec также тесно взаимодействует с Product Management, что нечасто встречается в AppSec. ProdSec интегрирует безопасность в жизненный цикл пользователя, внедряя MFA, историю входов, CAPTCHA и другие механизмы, тесно сотрудничая не только с dev и product, но и с маркетингом и другими бизнес-направлениями. Команде ProdSec, как и AppSec, не обязательно иметь в составе DevSecOps-инженера, который может существовать отдельно в команде DevOps.

Это зарождающееся разделение, где ProdSec получает больше доменов ИБ под управление, обусловлено, на мой взгляд, как и тесным переплетением слоев абстракций (cloud-native инфраструктура) так и непониманием старой школы инфраструктурных безопасников особенностей разработки и того, что нужно делать, чтобы быть гармоничным участником процесса. Любое изменение конфигурации в облаке, применение патча или правила на WAF может сильно повлиять на работу пользователя. Поэтому любое изменение для продуктов, независимо от инфраструктурного или прикладного слоя, может проходить аналогичный цикл SDLC, как и любое изменение кода.

P.S. И в этом процессе возникновения новых ролей можно разглядеть интересный элемент, дополняющий наш любимый shift left. Этакий shift right: когда приложения и процессы становятся все более сложными и запутанными, а мы чтобы приоритезировать необъятное фокусируемся прежде всего на опыте клиента, на том, что находится максимально справа. А затем "раскручиваем" то необходимое, что нужно для того чтобы его опыт состоялся (включая требования к ИБ и соответствие регуляторике).

#имхо

Container and Kubernetes Security Fundamentals

Я уверен, что многие из вас заметили, что мы редко затрагиваем вопросы безопасности Kubernetes и контейнеров, хотя обладаем соответствующей экспертизой. Поэтому вечерком, под чашечку расслабляющего чая, давайте преисполнимся оркестрации.... Мы не могли пройти мимо и решили опубликовать уже не новую, но постоянно обновляемую серию видео и статей от известного исследователя Rory McCune под названием "Kubernetes Security and Container Security Fundamentals" (ссылка на статьи). Материалы охватывают важные аспекты безопасности Kubernetes, включая его компоненты, а также такие механизмы безопасности контейнеров, как capabilities, namespaces, AppArmor, SELinux, cgroups и seccomp-фильтры.

В одном из последних материалов, опубликованных около двух недель назад, рассматривается вопрос авторизации в Kubernetes, включая модули авторизации (AlwaysAllow, AlwaysDeny, Node Authorizer, ABAC, RBAC) и авторизацию на уровне компонентов.

Rory McCune известен своими статьями еще с тех времен, когда работал в Aqua Security. Большую известность он получил как соавтор Kubernetes Benchmark и Docker Benchmark от CIS, а также как автор документа "Guidance for Containers and Container Orchestration Tools" для PCI DSS.

Этот курс идеально подходит для начинающих, а учиться никогда не поздно! Даже ночью 🙃

#k8s #docker #containersecurity

А между тем череда интересных митапов продолжается. Вот и Купер.тех (ex-СберМаркет) подготовил свой DevSecOps митап со спикерами из RuStore, Positive Technologies, Купер.тех (ex СберМаркет), SolidLab и MTS Web Services.

Дата: 21 августа в 19:00

Место: Москва, офис Купера + онлайн

На митапе будут представлены доклады на следующие темы*:

- Как выстроить DAST на Open-Source: гибкое использование Nuclei и ZAP под сервисы компании
- Вредные советов для вашего ASPM.
- Написали свою DSO-платформу, но все равно купили ASOC. Да как так-то?…
- Опыт тестирования Defect Dojo SASTами
- Какой должен быть SAST?

*по итогам каждого доклада и в афтерпати - обсуждение тем со спикерами

Зарегистрироваться на митап можно тут: это чтобы попасть в офлайн или чтобы не пропустить ссылку на трансляцию, если интересно присоединиться в онлайне.

#event #инфо

Harnessing LLMs for Automating BOLA Detection

Одна из самых распространённых уязвимостей в веб-приложениях — это broken access control. На сегодняшний день SAST и DAST бесполезны при их поиске, и всем известно, что выявление таких уязвимостей решается исключительно ручным тестированием с помощью плагинов для Burp, таких как Autorize, AuthMatrix, Authz.

Однако, недавно мы наткнулись на статью от Unit42 (Palo Alto Networks) о том, как они автоматизировали поиск уязвимостей типа broken object level authorization (BOLA) с помощью ИИ. В качестве входных данных используется спецификация OpenAPI, после чего механизм ищет потенциально уязвимые API, где происходит обращение к объектам (например, username, email, teamId, invoiceId, visitId). Далее строится дерево зависимостей между этими эндпоинтами и формируются тестовые кейсы, в которых инструмент пробует различные сценарии обращения к объектам на основе имеющихся доступов двух пользователей. Если один из пользователей имеет доступ к объектам другого, то существует высокая вероятность наличия уязвимости BOLA.

Звучит достаточно интересно и логично автоматизировать такого рода тестирования! В результате исследователи обнаружили уязвимости в Grafana (CVE-2024-1313), Harbor (CVE-2024-22278) и Easy!Appointments (целых 15 CVE). Они также отметили, что эксперименты показывают: обратная связь от людей постоянно улучшает точность и надёжность ИИ.

В конце статьи также много полезных ссылок на смежные исследования Unit42.

P.S. Кстати, вот еще один прекрасный пример поиска CVE с помощью LLM - анализ вылетов на предмет полезности при фаззинге браузера.

#ai