Yandex for Security

🔒 Как устроена защита от ботов в Яндексе Меня зовут Руслан Сабиргалиев, я руковожу группой аналитиков службы доверия и надёжности. В Яндексе есть сервис для защиты сайтов и приложений от DDoS‑, веб‑атак и ботов — Yandex Smart Web Security, который разрабатывают несколько команд. C помощью схемы защиты с reverse proxy можно обезопасить ресурс даже вне контура Yandex Cloud. В качестве базовой технологии защиты от роботов и DDoS‑атак на уровне приложений (L7 модели OSI) в сервисе мы используем SmartProtection‑модуль на базе сервиса «Антиробот», который защищает в том числе и весь Яндекс. Мы делаем фокус на простых инструментах управления и недавно добавили в сервис новую функциональность по работе с роботами — Bot Management. Пользователям облачной платформы она даёт возможность самостоятельно настраивать правила для выделения роботного трафика буквально с помощью пары бегунков. Хочу рассказать, какая инженерная работа стояла за этими, казалось бы, небольшими улучшениями интерфейса. ♒️ Скоринг запроса Мы присваиваем оценки от 0 (человек) до 100 (бот). Модель обучается на разметке weak supervision и CatBoost с монотонными ограничениями — например, чем больше запросов с одного IP, тем выше скорбалл. Для настройки чувствительности у нас есть шкала: 0–20 (человек), 20–40 (вероятно, человек), 40–60 (зона неуверенности), 60–80 (вероятно, бот), 80–100 (бот). 🤖 Верификация полезных роботов Мы вручную верифицировали более 100 роботов по комбинациям User-Agent + IP/подсети, User-Agent + ASN и обратному DNS. И разбили их на 17 категорий. Наши критерии: принадлежность компании, стабильные идентификаторы, региональная специфика, значительность трафика и известность бота. 🔍 Больше полезных сигналов и резюме Мы расширили возможность борьбы с автоматизированным и подозрительным трафиком и добавили ASN (номер автономной системы) и tls‑fingerprint (JA4 и JA3). Это позволило ещё более гранулярно профилировать трафик защищаемого ресурса и управлять им. Также мы научили сервис поставлять дополнительные сигналы в виде логов и заголовков, которыми обогащается запрос, что позволяет использовать наш скоринг в собственных антифрод-движках, расследованиях инцидентов и очистке логов от роботного трафика. ⏩ Читайте больше подробностей в статье на Хабре. Там я поделился тем, как мы вообще пришли к созданию новых механизмов управления трафиком, и рассказал об устройстве weak supervision и практических сценариях использования. Подписывайтесь: 💬 @Yandex4Security 📹 @YandexForSecurity

⚙️Покажем, как использовать стандарт OpenID Connect в Yandex Identity Hub Приглашаем на вебинар, где разберём, как правильно использовать OIDC для аутентификации пользователей в приложениях и не допустить ошибок при внедрении, а также как грамотно и безопасно настроить OIDC-приложение и протестировать его работу без развёртывания собственного бэкенда — с нуля до рабочего прототипа. Когда и где: 📆 25 июня, 12:00 📺 Онлайн В программе: 🟣 Основы OIDC и OAuth 2.0 — роли, типы клиентов и grant flows 🟣 Выбор подходящего типа приложения для вашего сценария 🟣 Создание и настройка OIDC-приложения в Yandex Identity Hub 🟣 Тестирование OIDC без написания бэкенда — ключевые запросы А ещё мы покажем, как настройки Identity Hub и параметры запросов влияют на поведение приложения. 🧬 После вебинара вы сможете самостоятельно создавать и настраивать OIDC-приложения в Identity Hub, тестировать OIDC-интеграции без развёртывания серверной части и применять полученные знания при разработке и защите реальных приложений. ⏩ Зарегистрироваться Подписывайтесь: 💬 @Yandex4Security 📹 @YandexForSecurity

🤔 Как нейросети сходят с ума и можно ли это остановить AI-модели уязвимы к состязательным атакам — алгоритмам генерации состязательных примеров. Их создают злоумышленники специально, чтобы заставить нейросети некорректно работать. Для человека небольшие изменения исходного текста, картинки или видео почти незаметны или вообще не видны. Но при этом из-за особенностей алгоритмов машинного обучения нейросеть значительно меняет ответ при таких изменениях. И начинает делать то, что выгодно атакующему. 👨‍💻 Меня зовут Леонид Морозов, я инженер по информационной безопасности. Хочу рассказать, как именно работают такие атаки в случае текстовых моделей, какие бывают цели и возможности злоумышленников и какие способы защиты действительно работают. 🕵️ Читайте все подробности в карточках выше

