SOC.OS automates security alert triage, allowing users to focus their resources on investigation and remediation. The SOC.OS Demo video explains how our centralised security alert monitoring solution works, using an anonymised incident seen by one of our users.
Watch the demo to find out:
- How SOC.OS maps security alerts to the MITRE ATT&CK® Framework
- How SOC.OS automates the parsing, enrichment and correlation of security alerts from across your security stack
- How your business context and third-party threat intelligence informs the SOC.OS severity scoring algorithm
Let’s dive in and show you a quick product demo- what’s actually happening under the hood here in SOC.OS world. So the first screen here, this represents the challenge that analysts face day to day, which is here’s a screen full of threat logs. This is what we’ve got here as an example, we’ve got 10,000 threat logs. This is an actual example taken from one of our customers, and anonymised.
Here you’ve got Fortigate, these are IPS alerts – so if you’re an analyst, this shouldn’t be uncommon to you. But the challenge is not just how to triage these alerts on this screen, it’s how do these alerts relate through time? How do these alerts relate across my security stack.
So I’ve got 10,000 IPS alerts related to my endpoint security tool alerts. It’s a daunting challenge for analysts to take this information, to triage this effectively and also to consolidate and correlate and spot patterns through time, really hard for a human to do. And so hence why these guys turned to SOC.OS for help. And so let’s talk to you about how SOC.OS would deal with this challenge.
So as these 10,000 alerts are coming in, basically in real time, SOC.OS is constantly parsing the alerts as they come in and enriching them and it’s also grouping them through time as and when they’re coming in and then it’s prioritizing them for the analysts.
So let’s go through that process.
So let’s say 10th of November, 2020, these 10,000 alerts have come in. SOC.OS has found 20 that it thinks are related to the same unique cyber case. And so these 20 here, SOC.OS has said “they’re related” and how it’s doing that (the thesis behind the tool) is all of these alerts are mapped to the MITRE ATT&CK® Framework.
And so all of these share the same threat types. So this is a technique exploitation for client execution and they’re all coming from the same external IP address. Very important that you’re not just correlating just on threats. So we’re going threats, we’re tracking entities and we’re saying they’re related. You should be looking at these alerts in the same breath.
So these 20 alerts started 5.48 in the morning until 6.38 in the morning. So you log on for your morning coffee and SOC.OS has already done this “grunt work” for you and said, “Hey, analysts, I found 20 alerts that are related”. It does that job. So that’s a big time-saver as it is, but then it goes one step further and now adds more context to it.
Once it’s grouped based on threat type and external entities, in this case, it’s an example of external enrichment, it then enriches it. You’ve also told me, “I really care about these types of alerts, Joomla core session, remote code execution, that’s an alert I should be worried about” So you’ve labeled them as critical alerts and SOC.OS tags that, but also looks at the metadata within each one of these alerts.
Here it realizes that the firewall has done its job. It’s blocked it. So it adds the tag of yes, it’s been blocked. That’s important because the critical alert would have affected the scoring and prioritisation for you but then the blocked metadata would have reduced the score instead.
So 20 alerts, that we just showed you. ECE (exploitation for client execution). There’s one internal entity here, and it’s all come from one source system, one security tool, you click on it and you’ve got a nice visualisation.
That is a visualization representation of the table which I’ve just shown you. So you have a look and you see exploitation for client execution is here. The external entity we put up at the top here, the internal entity we put here, the business critical context here. So FortiGate critical alert. You know, that these 20 alerts are from FortiGate, happened all in week one.
So timeline of when they’ve appeared and you know that all 20 are FortiGate, and some of them are critical, and they’re all this type of threat. You can dive in a little bit further and click on the external entity and see what’s actually happening here and you get threat intelligence built into the tool. So happening automatically you have AbuseIPDB score of 100 and you get AlienVault OTX feeds as well.
Firewall is doing its job, you can archive it. You can say, “I’m happy with this, thanks Firewall” and move on to the next set of clusters that I want to investigate. So that’s time-saving on its own. But here it really comes to life. This concept of stateful correlation which is really the USP of the tool.
Let’s fast forward the clock to the 7th of December. And here you have another 10,000 alerts and basically rinse and repeat everything I’ve said up until this time. SOC.OS is parsing, analyzing, correlating through time, enriching and prioritising. But what it’s doing now is really crucial. It finds 21 alerts on the 7th of December, that it groups, and it says, “Oh, I’ve seen all these 21, all the same threat type”.
It’s all the same external, but it not only groups the 21 from the 7th of December, it says, “Hey, I’ve seen that before, that looks familiar to the cluster four weeks ago, the alerts that we’ve already correlated together. And so it actually correlates this group of 21 and combines it with the last 20 that we saw previously.
It adds a business context. Again, this time it gets more interesting because now you’ve got different IP addresses from the first 20: sensitive web servers. You have the critical alerts, and this time your firewall saying, I haven’t blocked it. So we’ve detected this traffic. I’ve let it through, I haven’t stopped it, which is crucial. And that’s very important for our scoring algorithm, because that will boost this entire cluster much higher to the top of your cluster list.
And here you click on the tool, you get in, and you see four weeks later, December 7th and you now have 41 clustered alerts. Now in this one cluster, 21 alerts have been unactioned. The red arrow means not blocked. You click on it and you get this picture.
We have seen just now week one, three weeks of nothing. Now in week five, you have 21 new alerts that SOC.OS is saying, you should be considering these 41 together. You can click on these 21 alerts. You get all the original alert data. You can go to the data view to really dive into the threat logs themselves if you want a bit more of a granular threat log view.
I’ll pause here and I’ll say, imagine you’re the analyst. And on week five, you’ve picked up one alert. So you’ve looked at the Drupal core, one alert. You’ve triaged that alert. And in that metadata contains this external IP and this internal IP address, you would react according to that keyhole view of the world.
Whereas now with SOC.OS, analysts are able to ask really interesting questions. They go, “Okay, week one, that was all blocked”. “I’ve got the notes in my activity timeline. It tells me that my team member archived this, the firewall is doing its job, but then there’s nothing happening in these three weeks” And then in week five, we’ve got another 21. This is hitting the critical web servers you see here.
So now your responses will be, “I’m going to definitely check the logs on these three machines. I’m definitely going to make sure this IP address is block listed on the perimeter”. I’m also going to ask questions, okay. “What happened in these three weeks? So there’s a genuine chance that nothing’s happened or did our tools miss it?”. I’m going to go look at the logs and go do some searching. So your investigation becomes a lot more effective and well-rounded because of this time-based view of the world.
Hope you have enjoyed the video. Any questions, please feel free to ask!