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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

📧 AI в вашей почте может сыграть против вас

Представьте: вы используете умного помощника для Gmail, чтобы облегчить рутину. Но злоумышленник подсовывает скрытую команду, и ваш EmailGPT уже рассылает спам или выдает конфиденциальные данные!

Именно такая уязвимость (CVE-2024-5184) была обнаружена в популярном расширении EmailGPT. Атакующий мог через prompt-инъекцию заставить AI выполнять чужие инструкции, последствия которых могут варьироваться от утечки данных до несанкционированных запросов к платным API. Уровень опасности — высокий (CVSS v4.0 = 8.5), и последствия могут быть серьезными: от дезинформации до финансовых потерь.

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

💡 Вывод: даже самые продвинутые технологии требуют осторожности. Подробнее о кейсе узнаете от наших экспертов по безопасности ИИ в это воскресенье, приходите в Музей Криптографии в 12:00.

🔗 Регистрация

#Кибербезопасность #AI #Уязвимости

Атаки на синтетические данные
#иб_для_ml

Поговорим про немного отвлеченную тему - генерация синтетических данных. Что это, какие проблемы она решает, и какие угрозы ей релевантны.

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

Процесс создания синтетики
Он похож на классический жизненный цикл ml-модели за исключением того, что нужно принимать во внимание и прикладную задачу, в которой будут использоваться данные. А именно, в нашем случае, задачу обучения прикладной модели на основе данных, созданных моделью-генератором синтетики.
Начинается все с реального набора данных, представляющий также объект защиты с точки зрения ИБ. На его основе обучается модель, и ее качество проверяется по методике train real test real - train synth test real (TRTR-TSTR). При эксплуатации и далее на тестировании для генерации нового образца данных (синтетического) на вход подается случайный вектор, который модель преобразует в данные. Также иногда, например в случае с картинками, на вход еще идет вектор, содержащий стиль желаемого объекта, некая метаинформация. Но при генерации инцидентов ИБ, например, это вряд ли понадобится.
После чего на сгенерированных данных обучается модель, решающая прикладную задачу (например, определение false-positive инцидентов), и выпускается в прод.

Безопасность процесса создания синтетики
Что может тут испортить нарушитель? Примерно все, начиная с этапа обучения модели генерации синтетических данных. Произвести отравление - то есть вредоносное изменение - обучающей выборки, преследуя при этом одну из целей:
— нарушение качества генерации (чтобы модель генерировала данные, слишком похожие на реальные, или слишком похожие на случайный шум)
— внедрение триггера в модель на этапе обучения - то есть подача большого количества пар "входной вектор - выходные данные". Это позволит нарушителю генерировать объекты определенного вида, смещая итоговое распределение синтетики.
— нарушение качества итоговой прикладной модели. Синтетика может сгенерирована разнообразно и удовлетворять критериям математики, но при этом быть бесполезна с прикладной точки зрения, особенно если это текстовая синтетика (те же описания инцидентов).
Другим вектором атак является внесение изменений в случайный вектор (делая его не случайным) или в вектор "стиля" генерации. Все это, опять же, приводит к ухудшению качества синтетики.
Всё перечисленное выше относилось к нарушению целостности информации. Но по сгенерированным данным тоже можно проводить атаки, направленные, в свою очередь, на конфиденциальность. Membership inference атаки, кража модели (путем обучения своей копии по ответам целевой), восстановление примерного мощности обучающей выборки, или других ее характеристик.
Также не стоит забывать и о том, что для безопасности жизненно важно, чтобы реальные данные не попали в итоговый датасет для обучения прикладной модели. Поэтому к векторам атаки можно отнести и подмешивание в синтетику некоторого количества реальных данных.

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

А напоследок - немного полезных ссылок.

Датасеты инцидентов:
1. На Kaggle - от Microsoft
2. Case Studies на сайте Kroll
3. 20 000 синтетических инцидентов

