Whether you are running a server under your desk or have hundreds of servers at data centers around the world, you know that you need to make sure your data and applications are protected from hackers trying to exploit known security vulnerabilities.
The approach to server protection is pretty straightforward:
- Choose a vulnerability scanner and point it at your IP address or range of IP addresses.
- Tell it what you want to scan for and when you want the scans to run and say, “Go!”
- After a period of time, you will receive a report showing all the vulnerabilities found on the servers.
- Depending on the solution you selected, you might also get some information on how to remediate the issues.
For the next several hours, days, or even weeks, you are tracking down patches and making server configuration changes until you have all, or at least the most important, vulnerabilities resolved.
You probably will then make images of your patched servers, mark the images as your new gold builds, and consider the process complete.
This important, albeit tedious process, is a critical piece of your data security protocols; however, when you move to the cloud, this tried and true process falls apart quickly.
Here are three reasons why you need a fresh approach to vulnerability management in the cloud:
The Cloud is Dynamic
Standing up servers in a physical data center takes time. Depending on the complexity of your environment, it can take several days to incorporate a new server into your network. This gives you plenty of lead-time to ensure your new assets are within the scope of your vulnerability management tool–this is not the case in the cloud.
The cloud is dynamic by design and allows you to scale out your environment at an incredible pace. With the advent of continuous deployment processes (also known as DevOps), entire divisions of multinational organizations can have new servers–instances in cloud-speak–with dynamic IP addresses in a matter of hours.
Legacy security tools are not built to handle this level of fluidity. Cybersecurity tools built for the much slower paced physical data center will not keep up with changes that can occur automatically in the cloud.
Context is Everything
Context is defined by Merriam-Webster as the interrelated conditions in which something exists or occurs. The concept of context relates to everything we do. Context helps us understand the importance of one thing over another.
For instance, an email from your manager that reads “Swing by my office when you get a chance.” following a contentious project meeting has a different meaning than when it arrives after a lunch during which you both discussed getting tickets for next week’s baseball game. Without context, you would respond to both emails with equal priority even though one is much more important than the other.
This same principle holds true when we talk about security vulnerabilities. Every instance in your cloud environment will have vulnerabilities at some point. They key is to put these cloud vulnerabilities into the right context. For example, if your vulnerability management tool identifies 100 servers that have the shellshock vulnerability but two of those house your customer database, you are going to want to tackle those first since the potential impact of those assets being compromised is significant.
Now, say there are 10 of the vulnerable instances are not exposed to the Internet. Resolving the vulnerability on those servers automatically becomes less important. If your vulnerability management tool does not apply the lens of context over the vulnerabilities it identifies, then you are going to have a hard time deciding which asset to tackle first.
Your Cloud Configuration Is as Important as Your Server
About a year ago, Code Spaces was making a name for itself in the developer community. Today Code Spaces no longer exists, taken out by a devastating compromise that forced them to shut down. Attackers zeroed in on their poor credential policy and gained control of the company’s Amazon control panel, kidnapping the entire business and demanding ransom for its release.
When Code Spaces didn’t comply, the attackers made good on their threats and systematically deleted all of the companies EC2 instances, backups, S3 buckets, and more. Code Spaces’ story is a cautionary tale not only about the importance of keeping your servers free from vulnerabilities but also ensuring your configurations do not leave you exposed to a potential attack.
The problem is that legacy vulnerability management tools do not understand cloud configurations, so they cannot provide the visibility needed to find the weak spots in cloud configurations. Could Code Spaces have been saved if they had a tool that identified the lack of multi-factor authentication or IAM roles in their environment? Who knows, but it wouldn’t have hurt.
