Привет!

Взять приложение. Просканировать. Найти множество недостатков. Написать отчет. Скинуть команде со словами – «Разберитесь!». Получить какой-то небольшой результат (если повезет) … Знакомо?

И это описание того, как обстояли дела в Netflix до тех пор, пока они не признали такой подход несостоятельным. Что-что, а вот с фантазией у ребят просто отлично!

AppSec команда приняла волевое решение – необходимо построить долгосрочные отношения с Dev. Для этого команда Netflix определило свои 5 шагов (5 steps to approach partnership):

🍭 Step 1. Engagement Identification. Определение Dev команды, приложений с которыми она работает. AppSec убеждается, что Dev готова пойти на встречу

🍭 Step 2. Discovery Meeting. Знакомство с командой, сбор информации. AppSec Netflix собирает всю доступную информацию, включая оценку рисков, в зависимости от характеристик приложения. Их цель на данном этапе – показать Dev, что «домашнее задание» выполнено и они собрали информацию, которую могли, понять контекст (context) и что делает приложение

🍭 Step 3. Security Review. При помощи ранее собранной информации определяется перечень активностей по ИБ, которые формируются в Security initiatives Doc. Специалисты Netflix считают, что не всем приложениям нужен pentest или детальная модель угроз. Задача этого этапа сделать перечень инициатив ИБ, адаптированный под приложение

🍭 Step 4. Alignment on the Security Initiatives Doc. Обсуждение предложений по безопасности с Dev, «выравнивание приоритетов» задач

🍭 Step 5. Ongoing Relationship Management. Dev включает Security Initiatives в свой Roadmap. Далее – осуществляется синхронизация между Dev и AppSec (например, раз в две недели/месяц)

Практически на каждом из этапов команда Netflix использует различные средства автоматизации, которые позволяют консолидировать данные и создавать единую базу знаний по безопасности приложений.

Выступление команды Netflix, разбор каждого этапа (Step), а также используемые средства автоматизации можно посмотреть по ссылке!

И снова привет!

Есть большое количество заведомо уязвимых приложений, на которых можно поучиться базовым (и не только) способам атак/защиты.
А инфраструктура? Да, есть «уязвимые образы виртуальных машин», а что делать с кластером Kubernetes? Ответ есть и это… Kubernetes Goat!

Да, это уязвимая Kubernetes-среда, в которой можно попробовать реализовать такие сценарии как:

🍭 Sensitive keys in codebases
🍭 DIND (docker-in-docker) exploitation
🍭 Container escape to access host system
🍭 Attacking private registry
🍭 NodePort exposed services
🍭 Kubernetes Namespaces bypass
🍭 DoS the memory/CPU resources и другие

Kubernetes Goat можно в том числе посмотреть и на Katacoda. Guide доступен по ссылке: https://madhuakula.com/kubernetes-goat/ ☺️ Enjoy !

Всем привет!

И снова животрепещущая тема управления секретами!
Сегодня, в рубрике For Dummies, покажем пример использования, наглядно демонстрирующий пользу от систем Secret management и механизм их работы. Пример приведён с использованием продукта CyberArk Central Credential Provider (группа продуктов Application Access Manager), о котором ранее рассказали

🍩Вводные:
У нас есть монолитное, не контейнерное приложение, работающее на сервере приложений и имеющее зашитый в коде пароль в открытом, текстовом виде. Например, пароль для подключения к БД

🍩Проблема:
При удачной атаке на приложение этот пароль может стать доступен нарушителю, который с его помощью получит доступ к БД. Дальше ничего хорошего...

🍩Решение:
Заменить открытый пароль функцией вызова к системе управления секретами.

🍩 Что мы делаем?
1. Вместо пароля мы добавляем в код функцию обращения к системе управления и запроса секрета (пример на скриншоте)
2. В переменных функции (строка 10) мы указываем заранее определенные адрес хранилища, каталог с нужным секретом в нем, идентификатор приложения и идентификатор конкретного секрета.
3. Настраиваем параметры аутентификации приложения (разрешения на уровне системы управления секретами) по одному или нескольким параметрам: идентификатор конкретного приложения, контрольная сумма, ip адрес сервера приложения, пользователя, под которым оно запускается и т.д.

