Куда я попал?
SWIFT Customer Security Controls Framework v2022
Framework
4 - 4.1 Password Policy
Для проведения оценки соответствия по документу войдите в систему.
Список требований
-
4.1 Password PolicyОбязательно для типа архитектуры A1 A2 A3 A4 BОбласть требования: Универсальный компьютер оператора SWIFT | Jump Server SWIFT | Выделенный компьютер оператора SWIFT | Промежуточный сервер SWIFT
Похожие требования
CIS Critical Security Controls v8 (The 18 CIS CSC):
5.2
5.2 Use Unique Passwords
Use unique passwords for all enterprise assets. Best practice implementation includes, at a minimum, an 8-character password for accounts using MFA and a 14-character password for accounts not using MFA.
Use unique passwords for all enterprise assets. Best practice implementation includes, at a minimum, an 8-character password for accounts using MFA and a 14-character password for accounts not using MFA.
ГОСТ Р № 57580.1-2017 от 01.01.2018 "Безопасность финансовых (банковских) операций. Защита информации финансовых организаций. Базовый состав организационных и технических мер. Раздел 7. Требования к системе защиты информации":
РД.9
РД.9 Запрет использования учетных записей субъектов логического доступа с незаданными аутентификационными данными или заданными по умолчанию разработчиком ресурса доступа, в том числе разработчиком АС
3-О 2-О 1-О
3-О 2-О 1-О
РД.24
РД.24 Запрет использования в качестве паролей субъектов логического доступа легко вычисляемых сочетаний букв и цифр (например, имена, фамилии, наименования, общепринятые сокращения)
3-Н 2-О 1-О
3-Н 2-О 1-О
РД.23
РД.23 Использование при формировании паролей субъектов логического доступа символов, включающих буквы (в верхнем и нижнем регистрах) и цифры
3-Т 2-Т 1-Т
3-Т 2-Т 1-Т
РД.21
РД.21 Использование пользователями паролей длиной не менее восьми символов
3-Т 2-Т 1-Т
3-Т 2-Т 1-Т
NIST Cybersecurity Framework (RU):
PR.AC-1
PR.AC-1: Для авторизованных устройств, пользователей и процессов выдаются, управляются, верифицируются, аннулируются и проверяются идентификационные и учетные данные
Приказ ФСТЭК России № 21 от 18.02.2013 "Состав и содержание мер по обеспечению безопасности персональных данных, необходимых для обеспечения каждого из уровней защищенности персональных данных":
АНЗ.5
АНЗ.5 Контроль правил генерации и смены паролей пользователей, заведения и удаления учетных записей пользователей, реализации правил разграничения доступа, полномочий пользователей в информационной системе
Russian Unified Cyber Security Framework (на основе The 18 CIS CSC):
5.2
5.2 Используются уникальные пароли
Для учетных записей с многофакторной аутентификацией задан пароль длиной не менее 8 символов.
Для учетных записей без многофакторной аутентификации задан пароль длиной не менее 14 символов.
Для учетных записей с многофакторной аутентификацией задан пароль длиной не менее 8 символов.
Для учетных записей без многофакторной аутентификации задан пароль длиной не менее 14 символов.
Framework № PCI DSS 4.0 от 01.03.2022 "Payment Card Industry Data Security Standard":
Requirement 2.3.1
2.3.1
Defined Approach Requirements:
For wireless environments connected to the CDE or transmitting account data, all wireless vendor defaults are changed at installation or are confirmed to be secure, including but not limited to:
Defined Approach Requirements:
For wireless environments connected to the CDE or transmitting account data, all wireless vendor defaults are changed at installation or are confirmed to be secure, including but not limited to:
- Default wireless encryption keys.
- Passwords on wireless access points.
- SNMP defaults.
- Any other security-related wireless vendor defaults.
Customized Approach Objective:
Wireless networks cannot be accessed using vendor default passwords or default configurations.
Applicability Notes:
This includes, but is not limited to, default wireless encryption keys, passwords on wireless access points, SNMP defaults, and any other securityrelated wireless vendor defaults.
Defined Approach Testing Procedures:
Wireless networks cannot be accessed using vendor default passwords or default configurations.
Applicability Notes:
This includes, but is not limited to, default wireless encryption keys, passwords on wireless access points, SNMP defaults, and any other securityrelated wireless vendor defaults.
Defined Approach Testing Procedures:
- 2.3.1.a Examine policies and procedures and interview responsible personnel to verify that processes are defined for wireless vendor defaults to either change them upon installation or to confirm them to be secure in accordance with all elements of this requirement.
- 2.3.1.b Examine vendor documentation and observe a system administrator logging into wireless devices to verify:
- SNMP defaults are not used.
- Default passwords/passphrases on wireless access points are not used.
- 2.3.1.c Examine vendor documentation and wireless configuration settings to verify other security-related wireless vendor defaults were changed, if applicable.
Purpose:
If wireless networks are not implemented with sufficient security configurations (including changing default settings), wireless sniffers can eavesdrop on the traffic, easily capture data and passwords, and easily enter and attack the network.
Good Practice:
Wireless passwords should be constructed so that they are resistant to offline brute force attacks.
If wireless networks are not implemented with sufficient security configurations (including changing default settings), wireless sniffers can eavesdrop on the traffic, easily capture data and passwords, and easily enter and attack the network.
Good Practice:
Wireless passwords should be constructed so that they are resistant to offline brute force attacks.
Requirement 8.3.5
8.3.5
Defined Approach Requirements:
If passwords/passphrases are used as authentication factors to meet Requirement 8.3.1, they are set and reset for each user as follows:
Defined Approach Requirements:
If passwords/passphrases are used as authentication factors to meet Requirement 8.3.1, they are set and reset for each user as follows:
- Set to a unique value for first-time use and upon reset.
- Forced to be changed immediately after the first use.
Customized Approach Objective:
An initial or reset password/passphrase assigned to a user cannot be used by an unauthorized user.
Defined Approach Testing Procedures:
An initial or reset password/passphrase assigned to a user cannot be used by an unauthorized user.
Defined Approach Testing Procedures:
- 8.3.5 Examine procedures for setting and resetting passwords/passphrases (if used as authentication factors to meet Requirement 8.3.1) and observe security personnel to verify that passwords/passphrases are set and reset in accordance with all elements specified in this requirement.
Purpose:
If the same password/passphrase is used for every new user, an internal user, former employee, or malicious individual may know or easily discover the value and use it to gain access to accounts before the authorized user attempts to use the password.
If the same password/passphrase is used for every new user, an internal user, former employee, or malicious individual may know or easily discover the value and use it to gain access to accounts before the authorized user attempts to use the password.
Requirement 8.3.6
Defined Approach Testing Procedures:
8.3.6
Defined Approach Requirements:
If passwords/passphrases are used as authentication factors to meet Requirement 8.3.1, they meet the following minimum level of complexity:
Defined Approach Requirements:
If passwords/passphrases are used as authentication factors to meet Requirement 8.3.1, they meet the following minimum level of complexity:
- A minimum length of 12 characters (or IF the system does not support 12 characters, a minimum length of eight characters).
- Contain both numeric and alphabetic characters.
Customized Approach Objective:
A guessed password/passphrase cannot be verified by either an online or offline brute force attack.
Applicability Notes:
This requirement is not intended to apply to:
A guessed password/passphrase cannot be verified by either an online or offline brute force attack.
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).
- Application or system accounts, which are governed by requirements in section 8.6.
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.
Until 31 March 2025, passwords must be a minimum length of seven characters in accordance with PCI DSS v3.2.1 Requirement 8.2.3.
Until 31 March 2025, passwords must be a minimum length of seven characters in accordance with PCI DSS v3.2.1 Requirement 8.2.3.
Defined Approach Testing Procedures:
- 8.3.6 Examine system configuration settings to verify that user password/passphrase complexity parameters are set in accordance with all elements specified in this requirement.
Purpose:
Strong passwords/passphrases may be the first line of defense into a network since a malicious individual will often first try to find accounts with weak, static, or non-existent passwords. If passwords are short or easily guessable, it is relatively easy for a malicious individual to find these weak accounts and compromise a network under the guise of a valid user ID.
Good Practice:
Password/passphrase strength is dependent on password/passphrase complexity, length, and randomness. Passwords/passphrases should be sufficiently complex, so they are impractical for an attacker to guess or otherwise discover its value. Entities can consider adding increased complexity by requiring the use of special characters and upper- and lower-case characters, in addition to the minimum standards outlined by this requirement. Additional complexity increases the time required for offline brute force attacks of hashed passwords/passphrases.
Another option for increasing the resistance of passwords to guessing attacks is by comparing proposed password/passphrases to a bad password list and having users provide new passwords for any passwords found on the list.
Strong passwords/passphrases may be the first line of defense into a network since a malicious individual will often first try to find accounts with weak, static, or non-existent passwords. If passwords are short or easily guessable, it is relatively easy for a malicious individual to find these weak accounts and compromise a network under the guise of a valid user ID.
Good Practice:
Password/passphrase strength is dependent on password/passphrase complexity, length, and randomness. Passwords/passphrases should be sufficiently complex, so they are impractical for an attacker to guess or otherwise discover its value. Entities can consider adding increased complexity by requiring the use of special characters and upper- and lower-case characters, in addition to the minimum standards outlined by this requirement. Additional complexity increases the time required for offline brute force attacks of hashed passwords/passphrases.
Another option for increasing the resistance of passwords to guessing attacks is by comparing proposed password/passphrases to a bad password list and having users provide new passwords for any passwords found on the list.
Requirement 2.2.2
Customized Approach Objective:
System components cannot be accessed using default passwords.
Applicability Notes:
This applies to ALL vendor default accounts and passwords, including, but not limited to, those used by operating systems, software that provides security services, application and system accounts, point-of-sale (POS) terminals, payment applications, and Simple Network Management Protocol (SNMP) defaults.
This requirement also applies where a system component is not installed within an entity’s environment, for example, software and applications that are part of the CDE and are accessed via a cloud subscription service.
Defined Approach Testing Procedures:
2.2.2
Defined Approach Requirements:
Vendor default accounts are managed as follows:
Defined Approach Requirements:
Vendor default accounts are managed as follows:
- If the vendor default account(s) will be used, the default password is changed per Requirement 8.3.6.
- If the vendor default account(s) will not be used, the account is removed or disabled.
Customized Approach Objective:
System components cannot be accessed using default passwords.
Applicability Notes:
This applies to ALL vendor default accounts and passwords, including, but not limited to, those used by operating systems, software that provides security services, application and system accounts, point-of-sale (POS) terminals, payment applications, and Simple Network Management Protocol (SNMP) defaults.
This requirement also applies where a system component is not installed within an entity’s environment, for example, software and applications that are part of the CDE and are accessed via a cloud subscription service.
Defined Approach Testing Procedures:
- 2.2.2.a Examine system configuration standards to verify they include managing vendor default accounts in accordance with all elements specified in this requirement.
- 2.2.2.b Examine vendor documentation and observe a system administrator logging on using vendor default accounts to verify accounts are implemented in accordance with all elements specified in this requirement.
- 2.2.2.c Examine configuration files and interview personnel to verify that all vendor default accounts that will not be used are removed or disabled.
Purpose:
Malicious individuals often use vendor default account names and passwords to compromise operating systems, applications, and the systems on which they are installed.
Because these default settings are often published and are well known, changing these settings will make systems less vulnerable to attack.
Good Practice:
All vendor default accounts should be identified, and their purpose and use understood. It is important to establish controls for application and system accounts, including those used to deploy and maintain cloud services so that they do not use default passwords and are not usable by unauthorized individuals.
Where a default account is not intended to be used, changing the default password to a unique password that meets PCI DSS Requirement 8.3.6, removing any access to the default account, and then disabling the account, will prevent a malicious individual from re-enabling the account and gaining access with the default password.
Using an isolated staging network to install and configure new systems is recommended and can also be used to confirm that default credentials have not been introduced into production environments.
Examples:
Defaults to be considered include user IDs, passwords, and other authentication credentials commonly used by vendors in their products.
Malicious individuals often use vendor default account names and passwords to compromise operating systems, applications, and the systems on which they are installed.
Because these default settings are often published and are well known, changing these settings will make systems less vulnerable to attack.
Good Practice:
All vendor default accounts should be identified, and their purpose and use understood. It is important to establish controls for application and system accounts, including those used to deploy and maintain cloud services so that they do not use default passwords and are not usable by unauthorized individuals.
Where a default account is not intended to be used, changing the default password to a unique password that meets PCI DSS Requirement 8.3.6, removing any access to the default account, and then disabling the account, will prevent a malicious individual from re-enabling the account and gaining access with the default password.
Using an isolated staging network to install and configure new systems is recommended and can also be used to confirm that default credentials have not been introduced into production environments.
Examples:
Defaults to be considered include user IDs, passwords, and other authentication credentials commonly used by vendors in their products.
Guideline for a healthy information system v.2.0 (EN):
10 STANDARD
/STANDARD
ANSSI sets out a collection of rules and best practices in terms of the choice and size of passwords. The most critical one is to make users aware of the risks involved in choosing a password that is too easy to guess, and even the risks of reusing the same password from one application to another, especially for personal and professional mailboxes.
To supervise and confirm that these choice and size rules are being applied, the organization may use different measures, including:
ANSSI sets out a collection of rules and best practices in terms of the choice and size of passwords. The most critical one is to make users aware of the risks involved in choosing a password that is too easy to guess, and even the risks of reusing the same password from one application to another, especially for personal and professional mailboxes.
To supervise and confirm that these choice and size rules are being applied, the organization may use different measures, including:
- blocking accounts following several failed logins;
- deactivating anonymous login options;
- using a password robustness checking tool.
In advance of such procedures, communication aiming to explain the reason for these rules and raise awareness of their importance is fundamental.
12 STANDARD
/STANDARD
It is essential to consider that the default settings of the information systems are known by the hackers, even if these are not known to the general public. These settings are (too) often trivial (password the same as the username, not long enough or common to all the devices and services for example) and are often easy to obtain by hackers capable of pretending to be a legitimate user.
The default authentication settings of the components of the system must therefore be changed when they are set up and, in terms of passwords, be in accordance with the previous recommendations in terms of choice, size and storage.
If changing a default password is impossible due, for example, to a password or certificate being "hardcoded" onto a device, this critical problem must be raised with the product supplier so that it can correct this vulnerability as fast as possible.
It is essential to consider that the default settings of the information systems are known by the hackers, even if these are not known to the general public. These settings are (too) often trivial (password the same as the username, not long enough or common to all the devices and services for example) and are often easy to obtain by hackers capable of pretending to be a legitimate user.
The default authentication settings of the components of the system must therefore be changed when they are set up and, in terms of passwords, be in accordance with the previous recommendations in terms of choice, size and storage.
If changing a default password is impossible due, for example, to a password or certificate being "hardcoded" onto a device, this critical problem must be raised with the product supplier so that it can correct this vulnerability as fast as possible.
ГОСТ Р № ИСО/МЭК 27001-2021 от 01.01.2022 "Информационная технология. Методы и средства обеспечения безопасности. Системы менеджмента информационной безопасности. Требования - Приложение А":
A.9.4.3
A.9.4.3 Система управления паролями
Мера обеспечения информационной безопасности: Системы управления паролями должны быть интерактивными и должны обеспечивать уверенность в качестве паролей
Мера обеспечения информационной безопасности: Системы управления паролями должны быть интерактивными и должны обеспечивать уверенность в качестве паролей
CIS Critical Security Controls v7.1 (SANS Top 20):
CSC 4.4
CSC 4.4 Use Unique Passwords
Where multi-factor authentication is not supported (such as local administrator, root, or service accounts), accounts will use passwords that are unique to that system.
Where multi-factor authentication is not supported (such as local administrator, root, or service accounts), accounts will use passwords that are unique to that system.
Framework № PCI DSS 4.0 от 01.03.2022 "Payment Card Industry Data Security Standard (RU)":
Requirement 2.2.2
2.2.2
Определенные Требования к Подходу:
Учетные записи поставщика по умолчанию управляются следующим образом:
Определенные Требования к Подходу:
Учетные записи поставщика по умолчанию управляются следующим образом:
- Если будут использоваться учетные записи поставщика по умолчанию, пароль по умолчанию изменяется в соответствии с требованием 8.3.6.
- Если учетная запись (учетные записи) поставщика по умолчанию не будут использоваться, учетная запись будет удалена или отключена.
Цель Индивидуального подхода:
Доступ к системным компонентам с использованием паролей по умолчанию невозможен.
Примечания по применению:
Это относится ко ВСЕМ учетным записям и паролям поставщика по умолчанию, включая те, которые используются операционными системами, программным обеспечением, предоставляющим службы безопасности, учетными записями приложений и систем, терминалами точек продаж (POS), платежными приложениями и протоколами простого сетевого управления (SNMP) по умолчанию.
Это требование также применяется, если системный компонент не установлен в среде организации, например, программное обеспечение и приложения, которые являются частью CDE и доступны через облачную службу подписки.
Определенные Процедуры Тестирования Подхода:
Доступ к системным компонентам с использованием паролей по умолчанию невозможен.
Примечания по применению:
Это относится ко ВСЕМ учетным записям и паролям поставщика по умолчанию, включая те, которые используются операционными системами, программным обеспечением, предоставляющим службы безопасности, учетными записями приложений и систем, терминалами точек продаж (POS), платежными приложениями и протоколами простого сетевого управления (SNMP) по умолчанию.
Это требование также применяется, если системный компонент не установлен в среде организации, например, программное обеспечение и приложения, которые являются частью CDE и доступны через облачную службу подписки.
Определенные Процедуры Тестирования Подхода:
- 2.2.2.a Изучите стандарты конфигурации системы, чтобы убедиться, что они включают управление учетными записями поставщика по умолчанию в соответствии со всеми элементами, указанными в этом требовании.
- 2.2.2.b Изучите документацию поставщика и понаблюдайте, как системный администратор входит в систему, используя учетные записи поставщика по умолчанию, чтобы убедиться, что учетные записи реализованы в соответствии со всеми элементами, указанными в этом требовании.
- 2.2.2.c Изучите файлы конфигурации и опросите персонал, чтобы убедиться, что все учетные записи поставщика по умолчанию, которые не будут использоваться, удалены или отключены.
Цель:
Злоумышленники часто используют имена учетных записей и пароли поставщиков по умолчанию для компрометации операционных систем, приложений и систем, на которых они установлены.
Поскольку эти настройки по умолчанию часто публикуются и хорошо известны, изменение этих настроек сделает системы менее уязвимыми для атак.
Надлежащая практика:
Все учетные записи поставщика по умолчанию должны быть идентифицированы, а их назначение и использование должны быть поняты. Важно установить контроль для учетных записей приложений и систем, в том числе тех, которые используются для развертывания и обслуживания облачных служб, чтобы они не использовали пароли по умолчанию и не могли использоваться неавторизованными лицами.
Если учетная запись по умолчанию не предназначена для использования, изменение пароля по умолчанию на уникальный пароль, соответствующий требованию PCI DSS 8.3.6, удаление любого доступа к учетной записи по умолчанию, а затем отключение учетной записи предотвратит повторное включение учетной записи злоумышленником и получение доступа с помощью пароля по умолчанию.
Рекомендуется использовать изолированную промежуточную сеть для установки и настройки новых систем, а также может использоваться для подтверждения того, что учетные данные по умолчанию не были введены в производственные среды.
Примеры:
Значения по умолчанию, которые следует учитывать, включают идентификаторы пользователей, пароли и другие учетные данные для аутентификации, обычно используемые поставщиками в своих продуктах.
Злоумышленники часто используют имена учетных записей и пароли поставщиков по умолчанию для компрометации операционных систем, приложений и систем, на которых они установлены.
Поскольку эти настройки по умолчанию часто публикуются и хорошо известны, изменение этих настроек сделает системы менее уязвимыми для атак.
Надлежащая практика:
Все учетные записи поставщика по умолчанию должны быть идентифицированы, а их назначение и использование должны быть поняты. Важно установить контроль для учетных записей приложений и систем, в том числе тех, которые используются для развертывания и обслуживания облачных служб, чтобы они не использовали пароли по умолчанию и не могли использоваться неавторизованными лицами.
Если учетная запись по умолчанию не предназначена для использования, изменение пароля по умолчанию на уникальный пароль, соответствующий требованию PCI DSS 8.3.6, удаление любого доступа к учетной записи по умолчанию, а затем отключение учетной записи предотвратит повторное включение учетной записи злоумышленником и получение доступа с помощью пароля по умолчанию.
Рекомендуется использовать изолированную промежуточную сеть для установки и настройки новых систем, а также может использоваться для подтверждения того, что учетные данные по умолчанию не были введены в производственные среды.
Примеры:
Значения по умолчанию, которые следует учитывать, включают идентификаторы пользователей, пароли и другие учетные данные для аутентификации, обычно используемые поставщиками в своих продуктах.
Requirement 2.3.1
2.3.1
Определенные Требования к Подходу:
Для беспроводных сред, подключенных к CDE или передающих данные учетной записи, все настройки поставщика беспроводной связи по умолчанию изменяются при установке или подтверждаются как безопасные:
Определенные Требования к Подходу:
Для беспроводных сред, подключенных к CDE или передающих данные учетной записи, все настройки поставщика беспроводной связи по умолчанию изменяются при установке или подтверждаются как безопасные:
- Ключи шифрования беспроводной сети по умолчанию.
- Пароли на беспроводных точках доступа.
- Настройки SNMP по умолчанию.
- Любые другие настройки по умолчанию поставщика беспроводной связи, связанные с безопасностью.
Цель Индивидуального подхода:
Доступ к беспроводным сетям невозможен с использованием паролей поставщика по умолчанию или конфигураций по умолчанию.
Примечания по применению:
Ключи шифрования беспроводной сети по умолчанию, пароли на беспроводных точках доступа, значения по умолчанию SNMP и любые другие значения по умолчанию, связанные с безопасностью поставщика беспроводной связи.
Определенные Процедуры Тестирования Подхода:
Доступ к беспроводным сетям невозможен с использованием паролей поставщика по умолчанию или конфигураций по умолчанию.
Примечания по применению:
Ключи шифрования беспроводной сети по умолчанию, пароли на беспроводных точках доступа, значения по умолчанию SNMP и любые другие значения по умолчанию, связанные с безопасностью поставщика беспроводной связи.
Определенные Процедуры Тестирования Подхода:
- 2.3.1.a Изучите политики и процедуры и опросите ответственный персонал, чтобы убедиться, что процессы определены для настроек поставщика беспроводной связи по умолчанию, чтобы либо изменить их при установке, либо подтвердить их безопасность в соответствии со всеми элементами этого требования.
- 2.3.1.b Изучите документацию поставщика и понаблюдайте, как системный администратор входит в беспроводные устройства для проверки:
- Значения по умолчанию SNMP не используются.
- Пароли/парольные фразы по умолчанию на беспроводных точках доступа не используются.
- 2.3.1.c Изучите документацию поставщика и параметры конфигурации беспроводной сети, чтобы убедиться, что другие связанные с безопасностью настройки беспроводной сети по умолчанию были изменены, если это применимо.
Цель:
Если беспроводные сети не реализованы с достаточными конфигурациями безопасности (включая изменение настроек по умолчанию), беспроводные анализаторы могут прослушивать трафик, легко захватывать данные и пароли, а также легко входить в сеть и атаковать ее.
Надлежащая практика:
Беспроводные пароли должны быть сконструированы таким образом, чтобы они были устойчивы к атакам методом перебора в автономном режиме.
Если беспроводные сети не реализованы с достаточными конфигурациями безопасности (включая изменение настроек по умолчанию), беспроводные анализаторы могут прослушивать трафик, легко захватывать данные и пароли, а также легко входить в сеть и атаковать ее.
Надлежащая практика:
Беспроводные пароли должны быть сконструированы таким образом, чтобы они были устойчивы к атакам методом перебора в автономном режиме.
Requirement 8.3.5
8.3.5
Определенные Требования к Подходу:
Если пароли/парольные фразы используются в качестве факторов аутентификации в соответствии с требованием 8.3.1, они устанавливаются и сбрасываются для каждого пользователя следующим образом:
Определенные Требования к Подходу:
Если пароли/парольные фразы используются в качестве факторов аутентификации в соответствии с требованием 8.3.1, они устанавливаются и сбрасываются для каждого пользователя следующим образом:
- Устанавливается на уникальное значение при первом использовании и при сбросе.
- Принудительно заменяется сразу после первого использования.
Цель Индивидуального подхода:
Первоначальный или сброшенный пароль/кодовая фраза, назначенные пользователю, не могут быть использованы неавторизованным пользователем.
Определенные Процедуры Тестирования Подхода:
Первоначальный или сброшенный пароль/кодовая фраза, назначенные пользователю, не могут быть использованы неавторизованным пользователем.
Определенные Процедуры Тестирования Подхода:
- 8.3.5 Изучите процедуры установки и сброса паролей/парольных фраз (если они используются в качестве факторов аутентификации в соответствии с требованием 8.3.1) и понаблюдайте за персоналом службы безопасности, чтобы убедиться, что пароли/парольные фразы установлены и сброшены в соответствии со всеми элементами, указанными в этом требовании.
Цель:
Если один и тот же пароль / кодовая фраза используется для каждого нового пользователя, внутренний пользователь, бывший сотрудник или злоумышленник могут знать или легко обнаружить значение и использовать его для получения доступа к учетным записям до того, как авторизованный пользователь попытается использовать пароль.
Если один и тот же пароль / кодовая фраза используется для каждого нового пользователя, внутренний пользователь, бывший сотрудник или злоумышленник могут знать или легко обнаружить значение и использовать его для получения доступа к учетным записям до того, как авторизованный пользователь попытается использовать пароль.
Requirement 8.3.6
8.3.6
Определенные Требования к Подходу:
Если пароли/парольные фразы используются в качестве факторов аутентификации для удовлетворения требования 8.3.1, они соответствуют следующему минимальному уровню сложности:
Определенные Требования к Подходу:
Если пароли/парольные фразы используются в качестве факторов аутентификации для удовлетворения требования 8.3.1, они соответствуют следующему минимальному уровню сложности:
- Минимальная длина 12 символов (или, если система не поддерживает 12 символов, минимальная длина восемь символов).
- Содержат как цифровые, так и буквенные символы.
Цель Индивидуального подхода:
Угаданный пароль/кодовая фраза не могут быть проверены ни с помощью онлайн-, ни с помощью оффлайн-атаки методом перебора.
Примечания по применению:
Это требование не предназначено для применения к:
Угаданный пароль/кодовая фраза не могут быть проверены ни с помощью онлайн-, ни с помощью оффлайн-атаки методом перебора.
Примечания по применению:
Это требование не предназначено для применения к:
- Учетные записи пользователей в торговых терминалах, которые имеют доступ только к одному номеру карты одновременно для облегчения одной транзакции (например, идентификаторы, используемые кассирами в торговых терминалах).
- Учетные записи приложений или системы, которые регулируются требованиями раздела 8.6.
Это требование является наилучшей практикой до 31 марта 2025 года, после чего оно станет обязательным и должно быть полностью рассмотрено во время оценки PCI DSS.
До 31 марта 2025 года пароли должны быть длиной не менее семи символов в соответствии с требованием 8.2.3 PCI DSS v3.2.1.
Определенные Процедуры Тестирования Подхода:
До 31 марта 2025 года пароли должны быть длиной не менее семи символов в соответствии с требованием 8.2.3 PCI DSS v3.2.1.
Определенные Процедуры Тестирования Подхода:
- 8.3.6 Проверьте параметры конфигурации системы, чтобы убедиться, что параметры сложности пароля пользователя/парольной фразы установлены в соответствии со всеми элементами, указанными в этом требовании.
Цель:
Надежные пароли / парольные фразы могут быть первой линией защиты в сети, поскольку злоумышленник часто сначала пытается найти учетные записи со слабыми, статическими или несуществующими паролями. Если пароли короткие или легко угадываемые, злоумышленнику относительно легко найти эти слабые учетные записи и скомпрометировать сеть под видом действительного идентификатора пользователя.
Надлежащая практика:
Надежность пароля/парольной фразы зависит от сложности, длины и случайности пароля/парольной фразы. Пароли/парольные фразы должны быть достаточно сложными, чтобы злоумышленник не мог их угадать или иным образом обнаружить их значение. Организации могут рассмотреть возможность увеличения сложности, требуя использования специальных символов и символов верхнего и нижнего регистра в дополнение к минимальным стандартам, изложенным в этом требовании. Дополнительная сложность увеличивает время, необходимое для автономных атак методом перебора хэшированных паролей/парольных фраз.
Другим вариантом повышения устойчивости паролей к атакам на угадывание является сравнение предлагаемых паролей / парольных фраз со списком неверных паролей и предоставление пользователям новых паролей для любых паролей, найденных в списке.
Надежные пароли / парольные фразы могут быть первой линией защиты в сети, поскольку злоумышленник часто сначала пытается найти учетные записи со слабыми, статическими или несуществующими паролями. Если пароли короткие или легко угадываемые, злоумышленнику относительно легко найти эти слабые учетные записи и скомпрометировать сеть под видом действительного идентификатора пользователя.
Надлежащая практика:
Надежность пароля/парольной фразы зависит от сложности, длины и случайности пароля/парольной фразы. Пароли/парольные фразы должны быть достаточно сложными, чтобы злоумышленник не мог их угадать или иным образом обнаружить их значение. Организации могут рассмотреть возможность увеличения сложности, требуя использования специальных символов и символов верхнего и нижнего регистра в дополнение к минимальным стандартам, изложенным в этом требовании. Дополнительная сложность увеличивает время, необходимое для автономных атак методом перебора хэшированных паролей/парольных фраз.
Другим вариантом повышения устойчивости паролей к атакам на угадывание является сравнение предлагаемых паролей / парольных фраз со списком неверных паролей и предоставление пользователям новых паролей для любых паролей, найденных в списке.
Приказ ФСТЭК России № 17 от 11.02.2013 "Требования о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах":
АНЗ.5
АНЗ.5 Контроль правил генерации и смены паролей пользователей, заведения и удаления учетных записей пользователей, реализации правил разграничения доступом, полномочий пользователей в информационной системе
Strategies to Mitigate Cyber Security Incidents (EN):
2.6.
Protect authentication credentials. Remove CPassword values (MS14-025). Configure WDigest (KB2871997). Use Windows Defender Credential Guard. Change default passphrases. Require long complex passphrases.
Relative Security Effectiveness: Excellent | Potential User Resistance: Medium | Upfront Cost: Medium | Ongoing Maintenance Cost: Low
Relative Security Effectiveness: Excellent | Potential User Resistance: Medium | Upfront Cost: Medium | Ongoing Maintenance Cost: Low
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
Связанные защитные меры
Ничего не найдено
Мы используем cookie-файлы, чтобы получить статистику, которая помогает нам улучшить сервис для вас с целью персонализации сервисов и предложений. Вы может прочитать подробнее о cookie-файлах или изменить настройки браузера. Продолжая пользоваться сайтом, вы даёте согласие на использование ваших cookie-файлов и соглашаетесь с Политикой обработки персональных данных.