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

ГОСТ Р № 57580.1-2017 от 01.01.2018

Безопасность финансовых (банковских) операций. Защита информации финансовых организаций. Базовый состав организационных и технических мер. Раздел 9. Требования к защите информации на этапах жизненного цикла автоматизированных систем и приложений

ЖЦ.6

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

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

Приказ ФСТЭК России № 21 от 18.02.2013 "Состав и содержание мер по обеспечению безопасности персональных данных, необходимых для обеспечения каждого из уровней защищенности персональных данных":
УПД.2 УПД.2 Реализация необходимых методов (дискреционный, мандатный, ролевой или иной метод), типов (чтение, запись, выполнение или иной тип) и правил разграничения доступа
ГОСТ Р № ИСО/МЭК 27001-2021 от 01.01.2022 "Информационная технология. Методы и средства обеспечения безопасности. Системы менеджмента информационной безопасности. Требования - Приложение А":
A.12.1.4
A.12.1.4 Разделение сред разработки, тестирования и эксплуатации 
Мера обеспечения информационной безопасности: Для снижения рисков несанкционированного доступа или изменений среды эксплуатации необходимо обеспечивать разделение сред разработки, тестирования и эксплуатации 
A.9.2.2
A.9.2.2 Предоставление пользователю права доступа 
Мера обеспечения информационной безопасности: Должен быть реализован формализованный процесс назначения или отмены прав доступа пользователей к системам и сервисам 
Приказ ФСТЭК России № 17 от 11.02.2013 "Требования о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах":
УПД.2 УПД.2 Реализация необходимых методов (дискреционный, мандатный, ролевой или иной метод), типов (чтение, запись, выполнение или иной тип) и правил разграничения доступа
Стандарт № ИСО/МЭК 27001:2022(E) от 25.10.2022 "Информационная безопасность, кибербезопасность и защита частной жизни — Системы управления информационной безопасностью — Требования. Приложение А":
А.5.18
А.5.18 Права доступа
Права доступа к информационным и иным связанным с ней активам должны предоставляться, пересматриваться, изменяться и удаляться в соответствии с специфической тематической политикой и правилами управления доступом организации.
А.8.31
А.8.31 Разделение сред разработки, тестирования и производства
Должны быть разделены и защищены среды разработки, тестирования и производства.
Приказ ФСТЭК России № 239 от 25.12.2017 "Состав мер по обеспечению безопасности для значимого объекта соответствующей категории значимости":
УПД.2 УПД.2 Реализация модели управления доступом
ГОСТ Р № ИСО/МЭК 27002-2021 от 30.11.2021 "Информационные технологии. Методы и средства обеспечения безопасности. Свод норм и правил применения мер обеспечения информационной безопасности":
12.1.4
12.1.4 Разделение сред разработки, тестирования и эксплуатации

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

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

Дополнительная информация
Действия в ходе разработки и тестирования могут вызывать серьезные проблемы, например случайное изменение файлов, системной среды или системные сбои. Необходимо поддерживать понятную и стабильную среду, в которой можно проводить полноценное тестирование и предотвращать несанкционированный доступ разработчиков к среде эксплуатации.
Там, где персонал, занимающийся разработкой и тестированием, имеет доступ к среде эксплуатации и ее информации, он может иметь возможность внедрить неавторизованный и непроверенный код или изменить эксплуатационные данные. В некоторых системах эта возможность может использоваться для совершения мошенничества, внедрения непроверенного или вредоносного кода, что может вызвать серьезные проблемы в среде эксплуатации.
Персонал, занимающийся разработкой и тестированием, также представляет собой угрозу конфиденциальности эксплуатационной информации. Действия по разработке и тестированию могут привести к непреднамеренным изменениям программного обеспечения или информации, если они выполняются в одной вычислительной среде. Поэтому желательно разделять среду разработки, тестирования и эксплуатации, чтобы снизить риск случайного изменения или несанкционированного доступа к эксплуатируемому программного обеспечению и бизнес-данным (см. 14.3 о защите тестовых данных).
9.2.2
9.2.2 Предоставление пользователю права доступа

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

Руководство по применению
Процесс предоставления доступа для назначения или аннулирования прав доступа для идентификаторов пользователей должен включать в себя:
  • a) получение разрешения от владельца информационной системы или сервиса на использование этой информационной системы или сервиса (см. 8.1.2); также может быть целесообразным разделение подтверждения прав доступа от управления;
  • b) проверку того, что предоставляемый уровень доступа соответствует политикам доступа (см. 9.1) и согласуется с другими требованиями, такими как разделение обязанностей (см. 6.1.2);
  • c) обеспечение того, что права доступа не будут активированы (например, поставщиками услуг) до завершения процедур аутентификации;
  • d) ведение централизованной регистрации прав доступа, связываемых с идентификатором пользователя, к информационным системам и сервисам;
  • e) корректировку прав доступа пользователей, у которых поменялись роли или задачи, а также немедленное удаление или блокирование прав доступа пользователей, покинувших организацию;
  • f) периодический пересмотр права доступа совместно с владельцами информационных систем или сервисов (см. 9.2.5).

Дополнительная информация
Следует рассмотреть вопрос о создании ролей пользователей, которые вытекают из требований бизнеса и определяют права доступа для пользователей, объединяя ряд прав доступа в типовые профили доступа пользователей. Запросы на доступ и пересмотр прав доступа (см. 9.2.4) легче обрабатывать на уровне таких ролей, чем на уровне отдельных прав.
Следует рассмотреть вопрос включения в контракты с работниками и подрядчиками положений, предусматривающих санкции в случае совершения работником или подрядчиком попыток несанкционированного доступа (см. 7.1.2, 7.2.3, 13.2.4; 15.1.2).
Стандарт № ISO/IEC 27001:2022(E) от 25.10.2022 "Information security, cybersecurity and privacy protection — Information security management systems — Requirements. Annex A":
А.5.18
А.5.18 Access rights
Access rights to information and other associated assets shall be provisioned, reviewed, modified and removed in accordance with the organization’s topic-specific policy on and rules for access control.
А.8.31
А.8.31 Separation of development, test and production environments
Development, testing and production environments shall be separated and secured.

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

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

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