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

«Оборотные» не за горами! Стоит ли сообщить регулятору о старых утечках?

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

По нашим данным, только 31% компаний готовы уведомить власти при утечке. Разберемся, стоит ли менять позицию и «сдаваться» сейчас, или нет:

• Положения закона, ужесточающие наказания, обратной силы не имеют. Это напрямую отражено в КоАП РФ и значит, что утечки, произошедшие до 30 мая, но обнаруженные позже, должны наказываться по-старому: штрафом в 60-100 тысяч рублей. Но если регулятор узнает об инциденте не от вас, а, например, из публикации похищенной базы данных, моментом нарушения он сочтет время этой публикации.

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

• Обязанность уведомлять Роскомнадзор об утечках введена в 2022 году. С 30 мая ее неисполнение будет грозить бизнесу штрафами в 1-3 млн р. Неуведомление – длящееся нарушение. Если утечка случилась до 30 мая, но Роскомнадзор не был вовремя уведомлен о ней, оператор будет оштрафован на крупную сумму, даже если удастся доказать более раннюю дату инцидента.

Наше исследование показало, что сейчас более 85% компаний предпочитают умалчивать или отрицать факт утечки. Однако в ближайшее время такая позиция станет чревата серьезными штрафами. Так что, если раньше у вас случались утечки, лучше все-таки сообщить о них (как и том, что вы обрабатываете персданные) до 30 мая. Это позволит отделаться «малой кровью» и избежать риска привлечения к новой ответственности за старые инциденты.

А узнать, что делать, если после 30 мая вы попадете в поле внимания регулятора, вы сможете на нашем вебинаре «Как избежать наказания за утечку» 29 мая. Это бесплатно, регистрируйтесь – будем рады вас видеть.

РТУ МИРЭА совместно с АО «НИЦ» и «РУСИБ» приглашает всех, интересующихся Инфобезом, с 7 апреля по 8 июня принять участие в гибридном хакатоне NeedForFWSpeed на самое быстрое ПО межсетевого экрана и побороться за призовой фонд 0,6 млн рублей.

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

✨️️️️️️️ Иллюзия приватности: как мы доверились ИИ без оглядки

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

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

Мы ведём себя так, будто это безопасное пространство. Будто есть некий невидимый контракт: "Ты такой классный помошник, я тебе доверяю".

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

Но ИИ не магия. И под капотом там инфраструктура и люди, которые ее обслуживают. А инфраструктура ломается. Сливается. Продаётся. Взламывается.

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

Безопасники: Василий, мы обнаружили утечку данных и следы ведут к вам!

Василий: Но я просто промтил…

Безопасники: А, ну тогда все в порядке, извините за беспокойство.

Что можно и нужно сделать компаниям прямо сейчас?

1. Определить политики использования ИИ. Чётко зафиксировать, какие данные можно и нельзя передавать в ИИ-инструменты, особенно внешние.

2. Обучать сотрудников. Рассказывать не только о возможностях ИИ, но и о рисках. Показывать реальные кейсы утечек.

3. Использовать self-hosted и on-prem решения. Там, где это возможно - разворачивать модели локально, контролируя окружение.

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

5. Инвентаризировать, какие ИИ-сервисы уже используются в компании. "Теневой ИИ" - это как теневой IT: опасен, если не знаете, где он уже работает.

ИИ даёт мощные возможности. Но без здравого смысла и защиты данных - это всего лишь ещё один путь к новой форме утечки.

Отдельные заметки на предмет исполнения федерального закона № 152 "О персональных данных"

Число операторов персональныx данныx на данный момент ~ 1 млн

Количество действующиx коммерческиx предприятий ООО и ИП ~ 2,7 млн

Количества СЗ ~ 12 млн

Потенциал для роста реестра Роскомнадзора по операторам внушительный, так как любой бизнес, будь то ООО, ИП либо СЗ, в той или иной мере всегда будет сталкиваться с обработкой персональных данных физических лиц — будь то сбор, хранение или использование информации. И, судя по закону, практически нет лазеек, чтобы избежать этого. Правительство большинство подводит под статью, обозначая нас как ОПД (оператор персональных данных) в той или иной степени.

Однако, Роскомнадзор не резиновый и существенно ограничен в трудовыx и технических ресурсаx, чтобы отслеживать всеx и каждого по данному вопросу

Так вот, для того, чтобы НЕ выделяться бездействием на фоне другиx надо, образно выражаясь, "статистически не отсвечивать"

Что это значит?

Для этого нужно соблюдать базовые минимальные правила поведения для исполнения фз 152, а именно:

- подать уведомление в Роскомнадзор как Оператор минимум по Цели обработки ПД: Подготовка, заключение и исполнение договоров гражданско-правового xарактера с контрагентами (ООО, ИП, СЗ) и Ведение кадрового и бухгалтерского учета (ООО , ИП с сотрудниками)

- опубликовать на своем сайте Политику обработки данныx

- на сайте установить всплывание сообщения, что вы собираете и обрабатываете куки, согласно Политике

- В Политике обязательно перечислите какие метрические программы (Яндекс Метрика, Пиксель ВК реклама и др.) установлены на сайте. При использовании Гугл Аналитикс сообщить Роскомнадзору о трансграничной передаче данныx

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

- при работе с ПД физлиц всегда запрашивать согласие на обработку ПД с помощью подписания отдельного документа (да, есть исключения, например, согласно пункту 1 часть 2 статья 6 ФЗ №152, но лучше всегда получать)

Вкратце так, иначе возможны штрафы, когда попадете своим бездействием под проверку Роскомнадзора

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

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

ИБ-дайджест InfoWatch

Взлом разработчика ПО в США

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

Утечка биометрии из консалтинговой фирмы

Berkeley Research Group расследует инцидент, из-за которого могли быть украдены биометрические ПДн, генетическая информация и другие данные клиентов компании.

Дайджест кибератак на библиотеки

Эксперты ЭАЦ InfoWatch собрали информацию о крупнейших кибератаках на библиотеки за последние несколько лет.

Утечка ПДн миллионов британцев

Хакеры заявили, что завладели 2,1 млн записей ПДн людей, которые обращались за правовой поддержкой в агентство юридической помощи Великобритании с 2010 года.

Coinbase потеряла до $400 млн после кибертаки

Криптобиржа прогнозирует ущерб от $180 млн до $400 млн в результате кибератаки, в ходе которой были взломаны счета группы клиентов.

Утечка ПДн клиентов Dior

Неизвестные хакеры украли данные о самых богатых клиентах французского бренда в Китае — это может стать чувствительным репутационным ударом для компании.

Данные пользователей Steam оказались в дарквебе

Злоумышленник Machine1337 продавал данные 89 млн аккаунтов Steam за $5000, но представители компании утверждают, что база содержит только одноразовые коды доступа и пользователям не о чем беспокоиться.

Разведка по 2GIS: как отзывы выдают ваши секреты

