last sync: 2025-Mar-14 18:30:15 UTC

Key Vault secrets should have an expiration date

Azure BuiltIn Policy definition

Source Azure Portal
Display name Key Vault secrets should have an expiration date
Id 98728c90-32c7-4049-8429-847dc0f4fe37
Version 1.0.2
Details on versioning
Versioning Versions supported for Versioning: 1
1.0.2
Built-in Versioning [Preview]
Category Key Vault
Microsoft Learn
Description Secrets should have a defined expiration date and not be permanent. Secrets that are valid forever provide a potential attacker with more time to compromise them. It is a recommended security practice to set expiration dates on secrets.
Cloud environments AzureCloud = true
AzureUSGovernment = true
AzureChinaCloud = unknown
Available in AzUSGov The Policy is available in AzureUSGovernment cloud. Version: '1.0.2'
Repository: Azure-Policy 98728c90-32c7-4049-8429-847dc0f4fe37
Mode Microsoft.KeyVault.Data
Type BuiltIn
Preview False
Deprecated False
Effect Default
Audit
Allowed
Audit, Deny, Disabled
RBAC role(s) none
Rule aliases none
Rule resource types none
Compliance
The following 91 compliance controls are associated with this Policy definition 'Key Vault secrets should have an expiration date' (98728c90-32c7-4049-8429-847dc0f4fe37)
Control Domain Control Name MetadataId Category Title Owner Requirements Description Info Policy#
Azure_Security_Benchmark_v3.0 DP-6 Azure_Security_Benchmark_v3.0_DP-6 Microsoft cloud security benchmark DP-6 Data Protection Use a secure key management process Shared **Security Principle:** Document and implement an enterprise cryptographic key management standard, processes, and procedures to control your key lifecycle. When there is a need to use customer-managed key in the services, use a secured key vault service for key generation, distribution, and storage. Rotate and revoke your keys based on the defined schedule and when there is a key retirement or compromise. **Azure Guidance:** Use Azure Key Vault to create and control your encryption keys life cycle, including key generation, distribution, and storage. Rotate and revoke your keys in Azure Key Vault and your service based on the defined schedule and when there is a key retirement or compromise. When there is a need to use customer-managed key (CMK) in the workload services or applications, ensure you follow the best practices: - Use a key hierarchy to generate a separate data encryption key (DEK) with your key encryption key (KEK) in your key vault. - Ensure keys are registered with Azure Key Vault and implement via key IDs in each service or application. If you need to bring your own key (BYOK) to the services (i.e., importing HSM-protected keys from your on-premises HSMs into Azure Key Vault), follow the recommended guideline to perform the key generation and key transfer. Note: Refer to the below for the FIPS 140-2 level for Azure Key Vault types and FIPS compliance level. - Software-protected keys in vaults (Premium & Standard SKUs): FIPS 140-2 Level 1 - HSM-protected keys in vaults (Premium SKU): FIPS 140-2 Level 2 - HSM-protected keys in Managed HSM: FIPS 140-2 Level 3 **Implementation and additional context:** Azure Key Vault overview: https://docs.microsoft.com/azure/key-vault/general/overview Azure data encryption at rest--Key Hierarchy: https://docs.microsoft.com/azure/security/fundamentals/encryption-atrest#key-hierarchy BYOK(Bring Your Own Key) specification: https://docs.microsoft.com/azure/key-vault/keys/byok-specification n/a link 3
Canada_Federal_PBMM_3-1-2020 CM_8 Canada_Federal_PBMM_3-1-2020_CM_8 Canada Federal PBMM 3-1-2020 CM 8 Information System Component Inventory Information System Component Inventory Shared 1. The organization develops and documents an inventory of information system components that accurately reflects the current information system. 2. The organization develops and documents an inventory of information system components that includes all components within the authorization boundary of the information system. 3. The organization develops and documents an inventory of information system components that is at the level of granularity deemed necessary for tracking and reporting. 4. The organization develops and documents an inventory of information system components that includes unique asset identifier, NetBIOS name, baseline configuration name, OS Name, OS Version, system owner information. 5. The organization reviews and updates the information system component inventory at least monthly. To enable efficient decision-making and risk mitigation strategies. 12
Canada_Federal_PBMM_3-1-2020 CM_8(1) Canada_Federal_PBMM_3-1-2020_CM_8(1) Canada Federal PBMM 3-1-2020 CM 8(1) Information System Component Inventory Information System Component Inventory | Updates During Installations / Removals Shared The organization updates the inventory of information system components as an integral part of component installations, removals, and information system updates. To facilitate accurate asset management and effective security control implementation. 9
Canada_Federal_PBMM_3-1-2020 CM_8(2) Canada_Federal_PBMM_3-1-2020_CM_8(2) Canada Federal PBMM 3-1-2020 CM 8(2) Information System Component Inventory Information System Component Inventory | Automated Maintenance Shared The organization employs automated mechanisms to help maintain an up-to-date, complete, accurate, and readily available inventory of information system components. To facilitate accurate asset management and effective security control implementation. 9
CIS_Azure_1.1.0 8.2 CIS_Azure_1.1.0_8.2 CIS Microsoft Azure Foundations Benchmark recommendation 8.2 8 Other Security Considerations Ensure that the expiration date is set on all Secrets Shared The customer is responsible for implementing this recommendation. Ensure that all Secrets in the Azure Key Vault have an expiration time set. link 8
CIS_Azure_1.3.0 8.2 CIS_Azure_1.3.0_8.2 CIS Microsoft Azure Foundations Benchmark recommendation 8.2 8 Other Security Considerations Ensure that the expiration date is set on all Secrets Shared The customer is responsible for implementing this recommendation. Ensure that all Secrets in the Azure Key Vault have an expiration time set. link 8
CIS_Azure_1.4.0 8.3 CIS_Azure_1.4.0_8.3 CIS Microsoft Azure Foundations Benchmark recommendation 8.3 8 Other Security Considerations Ensure that the Expiration Date is set for all Secrets in RBAC Key Vaults Shared The customer is responsible for implementing this recommendation. Ensure that all Secrets in Role Based Access Control (RBAC) Azure Key Vaults have an expiration time set. link 8
CIS_Azure_1.4.0 8.4 CIS_Azure_1.4.0_8.4 CIS Microsoft Azure Foundations Benchmark recommendation 8.4 8 Other Security Considerations Ensure that the Expiration Date is set for all Secrets in Non-RBAC Key Vaults Shared The customer is responsible for implementing this recommendation. Ensure that all Secrets in Non Role Based Access Control (RBAC) Azure Key Vaults have an expiration time set. link 8
CIS_Azure_2.0.0 8.3 CIS_Azure_2.0.0_8.3 CIS Microsoft Azure Foundations Benchmark recommendation 8.3 8 Ensure that the Expiration Date is set for all Secrets in RBAC Key Vaults Shared Secrets cannot be used beyond their assigned expiry date respectively. Secrets need to be rotated periodically wherever they are used. Ensure that all Secrets in Role Based Access Control (RBAC) Azure Key Vaults have an expiration date set. The Azure Key Vault enables users to store and keep secrets within the Microsoft Azure environment. Secrets in the Azure Key Vault are octet sequences with a maximum size of 25k bytes each. The `exp` (expiration date) attribute identifies the expiration date on or after which the secret MUST NOT be used. By default, secrets never expire. It is thus recommended to rotate secrets in the key vault and set an explicit expiration date for all secrets. This ensures that the secrets cannot be used beyond their assigned lifetimes. link 8
CIS_Azure_2.0.0 8.4 CIS_Azure_2.0.0_8.4 CIS Microsoft Azure Foundations Benchmark recommendation 8.4 8 Ensure that the Expiration Date is set for all Secrets in Non-RBAC Key Vaults Shared Secrets cannot be used beyond their assigned expiry date respectively. Secrets need to be rotated periodically wherever they are used. Ensure that all Secrets in Non Role Based Access Control (RBAC) Azure Key Vaults have an expiration date set. The Azure Key Vault enables users to store and keep secrets within the Microsoft Azure environment. Secrets in the Azure Key Vault are octet sequences with a maximum size of 25k bytes each. The `exp` (expiration date) attribute identifies the expiration date on or after which the secret MUST NOT be used. By default, secrets never expire. It is thus recommended to rotate secrets in the key vault and set an explicit expiration date for all secrets. This ensures that the secrets cannot be used beyond their assigned lifetimes. link 8
CIS_Azure_Foundations_v2.1.0 8.3 CIS_Azure_Foundations_v2.1.0_8.3 CIS Azure Foundations v2.1.0 8.3 Key Vault Ensure that the Expiration Date is set for all Secrets in RBAC Key Vaults Shared n/a Ensure that the Expiration Date is set for all Secrets in RBAC Key Vaults. 1
CIS_Azure_Foundations_v2.1.0 8.4 CIS_Azure_Foundations_v2.1.0_8.4 CIS Azure Foundations v2.1.0 8.4 Key Vault Ensure that the Expiration Date is set for all Secrets in Non-RBAC Key Vaults Shared n/a Ensure that the Expiration Date is set for all Secrets in Non-RBAC Key Vaults. 1
CIS_Controls_v8.1 3.1 CIS_Controls_v8.1_3.1 CIS Controls v8.1 3.1 Data Protection Establish and maintain a data management process Shared 1. Establish and maintain a data management process. 2. In the process, address data sensitivity, data owner, handling of data, data retention limits, and disposal requirements, based on sensitivity and retention standards for the enterprise. 3. Review and update documentation annually, or when significant enterprise changes occur that could impact this safeguard. To ensure proper handling, protection, and disposal of data. 3
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. 44
CIS_Controls_v8.1 6.2 CIS_Controls_v8.1_6.2 CIS Controls v8.1 6.2 Access Control Management Establish an access revoking process Shared 1. Establish and follow a process, preferably automated, for revoking access to enterprise assets, through disabling accounts immediately upon termination, rights revocation, or role change of a user. 2. Disabling accounts, instead of deleting accounts, may be necessary to preserve audit trails. To restrict access to enterprise assets. 24
CMMC_2.0_L2 IA.L1-3.5.2 CMMC_2.0_L2_IA.L1-3.5.2 404 not found n/a n/a 15
CMMC_L2_v1.9.0 IA.L1_3.5.1 CMMC_L2_v1.9.0_IA.L1_3.5.1 Cybersecurity Maturity Model Certification (CMMC) Level 2 v1.9.0 IA.L1 3.5.1 Identification and Authentication Identification Shared Identify information system users, processes acting on behalf of users, or devices. To enable effective monitoring, authentication, and access control measures to be implemented within the system. 23
CMMC_L2_v1.9.0 SC.L2_3.13.10 CMMC_L2_v1.9.0_SC.L2_3.13.10 Cybersecurity Maturity Model Certification (CMMC) Level 2 v1.9.0 SC.L2 3.13.10 System and Communications Protection Key Management Shared Establish and manage cryptographic keys for cryptography employed in organizational systems. To protect information assets from unauthorized access, manipulation, or disclosure. 14
CSA_v4.0.12 CCC_03 CSA_v4.0.12_CCC_03 CSA Cloud Controls Matrix v4.0.12 CCC 03 Change Control and Configuration Management Change Management Technology Shared n/a Manage the risks associated with applying changes to organization assets, including application, systems, infrastructure, configuration, etc., regardless of whether the assets are managed internally or externally (i.e., outsourced). 31
CSA_v4.0.12 CEK_01 CSA_v4.0.12_CEK_01 CSA Cloud Controls Matrix v4.0.12 CEK 01 Cryptography, Encryption & Key Management Encryption and Key Management Policy and Procedures Shared n/a Establish, document, approve, communicate, apply, evaluate and maintain policies and procedures for Cryptography, Encryption and Key Management. Review and update the policies and procedures at least annually. 14
CSA_v4.0.12 CEK_02 CSA_v4.0.12_CEK_02 CSA Cloud Controls Matrix v4.0.12 CEK 02 Cryptography, Encryption & Key Management CEK Roles and Responsibilities Shared n/a Define and implement cryptographic, encryption and key management roles and responsibilities. 25
CSA_v4.0.12 CEK_03 CSA_v4.0.12_CEK_03 CSA Cloud Controls Matrix v4.0.12 CEK 03 Cryptography, Encryption & Key Management Data Encryption Shared n/a Provide cryptographic protection to data at-rest and in-transit, using cryptographic libraries certified to approved standards. 58
CSA_v4.0.12 CEK_04 CSA_v4.0.12_CEK_04 CSA Cloud Controls Matrix v4.0.12 CEK 04 Cryptography, Encryption & Key Management Encryption Algorithm Shared n/a Use encryption algorithms that are appropriate for data protection, considering the classification of data, associated risks, and usability of the encryption technology. 12
CSA_v4.0.12 CEK_05 CSA_v4.0.12_CEK_05 CSA Cloud Controls Matrix v4.0.12 CEK 05 Cryptography, Encryption & Key Management Encryption Change Management Shared n/a Establish a standard change management procedure, to accommodate changes from internal and external sources, for review, approval, implementation and communication of cryptographic, encryption and key management technology changes. 11
CSA_v4.0.12 CEK_10 CSA_v4.0.12_CEK_10 CSA Cloud Controls Matrix v4.0.12 CEK 10 Cryptography, Encryption & Key Management Key Generation Shared n/a Generate Cryptographic keys using industry accepted cryptographic libraries specifying the algorithm strength and the random number generator used. 24
CSA_v4.0.12 CEK_11 CSA_v4.0.12_CEK_11 CSA Cloud Controls Matrix v4.0.12 CEK 11 Cryptography, Encryption & Key Management Key Purpose Shared n/a Manage cryptographic secret and private keys that are provisioned for a unique purpose. 24
CSA_v4.0.12 CEK_12 CSA_v4.0.12_CEK_12 CSA Cloud Controls Matrix v4.0.12 CEK 12 Cryptography, Encryption & Key Management Key Rotation Shared n/a Rotate cryptographic keys in accordance with the calculated cryptoperiod, which includes provisions for considering the risk of information disclosure and legal and regulatory requirements. 22
CSA_v4.0.12 CEK_13 CSA_v4.0.12_CEK_13 CSA Cloud Controls Matrix v4.0.12 CEK 13 Cryptography, Encryption & Key Management Key Revocation Shared n/a Define, implement and evaluate processes, procedures and technical measures to revoke and remove cryptographic keys prior to the end of its established cryptoperiod, when a key is compromised, or an entity is no longer part of the organization, which include provisions for legal and regulatory requirements. 12
CSA_v4.0.12 CEK_14 CSA_v4.0.12_CEK_14 CSA Cloud Controls Matrix v4.0.12 CEK 14 Cryptography, Encryption & Key Management Key Destruction Shared n/a Define, implement and evaluate processes, procedures and technical measures to destroy keys stored outside a secure environment and revoke keys stored in Hardware Security Modules (HSMs) when they are no longer needed, which include provisions for legal and regulatory requirements. 12
CSA_v4.0.12 CEK_20 CSA_v4.0.12_CEK_20 CSA Cloud Controls Matrix v4.0.12 CEK 20 Cryptography, Encryption & Key Management Key Recovery Shared n/a Define, implement and evaluate processes, procedures and technical measures to assess the risk to operational continuity versus the risk of the keying material and the information it protects being exposed if control of the keying material is lost, which include provisions for legal and regulatory requirements. 25
CSA_v4.0.12 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. 52
CSA_v4.0.12 IAM_11 CSA_v4.0.12_IAM_11 CSA Cloud Controls Matrix v4.0.12 IAM 11 Identity & Access Management CSCs Approval for Agreed Privileged Access Roles Shared n/a Define, implement and evaluate processes and procedures for customers to participate, where applicable, in the granting of access for agreed, high risk (as defined by the organizational risk assessment) privileged access roles. 8
CSA_v4.0.12 IAM_13 CSA_v4.0.12_IAM_13 CSA Cloud Controls Matrix v4.0.12 IAM 13 Identity & Access Management Uniquely Identifiable Users Shared n/a Define, implement and evaluate processes, procedures and technical measures that ensure users are identifiable through unique IDs or which can associate individuals to the usage of user IDs. 49
CSA_v4.0.12 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. 32
Cyber_Essentials_v3.1 4 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. 74
EU_2555_(NIS2)_2022 EU_2555_(NIS2)_2022_21 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. 194
EU_GDPR_2016_679_Art. 24 EU_GDPR_2016_679_Art._24 EU General Data Protection Regulation (GDPR) 2016/679 Art. 24 Chapter 4 - Controller and processor Responsibility of the controller Shared n/a n/a 311
EU_GDPR_2016_679_Art. 25 EU_GDPR_2016_679_Art._25 EU General Data Protection Regulation (GDPR) 2016/679 Art. 25 Chapter 4 - Controller and processor Data protection by design and by default Shared n/a n/a 311
EU_GDPR_2016_679_Art. 28 EU_GDPR_2016_679_Art._28 EU General Data Protection Regulation (GDPR) 2016/679 Art. 28 Chapter 4 - Controller and processor Processor Shared n/a n/a 311
EU_GDPR_2016_679_Art. 32 EU_GDPR_2016_679_Art._32 EU General Data Protection Regulation (GDPR) 2016/679 Art. 32 Chapter 4 - Controller and processor Security of processing Shared n/a n/a 311
FBI_Criminal_Justice_Information_Services_v5.9.5_5 .1 FBI_Criminal_Justice_Information_Services_v5.9.5_5.1 FBI Criminal Justice Information Services (CJIS) v5.9.5 5.1 Policy and Implementation - Systems And Communications Protection Systems And Communications Protection Shared In addition, applications, services, or information systems must have the capability to ensure system integrity through the detection and protection against unauthorized changes to software and information. Examples of systems and communications safeguards range from boundary and transmission protection to securing an agency's virtualized environment. 111
FBI_Criminal_Justice_Information_Services_v5.9.5_5 .6 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. 19
FBI_Criminal_Justice_Information_Services_v5.9.5_5 .7 FBI_Criminal_Justice_Information_Services_v5.9.5_5.7 404 not found n/a n/a 96
FedRAMP_High_R4 IA-5 FedRAMP_High_R4_IA-5 FedRAMP High IA-5 Identification And Authentication Authenticator Management Shared n/a The organization manages information system authenticators by: a. Verifying, as part of the initial authenticator distribution, the identity of the individual, group, role, or device receiving the authenticator; b. Establishing initial authenticator content for authenticators defined 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/compromised or damaged authenticators, and for revoking authenticators; e. Changing default content of authenticators prior to information system installation; f. Establishing minimum and maximum lifetime restrictions and reuse conditions for authenticators; g. Changing/refreshing authenticators [Assignment: organization-defined time period by authenticator type]; h. Protecting authenticator content from unauthorized disclosure and modification; i. Requiring individuals to take, and having devices implement, specific security safeguards to protect authenticators; and j. Changing authenticators for group/role accounts when membership to those accounts changes. Supplemental Guidance: Individual authenticators include, for example, passwords, tokens, biometrics, PKI certificates, and key cards. Initial authenticator content is the actual content (e.g., the initial password) as opposed to requirements about authenticator content (e.g., minimum password length). In many cases, developers ship information 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. 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 within organizational information systems (e.g., passwords stored in hashed or encrypted formats, files containing encrypted or hashed passwords accessible with administrator privileges). Information systems support individual authenticator management by organization-defined settings and restrictions for various authenticator characteristics including, for example, minimum password length, password composition, validation time window for time synchronous one-time tokens, and number of allowed rejections during the verification stage of biometric authentication. Specific actions that can be taken to safeguard authenticators include, for example, maintaining possession of individual authenticators, not loaning or sharing individual authenticators with others, and reporting lost, stolen, or compromised authenticators immediately. Authenticator management includes issuing and revoking, when no longer needed, authenticators for temporary access such as that required for remote maintenance. Device authenticators include, for example, certificates and passwords. Related controls: AC-2, AC-3, AC-6, CM-6, IA-2, IA-4, IA-8, PL-4, PS-5, PS-6, SC-12, SC-13, SC-17, SC-28. References: OMB Memoranda 04-04, 11-11; FIPS Publication 201; NIST Special Publications 800-73, 800-63, 800-76, 800-78; FICAM Roadmap and Implementation Guidance link 18
FedRAMP_Moderate_R4 IA-5 FedRAMP_Moderate_R4_IA-5 FedRAMP Moderate IA-5 Identification And Authentication Authenticator Management Shared n/a The organization manages information system authenticators by: a. Verifying, as part of the initial authenticator distribution, the identity of the individual, group, role, or device receiving the authenticator; b. Establishing initial authenticator content for authenticators defined 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/compromised or damaged authenticators, and for revoking authenticators; e. Changing default content of authenticators prior to information system installation; f. Establishing minimum and maximum lifetime restrictions and reuse conditions for authenticators; g. Changing/refreshing authenticators [Assignment: organization-defined time period by authenticator type]; h. Protecting authenticator content from unauthorized disclosure and modification; i. Requiring individuals to take, and having devices implement, specific security safeguards to protect authenticators; and j. Changing authenticators for group/role accounts when membership to those accounts changes. Supplemental Guidance: Individual authenticators include, for example, passwords, tokens, biometrics, PKI certificates, and key cards. Initial authenticator content is the actual content (e.g., the initial password) as opposed to requirements about authenticator content (e.g., minimum password length). In many cases, developers ship information 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. 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 within organizational information systems (e.g., passwords stored in hashed or encrypted formats, files containing encrypted or hashed passwords accessible with administrator privileges). Information systems support individual authenticator management by organization-defined settings and restrictions for various authenticator characteristics including, for example, minimum password length, password composition, validation time window for time synchronous one-time tokens, and number of allowed rejections during the verification stage of biometric authentication. Specific actions that can be taken to safeguard authenticators include, for example, maintaining possession of individual authenticators, not loaning or sharing individual authenticators with others, and reporting lost, stolen, or compromised authenticators immediately. Authenticator management includes issuing and revoking, when no longer needed, authenticators for temporary access such as that required for remote maintenance. Device authenticators include, for example, certificates and passwords. Related controls: AC-2, AC-3, AC-6, CM-6, IA-2, IA-4, IA-8, PL-4, PS-5, PS-6, SC-12, SC-13, SC-17, SC-28. References: OMB Memoranda 04-04, 11-11; FIPS Publication 201; NIST Special Publications 800-73, 800-63, 800-76, 800-78; FICAM Roadmap and Implementation Guidance link 18
FFIEC_CAT_2017 3.1.2 FFIEC_CAT_2017_3.1.2 FFIEC CAT 2017 3.1.2 Cybersecurity Controls Access and Data Management Shared n/a Employee access is granted to systems and confidential data based on job responsibilities and the principles of least privilege.'FFIEC_Cybersecurity Control'!F8 - Employee access to systems and confidential data provides for separation of duties. - Elevated privileges (e.g., administrator privileges) are limited and tightly controlled (e.g., assigned to individuals, not shared, and require stronger 'FFIEC_Cybersecurity Control'!F7password controls). - User access reviews are performed periodically for all systems and applications based on the risk to the application or system. - Changes to physical and logical user access, including those that result from voluntary and involuntary terminations, are submitted to and approved by appropriate personnel. - Identification and authentication are required and managed for access to systems, applications, and hardware. - Access controls include password complexity and limits to password attempts and reuse. - All default passwords and unnecessary default accounts are changed before system implementation. - Customer access to Internet-based products or services requires authentication controls (e.g., layered controls, multifactor) that are commensurate with the risk. - Production and non-production environments are segregated to prevent unauthorized access or changes to information assets. (*N/A if no production environment exists at the institution or the institution’s third party.) - Physical security controls are used to prevent unauthorized access to information systems and telecommunication systems. - All passwords are encrypted in storage and in transit. - Confidential data are encrypted when transmitted across public or untrusted networks (e.g., Internet). - Mobile devices (e.g., laptops, tablets, and removable media) are encrypted if used to store confidential data. (*N/A if mobile devices are not used.) - Remote access to critical systems by employees, contractors, and third parties uses encrypted connections and multifactor authentication. - Administrative, physical, or technical controls are in place to prevent users without administrative responsibilities from installing unauthorized software. - Customer service (e.g., the call center) utilizes formal procedures to authenticate customers commensurate with the risk of the transaction or request. - Data is disposed of or destroyed according to documented requirements and within expected time frames. 59
HITRUST_CSF_v11.3 01.q HITRUST_CSF_v11.3_01.q HITRUST CSF v11.3 01.q Operating System Access Control To 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. 30
ISO_IEC_27002_2022 8.24 ISO_IEC_27002_2022_8.24 ISO IEC 27002 2022 8.24 Protection, Preventive Control Use of cryptography Shared Rules for the effective use of cryptography, including cryptographic key management, should be defined and implemented. To ensure proper and effective use of cryptography to protect the confidentiality, authenticity or integrity of information according to business and information security requirements, and taking into consideration legal, statutory, regulatory and contractual requirements related to cryptography. 14
ISO_IEC_27017_2015 10.1.2 ISO_IEC_27017_2015_10.1.2 ISO IEC 27017 2015 10.1.2 Cryptography Key Management Shared For Cloud Service Customer: The cloud service customer should identify the cryptographic keys for each cloud service, and implement procedures for key management. Where the cloud service provides key management functionality for use by the cloud service customer, the cloud service customer should request the following information on the procedures used to manage keys related to the cloud service: (i) type of keys; (ii) specifications of the key management system, including procedures for each stage of the key life-cycle, i.e., generating, changing or updating, storing, retiring, retrieving, retaining and destroying; (iii) recommended key management procedures for use by the cloud service customer. The cloud service customer should not permit the cloud service provider to store and manage the encryption keys for cryptographic operations when the cloud service customer employs its own key management or a separate and distinct key management service. To ensure proper and effective use of cryptography to protect the confidentiality, authenticity or integrity of information according to business and information security requirements, and taking into consideration legal, statutory, regulatory and contractual requirements related to cryptography. 14
New_Zealand_ISM 17.1.58.C.01 New_Zealand_ISM_17.1.58.C.01 New_Zealand_ISM_17.1.58.C.01 17. Cryptography 17.1.58.C.01 Key Refresh and Retirement n/a Agencies SHOULD establish cryptoperiods for all keys and cryptographic implementations in their systems and operations. 3
NIST_SP_800-171_R2_3 .5.2 NIST_SP_800-171_R2_3.5.2 NIST SP 800-171 R2 3.5.2 Identification and Authentication Authenticate (or verify) the identities of users, processes, or devices, as a prerequisite to allowing access to organizational systems. Shared Microsoft and the customer share responsibilities for implementing this requirement. Individual authenticators include the following: passwords, key cards, cryptographic devices, and one-time password devices. Initial authenticator content is the actual content of the authenticator, for example, the initial password. In contrast, the requirements about authenticator content include the minimum password length. Developers ship system components with factory default authentication credentials to allow for initial installation and configuration. Default authentication credentials are often well known, easily discoverable, and present a significant security risk. Systems support authenticator management by organization-defined settings and restrictions for various authenticator characteristics including minimum password length, validation time window for time synchronous one-time tokens, and number of allowed rejections during the verification stage of biometric authentication. Authenticator management includes issuing and revoking, when no longer needed, authenticators for temporary access such as that required for remote maintenance. Device authenticators include certificates and passwords. [SP 800-63-3] provides guidance on digital identities. link 21
NIST_SP_800-171_R3_3 .1.16 NIST_SP_800-171_R3_3.1.16 NIST 800-171 R3 3.1.16 Access Control Wireless Access Shared Establishing usage restrictions, configuration requirements, and connection requirements for wireless access to the system provides criteria to support access authorization decisions. These restrictions and requirements reduce susceptibility to unauthorized system access through wireless technologies. Wireless networks use authentication protocols that provide credential protection and mutual authentication. Organizations authenticate individuals and devices to protect wireless access to the system. Special attention is given to the variety of devices with potential wireless access to the system, including small form factor mobile devices (e.g., smart phones, smart watches). Wireless networking capabilities that are embedded within system components represent a significant potential vulnerability that can be exploited by adversaries. Disabling wireless capabilities when not needed for essential missions or business functions can help reduce susceptibility to threats by adversaries involving wireless technologies. a. Establish usage restrictions, configuration requirements, and connection requirements for each type of wireless access to the system. b. Authorize each type of wireless access to the system prior to establishing such connections. c. Disable, when not intended for use, wireless networking capabilities prior to issuance and deployment. 8
NIST_SP_800-171_R3_3 .1.5 NIST_SP_800-171_R3_3.1.5 NIST 800-171 R3 3.1.5 Access Control Least Privilege Shared Organizations employ the principle of least privilege for specific duties and authorized access for users and system processes. Least privilege is applied to the development, implementation, and operation of the system. Organizations consider creating additional processes, roles, and system accounts to achieve least privilege. Security functions include establishing system accounts and assigning privileges, installing software, configuring access authorizations, configuring settings for events to be audited, establishing vulnerability scanning parameters, and establishing intrusion detection parameters. Security-relevant information includes threat and vulnerability information, filtering rules for routers or firewalls, configuration parameters for security services, security architecture, cryptographic key management information, and access control lists. a. Allow only authorized system access for users (or processes acting on behalf of users) that is necessary to accomplish assigned organizational tasks. b. Authorize access to [Assignment: organization-defined security functions and security-relevant information]. c. Review the privileges assigned to roles or classes of users periodically to validate the need for such privileges. d. Reassign or remove privileges, as necessary. 24
NIST_SP_800-171_R3_3 .13.10 NIST_SP_800-171_R3_3.13.10 NIST 800-171 R3 3.13.10 System and Communications Protection Control Cryptographic Key Establishment and Management Shared Cryptographic key establishment and management include key generation, distribution, storage, access, rotation, and destruction. Cryptographic keys can be established and managed using either manual procedures or automated mechanisms supported by manual procedures. Organizations satisfy key establishment and management requirements in accordance with applicable federal laws, Executive Orders, policies, directives, regulations, and standards that specify appropriate options, levels, and parameters. This requirement is related to 03.13.11. Establish and manage cryptographic keys in the system in accordance with the following key management requirements: [Assignment: organization-defined requirements for key establishment and management]. 14
NIST_SP_800-171_R3_3 .5.1 NIST_SP_800-171_R3_3.5.1 404 not found n/a n/a 10
NIST_SP_800-171_R3_3 .5.5 NIST_SP_800-171_R3_3.5.5 404 not found n/a n/a 43
NIST_SP_800-53_R4 IA-5 NIST_SP_800-53_R4_IA-5 NIST SP 800-53 Rev. 4 IA-5 Identification And Authentication Authenticator Management Shared n/a The organization manages information system authenticators by: a. Verifying, as part of the initial authenticator distribution, the identity of the individual, group, role, or device receiving the authenticator; b. Establishing initial authenticator content for authenticators defined 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/compromised or damaged authenticators, and for revoking authenticators; e. Changing default content of authenticators prior to information system installation; f. Establishing minimum and maximum lifetime restrictions and reuse conditions for authenticators; g. Changing/refreshing authenticators [Assignment: organization-defined time period by authenticator type]; h. Protecting authenticator content from unauthorized disclosure and modification; i. Requiring individuals to take, and having devices implement, specific security safeguards to protect authenticators; and j. Changing authenticators for group/role accounts when membership to those accounts changes. Supplemental Guidance: Individual authenticators include, for example, passwords, tokens, biometrics, PKI certificates, and key cards. Initial authenticator content is the actual content (e.g., the initial password) as opposed to requirements about authenticator content (e.g., minimum password length). In many cases, developers ship information 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. 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 within organizational information systems (e.g., passwords stored in hashed or encrypted formats, files containing encrypted or hashed passwords accessible with administrator privileges). Information systems support individual authenticator management by organization-defined settings and restrictions for various authenticator characteristics including, for example, minimum password length, password composition, validation time window for time synchronous one-time tokens, and number of allowed rejections during the verification stage of biometric authentication. Specific actions that can be taken to safeguard authenticators include, for example, maintaining possession of individual authenticators, not loaning or sharing individual authenticators with others, and reporting lost, stolen, or compromised authenticators immediately. Authenticator management includes issuing and revoking, when no longer needed, authenticators for temporary access such as that required for remote maintenance. Device authenticators include, for example, certificates and passwords. Related controls: AC-2, AC-3, AC-6, CM-6, IA-2, IA-4, IA-8, PL-4, PS-5, PS-6, SC-12, SC-13, SC-17, SC-28. References: OMB Memoranda 04-04, 11-11; FIPS Publication 201; NIST Special Publications 800-73, 800-63, 800-76, 800-78; FICAM Roadmap and Implementation Guidance link 18
NIST_SP_800-53_R5.1.1 CM.3.6 NIST_SP_800-53_R5.1.1_CM.3.6 NIST SP 800-53 R5.1.1 CM.3.6 Configuration Management Control Configuration Change Control | Cryptography Management Shared Ensure that cryptographic mechanisms used to provide the following controls are under configuration management: [Assignment: organization-defined controls]. The controls referenced in the control enhancement refer to security and privacy controls from the control catalog. Regardless of the cryptographic mechanisms employed, processes and procedures are in place to manage those mechanisms. For example, if system components use certificates for identification and authentication, a process is implemented to address the expiration of those certificates. 3
NIST_SP_800-53_R5.1.1 IA.2 NIST_SP_800-53_R5.1.1_IA.2 NIST SP 800-53 R5.1.1 IA.2 Identification and Authentication Control Identification and Authentication (organizational Users) Shared Uniquely identify and authenticate organizational users and associate that unique identification with processes acting on behalf of those users. Organizations can satisfy the identification and authentication requirements by complying with the requirements in [HSPD 12]. Organizational users include employees or individuals who organizations consider to have an equivalent status to employees (e.g., contractors and guest researchers). Unique identification and authentication of users applies to all accesses other than those that are explicitly identified in AC-14 and that occur through the authorized use of group authenticators without individual authentication. Since processes execute on behalf of groups and roles, organizations may require unique identification of individuals in group accounts or for detailed accountability of individual activity. Organizations employ passwords, physical authenticators, or biometrics to authenticate user identities or, in the case of multi-factor authentication, some combination thereof. Access to organizational systems is defined as either local access or network access. Local access is any access to organizational systems by users or processes acting on behalf of users, where access is obtained through direct connections without the use of networks. Network access is access to organizational systems by users (or processes acting on behalf of users) where access is obtained through network connections (i.e., nonlocal accesses). Remote access is a type of network access that involves communication through external networks. Internal networks include local area networks and wide area networks. The use of encrypted virtual private networks for network connections between organization-controlled endpoints and non-organization-controlled endpoints may be treated as internal networks with respect to protecting the confidentiality and integrity of information traversing the network. Identification and authentication requirements for non-organizational users are described in IA-8. 8
NIST_SP_800-53_R5.1.1 SC.12 NIST_SP_800-53_R5.1.1_SC.12 NIST SP 800-53 R5.1.1 SC.12 System and Communications Protection Cryptographic Key Establishment and Management Shared Establish and manage cryptographic keys when cryptography is employed within the system in accordance with the following key management requirements: [Assignment: organization-defined requirements for key generation, distribution, storage, access, and destruction]. Cryptographic key management and establishment can be performed using manual procedures or automated mechanisms with supporting manual procedures. Organizations define key management requirements in accordance with applicable laws, executive orders, directives, regulations, policies, standards, and guidelines and specify appropriate options, parameters, and levels. Organizations manage trust stores to ensure that only approved trust anchors are part of such trust stores. This includes certificates with visibility external to organizational systems and certificates related to the internal operations of systems. [NIST CMVP] and [NIST CAVP] provide additional information on validated cryptographic modules and algorithms that can be used in cryptographic key management and establishment. 13
NIST_SP_800-53_R5 IA-5 NIST_SP_800-53_R5_IA-5 NIST SP 800-53 Rev. 5 IA-5 Identification and Authentication Authenticator Management Shared n/a 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. link 18
NZ_ISM_v3.5 CR-15 NZ_ISM_v3.5_CR-15 NZISM Security Benchmark CR-15 Cryptography 17.9.25 Contents of KMPs Customer n/a When agencies implement the recommended contents for Key Management Plans (KMPs) they will have a good starting point for the protection of cryptographic systems and their material within their agencies. link 4
NZISM_v3.7 16.3.5.C.01. NZISM_v3.7_16.3.5.C.01. NZISM v3.7 16.3.5.C.01. Privileged User Access 16.3.5.C.01. - To enhance overall security posture. Shared n/a Agencies MUST: 1. ensure strong change management practices are implemented; 2. ensure that the use of privileged accounts is controlled and accountable; 3. ensure that system administrators are assigned and consistently use, an individual account for the performance of their administration tasks; 4. keep privileged accounts to a minimum; and 5. allow the use of privileged accounts for administrative work only. 5
NZISM_v3.7 16.3.5.C.02. NZISM_v3.7_16.3.5.C.02. NZISM v3.7 16.3.5.C.02. Privileged User Access 16.3.5.C.02. - To enhance overall security posture. Shared n/a Agencies SHOULD: 1. ensure strong change management practices are implemented; 2. ensure that the use of privileged accounts is controlled and accountable; 3. ensure that system administrators are assigned an individual account for the performance of their administration tasks; 4. keep privileged accounts to a minimum; and 5. allow the use of privileged accounts for administrative work only. 5
NZISM_v3.7 16.5.10.C.02. NZISM_v3.7_16.5.10.C.02. NZISM v3.7 16.5.10.C.02. Remote Access 16.5.10.C.02. - To enhance security and reduce the risk of unauthorized access or misuse. Shared n/a Agencies SHOULD authenticate both the remote system user and device during the authentication process. 21
NZISM_v3.7 19.1.22.C.02. NZISM_v3.7_19.1.22.C.02. NZISM v3.7 19.1.22.C.02. Gateways 19.1.22.C.02. - To ensure transparency, accountability, and adherence to established procedures for maintaining network security and integrity. Shared n/a Agencies MUST document any changes to gateways in accordance with the agency's Change Management Policy. 5
NZISM_v3.7 3.3.6.C.05. NZISM_v3.7_3.3.6.C.05. NZISM v3.7 3.3.6.C.05. Information Technology Security Managers 3.3.6.C.05. - To enhance the integrity and security of agency IT operations. Shared n/a ITSMs SHOULD be included in the agency's change management and change control processes to ensure that risks are properly identified and controls are properly applied to manage those risks. 5
NZISM_v3.7 6.3.6.C.01. NZISM_v3.7_6.3.6.C.01. NZISM v3.7 6.3.6.C.01. Change Management 6.3.6.C.01. - To maintain the integrity and security of systems. Shared n/a Agencies MUST ensure that for routine and urgent changes: 1. the change management process, as defined in the relevant information security documentation, is followed; 2. the proposed change is approved by the relevant authority; 3. any proposed change that could impact the security or accreditation status of a system is submitted to the Accreditation Authority for approval; and 4. all associated information security documentation is updated to reflect the change. 5
NZISM_v3.7 6.3.6.C.02. NZISM_v3.7_6.3.6.C.02. NZISM v3.7 6.3.6.C.02. Change Management 6.3.6.C.02. - To maintain operational integrity and security posture. Shared n/a Agencies SHOULD ensure that for routine and urgent changes: 1. the change management process, as defined in the relevant information security documentation, is followed; 2. the proposed change is approved by the relevant authority; 3. any proposed change that could impact the security of a system or accreditation status is submitted to the Accreditation Authority for approval; and 4. all associated information security documentation is updated to reflect the change. 5
NZISM_v3.7 6.3.7.C.01. NZISM_v3.7_6.3.7.C.01. NZISM v3.7 6.3.7.C.01. Change Management 6.3.7.C.01. - To foster systematic and responsive management of critical alterations. Shared n/a An agency's change management process MUST define appropriate actions to be followed before and after urgent changes are implemented. 4
NZISM_v3.7 6.3.7.C.02. NZISM_v3.7_6.3.7.C.02. NZISM v3.7 6.3.7.C.02. Change Management 6.3.7.C.02. - To facilitate structured management of critical alterations. Shared n/a An agency's change management process SHOULD define appropriate actions to be followed before and after urgent changes are implemented. 4
NZISM_v3.7 6.3.7.C.03. NZISM_v3.7_6.3.7.C.03. NZISM v3.7 6.3.7.C.03. Change Management 6.3.7.C.03. - To ensure systematic and effective management of changes. Shared n/a Agencies SHOULD follow this change management process outline: 1. produce a written change request; 2. submit the change request to all stakeholders for approval; 3. document the changes to be implemented; 4. test the approved changes; 5. notification to user of the change schedule and likely effect or outage; 6. implement the approved changes after successful testing; 7. update the relevant information security documentation including the SRMP, SSP and SOPs 8. notify and educate system users of the changes that have been implemented as close as possible to the time the change is applied; and 9. continually educate system users in regards to changes. 4
PCI_DSS_v4.0.1 3.6.1 PCI_DSS_v4.0.1_3.6.1 PCI DSS v4.0.1 3.6.1 Protect Stored Account Data Procedures are defined and implemented to protect cryptographic keys used to protect stored account data against disclosure and misuse that include: access to keys is restricted to the fewest number of custodians necessary. Key-encrypting keys are at least as strong as the data-encrypting keys they protect. Key-encrypting keys are stored separately from data-encrypting keys. Keys are stored securely in the fewest possible locations and forms Shared n/a Examine documented key-management policies and procedures to verify that processes to protect cryptographic keys used to protect stored account data against disclosure and misuse are defined to include all elements specified in this requirement 16
PCI_DSS_v4.0.1 3.6.1.1 PCI_DSS_v4.0.1_3.6.1.1 PCI DSS v4.0.1 3.6.1.1 Protect Stored Account Data Additional requirement for service providers only: A documented description of the cryptographic architecture is maintained that includes: details of all algorithms, protocols, and keys used for the protection of stored account data, including key strength and expiry date. Preventing the use of the same cryptographic keys in production and test environments. Description of the key usage for each key. Inventory of any hardware security modules (HSMs), key management systems (KMS), and other secure cryptographic devices (SCDs) used for key management, including type and location of devices, to support meeting Requirement 12.3.4 Shared n/a Additional testing procedure for service provider assessments only: Interview responsible personnel and examine documentation to verify that a document exists to describe the cryptographic architecture that includes all elements specified in this requirement 14
PCI_DSS_v4.0.1 3.7.1 PCI_DSS_v4.0.1_3.7.1 PCI DSS v4.0.1 3.7.1 Protect Stored Account Data Key-management policies and procedures are implemented to include generation of strong cryptographic keys used to protect stored account data Shared n/a Examine the documented key-management policies and procedures for keys used for protection of stored account data to verify that they define generation of strong cryptographic keys. Observe the method for generating keys to verify that strong keys are generated 16
PCI_DSS_v4.0.1 3.7.2 PCI_DSS_v4.0.1_3.7.2 PCI DSS v4.0.1 3.7.2 Protect Stored Account Data Key-management policies and procedures are implemented to include secure distribution of cryptographic keys used to protect stored account data Shared n/a Examine the documented key-management policies and procedures for keys used for protection of stored account data to verify that they define secure distribution of cryptographic keys. Observe the method for distributing keys to verify that keys are distributed securely 16
PCI_DSS_v4.0.1 3.7.3 PCI_DSS_v4.0.1_3.7.3 PCI DSS v4.0.1 3.7.3 Protect Stored Account Data Key-management policies and procedures are implemented to include secure storage of cryptographic keys used to protect stored account data Shared n/a Examine the documented key-management policies and procedures for keys used for protection of stored account data to verify that they define secure storage of cryptographic keys. Observe the method for storing keys to verify that keys are stored securely 14
PCI_DSS_v4.0.1 3.7.5 PCI_DSS_v4.0.1_3.7.5 PCI DSS v4.0.1 3.7.5 Protect Stored Account Data Key management policies procedures are implemented to include the retirement, replacement, or destruction of keys used to protect stored account data, as deemed necessary when: the key has reached the end of its defined cryptoperiod. The integrity of the key has been weakened, including when personnel with knowledge of a cleartext key component leaves the company, or the role for which the key component was known. The key is suspected of or known to be compromised. Retired or replaced keys are not used for encryption operations Shared n/a Examine the documented key-management policies and procedures for keys used for protection of stored account data and verify that they define retirement, replacement, or destruction of keys in accordance with all elements specified in this requirement. Interview personnel to verify that processes are implemented in accordance with all elements specified in this requirement 14
PCI_DSS_v4.0.1 3.7.6 PCI_DSS_v4.0.1_3.7.6 PCI DSS v4.0.1 3.7.6 Protect Stored Account Data Where manual cleartext cryptographic key-management operations are performed by personnel, key-management policies and procedures are implemented, including managing these operations using split knowledge and dual control Shared n/a Examine the documented key-management policies and procedures for keys used for protection of stored account data and verify that they define using split knowledge and dual control. Interview personnel and/or observe processes to verify that manual cleartext keys are managed with split knowledge and dual control 16
PCI_DSS_v4.0.1 3.7.7 PCI_DSS_v4.0.1_3.7.7 PCI DSS v4.0.1 3.7.7 Protect Stored Account Data Key management policies and procedures are implemented to include the prevention of unauthorized substitution of cryptographic keys Shared n/a Examine the documented key-management policies and procedures for keys used for protection of stored account data and verify that they define prevention of unauthorized substitution of cryptographic keys. Interview personnel and/or observe processes to verify that unauthorized substitution of keys is prevented 14
PCI_DSS_v4.0.1 3.7.8 PCI_DSS_v4.0.1_3.7.8 PCI DSS v4.0.1 3.7.8 Protect Stored Account Data Key management policies and procedures are implemented to include that cryptographic key custodians formally acknowledge (in writing or electronically) that they understand and accept their key-custodian responsibilities Shared n/a Examine the documented key-management policies and procedures for keys used for protection of stored account data and verify that they define acknowledgments for key custodians in accordance with all elements specified in this requirement. Examine documentation or other evidence showing that key custodians have provided acknowledgments in accordance with all elements specified in this requirement 14
RBI_ITF_NBFC_v2017 3.1.h RBI_ITF_NBFC_v2017_3.1.h RBI IT Framework 3.1.h Information and Cyber Security Public Key Infrastructure (PKI)-3.1 n/a The IS Policy must provide for a IS framework with the following basic tenets: Public Key Infrastructure (PKI) - NBFCs may increase the usage of PKI to ensure confidentiality of data, access control, data integrity, authentication and nonrepudiation. link 31
SOC_2 CC6.1 SOC_2_CC6.1 SOC 2 Type 2 CC6.1 Logical and Physical Access Controls Logical access security software, infrastructure, and architectures Shared The customer is responsible for implementing this recommendation. The following points of focus, specifically related to all engagements using the trust services criteria, highlight important characteristics relating to this criterion: • Identifies and Manages the Inventory of Information Assets — The entity identifies, Page 29 TSP Ref. # TRUST SERVICES CRITERIA AND POINTS OF FOCUS inventories, classifies, and manages information assets. • Restricts Logical Access — Logical access to information assets, including hardware, data (at-rest, during processing, or in transmission), software, administrative authorities, mobile devices, output, and offline system components is restricted through the use of access control software and rule sets. • Identifies and Authenticates Users — Persons, infrastructure, and software are identified and authenticated prior to accessing information assets, whether locally or remotely. • Considers Network Segmentation — Network segmentation permits unrelated portions of the entity's information system to be isolated from each other. • Manages Points of Access — Points of access by outside entities and the types of data that flow through the points of access are identified, inventoried, and managed. The types of individuals and systems using each point of access are identified, documented, and managed. • Restricts Access to Information Assets — Combinations of data classification, separate data structures, port restrictions, access protocol restrictions, user identification, and digital certificates are used to establish access-control rules for information assets. • Manages Identification and Authentication — Identification and authentication requirements are established, documented, and managed for individuals and systems accessing entity information, infrastructure, and software. • Manages Credentials for Infrastructure and Software — New internal and external infrastructure and software are registered, authorized, and documented prior to being granted access credentials and implemented on the network or access point. Credentials are removed and access is disabled when access is no longer required or the infrastructure and software are no longer in use. • Uses Encryption to Protect Data — The entity uses encryption to supplement other measures used to protect data at rest, when such protections are deemed appropriate based on assessed risk. • Protects Encryption Keys — Processes are in place to protect encryption keys during generation, storage, use, and destruction 75
SOC_2023 CC2.3 SOC_2023_CC2.3 SOC 2023 CC2.3 Information and Communication To facilitate effective internal communication. Shared n/a Entity to communicate with external parties regarding matters affecting the functioning of internal control. 218
SOC_2023 CC5.3 SOC_2023_CC5.3 SOC 2023 CC5.3 Control Activities To 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
SOC_2023 CC6.1 SOC_2023_CC6.1 SOC 2023 CC6.1 Logical and Physical Access Controls To mitigate security events and ensuring the confidentiality, integrity, and availability of critical information assets. Shared n/a Entity implements logical access security software, infrastructure, and architectures over protected information assets to protect them from security events to meet the entity's objectives by identifying and managing the inventory of information assets, restricting logical access, identification and authentication of users, consider network segmentation, manage points of access, restricting access of information assets, managing identification and authentication, managing credentials for infrastructure and software, using encryption to protect data and protect using encryption keys. 128
SOC_2023 CC7.4 SOC_2023_CC7.4 SOC 2023 CC7.4 Systems Operations To 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
SOC_2023 CC8.1 SOC_2023_CC8.1 SOC 2023 CC8.1 Change Management To 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
SOC_2023 CC9.1 SOC_2023_CC9.1 SOC 2023 CC9.1 Risk Mitigation To enhance resilience and ensure continuity of critical operations in the face of adverse events or threats. Shared n/a Entity identifies, selects, and develops risk mitigation activities for risks arising from potential business disruptions. 18
SWIFT_CSCF_2024 4.2 SWIFT_CSCF_2024_4.2 SWIFT Customer Security Controls Framework 2024 4.2 Access Control Multi-Factor Authentication Shared 1. Multi-factor authentication requires the presentation of two or more of the following common authentication factors: (A). Knowledge factor: something the operator knows (for example, a password) (B). Possession factor: something the operator has (for example, connected USB tokens or smart cards, or disconnected tokens such as a (time based) one-time password- (T)OTP- generator or application storing a cryptographic private key that runs on another device like operator’s mobile phone considered as a software token, RSA token, 3-Skey Digital and its mobile version considered as a software token, or Digipass) (C). Inherence factor: something the operator is (for example, biometrics such as fingerprints, retina scans, or voice recognition) Implementing multi-factor authentication provides an additional layer of protection against common authentication attacks (for example, shoulder surfing, password re-use, or weak passwords) and provides further protection from account compromises for malicious transaction processing. Attackers often use the privileges of a compromised account to move laterally within an environment and to progress an attack. To prevent that a compromise of a single authentication factor allows access into Swift-related systems or applications by implementing multi-factor authentication. 11
UK_NCSC_CAF_v3.2 B2.a UK_NCSC_CAF_v3.2_B2.a NCSC Cyber Assurance Framework (CAF) v3.2 B2.a Identity and Access Control Identity Verification, Authentication and Authorisation Shared 1. The process of initial identity verification is robust enough to provide a high level of confidence of a user’s identity profile before allowing an authorised user access to networks and information systems that support the essential function. 2. Only authorised and individually authenticated users can physically access and logically connect to the networks or information systems on which that essential function depends. 3. The number of authorised users and systems that have access to all the networks and information systems supporting the essential function is limited to the minimum necessary. 4. Use additional authentication mechanisms, such as multi-factor (MFA), for privileged access to all systems that operate or support the essential function. 5. Use additional authentication mechanisms, such as multi-factor (MFA), when there is individual authentication and authorisation of all remote user access to all the networks and information systems that support the essential function. 6. The list of users and systems with access to networks and systems supporting and delivering the essential functions reviewed on a regular basis, at least every six months. The organisation understands, documents and manages access to networks and information systems supporting the operation of essential functions. Users (or automated functions) that can access data or systems are appropriately verified, authenticated and authorised. Robustly verify, authenticate and authorise access to the networks and information systems supporting the essential function. 32
Initiatives usage
Initiative DisplayName Initiative Id Initiative Category State Type polSet in AzUSGov
[Deprecated]: New Zealand ISM Restricted v3.5 93d2179e-3068-c82f-2428-d614ae836a04 Regulatory Compliance Deprecated BuiltIn unknown
[Preview]: CMMC 2.0 Level 2 4e50fd13-098b-3206-61d6-d1d78205cb45 Regulatory Compliance Preview BuiltIn true
[Preview]: Reserve Bank of India - IT Framework for NBFC 7f89f09c-48c1-f28d-1bd5-84f3fb22f86c Regulatory Compliance Preview BuiltIn unknown
Canada Federal PBMM 3-1-2020 f8f5293d-df94-484a-a3e7-6b422a999d91 Regulatory Compliance GA BuiltIn unknown
CIS Azure Foundations v2.1.0 fe7782e4-6ff3-4e39-8d8a-64b6f7b82c85 Regulatory Compliance GA BuiltIn unknown
CIS Controls v8.1 046796ef-e8a7-4398-bbe9-cce970b1a3ae Regulatory Compliance GA BuiltIn unknown
CIS Microsoft Azure Foundations Benchmark v1.1.0 1a5bb27d-173f-493e-9568-eb56638dde4d Regulatory Compliance GA BuiltIn true
CIS Microsoft Azure Foundations Benchmark v1.3.0 612b5213-9160-4969-8578-1518bd2a000c Regulatory Compliance GA BuiltIn true
CIS Microsoft Azure Foundations Benchmark v1.4.0 c3f5c4d9-9a1d-4a99-85c0-7f93e384d5c5 Regulatory Compliance GA BuiltIn unknown
CIS Microsoft Azure Foundations Benchmark v2.0.0 06f19060-9e68-4070-92ca-f15cc126059e Regulatory Compliance GA BuiltIn unknown
CSA CSA Cloud Controls Matrix v4.0.12 8791506a-dec4-497a-a83f-3abfde37c400 Regulatory Compliance GA BuiltIn unknown
Cyber Essentials v3.1 b2f588d7-1ed5-47c7-977d-b93dff520c4c Regulatory Compliance GA BuiltIn unknown
Cybersecurity Maturity Model Certification (CMMC) Level 2 v1.9.0 a4087154-2edb-4329-b56a-1cc986807f3c Regulatory Compliance GA BuiltIn unknown
Enforce recommended guardrails for Azure Key Vault Enforce-Guardrails-KeyVault Key Vault GA ALZ
EU 2022/2555 (NIS2) 2022 42346945-b531-41d8-9e46-f95057672e88 Regulatory Compliance GA BuiltIn unknown
EU General Data Protection Regulation (GDPR) 2016/679 7326812a-86a4-40c8-af7c-8945de9c4913 Regulatory Compliance GA BuiltIn unknown
FBI Criminal Justice Information Services (CJIS) v5.9.5 4fcabc2a-30b2-4ba5-9fbb-b1a4e08fb721 Regulatory Compliance GA BuiltIn unknown
FedRAMP High d5264498-16f4-418a-b659-fa7ef418175f Regulatory Compliance GA BuiltIn true
FedRAMP Moderate e95f5a9f-57ad-4d03-bb0b-b1d16db93693 Regulatory Compliance GA BuiltIn true
FFIEC CAT 2017 1d5dbdd5-6f93-43ce-a939-b19df3753cf7 Regulatory Compliance GA BuiltIn unknown
HITRUST CSF v11.3 e0d47b75-5d99-442a-9d60-07f2595ab095 Regulatory Compliance GA BuiltIn unknown
ISO/IEC 27002 2022 e3030e83-88d5-4f23-8734-6577a2c97a32 Regulatory Compliance GA BuiltIn unknown
ISO/IEC 27017 2015 f48ecfa6-581c-43f9-8141-cd4adc72cf26 Regulatory Compliance GA BuiltIn unknown
Microsoft cloud security benchmark 1f3afdf9-d0c9-4c3d-847f-89da613e70a8 Security Center GA BuiltIn true
NCSC Cyber Assurance Framework (CAF) v3.2 6d220abf-cf6f-4b17-8f7e-0644c4cc84b4 Regulatory Compliance GA BuiltIn unknown
New Zealand ISM 4f5b1359-4f8e-4d7c-9733-ea47fcde891e Regulatory Compliance GA BuiltIn unknown
NIST 800-171 R3 38916c43-6876-4971-a4b1-806aa7e55ccc Regulatory Compliance GA BuiltIn unknown
NIST SP 800-171 Rev. 2 03055927-78bd-4236-86c0-f36125a10dc9 Regulatory Compliance GA BuiltIn true
NIST SP 800-53 R5.1.1 60205a79-6280-4e20-a147-e2011e09dc78 Regulatory Compliance GA BuiltIn unknown
NIST SP 800-53 Rev. 4 cf25b9c1-bd23-4eb6-bd2c-f4f3ac644a5f Regulatory Compliance GA BuiltIn true
NIST SP 800-53 Rev. 5 179d1daa-458f-4e47-8086-2a68d0d6c38f Regulatory Compliance GA BuiltIn true
NZISM v3.7 4476df0a-18ab-4bfe-b6ad-cccae1cf320f Regulatory Compliance GA BuiltIn unknown
PCI DSS v4.0.1 a06d5deb-24aa-4991-9d58-fa7563154e31 Regulatory Compliance GA BuiltIn unknown
SOC 2 Type 2 4054785f-702b-4a98-9215-009cbd58b141 Regulatory Compliance GA BuiltIn true
SOC 2023 53ad89f5-8542-49e9-ba81-1cbd686e0d52 Regulatory Compliance GA BuiltIn unknown
SWIFT Customer Security Controls Framework 2024 7499005e-df5a-45d9-810f-041cf346678c Regulatory Compliance GA BuiltIn unknown
History
Date/Time (UTC ymd) (i) Change type Change detail
2021-08-30 14:27:30 change Patch, old suffix: preview (1.0.1-preview > 1.0.2)
2020-12-11 15:42:52 change Patch, suffix remains equal (1.0.0-preview > 1.0.1-preview)
2020-10-16 12:27:50 add 98728c90-32c7-4049-8429-847dc0f4fe37
JSON compare
compare mode: version left: version right:
JSON
api-version=2021-06-01
EPAC