M1019 Threat Intelligence Program: Turning Intelligence Into Exploit and Impersonation Defences

A threat intelligence programme does not block anything by itself, so ATT&CK maps M1019 to the few techniques where knowing who is coming, and with what, is the only practical defence. In ATT&CK v20, M1019 Threat Intelligence Program has five active "mitigates" relationships: four exploitation techniques where zero-days and unpatched flaws leave no configuration to change, and impersonation, where awareness of live lures is the control. This guide treats M1019 as a control a team implements and measures: what ATT&CK expects, how intelligence becomes patch priorities, detections and user warnings, where non-human identities fit, and how to tell whether the programme changes anything. It is for SOC leads, detection engineers and CTI analysts. The discipline itself is covered in the Threat Intelligence Guide; this page stays on the ATT&CK mitigation view.

Key takeaways

• M1019 covers the gaps other mitigations cannot close. ATT&CK's usage text for the four exploitation techniques is identical: develop a threat intelligence capability to know what types and levels of threat may use software exploits and 0-days against your organisation.
• The output is a decision, not a feed. A programme earns the M1019 label when intelligence changes a patch order, a detection, a block rule or a user warning within a defined time.
• Intelligence requirements come first. MITRE's own description starts with defining requirements around critical assets; collection without them produces volume, not coverage.
• Exploited edge devices put NHI credentials at risk. When a gateway or appliance is exploited, the service account passwords, API keys and certificates stored on it must be treated as exposed, so CTI has to reach the identity team.
• D3FEND does not model it. The D3FEND ontology states that establishing and running a threat intelligence programme is outside its scope, so mapping M1019 to defensive techniques is a programme design task.

What M1019 asks for

MITRE describes a Threat Intelligence Program as the ability to identify, analyse and act on threats using internal and external data, to support decisions, prioritise defences and improve incident response. The mitigation page lists seven measures:

1. Establish a team: a dedicated team or named responsibility within existing security staff.
2. Define intelligence requirements: identify critical assets and focus collection on threats to them.
3. Use internal and external sources: logs, incidents and alerts internally; feeds, ISACs and open-source intelligence externally.
4. Automate: threat intelligence platforms for collection, enrichment and dissemination, and SIEM integration to correlate indicators with internal events.
5. Analyse and act: map intelligence to ATT&CK techniques, and prioritise defensive measures such as patching or deploying indicators.
6. Share: exchange intelligence with peers through ISACs and sharing platforms.
7. Evaluate and update: assess effectiveness regularly and revise priorities as threats change.

Among example tools, MITRE names open-source platforms such as MISP and OpenCTI, ATT&CK Navigator for mapping behaviours, and ISAC membership. These are illustrations, not requirements. See the ISACs and Information Sharing Communities Guide for the sharing side.

Techniques M1019 mitigates

The v20 dataset has five entries. The first four share the same usage text about exploits and 0-days; the fifth is about lures.

The pattern is clear: for exploitation, M1051 Update Software and M1050 Exploit Protection are the controls that stop the attack, and M1019 decides which flaws get fixed or shielded first, especially before a patch exists. For impersonation, M1019 feeds M1017 User Training with the lures that are actually in circulation.

Turning intelligence into mitigation

An NHI Mgmt Group recommendation for making M1019 measurable is to define four outputs, each with an owner and a time limit.

Exploitation: from intelligence to patch order

The CISA Known Exploited Vulnerabilities catalogue is the most widely used public signal that a flaw is being exploited. In the catalogue release of 21 October 2026 it held 1,754 entries, of which 361 were marked as having known use in ransomware campaigns. A programme that joins KEV and exploitation intelligence to its asset inventory can answer, within hours, "do we run this, is it exposed, and who owns it". See the CISA KEV Catalogue Guide and the EPSS Guide for scoring.

The Ivanti Connect Secure exploitation shows why timing matters. Exploitation of CVE-2023-46805 and CVE-2024-21887 began weeks before Ivanti disclosed them on 10 January 2024, the same day CISA added both to KEV, and patches followed on 31 January. In that gap, the only defences were vendor mitigations, hunting and isolation, all of which depended on knowing about the campaign. CISA later advised organisations to assume that user and service account credentials stored on affected appliances were likely compromised.

Impersonation: from intelligence to warnings

For T1684.001, the useful intelligence is concrete: the pretext being used, the brand or supplier imitated, the channel (email, voice, messaging, collaboration apps), and what the caller asks for. Route it to the service desk, finance and the awareness team, not only the SOC. See the Business Email Compromise Awareness for Finance Teams Guide.

Building the programme in phases

