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

NIST Cybersecurity Framework (RU)

Framework

PR.IP-2

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

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

ГОСТ Р № 22301 от 01.01.2022 "Надежность в технике. Системы менеджмента непрерывности деятельности. Требования":
Р. 7 п. 5 пп. 3 ппп. 1
 7.5.3.1 Организация должна управлять документированной информацией, соответствующей требованиям СМНД и настоящему стандарту для обеспечения: 
  • а) доступности и пригодности ее использования, где и когда это необходимо; 
  • b) надлежащей защиты (например, от потери конфиденциальности, ненадлежащего использования или утраты целостности). 
ГОСТ Р № 57580.4-2022 от 01.02.2023 "Безопасность финансовых (банковских) операций. Обеспечение операционной надежности. Базовый состав организационных и технических мер. Раздел 7":
УИ.26
УИ.26 Управление уязвимостями на этапах жизненного цикла разработки объектов информатизации прикладного уровня (прикладного ПО), включая применение инструментов анализа (инспекции) кода (code review), посредством статического и динамического тестирования.
ГОСТ Р № ИСО/МЭК 27001-2021 от 01.01.2022 "Информационная технология. Методы и средства обеспечения безопасности. Системы менеджмента информационной безопасности. Требования - Приложение А":
A.14.2.5
A.14.2.5 Принципы безопасного проектирования систем 
Мера обеспечения информационной безопасности: Принципы безопасного проектирования систем должны быть установлены, документированы, поддерживаться и применяться к любым работам по реализации информационной системы 
A.6.1.5
A.6.1.5  Информационная безопасность при управлении проектом 
Мера обеспечения информационной безопасности: Информационную безопасность следует рассматривать при управлении проектом независимо от типа проекта 
A.14.2.1
A.14.2.1 Политика безопасной разработки 
Мера обеспечения информационной безопасности: Правила разработки программного обеспечения и систем должны быть установлены и применены к разработкам в рамках организации 
A.14.1.1
A.14.1.1 Анализ и спецификация требований информационной безопасности 
Мера обеспечения информационной безопасности: Требования, относящиеся к информационной безопасности, должны быть включены в перечень требований для новых информационных систем или для усовершенствования существующих информационных систем 
Стандарт № ИСО/МЭК 27001:2022(E) от 25.10.2022 "Информационная безопасность, кибербезопасность и защита частной жизни — Системы управления информационной безопасностью — Требования. Приложение А":
А.8.27
А.8.27 Архитектура и принципы проектирования безопасных систем
Для любой деятельности по разработке информационных систем должны быть установлены, задокументированы, поддерживаться и применяться принципы проектирования безопасных систем.
А.8.28
А.8.28 Безопасная разработка
При разработке программного обеспечения должны применяться принципы безопасной разработки программного обеспечения.
А.5.8
А.5.8 ИБ в управлении проектами
Информационная безопасность должна быть интегрирована в управление проектом.
А.8.26
А.8.26 Требования безопасности к приложениям
При разработке или приобретении приложений должны быть идентифицированы, точно определены и утверждены требования ИБ.
NIST Cybersecurity Framework (EN):
PR.IP-2 PR.IP-2: A System Development Life Cycle to manage systems is implemented
ГОСТ Р № ИСО/МЭК 27002-2021 от 30.11.2021 "Информационные технологии. Методы и средства обеспечения безопасности. Свод норм и правил применения мер обеспечения информационной безопасности":
14.1.1
14.1.1 Анализ и спецификация требований информационной безопасности

Мера обеспечения ИБ
Требования, относящиеся к ИБ, должны быть включены в перечень требований для новых информационных систем или для усовершенствования существующих информационных систем.

Руководство по применению
Требования ИБ должны быть идентифицированы с использованием различных методов, таких как выделение требований соответствия из политик и регламентов, моделирование угроз, анализ инцидентов или использование порогов уязвимости. Результаты идентификации должны быть задокументированы и рассмотрены всеми заинтересованными сторонами.
Требования и меры обеспечения ИБ должны отражать ценность информации (см. 8.2) и потенциальное негативное влияние на бизнес, которое может быть вызвано отсутствием надлежащей защиты.
Идентификация и управление требованиями ИБ и связанными с этими процессами должны быть интегрированы в проекты информационных систем на ранних стадиях. Раннее рассмотрение требований ИБ, например на этапе проектирования, может дать более эффективные и менее затратные решения.
Требования ИБ также должны учитывать:
  • a) требуемый уровень доверия в отношении идентификационной информации пользователей для установления требований к аутентификации пользователей;
  • b) процессы предоставления доступа как для пользователей, так и для привилегированных или технических пользователей;
  • c) информирование пользователей и операторов об их обязанностях и ответственности;
  • d) необходимый уровень защиты в отношении затронутых активов, в частности в отношении доступности, конфиденциальности и целостности;
  • e) требования, вытекающие из бизнес-процессов, такие как ведение журнала и мониторинг транзакций, требования по обеспечению неотказуемости;
  • f) требования, предписанные другими мерами обеспечения ИБ, например интерфейсы для систем регистрации, мониторинга или обнаружения утечки данных.
