Всех зову на мероприятие по ссылке выше)
Я там буду модератором дискуссии, а спикерами выступят эксперты по ИБ и ИИ-агентам)

Риски кибербезопасности информационных систем с ИИ и подходы к их митигации
#иб_для_ml

Вышла моя статья в журнале "Информационная безопасность"!

Ссылка: https://cs.groteck.ru/IB_1_2025/index.html
Страницы 54-57

Будет даже печатная версия, выйдет через две недели)

Саммари по статье
В этом материале я постарался дать полное введение в сферу безопасности ИИ. Для неподготовленного к специфике ИИ читателя (но для специалиста по ИБ) в начале рассказываю, чем отличаются системы с ИИ от прочих информационных систем.
Есть небольшой обзор ключевых документов по теме от основных экспертных игроков в этой области, чтобы дать понимание, насколько все уже серьезно)
Далее рассмотрены конкретика, разница понятий AI Safety и AI Security, основные проблемы безопасности в раскладке на жизненный цикл ИИ и как их митигировать, новинки ФСТЭК по вопросу безопасности ИИ и вообще состояние российской регуляторики в этой области.
А в конце - мои личные прогнозы на 2026-2030: придут агенты и захватят мир.

Приятного чтения)

Итоги подкаста "Новые векторы атак и уязвимости, которые открывают ИИ-агенты"
#иб_для_ml

На прошедшем в это воскресенье подкасте эксперты - Артем Семенов, Александр Товстолип, Александр Лебедев, и Борис Захир, обсудили AI-агентов — системы, способные самостоятельно принимать решения и выполнять задачи, используя инструменты и внешние сервисы. Ключевая характеристика агентов, как программного кода — способность воздействовать на информационные ресурсы, а не только генерировать текст, как это делают простые языковые модели (LLM).

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

Обсудили актуальные угрозы: prompt-инъекции (внедрение вредоносных команд), каскадные атаки (распространение ошибки одного агента на всю систему), отравление памяти агента (запоминание вредоносных инструкций) и эксплуатация уязвимостей протоколов взаимодействия. Чтобы справиться с рисками, предложили фильтрацию входящих и исходящих команд, автоматизированный аудит (агенты-безопасники), подход Zero Trust (минимальное доверие между агентами), а также обязательное присутствие человека в цикле принятия решений (human-in-the-loop).

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

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

Вот такие интересные темы мы обсуждаем в Музее Криптографии по воскресеньям на Открытых Подкастах сообщества Слономойка.

Следите за последующими анонсами, тема ИИ-агентов еще продолжится)

P.S. А еще мы сгенерировали текстовую расшифровку аудиозаписи. Там есть некоторые артефакты распознавания, но качество все равно сносное.

Первая российская модель угроз AI
#иб_для_ml

У Сбера вышла модель угроз кибербезопасности AI на всех этапах жизненного цикла - от сбора данных до эксплуатации. По сути, первый фреймворк, аналогичный DASF, NIST AI RMF, и прочим, но российский. Это круто. И в конце приведено, что модель учитывает все актуальные материалы OWASP, MITRE, NIST и др.
Главное, чем мне нравится документ - своей структурой и полнотой.

Что в ней есть?
Перечень из 70 различных угроз, разбитых на 5 групп:
— Угрозы, связанные с данными
— Угрозы, связанные с инфраструктурой
— Угрозы, связанные с моделью
— Угрозы, связанные с приложениями
— Угрозы, связанные с AI-агентами
У каждой угрозы прописаны пояснение, последствие реализации, объект, на который нарушитель воздействует для реализации угрозы, виды моделей, подверженных угрозе (PredAI, то есть узкие ml-модели, и GenAI), а также лица, ответственные за митигацию угрозы. Последний пункт, думаю, является наиболее интересным с прикладной точки зрения. И еще нарушаемое свойство информации, но оно больше для базового понимания угрозы. Правда, примечательно, что для угроз галлюцинаций (M03) и вредоносных генераций (App12) используется четвертое свойство безопасности - достоверность.
Нет конкретных мер безопасности моделей, но, возможно, это не так страшно.

Как пользоваться моделью?
Первое, на что падает в документе взгляд - схема объектов защиты. Рассмотрен цикл разработки модели машинного обучения. При построении частной модели угроз для своей системы на этой схеме можно очертить поверхность атаки, оставив на ней только актуальные информационные объекты.
Далее - выписываем угрозы, разбитые по идентификаторам. Какие-то можно отсеять, если тот или иной объект защиты (то есть информация) не является слишком ценной.
После чего - можно перейти к поручению разработать меры защиты для ответственных за противодействие выписанным угрозам. Да, напрямую мер и требований нет, но можно предположить, что для каждой отдельной организации они будут свои. И мне очень нравится решение в качестве общего для всех знаменателя выделить именно ответственных за эти меры.
При этом не всегда эта мера, что будет следовать из названия владельца митигации, находится на том же этапе ЖЦ, что и угроза. Например, подавляющее большинство угроз для модели или AI-агентам относятся к эксплуатации. Но за противодействие ответственен разработчик модели, и я думаю, тут имеется в виду проведение состязательного дообучения и т. п.