Перед тем как пойти в новое место, многие лезут в отзывы. Казалось бы — обычное дело. Но что, если я скажу, что ваш безобидный отзыв на шаурму у метро может раскрыть о вас гораздо больше, чем вы думаете?

Сегодня разберём, почему стоит дважды подумать, прежде чем писать отзывы, если вам важна приватность. И заодно — как эти отзывы могут использовать злоумышленники.

Причем здесь 2GIS?
В приложении у каждого авторизованного пользователя есть профиль, на который можно подписаться и следить за всеми отзывами. Многие думают: «Ну и что? Я же под ником "Аноним Анонимов"!»

Но вот в чём подвох:
➜ Если кто-то добавит ваш номер телефона в контакты, 2GIS подсветит ваш профиль — со всеми отзывами, фотками и активностью.

Что можно узнать из ваших отзывов?
1️⃣ Интересы — кафе, бары, магазины, кинотеатры… Всё, что вы оцениваете, рисует ваш цифровой портрет.
2️⃣ Место жительства — некоторые пишут отзывы на свои ЖК, ТЦ рядом с домом и даже на подъезды.
3️⃣ Круг общения — если вы и ваши друзья ходите в одни и те же места и оставляете отзывы, связь легко отследить.
4️⃣ Фотографии — машина, питомец, случайно попавшие в кадр документы… Мелочи, которые могут стоить дорого.

Вывод

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

Больше контента в моем авторском telegram-канале: https://t.me/ru_vm (BritLab)

Почему традиционные тренинги по ИБ не работают — и что с этим делать?

Коллеги из Ассоциации BISA выпустили отличный видеоподкаст с командой Start X: как применять теорию фреймов в обучении сотрудников и почему без понимания психологии устойчивую защиту не построить.

Рекомендуем к просмотру всем, кто отвечает за обучение, безопасность и работу с человеческим фактором.

🤖 Кибербезопасность и ИИ: почему нельзя сливать данные за контур банка

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

🛑 Главная угроза — утечка данных

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

📌 Реальные инциденты

• Samsung, 2023 — сотрудники случайно слили внутренний код и конфиденциальные данные через ChatGPT, используя его для дебага. Позже компания запретила использование ИИ-сервисов.
  🔗 Сотрудники Samsung раскрывали конфиденциальные данные, общаясь с ChatGPT

• Американский банк JPMorgan ещё в 2023 году ограничил доступ сотрудников к ChatGPT, чтобы не допустить утечки данных.
  🔗 Bank of America, Citigroup, Deutsche Bank, Goldman Sachs Group, Wells Fargo и JPMorgan Chase запретили в работе ChatGPT

• В России — в 2024 году Ростелеком опубликовал отчёт, где указал, что более 30% утечек в ИБ инцидентах связаны с несанкционированным использованием облачных AI-сервисов.
  🔗 «Ростелеком»: утечка данных была в инфраструктуре подрядчика, пользователям рекомендуется сбросить пароли и включить 2FA

🔍 Что делать в банке

• Использовать внутренние или локальные решения ИИ, работающие в изолированной среде.

• Обучать команды тестирования и разработки по теме: "какие данные можно и нельзя передавать ИИ".

• Применять анонимизацию данных при генерации тестов.

• Развивать политику «zero trust» при работе с внешними API и сервисами.

💡 Дополнительные материалы

• 🔗 Статья «ИИ и безопасность» — Хабр

• 🔗 «Риски ИИ и кибербезопасности» от Malwarebytes
  Обзор угроз, связанных с использованием ИИ в кибербезопасности, включая атаки и методы защиты.

• 🔗 «Как ИИ меняет мир кибербезопасности – защита или угроза?»
  Анализ плюсов и минусов использования ИИ в кибербезопасности, включая перспективы развития.

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

📌 Подписывайтесь на мой Telegram-канал про тестирование, AI и IT в целом! — там делюсь мыслями, новостями и практическими примерами из жизни!

InfoWatch примет участие в сессии «Киберстрахование: когда ждать прорыва?» на PHDays Fest 2025

Президент ГК InfoWatch Наталья Касперская поделится своим видением развития рынка киберстрахования в России.

Также на сцене — эксперты из «Кибериспытания», Mains, «СОГАЗ», Innostage, Red Security.

Участники обсудят:

• почему рынок киберстрахования растет медленно

• что мешает бизнесу и страховщикам создать прозрачные, понятные продукты

• как найти баланс между технологической экспертизой и требованиями регуляторов

23 мая, спорткомплекс «Лужники», Арена «Ломоносов», 15:40–16:40.

Интересно применение ML и AI в борьбе за безопасность и доверие пользователей? Тогда Trust&Safety AI Meetup точно для тебя 👀

Когда? 22 мая, 18:00
Где? офлайн в Москве + онлайн-трансляция 

В программе будут 2 технических доклада, интересная дискуссия, спикеры из Wildberries&Russ, Avito, AI Masters. А еще розыгрыш классного мерча среди активных участников и нетворкинг с полезными знакомствами.

Регистрация закроется 21 мая — выбирай формат участия и успей отправить заявку. До встречи на Trust&Safety AI Meetup!

Не пропустите подробности о митапе: @wb_space 🌟

Вышло обновление DLP-системы InfoWatch Traffic Monitor 7.12

Выпустили обновление DLP-системы InfoWatch Traffic Monitor. Агент новой версии получил поддержку работы с новыми версиями ОС.

Для соответствия требованиям госструктур агент InfoWatch Traffic Monitor версии 7.12 протестирован и поддерживает новые версии распространенных российских ОС — РЕД ОС 8 и Astra Linux 1.8.

Также в бета-версии агента добавлена поддержка macOS c возможностью контролировать HTTPS-трафик и события печати.

NotCVE - ещё одна база уязвимостей

В процессе подготовки будущей статьи искал информацию об уязвимостях, которые не были признаны разработчиками. И натнулся на проект NotCVE (он же !CVE). Проект появился как минимум с октября 2023 года. Удивительно, что в рунете практически нет упоминания этого проекта (нашёл только ссылку на этот ресурс на сайте БДУ).
Миссия проекта - предоставить общее пространство для уязвимостей, которые не признаны производителями, но при этом представляют собой серьезные проблемы безопасности. Если исследователь столкнулся с трудностями при присвоении CVE, авторы проекта готовы помочь - содействуя присвоению CVE. Либо, если это окажется безуспешным, присвоив NotCVE. База уязвимостей, которым присвоили NotCVE, пока скромная (всего 5 штук). Есть 3 варианта поиска, производящих поиск одновременно по базам CVE и NotCVE: с поддержкой фильтра по версиям, CVSS, наличию эксплоита, типу воздействия (у меня, правда, поиск по версиям плохо отработал - может, неверно составил запрос).

В часто задаваемых вопросах на сайте проекта приводят такой список причин обращаться к NotCVE:

• Проблема безопасности, которую производитель считает своей особенностью.

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

• Отклонения CVE по причине окончания срока службы и поддержки.

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

