AlexRedSec

Aikido Security в очередной раз сравнили последние версии ИИ-моделей с точки зрения способности обнаружения уязвимостей в коде🥇🥈🥉 В последнем тестировании смотрели на десять моделей, которым скормили наборы данных с 32 "свежими" уязвимостями: каждой модели давали по три попытки с максимум 30 итерациями для нахождения уязвимости (без доступа в сеть Интернет). Дублировать результаты для каждой модели нет смысла: всё понятно из статьи и графиков, а после выхода новых версий моделей результаты изменятся. Поэтому подсвечу обобщённые выводы из сравнения открытых и закрытых моделей: 🔗Объединение (pooling) результатов нескольких независимых прогонов значительно расширяет общий процент выявления уязвимостей – ИИ-модели по своей природе показывают нестабильные результаты от запуска к запуску, предлагая разные пути решения задачи, что может сыграть на руку при задаче поиска уязвимостей. 🔗Стратегия многократного запуска более дешевых и эффективных (с открытыми весами) моделей оказывается экономически более выгодной и результативной, чем один запуск дорогой коммерческой (закрытой) модели. 🔗Главной проблемой открытых моделей становится высокий уровень ложноположительных сработок, что увеличивает затраты (нагрузку) на последующий этап постпроверки и фильтрации шума. Дорогие коммерческие модели, напротив, окупают свою стоимость снижением затрат на последующий триаж, благодаря более высокой точности. 🔗Для достижения высокой эффективности работы ИИ-моделей в любом случае требуется качественный управляющий слой оркестрации (harness), который управляет агентом, координирует шаги проверок, интерпретирует выводы и отсекает ложные срабатывания. Модели с открытыми весами особенно чувствительны к качеству такой программной обвязки. #ai #benchmark #cve #vulnerability #harness #llm #triage

Такое берем🔥 p.s. Почте России на заметку) p.p.s. Бонусом идет срач дискуссия о том как правильно хранить пароли. #humor #friday

Cloud Security Alliance выпустила обновленный топ угроз облачной безопасности на основе опроса экспертов. Для каждой угрозы есть описание причин возникновения, технического и бизнес-влияния, ключевых мер митигации (в т.ч. связь с мерами из фреймворков CSA), тезисы из исследований и примеры связанных инцидентов (ссылки тоже есть). Сам топ угроз версии 2026 года выглядит следующим образом: ➡️Недостаточное управление идентификацией и доступом ➡️Атаки с использованием искусственного интеллекта ➡️Небезопасные сторонние ресурсы (зависимости и компоненты) ➡️Небезопасные интерфейсы и API ➡️Неправильная конфигурация и недостаточный контроль изменений ➡️Компрометация систем искусственного интеллекта ➡️APT-атаки ➡️Отсутствие стратегии и управления облачной безопасностью ➡️Небезопасная разработка ПО ➡️Случайное раскрытие облачных данных ➡️Системные уязвимости p.s. ИИ-технологии повлияли на развитие всех перечисленных угроз, о чем отдельно говорится в описании каждой из них. #cloud #csa #threats #landscape #ti #impact #mitigation #controls

