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

Exploiting Url Parsers: The Good, Bad, And Inconsistent

Команда Claroty совместно с Snyk опубликовала ресерч, посвященный уязвимостям в URL-парсерсах (названных URL Confussion), ведущих к SSRF, XSS, Open Redirect, обходам фильтраций и DoS. Всего было проанализирвоано 16 популярных библиотек и утилит на предмет их подверженности 5 категориям атак типа Confussion. В конце приведены также рекомендации, как использовать парсеры, чтобы минимизровать появление уязвимостей в своем вебе.

#dev #attack

What does your code use, and is it vulnerable? It depends!

Когда дело доходит до внедрения практики выявления уязвимостей в сторонних библиотеках, первое, что часто приходит на ум - внедрить инструмент класса SCA, получить уязвимые библиотеки и получить с разработчика обещание все исправить. При таком подходе мы сталкиваемся со встречными вопросами:
- откуда у вас уверенность, что в транзитивных зависимостях есть эксплуатируемые уязвимости,
- как определить версию директивной зависимости, чтобы обновить транзитивную
- можете ли вы полагаться на перечень зависимостей, который для вас определил SCA (например, в том же package.json может быть указано, что пакет lodash имеет версию "*")

На все эти вопросы ответить сразу на первых этапах внедрения практики не всегда удается успешно. Например, в случае, если мы имеем gradle, то build.gradle никак не даст ответов на вопросы выше, а результатом сборки в данном случае будет набор библиотек, лежащих в единой директории. Что из этого директивная зависимость,а что транзитивная по итогу анализа результатов SCA понять редко возможно. Приходится смотреть дерево зависимотей от самого gradle и сопоставлять с результатами SCA, из-за чего TTM сильно возрастает.

Часто компании принимают для себя решение просить исправлять только уязвимые директивные зависимости, а контроль устранения уязвимостей в транзитивных зависимостях отдавать на авторов директивных. Это решает часть проблем с объемом работы, но часть вопросов выше остаются актуальными.

В данном случае нам могут помочь несколько вещей. Один из простых и эффективных способов - получить lockfile! Это формат описания зависимостей с указанием явных хэш-сумм (а именно на хэш-суммы, как правило, смотрят все SCA, что сразу повышает точность сканирования). Что удобно, так это то, что lockfile можно получить нативным образом от всех популярных сборщиков (pipenv, npm, yarn, nuget, gradle, composer).

Второе решение - построить граф зависимостей и явно отсечь зависимости с глубиной выше 1. Здесь может помочь инструмент вроде It-Depends от Trail of Bits. Он построит вам перечень зависимостей с нужной глубиной и отдаст результат в формате SBOM, который можно скормить в SCA. Кроме того, он может выдать некоторые уязвимости на основе OSV vulnerability database, про которую я писал ранее.

#sca #dev

OWASP WrongSecrets

12 тасков на компрометацию секретов. Здесь есть hardcoded passwords, использование секрета в ENV, ConfigMap, AWS Secrets Manager, Vault и инжект во время сборки. Для работы с платформой, соответственно, может понадобится k8s, облако (aws, gzp, azure в experimental), minikube, vault.

#dev #secret

Improving Web Vulnerability Management through Automation

Опыт Lyft по периодическому авто-сканированию внутренних веб-приложений с помощью Burp. В принципе, все отражено на схеме. В статье вы можете познакомиться с некоторыми деталями реализации. Со слов автора, благодаря данному подходу им удалось выиграть 3 дополнительных месяца инженера, но, как правильно было отмечено, так как вся информация хранится в Jira, то имеются проблемы с ограничением объема запросов и отслеживанием версий уязвимостей.

#dev #dast

How Flipkart Reacts to Security Vulnerabilities

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

Команда Flipkart рассказывает, как устроены их AppSec-процессы по обработке уязвимостей: источники уязвимости, как они выглядят в Jira, какие есть роли в процессе по устранению уязвимостей, атрибуты, что такое "иммунизация", из чего состоит их обучение разработчиков.

https://blog.flipkart.tech/how-flipkart-reacts-to-security-vulnerabilities-17dae9b0661e

