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

Новый закон об ИИ вступает в силу 1 сентября: что изменится для владельцев сайтов

Привет! Я Александр Бондаренко, руководитель проектной группы в Далее. Мы делаем сайты и плотно работаем с их комплаенсом, поэтому новые законы я изучаю не как новости, а как список требований к проектам. 

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

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

Сначала напомню, о каком законе идет речь👇

Федеральный закон № 243-ФЗ «О поддержке развития технологий искусственного интеллекта в Российской Федерации»

Рамочный закон, который регулирует большие фундаментальные модели вроде ГигаЧата или Алисы. Они имеют от 1 миллиарда параметров и способны выполнять интеллектуальные задачи на уровне человека или выше. Если компания просто использует готовые модели в своих сервисах, закон на нее напрямую не распространяется.

Полный текст

Основная часть закона вступает в силу с 1 сентября 2026 года, отдельные нормы — с 1 марта 2027-го.

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

Суверенные модели смогут использовать контент с сайтов без согласия авторов

Национальный статус дает два преимущества: можно свободно обучаться на объектах авторского права и получить доступ к государственным данным. 

С 1 марта 2027 года модели с особым статусом будут использовать статьи, книги, музыку и изображения бесплатно и без отдельного разрешения автора. При условии, что произведение было получено правомерно или легально опубликовано и доступно для анализа. 

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

Обязательная маркировка ИИ-контента — просто слух

Его часто повторяли в интернете, пока закон проходил согласования. По факту же маркировка добровольная, обязательна только техническая возможность ее поставить, и только для крупных платформ.

Разработчики моделей с аудиторией до 500 000 могут опционально добавить функцию маркировки для пользователей. Для платформ с посещаемостью выше — это обязательное требование. Если ваш сайт или сервис близок к этому порогу аудитории и работает с генеративным контентом, стоит заранее продумать, как это реализовать.

Прямого запрета на использование иностранных моделей в законе нет

Правительство сможет регулировать объекты и сферы, где разрешено применять только суверенные модели. Подробностей пока нет, но мы знаем, что будет поблажка. Если система уже работает к 1 марта 2027 года и данные хранятся в России, владельцы смогут использовать иностранный ИИ до сентября 2032 года. 

Отдельно закон выделяет финансовый сектор. Здесь решения Правительства должны приниматься по согласованию с Банком России. Поэтому банкам и финтех-компаниям стоит следить не только за подзаконными актами Правительства, но и за будущими требованиями ЦБ.

Некоторые вопросы остаются открытыми

1. Какие государственные данные откроют для обучения? 

2. Как будет работать opt-out и каким будет технический механизм отказа правообладателя?

3. Где будут разрешены только суверенные модели и насколько широким будет этот список?

4. Что такое достаточная «техническая возможностью маркировки»?

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

Подборка вебинаров на сентябрь

В сентябре покажем, как за пять дней построить Data Lakehouse, защитить данные при работе с LLM, выстроить безопасную ИИ-инфраструктуру и обеспечить отказоустойчивость PostgreSQL для продакшен-нагрузок. Выбирайте интересную тему и регистрируйтесь. 

Как построить управляемый Data Lakehouse за неделю на Evolution Data Platform
Покажем, как за несколько дней с нуля построить архитектуру Data Lakehouse на Evolution Data Platform — от загрузки сырых данных до курированных витрин. Разберем принципы работы с Apache Iceberg, централизованное управление метаданными, контроль качества данных, единый SQL-слой и оркестрацию пайплайнов. Все увидите на демо.
🧑‍💻 Для кого: архитекторы данных, дата-инженеры, руководители аналитики и data-направлений, ИТ-директора, специалисты по управлению данными.
📅 Когда: 8 сентября, 11:00 мск.
📍 Где: Онлайн. Зарегистрируйтесь, чтобы задать вопросы спикерам.

Как защитить чувствительные данные при работе с LLM с помощью Guardrails
Разберем, как работают Guardrails LLM и Guardrails Filter: чем они отличаются, какие данные помогают обнаруживать и как адаптировать правила проверки под задачи компании. Отдельно рассмотрим, как защитный слой Guardrails работает в контуре Evolution Foundation Models, а также какую роль в проверке запросов играют модели-классификаторы HiveTrace. На демо покажем работу open source версии Guardrails Filter.
🧑‍💻 Для кого: специалисты по защите данных и ИБ, команды разработки ИИ-приложений и тем, кто внедряет LLM в бизнес-процессы.
📅 Когда: 15 сентября, 11:00 мск.
📍 Где: Онлайн. Зарегистрируйтесь, чтобы задать вопросы спикерам.

