🔴 Zero-shot модели для поиска конф данных в логах

Долгое время я думал, что в AppSec и так хватает тем и я не буду залезать на поприща смежных тем, но тут, возникла идея - "А что если в сок добавить чуточку магии?" И именно тут, я начал глубоко изучать тему с классификаторами, секретами и ML в частности. Вот Вы и читаете этот пост.

Чтож, если раньше soc-аналитики вручную проверяли логи или через сиемки (тут могла быть стебная шутка про то, что если выключить сием, то они ничего сделать не смогут, но она не прошла цензор), искали токены, session-id и приватные данные в инцидентах, то сегодня это можно отдать ML-модели.

Не в смысле "заменить человека", а в смысле - сделать анализ логов осмысленным и контекстным.

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

⚙️ Почему именно логи

Логи - это огромный, сырой и несовершенный поток внутренней информации.

В них можно найти:
🔘 токены доступа и refresh-ключи,
🔘 user/session identifiers,
🔘 stack traces с чувствительными payload’ами,

Regex тут бессилен, слишком много форматов, а чувствительность не всегда выражена словами “password” или “secret”, есть также куча нюансов по тому, как попадают логи и в каком формате лежат. Без глубоких познаний в архитектуре приложения, наши бравые L1(алладины🧞), L2 и L3 не смогут быстро и точечно детектировать что что-то не так или быстро искать нужные данные при инцидентах.

Поэтому, вместо бесконечных фильтров, я решил попробовать применить zero-shot классификацию, как это было в предыдущем посте.

💡 Идея

Используем pipeline(zero-shot-classification) и ставим задачу:

"Определи, содержит ли этот лог чувствительные данные."

Модель не ищет конкретные токены - она будет оценивать контекст: фраза, тип поля, значение, соседние строки, похожие проблемы.

Классы - "contains sensitive data" и "safe".

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

🧃 Что это даёт SOC

🟢 Ловит контекстные утечки, которые regex игнорирует:

2025-10-07 03:12:45,212 [debug] Internal audit event: user=svc_billing_01 executed task "ExportMonthlySummary" 
using temp credentials issued via ephemeral STS session. 
Token issued for role arn:aws:iam::934812734812:role/BillingReportAccess expires in 900 seconds.

Тут у нас:
- Нет самого секрета
- Фраза «temp credentials» не уникальна
- Энтропия нулевая
- Regex-подход без контекста не отличит «audit info» от реальной утечки.

🟢 Ускоряет triage инцидентов - модель подсказывает, какие логи стоит анализировать вручную.
🟢 Снижает шум при корреляции алертов и артефактов.
🟢 Работает без переобучения, просто через inference.

⛏️ Практические нюансики

🟢 Модели, показавшие хорошие результаты:

Прошу простить вашего админа, так как я не имею доступа к реальным большим логам, чтобы всё протестировать более детально

typeform/mobilebert-uncased-mnli - ТЫК
MoritzLaurer/deberta-v3-large-zeroshot-v1 - ТЫК
facebook/bart-large-mnli - ТЫК

🟢 Для скорости — нарезайте логи на чанки и прогоняйте параллельно.

🟢 CPU-инференс чаще всего достаточно, GPU не обязателен.

🟢 Обязательно сохраняйте контекст вокруг найденной строки - иначе ревью превращается в угадайку.

⚠️ Ограничения

🟣 Бинарные данные и hex без контекста не определяются
🟣 Модель может ошибаться на технических фразах ("token bucket", "auth middleware").
🟣 PII внутри сериализованных структур (JSON, Base64) требует дополнительного препроцессинга.

❓ Почему это важно

Zero-shot подход делает SOC-анализ умнее и масштабируемее, что помогает всему отделу безопасности. Из принципа, теперь можно не просто реагировать на сигнатуру, а понимать смысл лога и сразу видеть собранные/подходящие данные. И в этом, будет наша главная победа: от паттерн-matching-а к контекстному security-анализу.

Да, regex по-прежнему нужен, но теперь он не единственный инструмент на вооружении сока.

⚠️ CVE-2025-49844 (RediShell)

В Redis обнаружена критическая уязвимость CVE-2025-49844 (RediShell). Use-after-free в Lua-движке, присутствовавший в кодовой базе с момента встраивания Lua ~13 лет. Эксплуатация позволяет выполнить произвольный код в контексте процесса Redis при наличии права на запуск Lua-скриптов.

❌ Что ломается

