last sync: 2025-Feb-10 21:12:28 UTC

App Service apps should use managed identity

Azure BuiltIn Policy definition

Source Azure Portal
Display name App Service apps should use managed identity
Id 2b9ad585-36bc-4615-b300-fd4435808332
Version 3.0.0
Details on versioning
Versioning Versions supported for Versioning: 1
3.0.0
Built-in Versioning [Preview]
Category App Service
Microsoft Learn
Description Use a managed identity for enhanced authentication security
Cloud environments AzureCloud = true
AzureUSGovernment = unknown
AzureChinaCloud = unknown
Available in AzUSGov Unknown, no evidence if Policy definition is/not available in AzureUSGovernment
Mode Indexed
Type BuiltIn
Preview False
Deprecated False
Effect Default
AuditIfNotExists
Allowed
AuditIfNotExists, Disabled
RBAC role(s) none
Rule aliases THEN-ExistenceCondition (2)
Alias Namespace ResourceType Path PathIsDefault DefaultPath Modifiable
Microsoft.Web/sites/config/managedServiceIdentityId Microsoft.Web sites/config properties.managedServiceIdentityId True False
Microsoft.Web/sites/config/xmanagedServiceIdentityId Microsoft.Web sites/config properties.xManagedServiceIdentityId True False
Rule resource types IF (1)
Microsoft.Web/sites
Compliance
The following 78 compliance controls are associated with this Policy definition 'App Service apps should use managed identity' (2b9ad585-36bc-4615-b300-fd4435808332)
Control Domain Control Name MetadataId Category Title Owner Requirements Description Info Policy#
Azure_Security_Benchmark_v1.0 7.12 Azure_Security_Benchmark_v1.0_7.12 Azure Security Benchmark 7.12 Secure Configuration Manage identities securely and automatically Customer Use Managed Identities to provide Azure services with an automatically managed identity in Microsoft Entra ID. Managed Identities allows you to authenticate to any service that supports Microsoft Entra authentication, including Key Vault, without any credentials in your code. How to configure Managed Identities: https://docs.microsoft.com/azure/active-directory/managed-identities-azure-resources/qs-configure-portal-windows-vm n/a link 2
Azure_Security_Benchmark_v2.0 IM-1 Azure_Security_Benchmark_v2.0_IM-1 Azure Security Benchmark IM-1 Identity Management Standardize Microsoft Entra ID as the central identity and authentication system Customer Microsoft Entra ID is Azure's default identity and access management service. You should standardize on Microsoft Entra ID to govern your organization’s identity and access management in: - Microsoft cloud resources, such as the Azure portal, Azure Storage, Azure Virtual Machines (Linux and Windows), Azure Key Vault, PaaS, and SaaS applications. - Your organization's resources, such as applications on Azure or your corporate network resources. Securing Microsoft Entra ID should be a high priority in your organization’s cloud security practice. Microsoft Entra ID provides an identity secure score to help you assess your identity security posture relative to Microsoft’s best practice recommendations. Use the score to gauge how closely your configuration matches best practice recommendations, and to make improvements in your security posture. Note: Microsoft Entra ID supports external identity providers, which allow users without a Microsoft account to sign in to their applications and resources with their external identity. Tenancy in Microsoft Entra ID: https://docs.microsoft.com/azure/active-directory/develop/single-and-multi-tenant-apps How to create and configure a Microsoft Entra instance: https://docs.microsoft.com/azure/active-directory/fundamentals/active-directory-access-create-new-tenant Define Microsoft Entra tenants: https://azure.microsoft.com/resources/securing-azure-environments-with-azure-active-directory/ Use external identity providers for an application: https://docs.microsoft.com/azure/active-directory/b2b/identity-providers What is the identity secure score in Microsoft Entra ID: https://docs.microsoft.com/azure/active-directory/fundamentals/identity-secure-score n/a link 4
Azure_Security_Benchmark_v2.0 IM-2 Azure_Security_Benchmark_v2.0_IM-2 Azure Security Benchmark IM-2 Identity Management Manage application identities securely and automatically Customer For non-human accounts such as services or automation, use Azure managed identities, instead of creating a more powerful human account to access resources or execute code. Azure managed identities can authenticate to Azure services and resources that support Microsoft Entra authentication. Authentication is enabled through pre-defined access grant rules, avoiding hard-coded credentials in source code or configuration files. For services that do not support managed identities, use Microsoft Entra ID to create a service principal with restricted permissions at the resource level instead. It is recommended to configure service principals with certificate credentials and fall back to client secrets. In both cases, Azure Key Vault can be used in conjunction with Azure managed identities, so that the runtime environment (such as an Azure function) can retrieve the credential from the key vault. Azure managed identities: https://docs.microsoft.com/azure/active-directory/managed-identities-azure-resources/overview Services that support managed identities for Azure resources: https://docs.microsoft.com/azure/active-directory/managed-identities-azure-resources/services-support-managed-identities Azure service principal: https://docs.microsoft.com/powershell/azure/create-azure-service-principal-azureps Create a service principal with certificates: https://docs.microsoft.com/azure/active-directory/develop/howto-authenticate-service-principal-powershell Use Azure Key Vault for security principal registration: https://docs.microsoft.com/azure/key-vault/general/authentication#security-principal-registration n/a link 2
Azure_Security_Benchmark_v3.0 IM-3 Azure_Security_Benchmark_v3.0_IM-3 Microsoft cloud security benchmark IM-3 Identity Management Manage application identities securely and automatically Shared **Security Principle:** Use managed application identities instead of creating human accounts for applications to access resources and execute code. Managed application identities provide benefits such as reducing the exposure of credentials. Automate the rotation of credential to ensure the security of the identities. **Azure Guidance:** Use Azure managed identities, which can authenticate to Azure services and resources that support Microsoft Entra ID authentication. Managed identity credentials are fully managed, rotated, and protected by the platform, avoiding hard-coded credentials in source code or configuration files. For services that don't support managed identities, use Microsoft Entra ID to create a service principal with restricted permissions at the resource level. It is recommended to configure service principals with certificate credentials and fall back to client secrets for authentication. **Implementation and additional context:** Azure managed identities: https://docs.microsoft.com/azure/active-directory/managed-identities-azure-resources/overview Services that support managed identities for Azure resources: https://docs.microsoft.com/azure/active-directory/managed-identities-azure-resources/services-support-managed-identities Azure service principal: https://docs.microsoft.com/powershell/azure/create-azure-service-principal-azureps Create a service principal with certificates: https://docs.microsoft.com/azure/active-directory/develop/howto-authenticate-service-principal-powershell n/a link 3
CIS_Azure_1.1.0 9.5 CIS_Azure_1.1.0_9.5 CIS Microsoft Azure Foundations Benchmark recommendation 9.5 9 AppService Ensure that Register with Azure Active Directory is enabled on App Service Shared The customer is responsible for implementing this recommendation. Managed service identity in App Service makes the app more secure by eliminating secrets from the app, such as credentials in the connection strings. When registering with Azure Active Directory in the app service, the app will connect to other Azure services securely without the need of username and passwords. link 6
CIS_Azure_1.3.0 9.5 CIS_Azure_1.3.0_9.5 CIS Microsoft Azure Foundations Benchmark recommendation 9.5 9 AppService Ensure that Register with Azure Active Directory is enabled on App Service Shared The customer is responsible for implementing this recommendation. Managed service identity in App Service makes the app more secure by eliminating secrets from the app, such as credentials in the connection strings. When registering with Azure Active Directory in the app service, the app will connect to other Azure services securely without the need of username and passwords. link 6
CIS_Azure_1.4.0 9.5 CIS_Azure_1.4.0_9.5 CIS Microsoft Azure Foundations Benchmark recommendation 9.5 9 AppService Ensure that Register with Azure Active Directory is enabled on App Service Shared The customer is responsible for implementing this recommendation. Managed service identity in App Service makes the app more secure by eliminating secrets from the app, such as credentials in the connection strings. When registering with Azure Active Directory in the app service, the app will connect to other Azure services securely without the need of username and passwords. link 6
CIS_Azure_2.0.0 9.5 CIS_Azure_2.0.0_9.5 CIS Microsoft Azure Foundations Benchmark recommendation 9.5 9 Ensure that Register with Azure Active Directory is enabled on App Service Shared n/a Managed service identity in App Service provides more security by eliminating secrets from the app, such as credentials in the connection strings. When registering with Azure Active Directory in App Service, the app will connect to other Azure services securely without the need for usernames and passwords. App Service provides a highly scalable, self-patching web hosting service in Azure. It also provides a managed identity for apps, which is a turn-key solution for securing access to Azure SQL Database and other Azure services. link 6
CIS_Azure_Foundations_v2.1.0 9.4 CIS_Azure_Foundations_v2.1.0_9.4 CIS Azure Foundations v2.1.0 9.4 AppService Ensure that Register with Entra ID is enabled on App Service Shared n/a Ensure that Register with Entra ID is enabled on App Service. 1
CIS_Controls_v8.1 3.3 CIS_Controls_v8.1_3.3 CIS Controls v8.1 3.3 Data Protection Configure data access control lists Shared 1. Configure data access control lists based on a user’s need to know. 2. Apply data access control lists, also known as access permissions, to local and remote file systems, databases, and applications. To ensure that users have access only to the data necessary for their roles. 25
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 54
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 16
CMMC_2.0_L2 IA.L1-3.5.1 CMMC_2.0_L2_IA.L1-3.5.1 404 not found n/a n/a 5
CMMC_2.0_L2 IA.L1-3.5.2 CMMC_2.0_L2_IA.L1-3.5.2 404 not found n/a n/a 15
CMMC_2.0_L2 IA.L2-3.5.5 CMMC_2.0_L2_IA.L2-3.5.5 404 not found n/a n/a 5
CMMC_2.0_L2 IA.L2-3.5.6 CMMC_2.0_L2_IA.L2-3.5.6 404 not found n/a n/a 6
CMMC_L2_v1.9.0 AC.L2_3.1.7 CMMC_L2_v1.9.0_AC.L2_3.1.7 Cybersecurity Maturity Model Certification (CMMC) Level 2 v1.9.0 AC.L2 3.1.7 Access Control Privileged Functions Shared Prevent non privileged users from executing privileged functions and capture the execution of such functions in audit logs. To restrict information system access. 4
Cyber_Essentials_v3.1 2 Cyber_Essentials_v3.1_2 Cyber Essentials v3.1 2 Cyber Essentials Secure Configuration Shared n/a Aim: ensure that computers and network devices are properly configured to reduce vulnerabilities and provide only the services required to fulfill their role. 61
Cyber_Essentials_v3.1 5 Cyber_Essentials_v3.1_5 Cyber Essentials v3.1 5 Cyber Essentials Malware protection Shared n/a Aim: to restrict execution of known malware and untrusted software, from causing damage or accessing data. 60
EU_GDPR_2016_679_Art. 24 EU_GDPR_2016_679_Art._24 EU General Data Protection Regulation (GDPR) 2016/679 Art. 24 Chapter 4 - Controller and processor Responsibility of the controller Shared n/a n/a 311
EU_GDPR_2016_679_Art. 25 EU_GDPR_2016_679_Art._25 EU General Data Protection Regulation (GDPR) 2016/679 Art. 25 Chapter 4 - Controller and processor Data protection by design and by default Shared n/a n/a 311
EU_GDPR_2016_679_Art. 28 EU_GDPR_2016_679_Art._28 EU General Data Protection Regulation (GDPR) 2016/679 Art. 28 Chapter 4 - Controller and processor Processor Shared n/a n/a 311
EU_GDPR_2016_679_Art. 32 EU_GDPR_2016_679_Art._32 EU General Data Protection Regulation (GDPR) 2016/679 Art. 32 Chapter 4 - Controller and processor Security of processing Shared n/a n/a 311
FBI_Criminal_Justice_Information_Services_v5.9.5_5 .5 FBI_Criminal_Justice_Information_Services_v5.9.5_5.5 FBI Criminal Justice Information Services (CJIS) v5.9.5 5.5 Policy and Implementation - Access Control Access Control Shared Refer to Section 5.13.6 for additional access control requirements related to mobile devices used to access CJI. Access control provides the planning and implementation of mechanisms to restrict reading, writing, processing, and transmission of CJIS information and the modification of information systems, applications, services and communication configurations allowing access to CJIS information. 97
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_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 18
FedRAMP_High_R4 IA-2 FedRAMP_High_R4_IA-2 FedRAMP High IA-2 Identification And Authentication Identification And Authentication (Organizational Users) Shared n/a The information system uniquely identifies and authenticates organizational users (or processes acting on behalf of organizational users). Supplemental Guidance: Organizational users include employees or individuals that organizations deem to have equivalent status of employees (e.g., contractors, guest researchers). This control applies to all accesses other than: (i) accesses that are explicitly identified and documented in AC-14; and (ii) accesses that occur through authorized use of group authenticators without individual authentication. Organizations may require unique identification of individuals in group accounts (e.g., shared privilege accounts) or for detailed accountability of individual activity. Organizations employ passwords, tokens, or biometrics to authenticate user identities, or in the case multifactor authentication, or some combination thereof. Access to organizational information systems is defined as either local access or network access. Local access is any access to organizational information systems by users (or processes acting on behalf of users) where such access is obtained by direct connections without the use of networks. Network access is access to organizational information systems by users (or processes acting on behalf of users) where such access is obtained through network connections (i.e., nonlocal accesses). Remote access is a type of network access that involves communication through external networks (e.g., the Internet). Internal networks include local area networks and wide area networks. In addition, the use of encrypted virtual private networks (VPNs) for network connections between organization- controlled endpoints and non-organization controlled endpoints may be treated as internal networks from the perspective of protecting the confidentiality and integrity of information traversing the network. Organizations can satisfy the identification and authentication requirements in this control by complying with the requirements in Homeland Security Presidential Directive 12 consistent with the specific organizational implementation plans. Multifactor authentication requires the use of two or more different factors to achieve authentication. The factors are defined as: (i) something you know (e.g., password, personal identification number [PIN]); (ii) something you have (e.g., cryptographic identification device, token); or (iii) something you are (e.g., biometric). Multifactor solutions that require devices separate from information systems gaining access include, for example, hardware tokens providing time-based or challenge-response authenticators and smart cards such as the U.S. Government Personal Identity Verification card and the DoD common access card. In addition to identifying and authenticating users at the information system level (i.e., at logon), organizations also employ identification and authentication mechanisms at the application level, when necessary, to provide increased information security. Identification and authentication requirements for other than organizational users are described in IA-8. Related controls: AC-2, AC-3, AC-14, AC-17, AC-18, IA-4, IA-5, IA-8. References: HSPD-12; OMB Memoranda 04-04, 06-16, 11-11; FIPS Publication 201; NIST Special Publications 800-63, 800-73, 800-76, 800-78; FICAM Roadmap and Implementation Guidance; Web: http://idmanagement.gov. link 7
FedRAMP_High_R4 IA-4 FedRAMP_High_R4_IA-4 FedRAMP High IA-4 Identification And Authentication Identifier Management Shared n/a The organization manages information system identifiers by: a. Receiving authorization from [Assignment: organization-defined personnel or roles] to assign an individual, group, role, or device identifier; b. Selecting an identifier that identifies an individual, group, role, or device; c. Assigning the identifier to the intended individual, group, role, or device; d. Preventing reuse of identifiers for [Assignment: organization-defined time period]; and e. Disabling the identifier after [Assignment: organization-defined time period of inactivity]. Supplemental Guidance: Common device identifiers include, for example, media access control (MAC), Internet protocol (IP) addresses, or device-unique token identifiers. Management of individual identifiers is not applicable to shared information system accounts (e.g., guest and anonymous accounts). Typically, individual identifiers are the user names of the information system accounts assigned to those individuals. In such instances, the account management activities of AC-2 use account names provided by IA-4. This control also addresses individual identifiers not necessarily associated with information system accounts (e.g., identifiers used in physical security control databases accessed by badge reader systems for access to information systems). Preventing reuse of identifiers implies preventing the assignment of previously used individual, group, role, or device identifiers to different individuals, groups, roles, or devices. Related controls: AC-2, IA-2, IA-3, IA-5, IA-8, SC-37. References: FIPS Publication 201; NIST Special Publications 800-73, 800-76, 800-78. link 7
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
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 18
FedRAMP_Moderate_R4 IA-2 FedRAMP_Moderate_R4_IA-2 FedRAMP Moderate IA-2 Identification And Authentication Identification And Authentication (Organizational Users) Shared n/a The information system uniquely identifies and authenticates organizational users (or processes acting on behalf of organizational users). Supplemental Guidance: Organizational users include employees or individuals that organizations deem to have equivalent status of employees (e.g., contractors, guest researchers). This control applies to all accesses other than: (i) accesses that are explicitly identified and documented in AC-14; and (ii) accesses that occur through authorized use of group authenticators without individual authentication. Organizations may require unique identification of individuals in group accounts (e.g., shared privilege accounts) or for detailed accountability of individual activity. Organizations employ passwords, tokens, or biometrics to authenticate user identities, or in the case multifactor authentication, or some combination thereof. Access to organizational information systems is defined as either local access or network access. Local access is any access to organizational information systems by users (or processes acting on behalf of users) where such access is obtained by direct connections without the use of networks. Network access is access to organizational information systems by users (or processes acting on behalf of users) where such access is obtained through network connections (i.e., nonlocal accesses). Remote access is a type of network access that involves communication through external networks (e.g., the Internet). Internal networks include local area networks and wide area networks. In addition, the use of encrypted virtual private networks (VPNs) for network connections between organization- controlled endpoints and non-organization controlled endpoints may be treated as internal networks from the perspective of protecting the confidentiality and integrity of information traversing the network. Organizations can satisfy the identification and authentication requirements in this control by complying with the requirements in Homeland Security Presidential Directive 12 consistent with the specific organizational implementation plans. Multifactor authentication requires the use of two or more different factors to achieve authentication. The factors are defined as: (i) something you know (e.g., password, personal identification number [PIN]); (ii) something you have (e.g., cryptographic identification device, token); or (iii) something you are (e.g., biometric). Multifactor solutions that require devices separate from information systems gaining access include, for example, hardware tokens providing time-based or challenge-response authenticators and smart cards such as the U.S. Government Personal Identity Verification card and the DoD common access card. In addition to identifying and authenticating users at the information system level (i.e., at logon), organizations also employ identification and authentication mechanisms at the application level, when necessary, to provide increased information security. Identification and authentication requirements for other than organizational users are described in IA-8. Related controls: AC-2, AC-3, AC-14, AC-17, AC-18, IA-4, IA-5, IA-8. References: HSPD-12; OMB Memoranda 04-04, 06-16, 11-11; FIPS Publication 201; NIST Special Publications 800-63, 800-73, 800-76, 800-78; FICAM Roadmap and Implementation Guidance; Web: http://idmanagement.gov. link 7
FedRAMP_Moderate_R4 IA-4 FedRAMP_Moderate_R4_IA-4 FedRAMP Moderate IA-4 Identification And Authentication Identifier Management Shared n/a The organization manages information system identifiers by: a. Receiving authorization from [Assignment: organization-defined personnel or roles] to assign an individual, group, role, or device identifier; b. Selecting an identifier that identifies an individual, group, role, or device; c. Assigning the identifier to the intended individual, group, role, or device; d. Preventing reuse of identifiers for [Assignment: organization-defined time period]; and e. Disabling the identifier after [Assignment: organization-defined time period of inactivity]. Supplemental Guidance: Common device identifiers include, for example, media access control (MAC), Internet protocol (IP) addresses, or device-unique token identifiers. Management of individual identifiers is not applicable to shared information system accounts (e.g., guest and anonymous accounts). Typically, individual identifiers are the user names of the information system accounts assigned to those individuals. In such instances, the account management activities of AC-2 use account names provided by IA-4. This control also addresses individual identifiers not necessarily associated with information system accounts (e.g., identifiers used in physical security control databases accessed by badge reader systems for access to information systems). Preventing reuse of identifiers implies preventing the assignment of previously used individual, group, role, or device identifiers to different individuals, groups, roles, or devices. Related controls: AC-2, IA-2, IA-3, IA-5, IA-8, SC-37. References: FIPS Publication 201; NIST Special Publications 800-73, 800-76, 800-78. link 7
FFIEC_CAT_2017 3.1.2 FFIEC_CAT_2017_3.1.2 FFIEC CAT 2017 3.1.2 Cybersecurity Controls Access and Data Management Shared n/a Employee access is granted to systems and confidential data based on job responsibilities and the principles of least privilege.'FFIEC_Cybersecurity Control'!F8 - Employee access to systems and confidential data provides for separation of duties. - Elevated privileges (e.g., administrator privileges) are limited and tightly controlled (e.g., assigned to individuals, not shared, and require stronger 'FFIEC_Cybersecurity Control'!F7password controls). - User access reviews are performed periodically for all systems and applications based on the risk to the application or system. - Changes to physical and logical user access, including those that result from voluntary and involuntary terminations, are submitted to and approved by appropriate personnel. - Identification and authentication are required and managed for access to systems, applications, and hardware. - Access controls include password complexity and limits to password attempts and reuse. - All default passwords and unnecessary default accounts are changed before system implementation. - Customer access to Internet-based products or services requires authentication controls (e.g., layered controls, multifactor) that are commensurate with the risk. - Production and non-production environments are segregated to prevent unauthorized access or changes to information assets. (*N/A if no production environment exists at the institution or the institution’s third party.) - Physical security controls are used to prevent unauthorized access to information systems and telecommunication systems. - All passwords are encrypted in storage and in transit. - Confidential data are encrypted when transmitted across public or untrusted networks (e.g., Internet). - Mobile devices (e.g., laptops, tablets, and removable media) are encrypted if used to store confidential data. (*N/A if mobile devices are not used.) - Remote access to critical systems by employees, contractors, and third parties uses encrypted connections and multifactor authentication. - Administrative, physical, or technical controls are in place to prevent users without administrative responsibilities from installing unauthorized software. - Customer service (e.g., the call center) utilizes formal procedures to authenticate customers commensurate with the risk of the transaction or request. - Data is disposed of or destroyed according to documented requirements and within expected time frames. 59
HITRUST_CSF_v11.3 01.c HITRUST_CSF_v11.3_01.c HITRUST CSF v11.3 01.c Authorized Access to Information Systems To control privileged access to information systems and services. Shared 1. Privileged role assignments to be automatically tracked and monitored. 2. Role-based access controls to be implemented and should be capable of mapping each user to one or more roles, and each role to one or more system functions. 3. Critical security functions to be executable only after granting of explicit authorization. The allocation and use of privileges to information systems and services shall be restricted and controlled. Special attention shall be given to the allocation of privileged access rights, which allow users to override system controls. 44
New_Zealand_ISM 16.1.32.C.01 New_Zealand_ISM_16.1.32.C.01 New_Zealand_ISM_16.1.32.C.01 16. Access Control and Passwords 16.1.32.C.01 System user identification n/a Agencies MUST ensure that all system users are: uniquely identifiable; and authenticated on each occasion that access is granted to a system. 18
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 52
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 28
NIST_SP_800-171_R2_3 .5.1 NIST_SP_800-171_R2_3.5.1 NIST SP 800-171 R2 3.5.1 Identification and Authentication Identify system users, processes acting on behalf of users, and devices. Shared Microsoft and the customer share responsibilities for implementing this requirement. Common device identifiers include Media Access Control (MAC), Internet Protocol (IP) addresses, or device-unique token identifiers. Management of individual identifiers is not applicable to shared system accounts. Typically, individual identifiers are the user names associated with the system accounts assigned to those individuals. Organizations may require unique identification of individuals in group accounts or for detailed accountability of individual activity. In addition, this requirement addresses individual identifiers that are not necessarily associated with system accounts. Organizational devices requiring identification may be defined by type, by device, or by a combination of type/device. [SP 800-63-3] provides guidance on digital identities. link 9
NIST_SP_800-171_R2_3 .5.2 NIST_SP_800-171_R2_3.5.2 NIST SP 800-171 R2 3.5.2 Identification and Authentication Authenticate (or verify) the identities of users, processes, or devices, as a prerequisite to allowing access to organizational systems. Shared Microsoft and the customer share responsibilities for implementing this requirement. Individual authenticators include the following: passwords, key cards, cryptographic devices, and one-time password devices. Initial authenticator content is the actual content of the authenticator, for example, the initial password. In contrast, the requirements about authenticator content include the minimum password length. Developers ship system components with factory default authentication credentials to allow for initial installation and configuration. Default authentication credentials are often well known, easily discoverable, and present a significant security risk. Systems support authenticator management by organization-defined settings and restrictions for various authenticator characteristics including minimum password length, validation time window for time synchronous one-time tokens, and number of allowed rejections during the verification stage of biometric authentication. Authenticator management includes issuing and revoking, when no longer needed, authenticators for temporary access such as that required for remote maintenance. Device authenticators include certificates and passwords. [SP 800-63-3] provides guidance on digital identities. link 21
NIST_SP_800-171_R2_3 .5.5 NIST_SP_800-171_R2_3.5.5 NIST SP 800-171 R2 3.5.5 Identification and Authentication Prevent reuse of identifiers for a defined period. Shared Microsoft and the customer share responsibilities for implementing this requirement. Identifiers are provided for users, processes acting on behalf of users, or devices (3.5.1). Preventing reuse of identifiers implies preventing the assignment of previously used individual, group, role, or device identifiers to different individuals, groups, roles, or devices. link 6
NIST_SP_800-171_R2_3 .5.6 NIST_SP_800-171_R2_3.5.6 NIST SP 800-171 R2 3.5.6 Identification and Authentication Disable identifiers after a defined period of inactivity. Shared Microsoft and the customer share responsibilities for implementing this requirement. Inactive identifiers pose a risk to organizational information because attackers may exploit an inactive identifier to gain undetected access to organizational devices. The owners of the inactive accounts may not notice if unauthorized access to the account has been obtained. link 6
NIST_SP_800-171_R3_3 .1.7 NIST_SP_800-171_R3_3.1.7 NIST 800-171 R3 3.1.7 Access Control Least Privilege – Privileged Functions Shared Privileged functions include establishing system accounts, performing system integrity checks, conducting patching operations, or administering cryptographic key management activities. Non-privileged users do not possess the appropriate authorizations to execute privileged functions. Circumventing intrusion detection and prevention mechanisms or malicious code protection mechanisms are examples of privileged functions that require protection from non-privileged users. This requirement represents a condition to be achieved by the definition of authorized privileges in 03.01.01 and the enforcement of those privileges in 03.01.02. The misuse of privileged functions – whether intentionally or unintentionally by authorized users or by unauthorized external entities that have compromised system accounts – is a serious and ongoing concern that can have significant adverse impacts on organizations. Logging the use of privileged functions is one way to detect such misuse and mitigate the risks from insider threats and advanced persistent threats a. Prevent non-privileged users from executing privileged functions. b. Log the execution of privileged functions. 3
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_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 18
NIST_SP_800-53_R4 IA-2 NIST_SP_800-53_R4_IA-2 NIST SP 800-53 Rev. 4 IA-2 Identification And Authentication Identification And Authentication (Organizational Users) Shared n/a The information system uniquely identifies and authenticates organizational users (or processes acting on behalf of organizational users). Supplemental Guidance: Organizational users include employees or individuals that organizations deem to have equivalent status of employees (e.g., contractors, guest researchers). This control applies to all accesses other than: (i) accesses that are explicitly identified and documented in AC-14; and (ii) accesses that occur through authorized use of group authenticators without individual authentication. Organizations may require unique identification of individuals in group accounts (e.g., shared privilege accounts) or for detailed accountability of individual activity. Organizations employ passwords, tokens, or biometrics to authenticate user identities, or in the case multifactor authentication, or some combination thereof. Access to organizational information systems is defined as either local access or network access. Local access is any access to organizational information systems by users (or processes acting on behalf of users) where such access is obtained by direct connections without the use of networks. Network access is access to organizational information systems by users (or processes acting on behalf of users) where such access is obtained through network connections (i.e., nonlocal accesses). Remote access is a type of network access that involves communication through external networks (e.g., the Internet). Internal networks include local area networks and wide area networks. In addition, the use of encrypted virtual private networks (VPNs) for network connections between organization- controlled endpoints and non-organization controlled endpoints may be treated as internal networks from the perspective of protecting the confidentiality and integrity of information traversing the network. Organizations can satisfy the identification and authentication requirements in this control by complying with the requirements in Homeland Security Presidential Directive 12 consistent with the specific organizational implementation plans. Multifactor authentication requires the use of two or more different factors to achieve authentication. The factors are defined as: (i) something you know (e.g., password, personal identification number [PIN]); (ii) something you have (e.g., cryptographic identification device, token); or (iii) something you are (e.g., biometric). Multifactor solutions that require devices separate from information systems gaining access include, for example, hardware tokens providing time-based or challenge-response authenticators and smart cards such as the U.S. Government Personal Identity Verification card and the DoD common access card. In addition to identifying and authenticating users at the information system level (i.e., at logon), organizations also employ identification and authentication mechanisms at the application level, when necessary, to provide increased information security. Identification and authentication requirements for other than organizational users are described in IA-8. Related controls: AC-2, AC-3, AC-14, AC-17, AC-18, IA-4, IA-5, IA-8. References: HSPD-12; OMB Memoranda 04-04, 06-16, 11-11; FIPS Publication 201; NIST Special Publications 800-63, 800-73, 800-76, 800-78; FICAM Roadmap and Implementation Guidance; Web: http://idmanagement.gov. link 7
NIST_SP_800-53_R4 IA-4 NIST_SP_800-53_R4_IA-4 NIST SP 800-53 Rev. 4 IA-4 Identification And Authentication Identifier Management Shared n/a The organization manages information system identifiers by: a. Receiving authorization from [Assignment: organization-defined personnel or roles] to assign an individual, group, role, or device identifier; b. Selecting an identifier that identifies an individual, group, role, or device; c. Assigning the identifier to the intended individual, group, role, or device; d. Preventing reuse of identifiers for [Assignment: organization-defined time period]; and e. Disabling the identifier after [Assignment: organization-defined time period of inactivity]. Supplemental Guidance: Common device identifiers include, for example, media access control (MAC), Internet protocol (IP) addresses, or device-unique token identifiers. Management of individual identifiers is not applicable to shared information system accounts (e.g., guest and anonymous accounts). Typically, individual identifiers are the user names of the information system accounts assigned to those individuals. In such instances, the account management activities of AC-2 use account names provided by IA-4. This control also addresses individual identifiers not necessarily associated with information system accounts (e.g., identifiers used in physical security control databases accessed by badge reader systems for access to information systems). Preventing reuse of identifiers implies preventing the assignment of previously used individual, group, role, or device identifiers to different individuals, groups, roles, or devices. Related controls: AC-2, IA-2, IA-3, IA-5, IA-8, SC-37. References: FIPS Publication 201; NIST Special Publications 800-73, 800-76, 800-78. link 7
NIST_SP_800-53_R5.1.1 AC.6.9 NIST_SP_800-53_R5.1.1_AC.6.9 NIST SP 800-53 R5.1.1 AC.6.9 Access Control Least Privilege | Log Use of Privileged Functions Shared Log the execution of privileged functions. The misuse of privileged functions, either intentionally or unintentionally by authorized users or by unauthorized external entities that have compromised system accounts, is a serious and ongoing concern and can have significant adverse impacts on organizations. Logging and analyzing the use of privileged functions is one way to detect such misuse and, in doing so, help mitigate the risk from insider threats and the advanced persistent threat. 1
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
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 18
NIST_SP_800-53_R5 IA-2 NIST_SP_800-53_R5_IA-2 NIST SP 800-53 Rev. 5 IA-2 Identification and Authentication Identification and Authentication (organizational Users) Shared n/a Uniquely identify and authenticate organizational users and associate that unique identification with processes acting on behalf of those users. link 7
NIST_SP_800-53_R5 IA-4 NIST_SP_800-53_R5_IA-4 NIST SP 800-53 Rev. 5 IA-4 Identification and Authentication Identifier Management Shared n/a Manage system identifiers by: a. Receiving authorization from [Assignment: organization-defined personnel or roles] to assign an individual, group, role, service, or device identifier; b. Selecting an identifier that identifies an individual, group, role, service, or device; c. Assigning the identifier to the intended individual, group, role, service, or device; and d. Preventing reuse of identifiers for [Assignment: organization-defined time period]. link 7
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. 22
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. 29
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. 22
NZ_ISM_v3.5 AC-2 NZ_ISM_v3.5_AC-2 NZISM Security Benchmark AC-2 Access Control and Passwords 16.1.32 System User Identitfication Customer n/a Having uniquely identifiable system users ensures accountability. link 3
NZISM_Security_Benchmark_v1.1 AC-2 NZISM_Security_Benchmark_v1.1_AC-2 NZISM Security Benchmark AC-2 Access Control and Passwords 16.1.32 System User Identitfication Customer Agencies must ensure that all users are: - uniquely identifiable - authenticated on each occasion that access is granted to a system. Having uniquely identifiable system users ensures accountability. link 3
NZISM_v3.7 16.1.46.C.01. NZISM_v3.7_16.1.46.C.01. NZISM v3.7 16.1.46.C.01. Identification, Authentication and Passwords 16.1.46.C.01. - To enhance overall security posture. Shared n/a Agencies MUST: 1. Record all successful and failed logon attempts; 2. lock system user accounts after three failed logon attempts; 3. have a system administrator reset locked accounts; 4. 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 5. remove or suspend inactive accounts after a specified number of days. 2
NZISM_v3.7 16.1.46.C.02. NZISM_v3.7_16.1.46.C.02. NZISM v3.7 16.1.46.C.02. Identification, Authentication and Passwords 16.1.46.C.02. - To enhance overall security posture. Shared n/a Agencies SHOULD: 1. lock system user accounts after three failed logon attempts; 2. have a system administrator reset locked accounts; 3. 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 4. remove or suspend inactive accounts after a specified number of days. 2
NZISM_v3.7 2.3.26.C.01. NZISM_v3.7_2.3.26.C.01. NZISM v3.7 2.3.26.C.01. Using Cloud Services 2.3.26.C.01. - To enhance security measures and minimise trust assumptions in cloud environments. Shared n/a Agencies intending to adopt public cloud technologies or services SHOULD incorporate Zero Trust philosophies and concepts. 4
NZISM_v3.7 20.4.4.C.01. NZISM_v3.7_20.4.4.C.01. NZISM v3.7 20.4.4.C.01. Databases 20.4.4.C.01. - To enhance data security and integrity. Shared n/a Agencies MUST protect database files from access that bypasses the database's normal access controls. 23
NZISM_v3.7 20.4.4.C.02. NZISM_v3.7_20.4.4.C.02. NZISM v3.7 20.4.4.C.02. Databases 20.4.4.C.02. - To enhance data security and integrity. Shared n/a Agencies SHOULD protect database files from access that bypass normal access controls. 23
NZISM_v3.7 20.4.5.C.01. NZISM_v3.7_20.4.5.C.01. NZISM v3.7 20.4.5.C.01. Databases 20.4.5.C.01. - To enhance data security and integrity. Shared n/a Agencies MUST enable logging and auditing of system users' actions. 22
NZISM_v3.7 20.4.5.C.02. NZISM_v3.7_20.4.5.C.02. NZISM v3.7 20.4.5.C.02. Databases 20.4.5.C.02. - To bolster data security and compliance measures. Shared n/a Agencies SHOULD ensure that databases provide functionality to allow for auditing of system users' actions. 22
NZISM_v3.7 20.4.6.C.01. NZISM_v3.7_20.4.6.C.01. NZISM v3.7 20.4.6.C.01. Databases 20.4.6.C.01. - To mitigate the risk of unauthorized access to sensitive information and ensuring compliance with security clearance requirements. Shared n/a If results from database queries cannot be appropriately filtered, agencies MUST ensure that all query results are appropriately sanitised to meet the minimum security clearances of system users. 22
NZISM_v3.7 20.4.6.C.02. NZISM_v3.7_20.4.6.C.02. NZISM v3.7 20.4.6.C.02. Databases 20.4.6.C.02. - To enhance data security. Shared n/a Agencies SHOULD ensure that system users who do not have sufficient security clearances to view database contents cannot see or interrogate associated metadata in a list of results from a search engine query. 22
PCI_DSS_v4.0.1 10.2.1.2 PCI_DSS_v4.0.1_10.2.1.2 PCI DSS v4.0.1 10.2.1.2 Log and Monitor All Access to System Components and Cardholder Data Administrative Actions Logging Shared n/a Audit logs capture all actions taken by any individual with administrative access, including any interactive use of application or system accounts. 25
RBI_CSF_Banks_v2016 6.4 RBI_CSF_Banks_v2016_6.4 Application Security Life Cycle (Aslc) Application Security Life Cycle (Aslc)-6.4 n/a Besides business functionalities, security requirements relating to system access control, authentication, transaction authorization, data integrity, system activity logging, audit trail, session management, security event tracking and exception handling are required to be clearly specified at the initial and ongoing stages of system development/acquisition/implementation. 13
RBI_CSF_Banks_v2016 8.4 RBI_CSF_Banks_v2016_8.4 User Access Control / Management User Access Control / Management-8.4 n/a Implement centralised authentication and authorisation system or accessing and administering applications, operating systems, databases, network and security devices/systems, point of connectivity (local/remote, etc.) including enforcement of strong password policy, two-factor/multi-factor authentication depending on risk assessment and following the principle of least privileges and separation of duties. 3
SOC_2023 CC6.3 SOC_2023_CC6.3 404 not found n/a n/a 56
SWIFT_CSCF_2024 1.2 SWIFT_CSCF_2024_1.2 SWIFT Customer Security Controls Framework 2024 1.2 Privileged Account Control Operating System Privileged Account Control Shared Tightly protecting administrator-level accounts within the operating system reduces the opportunity for an attacker to use the privileges of the account as part of an attack (for example, executing commands or deleting evidence). To restrict and control the allocation and usage of administrator-level operating system accounts. 53
SWIFT_CSCF_v2021 2.1 SWIFT_CSCF_v2021_2.1 SWIFT CSCF v2021 2.1 Reduce Attack Surface and Vulnerabilities Internal Data Flow Security n/a Ensure the confidentiality, integrity, and authenticity of application data flows between local SWIFT-related applications. link 14
SWIFT_CSCF_v2021 5.2 SWIFT_CSCF_v2021_5.2 SWIFT CSCF v2021 5.2 Manage Identities and Segregate Privileges Token Management n/a Ensure the proper management, tracking, and use of connected hardware authentication or personal tokens (if tokens are used). link 3
SWIFT_CSCF_v2021 5.4 SWIFT_CSCF_v2021_5.4 SWIFT CSCF v2021 5.4 Manage Identities and Segregate Privileges Physical and Logical Password Storage n/a Protect physically and logically repository of recorded passwords. link 4
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 22
U.10.3 - Users U.10.3 - Users 404 not found n/a n/a 23
U.10.5 - Competent U.10.5 - Competent 404 not found n/a n/a 21
Initiatives usage
Initiative DisplayName Initiative Id Initiative Category State Type polSet in AzUSGov
[Deprecated]: Azure Security Benchmark v1 42a694ed-f65e-42b2-aa9e-8052e9740a92 Regulatory Compliance Deprecated BuiltIn true
[Deprecated]: Azure Security Benchmark v2 bb522ac1-bc39-4957-b194-429bcd3bcb0b Regulatory Compliance Deprecated BuiltIn true
[Deprecated]: New Zealand ISM Restricted d1a462af-7e6d-4901-98ac-61570b4ed22a Regulatory Compliance Deprecated BuiltIn unknown
[Deprecated]: New Zealand ISM Restricted v3.5 93d2179e-3068-c82f-2428-d614ae836a04 Regulatory Compliance Deprecated BuiltIn unknown
[Preview]: CMMC 2.0 Level 2 4e50fd13-098b-3206-61d6-d1d78205cb45 Regulatory Compliance Preview BuiltIn true
[Preview]: Control the use of App Service in a Virtual Enclave 528d78c5-246c-4f26-ade6-d30798705411 VirtualEnclaves Preview BuiltIn true
[Preview]: Reserve Bank of India - IT Framework for Banks d0d5578d-cc08-2b22-31e3-f525374f235a Regulatory Compliance Preview BuiltIn unknown
[Preview]: SWIFT CSP-CSCF v2021 abf84fac-f817-a70c-14b5-47eec767458a Regulatory Compliance Preview BuiltIn unknown
CIS Azure Foundations v2.1.0 fe7782e4-6ff3-4e39-8d8a-64b6f7b82c85 Regulatory Compliance GA BuiltIn unknown
CIS Controls v8.1 046796ef-e8a7-4398-bbe9-cce970b1a3ae Regulatory Compliance GA BuiltIn unknown
CIS Microsoft Azure Foundations Benchmark v1.1.0 1a5bb27d-173f-493e-9568-eb56638dde4d Regulatory Compliance GA BuiltIn true
CIS Microsoft Azure Foundations Benchmark v1.3.0 612b5213-9160-4969-8578-1518bd2a000c Regulatory Compliance GA BuiltIn true
CIS Microsoft Azure Foundations Benchmark v1.4.0 c3f5c4d9-9a1d-4a99-85c0-7f93e384d5c5 Regulatory Compliance GA BuiltIn unknown
CIS Microsoft Azure Foundations Benchmark v2.0.0 06f19060-9e68-4070-92ca-f15cc126059e Regulatory Compliance GA BuiltIn unknown
Cyber Essentials v3.1 b2f588d7-1ed5-47c7-977d-b93dff520c4c Regulatory Compliance GA BuiltIn unknown
Cybersecurity Maturity Model Certification (CMMC) Level 2 v1.9.0 a4087154-2edb-4329-b56a-1cc986807f3c Regulatory Compliance GA BuiltIn unknown
EU General Data Protection Regulation (GDPR) 2016/679 7326812a-86a4-40c8-af7c-8945de9c4913 Regulatory Compliance GA BuiltIn unknown
FBI Criminal Justice Information Services (CJIS) v5.9.5 4fcabc2a-30b2-4ba5-9fbb-b1a4e08fb721 Regulatory Compliance GA BuiltIn unknown
FedRAMP High d5264498-16f4-418a-b659-fa7ef418175f Regulatory Compliance GA BuiltIn true
FedRAMP Moderate e95f5a9f-57ad-4d03-bb0b-b1d16db93693 Regulatory Compliance GA BuiltIn true
FFIEC CAT 2017 1d5dbdd5-6f93-43ce-a939-b19df3753cf7 Regulatory Compliance GA BuiltIn unknown
HITRUST CSF v11.3 e0d47b75-5d99-442a-9d60-07f2595ab095 Regulatory Compliance GA BuiltIn unknown
Microsoft cloud security benchmark 1f3afdf9-d0c9-4c3d-847f-89da613e70a8 Security Center GA BuiltIn true
New Zealand ISM 4f5b1359-4f8e-4d7c-9733-ea47fcde891e Regulatory Compliance GA BuiltIn unknown
NIST 800-171 R3 38916c43-6876-4971-a4b1-806aa7e55ccc Regulatory Compliance GA BuiltIn unknown
NIST SP 800-171 Rev. 2 03055927-78bd-4236-86c0-f36125a10dc9 Regulatory Compliance GA BuiltIn true
NIST SP 800-53 R5.1.1 60205a79-6280-4e20-a147-e2011e09dc78 Regulatory Compliance GA BuiltIn unknown
NIST SP 800-53 Rev. 4 cf25b9c1-bd23-4eb6-bd2c-f4f3ac644a5f Regulatory Compliance GA BuiltIn true
NIST SP 800-53 Rev. 5 179d1daa-458f-4e47-8086-2a68d0d6c38f Regulatory Compliance GA BuiltIn true
NL BIO Cloud Theme 6ce73208-883e-490f-a2ac-44aac3b3687f Regulatory Compliance GA BuiltIn unknown
NL BIO Cloud Theme V2 d8b2ffbe-c6a8-4622-965d-4ade11d1d2ee Regulatory Compliance GA BuiltIn unknown
NZISM v3.7 4476df0a-18ab-4bfe-b6ad-cccae1cf320f Regulatory Compliance GA BuiltIn unknown
PCI DSS v4.0.1 a06d5deb-24aa-4991-9d58-fa7563154e31 Regulatory Compliance GA BuiltIn unknown
SOC 2023 53ad89f5-8542-49e9-ba81-1cbd686e0d52 Regulatory Compliance GA BuiltIn unknown
SWIFT Customer Security Controls Framework 2024 7499005e-df5a-45d9-810f-041cf346678c Regulatory Compliance GA BuiltIn unknown
History
Date/Time (UTC ymd) (i) Change type Change detail
2022-07-01 16:32:34 change Major (2.0.0 > 3.0.0)
2021-02-17 14:28:42 change Major (1.0.0 > 2.0.0)
2019-10-29 23:04:36 add 2b9ad585-36bc-4615-b300-fd4435808332
JSON compare
compare mode: version left: version right:
JSON
api-version=2021-06-01
EPAC