ИИ в облаке: кто отвечает за безопасность
Безопасность ИИ в облаке — это общая ответственность провайдера и бизнеса. Разберем, где проходят границы этой ответственности и как выстроить безопасную ИИ-инфраструктуру без лишних рисков. Обсудим подход Zero Trust: расскажем, как контролировать доступ к данным, моделям и сервисам в Cloud.ru Evolution и какую роль в этом играет Evolution Managed Identities (IAM).
🧑‍💻 Для кого: руководители и специалисты по ИБ (CISO), архитекторы и инженеры, проектирующие ИИ-инфраструктуру, специалисты, работающие с чувствительными данными, руководители, отвечающие за внедрение ИИ в компании.
📅 Когда: 17 сентября, 11:00 мск.
📍 Где: Онлайн. Зарегистрируйтесь, чтобы задать вопросы спикерам.

PostgreSQL для продакшен-нагрузок: Multi-AZ, реплики и переключение ролей
От доступности PostgreSQL зависит стабильная работа backend-сервисов и пользовательских сценариев. Разберем, как обеспечить высокую доступность PostgreSQL в облаке. Покажем, как в Evolution Managed PostgreSQL устроена архитектура Multi-AZ, какую роль играют реплики базы данных и как работают ручное и автоматическое переключение при плановых работах и сбоях.
🧑‍💻 Для кого: DevOps-инженеры, SRE-инженеры, инфраструктурные инженеры и все технические специалисты, работающие с PostgreSQL.
📅 Когда: 29 сентября, 11:00 мск.
📍 Где: Онлайн. Зарегистрируйтесь, чтобы задать вопросы спикерам.

Много лет висело без откликов у меня на hh.ru резюме на вакансию «Web-реаниматор старых сайтов» и вдруг прилетела «подработка»…

У небольшой организации занимающейся разработкой очень специфичной техники есть в интернете несколько информационных сайтов на Joomla 3 и уже года 4 без каких-либо изменений, и, соответственно без необходимости иметь сотрудника для их поддержки.
И что примечательно, у этих сайтов в среднем около 1 посещения в неделю..

Но месяц назад на двух сайтах вдруг появились вместо заглавных страниц сообщения «Взломан CoupDeGrace» и «Взломан ANTONKILL».
Так у меня появилась хоть какая-то работа за последние 4 года.
Убрать заставки взломщиков оказалось достаточно просто, сложнее перекрыть дальнейшие возможности для подобных хулиганств – не представляю как удалить из работающего сайта модули Helix и Sppagebuilder, через которые происходит основной вход «хулиганов»… частично их «деактивировал».  Но наверняка есть и другие способы, про которые я тогда не знал.
Обновлять Joomla до актуальной версии занятие долгое и непредсказуемое, а потому один сайт остался жить просто почищенным от заставок «Взломан …», а их там оказалось несколько десятков, а другой достаточно быстро перелопачен в статичные html страницы.
Первый этап «реанимации» закончен и очень постепенно начался второй – поиск нового движка для сайтов. Желательно отечественного производства, с активной поддержкой, чётким MVC, а ещё и бесплатным… в общем – проблематичные условия, но несколько кандидатов нашлось, и даже лидер образовался с самым маленьким количеством проблем на входе.

Но опять возникло «НО»!
Тот сайт, что остался крутиться на Joomla был заселён несколькими бэкдорами и это обнаружилось совершенно случайно только потому, что развили очень активную деятельность и буквально подвесили виртуальный сервер с очень скромными ресурсами.

За прошедшие выходные я понял, что мои возможности уже сильно устарели и резюме на вакансию «Web-реаниматор» надо бы убрать…
Мало того, что «искусство обфусцирования» вышло за уровни моего понимания, но как можно перехватывать пересылаемый по ftp на сайт index.php и класть его в корень с уже вписанным «вирусом» - мне уже видимо не осознать.

В прошлом году на секции «Слабое звено ИБ» один выступающий рассказал о своём эксперименте по «взлому» - всего $10 долларов на оплату токенов и ВСЁ!
Про миллион за взлом «белым хакерам» можно забыть – нейросети обесценили труд этих специалистов на несколько порядков.

Любая известная и популярная CMS со средствами «web-администрирования» и самообновления уже имеет в себе «парадные ворота» для взлома и заселения всем чем захочется.

На мой «устаревший» взгляд, самым эффективным вариантом решения проблемы для подобных информационных сайтов, мне видится CMS с полным функционалом по управлению сайтом на локальном компьютере, а в «публичное пространство» выгружаются только html страницы. И только 555 для папок и 444 для файлов.

А может не всё так грустно?
Может есть уже простые решения, про которые всем кроме меня всё давно известно?

ФСТЭК готовит новые требования к защите ИИ: как службе ИБ сохранить контроль

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

