CIS Critical Security Controls v7.1 (SANS Top 20)

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.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:

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:

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: 

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. 

A.14.2.5 Принципы безопасного проектирования систем 
Мера обеспечения информационной безопасности: Принципы безопасного проектирования систем должны быть установлены, документированы, поддерживаться и применяться к любым работам по реализации информационной системы 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Исследование и документирование методов разработки программного обеспечения или других методов помогает определить, как разработчики программного обеспечения предотвращают или смягчают различные программные атаки с помощью функций или контрмер, которые они встраивают в программное обеспечение. Это может включать механизмы идентификации/аутентификации, контроль доступа, процедуры проверки входных данных и т.д. Разработчики должны быть знакомы с различными типами уязвимостей и потенциальных атак и использовать меры, чтобы избежать потенциальных векторов атак при разработке кода.

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

А.8.29 Тестирование безопасности в разработке и приемке
В жизненном цикле разработки должны быть определены и внедрены процессы тестирования безопасности разрабатываемого продукта.

А.8.27 Архитектура и принципы проектирования безопасных систем
Для любой деятельности по разработке информационных систем должны быть установлены, задокументированы, поддерживаться и применяться принципы проектирования безопасных систем.

А.8.27 Secure system architecture and engineering principles
Principles for engineering secure systems shall be established, documented, maintained and applied to any information system development activities.

А.8.29 Security testing in development and acceptance
Security testing processes shall be defined and implemented in the development life cycle.