OpenShift cyber hardening: Australian E8 and ISM

This document provides a detailed analysis of Australian Information Security Manual (ISM) controls and Essential Eight (E8) strategies to mitigate risk, and how Red Hat Advanced Cluster Security for Kubernetes (RHACS) helps to align with these strategies and controls. RHACS is a Kubernetes-native security platform provided by Red Hat and helps to protect containerized OpenShift workloads throughout the build, deploy, and runtime phases of the container application lifecycle.

This document enables security architects, platform engineers, compliance teams, and auditors to better align Red Hat OpenShift Container Platform with the Essential Eight and ISM risk management strategies, and support these teams to manage risk for container workloads.

Specifically, the document covers how OpenShift can be configured to address the following ISM controls and Essential Eight risk mitigation strategies:

• Application control and SIEM Integration
• Patching applications and CVE vulnerability Analysis
• CI/CD pipelines and application hardening
• Least privilege and role-based access controls
• Network segmentation & observability
• Phishing-resistant, multi-factor authentication

Application control

ISM-1490 / ISM-1656 / ISM-1657 / ISM-1392 / ISM-1746

Application control is usually a difficult Essential Eight strategy for any organization to implement. Existing solutions typically focus on deploying agents to systems - such as Airlock or Microsoft Defender for Endpoints - and then configuring centralized allow-lists. However, deploying agents to containers is an anti-pattern and compromises the benefits of moving applications to containers - workload consistency and portability.
Red Hat Advanced Cluster Security for Kubernetes (RHACS) provides a sophisticated application control mechanism that aligns closely with the requirements of the Essential Eight while preserving consistency and portability for workloads.

RHACS uses an extended Berkeley Packet Filter (eBPF) probe to detect processes running in containers on OpenShift and then allows this baseline to be locked. If a process is detected running in the container that falls outside this baseline (via the eBPF probe), the workload is terminated and recreated; immediately destroying any attacker-controlled processes, restoring the service, and reporting the application control violation through to a configured SIEM.

Figure 1: The RHACS locked process baseline for an OpenShift workload.

In this screenshot from Red Hat Advanced Cluster Security for Kubernetes, the only processes permitted to run inside the container are associated with the JVM. Any other process detections will result in a policy violation, followed by first-level incident response and violations being forwarded to the SIEM. The ‘lock’ icon, highlighted in red, indicates that the process baseline is currently locked.

OpenShift also supports several native configurations that enable cluster-level workload control, aligning with the intent of these ISM controls without the workload fidelity that RHACS provides. These configurations control allow-listing source registries, ensuring that containers can only be deployed from trusted locations. These do not require additional operators, and are natively supported by the platform.

The OpenShift configuration options are allowedRegistries and allowedRegistriesForImport.

The difference is subtle, but important:

• allowedRegistriesForImport limits the container image registries from which normal users may import images. It only affects the image API, for example, oc import-image and ImageStreams.
• allowedRegistries determines how the container runtime (CRI-O) should treat individual registries when accessing images for builds and pods.

Both options need to be configured to effectively limit the registries used for a cluster. These configuration options are included in the OpenShift Compliance Operator “Essential Eight” security profile, enabling cluster operators to scan for misconfigured clusters.

RHACS supports vizualizing the results of the OpenShift Compliance Operator scans and reporting these through to the SIEM. For example, the allowedRegistries and allowedRegistriesForImport configurations reported by the OpenShift Compliance Operator “essential eight” profile, and allows these compliance issues to be visualized across clusters. RHACS natively integrates with several SIEMs, including Splunk and AWS Security Hub, and also supports a SplunkBase add-on to centralize compliance and CVE data. The platform also provides generic syslog and webhook integrations for other security platforms, such as Microsoft Sentinel.

The OpenShift Compliance Operator results for application control-related configuration visualized in RHACS. The screenshot shows that the allowedRegistries and allowedRegistriesForImport configurations have not been applied, and container images can be deployed from any registry.

Patch applications

ISM-1694 / ISM-1695 / ISM-1696 / ISM-1698 / ISM-1700 / ISM-1701 / ISM-1702 / ISM-1752 / ISM-1703

The Essential Eight makes specific reference to the frequency of vulnerability scanning and patching activities. Essential Eight maturity levels one, two, and three require that patches, updates, or vendor mitigations for internet-facing services are applied within 48 hours if an exploit exists for a vulnerability. In addition, ISM-1698 requires that a vulnerability scanner is used at least daily to identify missing patches or updates.

