Подсознательное обучение

Чем больше мы изучаем ИИ, тем больше находим сходств с "естественным интеллектом", далее буду писать ЕИ. В статье про креативность я сравнивал собственные подходы к созданию "нового" с тем, как работает LLM, и на каком-то уровне абстракции не нашел принципиальных отличий.

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

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

#ml

Building a Successful Career in AI Cybersecurity

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

Ключевые выводы из доки
1. Конвергенция AI и Cybersecurity:
Документ подчеркивает, что искусственный интеллект и машинное обучение (ML) кардинально меняют ландшафт ИБ. AI используется как для усиления защиты, так и в качестве инструмента атак

2. п. 1 объясняет растущий спрос на специалистов:
Возникает новая категория ролей, таких как "Инженер по безопасности AI/ML" или "Специалист по безопасности данных", которые требуют уникального сочетания навыков ИБ и Машобуча.

3. Из доки можно выделить необходимые навыки и знания:
Технические навыки (Hard Skills):
- Понимание основ машинного обучения и data science.
- Знание языков программирования (Python, R) и умение работать с данными.
- Опыт работы со специализированными фреймворками и библиотеками (TensorFlow, PyTorch, scikit-learn).
- Глубокие знания в области ИБ
- Понимание облачных платформ (AWS, Azure, GCP) и их систем безопасности.

Soft Skills:
- Критическое и аналитическое мышление.
- Решение сложных проблем.
- Коммуникация (способность объяснять сложные концепции AI нетехническим специалистам).
- Любознательность и постоянное стремление к обучению.

4. Рекомендации по построению карьеры:
- Начните с основ: Получите прочную базу в классической ИБ (сертификаты типа CISSP, SSCP, CCSP очень приветствуются).
- Освойте Data Science: Изучите математику, статистику и основы машинного обучения через онлайн-курсы (Coursera, edX) или практические проекты.
- Получайте практический опыт: Применяйте свои знания в реальных проектах, участвуйте в соревнованиях по анализу данных (например, на Kaggle) или в открытых source-проектах.
- Вступайте в профессиональные сообщества, посещайте конференции и общайтесь с экспертами в этой области.

С развитием технологий и ужесточением регулирования спрос на экспертов, способных обеспечивать безопасность, надежность и этичность AI-систем, будет только расти.

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

#ml #саморазвитие #vCISO

На выходных удалось немного найти время на интересное, делюсь полезными находками

1. Отличная серия онлайн-мероприятий о практическом использовании машобуча в кибербезе. Можно зарегистрироваться и принять участие (я зарегистрировался, но в итоге смотрел в записи).
Релевантные моим проиводственным интересам:
David Kennedy - AI-Assisted SOC Automation and Threat Analysis
Randy Pargman - AI-Assisted Malware Reverse Engineering
Jonathan Cran - Intelligent Threat Intel Tooling
Также, есть выпуски про Offensive и про риски и инфобез вообще - не смотрел

2. В продолжение прокачивания темы AI-агентов поизучал LangGraph: Build AI Agents and Chatbots with LangGraph - "галопом по Европам", но, в качестве быстрого погружения, курс неплох. В процессе выполнения лаб понял, что я не настолько здорово знаю Python, поэтому в ближайшее время решил подтянуть свои способности в питонизации (пишите, если интересно, какие курсы про Python я смотрел, с удовольствием поделюсь мнением), а затем, снова вернуться с AI-агентам, но уже поиграться с доступными локальными моделями.

Всем счастливой недели!

#саморазвитие #ml

Когда AIOps становится AIУпс

Как только новая технология обретает популярность, сразу появляются техники атак на нее. Поэтому большое количество уязвимостей не всегда означает, что ПО дырявое (ну разве что толко Adobe - исключение), но точно, что оно - популярное. Автономные SOC-и набирают популярность, вот и атак на AI-агентов все больше придумывают. В этой связи рекомендую ознакомиться с исследованием моего друга и коллеги Мохамеда Гобаши из команды GERT о вредоносных MCP-серверах, а я расскажу, в общем-то об инъекциях, но на современный лад.

Статья "When AIOps Become "AI OOPS" (прямая ссылка на pdf, статья в The Register) представляет первое в своём роде исследование безопасности систем AIOps (~ агентских систем), которые используют большие языковые модели для автоматизации обнаружения и расследования инцидентов, и реагирования на них.

