DevSecOps Talks

Обогащение информации по уязвимостям Всем привет! По ссылке можно найти repository, в котором содержится обогащенная информация по CVE. Проект и работа по нему курируется CISA. Если совсем просто, то CVE обогащаются информацией на основании SSVC scoring (наработки CISA, о которых можно прочесть тут). В «расширении» информации об уязвимости могут быть добавлены поля 🍭 Exploitation status 🍭 Technical impact 🍭 Automatable Зачем это может пригодиться? Например, для расстановки приоритетов в устранении уязвимостей, который, зачастую, дается очень не просто

Network Policy Templating с использованием Helm Всем привет! Продолжаем тему работы с сетевыми политиками. Сегодня хочется поделиться интересным и удобным подходом к их управлению. А именно – использованием Helm Template. В статье Автор предлагает следующее: 🍭 Создание сетевой политики, например, с использованием Cilium Network Policy Editor 🍭 Создание Helm Template на базе ранее созданной политики 🍭 Подготовка Helpers (podSelector, ingress, egress, cidr block и т.д.) 🍭 Тестирование! 😊 Все примеры и пояснения можно найти в статье. Но зачем использовать Helm? Все просто – политики могут отличаться в зависимости от ситуации, но «ядро политики» может быть одним. Поэтому может быть проще не создавать отдельные NetworkPolicy файлы, а осуществлять управление через разные Helm Values и Helpers.

Вакансия DevSecOps-инженера в Инфосистемы Джет. Всем привет! А вот и наша непостоянная рубрика "вакансии" :) Сейчас мы активно расширяем команду и ищем DevSecOps инженера. Перечень задач весьма обширный и обсуждается индивидуально исходя из ваших возможностей и предпочтений, но если коротко, то вот он: 🔹внедрение инструментов DevSecOps (SAST, DAST, Container Security, Secret Management, OSA\SCA, ASOC) 🔹формирование процессов безопасной разработки (проведение аудитов по фреймворкам BSIMM, SAMM, DAF, разработка документации и консалтинг) 🔹создание новых и совершенствование существующих в компании сервисов в части безопасной разработки Требования к кандидату, условия работы и наши ожидания: https://jet.su/career/vacancies/inzhener-devsecops/ Формат работы: гибрид с офисом в центре Москвы Резюме и вопросы присылайте в телеграм нашему HR @BigmanVictoria или в отклике на вакансию Если вы прочитали и подумали, что по каким-то параметрам не дотягиваете, то посмотрите на еще одну нашу интересную вакансию https://hh.ru/vacancy/96999601 ☺️

Cilium Network Policy: материал для погружения Всем привет! По ссылке можно найти весьма неплохую статью (~ 18 минут чтения) для погружения в Network Policy Kubernetes, которые можно реализовать при использовании Cilium. Начинается все достаточно «безобидно» - общие концепты про взаимодействие pod, про основные «поля» Network Policy (selector, direction, types и т.д.). Дальше становится интереснее Enforcement Mode, Application Discovery, Security Identity, использование Hubble для просмотра трафика между pods и, конечно же, возможные варианты troubleshooting. Все указанные концепции рассматриваются на примере небольшого приложения, для которого Автор описывает необходимые политики контроля сетевого трафика.

CyberCamp: прием заявок до 1-ого июня! Всем привет! Ранее мы писали про открытие Call For Papers (CFP) на CyberCamp – мероприятия, в котором соединяется теория и практика! CyberCamp проходит в online формате (как теория, так и практика) и собирает более 10 000 участников, объединенных любовью к информационной безопасности и тягой к знаниям. Если у вас есть что рассказать (по тематике безопасной разработки, DevSecOps и не только), то приглашаем вас откликнуться и стать частью CyberCamp 2024! Крайний срок подачи заявок – 1-ое июня 2024 года. Подробности можно найти по ссылке. Да, есть небольшая анкета, которую надо заполнить, но, обещаем, это не займет много времени! Спасибо и до встречи на мероприятии! ☺️

