ENISA Report on SCADA patch management - what is missing

Jan. 1, 2000

ENISA- the European Union Agency for Network and Information Security – issued a report on patching SCADA systems: “Window of exposure … a real problem for SCADA systems? Recommendations for Europe on SCADA patching” dated December 2013. To me, the report has several significant shortcomings starting with who was NOT involved in the development of this report as well as the apparent lack of understanding of what makes patching control systems unique. The ENISA document is correct in stating there will be a window of exposure. However, there are really two issues:

1)     What can be done to make the unpatched control system “invisible or inaccessible” so patching becomes irrelevant?

 

2)     If not, what policies, operational changes, etc should be employed during this window?

I saw nothing in the document to address these issues.

 

ENISA- the European Union Agency for Network and Information Security – issued a report on patching SCADA systems: “Window of exposure … a real problem for SCADA systems? Recommendations for Europe on SCADA patching” dated December 2013.

To me, the report has several significant shortcomings starting with who was NOT involved in the development of this report as well as the apparent lack of understanding of what makes patching control systems unique. 

Is security patching important? I don’t think there would be much disagreement. However, is patching control system different than patching business IT systems?  The answer is a resounding yes. Consequently, ISA established a committee on Patch Management for Industrial Control Systems – ISA 99.06 yet it isn’t even referenced. I was on the NERC Control System Cyber Security Working Group where they developed a guideline for patch management of SCADA systems that included references to ISA99.06.

One of the major concerns about patching control systems is the unintended systems interactions as control systems are “systems of systems”.  The ENISA document states: ”Patches should be adequately tested on an environment that closely mimics the production environment of the SCADA system on which the test will be applied. Creating such a test environment could be expensive, even when it is done virtually but it is not uncommon for patches to have an adverse effect on other software or systems. A test environment has the possibility to monitor the effect of patches without interrupting the real production process.  After a patch has shown to be working functionally it can then be deployed to production systems. Regression testing is advised.” It is certainly more difficult to model the system interactions of field equipment such as pumps, valves, turbines, breakers, etc than workstations. Two examples demonstrate this concern. A number of years ago, a water company patched their workstation and tested the patch off-line. After implementing the “tested patch”, they could turn on pumps but could not turn them off. At the 2013 ICS Cyber Security Conference, a case history was given of a utility implementing a turbine vendor’s patch and then LOSING VIEW and CONTROL of the turbine. One needs to ask if the cure is worse than the disease.

The ENISA document is correct in stating there will be a window of exposure. However, there are really two issues:

1)     What can be done to make the unpatched control system “invisible or inaccessible” so patching becomes irrelevant?

2)     If not, what policies, operational changes, etc should be employed during this window?

I saw nothing in the document to address these issues.

Joe Weiss