«Хотя такие атаки актуальны скорее для негенеративных моделей (например, для классификаторов текста), в сочетании с другими приёмами они могут быть использованы и против генеративных LLM. В качестве одной из мер защиты сообщество предлагает использовать детекторы промпт-инъекций. Однако без применения описанных методов безопасности они могут быть легко обмануты с помощью состязательной атаки».

Подписывайтесь: 💬 @Yandex4Security 📹 @YandexForSecurity

👩‍🏫Как мы используем AI в кибербезопасности С помощью технологий искусственного интеллекта мы автоматизируем рутинные операции, моделируем вероятные угрозы и предотвращаем потенциальные инциденты. А ещё помогаем хакерам (но только этичным ❗️). Мы опубликовали отчёт об AI-технологиях в нашей системе безопасности, где рассказали, какие решения на базе искусственного интеллекта внедрили в 2025 году. И поделились, как защищаем инфраструктуру, пользователей и собственные нейросети. ♒️ Защита инфраструктуры 🟣 NeuroSecReview. Это AI-инструмент, который анализирует безопасность архитектуры продуктов ещё до начала разработки. С момента его запуска скорость таких проверок выросла в три раза. 🟣 Антиробот. Система защиты на базе AI в режиме реального времени анализирует входящий трафик. В 2025 году Антиробот отбил 866 крупных DDoS-атак, причём 99,9% — без участия человека. 🟣 AI-суммаризатор в SOC. Инструмент находит повторяющиеся срабатывания систем мониторинга и сам предлагает готовые правила для их устранения. Около 74% его предложений команды в итоге внедряют в работу. 🟣 AI-помощник в «Охоте за ошибками». Он анализирует отчёты этичных хакеров, находит похожие уязвимости и подсказывает инженерам контекст. Так решения о наградах принимаются быстрее. ♒️ Защита пользователей и бизнеса 🟣 Яндекс ID заблокировал более 110 миллионов подозрительных попыток входа и защитил от взлома свыше 11 миллионов аккаунтов. Наши алгоритмы машинного обучения анализируют поведение при авторизации и отсекают аномалии. 🟣 Яндекс Браузер предупредил 9,1 миллиона пользователей об опасных сайтах и предотвратил 12,4 миллиона загрузок вредоносных файлов. В этом нам помог Нейропротект, который ловит фишинговые страницы в реальном времени. 🟣 Определитель номера обработал 1 миллиард незнакомых звонков. 454 миллиона из них были признаны нежелательными или мошенническими. Наши нейросети учитывают более 300 параметров (например, массовый обзвон), поэтому качество выявления мошенников выросло на 40%. 🟣 Спамооборона теперь распознаёт «картиночный спам», когда вредоносный текст прячут в изображение. Мы добавили в систему защиты функции на базе технологий компьютерного зрения. За год почтовые серверы Яндекс 360 заблокировали 4,9 миллиарда вредоносных писем и отправили в спам ещё 11,9 миллиарда. 🟣 Smart Web Security в Yandex Cloud получил модуль ML WAF на базе технологий машинного обучения. Он ловит сложные веб-атаки, от которых нельзя защититься классическими методами. ♒️ Защита нейросетей Яндекса Мы развиваем семейство генеративных моделей Alice AI (для работы с текстом, изображениями и мультимодальными данными) и контролируем все этапы их жизненного цикла — от сбора данных до защиты в продуктах. 🟣 Мы первыми в России получили международный сертификат ISO 42001. Это подтверждение, что все наши процессы разработки и внедрения Alice AI безопасны и этичны. 🟣 В «Охоте за ошибками» появилось новое направление. Теперь участники могут искать уязвимости в наших генеративных нейросетях. Максимальное вознаграждение — один миллион рублей. ⏩ Скачать PDF-версию отчёта и узнать больше подробностей о безопасности в сервисах Яндекса можно здесь. Подписывайтесь: 💬 @Yandex4Security 📹 @YandexForSecurity