AI-агенты
Что меня отдельно приятно порадовало - затронута безопасность AI-агентов. При чем на глубоком уровне - проработаны угрозы из-за исполнения действий, из-за мультиагентности, и угрозы для системы, которая эксплуатирует AI-агентов. Например, довольно необычный вектор атаки описывает угроза Ag05, при котором агент может использовать свои инструменты получения информации из интернета, чтобы загрузить вредоносное ПО. Есть даже упоминание каскадных атак в мультиагентных системах, для усиления какой-то исходной атаки-пэйлоада.

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

Поздравляю всех с Праздником Победы

Навсегда в наших сердцах подвиг наших предков, самоотверженность и воля защищать Отечество

Вебинар «AI в Кибербезе & Кибербез в AI»

Ссылка: https://cisoclub.ru/ai-v-kiberbeze-amp-kiberbez-v-ai-naskolko-gluboko-ii-pronik-v-nas-ostavajas-pri-jetom-ujazvimoj-sistemoj/

В эту пятницу, 16.05.2025, в 11:00 по Москве, пройдет вебинар про #ml_для_иб и #иб_для_ml. На нем в двух соответствующих блоках обсудим эту тему со Николаем Арефьевым, Львом Палеем (@WMXWAS, #ПоИБэшечка), Анной Олейниковой и Алексеем Пешиком.

AI в ИБ
Сначала пройдемся по способам применения AI в SOC, прям в разбивке на жизненный цикл инцидента. Будем сопровождать разговор примерами из TI и не только. Поговорим о данных в кибербезе, какими они могут быть и как их собирать. Эти разные грани одной и того же технологического аспекта плавно и незаметно подведут нас к деталям применения LLM, устройства RAG и даже AI-агентов.

ИБ в AI
После чего перейдем к обратной стороне медали - безопасности столь многообещающих технологий. Компрометация ответа модели, утечка данных через модель, и специфичные агентские атаки - об этом расскажу я во втором блоке. И кроме самой сути угроз, не оставим без внимания и меры обеспечения безопасности AI-систем в SOC. Конечно же, не упуская из виду системность обсуждения.

Почему стоит участвовать?
Потому что тема очень передовая, развивается динамично и в ней много неисследованного. А еще потому что все мы практики в своей области, и недоверенные гадания на той или иной гуще производить не собираемся)
Приходите, будет возможность не только слушать, но и задавать вопросы.

И еще одно мероприятие

Ближайщие 7 дней будут плотные, это не последний анонс)

Генерация синтетических инцидентов ИБ
#иб #ml_для_иб

SOC на основе ИИ - образ завтрашнего дня?
Сегодня есть большие ожидания от различных продуктов, реализующих ИИ для SOC (вот, кстати, исследование безумных ученых о том, как сделать полностью автоматизированный SOC, от сбора TI до взаимодействия с ISAC и т.д.).
Но возникает вопрос - а на каких данных ИИ обучать? Сейчас большая часть сложных моделей машинного обучения - языковые. Соответственно, одни из самых интересных текстовых данных в SOC - инциденты. И вот про их нехватку я и хотел бы поговорить.

Возьмем задачу, например, генерировать меры реагирования по описанию инцидента. Для нее нужны следующие данные:
1. Описание инцидента, включающее в себя текстовое пояснение, тип инцидента, название ассоциированных с инцидентом файлов, краткие дампы событий/трафика, характеристики хостов, и пр.
2. Описание мер защиты (фаза реагирования, состав действий)
3. Индикатор о качестве предпринятых мер защиты для данного инцидента. Он может быть бинарный (0 или 1), категориальный (светофор), или вещественный (например, от 0 до 1).

Задача сбора данных в таком составе является достаточно сложной. Эту сложность обуславливают два фактора – недостаточная зрелость систем сбора и управления информацией, требуемой для кибербезопасности, и чувствительность такой информации.
1. Недостаточная зрелость заключается в том, что стандартной ситуацией для крупных организаций, имеющих в активе десятки тысяч хостов по всей стране, является наличие от сотен до тысяч различных версий операционных систем, ими управляющих. Такое разнообразие операционных систем ведет к разнообразию состава логов, на основе которых формируются инциденты, что приводит к столь же значительному разнообразию состава самих инцидентов.

