As we wrap up our Introduction to Threat Operations series, let’s recap. We started by discussing why the way threats are handled hasn’t yielded the results the industry needs and how to think differently. Then we delved into what’s really required to keep pace with increasingly sophisticated adversaries: accelerating the human. To wrap up let’s use these concepts in a scenario to make them more tangible.

We’ll tell the story of a high-tech component manufacturer named ComponentCo. Yes, we’ve been working overtime on creative naming. ComponentCo (CCo) makes products that go into the leading smartphone platform, making their intellectual property a huge target of interest to a variety of adversaries with different motives.

• Competitors: Given CCo’s presence inside a platform that sells hundreds of millions of units a year, the competition is keenly trying to close the technology gap. A design win is worth hundreds of millions in revenue, so it’s not above these companies to gain parity any way they can.
• Stock manipulators: Confidential information about new products and imminent design wins is gold to unscrupulous traders. But that’s not the only interesting information. If they can see manufacturing plans or unit projections, they will gain insight into device sales, opening up another avenue to profit from non-public information.
• Nation-states: Many people claim nation-states hack to aid their own companies. That is likely true, but just as attractive is the opportunity to backdoor hundreds of millions of devices by manipulating their underlying components.

ComponentCo already invests heavily in security. They monitor critical network segments. They capture packets in the DMZ and data center. They have a solid incident response process. Given the money at stake, they have pretty much every new, shiny object that promises to detect advanced attackers. But they are not naive. They are very clear about how vulnerable they are, mostly due to the sophistication of the various adversaries they face.

As with many organizations, fielding a talented team to execute on their security program is challenging. There is a high-level CISO, as well as enough funding to maintain a team of dozens of security practitioners. But it’s not enough. So CCo is building a farm team. They recruit experienced professionals, but also high-potential system administrators from other parts of the business who they train in security. Bringing on less experienced folks has had mixed results – some of them have been able to figure it out, but others haven’t… as they expected when they started the farm team. They want to provide a more consistent training and job experience for these junior folks.

Given that backdrop, what should ComponentCo do? They understand the need to think differently about attacks, and how important it is to move past a tactical view of threats to see the threat operation more broadly. They understand this way of looking at threats will help existing staff reach their potential, and more effectively protect information. This is what that looks like.

Harness Threat Intel

The first step in moving to a threat operations mindset is to make better use of threat intelligence, which starts with understanding adversaries. As described above, CCo contends with a variety of adversaries – including competitors, financially motivated hackers, and nation-states. That’s a wide array of threats, so CCo decided to purchase a number of threat feeds, each specializing in a different aspect of adversary activities.

To leverage external threat data they aggregate it all into a platform built to reduce, normalize, and provide context. They looked at pumping the data directly into their SIEM, but at this time the flood of external data would have overwhelmed the existing SIEM. So they need yet another product to handle external threat data.

They use their TI platform to alert based on knowledge of adversaries and likely attacks. But these alerts are not smoking guns – each is only the first step in a threat validation process which sends the alert back to the SIEM looking for supporting evidence of an actual attack. Given their confidence in this threat data, alerts from these sources have higher priority because they match known real-world attacks.

Given what is at stake for CCo, they don’t want to miss anything. So they also integrate TI into some of their active controls – notably egress filters, IPS, and endpoint protection. This way they can quarantine devices communicating with known malicious sites or otherwise indicating a compromise before data is lost.

Enrich Alerts

We mentioned how an alert coming from the TI platform can be pushed to the SIEM for further investigation. But that’s only part of the story. The connection between SIEM and TI platform should be bidirectional, so when the SIEM fires an alert, information is pulled from the TI platform which corresponds to the adversary and attack.

In case of an attack on CCo, an alert involving network reconnaissance, brute force password attacks, and finally privilege escalation would clearly indicate an active threat actor. So it would be helpful for the analyst performing initial validation to have access to all the IP addresses the potentially compromised device communicated with over the past week. These addresses may point to a specific bot network, and can provide a good clue to the most likely adversary. Of course it could be a false flag, but it still provides the analyst a head start when digging into the alert.

Additional information useful to an analyst includes known indicators used by this adversary. This information helps to understand how an actor typically operates, and their likely next step. You can also save manual work by including network telemetry to/from the device for clues to whether the adversary has moved deeper into the network. Using destination network addresses you can also have a vulnerability scanner assess other targets to give the analyst what they need to quickly determine if any other devices have been compromised.

Finally, given the indicators seen on the first detected device, internal security data could be mined to look for other instances of that attack regardless of whether network traffic shows the device acting strangely. Then the analyst can tell whether the attacker has been successful using the same tactic to establish other footholds in the environment. This is critical when it’s time to eradicate an adversary.

This is pretty simple stuff which any semi-experienced analyst does as he/she validates an attack and assesses potential damage. The difference is all this data can be pulled automatically before an alert reaches the analyst. By the time an analyst starts to dig in, they shouldn’t have to start with a bunch of manual digging to get everything they need to investigate. They start validation in a good position to quickly understand what happened and assess the blast radius of the compromise.

Building Trustable Automation

Automation within threat operations can mean a lot of things. Assembling all the supporting information an analyst needs for threat validation prior to starting the process is clearly automation. But let’s move a little deeper into specific actions which can occur automatically. As described above, ComponentCo has a pretty mature response capability and typically removes all potentially compromised device from the network at the beginning of response to limit possible damage.

