Куда я попал?
Framework № PCI DSS 4.0 от 01.03.2022
Payment Card Industry Data Security Standard
Requirement 6.2.3
Для проведения оценки соответствия по документу войдите в систему.
Список требований
Похожие требования
CIS Critical Security Controls v8 (The 18 CIS CSC):
16.12
16.12 Implement Code-Level Security Checks
Apply static and dynamic analysis tools within the application life cycle to verify that secure coding practices are being followed.
Apply static and dynamic analysis tools within the application life cycle to verify that secure coding practices are being followed.
Russian Unified Cyber Security Framework (на основе The 18 CIS CSC):
16.12
16.12 Реализована проверка безопасности на уровне кода
Инструменты статического и динамического анализа встроены в жизненный цикл разработки.
Инструменты статического и динамического анализа встроены в жизненный цикл разработки.
CIS Critical Security Controls v7.1 (SANS Top 20):
CSC 18.7
CSC 18.7 Apply Static and Dynamic Code Analysis Tools
Apply static and dynamic analysis tools to verify that secure coding practices are being adhered to for internally developed software.
Apply static and dynamic analysis tools to verify that secure coding practices are being adhered to for internally developed software.
Framework № PCI DSS 4.0 от 01.03.2022 "Payment Card Industry Data Security Standard (RU)":
Requirement 6.2.3
6.2.3
Определенные Требования к Подходу:
Разработанное на заказ и заказное программное обеспечение проверяется перед выпуском в производство или для клиентов, чтобы выявить и исправить потенциальные уязвимости в коде следующим образом:
Определенные Требования к Подходу:
Разработанное на заказ и заказное программное обеспечение проверяется перед выпуском в производство или для клиентов, чтобы выявить и исправить потенциальные уязвимости в коде следующим образом:
- Проверка кода гарантирует, что код разрабатывается в соответствии с рекомендациями по безопасному кодированию.
- Анализ кода направлен на выявление как существующих, так и новых уязвимостей программного обеспечения.
- Соответствующие исправления вносятся до выпуска
Цель Индивидуального подхода:
Сделанное на заказ и изготовленное на заказ программное обеспечение не может быть использовано с помощью уязвимостей в кодировании.
Примечания по применению:
Это требование к проверке кода применяется ко всему программному обеспечению, разработанному на заказ (как внутреннему, так и общедоступному), как часть жизненного цикла разработки системы. Общедоступные веб-приложения также подвергаются дополнительному контролю для устранения текущих угроз и уязвимостей после внедрения, как определено в требовании PCI DSS 6.4. Проверка кода может выполняться с использованием ручных или автоматизированных процессов или их комбинации.
Определенные Процедуры Тестирования Подхода:
Сделанное на заказ и изготовленное на заказ программное обеспечение не может быть использовано с помощью уязвимостей в кодировании.
Примечания по применению:
Это требование к проверке кода применяется ко всему программному обеспечению, разработанному на заказ (как внутреннему, так и общедоступному), как часть жизненного цикла разработки системы. Общедоступные веб-приложения также подвергаются дополнительному контролю для устранения текущих угроз и уязвимостей после внедрения, как определено в требовании PCI DSS 6.4. Проверка кода может выполняться с использованием ручных или автоматизированных процессов или их комбинации.
Определенные Процедуры Тестирования Подхода:
- 6.2.3.a Изучить документированные процедуры разработки программного обеспечения и провести собеседование с ответственным персоналом, чтобы убедиться, что определены процессы, требующие проверки всего программного обеспечения, изготовленного на заказ и изготовленного на заказ, в соответствии со всеми элементами, указанными в этом требовании.
- 6.2.3.b Изучить доказательства изменений в заказном и заказном программном обеспечении, чтобы убедиться, что изменения в коде были рассмотрены в соответствии со всеми элементами, указанными в этом требовании.
Цель:
Уязвимости в системе безопасности в специально разработанном и заказном программном обеспечении обычно используются злоумышленниками для получения доступа к сети и компрометации данных учетной записи.
Уязвимый код гораздо сложнее и дороже устранять после того, как он был развернут или выпущен в производственных средах. Требование официального рассмотрения и одобрения руководством перед выпуском помогает гарантировать, что код одобрен и разработан в соответствии с политиками и процедурами.
Надлежащая практика:
Следующие пункты следует рассмотреть для включения в обзоры кода:
Уязвимости в системе безопасности в специально разработанном и заказном программном обеспечении обычно используются злоумышленниками для получения доступа к сети и компрометации данных учетной записи.
Уязвимый код гораздо сложнее и дороже устранять после того, как он был развернут или выпущен в производственных средах. Требование официального рассмотрения и одобрения руководством перед выпуском помогает гарантировать, что код одобрен и разработан в соответствии с политиками и процедурами.
Надлежащая практика:
Следующие пункты следует рассмотреть для включения в обзоры кода:
- Поиск недокументированных функций (инструменты имплантации, бэкдоры).
- Подтверждение того, что программное обеспечение безопасно использует функции внешних компонентов (библиотеки, фреймворки, API и т.д.). Например, если используется сторонняя библиотека, предоставляющая криптографические функции, убедитесь, что она была надежно интегрирована.
- Проверка правильного использования ведения журнала для предотвращения попадания конфиденциальных данных в журналы.
- Анализ небезопасных структур кода, которые могут содержать потенциальные уязвимости, связанные с распространенными программными атаками, определенными в Требованиях 6.2.5.
- Проверка поведения приложения на предмет обнаружения логических уязвимостей.
Стандарт № ИСО/МЭК 27001:2022(E) от 25.10.2022 "Информационная безопасность, кибербезопасность и защита частной жизни — Системы управления информационной безопасностью — Требования. Приложение А":
А.8.25
А.8.25 Жизненный цикл безопасной разработки
Должны быть установлены и применяться правила безопасной разработки программного обеспечения и систем.
Должны быть установлены и применяться правила безопасной разработки программного обеспечения и систем.
А.8.26
А.8.26 Требования безопасности к приложениям
При разработке или приобретении приложений должны быть идентифицированы, точно определены и утверждены требования ИБ.
При разработке или приобретении приложений должны быть идентифицированы, точно определены и утверждены требования ИБ.
Стандарт № ISO/IEC 27001:2022(E) от 25.10.2022 "Information security, cybersecurity and privacy protection — Information security management systems — Requirements. Annex A":
А.8.26
А.8.26 Application security requirements
Information security requirements shall be identified, specified and approved when developing or acquiring applications.
Information security requirements shall be identified, specified and approved when developing or acquiring applications.
А.8.25
А.8.25 Secure development life cycle
Rules for the secure development of software and systems shall be established and applied.
Rules for the secure development of software and systems shall be established and applied.
Связанные защитные меры
Ничего не найдено
Мы используем cookie-файлы, чтобы получить статистику, которая помогает нам улучшить сервис для вас с целью персонализации сервисов и предложений. Вы может прочитать подробнее о cookie-файлах или изменить настройки браузера. Продолжая пользоваться сайтом, вы даёте согласие на использование ваших cookie-файлов и соглашаетесь с Политикой обработки персональных данных.