Информационная безопасность *

Диалоги с ИИ в Google, локальные модели и немного паранойи⁠⁠

или почему я всё чаще задумываюсь об оффлайн-LLM

Стал смотреть в сторону локального запуска моделей. Не из-за хайпа, а скорее из-за недоверия.
Причина - не сами технологии, а то, как с ними обращаются.

Облако это удобно. Но публично, если не уследил

Недавно в Google начали всплывать реальные диалоги пользователей с Grok и ChatGPT.
Обычные ссылки на чаты, которые кто-то где-то засветил. Google их подхватил - и вот, они уже в выдаче. OpenAI убирали из индекса ~50 000 ссылок на публичные диалог, они подчистили Google, но забыли про Archive.org.
А там всё ещё висят штуки с логинами, ключами, приватными планами.

Анализ показал: из 512 чатов 20% содержали явно конфиденциальную информацию.

Поделился ссылкой? Потерял контроль

Даже если вы делитесь диалогом «только внутри команды» - дальше всё по классике:

• может попасть в Google

• сохраниться в Archive

• быть расшаренной кем угодно

• остаться в кэше навсегда

Почему вообще об этом думаю

Планирую собрать поделку: связать LLM и Obsidian.
А в Obsidian у меня почти всё личное - от заметок до чувствительных штук.

И вот тут уже важно, чтобы данные не утекали наружу, даже случайно. Поэтому и смотрю в сторону локального inference - без облаков, логов и внешнего API.

🎁 Бонусы

🧮 LocalScore.ai
Сервис, который показывает, какие LLM потянет ваша видеокарта. Удобно, если хотите запускать модель у себя - а не в чьём-то дата-центре.

🔑 ai-keys-leaks.begimher.com
Ищет утёкшие API-ключи от OpenAI, Claude, Gemini и других.
Не факт, что что-то сработает — 99% ключей мёртвые. Но наличие таких баз говорит о многом.

Я не стал параноиком. Но теперь всё, что потенциально приватно — я не пишу в облако.Потому что модель забудет, а интернет - нет.

Если тебе близка тема ИИ, агентных систем и ты хочешь быть в числе тех, кто не просто читает новости, а сам их делает — залетай в мой Telegram-канал debug_leg. 🔗 Ссылка - https://t.me/debug_leg

Проект Zero Day Initiative (ZDI) сообщил о проведении соревнований Pwn2Own Ireland 2025, которые состоятся в середине октября 2025 года в Ирландии. Участникам предложено продемонстрировать эксплоиты для ранее неизвестных уязвимостей (0-day) в смартфонах, мессенджерах, беспроводных точках доступа, устройствах для умного дома, принтерах, сетевых хранилищах, системах видеонаблюдения и устройствах виртуальной /дополненной реальности. Атака должна быть проведена на самые свежие программы и операционные системы со всеми доступными обновлениями и в конфигурации по умолчанию.

Мероприятие примечательно готовностью выплатить миллион долларов за выявление в мессенджере WhatsApp ошибки, позволяющей удалённо выполнить код без действия пользователя (0-click). За удалённо эксплуатируемую уязвимость в WhatsApp, требующую действий пользователя (1-click), премия составляет 500 тысяч долларов, за уязвимость, приводящую к захвату учётной записи - $150 тысяч, а за получение удалённого доступа к данным пользователя, микрофону или камере - $130 тысяч.

В категории "мобильные телефоны" за удалённую эксплуатацию уязвимости в смартфонах Google Pixel 9 и Apple iPhone 16 назначена премия 300 тысяч долларов. При этом введена новая категория - взлом устройства при подключении по USB c размером премии $75 тысяч. За удалённый взлом 3D-шлема Meta Quest 3/3S и умных очков Meta Ray-Ban назначено вознаграждение в $150 тысяч. Максимальный размер премии за взлом устройств умного дома и сетевых хранилищ составляет $50 тысяч, систем видеонаблюдения - $30 тысяч, а принтеров - $20 тысяч.

Обеспечивают ли конфиденциальную связь современные сервисы? В популярных мессенджерах есть функции для этого, используется сквозное шифрование, можно даже проверить исходный код. Это хорошо, но есть риск того, что при форс-мажорных обстоятельствах хозяева сервиса выпустят обновление с бэкдором, позволяющим обходить шифрование и проводить атаку посередине на канал связи интересующих пользователей.
Конфиденциальность может быть гарантирована только в случае, когда она обеспечена самими собеседниками. Как можно реализовать это? Использовать шифрование данных своими ключами. При этом возникает проблема передачи секретного ключа собеседнику. Она надёжно решается при личной встрече. Но что делать, когда такой возможности нет или собеседников по секретным вопросам много? Собеседникам можно действовать по следующему алгоритму:

