ASD Essentials IT.DET-02.1 Normalise, Time-Synchronise and Enrich Event Logs for Cross-System Correlation
What it says
Ensure event logs are normalised, time-synchronised and enriched to support correlation across systems and environments.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishPuts logs in one format and on one trusted clock, adding details like account type, so events can be matched across systems.
Firewalls, servers, laptops and cloud services each write logs in their own format and by their own clock. The organisation fixes this so security staff can line up events from different systems and spot the steps of one attack. To meet this, every system uses the same trusted time source. Logs are converted into one shared format and tagged with context, such as how sensitive each system is and the type of account used.
Free. Save your status, tasks and notes.
Where this action applies
What's in each domain?ASD orders the work by domain: apply this action to each ticked domain, phase by phase.
- Phase 3
Why it matters
If clocks disagree and logs lack a shared format or context, nobody can piece together an intruder's path. For example, a move from an internet-facing device to the staff directory goes unseen. Investigations take longer, timelines can be wrong and risky admin activity blends in.
How to implement
Infrastructure teams should set every system that writes logs to sync with the organisation's trusted time source.
Record times in universal time (UTC) or with a time zone, and alert when a clock goes out of sync.
The logging team should set one common log format, with standard field names such as user and source address.
Build a converter for every source that maps its events into that format, and alert when events fail to convert.
The logging platform team should automatically add system context, such as sensitivity and importance, from the asset list.
Add account type and role from the account directory, and flag events that cannot be matched.
The security operations team should regularly run a test sequence across on-site and cloud systems, such as a remote sign-in then a server change.
Make sure the events join up in the right order.
Keep it running
The logging team counts a new source as connected only when its events have the right time, use the shared format and carry system and account tags. Watch cloud services that use other time zones. Follow ASD's priority order: internet-facing and sign-in systems first, then critical and admin systems, then business systems and staff devices. Fix clock errors, failed conversions and out-of-date context, because each quietly breaks the links between events.
Evidence and audit
- Check 1 of 4What an auditor asks for
Ask for
Request the trusted time source and clock sync status for sample systems in each ASD domain.
Look at
Whether systems use an unapproved time source or none, run out of sync, or omit the time zone.
Good evidence
Every sampled system keeps time with the trusted source, and times line up across systems.
- Check 2 of 4What an auditor asks for
Ask for
Request the common log format and the converter each log source uses.
Look at
Whether any source has no converter, or the same detail, such as user, is named differently across sources.
Good evidence
Every in-scope source is converted into one maintained format, so fields mean the same everywhere.
- Check 3 of 4What an auditor asks for
Ask for
Ask the team to show sample events with added context next to the raw originals.
Look at
Whether the added context misses key details, such as system sensitivity or account type, or uses old lists.
Good evidence
Each event carries current system sensitivity and account type, traceable to the asset list and directory.
- Check 4 of 4What an auditor asks for
Ask for
Ask the team to trace one user's activity across systems, on site and in the cloud.
Look at
Whether linking works only within one source, or events appear out of order or will not join.
Good evidence
Events from every relevant source form one ordered timeline, joined on shared fields.
ASD indicators of good practice (7)
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-1Logs are not time-synchronised to an authoritative source.
- NE-2Logs are ingested in raw format and are neither normalised nor enriched.
Partially effective(2)
- PE-1Logs are time-synchronised but are not normalised to a common schema.
- PE-2Some enrichment is applied but critical contextual data such as asset classification or account type is missing.
Fully effective(3)
- FE-1Logs are time-synchronised to the authoritative time source.
- FE-2Logs are normalised into the common log schema and enriched with contextual metadata.
- FE-3Enriched logs support correlation across relevant systems, environments and data sources in the central logging platform.
Mappings
Closest match in ISO/IEC 27001: A.8.15, Logging of Activities and Events, which this control partially meets.
ISO/IEC 27001: 3 mappings
This control partially meets A.8.15.
IT.DET-02.1 requires event logs to be normalised, time-synchronised and enriched to support correlation across systems and environments. This strengthens the analysis element of Annex A 8.15, which requires logs recording activities, exceptions, faults and other relevant events to be produced, stored, protected and analysed. Annex A 8.15 covers the whole logging life cycle, while IT.DET-02.1 addresses the consistency and context of log data needed for effective correlation.
This control partially overlaps A.8.17.
IT.DET-02.1 requires event logs to be normalised, time-synchronised and enriched to support correlation across systems and environments. Its time-synchronisation element overlaps with Annex A 8.17, which requires the clocks of information processing systems to be synchronised to approved time sources, and in practice relies on it. IT.DET-02.1 also requires normalisation and enrichment, while Annex A 8.17 applies to all system clocks and requires approved time sources.
This control supports A.8.16.
IT.DET-02.1 requires event logs to be normalised, time-synchronised and enriched so they can be correlated across systems and environments. This directly enables the monitoring of networks, systems and applications for anomalous behaviour required by Annex A 8.16, since correlation depends on consistent, accurately timed and contextualised data. IT.DET-02.1 prepares the log data, while Annex A 8.16 covers the monitoring itself and the evaluation of potential incidents.
ASD Information Security Manual: 4 mappings
This control partially overlaps ISM-0585.
IT.DET-02.1 requires event logs to be normalised, time-synchronised and enriched to support correlation across systems; ISM-0585 requires each logged event to capture date and time, user or process, filename, description and IT equipment involved, detail that aids correlation.
This control partially overlaps ISM-0988.
IT.DET-02.1 requires event logs to be normalised, time-synchronised and enriched to support correlation across systems and environments; ISM-0988 requires an accurate and consistent time source for event logging, which covers the time-synchronisation part.
This control partially overlaps ISM-1405.
IT.DET-02.1 requires event logs to be normalised, time-synchronised and enriched to support correlation across systems and environments; ISM-1405 requires a centralised event logging facility, which supports that correlation by bringing logs together in one place.
This control partially overlaps ISM-1959.
IT.DET-02.1 requires event logs to be normalised, time-synchronised and enriched to support correlation across systems and environments; ISM-1959 requires event logs to be captured and stored in a consistent and structured format where possible, covering the normalisation part.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.