Devici Threat Modeling Tool

Если вы хотя бы немного следите за интернациональным аппсек-комьюнити, то вы наверняка сталкивались с материалами Криса Ромео (Chris Romeo). У Криса за плечами огромное количество докладов на конференциях, включая RSA Conference и OWASP Global AppSec, подкастов, блогов и исследований, значительная часть которых посвящена моделированию угроз.

Недавно Крис основал собственный стартап Devici для автоматизации моделирования угроз. Поскольку Devici поддерживает 3 модели угроз бесплатно и практически без ограничений для команд до 10 человек, а у Криса безупречная репутация, мы с командой не могли пройти мимо и решили попробовать этот сервис.

Идея следующая:

- Создается модель угроз в виде сущности, которая может иметь различные статусы, частоту обновлений, критичность и даже время, потраченное на моделирование.
- Команда совместно составляет архитектуру приложения, где для каждого компонента назначается атрибут в свободной форме, например, Database, API, WAF, User, Admin, MySQL, RDS, CloudTrail и т.д. В этом помогает небольшой AI, который подбирает нужные атрибуты по запросу пользователя.
- На основе выбранных атрибутов инструмент назначает список угроз. Связь осуществляется через преднастроенную библиотеку угроз, привязанных к атрибутам. Также к каждой угрозе прилагается рекомендация по устранению.
- Далее команда анализирует все назначенные угрозы по всем компонентам, в результате чего формируется to-do лист, назначаемый конкретным ответственным.

За исключением местами непродуманного UX и не всегда мгновенных откликов, инструмент выглядит интересным и перспективным. Индивидуальные исследователи могут использовать инструмент для поиска идей для своих моделей угроз, а команды, работающие за рубежом, могут рассмотреть Devici в качестве дополнения к своим процессам. Авторы также экспериментируют с инновациями и представили новый класс инструментов Design-SAST, который позволяет формировать модель угроз на основе анализированного кода. В будущем возможна генерация списка угроз с помощью AI на базе назначенных атрибутов.

#threatmodeling

AppSec != DevSecOps

Нашу команду часто подключают к процессам выстраивания безопасной разработки в компаниях. В свете продолжающихся изменений регуляторики будут ещё чаще. Помимо вопросов относящихся к специфике HR, существует пул hard skills задач, которые начинаются с четкого определения зоны ответственности человека и требуемых компетенций. Сегодняшний пост посвящен рефлексии и размышлениям о разнице между AppSec, DevSecOps и ProdSec на фоне неоднозначного видения этих ролей в компаниях, что часто приводит к недопониманию на интервью и затрудняет подбор подходящего сотрудника.

Все, что вы прочитаете далее, является субъективным рассуждением на основе эмпирики.

AppSec

Цель: Обеспечение безопасности приложения. Это отражено в KPI, включая количество найденных уязвимостей, охват тестируемых приложений и глубину анализа. В задачи входят анализ архитектуры, моделирование угроз, ревью кода и тестирование безопасности. Роль AppSec существует достаточно давно, с начала 2000-х годов, когда появилась организация OWASP. Хотя о результативности этой роли можно порассуждать, подробнее писали в относительно старом посте.

DevSecOps

Цель: Автоматизация процессов безопасности и интеграция безопасности в DevOps. В KPI входит адаптация инструментов безопасности в SDLC и автоматизация проверок безопасности на уровне CI/CD. Сюда часто включается безопасность платформ Kubernetes и облачных сервисов. Концепция DevSecOps начала формироваться в 2012-2014 годах.

Несмотря на явные различия в целях и задачах, часто можно встретить распределение ролей в командах, где AppSec-инженер в крупной компании, способной разделить ответственность, занимается встраиванием инструментов в CI/CD. При этом у инженера явный уклон именно в безопасность веба и мобильных приложений. В итоге мы видим, что внедрение произошло, но нередко оно выполнено неэффективно, не учитывая многие аспекты, к которым приходят опытные DevOps-инженеры. На рынке AppSec также существует множество кандидатов, приходящих на интервью с единственным опытом встраивания сканеров, многие из которых никогда не работали с инструментами вроде Burp Suite.

Product Security

Кто такие Product Security, о которых мы слышим все чаще последние 2-3 года, особенно на интернациональной рынке? Это команды, занимающиеся безопасностью продукта в целом, включая управление уязвимостями продукта и его инфраструктуры, а также облачную безопасность. Некоторые компании даже имеют команды Product Security как единственных специалистов по безопасности. ProdSec также тесно взаимодействует с Product Management, что нечасто встречается в AppSec. ProdSec интегрирует безопасность в жизненный цикл пользователя, внедряя MFA, историю входов, CAPTCHA и другие механизмы, тесно сотрудничая не только с dev и product, но и с маркетингом и другими бизнес-направлениями. Команде ProdSec, как и AppSec, не обязательно иметь в составе DevSecOps-инженера, который может существовать отдельно в команде DevOps.