• Опубликованная проблема безопасности, которой не присвоен CVE по истечении 90 дней.

• Опубликованная проблема безопасности без присвоенного CVE.

Также есть опубликованное электронное письмо от представителей NotCVE (от 2023 года). Среди прочего там указано:

В некоторых случаях MITRE выступает за присвоение CVE, но вендор против. В таких случаях MITRE ничего не может сделать. По опыту мы можем сказать, что в итоге CVE не будет присвоен. Обратите внимание, что «проблема безопасности» не может быть даже названа «уязвимостью», потому что не является таковой (только у поставщика есть такие полномочия) в соответствии с правилами MITRE. Если что-то не является «уязвимостью», то нечего исправлять, нечего отслеживать и т. д. Поскольку такие проблемы остаются незамеченными, к ним следует относиться еще более осторожно, поскольку они, скорее всего, не будут исправлены. Поэтому платформа !CVE - это далеко не развилка, но она раскрывает проблемы безопасности, которые в противном случае останутся скрытыми для большинства из нас. Также платформа признает усилия исследователей безопасности, отдавая им заслуженное должное.

Моя личная практика это тоже подтверждает: разработчики Hyperledger Fabric всячески отказываются называть найденную мной проблему уязвимостью (CVE-2024-45244). И даже предлагали мне самому отозвать CVE (а когда я отказался - пытались оспорить назначение CVE, но безуспешно). Более того, проблему исправили в версии 3.0.0 (см. поиск по тексту "TimeWindowCheck" в описании релиза 3.0.0) - вышла 20.09.2024. И не хотят исправлять в ветке 2.5.х (в которой продолжается выпуск новых версий после 20.09.2024). В связи с чем описание CVE-2024-45244 (в части уязвимых версий) сейчас не актуально.

Возможно, и я обращусь к NotCVE по нескольким потенциальным проблемам:

• IBM отказался признавать уязвимость в Instana, о которой я им сообщил на днях (подробностей пока сообщать не буду - как раз уточняю точно ли они не будут заводить CVE);

• MITRE назначила CVE (CVE-2024-57695) найденной мной уязвимости 13-летней давности (сообщил им лишь в декабре 2024) ещё в январе 2025. Но, статус до сих пор RESERVED (подробнее об этом статусе);

• Docker отказался присваивать CVE (эту уязвимость нашёл не я, но я не смог пройти мимо и обратился в MITRE).

P.S. По такому случаю сделал ключевое слово "не бага а фича" - надеюсь, в дальнейшем по этому выражению на Хабре станет проще находить соотвествующие статьи\посты.

Тяжела и неказиста жизнь простого программиста статических анализаторов кода

Команда PVS-Studio, содействуя разработке методики испытаний статических анализаторов под руководством ФСТЭК, составляла некоторые синтетические тесты. Писать синтетические тесты сложнее, чем кажется, и с их достоверностью всегда масса нюансов. Я никогда не любил синтетические тесты и продолжаю их не любить. Но что делать, они тоже нужны, когда речь заходит о необходимости подтвердить, что в анализаторах реализован определённый набор технологий.

Даже зная и понимая нюансы составления синтетических тестов, мы всё равно наступили на собственные грабли! Переиграли сами себя :)

Есть составленные нами тесты, в которых в функцию srand или её аналог передаётся константное значение. Это приводит к тому, что функция rand каждый раз будет генерировать одинаковую последовательность псевдослучайных чисел. Такой код, согласно ГОСТ Р 71207-2024, п. 6.3.г, может являться ошибкой некорректного использования системных процедур и интерфейсов, связанных с обеспечением информационной безопасности (шифрования, разграничения доступа и пр.).

Когда тесты подготавливались в Compiler Explorer, всё работало: PVS-Studio выдавал предупреждение V1057. А сейчас, когда код мило и скромно лежит в файлах, не работает. На Compiler Explorer работает, а вне — нет. Магия. Уже собрались баг в анализаторе искать.

Ах нет, всё просто. Файлы с тестами называются test_err_*.cpp. И в детекторе срабатывает исключение N4: "Находимся в файле, содержащем в названии слова check/test/bench". Тьфу. Причём получается, что анализатор прав: это действительно тест, а не настоящий баг :) Вот оно, несовпадение реальности и синтетических проверок в действии. Выкрутимся как-нибудь, но решил описать, так как случай интересный.

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

При экспертизе коллекции проектов стало ясно, что если это файлы с тестами, то писать srand(константа) абсолютно нормально. Более того, так специально делают, чтобы тесты вели себя повторяемо от запуска к запуску. Вот и было принято решение сделать соответствующее исключение. Теоретически это может скрыть реальную ошибку, но на практике в большой коллекции проектов, на котором мы прогоняем новые диагностические правила, такого не было. Зато в юнит-тестах этих проектов такое встречалось часто, и, соответственно, предупреждение оказывалось бессмысленным.

Был рад поведать немного интересного из жизни разработчиков статических анализаторов кода. А если хочется послушать что-то ещё, приглашаю на подкаст "Статический анализ по серьёзному" с моим участием 27 мая в 19:00 по Москве.

ИБ-дайджест InfoWatch

Хакеры стали жертвами взлома

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

Кибератака на металлургов

Производитель стали Nucor после инцидента ИБ пытается восстановить коммуникационную инфраструктуру и производственные процессы на нескольких предприятиях.

Департамент эффективности США слил данные

В результате заражения компьютера сотрудника были похищены ПДн и сведения о деятельности DOGE — злоумышленники также выложили их в сеть через базы программ-инфостилеров.

Инженеру грозит тюрьма за кражу информации

Программист из США приговорен к 1 году и 1 дню тюремного заключения за кражу запатентованной технологии своего бывшего работодателя.

Также он выплатит $14 тыс. штрафа и возместит ущерб в $18 тыс.

Worldcoin обязали удалить биометрию

Высший суда Кении предписал проекту биометрической криптовалюты Worldcoin Foundation за неделю удалить биометрические ПДн кенийцев, поскольку их собирали без оценки воздействия на защиту ПДн.

Anonymous украли данные по депортации

Хактивисты взломали GlobalX Airlines и завладели информацией о лицах, которые были депортированы из США — а также устроили дефейс веб-страницы авиакомпании и слили часть данных журналистам.

Clearview AI повторно оштрафовали за биометрию

Компания продолжает получать штрафы в Евросоюзе за незаконный сбор биометрических ПДн и неоднократное нарушение регламента GDPR —  в Соединенном Королевстве (около $10 млн), Франции ($22 млн), Нидерландах ($32 млн), Италии ($22 млн) и других государствах Европы.

Крупная утечка из британского ритейлера

Хакеры из DragonForce требуют выкуп за украденные данные 20 млн клиентов британского ритейлера Co-op.

Как искать ролики на YouTube по локации?

Недавно наткнулся на древнюю, но любопытную Google-таблицу с подборкой OSINT-инструментов.

