Automated assurance on a path to becoming practical

By on 27 Mar 2024

Category: Tech matters

Tags: , ,

Blog home

Cloud-native architecture is a game changer for security at scale. Whether the architecture is used on-premises or in the cloud, capabilities to ease the management of IT assets are continuously improving. Yes, there’s a long way to go in terms of simplifying interfaces and reducing barriers in terms of skill set requirements for managing cloud-native platforms and server-less infrastructure, built on cloud-native platforms, and this too will come in time.

How security and assurance are managed changes in a cloud-native architecture from traditional infrastructure. The standardized methods used on traditional infrastructure that require distributed configuration management by each organization 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. 

Figure 1 — Explosion in the risk surface area of a cloud-native application.
Figure 1 — Explosion in the risk surface area of a cloud-native application.

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 virtualized, 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 (for example, 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 utilizes the server host’s TPM, vTPM, and Trusted Execution Environment (TEE).

The second and most commonly used method today stems from the capabilities used in virtualized 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 still needed 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 realized 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 organizations 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 TEE to prevent tampering. The third option is a very good one if you have the resources to run fully in a TEE.

The first method introduced in this post 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 realize automation through attestation, built-in at scale:

  1. 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. A range of engineers from several organizations 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 standardize the approaches to assure policies and measurements are as expected using attestation consistently across platforms.
  3. 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’re likely to see a basic capability emerge across the commonly used container orchestration platforms (for example, 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 (such as benchmarks). Over time, these templates should become standardized 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.

Rate this article

The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.

Leave a Reply

Your email address will not be published. Required fields are marked *