ISA99 continues to churn out quality security documents. Some are written to be ISA/ANSI/IEC standards and others are Technical Reports for guidance. Recently a draft of ISA-TR62443-2-3: Patch Management in the IACS Environment was released for review.
Loyal readers likely don’t need this information because the topic has been discussed for years, but the average ICS owner/operator who is beginning to work on security is struggling with security patching and looking for guidance and good security practices.
Section 5 lists the asset owner requirements in security patching. It does an excellent job in describing and requiring an inventory of “updateable devices”. Documenting what software is running on each device and feeding this into the security patch process is key. Security patching is much more than simply applying Microsoft patches. There are component patches (JRE), 3rd party app patches (web server, database), and patches for the ICS application itself.
Where Section 5 falls down is on prioritization of security patches and phased deployment. There is more information in Appendix B4.3.3, but even that is lacking at this point in the draft. I could write a long section on this, but two important points that weren’t there:
- Prioritized Patching List – It’s a sad fact that many ICS organizations are just beginning security patching efforts and trying to accomplish this across all systems tends to fail. We recommend owner/operators determine what systems are most at risk and focus the initial security patching effort on those systems. For example systems in the ICS DMZ and ICS network systems that are accessible from any external network or the ICS DMZ. If that is too much for a first bite, the prioritized patching list can be further tightened to the services accessible from external networks. This is a lot more practical than evaluating patch by patch.
- Consider Insecure By Design – If the component is insecure by design, patching even a serious issue will do little to improve the security posture. Why do vendors even bother patching systems that can be compromised using a feature.
Section 6 covers the Product Supplier Requirements. It is brief, and the most interesting part is it sets a 30-day window for vendor action on applicable patches.
Section 7 and Appendix A define an XML Schema Definition for vendors to provide Vendor Patch Compatibility information. Will this catch on and is it worth the effort? At least it gives vendors guidance on what information should be provided to their customers.
Most readers should skip straight to Appendix B – IACS Asset Owner Guidance on Patching. Free from the IEC formatting restrictions, this Appendix provides practical advice from start to finish on this process.
The standards making process tends to prevent any strong statements or controls. For example from Section 4:
Some extremely critical systems may have no allowed outage windows available, and can therefore not be patched.
Applying patches is a risk management issue. If the cost of shutdown to apply patches is greater than the risk evaluated cost, then the patch may be delayed, especially if there are other security controls in place that mitigate the risk (such as no internet access from the system).
The idea that it is acceptable for “extremely critical systems” to have no outage window for patching or other component maintenance is flawed. If bringing a component (server/workstation) down for maintenance, not the process, puts an ICS at risk then there is a lack of redundancy and robustness in the system. The danger is an owner/operator not wanting to apply security patches now has an out from a reputable ICS security standards organization — and “such as no internet access” as a security control that mitigates the risk … we would be in for a professional liability claim if we gave that advice.
ISA99 is soliciting comments on this and other drafts. It’s an open process, and they want your input.
Image by ceci un matt