Обновление DevSecOps Assessment Framework (DAF)

Всем привет!

Настала очередь обновления DAF и вот основные изменения нового релиза:
🦴 Появился маппинг DAF на DSOMM
🦴 Появился маппинг DAF на ГОСТ 56939-2024
🦴 Актуализировался маппинг DAF на BSIMM и SAMM
🦴 Появился автомаппинг DAF на PT Table top, SAMM и DSOMM. Работает так: вы заполняете практики в основной вкладке с практиками DAF (Вкладка "Маппинг со стандартами"), а эти же данные, но в разметке PT Table top, SAMM и DSOMM появляются на соответствующих вкладках. Таким образом, проводя аудит по DAF, вы проводите аудит сразу по еще трем другим фреймворкам
🦴 Дополнили вкладку с документами по безопасной разработке - теперь тут есть документы из ГОСТ 56939-2024
🦴 Актуализировали расчет FTE AppSec. Теперь расчеты более приближены к реальности
🦴 Скорректировали текст практик, добавили новые, переместили некоторые практики между уровнями, убрали и добавили новые опечатки

Наш фреймворк становится все более структурированным и комплексным. Качайте новую версию, анализируйте её и свои процессы безопасной разработки!

Как вы можете заметить, бо́льшая часть практик ГОСТ 56939-2024 и PT Table Top есть в DAF. Наш фреймворк вышел в сентябре 2023 года, и если вы ему следовали, то уже соответствуете новому и ГОСТ и Table Top 😉

Мы всегда открыты к обратной связи и ждем новых контрибьюторов!

Обнаружение угроз с Falco!

Всем привет!

Сегодня рассказываем про объемную статью (~ 17 минут), посвященную обнаружению угроз в Kubernetes с использованием Falco.

Начинается статья, как обычно, с описания нюансов идентификации угроз в средах контейнеризации и краткого введения в Falco.

Далее Автор рассказывает про:
🍭 Как Falco обнаруживает угрозы, что есть правила
🍭 Способы установки Falco
🍭 Создание собственных правил для обнаружения угроз
🍭 Настройка оповещений, использование Falcosidekick
🍭 Примеры использования Falco из реальной практики
🍭 Сравнение Falco с другими решениями и не только

В итоге имеем отличный материал для знакомства с Falco.

Если хочется еще больше структурированной информации по решению, то рекомендуем обратиться к Falco from A to Y (про него мы писали тут).

ШТУРВАЛЬЧИК?

Ребятам из «Лаборатории Числитель», видимо, было мало шуток про Штурвал, теперь они выпустили Штурвальчик.

Многие говорили, что он слишком много жрёт. Теперь минимальный конфиг — это:
▪️один хост с 6 CPU
▪️8 ГБ RAM
▪️80 ГБ хранилища

В целом на мощном ноуте можно раскатать парочку кластеров куба — этого хватит на управляющий и несколько клиентских.

Вопросы можно в Kubernetes-чате «Штурвала» задать.

HackList: рекомендация по обучениям!

Всем привет!

Не знаете, что изучить на выходных? Не хочется самостоятельно искать материалы по интересующим вас темам?

Возможно, что HackList сможет вам помочь. Он представляет из себя небольшое web-приложение, которое ищет материалы по интересующим вас темам.

Внутри:
🍭 Рекомендации, сформированные с использованием AI на основе ваших интересов
🍭 Поиск по разным источникам: GitHub, OWASP, блоги, обучающие платформы
🍭 «Встроенный dataset» для быстрого получения информации
🍭 Категорирование проектов по разным ИБ-темам
🍭 Дедупликация результатов и приятный UI

Работает очень просто: вы описываете то, что вам интересно. HackList ищет разные проекты и статьи по теме. Читаете описание и начинаете обучение ☺️

Поддерживается около 15 различных ИБ-доменов, в том числе API Security, Mobile Security, DevSecOps и не только.