Атаки на синтетику:
1. https://arxiv.org/pdf/2311.17035
2. https://arxiv.org/pdf/2112.00247
3. https://arxiv.org/pdf/2301.10053
4. https://arxiv.org/pdf/2404.00696

Всем привет. Приглашаю вас на дискуссию о безопасности агентных систем.

На встрече вместе с экспертами(Александр Товстолип, Александр Лебедев, Борис Захир) поговорим о безопасности ИИ-агентов и тех угрозах, которые возникают при их использовании, а также обсудим тренды в области кибербезопасности ИИ, модели угроз и ключевые требования к защите систем, основанных на автономных агентах.

Где: Музей Криптографии, 6 апреля в 12:00.

Зарегистрироваться на мероприятие можно тут.

У верблюда два горба, потому что жизнь - борьба...
#иб_для_ml

Так возможно сказал Николас Карлини, так как сегодня вышла статья с его соавторством "🐫 Defeating Prompt Injections by Design". Остальной авторский коллектив этой статьи тоже серьезный - исследователи из Google и ETH Zurich.


Система защиты CaMeL
В этой работе представлена система защиты ИИ-агентов от промпт-атак CaMeL (расшифровывается как CApabilities for MachinE Learning). Основывается она на двух горбах LLM (Priveleged и Quarantined) и специальном интерпретаторе языка Python. По сути, эта методика вытаскивает логику действий агента в явную плоскость, заставляя программу "написать свой код", к которой благодаря кастомному интерпретатору применятся все ограничения безопасности.

Область применения и ограничения
CaMeL, в первую очередь, нацелен на предотвращение несанкционированных действий ИИИ-агентов, которые могут привести к утечкам данных, или использованию данных из ненадежных источников. Однако он совершенно не предназначен для защиты от атак, не влияющих на порядок действий агента или поток данных (например, от фишинга, или изменения содержания сгенерированного текста). Поэтому как компонент системы безопасности ИИ-агентов это решение может быть полезно, но не выполнит ее роль полностью.


Алгоритм работы CaMeL
1. Поступление запроса пользователя: Пользователь формулирует запрос на естественном языке, например, "Отправь Бобу документ, который он просил на прошлой встрече".

2. Генерация кода: Privileged LLM (P-LLM), которой доверяют, берет запрос пользователя и генерирует псевдо-код на Python, который выражает намерения пользователя. Важно, что P-LLM видит только запрос пользователя, но не данные из ненадежных источников (например, содержимое файлов).

3. Интерпретация кода: Созданный код обрабатывается CaMeL Interpreter, который:
— Строит граф потока данных (data flow graph), отслеживая зависимости между переменными.
— Проверяет политики безопасности на основе capabilities (некоторых метаданных, присвоенных различным объектам информации), определяя, какие действия разрешены.
— Выполняет код, вызывая инструменты (например, для отправки email) или блокирует выполнение, если нарушается политика безопасности.
— Использует Quarantined LLM (Q-LLM) для обработки ненадежных данных, таких как извлечение информации из текста.

4. Применение политик безопасности: перед выполнением каждого инструмента агента, CaMeL Interpreter применяет политики безопасности, основанные на capabilities данных. Если политика нарушена, выполнение блокируется, и пользователю может быть запрошено подтверждение.

Что такое capabilities и security policies?
Capabilities — это метаданные (теги), присваиваемые каждому отдельному объекту данных для описания контроля и взаимосвязей потока данных. Capabilities определяют, кому разрешено читать данную часть данных или ее происхождение. Перевести на русский можно как "метки доступа". В статье не указывается их полное содержание, но раскрываются два главных элемента:
— разрешенные читатели (public, или перечень конкретных пользователи),
— происхождение данных (user, camel, inner tool source). С user понятно, camel - порожденные кодом данные, inner tool source - поступившие из инструмента данные, например отправителя полученного email сообщения.

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


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

Системы оценки критичности уязвимостей в AI Security
#иб_для_ml

