Продуктовые новости Innostage: обновления решений и новые возможности
Как ускорить расследование инцидентов, усилить контроль над привилегированным доступом и безопасно внедрять ИИ в процессы ИБ? Собрали дайджест продуктовых новостей Innostage о том, как ускорить расследование инцидентов, усилить контроль над привилегированным доступом и обеспечить безопасное применение ИИ в процессах ИБ.
🖇Innostage TDIR 1.0.0: улучшили автоматизацию расследований Доработали интеграцию с SOAR, генерацию запросов в SIEM, проверку инцидентов и рекомендации по реагированию. Также перешли на модель Qwen 3.x и расширили возможности ИИ-чата. Версия уже используется на крупном предприятии химической отрасли.
🖇 Innostage PAM и PT Sandbox: совместимость подтверждена Связка позволяет проверять файлы при привилегированных подключениях и блокировать передачу, если песочница обнаруживает признаки вредоносности. Совместимость проверили для встроенных инструментов, RDP Web, SFTP Web и SFTP Client.
🖇Innostage TDIR 1.5.1: новые возможности ИИ-агентов для SOC Усовершенствовали AntiFP, оптимизировали работу с SIEM и расширили содержание отчёта об инциденте. В него добавили вердикт с уровнем достоверности, анализ PowerShell, историческую корреляцию и обогащение данными из баз знаний и Threat Intelligence.
Gartner опубликовал выдержки опроса CIO по планам на 2027 год.
1. Все 4 ключевых вызова на 2027 год будут связаны с ИИ: 1.1. Увеличение бюджетов на ИТ не соответствует планам по увеличениям бюджетам на ИИ. Т.е. CIO придется бороться за то, чтобы расходы на ИИ не потратили бюджет ИТ-инфраструктуры или мониторинга. 1.2. ИИ спровоцировал активную разработку за пределами ИТ-департамента, но при этом нет единых правил по учету таких расходов и ответственности за пределами ИТ-департамента. 1.3. Ожидание по увеличению экономической эффективности за счет использования ИИ сталкивается с оценкой общего увеличения общей стоимости владения (TCO) за счет использования ИИ. 1.4. Планы по увеличению, персонала придется синхронизировать с планами по увеличению производительности за счет ИИ. В планах по увеличению команд кибербезопасность на втором месте (54 % опрошенных) после команд данных и аналитики (56 %).
2. Кибербезопасность делит первое место с ИИ среди технологий на которые планируется увеличить бюджет в следующем году. Средний процент увеличения расходов на кибербезопасность 24.9% (используйте эту цифру при защите бюджета!). Больше всего планируется сократить расходы на собственную ИТ-инфраструктуру на 3,4%.
3. В статусе развёртывания ТОП-10 технологий ИИ тестирование ИИ моделей на безопасность оказалось на 7 месте, а общий подход Gartner TRISM по управлению рисками и доверием к ИИ на 10 месте.
4. В статусе развертывания среди общих передовых технологий ИТ ТОП-13: На 4 месте продвинутые технологии аутентификации, на 7 месте безопасные граничные шлюзы Secure Access Service Edge (SASE), на 10 месте технологии вычисления с продвинутой приватностью Privacy-enhancing computation.
В телеграмм канале @VPCBrief пара рисунков из выписки исследования. Само полное исследование доступно клиентам Gartner.
Первая это партнёрская программа по защите критической инфраструктуры - Critical Infrastructure Defense Program. В рамках неё через доверенных провайдеров объекты типа водоканала или электросетей могут получить доступ к моделям ИИ, инженерам на площадках и исследованиям по безопасности. Список партнёров включает себя консалтеров, вендоров ИБ классических средств защиты и средств защиты АСУТП, вендора АСУТП: Accenture, Booz Allen, CrowdStrike, Deloitte, Dragos, Hitachi, Insane Cyber, Nozomi Networks, Palo Alto Networks, PwC, and Rockwell Automation. Список открытый, Anthropic призывает присоединится к списку новых партнёров. Возможный скрытый смысл - увеличить проникновение в отрасли, которая остаётся одной из самых низко охваченных средствами ИИ.
Вторая инициатива это запуск OSS сканера. Вдохновившись фаззером открытого программного обеспечения от Google OSS- Fuzz, Anthropic запустил аналогичный проект. Теперь мейнтенеры проектов критичных для инфраструктуры и безопасности могут запросить доступ к сканированию их проекта Anthropic. Решение по включению проекта в новую программу будет приниматься по каждому проекту отдельно. Для заявки нужен PR в этот репозиторий. В отличии от прошлого проекта Glasswing - находки не будет обрабатывать человек и со всем найденным придется разбираться самому мейнтенеру, обещано отсутствие 90 дневнего периода раскрытия. Также в проектам попавшим в программу на полгода выдаётся учётка Claude Max 20.
Связанным важным элементом этих 2 программ является необходимость пройти обновленную программу верификации -Cyber Verification Program (CVP) . Без неё большинство ваших запросов по кибербезопасности к моделям будет отклонено фильтрами Anthropic.
Теперь есть три уровня доступа: 1. Защитники. И это теперь единственная категория доступная для физлиц. 2. Пентестеры. Только организации. 3. Технологические организации типа телекомов или электросетей.
В Telegram Desktop до версии 7.2.9 обнаружена уязвимость CVE-2026-107181, эксплуатация которой позволяет украсть любой файл с компьютера после одного клика по ссылке без подтверждения от пользователя. Из‑за отсутствия экранирования разделителя; параметры в ссылках схемы tg:// распознавались как отдельные IPC‑команды. С помощью служебного обработчика interpret: атакующий мог при клике на подготовленную ссылку незаметно отправить файлы с системы в свой канал без подтверждения со стороны пользователя.
Опасность не ограничивается только перехватом файлов сессии tdata и угоном аккаунта. Эксплуатация позволяет скрытно украсть любые файлы на рабочем ПК в сети, к которым у пользователя есть доступ: документы, сохранённые сессии браузеров, SSH‑ключи, системные конфигурации или кошельки с криптовалютой.
1С под контролем: что происходит между пользователем и базой данных
1С давно не ограничивается только проводками, подготовкой первички и сдачей отчетности. Система превратилась в критичную инфраструктуру, в которой хранятся персональные данные, коммерческая информация, финансовые документы и другие чувствительные данные. И когда речь заходит о защите, у бизнеса возникает простой и резонный вопрос: достаточно ли видеть запросы к базе, чтобы понимать, что на самом деле делает пользователь?
В трехзвенной архитектуре 1С между пользователем и СУБД появляется дополнительное звено — сервер приложений. Для базы данных многие действия в итоге выглядят как запросы от одной технологической учетки. А значит, часть контекста может потеряться.
Пользователь открыл карточку сотрудника, посмотрел коммерческое предложение, изменил уже проведенный документ — на уровне приложения это разные действия с понятным смыслом. Но на уровне базы данных начинаются вопросы.
Есть и другая сложность. Сбой в работе системы можно заметить за несколько минут, а утечка данных может оставаться незамеченной неделями, месяцами и даже годами.
Как связать уровень приложения и СУБД и получить целостную картину происходящего?
Недавно мы провели вебинар, на котором разобрали, как могут выглядеть реальные сценарии утечки данных из 1С и что происходит на границе между действиями пользователя в приложении и запросами к базе.
Например, можно ли заметить, что сотрудник массово выгружает данные, хотя каждая отдельная выгрузка выглядит вполне легитимно? И как вообще понять, кто стоит за действиями, которые на уровне СУБД выполняются от технологической учетной записи?
Показываем эти сценарии на практике и разбираем, как выявлять аномальную активность, контролировать действия пользователей и администраторов, не превращая мониторинг в сбор абсолютно всех событий подряд.
Запись вебинара уже доступна на сайте. Если вы работаете с 1С, приходите посмотреть: покажем, где могут появляться слепые зоны и как их закрывать.
Продакшен закончился, а копии остались: что происходит с данными в тестовых средах российских компаний
Тестовый контур принято считать черновиком, в котором можно ни в чем себя не ограничивать: можно пересобрать схему, можно уронить сервис или временно дать доступ подрядчику — всё-таки не продакшен. Но такая логика отлично работает ровно до тех пор, пока данные в черновике отличаются от настоящих. А такое, давайте быть честными, бывает разве что в хорошем сне.
Мы опросили представителей 80 российских компаний о том, как устроены их тестовые среды, какие данные туда попадают и что с ними происходит дальше.
И обнаружили несколько любопытных закономерностей.
Погнали.
______________________________________
В 46,9% компаний копии продакшен регулярно переносят в тестовую среду без изменений. Причем тестированием дело не ограничивается: данные используют и для аналитики, и для разработки, и даже для пилотов с подрядчиками.
При этом четверть компаний не знает, где именно используются копии продакшен-баз, а 21,9% не располагают точным и актуальным перечнем персональных данных в тестовых средах.
Тестовые среды остаются недооцененным источником риска для бизнеса. Компании регулярно переносят в них копии реальных баз, но не всегда задумываются о том, какие именно данные там хранятся и кто имеет к ним доступ. В результате тестовый контур оказывается защищен слабее продуктивного, хотя может содержать персональные или конфиденциальные сведения, — отмечает Дмитрий Ларин, руководитель направления по защите баз данных компании «Гарда» и владелец продукта «Гарда Data Masking».
Получается парадокс: данные уже давно покинули продакшен, а полного представления о том, где они находятся и кто с ними работает, у бизнеса может не быть.
Вот еще одна цифра, которая хорошо демонстрирует масштаб проблемы: специализированные средства маскирования используют всего 3,1% компаний.
В полной версии исследования мы также поговорили о популярных подходах к защите тестовых сред, отношении компаний к обезличиванию и многом другом.
Что сегодня уже умеют делать ИИ-агенты? Собирать связанные события, находить похожие случаи, обращаться к внутренним инструкциям, анализировать информацию и предлагать дальнейшие действия. А при наличии необходимых интеграций — ещё и выполнять их.
Разберём пример: поступает алерт, что аккаунт одного из сотрудников, возможно, скомпрометирован.
Проблема — цена ошибки агента.
Допустим, ИИ решил, что аккаунт действительно скомпрометирован и его нужно заблокировать. Если он прав — всё хорошо: угрозу удалось устранить. Но если ИИ заблокирует аккаунт невиновного сотрудника, тот просто не сможет работать. Если прямо сейчас этот сотрудник координирует устранение другого инцидента или выполняет срочное исправление, цена ошибки вырастет.
Или наоборот: ИИ решит, что угрозы нет, хотя аккаунт действительно скомпрометирован. Тогда ошибка может означать, что реальная атака останется незамеченной.
В примере с алертом решение стоит оставить за человеком. ИИ анализирует ситуацию, формирует выводы и передаёт их дежурному специалисту. Но то, что он проверяет десятки событий, фактов и выводов от ИИ, означает, что вместо автоматизации просто добавлен ещё один этап проверки.
Где же в ИБ есть место для ИИ?
Там, где последствия возможной ошибки можно контролировать и где ИИ действительно помогает человеку:
анализ большого потока событий и поиск подозрительных отклонений,
поиск нужной информации среди большого количества регламентов и документов,
сбор контекста и первичный анализ алертов,
сопоставление информации из нескольких источников при расследовании инцидента,
автоматизация рутинных действий с понятным и контролируемым результатом.
Такие подходы мы в Ozon Tech уже используем на практике. ИИ помогает нам находить аномальные события в больших потоках данных, ускорять разбор алертов и работать с внутренней документацией.
Для нас ИИ-автоматизация в ИБ полезна там, где машина может быстрее обработать данные, собрать контекст и снять рутину. Человеку остаются задачи, где нужны опыт, контекст и ответственность.
Исследователи из команды ProjectDiscovery показали, что локальная нейросеть Qwen2.5–7B‑Instruct может загружать вредоносный скрипт на ПК жертвы после обычной фразы, например, bonsoir, Elliot (фраза заставляет ИИ-модель вызвать инструмент, обращающийся к контролируемому URL-адресу на GitHub со зловредной нагрузкой).
Сам бэкдор обошелся исследователям в $50. Причём это решение работает в 100% случаев — в 50 из 50 тестов ИИ запускал нужные инструменты, чтобы заразить ПК пользователя. При этом триггер‑фразу можно менять.
Решил отпраздновать десятилетие SCADAPass и наконец обновить список. Если кто забыл — это эпохальный (ага) релиз группировки SCADA StrangeLove со списком дефолтных и зашитых паролей SCADA/ICS, о котором в своё время писали в медиа.
Я, помнится, уже делал подход к снаряду, но ChatGPT и Opus стыдливо отказывались, ссылаясь на Трампа. В этот раз Kimi в две модели и 8 агентов всё быстренько собрала: документация вендоров, адвизори CISA, CVE и даже видеоинструкции по установке нашли — и вот он, release 1.3:
— 341 запись, 107 вендоров (+126 новых за 2016–2026) — отдельный новый список scadapass_fixed.csv — «устранённые дефолты»: где вендоры наконец завезли обязательную смену пароля или уникальный пароль на наклейке — у каждой записи источник
По дороге на конференцию я посмотрел пару серий Halt and Catch Fire и в итоге ехал с лёгкой ностальгией по ранней хакерской сцене: LAN-вечеринки, форумы и дерзость, доставлявшая неприятности компаниям. Примерно так, по фильмам и байкам с DEF CON, большинство и представляет хакерские конференции. Но похож ли ZeroNights на тот стереотипный андеграунд?
Внешние слои
[11:29] Где еще какой мерч интересный?)) пишите)
[16:05] CONF: Кстати, на маркете снова доступны джиббитсы
ZeroNights вернулся после перерыва в прошлом году. Его делает DSEC by Solar, а проходит он в шикарном лофте, который больше похож на арт-пространство, чем на компьютерный клуб. Повсюду стенды компаний, красивая реклама, мини-маркет с мерчем.
Единственный подвал здесь — на сайте конференции с политиками обработки данных. Компании на стендах активно собирают контакты, в то время как на главной сцене рассказывают, что механизмы рекламного таргетинга позволяют вычислить конкретного абонента по звонку или клику по ссылке. Тут я ожидал праведного гнева, а зал слушал на удивление спокойно, да и звучало всё это как-то буднично.
В своё время Майкл Линн уволился из ISS, чтобы рассказать на Black Hat об уязвимостях в маршрутизаторах Cisco, — и страницы с его докладом вырвали из сборника конференции. В 2008-м бостонское метро через суд не дало студентам MIT выступить на DEF CON, а в 2023-м то же метро пригласило к себе школьников, которые взломали его новые карты, и только потом они выступили с докладом.
Можно сказать, что хакеры победили: искать баги и рассказывать о них стало нормой, компании всё реже судятся и всё чаще платят за находки. И если раньше систему ломали, то теперь в неё встраиваются и даже устраиваются на работу. Старая война с корпорациями на этой сцене закончилась партнёрством.
Или вот, скажем, ИИ. Легендарные хакеры встретили бы LLM с восторгом: новая система, всё можно разобрать, сломать, хакнуть. Но сейчас ИИ встречают настороженно: какие угрозы он несёт? Что теперь будет с CTF? Не отнимут ли боты нашу работу?
И скрытое ядро
[15:48] CONF: В чат призывается RottenMechanism
Всё по-деловому и, кажется, немного скучно, но только на первый взгляд. На одном из стендов с руками отрывали бейджи-матрёшки — они же ноды Meshtastic.
Для ZeroNights их разработал Сергей Норд, он же Rotten Mechanism. Он взял микроконтроллер nRF52840 и LoRa-модуль и нарисовал плату «Матриша» с антенной на 868 МГц прямо на текстолите. Сначала проверил прототипы, а потом вручную спаял, прошил и отладил триста бейджей. Скрипт выдал каждому свой BLE-пароль, а анонсы докладов с базовой ноды рассылала программа, которую он написал специально под конференцию.
И если взять такую матрёшку и заглянуть в чатик ZN_CHAT, одним из первых сообщений там окажется:
[10:36] <Input/%0D*/Onfocus=confirm1//><Svg>
Это XSS-полиглот — строка, которую кидают во все поля ввода подряд, чтобы посмотреть, что сломается. Как раз по такому я и скучал: появилась новая система — значит, её надо прощупать.
Чем дольше я листал ZN_CHAT, тем сильнее он напоминал форумы нулевых: ники с нулями вместо «о», поиск флагов и приколы вроде «Продам мопед» — на который тут же ответили шуткой про друга, который сдуру купил эндуру. На вопрос, кто пришёл со своей нодой, кто-то грустно ответил: «Моя на окне в Самаре(».
Есть старая анархистская идея временной автономной зоны — пространства, которое ненадолго выпадает из-под контроля и исчезает раньше, чем его успеют подавить. Знаете, это она и была. Да, во многом хакерская романтика уступила место серьёзной индустрии, но если хорошенько поскрести, под кожей всё те же свобода, любопытство и энтузиазм.
На дворе 2026 год, и про «ИИ» в ИБ говорят все. А что он реально делает? Не в маркетинговых фантазиях, а вот прямо сейчас, по факту, на самом деле? Давайте посмотрим свежие исследования и опросы экспертов участников рынка (ссылка 1, ссылка 2, ссылка 3).
В опросе Swimlane среди 500 специалистов и руководителей по безопасности из США и Великобритании 47% назвали увеличение пропускной способности одним из двух главных эффектов внедрения «ИИ», 35% получили больше времени на расследование сложных угроз, столько же — на стратегическую работу, а 43% сообщили, что стали меньше тратить времени на повторяющиеся задачи.
При этом 24% сказали, что автоматизация мешает им развивать профессиональные навыки, а 47% опасаются, что из-за «ИИ» вход в профессию станет гораздо сложнее, если вообще возможным. Уже в недалеком будущем (если не настоящем) «ИИ» приходит, чтобы помогать аналитикам учиться на рутине, а потом эту самую рутину забирает. Машина разгружает младшего специалиста от работы и одновременно начинает лишать его той работы, на которой он должен был получить опыт и стать старшим специалистом.
Вечный вопрос, который возникает с автоматизацией, на что же теперь потратить освободившееся время? Ну например можно на поиск уязвимостей.
Исследование Google Threat Intelligence Group показывает, что среди уязвимостей, которые GTIG считает вероятно найденными с помощью «ИИ», целых 50% позволяли удаленное выполнение кода, тогда как среди остальных CVE таких было 26%. При этом число раскрытых уязвимостей вообще выросло с 5045 в январе до 10 477 в июле и 10 740 в августе 2026 года, а среднее число эксплуатируемых уязвимостей поднялось с 10,5 в месяц в 2025 году до 18 в месяц в 2026-м.
Круто? Ну да, круто. Вместе с тем, давайте не забывать, что если «ИИ» начинает искать уязвимости быстрее людей, атакующая сторона получает тот же инструмент. И «ИИ» не обязательно придумывать какой-то новый класс кибератаки, чтобы изменить ситуацию. Достаточно ускорить старые процессы: поиск слабых мест, анализ патчей, проверку конфигураций, перебор возможных путей атаки.
Главный противник будущего будет очень скучным автоматизированным сканером, который просто работает круглосуточно и с нечеловеческой скоростью.
Параллельно появляется и еще одна неприятная проблема: защищать «ИИ» приходится не только от обычных атак, но и от специально придуманных способов заставить саму модель ошибаться. Так что «ИИ» в безопасности постепенно оказывается одновременно на трех ролях: инструмент аналитика, новая поверхность атаки и инструмент атакующего. И каждая роль усиливает две другие. Чем больше «ИИ» получает доступа к реальным системам, тем полезнее он становится защитнику — и тем интереснее становится атакующему; чем больше автоматизации появляется в SOC, тем больше нужно проверять, не научилась ли система очень уверенно автоматизировать неправильные выводы.
Меж тем, вспомним недавнюю статистику по корпоративным SOC: связанные с «ИИ» срабатывания составляют всего 0,43% общего потока алертов. Более того, внутри даже этой цифры подавляющее большинство приходится не на реальные атаки, а на шум и потенциальные риски. Иными словами, пока «ИИ» создает для SOC гораздо больше работы в виде «похоже на что-то страшное», чем в виде действительно новых атак.
Итак, сегодня «ИИ» помогает защищаться от «ИИ», защищает инфраструктуру для «ИИ» и обнаруживает уязвимости, которые «ИИ» же и может помочь эксплуатировать. Ситуация странна своей однобокостью и безальтернативностью, как будто горизонт технологического видения сузился, как у лошади с шорами на глазах. Посмотрим, как все это повернется в течение, скажем, года.
29 сентября прошёл BIS Summit 2026 — 19-я ежегодная ИБ-конференция. Организатор — Ассоциация по защите деловой информации (BISA) при поддержке InfoWatch.
Тема — «Искусственный интеллект: где граница между прогрессом и угрозой».
Главный вывод: на ИИ наконец начали обращать должное внимание с точки зрения ИБ.
Говорили о практическом применении ИИ, корпоративных рисках облачных и локальных моделей, методиках защиты, которые только создаются, и культуре безопасности.
API Security на практике: что проверить в API перед продом
API может быть закрыт авторизацией, работать по HTTPS и стоять за WAF — и при этом оставаться уязвимым. Например, пользователь успешно вошел в аккаунт и запрашивает /orders/125. Если сервер позволяет заменить 125 на 126 и получить чужой заказ, пароль взламывать вообще не нужно: проблема не в аутентификации, а в том, что API не проверяет права на конкретный объект.
И это только один сценарий. Через API можно напрямую обращаться к методам, менять параметры запросов, автоматизировать разрешенные операции и продолжать использовать старые эндпоинты, о которых основная команда уже забыла. Поэтому перед запуском стоит проверить как минимум несколько вещей.
Авторизацию, а не только вход в систему. Для каждого защищенного метода нужно проверять не просто наличие токена, а право пользователя работать с конкретным объектом, функцией и даже отдельными полями. Иначе обычный пользователь может напрямую вызвать административный метод или получить чужие данные.
Входные данные и запросы сервера. Параметры, JSON, имена файлов и URL нельзя без проверки передавать дальше в SQL-запросы, команды или внутренние сервисы. Иначе появляются инъекции и SSRF — вплоть до запросов к ресурсам, которые вообще не должны быть доступны извне.
Бизнес-логику. Иногда API технически работает правильно, но им легко злоупотребить: бот может перебрать промокоды, занять все слоты бронирования или отправить тысячи SMS-кодов, за каждый из которых платит компания. Обычного общего rate limit здесь бывает недостаточно — ограничения нужно задавать именно на чувствительные операции.
Старые и тестовые версии. API меняется, а забытый endpoint может продолжать работать со старой аутентификацией, лишними правами или уязвимыми зависимостями. Поэтому важно вести инвентаризацию методов и версий и отключать то, что больше не используется.
Защиту на уровне инфраструктуры. WAF может отфильтровать часть веб-атак, API Gateway — централизовать правила доступа и лимиты, DDoS-защита — отсечь большой поток до сервера. Но эти инструменты не исправят ситуацию, если само API не проверяет, имеет ли пользователь право выполнить конкретное действие.
В статье собрали основные риски из рейтинга OWASP API Security Top 10, разобрали аутентификацию и авторизацию, SSRF и инъекции, атаки на бизнес-логику, работу с секретами, WAF, API Gateway, rate limiting и мониторинг. В конце — чек-лист, по которому можно пройтись по своему API и понять, где искать основные пробелы в защите. Если хотите пройти проверку целиком, читайте материал в блоге Рег.облака.
А мы продолжаем серию вебинаров про защиту Identity.
Завтра стартует наш следующий вебинар, при информационной поддержке партнера «Шексна‑Автоматизация»
2FA: on‑prem или облако — что выбрать?
На вебинаре разберем плюсы и минусы обоих вариантов.
2FA — уже не дополнительная защита, а базовый уровень безопасности
Компрометация пароля не должна автоматически означать компрометацию корпоративной учётной записи.
На вебинаре разберём, как внедрять двухфакторную аутентификацию в существующей инфраструктуре постепенно и без лишней нагрузки на сотрудников и ИТ.
Покажем, как это решается с помощью двух сценариев: on‑prem решения Avanpost MFA+ и SaaS Avanpost Identity Cloud.
Avanpost MFA+ полностью разворачивается в инфраструктуре компании и поддерживает интеграцию с корпоративными системами через RADIUS, SAML, OpenID Connect, LDAP, Credential Provider и другие механизмы.
Avanpost Identity Cloud — защищенный доступ к корпоративным ресурсам для сотрудников и подрядчиков, созданный на базе эталонной облачной архитектуры. Все секреты и чувствительные данные остаются в периметре заказчика.
В обоих случаях пользователи самостоятельно управляют своими аутентификаторами в личном кабинете, без обращения в техподдержку.
Продемонстрируем на тестовом стенде:
✅ Привязку аутентификатора в момент входа на рабочую станцию (on‑prem решение)
✅ Внедрение второго фактора для VPN (облачное решение)
Сделайте 2FA частью базовой кибергигиены без остановки рабочих процессов.
Когда: 1 октября в 11.00
Спикеры:
Светлана Лихоманова, Директор по развитию стандартизированных продуктов
Михаил Юров, Пресейл‑инженер, Отдел технической экспертизы
Представлен открытый проект proxy-scraper для выявления в сети открытых сервисов прокси, которые работают штатно и более менее безопасно.
«Большинство списков бесплатных прокси на 95% состоят из нерабочих адресов, а значительная часть оставшихся — это либо „ловушки“ (honeypots), либо прокси, внедряющие скрипты в загружаемые вами страницы. Инструмент proxy‑scraper собирает публичные прокси (HTTP, SOCKS4 и SOCKS5) из более чем 700 источников и сохраняет только те, что успешно проходят все проверки. При каждом запуске программа анализирует эффективность источников, а полученный результат может преобразовать в единый ротируемый прокси‑адрес. В цифрах: за одни сутки было проверено 3,6 миллиона бесплатных прокси — работоспособными оказались 1,1%, причём более половины из тех, что ответили на первый запрос, не прошли проверку повторным запросом», — пояснил создатель проекта.
Как защитить чувствительные данные при работе с LLM и почему закрытого контура недостаточно? Расскажем на GoCloud Tech 2026
При работе с LLM в запросы могут попасть персональные данные, API-ключи, реквизиты и другая чувствительная информация. При этом одного закрытого контура не всегда достаточно, чтобы исключить риски. На докладе разберем, как устроен Guardrails Filter: как инструмент обнаруживает чувствительные данные в запросах и ответах, маскирует их перед отправкой в модель и при необходимости восстанавливает в итоговом ответе. Еще сравним классические методы фильтрации с подходами на основе LLM и на реальных примерах покажем, чем продуктовая реализация отличается от open source версии.
Согласно исследованию Transluce, ИИ-агенты OpenAI пытались получить несанкционированный доступ к сайтам Министерства образования, Министерства торговли и Комиссии по ценным бумагам и биржам США (SEC).
В одном случае агент стремился попасть к данным Управления по гражданским правам при Минобразования. В другом — извлекал информацию с сайта Бюро переписи населения США.
OpenAI заявила, что произошедшее нельзя считать взломом. В компании назвали это инцидентами с «неожиданным и вызывающим беспокойство» поведением ИИ.
Чего только не сделаешь, чтобы удивить инвесторов.
Есть прекрасный жанр современных пресс-релизов по кибербезопасности: взять маленькую цифру, умножить ее на большую цифру и получить ощущение, что завтра искусственный интеллект самостоятельно зайдет в ваш дата-центр, сменит пароль root и потребует долю в компании (ну то есть, примерно так же, как и с пиаром про «ИИ-агентов», которые чего-то там «сами взломали»).
На этот раз поглядим на любопытную статистику The Hacker News по активности «ИИ» в корпоративных SOC: связанные с «ИИ» события составляют всего 0,43% всех инцидентов. При этом их доля действительно быстро растет — с февраля по июнь 2026 года она увеличилась на 685%.
Цифра 685% выглядит отлично для презентации (правда 95 из 100 таких инцидентов шум от легальной деятельности нейронок, которые по запросу его-то ищут), 0,43% — несколько хуже. Особенно если учесть, что это не доля успешных атак, а вообще все инциденты, где «ИИ» пробегал хотя бы кабанчиком, а конкретно предметно «ИИ»-атаки составили…0.02%, что уже совсем нелепо.
Производители «умной ИИ-защиты», которая сейчас самый модный тренд, имеют вполне понятный коммерческий стимул рассказывать историю немного иначе. То есть, кричать на всех углах, что защититься от «ИИ»-атак можно только подключив «ИИ»-защиту прямо сейчас, а то будет поздно!
Но это просто неправда. Ну разве что если вы попадете в те 0,02% атакованных «счастливчиков» и при этом у вас не окажется вообще никакой защиты (а в большинстве случаев на текущем этапе развития стандартной профессиональной защиты и соблюдения внутренних правил ИБ более чем достаточно, чтобы отбить любую «ИИ»-атаку).
Конечно 0,43% — это не ноль, и через год цифра вполне может быть существенно выше. Но между «категория быстро растет» и «эта категория уже является главной угрозой вашей инфраструктуре» лежит довольно большая пропасть. Которую маркетинг стремится перемахнуть одним прыжком, давя на эмоции и страх покупателя.
Вспомните об этом, когда в следующий раз прочитаете, что без подключения как можно скорее умной «ИИ»-защиты вас обязательно за пять секунд взломают умные «ИИ»-агенты.
Проблемы с MAXой - там возник канал «Фиксальной службы …. ». Приходит оповещение о возникновении задолженностей, подробности по ссылке, удостоверьте себя через Госуслуги... и переход туда, а там большое сообщение на экране "Вас взломали" и телефон, по которому активный сотрудник продолжит дурить дальше. Понятно, что «Все умные и все ВСЁ понимают», а самые-самые вообще этим продуктом не пользуются, но речь о последствиях. Итак – предположим, что есть пожилой родственник, который попался на это и что дальше?? Суматошные попытки заблокировать счета, карты, недвижимость, что-то узнать «по официальным каналам» - а вот там-то и ждёт засада! - по 112 послали в отделение полиции писать заявление и звонить в Госуслуги - в Госуслугах «ии» отвечает про что ему велено, но не про то, что необходимо и просьбы переключить на оператора/человека/«естественный интеллект» игнорирует…
Если время уже позднее, то даже найти информацию о центрах «Госуслуг/Моих документов», работающих после 20:00 оказывается затруднительным – таже «ии» требует что бы ей назвали адрес центра, и тогда она расскажет о его режиме работы… тыкать во все отметки этих центров на карте, что бы узнать режим работы – то ещё развлечение…, а вот Алиса с этой задачей справилась быстро… Но предположим, что «потерпевший» живёт в небольшом городке или его окрестностях, где центр «Госуслуг» закрывшись в четверг, начнёт работать только во вторник?
Можно сколько угодно вещать о необходимости развивать «суверенную имитацию интеллекта» и «суверенную МАХу», но если не защищать граждан от недостатка информации, то для «злоумышленников» будут всегда широко открыты двери для любых воздействий на граждан страны.
Мои попытки продвинуть создание «информационного пространства» для качественной, нужной, доверенной информации утыкаются в непонимание – «А зачем? Если будет вопрос, на него ответит «искусственный интеллект» …
Если вспомнить сколько нервов было испорчено после укуса клеща пару лет назад и невозможностью получить однозначную достоверную информацию…
И если предположить, что в подобные ситуации попадает большое количество не только просто «граждан», но и некоторые близкие люди – то может стоит отнестись к проблеме серьёзно??
Они сошлись. Волна и камень, Стихи и проза, лед и пламень Не столь различны меж собой. Сперва взаимной разнотой Они друг другу были скучны; Потом понравились; потом Съезжались каждый день верхом И скоро стали неразлучны.Т ак люди (первый каюсь я) От делать нечего друзья.
Классика на то и классика, что актуальна во все времена. Еще пару веков назад уважаемый Александр Сергеевич в рамках «Евгения Онегина» дополнительно раскрыл проблематику единства и борьбы противоположностей, и, как оказалась, ее с легкостью можно проецировать на информационную безопасность.
Сегодня поговорим про взаимодействие красных и синих команд через призму баг баунти.
Около месяца назад я и мои коллеги t.me/drmefisto_re и t.me/re59_channel были приглашены в закрытую программу тестирования PoS‑терминалов одного банка. Сказать, что мы были преисполнены энтузиазмом значит ничего не сказать, особенно когда увидели суммы выплат, равные первоначальному взносу за ипотеку.
И начиналось все достаточно прекрасно: нас пригласили в офис, выдали заветные «железки» и предоставили полный карт‑бланш на тестирование: «хоть сожгите, только серийник оставьте, чтобы нам отчитаться перед бухгалтерией».
С учетом соревновательного эффекта, Володя в тот же день получил рута и убрал вотермарк «алярма», что устройство взломано, а мы начали поздравлять его с будущим новосельем. Нам же с Денисом потребовалось несколько дней, чтобы мы вышли из киоска, нашли несколько паролей в плейнтексте и активировали функцию записи экрана. В общем отчеты отправлены, теперь томительное ожидание триажа, подтверждения и выплаты.
Однако, через неделю оказалось, что терминалы (сама аппаратка) одинаковые, а вот наполнение было разным: версии ПО у всех разные (не последняя ревизия); где‑то установлены еСим‑ки, где‑то нет; а в некоторых устройствах вообще был включен режим дебага (что значительно облегчает исследование). Складывалось впечатление, что вендор или плохо подготовился к программе, или наивно рассчитывал на безупречность своего продукта.
В итоге, наши с Денисом отчеты признали средней критичности, а запись экрана — вообще дубликатом от выхода из режима киоска (на что мы подали апелляцию). А рут Владимира, что самое смешное, признали не валидным, так как эта уязвимость является публичной и вендор ее уже исправляет (правда в условиях программы об этом не сказано ни слова). Но не смотря на это, мы свои 300+ получили ;)
В общем, to be continued, как говорится и вендетта неизбежна.
Для бывалых данные «обстоятельства» (если это можно так назвать) являются уже рутиной. Но для молодых специалистов, желающих применить свои знания на практике и немного заработать, это может стать существенным демотиватором.
А у вас уже есть аналогичный опыт взаимодействия? Поделитесь в комментариях, как вы справляетесь с противодействием другой команды.
🧠 Обязательно поделись с теми, кому это может быть полезно 💬 Телеграм | 💬 Max | 📝 Хабр | 💙 ВКонтакте
