System Control And Data Acquisition: Difference between revisions

From Citizendium
Jump to navigation Jump to search
imported>Howard C. Berkowitz
imported>Howard C. Berkowitz
No edit summary
Line 51: Line 51:
  | url  =http://certs.lbl.gov/certs-rt.html
  | url  =http://certs.lbl.gov/certs-rt.html
  | title = Real-Time Grid Reliability Management}}</ref>
  | title = Real-Time Grid Reliability Management}}</ref>
==Vulnerability research==
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 <blockquote>large ICS [Industrial Control Systems] attack
surfaces created by excessive open ports allowed through [[firewall]]s 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.</blockquote><blockquote>


NSTB assessments indicate that the biggest security threats to ICS in the energy
infrastructure can be mitigated by patch management, eliminating unnecessary and
unsafe 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. <ref>{{citation
| url = http://www.fas.org/sgp/eprint/nstb.pdf
| NSTB Assessments Summary Report: Common Industrial Control System Cyber Security Weaknesses
| date = May 2010
| author = [[Idaho National Laboratory]], [[U.S. Department of Energy]]
| publisher = Office of Electricity Delivery & Energy Reliability (DOE-OE) National Supervisory
Control and Data Acquisition (SCADA) Test Bed (NSTB)}}</ref></blockquote>
==References==
==References==
{{reflist|2}}
{{reflist|2}}

Revision as of 10:11, 2 August 2010

This article is developing and not approved.
Main Article
Discussion
Related Articles  [?]
Bibliography  [?]
External Links  [?]
Citable Version  [?]
 
This editable Main Article is under development and subject to a disclaimer.

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.

  • Look at CMU SEI work

SCADA security and reliability have unique aspects

"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

Vulnerability assessment

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

SCADA-specific protocols

"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

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

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

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

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 ICS [Industrial Control Systems] 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 unsafe 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