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

Framework № PCI DSS 4.0 от 01.03.2022

Payment Card Industry Data Security Standard (RU)

Requirement 6.2.3.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: 
  • 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:
  • 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. 
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.
Стандарт № ИСО/МЭК 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. 

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

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