Это зарождающееся разделение, где ProdSec получает больше доменов ИБ под управление, обусловлено, на мой взгляд, как и тесным переплетением слоев абстракций (cloud-native инфраструктура) так и непониманием старой школы инфраструктурных безопасников особенностей разработки и того, что нужно делать, чтобы быть гармоничным участником процесса. Любое изменение конфигурации в облаке, применение патча или правила на WAF может сильно повлиять на работу пользователя. Поэтому любое изменение для продуктов, независимо от инфраструктурного или прикладного слоя, может проходить аналогичный цикл SDLC, как и любое изменение кода.

P.S. И в этом процессе возникновения новых ролей можно разглядеть интересный элемент, дополняющий наш любимый shift left. Этакий shift right: когда приложения и процессы становятся все более сложными и запутанными, а мы чтобы приоритезировать необъятное фокусируемся прежде всего на опыте клиента, на том, что находится максимально справа. А затем "раскручиваем" то необходимое, что нужно для того чтобы его опыт состоялся (включая требования к ИБ и соответствие регуляторике).

#имхо

Container and Kubernetes Security Fundamentals

Я уверен, что многие из вас заметили, что мы редко затрагиваем вопросы безопасности Kubernetes и контейнеров, хотя обладаем соответствующей экспертизой. Поэтому вечерком, под чашечку расслабляющего чая, давайте преисполнимся оркестрации.... Мы не могли пройти мимо и решили опубликовать уже не новую, но постоянно обновляемую серию видео и статей от известного исследователя Rory McCune под названием "Kubernetes Security and Container Security Fundamentals" (ссылка на статьи). Материалы охватывают важные аспекты безопасности Kubernetes, включая его компоненты, а также такие механизмы безопасности контейнеров, как capabilities, namespaces, AppArmor, SELinux, cgroups и seccomp-фильтры.

В одном из последних материалов, опубликованных около двух недель назад, рассматривается вопрос авторизации в Kubernetes, включая модули авторизации (AlwaysAllow, AlwaysDeny, Node Authorizer, ABAC, RBAC) и авторизацию на уровне компонентов.

Rory McCune известен своими статьями еще с тех времен, когда работал в Aqua Security. Большую известность он получил как соавтор Kubernetes Benchmark и Docker Benchmark от CIS, а также как автор документа "Guidance for Containers and Container Orchestration Tools" для PCI DSS.

Этот курс идеально подходит для начинающих, а учиться никогда не поздно! Даже ночью 🙃

#k8s #docker #containersecurity

А между тем череда интересных митапов продолжается. Вот и Купер.тех (ex-СберМаркет) подготовил свой DevSecOps митап со спикерами из RuStore, Positive Technologies, Купер.тех (ex СберМаркет), SolidLab и MTS Web Services.

Дата: 21 августа в 19:00

Место: Москва, офис Купера + онлайн

На митапе будут представлены доклады на следующие темы*:

- Как выстроить DAST на Open-Source: гибкое использование Nuclei и ZAP под сервисы компании
- Вредные советов для вашего ASPM.
- Написали свою DSO-платформу, но все равно купили ASOC. Да как так-то?…
- Опыт тестирования Defect Dojo SASTами
- Какой должен быть SAST?

*по итогам каждого доклада и в афтерпати - обсуждение тем со спикерами

Зарегистрироваться на митап можно тут: это чтобы попасть в офлайн или чтобы не пропустить ссылку на трансляцию, если интересно присоединиться в онлайне.

#event #инфо

Harnessing LLMs for Automating BOLA Detection

Одна из самых распространённых уязвимостей в веб-приложениях — это broken access control. На сегодняшний день SAST и DAST бесполезны при их поиске, и всем известно, что выявление таких уязвимостей решается исключительно ручным тестированием с помощью плагинов для Burp, таких как Autorize, AuthMatrix, Authz.

Однако, недавно мы наткнулись на статью от Unit42 (Palo Alto Networks) о том, как они автоматизировали поиск уязвимостей типа broken object level authorization (BOLA) с помощью ИИ. В качестве входных данных используется спецификация OpenAPI, после чего механизм ищет потенциально уязвимые API, где происходит обращение к объектам (например, username, email, teamId, invoiceId, visitId). Далее строится дерево зависимостей между этими эндпоинтами и формируются тестовые кейсы, в которых инструмент пробует различные сценарии обращения к объектам на основе имеющихся доступов двух пользователей. Если один из пользователей имеет доступ к объектам другого, то существует высокая вероятность наличия уязвимости BOLA.

Звучит достаточно интересно и логично автоматизировать такого рода тестирования! В результате исследователи обнаружили уязвимости в Grafana (CVE-2024-1313), Harbor (CVE-2024-22278) и Easy!Appointments (целых 15 CVE). Они также отметили, что эксперименты показывают: обратная связь от людей постоянно улучшает точность и надёжность ИИ.

