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

#humor

Дошли руки до русификации интерактивного курса по кибербезопасности с открытым исходным кодом, про который писал в прошлом году: помимо банального перевода, адаптировали с коллегами под отечественные реалии (152-ФЗ) модуль по защите персональных данных, а в модуле про безопасное программирование обновили описание OWASP TOP 10 под версию 2025 года.

Русифицированную версию положил в репозиторий на гитхабе. В LMS-платформу тоже загружал – всё работает, но если заметите ошибки, то пишите😉

#awareness #training #gamification #lms

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

Pillar Security выпустили обновленную версию своего фреймворка SAIL, разработанного для обеспечения безопасности ИИ-систем на всех этапах их жизненного цикла.

Для практического использования фреймворка SAIL авторы поделились также скиллом для ИИ-агентов, с помощью которого можно:
➡️Провести оценку по фреймворку, например, своих ИИ-агентов, чтобы выявить присущие риски (сформировать модель угроз).
➡️Сформировать план повышения уровня безопасности вашего проекта.
➡️Проверить на соответствие комплаинс-требованиям (например, ISO 42001).
➡️Сформировать опросник для оценки безопасности сторонних ИИ-решений.

p.s. Скилл совместим с Claude Code, Codex, ChatGPT, Antigravity и другими skill.md-совместимыми агентами.

#ai #framework #risk #sail #lifecycle #skill

✅ Здесь, кстати, исправил несколько ошибок и разместил веб-версию курса по адресу sa.alexredsec.ru.

p.s. Еще подборку ресурсов на тему управления уязвимостями положил в репозиторий и продублировал по адресу vm.alexredsec.ru ❤️

#awareness #training #vm #bookmarks

🥇 KPMG и TAG Infosphere недавно выпустили совместное руководство (скорее набор статей с рекомендациями) по пересмотру подходов к формированию бюджетов на кибербезопасность.
Ключевые тезисы вынесены в иллюстрацию к посту, а ниже немного распишу общие (не отраслевые) рекомендации.

Бюджетирование на принципах «Нулевого доверия»
➡️Ни одно средство защиты/услуга не должны автоматически пролонгироваться только потому, что они использовались в прошлом году.
➡️Бюджет должен разделяться на небольшие проверяемые сегменты, привязанные к конкретным целям снижения рисков.
➡️Каждый сегмент бюджета должен постоянно (например, ежеквартально) оцениваться с точки зрения фиксации наличия измеренного риска, который закрывается этим объемом бюджета, и изучения данных телеметрии, подтверждающих (или нет) его эффективности.
📌В публикации есть описание кейса бюджетирования в банке.

Риск-ориентированный подход к формированию бюджета
➡️Каждая категория расходов должна быть привязана к задокументированному и количественно оцененному риску.
➡️Бюджеты должны быть гибкими и обновляться в зависимости от изменения ландшафта угроз, а не фиксироваться раз в год.
➡️Должна поддерживаться прозрачность между затратами и снижением риска для всех участников процесса бюджетирования.
📌Для этого необходимо сформировать перечень "топ-рисков", смаппить статьи бюджета с техническим описанием на бизнес-риски и перераспределить средства из областей с избыточными мерами контроля и митигации в проблемные зоны.

Переход к "четырехмерной" модели оценки рисков
➡️Расширенная оценка вероятности – учитывает мотивацию, возможности и ресурсы злоумышленников в контексте конкретной отрасли и организации.
➡️Комплексная оценка воздействия – gереход от оценки технического ущерба к моделированию сбоев в критических бизнес-процессах.
➡️Анализ скорости – измерение скорости "материализации" угрозы и доступного времени на реагирование.
➡️Каскадность – оценка того, как инцидент может распространиться через цепочки поставок и экосистемы партнеров.
📌Помимо очевидных моментов, связанных с развитием направления Threat Intelligence и Red Teaming и использования полученных данных для динамической приоритизации рисков, есть важный совет как учитывать бизнес-контекст – интеграция с бизнес-календарем (например, корректировка оценки риска целевого фишинга в периоды подачи финансовой отчетности).

p.s. Следуя современным тенденциям, также приведены рекомендации по использованию ИИ в процессе бюджетирования.

#budget #ciso #risk #crq #roi #cost #effectiveness

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

ISACA – Just Pay It!

#isaca #humor #merch

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

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

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

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

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

🔗Чтобы разработчикам было проще воспринимать информацию и они не игнорировали длинные отчеты, был жестко ограничен формат вывода комментариев агента:
🟠Одно предложение с сутью проблемы.
🟠Пронумерованные шаги воспроизведения эксплойта.
🟠Краткая рекомендация по исправлению.
🟠Ссылки на соответствующие участки кода.
Это решение помогло побороть привычку современных моделей (таких как Opus 4.5+) выдавать избыточные описания.

Это позволило повысить метрику исправления уязвимостей до мержа пулл-реквестов.
Однако тут стоит отметить, что:
1️⃣ИИ-агенты получили возможность комментирования (оповещения о нахождении потенциальных уязвимостей) пулл-реквеста только после достижения порога в 70% по метрике точности (доли реальных уязвимостей среди всех сработок).
2️⃣Использование ИИ-агентов не заменяет классических инструментов (SAST/DAST/SCA), а там скорее всего блокировки есть.
3️⃣Если автор пулл-реквеста помечает сработку ИИ-агента как ложноположительную, то такой кейс проверяется другим ИИ-агентом и в случае повторной сработки направляется дежурному ИБ-инженеру для ручной проверки и окончательного вынесения вердикта.

#ai #figma #vm #vulnerability #culture #scr #ssdlc #awareness

Выбираем SIEM методом Сократа 😏

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

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

#framework #maturity #soc #siem

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

#humor #friday