Proactive Threat Intelligence
Proactive threat intelligence anticipates what an adversary is about to do, rather than cataloguing what one already did. Instead of consuming reports about incidents at other organisations, it derives forward-looking indicators from adversary behaviour observed directly — and converts them into controls before the technique is used against production.
The term is applied loosely. This page sets out what separates genuinely proactive intelligence from repackaged reactive feeds, which sources actually produce it, how to measure whether yours is working, and where it commonly fails.
Proactive vs. reactive threat intelligence
Almost all commercially available threat intelligence is reactive by construction. That is not a criticism of its quality — it is a description of where it comes from. An indicator can only be published after an intrusion has occurred, been investigated, and been written up.
| Dimension | Reactive | Proactive |
|---|---|---|
| Underlying event | An intrusion that already succeeded, somewhere else | An attempt being made now, against infrastructure you control |
| Earliest possible arrival | After exploitation, investigation, and publication | At the moment of the attempt |
| Who it describes | Adversaries targeting the population in general | Adversaries targeting you specifically |
| Typical artefact | Hashes, IPs, domains — the residue of an attack | Techniques, tooling, and infrastructure in current use |
| Shelf life | Short: infrastructure is rotated once it is published | Longer: behaviour changes more slowly than indicators |
| Failure mode | Arrives after the window it would have protected | Requires infrastructure adversaries actually engage with |
Both have a place. The distinction that matters operationally is not quality but timing relative to your own exposure.
Where proactive intelligence actually comes from
Six sources are commonly described as proactive. They are not equivalent, and the difference between them is whether the activity observed was aimed at somebody else or at you.
| Source | What it yields | Limitation |
|---|---|---|
| Open-source monitoring | Early signal on disclosed vulnerabilities, exploit code, and researcher chatter | Public by definition, so every defender and attacker sees it simultaneously |
| Criminal forum and marketplace monitoring | Credentials for sale, access brokerage, tooling under development | Access-dependent and unevenly reliable; describes intent more than technique |
| Commercial aggregated feeds | Breadth and volume across many contributors | Generic by construction — the same content is sold to your peers |
| Sector sharing (ISACs) | Relevance to your industry and threat model | Moves at the speed of member disclosure, which is rarely immediate |
| Your own estate telemetry | Ground truth about what is actually reaching you | By the time it appears in production logs, exposure has already occurred |
| Deception infrastructure | Technique, tooling, and sequencing observed live, before production is touched | Only sees adversaries who engage the deception layer |
The last row is the only one where the observed activity is both aimed at you and ahead of exposure. That is the basis of AST’s approach: BaitHive Decoy and TCP Mirage present our own clone infrastructure, which has no legitimate users, so every interaction is adversarial by definition, and CATIS converts what happens there into intelligence.
Indicators of Future Attacks
AST’s term for the output is an Indicator of Future Attack — the inverse of an Indicator of Compromise. An IOC says an intrusion succeeded elsewhere and here is its residue. An IOFA says a technique is being attempted now, against a clone of your environment, and here is the control that stops it.
The claim is falsifiable, which is the point. Each case has a date the behaviour was observed and a date the vulnerability was publicly disclosed, and the interval between them is either real or it is not. Ours are listed with CVE references on the evidence page; the documented cases run from two days to forty-five days of lead time.
What you actually do with it
Intelligence that is not acted on is a subscription, not a control. Four uses account for most of the value.
Pre-emptive control updates
The highest-value path, and the one most often missing: the indicator becomes an enforced rule automatically. In AST’s platform, intelligence from the deception layer propagates to NanoFirewall and ShenDNS without a human approving each change, because a loop that runs at human speed forfeits the lead time that made the intelligence valuable.
Retrospective hunting
A newly derived indicator is worth applying backwards as well as forwards. ASPEN runs detection logic retroactively across historical data, so a technique identified today can be tested against events that predate the rule — which is how presence that began weeks earlier gets found.
Exposure prioritisation
Vulnerability backlogs exceed the capacity to clear them, so the ordering matters more than the count. Knowing which flaws are being actively probed against infrastructure resembling yours is a better prioritisation signal than severity score alone.
Reporting that survives scrutiny
Board and regulator questions tend to be about specifics: what was aimed at us, when did we know, what did we do. Intelligence tied to dated observations on your own infrastructure answers those directly. Where AI systems are in scope, the same evidence trail feeds the obligations described on our EU AI Act compliance page.
How to measure whether it is working
Most threat intelligence programmes are evaluated on volume, which is the one metric that should not matter. Four that do:
| Measure | The question it answers |
|---|---|
| Lead time | How many days between our first observation of a technique and its public disclosure? If the answer is negative, the intelligence is reactive regardless of what it is called. |
| Specificity | What proportion of what we receive concerns adversaries or infrastructure actually engaging us, rather than the population at large? |
| Enforcement rate | What proportion of indicators became an enforced control, and how long did that take? A report that ends in a ticket queue has not changed the attack surface. |
| Precision | What is the false-positive rate, and is it low because of architecture or because of tuning? Tuning decays; architecture does not. |
Common failure modes
Programmes rarely fail because the intelligence was wrong. They fail structurally.
Feed sprawl without enforcement. Adding sources increases volume and analyst load while leaving the enforced control set unchanged. More intelligence is not more security if nothing downstream consumes it.
Generic content treated as specific. Aggregated feeds describe the threat landscape, not your threat landscape. Useful for context, weak for prioritisation, and often mistaken for the latter.
Lead time never measured. If nobody records the observation date against the disclosure date, there is no way to know whether the programme is proactive at all. It is the single cheapest metric to start collecting and the most commonly absent.
Precision achieved by tuning. Suppression rules that make an alert stream tolerable also encode assumptions that age badly. Precision that comes from an architectural property — nobody legitimate touches a decoy — does not decay the same way.
Where this sits in a preemptive posture
Proactive threat intelligence is one of the five capability areas that make up preemptive cybersecurity, not a synonym for it. Intelligence anticipates; a preemptive posture also enforces, automatically. A programme that predicts accurately but changes nothing has moved the knowledge, not the risk.
Frequently asked questions
What is proactive threat intelligence?
Proactive threat intelligence anticipates adversary behaviour before an attack reaches production, rather than describing intrusions that already occurred elsewhere. It is derived from adversaries observed directly — typically on deception infrastructure — and is most valuable when it is converted into an enforced control automatically.
How is it different from reactive threat intelligence?
Reactive intelligence can only exist after an intrusion has succeeded, been investigated, and been published, so it always arrives after the window it would have protected. Proactive intelligence is generated at the moment of the attempt, which is what creates lead time.
Is threat intelligence the same as threat hunting?
No. Threat hunting is the activity of searching your environment for adversaries who may already be present. Threat intelligence is the knowledge that informs where to look. Proactive intelligence improves hunting by supplying techniques worth hunting for before they are widely documented.
Which sources produce genuinely proactive intelligence?
Open-source monitoring, criminal forum monitoring, commercial feeds, and sector sharing all describe activity aimed primarily at others. Deception infrastructure is the source where the observed activity is both aimed at you and ahead of exposure, because the adversary is engaging a clone of your environment rather than production.
How do you measure whether it is proactive?
Record the date a technique was first observed against the date it was publicly disclosed. A positive interval is lead time; a negative one means the programme is reactive whatever it is called. Track enforcement rate alongside it, since unenforced intelligence does not change the attack surface.
Does it require sharing our data with a vendor?
Not necessarily. AST’s platform is air-gap capable and supports distributed deployment with configurable selective exchange between instances, which matters for government, defence, and operational technology environments where outbound connectivity to a vendor cloud is not permitted.
See it against your own environment
Lead-time claims are only worth the dates behind them. Ours are published with CVE references on the evidence page. The managed service that produces them is CATIS, and deployment options are set out on the service packages page.