Red Hat Advanced Cluster Security for Kubernetes (RHACS) updates Common Exposures and Vulnerabilities (CVE) definitions every 5 minutes. Containers deployed to OpenShift are re-evaluated with the latest definitions every 4 hours. A risk mitigation strategy that Red Hat recommends is to implement RHACS workflows that integrate CVE data streams with SIEMs and support SOC analysis and block workloads with critical vulnerabilities from the OpenShift platform via admission control (supported by RHACS).

RHACS extends vulnerability scanning and patch management across language runtimes (Java, JavaScript, Python, and Ruby) and application frameworks (.NET Core and ASP.NET Core). Vulnerability scanning is also supported for container images created from a number of operating systems, as shown in the following table.

Operating system	Version
Red Hat Enterprise Linux (RHEL)	rhel:6, rhel:7, rhel:8, rhel:9
Alpine Linux	alpine:v3.2, alpine:v3.3, alpine:v3.4, alpine:v3.5, alpine:v3.6, alpine:v3.7, alpine:v3.8, alpine:v3.9, alpine:v3.10, alpine:v3.11, alpine:v3.12, alpine:v3.13, alpine:v3.14, alpine:v3.15, alpine:v3.16, alpine:edge
Amazon Linux	amzn:2018.03, amzn:2
CentOS	centos:6, centos:7, centos:8
Debian*	debian:9, debian:10, debian:11, debian:unstable
Ubuntu*	ubuntu:14.04, ubuntu:16.04, ubuntu:18.04, ubuntu:20.04, ubuntu:21.10, ubuntu:22.04

*Older versions of Debian and Ubuntu are also supported, however the vulnerability sources and definitions are no longer updated by the vendor, for example,Debian 8.

This approach improves upon early container vulnerability scanning practices, as RHACS identifies vulnerabilities in active container workloads deployed to platforms, and in image registries. This means that security teams can uncover the true impact of a vulnerability in a containerized environment far quicker than they could have in a traditional virtual machine-based environment, and makes it easier to meet the 48-hour patching requirements identified in the Essential Eight maturity levels.

Phishing-resistant, multi-factor authentication

ISM-1504 / ISM-1505 / ISM-1173 / ISM-0974 / ISM-1682 / ISM-1894 / ISM-1401 / ISM-1683

The November 2023 Essential Eight update now requires phishing-resistant, multi-factor authentication at lower maturity levels. MFA fatigue and similar MFA bypass attacks have been used in several high-profile attacks over the years and target an inherently human condition. We make mistakes when we are tired, and it only takes one 'allow' prompt mistakenly clicked late at night to allow threat actors access to an account.

Phishing-resistant MFA is designed to specifically thwart these types of MFA bypass and MFA fatigue attacks. It uses security keys to provide the additional factor required for a login.

Security keys are small devices that connect to your computer or phone, allowing you to authenticate by physically touching the key or providing biometrics. Because only the user has physical access to the device and it doesn't support push notifications, it inherently mitigates many of these MFA bypass techniques.

You can configure phishing-resistant MFA for OpenShift using the Red Hat build of Keycloak (RHBK). This is a hardened and supported build of the open source Keycloak project from Red Hat and is provided with every OpenShift subscription.

RHBK allows you to create a browser-based Web Authentication (WebAuthn) flow, requiring users to present security keys to log in to OpenShift.

You can specify required user actions, such as registering security keys on the first log in to OpenShift.

Once users have registered their security keys, they will be prompted for it every time they log in to OpenShift, meeting the Essential Eight requirements for phishing-resistant MFA. Keycloak provides a complete audit log of successful and unsuccessful authentication attempts, which can be exported to an SIEM or similar security event logging solution.

User application hardening

ISM-0484 / ISM-0485 / ISM-1449 / ISM-0487 / ISM-0488 / ISM-0489 / ISM-1506

Red Hat Advanced Cluster Security for Kubernetes (RHACS) provides out-of-the-box policies that support developers to harden container applications, aligning with this Essential Eight strategy. These policies can be integrated with continuous integration and continuous development (CI/CD) pipelines.
Sample policies that align with user application hardening are shown below. If any of these policies are violated, CI/CD pipelines will fail, alerting developers to the failed security violation. Vulnerable workloads will be blocked by the RHACS Kubernetes admission controller.
For example:

• Netcat in image: This policy ensures that container images must not have the ‘netcat’ binary installed. Netcat can be used by attackers to probe internal services and move laterally once initial access is gained.
• Log4Shell Remote Code Execution vulnerability: This policy ensures that vulnerable log4j libraries are not present in Java applications. Log4Shell is a critical vulnerability that is trivial to exploit and can remotely access running Java applications.
• Secure shell (ssh) port exposed in image: This policy verifies whether container workloads are attempting to expose secure shell (SSH) access. SSH access is typically not used for container workloads, as it has fewer audit protections than Kubernetes execution, and presents a larger attack surface.

Restrict administrative privileges

ISM-1507 / ISM-1733 / ISM-1508 / ISM-1175 / ISM-1653 / ISM-1649 / ISM-0445 / ISM-1509 / ISM-1650 / ISM-1651 / ISM-1652

Red Hat Advanced Cluster Security for Kubernetes (RHACS) provides visibility into user privileges across OpenShift clusters and makes it easier to determine where cluster-administrative privileges have been created.

RHACS creates a consolidated view of cluster-wide RBAC, as shown in Figure 3. This provides security teams and platform administrators the ability to quickly identify anomalous administrative access, and remove these permissions.

RHACS also provides out-of-the-box policies that alert workloads requesting privileged access. Privileged access on Kubernetes and OpenShift means that workloads run without SELinux confinement, can access host-level resources, and are generally restricted.

Sample policies that align with this control are:

• Container with privilege escalation allowed: This policy alerts if a Kubernetes deployment has containers with allowPrivilegeEscalation set to true in its security context.
• Privileged containers with Important and Critical fixable CVEs: This policy alerts on containers running in privileged mode with Important or Critical fixable vulnerabilities.
• Ensure that a user for the container has been created: This policy alerts if a container tries to run as the root user.

Figure 2: RHACS consolidated view of user permissions across clusters and namespaces.

This screenshot shows consolidated user accesses across OpenShift clusters displayed in the RHACS console.

Network segmentation and observability

ISM-0520 / ISM-1182 / ISM-1271

OpenShift provides built-in capabilities supporting network segmentation and observability, aligning with the ISM controls that require network access controls implemented.

Kubernetes network policy is the default network isolation mode in OpenShift. By default, all pods in a project are accessible from other pods and network endpoints. To isolate one or more pods in a project, NetworkPolicy objects can be created in that project to indicate the allowed incoming connections.

Red Hat Advanced Cluster Security for Kubernetes (RHACS) simplifies network policy for security teams and operators, allowing them to visualize network traffic flows and simulate network policy. This enables security teams and cluster administrators to apply fine-grained control over network access controls, and visualize and simulate changes to network access controls.

Figure 3. RHACS Network Topology.

This screenshot from Red Hat Advanced Cluster Security for Kubernetes shows the network connections between application components and external sources. This screenshot also shows that there are no egress controls currently in place - all data egress is permitted.

Network policy can also be applied directly to OpenShift clusters. For example, the following NetworkPolicy denies all network connections by default. It matches all pods but accepts no traffic.

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: deny-by-default
spec:
  podSelector: {}
  ingress: []

A strategy Red Hat recommends for minimizing anomalous network traffic - which may represent data exfiltration, or attackers trying to move laterally within the network - is to implement network behavioral analysis for container workloads. A network traffic baseline for each OpenShift workload is created using an extended Berkeley Packet Filter (eBPF) probe, which can then be locked. Once locked, any anomalous network traffic flows result in the container workloads being recreated, and alerts sent to the SIEM.

This approach aligns closely with control ISM-1182, which requires that ‘servers minimize communications with other servers at both the network and file system level.’ It also means that less time is spent by security analysts identifying anomalous network traffic from OpenShift workload logs or node-level network traffic flow logs. Anomalous network traffic has already been validated by Red Hat Advanced Cluster Security for Kubernetes when alerts are created within the SOC, simplifying alignment with these ISM controls.

OpenShift also supports a native egress firewall that assists cluster administrators align to ISM requirements to ‘minimize communications with other servers at both the network and file system level’, and limits the external hosts that OpenShift workloads can access.

OpenShift egress firewalls are commonly used in the financial services industry and other data-sensitive environments. The egress firewall supports several network isolation scenarios, for example:

• A pod can only connect to internal hosts and cannot initiate connections to the public Internet.
• A pod can only connect to the public Internet and cannot initiate connections to internal hosts that are outside the OpenShiftcluster.
• A pod can connect to only specific external hosts.
• A pod can connect to only specific hosts.