🍩Что в итоге получим:
1. Пароль из кода исчезнет
2. За конкретным паролем приложение через агента сделает запрос в хранилище, идентифицировав при этом себя.
3. Хранилище сверит с какого сервера, от какого приложения, каким агентом, к какому секрету пришел запрос. Если все условия получения соблюдены, хранилище в зашифрованном виде вернет секрет, который будет записан в переменную вызова.

Таким образом, в коде приложения сам пароль никогда не будет виден, нарушитель не сможет его получить. При этом даже если он получит доступ к коду приложения и попытается выполнить запрос к хранилищу, оно не выдаст значение секрета, потому что настроенная политика разрешает выдачу только и только непосредственно приложению.

Та-дам!

Пример в коде

Всем привет!

И еще один потрясный доклад с сессии AppSec California, 2019! На этот раз от RIOT Games (тех самых, что придумали League of Legends и убили DotA)!

Автор рассказывает, как они определяли приоритеты развития в достаточно сложных условиях: большое количество команд (порядка 80), территориальная распределенность, крайне сильная независимость и автономность команд, а также невозможность использования подхода «top down» применительно к Security.

Началось все с того, что ребята решили некоторое время наблюдать за работой команд. На основании этих наблюдений удалось определить собственную модель зрелости, которая состоит из 4-ух уровней:
🍭 Level 1: «Absence» – ИБ отсутствует
🍭 Level 2: «Reactive» – ИБ «держится» на 1-ом человеке
🍭 Level 3: «Proactive» – ИБ – это уже практически постоянная практика
🍭 Level 4: «Proactive mindset» – ИБ это часть приложения, однако, практики этих команд не получится «перенести» на уровни ниже, т.к. Security является частью их жизни и она "естественна" для них

После анализа собранной информации (более 80 команд) был получен ожидаемый вывод – около 90% команд находятся на уровне 1 и 2.

Что RIOT сделали потом? Потом они взяли данные по Bug Bounty, BB (данные по количеству, выплатам, времени на устранение и т.д.) и провели корреляцию с уровнями команд! Получилась следующая картина:
🍭 Level 1 – BB avg pay: $ 1x; BB avg time to fix high risk: 1x
🍭 Level 2 – BB avg pay: $ 0,8x; BB avg time to fix high risk: 0,65x
🍭 Level 3 – BB avg pay: $ 0,65x; BB avg time to fix high risk: 0,45x
🍭 Level 4 – BB avg pay: $ 0,55x; BB avg time to fix high risk: 0,3x

Кроме Bug Bounty RIOT проанализировали количество запросов на Security Review, с которыми к ним приходили команды. И опять весьма предсказуемый результат: Level 1 практически не обращался за помощью, а Level 4 – разработчики сами проводили Security Code Review и обращались к Sec, как к еще одной «паре глаз» для формирования более точного результата.

Что тут интересного – спросите вы? Нам понравилось, что такой подход показал количественное подтверждение тезисам, что а) безопасность – это важно, б) безопасность может позволять экономить и в) можно реализовать безопасность даже в условиях agile и распределенности.

А что же сделали RIOT с этим знанием? Они определили стратегию – переход с уровня 3 на уровень 4 достаточно сложен (effort + cost / value), поэтому они пришли к выводу, что необходимо «подтянуть» команды Level 1 и 2 до Level 3. Как именно они решили это сделать – смотрите видео, time code ~ 22 минута ☺️

На наш взгляд это крайне интересный и познавательный доклад, поэтому рекомендуем Вам с ним ознакомиться ☺️ Надеемся, что вам он понравится также как и нам!

Привет!

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

По ссылкам (ENG/РУС) приведен материал, в которым крайне наглядно и доступно приводится описание must have команд, которые рекомендуется знать, даже если вы – Sec, особенно в начале пути:

