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

NIST Cybersecurity Framework (RU)

Framework

PR.AC-1

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

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

CIS Critical Security Controls v8 (The 18 CIS CSC):
13.9 
13.9 Deploy Port-Level Access Control
Deploy port-level access control. Port-level access control utilizes 802.1x, or similar network access control protocols, such as certificates, and may incorporate user and/or device authentication. 
6.2
6.2 Establish an Access Revoking Process 
Establish and follow a process, preferably automated, for revoking access to enterprise assets, through disabling accounts immediately upon termination, rights revocation, or role change of a user. Disabling accounts, instead of deleting accounts, may be necessary to preserve audit trails. 
5.3
5.3 Disable Dormant Accounts 
Delete or disable any dormant accounts after a period of 45 days of inactivity, where supported. 
5.1
5.1 Establish and Maintain an Inventory of Accounts 
Establish and maintain an inventory of all accounts managed in the enterprise. The inventory must include both user and administrator accounts. The inventory, at a minimum, should contain the person’s name, username, start/ stop dates, and department. Validate that all active accounts are authorized, on a recurring schedule at a minimum quarterly, or more frequently 
ГОСТ Р № 22301 от 01.01.2022 "Надежность в технике. Системы менеджмента непрерывности деятельности. Требования":
Р. 4 п. 2 пп. 2
 4.2.2 Законодательные и обязательные требования 
Организация должна: 
  • а) разработать и поддерживать процесс идентификации, получения доступа и оценки применимых законодательных и обязательных требований, связанных с непрерывностью производства и поставки продукции и оказания услуг, видов деятельности и ресурсов организации; 
  • b) обеспечить учет при внедрении и функционировании в организации СМНД применимых законодательных. обязательных и других требований; 
  • с) документировать данную информацию и поддерживать ее в актуализированном состоянии. 
Приказ ФСТЭК России № 21 от 18.02.2013 "Состав и содержание мер по обеспечению безопасности персональных данных, необходимых для обеспечения каждого из уровней защищенности персональных данных":
ИАФ.6 ИАФ.6 Идентификация и аутентификация пользователей, не являющихся работниками оператора (внешних пользователей)
ИАФ.1 ИАФ.1 Идентификация и аутентификация пользователей, являющихся работниками оператора
ИАФ.3
ИАФ.3 Управление идентификаторами, в том числе создание, присвоение, уничтожение идентификаторов
ИАФ.4 ИАФ.4 Управление средствами аутентификации, в том числе хранение, выдача, инициализация, блокирование средств аутентификации и принятие мер в случае утраты и (или) компрометации средств аутентификации
ИАФ.2 ИАФ.2 Идентификация и аутентификация устройств, в том числе стационарных, мобильных и портативных
УПД.1 УПД.1 Управление (заведение, активация, блокирование и уничтожение) учетными записями пользователей, в том числе внешних пользователей
ГОСТ Р № 57580.4-2022 от 01.02.2023 "Безопасность финансовых (банковских) операций. Обеспечение операционной надежности. Базовый состав организационных и технических мер. Раздел 7":
РВН.4.1
РВН.4.1 Применение соответствующих мер в рамках процесса управления учетными записями и правами субъектов логического доступа, требования к которому определены в ГОСТ Р 57580.1.
Russian Unified Cyber Security Framework (на основе The 18 CIS CSC):
6.2
6.2 Реализован процесс отзыва прав доступа
Блокирование учетных записей используется вместо удаления, чтобы сохранить журналы аудита.
13.9 
13.9 Реализован контроль доступа на уровне сетевых портов
На уровне портов для подключения используется протокол 802.1x или проверка сертификатов.
5.3
5.3 Отключены неактивные учетные записи
Учетная запись закрывается, если прошло 45 дней с момента последней активности.
5.1
5.1 Создан и поддерживается реестр учетных записей
Реестр включает учетные данные рядовых пользователей и администраторов.
Реестр содержит имя, фамилию, подразделение, дату создания/закрытия учетной записи.
Проверка авторизованных учетных записей осуществляется каждый квартал или чаще.
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: 
  • 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.6.1
8.6.1
Defined Approach Requirements: 
If accounts used by systems or applications can be used for interactive login, they are managed as follows: 
  • Interactive use is prevented unless needed for an exceptional circumstance.
  • Interactive use is limited to the time needed for the exceptional circumstance. 
  • Business justification for interactive use is documented.
  • Interactive use is explicitly approved by management. 
  • Individual user identity is confirmed before access to account is granted.
  • Every action taken is attributable to an individual user. 
