System Control And Data Acquisition

This article may be deleted soon.

|  | To oppose or discuss a nomination, please go to CZ:Proposed for deletion and follow the instructions.

For the monthly nomination lists, see Category:Articles for deletion.

| Main Article
| Discussion
| Related Articles  [?]
| Bibliography  [?]
| External Links  [?]
| Citable Version  [?]

|
|
|
|
|
|
|
|

This editable Main Article is under development and subject to a disclaimer.

[edit intro]

## Contents

* 1 SCADA security and reliability have unique aspects
* 1.1 Security policy
* 1.2 Vulnerability assessment
* 2 SCADA-specific protocols
* 3 SCADA, critical infrastructure, and terrorism
* 4 Isolation
* 5 Reliability research for electrical grid control
* 6 Vulnerability research
* 7 References

Supervisory Control and Data Acquisition (SCADA) systems are computer-controlled, human-monitored systems for collecting and analyzing data, and then controlling the configuration and actions, of real-time process control systems. Such systems include geographically distributed utilities such as electrical power grids and interconnects, pipelines, highway traffic control, water flood control, etc., where they are part of critical infrastructure. SCADA systems are also used in manufacturing, especially when hazards of the process make remote control much safer for the staff than working next to smelting, petrochemical refining, or radioactive substances.

Since they deal with real-time events, the hardware and software configuration of the SCADA system must be under strict change control, with thorough testing and simulation of proposed changes. Highly reliable real-time computing requires a well-understood workload for the sensors, device controls, alarms, etc., so a SCADA system absolutely must be completely isolated from any general-purpose computer system or network. The workloads in general-purpose systems, meant for flexibility, are inherently unpredictable and introduce too much risk into SCADA operation.

Even in isolated environments, SCADA implementations must, consistent with the hazards involved, follow best current practices for fault tolerance. There must be no single point of failure that can cause a catastrophic failure. More than simple backup may be required; automated decisions, based on sensors, may need to be implemented with an odd number of decision elements employing voting logic. With such logic, the safety analysis for each situation is unique: in some cases, the highest level of life safety means giving the "minority voter" a veto power, such as shutting down an irradiation system if any sensor determines that excessive radiation is being delivered. In other cases, majority rule is appropriate coupled with urgent alarms for human resolution of ambiguity.

Unforeseen circumstances, or insufficiently fast system response, has led to catastrophic responses to natural events.

## SCADA security and reliability have unique aspects[edit]

"It should also be understood when dealing with the SCADA infrastructure that there are commonalities and differences between SCADA-related IT security and IT security focused on typical business systems. For example, in a business systems environment, access to the server is typically the key focus. Whereas in a SCADA environment, the access focus is at the operator console level. This difference produces both alternate network topologies to provide the necessary availability as well as a different focus on what elements of the SCADA system would be of highest priority to safeguard against security breaches."[1]

### Security policy[edit]

Any policy should begin with a statement of the risks of failure. Failure, either from accident or design, in the electrical grid will cause major risks to life.

From the technical standpoint, a very good policy is that no active element in the SCADA network proper should have any direct connectivity to the Internet. Very carefully designed and audited exceptions might be made for encrypted tunnels, but they should be exceptions.

This does not preclude software updates being obtained, from vendors, by a separate Internet-connected system, and the software, after authenticating cryptographic checksums, can be physically transported, on storage media, to a single SCADA distribution point.

### Vulnerability assessment[edit]

Even assuming no Internet connectivity, there are still malware threats to SCADA systems.[2]

## SCADA-specific protocols[edit]

"An adversary with access to the communications link can easily inject false commands into the system to actuate valves, trip breakers, etc. This project seeks to devise and standardize a cryptographic protocol to protect SCADA communications from cyber attack while minimizing negative impact on SCADA system operation."[3]

## SCADA, critical infrastructure, and terrorism[edit]