В конце статьи также много полезных ссылок на смежные исследования Unit42.

P.S. Кстати, вот еще один прекрасный пример поиска CVE с помощью LLM - анализ вылетов на предмет полезности при фаззинге браузера.

#ai

Security Templates

Сегодня без сложных постов, уязвимостей и исследований. Вместо этого мы хотим поделиться парой полезных шаблонов!

Первый из них — шаблон моделирования угроз по STRIDE для Miro от самого Head of Product Security Miro. Этот шаблон наглядно демонстрирует процесс моделирования угроз и включает сопутствующие диаграммы, которые помогают на каждом этапе составления списка угроз.

Второй — это целый набор шаблонов от Robert Auger. Роберт делится материалами, которые помогали ему на его пути в построении программ bug bounty, управления уязвимостями, внешнего пентеста и реагирования на инциденты. Во всех своих шаблонах Роберт опирается на свой опыт в таких компаниях, как PayPal, eBay, Box, Workday и Coinbase. В качестве примера к посту приложена упрощенная диаграмма процесса bug bounty. Еще нам в целом понравился чеклист в подготовки построения процесса vulnerability management, который также учитывает AppSec-процессы. По нему хорошо можно проследить попытку автора передать именно свой личный опыт.

#templates #process

Making Sense of the Application Security Product Market

Недавно мы опубликовали пост о наших размышлениях на тему AppSec, ProdSec и DevSecOps, который вызвал широкий отклик среди наших читателей в чате. Сегодня мы наткнулись на статью, которая повторяет многие из этих тезисов, дополняя их новыми аспектами, о которых мы хотели бы также поговорить.

- AppSec охватывает буквально все: приложения, CloudSec, ProdSec, DevSecOps, AI Security, SaaS Security, Data Security, Runtime Security. Это также перекликается с определением CNAPP от Gartner.

- Систематичные практики AppSec по устранению выявленных проблем пошли дальше и распространись на облака, API, что привело к появлению Product Security, который включает AAA, privilege management, secrets management, encryption и тд.

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

- CSPM-решения вроде Wiz добились успеха благодаря отличному UI/UX и механизмам приоритизации, таким как "Attack Paths".

- ASPM-решения являются преемниками успеха CSPM, но с множеством "но", включая сложность, необходимость зрелых процессов AppSec, а также зависимость от качества подключаемых решений.

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

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

#trends

GitHub Actions Exploitation

Мы редко пишем про векторы атак и уязвимости, связанные с GitHub Actions, так как в России платформа по понятным причинам не используется. С другой стороны у нас есть читатели и не из России, а за каждой конкретной атакой скрываются полезные концептуальные идеи и универсальные принципы. Поэтому когда мы нашли блог SynAcktiv, где они делятся увлекательными атаками на GitHub Actions, мы были просто обязаны этим поделиться.

Итак, рассмотрим одну из интересных атак. Атака на цепочку поставок CI через инструменты безопасности, а именно через Dependabot, сканер уязвимых зависимостей!

1) Атакующий создаёт форк репозитория, куда собирается заинжектить вредонос.

2) Затем он тригерит работу Dependabot, который делает pull request (PR) в созданный форк, предлагая обновить библиотеку до безопасной версии. При этом создаётся новый форк от Dependabot для слияния. На этом этапе авторы нашли способ изменить то, что именно добавляется в PR от Dependabot, и внедрить вредоносный код (посредством излечение секрета бота через self-hosted runners и коммуникации с Dependabot API). Хотя это уже звучит угрожающе, при внимательном ревью PR вредоносные файлы все равно могут быть обнаружены, поэтому давайте продолжим цепочку эксплуатации.

3) Далее атакующий берёт новый PR, созданный Dependabot, и вместо слияния со своим форком отправляет его в основной бранч репозитория жертвы (main). GitHub позволяет изменить цель PR, перенаправив его из одного бранча в другой. В этом случае, хотя PR и был создан ботом, авторство будет приписано атакующему, так как он инициировал действия, а не сам Dependabot.

В обычной ситуации на этом всё должно было бы закончиться, но не в случае с авторами репозитория spring-security. Они намудрили с actions на GitHub, разрешив автоматическое слияние PR, если github.actor == 'dependabot[bot]'. Проблема в том, что в контексте GitHub github.actor — это не автор бранча, а последний пользователь, совершивший действие с PR!

4) Атакующий вызывает Dependabot повторно в своём PR в main, после чего уязвимый workflow автоматически сливает PR, включая вредоносный код.

Фикс в данном случае - использовать github.event.pull_request.user.login, а не github.actor, который выдает именно автора PR как и ожидается.