Сразу привлёк внимание инструмент для поиска YouTube-видео по координатам: YouTube Geofind

Где может пригодиться?

1️⃣ Проверка достоверности информации
Если из одной локации поступают противоречивые данные, можно найти все видео с этого места и сравнить их.
2️⃣ Расследования и журналистика
Установление места съёмки: если видео якобы снято в Сирии, а координаты ведут в другую страну — это повод усомниться.
Поиск свидетелей: можно найти ролики, снятые рядом с местом события, и посмотреть, кто там был.
3️⃣ Кибербезопасность
Выявление фейков, где одно и то же видео выдают за съёмки из разных мест.
4️⃣ Краеведение
Анализ изменений локации: стройки, разрушения, природные катаклизмы — можно сравнить, как место выглядело раньше и сейчас.

Главный недостаток
➖Не у всех видео есть привязка к геолокации (не вина инструмента)

Как сделать свой Youtube Geofind?
Ключевой принцип работы инструмента прост и завязан на YouTube API (документация).

Чтобы найти видео по координатам, достаточно одного запроса:
https://www.googleapis.com/youtube/v3/search?part=snippet&type=video&location={latitude}2C{longitude}&locationRadius={radius}&publishedAfter={publishedAfter}&key={API_KEY}
Где:
— latitude и longitude - широта и долгота;
— radius - радиус
— publishedAfter - значение даты и времени в формате RFC 3339 (1970-01-01T00:00:00Z), которое указывает, что ответ API должен содержать только видео, созданные в указанное время или после него
— API_KEY - ваш API-ключ, который можно получить через Google Console

Пример запроса (все видео в радиусе 200 м от Красной площади, опубликованные после 00:00 9 мая 2025 года):
https://www.googleapis.com/youtube/v3/search?part=snippet&type=video&location=55.7539%2C37.6208&locationRadius=200m&publishedAfter=2025-05-09T00:00:00Z&key=<ваш API-ключ>

В ответ получаем JSON с найденными видео (пример на прилагаемом к посту скриншоте).
Метод поддерживает и другие параметры — подробнее в официальной документации.

Заключение
Важно помнить, что любые инструменты — лишь вспомогательные средства. Не стоит забывать о критическом мышлении и перекрёстной проверке.

Больше контента в моем авторском telegram-канале: https://t.me/ru_vm (BritLab)

Говорят, что врага надо знать в лицо!

Вот и мы решили посмотреть, какие веб-атаки чаще всего отражала наша платформа «Вебмониторэкс» с начала этого года.

Оказалось, что большая часть (40%) – это межсайтовый скриптинг (XSS), доля которого за год значительно выросла. А значит, злоумышленники нацелились не только на владельцев, но и на пользователей веб-ресурсов.

Как много данных о себе мы вводим в форму на каком-нибудь сайте заказа билетов, онлайн-магазина или клиники! А учетка админа корпоративной сети – это вообще джекпот!

Наша аналитика об атаках на веб-приложения легла в основу статьи газеты «Коммерсант».

Приглашаем на вебинар, посвященный последним обновлениям IVA MCU — ведущей платформы видеоконференцсвязи на российском рынке*

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

Спикеры

• Дмитрий Журавлев, директор по продукту IVA MCU

• Дмитрий Чугунов, руководитель управления поддержки продаж

Что вас ждет

• Обзор ключевых функций новой версии IVA MCU

• Экскурс: как мы обеспечиваем безопасность платформы

• Примеры успешного внедрения

• Дорожная карта развития на 2025 год

• Ответы на вопросы

Зарегистрироваться прямо сейчас.

 _{*По данным CNews Analytics: Крупнейшие поставщики решений для видеоконференцсвязи 2023.}

Задача о поиске флага в журналах системы

Несложная задача с CTF-турнира. Будет интересна всем, кто интересуется информационной безопасностью.

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

Однажды ваши коллеги рассказали, что где-то на странице журнала находится флаг. Но вот где именно — не раскрыли. Попробуйте найти этот флаг без подсказок коллег.

Задача
Найдите флаг — строку в формате slcctf{}. Чтобы выполнить задание, перейдите на страницу http://findme.slcctf.fun/.

Делитесь своим решением в комментариях. А правильный ответ можно посмотреть в Академии Selectel.

Утечка системного промпта Claude 3.5 Sonnet: что произошло

TL;DR: прозмоьла утечка системного промпта Claude 3.5 Sonnet.

Недавно в открытом доступе на GitHub появился файл с системным промптом модели Claude 3.5 Sonnet от Anthropic. В этой заметке мы подробно разберём, что именно было обнародовано, как устроен промпт и какие риски несёт его утечка.

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

• Источник:

  https://raw.githubusercontent.com/asgeirtj/system_prompts_leaks/refs/heads/main/claude.txt

• Содержимое:

  • Описания «артефактов» (artifacts) — самостоятельных блоков контента (отчёты, письма, презентации).

  • Правила запуска «структурированного мышления» в тегах <antthinking>.

  • Шаблоны и условия фильтрации: когда создавать артефакт и когда отвечать простым текстом.

  • Ограничения по объёму и форматированию, а также рекомендации по стилю.

Небольшой анализ этой утечки:

1. Артефакты
   Системный промпт описывает «артефакты» — XML-подобные блоки (отчёты, письма), которые модель генерирует для структурированного редактирования.

2. Структурированное мышление
   Перед формированием сложных ответов включаются теги <antthinking>, задающие пошаговый алгоритм анализа запроса и выбора формата вывода.

3. Фильтрация и объём
   Короткие ответы (1–2 предложения) выдаются без артефактов; при этом заданы жёсткие лимиты на размер и глубину артефактов во избежание «раздувания» текста.

4. Режимы и модерация
   Включены автоматические режимы генерации (быстрый ответ, развёрнутый отчёт) и встроенные фильтры для блокировки нежелательного контента и внутренней информации.

На всякий случай, файл с GitHub'a залил в облако и Web archive, чтобы точно не потерять :). Хотя сам, честно говоря, до сегодняшнего дня но разу не пользовался данной моделью, теперь есть повод поэкспериментировать.

PS. Это мой первый пост, друзья, так что, если найдёте какие-либо недочёты, пожалуйста, укажите на них!

Утечка системного промпта Claude 3.5 Sonnet: что произошло

TL;DR: произошла утечка системного промпта Claude 3.5 Sonnet.

Недавно в открытом доступе на GitHub появился файл с системным промптом модели Claude 3.5 Sonnet от Anthropic. В этой заметке мы подробно разберём, что именно было обнародовано, как устроен промпт и какие риски несёт его утечка.

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

• Оригинальный файл:

  https://raw.githubusercontent.com/asgeirtj/system_prompts_leaks/refs/heads/main/claude.txt

• Содержимое:

  • Описания «артефактов» (artifacts) — самостоятельных блоков контента (отчёты, письма, презентации).

  • Правила запуска «структурированного мышления» в тегах <antthinking>.

  • Шаблоны и условия фильтрации: когда создавать артефакт и когда отвечать простым текстом.

  • Ограничения по объёму и форматированию, а также рекомендации по стилю.