Для приложений, которые предоставляют услуги через общедоступные сети или осуществляют транзакции, следует рассмотреть меры обеспечения ИБ, которые приведены в 14.1.2 и 14.1.3.
В случае приобретения продукта следует придерживаться формального процесса тестирования и приобретения. В договорах с поставщиком должны быть учтены установленные требования безопасности. Если функциональные возможности обеспечения безопасности в предлагаемом продукте не удовлетворяют указанным требованиям, порождаемый этим риск и связанные с ним меры должны быть рассмотрены до того, как продукт будет приобретен.
Имеющееся руководство по настройке мер обеспечения безопасности продукта, соответствующее финальному стеку программного обеспечения/сервисов системы, должно быть оценено и выполнено.
Должны быть определены критерии приемки продуктов, например с точки зрения их функциональности, что даст гарантию того, что установленные требования безопасности будут выполнены. Продукты должны быть оценены по этим критериям до их приобретения. Дополнительный функционал продукта также должен быть рассмотрен, чтобы убедиться, что он не порождает дополнительных неприемлемых рисков.

Дополнительная информация
ИСО/МЭК 27005 [11] и ИСО 31000 [27] предоставляют руководство по применению процессов управления рисками для идентификации мер обеспечения ИБ и выполнения требований.
6.1.5
6.1.5 Информационная безопасность при управлении проектом

Мера обеспечения ИБ
ИБ должна рассматриваться при управлении проектом независимо от типа проекта.

Руководство по применению
ИБ должна быть интегрирована в метод(ы) управления проектами, чтобы гарантировать, что риски ИБ идентифицированы и обработаны в рамках проекта. Обычно это относится к любому проекту независимо от его характера, например проект для основного бизнес-процесса, ИТ, управления объектами и других вспомогательных процессов. Применяемые методы управления проектами должны предусматривать, что:
  • a) цели ИБ включены в цели проекта;
  • b) оценку риска ИБ проводят на ранней стадии проекта для определения необходимых вариантов его обработки;
  • c) ИБ является частью всех этапов применяемой методологии проекта.
Последствия для ИБ следует регулярно анализировать и пересматривать во всех проектах. Ответственность за ИБ должна быть установлена и распределена между точно определенными ролями, которые заданы в методах управления проектом.
14.2.1
14.2.1 Политика безопасной разработки

Мера обеспечения ИБ
Правила разработки программного обеспечения и систем должны быть установлены и применены к разработкам в рамках организации.

Руководство по применению
Безопасная разработка - это требование для создания безопасного сервиса, архитектуры, программного обеспечения и системы. В рамках политики безопасной разработки должны быть учтены следующие аспекты:
  • a) безопасность среды разработки;
  • b) руководство по безопасности в жизненном цикле разработки программного обеспечения:
  1. безопасность в методологии разработки программного обеспечения;
  2. правила по безопасному программированию для каждого используемого языка программирования;
  • c) требования безопасности на этапе проектирования;
  • d) контрольные точки по проверке безопасности в рамках основных этапов проекта;
  • e) безопасные репозитории;
  • f) безопасность в управлении версиями;
  • g) необходимые знания по безопасности приложений;
  • h) способность разработчиков избегать, находить и исправлять уязвимости.
Методы безопасного программирования должны применяться как в отношении новых разработок, так и в случае повторного использования кода, при разработке которого использованы неизвестные стандарты или использованные стандарты не соответствуют лучшим практикам. Следует рассмотреть и, в случае необходимости, сделать обязательными для применения стандарты безопасного программирования. Разработчики должны быть обучены применению этих стандартов и тестированию, а анализ кода должен служить проверкой их использования.
Если разработка осуществляется на аутсорсинге, организация должна получить гарантии того, что внешняя сторона соблюдает правила по безопасной разработке (см. 14.2.7).

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

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

Руководство по применению
Процедуры безопасного проектирования информационных систем, основанные на указанных выше принципах, должны быть установлены, задокументированы и применены к внутренним процессам по проектированию информационных систем. Безопасность должна проектироваться на всех уровнях архитектуры (бизнес, данные, приложения и технологии), чтобы сбалансировать потребность в ИБ и удобстве. Новые технологии должны быть проанализированы на предмет угроз безопасности, а решения должны быть рассмотрены с точки зрения известных шаблонов атак.
Эти принципы и установленные процедуры проектирования должны регулярно пересматриваться, чтобы гарантировать, что они эффективно способствуют развитию стандартов безопасности в процессе проектирования. Их также следует регулярно пересматривать, чтобы обеспечить их актуальность с точки зрения борьбы с любыми потенциальными новыми угрозами и их пригодности к постоянно улучшающимся применяемым технологиям и решениям.
Установленные принципы безопасного проектирования должны применяться, по возможности, к информационным системам, находящимся на аутсорсинге, при помощи обязательных соглашений и контрактов между организацией и поставщиком. Организация должна подтвердить, что строгость принципов безопасного проектирования сопоставима с ее собственными.

Дополнительная информация
Процедуры разработки приложений должны применять методы безопасного проектирования при разработке приложений, имеющих интерфейсы ввода и вывода. Методы безопасного проектирования предоставляют методическую основу для методов аутентификации пользователей, безопасного управления сессиями и валидации данных, санитизации и удаления отладочной информации.
Стандарт № 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.
А.8.26
А.8.26 Application security requirements
Information security requirements shall be identified, specified and approved when developing or acquiring applications.
А.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.
А.5.8
А.5.8 Information security in project management
Information security shall be integrated into project management.

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

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

Мы используем cookie-файлы, чтобы получить статистику, которая помогает нам улучшить сервис для вас с целью персонализации сервисов и предложений. Вы может прочитать подробнее о cookie-файлах или изменить настройки браузера. Продолжая пользоваться сайтом, вы даёте согласие на использование ваших cookie-файлов и соглашаетесь с Политикой обработки персональных данных.