Implementation of DevSecOps for a Microservices-based Application with Service Mesh - SP 800-204C (Draft)

Сначала в эту историю влетели NSA и CISA, а теперь время пришло и для NIST. Вышел драфт документа SP 800-204C "Implementation of DevSecOps for a Microservices-based Application with Service Mesh" о внедрении DevSecOps в связке с Kubernetes.

#k8s #ops #dev

Introducing Snowcat: World’s First Dedicated Security Scanner for Istio

Snowcat - инструмент для аудита конфигурации Istio на предмет безопасности. В основу взята официальная страница Istio Security Best Practices. На текущий момент инструмент поддерживает:
- проверку наличия mTLS,
- поиск небезопасных паттернов политики авторизации (доступность эндпоинтов без авторизации),
- проверку контроля сертификата при egress-трафике
- проверку политики JWT-токенов ( first-party-jwt / third-party-jwt) для корректного контроля получателя
- поиск небезопасных версий Istio

Для поиска мисконфигураций инструмент может быть натравлен на yaml-файлы в качестве статического анализатора кода, XDS-порт, kubelet API или Istiod debug API без аутентификации. Подробнее об инструменте можно прочитать в блоге.

#ops #k8s

RBAC Tool For Kubernetes

RBAC-tool - инструмент от Alcide (которую недавно приобрела широкоизвестная Rapid7), позволяющий формировать RBAC-роли в Kubernetes по результатам анализа audit events (в основу был взят движок audit2rbac), строить карту ролей и выявлять небезопасные роли.

#k8s #ops

Common Threat Matrix for CI/CD Pipeline

В рамках доклада “Attacking and Securing CI/CD Pipeline” на конференции CODE BLUE 2021 Opentalks вышла матрица угроз MITRE ATT&CK для CI/CD: Threat Matrix for CI/CD Pipeline. Частично она переиспользует идеи, предложенные SLSA, расширяя перечень потенциальных угроз и мер безопасности. Про многое я писал в серии постов по моделированию угроз CI/CD [1,2,3] и возможности извлечения секретов из CI.

Очень понравился перечень мер безопасности, который сильно пересекается с тем, что прорабатывал я в рамках аналогичной активности (но не успел пока выложить в открытый доступ). Не стоит забывать, что создание модели угроз и требований ИБ для таких широких процессов, как сборка и деплой - это всегда про кастомизацию. Кому-то будет важно ограничить прямой доступ к CD, отделив процесс отдельной системой (например, AWX, для которого есть свой набор security практик) и закрыв PAM'ом. Для кого-то верификация сигнатур в CI/CD может быть очень дорогим процессом и они ограничиваются проставлением метатэгов на уровне централизованного репозитория артефактов. Сама по себе мера "Hardening CI/CD pipeline servers" может завезти вереницу проверок и возможных "переключателей" (пример вариации настроек).

#ops

Minimum Viable Secure Product

Небольшой чеклист, состоящий из минимальных необходимых мер безопасности продукта. Общий список поделен на следующие категории:
- Business controls
- Application design controls
- Application implementation controls
- Operational controls

Если ваши продукты далеки от MVP, то есть также стриница, посвященная Enterprise Ready системам, где собраны гайдлайны по разным доменам и опросник.

#dev #ops

Практика управления безопасностью ПО в масштабных продуктах

Доклад от CISO Тинькофф об угрозах, присущих платформам разработки (куда также относятся CI/CD системы). В число угроз попали:
- Уже многим известный Dependency Confussion
- Использование одних и тех же ключей для всех сборок и деплоев
- Повышение привилегий через shared раннеры (в т.ч. привилегированный DinD)
- Внесение изменений в код за счет отсутствия правил approve/review
- Использование небезопасных сторонних библиотек
- Публикация внутренних API во внешнюю среду через единый ingress
- Открытие полного доступа в Интернет для закрытых ресурсов

#dev #ops #attack

Подводные камни DevSecOps и "безопасности как сервис".

Отдельное внимание мне хотелось бы уделить фразе "Безопасность как сервис". Дмитрий интерпретирует ее в контексте предоставления шаблонов подключения WAF/SAST/DAST, которые могут быть легко встроены как код разработчиками. По сути - это классическое видение DSO, где каждый разработчик может встроить все проверки отдельными стейджами в свой пайплайн.

