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

NIST Cybersecurity Framework (RU)

Framework

PR.AC-7

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

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

CIS Critical Security Controls v8 (The 18 CIS CSC):
12.3
12.3 Securely Manage Network Infrastructure 
Securely manage network infrastructure. Example implementations include version-controlled-infrastructure-ascode, and the use of secure network protocols, such as SSH and HTTPS. 
6.5
6.5 Require MFA for Administrative Access 
Require MFA for all administrative access accounts, where supported, on all enterprise assets, whether managed on-site or through a third-party provider. 
6.4
6.4 Require MFA for Remote Network Access 
Require MFA for remote network access. 
ГОСТ Р № 22301 от 01.01.2022 "Надежность в технике. Системы менеджмента непрерывности деятельности. Требования":
Р. 8 п. 4 пп. 2 ппп. 4
 8.4.2.4 Для каждой команды необходимо: 
  • а) идентифицировать персонал и заменяющих лиц с необходимой ответственностью, полномочиями и компетенцией для выполнения назначенных функций; 
  • b) установить документированные процедуры управления действиями персонала (см. 8.4.4), в том числе для инициирования, выполнения, координации и обмена информацией об ответных мерах на нарушение деятельности организации. 
Приказ ФСТЭК России № 21 от 18.02.2013 "Состав и содержание мер по обеспечению безопасности персональных данных, необходимых для обеспечения каждого из уровней защищенности персональных данных":
ИАФ.6 ИАФ.6 Идентификация и аутентификация пользователей, не являющихся работниками оператора (внешних пользователей)
ИАФ.1 ИАФ.1 Идентификация и аутентификация пользователей, являющихся работниками оператора
Russian Unified Cyber Security Framework (на основе The 18 CIS CSC):
12.3
12.3 Реализовано управление безопасной сетевой инфраструктурой
Внедрить лучшие практики безопасного управления сетевой инфраструктурой 
6.5
6.5 Требуется многофакторная аутентификация для доступа с использованием прав администратора
Запрашивать многофакторную аутентификацию для доступа с правами администратора.
6.4
6.4 Требуется многофакторная аутентификация для удаленного доступа к сети
Запрашивать многофакторную аутентификацию для удаленного доступа к сети.
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:
  • 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:
  • 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. 
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:
  • 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. 
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:
  • 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:
  • 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. 
Requirement 8.4.3
8.4.3
Defined Approach Requirements: 
MFA is implemented for all remote network access originating from outside the entity’s network that could access or impact the CDE as follows: 
  • All remote access by all personnel, both users and administrators, originating from outside the entity’s network.
  • All remote access by third parties and vendors. 
Customized Approach Objective:
Remote access to the entity’s network cannot be obtained by using a single authentication factor. 

Applicability Notes:
The requirement for MFA for remote access originating from outside the entity’s network applies to all user accounts that can access the network remotely, where that remote access leads to or could lead to access into the CDE. 
If remote access is to a part of the entity’s network that is properly segmented from the CDE, such that remote users cannot access or impact the CDE, MFA for remote access to that part of the network is not required. However, MFA is required for any remote access to networks with access to the CDE and is recommended for all remote access to the entity’s networks. 
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. 

Defined Approach Testing Procedures:
  • 8.4.3.a Examine network and/or system configurations for remote access servers and systems to verify MFA is required in accordance with all elements specified in this requirement. 
  • 8.4.3.b Observe personnel (for example, users and administrators) connecting remotely to the network and verify that multi-factor authentication 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:
Multi-factor authentication (MFA) requires an individual to present a minimum of two of the three authentication factors specified in Requirement 8.3.1 before access is granted. 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:
  • 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. 
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:
  • 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) 
