Contextual Data: Answering Who, What, Where, When?

What if one day you came home and a bunch of your valuables had been stolen: computers, jewelry, that big screen TV… When you call the police to report the burglary, the first thing they will ask for to begin the investigation is context:

What time did it happen?

Was there a break-in? If not, who had keys to your house?

Where were your valuables being stored?

The more information they have, the better the chances they they will track down the culprit and get your stuff back. Now, if you have a home surveillance system set up—say, a Dropcam or Canary —they’re going to have even more information to work with: timestamps, video footage, audio, etc.

All in all – the more context you have, the better. The same applies to cloud security. When something goes awry, context is what guides you about what to do, where to start investigate, who’s at fault?

What Cloud Context Really Means

Context is particularly valuable in the world of cloud security because it helps you get to the root cause and the possible impacts of security events.

Many security teams, even today, are forced to manually sort through their logs in an attempt to gather enough context to take some form of action. But with a modern, comprehensive security tool, manual effort becomes unnecessary. These types of tools can derive context about a cloud security event, showing you exactly what happened and saving you lots of time and resources. (And let’s get real: none of us wants to spend our Friday night digging through logs…)

But, you need to know what kind of context is useful in a cloud security incident. In short, there are three key components:

  • Who: Which user, process or network connection triggered the alert?
  • 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?

With the above context at your fingertips, you’ll be able to take action on any security alert that comes through far more efficiently and effectively.

The Difference Between Global and Local Context (and Why You Need Both)

Going a step further, context can also be divided into global vs. local data, and it’s valuable to have both.

  • Local Context

Local context tells you what was happening in the exact part of your environment where the alert went off.

  • Global Context

Global context, on the other hand, takes a step back to look at what else was going on in your environment at the time of the alert (and even before it). This provides you with a more complete picture.

With global context, you may be able to see signs of lateral movement across your environment (i.e. , proof that the threat is spreading). Global context can also uncover potential entry points of the threat. Pair that with local context that can tell you exactly where the lateral movement ended up in your environment, and you’ll have a complete picture of the threat. That’s why you need both global and local context — with both you’ll be able to trace where the threat came from so you can quickly jump to remediation.

How Does Threat Stack Do Context?

The new Threat Stack Cloud Security Platform™ was built with the necessity of cloud context in mind — do you always know “who, what, where and when” of any security alert that you receive. (Specifically, we show this via the Process Details and Cloud Context dashboards.)

Every alert that Threat Stack generates focuses on a Contributing Event. That means with Threat Stack you can see exactly what triggered the alert. And because we gather information straight from the host, we’re able to pair each Contributing Event with the “who, what, where and when” we described above.

To complete the story, Threat Stack also provides you with the necessary local and global contexts we described above through our Process Details and Cloud Context features. These two features operate at different levels, giving you different types of information. Process Details delivers your local context: It shows you what happened around a given process, host or session. Cloud Context, on the other hand, is your global context: It lets you take a step back and look at what happened around the same time across all cloud functions. That’s global and local context in action.

The following is a screenshot of an alert as it is displayed in the Threat Stack Cloud Security Platform™:

Cloud_Context_Screen_Shot_1_copy.png

1. Highlighted alert    2. Contributing Event    3. Process Details – Use for finding out what happened on that particular host in that particular session.    4. Cloud Context – Use to find out what else happened across your cloud environment – identify all hosts, infrastructure used around that specific time for a given user or IP.


As you can see, you’re able to quickly view not just the Contributing Event (bottom left) but the full context around it, both Process Details and Cloud Context (bottom right).

How Threat Stack Organizes Context

Wondering exactly where to get the type of context you need in Threat Stack? Here’s a quick rundown:

Who

For each alert, we will pull the user and IP address to show you the “who.” In the below screenshot, you can see this indicated with blue arrows. To give you even more information, along with displaying which user triggered a given alert, we also show you what other actions that user has executed across all of your hosts and infrastructure, in 10 minute increments – both before and after the alert. The same applies to IP: you can look at all of the other actions (connects and accepts) to and from that IP across your hosts and CloudTrail.

Below, you can see what this looks like when you click “Cloud Context”:

Cloud_Context_2_copy.png

When
Next, you can look at security events based on when they happened. We organize events by time and display context in the hours following and preceding the event. In the above screenshot, you can see how this appears indicated with greens arrows.


Where:
Finally, you can dive into the “where” of an alert by looking at which server it took place on or the host where it occurred indicated in the above screenshot with an orange arrow.

Alright, now that you have a sense of the basics of how context in the cloud can be derived using Threat Stack, want to see it in action?

Deriving Cloud Context: Examples


Example 1: Exploitation of an Application
[External Threat]
To show you how Threat Stack would handle this type of threat, we installed a vulnerable Jenkins application. Once it was in there, we got an alert via the platform saying that user=jenkins downloaded a suspicious application from our Jenkins application server. Here’s what the alert looked like:

Cloud_Context_3_copy.png


To further investigate, we wanted to find out what else User Jenkins did around that time.

Cloud_Context_4.png

When we clicked on Cloud Context, we noticed that User Jenkins modified a file as well.

Cloud_Context_5_copy.png

Deeper investigation revealed that User Jenkins downloaded a file from an IP address, so naturally we wanted to know what else happened with that IP around this time. Clicking on the IP, we discovered that there was a Secure Shell (SSH) attempt from that IP, meaning that they were trying to control a server remotely. Uh oh.

Cloud_Context_6.png

This is a great example of how you can derive meaningful and actionable context. WIth a few clicks, we are able to quickly go from discovering a suspicious user (Jenkins) to uncovering an SSH attempt (and foiling it in the process.)

Example 2: Insider Threats


As you know, not all threats come from outside the organization. In this example, we received an alert saying DNS had been changed by a user. To understand what that meant for our environment, we needed to know what else that user had done.

With Cloud Context, we are able to quickly see that the user had issued suspicious commands (accesses and removed a file) on a host:

Cloud_Context_10_copy.png

Next we took a deeper look at the “who”: looking at the IP, we were able to see that the same IP from which the suspicious commands were originating, had also been involved in other suspicious CloudTrail API calls . This not only told us that the malicious actor used the same IP for multiple steps in the kill chain but also helped us to confidently take remediation steps against the IP

Cloud_Context_11_copy.png

Bringing it All Together

While an initial alert is of course vital, you really need more context to investigate the root cause of cloud security incidents and put a stop to them effectively. With the Threat Stack Cloud Security Platform™, you no longer need to go digging for this context manually. With a few clicks, you can figure out the who, what, when and where and get to the bottom of a threat and mitigate it before it becomes a big problem.

Check it out for yourself and see how quickly you can derive cloud context from incidents in your own cloud environment.