SWIFT Customer Security Controls Framework v2022

7.4.3. В организации БС РФ должны быть определены, выполняться, регистрироваться и контролироваться правила и процедуры:

3.3 Configure Data Access Control Lists 
Configure data access control lists based on a user’s need to know. Apply data access control lists, also known as access permissions, to local and remote file systems, databases, and applications. 

6.6. Кредитные организации в части нейтрализации информационных угроз со стороны внутреннего нарушителя разрабатывают и принимают организационные и технические меры в отношении субъектов доступа, привлекаемых в рамках выполнения технологических процессов, направленные на исключение возможности несанкционированного использования предоставленных указанным субъектам доступа полномочий.

PR.AC-4: При предоставлении разрешения на доступ и авторизации используется принцип наименьших привилегий и разделения обязанностей

РВН.4.1 Применение соответствующих мер в рамках процесса управления учетными записями и правами субъектов логического доступа, требования к которому определены в ГОСТ Р 57580.1.

3.3 Созданы списки разрешений для управления доступом к данным
Настроены списки управления доступом к данным в зависимости от потребностей. Применяйте списки управления доступом к данным, также известные как разрешения доступа, к локальным и удаленным файловым системам, базам данных и приложениям.

10.6.3
Defined Approach Requirements: 
Time synchronization settings and data are protected as follows:

Customized Approach Objective:
System time settings cannot be modified by unauthorized personnel. 

Defined Approach Testing Procedures:

Purpose:
Attackers will try to change time configurations to hide their activity. Therefore, restricting the ability to change or modify time synchronization configurations or the system time to administrators will lessen the probability of an attacker successfully changing time configurations. 

7.2.2
Defined Approach Requirements: 
Access is assigned to users, including privileged users, based on: 

Customized Approach Objective:
Access to systems and data is limited to only the access needed to perform job functions, as defined in the related access roles. 

Defined Approach Testing Procedures:

Purpose:
Assigning least privileges helps prevent users without sufficient knowledge about the application from incorrectly or accidentally changing application configuration or altering its security settings. Enforcing least privilege also helps to minimize the scope of damage if an unauthorized person gains access to a user ID. 

Good Practice:
Access rights are granted to a user by assignment to one or several functions. Assess is assigned depending on the specific user functions and with the minimum scope required for the job. 
When assigning privileged access, it is important to assign individuals only the privileges they need to perform their job (the “least privileges”). For example, the database administrator or backup administrator should not be assigned the same privileges as the overall systems administrator. 
Once needs are defined for user functions (per PCI DSS requirement 7.2.1), it is easy to grant individuals access according to their job classification and function by using the alreadycreated roles. 
Entities may wish to consider use of Privileged Access Management (PAM), which is a method to grant access to privileged accounts only when those privileges are required, immediately revoking that access once they are no longer needed. 

3.5.1.3
Defined Approach Requirements: 
If disk-level or partition-level encryption is used (rather than file-, column-, or field--level database encryption) to render PAN unreadable, it is managed as follows:

Customized Approach Objective:
Disk encryption implementations are configured to require independent authentication and logical access controls for decryption. 

Applicability Notes:
Disk or partition encryption implementations must also meet all other PCI DSS encryption and keymanagement requirements. 

Defined Approach Testing Procedures:

Purpose:
Disk-level encryption typically encrypts the entire disk or partition using the same key, with all data automatically decrypted when the system runs or when an authorized user requests it. Many diskencryption solutions intercept operating system read/write operations and perform the appropriate cryptographic transformations without any special action by the user other than supplying a password or passphrase at system start-up or at the beginning of a session. This provides no protection from a malicious individual that has already managed to gain access to a valid user account. 

Good Practice:
Full disk encryption helps to protect data in the event of physical loss of a disk and therefore its use is best limited only to removable electronic media storage devices. 

8.2.2
Defined Approach Requirements: 
Group, shared, or generic accounts, or other shared authentication credentials are only used when necessary on an exception basis, and are managed as follows:

Customized Approach Objective:
All actions performed by users with generic, system, or shared IDs are attributable to an individual person. 

Applicability Notes:
This requirement is not intended to apply to user accounts within point-of-sale terminals that have access to only one card number at a time to facilitate a single transaction (such as IDs used by cashiers on point-of-sale terminals). 

Defined Approach Testing Procedures:

Purpose:
Group, shared, or generic (or default) accounts are typically delivered with software or operating systems—for example, root or with privileges associated with a specific function, such as an administrator. 
If multiple users share the same authentication credentials (for example, user account and password), it becomes impossible to trace system access and activities to an individual. In turn, this prevents an entity from assigning accountability for, or having effective logging of, an individual’s actions since a given action could have been performed by anyone in the group with knowledge of the user ID and associated authentication factors. 
The ability to associate individuals to the actions performed with an account is essential to provide individual accountability and traceability regarding who performed an action, what action was performed, and when that action occurred. 

Good Practice:
If shared accounts are used for any reason, strong management controls need to be established to maintain individual accountability and traceability.

Examples:
Tools and techniques can facilitate both management and security of these types of accounts and confirm individual user identity before access to an account is granted. Entities can consider password vaults or other systemmanaged controls such as the sudo command. An example of an exceptional circumstance is where all other authentication methods have failed, and a shared account is needed for emergency use or “break the glass” administrator access. 

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

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

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

Определенные Процедуры Тестирования Подхода:

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