ФСТЭК России предложила изменения в приказ №117. Если проект примут, с 1 марта 2027 года появятся дополнительные требования к защите ИИ.

Среди предлагаемых мер:

• сетевая изоляция моделей;

• многофакторная аутентификация;

• применение принципа наименьших привилегий;

• фильтрация запросов и ответов;

• ограничение количества обращений к модели;

• контроль функциональности ИИ.

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

Как службе ИБ сохранить контроль над ИИ?
Один из практических вопросов — контроль взаимодействия между ИИ-приложением и языковой моделью: выявление чувствительных данных, доступ только к утверждённым моделям и передача событий ИБ в SIEM. Отдельная задача — контроль использования сотрудниками публичных ИИ-чатов, или Shadow AI.

Эти и другие вопросы защиты корпоративного ИИ разберём 10 сентября в 11:00 МСК на вебинаре «Корпоративный ИИ захватывает всё больше бизнес-процессов. Как службе ИБ сохранить контроль?»

Айдар Фатыхов, владелец продукта Innostage AIDR, и Александр Лебедев, старший ML-разработчик продукта Innostage AIDR расскажут:

• как защитить коммерческую тайну и другие чувствительные данные при работе с ИИ;

• почему события ИБ от ИИ-систем необходимо включать в процессы мониторинга, корреляции и расследования инцидентов;

• какие требования к защите ИИ действуют сегодня и что предлагается изменить в приказе ФСТЭК России №117.

• в практической части вебинара покажут сценарии защиты запросов и ответов LLM, утечки данных и контроля Shadow AI.

Регистрация на вебинар
10 сентября, 11:00–12:00 МСК

Зачем ФСТЭК ограничивает права ИИ

ФСТЭК готовит новые правила для ИИ в государственных информационных системах. 24 августа ведомство опубликовало проект изменений в приказ №117. В нем предлагается ограничить модели ИИ в доступе и правах. Проект должен вступить в силу 1 марта 2027 года.

Что меняется, когда ИИ получает доступ к LDAP

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

Например, если ИИ-агенту дать доступ к корпоративному LDAP-каталогу, он сможет:

• Добавить учетную запись в группу

• Изменить атрибут пользователя

• Изменить членство в группе

• Массово изменить данные

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

Что может оказаться под угрозой?

В каталоге лежат не только логины и учётные записи, но и ФИО, должности, отделы, телефоны, почта, фото – целая база персональных и служебных данных.

Если агенту разрешено читать эти данные, то злоумышленникам не обязательно взламывать LDAP. Достаточно дать агенту команду – и он сам отдаст данные наружу или испортит их.

Локальная или внешняя модель?

С точки зрения рисков не принципиально, используете вы внешнюю или локальную модель. Если локальная модель имеет широкие права, она сольёт данные не хуже внешнего сервиса. Так что ФСТЭК смотрит не на место проживания модели, а на то, что она видит, к чему имеет доступ и что может делать.

Один неправильный запрос может превратиться в инфраструктурный инцидент.

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

ИИ становится еще одним участником системы доступа

Выходит, ИИ-агент, подключенный к каталогу, становится еще одним участником системы управления доступом. Если дать ему слишком много прав, мы откроем путь:
внешняя команда → ИИ-агент → LDAP → данные пользователей или права доступа.

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

Что делать, если изменения уже произошли

Просто иметь бэкап каталога – мало. Если агент испортил сотни записей, полный откат вернёт старую версию, но заодно откатит все правильные изменения, которые появились после бэкапа.

Поэтому нужны два уровня защиты:

1. Резервное копирование, чтобы сохранить состояние каталога;

2. Гранулярное восстановление, чтобы найти и вернуть неправильно изменённые объекты или атрибуты.

Получается простая цепочка:

ограничить права ИИ → контролировать его действия → не дать слить данные наружу → не дать править лишнее → иметь бэкап → уметь точечно восстановить данные.

Новые требования ФСТЭК интересны не только для ИИ. Они показывают: если ИИ подключается к инфраструктуре, его безопасность становится частью безопасности всей системы – включая службу каталога.

Полезные онлайн-ресурсы с актуальными и отчётами по информационной безопасности:

• Annual Security Reports — репозиторий, который включает в себя ежегодные отчёты по кибербезопасности от крупнейших IT-компаний.

• Phishing campaigns — репозиторий с примерами фишинговых писем, которые направлялись APT‑группировками в различные компании по всему миру. Помимо примеров, проект включает в себя презентации с разбором и описанием фишинговых атак.

• Hackerone Reports — объёмный репозиторий, который включает в себя топ отчёты HackerOne. Поможет узнать много нового и полезного (варианты эксплуатации различных уязвимостей, векторы атак и так далее).

