Blog

I Think We’ve Seen This Before… …Why “Incident Intelligence” is Imperative

I Think We’ve Seen This Before… …Why “Incident Intelligence” is Imperative

Posted April 14, 2014

I Think We’ve Seen This Before… …Why “Incident Intelligence” is Imperative

– by Steven Weinstein

Lately, customers have been asking me how threat intelligence can enrich their incident response processes and how the right intelligence can make them more effective. As a former full time lead incident responder for a massive organization and now a researcher for LookingGlass, I thought I could draw from my previous experience and combine it with our threat intelligence management platform’s capabilities to answer that question. Just as a quick note, having been on the customer side of the table, I’ve sat through what seemed like hundreds of vendor demos, and since I hate having marketing shoved in my face as much as you do, I’ll try to limit that bit while answering their question. If our platform seems useful to anyone who isn’t a customer, that’s great. After all, I do have this platform at my disposal, and, well, they pay me.

Anyway, I can confidently say that when you’re dealing with literally hundreds of malware incidents per day, the minute differences in identified indicators can all start to blur together. Being able to very quickly and efficiently answer the question of whether or not a particular indicator of compromise has been seen before (and in what context) is crucial. Let’s see if I can coin a new phrase here: let’s call this “incident intelligence”. Incident responders always need to have a clear picture of what they are dealing with and how it may relate to something already encountered during previous incidents, but unfortunately for most teams, this is easier said than done.

An equally inhibiting issue is the fact that incident responders or security operations analysts typically require up to ten different web pages or portals open at any given time in order to fully understand the elements of the current incident. The number of details involved in a single security incident is staggering, and when responders need to gather those details from numerous sources, it only adds to the confusion of trying to remember if a single indicator has been seen in a previous incident or not.

The solution to this (lack of) incident intelligence problem is surprisingly simple: have proper processes in place! While many organizations implement complex incident handling and tracking processes, they may not be addressing the issue in the most effective way. Processes for ongoing incidents must be updated to include searching back through previous incidents to determine if there is any overlap. Hopefully organizations have a powerful search ability built into their incident tracking systems (assuming an organization even has a tracking system), which they can leverage in these situations. That’s something we’ll touch on briefly later. Spoiler alert, it will be part of the little bit of marketing for the LookingGlass ScoutVision platform in this blog post – I promise I’ll keep it more interesting than pretty much any marketing section in other companies’ blog posts, though.

Anyway, back to why it’s so important to have your processes updated to include this historical search capability. It’s absolutely imperative to be able to know what you’ve seen before. If you rely solely on that instinct of “I think we’ve seen this before,” you WILL make mistakes, you will miss crucial details, and you won’t be as effective as you need to be. Trust me, I’ve been there before.

Having this visibility into the incident intelligence of whether or not a specific indicator of compromise (including registry keys, IP addresses, domains, etc) has been seen before really makes an impact. Those Dynamic DNS FQDNs all look the same after dealing with the onslaught of the Blackhole and Neutrino exploit kits’ prolific usage of DynDNS domains, right? Being able to determine overlaps in incidents can help show how specific threats relate to each other – maybe how a specific exploit kit tends to continuously drop the same type of malware, or how Cryptolocker is typically spread via ZeuS Gameover (which often comes from malspam). You could also find overlaps and uncover extended undetected access after you thought a previous incident had been remediated – dare I say “persistent”?

Probably one of the best benefits of having incident intelligence? It substantially reduces the security operations team’s reliance on your subject matter experts (dedicated malware teams, incident response teams, CERTs, etc). The ability for a SOC analyst to be able to say “yes, we’ve seen this before in incident #99999, it was related to this threat, and this is how we handled it” is incredibly powerful and saves precious time and resources all around.

But what if simply modifying your processes isn’t efficient enough? What if you don’t have an incident tracking solution already in place? The ideal solution to this problem from an efficiency standpoint would be a platform that allows incident tracking and threat intelligence analysis to be performed in the same view, to allow for optimal discovery of incident intelligence.

Enter LookingGlass’ ScoutVision platform. At a very high level, we’re aggregating dozens and dozens of open and closed (some our own) source threat intelligence feeds to provide as much threat context around a network entity (domain, IP, CIDR, AS, etc) as we possibly can, in order to provide security analysts and incident responders with the intelligence required to take informed action. Basically, we create “tags” on each network entity specific to the observed associated threat.

Couple that with the ability to create your own tags (of other threat types, or anything for tracking purposes, really), and you have the ability to create your own incident intelligence. By using ScoutVision as an incident tracking platform, you can create a tag for each new security incident, and fill in some details…

Once you have the incident set up, the SOC or incident responders can immediately start “tagging” domains or IP addresses related to the incident (with the tag name of the incident ticket number, or however you decide to track it) to easily define the scope of the incident. This is incredibly helpful for the containment efforts. At any point, check out the domains and IP addresses (in the picture below) that have been tagged with this incident number to understand the scope…

We can immediately pivot to any of the domains or IP addresses to see what additional intelligence LookingGlass can provide on the network entities involved with the incident. Seeing all of these different tags (sources redacted) helps incident responders or SOC analysts validate their findings or help provide further context. What you can’t see in this screenshot is the passive DNS history and geo-location of this IP address also listed on this page – but this also helps provide context for an incident.

When a new incident occurs which has overlap from a previous incident, as we can see in the image below, I can immediately see that this domain has already been tagged with the previous incident ticket number. At that point, as either a SOC analyst or an incident responder, I can immediately reference the previous incident details to see what the details were and what the outcome was – all of this information is extremely important in determining the incident response action items.

Had I not known that this was related to a previous incident, I wouldn’t have been able to quickly determine that this was the same internal host that had been impacted, resulting in a different set of action items. Because I was so easily able to see this was a recurring incident (same threat, same machine), it completely changed my decision making process to request the machine be taken off the network immediately in order to be rebuilt instead of trying to remediate it.