Б1 (бывший EY) выпустил очень неплохой отчет по российскому рынку ИБ 👇 Не буду спойлерить и вытаскивать оттуда всякие цифры, которых там много 📊 Отмечу только, что в отчете также описываются не только российские тенденции, но и зарубежные ↗️

#статистика #тенденции #отчет

31 марта 2025 перешли в статус обязательных требования PCI DSS 4.0.1 для frontend-приложений

Обязательность выполнения требований актуальной версии PCI DSS указана в Программе безопасности ПС «Мир» / НСПК.

🔹 6.4.3 Все скрипты платежных страниц, которые загружаются и выполняются в браузере пользователя, управляются следующим образом:
- Актуальная инвентаризация всех скриптов с письменным обоснованием бизнес-необходимости каждого из них.
- Реализован метод подтверждения авторизации и целостности каждого скрипта.

🔹 11.6.1 Обнаружение и реагирование на несанкционированное изменение платежных страниц:
- Контроль изменений на платежных страницах.
- Контроль изменений HTTP заголовков (в том числе Content Security Policy (CSP)).
- Оповещение персонала о несанкционированных изменениях.

🔹 Требования также применяются к web-страницам, на которых встроен сторонний iframe c формой оплаты TPSP/платежного процессора.

Использование CSP не может полноценно выполнить эти требования и обеспечить безопасность пользователей ⚠️

Точнее сказать выполнить требования для аудитора то может, по принципу "заголовок CSP с хэшами скриптов есть, бизнес-обоснования записываем в блокноте 📝, каждый день проверяем глазами 👁 ..." 😄 (наотъе .. кто здесь 😂? только для галочки аудитора ☑️).

Но мы ведь не из таких ... 😎 Мы знаем, что требования появляются не просто так, а для снижения рисков от реальных угроз: js-снифферов, frontend-фишинга, Supply Chain Attack и т.д.

Файл-бандл frontend-приложения 📱 включает все зависимости (десятки-сотни opensource-библиотек) и изменяется при каждом релизе приложения ➡️ изменяется хэш файла ➡️ меняем заголовок CSP. Бизнес-обоснование? "Это главный скрипт приложения". Кто-то проверял, что в новые версии зависимостей не был встроен js-сниффер? Нет. 🤨 Но формально требования PCI DSS выполнены ☑️

Кстати, НКЦКИ требует именно проверку скриптов на вредоносные действия после любых изменений, а не только контроль целостности.

Допустим разрешенные хэши скриптов в CSP указали, а вот запретить eval() забыли (формально, не требуется). Вредоносный код в зависимости хранит пейлоад в base64 ➡️ извлекает код сниффера ➡️ выполняет через eval() ➡️ данные карт клиентов 💳 похищаются прямо в браузере пользователя в "слепой зоне" для WAF, NGFW, DLP... 🤨

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

В разъяснительной части PCI DSS 4.0.1, сказано: "Единственное место, где можно обнаружить изменения и признаки вредоносной активности — это браузер пользователя, где страница полностью собрана и выполнен весь JavaScript-код".

Без глубокого анализа поведения js-кода в реальном браузере 📱 / frontend-sandbox (например, DPA FAST Analyzer) невозможно провести достоверную инвентаризацию скриптов и обнаружить утечки данных в frontend-приложении.

PCI DSS 4.0.1 - первый стандарт, в явном виде зафиксировавший необходимость обеспечения безопасности frontend-ов и должен являться best practice для всех компаний ✅

Давайте защищать🛡 наших пользователей, их данные и репутацию компании, а не делать что-то только для "галочки" аудитора ☑️

@FrontSecOps