SynAcktiv также поддерживает собственный инструмент octoscan для анализа безопасности GitHub Actions, куда они уже добавили файндинги со своих ресерчей.

Среди других статей от них мы также рекомендуем ознакомиться с Introduction, где авторы разбирают базовые аспекты атакующего на GitHub Actions, а также со статьей про Untrusted Input.

Здесь важно понимать, что данная проблема не является уникальной для GitHub; аналогичные проблемы и векторы атак могут возникнуть в любом элементе цепочки поставок. Обратите внимание на причины, которые привели к появлению уязвимости:
- Наличие вызовов в платформе GitHub, название которых говорит совсем не о том, как их воспринимает конечный пользователь с позиции "здравого смысла".
- Использование вызовов авторами, не до конца разобравшимися в их логике работы.
- Автоматический обход ревью, основанный на неочевидных скриптах, которые могут быть использованы широким кругом лиц...

А если вы еще пока далеки от темы CI/CD Security, но хотите с легкостью понимать, о чем здесь идет речь, вот вам awesome ci-cd attacks, где есть и Threat Matrix, use cases, инструменты и многие другие ресерчи.

#cicd

Друзья, подписчики и читатели! В день знаний символично открыть новую страницу в истории канала. На эту идею нас натолкнули последние посты, и размышления об эволюции безопасной разработки и развитии prodsec. Что мы имеем?

- DevSecOps "как вещь-в-себе" вылетает из хайповых трендов (привет аналитика gartner!);
- DevSecOps без наличия зрелых сопутствующих практик, вроде развивающегося AI, reachability analysis и ASPM теряет смысл (а на самом деле, если вспомнить лучшие практики и системный подход к управлению ИБ а-ля ISO 27001 - никогда его не имел, как не имеют смысл отдельные меры не встроенные в систему управления "как в целое");
- Написание интересных постов про DevSecOps без затрагивания других областей, типа AppSec и ProdSec, стало практически невозможным - это либо пережевывание "хорошо известного старого" (для чего появляется все больше курсов, гайдов, программ); либо достаточно частная и слишком узкая тема (не интересная широкой аудитории);
- На фоне этого нам удается находить все меньше статей и материалов про голые практики DevSecOps. Все меньше людей довольствуются фразой "DevSecOps - это стратегическое решение". Комьюнити уже не впечатляют выстраивание secure SDLC как таковое, комьюнити интересно видеть то, что поможет им получить как можно больше ощутимого профита, а это зачастую выходит далеко за пределы автоматизации в CI/CD и затрагивает проблемы далеко за рамками DevSecOps.

Таким образом за 5 лет существования канала тематика DevSecOps в пространстве .ru прошла пик, и вышла на определенный "уровень зрелости". А мы, чтобы не потерять интерес к ИБ и сохранить полезность канала для коммьюнити постараемся расширить круг тем, и оставаться на фронтире кибербезопасности, чего бы нам это не стоило 🙃 А что думаете вы? О чем бы вам хотелось читать на Security Wine и поддерживаете ли вы расширение тематик?

P.S. Дополнительно обращаем внимание, что заявление выше не означает отказ от "классики жанра": в канале продолжат выходить и более консервативные материалы, ровно как сохранится история "прошлых постов". Поэтому вы всегда сможете вернуться "в прошлое" и найти актуальные для ваших кейсов материалы.

#оргвопрос #strategy

Contextual Vulnerability Management With Security Risk As Debt

Я думаю, каждый, кто занимался построением программы управления уязвимостями или хотя бы раз пытался добиться от ИТ-команд их устранения, знает, насколько сложно обеспечить соблюдение установленных SLA. Зачастую SLA берутся «с потолка» и, как правило, далеки от реальных возможностей организации по быстрому устранению выявленных уязвимостей. В результате в организации возникает общая фрустрация, где все сталкиваются с удручающими отчетами. А CISO за "кружкой пива" мрачно заявляет, что "у него в бэклоге 3 миллиона уязвимостей" и "он/она не знает, что с ними делать!". И хотя из общих соображений понятно, что здесь придется обращаться к приоритезации и мудрости в духе общества анонимных алкоголиков:

Господи, дай мне спокойствие принять то, чего я не могу изменить, дай мне мужество изменить то, что я могу изменить. И дай мне мудрость отличить одно от другого.

Всегда интересно понять, а как конкретно можно реализовать эффективный vulnerabilty management? Сегодня мы предлагаем вам ознакомиться с опытом DigitalOcean по внедрению методики «технического долга». Суть такова:

1) При выявлении новой уязвимости ей присваивается определенный уровень критичности.

2) В зависимости от уровня критичности уязвимости определяется рекомендуемое время для ее устранения. Это время известно как «Accepted Insecure Time» — период, в течение которого уязвимость должна быть устранена, чтобы не накапливать долг.

