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

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

Framework

CSC 18.2

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

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

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. 
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:
  • 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:
  • 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: 
  • 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. 
ГОСТ Р № ИСО/МЭК 27001-2021 от 01.01.2022 "Информационная технология. Методы и средства обеспечения безопасности. Системы менеджмента информационной безопасности. Требования - Приложение А":
A.14.2.5
A.14.2.5 Принципы безопасного проектирования систем 
Мера обеспечения информационной безопасности: Принципы безопасного проектирования систем должны быть установлены, документированы, поддерживаться и применяться к любым работам по реализации информационной системы 
A.14.2.8
A.14.2.8 Тестирование безопасности систем 
Мера обеспечения информационной безопасности: Тестирование функциональных возможностей безопасности должно осуществляться в процессе разработки 
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.
Requirement 6.2.4
6.2.4
Определенные Требования к Подходу:
Методы разработки программного обеспечения или другие методы определяются и используются персоналом по разработке программного обеспечения для предотвращения или смягчения распространенных программных атак и связанных с ними уязвимостей в программном обеспечении на заказ и на заказ, включая, но не ограничиваясь следующим:
  • Инъекционные атаки, включая SQL, LDAP, XPath или другие ошибки типа команд, параметров, объектов, ошибок или ошибок типа инъекций.
  • Атаки на данные и структуры данных, включая попытки манипулировать буферами, указателями, входными данными или общими данными.
  • Атаки на использование криптографии, включая попытки использовать слабые, небезопасные или неподходящие криптографические реализации, алгоритмы, наборы шифров или режимы работы.
  • Атаки на бизнес-логику, включая попытки злоупотребления или обхода функций и функциональных возможностей приложения посредством манипулирования API, протоколами и каналами связи, клиентскими функциями или другими системными/прикладными функциями и ресурсами. Это включает в себя межсайтовые скрипты (XSS) и подделку межсайтовых запросов (CSRF).
  • Атаки на механизмы контроля доступа, включая попытки обойти или злоупотребить механизмами идентификации, аутентификации или авторизации, или попытки использовать слабые места в реализации таких механизмов.
  • Атаки с использованием любых уязвимостей “высокого риска”, выявленных в процессе идентификации уязвимостей, как определено в требовании 6.3.1.
Цель Индивидуального подхода:
Сделанное на заказ и изготовленное на заказ программное обеспечение не может быть использовано с помощью обычных атак и связанных с ними уязвимостей.

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

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

Надлежащая практика:
Как для индивидуального, так и для пользовательского программного обеспечения организация должна обеспечить разработку кода с упором на предотвращение или смягчение распространенных программных атак, включая:
  • Попытки использовать распространенные уязвимости в кодировании (ошибки).
  • Попытки использовать недостатки дизайна программного обеспечения.
  • Попытки использовать недостатки реализации/конфигурации.
  • Атаки с перечислением – автоматизированные атаки, которые активно используются в платежах и злоупотребляют механизмами идентификации, аутентификации или авторизации. См. Статью в блоге PCI Perspectives “Остерегайтесь атак на тестирование учетных записей”.
Исследование и документирование методов разработки программного обеспечения или других методов помогает определить, как разработчики программного обеспечения предотвращают или смягчают различные программные атаки с помощью функций или контрмер, которые они встраивают в программное обеспечение. Это может включать механизмы идентификации/аутентификации, контроль доступа, процедуры проверки входных данных и т.д. Разработчики должны быть знакомы с различными типами уязвимостей и потенциальных атак и использовать меры, чтобы избежать потенциальных векторов атак при разработке кода.

Примеры:
Методы включают автоматизированные процессы и методы, которые сканируют код на ранней стадии цикла разработки, когда код проверяется для подтверждения отсутствия уязвимостей.
Стандарт № ИСО/МЭК 27001:2022(E) от 25.10.2022 "Информационная безопасность, кибербезопасность и защита частной жизни — Системы управления информационной безопасностью — Требования. Приложение А":
А.8.29
А.8.29 Тестирование безопасности в разработке и приемке
В жизненном цикле разработки должны быть определены и внедрены процессы тестирования безопасности разрабатываемого продукта.
А.8.27
А.8.27 Архитектура и принципы проектирования безопасных систем
Для любой деятельности по разработке информационных систем должны быть установлены, задокументированы, поддерживаться и применяться принципы проектирования безопасных систем.
Стандарт № ISO/IEC 27001:2022(E) от 25.10.2022 "Information security, cybersecurity and privacy protection — Information security management systems — Requirements. Annex A":
А.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
А.8.29 Security testing in development and acceptance
Security testing processes shall be defined and implemented in the development life cycle.

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

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