More and more companies are moving their workloads to the cloud - and for a good reason: it reduces the cost and the associated risk in comparison to running and maintaining the solutions themselves. Clearly, the shift to the cloud does not come for free. There are three points in particular that many companies are struggling with: Technical complexity, maintaining security, and ensuring compliance (Palo Alto, The State of Cloud-Native Security 2020).

Technical complexity arises from the fact that “moving to the cloud” means adopting new technology and does not mean deploying legacy software on resources provided by the Cloud Service Provider (CSP). To make use of the cost benefits, the software also needs to be adopted to cloud-native technologies (i.e. it should be provisioned using modern cloud-native technologies such as Kubernetes, CloudFormation, Terraform, or Serverless.) Only cloud-native technologies are able to make full use of the on-demand payment models that CSP promises. For more details see a post by one of my colleagues..

In this post our focus lies on the second of the abovementioned most critical challenge when moving to the cloud: maintaining security. Security itself, also prior to the cloud era, has been a challenge for many companies, as expertise in the area is rare.

Within the cloud security remains a challenge, as software is released even faster. With the "Shared Responsibility" security model that large cloud providers apply, part of the security responsibility is taken care of by the cloud provider. (for instance, physical hardware security, OS, and network security). New challenges that companies need to handle are a) secure configuration of the cloud account (setting minimal IAM permissions) and b) secure application level (i.e. address CVEs in third-party libraries and vulnerabilities in the own code).

Luckily, we have a large set of tools that help us detect security vulnerabilities as well as cloud misconfigurations. Unfortunately, with a large set of tools, the set of potential warnings easily reach between 100s and 1.000s that experts and developers need to navigate through and prioritize. This raises the question:

How do Companies Currently Prioritize Security Vulnerabilities?

A common way to prioritize security vulnerabilities is to prioritize them based on the scores that are pre-assigned by the underlying security tools, e.g., tools that perform software composition analysis (SCA) or software application security testings (SAST). Each security issue is assigned a score, mostly following the classification of easy, medium, high, and critical. SCA tools typically report the CVSS score associated with each CVE. The CVSS score is assigned by CVE Number Authorities (for instance GitHub) at the time when the vulnerability is reported. The score is assigned based on the information available to the authority at the time of the report. The score is rarely updated later on when more information is available. But this information clearly lacks context: the context of your application, your business, and the impact it may have on your application.

Best practice for Prioritizing Security Vulnerabilities

With 100s to 1.000s of findings that security teams have to navigate, the severity score is only a first indication for prioritization. Companies have to bear in mind that severity alone does not map the company risk associated with each vulnerability. The risk can clearly significantly differ from the default suggested CVSS score. Even a low severity vulnerability can have a severe impact on one’s own application. A low vulnerability may serve as an entry point for an attacker to navigate through the software.

So what is the business risk associated with a vulnerability? Well, it depends…Vulnerability assessment suggests that the business risk of a vulnerability depends on four parameters (Figure 1):

Figure 1: Security Risk is a combination of Vulnerability Score, Threat Context, Asset Exposure, and Business Impact

Vulnerability Severity Score: CVSS score given by code scanning tools (SCA, SAST,…) or other severity score provided by tools.

Threat Context: Additional meta-information about the vulnerability: How often has this vulnerability been exploited elsewhere? Is there an exploit publicly available? Have other companies been hacked because of this vulnerability?

Business Impact: Given that the vulnerability is exploited, which assets can be leaked? And what is the business value associated with these assets?

Asset Exposure: Is the affected component/resource containing the vulnerability publicly reachable? How complicated is it for an attacker to reach the affected resource that contains the vulnerability? 

The good news is that with cloud-native determining asset exposure as well as automatically estimating the business impact is possible. And here is how:

How can we Automatically Assess the Asset Exposure?

By shifting to cloud-native software, infrastructure provisioning is becoming more automated and standardized in the form of Infrastructure-as-Code. Infrastructure-as-code is version-controlled alongside the application, which also means we can automatically analyze the code and derive additional application semantic from it.

See the diagram below (Figure 2) which depicts a CloudFormation template of a cloud-native application visualized in the form of a data-flow diagram. Highlighted in red is one cloud resource (an AWS Lambda called OrderGetFunction) which contains a vulnerability. Additionally, you see a graph that contains potential attack paths from different APIGateway methods within the infrastructure leading to the vulnerability. All paths end in the affected resource and start in different API endpoints (AWS ApiGatewayApi resources). Given the paths, one can decide and estimate the impact the vulnerability has on your application. Is the resource externally reachable at all?

Figure 2: Potential attack paths in a cloud-native application (the red node contains a vulnerability)

In the given case, you can see that the affected resource containing the vulnerability is reachable via several API gateway methods. For all paths, however, there are two hops in the infrastructure necessary as there are AWS Lambda nodes inbetween. An attacker must therefore craft an exploit to reach across two resources.

If you want to prioritize your security workload and automatically assess your cloud security infrastructure, at CodeShield we are happy to help.

About the Author

Johannes Späth is an AWS Community Builder and a co-founder of CodeShield, a context-aware cloud-native security tool. CodeShield allows you to automatically visualize your cloud environment. Sign up with GitHub to connect your AWS account. Johannes completed his Ph.D. in static program analysis. In his dissertation, he invented a new algorithm for data-flow analysis which allows automated detection of security vulnerabilities.