Stuxnet Report: A System Attack
Thursday, February 24, 2011 @ 09:02 AM gHale
EDITOR’S NOTE: Stuxnet was elegant in its sophistication and then quietly moved and evolved over a period of time while buried deep within a system. Make no mistake about it, though, this was a vicious attack on an industrial control system with the intent to destroy. While there has been some resolution as to the masterminds behind the attack, understanding how the worm was able to infiltrate a secure control system remains a top priority. Security professionals Eric Byres, Andrew Ginter and Joel Langill teamed to publish a white paper entitled “How Stuxnet Spreads – A Study of Infection Paths in Best Practice Systems.” This is the first part in a series of stories detailing just how the Stuxnet worm was able to penetrate a system, and how automation professionals can keep an eye out for the next type of attack.
By Eric Byres, Andrew Ginter and Joel Langill
Stuxnet is a sophisticated piece of computer malware designed to sabotage industrial processes controlled by Siemens SIMATIC WinCC and PCS 7 control systems. The worm used known and previously unknown vulnerabilities to install, infect and propagate, and was powerful enough to evade state-of-the-art security technologies and procedures.
Since its discovery, there has been extensive analysis of Stuxnet’s internal workings. What has not been discussed is how the worm might have migrated from the outside world to supposedly isolated and secure industrial control systems (ICS). Understanding the routes that a directed worm takes as it targets an ICS is critical if automation professionals want to close off these vulnerable pathways to future worms.
To help address this gap, this series of stories will talk about the system under attack, describe a hypothetical industrial site that follows the high security architecture and best practices defined in vendor documents, how Stuxnet can slither its way through defenses to take control of the process and cause physical damage, and what did automation professionals learn from the analysis of pathways in order to prevent infection from future ICS worms.
Part I: Stuxnet attacked the Siemens SIMATIC PCS 7; Why that system?
Part II: How did Stuxnet infect a system?
Part III: A “high security site” targeted by Stuxnet or the Next Gen of Stuxnet-like worms.
Part IV: How Stuxnet infected a minor computer and then got deep inside a control system.
Part V: What should this mean for security of industrial control systems in the future?
Download the complete White Paper at Tofino Security.
Talk to Me: Stuxnet: Joint Operation Nets Victim
This analysis works off an accepted best practice security model. Unfortunately, this model does not often see use because system architectures in the real world are typically much less secure.
What we found researching Stuxnet and what you will learn over this series is:
- A modern ICS or Supervisory Control and Data Acquisition (SCADA) system is highly complex and interconnected, resulting in multiple potential pathways from the outside world to the process controllers.
- Assuming an air-gap between ICS and corporate networks is unrealistic, as information exchanges are essential for process and business operations to function effectively.
- All mechanisms for transfer of electronic information (in any form) to or from an ICS must undergo evaluation security risk. Focusing security efforts on a few obvious pathways (such as USB storage drives or the Enterprise/ICS firewall) is a flawed defense.
- Industry must accept the complete prevention of ICS infection is probably impossible and that instead of complete prevention, industry must create a security architecture that can respond to the full life cycle of a cyber breach.
- Industry must address the containment of attacks when prevention fails and aggressively segment control networks to limit the consequences of compromise. In particular, securing last-line-of-defense critical systems, such as safety integrated systems (SIS), is essential.
- Combining control and safety functionality in highly integrated ICS equipment exposes systems to common-cause security failures. For critical systems, diversity is important.
- Providing security by simply blocking or allowing entire classes of protocols between manufacturing areas is no longer sufficient. Stuxnet highlights the need for the deep packet inspection (DPI) of key SCADA and ICS protocols.
- The Remote Procedure Call (RPC) protocol is an ideal vector for SCADA and ICS attacks because it sees use for so many legitimate purposes in modern control systems.
- Industry should start to include security assessments and testing as part of the system development and periodic maintenance processes in all ICS.
- There is a need to improve the culture of industrial security among management and technical teams.
If the critical infrastructures of the world are to be safe and secure, then the owners and operators need to recognize that their control systems are now the target of sophisticated attacks. Improved defense-in-depth postures for industrial control systems are needed urgently. Thinking this was a once in a lifetime attack would be incorrect, so waiting for the next worm may be too late.
Since the discovery of the Stuxnet worm in July 2010, there has been extensive analysis by Symantec, ESET, Langner and others of the worm’s internal workings and the various vulnerabilities it exploits. Understanding the design of the worm helps antivirus product vendors make better malware detection software.
But the question of how the worm was able to migrate from the outside world to a supposedly isolated and secure industrial control system is what this analysis is all about. To the owners and operators of industrial control systems, this matters. Other worms will follow in Stuxnet’s footsteps and understanding the routes a directed worm takes as it targets an ICS is critical. Only by understanding the full array of threats and pathways into a SCADA or control network can critical processes be truly secure.
It is easy to imagine a trivial scenario and the corresponding solution:
Scenario: Joe finds a USB flash drive in the parking lot and brings it into the control room where he plugs it into the PLC programming station.
Solution: Ban all USB flash drives in the control room.
While this may be a possibility, it is far more likely that Stuxnet traveled a circuitous path to its final victim. Certainly, the designers of the worm expected it to – they designed at least seven different propagation techniques for Stuxnet to use. This is why we conducted a more realistic analysis of penetration and infection pathways.
This analysis addresses this gap by analyzing a range of potential “infection pathways” in a typical ICS. Some of these are obvious, but others less so. By shedding light on the multitude of infection pathways, we hope the designers and operators of industrial facilities can take the appropriate steps to make control systems much more secure from all threats.Understanding the Siemens PCS 7
In order to understand the attack Stuxnet performed against its victim, you have to understand Siemens ICS systems. Thus a brief overview of the Siemens SIMATIC PCS 7 architecture is in order. We will start few general terms:
- SIMATIC is a comprehensive term used by Siemens, which includes their portfolio of industrial automation solutions ranging from machine vision to distributed I/O systems and programmable controllers.
- SIMATIC WinCC is a process visualization system that comprises the core SCADA system. It works with Siemens-branded control equipment, such as the S7 line of programmable logic controllers (PLC) or it act independently with control products from other vendors.
- The SIMATIC STEP 7 software environment is specifically for the configuration and programming of the Siemens S7 line of controllers.
- SIMATIC PCS 7 is an integrated solution, composed of S7 PLC’s, WinCC visualization software, and the STEP 7 configuration software.
Now to understand the SIMATIC PCS 7 system; it is important to separate the functional components called “systems” from their platform components that commonly carry names like “stations” or “servers.” The basis of the SIMATIC PCS 7 control system breaks into three functional components:
• Operator System (OS)
• Automation System (AS)
• Engineering System (ES)
The Operator System (OS) permits the secure interaction of the operator with the process under control of PCS 7. The Operator System architecture is highly flexible, but always consists of a client and server function, which can work on the same or separate physical platforms.
The Automation System (AS) is the name given to the class of programmable logic controllers (PLC) used with PCS 7. This includes the Microbox solution based on a software controller running on a standard computer, and the S7-300 and S7-400 lines of hardware controllers.
The Engineering System (ES) consists of software responsible for configuring the various PCS 7 system components. The ES is further broken down into the engineering software required to configure either the Operator System (OS) or Automation System (AS).
With that behind us, we can focus on the software and platform components which are the main players in the SIMATIC PCS 7 system:
- OS Server: The OS Server is one of the two components utilized within the PCS 7 Operator System. The OS Server accesses system level information from the AS components (i.e. the controllers) and provide all process data to OS Clients. The OS Server also works for data collection and archival. However, you can only retrieve this data on OS Clients. OS Servers connect to the Process Control Network (sometimes called the “terminal bus”) and the Control System Network (or “plant bus”). The AS controllers also connect to the Control System Network.
- OS Client: The OS Client is the operator terminal that receives data from one or more OS Servers. The OS Server and OS Client may be installed on the same hardware platform in smaller systems, or distributed into a true client-server configuration on larger configurations. OS Clients connect to the Process Control Network.
- WinCC Server: The WinCC Server is the second major component in the Operator System. It acts as the core server for the Human Machine Interface client/server system, allowing multiple, coordinated HMI client stations to operate together with process data, archive data, messages, screens and reports. The WinCC Server, like the OS Servers, connects to the Process Control Network and the Control System Network.
- WinCC Client: The WinCC Client is part of the general-purpose WinCC SCADA visualization package used to provide monitoring and control of a particular manufacturing process. When installed with other PCS 7 and OS components, it provides an integrated automation solution incorporating reliable communications, diagnostics functions, and integrated engineering activities. In a typical system, the WinCC client is installed on the same hardware platform as the OS Client, and connects to the Process Control Network.
- Web Navigation Server: The Web Navigation Server provides the capability to monitor and control the process from external workstations interconnected via an Enterprise Control Network like a company Intranet (or even the Internet) using standard browser technology. The Web Navigation Server is installed on a WinCC Server that manages the connection to the PCS 7 system. The Web Navigation Server connects to the Perimeter Network.
- OS Web Server: The OS Web Server provides the ability to access PCS 7 information remotely functioning in a similar fashion to the Web Navigation Server. Unlike the clients using the Web Navigation Server for access to visualization displays of the underlying PCS 7 system, the OS Web Server provides standard Internet access to PCS 7 data functions like process values, archives, alarms and messages, historical trend data, etc. This may include connections from systems such as Manufacturing Execution Systems (MES) or Enterprise Resource Planning (ERP) systems that reside on the Enterprise Control Network. The OS Web Server connects to the Perimeter Network.
- CAS Server: The Central Archive Server (CAS) provides central data management and long-term data archival. This data is then accessible on local PCS 7 OS stations (OS Client, WinCC Client) on the Process Control Network and external workstations on the Enterprise Control Network using a standard Internet browser. The CAS Server connects to the Perimeter Network.
- Engineering Station: An Engineering Station can either connect to the Process Control Network, or it can reside remotely as a Support Station. This platform contains all PCS 7 client software components, including the OS Client, WinCC Client, and STEP 7 configuration tools.
This is a basic overview of how a Siemens PCS 7 system is defined.
Part II will explore Stuxnet itself and the tools it had it its arsenal to attack a PCS7 system.
Eric Byres, P. Eng., ISA Fellow, is the chief technology officer at Byres Security Inc. (email@example.com); Andrew Ginter, CISSP, is the chief technology officer at Abterra Technologies (firstname.lastname@example.org) and Joel Langill, CEH, CPT, CCNA, is the chief security officer at SCADAhacker.com (email@example.com) and Dept. of Critical Infrastructure Officer with The Cyber Security Forum Initiative (csfi.us).
2 Responses to “Stuxnet Report: A System Attack”
Leave a Reply
You must be logged in to post a comment.