🥁 У нас есть победители Розыгрыш трёх проходок на закрытый митап Assume Birch состоялся. Мы поздравляем победителей 🎉: 🟣 @vIadim1r 🟣 @Broiler787 🟣 @fdsarr_officiall ⏩ Свяжемся с вами в личных сообщениях в ближайшее время. Но это ещё не всё На самом митапе мы будем выдавать купоны на увеличение выплат багбаунти: +13 337 рублей за лучший вопрос спикеру. 🚀 До встречи на Assume Birch! Подписывайтесь: 💬 @Yandex4Security 📹 @YandexForSecurity

🎉 Розыгрыш завершен! 🏆 Победители: 1. @vIadim1r 2. @Broiler787 3. @fdsarr_officiall 🔍 Проверить результаты

🚘 Новая реальность: эксплойт за 15 минут и один доллар Всем привет! На связи Денис Макрушин из команды SourceCraft Security. Возможно, вы уже видели мой пост в этом канале — тогда я рассказывал про топ-10 атак на веб-приложения. Сегодня поделюсь, почему генерация эксплойтов на основе CVE за 1 $ и 15 минут — это хорошая новость и для security-инженера, а не только для злоумышленника. ♒️ LLM изменили правила игры Они дали исследователям возможность для генерации эксплойтов к известным уязвимостям на основе их описаний и патчей. Это сократило время между обнаружением бага и его эксплуатацией с десятков часов до 15 минут. Стоимость разработки такого эксплойта — около одного доллара (в другом похожем исследовании средняя цена составила 2,77 $). Но это не меняет сути: процесс эксплуатации уязвимостей стал дешевле и доступнее. Теперь представим, что злоумышленник может автоматически создавать эксплойты для всех 100+ CVE, которые выходят ежедневно. ⚙️ Как это влияет на security-процессы 🟣 Политики исправления уязвимостей в течение 7 дней (а у кого-то и всех 90) неактуальны и требуют обновления. Время реакции команды продуктовой безопасности должно сократиться до нескольких минут 🟣 Временным преимуществом является закрытая кодовая база. Её нужно использовать для самостоятельного поиска «низко висящих фруктов» в своём коде с помощью LLM. Например, AI SAST 🟣 В процессе управления уязвимостями нужна система для дополнительной верификации находок. Она поможет точнее определять приоритеты в потоке критических проблем, а при необходимости — генерировать патчи ♒️ Как мы подтвердили это на практике Здесь нам помогли наши инструменты SourceCraft Security. До внедрения в платформу функций AI-триажа разработчик тратил на разбор одной находки от 10 до 20 минут. Это время требовалось, чтобы восстановить контекст, изучить уязвимый фрагмент кода и вынести вердикт. После того как мы добавили возможность использовать LLM для этих задач, разработчик с помощью одной кнопки стал получать разобранную находку. В итоге стоимость обработки уязвимости снизилась до нескольких секунд. 🧠 Какой контекст о проблеме передавать в модель для точного ответа: 🟣 codeBlock — основной фрагмент кода, который связан с проблемой 🟣 ruleName — правило анализатора, которое нашло дефект 🟣 engine/engineType — какой движок обнаружил проблему 🟣 severity и cvssScore — критичность находки 🟣 firstFoundCommitHash — коммит, где дефект был впервые найден 🟣 latestCommitHash — последний коммит, где дефект всё ещё есть 🟣 latestTimeFound — время последнего обнаружения 🟣 shortDescription, fullDescription, helpText, helpUri — описание проблемы и ссылка/подсказка для исправления А с недавних пор мы передаём ещё и трассу. Это путь данных по коду: от источника (source) через промежуточные шаги (propagation) до опасного места (sink). ⏩ Что можно сделать прямо сейчас Если вы решили построить такую же систему для своих задач, используйте этот опыт и контекст в качестве первого шага в сторону снижения ложных срабатываний и ускорения разбора багов. 🔒 Из упомянутых исследований можно извлечь ключевую идею: архитектура такой системы должна быть модульной, чтобы задача разработки эксплойта выполнялась на разных этапах разными агентами. И не забывайте тщательно тестировать автосгенерированные патчи. Подписывайтесь: 💬 @Yandex4Security 📹 @YandexForSecurity