Авторы показывают, что злоумышленники могут манипулировать событиями телеметрии, чтобы "обмануть" AI-агента и заставить его выполнить вредоносные действия по "исправлению" проблемы.
В статье авторы предложили методологию и инструмент "AIOpsDoom" для проведения атаки на агентскую систему, которая может обмануть AI-агента, заставив его выполнить вредоносное действие, подставив в телеметрию ложные артефакты.
Кроме того, здесь же авторы предложили и защиту - "AIOpsShield", которая санитизирует подставленные системой, аналогичной AIOpsDoom, вредоносные данные.
В общем, ребята разобрали агентские системы в хвост и в гриву, причем, и в AIOpsDoom, и в AIOpsShield также используются LLM, хотя и не в качестве основного компонента.

Исследование лишний раз подтверждает, что ML/DL/LLM - это такой же инструмент, как, например, любой язык программирования, который может использоваться и для автоматизации (AI-агенты), и для автоматизации атак на автоматизацию (AIOpsDoom), и для автоматизированного обеспечения безопасности (AIOpsShield), и если ранее мы работали с Host IDS и Network IDS, то вот они уже и AI IDS.

#ml

Promptware: в полку warezz прибавление

Совсем недавно мы рассуждали об атаках на агентские системы и вот снова, почти, о том же.

Исследование (прямая ссылка на PDF) показывает, что promptware - специально сконструированные вредоносные промты - представляет серьёзную угрозу для пользователей LLM-ассистентов (на примере Gemini от Google). Атаки используют непрямые инъекции промтов через письма, календарные приглашения и общие документы, что позволяет злоумышленникам нарушать конфиденциальность, целостность и доступность систем. Приведены примеры запуска атак через приглашения в календаре или письма с вредоносным промтом в заголовке, а для активации требуется минимальное взаимодействие с пользователем, например, невинный запрос "Какие у меня встречи?", т.е. практически Zero touch. Также авторы показали, что promtware позволяет осуществлять горизонтальные перемещение в скомпрометированной системе, выходя за пределы LLM-приложения.

Авторы продемонстрировали 14 сценариев атак против трёх версий Gemini (веб, мобильная, Google Assistant), которые классифицировали по пяти типам угроз:
- Кратковременное отравление контекста (Short-term Context Poisoning)
- Постоянное отравление памяти (Permanent Memory Poisoning)
- Неправильное использование инструментов (Tool Misuse)
- Автоматический вызов агентов (Automatic Agent Invocation)
- Автоматический вызов приложений (Automatic App Invocation)
в результате которых удалось реализовать спам, фишинг, утечку данных, видеозапись пользователя, управление умным домом (открытие окон, включение котла), в общем, все что угодно. По мнению авторов 73% угроз оцениваются как высококритические.

В статье также предложен фреймворк TARA (Threat Analysis and Risk Assessment) на основе стандарта ISO/SAE 21434 и предложена оценка рисков по классике - на основе вероятности сценария атаки и влияния\ущерба от него.

Среди методов противодействия упоминаются:
- Изоляция контекста между агентами
- Валидация ввода/вывода
- A/B-тестирование
- Подтверждение действий пользователем
- Обнаружение подозрительных артефактов (URL)
однако, как мы знаем, митигационные меры не избавляют от риска, но снижают его уровень до низкого или среднего.

Ну что можно сказать?!
1. Promptware — практичная и опасная угроза, требующая срочного внимания, возможно, это новая область для систем обнаружения: мы научились находить SQL-инъкции, пора повышать уровень
2. Пока не видно вала публикаций на эту тему, как будто, индустрия пока не дооцениват риск атак на LLM-системы, а вендоры ИБ пока не осознали перспективность этого рынка
3. Если смотреть предлагаемые меры защиты, то можно обнаружить сходство с классикой: валидация пользовательского ввода, сегментация\изоляция, минимум полномочий и т.п. Соответственно, все эти меры надо сразу интегрировать в приложения, ибо навесная безопасность работает плохо, а это открывает новое важной и перспективное направление - безопасная архитектура LLM-систем, похожие эксперты упоминались здесь .

#ml #vCISO

Машинное обучение в обнаружении