Как работает Kubectl? Всем привет! Если вам хоть раз доводилось «что-то» с Kubernetes, то вы точно использовали kubectl. Но задавались ли вы вопросом – а что именно она делает и как она устроена? Если нет, то рекомендуем прочесть статью, в которой описаны основные принципы работы этой удобной утилиты. Например: 🍭 Где и как она ищет kubeconfig 🍭 Почему и зачем в kubeconfig приведены именно эти параметры 🍭 Какие способы аутентификации она использует 🍭 Как можно воспроизвести (ну почти) ее действия с использованием обычного curl В завершении статьи Автор предлагает пойти дальше – скачать себе ее repo, посмотреть на исходный код и добавить собственную функцию

Управление секретами: Vault и External Secrets Operator Всем привет! «Среда – это маленькая пятница!» Сегодня так уж точно ☺️ Поэтому предлагаем вашему вниманию небольшую статью. В ней Автор рассматривает возможность динамического управления секретами в Kubernetes с использованием HashiCorp Vault и External Secrets Operator (ESO). Предлагается следующий алгоритм: 🍭 Установка Vault и ESO 🍭 Создание Read Token в Vault для настройки взаимодействия с ESO 🍭 Создание Secret Engines и Secrets в Vault 🍭 Создание External Secret, обновление Secret на стороне Vault, синхронизация с Secret в Kubernetes Ничего лишнего. Только примеры, screenshots, комментарии и конфигурационные файлы! А если хочется больше узнать про используемые в статье технологии – то в ней есть ссылки на все необходимое. И, пользуясь случаем, поздравляем вас с наступающими праздниками! Желаем отлично провести время, набраться сил и до встречи на следующей неделе! ☺️

Linux Exploit Education Всем привет! Скоро будут вторые майские праздники, в которые можно поучиться чему-нибудь новому! Предлагаем вам обратить внимание на проект «Exploit Education», который позволит углубиться в тонкости работы с Linux. Сами лабораторные работы представляют из себя набор виртуальных машин (увы, online не получится), в которых есть задания на различные тематики. Например: 🍭 Nebula. Повышение привилегий в Linux, состояние гонок в файловой системе, проблемы в scripting languages 🍭 Phoenix. Работа с дефектами, характерными для памяти 🍭 Fusion. Аналогично Phoenix, но предлагает более сложные сценарии В среднем, в каждой виртуальной машине содержится примерно 15 заданий. Уровень сложности варьируется – от Nebula к Fusion он повышается.

GitLab: CIS Benchmark Всем привет! В апреле этого года GitLab совместно с Center for Internet Security (CIS) выпустили CIS GitLab Benchmark (~ 301 страница), который можно найти в приложении. В документе содержится перечень рекомендаций для аудита и настройки механизмов безопасности при использовании GitLab. Рекомендации делятся на 5 глобальных блоков: 🍡Source Code (исходный код) 🍡Build Pipelines (среда и конфигурационный файл сборки) 🍡Dependencies (зависимости) 🍡Artifacts (артефакты) 🍡Deployments (конфигурационные файлы для развертывания приложения) Документ похож на CIS Benchmark for Supply Chain, который CIS выпускала ранее. Он может быть крайне полезен, если вы используете GitLab и хотите настроить его с учетом ИБ-практик

Vulnerability Management: ключевая проблематика и стоимость Всем привет! «Сколько, в среднем, стоит устранение уязвимостей в Компаниях?» - именно такой вопрос задала себе команда Chainguard (одним из направления деятельности, которых является создание минималистичных образов контейнеров, в которых уязвимостей значительно меньше, чем в «обычных»). Для того, чтобы ответить на этот вопрос Команда провела небольшое исследование, результаты которого можно найти в приложении. Если кратко, то: 🍭 Оценить время для tirage конкретной CVE затруднительно. Оно может варьироваться от 20 минут до нескольких недель 🍭 Большое количество действий при tirage. Обилие данных может привести к «открытию и чтению десятков вкладок» браузера, чтобы понять «что это есть на самом деле» 🍭 Shift Left не панацея. Уязвимости могут появляться ежедневно, поэтому управлять ими надо в «режиме реального времени» 🍭 Некоторые компании тратят тысячи часов на процесс управления уязвимостями. Грубо говоря, 1 и более сотрудников полноценно занимаются только этим в течение года Для того, чтобы избежать этих проблем Chainguard предлагает свой подход. Суть его, хоть и похожа, но отличается в корне – не исправлять уязвимости в образах контейнеров, а использовать образы, в которых количество уязвимостей сведено к минимуму. А что вы думаете по этому поводу? Имеет ли такой подход место быть и нужно ли стремиться к «zero tolerance»?