A complete, and still generic, response to Mark

Since Mark has brought up the issue, I think it is time for a complete response. It may ruffle some feathers. When I first got involved in cyber security at EPRI in February 2000, we had to make a decision as to what should be the scope of the program. Security as we are discussing it involves 3 critical perspectives – physical security, business IT security, and control system security. Physical security is a well-established discipline. Additionally, if physical security is breached, the issue of remote access becomes moot as one would have complete access. Consequently, physical security was not a significant focus (other than to acknowledge its importance) in the EPRI Program. I believe this same thought process was used in the preparation of the NERC CIPs. The second part of the triad, business IT security, was already being addressed by the commercial and government security communities. Business IT does affect control systems in the sense that we use modern networking technologies, commercial off-the-shelf (COTS) operating systems (eg, Windows, UNIX, LINUX) particularly for the HMIs, IP/UDP protocols, and communicate with business networks. Additionally, IT has established rigorous programs based on accepted standards (eg, ISO-17799, 27001, etc) that can be used as starting points for control system programs. However, since business IT policies and technologies were already well-established, it was decided not to address business IT security. Again, the NERC CIPs also used this approach by saying the NERC CIPs were for the operational systems, not business IT. Finally, there was control system cyber security. There were very few (I don’t want to say none) technologies available to address the unique needs of control systems, there were no control system-specific best practices available, there was no control system-specific training, and there was very little fundamental understanding of the unique aspects of control systems. The reason for reviewing this history is most of the technologies being developed for “SCADA security” are not for the legacy control systems but for the “Windows” front-end. How many control system Ethernet business network firewalls and intrusion detection systems that don’t address actual control system vulnerabilities do we need? Conversely, why is there so little development on-going to address security for RTUs, IEDs, DCS controllers, PLCs, smart transmitters and drives, chemical analyzers, etc? I believe the answer is it is difficult and you need to know your subject. However, we have VERY FEW domain experts. There have been enough incidents that have occurred to demonstrate major significant damage occurs from access to these RTUs, IEDs, PLCs, DCS controllers, and other edge devices which have little or no capability to defend themselves from even simple attacks.  Viruses and worms do cause problems, but they are really “glitches” as they rarely damage major plant equipment that could take years (yes years) to replace. The incidents and demonstrations that have damaged equipment have come from compromise of such field devices. The policies, risk, and mitigation to protect this major equipment is different than that necessary to protect traditional IT systems equipment or control system workstations and servers. I was not at the meeting Mark refers to. What I can unequivocally state is there is still minimal understanding of the unique aspects of control system cyber security and the need to defend the huge installed base of legacy equipment that runs most of our industrial (not just critical) infrastructures. This has been reinforced by almost every meeting I have attended where non-control system cyber security experts are in attendance. This includes last week’s meeting with some of the top IT cyber security experts in the country. Also IT does not understand where and how traditional IT testing and technologies can, and has, impacted control system performance. Additionally, there is a great desire by management to make the problem go away by using tools that already exist even if they do not fully apply.  We are continuously finding new control-system unique vulnerabilities that IT security either would not address or could actually exacerbate. Most IT security technologies are at least partially applicable and should be embraced where it makes sense – but only with the understanding of the differences between typical applications in each domain, and the need to do more. There is a great need for both IT and control system domain experts to work cooperatively while respecting the expertise of each other. Only then can we develop the “appropriate“ people with the necessary skill sets to determine the appropriate technologies or parts of technologies to use to secure control systems. Joe Weiss