System Control And Data Acquisition: Difference between revisions
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
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
- ↑ 1.0 1.1 Wooldridge, Scott, "SCADA/Business Network Separation: Securing an Integrated SCADA System", automation.com
- ↑ Mark Underwood (20 July 2010), "Network admins must beware of Stuxnet: A SCADA System worm", TechRepublic
- ↑ SCADA Serial Link Protection
- ↑ Arnone, Michael (8 May 2006), "SCADA on thin ice: Industrial control systems pose little-noticed security threat", Federal Computer Week
- ↑ NERC History
- ↑ Power Systems Engineering Research Center (PSERC)
- ↑ Real-Time Grid Reliability Management
- ↑ Idaho National Laboratory, U.S. Department of Energy (May 2010)