Az Policy Advertizer

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

Azure_Security_Benchmark_v2.0

IM-2

Azure_Security_Benchmark_v2.0_IM-2

Azure Security Benchmark IM-2

Identity Management

Manage application identities securely and automatically

Customer

For non-human accounts such as services or automation, use Azure managed identities, instead of creating a more powerful human account to access resources or execute code. Azure managed identities can authenticate to Azure services and resources that support Microsoft Entra authentication. Authentication is enabled through pre-defined access grant rules, avoiding hard-coded credentials in source code or configuration files. For services that do not support managed identities, use Microsoft Entra ID to create a service principal with restricted permissions at the resource level instead. It is recommended to configure service principals with certificate credentials and fall back to client secrets. In both cases, Azure Key Vault can be used in conjunction with Azure managed identities, so that the runtime environment (such as an Azure function) can retrieve the credential from the key vault. Azure managed identities: https://docs.microsoft.com/azure/active-directory/managed-identities-azure-resources/overview Services that support managed identities for Azure resources: https://docs.microsoft.com/azure/active-directory/managed-identities-azure-resources/services-support-managed-identities Azure service principal: https://docs.microsoft.com/powershell/azure/create-azure-service-principal-azureps Create a service principal with certificates: https://docs.microsoft.com/azure/active-directory/develop/howto-authenticate-service-principal-powershell Use Azure Key Vault for security principal registration: https://docs.microsoft.com/azure/key-vault/general/authentication#security-principal-registration

n/a

Azure_Security_Benchmark_v3.0

IM-3

Azure_Security_Benchmark_v3.0_IM-3

Microsoft cloud security benchmark IM-3

Identity Management

Manage application identities securely and automatically

Shared

**Security Principle:** Use managed application identities instead of creating human accounts for applications to access resources and execute code. Managed application identities provide benefits such as reducing the exposure of credentials. Automate the rotation of credential to ensure the security of the identities. **Azure Guidance:** Use Azure managed identities, which can authenticate to Azure services and resources that support Microsoft Entra ID authentication. Managed identity credentials are fully managed, rotated, and protected by the platform, avoiding hard-coded credentials in source code or configuration files. For services that don't support managed identities, use Microsoft Entra ID to create a service principal with restricted permissions at the resource level. It is recommended to configure service principals with certificate credentials and fall back to client secrets for authentication. **Implementation and additional context:** Azure managed identities: https://docs.microsoft.com/azure/active-directory/managed-identities-azure-resources/overview Services that support managed identities for Azure resources: https://docs.microsoft.com/azure/active-directory/managed-identities-azure-resources/services-support-managed-identities Azure service principal: https://docs.microsoft.com/powershell/azure/create-azure-service-principal-azureps Create a service principal with certificates: https://docs.microsoft.com/azure/active-directory/develop/howto-authenticate-service-principal-powershell

n/a

Canada_Federal_PBMM_3-1-2020_AC_14

AC_14

Canada Federal PBMM 3-1-2020 AC 14

Permitted Actions Without Identification or Authentication

Permitted Actions without Identification or Authentication

Shared

1. The organization identifies user actions that can be performed on the information system without identification or authentication consistent with organizational missions/business functions. 2. The organization documents and provides supporting rationale in the security plan for the information system, user actions not requiring identification or authentication.

To ensure transparency and accountability in the system's security measures.

Canada_Federal_PBMM_3-1-2020_AC_3

AC_3

Canada Federal PBMM 3-1-2020 AC 3

Access Enforcement

Shared

The information system enforces approved authorizations for logical access to information and system resources in accordance with applicable access control policies.

To mitigate the risk of unauthorized access.

Canada_Federal_PBMM_3-1-2020_IA_1

IA_1

Canada Federal PBMM 3-1-2020 IA 1

Identification and Authentication Policy and Procedures

Shared

1. The organization Develops, documents, and disseminates to all personnel: a. An identification and authentication policy that addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and b. Procedures to facilitate the implementation of the identification and authentication policy and associated identification and authentication controls. 2. The organization Reviews and updates the current: a. Identification and authentication policy at least every 3 years; and b. Identification and authentication procedures at least annually.

To ensure secure access control and compliance with established standards.

Canada_Federal_PBMM_3-1-2020_IA_2

IA_2

Canada Federal PBMM 3-1-2020 IA 2

Identification and Authentication (Organizational Users)

Shared

The information system uniquely identifies and authenticates organizational users (or processes acting on behalf of organizational users).

To prevent unauthorized access and maintain system security.

Canada_Federal_PBMM_3-1-2020_IA_4(2)

IA_4(2)

Canada Federal PBMM 3-1-2020 IA 4(2)

Identifier Management

Identifier Management | Supervisor Authorization

Shared

The organization requires that the registration process to receive an individual identifier includes supervisor authorization.

To ensure accountability and authorization by requiring supervisor approval during the registration process for individual identifiers.

Canada_Federal_PBMM_3-1-2020_IA_4(3)

IA_4(3)

Canada Federal PBMM 3-1-2020 IA 4(3)

Identifier Management

Identifier Management | Multiple Forms of Certification

Shared

The organization requires multiple forms of certification of individual identification such as documentary evidence or a combination of documents and biometrics be presented to the registration authority.

To enhance the reliability and accuracy of individual identification.

Canada_Federal_PBMM_3-1-2020_IA_8

IA_8

Canada Federal PBMM 3-1-2020 IA 8

Identification and Authentication (Non-Organizational Users)

Shared

