DevSecOps Talks
7.45K subscribers
88 photos
96 files
1.25K links
Рассказываем об актуальном в мире DevSecOps. Канал DevSecOps-команды "Инфосистемы Джет"
Download Telegram
AquaNautilus Container Attacks Catalog 2022.pdf
6.8 MB
Container Attacks Catalog

Всем привет!

Team Nautilus, являющаяся частью Aqua Security, подготовила отчет об атаках на среды контейнеризации за 2022 год.

В отчете можно найти:
🍭 Общую статистику, распределение по типам образов, используемых для атак, географию атак и т.д.
🍭 Образы контейнеров, которые чаще других использовались в атаках
🍭 Общее описание атак, включающее в себя: image name, impact, category, entry point и т.д.

В целом получилась интересная агрегации информации об атаках на контейнеры за 2022 год. Особенностью отчета является то, что это не теория. В качестве «подопытных» рассматривалась honey pot сеть, которая собирала данные с 1-ого января по 1-ое ноября 2022 года.
👍2
Всем привет!

Мероприятие не совсем про DevSecOps, но Linux - штука крайне полезная и никогда не будет лишним.

Поэтому будем рады, если Вы 21 декабря в 11:00 подключитесь к онлайн-трансляции. Разберем тему безопасности Linux с практической стороны. Бесплатно.

В программе:

🔹Безопасность ядра Linux: в теории и на практике
Александр Попов, главный исследователь безопасности открытых операционных систем, Positive Technologies

🔹Обзор популярных уязвимостей Unix
Владимир Ротанов, руководитель группы практического анализа защищенности, «Инфосистемы Джет»

🔹Харденинг Linux
Антон Велижанинов, старший инженер по ИБ, «Инфосистемы Джет»

🔹Особенности вредоносного ПО под Linux-системы
Ярослав Шмелев, вирусный аналитик, «Лаборатория Касперского»

🔹Разбираем кейс по форензике
Александр Матвиенко, руководитель группы защиты от утечек информации, «Инфосистемы Джет»

🔹Анализ логов в Unix-системах
Артем Крикунов, аналитик центра мониторинга и реагирования Jet CSIRT

Слушай доклады ➡️ Выполняй задания киберучений ➡️ Отрабатывай практические навыки в ИБ!

Регистрация по ссылке
🔥9👍4🥰1🐳1🌭1
OSV-Scanner: Vulnerability Scanner for Open Source

Всем привет!

13 декабря 2022 года Google представили в общий доступ собственную разработку – OSV Scanner, задачей которого является поиск уязвимостей в open source компонентах.

Активность тесно связана
с Open Source Vulnerabilities (OSV) – проектом, представленным Google в предыдущем году и представляющим из себя базу данных по уязвимостям.

OSV-Scanner позволяет:
🍭 Анализировать Lockfiles, SBOMs
🍭 Получать результаты по анализу уязвимостей из OSV (в которой находится более 38 000 advisories, согласно данным Google)
🍭 Анализировать пакеты в Debian-based образах контейнеров

Кроме того, OSV-Scanner интегрирован в OpenSSF Scorecard’s Vulnerability Check. Дальнейшие планы по развитию – доработка для более удобной интеграции с CI, улучшение работы с C/C++ и поддержка VEX.
Управление уязвимостями образов контейнеров от Lyft

Всем привет!

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

Команда создала собственный концепт, который строится на идеях:
🍭 Самостоятельное устранение уязвимостей там, где это возможно (spoiler: почти не работает). Постановка задач на устранение только в том случае, если у уязвимости есть fix
🍭 Автоматизация всего, чего только можно
. Заодно можно будет узнать, почему ребята перешли с Clair на Trivy
🍭
Что делать, если в компании используется базовый образ, на основе которого могут строиться остальные? Как сделать так, чтобы обновление получили все?
🍭 Единое окно
по сбору информации об образах и уязвимостях. DefectDojo! Нет, не в этот раз. Предпочтение отдали Cartography
🍭 Анализ только того, что используется. Общее количество образов оценивалось в 400 000, «активных» образов – 4 000

Очень много интересных размышлений, описание проблематики с которой можно столкнуться и возможные варианты решений на уровне идей. А реализация идей будет описана во второй статье, посвященной тому, как именно Lyft автоматизировали созданный ими концепт. Ждем!
👍5
isovalent_security_observability.pdf
2.9 MB
Security Observability with eBPF

Всем привет!

