Куда я попал?
ГОСТ Р № 57580.4-2022 от 01.02.2023
Безопасность финансовых (банковских) операций. Обеспечение операционной надежности. Базовый состав организационных и технических мер. Раздел 7
УИ.11.1
Для проведения оценки соответствия по документу войдите в систему.
Список требований
Похожие требования
Положение Банка России № 787-П от 12.01.2022 "Обязательные для кредитных организаций требованиях к операционной надежности при осуществлении банковской деятельности в целях обеспечения непрерывности оказания банковских услуг":
п. 6
6. Кредитные организации должны разработать во внутренних документах и выполнять требования к операционной надежности, которые включают в себя:
- требования к порядку определения значений целевых показателей операционной надежности и обеспечению контроля за их соблюдением;
- требования к идентификации состава элементов, указанных в подпункте 6.1 настоящего пункта;
- требования к управлению изменениями элементов, указанных в подпункте 6.1 настоящего пункта;
- требования к выявлению, регистрации инцидентов операционной надежности и реагированию на них, а также восстановлению выполнения технологических процессов и функционирования объектов информационной инфраструктуры после реализации указанных инцидентов с учетом установленных главой 7 Положения Банка России N 716-П требований к выявлению событий риска информационной безопасности, порядку реагирования на выявленные события риска информационной безопасности и восстановлению деятельности кредитной организации в случае реализации таких событий;
- требования к взаимодействию с третьими лицами (внешними подрядчиками, контрагентами, участниками банковской группы), оказывающими услуги в сфере информационных технологий, связанные с выполнением технологических процессов (далее - поставщики услуг в сфере информационных технологий), с учетом установленных главами 7 и 8 Положения Банка России N 716-П требований к управлению риском информационной безопасности и риском информационных систем при передаче поставщикам услуг в сфере информационных технологий выполнения отдельных функций кредитной организации и (или) использовании внешних информационных систем, а также требований к аутсорсингу обслуживания и функционирования информационных систем;
- требования к тестированию операционной надежности технологических процессов;
- требования к нейтрализации информационных угроз со стороны несанкционированного доступа работников кредитной организации или работников поставщиков услуг в сфере информационных технологий, обладающих полномочиями доступа к объектам информационной инфраструктуры (далее - внутренний нарушитель), к объектам информационной инфраструктуры;
- требования к обеспечению осведомленности кредитной организации об актуальных информационных угрозах, которые могут привести к инцидентам операционной надежности.
Приказ ФСТЭК России № 21 от 18.02.2013 "Состав и содержание мер по обеспечению безопасности персональных данных, необходимых для обеспечения каждого из уровней защищенности персональных данных":
УКФ.3
УКФ.3 Анализ потенциального воздействия планируемых изменений в конфигурации информационной системы и системы защиты персональных данных на обеспечение защиты персональных данных и согласование изменений в конфигурации информационной системы с должностным лицом (работником), ответственным за обеспечение безопасности персональных данных
Framework № PCI DSS 4.0 от 01.03.2022 "Payment Card Industry Data Security Standard":
Requirement 6.5.4
6.5.4
Defined Approach Requirements:
Roles and functions are separated between production and pre-production environments to provide accountability such that only reviewed and approved changes are deployed.
Customized Approach Objective:
Job roles and accountability that differentiate between pre-production and production activities are defined and managed to minimize the risk of unauthorized, unintentional, or inappropriate actions.
Applicability Notes:
In environments with limited personnel where individuals perform multiple roles or functions, this same goal can be achieved with additional procedural controls that provide accountability. For example, a developer may also be an administrator that uses an administrator-level account with elevated privileges in the development environment and, for their developer role, they use a separate account with user-level access to the production environment.
Defined Approach Testing Procedures:
Defined Approach Requirements:
Roles and functions are separated between production and pre-production environments to provide accountability such that only reviewed and approved changes are deployed.
Customized Approach Objective:
Job roles and accountability that differentiate between pre-production and production activities are defined and managed to minimize the risk of unauthorized, unintentional, or inappropriate actions.
Applicability Notes:
In environments with limited personnel where individuals perform multiple roles or functions, this same goal can be achieved with additional procedural controls that provide accountability. For example, a developer may also be an administrator that uses an administrator-level account with elevated privileges in the development environment and, for their developer role, they use a separate account with user-level access to the production environment.
Defined Approach Testing Procedures:
- 6.5.4.a Examine policies and procedures to verify that processes are defined for separating roles and functions to provide accountability such that only reviewed and approved changes are deployed.
- 6.5.4.b Observe processes and interview personnel to verify implemented controls separate roles and functions and provide accountability such that only reviewed and approved changes are deployed.
Purpose:
The goal of separating roles and functions between production and pre-production environments is to reduce the number of personnel with access to the production environment and account data and thereby minimize risk of unauthorized, unintentional, or inappropriate access to data and system components and help ensure that access is limited to those individuals with a business need for such access.
The intent of this control is to separate critical activities to provide oversight and review to catch errors and minimize the chances of fraud or theft (since two people would need to collude in order to hide an activity).
Separating roles and functions, also referred to as separation or segregation of duties, is a key internal control concept to protect an entity’s assets.
The goal of separating roles and functions between production and pre-production environments is to reduce the number of personnel with access to the production environment and account data and thereby minimize risk of unauthorized, unintentional, or inappropriate access to data and system components and help ensure that access is limited to those individuals with a business need for such access.
The intent of this control is to separate critical activities to provide oversight and review to catch errors and minimize the chances of fraud or theft (since two people would need to collude in order to hide an activity).
Separating roles and functions, also referred to as separation or segregation of duties, is a key internal control concept to protect an entity’s assets.
Requirement 6.5.2
6.5.2
Defined Approach Requirements:
Upon completion of a significant change, all applicable PCI DSS requirements are confirmed to be in place on all new or changed systems and networks, and documentation is updated as applicable.
Customized Approach Objective:
All system components are verified after a significant change to be compliant with the applicable PCI DSS requirements.
Applicability Notes:
These significant changes should also be captured and reflected in the entity’s annual PCI DSS scope confirmation activity per Requirement 12.5.2.
Defined Approach Testing Procedures:
Defined Approach Requirements:
Upon completion of a significant change, all applicable PCI DSS requirements are confirmed to be in place on all new or changed systems and networks, and documentation is updated as applicable.
Customized Approach Objective:
All system components are verified after a significant change to be compliant with the applicable PCI DSS requirements.
Applicability Notes:
These significant changes should also be captured and reflected in the entity’s annual PCI DSS scope confirmation activity per Requirement 12.5.2.
Defined Approach Testing Procedures:
- 6.5.2 Examine documentation for significant changes, interview personnel, and observe the affected systems/networks to verify that the entity confirmed applicable PCI DSS requirements were in place on all new or changed systems and networks and that documentation was updated as applicable.
Purpose:
Having processes to analyze significant changes helps ensure that all appropriate PCI DSS controls are applied to any systems or networks added or changed within the in-scope environment, and that PCI DSS requirements continue to be met to secure the environment.
Good Practice:
Building this validation into change management processes helps ensure that device inventories and configuration standards are kept up to date and security controls are applied where needed.
Examples:
Applicable PCI DSS requirements that could be impacted include, but are not limited to:
Having processes to analyze significant changes helps ensure that all appropriate PCI DSS controls are applied to any systems or networks added or changed within the in-scope environment, and that PCI DSS requirements continue to be met to secure the environment.
Good Practice:
Building this validation into change management processes helps ensure that device inventories and configuration standards are kept up to date and security controls are applied where needed.
Examples:
Applicable PCI DSS requirements that could be impacted include, but are not limited to:
- Network and data-flow diagrams are updated to reflect changes.
- Systems are configured per configuration standards, with all default passwords changed and unnecessary services disabled.
- Systems are protected with required controls—for example, file integrity monitoring (FIM), anti-malware, patches, and audit logging.
- Sensitive authentication data is not stored, and all account data storage is documented and incorporated into data retention policy and procedures.
- New systems are included in the quarterly vulnerability scanning process.
- Systems are scanned for internal and external vulnerabilities after significant changes per Requirements 11.3.1.3 and 11.3.2.1.
Framework № PCI DSS 4.0 от 01.03.2022 "Payment Card Industry Data Security Standard (RU)":
Requirement 6.5.4
6.5.4
Определенные Требования к Подходу:
Роли и функции разделены между производственной и предпроизводственной средами для обеспечения подотчетности таким образом, чтобы внедрялись только проверенные и утвержденные изменения.
Цель Индивидуального подхода:
Должностные обязанности и ответственность, которые различают подготовительную и производственную деятельность, определяются и управляются таким образом, чтобы свести к минимуму риск несанкционированных, непреднамеренных или ненадлежащих действий.
Примечания по применению:
В условиях ограниченного персонала, когда отдельные лица выполняют несколько ролей или функций, эта же цель может быть достигнута с помощью дополнительных процедурных средств контроля, обеспечивающих подотчетность. Например, разработчик может также быть администратором, который использует учетную запись уровня администратора с повышенными привилегиями в среде разработки, а для своей роли разработчика он использует отдельную учетную запись с доступом на уровне пользователя к рабочей среде.
Определенные Процедуры Тестирования Подхода:
Определенные Требования к Подходу:
Роли и функции разделены между производственной и предпроизводственной средами для обеспечения подотчетности таким образом, чтобы внедрялись только проверенные и утвержденные изменения.
Цель Индивидуального подхода:
Должностные обязанности и ответственность, которые различают подготовительную и производственную деятельность, определяются и управляются таким образом, чтобы свести к минимуму риск несанкционированных, непреднамеренных или ненадлежащих действий.
Примечания по применению:
В условиях ограниченного персонала, когда отдельные лица выполняют несколько ролей или функций, эта же цель может быть достигнута с помощью дополнительных процедурных средств контроля, обеспечивающих подотчетность. Например, разработчик может также быть администратором, который использует учетную запись уровня администратора с повышенными привилегиями в среде разработки, а для своей роли разработчика он использует отдельную учетную запись с доступом на уровне пользователя к рабочей среде.
Определенные Процедуры Тестирования Подхода:
- 6.5.4.a Изучите политики и процедуры, чтобы убедиться, что процессы определены для разделения ролей и функций для обеспечения подотчетности таким образом, чтобы внедрялись только проверенные и одобренные изменения.
- 6.5.4.b Наблюдать за процессами и проводить собеседования с персоналом для проверки внедренных средств контроля, разделения ролей и функций и обеспечения подотчетности таким образом, чтобы внедрялись только проверенные и одобренные изменения.
Цель:
Целью разделения ролей и функций между производственной и предпроизводственной средами является сокращение числа сотрудников, имеющих доступ к производственной среде и данным учетной записи, и тем самым минимизация риска несанкционированного, непреднамеренного или ненадлежащего доступа к данным и компонентам системы, а также обеспечение того, чтобы доступ был ограничен лицами, имеющими бизнес- необходимость в таком доступе.
Цель этого контроля состоит в том, чтобы разделить критические действия для обеспечения надзора и проверки, чтобы выявить ошибки и свести к минимуму вероятность мошенничества или кражи (поскольку два человека должны были бы вступить в сговор, чтобы скрыть действие).
Разделение ролей и функций, также называемое разделением или разделением обязанностей, является ключевой концепцией внутреннего контроля для защиты активов организации.
Целью разделения ролей и функций между производственной и предпроизводственной средами является сокращение числа сотрудников, имеющих доступ к производственной среде и данным учетной записи, и тем самым минимизация риска несанкционированного, непреднамеренного или ненадлежащего доступа к данным и компонентам системы, а также обеспечение того, чтобы доступ был ограничен лицами, имеющими бизнес- необходимость в таком доступе.
Цель этого контроля состоит в том, чтобы разделить критические действия для обеспечения надзора и проверки, чтобы выявить ошибки и свести к минимуму вероятность мошенничества или кражи (поскольку два человека должны были бы вступить в сговор, чтобы скрыть действие).
Разделение ролей и функций, также называемое разделением или разделением обязанностей, является ключевой концепцией внутреннего контроля для защиты активов организации.
Requirement 6.5.2
6.5.2
Определенные Требования к Подходу:
После завершения существенных изменений подтверждается, что все применимые требования PCI DSS применяются ко всем новым или измененным системам и сетям, а документация обновляется по мере необходимости.
Цель Индивидуального подхода:
Все компоненты системы проверяются после внесения существенных изменений на соответствие применимым требованиям PCI DSS.
Примечания по применению:
Эти существенные изменения также должны быть зафиксированы и отражены в ежегодной деятельности организации по подтверждению охвата PCI DSS в соответствии с требованием 12.5.2.
Определенные Процедуры Тестирования Подхода:
Определенные Требования к Подходу:
После завершения существенных изменений подтверждается, что все применимые требования PCI DSS применяются ко всем новым или измененным системам и сетям, а документация обновляется по мере необходимости.
Цель Индивидуального подхода:
Все компоненты системы проверяются после внесения существенных изменений на соответствие применимым требованиям PCI DSS.
Примечания по применению:
Эти существенные изменения также должны быть зафиксированы и отражены в ежегодной деятельности организации по подтверждению охвата PCI DSS в соответствии с требованием 12.5.2.
Определенные Процедуры Тестирования Подхода:
- 6.5.2 Изучите документацию на предмет существенных изменений, опросите персонал и понаблюдайте за затронутыми системами/сетями, чтобы убедиться, что организация подтвердила, что применимые требования PCI DSS применяются ко всем новым или измененным системам и сетям, и что документация была обновлена по мере необходимости.
Цель:
Наличие процессов для анализа существенных изменений помогает гарантировать, что все соответствующие элементы управления PCI DSS применяются к любым системам или сетям, добавленным или измененным в рамках среды in-scope, и что требования PCI DSS продолжают выполняться для обеспечения безопасности среды.
Надлежащая практика:
Включение этой проверки в процессы управления изменениями помогает гарантировать, что инвентаризация устройств и стандарты конфигурации поддерживаются в актуальном состоянии, а средства контроля безопасности применяются там, где это необходимо.
Примеры:
Применимые требования PCI DSS, которые могут быть затронуты, включают, но не ограничиваются ими::
Наличие процессов для анализа существенных изменений помогает гарантировать, что все соответствующие элементы управления PCI DSS применяются к любым системам или сетям, добавленным или измененным в рамках среды in-scope, и что требования PCI DSS продолжают выполняться для обеспечения безопасности среды.
Надлежащая практика:
Включение этой проверки в процессы управления изменениями помогает гарантировать, что инвентаризация устройств и стандарты конфигурации поддерживаются в актуальном состоянии, а средства контроля безопасности применяются там, где это необходимо.
Примеры:
Применимые требования PCI DSS, которые могут быть затронуты, включают, но не ограничиваются ими::
- Схемы сети и потоков данных обновляются с учетом изменений.
- Системы настроены в соответствии со стандартами конфигурации, при этом все пароли по умолчанию изменены, а ненужные службы отключены.
- Системы защищены необходимыми элементами управления — например, мониторинг целостности файлов (FIM), защита от вредоносных программ, исправления и ведение журнала аудита.
- Конфиденциальные данные аутентификации не сохраняются, и все хранение данных учетной записи документируется и включается в политику и процедуры хранения данных.
- Новые системы включаются в ежеквартальный процесс сканирования уязвимостей.
- Системы проверяются на наличие внутренних и внешних уязвимостей после значительных изменений в соответствии с требованиями 11.3.1.3 и 11.3.2.1.
Связанные защитные меры
Ничего не найдено
Мы используем cookie-файлы, чтобы получить статистику, которая помогает нам улучшить сервис для вас с целью персонализации сервисов и предложений. Вы может прочитать подробнее о cookie-файлах или изменить настройки браузера. Продолжая пользоваться сайтом, вы даёте согласие на использование ваших cookie-файлов и соглашаетесь с Политикой обработки персональных данных.