compliance controls are associated with this Policy definition 'Satisfy token quality requirements' (056a723b-4946-9d2a-5243-3aa27c4d31a1)
| Control Domain |
Control |
Name |
MetadataId |
Category |
Title |
Owner |
Requirements |
Description |
Info |
Policy# |
| CIS_Azure_1.1.0 |
1.22 |
CIS_Azure_1.1.0_1.22 |
CIS Microsoft Azure Foundations Benchmark recommendation 1.22 |
1 Identity and Access Management |
Ensure that 'Require Multi-Factor Auth to join devices' is set to 'Yes' |
Shared |
The customer is responsible for implementing this recommendation. |
Joining devices to the active directory should require Multi-factor authentication. |
link |
8 |
| CIS_Azure_1.1.0 |
1.4 |
CIS_Azure_1.1.0_1.4 |
CIS Microsoft Azure Foundations Benchmark recommendation 1.4 |
1 Identity and Access Management |
Ensure that 'Allow users to remember multi-factor authentication on devices they trust' is 'Disabled' |
Shared |
The customer is responsible for implementing this recommendation. |
Do not allow users to remember multi-factor authentication on devices. |
link |
3 |
| CIS_Azure_1.3.0 |
1.20 |
CIS_Azure_1.3.0_1.20 |
CIS Microsoft Azure Foundations Benchmark recommendation 1.20 |
1 Identity and Access Management |
Ensure that 'Require Multi-Factor Auth to join devices' is set to 'Yes' |
Shared |
The customer is responsible for implementing this recommendation. |
Joining devices to the active directory should require Multi-factor authentication. |
link |
8 |
| CIS_Azure_1.3.0 |
1.22 |
CIS_Azure_1.3.0_1.22 |
CIS Microsoft Azure Foundations Benchmark recommendation 1.22 |
1 Identity and Access Management |
Ensure Security Defaults is enabled on Azure Active Directory |
Shared |
The customer is responsible for implementing this recommendation. |
Security defaults in Azure Active Directory (Azure AD) make it easier to be secure and help protect your organization. Security defaults contain preconfigured security settings for common attacks.
Microsoft is making security defaults available to everyone. The goal is to ensure that all organizations have a basic level of security-enabled at no extra cost. You turn on security defaults in the Azure portal. |
link |
9 |
| CIS_Azure_1.3.0 |
1.4 |
CIS_Azure_1.3.0_1.4 |
CIS Microsoft Azure Foundations Benchmark recommendation 1.4 |
1 Identity and Access Management |
Ensure that 'Allow users to remember multi-factor authentication on devices they trust' is 'Disabled' |
Shared |
The customer is responsible for implementing this recommendation. |
Do not allow users to remember multi-factor authentication on devices. |
link |
3 |
| CIS_Azure_1.4.0 |
1.19 |
CIS_Azure_1.4.0_1.19 |
CIS Microsoft Azure Foundations Benchmark recommendation 1.19 |
1 Identity and Access Management |
Ensure that 'Require Multi-Factor Authentication to register or join devices with Azure AD' is set to 'Yes' |
Shared |
The customer is responsible for implementing this recommendation. |
Joining or registering devices to the active directory should require Multi-factor authentication. |
link |
8 |
| CIS_Azure_1.4.0 |
1.21 |
CIS_Azure_1.4.0_1.21 |
CIS Microsoft Azure Foundations Benchmark recommendation 1.21 |
1 Identity and Access Management |
Ensure Security Defaults is enabled on Azure Active Directory |
Shared |
The customer is responsible for implementing this recommendation. |
Security defaults in Azure Active Directory (Azure AD) make it easier to be secure and help protect your organization. Security defaults contain preconfigured security settings for common attacks.
Microsoft is making security defaults available to everyone. The goal is to ensure that all organizations have a basic level of security-enabled at no extra cost. You turn on security defaults in the Azure portal. |
link |
9 |
| CIS_Azure_1.4.0 |
1.4 |
CIS_Azure_1.4.0_1.4 |
CIS Microsoft Azure Foundations Benchmark recommendation 1.4 |
1 Identity and Access Management |
Ensure that 'Restore multi-factor authentication on all remembered devices' is Enabled |
Shared |
The customer is responsible for implementing this recommendation. |
Do not allow users to remember multi-factor authentication on devices. |
link |
3 |
| CIS_Azure_2.0.0 |
1.1.1 |
CIS_Azure_2.0.0_1.1.1 |
CIS Microsoft Azure Foundations Benchmark recommendation 1.1.1 |
1.1 |
Ensure Security Defaults is enabled on Azure Active Directory |
Shared |
This recommendation should be implemented initially and then may be overridden by other service/product specific CIS Benchmarks. Administrators should also be aware that certain configurations in Azure Active Directory may impact other Microsoft services such as Microsoft 365. |
Security defaults in Azure Active Directory (Azure AD) make it easier to be secure and help protect your organization. Security defaults contain preconfigured security settings for common attacks.
Security defaults is available to everyone. The goal is to ensure that all organizations have a basic level of security enabled at no extra cost. You may turn on security defaults in the Azure portal.
Security defaults provide secure default settings that we manage on behalf of organizations to keep customers safe until they are ready to manage their own identity security settings.
For example, doing the following:
- Requiring all users and admins to register for MFA.
- Challenging users with MFA - when necessary, based on factors such as location, device, role, and task.
- Disabling authentication from legacy authentication clients, which can’t do MFA. |
link |
9 |
| CIS_Azure_2.0.0 |
1.1.4 |
CIS_Azure_2.0.0_1.1.4 |
CIS Microsoft Azure Foundations Benchmark recommendation 1.1.4 |
1.1 |
Ensure that 'Allow users to remember multi-factor authentication on devices they trust' is Disabled |
Shared |
For every login attempt, the user will be required to perform multi-factor authentication. |
Do not allow users to remember multi-factor authentication on devices.
Remembering Multi-Factor Authentication (MFA) for devices and browsers allows users to have the option to bypass MFA for a set number of days after performing a successful sign-in using MFA. This can enhance usability by minimizing the number of times a user may need to perform two-step verification on the same device. However, if an account or device is compromised, remembering MFA for trusted devices may affect security. Hence, it is recommended that users not be allowed to bypass MFA. |
link |
3 |
| CIS_Azure_2.0.0 |
1.22 |
CIS_Azure_2.0.0_1.22 |
CIS Microsoft Azure Foundations Benchmark recommendation 1.22 |
1 |
Ensure that 'Require Multi-Factor Authentication to register or join devices with Azure AD' is set to 'Yes' |
Shared |
A slight impact of additional overhead, as Administrators will now have to approve every access to the domain. |
Joining or registering devices to the active directory should require Multi-factor authentication.
Multi-factor authentication is recommended when adding devices to Azure AD. When set to `Yes`, users who are adding devices from the internet must first use the second method of authentication before their device is successfully added to the directory. This ensures that rogue devices are not added to the domain using a compromised user account. _Note:_ Some Microsoft documentation suggests to use conditional access policies for joining a domain from certain whitelisted networks or devices. Even with these in place, using Multi-Factor Authentication is still recommended, as it creates a process for review before joining the domain. |
link |
8 |
| FedRAMP_High_R4 |
IA-5(11) |
FedRAMP_High_R4_IA-5(11) |
FedRAMP High IA-5 (11) |
Identification And Authentication |
Hardware Token-Based Authentication |
Shared |
n/a |
The information system, for hardware token-based authentication, employs mechanisms that satisfy [Assignment: organization-defined token quality requirements].
Supplemental Guidance: Hardware token-based authentication typically refers to the use of PKI-based tokens, such as the U.S. Government Personal Identity Verification (PIV) card. Organizations define specific requirements for tokens, such as working with a particular PKI. |
link |
1 |
| FedRAMP_Moderate_R4 |
IA-5(11) |
FedRAMP_Moderate_R4_IA-5(11) |
FedRAMP Moderate IA-5 (11) |
Identification And Authentication |
Hardware Token-Based Authentication |
Shared |
n/a |
The information system, for hardware token-based authentication, employs mechanisms that satisfy [Assignment: organization-defined token quality requirements].
Supplemental Guidance: Hardware token-based authentication typically refers to the use of PKI-based tokens, such as the U.S. Government Personal Identity Verification (PIV) card. Organizations define specific requirements for tokens, such as working with a particular PKI. |
link |
1 |
| hipaa |
0948.09y2Organizational.3-09.y |
hipaa-0948.09y2Organizational.3-09.y |
0948.09y2Organizational.3-09.y |
09 Transmission Protection |
0948.09y2Organizational.3-09.y 09.09 Electronic Commerce Services |
Shared |
n/a |
Where a trusted authority is used (e.g., for the purposes of issuing and maintaining digital signatures and/or digital certificates), security is integrated and embedded throughout the entire end-to-end certificate/signature management process. |
|
6 |
| hipaa |
11112.01q2Organizational.67-01.q |
hipaa-11112.01q2Organizational.67-01.q |
11112.01q2Organizational.67-01.q |
11 Access Control |
11112.01q2Organizational.67-01.q 01.05 Operating System Access Control |
Shared |
n/a |
The information system employs replay-resistant authentication mechanisms such as nonce, one-time passwords, or time stamps to secure network access for privileged accounts. |
|
3 |
| hipaa |
1112.01b2System.2-01.b |
hipaa-1112.01b2System.2-01.b |
1112.01b2System.2-01.b |
11 Access Control |
1112.01b2System.2-01.b 01.02 Authorized Access to Information Systems |
Shared |
n/a |
User identities are verified in person before a designated registration authority with authorization by a designated organizational official (e.g., a supervisor or other individual defined in an applicable security plan) prior to receiving a hardware token. |
|
7 |
| NIST_SP_800-53_R4 |
IA-5(11) |
NIST_SP_800-53_R4_IA-5(11) |
NIST SP 800-53 Rev. 4 IA-5 (11) |
Identification And Authentication |
Hardware Token-Based Authentication |
Shared |
n/a |
The information system, for hardware token-based authentication, employs mechanisms that satisfy [Assignment: organization-defined token quality requirements].
Supplemental Guidance: Hardware token-based authentication typically refers to the use of PKI-based tokens, such as the U.S. Government Personal Identity Verification (PIV) card. Organizations define specific requirements for tokens, such as working with a particular PKI. |
link |
1 |
| PCI_DSS_v4.0 |
8.2.3 |
PCI_DSS_v4.0_8.2.3 |
PCI DSS v4.0 8.2.3 |
Requirement 08: Identify Users and Authenticate Access to System Components |
User identification and related accounts for users and administrators are strictly managed throughout an account’s lifecycle |
Shared |
n/a |
Service providers with remote access to customer premises use unique authentication factors for each customer premises. |
link |
3 |
| PCI_DSS_v4.0 |
8.3.1 |
PCI_DSS_v4.0_8.3.1 |
PCI DSS v4.0 8.3.1 |
Requirement 08: Identify Users and Authenticate Access to System Components |
Strong authentication for users and administrators is established and managed |
Shared |
n/a |
All user access to system components for users and administrators is authenticated via at least one of the following authentication factors:
• Something you know, such as a password or passphrase.
• Something you have, such as a token device or smart card.
• Something you are, such as a biometric element. |
link |
4 |
| PCI_DSS_v4.0 |
8.3.11 |
PCI_DSS_v4.0_8.3.11 |
PCI DSS v4.0 8.3.11 |
Requirement 08: Identify Users and Authenticate Access to System Components |
Strong authentication for users and administrators is established and managed |
Shared |
n/a |
Where authentication factors such as physical or logical security tokens, smart cards, or certificates are used:
• Factors are assigned to an individual user and not shared among multiple users.
• Physical and/or logical controls ensure only the intended user can use that factor to gain access. |
link |
6 |
| PCI_DSS_v4.0 |
8.4.2 |
PCI_DSS_v4.0_8.4.2 |
PCI DSS v4.0 8.4.2 |
Requirement 08: Identify Users and Authenticate Access to System Components |
Multi-factor authentication (MFA) is implemented to secure access into the CDE |
Shared |
n/a |
MFA is implemented for all access into the CDE. |
link |
8 |
| PCI_DSS_v4.0 |
8.4.3 |
PCI_DSS_v4.0_8.4.3 |
PCI DSS v4.0 8.4.3 |
Requirement 08: Identify Users and Authenticate Access to System Components |
Multi-factor authentication (MFA) is implemented to secure access into the CDE |
Shared |
n/a |
MFA is implemented for all remote network access originating from outside the entity’s network that could access or impact the CDE as follows:
• All remote access by all personnel, both users and administrators, originating from outside the entity’s network.
• All remote access by third parties and vendors. |
link |
8 |
| PCI_DSS_v4.0 |
8.5.1 |
PCI_DSS_v4.0_8.5.1 |
PCI DSS v4.0 8.5.1 |
Requirement 08: Identify Users and Authenticate Access to System Components |
Multi-factor authentication (MFA) systems are configured to prevent misuse |
Shared |
n/a |
MFA systems are implemented as follows: • The MFA system is not susceptible to replay attacks.
• MFA systems cannot be bypassed by any users, including administrative users unless specifically documented, and authorized by management on an exception basis, for a limited time period.
• At least two different types of authentication factors are used.
• Success of all authentication factors is required before access is granted. |
link |
8 |