3) Если уязвимость не устранена в течение рекомендованного времени, начинает накапливаться долг по безопасности. Долг рассчитывается ежедневно: за каждый день, в течение которого уязвимость остается нерешенной после истечения срока, к общему долгу добавляется определенная величина, зависящая от критичности уязвимости. Чем выше критичность, тем быстрее накапливается долг.

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

5) Для каждой команды или бизнес-подразделения устанавливается определенный порог долга — максимально допустимая сумма накопленного долга по безопасности. Если долг превышает этот порог, это сигнализирует о необходимости устранить уязвимости, чтобы вернуть показатели в допустимые рамки.

6) Для всех бизнес-подразделений рассчитывается показатель соответствия порогу долга по безопасности (Security Debt Adherence), то есть процент команд, у которых долг по безопасности соответствует ожидаемому уровню (или, иначе говоря, установленному уровню обслуживания (SLO)). Вначале DigitalOcean достигали 75% и постепенно продвигались к цели в 95%. Этот порог является согласованным компромиссом между бизнес-подразделением и командой безопасности относительно того, насколько гибким может быть график выполнения работ по безопасности. Если ускорение разработки продукта, критическая инициатива, инцидент безопасности или другой фактор изменяет верхнеуровневую оценку этой гибкости, DigitalOcean может повысить или снизить порог долга для соответствующей части организации.

В результате, по словам DigitalOcean, снизилась "ментальное давление" на команды и улучшились отношения с бизнес-подразделениями, что привело к тому, что многие другие команды начали адаптировать концепцию технического долга.

Очень красивая success story. И что характерно очень соответствующая ситуационным моделям управления ИБ, которые мы упоминали во вчерашнем посте. А как выстраиваете свой VM вы, и что используете в качестве "центральной шины"?

#vm #experience

CI/CD Attack Diagram

В развитии недавнего поста - диаграмма* атак на CI/CD на примере GitHub. Для каждого шага работы CI/CD описываются актуальные "сценарии провала", по некоторым из которых даны линки на статьи с подробными описаниями соответствующих атак и утилитами для их автоматизации.

Автор схемы - John Stawinski IV (именно так он именует себя на личном сайте) - с 2023 года сосредоточен на исследованиях атак на CI/CD в компании Praetorian.

*Фрагмент соответствующей схемы на ваших экранах

#ci #scheme

3.7 Million Fake GitHub Stars

«Чем больше количественный социальный индикатор используется для принятия решений, тем сильнее он подвержен коррупционному давлению и тем выше вероятность, что он исказит и разрушит социальные процессы, которые должен отслеживать» (Закон Кэмпбелла).

О том, что на GitHub существуют фейковые звезды, известно давно. Однако насколько часто можно объективно оценить безопасность репозитория, исходя лишь из его популярности? Насколько эта проблема актуальна сегодня и какие последствия она влечет за собой? Ведь часто на аудитах коллеги пытаются аргументировать отсутствие собственного контроля безопасности supply chain тем, что "используют массово популярные компоненты", которые "наверняка безопасны, а если что-то вредоносное случится, то это сразу станет заметно и изменения отзовут/заблокируют ответственные ребята".

Рассмотрим ключевые моменты статьи компании Socket, специализирующейся на безопасности цепочки поставок:

1) Звезду можно купить всего за $0.10;

2) Накрутку часто используют в репозиториях, содержащих бэкдоры и вредоносные программы, включая те, которые крадут криптовалюту;

3) Поддельные звезды вводят в заблуждение венчурных инвесторов, побуждая их инвестировать в компании с низкокачественными продуктами и слабой активностью;

4) Несмотря на активную борьбу GitHub с накруткой, 89% подозрительных репозиториев с фейковыми звездами были удалены, однако 11% остаются доступными для пользователей (1 136 репозиториев), причем 28 из них отмечены на Virus Total;

5) Репозитории с накруткой существуют в среднем около одного месяца, что представляет ощутимую угрозу для пользователей, скачивающих такие проекты;

6) Лишь 18% аккаунтов, использованных для накрутки, удаляются с платформы.

В качестве решения данной проблемы сотрудник компании Socket предложил разработать детектор для выявления поддельных звезд на GitHub. Он основывается на данных из GHArchive, ежедневно обновляемого зеркала активности на GitHub, и двух ключевых эвристических методах:

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

Эвристика кластеризации: Определяет группы пользователей, которые отмечают большое количество репозиториев звездами в короткий промежуток времени, что свидетельствует о массовой покупке фейковых звезд.

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

В результате данный детектор был добавлен в GitHub App компании. На их сайте также доступен список подозрительных репозиториев и другие полезные списки. Например, список репозиториев с подтвержденным вредоносным ПО, репозитории используемые с typosquat атаках и т.д.

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

#supplychain #securitycontrol

AI Security Newsletter

