An Azure Active Directory administrator should be provisioned for SQL servers

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.

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.

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.

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.

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.

Azure_Security_Benchmark_v1.0

3.9

Azure_Security_Benchmark_v1.0_3.9

Azure Security Benchmark 3.9

Identity and Access Control

Use Azure Active Directory

Customer

Use Azure Active Directory (AAD) as the central authentication and authorization system. AAD protects data by using strong encryption for data at rest and in transit. AAD also salts, hashes, and securely stores user credentials. How to create and configure an AAD instance: https://docs.microsoft.com/azure/active-directory/fundamentals/active-directory-access-create-new-tenant

n/a

Azure_Security_Benchmark_v2.0

IM-1

Azure_Security_Benchmark_v2.0_IM-1

Azure Security Benchmark IM-1

Identity Management

Standardize Azure Active Directory as the central identity and authentication system

Customer

Azure Active Directory (Azure AD) is Azure's default identity and access management service. You should standardize on Azure AD 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 Azure AD should be a high priority in your organization’s cloud security practice. Azure AD 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: Azure AD 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 Azure AD: https://docs.microsoft.com/azure/active-directory/develop/single-and-multi-tenant-apps How to create and configure an Azure AD instance: https://docs.microsoft.com/azure/active-directory/fundamentals/active-directory-access-create-new-tenant Define Azure AD 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 Azure AD: https://docs.microsoft.com/azure/active-directory/fundamentals/identity-secure-score

n/a

Azure_Security_Benchmark_v3.0

IM-1

Azure_Security_Benchmark_v3.0_IM-1

Azure 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:** Azure Active Directory (Azure AD) is Azure's identity and authentication management service. You should standardize on Azure AD 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 Azure AD 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 Azure AD. This could be an Azure AD Enterprise Directory, Business to Business configuration, or Business to consumer configuration. **Implementation and additional context:** Tenancy in Azure AD: https://docs.microsoft.com/azure/active-directory/develop/single-and-multi-tenant-apps How to create and configure an Azure AD instance: https://docs.microsoft.com/azure/active-directory/fundamentals/active-directory-access-create-new-tenant Define Azure AD 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

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.

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.

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.

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.

AC.L1-3.1.1

CMMC_2.0_L2_AC.L1-3.1.1

404 not found

n/a

AC.L1-3.1.2

CMMC_2.0_L2_AC.L1-3.1.2

404 not found

n/a

IA.L1-3.5.1

CMMC_2.0_L2_IA.L1-3.5.1

404 not found

n/a

IA.L1-3.5.2

CMMC_2.0_L2_IA.L1-3.5.2

404 not found

n/a

IA.L2-3.5.5

CMMC_2.0_L2_IA.L2-3.5.5

404 not found

n/a

IA.L2-3.5.6

CMMC_2.0_L2_IA.L2-3.5.6

404 not found

n/a

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.

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.

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.

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.

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.

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.

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.

AC-2

FedRAMP_Moderate_R4_AC-2

FedRAMP Moderate AC-2

Access Control

Account Management

Shared

n/a

FedRAMP_Moderate_R4_AC-2(1)

AC-2(1)

FedRAMP Moderate AC-2 (1)

Access Control

Automated System Account Management

Shared

n/a

FedRAMP_Moderate_R4_AC-2(7)

AC-2(7)

FedRAMP Moderate AC-2 (7)

Access Control

Role-Based Schemes

Shared

n/a

AC-3

FedRAMP_Moderate_R4_AC-3

FedRAMP Moderate AC-3

Access Control

Access Enforcement

Shared

n/a

IA-2

FedRAMP_Moderate_R4_IA-2

FedRAMP Moderate IA-2

Identification And Authentication

Identification And Authentication (Organizational Users)

Shared

n/a

IA-4

FedRAMP_Moderate_R4_IA-4

FedRAMP Moderate IA-4

Identification And Authentication

Identifier Management

Shared

n/a

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)

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.

.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.

.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).

.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.

.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.

.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.

.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.

AC-2

NIST_SP_800-53_R4_AC-2

NIST SP 800-53 Rev. 4 AC-2

Access Control

Account Management

Shared

n/a

NIST_SP_800-53_R4_AC-2(1)

AC-2(1)

NIST SP 800-53 Rev. 4 AC-2 (1)

Access Control

Automated System Account Management

Shared

n/a

NIST_SP_800-53_R4_AC-2(7)

AC-2(7)

NIST SP 800-53 Rev. 4 AC-2 (7)

Access Control

Role-Based Schemes

Shared

n/a

AC-3

NIST_SP_800-53_R4_AC-3

NIST SP 800-53 Rev. 4 AC-3

Access Control

Access Enforcement

Shared

n/a

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

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

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.

NIST_SP_800-53_R5_AC-2(1)

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].

NIST_SP_800-53_R5_AC-2(7)

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.

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.

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.

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].

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.

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.

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

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

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

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.

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.

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.

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

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.).

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.

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.