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

Non-Actionable Findings в 3rd-party Security Scanners...и как их распознать

Инженер Google написал блог-пост о том, как обрабатывать результаты CVE от сканеров безопасности и как распознать те, которые можно спокойно убрать из списка задач на фиксы.

Краткий конспект от нашей команды:

Rejected уязвимости: Самый простой вариант — исключить уязвимости с пометкой rejected в NVD (например, CVE-2023-4881). Это имеет смысл, когда сканер тащит весь NVD без минимальной фильтрации. Такой случай не особо интересен, двигаемся дальше.

Переоценка от мейнтейнеров: Бывает, что NVD отмечает уязвимость как high, а мейнтейнеры ОС считают, что у неё минимальный импакт и не выпускают патчи для своих дистрибутивов Linux. В таких случаях мнение мейнтейнеров может быть более релевантным, и уязвимость можно классифицировать как false positive.
Пример — CVE-2018-20657:

10-byte memleak, not considered important to be fixed by upstream, so no patch is available as of 2023-06-02

Отсутствие импакта на используемую ОС: NVD может показывать широкий диапазон уязвимых версий пакета, но не учитывать влияние на конкретную версию ОС. Если сканер использует только данные NVD и игнорирует статусы not affected от ОС, то он может ложно сработать на уязвимость, которой на самом деле нет (пример CVE-2023-52426)

Кастомные патчи от ОС: Иногда сканеры не учитывают кастомные патчи, которые ОС выпускает для фиксов. Например, сканер видит версию Python 3.6.10 как уязвимую, но Ubuntu выпустила патч с версией 3.6.9-1~18.04ubuntu1.1. Внешние сканеры, использующие NVD вместо базы уязвимостей от Ubuntu, могут ложно считать патченную версию Python уязвимой.

Неполная информация об уязвимости пакета: Некоторые фиды, как Debian, репортят уязвимости только для исходных пакетов. Сканеры часто ошибаются, считая уязвимыми все связанные бинарные пакеты, даже если они не содержат уязвимых библиотек. Например для уязвимости CVE-2024-6387 затрагивается только OpenSSH-серверы, но Debian отмечает уязвимым исходный пакет "openssh". В итоге даже системы с установленным только "openssh-client" будут ошибочно помечены как уязвимые, хотя уязвимых библиотек там нет.

Нерелевантные к безопасности срабатывания: Некоторые сканеры репортят пакеты, не связанные с безопасностью. Например, Trivy репортит файндинги из Debian LTS (DLA) о таких вещах, как обновления часовых поясов или новые GPG-ключи, которые не влияют на безопасность. Отсутствие этих обновлений не создает рисков для безопасности.

А какие классификации используете вы? Может быть расширим и углубим список "гугла"?

#sca #supplychain

GitHub Users Targeted by New Wave of Spambots

Ищите чтиво на выходные? Если вдруг вы увидели спам в комментариях своего репозитория на GitHub на этой неделе, вы не одиноки. Недавно мы писали об атаках на разработчиков, но на этот раз методы напоминают устаревшие практики. Боты оставляют комментарии, предлагая загрузить файлы с платформы MediaFire, содержащие вредоносное ПО. Цель злоумышленников — убедить разработчиков загрузить эти файлы, что в итоге приводит к компрометации системы и аккаунта GitHub.

GitHub пытается удалять такие комментарии, но проблема остается. Один из разработчиков создал GitHub Action, который фильтрует подобные комментарии.

"Это не должно быть задачей мейнтейнеров open-source — предотвращать спам с вредоносным ПО, но пока GitHub не решит эту проблему, я создал небольшой автоматизированный action, которая удаляет подозрительные ссылки из комментариев в задачах."

В целом подобного рода атаки на open-source не первые и не последние. В феврале этого года волна спама обрушилась на проект Express.js в следствие того как популярный youtube блогер с почти 5 млн подписчиками продемонстрировал пример как делать PR на нетестовом Github репозитории (вот здесь можно увидить результат). Несмотря на то, что это может показаться безобидным, но дело дошло даже до того один из мейнтейнеров Express.js заявил, что люди начали отправлять электронные письма с угрозами и преследовать участников репозитория за открытие спам-запросов на слияние (PR).

#supplychain #malware

SLSA provenance и кое-что еще

Так как канал исторически носит название "DevSecOps", самое время вспомнить то, что было активно обсуждаемым в 2021 году — SLSA. Недавно мы наткнулись на репозиторий s3cme — тестовое приложение на Go, в котором реализованы следующие лучшие практики:

- Сканирование с помощью Trivy
- Сканирование с помощью CodeQL
- Сборка и публикация образа с использованием ko (включает генерацию SBOM)
- Сканирование уязвимостей образа с использованием trivy с параметром проверки максимальной серьезности
- Подпись образа и аттестация с использованием cosign
- Генерация происхождения (provenance) SLSA с помощью slsa-framework/slsa-github-generator
- Проверка происхождения SLSA с использованием slsa-framework/slsa-verifier и CUE политики через cosign.

Напомним, что такое provenance. Всякий раз, когда образ публикуется в реестр, к этому образу прикрепляется аттестация в виде файла SLSA provenance (v0.2). Это позволяет отследить этот образ вплоть до его исходного кода в репозитории (включая GitHub Actions, которые использовались для его создания). Способность обеспечивать такую проверяемую прослеживаемость называется как раз происхождением (provenance). Делать это наибходимо с той целью, чтобы убедиться, что конечный доставляемый артефакт нигде не изменился по пути прохождения цепочки поставок, включая CI/CD. Отследить это можно либо вручную с помощью cosign, либо сразу в кластере с помощью sigstore admission controller.

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