Как ИИ помогает специалистам по безопасности

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

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

1️⃣ Как ИИ помогает разбирать инциденты?

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

ИИ может проанализировать логи и другие данные и собрать их в понятную картину.

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

2️⃣ Как ИИ помогает проверять защищенность приложений?

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

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

3️⃣ Может ли ИИ находить уязвимости еще на этапе разработки?

Да. Современные модели умеют находить типовые веб‑уязвимости — например, SQL‑инъекции, XSS и CSRF, — участвовать в ревью кода и объяснять, почему выбранный подход может быть опасен.

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

4️⃣ Где еще он может пригодиться?

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

5️⃣ Какие ограничения важно учитывать?

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

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

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

→ Подробнее своим опытом Евгений поделился в статье.

Бот с заданиями по кибербезопасности и розыгрыш мерча

Каждый год у нас в Ozon Tech проходит турнир Capture The Flag. И каждый раз после его окончания мы делимся заданиями с подписчиками. За правильные флаги самым удачливым дарим мерч.

В этом сезоне наш гусь-маскот Гоша отправился в путешествие в далёкие-далёкие галактики. По пути он попал сразу в пять приключений формата OSINT, Forensic и Stego. Пришлось дешифровать тревожные сигналы, ловить акустические аномалии, декодировать координаты.

Присоединиться к выполнению заданий можно до 6 сентября включительно

Добудете минимум 4 флага из 5, и сможете претендовать на набор мерча. В наборе полезные мелочи для путешествий и приключений в пределах Млечного Пути.

Удачи!

MAX тоже можно защитить шифрованием поверх мессенджера

Telegram, VK и другие сервисы можно использовать как транспорт для зашифрованных сообщений, не полагаясь на их собственный механизм защиты содержимого. Российский разработчик развивает open-source проект CryptoLayer — библиотеку, которая создает дополнительный криптографический слой непосредственно на устройствах участников переписки.

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

Как это работает

CryptoLayer не заменяет Telegram, VK или другой сервис, а отделяет защиту содержимого от транспорта.

Для шифрования используется AES-256-GCM, для цифровых подписей — ECDSA на кривой SECP256R1, а согласование ключей выполняется через ECDH с той же кривой. Дополнительно библиотека может преобразовывать зашифрованные данные с помощью WordCoder — он кодирует байты в последовательность обычных слов.

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

Один криптографический слой — разные каналы

Главная особенность проекта — модульная архитектура. CryptoLayer не привязан к конкретному мессенджеру или платформе.

В репозитории указано, что транспортом может быть практически любой канал, способный передавать данные. Среди примеров — Telegram, VK, Discord, HTTP, SSH, FTP, UDP, облачные хранилища, файловая система и Bluetooth. Для нового варианта передачи требуется написать отдельный модуль.

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

Однако готового модуля для MAX в основном репозитории сейчас нет. Поэтому полноценной поддержки этого мессенджера пока нет — потребуется отдельная интеграция.

Какие инструменты уже доступны

Вокруг CryptoLayer постепенно формируется собственная экосистема:

• CryptoLayer CLI — интерфейс для работы из терминала;

• CryptoLayer Web UI — веб-интерфейс для защищенного обмена сообщениями;

• zkgram — отдельный клиент для приватного общения через Telegram.

Исходный код опубликован под лицензией MIT. На момент проверки официальный репозиторий набрал более 200 звезд на GitHub, но проект остается небольшим независимым open-source решением, а не криптографической системой, прошедшей масштабный аудит.

Это важная оговорка. Наличие AES-256-GCM, ECDSA и ECDH само по себе не гарантирует безопасность всей системы. Многое зависит от реализации протокола, генерации и хранения ключей, защиты конечных устройств и отсутствия ошибок в коде.

Что все равно видит мессенджер

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

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

Иными словами, CryptoLayer не скрывает существование переписки. Его задача — не дать транспортному каналу получить исходный текст сообщения.

Где посмотреть исходный код

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

Архитектура и принцип работы проекта также показаны в видеопрезентации CryptoLayer.

Главное

CryptoLayer интересен не как новый защищенный мессенджер, а как внешний слой шифрования, который отделяет конфиденциальность переписки от конкретного сервиса доставки.

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

✔ Код — журнал о технологиях https://t.me/kodjournal подпишитесь на наш Telegram-канал! 😎

Регистрацию на иностранных сайтах по номеру телефона убрали из «Антифрод 3.0»

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

Из актуальной версии «Антифрод 3.0» исключили норму, обязывающую иностранные сайты и приложения, работающие в России, регистрировать пользователей внутри страны только по номеру телефона. Об этом сообщили «Ведомости», ознакомившиеся с новой редакцией законопроекта.

