The public cloud has seen massive adoption in recent years. The number of workloads and companies now “cloud first” continues to increase, and this growth has not been without incidents. There have been countless security vulnerabilities and involuntary disclosures due to misconfigured cloud accounts and assets.
In the beginning, when public clouds had only a few services, disclosures were mainly due to misconfigured cloud accounts and publicly exposed storage compartments. Yet even today, after years of use, these types of disclosures continue to occur. Why have security teams not found a way to prevent such incidents? This is because the public cloud contains hundreds of different services and configuration settings, which means vulnerabilities can go unnoticed until it’s too late. In addition, applications are now written in a distributed setting, making it even more difficult to follow best security practices.
Imagine trying to manage the security of your company’s assets across multiple cloud providers. One of your biggest challenges would be to try to find the right balance between risk management without slowing down development. Knowing that there are hundreds of services and settings in public clouds, what would you focus on? How many security rules are needed to avoid a security breach? How do you make sure that the alerts you receive are tactical and do not 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 this is done wrong, securing your public cloud could turn into a huge data fog with overwhelming alerts that are never taken into account.
The need for context
Trying to verify the configuration of each service available in a public cloud will generate a lot of noise, especially if these checks are applied to all your accounts and application deployments. For example, what is the security risk if you don’t use the AWS web app firewall or if self-scaling isn’t on? There may be an operational risk, but would you like to be alerted to each of these results? What about an open S3 compartment accessible to the public? There have been a number of involuntary disclosures due to publicly available S3 compartments, but is that the case every time? Part of understanding risk is understanding the context. An S3 public compartment containing marketing advertisements is very different from snapshots in your customer database. Without context, security breaches and alerts are just noise.
The goal of VMware Secure State is to help security teams prioritize these results, better understand risk and ultimately evolve information relevant to service owners. VMware Secure State is designed to focus on specific violations that pose a risk to an organization and minimize inoperative alerts. The product not only examines a particular violation, but also provides the security team with a context on the object under consideration. For example, if they are found to have a security group that allows public access to port 22, VMware Secure State will provide them with the necessary context to decide whether or not it is a risk by displaying all objects connected to that security group, including instances, the owner and other objects that may be threatened as a result of this breach. This context is what it takes to validate the risk. Without it, this is just another alert in a sea of alerts.