compliance controls are associated with this Policy definition 'Blocked accounts with owner permissions on Azure resources should be removed' (0cfea604-3201-4e14-88fc-fae4c427a6c5)
| Control Domain |
Control |
Name |
MetadataId |
Category |
Title |
Owner |
Requirements |
Description |
Info |
Policy# |
| AU_ISM |
380 |
AU_ISM_380 |
AU ISM 380 |
Guidelines for System Hardening - Operating system hardening |
Operating system configuration - 380 |
|
n/a |
Unneeded operating system accounts, software, components, services and functionality are removed or disabled. |
link |
2 |
| AU_ISM |
430 |
AU_ISM_430 |
AU ISM 430 |
Guidelines for Personnel Security - Access to systems and their resources |
Suspension of access to systems - 430 |
|
n/a |
Access to systems, applications and data repositories is removed or suspended on the same day personnel no longer have a legitimate requirement for access. |
link |
2 |
| AU_ISM |
441 |
AU_ISM_441 |
AU ISM 441 |
Guidelines for Personnel Security - Access to systems and their resources |
Temporary access to systems - 441 |
|
n/a |
When personnel are granted temporary access to a system, effective security controls are put in place to restrict their access to only data required for them to undertake their duties. |
link |
4 |
| Azure_Security_Benchmark_v1.0 |
3.1 |
Azure_Security_Benchmark_v1.0_3.1 |
Azure Security Benchmark 3.1 |
Identity and Access Control |
Maintain an inventory of administrative accounts |
Customer |
Microsoft Entra ID has built-in roles that must be explicitly assigned and are queryable. Use the Microsoft Entra PowerShell module to perform ad hoc queries to discover accounts that are members of administrative groups.
How to get a directory role in Microsoft Entra ID with PowerShell:
https://docs.microsoft.com/powershell/module/azuread/get-azureaddirectoryrole?view=azureadps-2.0
How to get members of a directory role in Microsoft Entra ID with PowerShell:
https://docs.microsoft.com/powershell/module/azuread/get-azureaddirectoryrolemember?view=azureadps-2.0 |
n/a |
link |
4 |
| Azure_Security_Benchmark_v1.0 |
3.10 |
Azure_Security_Benchmark_v1.0_3.10 |
Azure Security Benchmark 3.10 |
Identity and Access Control |
Regularly review and reconcile user access |
Customer |
Microsoft Entra ID provides logs to help discover stale accounts. In addition, use Azure Identity Access Reviews to efficiently manage group memberships, access to enterprise applications, and role assignments. User access can be reviewed on a regular basis to make sure only the right Users have continued access.
Understand Microsoft Entra reporting:
https://docs.microsoft.com/azure/active-directory/reports-monitoring/
How to use Azure Identity Access Reviews:
https://docs.microsoft.com/azure/active-directory/governance/access-reviews-overview |
n/a |
link |
5 |
| Azure_Security_Benchmark_v2.0 |
PA-1 |
Azure_Security_Benchmark_v2.0_PA-1 |
Azure Security Benchmark PA-1 |
Privileged Access |
Protect and limit highly privileged users |
Customer |
Limit the number of highly privileged user accounts, and protect these accounts at an elevated level.
The most critical built-in roles in Microsoft Entra ID are Global Administrator and the Privileged Role Administrator, because users assigned to these two roles can delegate administrator roles. With these privileges, users can directly or indirectly read and modify every resource in your Azure environment:
- Global Administrator / Company Administrator: Users with this role have access to all administrative features in Microsoft Entra ID, as well as services that use Microsoft Entra identities.
- Privileged Role Administrator: Users with this role can manage role assignments in Microsoft Entra ID, as well as within Microsoft Entra Privileged Identity Management (PIM). In addition, this role allows management of all aspects of PIM and administrative units.
Note: You may have other critical roles that need to be governed if you use custom roles with certain privileged permissions assigned. And you may also want to apply similar controls to the administrator account of critical business assets.
You can enable just-in-time (JIT) privileged access to Azure resources and Microsoft Entra ID using Microsoft Entra Privileged Identity Management (PIM). JIT grants temporary permissions to perform privileged tasks only when users need it. PIM can also generate security alerts when there is suspicious or unsafe activity in your Microsoft Entra organization.
Administrator role permissions in Microsoft Entra ID: https://docs.microsoft.com/azure/active-directory/users-groups-roles/directory-assign-admin-roles
Use Azure Privileged Identity Management security alerts: https://docs.microsoft.com/azure/active-directory/privileged-identity-management/pim-how-to-configure-security-alerts
Securing privileged access for hybrid and cloud deployments in Microsoft Entra ID: https://docs.microsoft.com/azure/active-directory/users-groups-roles/directory-admin-roles-secure |
n/a |
link |
4 |
| Azure_Security_Benchmark_v2.0 |
PA-3 |
Azure_Security_Benchmark_v2.0_PA-3 |
Azure Security Benchmark PA-3 |
Privileged Access |
Review and reconcile user access regularly |
Customer |
Review user accounts and access assignment regularly to ensure the accounts and their level of access are valid. You can use Microsoft Entra access reviews to review group memberships, access to enterprise applications, and role assignments. Microsoft Entra reporting can provide logs to help discover stale accounts. You can also use Microsoft Entra Privileged Identity Management to create an access review report workflow that facilitates the review process.
In addition, Azure Privileged Identity Management can be configured to alert when an excessive number of administrator accounts are created, and to identify administrator accounts that are stale or improperly configured.
Note: Some Azure services support local users and roles that aren't managed through Microsoft Entra ID. You must manage these users separately.
Create an access review of Azure resource roles in Privileged Identity Management(PIM): https://docs.microsoft.com/azure/active-directory/privileged-identity-management/pim-resource-roles-start-access-review
How to use Microsoft Entra identity and access reviews: https://docs.microsoft.com/azure/active-directory/governance/access-reviews-overview |
n/a |
link |
5 |
| Azure_Security_Benchmark_v3.0 |
PA-1 |
Azure_Security_Benchmark_v3.0_PA-1 |
Microsoft cloud security benchmark PA-1 |
Privileged Access |
Separate and limit highly privileged/administrative users |
Shared |
**Security Principle:**
Ensure you are identifying all high business impact accounts. Limit the number of privileged/administrative accounts in your cloud's control plane, management plane and data/workload plane.
**Azure Guidance:**
Microsoft Entra ID is Azure's default identity and access management service. The most critical built-in roles in Microsoft Entra ID are Global Administrator and Privileged Role Administrator, because users assigned to these two roles can delegate administrator roles. With these privileges, users can directly or indirectly read and modify every resource in your Azure environment:
- Global Administrator / Company Administrator: Users with this role have access to all administrative features in Microsoft Entra ID, as well as services that use Microsoft Entra identities.
- Privileged Role Administrator: Users with this role can manage role assignments in Microsoft Entra ID, as well as within Microsoft Entra Privileged Identity Management (PIM). In addition, this role allows management of all aspects of PIM and administrative units.
Outside of the Microsoft Entra ID, Azure has built-in roles that can be critical for privileged access at the resource level.
- Owner: Grants full access to manage all resources, including the ability to assign roles in Azure RBAC.
- Contributor: Grants full access to manage all resources, but does not allow you to assign roles in Azure RBAC, manage assignments in Azure Blueprints, or share image galleries.
- User Access Administrator: Lets you manage user access to Azure resources.
Note: You may have other critical roles that need to be governed if you use custom roles in the Microsoft Entra ID level or resource level with certain privileged permissions assigned.
Ensure that you also restrict privileged accounts in other management, identity, and security systems that have administrative access to your business-critical assets, such as Active Directory Domain Controllers (DCs), security tools, and system management tools with agents installed on business critical systems. Attackers who compromise these management and security systems can immediately weaponize them to compromise business critical assets.
**Implementation and additional context:**
Administrator role permissions in Microsoft Entra ID:
https://docs.microsoft.com/azure/active-directory/users-groups-roles/directory-assign-admin-roles
Use Azure Privileged Identity Management security alerts:
https://docs.microsoft.com/azure/active-directory/privileged-identity-management/pim-how-to-configure-security-alerts
Securing privileged access for hybrid and cloud deployments in Microsoft Entra ID:
https://docs.microsoft.com/azure/active-directory/users-groups-roles/directory-admin-roles-secure |
n/a |
link |
4 |
| Azure_Security_Benchmark_v3.0 |
PA-4 |
Azure_Security_Benchmark_v3.0_PA-4 |
Microsoft cloud security benchmark PA-4 |
Privileged Access |
Review and reconcile user access regularly |
Shared |
**Security Principle:**
Conduct regular review of privileged account entitlements. Ensure the access granted to the accounts are valid for administration of control plane, management plane, and workloads.
**Azure Guidance:**
Review all privileged accounts and the access entitlements in Azure including such as Azure tenant, Azure services, VM/IaaS, CI/CD processes, and enterprise management and security tools.
Use Microsoft Entra access reviews to review Microsoft Entra roles and Azure resource access roles, group memberships, access to enterprise applications. Microsoft Entra reporting can also provide logs to help discover stale accounts, accounts not being used for certain amount of time.
In addition, Microsoft Entra Privileged Identity Management can be configured to alert when an excessive number of administrator accounts are created for a specific role, and to identify administrator accounts that are stale or improperly configured.
**Implementation and additional context:**
Create an access review of Azure resource roles in Privileged Identity Management (PIM):
https://docs.microsoft.com/azure/active-directory/privileged-identity-management/pim-resource-roles-start-access-review
How to use Microsoft Entra identity and access reviews:
https://docs.microsoft.com/azure/active-directory/governance/access-reviews-overview
|
n/a |
link |
5 |
| CCCS |
AC-2 |
CCCS_AC-2 |
CCCS AC-2 |
Access Control |
Account Management |
|
n/a |
(A) The organization identifies and selects which types of information system accounts support organizational missions/business functions.
(B) The organization assigns account managers for information system accounts.
(C) The organization establishes conditions for group and role membership.
(D) The organization specifies authorized users of the information system, group and role membership, and access authorizations (i.e., privileges) and other attributes (as required) for each account.
(E) The organization requires approvals by responsible managers for requests to create information system accounts.
(F) The organization creates, enables, modifies, disables, and removes information system accounts in accordance with information system account management procedures.
(G) The organization monitors the use of information system accounts.
(H) The organization notifies account managers:
(a) When accounts are no longer required;
(b) When users are terminated or transferred; and
(c) When individual information system usage or need-to-know changes.
(I) The organization authorizes access to the information system based on:
(a) A valid access authorization;
(b) Intended system usage; and
(c) Other attributes as required by the organization or associated missions/business functions.
(J) The organization reviews accounts for compliance with account management requirements at least annually.
(K) The organization establishes a process for reissuing shared/group account credentials (if deployed) when individuals are removed from the group. |
link |
5 |
| CMMC_2.0_L2 |
AC.L1-3.1.1 |
CMMC_2.0_L2_AC.L1-3.1.1 |
404 not found |
|
|
|
n/a |
n/a |
|
57 |
| CMMC_2.0_L2 |
AC.L1-3.1.2 |
CMMC_2.0_L2_AC.L1-3.1.2 |
404 not found |
|
|
|
n/a |
n/a |
|
19 |
| CMMC_L3 |
AC.1.001 |
CMMC_L3_AC.1.001 |
CMMC L3 AC.1.001 |
Access Control |
Limit information system access to authorized users, processes acting on behalf of authorized users, and devices (including other information systems). |
Shared |
Microsoft and the customer share responsibilities for implementing this requirement. |
Access control policies (e.g., identity- or role-based policies, control matrices, and 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, and domains) in systems. Access enforcement mechanisms can be employed at the application and service level to provide increased information security. Other systems include systems internal and external to the organization. This requirement focuses on account management for systems and applications. The definition of and enforcement of access authorizations, other than those determined by account type (e.g., privileged verses non-privileged) are addressed in requirement AC.1.002. |
link |
31 |
| CMMC_L3 |
SC.3.181 |
CMMC_L3_SC.3.181 |
CMMC L3 SC.3.181 |
System and Communications Protection |
Separate user functionality from system management functionality. |
Shared |
Microsoft and the customer share responsibilities for implementing this requirement. |
System management functionality includes functions necessary to administer databases, network components, workstations, or servers, and typically requires privileged user access. The separation of user functionality from system management functionality is physical or logical. Organizations can implement separation of system management functionality from user functionality by using different computers, different central processing units, different instances of operating systems, or different network addresses; virtualization techniques; or combinations of these or other methods, as appropriate. This type of separation includes web administrative interfaces that use separate authentication methods for users of any other system resources. Separation of system and user functionality may include isolating administrative interfaces on different domains and with additional access controls. |
link |
6 |
| FedRAMP_High_R4 |
AC-2 |
FedRAMP_High_R4_AC-2 |
FedRAMP High AC-2 |
Access Control |
Account Management |
Shared |
n/a |
The organization:
a. Identifies and selects the following types of information system accounts to support organizational missions/business functions: [Assignment: organization-defined information system account types];
b. Assigns account managers for information system accounts;
c. Establishes conditions for group and role membership;
d. Specifies authorized users of the information system, group and role membership, and access authorizations (i.e., privileges) and other attributes (as required) for each account;
e. Requires approvals by [Assignment: organization-defined personnel or roles] for requests to create information system accounts;
f. Creates, enables, modifies, disables, and removes information system accounts in accordance with [Assignment: organization-defined procedures or conditions];
g. Monitors the use of, information system accounts;
h. Notifies account managers:
1. When accounts are no longer required;
2. When users are terminated or transferred; and
3. When individual information system usage or need-to-know changes;
i. Authorizes access to the information system based on:
1. A valid access authorization;
2. Intended system usage; and
3. Other attributes as required by the organization or associated missions/business functions;
j. Reviews accounts for compliance with account management requirements [Assignment: organization-defined frequency]; and
k. Establishes a process for reissuing shared/group account credentials (if deployed) when individuals are removed from the group.
Supplemental Guidance: Information system account types include individual, shared, group, system, guest/anonymous, emergency, developer/manufacturer/vendor, temporary, and service. Some of the account management requirements listed above can be implemented by organizational information systems. The identification of authorized users of the information system and the specification of access privileges reflects the requirements in other security controls in the security plan. Users requiring administrative privileges on information system accounts receive additional scrutiny by appropriate organizational personnel (e.g., system owner, mission/business owner, or chief information security officer) responsible for approving such accounts and privileged access. Organizations may choose to define access privileges or other attributes by account, by type of account, or a combination of both. Other attributes required for authorizing access include, for example, restrictions on time-of-day, day-of-week, and point-of-origin. In defining other account attributes, organizations consider system-related requirements (e.g., scheduled maintenance, system upgrades) and mission/business requirements, (e.g., time zone differences, customer requirements, remote access to support travel requirements). Failure to consider these factors could affect information system availability. Temporary and emergency accounts are accounts intended for short-term use. Organizations establish temporary accounts as a part of normal account activation procedures when there is a need for short-term accounts without the demand for immediacy in account activation. Organizations establish emergency accounts in response to crisis situations and with the need for rapid account activation. Therefore, emergency account activation may bypass normal account authorization processes. Emergency and temporary accounts are not to be confused with infrequently used accounts (e.g., local logon accounts used for special tasks defined by organizations or when network resources are unavailable). Such accounts remain available and are not subject to automatic disabling or removal dates. Conditions for disabling or deactivating accounts include, for example: (i) when shared/group, emergency, or temporary accounts are no longer required; or (ii) when individuals are transferred or terminated. Some types of information system accounts may require specialized training. Related controls: AC-3, AC-4, AC-5, AC-6, AC-10, AC-17, AC-19, AC-20, AU-9, IA-2, IA-4, IA-5, IA-8, CM-5, CM-6, CM-11, MA-3, MA-4, MA-5, PL-4, SC-13.
References: None. |
link |
25 |
| FedRAMP_Moderate_R4 |
AC-2 |
FedRAMP_Moderate_R4_AC-2 |
FedRAMP Moderate AC-2 |
Access Control |
Account Management |
Shared |
n/a |
The organization:
a. Identifies and selects the following types of information system accounts to support organizational missions/business functions: [Assignment: organization-defined information system account types];
b. Assigns account managers for information system accounts;
c. Establishes conditions for group and role membership;
d. Specifies authorized users of the information system, group and role membership, and access authorizations (i.e., privileges) and other attributes (as required) for each account;
e. Requires approvals by [Assignment: organization-defined personnel or roles] for requests to create information system accounts;
f. Creates, enables, modifies, disables, and removes information system accounts in accordance with [Assignment: organization-defined procedures or conditions];
g. Monitors the use of, information system accounts;
h. Notifies account managers:
1. When accounts are no longer required;
2. When users are terminated or transferred; and
3. When individual information system usage or need-to-know changes;
i. Authorizes access to the information system based on:
1. A valid access authorization;
2. Intended system usage; and
3. Other attributes as required by the organization or associated missions/business functions;
j. Reviews accounts for compliance with account management requirements [Assignment: organization-defined frequency]; and
k. Establishes a process for reissuing shared/group account credentials (if deployed) when individuals are removed from the group.
Supplemental Guidance: Information system account types include individual, shared, group, system, guest/anonymous, emergency, developer/manufacturer/vendor, temporary, and service. Some of the account management requirements listed above can be implemented by organizational information systems. The identification of authorized users of the information system and the specification of access privileges reflects the requirements in other security controls in the security plan. Users requiring administrative privileges on information system accounts receive additional scrutiny by appropriate organizational personnel (e.g., system owner, mission/business owner, or chief information security officer) responsible for approving such accounts and privileged access. Organizations may choose to define access privileges or other attributes by account, by type of account, or a combination of both. Other attributes required for authorizing access include, for example, restrictions on time-of-day, day-of-week, and point-of-origin. In defining other account attributes, organizations consider system-related requirements (e.g., scheduled maintenance, system upgrades) and mission/business requirements, (e.g., time zone differences, customer requirements, remote access to support travel requirements). Failure to consider these factors could affect information system availability. Temporary and emergency accounts are accounts intended for short-term use. Organizations establish temporary accounts as a part of normal account activation procedures when there is a need for short-term accounts without the demand for immediacy in account activation. Organizations establish emergency accounts in response to crisis situations and with the need for rapid account activation. Therefore, emergency account activation may bypass normal account authorization processes. Emergency and temporary accounts are not to be confused with infrequently used accounts (e.g., local logon accounts used for special tasks defined by organizations or when network resources are unavailable). Such accounts remain available and are not subject to automatic disabling or removal dates. Conditions for disabling or deactivating accounts include, for example: (i) when shared/group, emergency, or temporary accounts are no longer required; or (ii) when individuals are transferred or terminated. Some types of information system accounts may require specialized training. Related controls: AC-3, AC-4, AC-5, AC-6, AC-10, AC-17, AC-19, AC-20, AU-9, IA-2, IA-4, IA-5, IA-8, CM-5, CM-6, CM-11, MA-3, MA-4, MA-5, PL-4, SC-13.
References: None. |
link |
25 |
| 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 |
| IRS_1075_9.3 |
.1.2 |
IRS_1075_9.3.1.2 |
IRS 1075 9.3.1.2 |
Access Control |
Account Management (AC-2) |
|
n/a |
The agency must:
a. Identify and select the accounts with access to FTI to support agency missions/business functions
b. Assign account managers for information system accounts;
c. Establish conditions for group and role membership
d. Specify authorized users of the information system, group and role membership, and access authorizations (i.e., privileges) and other attributes (as required) for each account
e. Require approval for requests to create information system accounts
f. Create, enable, modify, disable, and remove information system accounts in accordance with documented agency account management procedures
g. Monitor the use of information system accounts
h. Notify account managers when accounts are no longer required, when users are terminated or transferred, or when individual information system usage or need- to-know permission changes
i. Authorize access to information systems that receive, process, store, or transmit FTI based on a valid access authorization, need-to-know permission, and under the authority to re-disclosed FTI under the provisions of IRC 6103
j. Review accounts for compliance with account management requirements at a
k. minimum of annually for user accounts and semi-annually for privileged accounts
l. Establish a process for reissuing shared/group account credentials (if deployed) when individuals are removed from the group.
The information system must automatically disable inactive accounts after 120 days of inactivity. (CE3) |
link |
9 |
| ISO27001-2013 |
A.9.2.5 |
ISO27001-2013_A.9.2.5 |
ISO 27001:2013 A.9.2.5 |
Access Control |
Review of user access rights |
Shared |
n/a |
Asset owners shall review users' access rights at regular intervals. |
link |
17 |
| ISO27001-2013 |
A.9.2.6 |
ISO27001-2013_A.9.2.6 |
ISO 27001:2013 A.9.2.6 |
Access Control |
Removal or adjustment of access rights |
Shared |
n/a |
The access rights of all employees and external party users to information and information processing facilities shall be removed upon termination of their employment, contract or agreement, or adjusted upon change. |
link |
17 |
| New_Zealand_ISM |
16.4.30.C.01 |
New_Zealand_ISM_16.4.30.C.01 |
New_Zealand_ISM_16.4.30.C.01 |
16. Access Control and Passwords |
16.4.30.C.01 Policy Creation and Implementation |
|
n/a |
Agencies MUST establish a Privileged Access Management (PAM) policy. |
|
6 |
| NIST_SP_800-171_R2_3 |
.1.1 |
NIST_SP_800-171_R2_3.1.1 |
NIST SP 800-171 R2 3.1.1 |
Access Control |
Limit system access to authorized users, processes acting on behalf of authorized users, and devices (including other systems). |
Shared |
Microsoft and the customer share responsibilities for implementing this requirement. |
Access control policies (e.g., identity- or role-based policies, control matrices, and 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, and domains) in systems. Access enforcement mechanisms can be employed at the application and service level to provide increased information security. Other systems include systems internal and external to the organization. This requirement focuses on account management for systems and applications. The definition of and enforcement of access authorizations, other than those determined by account type (e.g., privileged verses non-privileged) are addressed in requirement 3.1.2. |
link |
55 |
| 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-53_R4 |
AC-2 |
NIST_SP_800-53_R4_AC-2 |
NIST SP 800-53 Rev. 4 AC-2 |
Access Control |
Account Management |
Shared |
n/a |
The organization:
a. Identifies and selects the following types of information system accounts to support organizational missions/business functions: [Assignment: organization-defined information system account types];
b. Assigns account managers for information system accounts;
c. Establishes conditions for group and role membership;
d. Specifies authorized users of the information system, group and role membership, and access authorizations (i.e., privileges) and other attributes (as required) for each account;
e. Requires approvals by [Assignment: organization-defined personnel or roles] for requests to create information system accounts;
f. Creates, enables, modifies, disables, and removes information system accounts in accordance with [Assignment: organization-defined procedures or conditions];
g. Monitors the use of, information system accounts;
h. Notifies account managers:
1. When accounts are no longer required;
2. When users are terminated or transferred; and
3. When individual information system usage or need-to-know changes;
i. Authorizes access to the information system based on:
1. A valid access authorization;
2. Intended system usage; and
3. Other attributes as required by the organization or associated missions/business functions;
j. Reviews accounts for compliance with account management requirements [Assignment: organization-defined frequency]; and
k. Establishes a process for reissuing shared/group account credentials (if deployed) when individuals are removed from the group.
Supplemental Guidance: Information system account types include individual, shared, group, system, guest/anonymous, emergency, developer/manufacturer/vendor, temporary, and service. Some of the account management requirements listed above can be implemented by organizational information systems. The identification of authorized users of the information system and the specification of access privileges reflects the requirements in other security controls in the security plan. Users requiring administrative privileges on information system accounts receive additional scrutiny by appropriate organizational personnel (e.g., system owner, mission/business owner, or chief information security officer) responsible for approving such accounts and privileged access. Organizations may choose to define access privileges or other attributes by account, by type of account, or a combination of both. Other attributes required for authorizing access include, for example, restrictions on time-of-day, day-of-week, and point-of-origin. In defining other account attributes, organizations consider system-related requirements (e.g., scheduled maintenance, system upgrades) and mission/business requirements, (e.g., time zone differences, customer requirements, remote access to support travel requirements). Failure to consider these factors could affect information system availability. Temporary and emergency accounts are accounts intended for short-term use. Organizations establish temporary accounts as a part of normal account activation procedures when there is a need for short-term accounts without the demand for immediacy in account activation. Organizations establish emergency accounts in response to crisis situations and with the need for rapid account activation. Therefore, emergency account activation may bypass normal account authorization processes. Emergency and temporary accounts are not to be confused with infrequently used accounts (e.g., local logon accounts used for special tasks defined by organizations or when network resources are unavailable). Such accounts remain available and are not subject to automatic disabling or removal dates. Conditions for disabling or deactivating accounts include, for example: (i) when shared/group, emergency, or temporary accounts are no longer required; or (ii) when individuals are transferred or terminated. Some types of information system accounts may require specialized training. Related controls: AC-3, AC-4, AC-5, AC-6, AC-10, AC-17, AC-19, AC-20, AU-9, IA-2, IA-4, IA-5, IA-8, CM-5, CM-6, CM-11, MA-3, MA-4, MA-5, PL-4, SC-13.
References: None. |
link |
25 |
| NIST_SP_800-53_R5 |
AC-2 |
NIST_SP_800-53_R5_AC-2 |
NIST SP 800-53 Rev. 5 AC-2 |
Access Control |
Account Management |
Shared |
n/a |
a. Define and document the types of accounts allowed and specifically prohibited for use within the system;
b. Assign account managers;
c. Require [Assignment: organization-defined prerequisites and criteria] for group and role membership;
d. Specify:
1. Authorized users of the system;
2. Group and role membership; and
3. Access authorizations (i.e., privileges) and [Assignment: organization-defined attributes (as required)] for each account;
e. Require approvals by [Assignment: organization-defined personnel or roles] for requests to create accounts;
f. Create, enable, modify, disable, and remove accounts in accordance with [Assignment: organization-defined policy, procedures, prerequisites, and criteria];
g. Monitor the use of accounts;
h. Notify account managers and [Assignment: organization-defined personnel or roles] within:
1. [Assignment: organization-defined time period] when accounts are no longer required;
2. [Assignment: organization-defined time period] when users are terminated or transferred; and
3. [Assignment: organization-defined time period] when system usage or need-to-know changes for an individual;
i. Authorize access to the system based on:
1. A valid access authorization;
2. Intended system usage; and
3. [Assignment: organization-defined attributes (as required)];
j. Review accounts for compliance with account management requirements [Assignment: organization-defined frequency];
k. Establish and implement a process for changing shared or group account authenticators (if deployed) when individuals are removed from the group; and
l. Align account management processes with personnel termination and transfer processes. |
link |
25 |
| NL_BIO_Cloud_Theme |
U.07.3(2) |
NL_BIO_Cloud_Theme_U.07.3(2) |
NL_BIO_Cloud_Theme_U.07.3(2) |
U.07 Data separation |
Management features |
|
n/a |
Isolation of CSC data is ensured by separating it at least logically from the data of other CSCs under all operating conditions. |
|
19 |
| NL_BIO_Cloud_Theme |
U.10.2(2) |
NL_BIO_Cloud_Theme_U.10.2(2) |
NL_BIO_Cloud_Theme_U.10.2(2) |
U.10 Access to IT services and data |
Users |
|
n/a |
Under the responsibility of the CSP, administrators shall be granted access: to data with the least privilege principle; to data with the need-to-know principle; with multi-factor authentication; to data and application functions via technical measures. |
|
25 |
| NL_BIO_Cloud_Theme |
U.10.3(2) |
NL_BIO_Cloud_Theme_U.10.3(2) |
NL_BIO_Cloud_Theme_U.10.3(2) |
U.10 Access to IT services and data |
Users |
|
n/a |
Only users with authenticated equipment can access IT services and data. |
|
32 |
| NL_BIO_Cloud_Theme |
U.10.5(2) |
NL_BIO_Cloud_Theme_U.10.5(2) |
NL_BIO_Cloud_Theme_U.10.5(2) |
U.10 Access to IT services and data |
Competent |
|
n/a |
Under the responsibility of the CSP, privileges (system authorisations) for users are granted through formal procedures. |
|
25 |
| NZ_ISM_v3.5 |
AC-5 |
NZ_ISM_v3.5_AC-5 |
NZISM Security Benchmark AC-5 |
Access Control and Passwords |
16.1.46 Suspension of access |
Customer |
n/a |
Locking a system user account after a specified number of failed logon attempts will reduce the risk of brute force attacks.
Removing a system user account when it is no longer required will prevent personnel from accessing their old account and reduce the number of accounts that an attacker can target.
Suspending inactive accounts after a specified number of days will reduce the number of accounts that an attacker can target.
Investigating repeated account lockouts will reduce the security risk of any ongoing brute force logon attempts and allow security management to act accordingly. |
link |
2 |
| NZISM_Security_Benchmark_v1.1 |
AC-5 |
NZISM_Security_Benchmark_v1.1_AC-5 |
NZISM Security Benchmark AC-5 |
Access Control and Passwords |
16.1.46 Suspension of access |
Customer |
Agencies SHOULD:
lock system user accounts after three failed logon attempts;
have a system administrator reset locked accounts;
remove or suspend system user accounts as soon as possible when personnel no longer need access due to changing roles or leaving the agency; and
remove or suspend inactive accounts after a specified number of days. |
Locking a system user account after a specified number of failed logon attempts will reduce the risk of brute force attacks.
Removing a system user account when it is no longer required will prevent personnel from accessing their old account and reduce the number of accounts that an attacker can target.
Suspending inactive accounts after a specified number of days will reduce the number of accounts that an attacker can target.
Investigating repeated account lockouts will reduce the security risk of any ongoing brute force logon attempts and allow security management to act accordingly. |
link |
2 |
|
op.acc.1 Identification |
op.acc.1 Identification |
404 not found |
|
|
|
n/a |
n/a |
|
66 |
|
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.acc.5 Authentication mechanism (external users) |
op.acc.5 Authentication mechanism (external users) |
404 not found |
|
|
|
n/a |
n/a |
|
72 |
| PCI_DSS_V3.2.1 |
8.1.2 |
PCI_DSS_v3.2.1_8.1.2 |
PCI DSS v3.2.1 8.1.2 |
Requirement 8 |
PCI DSS requirement 8.1.2 |
customer |
n/a |
n/a |
link |
5 |
| PCI_DSS_V3.2.1 |
8.1.3 |
PCI_DSS_v3.2.1_8.1.3 |
PCI DSS v3.2.1 8.1.3 |
Requirement 8 |
PCI DSS requirement 8.1.3 |
customer |
n/a |
n/a |
link |
2 |
| PCI_DSS_V3.2.1 |
8.1.5 |
PCI_DSS_v3.2.1_8.1.5 |
PCI DSS v3.2.1 8.1.5 |
Requirement 8 |
PCI DSS requirement 8.1.5 |
shared |
n/a |
n/a |
link |
5 |
| PCI_DSS_v4.0 |
8.2.4 |
PCI_DSS_v4.0_8.2.4 |
PCI DSS v4.0 8.2.4 |
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 |
Addition, deletion, and modification of user IDs, authentication factors, and other identifier objects are managed as follows:
• Authorized with the appropriate approval.
• Implemented with only the privileges specified on the documented approval. |
link |
7 |
| PCI_DSS_v4.0 |
8.2.5 |
PCI_DSS_v4.0_8.2.5 |
PCI DSS v4.0 8.2.5 |
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 |
Access for terminated users is immediately revoked. |
link |
2 |
| PCI_DSS_v4.0 |
8.2.7 |
PCI_DSS_v4.0_8.2.7 |
PCI DSS v4.0 8.2.7 |
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 |
Accounts used by third parties to access, support, or maintain system components via remote access are managed as follows:
• Enabled only during the time period needed and disabled when not in use.
• Use is monitored for unexpected activity. |
link |
6 |
| RBI_CSF_Banks_v2016 |
8.1 |
RBI_CSF_Banks_v2016_8.1 |
|
User Access Control / Management |
User Access Control / Management-8.1 |
|
n/a |
Provide secure access to the bank???s assets/services from within/outside bank???s
network by protecting data/information at rest (e.g. using encryption, if supported by
the device) and in-transit (e.g. using technologies such as VPN or other secure web
protocols, etc.) |
|
10 |
| RBI_CSF_Banks_v2016 |
8.2 |
RBI_CSF_Banks_v2016_8.2 |
|
User Access Control / Management |
User Access Control / Management-8.2 |
|
n/a |
Carefully protect customer access credentials such as logon userid, authentication information and tokens, access profiles, etc. against leakage/attacks |
|
7 |
| RBI_CSF_Banks_v2016 |
8.3 |
RBI_CSF_Banks_v2016_8.3 |
|
User Access Control / Management |
User Access Control / Management-8.3 |
|
n/a |
Disallow administrative rights on end-user workstations/PCs/laptops and provide access rights on a need to know basis and for specific duration when it is required following an established process. |
|
5 |
| RBI_CSF_Banks_v2016 |
8.5 |
RBI_CSF_Banks_v2016_8.5 |
|
User Access Control / Management |
User Access Control / Management-8.5 |
|
n/a |
Implement appropriate (e.g. centralised) systems and controls to allow, manage, log and monitor privileged/superuser/administrative access to critical systems (Servers/OS/DB, applications, network devices etc.). |
|
12 |
| RBI_ITF_NBFC_v2017 |
3.1.a |
RBI_ITF_NBFC_v2017_3.1.a |
RBI IT Framework 3.1.a |
Information and Cyber Security |
Identification and Classification of Information Assets-3.1 |
|
n/a |
The IS Policy must provide for a IS framework with the following basic tenets:
Identification and Classification of Information Assets. NBFCs shall maintain detailed inventory of Information Asset with distinct and clear identification of the asset. |
link |
7 |
| RBI_ITF_NBFC_v2017 |
3.1.c |
RBI_ITF_NBFC_v2017_3.1.c |
RBI IT Framework 3.1.c |
Information and Cyber Security |
Role based Access Control-3.1 |
|
n/a |
The IS Policy must provide for a IS framework with the following basic tenets:
Role based Access Control ??? Access to information should be based on well-defined user roles (system administrator, user manager, application owner etc.), NBFCs shall avoid dependence on one or few persons for a particular job. There should be clear delegation of authority for right to upgrade/change user profiles and permissions and also key business parameters (eg. interest rates) which should be documented. |
link |
15 |
| RBI_ITF_NBFC_v2017 |
3.1.f |
RBI_ITF_NBFC_v2017_3.1.f |
RBI IT Framework 3.1.f |
Information and Cyber Security |
Maker-checker-3.1 |
|
n/a |
The IS Policy must provide for a IS framework with the following basic tenets:
Maker-checker is one of the important principles of authorization in the information systems of financial entities. For each transaction, there must be at least two individuals necessary for its completion as this will reduce the risk of error and will ensure reliability of information. |
link |
23 |
| RMiT_v1.0 |
10.54 |
RMiT_v1.0_10.54 |
RMiT 10.54 |
Access Control |
Access Control - 10.54 |
Shared |
n/a |
A financial institution must implement an appropriate access controls policy for the identification, authentication and authorisation of users (internal and external users such as third party service providers). This must address both logical and physical technology access controls which are commensurate with the level of risk of unauthorised access to its technology systems. |
link |
17 |
| RMiT_v1.0 |
10.61 |
RMiT_v1.0_10.61 |
RMiT 10.61 |
Access Control |
Access Control - 10.61 |
Shared |
n/a |
A financial institution must ensure'
(a) access controls to enterprise-wide systems are effectively managed and monitored; and
(b) user activities in critical systems are logged for audit and investigations. Activity logs must be maintained for at least three years and regularly reviewed in a timely manner. |
link |
8 |
| SOC_2 |
CC5.2 |
SOC_2_CC5.2 |
SOC 2 Type 2 CC5.2 |
Control Activities |
COSO Principle 11 |
Shared |
The customer is responsible for implementing this recommendation. |
• Determines Dependency Between the Use of Technology in Business Processes and
Technology General Controls — Management understands and determines the dependency and linkage between business processes, automated control activities, and
technology general controls.
• Establishes Relevant Technology Infrastructure Control Activities — Management
selects and develops control activities over the technology infrastructure, which are
designed and implemented to help ensure the completeness, accuracy, and availability of technology processing.
• Establishes Relevant Security Management Process Controls Activities — Management selects and develops control activities that are designed and implemented
to restrict technology access rights to authorized users commensurate with their job
responsibilities and to protect the entity’s assets from external threats.
• Establishes Relevant Technology Acquisition, Development, and Maintenance Process Control Activities — Management selects and develops control activities over the acquisition, development and maintenance of technology and its infrastructure to achieve management's objectives. |
|
18 |
| 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 |
| SOC_2 |
CC6.3 |
SOC_2_CC6.3 |
SOC 2 Type 2 CC6.3 |
Logical and Physical Access Controls |
Rol based access and least privilege |
Shared |
The customer is responsible for implementing this recommendation. |
• Creates or Modifies Access to Protected Information Assets — Processes are in
place to create or modify access to protected information assets based on authorization from the asset’s owner.
• Removes Access to Protected Information Assets — Processes are in place to remove access to protected information assets when an individual no longer requires
access.
• Uses Role-Based Access Controls — Role-based access control is utilized to support segregation of incompatible functions.
• Reviews Access Roles and Rules — The appropriateness of access roles and access
rules is reviewed on a periodic basis for unnecessary and inappropriate individuals
with access and access rules are modified as appropriate |
|
20 |
| SWIFT_CSCF_v2021 |
1.2 |
SWIFT_CSCF_v2021_1.2 |
SWIFT CSCF v2021 1.2 |
SWIFT Environment Protection |
Operating System Privileged Account Control |
|
n/a |
Restrict and control the allocation and usage of administrator-level operating system accounts. |
link |
12 |
| SWIFT_CSCF_v2021 |
5.1 |
SWIFT_CSCF_v2021_5.1 |
SWIFT CSCF v2021 5.1 |
Manage Identities and Segregate Privileges |
Logical Access Control |
|
n/a |
Enforce the security principles of need-to-know access, least privilege, and segregation of duties for operator accounts. |
link |
7 |
| SWIFT_CSCF_v2022 |
1.2 |
SWIFT_CSCF_v2022_1.2 |
SWIFT CSCF v2022 1.2 |
1. Restrict Internet Access & Protect Critical Systems from General IT Environment |
Restrict and control the allocation and usage of administrator-level operating system accounts. |
Shared |
n/a |
Access to administrator-level operating system accounts is restricted to the maximum extent possible. Usage is controlled, monitored, and only permitted for relevant activities such as software installation and configuration, maintenance, and emergency activities. At all other times, an account with the least privilege access is used. |
link |
22 |
| SWIFT_CSCF_v2022 |
5.1 |
SWIFT_CSCF_v2022_5.1 |
SWIFT CSCF v2022 5.1 |
5. Manage Identities and Segregate Privileges |
Enforce the security principles of need-to-know access, least privilege, and separation of duties for operator accounts. |
Shared |
n/a |
Accounts are defined according to the security principles of need-to-know access, least privilege, and separation of duties. |
link |
35 |
|
U.07.3 - Management features |
U.07.3 - Management features |
404 not found |
|
|
|
n/a |
n/a |
|
19 |
|
U.10.2 - Users |
U.10.2 - Users |
404 not found |
|
|
|
n/a |
n/a |
|
25 |
|
U.10.3 - Users |
U.10.3 - Users |
404 not found |
|
|
|
n/a |
n/a |
|
26 |
|
U.10.5 - Competent |
U.10.5 - Competent |
404 not found |
|
|
|
n/a |
n/a |
|
24 |
| UK_NCSC_CSP |
10 |
UK_NCSC_CSP_10 |
UK NCSC CSP 10 |
Identity and authentication |
Identity and authentication |
Shared |
n/a |
All access to service interfaces should be constrained to authenticated and authorised individuals. |
link |
25 |