Customized Approach Objective:
When used interactively, all actions with accounts designated as system or application accounts are authorized and attributable to an individual person. 

Applicability Notes:
This requirement is a best practice until 31 March 2025, after which it will be required and must be fully considered during a PCI DSS assessment. 

Defined Approach Testing Procedures:
  • 8.6.1 Examine application and system accounts that can be used interactively and interview administrative personnel to verify that application and system accounts are managed in accordance with all elements specified in this requirement. 
Purpose:
Like individual user accounts, system and application accounts require accountability and strict management to ensure they are used only for the intended purpose and are not misused. 
Attackers often compromise system or application accounts to gain access to cardholder data. 

Good Practice:
Where possible, configure system and application accounts to disallow interactive login to prevent unauthorized individuals from logging in and using the account with its associated system privileges, and to limit the machines and devices on which the account can be used. 

Definitions:
System or application accounts are those accounts that execute processes or perform tasks on a computer system or application and are not typically accounts that an individual logs into. These accounts usually have elevated privileges that are required to perform specialized tasks or functions. 
Interactive login is the ability for a person to log into a system or application account in the same manner as a normal user account. Using system and application accounts this way means there is no accountability and traceability of actions taken by the user. 
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:
  • 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. 
Requirement 8.2.6
8.2.6
Defined Approach Requirements: 
Inactive user accounts are removed or disabled within 90 days of inactivity. 

Customized Approach Objective:
Inactive user accounts cannot be used 

Defined Approach Testing Procedures:
  • 8.2.6 Examine user accounts and last logon information, and interview personnel to verify that any inactive user accounts are removed or disabled within 90 days of inactivity. 
Purpose:
Accounts that are not used regularly are often targets of attack since it is less likely that any changes, such as a changed password, will be noticed. As such, these accounts may be more easily exploited and used to access cardholder data. 

Good Practice:
Where it may be reasonably anticipated that an account will not be used for an extended period of time, such as an extended leave of absence, the account should be disabled as soon as the leave begins, rather than waiting 90 days. 
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):
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. 
ГОСТ Р № ИСО/МЭК 27001-2021 от 01.01.2022 "Информационная технология. Методы и средства обеспечения безопасности. Системы менеджмента информационной безопасности. Требования - Приложение А":
A.9.2.4
A.9.2.4 Процесс управления секретной аутентификационной информацией пользователей 
Мера обеспечения информационной безопасности: Предоставление секретной аутентификационной информации должно контролироваться посредством формального процесса управления. 
A.9.2.6
A.9.2.6 Аннулирование или корректировка прав доступа 
Мера обеспечения информационной безопасности: Права доступа всех работников и внешних пользователей к информации и средствам ее обработки должны быть аннулированы (после их увольнения, истечения срока действия договора или соглашения) либо скорректированы в случае необходимости 
A.9.4.2
A.9.4.2 Безопасные процедуры входа в систему 
Мера обеспечения информационной безопасности: Когда этого требует политика управления доступом, доступ к системам и приложениям должен управляться посредством безопасной процедуры входа в систему 
A.9.2.1
A.9.2.1 Регистрация и отмена регистрации пользователей 
Мера обеспечения информационной безопасности: Для назначения прав доступа должна быть реализована формализованная процедура регистрации и отмены регистрации пользователей 
A.9.4.3
A.9.4.3 Система управления паролями 
Мера обеспечения информационной безопасности: Системы управления паролями должны быть интерактивными и должны обеспечивать уверенность в качестве паролей 
A.9.2.2
A.9.2.2 Предоставление пользователю права доступа 
Мера обеспечения информационной безопасности: Должен быть реализован формализованный процесс назначения или отмены прав доступа пользователей к системам и сервисам 
A.9.2.3
A.9.2.3 Управление привилегированными правами доступа 
Мера обеспечения информационной безопасности: Распределение и использование привилегированных прав доступа следует ограничивать и контролировать 
A.9.3.1
A.9.3.1 Использование секретной аутентификационной информации 
Мера обеспечения информационной безопасности: При использовании секретной аутентификационной информации пользователи должны выполнять установленные в организации правила 
CIS Critical Security Controls v7.1 (SANS Top 20):
CSC 16.8 CSC 16.8 Disable Any Unassociated Accounts
Disable any account that cannot be associated with a business process or business owner.
CSC 4.1 CSC 4.1 Maintain Inventory of Administrative Accounts
Use automated tools to inventory all administrative accounts, including domain and local accounts, to ensure that only authorized individuals have elevated privileges.
CSC 16.9 CSC 16.9 Disable Dormant Accounts
Automatically disable dormant accounts after a set period of inactivity.
CSC 16.10 CSC 16.10 Ensure All Accounts Have An Expiration Date
Ensure that all accounts have an expiration date that is monitored and enforced.
CSC 16.7 CSC 16.7 Establish Process for Revoking Access
Establish and follow an automated process for revoking system access by disabling accounts immediately upon termination or change of responsibilities of an employee or contractor . Disabling these accounts, instead of deleting accounts, allows preservation of audit trails.
CSC 1.7 CSC 1.7 Deploy Port Level Access Control
Utilize port level access control, following 802.1x standards, to control which devices can authenticate to the network. The authentication system shall be tied into the hardware asset inventory data to ensure only authorized devices can connect to the network.
CSC 20.8 CSC 20.8 Control and Monitor Accounts Associated with Penetration Testing
Any user or system accounts used to perform penetration testing should be controlled and monitored to make sure they are only being used for legitimate purposes, and are removed or restored to normal function after testing is over.
CSC 16.6 CSC 16.6 Maintain an Inventory of Accounts
Maintain an inventory of all accounts organized by authentication 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 и доступны через облачную службу подписки.

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

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

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

