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

Приказ ФСТЭК России № 21 от 18.02.2013

Состав и содержание мер по обеспечению безопасности персональных данных, необходимых для обеспечения каждого из уровней защищенности персональных данных

АНЗ.5

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

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

ГОСТ Р № 57580.1-2017 от 01.01.2018 "Безопасность финансовых (банковских) операций. Защита информации финансовых организаций. Базовый состав организационных и технических мер. Раздел 7. Требования к системе защиты информации":
РД.19
РД.19 Смена паролей пользователей не реже одного раза в год
3-Т 2-Т 1-Т
РД.20
РД.20 Смена паролей эксплуатационного персонала не реже одного раза в квартал
3-Т 2-Т 1-Т
УЗП.2
УЗП.2 Контроль соответствия фактического состава разблокированных учетных записей фактическому составу легальных субъектов логического доступа
3-О 2-О 1-Т
УЗП.З
УЗП.З Контроль отсутствия незаблокированных учетных записей:
  •  уволенных работников;
  •  работников, отсутствующих на рабочем месте более 90 календарных дней;
  •  работников внешних (подрядных) организаций, прекративших свою деятельность в организации
3-О 2-О 1-Т
РД.21
РД.21 Использование пользователями паролей длиной не менее восьми символов
3-Т 2-Т 1-Т
УЗП.8
УЗП.8 Хранение эталонной информации о предоставленных правах логического доступа и обеспечение целостности указанной информации
3-О 2-Т 1-Т
УЗП.9
УЗП.9 Контроль соответствия фактических прав логического доступа эталонной информации о предоставленных правах логического доступа
3-О 2-Т 1-Т
РД.24
РД.24 Запрет использования в качестве паролей субъектов логического доступа легко вычисляемых сочетаний букв и цифр (например, имена, фамилии, наименования, общепринятые сокращения)
3-Н 2-О 1-О
РД.23
РД.23 Использование при формировании паролей субъектов логического доступа символов, включающих буквы (в верхнем и нижнем регистрах) и цифры
3-Т 2-Т 1-Т
РД.22
РД.22 Использование эксплуатационным персоналом паролей длиной не менее шестнадцати символов
3-Т 2-Т 1-Т
РД.9
РД.9 Запрет использования учетных записей субъектов логического доступа с незаданными аутентификационными данными или заданными по умолчанию разработчиком ресурса доступа, в том числе разработчиком АС
3-О 2-О 1-О
УЗП.4
УЗП.4 Контроль отсутствия незаблокированных учетных записей неопределенного целевого назначения
3-О 2-О 1-О
УЗП.10
УЗП.10 Исключение возможного бесконтрольного самостоятельного расширения пользователями предоставленных им прав логического доступа
3-Т 2-Т 1-Т
Framework № PCI DSS 4.0 от 01.03.2022 "Payment Card Industry Data Security Standard":
Requirement 8.3.10
8.3.10
Defined Approach Requirements: 
Additional requirement for service providers only: If passwords/passphrases are used as the only authentication factor for customer user access to cardholder data (i.e., in any singlefactor authentication implementation), then guidance is provided to customer users including: 
  • Guidance for customers to change their user passwords/passphrases periodically.
  • Guidance as to when, and under what circumstances, passwords/passphrases are to be changed. 
Customized Approach Objective:
Passwords/passphrases for service providers’ customers cannot be used indefinitely. 

Applicability Notes:
This requirement applies only when the entity being assessed is a service provider. 
This requirement does not apply to accounts of consumer users accessing their own payment card information. 
This requirement for service providers will be superseded by Requirement 8.3.10.1 once 8.3.10.1 becomes effective. 

Defined Approach Testing Procedures:
  • 8.3.10 Additional testing procedure for service provider assessments only: If passwords/passphrases are used as the only authentication factor for customer user access to cardholder data, examine guidance provided to customer users to verify that the guidance includes all elements specified in this requirement. 
Purpose:
Using a password/passphrase as the only authentication factor provides a single point of failure if compromised. Therefore, in these implementations, controls are needed to minimize how long malicious activity could occur via a compromised password/passphrase. 

Good Practice:
Passwords/passphrases that are valid for a long time without a change provide malicious individuals with more time to break the password/phrase. Periodically changing passwords offers less time for a malicious individual to crack a password/passphrase and less time to use a compromised password. 
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: 
  • 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:
  • 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. 
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:
  • 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:
  • 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. 