Nova: поиск устаревших Helm Charts

Всем привет!

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

Да, есть специализированные решения, которые могут помочь управлять версиями. Например, тот же Helm. Однако, даже с ним, не всегда получается за всем уследить.

Именно эту проблему и решает Nova – open source проект от команды Fairwinds.

Работает максимально просто:
🍭 Устанавливаем
🍭 Запускаем nova find
🍭 Анализируем результаты

В качестве выходных данных Nova предоставляет информацию об установленной версии chart’a и его latest-версии.

Кроме того, можно посмотреть устаревшие версии образов контейнеров, которые используются в chart’e.

Больше информации об утилите и ее возможностях можно узнать в документации.

Поиск уязвимостей в Helm Charts

Всем привет!

В предыдущем посте мы писали о том, как можно искать устаревшие версии используемых Helm Chart’ов.

А как быть с уязвимостями в них? По крайней мере в public-версиях chart’ов, которые используются? Например, есть ли там ошибки конфигураций или уязвимости?

Ответ на этот вопрос можно найти в статье от Cloudsmith.

Автор использует open source инструменты, такие как Trivy и OPA для анализа chart’ов до их активного использования в промышленных средах.

Помимо этого, Автор рекомендует всегда проверять репозиторий, в котором хранится chart. Обращать внимание рекомендуется на: поддержку, использование, автора.

В завершении статье можно найти несколько сценариев, описывающих возможные способы эксплуатации уязвимостей в Helm Chart.

Безопасность Golang parsers

Всем привет!

Разбор (parsing) данных, получаемых от непроверенных источников, может привести к разным последствиям.

Например, обходу аутентификации, нарушению авторизации, эксфильтрации чувствительных данных и не только.

В статье Trail of Bits Авторы исследуют насколько хороши различные Golang parsers с точки зрения информационной безопасности: можно ли им доверять по умолчанию, можно ли их делать более безопасными и что (не) следует использовать.

Для анализа используется несколько наиболее популярных библиотек для работы с JSON, XML и YAML.

После небольшой вводной про Marshalling и Unmarshalling Авторы переходят к самому интересному – сценариям атак.

Рассматривается:
🍭 (Un)Marshalling unexpected data
🍭 Parser differentials
🍭 Data format confusion

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

Завершает статью набор общих рекомендаций о том, как минимизировать риски при работе с JSON, XML, YAML.

Множество примеров, кода, пояснений! Рекомендуем к изучению!

EoL или End Of Life

Всем привет!

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

Если мы говорим про одну технологию, то это достаточно просто. Если их десятки и сотни, то становится в разы сложнее.

Хочется чего-то централизованного, удобного и автоматизируемого. Например, endoflife.date. Это ресурс, на котором собрана информация о различных релизах и их «актуальности» с точки зрения поддержки.

На сайте представлена информация о Ansible, Nginx, Redis, Argo CD, Kubernetes, Kyverno, SonarQube и не только.

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

Автоматизация тоже возможна: есть минималистичный API, через который можно получить всю нужную информацию, доступную на сайте.

Данные о Supply Chain атаках

Всем привет!

Автор репозитория проделал отличную работу и собрал информацию об общеизвестных Supply Chain атаках.

В наборе данных приведена информация о 56 OSS проектах и 59 инцидентах.

Для каждого случая есть своя «карточка» (конечно же в формате *.yaml!):
🍭 Наименование
🍭 Синопсис
🍭 Дата «реализации»
🍭 Ссылки на материалы по теме
🍭 Информация по артефактам и не только

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

Если хочется посмотреть «на все сразу», то в корне проекта есть oss_summary.csv, в котором представлена консолидированная информация.

🚀 Шерлок прокачивает управление ИБ-дефектами!

24 июля в 11:00 мск приглашаем на вебинар по новому релизу «Шерлока» — AppSec-платформы, которая оптимизирует процессы безопасной разработки.