The information system uniquely identifies and authenticates non-organizational users (or processes acting on behalf of non-organizational users).

To ensure secure access and accountability.

CIS_Azure_1.1.0

9.5

CIS_Azure_1.1.0_9.5

CIS Microsoft Azure Foundations Benchmark recommendation 9.5

9 AppService

Ensure that Register with Azure Active Directory is enabled on App Service

Shared

The customer is responsible for implementing this recommendation.

Managed service identity in App Service makes the app more secure by eliminating secrets from the app, such as credentials in the connection strings. When registering with Azure Active Directory in the app service, the app will connect to other Azure services securely without the need of username and passwords.

CIS_Azure_1.3.0

9.5

CIS_Azure_1.3.0_9.5

CIS Microsoft Azure Foundations Benchmark recommendation 9.5

9 AppService

Ensure that Register with Azure Active Directory is enabled on App Service

Shared

The customer is responsible for implementing this recommendation.

CIS_Azure_1.4.0

9.5

CIS_Azure_1.4.0_9.5

CIS Microsoft Azure Foundations Benchmark recommendation 9.5

9 AppService

Ensure that Register with Azure Active Directory is enabled on App Service

Shared

The customer is responsible for implementing this recommendation.

CIS_Azure_2.0.0

9.5

CIS_Azure_2.0.0_9.5

CIS Microsoft Azure Foundations Benchmark recommendation 9.5

Ensure that Register with Azure Active Directory is enabled on App Service

Shared

n/a

Managed service identity in App Service provides more security by eliminating secrets from the app, such as credentials in the connection strings. When registering with Azure Active Directory in App Service, the app will connect to other Azure services securely without the need for usernames and passwords. App Service provides a highly scalable, self-patching web hosting service in Azure. It also provides a managed identity for apps, which is a turn-key solution for securing access to Azure SQL Database and other Azure services.

CIS_Controls_v8.1

4.1

CIS_Controls_v8.1_4.1

CIS Controls v8.1 4.1

Secure Configuration of Enterprise Assets and Software

Establish and maintain a secure configuration process.

Shared

1. Establish and maintain a secure configuration process for enterprise assets (end-user devices, including portable and mobile; non-computing/IoT devices; and servers) and software (operating systems and applications). 2. Review and update documentation annually, or when significant enterprise changes occur that could impact this safeguard.

To ensure data integrity and safety of enterprise assets.

CIS_Controls_v8.1

5.6

CIS_Controls_v8.1_5.6

CIS Controls v8.1 5.6

Account Management

Centralize account management

Shared

Centralize account management through a directory or identity service.

To optimize and simply the process of account management.

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

CMMC_L2_v1.9.0_AC.L2_3.1.3

IA.L2-3.5.6

CMMC_2.0_L2_IA.L2-3.5.6

404 not found

n/a

CMMC_L2_v1.9.0

AC.L2_3.1.3

Cybersecurity Maturity Model Certification (CMMC) Level 2 v1.9.0 AC.L2 3.1.3

Access Control

Control CUI Flow

Shared

Control the flow of CUI in accordance with approved authorizations.

To regulate the flow of Controlled Unclassified Information (CUI) in accordance with approved authorizations

CMMC_L2_v1.9.0

IA.L2_3.5.7

CMMC_L2_v1.9.0_IA.L2_3.5.7

Cybersecurity Maturity Model Certification (CMMC) Level 2 v1.9.0 IA.L2 3.5.7

Identification and Authentication

Password Complexity

Shared

Enforce a minimum password complexity and change of characters when new passwords are created.

To reduce the risk of unauthorized access through password guessing or brute force attacks.

DCS_02

CSA_v4.0.12_DCS_02

CSA Cloud Controls Matrix v4.0.12 DCS 02

Datacenter Security

Off-Site Transfer Authorization Policy and Procedures

Shared

n/a

Establish, document, approve, communicate, apply, evaluate and maintain policies and procedures for the relocation or transfer of hardware, software, or data/information to an offsite or alternate location. The relocation or transfer request requires the written or cryptographically verifiable authorization. Review and update the policies and procedures at least annually.

DSP_05

CSA_v4.0.12_DSP_05

CSA Cloud Controls Matrix v4.0.12 DSP 05

Data Security and Privacy Lifecycle Management

Data Flow Documentation

Shared

n/a

Create data flow documentation to identify what data is processed, stored or transmitted where. Review data flow documentation at defined intervals, at least annually, and after any change.

IAM_01

CSA_v4.0.12_IAM_01

CSA Cloud Controls Matrix v4.0.12 IAM 01

Identity & Access Management

Identity and Access Management Policy and Procedures

Shared

n/a

Establish, document, approve, communicate, implement, apply, evaluate and maintain policies and procedures for identity and access management. Review and update the policies and procedures at least annually.

IAM_02

CSA_v4.0.12_IAM_02

CSA Cloud Controls Matrix v4.0.12 IAM 02

Identity & Access Management

Strong Password Policy and Procedures

Shared

n/a

Establish, document, approve, communicate, implement, apply, evaluate and maintain strong password policies and procedures. Review and update the policies and procedures at least annually.

IAM_03

CSA_v4.0.12_IAM_03

CSA Cloud Controls Matrix v4.0.12 IAM 03

Identity & Access Management

Identity Inventory

Shared

n/a

Manage, store, and review the information of system identities, and level of access.

IAM_14

CSA_v4.0.12_IAM_14

CSA Cloud Controls Matrix v4.0.12 IAM 14

Identity & Access Management

Strong Authentication

Shared

n/a

