Securing your control system

 By Jay Abshier, CBCP, CISSP, and Joe Weiss, PE, CISM

hile the widespread deployment of Internet technologies has brought about efficiencies and new opportunities for productivity, it also carries significant risks, such as those posed by common software vulnerabilities and the consequent susceptibility of networked systems to Internet attacks. How to isolate and protect Supervisory Control and Data Acquisition (SCADA) systems from vulnerabilities inherent to the Internet while meeting common business requirements is a critical issue for control engineers and managers. Control systems utilized in industry include SCADA systems, Distributed Control Systems (DCS), and Programmable Logic Controllers (PLCs), all of which we will call SCADA systems.

The most troublesome vulnerability of SCADA systems arises with its increasing connectivity between automated control systems and Internet-based IT business systems. Particularly vulnerable are SCADA systems whose original engineering design never envisioned a connection to the Internet. Why? SCADA systems are evolving from proprietary products into standardized commercial-off-the-shelf (COTS) components, using open, Internet-based technologies with operating characteristics and vulnerabilities that are widely known. To achieve further economies of scale, vendors are now using the same product families of control system components across multiple critical infrastructures.

The Threat is Real
Richard Clarke, the former Cyber Security Czar for the White House, stated in an October 20, 2003 Computer World interview, “We do know that Norway and Israel at least are saying there were cyber-hacking attempts to bring down the power grids in their countries.”

The vulnerabilities of SCADA systems have resulted in many verified cases where control systems in oil/gas, electric power, water, paper, and manufacturing have been impacted. Most of these cases remain confidential, but some that have been disclosed include:
* The loss of a 1,000-MW hydro station in Asia,
* Hacking of a sewage treatment plant discharge valve in Australia (46 times before the hacker was discovered and caught) resulting in a release of millions of liters of sewage, and
* The recent Slammer and Blaster worms that impacted many electric and water utility control systems including Ohio's Davis Besse Nuclear Power Plant, as well as other industrial and manufacturing control systems.

The vulnerabilities are real, the threats are real, and now is a good time to review the basics of SCADA security.

In order to function securely, the SCADA system must be isolated from outside negative influences. A negative influence can be anything from an engineer requesting a massive amount of data to the high-volume of e-mail traffic generated by a hacker’s worm or virus. 

To accomplish this isolation, all of the machines associated with the primary function of the SCADA must be grouped together on a common network (the “Plant Control Network”), and be protected from other networks using an internal firewall.

Firewalls are built to regulate connections between machines inside the firewall and machines outside the firewall. Firewall rules can be written to allow any traffic, or to restrict traffic to only specific devices and applications. In order to be secure, the firewall should be configured to reject all connection requests either inbound or outbound. Then, as functionality is added to SCADA systems, new rules can be amended to specifically allow the connections required by new functionality.

The types of systems required to send data to the SCADA system will vary depending on the application. A good example is the Laboratory Information System (LIS), found in contemporary refining operations which periodically exchanges data associated with product quality and yield with the refinery's SCADA system. In our hypothetical situation, we will refer to the network that is home to the LIS as the Plant Information Network.

In order for the transfer of data to take place software agents on the SCADA system will need to talk, or establish a connection, with the LIS software. The new firewall rule should specifically identify the LIS system so that only it can use the rule.

Many companies have found that it is a best practice to require human review and explicit acceptance of data flowing from less secure systems (anything outside the control network firewall must be considered less secure than systems on the control network) before that data is allowed to contribute to SCADA control calculations.

Almost every employee needs access to corporate e-mail and at least some access to the Internet in order to perform their duties. These two business requirements are at best a mere distraction to the operator. The more problematic scenario appears when the operator inadvertently introduces a worm or virus to the control network by bridging the two networks. The firewall rules required to allow this type of access from the control network will also open the control network to floods of unwanted data generated by viruses and worms, even if the computers on the control network remain uninfected. Creating rules like this should be avoided.

In order to provide corporate e-mail and Internet functionality to the operators without compromising the control network, separate connections to the Plant Information Network should be available in the rooms housing the operators. Then workstations that only connect to the Plant Information Network can provide operator access to email and the Internet, disassociating those dangers from the Control Network.

Keep it Unplugged
Most vendors prefer modem access to equipment for remote software uploads and system diagnostics. In this situation, the telephone line to the modem should be left unplugged until service is required, and it should be unplugged as soon as the vendor terminates the connection. With appropriate security policies and enforcement, this can be an acceptable method if a company has employees on site when vendors need to perform the diagnostics. 

