Стандарт № ISO/IEC 27001:2022(E) от 25.10.2022

ЖЦ.2 Документарное определение состава (с указанием соответствия настоящему стандарту) и содержания мер системы защиты информации АС (функционально-технических требований к системе защиты информации АС)
3-О 2-О 1-О

ЖЦ.3 Документарное определение в проектной и эксплуатационной документации на систему защиты информации АС: 

ЖЦ.12 Размещение и настройка (конфигурирование) технических мер системы защиты информации АС в информационной инфраструктуре, используемой для непосредственной реализации бизнес-процессов или технологических процессов финансовой организации (далее - промышленная среда), в соответствии с положениями проектной и эксплуатационной документации
3-О 2-О 1-О

PR.IP-2: Реализован жизненный цикл разработки систем (SDLC) для управления системами 

6.2.3.1
Defined Approach Requirements: 
If manual code reviews are performed for bespoke and custom software prior to release to production, code changes are: 

Customized Approach Objective:
The manual code review process cannot be bypassed and is effective at discovering security vulnerabilities. 

Applicability Notes:
Manual code reviews can be conducted by knowledgeable internal personnel or knowledgeable third-party personnel. 
An individual that has been formally granted accountability for release control and who is neither the original code author nor the code reviewer fulfills the criteria of being management. 

Defined Approach Testing Procedures:

Purpose:
Having code reviewed by someone other than the original author, who is both experienced in code reviews and knowledgeable about secure coding practices, minimizes the possibility that code containing security or logic errors that could affect the security of cardholder data is released into a production environment. Requiring management approval that the code was reviewed limits the ability for the process to be bypassed. 

Good Practice:
Having a formal review methodology and review checklists has been found to improve the quality of the code review process. 
Code review is a tiring process, and for this reason, it is most effective when reviewers only review small amounts of code at a time. 
To maintain the effectiveness of code reviews, it is beneficial to monitor the general workload of reviewers and to have them review applications they are familiar with. 
Code reviews may be performed using either manual or automated processes, or a combination of both. 
Entitles that rely solely on manual code review should ensure that reviewers maintain their skills through regular training as new vulnerabilities are found, and new secure coding methods are recommended. 

Further Information:
See the OWASP Code Review Guide. 

6.2.1
Defined Approach Requirements: 
Bespoke and custom software are developed securely, as follows:

Customized Approach Objective:
Bespoke and custom software is developed in accordance with PCI DSS and secure development processes throughout the software lifecycle. 

Applicability Notes:
This applies to all software developed for or by the entity for the entity’s own use. This includes both bespoke and custom software. This does not apply to third-party software. 

Defined Approach Testing Procedures:

Purpose:
Without the inclusion of security during the requirements definition, design, analysis, and testing phases of software development, security vulnerabilities can be inadvertently or maliciously introduced into the production environment. 

Good Practice:
Understanding how sensitive data is handled by the application—including when stored, transmitted, and in memory—can help identify where data needs to be protected. 
PCI DSS requirements must be considered when developing software to meet those requirements by design, rather than trying to retrofit the software later. 

Examples:
Secure software lifecycle management methodologies and frameworks include PCI Software Security Framework, BSIMM, OPENSAMM, and works from NIST, ISO, and SAFECode. 

6.2.3
Defined Approach Requirements: 
Bespoke and custom software is reviewed prior to being released into production or to customers, to identify and correct potential coding vulnerabilities, as follows: 

Customized Approach Objective:
Bespoke and custom software cannot be exploited via coding vulnerabilities. 

Applicability Notes:
This requirement for code reviews applies to all bespoke and custom software (both internal and public-facing), as part of the system development lifecycle. Public-facing web applications are also subject to additional controls, to address ongoing threats and vulnerabilities after implementation, as defined at PCI DSS Requirement 6.4. Code reviews may be performed using either manual or automated processes, or a combination of both. 

Defined Approach Testing Procedures:

Purpose:
Security vulnerabilities in bespoke and custom software are commonly exploited by malicious individuals to gain access to a network and compromise account data. 
Vulnerable code is far more difficult and expensive to address after it has been deployed or released into production environments. Requiring a formal review and signoff by management prior to release helps to ensure that code is approved and has been developed in accordance with policies and procedures. 

Good Practice:
The following items should be considered for inclusion in code reviews:

A.14.1.1 Анализ и спецификация требований информационной безопасности 
Мера обеспечения информационной безопасности: Требования, относящиеся к информационной безопасности, должны быть включены в перечень требований для новых информационных систем или для усовершенствования существующих информационных систем 

6.2.3.1
Определенные Требования к Подходу:
Если проверка кода вручную выполняется для программного обеспечения, изготовленного на заказ, перед выпуском в производство, изменения кода:

Цель Индивидуального подхода:
Процесс проверки кода вручную невозможно обойти, и он эффективен при обнаружении уязвимостей в системе безопасности.

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

Определенные Процедуры Тестирования Подхода:

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

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

Дополнительная информация:
См. Руководство по обзору кода OWASP.

6.2.1
Определенные Требования к Подходу:
Программное обеспечение на заказ и на заказ разрабатывается надежно, следующим образом:

Цель Индивидуального подхода:
Индивидуальное и индивидуальное программное обеспечение разрабатывается в соответствии с PCI DSS и безопасными процессами разработки на протяжении всего жизненного цикла программного обеспечения.

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

Определенные Процедуры Тестирования Подхода:

Цель:
Без учета безопасности на этапах определения требований, проектирования, анализа и тестирования разработки программного обеспечения уязвимости безопасности могут быть непреднамеренно или злонамеренно внедрены в производственную среду.

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

Примеры:
Методологии и фреймворки безопасного управления жизненным циклом программного обеспечения включают PCI Software Security Framework, BSIMM, OPENSAMM и работы из NIST, ISO и SafeCode.

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

Цель Индивидуального подхода:
Сделанное на заказ и изготовленное на заказ программное обеспечение не может быть использовано с помощью уязвимостей в кодировании.

Примечания по применению:
Это требование к проверке кода применяется ко всему программному обеспечению, разработанному на заказ (как внутреннему, так и общедоступному), как часть жизненного цикла разработки системы. Общедоступные веб-приложения также подвергаются дополнительному контролю для устранения текущих угроз и уязвимостей после внедрения, как определено в требовании PCI DSS 6.4. Проверка кода может выполняться с использованием ручных или автоматизированных процессов или их комбинации.

Определенные Процедуры Тестирования Подхода:

Цель:
Уязвимости в системе безопасности в специально разработанном и заказном программном обеспечении обычно используются злоумышленниками для получения доступа к сети и компрометации данных учетной записи.
Уязвимый код гораздо сложнее и дороже устранять после того, как он был развернут или выпущен в производственных средах. Требование официального рассмотрения и одобрения руководством перед выпуском помогает гарантировать, что код одобрен и разработан в соответствии с политиками и процедурами.

Надлежащая практика:
Следующие пункты следует рассмотреть для включения в обзоры кода:

А.8.26 Требования безопасности к приложениям
При разработке или приобретении приложений должны быть идентифицированы, точно определены и утверждены требования ИБ.