ASD ISM 0488 Use forced commands for SSH without passwords
What it says
If using remote access without the use of a password for SSH connections, the 'forced command' option is used to specify what command is executed and parameter checking is enabled.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishEnsure SSH without passwords uses specific commands and checks parameters for security.
This control ensures that when people or systems connect remotely to your computer network without typing a password, they can only run specific, pre-approved actions. This is important because if someone manages to break in, they can't use the open connection to cause harm unless they do something we've already allowed. It's like giving someone a key to enter your business, but making sure all the important rooms are still locked.
Free. Save your status, tasks and notes.
Why it matters
Without SSH forced commands and parameter checking for key-based logins, a stolen key can be used to run arbitrary commands and escalate access on the host.
How to implement
IT team should configure the SSH server to enforce 'forced commands' on the user accounts used for remote connections.
This involves setting up specific rules on the server that specify which commands can be executed when this type of connection is made.
The IT manager should update organisational policies to include the use of 'forced commands' for any SSH access that doesn't require a password.
This means adding a requirement for these rules in any documents that cover remote access procedures.
IT staff should regularly review and update the list of allowed commands for SSH connections.
They can do this by accessing the server, checking the configuration files where these commands are listed, and ensuring they still align with what's needed for business operations.
The system owner should hold a workshop with the IT team to understand what tasks require SSH access without passwords and design the forced command scripts accordingly.
This involves discussing which operations need automated access and what commands should be authorised during these sessions.
Supervisors should work with the IT team to ensure any new SSH keys generated for passwordless access automatically apply forced commands.
This involves creating a checklist or process document that reminds staff how to set up these commands whenever they create a new key.
Keep it running
Regularly audit `authorized_keys` for `command="..."` and validate parameter checking; alert on any key-based access that lacks a forced command restriction.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
The server configuration file: Request the file that dictates SSH behaviour on the server.
Look at
The specific sections that define forced commands for SSH keys.
Good evidence
Would display clear command restrictions tied to specific user accounts.
- Check 2 of 5What an auditor asks for
Ask for
Procedural documents on remote access: Request organisational policies describing the use of forced commands.
Look at
Sections that explicitly mention passwordless SSH usage.
Good evidence
Shows that forced commands are a standard part of the practice.
- Check 3 of 5What an auditor asks for
Ask for
Logs showing SSH access: Request logs from the SSH server.
Look at
Timestamps and user accounts to verify that only pre-defined commands were executed.
Good evidence
Shows recorded activity matching authorised operations only.
- Check 4 of 5What an auditor asks for
Ask for
Notes from a recent forced command review: Request documentation from meetings where forced commands were evaluated.
Look at
Agendas, discussion points, and outcomes.
Good evidence
Includes identified improvements and action items noted during the meeting.
- Check 5 of 5What an auditor asks for
Ask for
A demonstration of SSH setup on a test environment: Request to see how forced commands are implemented during the key setup process.
Look at
The demonstration of setting up a key with specific forced commands.
Good evidence
Shows a test user only executing approved commands.
Mappings
Closest match in ISO/IEC 27001: A.8.3, Restrict access to information and assets, which this control partially meets.
ISO/IEC 27001: 2 mappings
This control partially meets A.8.3.
ISM-0488 requires restricting SSH key-based remote access by enforcing a specific command and validating parameters to prevent unauthorised or unintended actions. Annex A 8.3 requires restricting access to information and associated assets according to the organisation's access control policy. This policy-driven approach can include constraining what actions a remote access method permits. While Annex A 8.3 is higher-level and broader, ISM-0488 is a concrete SSH configuration pattern implementing the least privilege for remote access actions.
This control partially meets A.8.5.
ISM-0488 addresses secure use of SSH authentication without passwords by constraining authorised SSH key usage to a forced command and checking parameters. Annex A 8.5 requires secure authentication technologies and procedures based on access restrictions, which inherently includes safely-scoped authentication mechanisms for remote administration. Both controls aim for secure authentication, but Annex A 8.5 is broader across different methods and procedures while ISM-0488 specifies key-based SSH access.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.