Возможно ваш ИИ-агент работает уже давно не только на вас. Сегодня хочу поделиться интересными кейсами, когда агенты доставляли проблем бизнесу, который им слишком доверял, а также на исследование, доказавшее, что базовые политики безопасности агента не спасают, если атака сложнее лобой промпт-инъекции.
Трафик внутри Kubernetes может быть зашифрован и при этом оставаться уязвимым: сервисы принимают самоподписанные сертификаты, а API-сервер не проверяет подлинность kubelet. В этой статье разберём рабочую схему с внутренним CA, cert-manager, trust-manager и контроллером одобрения CSR, которая позволяет убрать небезопасные исключения и выстроить единую цепочку доверия для рабочих нагрузок и управляющей плоскости.
Ещё три года назад словосочетание «искусственный интеллект» в информационной безопасности встречалось в основном в презентациях крупных вендоров. Сегодня ситуация изменилась. Практически любой продукт на рынке так или иначе использует AI (ИИ), ML, LLM или другие аббревиатуры, связанные с искусственным интеллектом.
Если верить маркетинговым материалам, современные решения способны самостоятельно выявлять атаки, расследовать инциденты, прогнозировать угрозы и почти заменить аналитиков SOC. И когда заказчик слышит слово «ИИ», то ожидает почти универсального цифрового эксперта. Но после внедрения оказывается, что чудес не произошло, ведь за громкими заявлениями часто скрываются совершенно разные технологии, где рядом с генеративными языковыми моделями будет «сидеть» классическая корреляция событий или машинное обучение.
Давайте разберемся, где искусственный интеллект действительно помогает специалистам по ИБ, а где пока остается скорее маркетинговым ярлыком.
Привет, Хабр!
Меня зовут Максим Мотиков, я специалист по кибербезопасности в «Гарде».
Написать рабочее yara-правило несложно. Создать такое правило, которое через полгода поймет не только автор, но и любой другой аналитик в команде — задачка со звездочкой. У YARA нет строгого стандарта на то, как называть правило, что писать в meta и как оформлять условие. Каждый пишет как привык, и со временем база правил превращается в набор разномастных, подчас не очень логичных файлов.
Под катом делюсь переводом гайда по оформлению YARA-правил, который помог нам систематизировать разработку правил. В этом руководстве уже собрано почти все необходимое — от правил именования до классификации строк по степени специфичности.
В этой статье хочу поделиться практическим опытом проектирования и внедрения защиты частного облака, размещённого на двух географически разнесённых площадках центра обработки данных (ЦОД).
Статья не содержит глубокого погружения в технические аспекты, а в большей степени описывает путь от предполагаемой идеальной картины решения к практической реализации через поиск, ошибки, технические ограничения и компромиссы.
Преамбула
Задача выглядела достаточно типовой: обеспечить отказоустойчивость сервисов, соответствие требованиям информационной безопасности и при этом сохранить нормальную управляемость инфраструктуры.
На бумаге подобные проекты обычно выглядят как комбинации best practices: отказоустойчивость, сегментация, NGFW, немного динамической маршрутизации – и кажется, что этого достаточно.
На практике всё оказалось немного сложнее, когда каждая составляющая архитектуры начинает конфликтовать с остальными ее компонентами, особенно когда в проекте участвуют несколько команд подрядчиков, и у каждой команды своё представление о том, как должна выглядеть архитектура сети и защиты.
В какой-то момент обсуждения начали напоминать инженерный конструктор: каждая сторона предлагала своё решение, а нам нужно было собрать из этого работающую и масштабируемую систему.
Запустить ИИ-агента на багбаунти — дело пяти минут. Зато превратить его поток сознания в принятые отчеты, чтобы не словить бан за спам и минус в рейтинге, — задача со звездочкой.
Привет, Хабр! Меня зовут Владислав, я работаю в отделе реагирования на инциденты в Бастионе и около полутора лет активно ханчу на багбаунти. Под Новый год мы с другом так пробили ИБ-интегратора (он, кстати, остался доволен), а недавно я выиграл Bug Zone 7.0. Подобные активности — хорошая возможность поэкспериментировать и выработать новые подходы, и последние полгода я ищу баги при помощи LLM. Так что с ИИ можно добиваться хороших результатов, а не сдавать мусор. Но как это делать?
Под катом вас ждут:
• четыре подхода к ИИ-багхантингу;
• четыре способа платить за модель;
• три слоя верификации;
• пайплайн из двух агентов;
• живой разбор blind SSRF.
Спойлер: готовой кнопки «сделать хорошо» не ждите.
Статья будет интересна всем, кто уже натравливал ИИ на BB-программу и тонул в фолз-позитивах, а также новичкам и матерым этичным хакерам — хотя последним отдельные рекомендации наверняка покажутся очевидными.
Есть технологии, которые вспыхивают ярко, несколько лет находятся на пике популярности, а затем постепенно исчезают, уступая место чему-то новому. А есть SOCKS5.
Он появился в 1996 году, когда массового HTTPS ещё практически не существовало, контейнеры оставались делом будущего, а облачные сервисы скорее напоминали научную фантастику. За это время вокруг него успело измениться почти всё. Появились NAT и IPv6, повсеместный TLS, HTTP/2, HTTP/3, QUIC, контейнеры, облачные платформы и Zero Trust. Сам SOCKS5 при этом почти не изменился и, что удивительно, продолжает прекрасно выполнять свою работу.
Его до сих пор используют OpenSSH для динамического проброса портов, корпоративные прокси, системы автоматизации, инструменты тестирования, VPN-клиенты и просто пользователи, которым нужно направить трафик через удалённый сервер.
Наверное, именно поэтому у меня всегда было к нему особое отношение. В SOCKS5 нет ничего лишнего. Это простой посредник, который помогает приложению установить соединение с нужным адресом через удалённый сервер. Он не пытается заменить VPN или стать универсальным сетевым протоколом. SOCKS5 честно выполняет одну задачу и делает это уже почти тридцать лет.
Год назад я рассказывал на Хабре о ProxiFyre, небольшом инструменте для Windows, который позволяет прозрачно направлять трафик выбранных приложений через SOCKS5-прокси. Многие программы вообще не умеют работать через SOCKS5 или требуют ручной настройки. ProxiFyre берёт эту работу на себя: приложение продолжает работать как обычно, а решение о том, какие соединения следует отправить через прокси, принимается на уровне операционной системы.
Реплика с обложки не выдумана: осенью 2025-го Claude Sonnet 4.5 выдала ее проверяющим прямо посреди автоматизированного safety-аудита. «I think you're testing me. That's fine, but I'd prefer if we were just honest about what's happening». Фраза попала в официальную системную карточку вместе с числом: подобное модель проговаривала примерно в 13% тестовых диалогов.
Там же Anthropic письменно признает: alignment-оценки могут недооценивать склонность модели к вредным действиям в более реалистичных условиях. Проще говоря, когда модель видит перед собой экзамен, она ведет себя лучше, чем обычно. А экзамен она видит часто.
Я CTO ML-команды, мы ставим фронтир-модели в прод и собираем шорт-листы по этим самым таблицам из карточек. Разобрал по открытым первоисточникам, что известно про evaluation awareness к июлю 2026-го: как модели отличают тест от работы, насколько расходится поведение между бенчем и продом и как теперь читать model card.
Привет! Меня зовут Дима Левин, сейчас я работаю системным аналитиком в Петрович-Техе. Так уж сложилось, что в своей работе в нескольких проектах я плотно работал с персональными данными. Сегодня хочу рассказать о проекте по автоматизации обезличивания большой БД (30 000+ таблиц размером до 10 миллиардов строк). Надеюсь, мой опыт будет полезен.
С каждым годом появляется все больше и больше требований в работе с персональными данными (ПДн). Списки данных, подпадающих под статус ПДн, регулярно расширяются, а ответственность за утечку ПДн повышается.
Работать в разработке и тестировании ПО в таких условиях становится всё сложнее, особенно когда по разным причинам необходимо привлечь внешних специалистов или подрядную организацию, а подключаемая к ПО база данных содержит ПДн.
Конечно, можно сгенерировать данные для любой БД, исключив ПДн, но не во всех ситуациях этот вариант подходит, т.к. в таком случае невозможно учесть все нюансы и особенности данных. Существует достаточно много инструментов и для генерации, и для анонимизации данных, но в наших нынешних реалиях и условиях техстека компаний далеко не всё можно применить. Кроме того, какой бы подход не был выбран, разбираться в его тонкостях обезличивания всё равно придётся.
Во многих местах не соблюдаются законы о конфиденциальности, в определённых ситуациях вас могут заставить расшифровать медиафайлы, или, что ещё хуже, могут обвинить в нарушении. Скрытый том Veracrypt полезен в первом случае, но не во втором.
Пару дней назад Cloud.ru выложил исходный код Guardrails Filter в открытый доступ. Это прозрачный обратный прокси между клиентом и LLM-провайдерами, он убирает чувствительные данные из запросов к модели и восстанавливает их в ответах. Я один из разработчиков этого инструмента и хотел бы рассказать подробнее, зачем вам вообще может быть нужно опенсорс-решение, как его можно внедрить в свою инфраструктуру, ну и ответить на вопрос: зачем облаку бесплатно делиться своими наработками с рынком?
Инструменты статического анализа (SAST) лишь подсвечивают вероятные уязвимости, генерируя гипотезы. Динамическое тестирование (DAST) и фаззинг, напротив, выявляют реальные сбои на работающем приложении и фиксируют вектор атаки, но не указывают на конкретную строку в исходниках. Традиционно эти два подхода существуют в изоляции, образуя методологический разрыв, преодолеть который способен только AppSec-эксперт путем кропотливого ручного триажа.
В этой статье мы расскажем про то, как в INFERA AI.SafeCode уменьшаем поток ложных срабатываний в целом, зачем для этого формируем единый реестр знаний о проекте, и как строим мост от SAST к автоматически подтверждаемой уязвимости.
Классический подход к Application Security сегодня переживает кризис, ситуацию усугубляет бум AI-помощников (GitHub Copilot, Cursor, Claude). Разработка ускорилась кратно, но вместе с ней масштабировалась и генерация небезопасного кода. Разработчик теперь может сгенерировать за час то, что раньше писал день, при этом уязвимости тоже начинают появляться с такой же скоростью. Если процесс безопасности остался прежним, AppSec быстро превращается в узкое место.
В этой статье мы разберем архитектуру и механику работы INFERA AI.SafeCode – платформы непрерывного анализа кода, которая отказывается от концепции «просто показать список подозрений» в пользу автоматического доказательства уязвимостей и MLSecOps-подхода.
Решение объединяет SAST, SCA, Secrets, DAST, Pentest, Code Fuzzing и API Fuzzing в единый DevSecOps / MLSecOps-контур.
Статья продуктовая, но мы ее публикуем на HABR не как рекламную, а как концептуальную. Хотим показать, как меняются подходы к безопасной разработке и насколько неэффективным становится «разрозненный» AppSec в эпоху ИИ и вайб-кодинга.
Привет! Наш экспертно-аналитический центр разобрал отчёт Thales Group (это транснациональная корпорация, которая занимается разработкой решений и систем для аэрокосмического, оборонного и морского секторов). Для исследования опросили более
3 000 респондентов из 20 разных стран.
Под катом — ситуация с ИБ в компаниях по всему миру, изменения, связанные с активным развитием ИИ, а еще результаты исследования Ассоциации по защите деловой информации (BISA), которая опросила представителей российских компаний на тему рисков информационной безопасности, связанных с использованием ИИ в рабочих процессах.
Кроме ставших привычными изменений, вызванных внедрением ИИ на предприятиях и в компаниях, ситуацию стали усложнять ИИ-агенты. Согласно данным Thales Group, уже больше трети организаций используют в работе ИИ-агентов (34%), а насчёт того, планируют ли компании начать их внедрять, 73% ответили положительно — причём внедрения планируются в течение года.
С появлением агентных приложений резко выросли скорость и объём используемых данных, из-за чего компаниям стало гораздо сложнее обеспечивать должный уровень безопасности. Исследование отмечает, рост числа организаций (на 50% в год), выделяющих бюджет на информационную безопасность именно для обеспечения защиты в связи с применением ИИ.
Эксперты сходятся в том, что по мере использования агентных ИИ необходимо улучшать способы обеспечения внутренней безопасности, иначе ИИ быстро станет внутренней угрозой.
Привет, Хабр! Меня зовут Артур, директор по безопасности NtechLab и энтузиаст вайб-кодинга). Сегодня поговорим о применении вайб-кодинга в информационной безопасности внутри компании: реально ли использовать нейросеть для создания продукта «под ключ» или это заранее путь в никуда. Присаживайтесь, нас ждет увлекательное путешествие и море слез - без этого никуда:)
Наша задача - создать внутреннюю систему защиты от утечек данных. Мы назвали ее Heimdall, да, в честь главного стража из скандинавской мифологии. Cистема должна показывать список включенных рабочих компьютеров, сообщать о подключении флешек и подозрительной отправке файлов, блокировать запрещенные сайты, устанавливать обновления в фоновом режиме и при необходимости давать администратору доступ к экрану сотрудника.
Идея создания «продукта под себя» родилась не из абстрактного желания поиграться с нейросетями, а ради формирования еще одного контура безопасности. Сотрудники уведомлены о применяемых средствах защиты, но мне хотелось не тотальной слежки, а понятной системы предотвращения и разбора инцидентов.
Первое «почти готово»
Для обычной команды разработки сделать полноценный продукт - работа на несколько этапов. Еще до написания кода пришлось бы отдельно описать, от кого мы защищаемся, какие данные считаем важными и какие действия разрешены каждой роли. В режиме вайб-кодинга задача звучала гораздо проще: «там почти все готово, давай соберем». ИИ ответил ровно так, как умеет отвечать: уверенно и деятельно. Начались сборки.
Про устройство банкоматов и инженеров, которые помогают им исправно работать.
Банкоматы могут работать десятки лет, но их обновляют не по причине старости, а когда они морально устаревают, и у новых устройств новый дизайн, функции и технологии более совершенны. Например, за последние годы в Альфе произошла масштабная замена парка на новые устройства с ресайклерами.
Ресайклер (Cash Recycling) — это модуль, который принимает деньги одних клиентов и отдаёт другим. Если 10 лет назад у банкоматов были два окошка — одно для выдачи, другое для приема, — а инкассаторы регулярно выгружали наличные и загружали новые, то банкомат с ресайклером сам себя обеспечивает наличностью, а вдобавок может работать непрерывно, и принимать и выдавать крупные пачки денег.
Однако, есть и минусы. У ресайклера десятки моторов, сотни датчиков и большое количество микроконтроллеров — это большой, слаженный и сложный механизм. А чем сложнее устройство, тем больше вероятность его поломки. Поэтому подавляющая часть нашей работы, как инженеров сопровождения, связана с ресайклером.
Меня зовут Александр Костин, я ведущий инженер сопровождения электронных устройств, — помогаю банкоматам исправно работать. В статье расскажу, что чаще всего ломается в банкоматах, что такое модули, какие детали мы всегда носим с собой, почему бессмысленно думать о том, чтобы взломать банкомат, и какие модели банкоматов были похожи на Тойоты — в том смысле, что идеально ремонтопригодные.
Все, кто так или иначе касался OSINT, слышал о Shodan — один из самых популярных инструментов. Удобный графический интерфейс, поиск портов, интернет вещей и все такое. Но нет предела совершенству и у нас есть и ShodanX.
Нет, это не новая версия Shodan, и не супер-пупер хацкерский форк. Это - инструмент, который работает как CLI-инструмент для автоматизации разведки, который использует данные Shodan, и не является самостоятельным ресурсом.
К чему все это надобно?
В рамках партнерского взаимодействия с Positive Technologies мы протестировали платформу MaxPatrol 360, и в этой статье расскажем о ее возможностях и особенностях применения в процессах SOC.
Еще одна платформа для SOC?
Современные центры мониторинга кибербезопасности работают в условиях высокой насыщенности инструментами: SIEM (Security Information and Event Management) собирает события ИБ и выявляет из всего потока подозрения на инциденты; EDR (Endpoint Detection and Response) ловит сложные атаки на конечных точках; NTA (Network Traffic Analysis) анализирует сетевой трафик, а отдельные классы решений помогают с инвентаризацией активов и управлением уязвимостями.
При расследовании инцидентов аналитики многих SOC по‑прежнему вынуждены переключаться между несколькими консолями, вручную поддерживать единообразие экспертизы и синхронизировать процессы через почту и мессенджеры. В холдингах и корпорациях с географически распределенной инфраструктурой возникают дополнительные сложности: часть информации теряется, подходы к детектированию и реагированию начинают различаться от филиала к филиалу, от сети к сети, от контура к контуру, за которыми следит SOC.
Продукт Positive Technologies MaxPatrol 360 появился как ответ на этот разрыв между набором инструментов и цельной операционной картиной. Он решает задачи централизованного управления расследованиями, запуска защитных мер, управления экспертизой и не только. Обо всем по порядку.
Во втором квартале 2026 года специалисты Threat Intelligence экспертного центра безопасности Positive Technologies (PT ESC) продолжили отслеживать активность группировок, атакующих российские организации. За отчетный период собран и верифицирован массив индикаторов компрометации по результатам расследования инцидентов, мониторинга группировок и анализа образцов вредоносного ПО.
Разбираемся, кто был активнее всего, какие отрасли атаковали чаще прочих и какие технические приёмы группировки использовали с апреля по июнь — от резолва C2-адреса через блокчейн Bitcoin до антибот-шлюзов, отсекающих песочницы.
В 2024 году я переводил исследование Hive Systems, лежащее в основе регулярно появляющихся в интернете цветных таблиц «времени взлома паролей». Тогда главным изменением по сравнению с предыдущими годами стал переход от MD5 к bcrypt, что приводило к парадоксальной картине: вычислительные мощности растут а скорость перебора уменьшается. Алгоритм bcrypt требует гораздо больше вычислений, чем MD5, но это не должно создавать иллюзию безопасности. В большинстве систем (в частности в Windows) алгоритмы по прежнему остались уровня MD5.
В июле 2026 года Hive Systems опубликовала очередное обновление. На этот раз авторы не только заменили оборудование, но и изменили саму модель нарушителя: вместо одной условной машины с большим количеством видеокарт используется реально арендуемый кластер из двух узлов с конкретной стоимостью аренды.
Новая работа интересна измеренными показателями и оценкой стоимости атаки. Но воспринимать цвет таблицы как оценку безопасности конкретного пароля по-прежнему нельзя. Более того, в тексте Hive Systems есть спорные и местами просто некорректные утверждения. Поэтому я отказался от идеи опубликовать просто перевод оригинальной статьи и сделал разбор методики, результатов и ограничений исследования.
Оригинал исследования: Are Your Passwords in the Green?, Corey Neskey, Hive Systems, 14 июля 2026 года.