Надлежащая практика:
Права доступа предоставляются пользователю путем назначения одной или нескольким функциям. Оценка назначается в зависимости от конкретных функций пользователя и с минимальным объемом, необходимым для выполнения задания.
При назначении привилегированного доступа важно назначать отдельным лицам только те привилегии, которые им необходимы для выполнения их работы (“наименьшие привилегии”). Например, администратору базы данных или администратору резервного копирования не следует назначать те же привилегии, что и общему системному администратору.
Как только потребности определены для пользовательских функций (в соответствии с требованием PCI DSS 7.2.1), легко предоставить отдельным лицам доступ в соответствии с их классификацией должностей и функциями, используя уже созданные роли.
Организации могут пожелать рассмотреть возможность использования Управления привилегированным доступом (PAM), которое представляет собой метод предоставления доступа к привилегированным учетным записям только тогда, когда эти привилегии требуются, и немедленного отзыва этого доступа, как только они больше не нужны.

8.2.2
Определенные Требования к Подходу:
Групповые, общие или общие учетные записи или другие общие учетные данные для проверки подлинности используются только при необходимости в исключительных случаях и управляются следующим образом:

Цель Индивидуального подхода:
Все действия, выполняемые пользователями с общими, системными или общими идентификаторами, относятся к отдельному лицу.

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

Определенные Процедуры Тестирования Подхода:

Цель:
Групповые, общие или общие учетные записи (или учетные записи по умолчанию) обычно поставляются с программным обеспечением или операционными системами — например, root или с привилегиями, связанными с определенной функцией, например, с правами администратора.
Если несколько пользователей используют одни и те же учетные данные для аутентификации (например, учетную запись пользователя и пароль), становится невозможным отслеживать доступ к системе и действия отдельного пользователя. В свою очередь, это препятствует тому, чтобы организация назначала ответственность за действия отдельного лица или эффективно регистрировала их, поскольку данное действие могло быть выполнено любым членом группы, знающим идентификатор пользователя и связанные с ним факторы аутентификации.
Возможность привязывать отдельных лиц к действиям, выполняемым с помощью учетной записи, имеет важное значение для обеспечения индивидуальной подотчетности и отслеживания того, кто выполнил действие, какое действие было выполнено и когда это действие произошло.

Надлежащая практика:
Если по какой-либо причине используются общие учетные записи, необходимо установить строгий управленческий контроль для поддержания индивидуальной подотчетности и отслеживания.

Примеры:
Инструменты и методы могут облегчить как управление, так и безопасность этих типов учетных записей, а также подтвердить индивидуальную личность пользователя до предоставления доступа к учетной записи. Сущности могут использовать хранилища паролей или другие управляемые системой элементы управления, такие как команда sudo. Примером исключительного обстоятельства является ситуация, когда все другие методы аутентификации завершились неудачей, и общая учетная запись необходима для экстренного использования или доступа администратора “разбить стекло”.

3.5.1.3
Определенные Требования к Подходу:
Если используется шифрование на уровне диска или раздела (а не шифрование базы данных на уровне файлов, столбцов или полей), чтобы сделать PAN нечитаемым, оно управляется следующим образом:

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

Примечания по применению:
Реализации шифрования диска или раздела также должны соответствовать всем другим требованиям к шифрованию PCI DSS и управлению ключами.

Определенные Процедуры Тестирования Подхода:

Цель:
Шифрование на уровне диска обычно шифрует весь диск или раздел с использованием одного и того же ключа, при этом все данные автоматически расшифровываются при запуске системы или по запросу авторизованного пользователя. Многие решения для шифрования дисков перехватывают операции чтения/записи операционной системы и выполняют соответствующие криптографические преобразования без каких-либо специальных действий со стороны пользователя, кроме ввода пароля или ключевой фразы при запуске системы или в начале сеанса. Это не обеспечивает никакой защиты от злоумышленника, которому уже удалось получить доступ к действительной учетной записи пользователя.

Надлежащая практика:
Полное шифрование диска помогает защитить данные в случае физической потери диска, и поэтому его использование лучше всего ограничить только съемными электронными устройствами хранения данных.

10.6.3
Определенные Требования к Подходу:
Настройки и данные синхронизации времени защищены следующим образом:

Цель Индивидуального подхода:
Настройки системного времени не могут быть изменены неавторизованным персоналом.

Определенные Процедуры Тестирования Подхода:

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

7.2.1
Определенные Требования к Подходу:
Определена модель управления доступом, которая включает в себя предоставление доступа следующим образом:

Цель Индивидуального подхода:
Требования к доступу устанавливаются в соответствии с должностными функциями в соответствии с принципами наименьших привилегий и необходимости знать

Определенные Процедуры Тестирования Подхода:

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

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

Определения:
Ключевые элементы модели контроля доступа включают в себя:

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

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

Restrict administrative privileges to operating systems and applications based on user duties. Regularly revalidate the need for privileges. Don’t use privileged accounts for reading email and web browsing.
Relative Security Effectiveness:  Essential | Potential User Resistance:  Medium | Upfront Cost:  High | Ongoing Maintenance Cost:  Medium

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

1.9. Некредитные финансовые организации, обязанные соблюдать усиленный, стандартный или минимальный уровень защиты информации, в рамках обеспечения операционной надежности должны принимать организационные и технические меры в отношении субъектов доступа, являющихся работниками указанных некредитных финансовых организаций и работниками поставщиков услуг, привлекаемых в рамках выполнения технологических процессов, предусмотренных в приложении к настоящему Положению, направленные на управление риском реализации информационных угроз, обусловленным возможностью несанкционированного использования предоставленных указанным субъектам доступа полномочий.

А.5.15 Access control
Rules to control physical and logical access to information and other associated assets shall be established and implemented based on business and information security requirements.