A litany of control system cyber issues – Are we making progress?
As I was getting ready to put the draft agenda on the website for the August Control System Cyber Security Conference (it should be up by Monday at www.realtimeacs.com), many things became clearer.
Based on the events that keep happening and industry’s response, or lack thereof, I am still pessimistic about real progress.
We still have too many very smart people who appear ambivalent on the questions of: “what is a cyber incident?”, “what is unique about securing control systems?” and most importantly "why secure control systems at all?”
The question I keep asking myself is after the incidents that have happened, the vulnerabilities that have been disclosed, and even NERC admitting they've lied to Congress, why is there still so little REAL progress being made?
Here are some specific concerns and the sessions that will directly address them.
We continue to have cyber incidents; many of them complete repetitions, because there is no appropriate guidance or knowledge. The recent Hatch Nuclear Plant incident was a good example. One senior nuclear plant I&C Engineer wasn’t even informed of the incident because plant management considered it to be an IT issue. The Florida Outage is another – blame the field engineer even though the SCADA operator was unaware the protection was removed. How many people know about cyber incidents other than the three or four public cases even though there have been more than 100 actual cyber incidents? What would Einstein say about repeating the same thing and expecting a different result?
- A session on the cyber issues affecting IEDs including the Florida Outage issues of remote access and lack of appropriate logging.
- A session on the implications of the Hatch incident to nuclear and non-nuclear facilities including design assumptions.
Some of the current security research harkens back to my days as an EPRI Project Manager – we have too many solutions looking for problems, rather than looking at the ACTUAL problems and developing appropriate solutions. The vast majority of the cyber incidents that have occurred in critical infrastructure have not happened because of insecure operating systems or weak passwords. Most of the research I am aware of in electric and oil/gas would not have prevented most of the events that have occurred to date.
- A session on University-sponsored research.
Safety systems (emergency safeguards in nuclear plants, burner management in fossil plant, SIS in chemical plants, etc.) originally were hard-wired analog systems completely isolated from the control network. For economic and productivity reasons, they are now being co-mingled.
There has even been an actual cyber compromise of a safety system.
Field devices and wireless can be major sources of cyber vulnerabilities for safety systems. However, they may not be considered in the oil/gas safety system efforts similar to the exclusions in the AGA-12 Gas SCADA Encryption efforts. What should industry be doing to secure safety systems? How should control and safety networks be designed?
- A session on safety and control systems including a demonstration of hacking a safety system.
The area of control system vulnerability disclosure is still a horrible quagmire with no “right place” to go. You have one cyber security researcher make a disclosure to the Associated Press. I know of another that will make a disclosure to DHS because they don’t know where else to go, including the vendor. This is one of many reasons we need a CERT for Control Systems which we currently do not have.
- A session with Carnegie-Mellon to discuss the CERT concept and extending it to control systems.
Many vendors that are competing in the SCADA/control system security space are making claims that are questionable at best often with little to no field experience:
- “My technology works in (fill in the blank - IT, banking, finance, defense,…) and therefore will work for industrial control systems.” Until the systems are installed in the field, how do you know they won’t affect performance of the systems they are meant to protect?
- “My technology is NERC-compliant.” There is no such thing as NERC-compliant technology. NERC compliance is the utility’s program meeting specific criteria.
- “Our DCSs are all tested before they leave the factory.” You only get what you specify and very few companies know enough as what to specify.
- “I have used the INL Procurement Language specification to provide vendors specific procurement requirements.” There are no two major control system implementations or retrofits (DCS, SCADA, substation, pipeline, etc) that are identical. A control system is more than just than HMI and procurement specifications need to address those also.
Consequently, there is a need for an open discussion on the differing expectations between end-users and vendors.
- A one-on-one discussion with a utility engineer whose plant is going thru a DCS retrofit and his DCS vendor to demonstrate the differences in perspectives and the need to close the gap.
Nuclear power plants are implementing digital upgrades and Ethernet LANs often with unexpected consequences (see Browns Ferry and Hatch). Some of the smaller field changes that are not required to be analyzed can, and have had cyber consequences. The nuclear industry has not formally participated in non-nuclear cyber conferences or organizations such as ISA S99. There is a great need for the nuclear industry to include the experience and expertise of the non-nuclear community.
- An open discussion with NRC, FERC, and PNNL to discuss their concerns with cyber security in nuclear plant operations.
The issue of memory leakage discussed at ISA POWID demonstrates the need for IT and Operations to better understand each others’ needs. What is a problem to one may not be problem to the other. Without better communications, these problems will continue to appear.
- An open discussion session to discuss cross-functional issues.
