Establishing an Electronic Security Perimeter (ESP) around a defined enclave provides direct protection against unauthorized access to the enclosed systems and also prevents the enclosed systems from accessing external systems from the inside out. To establish an ESP and effectively secure inbound and outbound traffic, two things must occur:
For each enclave, appropriate security devices should be selected and implemented using the recommendations below.
Selecting Perimeter Security Devices
At a minimum, a firewall is typically required. Additional security—provided by IDS, IPS, and a variety of specialized and hybrid devices such as Unified Threat Management (UTM) devices, Network Whitelisting devices, Application Monitors, Industrial Protocol Filters, etc.—may be desired as well. Typically, the criticality of the enclave (see “Criticality”) dictates the degree of security that is required.
Table 7.1 maps the criticality of an enclave to required security measures of NERC CIP and NRC CFR 73.54, as well as recommended enhancements to improve security beyond regulatory requirements.
Table 7.1 Perimeter Security Requirements by Criticality
Criticality | Required Security | Recommended Enhancements |
---|
4 (highest) | NRC CFR 73.54: Unidirectional Perimeter, NERC CIP 005: Firewall or IDS or IPS | Application layer monitoring, Firewall, IDS and IPS |
3 | NRC CFR 73.54: Unidirectional Perimeter, NERC CIP 005: Firewall or IDS or IPS | Application layer monitoring, Firewall, IDS and IPS |
2 | NERC CIP 005: Firewall or IDS or IPS | Firewall and IDS and IPS |
1 | NERC CIP 005: Firewall or IDS or IPS | Firewall and IPS |
0 (lowest) | NERC CIP 005: Firewall or IDS or IPS | Firewall and IPS |
Table 7.1 recommends that both a firewall and an IPS be used at each security perimeter. This is because firewalls and IPS devices serve different functions: firewalls enforcing what types of traffic are allowed to pass through the perimeter; and Intrusion Prevention Systems closely examining the traffic that is allowed through in order to detect “legitimate” traffic with malicious intent—that is, exploit code, malware, etc—that is transferred over allowed paths. Using both devices together provides two mutual benefits: first, it allows the IPS to perform
deep packet inspection (
DPI) on all traffic allowed in through the firewall; second, the firewall limits the allowed traffic based on the defined parameters of the security enclave, freeing the IPS to focus its resources on just that traffic and therefore enabling it to enforce a more comprehensive and robust set of IPS rules.
For even greater protection, DPI can be used to analyze specific industrial protocol functions. This may require the use of specialized SCADA IDS or SCADA firewall devices that are designed to identify these protocol functions, or even the use of an ICS protocol filter or application monitoring tool that provides DPI across all packets within a session—providing detection and analysis capability to protocol and application contents that span multiple packets. This provides an even deeper look into the contents of network traffic.
Figure 7.14 illustrates the increased security capability of firewalls, IDS/IPS devices, and application session monitoring systems.
In the most critical areas, application layer session monitoring provides a valuable and necessary level of assurance, as they are able to detect both low-level protocol anomalies (such as a base64-encoded application stream inside of HTTP, used by many APTs and botnets) and application policy violations (such as an unauthorized attempt to write a new configuration to a PLC). However, unless monitoring very simple application protocols, where the desired contents are distinctly packaged within a single packet or frame, the application session must be reassembled prior to monitoring as illustrated in
Figure 7.15.
The most stringent perimeter security device may be the data diode, also referred to as a unidirectional gateway. A data diode is, very simply, a one-way network connection—often a physically restricted connection that uses only one fiber-optic strand from a transmit/receive pair. By only using TX optics, it is physically impossible for any digital communications to occur in a highly sensitive network area containing control system devices, while supervisory data may be allowed to communicate out of that highly secure enclave into the SCADA DMZ or beyond. In certain instances, such as for the storage of highly sensitive documents, the diode may be reversed, such that information can be sent into a secure enclave that is then physically prevented from communicating that information back outside of the enclave.
Intrusion Detection and Prevention (IDS/IPS) Configuration Guidelines
IDS and IPS devices inspect network packets for signs of malicious code or exploits. Intrusion Detection refers to passive inspection. An IDS examines packets and compares them against a set of detection signatures, and issues an alert when there is a match. Intrusion Prevention refers to active inspection, where traffic is matched against IDS rules, but where specific actions can be taken in addition to alerting. IDS actions can include
Alert (generate a custom message and log the packet),
Log (log the packet), and
Pass (ignore the packet), while IPS actions can also include
Drop (drop the packet and log it),
Reject (drop the packet and initiate a TCP reset to kill the session), and
sDrop (drop the packet, but do not log it). In addition, both IDS and IPS rules can use the
Activate and
Dynamic actions, the former of which activates another rule, and the latter of which remains idle until activated by an
Activate rule.
18Both IDS and IPS devices can be deployed either out-of-line using a network span or tap port or in-line using two network interfaces, although an IPS can only actively block traffic if it is deployed in-line.
An enabled collection of IDS/IPS detection signatures is referred to as an IDS/IPS policy, and this policy will dictate what types of threats may be detected by the device, as well as the degree and scope of events that will be generated. While active blocking of malicious traffic is important, the IDS/IPS events that are generated can also be analyzed to provide other important indicators—including network behavior, larger threat incidents, etc. (see
Chapter 9, “Monitoring Enclaves”). Signatures generally follow a format similar to a firewall rule, where there is an identified source and destination address and/or port, as well as an action. In addition, IDS/IPS signatures may match against specific contents of a packet, looking for patterns within the packet that indicate a known exploit (i.e., a “signature”). Common IDS/IPS signature syntax follows the de facto standards defined by Snort, an open-source IDS project owned by SourceFire. An example signature is written as follows:
[Action] [Protocol] [Source Address] [Source Port] [Direction Indicator] [Destination Address] [Destination Port] [Rule Options]
which when written in correct syntax looks like
drop tcp 10.2.2.1 80 -> 192.168.1.1 80 (flags: <optional snort flags>; msg: “<message text>”; content: <this is what the rule is looking for>; reference: <reference to external threat source>;)
To highlight the difference between a firewall rule and an IDS/IPS signature, consider the following example:
drop tcp 10.2.2.1 80 -> any any
Without any rule options, the previous rule is essentially the same as the firewall rule
Deny 10.2.2.1port 80, which would block all traffic originating from 10.2.2.1 on port 80, effectively preventing that user from accessing the web (via HTTP port
80). However, the ability to match packet contents within the rule options enables an IDS/IPS device to control traffic at a much more granular level, such as
drop tcp 10.2.2.1 80 -> any any (msg: “drop http POST”; content: “POST”;)
This rule functions differently, only dropping traffic from the source address in question if the HTTP traffic contains a POST request (used by many web forms or applications attempting to upload a file to a web server over HTTP).
NoteIDS/IPS rule examples are written using Snort syntax, as it is the de facto signature creation language. However, many IDS or IPS devices support proprietary rule syntax, GUI rule editors, or other rule creation methods. Depending on the product used, the example rules in this book may or may not function as intended. All rules should always be tested prior to deployment.
As with a firewall configurations, determining the exact IDS/IPS policy to be enforced is the first step in correctly configuring the device. Also as with firewalls, the enclave variables defined earlier under “Establishing Enclaves” are valuable tools that can be used to write succinct and highly relevant signatures. However, unlike a firewall which starts with a simple Deny All rule, an IDS/IPS should be deployed “large”—with many active signatures—and then pruned back to the specific requirements of the enclave. A method of properly configuring an IDS/IPS is as follows:
1. Begin with a more robust signature set, with many active rules.
2. If a protocol or service is not allowed in the enclave, replace any specific detection signatures associated with that protocol or service with a broader rule that will block all traffic from that protocol or service (i.e., drop unauthorized ports and services).
3. If a protocol or service is allowed in the enclave, keep all detection signatures associated with that protocol or service active.
3a. For all active signatures, assess the appropriate action, using
Table 7.3.
Table 7.3 Determining Appropriate IDS/IPS Actions
Allowed Port or Service? | Source | Destination | Criticality of Service | Severity of Event | Recommended Action | Note |
---|
No | Any | Any | Any | Any | Reject | Any communication not explicitly allowed within the enclave should be Rejected to disrupt unauthorized sessions and deter an attack. |
Yes | Inside Enclave | Inside Enclave | High | Any | Alert | Active blocking or rejection of traffic that originates and terminates within an enclave could impact operations. For example, a false positive could result in legitimate control system traffic being blocked or rejected. |
Yes | Inside Enclave | Inside Enclave | Low | Any | Alert or Pass | For noncritical services, logging is recommended but not necessary (Alert actions will provide valuable event and packet information that could assist in later incident investigations). |
Yes | Outside Enclave | Inside Enclave | High | Low (events from obfuscated detection signatures or informational events) | Alert | Many detection signatures are broad to detect a wider range of potential threat activity. These signatures should Alert only to prevent unintentional interruption of control system operations. |
Yes | Outside Enclave | Inside Enclave | High | High (explicit malware or exploit detected by a precisely tuned signature) | Block, Alert | If inbound traffic to a critical system or asset contains known malicious payload, the traffic should be blocked to prevent outside cyber incidents or sabotage. |
Yes | Inside Enclave | Outside Enclave (explicitly allowed destination address) | Any | Any | Alert | This traffic is most likely legitimate. However, alerting and logging the event will provide valuable event and packet information that could assist in later incident investigations. |
Yes | Inside Enclave | Outside Enclave (unknown destination address) | Any | Any | Block or Reset | This traffic is most likely illegitimate. Generated alerts should be addressed quickly: if the event is a false positive, necessary traffic could be unintentionally blocked; if the event is a threat, it could indicate that the enclave has been breached. |
4. Keep all IDS signatures current and up to date.
Remember that an IDS or IPS can be used in a purely passive mode, to analyze traffic that is allowed, including traffic within an enclave (that is, between two devices within the same enclave, that do not cross an enclave perimeter). Passive monitoring will generate alerts and logs that can be useful in many security operations, including forensic investigations, threat detection, and compliance reporting (see
Chapter 9, “Monitoring Enclaves,” and
Chapter 10, “Standards and Regulations”).
IDS/IPS rules should be tailored to the appropriate enclave using the variables defined in “Establishing Enclaves.” A typical Snort variable is established using the var command, as follows:
var VARIABLE_NAME <alphanumeric value>.
The
var command can be used ubiquitously, or specialized
ipvar and
portvar can be used exclusively for IP addresses and ports, respectively.
19 In the enclave method described earlier under “Establishing Enclaves,” variables would be defined as
ipvar ControlSystem_Enclave01_Devices [192.168.1.0/24, 10.2.2.0/29]
var ControlSystem_Enclave01_Users [jcarson, jrhewing, kdfrog, mlisa]
portvar ControlSystem_Enclave01_PortsServices [502, 20000]
These variables can then be used extensively throughout the active detection signatures. For example, a signature designed to detect a known SCADA buffer overflow attack that is available within the Metasploit framework might appear as follows. (The following rule has been deliberately obfuscated; the complete rule can be obtained from Digital Bond at
www.digitalbond.com.)
NoteMany Snort rules reference the $HOME_NET or $MY_NET variable. The use of multiple $ControlSystem_Enclave01_Devices variables (one for each defined enclave) accomplishes the same purpose, effectively defining a unique $HOME_NET for each enclave. The nomenclature of $ControlSystem_Enclave01_Devices is deliberately verbose in order to easily identify the variable’s contents, so that the examples within this book are easier to understand.
Additional examples include signatures designed to specifically block known infection vectors used by Stuxnet.
20 The first example looks for one of the early delivery mechanisms for the Stuxnet malware: specifically, a shortcut image file delivered via a WebDav connection. The second example detects Semens WinCC connection attempts, used in early Stuxnet infection phases.
tcp !$ControlSystem_Enclave01_Devices $HTTP_PORTS -> $ControlSystem_Enclave01_Devices any (msg: “Possible Stuxnet Delivery: Microsoft WebDav PIF File Move Detected”; flow:from_server; content: “MOVE”; offset:0; within:5; content: “.pif”; distance:0; classtype:attempted-user; reference:cve, 2010-2568; reference:osvdb,66387; reference:bugtraq,41732; reference:secunia,40647; reference:research,20100720-01; sid:710072205; rev:1;)
tcp any any -> any 1433 (msg: “Possible Stuxnet Infection: Siemens Possible Rootkit.TmpHider connection attempt”; flow:to_server; content: “Server=|2e 5c|WinCC|3b|uid=WinCCConnect|3b|pwd=2WSXcder”; classtype:suspicious-login; reference:cve,2010-2772; reference:osvdb,66441; reference:bugtraq,41753; sid:710072201; rev:2;) Recommended IDS/IPS Rules
Basic recommendations for IDS/IPS configuration include active block rules to
1. Prevent any undefined traffic from crossing enclave boundaries (where the disruption of the communication will not impact the reliability of a legitimate service).
2. Prevent any defined traffic containing malware or exploitation code from crossing enclave boundaries.
3. Detect and log suspicious or abnormal activity within an enclave (see “Securing Enclave Interiors” and
Chapter 9, “Monitoring Enclaves”).
4. Log normal or legitimate activity within an enclave, which may be useful for compliance reporting (see
Chapter 10, “Standards and Regulations”).
CautionA false positive (a rule that triggers in response to unintended traffic, typically due to imprecisions in the detection signature) can block legitimate traffic and in a control system legitimate traffic could represent a necessary operational control. Only use block IPS rules where absolutely necessary, and only after extensive testing.
The greater the extent of functional isolation and separation into defined enclaves, the more concise and effective the IDS/IPS policy will be. Some basic IDS and IPS rules suitable for use in enclave perimeters include the following:
• Block any industrial network protocol packets that are the wrong size or length.
• Block any network traffic that is detected inbound to or outbound from any enclave where that is not expected or allowed.
• Block any industrial network protocol packets that are detected in any enclave where that protocol is not expected or allowed.
• Alert any authentication attempts, in order to log both successful and failed logins.
• Alert any industrial network port scans.
• Alert any industrial network protocol function codes of interest, such as:
• “Write” functions, including codes that write files or that clear, erase, or reset diagnostic counters.
• “System” functions, including codes that stop or restart a device.
• “System” functions that disable alerting or alarming.
• “Read” functions that request sensitive information.
• “Alarm” or “Exception” codes and messages.
While SCADA IDS/IPS devices may be able to detect and trigger upon industrial network protocol function codes and commands, specialized application monitoring devices may be more capable of analyzing the contents of application layer protocols.
CautionIDS and IPS signatures are only able to block known threats, meaning that the IDS/IPS policy must be kept current in order to detect more recently identified attacks (virus, exploits, etc). Therefore, IDS/IPS products must be included within the overall Patch Management Strategy in order for the devices to remain effective (see
Chapter 6, “Vulnerability and Risk Assessment”).
Anomaly based Intrusion Detection
So far, only signature-based detection has been discussed. However, many IDS and IPS systems also support detection based on anomaly detection. Anomaly detection uses statistical models to detect when something unusual is happening, on the premise that unexpected behavior could be the result of an attack.
The exact capabilities will vary from product to product, as there is no standard anomaly detection mechanism. Theoretically, anything monitored by the IDS could be used for anomaly detection. Because network flows are highly quantifiable, anomaly detection is often used to identify abnormal behavior in what devices are communicating, and how. Referred to as Network Anomaly Detection, these systems are able to detect a sudden increase in outbound traffic, an increase in sessions, an increase in total bytes transmitted, an increase in the number of unique destination IP addresses, or other quantifiable metrics.
Anomaly detection is useful because it does not require an explicitly defined signature in order to detect a threat. This allows anomaly detection systems to identify zero day attacks or other threats for which no detection signature exists. At the same time, however, anomaly detection trends toward a higher number of false positives, as a benign change in behavior can lead to an alert. It is for this reason that anomaly-based threat detection is typically used passively, generating alerts rather than actively blocking suspect traffic.
In industrial networks—especially in well-isolated control system enclaves—network behavior tends to be highly predictable, making anomaly detection more reliable.
Anomaly detection systems may be referred to as “rule-less” detection systems. This is because they do not pattern match against a defined signature, although they do use rules. However, unlike a normal IDS rule, anomaly rules are often based on thresholds and/or statistical deviations, such as in the following example:
TotalByteCount from $Control_System_Enclave01_Devices increases by >20%
An example of a threshold rule would use a hard upper- or lower-limit, most likely derived automatically by the anomaly detection system:
As a general guideline, the greater the variation of the network traffic being monitored, the greater the chances of anomaly detection rules to generate a false positive.
Anomaly detection can be used across devices as well, using an information consolidation tool such as a Security Information and Event Management (SIEM) system. This system-level anomaly detection is discussed in more detail in
Chapter 8, “Exception, Anomaly, and Threat Detection.”
Application and Protocol Monitoring in Industrial Networks
Because many industrial operations are controlled using specialized industrial network protocols that issue commands, read and write data, etc. using defined function codes, specialized devices can leverage that understanding along with Firewall, IDS, and IPS technology to enforce communications based on the specific operations being performed across the network.
In addition to the inspection of industrial protocol contents (e.g., DNP3 function codes), the applications themselves—the software that controls how those protocols are used—can also be inspected. This degree of Application Monitoring, also referred to as Session Inspection, allows the contents of an application (e.g., HMI, Web Browser) to be inspected even though it might exist across a large number of individual packets. That is, inspection can occur up to and include the contents of a file being transferred to a PLC, a virus definition downloaded from a web browser of update server, etc. Application Monitors provide a very broad and very deep look into how network traffic is being used, and are therefore especially useful in environments where both control systems and enterprise protocols and applications are in use.
Many specialized security devices are available for SCADA and control system environments that use either application or protocol monitoring to this degree. At the time of this writing, these devices include the Tofino Industrial Security Appliance and the Secure Crossing Zen Firewall, as well as other broader-use enterprise Application Data Monitors. The two former devices were designed specifically to identify the operations being performed within industrial protocols, to prevent unauthorized operations. The latter refers to a more general-purpose enterprise security appliance, which is able to support the most common industrial network protocols. Each of these specialized devices has specific strengths and weaknesses, which are summarized in
Table 7.4.
Table 7.4 A Comparison of Industrial Security Devices
Security Product | Functionality | Strengths | Weaknesses | Rule Example |
---|
SCADA Firewall | Traffic policy enforcement | Enables separation of networks, ports and services | Does not block hidden threats or exploits within “allowed” traffic | Allow only TCP port 502 (Modbus TCP) |
SCADA IDS/IPS | Detects malware and exploits within traffic | Prevents exploitation of vulnerabilities via authorized ports and services | “Blacklist” methodology can only detect and block known threats | Block Modbus packets containing known malware code |
SCADA UTM or hybrid security appliance | Combines firewall, IDS/IPS, VPN, and other security functions | Combination of security functions facilitates “defense in depth” via a single product | Security functions maintain their component weaknesses (i.e., the whole is equal to but not greater than the sum of its parts) | Allow only TCP port 502 with “read only” function codes |
Allow outbound TCP 502 only via encrypted VPN to other SCADA enclaves |
SCADA Content Firewall or Application Firewall | Traffic policy enforcement | Enables content-based traffic separation, based on industrial network protocols | Assesses content of a single packet only (lacks session reassembly or document decode) | Allow only “Read only” Modbus TCP functions |
Deep Session Inspection (application content monitoring) | Session Reassembly | Functions of a SCADA content firewall, plus visibility into full application session and document contents to detect APT threats and insider data theft; provides strong security in hybrid enterprise/industrial areas such as SCADA DMZ | Typically limited to TCP/IP inspection, making session inspection less suitable for deployment in pure control system environments | Alert on Modbus TCP traffic on ports other than TCP 502 |
File/Content Decode | Alert on any traffic with base64-encoded content |
File/Content Capture |
Network Whitelist | Allows only defined “good” traffic | Prevents all malicious traffic by allowing only known, good traffic to pass | Requires proper baselining of correct network behavior | Can make legitimate changes in network operations more difficult |
Because these devices are highly specialized, configurations can vary widely. In general terms, a firewall capable of SCADA protocol inspection may utilize a rule as follows to block any protocol function from writing a configuration or register, or executing a system command (such as a device restart):
Deny [$ControlSystem_ProtocolFunctionCodes_Write, $ControlSystem_ProtocolFunctionCodes_System]
An IDS capable of SCADA protocol inspection may utilize a rule as follows, which looks for a specific function code within a DNP3 packet:
tcp any any -> $ControlSystem_Enclave01_Devices 502 (msg: “DNP function code 15, unsolicited alarms disabled”; content:“|15|”; offset:12; rev:1;)
In contrast, an application monitor performing full session decode may use syntax similar to the following rule to detect windows .LNK files within application traffic, which could indicate a possible Stuxnet delivery attempt.
ALERT_ACTION=log-with-metadata
DESCRIPTION=A Microsoft Windows .LNK file was detected
EXPRESSION=(objtype==application/vnd.ms-lnk)
Data Diodes and Unidirectional Gateways
Data diodes and unidirectional gateways work by physically preventing return communications over a fiber-optic connection, typically through the physical removal of the RX optics. This provides absolute physical layer security at the sake of bidirectional communications. Because the connection in one direction does not exist, data diodes are true air gaps, albeit in only one direction.
Because many network applications and protocols require bidirectional communication (such as TCP/IP, which requires a variety of handshakes and acknowledgments to establish and complete a session), considerations should be taken when using data diodes in order to ensure that the remaining one-way data path is capable of transferring the required traffic. To accommodate this concern, many data diode vendors implement a software-based solution, where the physical diode exists between two servers. These servers support a variety of bidirectional applications, so that the bidirectional requirements can be met fully at the transmitting end, and so that the receiving end can then spoof the behavior of the original transmitter—essentially tricking the application to operate over a one-way link. This allows an additional level of control over the applications and services that can be transmitted over the diode or gateway. An example of enabling DNP3 services over a unidirectional gateway is shown in
Figure 7.16. While data diodes are physical layer devices that do not require any specific configuration, the communication servers may need to be correctly configured before these applications work correctly over the diode.