Что планировали изменить

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

Если бы норма сохранилась, такие платформы должны были бы:

• использовать номер телефона как обязательный способ авторизации пользователей в России;

• хранить сведения о регистрации, входе и удалении аккаунтов в течение трёх лет;

• предоставлять эти данные по запросам органов, занимающихся оперативно-розыскной деятельностью или обеспечением безопасности.

Теперь этих положений в новой редакции проекта нет.

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

Почему от требования могли отказаться

Главная проблема — техническая и юридическая реализация такой схемы на иностранных платформах.

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

Гендиректор Telecom Daily Денис Кусков считает исключение нормы разумным именно по этой причине. Независимый аналитик Алексей Бойко также обращает внимание на риск, что зарубежной платформе может оказаться проще ограничить работу в России, чем создавать отдельную систему авторизации для российских пользователей.

«Антифрод 3.0» ещё меняется

О подготовке третьего пакета мер против кибермошенничества объявили в апреле 2026 года. Законопроект планируют внести в Госдуму осенью.

Причём требования к иностранным ресурсам уже успели измениться: ещё в конце июля «Ведомости» сообщали о проекте, в котором обязательная авторизация по номеру телефона присутствовала.

Пока окончательный набор мер не утверждён, поэтому пользователям иностранных сайтов не стоит воспринимать исключённую норму как уже принятое решение или окончательную отмену каких-либо требований. Финальная редакция «Антифрод 3.0» может ещё измениться.

🔎 PhishIntel — автономный OSINT-инструмент для анализа доменов

Проект помогает быстро собрать технический профиль домена и оценить потенциальный фишинговый риск в формате структурированного JSON-отчёта.

Что проверяет PhishIntel:

• DNS-записи, IP и reverse DNS;
• RDAP/WHOIS и регистрационные данные;
• HTTP, TLS-сертификаты и цепочки редиректов;
• содержимое веб-страниц, формы и внешние action;
• упоминания брендов и фишинговых ключевых слов;
• используемые веб-технологии;
• sitemap и обнаружение распространённых поддоменов;
• локальную историю изменений DNS и TLS;
• контекстный explainable scoring — с пояснением, почему домен получил тот или иной уровень риска.

Инструмент работает автономно, не требует обязательного доступа ко всем сетевым сервисам и продолжает формировать отчёт даже при недоступности DNS, HTTP или TLS-проверок.

Запуск:

python3 scan.py example.com

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

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

"Изучи технический отчет домена и дай оценку потенциальному фишинговому риску, составь краткий человекочитаемый отчет"

Инструмент писал для личных нужд, но может он будет полезен детективам, безопасникам и OSINT-специалистам.

🔗 Репозиторий: https://github.com/Bednyakov/PhishIntel

Аттестация начинается с инфраструктуры: виртуализация и контейнеризация под требования ФСТЭК

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

На вебинаре разберем, какие требования предъявляются к инфраструктуре регулируемых ИС и как zVirt Max и Nova SE помогают сформировать технологический фундамент для аттестации.

Что обсудим:

— Требования ФСТЭК к инфраструктуре ЗО КИИ, ГИС, МИС, АСУ ТП и ИСПДн
— Применение сертифицированных версий zVirt Max и Nova SE в регулируемых контурах
— Механизмы защиты на уровнях виртуализации и контейнеризации
— Изоляция данных, разграничение доступа, контроль целостности и регистрация событий безопасности
— Роль сертифицированных продуктов в подготовке систем к аттестации
— Построение доверенной российской инфраструктуры без отказа от современных технологий виртуализации и контейнеризации

Спикеры:

Александр Гавриленко, директор технического пресейла и партнерских интеграций, Orion soft

Анна Лернер, руководитель по безопасной разработке, Orion soft

Регистрация тут

Наша команда потихоньку перебирается в новый офис и обзаводится дополнительным оборудованием. Среди новых "игрушек" у нас появился источник питания RIGOL DP932E, цифровой мультиметр DM3058E, осциллограф RIGOL DS1202Z-E, на подходе USRP-200 и еще более 50 позиций.

Среди давно ожидаемого оборудования, как бы это не казалось таким странным, являлся тепловизор и, в данном случае, наш выбор остановился на Verdo Ti3101.
Тепловизор - вещь достаточно незаменимая и нужная в хозяйстве. Основная задача измерителя - найти неисправные элементы для их последующей замены и восстановления работоспособности устройства: подаешь 1-2 вольта и смотришь где греется - там и короткое замыкание.

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

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

