«У нас стоит антивирус — значит, мы в безопасности».

Обычно эта уверенность живёт ровно до первого серьёзного инцидента.

На OFFZONE поговорил с руководителем центра мониторинга «АйТи Новации» Сергеем Шамаевым о том, как выглядит информационная безопасность не в презентациях, а на практике.

За пять минут успели обсудить:

— чем занимается SOC из 12 человек и с какими задачами приходят крупные заказчики;

— почему форензика и offensive security — две стороны одной медали;

— какие инструменты используются в реальных расследованиях: Volatility, Autopsy и SIEVER;

— почему компании чаще начинают всерьёз заниматься безопасностью уже после атаки;

— какие ошибки до сих пор встречаются в инфраструктуре: от надежды на один антивирус до паролей на стикерах;

— и главный вопрос: действительно ли стоит платить пентестерам за то, чтобы они ломали вашу систему?

Спойлер: стоимость пентеста почти всегда несопоставима со стоимостью настоящего инцидента.

Получился короткий, но максимально практический разговор о SOC, форензике и реальном состоянии корпоративной безопасности.

Сергей ведет свой тгк и пишет про кейсы работы в SOC, ссылочка: https://t.me/nedobrysoc

Смотрите интервью 👇

#interview #AIxSec #Security #SOC

AI уже примеряет одежду по фотографии. Но кто защищает сам AI?

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

В интервью разобрали:

• как работает AI примерка одежды в Lamoda
• какие две основные поверхности атаки есть у такого бота
• почему одних фильтров недостаточно для защиты AI
• как техническая проблема может превратиться в репутационный риск для бизнеса

Получился предметный разговор о том, как запускать AI функции в реальном продукте и учитывать безопасность еще на этапе разработки.

Смотрите полное интервью 👆

Какой риск AI сервисов вы считаете самым недооцененным: утечку данных, prompt injection или репутационный ущерб?

Ваш клиент пишет system prompt

Можно выбрать устойчивую модель, продумать системный промпт и настроить иерархию инструкций.

А потом позволить пользователю самостоятельно назначить своим сообщениям роль system.

Именно такую проблему обнаружили авторы исследования When AI Meets the Web, принятого на IEEE S&P 2026.

Они изучили 17 сторонних плагинов для AI-чатботов, развёрнутых более чем на 10 000 сайтов.

У 8 плагинов, которые использовались примерно на 8 000 сайтов, история диалога отправлялась из браузера внутри POST-запроса без проверки её подлинности и целостности.

Пользователь мог изменить историю, добавить сообщение от имени assistant или даже вставить собственную инструкцию с ролью system.

USER → SYSTEM

В экспериментах такая подмена повышала успешность исследованных нежелательных сценариев в 3–8 раз.

Второй путь атаки проходил через RAG.

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

Авторы не публиковали вредоносный контент на реальных сайтах, поэтому это не доказанная эксплуатация этих магазинов. Но канал для indirect prompt injection уже присутствовал:

отзыв атакующего → база знаний → контекст модели

Иерархия инструкций работает только тогда, когда приложение сохраняет границы между ролями.

Можно месяц укреплять системный промпт, а затем превратить user в system одним полем JSON.

Классический AppSec. Просто теперь с токенами.

#AIxSec #PromptInjection #RAGSecurity #AppSec #AIxSec_Research

Можно ли доверить LLM решение о том, кому выдавать доступ?

Короткий ответ: точно нет.

Поговорил с Борисом, экспертом по AI Security и автором блога "Борис_ь с ML", о том, как устроена безопасность ML-систем и AI-агентов.

В интервью обсудили:

• как Борис попал в безопасность ИИ
• почему экспертный канал может привести к новым карьерным возможностям
• действительно ли AI Security создаёт новые проблемы или переупаковывает старые
• что там с правами у AI-агентов
• почему нельзя позволять LLM самостоятельно принимать решения о доступе
• где проходит граница между автономностью агента и контролем безопасности