А вот, например, автор из GitHub рассказывают про фичу GitHub по аттестации артефактов, которая упрощает подписание кода для программного обеспечения, созданного в GitHub Actions, и помогает достичь соответствия уровню 2 SLSA. Provenance включает информацию о происхождении, такую как данные о репозитории, инструкции по сборке и SHA исходного кода, делая процесс "голеньким и прозрачненьким".

А как вы решаете эти задачи, и дошли ли до их решения в своих пайпах?

#slsa #supplychain #devsecops

Vulncov - A tool that correlates Semgrep scans with Python test code coverage

Небольшой тул-эксперимент недельной давности — VulnCov. Его цель — приоритизировать файндинги Semgrep, исключая уязвимости, найденные в "мертвом коде". Для этого тул берет файндинги из Semgrep и объединяет их с результатами работы юнит-тестов Pytest.

Чтобы лучше разобраться, проще всего рассмотреть демонстрационный пример, где есть несколько уязвимостей внутри недостижимого участка кода:
- Закомментированный роутер #@app.route
- Невыполнимое условие if 1 == 2

По результатам сканирования Semgrep, по очевидным причинам, выдаст все уязвимости, включая те, что находятся в недостижимом коде. В проекте также есть тесты, которые по итогам выполнения формируют файл coverage.json. Файл coverage из отчета юнит-тестов содержит информацию о том, какие строки кода были выполнены в процессе тестирования, а также предоставляет сводную статистику о покрытии кода тестами. Этот файл помогает разработчикам понять, какие части кода проверены тестами, а какие — нет, что создает идеальную базу для приоритизации результатов Semgrep. В результате VulnCov сравнивает два файла и выдает JSON с наиболее релевантными файндингами.

А еще проект имеет поддержку приватной LLM ollama (хотя где-то без подключения OpenAI) для генерации баг-фиксов.

В репозитории всего 21 ⭐️, но в домене корреляции результатов, даже в эпоху искусственного интеллекта, вряд ли стоит ожидать величайших прорывов. Сразу вспоминаются решения класса IAST и сопутствующие рассуждения о корреляции SAST и DAST из далекого 2020 года. Как мы можем видеть, гораздо быстрее и эффективнее развиваются практики reachability analysis и автоматического триажа с помощью AI.

#sast #ai

Secrets and Shadows: Leveraging Big Data for Vulnerability Discovery at Scale

Помните, когда Big Data была такой же популярной, как сейчас искусственный интеллект?

Очень объемная и интересная статья "Secrets and Shadows: Leveraging Big Data for Vulnerability Discovery at Scale". Автор с высокой степенью детализации описывает исследование, которое началось еще в 2021 году. Оно посвящено двум аспектам: поиску "висящих" DNS-записей (записей, указывающих на освобожденные IP-адреса, что может привести к захвату домена) и поиску hardcoded credentials в больших объемах данных, полученных из открытых источников.

В рамках данного поста мы сосредоточимся на аспекте поиска hardcoded credentials, хотя рекомендуем ознакомиться и с кейсом, связанным с DNS-записями.

Многие инженеры знакомы с сервисом VirusTotal, созданным для быстрого анализа файлов на предмет вредоносного кода. При загрузке файла VirusTotal выводит сообщение:

By submitting data ... you are agreeing ... to the sharing of your sample submission with the security community

Вопрос извлечения и анализа загруженных файлов в VirusTotal достаточно прост: используя инструмент Retrohunt и написав YARA-правило, можно извлекать образцы из ранее загруженных файлов на основе регулярных выражений. Учитывая, что захардкоженные секреты часто имеют определенные regexp паттерны, это идеальный способ их идентификации в загруженных файлах. Однако автор пошел дальше, стремясь извлечь и те секреты, которые не поддаются стандартным паттернам. Для этого он искал косвенные признаки, такие как строки вида [a-zA-Z0-9]{32} для поиска потенциальных API-ключей. Он также создал конвейер на базе AWS Lambda для автоматизированного извлечения и проверки валидности секретов из Retrohunt.

Избегая подробностей, в результате было просканировано 5 миллионов файлов, в которых было обнаружено более 15 тысяч секретов, включая ключи OpenAI, AWS и GitHub.

Хотя статья и результаты исследования впечатляют, особенно заслуживают внимания дальнейшие действия автора. В попытке устранить выявленные секреты он решил воспользоваться функционалом GitHub. Платформа, предоставляющая открытые репозитории, может стать источником утечек конфиденциальной информации, которая быстро попадает в руки злоумышленников. В связи с этим GitHub сотрудничает с различными вендорами для оперативного отзыва таких секретов через интеграцию. Однако, поскольку GitHub не предоставляет API для массового отзыва секретов, автор был вынужден использовать кратковременные Gist'ы для публикации всех найденных данных. Идея заключалась в том, чтобы создать настолько коротко живущий Gist, который GitHub успел бы обработать для отзыва секретов, прежде чем их могли бы скомпрометировать. Тем не менее, из-за большого количества созданных Gist'ов, аккаунт автора попал под теневой бан, что лишило его возможности видеть создаваемые публикации. К счастью, несмотря на это ограничение, процесс отзыва секретов продолжал успешно работать, что позволило автору безопасно удалять ключи без дополнительных рисков.

Цитата исследователя:

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

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

А завершим мы пост цитатой статьи о том, что такое "The Security at Scale Mindset":
- Начните с уязвимости, а не с цели.
- Работайте в обратном направлении, используя креативные источники данных.
- Должны присутствовать взаимосвязи, указывающие на целевой класс уязвимостей.
- Должна быть возможность поиска по этим данным в масштабах.

#secrets