Выбираем SIEM методом Сократа 😏 Интересная визуализация методики выбора SIEM‑системы (правда, забугорной) через анализ ресурсов и потребностей организации с помощью восьми контрольных (критически важных, по мнению автора) вопросов. Для выбора решения предлагается дать ответы на следующие вопросы: 1️⃣Что является приоритетом — простое соблюдение нормативных требований или проактивное обнаружение угроз? 2️⃣Каков объем данных? Это небольшая инфраструктура или среда с более чем 100 устройствами, облачными сервисами (c EDR+IAM), объемом данных свыше 250 ГБ в день и 2+ сотрудниками SOC? 3️⃣Используются другие ИБ-решения от выбираемого вендора или внедрен мультивендорный стек? 4️⃣Соответствует ли объем алертов возможностям команды? Каково качество обнаружения (уровень ложноположительных срабатываний, точность)? 5️⃣Готова ли компания инвестировать в собственную команду по разработке правил обнаружения или планирует полностью передать это на аутсорс? 6️⃣Нужно ли пытаться оптимизировать текущую legacy-систему или лучше начать «с чистого листа» с новой SIEM? 7️⃣Критически ли важно проводить анализ в реальном времени в момент поступления данных или допустима задержка после их сохранения в хранилище? 8️⃣Требуется ли решение, изначально созданное для облака, или необходимо поддерживать сложную гибридную инфраструктуру? Как верхнеуровневый чеклист – приемлемо, может задать направление, но сама методика не учитывает многие важные моменты: как минимум, не учитываются скрытые и косвенные затраты, упор сделан на на объеме обработки данных, но ничего не говорится про сложность парсинга и нормализации и т.п. #framework #maturity #soc #siem

ИБ-инженеры из Figma поделились опытом внедрения и использования ИИ-агентов для поиска и исправления уязвимостей в программном коде – статья написана простым доступным языком, да еще и с забавными иллюстрациями (Figma же😁). В компании ИИ-агенты используются в трех процессах: генерации кода, проверка пулл-реквестов и аудит (ретроспективный) всего кода. Из всех выводов и тезисов остановлюсь только на одном, который показался очень интересным с точки зрения баланса между "ИБ-запретительством" и "ИБ с человеческим лицом". Несмотря на то, что ИБ-инженеры Figma обязали разработчиков направлять все пулл-реквесты через проверку ИИ-агентами, они сознательно не стали внедрять режим блокировки – руководство решило не платить "налог на трение", который возник бы при автоматической блокировке работы разработчиков. Вместо этого они сосредоточились на "правильных" коммуникациях: 🔗Figma отошла от мягких, «извиняющихся» формулировок в комментариях (с информацией о найденных багах в пулл-реквестах) агентов, чтобы сделать требования безопасности более весомыми. Было:

«Есть вопросы? Напишите в #security. Ложное срабатывание? Нажмите 👎. Извините за шум».

Новый вариант содержит жирный шрифт и прямой призыв:

«🎯 Мы настраиваем точность сработок на основе оценок и отзывов пользователей. Пожалуйста, обработайте этот недостаток. Нажимайте 👎 на ложные срабатывания, чтобы помочь нам поддерживать высокий уровень точности. Вопросы? #security.

🔗Чтобы разработчикам было проще воспринимать информацию и они не игнорировали длинные отчеты, был жестко ограничен формат вывода комментариев агента: 🟠Одно предложение с сутью проблемы. 🟠Пронумерованные шаги воспроизведения эксплойта. 🟠Краткая рекомендация по исправлению. 🟠Ссылки на соответствующие участки кода. Это решение помогло побороть привычку современных моделей (таких как Opus 4.5+) выдавать избыточные описания. Это позволило повысить метрику исправления уязвимостей до мержа пулл-реквестов. Однако тут стоит отметить, что: 1️⃣ИИ-агенты получили возможность комментирования (оповещения о нахождении потенциальных уязвимостей) пулл-реквеста только после достижения порога в 70% по метрике точности (доли реальных уязвимостей среди всех сработок). 2️⃣Использование ИИ-агентов не заменяет классических инструментов (SAST/DAST/SCA), а там скорее всего блокировки есть. 3️⃣Если автор пулл-реквеста помечает сработку ИИ-агента как ложноположительную, то такой кейс проверяется другим ИИ-агентом и, в случае, повторной сработки направляется дежурному ИБ-инженеру для ручной проверки и окончательного вынесения вердикта. #ai #figma #vm #vulnerability #culture #scr #ssdlc #awareness

Хех, ISACA заколлабилась с Nike и выпустила лимитированную серию кроссовок) p.s. Говорят, чтобы не потерять право ношения кроссовок надо ежегодно заносить в ISACA 45$😁 ISACA – Just Pay It! #isaca #humor #merch

