The Hidden Risks of Process Controls

These networks aren’t well known by many, yet they’re responsible for controlling much in our lives. And they’re not very secure.

What are the most powerful networks in the world? Those that run the government offices of powerful nations? Those that connect the offices, employees, customers and suppliers of Fortune 500 companies or international commercial ventures? Banking networks? The CIA? FBI?

The most powerful networks in the world aren’t data networks—they’re process control networks, which control the operation of devices. They may be heating and cooling (HVAC); building security; factory machinery; water supply; power grids; phone networks. A sample listing of what process control networks handle would include:

Pumping air in a building.

Controlling lighting during surgery.

Controlling locks on office doors.

Regulating flow of oil and gas.

Handling manufacture of paper and power.

Controlling traffic lights and systems of major cities.

Regulating the seat-belt warning, ABS and engine management systems on your car.

Some day they’ll control nearly every critical and non-critical function where automated controls can be used. These control networks may have just a couple of nodes, or potentially millions of them.

So what should we be doing to prevent some evil genius or a 14-year-old with a twisted sense of coolness from disrupting essential services, endangering lives or playing Russian roulette with the building controls of our offices?

The Basics
In my house, an automated thermostat controls the operation of my heating and air conditioning. I use a simple wall-mounted device to program desired temperatures, time of day and days of the week. Sensors detect room temperature and actuators, directed by a simple decision-making computation, turn heat or air conditioning on or off to maintain temperatures. It’s convenient and hasn’t needed repairs or adjustments. HVAC systems that control larger buildings and other process control systems that manage the operation of manufacturing, mining and core infrastructure systems are, of course, more complex. Still, the same principles are in effect. Sensors provide information used in decision-making. Actuators make changes in response to automated or directed control decisions. A human interface system is provided for operations, monitoring and maintenance. Unlike my simple system, however, most process control systems are part of control networks.

Control networks use standard protocols to communicate over different types of media. Older process control networks used proprietary protocols over RS-232 and RS-485 serial communications networks. The decision-making or control devices were also proprietary and programmed using proprietary languages. Remote maintenance was either not performed or primarily accomplished over dial-up. These networks didn’t interface with data networks.

Today’s process control systems often run on Windows NT or XP and are connected to data networks. Device control mechanisms (those simple, inscrutable black boxes that are physically close to or part of the actual physical system and may monitor and make adjustments on their own) may also still be proprietary, but are accessible to administration stations over TCP/IP networks via gateways that convert and filter communications. Furthermore, many devices now include the capability to use IP as the transport mechanism for serial communications or are directly accessible using TCP/IP to permit control and reporting functions.

The rationale behind using the data network to provide control of process control systems is classic. It reduces cost; increases the ability for distributed control; eliminates a single point of failure for monitoring; enables better, more efficient, more coordinated control and monitoring of distributed mechanisms; and increases the distance over which control can be performed. (Many offshore drilling rigs, for example, are now unattended. They’re controlled via radio communications from remote land-based administration centers.)

SCADA and DCS
Different types of control networks exist. You may have heard about supervisory control and data acquisition (SCADA) networks. These networks are used to control the operation of critical infrastructure services. SCADA systems are typically managed over a local LAN, although they may be connected with other SCADA systems via satellite, leased line, PSTN or Internet.

Another type of control network is DCS, or distributed control system. These networks typically locate main administrative functions in one place, but control distributed devices at remote locations. The figure below illustrates a sample network.

DCS network sample
A sample distributed control system (DCS) network. (Click image to view larger version.)

Not Designed With Security in Mind
Like data networks, control networks were originally developed for business and convenience reasons. They were developed with little consideration for security or with primary security considerations being physical. They were conceived by people whose expertise is in the process side, not the IT side.

Security for the majority of devices in operation today is non-existent or turned off. Like data systems, process control devices and applications are generally shipped with security functions disabled to make installation easier. Because installers may not be properly trained, and organizations may lack any knowledge of security requirements, security features may not be implemented or will continue to run with defaults still set. On many devices, security consists of the ability to password-protect access. IT personnel are at a distinct disadvantage, as they may not recognize the security issues. The use of the data network as a transport for control networks doesn’t appear to offer any increased threat for the IT network, and the technologies used in control operations are foreign to most IT employees.