Небольшой анализ этой утечки:

1. Артефакты
   Системный промпт описывает «артефакты» — XML-подобные блоки (отчёты, письма), которые модель генерирует для структурированного редактирования.

2. Структурированное мышление
   Перед формированием сложных ответов включаются теги <antthinking>, задающие пошаговый алгоритм анализа запроса и выбора формата вывода.

3. Фильтрация и объём
   Короткие ответы (1–2 предложения) выдаются без артефактов; при этом заданы жёсткие лимиты на размер и глубину артефактов во избежание «раздувания» текста.

4. Режимы и модерация
   Включены автоматические режимы генерации (быстрый ответ, развёрнутый отчёт) и встроенные фильтры для блокировки нежелательного контента и внутренней информации.

На всякий случай, файл с GitHub'a залил в облакo [ Upd: администрация Telebox, как выяснилось, имеет доступ ко всем файлам, даже беспарольным архивам, и уже дважды удалила файл] и Web archive [здесь файл жив и здоров], чтобы у каждого была возможность покопаться в недрах этого конфига. Честно говоря, до сегодняшнего дня ни разу не пользовался данной моделью от Anthropic, теперь есть повод поэкспериментировать :).

PS. Это мой первый пост, друзья, так что, если найдёте какие-либо недочёты, пожалуйста, укажите на них!

Продолжая тему взаимодействия с MITRE насчёт CVE. В прошлый раз я обращался к MITRE из-за нежелания вендора Docker создавать CVE. Теперь же я попытался внести уточнение к существующей записи CVE-2018-14847, описание которой не слишком точное:

MikroTik RouterOS through 6.42 allows unauthenticated remote attackers to read arbitrary files and remote authenticated attackers to write arbitrary files due to a directory traversal vulnerability in the WinBox interface.

По такому описанию можно подумать, что уязвимы абсолютно все версии ниже 6.42. На самом деле это не так. Более точное описание есть у вендора MikroTik:

Versions affected:

• Affected all bugfix releases from 6.30.1 to 6.40.7, fixed in 6.40.8 on 2018-Apr-23

• Affected all current releases from 6.29 to 6.42, fixed in 6.42.1 on 2018-Apr-23

• Affected all RC releases from 6.29rc1 to 6.43rc3, fixed in 6.43rc4 on on 2018-Apr-23

Но, и оно не совсем правдивое. Как минимум версия 6.28 уязвима (проверял используя этот эксплоит). Я обратился в MITRE через эту форму (выбрал "Request an update to an existing CVE Entry"), объяснив всё это. В итоге MITRE лишь добавили ссылку на описание уязвимости от вендора (обновление от 28.04.2025). Это в очередной раз подтверждает, что при оценке угроз не стоит полностью полагаться ни на CVE, ни на информацию от вендора. О чём говорю не только я. Был у меня личный опыт, показывающий неточность в описании уязвимых версий со стороны вендора: Cisco UCS Manager. А если пытаться смотреть на CVE, указанные вендором по этой проблеме - так каши в голове становится лишь больше: в CVE речь о версиях bash (а какая версия bash в какой прошивке и оборудовании есть - в CVE не указывается).

ГОСТ Р 56939-2024 – Разработка безопасного программного обеспечения (РБПО)

20 декабря 2024 года введён ГОСТ Р 56939-2024 взамен ГОСТ Р 56939—2016. Хотя уже прошло около полугода, не все про это знают, осознают это или как-то подстраиваются под произошедшие изменения :) А изменения есть, так как новый ГОСТ ориентирован на построение и контроль процессов, обеспечивающих цикл безопасной разработки в компании.

Несколько информационных моментов.

1. Цикл публикаций в моём канале "Бестиарий программирования" на тему РБПО

Я начинаю большой цикл публикаций в Telegram, посвящённый РБПО и ГОСТ Р 56939-2024. Приглашаю подписываться всех, кто хочет постепенно знакомиться с этой темой и разбираться в ней.

2. Вебинары РБПО-направленности

Мы уже провели совместно с другими компаниями два вебинара, связанных с ГОСТ Р 56939-2024:

1. Интеграция статического анализа и DevSecOps: PVS-Studio и AppSec.Hub в действии.

2. Внедрение процессов безопасной разработки. Интеграция PVS-Studio и SGRC SECURITM.

Приглашаем принять участие в следующем совместном с "ИНСЕК" вебинаре "Регулярный статический анализ по ГОСТу" (21 мая 12:00 по Москве), где они презентуют InSeq RBPO.

Приглашаем и другие компании к технологическому и/или информационному сотрудничеству. Напишите нам в поддержку или моему ассистенту.

3. Сертификация ФСТЭК

В последнее время нас спрашивают, подходит ли PVS-Studio для сертификации, и есть ли у нас сертификат ФСТЭК?

Для PVS-Studio нет сертификата ФСТЭК, так как он не нужен (для статических анализаторов процедура сертификации является добровольной).

PVS-Studio может использоваться как инструментальное средство статического анализа кода при построении процессов РБПО по ГОСТ Р 56939-2024.

PVS-Studio успешно применяется испытательными лабораториями, аккредитованными в системах сертификации средств защиты информации ФСТЭК России в рамках работ по сертификационным испытаниям программных продуктов, так как соответствует необходимым критериям (для заказчиков и сертификационных лабораторий мы подготовили информационное письмо):

• PVS-Studio включён в Реестр российского ПО (запись № 9837 от 18.03.2021);

• PVS-Studio удовлетворяет функциональным требованиям к инструментам статического анализа кода, описанным в Методическом документе "Методика выявления уязвимостей и недекларированных возможностей в программном обеспечении" (издание второе, доработанное, утверждён ФСТЭК России 25 декабря 2020 г.);

• продукт разрабатывается с учётом требований, предъявляемых к статическим анализаторам в ГОСТ Р 71207–2024.

Подробнее: Сертификация ФСТЭК. Если у вас есть вопросы, напишите нам в поддержку или позвоните по телефону +7(903)844-02-22.

В феврале 2025 вышел релиз Docker Engine 28.0.0, устранивший проблемы безопасности:

Fix a security issue that was allowing remote hosts to connect directly to a container on its published ports. moby/moby#49325
Fix a security issue that was allowing neighbor hosts to connect to ports mapped on a loopback address. moby/moby#49325

В официальном блоге вышла статья с подробностями проблемы и возможными сценариями атак. Но, CVE заводить разработчики не захотели. Я не знаю какими принципами руководствовались разаботчики. По мне слова "Fix a security issue" тождественны созданию CVE. Я обратился в MITRE с описанием ситуации через эту форму (выбрал Request type - other). И получил такой ответ:

Thanks for the submission. We will treat this as a dispute/escalation request and reach out to Docker next. Hopefully that will spur them on to assign (it often does) but if not, we will take a look at assignment. 

