Supervisory Control and Data Acquisition
Paul A. Henry, (MCP+I, MCSE, CCSA, CCSE, CFSA, CFSO, CISSP, -ISSAP, CISM, CISA, CIFI) is the Vice President of Technology Evangelism at Secure Computing®
Paul is one of the world’s foremost global information security experts, with more than 20 years experience managing security initiatives for Global 2000 enterprises and government organizations worldwide.
At Secure Computing, Paul plays a key strategic role in launching new products and re-tooling existing product lines. In his role as Vice President Technology Evangelism, Paul also advises and consults on some of the world’s most challenging and high-risk information security projects, including the National Banking System in Saudi Arabia, Department of Defense’s Satellite Data Project, USA, and both Government as well as Telecommunications projects throughout Japan.
Paul is frequently cited by major and trade print publications as an expert on both technical security topics and general security trends, and serves as an expert commentator for network broadcast outlets such as NBC and CNBC. In addition, Paul regularly authors thought leadership articles on technical security issues, and his expertise and insight help shape the editorial direction of key security publications such as the Information Security Management Handbook, where he is a consistent contributor.
Paul serves as a featured and keynote speaker at network security seminars and conferences worldwide, delivering presentations on diverse topics including network access control, Cyber crime, DDoS attack risk mitigation, firewall architectures, computer and network forensics, Enterprise security architectures and managed security services.
Introduction
Within the time span of the author’s career, process controls have evolved from pneumatic systems to analog, and then again from analog to digital. Today’s digital controls are predominately referred to as Supervisory Control And Data Acquisition (SCADA) systems.
Early pneumatic and analog control systems were isolated from organizations’ business systems. Simply putting the integration of process control data into the business decision-making process was a labor-intensive task. Control system data loggers and variable recorder chart data were typically read by an operator or supervisor and then manually entered into business systems.
Current-technology SCADA systems integrate directly with organizations’ business systems. Control system data are immediately available to specialized business systems that can optimize SCADA system set points and parameters to better meet the immediate business needs of the organization. It is the integration of SCADA systems and the organizations business systems that pose the greatest risk in SCADA security today.
Just What Is SCADA?
Supervisory Control and Data Acquisition (SCADA) systems provide for the supervisory control, management, and monitoring of process control and manufacturing automation systems through the collection and analysis of real-time data. The prevalence of SCADA systems has grown to the point that our national infrastructure today depends, to a large degree, on SCADA systems.
Today SCADA systems play important roles in several industries (Table 2.1):
Table 2.1
Industries Where SCADA Plays an Important Role
| Aluminum | Boilers |
| Automotive | Chemical |
| Electric Power | Nuclear Power |
| Chemical | Oil and Gas Transportation |
| Flight Simulation | Paper Manufacturing |
| Food Processing | Specialized Petrochemical |
| Fossil Fuel Production | Rubber Manufacturing |
| Glass Production | Steel Manufacturing |
SCADA system capabilities have evolved from that of simply replacing lights and push buttons to handling very complex process control and critical safety shutdown systems. The intelligence of SCADA systems has advanced to the point where their automated operation requires fewer operators: less human supervision than previous control system methodologies. Today, common applications for SCADA systems include, but are not limited to, those shown in Table 2.2.
Table 2.2
Common Applications for SCADA Systems
| AC efficiency test standards | Batch process controls |
| Bearing temperature monitor | Boiler and turbine controls |
| Boiler controls | Burner management systems |
| Boiler data acquisition | Sequence of Events (S.O.E.) |
| Boiler water treatment controls | Brick kiln controls |
| Bulk resin dispensing | Carburetor test standards |
| Clay manufacturing controls | Continuous polymer manufacturing |
| Continuous welding SPC monitoring | Desulphurization and acid processing |
| Dynamometer controls | Electric power T&D monitoring |
| Extruder controls | F16 and F117 flight simulation |
| Fiber optics filter manufacturing | Floating dry dock controls |
| Food preservation | Fore hearth controls |
| Fuel injector test standard | Fuel oil handling system |
| Fuel pump test standards | Furnace controls |
| Gas processing | Glass furnace controls |
| H2O chemistry controls | Hazardous chemical waste controls |
| High-flux research reactor controls | Hydroelectric load management |
| Incinerator controls | Material handling and finishing |
| Meteorological monitoring | Military data acquisition |
| Nuclear plant DAS | Nuclear plant full-scope simulators |
| Nuclear simulators | Offshore platform oil/gas separation |
| Paper mill wet end process controls | Petroleum pilot plants |
| Plant energy management | Plant monitoring |
| Power distribution monitoring | Process controls |
| Process simulators | Product distribution monitor |
| Radwaste monitoring | Reactor and plant monitoring |
| Reactor core temperature monitoring | Reactor monitoring / reactor plant DAS |
| Refrigerator efficiency test standards | Resin mixing |
| Rod drop monitoring systems | Rolling mill controls |
| Rotating equipment monitoring | Safety parameter display systems |
| Ship controls development systems | Shipboard LNG controls |
| Solder manufacturing controls | Spool-winder temperature monitoring and controls |
| Steam control systems | Submarine diving simulators |
| Tank controls | Target ranges |
| Textile finishing range controls | TG monitoring |
| Tritium processing | Turbine controls |
| Turbine generator fuel test cells | Turbine monitoring |
| Utility monitoring | Virtual annunciator panels |
| Waste tank controls | Waste water monitoring |
| Water chemistry monitoring | Weapons release simulators |
| Whole body calorie monitoring | Compressor surge controls |
| Wind tunnel controls |
SCADA Systems and Components
While exceptions exist, such as self-contained and stand-alone SCADA systems that are purpose built for a given application, most SCADA systems are comprised of several components that communicate across a network.
Remote Terminal Units (RTUs)
An RTU (Remote Terminal Unit) provides intelligent I/O collection and processing, such as reading inputs from switches, sensors, and transmitters and then arranging the representative data into a format that the SCADA system can understand. The RTU also converts output values provided by the SCADA system from their digital form into that which can be understood by field-controllable devices such as discrete (relay) and analog outputs (current or voltage).
Programmable Logic Controllers (PLC)
The PLC can be regarded as the “brain” of the SCADA system. The actual control program for a given process or its control systems is executed within the PLC. A PLC can either work with local physically connected inputs and outputs or with remote inputs and outputs provided by an RTU. Typical PLCs can provide for two different types of control: discrete and continuous.
Discrete Control
In discrete control applications, the PLC works with inputs and outputs that have defined states (on/off) and can perform actions based on time, events, or a particular sequence (for example, turn on an output at a given time, turn off an output after the input from a field device, such as a limit switch closes; turn on a series of outputs in a given sequential order).
Continuous Control
In continuous control applications, the PLC typically works with analog input and output devices and uses special algorithms to maintain a steady operating state. For instance, the PLC has a set point that is provided by the SCADA system for the desired temperature of a given process. It receives an analog input value of 0 to 100 percent, representing the process temperature. The PLC uses specialized algorithms (such as PID algorithms) to generate an analog output value of 0 to 100 percent that is then used to position a valve or to control the speed of a motor in an effort to continuously keep the temperature at the desired set point.
Combinations of both discrete and continuous control are often used in what is referred to as batch control. In batch control applications, both discrete control and continuous control are used together. In the simplest of terms, discrete operations could be used to mix the given ingredients of a recipe and place the batter in a pan in the oven, while continuous control would be used to maintain the oven at a specific temperature to create the finished product—the cake.
Human Machine Interface (HMI)
The HMI (Human Machine Interface) is the means by which the user (operator) interacts with the SCADA system. Simply put, the HMI provides a clear and easy-to-understand computer representation of what is, in fact, being controlled or monitored by the SCADA system. Further, it provides for interaction, either in the form of a touch screen, a specialized keyboard, or both.
Current-generation SCADA HMIs are not just a replacement for push buttons and pilot lights of the past. In fact, they provide a simpler user interface for even the most complex SCADA systems. The “usability” of the HMI is the measure by which a user can effectively interact with the SCADA system. HMI implementations that offer high levels of usability provide SCADA systems that are intuitive, efficient, and effective. A good and effective SCADA HMI design makes the interaction with the SCADA through the HMI seem natural to the operator—in other words, clear and easy to understand, with no need for explanation.
The International Engineering Consortium (IEC) has defined a standard ISO 9241 that provides a definition for the quality of use for an HMI. The ISO 9241 standard defines three components of quality of use applicable to the design of an HMI:
1. Effectiveness—Does the product do what the users require? Does it do the right thing?
2. Efficiency—Can the users learn the HMI quickly? Can they carry out their tasks with minimum expended effort, including a minimum of errors? Does it improve the productivity/effort ratio? Does it do things right?
3. Satisfaction—Do users express satisfaction with the product? Does the new product reduce stress? Do end users now have a more satisfying job?
Distributed Control Systems (DCS)
Historically, the term DCS could best be defined as a dedicated control system that did not rely upon a single central computer to control a given process, was comprised of multiple computers, did not require operator intervention, and afforded for interaction between those computer systems to provide for the total control of a given manufacturing or process control system.
The distinction between DCS and SCADA systems has become difficult since SCADA systems have evolved to become more powerful and capable with many SCADA solutions today offering DCS-like capabilities. In fact, vendors of SCADA systems today would argue that the current-generation SCADA system gives the distributed control capability of a large DCS system, while still affording the ease of use found in a SCADA system. At the same time, of course, DCS vendors are today claiming that their DCS systems are able to handle much more complex processes with the ability for operator interaction through an HMI that rivals the ease of use found in a SCADA system.
Looking toward the future, it is not hard to imagine that SCADA systems will continue to become more powerful and capable and, in fact, may one day replace the traditional DCS, at least in the form that we know them today.
Hybrid Controllers
Hybrid controllers are specialized devices that provide for capabilities not found in standard discrete and continuous control modules for PLC systems. Capabilities such as adaptive control, artificial intelligence, and fuzzy logic are afforded by typical hybrid controllers.
The capability of hybrid controllers is one of the primary mechanisms that is blurring the line between SCADA and DCS systems. Benefiting from Moore’s Law (computing power nearly doubles every 18 months), the most complex control algorithms and intricate mathematical capabilities previously reserved only for powerful DCS systems are quickly finding their way into today’s increasingly more powerful hybrid controllers for SCADA systems.
A SCADA system may utilize multiple hybrid controllers distributed as needed to perform the tasks at hand across a given process while still operating under the supervisory control of the SCADA system.
Event Loggers
Event loggers provide for the capturing of events as they happen within a SCADA system and provide time/date stamping, which affords a complete audit trail of the events that have occurred in the SCADA system. Typically, time within a SCADA system event logger provides for usable resolution down to 1/10 of a second. While this is more than fast enough for many typical applications, it is not suitable for applications where multiple events can happen only milliseconds apart, such as in the switch gear for power distribution systems and safety shutdown systems for critical processes. In these applications, specialized event loggers that can capture events occurring perhaps just milliseconds apart are typically required.
In SCADA systems that utilize the integrated event logging capability of multiple individual components, it is critical that the time across the SCADA system be synchronized. Hence, it is not uncommon today for a SCADA system to use a single time reference such as that found in a Global Positioning System (GPS) satellite receiver as a time-synchronizing source to assure that all real-time and historical data timestamps are accurate across all HMIs, PLCs, hybrid controllers, and other devices within the SCADA system.
Common SCADA Architectures
Early SCADA systems used proprietary event–driven operating systems and some form of rudimentary/proprietary serial communications typically based on R232/RS422/RS485. One could perhaps argue that early SCADA systems benefited from the “Security by obscurity” that was afforded by their specialized operating systems and communications.
Today, SCADA system components utilize purpose built event-driven operating systems, commercial operating systems (for example, Windows/Linux as well as hybrids), and commercial operating systems with real-time extensions. While SCADA systems for critical processes are available with fault-tolerant networking, most have evolved to take advantage of UDP/TCP over Ethernet communications.
In a SCADA network (Figure 2.1), field devices are typically connected to the PLCs across an independent network using specialized protocols such as Fieldbus, HART, or MODBUS.
The PLCs are on a separate network and Communicate to the system’s HMIs, hybrid controllers, and event loggers using protocols such as InfiNET.
If the preceding example were the extent of connectivity to the SCADA system, they would be relatively secure. However, it is common today (Figure 2.2) for the corporate IT network to typically connect to the InfiNET network with a bridge to allow for the collection of production data, and SCADA vendors are typically allowed to connect to PLCs or hybrid controllers in order to facilitate vendor support of the SCADA system.
SCADA Communications Protocols
In the early years of SCADA systems, few if any communications standards existed, hence individual SCADA equipment vendors each created their own exclusive proprietary protocols. It has been estimated that at one point there were between 150 to 200 different proprietary SCADA protocols in use. The high number of protocols in use along with their proprietary nature actually afforded a degree of security through “security by obscurity.”
As the SCADA industry matured and vendors began to adopt open standards, the total number of SCADA protocols commonly in use was reduced to a small number of popular protocols that were being promoted by industry professional organizations, which included, but were not limited to, the following:
How Serious Are the Security Issues of SCADA?
Data within the British Columbia Institute of Technology (BCIT) report titled “The Myths and Facts behind Cyber Security Risks for Industrial Control Systems” issued in 2004 indicates that there has been a ten-fold increase in SCADA incidents since 2000. Of those organizations surveyed within the report that placed a dollar value on the losses associated with a SCADA attack, 50 percent reported financial losses of $1,000,000 or more.
The BCIT report includes 100 or so recent SCADA incidents, but unfortunately this only uncovers the tip of the iceberg. The problem is in the reporting (or lack thereof) of SCADA incidents. Out of the 200 Fortune 500 companies that are considered to be part of our critical infrastructure, only 14 currently report anything on SCADA issues to authorities. Simply put, if the incident is not reported to authorities, then it is not included within the Industrial Security Incident Database (ISID). The next issue in reporting SCADA issues is that those 14 organizations that do report to ISID are considered to be the leading edge, hence they are using more current technology perhaps than a typical SCADA operator and would perhaps naturally see lower incident numbers. Security companies have published white papers that suggest a more probable number of annual SCADA incidents is actually 2,000 to 3,000.
At a recent SANS security seminar, featured speaker CIA Analyst Tom Donahue noted that recently declassified information had revealed that cyber criminals had in fact disrupted electrical power in several regions outside of the US and further noted that the goal of the attacks was extortion.
Early digital SCADA systems were designed for performance, and little if any regard was given to the proper error handling normally associated with network protocols. Hence, many times only a portion of the given protocol was ever properly implemented. Simply put, saving a few bytes of code was considered more important than properly handling protocol errors. After all, SCADA was a closed system and the normal errors associated with network protocols would be nonexistent. Hence, most of the current installed base of SCADA systems in use today utilize protocols that are either inherently insecure by design or that by-and-of themselves are not necessarily insecure but are poorly implemented by the SCADA product vendor, which results in SCADA insecurities. It should come as no surprise that a simple port scan of a SCADA network could in fact cause the entire network to crash because of the lack of proper error handling.
Unfortunately, in order to reap the full financial benefits of a SCADA system, interconnection to the enterprise network is necessary to provide real-time process data to enterprise back-end systems. It is this interconnection of SCADA systems and the enterprise network that is the weakest link in SCADA system security.
The first step in understanding the risks associated with SCADA while operating in today’s digital world is to accept that SCADA systems have always been designed to operate in closed environments. While most organizations claim that their SCADA system is not connected to their enterprise network it has been estimated that, in reality, 80 to 90 percent of SCADA systems are in fact connected to the enterprise network. It is that connection to the enterprise network that opens the door for Internet hackers to attack SCADA systems.
Basically, SCADA systems have no inherent ability to cope with the issues commonly found plaguing today’s enterprise networks. Connecting the SCADA system to a corporate network dramatically increases risks poised by traditional malware.
A common denominator among most SCADA protocols is that they were nearly always based on a given vendor’s proprietary standard and were almost always designed to pass data accurately and quickly between devices with little if any direct regard to security.
Further in some implementations only a portion of a given protocol was implemented in the SCADA device in order to save development time, and perhaps memory and CPU cycles. Unfortunately, it is not uncommon for a SCADA system protocol implementation to have improperly implemented error handling within the given protocol. Hence most of the current installed base of SCADA systems in use today utilize protocols that are either inherently insecure by design or that by-and-of themselves are not necessarily insecure but are poorly implemented by the SCADA product vendor, which results in SCADA insecurities.
Typical high-level weaknesses found in SCADA systems today include:
These high-level weaknesses open several potential attack vectors:
These attack vectors can lead to potentially disastrous results, such as:
Determining the Risks in Your SCADA System
First, a word of caution: Determining the risks within your SCADA system is not as easy as it may first seem. The traditional methods used in determining if vulnerabilities exist within an IT network can wreak havoc within a SCADA network. The simple task of port scanning can bring down a SCADA system if the network error handling was not properly implemented by the manufacturer. Further, care must be taken not to overwhelm the SCADA network with traffic in testing since many SCADA controllers rely upon data passed across the network to continue safe operation. In fact, many SCADA controllers are designed to failover to a safe manual value if they do not receive a set point or other controller variables within a predetermined time period. Hence, it is critical that only technicians that are knowledgeable of the shortcomings inherent to SCADA systems be used for any vulnerability assessment.
Active scanning considerations:
Use a lab environment first, not a production network, to determine the impact of scanning.
Be sure the scanning software that is utilized simulates vulnerabilities by testing version levels and so on, rather than simply executing known vulnerabilities.
Any devices more than five years old should not be targets of any vulnerability scan.
Be sure that any back-up devices are operational and ready for failover should a primary controller fail during scanning.
Be sure control system operators are fully informed of the potential for SCADA system failures before any scanning begins.
Passive scanning considerations:
Passive scanning does not generate any network traffic within the network being tested and is considered a safer alternative to active scanning.
The rate of passive network discovery is determined by the amount of network traffic and the number of SCADA nodes that are talking.
Passive scanning can discover hosts, services, and versions that can then be mapped to potential vulnerabilities.
Risk Mitigation for SCADA
While most enterprises have a security policy to deal with the operation of the enterprise network, few have policies that address the SCADA environment specifically. With SCADA systems operating today within the inherently insecure world of TCP/IP and often interconnected to the enterprise network and public Internet, a SCADA security policy is a crucial first step in securing the system.
A SCADA security policy should (at the least):
1. Require the development and maintenance of a list of all SCADA components and version levels.
2. Require the development and maintenance of diagrams for data flows within the SCADA network and just as importantly between the SCADA network and the enterprise network.
3. Require use of the latest stable software release for all SCADA components.
4. Disable all unnecessary servers and services on SCADA components.
5. Establish a password policy, eliminate the use of shared passwords, and utilize one-time passwords wherever possible.
6. Require the development and maintenance of a policy for a Rule of Least Privilege across the entire SCADA system.
7. Require the use of all available auditing capabilities across the SCADA system.
8. Regularly test all SCADA components for vulnerabilities.
9. Approach security and the hardening of all SCADA workstations and database servers as if they were connected directly to the public Internet.
10. Utilize firewalls to both separate the SCADA network from the enterprise network and segment the SCADA network.
11. Encrypt all communication between enterprise applications and the SCADA system.
With a SCADA security policy in place, the next step in risk mitigation would be the incorporation of technical safeguards to enforce the security policy.
Firewall Considerations for SCADA
A firewall by-and-of-itself is not the Holy Grail, and simply installing one to isolate the SCADA network from the enterprise network and walking away does not fix all the problems. The firewall is a tool where vigilance is required. Risks do not magically go away when you flip the switch on your firewall. While a good firewall offers some security and functionality out of the box, the administrator must take security to an even higher level. The firewall is, in effect, a necessary tool that is part of an overarching approach and philosophy of security. It is a gateway tool for implementing an all-encompassing security policy that defines your entire network’s level of access and services when connecting with other networks like the Internet. The following three items are important in making your firewall work for you:
1. Create an appropriate set of perimeter access and content inspection policies.
2. Implement the right type of firewall that is capable of most effectively automating the enforcement of your perimeter security policies.
Given the right approach and a good understanding of firewall fundamentals, you can stop attacks from crossing into and impacting your SCADA network.
Negative and Positive Security Models in Firewalls
Even before the Internet and Web 2.0 ushered in our current era of threats, network-based systems were still a target, and firewalls evolved very quickly to mitigate the risks. The concept was simple: create a device that prevents undesirable elements from entering the network, while still allowing legitimate access. As such, the firewall’s basic task is to control traffic that flows between computer networks. The firewall has evolved considerably, and today there are usually multiple zones of trust, each one with different levels of access. Most early firewalls, and some that are still being offered, work on a “negative” security model that identifies undesirable traffic and prevents it from entering. It’s very much like having a list at a country’s port of entry, which identifies known criminals. When people travel into the country, their passports are checked against this list, and if they are not on it, they are allowed in. This design is effective to the degree that it catches known criminals, but what about those who have not yet committed any acts of terror, or have not yet been caught for their crimes, or who should also be considered a risk because of their associations or reputation? In fact, it is not always possible to determine whether somebody, or in the case of the network, a particular packet of traffic, is undesirable based on known parameters. The most effective security policy revolves around one statement: “Trust no one.” That’s why the best firewalls operate on a “positive” security model, which denies all access unless it is explicitly allowed.
Multi-Network Connectivity
At its most basic, think of a firewall as a “control point” computer with two interfaces (typically Ethernet) that is located between two separate networks. A cable connects the first network to the firewall, and a second cable connects the firewall to the second network. All traffic is then blocked, and is not allowed to pass to the other network unless the firewall computer decides, based on its preconfigured rules and policies, that it should be allowed.
Because the firewall has two or more physically separate network interfaces, it is a multi-homed device. This is why firewalls are unlike most other networked devices. Other networked devices, such as servers, workstations, and printers, are connected to networks with only one physical connection (or wireless port), which passes all needed traffic coming and going in both directions, simultaneously. Some vendors and industry observers claim that it is possible to build a network firewall with only one physical interface, but that architecture would have serious limitations and has never been accepted by the market, and it would not be recommended by any serious security practitioners as a primary firewall device.
A firewall should “know,” by way of configured policies and rules, which networks to trust more than others. The Internet, for example, is not under the control of the company deploying the firewall, and the content is completely unknown. As such, the Internet is a zone that should be attributed no trust at all, and the firewall that is connected to the Internet should have the highest level of defenses established. But firewalls do far more than just protect internal networks from the perils of the Internet, and the firewall must still be used even to separate traffic flowing between internal networks, even if they are not connected by the Internet. Not all attacks are Internet-based, and internal attacks are unfortunately quite prevalent. As a result, large enterprises usually deploy multiple firewalls, with one for each department, division, or branch. Not only does the firewall protect the company’s Internet server from the external Internet, it also protects each departmental sub-network from any risks that may already be inside.
However, an internal departmental network is under control and its content is well known, so it should be a zone with a higher level of trust. The ultimate goal is to provide high-speed, reliable, and tightly controlled connections between networks of differing trust levels, while enforcing a “deny all unless explicitly allowed” security policy.
While some firewalls are more intuitive than others, they still require proper configuration and skill to maintain. Some administrators get a false sense of security because they have a firewall and mistakenly believe it can be plugged in, powered on, and forgotten. In fact, an improperly configured or neglected firewall is more dangerous than having none at all. The firewall is a key component when implementing policy. As such, the firewall itself should be useful in designing that policy, but it is the policy itself that guides how the firewall is used and how effective it becomes.
Reactive and Proactive Solutions
Within the framework of the firewall, and in the case of a Unified Threat Management environment (all of the associated protections such as anti-virus, anti-spam, URL filtering, SSL scanning, and IPS/IDS), the firewall appliance must take both a reactive and proactive approach. In many of the first- and second-generation firewalls, it became obvious that being limited to reactive security provided some, but not enough, protection. An example of reactive security is signature-based anti-virus databases, which keep track of known virus signatures to prevent them from entering the network. Similarly, URL filters that rely exclusively on categorized lists prevent users from accessing Web sites that are known to be harmful.
Proactive security comes from several different angles. First and foremost, proactive security comes from the “deny everything that is not explicitly allowed” philosophy. This approach to proactive security is exemplified in the Sidewinder firewall’s deeply aware and deeply configurable application-specific security proxies. Proxy-based Web and mail security gateways from numerous companies have recently emerged into the market as well to (basically) plug the holes in traditional firewalls protecting most corporate networks today. Deeply configurable application-specific proxies will eliminate most attacks that have not yet been detected and defined by simply sloughing them off as superfluous to the use of the company’s applications (in other words, not needed) or because they violate the fundamental use of the applications when checked against the Internet RFCs. An extra layer of proactive security comes from the inclusion of a reputation-based system, which acts as a sort of virtual credit agency to determine a precise reputation score for every sender.
Reactive signature-based systems are quite good at catching malware attacks that have already been detected and included in signature databases, and these sorts of systems play an important role in unified threat management. However, there is a growing body of malware that has not yet been detected, and in such cases, signature-based reactive solutions must themselves be secured within a more comprehensive and proactive security software environment. Attacks that have not yet been catalogued, known as “zero-hour” attacks, are on the increase. Signature engines simply cannot keep ahead of large instantaneous malware outbreaks spewing out of zombie networks today. Zombie machines (PCs connected to the Internet that can be remotely controlled at will from across the Internet by the bad guys) are responsible for the majority of spam, viruses, and “for profit” schemes like phishing attacks on the Internet today.
Criminal elements lease access to thousands or tens of thousands of zombie PCs to create malicious networks of computers called botnets. These botnets are used to distribute whatever the criminal or hacker wants them to distribute and pose a serious threat to SCADA systems. With hundreds of thousands of computers being silently hijacked and turned into zombies on a daily basis, corporate networks suffer a constant stream of unwanted and dangerous traffic. To combat this threat, in addition to being able to recognize a threat with a signature database, the security system must also be able to tell if a remote computer is actually a zombie machine. The next generation of proactive security tools is being built with this in mind. These systems are called reputation-based systems.
Firewall Inspection Methods
The level of protection that any firewall is able to provide in securing a private network when connected to the public Internet is directly related to the architecture(s) chosen for the firewall by the respective vendor. Generally speaking, most commercially available firewalls utilize one or more of the following firewall architectures:
Static Packet Filter
Packet filtering firewalls are among the oldest firewall architectures. The static packet filtering firewall operates only at the network layer (layer 3) of the OSI model and does not differentiate between application protocols. This type of firewall decides whether to accept or deny individual packets, based on examining fields in the packet’s IP and protocol headers. The static packet filter does not impact performance to any noticeable degree, and its low processing requirements made this an attractive option early on when compared to other firewalls that dragged down responsiveness. However, today’s higher-level firewalls deliver excellent performance as well. In addition, faster networks are more capable of handling the greater processing requirements of a firewall that operates at a higher level of the OSI stack.
The packet filtering firewall filters IP packets based on source and destination IP address, and source and destination port. The packet filter may lack logging facilities, which would make it impractical for an organization that has compliance and reporting requirements to which they must adhere. Also, because it examines only the packet headers, attackers can bypass the static packet filter with simple spoofing techniques, since the filter cannot tell the difference between a true and a forged address. Another limitation is that for larger installations, the static packet filter becomes unwieldy because packet-filtering rules are examined in sequential order, and care must be taken when entering rules into the rule base. Another inherent limitation is that the static packet filter does not examine the entire packet, which makes it possible for an attacker to hide malicious commands inside unexamined headers or within the payload itself. Lastly, the static packet filter is not state-aware, so the administrator is required to configure rules for both sides of the conversation. Today, this type of firewall is considered very basic and limited, and may even be included in operating systems as an “extra.”
The Stateful Packet Filter
The next step in firewall evolution came with the stateful packet filtering firewall (or the stateful inspection firewall as it is often referred to). This type of firewall has the same limitations as the static packet filtering firewall, with the exception of being state-aware. The stateful packet filter still operates at the network layer of the OSI model, although some may extend into the transport layer (layer 4) to collect state information. Despite the stateful packet filter being application-unaware, it does offer limited advantages over the basic static packet filter.
Like the static packet filter, the stateful packet filter examines each packet’s IP and protocol headers to determine whether each packet should be allowed or denied. Also like the static packet filter, it does not examine the packet payload. The fact that it is stateful means that the packet filter is aware of the difference between a new and an established connection, which has some advantages regarding efficiency. Once a connection has been established, it resides in a table in RAM, and subsequent packets are compared to this table. If a packet is part of an existing connection, it is then allowed to pass without further inspection. As a result, it is not necessary to parse the packet filter rule base for every single packet that enters the firewall.
Although there is some performance gain over the static filter, many stateful packet filters operate on a single-threaded process, which cannot take full advantage of symmetrical multiprocessing, and which limits the performance gain possible. Those stateful filters that do support SMP afford up to a 30-percent increase in performance. Nonetheless, the performance advantage gained by packet filtering in general is today negligible, due to the existence of faster processors.
The Circuit-Level Gateway
The circuit-level gateway extends the concept of the packet filter by first performing the same packet filtering operations as the firewalls mentioned earlier, and then adding the extra step of verification of proper handshaking and the legitimacy of the sequence of numbers used in establishing the connection. As such, the circuit-level gateway operates at the Session layer (layer 5). The circuit-level gateway effectively breaks the normal client server model, thereby eliminating a direct connection between the malicious hacker and the protected server and/or SCADA component. The circuit-level gateway examines more data than a standard packet filter. In addition to examining the source and destination address and source and destination port, it examines and validates TCP and user datagram protocol (UDP) sessions before opening a connection. The older packet filter bases its decisions about accepting or denying a packet on the source and destination address and the source port number and destination port number. The circuit-level gateway also adds handshaking and sequence numbers to the equation. It therefore has more data to use in deciding whether to admit any given packet.
The circuit-level gateway has about the same performance metrics as the packet filter, and since it operates at a low level of the OSI model, it does not affect network performance significantly. The disadvantage is that once the connection has been established, any application can run across that connection, because the circuit-level gateway filters packets only at the Session and Network layers—not the Application layer. Nevertheless, the circuit-level gateway still does not examine the data content of the packets being sent.
A hybrid approach for SCADA would be to take advantage of the circuit-level gateway’s inherent ability to break the client server model and to then apply signatures to inspect the packet before allowing it to pass to the SCADA system (Figure 2.3).
Application-Level Gateway (Proxy)
Operating on the application layer (the highest layer of the OSI model), the application-level gateway, like the other filters mentioned here, intercepts and examines packets that come into, and go out of, the firewall. In addition, it runs proxies, which prevent direct connection between a trusted server or client and an untrusted host. The proxies are application-specific, and they examine the entire packet assembly (unlike packet filtering and circuit-level gateways that do not assemble packet sessions). Because each proxy is application-specific (for example, the HTTP proxy can only copy, forward, and filter HTTP traffic), packets may be unable to access services for which there is no proxy, depending on the security software that you choose. For example, if an application-level gateway only runs FTP and HTTP proxies, only packets generated by these services can pass by the firewall, while all other services are blocked.
This type of firewall therefore has a stronger security infrastructure, because:
1. It eliminates the need for a direct connection between a trusted client or server and an untrusted host.
2. It examines the entire packet assembly, including the assembled payload in context.
3. It facilitates the preferred “deny all unless explicitly allowed” policy by offering deep configuration options over how a protected application can be communicated with.
The proxies are able to filter particular information—on specific individual commands in the application protocols, the proxies are designed to copy, forward, and filter. For example, an FTP gateway could filter multiple commands to allow a high degree of granularity on permission levels for specific users of the protected FTP service.
Because it inspects the complete packet, and because it is application-specific (applications that do not have proxies installed cannot run), the application gateway is one of the most secure firewall architectures available. This type of firewall eliminates many different classes of attacks that could otherwise penetrate firewalls that operate only on lower levels of the OSI model.
Because it breaks the direct connection to the server behind the firewall, the application proxy eliminates the risk of an entire class of covert channel attacks. In addition, the application gateway, when run on a symmetric multiprocessing appliance, consumes only a negligible amount of processing and has little impact on network performance.
Simply described, the path of a packet across a strong application proxy is as follows:
1. The new packet arrives at the external interface. Layer 4 data is tested to validate that the IP source and destination, as well as the service ports, are acceptable to the firewall’s security policy.
2. For every “good” packet, a new empty datagram is created on the internal side of the firewall. This eliminates the possibility of an attacker hiding malicious data in an unused protocol header.
3. Protocol anomaly testing is performed on the packet to validate that all protocol headers are within defined protocol specifications.
4. The application proxy applies command-level controls and validates these against the user’s permission levels.
5. After the packet has been determined to be protocol-compliant and the application-level commands validated against policy, the permitted content is copied to the new datagram on the internal side of the firewall.
Intrusion Prevention Gateway
The best modern firewalls go beyond even the capabilities of the application-level proxy firewall with the addition of an integrated intrusion prevention system (IPS). This type of firewall not only examines the data contained in the application payload, but also interprets the intent of that data. Using a combination of pattern matching, heuristics, statistics, behavioral patterns, and reputation analysis, the IPS is able to “sense” malicious activity before it penetrates the network.
Most IPS gateways use a library of signatures, which contain signatures of malicious activity and known vulnerabilities, against which packets are compared as they cross the gateway. The best operation of signature databases will include an automatic frequent update to minimize “zero-hour” attacks that cross the network threshold before the signature has had a chance to make it into the database. However, the alarming frequency of new vulnerabilities and malicious attacks means that there is still a very high likelihood that something will be missed by the IPS. Therefore, an IPS that is strictly based on signatures is limited and exposes the network to an unnecessary risk. The IPS should be used as a complement to, and not a replacement for, an effective Application-layer proxy firewall defense. Furthermore, the IPS should go beyond signature-based defenses to also include predictive and reputation-based technologies that evaluate unknown risks and prevent “zero-hour” attacks.
Deep Packet Inspection
“Deep packet inspection” may sound advanced, but the name is somewhat deceptive. This type of firewall still does little more than inspect packets against outdated signatures, and does nothing to detect and prevent unknown attacks. The signature-based model has merit and it does afford a rapid response, but relying exclusively on a signature-based model is dangerous. A simple way to circumvent a deep packet inspection firewall is just to add a little white space in the data before or after a command. White space is usually tolerated by most applications, and the addition of a blank space or two would cause the signature to fail to match the signature database.
With hundreds of new vulnerabilities being detected every week, developing new signatures and adding them to the inspection database is a difficult task.
The deep packet inspection firewall, like most stateful inspection firewalls, focuses on finding, and subsequently denying, bad packets. In fact, the most effective approach, as demonstrated in strong application proxy firewalls, is to allow packets that are known to be good, and then deny everything else. Since most protocols on the Internet are standards-based, the best approach is to create an application proxy that is protocol-aware, and use the standards as the basis for deciding whether or not to admit a packet. The opposite approach taken by deep packet inspection leaves the network vulnerable, because it requires frequent updates whenever any new type of attack is unleashed.
Another major limitation of the deep packet inspection is the lack of protocol anomaly detection. These firewalls, unlike a strong application-proxy firewall, often still take the less secure approach of seeking out “bad” packets and dropping them, and then allowing everything else in that has not been identified as “bad.”
Unified Threat Management (UTM)
Unified Threat Management is the latest and most innovative development in firewalling. According to IDC, a leading analyst firm, UTM security appliances unify and integrate multiple security features onto a single hardware platform, including network firewall capabilities, network intrusion detection and prevention, and gateway anti-virus. Some UTM offerings go further, incorporating an anti-spam and URL filtering capability on a hardened operating system as well. The UTM segment is the fastest growing segment of the firewall market.
Reasons exist even beyond convenience and practicality for integrating multiple threat protection applications into the same appliance and under the same interface. Many modern attacks today are blended attacks, which do not utilize any one-attack vector exclusively. For example, a blended attack may target multiple protocols, such as e-mail (SMTP) and the Web (HTTP), and it may do this by first sending out an e-mail, (which in itself may not contain any malware) that then tricks the recipient into clicking a Web link. The recipient is then taken to an infected site, where the malware is downloaded onto the computer. Mitigation of this sort of attack can take place either in the e-mail messaging protection (anti-spam) application, which would recognize the nature of the attack, or in the second stage, when the user attempts to go to the infected Web site, it would be blocked by the URL filter.
The addition of URL filtering is an important part of UTM that is often not included by other UTM vendors. URL filtering is often a first line of defense, especially against zero-hour threats. In addition, spam has also grown into a complicated and dangerous threat, and it is imperative to reduce the risk of spam with a best-of-breed anti-spam capability integrated into the UTM appliance.
Summary
SCADA systems evolved out of isolated pneumatic and analog control systems and are simply not equipped to play a part in today’s Internet-connected Web 2.0 world. Even traditional network security procedures such as port scanning (to determine the open ports on a network-connected device) can wreak havoc within a SCADA network.
The first step in SCADA risk mitigation is establishing a SCADA network security policy. Second would be bringing all SCADA component software and firmware up to current stable revision levels. Next would be to eliminate the security issue with what has been regarded as the weakest link in SCADA—the interconnection to the corporate network. Significant risk mitigation can be obtained by installing a firewall between the SCADA network and the corporate network. However, care must be taken in the selection of the firewall architecture. Put simply, current popular solutions are not able to mitigate the risk that the SCADA network is exposed to when connected to the corporate network. The most effective firewall architecture at this time is a circuit-Level gateway that first breaks the client server model and then also applies IPS signatures for known attacks.
Solutions Fast Track
The First Step in Mitigating Risk in a SCADA Environment
The first step In risk mitigation is the development of a SCADA security policy. Once policies are in place, they must be continuously updated and monitored to account for changes in the SCADA network, SCADA component software updates, and (as with any enterprise network) the addition and subtraction of users (operators).
Eliminating Interconnection Risks with a Firewall
A great deal of the associated risk can be mitigated with the selection of the correct firewall. However, firewall architecture is critical to the amount of risk mitigation that will be gained. Simply put, the most popular firewalls in use today cannot afford any meaningful risk mitigation in a SCADA environment.
Resources
With the increased awareness of the need to secure SCADA in an effort to protect our critical infrastructure, a growing number of SCADA security resources are available on the Internet. The following list offers resources that the author has found useful.
The Center For SCADA Security, www.sandia.gov/scada/home.htm
DigitalBond – Securing Critical Infrastructure, www.digitalbond.com/
The Cyber Security Alliance, www.csialliance.org/issues/scada/
21 Steps to Improve the Cyber Security of SCADA Networks, www.oe.netl.doe.gov/docs/prepare/21stepsbooklet.pdf
SANS – Security for Critical Infrastructure, www.sans.org/reading_room/whitepapers/warfare/1644.php
Tennable Security – Nessus Plug-Ins for SCADA, http://blog.tenablesecurity.com/2006/12/nessus_3_scada_.html
IBM – SCADA Security Best Practices, http://www-935.ibm.com/services/us/index.wss/offering/iss/a1027203
Frequently Asked Questions
Q Why all the concern about SCADA security today?
A SCADA has evolved from proprietary pneumatic to proprietary analog systems and now today to digital systems interconnected over TCP/IP. In the shift away from the use of proprietary systems to the use of TCP/IP SCADA has lost a great deal of its historical Security-by-Obscurity. Further; today’s SCADA systems when connected to the enterprise network to share data with back-end systems effectively exposes the SCADA to all of the risks associated with the enterprise network and if that enterprise is connected to the public Internet then the SCADA is also then exposed to all of the risks of the public Internet as well.
Q How many SCADA security incidents are reported annually?
A The annual reporting to British Columbia Institute of Technology (BCIT) SCADA database for the past year was just over 100 verified incidents. However, security experts believe the actual number of incidents is between 2,000 and, 3000 because like network security–related incidents, they are under-reported.
Q Why can’t I download one of the open source network vulnerability scanners and run it against my SCADA network?
A SCADA systems more than five years old were known to have been placed in service with incomplete or missing TCP/IP error handling capabilities. A simple port scan could crash the SCADA network. So, it is recommended to configure a lab environment of “like” components and perform scans to determine if the components are vulnerable to error handling issues.
Q Why can’t I just install a popular firewall between the enterprise and my SCADA network to mitigate my SCADA risks?
A Today’s most popular firewalls are, in fact, popular because of their ease of use, and their low cost and low impact on the network—NOT because of the risk mitigation they provide.
Q What is the problem with connecting my SCADA system to the corporate network so we can use process data in our back-end systems?
A Connecting the SCADA system to the enterprise network poses nearly the same risks as connecting the SCADA network directly to the public Internet. Worms, viruses, and malware are common within the enterprise network and can be a major issue within a SCADA network. However, when connected to the enterprise network through a properly configured application firewall, these risks are minimized.
Q What is the first step in reducing my SCADA risks?
A As with network security, the first step is a security policy to define the ground rules.
Q There are so many kinds of firewalls, which one affords the maximum risk mitigation in the SCADA environment?
A Theoretically, an application-level gateway affords maximum risk mitigation. However, they do not currently offer full support for the many proprietary SCADA protocols and applications. Hence, a circuit-level gateway that first breaks the client server model and then also applies IPS signatures for known attacks is most effective.
Q Deep inspection is a popular firewall methodology. Why do you recommend not using it for SCADA?
A Deep inspection does not break the client server model. Thus, a malicious hacker would have a direct connection to the protected SCADA component. Deep inspection does not provide for any protocol anomaly detection, and in SCADA, due to historically poor TCP/IP error handling, even a poorly formed packet for a given protocol can wreak havoc in a SCADA network. Lastly, they rely upon a negative security model that can only protect against attacks for which it has a specific signature. Any packet that it cannot identify is simply passed along to the protected server.