last sync: 2025-May-01 19:36:43 UTC

Kubernetes cluster containers should run with a read only root file system

Azure BuiltIn Policy definition

Source Azure Portal
Display name Kubernetes cluster containers should run with a read only root file system
Id df49d893-a74c-421d-bc95-c663042e5b80
Version 6.3.0
Details on versioning
Versioning Versions supported for Versioning: 3
6.3.0
6.2.0
6.1.0
Built-in Versioning [Preview]
Category Kubernetes
Microsoft Learn
Description Run containers with a read only root file system to protect from changes at run-time with malicious binaries being added to PATH in a Kubernetes cluster. This policy is generally available for Kubernetes Service (AKS), and preview for Azure Arc enabled Kubernetes. For more information, see https://aka.ms/kubepolicydoc.
Cloud environments AzureCloud = true
AzureUSGovernment = true
AzureChinaCloud = unknown
Available in AzUSGov The Policy is available in AzureUSGovernment cloud. Version: '7.1.0'
Repository: Azure-Policy df49d893-a74c-421d-bc95-c663042e5b80
Assessment(s) Assessments count: 1
Assessment Id: 27d6f0e9-b4d5-468b-ae7e-03d5473fd864
DisplayName: Immutable (read-only) root filesystem should be enforced for containers
Description: Containers should run with a read only root file system in your Kubernetes cluster. Immutable filesystem protects containers from changes at run-time with malicious binaries being added to PATH.
Remediation description:
1. From the Unhealthy resources tab, select the cluster. Defender for Cloud lists the pods running containers without read only root file system.
2. For these pods, set the readOnlyRootFilesystem flag to 'true' on the security context of the container's spec.
3. After making your changes, redeploy the pod with the updated spec.
Categories: Container
Severity: Medium
Mode Microsoft.Kubernetes.Data
Type BuiltIn
Preview False
Deprecated False
Effect Default
Audit
Allowed
audit, Audit, deny, Deny, disabled, Disabled
RBAC role(s) none
Rule aliases none
Rule resource types IF (2)
Compliance
The following 52 compliance controls are associated with this Policy definition 'Kubernetes cluster containers should run with a read only root file system' (df49d893-a74c-421d-bc95-c663042e5b80)
Control Domain Control Name MetadataId Category Title Owner Requirements Description Info Policy#
Azure_Security_Benchmark_v2.0 PV-2 Azure_Security_Benchmark_v2.0_PV-2 Azure Security Benchmark PV-2 Posture and Vulnerability Management Sustain secure configurations for Azure services Customer Use Azure Security Center to monitor your configuration baseline and use Azure Policy [deny] and [deploy if not exist] rule to enforce secure configuration across Azure compute resources, including VMs, containers, and others. Understand Azure Policy effects: https://docs.microsoft.com/azure/governance/policy/concepts/effects Create and manage policies to enforce compliance: https://docs.microsoft.com/azure/governance/policy/tutorials/create-and-manage n/a link 19
Azure_Security_Benchmark_v3.0 PV-2 Azure_Security_Benchmark_v3.0_PV-2 Microsoft cloud security benchmark PV-2 Posture and Vulnerability Management Audit and enforce secure configurations Shared **Security Principle:** Continuously monitor and alert when there is a deviation from the defined configuration baseline. Enforce the desired configuration according to the baseline configuration by denying the non-compliant configuration or deploy a configuration. **Azure Guidance:** Use Microsoft Defender for Cloud to configure Azure Policy to audit and enforce configurations of your Azure resources. Use Azure Monitor to create alerts when there is a configuration deviation detected on the resources. Use Azure Policy [deny] and [deploy if not exist] rule to enforce secure configuration across Azure resources. For resource configuration audit and enforcement not supported by Azure Policy, you may need to write your own scripts or use third-party tooling to implement the configuration audit and enforcement. **Implementation and additional context:** Understand Azure Policy effects: https://docs.microsoft.com/azure/governance/policy/concepts/effects Create and manage policies to enforce compliance: https://docs.microsoft.com/azure/governance/policy/tutorials/create-and-manage Get compliance data of Azure resources: https://docs.microsoft.com/azure/governance/policy/how-to/get-compliance-data n/a link 27
C.04.7 - Evaluated C.04.7 - Evaluated 404 not found n/a n/a 55
CMMC_2.0_L2 CM.L2-3.4.1 CMMC_2.0_L2_CM.L2-3.4.1 404 not found n/a n/a 25
CMMC_2.0_L2 CM.L2-3.4.2 CMMC_2.0_L2_CM.L2-3.4.2 404 not found n/a n/a 27
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). 30
CSA_v4.0.12 CCC_04 CSA_v4.0.12_CCC_04 CSA Cloud Controls Matrix v4.0.12 CCC 04 Change Control and Configuration Management Unauthorized Change Protection Shared n/a Restrict the unauthorized addition, removal, update, and management of organization assets. 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 IAM_07 CSA_v4.0.12_IAM_07 CSA Cloud Controls Matrix v4.0.12 IAM 07 Identity & Access Management User Access Changes and Revocation Shared n/a De-provision or respectively modify access of movers / leavers or system identity changes in a timely manner in order to effectively adopt and communicate identity and access management policies. 56
CSA_v4.0.12 IVS_07 CSA_v4.0.12_IVS_07 CSA Cloud Controls Matrix v4.0.12 IVS 07 Infrastructure & Virtualization Security Migration to Cloud Environments Shared n/a Use secure and encrypted communication channels when migrating servers, services, applications, or data to cloud environments. Such channels must include only up-to-date and approved protocols. 8
CSA_v4.0.12 TVM_04 CSA_v4.0.12_TVM_04 CSA Cloud Controls Matrix v4.0.12 TVM 04 Threat & Vulnerability Management Detection Updates Shared n/a Define, implement and evaluate processes, procedures and technical measures to update detection tools, threat signatures, and indicators of compromise on a weekly, or more frequent basis. 50
CSA_v4.0.12 TVM_07 CSA_v4.0.12_TVM_07 CSA Cloud Controls Matrix v4.0.12 TVM 07 Threat & Vulnerability Management Vulnerability Identification Shared n/a Define, implement and evaluate processes, procedures and technical measures for the detection of vulnerabilities on organizationally managed assets at least monthly. 8
Cyber_Essentials_v3.1 1 Cyber_Essentials_v3.1_1 Cyber Essentials v3.1 1 Cyber Essentials Firewalls Shared n/a Aim: to make sure that only secure and necessary network services can be accessed from the internet. 37
Cyber_Essentials_v3.1 3 Cyber_Essentials_v3.1_3 Cyber Essentials v3.1 3 Cyber Essentials Security Update Management Shared n/a Aim: ensure that devices and software are not vulnerable to known security issues for which fixes are available.   38
Cyber_Essentials_v3.1 5 Cyber_Essentials_v3.1_5 Cyber Essentials v3.1 5 Cyber Essentials Malware protection Shared n/a Aim: to restrict execution of known malware and untrusted software, from causing damage or accessing data. 60
EU_2555_(NIS2)_2022 EU_2555_(NIS2)_2022_11 EU_2555_(NIS2)_2022_11 EU 2022/2555 (NIS2) 2022 11 Requirements, technical capabilities and tasks of CSIRTs Shared n/a Outlines the requirements, technical capabilities, and tasks of CSIRTs. 68
EU_2555_(NIS2)_2022 EU_2555_(NIS2)_2022_12 EU_2555_(NIS2)_2022_12 EU 2022/2555 (NIS2) 2022 12 Coordinated vulnerability disclosure and a European vulnerability database Shared n/a Establishes a coordinated vulnerability disclosure process and a European vulnerability database. 66
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. 193
EU_2555_(NIS2)_2022 EU_2555_(NIS2)_2022_29 EU_2555_(NIS2)_2022_29 EU 2022/2555 (NIS2) 2022 29 Cybersecurity information-sharing arrangements Shared n/a Allows entities to exchange relevant cybersecurity information on a voluntary basis. 66
FBI_Criminal_Justice_Information_Services_v5.9.5_5 .11 FBI_Criminal_Justice_Information_Services_v5.9.5_5.11 FBI Criminal Justice Information Services (CJIS) v5.9.5 5.11 Policy and Implementation - Formal Audits Policy Area 11: Formal Audits Shared Internal compliance checklists should be regularly kept updated with respect to applicable statutes, regulations, policies and on the basis of findings in audit. Formal audits are conducted to ensure compliance with applicable statutes, regulations and policies. 64
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 95
FedRAMP_High_R4 CM-6 FedRAMP_High_R4_CM-6 FedRAMP High CM-6 Configuration Management Configuration Settings Shared n/a The organization: a. Establishes and documents configuration settings for information technology products employed within the information system using [Assignment: organization-defined security configuration checklists] that reflect the most restrictive mode consistent with operational requirements; b. Implements the configuration settings; c. Identifies, documents, and approves any deviations from established configuration settings for [Assignment: organization-defined information system components] based on [Assignment: organization-defined operational requirements]; and d. Monitors and controls changes to the configuration settings in accordance with organizational policies and procedures. Supplemental Guidance: Configuration settings are the set of parameters that can be changed in hardware, software, or firmware components of the information system that affect the security posture and/or functionality of the system. Information technology products for which security- related configuration settings can be defined include, for example, mainframe computers, servers (e.g., database, electronic mail, authentication, web, proxy, file, domain name), workstations, input/output devices (e.g., scanners, copiers, and printers), network components (e.g., firewalls, routers, gateways, voice and data switches, wireless access points, network appliances, sensors), operating systems, middleware, and applications. Security-related parameters are those parameters impacting the security state of information systems including the parameters required to satisfy other security control requirements. Security-related parameters include, for example: (i) registry settings; (ii) account, file, directory permission settings; and (iii) settings for functions, ports, protocols, services, and remote connections. Organizations establish organization-wide configuration settings and subsequently derive specific settings for information systems. The established settings become part of the systems configuration baseline. Common secure configurations (also referred to as security configuration checklists, lockdown and hardening guides, security reference guides, security technical implementation guides) provide recognized, standardized, and established benchmarks that stipulate secure configuration settings for specific information technology platforms/products and instructions for configuring those information system components to meet operational requirements. Common secure configurations can be developed by a variety of organizations including, for example, information technology product developers, manufacturers, vendors, consortia, academia, industry, federal agencies, and other organizations in the public and private sectors. Common secure configurations include the United States Government Configuration Baseline (USGCB) which affects the implementation of CM-6 and other controls such as AC-19 and CM-7. The Security Content Automation Protocol (SCAP) and the defined standards within the protocol (e.g., Common Configuration Enumeration) provide an effective method to uniquely identify, track, and control configuration settings. OMB establishes federal policy on configuration requirements for federal information systems. Related controls: AC-19, CM-2, CM-3, CM-7, SI-4. References: OMB Memoranda 07-11, 07-18, 08-22; NIST Special Publications 800-70, 800-128; Web: http://nvd.nist.gov, http://checklists.nist.gov, http://www.nsa.gov. link 23
FedRAMP_Moderate_R4 CM-6 FedRAMP_Moderate_R4_CM-6 FedRAMP Moderate CM-6 Configuration Management Configuration Settings Shared n/a The organization: a. Establishes and documents configuration settings for information technology products employed within the information system using [Assignment: organization-defined security configuration checklists] that reflect the most restrictive mode consistent with operational requirements; b. Implements the configuration settings; c. Identifies, documents, and approves any deviations from established configuration settings for [Assignment: organization-defined information system components] based on [Assignment: organization-defined operational requirements]; and d. Monitors and controls changes to the configuration settings in accordance with organizational policies and procedures. Supplemental Guidance: Configuration settings are the set of parameters that can be changed in hardware, software, or firmware components of the information system that affect the security posture and/or functionality of the system. Information technology products for which security- related configuration settings can be defined include, for example, mainframe computers, servers (e.g., database, electronic mail, authentication, web, proxy, file, domain name), workstations, input/output devices (e.g., scanners, copiers, and printers), network components (e.g., firewalls, routers, gateways, voice and data switches, wireless access points, network appliances, sensors), operating systems, middleware, and applications. Security-related parameters are those parameters impacting the security state of information systems including the parameters required to satisfy other security control requirements. Security-related parameters include, for example: (i) registry settings; (ii) account, file, directory permission settings; and (iii) settings for functions, ports, protocols, services, and remote connections. Organizations establish organization-wide configuration settings and subsequently derive specific settings for information systems. The established settings become part of the systems configuration baseline. Common secure configurations (also referred to as security configuration checklists, lockdown and hardening guides, security reference guides, security technical implementation guides) provide recognized, standardized, and established benchmarks that stipulate secure configuration settings for specific information technology platforms/products and instructions for configuring those information system components to meet operational requirements. Common secure configurations can be developed by a variety of organizations including, for example, information technology product developers, manufacturers, vendors, consortia, academia, industry, federal agencies, and other organizations in the public and private sectors. Common secure configurations include the United States Government Configuration Baseline (USGCB) which affects the implementation of CM-6 and other controls such as AC-19 and CM-7. The Security Content Automation Protocol (SCAP) and the defined standards within the protocol (e.g., Common Configuration Enumeration) provide an effective method to uniquely identify, track, and control configuration settings. OMB establishes federal policy on configuration requirements for federal information systems. Related controls: AC-19, CM-2, CM-3, CM-7, SI-4. References: OMB Memoranda 07-11, 07-18, 08-22; NIST Special Publications 800-70, 800-128; Web: http://nvd.nist.gov, http://checklists.nist.gov, http://www.nsa.gov. link 23
HITRUST_CSF_v11.3 01.l HITRUST_CSF_v11.3_01.l HITRUST CSF v11.3 01.l Network Access Control Prevent unauthorized access to networked services. Shared Ports, services, and applications installed on a computer or network systems, which are not specifically required for business functionality, to be disabled or removed. Physical and logical access to diagnostic and configuration ports shall be controlled. 26
HITRUST_CSF_v11.3 09.j HITRUST_CSF_v11.3_09.j HITRUST CSF v11.3 09.j Protection Against Malicious and Mobile Code Ensure that integrity of information and software is protected from malicious or unauthorized code Shared 1. Technologies are to be implemented for timely installation, upgrade and renewal of anti-malware protective measures. 2. Automatic periodic scans of information systems is to be implemented. 3. Anti-malware software that offers a centralized infrastructure that compiles information on file reputations is to be implemented. 4. Post-malicious code update, signature deployment, scanning files, email, and web traffic is to be verified by automated systems, while BYOD users require anti-malware, network-based malware detection is to be used on servers without host-based solutions use. 5. Anti-malware audit logs checks to be performed. 6. Protection against malicious code is to be based on malicious code detection and repair software, security awareness, appropriate system access, and change management controls. Detection, prevention, and recovery controls shall be implemented to protect against malicious code, and appropriate user awareness procedures on malicious code shall be provided. 37
HITRUST_CSF_v11.3 09.m HITRUST_CSF_v11.3_09.m HITRUST CSF v11.3 09.m Network Security Management Ensure the protection of information in networks and protection of the supporting network infrastructure. Shared 1. Vendor default encryption keys, default SNMP community strings on wireless devices, default passwords/passphrases on access points, and other security-related wireless vendor defaults is to be changed prior to authorization of implementation of wireless access points. 2. Wireless encryption keys to be changed when anyone with knowledge of the keys leaves or changes. 3. All authorized and unauthorized wireless access to the information system is to be monitored and installation of wireless access points (WAP) is to be prohibited unless explicitly authorized. Networks shall be managed and controlled in order to protect the organization from threats and to maintain security for the systems and applications using the network, including information in transit. 24
HITRUST_CSF_v11.3 10.c HITRUST_CSF_v11.3_10.c HITRUST CSF v11.3 10.c Correct Processing in Applications Incorporate validation checks into applications to detect any corruption of information through processing errors or deliberate acts. Shared Data integrity controls which manage changes, prevent sequencing errors, ensure recovery from failures, and protect against buffer overrun attacks are to be implemented. Validation checks shall be incorporated into applications to detect any corruption of information through processing errors or deliberate acts. 35
HITRUST_CSF_v11.3 10.m HITRUST_CSF_v11.3_10.m HITRUST CSF v11.3 10.m Technical Vulnerability Management Reduce the risks resulting from exploitation of published technical vulnerabilities, technical vulnerability management shall be implemented in an effective, systematic, and repeatable way with measurements taken to confirm its effectiveness. Shared 1. The necessary secure services, protocols required for the function of the system are to be enabled. 2. Security features to be implemented for any required services that are considered to be insecure. 3. Laptops, workstations, and servers to be configured so they will not auto-run content from removable media. 4. Configuration standards to be consistent with industry-accepted system hardening standards. 5. An enterprise security posture review within every 365 days is to be conducted. 6. Vulnerability scanning tools to be regularly updated with all relevant information system vulnerabilities. Timely information about technical vulnerabilities of information systems being used shall be obtained; the organization’s exposure to such vulnerabilities evaluated; and appropriate measures taken to address the associated risk. 46
New_Zealand_ISM 14.1.9.C.01 New_Zealand_ISM_14.1.9.C.01 New_Zealand_ISM_14.1.9.C.01 14. Software security 14.1.9.C.01 Maintaining hardened SOEs n/a Agencies MUST ensure that for all servers and workstations: a technical specification is agreed for each platform with specified controls; a standard configuration created and updated for each operating system type and version; system users do not have the ability to install or disable software without approval; and installed software and operating system patching is up to date. 16
NIST_SP_800-171_R2_3 .4.1 NIST_SP_800-171_R2_3.4.1 NIST SP 800-171 R2 3.4.1 Configuration Management Establish and maintain baseline configurations and inventories of organizational systems (including hardware, software, firmware, and documentation) throughout the respective system development life cycles. Shared Microsoft and the customer share responsibilities for implementing this requirement. Baseline configurations are documented, formally reviewed, and agreed-upon specifications for systems or configuration items within those systems. Baseline configurations serve as a basis for future builds, releases, and changes to systems. Baseline configurations include information about system components (e.g., standard software packages installed on workstations, notebook computers, servers, network components, or mobile devices; current version numbers and update and patch information on operating systems and applications; and configuration settings and parameters), network topology, and the logical placement of those components within the system architecture. Baseline configurations of systems also reflect the current enterprise architecture. Maintaining effective baseline configurations requires creating new baselines as organizational systems change over time. Baseline configuration maintenance includes reviewing and updating the baseline configuration when changes are made based on security risks and deviations from the established baseline configuration. Organizations can implement centralized system component inventories that include components from multiple organizational systems. In such situations, organizations ensure that the resulting inventories include system-specific information required for proper component accountability (e.g., system association, system owner). Information deemed necessary for effective accountability of system components includes hardware inventory specifications, software license information, software version numbers, component owners, and for networked components or devices, machine names and network addresses. Inventory specifications include manufacturer, device type, model, serial number, and physical location. [SP 800-128] provides guidance on security-focused configuration management. link 31
NIST_SP_800-171_R2_3 .4.2 NIST_SP_800-171_R2_3.4.2 NIST SP 800-171 R2 3.4.2 Configuration Management Establish and enforce security configuration settings for information technology products employed in organizational systems. Shared Microsoft and the customer share responsibilities for implementing this requirement. Configuration settings are the set of parameters that can be changed in hardware, software, or firmware components of the system that affect the security posture or functionality of the system. Information technology products for which security-related configuration settings can be defined include mainframe computers, servers, workstations, input and output devices (e.g., scanners, copiers, and printers), network components (e.g., firewalls, routers, gateways, voice and data switches, wireless access points, network appliances, sensors), operating systems, middleware, and applications. Security parameters are those parameters impacting the security state of systems including the parameters required to satisfy other security requirements. Security parameters include: registry settings; account, file, directory permission settings; and settings for functions, ports, protocols, and remote connections. Organizations establish organization-wide configuration settings and subsequently derive specific configuration settings for systems. The established settings become part of the systems configuration baseline. Common secure configurations (also referred to as security configuration checklists, lockdown and hardening guides, security reference guides, security technical implementation guides) provide recognized, standardized, and established benchmarks that stipulate secure configuration settings for specific information technology platforms/products and instructions for configuring those system components to meet operational requirements. Common secure configurations can be developed by a variety of organizations including information technology product developers, manufacturers, vendors, consortia, academia, industry, federal agencies, and other organizations in the public and private sectors. [SP 800-70] and [SP 800-128] provide guidance on security configuration settings. link 25
NIST_SP_800-53_R4 CM-6 NIST_SP_800-53_R4_CM-6 NIST SP 800-53 Rev. 4 CM-6 Configuration Management Configuration Settings Shared n/a The organization: a. Establishes and documents configuration settings for information technology products employed within the information system using [Assignment: organization-defined security configuration checklists] that reflect the most restrictive mode consistent with operational requirements; b. Implements the configuration settings; c. Identifies, documents, and approves any deviations from established configuration settings for [Assignment: organization-defined information system components] based on [Assignment: organization-defined operational requirements]; and d. Monitors and controls changes to the configuration settings in accordance with organizational policies and procedures. Supplemental Guidance: Configuration settings are the set of parameters that can be changed in hardware, software, or firmware components of the information system that affect the security posture and/or functionality of the system. Information technology products for which security- related configuration settings can be defined include, for example, mainframe computers, servers (e.g., database, electronic mail, authentication, web, proxy, file, domain name), workstations, input/output devices (e.g., scanners, copiers, and printers), network components (e.g., firewalls, routers, gateways, voice and data switches, wireless access points, network appliances, sensors), operating systems, middleware, and applications. Security-related parameters are those parameters impacting the security state of information systems including the parameters required to satisfy other security control requirements. Security-related parameters include, for example: (i) registry settings; (ii) account, file, directory permission settings; and (iii) settings for functions, ports, protocols, services, and remote connections. Organizations establish organization-wide configuration settings and subsequently derive specific settings for information systems. The established settings become part of the systems configuration baseline. Common secure configurations (also referred to as security configuration checklists, lockdown and hardening guides, security reference guides, security technical implementation guides) provide recognized, standardized, and established benchmarks that stipulate secure configuration settings for specific information technology platforms/products and instructions for configuring those information system components to meet operational requirements. Common secure configurations can be developed by a variety of organizations including, for example, information technology product developers, manufacturers, vendors, consortia, academia, industry, federal agencies, and other organizations in the public and private sectors. Common secure configurations include the United States Government Configuration Baseline (USGCB) which affects the implementation of CM-6 and other controls such as AC-19 and CM-7. The Security Content Automation Protocol (SCAP) and the defined standards within the protocol (e.g., Common Configuration Enumeration) provide an effective method to uniquely identify, track, and control configuration settings. OMB establishes federal policy on configuration requirements for federal information systems. Related controls: AC-19, CM-2, CM-3, CM-7, SI-4. References: OMB Memoranda 07-11, 07-18, 08-22; NIST Special Publications 800-70, 800-128; Web: http://nvd.nist.gov, http://checklists.nist.gov, http://www.nsa.gov. link 23
NIST_SP_800-53_R5 CM-6 NIST_SP_800-53_R5_CM-6 NIST SP 800-53 Rev. 5 CM-6 Configuration Management Configuration Settings Shared n/a a. Establish and document configuration settings for components employed within the system that reflect the most restrictive mode consistent with operational requirements using [Assignment: organization-defined common secure configurations]; b. Implement the configuration settings; c. Identify, document, and approve any deviations from established configuration settings for [Assignment: organization-defined system components] based on [Assignment: organization-defined operational requirements]; and d. Monitor and control changes to the configuration settings in accordance with organizational policies and procedures. link 23
NZ_ISM_v3.5 SS-3 NZ_ISM_v3.5_SS-3 NZISM Security Benchmark SS-3 Software security 14.1.9 Maintaining hardened SOEs Customer n/a Whilst a SOE can be sufficiently hardened when it is deployed, its security will progressively degrade over time. Agencies can address the degradation of the security of a SOE by ensuring that patches are continually applied, system users are not able to disable or bypass security functionality and antivirus and other security software is appropriately maintained with the latest signatures and updates. End Point Agents monitor traffic and apply security policies on applications, storage interfaces and data in real-time. Administrators actively block or monitor and log policy breaches. The End Point Agent can also create forensic monitoring to facilitate incident investigation. End Point Agents can monitor user activity, such as the cut, copy, paste, print, print screen operations and copying data to external drives and other devices. The Agent can then apply policies to limit such activity. link 15
NZISM_v3.7 14.1.8.C.01. NZISM_v3.7_14.1.8.C.01. NZISM v3.7 14.1.8.C.01. Standard Operating Environments 14.1.8.C.01. - minimise vulnerabilities and enhance system security Shared n/a Agencies SHOULD develop a hardened SOE for workstations and servers, covering: 1. removal of unneeded software and operating system components; 2. removal or disabling of unneeded services, ports and BIOS settings; 3. disabling of unused or undesired functionality in software and operating systems; 4. implementation of access controls on relevant objects to limit system users and programs to the minimum access required; 5. installation of antivirus and anti-malware software; 6. installation of software-based firewalls limiting inbound and outbound network connections; 7. configuration of either remote logging or the transfer of local event logs to a central server; and 8. protection of audit and other logs through the use of a one way pipe to reduce likelihood of compromise key transaction records. 31
NZISM_v3.7 17.8.10.C.01. NZISM_v3.7_17.8.10.C.01. NZISM v3.7 17.8.10.C.01. Internet Protocol Security (IPSec) 17.8.10.C.01. - enhance overall cybersecurity posture. Shared n/a Agencies SHOULD use tunnel mode for IPSec connections. 22
NZISM_v3.7 17.8.10.C.02. NZISM_v3.7_17.8.10.C.02. NZISM v3.7 17.8.10.C.02. Internet Protocol Security (IPSec) 17.8.10.C.02. - enhance overall cybersecurity posture. Shared n/a Agencies choosing to use transport mode SHOULD additionally use an IP tunnel for IPSec connections. 35
NZISM_v3.7 22.3.11.C.01. NZISM_v3.7_22.3.11.C.01. NZISM v3.7 22.3.11.C.01. Virtual Local Area Networks 22.3.11.C.01. - ensure data security and integrity. Shared n/a Unused ports on the switches MUST be disabled. 18
NZISM_v3.7 22.3.11.C.02. NZISM_v3.7_22.3.11.C.02. NZISM v3.7 22.3.11.C.02. Virtual Local Area Networks 22.3.11.C.02. - ensure data security and integrity. Shared n/a Unused ports on the switches SHOULD be disabled. 18
RMiT_v1.0 10.55 RMiT_v1.0_10.55 RMiT 10.55 Access Control Access Control - 10.55 Shared n/a In observing paragraph 10.54, a financial institution should consider the following principles in its access control policy: (a) adopt a 'deny all' access control policy for users by default unless explicitly authorised; (b) employ 'least privilege' access rights or on a 'need-to-have' basis where only the minimum sufficient permissions are granted to legitimate users to perform their roles; (c) employ time-bound access rights which restrict access to a specific period including access rights granted to service providers; (d) employ segregation of incompatible functions where no single person is responsible for an entire operation that may provide the ability to independently modify, circumvent, and disable system security features. This may include a combination of functions such as: (i) system development and technology operations; (ii) security administration and system administration; and (iii) network operation and network security;" (e) employ dual control functions which require two or more persons to execute an activity; (f) adopt stronger authentication for critical activities including for remote access; (g) limit and control the use of the same user ID for multiple concurrent sessions; (h) limit and control the sharing of user ID and passwords across multiple users; and (i) control the use of generic user ID naming conventions in favour of more personally identifiable IDs. link 8
SOC_2 CC6.8 SOC_2_CC6.8 SOC 2 Type 2 CC6.8 Logical and Physical Access Controls Prevent or detect against unauthorized or malicious software Shared The customer is responsible for implementing this recommendation. Restricts Application and Software Installation — The ability to install applications and software is restricted to authorized individuals. • Detects Unauthorized Changes to Software and Configuration Parameters — Processes are in place to detect changes to software and configuration parameters that may be indicative of unauthorized or malicious software. • Uses a Defined Change Control Process — A management-defined change control process is used for the implementation of software. • Uses Antivirus and Anti-Malware Software — Antivirus and anti-malware software is implemented and maintained to provide for the interception or detection and remediation of malware. • Scans Information Assets from Outside the Entity for Malware and Other Unauthorized Software — Procedures are in place to scan information assets that have been transferred or returned to the entity’s custody for malware and other unauthorized software and to remove any items detected prior to its implementation on the network. 47
SOC_2 CC8.1 SOC_2_CC8.1 SOC 2 Type 2 CC8.1 Change Management Changes to infrastructure, data, and software Shared The customer is responsible for implementing this recommendation. Manages Changes Throughout the System Life Cycle — A process for managing system changes throughout the life cycle of the system and its components (infrastructure, data, software, and procedures) is used to support system availability and processing integrity. • Authorizes Changes — A process is in place to authorize system changes prior to development. • Designs and Develops Changes — A process is in place to design and develop system changes. • Documents Changes — A process is in place to document system changes to support ongoing maintenance of the system and to support system users in performing their responsibilities. • Tracks System Changes — A process is in place to track system changes prior to implementation. • Configures Software — A process is in place to select and implement the configuration parameters used to control the functionality of software. • Tests System Changes — A process is in place to test system changes prior to implementation. • Approves System Changes — A process is in place to approve system changes prior to implementation. • Deploys System Changes — A process is in place to implement system changes. • Identifies and Evaluates System Changes — Objectives affected by system changes are identified and the ability of the modified system to meet the objectives is evaluated throughout the system development life cycle. • Identifies Changes in Infrastructure, Data, Software, and Procedures Required to Remediate Incidents — Changes in infrastructure, data, software, and procedures required to remediate incidents to continue to meet objectives are identified and the change process is initiated upon identification. • Creates Baseline Configuration of IT Technology — A baseline configuration of IT and control systems is created and maintained. • Provides for Changes Necessary in Emergency Situations — A process is in place for authorizing, designing, testing, approving, and implementing changes necessary in emergency situations (that is, changes that need to be implemented in an urgent time frame). Additional points of focus that apply only in an engagement using the trust services criteria for confidentiality: • Protects Confidential Information — The entity protects confidential information during system design, development, testing, implementation, and change processes to meet the entity’s objectives related to confidentiality. Additional points of focus that apply only in an engagement using the trust services criteria for privacy: • Protects Personal Information — The entity protects personal information during system design, development, testing, implementation, and change processes to meet the entity’s objectives related to privacy. 52
SOC_2023 CC2.3 SOC_2023_CC2.3 SOC 2023 CC2.3 Information and Communication Facilitate effective internal communication. Shared n/a Entity to communicate with external parties regarding matters affecting the functioning of internal control. 218
SOC_2023 CC5.3 SOC_2023_CC5.3 SOC 2023 CC5.3 Control Activities Maintain alignment with organizational objectives and regulatory requirements. Shared n/a Entity deploys control activities through policies that establish what is expected and in procedures that put policies into action by establishing Policies and Procedures to Support Deployment of Management’s Directives, Responsibility and Accountability for Executing Policies and Procedures, perform tasks in a timely manner, taking corrective actions, perform using competent personnel and reassess policies and procedures. 229
SOC_2023 CC6.1 SOC_2023_CC6.1 SOC 2023 CC6.1 Logical and Physical Access Controls 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 CC6.7 SOC_2023_CC6.7 404 not found n/a n/a 52
SOC_2023 CC6.8 SOC_2023_CC6.8 SOC 2023 CC6.8 Logical and Physical Access Controls Mitigate the risk of cybersecurity threats, safeguard critical systems and data, and maintain operational continuity and integrity. Shared n/a Entity implements controls to prevent or detect and act upon the introduction of unauthorized or malicious software to meet the entity’s objectives. 33
SOC_2023 CC7.2 SOC_2023_CC7.2 SOC 2023 CC7.2 Systems Operations Maintain robust security measures and ensure operational resilience. Shared n/a The entity monitors system components and the operation of those components for anomalies that are indicative of malicious acts, natural disasters, and errors affecting the entity's ability to meet its objectives; anomalies are analysed to determine whether they represent security events. 167
SOC_2023 CC7.4 SOC_2023_CC7.4 SOC 2023 CC7.4 Systems Operations Effectively manage security incidents, minimize their impact, and protect assets, operations, and reputation. Shared n/a The entity responds to identified security incidents by: a. Executing a defined incident-response program to understand, contain, remediate, and communicate security incidents by assigning roles and responsibilities; b. Establishing procedures to contain security incidents; c. Mitigating ongoing security incidents, End Threats Posed by Security Incidents; d. Restoring operations; e. Developing and Implementing Communication Protocols for Security Incidents; f. Obtains Understanding of Nature of Incident and Determines Containment Strategy; g. Remediation Identified Vulnerabilities; h. Communicating Remediation Activities; and, i. Evaluating the Effectiveness of Incident Response and periodic incident evaluations. 213
SWIFT_CSCF_2024 2.1 SWIFT_CSCF_2024_2.1 SWIFT Customer Security Controls Framework 2024 2.1 Risk Management Internal Data Flow Security Shared The protection of internal data flows safeguards against unintended disclosure, modification, and access of the data while in transit. To ensure the confidentiality, integrity, and authenticity of application data flows between ’user’s Swift-related components. 48
SWIFT_CSCF_2024 6.2 SWIFT_CSCF_2024_6.2 SWIFT Customer Security Controls Framework 2024 6.2 Risk Management Software Integrity Shared Software integrity checks provide a detective control against unexpected modification to operational software. To ensure the software integrity of the Swift-related components and act upon results. 16
SWIFT_CSCF_2024 6.3 SWIFT_CSCF_2024_6.3 SWIFT Customer Security Controls Framework 2024 6.3 Risk Management Database Integrity Shared Database integrity checks allow unexpected modification to records stored within the database to be detected. To ensure the integrity of the database records for the Swift messaging interface or the customer connector and act upon results. 16
Initiatives usage
Initiative DisplayName Initiative Id Initiative Category State Type polSet in AzUSGov
[Deprecated]: Azure Security Benchmark v2 bb522ac1-bc39-4957-b194-429bcd3bcb0b Regulatory Compliance Deprecated BuiltIn true
[Deprecated]: New Zealand ISM Restricted v3.5 93d2179e-3068-c82f-2428-d614ae836a04 Regulatory Compliance Deprecated BuiltIn unknown
[Preview]: CMMC 2.0 Level 2 4e50fd13-098b-3206-61d6-d1d78205cb45 Regulatory Compliance Preview BuiltIn true
[Preview]: Nexus Compute Cluster Security Baseline 336cb876-5cb8-4795-b9d1-bd9323d3487e Nexus Preview BuiltIn unknown
CSA CSA Cloud Controls Matrix v4.0.12 8791506a-dec4-497a-a83f-3abfde37c400 Regulatory Compliance GA BuiltIn unknown
Cyber Essentials v3.1 b2f588d7-1ed5-47c7-977d-b93dff520c4c Regulatory Compliance GA BuiltIn unknown
EU 2022/2555 (NIS2) 2022 42346945-b531-41d8-9e46-f95057672e88 Regulatory Compliance GA BuiltIn unknown
FBI Criminal Justice Information Services (CJIS) v5.9.5 4fcabc2a-30b2-4ba5-9fbb-b1a4e08fb721 Regulatory Compliance GA BuiltIn unknown
FedRAMP High d5264498-16f4-418a-b659-fa7ef418175f Regulatory Compliance GA BuiltIn true
FedRAMP Moderate e95f5a9f-57ad-4d03-bb0b-b1d16db93693 Regulatory Compliance GA BuiltIn true
HITRUST CSF v11.3 e0d47b75-5d99-442a-9d60-07f2595ab095 Regulatory Compliance GA BuiltIn unknown
Microsoft cloud security benchmark 1f3afdf9-d0c9-4c3d-847f-89da613e70a8 Security Center GA BuiltIn true
New Zealand ISM 4f5b1359-4f8e-4d7c-9733-ea47fcde891e Regulatory Compliance GA BuiltIn unknown
NIST SP 800-171 Rev. 2 03055927-78bd-4236-86c0-f36125a10dc9 Regulatory Compliance GA BuiltIn true
NIST SP 800-53 Rev. 4 cf25b9c1-bd23-4eb6-bd2c-f4f3ac644a5f Regulatory Compliance GA BuiltIn true
NIST SP 800-53 Rev. 5 179d1daa-458f-4e47-8086-2a68d0d6c38f Regulatory Compliance GA BuiltIn true
NL BIO Cloud Theme 6ce73208-883e-490f-a2ac-44aac3b3687f Regulatory Compliance GA BuiltIn unknown
NL BIO Cloud Theme V2 d8b2ffbe-c6a8-4622-965d-4ade11d1d2ee Regulatory Compliance GA BuiltIn unknown
NZISM v3.7 4476df0a-18ab-4bfe-b6ad-cccae1cf320f Regulatory Compliance GA BuiltIn unknown
RMIT Malaysia 97a6d4f1-3bed-4cf4-ac5b-0e444c0408d6 Regulatory Compliance GA BuiltIn unknown
SOC 2 Type 2 4054785f-702b-4a98-9215-009cbd58b141 Regulatory Compliance GA BuiltIn true
SOC 2023 53ad89f5-8542-49e9-ba81-1cbd686e0d52 Regulatory Compliance GA BuiltIn unknown
SWIFT Customer Security Controls Framework 2024 7499005e-df5a-45d9-810f-041cf346678c Regulatory Compliance GA BuiltIn unknown
History
Date/Time (UTC ymd) (i) Change type Change detail
2024-08-09 18:17:47 change Minor (6.2.0 > 6.3.0)
2024-02-20 22:44:08 change Minor (6.1.0 > 6.2.0)
2023-05-01 17:41:52 change Minor (6.0.1 > 6.1.0)
2022-10-21 16:42:13 change Patch (6.0.0 > 6.0.1)
2022-09-19 17:41:40 change Major (5.0.0 > 6.0.0)
2022-07-08 16:32:07 change Major (4.2.1 > 5.0.0)
2022-06-17 16:31:08 change Patch (4.2.0 > 4.2.1)
2022-04-29 18:06:01 change Minor (4.1.0 > 4.2.0)
2022-04-01 20:29:14 change Minor (4.0.2 > 4.1.0)
2021-12-06 22:17:57 change Patch (4.0.1 > 4.0.2)
2021-09-08 15:39:57 change Patch (4.0.0 > 4.0.1)
2021-08-30 14:27:30 change Major (3.0.0 > 4.0.0)
2021-03-02 15:11:40 change Major (2.0.1 > 3.0.0)
2020-12-11 15:42:52 change Major (1.0.1 > 2.0.1)
2020-09-15 14:06:41 change Previous DisplayName: [Preview]: Kubernetes cluster containers should run with a read only root file system
2020-07-08 14:28:08 add df49d893-a74c-421d-bc95-c663042e5b80
JSON compare
compare mode: version left: version right:
JSON
api-version=2021-06-01
EPAC