В свете текущих тенденций мы всё чаще пишем о синергии AI и безопасности. История про автоматизацию ИБ с помощью ИИ - это не только способ преодолеть пресловутый дефицит кадров (который, если смотреть исторически существовал, кажется, всегда: что во времена индустриализации 30х годов 20 века; что времена средних веков и аграрного хозяйства, что...), но и возможность реализовать пресловутый риск-ориентированный подход и гибкость системы защиты на практике (именно за счет применения ИИ, и высокоскоростной аналитики событий, журналов, изменений, угроз и т.д. мы впервые в истории получаем объективную возможность попытаться выстроить достаточно взвешенный подход к управлению ИБ организации).

В этот раз мы решили не мелочиться и предлагаем ознакомиться с пакетом материалов, который мы нашли за последние несколько недель.

1). jthack/ffufai – расширение для известного фазера ffuf, которое предлагает варианты файловых расширений для тестирования на основе предоставленного URL и заголовков. В основе используется выбор между OpenAI и Anthropic;

2). Using AI for Offensive Security - материал от Cloud Security Aliance о применении AI в OffSec, включая методики reconnaissance, scanning, vulnerability analysis, exploitation, и reporting.

3). The tech behind Semgrep Assistant’s triage and remediation guidance – статья о том, как работает AI Assistant от Semgrep. Используемый LLM помогает предложить варианты исправления уязвимостей в PR. Semgrep пошли дальше и предоставили клиентам своей enterprise-версии возможность автоматически генерировать правила на базе их движка, используя промпт.

4). Provisioning cloud infrastructure the wrong way, but faster - статья посвящена рискам использования LLM для генерации небезопасного Terraform-кода. Одной из проблем является то, что ИИ может сгенерировать инструкции для создания виртуальных машин с захардкоженными паролями, далеких от соответствия корпоративным политикам безопасности. В качестве примера в статье приведён пароль "P@ssw0rd1234!", предложенный ИИ при создании VM. Это происходит потому, что ИИ использует метод "следующего наиболее вероятного токена" для генерации текста, который не подразумевает полноценную рандомизацию, делая пароли предсказуемыми. Примечательно, что даже при использовании скриптов, созданных с помощью ChatGPT, пароли генерируются через небезопасный метод random...

5). TL;DR: Every AI Talk from BSidesLV, Black Hat, and DEF CON 2024. Подборка материалов по AI и security с конференций BSidesLV, Black Hat USA, DEF CON, проводимых в 2024 году (больше 60 докладов).

#ai

"Суровые истины, о которых ваш CISO не скажет"

Сегодня мы делимся довольно провокационным постом, основанным на материалах доклада "Hard Truths Your CISO Won’t Tell You"🌶.

Автор рассматривает множество "темных сторон" ИБ, с которыми в некоторых случаях можно согласиться, а в некоторых — нет. Предлагаем вам ознакомиться с основными тезисами:

- Бизнес всегда будет важнее безопасности, независимо от того, какие приоритеты компании декларируют в своих публичных заявлениях о защите данных клиентов.
- Compliance поддерживает бизнес. Соответствие требованиям регуляторов всегда в приоритете, поскольку без этого бизнес часто не может функционировать (оставим в стороне мнение CISM, который рассматривает compliance как еще один вид риска).
- Опросники безопасности, используемые в B2B отношениях (TPRM), нередко основаны на вранье и предоставления ложной информации, чтобы вновь поддержать бизнес.
- Людям по своей природе сложно предсказывать и оценивать риски. Люди часто ошибочно полагают, что акулы опаснее бассейнов, хотя статистически больше людей погибает именно в бассейнах. Почему тогда мы берем риск-ориентированный подход за основу? Соответственно, так как безопасность строится на оценке абстрактных рисков, её можно скорее отнести к творчеству, а не к точным наукам.
- В информационной безопасности многое построено на светофоре - приоритизации по категориям критичности (critical, medium и т.д.). Но до сих пор нет однозначного понимания, как правильно работать с этими категориями. Два «желтых» риска — это лучше или хуже, чем один «красный»?
- Безопасность поглощает бюджеты под предлогом "минимизации рисков", но насколько это эффективно, никто не может точно оценить.
- Нет гарантии, что безопасность действительно сработает там где надо и поможет избежать серьезных последствий. Стоит ли компании ожидать утечки? (непонятно). Достаточно ли количество людей в безопасности или нужно больше/меньше? Все ли мы делаем правильно? Как оценить изменение в безопасности, если мы оставим только 1/5 команды ИБ?
- Влияние инцидентов на акции компаний минимально. Статистика показывает, что большинство компаний восстанавливаются через 2-6 месяцев после утечек данных.
- Защита данных потеряла свою значимость. Рынок дата-брокеров, торгующих информацией о людях, продолжает расти, а стоимость персональных данных составляет в среднем 0.00005$ на человека.
- Безопасность часто опирается на менеджеров среднего звена, которых не воспринимают всерьез. Аналогично руководство компании и разработчики предпочитают не уделять этому внимание, поскольку ROI от вложений в безопасность остается невысоким.
- Закупки решений ИБ часто базируются на личных связях CISO с основателями компаний, инвесторами и других неформальных факторах, далёких от рациональных обоснований.
- Большинство моделирований угроз неэффективны. Разработчики ненавидят этот процесс, а архитектура может измениться на следующий день после проведения моделирования — и вы об этом даже не узнаете.

