ASD ISM 1449 Protect SSH private keys with passwords or encryption
What it says
SSH private keys are protected with a password or a key encryption key.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishEnsure SSH keys have a password or are encrypted to prevent unauthorised access.
SSH private keys are like the master keys for accessing your computer systems remotely. If these keys fall into the wrong hands, someone could break in and control your systems. Protecting these keys with passwords or encryption is crucial to keep your digital doors locked and prevent unauthorised access.
Free. Save your status, tasks and notes.
Why it matters
If SSH private keys are not protected with a passphrase or encryption, attackers can steal them and gain remote access, leading to compromise and data loss.
How to implement
IT team should ensure every SSH private key is secured: Require that all SSH keys used within the organisation are either password-protected or encrypted.
This can be done by configuring the key generation process to include a passphrase, which can be a memorable but complex password.
System administrators must regularly audit key access: Regular checks should be conducted to verify which team members have access to SSH keys and ensure they are aware of the importance of protecting them with passwords.
Use an inventory tool to list all keys and their current security status.
Management should promote strong passphrase policies: Educate employees on creating strong, memorable passwords for SSH keys.
Encourage using a combination of letters, numbers, and symbols, and recommend password managers to store them securely.
Procurement or IT should source secure storage solutions: Invest in hardware or software solutions that securely store and manage SSH keys.
This can include encrypted USB devices or key management systems that store passwords securely.
Policy makers need to define and document SSH key handling policies: Create comprehensive policies that define how SSH keys should be generated, stored, and used.
Ensure these policies are reviewed and updated regularly, and communicate them to all relevant team members.
Keep it running
Audit where SSH private keys are stored and enforce passphrases or key encryption; restrict file permissions and rotate keys when exposure is suspected.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
Documentation on SSH key management policies: Request to see the written policies that describe how SSH keys are managed and protected.
Look at
Whether these policies specify password or encryption requirements. Good evidence shows clear guidelines and approved procedures.
- Check 2 of 5What an auditor asks for
Ask for
A current inventory of SSH keys: Request a list of all SSH keys currently in use within the organisation.
Look at
The protection status of each key (password-protected or encrypted).
Good evidence
Shows each key with a corresponding protection status.
- Check 3 of 5What an auditor asks for
Ask for
Training records for SSH key handling: Request evidence of any training sessions conducted on SSH key management.
Look at
Attendance records and training content.
Good evidence
Includes recent training sessions with thorough coverage of password protection or encryption topics.
- Check 4 of 5What an auditor asks for
Ask for
A demonstration of SSH key creation: Request a step-by-step demonstration of how new SSH keys are created, focusing on the inclusion of passwords or encryption.
Look at
The process and steps taken to ensure security.
Good evidence
Shows secure processes with a clear emphasis on protection.
- Check 5 of 5What an auditor asks for
Ask for
Logs of key usage audits: Request records of recent audits or checks on SSH key usage and protection.
Look at
Any noted issues and resolutions.
Good evidence
Includes regular audit logs with resolved issues and documented corrective actions.
Mappings
Closest match in ISO/IEC 27001: A.8.24, Effective use of cryptography and key management, which this control partially meets.
ISO/IEC 27001: 2 mappings
This control partially meets A.8.24.
ISM-1449 requires SSH private keys to be protected with a password (passphrase) or encrypted with a key encryption key to prevent unauthorised use if the key file is obtained. ISO/IEC 27001:2022 Annex A 8.24 requires rules for effective use of cryptography and cryptographic key management to be defined and implemented, which would include protecting private keys (including SSH keys) and managing how they are encrypted and stored. ISM-1449 is a specific technical requirement for one key type, whereas Annex A 8.24 is broader across all cryptographic keys and lifecycle management.
This control partially overlaps A.5.17.
ISM-1449 requires SSH private keys to be protected with a password or encryption so that possession of the key file alone is insufficient for authentication. ISO/IEC 27001:2022 Annex A 5.17 requires authentication information to be allocated and managed under a controlled process, including guidance on appropriate handling of secrets. They overlap because SSH private key passphrases (and any key-encryption credentials) are a form of authentication information that must be handled securely, but Annex A 5.17 is process-focused and covers many credential types beyond SSH keys.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.