Uncovering the Value of Intelligence-Driven Security Operations
January 14, 2019 • Justin Grosfelt
Editor’s Note: The following blog post is a summary of a presentation from RFUN 2018 featuring Justin Grosfelt, senior solutions architect at Recorded Future.
Having worked in a security operations center (SOC) myself, I know what you may be thinking when you read the phrase “intelligence-driven security operations” — another cybersecurity buzz-phrase thrown around by marketing teams and CISOs that will just add another layer of complication to your work for no reason.
When I used to consult with organizations to help build out their security operations as recently as three years ago, this may have largely been the case. Intelligence-driven security was an unattainable dream for anyone smaller than a major financial institution or government agency — something security operations teams worked toward because they thought everyone else was doing it, but one that mostly resulted in simple response procedures that told them to block bad IP addresses and not much else. Is that intelligence driven? No.
Things have changed, however. Thanks to rapid advances in fields like machine learning, cyber intelligence collection and analysis is no longer the bottleneck it was before. Although the majority of the problems that SOCs faced before — allocating resources and managing assets, providing context to indicators of compromise, developing effective and automated playbooks for different scenarios — still very much exist today (and in some ways have become more difficult to manage as the number of alerts has risen), threat intelligence capabilities have also matured significantly. The goal now is to understand how to make sure that SOCs of all sizes can actually take advantage of that threat intelligence.
To explore what intelligence-driven security operations can actually look like when it’s powered by threat intelligence that is timely and provides actionable context, we’ll look at a case study using the Recorded FutureⓇ Platform to pursue an indicator across three stages: detection, incident management, and analysis.
Not the easiest visual, but let me explain. Let’s start with detection.
Incorporating data from the broadest possible range of sources, Recorded Future integrates with major SIEMs and provides context to build correlation rules and determine whether activity is suspicious by using risk scores, risk rules, and supporting evidence.
For example, if you wanted to detect possible data exfiltration or a reverse shell, you could match our risk rule “Recent C&C Server” with netflow or proxy logs to identify large data transfers.
Let’s look at a specific example: Say we get the alert below in Splunk. Even without context, there are immediately a few suspicious details, like the command line and the fact that it appears to be running on a public server. Further, the risk score is 67, and the risk rule indicates it has a positive malware verdict. We now have good justification that this indicator represents suspicious activity.
Now that a possible threat has been detected, the next step is to determine how much of a risk it represents — how bad is it? That question can’t necessarily be answered with the data we have so far. Our next step is to perform triage. At a basic level, during triage, an analyst is trying to answer the following questions:
- What is the scope of the incident? Who in my organization, or what systems and processes exactly, does it affect?
- How bad is it? How severe of a risk does this threat represent? Are the systems it targets critical? Would their compromise expose confidential data or sensitive controls?
- Do I have a procedure? Are there already playbooks my organization has developed for dealing with this kind of threat?
- Do I need to escalate? Am I capable of handling this directly, or do I need help?
At this point, an analyst will commonly be working out of an incident management system in which the workflow is properly defined. Just as with the SIEM, there is a lot of value in integrating Recorded Future’s data into an incident management system — but the intelligence needed for incident response is different from what is needed to use a SIEM effectively. In this case, we want intelligence that tells us about related entities, such as IPs, domains, hashes, malware types, or whether there is a threat actor associated with the indicator.
Moving forward with our suspicious indicator from before, we have now identified that our malicious hash is related to the NanoCore remote access trojan (RAT). This is a big find as far as triage is concerned, but we are still missing one core piece.
We have a malicious hash, and we know that hash is tied to NanoCore. But where is our command and control infrastructure? Most malware reaches out to an external IP or domain. Either we have an example of one of the rare types that don’t, or we are still missing a piece of the puzzle.
Running our malicious file through some further analysis reveals the results above. Although a risk score of five is low, the risk rules show that it is historically linked to APT activity. This is significant because APT actors commonly use old infrastructure. The low risk score is only an indication that the IP has not been used recently. Some further enrichment leads to the results below.
Now we are starting to close the loop — we’ve tied this incident to APT activity. At this point, a lower-level analyst should have all the needed context to prioritize and initiate the appropriate response for this incident.
Now that we have a confirmed APT intrusion, do we have enough context? Are we worried that we’re missing something? Do we have visibility gaps?
Answering these questions is where incident analysis comes into play.
Don’t laugh, but the next step is to perform enterprise triage of all our endpoints to find anomalies and malicious behavior. Obviously, this is easier said than done, especially if you have over 15,000 endpoints (as many reasonably sized networks do), but it can be done, even with open source tools.
For this incident in particular, our main artifact of interest is AmCache.hve, a Windows artifact whose main purpose is to store metadata about recently executed applications. From a Windows perspective, AmCache.hve plays a part in the application experience and compatibility features of Windows.
From a forensic and incident response perspective, AmCache.hve stores some pretty awesome data about recently executed applications, like the full path, file last modified, create dates, and the SHA1 hash.
Using Recorded Future® Fusion, we can automatically process and enrich all of the hashes found in the AmCache hives, with a result shown below.
So here is the advanced analysis process we created:
- First, we collect all AmCache.hve files.
- Next, we run our script on all of the hives. Our script will parse the hives and enrich each record with items like malware type, malware family, and threat actor.
- Finally, we sort and search through all of the outputs (either through grep or a spreadsheet).
Now, we have identified some other hosts with the NanoCore RAT, which is great. But we also found a PHP file attributed to APT33 and ALFA Team Shell.
At this point, the core aspects of the incident have been identified and the response can be prioritized and undertaken appropriately.
The benefits of taking an intelligence-driven security approach are clear; applying threat intelligence to the systems you’re already using will enable you to gain context on alerts, intelligently prioritize risk, sort out real alerts from false positives, and quickly determine the best course of remedial action. To summarize, here’s what we saw happen when an alert came in:
- Splunk, enriched with our threat intelligence, detected a hash of a malicious file.
- Our incident management system enriched the hash using our threat intelligence to determine that it was linked to a NanoCore RAT.
- The NanoCore RAT was run through a sandbox and the output was enriched with our threat intelligence to find an IP that was tied to APT33.
- We utilized a risk scoring method using our threat intelligence to properly assess the severity of our incident (we could have also used incident orchestration to automate the triage process).
- Forensic analysis was enriched by our threat intelligence to find ALFA Team Shell, used by APT33, that was likely the vector of infection and source for lateral movement.
With the automatic enrichment provided by threat intelligence solutions like the Recorded Future platform, an intelligence-driven approach to security operations is no longer only the exclusive domain of organizations that are large and experienced enough to use it. Indeed, threat intelligence is quickly becoming a necessity as our attack surfaces grow and affect more critical systems and infrastructure.