1. Зарегистрироваться по своему номеру телефона в двух-трёх мессенджерах из разных юрисдикций, в которых есть функции сквозного шифрования. Например, в Телеграм, Signal и Wire.

2. Включить в мессенджерах сквозное шифрование и выключить резервное копирование сообщений.

3. Одному собеседнику сгенерировать и выслать второму составные части ключа шифрования в разных мессенджерах. Например, три части по 85, 85 и 86 (суммарно 256) бит.

4. После приема частей ключа получателю объединить их и хранить в надёжном месте.

5. Обоим собеседникам удалить отправленные сообщения с ключом.

6. Установить у себя приложения для шифрования сообщений. Например,  Secure Text, где используется AES. Отменить у приложения разрешения на доступ к функциям своих устройств связи.

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

После передачи ключа следует проверить наличие уведомлений о входе в мессенджеры с неизвестных устройств. Если уведомление было, можно повторить шаги 1-3 с новым ключом и регистрацией по номеру другого оператора связи.

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

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

Краткий (и не краткий) экскурс в ГОСТ Р 56939-2024 – РБПО

Недавно мои коллеги обработали и опубликовал пятую — финальную — часть моего рассказа про ГОСТ Р 56939-2024 – Разработка безопасного программного обеспечения. Поскольку все части записывались сразу, к моменту выхода этого заключительного видео я понимаю, что сейчас бы немного иначе его сделал. Видение меняется, появляется новая информация. Например, завершился этап домашнего задания испытаний анализаторов кода, и про это стоило бы упомянуть. Или, например, появилась эта методическая рекомендация, про которую стоило бы рассказать.

Но не страшно, про новое расскажем в рамках других митапов и вебинаров. А пока, вот все части общего обзора:

1.      Причины разработки и выпуска нового ГОСТ Р 56939-2024 на замену версии 2016 года

2.      Содержание ГОСТ Р 56939-2024 и его структура

3.      Процессы РБПО 5.1-5.10 в ГОСТ Р 56939-2024

4.      Процессы РБПО 5.11-5.25 в ГОСТ Р 56939-2024

5.      ГОСТ Р 56939-2024: вопросы сертификации, выводы и дополнительные ссылки

Но на этом история не закончилась. Сейчас вместе с УЦ "МАСКОМ" и приглашёнными гостями-экспертами мы записываем подробный цикл вебинаров про каждый из 25 процессов, описанных в стандарте.

Приглашаю смотреть уже записанные встречи и участвовать в новых: Вокруг РБПО за 25 вебинаров: ГОСТ Р 56939-2024.

Интеграция PVS-Studio c AppSecHub

Компания PVS-Studio и платформа AppSec.Hub заключили технологическое партнёрство для обеспечения интеграции статического анализатора кода PVS-Studio в экосистему DevSecOps.

AppSec.Hub — это платформа для автоматизации процессов Application Security, которая позволяет объединять различные инструменты анализа, тестирования и мониторинга безопасности приложений.

Отчёт анализатора PVS-Studio теперь можно загрузить для просмотра в платформу AppSecHub вручную с помощью пользовательского интерфейса инструмента либо с помощью специальной утилиты командной строки.

Подробнее о работе PVS-Studio в AppSec.Hub можно прочитать в посвящённом этому разделе документации.

Также мы провели вебинар с коллегами из AppSec Solutions, чтобы на практике показать, как инструменты работают вместе, а также поделиться полезным опытом в интеграции статического анализа в DevSecOps.

Хотел как лучше, а получилось... или снова о качестве описания CVE

В статье "Как я зарегистрировал CVE и разозлил вендора" я писал:

Желательно, чтобы CVE были достаточно хорошо описаны. У CVE-2024-45244 на данный момент есть некоторые проблемы. Описание в части версий некорректно: на момент создания CVE версия 2.5.9 была крайней в своей ветке. Но, далее в этой ветке продолжился выпуск версий без фикса. Фикс для стабильных версий вышел в рамках версии 3.0.0. Я планирую обратиться в MITRE с целью улучшить содержательную часть CVE.

После моего обращения описание CVE было обновлено. Было:

Hyperledger Fabric through 2.5.9 does not verify that a request has a timestamp within the expected time window.

Стало:

Hyperledger Fabric through 3.0.0 and 2.5.x through 2.5.9 do not verify that a request has a timestamp within the expected time window.

