Жизненный цикл, данные и АНБ. Новый американский стандарт описывает лучшие практики по защите данных для AI. И, наверное, все мы понимаем базовое вроде «не должно быть перекоса в данных», «должен быть контроль доступа и очистка». Но как видит это АНБ? Тут всё не так уж и однозначно.
Это не фреймворк, в классическом понимании. Но что-то схожего тут есть – например рассматривают меры для жизненного цикла данных, раскладывают его по полочкам.
Как отмечается в документе, успешные стратегии управления данными должны гарантировать, что данные не были подвергнуты несанкционированному изменению на любом этапе жизненного цикла ИИ, не содержат вредоносного, а также не имеют непреднамеренной дублирующей или информации, которая может быть аномалией.
NSA определяет следующие риски:
1.Цепочка поставок. Тут кристально понятно. Они, кстати, приводят в пример кейс с отравлением википедии, когда злоумышленник вносит вредоносные правки непосредственно перед тем, как сайты с краудсорсинговым контентом делают снимок своих данных. Также уделили внимание на своей аналитике – отравление датасета LAION-2B – для злоумышленника может стоить от 60$ до 1000, а эффект будет большой.
2. Предвзятость, состязательные примеры, искажающие процесс обучения, проблемные метаданные и некачественный датасет – всё это относят ко второму типу угроз,
3. Дрейф данных. Хотя документ упоминает дрейф данных как один из рисков безопасности данных на некоторых этапах жизненного цикла, подробное описание этого риска и стратегий его снижения в документе отсутствует.
Между этим как мне кажется можно было бы определить угрозы, связанные с синтетикой, а может и нет … всё-таки ж речь про безопасность. К этим рискам они отнесли рекомендации:
NSA дают общие рекомендации:
1.Использование надежных источников данных и отслеживание происхождения
2.Проверка и поддержание целостности данных
3. Использование цифровых подписей
4. Использование доверенной инфраструктуры
5. Классификация данных и контроль доступа
6. Шифрование данных (AES-256)
7. Безопасное хранение данных (должны храниться на устройствах, соответствующих NIST FIPS 140–3)
8. Методы сохранения конфиденциальности (Дифференциальная приватность, федеративное обучение)
9. Безопасное удаление данных (в соответствии с NIST SP 800-88)
10. Проводить регулярную оценку безопасности данных (также в соответствии с NIST SP 800-3r2 и NIST AI 100-1)
По их мнению, да и по лучшим стандартам сейчас для цепочки поставок можно реализовывать хеширование данных, регулярно смотреть целостность.
ну а ссылка вот.
Это не фреймворк, в классическом понимании. Но что-то схожего тут есть – например рассматривают меры для жизненного цикла данных, раскладывают его по полочкам.
Как отмечается в документе, успешные стратегии управления данными должны гарантировать, что данные не были подвергнуты несанкционированному изменению на любом этапе жизненного цикла ИИ, не содержат вредоносного, а также не имеют непреднамеренной дублирующей или информации, которая может быть аномалией.
NSA определяет следующие риски:
1.Цепочка поставок. Тут кристально понятно. Они, кстати, приводят в пример кейс с отравлением википедии, когда злоумышленник вносит вредоносные правки непосредственно перед тем, как сайты с краудсорсинговым контентом делают снимок своих данных. Также уделили внимание на своей аналитике – отравление датасета LAION-2B – для злоумышленника может стоить от 60$ до 1000, а эффект будет большой.
2. Предвзятость, состязательные примеры, искажающие процесс обучения, проблемные метаданные и некачественный датасет – всё это относят ко второму типу угроз,
3. Дрейф данных. Хотя документ упоминает дрейф данных как один из рисков безопасности данных на некоторых этапах жизненного цикла, подробное описание этого риска и стратегий его снижения в документе отсутствует.
Между этим как мне кажется можно было бы определить угрозы, связанные с синтетикой, а может и нет … всё-таки ж речь про безопасность. К этим рискам они отнесли рекомендации:
NSA дают общие рекомендации:
1.Использование надежных источников данных и отслеживание происхождения
2.Проверка и поддержание целостности данных
3. Использование цифровых подписей
4. Использование доверенной инфраструктуры
5. Классификация данных и контроль доступа
6. Шифрование данных (AES-256)
7. Безопасное хранение данных (должны храниться на устройствах, соответствующих NIST FIPS 140–3)
8. Методы сохранения конфиденциальности (Дифференциальная приватность, федеративное обучение)
9. Безопасное удаление данных (в соответствии с NIST SP 800-88)
10. Проводить регулярную оценку безопасности данных (также в соответствии с NIST SP 800-3r2 и NIST AI 100-1)
По их мнению, да и по лучшим стандартам сейчас для цепочки поставок можно реализовывать хеширование данных, регулярно смотреть целостность.
ну а ссылка вот.
Не очень часто что-то нахожу/публикую интересное по форензике моделей. Да и вообще по тому, как расследовать инциденты в организации, если взломали через какую-то заражённую ML-модель. Поэтому исправляюсь. Предлагаю Вам немного полезного материала по этой теме.
1. NullfiAI, атака доказывающая, что средства защиты могут быть бесполезными. Давняя статья, я даже писал о ней - суть в том, что исследователи рассказали о том, как можно замалварить пикл, да так чтобы сканеры не отрабатывали.
2. Цепочка поставок - большая беда. ReversingLabs также недавно провели анализ PyPi и, к сожалению, обнаружили вредоносную ML-библиотеку. Это не первый похожий случай.
3. Кажется, что подходы классической безопасности хорошо подходят для анализа моделей - но уж нет. Авторы статьи "Gaps in Traditional DFIR Playbooks: Machine Learning Models" рассматривают особенности процесса на примере анализа onnx.
4. От авторов предыдущей статьи есть также публикация про расследование с ml-артефактами . Хорошее чтение с реальным примером.
Только ли в сериализации беда?
Вам может показаться после прочтения статьей что сериализация является важным источником угроз для ML. Частично это да. Для неё уже есть много крутых инструментов, flickling, к примеру. Хотя мы ни в коем случае не должны забывать про MLOps ландшафт, область, где модель храниться, хранит свои данные. Тут в большинстве случаев вам порекомендуют анализировать логи MLOps решений, DVC и кто делает коммиты в GIT. В целом вам также может понадобиться понимание ответа на вопрос "какие форматы датасетов" существуют? и тут тоже есть полезный ресурс - храним, запоминаем.
1. NullfiAI, атака доказывающая, что средства защиты могут быть бесполезными. Давняя статья, я даже писал о ней - суть в том, что исследователи рассказали о том, как можно замалварить пикл, да так чтобы сканеры не отрабатывали.
2. Цепочка поставок - большая беда. ReversingLabs также недавно провели анализ PyPi и, к сожалению, обнаружили вредоносную ML-библиотеку. Это не первый похожий случай.
3. Кажется, что подходы классической безопасности хорошо подходят для анализа моделей - но уж нет. Авторы статьи "Gaps in Traditional DFIR Playbooks: Machine Learning Models" рассматривают особенности процесса на примере анализа onnx.
4. От авторов предыдущей статьи есть также публикация про расследование с ml-артефактами . Хорошее чтение с реальным примером.
Только ли в сериализации беда?
Вам может показаться после прочтения статьей что сериализация является важным источником угроз для ML. Частично это да. Для неё уже есть много крутых инструментов, flickling, к примеру. Хотя мы ни в коем случае не должны забывать про MLOps ландшафт, область, где модель храниться, хранит свои данные. Тут в большинстве случаев вам порекомендуют анализировать логи MLOps решений, DVC и кто делает коммиты в GIT. В целом вам также может понадобиться понимание ответа на вопрос "какие форматы датасетов" существуют? и тут тоже есть полезный ресурс - храним, запоминаем.
В конце мая исследователи из ReversingLabs обнаружили атаку на цепочку поставок, распространяющуюся на разработчиков, которые использовали Alibaba AI Labs.
Злоумышленники загрузили в PyPI три вредоносных пакета, маскирующихся под официальные SDK для взаимодействия с сервисами Alibaba Cloud AI Labs:
1.aliyun-ai-labs-snippets-sdk
2.ai-labs-snippets-sdk
3.aliyun-ai-labs-sdk
Пакеты были доступны с 19 мая, в течение 24 часов до обнаружения. И за это время они были загружены примерно 1600 раз. Наибольшее количество загрузок пришлось на пакет ai-labs-snippets-sdk, который был доступен дольше остальных.
Сами по себе пакеты вовсе не содержали функциональности связанной с AI или взаимодействием с серверами Alibaba, а вредоносный код был скрыт в Pickle. Заражение происходило через __init__.py, который загружал вредоносные pickle.
Какая информация отправлялась злоумышленникам при запуске Pickle:
1. Данные о хосте, сетевом адресе машины
2. Название организации
3. Содержимое. gitconfig
4. Также происходила идентификация разработчиков, которые используют инструмент AliMeeting
Собранная информация отправлялась в base64 на сервера злоумышленников.
Злоумышленники загрузили в PyPI три вредоносных пакета, маскирующихся под официальные SDK для взаимодействия с сервисами Alibaba Cloud AI Labs:
1.aliyun-ai-labs-snippets-sdk
2.ai-labs-snippets-sdk
3.aliyun-ai-labs-sdk
Пакеты были доступны с 19 мая, в течение 24 часов до обнаружения. И за это время они были загружены примерно 1600 раз. Наибольшее количество загрузок пришлось на пакет ai-labs-snippets-sdk, который был доступен дольше остальных.
Сами по себе пакеты вовсе не содержали функциональности связанной с AI или взаимодействием с серверами Alibaba, а вредоносный код был скрыт в Pickle. Заражение происходило через __init__.py, который загружал вредоносные pickle.
Какая информация отправлялась злоумышленникам при запуске Pickle:
1. Данные о хосте, сетевом адресе машины
2. Название организации
3. Содержимое. gitconfig
4. Также происходила идентификация разработчиков, которые используют инструмент AliMeeting
Собранная информация отправлялась в base64 на сервера злоумышленников.
Forwarded from Alaid TechThread
Наш подход к генерации патчей для уязвимых зависимостей в Docker-образах
https://vk.com/video-28022322_456241194
#safeliner
https://vk.com/video-28022322_456241194
#safeliner
VK Видео
Контроль зависимостей на автопилоте AI-ассистент на страже Dockerfile
В докладе будет разобран наш опыт создания и интеграции LLM-агента, исправляющего уязвимости в контейнерных образах. Вы узнаете, почему Dependabot и Renovate не решают все ваши проблемы. Мы расскажем о нашем подходе, а также о том, сколько уязвимостей можно…
Forwarded from Борис_ь с ml
Гайд по 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
Кому-то точно нужен был чек-лист для llm governance. Так вот я нашел полезную статью по теме.
https://www.newline.co/@zaoyang/checklist-for-llm-compliance-in-government--1bf1bfd0
Кажется вроде как базой, но что удобно - так это то что все в одном месте - законы, процесс, и кто сколько может заплатить за несоблюдение мер, но в разных странах. Конечно тут речь не про технику, но куда уж без комплаенса.🤪
https://www.newline.co/@zaoyang/checklist-for-llm-compliance-in-government--1bf1bfd0
Кажется вроде как базой, но что удобно - так это то что все в одном месте - законы, процесс, и кто сколько может заплатить за несоблюдение мер, но в разных странах. Конечно тут речь не про технику, но куда уж без комплаенса.
Please open Telegram to view this post
VIEW IN TELEGRAM
newline
Checklist for LLM Compliance in Government | newline
Deploying AI in government? Compliance isn’t optional. Missteps can lead to fines reaching $38.5M under global regulations like the EU AI Act - or worse, erode public trust. This checklist ensures your government agency avoids pitfalls and meets ethical standards…
В последнее время анализируя множество исследований, статьей по теме - ощущаю нехватку того что меры которые предлагаются для защиты не содержат как правило проактивного характера.
У нас есть классический cyberkillchain. Mitre попытались отобразить его в своём фреймворке Atlas - несколько этапов от начального рекона до эксфильтрации и т.д. Это круто, но как мне кажется - знания о защите должны также быть, не хуже да и вообще быть изложены в структурированном виде. А то всё об угрозах да и об угрозах - а как защищать, когда атака уже идёт ? Говорить "не использовать MLFlow, потому что уязвимо" или другое решение выглядит обсурдным.
Н А Д О Е Л О
Поэтому с начала марта я задумался о том как можно было бы представить anti cyberkillchain, да так чтобы он ещё укладывался в ландшафт ML.
я закомитил свои наработки по теме сюда
https://github.com/wearetyomsmnv/ML-Defense-Matrix
это матрица противодействия разным этапам, как мне самому кажется - это очень верхнеуровневый документ, его определённо надо дорабатывать с коллегами которые строят защиту - поэтому призываю вас принять участие, дать комменты(только обоснованные) - чтобы сделать проактивную защиту ML лучше. Не всегда можно покрыть риски только на этапе разработки. Это печалит.
О чём документ: В нём я изложил меры по защите(очень поверхностно, думаю буду прорабатывать их в соответствии с публикациям на arxiv) которые можно использовать на разных этапах - защита от разведки, защита от исполнения кода и тд. В перспективе добавить тему уже услышанную всеми - это агенты.
Инциденты уже шагают, угрозы уже изучены и задокументированы - но вот защита ... С этим всё слабо кмк. Прошу репост, тех кто заинтересован в развитии такой истории.
У нас есть классический cyberkillchain. Mitre попытались отобразить его в своём фреймворке Atlas - несколько этапов от начального рекона до эксфильтрации и т.д. Это круто, но как мне кажется - знания о защите должны также быть, не хуже да и вообще быть изложены в структурированном виде. А то всё об угрозах да и об угрозах - а как защищать, когда атака уже идёт ? Говорить "не использовать MLFlow, потому что уязвимо" или другое решение выглядит обсурдным.
Н А Д О Е Л О
Поэтому с начала марта я задумался о том как можно было бы представить anti cyberkillchain, да так чтобы он ещё укладывался в ландшафт ML.
я закомитил свои наработки по теме сюда
https://github.com/wearetyomsmnv/ML-Defense-Matrix
это матрица противодействия разным этапам, как мне самому кажется - это очень верхнеуровневый документ, его определённо надо дорабатывать с коллегами которые строят защиту - поэтому призываю вас принять участие, дать комменты(только обоснованные) - чтобы сделать проактивную защиту ML лучше. Не всегда можно покрыть риски только на этапе разработки. Это печалит.
О чём документ: В нём я изложил меры по защите(очень поверхностно, думаю буду прорабатывать их в соответствии с публикациям на arxiv) которые можно использовать на разных этапах - защита от разведки, защита от исполнения кода и тд. В перспективе добавить тему уже услышанную всеми - это агенты.
Инциденты уже шагают, угрозы уже изучены и задокументированы - но вот защита ... С этим всё слабо кмк. Прошу репост, тех кто заинтересован в развитии такой истории.
GitHub
GitHub - wearetyomsmnv/ML-Defense-Matrix: Mitre Atlas counter-attack techniques
Mitre Atlas counter-attack techniques. Contribute to wearetyomsmnv/ML-Defense-Matrix development by creating an account on GitHub.
В прошлом году Google выпустили исследование в котором показали как при помощи агентов искать zero days. Тогда была найдена проблема с sqlite3, критическая и быстро закрытая уязвимость.
Но уже в конце мая исследователь из Оксфорда опубликовал исследование в котором при помощи o3, без агентов и инструментов ему также удалось найти нолик, но уже в ядре линукса.
Уязвимости был присвоен CVE-2025-37899. Уязвимость позволяет удаленно выполнить код за счёт Use-after-free в SMB 'logoff'. Только доступ к апи, ничего больше. Наверное это первый публичный кейс когда ноль был обнаружен в ядре, да и как говорит автор - если можно закинуть 10к строк кода, то о3 справиться или поможет справиться.
На уязвимость уже вышел патч.
https://sean.heelan.io/2025/05/22/how-i-used-o3-to-find-cve-2025-37899-a-remote-zeroday-vulnerability-in-the-linux-kernels-smb-implementation/
Но уже в конце мая исследователь из Оксфорда опубликовал исследование в котором при помощи o3, без агентов и инструментов ему также удалось найти нолик, но уже в ядре линукса.
Уязвимости был присвоен CVE-2025-37899. Уязвимость позволяет удаленно выполнить код за счёт Use-after-free в SMB 'logoff'. Только доступ к апи, ничего больше. Наверное это первый публичный кейс когда ноль был обнаружен в ядре, да и как говорит автор - если можно закинуть 10к строк кода, то о3 справиться или поможет справиться.
На уязвимость уже вышел патч.
https://sean.heelan.io/2025/05/22/how-i-used-o3-to-find-cve-2025-37899-a-remote-zeroday-vulnerability-in-the-linux-kernels-smb-implementation/
Sean Heelan's Blog
How I used o3 to find CVE-2025-37899, a remote zeroday vulnerability in the Linux kernel’s SMB implementation
In this post I’ll show you how I found a zeroday vulnerability in the Linux kernel using OpenAI’s o3 model. I found the vulnerability with nothing more complicated than the o3 API ̵…
Фреймворков для тестирования моделей уже достаточно много на рынке. Но куда они движутся ? Что их объединяет и какие особенности преследует каждый из них.
В этой статье я изложил некоторую аналитику по этой части, но чтобы текст не казался техническим насилием при прочтении - я изложил его в формате гонзо журналистики. Приятного чтения
В этой статье я изложил некоторую аналитику по этой части, но чтобы текст не казался техническим насилием при прочтении - я изложил его в формате гонзо журналистики. Приятного чтения
Хабр
Лаборатория Безумного Ученого: Хроники Четырех Экспериментов повлиявших на представление об обеспечении безопасности ИИ
Дата: 11 мая 2025 Жанр: Гонзо-журналистика Записки исследователя, проникшего в тайные лаборатории создателей инструментов безопасности ИИ Дорогие читатели, то, что я собираюсь вам рассказать, звучит...