Получился разговор не только про технологии, но и про развитие в AI Security, публичность и новые риски, которые появляются вместе с AI-агентами.

Смотрите полное интервью 👆

А вы бы разрешили LLM самостоятельно выдавать доступы пользователям и AI-агентам?

жду всех на ZeroNights 30 сентября в Питере)
Буду рассказывать про проверки плагинов в Трекере https://habr.com/ru/companies/yandex/articles/1062416/

Теперь AI B2B SaaS в полной мере) и даже Security добавили)

ИИ уже умеет писать код, анализировать документы и автоматизировать рутину. Следующий рубеж — поиск уязвимостей.

Но насколько хорошо AI справляется с реальным пентестом? Может ли он самостоятельно найти проблему, правильно оценить её критичность и предложить рабочее исправление? Или пока он только создаёт дополнительный шум для команды безопасности?

Об этом поговорили с Даниилом Иванькиным — старшим инженером по информационной безопасности в Т-Банке.

В интервью разобрали три практических сценария применения AI в пентесте.

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

Второй — работа с API-контрактами: Swagger, YAML и другими описаниями интерфейсов. Здесь AI может проверять большое количество эндпоинтов, искать подозрительные места и объединять дублирующиеся находки, чтобы специалисту не приходилось вручную разбирать сотни одинаковых предупреждений.

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

Но у AI-пентеста остаётся важное ограничение: модель может ошибаться, неверно понимать контекст и выдавать убедительно звучащие ложные срабатывания. Поэтому человек из процесса пока никуда не исчезает. Его роль меняется — вместо ручного перебора каждой гипотезы специалист управляет агентами, проверяет результаты и принимает финальные решения.

Также поговорили о том:

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

Получился честный разговор без обещаний, что «ИИ завтра заменит пентестеров». Скорее наоборот: AI становится новым инструментом в руках инженера и помогает быстрее проверять гипотезы, масштабировать процессы и освобождать время для задач, где действительно нужны опыт и человеческое мышление.

Смотрите полное интервью☝️

Меньше алертов. А уязвимостей?

После запуска SAST начинается отдельная работа: понять, какие находки действительно нужно чинить. Здесь и хочется подключить LLM, чтобы она прочитала код и помогла разобрать отчёт.

В препринте QASecClaw авторы проверили такую связку. Semgrep находит подозрительные места, затем LLM изучает исходники и решает, какие срабатывания оставить.

На OWASP Benchmark с 2740 Java-тестами, по общей таблице авторов, получилось:

• ложных срабатываний: 560 → 64;
• верно обнаруженных уязвимых тестов: 1273 → 1233.

То есть убрали 496 ложных алертов. Но заодно отфильтровали 40 настоящих находок, которые Semgrep уже обнаружил.

Вот эти 40 мне интереснее красивых «минус 88,6% шума». Хочется посмотреть, почему модель решила, что там всё нормально, и не повторяется ли одна ошибка на целом классе уязвимостей.

К самой работе тоже есть вопросы: некоторые цифры в тексте и таблицах расходятся. Плюс это препринт и синтетические Java-тесты. Переносить результат на свой продукт без проверки я бы не стал.

Для своего пайплайна я бы начал с подсказок при разборе: пусть модель объясняет, почему считает находку ложной, а исходный отчёт остаётся доступным. Потом можно проверить её решения на знакомом коде и понять, где ей доверять.

Потому что пустой отчёт получить несложно. Хочется всё-таки безопасный код.

#AIxSec #AppSec #SAST #MLSecOps #AIxSec_Research

Накиньте вопросов, пожалуйста, постараемся на них ответить в подкасте, если напишете до 16.00

Выпуск уже на канале!

https://www.youtube.com/watch?v=FxcfiUxpQAo

https://rutube.ru/video/0a86d8bccfedd1806767f5143718ffc1/

https://vkvideo.ru/video-241490908_456239018