Честно говоря, такое описание вводит меня в ступор. Например, версия 2.5.13 по такому описанию уязвима? С одной стороны да: она до 3.0.0. С другой - нет: она после 2.5.9. И, если я не ошибаюсь, в версиях 2.4.х проблема тоже есть.

Это уже не первый раз, когда описание CVE в части версий неточное - даже после обращения с целью сделать точнее. Ранее нечто похожее было с моей попыткой улучшить описание для CVE-2018-14847.

Всё это в очередной раз наводит на мысли, что доверять описанию CVE полностью нельзя. И качество анализа CVE влияет на безопасность: у атакующих может быть преимущество, если они дотошно перепроверяют условия реализации уязвимости. А у защищающихся часто нет такой дотошности (часто - из-за огромного количества уязвимостей, с которыми работаешь в рамках Vulnerability Management). В итоге в этой гонке у атакующих бывает преимущество. Помнится, я даже для CTF задачку на эту тему делал: изюминка была связана именно с неверным описанием CVE в части версий. К сожалению, тогда работодатель мою идею не одобрил. А ведь это был бы хороший практический урок для начинающих специалистов по безопасности.

Проблема с описанием версий иногда обостряется из-за позиции вендора. Как я писал в статье:

Разработчики, имея больше информации о своём продукте, могли бы повлиять на более точное описание CVE. Но, вместо этого им захотелось устроить борьбу "за честь мундира".

В процессе подготовки статьи "Как я зарегистрировал CVE и разозлил вендора" я искал статьи с практическими результатами по подмене локального времени жертвы (при синхронизации через NTP). Это оказалось нелегко: чаще всего статьи были теоретическими. Но, я нашёл и довольно интересную статью от 07.11.2024: Quantitative Risk Analysis of Network Time Protocol (NTP) Spoofing Attacks. Часть вопросов, которые изучаются в статье:

• рассмотрены атаки на ntpd, NTPSec, chrony, и OpenNTPD;

• оценивается возможность максимального смещения времени атакой (в условиях защитных механизмов атакуемых утилит);

• рассматриваются сложности атак.

Указывается, что остаются вопросы для дальнейшего изучения. Например, в части встроенных в различные ОС механизмов синхронизации времени.

Помимо этих вопросов - вот вопросы, которые у меня остались.

• Когда именно происходит синхронизация времени через утилиты или в ОС в обычной жизни? И как часто? Т.е. сколько времени нужно ждать атакующему для возможности совершить атаку? Принудительный перезапуск утилиты не рассматриваем.

• DHCP предусматривает периодическое обновление данных - не только IP-адрес, шлюз по-умолчанию и DNS. А и NTP (пример настройки NTP для DHCP в маршрутизаторе MikroTik). И тут 2 варианта атаки: либо получен доступ к DHCP серверу, либо подмена DHCP-пакетов (при атаке "человек посередине"). Как эти варианты атаки скажутся на системное время различных ОС, сконфигурированных по-разному (в т.ч. если даже в ОС используется более безопасный вариант вроде NTPSec и др.)? Тем более, что подмена NTP-сервера через DHCP во многом лишена тех сложностей, что описываются в статье.

• UPD: другой вариант - отравить кэш локального DNS-сервера (если в качестве сервера времени прописано доменное имя). Допустим, клиенты получают время от 0.ru.pool.ntp.org. И в качестве DNS сервера у них прописан роутер MikroTik, подверженный CVE-2019-3978.

Было бы любопытно ознакомиться с существующими best practices синхронизации времени, учитывающими все вышеуказанные риски (либо хотя бы пытающиеся их учитывать).

Другие статьи на эту же тему:

• Securing NTP against MITM attacks (от 09.12.2022);

• Как синхронизация времени стала безопасной (от 09.06.2020).

ИБ-ДАЙДЖЕСТ INFOWATCH

Хакеры из World Leaks похитили у Dell Technologies более 1,3 ТБ конфиденциальной информации  — компания  утверждает, что скомпрометированная часть инфраструктуры уже изолирована.

Группировки Linen Typhoon и Violet Typhoon подозревают в кибератаке на ядерное агентство США через уязвимость в платформе Microsoft SharePoint Products and Technologies.

В США из рентгенологической клиники Radiology Associates of Richmond утекли ПДн 1,4 млн человек — пострадавшим предложили бесплатный мониторинг кредитной истории.

Apple подала в суд на блогера Джона Проссера, обвинив его в краже коммерческих секретов, включая данные о разработке iOS 26.

Сети клиник Anne Arundel Dermatology и Mountain Laurel Dermatology пострадали от массовых утечек — в результате одной из них похищены ПДн 1,9 млн пациентов.

