SCADA security and understanding the risk impacts
- 01 May, 2013 11:44
Cyber security threats are on the rise. As a result, there is a focus on systems managing the critical infrastructure that everyone depends upon. Critical infrastructure is loosely defined as assets essential for the economy and overall society to function.
Among items considered to be critical infrastructure are:
- Manufacturing, logistics and transportation networks
- Generation, production and delivery of energy and utilities including water, oil, gas, and electricity
- Telecommunication services
- Agriculture, food production and distribution.
Both public and private sector organisations operating these systems are increasingly under attack. Mandiant, a U.S. based security firm, released a report in February 2013 that discusses a Chinese military hacking unit. They believe this group (known as “Unit 61398”) were involved in a recent attack on a company with remote access to more than 60 per cent of oil and gas pipelines in North America. If the attack was carried out to maximum impact, it could have had far-reaching consequences on energy supply and the environment across the US and Canada.
Systems that manage operational aspects of critical infrastructure are commonly known as Supervisory Control and Data Acquisition (SCADA) systems. SCADA systems are part of a larger grouping known as “Industrial Control Systems” (ICS), “Process Control Systems” (PCS) or “Real-Time Systems” (RTS) – they are used for controlling and monitoring the logical processes, including physical operations, which the delivery of critical infrastructure is dependent upon.
Failure or security breaches of these systems could result in wide-reaching adverse impacts, not only for the organisation, but for the community and economy at-large that depends on their goods or services. For example, wide-scale blackouts due to a failure of the electricity grid or an environmental disaster such as an oil or sewage pipeline releasing its contents, plus any collateral impact. For the remainder of this article, SCADA will be used to refer to all of these systems.
Because of the importance of SCADA systems, they have become a target for those wishing to create significant harm. Examples include:
Maroochy Shire (QLD) Sewage Spill
In early 2000, a developer with a company that implemented a system to manage the Shire’s sewage left his position due to a strained relationship. He was also turned down for a related job by the Shire Council. In an act of revenge against both the company and the council, he used a wireless radio transmitter to remotely break into the sewage treatment system and alter electronic data on the SCADA controller for the pumping station, causing malfunctions. 800,000 litres of raw sewage was dumped into local rivers and parks.
In June 2010, a worm was created that specifically targeted Siemens SCADA industrial software and equipment operating at Iranian nuclear facilities. Although the worm was intended for a specific target, it leveraged Windows and a USB flash drive, and had the capability to spread indiscriminately. This raised awareness of possible collateral damage against any other organisation running equipment from the same SCADA system supplier, even if they’re not the intended target.
SCADA was not the target, but…
Unlike Stuxnet, many malware infections and other incidents impacting SCADA are not targeted attacks. The following are cases where SCADA systems were infected because of connectivity or other factors. The resulting outages had a visible impact on the organisation or the areas they served:
CSX Train Signaling System
In 2003, the SoBig virus spread via a major e-mail infection outbreak and it impacted the train signalling systems at CSX Corp, which manages a large number of train lines across the eastern United States. Signalling, dispatching and other related systems at CSX were impacted, causing a 2-hour signals outage and resulting in delays for both transport and commuter trains within their territory.
Zotob Worm and Chrysler
In 2005, 13 Chrysler manufacturing plants had to be shut down due to the Zotob Internet Worm. Even though Chrysler’s manufacturing control network was separated from their corporate systems and Internet, the worm spread into the control network via an infected laptop that was connected to it. The worm then spread, leading to assembly line shut-downs. 50,000 assembly line workers were forced to cease all automobile production and be idle for about an hour.
Connectivity is increasing
Historically, security in the world of SCADA was managed by the principles of “security by obscurity” and what is referred to as “the air gap”. As these systems used proprietary obscure protocols that not many people other than specialist engineers understood and were isolated from other networks, an air gap existed that reduced the risk of SCADA systems being compromised and exploited. Security was never a consideration due to their isolation and the focus on process control, safety and reliability.
Connectivity to corporate IT networks is now increasing due to use of common technology standards and network protocols such as IPv6, data requirements to enable better decision making, and improved management capabilities through the leveraging of corporate IT management platforms and staff. With this increased connectivity comes increased risks and opportunity for a security breach of the SCADA network, or adverse and unintended consequences due to accidental human error.
Managing and architecting SCADA security
Edith Cowan University published a 2010 study assessing different organisational models for critical infrastructure providers, and the level of involvement from corporate IT managing the SCADA environment and security. After assessing security controls implemented at the organisations against published SCADA security best practices, the paper concluded the organisations that depended on corporate IT to manage their SCADA environment and security (either whole or in part) were not adequately protecting their SCADA/process control systems – controls implemented were weaker than the organisations where the SCADA operations group maintained their own internal security and IT specialists.
While two separate security and IT groups may not be ideal for all organisations due to cost and other factors, assurance is required to demonstrate that IT architects and managers without previous experience with SCADA systems understand the differing risk and security requirements prior to design and implementation. They need to be trained specifically in the realm of SCADA security and be familiar with the guidance documents discussed at the end of this article. Otherwise, weaker security controls than what is required may be implemented, putting both the organisation and the community dependent on their critical infrastructure services at increased risk.
Understanding the risk differences
The risk profile and consequences of a security breach within a SCADA environment are different than a corporate IT system such as a financial system or customer database.
The following summarises some generalised primary risk differences and demonstrates why traditional IT security controls may not work (or be as effective):
Integrity and availability are usually the key security dimensions to protect on a SCADA system. Data confidentiality is not as important on most real-time systems as a command usually becomes relatively meaningless after it has been executed. Failure to transmit timely accurate commands may lead to a complete shut-down to ensure safety requirements aren’t compromised. For critical infrastructure providers such as electricity utilities where companies, residents and institutions within their service area are dependent on their services, the impact on the community and the economy could be significant.
Unintended Consequences from Increased Connectivity and Sharing
In addition to targeted attacks or malware, SCADA availability loss can also be accidental due to human error or unintended consequences. For example, a common security management practice is Vulnerability Scanning. However, SCADA systems have minimal tolerance for latency in their communications, and something as simple and common as a port scan could lead to system outages. Lack of planning or a poor network design that does not properly segregate SCADA networks could result in a corporate network vulnerability scan negatively impacting an operational SCADA system.
Consolidation and shared processes or systems between the corporate and SCADA environments, while ideal from a financial and managerial point of view, may also increase security and availability risks to the SCADA environment. Controls may not be able to mitigate risk from either an intentional attack (external or from an “insider”) or the “accidental factor” to an acceptable level, due to the increased attack surface created against SCADA from having a shared environment. A people or process error that may have a minor impact or be tolerable in a corporate environment could be catastrophic in a SCADA environment where integrity of commands and uptime availability is paramount.
Due to unique risks when compared to corporate IT systems, several leading standards bodies and government agencies have published security guidance and further background information specific to SCADA:
- NIST Special Publication 800-82: Guide to Industrial Control Systems (ICS) Security
- Australian Government’s Trusted Information Sharing Network (TISN) for Critical Infrastructure Resilience - SCADA Good Practice Guides (available to TISN members)
- NERC (North American Electricity Reliability Corporation) Critical Infrastructure Protection (CIP) Manuals
- ANSI/ISA-99: Security for Industrial Automation and Control Systems.
These guides not only address technical architectural recommendations, but also people and process related controls. Anyone with a general IT background being exposed to SCADA for the first time should review these documents to gain an understanding of the different risks and controls they need to consider for this environment.
Wayne Chung is a Senior Security Consultant with experience in the utility and telecommunications industries.