last sync: 2024-Oct-04 17:51:30 UTC

An Azure Active Directory administrator should be provisioned for SQL servers

Azure BuiltIn Policy definition

Source Azure Portal
Display name An Azure Active Directory administrator should be provisioned for SQL servers
Id 1f314764-cb73-4fc9-b863-8eca98ac36e9
Version 1.0.0
Details on versioning
Versioning Versions supported for Versioning: 1
1.0.0
Built-in Versioning [Preview]
Category SQL
Microsoft Learn
Description Audit provisioning of an Azure Active Directory administrator for your SQL server to enable Azure AD authentication. Azure AD authentication enables simplified permission management and centralized identity management of database users and other Microsoft services
Mode Indexed
Type BuiltIn
Preview False
Deprecated False
Effect Default
AuditIfNotExists
Allowed
AuditIfNotExists, Disabled
RBAC role(s) none
Rule aliases none
Rule resource types IF (1)
Microsoft.Sql/servers
THEN-Details (1)
Microsoft.Sql/servers/administrators
Compliance
The following 70 compliance controls are associated with this Policy definition 'An Azure Active Directory administrator should be provisioned for SQL servers' (1f314764-cb73-4fc9-b863-8eca98ac36e9)
Control Domain Control Name MetadataId Category Title Owner Requirements Description Info Policy#
AU_ISM 1260 AU_ISM_1260 AU ISM 1260 Guidelines for Database Systems - Database management system software Database administrator accounts - 1260 n/a Default database administrator accounts are disabled, renamed or have their passphrases changed. link 1
AU_ISM 1261 AU_ISM_1261 AU ISM 1261 Guidelines for Database Systems - Database management system software Database administrator accounts - 1261 n/a Database administrator accounts are not shared across different databases. link 1
AU_ISM 1262 AU_ISM_1262 AU ISM 1262 Guidelines for Database Systems - Database management system software Database administrator accounts - 1262 n/a Database administrators have unique and identifiable accounts. link 1
AU_ISM 1263 AU_ISM_1263 AU ISM 1263 Guidelines for Database Systems - Database management system software Database administrator accounts - 1263 n/a Database administrator accounts are used exclusively for administrative tasks, with standard database accounts used for general purpose interactions with databases. link 1
AU_ISM 1264 AU_ISM_1264 AU ISM 1264 Guidelines for Database Systems - Database management system software Database administrator accounts - 1264 n/a Database administrator access is restricted to defined roles rather than accounts with default administrative permissions, or all permissions. link 1
Azure_Security_Benchmark_v1.0 3.9 Azure_Security_Benchmark_v1.0_3.9 Azure Security Benchmark 3.9 Identity and Access Control Use Microsoft Entra ID Customer Use Microsoft Entra ID as the central authentication and authorization system. Microsoft Entra ID protects data by using strong encryption for data at rest and in transit. Microsoft Entra ID also salts, hashes, and securely stores user credentials. How to create and configure a Microsoft Entra instance: https://docs.microsoft.com/azure/active-directory/fundamentals/active-directory-access-create-new-tenant 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_v3.0 IM-1 Azure_Security_Benchmark_v3.0_IM-1 Microsoft cloud security benchmark IM-1 Identity Management Use centralized identity and authentication system Shared **Security Principle:** Use a centralized identity and authentication system to govern your organization's identities and authentications for cloud and non-cloud resources. **Azure Guidance:** Microsoft Entra ID is Azure's identity and authentication management service. You should standardize on Microsoft Entra ID to govern your organization's identity and authentication in: - Microsoft cloud resources, such as the Azure Storage, Azure Virtual Machines (Linux and Windows), Azure Key Vault, PaaS, and SaaS applications. - Your organization's resources, such as applications on Azure, third-party applications running on your corporate network resources, and third-party SaaS applications. - Your enterprise identities in Active Directory by synchronization to Microsoft Entra ID to ensure a consistent and centrally managed identity strategy. Note: As soon as it is technically feasible, you should migrate on-premises Active Directory based applications to Microsoft Entra ID. This could be a Microsoft Entra Enterprise Directory, Business to Business configuration, or Business to consumer configuration. **Implementation and additional context:** 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 ID 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 n/a link 15
CCCS AC-2(7) CCCS_AC-2(7) CCCS AC-2(7) Access Control Account Management | Role-Based Schemes n/a (a) The organization establishes and administers privileged user accounts in accordance with a role-based access scheme that organizes allowed information system access and privileges into roles; (b) The organization monitors privileged role assignments; and (c) The organization disables (or revokes) privileged user assignments within 24 hours or sooner when privileged role assignments are no longer appropriate. link 2
CIS_Azure_1.1.0 4.8 CIS_Azure_1.1.0_4.8 CIS Microsoft Azure Foundations Benchmark recommendation 4.8 4 Database Services Ensure that Azure Active Directory Admin is configured Shared The customer is responsible for implementing this recommendation. Use Azure Active Directory Authentication for authentication with SQL Database. link 5
CIS_Azure_1.3.0 4.4 CIS_Azure_1.3.0_4.4 CIS Microsoft Azure Foundations Benchmark recommendation 4.4 4 Database Services Ensure that Azure Active Directory Admin is configured Shared The customer is responsible for implementing this recommendation. Use Azure Active Directory Authentication for authentication with SQL Database. link 5
CIS_Azure_1.4.0 4.5 CIS_Azure_1.4.0_4.5 CIS Microsoft Azure Foundations Benchmark recommendation 4.5 4 Database Services Ensure that Azure Active Directory Admin is configured Shared The customer is responsible for implementing this recommendation. Use Azure Active Directory Authentication for authentication with SQL Database to manage credentials in a single place. link 5
CIS_Azure_2.0.0 4.1.4 CIS_Azure_2.0.0_4.1.4 CIS Microsoft Azure Foundations Benchmark recommendation 4.1.4 4.1 Ensure that Azure Active Directory Admin is Configured for SQL Servers Shared This will create administrative overhead with user account and permission management. For further security on these administrative accounts, you may want to consider higher tiers of AAD which support features like Multi Factor Authentication, that will cost more. Use Azure Active Directory Authentication for authentication with SQL Database to manage credentials in a single place. Azure Active Directory authentication is a mechanism to connect to Microsoft Azure SQL Database and SQL Data Warehouse by using identities in Azure Active Directory (Azure AD). With Azure AD authentication, identities of database users and other Microsoft services can be managed in one central location. Central ID management provides a single place to manage database users and simplifies permission management. - It provides an alternative to SQL Server authentication. - Helps stop the proliferation of user identities across database servers. - Allows password rotation in a single place. - Customers can manage database permissions using external (AAD) groups. - It can eliminate storing passwords by enabling integrated Windows authentication and other forms of authentication supported by Azure Active Directory. - Azure AD authentication uses contained database users to authenticate identities at the database level. - Azure AD supports token-based authentication for applications connecting to SQL Database. - Azure AD authentication supports ADFS (domain federation) or native user/password authentication for a local Azure Active Directory without domain synchronization. - Azure AD supports connections from SQL Server Management Studio that use Active Directory Universal Authentication, which includes Multi-Factor Authentication (MFA). MFA includes strong authentication with a range of easy verification options — phone call, text message, smart cards with pin, or mobile app notification. 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_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 18
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_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_High_R4 AC-2(1) FedRAMP_High_R4_AC-2(1) FedRAMP High AC-2 (1) Access Control Automated System Account Management Shared n/a The organization employs automated mechanisms to support the management of information system accounts. Supplemental Guidance: The use of automated mechanisms can include, for example: using email or text messaging to automatically notify account managers when users are terminated or transferred; using the information system to monitor account usage; and using telephonic notification to report atypical system account usage. link 7
FedRAMP_High_R4 AC-2(7) FedRAMP_High_R4_AC-2(7) FedRAMP High AC-2 (7) Access Control Role-Based Schemes Shared n/a The organization: (a) Establishes and administers privileged user accounts in accordance with a role-based access scheme that organizes allowed information system access and privileges into roles; (b) Monitors privileged role assignments; and (c) Takes [Assignment: organization-defined actions] when privileged role assignments are no longer appropriate. Supplemental Guidance: Privileged roles are organization-defined roles assigned to individuals that allow those individuals to perform certain security-relevant functions that ordinary users are not authorized to perform. These privileged roles include, for example, key management, account management, network and system administration, database administration, and web administration. link 10
FedRAMP_High_R4 AC-3 FedRAMP_High_R4_AC-3 FedRAMP High AC-3 Access Control Access Enforcement Shared n/a The information system enforces approved authorizations for logical access to information and system resources in accordance with applicable access control policies. Supplemental Guidance: Access control policies (e.g., identity-based policies, role-based policies, attribute-based policies) and access enforcement mechanisms (e.g., access control lists, access control matrices, cryptography) control access between active entities or subjects (i.e., users or processes acting on behalf of users) and passive entities or objects (e.g., devices, files, records, domains) in information systems. In addition to enforcing authorized access at the information system level and recognizing that information systems can host many applications and services in support of organizational missions and business operations, access enforcement mechanisms can also be employed at the application and service level to provide increased information security. Related controls: AC-2, AC-4, AC-5, AC-6, AC-16, AC-17, AC-18, AC-19, AC-20, AC-21, AC-22, AU-9, CM-5, CM-6, CM-11, MA-3, MA-4, MA-5, PE-3. References: None. link 21
FedRAMP_High_R4 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 10
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-2(1) FedRAMP_Moderate_R4_AC-2(1) FedRAMP Moderate AC-2 (1) Access Control Automated System Account Management Shared n/a The organization employs automated mechanisms to support the management of information system accounts. Supplemental Guidance: The use of automated mechanisms can include, for example: using email or text messaging to automatically notify account managers when users are terminated or transferred; using the information system to monitor account usage; and using telephonic notification to report atypical system account usage. link 7
FedRAMP_Moderate_R4 AC-2(7) FedRAMP_Moderate_R4_AC-2(7) FedRAMP Moderate AC-2 (7) Access Control Role-Based Schemes Shared n/a The organization: (a) Establishes and administers privileged user accounts in accordance with a role-based access scheme that organizes allowed information system access and privileges into roles; (b) Monitors privileged role assignments; and (c) Takes [Assignment: organization-defined actions] when privileged role assignments are no longer appropriate. Supplemental Guidance: Privileged roles are organization-defined roles assigned to individuals that allow those individuals to perform certain security-relevant functions that ordinary users are not authorized to perform. These privileged roles include, for example, key management, account management, network and system administration, database administration, and web administration. link 10
FedRAMP_Moderate_R4 AC-3 FedRAMP_Moderate_R4_AC-3 FedRAMP Moderate AC-3 Access Control Access Enforcement Shared n/a The information system enforces approved authorizations for logical access to information and system resources in accordance with applicable access control policies. Supplemental Guidance: Access control policies (e.g., identity-based policies, role-based policies, attribute-based policies) and access enforcement mechanisms (e.g., access control lists, access control matrices, cryptography) control access between active entities or subjects (i.e., users or processes acting on behalf of users) and passive entities or objects (e.g., devices, files, records, domains) in information systems. In addition to enforcing authorized access at the information system level and recognizing that information systems can host many applications and services in support of organizational missions and business operations, access enforcement mechanisms can also be employed at the application and service level to provide increased information security. Related controls: AC-2, AC-4, AC-5, AC-6, AC-16, AC-17, AC-18, AC-19, AC-20, AC-21, AC-22, AU-9, CM-5, CM-6, CM-11, MA-3, MA-4, MA-5, PE-3. References: None. link 21
FedRAMP_Moderate_R4 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 10
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
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.3 ISO27001-2013_A.9.2.3 ISO 27001:2013 A.9.2.3 Access Control Management of privileged access rights Shared n/a The allocation and use of privileged access rights shall be restricted and controlled. link 33
New_Zealand_ISM 16.4.32.C.01 New_Zealand_ISM_16.4.32.C.01 New_Zealand_ISM_16.4.32.C.01 16. Access Control and Passwords Privileged Access Management - Strong Authentication process n/a The approval and authorisation process for the granting of privileged access should be based on the requirement to manage and protect agency systems and assets or as an operational necessity only. 1
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-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 24
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-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-2(1) NIST_SP_800-53_R4_AC-2(1) NIST SP 800-53 Rev. 4 AC-2 (1) Access Control Automated System Account Management Shared n/a The organization employs automated mechanisms to support the management of information system accounts. Supplemental Guidance: The use of automated mechanisms can include, for example: using email or text messaging to automatically notify account managers when users are terminated or transferred; using the information system to monitor account usage; and using telephonic notification to report atypical system account usage. link 7
NIST_SP_800-53_R4 AC-2(7) NIST_SP_800-53_R4_AC-2(7) NIST SP 800-53 Rev. 4 AC-2 (7) Access Control Role-Based Schemes Shared n/a The organization: (a) Establishes and administers privileged user accounts in accordance with a role-based access scheme that organizes allowed information system access and privileges into roles; (b) Monitors privileged role assignments; and (c) Takes [Assignment: organization-defined actions] when privileged role assignments are no longer appropriate. Supplemental Guidance: Privileged roles are organization-defined roles assigned to individuals that allow those individuals to perform certain security-relevant functions that ordinary users are not authorized to perform. These privileged roles include, for example, key management, account management, network and system administration, database administration, and web administration. link 10
NIST_SP_800-53_R4 AC-3 NIST_SP_800-53_R4_AC-3 NIST SP 800-53 Rev. 4 AC-3 Access Control Access Enforcement Shared n/a The information system enforces approved authorizations for logical access to information and system resources in accordance with applicable access control policies. Supplemental Guidance: Access control policies (e.g., identity-based policies, role-based policies, attribute-based policies) and access enforcement mechanisms (e.g., access control lists, access control matrices, cryptography) control access between active entities or subjects (i.e., users or processes acting on behalf of users) and passive entities or objects (e.g., devices, files, records, domains) in information systems. In addition to enforcing authorized access at the information system level and recognizing that information systems can host many applications and services in support of organizational missions and business operations, access enforcement mechanisms can also be employed at the application and service level to provide increased information security. Related controls: AC-2, AC-4, AC-5, AC-6, AC-16, AC-17, AC-18, AC-19, AC-20, AC-21, AC-22, AU-9, CM-5, CM-6, CM-11, MA-3, MA-4, MA-5, PE-3. References: None. link 21
NIST_SP_800-53_R4 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 10
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 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-2(1) NIST_SP_800-53_R5_AC-2(1) NIST SP 800-53 Rev. 5 AC-2 (1) Access Control Automated System Account Management Shared n/a Support the management of system accounts using [Assignment: organization-defined automated mechanisms]. link 7
NIST_SP_800-53_R5 AC-2(7) NIST_SP_800-53_R5_AC-2(7) NIST SP 800-53 Rev. 5 AC-2 (7) Access Control Privileged User Accounts Shared n/a (a) Establish and administer privileged user accounts in accordance with [Selection: a role-based access scheme;an attribute-based access scheme] ; (b) Monitor privileged role or attribute assignments; (c) Monitor changes to roles or attributes; and (d) Revoke access when privileged role or attribute assignments are no longer appropriate. link 10
NIST_SP_800-53_R5 AC-3 NIST_SP_800-53_R5_AC-3 NIST SP 800-53 Rev. 5 AC-3 Access Control Access Enforcement Shared n/a Enforce approved authorizations for logical access to information and system resources in accordance with applicable access control policies. link 21
NIST_SP_800-53_R5 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 10
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
NZ_ISM_v3.5 AC-11 NZ_ISM_v3.5_AC-11 NZISM Security Benchmark AC-11 Access Control and Passwords 16.4.30 Privileged Access Management Customer n/a A fundamental part of any security policy is the inclusion of requirements for the treatment of Privileged Accounts. This is most conveniently contained in a Privileged Access Management (PAM) section within the agency???s security policy. A PAM policy is a fundamental component of an agency???s IT Governance. link 7
NZISM_Security_Benchmark_v1.1 AC-11 NZISM_Security_Benchmark_v1.1_AC-11 NZISM Security Benchmark AC-11 Access Control and Passwords 16.4.30 Privileged Access Management Customer Agencies MUST establish a Privileged Access Management (PAM) policy. Within the context of agency operations, the agency’s PAM policy MUST define: a privileged account; and privileged access. Agencies MUST manage Privileged Accounts in accordance with the Agency’s PAM Policy. A fundamental part of any security policy is the inclusion of requirements for the treatment of Privileged Accounts. This is most conveniently contained in a Privileged Access Management (PAM) section within the agency’s security policy. A PAM policy is a fundamental component of an agency’s IT Governance. link 9
PCI_DSS_V3.2.1 3.2 PCI_DSS_v3.2.1_3.2 PCI DSS v3.2.1 3.2 Requirement 3 PCI DSS requirement 3.2 customer n/a n/a link 7
PCI_DSS_V3.2.1 7.2.1 PCI_DSS_v3.2.1_7.2.1 PCI DSS v3.2.1 7.2.1 Requirement 7 PCI DSS requirement 7.2.1 customer n/a n/a link 7
PCI_DSS_V3.2.1 8.3.1 PCI_DSS_v3.2.1_8.3.1 PCI DSS v3.2.1 8.3.1 Requirement 8 PCI DSS requirement 8.3.1 shared n/a n/a link 7
PCI_DSS_v4.0 3.3.3 PCI_DSS_v4.0_3.3.3 PCI DSS v4.0 3.3.3 Requirement 03: Protect Stored Account Data Sensitive authentication data (SAD) is not stored after authorization Shared n/a Additional requirement for issuers and companies that support issuing services and store sensitive authentication data: Any storage of sensitive authentication data is: • Limited to that which is needed for a legitimate issuing business need and is secured. • Encrypted using strong cryptography. This bullet is a best practice until its effective date; refer to Applicability Notes below for details. link 13
PCI_DSS_v4.0 7.3.1 PCI_DSS_v4.0_7.3.1 PCI DSS v4.0 7.3.1 Requirement 07: Restrict Access to System Components and Cardholder Data by Business Need to Know Access to system components and data is managed via an access control system(s) Shared n/a An access control system(s) is in place that restricts access based on a user’s need to know and covers all system components. link 17
PCI_DSS_v4.0 8.4.1 PCI_DSS_v4.0_8.4.1 PCI DSS v4.0 8.4.1 Requirement 08: Identify Users and Authenticate Access to System Components Multi-factor authentication (MFA) is implemented to secure access into the CDE Shared n/a MFA is implemented for all non-console access into the CDE for personnel with administrative access. link 8
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.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
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
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
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
Initiatives usage
Initiative DisplayName Initiative Id Initiative Category State Type
[Deprecated]: Azure Security Benchmark v1 42a694ed-f65e-42b2-aa9e-8052e9740a92 Regulatory Compliance Deprecated BuiltIn
[Deprecated]: Azure Security Benchmark v2 bb522ac1-bc39-4957-b194-429bcd3bcb0b Regulatory Compliance Deprecated BuiltIn
[Deprecated]: DoD Impact Level 4 8d792a84-723c-4d92-a3c3-e4ed16a2d133 Regulatory Compliance Deprecated BuiltIn
[Deprecated]: New Zealand ISM Restricted d1a462af-7e6d-4901-98ac-61570b4ed22a Regulatory Compliance Deprecated BuiltIn
[Deprecated]: New Zealand ISM Restricted v3.5 93d2179e-3068-c82f-2428-d614ae836a04 Regulatory Compliance Deprecated BuiltIn
[Preview]: Australian Government ISM PROTECTED 27272c0b-c225-4cc3-b8b0-f2534b093077 Regulatory Compliance Preview BuiltIn
[Preview]: CMMC 2.0 Level 2 4e50fd13-098b-3206-61d6-d1d78205cb45 Regulatory Compliance Preview BuiltIn
[Preview]: Control the use of Microsoft SQL in a Virtual Enclave 0fbe78a5-1722-4f1b-83a5-89c14151fa60 VirtualEnclaves Preview BuiltIn
[Preview]: Reserve Bank of India - IT Framework for Banks d0d5578d-cc08-2b22-31e3-f525374f235a Regulatory Compliance Preview BuiltIn
[Preview]: SWIFT CSP-CSCF v2020 3e0c67fc-8c7c-406c-89bd-6b6bdc986a22 Regulatory Compliance Preview BuiltIn
[Preview]: SWIFT CSP-CSCF v2021 abf84fac-f817-a70c-14b5-47eec767458a Regulatory Compliance Preview BuiltIn
Canada Federal PBMM 4c4a5f27-de81-430b-b4e5-9cbd50595a87 Regulatory Compliance GA BuiltIn
CIS Microsoft Azure Foundations Benchmark v1.1.0 1a5bb27d-173f-493e-9568-eb56638dde4d Regulatory Compliance GA BuiltIn
CIS Microsoft Azure Foundations Benchmark v1.3.0 612b5213-9160-4969-8578-1518bd2a000c Regulatory Compliance GA BuiltIn
CIS Microsoft Azure Foundations Benchmark v1.4.0 c3f5c4d9-9a1d-4a99-85c0-7f93e384d5c5 Regulatory Compliance GA BuiltIn
CIS Microsoft Azure Foundations Benchmark v2.0.0 06f19060-9e68-4070-92ca-f15cc126059e Regulatory Compliance GA BuiltIn
CMMC Level 3 b5629c75-5c77-4422-87b9-2509e680f8de Regulatory Compliance GA BuiltIn
FedRAMP High d5264498-16f4-418a-b659-fa7ef418175f Regulatory Compliance GA BuiltIn
FedRAMP Moderate e95f5a9f-57ad-4d03-bb0b-b1d16db93693 Regulatory Compliance GA BuiltIn
IRS1075 September 2016 105e0327-6175-4eb2-9af4-1fba43bdb39d Regulatory Compliance GA BuiltIn
ISO 27001:2013 89c6cddc-1c73-4ac1-b19c-54d1a15a42f2 Regulatory Compliance GA BuiltIn
Microsoft cloud security benchmark 1f3afdf9-d0c9-4c3d-847f-89da613e70a8 Security Center GA BuiltIn
New Zealand ISM 4f5b1359-4f8e-4d7c-9733-ea47fcde891e Regulatory Compliance GA BuiltIn
NIST SP 800-171 Rev. 2 03055927-78bd-4236-86c0-f36125a10dc9 Regulatory Compliance GA BuiltIn
NIST SP 800-53 Rev. 4 cf25b9c1-bd23-4eb6-bd2c-f4f3ac644a5f Regulatory Compliance GA BuiltIn
NIST SP 800-53 Rev. 5 179d1daa-458f-4e47-8086-2a68d0d6c38f Regulatory Compliance GA BuiltIn
NL BIO Cloud Theme 6ce73208-883e-490f-a2ac-44aac3b3687f Regulatory Compliance GA BuiltIn
PCI DSS v4 c676748e-3af9-4e22-bc28-50feed564afb Regulatory Compliance GA BuiltIn
PCI v3.2.1:2018 496eeda9-8f2f-4d5e-8dfd-204f0a92ed41 Regulatory Compliance GA BuiltIn
RMIT Malaysia 97a6d4f1-3bed-4cf4-ac5b-0e444c0408d6 Regulatory Compliance GA BuiltIn
UK OFFICIAL and UK NHS 3937f550-eedd-4639-9c5e-294358be442e Regulatory Compliance GA BuiltIn
History none
JSON compare n/a
JSON
api-version=2021-06-01
EPAC