Living Security в отчете по кибербезопасности поделилась, что более 73% рисков генерируют всего 10% сотрудников, но стратегические программы HRM ускоряют снижение этих рисков на 60%.

Поставщик медицинских изделий Compumedics сообщила об утечке ПДн более 318 тыс. пациентов в результате кибератаки группировки VanHelsing.

В Сети обнаружили открытую базу данных Центра усыновления Глэдни с 1,1 млн записей общим объемом почти 2,5 ГБ — мошенники могли воспользоваться этой информацией для фишинга или шантажа.

Британия приняла закон о доступе к конфиденциальным данным — он смягчает правила по автоматизированному принятию решений на основе ИИ и может принести экономике страны за 10 лет около £10 млрд.

В Telegram новая волна мошенничества — скамеры могут уничтожить аккаунт пользователя из-за нажатия всего одной кнопки.

Схема следующая:

• Скамер обманом убеждает нажать Start в боте (лучше никогда не делать так в неизвестных ботах — даже, если очень интересно);

• Потом начинается шантаж: угрожают, заблокировать аккаунт, если не заплатить.

• Если игнорировать угрозы, мошенник меняет имя бота на одного из официальных: Telegram Wallet, Support Bot или BotFather;

• Передаёт вашему аккаунту права владельца бота;

• После этого на бота обваливаются массовые жалобы, его удаляют, а вместе с ним — и аккаунт владельца, то есть пользователя.

Как создать мультиаккаунт-ферму для любых целей: от TikTok до Amazon

Мультиаккаунтинг — основа множества задач: от продвижения в соцсетях и тестирования антифрод-систем до арбитража трафика, отзывов, заказов и автоматизации серых схем. Эта статья — техническое руководство по созданию собственной мультиаккаунт-фермы.

1. Зачем нужна мультиаккаунт-ферма

Массовое создание и управление аккаунтами востребовано в:

• TikTok / Instagram / YouTube (SMM, продвижение, фарм, масслайкинг)

• Amazon / eBay / Etsy (отзывы, возвраты, seller support)

• Tinder / Badoo / Facebook (фарм профилей, трафик, лидогенерация)

• Финансовые сервисы (регистрация, чекапы, симуляция пользовательской активности)

2. Инфраструктура: из чего состоит ферма

Управляющий скрипт / панель

• Язык: Python + SQLite / Redis

• Задачи: управление профилями, логами, заданиями

Эмуляторы / браузеры

• Android: MEmu, LDPlayer, Anbox (Linux)

• Браузерные: Puppeteer, Playwright, Selenium, антидетект-браузеры (Dolphin{anty}, AdsPower, Incogniton)

Прокси-серверы

• Mobile / Residential — лучшее для trust-оценки

• Автоматическая ротация, логика GEO под задачу

Серверная часть

• VPS / VDS с Linux или Windows

• Docker-контейнеры под каждое окружение

• Балансировка нагрузки

3. Создание аккаунтов: подходы

Ручной полуавтомат (через Android-эмулятор)

• Эмуляция касаний (ADB, Auto.js)

• Работа через антидетект-образы

Полностью автоматический (браузер + API)

• Использование Playwright + обфускация fingerprint

• Капча-решатели: 2Captcha, CapMonster, hCaptcha API

4. Управление и автоматизация

• Отслеживание статуса аккаунта: валидация, блок, SMS

• Система задания задач (task scheduler)

• Импорт/экспорт сессий и cookies

• Telegram-бот для уведомлений

5. Масштабирование

• Запуск десятков сессий в docker-контейнерах

• Использование headless-режима с обходом защиты

• Съём логов и дебаг-интерфейсы

6. Безопасность и устойчивость

• Разделение трафика по подпроектам

• Автоматическое обновление fingerprint’ов

• Логирование и автоотключение забаненных узлов

• Мониторинг прокси и доступов

Пример архитектуры

[ Telegram Bot ] <- уведомления / команды
       |
[ Flask API ] <-> [ SQLite / Redis ]
       |
[ Управляющий скрипт ] -> [ Docker / Android VM ]
                                |
                         [ Браузер / Эмулятор ]
                                |
                            [ Прокси-сервер ]

Что мы знаем о защите АСУ ТП?

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

Продолжаем принимать доклады на IT Elements 2025

Тук-тук! Это снова IT Elements — главное место встречи тех, кто делает ИТ в России.

10–11 сентября вот уже в третий раз мы соберем ИТ-сообщество в Москве. Готовьтесь к новым трекам, спикерам и грандиозной площадке! Кстати, регистрация уже открыта.