🎟️ Разыгрываем три проходки на закрытый митап 📆 18 июня в Москве пройдёт Assume Birch — камерный ивент для специалистов по кибербезу с докладами, направленными на атакующую безопасность, и нетворкингом. Митап проходит дважды в год в формате закрытой встречи для своих. Попасть туда просто так нельзя: только по приглашению организаторов или как +1 от спикера. На митапе выступят два наших инженера: 🟣 Заряжай, но проверяй: анализ уязвимостей экосистемы шеринговых зарядных станций. Данила Урванцев, инженер по ИБ Городских сервисов, расскажет об исследовании реального устройства, которое проводилось в период интеграции сервиса аренды пауэрбанков «Бери заряд» в экосистему Яндекса 🟣 Твой Secure Boot не твой: как мы автоматизировали проверку загрузчиков умных устройств. Дмитрий Сибирцев, инженер по ИБ Алисы и Умных устройств, объяснит, как устроены загрузчики в Умных устройствах и как мы построили инструмент, который автоматически проверяет целостность и подлинность прошивок без запуска на железе 🛎 Разыгрываем три проходки на Assume Birch среди наших подписчиков. Участвуйте, если вы точно сможете присутствовать очно в Москве 18 июня. Условия: 🟣 Подписаться на канал «Охоты за ошибками» 🟣 Подписаться на канал Assume Birch 🟣 Быть подписчиком нашего канала Yandex for Security 🟣 Нажать на кнопку «Участвую» под этим постом 🧩 Каждый участник получит свой номер. 9 июня мы определим трёх победителей с помощью силы рандома и вручим проходки на закрытый митап. 💕 Желаем всем удачи! ⏩ С подробными правилами конкурса можно ознакомиться здесь. Подписывайтесь: 💬 @Yandex4Security 📹 @YandexForSecurity

👩‍🏫 Осваиваем Yandex SIEM SIEM часто считают сложным в настройке и эксплуатации: долгое подключение, непростой язык запросов, высокий порог входа для команд. Поэтому мы решили устроить практический вебинар, где покажем, как начать работать с Yandex SIEM, и подробно разберём, как автоматизировать типовые сценарии и сокращать время реакции на атаки — от анализа алертов до расследования инцидентов. Когда и где: 📆 4 июня в 12:00 📺 Онлайн На вебинаре обсудим: 🟣 Основы работы с языком KQL 🟣 Детектирование в SIEM и основы разработки правил 🟣 Поиск событий, триаж и анализ алертов в интерфейсе SIEM 🟣 Расследование и реагирование на инциденты ⏩ Зарегистрироваться на вебинар 👀 Ждём руководителей и аналитиков SOC, ИБ-специалистов, SIEM-инженеров и всех, кто ищет облачное решение для мониторинга и расследований Подписывайтесь: 💬 @Yandex4Security 📹 @YandexForSecurity

🛎 Приглашаем на 401 meetup Это свободная, вендор-независимая встреча про Identity & Access Management. Мы сфокусируемся на тематике IAM: аутентификация, авторизация и всё, что лежит вокруг этого 😉 Когда и где: 📆 27 мая в 18:00 📍 Москва, ул. Льва Толстого, 16, БЦ «Морозов», подъезд 4, этаж 1, зал «Мулен Руж» В программе: 🟣 Использование развёрнутого контекста устройства и сессии в корпоративном IAM на базе приложения-аутентификатора. Дмитрий Грудинин, архитектор Identity Security-решений в Avanpost, разберёт концепцию обогащения контекста IAM-системы информацией об устройствах 🟣 Разработка своего IAM в схемах и мемах. Сергей Ипатов, руководитель группы разработки в Лаборатории Касперского, расскажет про опыт разработки своего IAM-решения с использованием расширений OAuth2/OIDC, протокола SCIM и NGAC 🟣 Политики ограничения в Yandex Cloud IAM. Антон Дедов, архитектор функций безопасности в Yandex Cloud IAM, поделится, как были разработаны политики, которые расширяют текущую модель авторизации в облаке: от абстрактных конструкций к реализации ⏩ Больше подробностей и регистрация — на сайте. Подписывайтесь: 💬 @Yandex4Security 📹 @YandexForSecurity