Requirement 8.3.9
8.3.9
Defined Approach Requirements: 
If passwords/passphrases are used as the only authentication factor for user access (i.e., in any single-factor authentication implementation) then either:
  • Passwords/passphrases are changed at least once every 90 days, 
OR
  • The security posture of accounts is dynamically analyzed, and real-time access to resources is automatically determined accordingly. 
Customized Approach Objective:
An undetected compromised password/passphrase cannot be used indefinitely. 

Applicability Notes:
This requirement applies to in-scope system components that are not in the CDE because these components are not subject to MFA requirements. 
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 apply to service providers’ customer accounts but does apply to accounts for service provider personnel. 

Defined Approach Testing Procedures:
  • 8.3.9 If passwords/passphrases are used as the only authentication factor for user access, inspect system configuration settings to verify that passwords/passphrases are managed in accordance with ONE of the elements specified in this requirement. 
Purpose:
Access to in-scope system components that are not in the CDE may be provided using a single authentication factor, such as a password/passphrase, token device or smart card, or biometric attribute. Where passwords/passphrases are employed as the only authentication factor for such access, additional controls are required to protect the integrity of the password/passphrase. 

Good Practice:
Passwords/passphrases that are valid for a long time without a change provide malicious individuals with more time to break the password/phrase. Periodically changing passwords offers less time for a malicious individual to crack a password/passphrase and less time to use a compromised password. 
Using a password/passphrase as the only authentication factor provides a single point of failure if compromised. Therefore, in these implementations, controls are needed to minimize how long malicious activity could occur via a compromised password/passphrase. 
Dynamically analyzing an account’s security posture is another option that allows for more rapid detection and response to address potentially compromised credentials. Such analysis takes a number of data points, which may include device integrity, location, access times, and the resources accessed to determine in real time whether an account can be granted access to a requested resource. In this way, access can be denied and accounts blocked if it is suspected that authentication credentials have been compromised. 

Further Information:
For information about using dynamic analysis to manage user access to resources, see NIST SP 800-207 Zero Trust Architecture. 
Requirement 2.2.2
2.2.2 
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. 
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: 
  • 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. 
ГОСТ Р № ИСО/МЭК 27001-2021 от 01.01.2022 "Информационная технология. Методы и средства обеспечения безопасности. Системы менеджмента информационной безопасности. Требования - Приложение А":
A.9.4.3
A.9.4.3 Система управления паролями 
Мера обеспечения информационной безопасности: Системы управления паролями должны быть интерактивными и должны обеспечивать уверенность в качестве паролей 
Framework № PCI DSS 4.0 от 01.03.2022 "Payment Card Industry Data Security Standard (RU)":
Requirement 8.3.9
8.3.9
Определенные Требования к Подходу:
Если пароли / парольные фразы используются в качестве единственного фактора аутентификации для доступа пользователя (т.е. в любой реализации однофакторной аутентификации), то либо:
  • Пароли/парольные фразы меняются не реже одного раза в 90 дней,
ИЛИ
  • Состояние безопасности учетных записей динамически анализируется, и соответственно автоматически определяется доступ к ресурсам в режиме реального времени.
Цель Индивидуального подхода:
Необнаруженный скомпрометированный пароль/парольную фразу нельзя использовать бесконечно.

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

Определенные Процедуры Тестирования Подхода:
  • 8.3.9 Если пароли/парольные фразы используются в качестве единственного фактора аутентификации для доступа пользователя, проверьте параметры конфигурации системы, чтобы убедиться, что управление паролями/парольными фразами осуществляется в соответствии с ОДНИМ из элементов, указанных в этом требовании.
Цель:
Доступ к компонентам системы, которые не входят в CDE, может быть предоставлен с использованием единственного фактора аутентификации, такого как пароль/кодовая фраза, устройство токена или смарт-карта, или биометрический атрибут. В тех случаях, когда пароли/парольные фразы используются в качестве единственного фактора аутентификации для такого доступа, требуются дополнительные средства контроля для защиты целостности пароля/парольной фразы.

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

Дополнительная информация:
Об использовании динамического анализа для управления доступом пользователей к ресурсам см. в NIST SP 800-207 Архитектура нулевого доверия.
Requirement 2.2.2
2.2.2
Определенные Требования к Подходу:
Учетные записи поставщика по умолчанию управляются следующим образом: 
  • Если будут использоваться учетные записи поставщика по умолчанию, пароль по умолчанию изменяется в соответствии с требованием 8.3.6. 
  • Если учетная запись (учетные записи) поставщика по умолчанию не будут использоваться, учетная запись будет удалена или отключена.
