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

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

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

УЗП.20

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

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

Приказ ФСТЭК России № 21 от 18.02.2013 "Состав и содержание мер по обеспечению безопасности персональных данных, необходимых для обеспечения каждого из уровней защищенности персональных данных":
УПД.4 УПД.4 Разделение полномочий (ролей) пользователей, администраторов и лиц, обеспечивающих функционирование информационной системы
Framework № PCI DSS 4.0 от 01.03.2022 "Payment Card Industry Data Security Standard":
Requirement 7.2.1
7.2.1
Defined Approach Requirements: 
An access control model is defined and includes granting access as follows: 
  • Appropriate access depending on the entity’s business and access needs.
  • Access to system components and data resources that is based on users’ job classification and functions.
  • The least privileges required (for example, user, administrator) to perform a job function. 
Customized Approach Objective:
Access requirements are established according to job functions following least-privilege and need-toknow principles 

Defined Approach Testing Procedures:
  • 7.2.1.a Examine documented policies and procedures and interview personnel to verify the access control model is defined in accordance with all elements specified in this requirement. 
  • 7.2.1.b Examine access control model settings and verify that access needs are appropriately defined in accordance with all elements specified in this requirement. 
Purpose:
Defining an access control model that is appropriate for the entity’s technology and access control philosophy supports a consistent and uniform way of allocating access and reduces the possibility of errors such as the granting of excessive rights. 

Good Practice:
A factor to consider when defining access needs is the separation of duties principle. This principle is intended to prevent fraud and misuse or theft of resources. For example, 1) dividing missioncritical functions and information system support functions among different individuals and/or functions, 2) establishing roles such that information system support activities are performed by different functions/individuals (for example, system management, programming, configuration management, quality assurance and testing, and network security), and 3) ensuring security personnel administering access control functions do not also administer audit functions. 
In environments where one individual performs multiple functions, such as administration and security operations, duties may be assigned so that no single individual has end-to-end control of a process without an independent checkpoint. For example, responsibility for configuration and responsibility for approving changes could be assigned to separate individuals. 

Definitions:
Key elements of an access control model include:
  • Resources to be protected (the systems/devices/data to which access is needed), 
  • Job functions that need access to the resource (for example, system administrator, call-center personnel, store clerk), and 
  • Which activities each job function needs to perform (for example, read/write or query). 
Once job functions, resources, and activities per job functions are defined, individuals can be granted access accordingly. 

Examples:
Access control models that entities can consider include role-based access control (RBAC) and attribute-based access control (ABAC). The access control model used by a given entity depends on their business and access needs. 
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:
  • 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: 
  • 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.2
A.9.4.2 Безопасные процедуры входа в систему 
Мера обеспечения информационной безопасности: Когда этого требует политика управления доступом, доступ к системам и приложениям должен управляться посредством безопасной процедуры входа в систему 
Framework № PCI DSS 4.0 от 01.03.2022 "Payment Card Industry Data Security Standard (RU)":
Requirement 7.2.1
7.2.1
Определенные Требования к Подходу:
Определена модель управления доступом, которая включает в себя предоставление доступа следующим образом:
  • Соответствующий доступ в зависимости от бизнеса организации и потребностей в доступе.
  • Доступ к системным компонентам и ресурсам данных, основанный на классификации и функциях пользователей.
  • Наименьшие привилегии, необходимые (например, пользователь, администратор) для выполнения рабочей функции.
Цель Индивидуального подхода:
Требования к доступу устанавливаются в соответствии с должностными функциями в соответствии с принципами наименьших привилегий и необходимости знать

Определенные Процедуры Тестирования Подхода:
  • 7.2.1.a Изучите документированные политики и процедуры и опросите персонал, чтобы убедиться, что модель контроля доступа определена в соответствии со всеми элементами, указанными в этом требовании.
  • 7.2.1.b Изучите настройки модели управления доступом и убедитесь, что потребности в доступе определены надлежащим образом в соответствии со всеми элементами, указанными в этом требовании.
Цель:
Определение модели управления доступом, соответствующей технологии организации и философии управления доступом, поддерживает последовательный и единообразный способ распределения доступа и снижает вероятность ошибок, таких как предоставление чрезмерных прав.

Надлежащая практика:
Фактором, который следует учитывать при определении потребностей в доступе, является принцип разделения обязанностей. Этот принцип предназначен для предотвращения мошенничества и неправильного использования или кражи ресурсов. Например, 1) разделение критически важных функций и функций поддержки информационной системы между различными лицами и/или функциями, 2) установление ролей таким образом, чтобы деятельность по поддержке информационной системы выполнялась различными функциями/лицами (например, управление системой, программирование, управление конфигурацией, обеспечение качества и тестирование, а также сетевая безопасность), и 3) обеспечение того, чтобы сотрудники службы безопасности, выполняющие функции контроля доступа, не выполняли также функции аудита.
В средах, где один человек выполняет несколько функций, таких как администрирование и операции безопасности, обязанности могут быть распределены таким образом, чтобы ни один отдельный человек не имел сквозного контроля над процессом без независимой контрольной точки. Например, ответственность за настройку и ответственность за утверждение изменений могут быть возложены на отдельных лиц.