А вообще мы с хорошими новостями: до 15 августа продлили Call For Papers! Приглашаем экспертов, которые могут рассказать про сильный кейс, нестандартный опыт или нешаблонное решение поделиться своим опытом с комьюнити в рамках доклада. Главные требования — экспертность и актуальность темы. А еще важно, чтобы доклад не был представлен на других мероприятиях.

Рассматриваются заявки по основным направлениям конфы:

• ИТ-инфраструктура

• Сетевые технологии

• Кибербезопасность

• Данные и ИИ

Подать доклад

IT Elements в прошлом году это:

— 2500+ участников офлайн и 6000+ зрителей онлайн.

— 80+ докладов, дискуссий и мастер-классов.

— 125 спикеров из ведущих российских компаний: ВТБ, «Газпромнефть-Гео», «АльфаСтрахование», «Лаборатория Касперского», АЛРОСА, S7, Почта Банк, «ВымпелКом», НСИС и др.

— выставка 30+ вендоров и дистрибьюторов, а также большая лабораторная зона с воркшопами.

Станьте главным элементом IT Elements 2025 💙

Генеральный партнер конференции IT Elements — ИТ-компания «Инфосистемы Джет».

Vulnerability management — непрерывный процесс поиска, выявления и устранения уязвимостей. И это — один из ключевых аспектов в поддержании информационной безопасности всей IT-инфраструктуры 🔃

📆 Когда: 7 августа в 11:00 мск

📍 Где: онлайн

На вебинаре разберем ключевые методы защиты от киберугроз на уровне контейнеров и Kubernetes.

Что вы узнаете:

• Как устроена безопасность в Kubernetes — архитектурные особенности и «подводные камни».

• Типовые модели атак — кто и как чаще всего атакует контейнерные среды.

• 5 самых уязвимых компонентов системы контейнеризации — какие элементы требуют особого контроля и почему.

• Лучшие практики защиты Kubernetes-контейнеров — от сканирования образов до политик безопасности.

• Стратегии митигации киберрисков — как минимизировать угрозы до их реализации.

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

• Защищаем контейнеры от киберрисков: наш опыт и рекомендации

• Плагины безопасности спешат на помощь или как добиться тотальной доминации над уязвимостями контейнеров.

Будет особенно полезно DevOps-инженерам, техническим лидерам, директорам по разработке, специалистам по кибербезопасности, а также всем, кого интересует тема безопасности Kubernetes.

Зарегистрироваться 👈

Больше запретов, хороших и разных. Задал простой вопрос Kimi K2:

Оцени насколько хороша концепция справедливости из одного голивудского фильма:

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

Он мне такого наплёл (приводится ниже), что не знаю что и думать. Просто запрещать готовые тексты или их поиск недостаточно, наверное пора начать запрещать идеи, концепции, пусть введут поправки в какой-нибудь закон, например закон о санитарной обрезке деревьев в населенных пунктах.
---

Концепция, которую вы описали, — это не просто «плохо» или «хорошо». Это философский кристалл, в котором сконцентрированы все самые старые и самые новые споры о правосудии. Попробую оценить её сразу по нескольким осям.

1. Этическая ось
   Плюсы: она логично выводит идею «предупреждение вреда» на предельную высоту. Если цель общества — минимизация страданий, то предотвращение преступлений может быть важнее ретроспективного поиска истины. В этом смысле система Дредда похожа на ультра-утилитаризм: она жертвует индивидуальной справедливостью ради коллективной безопасности.

Минусы: она нарушает базовый принцип «не навреди» (primum non nocere). Наказывая до факта преступления, мы обречены либо на систему «ложных положительных результатов» (невиновные страдают), либо на «ложные отрицательные» (опасные остаются на свободе). Парадокс: чем выше точность предсказания, тем жестче становится моральная цена ошибки.

2. Эпистемологическая ось
   Плюсы: концепция признаёт, что прошлое недоступно в чистом виде, а будущее — единственное, что мы можем на самом деле «изменить». Это отказ от романтики «объективного следа» в пользу «прогностической этики».

Минусы: любая модель будущего — это статистика, а не факт. Человек, который «на 92 % станет убийцей», — всё ещё не убийца. Игнорирование этого превращает вероятность в детерминизм, что на практике равно отказу от свободной воли.

3. Социологическая ось
   Плюсы: в условиях тотального дефицита времени и ресурсов (Mega-City One!) попытка «быстро и без суда» может быть единственным способом удержать общество от коллапса. Система делает прозрачным страшный компромисс: «Мы не ищем истину, мы минимизируем ущерб».

