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 |