🔘 Уязвимость связана с парсером Lua (функции вроде luaY_parser / chunk name handling) и тем, как chunk name управляется на стеке Lua до/после вызова. При обработке специально сконструированного скрипта парсер может вызвать garbage collector в момент, когда ссылка на строку уже считалась ненужной, но код парсера всё ещё держит указатель на эту строку. В результате возникает use-after-free или по нормальному - освобождённая TString используется повторно.

🔘 Опасность UAF состоит в том, что при корректной последовательности действий злоумышленник может управлять освобождённой областью и подменить управляемые структуры/указатели, что приводит к исполнению кода в процессе Redis, по сути - RCE.

✉️ Известные PoC

Тестировать только в изолированной среде

🔵 Лаба с практической средой и PoC-демо - raminfp/redis_exploit (ТЫК)
🔵 dwisiswant0/CVE-2025-49844 (ТЫК) - содержит разбор luaY_parser / chunk name GC-race

🧃 Конкретные индикаторы и артефакты soc

🔵 В логах Redis присутствуют непонятные EVAL/EVALSHA/SCRIPT LOAD вызовы от неизвестных клиентов, последовательности команд, которые загружают/исполняют скрипты
🔵 Необычные процессы/сигнатуры на хосте после взаимодействия с Redis (подмена процессов, новые сокеты, нетипичная сеть)
🔵 Вызовы EVAL с скриптами, содержащими необычные chunk-names или многократные попытки вызвать тяжелые парс-операции (triage: считать инцидентом)

📝 Митигейшены

🔘 Обновить Redis до версии с исправлением (Redis 8.2.2 или позже)
🔘 Если немедленный патч невозможен, то нужно отключить исполнение Lua - ограничить EVAL/EVALSHA через ACL (запретить соответствующие привилегии) или конфигурацию, пока не обновитесь

redis-cli ACL SETUSER service_user off >somepassword ~* -EVAL -EVALSHA -SCRIPT

🔘 Найти все инстансы (public и private), убедиться, что Redis не развернут публично без проксирования
🔘 Ротация учётных данных и ключей, если есть подозрение на компрометацию (особенно если Redis использовался для хранения сессий/токенов)
🔘 Добавить детекции в SIEM по EVAL/SCRIPT LOAD, аномалиям аутентификации и всплескам активности

🌐 Ссылки на источники

RediShell: Critical Remote Code Execution Vulnerability (CVE-2025-49844) in Redis, 10 CVSS score - ТЫК
Security Advisory: CVE-2025-49844 - ТЫК
CVE-2025-49844 Detail - ТЫК

Всем доброй ночи 🐈

🔔 Почему in-house SOC лучше аутсорса

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

Есть одна "уважаемая" компания. По связям проталкивает свои soc-услуги куда угодно: «мы быстрее, мы дешевле, у нас лучший MDR». А по факту - отсутствие экспертизы у интеграторов и неспособность оперативно решать ошибки подключения источников/нормализации/корреляции, проблемные агенты/их отсутствие, отговорки по типу "у нас нет данных", универсальные плейбуки, которые не знают ни вашего кода, ни ваших релизов. Красивые презентации - да, имеются. Практической пользы - минимум. Долги по SLA копятся быстрее, чем закрываются инциденты. И да, все "настройки под вас" упираются в договор и "в следующем квартале".

Главное слово для soc - адаптивность. Это когда корреляцию можно править сегодня, а не после совещаний, подтверждений или когда-нибудь потом. Когда у SOC есть доступ к репозиториям правил, к смбд, к релиз-планам и он понимает контекст событий. Адаптивность не покупается - её собирают внутри. Особенно при условии, что более менее здоровый и адаптированный под вашу инфраструктуру и контекст soc вырастает спустя год-полтора после начала работ

❌ Что обсёр аутсорсёр не даст

И это очень критично

🟣 Универсальные детекты не видят ваши бизнес-правила, а значит путают "норму" с инцидентом. FP не режется без знания архитектуры и данных.

🟣 Любая новая фича ломает "общие" правила. Внешний чендж-контроль = задержки в развитии. In-house меняет парсер/корреляцию в тот же спринт, если не в тот же день.

🟣 Когда TTP нестандартны, нужны инженеры, которые знают сервис изнутри, а не колл-центр по скрипту и отговорками по типу "у нас недостаточно даных"

🟣Своевременное реагирование в случае критичных инцидентов. Аутсорс, к сожалению, может только сказать "Вас вот тут ебут, смотрите" и развести руками


🧩 Почему свой SOC адаптивнее

