In a past post we talked about the power of context, and how CloudCoreo @Deploy (our deployment time scanning and Jenkins integration) can be used to supply the context needed to make better decisions about whether to alert, who to notify, and how to remediate cloud vulnerabilities. Discovering these issues early allows teams with significant footprints in public cloud services such as AWS and Azure to make better decisions with less noise. The whole point of @Deploy is to shift left the types of checks we do on cloud object configuration from an afterthought to an integral part of the build pipeline.
Today, I want to talk more about applications. Shifting left is great, but equally important is what we are shifting left. Checking cloud object configuration at the cloud API level is very important (as we have seen so vividly with recent S3 configuration-related breaches) but an application that is being built and deployed in a CI/CD pipeline also consists of compute elements (like instances, containers, functions, etc.) that have their own configuration state as well (processes, files, ports, services, packages, etc.). If the server and application state is not included in the checking, then the picture of vulnerabilities is incomplete, and therefore inaccurate.
CloudCoreo has recently enhanced our rule checking to include these types of endpoint checks. We can now check entire application stacks from file state in an instance or container all the way to the encryption policies applied to the front end application load balancers. Inspecting for configuration vulnerabilities across application, host and cloud infrastructure allows us to better assess the actual risk by correlating vulnerabilities within application infrastructure.
Here’s a simple example of how the presence of multiple alerts might elevate the risk for your application infrastructure:
Essentially, when there are risks present in multiple layers of your infrastructure it can multiply your overall risk.
On the other hand, getting a view of risk across your stack can also help reduce noise and better understand when there are compensating controls in place, so a risk is actually lowered. For example, if the Jenkins job knows it is building application “Checkout,” then our context checking also knows that what we are checking is part of that application. Let’s say the “Checkout” application requires SSH to be turned on for a specific type of instance that is deployed, and that this is normal and expected, and is in fact required. Let’s further state that a second type of instance uses the same AWS security group that has SSH turned on, but the CloudFormation templates that create the instances specifically uninstall the SSH packages and the service can never be listening.
When we both have the context of knowing that a given security group is part of “Checkout,” and we also have access to the endpoint state for all instances that are part of “Checkout” which are also connected to a specific security group, we have all the pieces to correctly conclude that we should not create a violation for port 22 open on this security group because we’re talking about “Checking,” and “Checkout’s” mid-tier instances uninstalled SSH and I can prove it’s uninstalled. Knowing the full picture lets us correlate violations across the infrastructure stack and provide more accurate insight into the true risk for an application and the areas where risk is multiplied.
Security compliance is a numbers and context game. The winners know how to dramatically reduce the number of reported violations so that the automation, processes, and people in an organization are not desensitized to the volume, and then report these few, quality results back early—right after the code that introduces a violation is checked in and built for the first time.