Modernizing Threat Intelligence with TTPs: Not Your Father’s Threat Intelligence Pt. 1

TL;DR: Think differently about threat intelligence with TTPs.
Traditional approaches to threat intelligence leave security teams reactive, overwhelmed, and unable to quickly and proactively address threats. Operationalizing TTP-based intelligence carries some challenges, but the juice is well worth the squeeze.

Who Built The Pyramids? The Pyramid of Pain, IOCs, and TTPs

David Bianco’s Pyramid of Pain has become an industry-recognized benchmark for security teams to assess the robustness of their threat detection. It’s no secret that the further up the Pyramid you get, the more robust your threat detection strategy is.
Pyramid of pain - TTPs and IOCs
But getting up the Pyramid? That’s not so straightforward. And a lot of security teams get trapped at the bottom because they don’t realize just how much of a difference it makes to reach that peak.
Most organizations are stuck at the bottom of the Pyramid – that means their threat intelligence is primarily relying on IOCs (Indicators of Compromise) and traditional threat intelligence to power both alerting and threat hunting, assuming they do it all. The foundation of their ENTIRE threat detection strategy is reliant upon data that becomes less valuable with each passing minute because it is so easy for actors to change. The resulting IOC whack-a-mole is impossible to operationalize before the damage is done.
On the other hand, mature organizations know that IOCs can only get you so far, and are shaking their heads from atop the Pyramid. Several years ago, IOCs alone may have been enough…but today’s threat landscape is unrecognizable from those days. Today, effective threat management requires focus on the behavioral aspects of an attack – the aspects that aren’t easily changed the second a burnt IOC hits MISP or the Open Threat Exchange – because you can be sure the bad guys are monitoring them too.

So those at the top of the Pyramid? They’re leveraging TTPs (Tactics, Techniques, and Procedures) to both catch threat actors in the act AND predict malicious activity before the alarms go off.

Traditional Threat Intelligence: IOCs and Finished Intelligence

Indicators of Compromise (IOCs)

Indicators of Compromise (IOCs) include:

  • Hash values
  • IP addresses
  • Domain names
  • Network / host artifacts
In the case of a data breach or ongoing attack, IOCs can help teams quickly mobilize or retrace the attacker’s steps. Afterward, with a greater understanding of their vulnerabilities, organizations can leverage their learnings to fill gaps and prevent future attacks of the same nature.
All that to say, they provide specific details into ongoing or past attacks, which is great if you’re trying to understand or recover from an attack that’s already happened. However, when you’re developing a proactive security strategy, known or past threats aren’t going to do you much good. Preventing or learning about unknown attacks requires more sophisticated threat intelligence, and IOCs paint an incomplete picture.

Finished Intelligence

The mountain of mediocre threat intelligence doesn’t end there. On the other end of the spectrum, some organizations have invested somewhat more heavily in threat intelligence via a dedicated team focused on digesting intelligence in the form of both IOCs and finished intelligence.

These organizations tend to have complex attack surfaces, low risk appetites, and threat models that include sophisticated and dangerous adversaries, and they know that an IOC feed – no matter how good – is just one element of an effective intelligence strategy.

Finished intelligence aims to bring together a more complete picture of a threat or class of threats, and good finished intelligence helps teams contextualize reporting to leadership, usually through a profile based on firmographics and environmental factors. A well constructed finished intelligence product will include not just IOCs, but expert-driven analysis that yields deeper insight into the adversary.

Challenges with Traditional Threat Intelligence

For many organizations, so much of their time and budget is consumed by the daily grind of cybersecurity that they have no choice but to take a reactive, “check-the-box” approach. They can’t even begin to think about security as something they could get ahead of, because they’re stuck thinking about compliance, triaging false alarms, and responding to the latest threat of the week.
When that’s the case, though, they’re doomed to get hit with cyber incidents. They’re building their entire strategy around known vulnerabilities and past incidents…meaning they’ll never have enough time to prepare for or prevent an attack, let alone detect and contain one that’s underway – before it becomes an incident.