Здесь, правда, есть большое количество "но", с которыми часто сталкиваются крупные компании, что зачастую препятствует закреплению DSO в культуре разработки.

Разберем некоторые из них:
- До сих пор в компаниях не везде есть единый согласованный CI, под который нужно писать шаблоны
- До сих пор есть разработчики, которые собирают код руками
- Разработчики могут буквально забить на проверку ИБ и не встроить ее в пайплайн, а у ИБ нет механизмов это своевременно выявить
- Все решения (SAST/SCA/DAST) имеют свой flow по работе с уязвимостями. Где-то нужно проставлять комментарии и статусы, а где-то таких механизмов в принципе нет (не говоря про то, что у многих инструментов нет UI)
- У каждого решения (SAST/SCA/DAST) есть своя консоль и, соответственно, свой набор доступов, который нужно предоставлять для разработчиков для триажа.
- Специалистов со стороны ИБ <5, а разработчиков 500+

Но чем больше мне удается пообщаться со зрелыми командами из компаний с большой разношерстной инфраструктурой разработки, тем больше прихожу к концепции предоставления безопасности не просто в виде шаблонов, а в виде полноценного SaaS-решения (DevSecOps/AppSec-платформа). В следующих частях мы поговорим подробнее об этом явлении, которое активно набирает обороты в large enterprise.

#dev #ops

Vulnerability subsprition

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

Вариант #1 - подписаться на CVE

Есть множество сервисов, где это можно сделать. Один из них - opencve.io. Сервис абсолютно бесплатный, можно подписаться на определенного вендора или продукт с отбивками на почту. Достаточно удобно, но наблюдаются задержки в 1-2 дня.

Вариант #2 - узнавать о новых уязвимостях от первоисточника.

Информация о важных обновлениях, решающих вопросы безопасности, может содержаться в еженедельных отчетах вендоров через их официальные страницы (как, например, страница релизов на примере Gitlab). Здесь мы имеем очевидную проблему c отсутствием унификации поступающей информации. В случае, если продукт open source и он находится на Github или Gitlab, то здесь у нас есть возможность отслеживать уязвимости через страницу Issues. Так, например, чтобы узнавать раньше всех о найденных уязвимостей Kubernetes, надежнее всего подписаться на label kind/bug (в сочетании с triage/accepted) через desktop client (как описано в этом топике).

Вариант #3 - воспользоваться агрегатором

Другой вариант - воспользоваться сервисами вроде Vulners. Vulners, помимо возможности отслеживания CVE, предоставляет язык запросов, на результаты которого можно подписываться. Например, запрос affectedSoftware.name:"nginx" OR affectedPackage.packageName:"nginx" OR cpe:nginx order:published выдаст агрегированную информацию обо всех уязвимостях, связанных с nginx.

В заключение хочу поделиться также интересным ресурсом - cvetrends.com, который собирает информацию о "хайповых" CVE из twitter.

#dev #ops

CodeQL for Log4j

“Пятница-пятницей, а Log4j JNDI инъекцию никто не отменял :) все про нее уже в курсе, но если нет, то почитать можно тут или тут, ну или по-русски тут. Для CodeQL соответственно сразу же подъехали экспериментальные запросы: https://github.com/github/codeql/pull/7354/files
Можно уже погонять на своём коде. Сами запросы используют csv-модели, то есть разделенные точкой с запятой однострочные описания неймспейса, типа, подтипа, имени класса и еще нескольких параметров для задания source'a, sink'a и summary. Это укорачивает спецификацию этих элементов, позволяет их писать быстрее, но читать это чуть непривычнее :)”

За текст спасибо @shad0wrunner

Из чата @codeql

#dev #ops #attack #sast

Acra 0.90.0: application-level encryption and searchable encryption for any SQL and NoSQL databases

