Do you know your patch compatibility?
A pending ISA99 technical report defines a standard XML format for automation vendors to publish patch compatibility information.
Managing dozens of software applications on dozens of servers with supporting software elements, such as browsers, office tools, and virus protection can be an overwhelming task. There are numerous compatibility issues for patches and updates from multiple vendors. On the first Tuesday of every month, Microsoft releases a new set of OS (operating system) and application patches, and automation vendors start testing the supported versions of their software against the patches.
Other vendors also release their patches and updates regularly or as needed. Virus updates may come out several times a week; database patches and updates may be released every few months; automation application patches and updates may be released quarterly. Manufacturing IT staff need to keep track of all these changes and all the compatibility dependencies across all of their applications. For example, your vendor’s HMI may require a specific version and minimum patch level for an OS, your data historian may require a different patch version, and your database may require a different maximum patch level. It can be a fulltime job just collecting the compatibility information from all of your vendors and building a compatibility network.
Managing patch and update compatibility across vendors is difficult, but managing patch and update compatibility within a vendor suite can be even more complicated. Most of the large automation vendors have constructed application suites by buying software companies and collecting the software into a commonly named suite, even if the software doesn’t integrate. It’s not uncommon to hear “… well, that version of the HMI doesn’t work with the latest version of our database” from your vendor’s support staff.
Because of compatibility issues, many organizations will get one application and operating system configuration working and then will not install any new patches or updates. While this strategy minimizes your support effort, it does add a significant amount of risk.
The ISA99 committee on industrial automation security is working on solutions to the problems of patch management in industrial systems. One new work product of the committee is a pending technical report that defines a standard XML format for vendors to publish their patch compatibility information.
Vendors currently publish the information in PDF files, spreadsheets, databases, and Microsoft Word documents. The formats for publication are not common, and it is sometimes difficult, if not impossible, to find detailed information on: what was tested for compatibility; if testing is planned; and the results of the tests (success and failure). The ISA99 patch compatibility format addresses these issues.
Each vendor would provide a set of patch compatibility files for their products. Each file identifies the vendor’s product and version, the patch that was tested, and the test results. Patches are identified by the patch vendor’s name (such as Microsoft, Adobe or Oracle), the patch ID (which in the case of Microsoft is Patch KB-Number), the version of the patch, and the release date of the patch. The test results can specify if the patch applies to the vendor’s product, if a test was performed or is still in progress, and test results.
When vendors provide this information in a common format, it is possible to construct a compatibility network that shows the impact of implementing a patch or update on all of your systems. Vendors that provide this information across their own suite will also reduce their support and service calls.
In patch management, knowing compatibility dependencies helps you make intelligent decisions about what to patch and when to update. Ask your vendors to support the new format and make your job easier.