Security Advisor
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.
- By Roberta Bragg
- 05/01/2004
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.
 |
| 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.