🥇KPMG и TAG Infosphere недавно выпустили совместное руководство (скорее набор статей с рекомендациями) по пересмотру подходов к формированию бюджетов на кибербезопасность. Ключевые тезисы вынесены в иллюстрацию к посту, а ниже немного распишу общие (не отраслевые) рекомендации. Бюджетирование на принципах «Нулевого доверия» ➡️Ни одно средство защиты/услуга не должны автоматически пролонгироваться только потому, что они использовались в прошлом году. ➡️Бюджет должен разделяться на небольшие проверяемые сегменты, привязанные к конкретным целям снижения рисков. ➡️Каждый сегмент бюджета должен постоянно (например, ежеквартально) оцениваться с точки зрения фиксации наличия измеренного риска, который закрывается этим объемом бюджета, и изучения данных телеметрии, подтверждающих (или нет) его эффективности. 📌В публикации есть описание кейса бюджетирования в банке. Риск-ориентированный подход к формированию бюджета ➡️Каждая категория расходов должна быть привязана к задокументированному и количественно оцененному риску. ➡️Бюджеты должны быть гибкими и обновляться в зависимости от изменения ландшафта угроз, а не фиксироваться раз в год. ➡️Должна поддерживаться прозрачность между затратами и снижением риска для всех участников процесса бюджетирования. 📌Для этого необходимо сформировать перечень "топ-рисков", смаппить статьи бюджета с техническим описанием на бизнес-риски и перераспределить средства из областей с избыточными мерами контроля и митигации в проблемные зоны. Переход к "четырехмерной" модели оценки рисков ➡️Расширенная оценка вероятности – учитывает мотивацию, возможности и ресурсы злоумышленников в контексте конкретной отрасли и организации. ➡️Комплексная оценка воздействия – gереход от оценки технического ущерба к моделированию сбоев в критических бизнес-процессах. ➡️Анализ скорости – измерение скорости "материализации" угрозы и доступного времени на реагирование. ➡️Каскадность – оценка того, как инцидент может распространиться через цепочки поставок и экосистемы партнеров. 📌Помимо очевидных моментов, связанных с развитием направления Threat Intelligence и Red Teaming и использования полученных данных для динамической приоритизации рисков, есть важный совет как учитывать бизнес-контекст – интеграция с бизнес-календарем (например, корректировка оценки риска целевого фишинга в периоды подачи финансовой отчетности). p.s. Следуя современным тенденциям, также приведены рекомендации по использованию ИИ в процессе бюджетирования. #budget #ciso #risk #crq #roi #cost #effectiveness

✅ Здесь, кстати, исправил несколько ошибок и разместил веб-версию курса по адресу sa.alexredsec.ru. p.s. Еще подборку ресурсов на тему управления уязвимостями положил в репозиторий и продублировал по адресу vm.alexredsec.ru ❤️ #awareness #training #vm #bookmarks

Pillar Security выпустили обновленную версию своего фреймворка SAIL, разработанного для обеспечения безопасности ИИ-систем на всех этапах их жизненного цикла. Для практического использования фреймворка SAIL авторы поделились также скиллом для ИИ-агентов, с помощью которого можно: ➡️Провести оценку по фреймворку, например, своих ИИ-агентов, чтобы выявить присущие риски (сформировать модель угроз). ➡️Сформировать план повышения уровня безопасности вашего проекта. ➡️Проверить на соответствие комплаинс-требованиям (например, ISO 42001). ➡️Сформировать опросник для оценки безопасности сторонних ИИ-решений. p.s. Скилл совместим с Claude Code, Codex, ChatGPT, Antigravity и другими skill.md-совместимыми агентами. #ai #framework #risk #sail #lifecycle #skill