🍭 init
🍭add & commit
🍭push
🍭branch
🍭checkout и т.д.

Можно скачать cheatsheet, в котором собрано все необходимое, а в самом конце – небольшая подборка материалов с более детальными разборами. Надеемся, что вам это пригодится!

P.S. Preview не работает, поэтому дублируем ссылки еще раз:
ENG: https://rogerdudler.github.io/git-guide/
РУС: https://rogerdudler.github.io/git-guide/index.ru.html

Всем привет! Мы уже неоднократно писали про различные модули продукта CyberArk Application Access Manager (AAM) и сегодня решили немного агрегировать информацию для демонстрации полноты картины.

Что такое AAM?
Простыми словами, AAM - это про Secret Management на уровне приложений. На самом деле это набор модулей, предназначенных для организации безопасного взаимодействия между различными системами. Глобально каждый инструмент решает одну и ту же задачу – встраивание защитных механизмов в код приложения/скрипты с целью изъятия хранящихся в открытом виде паролей. Различие заключается в специфике приложений (контейнеризованные, неконтейнеризованные и пр.).

Модули AAM:
🍡Credential Provider (CP) – агент, устанавливаемый на АРМ разработчика и/или сервер системы, где функционирует разработанное приложение. Для интеграции в приложение используются библиотеки (Java, C/C++, .NET) или CLI. Доступен для Windows и *nix систем. Для неконтейнеризованных приложений
🍡Central Credential Provider (CCP) – веб-версия Credential Provider. Для интеграции в приложение используются REST API/SOAP запросы (агенты не требуются). Для неконтейнеризованных приложений
🍡Application Server Credential Provider (ASCP) – агент, который устанавливается на сервер приложений (JBoss, Web Logic, WebSphere, Tomcat). Для неконтейнеризованных приложений
🍡Dynamic Access Provider (DAP) – система с поддержкой различных инструментов, используемых для интеграции с контейнеризованными приложениями и контейнерными средами. Имеет open source версию, которая называется CyberArk Conjur

Что еще нужно знать:
Для функционирования продуктов группы AAM требуются дополнительные компоненты CyberArk. Большая часть компонентов – это компоненты продукта CyberArk PAS, которые является решением класса Privileged Account Management (PAM) и о котором, скорее всего, вы уже наслышаны. Это решение давно присутствует на российском рынке для решения задач по контролю действий привилегированных пользователей. Суммарный перечень компонентов представлен ниже.

🍡CyberArk EPV – компонент защищенного хранения паролей (здесь и будут храниться пароли, которые забирает AAM при вызове функций из скрипта или приложения)
🍡CyberArk CPM – компонент управления паролями
🍡CyberArk PVWA – компонент консоли управления (веб-интерфейс)
🍡CyberArk Vault Synchronizer – компонент, который используется для синхронизации секретов в модуль AAM (CyberArk DAP)

Более подробную информацию про AAM можно найти тут.

Всем привет!

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

🍭 STRIDE
🍭 PASTA
🍭 LINDDUN
🍭 CVSS
🍭 Attack Trees
🍭 Persona non Grata
🍭 Security Cards
🍭 hTMM
🍭 Quantitative Threat Modelling Method
🍭 TRIKE
🍭 Octave

Материал полезен тем, что позволяет определиться с выбором наиболее подходящего подхода. Особенно удобна табличка в разделе «Conclusions», которая описывает сильные и слабые стороны подходов.

Если хочется больше деталей, то можно обратить внимание на этот материал. В нем проводится общий анализ подхода к моделированию угроз, а в конце – небольшой пример с использованием STRIDE для Web-based User Feedback System.

От service'ов потоки трафика идут!
Egress настроен верно -
Спокоен самурай.

Привет!

Сегодня пятница, а это значит время традиционного занятного чтива! Сегодня погружаемся в RedHat Openshift Egress

