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

CIS Critical Security Controls v8 (The 18 CIS CSC)

Framework

16.12

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

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

Framework № PCI DSS 4.0 от 01.03.2022 "Payment Card Industry Data Security Standard":
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: 
  • 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:
  • 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:
  • 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. 
CIS Critical Security Controls v7.1 (SANS Top 20):
CSC 18.7 CSC 18.7 Apply Static and Dynamic Code Analysis Tools
Apply static and dynamic analysis tools to verify that secure coding practices are being adhered to for internally developed software.
Framework № PCI DSS 4.0 от 01.03.2022 "Payment Card Industry Data Security Standard (RU)":
Requirement 6.2.3
6.2.3
Определенные Требования к Подходу:
Разработанное на заказ и заказное программное обеспечение проверяется перед выпуском в производство или для клиентов, чтобы выявить и исправить потенциальные уязвимости в коде следующим образом:
  • Проверка кода гарантирует, что код разрабатывается в соответствии с рекомендациями по безопасному кодированию.
  • Анализ кода направлен на выявление как существующих, так и новых уязвимостей программного обеспечения.
  • Соответствующие исправления вносятся до выпуска
Цель Индивидуального подхода:
Сделанное на заказ и изготовленное на заказ программное обеспечение не может быть использовано с помощью уязвимостей в кодировании.

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

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

Надлежащая практика:
Следующие пункты следует рассмотреть для включения в обзоры кода:
  • Поиск недокументированных функций (инструменты имплантации, бэкдоры).
  • Подтверждение того, что программное обеспечение безопасно использует функции внешних компонентов (библиотеки, фреймворки, API и т.д.). Например, если используется сторонняя библиотека, предоставляющая криптографические функции, убедитесь, что она была надежно интегрирована.
  • Проверка правильного использования ведения журнала для предотвращения попадания конфиденциальных данных в журналы.
  • Анализ небезопасных структур кода, которые могут содержать потенциальные уязвимости, связанные с распространенными программными атаками, определенными в Требованиях 6.2.5.
  • Проверка поведения приложения на предмет обнаружения логических уязвимостей.

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

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