Еще один материал от Isovalent, посвященный использованию eBPF. На этот раз рассматривается тема observability и чем eBPF может быть полезен.

В книге (~ 65 страниц) всего 4 главы:
🍭 The lack of Visibility
🍭 Why is eBPF the Optimal Tool for Security
🍭 Secuity Observability
🍭 Security Prevention

Материал обзорный и отлично подойдет для знакомства с eBPF
и ее возможностями для Security. Про еще один материал от Isovalent, посвященный рассматриваемой технологии, мы писали тут.
🔥2
Kyverno: Use Cases

Всем привет!

Статья от Compass, в которой приводятся сценарии использования Kyverno. Отличительной особенностью является то, что приведены все три «ключевые возможности» - Validating, Mutating и Generating.

Рассматриваются примеры:
🍭 Validate: анализ Ingress-правил на наличие «дубликатов»
🍭 Mutate: установка timeout-параметров для liveness/readiness probes
🍭 Generate: создание Vertical Pod Autoscaler (VPA)

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

Еще про один интересный пример использования Kyvernoанализ подписи образа контейнера и его аттестации – мы писали тут. И, как обычно, больше информации можно найти в документации. А что предпочитаете Вы? Kyverno/Gatekeeper/Иное?
🔥5
Kubernetes Labels: best practice

Всем привет!

Kubernetes Labels – крайне удобный инструмент, который позволяет управлять группами ресурсов с использованием «фильтров». В статье приводится краткое описание механизма, его отличия от Annotations, сценарии использования Labels и набор советов о том, как ими лучше пользоваться.

Например:
🍭 Использование рекомендуемых Labels согласно документации Kubernetes
🍭 Формирование Label Naming Convention
🍭 Не указывать sensitive
информацию в Labels
🍭 По возможности автоматизировать процесс назначения Labels и другие

Labels могут быть полезны не только DevOps командам, но и Security специалистам. Например, для применения Network Policies.
D2Lang: Diagram as Code

Всем привет!

Есть много разных инструментов для «программирования диаграмм и схем». Суть простая – описываем связи в виде кода, а решение строит схему.

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

Сегодня пост посвящен D2Lang, который:
🍭 Обладает простым синтаксисом
🍭 Может быть интегрирован в VS Code, Vim и Obsidian в качестве плагинов
🍭 Добавлять необходимые значки/иконки «на лету»
🍭 И многое другое, с чем можно ознакомиться в документации

Можно не ставить сразу, а использовать playground и посмотреть, что к чему. Если интересно, какие еще есть инструменты, то можно обратиться к этому посту, в котором собраны наиболее часто используемые инструменты.

А если возникнет вопрос – «Еще один подобный инструмент, в чем разница с XXX?», то есть ответ от разработчиков.
🔥8
DevSecOps Roadmap

Всем привет!

Давно мы не публиковали awesome-подборок или их аналогов. Быть может под Новый Год самое время – вдруг кто-то ищет, что можно почитать/изучить на выходных?

Поэтому предлагаем обратить внимание на DevSecOps Roadmap, в котором собраны полезные материалы для всех этапов:
🍭 Design. SDL, SAMM, BSIMM и аналоги
🍭 Develop. Secure coding
🍭 Build. SAST
🍭 Test. DAST
🍭 Deploy. Hardening, security scanning
🍭 Security for CI/CD. GitHub Actions, Jenkins

Также в repo можно найти ссылки на другие аналогичные awesome-проекты, посвященные общему взгляду на DevSecOps.
🔥8👍1
CNCF Landscape Navigator

Всем привет!

Наверное каждый, кто интересуется темой DevSecOps и Cloud Native рано или поздно открывает для себя CNCF Landscape. Количество разнообразных инструментов ошеломляет, и даже группировка по тематикам не всегда помогает найти ответ на вопрос «что выбрать?».

Интересный подход придумали ребята из InfraCloudCNCF Landscape Navigator! Суть крайне простая:
🍭 Выбираете тему: Monitoring, Logging, Security, Service Mesh и т.д.
🍭 Отвечаете на несколько простых вопросов о том, что для Вас важно
🍭 Получаете результат – перечень инструментов и % насколько он Вам подойдет

Может быть полезно, если Вы только начинаете выбирать технологии или для того, чтобы найти «ту, которую Вы могли пропустить» в этом невероятном перечне.
👍6
GitOps_Cookbook.pdf
17.7 MB
GitOps Cookbook

Всем привет!

