ASD ISM 1249 Limit server application user privileges
What it says
Server applications are configured to run as a separate user account with the minimum privileges needed to perform their functions.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishServer apps must run separately with only the necessary permissions to operate.
This control is about making sure that any software running on your server doesn't have more power than it needs. If an application has too many permissions, a hacker could exploit these and cause damage or access sensitive information. By keeping permissions to the bare minimum, we limit what harm can be done if there's a breach.
Free. Save your status, tasks and notes.
Why it matters
If server apps run with excessive privileges or shared accounts, an attacker can escalate access, alter data, or disrupt services.
How to implement
System owners should create a separate user account for each server application.
This means asking your IT team to set up a specific account that is used only by that application. It should have the lowest level of access to get its job done-nothing more.
The IT team should review each application's functions to determine necessary permissions.
They need to document what the application actually needs to do, and configure the server accordingly, ensuring it can't access other data or functions.
Managers should schedule regular meetings with the IT team to review application user accounts.
These meetings can ensure that no extra permissions have been added over time and uphold the security processes you've put in place.
Procurement should ensure any new software clearly states its permission needs before purchase.
This prevents buying applications that demand excessive access, keeping your systems secure from the start.
The IT team should monitor server logs for unusual activities by application accounts.
They should use these logs to spot if an application suddenly starts doing more than it should, which might indicate an account has been compromised.
Keep it running
Run each server application under its own dedicated account; review granted rights and group memberships regularly and remove any no longer required.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
User account documentation: Request a list of all user accounts associated with server applications.
Look at
Accounts that indicate the application's specific, rather than general, usage.
Good evidence
List clearly separates application accounts from regular user accounts with defined roles.
- Check 2 of 5What an auditor asks for
Ask for
A permissions review report: Request a document that shows the permissions each application has.
Look at
Clear explanations justifying each permission granted. Good reports will show only necessary permissions, with no unexplained or broad privileges.
- Check 3 of 5What an auditor asks for
Ask for
Meeting notes from IT reviews: Request documentation of the regular meetings held to discuss application permissions.
Look at
Evidence that these meetings occur regularly with action items recorded. Good notes will reflect regular, proactive engagement with security practices.
- Check 4 of 5What an auditor asks for
Ask for
Logs showing account activity: Request server logs that show what application accounts have done recently.
Look at
Records of typical vs. unusual activities. Good logs highlight normal patterns, with any anomalies investigated promptly.
- Check 5 of 5What an auditor asks for
Ask for
Procurement records of new software: Request records of software evaluations pre-purchase.
Look at
Evidence that permission requirements were checked before purchase. Good records will align software function with its limited permissions on your server.
Mappings
Closest match in ISO/IEC 27001: A.8.2, Management of privileged access rights, which this control partially meets.
ISO/IEC 27001: 2 mappings
This control partially meets A.8.2.
ISM-1249 requires server applications to use separate user accounts and least privilege to perform their functions. Annex A 8.2 broadly requires privileged access rights to be restricted and managed, covering allocation, use, and governance of elevated permissions across the organisation. ISM-1249 is a specific service-account/run-time privilege control, while Annex A 8.2 encompasses processes beyond server applications.
This control partially meets A.8.3.
ISM-1249 requires that server applications run under separate accounts with only the permissions they need. Annex A 8.3 requires access to information and associated assets to be restricted in line with an access control policy, which includes controlling service and application access rights. ISM-1249 is focused on how server applications are configured at run time, whereas Annex A 8.3 is policy-driven and applies to all asset access.
ASD Essential Eight: 1 mapping
This control partially meets E8-RA-ML3.1.
ISM-1249 requires server applications to run under separate user accounts with only the minimum privileges required for their function. E8-RA-ML3.1 sets the broader requirement that privileged access for all users and services is limited to what is necessary to perform duties, which includes service accounts used by server applications. ISM-1249 is a specific implementation pattern, whereas E8-RA-ML3.1 covers privileged access more generally across systems, applications and data repositories.
ASD Essentials for enterprise IT: 1 mapping
- IT.PRO-12.3Provision user, administrative and non-person accounts with minimum required privilegesPartially overlaps
This control partially overlaps IT.PRO-12.3.
IT.PRO-12.3 requires user, administrative and non-person accounts to be provisioned with only the minimum access and privileges they need; ISM-1249 requires server applications to run as a separate user account with minimum privileges, a specific case for application accounts.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.