🟢 Парсеры, нормализация (ECS/OTel), обогащения (CMDB, владельцы, релизы) - в одном репо. Можно выстроить процесс с другими командами иб и контролировать всё, начиная с пул реквестов и заканчивая деплоем релиза в прод.

🟢 Dev/SRE/SOC в одном канале, с едиными on-call и плейбуками. Нет прослоек из тикетов к внешним NOC.


🆗 Как изгнать нахлебников-аутсорсников из вашей сети

🔘Начните с инвентаризации вторжений.
Проверьте, куда эти "аудиторы" уже пролезли.
Доступы, vpn-токены, ssh-ключи, сервисные аккаунты в siem или интеграции, почтовые алерты на их домен - вычистите всё.
Если кто-то с внешнего адреса получает копии ваших инцидентов - это не партнёр, это наблюдатель с зарплатой из вашего бюджета.

🔘Заберите контроль над телеметрией.
Разверните свои пайплайны логов, сделайте свой брокер событий. Когда поток идёт через вас - вы решаете, что и в каком виде уходит наружу.

🔘Переопределите "их" зоны ответственности.
Никаких "общих" алертов, которые висят неделями.
Всё, что связано с продуктом, пользователями и кодом - только ваша зона.

🔘Перехватите коммуникации.
SOC-чат, инцидент-менеджмент, оповещения — всё через ваши каналы.
Когда инцидент сначала уходит внешнему диспетчеру, а потом вам — вы уже проиграли.
Аутсорс должен получать только то, что вы решили передать, а не наоборот.

👩‍💻 Что мы слышим и что отвечаем

🟡 "Мы дешевле" - дешёвый мониторинг равен дорогому инциденту.

🟡 "У нас экспертиза" - универсальная экспертиза без знания вашей инфраструктуры = красивые отчёты про "подозрительные события"

🟡 "24×7 спасёт" - круглосуточный просмотр fp - всё ещё fp. Спасает не часовая стрелка, а адаптивность

🟡 "Заполните excel таблицу о вашей инфраструктуре и мы скажем где у вас проблема" - я так проходил тесты "какой ты хлеб?" или "кто ты из феечек винкс?"

✏️ Вывод

Своя команда SOC - это не про "делать всё самим". Это про право быстро меняться, видя систему изнутри. Аутсорс можно использовать как усилитель покрытия и ночной мониторинг. Но ядро - внутри. Иначе вы отдаёте на сторону не "мониторинг", а способность принимать решения. И это самый дорогой актив безопасности в 2025 году.

🐾 Пост для тех, кто любит котиков, а не политику

- Женя Белкин, по поводу канала с фотками сырника - будет? Одна фраза, от вас зависит...
- Не будет.
- Не будет... Твердо и четко?
- Твердо и четко. И не просто это я придумываю. Или фантазия. Или не хотел бы. Нет, это всё просчитано...

Дальше должно было быть - смотрите, что я сделал и какая-нибудь история или мем, ну или пост, но будет только кот.

Ссылка на моего любимца, он теперь медиа-создание - ТЫК

👀 EdgeAI for Beginners или как думать локально

Есть репозиторий от микромягких - ТЫК

На вид - курс "для самых маленьких", на деле - дорожная карта, как строить и запускать EdgeAI-модели

EdgeAI - это подход, при котором искусственный интеллект выполняет обработку и принятие решений на самих устройствах: камерах, шлюзах, сенсорах, пк - без передачи данных в облако, что снижает задержки, повышает приватность и автономность систем

Звучит прям круто, но, как всегда, дьявол кроется в деталях 💥


🔎 Что внутри

🔹 01-03 - основы ML, inference и оптимизация (ONNX, quantization, Olive)

🔹 04 - перенос моделей в edge-формат (Llama.cpp, OpenVINO)

🔹 05-06 - интеграция и маршрутизация агентов, работа с api и sdk

🔹 07-08 - Production: контейнеризация, обновления, ci/cd


💎 Что реально полезно

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

🟢 Quantization, pruning, mixed precision, Llama.cpp - всё, что делает inference доступным даже на малинке (raspberry pi)

🟢 Edge-агенты, которые могут переключаться между моделями в зависимости от задачи и контекста

🟢 Проект не для рекламы, а для тех, кто реально хочет руками запустить edge-проект


❌ Где зарыты риски

🟣 В курсе ни слова о защите моделей от извлечения и подмены

Edge без харденинга превращается в лёгкую добычу: достаточно подменить файл .onnx или подгрузить свой агент

🟣 Модели стареют быстрее, чем устройства. Без централизованного ci/cd вы получите зоопарк несовместимых версий