30 STRENGTHENED
/STRENGTHENED 
Finally, in order to make the device on its own unusable, the use of an additional external media (smart card or USB token for example) to hold decryption or authentication secrets may be considered. In this case, it must be kept separate. 
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. 
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. 
ГОСТ Р № ИСО/МЭК 27001-2021 от 01.01.2022 "Информационная технология. Методы и средства обеспечения безопасности. Системы менеджмента информационной безопасности. Требования - Приложение А":
A.9.2.4
A.9.2.4 Процесс управления секретной аутентификационной информацией пользователей 
Мера обеспечения информационной безопасности: Предоставление секретной аутентификационной информации должно контролироваться посредством формального процесса управления. 
A.9.4.2
A.9.4.2 Безопасные процедуры входа в систему 
Мера обеспечения информационной безопасности: Когда этого требует политика управления доступом, доступ к системам и приложениям должен управляться посредством безопасной процедуры входа в систему 
A.9.2.1
A.9.2.1 Регистрация и отмена регистрации пользователей 
Мера обеспечения информационной безопасности: Для назначения прав доступа должна быть реализована формализованная процедура регистрации и отмены регистрации пользователей 
A.9.4.3
A.9.4.3 Система управления паролями 
Мера обеспечения информационной безопасности: Системы управления паролями должны быть интерактивными и должны обеспечивать уверенность в качестве паролей 
A.18.1.4
A.18.1.4 Конфиденциальность и защита персональных данных 
Мера обеспечения информационной безопасности: Конфиденциальность и защита персональных данных должна обеспечиваться в соответствии с требованиями соответствующего законодательства и правилами там, где это применимо 
A.9.3.1
A.9.3.1 Использование секретной аутентификационной информации 
Мера обеспечения информационной безопасности: При использовании секретной аутентификационной информации пользователи должны выполнять установленные в организации правила 
CIS Critical Security Controls v7.1 (SANS Top 20):
CSC 16.3 CSC 16.3 Require Multi-Factor Authentication
Require multi-factor authentication for all user accounts, on all systems, whether managed on-site or by a third-party provider.
CSC 12.11 CSC 12.11 Require All Remote Login to Use Multi-Factor Authentication
Require all remote login access to the organization's network to encrypt data in transit and use multi-factor authentication.
CSC 11.5 CSC 11.5 Manage Network Devices Using Multi-Factor Authentication and Encrypted Sessions
Manage all network devices using multi-factor authentication and encrypted sessions.
CSC 15.8 CSC 15.8 Use Wireless Authentication Protocols That Require Mutual, Multi-Factor Authentication
Ensure that wireless networks use authentication protocols such as Extensible Authentication Protocol-Transport Layer Security (EAP/TLS), which requires mutual, multi-factor authentication.
CSC 4.5 CSC 4.5 Use Multi-Factor Authentication for All Administrative Access
Use multi-factor authentication and encrypted channels for all administrative account access.
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 требуется для обоих типов доступа, указанных в Требованиях 8.4.2 и 8.4.3. Следовательно, применение MFA к одному типу доступа не заменяет необходимость применения другого экземпляра MFA к другому типу доступа. Если физическое лицо сначала подключается к сети организации через удаленный доступ, а затем позже инициирует подключение к CDE из сети, в соответствии с этим требованием физическое лицо будет проходить проверку подлинности с использованием MFA дважды, один раз при подключении через удаленный доступ к сети организации и один раз при подключении через неконсольный административный доступ из сети организации в CDE.
Требования 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.

Определенные Процедуры Тестирования Подхода:
  • 8.4.1.проверка сетевых и/или системных конфигураций для проверки MFA требуется для всех неконсолей в CDE для персонала с административным доступом.
  • 8.4.1.b Наблюдайте за тем, как персонал администратора входит в CDE, и убедитесь, что требуется MFA.
Цель:
Требование более одного типа фактора аутентификации снижает вероятность того, что злоумышленник сможет получить доступ к системе, выдавая себя за законного пользователя, поскольку злоумышленнику потребуется скомпрометировать несколько факторов аутентификации. Это особенно верно в средах, где традиционно единственным фактором аутентификации было то, что известно пользователю, например пароль или кодовая фраза.