Acra - проект с открытым исходным кодом для обеспечения безопасности sensitive-информации, хранящейся в базе данных за счет application-level шифрования. Что из себя представляет проект, из каких компонентов состоит и какими принципами руководствуется можно прочитать в статье. Помимо шифрования данных, есть возможность их маскирования, токенизации и поиска. Более того, есть модуль SQL firewall, который позволяет задавать политики для извлечения данных из БД, и модуль Intrusion Detection, расширяющий ваши данные honey-токенами, извлечение которых свидетельствует об атаке. Все это, ко всему прочему, интегрируется с SIEM.

#ops

Log4j - impacted products

Самое время посмотреть на те продукты, которые попали под impact от log4j:

https://github.com/NCSC-NL/log4shell/tree/main/software

https://gist.github.com/SwitHak/b66db3a06c2955a9cb71a8718970c592

Фиксить придется много

#dev #ops #attack

Cloud-Native Observability and Security Analytics with SysFlow and Falco

Всех с возвращением в рабочие будни. На канале мы их, кстати, начнем с материала про Falco (движок, реализующий обнаружение аномалий в Cloud-Native мире на базе самописных сигнатур). За последние 2 года вопросов к нему было достаточно много с точки зрения качества, но чем дальше, тем сложнее отрицать его колосальную популярность, которая в свою очередь повлияла на появление сторонних проектов. Особенно интересно наблюдать на интеграции этих проектов в 2022 году. На сайте Falco появилась статья "Cloud-Native Observability and Security Analytics with SysFlow and Falco", описывающая потенциальные возможности интеграции проекта SysFlow и Falco Sidekick.

SysFlow - свежий проект, созданный для стандартизации событий систем и расширения их дополнительными данными (источник, процесс, образ, таймштамп, состояние и тд.). Для расширенных событий строится граф связей, применяется процессинг на базе Falco правил и происходит преобразование в телеметрию и алерты.

Falco Sidekick - молодой, но уже достаточно популярный проект, предоставляющий веб-интерфейс для работы с алертами Falco из большого количества источников.

Итого в связке из двух проектов мы получаем достаточно красивое решение для визуалиации поведения злоумышленника на базе экосистемы Falco. Все это еще и красиво экспортируется в Jupyter для последующей аналитики.

#ops #k8s #docker

Building Trust in the Software Supply Chain

В канале мы очень много говорили про различные варианты атак на цепочку поставок через CI/CD и варианты ее защиты. Предлагаю посмотреть красивую страницу "Building Trust in the Software Supply Chain" по безопасности цепочки поставок от Google, которая в свою очередь предлагает обеспечить защиту пайплайнов через подход создания свидетельствующих об искажении логов (Tamper-evident logs) и их открытого решения Trillian. В основе лежит концепция Verifiable Data Structures, гарантирующая то, что логи, получившиеся в процессе скачивания сторонних библиотек, сборки и проверки сканерами безопасности, не пострадали. Эти же логи можно проверять на целостность перед тем как задеплоить соответствующий артефакт на целевое устройство.

Помимо защиты цепочки поставок подход предлагается использовать при скачивании обновлений на конечных устройствах или при работе с финансовыми транзакциями. Кстати, фреймворк SLSA от того же Google получил отдельный веб-ресурс для изучения. В нем важность сбора логов и информации о том, что собирается, когда и кем отмечена также в отдельном направлении Provenance.

#ops

10 real-world stories of how we’ve compromised CI/CD pipelines

Обожаю NCC Group за их статьи и "10 real-world stories of how we’ve compromised CI/CD pipelines" не исключение. Разбираем варианты атак, где встречающийся CI/CD на пути злоумышленника становится ключевым звеном для развития вариантов компрометации: 3 примера для Jenkins (в т.ч. дамп кредов, про который я писал ранее) и 5 примеров для Gitlab (в т.ч. атаки с использованием неизолированных привилегированных раннеров). Еще 2 примера повествуют об удивительных находках ресерчеров NCC Group в контексте повышения привилегий в AWS аккаунте при наличии доступа к "ноутбуку разработчика" или посредством эксплуатации особенностей плагина Kube2IAM.

#ops

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

CIS Software Supply Chain Security Guide

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

#dev #ops #cicd

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

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

Помните один из первых постов этого канала? 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

