The public cloud has seen massive adoption over the past few years. The number of workloads and companies that are now “cloud first” is ever increasing—and this growth has not been without incidents. There have been countless security breaches and unintended disclosers due to misconfigured cloud accounts and assets.
At first, when the public clouds only had a few services, the disclosures were mostly due to misconfigured cloud accounts and publicly exposed storage buckets. Yet even today, after years of usage, these types of disclosures continue to occur. Why haven’t security teams figured out a way to prevent such incidents? The reason is that public cloud contains hundreds of different services and configuration parameters, meaning vulnerabilities can go unnoticed until it’s too late. Furthermore, applications are now written in a distributed framework, making following security best practices even more complicated.
Imagine trying to manage the security of your company’s assets across multiple cloud providers. One of your biggest challenges would be trying to find the right balance of managing risk without slowing down development. Knowing that there are hundreds of services and settings within public clouds, which ones would you focus on? How many security rules are needed to prevent a security hole? How do you ensure that the alerts you receive are tactical and don’t contain false positives? What happens when you flood your security operations or end users with hundreds or thousands of alerts? As you can see, if done incorrectly, securing your public cloud could turn into a massive data fog with overwhelming alerts that are never acted upon.
Figure 1 IBM X-Force Threat Intelligence Index 2018
The need for context
Trying to check the configuration of every service available in a public cloud will produce a lot of noise, especially if these checks are applied across all your accounts and application deployments. For example, what is the security risk if you are aren’t using the AWS Web Application Firewall or Autoscaling isn’t enabled? There may be an operational risk, but would you want to be alerted about every one of these findings? What about an open S3 bucket that is publicly accessible? There has been a fair amount of unintended disclosures due to publicly accessible S3 buckets but is that the case every time? Part of understanding risk is understanding context. A public S3 bucket containing marketing ads is very different then your customer database snapshots. Without context, security violations and alerts are just noise.
VMware Secure State’s focus is to help security teams prioritize those findings, better understand the risk, and ultimately help scale the insights that are relevant to service owners. VMware Secure State is designed to focus on specific violations that pose a risk to an organization and minimize unactionable alerts. The product not only looks at a given violation, but also provides the security team with context about the object under consideration. For example, if one finds that they have a security group that allows public access over port 22, VMware Secure State will provide them the necessary context to decide if this is a risk or not by showing all the objects connected to that security group, including the instances, the owner, and other objects that may be at risk because of this violation. This context is what is needed in order validate the risk. Without it, it’s just another alert in a sea of alerts.
Alerts vs risk
The ability to provide context around an alert allows VMware Secure State to help customers make better risk-based decisions about their cloud. This can still overwhelm an organization if the number of rules are not configurable and suppressible. For example, one of our customers has millions of objects in AWS but has a very open deployment model, where end users are given great latitude to deploy objects as they see fit. The security team didn’t want to be alerted about every violation for two main reasons. First, they had a small security team and didn’t want to flood their security operations team with a ton of alerts. Second, they were comfortable with having some misconfigurations that did not pose severe security risks.
They knew that they would not be able to put in a restrictive security policy without a huge backlash from IT and Development. Instead, they leveraged VMware Secure State to focus on eight high risk vulnerabilities. The idea was to attack the most critical vulnerabilities first, instead of being overwhelmed by low priority alerts (eventually leading to a culture of inaction). As the customer slowly gained control over those eight risky violations, they enabled a few more rules. Gradually, they were able to switch on more rules and educate end users so they could manage their risk while continuing to partner with IT and Development.
This is the balance that is needed. The ability to control what security rules are run based on risk and governance allows organization to roll out security controls without flooding people with noise. This also provides a level of trust between the security teams and the end users, since the alerts that are being fired are valid and pose a risk. Furthermore, the service owner is given an actionable alert. They understand the alert, the context, and what actions they need to take to resolve the issue
Beyond violations: finding cross service risks
One of the unique features of VMware Secure State is the ability to find a connected violation chain. Violation chains are risks that wouldn’t be found unless related context was available. The risk is found by looking across a group of related services and correlating conditions that create an elevated risk in your security posture. VMware Secure State looks at the entire cloud presence of an organization. This allows Secure State to find heightened risk due to adjacent objects’ risk posture. For example, one of the threats that VMware Secure State looks for is the presence of a key pair with administrative privileges deployed to a workload that can connect to an internet gateway. Using a key pair with admin privileges on its own isn’t necessarily high risk—the risk is that one of the other workloads that share the same network could be compromised. This would open the customer to a lateral movement attack with a possible outcome of an adversary gaining access to admin level keys.
Want to learn more? Speak to a public cloud security expert and get a VMware Secure State free trial, request a meeting now.
