compliance controls are associated with this Policy definition 'Enforce mandatory and discretionary access control policies' (b1666a13-8f67-9c47-155e-69e027ff6823)
Control Domain |
Control |
Name |
MetadataId |
Category |
Title |
Owner |
Requirements |
Description |
Info |
Policy# |
CIS_Azure_1.1.0 |
1.10 |
CIS_Azure_1.1.0_1.10 |
CIS Microsoft Azure Foundations Benchmark recommendation 1.10 |
1 Identity and Access Management |
Ensure that 'Users can add gallery apps to their Access Panel' is set to 'No' |
Shared |
The customer is responsible for implementing this recommendation. |
Require administrators to provide consent for the apps before use. |
link |
3 |
CIS_Azure_1.1.0 |
1.11 |
CIS_Azure_1.1.0_1.11 |
CIS Microsoft Azure Foundations Benchmark recommendation 1.11 |
1 Identity and Access Management |
Ensure that 'Users can register applications' is set to 'No' |
Shared |
The customer is responsible for implementing this recommendation. |
Require administrators to register third-party applications. |
link |
3 |
CIS_Azure_1.1.0 |
1.12 |
CIS_Azure_1.1.0_1.12 |
CIS Microsoft Azure Foundations Benchmark recommendation 1.12 |
1 Identity and Access Management |
Ensure that 'Guest user permissions are limited' is set to 'Yes' |
Shared |
The customer is responsible for implementing this recommendation. |
Limit guest user permissions. |
link |
8 |
CIS_Azure_1.1.0 |
1.13 |
CIS_Azure_1.1.0_1.13 |
CIS Microsoft Azure Foundations Benchmark recommendation 1.13 |
1 Identity and Access Management |
Ensure that 'Members can invite' is set to 'No' |
Shared |
The customer is responsible for implementing this recommendation. |
Restrict invitations to administrators only. |
link |
8 |
CIS_Azure_1.1.0 |
1.14 |
CIS_Azure_1.1.0_1.14 |
CIS Microsoft Azure Foundations Benchmark recommendation 1.14 |
1 Identity and Access Management |
Ensure that 'Guests can invite' is set to 'No' |
Shared |
The customer is responsible for implementing this recommendation. |
Restrict guest invitations. |
link |
8 |
CIS_Azure_1.1.0 |
1.15 |
CIS_Azure_1.1.0_1.15 |
CIS Microsoft Azure Foundations Benchmark recommendation 1.15 |
1 Identity and Access Management |
Ensure that 'Restrict access to Azure AD administration portal' is set to 'Yes' |
Shared |
The customer is responsible for implementing this recommendation. |
Restrict access to the Azure AD administration portal to administrators only. |
link |
7 |
CIS_Azure_1.1.0 |
1.16 |
CIS_Azure_1.1.0_1.16 |
CIS Microsoft Azure Foundations Benchmark recommendation 1.16 |
1 Identity and Access Management |
Ensure that 'Self-service group management enabled' is set to 'No' |
Shared |
The customer is responsible for implementing this recommendation. |
Restrict group creation to administrators only. |
link |
4 |
CIS_Azure_1.1.0 |
1.17 |
CIS_Azure_1.1.0_1.17 |
CIS Microsoft Azure Foundations Benchmark recommendation 1.17 |
1 Identity and Access Management |
Ensure that 'Users can create security groups' is set to 'No' |
Shared |
The customer is responsible for implementing this recommendation. |
Restrict security group creation to administrators only. |
link |
4 |
CIS_Azure_1.1.0 |
1.18 |
CIS_Azure_1.1.0_1.18 |
CIS Microsoft Azure Foundations Benchmark recommendation 1.18 |
1 Identity and Access Management |
Ensure that 'Users who can manage security groups' is set to 'None' |
Shared |
The customer is responsible for implementing this recommendation. |
Restrict security group management to administrators only. |
link |
4 |
CIS_Azure_1.1.0 |
1.19 |
CIS_Azure_1.1.0_1.19 |
CIS Microsoft Azure Foundations Benchmark recommendation 1.19 |
1 Identity and Access Management |
Ensure that 'Users can create Office 365 groups' is set to 'No' |
Shared |
The customer is responsible for implementing this recommendation. |
Restrict Office 365 group creation to administrators only. |
link |
4 |
CIS_Azure_1.1.0 |
1.20 |
CIS_Azure_1.1.0_1.20 |
CIS Microsoft Azure Foundations Benchmark recommendation 1.20 |
1 Identity and Access Management |
Ensure that 'Users who can manage Office 365 groups' is set to 'None' |
Shared |
The customer is responsible for implementing this recommendation. |
Restrict Office 365 group management to administrators only. |
link |
4 |
CIS_Azure_1.1.0 |
1.23 |
CIS_Azure_1.1.0_1.23 |
CIS Microsoft Azure Foundations Benchmark recommendation 1.23 |
1 Identity and Access Management |
Ensure that no custom subscription owner roles are created |
Shared |
The customer is responsible for implementing this recommendation. |
Subscription ownership should not include permission to create custom owner roles. The principle of least privilege should be followed and only necessary privileges should be assigned instead of allowing full administrative access. |
link |
6 |
CIS_Azure_1.1.0 |
1.9 |
CIS_Azure_1.1.0_1.9 |
CIS Microsoft Azure Foundations Benchmark recommendation 1.9 |
1 Identity and Access Management |
Ensure that 'Users can consent to apps accessing company data on their behalf' is set to 'No' |
Shared |
The customer is responsible for implementing this recommendation. |
Require administrators to provide consent for the apps before use. |
link |
3 |
CIS_Azure_1.1.0 |
3.6 |
CIS_Azure_1.1.0_3.6 |
CIS Microsoft Azure Foundations Benchmark recommendation 3.6 |
3 Storage Accounts |
Ensure that 'Public access level' is set to Private for blob containers |
Shared |
The customer is responsible for implementing this recommendation. |
Disable anonymous access to blob containers. |
link |
7 |
CIS_Azure_1.1.0 |
8.5 |
CIS_Azure_1.1.0_8.5 |
CIS Microsoft Azure Foundations Benchmark recommendation 8.5 |
8 Other Security Considerations |
Enable role-based access control (RBAC) within Azure Kubernetes Services |
Shared |
The customer is responsible for implementing this recommendation. |
Ensure that RBAC is enabled on all Azure Kubernetes Services Instances |
link |
7 |
CIS_Azure_1.3.0 |
1.10 |
CIS_Azure_1.3.0_1.10 |
CIS Microsoft Azure Foundations Benchmark recommendation 1.10 |
1 Identity and Access Management |
Ensure that 'Users can add gallery apps to their Access Panel' is set to 'No' |
Shared |
The customer is responsible for implementing this recommendation. |
Require administrators to provide consent for the apps before use. |
link |
3 |
CIS_Azure_1.3.0 |
1.11 |
CIS_Azure_1.3.0_1.11 |
CIS Microsoft Azure Foundations Benchmark recommendation 1.11 |
1 Identity and Access Management |
Ensure that 'Users can register applications' is set to 'No' |
Shared |
The customer is responsible for implementing this recommendation. |
Require administrators to register third-party applications. |
link |
3 |
CIS_Azure_1.3.0 |
1.12 |
CIS_Azure_1.3.0_1.12 |
CIS Microsoft Azure Foundations Benchmark recommendation 1.12 |
1 Identity and Access Management |
Ensure that 'Guest user permissions are limited' is set to 'Yes' |
Shared |
The customer is responsible for implementing this recommendation. |
Limit guest user permissions. |
link |
8 |
CIS_Azure_1.3.0 |
1.13 |
CIS_Azure_1.3.0_1.13 |
CIS Microsoft Azure Foundations Benchmark recommendation 1.13 |
1 Identity and Access Management |
Ensure that 'Members can invite' is set to 'No' |
Shared |
The customer is responsible for implementing this recommendation. |
Restrict invitations to administrators only. |
link |
8 |
CIS_Azure_1.3.0 |
1.14 |
CIS_Azure_1.3.0_1.14 |
CIS Microsoft Azure Foundations Benchmark recommendation 1.14 |
1 Identity and Access Management |
Ensure that 'Guests can invite' is set to 'No' |
Shared |
The customer is responsible for implementing this recommendation. |
Restrict guest being able to invite other guests to collaborate with your organization. |
link |
8 |
CIS_Azure_1.3.0 |
1.15 |
CIS_Azure_1.3.0_1.15 |
CIS Microsoft Azure Foundations Benchmark recommendation 1.15 |
1 Identity and Access Management |
Ensure that 'Restrict access to Azure AD administration portal' is set to 'Yes' |
Shared |
The customer is responsible for implementing this recommendation. |
Restrict access to the Azure AD administration portal to administrators only. |
link |
6 |
CIS_Azure_1.3.0 |
1.16 |
CIS_Azure_1.3.0_1.16 |
CIS Microsoft Azure Foundations Benchmark recommendation 1.16 |
1 Identity and Access Management |
Ensure that 'Restrict user ability to access groups features in the Access Pane' is set to 'No' |
Shared |
The customer is responsible for implementing this recommendation. |
Restrict group creation to administrators only. |
link |
4 |
CIS_Azure_1.3.0 |
1.17 |
CIS_Azure_1.3.0_1.17 |
CIS Microsoft Azure Foundations Benchmark recommendation 1.17 |
1 Identity and Access Management |
Ensure that 'Users can create security groups in Azure Portals' is set to 'No' |
Shared |
The customer is responsible for implementing this recommendation. |
Restrict security group creation to administrators only. |
link |
4 |
CIS_Azure_1.3.0 |
1.18 |
CIS_Azure_1.3.0_1.18 |
CIS Microsoft Azure Foundations Benchmark recommendation 1.18 |
1 Identity and Access Management |
Ensure that 'Owners can manage group membership requests in the Access Panel' is set to 'No' |
Shared |
The customer is responsible for implementing this recommendation. |
Restrict security group management to administrators only. |
link |
4 |
CIS_Azure_1.3.0 |
1.19 |
CIS_Azure_1.3.0_1.19 |
CIS Microsoft Azure Foundations Benchmark recommendation 1.19 |
1 Identity and Access Management |
Ensure that 'Users can create Microsoft 365 groups in Azure Portals' is set to 'No' |
Shared |
The customer is responsible for implementing this recommendation. |
Restrict Microsoft 365 group creation to administrators only. |
link |
4 |
CIS_Azure_1.3.0 |
1.21 |
CIS_Azure_1.3.0_1.21 |
CIS Microsoft Azure Foundations Benchmark recommendation 1.21 |
1 Identity and Access Management |
Ensure that no custom subscription owner roles are created |
Shared |
The customer is responsible for implementing this recommendation. |
Subscription ownership should not include permission to create custom owner roles. The principle of least privilege should be followed and only necessary privileges should be assigned instead of allowing full administrative access. |
link |
6 |
CIS_Azure_1.3.0 |
1.23 |
CIS_Azure_1.3.0_1.23 |
CIS Microsoft Azure Foundations Benchmark recommendation 1.23 |
1 Identity and Access Management |
Ensure Custom Role is assigned for Administering Resource Locks |
Shared |
The customer is responsible for implementing this recommendation. |
Resource locking is a powerful protection mechanism that can prevent inadvertent modification/deletion of resources within Azure subscriptions/Resource Groups and is a recommended NIST configuration. |
link |
4 |
CIS_Azure_1.3.0 |
1.9 |
CIS_Azure_1.3.0_1.9 |
CIS Microsoft Azure Foundations Benchmark recommendation 1.9 |
1 Identity and Access Management |
Ensure that 'Users can consent to apps accessing company data on their behalf' is set to 'No' |
Shared |
The customer is responsible for implementing this recommendation. |
Require administrators to provide consent for the apps before use. |
link |
3 |
CIS_Azure_1.3.0 |
3.5 |
CIS_Azure_1.3.0_3.5 |
CIS Microsoft Azure Foundations Benchmark recommendation 3.5 |
3 Storage Accounts |
Ensure that 'Public access level' is set to Private for blob containers |
Shared |
The customer is responsible for implementing this recommendation. |
Disable anonymous access to blob containers and disallow blob public access on storage account. |
link |
7 |
CIS_Azure_1.3.0 |
8.5 |
CIS_Azure_1.3.0_8.5 |
CIS Microsoft Azure Foundations Benchmark recommendation 8.5 |
8 Other Security Considerations |
Enable role-based access control (RBAC) within Azure Kubernetes Services |
Shared |
The customer is responsible for implementing this recommendation. |
Ensure that RBAC is enabled on all Azure Kubernetes Services Instances |
link |
7 |
CIS_Azure_1.4.0 |
1.10 |
CIS_Azure_1.4.0_1.10 |
CIS Microsoft Azure Foundations Benchmark recommendation 1.10 |
1 Identity and Access Management |
Ensure that 'Users can add gallery apps to My Apps' is set to 'No' |
Shared |
The customer is responsible for implementing this recommendation. |
Require administrators to provide consent for the apps before use. |
link |
3 |
CIS_Azure_1.4.0 |
1.11 |
CIS_Azure_1.4.0_1.11 |
CIS Microsoft Azure Foundations Benchmark recommendation 1.11 |
1 Identity and Access Management |
Ensure that 'Users can register applications' is set to 'No' |
Shared |
The customer is responsible for implementing this recommendation. |
Require administrators to register third-party applications. |
link |
3 |
CIS_Azure_1.4.0 |
1.12 |
CIS_Azure_1.4.0_1.12 |
CIS Microsoft Azure Foundations Benchmark recommendation 1.12 |
1 Identity and Access Management |
Ensure That 'Guest users access restrictions' is set to 'Guest user access is restricted to properties and memberships of their own directory objects'' |
Shared |
The customer is responsible for implementing this recommendation. |
Limit guest user permissions. |
link |
8 |
CIS_Azure_1.4.0 |
1.13 |
CIS_Azure_1.4.0_1.13 |
CIS Microsoft Azure Foundations Benchmark recommendation 1.13 |
1 Identity and Access Management |
Ensure that 'Guest invite restrictions' is set to "Only users assigned to specific admin roles can invite guest users" |
Shared |
The customer is responsible for implementing this recommendation. |
Restrict invitations to users with specific admin roles only. |
link |
8 |
CIS_Azure_1.4.0 |
1.14 |
CIS_Azure_1.4.0_1.14 |
CIS Microsoft Azure Foundations Benchmark recommendation 1.14 |
1 Identity and Access Management |
Ensure That 'Restrict access to Azure AD administration portal' is Set to "Yes" |
Shared |
The customer is responsible for implementing this recommendation. |
Restrict access to the Azure AD administration portal to administrators only. |
link |
6 |
CIS_Azure_1.4.0 |
1.15 |
CIS_Azure_1.4.0_1.15 |
CIS Microsoft Azure Foundations Benchmark recommendation 1.15 |
1 Identity and Access Management |
Ensure that 'Restrict user ability to access groups features in the Access Pane' is Set to 'Yes' |
Shared |
The customer is responsible for implementing this recommendation. |
Restricts group creation to administrators with permissions only. |
link |
4 |
CIS_Azure_1.4.0 |
1.16 |
CIS_Azure_1.4.0_1.16 |
CIS Microsoft Azure Foundations Benchmark recommendation 1.16 |
1 Identity and Access Management |
Ensure that 'Users can create security groups in Azure portals, API or PowerShell' is set to 'No' |
Shared |
The customer is responsible for implementing this recommendation. |
Restrict security group creation to administrators only. |
link |
4 |
CIS_Azure_1.4.0 |
1.17 |
CIS_Azure_1.4.0_1.17 |
CIS Microsoft Azure Foundations Benchmark recommendation 1.17 |
1 Identity and Access Management |
Ensure that 'Owners can manage group membership requests in the Access Panel' is set to 'No' |
Shared |
The customer is responsible for implementing this recommendation. |
Restrict security group management to administrators only. |
link |
4 |
CIS_Azure_1.4.0 |
1.18 |
CIS_Azure_1.4.0_1.18 |
CIS Microsoft Azure Foundations Benchmark recommendation 1.18 |
1 Identity and Access Management |
Ensure that 'Users can create Microsoft 365 groups in Azure portals, API or PowerShell' is set to 'No' |
Shared |
The customer is responsible for implementing this recommendation. |
Restrict Microsoft 365 group creation to administrators only. |
link |
4 |
CIS_Azure_1.4.0 |
1.20 |
CIS_Azure_1.4.0_1.20 |
CIS Microsoft Azure Foundations Benchmark recommendation 1.20 |
1 Identity and Access Management |
Ensure That No Custom Subscription Owner Roles Are Created |
Shared |
The customer is responsible for implementing this recommendation. |
Subscription ownership should not include permission to create custom owner roles. The principle of least privilege should be followed and only necessary privileges should be assigned instead of allowing full administrative access. |
link |
6 |
CIS_Azure_1.4.0 |
1.22 |
CIS_Azure_1.4.0_1.22 |
CIS Microsoft Azure Foundations Benchmark recommendation 1.22 |
1 Identity and Access Management |
Ensure a Custom Role is Assigned Permissions for Administering Resource Locks |
Shared |
The customer is responsible for implementing this recommendation. |
Resource locking is a powerful protection mechanism that can prevent inadvertent modification/deletion of resources within Azure subscriptions/Resource Groups and is a recommended NIST configuration. |
link |
4 |
CIS_Azure_1.4.0 |
1.9 |
CIS_Azure_1.4.0_1.9 |
CIS Microsoft Azure Foundations Benchmark recommendation 1.9 |
1 Identity and Access Management |
Ensure that 'Users can consent to apps accessing company data on their behalf' is set to 'No' |
Shared |
The customer is responsible for implementing this recommendation. |
Require administrators to provide consent for the apps before use. |
link |
3 |
CIS_Azure_1.4.0 |
3.5 |
CIS_Azure_1.4.0_3.5 |
CIS Microsoft Azure Foundations Benchmark recommendation 3.5 |
3 Storage Accounts |
Ensure that 'Public access level' is set to Private for blob containers |
Shared |
The customer is responsible for implementing this recommendation. |
Disable anonymous access to blob containers and disallow blob public access on storage account. |
link |
7 |
CIS_Azure_1.4.0 |
8.7 |
CIS_Azure_1.4.0_8.7 |
CIS Microsoft Azure Foundations Benchmark recommendation 8.7 |
8 Other Security Considerations |
Enable role-based access control (RBAC) within Azure Kubernetes Services |
Shared |
The customer is responsible for implementing this recommendation. |
Ensure that RBAC is enabled on all Azure Kubernetes Services Instances |
link |
7 |
CIS_Azure_2.0.0 |
1.11 |
CIS_Azure_2.0.0_1.11 |
CIS Microsoft Azure Foundations Benchmark recommendation 1.11 |
1 |
Ensure `User consent for applications` is set to `Do not allow user consent` |
Shared |
Enforcing this setting may create additional requests that administrators need to review. |
Require administrators to provide consent for applications before use.
If Azure Active Directory is running as an identity provider for third-party applications, permissions and consent should be limited to administrators or pre-approved. Malicious applications may attempt to exfiltrate data or abuse privileged user accounts. |
link |
3 |
CIS_Azure_2.0.0 |
1.13 |
CIS_Azure_2.0.0_1.13 |
CIS Microsoft Azure Foundations Benchmark recommendation 1.13 |
1 |
Ensure that 'Users can add gallery apps to My Apps' is set to 'No' |
Shared |
Can cause additional requests to administrators that need to be fulfilled quite often. |
Require administrators to provide consent for the apps before use.
Unless Azure Active Directory is running as an identity provider for third-party applications, do not allow users to use their identity outside of your cloud environment. User profiles contain private information such as phone numbers and email addresses which could then be sold off to other third parties without requiring any further consent from the user. |
link |
3 |
CIS_Azure_2.0.0 |
1.14 |
CIS_Azure_2.0.0_1.14 |
CIS Microsoft Azure Foundations Benchmark recommendation 1.14 |
1 |
Ensure That 'Users Can Register Applications' Is Set to 'No' |
Shared |
Enforcing this setting will create additional requests for approval that will need to be addressed by an administrator. If permissions are delegated, a user may approve a malevolent third party application, potentially giving it access to your data. |
Require administrators or appropriately delegated users to register third-party applications.
It is recommended to only allow an administrator to register custom-developed applications. This ensures that the application undergoes a formal security review and approval process prior to exposing Azure Active Directory data. Certain users like developers or other high-request users may also be delegated permissions to prevent them from waiting on an administrative user. Your organization should review your policies and decide your needs. |
link |
3 |
CIS_Azure_2.0.0 |
1.15 |
CIS_Azure_2.0.0_1.15 |
CIS Microsoft Azure Foundations Benchmark recommendation 1.15 |
1 |
Ensure That 'Guest users access restrictions' is set to 'Guest user access is restricted to properties and memberships of their own directory objects' |
Shared |
This may create additional requests for permissions to access resources that administrators will need to approve. |
Limit guest user permissions.
Limiting guest access ensures that guest accounts do not have permission for certain directory tasks, such as enumerating users, groups or other directory resources, and cannot be assigned to administrative roles in your directory. Guest access has three levels of restriction.
1. Guest users have the same access as members (most inclusive),
2. Guest users have limited access to properties and memberships of directory objects (default value),
3. Guest user access is restricted to properties and memberships of their own directory objects (most restrictive).
The recommended option is the 3rd, most restrictive: "Guest user access is restricted to their own directory object". |
link |
8 |
CIS_Azure_2.0.0 |
1.16 |
CIS_Azure_2.0.0_1.16 |
CIS Microsoft Azure Foundations Benchmark recommendation 1.16 |
1 |
Ensure that 'Guest invite restrictions' is set to "Only users assigned to specific admin roles can invite guest users" |
Shared |
With the option of `Only users assigned to specific admin roles can invite guest users` selected, users with specific admin roles will be in charge of sending invitations to the external users, requiring additional overhead by them to manage user accounts. This will mean coordinating with other departments as they are onboarding new users. |
Restrict invitations to users with specific administrative roles only.
Restricting invitations to users with specific administrator roles ensures that only authorized accounts have access to cloud resources. This helps to maintain "Need to Know" permissions and prevents inadvertent access to data.
By default the setting `Guest invite restrictions` is set to `Anyone in the organization can invite guest users including guests and non-admins`. This would allow anyone within the organization to invite guests and non-admins to the tenant, posing a security risk. |
link |
8 |
CIS_Azure_2.0.0 |
1.17 |
CIS_Azure_2.0.0_1.17 |
CIS Microsoft Azure Foundations Benchmark recommendation 1.17 |
1 |
Ensure That 'Restrict access to Azure AD administration portal' is Set to 'Yes' |
Shared |
All administrative tasks will need to be done by Administrators, causing additional overhead in management of users and resources. |
Restrict access to the Azure AD administration portal to administrators only.
**NOTE**: This only affects access to the Azure AD administrator's web portal. This setting does not prohibit privileged users from using other methods such as Rest API or Powershell to obtain sensitive information from Azure AD.
The Azure AD administrative portal has sensitive data and permission settings. All non-administrators should be prohibited from accessing any Azure AD data in the administration portal to avoid exposure. |
link |
6 |
CIS_Azure_2.0.0 |
1.18 |
CIS_Azure_2.0.0_1.18 |
CIS Microsoft Azure Foundations Benchmark recommendation 1.18 |
1 |
Ensure that 'Restrict user ability to access groups features in the Access Pane' is Set to 'Yes' |
Shared |
Setting to `Yes` could create administrative overhead by customers seeking certain group memberships that will have to be manually managed by administrators with appropriate permissions. |
Restricts group creation to administrators with permissions only.
Self-service group management enables users to create and manage security groups or Office 365 groups in Azure Active Directory (Azure AD). Unless a business requires this day-to-day delegation for some users, self-service group management should be disabled. |
link |
4 |
CIS_Azure_2.0.0 |
1.19 |
CIS_Azure_2.0.0_1.19 |
CIS Microsoft Azure Foundations Benchmark recommendation 1.19 |
1 |
Ensure that 'Users can create security groups in Azure portals, API or PowerShell' is set to 'No' |
Shared |
Enabling this setting could create a number of requests that would need to be managed by an administrator. |
Restrict security group creation to administrators only.
When creating security groups is enabled, all users in the directory are allowed to create new security groups and add members to those groups. Unless a business requires this day-to-day delegation, security group creation should be restricted to administrators only. |
link |
4 |
CIS_Azure_2.0.0 |
1.20 |
CIS_Azure_2.0.0_1.20 |
CIS Microsoft Azure Foundations Benchmark recommendation 1.20 |
1 |
Ensure that 'Owners can manage group membership requests in the Access Panel' is set to 'No' |
Shared |
Group Membership for user accounts will need to be handled by Admins and cause administrative overhead. |
Restrict security group management to administrators only.
Restricting security group management to administrators only prohibits users from making changes to security groups. This ensures that security groups are appropriately managed and their management is not delegated to non-administrators. |
link |
4 |
CIS_Azure_2.0.0 |
1.21 |
CIS_Azure_2.0.0_1.21 |
CIS Microsoft Azure Foundations Benchmark recommendation 1.21 |
1 |
Ensure that 'Users can create Microsoft 365 groups in Azure portals, API or PowerShell' is set to 'No' |
Shared |
Enabling this setting could create a number of requests that would need to be managed by an administrator. |
Restrict Microsoft 365 group creation to administrators only.
Restricting Microsoft 365 group creation to administrators only ensures that creation of Microsoft 365 groups is controlled by the administrator. Appropriate groups should be created and managed by the administrator and group creation rights should not be delegated to any other user. |
link |
4 |
CIS_Azure_2.0.0 |
1.23 |
CIS_Azure_2.0.0_1.23 |
CIS Microsoft Azure Foundations Benchmark recommendation 1.23 |
1 |
Ensure That No Custom Subscription Administrator Roles Exist |
Shared |
Subscriptions will need to be handled by Administrators with permissions. |
The principle of least privilege should be followed and only necessary privileges should be assigned instead of allowing full administrative access.
Classic subscription admin roles offer basic access management and include Account Administrator, Service Administrator, and Co-Administrators. It is recommended the least necessary permissions be given initially. Permissions can be added as needed by the account holder. This ensures the account holder cannot perform actions which were not intended. |
link |
7 |
CIS_Azure_2.0.0 |
1.24 |
CIS_Azure_2.0.0_1.24 |
CIS Microsoft Azure Foundations Benchmark recommendation 1.24 |
1 |
Ensure a Custom Role is Assigned Permissions for Administering Resource Locks |
Shared |
By adding this role, specific permissions may be granted for managing just resource locks rather than needing to provide the wide Owner or User Access Administrator role, reducing the risk of the user being able to do unintentional damage. |
Resource locking is a powerful protection mechanism that can prevent inadvertent modification/deletion of resources within Azure subscriptions/Resource Groups and is a recommended NIST configuration.
Given the resource lock functionality is outside of standard Role Based Access Control(RBAC), it would be prudent to create a resource lock administrator role to prevent inadvertent unlocking of resources. |
link |
4 |
CIS_Azure_2.0.0 |
3.7 |
CIS_Azure_2.0.0_3.7 |
CIS Microsoft Azure Foundations Benchmark recommendation 3.7 |
3 |
Ensure that 'Public access level' is disabled for storage accounts with blob containers |
Shared |
Access will have to be managed using shared access signatures or via Azure AD RBAC. |
Disallowing public access for a storage account overrides the public access settings for individual containers in that storage account.
The default configuration for a storage account permits a user with appropriate permissions to configure public (anonymous) access to containers and blobs in a storage account. Keep in mind that public access to a container is always turned off by default and must be explicitly configured to permit anonymous requests. It grants read-only access to these resources without sharing the account key, and without requiring a shared access signature.
It is recommended not to provide anonymous access to blob containers until, and unless, it is strongly desired. A shared access signature token or Azure AD RBAC should be used for providing controlled and timed access to blob containers.
If no anonymous access is needed on any container in the storage account, it’s recommended to set allowBlobPublicAccess false at the account level, which forbids any container to accept anonymous access in the future. |
link |
7 |
FedRAMP_High_R4 |
AC-1 |
FedRAMP_High_R4_AC-1 |
FedRAMP High AC-1 |
Access Control |
Access Control Policy And Procedures |
Shared |
n/a |
The organization:
a. Develops, documents, and disseminates to [Assignment: organization-defined personnel or roles]:
1. An access control policy that addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and
2. Procedures to facilitate the implementation of the access control policy and associated access controls; and
b. Reviews and updates the current:
1. Access control policy [Assignment: organization-defined frequency]; and
2. Access control procedures [Assignment: organization-defined frequency].
Supplemental Guidance: This control addresses the establishment of policy and procedures for the effective implementation of selected security controls and control enhancements in the AC family. Policy and procedures reflect applicable federal laws, Executive Orders, directives, regulations, policies, standards, and guidance. Security program policies and procedures at the organization level may make the need for system-specific policies and procedures unnecessary. The policy can be included as part of the general information security policy for organizations or conversely, can be represented by multiple policies reflecting the complex nature of certain organizations. The procedures can be established for the security program in general and for particular information systems, if needed.
The organizational risk management strategy is a key factor in establishing policy and procedures. Related control: PM-9.
Control Enhancements: None.
References: NIST Special Publications 800-12, 800-100. |
link |
4 |
FedRAMP_High_R4 |
AC-3 |
FedRAMP_High_R4_AC-3 |
FedRAMP High AC-3 |
Access Control |
Access Enforcement |
Shared |
n/a |
The information system enforces approved authorizations for logical access to information and system resources in accordance with applicable access control policies.
Supplemental Guidance: Access control policies (e.g., identity-based policies, role-based policies, attribute-based policies) and access enforcement mechanisms (e.g., access control lists, access control matrices, cryptography) control access between active entities or subjects (i.e., users or processes acting on behalf of users) and passive entities or objects (e.g., devices, files, records, domains) in information systems. In addition to enforcing authorized access at the information system level and recognizing that information systems can host many applications and services in support of organizational missions and business operations, access enforcement mechanisms can also be employed at the application and service level to provide increased information security. Related controls: AC-2, AC-4, AC-5, AC-6, AC-16, AC-17, AC-18, AC-19, AC-20, AC-21, AC-22, AU-9, CM-5, CM-6, CM-11, MA-3, MA-4, MA-5, PE-3.
References: None. |
link |
21 |
FedRAMP_High_R4 |
AC-6(1) |
FedRAMP_High_R4_AC-6(1) |
FedRAMP High AC-6 (1) |
Access Control |
Authorize Access To Security Functions |
Shared |
n/a |
The organization explicitly authorizes access to [Assignment: organization-defined security functions (deployed in hardware, software, and firmware) and security-relevant information].
Supplemental Guidance: Security functions include, for example, establishing system accounts, configuring access authorizations (i.e., permissions, privileges), setting events to be audited, and setting intrusion detection parameters. Security-relevant information includes, for example, filtering rules for routers/firewalls, cryptographic key management information, configuration parameters for security services, and access control lists. Explicitly authorized personnel include, for example, security administrators, system and network administrators, system security officers, system maintenance personnel, system programmers, and other privileged users. Related controls: AC-17, AC-18, AC-19. |
link |
3 |
FedRAMP_Moderate_R4 |
AC-1 |
FedRAMP_Moderate_R4_AC-1 |
FedRAMP Moderate AC-1 |
Access Control |
Access Control Policy And Procedures |
Shared |
n/a |
The organization:
a. Develops, documents, and disseminates to [Assignment: organization-defined personnel or roles]:
1. An access control policy that addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and
2. Procedures to facilitate the implementation of the access control policy and associated access controls; and
b. Reviews and updates the current:
1. Access control policy [Assignment: organization-defined frequency]; and
2. Access control procedures [Assignment: organization-defined frequency].
Supplemental Guidance: This control addresses the establishment of policy and procedures for the effective implementation of selected security controls and control enhancements in the AC family. Policy and procedures reflect applicable federal laws, Executive Orders, directives, regulations, policies, standards, and guidance. Security program policies and procedures at the organization level may make the need for system-specific policies and procedures unnecessary. The policy can be included as part of the general information security policy for organizations or conversely, can be represented by multiple policies reflecting the complex nature of certain organizations. The procedures can be established for the security program in general and for particular information systems, if needed.
The organizational risk management strategy is a key factor in establishing policy and procedures. Related control: PM-9.
Control Enhancements: None.
References: NIST Special Publications 800-12, 800-100. |
link |
4 |
FedRAMP_Moderate_R4 |
AC-3 |
FedRAMP_Moderate_R4_AC-3 |
FedRAMP Moderate AC-3 |
Access Control |
Access Enforcement |
Shared |
n/a |
The information system enforces approved authorizations for logical access to information and system resources in accordance with applicable access control policies.
Supplemental Guidance: Access control policies (e.g., identity-based policies, role-based policies, attribute-based policies) and access enforcement mechanisms (e.g., access control lists, access control matrices, cryptography) control access between active entities or subjects (i.e., users or processes acting on behalf of users) and passive entities or objects (e.g., devices, files, records, domains) in information systems. In addition to enforcing authorized access at the information system level and recognizing that information systems can host many applications and services in support of organizational missions and business operations, access enforcement mechanisms can also be employed at the application and service level to provide increased information security. Related controls: AC-2, AC-4, AC-5, AC-6, AC-16, AC-17, AC-18, AC-19, AC-20, AC-21, AC-22, AU-9, CM-5, CM-6, CM-11, MA-3, MA-4, MA-5, PE-3.
References: None. |
link |
21 |
FedRAMP_Moderate_R4 |
AC-6(1) |
FedRAMP_Moderate_R4_AC-6(1) |
FedRAMP Moderate AC-6 (1) |
Access Control |
Authorize Access To Security Functions |
Shared |
n/a |
The organization explicitly authorizes access to [Assignment: organization-defined security functions (deployed in hardware, software, and firmware) and security-relevant information].
Supplemental Guidance: Security functions include, for example, establishing system accounts, configuring access authorizations (i.e., permissions, privileges), setting events to be audited, and setting intrusion detection parameters. Security-relevant information includes, for example, filtering rules for routers/firewalls, cryptographic key management information, configuration parameters for security services, and access control lists. Explicitly authorized personnel include, for example, security administrators, system and network administrators, system security officers, system maintenance personnel, system programmers, and other privileged users. Related controls: AC-17, AC-18, AC-19. |
link |
3 |
hipaa |
0114.04b1Organizational.1-04.b |
hipaa-0114.04b1Organizational.1-04.b |
0114.04b1Organizational.1-04.b |
01 Information Protection Program |
0114.04b1Organizational.1-04.b 04.01 Information Security Policy |
Shared |
n/a |
The security policies are regularly reviewed and updated to ensure they reflect leading practices (e.g., for systems and services development and acquisition), and are communicated throughout the organization. |
|
9 |
hipaa |
0115.04b2Organizational.123-04.b |
hipaa-0115.04b2Organizational.123-04.b |
0115.04b2Organizational.123-04.b |
01 Information Protection Program |
0115.04b2Organizational.123-04.b 04.01 Information Security Policy |
Shared |
n/a |
The owner of the security policies has management approval and assigned responsibility to develop, review, update (based on specific input), and approve the security policies; and such reviews, updates, and approvals occur no less than annually. |
|
20 |
hipaa |
0227.09k2Organizational.12-09.k |
hipaa-0227.09k2Organizational.12-09.k |
0227.09k2Organizational.12-09.k |
02 Endpoint Protection |
0227.09k2Organizational.12-09.k 09.04 Protection Against Malicious and Mobile Code |
Shared |
n/a |
The organization takes specific actions to protect against mobile code performing unauthorized actions. |
|
18 |
hipaa |
0894.01m2Organizational.7-01.m |
hipaa-0894.01m2Organizational.7-01.m |
0894.01m2Organizational.7-01.m |
08 Network Protection |
0894.01m2Organizational.7-01.m 01.04 Network Access Control |
Shared |
n/a |
Networks are segregated from production-level networks when migrating physical servers, applications, or data to virtualized servers. |
|
19 |
hipaa |
11180.01c3System.6-01.c |
hipaa-11180.01c3System.6-01.c |
11180.01c3System.6-01.c |
11 Access Control |
11180.01c3System.6-01.c 01.02 Authorized Access to Information Systems |
Shared |
n/a |
Access to management functions or administrative consoles for systems hosting virtualized systems are restricted to personnel based upon the principle of least privilege and supported through technical controls. |
|
7 |
hipaa |
1123.01q1System.2-01.q |
hipaa-1123.01q1System.2-01.q |
1123.01q1System.2-01.q |
11 Access Control |
1123.01q1System.2-01.q 01.05 Operating System Access Control |
Shared |
n/a |
Users who perform privileged functions (e.g., system administration) use separate accounts when performing those privileged functions. |
|
6 |
hipaa |
1129.01v1System.12-01.v |
hipaa-1129.01v1System.12-01.v |
1129.01v1System.12-01.v |
11 Access Control |
1129.01v1System.12-01.v 01.06 Application and Information Access Control |
Shared |
n/a |
Access rights to applications and application functions should be restricted in accordance with the access control policy. |
|
12 |
hipaa |
1143.01c1System.123-01.c |
hipaa-1143.01c1System.123-01.c |
1143.01c1System.123-01.c |
11 Access Control |
1143.01c1System.123-01.c 01.02 Authorized Access to Information Systems |
Shared |
n/a |
Privileges are formally authorized and controlled, allocated to users on a need-to-use and event-by-event basis for their functional role (e.g., user or administrator), and documented for each system product/element. |
|
10 |
hipaa |
1144.01c1System.4-01.c |
hipaa-1144.01c1System.4-01.c |
1144.01c1System.4-01.c |
11 Access Control |
1144.01c1System.4-01.c 01.02 Authorized Access to Information Systems |
Shared |
n/a |
The organization explicitly authorizes access to specific security relevant functions (deployed in hardware, software, and firmware) and security-relevant information. |
|
6 |
hipaa |
1146.01c2System.23-01.c |
hipaa-1146.01c2System.23-01.c |
1146.01c2System.23-01.c |
11 Access Control |
1146.01c2System.23-01.c 01.02 Authorized Access to Information Systems |
Shared |
n/a |
The organization promotes the development and use of programs that avoid the need to run with elevated privileges and system routines to avoid the need to grant privileges to users. |
|
8 |
hipaa |
1147.01c2System.456-01.c |
hipaa-1147.01c2System.456-01.c |
1147.01c2System.456-01.c |
11 Access Control |
1147.01c2System.456-01.c 01.02 Authorized Access to Information Systems |
Shared |
n/a |
Elevated privileges are assigned to a different user ID from those used for normal business use, all users access privileged services in a single role, and such privileged access is minimized. |
|
6 |
hipaa |
1148.01c2System.78-01.c |
hipaa-1148.01c2System.78-01.c |
1148.01c2System.78-01.c |
11 Access Control |
1148.01c2System.78-01.c 01.02 Authorized Access to Information Systems |
Shared |
n/a |
The organization restricts access to privileged functions and all security-relevant information. |
|
8 |
hipaa |
1230.09c2Organizational.1-09.c |
hipaa-1230.09c2Organizational.1-09.c |
1230.09c2Organizational.1-09.c |
12 Audit Logging & Monitoring |
1230.09c2Organizational.1-09.c 09.01 Documented Operating Procedures |
Shared |
n/a |
No single person is able to access, modify, or use information systems without authorization or detection. |
|
13 |
hipaa |
1232.09c3Organizational.12-09.c |
hipaa-1232.09c3Organizational.12-09.c |
1232.09c3Organizational.12-09.c |
12 Audit Logging & Monitoring |
1232.09c3Organizational.12-09.c 09.01 Documented Operating Procedures |
Shared |
n/a |
Access for individuals responsible for administering access controls is limited to the minimum necessary based upon each user's role and responsibilities and these individuals cannot access audit functions related to these controls. |
|
21 |
hipaa |
1276.09c2Organizational.2-09.c |
hipaa-1276.09c2Organizational.2-09.c |
1276.09c2Organizational.2-09.c |
12 Audit Logging & Monitoring |
1276.09c2Organizational.2-09.c 09.01 Documented Operating Procedures |
Shared |
n/a |
Security audit activities are independent. |
|
18 |
hipaa |
1451.05iCSPOrganizational.2-05.i |
hipaa-1451.05iCSPOrganizational.2-05.i |
1451.05iCSPOrganizational.2-05.i |
14 Third Party Assurance |
1451.05iCSPOrganizational.2-05.i 05.02 External Parties |
Shared |
n/a |
Cloud service providers design and implement controls to mitigate and contain data security risks through proper separation of duties, role-based access, and least-privilege access for all personnel within their supply chain. |
|
21 |
ISO27001-2013 |
A.12.1.1 |
ISO27001-2013_A.12.1.1 |
ISO 27001:2013 A.12.1.1 |
Operations Security |
Documented operating procedures |
Shared |
n/a |
Operating procedures shall be documented and made available to all users who need them. |
link |
31 |
ISO27001-2013 |
A.13.1.1 |
ISO27001-2013_A.13.1.1 |
ISO 27001:2013 A.13.1.1 |
Communications Security |
Network controls |
Shared |
n/a |
Networks shall be managed and controlled to protect information in systems and applications. |
link |
40 |
ISO27001-2013 |
A.14.1.2 |
ISO27001-2013_A.14.1.2 |
ISO 27001:2013 A.14.1.2 |
System Acquisition, Development And Maintenance |
Securing application services on public networks |
Shared |
n/a |
Information involved in application services passing over public networks shall be protected from fraudulent activity, contract dispute and unauthorized disclosure and modification. |
link |
32 |
ISO27001-2013 |
A.14.1.3 |
ISO27001-2013_A.14.1.3 |
ISO 27001:2013 A.14.1.3 |
System Acquisition, Development And Maintenance |
Protecting application services transactions |
Shared |
n/a |
Information involved in application service transactions shall be protected to prevent incomplete transmission, mis-routing, unauthorized message alteration, unauthorized disclosure, unauthorized message duplication or replay. |
link |
29 |
ISO27001-2013 |
A.18.1.1 |
ISO27001-2013_A.18.1.1 |
ISO 27001:2013 A.18.1.1 |
Compliance |
Identification applicable legislation and contractual requirements |
Shared |
n/a |
All relevant legislative statutory, regulatory, contractual requirements and the organization's approach to meet these requirements shall be explicitly identified, documented and kept up to date for each information system and the organization. |
link |
30 |
ISO27001-2013 |
A.5.1.1 |
ISO27001-2013_A.5.1.1 |
ISO 27001:2013 A.5.1.1 |
Information Security Policies |
Policies for information security |
Shared |
n/a |
A set of policies for information security shall be defined, approved by management, published and communicated to employees and relevant external parties. |
link |
42 |
ISO27001-2013 |
A.5.1.2 |
ISO27001-2013_A.5.1.2 |
ISO 27001:2013 A.5.1.2 |
Information Security Policies |
Review of the policies for information security |
Shared |
n/a |
The policies for information security shall be reviewed at planned intervals or if significant changes occur to ensure their continuing suitability, adequacy, and effectiveness. |
link |
29 |
ISO27001-2013 |
A.6.1.1 |
ISO27001-2013_A.6.1.1 |
ISO 27001:2013 A.6.1.1 |
Organization of Information Security |
Information security roles and responsibilities |
Shared |
n/a |
All information security responsibilities shall be clearly defined and allocated. |
link |
73 |
ISO27001-2013 |
A.6.2.2 |
ISO27001-2013_A.6.2.2 |
ISO 27001:2013 A.6.2.2 |
Organization of Information Security |
Teleworking |
Shared |
n/a |
A policy and supporting security measures shall be implemented to protect information accessed, processed or stored at teleworking sites. |
link |
16 |
ISO27001-2013 |
A.9.1.1 |
ISO27001-2013_A.9.1.1 |
ISO 27001:2013 A.9.1.1 |
Access Control |
Access control policy |
Shared |
n/a |
An access control policy shall be established, documented, and reviewed based on business and information security requirements. |
link |
4 |
ISO27001-2013 |
A.9.1.2 |
ISO27001-2013_A.9.1.2 |
ISO 27001:2013 A.9.1.2 |
Access Control |
Access to networks and network services |
Shared |
n/a |
Users shall only be provided with access to the network and network services that they have been specifically authorized to use. |
link |
29 |
ISO27001-2013 |
A.9.2.2 |
ISO27001-2013_A.9.2.2 |
ISO 27001:2013 A.9.2.2 |
Access Control |
User access provisioning |
Shared |
n/a |
A formal user access provisioning process shall be implemented to assign or revoke access rights for all user types to all systems and services. |
link |
19 |
ISO27001-2013 |
A.9.2.3 |
ISO27001-2013_A.9.2.3 |
ISO 27001:2013 A.9.2.3 |
Access Control |
Management of privileged access rights |
Shared |
n/a |
The allocation and use of privileged access rights shall be restricted and controlled. |
link |
33 |
ISO27001-2013 |
A.9.4.1 |
ISO27001-2013_A.9.4.1 |
ISO 27001:2013 A.9.4.1 |
Access Control |
Information access restriction |
Shared |
n/a |
Access to information and application system functions shall be restricted in accordance with the access control policy. |
link |
11 |
ISO27001-2013 |
A.9.4.4 |
ISO27001-2013_A.9.4.4 |
ISO 27001:2013 A.9.4.4 |
Access Control |
Use of privileged utility programs |
Shared |
n/a |
The use of utility programs that might be capable of overriding system and application controls shall be restricted and tightly controlled. |
link |
9 |
ISO27001-2013 |
A.9.4.5 |
ISO27001-2013_A.9.4.5 |
ISO 27001:2013 A.9.4.5 |
Access Control |
Access control to program source code |
Shared |
n/a |
Access to program source code shall be restricted. |
link |
10 |
|
mp.com.2 Protection of confidentiality |
mp.com.2 Protection of confidentiality |
404 not found |
|
|
|
n/a |
n/a |
|
55 |
|
mp.com.3 Protection of integrity and authenticity |
mp.com.3 Protection of integrity and authenticity |
404 not found |
|
|
|
n/a |
n/a |
|
62 |
|
mp.com.4 Separation of information flows on the network |
mp.com.4 Separation of information flows on the network |
404 not found |
|
|
|
n/a |
n/a |
|
51 |
|
mp.info.1 Personal data |
mp.info.1 Personal data |
404 not found |
|
|
|
n/a |
n/a |
|
33 |
|
mp.info.2 Rating of information |
mp.info.2 Rating of information |
404 not found |
|
|
|
n/a |
n/a |
|
45 |
|
mp.info.3 Electronic signature |
mp.info.3 Electronic signature |
404 not found |
|
|
|
n/a |
n/a |
|
40 |
|
mp.info.4 Time stamps |
mp.info.4 Time stamps |
404 not found |
|
|
|
n/a |
n/a |
|
33 |
|
mp.info.6 Backups |
mp.info.6 Backups |
404 not found |
|
|
|
n/a |
n/a |
|
65 |
|
mp.sw.1 IT Aplications development |
mp.sw.1 IT Aplications development |
404 not found |
|
|
|
n/a |
n/a |
|
51 |
NIST_SP_800-171_R2_3 |
.1.2 |
NIST_SP_800-171_R2_3.1.2 |
NIST SP 800-171 R2 3.1.2 |
Access Control |
Limit system access to the types of transactions and functions that authorized users are permitted to execute. |
Shared |
Microsoft and the customer share responsibilities for implementing this requirement. |
Organizations may choose to define access privileges or other attributes by account, by type of account, or a combination of both. System account types include individual, shared, group, system, anonymous, guest, emergency, developer, manufacturer, vendor, and temporary. Other attributes required for authorizing access include restrictions on time-of-day, day-of-week, and point-of-origin. In defining other account attributes, organizations consider system-related requirements (e.g., system upgrades scheduled maintenance,) and mission or business requirements, (e.g., time zone differences, customer requirements, remote access to support travel requirements). |
link |
31 |
NIST_SP_800-171_R2_3 |
.1.5 |
NIST_SP_800-171_R2_3.1.5 |
NIST SP 800-171 R2 3.1.5 |
Access Control |
Employ the principle of least privilege, including for specific security functions and privileged accounts. |
Shared |
Microsoft and the customer share responsibilities for implementing this requirement. |
Organizations employ the principle of least privilege for specific duties and authorized accesses for users and processes. The principle of least privilege is applied with the goal of authorized privileges no higher than necessary to accomplish required organizational missions or business functions. Organizations consider the creation of additional processes, roles, and system accounts as necessary, to achieve least privilege. Organizations also apply least privilege to the development, implementation, and operation of organizational systems. Security functions include establishing system accounts, setting events to be logged, setting intrusion detection parameters, and configuring access authorizations (i.e., permissions, privileges). Privileged accounts, including super user accounts, are typically described as system administrator for various types of commercial off-the-shelf operating systems. Restricting privileged accounts to specific personnel or roles prevents day-to-day users from having access to privileged information or functions. Organizations may differentiate in the application of this requirement between allowed privileges for local accounts and for domain accounts provided organizations retain the ability to control system configurations for key security parameters and as otherwise necessary to sufficiently mitigate risk. |
link |
8 |
NIST_SP_800-53_R4 |
AC-1 |
NIST_SP_800-53_R4_AC-1 |
NIST SP 800-53 Rev. 4 AC-1 |
Access Control |
Access Control Policy And Procedures |
Shared |
n/a |
The organization:
a. Develops, documents, and disseminates to [Assignment: organization-defined personnel or roles]:
1. An access control policy that addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and
2. Procedures to facilitate the implementation of the access control policy and associated access controls; and
b. Reviews and updates the current:
1. Access control policy [Assignment: organization-defined frequency]; and
2. Access control procedures [Assignment: organization-defined frequency].
Supplemental Guidance: This control addresses the establishment of policy and procedures for the effective implementation of selected security controls and control enhancements in the AC family. Policy and procedures reflect applicable federal laws, Executive Orders, directives, regulations, policies, standards, and guidance. Security program policies and procedures at the organization level may make the need for system-specific policies and procedures unnecessary. The policy can be included as part of the general information security policy for organizations or conversely, can be represented by multiple policies reflecting the complex nature of certain organizations. The procedures can be established for the security program in general and for particular information systems, if needed.
The organizational risk management strategy is a key factor in establishing policy and procedures. Related control: PM-9.
Control Enhancements: None.
References: NIST Special Publications 800-12, 800-100. |
link |
4 |
NIST_SP_800-53_R4 |
AC-3 |
NIST_SP_800-53_R4_AC-3 |
NIST SP 800-53 Rev. 4 AC-3 |
Access Control |
Access Enforcement |
Shared |
n/a |
The information system enforces approved authorizations for logical access to information and system resources in accordance with applicable access control policies.
Supplemental Guidance: Access control policies (e.g., identity-based policies, role-based policies, attribute-based policies) and access enforcement mechanisms (e.g., access control lists, access control matrices, cryptography) control access between active entities or subjects (i.e., users or processes acting on behalf of users) and passive entities or objects (e.g., devices, files, records, domains) in information systems. In addition to enforcing authorized access at the information system level and recognizing that information systems can host many applications and services in support of organizational missions and business operations, access enforcement mechanisms can also be employed at the application and service level to provide increased information security. Related controls: AC-2, AC-4, AC-5, AC-6, AC-16, AC-17, AC-18, AC-19, AC-20, AC-21, AC-22, AU-9, CM-5, CM-6, CM-11, MA-3, MA-4, MA-5, PE-3.
References: None. |
link |
21 |
NIST_SP_800-53_R4 |
AC-6(1) |
NIST_SP_800-53_R4_AC-6(1) |
NIST SP 800-53 Rev. 4 AC-6 (1) |
Access Control |
Authorize Access To Security Functions |
Shared |
n/a |
The organization explicitly authorizes access to [Assignment: organization-defined security functions (deployed in hardware, software, and firmware) and security-relevant information].
Supplemental Guidance: Security functions include, for example, establishing system accounts, configuring access authorizations (i.e., permissions, privileges), setting events to be audited, and setting intrusion detection parameters. Security-relevant information includes, for example, filtering rules for routers/firewalls, cryptographic key management information, configuration parameters for security services, and access control lists. Explicitly authorized personnel include, for example, security administrators, system and network administrators, system security officers, system maintenance personnel, system programmers, and other privileged users. Related controls: AC-17, AC-18, AC-19. |
link |
3 |
NIST_SP_800-53_R5 |
AC-1 |
NIST_SP_800-53_R5_AC-1 |
NIST SP 800-53 Rev. 5 AC-1 |
Access Control |
Policy and Procedures |
Shared |
n/a |
a. Develop, document, and disseminate to [Assignment: organization-defined personnel or roles]:
1. [Selection (OneOrMore): Organization-level;Mission/business process-level;System-level] access control policy that:
(a) Addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and
(b) Is consistent with applicable laws, executive orders, directives, regulations, policies, standards, and guidelines; and
2. Procedures to facilitate the implementation of the access control policy and the associated access controls;
b. Designate an [Assignment: organization-defined official] to manage the development, documentation, and dissemination of the access control policy and procedures; and
c. Review and update the current access control:
1. Policy [Assignment: organization-defined frequency] and following [Assignment: organization-defined events]; and
2. Procedures [Assignment: organization-defined frequency] and following [Assignment: organization-defined events]. |
link |
4 |
NIST_SP_800-53_R5 |
AC-3 |
NIST_SP_800-53_R5_AC-3 |
NIST SP 800-53 Rev. 5 AC-3 |
Access Control |
Access Enforcement |
Shared |
n/a |
Enforce approved authorizations for logical access to information and system resources in accordance with applicable access control policies. |
link |
21 |
NIST_SP_800-53_R5 |
AC-6(1) |
NIST_SP_800-53_R5_AC-6(1) |
NIST SP 800-53 Rev. 5 AC-6 (1) |
Access Control |
Authorize Access to Security Functions |
Shared |
n/a |
Authorize access for [Assignment: organization-defined individuals or roles] to:
(a) [Assignment: organization-defined security functions (deployed in hardware, software, and firmware)]; and
(b) [Assignment: organization-defined security-relevant information]. |
link |
3 |
|
op.acc.1 Identification |
op.acc.1 Identification |
404 not found |
|
|
|
n/a |
n/a |
|
66 |
|
op.acc.2 Access requirements |
op.acc.2 Access requirements |
404 not found |
|
|
|
n/a |
n/a |
|
64 |
|
op.acc.3 Segregation of functions and tasks |
op.acc.3 Segregation of functions and tasks |
404 not found |
|
|
|
n/a |
n/a |
|
43 |
|
op.acc.4 Access rights management process |
op.acc.4 Access rights management process |
404 not found |
|
|
|
n/a |
n/a |
|
40 |
|
op.ext.4 Interconnection of systems |
op.ext.4 Interconnection of systems |
404 not found |
|
|
|
n/a |
n/a |
|
68 |
|
op.pl.2 Security Architecture |
op.pl.2 Security Architecture |
404 not found |
|
|
|
n/a |
n/a |
|
65 |
|
op.pl.3 Acquisition of new components |
op.pl.3 Acquisition of new components |
404 not found |
|
|
|
n/a |
n/a |
|
61 |
PCI_DSS_v4.0 |
10.6.3 |
PCI_DSS_v4.0_10.6.3 |
PCI DSS v4.0 10.6.3 |
Requirement 10: Log and Monitor All Access to System Components and Cardholder Data |
Time-synchronization mechanisms support consistent time settings across all systems |
Shared |
n/a |
Time synchronization settings and data are protected as follows:
• Access to time data is restricted to only personnel with a business need.
• Any changes to time settings on critical systems are logged, monitored, and reviewed. |
link |
10 |
PCI_DSS_v4.0 |
7.1.1 |
PCI_DSS_v4.0_7.1.1 |
PCI DSS v4.0 7.1.1 |
Requirement 07: Restrict Access to System Components and Cardholder Data by Business Need to Know |
Processes and mechanisms for restricting access to system components and cardholder data by business need to know are defined and understood |
Shared |
n/a |
All security policies and operational procedures that are identified in Requirement 7 are:
• Documented.
• Kept up to date.
• In use.
• Known to all affected parties. |
link |
4 |
PCI_DSS_v4.0 |
7.1.2 |
PCI_DSS_v4.0_7.1.2 |
PCI DSS v4.0 7.1.2 |
Requirement 07: Restrict Access to System Components and Cardholder Data by Business Need to Know |
Processes and mechanisms for restricting access to system components and cardholder data by business need to know are defined and understood |
Shared |
n/a |
Roles and responsibilities for performing activities in Requirement 7 are documented, assigned, and understood. |
link |
3 |
PCI_DSS_v4.0 |
7.2.1 |
PCI_DSS_v4.0_7.2.1 |
PCI DSS v4.0 7.2.1 |
Requirement 07: Restrict Access to System Components and Cardholder Data by Business Need to Know |
Access to system components and data is appropriately defined and assigned |
Shared |
n/a |
An access control model is defined and includes granting access as follows:
• Appropriate access depending on the entity’s business and access needs.
• Access to system components and data resources that is based on users’ job classification and functions.
• The least privileges required (for example, user, administrator) to perform a job function. |
link |
10 |
PCI_DSS_v4.0 |
7.2.2 |
PCI_DSS_v4.0_7.2.2 |
PCI DSS v4.0 7.2.2 |
Requirement 07: Restrict Access to System Components and Cardholder Data by Business Need to Know |
Access to system components and data is appropriately defined and assigned |
Shared |
n/a |
Access is assigned to users, including privileged users, based on:
• Job classification and function.
• Least privileges necessary to perform job responsibilities. |
link |
7 |
PCI_DSS_v4.0 |
7.2.3 |
PCI_DSS_v4.0_7.2.3 |
PCI DSS v4.0 7.2.3 |
Requirement 07: Restrict Access to System Components and Cardholder Data by Business Need to Know |
Access to system components and data is appropriately defined and assigned |
Shared |
n/a |
Required privileges are approved by authorized personnel. |
link |
8 |
PCI_DSS_v4.0 |
7.2.6 |
PCI_DSS_v4.0_7.2.6 |
PCI DSS v4.0 7.2.6 |
Requirement 07: Restrict Access to System Components and Cardholder Data by Business Need to Know |
Access to system components and data is appropriately defined and assigned |
Shared |
n/a |
All user access to query repositories of stored cardholder data is restricted as follows:
• Via applications or other programmatic methods, with access and allowed actions based on user roles and least privileges.
• Only the responsible administrator(s) can directly access or query repositories of stored CHD. |
link |
8 |
PCI_DSS_v4.0 |
7.3.1 |
PCI_DSS_v4.0_7.3.1 |
PCI DSS v4.0 7.3.1 |
Requirement 07: Restrict Access to System Components and Cardholder Data by Business Need to Know |
Access to system components and data is managed via an access control system(s) |
Shared |
n/a |
An access control system(s) is in place that restricts access based on a user’s need to know and covers all system components. |
link |
17 |
PCI_DSS_v4.0 |
7.3.2 |
PCI_DSS_v4.0_7.3.2 |
PCI DSS v4.0 7.3.2 |
Requirement 07: Restrict Access to System Components and Cardholder Data by Business Need to Know |
Access to system components and data is managed via an access control system(s) |
Shared |
n/a |
The access control system(s) is configured to enforce permissions assigned to individuals, applications, and systems based on job classification and function. |
link |
10 |
PCI_DSS_v4.0 |
7.3.3 |
PCI_DSS_v4.0_7.3.3 |
PCI DSS v4.0 7.3.3 |
Requirement 07: Restrict Access to System Components and Cardholder Data by Business Need to Know |
Access to system components and data is managed via an access control system(s) |
Shared |
n/a |
The access control system(s) is set to “deny all” by default. |
link |
6 |
SOC_2 |
CC6.1 |
SOC_2_CC6.1 |
SOC 2 Type 2 CC6.1 |
Logical and Physical Access Controls |
Logical access security software, infrastructure, and architectures |
Shared |
The customer is responsible for implementing this recommendation. |
The following points of focus, specifically related to all engagements using the trust services criteria, highlight important characteristics relating to this criterion:
• Identifies and Manages the Inventory of Information Assets — The entity identifies,
Page 29
TSP
Ref. #
TRUST SERVICES CRITERIA AND POINTS OF FOCUS
inventories, classifies, and manages information assets.
• Restricts Logical Access — Logical access to information assets, including hardware, data (at-rest, during processing, or in transmission), software, administrative
authorities, mobile devices, output, and offline system components is restricted
through the use of access control software and rule sets.
• Identifies and Authenticates Users — Persons, infrastructure, and software are
identified and authenticated prior to accessing information assets, whether locally
or remotely.
• Considers Network Segmentation — Network segmentation permits unrelated portions of the entity's information system to be isolated from each other.
• Manages Points of Access — Points of access by outside entities and the types of
data that flow through the points of access are identified, inventoried, and managed. The types of individuals and systems using each point of access are identified,
documented, and managed.
• Restricts Access to Information Assets — Combinations of data classification, separate data structures, port restrictions, access protocol restrictions, user identification, and digital certificates are used to establish access-control rules for information assets.
• Manages Identification and Authentication — Identification and authentication requirements are established, documented, and managed for individuals and systems
accessing entity information, infrastructure, and software.
• Manages Credentials for Infrastructure and Software — New internal and external
infrastructure and software are registered, authorized, and documented prior to being granted access credentials and implemented on the network or access point.
Credentials are removed and access is disabled when access is no longer required
or the infrastructure and software are no longer in use.
• Uses Encryption to Protect Data — The entity uses encryption to supplement other
measures used to protect data at rest, when such protections are deemed appropriate based on assessed risk.
• Protects Encryption Keys — Processes are in place to protect encryption keys during generation, storage, use, and destruction |
|
78 |
SWIFT_CSCF_v2022 |
2.11A |
SWIFT_CSCF_v2022_2.11A |
SWIFT CSCF v2022 2.11A |
2. Reduce Attack Surface and Vulnerabilities |
Restrict transaction activity to validated and approved business counterparties. |
Shared |
n/a |
Implement RMA controls to restrict transaction activity with effective business counterparties. |
link |
10 |