AI SOC Evaluation Framework – еще один вендор-независимый фреймворк для оценки применимости и эффективности AI SOC. На сайте проекта также есть онлайн-калькулятор. Ключевые компоненты ASEF: 🟠Shift Map (карта жизненного цикла инцидента) Позволяет оценить применимость ИИ на каждом этапе обработки данных и угроз: 🟠Evaluator Scale (шкала автономности) – каждая функция оценивается по уровню автоматизации от 0 (ручной режим) до 2 (полная автономия). Например, уровень 1A (Approve) означает, что ИИ самостоятельно сформировал план действий и ожидает только подтверждения от аналитика. 🟠Builder Mode (оценка рисков внедрения) – скоринг применимости функций под специфику конкретной команды, учитывая степень надежности реализации алгоритма (Trust), ресурсоемкость развертывания и поддержки силами внутренней команды (Complexity) и риски для бизнес-процессов в случае ошибки ИИ (Impact). 🟠Метрики эффективности (PICERL) – внедрение платформы оценивается через изменение (дельту) метрик на разных стадиях инцидента (Preparation -> Identification -> Containment -> Eradication -> Recovery -> Learning) относительно исходного состояния. Этапы выбора AI SOC платформы по методологии ASEF: 🟠Frame – самооценка слабых мест текущего SOC, фиксация базовых метрик и определение критических требований. Без фиксации базовой линии дальнейшая объективная оценка невозможна. 🟠Shortlist – фильтрация кандидатов по ключевым технологическим критериям, проверка наличия механизмов логирования и аудита, исключение заведомо незрелых решений. 🟠Evaluate – тестирование систем на собственных данных. Проводится сначала в Shadow mode (ИИ наблюдает и готовит черновики без активных действий в инфраструктуре), затем — с постепенным расширением зон контроля (тестовые хосты -> рабочие станции -> продуктивная среда). 🟠Maturity – составление итогового профиля возможностей продукта на карте Shift Map. 🟠ROI – расчет изменения метрик эффективности PICERL и оценка совокупной стоимости владения для покупателя. 🟠Decide – принятие финального решения на основе сопоставления результатов пилота с пороговыми значениями, установленными на первом этапе. Посты про другие фреймворки: ➡️SIEM and AI SOC Ratings Framework ➡️AI Response Maturity Model #framework #maturity #soc #siem #ai

Дошли руки до русификации интерактивного курса по кибербезопасности с открытым исходным кодом, про который писал в прошлом году: помимо банального перевода, адаптировали с коллегами под отечественные реалии (152-ФЗ) модуль по защите персональных данных, а в модуле про безопасное программирование обновили описание OWASP TOP 10 под версию 2025 года. Русифицированную версию положил в репозиторий на гитхабе. В LMS-платформу тоже загружал – всё работает, но если заметите ошибки, то пишите😉 #awareness #training #gamification #lms

Наконец-то полезный ресурс – APT & Threat Name Generator! Теперь исследователям не придется ломать голову над названием для новой группировки или очередного вредоноса🤤 p.s. Сгенерированное имя можно даже застолбить у автора ресурса, чтобы он исключил его генератора👍 #humor

⚡️Агентство CISA выпустило директиву для гос.учреждений США (а для всех остальных – хороший гайд🙂) о приоритизации устранения уязвимостей на основе риск-ориентированного подхода. Критерии оценки рисков: 1️⃣Доступность системы из сети Интернет. 2️⃣Наличие уязвимости в каталоге KEV CISA. 3️⃣Возможность автоматизации процесса эксплуатации уязвимости (шаги 1-4 цепочки атаки, kill chain). 4️⃣Уровень воздействия на систему (полный или частичный контроль над системой в случае успешной атаки). Напомню, что критерии 3 и 4 взяты из методологии SSVC*, а значения для этих параметров можно взять из репозитория CISA Vulnrichment. Комбинирование вышеуказанных критериев риска порождает шестнадцать сценариев – а точнее SLA по устранению уязвимостей (от трех дней и до планового обновления). Из интересного стоит отметить, что для самых высокорисковых сценариев, помимо устранения уязвимостей за три дня, необходимо провести расследование, чтобы исключить компрометацию инфраструктуры до момента применения патча. *p.s. Кстати, в рамках вебинаров про подходы и инструменты приоритизации устранения уязвимостей я отмечаю, что методология SSVC напрашивается на преобразование в более прикладной подход и привожу несколько таких примеров. Теперь будет еще один 🙃 #vm #prioritization #cisa #vulnerability #ssvc #risk