Положительные моменты в ИБ:

- Сообщество специалистов по информационной безопасности выделяется своей сплоченностью на фоне общей борьбы против "них" - групп преступности.
- Все больше профессионалов ИБ понимают бизнес и начинают менять устаревшие парадигмы.
- Информационная безопасность медленно, но верно развивается и начинает напоминать точную науку.
- Разработчики также стремятся делать все правильно, и в условиях дефицита кадров волей-неволей "перехватывают на себя" все больше функций и задач ИБ.

А что вы думаете по этим тезисам? С каким согласны, а с какими нет? 🙃

#имхо

Revival Hijack and Fake recruiter coding tests

В различных телеграм-каналах можно встретить множество упоминаний о новой атаке на цепочку поставок PyPI, известной как Revival Hijack, выявленной исследователями из JFrog. Суть атаки заключается в загрузке вредоносного пакета с тем же именем, что и у популярного пакета, который был удален. Это возможно благодаря тому, что PyPI позволяет использовать имя пакета практически сразу после его освобождения. Уже опубликовано немало постов с подробным разбором этой уязвимости на русском языке, поэтому не видим большой необходимости углубляться в детали. Для нас примечательнее скорее то, что эта атака не является совершенно новой: о ней сообщали исследователи из ReversingLabs еще в апреле 2023 года, однако тогда она не вызвала большого резонанса как сейчас 😅. Более того, ReversingLabs также предоставили инструмент для онлайн-идентификации подобных вредоносных пакетов.

В преддверии возможных аналогичных громких заголовков расскажем о еще одном сценарии атаки, который недавно, около недели назад, описали те же исследователи из ReversingLabs. Речь идет о целенаправленной атаке на разработчиков через вредоносный код, замаскированный под тестовое задание от фейкового HR в рамках python проекта. Атака осуществляется следующим образом: фейковый HR связывается с разработчиком через LinkedIn, предлагая решить тестовое задание, которое предполагает нахождение и исправление бага в проекте. Для этого требуется, соответственно, необходимо выполнить сборку, во время которой запускается исполняемый python-файл. В результате жертва подключается к C2 серверу. Помимо известных примеров подобных вредоносных заданий, в сети также были обнаружены реальные жертвы среди разработчиков. На данный момент известно, что за этой вредоносной кампанией, получившей название VMConnect, скорее всего стоит северокорейская APT-группа, действующая в интересах правительства.

P.S. Но самое забавное во всех этих атаках то, что за поверхностным разнообразием инструментов и сценариев скрываются универсальные принципы и базовые архитектурно-процессные изъяны, хорошо известные специалистам с 80-х годов, а то и раньше. Ведя книжный клуб в Кибердоме ваш покорный слуга открыл для себя Клиффорда Столла и «Яйцо кукушки: история разоблачения легендарного хакера». Эта любопытная, но нудноватая книга, на материале 1986 года наглядно показано как "уникальная специфика мира КИИ, цепочек поставок и кибервойн" на деле является давно известной и хорошо изученной территорией, но как обычно "скорость прогресса", пресловутый TTM и плохое понимание и игнорирование универсальных принципов PDCA приводят к тому, к чему приводят и даруют работу десяткам тысяч безопасников по всему миру, создавая ещё один дефицит на рынке труда....

#supplychain #attack

Enhancing LinkedIn’s security posture management with AI-driven insights

В сегодняшнем нашем посте инженеры LinkedIn рассказывают о собственной Security Posture Platform (SPP) — внутренней системе, которая предоставляет динамическое представление об инфраструктуре компании и упрощает управление уязвимостями. Основная цель SPP заключается в предоставлении актуальной картины безопасности всей цифровой экосистемы компании. Платформа интегрируется с существующими инструментами безопасности и автоматизирует сбор и анализ данных, что позволяет оценивать риски практически в режиме реального времени. Это помогает проактивно управлять безопасностью, сокращая количество ручных операций.

Ключевые особенности SPP:

- Каталогизация активов: SPP собирает данные обо всех цифровых активах компании, включая физические устройства и облачные ресурсы. Это обеспечивает полную видимость инфраструктуры, что упрощает приоритизацию рисков.
- Анализ рисков и автоматизированные решения: Платформа использует метаданные для постоянной оценки рисков. Это позволяет оперативно реагировать на новые угрозы, включая упреждающие меры, такие как изоляция устройств с высоким уровнем риска.
- Централизованное управление рисками: В основе SPP лежит Security Knowledge Graph — граф знаний, который объединяет информацию о взаимосвязях между активами. Это помогает быстрее идентифицировать риски и принимать обоснованные решения. Визуальные панели предоставляют полную информацию о состоянии безопасности пользователей и активов.

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

Немного про AI в платформе:

- Генерация контекста: Исходные данные, такие как метаданные из различных источников, преобразуются в формат, понятный AI-моделям, что повышает эффективность ответов на запросы пользователей.
- Создание запросов: AI анализирует пользовательские запросы и трансформирует их в команды для поиска данных в графе знаний, используя нетривиальные механизмы для оптимизации запросов и повышения точности.
- Маршрутизация запросов: Запросы распределяются по различным источникам данных с минимальной задержкой, что обеспечивает высокую скорость ответов.
- Обобщение данных: AI также выполняет обобщение информации, предоставляя краткие и информативные ответы.

В процессе разработки системы команда LinkedIn столкнулась с рядом технических проблем. Одной из них было ограничение ранних AI-моделей (старая модель Davinci, относящаяся к GPT3) , которые не справлялись с объемами данных в графе знаний. Также возникали сложности с управлением «галлюцинациями» AI, когда система предоставляла неверные ответы. Для решения этих проблем были внедрены сложные системы тестирования и итеративная настройка моделей, что значительно повысило точность ответов.

Результаты работы SPP впечатляют: время реагирования на уязвимости сократилось на 150%, а охват цифровой инфраструктуры увеличился на 155%.

Красивая success-story без единого скриншота и ссылок на open-source😄

#ai #experience

How to 10X Your Security (without the Series D)

Мы регулярно обращаем внимание на работы и выступления экспертов, за которыми следим, и на этот раз хотим выделить Рами МакКарти, имя которого слышно на конференциях по облачной безопасности. Недавно он опубликовал материалы своего доклада под названием "How to 10X Your Cloud Security (Without the Series D)”, за интригующим заголовком которого скрывается гораздо больше, чем облака. Ключевые тезисы доклада ниже. Запись доступна по ссылке
 
Основные "философские идеи" для компаний, стремящихся к быстрому масштабированию:
 

- Занимайтесь тем, что нельзя автоматизировать, и автоматизируйте всё возможное, чтобы эффективно масштабироваться. Не нужно автоматизировать то, что можно сделать быстрее руками. Автоматизируйте те процессы, которые очевидно подвергнуться масштабированию (например, предоставление доступов).
- Масштабируйтесь только тогда, когда отработали процессы на небольшом объёме, чтобы избежать излишней нагрузки на дашборды.
- Делайте выбор в пользу guardrails, а не gatekeepers. Про эту тему мы не так давно делали отдельный пост.
- Интегрируйте безопасность в процессы разработки с самого начала, рассматривая её как партнёра, а не как отдельную структуру. Избегайте ситуации, когда безопасность становится лишь консультантом команд, так как эта модель не масштабируется. Стремитесь к shared responsibility, делая безопасность общей задачей. А ещё это единственный стратегический вариант закрыть дефицит кадров и демографический спад, если вы не ооочень большая и интересная для ширнармас компания.
- Сведите к минимуму количество инициатив по внедрению новых решений в области безопасности, не стремитесь интегрировать всё увиденное на конференциях. Лучшее враг хорошего + keep it simple никто не отменял.
- Не бойтесь использовать пробные версии и демо-версии решений от поставщиков для получения полезных инсайтов без значительных затрат. Это не исключает дальнейшее добавление вендора в шорт-лист, но позволит вам изучить новые подходы и инновации на практике.

 
Рами выделяет ключевые категории безопасности, которые способствуют масштабированию компании:
 

- Security Program
- Invariants
- Vulnerability & Asset Management
- Identity & Access Management 
- Detection (Engineering)
- Deployment

 
В заключении представлен план действий на первые 30-60-90 дней:

- В первые 30 дней сосредоточьтесь на оценках, выстраивании отношений с коллегами и установлении baselines.
- В течение следующих 60 дней реализуйте одно заметное улучшение, которое продемонстрирует результат.
- В течение следующих 90 дней начните планировать масштабирование, создавая повторяющиеся процессы и стратегию для дальнейшего укрепления безопасности.

 
Стоит отметить, что доклад создан на основе работы "How to 10X Your Security (Without the Series D)" (https://youtu.be/tWA_EBNsQH8?si=KYsJs41Wk7DaLFmP) Клинта Файбера, материалы которого уже не раз упоминались в нашем канале.

Вроде бы все банально. Но как часто эти идеи реализуются на практике? И что мешает их воплощению в жизнь?

#cloud #experience #management