For companies that do not have employees on site 24/7 this can be a major issue, one that may require compromise from both the company's network security professionals and the vendor. Alternatives include a dial-back modem that calls back to a specific vendor phone number, password protected modems, encrypting modems, and SSL VPN connections. 

The dial-back modem is often not feasible because it requires the vendor to always provide the service from the same phone number. Password-protected modems are probably the most cost-effective method of protecting vendor access if you the phone line just cannot be left unplugged. The password-protected modem should support account inactivation after a set number of login failures (three or four is usually chosen) and capable of processing complex passwords. In general, a complex password does not contain words found in ANY dictionary. A complex password  might contain the acronym of a password phrase imbedded with special characters (My Dog Has Fleas 247). Simple to create and easily remembered. 

The primary purpose of the encrypting modem is to keep the traffic flowing between two modems confidential. It is attractive in this situation because the same manufacturer must make the modems that establish a connection and share the same secret key. This greatly reduces the chance unauthorized personnel connecting to the SCADA system.

Defense-in-Depth
Another way to out-maneuver hackers is to locate an SSL VPN (Secure Socket Layer Virtual Private Network) appliance on your network's DeMilitarized Zone (DMZ – established by a firewall that separates two networks). Access rules on the SSL VPN can restrict the vendor to the specific device for which they are responsible. This method is more costly, but adds security value because you can eliminate modems and centrally manage all vendors through a single gateway. It is a best practice to never allow vendors access to devices on the control network unless it is explicitly granted and their activity monitored while performing service.

SCADA data is required by related systems on diverse networks, such as the LIS mentioned earlier. Plant managers usually want a high-level dashboard view of what is happening, and regulatory agencies sometimes require access to data, such as the data from emissions monitoring systems. The model that works best for satisfying this business requirement is similar to the one we used for transferring data from the LIS system to the SCADA system, but this time the transfer is reversed.

This model requires that “copies” of the data collected and calculated by the SCADA system are established at less secure levels of the plant and corporate networks. Multiple levels or copies can be established based on requirements. By copies, we do not mean exact duplicates, but databases with relevant data based on the SCADA database: 5-minute averages or hourly averages instead of each time-stamped instance of a variable. See Figure 4 for an example.

In order to maintain control network security, data should be pushed from the control network to the next lower level of security, usually the plant network. If another level of security is required, such as data needed by a partner or a regulatory agency, then this data should be pushed from the plant network to the next lower level of security.  

Historically, this model has been implemented using proprietary code, but fortunately, vendors have developed commercially available products around this concept--such as Wonderware and OSI PI databases.

Avoid Remote Access When Possible
Operator remote access should be avoided. Once remote access (other than the limited access recommended for vendors) is established, it is very difficult to guarantee the immunity of the control network from hackers, and viruses, worms, and other malicious code produced in the wild by similar malcontents. 

If denying remote access is just not possible, the first alternative to explore is installing a dedicated line from the operator’s remote location to the control network. Providing a computer dedicated to the control function to is also highly desirable. If operators uses their personal home computer, the likelihood increases that it will become infected or compromised in some way, and the control network can then be compromised. 

If the control functions of the SCADA are web browser-enabled, locating an SSL VPN appliance at the DMZ which encrypts the connection between the operator and the Control Network is a feasible alternative. To add that extra measure of security, the operator will need high-speed Internet access, and required to take additional network access steps, such as frequently-expiring, complex passwords that  disable after a set number of failed logon attempts. The added value of this solution is that, unless you allow the operator to upload files to the SCADA system, you have shielded the SCADA from malicious code or viruses on the operator’s remote computer. 

If neither of the first two alternatives is viable, then the third option would be to establish what is commonly known as a 3DES or AES encrypted IPSec VPN. IPSec is a relatively new method of encapsulating communications over the Internet, and 3DES and AES refer to accepted algorithms for encrypting the packets. The tunnel that is established is almost guaranteed to be impervious to hackers. 

Like the SSL VPN alternative, this one requires some expensive hardware on the DMZ. Unlike the SSL VPN, the IPSec VPN can expose the control network to malicious code or unauthorized access via the remote computer, unless strict controls are maintained on the computer the operator uses. This setup also usually requires the operator’s remote computer to run specialized client software. 

A third element, or "factor" should be required for operator authentication when the operator is not physically located in a secured control room. The first two factors are the UserID and the password (something the operator knows). Common third-factor authenticators include USB port-enabled tokens, smart cards, or bio- characteristic ID such as a voice or thumbprint.