На вебинаре расскажем:
🐾 О возможностях Шерлока для автоматизации
🐾 О новом функционале платформы
🐾 Проведем живое демо и ответим на все ваши вопросы

📌 Успейте зарегистрироваться! 👇
👉 РЕГИСТРАЦИЯ НА ВЕБИНАР

Application Security Introduction

Всем привет!

Начинаем новую рабочую неделю с плавного погружения в Application Security.

В приложении можно найти материал (~ 73 страницы), в котором описаны основы Application Security.

Например:
🍭 Те самые известные атаки (XSS, CSRF, SQLi, DDoS, IDOR и т.д.)
🍭 Secure Software Development Process (SAMM, BSIMM и т.д.)
🍭 Security Requirements Engineering
🍭 Security Design и не только

Неплохой обзорный материал, в котором собраны основные концепты, методологии, подходы и практики.

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

Уязвимости OAuth и что с ними делать

Всем привет!

Open Authentication (OAuth) повсеместно используемый способ аутентификации, в котором вместо логина и пароля используется токен.

Однако, как и любая технология, OAuth не лишена недостатков и, если реализовать ее некорректно, это может привести к уязвимостям.

Именно им и посвящена статья от Outpost24. В ней автор рассматривает:
🍭 Open redirect and redirect URI manipulation
🍭 Missing or weak CSRF/state protections
🍭 Implicit flow and lack of PKCE (Proof Key for Code Exchange)
🍭 Inadequate scope validation and overly broad permissions
🍭 Token leakage via insecure storage or transport и не только

Для каждого сценария приводится краткое описание недостатка и способы его устранения (корректной реализации).

Кстати, на сайте Outpost24 можно найти еще много чего интересного по тематике Application Security.

Kubetail – logging dashboard для Kubernetes

Всем привет!

Если для анализа логов в моменте нужно что-то легковесное, небольшое, простое в эксплуатации, то можно познакомиться с Kubetail.

Эта утилита позволяет анализировать журналы, генерируемые в кластере Kubernetes, в режиме реального времени.

Состоит Kubetail из CLI-утилиты и интерактивного dashboard, который можно установить как локально, так и в кластере Kubernetes.

Возможности, хоть и не велики, но практичны:
🍭 Агрегация данных по разным типам ресурсов Kubernetes
🍭 Возможность фильтрации событий
🍭 Переключение между несколькими кластерами
🍭 Указание временного диапазона для отображения информации о логах и не только

Больше подробностей можно прочесть в документации.

Кстати, если хочется посмотреть, как это выглядит, то у Kubetail есть интерактивная демо-площадка, доступная вот тут.

Библиотека Validating Admission Policies

Всем привет!

В репозитории можно найти набор Validating Admission Policies в формате CEL, подготовленных командой ARMO.

За основу при разработке политик был взят перечень ИБ-контролей, используемый в Kubescape.

Примеры того, что есть в репозитории:
🍭 Forbidden Container Registries
🍭 Automatic mapping of service account
🍭 Writable hostPath mount
🍭 Naked PODs
🍭 Image pull policy on latest tag и другие

На текущий момент доступно 33 политики. Для каждой из них доступен манифест и тестовые данные, которыми можно воспользоваться для проверки работоспособности политик.

Использование Validating Admission Policies может быть целесообразно в том случае, если вы не хотите использовать сторонние решения (Kyverno, Gatekeeper и их аналоги) и полностью использовать функционал, доступный в Kubernetes.

Вредоносный код в `is`

Всем привет!

Еще один пример атаки на цепочку поставок ПО. На этот раз «героем» стала is - достаточно популярная JavaScript библиотека (2.8 млн загрузок в неделю).

В нее было встроено вредоносное ПО, которое собирало различную информацию (имя, ОС, сведения о CU и т.д.) о рабочей станции, на которой оно запускалось, и передавала данные «наружу» через websocket.

