ASD ISM 1895 Log single-factor authentication events
What it says
Successful and unsuccessful single-factor authentication events are centrally logged.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishKeep track of successful and unsuccessful single-factor login attempts.
This control is all about keeping a record of when someone successfully logs in or fails to log in using a single-factor method, like just a password. It matters because keeping track of these events helps to identify suspicious activities, like repeated failed login attempts, which could indicate that someone is trying to break into your system.
Free. Save your status, tasks and notes.
Why it matters
Without central logging of successful and failed single-factor authentication events, suspicious access attempts can go undetected, increasing breach risk.
How to implement
The IT team should set up a central logging system to capture all login attempts.
They should ensure that each login attempt, whether successful or unsuccessful, is sent to this logging system for centralised tracking.
A manager responsible for IT should regularly review these logs for unusual patterns, like multiple failed attempts from the same user or location.
They can set up alerts that notify a designated person when such patterns occur.
System owners must ensure their systems are configured to send login event data to the central logging system.
This may involve updating software settings to enable logging as required by this control.
The IT team should train staff on recognising phishing attempts since these can lead to failed logins if credentials are stolen and misused.
Provide practical examples and updates on what to look out for.
The procurement team should ensure any new software or system purchases have the capability to support logging of authentication events.
This sometimes requires liaising with vendors to confirm logging features are present and adequate.
Keep it running
Centrally collect successful and failed single-factor authentication logs and review them weekly for patterns such as repeated failures or logins from unusual sources.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
The logs from the central logging system: Request to see the logs that record successful and unsuccessful single-factor login attempts.
Look at
Whether all systems are consistently sending information to this central log.
Good evidence
Is logs displaying entries from all relevant systems with timestamps and user details.
- Check 2 of 5What an auditor asks for
Ask for
Alert settings documentation: Request to see how alerts are configured within the logging system for failed login attempts.
Look at
Details on thresholds and escalation procedures.
Good evidence
Shows clearly defined alerts and an escalation procedure for responding to suspicious activity.
- Check 3 of 5What an auditor asks for
Ask for
Evidence of regular log reviews: Request documentation or confirmation of periodic log reviews.
Look at
Logs of reviews with noted findings or actions taken.
Good evidence
Is a regular schedule of reviews that staff sign off on, noting actions taken if any incidents were found.
- Check 4 of 5What an auditor asks for
Ask for
Training materials on phishing and login security: Request documents or recordings used for staff training sessions.
Look at
How clearly these materials explain the importance of securing login credentials.
Good evidence
Includes clear, understandable training that is periodically updated.
- Check 5 of 5What an auditor asks for
Ask for
Procurement evaluation documents: Request information on how authentication logging was assessed for incoming systems.
Look at
Evaluation criteria or vendor communications about logging capabilities.
Good evidence
Shows a consistent process ensuring all systems evaluated have the necessary logging features.
Mappings
Closest match in ISO/IEC 27001: A.8.15, Logging of activities and events, which this control partially meets.
ISO/IEC 27001: 1 mapping
This control partially meets A.8.15.
ISM-1895 requires central logging of successful and unsuccessful single-factor authentication events. ISO/IEC 27001:2022 Annex A 8.15 requires logs of activities, exceptions, faults and other relevant events to be produced, stored, protected and analysed, which encompasses authentication event logging as one type of relevant event. ISM-1895 is therefore a specific application of the broader logging control in Annex A 8.15, with a tighter focus on single-factor authentication outcomes and centralisation.
ASD Essential Eight: 2 mappings
This control partially overlaps E8-MF-ML2.6.
ISM-1895 requires successful and unsuccessful single-factor authentication events to be centrally logged. E8-MF-ML2.6 requires the same central logging outcome but specifically for multi-factor authentication success and failure events. They overlap on the intent and logging pattern (central capture of auth outcomes), but differ in scope because ISM-1895 is about single-factor authentication while E8-MF-ML2.6 is about MFA.
This control partially overlaps E8-RA-ML2.6.
ISM-1895 requires central logging of successful and unsuccessful single-factor authentication events. E8-RA-ML2.6 focuses on centrally logging privileged access events, which can include privileged logons and session elevation activities. The controls overlap where privileged access is granted via single-factor authentication and those authentication outcomes are part of privileged access logging, but E8-RA-ML2.6 is broader in covering privileged activity beyond authentication outcomes.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.