Разбор докладов с AI-трека OFFZONE 2025. Часть 2

На прошлой встрече PT ML Reading Group специалист ML-команды Максим Митрофанов поделился разбором части докладов с конференции.

Мы обсудили:
🛑роль AI в работе SOC;
🛑применение LLM для интерпретации бинарных файлов;
🛑использование ML в NDR-системах;
🛑применение графовых, трансформерных и генеративных моделей в борьбе с вредоносными файлами.

А уже в эту пятницу мы продолжим разбирать материалы AI-трека.
Вадим Безбородов расскажет про:
🛑подходы к созданию AI-агентов для пентеста и реверса, а также о бенчмарках для их оценки;
🛑применение LLM в системах автоматизации и обнаружения угроз;
🛑методы защиты моделей и данных в продакшене.

📅 Ждём всех в Толке в пятницу, 19 сентября, 15:00.
🔗 Ссылка для подключения: Ктолк

#reading_group #conf #offzone2025

На очередной встрече PT ML Reading Group поговорим о том, как современные техники TLS-фингерпринтинга помогают находить вредоносные серверы и скрытую активность в зашифрованных каналах, а также о том, какую роль в этом играет машинное обучение.

Обсудим:
🛑TLS-фингерпринтинг — основные понятия, виды отпечатков (JA3, JA4, JA4+) и их отличия;
🛑причины, по которым JA4 лучше JA3;
🛑усиление TLS-фингерпринтинга с помощью машинного обучения.

Найти ответы на эти и другие вопросы нам помогут разборы статей:
🟡«Fingerprinting the Shadows: Unmasking Malicious Servers with Machine Learning‑Powered TLS Analysis»,
🟡«Experience Report: Using JA4+ Fingerprints for Malware Detection in Encrypted Traffic».

Встречу проведут:
🛑Коля Лыфенко — Dev Lead ML-команды
🛑Женя Бечкало — ESC AVLab Network Lead

📅Как обычно, встречаемся в пятницу!
🔗Подключайтесь: Ктолк, 3 октября, в 15:00

#reading_group #cybersecurity #classic_ml

Читаем вместе. ИИ в AppSec: могут ли LLM работать с уязвимым кодом

[хабр-обзор] [папира]

Всем привет!

Решил расширить RG еще и на тексты Хабр, сделал разбор статьи LLMs Cannot Reliably Identify and Reason About Security Vulnerabilities (Yet?): A Comprehensive Evaluation, Framework, and Benchmarks. В качестве затравки — несколько тезисов из разбора:

➡️ Результаты бенчмарка — «фотография во времени», быстро устаревающая не только по списку оцененных моделей, но и по попаданию данных в cut-off более современных LLM. Бенчмаркам на безопасность кода критически не хватает подходов по автоматическому обновлению на подобие SWE-rebench.

➡️ Очень зашли гипотезы про согласованность рассуждений и ответов, проверка на «пропатченном» коде и эксперименты с аугментацией.

➡️ Так, например, даже сильные модели ломаются на стресс-аугментациях, таких как изменения в уязвимом коде названий методов/переменных или добавление неиспользуемого кода.

➡️ Наглядная секция про техники промптинга. Практический вывод: роль-ориентированные инструкции и пошаговый CoT заметно улучшают качество (особенно в zero-shot). Но при наличии few-shot инструкций импакт от CoT снижается. Это может помочь сэкономить контекста в некоторых задачах.

➡️ Ограничение длины контекста в реальных кейсах играет критическую роль, поскольку код, приводящий к уязвимости, может находиться не только в разных частях файла, но и в разных частях проекта. Тут стоит отойти от академических статей и посмотреть на инженерные подходы к отбору контекста разработчиками Cursor, Claude-code и прочих копайлотов для разработки.
__________________

Макс Митрофанов, ML-лид направления AppSec 🟥

Что мы поняли о роли AI/ML в защите данных за последний год?

Сегодня, на Positive Security Day состоится долгожданный коммерческий релиз PT Data Security — продукта для защиты корпоративных данных, независимо от их типа и места хранения.
Наша команда разрабатывала одну из ключевых фич - ML-модуль классификации данных. Прошли путь с нуля — от идеи и конкурентного анализа до интеграции в продукт и оптимизации инференса.

Поэтому делимся нашим взглядом на роль AI/ML в классификации данных:

⚡️1. Метаданные ≠ данные

Мы провели конкурентный анализ и поняли, что большинство решений на рынке анализируют только метаданные — названия файлов/колонок/таблиц, расширения и описания к объектам.
Но в реальных компаниях данные часто выглядит так: “новый документ финал.docx” или "column123"

Так что “аналитика по названиям” быстро разбивается о реальность корпоративного хаоса.

⚡️2. Реальность рушит простые гипотезы

Мы собрали валидационную выборку, имитирующую корпоративные данные, и прогнали по ней несколько вендоров и open-source решений.
Результат: полнота <= 40% у regex-пайплайнов.
Регулярки просто не видят такие сущности, как имена, организации, телефоны, даты и многие другие — особенно в естественном тексте.

⚡️3. Значит, идем глубже — в контент

С первых итераций мы сделали ставку на анализ содержимого.
Для прототипов использовали Microsoft Presidio — удобный фреймворк, который позволил без интеграции в продукт опробовать наши ML-модели на сценарии защиты данных (но производительность фреймворка не позволяет использовать его в production).

Мы попробовали несколько ML подходов, остановившись на NER архитектуре. С учетом специфики РФ рынка, держали фокус на работе как с русским, так и с английским языком.
Подробности — в нашей статье на Хабре.

⚡️4. Идеальный баланс: ML + регулярки

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

⚡️5. А LLM?

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

LLM имеют потенциал в качестве копайлотов для ИБ-специалиста, но не станут ядром системы, которая должна работать на масштабе и в реальном времени.

---

Поздравляем команду продукта в релизом и уходим готовить новые фичи, которые позволят еще надежнее защитить компании от утечек!


____________________________________

Вадим Безбородов, ML-инженер AppSec
Максим Митрофанов, ML-лид AppSec

Один из способов ускорить инференс LLM — это использовать спекулятивное декодирование (Speculative Decoding), чтобы оптимизировать генерацию ответа. Маленькая модель генерирует черновые токены, а большая — их валидирует. Причём чем длиннее принятый фрагмент, тем больше прирост к скорости работы.

В то же время, узкое место классического SD — фиксированный размер чернового окна. При разношёрстных запросах часть проверок проходит впустую, потому что где‑то черновики совпадают почти полностью, а где‑то ломаются уже на первом токене.

В эту пятницу специалист ML-команды Екатерина Синькова разберёт статью «TETRIS: Optimal Draft Token Selection for Batch Speculative Decoding». Ее авторы предлагают способ динамически выбирать число генерируемых черновых токенов на основе батча запросов, чтобы максимизировать число принятых токенов.

Катя расскажет:
🛑как работает спекулятивное декодирование,
🛑как авторы «TETRIS» обошли проблему фиксированного чернового окна,
🛑как размер батча и запросы в нём влияют на количество генерируемых черновых токенов,
🛑как это влияет на инференс LLM на практике.

📅 Ждём всех в Толке в пятницу, 17 октября, в 15:00 (GMT+3).
🔗 Ссылка для подключения: Ктолк

#reading_group #llm #deployment

Мы начинаем🎃