Куда я попал?
SWIFT Customer Security Controls Framework v2022
Framework
4 - 4.2 Multi-Factor Authentication
Для проведения оценки соответствия по документу войдите в систему.
Список требований
-
4.2 Multi-Factor AuthenticationОбязательно для типа архитектуры A1 A2 A3 A4 BОбласть требования: Коннектор SWIFT | Коммуникационный интерфейс SWIFT | Интерфейс обмена сообщениями SWIFT | Jump Server SWIFT | Выделенный компьютер оператора SWIFT
Похожие требования
CIS Critical Security Controls v8 (The 18 CIS CSC):
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.
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.
Require MFA for remote network access.
ГОСТ Р № 57580.1-2017 от 01.01.2018 "Безопасность финансовых (банковских) операций. Защита информации финансовых организаций. Базовый состав организационных и технических мер. Раздел 7. Требования к системе защиты информации":
РД.2
РД.2 Идентификация и многофакторная аутентификация пользователей
3-Н 2-Н 1-Т
3-Н 2-Н 1-Т
РД.4
РД.4 Идентификация и многофакторная аутентификация эксплуатационного персонала
3-Н 2-Т 1-Т
3-Н 2-Т 1-Т
NIST Cybersecurity Framework (RU):
PR.AC-1
PR.AC-1: Для авторизованных устройств, пользователей и процессов выдаются, управляются, верифицируются, аннулируются и проверяются идентификационные и учетные данные
PR.AC-6
PR.AC-6: Идентификационные данные проверяются и привязываются к учетным данным, а при необходимости утверждаются при взаимодействии
PR.AC-7
PR.AC-7: Пользователи, устройства и другие активы проходят аутентификацию (например, однофакторную, многофакторную), соизмеримую с риском транзакции (например, рисками безопасности и конфиденциальности отдельных лиц и другими организационными рисками)
Приказ ФСТЭК России № 21 от 18.02.2013 "Состав и содержание мер по обеспечению безопасности персональных данных, необходимых для обеспечения каждого из уровней защищенности персональных данных":
ИАФ.4
ИАФ.4 Управление средствами аутентификации, в том числе хранение, выдача, инициализация, блокирование средств аутентификации и принятие мер в случае утраты и (или) компрометации средств аутентификации
Russian Unified Cyber Security Framework (на основе The 18 CIS CSC):
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:
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 8.2.5
8.2.5
Defined Approach Requirements:
Access for terminated users is immediately revoked.
Customized Approach Objective:
The accounts of terminated users cannot be used.
Defined Approach Testing Procedures:
Defined Approach Requirements:
Access for terminated users is immediately revoked.
Customized Approach Objective:
The accounts of terminated users cannot be used.
Defined Approach Testing Procedures:
- 8.2.5.a Examine information sources for terminated users and review current user access lists—for both local and remote access—to verify that terminated user IDs have been deactivated or removed from the access lists.
- 8.2.5.b Interview responsible personnel to verify that all physical authentication factors—such as, smart cards, tokens, etc.—have been returned or deactivated for terminated users.
Purpose:
If an employee or third party/vendor has left the company and still has access to the network via their user account, unnecessary or malicious access to cardholder data could occur—either by the former employee or by a malicious user who exploits the old and/or unused account.
If an employee or third party/vendor has left the company and still has access to the network via their user account, unnecessary or malicious access to cardholder data could occur—either by the former employee or by a malicious user who exploits the old and/or unused account.
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.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)
ГОСТ Р № ИСО/МЭК 27001-2021 от 01.01.2022 "Информационная технология. Методы и средства обеспечения безопасности. Системы менеджмента информационной безопасности. Требования - Приложение А":
A.9.4.2
A.9.4.2 Безопасные процедуры входа в систему
Мера обеспечения информационной безопасности: Когда этого требует политика управления доступом, доступ к системам и приложениям должен управляться посредством безопасной процедуры входа в систему
Мера обеспечения информационной безопасности: Когда этого требует политика управления доступом, доступ к системам и приложениям должен управляться посредством безопасной процедуры входа в систему
CIS Critical Security Controls v7.1 (SANS Top 20):
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.
Use multi-factor authentication and encrypted channels for all administrative account access.
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.
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.
Require all remote login access to the organization's network to encrypt data in transit and use multi-factor authentication.
Framework № PCI DSS 4.0 от 01.03.2022 "Payment Card Industry Data Security Standard (RU)":
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.2.5
8.2.5
Определенные Требования к Подходу:
Доступ для прекращенных пользователей немедленно аннулируется.
Цель Индивидуального подхода:
Учетные записи прекращенных пользователей не могут быть использованы.
Определенные Процедуры Тестирования Подхода:
Определенные Требования к Подходу:
Доступ для прекращенных пользователей немедленно аннулируется.
Цель Индивидуального подхода:
Учетные записи прекращенных пользователей не могут быть использованы.
Определенные Процедуры Тестирования Подхода:
- 8.2.5.a Изучите источники информации о завершенных пользователях и просмотрите текущие списки доступа пользователей — как для локального, так и для удаленного доступа — чтобы убедиться, что идентификаторы завершенных пользователей были деактивированы или удалены из списков доступа.
- 8.2.5.b Опросите ответственный персонал, чтобы убедиться, что все физические факторы аутентификации — такие как смарт—карты, токены и т.д. - были возвращены или деактивированы для прекращенных пользователей.
Цель:
Если сотрудник или третья сторона/ поставщик покинули компанию и по—прежнему имеют доступ к сети через свою учетную запись пользователя, может возникнуть ненужный или злонамеренный доступ к данным о держателях карт - либо со стороны бывшего сотрудника, либо со стороны злоумышленника, который использует старую и/или неиспользуемую учетную запись.
Если сотрудник или третья сторона/ поставщик покинули компанию и по—прежнему имеют доступ к сети через свою учетную запись пользователя, может возникнуть ненужный или злонамеренный доступ к данным о держателях карт - либо со стороны бывшего сотрудника, либо со стороны злоумышленника, который использует старую и/или неиспользуемую учетную запись.
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 "Требования о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах":
ИАФ.4
ИАФ.4 Управление средствами аутентификации, в том числе хранение, выдача, инициализация, блокирование средств аутентификации и принятие мер в случае утраты и (или) компрометации средств аутентификации
Strategies to Mitigate Cyber Security Incidents (EN):
2.3.
Multi-factor authentication including for VPNs, RDP, SSH and other remote access, and for all users when they perform a privileged action or access an important (sensitive/high-availability) data repository.
Relative Security Effectiveness: Essential | Potential User Resistance: Medium | Upfront Cost: High | Ongoing Maintenance Cost: Medium
Relative Security Effectiveness: Essential | Potential User Resistance: Medium | Upfront Cost: High | Ongoing Maintenance Cost: Medium
Стандарт № ИСО/МЭК 27001:2022(E) от 25.10.2022 "Информационная безопасность, кибербезопасность и защита частной жизни — Системы управления информационной безопасностью — Требования. Приложение А":
А.8.5
А.8.5 Безопасная аутентификация
Технологии и процедуры безопасной аутентификации должны быть внедрены на основании ограничений доступа к информации и специфической тематической политики по контролю доступа.
Технологии и процедуры безопасной аутентификации должны быть внедрены на основании ограничений доступа к информации и специфической тематической политики по контролю доступа.
Приказ ФСТЭК России № 31 от 14.03.2014 "Состав мер защиты информации и их базовые наборы для соответствующего класса защищенности автоматизированной системы управления":
ИАФ.4
ИАФ.4 Управление средствами аутентификации
NIST Cybersecurity Framework (EN):
PR.AC-1
PR.AC-1: Identities and credentials are issued, managed, verified, revoked, and audited for authorized devices, users and processes
PR.AC-6
PR.AC-6: Identities are proofed and bound to credentials and asserted in interactions
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 "Состав мер по обеспечению безопасности для значимого объекта соответствующей категории значимости":
ИАФ.4
ИАФ.4 Управление средствами аутентификации
ГОСТ Р № ИСО/МЭК 27002-2021 от 30.11.2021 "Информационные технологии. Методы и средства обеспечения безопасности. Свод норм и правил применения мер обеспечения информационной безопасности":
9.4.2
9.4.2 Безопасные процедуры входа в систему
Мера обеспечения ИБ
Когда этого требует политика управления доступом, доступ к системам и приложениям должен управляться посредством безопасной процедуры входа в систему.
Руководство по применению
Должны быть выбраны подходящие методы аутентификации для подтверждения заявленной личности пользователя.
Там, где требуется строгая аутентификация и проверка личности, должны использоваться методы аутентификации, альтернативные паролям, такие как криптографические средства, смарт-карты, токены или биометрические средства.
Процедура входа в систему или приложение должна быть разработана таким образом, чтобы минимизировать возможность несанкционированного доступа. Таким образом, процедура входа в систему должна раскрывать минимум информации о системе или приложении, во избежание оказания какой-либо неумышленной помощи неавторизованному пользователю. Разработанная надлежащим образом процедура входа должна:
- a) не отображать идентификаторы системы или приложения до тех пор, пока процесс входа успешно не завершен;
- b) выводить общее предупреждение, что доступ к компьютеру предоставляется только авторизованным пользователям;
- c) не предоставлять подсказок во время процедуры входа, которые могли бы помочь неавторизованному пользователю;
- d) осуществлять подтверждение информации для входа только после завершения ввода всех данных. Если возникает ошибка, система не должна указывать, какая часть данных для входа является правильной или неправильной;
- e) защищать от попыток входа в систему методом полного перебора (грубой силы);
- f) регистрировать неуспешные и успешные попытки входа;
- g) фиксировать событие безопасности при обнаружении попыток или фактов успешного нарушения процедуры входа;
- h) отображать следующую информацию по завершении успешного входа в систему:
- - дата и время предыдущего успешного входа;
- - сведения всех неудачных попыток входа с момента последнего успешного входа;
- i) не отображать вводимый пароль;
- j) не передавать пароли в открытом виде по сети;
- k) завершать неактивные сессии после определенного периода бездействия, особенно в местах повышенного риска, таких как общественные места или точки за пределами организации, которые не попадают под контроль системы менеджмента информационной безопасности организации, или на мобильных устройствах;
- l) ограничивать время соединения для обеспечения дополнительной защиты приложений с высоким риском и снижения возможности несанкционированного доступа.
Дополнительная информация
Пароли являются наиболее распространенным способом обеспечения идентификации и аутентификации на основе использования секрета, который знает только пользователь. То же самое может быть достигнуто при использовании криптографических средств и протоколов аутентификации. Надежность аутентификации пользователя должна соответствовать категории информации, к которой осуществляется доступ.
Если пароли передаются по сети в открытом виде во время процедуры входа, они могут быть перехвачены программой анализа сетевого трафика.
Стандарт № ISO/IEC 27001:2022(E) от 25.10.2022 "Information security, cybersecurity and privacy protection — Information security management systems — Requirements. Annex A":
А.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.
Secure authentication technologies and procedures shall be implemented based on information access restrictions and the topic-specific policy on access control.
Связанные защитные меры
Ничего не найдено
Мы используем cookie-файлы, чтобы получить статистику, которая помогает нам улучшить сервис для вас с целью персонализации сервисов и предложений. Вы может прочитать подробнее о cookie-файлах или изменить настройки браузера. Продолжая пользоваться сайтом, вы даёте согласие на использование ваших cookie-файлов и соглашаетесь с Политикой обработки персональных данных.