🥹 Как команда ИБ Яндекса делает умные устройства и роботов безопасными 23 мая в Москве и онлайн пройдёт конференция про девайсы, где команда информационной безопасности не только расскажет, как в Яндексе устроены механизмы защиты в устройствах и сервисах, но и будет ждать вас на своих стендах. Приходите знакомиться и обсуждать вопросы кибербезопасности в сложных технологических продуктах: подходы, процессы и инженерные решения! ♒️ Почему это важно? Безопасность — это не отдельная «надстройка», а такое же требование к качеству продукта, как стабильность и функциональность. Команда ИБ работает с реальными технологическими вызовами: от инфраструктуры и данных до роботов и автономных систем, где критерии защиты особенно высоки. ♒️ Что команда ИБ расскажет на Я.Железе? 🔒 Доклад «Безопасность в устройствах Яндекса» Вадим Радовель, системный разработчик, и Никита Лычаный, инженер информационной безопасности в Алисе AI и Умных устройствах, расскажут, какие технологии и методы харденинга они разрабатывают и применяют на практике. А также уделят особое внимание деталям внедрения шифрования и контроля целостности в Linux. 🔍 Один из инсайдов доклада: в Android dm-verity и шифрование идут из коробки, но на встраиваемом Linux весь стек приходится собирать вручную. Вместо жёсткого диска — Flash-память, поэтому до dm-verity нужно пройти через слои MTD → UBI → UBIBLOCK. И только тогда можно запустить блочную проверку хеш-дерева. Ключ шифрования находится в kernel space в зашифрованном виде. В итоге на «ванильном» Linux мы получаем уровень безопасности, который не уступает Android, — но ценой ручной сборки 5–6 компонентов с учётом специфики железа. 💻 Послушать ребят можно будет офлайн или онлайн во время трансляции. Кто придёт очно — ищите стенды: 🟣 Алиса AI и Умные устройства 🟣 Автономный транспорт и роботы ⏩ Больше подробностей о конференции и регистрация — на сайте. Подписывайтесь: 💬 @Yandex4Security 📹 @YandexForSecurity

⚙️ Как мы добавили EPA в FreeTDS и go-mssqldb Представьте: злоумышленник через NTLM relay получает доступ в ваш MSSQL и забирает контроль над SCCM — одним из самых критичных инструментов управления инфраструктурой 🤯 🤝 Меня зовут Булат Гафуров, я инженер по информационной безопасности в Яндексе. Мы с командой не хотели ждать эксплуатации этой уязвимости, но стандартных решений оказалось недостаточно. Поэтому мы добавили поддержку механизма EPA (Extended Protection for Authentication) в популярные библиотеки. Такой подход переключает защиту на стороне MSSQL в режим Require и не ломает у Linux- и Windows-сервисов доступ к данным. ⏩ Что такое NTLM relay Это техника, при которой атакующий перехватывает аутентификационные данные клиента и пересылает их на нужный сервер, чтобы получить доступ к сервису от имени жертвы. И неважно, куда именно она подключается. Особенно уязвимы сервисы, которые работают под SYSTEM или Network Service и аутентифицируются в сети именно из-под машинной учётной записи. SCCM — типичный пример этого. ⏩ Зачем нужен Channel Binding Кажется, что настроенный TLS и проверка сертификата сервера надёжно защищают от MITM-атак. Но с NTLM relay всё сложнее: атаки могут быть кросс-протокольными. Именно для защиты от подобного и существует Channel Binding (CB) — механизм, который даёт криптографическое доказательство того, что обе стороны общаются по одному и тому же TLS-каналу. А конкретное значение, которое клиент передаёт серверу для верификации, называется Channel Binding Token (CBT). Как именно CB защищает от атаки: злоумышленник перехватывает TLS-соединение → не может изменить CBT → сервер отклоняет аутентификацию. ⏩ Что мы сделали 🟣 Разобрались, как TDS (Tabular Data Stream) работает поверх TLS. Версии 7.4 и 8.0 различаются, и это влияет на вычисление Channel Binding Token 🟣 Научились передавать CBT через GSS-API для Kerberos и через AV_PAIR для NTLM. Так атакующий не способен подменить значение 🟣 Написали свой диссектор для Wireshark. Стандартный не умеет парсить TDS внутри TLS 🟣 Запилили два пул-реквеста. FreeTDS и microsoft/go-mssqldb 📖 Читайте все подробности в статье на Хабре. Там я объясняю, как работает EPA, чем режим Require лучше Allowed и как добавить поддержку EPA в свой клиент. Подписывайтесь: 💬 @Yandex4Security 📹 @YandexForSecurity

