Куда я попал?
ГОСТ Р № 57580.1-2017 от 01.01.2018
Безопасность финансовых (банковских) операций. Защита информации финансовых организаций. Базовый состав организационных и технических мер. Раздел 7. Требования к системе защиты информации
РД.4
Для проведения оценки соответствия по документу войдите в систему.
Список требований
-
РД.4 Идентификация и многофакторная аутентификация эксплуатационного персонала
3-Н 2-Т 1-ТОбязательно для уровня защиты 1 2
Похожие требования
Приказ ФСТЭК России № 21 от 18.02.2013 "Состав и содержание мер по обеспечению безопасности персональных данных, необходимых для обеспечения каждого из уровней защищенности персональных данных":
ИАФ.1
ИАФ.1 Идентификация и аутентификация пользователей, являющихся работниками оператора
ГОСТ Р № 57580.4-2022 от 01.02.2023 "Безопасность финансовых (банковских) операций. Обеспечение операционной надежности. Базовый состав организационных и технических мер. Раздел 7":
ВПУ.13.1
ВПУ.13.1 Многофакторную аутентификацию субъектов доступа, осуществляющих удаленное техническое обслуживание и диагностику;
Framework № PCI DSS 4.0 от 01.03.2022 "Payment Card Industry Data Security Standard":
Requirement 8.3.1
8.3.1
Defined Approach Requirements:
All user access to system components for users and administrators is authenticated via at least one of the following authentication factors:
Defined Approach Requirements:
All user access to system components for users and administrators is authenticated via at least one of the following authentication factors:
- Something you know, such as a password or passphrase.
- Something you have, such as a token device or smart card.
- Something you are, such as a biometric element.
Customized Approach Objective:
An account cannot be accessed except with a combination of user identity and an authentication factor.
Applicability Notes:
This requirement is not intended to apply to user accounts on 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).
This requirement does not supersede multi-factor authentication (MFA) requirements but applies to those in-scope systems not otherwise subject to MFA requirements.
A digital certificate is a valid option for “something you have” if it is unique for a particular user.
Defined Approach Testing Procedures:
An account cannot be accessed except with a combination of user identity and an authentication factor.
Applicability Notes:
This requirement is not intended to apply to user accounts on 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).
This requirement does not supersede multi-factor authentication (MFA) requirements but applies to those in-scope systems not otherwise subject to MFA requirements.
A digital certificate is a valid option for “something you have” if it is unique for a particular user.
Defined Approach Testing Procedures:
- 8.3.1.a Examine documentation describing the authentication factor(s) used to verify that user access to system components is authenticated via at least one authentication factor specified in this requirement.
- 8.3.1.b For each type of authentication factor used with each type of system component, observe an authentication to verify that authentication is functioning consistently with documented authentication factor(s).
Purpose:
When used in addition to unique IDs, an authentication factor helps protect user IDs from being compromised, since the attacker needs to have the unique ID and compromise the associated authentication factor(s).
Good Practice:
A common approach for a malicious individual to compromise a system is to exploit weak or nonexistent authentication factors (for example, passwords/passphrases). Requiring strong authentication factors helps protect against this attack.
Further Information:
See fidoalliance.org for more information about using tokens, smart cards, or biometrics as authentication factors.
When used in addition to unique IDs, an authentication factor helps protect user IDs from being compromised, since the attacker needs to have the unique ID and compromise the associated authentication factor(s).
Good Practice:
A common approach for a malicious individual to compromise a system is to exploit weak or nonexistent authentication factors (for example, passwords/passphrases). Requiring strong authentication factors helps protect against this attack.
Further Information:
See fidoalliance.org for more information about using tokens, smart cards, or biometrics as authentication factors.
Requirement 7.3.1
7.3.1
Defined Approach Requirements:
An access control system(s) is in place that restricts access based on a user’s need to know and covers all system components.
Customized Approach Objective:
Access rights and privileges are managed via mechanisms intended for that purpose.
Defined Approach Testing Procedures:
Defined Approach Requirements:
An access control system(s) is in place that restricts access based on a user’s need to know and covers all system components.
Customized Approach Objective:
Access rights and privileges are managed via mechanisms intended for that purpose.
Defined Approach Testing Procedures:
- 7.3.1 Examine vendor documentation and system settings to verify that access is managed for each system component via an access control system(s) that restricts access based on a user’s need to know and covers all system components.
Purpose:
Without a mechanism to restrict access based on user’s need to know, a user may unknowingly be granted access to cardholder data. Access control systems automate the process of restricting access and assigning privileges.
Without a mechanism to restrict access based on user’s need to know, a user may unknowingly be granted access to cardholder data. Access control systems automate the process of restricting access and assigning privileges.
Requirement 8.4.2
8.4.2
Defined Approach Requirements:
MFA is implemented for all access into the CDE.
Customized Approach Objective:
Access into the CDE cannot be obtained by the use of a single authentication factor.
Applicability Notes:
This requirement does not apply to:
Defined Approach Requirements:
MFA is implemented for all access into the CDE.
Customized Approach Objective:
Access into the CDE cannot be obtained by the use of a single authentication factor.
Applicability Notes:
This requirement does not apply to:
- Application or system accounts performing automated functions.
- User accounts on 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).
MFA is required for both types of access specified in Requirements 8.4.2 and 8.4.3. Therefore, applying MFA to one type of access does not replace the need to apply another instance of MFA to the other type of access. If an individual first connects to the entity’s network via remote access, and then later initiates a connection into the CDE from within the network, per this requirement the individual would authenticate using MFA twice, once when connecting via remote access to the entity’s network and once when connecting via non-console administrative access from the entity’s network into the CDE.
The MFA requirements apply for all types of system components, including cloud, hosted systems, and on-premises applications, network security devices, workstations, servers, and endpoints, and includes access directly to an entity’s networks or systems as well as web-based access to an application or function.
MFA for remote access into the CDE can be implemented at the network or system/application level; it does not have to be applied at both levels. For example, if MFA is used when a user connects to the CDE network, it does not have to be used when the user logs into each system or application within the CDE.
This requirement is a best practice until 31 March 2025, after which it will be required and must be fully considered during a PCI DSS assessment.
Defined Approach Testing Procedures:
The MFA requirements apply for all types of system components, including cloud, hosted systems, and on-premises applications, network security devices, workstations, servers, and endpoints, and includes access directly to an entity’s networks or systems as well as web-based access to an application or function.
MFA for remote access into the CDE can be implemented at the network or system/application level; it does not have to be applied at both levels. For example, if MFA is used when a user connects to the CDE network, it does not have to be used when the user logs into each system or application within the CDE.
This requirement is a best practice until 31 March 2025, after which it will be required and must be fully considered during a PCI DSS assessment.
Defined Approach Testing Procedures:
- 8.4.2.a Examine network and/or system configurations to verify MFA is implemented for all access into the CDE. 8.4.2.b Observe personnel logging in to the CDE and examine evidence to verify that MFA is required.
Purpose:
Requiring more than one type of authentication factor reduces the probability that an attacker can gain access to a system by masquerading as a legitimate user, because the attacker would need to compromise multiple authentication factors. This is especially true in environments where traditionally the single authentication factor employed was something a user knows such as a password or passphrase.
Definitions:
Using one factor twice (for example, using two separate passwords) is not considered multifactor authentication.
Requiring more than one type of authentication factor reduces the probability that an attacker can gain access to a system by masquerading as a legitimate user, because the attacker would need to compromise multiple authentication factors. This is especially true in environments where traditionally the single authentication factor employed was something a user knows such as a password or passphrase.
Definitions:
Using one factor twice (for example, using two separate passwords) is not considered multifactor authentication.
Requirement 8.4.1
8.4.1
Defined Approach Requirements:
MFA is implemented for all non-console access into the CDE for personnel with administrative access.
Customized Approach Objective:
Administrative access to the CDE cannot be obtained by the use of a single authentication factor.
Applicability Notes:
The requirement for MFA for non-console administrative access applies to all personnel with elevated or increased privileges accessing the CDE via a non-console connection—that is, via logical access occurring over a network interface rather than via a direct, physical connection.
MFA is considered a best practice for non-console administrative access to in-scope system components that are not part of the CDE.
Defined Approach Testing Procedures:
Defined Approach Requirements:
MFA is implemented for all non-console access into the CDE for personnel with administrative access.
Customized Approach Objective:
Administrative access to the CDE cannot be obtained by the use of a single authentication factor.
Applicability Notes:
The requirement for MFA for non-console administrative access applies to all personnel with elevated or increased privileges accessing the CDE via a non-console connection—that is, via logical access occurring over a network interface rather than via a direct, physical connection.
MFA is considered a best practice for non-console administrative access to in-scope system components that are not part of the CDE.
Defined Approach Testing Procedures:
- 8.4.1.a Examine network and/or system configurations to verify MFA is required for all nonconsole into the CDE for personnel with administrative access.
- 8.4.1.b Observe administrator personnel logging into the CDE and verify that MFA is required.
Purpose:
Requiring more than one type of authentication factor reduces the probability that an attacker can gain access to a system by masquerading as a legitimate user, because the attacker would need to compromise multiple authentication factors. This is especially true in environments where traditionally the single authentication factor employed was something a user knows such as a password or passphrase.
Definitions:
Using one factor twice (for example, using two separate passwords) is not considered multifactor authentication.
Requiring more than one type of authentication factor reduces the probability that an attacker can gain access to a system by masquerading as a legitimate user, because the attacker would need to compromise multiple authentication factors. This is especially true in environments where traditionally the single authentication factor employed was something a user knows such as a password or passphrase.
Definitions:
Using one factor twice (for example, using two separate passwords) is not considered multifactor authentication.
Guideline for a healthy information system v.2.0 (EN):
13 STANDARD
/STANDARD
The implementation of a two-factor authentication is strongly recommended, requiring the use of two different authentication factors from among the following:
The implementation of a two-factor authentication is strongly recommended, requiring the use of two different authentication factors from among the following:
- something I know (password, unlock pattern, signature);
- something I have (smart card, USB token, magnetic card, RFID, a phone to receive an SMS);
- something I am (a digital fingerprint)
13 STRENGTHENED
/STRENGTHENED
Smart cards must be encouraged or, by default, one-time passwords with a physical token. Encryption operations implemented with two-factor authentication generally offer good security results.
Smart cards can be more complex to implement as they require an adapted key management structure. However, they have the advantage of being re-usable for various purposes: encryption, message authentication, authentication on the workstation, etc.
Smart cards must be encouraged or, by default, one-time passwords with a physical token. Encryption operations implemented with two-factor authentication generally offer good security results.
Smart cards can be more complex to implement as they require an adapted key management structure. However, they have the advantage of being re-usable for various purposes: encryption, message authentication, authentication on the workstation, etc.
32 STRENGTHENED
/STRENGTHENED
In order to avoid any reuse of authenticators from a stolen or lost device (saved username and password for example), it is preferable to use two-factor authentication, with a password and a certificate stored on an external medium (smart card or USB token) or a one-time password mechanism, for example.
In order to avoid any reuse of authenticators from a stolen or lost device (saved username and password for example), it is preferable to use two-factor authentication, with a password and a certificate stored on an external medium (smart card or USB token) or a one-time password mechanism, for example.
Framework № PCI DSS 4.0 от 01.03.2022 "Payment Card Industry Data Security Standard (RU)":
Requirement 8.4.2
8.4.2
Определенные Требования к Подходу:
MFA реализован для всех видов доступа к CDE.
Цель Индивидуального подхода:
Доступ к CDE не может быть получен с помощью одного фактора аутентификации.
Примечания по применению:
Это требование не распространяется на:
Определенные Требования к Подходу:
MFA реализован для всех видов доступа к CDE.
Цель Индивидуального подхода:
Доступ к CDE не может быть получен с помощью одного фактора аутентификации.
Примечания по применению:
Это требование не распространяется на:
- Учетные записи приложений или систем, выполняющие автоматизированные функции.
- Учетные записи пользователей в терминалах торговых точек, которые имеют доступ только к одному номеру карты одновременно для облегчения одной транзакции (например, идентификаторы, используемые кассирами в терминалах торговых точек).
MFA требуется для обоих типов доступа, указанных в Требованиях 8.4.2 и 8.4.3. Следовательно, применение MFA к одному типу доступа не заменяет необходимость применения другого экземпляра MFA к другому типу доступа. Если физическое лицо сначала подключается к сети организации через удаленный доступ, а затем позже инициирует подключение к CDE из сети, в соответствии с этим требованием физическое лицо будет проходить проверку подлинности с использованием MFA дважды, один раз при подключении через удаленный доступ к сети организации и один раз при подключении через неконсольный административный доступ из сети организации в CDE.
Требования MFA применяются ко всем типам системных компонентов, включая облачные, размещенные системы и локальные приложения, устройства сетевой безопасности, рабочие станции, серверы и конечные точки, и включают прямой доступ к сетям или системам организации, а также веб-доступ к приложению или функции.
MFA для удаленного доступа к CDE может быть реализован на сетевом или системном/прикладном уровне; его необязательно применять на обоих уровнях. Например, если MFA используется, когда пользователь подключается к сети CDE, его необязательно использовать, когда пользователь входит в каждую систему или приложение в CDE.
Это требование является наилучшей практикой до 31 марта 2025 года, после чего оно станет обязательным и должно быть полностью рассмотрено во время оценки PCI DSS.
Определенные Процедуры Тестирования Подхода:
Требования MFA применяются ко всем типам системных компонентов, включая облачные, размещенные системы и локальные приложения, устройства сетевой безопасности, рабочие станции, серверы и конечные точки, и включают прямой доступ к сетям или системам организации, а также веб-доступ к приложению или функции.
MFA для удаленного доступа к CDE может быть реализован на сетевом или системном/прикладном уровне; его необязательно применять на обоих уровнях. Например, если MFA используется, когда пользователь подключается к сети CDE, его необязательно использовать, когда пользователь входит в каждую систему или приложение в CDE.
Это требование является наилучшей практикой до 31 марта 2025 года, после чего оно станет обязательным и должно быть полностью рассмотрено во время оценки PCI DSS.
Определенные Процедуры Тестирования Подхода:
- 8.4.2.a Изучите сетевые и / или системные конфигурации, чтобы убедиться, что MFA реализован для любого доступа к CDE. 8.4.2.b Наблюдайте за персоналом, входящим в CDE, и изучайте доказательства, чтобы убедиться, что MFA требуется.
Цель:
Требование более одного типа фактора аутентификации снижает вероятность того, что злоумышленник сможет получить доступ к системе, выдавая себя за законного пользователя, поскольку злоумышленнику потребуется скомпрометировать несколько факторов аутентификации. Это особенно верно в средах, где традиционно единственным фактором аутентификации было то, что известно пользователю, например пароль или кодовая фраза.
Определения:
Использование одного фактора дважды (например, использование двух отдельных паролей) не считается многофакторной аутентификацией.
Требование более одного типа фактора аутентификации снижает вероятность того, что злоумышленник сможет получить доступ к системе, выдавая себя за законного пользователя, поскольку злоумышленнику потребуется скомпрометировать несколько факторов аутентификации. Это особенно верно в средах, где традиционно единственным фактором аутентификации было то, что известно пользователю, например пароль или кодовая фраза.
Определения:
Использование одного фактора дважды (например, использование двух отдельных паролей) не считается многофакторной аутентификацией.
Requirement 7.3.1
7.3.1
Определенные Требования к Подходу:
Существует система (системы) контроля доступа, которая ограничивает доступ на основе необходимости пользователя знать и охватывает все компоненты системы.
Цель Индивидуального подхода:
Права доступа и привилегии управляются с помощью механизмов, предназначенных для этой цели.
Определенные Процедуры Тестирования Подхода:
Определенные Требования к Подходу:
Существует система (системы) контроля доступа, которая ограничивает доступ на основе необходимости пользователя знать и охватывает все компоненты системы.
Цель Индивидуального подхода:
Права доступа и привилегии управляются с помощью механизмов, предназначенных для этой цели.
Определенные Процедуры Тестирования Подхода:
- 7.3.1 Изучите документацию поставщика и системные настройки, чтобы убедиться, что управление доступом для каждого компонента системы осуществляется с помощью системы (систем) контроля доступа, которая ограничивает доступ на основе потребностей пользователя и охватывает все компоненты системы.
Цель:
Без механизма ограничения доступа, основанного на необходимости пользователя знать, пользователь может неосознанно получить доступ к данным о держателях карт. Системы контроля доступа автоматизируют процесс ограничения доступа и назначения привилегий.
Без механизма ограничения доступа, основанного на необходимости пользователя знать, пользователь может неосознанно получить доступ к данным о держателях карт. Системы контроля доступа автоматизируют процесс ограничения доступа и назначения привилегий.
Requirement 8.4.1
8.4.1
Определенные Требования к Подходу:
MFA реализован для всего неконсольного доступа к CDE для персонала с административным доступом.
Цель Индивидуального подхода:
Административный доступ к CDE не может быть получен с помощью одного фактора аутентификации.
Примечания по применению:
Требование MFA для неконсольного административного доступа применяется ко всему персоналу с повышенными или повышенными привилегиями, получающему доступ к CDE через неконсольное соединение, то есть через логический доступ, осуществляемый через сетевой интерфейс, а не через прямое физическое соединение.
MFA считается наилучшей практикой для неконсольного административного доступа к системным компонентам, которые не являются частью CDE.
Определенные Процедуры Тестирования Подхода:
Определенные Требования к Подходу:
MFA реализован для всего неконсольного доступа к CDE для персонала с административным доступом.
Цель Индивидуального подхода:
Административный доступ к CDE не может быть получен с помощью одного фактора аутентификации.
Примечания по применению:
Требование MFA для неконсольного административного доступа применяется ко всему персоналу с повышенными или повышенными привилегиями, получающему доступ к CDE через неконсольное соединение, то есть через логический доступ, осуществляемый через сетевой интерфейс, а не через прямое физическое соединение.
MFA считается наилучшей практикой для неконсольного административного доступа к системным компонентам, которые не являются частью CDE.
Определенные Процедуры Тестирования Подхода:
- 8.4.1.проверка сетевых и/или системных конфигураций для проверки MFA требуется для всех неконсолей в CDE для персонала с административным доступом.
- 8.4.1.b Наблюдайте за тем, как персонал администратора входит в CDE, и убедитесь, что требуется MFA.
Цель:
Требование более одного типа фактора аутентификации снижает вероятность того, что злоумышленник сможет получить доступ к системе, выдавая себя за законного пользователя, поскольку злоумышленнику потребуется скомпрометировать несколько факторов аутентификации. Это особенно верно в средах, где традиционно единственным фактором аутентификации было то, что известно пользователю, например пароль или кодовая фраза.
Определения:
Использование одного фактора дважды (например, использование двух отдельных паролей) не считается многофакторной аутентификацией.
Требование более одного типа фактора аутентификации снижает вероятность того, что злоумышленник сможет получить доступ к системе, выдавая себя за законного пользователя, поскольку злоумышленнику потребуется скомпрометировать несколько факторов аутентификации. Это особенно верно в средах, где традиционно единственным фактором аутентификации было то, что известно пользователю, например пароль или кодовая фраза.
Определения:
Использование одного фактора дважды (например, использование двух отдельных паролей) не считается многофакторной аутентификацией.
Requirement 8.3.1
8.3.1
Определенные Требования к Подходу:
Весь пользовательский доступ к системным компонентам для пользователей и администраторов проверяется с помощью по крайней мере одного из следующих факторов аутентификации:
Определенные Требования к Подходу:
Весь пользовательский доступ к системным компонентам для пользователей и администраторов проверяется с помощью по крайней мере одного из следующих факторов аутентификации:
- Что-то, что вы знаете, например, пароль или кодовую фразу.
- Что-то, что у вас есть, например, токен-устройство или смарт-карта.
- Что-то, чем вы являетесь, например, биометрический элемент.
Цель Индивидуального подхода:
Доступ к учетной записи возможен только с использованием комбинации идентификатора пользователя и фактора аутентификации.
Примечания по применению:
Это требование не предназначено для применения к учетным записям пользователей в торговых терминалах, которые имеют доступ только к одному номеру карты одновременно для облегчения одной транзакции (например, идентификаторы, используемые кассирами в торговых терминалах).
Это требование не заменяет требования к многофакторной аутентификации (MFA), но применяется к тем системам, которые в других случаях не подпадают под требования MFA.
Цифровой сертификат является допустимым вариантом для “того, что у вас есть”, если он уникален для конкретного пользователя.
Определенные Процедуры Тестирования Подхода:
Доступ к учетной записи возможен только с использованием комбинации идентификатора пользователя и фактора аутентификации.
Примечания по применению:
Это требование не предназначено для применения к учетным записям пользователей в торговых терминалах, которые имеют доступ только к одному номеру карты одновременно для облегчения одной транзакции (например, идентификаторы, используемые кассирами в торговых терминалах).
Это требование не заменяет требования к многофакторной аутентификации (MFA), но применяется к тем системам, которые в других случаях не подпадают под требования MFA.
Цифровой сертификат является допустимым вариантом для “того, что у вас есть”, если он уникален для конкретного пользователя.
Определенные Процедуры Тестирования Подхода:
- 8.3.1.a Изучить документацию, описывающую фактор (ы) аутентификации, используемый(ые) для проверки того, что доступ пользователя к компонентам системы аутентифицируется по крайней мере с помощью одного фактора аутентификации, указанного в этом требовании.
- 8.3.1.b Для каждого типа фактора аутентификации, используемого с каждым типом системного компонента, соблюдайте аутентификацию, чтобы убедиться, что аутентификация работает в соответствии с задокументированным фактором (факторами) аутентификации.
Цель:
При использовании в дополнение к уникальным идентификаторам фактор аутентификации помогает защитить идентификаторы пользователей от взлома, поскольку злоумышленнику необходимо иметь уникальный идентификатор и скомпрометировать связанные с ним факторы аутентификации.
Надлежащая практика:
Распространенный подход злоумышленника к компрометации системы заключается в использовании слабых или несуществующих факторов аутентификации (например, паролей/парольных фраз). Требование надежных факторов аутентификации помогает защититься от этой атаки.
Дополнительная информация:
См. fidoalliance.org дополнительные сведения об использовании токенов, смарт-карт или биометрических данных в качестве факторов аутентификации см.
При использовании в дополнение к уникальным идентификаторам фактор аутентификации помогает защитить идентификаторы пользователей от взлома, поскольку злоумышленнику необходимо иметь уникальный идентификатор и скомпрометировать связанные с ним факторы аутентификации.
Надлежащая практика:
Распространенный подход злоумышленника к компрометации системы заключается в использовании слабых или несуществующих факторов аутентификации (например, паролей/парольных фраз). Требование надежных факторов аутентификации помогает защититься от этой атаки.
Дополнительная информация:
См. fidoalliance.org дополнительные сведения об использовании токенов, смарт-карт или биометрических данных в качестве факторов аутентификации см.
Приказ ФСТЭК России № 17 от 11.02.2013 "Требования о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах":
ИАФ.1
ИАФ.1 Идентификация и аутентификация пользователей, являющихся работниками оператора
Методика экспресс-оценки уровня кибербезопасности организации РезБез:
6.3.1.2.
Для удаленного доступа к системам и приложениям используется многофакторная аутентификация
SWIFT Customer Security Controls Framework v2022:
4 - 4.2 Multi-Factor Authentication
4.2 Multi-Factor Authentication
Приказ ФСТЭК России № 31 от 14.03.2014 "Состав мер защиты информации и их базовые наборы для соответствующего класса защищенности автоматизированной системы управления":
ИАФ.1
ИАФ.1 Идентификация и аутентификация пользователей и инициируемых ими процессов
Приказ ФСТЭК России № 239 от 25.12.2017 "Состав мер по обеспечению безопасности для значимого объекта соответствующей категории значимости":
ИАФ.1
ИАФ.1 Идентификация и аутентификация пользователей и инициируемых ими процессов
Связанные защитные меры
Ничего не найдено
Мы используем cookie-файлы, чтобы получить статистику, которая помогает нам улучшить сервис для вас с целью персонализации сервисов и предложений. Вы может прочитать подробнее о cookie-файлах или изменить настройки браузера. Продолжая пользоваться сайтом, вы даёте согласие на использование ваших cookie-файлов и соглашаетесь с Политикой обработки персональных данных.