1. Set requirements: list crown-jewel systems, internet-facing products by vendor and version, identity platforms, and the actor groups relevant to your sector. Review them every quarter.
2. Connect to the asset inventory: intelligence about a flaw is useless if nobody can say where the product runs. This is the first integration to build.
3. Pick a small source set: KEV, your vendors' security advisories, one sector ISAC or national CERT, and one commercial or community source. Add more only when an intelligence requirement is not being met.
4. Map to ATT&CK: map each relevant report to techniques and compare with your detection and mitigation coverage in ATT&CK Navigator layers. MITRE's free ATT&CK CTI training covers mapping from reports and raw data and turning the result into defensive recommendations. See the MITRE ATT&CK Coverage Mapping Guide.
5. Pilot the four outputs: run them for one quarter with the vulnerability, detection and awareness teams, measuring time to action.
6. Share and handle properly: label shared material with the FIRST Traffic Light Protocol (TLP 2.0, authoritative since August 2022: TLP:RED, TLP:AMBER, TLP:AMBER+STRICT, TLP:GREEN, TLP:CLEAR), and follow NIST SP 800-150 for setting sharing goals, scope and rules.
7. Review and roll back noise: if indicator feeds generate alerts that never lead to action, remove or down-weight them. Expire indicators; stale ones cause false positives and blocklist outages.

Small and large organisations

A small team without analysts can meet the intent of M1019 by subscribing to KEV and vendor advisories, joining a sector ISAC or national CERT mailing list, and naming one person who checks them daily against a maintained product list. A large organisation needs written intelligence requirements, a threat intelligence platform integrated with the SIEM and vulnerability tooling, and analysts who map reports to ATT&CK and track actions to closure. The Threat Intelligence Maturity Model describes the steps between.

Where non-human identities fit

Exploited edge devices, management planes and integration platforms often hold machine credentials: service account passwords, API keys, certificates and OAuth secrets. When intelligence says such a product is under active exploitation, the response has to include rotating the secrets stored on it, not only patching. Build that into the patch-or-shield output: each internet-facing product in the inventory should list the non-human identities it stores and the owner who can rotate them. Intelligence about leaked tokens, exposed keys in public repositories and abuse of specific SaaS integrations is equally an NHI concern. See the Threat Intelligence for Identity and NHI Guide. The platform itself holds API keys to feeds, SIEM and ticketing systems; secure it as covered in Securing the threat intelligence platform (TIP) itself.

What M1019 does not stop

• The exploit itself: intelligence shortens time to patch or shield but cannot replace M1051 Update Software, M1050 Exploit Protection or M1048 Application Isolation and Sandboxing.
• Unreported or targeted zero-days: an exploit used only against you will not appear in any feed; defence then rests on segmentation, least privilege and behavioural detection.
• Attacks with no intelligence footprint: insider misuse and valid-account abuse rarely show up in external reporting.
• A programme without action owners: reports read but not turned into tickets produce no mitigation, whatever the feed spend.

Detection and measurement

Measure M1019 by what changes downstream. Suggested metrics:

• Time to exposure answer: hours from an exploited-vulnerability report to a confirmed list of affected, internet-facing assets.
• Time to mitigation for exploited flaws: median days from KEV addition or credible exploitation report to patch or shield, for exposed systems.
• Intelligence-driven detections: number of detections created or tuned per quarter that cite an intelligence report or ATT&CK mapping.
• Requirement coverage: share of written intelligence requirements answered by at least one active source.
• Indicator quality: share of indicator-based alerts that led to an investigation or block, and the share of indicators with expiry dates.
• Warning lead time: days between an impersonation campaign warning and the first related report from staff or the service desk.

Common failure patterns

• Feeds without requirements: buying indicator feeds before defining what decisions they support, which floods the SIEM with low-confidence matches.
• No link to the asset inventory: the team knows a product is under attack but cannot say where it runs or who owns it.
• Patching without credential rotation: after exploitation of an appliance, the stored service account passwords, keys and certificates are left in place, as CISA warned against in the Ivanti case.
• Intelligence that stops at the SOC: impersonation warnings never reach the service desk or finance teams who take the calls.
• Stale indicators: blocklists that never expire, causing false positives and loss of trust in the programme.
• Mapping without action: ATT&CK heatmaps produced for reports but never compared with detection coverage.

Framework mapping

Practitioner checklist

• Write intelligence requirements around crown-jewel systems, exposed products and relevant actor groups.
• Link intelligence to an asset inventory that records product, version, exposure and owner.
• Check KEV and vendor advisories daily against that inventory.
• Define patch-or-shield, detection, block and warning outputs with owners and target times.
• Record the non-human credentials stored on each exposed product, and rotate them after exploitation.
• Map relevant reports to ATT&CK and compare against detection coverage each quarter.
• Route impersonation intelligence to the service desk, finance and awareness teams.
• Label shared material with TLP 2.0 and expire indicators.
• Report time to exposure answer and time to mitigation for exploited flaws.

Standards and references

• MITRE ATT&CK: M1019 Threat Intelligence Program
• MITRE ATT&CK: T1210 Exploitation of Remote Services
• MITRE ATT&CK: Using ATT&CK for Cyber Threat Intelligence Training
• NIST: SP 800-150 Guide to Cyber Threat Information Sharing
• NIST: SP 800-53 Rev. 5
• NIST: Cybersecurity Framework 2.0
• CISA: Known Exploited Vulnerabilities Catalog
• FIRST: Traffic Light Protocol (TLP)

Related NHI Mgmt Group resources: Threat Intelligence Guide · Threat Intelligence for Identity and NHI Guide · CISA KEV Catalogue Guide · Detection Engineering Guide · Patch Management Guide