ASD ISM 1937 Weekly audit of sIDHistory in user accounts
What it says
User accounts are checked at least weekly for the presence of the sIDHistory attribute.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishCheck user accounts weekly to ensure they don't have the sIDHistory attribute.
This control is about regularly checking that the sIDHistory attribute is not present in user accounts within a Microsoft Active Directory. Ignoring this could allow unauthorised access or attacks that take advantage of old, previously removed permissions, putting your sensitive data at risk.
Free. Save your status, tasks and notes.
Why it matters
If sIDHistory is not audited weekly, legacy SIDs can remain on accounts and be used to inherit old permissions, enabling unauthorised access and data compromise.
How to implement
The IT team should schedule a weekly task to review user accounts.
They can do this by setting a calendar reminder to run a script that checks for the sIDHistory attribute on Active Directory accounts.
System administrators should use tools or scripts that are designed to identify the sIDHistory attribute.
They can often find these tools in security management software that they already use, like those recommended by the Australian Cyber Security Centre.
HR should coordinate with the IT team during employee offboarding.
This ensures that when someone leaves, their access is removed promptly, reducing the chance that sIDHistory can be misused.
IT Security Managers should document a procedure for dealing with accounts that still have the sIDHistory attribute.
This might involve immediate removal of the attribute and a review of any potential security issues caused.
Executives should ensure resources are allocated for regular training on this process.
This could mean budget for IT staff to stay up-to-date with Microsoft Active Directory best practices recommended by the Australian Signals Directorate.
Keep it running
Run a weekly query/report for non-empty sIDHistory on all user accounts, investigate any entries, and record results and remediation actions in your audit log.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
The most recent sIDHistory check report: This report should show when the last check was performed and the results.
Look at
The date to ensure it was done in the past week and note any accounts that had sIDHistory removed.
Good evidence
A regular log with no or very few accounts showing residual sIDHistory attributes.
- Check 2 of 5What an auditor asks for
Ask for
A list of all scripts or tools used.
Look at
The version and source of these tools to ensure they are up-to-date and come from trusted sources.
Good evidence
Certified or well-documented scripts from reliable vendors.
- Check 3 of 5What an auditor asks for
Ask for
The IT team's task schedule.
Look at
Their calendar or task management system to verify that the weekly checks are scheduled.
Good evidence
A recurring entry with more than two past completions.
- Check 4 of 5What an auditor asks for
Ask for
Incident response procedures related to sIDHistory.
Look at
The details of the procedures to ensure they include steps for removing the attribute and assessing any related incidents.
Good evidence
A clear, written procedure authorised by management.
- Check 5 of 5What an auditor asks for
Ask for
Training logs or certificates.
Look at
The dates and content of any training sessions on sIDHistory.
Good evidence
Evidence of recent, regular training sessions attended by relevant staff members.
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-1937 requires organisations to check Active Directory user accounts at least weekly for the presence of the sIDHistory attribute, which is a specific directory-attribute audit to detect privilege inheritance and persistence risks. ISO/IEC 27001:2022 Annex A 8.15 requires logs of relevant events to be produced, protected and analysed, which can include directory service and account-management/auditing events that help detect or investigate unauthorised changes related to sIDHistory. Annex A 8.15 is broader and logging-centric, while ISM-1937 is a specific operational identity control focused on detecting sIDHistory directly (not just via logs).
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.