👩‍🏫 AI-агенты в ИБ: путь к доверенному члену команды ♒️ Один неверный вывод AI-агента в SOC — и компания может остаться без домена, а вместе с ним без Kerberos, LDAP и части критичных сервисов. Искусственный интеллект в ИБ действительно умеет разгружать команды: он быстрее разбирает поток алертов, помогает в триаже и берёт на себя рутину там, где у аналитиков уже не хватает рук. ♒️ Но есть нюанс: такой агент может не просто ошибиться, а эскалировать собственное заблуждение в полноценный инцидент, если дать ему слишком много полномочий. Поэтому главный вопрос уже не в том, нужен ли AI в безопасности, а в том, где заканчивается автоматизация и начинается опасный автопилот. Нужны ограничения, проверки, защитные слои и обязательный контроль человека в критичных действиях, иначе помощник легко превращается в источник риска. ⏩ Читайте на Хабре разбор того, как внедрять AI-агентов в ИБ без иллюзий и излишнего доверия. Подписывайтесь: 💬 @Yandex4Security 📹 @YandexForSecurity

⚙️ Принципы, которые помогают строить надёжную архитектуру 🤝 Привет, это Евгений Сидоров, директор по информационной безопасности Yandex Cloud. Наша команда отвечает не только за защиту всей платформы облака, но и за разработку продуктов, которые используют тысячи клиентов. В этом посте расскажу, как устроена наша работа и какие задачи мы решаем. Поехали 🟣 〰️ Security by design с самого начала Безопасность в архитектуре нужно закладывать на этапе проектирования: не исправлять уязвимости после релиза, а предотвращать их появление. Один из примеров — система управления доступом IAM. Изначально она была простой: три предопределённые роли и выдача доступов на уровне всего облака. Мы перестроили систему, чтобы усилить безопасность. Теперь права можно назначать на отдельные ресурсы, группы ресурсов и сервисные аккаунты. Всё по принципу минимальных привилегий: каждому пользователю и сервису даётся ровно столько доступов, сколько необходимо для выполнения задачи. 〰️ Бок о бок с разработчиками Специалисты ИБ курируют команды разработки и делятся с ними стандартами безопасности. Мы проводим security review и указываем на проблемы в коде и архитектуре. А также проводим регулярные аудиты: анализируем, как команды следуют стандартам, выявляем отклонения и помогаем их устранить. 〰️ Эшелонированная защита от уязвимостей Мы ищем уязвимости на всех этапах жизненного цикла продукта и выстраиваем несколько слоёв контроля: 🟣 Когда разработчик пишет код 🟣 Во время сборки финального продукта 🟣 При тестировании и выкатке, когда код движется к продакшену 🟣 В проде — мониторим работающий код и среду его исполнения 🟣 При анализе внешнего периметра: как мы выглядим со стороны, что видят клиенты и потенциальные злоумышленники Для дополнительной проверки используем пентесты, когда внешняя компания пытается взломать периметр и эксплуатировать уязвимости. А также проводим учения purple team: наш SOC и внешняя команда атакующих совместно моделируют сценарии обхода защиты. 〰️ Система дежурств У нас нет чёткого разделения на обычные и инцидентные дни: происшествия случаются непредсказуемо. Зато есть несколько типов дежурств: 🟣 По инцидентам 🟣 По доступам 🟣 По безопасной разработке 🟣 По фаерволу 🟣 По общей безопасности Когда возникает инцидент, дежурный немедленно прекращает все текущие дела и приступает к реагированию. Его задачи — снять первичное воздействие, провести анализ и проинформировать клиентов. После этого инцидент передаётся дежурному по общей безопасности, который определяет действия для устранения корневой причины или распределяет задачи по командам. ⏩ А про направления внутри команды, работу с клиентами и культуру роста рассказываю в статье. Подписывайтесь: 💬 @Yandex4Security 📹 @YandexForSecurity