Определения:
Использование одного фактора дважды (например, использование двух отдельных паролей) не считается многофакторной аутентификацией.
Requirement 8.4.3
8.4.3
Определенные Требования к Подходу:
MFA реализуется для всего удаленного доступа к сети, исходящего из-за пределов сети организации, который может получить доступ к CDE или повлиять на него следующим образом:
  • Весь удаленный доступ для всего персонала, как пользователей, так и администраторов, исходящий из-за пределов сети организации.
  • Весь удаленный доступ третьих сторон и поставщиков.
Цель Индивидуального подхода:
Удаленный доступ к сети объекта не может быть получен с помощью одного фактора аутентификации.

Примечания по применению:
Требование для MFA для удаленного доступа, исходящего из-за пределов сети организации, применяется ко всем учетным записям пользователей, которые могут получать удаленный доступ к сети, если этот удаленный доступ ведет или может привести к доступу к CDE.
Если удаленный доступ осуществляется к части сети организации, которая должным образом сегментирована от CDE, так что удаленные пользователи не могут получить доступ к CDE или повлиять на него, MFA для удаленного доступа к этой части сети не требуется. Однако MFA требуется для любого удаленного доступа к сетям с доступом к CDE и рекомендуется для всего удаленного доступа к сетям организации.
Требования MFA применяются ко всем типам системных компонентов, включая облачные, размещенные системы и локальные приложения, устройства сетевой безопасности, рабочие станции, серверы и конечные точки, и включают прямой доступ к сетям или системам организации, а также веб-доступ к приложению или функции.

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

Определения:
Многофакторная аутентификация (MFA) требует, чтобы пользователь представил минимум два из трех факторов аутентификации, указанных в требовании 8.3.1, прежде чем будет предоставлен доступ. Использование одного фактора дважды (например, использование двух отдельных паролей) не считается многофакторной аутентификацией.
Requirement 8.3.1
8.3.1
Определенные Требования к Подходу:
Весь пользовательский доступ к системным компонентам для пользователей и администраторов проверяется с помощью по крайней мере одного из следующих факторов аутентификации:
  • Что-то, что вы знаете, например, пароль или кодовую фразу.
  • Что-то, что у вас есть, например, токен-устройство или смарт-карта.
  • Что-то, чем вы являетесь, например, биометрический элемент.
Цель Индивидуального подхода:
Доступ к учетной записи возможен только с использованием комбинации идентификатора пользователя и фактора аутентификации.

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

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

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