Define, implement and evaluate processes, procedures and technical measures for authenticating access to systems, application and data assets, including multifactor authentication for at least privileged user and sensitive data access. Adopt digital certificates or alternatives which achieve an equivalent level of security for system identities.

IAM_15

CSA_v4.0.12_IAM_15

CSA Cloud Controls Matrix v4.0.12 IAM 15

Identity & Access Management

Passwords Management

Shared

n/a

Define, implement and evaluate processes, procedures and technical measures for the secure management of passwords.

Cyber_Essentials_v3.1

Cyber_Essentials_v3.1_4

Cyber Essentials v3.1 4

Cyber Essentials

User Access Control

Shared

n/a

Aim: ensure that user accounts (1) are assigned to authorised individuals only, and (2) provide access to only those applications, computers and networks the user needs to carry out their role.

EU_2555_(NIS2)_2022

EU_2555_(NIS2)_2022_21

EU 2022/2555 (NIS2) 2022 21

Cybersecurity risk-management measures

Shared

n/a

Requires essential and important entities to take appropriate measures to manage cybersecurity risks.

193

EU_GDPR_2016_679_Art._24

EU General Data Protection Regulation (GDPR) 2016/679 Art. 24

Chapter 4 - Controller and processor

Responsibility of the controller

Shared

n/a

310

EU_GDPR_2016_679_Art._25

EU General Data Protection Regulation (GDPR) 2016/679 Art. 25

Chapter 4 - Controller and processor

Data protection by design and by default

Shared

n/a

310

EU_GDPR_2016_679_Art._28

EU General Data Protection Regulation (GDPR) 2016/679 Art. 28

Chapter 4 - Controller and processor

Processor

Shared

n/a

310

FBI_Criminal_Justice_Information_Services_v5.9.5_5

EU_GDPR_2016_679_Art._32

EU General Data Protection Regulation (GDPR) 2016/679 Art. 32

Chapter 4 - Controller and processor

Security of processing

Shared

n/a

310

FBI_Criminal_Justice_Information_Services_v5.9.5_5.5

FBI Criminal Justice Information Services (CJIS) v5.9.5 5.5

Policy and Implementation - Access Control

Access Control

Shared

Refer to Section 5.13.6 for additional access control requirements related to mobile devices used to access CJI.

Access control provides the planning and implementation of mechanisms to restrict reading, writing, processing, and transmission of CJIS information and the modification of information systems, applications, services and communication configurations allowing access to CJIS information.

FBI_Criminal_Justice_Information_Services_v5.9.5_5

FBI_Criminal_Justice_Information_Services_v5.9.5_5.6

FBI Criminal Justice Information Services (CJIS) v5.9.5 5.6

Policy and Implementation - Identification And Authentication

Identification And Authentication

Shared

Ensure and maintain the proper identification and authentications measures with appropriate security safeguards to avoid issues like identity theft.

1. Identification is a unique, auditable representation of an identity within an information system usually in the form of a simple character string for each individual user, machine, software component, or any other entity. 2. Authentication refers to mechanisms or processes to verify the identity of a user, process, or device, as a prerequisite to allowing access to a system's resources.

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

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

New_Zealand_ISM_16.1.32.C.01

HITRUST_CSF_v11.3

01.q

HITRUST_CSF_v11.3_01.q

HITRUST CSF v11.3 01.q

Operating System Access Control

Prevent unauthorized access to operating systems and implement authentication technique to verify user.

Shared

1. Each user ID in the information system to be assigned to a specific named individual to ensure accountability. 2. Multi-factor authentication to be implemented for network and local access to privileged accounts. 3. Users to be uniquely identified and authenticated for local access and remote access. 4. Biometric-based electronic signatures and multifactor authentication to be implemented to ensure exclusive ownership validation and enhanced security for both remote and local network access to privileged and non-privileged accounts.

All users shall have a unique identifier (user ID) for their personal use only, and an authentication technique shall be implemented to substantiate the claimed identity of a user.

HITRUST_CSF_v11.3

09.ab

HITRUST_CSF_v11.3_09.ab

HITRUST CSF v11.3 09.ab

Monitoring

Establish procedures for monitoring use of information processing systems and facilities to check for use and effectiveness of implemented controls.

Shared

1. It is to be specified how often audit logs are reviewed, how the reviews are documented, and the specific roles and responsibilities of the personnel conducting the reviews, including the professional certifications or other qualifications required. 2. All relevant legal requirements applicable to its monitoring of authorized access and unauthorized access attempts is to be complied with.

Procedures for monitoring use of information processing systems and facilities shall be established to check for use and effectiveness of implemented controls. The results of the monitoring activities shall be reviewed regularly.

113

HITRUST_CSF_v11.3

09.w

HITRUST_CSF_v11.3_09.w

HITRUST CSF v11.3 09.w

Exchange of Information

Develop and implement policies and procedures, to protect information associated with the interconnection of business information systems.

Shared

1. A security baseline is to be documented and implemented for interconnected systems. 2. Other requirements and controls linked to interconnected business systems are to include the separation of operational systems from interconnected system, retention and back-up of information held on the system, and fallback requirements and arrangements.

Policies and procedures shall be developed and implemented to protect information associated with the interconnection of business information systems.

ISO_IEC_27002_2022

5.14

ISO_IEC_27002_2022_5.14

ISO IEC 27002 2022 5.14

Protection, Preventive Control

Information transfer

Shared

To maintain the security of information transferred within an organization and with any external interested party.

Information transfer rules, procedures, or agreements should be in place for all types of transfer facilities within the organization and between the organization and other parties.

