Skip to content
DET-01 Centralised event logging
ASD EssentialsIT.DET-01.2

ASD Essentials IT.DET-01.2 Forward High-Value Security Logs and Configuration Changes to Central Log Storage

What it says

Forward high-value, security-relevant event logs and configuration changes from infrastructure, operating systems and applications to a central log storage capability.

Quoted as published. Everything else on this page is written by Control Stack.

What it means

In plain English

Sends key security logs and setting changes from network gear, servers, computers and apps to one central store.

Servers, network equipment, laptops and apps keep logs of who signed in, what ran and which settings changed. The organisation sends copies of the most useful security records to one central store soon after they happen. For example, a changed firewall rule shows up there too. To meet this, every relevant system sends its records. Regular checks confirm each one is sending, and that the records still help spot current attacks.

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.

Why it matters

If logs stay only on the systems that create them, an intruder can clear them or switch logging off and leave no trail. Gaps and slow sending let unapproved changes and attacker activity go unnoticed.

How to implement

  1. The security team should list every log source, using the asset inventory.

    For each system, record the infrastructure, operating system and application events to send, such as sign-ins, admin actions and scripts running.

  2. System administrators should turn on the logging each source needs and send its events, including every settings change, to the central store.

    Build this into standard builds, such as server and laptop images.

  3. The logging platform team should send events soon after they happen and agree a maximum delay with security operations.

    Measure the delay, and hold events locally during outages so none are lost.

  4. The security operations team should regularly compare the source list with the sources actually sending.

    Alert when an expected source goes silent, and track each gap until it is fixed.

  5. Detection engineers should review every log source on a set schedule against current reports of attacker techniques and lessons from incidents and exercises.

    Record each decision, then add, change or retire sources in the list.

Keep it running

The logging team watches for expected sources that go silent, drop sharply in volume or send later than the agreed delay. It treats each as a fault or possible tampering. Extend coverage in ASD's priority order: internet-facing and sign-in systems first, then critical and admin systems, then business systems and staff devices. Make log sending a standard build step, and update the log source list whenever a system is added, changed or retired.

Evidence and audit

  1. Check 1 of 5What an auditor asks for

    Ask for

    Request the log source list and sample systems in every ASD domain, from firewalls to laptops.

    Look at

    Whether each sample's infrastructure, operating system and application events reach central storage, or stay local.

    Good evidence

    Every relevant source across every ASD domain sends its high-value security events centrally.

  2. Check 2 of 5What an auditor asks for

    Ask for

    Ask to see the central log events for a sample of recent approved changes.

    Look at

    Whether change events arrive from some platforms but not others, or only some of the time.

    Good evidence

    Each sampled change, on infrastructure, an operating system or an application, appears centrally.

  3. Check 3 of 5What an auditor asks for

    Ask for

    Ask for the latest check of expected sources against those actually sending.

    Look at

    Whether completeness is assumed rather than tested, and whether silent sources went unnoticed.

    Good evidence

    Every expected source is sending, and gaps are found quickly and tracked until fixed.

  4. Check 4 of 5What an auditor asks for

    Ask for

    Ask for the agreed maximum delay and measured delays for sources in several ASD domains.

    Look at

    Whether sources upload in rare batches, or no delay limit is set or measured.

    Good evidence

    Events reach central storage within the agreed limit, soon enough to catch attacks in time.

  5. Check 5 of 5What an auditor asks for

    Ask for

    Ask for the log source review schedule and the findings and decisions from recent reviews.

    Look at

    Whether reviews ran only after incidents or tool changes, or recorded no findings, decisions or follow-up.

    Good evidence

    Reviews run on schedule, use current threat reports, and each gap leads to a change.

ASD indicators of good practice (10)

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-1Security-relevant logs from assets are not forwarded to a central logging capability.
  • NE-2High-value, security-relevant event logs or configuration changes from infrastructure, operating systems or applications are not forwarded.

Partially effective(4)

  • PE-1High-value, security-relevant event logs are forwarded, but coverage gaps are identified or completeness has not been validated.
  • PE-2Configuration change logs are forwarded inconsistently.
  • PE-3The utility of security log sources is reviewed, but on an ad hoc basis rather than according to a defined schedule.
  • PE-4Log forwarding is in place but latency is excessive for effective detection.

Fully effective(4)

  • FE-1High-value security-relevant event logs and configuration changes from all relevant infrastructure, operating systems and application sources are forwarded to the central logging capability.
  • FE-2Security log sources are reviewed at regular intervals to ensure their continued utility in detecting and responding to changing adversary techniques.
  • FE-3Log completeness has been validated against the expected log sources.
  • FE-4Logs are forwarded at a frequency that enables timely detection.

Mappings

Closest match in ISO/IEC 27001: A.8.15, Logging of Activities and Events, which this control partially meets.

ISO 27001

ISO/IEC 27001: 1 mapping

Essential Eight

ASD Essential Eight: 6 mappings

ASD ISM

ASD Information Security Manual: 3 mappings

Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.