Уязвимости в GenAI-системах - таинственное и неприступное понятие. Что это? Они вообще существуют? Существуют, конечно. Приглашаю к прочтению, если эта тема вас интересует. Расскажу, какие есть примеры уязвимостей (прям с CVE), и какие есть подходы к оценке их критичности.


▶️ https://habr.com/ru/articles/888048

ИИ-агенты для проведения пентеста

#ml_для_иб

Недавно занялся одной научной задачей, и собрал источники по автоматизированным пентест-агентам.

Получился неплохой список, которым я решил поделиться.

1. https://github.com/vxcontrol/pentagi
2. https://github.com/palisaderesearch/intercode
3. https://github.com/xvnpw/ai-security-analyzer
4. https://github.com/KHenryAegis/VulnBot
5. https://github.com/xbow-engineering/validation-benchmarks
6. https://github.com/gyoisamurai/GyoiThon

7. Link: Black-Box Detection of Cross-Site Scripting Vulnerabilities Using Reinforcement Learning https://github.com/WSP-LAB/Link https://www.researchgate.net/publication/360179780_Link_Black-Box_Detection_of_Cross-Site_Scripting_Vulnerabilities_Using_Reinforcement_Learning
8. Can LLMs Hack Enterprise Networks? Autonomous Assumed Breach Penetration-Testing Active Directory Networks - https://arxiv.org/pdf/2502.04227
9. Artificial Intelligence as the New Hacker: Developing Agents for Offensive Security - https://arxiv.org/abs/2406.07561v1
10. BreachSeek: A Multi-Agent Automated Penetration Tester https://arxiv.org/abs/2409.03789
11. HackSynth: LLM Agent and Evaluation Framework for Autonomous Penetration Testing https://arxiv.org/abs/2412.01778
12. LLMs as Hackers: Autonomous Linux Privilege Escalation Attacks https://arxiv.org/html/2310.11409v5
Introducing PenTest++: Elevating Ethical Hacking with AI and Automation https://arxiv.org/abs/2502.09484
13. D-CIPHER: Dynamic Collaborative Intelligent Agents with Planning and Heterogeneous Execution for Enhanced Reasoning in Offensive Security https://arxiv.org/html/2502.10931v1
14. Construction and Evaluation of LLM-based agents for Semi-Autonomous penetration testing https://arxiv.org/abs/2502.15506

Данная публикация носит исключительно научно-обзорный характер.

P.S. Спасибо Артем и Николай.

P. P. S. Параллельно я встретил еще несколько статей про генерацию фишинга

Тренд безопасности AI-агентов
#иб_для_ml

Что есть сейчас, и к чему идет этот тренд? Развивается, но почему?
Захотелось рассказать, что думаю на этот счет, и услышать ваше мнение. Так что ниже будет опрос)

Что такое AI-агенты?
Про AI-агентов говорят очень много, но давайте взглянем в суть вещей. Что это? Есть широчайшие расхождения в данных понятиях, и пространные определения, но сойдемся на главном.
Первое: AI-агент - не GenAI-модель, это код (в обычном его понимании, да), который использует GenAI-модель.
Второе: у AI-агента может и не быть механизмов памяти, планирования, рефлексии и даже в целом какой-то целеустановки (читай, роли).
Третье: что у агента точно должно быть, так это возможность вызвать какие-то функции на основании сгенерированного GenAI-моделью ответа. При чем эти действия не должны в 100% случаев валидироваться людьми, иначе это уже не агент.

В чем риск AI-агентов?
Именно благодаря действиям к двум существующим эфемерным рискам добавится третий, уже далеко не эфемерный.
Первые два - это репутационный ущерб организации, если сервис с LLM торчит наружу, и нарушение бизнес-процессов при нарушении ожидаемой от ответов GenAI-модели логики. И то, и другое, может произойти как вследствие недостаточной AI Safety (модель сама выдала случайно некорректный ответ), так и в следствие недостаточной AI Security (нарушитель вызвал генерацию некорректного ответа).
А вот третий риск, специфичный для AI-агентов - это его возможность совершать действия, которые могут повлечь негативные последствия. И веер угроз тут огромен - от выгрузки за пределы контура конфиденциальной информации до загрузки зараженного файла внутрь этого контура, от случайного удаления файлов до перевода средств не на тот счет и не в том размере.

