Избранное про ИБ
СтатистикаНаиболее интересные новости ИБ, отобранные Сергеем Борисовым и несущие пользу для читателей
- Последний пост
- 29 июн.
- Последнее чтение
- 11:44
- Постов за неделю
- 0
- Всего постов
- 32
- Тип
- открытый
- Язык
- русский
- Категория
- Новости и СМИ
- В каталоге с
- 12 авг.
- 1/24сутки в ленте
- —
- 1/48двое суток
- —
- 1/72трое суток
- —
Оценка по просмотрам недавних постов: пост набирает почти всё за первые сутки.
Посты
без подписи
Telegram | MAX | ВКонтакте
Почему композиционный анализ (SCA) не гарантирует отсутствие вредоносного кода в frontend-приложении? В прошлый раз мы обсуждали, почему SAST не может обнаружить вредоносный код в frontend-приложениях. Сегодня рассмотрим SCA. 1️⃣ Современные js-фреймворки 📱 используют пакетный менеджер (npm). Все зависимости при билде упаковываются в файл-бандл (app.js, main.js и т.п.). Этот бандл подключается на веб-страницу в виде файлового скрипта. SCA-анализатору передается файл package.json/package-lock.json - по данному файлу SCA обнаружит зависимости, которые попадут в бандл. НО на веб-странице могут быть подключены и другие скрипты 👩💻. В следующем примере на странице размещен бандл (main.js) и еще 2 внешних и 2 инлайн-скрипта. О них SCA не знает. <html> <head> <script src="//metrics.ru/metrics.js"></script> <script src="//cdn.ru/module.js"></script> <script src="/js/main.js"></script> </head> <body onload='console.log("inline 1 script")'> <div id="root"></div> <script>console.log("inline 2 script")</script> </body> </html> 2️⃣ У вас в проекте нет внешних и инлайн-скриптов? А вы уверены? Проверяете? На аудитах безопасности мы иногда обнаруживаем даже скрипты Яндекс Метрики в проектах, которые должны работать в корп. сетях без интернета 😱. Поэтому одной уверенности здесь мало. 3️⃣ В некоторых компаниях SCA встроен только на этапе сканирования образов контейнеров 🖥. Для frontend-приложений это бессмысленно, т.к. из файла-бандла js невозможно восстановить зависимости (невозможно = SCA этим не занимается). Поэтому ваш Trivy покажет вам только уязвимости пакетов ОС, т.к. не найдет ни одной зависимости npm. Анализировать npm-зависимости необходимо только по исходному коду (package-lock.json). 4️⃣ В js есть возможность динамического импорта модулей / добавления на страницу новых скриптов в рантайме 🔎. Любая библиотека может загрузить новые скрипты со сторонних хостов. Код даже может быть спрятан в картинке/другом ресурсе и проинтерпретирован динамически через eval(). Если такое поведение библиотеки (НДВ) еще не засветилось и не попало в базы вредоносных пакетов вашего SCA, то вы об этом не узнаете. 6️⃣ Об актуальности базы вредоносных/уязвимых пакетов. Любая база пополняется с задержкой. Например в инциденте с вредоносным кодом в библиотеке polyfill.js информация попала в базы только через 4 месяца 😭. В более 100 000 приложений 4 месяца присутствовал вредоносный код 💰 7️⃣ В хороших SCA-анализаторах есть возможность подключения внешних фидов о вредоносных пакетах. А насколько хороша бесплатная база Trivy/Grype? 8️⃣ Если для популярных пакетов кто-то заметит вредоносное поведение и сообщит SCA-вендорам, то что говорить о редких пакетах /форках /внутренних библиотеках. Информация о них вообще никогда не появится в базах SCA. 9️⃣ Тег-менеджер (Google, Яндекс и другие). Прямое назначение тег-менеджеров - динамическое добавление на страницы новых скриптов по определенным условиям. SCA не видят это. 1️⃣0️⃣ Мы не знаем зависимости внешних/сторонних скриптов. Допустим скрипт системы аналитики, мы получаем его в виде минифицированного бандла, понять его зависимости также не получится. 1️⃣1️⃣ Можно ли считать код, написанный ИИ, сторонним opensource-кодом, а не собственным? 😄 1️⃣2️⃣ Разработчик может скопировать код сторонней библиотеки в проект/сделать форк, чтобы SCA не ругался. Но это отдельная история... Таким образом SCA-анализатор не может достоверно обнаружить все сторонние компоненты, используемые frontend-приложением, а для тех которые обнаружил полностью зависит от качества используемых баз/фидов. Применение SCA нейтрализует всего 3 из 75 угроз по фреймворку Frontend Kill Chain. Для безопасной разработки frontend-приложений применяются FAST-анализаторы, обнаруживающие вредоносные компоненты по поведению в рантайме браузера-песочницы 🌐 FAST обнаруживает все скрипты, даже динамически загруженные и добавленные через тег-менеджеры, и анализирует реальное поведение собственного, стороннего и сгенерированного ИИ кода. И все это без ложных срабатываний и регулярного триажа 🔎 @FrontSecOps
Безопасное использование пакетных менеджеров Всем привет! В марте 2026 года ENISA выпустила руководство «Technical Advisory for Secure Use of Package Managers», (~ 28 страниц), которое можно найти в приложении. В нём приводятся практики, позволяющие повысить уровень информационной безопасности при работе с пакетными менеджерами. Материал структурирован по разделам: 🍭 Solution architecture and data flows. Общее описание принципов работы пакетных менеджеров 🍭 Security risks in package consumption. Основная проблематика, с которой можно столкнуться (уязвимости, атаки на цепочку поставок и т.д.) 🍭 Best practices – secure package consumption. Рекомендации по безопасному использованию пакетных менеджеров Материал описывает общие рекомендации (т.е. отдельных рекомендаций для «конкретного» пакетного менеджера нет). Всё довольно лаконично, понятно и достаточно подробно описано для того, чтобы реализовать это у себя. Останется только понять «как именно» это можно сделать. Но здесь уникального ответа нет – каждый найдет свой собственный путь.
OWASP Vendor Evaluation Criteria for AI Red Teaming Providers & Tooling v1.0 https://genai.owasp.org/resource/owasp-vendor-evaluation-criteria-for-ai-red-teaming-providers-tooling-v1-0/
без подписи
без подписи
На портале Open Group можно найти набор стандартов "Security Roles and Glossary", призванный помочь построить зрелую системы кибербезопасности, основываясь на том, что кибербезопасность — это фундаментальный бизнес-риск, а каждый сотрудник, от топ-менеджера до рядового специалиста, должен понимать свою роль в защите компании. Набор состоит из четырех частей: 1️⃣В первом стандарте описана структура документов и приведен подробный глоссарий, который унифицирует ключевые термины, чтобы гарантировать, что бизнес, ИТ и ИБ-команды говорят на одном языке. 2️⃣Во втором документе даются рекомендации по имплементации ролей и обязанностей в структуру компании, опираясь на принцип, что кибербезопасность - это командный спорт. В стандарте вводится модель управления, разграничивающая "подотчетность", которая лежит на лицах, принимающих решения, и "ответственность", возлагаемую на экспертов. 3️⃣В третьем стандарте подробно расписываются роли и обязанности руководства. Особо подчеркивается, что кибербезопасность — неотъемлемая часть фидуциарной обязанности совета директоров и высшего руководства (CEO, CFO и т.д.). Они подотчетны за формирование культуры безопасности, утверждение стратегии и принятие окончательных решений по критическим вопросам. 4️⃣В четвертом документе детально расписаны роли, функции и обязанности команды SecOps/SOC (аналитики, менеджеры, инженеры, TI-специалисты и т.д.). Помимо подробно расписанных ролей, обязанностей и принципов построения системы управления, в стандартах описаны актуальные стратегические задачи для руководства: ➡️Выявление и подготовка к сбоям в работе бизнеса, вызванным кибератаками. ➡️Участие в симуляциях кибератак. ➡️Поддержка внедрения концепции Zero Trust. ➡️Поддержка квантово-безопасных инициатив. #framework #roles #glossary #secops #soc #management #bestpractices #standard #responsibilities
Wiz представила SITF (SDLC Infrastructure Threat Framework) — первую в мире открытую модель угроз, специально ориентированную на защиту инфраструктуры жизненного цикла разработки программного обеспечения. Эта инфраструктура (IDE, VCS, CI/CD, Registry) становится привлекательной целью для атак не только на код, но и на сами процессы сборки и доставки ПО. SITF предлагает визуализатор потоков атак, библиотеку из более чем 70 техник атак с привязкой к рискам и средствам защиты, а также причинно-следственное сопоставление. Это позволяет командам не просто фиксировать инциденты, а понимать и разрывать цепочки атак на ранних стадиях.
Предновогодний релиз DAF! С наступающим новым годом, друзья! Все подводят итоги года, а мы запрыгиваем в последний вагон трудовых будней 2025 года с очередным релизом DAF! Первая часть релиза (что добавилось и изменилось): 1. Актуализировали маппинг на ГОСТ 56939-2024 2. Добавили автомаппинг на BSIMM. Теперь проводя аудит по DAF можно сразу же получать результат относительно 5 фреймворков - ГОСТ 56939, DSOMM, SAMM, BSIMM, PT Table Top 3. Отдельный лист "Карта DAF" решили вовсе убрать, т.к. есть отличное визуальное представление на вкладке "Общее, домены, поддомены" (в нем еще добавили часть MLSecOps) 4. Учли некоторые пожелания пользователей DAF: - скорректировали формулировки некоторых практик (T-ADI-ART-4-3, T-DEV-SCM-4-3, T-ADI-DEP-3-2, T-DEV-SRC-2-2, T-DEV-SRC-2-3, T-DEV-SRC-3-4, T-DEV-SRC-3-6) - в выпадающем списке на странице «Практики» добавили вариант «Не заполнено» и по-умолчанию проставили для всех практик (чтобы было явно заметно что именно нужно еще заполнить при аудите) - добавили на странице «Практики» отдельный столбец "Область действия практики", чтобы можно было заполнить часть практик для одной команды, часть - для группы команд, а еще часть - для всей компании в целом (например, общие на всю компанию регламенты, процессы) 5. Сделали более приятное визуальное оформление 6. Ну и как обычно, исправили битые ссылки, опечатки, прочие косяки с визуалом и добавили новые Что перенесено на следующий релиз: 1. Новые способы расчета и оформление вкладки "FTE DevSecOps" - к сожалению, 4й квартал нас не пощадил и мы не пришли внутри к общему мнению как же правильно считать. Поэтому переносим на весенний релиз Вторая часть релиза. Мы довольно долго обходили вниманием MLSecOps, хотя это направление очень-очень близко нашему классическому DevSecOps. В этом релизе DAF мы исправили это упущение и добавили: - отдельную вкладку "Практики+MLSecOps" - в ней голубой заливкой выделены отдельные практики MLSecOps, наложенные на обычные практики нашего фреймворка. Это сделано для того, чтобы можно было пользоваться фреймворком как для аудита только DevSecOps (вкладка "Практики"), так и для аудита MLSecOps (вкладка "Практики+MLSecOps"), который является "надстройкой" над DevSecOps - на вкладке "Результаты аудита" добавили результаты по MLSecOps (эти строки скрыты, раскройте их, нажав слева сверху цифру "2") - актуализировали "Общее, домены, поддомены" с учетом добавления MLSecOps Ну и если сделали два релиза (в одном), то почему бы не сделать и третий, верно?😉 Вышел релиз английской версии DAF! Лайк, шер, репост своим зарубежным коллегам!☺️
Новая редакция Профиля Защиты от ЦБ РФ Всем привет! Банк России опубликовал новую редакцию Профиля защиты приложений для финансовых организаций (в приложении). В обновленном документе исправлено большинство недочетов прошлого издания. Основной лейтмотив обновления - синхронизация Профиля защиты с ГОСТ Р 56939-2024. Наш обзор изменений Профиля защиты можно почитать здесь И этот пост закрывает наш рабочий 2025 год! Еще раз поздравляем всех с Наступающим!!!
USVL: визуализация атак и моделей угроз Всем привет! Universal Security Visualization Library (USVL) – open-source проект, который генерирует схемы на основании предоставленной конфигурации. Он может «отрисовать»: 🍭 Attack Trees. Иерархические диаграммы сценария атаки 🍭 Attack Graph. Визуализация атаки с точки зрения сети 🍭 Threat Modelling. Диаграммы потоков данных, учитывающие анализ, реализованный с использованием STRIDE Если это не хватает, то допустимо создание собственных диаграмм («из коробки» доступны формы для использования и шаблоны). В качестве «входных данных» USVL может работать с TOML, YAML и JSON. Полученные результаты можно выгружать в Mermaid-формате. Подробнее с возможностями инструмента, вариантами его запуска и эксплуатации можно ознакомиться в GitHub-репозитории проекта.
Одним из самых частых вопросов на протяжении последних 3-х лет, который мне задавали на моем тренинге, да и вообще на конференциях, после докладов, в кулуарах - это: "А есть отечественные аналоги Talos?" Этот вопрос и сейчас активно спрашивают, НО теперь на него можно положительно ответить! Проект ALT Orchestra (исходники) от ребят из Базальта, на базе Talos и в реестре Российского ПО. О проделанной работе, вкладе в upstream Talos, отличиях, изменениях и планах было рассказано в этом году на KUBER CONF. Мы очень рассчитываем на то что, это даст положительный толчок нашей индустрии, сигнал для регуляторов, что можно и нужно по другому защищать контейнерные окружения и не мучать всех антивирусами на Node, и вообще повысит уровень безопасности, выбросив модель нарушителя "атакующий на Node" из модели угроз. Кто-то уже активно использует container specific OS, а кого-то наконец сможет их использовать) P.S. Также надеемся, что другие отечественные разработчики ОС посмотрят на этот вектор развития своих ОС. UPD. В комментарии добавлены слайды с KUBER CONF
ФСТЭК 🗂 активизировалась в части подготовки методических документов по различным аспектам кибербезопасности. За последнее время регулятор выпустил следующие документы (в отдельном разделе на сайте): ➡️ Рекомендации по базовой настройке регистрации событий безопасности (для Windows и Linux) ➡️ Рекомендации по настройке механизмов безопасности почтового сервера Microsoft Exchange Server от атак, связанных с подменой отправителя (спуфинг-атак) ➡️ Рекомендации по настройке механизмов безопасности почтового сервера, созданного с использованием программного обеспечения с открытым исходным кодом Postfix, от атак, связанных с подменой отправителя (спуфинг-атак) ➡️ Рекомендации по настройке механизмов безопасности почтового сервера, созданного с использованием программного обеспечения с открытым исходным кодом Exim, от атак, связанных с подменой отправителя (спуфинг-атак) ➡️ Рекомендации по базовой настройке механизмов безопасности почтовых сервисов от атак, связанных с подменой отправителя (спуфинг-атак) ➡️ Рекомендации по безопасной настройке операционных систем Linux Первый документ (про регистрацию событий) прям свежайший 🆕 Но я бы в приведенную в приложении табличку добавил бы все-таки Event ID, которые надо мониторить. Тогда их можно сразу засовывать в SIEM. Так это сделано, например, у австралийской ФСТЭК, в их руководстве по настройке регистрации событий. Если бы ФСТЭК еще собрала схожие сведения с производителей отечественного сетевого оборудования (аналогичная работа была проведена теми же австралийцами и альянсом "пяти глаз"), то цены ей бы не было 🤔 #bestpractice
На сцене Николай Панченко, Т-Банк: "Чеклист безопасности ML-кластеров"
Building Secure AI Applications Всем привет! В приложении можно скачать небольшой методический материал (~ 40 страниц), посвященный тому, на что обращать внимание при обеспечении ИБ при разработке приложений, использующих AI. Материал основан на OWASP Top 10 для LLM: 🍭 LLM01 Prompt Injection 🍭 LLM02 Sensitive Information Disclosure 🍭 LLM03 Supply Chain 🍭 LLM04 Data and Model Poisoning 🍭 LLM05 Improper Output Handling и не только Для каждого раздела описаны общие рекомендации по повышению уровня защищенности и перечень инструментов, которые можно использовать для автоматизации. Дополнительно в материале представлена концептуальная архитектура с соотношением рассматриваемых угроз.
OWASP Top 10 For Agentic Applications 2026 Всем привет! В декабре 2025 года вышел еще один материал, посвященный безопасности при работе с AI, а именно при работе с агентами. Документ можно скачать в приложении к посту, ~ 58 страниц для изучения. Представлены следующие уязвимости: 🍭 ASI01: Agent Goal Hijack 🍭 ASI02: Tool Misuse & Exploitation 🍭 ASI03: Identity & Privilege Abuse 🍭 ASI04: Agentic Supply Chain Vulnerabilities 🍭 ASI05: Unexpected Code Execution (RCE) 🍭 ASI06: Memory & Context Poisoning 🍭 ASI07: Insecure Inter-Agent Communication 🍭 ASI08: Cascading Failures 🍭 ASI09: Human-Agent Trust Exploitation 🍭 ASI10: Rogue Agents Для каждой из рассматриваемых уязвимостей приводится ее описание, примеры, примеры атак с ее «использованием», рекомендации по устранению и ссылки на полезные материалы по теме. Дополнительно приводится соотношение рассматриваемых уязвимостей с ключевыми «логическими блоками»: Inputs, Integration/Processing и Outputs.
без подписи
без подписи
Кейс: как мы автоматизировали генерацию Nuclei-шаблонов для VK API с помощью LLM Представьте, что у вас есть огромное количество новых методов в API, и вы хотите быстро и качественно тестировать их на уязвимости. Вручную это делать невозможно — слишком долго и скучно. Вот почему мы решили автоматизировать генерацию Nuclei-шаблонов на основе JSON-схем методов VK API, используя LLM. 🔹 Но задача оказалась не такой простой. Например, для создания комментария нужно сначала получить `postId`, а для этого вызвать другой метод. Как автоматически определить, какие данные нужны для каждого метода? И как понять, какие параметры можно использовать для тестирования уязвимостей, а какие — нет? Ведь не все поля одинаково «безопасны» для нагрузки. Еще одна сложность — не всегда достаточно просто вызвать метод: иногда уязвимость проявится только после ряда действий на странице (например, открытие модального окна, клик по кнопке). Раньше такие сценарии писали вручную, но это не масштабируется. Мы искали способ автоматически собирать эти действия и использовать их для обучения LLM. В итоге мы выбрали такой подход: ▫️автоматически собираем актуальные методы VK API, чтобы всегда иметь самую свежую информацию; обучаем LLM анализировать JSON-схемы, чтобы определять, какие параметры использовать для нагрузки, а какие — оставить в покое; ▫️обогащаем модель контекстом: используем не только схемы методов, но и реальный трафик тестировщиков, а также автотесты, чтобы модель понимала, как методы применяются на практике; ▫️запускаем бота на Selenium, который «проживает» основные пользовательские сценарии, чтобы фиксировать, какие методы используются на каких страницах; ▫️для сложных сценариев, где методы вызываются не напрямую, собираем скрипты действий, чтобы расширить контекст обучения; ▫️всё это позволяет нам избегать «галлюцинаций» — когда модель начинает выдумывать что-то лишнее — и поддерживать нужный баланс между информативностью и точностью. Не обошлись без LLM и при выборе триггера сканирования. Как только завершаются функциональные тесты в пайплайне, в дело вступает модуль скоринга «фичи» на базе LLM. Модуль оценивает её на предмет существенности изменений: если фича больше про косметические правки, не затрагивает бизнес-логику, не порождает новых полей для пользовательского ввода, etc, то необходимости сканировать её нет. 🔹Генерация Nuclei-шаблонов стала быстрой, масштабируемой и автоматической. Теперь мы можем быстро реагировать на появление новых методов, и количество тестов выросло в разы, а рутинная ручная работа — уменьшилась. Но, конечно, не всё идеально: сложные user flows, вопросы с контекстом и галлюцинации — всё это мы учли и продолжаем дорабатывать. 🔹Если у вас есть вопросы по нашему подходу или хотите обсудить детали — пишите!