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

А вы импортозаместили виртуализацию? Тогда мы идем к вам!

С момента мая 2022 и 250 Указа прошло почти 3 года. И хотя в рамках некоторых базовых технологий типа отечественного NGFW активно продолжается так называемое развитие и конкуренция, в других областях, больше привязанных не к "железу", а к "софту", российские решения уже достигли определенного уровня зрелости. Речь не только об известных кейсах типа антивируса Касперского, который еще в досанкционные времена успешно конкурировал с западными вендорами на рынках Америки, но и о множестве других продуктов. 2022 подстегнул этот тренд и дал отечественным разработчикам дополнительные шансы "быть замеченными в своем отечестве" на фоне проверенных решений зарубежных поставщиков. И те разработчики, кто начал развитие собственных продуктов заранее, а не под влиянием "дедлайна 1 января 2025 года" получили возможность "разыграться на полную".

Из критичных для импортозамещения технологий интересно посмотреть на аналитику в области VDI, где согласно аналитикам iKS-Consulting по итогам 2023 года выделился явный фаворит отечественных виртуализаторов - компания "Базис", которая согласно исследованию:

Заняла 52% рынка виртуальных рабочих мест, а следующие игроки - ГК «Астра» и «Даком М», заняли соответственно, 9 и 8 процентов.

Образованный в 2021 году через слияние активов "Ростелекома", YADRO и Rubytech "Базис" позиционирует свои решения как импортонезависимую экосистему продуктов "от инструментов управления виртуальной инфраструктурой и средств ее защиты до конвейера для организации полного цикла разработки". Решения, само собой, сертифицируются по "высшему разряду": 4 уровень доверия согласно требованиям ФСТЭК России и возможность использования в ОКИИ 1 категория значимости, ИСПДн и АСУ ТП 1 уровня защищенности, ГИС 1 класса защиты. В сегодняшних реалиях, когда основным заказчиком подобных продуктов является крупный бизнес и государственные структуры, наличие сертификатов давно стало must have для разработчиков подобного уровня. А малосредние покупатели всегда могут найти оупен сурсные и бесплатные аналоги.

На этом фоне возникает глобальный вопрос: в сообществе много представителей как крупных, так и малых и средних компаний, оставшихся работать в России. Каков ваш опыт работы с отечественными решениями? И что вы можете сказать о своем опыте перехода/использования импортозамещенной виртуализации (особенно интересно послушать опыт товарищей, которые несмотря на большие размеры инфраструктуры остаются на оупен сурс и не собираются никуда уходить)? Можно не только о VDI, но шире... Чувствую особую остроту вопроса после начала форума Банка России.

Источник картинки: исследование iKS-Consulting

#Тренды #Импортозамещение #VDI #Виртуализация