Есть масса применений машобуча в ИБ и нередко на маркетинговых мероприятиях можно услышать об успехах применения машинного обучения без учителя для обнаружения: есть некоторый движок, выполняющий профилирование, который затем выдает статистические отклонения. Проблема тут в том, что "статистическое отклонение" - это не всегда "инцидент", и окончательное решение принимает человек. Понятие инцидента - не простое, поэтому построить классификатор, который будет выдавать не статистическое отклонение, а инцидент невозможно без анализа обратной связи от пользователя (варианты решения этой задачи с помощью LLM пока не будем рассматривать, но и там проблем немало, ибо закономерность сохраняется: чем сложнее система, тем сложнее ей пользоваться). А это уже вопрос, решаемый в рамках машинного обучения с учителем, однако, в этом случае, для получения удовлетворительных результатов, нам нужны размеченные данные, типа, вот это статистическое отклонение - инцидент, а вот это статистическое отклонение - не инцидент. Кроме того, на практике нередки и false negative (пропуски), т.е. Модель надо подкрутить так, чтобы в сценариях прошлых промахов она, таки, выдавала статистическое отклонение, которое будет интерпретировано пользователем как инцидент. Чем размеченных данных будет больше, тем лучше, а если данных будем мало, построение такого классификатора под большим вопросом.

Таким образом, налицо двухходовочка:
- Unsupervised ML поможет найти статистическое отклонение - здесь будет много False positives, но практика показывает, что будут и False negative (собственно, этот объем False* и является основным аргументов скептиков относительно пригодности ML в ИБ вообще, сравнивающих ML-вердикты с выдачей ГПСЧ)
- Supervised ML теоретически можно обучить распознавать среди статистических отклонений инциденты, но в этом случае нужны большие размеченные данные, как например, в случае Автоаналитика

В нашем случае упомянутая двухходовочка для обнаружения горизонтальных перемещений в сети реализована одной Моделью без учителя. Но для поддержания удовлетворительного качества работы, все ее False* разбираются с участием аналитиков команды SOC, после чего Модель дорабатывается: начинает ловить прошлые пропуски и не генерить статистическое отклонение в определенных сценариях, не являющихся инцидентом.

Итого, нам всем нужно понимать:
1. Статистическое отклонение, выдаваемое Моделью без учителя - это еще не Инцидент
2. Для того, чтобы Модель научилась выдавать не статистические отклонения, а инциденты, обязательна обратная связь от пользователя, разметка данных пользователями
3. Чтобы обучить Модель на размеченных данных, их должно быть много
4. Нужно заниматься постоянным тюнингом Модели без учителя, выдающей статистические отклонения, чтобы она выдавала бизнес-значимые статистические отклонения, т.е. инциденты
5. В "коробочных" on prem решениях есть проблемы с получением обратной связи от пользователя и ее анализом, чтобы подстраивать и переобучать Модель, т.е. пп. 2-4 нереализуемы

В итоге получаем, что более-менее рабочим сценарием является портирование обученных моделей из облачных сервисов в on prem решения. Как, в частности, мы и сделаем с моделью обнаружения горизонтальных перемещений, которая из MDR когда-то станет доступна в KUMA. В этом случае постоянство качества Модели будет обеспечиваться ее постоянным тюнингом в рамках сервиса в предположении, что в пользовательской инфраструктуре демонстрируемые ею статистические отклонения будут интерпретировать как инциденты по тем же правилам, что и в MDR. Это очередная прекрасная демонстрация как правильно выкристаллизовывать облака в on prem, а никак не наоборот!

#MDR #vCISO #ml

AI Agents vs. Prompt Injections

Мой приятель и замечательный человек Владислав Тушканов, руководитель группы исследований и разработки технологий машинного обучения (Центр исследования технологий искусственного интеллекта), человек, который внимательнейшим образом выслушивает все мои бредовые идеи по автоматизации нашей работы с использованием машобуча, с которым у нас длиннющий бэклог и громадье совместных планов, [... и много чего... еще] дает вебинар, подробности в канале у Влада.

#ml

Первый вредоносный MCP-сервер в мире

А вот и вредоносные MCP поспели!
The Register
Dark Reading
Оригнальная публикация от KOI

Понятно, что не все что скачивается с Github безопасно, однако, в свете последних тенденций атака отдает новизной.
Как и ожидалось, новый слой абстрации, в данном случае MCP, расширяет поверхность атаки.

#ml #vCISO

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

Также интересный материал от коллег, но уже более прикладной.

#ml #MDR

Mind the Gap: Time-of-Check to Time-of-Use Vulnerabilities in LLM-Enabled Agents

Работа (pdf, abstract) - первое системное исследование уязвимостей типа Time-of-Check to Time-of-Use (TOCTOU) в агентах на основе больших языковых моделей (LLM), возникающих из-за временного разрыва между последовательными вызовами инструментов, когда злоумышленник может изменить состояние системы после его проверки агентом.