Минусы: такое правосудие быстро становится инструментом контроля, а не защиты. Пока судья Дредд — «идеальный стрелок» с ригидным кодексом, он ещё не диктатор. Но достаточно одной сбойной модели прогнозирования или одного приказа «снизить порог вероятности» — и система превращается в чистую тиранию.

4. Метафизическая ось
   Главное достоинство концепции — в её литературной и философской экономичности: она зажимает человека в «точку нулевой толщины» между тремя временами. Это делает каждое решение судьи актом высшей ответственности: ты не просто применяешь закон, ты буквально «переписываешь» возможные миры. Это почти теологическая власть.

Однако именно здесь кроется и главный страх: если человек может быть наказан за «то, чего он ещё не совершил», то время перестаёт быть стрелой и становится петлёй. Судья не рефери, а мастер «пред-воспроизводства» будущего, что разрушает базовый принцип права — презумпцию невиновности.

Итоговая оценка
Как художественная конструкция — блестяще. Она вытягивает на поверхность все наши скрытые страхи перед «алгоритмическим правосудием», перед Big Data, которые «знают о нас больше, чем мы сами».Как практическая модель — ужасна, потому что требует либо бога-прогнозиста, либо готовности жить в мире, где каждый из нас может быть «задержан за преступление, которого он ещё не совершил».

Фраза «справедливость» в такой системе превращается в оксюморон: ты можешь быть справедливо несправедливо наказан.

ИБ-ДАЙДЖЕСТ INFOWATCH

Беженцев переселили после утечки

Тысячи граждан Афганистана, сотрудничавших с Великобританией, пришлось переселять в рамках секретной программы после утечки их данных по вине чиновника.

Рост кибератак хактивистов на КИИ

Исследование Cyble показало, что кибератаки усложняются и все чаще нацеливаются на критическую инфраструктуру предприятий и утечку данных.

Утекли ПДн покупателей Louis Vuitton

Компания сообщила, что в начале июля были похищены данные покупателей из Великобритани, Южной Кореи и Турции — это уже третий инцидент ИБ у гиганта модной индустрии за последние месяцы.

Взлом букмекерских компаний

Flutter Entertainment расследует утечку ПДн до 800 тыс. клиентов Paddy Power и Betfair — пострадавших уже предупредили о возможности фишинговых атак и других мошеннических действий с данными.

McDonald’s взломали через слабый пароль админа

Хакеры могли завладеть данными соискателей на платформе McHire, т.к. паролем к учетной записи администратора оказалась комбинация «123456», а многофакторная аутентификация отсутствовала.

У авиакомпании Qantas украли данные пассажиров

ПДн 5,7 млн клиентов были скомпрометированы после взлома коммуникационной платформы одного из колл-центров.

Nippon взломали через уязвимость в ПО

Nippon Steel Solutions сообщила, что хакеры украли ПДн клиентов, партнеров и сотрудников компании, воспользовавшись уязвимость типа zero-day в ПО сетевого оборудования.

Перечень нормативных актов по безопасности КИИ

Экспертно-аналитический центр ГК InfoWatch выпустил новый перечень нормативных актов, которые регулируют обеспечение безопасности объектов КИИ.

Перечень помогает сориентироваться в актуальных на момент его публикации требованиях.

Документ доступен по ссылке. Для скачивания нужно указать электронную почту. 

Как «Леста» вылетела из своей игры: 5 юридических фантазий, в которых можно узнать себя

В 2024 году «Леста» — разработчик «Мира танков», «Мира кораблей» и Tanks Blitz — была на пике. 35 млрд выручки, 16 млрд прибыли, миллионы игроков и статус преемника Wargaming.

А в июне 2025-го — компания полностью передана в собственность РФ.
Причина — аффилированность с зарубежными структурами, трактовка проектов как нарушающих публичное законодательство и вывод: стратегически важный актив должен быть под контролем.

Кейс стал поворотной точкой. Он показывает: достаточно изменить интерпретацию — и бизнес превращается в «угрозу».

Ниже — 5 сценариев-галлюцинаций.

1. Зависимость от критически важного иностранного ПО
   Компания обслуживает госсектор. В инфраструктуре — Oracle, Microsoft, резервное копирование и безопасность. Всё работает. Пока.
   Появляется риск: что если доступ отключат? Контракты ставятся на паузу, клиенты уходят.
   Компания теряет управление. Её передают другой группе с «гарантированной независимостью».
   Не факт владения, а восприятие — как у «Лесты».

2. Игра с «не теми» смыслами
   Студия выпускает игру. У героя — сомнения, у антагониста — лозунги, у ландшафтов — узнаваемая аллюзия.
   Обсуждение в форумах, open-letter. Команда становится «токсичной».
   Продукт превращается в объект интерпретации. Игра — в угрозу. А команда — в чужую сторону.