Определения:
Ключевые элементы модели контроля доступа включают в себя:
  • Ресурсы, подлежащие защите (системы/устройства/данные, к которым необходим доступ),
  • Рабочие функции, которым требуется доступ к ресурсу (например, системный администратор, персонал колл-центра, продавец в магазине), и
  • Какие действия должна выполнять каждая функция задания (например, чтение /запись или запрос).
Как только рабочие функции, ресурсы и действия для каждой рабочей функции определены, отдельным лицам может быть предоставлен соответствующий доступ.

Примеры:
Модели управления доступом, которые могут учитывать организации, включают управление доступом на основе ролей (RBAC) и управление доступом на основе атрибутов (ABAC). Модель управления доступом, используемая данной организацией, зависит от их бизнеса и потребностей в доступе.
Requirement 3.7.6
3.7.6
Определенные Требования к Подходу:
Там, где персонал выполняет операции по управлению ключами с открытым текстом вручную, политики и процедуры управления ключами включают управление этими операциями с использованием разделенных знаний и двойного контроля.

Цель Индивидуального подхода:
Секретные или закрытые ключи открытого текста не могут быть известны никому. Операции, связанные с ключами открытого текста, не могут выполняться одним человеком.

Примечания по применению:
Этот элемент управления применим для операций ручного управления ключами или там, где управление ключами не контролируется продуктом шифрования. Криптографический ключ, который просто разделяется на две части, не соответствует этому требованию. Секретные или закрытые ключи, хранящиеся в качестве ключевых компонентов или общих ключей, должны быть сгенерированы одним из следующих способов:
  • С использованием одобренного генератора случайных чисел и в защищенном криптографическом устройстве (SCD), таком как аппаратный модуль безопасности (HSM) или устройство точки взаимодействия, одобренное PTS, 
ИЛИ
  • В соответствии с в соответствии с ISO 19592 или эквивалентным отраслевым стандартом для генерации общих секретных ключей.

Определенные Процедуры Тестирования Подхода:
  • 3.7.6.a Изучите документированные политики и процедуры управления ключами для ключей, используемых для защиты хранимых данных учетной записи, и убедитесь, что они определены с использованием разделенных знаний и двойного контроля.
  • 3.7.6.b Опрашивать персонал и / или наблюдать за процессами, чтобы убедиться, что ручные ключи открытого текста управляются с разделенными знаниями и двойным контролем.
Цель:
Разделение знаний и двойной контроль ключей используются для устранения возможности того, что один человек имеет доступ ко всему ключу и, следовательно, может получить несанкционированный доступ к данным.

Определения:
Разделение знаний - это метод, при котором два или более человека по отдельности владеют ключевыми компонентами, где каждый человек знает только свой собственный ключевой компонент, а отдельные ключевые компоненты не передают никаких знаний о других компонентах или об исходном криптографическом ключе.
Двойной контроль требует, чтобы два или более человека проверяли подлинность использования криптографического ключа или выполняли функцию управления ключами. Ни один человек не может получить доступ или использовать фактор аутентификации (например, пароль, PIN-код или ключ) другого человека.

Надлежащая практика:
Там, где используются ключевые компоненты или общие ресурсы ключей, процедуры должны гарантировать, что ни один хранитель никогда не будет иметь доступа к достаточному количеству ключевых компонентов или общих ресурсов для восстановления криптографического ключа. Например, в схеме m-of-n (например, Shamir), где для восстановления криптографического ключа требуются только два из любых трех компонентов, хранитель не должен иметь текущих или предварительных знаний более чем об одном компоненте. Если хранителю ранее был назначен компонент A, который затем был переназначен, хранителю не следует назначать компонент B или C, поскольку это дало бы хранителю знания о двух компонентах и возможность воссоздать ключ.

Примеры:
Операции управления ключами, которые могут выполняться вручную, включают, но не ограничиваются ими, генерацию, передачу, загрузку, хранение и уничтожение ключей.

Дополнительная информация:
Отраслевые стандарты для управления ключевыми компонентами включают:
  • NIST SP 800-57 Часть 2, Редакция 1 – Рекомендация для управления ключами: Часть 2 - Лучшие практики для организаций по управлению ключами [4.6 Распределение материалов по ключам]
  • ISO 11568-2 Банковское дело — Управление ключами (розничная торговля) — Часть 2: Симметричные шифры, их управление ключами и жизненный цикл [4.7.2.3 Ключевые компоненты и 4.9.3 Ключевые компоненты]
  • Руководство Европейского Платежного совета EPC342-08 по использованию криптографических алгоритмов и управлению ключами [особенно установка ключа 4.1.4].
Приказ ФСТЭК России № 17 от 11.02.2013 "Требования о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах":
УПД.4 УПД.4 Разделение полномочий (ролей) пользователей, администраторов и лиц, обеспечивающих функционирование информационной системы
Приказ ФСТЭК России № 31 от 14.03.2014 "Состав мер защиты информации и их базовые наборы для соответствующего класса защищенности автоматизированной системы управления":
УПД.4 УПД.4 Разделение полномочий (ролей) пользователей
Приказ ФСТЭК России № 239 от 25.12.2017 "Состав мер по обеспечению безопасности для значимого объекта соответствующей категории значимости":
УПД.4 УПД.4 Разделение полномочий (ролей) пользователей

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

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

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