2. Второй фактор является не менее весомым - это чувствительность информации об инцидентах кибербезопасности. И причина кроется в "плохих" мерах реагирования. Если "хорошие" меры, то есть успешно закрывшие реальный инцидент, можно найти в любом SOC, то "плохих" получить от реальной организации очень сложно как минимум трем причинам:
2.1. Информацию об инцидентах, которые SOC пытался закрыть, но не смог, может привести к дальнейшей компрометации защищаемой инфраструктуры, то есть порождению потенциальных новых атак. Это неприемлемый для SOC риск.
2.2. Информация о неуспешных мерах закрытия инцидента, а, соответственно, об успешных хакерских атаках, является наносящей вред репутации как владельца защищаемой системы, так и оператора услуг информационной безопасности.
2.3. У одной организации, защищающей свою инфраструктуру с помощью SOC, которая несмотря на инциденты безопасности информации, продолжает, много неудачных случаев реагирования просто не бывает.

Даже для организаций MSSP (Managed Security Service Provider), предоставляющих услуги SOC на коммерческой основе, собрать такую информацию сложно. Причина в том, что не со всеми клиентами договор предполагает осуществление мер реагирования, а следовательно – и наличие у SOC централизованной информации об эффективности мер. Обычно в рамки условий сотрудничества входит только предоставление экспертных рекомендаций по реагированию, и точечное участие аналитиков SOC по отдельным критичным событиям безопасности.

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

И, в итоге выходит, что единственный выход сегодня - генерировать инциденты искусственно, синтетически.
Главный вопрос - как? У меня пока соображений немного:
1. Можно пойти сложным путем. Написать самому комбайн со скриптами атак, используя, например, OpenBAS
2. Тул от сообщества - attackgen
3. Тул от Splunk - attack_range

Приглашаю делиться своими идеями и мыслями в комментарии)

Скоро начинаем вебинар)

«AI в Кибербезе & Кибербез в AI»

Ссылка: https://cisoclub.ru/ai-v-kiberbeze-amp-kiberbez-v-ai-naskolko-gluboko-ii-pronik-v-nas-ostavajas-pri-jetom-ujazvimoj-sistemoj/

Датасеты с промпт-атаками
#иб_для_ml

1. https://eddyluo1232.github.io/JailBreakV28K/
2. Коллекция вредоносных промптов для LLM (https://github.com/elder-plinius/L1B3RT45)
3. Сборник датасетов и инструментов по промпт-атакам (https://github.com/CyberAlbSecOP/Awesome_GPT_Super_Prompting)
4. большая работа, в том числе есть датасет (https://github.com/allenai/wildteaming)
5. датасет Lakera (https://huggingface.co/datasets/Lakera/mosscap_prompt_injection)
6. статья JailbreaksOverTime (https://www.alphaxiv.org/abs/2504.19440) и датасет (https://github.com/wagner-group/JailbreaksOverTime/tree/main/data)

Итак, доклад по безопасности AI-агентов, MCP и A2A, который я прочитал с коллегой на Форуме "Технологии Доверенного ИИ"
#иб_для_ml

Файл вы найдете ниже под постом

Более того, я собираюсь сделать небольшую серию постов, согласно оглавлению доклада.

О чем же он был?
Во введении мы рассказали про понятие AI-агентов как таковых, немного раскрыли их отличие от просто чат-ботов или RAG. Привели определение мультиагентной системы и представили схему объектов защиты на основе модели угроз AI, представленной Сбербанком.
Далее раскрыли суть понятия MCP, конечно же со схемкой, и дали описание одной из возможных атак на этот протокол: Tool Poisoning Attack.
После чего - аналогично с A2A и атакой Privilege Escalation.

Главный интересный раздел - безопасность систем на стыке этих протоколов, пример атаки, эксплуатирующей их несогласованность, и главное - модель угроз для систем на протоколах MCP+A2A.

В качестве завершения - возможные меры защиты, мои выводы и пучок полезных ссылок по поводу)

Остаемся на связи, скоро расскажу про все подробнее.

AI в SOC
#ai
#ml_для_иб


26 июня в 11:00 CISOCLUB продолжает разговор о том, как AI можно применять в безопасности. В фокусе — SOC и всё, что может пойти не так (или наоборот, удачно).

На вебинаре — несколько блоков по теме использования машинного обучения в кибербезопасности:

— где AI уже работает в SOC
— архитектура гибридных SOC (если вам тоже кажется, что без этого не обойтись)
— как вообще измерять эффективность, и что считать успехом
— блок про риски: атаки на AI, LLM-уязвимости, реальные кейсы

👉 Программа и регистрация тут

Если вы следили за первой частью, её можно пересмотреть вот здесь
К сожалению, в этот раз не получится принять участие лично, но эксперты собираются отличные, рекомендую