compliance controls are associated with this Policy definition 'Key vaults should have soft delete enabled' (1e66c121-a66a-4b1f-9b83-0fd99bf0fc2d)
| Control Domain |
Control |
Name |
MetadataId |
Category |
Title |
Owner |
Requirements |
Description |
Info |
Policy# |
| Azure_Security_Benchmark_v2.0 |
BR-4 |
Azure_Security_Benchmark_v2.0_BR-4 |
Azure Security Benchmark BR-4 |
Backup and Recovery |
Mitigate risk of lost keys |
Customer |
Ensure you have measures in place to prevent and recover from loss of keys. Enable soft delete and purge protection in Azure Key Vault to protect keys against accidental or malicious deletion.
How to enable soft delete and purge protection in Key Vault: https://docs.microsoft.com/azure/storage/blobs/storage-blob-soft-delete?tabs=azure-portal |
n/a |
link |
2 |
| Azure_Security_Benchmark_v3.0 |
DP-8 |
Azure_Security_Benchmark_v3.0_DP-8 |
Microsoft cloud security benchmark DP-8 |
Data Protection |
Ensure security of key and certificate repository |
Shared |
**Security Principle:**
Ensure the security of the key vault service used for the cryptographic key and certificate lifecycle management. Harden your key vault service through access control, network security, logging and monitoring and backup to ensure keys and certificates are always protected using the maximum security.
**Azure Guidance:**
Secure your cryptographic keys and certificates by hardening your Azure Key Vault service through the following controls:
- Restrict the access to keys and certificates in Azure Key Vault using built-in access policies or Azure RBAC to ensure the least privileges principle are in place for management plane access and data plane access.
- Secure the Azure Key Vault using Private Link and Azure Firewall to ensure the minimal exposure of the service
- Ensure separation of duties is place for users who manages encryption keys not have the ability to access encrypted data, and vice versa.
- Use managed identity to access keys stored in the Azure Key Vault in your workload applications.
- Never have the keys stored in plaintext format outside of the Azure Key Vault.
- When purging data, ensure your keys are not deleted before the actual data, backups and archives are purged.
- Backup your keys and certificates using the Azure Key Vault. Enable soft delete and purge protection to avoid accidental deletion of keys.
- Turn on Azure Key Vault logging to ensure the critical management plane and data plane activities are logged.
**Implementation and additional context:**
Azure Key Vault overview:
https://docs.microsoft.com/azure/key-vault/general/overview
Azure Key Vault security best practices:
https://docs.microsoft.com/azure/key-vault/general/best-practices
Use managed identity to access Azure Key Vault:
https://docs.microsoft.com/azure/active-directory/managed-identities-azure-resources/tutorial-windows-vm-access-nonaad
|
n/a |
link |
6 |
| CIS_Azure_2.0.0 |
8.5 |
CIS_Azure_2.0.0_8.5 |
CIS Microsoft Azure Foundations Benchmark recommendation 8.5 |
8 |
Ensure the Key Vault is Recoverable |
Shared |
Once purge-protection and soft-delete are enabled for a Key Vault, the action is irreversible. |
The Key Vault contains object keys, secrets, and certificates. Accidental unavailability of a Key Vault can cause immediate data loss or loss of security functions (authentication, validation, verification, non-repudiation, etc.) supported by the Key Vault objects.
It is recommended the Key Vault be made recoverable by enabling the "Do Not Purge" and "Soft Delete" functions. This is in order to prevent loss of encrypted data, including storage accounts, SQL databases, and/or dependent services provided by Key Vault objects (Keys, Secrets, Certificates) etc. This may happen in the case of accidental deletion by a user or from disruptive activity by a malicious user.
WARNING: A current limitation of the soft-delete feature across all Azure services is role assignments disappearing when Key Vault is deleted. All role assignments will need to be recreated after recovery.
There could be scenarios where users accidentally run delete/purge commands on Key Vault or an attacker/malicious user deliberately does so in order to cause disruption.
Deleting or purging a Key Vault leads to immediate data loss, as keys encrypting data and secrets/certificates allowing access/services will become non-accessible.
There are 2 Key Vault properties that play a role in permanent unavailability of a Key Vault:
1. `enableSoftDelete`:
Setting this parameter to "true" for a Key Vault ensures that even if Key Vault is deleted, Key Vault itself or its objects remain recoverable for the next 90 days. Key Vault/objects can either be recovered or purged (permanent deletion) during those 90 days. If no action is taken, key vault and its objects will subsequently be purged.
2. `enablePurgeProtection`:
enableSoftDelete only ensures that Key Vault is not deleted permanently and will be recoverable for 90 days from date of deletion. However, there are scenarios in which the Key Vault and/or its objects are accidentally purged and hence will not be recoverable. Setting enablePurgeProtection to "true" ensures that the Key Vault and its objects cannot be purged.
Enabling both the parameters on Key Vaults ensures that Key Vaults and their objects cannot be deleted/purged permanently. |
link |
2 |
| CMMC_2.0_L2 |
MP.L2-3.8.9 |
CMMC_2.0_L2_MP.L2-3.8.9 |
404 not found |
|
|
|
n/a |
n/a |
|
6 |
| CMMC_L3 |
SC.3.187 |
CMMC_L3_SC.3.187 |
CMMC L3 SC.3.187 |
System and Communications Protection |
Establish and manage cryptographic keys for cryptography employed in organizational systems. |
Shared |
Microsoft and the customer share responsibilities for implementing this requirement. |
Cryptographic key management and establishment can be performed using manual procedures or mechanisms supported by manual procedures. Organizations define key management requirements in accordance with applicable federal laws, Executive Orders, policies, directives, regulations, and standards specifying appropriate options, levels, and parameters. |
link |
8 |
| FedRAMP_High_R4 |
CP-9 |
FedRAMP_High_R4_CP-9 |
FedRAMP High CP-9 |
Contingency Planning |
Information System Backup |
Shared |
n/a |
The organization:
a. Conducts backups of user-level information contained in the information system [Assignment: organization-defined frequency consistent with recovery time and recovery point objectives];
b. Conducts backups of system-level information contained in the information system [Assignment: organization-defined frequency consistent with recovery time and recovery point objectives];
c. Conducts backups of information system documentation including security-related documentation [Assignment: organization-defined frequency consistent with recovery time and recovery point objectives]; and
d. Protects the confidentiality, integrity, and availability of backup information at storage locations.
Supplemental Guidance: System-level information includes, for example, system-state information, operating system and application software, and licenses. User-level information includes any information other than system-level information. Mechanisms employed by organizations to protect the integrity of information system backups include, for example, digital signatures and cryptographic hashes. Protection of system backup information while in transit is beyond the
scope of this control. Information system backups reflect the requirements in contingency plans as well as other organizational requirements for backing up information. Related controls: CP-2, CP-6, MP-4, MP-5, SC-13.
References: NIST Special Publication 800-34. |
link |
9 |
| FedRAMP_Moderate_R4 |
CP-9 |
FedRAMP_Moderate_R4_CP-9 |
FedRAMP Moderate CP-9 |
Contingency Planning |
Information System Backup |
Shared |
n/a |
The organization:
a. Conducts backups of user-level information contained in the information system [Assignment: organization-defined frequency consistent with recovery time and recovery point objectives];
b. Conducts backups of system-level information contained in the information system [Assignment: organization-defined frequency consistent with recovery time and recovery point objectives];
c. Conducts backups of information system documentation including security-related documentation [Assignment: organization-defined frequency consistent with recovery time and recovery point objectives]; and
d. Protects the confidentiality, integrity, and availability of backup information at storage locations.
Supplemental Guidance: System-level information includes, for example, system-state information, operating system and application software, and licenses. User-level information includes any information other than system-level information. Mechanisms employed by organizations to protect the integrity of information system backups include, for example, digital signatures and cryptographic hashes. Protection of system backup information while in transit is beyond the
scope of this control. Information system backups reflect the requirements in contingency plans as well as other organizational requirements for backing up information. Related controls: CP-2, CP-6, MP-4, MP-5, SC-13.
References: NIST Special Publication 800-34. |
link |
9 |
| New_Zealand_ISM |
23.4.9.C.01 |
New_Zealand_ISM_23.4.9.C.01 |
New_Zealand_ISM_23.4.9.C.01 |
23. Public Cloud Security |
23.4.9.C.01 Data protection mechanisms |
|
n/a |
For each cloud service, agencies MUST ensure that the mechanisms used to protect data meet agency requirements. |
|
17 |
| NIST_SP_800-171_R2_3 |
.8.9 |
NIST_SP_800-171_R2_3.8.9 |
NIST SP 800-171 R2 3.8.9 |
Media Protection |
Protect the confidentiality of backup CUI at storage locations. |
Shared |
Microsoft and the customer share responsibilities for implementing this requirement. |
Organizations can employ cryptographic mechanisms or alternative physical controls to protect the confidentiality of backup information at designated storage locations. Backed-up information containing CUI may include system-level information and user-level information. System-level information includes system-state information, operating system software, application software, and licenses. User-level information includes information other than system-level information. |
link |
8 |
| NIST_SP_800-53_R4 |
CP-9 |
NIST_SP_800-53_R4_CP-9 |
NIST SP 800-53 Rev. 4 CP-9 |
Contingency Planning |
Information System Backup |
Shared |
n/a |
The organization:
a. Conducts backups of user-level information contained in the information system [Assignment: organization-defined frequency consistent with recovery time and recovery point objectives];
b. Conducts backups of system-level information contained in the information system [Assignment: organization-defined frequency consistent with recovery time and recovery point objectives];
c. Conducts backups of information system documentation including security-related documentation [Assignment: organization-defined frequency consistent with recovery time and recovery point objectives]; and
d. Protects the confidentiality, integrity, and availability of backup information at storage locations.
Supplemental Guidance: System-level information includes, for example, system-state information, operating system and application software, and licenses. User-level information includes any information other than system-level information. Mechanisms employed by organizations to protect the integrity of information system backups include, for example, digital signatures and cryptographic hashes. Protection of system backup information while in transit is beyond the
scope of this control. Information system backups reflect the requirements in contingency plans as well as other organizational requirements for backing up information. Related controls: CP-2, CP-6, MP-4, MP-5, SC-13.
References: NIST Special Publication 800-34. |
link |
9 |
| NIST_SP_800-53_R5 |
CP-9 |
NIST_SP_800-53_R5_CP-9 |
NIST SP 800-53 Rev. 5 CP-9 |
Contingency Planning |
System Backup |
Shared |
n/a |
a. Conduct backups of user-level information contained in [Assignment: organization-defined system components] [Assignment: organization-defined frequency consistent with recovery time and recovery point objectives];
b. Conduct backups of system-level information contained in the system [Assignment: organization-defined frequency consistent with recovery time and recovery point objectives];
c. Conduct backups of system documentation, including security- and privacy-related documentation [Assignment: organization-defined frequency consistent with recovery time and recovery point objectives]; and
d. Protect the confidentiality, integrity, and availability of backup information. |
link |
9 |
| NL_BIO_Cloud_Theme |
U.04.1(2) |
NL_BIO_Cloud_Theme_U.04.1(2) |
NL_BIO_Cloud_Theme_U.04.1(2) |
U.04 Data and Cloud Service Recovery |
Restore Function |
|
n/a |
In the event of calamities, the data and cloud services are restored within the agreed period and maximum data loss and made available to the CSC. |
|
3 |
| NL_BIO_Cloud_Theme |
U.04.2(2) |
NL_BIO_Cloud_Theme_U.04.2(2) |
NL_BIO_Cloud_Theme_U.04.2(2) |
U.04 Data and Cloud Service Recovery |
Restore Function |
|
n/a |
The continuous process of recoverable protection of data is monitored. |
|
3 |
| NL_BIO_Cloud_Theme |
U.04.3(2) |
NL_BIO_Cloud_Theme_U.04.3(2) |
NL_BIO_Cloud_Theme_U.04.3(2) |
U.04 Data and Cloud Service Recovery |
Tested |
|
n/a |
The adequate functioning of recovery functions is periodically tested by qualified personnel and the results are shared with the CSC. |
|
3 |
| NZ_ISM_v3.5 |
CR-2 |
NZ_ISM_v3.5_CR-2 |
NZISM Security Benchmark CR-2 |
Cryptography |
17.1.52 Data Recovery |
Customer |
n/a |
It is important for continuity and operational stability that cryptographic products provide a means of data recovery to allow for the recovery of data in circumstances such as where the encryption key is unavailable due to loss, damage or failure. This includes production, storage, backup and virtual systems. This is sometimes described as ???key escrow???. |
link |
2 |
| NZISM_Security_Benchmark_v1.1 |
CR-2 |
NZISM_Security_Benchmark_v1.1_CR-2 |
NZISM Security Benchmark CR-2 |
Cryptography |
17.1.45 Data Recovery |
Customer |
Cryptographic products SHOULD provide a means of data recovery to allow for recovery of data in circumstances where the encryption key is unavailable due to loss, damage or failure. |
It is important for continuity and operational stability that cryptographic products provide a means of data recovery to allow for the recovery of data in circumstances such as where the encryption key is unavailable due to loss, damage or failure. This includes production, storage, backup and virtual systems. This is sometimes described as “key escrow”. |
link |
2 |
| RBI_CSF_Banks_v2016 |
21.1 |
RBI_CSF_Banks_v2016_21.1 |
|
Metrics |
Metrics-21.1 |
|
n/a |
Develop a comprehensive set of metrics that provide for prospective and
retrospective measures, like key performance indicators and key risk indicators |
|
15 |
| 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 |
| RMiT_v1.0 |
10.16 |
RMiT_v1.0_10.16 |
RMiT 10.16 |
Cryptography |
Cryptography - 10.16 |
Shared |
n/a |
A financial institution must establish a robust and resilient cryptography policy to promote the adoption of strong cryptographic controls for protection of important data and information. This policy, at a minimum, shall address requirements for:
(a) the adoption of industry standards for encryption algorithms, message authentication, hash functions, digital signatures and random number generation;
(b) the adoption of robust and secure processes in managing cryptographic key lifecycles which include generation, distribution, renewal, usage, storage, recovery, revocation and destruction;
(c) the periodic review, at least every three years, of existing cryptographic standards and algorithms in critical systems, external linked or transactional customer-facing applications to prevent exploitation of weakened algorithms or protocols; and
(d) the development and testing of compromise-recovery plans in the event of a cryptographic key compromise. This must set out the escalation process, procedures for keys regeneration, interim measures, changes to business-as-usual protocols and containment strategies or options to minimise the impact of a compromise. |
link |
10 |
| RMiT_v1.0 |
11.15 |
RMiT_v1.0_11.15 |
RMiT 11.15 |
Data Loss Prevention (DLP) |
Data Loss Prevention (DLP) - 11.15 |
Shared |
n/a |
A financial institution must design internal control procedures and implement appropriate technology in all applications and access points to enforce DLP policies and trigger any policy violations. The technology deployed must cover the following:
(a) data in-use - data being processed by IT resources;
(b) data in-motion - data being transmitted on the network; and
(c) data at-rest - data stored in storage mediums such as servers, backup media and databases. |
link |
14 |
| 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 |
|
78 |
|
U.04.1 - Restore function |
U.04.1 - Restore function |
404 not found |
|
|
|
n/a |
n/a |
|
3 |
|
U.04.2 - Restore function |
U.04.2 - Restore function |
404 not found |
|
|
|
n/a |
n/a |
|
3 |
|
U.04.3 - Tested |
U.04.3 - Tested |
404 not found |
|
|
|
n/a |
n/a |
|
3 |