But this impacts response in multiple ways. First, it may tip off the adversary, prompting them to burrow deeper and find other points of entry. Additionally, CCo loses their opportunity to monitor adversary activity to figure out what they were trying to do and how.

Automation can help. CCo can automatically move a suspicious device onto a VLAN where all network traffic is captured, which won’t tip off the adversary to their discovery. They also start to pull EDR telemetry off the device at least every 30 minutes, to ensure data is captured even if the adversary is tampering with endpoint’s logs. This provides opportunity to see what adversaries are up to, and perhaps to establish preemptive workarounds in anticipation of the attacker’s next move.

Another step CCo may add to their response playbook is to automatically update a network blacklist with any unknown external networks a compromised device has been communicating with, under the assumption they are likely botnets, and block traffic to them. They can search their network and device security data for other devices connecting to those networks, which can help identify additional compromised devices.

Workflow and Process Automation

Underlying all these functions is an automate first mentality, where the team builds playbooks which specify actions to take in response to typical threats. This is valuable for several reasons, including consistent response and minimization of human error. But scaling the security team is the most important. CCo is a very desirable place to work, and doesn’t generally have an issue finding talented folks, but skilled security staff are still in high demand. By combining a threat operations mindset with a heavy dose of automation, CCo can make less sophisticated (and cheaper) analysts more productive.

Of course they still use Tier 3 analysts to handle tough and complicated incidents. But for others their playbooks can guide Tier 1 & 2 analysts. Let’s use an example of a response playbook for a phishing issue leads off a targeted attack.

In our scenario a junior staffer in Finance received a phishing email claiming to come from his bank, and requiring immediate attention. The employee fell for the ruse and clicked the link, which compromised his device. The compromised device began internal reconnaissance and connected to a known botnet. At that point an alert triggered and the automated playbook kicked in, putting the device in a fully logged VLAN and increasing the monitoring level, then updating egress filters and the IPS configuration to watch for indicators corresponding to the initial attack. A full image of the device was taken prior to clean-up, and then it was restored and resumed normal operations quickly, without any real data loss or extensive manual effort.

But given the sophistication of its adversaries, CCo doesn’t assume any phishing attack is just everyday phishing. So they install the image of the compromised device in a sandbox to see what it does. This secondary analysis shows the phishing attack was a diversion. A secondary malware kit activated the next day, which had all of the earmarks of far more sophisticated nation-state malware.

So this gets immediately escalated to Tier 3.

Handling a Targeted Threat

Escalation of what appears to be a nation-state level attack triggers yet another playbook, which triggers the threat intel and alert enrichment functions discussed previously. By the time the case reaches a Tier 3 responder, they will quickly understand the adversary, their tactics, and where else similar attacks have been seen – inside or outside CCo.

At this point the response team knows they are under real attack bt a sophisticated adversary, and automatically starts capturing egress traffic and locking down their most critical assets as a precaution. Because related information has already been collected and associated with this case, the Tier 3 analyst can very quickly figure out the adversary’s TTPs and choose an appropriate response.

Obviously there is a lot more effort and detail to actually eradicate a nation-state from CCo’s systems, but they have a response process and playbook for that. The point to highlight here is that what looked like simple phishing, handled in a largely automated fashion, uncovered a sophisticated nation-state campaign. At that point the threat operations mindset enables CCo to seamlessly escalate and provides a Tier 3 analyst with all available information to streamline attack and adversary research, and accelerate both damage assessment and eventual eradication of the adversary.

So what is required for this threat operations mindset?

1. Define processes and playbooks: Consistent activity requires initial work to figure out appropriate responses for a number of different scenarios. The evolution always starts by defining how you want the team to behave, and then working to implement consistent processes.
2. Implement an external threat data aggregation platform: External threat data is key to understanding what adversary you are facing and what they are likely to do. Numerous feeds are available, but to avoid overload and ensure can effectively utilize the data, you’ll want to aggregate and process it for better context.
3. Integrate external and internal security data with analytics: Once aggregated, the external data needs to be analyzed alongside internal security data to pinpoint potential issues and identify patterns of malicious behavior based on what’s happening in the wild. At this point you get much more relevant alerts, enriched with supporting information about probable adversaries and indications of whether an attack has spread within your environment.
4. Orchestrate existing monitors and controls: The key to operationalizing a playbook is to have all the systems work together. So your TI aggregation platform (if a separate technology) needs a bi-directional connection to and from your SIEM. It can also send data to IPS devices and egress filters to block known bad sites. It can check with an advanced endpoint tool to confirm that what is reported from the network actually happened on the endpoint, and vice-versa.
5. Automate first: Finally, given all this analysis and integration, trusted automation can block traffic to known bad sites and move compromised devices into quarantine networks or capture telemetry on detection of suspicious activity. Basically, if something can be documented in a playbook, you should be able to automate much of the process.

The end result is an orchestrated and automated ability to handle threats, equipping human analysts to do what they do best: pull on threads and make connections between isolated attacks which may represent sophisticated campaigns. Machines don’t do this well or automatically. If it can be enumerated in a playbook, it likely should be automated. If not it remains the purview of humans on the security team, and you can make them more productive by automatically aggregating the data they need to understand and address each situation.

With that we wrap up our Threat Operations series. We’re always interested in feedback on our research, especially our scenarios. Just drop us an email, tweet, or comment on this post – we’re happy to discuss.