🟣 Локальный inference спасает от утечек, но требует чёткого контроля, кто и как обучает модель на устройстве

🟣 Да, quantization снижает латентность, но без ручной оптимизации под железо результат непредсказуем


↗️ Как можно применить в ибешечке

💡 Edge-soc. Модели аномалий крутятся локально, не передавая логи наружу

💡 Автономные агенты-изоляторы. Edge-агенты, которые при обнаружении подозрительной активности сами закрывают порт или сегмент сети

💡 Контекстная фильтрация трафика. Модели на сетевых узлах классифицируют пакеты по смыслу, а не по сигнатуре

💡 Privacy-by-design. Локальный inference = меньше PII в облаке, меньше комплаенс-боли


👀 Что вынести из всего этого

Edge-модели позволяют работать там, где latency, регуляции и здравый смысл не дают слать всё в AI-облако.

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

НЕ MlSecOps, я не собираюсь продать вам воздух, а пытаюсь дать идеи как улучшить уже готовые процессы и без пунтков "постквантовая криптография"

TL;DR: изучить, адаптировать, не доверять без ревью, и да - ставить апдейты руками

🧠 AI, AI, AI, AI ... или документ по MLSec

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

Ссылка на GitHub - ТЫК

Что внутри

🔵 Обзор
🔵 Архитектура ML Sec и немного Ops
🔵 Этапы внедрения
🔵 Методы тестирования моделей
🔵 Инструменты
🔵 Управление секретами, Threat Modeling, безопасность LLM-агентов

Что буду делать дальше

🟢 Завершить разделы по CI/CD и ML-платформам
🟢 Добавить кейсы безопасности LLM-агентов и атак
🟢 Перевести ключевые разделы на английский, сделать мультиязычную версию

#mlsec

🧠 Как я строил свой безопасный MCP с головной болью, страданием и желанием всё бросить и уйти на OnlyFans

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

Они выполняют команды, ходят по API, читают внутренние данные и всё это без слоёв изоляции, без валидации и без УВАЖЕНИЯ аудита.

Решил это попытаться исправить - собрать свой безопасный MCP, который регулирует, как модель взаимодействует с инструментами и данными.

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

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

🧩 LLM != API Gateway

Первая головная боль - большинство систем воспринимают LLM как просто клиент, которому можно выдавать токен и hope for the best.

❌ Ошибка ❌

LLM - это не клиент, это динамическая среда исполнения, и ей нужен control plane, который будет отвечать нашим требованиям:

🔵 посредничает между моделью и внешними ресурсами
🔵 валидирует вызовы (RBAC, ABAC, PoLP)
🔵 и протоколирует всё, что модель делает
🔵 ну и не выебывается

В итоге, я сделал отдельный шлюз - MCP-сервер, через который проходят все действия агентов.

Он подписывает запросы, вставляет контекст авторизации и валидирует payload до передачи инструменту.

😤 Проблема с безопасностью

Когда тестировал прототип, стало ясно, что LLM умеет обходить собственные фильтры.

Кто бы мог подумать 👀

В одном случае агент "убедил" MCP-шлюз, что ему нужен доступ к системному токену, просто потому что в prompt был "!admin".

Решение:

🟢 фильтрация входных данных до LLM
🟢 валидация действий после вывода (double-side checking)
🟢 строгая типизация всех ответов (JSON schema)

Теперь любое действие проходит по цепочке:

➡️ intent - validation - approval - execution - audit - слитые данные


💎 Изоляция инструментов

Второй сюрприз - сами тулзы.

Часто они работают в общей среде с агентом, а это минус со стороны иб.

Я вынес каждый инструмент в отдельный контейнер с seccomp и AppArmor, подписал манифесты через Sigstore (спасибо, что в какой-то момент пришлось с ним плотно поработать 😵‍💫) и ввёл валидацию версий.

Если кто-то решит заменить бинарь или добавить вредоносный инструмент - MCP сразу откажет по подписи.


😳 Аудит и наблюдаемость

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

LLM без логов - как SOC без SIEM

Можно проследить, кто, когда и через какую модель вызвал API, и что ответил инструмент. Даже если агент ошибся, мы видим причину и контекст. Главное, очищать от конф данных.

⚙️ Что в итоге получилось

🔵 Полная трассировка действий агента
🔵 RBAC и подписи для каждого инструмента
🔵 Валидация входных и выходных данных
🔵 Контейнерная изоляция с политиками безопасности
🔵 Частичная поддержка human-in-the-loop для критичных операций