ISO_IEC_27002_2022

5.17

ISO_IEC_27002_2022_5.17

ISO IEC 27002 2022 5.17

Protection, Preventive Control

Authentication information

Shared

Allocation and management of authentication information should be controlled by a management process, including advising personnel on the appropriate handling of authentication information.

To ensure proper entity authentication and prevent failures of authentication processes.

ISO_IEC_27017_2015

9.2.4

ISO_IEC_27017_2015_9.2.4

ISO IEC 27017 2015 9.2.4

Access Control

Management of secret authentication information of users

Shared

For Cloud Service Customer: The cloud service customer should verify that the cloud service provider's management procedure for allocating secret authentication information, such as passwords, meets the cloud service customer's requirements. For Cloud Service Provider: The cloud service provider should provide information on procedures for the management of the secret authentication information of the cloud service customer, including the procedures for allocating such information and for user authentication.

To ensure proper entity authentication and prevent failures of authentication processes.

New_Zealand_ISM

16.1.32.C.01

16. Access Control and Passwords

16.1.32.C.01 System user identification

n/a

Agencies MUST ensure that all system users are: uniquely identifiable; and authenticated on each occasion that access is granted to a system.

NIST_CSF_v2.0

PR.AA_01

NIST_CSF_v2.0_PR.AA_01

NIST CSF v2.0 PR.AA 01

PROTECT- Identity Management, Authentication, and Access

Identities and credentials for authorized users, services, and hardware are managed by the organization.

Shared

n/a

To implement safeguards for managing organization’s cybersecurity risks.

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

NIST_SP_800-171_R3_3.5.12

NIST_SP_800-171_R3_3

.1.3

NIST_SP_800-171_R3_3.1.3

NIST 800-171 R3 3.1.3

Access Control

Information Flow Enforcement

Shared

Information flow control regulates where CUI can transit within a system and between systems (versus who can access the information) and without explicit regard to subsequent accesses to that information. Flow control restrictions include keeping CUI from being transmitted in the clear to the internet, blocking outside traffic that claims to be from within the organization, restricting requests to the internet that are not from the internal web proxy server, and limiting information transfers between organizations based on data structures and content. Organizations commonly use information flow control policies and enforcement mechanisms to control the flow of CUI between designated sources and destinations (e.g., networks, individuals, and devices) within systems and between interconnected systems. Flow control is based on characteristics of the information or the information path. Enforcement occurs in boundary protection devices (e.g., encrypted tunnels, routers, gateways, and firewalls) that use rule sets or establish configuration settings that restrict system services, provide a packet-filtering capability based on header information, or provide a message-filtering capability based on message content (e.g., implementing key word searches or using document characteristics). Organizations also consider the trustworthiness of filtering and inspection mechanisms (i.e., hardware, firmware, and software components) that are critical to information flow enforcement. Transferring information between systems that represent different security domains with different security policies introduces the risk that such transfers violate one or more domain security policies. In such situations, information owners or stewards provide guidance at designated policy enforcement points between interconnected systems. Organizations consider mandating specific architectural solutions when required to enforce specific security policies. Enforcement includes prohibiting information transfers between interconnected systems (i.e., allowing information access only), employing hardware mechanisms to enforce one-way information flows, and implementing trustworthy regrading mechanisms to reassign security attributes and security labels.

Enforce approved authorizations for controlling the flow of CUI within the system and between connected systems.

NIST_SP_800-171_R3_3

.5.12

NIST 800-171 R3 3.5.12

Identification and Authentication Control

Authenticator Management

Shared

Authenticators include passwords, cryptographic devices, biometrics, certificates, one-time password devices, and ID badges. The initial authenticator content is the actual content of the authenticator (e.g., the initial password). In contrast, requirements for authenticator content contain specific characteristics. Authenticator management is supported by organization-defined settings and restrictions for various authenticator characteristics (e.g., password complexity and composition rules, validation time window for time synchronous one-time tokens, and the number of allowed rejections during the verification stage of biometric authentication). The requirement to protect individual authenticators may be implemented by 03.15.03 for authenticators in the possession of individuals and by 03.01.01, 03.01.02, 03.01.05, and 03.13.08 for authenticators stored in organizational systems. This includes passwords stored in hashed or encrypted formats or files that contain encrypted or hashed passwords accessible with administrator privileges. Actions can be taken to protect authenticators, including maintaining possession of authenticators, not sharing authenticators with others, and immediately reporting lost, stolen, or compromised authenticators. Developers may deliver 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 risk. Authenticator management includes issuing and revoking authenticators for temporary access when no longer needed. The use of long passwords or passphrases may obviate the need to periodically change authenticators.

a. Verify the identity of the individual, group, role, service, or device receiving the authenticator as part of the initial authenticator distribution. b. Establish initial authenticator content for any authenticators issued by the organization. c. Establish and implement administrative procedures for initial authenticator distribution, for lost, compromised, or damaged authenticators, and for revoking authenticators. d. Change default authenticators at first use. e. Change or refresh authenticators periodically or when the following events occur:[Assignment: organization-defined events]. f. Protect authenticator content from unauthorized disclosure and modification.

NIST_SP_800-171_R3_3

.5.7

NIST_SP_800-171_R3_3.5.7

404 not found

n/a

AC-2

NIST_SP_800-53_R4_AC-2

NIST SP 800-53 Rev. 4 AC-2

Access Control

Account Management

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

NIST_SP_800-53_R5.1.1_AC.4

NIST_SP_800-53_R5.1.1