Здесь очень характерно поведение Microsoft, который после покупки GitHub, начал интегрировать с ним все больше интересных инструментов, связанных с безопасностью разработки. Например, уже в декабре на базе GitHub должен открыться (если еще не открылся) чат с Copilot, который позволит в числе прочих фич следить за безопасностью создаваемого кода в режиме онлайн. А тут можно посмотреть демо от CEO Microsoft с возможностями Copilot в части интеграции с различными приложениями и внешними источниками данных, в рамках Office 365 и как это позволит автоматизировать самые разные задачи. И это один продукт, одной корпорации, не специализированной на кибербезопасности. Понятное дело, что Microsoft известен своими багами и что в любом случае адаптация к новым возможностям займет какое-то время. Но кажется для всех, кто хочет "держать хвост по ветру" наступает время готовиться к адаптации прямо сейчас. И для тех, кто любит неопределенность и риски открываются возможности по развитию собственных стартапов в новых нишах. Например, почти наверняка потребуются консультанты по обучению команд AppSec и DevSecOps использованию и внедрению нового инструментария, возникнет потребность в защите API агентов GPT, встанут вопросы дообучения и тюнинга моделей, появятся истории про доверие и конфиденциальность вводимых данных, станет накапливаться ещё больше чисто юридических кейсов относительно прав собственности на "выделяемый AI продукт", потребуются стандарты и фреймворки безопасности AI и т.д. и т.п.

И хотя футурология и прогнозы дело не благодарное** (во многом потому, что технологии не существуют в вакууме и многое зависит от сил, занимающихся их внедрением, и заинтересованности субъектов, которые используют эти технологии), кажется, что AI не будет пустым хайпом и в ближайшую декаду мы увидим существенную трансформацию профессии, к которой можно и нужно готовиться прямо сейчас. А что думаете вы?

*Подробнее о состоянии безопасности в развивающихся странах можно посмотреть в замечательном выступлении Евгения Соболева: https://youtu.be/XWSrDseKMaI?si=QStWhX4u3BfSNlUp

**Здесь "на каникулы" рекомендую годную книгу "ИИ-2041. Десять образов нашего будущего" Кай-Фу Ли и Чэнь Цюфань - достаточно взвешенная и многомерная аналитика от профильного специалиста на тему влияния AI на разные области жизни. Сама книга смесь сборника художественных рассказов и научно-популярных заметок к каждому из них, где рассматриваются в том числе аспекты кибербезопасности AI.

#dev #ops #ai #прогнозы

SSPM и защита SaaS сервисов

В развитии вчерашнего лонгрида пример нового класса решений, ещё не сильно распространенного на рынке. SSPM призваны решать проблему контроля и безопасности интеграций компаний со все большим количеством облачных сервисов. Когда тот же самый GPT помощник, или онлайн-репозиторий не просто детектируется, но ставится на непрерывный контроль автоматически. Это подразумевает:

- правильную конфигурацию;
- выявление уязвимостей;
- мониторинг и реагирование на инциденты;
- контроль утечек защищаемой информации;
- управление привилегиями;
и многое другое

Подробнее про риски, подходы и модель работы с SaaS здорового человека можно почитать в прилагаемом отчете AppOmni - одного из вендоров SSPM. По данным авторов отчета в части безопасности SaaS на рынке доминирует ложная уверенность в надежности собственной системы защиты. Так 71% из 644 опрошенных оценивают уровень безопасности своих SaaS между средним и высоким, при том, что 79% из них сталкивались с соответствующими инцидентами за последние 12 месяцев. При этом, большинство опрошенных занимаются ручным контролем интеграции SaaS в организацию, и не осуществляют непрерывный контроль текущего состояния сервисов. Число же используемых сервисов и интеграций непрерывно растет.

Здесь очень хорошо видна коренная проблема ИБ: непрерывное развитие технологий и гонка за новыми интеграциями порождает небезопасный фронтир, который требует автоматизации. Автоматизация требует инвестиций времени и квалификации, либо деньги и сторонние решения с поддержкой. И вот уже на смену универсальным сканерам, IaC утилитам и system hardening решениям приходят "точечные продукты" под узкопрофильные задачи. Так и живем.

#ops #sspm #решение