In this ultimate how to implement guide to ISO 27001 Annex A 8.19 Installation of Software on Operational Systems, you will learn directly from an ISO 27001 Lead Auditor:
Table of contents
- 1. Establish a Formal ‘Approved Software’ Repository
- 2. Remove Local Administrative Rights
- 3. Enforce Application Whitelisting
- 4. Segregate Development and Production Libraries
- 5. Implement Mandatory Staging Verification
- 6. Define Rollback Procedures
- 7. Verify Package Integrity
- 8. Retain Strict Change Logs
- 9. Prohibit ‘Live’ Patching
- 10. Conduct Post-Installation Audits
1. Establish a Formal ‘Approved Software’ Repository
Control Requirement: Only authorised and tested software must be installed on operational systems.
Required Implementation Step: Create an internal package repository (e.g., Artifactory, internal Apt/Yum mirror) containing only vetted versions of required libraries and binaries. Configure all production servers to pull updates exclusively from this internal source, blocking direct internet access to public repositories like Docker Hub or NPM.
Minimum Requirement: Production servers cannot reach public software repositories directly.
2. Remove Local Administrative Rights
Control Requirement: Users should not have the privileges to install arbitrary software.
Required Implementation Step: Audit all user accounts on operational systems and revoke `sudo` or Local Admin access for standard users and developers. Implement a Privileged Access Management (PAM) solution (or simple `sudoers` file restrictions) that strictly limits installation commands to specific system administrators.
Minimum Requirement: Developers cannot execute `apt-get install` or `msiexec` on production servers.
3. Enforce Application Whitelisting
Control Requirement: The execution of unauthorised software must be technically prevented.
Required Implementation Step: Configure Windows AppLocker, WDAC, or Linux fapolicyd to block the execution of any binary or script that does not originate from a trusted path or possess a valid corporate digital signature. Set the policy to “Audit” initially, then move to “Enforce”.
Minimum Requirement: An unknown `.exe` or binary copied to the server fails to launch.
4. Segregate Development and Production Libraries
Control Requirement: Operational systems must not contain compilers or development tools.
Required Implementation Step: Strip production images of all build tools (GCC, Make, Maven) and debugging utilities. Ensure that the software deployed is the compiled binary/artifact only, not the source code requiring local compilation.
Minimum Requirement: Typing `gcc –version` on a production server returns “Command not found”.
5. Implement Mandatory Staging Verification
Control Requirement: Software must be tested in a mirror environment before production installation.
Required Implementation Step: Enforce a strict release pipeline where software updates are automatically deployed to a Staging environment first. Require a “burn-in” period or automated regression test pass confirmation before the release pipeline permits promotion to Production.
Minimum Requirement: Evidence exists that the exact binary version running in Prod was first run in Staging.
6. Define Rollback Procedures
Control Requirement: Unsuccessful installations must be reversible to maintain availability.
Required Implementation Step: Script a rollback action for every deployment (e.g., `kubectl rollout undo` or swapping symbolic links to the previous build directory). Verify that the rollback mechanism works before approving the change ticket.
Minimum Requirement: A tested command or script to revert the installation exists before deployment starts.
7. Verify Package Integrity
Control Requirement: The authenticity of the software must be verified to prevent supply chain attacks.
Required Implementation Step: Configure installation scripts to verify GPG signatures or SHA-256 checksums of all packages against the vendor’s official publication before installation. Fail the pipeline immediately if a hash mismatch occurs.
Minimum Requirement: Installation aborts automatically if the package signature is invalid.
8. Retain Strict Change Logs
Control Requirement: Every software installation must be traceable to an authorised change request.
Required Implementation Step: Ensure your configuration management tool (Ansible, Chef, Puppet) logs every package installation event to a centralised logging server. Correlate these logs with Change Management tickets to identify “shadow IT” installations.
Minimum Requirement: You can identify exactly who authorised the installation of `htop` on Server A.
9. Prohibit ‘Live’ Patching
Control Requirement: Updates should be applied via image replacement, not live patching, where possible (Immutable Infrastructure).
Required Implementation Step: Adopt an immutable infrastructure pattern where software updates are achieved by deploying a new server image (AMI/Container) rather than running update commands on a live server. This ensures consistency and eliminates configuration drift.
Minimum Requirement: Uptime on servers is low (e.g., <30 days) because they are cycled for updates rather than patched live.
10. Conduct Post-Installation Audits
Control Requirement: Verify that the installation did not introduce unintended files or permissions.
Required Implementation Step: Run a File Integrity Monitoring (FIM) scan immediately after installation to verify that only the expected files were modified. Alert the security team if system binaries were altered during the application update.
Minimum Requirement: FIM alerts trigger if an update modifies `/etc/passwd` or system32.
About the author
