Implementing ISO 27001 Annex A 8.18 requires stringent controls over powerful utility programs that can override system security. This control mandates the segregation of privileged tools, removal of compilers from production, and the enforcement of Just-In-Time (JIT) access with strict logging. The primary business benefit is preventing unauthorized system manipulation and insider threats by limiting the attack surface of administrative tools.
ISO 27001 Annex A Use of privileged utility programs Implementation Checklist
Use this implementation checklist to achieve compliance with ISO 27001 Annex A 8.18. This control mandates strict restrictions and controls over utility programs that are capable of overriding system and application controls, such as database editors, disk tools, and network sniffers.
1. Create a Restricted Utility Inventory
Control Requirement: You must identify and list all software capable of overriding system controls.
Required Implementation Step: Audit your server builds and administrative workstations to create a definitive list of “Privileged Utilities.” This includes database management tools (e.g., SSMS, pgAdmin), disk editors, packet sniffers (Wireshark), and debugging tools. Explicitly classify these as “Restricted.”
Minimum Requirement: A maintained register of tools that can bypass application logic exists.
2. Remove Utilities from Operational Systems
Control Requirement: Privileged utilities should not be installed on production systems unless absolutely necessary.
Required Implementation Step: Harden your production server images (Gold Images) by stripping out compilers (`gcc`, `make`), debuggers, and unnecessary shells. Ensure that maintenance tools reside only on a secured “Jump Box” or Bastion Host, never on the production database server itself.
Minimum Requirement: Compilers and debuggers are technically absent from the Production environment.
3. Enforce Just-In-Time (JIT) Access
Control Requirement: Access to privileged utilities must be limited to the duration of the specific task.
Required Implementation Step: Implement a Privileged Access Management (PAM) solution (like Teleport or CyberArk) that grants access to the utility for a specific time window (e.g., 2 hours) linked to a change ticket. Revoke access automatically when the window expires.
Minimum Requirement: Standing “always-on” access to root-level utilities is disabled.
4. Segregate Execution Environments
Control Requirement: Utilities must be run in a controlled environment to prevent cross-contamination or accidental damage.
Required Implementation Step: Execute privileged utilities from a dedicated, hardened management VLAN or Citrix session that is isolated from the internet (no email, no web browsing). This prevents malware from an admin’s laptop from riding the privileged session into the core network.
Minimum Requirement: Admin tools are run from a dedicated, isolated management subnet.
5. Mandate Strong Authentication (MFA)
Control Requirement: Identity verification must be rigorous before launching a privileged tool.
Required Implementation Step: Configure the utility or the server hosting it to require Multi-Factor Authentication (MFA) at the point of launch or login. Relying on the initial workstation login is insufficient; the specific high-risk action requires re-authentication.
Minimum Requirement: Launching a production DB tool triggers an MFA prompt.
6. Implement Command-Level Logging
Control Requirement: The use of utility programs must be logged to a forensic level.
Required Implementation Step: Configure `auditd` (Linux) or PowerShell Script Block Logging (Windows) to capture the exact commands entered within the utility. Ship these logs instantly to an immutable SIEM bucket to prevent the admin from wiping their own tracks.
Minimum Requirement: You can retrieve the exact SQL query or command executed by the utility 30 days later.
7. Enforce Segregation of Duties
Control Requirement: Authorisation to use a utility should be separate from the user of the utility.
Required Implementation Step: Ensure that the person requesting access to the utility (e.g., to fix a corrupt database) is different from the person authorising the access. Use a “Four-Eyes Principle” where a second engineer must digitally approve the session before the tool launches.
Minimum Requirement: No engineer can authorise their own access to privileged utilities.
8. Define Specific Procedures for Use
Control Requirement: Usage of these tools must be governed by documented procedures to avoid ad-hoc changes.
Required Implementation Step: Write specific Runbooks for permitted tasks (e.g., “Database Schema Repair Procedure”). Ad-hoc usage of utilities outside of these defined procedures must be treated as a security incident and investigated.
Minimum Requirement: Usage of a privileged tool is linked to a specific, documented procedure.
9. Change Default Passwords Immediately
Control Requirement: Default credentials for utility programs must be changed to prevent trivial compromise.
Required Implementation Step: Scan all utility programs for default accounts (e.g., “sa” in SQL, default web console logins). Rotate these credentials to complex, vault-stored values immediately upon installation.
Minimum Requirement: No utility program retains its factory default password.
10. Verify Utility Integrity
Control Requirement: Ensure the utility software itself hasn’t been tampered with.
Required Implementation Step: Periodically verify the cryptographic hash (SHA-256) of the utility binaries against the vendor’s known good baseline. This detects if a “backdoor” version of a tool (like a compromised SSH client) has been swapped in.
Minimum Requirement: Automated checks alert if the binary hash of a privileged tool changes.
ISO 27001 Annex A 8.18 SaaS / GRC Platform Implementation Failure Checklist
| Control Requirement | The ‘Checkbox Compliance’ Trap | The Reality Check |
|---|---|---|
| Inventory | SaaS tool lists “Microsoft Office” as software. | The tool ignores `nmap`, `wireshark`, and `metasploit` installed on the SysAdmin’s laptop. |
| Access Control | SaaS tool checks “Is there an Access Policy?”. | The root password for the production database is saved in the “Favorites” of the Admin tool, bypassing auth. |
| Logging | SaaS tool verifies “Logging is Enabled”. | The logs capture “User logged in”, but fail to record that they ran `DROP TABLE users;` using the utility. |
| Segregation | SaaS tool asks “Are duties separated?” (Yes/No). | The Lead Developer approves their own request to access the production DB tool to “fix a bug” at 2 AM. |
| Installation | SaaS tool checks “Is antivirus installed?”. | Compilers (`gcc`) are present on the production web server, allowing an attacker to build malware locally. |
| Network Isolation | SaaS tool assumes VPN equals security. | The Admin tool connects directly from a malware-infected home laptop over VPN to the core database port. |
| Default Passwords | SaaS tool scans for weak user passwords. | The management console for the backup utility is still accessible via `admin/admin` on the internal network. |
DO IT YOURSELF ISO 27001
STOP SPANKING £10,000s on CONSULTANTS and ISMS ONLINE PLATFORMS
About the author
