The Evolving Threat Landscape
Design Goals for ICS Signatures
IPS Technology: Deep Packet Inspection
Engineering IPS Signatures
A Vulnerability-Specific Approach
ICS Signatures are Available in Both Standalone and Integrated IPS Appliances
Deploying Cisco IPS in ICS Networks
Industrial Control Systems (ICS) are comprised of devices used to monitor and control industrial processes. ICS examples include supervisory control and data acquisition (SCADA) systems, process control systems (PCS), and smaller control systems such as Programmable Logic Controllers (PLC) and Intelligent Electronic Devices (IED). ICS devices may contain vulnerabilities that attackers can exploit. One method of mitigating such attacks is to employ Intrusion Prevention Systems (IPS) capable of detecting and stopping these attacks. IPS has been established as a vulnerability mitigation technique for over a decade. ICS and traditional networks share similarities such as common network topologies, underlying transport protocols and application services. ICS networks also utilize domain-specific protocols such as MODBUS, DNP3, ICCP, MMS, Ethernet/IP and dozens of others. IPS can mitigate threats against ICS regardless of whether the underlying issue is in a traditional network component or is specific to ICS.
The following suggests that the ICS threat landscape has received increased focus and has matured significantly in recent years:
- The recent disclosure of vulnerability details and proof-of-concept exploits for vulnerabilities in ICS products via the Full Disclosure mailing list.
- Security tools like the Metasploit Framework now include exploits for ICS devices.
- The creation of the Industrial Control Systems Cyber Emergency Response Team (ICS-CERT), which is responsible for coordinating vulnerability disclosure with ICS vendors.
- The number vulnerabilities disclosed by ICS-CERT has increased tenfold in the past year.
Figure 1. ICS CERT Disclosed Number of Vulnerabilities
Source: ICS-CERT http://www.us-cert.gov/control_systems/ics-cert/archive.html Accessed 7 Nov 2011
This evolution in the ICS threat landscape suggests that researchers are performing sophisticated analysis to discover not only how to disable ICS devices but also how to analyze and control them. In the past, the impact that malware had on ICS was mostly due to collateral damage. Examples include the well-publicized Conficker, Slammer and Blaster outbreaks [see references 1, 2, and 3]. While those outbreaks impacted ICS systems, they were not targeted at ICS systems specifically. However, security researchers have now uncovered malware that clearly targets ICS devices. W32.Duqu, for example, installs applications such as key loggers on IT systems with access to sensitive intelligence about industrial systems (see reference 4). Other malware, such as Stuxnet, actively takes command of the control system itself (see reference 5).
Design Goals for ICS Signatures
Cisco IPS Industrial Signatures provide a rapid-response capability to mitigate attacks while maintaining the availability and integrity of the critical asset. While all the rules for commodity computing still apply, ICS face additional requirements and constraints that require specific support. Some of these additional requirements and constraints include:
- Maintenance windows for ICS are far part.
- ICS are both highly distributed and have real-time system requirements. Thus, the tolerance for downtime is low.
- Availability and integrity are of the utmost importance. They trump confidentiality.
- Extremely long field deployment time for equipment (often 10-20 years).
- ICS were originally designed to operate on a “trusted” network that is not connected to other networks. These networks are known as “air-gapped” networks. Since ICS networks were traditionally air-gapped, they have been designed without authentication and authorization controls.
Cisco Industrial Signatures protect ICS while addressing the requirements and constraints above. Specifically, Cisco Industrial Signatures do the following:
- Address publicly known vulnerabilities. Cisco Security Intelligence Operations monitors a wide range of sources, including ICS-CERT, the security research community and exploit sources, such as Metasploit and exploitdb.com.
- Provide policy enforcement and visibility for industrial protocols. For example, Cisco Industrial Signatures can record or prevent “write” commands. This is especially useful for protocols without authentication mechanisms.
- Provide protocol normalizations. This addresses common classes of vulnerabilities that exist in poorly specified functionalities.
- Address products produced by leading ICS infrastructure vendors.
- Address multiple protocols that are pervasive in ICS networks. For example, the signature set includes signatures for the MODBOS and CIP protocols.
- Address multiple elements of ICS infrastructure. For example, the signature set detects vulnerabilities in PLCs and HMIs.
- Address vulnerabilities that are publicly known and for which exploits may be publicly available.
The following table lists a sample of Cisco IPS signatures written to protect ICS systems.
|Signature ID||Signature Name||CVE||Description|
|DCS HMI Denial of Service||
|A specially crafted message sent to the DCS HMI component will trigger a denial of service condition.|
|MODBUS Unauthorized Write Attempt||
|The MODBUS/TCP protocol does not include an authentication mechanism, and as a consequence, MODBUS/TCP slaves will accept commands from any MODBUS master. The signature allows the IPS to implement a read-only policy for MODBUS slave devices.|
|PLC HMI Buffer Overflow||
|An overly long string sent to the PLC HMI listening service triggers a remotely exploitable buffer overflow condition.|
|DATAC RealFlex RealWin v2.1 On_FC_CONNECT_FCS_LOGIN Message Buffer Overflow||
|An On_FC_CONNECT_FCS_LOGIN message containing an invalid user name parameter will trigger a buffer overflow condition.|
IPS uses deep packet inspection to detect sophisticated attacks. By examining the traffic traversing a network, IPS devices can determine if an attack is underway. IPS devices interpret network traffic in much the same way as the end points that receive the traffic in question. The following explains the major components of the IPS data path in an attempt to illustrate how IPS does deep packet inspection.
When IPS receives packets for inspection, a component known as Normalizer does analysis on the IP and TCP layers of the packet. Normalizer looks for TCP and IP evasions and reassembles IP fragments and TCP segments so that the payload transported at the application layer can be inspected. Attackers have leveraged ambiguities in IP and TCP in an attempt to evade security devices for some time now, and this will likely also be true in the ICS space.
Once a packet is processed by IPS Normalizer it is passed to the various signature engines for further inspection. Signature Engines are optimized to inspect specific protocols in an efficient manner. For example, the Atomic IP Advanced signature engine can inspect the IP headers for both IPv4 and IPv6 packets, as well as the packet payload. The String TCP signature engine is optimized to inspect TCP payload. Since Normalizer reassembles TCP segments, signatures in the String TCP engine can look across packets to determine if a particular vulnerability is being exploited. Signatures are written in the engine that is best suited for the particular vulnerability in question.
Once the IPS determines an attack is in progress it will stop the attack and issue an alert. This alert contains information that can be used for further investigation. The following table outlines the major components in an IPS alert.
|Originator||Identifies the IPS that generated the alert.|
|Time||Identifies when the alert was generated.|
|Signature||Identifies which signature generated the alert.|
|Interface Group||Identifies which virtual sensor inspected the traffic which generated the alert|
|VLAN||Identifies relevant VLAN.|
|Participants||Identifies L3 and L4 info and OS information.|
|Actions||Identifies which event actions were[not] carried out.|
|Summary||Identifies information relevant to summary alerts.|
|Context||Identifies relevant packet payload data.|
|Trigger Packet||Identifies relevant packet payload data.|
The first step to engineering a signature for a given vulnerability is to understand the vulnerability and to understand how an attacker will engineer an exploit for the vulnerability. This is accomplished in two ways: First, by utilizing the tools and techniques leveraged by attackers themselves, and second, with support of the product vendor, to validate the vulnerability and ensure mitigations do not impair required functionality.
With this knowledge, signature engineers can determine which signature engine can best detect attempts to exploit the vulnerability against all attempts, not simply against a particular exploit sample or proof-of-concept code.. After a signature is developed it is tested to ensure fidelity and to ensure that it uses IPS system resources efficiently.
Cisco IPS signatures are engineered such that they detect attempts to exploit a given vulnerability. The alternative approach is to detect the presence of a specific exploit traversing the network. The issue with the latter approach is that an attacker can evade detection by modifying this exploit. However, when signatures are engineered such that the signature logic detects underlying heuristics associated with exploiting the vulnerability, the signature will detect many different exploits that exploit that vulnerability.
To illustrate the signature engineering process, we’ll do a deep dive into the “DATAC RealFlex RealWin On_FC_CONNECT_FCS_LOGIN Message Buffer Overflow” signature (37266-0). The vulnerability associated with this signature is tracked via CVE-2011-1563 and exploits are publicly available. Using this publicly available information we were able to determine that an attacker can exploit this vulnerability by sending a crafted packet with a username longer than 1024 bytes. To inspect the protocol in question we use the Service Generic (SG) engine. SG allows signature developers to use intermediate instructions to process arbitrary protocols to see if the protocol meets a given criteria. The following depicts the intermediate instructions for this signature:
Figure 2. Instructions for Signature 37266-0
Customers can leverage ICS signatures via the entire IPS product line. This includes standalone IPS appliances and IPS modules that are integrated in Adaptive Security Appliances (ASA) and Integrated Service Routers (ISRs).
Cisco IPS can be deployed in accordance to an organization's existing network architecture in a variety of fashions. Many government and industry governing bodies have produced standard-based best practice recommendations for security network design and operation (see reference 6). While terminology and application may vary between organizations and assets within an organization, the basic design principles and use cases generally remain constant.
The Purdue Model (T. J. Williams Purdue Model for Control Hierarchy ISBN 1-55617-265-6, 1992.) is utilized by the ANSI/ISA SP99 standard as a reference network architecture of a control system, including an adaptation for geographically distributed SCADA systems. IPS signature rules are designed to be deployed at several demarcation points depending on an organization's network design philosophy. Organizations can choose to deploy IPS in the following locations:.
- VPN endpoints to the operations DMZ
- Between layers 3 and 4 of the Purdue Model
- Between layers 2 and 3 of the Purdue Model
- Energy Zone of the ISA-SP99 Factory Model
- Cell/Area Zone of the ISA-SP99 Factory Model
Other examples can be found in the NERC CIP reliability standards, which include specific references to compensating controls and defense-in-depth, including firewall, anti-virus and IPS technologies.
Shiva Persaud, Software Engineer
Conficker Data Highlights Infected Networks
Slammer Worm Crashed Ohio Nuke Plant Net
Blaster Worm Linked to Severity of Blackout
Duqu Trojan a Precursor to Next Stuxnet, Symantec Warns
Stuxnet - Wikipedia
Recommended Practice: Improving Industrial Control Systems Cybersecurity with Defense-In-Depth Strategies
This document is part of Cisco Security Research & Operations.
This document is provided on an "as is" basis and does not imply any kind of guarantee or warranty, including the warranties of merchantability or fitness for a particular use. Your use of the information on the document or materials linked from the document is at your own risk. Cisco reserves the right to change or update this document at any time.