Challenge #1 – Information Overload: It’s impossible to sift through the noise or contextualize alerts when you don’t know what to look for. Traditional IOC feeds aren’t tailored to the user’s environment or, more importantly, threat landscape. Even with good automation, teams struggle to sift through ALL of the threat intelligence available to them – making it nearly impossible to figure out what’s actually helpful.

 

Challenge #2 – Stale Data: So you’ve got a mountain of threat intelligence in front of you – what next? Depending on your sources, the quality of the data could be the next challenge to overcome. Since adversaries can so easily change infrastructure, indicators like IP addresses and domain names have a very short shelf life.

If you’re alerting based on stale IOCs, not only are you consuming precious cycles reacting to false positives, you’re probably blind to a lurking false negative problem, too. It’s all well and good to blacklist or alert on known-bad IPs or domains, but the strategy proves fragile the moment that attacker moves their command and control infrastructure and the attack sails by your defenses.

 

Challenge #3 – Cha-Ching: Quality finished intelligence is typically reserved for well-funded organizations. Not only is the service costly (if you want to reap any real benefits, that is), but the organization must also invest in intelligence analysts to interpret the information.

For most organizations, this level of expense is untenable; the team they already have is expensive enough and they’ve sunk costs into an extensive toolkit already. They’re not jumping at the chance to tack on a few more zeroes to their security spend.

 

Challenge #4 – Checking a Box: Threat intelligence has been around for a long time, and pretty much every CISO in the world knows they need something. There’s also a common misconception that “threat intelligence=IOC feed”, because that’s the easiest place to begin and there are a wealth of free sources that aren’t going to consume precious budget.

Whether it’s to save time, money, or manpower, many companies get an open or closed source IOC feed plumbed into their firewall or SIEM, and consider that the end of the road. In other cases, the firewall or SIEM vendor includes a basic feed as part of the platform and many think that means they’re covered. Spoiler alert: they’re not.

 

Challenge #5 – Actionability: Rather than looking ahead to unknown threats, IOCs and intelligence feeds tell you what’s already happened to someone else – making them significantly less helpful in building a proactive, preventative security strategy.

Additionally, a common complaint re: finished intelligence is that it lacks actionability for tactical intelligence customers. A detailed report on a nation-state actor might be an interesting read, but unless the intelligence team has interpreted the relevancy of the reporting, the impact and likelihood of exposure, as well as the preventive mitigations and detection strategies, the report will just take up space on the shelf (EXPENSIVE space).

And since many intelligence teams lack the technical skill required to set their detection engineer, SOC analyst, incident response, and threat hunt colleagues up for success, the baton-passing from intelligence to ops is cumbersome, or at the very least not specific enough to incite any action.

Actionability in intelligence reporting demands more than just good reading material. Security teams who need to reliably and proactively defend their organization must understand the adversary’s tradecraft – their TTPs.

IOCs vs. TTPs: What’s the Difference?

Both IOCs and TTPs are critical components of any threat management strategy. But think about it this way: by relying on IOCs from your open and closed source intelligence, you’re hoping to catch the adversary in a mistake. By the time an IOC has been publicly burnt and made available to you in an IOC feed, competent threat actors should have cycled to new infrastructure – it’s part of their opsec practices.

Make no mistake, you should certainly hunt with fresh IOCs after a major zero day is announced – recency is a key indicator of quality in the case of IOCs. Against some campaigns, IOCs have been and will continue to be key to preventing many incidents. But if your intelligence program is over – or solely – reliant on IOCs, you’ll find yourself in a never-ending game of IOC whack-a-mole, because the adversary is no longer where you thought they’d be.

Instead, by understanding an adversary’s behavior – their TTPs – you unlock an ability to see the pattern in that arcade game and can begin to reliably predict which opening the mole is going to pop out of.

What Are TTPs?

IOCs and finished intelligence can be helpful, but on their own, they’re too reactive and vague to justify the cost and manpower needed to make them effective. TTPs are the proactive, actionable weapon your threat intelligence has been missing.
Because TTPs are behavioral indicators, they can help you detect attacks as they unfold, even when an adversary is leveraging unknown infrastructure or tooling. Unraveling the TTP acronym, you get:

