Chapter 6. Vulnerability and Risk Assessment
Information in this Chapter:
• Basic Hacking Techniques
• Accessing Industrial Networks
• Determining Vulnerabilities
• Vulnerability Management
In order to protect an industrial network from attack, it is important to understand how an attacker might approach an industrial network, gain access, and ultimately gain control. The basic hacking methodology and techniques of “identify, enumerate, and penetrate” are often discussed within the context of a typical Ethernet and Transmission Control Protocol/Internet Protocol (TCP/IP) enterprise network. However, in industrial networks, the methodology holds true but the techniques are subtly different. The entry points and attack vectors into an industrial system, the vulnerabilities of industrial systems, devices and protocols, and the exploits built against them must be understood before these systems can be effectively secured.
A discussion of vulnerabilities needs even greater consideration, as industrial networks are sensitive to traditional scanning techniques, and by their nature difficult to patch and reconfigure in order to minimize vulnerability. Therefore, it is important to understand where attacks may originate from, the paths or vectors that may be used, the targets, and their specific vulnerabilities.
Once an understanding of how a successful attack might occur is attained, the process of securing and isolating functional groups can be started. The information obtained from a strong vulnerability assessment and patch management strategy will facilitate the process of both defining and securing these functional groups (discussed in detail in Chapter 7, “Establishing Secure Enclaves”).
Basic Hacking Techniques
In order to defend a network against an attacker, it is important to be able to think like an attacker—and that means understanding the basics of hacking. The tools and techniques for hacking vary widely, although there are well-known and common methodologies that are often employed. By analyzing possible methods of gaining unauthorized entry into an industrial network, the perimeter can be strengthened accordingly. Note that these methods are all methods of attacking, and do not define the attack itself. That is, these steps define the process of how an attacker might gain entry into your network to deliver some sort of malicious payload such as a virus or malware; they do not define the payload itself. Protecting against the delivery of the payload comes first; protecting the users, services and hosts within your network from the payload (any malicious code, virus, bot, Trojan, etc.) comes after. The latter is discussed in Chapter 7, “Establishing Secure Enclaves”.
The Attack Process
While there are numerous ways to penetrate a network, most involve some (if not all) of the following defined steps. They are performing some sort of reconnaissance activity to learn more about the target network; scanning the network to determine what the network looks like and what services are available for exploitation; enumeration, which is the process of identifying operating systems and users, including the determination of authentication credentials of users on the network; and then an attack—typically either an abrupt disruption such as a Denial of Service (DOS), or an attempt to penetrate and infect the network. 1 Examining these steps as a process, it can be seen that successfully penetrating a network is more difficult than simply disrupting it from the outside (see Figure 6.1). For example, if the goal of an attack is to disrupt an outward-facing service such as HTTP, an attack can be as simple as a targeted DOS against an organization’s primary Internet access point. It is easy because the target is fully exposed, by design. Conversely, penetrating a network—either to disrupt an internal system that is not exposed, or to steal or alter information or other resources—requires that one or more layers of defense must be compromised. For the purposes of developing a best-practice defensive strategy, all industrial systems should be fully enclosed and protected within secure boundaries (see Chapter 7, “Establishing Secure Enclaves”); however, in reality many critical industrial networks are fully exposed (see the section “Targeting an Industrial Network”).
1.S. McClure, J. Scambray, G. Kurtz, Hacking Exposed: Network Security Secrets and Solutions, McGraw Hill, 1999.
Reconnaissance
The initial reconnaissance, or “foot printing” of a target, enables an attacker to understand the organization’s security posture. By properly researching a target, an attacker can conclude information about the company and its employees, the company’s Internet presence, internal and external networks and domains, and potential points of entry into those networks. 2
2.Ibid.
Many readily available Internet services and search engines can be used for foot printing. Many companies openly publish information about partners, member organizations, and even employee blogs—any of which might equate to a way in. Partners typically interact with a company via a partner portal that may provide access to a greater range of information and services. Blog-friendly companies might implement special web services to aggregate employee RSS feeds.
Any information that can be obtained is important because it could identify an entry point into the network, or it may be leveraged directly for social-engineering efforts, with results ranging from additional information gathering to targeted spear-phishing.
The tools available for network reconnaissance include: open-source aggregation services such as Maltego (www.paterva.com/web5/); social networking sites such as Facebook and LinkedIn; or more advanced tools such as the Social Engineer Toolkit (SET), a specialized tool set designed to “perform advanced attacks against the human element.”3
3.Computer Based Social Engineering Tools: Social Engineer Toolkit (SET). < http://www.social-engineer.org/framework/Computer_Based_Social_Engineering_Tools:_Social_Engineer_Toolkit_(SET)> 2010 (cited: December 23, 2010).
For reconnaissance of network domains, IP space, extranets, and other essentials of network foot printing, domain queries, and lookups provide useful information about the available network(s) as well as specific devices within the network. DNS information can also be used to locate additional related domains (using point of contact searches), or simply provide a relevant user identity (including address and phone number) that might be leveraged as part of a social-engineering attack. Once a device within a network has been identified, it can be scrutinized to obtain more detail—such as using a command line tool like traceroute to learn about the routers, firewalls, and other devices that might sit along the path to the target. 4
4.S. McClure, J. Scambray, G. Kurtz, Hacking Exposed: Network Security Secrets and Solutions, McGraw Hill, 1999.
Scanning
Scanning a network typically begins with broad attempts to identify network devices and hosts using a ping sweep, and then leveraging additional capabilities of the Internet Control Message Protocol (ICMP) to determine additional information, such as the network mask (which allows you to derive subnet information), as well as open TCP and User Datagram Protocol (UDP) ports (which allows you to identify operating services, as most services map to well-known ports). 5
5.Ibid.
Again, there are many tools that are available to facilitate network scanning, including tools like Fyodor’s popular Nmap scanner, a free network scanning tool that combines ping sweeps, port scans, operating system detection, and service detection (by looking up well-known ports) and service version detection (by connecting to identified servers and obtaining reported version information). Nmap (www.nmap.org) is widely used; it is available on all major operating systems, and many minor ones including Amiga, 6 and is thoroughly documented in 16 languages. 7 Metasploit (www.metasploit.com) is another popular penetration testing tool that includes network scanning modules.
6.nmap.org. Introduction. < http://nmap.org>, 2010 (cited: December 23, 2010).
7.nmap.org. Nmap Reference Guide. < http://nmap.org/docs.html>, 2010 (cited: December 23, 2010).
Enumeration
Enumeration refers to the process of identifying valid users and/or account credentials, as well as shared network resources that those user accounts might be able to access. The process involves establishing connections (or attempting to) and performing directed queries using tools like net view (for NT domains), or applications such as finger (for Unix user information) and rpcinfo (for identifying remote procedure calls that may be running). 8 The concept is that if an open entry point does not exist, a valid user account can be used to breach the network via a closed entry point. Once a username is known, passwords can be guessed (using knowledge gained during reconnaissance), brute-forced using password generators, or obtained from captured network traffic during the authentication process.
8.S. McClure, J. Scambray, G. Kurtz, Hacking Exposed: Network Security Secrets and Solutions, McGraw Hill, 1999.
Once again, common tools such as Metasploit include ready-to-use enumeration modules. As of version 3.5.0, Metasploit included modules for the enumeration of MySQL and MS-SQL services, Oracle database users, DNS services, SAP BusinessObjects, Apache web servers, Wordpress blogs, Server Message Block (SMB) users and shares, Simple Mail Transfer Protocol (SMTP) users, Session Initiation Protocol (SIP) users, and even SMTP and Telnet authentications. 9
9.Rapid7 LLC. The Metasploit framework. < http://www.metasploit.com/framework>, 2010 (cited: December 23, 2010).
Disruption, Infection and Persistence
The intentions of the attacker dictate what further actions might be taken. Does the attacker want to kill a service, or hide within the network to steal information over time?
If the goal is simply to disrupt a process or service, only understanding that service—for example, knowing an outward-facing IP address of a server—can be enough. There is no need to actually penetrate a web server to disrupt a company’s ability to serve web pages, for example, because a simple DOS attack can be sufficient to break that service. In this very simple example the path to disruption shown in Figure 6.1 can be taken prior to enumeration. It may be necessary to first penetrate the network to a degree prior to breaking a service, however. For example, to attack a system or service that operates only internally (such as a supervisory system), it may first be necessary to penetrate one or more layers of defense (see the section “Disruption and Penetration of Industrial Networks”).
Once a system has been accessed, it can be infected, referring to the successful installation and execution of some type of malware code on a device. The nature of the malware could be simple or complex, ranging from botnets to more advanced rootkits and/or memory-resident malware. Once a system is infected, the attacker can do almost anything, for example, opening backdoors, escalating privileges, spreading the infection to other devices, and establishing command and control functionality, etc.
Persistence means that the attacker’s goal is to penetrate the network and lie hidden, listening, and waiting. Malware introduced as part of a persistent threat will attempt to remain hidden. As stated in Chapter 3, “Introduction to Industrial Network Security,” this is one of the foundations of the Advanced Persistent Threat (APT). Persistence requires the following additional steps that must be taken: 10
10.B. Sterling, The advanced persistent threat attack. < http://www.wired.com/beyond_the_beyond/2010/01/the-advanced-persistent-threat-attack/> January 30, 2010 (cited: December 23, 2010).
• Establish outbound connections or backdoors for command and control
• Continue to farm user credentials to access additional systems
• Escalate privileges and obtain data for exfiltration
• Maintain persistence by deleting logs and other evidence of the infection, rewriting legitimate services to hide command and control and other functionality, and evading detection through mutation
The last step sets requires that all steps in the attack process remain hidden. This could mean operating entirely in memory, or it could mean rewriting an existing service so that the outbound command and control can operate secretly within a legitimate service—something that is expected and will not raise a red flag if seen by a network security analyst (Chapter 9, “Monitoring Enclaves,” discusses how to use security monitoring tools to help detect these covert communications). Persistent threats might also include several layers of infection, with dormant “backup” malware waiting to take over if the running exfiltration services are detected and removed. 11 In this way, the threat remains active in a new unknown form even after the original threat has been discovered and cleaned—perhaps even more so due to unwarranted complacency that can be felt after “eliminating” the original threat.
11.Ibid.
Targeting an Industrial Network
While the basic hacking methods discussed above apply to industrial networks, there are additional considerations—at all stages of an attack—when targeting a control system, as illustrated in Figure 6.2. Industrial control systems, because they utilize specialized systems and protocols, present new opportunities to an attacker. However, enterprise network hacking methods remain available as well, presenting a greater overall attack surface, which can be an advantage to an attacker.
Industrial networks can be difficult to attack if properly isolated, however. The establishment of secure zone or enclaves and a clear delineation between business, supervisory, and operation systems provides additional layers that an attacker must penetrate before reaching the most critical—and the most vulnerable system. Once the attacker has penetrated surrounding enclaves, they must discover the continued path into the control system.
Finally, in addition to normal user accounts and authentications, there are device Master/Slave relationships that can be discovered and manipulated to gain “authenticated” access to control system assets. In other words, there are Reconnais-sance, Scanning, and Enumeration techniques specific to Supervisory Control and Data Acquisition (SCADA) and distributed control systems (DCS) environments.
Industrial Reconnaissance
Industrial networks, protocols, assets, and systems are specialized. They are not commonly available, however, so an attacker intent on infiltrating an industrial system may focus reconnaissance efforts on information about the specific systems in use. As with enterprise hacking, reconnaissance can focus on public information about a company in order to learn the types of control system assets being used, the shift change schedule, and what other companies partner, service, or trade with the target company. Because many asset vendors use different and sometimes proprietary industrial protocols, knowing the specific assets used within the control system can indicate to an attacker what to look for in terms of systems, devices, and protocols.
Unfortunately, information can be obtained as easily as for any other network. Websites like the Sentient Hyper-Optimized Data Access Network (SHODAN) allow Internet-connected devices to be searched by port and protocol, country, and other filters. Any server, network switch or router, or other networked device using HTTP, FTP, SSH or Telnet is indexed by SHODAN (shodanhq.com). As a result, the site can easily identify devices utilizing SCADA protocols over any of these services (as seen in Figure 6.3). 12 This is an important step, as control systems are not easily procured, and therefore not easily reverse-engineered to find vulnerabilities. However, by understanding the control system devices in use the attacker is able to look for existing well-known vulnerabilities, or acquire device-specific research about the device through backchannels in order to determine vulnerabilities or backdoors. For example, in the case of Stuxnet, a hard-coded authentication process was used to gain access to the target Programmable Logic Controllers (PLCs). There has been much speculation in general about how a malware author might know this “insider information.” It could have been someone with insider knowledge, access to a production DCS, or—depending upon the sophistication of the attacker—this level of industrial-grade information could have been obtained via the deployment of APTs that are intent on discovering control system schematics, source code, and other information. Black market information sources might already posses the information from existing APTs.
Scanning Industrial Networks
As mentioned in the section “Scanning,” a network scan can identify hosts as well as the ports and services those hosts are using. In industrial networks, network scanning works in much the same way. The results of the scan can quickly identify SCADA and DCS communications, allowing the attacker to focus on these items. For example, a device found using port 502 is known to be using Modbus and is therefore very likely an HMI system or some supervisory workstation that is communicating with the HMI (see Table 6.1).
However, there is a caveat when scanning industrial networks: because many industrial network protocols are extremely sensitive to latency and/or latency variation (jitter), a “hard scan” could actually cause the industrial network to fail. The lesson here is that, if the intention is disruption of services, all it takes is a simple network scan to achieve your goal. It is easy enough to scan through a firewall, 13 meaning that if real-time protocols are only protected by a firewall, they are highly prone to DOS attacks using very basic hacking techniques. If the goal of the attacker is more complex, network scans need to be performed more sensitively. This means using a “soft scan” versus large sweeps—for example, inspecting router tables or even sniffing traffic passively (see the section “Determining Vulnerabilities”). Successful scan results can quickly map known SCADA and DCS systems by filtering on the ports and services listed in Table 6.1.
13.S. McClure, J. Scambray, G. Kurtz, Hacking Exposed: Network Security Secrets and Solutions, McGraw Hill, 1999.
Caution
Table 6.1 is only a partial list of some of the more common industrial ports and services. Many industrial devices utilize proprietary or unregistered port numbers. Always consult asset documentation to determine if special ports are used, and for what service, so that a comprehensive list of SCADA and DCS ports can be built.
Once a target system is identified, the scanning can continue—this time using the inherent functions of the industrial network protocols rather than commercial scanning tools. The following examples will obtain device information from industrial networks:
• Sniffing Ethernet/IP traffic to obtain Critical Infrastructure Protection (CIP) device identifiers and attributes
• Sweeping DNP3 requests that solicit a response (e.g., REQUEST_LINK_STATUS) to discover DNP3 slave addresses14
14.M. Franz, DNP3 Recon, Digital bond. < http://www.digitalbond.com/index.php/2006/10/18/dnp3-recon/>, October 18, 2006 (cited December 23, 2010).
• Capture an EtherCAT frame or a SERCOS III Master Data Telegram to obtain all slave devices and time synchronization information
Each industrial protocol utilizes its own function codes, and some proprietary function codes may be used on specific devices (necessitating some reconnaissance). For example, on SERCOS (Serial Real-time Communications System) networks, all slave devices can be easily identified via a short packet capture, as all communications to all nodes are packaged into a common message. Obtaining a SERCOS Master Data Telegram may also allow an attacker to identify designated time slots for communications to a specific device, as well as what cycles are available for open TCP/IP use.
Again, Stuxnet has exemplified the disruptive potential of this type of scanning. Once Stuxnet establishes itself in the logic of a target PLC, it listens to Profibus communications using these same techniques in order to detect specific frequency settings of specific frequency controllers. Stuxnet then manipulates the PLC outputs in order to sabotage the process. 15
15.N. Falliere, L.O. Murchu, E. Chien, Symantec, W32.Stuxnet Dossier, version 1.3, October 2010.
Note
Scanning an industrial network can effectively act as a DOS attack. Because many industrial protocols are real time, and the processes tightly synchronized, the introduction of additional packets into a real-time network can be disruptive. This means that an attacker who does not want to immediately disrupt an industrial network may scan quietly: performing low-and-slow scans, or using the “scan and spread” methodology of Stuxnet, where the malware crawls invasively but quietly through the network examining its surroundings at it goes in order to find target systems, rather than performing fast and loud sweeps.
Enumerating Industrial Networks
Because many industrial systems are Windows based, Windows user accounts can be enumerated in standard ways and be fully applicable to industrial operations. This is especially true of OPC Classic systems that rely on Windows OLE and DCOM, where obtaining authentication to the host allows essentially full control over the OPC environment. However, despite the lack of authentication in the underlying network protocols, enumeration can extend to specific identities and roles within a control system. Useful authentication information might include the following:
• HMI users
• ICCP server credentials (the bilateral table)
• Master node addresses (for any Master/Slave industrial protocol)
• Historian database authentication
Accessing an HMI would allow direct control of that HMI’s managed processes, and/or theft of information about that process. Obtaining ICCP server credentials would allow an ICCP server to be spoofed, enabling either steal or manipulate information being transmitted between control centers. If a Master node address is obtained, the attacker could spoof that Master node, obtaining control over a control loop without requiring access to the HMI (the attacker could inject function codes directly on the bus at this point).
In many cases, user roles and privileges are stored centrally, in an LDAP or an Active Directory server, providing attackers with a clear target for enumeration attempts. This is why it is important to functionally isolate both physical devices and logical services into established enclaves. This is also why NIST 800-82 (Guide to Industrial Control Systems [ICS] Security) recommends using a combination of account verification methods, including “something known (e.g., PIN number or password), something possessed (e.g., key, dongle, smart card), something you are such as a biological characteristic (e.g., fingerprint, retinal signature), a location (e.g., Global Positioning System [GPS] location access), the time when a request is made, or a combination of these attributes.”16 By abstracting authentication across multiple physical and digital attributes, enumeration becomes very difficult and can be effectively limited. That is, it may be possible to obtain a username or even a password, but full authentication remains elusive.
16.K. Stouffer, J. Falco, K. Scarfone, National Institute of Standards and Technology, Special Publication 800-82 (Final Public Draft), Guide to Industrial Control Systems (ICS) Security, Section 6.3.1 Identification and Authentication, September, 2008.
Disruption and Penetration of Industrial Networks
As mentioned in the section “Scanning Industrial Networks,” simply scanning an industrial network can be enough to disrupt it: many of the industrial protocols are sensitive enough that the introduction of a significant amount of unexpected traffic will result in protocol failure, and an effective DOS condition. This is a significant concern: it is possible to perform a network scan through a firewall, 17 and even easier to packet-flood through an open port on a firewall. That is, by identifying what traffic is allowed through the firewall, the attacker can then use allowed traffic to scan through the firewall, using a soft scan for true reconnaissance or a hard scan for disruption of service. If the firewall is well configured, a scan may not be possible, but all firewalls will allow some traffic through. By spoofing legitimate communications, abnormal amounts of traffic can be injected into a control network, causing a DOS.
17.S. McClure, J. Scambray, G. Kurtz, Hacking Exposed: Network Security Secrets and Solutions, McGraw Hill, 1999.
Tip
The more strictly defined, a firewall’s rules are, the more difficult it will be to identify and spoof “allowed” traffic. When configuring a firewall, always begin with “deny all,” and then configure “allow” rules according to the following guidelines:
1. Only “allow” traffic that is absolutely necessary for the operation of the devices specific to the enclave that is being secured. If too many “allow” conditions are needed, consider breaking the enclave into additional functional groups.
2. Always explicitly define the source and destination IP address and port. That is, use “allow from [a specific IP address and port] to [a specific IP address and port]” rather than “allow all from [a specific IP address].”
3. Especially for critical control systems, supplement the firewall with an IDS/IPS, application monitor or similar device to detect hidden channels or exploits inside of allowed protocols. An IDS/IPS with rate-based anomaly detection, for example, could detect and prevent a potentially disruptive packet-flood condition.
If the goal is not disruption, but penetration (and possibly persistence), we can again look to Stuxnet as an example of the types of infiltration techniques that might be deployed. Stuxnet employs a variety of scanning and mutation mechanisms for industrial network penetration. By looking for specific conditions in the network environment before performing additional tasks, Stuxnet is able to distribute itself widely despite maintaining a very focused target. Stuxnet reacts to its environment as follows:
• In the “enterprise phase” it looks for a target HMI before mutating to penetrate the HMI.
• In the “industrial phase” it infects the HMI, looks for target PLCs, and then again mutates, injecting malware into the PLC.
• In the “operational phase” it uses the PLC to look for certain IEDs operating with specific parameters before injecting commands to sabotage the process.
This simplified description of how Stuxnet operates highlights the following important considerations:
• The initial attack vectors leverage common enterprise hacking techniques.
• A compromised SCADA or DCS asset can be used to detect and penetrate additional industrial systems.
• Even “nonroutable” systems (such as a fieldbus consisting of PLCs and IEDs) are susceptible to infection, and can be used to penetrate even further into the industrial process.
Threat Agents
Industrial networks are different in many ways from enterprise networks, and as such they attract a different type of attacker. Who would want to deliberately breach an industrial network? An attack on an industrial network is not difficult, although it does require specialized knowledge and therefore the attacker will require more resources. There also is not an obvious benefit to attacking most industrial networks, as there might be from a financial services network or a retailer. The bad news is that there are attackers, and they fall into several distinct classes. The Government Accountability Office (GAO) has identified several classes of attackers, or “threat agents” in DHS parlance. They include the following18:
18.K. Stouffer, J. Falco, K. Scarfone, National Institute of Standards and Technology. Special Publication 800-82 (Final Public Draft), Guide to Industrial Control Systems (ICS) Security, September 2008.
• General hackers looking for individual prestige (referred to as “attackers” by the GAO, although the term “attacker” is used more generally in this book to refer to any threat)
• Botnet operators and spammers, identified as having the same skill sets as general hackers, but with the intent of further distributing spambots and other botnets
• Criminal groups looking to obtain money, either as ransom against the threat of a disruptive attack, or through direct monetary theft
• Insiders, including disgruntled employees, technology or business partners, or recently terminated employees or partners
• Phishers, treating industrial networks as another population of users susceptible to identity theft
• Spyware and malware authors
• Foreign intelligence services, as part of information gathering and espionage efforts
• Terrorists, seeking to destroy or disrupt critical infrastructures
• Industrial spies, who—much like foreign intelligence services—perform espionage, but for the purpose of acquiring intellectual property from competitive companies and/or nations
At first, the list of identified threat agents does not stand apart from what might be expected from an enterprise network attacker. However, the last three (foreign intelligence agencies, terrorists, and industrial spies) quickly put the risk of industrial network attack in perspective. Mapping the GAO’s classifications to the likelihood and sophistication of an attack (as depicted in Chapter 2, “About Industrial Networks,”Figure 2.2), we can now also see the consequences of such an attack, as illustrated in Figure 6.4.
Accessing Industrial Networks
In an ideal situation, the most critical systems of an industrial network are well protected behind strong layered defenses, making a basic attack difficult if not impossible. In reality, there are many entry points or attack vectors into industrial systems. The most obvious is via the business network, but in many cases there are entry points directly into “secure” SCADA demilitarized zones, and even into the control systems’ networks themselves. As shown in Figure 6.5, direct entry is possible into almost any network zone, and from there an attacker might easily penetrate into other areas.
The whole concept of “perimeter defense” only works if an attacker actually needs to break through that defense. If a perimeter can be bypassed, it adds little value to the overall security of the network. An example of this is implementing a data diode to make inbound data communications impossible, and then allowing uncontrolled use of removable media within the secure enclave. Securing an industrial network therefore begins with understanding how an attack might gain entry and then putting the necessary defenses in place. To complicate matters, the clean delineation of industrial networks into three well-defined enclaves (Business, SCADA, and Control) is overly simplified. In real industrial networks, there are many—potentially dozens—of enclaves that need to be isolated and protected; if any one system is vulnerable, and there is lack of separation between that system and others, then an attack vector exists.
Further complication is introduced by smart grids. As discussed in Chapter 5, “How Industrial Networks Operate,” the smart grid presents an unprecedentedly large attack surface. The sheer scale of a smart grid deployment makes these networks easily accessible, both physically and digitally. In addition, a smart grid communicates with several systems that are (hopefully) logically separated into distinct enclaves. A breach of the smart grid, therefore, can potentially open many entry points into different areas on the industrial network.
The Business Network
Unlike SCADA networks and control systems, business networks rely on connectivity. Out of necessity, they allow more open communications, both inbound and outbound, in order to support the various normal functions of business: sales, marketing, accounting, administrative, and other business functions all rely upon networked systems, many of which utilize web applications or even cloud computing resources. Therefore, unlike industrial network enclaves, the business network must allow connectivity to the Internet. Also, unlike industrial control systems, the network-, user-, and application-behavior patterns in an enterprise vary widely.
Unfortunately, this makes the business network highly exposed to attack. If vulnerabilities exist, it is a simple matter to discover and exploit them remotely. Even more unfortunate is that the business systems also rely upon information from SCADA and DCS systems, and as such these services are sometimes made accessible from within the business network. When the business network is inevitably compromised, it becomes a primary attack vector into these supervisory and control systems. The business network, therefore, should be considered “contested ground,” and when assessing the security of industrial networks it should be treated as if it were already compromised.
The primary entry point to the business network, as shown in Figure 6.6, is from the Internet. According to the SANS Institute, the leading methods of entry continues to be unpatched client software and vulnerable Internet-facing web servers, reinforcing the trend toward application-based vulnerabilities (vs. previous trends of operating system and protocol stack vulnerabilities). 19 With the previously described attack methodologies in mind (see the section “Basic Hacking Techniques”), steps should be taken to mitigate these vulnerabilities by limiting the attacker’s ability to identify and enumerate important systems and services. This involves the following steps:
19.The SANS Institute, Top cyber security risks; executive summary. < http://www.sans.org/top-cyber-security-risks/summary.php>, 2010 (cited: December 23, 2010).
• Properly controlling and monitoring inbound and outbound traffic
• Disabling all unnecessary ports and services
• Enforcing strong authentication and access control policies
• Minimizing backdoor access through application vulnerability assessment and patching
• Controlling the use of removable media, remote access and other rogue I/O where control is possible (and establishing security awareness and policies where it is not)
Weaknesses in any of these areas will increase the attack surface of the network, as can also be seen in Figure 6.6. However, the highly dynamic and interconnected nature of modern business practices requires a more open approach to information sharing (see the section “Poorly Configured Firewalls”).
It should be noted that access to the business network from the SCADA DMZ is possible. Although no substantial evidence of past attacks has been observed along this path, 20 all security demarcations should enforce communications in both directions.
20.J. Pollet, Electricity for free? The dirty underbelly of SCADA and Smart Meters. Red Tiger Security. in: Proc. 2010 BlackHat Technical Conference, July, 2010.
The SCADA DMZ
Where the business network is “contested ground,” the SCADA network is the “middle ground,” the demilitarized zone between the business and process control systems. Here, the network is bridged between standard business applications and services and specialized process control applications and services, as well as between common Ethernet TCP/IP networks and either Ethernet or serial fieldbus networks. If we assume that the business network has been compromised (for the sake of establishing a strong security profile), the same vulnerabilities and entry points exist. As can be seen in Figure 6.7, different systems are in use, but they present many of the same inbound vectors for an attacker.
Again, weak firewall rules and access control provide a primary entry point from the business network into the SCADA DMZ. Legitimate reasons for allowing communications through the firewall exist, and these can introduce entry points into industrial network enclaves, via the business network. However, there are also inbound entry paths that lead directly into the supervisory enclave(s), bypassing the business network. These entry points include the following:
• Inter-control center communications over ICCP
• Remote access connections to field stations
• Connections to the Control System
• Diagnostic access to SCADA devices via dial-up or remote access
Each entry path requires security demarcation, using (at a minimum) a properly configured firewall. See Chapter 7, “Establishing Secure Enclaves,” for recommendations on how to provide strong perimeter defenses.
The Control System
If the business network is “contested ground” and the SCADA DMZ is “middle ground” than the Control System is “sacred ground.” Within the context of industrial network security, the control system represents the ultimate target: the devices and systems that actually control the industrial process which needs to be protected. Theoretically, the Control System has very limited access, but in practice there are multiple points of entry. These include not only the obvious path from the SCADA DMZ, but also direct entry paths from wireless and diagnostics systems, as shown in Figure 6.8.
Because the control system is likely the target of more sophisticated attacks from more dangerous threat agents, minimizing any direct entry path into these networks is critical. Again, direct vectors of attack can be minimized through the isolation of critical functional groups, secured by strong defense-in-depth practices (see Chapter 7, “Establishing Secure Enclaves”).
Common Vulnerabilities
In addition to identifying paths into an industrial network, understanding the vulnerabilities associated with industrial network systems will give the attacker—or the defender—an advantage. While many vulnerabilities are derived from software bugs in applications or network protocol stacks, other vulnerabilities are derived from weak security practices and policies, poor network design, and other easily addressable factors. Some of these vulnerabilities, including poor firewall configurations, weak authentication, unmanaged and/or insecure network access, and remote access vulnerabilities, can be addressed easily.
Poorly Configured Firewalls
Poorly configured firewalls represent the largest vulnerability to any network, because firewalls are still relied upon as the primary (and in some cases the only) method of cyber defense. Firewall misconfigurations derive from a number of factors, including a combination of legitimate business requirements and increasingly complex firewall policies that are required to accommodate them. In addition, poor network housekeeping can result in open policies allowing network traffic types that are no longer in use (but could still be leveraged by an attacker to gain entry into the network). They are also derived from a lack of understanding; for example, many firewalls include only inbound traffic policies and allow any outbound traffic free reign, ignoring the very real possibility that an attacker could be residing inside the network perimeter attempting to communicate outwards—such as a command and control agent of APT, looking to exfiltrate information about control system functions, configurations, and operations. 21
21.United States Computer Emergency Readiness Team (US-CERT), Overview of cyber vulnerabilities. < http://www.us-cert.gov/control_systems/csvuls.html#under>, 2010 (cited: December 23, 2010).
Table 6.2 highlights in general terms some common firewall misconfigurations, indicates how they introduce risk, and gives recommendations on how to remediate the issue(s). Note that more detailed recommendations for security configurations are provided in Chapter 7, “Establishing Secure Enclaves.”
| aInternet Engineering Lab (IEL) Group for Advanced Information Technology (GAIT), NISCC Good Practice Guide on Firewall Deployment for SCADA and Process Control Networks, version 1.4, National Infrastructure Security Coordination Center (NISCC), February 15, 2005. | |||
| Firewall Rule | Business Justification | Issues | Recommendations |
|---|---|---|---|
| “Permit All” policies for traffic from the business network to the Internet | Employees in the business network require access to outside world for a variety of business functions | Unless source and destination addresses and ports are explicitly defined, devices such as printers or rogue PCs are exposed to the Internet over port 80. There is also no control in place to prevent a rogue web server inside the business network from initiating or accepting HTTP connections | Specify source and destination IP address details on all firewall rules. Consider web content firewall to restrict access to websites that have inappropriate content and/or malware |
| Allow SCADA protocols to pass from the SCADA DMZ to the business network | Executive access to an HMI console or other SCADA system is desired for business planning, strategy, trading or other legitimate business purpose | Unless source and destination addresses and ports are explicitly defined, the SCADA protocols will be exposed to all nodes in the corporate LAN. If the business firewall does not inherently or explicitly deny SCADA traffic to the Internet, the HMI is directly accessible from the Internet | Inherently disallow SCADA protocols across all firewalls, and only explicitly allow them where needed, using allow rules that specify both source and destination address and port. SCADA and DCS protocols can be detected using network monitoring as well for added situational awareness |
| Allow business services from the business network to pass into the Control System | These types of policies are usually caused by oversight. In some cases they are the result of unintended bi-directionality caused by other rules designed to allow traffic from the SCADA Network into the business network | Any business service (such as web, e-mail, file sharing, etc.) available to SCADA or Control Systems provides an open entry path for an attacker | Always define firewall policies to enforce traffic in both directions, and inherently deny all traffic into critical network areas. Common business services can be detected using network monitoring as well for added situational awareness |
| Allow contiguous service use across multiple enclaves | To facilitate business operations across functional units, communications, fire sharing and other services may be allowed within Business, SCADA and Control System networks | If allowed contiguously, an exploited service will provide a clear path through any and all additional enclaves, potentially bypassing their perimeter defenses entirely | Configure enclave boundaries using “disjointed” policies—that is, do not allow the same service to operate within any two adjacent enclavesa |
Unnecessary Ports and Services
NERC CIP and other regulations dictate the disclosure of all open ports and services and all cyber assets, and recommend that any unused or unnecessary ports and services be closed or disabled. Looking at the intricacies of firewall configurations, the reason is clear. Every open port and service represents a network communication path that could be used maliciously, and as such the number of open ports and services correlates directly to the complexity of firewall, IDS/IPS, and other security device configurations. As complexity increases, so does the likelihood of a misconfiguration that will result in network vulnerability.
Application Backdoors
Many business applications and control system applications utilize a database, and databases remain highly vulnerable to attack unless properly configured and secured. Using SQL injection techniques, an attacker can gain control of the database, and from there he or she can migrate control to the database server or the application server, such as a company’s customer management and billing systems or a SCADA system’s Historian system. Most control systems not only log activity to a Historian, but the data is also replicated across the perimeter between the SCADA DMZ and business network. 22 These attacks are especially dangerous because the databases (and the applications which they backend) are explicitly reachable by authoritative systems and users. Many OPC systems store local connection databases which might enable an attacker to quickly migrate into several systems inside a SCADA DMZ or even the Control System itself.
22.United States Computer Emergency Readiness Team (US-CERT), Overview of cyber vulnerabilities. < http://www.us-cert.gov/control_systems/csvuls.html#under>, 2010 (cited: December 23, 2010).
Ideally, databases should only be accessible by the application which it back-ends, using strong user authentication. Hard-coded internal authentication, such as was exploited by Stuxnet, should be avoided. To avoid these vulnerabilities, limit connectivity between both users and applications, as well as applications and databases. If data from a SCADA database need to be replicated to a business network, use hard defenses such as unidirectional data diodes, which allow traffic to move only in one direction (out of the SCADA DMZ) and prevent a compromised database on the business network from letting an attacker migrate into the SCADA DMZ.
Asset Controls
Even a data diode can be compromised physically. A user can walk into a secure facility and plug in a USB drive or iPod, well inside the secure perimeter established by firewalls, IDS/IPS devices, or diodes. It is therefore important to control the assets themselves. All assets should require authentication, and all unnecessary services should be disabled. This includes device mounting services, file sharing services, and other commonly overlooked computer functions (Stuxnet initially spread via removable USB drives, although network-based vulnerabilities and even print-spooler vulnerabilities were utilized.
Wi-Fi Access
Wireless network represents significant risk due to multiple vulnerabilities associated with network architecture, access control configurations, and even component-level vulnerabilities. This is because wireless networks are accessible easily from the air: they possess antennae capable of receiving wireless transmissions. The tools required to detect a Wi-Fi network are readily available, and there is an extensive list of tools available to hack into wireless networks. These tools include discovery, mapping, traffic analysis (“sniffing”), client evaluators, wireless frame generators, and encryption cracking tools designed to break wireless authentication. 23
23.Wi-Foo.com, Recon and attack tools. < http://www.wi-foo.com/ViewPageefe4.html?siteNodeId=55&languageId=1&contentId=-1>, 2006 (cited: December 23, 2010).
Even disabled wireless systems can present a challenge. A researcher from the Idaho National Labs presented methods for hacking into devices at the component level, utilizing Wi-Fi antennae that were built into the microprocessor silicon but never enabled by the manufacturer. 24 Also, beyond the control of most security administrators are exploitations of the normal functions of Wi-Fi access points. Jamming a Wi-Fi signal using off-the-shelf components could cause an access point to enter a state of continuous reconnection attempts. The result, if sensitive Ethernet fieldbus protocols are in use, could be a processwide DOS. 25
24.J. Larson, Idaho National Laboratories, Control systems at risk: sophisticated penetration testers show how to get through the defenses. in: Proc. 2009 SANS European SCADA and Process Control Security Summit, October, 2009.
25.S4 Briefings book (Wi-Fi jamming presentation).
The best mitigating factor for wireless access is to avoid it where possible, and to thoroughly isolate and secure access points wherever they are located. That is, assume that Wi-Fi access will be successfully detected and that authentication will be cracked, and treat the access point as contested ground, separating it from other networks.
Remote Access, VPNs and Mobile Apps
Remote access, if not implemented properly, can represent significant risk. Especially when considering the potential threat agents in an industrial network attack scenario, the remote end of the connection simply cannot be trusted. A laptop with a VPN client can be stolen. Extranets can be easily breached. Mobile SCADA and control applications for smart phones and other mobile devices expound the problem even further.
To avoid inherent vulnerabilities with remote access, always treat the access point (whether a VPN client, application server, etc.) as if it were directly exposed to the Internet, and do not terminate remote access directly into critical networks. Also, when performing vulnerability analysis and penetration tests, make sure to include all remote interfaces into the network.
Diagnostic access/Dial-up Access/Field Access
Some remote access mechanisms do terminate into critical systems—sometimes directly into a critical cyber asset. Because industrial networks are built around reliability, and control systems are sometimes difficult to access physically (especially remote stations or plants), many vendors of industrial products include mechanisms to access field devices remotely. If a system has a remote dial-up modem interface for diagnostics or for backup communication, an attacker can potentially bypass every single defensive measure in place and call into the asset directly. A simple war-dialing attack (where an attacker rapidly dials every combination of possible telephone numbers using specialized software) will quickly locate modems, putting any asset with exposed dial-up interfaces at extreme risk.
Remember that many industrial assets do not require authentication, and for those that do, it is still common to find default passwords in use in many field devices. 26 Securing long-distance communication facilities can be difficult. Lines are typically terminated at a PBX or other telecommunications demarcation device, which is most often under the authority of the corporate IT department. Special care should be taken for remote access over these lines: ideally, all field access of this sort would operate over private lines that terminate in a controlled corporate environment, limiting access to devices located within a central, controlled environment.
26.United States Computer Emergency Readiness Team (US-CERT), Overview of cyber vulnerabilities. < http://www.us-cert.gov/control_systems/csvuls.html>, 2010 (cited: December 23, 2010).
The Smart Grid
Once again, the smart grid represents new inbound attack vectors into industrial systems. The nature of Smart Metering technology and its close marriage to power transmission and distribution essentially turn the entire T&D infrastructure into a potential entry point into the utility’s network. These entry points are numerous and are therefore not depicted in Figure 6.6, Figure 6.7 and Figure 6.8. However, they include access via the T&D communications infrastructure, via customer service and billing apps within the business network, via generation and usage applications within the SCADA network, and so on. Almost every physical system, network, and application is tied in some way to the smart grid, requiring strong security on these systems to prevent an attacker using them as an inbound vector (see the section “Smart Grid Operations” in Chapter 5, “How Industrial Networks Operate”).
Determining Vulnerabilities
Understanding what are the entry points through which an attacker might attempt to penetrate an industrial network is one thing; understanding how the attack might succeed is another. As discussed in the section “Basic Hacking Techniques,” an attacker will attempt to gather information and scan networks for entry points. Next comes enumeration, where an attacker will attempt to obtain user and authentication information; and then penetration. During both of these steps an attacker will look for vulnerabilities that can be exploited in order to obtain access and control. Many vulnerabilities are well known, and therefore vulnerability management and patch management are closely related (see the section “Vulnerability Management”). For example, dozens of common industrial network vulnerabilities are identified in NIST SP 800-82. While the list is extensive—ranging from procedural vulnerabilities cause by inadequate security policies (e.g., lack of training, awareness, documented security procedures, etc.), to platform configuration vulnerabilities (i.e., unpatched systems, default configuration use, missing weak or default password use, etc.), software vulnerabilities (inherent vulnerabilities such as buffer overflows, the use of vulnerable protocols or services such as DCOM, insufficient logging, etc.), the lack of sufficient malware protection, improperly configured networks (weak or missing network security controls, lack of encryption, lack of access control, lack of redundancy, etc.), inadequate network authentication, inadequate or missing perimeter protection, and lack of communication integrity checking27—most are directly addressable by implementing the security best practices described within this book. For others, diligent vulnerability scanning and management is required (see Table 6.3).
27.K. Stouffer, J. Falco, K. Scarfone, National Institute of Standards and Technology, Special Publication 800-82 (Final Public Draft), Guide to Industrial Control Systems (ICS) Security, September, 2008.
| aK. Stouffer, J. Falco, K. Scarfone, National Institute of Standards and Technology, Special Publication 800-82 (Final Public Draft), Guide to Industrial Control Systems (ICS) Security, September, 2008. | |||||||||||||||||
| Policy and Procedure Vulnerabilities | Suggested Actions | ||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Inadequate security architecture and design | Identify functional groups and separate into security enclaves with appropriate security measures (see Chapter 7, “Establishing Secure Enclaves”) | ||||||||||||||||
Few or no security audits on the ICS | Implement centralized log and event collection and reporting (see Chapter 9, “Monitoring Enclaves”) | ||||||||||||||||
Lack of ICS specific configuration change management | Monitor control processes for changes using Historians and/or importing Historian data into other security tools such as SIEM (see Chapter 9, “Monitoring Enclaves”) | ||||||||||||||||
| Platform Configuration Vulnerabilities | Suggested Actions | ||||||||||||||||
OS and vendor software patches may not be developed until significantly after security vulnerabilities are found OS and application security patches are not maintained OS and application security patches are implemented without exhaustive testing | Perform regular VA scans and follow Vulnerability Management best practices (see the sections “ Vulnerability Assessment in Industrial Networks” and “Vulnerability Management”) | ||||||||||||||||
| Default Configuration Vulnerabilities | Suggested Actions | ||||||||||||||||
Lack of adequate password policy No password used Password disclosure Password guessing | Monitor network for weak passwords using content inspection such as content aware IDS, content firewalls, ADM or transaction monitors (see Chapter 9, “Monitoring Enclaves”). Also, look for password weakness and/or password stagnation during the vulnerability assessment process (see the section “Vulnerability Scanning for Configuration Assurance”) | ||||||||||||||||
| Platform Software Vulnerabilities | Suggested Actions | ||||||||||||||||
Buffer overflow Installed security capabilities not enabled by default Mishandling of undefined, poorly defined, or “illegal” conditions | Perform regular VA scans and follow Vulnerability Management best practices (see the sections “ Vulnerability Assessment in Industrial Networks” and “Vulnerability Management”) | ||||||||||||||||
OLE for Process Control (OPC) relies on Remote Procedure Call (RPC) and Distributed Component Object Model (DCOM) Use of insecure industry-wide ICS protocols | Monitor the network for SCADA and DCS protocols outside of their defined enclaves (see Chapter 9, “Monitoring Enclaves”) | ||||||||||||||||
Unneeded services running | Vulnerability scans can identify open ports and services on a host, while network flow monitoring can identify services in use in the network (see section “ Vulnerability Assessment in Industrial Networks” and Chapter 9, “Monitoring Enclaves”) | ||||||||||||||||
Intrusion detection/prevention software not installed | Implement host- and/or network-based intrusion detection and prevention systems. At a minimum, Host IDS (HIDS) should be used on all critical assets, while Network IDS (NIDS) should be used at all enclave perimeters (see Chapter 7, “Establishing Secure Enclaves”) | ||||||||||||||||
Logs not maintained | All logs should be centrally collected and managed using a Log Management and/or SIEM system. For those devices that are incapable of producing logs, compensating measures should be implemented, such as passive network monitoring to produce logs in proxy, or the use of Historian or other information stores in lieu of activity logs (see the section “Vulnerability Assessment in Industrial Networks” and Chapter 9, “Monitoring Enclaves”) | ||||||||||||||||
Incidents are not detected | Implement a central event analysis and correlation system to detect and document potential incidents (see Chapter 9, “Monitoring Enclaves”) | ||||||||||||||||
| Platform Malware Protection Vulnerabilities | Suggested Actions | ||||||||||||||||
Malware protection software not installed | Implement Host and/or Network Anti-Malware (see Chapter 7, “Establishing Secure Enclaves”) | ||||||||||||||||
Malware protection software or definitions not current | Include Anti-Malware definitions in the Vulnerability Management process (see “Vulnerability Management”). Consider a Host and/or Network Anti-Malware solution based on whitelisting rather than signature-based detection (see Chapter 7, “Establishing Secure Enclaves”) | ||||||||||||||||
Malware protection software implemented without exhaustive testing | Include Anti-Malware definitions in the Vulnerability Management process (see section “Vulnerability Management”). | ||||||||||||||||
| Network Configuration Vulnerabilities | Suggested Actions | ||||||||||||||||
Weak network security architecture | Identify functional groups and separate into security enclaves with appropriate security measures (see Chapter 7, “Establishing Secure Enclaves”) | ||||||||||||||||
Data flow controls not employed | Implement firewalls, IDS/IPS, routing and/or ACL controls to enforce data flow control. Analyze network flows using Network Management System (NMS), Network Behavior Anomaly Detection (NBAD), SIEM, or other tools to monitor data flow violations (see Chapter 7, “Establishing Secure Enclaves”) | ||||||||||||||||
| Network Perimeter Vulnerabilities | Suggested Actions | ||||||||||||||||
No security perimeter defined Firewalls non-existent or improperly configured | Identify functional groups and separate into security enclaves with appropriate security measures at the perimeter of each enclave (see Chapter 7, “Establishing Secure Enclaves”) | ||||||||||||||||
Control networks used for non-control traffic | Monitor within control network enclaves for non-DCS traffic. Also implement exception rules at other demarcations to prevent non-control traffic that originates from a control network. For example, adding Deny %DCS_IP_ADDRS to Any rules at the Internet firewall (see Chapter 7, “Establishing Secure Enclaves”) | ||||||||||||||||
Control network services not within the control network | Monitor for SCADA and DCS outside of their respective enclaves, and deny this traffic at enclave perimeters (see Chapter 7, “Establishing Secure Enclaves,” and Chapter 9“Monitoring Enclaves”) | ||||||||||||||||
Inadequate firewall and router logs | Enable logging on all networked devices, and implement centralized log collection and analysis (see Chapter 9“Monitoring Enclaves”) | ||||||||||||||||
No security monitoring on the ICS network | Implement SCADA- and DCS-capable NIDS or other network probe(s) in control system networks to act as a passive ICS security monitoring device | ||||||||||||||||
| Ideally use these devices as part of a larger security information monitoring solution such as a SIEM | |||||||||||||||||
| Communication Vulnerabilities | Suggested Actions | ||||||||||||||||
Authentication of users, data or devices is substandard or nonexistent | Implement centralized authentication management. Ideally, monitor user activity using a monitoring tool with IAM context | ||||||||||||||||
Lack of integrity checking for communications | Implement whitelisting technology to assure only validated communications are initiatedImplement application-layer content inspection devices or similar technology to verify the integrity of all communications to assure that “validated” applications and protocols have not been modified on the wire | ||||||||||||||||
| Wireless Connection Vulnerabilities | Suggested Actions | ||||||||||||||||
Inadequate authentication between clients and access points | Secure all entry points from wireless, dial-up and other remote access methods via isolated enclaves (see Chapter 7, “Establishing Secure Enclaves”) | ||||||||||||||||
Mapping suggested actions to the ICS vulnerabilities identified by NIST shows the necessity of performing thorough vulnerability assessments and isolating the detected ports and services into clearly defined and secure enclaves.
Note
Table 6.3 represents only a subset of the identified ICS vulnerabilities identified by NIST. For a full list of identified ICS vulnerabilities, please refer to the latest version of NIST Special Publication 800-82, available at http://csrc.nist.gov/publications/PubsSPs.html.
Why Vulnerability Assessment Is Important
Apart from the known architecture, procedural or configuration vulnerabilities that can be easily addressed in advance through security best practices, to manage vulnerabilities it is first necessary to assess the network to determine what specific vulnerabilities exist, and where. This requires either extensive manual assessments of each network asset or the use of an automated vulnerability assessment (VA) tool. Automated tools greatly facilitate the process of vulnerability assessment through a combination of various network and asset scans and the correlation of the results to known vulnerabilities, typically from a central data repository of known threats that is maintained by the VA tool.
The scanning of networks and assets in an attempt to find unpatched vulnerabilities is also one of the initial steps of an attack, as discussed in the section “Basic Hacking Techniques.” VA scanning tools are often used by hackers, and in fact the very popular exploit framework Metasploit (www.metasploit.com) was acquired by vulnerability assessment vendor Rapid7 in October, 2009 specifically to “[bring] richer exploitability data to customers and partners … enabling them to better identify, prioritize and remediate critical security issues.”28
28.Rapid7, LLC, Press Release: Rapid7 acquires metasploit. < http://www.rapid7.com/news-events/press-releases/2009/2009-rapid7-acquire-metasploit.jsp>, October 21, 2009 (cited: December 23, 2010).
When a vulnerability is found, it must be remediated. Remediation can be achieved by applying a patch to the vulnerable system (if one is available) to eliminate the vulnerability, adjusting the system’s network or operating configuration to functionally eliminate the vulnerability, or by eliminating the vulnerable system altogether. 29 If the system is critical and cannot be remediated, the option of last resort is to isolate the vulnerable system in order to effectively quarantine the vulnerability. This process of vulnerability management and remediation is covered in more detail in the section “Vulnerability Management.”
29.P. Mell, T. Bergeron, D. Henning, Special Publication 800-40 Version 2, Creating a Patch and Vulnerability Management Program, National Institute of Standards and Technology (NIST), November, 2005.
Before managing vulnerabilities, however, they must first be identified. However, as discussed earlier under “Basic Hacking Techniques,” scanning industrial networks can be detrimental to operations, as many industrial network protocols are sensitive to latency, jitter, and/or unexpected network utilization (see Chapter 4, “Industrial Network protocols”). Because of this it is necessary to understand how to perform a non-disruptive scan, when to scan, and where.
Vulnerability Assessment in Industrial Networks
Because many industrial network protocols are sensitive to latency and/or latency variation (jitter), any large amount of introduced network traffic could cause a failure. Aggressive scans that actively probe many addresses and ports in rapid succession could overwhelm an industrial network. Likewise, broad scans that attempt to penetrate through multiple network hops could unintentionally reach and disrupt a process control system. Because of this, vulnerability scans should be performed differently depending upon what the network it is scanning: in a non-production test environment, both hard and soft scan methods should be used; while in production environments, only soft scan methods should be used. By subjecting an industrial system to aggressive scanning techniques in a test environment, it can be determined if the scan will actually disrupt the network, and if so how. Any failure should be treated as a vulnerability, and addressed according to established vulnerability management procedures (see section “Vulnerability Management”). Obviously, a scan that causes a failure will also fail to determine all open vulnerabilities, so soft scans should also be performed—first in the test environment, and then in production environments during scheduled maintenance windows.
Soft scans replace hard techniques with somewhat more intrusive techniques that require much less network overhead, effectively reaching the same goal (to find open ports and services, patch levels, etc.) but with less risk to sensitive networks. If attempting to identify the devices on a network, instead of a ping sweep using a tool such as Nmap, which can potentially introduce significant traffic to the network, the Content-Addressable Memory (CAM) tables of Ethernet switches or the router tables of Ethernet routers can be examined to both identify valid network addresses and also determine where they are located in the network. If a device within the network is compromised, it can also be used to sniff live network traffic, extracting source and destination address information of all nodes that are actively communicating on the network. 30
30.D.P. Duggan, Sandia Report SAND2005-2846P, Penetration Testing of Industrial Control Systems, Sandia National Laboratories, March, 2005.
To identify open ports and services, soft techniques again require gaining access to a system or device and looking at local network statistics. In place of “outside in” sweeps that query device after device to identify available services, the “inside out” approach utilizes tools such as netstat to list all network connections from a single host. Netstat is able to show the protocol, the source address, destination address, and the state of the connection. By looking at connection information, a list of active systems and the services that they are using can be compiled; the more host connection tables that can be examined, the more complete the list will be. 31 Many commercial VA tools support soft scanning in this manner, using valid user credentials to legitimately authenticate to systems and gather network and service information from the host operating system.
31.Ibid.
Mapping a list of discovered network devices and their open ports and services to known vulnerabilities can be done passively as well. In place of actively scanning for vulnerabilities using a VA tool, a passive scan can be performed using the same tool. Passive VA scanning sniffs network traffic (or in some tools, accepts pcap files from previously captured traffic) to perform “soft” detection of devices, ports and services, and then reconstructs the communication so that a banner analysis can be performed. 32 Banner analysis—the process of examining information banners in application services—can identify version information and other specifications about a particular service that is in use. Mapping this information to a database of known vulnerabilities, such as the Common Vulnerabilities and Exposures (CVE) list published by the MITRE Corporation, identifies known vulnerabilities that are present in the network. This mapping can be automated, as part of a passive VA scan, or it can be performed manually. 33
32.R. Deraison, R. Gula, T. Hayton, Passive vulnerability scanning introduction (revision 14), tenable network security, < http://www.nessus.org/whitepapers/passive_scanning_tenable.pdf>, October 13, 2009 (cited: December 23, 2010).
33.D.P. Duggan, Sandia Report SAND2005-2846P, Penetration Testing of Industrial Control Systems, Sandia National Laboratories, March, 2005.
When scanning an active control system, safe scan methods should always be used. If manual control of the system is possible, personnel capable of performing manual control must be present during the security testing. 34 Ideally, a test system will be available for “hard testing” in a non-production environment. If possible, build out a test system, or plan to perform hard tests against production systems during scheduled maintenance windows or other periods of downtime. This will allow you to identify and document the detrimental effects of a hard scan, so that compensating measures can be introduced. For example, it is possible to block ping sweeps and may be possible to implement traffic throttling controls or to provide additional network separation that can protect against more sophisticated and aggressive scans.
34.Ibid.
Vulnerability Scanning for Configuration Assurance
Assessing vulnerabilities and documenting them is a compliance requirement of NERC CIP-007, specifically requirement R2 (which requires the identification of open ports and services) and R8 (which requires a vulnerability assessment). However, the vulnerability assessment process can be used for additional compliance purposes as well. One example is the Bandolier project by Digital Bond. Bandolier is a Department of Energy–funded project designed to audit configuration files in control system environments. Written for the Nessus vulnerability scanner, Bandolier helps to validate the security configuration of a workstation, identify ports and services, detect default passwords and accounts and verify password requirements, and audit the status of malware prevention software. 35 Bandolier is an example of a soft vulnerability scan configuration: it uses valid credentials to authenticate to each system and then uses local tools such as netstat to obtain port and services information, capture application banners, etc. 36 Many of these functions could be performed manually as well, although the use of an automated tool can simplify the process and help to eliminate oversight. In some cases additional monitoring tools can be implemented to help with configuration assurance. For example, a passive application monitor that is capable of decoding and analyzing application sessions could compare authentication credentials against known defaults, determining weak passwords, etc.
35.Digital Bond SCADApedia, Bandolier and NERC CIP. < http://www.digitalbond.com/wiki/index.php/Bandolier_and_NERC_CIP>, 2010 (cited: December 23, 2010).
36.Digital Bond, Bandolier. < http://www.digitalbond.com/index.php/research/bandolier/>, 2010 (cited: December 23, 2010).
Configuration assurance can also be addressed through configuration management, which allows a proven configuration to be validated and then managed, notifying the administrator when a configuration change occurs. Configuration control is an important part of Vulnerability Management and can help maintain a compliant configuration once one has been established (see the section “Vulnerability Management”).
Note
There are many commercial vulnerability assessment tools. Although Bandolier was written for the Nessus scanner, optimized vulnerability scanning options for industrial networks may be supported by other scanners as well. When evaluating vulnerability assessment products or services, ask the vendor or consultant about how the specific tool(s) support SCADA and DCS protocols, if there are specialized scan profiles, audit files, or other customizations that support safe scanning within industrial control systems.
Where to Perform VA Scans
Especially in industrial networks that consist of (sometimes) clearly defined security enclaves and (most of the times) overlapping or poorly defined security enclaves, knowing where to perform a scan is as important as knowing how to perform a scan. A rule of thumb is whenever attempting to functionally isolate a group of devices or services, first quantify that group into a defined enclave (see Chapter 7, “Establishing Secure Enclaves”) and then perform a penetration test against it. This requires first scanning the network immediately outside of the enclave, as well as scanning from within the enclave to ensure that there are no outbound vulnerabilities.
The reason for this is simple: in a network that contains nested security enclaves, some enclaves may not be immediately vulnerable from every other enclave. For example, it may not be possible to exploit an RTU directly from the Internet. However, if an attacker breaches the business network and then the SCADA DMZ, there may be new vulnerabilities present. Penetration testing should first be performed from the outermost entry points (such as an Internet firewall or a VPN gateway). Next, the tests should be repeated from “one level in,” assuming that the first line of defense has been compromised.
This accomplishes two things: first, it helps to detect all addressable vulnerabilities within nested enclaves; second, it helps to identify ports and services that are in use so that “disjointing” of communications policies can be implemented where possible. For example, in a control system enclave that utilizes Modbus TCP, port 502 will be open to support this protocol. To protect that traffic, port 502 should be filtered in the next outermost enclave (in this example, it is perhaps the SCADA DMZ), if possible. In our example, the SCADA DMZ probably requires Modbus TCP connections as well, and so port 502 should be filtered at the outer boundary of the DMZ instead. In this way, the protocol is “disjointed,” meaning there is no single path from the Internet to the control system over port 502.
Cyber Security Evaluation Tool
The Cyber Security Evaluation Tool (CSET) is a software tool available from the National Cyber Security Division of the DHS. CSET walks through a control system vulnerability assessment process, and then produces guidelines for vulnerability remediation. The CSET recommendations are made after comparing the assessment against relevant NIST, ISO, NERC, and other standards. Note that the CSET assessment is a user survey designed to evaluate policies against recommendations, and is not a “vulnerability assessment” as described in the section “Vulnerability Assessment in Industrial Networks.”37
37.Control Systems Security Program (CSSP), Cyber Security Evaluation Tool: overview, United States Computer Emergency Readiness Team (US-CERT). < http://www.us-cert.gov/control_systems/satool.html>, 2010 (cited: December 23, 2010).
Vulnerability Management
Once a vulnerability has been identified, it needs to be eliminated. Depending upon the nature of the vulnerability, it may be addressable via a software patch or a configuration adjustment, or it may need to be removed. 38 Patching and configuration-based remediation require careful management: patches, while technically a “fix” for a known vulnerability, represent new code and should be carefully tested prior to installation. Configuration changes may also fix a vulnerability, but may impact other systems or devices and therefore require controlled testing as well. Configuration adjustments could include direct adjustments to the vulnerable system itself, such as disabling vulnerable or unused services or modifying user privileges, or configuration adjustments to outside systems, such as modifying firewall or IPS policies or limiting access via router Access Control Lists (ACLs) to block the vulnerable service. 39 Obtaining patches can also prove challenging: downloading up-to-date software from vendor websites requires connectivity to the Internet, yet with proper security enclaves in place, the systems requiring an upgrade should not have this connectivity. Instead, a patch management enclave should be established, providing an additional barrier between online patch management and the systems requiring upgrades. Patches obtained in this way still must be transferred to the system needing an upgrade, and even if patches are “walked in” using removable media, the process represents a potential attack vector (albeit a small one). Figure 6.9 illustrates the vulnerability assessment and remediation process, accounting for the isolation of patch management and configuration management.
38.P. Mell, T. Bergeron, D. Henning, Special Publication 800-40, Version 2, Creating a Patch and Vulnerability Management Program, National Institute of Standards and Technology (NIST), November, 2005.
39.Ibid.
If the vulnerability is not addressable via a patch or configuration change, the vulnerable service should be removed. This may be easy or difficult depending upon the criticality of the vulnerable system. If an HMI is found to posses Microsoft Internet Information Service (IIS) vulnerabilities, the decision is easy: web services should not be necessary or allowed within SCADA and control networks, and so the service can be safely removed. However, if the same HMI has vulnerabilities in core OPC services and there is no patch available, you cannot simply disable the service as it would effectively disable the HMI. In these cases, the offending system should be quarantined: effectively locking down its security enclave and preventing any access exceptions at the perimeter. For example, if there is an HMI system with OPC vulnerabilities, all systems that connect legitimately via OPC should be grouped into an enclave and isolated from remaining systems with strong firewall and/or IPS policies. More advanced threat and malware detection should also be considered in these circumstances, such as protocol or application inspection at the perimeter, to ensure that all OPC protocol traffic is legitimate and benign. This is covered in more detail in Chapter 7, “Establishing Secure Enclaves.”
Patch Management
The most secure and effective method of obtaining and applying a software patch is through the use of a dedicated patch management system. Because this system will be responsible for connecting to the Internet and downloading unverified software, it should be treated with caution and carefully isolated from other systems. The adequate sandboxing of patch management systems is paramount, as patch management system introduce significant risk. According to NIST SP 800-40, creating a Patch and Vulnerability Management Program, the following risks may be introduced when obtaining patches through a commercial patch management system: 40
40.Ibid.
• The software vendor’s patch might have been corrupted or infected with malware, either prior to distribution or during the distribution process.
• The patch management system could become infected, compromising all subsequently obtained patches.
• The patch management tool could be used by an attacker as centralized attack vector to industrial systems, leveraging the patch distribution capabilities.
• The patch management system could be used by an attacker to identify participating systems, as well as which patches have/have not been applied to participating systems.
• Once breached, the patch management software could be used to elevate privileges of participating systems, gain administrative access to participating systems.
Locate the patch management system within an enclave that already has open Internet access, such as the business network. If the patch management system needs to be located in SCADA or DCS networks (e.g., if the business network is geographically separate), create a unique enclave for patch management with true air gap boundaries. The patch management system is responsible for downloading and testing patches, configuration files, upgrades, and other third-party material; testing it for malware; and then archiving the validated files to read-only media (preventing any subsequent infection or manipulation). The entire patch management process is illustrated in Figure 6.10.
Applying patches, once validated, also requires caution. Even clean files may impact the operation of the target system in some unintended manner. This is especially true on industrial devices that utilize legacy versions of operating systems, as new software updates may only be tested and supported by the vendor on newer OS versions. To ensure that the new patch or configuration will not impact the target system, full testing of the application should be performed on a functionally identical test system. Ideally, an isolated test network should be maintained that contains an offline version of all systems in use. If patching an operating system (such as a Windows update or service pack), all applications on that host that are in use should be fully tested, as even minor changes in the OS could unintentionally affect third- party software. 41
41.K. Stouffer, J. Falco, K. Scarfone, National Institute of Standards and Technology, Special Publication 800-82 (Final Public Draft), Guide to Industrial Control Systems (ICS) Security, Section 6.3.1 Identification and Authentication, September, 2008.
Automated updates are supported on many newer systems, and third-party commercial solutions are also available to automate the distribution and application of patches. Automation offers many benefits, including greater assurance that obtained patches are successfully applied. However, the systems used to obtain patches and to distribute patches should be kept separate, or there will be an automated mechanism in place that allows inbound Internet attacks to spread directly to industrial systems. If required, implement two instances of the patch management system: one to retrieve patches in isolation and one to distribute the validated patches after they have been hand carried across a true air gap.
Note
Note that the required sandboxing of these systems can be facilitated using virtual machines (VMs), allowing the patch management system to be easily restored to a known clean state after every use. This will prevent the patch management itself from being infected with malware that could then compromise all subsequently obtained patches.
Configuration Management
Configuration management refers to the process of documenting the active configurations of all systems, validating known “good” configurations, monitoring all systems to ensure the use of known “good” configurations, and monitoring all systems for any subsequent changes to the validated configuration. The logic is simple: any change could introduce risk, so once a system has been appropriately patched and configured, that system should not be changed. If a new vulnerability is found, the configuration management process allows a new configuration to be validated, at which point systems are reassessed against the new valid configuration.
As with validated patches and upgrades, a digital record of validated configurations should be stored on read-only media, ensuring that there is a clean, unadulterated copy of the configuration for use in turning up new systems, rolling back test systems, etc.
Note
Because many attacks attempt to adjust the configurations of the penetrated hosts (e.g., escalating privileges, disabling logging, etc.), configuration management tools can be useful for security monitoring and threat detection as well. This is discussed in more detail in Chapter 9, “Monitoring Enclaves.”
Device Removal and Quarantine
When a vulnerability cannot be remediated via patch or configuration management, the vulnerable system should be removed. If the service is critical, and there is no viable and secure replacement, the only alternative is completely isolate that vulnerability. Quarantining a service based upon enforced policies requires that all access to the vulnerable service is cut off from any non-essential communications, with all essential communications being encrypted for further protection. The service should also be disjointed across enclaves, with explicitly defined “deny” policies at all encompassing firewalls, IDS/IPS, and other devices. This ensures that no direct access to the vulnerable service exists. Quarantined enclaves are discussed in Chapter 7, “Establishing Secure Enclaves.”
Summary
Understanding how an attack might be performed, the importance of identifying and remediating vulnerabilities becomes clear. The importance of establishing secure enclaves that isolate functional groups—especially control system functions, which utilize specialized protocols that can facilitate the most basic steps of an attack: scanning to identify targets, enumerating the client/server relationships within the control protocol (as there is no real authentication to enumerate), and the delivery of a malware payload and/or the direct control over a process.
To adequately assess vulnerabilities in a control network, however, appropriate vulnerability assessment techniques must be used in order to prevent potential disruption of sensitive industrial protocols that may be in use. In addition, the various entry points—the paths through which an attacker might attempt to gain access to the industrial control network—must be understood, so that vulnerability detection can used as part of a real penetration test: identifying all the vectors and exploits that are available to an attacker enable vulnerabilities to be remediated, significantly increasing the overall security of the industrial network. No network should be assumed safe, and assessment of vulnerabilities from various internal networks should be performed.
Once an understanding of how various systems might be vulnerable is achieved, the process of securing and isolating them can begin. The information obtained from a strong vulnerability assessment and patch management strategy will also facilitate the process of both defining and securing these functional groups into secure enclaves, discussed in detail in Chapter 7, “Establishing Secure Enclaves.”
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.