Куда я попал?
Framework № PCI DSS 4.0 от 01.03.2022
Payment Card Industry Data Security Standard (RU)
Requirement 3.7.6
Для проведения оценки соответствия по документу войдите в систему.
Список требований
Похожие требования
ГОСТ Р № 57580.1-2017 от 01.01.2018 "Безопасность финансовых (банковских) операций. Защита информации финансовых организаций. Базовый состав организационных и технических мер. Раздел 7. Требования к системе защиты информации":
УЗП.20
УЗП.20 Реализация правил управления правами логического доступа, обеспечивающих запрет совмещения одним субъектом логического доступа ролей, предусмотренных мерой УЗП.19 настоящей таблицы
3-О 2-Т 1-Т
3-О 2-Т 1-Т
УЗП.19
УЗП.19 Определение состава ролей, связанных с выполнением операции (транзакции) в АС, имеющих финансовые последствия для финансовой организации, клиентов и контрагентов, и ролей, связанных с контролем выполнения указанных операций (транзакций), запрет выполнения указанных ролей одним субъектом логического доступа
3-О 2-Т 1-Т
3-О 2-Т 1-Т
Framework № PCI DSS 4.0 от 01.03.2022 "Payment Card Industry Data Security Standard":
Requirement 3.7.6
3.7.6
Defined Approach Requirements:
Where manual cleartext cryptographic keymanagement operations are performed by personnel, key-management policies and procedures are implemented include managing these operations using split knowledge and dual control.
Customized Approach Objective:
Cleartext secret or private keys cannot be known by anyone. Operations involving cleartext keys cannot be carried out by a single person.
Applicability Notes:
This control is applicable for manual keymanagement operations or where key management is not controlled by the encryption product. A cryptographic key that is simply split into two parts does not meet this requirement. Secret or private keys stored as key components or key shares must be generated via one of the following:
Defined Approach Requirements:
Where manual cleartext cryptographic keymanagement operations are performed by personnel, key-management policies and procedures are implemented include managing these operations using split knowledge and dual control.
Customized Approach Objective:
Cleartext secret or private keys cannot be known by anyone. Operations involving cleartext keys cannot be carried out by a single person.
Applicability Notes:
This control is applicable for manual keymanagement operations or where key management is not controlled by the encryption product. A cryptographic key that is simply split into two parts does not meet this requirement. Secret or private keys stored as key components or key shares must be generated via one of the following:
- Using an approved random number generator and within a secure cryptographic device (SCD), such as a hardware security module (HSM) or PTS-approved point-of-interaction device, OR
- According to ISO 19592 or equivalent industry standard for generation of secret key shares.
Defined Approach Testing Procedures:
- 3.7.6.a Examine the documented key-management policies and procedures for keys used for protection of stored account data and verify that they define using split knowledge and dual control.
- 3.7.6.b Interview personnel and/or observe processes to verify that manual cleartext keys are managed with split knowledge and dual control.
Purpose:
Split knowledge and dual control of keys are used to eliminate the possibility of a single person having access to the whole key and therefore being able to gain unauthorized access to the data.
Definitions:
Split knowledge is a method in which two or more people separately have key components, where each person knows only their own key component, and the individual key components convey no knowledge of other components or of the original cryptographic key.
Dual control requires two or more people to authenticate the use of a cryptographic key or perform a key-management function. No single person can access or use the authentication factor (for example, the password, PIN, or key) of another.
Good Practice:
Where key components or key shares are used, procedures should ensure that no single custodian ever has access to sufficient key components or shares to reconstruct the cryptographic key. For example, in an m-of-n scheme (for example, Shamir), where only two of any three components are required to reconstruct the cryptographic key, a custodian must not have current or prior knowledge of more than one component. If a custodian was previously assigned component A, which was then reassigned, the custodian should not then be assigned component B or C, as this would give the custodian knowledge of two components and the ability to recreate the key.
Examples:
Key-management operations that might be performed manually include, but are not limited to, key generation, transmission, loading, storage, and destruction.
Further Information:
Industry standards for managing key components include:
Split knowledge and dual control of keys are used to eliminate the possibility of a single person having access to the whole key and therefore being able to gain unauthorized access to the data.
Definitions:
Split knowledge is a method in which two or more people separately have key components, where each person knows only their own key component, and the individual key components convey no knowledge of other components or of the original cryptographic key.
Dual control requires two or more people to authenticate the use of a cryptographic key or perform a key-management function. No single person can access or use the authentication factor (for example, the password, PIN, or key) of another.
Good Practice:
Where key components or key shares are used, procedures should ensure that no single custodian ever has access to sufficient key components or shares to reconstruct the cryptographic key. For example, in an m-of-n scheme (for example, Shamir), where only two of any three components are required to reconstruct the cryptographic key, a custodian must not have current or prior knowledge of more than one component. If a custodian was previously assigned component A, which was then reassigned, the custodian should not then be assigned component B or C, as this would give the custodian knowledge of two components and the ability to recreate the key.
Examples:
Key-management operations that might be performed manually include, but are not limited to, key generation, transmission, loading, storage, and destruction.
Further Information:
Industry standards for managing key components include:
- NIST SP 800-57 Part 2, Revision 1 -- Recommendation for Key Management: Part 2 – Best Practices for Key Management Organizations [4.6 Keying Material Distribution]
- ISO 11568-2 Banking — Key management (retail) — Part 2: Symmetric ciphers, their key management and life cycle [4.7.2.3 Key components and 4.9.3 Key components]
- European Payments Council EPC342-08 Guidelines on Cryptographic Algorithms Usage and Key Management [especially 4.1.4 Key installation].
ГОСТ Р № ИСО/МЭК 27001-2021 от 01.01.2022 "Информационная технология. Методы и средства обеспечения безопасности. Системы менеджмента информационной безопасности. Требования - Приложение А":
A.9.4.1
A.9.4.1 Ограничение доступа к информации
Мера обеспечения информационной безопасности: Доступ к информации и функциям прикладных систем должен быть ограничен в соответствии с политикой управления доступом
Мера обеспечения информационной безопасности: Доступ к информации и функциям прикладных систем должен быть ограничен в соответствии с политикой управления доступом
A.9.2.3
A.9.2.3 Управление привилегированными правами доступа
Мера обеспечения информационной безопасности: Распределение и использование привилегированных прав доступа следует ограничивать и контролировать
Мера обеспечения информационной безопасности: Распределение и использование привилегированных прав доступа следует ограничивать и контролировать
A.11.1.2
A.11.1.2 Меры и средства контроля и управления физическим доступом
Мера обеспечения информационной безопасности: Зоны безопасности должны быть защищены соответствующими мерами и средствами контроля доступа, чтобы обеспечить уверенность в том, что доступ разрешен только уполномоченному персоналу
Мера обеспечения информационной безопасности: Зоны безопасности должны быть защищены соответствующими мерами и средствами контроля доступа, чтобы обеспечить уверенность в том, что доступ разрешен только уполномоченному персоналу
Стандарт № ИСО/МЭК 27001:2022(E) от 25.10.2022 "Информационная безопасность, кибербезопасность и защита частной жизни — Системы управления информационной безопасностью — Требования. Приложение А":
А.5.18
А.5.18 Права доступа
Права доступа к информационным и иным связанным с ней активам должны предоставляться, пересматриваться, изменяться и удаляться в соответствии с специфической тематической политикой и правилами управления доступом организации.
Права доступа к информационным и иным связанным с ней активам должны предоставляться, пересматриваться, изменяться и удаляться в соответствии с специфической тематической политикой и правилами управления доступом организации.
А.8.2
А.8.2 Привилегированные права доступа
Должны ограничиваться и управляться назначение и использование привилегированных прав доступа.
Должны ограничиваться и управляться назначение и использование привилегированных прав доступа.
А.8.3
А.8.3 Ограничение доступа к информации
Доступ к информационным и иным связанным с ними активам должен быть ограничен в соответствии с установленной специфической тематической политикой управления доступом.
Доступ к информационным и иным связанным с ними активам должен быть ограничен в соответствии с установленной специфической тематической политикой управления доступом.
ГОСТ Р № ИСО/МЭК 27002-2021 от 30.11.2021 "Информационные технологии. Методы и средства обеспечения безопасности. Свод норм и правил применения мер обеспечения информационной безопасности":
9.4.1
9.4.1 Ограничение доступа к информации
Мера обеспечения ИБ
Доступ к информации и функциям прикладных систем должен быть ограничен в соответствии с политикой управления доступом.
Руководство по применению
Ограничения доступа должны основываться на требованиях конкретных бизнес-приложений и соответствовать установленной политике управления доступом.
Для обеспечения выполнения требований по ограничению доступа следует учитывать следующее:
- a) предоставление меню для управления доступом к функциям прикладных систем;
- b) управление тем, какие данные могут быть доступны конкретному пользователю;
- c) управление правами доступа пользователей, например чтение, запись, удаление и выполнение;
- d) управление правами доступа других приложений;
- e) ограничение информации, содержащейся в выходных данных;
- f) обеспечение физических или логических мер управления доступом для изоляции чувствительных приложений, данных или систем.
9.2.3
9.2.3 Управление привилегированными правами доступа
Мера обеспечения ИБ
Распределение и использование привилегированных прав доступа следует ограничивать и контролировать.
Руководство по применению
Назначение привилегированных прав доступа должно контролироваться посредством формализованного процесса аутентификации в соответствии с действующей политикой управления доступом (см. 9.1.1). При этом должны быть предусмотрены следующие шаги:
- a) идентификация привилегированных прав доступа, связанных с каждой системой или процессом, например операционной системой, системой управления базами данных, каждым приложением и пользователями, которым требуется назначение таких прав;
- b) привилегированные права доступа должны назначаться пользователям исходя из принципов "необходимого использования" и "предоставления доступа по событию" в соответствии с политикой управления доступом (см. 9.1.1), то есть по минимуму для их функциональных ролей;
- c) все процессы аутентификации и назначения привилегий должны регистрироваться. Привилегированные права доступа не должны предоставляться до завершения процесса аутентификации;
- d) должны быть определены требования для установления срока действия привилегированных прав доступа;
- e) привилегированные права доступа должны быть связаны с идентификатором пользователя, отличным от того, что используется для исполнения повседневных должностных обязанностей. Эти обязанности не должны выполняться под привилегированным идентификатором;
- f) полномочия пользователей с привилегированными правами доступа должны регулярно пересматриваться с целью убедиться, что они соответствуют их обязанностям;
- g) должны быть разработаны и поддерживаться специальные процедуры, во избежание несанкционированного использования общих административных идентификаторов в соответствии с возможностями конфигурации системы;
- h) при совместном использовании общих административных идентификаторов должна обеспечиваться конфиденциальность секретной аутентификационной информации (например, частая смена паролей, а также максимально быстрая их смена при увольнении пользователя с привилегированными правами или изменении его обязанностей, передача паролей всем пользователям с привилегированными правами посредством соответствующих механизмов).
Дополнительная информация
Несоответствующее использование привилегий, связанных с администрированием системы (любой функции или сервиса информационной системы, которая позволяет пользователю изменить средства управления системой или приложением) является основным фактором сбоев и нарушения функционирования системы.
11.1.2
11.1.2 Меры и средства контроля и управления физическим доступом
Мера обеспечения ИБ
Зоны безопасности должны быть защищены соответствующими мерами и средствами контроля доступа, чтобы обеспечить уверенность в том, что доступ разрешен только уполномоченному персоналу.
Руководство по применению
Следует принять во внимание следующие рекомендации:
- a) регистрировать дату и время въезда и выезда посетителей, а также брать под сопровождение всех, чье право доступа не было предварительно согласовано; доступ посетителям следует предоставлять только для выполнения определенных, авторизованных целей и следует начинать с проведения инструктажа по требованиям безопасности и действий в аварийных ситуациях. Личность посетителей должна подтверждаться соответствующими средствами;
- b) доступ в зоны обработки или хранения конфиденциальной информации следует контролировать и предоставлять только авторизованным лицам путем применения соответствующих мер, например реализацией механизма двухфакторной аутентификации, такой, как карты доступа или секретным ПИН-кодом;
- c) рукописный или электронный журнал регистрации посещений нужно надежным образом вести и проверять;
- d) все работники, подрядчики и представители внешней стороны должны носить ту или иную форму визуального идентификатора и должны немедленно уведомлять персонал службы безопасности, если они встречают посетителей без сопровождения или без визуальных идентификаторов;
- e) персоналу службы поддержки сторонних организаций следует выдавать ограниченный доступ к зонам и средствам обработки конфиденциальной информации только при необходимости; такой доступ должен быть санкционирован и сопровождаться соответствующим контролем;
- f) права доступа к зонам безопасности следует регулярно пересматривать и обновлять, а при необходимости отменять (см. 9.25, 9.2.6).
Стандарт № ISO/IEC 27001:2022(E) от 25.10.2022 "Information security, cybersecurity and privacy protection — Information security management systems — Requirements. Annex A":
А.8.2
А.8.2 Privileged access rights
The allocation and use of privileged access rights shall be restricted and managed.
The allocation and use of privileged access rights shall be restricted and managed.
А.8.3
А.8.3 Information access restriction
Access to information and other associated assets shall be restricted in accordance with the established topic-specific policy on access control.
Access to information and other associated assets shall be restricted in accordance with the established topic-specific policy on access control.
А.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.
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.
Связанные защитные меры
Ничего не найдено
Мы используем cookie-файлы, чтобы получить статистику, которая помогает нам улучшить сервис для вас с целью персонализации сервисов и предложений. Вы может прочитать подробнее о cookie-файлах или изменить настройки браузера. Продолжая пользоваться сайтом, вы даёте согласие на использование ваших cookie-файлов и соглашаетесь с Политикой обработки персональных данных.