Куда я попал?
SECURITM это SGRC система, ? автоматизирующая процессы в службах информационной безопасности. SECURITM помогает построить и управлять ИСПДн, КИИ, ГИС, СМИБ/СУИБ, банковскими системами защиты.
А еще SECURITM это место для обмена опытом и наработками для служб безопасности.

Framework № PCI DSS 4.0 от 01.03.2022

Payment Card Industry Data Security Standard

Requirement 6.2.3.1

Для проведения оценки соответствия по документу войдите в систему.

Список требований

Похожие требования

CIS Critical Security Controls v7.1 (SANS Top 20):
CSC 18.2 CSC 18.2 Ensure That Explicit Error Checking is Performed for All In-House Developed Software
For in-house developed software, ensure that explicit error checking is performed and documented for all input, including for size, data type, and acceptable ranges or formats.
Framework № PCI DSS 4.0 от 01.03.2022 "Payment Card Industry Data Security Standard (RU)":
Requirement 6.2.3.1
6.2.3.1
Определенные Требования к Подходу:
Если проверка кода вручную выполняется для программного обеспечения, изготовленного на заказ, перед выпуском в производство, изменения кода:
  • Проверено лицами, не являющимися автором исходного кода, и которые хорошо осведомлены о методах проверки кода и методах безопасного кодирования.
  • Рассмотрено и одобрено руководством перед выпуском.
Цель Индивидуального подхода:
Процесс проверки кода вручную невозможно обойти, и он эффективен при обнаружении уязвимостей в системе безопасности.

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

Определенные Процедуры Тестирования Подхода:
  • 6.2.3.1.a Если для программного обеспечения, изготовленного на заказ и изготовленного на заказ, выполняются проверки кода вручную перед выпуском в производство, изучите документированные процедуры разработки программного обеспечения и опросите ответственный персонал, чтобы убедиться, что процессы определены для проведения проверок кода вручную в соответствии со всеми элементами, указанными в этом требовании.
  • 6.2.3.1.b Изучить доказательства изменений в программном обеспечении, изготовленном на заказ, и провести собеседование с персоналом, чтобы убедиться, что проверка кода вручную проводилась в соответствии со всеми элементами, указанными в этом требовании.
Цель:
Проверка кода кем-либо, кроме первоначального автора, который имеет опыт в проверке кода и осведомлен о методах безопасного кодирования, сводит к минимуму вероятность того, что код, содержащий ошибки безопасности или логические ошибки, которые могут повлиять на безопасность данных о держателях карт, будет выпущен в производственную среду. Требование одобрения руководством того, что код был пересмотрен, ограничивает возможность обхода процесса.

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

Дополнительная информация:
См. Руководство по обзору кода OWASP.
Стандарт № ИСО/МЭК 27001:2022(E) от 25.10.2022 "Информационная безопасность, кибербезопасность и защита частной жизни — Системы управления информационной безопасностью — Требования. Приложение А":
А.8.29
А.8.29 Тестирование безопасности в разработке и приемке
В жизненном цикле разработки должны быть определены и внедрены процессы тестирования безопасности разрабатываемого продукта.
А.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.
А.8.29
А.8.29 Security testing in development and acceptance
Security testing processes shall be defined and implemented in the development life cycle.
А.8.25
А.8.25 Secure development life cycle
Rules for the secure development of software and systems shall be established and applied. 

Связанные защитные меры

Ничего не найдено

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