ASD Essentials IT.DET-03.2 Correlate Signals Across Identities, Applications, Data and Infrastructure to Identify Incidents
What it says
Use indicators from across identities, applications, data and infrastructure activity rather than isolated signals when identifying cyber security incidents.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishSpots cyber security incidents by linking clues from accounts, apps, data and systems, rather than relying on one alert alone.
Analysts decide if something is an incident from clues in four areas, not from one alert alone. The areas are accounts and sign-ins (identities), applications, data, and servers, networks and cloud (infrastructure). For example, an odd sign-in, a new permission and a large download may be one attack. To meet this, alert rules and the steps analysts follow cover all four areas. Tools also link the steps of an attack into one alert automatically.
Free. Save your status, tasks and notes.
Where this action applies
What's in each domain?Visibility and response: a capability domain, which ASD applies across all phases from the start.
Why it matters
Judged one by one, each step of an attack can look minor and be closed. The attack is then found late or not at all, and the team underestimates how far it reached.
How to implement
The detection engineering team should list the log sources for each area, such as sign-ins, app audit logs, file access and network records.
Fill gaps with system owners, and record users and devices the same way in every source.
The security operations manager should give analysts saved searches that cover all sources, and a timeline view for each user or device.
Case templates should have a field for each of the four areas.
Detection engineers should build automated rules that link clues about the same user, device or files across the four areas, starting with multi-step attacks.
Use risk scores so several small warning signs add up to one alert.
The security operations manager should update the investigation guides (playbooks) so analysts check related activity in all four areas before closing or escalating an alert.
Train every analyst in these steps, and have them record what they checked.
The detection engineering team should run practice multi-step attacks across the four areas on a set schedule.
If the steps do not join into one alert, add or adjust rules for the missed step.
Keep it running
Security operations runs this linking as one service. This action applies organisation-wide, in every priority phase, so add each newly connected system to the linking rules and investigation guides. Detection engineers should check that rules still work. A rule can quietly stop firing, or end up using only one source, when a log feed stops or field names change after an upgrade.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
Ask for a list of active linking rules showing the log sources each one uses.
Look at
Whether rules use only one source or fixed pairs, or one of the four areas is never used.
Good evidence
Rules link the same user or device across several areas, and every area is used.
- Check 2 of 5What an auditor asks for
Ask for
Ask an analyst to show how they gather related activity for one user or device.
Look at
Whether they copy names between screens because sources do not match, or an area is missing.
Good evidence
The tools bring related activity from all four areas together, already linked.
- Check 3 of 5What an auditor asks for
Ask for
Ask for the steps analysts follow to decide on an incident, and the investigation guides.
Look at
Whether they allow a decision on one alert, or skip an area such as data access.
Good evidence
Analysts must consider related activity in all four areas before deciding on an incident.
- Check 4 of 5What an auditor asks for
Ask for
Request a sample of recent case records, including alerts closed as not an incident.
Look at
Whether cases were decided on one alert, or links between sources were pieced together by hand.
Good evidence
Each case shows all four areas considered, with automated rules doing the linking.
- Check 5 of 5What an auditor asks for
Ask for
Ask for results of practice multi-step attacks, or past incidents, that tested the linking.
Look at
Whether steps showed up as separate alerts, were linked only by hand, or were never tested.
Good evidence
Automated rules linked the steps into one alert, and missed steps led to rule changes.
ASD indicators of good practice (6)
The indicators below are quoted as published from ASD's Assessment evidence guide for enterprise IT. These optional indicators help an assessor judge the action in each domain where it applies: if any not effective statement is true, the action is rated not effective; if every applicable fully effective statement is true and no other statement is, it is rated fully effective; otherwise it is rated partially effective. ASD says the indicators "do not replace expert judgement, nor are they intended to serve as a checklist".
Not effective(2)
- NE-1Investigation relies on single-source alerts with no cross-source correlation.
- NE-2Correlation rules do not consider signals from multiple data sources.
Partially effective(2)
- PE-1Some correlation exists but is limited to specific data source pairs.
- PE-2Cross-source investigation is performed manually but not supported by automated correlation.
Fully effective(2)
- FE-1Correlation rules and investigation procedures consider signals across identities, applications, data and infrastructure.
- FE-2Automated correlation supports detection of multi-stage adversary activity.
Mappings
Closest match in ISO/IEC 27001: A.5.25, Assessment and decision on information security events, which this control partially meets.
ISO/IEC 27001: 2 mappings
This control partially meets A.5.25.
IT.DET-03.2 requires cyber security incidents to be identified using indicators from across identities, applications, data and infrastructure activity rather than isolated signals. This is a specific requirement on how the assessment in Annex A 5.25 is carried out, where information security events are assessed to decide whether they are to be categorised as incidents. Annex A 5.25 covers the assessment and categorisation decision as a whole without prescribing the sources of indicators.
This control partially meets A.8.16.
IT.DET-03.2 requires indicators from across identities, applications, data and infrastructure activity, rather than isolated signals, to be used when identifying cyber security incidents. This sets a specific expectation for how the monitoring and evaluation of potential incidents required by Annex A 8.16 is carried out. Annex A 8.16 covers monitoring networks, systems and applications for anomalous behaviour more broadly but does not require indicators to be correlated across sources.
ASD Essential Eight: 4 mappings
This control partially overlaps E8-AC-ML2.8.
IT.DET-03.2 requires incidents to be identified from indicators across identities, applications, data and infrastructure, not isolated signals; E8-AC-ML2.8 requires timely analysis of cyber security events to identify incidents, and IT.DET-03.2 shapes how that analysis is done.
This control partially overlaps E8-AH-ML2.15.
IT.DET-03.2 requires incidents to be identified from indicators across identities, applications, data and infrastructure, not isolated signals; E8-AH-ML2.15 requires timely analysis of cyber security events to identify incidents, the analysis those wider indicators should inform.
This control partially overlaps E8-MF-ML2.9.
IT.DET-03.2 requires incidents to be identified from indicators across identities, applications, data and infrastructure, not isolated signals; E8-MF-ML2.9 requires timely analysis of cyber security events to identify incidents, sharing that goal but not saying which indicators the analysis should draw on.
This control partially overlaps E8-RA-ML2.10.
IT.DET-03.2 requires incidents to be identified from indicators across identities, applications, data and infrastructure, not isolated signals; E8-RA-ML2.10 requires timely analysis of cyber security events to identify incidents, and IT.DET-03.2 sets out what it should draw on.
ASD Information Security Manual: 3 mappings
This control partially overlaps ISM-0120.
IT.DET-03.2 requires incidents to be identified from indicators across identities, applications, data and infrastructure, not isolated signals; ISM-0120 requires cyber security personnel to have sufficient tools to detect events and identify incidents, which supports that approach.
This control partially overlaps ISM-2116.
IT.DET-03.2 requires incidents to be identified from indicators across identities, applications, data and infrastructure, not isolated signals; ISM-2116 serves the same goal by requiring cyber threat intelligence services to support event detection and incident identification.
This control partially overlaps ISM-2117.
IT.DET-03.2 requires incidents to be identified from indicators across identities, applications, data and infrastructure, not isolated signals; ISM-2117 requires suitable AI models to be used to augment the detection of events and identification of incidents, aiding that work.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.