Куда я попал?
CIS Critical Security Controls v8 (The 18 CIS CSC)
Framework
16.1
Для проведения оценки соответствия по документу войдите в систему.
Список требований
Похожие требования
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.
ГОСТ Р № ИСО/МЭК 27001-2021 от 01.01.2022 "Информационная технология. Методы и средства обеспечения безопасности. Системы менеджмента информационной безопасности. Требования - Приложение А":
A.14.2.1
A.14.2.1 Политика безопасной разработки
Мера обеспечения информационной безопасности: Правила разработки программного обеспечения и систем должны быть установлены и применены к разработкам в рамках организации
Мера обеспечения информационной безопасности: Правила разработки программного обеспечения и систем должны быть установлены и применены к разработкам в рамках организации
A.9.4.5
A.9.4.5 Управление доступом к исходному тексту программы
Мера обеспечения информационной безопасности: Доступ к исходному тексту программы должен быть ограничен
Мера обеспечения информационной безопасности: Доступ к исходному тексту программы должен быть ограничен
A.12.1.4
A.12.1.4 Разделение сред разработки, тестирования и эксплуатации
Мера обеспечения информационной безопасности: Для снижения рисков несанкционированного доступа или изменений среды эксплуатации необходимо обеспечивать разделение сред разработки, тестирования и эксплуатации
Мера обеспечения информационной безопасности: Для снижения рисков несанкционированного доступа или изменений среды эксплуатации необходимо обеспечивать разделение сред разработки, тестирования и эксплуатации
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.
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.4
А.8.4 Доступ к исходному коду
Должен управляться соответствующим образом доступ к исходному коду, а также к средствам разработки и программным библиотекам.
Должен управляться соответствующим образом доступ к исходному коду, а также к средствам разработки и программным библиотекам.
А.8.25
А.8.25 Жизненный цикл безопасной разработки
Должны быть установлены и применяться правила безопасной разработки программного обеспечения и систем.
Должны быть установлены и применяться правила безопасной разработки программного обеспечения и систем.
А.8.28
А.8.28 Безопасная разработка
При разработке программного обеспечения должны применяться принципы безопасной разработки программного обеспечения.
При разработке программного обеспечения должны применяться принципы безопасной разработки программного обеспечения.
А.8.31
А.8.31 Разделение сред разработки, тестирования и производства
Должны быть разделены и защищены среды разработки, тестирования и производства.
Должны быть разделены и защищены среды разработки, тестирования и производства.
ГОСТ Р № ИСО/МЭК 27002-2021 от 30.11.2021 "Информационные технологии. Методы и средства обеспечения безопасности. Свод норм и правил применения мер обеспечения информационной безопасности":
12.1.4
12.1.4 Разделение сред разработки, тестирования и эксплуатации
Мера обеспечения ИБ
Для снижения рисков несанкционированного доступа или изменений среды эксплуатации необходимо обеспечивать разделение сред разработки, тестирования и эксплуатации.
Руководство по применению
Должен быть определен и реализован необходимый для предотвращения эксплуатационных проблем уровень разделения среды разработки, тестирования и эксплуатации.
Необходимо принять во внимание следующие пункты:
- a) правила перевода программного обеспечения из состояния разработки в состояние эксплуатации должны быть определены и задокументированы;
- b) программное обеспечение для разработки и эксплуатации должно быть развернуто на разных системах или компьютерах и в разных доменах или каталогах;
- c) изменения в эксплуатируемых системах и приложениях должны быть протестированы в тестовой или промежуточной среде перед их применением;
- d) кроме как при возникновении исключительных ситуаций, тестирование не должно проводиться на эксплуатируемой среде;
- e) компиляторы, редакторы и другие средства разработки или системные служебные программы не должны быть доступны из среды эксплуатации без необходимости;
- f) пользователи должны использовать разные профили для сред эксплуатации и тестирования, а на экране должны отображаться соответствующие предупреждающие сообщения, чтобы снизить риск ошибки;
- g) конфиденциальные данные не должны копироваться в среду системы тестирования, если для системы тестирования не предусмотрены эквивалентные меры обеспечения ИБ (см. 14.3).
Дополнительная информация
Действия в ходе разработки и тестирования могут вызывать серьезные проблемы, например случайное изменение файлов, системной среды или системные сбои. Необходимо поддерживать понятную и стабильную среду, в которой можно проводить полноценное тестирование и предотвращать несанкционированный доступ разработчиков к среде эксплуатации.
Там, где персонал, занимающийся разработкой и тестированием, имеет доступ к среде эксплуатации и ее информации, он может иметь возможность внедрить неавторизованный и непроверенный код или изменить эксплуатационные данные. В некоторых системах эта возможность может использоваться для совершения мошенничества, внедрения непроверенного или вредоносного кода, что может вызвать серьезные проблемы в среде эксплуатации.
Персонал, занимающийся разработкой и тестированием, также представляет собой угрозу конфиденциальности эксплуатационной информации. Действия по разработке и тестированию могут привести к непреднамеренным изменениям программного обеспечения или информации, если они выполняются в одной вычислительной среде. Поэтому желательно разделять среду разработки, тестирования и эксплуатации, чтобы снизить риск случайного изменения или несанкционированного доступа к эксплуатируемому программного обеспечению и бизнес-данным (см. 14.3 о защите тестовых данных).
9.4.5
9.4.5 Управление доступом к исходному коду программы
Мера обеспечения ИБ
Доступ к исходному коду программ должен быть ограничен.
Руководство по применению
Доступ к исходному коду программы и связанным с ним элементам (таким, как проекты, спецификации, планы верификации и валидации) должен строго контролироваться для того, чтобы предотвратить внедрение в него несанкционированного функционала и избежать непреднамеренных изменений, а также сохранить конфиденциальность ценной интеллектуальной собственности. Для исходного кода программы это может быть достигнуто путем контролируемого централизованного хранения такого кода, предпочтительно в библиотеках исходных кодов программ. Затем следует учесть следующие рекомендации для управления доступом к таким библиотекам исходных кодов программ для того, чтобы уменьшить вероятность повреждения компьютерных программ:
- a) где это возможно, библиотеки исходных кодов программ не должны содержаться в эксплуатируемых системах;
- b) исходный код программы и библиотеки исходных кодов программы должны управляться в соответствии с установленными процедурами;
- c) вспомогательный персонал не должен иметь неограниченный доступ к библиотекам исходных кодов программы;
- d) обновление библиотек исходных кодов программ и связанных с ними элементов, а также выдача исходного кода программистам должна выполняться только после прохождения соответствующей авторизации;
- e) листинги программ должны храниться в безопасной среде;
- f) должны сохраняться записи всех обращений к библиотекам исходных кодов;
- g) обслуживание и копирование библиотек исходных кодов должно проводиться по строгим процедурам контроля изменений (см. 14.2.2).
Если исходный код программы предполагается публиковать, следует принять во внимание дополнительные меры обеспечения ИБ для получения гарантии его целостности (например, электронная подпись).
14.2.1
14.2.1 Политика безопасной разработки
Мера обеспечения ИБ
Правила разработки программного обеспечения и систем должны быть установлены и применены к разработкам в рамках организации.
Руководство по применению
Безопасная разработка - это требование для создания безопасного сервиса, архитектуры, программного обеспечения и системы. В рамках политики безопасной разработки должны быть учтены следующие аспекты:
- a) безопасность среды разработки;
- b) руководство по безопасности в жизненном цикле разработки программного обеспечения:
- безопасность в методологии разработки программного обеспечения;
- правила по безопасному программированию для каждого используемого языка программирования;
- c) требования безопасности на этапе проектирования;
- d) контрольные точки по проверке безопасности в рамках основных этапов проекта;
- e) безопасные репозитории;
- f) безопасность в управлении версиями;
- g) необходимые знания по безопасности приложений;
- h) способность разработчиков избегать, находить и исправлять уязвимости.
Методы безопасного программирования должны применяться как в отношении новых разработок, так и в случае повторного использования кода, при разработке которого использованы неизвестные стандарты или использованные стандарты не соответствуют лучшим практикам. Следует рассмотреть и, в случае необходимости, сделать обязательными для применения стандарты безопасного программирования. Разработчики должны быть обучены применению этих стандартов и тестированию, а анализ кода должен служить проверкой их использования.
Если разработка осуществляется на аутсорсинге, организация должна получить гарантии того, что внешняя сторона соблюдает правила по безопасной разработке (см. 14.2.7).
Дополнительная информация
Разработка также может вестись внутри самих приложений, например в офисных приложениях, скриптах, браузерах и базах данных.
Стандарт № 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.
А.8.4
А.8.4 Access to source code
Read and write access to source code, development tools and software libraries shall be appropriately managed.
Read and write access to source code, development tools and software libraries shall be appropriately managed.
А.8.25
А.8.25 Secure development life cycle
Rules for the secure development of software and systems shall be established and applied.
Rules for the secure development of software and systems shall be established and applied.
А.8.31
А.8.31 Separation of development, test and production environments
Development, testing and production environments shall be separated and secured.
Development, testing and production environments shall be separated and secured.
Связанные защитные меры
Ничего не найдено
Мы используем cookie-файлы, чтобы получить статистику, которая помогает нам улучшить сервис для вас с целью персонализации сервисов и предложений. Вы может прочитать подробнее о cookie-файлах или изменить настройки браузера. Продолжая пользоваться сайтом, вы даёте согласие на использование ваших cookie-файлов и соглашаетесь с Политикой обработки персональных данных.