Tactics describe the overarching goal a threat actor has when conducting an attack.

Techniques are the methods and tools attackers use to achieve tactics.

Procedures are the precise sequences of actions that threat actors carry out to execute tactics. They’re more detailed and provide security teams with the timeline and workflow of an attack.

The MITRE ATT&CK® Framework has become the industry-standard reference for adversary behaviors, and can be incredibly useful both in better understanding an attack as well as measuring one’s existing coverage and visibility. By helping organizations understand what an adversary seeks to accomplish and how they may do it, MITRE ATT&CK® gives intelligence teams both more insight and an action plan when they hand findings off to operations.

Benefits of TTPs

More sophisticated threat intelligence leads to more sophisticated threat detection. TTPs are proactive, indicative of an attacker’s likely next steps, and challenging (if not impossible) for threat actors to alter.

 

Benefit #1 – Resilient Detection: By keying in on the actions an adversary may take rather than a list of known-bad IPs, your detection strategies become more robust, and are able to survive the inevitable cycle of new malicious IPs, domains, and hashes. You’re much less likely to suffer false negatives.

 

Benefit #2 – Context-Led Prioritization: TTPs help teams identify attackers’ methods and motivations, which means they can get to the core of WHY and HOW an attack may occur. Organizations can proactively allocate resources towards likely exposures and implement defenses rather than recover afterward.

 

Benefit #3 – Proactive, Threat-Informed Defense: Whereas IOCs can only help you identify known threats previously seen in an attack, TTPs go the extra mile and enable you to uncover unknown threats. Teams that hunt using TTPs take a proactive stance and can actively prevent lurking threats from damaging their organization.

Even if the threat actor has already gained access to an environment, a team hunting with TTPs is significantly more likely to have the ability to prevent an adversary from progressing along an attack chain and accomplishing their objective (ransomware deployment is a great example).

 

Benefit #4 – Patterns of Attack: With a broad, comprehensive view of specific adversary behavior, organizations are better able to understand the sequences of events that are likeliest to be leveraged against them. Moving forward, they’ll know exactly where to prioritize detection engineering and threat hunting, and ultimately, how to get ahead and thwart an attack.

 

Benefit #5 – Build Barriers to Threat Actors: When you’re relying on IOCs for your threat detection strategy, threat actors can easily evade detection. But by focusing on TTPs, it’s not so straightforward. Adversaries have skill and experience using their preferred techniques, and having to learn new techniques to evade detection is at minimum a deterrent that may push an adversary to a softer target.

Challenges to Leveraging TTPs

While the benefits to orienting your threat management program around TTPs are evident, there are challenges an organization must overcome as they mature up the Pyramid of Pain.

Challenge #1 – Specificity and Depth of Coverage: While intelligence on a given adversary’s preferred technique is incredibly valuable, that alone may not be specific enough to build and execute an effective detection strategy. MITRE ATT&CK ID T1003 – OS Credential Dumping is a great example of this conundrum.

OS Credential Dumping is a technique with 8 subtechniques, meaning there are at least 8 unique ways an adversary may be able to compromise credentials via this technique. Moreover, within SnapAttack, we’ve captured no less than 187 different variations of this technique. In some cases, detection strategies are robust enough to catch multiple sub-techniques and their variations, but in others, they may not be.

Depth of coverage against any given technique is imperative, especially when granularity on likely sub-techniques and procedures is lacking. A security team needs to know and use the detection strategies that are the most robust – those Goldilocks detections which are flexible enough to detect multiple variations of a technique, but precise enough to minimize false positives. Implementing a flawed detection strategy, even one based on good intelligence, can lead to false negatives – and incidents.

Challenge #2 – Detection Engineering Skills: Building upon the last challenge, once a security team knows the techniques and subtechniques they’re focused on, they need to build the actual detection logic that will be used to identify the adversary’s activity. While this sounds simple, it can be incredibly complex, as it requires a deep understanding of the technique, the data available to the threat detection team in its detection tools (SIEMs, EDRs, XDRs and datalakes), and the query languages each tool in their environment uses.