Wireless Communications
While SCADA operators in a refinery or chemical plant setting may not have a driving need for deploying wireless communication systems, for certain applications, such as a production field site or a remote pipeline pumping station they are almost essential. In some cases, there is almost no other cost-effective way to feed data points from geographically distributed sensors to the SCADA system.

In their off–the-shelf, easy-to-use configuration, Wireless Access Points (WAPs-- the wireless point of entry into the Control Network) are a security nightmare. They accept signals from any direction, and if antennas are used to boost the signal strength, the client could be miles away. Anyone with a laptop or PDA and inexpensive transmitter and antenna would have access to your control system. 

The least secure option is to use a static key Wired Equivalent Privacy (WEP). WEP is a weak method of encrypting the communications between the wireless client (in our case sensors) and the Wireless Access Point. It is weak because it can be broken in a matter of hours, but it is better than plain text communication. 

Dynamic WEP will do a much better job in protecting your wireless access point. Dynamic WEP changes the WEP encryption keys after a random number of bytes have been transmitted, thus making the attempt at breaking WEP more difficult. In fact, using Dynamic WEP in a wireless SCADA environment should be considered essential.

A more secure alternative to using Dynamic WEP is to force all communication from the WAPs to go through a device that enforces strong IPsec 3DES encryption on all wireless traffic. However, this can be probitively expensive and usually not necessary for this scenario.

A second step that can be taken is to use a WAP that allows you to specify the machine addresses (MACs) that are allowed to communicate with it. Combining dynamic WEP while restricting access to specific MAC addresses is usually sufficient security for this type of environment.

By incorporating the above steps, one can effectively make it difficult, if not impossible, for someone to gain unauthorized access to your Control Network via the WAP, but we have not dealt with electronic interference that may interrupt the availability of sensor data. Interference from either a malicious source or naturally occurring phenomena could still interrupt the signals from the sensors to the SCADA system, and thus compromise control. To offset this problem, system specifiers should consider deploying directional antennas, microwaves and/or other technologies that boost the signal strength from the sensors and ensure the WAP only receives signals from the sensors.

Security Policies, Standards, and Guidelines
Standards are specific actions or procedures that must be followed to ensure network security policy is maintained. For instance, a strong security policy standard might be: “All user IDs for the Control Network must be approved via the "XYZ" process. Guidelines, on the other hand, are specific actions or procedures that should be followed to ensure security policy is followed. For example, operators might institute this guideline: “On the SCADA System, user IDs  should start with OP for operators and CE for control engineers.” 

Sample categories for which security policies, standards, and guidelines should be developed include Authentication and Access Control, Access Control Administration, Network, Wireless, Remote Access,  Application, Systems, Encryption and Exceptions to Policy. For additional information, The American Petroleum Institute Recommended Practice 554 for Process Control Systems and ISA’s Process Control Cyber security Committee SP99’s ISA-dTR99.00.02, Integrating Electronic Security into the Manufacturing and Control Systems Environment are good resources for SCADA system best practices.

here is no accepted standard methodology for an IT Risk Assessment. In fact, it is difficult to develop a methodology at all. A Risk Assessment will examine specific categories or aspects of an IT system but will ultimately rely upon the skill of the assessor to ask the right questions and dig deeper where required. 

Authentication and Access Control
Describe how user access to the control network and SCADA system is limited. This can include restricting IDs to specific individuals, restricting levels of access for specific individuals, and physically securing the system, etc.

Access Control Administration
Describe how user IDs for the control network and SCADA system are administered (i.e., who can request, how requested, who approves, who implements, how are IDs removed, terminations, etc.).

Data Flow/Storage
What steps are taken to ensure that unauthorized individuals are not able to gain access to the data?  This is different from access to the control network or SCADA system. The data may have further access restrictions. What steps are taken to ensure that unauthorized individuals are not able to modify the data? If data is altered or corrupted, identify all checks and balances used to detect this and correct.

System Administration
Describe the process and procedures for administering the system from an operating system perspective (i.e., identification and testing of upgrades, application of the upgrades, access to the system by system administrators, etc.) This should include disaster recovery plans, backup procedures and tests, etc.

Application Administration
Describe the process and procedures for administering the system from an application perspective (i.e., identification and testing of upgrades, application of the upgrades, access to the system by system administrators, etc.) This should include disaster recovery plans, backup procedures and tests, etc.

Architecture
Describe how the system fits into the overall infrastructure, whether circumstances warrant additional security procedures (i.e., perimeter access, remote access, connected to wireless access point, etc.) and steps taken to mitigate additional risk because of this circumstance.