Куда я попал?
ГОСТ Р № ИСО/МЭК 27001-2021 от 01.01.2022
Информационная технология. Методы и средства обеспечения безопасности. Системы менеджмента информационной безопасности. Требования - Приложение А
A.14.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.
16.9
16.9 Train Developers in Application Security Concepts and Secure Coding
Ensure that all software development personnel receive training in writing secure code for their specific development environment and responsibilities. Training can include general security principles and application security standard practices. Conduct training at least annually and design
Ensure that all software development personnel receive training in writing secure code for their specific development environment and responsibilities. Training can include general security principles and application security standard practices. Conduct training at least annually and design
16.3
16.3 Perform Root Cause Analysis on Security Vulnerabilities
Perform root cause analysis on security vulnerabilities. When reviewing vulnerabilities, root cause analysis is the task of evaluating underlying issues that create vulnerabilities in code, and allows development teams to move beyond just fixing individual vulnerabilities as they arise.
Perform root cause analysis on security vulnerabilities. When reviewing vulnerabilities, root cause analysis is the task of evaluating underlying issues that create vulnerabilities in code, and allows development teams to move beyond just fixing individual vulnerabilities as they arise.
NIST Cybersecurity Framework (RU):
PR.IP-2
PR.IP-2: Реализован жизненный цикл разработки систем (SDLC) для управления системами
ГОСТ Р № 57580.4-2022 от 01.02.2023 "Безопасность финансовых (банковских) операций. Обеспечение операционной надежности. Базовый состав организационных и технических мер. Раздел 7":
УИ.25.5
УИ.25.5 Применение отдельных сред разработки, тестирования и постоянной эксплуатации, обеспечивающих возможность быстрого тестирования.
УИ.26
УИ.26 Управление уязвимостями на этапах жизненного цикла разработки объектов информатизации прикладного уровня (прикладного ПО), включая применение инструментов анализа (инспекции) кода (code review), посредством статического и динамического тестирования.
Russian Unified Cyber Security Framework (на основе The 18 CIS CSC):
16.1
16.1 Реализован и поддерживается процесс безопасной разработки программного обеспечения
Описание процесса включает стандарты безопасного проектирования ПО, стандарты безопасного написания кода, регулярное обучение разработчиков, управление уязвимостями, контроль сторонней разработки и процедуры тестирования ПО.
Описание процесса включает стандарты безопасного проектирования ПО, стандарты безопасного написания кода, регулярное обучение разработчиков, управление уязвимостями, контроль сторонней разработки и процедуры тестирования ПО.
16.9
16.9 Проводится обучение разработчиков практикам безопасной разработки программного обеспечения
Разработчики проходят обучение по информационной безопасности раз в год или чаще.
В командах поддерживается культура безопасной разработки.
Разработчики проходят обучение по информационной безопасности раз в год или чаще.
В командах поддерживается культура безопасной разработки.
16.3
16.3 Реализовано выполнение анализа первопричин уязвимостей прикладного программного обеспечения
Найдены глубинные причины уязвимостей, которые позволяют уменьшить количество критичных замечаний по безопасности.
Найдены глубинные причины уязвимостей, которые позволяют уменьшить количество критичных замечаний по безопасности.
Framework № PCI DSS 4.0 от 01.03.2022 "Payment Card Industry Data Security Standard":
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.
Guideline for a healthy information system v.2.0 (EN):
2 STRENGTHENED
/STRENGTHENED
To strengthen these measures, the creation and signature of an IT resource charter specifying the rules and instructions that must be adhered to by users may be considered.
To strengthen these measures, the creation and signature of an IT resource charter specifying the rules and instructions that must be adhered to by users may be considered.
CIS Critical Security Controls v7.1 (SANS Top 20):
CSC 18.1
CSC 18.1 Establish Secure Coding Practices
Establish secure coding practices appropriate to the programming language and development environment being used.
Establish secure coding practices appropriate to the programming language and development environment being used.
CSC 18.6
CSC 18.6 Ensure Software Development Personnel are Trained in Secure Coding
Ensure that all software development personnel receive training in writing secure code for their specific development environment and responsibilities.
Ensure that all software development personnel receive training in writing secure code for their specific development environment and responsibilities.
Framework № PCI DSS 4.0 от 01.03.2022 "Payment Card Industry Data Security Standard (RU)":
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.
Стандарт № ИСО/МЭК 27001:2022(E) от 25.10.2022 "Информационная безопасность, кибербезопасность и защита частной жизни — Системы управления информационной безопасностью — Требования. Приложение А":
А.8.28
А.8.28 Безопасная разработка
При разработке программного обеспечения должны применяться принципы безопасной разработки программного обеспечения.
При разработке программного обеспечения должны применяться принципы безопасной разработки программного обеспечения.
Приказ ФСТЭК России № 31 от 14.03.2014 "Состав мер защиты информации и их базовые наборы для соответствующего класса защищенности автоматизированной системы управления":
УКФ.0
УКФ.0 Разработка политики управления конфигурацией информационной (автоматизированной) системы
NIST Cybersecurity Framework (EN):
PR.IP-2
PR.IP-2: A System Development Life Cycle to manage systems is implemented
Приказ ФСТЭК России № 239 от 25.12.2017 "Состав мер по обеспечению безопасности для значимого объекта соответствующей категории значимости":
УКФ.0
УКФ.0 Регламентация правил и процедур управления конфигурацией информационной (автоматизированной) системы
Стандарт № ISO/IEC 27001:2022(E) от 25.10.2022 "Information security, cybersecurity and privacy protection — Information security management systems — Requirements. Annex A":
А.8.28
А.8.28 Secure coding
Secure coding principles shall be applied to software development.
Secure coding principles shall be applied to software development.
Связанные защитные меры
Ничего не найдено
Мы используем cookie-файлы, чтобы получить статистику, которая помогает нам улучшить сервис для вас с целью персонализации сервисов и предложений. Вы может прочитать подробнее о cookie-файлах или изменить настройки браузера. Продолжая пользоваться сайтом, вы даёте согласие на использование ваших cookie-файлов и соглашаетесь с Политикой обработки персональных данных.