Куда я попал?
Стандарт Банка России № СТО БР ИББС-1.0-2014 от 01.06.2014
Обеспечение информационной безопасности организаций банковской системы Российской Федерации - Общие положения
Р. 7 п. 4 п.п. 16
Для проведения оценки соответствия по документу войдите в систему.
Список требований
Похожие требования
ГОСТ Р № 57580.1-2017 от 01.01.2018 "Безопасность финансовых (банковских) операций. Защита информации финансовых организаций. Базовый состав организационных и технических мер. Раздел 7. Требования к системе защиты информации":
УЗП.1
УЗП.1 Осуществление логического доступа пользователями и эксплуатационным персоналом под уникальными и персонифицированными учетными записями
3-Т 2-Т 1-Т
3-Т 2-Т 1-Т
Framework № PCI DSS 4.0 от 01.03.2022 "Payment Card Industry Data Security Standard":
Requirement 8.2.3
8.2.3
Defined Approach Requirements:
Additional requirement for service providers only: Service providers with remote access to customer premises use unique authentication factors for each customer premises
Customized Approach Objective:
A service provider’s credential used for one customer cannot be used for any other customer.
Applicability Notes:
This requirement applies only when the entity being assessed is a service provider.
This requirement is not intended to apply to service providers accessing their own shared services environments, where multiple customer environments are hosted.
If service provider employees use shared authentication factors to remotely access customer premises, these factors must be unique per customer and managed in accordance with Requirement 8.2.2.
Defined Approach Testing Procedures:
Defined Approach Requirements:
Additional requirement for service providers only: Service providers with remote access to customer premises use unique authentication factors for each customer premises
Customized Approach Objective:
A service provider’s credential used for one customer cannot be used for any other customer.
Applicability Notes:
This requirement applies only when the entity being assessed is a service provider.
This requirement is not intended to apply to service providers accessing their own shared services environments, where multiple customer environments are hosted.
If service provider employees use shared authentication factors to remotely access customer premises, these factors must be unique per customer and managed in accordance with Requirement 8.2.2.
Defined Approach Testing Procedures:
- 8.2.3 Additional testing procedure for service provider assessments only: Examine authentication policies and procedures and interview personnel to verify that service providers with remote access to customer premises use unique authentication factors for remote access to each customer premises.
Purpose:
Service providers with remote access to customer premises typically use this access to support POS POI systems or provide other remote services.
If a service provider uses the same authentication factors to access multiple customers, all the service provider’s customers can easily be compromised if an attacker compromises that one factor.
Criminals know this and deliberately target service providers looking for a shared authentication factor that gives them remote access to many merchants via that single factor.
Examples:
Technologies such as multi-factor mechanisms that provide a unique credential for each connection (such as a single-use password) could also meet the intent of this requirement.
Service providers with remote access to customer premises typically use this access to support POS POI systems or provide other remote services.
If a service provider uses the same authentication factors to access multiple customers, all the service provider’s customers can easily be compromised if an attacker compromises that one factor.
Criminals know this and deliberately target service providers looking for a shared authentication factor that gives them remote access to many merchants via that single factor.
Examples:
Technologies such as multi-factor mechanisms that provide a unique credential for each connection (such as a single-use password) could also meet the intent of this requirement.
Requirement 8.2.1
8.2.1
Defined Approach Requirements:
All users are assigned a unique ID before access to system components or cardholder data is allowed.
Customized Approach Objective:
All actions by all users are attributable to an individual.
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:
Defined Approach Requirements:
All users are assigned a unique ID before access to system components or cardholder data is allowed.
Customized Approach Objective:
All actions by all users are attributable to an individual.
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:
- 8.2.1.a Interview responsible personnel to verify that all users are assigned a unique ID for access to system components and cardholder data.
- 8.2.1.b Examine audit logs and other evidence to verify that access to system components and cardholder data can be uniquely identified and associated with individuals.
Purpose:
The ability to trace actions performed on a computer system to an individual establishes accountability and traceability and is fundamental to establishing effective access controls.
By ensuring each user is uniquely identified, instead of using one ID for several employees, an organization can maintain individual responsibility for actions and an effective record in the audit log per employee. In addition, this will assist with issue resolution and containment when misuse or malicious intent occurs.
The ability to trace actions performed on a computer system to an individual establishes accountability and traceability and is fundamental to establishing effective access controls.
By ensuring each user is uniquely identified, instead of using one ID for several employees, an organization can maintain individual responsibility for actions and an effective record in the audit log per employee. In addition, this will assist with issue resolution and containment when misuse or malicious intent occurs.
Guideline for a healthy information system v.2.0 (EN):
8 STANDARD
/STANDARD
In the event of an incident, in order to facilitate the attribution of an action within the information system or the identification of possible compromised accounts easier, access accounts must be nominative.
The use of generic accounts (e.g : admin, user) must be marginal and they must be able to be associated with a limited number of individuals.
Of course, this rule does not stop you from retaining service accounts attributed to an IT process (e.g : apache, mysqld).
In any event, generic and service accounts must be managed according to a policy that is at least as stringent as the one for nominative accounts. Moreover, a nominative administration account, different from the user account, must be attributed to each administrator. The usernames and authentication secrets must be different (e.g : pmartin as a username, adm-pmartin as an admin username). This admin account, having more privileges, must be exclusively dedicated to administration actions. Furthermore, it must be used in environments dedicated to administration in order that no connection traces or password hashes are left in a more exposed environment.
In the event of an incident, in order to facilitate the attribution of an action within the information system or the identification of possible compromised accounts easier, access accounts must be nominative.
The use of generic accounts (e.g : admin, user) must be marginal and they must be able to be associated with a limited number of individuals.
Of course, this rule does not stop you from retaining service accounts attributed to an IT process (e.g : apache, mysqld).
In any event, generic and service accounts must be managed according to a policy that is at least as stringent as the one for nominative accounts. Moreover, a nominative administration account, different from the user account, must be attributed to each administrator. The usernames and authentication secrets must be different (e.g : pmartin as a username, adm-pmartin as an admin username). This admin account, having more privileges, must be exclusively dedicated to administration actions. Furthermore, it must be used in environments dedicated to administration in order that no connection traces or password hashes are left in a more exposed environment.
Framework № PCI DSS 4.0 от 01.03.2022 "Payment Card Industry Data Security Standard (RU)":
Requirement 8.2.3
8.2.3
Определенные Требования к Подходу:
Дополнительное требование только для поставщиков услуг: Поставщики услуг с удаленным доступом к помещениям клиентов используют уникальные факторы аутентификации для каждого помещения клиента.
Цель Индивидуального подхода:
Учетные данные поставщика услуг, используемые для одного клиента, не могут быть использованы для любого другого клиента.
Примечания по применению:
Это требование применяется только в том случае, если оцениваемый субъект является поставщиком услуг.
Это требование не предназначено для применения к поставщикам услуг, получающим доступ к своим собственным средам общих служб, в которых размещены несколько клиентских сред.
Если сотрудники поставщика услуг используют общие факторы аутентификации для удаленного доступа к помещениям клиентов, эти факторы должны быть уникальными для каждого клиента и управляться в соответствии с требованием 8.2.2.
Определенные Процедуры Тестирования Подхода:
Определенные Требования к Подходу:
Дополнительное требование только для поставщиков услуг: Поставщики услуг с удаленным доступом к помещениям клиентов используют уникальные факторы аутентификации для каждого помещения клиента.
Цель Индивидуального подхода:
Учетные данные поставщика услуг, используемые для одного клиента, не могут быть использованы для любого другого клиента.
Примечания по применению:
Это требование применяется только в том случае, если оцениваемый субъект является поставщиком услуг.
Это требование не предназначено для применения к поставщикам услуг, получающим доступ к своим собственным средам общих служб, в которых размещены несколько клиентских сред.
Если сотрудники поставщика услуг используют общие факторы аутентификации для удаленного доступа к помещениям клиентов, эти факторы должны быть уникальными для каждого клиента и управляться в соответствии с требованием 8.2.2.
Определенные Процедуры Тестирования Подхода:
- 8.2.3 Дополнительная процедура тестирования только для оценки поставщиков услуг: Изучите политики и процедуры аутентификации и опросите персонал, чтобы убедиться, что поставщики услуг с удаленным доступом к помещениям клиентов используют уникальные факторы аутентификации для удаленного доступа к помещениям каждого клиента.
Цель:
Поставщики услуг с удаленным доступом к помещениям клиентов обычно используют этот доступ для поддержки систем POS POI или предоставления других удаленных услуг.
Если поставщик услуг использует одни и те же факторы аутентификации для доступа к нескольким клиентам, все клиенты поставщика услуг могут быть легко скомпрометированы, если злоумышленник скомпрометирует этот один фактор.
Преступники знают это и намеренно нацеливаются на поставщиков услуг, ищущих общий фактор аутентификации, который дает им удаленный доступ ко многим продавцам через этот единственный фактор.
Примеры:
Такие технологии, как многофакторные механизмы, которые предоставляют уникальные учетные данные для каждого соединения (например, одноразовый пароль), также могут соответствовать цели этого требования.
Поставщики услуг с удаленным доступом к помещениям клиентов обычно используют этот доступ для поддержки систем POS POI или предоставления других удаленных услуг.
Если поставщик услуг использует одни и те же факторы аутентификации для доступа к нескольким клиентам, все клиенты поставщика услуг могут быть легко скомпрометированы, если злоумышленник скомпрометирует этот один фактор.
Преступники знают это и намеренно нацеливаются на поставщиков услуг, ищущих общий фактор аутентификации, который дает им удаленный доступ ко многим продавцам через этот единственный фактор.
Примеры:
Такие технологии, как многофакторные механизмы, которые предоставляют уникальные учетные данные для каждого соединения (например, одноразовый пароль), также могут соответствовать цели этого требования.
Requirement 8.2.1
8.2.1
Определенные Требования к Подходу:
Всем пользователям присваивается уникальный идентификатор, прежде чем будет разрешен доступ к компонентам системы или данным о держателях карт.
Цель Индивидуального подхода:
Все действия всех пользователей приписываются отдельному лицу.
Примечания по применению:
Это требование не предназначено для применения к учетным записям пользователей в торговых терминалах, которые имеют доступ только к одному номеру карты одновременно для облегчения одной транзакции (например, идентификаторы, используемые кассирами в торговых терминалах).
Определенные Процедуры Тестирования Подхода:
Определенные Требования к Подходу:
Всем пользователям присваивается уникальный идентификатор, прежде чем будет разрешен доступ к компонентам системы или данным о держателях карт.
Цель Индивидуального подхода:
Все действия всех пользователей приписываются отдельному лицу.
Примечания по применению:
Это требование не предназначено для применения к учетным записям пользователей в торговых терминалах, которые имеют доступ только к одному номеру карты одновременно для облегчения одной транзакции (например, идентификаторы, используемые кассирами в торговых терминалах).
Определенные Процедуры Тестирования Подхода:
- 8.2.1. Провести собеседование с ответственным персоналом, чтобы убедиться, что всем пользователям присвоен уникальный идентификатор для доступа к компонентам системы и данным о держателях карт.
- 8.2.1.b Изучите журналы аудита и другие доказательства, чтобы убедиться, что доступ к компонентам системы и данным о держателях карт может быть однозначно идентифицирован и связан с отдельными лицами.
Цель:
Возможность отслеживать действия, выполняемые в компьютерной системе, для отдельного лица обеспечивает подотчетность и отслеживаемость и имеет основополагающее значение для установления эффективного контроля доступа.
Обеспечивая уникальную идентификацию каждого пользователя, вместо использования одного идентификатора для нескольких сотрудников, организация может поддерживать индивидуальную ответственность за действия и эффективную запись в журнале аудита для каждого сотрудника. Кроме того, это поможет в разрешении проблем и сдерживании при неправильном использовании или злонамеренном умысле.
Возможность отслеживать действия, выполняемые в компьютерной системе, для отдельного лица обеспечивает подотчетность и отслеживаемость и имеет основополагающее значение для установления эффективного контроля доступа.
Обеспечивая уникальную идентификацию каждого пользователя, вместо использования одного идентификатора для нескольких сотрудников, организация может поддерживать индивидуальную ответственность за действия и эффективную запись в журнале аудита для каждого сотрудника. Кроме того, это поможет в разрешении проблем и сдерживании при неправильном использовании или злонамеренном умысле.
Связанные защитные меры
Ничего не найдено
Мы используем cookie-файлы, чтобы получить статистику, которая помогает нам улучшить сервис для вас с целью персонализации сервисов и предложений. Вы может прочитать подробнее о cookie-файлах или изменить настройки браузера. Продолжая пользоваться сайтом, вы даёте согласие на использование ваших cookie-файлов и соглашаетесь с Политикой обработки персональных данных.