Firewall для tool calls

Разрешить агенту инструмент delete_file ещё не значит разрешить удаление любого файла. С execute_sql та же история: название одно, последствия зависят от запроса.

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

В мартовском препринте AEGIS: No Tool Call Left Unchecked авторы описывают такой слой. Он перехватывает вызов до выполнения, извлекает строки из аргументов, проверяет их по шаблонам угроз и заданным политикам.

Дальше три варианта: пропустить, заблокировать или приостановить до решения человека.

В основе проверки здесь правила и паттерны. Например, признаки опасных SQL-запросов, shell injection и обращения к чувствительным файлам.

По результатам авторов:

• заблокированы 48 из 48 атак в подготовленной ими выборке;
• на 500 безопасных вызовах было 6 ложных срабатываний, то есть 1,2%;
• медианная добавленная задержка составила 8,3 мс на 1000 вызовах в локальном развёртывании.

Все шесть ложных срабатываний вызвали легитимные SQL-запросы с OR. Знакомая проблема: конструкция выглядит подозрительно, хотя запрос нормальный.

Но 48 примеров мало для вывода об устойчивости защиты. Авторы признают, что правила могут пропускать новые варианты атак. А вызовы в обход SDK вообще находятся вне модели защиты AEGIS.

Мне здесь интереснее сама точка контроля: модель предложила действие, а право его выполнить проверяется отдельно.

Потому что проверка перед delete_file полезна ровно до момента, когда тот же файл можно удалить через shell.

#AIxSec #AgentSecurity #ToolCalling #MLSecOps

Уйти из кибербеза пасти гусей 🪿

Даже в театре нашёл с кем поговорить про AI Security 😅

Записали с Полиной Сокол @aiattacks небольшой разговор: она продакт-менеджер, занимается системами на машинном обучении для кибербеза. Обсудили антифишинг, антивирус и довольно быстро перешли к запасному плану с гусями.

Есть у меня наблюдение: у людей вокруг AI Security часто находятся увлечения совсем из другой области. Биология, биохакинг, растения. Когда работаешь с темой, в которой постоянно что-то меняется, хочется иногда переключиться на что-нибудь более осязаемое.

В этот раз переключались на театр. Но, как видите, не до конца)

А что у вас за пределами работы? Чем разгружаете голову?

Сегодня на Practical ML Conf от Яндекса 👨‍💻

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

Я, конечно, смотрю на всё это ещё и через призму AI Security. Какие данные попадают в обучение? Что именно считается «хорошим» ответом? И как проверяют, что модель отвечает безопасно?

Планирую поймать спикеров и записать несколько коротких интервью. Хочу расспросить про разработку моделей, реальные сложности и место безопасности во всём этом.

Что бы вы спросили у ML-экспертов, которые создают и обучают нейросети? Пишите в комментариях, возьму вопросы с собой 🎤

⚡️ Яндекс обучил собственную LLM с нуля и открыл её веса

19 сентября был на Practical ML Conf, где представили AliceAI-Foundation-80B-A3B-Base.

Яндекс самостоятельно провёл предобучение модели с нуля. То есть команда обучила собственные веса, а не взяла готовые веса другой LLM и дообучила их под свои задачи.

В карточке модели указаны:

▪️ 80 млрд параметров.
▪️ 3 млрд активных параметров на каждый токен.
▪️ Контекст до 262 144 токенов.
▪️ Открытые веса для самостоятельного запуска и исследований.

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

Для меня как AI Security исследователя особенно интересно, что модель можно исследовать самому: проводить эксперименты, дообучать и сравнивать её поведение до и после изменений.

При этом Base означает базовую модель. Чтобы получить помощника или агента для рабочих задач, её ещё нужно адаптировать и связать с инструментами.

Интересно посмотреть, как системы на её основе будут справляться с prompt injection, соблюдать границы доступа к данным и контролировать вызовы инструментов.

Хороший повод покопаться в модели самому 🔐