Control Systems Cyber Security—The Current Status of Cyber Security of Critical Infrastructures

Testimony of Joseph M. Weiss Control Systems Cyber Security Expert before the Committee on Commerce, Science, and Transportation U.S. Senate

Share Print Related RSS
Page 4 of 7 1 | 2 | 3 | 4 | 5 | 6 | 7 View on one page

An example of information-sharing concerns is the SCADA Internet email-based discussion list from Australia where people from around the world can discuss SCADA/control system issues. Unfortunately, this includes questions from individuals from suspect countries about ICS systems, processes, or devices they do not have, but that we do. This approach works in a benign world – unfortunately, we don’t live in one.

There is a reticence by commercial entities to share information with the U.S. government.  Few “public” ICS cyber incidents have been documented (probably less than 10), yet there have been more than 125 actual ICS incidents. Even the “public” cases may not be easily found as they are buried in public documents such as the National Transportation Safety Board (NTSB) report on the Bellingham, WA Pipeline Disaster4 or nuclear plant Operating Experience Reports. An interesting anecdote was a presentation made by a utility at the 2004 KEMA Control System Cyber Security Conference on an actual SCADA system external attack. This event shut down the SCADA system for two weeks. However, since power was not lost, the utility chose not to inform local law enforcement, the FBI, or the Electric Sector ISAC since they did not want their customers to know. This is one of the reasons it is not possible to provide a credible business case for control system cyber security.

The prevailing perception is the government will not protect confidential commercial information and organizations such as ISACs will act as regulators. That is, if two organizations have the same vulnerabilities and only one is willing to share the information, the organization sharing the information will be punished as not being cyber secure while the organization does not share will be viewed as cyber secure by default. This has Sarbanes-Oxley implications as well. It is one reason why the US CERT, which is government-operated, does not work as effectively as needed. 

Therefore, a “Cyber Incident Response Team (CIRT) for Control Systems” by a global non-governmental organization with credible control system expertise is required.  This organization would collect and disseminate information used to provide the necessary business cases for implementing a comprehensive ICS system security program. Models for this approach include CERT, InfraGard, or FAA5. Specific details can be provided if desired.  The InfraGard model for public-private information sharing requires more sharing with the ICS community by the FBI so industry can protect themselves if a cyber attack has been detected.  The FBI’s “cone of silence” is not adequate. As identified by numerous government reports following the 9/11 disaster, there is a need to “connect the dots” to determine if there are patterns in events that should be followed-up. In this case, the dots that need to be connected are with ICS cyber incidents to determine if policies, technologies, and testing are adequate to address these incidents.

Operationally, there are differences between mainstream IT and ICS systems.  Of primary concern is maintenance of systems.  Like all systems, periodic maintenance and tuning is required to insure effective operation which must be scheduled in advance so as not to cause system impacts. Shutting down a major industrial plant may cost as much as several hundred thousand dollars per minute.

The current state of the IT world insures a high degree of intelligence and processing capability on the part of the various devices within an IT system.  The standard implementation provides centralized control points for authentication and authorization of IT activities.  The lifetime of the equipment in an IT network, typically, ranges from 3 to 7 years before anticipated replacement and often does not need to be in constant operation.  By the very nature of the devices and their intended function, ICS devices may be 15 to 20 years old, perhaps older, before anticipated replacement.  Since security was not an initial design consideration, ICS devices do not have excess computing capacity for what would have been considered unwanted or unneeded applications.

As can be seen, device expectations are different for ICS and IT systems, and this very difference generates two incredibly complex problems:  how to authenticate access, and how to patch or upgrade software. 

Of considerable importance is intra- and inter- systems communication in both the IT and ICS realms.  ICS systems are intended to operate at all times, whether connected to other systems or not.  This independence makes the ICS very flexible, indeed.  The age of the equipment makes it difficult to authenticate communications properly.  Not just between servers, but between servers and devices, devices and devices, workstations and devices, devices and people,… The older technologies do not have the ability, by want of adequate operating systems, to access centralized authentication processes.  By want of the ability of the ICS network to be broken into very small chunks, the use of centralized authentication is impractical, using the technologies of today.  In an IT network, the authentication rules take place in the background and are hidden, for the most part, from the end user.  In an ICS network, the authentication rules take place in the foreground and require interaction with the end user, causing delay and frustration.

Patching or upgrading an ICS has many pitfalls. The field device must be taken out of service which may require stopping the process being controlled. This in turn may cost many thousands of dollars and impact thousands of people. An important issue is how to protect unpatchable, unsecurable workstations such as those still running NT Service Pack 4, Windows 95, and Windows 97. Many of these older workstations were designed as part of plant equipment and control system packages and cannot be replaced without replacing the systems.  Additionally, many Windows patches in the ICS world are not standard Microsoft patches but have been modified by the ICS supplier. Implementing a generic Microsoft patch can potentially do more harm than the virus or worm against which it was meant to defend. As an example, in 2003 when the Slammer worm was in the wild, one ICS supplier sent a letter to all of their customers stating that the generic Microsoft patch should not be installed as it WOULD shut down the ICS. Another example was a water utility that patched a system at a Water Treatment Plant with a patch from the operating system vendor. Following the patch, they were able to start pumps, but were unable to stop them!

Page 4 of 7 1 | 2 | 3 | 4 | 5 | 6 | 7 View on one page
Share Print Reprints Permissions

What are your comments?

You cannot post comments until you have logged in. Login Here.

Comments

No one has commented on this page yet.

RSS feed for comments on this page | RSS feed for all comments