ASD Essentials IT.DET-01.1 Encrypt Event Logs and Restrict Access to Prevent Tampering and Deletion
What it says
Protect event logs from unauthorised access, modification or deletion, including by encrypting them during transit and at rest and securing the systems and accounts used to store, manage and analyse them.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishKeeps event logs safe from being read, changed or deleted without approval, with encryption and locked-down logging systems and accounts.
Event logs record what happens on systems, such as who signed in and what changed. They are often the only way to see what an attacker did. The organisation stops these logs being read, changed or deleted without a real need. To meet this, logs are encrypted when sent and when stored. Only people whose job needs it can open them. The logging systems, and the accounts that run them, are locked down too.
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
Without these protections, an intruder can delete or edit logs, or switch logging off, so the break-in goes unseen and cannot be pieced together. Exposed logs also reveal usernames and system details. One hacked logging account could wipe evidence everywhere.
How to implement
The security operations manager should name the roles that need to read or manage logs for their job.
Grant access only through those roles, and recheck who holds them on a set schedule.
System administrators should let only the approved role clear local logs or stop logging.
Set central storage so that no one can change or delete stored logs outside an approved process.
Network and logging engineers should encrypt logs at every step, from source to collection server to central storage, replacing unencrypted methods such as plain syslog.
Send logs from older devices through a nearby log collection server that encrypts them.
Platform administrators should encrypt logs wherever they are stored, including collectors, the central store, archives and backups.
Where practical, people who run the logs day to day should not also control the encryption keys.
The logging platform owner should lock down and patch the systems that store, manage and analyse logs, and require multi-factor authentication (MFA).
Keep admin accounts separate from those on the logged systems, and give log-sending software send-only access.
Keep it running
The security operations manager reviews who can reach logs on a set schedule. Alert on signs of tampering, such as logs cleared, logging stopped or log retention settings changed. Follow ASD's priority order: internet-facing and sign-in systems first, then critical and admin systems, then business systems and staff devices. Watch internet-facing devices, whose local logs are easily wiped, and cloud audit settings that cloud administrators can change. Protect every new log source from the start.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
Ask for the approved log access roles and the current members of each access group.
Look at
Whether broad groups, shared accounts or leavers can still read or export logs without a business need.
Good evidence
Only approved roles with a business need can reach logs, at the source and centrally.
- Check 2 of 5What an auditor asks for
Ask for
Ask to see what happens when an unapproved account tries to delete a stored log.
Look at
Whether some roles, such as platform or system administrators, can still delete or change stored logs.
Good evidence
No role can change or delete logs outside a controlled, approved process.
- Check 3 of 5What an auditor asks for
Ask for
Request the local logging settings for sample devices, such as a firewall and a laptop.
Look at
Whether logs are sent on but can still be cleared at the source, or logging switched off.
Good evidence
Logs are protected from change or deletion at the source, not only after collection.
- Check 4 of 5What an auditor asks for
Ask for
Request a diagram of log flows showing encryption at each step, and the storage encryption settings.
Look at
Whether any step sends logs unencrypted, or logs sit unencrypted in collectors, archives or backups.
Good evidence
Logs are encrypted at every step and wherever they are stored.
- Check 5 of 5What an auditor asks for
Ask for
Ask which people and system accounts can reach logging platforms, and how each signs in.
Look at
Whether logging platforms share admins with logged systems, lack MFA, run unpatched or let log-sending software delete logs.
Good evidence
Logging systems are locked down and patched, with separate accounts protected by MFA.
ASD indicators of good practice (9)
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(3)
- NE-1Logs generated by applicable assets are not protected from modification or deletion.
- NE-2Log access is not restricted to authorised roles with a business need.
- NE-3Logs are neither encrypted during transit nor at rest.
Partially effective(3)
- PE-1Logs are forwarded but integrity protections are not in place at the source.
- PE-2Log access is restricted but some roles retain the ability to modify or delete logs.
- PE-3Logs are encrypted during transit but are not protected with encryption at rest (or vice versa).
Fully effective(3)
- FE-1Logs are protected against modification or deletion.
- FE-2Logs are encrypted in transit and at rest.
- FE-3Access to logs is restricted to authorised roles with a business need.
Mappings
Closest match in ISO/IEC 27001: A.5.33, Protection of Records, which this control partially meets.
ISO/IEC 27001: 3 mappings
This control partially meets A.5.33.
IT.DET-01.1 requires event logs to be protected from unauthorised access, modification or deletion, including through encryption and by securing the systems and accounts that store, manage and analyse them. Because event logs are records, this is a specific case of Annex A 5.33, which requires records to be protected from loss, destruction, falsification, unauthorised access and unauthorised release. Annex A 5.33 applies to all organisational records, while IT.DET-01.1 covers only event logs but is more prescriptive about the protections required.
This control partially meets A.8.15.
IT.DET-01.1 requires event logs to be protected from unauthorised access, modification or deletion, including by encrypting them in transit and at rest and securing the systems and accounts used to store, manage and analyse them. This is a specific implementation of the protection 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-01.1 addresses protection only but is more prescriptive about how it is achieved.
This control supports A.5.28.
IT.DET-01.1 requires event logs to be protected from unauthorised access, modification or deletion, including through encryption and by securing the systems and accounts that store and manage them. Protecting logs in this way preserves their integrity and availability, which supports the preservation of evidence related to information security events required by Annex A 5.28. Annex A 5.28 requires procedures for identifying, collecting, acquiring and preserving evidence, which IT.DET-01.1 does not itself establish.
ASD Essential Eight: 4 mappings
This control partially overlaps E8-AC-ML2.6.
IT.DET-01.1 requires event logs to be protected from unauthorised access, modification or deletion, including by encryption; E8-AC-ML2.6 (application control) requires event logs to be protected from unauthorised modification and deletion, a subset of that.
This control partially overlaps E8-AH-ML2.13.
IT.DET-01.1 requires event logs to be protected from unauthorised access, modification or deletion, including by encryption; E8-AH-ML2.13 (user application hardening) requires event logs to be protected from unauthorised modification and deletion, a subset of that.
This control partially overlaps E8-MF-ML2.7.
IT.DET-01.1 requires event logs to be protected from unauthorised access, modification or deletion, including by encryption; E8-MF-ML2.7 (multi-factor authentication) requires event logs to be protected from unauthorised modification and deletion, a subset of that.
This control partially overlaps E8-RA-ML2.8.
IT.DET-01.1 requires event logs to be protected from unauthorised access, modification or deletion, including by encryption; E8-RA-ML2.8 (restrict administrative privileges) requires event logs to be protected from unauthorised modification and deletion, a subset of that.
ASD Information Security Manual: 2 mappings
This control partially overlaps ISM-1984.
IT.DET-01.1 requires event logs to be protected from unauthorised access, modification or deletion, including encryption in transit and at rest; ISM-1984 requires event logs sent to central logging to be encrypted in transit with ASD-approved cryptography, the in-transit part.
This control partially overlaps ISM-1985.
IT.DET-01.1 requires event logs to be protected from unauthorised access, modification or deletion, including encryption and securing the systems and accounts that handle them; ISM-1985 requires event logs to be protected from unauthorised access, covering only the access part.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.