Данные проблемы можно решать не только через Jira, приводя за собой ее проблемы. Мы, например, в Альфа-Банке пошли по пути реализации собственного инструмента оркестрации AppSec (через "платформизацию"), который выполняет задачи, связанные с запуском необходимых сканеров (вроде, nuclei) и обработкой полученных результатов, решая часть упомянутых проблем.

#dev

Code Review Hotspots with Semgrep

Автор сегодняшней статьи предлагает поделить сработки на две группы - security и hotspots. Сработки группы security имеют низкий уровень ложных срабатываний и предназначаются для разработчиков, в то время как сработки группы hotspots только свидетельствуют о подрзрении на уязвимость и попадают под ответственность security-инженеров. Вся статья дальше вращается вокруг хотспотов и способов их поиска через инструмент semgrep. К хотспотам относят hardoced secrets, небезопасную криптографию, мисконфиги, переполнения буфера и тд.

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

В теории можно обратиться к последнему отчету Veracode - State of Software Security v12. В отчете приводится разного рода интересная статистика в контексте сканеров класса SAST/DAST/SCA. В частности, здесь есть перечень CWE, которые лучше всего находятся для того или иного класса сканера (картинка приложена к посту выше). Любопытно, что Cryptographic Issues и Credentials Management относятся к категории уязвимостей, которые гораздо чаще находятся именно SAST'ами, в то время как в вышеупомянутой статье они относятся к хотспотам. Что же делать?

Здесь позволю себе высказать собственное мнение, как мы делим сработки на security и hotspots в Альфе. Для многих оно покажется очевидным. Чем больше уязвимость поддается паттернам, а не механизмам data flow, тем лучше она будет находиться через SAST и тем более уверены вы в ней будете. Сюда относятся hardocded credentials, небезопасный CORS, мисконфиги (в т.ч. Docker / Kubernetes) и другие уязвимости, которые можно допустить, указав в коде непрерывный набор строк кода. SQL-инъекции, XSS, SSRF и прочие уязвимости, подразумевающие прием данных от пользователя через request-объекты имеют свойства приобретать сложную логику развития, а значит и более высокую степень FP/FN. Нередко, влияние на правила нахождения таких уязвимостей в контексте data flow стоит вам от 3 непрерывных месяцев работы в codeql/checkmarx в соусе из перегоревших appsec'ов. В это же время паттерновые уязвимости довольно легко корректируются с помощью того же semgrep.

#dev #sast

Securing Developer Tools: Package Managers

Случались ли у вас ситуации, когда антивирусный агент начинает генерировать алерты о вредоносной активности будучи установленным на сборщике? Вероятно, вы столкнулись с вредоносами, описанными в этой статьей - "Securing Developer Tools: Package Managers". Речь пойдет о вредоносных пакетах, запускаемых с помощью Composer, Bundler, Bower, Yarn и других пакетных менеджерах. Приведены также разные меры по митигации.

В Golang, кстати, часть проблем supply chain попытались решить архитектурно. Начиная c того, что сборщики не могут ничего поставить за пределами зафиксированных хэшей в go.sum и заканчивая невозможностью запускать код во время сборки. Об этой подробнее в статье "How Go Mitigates Supply Chain Attacks".

#dev

Уязвимость в репозитории NPM, позволяющая добавить сопровождающего без подтверждения

“В репозитории пакетов NPM выявлена проблема с безопасностью, позволяющая владельцу пакета добавить в число сопровождающих любого пользователя, без получения от этого пользователя согласия и без информирования о совершённом действии. Проблема усугубляется тем, что после добавления стороннего пользователя в число сопровождающих, изначальный автор пакета мог удалить себя из списка сопровождающих и сторонний пользователь оставался единственным лицом, отвечающим за пакет.

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

https://opennet.ru/57108/

#dev #news

Наиболее распространенные уязвимости в мобильных приложениях

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

Открываем короткую неделю со статьи "Наиболее распространенные уязвимости в мобильных приложениях". Это авторский список уязвимостей на основе опыта их нахождения собственным инструментом динамического анализа мобильных приложений. Здесь есть и примеры небезопасного кода и варианты митигации. Как сам автор пишет, они мало чем отличаются от OWASP, даже не смотря на то, что последняя версия Mobile Top 10 вышла в далеком 2016 году.

#dev #mobile

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 #прогнозы