Цель Индивидуального подхода:
Доступ к системным компонентам с использованием паролей по умолчанию невозможен.

Примечания по применению:
Это относится ко ВСЕМ учетным записям и паролям поставщика по умолчанию, включая те, которые используются операционными системами, программным обеспечением, предоставляющим службы безопасности, учетными записями приложений и систем, терминалами точек продаж (POS), платежными приложениями и протоколами простого сетевого управления (SNMP) по умолчанию.
Это требование также применяется, если системный компонент не установлен в среде организации, например, программное обеспечение и приложения, которые являются частью CDE и доступны через облачную службу подписки.

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

Надлежащая практика:
Все учетные записи поставщика по умолчанию должны быть идентифицированы, а их назначение и использование должны быть поняты. Важно установить контроль для учетных записей приложений и систем, в том числе тех, которые используются для развертывания и обслуживания облачных служб, чтобы они не использовали пароли по умолчанию и не могли использоваться неавторизованными лицами.
Если учетная запись по умолчанию не предназначена для использования, изменение пароля по умолчанию на уникальный пароль, соответствующий требованию PCI DSS 8.3.6, удаление любого доступа к учетной записи по умолчанию, а затем отключение учетной записи предотвратит повторное включение учетной записи злоумышленником и получение доступа с помощью пароля по умолчанию.
Рекомендуется использовать изолированную промежуточную сеть для установки и настройки новых систем, а также может использоваться для подтверждения того, что учетные данные по умолчанию не были введены в производственные среды.

Примеры:
Значения по умолчанию, которые следует учитывать, включают идентификаторы пользователей, пароли и другие учетные данные для аутентификации, обычно используемые поставщиками в своих продуктах.
Requirement 2.3.1
2.3.1
Определенные Требования к Подходу:
Для беспроводных сред, подключенных к CDE или передающих данные учетной записи, все настройки поставщика беспроводной связи по умолчанию изменяются при установке или подтверждаются как безопасные: 
  • Ключи шифрования беспроводной сети по умолчанию.
  • Пароли на беспроводных точках доступа. 
  • Настройки 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.5 Изучите процедуры установки и сброса паролей/парольных фраз (если они используются в качестве факторов аутентификации в соответствии с требованием 8.3.1) и понаблюдайте за персоналом службы безопасности, чтобы убедиться, что пароли/парольные фразы установлены и сброшены в соответствии со всеми элементами, указанными в этом требовании.
Цель:
Если один и тот же пароль / кодовая фраза используется для каждого нового пользователя, внутренний пользователь, бывший сотрудник или злоумышленник могут знать или легко обнаружить значение и использовать его для получения доступа к учетным записям до того, как авторизованный пользователь попытается использовать пароль.
Requirement 8.3.10
8.3.10
Определенные Требования к Подходу:
Дополнительное требование только для поставщиков услуг: Если пароли/парольные фразы используются в качестве единственного фактора аутентификации для доступа пользователя клиента к данным держателя карты (т.е. в любой реализации однофакторной аутентификации), то пользователям клиентов предоставляются рекомендации, в том числе:
  • Рекомендации для клиентов по периодической смене своих пользовательских паролей/парольных фраз.
  • Указания относительно того, когда и при каких обстоятельствах следует менять пароли/парольные фразы.
Цель Индивидуального подхода:
Пароли/парольные фразы для клиентов поставщиков услуг не могут использоваться бесконечно.

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

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

Надлежащая практика:
Пароли/парольные фразы, которые действительны в течение длительного времени без изменений, дают злоумышленникам больше времени для взлома пароля / фразы. Периодическая смена паролей дает злоумышленнику меньше времени для взлома пароля / парольной фразы и меньше времени для использования скомпрометированного пароля.
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 
SWIFT Customer Security Controls Framework v2022:
4 - 4.1 Password Policy
4.1 Password Policy

Мы используем cookie-файлы, чтобы получить статистику, которая помогает нам улучшить сервис для вас с целью персонализации сервисов и предложений. Вы может прочитать подробнее о cookie-файлах или изменить настройки браузера. Продолжая пользоваться сайтом, вы даёте согласие на использование ваших cookie-файлов и соглашаетесь с Политикой обработки персональных данных.