Примечания по применению:
Это требование является наилучшей практикой до 31 марта 2025 года, после чего оно станет обязательным и должно быть полностью рассмотрено во время оценки PCI DSS.

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

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

Определения:
Системные или прикладные учетные записи - это учетные записи, которые выполняют процессы или задачи в компьютерной системе или приложении и обычно не являются учетными записями, в которые пользователь входит. Эти учетные записи обычно имеют повышенные привилегии, необходимые для выполнения специализированных задач или функций.
Интерактивный вход в систему - это возможность для пользователя войти в учетную запись системы или приложения таким же образом, как и обычная учетная запись пользователя. Использование учетных записей системы и приложений таким образом означает отсутствие подотчетности и отслеживания действий, предпринятых пользователем.
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.2.6
8.2.6
Определенные Требования к Подходу:
Неактивные учетные записи пользователей удаляются или отключаются в течение 90 дней бездействия.

Цель Индивидуального подхода:
Неактивные учетные записи пользователей не могут быть использованы

Определенные Процедуры Тестирования Подхода:
  • 8.2.6 Проверьте учетные записи пользователей и информацию о последнем входе в систему, а также опросите персонал, чтобы убедиться, что все неактивные учетные записи пользователей удалены или отключены в течение 90 дней бездействия.
Цель:
Учетные записи, которые не используются регулярно, часто становятся объектами атак, поскольку менее вероятно, что какие-либо изменения, такие как изменение пароля, будут замечены. Таким образом, эти учетные записи могут быть более легко использованы для доступа к данным о держателях карт.

Надлежащая практика:
Если можно обоснованно предположить, что учетная запись не будет использоваться в течение длительного периода времени, например, в течение длительного отпуска, учетная запись должна быть отключена сразу после начала отпуска, а не ждать 90 дней.
Requirement 8.2.5
8.2.5
Определенные Требования к Подходу:
Доступ для прекращенных пользователей немедленно аннулируется.

Цель Индивидуального подхода:
Учетные записи прекращенных пользователей не могут быть использованы.

Определенные Процедуры Тестирования Подхода:
  • 8.2.5.a Изучите источники информации о завершенных пользователях и просмотрите текущие списки доступа пользователей — как для локального, так и для удаленного доступа — чтобы убедиться, что идентификаторы завершенных пользователей были деактивированы или удалены из списков доступа.
  • 8.2.5.b Опросите ответственный персонал, чтобы убедиться, что все физические факторы аутентификации — такие как смарт—карты, токены и т.д. - были возвращены или деактивированы для прекращенных пользователей.
