last sync: 2024-Jul-26 18:17:39 UTC

Azure Key Vault Managed HSM should have purge protection enabled

Azure BuiltIn Policy definition

Source Azure Portal
Display name Azure Key Vault Managed HSM should have purge protection enabled
Id c39ba22d-4428-4149-b981-70acb31fc383
Version 1.0.0
Details on versioning
Category Key Vault
Microsoft Learn
Description Malicious deletion of an Azure Key Vault Managed HSM can lead to permanent data loss. A malicious insider in your organization can potentially delete and purge Azure Key Vault Managed HSM. Purge protection protects you from insider attacks by enforcing a mandatory retention period for soft deleted Azure Key Vault Managed HSM. No one inside your organization or Microsoft will be able to purge your Azure Key Vault Managed HSM during the soft delete retention period.
Mode Indexed
Type BuiltIn
Preview False
Deprecated False
Effect Default
Audit
Allowed
Audit, Deny, Disabled
RBAC role(s) none
Rule aliases IF (2)
Alias Namespace ResourceType Path PathIsDefault DefaultPath Modifiable
Microsoft.KeyVault/managedHsms/enablePurgeProtection Microsoft.KeyVault managedHSMs properties.enablePurgeProtection True True
Microsoft.KeyVault/managedHsms/enableSoftDelete Microsoft.KeyVault managedHSMs properties.enableSoftDelete True False
Rule resource types IF (1)
Microsoft.KeyVault/managedHsms
Compliance
The following 6 compliance controls are associated with this Policy definition 'Azure Key Vault Managed HSM should have purge protection enabled' (c39ba22d-4428-4149-b981-70acb31fc383)
Control Domain Control Name MetadataId Category Title Owner Requirements Description Info Policy#
CIS_Azure_1.1.0 8.4 CIS_Azure_1.1.0_8.4 CIS Microsoft Azure Foundations Benchmark recommendation 8.4 8 Other Security Considerations Ensure the key vault is recoverable Shared The customer is responsible for implementing this recommendation. 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., as may happen in the case of accidental deletion by a user or from disruptive activity by a malicious user. link 3
hipaa 1635.12b1Organizational.2-12.b hipaa-1635.12b1Organizational.2-12.b 1635.12b1Organizational.2-12.b 16 Business Continuity & Disaster Recovery 1635.12b1Organizational.2-12.b 12.01 Information Security Aspects of Business Continuity Management Shared n/a Information security aspects of business continuity are: (i) based on identifying events (or sequence of events) that can cause interruptions to the organization's critical business processes (e.g., equipment failure, human errors, theft, fire, natural disasters acts of terrorism); (ii) followed by a risk assessment to determine the probability and impact of such interruptions, in terms of time, damage scale and recovery period; (iii) based on the results of the risk assessment, a business continuity strategy is developed to identify the overall approach to business continuity; and, (iv) once this strategy has been created, endorsement is provided by management, and a plan created and endorsed to implement this strategy. 6
NZ_ISM_v3.5 GS-2 NZ_ISM_v3.5_GS-2 NZISM Security Benchmark GS-2 Gateway security 19.1.11 Using Gateways Customer n/a Physically locating all gateway components inside a secure server room will reduce the risk of unauthorised access to the device(s). The system owner of the higher security domain of connected security domains would be most familiar with the controls required to protect the more sensitive information and as such is best placed to manage any shared components of gateways. In some cases where multiple security domains from different agencies are connected to a gateway, it may be more appropriate to have a qualified third party manage the gateway on behalf of all connected agencies. Gateway components may also reside in a virtual environment ??? refer to Section 22.2 ??? Virtualisation and Section 22.3 ??? Virtual Local Area Networks link 10
NZISM_Security_Benchmark_v1.1 GS-2 NZISM_Security_Benchmark_v1.1_GS-2 NZISM Security Benchmark GS-2 Gateway security 19.1.11 Using Gateways Customer Agencies MUST ensure that: all agency networks are protected from networks in other security domains by one or more gateways; all gateways contain mechanisms to filter or limit data flow at the network and content level to only the information necessary for business purposes; and all gateway components, discrete and virtual, are physically located within an appropriately secured server room. Physically locating all gateway components inside a secure server room will reduce the risk of unauthorised access to the device(s). The system owner of the higher security domain of connected security domains would be most familiar with the controls required to protect the more sensitive information and as such is best placed to manage any shared components of gateways. In some cases where multiple security domains from different agencies are connected to a gateway, it may be more appropriate to have a qualified third party manage the gateway on behalf of all connected agencies. Gateway components may also reside in a virtual environment – refer to Section 22.2 – Virtualisation and Section 22.3 – Virtual Local Area Networks link 8
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
Initiatives usage
Initiative DisplayName Initiative Id Initiative Category State Type
[Deprecated]: New Zealand ISM Restricted d1a462af-7e6d-4901-98ac-61570b4ed22a Regulatory Compliance Deprecated BuiltIn
[Deprecated]: New Zealand ISM Restricted v3.5 93d2179e-3068-c82f-2428-d614ae836a04 Regulatory Compliance Deprecated BuiltIn
CIS Microsoft Azure Foundations Benchmark v1.1.0 1a5bb27d-173f-493e-9568-eb56638dde4d Regulatory Compliance GA BuiltIn
Enforce recommended guardrails for Azure Key Vault Enforce-Guardrails-KeyVault Key Vault GA ALZ
HITRUST/HIPAA a169a624-5599-4385-a696-c8d643089fab Regulatory Compliance GA BuiltIn
RMIT Malaysia 97a6d4f1-3bed-4cf4-ac5b-0e444c0408d6 Regulatory Compliance GA BuiltIn
History
Date/Time (UTC ymd) (i) Change type Change detail
2021-02-17 14:28:42 add c39ba22d-4428-4149-b981-70acb31fc383
JSON compare n/a
JSON
api-version=2021-06-01
EPAC