В приложении доступна книжка GitOps Cookbook от RedHat! Обзорный материал на тему использования Git для CD процессов: инструменты, подходы и советы.

Книга разделена на главы:
🍭 Введение. Что такое GitOps и зачем он нужен, какие проблемы решает
🍭 Containers. Различные подходы к сборке образов
🍭 Kustomize. Обзор инструмента и его ключевых возможностей
🍭 Helm. Charts, packages и все, что с ними связано
🍭 ArgoCD. Автоматизация CD процесса, использование ранее упомянутых инструментов
🍭 Advanced Topics. Шифрование, управление несколькими кластерами

В книге ~245 страниц, которые дают неплохое представление о том, какие есть практики, подходы и инструменты автоматизации для реализации GitOps.
🔥4
Kubent: поиск deprecated API

Всем привет!

При обновлении кластера Kubernetes может много чего произойти. В том числе, нарушение работоспособности из-за изменений в API. Отслеживать их не всегда удобно, особенно если кластер большой и/или их много.

Kubent (Kube No Trouble) – утилита, которая может помочь. Ее задача – поиск deprecated API. При помощи нее можно:
🍭 Анализировать локальные манифесты (в том числе можно использовать в CI)
🍭Анализировать используемые helm-chart
🍭Анализировать ресурсы кластера через last applied configuration

Больше про возможности Kubent, параметры запуска и сценарии использования можно узнать в readme.md проекта.
👍3
Друзья, поздравляем с Наступающим Новым годом!

Желаем вам всего самого доброго и светлого: мира, любви и процветания!

Дотроньтесь до мешка с подарками нашего DevSecOps Санты и это принесет вам счастье в новом году: ресурсы будут выдаваться по щелчку пальцев, системы работать непоколебимо, деплой будет мгновенным, а код — безопасным.

Мы рады, что вы с нами)
Отличного отдыха и до встречи в 2023!


С любовью,
Jet DevSecOps Team
❤️
🎉115🎅2❤‍🔥1🤩1🍾1🎄1
Доброе утро!
Крутая вакансия, чтобы начать с нового года новую жизнь

Мы находимся в поиске Руководителя DevOps направления, который выстроит позиционирование нашей экспертизы внутри компании и на внешнем рынке.

В круг задач будет входить активная пресейловая деятельность, продвижение направления DevOps, а также координация технических специалистов, вендоров и дистрибьюторов.
Подробнее о вакансии: https://hh.ru/vacancy/73999701

Задать вопрос и направить резюме можно нашему HR Валентине, ее TG: @valenciyani
🔥8👍1👎1
SecretDiver: поиск секретов в контейнерах

Всем привет!

SecretDiver – минималистичная утилита, у которой лишь одна задача – поиск секретов в образах контейнеров, слой за слоем.

Анализ осуществляется на основании правил, с которыми можно ознакомиться тут. Со слов Разработчиков – «If you want to use your own rules (and then create a PR so everyone can enjoy them) just run the command with the -generate-settings flag which will create a file ./settings.yaml in your directory».

Возможно анализировать образы локально (в том числе в виде *.tar) или из repo. Ну и не забывать про флаг -human для получения результата, доступного для понимания человеку ☺️
👍1
Caretta: визуализация сети k8s

Всем привет!

Иногда бывает полезно посмотреть на то, как сервисы приложения взаимодействуют между собой. Для этого можно использовать несколько подходов, например, связку Caretta + Grafana.

Первая собирает информацию о сетевом взаимодействии при помощи eBPF, а вторая – позволяет визуализировать информацию и делать интересующие пользователя запросы. Например: роль сервиса (клиент/сервер), по какому порту идет взаимодействие, тип (ресурс k8s, узел, "внешние") и т.д.

Приятно, что в таком сценарии кластер Kubernetes никак не «модифицируется» и влияние на него минимально.

Если вам интересно, что из себя представляет Caretta «изнутри», то рекомендуем ознакомиться с этой статьей, в которой описаны основные принципы работы утилиты и ее логика.
👍4
Атаки на distroless-образы

Всем привет!

Distroless образы отлично помогают ИБ за счет сокращения поверхности атаки. В них содержится только приложение и его runtime-зависимости. Никаких пакетных менеджеров и различных shells!

Если проанализировать их при помощи сканеров, то можно наблюдать приятную картину – количество уязвимостей в них в разы меньше, чем в «обычных». И, как правило, это уязвимости в исполняемых файлах.

