Куда я попал?
Стандарт № ISO/IEC 27001:2022(E) от 25.10.2022
Information security, cybersecurity and privacy protection — Information security management systems — Requirements. Annex A
А.8.25
Для проведения оценки соответствия по документу войдите в систему.
Похожие требования
ГОСТ Р № 57580.1-2017 от 01.01.2018 "Безопасность финансовых (банковских) операций. Защита информации финансовых организаций. Базовый состав организационных и технических мер. Раздел 9. Требования к защите информации на этапах жизненного цикла автоматизированных систем и приложений":
ЖЦ.24
ЖЦ.24 Реализация контроля в сегментах разработки и тестирования корректности функционирования систем защиты информации АС после внесения изменений в АС, включая обновления прикладного ПО
3-Н 2-О 1-О
3-Н 2-О 1-О
CIS Critical Security Controls v8 (The 18 CIS CSC):
16.1
16.1 Establish and Maintain a Secure Application Development Process
Establish and maintain a secure application development process. In the process, address such items as: secure application design standards, secure coding practices, developer training, vulnerability management, security of third-party code, and application security testing procedures. Review and update documentation annually, or when significant enterprise changes occur that could impact this Safeguard.
Establish and maintain a secure application development process. In the process, address such items as: secure application design standards, secure coding practices, developer training, vulnerability management, security of third-party code, and application security testing procedures. Review and update documentation annually, or when significant enterprise changes occur that could impact this Safeguard.
NIST Cybersecurity Framework (RU):
PR.IP-3
PR.IP-3: Реализованы процессы контроля изменений конфигурации
PR.IP-1
PR.IP-1: С учетом соответствующих принципов безопасности (например, концепция минимальной функциональности) создается и поддерживается базовая конфигурация информационных технологий / промышленных систем управления
Russian Unified Cyber Security Framework (на основе The 18 CIS CSC):
16.1
16.1 Реализован и поддерживается процесс безопасной разработки программного обеспечения
Описание процесса включает стандарты безопасного проектирования ПО, стандарты безопасного написания кода, регулярное обучение разработчиков, управление уязвимостями, контроль сторонней разработки и процедуры тестирования ПО.
Описание процесса включает стандарты безопасного проектирования ПО, стандарты безопасного написания кода, регулярное обучение разработчиков, управление уязвимостями, контроль сторонней разработки и процедуры тестирования ПО.
Framework № PCI DSS 4.0 от 01.03.2022 "Payment Card Industry Data Security Standard":
Requirement 6.2.3.1
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:
Defined Approach Requirements:
If manual code reviews are performed for bespoke and custom software prior to release to production, code changes are:
- Reviewed by individuals other than the originating code author, and who are knowledgeable about code-review techniques and secure coding practices.
- Reviewed and approved by management prior to release.
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:
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:
- 6.2.3.1.a If manual code reviews are performed for bespoke and custom software prior to release to production, examine documented software development procedures and interview responsible personnel to verify that processes are defined for manual code reviews to be conducted in accordance with all elements specified in this requirement.
- 6.2.3.1.b Examine evidence of changes to bespoke and custom software and interview personnel to verify that manual code reviews were conducted in accordance with all elements specified in this requirement.
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.
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.
Requirement 6.5.3
6.5.3
Defined Approach Requirements:
Pre-production environments are separated from production environments and the separation is enforced with access controls.
Customized Approach Objective:
Pre-production environments cannot introduce risks and vulnerabilities into production environments.
Defined Approach Testing Procedures:
Defined Approach Requirements:
Pre-production environments are separated from production environments and the separation is enforced with access controls.
Customized Approach Objective:
Pre-production environments cannot introduce risks and vulnerabilities into production environments.
Defined Approach Testing Procedures:
- 6.5.3.a Examine policies and procedures to verify that processes are defined for separating the preproduction environment from the production environment via access controls that enforce the separation.
- 6.5.3.b Examine network documentation and configurations of network security controls to verify that the pre-production environment is separate from the production environment(s).
- 6.5.3.c Examine access control settings to verify that access controls are in place to enforce separation between the pre-production and production environment(s).
Purpose:
Purpose Due to the constantly changing state of preproduction environments, they are often less secure than the production environment.
Good Practice:
Organizations must clearly understand which environments are test environments or development environments and how these environments interact on the level of networks and applications.
Definitions:
Pre-production environments include development, testing, user acceptance testing (UAT), etc. Even where production infrastructure is used to facilitate testing or development, production environments still need to be separated (logically or physically) from preproduction functionality such that vulnerabilities introduced as a result of pre-production activities do not adversely affect production systems.
Purpose Due to the constantly changing state of preproduction environments, they are often less secure than the production environment.
Good Practice:
Organizations must clearly understand which environments are test environments or development environments and how these environments interact on the level of networks and applications.
Definitions:
Pre-production environments include development, testing, user acceptance testing (UAT), etc. Even where production infrastructure is used to facilitate testing or development, production environments still need to be separated (logically or physically) from preproduction functionality such that vulnerabilities introduced as a result of pre-production activities do not adversely affect production systems.
Requirement 6.2.1
6.2.1
Defined Approach Requirements:
Bespoke and custom software are developed securely, as follows:
Defined Approach Requirements:
Bespoke and custom software are developed securely, as follows:
- Based on industry standards and/or best practices for secure development.
- In accordance with PCI DSS (for example, secure authentication and logging).
- Incorporating consideration of information security issues during each stage of the software development lifecycle.
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:
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:
- 6.2.1 Examine documented software development procedures to verify that processes are defined that include all elements specified in this requirement.
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.
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.
Requirement 6.2.4
6.2.4
Defined Approach Requirements:
Software engineering techniques or other methods are defined and in use by software development personnel to prevent or mitigate common software attacks and related vulnerabilities in bespoke and custom software, including but not limited to the following:
Defined Approach Requirements:
Software engineering techniques or other methods are defined and in use by software development personnel to prevent or mitigate common software attacks and related vulnerabilities in bespoke and custom software, including but not limited to the following:
- Injection attacks, including SQL, LDAP, XPath, or other command, parameter, object, fault, or injection-type flaws.
- Attacks on data and data structures, including attempts to manipulate buffers, pointers, input data, or shared data.
- Attacks on cryptography usage, including attempts to exploit weak, insecure, or inappropriate cryptographic implementations, algorithms, cipher suites, or modes of operation.
- Attacks on business logic, including attempts to abuse or bypass application features and functionalities through the manipulation of APIs, communication protocols and channels, clientside functionality, or other system/application functions and resources. This includes cross-site scripting (XSS) and cross-site request forgery (CSRF).
- Attacks on access control mechanisms, including attempts to bypass or abuse identification, authentication, or authorization mechanisms, or attempts to exploit weaknesses in the implementation of such mechanisms.
- Attacks via any “high-risk” vulnerabilities identified in the vulnerability identification process, as defined in Requirement 6.3.1.
Customized Approach Objective:
Bespoke and custom software cannot be exploited via common attacks and related vulnerabilities.
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 sof
Defined Approach Testing Procedures:
Bespoke and custom software cannot be exploited via common attacks and related vulnerabilities.
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 sof
Defined Approach Testing Procedures:
- 6.2.4 Examine documented procedures and interview responsible software development personnel to verify that software engineering techniques or other methods are defined and in use by developers of bespoke and custom software to prevent or mitigate all common software attacks as specified in this requirement.
Purpose:
Detecting or preventing common errors that result in vulnerable code as early as possible in the software development process lowers the probability that such errors make it through to production and lead to a compromise. Having formal engineering techniques and tools embedded in the development process will catch these errors early. This philosophy is sometimes called “shifting security left.”
Good Practice:
For both bespoke and custom software, the entity must ensure that code is developed focusing on the prevention or mitigation of common software attacks, including:
Detecting or preventing common errors that result in vulnerable code as early as possible in the software development process lowers the probability that such errors make it through to production and lead to a compromise. Having formal engineering techniques and tools embedded in the development process will catch these errors early. This philosophy is sometimes called “shifting security left.”
Good Practice:
For both bespoke and custom software, the entity must ensure that code is developed focusing on the prevention or mitigation of common software attacks, including:
- Attempts to exploit common coding vulnerabilities (bugs).
- Attempts to exploit software design flaws.
- Attempts to exploit implementation/configuration flaws.
- Enumeration attacks – automated attacks that are actively exploited in payments and abuse identification, authentication, or authorization mechanisms. See the PCI Perspectives blog article “Beware of Account Testing Attacks.”
Researching and documenting software engineering techniques or other methods helps to define how software developers prevent or mitigate various software attacks by features or countermeasures they build into software. This might include identification/authentication mechanisms, access control, input validation routines, etc. Developers should be familiar with different types of vulnerabilities and potential attacks and use measures to avoid potential attack vectors when developing code.
Examples:
Techniques include automated processes and practices that scan code early in the development cycle when code is checked in to confirm the vulnerabilities are not present.
Examples:
Techniques include automated processes and practices that scan code early in the development cycle when code is checked in to confirm the vulnerabilities are not present.
Requirement 6.2.3
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:
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:
- Code reviews ensure code is developed according to secure coding guidelines.
- Code reviews look for both existing and emerging software vulnerabilities.
- Appropriate corrections are implemented prior to release
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:
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:
- 6.2.3.a Examine documented software development procedures and interview responsible personnel to verify that processes are defined that require all bespoke and custom software to be reviewed in accordance with all elements specified in this requirement.
- 6.2.3.b Examine evidence of changes to bespoke and custom software to verify that the code changes were reviewed in accordance with all elements specified in this requirement.
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:
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:
- Searching for undocumented features (implant tools, backdoors).
- Confirming that software securely uses external components’ functions (libraries, frameworks, APIs, etc.). For example, if a third-party library providing cryptographic functions is used, verify that it was integrated securely.
- Checking for correct use of logging to prevent sensitive data from getting into logs.
- Analysis of insecure code structures that may contain potential vulnerabilities related to common software attacks identified in Requirements 6.2.5.
- Checking the application’s behavior to detect logical vulnerabilities.
ГОСТ Р № ИСО/МЭК 27001-2021 от 01.01.2022 "Информационная технология. Методы и средства обеспечения безопасности. Системы менеджмента информационной безопасности. Требования - Приложение А":
A.14.2.2
A.14.2.2 Процедуры управления изменениями системы
Мера обеспечения информационной безопасности: Необходимо управлять изменениями в системах в течение жизненного цикла разработки посредством применения формализованных процедур управления изменениями
Мера обеспечения информационной безопасности: Необходимо управлять изменениями в системах в течение жизненного цикла разработки посредством применения формализованных процедур управления изменениями
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.
Проверка кода кем-либо, кроме первоначального автора, который имеет опыт в проверке кода и осведомлен о методах безопасного кодирования, сводит к минимуму вероятность того, что код, содержащий ошибки безопасности или логические ошибки, которые могут повлиять на безопасность данных о держателях карт, будет выпущен в производственную среду. Требование одобрения руководством того, что код был пересмотрен, ограничивает возможность обхода процесса.
Надлежащая практика:
Было обнаружено, что наличие официальной методологии проверки и контрольных списков проверки повышает качество процесса проверки кода.
Проверка кода - утомительный процесс, и по этой причине он наиболее эффективен, когда рецензенты просматривают только небольшие объемы кода за один раз.
Для поддержания эффективности проверок кода полезно отслеживать общую рабочую нагрузку проверяющих и поручать им проверять приложения, с которыми они знакомы.
Проверка кода может выполняться с использованием либо ручных, либо автоматизированных процессов, либо комбинации того и другого.
Права, которые полагаются исключительно на ручную проверку кода, должны гарантировать, что проверяющие поддерживают свои навыки посредством регулярного обучения по мере обнаружения новых уязвимостей и рекомендуются новые безопасные методы кодирования.
Дополнительная информация:
См. Руководство по обзору кода OWASP.
Requirement 6.5.3
6.5.3
Определенные Требования к Подходу:
Предпроизводственные среды отделены от производственных сред, и это разделение обеспечивается с помощью средств контроля доступа.
Цель Индивидуального подхода:
Предпроизводственная среда не может привносить риски и уязвимости в производственную среду.
Определенные Процедуры Тестирования Подхода:
Определенные Требования к Подходу:
Предпроизводственные среды отделены от производственных сред, и это разделение обеспечивается с помощью средств контроля доступа.
Цель Индивидуального подхода:
Предпроизводственная среда не может привносить риски и уязвимости в производственную среду.
Определенные Процедуры Тестирования Подхода:
- 6.5.3.a Изучите политики и процедуры, чтобы убедиться, что определены процессы для отделения среды подготовки производства от производственной среды с помощью средств управления доступом, которые обеспечивают разделение.
- 6.5.3.b Изучите сетевую документацию и конфигурации средств управления сетевой безопасностью, чтобы убедиться, что предпроизводственная среда отделена от производственной среды (ов).
- 6.5.3.c Проверьте настройки контроля доступа, чтобы убедиться, что средства контроля доступа установлены для обеспечения разделения между предварительной и производственной средой (средами).
Цель:
Среды разработки и тестирования из-за постоянно меняющегося состояния часто менее безопасны, чем производственная среда.
Надлежащая практика:
Организации должны четко понимать, какие среды являются средами тестирования или средами разработки, и как эти среды взаимодействуют на уровне сетей и приложений.
Определения:
Предпроизводственные среды включают разработку, тестирование, приемочное тестирование пользователей (UAT) и т.д. Даже в тех случаях, когда производственная инфраструктура используется для облегчения тестирования или разработки, производственные среды все равно должны быть отделены (логически или физически) от функциональных возможностей подготовки производства, чтобы уязвимости, возникающие в результате подготовительных действий, не оказывали негативного влияния на производственные системы.
Среды разработки и тестирования из-за постоянно меняющегося состояния часто менее безопасны, чем производственная среда.
Надлежащая практика:
Организации должны четко понимать, какие среды являются средами тестирования или средами разработки, и как эти среды взаимодействуют на уровне сетей и приложений.
Определения:
Предпроизводственные среды включают разработку, тестирование, приемочное тестирование пользователей (UAT) и т.д. Даже в тех случаях, когда производственная инфраструктура используется для облегчения тестирования или разработки, производственные среды все равно должны быть отделены (логически или физически) от функциональных возможностей подготовки производства, чтобы уязвимости, возникающие в результате подготовительных действий, не оказывали негативного влияния на производственные системы.
Requirement 6.2.1
6.2.1
Определенные Требования к Подходу:
Программное обеспечение на заказ и на заказ разрабатывается надежно, следующим образом:
Определенные Требования к Подходу:
Программное обеспечение на заказ и на заказ разрабатывается надежно, следующим образом:
- На основе отраслевых стандартов и/или лучших практик безопасной разработки.
- В соответствии с PCI DSS (например, безопасная аутентификация и ведение журнала).
- Учет вопросов информационной безопасности на каждом этапе жизненного цикла разработки программного обеспечения.
Цель Индивидуального подхода:
Индивидуальное и индивидуальное программное обеспечение разрабатывается в соответствии с PCI DSS и безопасными процессами разработки на протяжении всего жизненного цикла программного обеспечения.
Примечания по применению:
Это относится ко всему программному обеспечению, разработанному для организации или для ее собственного использования. Это включает в себя как индивидуальное, так и индивидуальное программное обеспечение. Это не относится к стороннему программному обеспечению.
Определенные Процедуры Тестирования Подхода:
Индивидуальное и индивидуальное программное обеспечение разрабатывается в соответствии с PCI DSS и безопасными процессами разработки на протяжении всего жизненного цикла программного обеспечения.
Примечания по применению:
Это относится ко всему программному обеспечению, разработанному для организации или для ее собственного использования. Это включает в себя как индивидуальное, так и индивидуальное программное обеспечение. Это не относится к стороннему программному обеспечению.
Определенные Процедуры Тестирования Подхода:
- 6.2.1 Изучите документированные процедуры разработки программного обеспечения, чтобы убедиться, что определены процессы, включающие все элементы, указанные в этом требовании.
Цель:
Без учета безопасности на этапах определения требований, проектирования, анализа и тестирования разработки программного обеспечения уязвимости безопасности могут быть непреднамеренно или злонамеренно внедрены в производственную среду.
Надлежащая практика:
Понимание того, как конфиденциальные данные обрабатываются приложением, в том числе при хранении, передаче и в памяти, может помочь определить, где данные нуждаются в защите.
Требования PCI DSS необходимо учитывать при разработке программного обеспечения, чтобы оно соответствовало этим требованиям по дизайну, а не пыталось модифицировать программное обеспечение позже.
Примеры:
Методологии и фреймворки безопасного управления жизненным циклом программного обеспечения включают PCI Software Security Framework, BSIMM, OPENSAMM и работы из NIST, ISO и SafeCode.
Без учета безопасности на этапах определения требований, проектирования, анализа и тестирования разработки программного обеспечения уязвимости безопасности могут быть непреднамеренно или злонамеренно внедрены в производственную среду.
Надлежащая практика:
Понимание того, как конфиденциальные данные обрабатываются приложением, в том числе при хранении, передаче и в памяти, может помочь определить, где данные нуждаются в защите.
Требования PCI DSS необходимо учитывать при разработке программного обеспечения, чтобы оно соответствовало этим требованиям по дизайну, а не пыталось модифицировать программное обеспечение позже.
Примеры:
Методологии и фреймворки безопасного управления жизненным циклом программного обеспечения включают PCI Software Security Framework, BSIMM, OPENSAMM и работы из NIST, ISO и SafeCode.
Requirement 6.2.4
6.2.4
Определенные Требования к Подходу:
Методы разработки программного обеспечения или другие методы определяются и используются персоналом по разработке программного обеспечения для предотвращения или смягчения распространенных программных атак и связанных с ними уязвимостей в программном обеспечении на заказ и на заказ, включая, но не ограничиваясь следующим:
Определенные Требования к Подходу:
Методы разработки программного обеспечения или другие методы определяются и используются персоналом по разработке программного обеспечения для предотвращения или смягчения распространенных программных атак и связанных с ними уязвимостей в программном обеспечении на заказ и на заказ, включая, но не ограничиваясь следующим:
- Инъекционные атаки, включая SQL, LDAP, XPath или другие ошибки типа команд, параметров, объектов, ошибок или ошибок типа инъекций.
- Атаки на данные и структуры данных, включая попытки манипулировать буферами, указателями, входными данными или общими данными.
- Атаки на использование криптографии, включая попытки использовать слабые, небезопасные или неподходящие криптографические реализации, алгоритмы, наборы шифров или режимы работы.
- Атаки на бизнес-логику, включая попытки злоупотребления или обхода функций и функциональных возможностей приложения посредством манипулирования API, протоколами и каналами связи, клиентскими функциями или другими системными/прикладными функциями и ресурсами. Это включает в себя межсайтовые скрипты (XSS) и подделку межсайтовых запросов (CSRF).
- Атаки на механизмы контроля доступа, включая попытки обойти или злоупотребить механизмами идентификации, аутентификации или авторизации, или попытки использовать слабые места в реализации таких механизмов.
- Атаки с использованием любых уязвимостей “высокого риска”, выявленных в процессе идентификации уязвимостей, как определено в требовании 6.3.1.
Цель Индивидуального подхода:
Сделанное на заказ и изготовленное на заказ программное обеспечение не может быть использовано с помощью обычных атак и связанных с ними уязвимостей.
Примечания по применению:
Это относится ко всему программному обеспечению, разработанному для организации или для ее собственного использования. Это включает в себя как индивидуальные, так и индивидуальные sof
Определенные Процедуры Тестирования Подхода:
Сделанное на заказ и изготовленное на заказ программное обеспечение не может быть использовано с помощью обычных атак и связанных с ними уязвимостей.
Примечания по применению:
Это относится ко всему программному обеспечению, разработанному для организации или для ее собственного использования. Это включает в себя как индивидуальные, так и индивидуальные sof
Определенные Процедуры Тестирования Подхода:
- 6.2.4 Изучить документированные процедуры и провести собеседование с ответственным персоналом по разработке программного обеспечения, чтобы убедиться, что методы разработки программного обеспечения или другие методы определены и используются разработчиками индивидуального и заказного программного обеспечения для предотвращения или смягчения всех распространенных программных атак, как указано в этом требовании.
Цель:
Обнаружение или предотвращение распространенных ошибок, приводящих к уязвимому коду, как можно раньше в процессе разработки программного обеспечения снижает вероятность того, что такие ошибки попадут в производство и приведут к компрометации. Наличие формальных инженерных методов и инструментов, встроенных в процесс разработки, позволит выявить эти ошибки на ранней стадии. Эту философию иногда называют “смещением безопасности влево”.
Надлежащая практика:
Как для индивидуального, так и для пользовательского программного обеспечения организация должна обеспечить разработку кода с упором на предотвращение или смягчение распространенных программных атак, включая:
Обнаружение или предотвращение распространенных ошибок, приводящих к уязвимому коду, как можно раньше в процессе разработки программного обеспечения снижает вероятность того, что такие ошибки попадут в производство и приведут к компрометации. Наличие формальных инженерных методов и инструментов, встроенных в процесс разработки, позволит выявить эти ошибки на ранней стадии. Эту философию иногда называют “смещением безопасности влево”.
Надлежащая практика:
Как для индивидуального, так и для пользовательского программного обеспечения организация должна обеспечить разработку кода с упором на предотвращение или смягчение распространенных программных атак, включая:
- Попытки использовать распространенные уязвимости в кодировании (ошибки).
- Попытки использовать недостатки дизайна программного обеспечения.
- Попытки использовать недостатки реализации/конфигурации.
- Атаки с перечислением – автоматизированные атаки, которые активно используются в платежах и злоупотребляют механизмами идентификации, аутентификации или авторизации. См. Статью в блоге PCI Perspectives “Остерегайтесь атак на тестирование учетных записей”.
Исследование и документирование методов разработки программного обеспечения или других методов помогает определить, как разработчики программного обеспечения предотвращают или смягчают различные программные атаки с помощью функций или контрмер, которые они встраивают в программное обеспечение. Это может включать механизмы идентификации/аутентификации, контроль доступа, процедуры проверки входных данных и т.д. Разработчики должны быть знакомы с различными типами уязвимостей и потенциальных атак и использовать меры, чтобы избежать потенциальных векторов атак при разработке кода.
Примеры:
Методы включают автоматизированные процессы и методы, которые сканируют код на ранней стадии цикла разработки, когда код проверяется для подтверждения отсутствия уязвимостей.
Примеры:
Методы включают автоматизированные процессы и методы, которые сканируют код на ранней стадии цикла разработки, когда код проверяется для подтверждения отсутствия уязвимостей.
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 Жизненный цикл безопасной разработки
Должны быть установлены и применяться правила безопасной разработки программного обеспечения и систем.
Должны быть установлены и применяться правила безопасной разработки программного обеспечения и систем.
NIST Cybersecurity Framework (EN):
PR.IP-3
PR.IP-3: Configuration change control processes are in place
PR.IP-1
PR.IP-1: A baseline configuration of information technology/industrial control systems is created and maintained incorporating security principles (e.g. concept of least functionality)
ГОСТ Р № ИСО/МЭК 27002-2021 от 30.11.2021 "Информационные технологии. Методы и средства обеспечения безопасности. Свод норм и правил применения мер обеспечения информационной безопасности":
14.2.2
14.2.2 Процедуры управления изменениями системы
Мера обеспечения ИБ
Необходимо управлять изменениями в системах в течение жизненного цикла разработки посредством применения формализованных процедур управления изменениями.
Руководство по применению
Формальные процедуры управления изменениями должны быть задокументированы и применены для обеспечения целостности системы, приложений и продуктов, начиная с ранних этапов проектирования и до всех последующих действий по поддержке. Внедрение новых систем и значительные изменения в существующих системах должны происходить в соответствии с формальным процессом документирования, спецификации, тестирования, контроля качества и управляемой реализации.
Этот процесс должен включать оценку риска, анализ последствий от изменений и определение необходимых мер обеспечения ИБ, а также должен гарантировать, что существующие меры не будут нарушены, что программистам поддержки предоставлен доступ только к тем частям системы, которые необходимы для их работы, и что получено формальное согласие на любые изменения и их одобрение.
Везде, где это практически возможно, процедуры управления изменениями для приложений и среды эксплуатации должны быть объединены (см. 12.1.2). Процедуры управления изменениями должны включать (но не ограничиваться этим) следующее:
- a) ведение учета согласованных уровней разрешений;
- b) обеспечение внесения изменений авторизованными пользователями;
- c) пересмотр процедур управления и целостности для гарантии того, что они не будут нарушены изменениями;
- d) идентификация всего программного обеспечения, информации, объектов базы данных и аппаратного обеспечения, которые требуют изменений;
- e) выявление и проверка критического с точки зрения безопасности кода для минимизации вероятности реализации известных ошибок программирования;
- f) получение официального одобрения на предлагаемые изменения до начала работ;
- g) обеспечение того, чтобы авторизованные пользователи одобрили все изменения до их реализации;
- h) обеспечение того, чтобы набор системной документации был обновлен по завершении каждого изменения, а старая документация архивировалась или удалялась;
- i) поддержание контроля версий всех обновлений программного обеспечения;
- j) ведение записей всех запросов на изменение;
- k) обеспечение того, чтобы эксплуатационная документация (см. 12.1.1) и пользовательские процедуры подвергались изменениям по мере необходимости и оставались актуальными;
- l) обеспечение того, чтобы внедрение изменений происходило в согласованное время и не нарушало вовлеченные бизнес-процессы.
Дополнительная информация
Так же как изменение программного обеспечения может повлиять на среду эксплуатации, так и наоборот.
Общепринятая практика включает в себя тестирование нового программного обеспечения в среде, отделенной как от среды эксплуатации, так и от среды разработки (см. 12.1.4). Это позволит иметь средства управления над новым программным обеспечением и обеспечивает дополнительную защиту эксплуатационной информации, которая используется в целях тестирования. Это относится к пакетам обновлений и исправлений, а также к прочим типам обновлений.
В тех случаях, где рассматривается автоматическое применение обновлений, риск в отношении целостности и доступности системы должен быть сопоставлен с преимуществами быстрого развертывания обновлений. Автоматические обновления не должны использоваться в критических системах, так как некоторые из них могут привести к сбою критических приложений.
Связанные защитные меры
Ничего не найдено
Мы используем cookie-файлы, чтобы получить статистику, которая помогает нам улучшить сервис для вас с целью персонализации сервисов и предложений. Вы может прочитать подробнее о cookie-файлах или изменить настройки браузера. Продолжая пользоваться сайтом, вы даёте согласие на использование ваших cookie-файлов и соглашаетесь с Политикой обработки персональных данных.