AC.4

NIST SP 800-53 R5.1.1 AC.4

Access Control

Information Flow Enforcement

Shared

Enforce approved authorizations for controlling the flow of information within the system and between connected systems based on [Assignment: organization-defined information flow control policies].

Information flow control regulates where information can travel within a system and between systems (in contrast to who is allowed to access the information) and without regard to subsequent accesses to that information. Flow control restrictions include blocking external traffic that claims to be from within the organization, keeping export-controlled information from being transmitted in the clear to the Internet, restricting web requests that are not from the internal web proxy server, and limiting information transfers between organizations based on data structures and content. Transferring information between organizations may require an agreement specifying how the information flow is enforced (see CA-3). Transferring information between systems in different security or privacy domains with different security or privacy policies introduces the risk that such transfers violate one or more domain security or privacy policies. In such situations, information owners/stewards provide guidance at designated policy enforcement points between connected systems. Organizations consider mandating specific architectural solutions to enforce specific security and privacy policies. Enforcement includes prohibiting information transfers between connected systems (i.e., allowing access only), verifying write permissions before accepting information from another security or privacy domain or connected system, employing hardware mechanisms to enforce one-way information flows, and implementing trustworthy regrading mechanisms to reassign security or privacy attributes and labels. Organizations commonly employ information flow control policies and enforcement mechanisms to control the flow of information between designated sources and destinations within systems and between connected systems. Flow control is based on the characteristics of the information and/or the information path. Enforcement occurs, for example, in boundary protection devices that employ rule sets or establish configuration settings that restrict system services, provide a packet-filtering capability based on header information, or provide a message-filtering capability based on message content. Organizations also consider the trustworthiness of filtering and/or inspection mechanisms (i.e., hardware, firmware, and software components) that are critical to information flow enforcement. Control enhancements 3 through 32 primarily address cross-domain solution needs that focus on more advanced filtering techniques, in-depth analysis, and stronger flow enforcement mechanisms implemented in cross-domain products, such as high-assurance guards. Such capabilities are generally not available in commercial off-the-shelf products. Information flow enforcement also applies to control plane traffic (e.g., routing and DNS).

NIST_SP_800-53_R5.1.1

IA.5

NIST_SP_800-53_R5.1.1_IA.5

NIST SP 800-53 R5.1.1 IA.5

Identification and Authentication Control

Authenticator Management

Shared

Manage system authenticators by: a. Verifying, as part of the initial authenticator distribution, the identity of the individual, group, role, service, or device receiving the authenticator; b. Establishing initial authenticator content for any authenticators issued by the organization; c. Ensuring that authenticators have sufficient strength of mechanism for their intended use; d. Establishing and implementing administrative procedures for initial authenticator distribution, for lost or compromised or damaged authenticators, and for revoking authenticators; e. Changing default authenticators prior to first use; f. Changing or refreshing authenticators [Assignment: organization-defined time period by authenticator type] or when [Assignment: organization-defined events] occur; g. Protecting authenticator content from unauthorized disclosure and modification; h. Requiring individuals to take, and having devices implement, specific controls to protect authenticators; and i. Changing authenticators for group or role accounts when membership to those accounts changes.

Authenticators include passwords, cryptographic devices, biometrics, certificates, one-time password devices, and ID badges. Device authenticators include certificates and passwords. Initial authenticator content is the actual content of the authenticator (e.g., the initial password). In contrast, the requirements for authenticator content contain specific criteria or characteristics (e.g., minimum password length). Developers may deliver system components with factory default authentication credentials (i.e., passwords) to allow for initial installation and configuration. Default authentication credentials are often well known, easily discoverable, and present a significant risk. The requirement to protect individual authenticators may be implemented via control PL-4 or PS-6 for authenticators in the possession of individuals and by controls AC-3, AC-6, and SC-28 for authenticators stored in organizational systems, including passwords stored in hashed or encrypted formats or files containing encrypted or hashed passwords accessible with administrator privileges. Systems support authenticator management by organization-defined settings and restrictions for various authenticator characteristics (e.g., minimum password length, validation time window for time synchronous one-time tokens, and number of allowed rejections during the verification stage of biometric authentication). Actions can be taken to safeguard individual authenticators, including maintaining possession of authenticators, not sharing authenticators with others, and immediately reporting lost, stolen, or compromised authenticators. Authenticator management includes issuing and revoking authenticators for temporary access when no longer needed.

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.

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

NZ_ISM_v3.5_AC-2

NZISM Security Benchmark AC-2

Access Control and Passwords

16.1.32 System User Identitfication

Customer

n/a

Having uniquely identifiable system users ensures accountability.

NZISM_Security_Benchmark_v1.1

AC-2

NZISM_Security_Benchmark_v1.1_AC-2

NZISM Security Benchmark AC-2

Access Control and Passwords

16.1.32 System User Identitfication

Customer

Agencies must ensure that all users are: - uniquely identifiable - authenticated on each occasion that access is granted to a system.

Having uniquely identifiable system users ensures accountability.

14.3.12.C.01.

NZISM_v3.7_14.3.12.C.01.

NZISM v3.7 14.3.12.C.01.

Web Applications

14.3.12.C.01. - strengthening the overall security posture of the agency's network environment.

Shared

n/a

Agencies SHOULD use the Web proxy to filter content that is potentially harmful to system users and their workstations.

16.1.33.C.01.

NZISM_v3.7_16.1.33.C.01.

NZISM v3.7 16.1.33.C.01.

Identification, Authentication and Passwords

