Cyber Threat Intelligence Is an Offensive Security Discipline and Partnership

Ask most organizations what Cyber Threat Intelligence (CTI) does, and you’ll hear some variation of:

  • Monitor commercial and open-source intelligence feeds
  • Publish reports
  • Produce indicators of compromise (IOCs)
  • Support threat hunting
  • Brief leadership

None of those things are wrong.

They’re just incomplete.

The biggest missed opportunity I see is that CTI often becomes a reporting function for the defensive side of the house, while the offensive teams—the people responsible for validating the organization’s assumptions—rarely benefit from that intelligence in a meaningful way.

I believe that’s backwards.

Threat Intelligence Is a Prioritization Engine

The purpose of CTI isn’t to collect information.

It isn’t to write reports.

It isn’t even to predict attacks.

The purpose of threat intelligence is to reduce uncertainty so the organization can make better security decisions faster.

One of the most important security decisions is simply this:

What should we test next and WHY?

That’s exactly the question red teams exist to answer.

Intelligence Should Drive Adversary Emulation

Imagine your CTI team identifies that a ransomware group targeting your industry has shifted from password attacks to OAuth application abuse and Microsoft Graph APIs.

Many organizations stop there.

They publish a report.

Maybe they create a detection.

Maybe they run a threat hunt.

Then the report gets archived.

A mature organization goes further.

  • The Red Team builds an emulation of the OAuth abuse.
  • The Purple Team validates whether defenders can detect and respond.
  • Detection Engineering develops detections & analytics based on the exercise.
  • Engineering reviews conditional access policies, application consent, and logging.
  • CTI continues tracking how the adversary evolves.

Now intelligence has done something far more valuable than informing a hunt.

It has improved the organization’s resilience.

From Information to Validation

Threat intelligence should feed a continuous learning loop.

Threat Intelligence
        ↓
    Assumptions
        ↓
 Adversary Emulation
        ↓
 Purple Team Validation
        ↓
 Detection Engineering
        ↓
 Improved Defensive Coverage
        ↓
 New Intelligence Requirements

Threat intelligence shouldn’t be a one-way pipeline into the SOC.

It should continuously influence what the organization chooses to validate.

Stop Measuring Reports

One reason CTI programs struggle to demonstrate value is because they measure production instead of impact.

Executives don’t care how many reports were published.

They care what changed because of them.

Instead of asking:

“How many intelligence reports did we produce?”

Ask questions like:

  • How many offensive scenarios did CTI generate?
  • How many adversary techniques were emulated because of new intelligence?
  • How many detection gaps were discovered?
  • How many controls improved because of those exercises?
  • Did we get in front of adversary attacks with CTI?

A much more compelling story looks like this:

  • 12 new adversary TTP updates identified
  • 8 adversary emulations developed
  • 6 detection gaps discovered
  • 6 new detections deployed
  • 2 real-world incidents detected using those improvements

That’s a value chain.

Red Teams Should Produce Intelligence Too

This relationship shouldn’t be one directional.

Red teams are one of the organization’s best intelligence collection assets.

Every engagement should answer questions like:

  • Which ATT&CK techniques consistently succeeded?
  • Which assumptions about our environment were wrong?
  • Which defensive controls created meaningful friction?
  • Which attacker tradecraft was unexpectedly effective?
  • What new intelligence requirements should we be requesting from CTI?

Those lessons shouldn’t disappear into an after-action report.

They should feed directly back into CTI, influencing future collection priorities and adversary emulation.

Validate Assumptions, Not Controls

One idea has shaped much of my thinking about offensive security:

Security shouldn’t exist to validate controls. It should exist to validate assumptions.

Threat intelligence identifies which assumptions about adversaries deserve testing.

Red teaming tests those assumptions.

Purple teaming measures whether the organization can detect and respond.

Detection engineering operationalizes the lessons and creates detections.

Threat Hunting checks if we are late to the information.

CTI refines its understanding of the threat landscape.

Then the cycle repeats.

That’s what a living adversary program looks like.

Final Thought

Threat intelligence isn’t a reporting function.

It’s a prioritization engine.

When CTI is treated as something that simply feeds the SOC, organizations leave enormous value on the table.

When it drives offensive testing, defensive validation, and executive decision-making, it becomes something much more powerful:

It becomes the function that decides what the organization learns next.

After 20 years of Offensive Security work I can assure you that your Offensive Security leads want this information and interaction with CTI.

Note: this post was inspired by the question in the ThreatIntel subreddit: https://www.reddit.com/r/threatintel/comments/1v7sfi6/how_do_you_show_threat_intel_value_to_execs/

Want to know whether your CTI program is informing action or just producing reports?

Adversarial Insights helps organizations connect threat intelligence to adversary emulation, assumption validation, and measurable improvements in defensive capability.

If your intelligence program isn’t changing what your red team tests, it may not be changing your security posture at all.