В нашем корпоративном блоге на Хабре стартовал цикл статьей о приручении исходящего трафика в RedHat Openshift. О входящем трафике и использовании Ingress сказано и написано уже много, а Egress нередко остается обделен вниманием.
Если вы сталкиваетесь или уже сейчас реализовываете контроль исходящего трафика, если работаете с большими сервисами и потоками данных и хотели бы узнать больше об устройстве и принципе работы Egress в Openshift - мы с удовольствием делимся!

В этих статьях поговорим на такие темы как:
🍩Управление сетевым трафиком
🍩Маршрутизация Egress IP
🍩Планирование и настройка
🍩Полезные советы

Наглядные объяснения теории, вкусное "техническое мясцо", примеры развертываний и все что вы так любите уже на нашем Хабре!

Проходите по ссылке и погружайтесь в сети Openshift:
https://habr.com/ru/company/jetinfosystems/blog/527482/

И снова привет!

Мы уже не раз упоминали Netflix в своих постах, их подходы и практики. Сегодня хотим поделиться обзором open source решений, разработанных командой безопасности вышеупомянутой компании (все началось еще в 2014 году, с релизом Security Monkey). В этой подборке есть:

🍭 Решения, которые позволяют сформировать персональные рекомендации по ИБ;
🍭 Эмуляторы DDoS атаки на приложения;
🍭 Фреймворк по управлению payload для XSS;
🍭 Инструменты по автоматизации процесса реагирования на инциденты ИБ;
🍭 Средства по управлению SSL/TLS сертификатами;
🍭 И другие решения.

Подборка интересна больше не использованием инструментов (которое, скорее всего будет затруднительно, т.к. нацелено на использование в облачной инфраструктуре конкретной компании), а подходом и креативностью специалистов по ИБ Netflix ☺️☺️☺️

Привет!

Помимо статического (static, SAST) и динамического (dynamic, DAST) анализа приложений есть интерактивный (interactive, IAST), самый молодой 😊. Что же в нем интерактивного? И чем он отличается от Static и Dynamic?

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

А если вкратце, то интерактивные сканеры используют практики инструментации/инструментирования исходного кода, что позволяет им получать много информации о приложении и о том, как оно работает. Эти сведения помогают идентифицировать проблемы ИБ и указывать на место в коде, содержащее уязвимость. Примеры возможностей IAST:

🍭 Анализ кода – IAST может показать на строчку кода, из-за которой возникла ошибка;
🍭 Анализ HTTP-траффика – анализатор видит запросы и ответы, может идентифицировать потенциальные атаки;
🍭 Построение и анализ Data Flow – возможность отслеживания «пути» данных, полученных из untrusted sources от момента их попадания в программу для обнаружения, например, потенциальных инъекций;
🍭 Анализ конфигураций – некоторые решения позволяют проводить анализ конфигурации, например, сервера приложений на предмет наличия недостатков по информационной безопасности;
🍭 И иные функции, с которыми можно ознакомиться в статье.

Можно сказать, что IAST забрал лучшее от SAST (возможность доступа к исходному коду для анализа) и DAST (анализ приложений в run time).

Чат далеко не все читают, а там бывает интересно. Недавно попросили best practice по Kubernetes - рискну посоветовать https://learnk8s.io/production-best-practices
Очень круто, что сделано в виде чеклиста в три больших раздела:
📍Application development
📍Governance
📍Cluster configuration
Что забавно, структура разделов примерно соответствует "стандартному" фокусу команд Dev, Sec и Ops, насколько тут вообще могут быть стандарты.
Исходники и расширенная версия тут: https://github.com/learnk8s/kubernetes-production-best-practices

Всем привет!

