ASD ISM 1936 Prevent usage of sIDHistory in user accounts
What it says
The sIDHistory attribute for user accounts is not used.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishEnsure user accounts do not use the sIDHistory attribute for security purposes.
The sIDHistory is a technical feature in computer systems that helps during migrations by retaining old permissions. However, keeping it can become a backdoor for hackers. If we don't switch this off, unauthorised people might sneak into secure areas of our systems, leading to data breaches or disruptions.
Free. Save your status, tasks and notes.
Why it matters
If sIDHistory is populated, attackers can abuse inherited legacy SIDs to escalate access and access data, leading to unauthorised changes, data breaches and service disruption.
How to implement
The IT team should review all user accounts on the system.
They need to check if any account uses the sIDHistory attribute, which is a way of carrying over old permissions. They can do this by using administrative tools specific to Microsoft Active Directory to list all attributes of user accounts.
System administrators should remove the sIDHistory from accounts that no longer need it.
This means carefully evaluating each account and using the Active Directory Users and Computers tool to delete the sIDHistory attribute where it's present.
Managers should ensure that system migrations are thoroughly planned to avoid the need for sIDHistory.
During migration planning meetings, discuss how to handle permissions without relying on sIDHistory and document the process in migration plans.
HR and IT should coordinate to update user account permissions when employees change roles or leave the organisation.
Ensure that staff are aware of the importance of updating accounts instantly to avoid relying on outdated sIDHistory settings.
Security teams should conduct regular security audits to check for sIDHistory usage.
This involves scheduling routine checks every six months using scripts or software to automatically flag accounts using sIDHistory and report them for review.
Keep it running
After migrations, verify sIDHistory is blank on all user accounts and enforce a process to prevent future population. Monitor AD changes and periodically report any non-empty sIDHistory values.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
A recent user account audit report: Request documentation that lists all user accounts and any usage of the sIDHistory attribute.
Look at
Accounts listed with this attribute still active.
Good evidence
Is a dated report with no accounts showing active sIDHistory attributes.
- Check 2 of 5What an auditor asks for
Ask for
Evidence of account migration plans: Request to see documented plans from recent system migrations.
Look at
Clear steps on managing user permissions without sIDHistory.
Good evidence
Includes a detailed plan with steps and alternatives used instead of sIDHistory.
- Check 3 of 5What an auditor asks for
Look at
Automated processes or manual procedures that check account attributes regularly.
Good evidence
Would show an active tool in place with recent checks logged.
- Check 4 of 5What an auditor asks for
Ask for
The policy on roles and permissions update: Request the organisational policy that outlines roles and permissions management. Ensure it specifies that sIDHistory should not be used and outlines steps taken upon role changes.
Good evidence
Is a clear, written policy specifically prohibiting sIDHistory use.
- Check 5 of 5What an auditor asks for
Ask for
Records of training sessions on this topic: Request evidence of staff training on the importance of managing sIDHistory appropriately.
Look at
Attendance logs, session materials, or summaries.
Good evidence
Includes records of recent sessions with clear emphasis on the risks of sIDHistory.
Mappings
Closest match in ISO/IEC 27001: A.5.15, Access control policies and procedures, which this control partially meets.
ISO/IEC 27001: 3 mappings
This control partially meets A.5.15.
ISM-1936 addresses a specific logical access control weakness by requiring organisations not to use the sIDHistory attribute on user accounts. This aligns with Annex A 5.15 because prohibiting sIDHistory use is an implementation-level rule that would sit under an organisation's logical access control policies and procedures. Annex A 5.15 is broader, requiring establishment of access control rules generally, whereas ISM-1936 prescribes one particular rule for AD identity security.
This control partially meets A.8.2.
ISM-1936 requires that Active Directory user accounts do not use the sIDHistory attribute, reducing the risk of unintended or covert privilege inheritance through SID mapping. This relates to Annex A 8.2 because disabling/avoiding sIDHistory is a specific technical measure that helps restrict and manage privileged access rights in identity systems. Annex A 8.2 is broader and covers governance and controls for privileged access allocation and use across systems, not just sIDHistory in AD.
This control partially meets A.8.3.
ISM-1936 requires that sIDHistory is not used for user accounts, which helps prevent access being granted through historical identifiers rather than current authorised identities. This relates to Annex A 8.3 because removing/avoiding sIDHistory helps ensure access is restricted according to defined access control policy, not expanded through hidden SID-based paths. Annex A 8.3 is broader and applies to restricting access to information assets in general, while ISM-1936 is a targeted control for a specific AD mechanism.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.