Cloud Security Wrangling: Managing the Wild West Cloud

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.

Risk alerts

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 always overwhelm an organization if the number of rules are neither configurable nor deletable. For example, one of our customers has millions of objects in AWS but has a very open deployment model, where end-users have wide latitude to deploy objects as they see fit. The security team did not want to be alerted to each violation for two main reasons. First, they had a small security team and did not want to flood their security operations team with a ton of alerts. Second, they were comfortable with configuration errors that did not pose a serious safety risk.

They knew that they would not be able to implement a restrictive security policy without a huge reaction from IT and development. Instead, they took advantage of VMware Secure State to focus on eight high-risk vulnerabilities. The idea was to first attack the most critical vulnerabilities, instead of being overwhelmed by low-priority alerts (ultimately leading to a culture of inaction). As the customer took control of these eight risky violations, he activated a few additional rules. Gradually, they were able to activate more rules and educate end-users so that they could manage their risks while continuing to collaborate with IT and development.

That is the balance that is needed. The ability to control safety rules based on risk and governance allows the organization to deploy security controls without flooding people with noise. It also provides a level of trust between security teams and end-users, as alerts that are triggered are valid and pose a risk. In addition, the owner of the service receives an actionable alert. They include the alert, the context and the actions to be taken to solve the problem

Beyond Violations: Finding Inter-Service Risks

One of the unique features of VMware Secure State is the ability to find a connected breach chain. Violation chains are risks that would only be detected if the associated context was available. Risk is detected by examining a group of related services and correlating conditions that create a high risk in your safety posture. VMware Secure State examines an organization’s entire cloud presence. This allows Secure State to detect an increased risk due to the risk posture of adjacent objects. For example, one of the threats Sought by VMware Secure State is the presence of a pair of keys with administrative privileges deployed on a workload that can connect to an Internet gateway. The use of a pair of keys with a director’s privileges in itself is not necessarily a high risk. The risk is that one of the other workloads sharing the same network will be compromised. This would open the client to a side-movement attack with a possible result from an opponent having access to the administrator-level keys.

Leave a Reply

Your email address will not be published. Required fields are marked *