Недавно завершился All Day DevOps, в котором было много интересных докладов, в том числе и по информационной безопасности. Но сегодня мы бы хотели рассказать про доклад 2019 года: An Intelligent Approach to Upgrading OSS Libraries! (второй доклад в playlist'e)

Использование open source библиотек позволяет делать поразительные вещи! Например, простейший web server на Java (Spring), который скажет нам «Hello world!» занимает всего 10 строк кода. Однако, всегда есть некоторая «невидимая часть», которая заключается в том, что для реализации нашего простого «Hello world!» необходимо 36 библиотек.

Какие из них уязвимы? Как можно устранить уязвимости с минимально необходимыми усилиями, за что браться «в первую очередь»?

На первый вопрос помогут ответить решения класса SCA (software composition analysis), такие как Nexus IQ, WhiteSource, Black Duck, Snyk, Checkmarx OSA и другие. А что делать со вторым вопросом?
Есть несколько «традиционных» подходов к решению этой задачи:

🍭 Подход №1: Приоритизация критичности приложений с последующим уточнением количества уязвимостей в рассматриваемых приложениях («Это приложение для нас критично и в нем не так много уязвимостей, отличный вариант для начала!»)
🍭 Подход №2: Приоритизация уязвимостей в зависимости от уровня критичности и масштаба использования рассматриваемой библиотеки в Компании («Она уязвима и ее часто используют – надо устранять в первую очередь»)

Однако, оба эти подхода, хоть и работают, могут породить большое количество дополнительных задач (пример можно посмотреть по ссылке на видео, time code ~ 4:55). Для решения этой проблемы ребята предложили интересный подход: Bottom Up, для реализации которого необходимо:

🍭 Идентифицировать все внутренние проекты, которые не зависят от иных внутренних проектов (а значит, зависят только от one source компонент)
🍭 Обновить уязвимые open source компоненты для множества проектов, идентифицированных на предыдущем этапе
🍭 Идентифицировать внутренние проекты, которые ссылаются на недавно обновленные проекты
🍭 Обновить множество проектов, идентифицированных на предыдущем этапе
🍭 Повторять, пока не будет достигнут «корень дерева»

С точки зрения авторов такой подход является оптимальным, т.к. он не порождает дополнительных задач и позволяет сформировать backlog по устранению уязвимостей.

Кроме проработки концепта ребята разработали утилиту, которая позволяет расставлять приоритеты устранения уязвимостей на основе вышеуказанного подхода – Ariadne.

OpenSource - это круто, говорили они. Нас попросили для POC из грязи и прутиков собрать storage на bare-metal Kubernetes кластере. Ниже выдержка из чата, как есть, с сохранением авторской орфографии и пунктуации.
Дисклеймер: сообщения вырваны из контекста. Предлагаю определить "Индусы" = "Разработчики разного уровня квалификации", национальная принадлежность разработчиков не имеет значения.

Архитектор
Так, у меня фиговые новости - отказ storage на storage node несовместим с дальнейшей нормальной жизнью. Индусы из OpenEBS - это сборище непуганых идиотов. И они еще это пытаются продавать.

Инженер
Эмм каким образом оно отказало?

Архитектор
у вас никак. А на стенде я убил себе storage на 1 ноде
и раскрылись бездны индусского слабоумия

Инженер
Какими действиям хоть убил?

Архитектор
взял и на VM диск грохнул

Архитектор
tbe commented on 22 May 2019
I just wonder why this is not a blocker or at least mentioned in the docs: "WARNING! You can not remove a broken disk from a custom pool"

Disks break. A "Leading Open Source" software should be able to handle this.

We lost one of your disks on one node yesterday. After replacing it the according pool was still fucked up, so restartet it. And at this point the whole thing broke ... many volumes in state "Recreating", the pool itself didn't start anymore, all iscsi targets for volumes that hat a replica on that pool staled, because missing quorum ( in a two replica setup, wtf? )

Yeah, this went a little bit offtopic. Sry for that. Just wanted to illustrate what happens if you put a "not so fancy, but essential feature" at the end of the roadmap.

Архитектор
https://github.com/openebs/openebs/issues/2258
они потом привернули костылей, и я даже вернул pool к жизни, но реплики не ожили

Привет!

По ссылке можно найти материалы от Geoffrey Hill (автора проекта по автоматизации моделирования угроз Tutamantic) и его размышления на тему Rapid Threat Modelling Prototyping. Одна из ключевых идей автора строится на том, что «классическое» моделирование угроз не применимо в DevSecOps, хотя бы потому что:

🍭 Его трудно сделать быстро (или потеряется качество)
🍭 Как правило оно более детальное, чем требуется
🍭 Не подходит для CI pipeline (или потребуется сильная адаптация)

Поэтому автор предлагает свой подход, который представлен в материалах: общие презентации (обзоры, примеры step by step), небольшие how2 guides ☺️

Всем привет!

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

🍭 Namespace breakout через некорректный mount hostPath
🍭 Lateral movement в cloud на примере GKE (Google Kubernetes Environment)

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

И снова привет!

Если хочется погрузиться в мир «практической» безопасности, связанной с Docker, то мы рекомендуем обратить внимание на подборку материалов, доступных по ссылке. Автор начинает с азов – Что такое Docker (даже есть отсылки к истории контейнеров, как таковых) и «повышает градус» от урока к уроку. Все наглядно, с примерами, командами и описанием необходимого минимума, который потребуется, чтобы все это реализовать самостоятельно. Всего доступно 6 уроков:

🍭 Lesson 1: Understand Docker from a security perspective
🍭 Lesson 2: Docker Images, Docker Layers, and Registry
🍭 Lesson 3: Container reconnaissance techniques for beginners
🍭 Lesson 4: Hacking Containers Like A Boss
🍭 Lesson 5: Hacking Containers Like A Boss – Part 2
🍭 Lesson 6: Defending container Infrastructure

Надеемся, что вам понравится!

Контейнеры в России популярны, в этом нет сомнений; их применение растет – в этом тоже. Нам стало интересно, как этот тренд выглядит в цифрах, и вот.

По данным свежего исследования о применении контейнеров в России 2020, проведенного нами совместно с CNews Analytics:

56% крупных компаний сегодня используют контейнеры для своих приложений и 7% собираются. Подавляющее большинство! Но:

Всего 8% компаний размещают в контейнерах более 60% своих приложений. А 58% только начинают осваиваться с этой технологией, доля их приложений в контейнерах < 20%.

Интересно, какие технологии предпочитают отечественные компании. В основном on-premise, так сказали 57%. В тройке лидеров:

🍫Kubernetes on-premise
🍫Различные публичные облачные решения
🍫Red Hat OpenShift

Также в исследовании:

❓с какими сложностями стакиваются компании при внедрении
❓как организуют защиту сред контейнеризации
❓какие получают преимущества от внедрения контейнеров

Получить отчет можно по ссылке https://jet.su/devsecops/#research

Всем привет!

Огромный шар, летящий в пучине беззвучного вакуума сделал семь оборотов вокруг своей оси и снова наступила она, пятница!
А как мы знаем, пятница - время вкусненьких расслабленных постов! 🍩

Сегодня мы с удовольствием делимся приятной новостью из мира container security! Недавно вышла новая версия платформы контейнерной защиты Aqua Container Security Platform, которая теперь называется Aqua Enterprise версии 5.3.
Новая версия получила новый кастомизируемый веб интерфейс, концептуально похожий на старый, но элегантно переработанный с большой оглядкой на удобство и usability.
Помимо прочего, не обошлось и без новых фич. Самые броские:

🍩 Масштабирование модуля Gateway позволяет подключить несколько instance системы в разных кластерах к одному control-plane
🍩 Multi-App RBAC, благодаря которому пользователи могут видеть события аудита только в своей зоне ответственности
🍩 Раздельные БД для хранения конфигураций системы и событий аудита
🍩 Сканирование локальных docker образов в .tar архиве
🍩 Возможность автоматического добавления sidecar контейнера защиты PodEnforces для новых подов в кластере.
🍩 Расширен список поддерживаемых систем оркестрации

И многое другое!
А еще, можно смотреть бесконечно на огонь, как выдают зарплату и новый login screen Aqua Enterprise!!! 😂

Больше информации можно найти на сайте вендора

Всем хороших выходных!