The Secure Runtime Maturity Framework

Not sure what the difference between zero cve images, vm backed isolation or unikernels are? Trying to figure out where your infrastructure sits and where you might be able to improve your security posture? Well you're in luck cause we have put together the Secure Runtime Maturity Framework.

A lot of people are starting to come to grips with the fact that normal containers simply don't cut it for security anymore. Thus we've seen an explosion of new runtime security models on the market lately. Some say maintaining zero cve images improves the situation while others argue that containers can only provide isolation when put inside virtual machines. While we agree to both of these statements there are substantially more powerful options out there that not everyone might be aware of. It is useful to know where your organization stands with regards to runtime security and how to distinguish amongst the various paradigms.

Enter the Secure Runtime Maturity Framework.

Normal Containers

CVE Remediation

The vast majority of companies that make up this framework are using plain old containers running on kubernetes. These companies might be using scanners such as snyk or trivy to detect known vulnerabilities in their images. These scanners typically are ran inside ci/cd pipelines. Many docker images will have quite a lot of cves and it is up to the overworked devops folks to find some time to manually remediate known vulnerabilities in these images.

Unknown Vulnerabilites

Unknown vulnerabilities plague most rungs of the secure runtime maturity framework. It is very hard to detect security issues that are not known. There are tools that do dynamic analysis or runtime instrumentation to do things like ensure known bad hosts are not being talked to but outside of that it's rather hard to defend against an unknown vulnerability

Isolation

Out of the box containers provide zero isolation. Isolation can be characterized as isolation between one container and another container and it can also be differentiated between a guest container and the host system. Container escapes happen all the time because there is no create_container(2) unlike a virtual machine that has actual hardware backed isolation. It is important to note that all the major public clouds including AWS, GCP and Azure are 100% built on virtual machines - not containers. gVisor from Google was built to provide a sandbox environment for containers. Firecracker from AWS was built to provide vm backed isolation for containers. Apple recently released a container runtime that isolates each individual container inside of a virtual machine.

Lateral Movement

Lateral movement is what happens after an attacker gains initial access to a company's infrastructure. A classic example that plagued JVM environments for a long time were deserialization attacks where an attacker would upload an object to an application server, it would deserialize it incorrectly and place a webshell on the server allowing the attacker to jump right in without the need for ssh or key or password. Once the attacker is on the virtual machine or container they can then start mapping out the rest of the infrastructue and typically have a lot more access than they should. For instance many production databases are not addressable from the internet - they only listen on internal network ips. In this example where an attacker was able to go through a publicly listening webserver and land a shell inside there is a very good chance that the database ip address, username and password are all easily available and the attacker can connect to it. Not only could the attacker dump the database but they could probably spawn a shell from the database as well! For instance on postgres this is as easy as executing `\!` on the psql client or `copy` from raw sql. Once an attacker breaches the database server this way they can probably hijack all incoming connections as well. What this means is that even though they started out on one JVM webapp server they can probably start getting entry to *other* servers that are talking to the same database.

This is why many security pros consider your infrastructure completely compromised if even a single instance is breached. We will address defensive measures for this later on in the framework.

Zero CVE Images

Known CVE Remediation

So-called zero cve images are a step up from normal containers as these images are carefully curated by third party vendors to ensure that no known CVEs are present in images. Through a number of directives including BOD 22-01 (Known Exploited Vulnerabilities) the government has started mandating that known cves be addressed in a timely manner. This is in general good deployment hygiene but is a tax on organizations that perhaps don't have the time to do it themselves.

Zero CVE images also are still susceptible to unknown vulnerabilities. They also do not prevent lateral movement. Since zero cve images are still containers they do not provide vm isolation either. Finally, zero cve images can easily run attacker provided software as the underlying kernel is fundamentally built with the notion of mulitple users and multiple running applications.

VM Isolated Images

Hardware Backed Isolation

Apple recently announced vm isolated containers for its new container runtime hitting the macOS Tahoe release later this fall. They aren't the first to do this though. AWS has firecracker and Google has gVisor and there are a host of other vendors that have fully embraced vm isolated images as well.

While containers brought more composable and downloadable developer environments they completely dropped the hardware isolation that the big clouds have provided for 20 years now. It's only recently been that many organizations are starting to realize how important it is.

Lateral Movement

While vm backed containers play a pivotal role in hardening defenses against lateral movement they themselves are not a panacea. They help prevent movement in the case of a container breakout allowing another container from being immediately attacked but do nothing in traditional vm to vm networks as mentioned earlier in the example where an attacker has compromised a JVM web application and jumps to the webserver.

Unikernels

A lot of literature exists on the role of unikernels when it comes to security. Unfortunately a lot of it was written by people who had no security background and focused on the wrong things. Attack surface reduction, while true, is not a compelling argument to an attacker.

Exploit Payload Mitigation

One of the most compelling features of unikernel security in the secure runtime maturity framework is exploit payload mitigation. The vast majority of exploit payloads are designed to do one thing - execute an attackers program. Many of the exploit payloads are very naive as the vulnerablity they are exploiting is so easily abused. This typically manifests itself as a call to system or fork/exec to run a shell or run a program. If it's a shell then it allows the attacker to download new software, compile new software, give them access to tools to enumerate the network, etc.

Not only can unikernels not execute new programs but advanced unikernels can also disallow exec-mapping anything not explicitly mapped as executable. In this example we aren't even talking about external programs - we are just talking about memory.

Furthermore pledge and unveil can be utilized to futher lock down an application.

Lateral Movement Protection

While all the prior rungs of the secure runtime maturity framework do nothing to prevent lateral movement unikernels really shine here. Unikernels have no notion of users. The nanos unikernel itself, unlike linux, has no capability of running other programs on it. It is not like a seccomp filter - it simply does not have support. They do not have shells that you can login to or ssh. This is extremely important because of an attacker has found a vulnerability in your application they can't simply use off the shelf tools to enumerate the instance, its network or other things. All of this will have to be put into the memory they control and becomes quite hard. Since unikernels make use of common linux security primitives such as ASLR and page permissions enforced with w^x having to construct ROP gadgets out of a memory space that gets re-organized on every deploy becomes extremely difficult.

CWE Class Eliminations

Finally unikernels kill off entire weakness classes such as CWE-77 (Improper Neutralization of Special Elements used in a Command ('Command Injection')), CWE-78, (Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection')) CWE-309 (Use of Password System for Primary Authentication), many cases of CWE-22 (Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')), many cases of CWE-434 (Unrestricted Upload of File with Dangerous Type) and much much more. Two of these sets were in the top 25 last year.

The Secure Runtime Maturity Framework is here as a guide for devops, SREs, sysadmins, and architects to help validate their secure runtime challenges and goals. If you have further questions or would like to discuss how you can elevate your security posture don't hesitate to reach out.