Но меня поразил "побочный эффект" (если можно его так назвать) тепловизора, отчего я снова могу начать верить в приведений 😅 Ситуация в следующем: я находился в кабинете, стены которого выполнены из стекла. Стекло было прозрачным, но все равно, если присмотреться, можно было увидеть свое отражение. И тут я направляю тепловизор на свое отражение и ... оно явно и четко появляется на экране, да и еще с повышенной температурой.
То есть еще раз: тепловизор принимает тепло моего отражения в стекле.

Физику процесса с коллегами мы кубатурили долго и пришли к вероятностному выводу, что все есть волны. Соответственно, волны тепла от моего тела частично отразились от стекла и попали на объектив тепловизора. Не знаю, насколько это истинна, но было жутковато.
Коллеги, поможете нам в решении этой головоломки, почему так происходит?

🧠 Обязательно поделись с теми, кому это может быть полезно 💬 Телеграм | 💬 Max | 📝 Хабр | 💙 ВКонтакте

14 августа была выложена новая версия модели Qwen 3.8 27b и 27b-FP8. 12 августа назад была выложена новая версия модели Qwen 3.8-2.4T-A95B и Qwen 3.8-2.4T-A95B-FP8.

Почему это важно для кибербеза? Семейство квен самое популярное семейство среди моделей на hugging face как по количеству скачиваний так и по использованию для построения\файнтюна своих моделей. Россия в этом плане не сильно отличается от мировых тенденций.

Версия на 27 млрд параметров по общим бенчмаркам способностей находится на уровне GLM-5.2 (max), Deepseek V4Pro 0813, GPT 5.6 Luna. Квантованную до FP8 версию можно попробовать запустить на условно домашней rtx 5090 32 Гб

Версия на 2,4 трлн параметров по общим бенчмаркам способностей находится на уровне Muse Spark 1.2, GPT 5.6 Terra, т.е. можно отнести к SOTA моделям . Эта версия FP8 уже потребует профессиональных минимум 16 видеокарт Nvidia B300.

Как обычно хотелось бы понимать насколько эти модели более защищенная и (или) более способная для задач кибербезопасности.

А тут появляются проблемы, официально у новых моделей нет тех репорта, только карточки на hugging face c ссылками в никуда или на весьма ограниченное описание. Каких либо других независимых отчетов по кибербезопасности и safety мне тоже не удалось найти. В части возможностей самой модели можно с допущениями ориентироваться на тест облачной версии модели Qwen 3.8 Max (как аналога Qwen 3.8-2.4T-A95B) от Aikido:
"Qwen rediscovered 26 of 32 CVEs across three runs, for 81.25% pass@3 recall. That's ahead of GPT-5.6-Sol and matches Opus 5, at roughly half the cost".

Можно попробовать ориентироваться на комплексные бенчи:
Terminal‑Bench 2.1 - навыки работы в командной строке, в том числе для задач кибербезопасности (нахождение и закрытие уязвимостей в коде, реверс-инжиниринг бинарных файлов и безопасная настройка доступов).
DeepSWE 1.1 - бенч для навыков агентов по написанию кода, отдельных разделов по безопасности нет, но это навык смежный с написанием кода.

Значимое отличие - Qwen 3.8 27b единственную из актуальных опенсорс общих моделей можно запустить на одиночном устройстве, особенно если на неофициальном квантовании FP4. Тогда как для "соседей" по бенчмаркам (GLM 5.2, Deepseek V4Pro 0813, GPT 5.6 Luna) потребуется кластер (а иногда и не один) профессиональных видеокарт.

Что на текущий момент является аномальным результатом по соотношению (возможности модели в Terminal‑Bench 2.1)/стоимость оборудования. Соотношение сохраняется в DeepSWE 1.1 и нескольких других бенчах .

Будем ждать новых отчетов по этому семейству, пока Artificial Analysis не включил в бенч по затратам Qwen 3.8 27b, поэтому нужно отнестись сдержанно к получившейся аномальной оценке.

Если у кого то есть локальная RTX 5090 и свободное время - поделитесь впечатлениями ;) .

Эксплойт с молоком

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

Меламин - синтетическое органическое химическое вещество, используемое для создания прочных смол, пластика, ламината для мебели и посуды. Казалось бы, где меламин, и где молоко? Дельфин и русалка... Но...

Как определяют содержание белка в продуктах? В белках есть азот. Извлекают азот или его соединения (для этого варят в кислоте или сжигают), замеряют их и по содержанию азота считают, сколько было белков. Метод не абсолютно точный, может же быть и иной азот в продукте, но его ничтожно мало и можно принебречь.

Можно принебречь так же, как можно принебречь экранированием апострофа в имени пользователя на сайте парикмахерской. (Вряд ли у нас на районе поселится д'Артаньян или Жанна д'Арк). Но если принебрегли - у нас поселится '; DROP TABLE users; --

