One of the most controversial security-related issues that I run into – on a rather regular basis – is whether or not IT personnel are sufficiently knowledgeable about industrial automation (in general) and SCADA systems (specifically) to be put in charge of security for these types of industrial automation systems. And, whether they can/should be put in charge of ongoing technical support for such systems.
Quite frankly, in the 1970s and 1980s the groups that purchased, operated and supported computer-based automation systems were dealing with computer technologies very different from those of “office automation” or IT. (The existence of Information Technology as a separate entity actually evolved in the late 1980s.) That is, the IT folks were dealing mainly with IBM, Univac or Burroughs mainframe computers and the industrial automation folks were dealing with minicomputer manufacturers like Digital Equipment Corporation (DEC) and Data General.
The operating systems were totally different, the programming languages used (assembly and ‘C’ versus COBOL) were totally different, the computer hardware was totally incompatible and the networking (if there was any) was vendor-specific. But during the 1990s – and certainly today – most of those vendor boundaries have either disappeared or have been moved into specialized areas by contemporary suppliers.
Today, most automation systems are typically running on some type of MS-Windows/Intel platform, interconnected locally with other computers and devices using high-speed Ethernet1 and connected over greater distances by TCP/IP networking technologies. The basic operating systems used in these systems (except in most [but not all] real-time ‘controllers’ and RTUs) will be either a Microsoft Windows™ variant or a Unix/Linux variant. And even in the controllers and RTUs there has been a move toward using commercial embedded operating systems rather than having vendors write their own. It is also probable that other ‘standard’ information technologies such as SQL-compatible relational databases, Web servers, etc. will be incorporated into those systems.
So, in other words, a large percentage of the elements that form those systems – as well as their overall architectural design – look just like those of a conventional IT/business system. You might even say that the major difference between an automation system and a business system today, is just a matter of the applications they are running. Personally I wouldn’t super-simplify quite to that level, but the argument can be (and is being) made.
The observation that platforms have standardized is one reason why senior management in many organizations sees no reason why the “IT guys” can’t also be responsible for the SCADA systems. I am aware of several organizations where the SCADA systems, and associated support and operational personnel, have actually been placed (i.e., organizationally), under the IT umbrella.
Historically there has been no love lost between the SCADA/operations folks and the IT department. That is undoubtedly the result of numerous factors. Over the years I’ve personally witnessed more than a few heated arguments between members of those two groups. The IT personnel usually don’t see that there is any difference between the SCADA system and the business systems (or any that do exist are obviously minor). The SCADA personnel come from the standpoint that getting that system installed, commissioned and operating was a massive undertaking and they are loathe to make any modifications or let ‘outsiders’ do so. There are valid reasons for both viewpoints, but there are also critical differences that are not always apparent.
Conventional IT training and operational philosophies put a focus on three vital objectives for the computer systems they administer and support: Confidentiality, Integrity and Availability. Most texts about IT frequently refer to the acronym “CIA”. These three objectives are also being listed in the priority order that makes the most sense from an IT viewpoint. Keeping the information in business systems confidential and trustworthy is critical. Keeping those systems operating and available is important. Usually nothing much bad happens if the IT guys need to reboot the servers. Although it would be nice, business systems don’t always have the requirement for 100% availability that industrial automation systems are (and always have been) expected to provide.
Now before I get a pile of hate email from IT folks, let me say that the IT world does recognize the need to try for 100% uptime and some applications can cost-justify the necessary redundant elements. If you have a web based sales portal, downtime means lost orders and customers who might go to your competitor. But downtime generally doesn’t mean potential for injury, death or massive physical damage. And that brings us to the main difference between the IT world view and that of the people running industrial automation systems: the issue of safety.
If a SCADA, DCS or PLC system is disabled, malfunctions, or is commandeered and used to manipulate field/process equipment and devices, there is a possibility – depending on the process involved and other safety and backup systems – that an unsafe condition can be created, potentially leading to injury, death and/or physical, and even environmental, damage. Of course, in the design of mission-critical systems we usually make them fully redundant and may even have a totally separate, backup system, located in a physically separated site impervious to intentional attacks and/or natural disasters.
Common practices that are low-risk in the typical IT environment, may be considered as too risky in the control systems world, specifically because of the safety implications. Examples of such practices could include deployment of new applications with less than exhaustive testing or the wholesale and immediate (and unquestioned) installation of unverified patches.
My own experience upgrading to Microsoft Office 2007 exemplifies that application pre-testing in the IT world doesn’t have to be as rigorous as in the process control world. Indeed, there are numerous well-documented incidents where vendor-approved patches were installed on industrial automation systems, that resulted in system malfunctions and requiring restoration to a previous version.
So, what about the question at the beginning of this column? In general, I believe that the best situation is to have cooperation between real-time operations organizations and IT organizations, each having a mutual respect for the experience and knowledge of the other group. The fact is, a great deal of what is needed to secure industrial automation systems comes directly out of the playbook used by IT. On the other hand, the SCADA folks have serious safety concerns and have devised processes and procedures that allow for safe support and modification of their systems.
By getting these two groups to engage in meaningful dialog and make a concerted effort to work together, you achieve the best of both worlds – and undoubtedly a higher level of security! There are team-building exercises that can help in making this happen… but perhaps that will be the subject of a future column.
About the Author
William T. “Tim” Shaw (PhD, CISSP) has been active in industrial automation for more than 30 years and is the author of Computer Control of BATCH Processes and CYBERSECURITY for SCADA Systems. Tim has contributed to several other books and is a prolific writer and presenter on a range of technical topics. He is currently a senior security consultant for SecuriCon, an information security solutions firm, based in Alexandria, Virginia. Tim has been directly involved in the development of several DCS and SCADA system products and regularly teaches courses for ISA (International Society of Automation) on various topics. Inquiries or comments about this column may be directed to Tim at Tim@electricenergyonline.com.