When the individuals who should be most concerned with the secure operation of these devices—process control engineers and IT systems administrators—are not only not aware of the risks, but have no basis for extended communications, and their management shares their naiveté, it’s only a matter of time before accidental or malicious use of these networks results in disruption of services or, at worst, loss of life and limb. It’s also possible to envision the scenario where such intrusion results in the economic collapse of the organization.

In addition to these general risks, a threat model has been developed by the National Institute of Standards (www.nist.gov) in coordination with the Process Control Security Requirements Forum and included in the document, “IT Security for Industrial Control Systems.” You should note that the document indicates the list was developed using Common Criteria. Common Criteria is an international standard for developing specifications for secure information systems. You can and should visit the NIST site for more information and to follow the development of standards for process control network security. A listing of the threat model is below.

The Threat Model
The following threat model was developed by the National Institute of Standards. The examples following the description are mine.

Administrative errors. Directly compromise systems or weaken the technical security policy. Example: turn off password protection.

Administrative errors of omission. Failure to perform a security function. Example: using default passwords, not using secured communications.

Hostile administrator modification of, or use of, data. Malicious modification, obstruction of security, or weakened security to allow or directly perform security violation. Example: providing administrative passwords to unauthorized individuals. Publishing of network specification or security controls to a public web site or chat room.

Administration violation of user privacy policy. Obtains and uses user-sensitive information. Example: administrators of control systems may have elevated privileges on the network that provides them access to this information. They might publish it on the Internet or otherwise reveal it or use it for personal gain.

Critical system component failure. System failure results in loss of system-critical function.

Software contains security-related flaws. Code doesn’t perform to specifications or has security flaw.

Failure of distributed system component. Failure means other parts can’t function or the information received is incorrect

Hacker undetected system access. Potential violation of integrity, confidentiality, and availability. Example: individual finds telephone number for control system, and because there are no security controls, is able to connect to the network.

Hacker attempts resource denial of service. Executes commands, sends data, or other operations that make system resources unavailable to users.

Hacker eavesdrops on user data communications. Obtains data which may or may not provide ability to disrupt services or otherwise cause harm.

Cryptanalysis for theft of information. Hacker performs cryptanalysis on encrypted data in order to recover message content.

Hacker masquerading as a legitimate user or as a system process. Obtains valid system credentials and performs operations that will be attributed to the real, authorized user or system process.

Message content modification. Hacker intercepts and modifies information being sent between entities (devices or individuals). The recipient doesn’t know a change has been made. Example: this process could be used to initiate overrides to automated controls, to communicate invalid data that might make an operator override automated controls, or otherwise disrupt or control operations.

Exploitation of vulnerability in the physical environment of the system. Compromise of systems by physical attacks. Example: obtaining access to facilities and performance of control at the device, or physical access to resulting in compromise of an administrative workstation.

—Roberta Bragg

Easy Targets
Process control systems are increasingly integrated with data networks, have few access controls configured and the proprietary nature of their processing doesn’t block a determined attacker. In fact, the primary security for many of these systems is obscurity, a function that only deters access. The function of these systems—even the technical operation and programming of their interfaces—is widely documented on the Internet, and former and current employees of the organizations that use them and develop them also provide a knowledge base.

In contrast, information on how to secure these systems and on the results of industry research into standards is often hard to find, requires membership in particular organizations and is protected from public quotation or reference even when publicly available.

29 Things You Can Do
All is not lost yet, however. Many process control engineers and their IT counterparts are working on securing process control systems. They, and you, now have many places to go to learn more about process control networks and engage in a discussion of how to secure them. It turns out that securing these systems does present unique challenges, but that good security is good security no matter the system. The following list is adapted from several resources: The President’s Critical Information Protection Board, the Department of Energy’s “21 Steps to Improve Cyber Security of SCADA Networks,” and discussions with those actively engaged in managing process control networks. The security principles pertinent to protection of data networks also have broad applicability in developing and implementing sound security policy and technical controls for process control systems and networks.

1 Don’t assume the only process control networks needing security are those controlling critical infrastructure. You may not work for an electric, gas, water, communications, financial or other critical industry, but I’m willing to bet you have process control networks in your organization. They all need security.

2 Identify process control networks in your organization. You can’t protect what you don’t know about.

3 Document network architecture. Identify critical systems, including those that may contain sensitive information. Include process control functions such as administrative stations, gateways and intelligent devices. In addition, many process control networks have a centralized database of control information that includes configuration and data records.

