Patch testing is an integral part of the industrial patch management process. The asset owners maintain an identical lab to test the patches and observe the changes and behavior of the asset before approving it for the final deployment.
Before installing security patches, the owner/operator must test and qualify them in a quality assurance environment. This includes live data feeds and interaction between other system components, operators, and operating procedures.
The asset owners sometimes face the challenge of not having a testing environment, they can adopt the methodology to test the patches on secondary systems with a clear roll-out plan to ensure the least impact on the production environment.
This includes the following processes:
- Patch Testing Process: It includes Patch file authenticity, Review changes, Installation procedure, Qualification & verification, Removal procedure, and Risk mitigation.
- Determining Patch File Authenticity: it is important to authenticate the patch files before installing or testing them. For this, you can determine the patch source, verify the file size, checksum, and digital signature, and scan the patch for viruses.
- Installation Procedure: The installation process requires checking the technical notes and platform information, product supplier installation instructions, identification of prerequisites, identifying target devices and testing samples, and installing a patch for creating a new environment.
- Patch Qualification and Validation: As part of their qualification process, the asset owner might rely upon iterative testing phases performed by different groups.
- Review Functional and Security Changes from Patches This allows you to verify if the patch has affected the IACS device’s functionality, operability, or reliability. It included:
-
- Effects on system reliability
- Effects on system performance
- Effect on fault-tolerance capabilities or redundancy
- If the critical component is operational, will the patch be installed?
- Ability to roll back the patch in the event of unforeseen effects
In case the above cannot be performed alternative risk mitigation strategies can be adopted to reduce the attack surface.
Risk Mitigation Alternatives: If the patch isn’t installed, but the security vulnerability persists, several options exist to mitigate the security risks: like:
- Reconfiguring a product
- Remove or disable the vulnerable component or feature that requires the patch; remove affected software.
- The patch is required to disable the startup of the vulnerable service.
- Network filtering controls, intrusion detection systems (IPS), rules and signatures, program and executable access control, and security policies that include technical support solutions are all possible.
- Based on cost and business justification, investigate the possibility of replacing the vulnerable device.
- Secure outbound gateways that are only accessible to authorized personnel with strong access controls