Если разбавить молоко бесплатной водой - получим много молока. Но его не примут, так как по азотному тесту содержание белка будет слишком низким. А вот в меламине - 66% азота. Добавляем совсем немного дешевого меламина - и белковый анализатор счастлив!

https://ru.wikipedia.org/wiki/Скандал_с_китайским_молоком_(2008)

Мы, конечно, пилим наш продукт в России, но Atmy (ex-Nebo - карта качества воздуха, приложение и датчики) будет жить и за пределами нашей страны.

И перед релизом бета-сайта Atmy мы столкнулись с вполне себе геморройной проблемой - data residency.

С правилами РФ более-менее разберёмся. А вот что делать с SOC2, GDPR и прочими зарубежными требованиями — вопрос открытый. Каждая юрисдикция хочет своё, и универсального рецепта не видно.

Поэтому спрашиваю: как вы сейчас решаете data residency?

▶ Подняли второй Keycloak.
▶ Купили InCountry или Strivacity. Платим $XXk.
▶ Отказались от рынка.
▶ Держим два Auth0 tenants.
▶ Написали свой router.
▶ Ничего не сделали и живём с риском.

Что из этого — про вас? Или есть свой вариант, которого здесь нет?

Ситуация, знакомая многим: MAX ставить не хочется, а приходится. Работа, знакомые, школьные чаты — и вот у тебя на телефоне живёт приложение, которому ты не доверяешь, и которое работает в фоне тогда, когда ему захочется.

Мне хотелось чтобы MAX вообще не было ни на моём телефоне, ни в моём браузере — а переписка при этом приходила туда, где я и так сижу. В Telegram.

Так появился Telemax — мост между MAX и Telegram.

Что понадобится

Сервер — любая VPS на Ubuntu/Debian. Требования скромные, хватит самой дешёвой.

Свой Telegram-бот — создаётся за минуту в @BotFather, токен вставляется при настройке. Бот твой, живёт на твоём сервере, никакого общего чужого бота — данные идут только через твою инфраструктуру.

Telegram-группа с включёнными темами, куда ты добавишь этого бота админом. Она и станет твоим «окном» в MAX.

Номер MAX, на который мост авторизуется (в том числе если на аккаунте стоит пароль-2FA).

Про безопасность и доступ — два уровня:

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

Внутри группы — разграничение. Обычные участники могут читать и писать (можно спокойно добавить людей в группу, чтобы вести общее обсуждение). А вот команды боту — только для админа.

Честная оговорка: тот, кого ты добавил в Telegram-группу, видит там все MAX-чаты, а не один. Так что доступ к самой группе — вещь чувствительная.

В ТГ это выглядит так:

Сертификаты минцифры в Firefox Nightly на Android: через adb, без рута

Понадобилось, чтобы сертификату минцифры доверял только Firefox Nightly, а не весь Android.

GeckoView читает /data/local/tmp/<package>-geckoview-config.yaml не только у debuggable-приложений, но и если пакет назначен текущим debug_app. А в конфиге можно задать аргументы запуска Gecko и поднять Marionette.

Поднимаем Marionette

geckoview-config.yaml:

args:
  - --marionette
  - --remote-allow-system-access
prefs:
  marionette.port: 2828

adb shell am set-debug-app --persistent org.mozilla.fenix
adb push geckoview-config.yaml \
  /data/local/tmp/org.mozilla.fenix-geckoview-config.yaml
adb shell chmod 644 /data/local/tmp/org.mozilla.fenix-geckoview-config.yaml
adb shell am force-stop org.mozilla.fenix
adb shell monkey -p org.mozilla.fenix -c android.intent.category.LAUNCHER 1
adb forward tcp:2828 tcp:2828

Кладём сертификаты в cert9.db

Marionette в chrome-контексте даёт привилегированный JS, дальше всё делает nsIX509CertDB. Флаг "C,," для корня, которому доверяем по SSL, ",," для промежуточных: доверия им не надо, они нужны только чтобы собралась цепочка.

Протокол простой, длина:json поверх TCP, клиент пишется за пять минут:

use v5.36;
use IO::Socket::INET;
use MIME::Base64 'encode_base64';
use JSON::PP;

my $s = IO::Socket::INET->new('127.0.0.1:2828') or die $@;
my $j = JSON::PP->new->canonical;
my $id = 0;

sub pkt {
    my ($len, $buf, $c) = ('', '');
    $len .= $c while sysread($s, $c, 1) and $c ne ':';
    $buf .= $c
        while length $buf < $len and sysread $s, $c, $len - length $buf;
    $j->decode($buf);
}

