Dr. Watson is the intellectual and gentlemanly sidekick of fictional detective Sherlock Holmes. With Watson at his side, Sherlock is able to better navigate the complexities of human emotion (not his forte), so Sherlock leans on Watson, and understandably so. They make a good pair.
But while Watson is able to solve the odd mystery himself, only the highly observant Sherlock, with his machine-like analytical mind, is able to produce the insight needed to crack their toughest cases.
You can think of cloud security in the same way. A basic cloud security system will probably alert you to many of the biggest, most obvious attacks. But without sufficient context, you won’t be able to see the full scope of impact. You won’t know where it has spread in your system or what kind of damage it has done. Even if you manage to stop it in one area, you may not succeed in defeating it, and the ramifications can be distressing.
Cloud context gives you the clarity of a Sherlock Holmes.
Context Matters in the Cloud—Even More than Outside of It
There’s a persistent myth that migrating to the cloud makes your systems more vulnerable. Put simply, this isn’t true. In fact, the director of security for Google Apps explained in a ComputerWeekly editorial that data is often safer in the cloud than on an endpoint machine. Why? It comes down to two factors:
- It travels less (there’s no need for email, jump drives or a desktop download if you’re doing it right)
- Patches happen faster
The latter is true because cloud computing ensures a more homogeneous environment, which means it’s faster and easier to construct and deploy patches when security vulnerabilities come to light. It can take significantly longer to do this with traditional computing environments, which are often cobbled together and lack uniformity.
So the cloud isn’t less secure (assuming you’re employing best practices). But context has even more value in the world of cloud computing, because the potential attack surface is indeed larger, with threats coming from a number of sources.
Context is invaluable in the cloud because, when something goes wrong, it will help you sort out the root cause and measure the potential impact of security events.
The Types of Context Required
Investigating a cloud security incident isn’t totally dissimilar to investigating a crime: you need to know the who, what, when and where to get to the bottom of it. In the case of cloud security, here’s what that means (as we explained in this blog post):
- Who: Which user, process or network connection triggered the alert?
- What: What type of attack was it?
- When: What’s the timestamp on the alert? What’s the timeline of the processes that led up to the alert being triggered?
- Where: What part of your environment (e.g. which server, EC2 tag or AWS service) caused the alert to fire?
When you have this context in hand, you can avoid a lot of hand-wringing and manual investigation of logs. You can do what it takes to mitigate risk and get back to the business at hand.
Begin with the End in Mind
Now, we don’t want this post to make you think that you can just slap a little context onto your cloud security processes and go on your merry way. You need to start at the strategy level and work your way down to tactics if you want to have an effective and complete security posture.
In other words, you can’t start with a Watson and add a Sherlock later when you realize you need it. They’re a package deal, and the insight that a Sherlock brings to the table is nonnegotiable in the world of the cloud. Context isn’t a “nice to have” for your cloud security strategy. It’s table stakes.
Get the Context You Need with Threat Stack
Give Threat Stack a try for free and see how quickly you can derive cloud context from incidents in your own cloud environment. You’ll feel like a regular detective in no time.