В статье приведен TOCTOU-Bench - первый бенчмарк для оценки уязвимостей TOCTOU, содержащий 66 реалистичных пользовательских задач. Анализ показал, что 56 из них потенциально уязвимы.

Также в статье приведен список мер защиты (в целом, ничего инновационного в них я не заметил):
- Переформулирование промптов (Prompt Rewriting) - изменяет пользовательские запросы, чтобы снизить вероятность создания планов с TOCTOU.
- Мониторинг целостности состояния (State Integrity Monitoring, SIM) - автоматическое обнаружение потенциально уязвимых последовательностей вызовов инструментов с помощью конечного автомата.
- Объединение инструментов (Tool Fuser) - уязвимые пары инструментов объединяются в один атомарный вызов, устраняя временное окно для атаки.

Как отмечал SANS мы получаем много направлений для развития на стыке разных областей знаний, TOCTOU - очередной пример на стыке безопасности ИИ и системной безопасности. Здесь же хочу провести параллели в мою, когда-то горячо любимую, криптографию, а именно с side-channel атаками:
- Использование непреднамеренного канала информации/влияния. В криптографии атакующий использует не саму математическую уязвимость алгоритма (например, факторизацию числа или дискретное логарифмирование), а побочные эффекты его физической реализации: время выполнения, энергопотребление, акустические эмиссии, электромагнитное излучение и т.п. В LLM-агентах атакующий использует не прямую уязвимость в LLM (например, инъекцию промпта), а архитектурную особенность ее работы - временной разрыв (temporal gap) между проверкой и использованием - это и есть "побочный канал"
- Обход прямых защитных механизмов. В случае криптографии защита, как правило, криптографически стойка для атаки "в лоб", но для атаки через побочный канал криптостойкость вообще не важна. А в LLM-агентах используемые механизмы защиты (guardrails, контроль ввода/вывода, sandboxing) предполагают, что вызовы инструментов атомарны и состояние между ними стабильно, однако, TOCTOU-атака обходит это предположение, атакуя сам процесс между вызовами.
- Необходимость специализированных методов защиты. В криптографии для защиты от side-channel атак нужны специальные методы: алгоритмы с постоянным временем выполнения, маскирование, аппаратная изоляция и т.п. А в LLM-агентах, как показано в статье, для защиты от TOCTOU нужны специальные методы, адаптированные под агентскую архитектуру: мониторинг целостности состояния (аналог детекторов аномалий), слияние инструментов (аналог создания защищенных примитивов).

В общем, все новое - это хорошо забытое старое. Наверно, это неплохо, так как подобные параллели упрощают придумывание методов защиты от новых модных атак.

#ml #crypto

Автономные SOC

Последнее время все резко заговорили об автономном SOC: эфир AM Live (напишите, нужно ли писать заметку с комментариями ряда утверждений, а еще лучше - какие утверждения нужно прокомментировать), и Дэн написал заметку, приятель Игорь продолжает эксперименты с агентскими системами, поднимается воодушевление, но в то же время Gartner в декабре 2024 писал вполне адекватный док "Predict 2025: There Will Never Be an Autonomous SOC", есть и немало неплохих статей (например). В общем, видимо, надо поделиться мнением.

Уже 8 лет назад я рисовал что можно сделать с угрозой. Абстрактность описания этого принципа позволяет ему быть аксиоматичным, т.е. он прекрасно работает в условиях любой автоматизации. ML/DL - не что иное, как новые возможности по автоматизации. Если у нас некоторый автомат, - не важно что у него внутри: поиск битовых последовательностей в файле или действий в логе поведения, или пороги вероятности True positive в задаче регрессии при машобуче с учителем или отклонение от профиля при обучении без учителя, или там будет LLM-агент, запускающий автоматически реакцию для каких-то сценариев - умеющий автоматически выполнять инвазивные действия, то это всем нам давно известный сценарий, отмеченный на упоминаемой картинке как "Prevent", реализуемый исторически "антивирусом". Антивирусы начинались как файловые, но с расширением спектра применяемых тактик и техник атакующих, расширялись и технологические возможности средств защиты: подтянулась облачная поддержка (без подобного фанатизма, конечно же) и много других технологий, новички, в желании постричь уже зрелый рынок повторно, изобрели новые термины и подняли хайп "антивирусы мертвы" (или "антивирусы не нужны") - типичный пример говноPRа, когда вместо доказательств преимуществ своего решения фокусируются на недостатках конкурентов, нередко вымышленных и преувеличенных.