Цель:
Если сотрудник или третья сторона/ поставщик покинули компанию и по—прежнему имеют доступ к сети через свою учетную запись пользователя, может возникнуть ненужный или злонамеренный доступ к данным о держателях карт - либо со стороны бывшего сотрудника, либо со стороны злоумышленника, который использует старую и/или неиспользуемую учетную запись.
Приказ ФСТЭК России № 17 от 11.02.2013 "Требования о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах":
ИАФ.1 ИАФ.1 Идентификация и аутентификация пользователей, являющихся работниками оператора
ИАФ.3 ИАФ.3 Управление идентификаторами, в том числе создание, присвоение, уничтожение идентификаторов
ИАФ.6 ИАФ.6 Идентификация и аутентификация пользователей, не являющихся работниками оператора (внешних пользователей)
ИАФ.2 ИАФ.2 Идентификация и аутентификация устройств, в том числе стационарных, мобильных и портативных
ИАФ.4 ИАФ.4 Управление средствами аутентификации, в том числе хранение, выдача, инициализация, блокирование средств аутентификации и принятие мер в случае утраты и (или) компрометации средств аутентификации
УПД.1 УПД.1 Управление (заведение, активация, блокирование и уничтожение) учетными записями пользователей, в том числе внешних пользователей
Strategies to Mitigate Cyber Security Incidents (EN):
2.4.
Disable local administrator accounts or assign passphrases that are random and unique for each computer’s local administrator account to prevent propagation using shared local administrator credentials.
Relative Security Effectiveness:  Excellent | Potential User Resistance:  Low | Upfront Cost:  Medium | Ongoing Maintenance Cost:  Low
Стандарт № ИСО/МЭК 27001:2022(E) от 25.10.2022 "Информационная безопасность, кибербезопасность и защита частной жизни — Системы управления информационной безопасностью — Требования. Приложение А":
А.5.18
А.5.18 Права доступа
Права доступа к информационным и иным связанным с ней активам должны предоставляться, пересматриваться, изменяться и удаляться в соответствии с специфической тематической политикой и правилами управления доступом организации.
А.8.2
А.8.2 Привилегированные права доступа
Должны ограничиваться и управляться назначение и использование привилегированных прав доступа.
А.5.17
А.5.17 Аутентификационная информация
Распределение и управление аутентификационной информацией должно контролироваться процессом управления, включая информирование персонала о надлежащем обращении с аутентификационной информацией.
А.8.5
А.8.5 Безопасная аутентификация
Технологии и процедуры безопасной аутентификации должны быть внедрены на основании ограничений доступа к информации и специфической тематической политики по контролю доступа.
Методика экспресс-оценки уровня кибербезопасности организации РезБез:
6.2.1.6.
Пересмотр активных учетных записей и прав доступа осуществляется на регулярной основе
SWIFT Customer Security Controls Framework v2022:
4 - 4.1 Password Policy
4.1 Password Policy
4 - 4.2 Multi-Factor Authentication
4.2 Multi-Factor Authentication
5 - 5.2 Token Management
5.2 Token Management
5 - 5.4 Physical and Logical Password Storage
5.4 Physical and Logical Password Storage
Приказ ФСТЭК России № 31 от 14.03.2014 "Состав мер защиты информации и их базовые наборы для соответствующего класса защищенности автоматизированной системы управления":
ИАФ.2 ИАФ.2 Идентификация и аутентификация устройств
ИАФ.5 ИАФ.5 Идентификация и аутентификация внешних пользователей
ИАФ.3 ИАФ.3 Управление идентификаторами
ИАФ.4 ИАФ.4 Управление средствами аутентификации
ИАФ.1 ИАФ.1 Идентификация и аутентификация пользователей и инициируемых ими процессов
УПД.1 УПД.1 Управление учетными записями пользователей
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
Приказ ФСТЭК России № 239 от 25.12.2017 "Состав мер по обеспечению безопасности для значимого объекта соответствующей категории значимости":
ИАФ.1 ИАФ.1 Идентификация и аутентификация пользователей и инициируемых ими процессов
ИАФ.3 ИАФ.3 Управление идентификаторами
ИАФ.5 ИАФ.5 Идентификация и аутентификация внешних пользователей
ИАФ.4 ИАФ.4 Управление средствами аутентификации
УПД.1 УПД.1 Управление учетными записями пользователей
Стандарт № ISO/IEC 27001:2022(E) от 25.10.2022 "Information security, cybersecurity and privacy protection — Information security management systems — Requirements. Annex A":
А.5.17
А.5.17 Authentication information
Allocation and management of authentication information shall be controlled by a management process, including advising personnel of appropriate handling of authentication information.
А.8.2
А.8.2 Privileged access rights
The allocation and use of privileged access rights shall be restricted and managed.
А.5.18
А.5.18 Access rights
Access rights to information and other associated assets shall be provisioned, reviewed, modified and removed in accordance with the organization’s topic-specific policy on and rules for access control.
А.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.

Связанные защитные меры

Ничего не найдено