Дополнительная информация:
См. fidoalliance.org дополнительные сведения об использовании токенов, смарт-карт или биометрических данных в качестве факторов аутентификации см.
Приказ ФСТЭК России № 17 от 11.02.2013 "Требования о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах":
ИАФ.1 ИАФ.1 Идентификация и аутентификация пользователей, являющихся работниками оператора
ИАФ.6 ИАФ.6 Идентификация и аутентификация пользователей, не являющихся работниками оператора (внешних пользователей)
Стандарт № ИСО/МЭК 27001:2022(E) от 25.10.2022 "Информационная безопасность, кибербезопасность и защита частной жизни — Системы управления информационной безопасностью — Требования. Приложение А":
А.5.17
А.5.17 Аутентификационная информация
Распределение и управление аутентификационной информацией должно контролироваться процессом управления, включая информирование персонала о надлежащем обращении с аутентификационной информацией.
А.8.5
А.8.5 Безопасная аутентификация
Технологии и процедуры безопасной аутентификации должны быть внедрены на основании ограничений доступа к информации и специфической тематической политики по контролю доступа.
Положение Банка России № 719-П от 04.06.2020 "О требованиях к обеспечению защиты информации при осуществлении переводов денежных средств и о порядке осуществления Банком России контроля за соблюдением требований к обеспечению защиты информации при осуществлении переводов денежных средств":
Глава 2 п. 9
2.9. Технологические меры, указанные в пункте 2.8 настоящего Положения, должны обеспечивать реализацию:
  • механизмов идентификации и аутентификации клиента оператора по переводу денежных средств при формировании (подготовке) и при подтверждении им электронных сообщений в соответствии с требованиями законодательства Российской Федерации;
  • механизмов двухфакторной аутентификации клиента оператора по переводу денежных средств при совершении им действий в целях осуществления переводов денежных средств;
  • механизмов и (или) протоколов формирования и обмена электронными сообщениями, обеспечивающих защиту электронных сообщений от искажения, фальсификации, переадресации, несанкционированного ознакомления и (или) уничтожения, ложной авторизации, в том числе аутентификацию входных электронных сообщений;
  • взаимной (двухсторонней) аутентификации участников обмена средствами вычислительной техники операторов по переводу денежных средств, банковских платежных агентов (субагентов), операторов услуг информационного обмена, операторов услуг платежной инфраструктуры, клиентов операторов по переводу денежных средств;
  • возможности использования клиентом оператора по переводу денежных средств независимых программных сред для формирования (подготовки) и подтверждения электронных сообщений;
  • возможности контроля клиентом оператора по переводу денежных средств реквизитов распоряжений о переводе денежных средств при формировании (подготовке) электронных сообщений (пакета электронных сообщений) и их подтверждении;
  • возможности установления временных ограничений на выполнение клиентом оператора по переводу денежных средств подтверждения электронных сообщений;
  • функций передаваемого клиенту оператора по переводу денежных средств программного обеспечения, используемого при осуществлении переводов денежных средств и предназначенного для установки на мобильные устройства клиента оператора по переводу денежных средств, связанных с выявлением модификации мобильного устройства клиента оператора по переводу денежных средств с использованием недекларируемых возможностей, в том числе деактивации (отключения) механизма разграничения доступа (далее - недекларируемая модификация мобильного устройства клиента), а также уведомлением клиента оператора по переводу денежных средств о случаях недекларируемой модификации мобильного устройства клиента с указанием рисков использования такого устройства (при наличии технической возможности).
SWIFT Customer Security Controls Framework v2022:
4 - 4.2 Multi-Factor Authentication
4.2 Multi-Factor Authentication
Положение Банка России № 808-П от 17.10.2022 "О требованиях к обеспечению защиты информации при осуществлении деятельности в сфере оказания профессиональных услуг на финансовом рынке в целях противодействия осуществлению незаконных финансовых операций":
Глава 2 Пункт 6 Подпункт 1
2.6.1. Технология обработки защищаемой информации, применяемая бюро кредитных историй на всех технологических участках, должна обеспечивать целостность и неизменность защищаемой информации, в том числе путем взаимной (двухсторонней) аутентификации с субъектами взаимодействия средствами вычислительной техники бюро кредитных историй и субъектов взаимодействия.
Приказ ФСТЭК России № 31 от 14.03.2014 "Состав мер защиты информации и их базовые наборы для соответствующего класса защищенности автоматизированной системы управления":
ИАФ.1 ИАФ.1 Идентификация и аутентификация пользователей и инициируемых ими процессов
NIST Cybersecurity Framework (EN):
PR.AC-7 PR.AC-7: Users, devices, and other assets are authenticated (e.g., single-factor, multi-factor) commensurate with the risk of the transaction (e.g., individuals’ security and privacy risks and other organizational risks)
Приказ ФСТЭК России № 239 от 25.12.2017 "Состав мер по обеспечению безопасности для значимого объекта соответствующей категории значимости":
ИАФ.1 ИАФ.1 Идентификация и аутентификация пользователей и инициируемых ими процессов
Стандарт № ISO/IEC 27001:2022(E) от 25.10.2022 "Information security, cybersecurity and privacy protection — Information security management systems — Requirements. Annex A":
А.5.17
А.5.17 Authentication information
Allocation and management of authentication information shall be controlled by a management process, including advising personnel of appropriate handling of authentication information.
А.8.5
А.8.5 Secure authentication
Secure authentication technologies and procedures shall be implemented based on information access restrictions and the topic-specific policy on access control.