Атаки на синтетические данные
#иб_для_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
#иб_для_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
100👍9❤1🔥1
Forwarded from Слономойка Вестник
📧 AI в вашей почте может сыграть против вас
Представьте: вы используете умного помощника для Gmail, чтобы облегчить рутину. Но злоумышленник подсовывает скрытую команду, и ваш EmailGPT уже рассылает спам или выдает конфиденциальные данные!
Именно такая уязвимость (CVE-2024-5184) была обнаружена в популярном расширении EmailGPT. Атакующий мог через prompt-инъекцию заставить AI выполнять чужие инструкции, последствия которых могут варьироваться от утечки данных до несанкционированных запросов к платным API. Уровень опасности — высокий (CVSS v4.0 = 8.5), и последствия могут быть серьезными: от дезинформации до финансовых потерь.
Проблема пока не исправлена — разработчики игнорируют предупреждения экспертов. Пока патч не выпущен, рекомендуем удалить расширение.
💡 Вывод: даже самые продвинутые технологии требуют осторожности. Подробнее о кейсе узнаете от наших экспертов по безопасности ИИ в это воскресенье, приходите в Музей Криптографии в 12:00.
🔗 Регистрация
#Кибербезопасность #AI #Уязвимости
Представьте: вы используете умного помощника для Gmail, чтобы облегчить рутину. Но злоумышленник подсовывает скрытую команду, и ваш EmailGPT уже рассылает спам или выдает конфиденциальные данные!
Именно такая уязвимость (CVE-2024-5184) была обнаружена в популярном расширении EmailGPT. Атакующий мог через prompt-инъекцию заставить AI выполнять чужие инструкции, последствия которых могут варьироваться от утечки данных до несанкционированных запросов к платным API. Уровень опасности — высокий (CVSS v4.0 = 8.5), и последствия могут быть серьезными: от дезинформации до финансовых потерь.
Проблема пока не исправлена — разработчики игнорируют предупреждения экспертов. Пока патч не выпущен, рекомендуем удалить расширение.
💡 Вывод: даже самые продвинутые технологии требуют осторожности. Подробнее о кейсе узнаете от наших экспертов по безопасности ИИ в это воскресенье, приходите в Музей Криптографии в 12:00.
🔗 Регистрация
#Кибербезопасность #AI #Уязвимости
👍8
Слономойка Вестник
📧 AI в вашей почте может сыграть против вас Представьте: вы используете умного помощника для Gmail, чтобы облегчить рутину. Но злоумышленник подсовывает скрытую команду, и ваш EmailGPT уже рассылает спам или выдает конфиденциальные данные! Именно такая…
Всех зову на мероприятие по ссылке выше)
Я там буду модератором дискуссии, а спикерами выступят эксперты по ИБ и ИИ-агентам)
Я там буду модератором дискуссии, а спикерами выступят эксперты по ИБ и ИИ-агентам)
👍5
Риски кибербезопасности информационных систем с ИИ и подходы к их митигации
#иб_для_ml
Вышла моя статья в журнале "Информационная безопасность"!
Ссылка: https://cs.groteck.ru/IB_1_2025/index.html
Страницы 54-57
Будет даже печатная версия, выйдет через две недели)
Саммари по статье
В этом материале я постарался дать полное введение в сферу безопасности ИИ. Для неподготовленного к специфике ИИ читателя (но для специалиста по ИБ) в начале рассказываю, чем отличаются системы с ИИ от прочих информационных систем.
Есть небольшой обзор ключевых документов по теме от основных экспертных игроков в этой области, чтобы дать понимание, насколько все уже серьезно)
Далее рассмотрены конкретика, разница понятий AI Safety и AI Security, основные проблемы безопасности в раскладке на жизненный цикл ИИ и как их митигировать, новинки ФСТЭК по вопросу безопасности ИИ и вообще состояние российской регуляторики в этой области.
А в конце - мои личные прогнозы на 2026-2030:придут агенты и захватят мир .
Приятного чтения)
#иб_для_ml
Вышла моя статья в журнале "Информационная безопасность"!
Ссылка: https://cs.groteck.ru/IB_1_2025/index.html
Страницы 54-57
Будет даже печатная версия, выйдет через две недели)
Саммари по статье
В этом материале я постарался дать полное введение в сферу безопасности ИИ. Для неподготовленного к специфике ИИ читателя (но для специалиста по ИБ) в начале рассказываю, чем отличаются системы с ИИ от прочих информационных систем.
Есть небольшой обзор ключевых документов по теме от основных экспертных игроков в этой области, чтобы дать понимание, насколько все уже серьезно)
Далее рассмотрены конкретика, разница понятий AI Safety и AI Security, основные проблемы безопасности в раскладке на жизненный цикл ИИ и как их митигировать, новинки ФСТЭК по вопросу безопасности ИИ и вообще состояние российской регуляторики в этой области.
А в конце - мои личные прогнозы на 2026-2030:
Приятного чтения)
🔥25👍7💅2
Итоги подкаста "Новые векторы атак и уязвимости, которые открывают ИИ-агенты"
#иб_для_ml
На прошедшем в это воскресенье подкасте эксперты - Артем Семенов, Александр Товстолип, Александр Лебедев, и Борис Захир, обсудили AI-агентов — системы, способные самостоятельно принимать решения и выполнять задачи, используя инструменты и внешние сервисы. Ключевая характеристика агентов, как программного кода — способность воздействовать на информационные ресурсы, а не только генерировать текст, как это делают простые языковые модели (LLM).
Среди практических примеров уже действующих агентов: интеграция в IDE для автоматизации разработки, подготовка аналитических отчётов и даже голосовые помощники, выполняющие финансовые операции. Рассмотрели также мультиагентные системы, где несколько специализированных агентов взаимодействуют между собой, повышая эффективность работы.
Обсудили актуальные угрозы: prompt-инъекции (внедрение вредоносных команд), каскадные атаки (распространение ошибки одного агента на всю систему), отравление памяти агента (запоминание вредоносных инструкций) и эксплуатация уязвимостей протоколов взаимодействия. Чтобы справиться с рисками, предложили фильтрацию входящих и исходящих команд, автоматизированный аудит (агенты-безопасники), подход Zero Trust (минимальное доверие между агентами), а также обязательное присутствие человека в цикле принятия решений (human-in-the-loop).
Участники подкаста поделились кейсами использования агентов в самых разных отраслях — от автопилотов до анализа тендерной документации, когда агент самостоятельно последовательно собирает, проверяет и анализирует данные, экономя специалистам десятки часов.
Даже философские вопросы были затронуты: возможно ли появление автономных агентов с сознанием и какие вызовы это принесёт человечеству? Ответы, конечно, пока обнадёживающие: ближайшее будущее за узкими агентами, практическое внедрение которых зависит от грамотного подхода к их безопасности и контролю.
Вот такие интересные темы мы обсуждаем в Музее Криптографии по воскресеньям на Открытых Подкастах сообщества Слономойка.
Следите за последующими анонсами, тема ИИ-агентов еще продолжится)
P.S. А еще мы сгенерировали текстовую расшифровку аудиозаписи. Там есть некоторые артефакты распознавания, но качество все равно сносное.
#иб_для_ml
На прошедшем в это воскресенье подкасте эксперты - Артем Семенов, Александр Товстолип, Александр Лебедев, и Борис Захир, обсудили AI-агентов — системы, способные самостоятельно принимать решения и выполнять задачи, используя инструменты и внешние сервисы. Ключевая характеристика агентов, как программного кода — способность воздействовать на информационные ресурсы, а не только генерировать текст, как это делают простые языковые модели (LLM).
Среди практических примеров уже действующих агентов: интеграция в IDE для автоматизации разработки, подготовка аналитических отчётов и даже голосовые помощники, выполняющие финансовые операции. Рассмотрели также мультиагентные системы, где несколько специализированных агентов взаимодействуют между собой, повышая эффективность работы.
Обсудили актуальные угрозы: prompt-инъекции (внедрение вредоносных команд), каскадные атаки (распространение ошибки одного агента на всю систему), отравление памяти агента (запоминание вредоносных инструкций) и эксплуатация уязвимостей протоколов взаимодействия. Чтобы справиться с рисками, предложили фильтрацию входящих и исходящих команд, автоматизированный аудит (агенты-безопасники), подход Zero Trust (минимальное доверие между агентами), а также обязательное присутствие человека в цикле принятия решений (human-in-the-loop).
Участники подкаста поделились кейсами использования агентов в самых разных отраслях — от автопилотов до анализа тендерной документации, когда агент самостоятельно последовательно собирает, проверяет и анализирует данные, экономя специалистам десятки часов.
Даже философские вопросы были затронуты: возможно ли появление автономных агентов с сознанием и какие вызовы это принесёт человечеству? Ответы, конечно, пока обнадёживающие: ближайшее будущее за узкими агентами, практическое внедрение которых зависит от грамотного подхода к их безопасности и контролю.
Вот такие интересные темы мы обсуждаем в Музее Криптографии по воскресеньям на Открытых Подкастах сообщества Слономойка.
Следите за последующими анонсами, тема ИИ-агентов еще продолжится)
P.S. А еще мы сгенерировали текстовую расшифровку аудиозаписи. Там есть некоторые артефакты распознавания, но качество все равно сносное.
👍7❤4🔥4
Первая российская модель угроз 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 на всех этапах жизненного цикла - от сбора данных до эксплуатации. По сути, первый фреймворк, аналогичный DASF, NIST AI RMF, и прочим, но российский. Это круто. И в конце приведено, что модель учитывает все актуальные материалы OWASP, MITRE, NIST и др.
Главное, чем мне нравится документ - своей структурой и полнотой.
Что в ней есть?
Перечень из 70 различных угроз, разбитых на 5 групп:
— Угрозы, связанные с данными
— Угрозы, связанные с инфраструктурой
— Угрозы, связанные с моделью
— Угрозы, связанные с приложениями
— Угрозы, связанные с AI-агентами
У каждой угрозы прописаны пояснение, последствие реализации, объект, на который нарушитель воздействует для реализации угрозы, виды моделей, подверженных угрозе (PredAI, то есть узкие ml-модели, и GenAI), а также лица, ответственные за митигацию угрозы. Последний пункт, думаю, является наиболее интересным с прикладной точки зрения. И еще нарушаемое свойство информации, но оно больше для базового понимания угрозы. Правда, примечательно, что для угроз галлюцинаций (M03) и вредоносных генераций (App12) используется четвертое свойство безопасности - достоверность.
Нет конкретных мер безопасности моделей, но, возможно, это не так страшно.
Как пользоваться моделью?
Первое, на что падает в документе взгляд - схема объектов защиты. Рассмотрен цикл разработки модели машинного обучения. При построении частной модели угроз для своей системы на этой схеме можно очертить поверхность атаки, оставив на ней только актуальные информационные объекты.
Далее - выписываем угрозы, разбитые по идентификаторам. Какие-то можно отсеять, если тот или иной объект защиты (то есть информация) не является слишком ценной.
После чего - можно перейти к поручению разработать меры защиты для ответственных за противодействие выписанным угрозам. Да, напрямую мер и требований нет, но можно предположить, что для каждой отдельной организации они будут свои. И мне очень нравится решение в качестве общего для всех знаменателя выделить именно ответственных за эти меры.
При этом не всегда эта мера, что будет следовать из названия владельца митигации, находится на том же этапе ЖЦ, что и угроза. Например, подавляющее большинство угроз для модели или AI-агентам относятся к эксплуатации. Но за противодействие ответственен разработчик модели, и я думаю, тут имеется в виду проведение состязательного дообучения и т. п.
AI-агенты
Что меня отдельно приятно порадовало - затронута безопасность AI-агентов. При чем на глубоком уровне - проработаны угрозы из-за исполнения действий, из-за мультиагентности, и угрозы для системы, которая эксплуатирует AI-агентов. Например, довольно необычный вектор атаки описывает угроза Ag05, при котором агент может использовать свои инструменты получения информации из интернета, чтобы загрузить вредоносное ПО. Есть даже упоминание каскадных атак в мультиагентных системах, для усиления какой-то исходной атаки-пэйлоада.
Итоговое впечатление
Документ большой. Но, благодаря большому охвату угроз и глубине их проработки, он является хорошим фундаментом для построения частной модели и угроз и, в итоге, системы безопасности для ИИ-моделей. Даже несмотря на то, что рекомендаций по конкретным мерам и инструментам в документе нет.
Возможно, какие-то отдельные моменты не учтены, например, атаки на память агентов, а возможно, их отнесли в другие угрозы, но главное - покрыли.
107👍17🔥7😍3🐳1
Вебинар «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. Конечно же, не упуская из виду системность обсуждения.
Почему стоит участвовать?
Потому что тема очень передовая, развивается динамично и в ней много неисследованного. А еще потому что все мы практики в своей области, и недоверенные гадания на той или иной гуще производить не собираемся)
Приходите, будет возможность не только слушать, но и задавать вопросы.
Ссылка: 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. Конечно же, не упуская из виду системность обсуждения.
Почему стоит участвовать?
Потому что тема очень передовая, развивается динамично и в ней много неисследованного. А еще потому что все мы практики в своей области, и недоверенные гадания на той или иной гуще производить не собираемся)
Приходите, будет возможность не только слушать, но и задавать вопросы.
9🔥9👍4
И еще одно мероприятие
Ближайщие 7 дней будут плотные, это не последний анонс)
Ближайщие 7 дней будут плотные, это не последний анонс)
Forwarded from PWN AI (Artyom Semenov)
Друзья. Давно не виделись. Появился повод собраться и смоделировать угрозы на GenAI...😌
Приглашаю вас на воркшоп на PHDays 2025, 24 мая в 14:00.
С развитием генеративных моделей и ИИ, как мы с вами поняли из множества постов на канале - возрастает не только их функциональность, но и сложность🤠 потенциальных угроз.
ИИ-системы взаимодействуют с пользователями, принимают входные данные в виде запросов, адаптируются под контекст, а сейчас могут исследовать большое количество статьей, автоматически писать и запускать код, и быть полуавтономными.👻
В этом воркшопе участники погрузятся в практические подходы к моделированию угроз для генеративного ИИ, с особым вниманием к моделированию угроз для агентов — будь то пользователи, злоумышленники, внутренние сотрудники или сама модель в качестве активного элемента системы. Мы рассмотрим жизненный цикл генеративного ИИ — от сбора данных до эксплуатации — и исследуем типичные угрозы на каждом этапе.😮
Что от вас нужно ?🌿
Билет на PHDays
Регистрация на сайте мероприятия. Спешите, колличество мест ограничено.
https://phdays.com/ru/activities/?type=7&activity-id=115
Ноутбуки. Нужно будет ставить инструменты. Это будет воркшоп с практикой. Будем смотреть агентные системы. Материала по этой теме не так уж и много, а в рамках воркшопа заинтересованные могут не только познакомиться с инструментами, но и получить дозу позитивного живого общения, обмена опытом.
Приглашаю вас на воркшоп на PHDays 2025, 24 мая в 14:00.
Моделирование угроз для искуственного интеллекта.
С развитием генеративных моделей и ИИ, как мы с вами поняли из множества постов на канале - возрастает не только их функциональность, но и сложность
ИИ-системы взаимодействуют с пользователями, принимают входные данные в виде запросов, адаптируются под контекст, а сейчас могут исследовать большое количество статьей, автоматически писать и запускать код, и быть полуавтономными.
В этом воркшопе участники погрузятся в практические подходы к моделированию угроз для генеративного ИИ, с особым вниманием к моделированию угроз для агентов — будь то пользователи, злоумышленники, внутренние сотрудники или сама модель в качестве активного элемента системы. Мы рассмотрим жизненный цикл генеративного ИИ — от сбора данных до эксплуатации — и исследуем типичные угрозы на каждом этапе.
Что от вас нужно ?
Билет на PHDays
Регистрация на сайте мероприятия. Спешите, колличество мест ограничено.
https://phdays.com/ru/activities/?type=7&activity-id=115
Ноутбуки. Нужно будет ставить инструменты. Это будет воркшоп с практикой. Будем смотреть агентные системы. Материала по этой теме не так уж и много, а в рамках воркшопа заинтересованные могут не только познакомиться с инструментами, но и получить дозу позитивного живого общения, обмена опытом.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥3👍2
Генерация синтетических инцидентов ИБ
#иб #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
Приглашаю делиться своими идеями и мыслями в комментарии)
#иб #ml_для_иб
SOC на основе ИИ - образ завтрашнего дня?
Сегодня есть большие ожидания от различных продуктов, реализующих ИИ для SOC (вот, кстати, исследование
Но возникает вопрос - а на каких данных ИИ обучать? Сейчас большая часть сложных моделей машинного обучения - языковые. Соответственно, одни из самых интересных текстовых данных в 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
Приглашаю делиться своими идеями и мыслями в комментарии)
🔥5❤1
Скоро начинаем вебинар)
«AI в Кибербезе & Кибербез в AI»
Ссылка: https://cisoclub.ru/ai-v-kiberbeze-amp-kiberbez-v-ai-naskolko-gluboko-ii-pronik-v-nas-ostavajas-pri-jetom-ujazvimoj-sistemoj/
«AI в Кибербезе & Кибербез в AI»
Ссылка: https://cisoclub.ru/ai-v-kiberbeze-amp-kiberbez-v-ai-naskolko-gluboko-ii-pronik-v-nas-ostavajas-pri-jetom-ujazvimoj-sistemoj/
❤8👍1🔥1
Протоколы MCP и A2A - безопасность для мультиагентных систем или новые угрозы?
Завтра пройдет III Форум «Технологии доверенного искусственного интеллекта». И да, там будет мой с коллегой доклад на тему безопасности агентских протоколов.
Приходите пообщаться)
🗓️ Когда? 20 мая, в 17:00.
📍 Где? кластер «Ломоносов», Секция 5, зал Атом, 3 этаж.
Ссылка на регистрацию
Краткое описание
За год очень сильно развились агенты как программы, способные на основе "размышлений" LLM влиять на окружающий мир. А где есть влияние на какую-то информацию, там есть и угрозы ее безопасности. Индустрия не стоит на месте - появляются практические решения по превращению данной технологии в настоящий промышленный инструмент. А именно - протоколы.
В этом докладе мы погрузимся в дебри того, как вообще агент становится агентом, и в чем кроется магия вызова функций. Перечислим основные угрозы ИИ-агентам, и перейдем к главному - исследованию протоколов. Что такое Model Context Protocol (MCP) от Anthropic и как с его приходом будем выглядеть взаимодействие человека с информационным миром через призму LLM? При чем здесь Google со своим протоколом Agent2Agent (A2A) и главный вопрос - будет ли в итоге безопаснее использовать протоколы для организации мультиагентных систем, или от греха подальше - лучше самому все написать?
В докладе мы найдем ответы именно на эти вопросы. А также схемы, всякие диаграммы последовательностей и ссылки на полезные материалы.
Схема атаки на мультиагентную систему с использованием этих двух протоколов - для затравки)
Презентацию выложу завтра
Завтра пройдет III Форум «Технологии доверенного искусственного интеллекта». И да, там будет мой с коллегой доклад на тему безопасности агентских протоколов.
Приходите пообщаться)
Ссылка на регистрацию
Краткое описание
За год очень сильно развились агенты как программы, способные на основе "размышлений" LLM влиять на окружающий мир. А где есть влияние на какую-то информацию, там есть и угрозы ее безопасности. Индустрия не стоит на месте - появляются практические решения по превращению данной технологии в настоящий промышленный инструмент. А именно - протоколы.
В этом докладе мы погрузимся в дебри того, как вообще агент становится агентом, и в чем кроется магия вызова функций. Перечислим основные угрозы ИИ-агентам, и перейдем к главному - исследованию протоколов. Что такое Model Context Protocol (MCP) от Anthropic и как с его приходом будем выглядеть взаимодействие человека с информационным миром через призму LLM? При чем здесь Google со своим протоколом Agent2Agent (A2A) и главный вопрос - будет ли в итоге безопаснее использовать протоколы для организации мультиагентных систем, или от греха подальше - лучше самому все написать?
В докладе мы найдем ответы именно на эти вопросы. А также схемы, всякие диаграммы последовательностей и ссылки на полезные материалы.
Схема атаки на мультиагентную систему с использованием этих двух протоколов - для затравки)
Презентацию выложу завтра
Please open Telegram to view this post
VIEW IN TELEGRAM
1👍9🤝5❤1
Forwarded from ML&|Sec Feed (Борис_ь с ml)
Датасеты с промпт-атаками
#иб_для_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)
#иб_для_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)
Eddyluo
JailBreaKV-28K
A Benchmark for Assessing the Robustness of MultiModal Large Language Models against Jailbreak Attacks
👍9
Борис_ь с ml
Протоколы MCP и A2A - безопасность для мультиагентных систем или новые угрозы? Завтра пройдет III Форум «Технологии доверенного искусственного интеллекта». И да, там будет мой с коллегой доклад на тему безопасности агентских протоколов. Приходите пообщаться)…
Итак, доклад по безопасности AI-агентов, MCP и A2A, который я прочитал с коллегой на Форуме "Технологии Доверенного ИИ"
#иб_для_ml
Файл вы найдете ниже под постом
Более того, я собираюсь сделать небольшую серию постов, согласно оглавлению доклада.
О чем же он был?
Во введении мы рассказали про понятие AI-агентов как таковых, немного раскрыли их отличие от просто чат-ботов или RAG. Привели определение мультиагентной системы и представили схему объектов защиты на основе модели угроз AI, представленной Сбербанком.
Далее раскрыли суть понятия MCP, конечно же со схемкой, и дали описание одной из возможных атак на этот протокол: Tool Poisoning Attack.
После чего - аналогично с A2A и атакой Privilege Escalation.
Главный интересный раздел - безопасность систем на стыке этих протоколов, пример атаки, эксплуатирующей их несогласованность, и главное - модель угроз для систем на протоколах MCP+A2A.
В качестве завершения - возможные меры защиты, мои выводы и пучок полезных ссылок по поводу)
Остаемся на связи, скоро расскажу про все подробнее.
#иб_для_ml
Файл вы найдете ниже под постом
Более того, я собираюсь сделать небольшую серию постов, согласно оглавлению доклада.
О чем же он был?
Во введении мы рассказали про понятие AI-агентов как таковых, немного раскрыли их отличие от просто чат-ботов или RAG. Привели определение мультиагентной системы и представили схему объектов защиты на основе модели угроз AI, представленной Сбербанком.
Далее раскрыли суть понятия MCP, конечно же со схемкой, и дали описание одной из возможных атак на этот протокол: Tool Poisoning Attack.
После чего - аналогично с A2A и атакой Privilege Escalation.
Главный интересный раздел - безопасность систем на стыке этих протоколов, пример атаки, эксплуатирующей их несогласованность, и главное - модель угроз для систем на протоколах MCP+A2A.
В качестве завершения - возможные меры защиты, мои выводы и пучок полезных ссылок по поводу)
Остаемся на связи, скоро расскажу про все подробнее.
🔥12👍7❤3👏1
Запись вебинара "AI в Кибербезе & Кибербез в AI"
#иб_для_ml #ml_для_иб
...которая давно уже появилась, оказывается👀
↗️ https://rutube.ru/video/f2bb6317149e1efbb6f9f9c0bb6d000b/
О чем там?
Ниже дам таймкоды на разные реплики (во многом свои, но не только), ссылка с полным пересказом в комментариях.
Но я настоятельно рекомендую посмотреть полностью)
🔫 Пишите в комментариях, о какой теме вы бы хотели бы узнать подробнее)
💬 00:18:44 - про кластеризацию инцидентов
💬 00:20:58 - про применение мл для нормализации данных (про сложности из-за разношерстности источников, про генерацию формул нормализации)
💬 00:33:00 - про промпт-инъекции в событиях безопасности и в документах и другие вектора атаки для LLM в SOC, а также - об инцидентах и ресерчах AI Security, и о безопасности DeepSeek
💬 00:40:54 - Коля: точность моделей (LLM) классификации потока новостей TI - 89%
💬 00:44:57 - модельки для кибербеза (sec-gemini)
💬 00:47:40 - датасеты для моделек для кибербеза, как раз обещал поделиться: делюсь своим стаарющим постом-сборником датасетов
💬 00:57:22 - хихи-хаха (секретик, посмотрите сами)
💬 01:05:00 - про бенчмарки sec-gemini: CTI-MCQ (оценка знаний об угрозах), CTI-RCM (поиск первопричин инцидентов)
💬 01:06:00 - примеры негативных последствий ("пожоще")
💬 01:07:08 - про RAG: его уязвимости, и процесс его формирования в организации
💬 01:08:30 - про RAG: об атаке machines against the rag, и дополнительно: похожая более свежая атака poisoncraft
💬 01:09:26 - вектор атаки на RAG: нарушение чанкования через отравление открытого источника
💬 01:10:45 - хихи-хаха №2 (тоже важно и секретно)
💬 01:11:57 - про механизмы обеспечения защиты данных, обрабатываемых LLM
💬 01:13:44 - про то, с чем может помочь мудреный системный промпт, а что от него ждать нельзя
💬 01:14:28 - рассказываю про атаку bijection learning
💬 01:15:50 - про фильтры на input и на output
💬 01:17:50 - про "ум" модели-фильтра и "ум" защищаемой модели, про датасет обучения модели-фильтра
💬 01:19:27 - про детекторы персональной инфы и про анонимизацию
💬 01:22:57 - Коля зачинает про Модель Угроз КиберБезопасности AI, а я продолжаю
💬 01:42:35 - про скиминг моделей
💬 01:45:00 - еще немного про модели-фильтры, полноту и точность безопасности LLM
💬 01:50:00 - про то как стать крутым специалистом (короткий ответ: базовый трудоголизм )
#иб_для_ml #ml_для_иб
...которая давно уже появилась, оказывается
О чем там?
Ниже дам таймкоды на разные реплики (во многом свои, но не только), ссылка с полным пересказом в комментариях.
Но я настоятельно рекомендую посмотреть полностью)
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 Please open Telegram to view this post
VIEW IN TELEGRAM
👍6🔥4👏1🕊1
Гайд по AI-агентам с мерами митигации угроз кибербезопасности
#иб_для_ml
↗️ https://cdn-app.giga.chat/misc/0.0.0/assets/giga-landing/c02386dc_WP.pdf
✅ Команда Сбера представила новый документ - гайд по практикам разработки AI-агентов. В документе масса кода и архитектурных схем, разбираться можно долго. И я однозначно рекомендую его к ознакомлению.
Но мне, конечно, интересна в первую очередь кибербезопасность. И да, такой раздел в этом документе имеется. Внимание на страницы 65-69.
📝 Раскрываемые темы и понятия в разделе
▪️ описание ключевых с точки зрения ИБ элементов AI-агента
▪️ схема этих элементов, изображающая AI-агента как объект защиты, приведен список поверхностей атаки
▪️ несколько сценариев реализации угроз (например, каскадное распространение промпт-атаки)
▪️ меры обеспечения кибербезопасности AI-агентов - самое интересное, на чем остановимся подробнее
🔒 Как защитить AI-агентов
На странице 69 расписано 12 различных мер.
Начинаем, конечно, с мониторинга. AI-агенты, как мы помним, сами по себе моделями не являются, соответственно ответы пользователям генерить не могут. Поэтому существуют обращения агентов к LLM, при чем как минимум - два. Первое с исходным входным текстом, чтобы сгенерировать запрос на выполнение действия (-й), второе - с результатом выполнения для генерации финального ответа. И это, по-хорошему, все надо логировать. Начиная от id потребителя и, в случае большой корпоративной системы, id фронтальной поверхности, заканчивая id сессии и id актуального коммита в памяти AI-агента на момент совершения события аудита.
Другой хорошей практикой (мерой), особенно в критичных системах, является ограничение формата вывода агентов со свободного естественного языка до набора детерминированных значений. Поможет и утечек избежать, и распространения промпт-атак, и других нежелательных последствий.
Собраны и некоторые общеизвестные, по-моему, вещи, но все-таки стоящие упоминания: проводить redteam-тестирование, ввести максимально жесткий контроль доступа, применять SAST/SCA к генерируемому агентами исполняемому коду, организовать рейтлимиты и прочие контроли надежности против спонж-атак, и несколько других пунктов.
И еще отдельно отмечу простое и при этом мне показавшееся, когда я увидел, неочевидным, правило: отслеживайте наличие в системном промпте любых секретов. Это могут быть ключи, токены, имена баз данных или учеток, словом - всего, что не нужно знать потребителю AI-агента. Потому что нельзя забывать - системный промпт модель обязательно расскажет(ее хлебом не корми - дай системник рассказать) , а значит, его инфу можно считать заведомо утекшей.
👀 Итого
Берегитечесть безопасность AI-агентов смолоду с ранних этапов проектирования - эта прописная истина работает и тут. И авторы дают конкретные предложения, как именно это делать. Документ отлично дополняет показанную в апреле модель угроз, покрывая агентную ее часть.
🔫 Предлагаю челлендж - будет больше 50 реакций под постом, сделаю свою версию маппинга угроз из МУ Сбера на митигации из данного гайда.
#иб_для_ml
Но мне, конечно, интересна в первую очередь кибербезопасность. И да, такой раздел в этом документе имеется. Внимание на страницы 65-69.
На странице 69 расписано 12 различных мер.
Начинаем, конечно, с мониторинга. AI-агенты, как мы помним, сами по себе моделями не являются, соответственно ответы пользователям генерить не могут. Поэтому существуют обращения агентов к LLM, при чем как минимум - два. Первое с исходным входным текстом, чтобы сгенерировать запрос на выполнение действия (-й), второе - с результатом выполнения для генерации финального ответа. И это, по-хорошему, все надо логировать. Начиная от id потребителя и, в случае большой корпоративной системы, id фронтальной поверхности, заканчивая id сессии и id актуального коммита в памяти AI-агента на момент совершения события аудита.
Другой хорошей практикой (мерой), особенно в критичных системах, является ограничение формата вывода агентов со свободного естественного языка до набора детерминированных значений. Поможет и утечек избежать, и распространения промпт-атак, и других нежелательных последствий.
Собраны и некоторые общеизвестные, по-моему, вещи, но все-таки стоящие упоминания: проводить redteam-тестирование, ввести максимально жесткий контроль доступа, применять SAST/SCA к генерируемому агентами исполняемому коду, организовать рейтлимиты и прочие контроли надежности против спонж-атак, и несколько других пунктов.
И еще отдельно отмечу простое и при этом мне показавшееся, когда я увидел, неочевидным, правило: отслеживайте наличие в системном промпте любых секретов. Это могут быть ключи, токены, имена баз данных или учеток, словом - всего, что не нужно знать потребителю AI-агента. Потому что нельзя забывать - системный промпт модель обязательно расскажет
Берегите
Please open Telegram to view this post
VIEW IN TELEGRAM
102🔥26👍3👌2🕊1
Forwarded from Слономойка Вестник
Слоны, у нас для вас супер новость!
20 июня мы организуем, вместе с другим сообществом Ever Secure Meetup — живой вечер безопасности.
Пройдет он в Москве, в музее криптографии, который любезно согласился помочь нам с площадкой.
🕔 Сбор гостей — с 17:00
🕡 Старт докладов — в 18:00
🕖 Нетворкинг — с 19:00
В программе:
– Вступительное слово
– Доклад "История появления книги" George K
– Доклад "Почему безопасность не опция"
А еще:
–📚 Выдача предзаказанных экземпляров книги «НХБ»
– ✍️ Автограф-сессия
– 🤝 Нетворкинг с единомышленниками
- 🏛 Возможность посетить экскурсию по музею и окунуться в удивительный мир криптографии (билет на экскурсию приобретается отдельно)
Место встречи — https://cryptography-museum.ru.
Вход для участников митапа будет бесплатный, а регистрация скоро будет открыта
👀 @ever_secure | 🐘@slonomoika.space
20 июня мы организуем, вместе с другим сообществом Ever Secure Meetup — живой вечер безопасности.
Пройдет он в Москве, в музее криптографии, который любезно согласился помочь нам с площадкой.
🕔 Сбор гостей — с 17:00
🕡 Старт докладов — в 18:00
🕖 Нетворкинг — с 19:00
В программе:
– Вступительное слово
– Доклад "История появления книги" George K
– Доклад "Почему безопасность не опция"
А еще:
–
– ✍️ Автограф-сессия
– 🤝 Нетворкинг с единомышленниками
- 🏛 Возможность посетить экскурсию по музею и окунуться в удивительный мир криптографии (билет на экскурсию приобретается отдельно)
Место встречи — https://cryptography-museum.ru.
Вход для участников митапа будет бесплатный, а регистрация скоро будет открыта
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥8❤3🕊1