16.1.33.C.01. - promote security and accountability within the agency's systems.

Shared

n/a

Agencies MUST NOT use shared credentials to access accounts.

16.1.33.C.02.

NZISM_v3.7_16.1.33.C.02.

NZISM v3.7 16.1.33.C.02.

Identification, Authentication and Passwords

16.1.33.C.02. - promote security and accountability within the agency's systems.

Shared

n/a

Agencies SHOULD NOT use shared credentials to access accounts.

16.1.34.C.01.

NZISM_v3.7_16.1.34.C.01.

NZISM v3.7 16.1.34.C.01.

Identification, Authentication and Passwords

16.1.34.C.01. - promote security and accountability within the agency's systems.

Shared

n/a

If agencies choose to allow shared, non user-specific accounts they MUST ensure that an independent means of determining the identification of the system user is implemented.

16.1.35.C.02.

NZISM_v3.7_16.1.35.C.02.

NZISM v3.7 16.1.35.C.02.

Identification, Authentication and Passwords

16.1.35.C.02. - implement additional authentication factors to enhance security.

Shared

n/a

Agencies SHOULD ensure that they combine the use of multiple methods when identifying and authenticating system users.

16.1.36.C.01.

NZISM_v3.7_16.1.36.C.01.

NZISM v3.7 16.1.36.C.01.

Identification, Authentication and Passwords

16.1.36.C.01. - enhance overall security posture.

Shared

n/a

Agencies MUST NOT allow storage of unprotected authentication information that grants system access, or decrypts an encrypted device, to be located on, or with the system or device, to which the authentication information grants access.

16.1.37.C.01.

NZISM_v3.7_16.1.37.C.01.

NZISM v3.7 16.1.37.C.01.

Identification, Authentication and Passwords

16.1.37.C.01. - enhance overall security posture.

Shared

n/a

Agencies MUST ensure that system authentication data is protected when in transit on agency networks or All-of-Government systems.

16.1.38.C.01.

NZISM_v3.7_16.1.38.C.01.

NZISM v3.7 16.1.38.C.01.

Identification, Authentication and Passwords

16.1.38.C.01. - enhance overall security posture.

Shared

n/a

Password and other authentication data SHOULD be hashed before storage using an approved cryptographic protocol and algorithm.

16.1.39.C.01.

NZISM_v3.7_16.1.39.C.01.

NZISM v3.7 16.1.39.C.01.

Identification, Authentication and Passwords

16.1.39.C.01. - enhance overall security posture.

Shared

n/a

Where systems contain NZEO or other nationalities releasability marked or protectively marked information, agencies MUST provide a mechanism that allows system users and processes to identify users who are foreign nationals, including seconded foreign nationals.

16.1.39.C.02.

NZISM_v3.7_16.1.39.C.02.

NZISM v3.7 16.1.39.C.02.

Identification, Authentication and Passwords

16.1.39.C.02. - enhance overall security posture.

Shared

n/a

Agencies using NZEO systems SHOULD ensure that identification includes specific nationality for all foreign nationals, including seconded foreign nationals.

16.1.41.C.01.

NZISM_v3.7_16.1.41.C.01.

NZISM v3.7 16.1.41.C.01.

Identification, Authentication and Passwords

16.1.41.C.01. - enhance overall security posture.

Shared

n/a

Agencies MUST: 1. ensure that passwords are changed at least every 90 days; 2. prevent system users from changing their password more than once a day; 3. check passwords for compliance with their password selection policy where the system cannot be configured to enforce complexity requirements; and 4. force the system user to change an expired password on initial logon or if reset.

16.1.41.C.02.

NZISM_v3.7_16.1.41.C.02.

NZISM v3.7 16.1.41.C.02.

Identification, Authentication and Passwords

16.1.41.C.02. - enhance overall security posture.

Shared

n/a

Agencies MUST NOT: 1. allow predictable reset passwords; 2. reuse passwords when resetting multiple accounts; 3. store passwords in the clear on the system; 4. allow passwords to be reused within eight password changes; and 5. allow system users to use sequential passwords.

16.1.41.C.03.

NZISM_v3.7_16.1.41.C.03.

NZISM v3.7 16.1.41.C.03.

Identification, Authentication and Passwords

16.1.41.C.03. - enhance overall security posture.

Shared

n/a

Agencies SHOULD: 1. ensure that passwords are changed at least every 90 days; 2. prevent system users from changing their password more than once a day; 3. check passwords for compliance with their password selection policy where the system cannot be configured to enforce complexity requirements; and 4. force the system user to change an expired password on initial logon or if the password is reset.

16.1.41.C.04.

NZISM_v3.7_16.1.41.C.04.

NZISM v3.7 16.1.41.C.04.

Identification, Authentication and Passwords

16.1.41.C.04. - enhance overall security posture.

Shared

n/a

Agencies SHOULD NOT: 1. allow predictable reset passwords; 2. reuse passwords when resetting multiple accounts; 3. store passwords in the clear on the system; 4. allow passwords to be reused within eight password changes; and 5. allow system users to use sequential passwords.

16.1.42.C.01.

NZISM_v3.7_16.1.42.C.01.

NZISM v3.7 16.1.42.C.01.

Identification, Authentication and Passwords

16.1.42.C.01. - enhance overall security posture.

Shared

n/a

Agencies MUST ensure system users provide sufficient evidence to verify their identity when requesting a password reset for their system account.

16.1.43.C.01.

NZISM_v3.7_16.1.43.C.01.

NZISM v3.7 16.1.43.C.01.

Identification, Authentication and Passwords