While SCADA may serve as the means to stop an impending catastrophe, it also gives the capability to create one. The Chernobyl disaster was caused, in part, by an extremely unwise test of the facility overriding some of the SCADA controls that otherwise might have stopped the reactor runaway. That situation was not a deliberate attempt to cause a disaster, but system control engineers are very aware that a technically qualified terrorist, with authorized SCADA access, could cause far more damage than traditional sabotage.

## Isolation[edit]

SCADA for critical infrastructure needs to have checks and balances on human error and deliberate human attack. Attacks from the Internet or other external sources should never be possible; the same kind of isolation as used for high-security military networks is mandatory. Less obvious "back doors", however, have included unwise use of wireless local area networks (WLAN).[4]

Other lessons from the military include some of the protections against accidental war or nuclear events, such as requiring multiple people, at multiple sites, to agree to a critical action. The "no lone zone" principle used with nuclear weapons and nuclear command & control is appropriate; no single person is ever allowed access without being monitored by at least one other cleared person.

Managers more concerned with cost than engineering safety may be tempted to share SCADA resources with general corporate computing. [1]

## Reliability research for electrical grid control[edit]

This is a continuing area of research and process improvement with respect to electrical grids, and the situations under which a SCADA system should shut down a questionable section to protect the larger power grid. In the U.S., for example, the North American Electric Reliability Council[5] coordinates the work of 8 regional grids, and is overseen by the Federal Energy Regulatory Commission.

With National Science Foundation sponsorship, the Power Systems Engineering Research Center (PSERC) is an academic consortium that works with industry and government to understand past system behavior and optimal response to unforeseen situations. [6] One project, for example, is the development of Real-Time Grid Reliability Management simulations and operational tools.[7]

## Vulnerability research[edit]

In 2010, an analysis of electrical power SCADA vulnerabilities was conducted, by the Idaho National Laboratory, for the the U.S. Department of Energy Office of Electricity Delivery & Energy Reliability (DOE-OE) National Supervisory

Control and Data Acquisition (SCADA) Test Bed (NSTB) program. 24 assessments performed under the NSTB program from 2003 through 2009 reported

> large [Industrial Control Systems] ICS [have] attack surfaces created by excessive open ports allowed through firewalls and unsecure and excessive services listening on them. Well-known unsecure coding practices account

> for most of the ICS software vulnerabilities, which result in system access vulnerability or Denial of Service (DoS). However, poor patch management provides more likely attack targets because the vulnerabilities are public and attack tools are available for them. Once ICS network access is obtained, status data and control commands can be manipulated as they are communicated by unsecured ICS protocols. Perimeter defenses cannot mitigate threats associated with required services between security zones. Vulnerabilities in Web services, database applications, and data transfer protocols can provide attack paths through firewalls. ICS network protocol applications can also be exploited to gain access to ICS hosts. Weak

> authentication and integrity checks allow unauthorized control or data manipulation, once ICS network access has been obtained.

> NSTB assessments indicate that the biggest security threats to ICS in the energy infrastructure can be mitigated by patch management, eliminating unnecessary and nsafe services, implementing strong authentication and integrity checks to network protocols, and securing applications that accept network traffic. Secure configurations and network layers of defense can then be used to protect these critical assets. [8]

## References[edit]

1. ↑ 1.0 1.1 Wooldridge, Scott, "SCADA/Business Network Separation: Securing an Integrated SCADA System", automation.com
2. ↑ Mark Underwood (20 July 2010), "Network admins must beware of Stuxnet: A SCADA System worm", TechRepublic
3. ↑ SCADA Serial Link Protection
4. ↑ Arnone, Michael (8 May 2006), "SCADA on thin ice: Industrial control systems pose little-noticed security threat", Federal Computer Week
5. ↑ NERC History
6. ↑ Power Systems Engineering Research Center (PSERC)
7. ↑ Real-Time Grid Reliability Management
8. ↑ Idaho National Laboratory, U.S. Department of Energy (May 2010), NSTB Assessments Summary Report: Common Industrial Control System Cyber Security Weaknesses, Office of Electricity Delivery & Energy Reliability (DOE-OE) National Supervisory Control and Data Acquisition (SCADA) Test Bed (NSTB)