In many environments, security data exists across several different tools, meaning comprehensive threat detection requires querying all of them – usually with a different query written in the language that tool supports. The duplication of effort involved is significant, and each tool involved amplifies the resource and skillset gaps that organizations are likely to suffer from.
Even in organizations with abundant skilled security engineers, this process takes time – the most precious resource available to operations teams. Reliable detection engineering requires performance testing, tuning, validation, documentation and deployment, meaning in order to truly take advantage of those skills, rigor in the detection development process is critical.

Challenge #3 – Adversary Emulation: In order to build reliable detection logic, you need a deep understanding of the attack and the evidence it leaves behind. The best way to accomplish this is adversary emulation, but adversary emulation requires a blend of skills across infrastructure, offense, and threat detection – not to mention an environment within the organization suited to the activity of safely executing malicious actions. Not every organization has the ability to fulfill these requirements, and without them, they risk running ineffective or poor-performing detection logic, resulting in either high false positives, or worse – false negatives and incidents.

Using TTPs for Better Threat Detection

As detailed above, most challenges with threat intelligence are introduced once the rubber hits the road – meaning, once it’s time to turn intel into action. Even the most specific, actionable TTPs are useless if the team doesn’t know what to do with them. So the question is: How can security teams combat those challenges to TTPs we listed above?
Structured, Streamlined Threat Detection: To overcome a lack of bandwidth or integrated tooling, the security community has taken a page out of the developer handbook by adapting the Software Development Lifecycle (SDLC) to detection development.
By following a structured, repeatable workflow powered by detection-as-code, detection engineering teams can produce robust, relevant detections at scale…and only need to do it once vs. creating the same detection over and over in various query languages.

Specificity and Depth of Coverage: Fighting bad actors on a wide attack surface that’s only growing has led many security teams to think that the more alerting rules they’re running, or the more IOCs they consume, the safer they are. But all that leads to is a false sense of security and a needlessly noisy SOC.

That’s where both breadth and depth of coverage are crucial: when security teams know which TTPs are specifically relevant to their environment, they can more quickly, effectively, and proactively implement the measures / deploy the detections needed to protect against them.

Validation and Adversary Emulation: So how does the detection engineer test, tune, and validate the detection content? Or better yet, how does she know what artifacts to query for? The answer lies with adversary emulation.
By performing the actions the adversary uses to execute an attack, the detection engineer has the opportunity to inspect the evidence the attack leaves behind. In doing so, it becomes possible to build a reliable detection strategy, because the true positive evidence is available to build from.
This also provides the detection engineer the ability to test and tune detection logic before pushing it to the SOC. Failure to do so can easily result in an overwhelming volume of alarms – and the detection engineer responsible for blowing up the SOC is not going to be popular at the office happy hour.
We believe that adversary emulation is the key to understanding telemetry and creating detections that actually protect you – it’s the foundational concept of Threat-Informed Defense. That’s why our platform has one of the world’s largest datalakes of known-malicious attack data. Our extensively labeled attack data enables machine learning to automate the validation process and predict the performance of detection logic (false positives, false negatives, and robustness), before it’s deployed downstream in a production SOC.

How SnapAttack Can Help

Operationalizing behavioral indicators instead of more traditional intelligence can be a daunting task for many organizations, but it shouldn’t be. Think differently about threat intelligence – your data sources, your threats, your strengths and weaknesses. Most importantly, think differently about what you’re trying to accomplish, because intelligence that simply informs doesn’t cut it.
SnapAttack is pre-loaded with Mandiant Advantage Threat Intelligence and TTPs tailored to users’ individual environments, mapped to the most effective detections depending on unique threat landscapes, tech stacks, and detection needs. Machine learning helps users easily prioritize the threats that matter, and from there it only takes a click (MAYBE two) to hunt for the threat, deploy detections as alerting rules, and validate whether your detection coverage is effective.
The road to better threat intelligence is a long and winding one, but not with SnapAttack. Find out how we can power up your threat intelligence and help you get from research to action faster.