February 2013, Vol. 240 No. 2
Features
Cyber Security And SCADA In Critical Infrastructure
Ensuring the stability and protection of critical infrastructure is essential to the nation’s public health and safety, security, economic strength and way of life. The Department of Homeland Security (DHS) recently revealed a rash of cyber attacks on natural gas pipeline companies.
Prior to that, the STUXNET computer virus wreaked havoc on Iran’s nuclear program for nearly two years and sparked worldwide controversy and concern about the threat of cyber attacks and cyber crime within critical infrastructures around the world.
In fact, to recognize the importance of protecting U.S. infrastructure resources, President Obama proclaimed December 2012 as Critical Infrastructure Protection and Resilience Month, furthering the call to action in the protection of assets, systems and networks, whether physical or virtual.
The Evolution Of Technology Without Security
Over the past 30 years, control system technology has evolved into a method of monitoring and controlling industrial processes. Supervisory Control and Data Acquisition (SCADA), Process Control Systems (PCS) and Distributed Control Systems (DCS) have evolved to monitor, control and manage critical infrastructures such as subway systems, natural gas pipelines, power generators and telecommunication systems to name a few.
Integrated control systems and embedded technology have conventionally been isolated and protected within the silos of gas and oil refineries, nuclear facilities and wastewater management and utility plants. However, the introduction of information technologies and connectivity through systems and protocols such as Windows, Ethernet, TCP/IP and wireless technologies within industrial control devices has resulted in significantly less isolation from the outside world.
Industrial Control Systems (ICS) are the computer systems that monitor and control critical industrial infrastructure or facility-based operations. Both subjective evidence and research indicate that SCADA protocols, specifically those running over the top of transport procedures such as TCP/IP, have weaknesses that could be manipulated by network hackers or terrorists, causing substantial interruption to critical facilities.
Until recently, little was known about these vulnerabilities and there have been limited security tools and methodologies available for manufacturers and owner/operators to detect these weaknesses prior to equipment distribution. As highly integrated control systems have progressed, there has been shockingly little data, good or bad, on network security for these industrial devices.
Understanding SCADA Vulnerabilities
Pioneering software engineer, E.W. Dijkstra, summarizes the situation well: “Program testing can show the presence of bugs but never their absence.”
No amount of testing guarantees correct device behavior in the field; only running all possible tests could do that, and there are far too many possible tests to exhaustively run them all. Worse, due to timing variations, a device may pass a test once and fail when the test is rerun at a later time.
This is particularly true for the SCADA systems used in critical infrastructure. The embedded devices used in these systems are not the usual Windows or UNIX-based platforms and the vulnerabilities are not available in IT-focused vulnerability lists. The reality is that until a disaster strikes, manufacturers and owner/operators have little knowledge of possible weaknesses in their critical systems.
This lack of industrial security data puts operators in a difficult position, as they are unable to make informed decisions regarding their security policies. Without data, it is impossible to answer questions, such as:
* What vulnerabilities are present in our systems?
* What is our security risk?
* What is the return-on-investment for security improvements?
Furthermore, if significant vulnerabilities do exist within a plant, operators need to know how they can be mitigated, preferably without significant interruption to normal plant operation.
A Definitive Need For Effective Robustness Testing
Through a process known as “robustness testing,” manufacturers are able to gain valuable insight into how control systems perform under stress and in situations or environments that go beyond requirement specifications or the normal operating envelope. The U.S. Department of Defense (DoD) and the National Aeronautics and Space Administration (NASA) reports indicate that more than half of the bugs found in deployed devices are directly related to a lack of robustness testing.
The Institute of Electrical and Electronics Engineers (IEEE) defines robustness as “the degree to which a system or component can function correctly in the presence of invalid inputs or stressful environmental conditions.” In other words, how does your system respond to something you did not predict?
According to a Defense Department assessment report, many DoD programs engage in what has been called “happy-path testing,” testing only meant to show that the system meets its functional requirements. While this sort of testing is certainly necessary, additional tests aimed at ensuring that the system handles errors and failures appropriately are often neglected. This “happy-path testing” underscores our belief that many control system failures in the field are due to a lack of robustness.
Although many manufacturers are doing a great job ensuring their products meet the customer’s security requirements, some owner/operators may not fully understand or be able to quantify, the level of robustness needed for a particular installation.
The fact remains that many communication protocols are highly complex and their implementations are usually written to a specification that contains small but significant areas of ambiguity. Incorrect assumptions or carelessness in implementation are common sources of protocol vulnerabilities that can disclose themselves as segmentation faults, stack, heap or buffer overflows, all of which may result in the protocol implementation to fail, resulting in a possible exploit.
As highly integrated control systems typically consist of many different devices and because these devices may contain implementations of a variety of protocols, a truly valuable vulnerability-testing tool must be easily applicable to a wide variety of protocols. The tool must also be accessible to users with varying skill sets. For example, the tool should be deployable by the vendor, by a field engineer or by a plant floor worker.
Testing is the most common approach for finding bugs; a failed test definitively proves that a device has a bug. Well-designed tests are able to exercise a device in near real-world conditions, demonstrating device capabilities and limitations, qualitatively and quantitatively. Additionally, testing provides legal and regulatory protection and as systematic testing of networked devices becomes common engineering practice, it will become increasingly risky to omit.
Protecting Organization Brand Equity And Reputation
Protecting critical infrastructure has taken a front seat with the media and is top of mind for government officials worldwide. Both owner/operators and manufacturers must look to protect organization brand equity, reputation and customer relationships by increasing protection against cybersecurity threats and mitigating risk.
Best practices suggest a comprehensive approach to cybersecurity that follows the lifecycle of these components:
1. Develop and implement best practice benchmarks that will help improve cyber security processes, practices, development, testing, commissioning, maintenance and support throughout system and component lifecycles.
2. Discover and analyze anomalies through device testing of products, root cause analysis and security services.
3. Mitigate and protect by utilizing the data gleaned from the discovery and analysis process to reduce or eliminate cyber attack risks inherent in networks of unpatched devices.
4. When identifying new products, insist on systems and components that have been built and certified to meet industry security standards such as the WIB – Werkgroup voor Instrument Beoordeling – International Instrument User’s Association Plant Security Standard and ISA99 – ISA Secure Standard. These certifications independently verify that manufacturers have met specific customer requirements for industry standard security benchmarks, and the creators of these industry standards have taken their work to IEC/ISO for inclusion in the IEC 62443 series.
Security Through Obscurity No Longer An Option
The singular aim of any SCADA protocol test is protecting critical infrastructure. In support of this goal, testing is not just critically important. Today it is imperative. This imperative extends from the plant floor to every point where a facility’s systems touch or are touched by the Internet.
In the critical infrastructure environment, we are no longer able to count on “security through obscurity” as more and more devices become Ethernet and wireless enabled devices. Automated testing of SCADA protocols is key to helping achieve that goal.
The Author
Nate Kube founded Wurldtech Security Technologies in 2006 and as the company’s Chief Technical Officer is responsible for strategic alliances, technology and thought leadership. He is an internationally recognized subject matter expert in embedded device protection and has created an extensive intellectual property portfolio including numerous patents in formal test methods and critical systems protection. He has also co-authored a multitude of security publications for the embedded device security market, and frequently presents on cyber security issues.
Comments