16.1.43.C.01. - enhance overall security posture.

Shared

n/a

Agencies SHOULD disable LAN Manager for password authentication on workstations and servers.

2.2.2

PCI_DSS_v4.0.1_2.2.2

PCI DSS v4.0.1 2.2.2

Apply Secure Configurations to All System Components

Vendor default accounts are managed as follows: If the vendor default account(s) will be used, the default password is changed per Requirement 8.3.6. If the vendor default account(s) will not be used, the account is removed or disabled

Shared

n/a

Examine system configuration standards to verify they include managing vendor default accounts in accordance with all elements specified in this requirement. Examine vendor documentation and observe a system administrator logging on using vendor default accounts to verify accounts are implemented in accordance with all elements specified in this requirement. Examine configuration files and interview personnel to verify that all vendor default accounts that will not be used are removed or disabled

2.3.1

PCI_DSS_v4.0.1_2.3.1

PCI DSS v4.0.1 2.3.1

Apply Secure Configurations to All System Components

For wireless environments connected to the CDE or transmitting account data, all wireless vendor defaults are changed at installation or are confirmed to be secure, including but not limited to: Default wireless encryption keys. Passwords on wireless access points. SNMP defaults. Any other security-related wireless vendor defaults

Shared

n/a

Examine policies and procedures and interview responsible personnel to verify that processes are defined for wireless vendor defaults to either change them upon installation or to confirm them to be secure in accordance with all elements of this requirement. Examine vendor documentation and observe a system administrator logging into wireless devices to verify: SNMP defaults are not used. Default passwords/passphrases on wireless access points are not used. Examine vendor documentation and wireless configuration settings to verify other security-related wireless vendor defaults were changed, if applicable

3.2.1

PCI_DSS_v4.0.1_3.2.1

PCI DSS v4.0.1 3.2.1

Protect Stored Account Data

Account data storage is kept to a minimum through implementation of data retention and disposal policies, procedures, and processes that include at least the following: coverage for all locations of stored account data, coverage for any sensitive authentication data (SAD) stored prior to completion of authorization, limiting data storage amount and retention time to that which is required for legal or regulatory, and/or business requirements, specific retention requirements for stored account data that defines length of retention period and includes a documented business justification, processes for secure deletion or rendering account data unrecoverable when no longer needed per the retention policy, a process for verifying, at least once every three months, that stored account data exceeding the defined retention period has been securely deleted or rendered unrecoverable

Shared

n/a

Examine the data retention and disposal policies, procedures, and processes and interview personnel to verify processes are defined to include all elements specified in this requirement. Examine files and system records on system components where account data is stored to verify that the data storage amount and retention time does not exceed the requirements defined in the data retention policy. Observe the mechanisms used to render account data unrecoverable to verify data cannot be recovered

3.3.3

PCI_DSS_v4.0.1_3.3.3

PCI DSS v4.0.1 3.3.3

Protect Stored Account Data

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

Shared

n/a

Additional testing procedure for issuers and companies that support issuing services and store sensitive authentication data: Examine documented policies and interview personnel to verify there is a documented business justification for the storage of sensitive authentication data. Examine data stores and system configurations to verify that the sensitive authentication data is stored securely

RBI_CSF_Banks_v2016

6.4

RBI_CSF_Banks_v2016_6.4

Application Security Life Cycle (Aslc)

Application Security Life Cycle (Aslc)-6.4

n/a

Besides business functionalities, security requirements relating to system access control, authentication, transaction authorization, data integrity, system activity logging, audit trail, session management, security event tracking and exception handling are required to be clearly specified at the initial and ongoing stages of system development/acquisition/implementation.

RBI_CSF_Banks_v2016

8.4

RBI_CSF_Banks_v2016_8.4

User Access Control / Management

User Access Control / Management-8.4

n/a

Implement centralised authentication and authorisation system or accessing and administering applications, operating systems, databases, network and security devices/systems, point of connectivity (local/remote, etc.) including enforcement of strong password policy, two-factor/multi-factor authentication depending on risk assessment and following the principle of least privileges and separation of duties.

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.

Sarbanes_Oxley_Act_(1)_2022_1

Sarbanes Oxley Act 2022 1

PUBLIC LAW

Sarbanes Oxley Act 2022 (SOX)

Shared

n/a

A1.1

SOC_2023_A1.1

SOC 2023 A1.1

Additional Criteria for Availability

Effectively manage capacity demand and facilitate the implementation of additional capacity as needed.

Shared

n/a

The entity maintains, monitors, and evaluates current processing capacity and use of system components (infrastructure, data, and software) to manage capacity demand and to enable the implementation of additional capacity to help meet its objectives.

111

CC2.3

SOC_2023_CC2.3

SOC 2023 CC2.3

Information and Communication

Facilitate effective internal communication.

Shared

n/a

Entity to communicate with external parties regarding matters affecting the functioning of internal control.

218

CC5.3

SOC_2023_CC5.3

SOC 2023 CC5.3

Control Activities

Maintain alignment with organizational objectives and regulatory requirements.

Shared

n/a

Entity deploys control activities through policies that establish what is expected and in procedures that put policies into action by establishing Policies and Procedures to Support Deployment of Management’s Directives, Responsibility and Accountability for Executing Policies and Procedures, perform tasks in a timely manner, taking corrective actions, perform using competent personnel and reassess policies and procedures.

229

CC7.2

SOC_2023_CC7.2

SOC 2023 CC7.2

Systems Operations

Maintain robust security measures and ensure operational resilience.

Shared

