To enable proper security, these examples demonstrate the mandate to understand the ICS and control processes and to evaluate the impacts of potential security process and actions upon those systems and processes prior to implementation.
Figure 1 is used to illustrate the distinction between ICS and business IT considerations. A person is shown (see yellow arrow for location) at the bottom cylindrical torus to provide a perspective of size. In this nuclear plant case, the box shown in the figure (on the left side approximately one-quarter of the way up, see green arrow for location) is one of two main coolant pumps each consuming enough power to power approximately 30,000-50,000 homes. A power plant of this design suffered a broadcast storm resulting in a DOS. In a typical broadcast storm creating a DOS, the impact is disruption of communications across a computer network, potentially resulting in shutdown of computers as a consequence. This broadcast storm DOS shutdown the equipment controlling the pumps eventually resulting in the shutdown of the nuclear plant. The term DOS has a completely different meaning when talking about desktops being shutdown compared to major equipment in nuclear plants and other major facilities being shutdown or compromised.
Figure 1 Nuclear Power Plant Denial of Service
Need for Understanding
In the past, the people that implemented a system, whether Business IT or ICS, were intimately familiar with the processes and systems being automated. Today, few people possess this kind of system knowledge. Rather they design and implement systems based upon design concepts handed to them. In the case of an ICS, the designer and implementer may not even know what the end device does, how it does it, or even what it looks like. The system designer and implementer may not be in the same country as the controlled device. This disconnect allows for loss of understanding about the impacts of miss-operation of a device, device failure, or improper communication with the device.
The more complex the ICS application, the more detailed knowledge of the automated ICS processes are required: how it is designed and operated; how it communicates; how it is interconnected with other systems and ancillary computing assets. Only with this knowledge can appreciation of the cyber vulnerabilities of the system as a whole can begin. There is a current lack of ICS cyber security college curricula and ICS cyber security professional certifications.
Figure 2 characterizes the relationship of the different types of special technical skills needed for ICS cyber security expertise, and the relative quantities of each at work in the industry today. Most people now becoming involved with ICS cyber security typically come from a mainstream IT background and not an ICS background. This distinction needs to be better appreciated by government personnel (e.g., DHS NCSD and S&T, DOE, EPA, etc.) responsible for ICS security. This lack of appreciation has resulted in the repackaging of IT business security techniques for control systems rather than addressing the needs of field ICS devices that often have no security or lack the capability to implement modern security mitigation technologies. This, in some cases, inadvertently results in making ICS systems less reliable without providing increased security. An example of the uninformed use of mainstream IT technologies is utilizing port scanners on PLC networks.
Figure 2 - Relationship and Relative Availability of ICS Cyber Security Expertise
In figure 2, we see that IT encompasses a large realm, but does not include ICS processes. It is true that IT evaluation and design models can be used to develop an ICS; the major difference is that within the Business IT model all tasks have a defined start and a defined end. In the process control model, the process is a continuous loop. Generally, the IT community avoids the continuous loop, while the ICS community embraces the continuous loop. It is the continuous loop that enables an ICS to operate efficiently and safely. As an example,, automated meters “read and record the value from a meter every second”. The meter will happily read and record forever, and be proud that it is doing its function.
A common misconception deals with the availability of knowledge about an ICS. There are only a limited number of DCS, SCADA, and PLC suppliers A few of the major suppliers include ABB, Areva, Alsthom, Emerson, General Electric, Honeywell, Invensys, Metso Automation, Rockwell Automation, Schneider, Siemens, Telvent, and Yokogawa. Approximately half of the suppliers are US-based while the other half are European or Asian-based. The US suppliers provide systems to North America and throughout the world, except to “unfriendly” countries. The ICS systems provided internationally are the same systems provided in North America with the same architecture, same default vendor passwords, and same training. Sales of electric industry SCADA/Energy Management Systems include the system source code, meaning that the software used in North American SCADA systems is available world-wide. Some of the largest implementations of ICS systems originating in the United States are implemented in the Middle East and China. A number of North American control system suppliers have development activities in countries with dubious credentials (e.g. a major North American control system supplier has a major code writing office in China and a European RTU manufacturer has code written in Iran). There are cases where US companies will remotely control assets throughout the world from North America (and vice versa). The non-North American-based ICS suppliers provide the same systems to North America as those provided to countries NOT friendly to us. There are cases where non-North American companies will remotely control assets in North America from Europe or Asia. Additionally, ICS engineers willingly share information. This truly is a global issue.