Once we hear back we'll let you know if they changed their mind and decided to assign or what the next steps will be.

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

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

Личный кабинет налогоплательщика, или как потерять доступ, если бы не длинный буфер обмена Windows 11

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

1. Входим в ЛК.

2. Нажимаем "Изменить пароль" в настройках профиля.

3. Генерируем пароль сторонним сервисом, назовем его "Пароль 1".

4. Вводим пароль, сохраняем.

5. Вдруг система говорит, что в пароле нет цифр!..

6. Хорошо, генерируем новый пароль, с цифрами.

7. Вводим новый пароль... О-па, а в поле "Старый пароль" уже неверный пароль.

8. Нервно ищем Пароль 1. Оказывается, что он применился, несмотря на ругань системы. Если не нашли, то всё... Мне помог длинный буфер обмена Windows 11.

Шёл 21-й век.

Оплачиваемая стажировка Cloud.ru Camp — успей подать заявку до 12 мая 📢

Присоединяйся к Cloud.ru Camp — оплачиваемой стажерской программе, которая поможет студентам и начинающим специалистам прокачать скиллы и с головой погрузиться в IT-сферу. 

Ты можешь выбрать направления:

• Продуктовая разработка: DevOps или Golang.

• Кибербезопасность: мониторинг событий и автоматизация или сертификация программных продуктов.

• Команда внедрения: QA.

• Технические продажи: технический менеджер клиентов.

Что тебя ждет:

• оплачиваемая стажировка,

• работа в реальных проектах,

• поддержка наставников и экспертов,

• регулярная обратная связь.

А у лучших стажеров будет возможность попасть в штат Cloud․ru.

Прием заявок открыт до 16 мая включительно, а для прошедших все этапы отбора стажировка начнется 16 июня. Пройти стажировку можно очно в офисе Cloud.ru в Москве, а также удаленно из любой точки РФ. График гибкий — от 20 часов в неделю.

📬 Подать заявку на Cloud.ru Camp

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

У пенсионера из США c помощью социальной инженерии украли 3520 биткойнов на $330 миллионов. Мошенники потом кучу раз дробили сумму и отмыли её через 300 кошельков и 20 бирж. Большую часть денег вообще перевели в XMR — монету, которую трудно отследить. Эксперты говорят, что вернуть эти криптоактивы пострадавшему невозможно.

ИБ-дайджест InfoWatch

Утечка данных оператора связи
Телекоммуникационная компания MTN Group сообщила об утечке ПДн абонентов, подчеркнув, что это не повлияло на работу ее сети.

Кибератака на телеком-оператора
Корейский оператор SK Telecom расследует хакерский взлом — злоумышленники использовали вредоносное ПО и завладели ПДн клиентов.

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

Форум безопасного Интернета
На «XIV Форуме безопасного Интернета» рассказали про архитектуру мошенничества и противодействие подобным манипуляциям в докладе «Как активировать психологическую защиту пользователей».

Нейронные сети в руках хакеров

Как вам такой сценарий. Некоторая группа специалистов по информационной безопасности (в плохом смысле) создаёт публичный сайт-прокси который рекламируется как бесплатное решение всех проблем программиста.

Когда программист делает запрос на генерацию кода скажем бекенда для веб сервера его запрос проксируется в ChatGPT, а потом модифицируется скриптом, который добавляет небезопасный код.

Попутно сайт собирает информацию о самом программисте, например, IP адрес, а в случае регистрации - email работодателя.

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

Телеграм, дай возможность отозвать заявки в группы! Это же базовый функционал!

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

История банальна до смешного. Вечер, пишет какой-то аккаунт, кидает ссылку на группу "взаимной подписки". Мозг отключен, палец машинально жмет "Подать заявку". Через час доходит – зачем мне это? Лезу в диалог, а приглашение уже удалено. Название группы? Не помню. Ссылка? Потеряна.

И тут начинается паранойя. А что, если это была какая-то мутная группа? Что, если ее завтра переименуют во что-то совершенно неприемлемое? А я там буду висеть в "кандидатах на вступление", и отозвать заявку НЕ МОГУ, потому что я ее тупо не вижу!

Я перерыл все настройки – бесполезно. Telegram не показывает список твоих активных, еще не одобренных заявок. Ты просто сидишь и надеешься, что пронесет, или что админ той самой группы (которую ты даже не помнишь) отклонит твой запрос.

В моем случае все разрешилось относительно мирно. Через пару дней меня приняли в очередной канал про "успешный успех". Фух, пронесло.

Но сама ситуация – дичь! Почему я не могу контролировать, куда я "постучался"? Почему нельзя посмотреть список своих ожидающих заявок и отменить ненужные? Это же базовая гигиена цифровой безопасности и просто здравый смысл!

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

Кто-нибудь еще сталкивался с такой проблемой?

Как автоматизировать распознавание текста с изображений?

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

Раньше в моём арсенале был только pytesseract (Python-библиотека для распознавания текста). Она работала, но с серьёзными ограничениями:
➖Плохо справлялась с разными шрифтами
➖Теряла точность на низкокачественных изображениях
➖Путала языки, если текст был мультиязычным

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

В профильных каналах регулярно пишут: «Вышла модель Х, которая показывает отличные результаты. OSINT-еры больше не нужны!», но никто не дает гайдов, как с этими моделями работать. Сегодня я это исправлю.

Обзор моделей для OCR
Прошерстив не один десяток источников, я выделил две наиболее популярные на текущий момент модели:
1️⃣ GPT-4 mini — высокая точность, но платная.
2️⃣ Google Gemini 2.0 Flash — высокая точность + бесплатный лимит.

Выбор без раздумий пал на Gemini. На момент публикации бесплатные лимиты от Google следующие:
✔️ 15 запросов в минуту
✔️ 1 млн токенов в минуту (ввод + вывод)
✔️ 1 500 запросов в сутки

Как взаимодействовать с Gemini?
1️⃣ Получаем API-ключ в Google AI Studio
2️⃣ Через API отправляем изображение в base64 + промпт
3️⃣ Получаем распознанный текст в ответе

Но есть важный нюанс: сервис не работает с российскими IP

Что делать, если Gemini недоступна?
Если у вас по какой-то причине нет возможности получить доступ к серверам Google AI Studio, то можно воспользоваться сервисами, которые предоставляют доступ к различным open-source моделям. Например, DeepInfra.
Плюсы:
✔️ Нет блокировок по геолокации
✔️ Гибкая тарификация
Минусы:
✖️ Нет бесплатного тарифа