4 Identify all connections to the process control networks. Connections may be via gateways to IP networks, radio, satellite, wireless, PSTN, leased line and modem. Investigate all possible connections and determine to what they provide access. Determine who has access to them and why.

5 Remove unnecessary connections. Are partner, regulatory or vendor connections necessary? Is it possible to isolate the control network? Some plant operations may reside on their own network but be arbitrarily connected to the data network. If there’s no good reason for the connection, disconnect it.

6 Secure necessary connections by using available process control network gateway security, device passwords and physical security.

7 Require a review and sound security analysis to be performed on requests for new connections.

8 Implement standard, strong encryption protocols such as 128-bit AES, RSA 1024-bit and SHA-1 to ensure the integrity and confidentiality of communications, both on the process control network and in communications between it and administrative stations.

9 Require use of hardware-based keys such as smart cards, RSA tokens or USB-based devices

10 Implement firewalls to guard access to process control networks.

11 Implement intrusion detection (IDS) systems to monitor networks and devices for unauthorized access. Provide around-the-clock monitoring.

12 Provide intrusion response “red teams” with knowledge of process control networks and how to recognize and respond to incidents. Prepare policies and procedures.

13 Remember the most basic security principal—security is only as good as its weakest link. How secure is your data network? When you protect your data network, you reinforce security for your process control networks and vice versa.

14 Remove or disable unnecessary services on process control networks and devices. Examples of unnecessary services may be automatic meter reading/remote billing, Web and e-mail and Internet access.

15 Require process control device and network vendors to identify secure configurations for their products and to support secure configurations of operating systems used for their devices. Examples of this are support for OS patches and software that follows OS application development standards.

16 Require vendors to support security. Secure configuration and operation shouldn’t void warranty or support contracts.

17 Require vendors to disclose all backdoors, system overrides or vendor interfaces and provide the ability to block access via these.

18 Don’t rely on proprietary protocols for security. These protocols can be learned as easily by an attacker as by authorized users. They may be more at risk, since they haven’t been reviewed for security vulnerabilities.

19 Implement security provided by process control systems and insist on systems with security controls.

20 Perform technical audits of devices, networks and connected networks. Identify security concerns and address them. Look for active services, security patch levels, common vulnerabilities and compliance with your security policy. Re-audit systems after correcting problems. Audits should consist of inspection and penetration testing. (Be aware that common penetration testing tools may themselves disrupt service on process control systems.) Proceed with caution and test isolated or test systems. Vendors are increasing their support for the testing of patches and vulnerability testing applications in test labs at their locations. Ask for information and insist on this type of support.

Additional Information
Organizations and resources for further information on process control systems, networks and process control security include:

21 Perform risk assessment. Develop threat models and make process control systems a part of your organization’s continuing risk assessment process.

22 Include process control in your business continuity and disaster recovery plans and operations. Don’t forget to back up critical configuration and data.

23 Define security roles for process control administrators, IT administrators, managers and users. Provide sufficient authority and access. Provide security awareness training that includes coverage on how to identify and avoid social engineering attacks and whom to notify for any questions or perceived security incidents. A clear definition of response roles and responsibilities should be defined for each role.

24 Use defense in-depth. Defense in-depth is important for any security strategy. It limits the impact of a security incident, provides time for a response and may block intrusion because of the combined skills necessary to penetrate all defenses.

25 Develop and use a clear cyber security policy and program. Security for process controls must be supported by the entire organization.

26 Establish and manage proper configuration and change management, including patch management. Consistency, review and documentation are essential here. One of the largest issues in security for process control is the same as that for data systems—the management of security patches. Many of these systems run on, or are administered from, Windows systems. It may not surprise you to learn that many may still reside on Windows NT 4.0 SP3 systems. The problems may be due to a lack of patching, but they may also result from problems with proprietary device drivers that are affected by patches. This is a problem than can be resolved, but isn’t going to be fixed by a simple “patch it now regardless” directive.

27 Provide physical security for process control systems, gateways, and administration stations. Provide “tamper evident” packaging and controls. An example of tamper evident packaging can be as simple as a physical lock. To open devices without a key or code, the lock must be broken. A broken or damaged lock would be evidence of tampering.

28 Obtain and highlight senior management’s support and expectations for cyber security performance. Without it, any security program can fail.

29 Hold individuals accountable for their actions. The consequences of non-compliance with security policy should be clear and enforced.

Featured

Most   Popular