Теперь любой LLM работает в управляемом и наблюдаемом контуре, а не как хаотичный ассистент с SSH-доступом.

🍄 Что рекомендую, если решите строить свой MCP

1️⃣ Не давайте LLM прямой доступ к API
2️⃣ Изолируйте инструменты
3️⃣ Добавьте аудит
4️⃣ Введите human-approval для важных моментов
5️⃣ Стройте доступы как код

Пусть OPA или Kyverno решают, LLM - только инициирует

👀 Выводы

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

Документ с деталями - ТЫК
Если хотите внести вклад или протестировать подход - присоединяйтесь к коммюнити.

Если всё надоело - канал сырника 👀

🔗 Fulcio, Cosign, Rekor - три кита против невидимых подмен

Помню не зря пятый день ноября
И заговор пороховой.
Проходят века, но грусть и тоска
Всегда остаются со мной.

Современный CI/CD - это уже не сборка, а лабиринт доверия. Доверия к коллегам, коллегам из других отделов, разработчикам, к себе (тут вообще жуть). Git, runners, registry, helm-чарты, контейнеры, облачные кэши - каждый узел может быть точкой компрометации.

А теперь вопрос: "Откуда уверенность, что ваш контейнер в проде это тот же самый, что вы собрали на пайплайне?"

Если ответ - "мы верим CI", то, возможно, пора начать проверять, а не верить.


🧩 Что делает Sigstore

Sigstore - это открытая экосистема, которая превращает процесс сборки в криптографически доказуемую цепочку доверия.

Она подтверждает кем, где и из чего был собран артефакт: контейнер, бинарь, SBOM или даже модель ML.


🥳 Как работает механизм доверия

1️⃣ Сборка

Runner получает краткоживущий сертификат через OIDC-провайдера (например, Keycloak или Dex).

Cosign подписывает артефакт, прикладывая:
🔘 SHA256-хэш
🔘 issuer и subject (OIDC claims)
🔘 время подписи и provenance (commit, ref, build job ID)

2️⃣ Публикация

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

3️⃣ Верификация

Policy Controller при деплое проверяет подпись:
🔘 совпадает ли issuer с разрешённым
🔘 существует ли запись в Rekor
🔘 соответствует ли subject утверждённому pipeline

Если хоть одно нет - деплой останавливается.


🛠 Пример self-hosted реализации

Для компаний, где внешний интернет запрещён, Sigstore можно развернуть внутри контура.

Пример инфраструктуры:

# Развёртывание self-hosted Sigstore
git clone https://github.com/sigstore/helm-charts
helm install fulcio ./helm-charts/charts/fulcio \
  --set config.oidcIssuer=https://keycloak.company.local/auth/realms/ci \
  --set config.ca.type=self-signed

helm install rekor ./helm-charts/charts/rekor
helm install cosign-policy ./helm-charts/charts/policy-controller

Подпись и проверка выполняются так:

# Подписываем артефакт локально
COSIGN_EXPERIMENTAL=1 cosign sign \
  --fulcio-url https://fulcio.company.local \
  --rekor-url https://rekor.company.local \
  registry.company.local/backend@sha256:123...

# Проверяем подпись перед деплоем
cosign verify \
  --rekor-url https://rekor.company.local \
  registry.company.local/backend@sha256:123...

Результат содержит issuer, subject и время подписи - всё, что нужно для внутреннего аудита.


😑 Почему это важно для AppSec

🔵 Целостность артефакта подтверждается криптографически
🔵 Происхождение (кто собрал, когда и из чего) становится проверяемым фактом
🔵 Журнал Rekor обеспечивает доказательную базу для SOC и аудиторов
🔵 Kubernetes-policy превращает верификацию в обязательный шаг деплоя

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


❌ Практические нюансы, с которыми точно столкнетесь

🔘 OIDC-провайдер должен быть отдельным для Dev/Staging/Prod
🔘 Необходимо подписывать не только контейнер, но и SBOM, provenance и Helm-чарты
🔘 Проверка в policy-controller должна быть enforce, а не “audit”
🔘 Отдельный Rekor-журнал для каждой среды снижает риск сквозной подмены


👀 Итог

Sigstore и Cosign это не про подписи ради галочки. Это инструмент, который делает supply chain доказуемым, воспроизводимым и проверяемым.

В self-hosted варианте он превращается в вашу внутреннюю PKI-инфраструктуру нового поколения - лёгкую, автоматическую и привязанную к идентичности CI.

Если вы всё ещё деплоите контейнеры "на доверии", то это не DevSecOps - это просто вера в чудеса.