n/a

The entity monitors system components and the operation of those components for anomalies that are indicative of malicious acts, natural disasters, and errors affecting the entity's ability to meet its objectives; anomalies are analysed to determine whether they represent security events.

167

CC7.4

SOC_2023_CC7.4

SOC 2023 CC7.4

Systems Operations

Effectively manage security incidents, minimize their impact, and protect assets, operations, and reputation.

Shared

n/a

The entity responds to identified security incidents by: a. Executing a defined incident-response program to understand, contain, remediate, and communicate security incidents by assigning roles and responsibilities; b. Establishing procedures to contain security incidents; c. Mitigating ongoing security incidents, End Threats Posed by Security Incidents; d. Restoring operations; e. Developing and Implementing Communication Protocols for Security Incidents; f. Obtains Understanding of Nature of Incident and Determines Containment Strategy; g. Remediation Identified Vulnerabilities; h. Communicating Remediation Activities; and, i. Evaluating the Effectiveness of Incident Response and periodic incident evaluations.

213

CC8.1

SOC_2023_CC8.1

SOC 2023 CC8.1

Change Management

Minimise risks, ensure quality, optimise efficiency, and enhance resilience in the face of change.

Shared

n/a

The entity authorizes, designs, develops or acquires, configures, documents, tests, approves, and implements changes to infrastructure, data, software, and procedures to meet its objectives by Managing Changes Throughout the System Life Cycle, authorizing changes, designing and developing changes, documenting all changes, tracking system changes, configuring software's, testing system changes, approving system changes, deploying system changes, identifying and evaluating system changes, creating baseline configurations for IT technologies and providing necessary changes in emergency situations.

147

PI1.3

SOC_2023_PI1.3

SOC 2023 PI1.3

Additional Criteria for Processing Integrity (Over the provision of services or the production, manufacturing, or distribution of goods)

Enhance efficiency, accuracy, and compliance with organizational standards and regulatory requirements with regards to system processing to result in products, services, and reporting to meet the entity’s objectives.

Shared

n/a

The entity implements policies and procedures over system processing to result in products, services, and reporting to meet the entity’s objectives.

1.1

SWIFT_CSCF_2024_1.1

SWIFT Customer Security Controls Framework 2024 1.1

Physical and Environmental Security

Swift Environment Protection

Shared

1. Segmentation between the user's Swift infrastructure and the larger enterprise network reduces the attack surface and has shown to be an effective way to defend against cyber-attacks that commonly involve a compromise of the general enterprise IT environment. 2. Effective segmentation includes network-level separation, access restrictions, and connectivity restrictions.

To ensure the protection of the user’s Swift infrastructure from potentially compromised elements of the general IT environment and external environment.

4.1

SWIFT_CSCF_2024_4.1

SWIFT Customer Security Controls Framework 2024 4.1

Password Management

Password Policy

Shared

1. Implementing a password policy that protects against common password attacks (for example, guessing and brute force) is effective for protecting against account compromise. Attackers often use the privileges of a compromised account to move laterally within an environment and progress the attack. 2. Another risk is the compromise of local authentication keys to tamper with the integrity of transactions. However, it is important to recognise that passwords alone are generally not sufficient in the current cyber-threat landscape. Users should consider this control in close relationship with the multi-factor authentication requirement.

To ensure passwords are sufficiently resistant against common password attacks by implementing and enforcing an effective password policy.

5.2

SWIFT_CSCF_2024_5.2

SWIFT Customer Security Controls Framework 2024 5.2

Access Control

Token Management

Shared

1. The protection of connected and disconnected hardware authentication, personal tokens or software tokens is essential to safeguard the related operator or system account. 2. It also reinforces good security practice by providing an additional layer of protection from attackers.

To ensure the proper management, tracking, and use of connected and disconnected hardware authentication or personal and software tokens (when tokens are used).

5.4

SWIFT_CSCF_2024_5.4

SWIFT Customer Security Controls Framework 2024 5.4

Password Management

Password Repository Protection

Shared

1. The secure storage of recorded passwords (repository) makes sure that passwords are not easily accessible to others, thereby protecting against simple password theft. 2. Common unsecure methods include, but are not limited to: recording passwords in a spreadsheet or a text document saved in cleartext on a desktop, or in a shared directory, or a server, saved on a mobile phone, written/printed on a post-it or a leaflet. 3. This control covers the storage of emergency, privileged or any other account passwords. 4. All accounts have to be considered because (i) combination of compromised, not-privileged, accounts, such as transaction creator account and approver account can be damageable, and (ii) even monitoring accounts provide valuable information during the reconnaissance time.

To protect physically and logically the repository of recorded passwords.

SWIFT_CSCF_v2021

2.1

SWIFT_CSCF_v2021_2.1

SWIFT CSCF v2021 2.1

Reduce Attack Surface and Vulnerabilities

Internal Data Flow Security

n/a

Ensure the confidentiality, integrity, and authenticity of application data flows between local SWIFT-related applications.

SWIFT_CSCF_v2021

5.2

SWIFT_CSCF_v2021_5.2

SWIFT CSCF v2021 5.2

Manage Identities and Segregate Privileges

Token Management

n/a

Ensure the proper management, tracking, and use of connected hardware authentication or personal tokens (if tokens are used).

SWIFT_CSCF_v2021

5.4

SWIFT_CSCF_v2021_5.4

SWIFT CSCF v2021 5.4

Manage Identities and Segregate Privileges

Physical and Logical Password Storage

n/a

Protect physically and logically repository of recorded passwords.