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

10 Types of Web Vulnerabilities that are Often Missed, OWASP Top 10 Over Time

Сегодня у нас на очереди снова веб, а именно 10 уязвимостей, которые часто упускают.

Среди них:
- HTTP/2 Smuggling
- XXE via Office Open XML Parsers
- SSRF via XSS in PDF Generators
- XSS via SVG Files
- Blind XSS
- Web Cache Deception
- Web Cache Poisoning
- h2c Smuggling
- Second Order Subdomain Takeovers
- postMessage bugs

А на картинке вы, кстати, видете, как менялся OWASP Top 10 с 2004 по 2021 год.

#dev

Popular NPM package UA-Parser-JS poisoned with cryptomining, password-stealing malware

Несколько дней назад в популярном пакете ua-parser-js был обнаружен криптомайнер и password-stealer. Пакет используется такими компаниями как Google, Amazon, Facebook, IBM и Microsoft. Предполагается, что вредоносное ПО попало в пакет после получения доступа к учетной записи мейнтейнера злоумышленником.

Подверженные версии:
0.7.29, 0.8.0, 1.0.0.
Проблема устранена в:
0.7.30, 0.8.1, 1.0.1.

Сейчас уязвимость уже есть во многих AV-движках (в случае если на вашем слейве есть AV) и закрытых базах платных SCA (например, Sonatype под идентификатором sonatype-2021-1529)

P.S. Зависимость может быть транзитивной, поэтому ее можно ожидать в том же пакете react.

#attack #dev #news

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

The Python Vulnerability Landscape

Сегодня у нас пост про Python. Начнем со статьи "The Python Vulnerability Landscape" о развитии уязвимостей в пакетах python'а. В статье приведены данные об изменение числа уязвимостей в пакетах (в т.ч. с разбивкой на CWE и популярные фреймворки вроде django) и степени их критичности. На картинке вы в частности можете видеть наиболее уязвимые пакеты по годам.

А теперь об инструментах. Они не такие популярные как тот же Safety, но безусловно заслуживают внимания.

trailofbits/pip-audit - инструмент для анализа уязвимостей пакетов python от небезызвестных Trail of Bits с базой advisory-db. Скармливаем requirments.txt и получаем результат (можно в json).

ochronasec/ochrona-cli - аналогичный инструмент, использующий базу данных с уязвимостями, которая бралась за основу для формирования статистики выше. В базе используются NIST NVD, Github Advisory Database, PyPA Advisory DB.

#dev #sca

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

Log4j - impacted products

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

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

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

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

#dev #ops #attack