🔤🔤🔤🔤 🔤5️⃣ Через неделю выйдет очередная версия EPSS (пятая), но уже сейчас есть информация о некоторых изменениях, сравнение с действующей четвертой версией, да и фиды ежедневные уже как пару недель можно скачать. Разработчики EPSS ожидаемо заявляют, что:

"Модель EPSS V5 представляет собой значительное обновление системы прогнозирования эксплуатации уязвимостей"

Из более "осязаемых" изменений: 🔗Улучшили поиск эксплойтов – стали лучше искать код на гитхабе, в т.ч. с точки зрения "качества", учитывая метрики популярности репозиториев. 🔗Добавили несколько новых источников данных – например, Vulncheck KEV. 🔗Модель V5 стала более стабильной, чем V4 – оценки в V5 реже подвергаются резким колебаниям при ежедневных обновлениях данных (примерно в 7-8 раз). #epss #vm #cvss #kev #github #prioritization

AIRQ Framework – очень классное исследование и подход оценки безопасности использования ИИ-агентов в корпоративной среде: в рамках работы изучили сотню агентов, которые предварительно разбили на десять классов (по специфике работы), на предмет выявления рисков, связанных с предоставлением доступа к данным и выполнению критичных операций. В итоге все агенты разнесли на четыре профиля риска, основываясь на определенной поверхности атаки, эффективности защитных мер и размере возможного ущерба (в случае компрометации агента): 🟠Exposed Giants – широкие возможности, но слабая защита. 🟠Fortified Leaders – мощные возможности с пропорциональными мерами защиты. 🟠Humble Providers – ограниченные права доступа и слабая защита. 🟠Tight Operators – узкая специализация и сильная защита. На сайте сделали удобную визуализацию результатов сравнения, а для каждого (из сотни!) агентов есть подробное описание профиля риска, советы по харденингу и ссылки на документацию/связанные исследования/уязвимости. Помимо точечных выводов по каждому агенту, есть аналитика по каждому классу агентов и рекомендации по выбору решений и организационным мерам защиты. #ai #framework #airq #risk #controls #research #vulnerability #agent #hardening

Небольшой портал со статистикой и аналитикой по уязвимостям, обнаруженным с помощью автономных ИИ-агентов. Ключевые выводы: ➡️В 2026 году наблюдается резкое сокращение (–68%) количества обнаруженных агентами классических веб-уязвимостей, таких как XSS, SQLi и CSRF, по сравнению с 2025 годом. ➡️Уязвимости, найденные ИИ, чаще (по сравнению с остальными) получают высокие или критические оценки по CVSS, однако, вероятность эксплуатации (по EPSS) почти всегда околонулевая. Например, EPSS > 80% зафиксирован только у трех уязвимостей. ➡️Чаще всего ИИ-агенты успешно находят уязвимости XSS, Code Injection и Path Traversal. Совсем плохи дела с Resource Management Errors, PHP File Inclusion, Embedded Malware и Protection Failure. ➡️Разные компании (разработчики ИИ-агентов) доминируют в различных метриках. Например, Anthropic лидирует по количеству найденных критических уязвимостей (40), в то время как Hacktron AI находит наиболее опасные с точки зрения эксплуатации уязвимости (самый высокий средний показатель EPSS — 12,77%). Организация AISLE Research Team лидирует по общему объему и разнообразию найденных типов уязвимостей. #ai #vulnerability #cve #epss #cwe