Но все ли так хорошо и можно ли утверждать, что «Я использую distroless и этого достаточно?».

В статье разбирается пример с distroless образом для Golang:
🍭 Создается обычное приложение, которое печатает "Hello world" с интервалом в одну секунду
🍭 Приложение «упаковывается» в контейнер с FROM gcr.io/distroless/base
🍭 Контейнер запускается, все работает, bash недоступен, но… есть интерактивная командная строка openssl позволяющая выполнять команды

Как этим можно воспользоваться описано в статье. Получается, что не существует ничего абсолютного или защищенного "по умолчанию". Несомненно, если есть возможно выбрать distroless, то это стоит сделать. Но не стоит забывать и о других ИБ-контролях.
👍6🤡1
Автоматическое устранение уязвимостей в образах контейнеров

Всем привет!

Интересный подход к автоматическому устранению уязвимостей в образах контейнеров предложили авторы Copacetic.

Утилита делает следующее:
🍭 Берет результаты сканирования Trivy, определяет потребность в обновлении пакетов с использованием соответствующих менеджеров - apt, apk, yum и т.д.
🍭 Скачивает все необходимое и обновляет образ с использованием buildkit

Такой подход позволяет не собирать образ «заново», а именно обновлять его. Это в значительной степени сокращает вероятность того, что что-то сломается и пойдет не так после обновления. Но все равно лучше перепроверять и не полагаться на одну лишь автоматизацию.

В планах по развитию поддержка Grype в качестве альтернативы Trivy; «поддержка работы» с пакетными менеджерами языков программирования (pypi, npm, maven); расширение возможностей по конфигурации реализуемых обновлений.

Для работы утилиты нужно установить несколько зависимостей, которые описаны тут. И, конечно же, если хочется попробовать самому, то есть небольшой пример. А заглянуть «под капот», то можно по этой ссылке.
👍3
Контроль configuration drift в контейнерах

Всем привет!

В repo можно найти оператор, который позволяет контролировать configuration drift в контейнерах.

Работает все достаточно просто:
🍭 Пользователь осуществляет exec в контейнер
🍭 Запрос регистрируется kube-apiserver, pod’у контейнера проставляется label
🍭 После установленного времени k8s удаляет pod, у которого есть определенный label

Вот и все 😊 Работает не только с exec, но и с другими «интерактивными» запросами (attach, cp и т.д.). Для kubectl предусмотрен специальный плагин, который упрощает чтение label, содержащего информацию о том кто совершал операцию, когда и сколько еще осталось «жить» pod’у.
👍1
Как происходит удаление pod?

Всем привет!

Есть много разных статей в стиле «what happens when…». Например, что происходит при использовании команды kubectl apply -f smth.yaml.

Сегодняшняя статья рассказывает про то, что происходит при kubectl delete pod. Например, как k8s понимает, что надо ограничить трафик к «умирающему» pod? Как реализовать graceful shutdown и т.д.

Процесс выглядит следующим образом:
🍭 Обновление записи в etcd: добавление deletionTimestamp, deletionGracePeriodSeconds. Pod получает статус terminating
🍭Удаление endpoint pod из соответствующих services
🍭kubelet останавливает pod, api-server удаляет запись о pod’е из etcd

В статье все расписано более детально, уточнены нюансы: например, зачем нужен grace period. В завершении статьи представлены эксперименты с различными параметрами процесса удаления pod’a.
👍5
Пример моделирования угроз с использованием Systemic Approach

Всем привет!

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

Подход оперирует следующими терминами:
🍭 Boundary. Определение той части/компонентов системы, для которых будет реализовано моделирование. В примере Автор «привязывает» их к user story – отправка уведомлений – и рассматривает угрозы, применительно лишь к этому сценарию
🍭 Abstraction levels. Постепенное «погружение» в систему. Сперва – общий взгляд и все большая детализация при дальнейшем анализе. Применяется к выбранному boundary
🍭 Perspectives. Рассмотрение системы с точки зрения защищающегося или атакующего. В примере Автор берет STRIDE и расписывает возможные сценарии

Получается нечто вроде моделирования угроз «по спирали» - от общих абстракций до вполне себе конкретных мер. Рекомендуем прочесть статью, если Вам интересно ознакомиться с концептом Systemic Approach подробнее. Важно – там будет описание идеологии и подхода, но никак не детальный how to. Ведь как видно из примера выше – сделать такое универсальным вряд ли получится.