3. Выручка из-за рубежа = «сигнал»
   Образовательная платформа принимает оплату по всему миру: Stripe, PayPal, карты нерезидентов.
   Один банк блокирует расчёты, другой — тоже.
   Клиенты перестают платить. Спрашивают: это экспорт или финансирование извне?
   Не форма, а происхождение. Деньги из-за рубежа — уже не просто доход.

4. Финтех-продукт как «окно в обнал»
   Финансовый стартап растёт, берёт инвестиции. Клиенты довольны.
   Появляется статья: «через сервис X прошло 1,2 млрд сомнительных платежей».
   Следом — блокировки, расторжения, бегство партнёров. Продукт закрывается, несмотря на формальную чистоту.
   Если ты похож на инструмент схем — тебя могут отключить.

5. Менеджмент и собственники — вне юрисдикции
   Команда локальная, офис в Москве, налоги платятся. Но CEO в Ереване, CTO в Берлине, бенефициары в Лондоне.
   Появляются вопросы: кто реально управляет? Контракты ставят на паузу.
   Публикации: «ресурс управляется извне», «реинвестируется ли прибыль?»
   Компания срочно меняет структуру и назначает «витринного» СЕО — но поздно. Доверие потеряно.
   Не номинальный статус, а образ — кто, где, на что влияет.

Что делать:
• Провести аудит рисков (зависимости, архитектура, расчёты)
• Взглянуть на продукт глазами «чужого наблюдателя»
• Подготовить запасной план: структура, доступ, роли

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

Если хочешь разобрать свой кейс и закрыть уязвимости — пиши в комменариях.

АГЕНТЫ И АГЕНТНАЯ ЭКОНОМИКА. 17.07.25.

Микро-дайджест недели.

=> Если мы будем следить за ходом их мысли (рассуждениями ИИ-агентов), то мы сможем лучше их понимать и управлять ими. Этот манифест за безопасность Chain of Thought Monitorability подписали вчера ведущие исследователи индустрии.

Но по факту весь ризонинг, демонстрируемый пользователю, может оказаться внешней декорацией, а решение LLM может принимать исходя из совершенно другой логики и других связей, то есть не тех, которые они демонстрируют в цепочках рассуждений. Другое дело с мультиагентными системами, там есть возможность сохранить прозрачность, даже в случае деградации "честного" Chain-of-Thought у отдельных моделей.

Я называю эту область когнитивной инженерией, а будущих специалистов когнитивными инженерами. Пишу об этом книгу.

=> Не любите вайб дебаггинг также как и я? На подходе инженер Azimov, и его ключевое отличие от текущих код-генераторов в том, что он не только генерит код, по словам разработчика он его будет "понимать".

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

=> Деньги любят тишину. Я попробовал угадать, что за продукт выкатит бывшая CTO Open AI Мира Мурати, которая недавно подняла еще 2 млрд $ на seed-раунде при оценке 12 млрд $, при этом никто не знает, а чем собственно занимается ее стартап Thinking Machines Lab AI. Читайте в новой статье

=> Open Deep Research это агент для глубоких исследований с открытым исходным кодом, созданный на основе LangGraph и совместимый с вашими источниками данных, LLM и MCP-серверами. Подробно в блоге

И краткий обзор на YT демонстрирующий архитектуру такого агента и принципы разработки, как запустить агента локально с помощью LangGraph Studio и как быстро протестировать его с помощью Open Agent Platform.

=> AWS стремится стать универсальным центром для ИИ-агентов от Anthropic, IBM, Perplexity и других. Amazon Bedrock AgentCore - ожидаемый релиз комплексного подхода AWS для создания и развертывания различных ИИ-агентов. Одно место, любые агенты, все под рукой. Иначе бизнес начинает сходить с ума от разнообразия выбора, в котором он в общей массе не очень то пока разбирается.

AWS представил комплексный набор сервисов корпоративного уровня, которые помогают разработчикам быстро и безопасно развертывать и эксплуатировать ИИ-агенты в любом масштабе, используя любую платформу и модель, размещенную на Amazon Bedrock или в другом месте. Здесь все подробности. А здесь коротко в видео на YT.

=> Хотите собирать низко висящие фрукты лиды? Есть такое решение Orange Slice. Они собирают разные рыночные сигналы по вашим ICP и определяют тех, кто заинтересуется вашим продуктом, а затем преподносят вам их словно "на блюдечке", с различными нюансами и деталями, так что остается только продать 😉