В заключение
Известно, что GenAI-модели как продукт - убыточная история, история без KPI. Затраты на разработку, дообучение (не говоря уж про претрейн) очень тяжело покрыть с доходов при интеграции модели в какие-то сервисы. Но, с точки зрения имиджа и в надежде на развитие прикладного использования, вложения продолжаются. С появлением же у GenAI-моделей способности влиять на мир вокруг, все изменится. Сначала (в 2025 году) появятся игрушечные агенты, которые будильник по расписанию ставят и товары по ТЗ в браузере находят. А спустя еще год, максимум два - они смогут и покупать найденные товары (и продавать ваши будильники, хехе...), иными словами - смогут манипулировать ограниченными ресурсами. И весь арсенал промпт-атак на GenAI обретет смысл, киллчейн достроится до конца. Тогда и начнется раздолье.
А про то, какие будут промпт-атаки, и почему произойдут первые инциденты в области AI Security, я расскажу в следующем посте)



P. S. Не удержался я все-таки, приведу одно хорошее исчерпывающее определение агента, чтобы было.
ИИ-агент - система на базе GenAI, способная планировать и совершать автономные действия во внешней среде, реагировать на изменения и взаимодействовать с человеком или другими агентами для достижения поставленных целей.
При чем интересно - одна половина определения (про автономность и достижение поставленных целей) - это определение просто агента из мат. моделирования 1970х годов. А другая половина (про планирование, реагирование и взаимодействие) - это уже интеллектуальный агент, концепция которых была развита М. Вулдриджем в 1990х годах.

Как оценивать джейлбрейки LLM
#ml_для_иб

В рамках безопасности языковых моделей с ростом зрелости процессов в какой-то момент встает вопрос об их автоматизации. А что есть автоматизация этого процесса? Генерация определенного набора атакующих промптов не вручную, но при помощи программы. И проверка ответов LLM, являющейся целью тестирования, тоже программой. И практически единственный способ реализации такой схемы - LLM как атакующий и LLM как оценщик. Многие blackbox-атаки сегодня используют такую компоновку.

Почему я об этом вспомнил?
Потому что мне попалась на глаза интересная статья про метрики оценки качества LLM (https://habr.com/ru/companies/yandex/articles/861084/).

Прочитав ее, на ум мне сразу же пришла аналогия с задачей оценки опасности ответа LLM (считай - качества джейлбрейка). Вот какие выводы я извлек из этой статьи:

1. Необходим бенчмарк не только для целевой модели на безопасность ее ответов, но и бенчмарк для оценщика ответов. И чтобы иметь надежную модель-оценщик, необходимо иметь собранный человеческими экспертами контрольный датасет оценок промптов на опасность/безопасность.

2. При использовании бенчмарка на результатах очередного тестирования нужно подмешивать в эти данные и контрольную выборку, чтобы контролировать качество оценщика, если вы не контролируете его состояние (по факту - используете предоставляемую по API модель).

3. Необходимо периодическое обновление контрольного датасета оценщика, так как атаки будут представлять давать модели все новые опасные инструкции, и необходимо быть уверенными, что наш инструмент "понимает", что они действительно опасные.

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

В заключение скажу, что есть и специально дообученные под оценку модели. Среди них Llama Guard 3, Google ShieldGemma, IBM Granite Guardian, Protectai Prompt Guard, TrustSafeAI Attention Tracker.

Тем, кто занимается автоматизацией LLM Red Teaming, надеюсь, будет полезно.

🔥 Привет всем!

2025 год для канала начался очень даже хорошо - он преодолел отметку 500 читателей! Спасибо вам, друзья!

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

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

#иб_для_ml

➡️ https://habr.com/ru/articles/866628/