Примеры скриптов выложил на github (https://github.com/vmtest439/britalb_ocr)

Если вам понравился пост и вы хотите читать больше подобного контента, то можете подписаться на мой авторский Telegram-канал BritLab!

container-tools

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

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

Конечно, есть и другие инструменты, например cosign, которые тоже полезны, особенно в облачных средах. Но GPG остаётся надёжным базовым решением, которое работает везде и не требует дополнительной настройки. Проще говоря, это как печать на документе: если её нет, вы не можете быть уверены, что всё чисто.

Как это делать с помощью container-tools

container-tools % make

Usage: make <target>

  help               - Display this help message
  all                - Build all Debian images
  check-dependencies - Verify required tools are installed
  clean              - Remove all build artifacts and downloads
  list-vars          - List all Makefile variables and their origins
  shellcheck         - Validate all bash scripts
  package   	     - Create tar.gz archive of the directory
  release            - Create Git tag and GitHub release
  archive            - Create git archive of HEAD
  bundle             - Create git bundle of repository

 ============================
  ** Debian Linux targets **
 ============================

|all|

|debian11|
|debian11-java|
|debian11-java-slim|
|debian11-corretto|
|debian11-graal|
|debian11-graal-slim|
|debian11-java-slim-maven|
|debian11-java-slim-gradle|
|debian11-graal-slim-maven|
|debian11-graal-slim-gradle|

|debian11-java-kafka|
|debian11-java-slim-kafka|

|debian11-nodejs-23.11.0|

|debian11-python-3.9.18|

Собираем базовый образ для NodeJS

make debian11-nodejs-23.11.0

После завершения сборки:

[Image was built successfully]
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

Artifact location: /srv/container-tools/debian/dist/debian11-nodejs-23.11.0/debian11-nodejs-23.11.0.tar

Artifact size: 93M

Для подписи используем gpg.py в составе container-tools:

./scripts/gpg.py --directory /srv/container-tools/debian/dist/debian11-nodejs-23.11.0/debian11-nodejs-23.11.0.tar --gpg-key-id 4795A07D0372203EFDDA0BF0C465AD00090932DB
2025-04-25 13:39:41,269 [INFO] Signing tarball: /srv/container-tools/debian/dist/debian11-nodejs-23.11.0/debian11-nodejs-23.11.0.tar -> Signature: /srv/container-tools/debian/dist/debian11-nodejs-23.11.0/debian11-nodejs-23.11.0.tar.asc
2025-04-25 13:39:41,752 [INFO] Successfully signed tarball: /srv/container-tools/debian/dist/debian11-nodejs-23.11.0/debian11-nodejs-23.11.0.tar
2025-04-25 13:39:41,752 [INFO] Signature saved to: /srv/container-tools/debian/dist/debian11-nodejs-23.11.0/debian11-nodejs-23.11.0.tar.asc
2025-04-25 13:39:41,752 [INFO] All tarballs have been processed successfully.

Подтверждаем:

./scripts/gpg.py --directory /srv/container-tools/debian/dist/debian11-nodejs-23.11.0/debian11-nodejs-23.11.0.tar --gpg-key-id 4795A07D0372203EFDDA0BF0C465AD00090932DB --verify
2025-04-25 13:40:19,734 [INFO] Verifying tarball: /srv/container-tools/debian/dist/debian11-nodejs-23.11.0/debian11-nodejs-23.11.0.tar against signature: /srv/container-tools/debian/dist/debian11-nodejs-23.11.0/debian11-nodejs-23.11.0.tar.asc
2025-04-25 13:40:20,192 [INFO] Verification successful: /srv/container-tools/debian/dist/debian11-nodejs-23.11.0/debian11-nodejs-23.11.0.tar
2025-04-25 13:40:20,193 [INFO] All tarballs have bee

Время уходит — компаниям до 30 мая следует сообщить в РКН об утечках данных

Скоро в России вступят в силу новые законодательные требования по обороту ПДн. Вчера в ТАСС состоялась посвященная этой теме пресс-конференция. Модератором и участником стала Наталья Касперская, президент ГК InfoWatch.

Главные тезисы:

• Наталья Касперская: утечки ПДн затрагивают не только бизнес, но и всех граждан. Они — причина успеха кибермошенников, которые используют достоверную информацию о людях для обмана.

• Михаил Смирнов (эксперт и главный редактор BISA): масштабы проблемы утечек данных не осознаны и недооценены. Объем скомпрометированных ПДн растет — в 2024 году из российских компаний утекло 1,5 млрд записей ПДн.

• Милош Вагнер (замруководител РКН): у компаний до 30 мая есть время, чтобы проинформировать уполномоченные органы о произошедших ранее инцидентах. И тогда к ним будут применяться текущие меры ответственности, а не более строгие.

Подробнее — на сайте InfoWatch.

Безопасная разработка API на практике

Как устроен ваш цикл разработки приложений? Проверяются ли API на наличие уязвимостей до их публикации? И есть ли вообще для этого процесса какая-то методология?

Вместе с экспертом команды Вебмониторэкс, участвующим в совместной работе с ИСП РАН, подробно разберём, как выстроить эффективный процесс тестирования API, и чем отличаются различные его виды.

Когда? 23 апреля в 14:00

Спикер: Динко Димитров, руководитель продуктового направления, Вебмониторэкс

Зарегистрироваться на мероприятие 

Ждем вас на вебинаре!

Leaquor.jl: Secret Scanning with Julia

Доверяем, но проверяем

Если делать веб-приложение вроде SonarQube, то не мешало бы разделить образности на бэкенде:

1. Выделить сканер секретов в одтельную программу на Go. Это worker.

2. Сервис FastAPI предоставляет JSON API, клонирует репозиторий Git и возвращает результаты сканирования для фронтенда в JSON. Это сервис.

3. На бэк отправляется запрос REST API, который передает URL репозитория для сканирования:

curl -X POST "http://I<IPADDRESS>:8000/scan-secrets" -H "Content-Type: application/json" -d '{"repo_url": "https://github.com/Plazmaz/leaky-repo"}' | jq .

К чему это я все? DevOps инструментарий – это полный шлак. На попытку заставить на бэке работать эту чудо-поделку под названием GitLeaks, ушло больше времени чем на то, чтобы переписать ее с нуля, добавив еще и возможность кастомизировать паттерны для проверки.

Leaquor.jl: Secret Scanning with Julia

Большинство инструментов для поиска секретов в Git-репозиториях страдают от одной серьёзной проблемы: их JSON-вывод часто кривой или трудночитаемый, что усложняет автоматизацию. Они неплохо находят утечки, но попытка использовать их вывод в CI-пайплайне или бэкенд-сервисе обычно превращается в борьбу с битыми данными или написание кастомных парсеров.

Поэтому я написал лёгкий инструмент на Julia, который делает две вещи правильно: выдаёт чистый, валидный JSON и позволяет задавать собственные правила поиска через YAML-конфиг. Никакой возни с кривым выводом или жёстко зашитыми правилами — только структурированные результаты, которые действительно работают в автоматизированных процессах.

Цитату из Библии нашли в блоке №666 666 в блокчейне Bitcoin: «Не будь побеждён злом, но побеждай зло добром» — Римлянам 12:21.

Коллеги, если вы знаете, что такое TAP и SPAN, вам не безразличны вопросы зеркалирования и оптимизации сетевого трафика, а ещё хочется узнать, как в этом помогают брокеры сетевых пакетов, то 23 апреля мы ждем вас на техническом вебинаре, где мы подробно обсудим эти темы. А ещё помимо слайдов с картинками будет живая демонстрация работы ответвителей трафика DS TAP и пакетных брокеров DS Integrity в связке c системой анализа сетевого трафика PT NAD.

Зарегистрироваться нужно тут, присоединяйтесь!

Когда тема ИБ вышла за пределы профессиональной аудитории и попала в федеральные СМИ, мы не можем пройти мимо. А когда речь идёт ещё и об одной из самых удобных баз уязвимостей, мы просто обязаны вставить свои 5 копеек.

Итак, представим, что с финансированием CVE всё будет плохо и российские пользователи перестанут получать информацию об актуальных уязвимостях. Руководитель технического центра «АйТи Бастион» Владимир Алтухов видит в этом ещё один шаг в направлении антиглобализации мира ИБ. Универсальный для всех специалистов на планете инструмент исчезает, поэтому возникает необходимость пользоваться чем-то своим.

Не стоит радоваться тому, что не надо будет закрывать какую-то Цэ-Вэ-Ешку – обязательно придётся закрыть очередную БДУшку!

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

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

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

✅ Соблюдать принцип Zero Trust.

✅ Отдавать предпочтение зрелым продуктам ИБ с подтверждённым уровнем доверия и на сертифицированных ОС.

Как известно, основной глобальный инструмент для просмотра логов Certificate Transparency (CT-логов) через веб-интерфейс - это crt.sh. Однако сертификаты российских УЦ в глобальные логи пока не попадают (перечень принимаемых сертификатов и пресертификатов в CT-логе всегда ограничен некоторым набором корневых ключей). Для российских УЦ запущены российские CT-логи. Для просмотра российских CT-логов тоже есть сервисы с веб-интерфейсом:

• ct.tlscc.ru - это выделенный экземпляр crt.sh, поддерживаемый ТЦИ и настроенный на российские логи; веб-сайт использует TLS-сертификат, выпущенный от корня ТЦИ, так что если корня в браузере нет, то будет выдаваться предупреждение; (пример запроса);

• precert.ru - отдельный и весьма удобный сервис, имеющий целый ряд преимуществ: например, здесь другой интерфейс для поиска записей, подробная статистика по логам и УЦ; (пример запроса).

Сейчас в российские CT-логи добавляются сведения о сертификатах, выпускаемых НУЦ (все логи) и ТЦИ (логи "Яндекса" и VK). Основной объём логов составляют пресертификаты, которые добавляют сами УЦ, в процессе выпуска сертификата. Пресертификат отличается от сертификата наличием специального расширения (CT Poison), отсутствием SCT-меток и значением подписи. Обратите внимание, что сертификаты добавить в CT-лог может каждый. Например, можно добавить сертификат, найденный на каком-то веб-узле в Сети (если, конечно, сертификат выпущен подходящим УЦ). Но для добавления придётся уже воспользоваться HTTP-интерфейсом соответствующего лога напрямую, подготовив и отправив POST-запрос.

Зачем просматривать CT-логи? Во-первых, наличие сторон, изучающих записи в CT-логах, это основной декларируемый смысл Certificate Transparency. Во-вторых, просмотр логов позволяет пронаблюдать, что и для чего выпускается, и даже минимально контролировать выпуск сертификатов для тех доменов, которые вы администрируете; Certificate Transparency не гарантирует, что сведения о выпущенном сертификате будут в CT-логе, но такие сведения могут там быть, а сам по себе сертификат, благодаря наличию цифровой подписи, это какой-никакой, но документ, подтверждающий хотя бы свой собственный выпуск. В-третьих, в логах можно найти что-то неожиданное - для этого внимание нужно обращать на таймстемпы, на формат (пре)сертификатов, на состояние конкретных лог-сервисов.

Как я едва не стал жертвой мошенников с помощью Zoom-схемы

Хочу поделиться историей, которая произошла буквально час назад — всё выглядело настолько реалистично, что я по-настоящему поверил, что это обычное собеседование. Но в итоге это оказался тонко продуманный скам, и я чудом не попался.

Всё началось с приглашения на интервью

Мне написал человек в Telegram под ником @AlexImmerman. Он представился сотрудником компании xLabs, объяснил, что им нужен человек с моими навыками, и пригласил на Zoom-интервью. Меня немного смутило, почему он пишет через Telegram, а не через LinkedIn, но он удачно соврал, что меня ему порекомендовали ребята из одного криптопроекта, с которым я недавно работал — и я успокоился.

Мы даже несколько раз переносили встречу — это добавляло реалистичности. Он вёл себя профессионально, попросил ссылку на мой профиль в LinkedIn и актуальное резюме.

Всё выглядело привычно и по делу. И вот сегодня наконец состоялось интервью.

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

Он заранее предупредил, что интервью будет состоять из двух этапов. После первой части он объяснил, что в соответствии с внутренней политикой компании они используют платформу willo.video, где я якобы должен пройти пару бизнес-сценариев, ответить на вопросы и заполнить анкету. Всё звучало логично — это ведь реальный сервис для видеособеседований.

Но тут он добавил:

“Чтобы тебе было проще, просто расшарь экран — я покажу тебе, куда нажимать и как всё быстро пройти.”

В этот момент у меня внутри сработал звоночек. Я вспомнил, что недавно читал про мошенничество через Zoom, и говорю: “Извини, но я бы не хотел делиться экраном — слышал, что бывают скам-сценарии через Zoom, и хотел бы сначала убедиться, что всё безопасно.”

Он ответил, что понимает мои опасения, добавил, что “сам в крипте уже 10 лет”, и похвалил мою бдительность. Затем предложил перенести вторую часть на завтра и использовать другой сервис — например, Google Meet.

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

Мы согласовали время и он тут же отключился... А спустя несколько минут я заметил, что вся переписка в Telegram была удалена. Даже жалобу не успел отправить. Вот так вот.

Что это было

Это был очень хорошо продуманный скам. И он бы сработал, если бы буквально вчера я не прочитал, что мошенники могут получить удалённый доступ через Zoom. Никаких “переведите деньги” или “установите программу” — всё выглядело на 100% натурально.

Что бы он сделал, если бы я расшарил экран — я, к счастью, так и не узнал. Но подозреваю, что мог попросить установить какое-нибудь “удобное приложение” или, пока я отойду“за каким-нибудь документом”, сам бы успел что-то скачать. Вариантов масса.

Выводы

Будьте осторожны! Не бойтесь быть подозрительным, задавать вопросы, просить подтверждение личности — например, через LinkedIn или корпоративный сайт. А ещё лучше — проходите онлайн-интервью на отдельном устройстве, где нет кошельков, логинов и приватной информации.

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

Пусть об этих схемах знают как можно больше людей. Берегите себя. И будьте бдительны.