🔒 Как мы защищаем умные устройства Колонки, ТВ и камеры с Алисой сегодня уже не просто бытовая электроника. Эти устройства формируют экосистему, в которой безопасность — важное свойство продукта. Меня зовут Никита Лычаный, я инженер по информационной безопасности Алисы и Умных устройств Яндекса. И мне нужно быть по обе стороны баррикад: проектировать защиту и понимать, как её ломать. Сегодня я расскажу, что помогает нам обеспечивать безопасность устройств. Аппаратный уровень 🟣 Первое, на что я смотрю, — процесс загрузки. Механизм Secure Boot проверяет подлинность и целостность каждого этапа: от неизменяемого аппаратного кода BootROM до пользовательских приложений. Это фундаментальный механизм безопасности, без которого остальные слои защиты просто теряют смысл. Аппаратная изоляция 🟣 Даже если злоумышленник получит доступ к части системы, критичные операции и данные должны остаться вне досягаемости. 🟣 В устройствах на базе ARM мы используем TrustZone. Это два раздельных контура исполнения операций: обычная среда и защищённая область. Пользовательская ОС 🟣 Сетевое взаимодействие с облачной инфраструктурой я рассматриваю как ещё одну границу. 🟣 Передача данных по зашифрованным каналам с проверкой подлинности сторон закрывает целый класс атак, которые связаны с перехватом и подменой трафика. Поэтому она является обязательным элементом современной безопасной архитектуры. Чувствительные данные 🟣 Логи — это одна из самых частых точек утечки информации. Разработчик пишет отладочный вывод, случайно включает в него содержимое запроса, а там — токен авторизации или другие важные сведения. 🟣 Сервис маскировки решает эту проблему автоматически. Он работает как фильтр на выходе любого лог-вызова: перед тем как данные попадают в файл или систему сбора логов, она проходит через набор паттернов. Если они сработали — чувствительная часть строки заменяется на маску. ⏩ В статье на Хабре я поделился кейсом закрытия аппаратной уязвимости. А также объяснил, в чём заключается роль внешних исследователей в программе «Охота за ошибками». Подписывайтесь: 💬 @Yandex4Security 📹 @YandexForSecurity

🔒 Запатентовали новую технологию: как мы объединяем регионы в облаке Облачные провайдеры разворачивают инфраструктуру в разных географических зонах со своими дата-центрами, питанием и охлаждением. Это помогает снизить задержки, повысить отказоустойчивость и адаптироваться к локальному законодательству. Но тут возникает интересная задача: нужно изолировать региональные облака так, чтобы сбой или атака в одном месте не затронули другие. При этом пользователи должны управлять ими как единым целым. Команда безопасности Yandex Cloud получила патент на технологию объединения облаков, развёрнутых в разных регионах. Она изолирует инфраструктуру на уровне безопасности и позволяет пользователям бесшовно переключаться между локациями внутри одной организации. 🕵️ В карточках разбираем, как устроена эта архитектура А полный доклад смотрите на платформах: 🟣 Ютуб 🟣 VK Видео 🟣 Рутуб ⏩ Или читайте подробности в блоге Yandex Cloud Подписывайтесь: 💬 @Yandex4Security 📹 @YandexForSecurity

🦊 TrustYFox: от пет-проекта к рабочему инструменту Всем привет, это Андрей Фримучков, руководитель службы разработки платёжных интерфейсов. В карточках я показываю, как создавал TrustYFox — платформу, которая ищет уязвимости в коде с помощью LLM. А тут расскажу об основных фичах: 🟣 Всё стабильно работает в нескольких локациях 🟣 Инструмент сам переключается между базами и переживает учения по закрытию локаций, умеет продолжать прерванный аудит 🟣 Можно тестировать гипотезы на разных промптах и аудитах через механизм тегов 🟣 Для сбора контекста используется tool calling 🟣 Можно запускать аудит в выбранной ветке или ревизии 🟣 Права и доступы корректно разграничены 🟣 Есть механизмы observability, в том числе метрики 📖 В полной статье на Хабре делюсь техническими деталями и кодом. А также рассказываю, над чем работаю сейчас и что в пете можно было бы сделать по-другому. Подписывайтесь: 💬 @Yandex4Security 📹 @YandexForSecurity

