Disclosures, FUD, and the need to maintain credibility

Nov. 26, 2007
The issue of disclosure is not just of software and programming vulnerabilities, but also disclosure of events. I have been following the issue of disclosures and FUD for quite a while and generally have been silent on the discussion. The recent Wonderware disclosure on the Digital Bond web site inspired this response. The predominant concern with disclosures is exactly that- disclosures create security and/or business issues and inform the "bad guys" of things you don't want them to know....
The issue of disclosure is not just of software and programming vulnerabilities, but also disclosure of events. I have been following the issue of disclosures and FUD for quite a while and generally have been silent on the discussion. The recent Wonderware disclosure on the Digital Bond web site inspired this response. The predominant concern with disclosures is exactly that- disclosures create security and/or business issues and inform the "bad guys" of things you don't want them to know. My concern goes deeper than making the disclosure - it is the technical validity of the disclosure. More than four years ago, DOE funded Carnegie-Mellon CERT and KEMA (myself) to develop a scoping study for establishing a CERT for control systems (which was not made public). There were certain fundamental tenets in that report. The primary recommendation was that a CERT for Control Systems needs to have control system expertise. The recent National Infrastructure Advisory Council (NIAC) report dated January 16, 2007 "Convergence of Physical and Cyber Technologies and Related Security Management Challenges - Working Group Final Report and Recommendations by the Council" concurred. However, recent disclosures demonstrate that expertise does not yet exist: Specific examples: - US CERT issued an advisory on November 16, 2006 on Worm Outbreak at Public Power Company.  This advisory was fraught with confusion. In fact, NERC issued the following note on November 21, 2006:  "The NERC ES-ISAC recognizes that the report distributed this morning regarding the Worm Outbreak at Power Company suffered from a significant lack of detail.  US-CERT is working to address this lack of detail, and further information should be forthcoming." It turns out this was an e-mail worm that had nothing to do with control systems. - Following an Australian government warning on an ICONICS Active X application, the US CERT issued an advisory. They didn't realize the vulnerability was strictly on the website demo. - DHS HITRAC stated that cyber was not included because there were no previous incidents in the Electric Power Sector (since the beginning of the Suspicious Activity Assessments).  This was not because there were no cyber events, but because none were reported to DHS. I am also concerned about accusing very reputable control system companies of covering up vulnerabilities. Following the Knoxville Control System Cyber security Workshop, I had a utility volunteer to serve as a test bed for evaluating control system cyber security and networking technologies. The test bed would subscription-based as we need to pay for equipment and staffing. However, unlike the test beds at the National Labs with the non-disclosure requirements, all evaluation information would be made available to test bed participants. I would be happy to provide information on this proposed effort to anyone interested. The way that the cybersecurity establishment has presented the Wonderware disclosure on the Digital Bond website clearly shows the lack of control system expertise in the cybersecurity "industry." It IS an industry, and it is filled with people from IT security and cryptographic analysis backgrounds who have rarely, if ever, set foot in a control room for a process plant, refinery, or power plant. It isn't enough to be able to understand a vulnerability. It is every bit as important to understand the relative danger of the vulnerability IN CONTROL SYSTEMS. For example, the Wonderware disclosure isn't very dangerous. Why not? Because the vulnerability disclosed is limited to a very small population of control systems using an outdated version of the Wonderware software. Like the ICONICS issue, revealing a vulnerability without a corresponding assessment of its impact is not only detrimental, but could be viewed (and certainly would be by Wonderware and ICONICS, for example) as unnecessarily injurious to their brands. These examples are clearly due to a lack of control system experience. Cybersecurity experience in IT or enterprise data centers, or government does not necessarily translate completely to control system cybersecurity. This is not to say that there aren't control system cybersecurity experts-- there are, and quite a few. They are the ones that government and industry need to coopt for blue ribbon panels, cybersecurity tests, and developing strategies. Joe Weiss  

Sponsored Recommendations

Measurement instrumentation for improving hydrogen storage and transport

Hydrogen provides a decarbonization opportunity. Learn more about maximizing the potential of hydrogen.

Get Hands-On Training in Emerson's Interactive Plant Environment

Enhance the training experience and increase retention by training hands-on in Emerson's Interactive Plant Environment. Build skills here so you have them where and when it matters...

Learn About: Micro Motion™ 4700 Config I/O Coriolis Transmitter

An Advanced Transmitter that Expands Connectivity

Learn about: Micro Motion G-Series Coriolis Flow and Density Meters

The Micro Motion G-Series is designed to help you access the benefits of Coriolis technology even when available space is limited.