sub cmd ($name, $params = {}) {
    my $body = $j->encode([0, ++$id, $name, $params]);
    print {$s} length($body) . ":$body";
    my $r = pkt();
    die "$name: " . $j->encode($r->[2]) . "\n" if defined $r->[2];
    $r->[3];
}

my @certs = map {
    my ($file, $trust) = split /=/, $_, 2;
    open my $fh, '-|', qw(openssl x509 -outform DER -in), $file
        or die "$file: $!";
    binmode $fh;
    [ encode_base64(do { local $/; <$fh> }, ''), $trust // 'C,,' ];
} @ARGV;

pkt();
cmd 'WebDriver:NewSession';
cmd 'Marionette:SetContext', { value => 'chrome' };

say JSON::PP->new->pretty->canonical->encode(cmd 'WebDriver:ExecuteScript', {
    script => q{
        const cid = "@mozilla.org/security/x509certdb;1";
        const db = Cc[cid].getService(Ci.nsIX509CertDB);
        return arguments[0].map(([b64, trust]) => {
            try {
                const c = db.addCertFromBase64(b64, trust);
                return { ok: true, subject: c.subjectName };
            } catch (e) {
                return { ok: false, error: String(e) };
            }
        });
    },
    args => [ \@certs ],
});

cmd 'WebDriver:DeleteSession';

устанавливем:

perl fenix-cert.pl \
  russian_trusted_root_ca_pem.crt=C,, \
  russian_trusted_sub_ca_pem.crt=,, \
  russian_trusted_sub_ca_2024_pem.crt=,,

# cleanup
adb shell rm -f /data/local/tmp/org.mozilla.fenix-geckoview-config.yaml
adb shell am clear-debug-app
adb forward --remove tcp:2828
adb shell am force-stop org.mozilla.fenix

Проверено на Pixel 5, Android 14, Firefox Nightly 156.0a1.

Видео доступно по ссылке -> https://vkvideo.ru/clip-237277610_456239029

Давайте сегодня поговорим про бумажную безопасность, но не в привычном ее понимании: политики, контроли и комплаенс; а в буквальном смысле - безопасность информации, представленной на бумаге. Сотрудник ФБР (по крайней мере он так представился) на наглядных примерах показывает разницу между шредерами и качеством выполнения их работы.

На сегодня существует 3 типа уничтожителей бумаги: прямые, ромбовидные и конфетти. 
Первые уничтожают бумагу, разрезая ее на ровные полоски. При таком подходе собрать обратно пазл не составляет особого труда и занимает не более 1 часа на восстановление информации. Тоже самое относится и к банковским картам - получить номер карты, ФИО и CVV код займет от силы 1 минуту (30 секунд из которых вы будет искать кончик скотча, чтобы склеить ее обратно).

С ромбовидными сложнее, но восстановление тоже возможно, хотя и занимает намного больше времени. По информации сотрудника, собрать обратно документ составляет около 8 часов.

Самые лучшие, и которые стоят в офисах ФБР (спасибо за подсказку) - это шредеры, которые превращают документ в конфетти. При таком подходе собрать документ обратно не возможно (но тут бы я поспорил). 

Естественно, стоимость бумагоизмельчителей пропорционально растет в зависимости от качества уничтожения документов. С другой стороны, купить шредер ради шредера (первый вариант) - выглядит бездумной тратой денег. К сожалению, не всегда удается донести до закупки почему нужно покупать дорогую вещь, когда существует версии в 10 раз дешевле. 

И к слову сказать, мы в своей работе в рамках Red Team проектах нередко прибегаем к таким методам, так поиск информации в шредерах. Психология людей обычно сводится к тому, что раз документ прошел через измельчитель, значит информация безвозвратно уничтожена. Однако вы теперь знаете, что это далеко не так.
Так что, какой берем?

п.с. нас еще учили, чтобы безвозвратно уничтожить документ, его сначала сжигают, а потом просеивают через мелкозернистую сеть. К сожалению, таких устройств еще не существует, поэтому дарю бизнес-идею ;) 

🧠 Обязательно поделись с теми, кому это может быть полезно 💬 Телеграм | 💬 Max | 📝 Хабр | 💙 ВКонтакте

ФСТЭК опубликовала методику оценки уровня зрелости в области технической защиты информации, которая затрагивает в том числе значимые объекты КИИ. Документ вводит пять уровней зрелости (от «нулевого» до «верифицируемого») и 21 направление оценки — от управления защитой до применения ИИ. Эксперты отмечают, что методика призвана бороться с недобросовестными подрядчиками и перевести ИБ из разрозненных задач в стратегию, однако её реализацию могут осложнить неясность с проведением оценки и отсутствие должного контроля со стороны регулятора.