Если кратко, то:
🍭 Учетные данные maintainer’a были скомпрометированы с использованием phishing
🍭 Злоумышленники сменили owner’a, что оставалось незамеченным несколько часов
🍭 В is был добавлен вредоносный код

Подмена была обнаружена достаточно оперативно и уже устранена: уязвимая версия – v3.3.1 – уже удалена, после чего уже легитимные авторы разместили обновленный вариант – v3.3.2.

Рекомендации постепенно становятся классикой: понимать из чего именно собирается ПО; контролировать то, что попадает в периметр; не забывать, что весь код (и заимствованные библиотеки тоже) - это всё ваш код, который надо анализировать; делать все это на регулярной основе.

P.S. Больше подробностей об инциденте можно узнать из статьи и ссылок, которые в ней доступны.

OpenCVE: управление информацией об уязвимостях

Всем привет!

OpenCVE – проект, который позволяет управлять данными о CVE, получаемыми из различных источников (NVD, RedHat, MITRE, Vulnrichment и т.д.)

Из ключевых функций можно выделить:
🍭 Наличие интерактивного графического web-интерфейса
🍭 Возможность «подписки» на определенные CVE с последующим получением уведомлений об изменениях
🍭 Получение комплексной информации об уязвимостях
🍭 Отслеживание истории изменения CVE
🍭 Создание собственных дашбордов
🍭 Интеграция с используемыми сервисами через API/Webhook и не только

Решение платное, но есть бесплатный вариант с некоторым (не критическим) ограничением по функционалу.

Установка возможна как в облаке, так и on-premise.

Больше информации об OpenCVE можно найти в GitHub-репозитории проекта и в документации.

Zeropod: оптимизация потребления ресурсов в Kubernetes

Всем привет!

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

При этом они потребляют ресурсы, которые могут быть нужнее «соседу». Как быть? Например, делать scale down до 0. И именно это и делает Zeropod.

Если просто, то по истечении некоторого времени от последнего TCP-соединения, он делает checkpoint (используя CRIU) и scale down до 0.

После, если TCP-соединения появляется вновь, pod восстанавливается и продолжает работу. Для пользователя это происходит «бесшовно». При этом реализуется оптимизация использования вычислительных ресурсов кластера Kubernetes.

Более детально процесс и логика работы Zeropod описаны в GitHub-репозитории проекта. Помимо этого, в repo можно найти информацию по установке, настройке и возможностях утилиты.

Важно: концепт, возможно, и интересный, но использовать такое "у себя" лучше после плотного тестирования ☺️

А как вы думаете, есть ли в этом смысл или "нет, очень опасно и зачем оно вообще нужно"?

Open Source Project Security Baseline

Всем привет!

Еще один проект от OpenSSF, цель которого – снижение количества потенциальных уязвимостей за счет внедрения практик и повышение доверия пользователей к рассматриваемому проекту.

Материал содержит практики 3-х уровней: общие рекомендации (для всех) и отдельно для проектов, у которых (не) очень много пользователей.

Всего порядка 50 рекомендаций. Например:
🍭 Когда был выпущен релиз, то должна обновиться и документация
🍭 Должна вестись запись всех изменений (само изменение, Автор, дата)
🍭 Для каждого проекта должен быть указать контакт по вопросам ИБ
🍭 Перед тем, как принять изменение, необходимо убедиться, что тесты пройдены и функционал соответствует ожиданиям
🍭 Все релизные объекты должны быть однозначно «связаны» с релизом и многое другое

Указанные практики можно использовать, например, при оценке надежности open-source проекта или использовать у себя (да, применимы далеко не все, но можно найти вполне интересные).

Помимо этого, для каждой практики кратко описано зачем она нужна (какой риск она сокращает), приведен небольшой набор рекомендаций и соотношение с иными стандартами и фреймворками (SSDF, PCI DSS, SAMM и т.д.)