Automated Assurance on a Path to Becoming Practical

There's are significant differences in how security and assurance are managed in a cloud native architecture as opposed to traditional infrastructure. The standardised methods used on traditional infrastructure that require distributed configuration management by each organisation do not work in a cloud environment.

This is good news as this architecture presents an opportunity to ease security management and make it accessible to businesses of all sizes. 

Security rooted in hardware is becoming more accessible now that trusted platform modules (TPMs) are near ubiquitous and trusted execution environments or secure enclaves are becoming a more common part of the CPU. This allows for increased use of these components to assure systems, applications, and data are as expected using attestation inherent to the system measuring current state values against a set of expected values for a level of compliance. Open source projects are gaining traction through efforts such as the Confidential Computing Consortium (CCC), the Cloud Native Computing Foundation (CNCF), and the Internet Engineering Task Force (IETF)to scale management, built-in resiliency, and assure the integrity of systems and software in cloud native platforms.

Understanding why a cloud native architecture presents a game change is important. As we transitioned from traditional infrastructure to virtualised, and now to cloud native, a tremendous amount of work has been put in by thousands of engineers to architect resiliency, flexibility, and isolation into this updated architectural design. Layers have been created to allow for quick updates that are focused on specific code segments (e.g. DevOps and microservices) as well as the ability to move workloads to aid in quick remediation from a vulnerability or to recover from an attack.

The cloud native architecture has three possible areas to provide integrity assessments, with the most efficient and elegant being through trusted assurance rooted in hardware using a technology called attestation. This method utilises the TPM, vTPM, and TEE of the server host. The second and most commonly used method today stems from the capabilities used in virtualised and traditional environments, where an SSH connection or API is used to interrogate a system or application, comparing results  to a set of expected configuration settings. This method works and is part of several cloud security posture management (CSPM) and cloud native application protection (CNAPP) products today. These capabilities are needed still today for assurance, but how integrity is assured in cloud native platforms should begin to shift over the coming year with some of these products integrating results from the first method rather than performing the interrogation themselves.

This transition will take several years to be realised more fully and is possible to achieve with the cloud orchestration platform and existing libraries today. CSPM and CNAPP products have the opportunity to adapt to continue to serve organisations that require a composite picture of assets as described in the transition steps below.  The third method is already available in at least one commercial cloud provider, and it assures a workload by running it completely within a Trusted Execution Environment (TEE) to prevent tampering. The third option isa very good one if you have the resources to run fully in a TEE.

The first method introduced in this blog is meant to cut costs, while providing an elegant solution that is built-in to the container orchestration platform, obviating the need for additional software that interrogates the contents of a container and having to manage that external software.

Steps to realise automation through attestation, built-in at scale:

1. Supporting libraries: Libraries supporting the integrity assessment of code in a container using attestation are now available. Multiple proofs of concepts using this technique have been conducted, including one from RedHat and  the one described below in an internship project by John Schmidt while at the Center for Internet Security (CIS) in 2023. Sean Turner assisted in the project, ensuring options for key management and cryptographic options were appropriately selected.
2. Documentation and standards: A range of engineers from several organisations are working to architect the expected patterns for automated configuration and integrity assurance up the stack in a cloud native environment. This step provides documentation to unify and standardise the approaches to assure policies and measurements are as expected using attestation consistently across platforms.
3. Compliance reporting: Reporting of compliance against a set of policies or measurements to governance, risk, and compliance (GRC) management solution, CNAPP, or CSPM product if one is used. Alternatively, reliance could be maintained in the container management system to ensure compliance and include remediation and isolation capabilities within a cloud native environment.

We will likely see this capability emerge gradually since it is built on open source software and cloud management platforms will have to integrate and ease the configuration process for this capability.

First, we can expect to see a basic capability emerge across the commonly used container orchestration platforms (e.g. VMWare/Broadcom, RedHat OpenShift, and Xen). The initial capability might provide a method to create templates to ensure software to a set of expected policies and measurements (e.g. benchmarks). Over time, these templates should become standardised to levels and available for selection, such as those defined by the CIS Benchmarks. The first iterations will be much like today’s cloud platforms, where the administrator will need to be knowledgeable. 

Within a year or two, we should begin to see steady improvements where generic templates are available to select compliance levels of popular software and operating systems from the container orchestration platform. The ability to establish policies and measurements of additional software packages will grow in time and the ability to manage this capability will become easier as well. We will also see the ability to report compliance evolve after the assurance of integrity and configuration settings is more widely available.

If you are interested in learning more or joining in to help progress this work, the linked IETF Remote Attestation working group, Confidential Computing Consortium, Cloud Native Computing Foundation, and open source projects are all possible options.

Proof of concept project summary (John Schmidt)

A project was proposed to align policies to both CIS Ubuntu 20.04 LTS v2.0.1 server and Kubernetes v1.7.1 benchmarks where drift could be measured with TPM assurance.

The project sought to assist underserved State, Local, Tribal, and Territorial (SLTT) organisations in providing low-cost, built-in alternatives to paid software assurance platforms. After some research, it seemed fitting that Linux IMA, considering its demonstrated remote attestation capabilities, be tested for the capability. Linux IMA is a subsystem within the Linux kernel introduced in the Linux 2.6.30 kernel in 2009. It can measure, store, and appraise TPM-assured IMA file hashes against a stored value to confirm file integrity. IMA can also enforce default and custom-loaded policies, offering the ability for a greater number of benchmarks covered. Examples of such policies may include creating a runtime custom policy noting file changes as they occur or directing IMA not to measure event logs. A runtime policy could include a response to prevent access to an object if a file hash does not match a stored value.

Testing took place in a vSphere 8 environment, where a single Kubernetes cluster was created with vTPM support for IMA and with one deployed pod running Ubuntu 20.04 LTS server. Testing showed up to 54.5% of the worker node level 1 recommendations for CIS’s Kubernetes v1.7.1 benchmark were possible out-of-the-box with existing tuneable IMA policies.  Accordingly, the Ubuntu 20.04 LTS v2.0.1 server benchmark recommends some file integrity management. However, it recommends downloading AIDE, a third-party program. Because of security concerns, cost, and ease of management, built-in solutions are preferred for those with fewer resources. The proof of concept proved the capability to ensure a set of policies and measurements could be attested for container environments, including operating systems and applications running in containers.