🔒 Что такое guardrails и как их атакуют Даже хорошо обученная LLM остаётся уязвимой к prompt injection — это когда злоумышленник через пользовательский ввод или вложенный контент меняет поведение системы. Jailbreak — частный случай инъекции, при котором атакующий стремится обойти встроенные ограничения и политику безопасности. Проблему усугубляет и то, что system- и user-инструкции не изолированы друг от друга. Промпт-инъекции могут привести к различным последствиям: 🟣 Утечка данных (в том числе системного промпта) 🟣 Обход safety‑фильтров и генерация запрещённого контента 🟣 Компрометация агентных сценариев (tool calling) 🟣 Репутационные риски и падение доверия к продукту Инциденты регулярно показывают индустрии, что слепо доверять LLM нельзя: Microsoft Tay (2016), утечки системных инструкций в Bing Chat/Sydney (2023), кейсы вокруг Grok (декабрь 2025). Чтобы обезопасить модели от промпт-инъекций, можно использовать guardrails — набор механизмов, которые в рантайме проверяют вход, выход и поведение LLM. Когда они срабатывают, запускаются разные пути защиты: блокировка, санитизация, регенерация, перевод в безопасный сценарий. Guardrails помогают снизить риск промпт‑инъекций, но у каждого свои недостатки: 🟣 Blacklist запрещённых фраз — легко обходится перефразированием, синонимами и опечатками (любыми способами обфускации) 🟣 ML‑классификаторы — атакующий может изменить запрос так, что модель начинает считать промпт безопасным (adversarial-атаки) 🟣 LLM‑as‑a‑judge — саму проверяющую модель тоже можно обмануть (second-order prompt injection), поэтому гарантий такой подход не даёт. Зато это единственный метод, который анализирует контекст диалога Но различные типы guardrails можно комбинировать между собой, чтобы компенсировать их слабые стороны. Рабочая стратегия — не искать панацею, а построить эшелонированную защиту: с валидацией форматов, классификаторами, проверкой контекста, мониторингом и регулярным red teaming (особенно для агентных систем с инструментами). ⏩ А для агентных архитектур полезно опираться на практические рекомендации вроде AI Secure Agentic Framework Essentials (AI‑SAFE) от команды безопасности Yandex B2B Tech. 📺 Смотрите полное выступление Андрея и Максима по ссылке. Подписывайтесь: 💬 @Yandex4Security 📹 @YandexForSecurity

👩‍🏫 Как устроено управление правами в SAP Privileges на macOS Привет, это Булат Гафуров, security-инженер в Яндексе. Недавно по работе я решил попробовать Privileges. Это опенсорсное приложение для macOS от компании SAP, которое предназначено для быстрого и удобного управления правами локального администратора. Чтобы точно знать, с чем предстоит иметь дело, я клонировал репозиторий. И подробно разобрался, как именно работает приложение. 〰️ В первую очередь меня интересовало, может ли атакующий получить права локального администратора без подтверждения пользователя. Главная защита завязана на XPC и audit token. Каждый запрос к агенту или демону сопровождается системным идентификатором процесса, который нельзя подделать. На его основе macOS проверяет подпись вызывающего приложения. Если клиент не подписан тем же разработчиком или изменён, то соединение разрывается. Это закрывает самый очевидный сценарий — притвориться легитимной утилитой. Попытка обойти аутентификацию через CLI не сработает. Логика проверки вынесена в агент, который повторно валидирует запрос. Перескочить этап с Touch ID или паролем и напрямую вызвать повышение прав не получится. Более того, демон, который реально меняет группы пользователей, принимает команды только от агента с корректной подписью и bundle id. Отдельный слой защиты — Hardened Runtime и Launch Constraints. Они не дают подключиться отладчиком, внедрить код или запустить сервисы вне ожидаемого сценария. Даже если переподписать приложение, остальные компоненты перестанут ему доверять, и цепочка сломается. На практике это делает скрытое повышение привилегий через Privileges крайне маловероятным сценарием, если система настроена корректно. ⏩ В статье на Хабре: подкапотные подробности о том, как взаимодействуют компоненты приложения, через что происходит обмен сообщениями и на чём строится доверие между процессами. 🔒 Системным администраторам будет интересно узнать, почему Privileges можно доверять. А для разработчиков в статье описан пример хорошей архитектуры безопасной утилиты. Подписывайтесь: 💬 @Yandex4Security 📹 @YandexForSecurity