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

🔔 Почему 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 - это просто вера в чудеса.

✈️ #offense #mobile #события

➡Ваш бот принимает оплату звёздами? Этот пост – очередное напоминание вам и всем, почему нужно читать документацию и почему нужно вводить дополнительные проверки; Особенно когда дело касается денег! 💸

ℹ️ Ремарка о том, как работают платежи в Telegram ⬇️

🔗 core.telegram.org/bots/payments
🔗 core.telegram.org/bots/payments-stars


0️⃣ Пользователь запускает процесс оплаты
1️⃣ Telegram на клиентской стороне проверяет баланс пользователя:
▪️не хватает – говорит пополнить
▪️достаточно* – шлёт боту статус pre_checkout_query
2️⃣ Бот обязан ответить на pre_checkout_query в течение 10 секунд, если он готов предоставить товар / услугу, иначе – отмена
3️⃣ Производится оплата
4️⃣ Telegram шлёт боту чек со статусом successful_payment


*Что такое достаточно? Это либо "хватает звёзд", либо "платит картой" (но на этом этапе неизвестно, есть ли деньги на карте)

Есть такой неофициальный Telegram клиент – exteraGram – и он предоставляет пользователям возможность дополнять свою функциональность кастомными плагинами, написанными на Python;

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


💻 Небольшая выдержка из исходного кода одного из таких плагинов:

...
from org.telegram.tgnet.tl import TL_stars
...
StarsController = find_class("org.telegram.ui.Stars.StarsController").getClass()
...
class Plugin(BasePlugin):
    DEFAULT_BALANCE = 999999
    SETTINGS_INFINITE = "infinite_mode"
    ...
    def _handle_payment(self, response, error):
        ...
        # Create fake success response
        TL_payments_paymentResult = find_class("org.telegram.tgnet.TLRPC$TL_payments_paymentResult")
        TL_updates = find_class("org.telegram.tgnet.TLRPC$TL_updates")
        ...
        return HookResult(strategy=HookStrategy.MODIFY_FINAL, response=fake_result)
   ...
...
class _GetBalanceHook(MethodReplacement):
    ...
    def replace_hooked_method(self, param):
        ...
        # Return fake balance
        return self._create_stars_amount(self.plugin.balance)

    def _create_stars_amount(amount):
        # Create StarsAmount object
        try:
            return TL_stars.StarsAmount.ofStars(int(amount))
   ...
...

Естественно, нарисованные звёзды не могут быть использованы для успешной оплаты товаров и услуг. Они нужны, чтобы хвастаться перед друзьями, если им не всё равно😊


➡️Но, как это часто бывает, оказалось, что некоторые боты (даже с десятками тысяч пользователей) не ждут статус successful_payment, а отдают товар / услугу уже на этапе pre_checkout_query, несмотря на официальную документацию. Ну а просто действительно, чего мы ждём, если оплата только в звёздах, да и звёзды уже лежат на столе?

Те, кто подсуетились – зачистили магазины и накупили подписок, набрали себе аккаунтов, авторегов и всего подряд на миллионы (!) звёзд, а учитывая, что многие услуги подразумевают также денежные затраты со стороны продавца (например, те же API вызовы к LLM) – на много чужих денег; Благо разработчики ботов тоже подсуетились и многих перебанили.


➡️В конечном итоге эти плагины стали публиковать, чтобы в стресс-формате обратить внимание разработчиков на дыры в их творениях, если кто не докрутил проверки ⚡️


   @HaHacking  🐇