Use Cyber Threat Intelligence for Event Detection
Cyber threat intelligence is fed into log monitoring and detection tooling so that matches against known indicators help detect cyber security events and identify cyber security incidents.
Plain language
Cyber threat intelligence (CTI) is information about known attacker indicators, such as malicious IP addresses, domains, file hashes, and attacker techniques. This control is about loading that intelligence into your log monitoring and detection tools so that when your logs show activity matching a known indicator, an alert is raised. It is a detection control, not a prevention one: its job is to help you spot and confirm that a cyber security event or incident is occurring, not to block it.
Framework
ASD Information Security Manual (ISM)
Control effect
Preventative
Classifications
NC, OS, P, S, TS
ISM last updated
June 2026
Control Stack last updated
19 June 2026
E8 maturity levels
N/A
Official control statement
Cyber threat intelligence services are used to support the detection of cyber security events and the identification of cyber security incidents.
Why it matters
If cyber threat intelligence is not ingested into log monitoring and detection tooling, indicators of compromise (IOCs) and attacker techniques that appear in collected logs pass unmatched, so connections to known malicious infrastructure, known-bad file hashes, and recognised attacker tradecraft go unflagged. Cyber security events tied to known threats are missed in the noise of normal log volume, and genuine incidents are identified late or only after damage is done, extending attacker dwell time.
Operational notes
Treat CTI ingestion as a continuously maintained detection capability, not a one-off setup: indicator feeds change constantly, so keep automated feed updates running and confirm new indicators reach the SIEM and detection rules. Tune CTI-driven alert rules to suppress known false positives and stale indicators so analysts are not buried, and age out or retire indicators on a defined schedule. Periodically validate that an IOC match in collected logs actually fires an alert and is triaged into the event-to-incident workflow, and align ingested intelligence (IP, domain, hash, URL, TTP feeds) with the log sources you actually collect so there is something to match against.
Implementation tips
- Subscribe to or connect at least one cyber threat intelligence source (commercial feed, ACSC/government advisories, or an open feed such as MISP via STIX/TAXII) and configure it to deliver IOCs and attacker TTPs into your SIEM or detection platform.
- Configure automated, scheduled ingestion of indicators (malicious IP addresses, domains, URLs, file hashes) into the SIEM so the indicator set refreshes without manual effort and stale indicators are aged out.
- Build correlation or detection rules that compare collected log data (firewall, proxy, DNS, endpoint, authentication, and email logs) against ingested indicators and raise an alert on any match.
- Map your ingested indicator types to the log sources you actually collect, and add any missing telemetry (for example enable DNS or proxy logging) so domain and URL indicators have data to match against.
- Wire CTI-match alerts into your event triage and incident-identification workflow so a confirmed indicator match is escalated and recorded as a candidate cyber security incident.
- Tune CTI-driven rules to suppress known false positives and de-prioritise low-confidence or expired indicators, and review match volumes so analysts focus on high-confidence detections.
Audit / evidence tips
- Confirm at least one cyber threat intelligence feed is actually ingested into the SIEM or detection tooling: inspect the feed connector or integration configuration and the timestamp of the last successful indicator update.
- Select a sample of CTI detection or correlation rules and confirm they match collected log fields (source/destination IP, domain, URL, file hash, or TTP) against current indicators and are set to raise an alert when matched.
- Trace one CTI indicator match end to end: find a logged match against a known-bad indicator and confirm it generated an alert that entered the event triage and incident-identification workflow.
- Check that ingested indicator types align with the log sources collected (for example domain and URL indicators have proxy or DNS logs to match against), so matching is actually possible.
- Inspect a sample of incident records and confirm that where CTI contributed to identifying an incident, the matching indicator is recorded and traceable back to the source log.
Cross-framework mappings
How ISM-2116 relates to controls across ISO/IEC 27001, ISO/IEC 42001, Essential Eight, and ASD ISM.
ISO 27001
| Control | Notes | Details |
|---|---|---|
| sync_alt Partially overlaps (1) expand_less | ||
| Annex A 5.7 | ISM-2116 requires organisations to use cyber threat intelligence services to support detection of cyber security events and identificatio... | |
| handshake Supports (3) expand_less | ||
| Annex A 5.25 | ISM-2116 requires organisations to use cyber threat intelligence services to support detecting events and identifying incidents | |
| Annex A 8.15 | ISM-2116 requires using cyber threat intelligence services to support detection of cyber security events and identification of incidents | |
| Annex A 8.16 | ISM-2116 requires use of cyber threat intelligence services to improve the detection of cyber security events and identification of incid... | |
E8
| Control | Notes | Details |
|---|---|---|
| handshake Supports (2) expand_less | ||
| E8-AC-ML2.8 | ISM-2116 requires use of cyber threat intelligence services to support the detection of cyber security events and identification of incid... | |
| E8-RA-ML2.10 | ISM-2116 requires cyber threat intelligence services to be used to support event detection and incident identification | |
| link Related (1) expand_less | ||
| E8-RA-ML3.8 | ISM-2116 requires cyber threat intelligence services to be used to support detection of cyber security events and identification of incid... | |
These mappings show relationships between controls across frameworks. They do not imply full equivalence or certification.