Все на той же картинке мы видим стрелочки, когда угрозу, обнаруженную вручную (Threat hunting) потом обнаруживают и, по возможности, предотвращают автоматически. Сейчас у нас [уже давно] есть новые возможности по автоматизации, которые, конечно же, используются. Машобуч, как и любая другая автоматизация, никогда не заменит полностью человека, иначе нас ждет конец. Любая работа при достижении определенного уровня профессионализма превращается в рутину, эту рутину будут автоматизировать, а человеку надо будет грызть новый гранит науки, снова сначала что-то делать вручную, затем это алгоритмизировать и передавать автоматам.

#vCISO #ml

Подписчик поделился видео.

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

Согласие, несогласие, дополнения, уточнения - приветствуются в комментариях!

#ml #саморазвитие #книги

How to build AI agents into your SOC

Одним из положительных моментов путешествий является избыток свободного времени в аэропорту. На этот раз, по пути домой в столицу, мне наконец-то удалось закончить ознакомление с замечательным гайдом от Red Canary по созданию надежных и эффективных AI-агентов для интеграции в операционную работу SOC. Тема мне небезразлична, поэтому поделюсь мыслями из доки. Сразу замечу, что если вы уже имеете хоть какой-то практический опыт написания агентов, хотя бы на уровне упомянутого здесь курса, то дока покажется вам скучной, но для начинающих джедаев материал может стать неплохой базой, упорядочивающей понимание и перечисляющей очевидные грабли, которые можно обойти.

Мы все немного скептически относимся к формализации процессов, и я сам нередко пропагандирую fuckup-driven management, однако, в случае передачи чего-либо программному болвану AI-агенту, никакая формализация не может быть лишней. Основной тезис документа: надежность важнее новизны, поэтому ключ к успеху лежит не в использовании самой передовой модели, а в построении детерминированных рабочих процессов, строгих ограничений и постоянном измерении результатов. Документ содержит не только теоретические основы, но и практические примеры на Git, а кто любит за трапезой посмотреть что-то полезное есть видео на Youtube Elevate and empower your SOC with AI.

Ключевые принципы построения надежных AI-агентов
1. Структура и Детерминизм. Большие языковые модели по своей природе вероятностны и могут давать разные результаты при одних и тех же входных данных. Для SOC это недопустимо, так как критически важна повторяемость, поэтому Канарейки рекомендуют использовать детерминированную оркестрацию в сочетании с ограниченным рассуждением агентов: задачи разбиваются на явные, небольшие шаги, а агенты используются только там, где их вероятностная природа может приносить пользу (например, для анализа и корреляции), а не для принятия ключевых решений.

2. Дизайн системы, а не одной модели. Ценность извлекается из взаимодействия дизайна workflow, защитных механизмов и выбора моделей, т.е. вместо одного "универсального" агента следует строить сложные системы из простых, узкоспециализированных компонентов. Четкое выделение простых детерменированных шагов для агента прекрасно бьется и с мнением моих друзей, съевших не одну собаку на автоматизации SOC с помощью AI-агентов.

Документ разбирает кейс автоматизации анализа данных OSQuery с конечных точек. В частности, Аналитик может тратить 30+ минут на полуручной разбор десятков JSON-файлов, тогда как AI-агенты могут сократить это время до 2 мин. Для этого создаются несколько узкоспециализированных агентов, каждый из которых отвечает за свою категорию данных OSQuery, например, агент программного обеспечения, агент файловой системы, агент пользователей и групп, агент WMI-событий, и т.п. Для оркестрации используются специализированные агенты, запускаемые параллельно, а их результаты затем агрегируются в единый отчет. Для управления таким workflow используются фреймворки вроде LangGraph.

В документе также освещаются вопросы выбора и оптимизации моделей и безопасности. Интересно почитать о том, как Канарейки пишут об использовании агентов у себя, конечно, по возможности, счищая весь налет маркетинга. В целом, ребята не испытывают беспокойства, используя доступные из облака LLM, поэтому клиентам Red Canary, возможно, имеет смысл обратить внимание на то, что их данные доступны помимо MSSP (Канарейки) и IaaS (Microsoft), но и провайдерам LLM (OpenAI, Google), в общем, поверхность атаки расширяется.

#ml #MDR