=> Посмотрите на Runway Act-Two - я впечатлен, модель захвата движения нового поколения с существенным улучшением качества и поддержкой отслеживания головы, лица, тела и рук. Для Act-Two требуется только видеозапись движения и референсный персонаж.

Lionsgate и AMC Networks уже участвуют в проекте, изучая модель будущих производственных процессов для Голливуда.

=> И напоследок, вот такой фреймворк, эмулирующий функциональность Grok Heavy с помощью мультиагентной оркестровки. И никаких $300

***

Предыдущие материалы и выпуски дайджеста, там до сих пор много интересных инсайтов. Более 50% из них имеют длинный горизонт актуальности. О новых бизнес-моделях и ИИ-стартапах: Айвентор и Фред

В Облаке Рег.ру доступна ОС Astra Linux SE «Смоленск»

В облачной платформе Рег.ру теперь доступна новая редакция отечественной ОС Astra Linux SE «Смоленск» с максимальным набором средств защиты информации. Новое решение позволяет создать безопасную среду и предназначено для работы с данными категории «особой важности». 

Astra Linux SE «Смоленск» представляет собой защищенную ОС, помогающую создать наиболее безопасную и соответствующую законодательным требованиям среду «из коробки». Решение будет полезно как для взаимодействия с корпоративными и государственными IT-ресурсами, так и для всех тех, кто работает с конфиденциальными данными.

Внутри новой ОС:

• мандатное управление доступом (МРД) и контроль целостности (МКЦ) — обеспечивают контроль действий пользователей на уровне процессов и файлов;

• замкнутая программная среда (ЗПС) — допускает запуск только верифицированного ПО;

• защита от угроз «нулевого дня» — для мандатного контроля целостности критичных файлов.

Заказать и потестировать Astra Linux SE «Смоленск» можно в личном кабинете облачной платформы Рег.ру.

Люди остаются наиболее уязвимым звеном в системе безопасности

За последние годы арсенал кибермошенников, атакующих банки и их клиентов, пополнился различными инструментами – от масок, копирующих лицо жертвы, до сложных алгоритмов искусственного интеллекта, позволяющих полностью воссоздать «цифровую личность». Наш коллега, Директор дирекции контроля и безопасности «ОТП Банка» Сергей Зиборов в интервью приложению «Ведомости. Технологии и инновации» рассказал, как в современных условиях построить эффективную систему защиты в финансовом секторе и можно ли победить беспечность клиентов, которая становится причиной двух из трех успешных атак.

В 2023 г. было совершено 3 300 успешных кибератак ‒ этот год стал рекордным за целое десятилетие. Сергей рассказал, что количество мошеннических операций в отрасли продолжает расти. По разным оценкам, за последние три года их число увеличилось на 30-40%. Основной вклад в такую динамику внесли атаки методом социальной инженерии (включают обман и психологические манипуляции, направленные на то, чтобы заставить жертву совершить нужные злоумышленнику действия), а также схемы обмана при помощи телефонных звонков, мессенджеров и поддельных сайтов.

Методы «цифровых атак» становятся все изощреннее. Помимо традиционно активного использования фишинга (копии сайтов для получения доступа к личной информации клиентов, например паролям), в сети компьютеров, зараженных вредоносным программным обеспечением, растет число случаев использования мошенниками искусственного интеллекта и дипфейков ‒ методов синтеза изображения и голоса клиентов. По данным системного интегратора «Информзащита», с января по октябрь 2024 г. число атак с использованием технологии дипфейк в финансовом секторе выросло на 13% год к году ‒ до 5 700 случаев.

При этом улучшилась и эффективность антифрод-систем банков, количество предотвращенных мошеннических операций значительно выросло. По данным ЦБ, антифрод-системы кредитных организаций в 2024 г. отразили 72,17 млн попыток хищения денег клиентов со стороны злоумышленников. Годом ранее ‒ 34,77 млн.

В первом квартале 2025 г. количество предотвращенных «ОТП Банком» операций без добровольного согласия клиентов увеличилось на 17% по сравнению с IV кварталом 2024 г. и составило 631 транзакцию. Это связано в основном с возросшей активностью мошенников. Вследствие этого системой антифрода банка было выявлено и отклонено больше подозрительных операций по сравнению с предыдущим периодом. При этом в банке уделяют большое внимание влиянию системы антифрода на наших клиентов: в течение первого квартала 2025 г. доля приостановленных антифродом операций от общего их количества была снижена почти вдвое: с 0,27% до 0,18%.

Развитие новых технологий, по сути, идет на пользу прежде всего мошенникам.

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

Продолжение интервью можно прочитать на сайте "Ведомости".