Protecting ICSs from Electronic Threats, II

By Joe WEISS, PE, CISM, Applied Control

The following is the second section of a three-part Security Spotlight series that consists of portions of Joe Weiss' Protecting Industrial Control Systems from Electronic Threats, Momentum Press, 2010. Part 1 ran in the June issue of Control, and Part 3 will run in the October issue. In industrial control systems (ICS), cyber attacks tend to focus on destabilizing assets. Because integrity and availability are most important for ICSs, their security also relies more on authentication and message integrity.

Fortunately, IC security is an engineering problem that requires engineering solutions. Resilience and robustness are the critical factors in the survivability of compromised ICSs. Their security requires a balanced approach to technology design, product development and testing, development and application of appropriate ICS policies and procedures, analysis of intentional and unintentional security threats, and proactive management of communications across view, command and control, monitoring and safety. It's a lifecycle process that begins with the conceptual design of a system and continues through to its retirement.

Threats and Myths

To begin dealing with cyber threats to ICSs, it's useful to break them out in four main ways:

• Insider intentional threats—usually by disgruntled employees, vendors, system integrators or anyone else with internal knowledge or access to the ICS.
• Internal unintentional threats—from inappropriate system designs, policies, architectures procedures, technologies or testing.
• External non-targeted threats—due to maliciously designed software viruses and worms.
• Malicious actors—that includes hackers, criminals and nation-states.

Besides these threats, there are many misconceptions about cybersecurity that can impact ICSs and their users. These myths include:

• "The Internet and Microsoft Windows are the biggest cyber threats." Many cyber incidents didn't involve either.
• "Using Windows and TCP/IP Makes it IT." Distinctions between IT and ICSs are blurring.
• "External malicious threats are always the biggest concerns." Less than 25% of 170 cyber incidents were due to external threats.
• "Firewalls make you secure." They're only speed bumps to knowledgeable hackers.
• "Virtual private networks (VPNs) and encryption make you secure." VPNs can send compromised data too.
• "Intrusion detection systems (IDSs) will identify control system attacks." New attack signatures are constantly being identified.
• "Field devices can't be hacked." Some have already been hacked.
• "You're secure if hackers can't get in." Many cyber incidents have originated internally.
• "More and better widgets can solve our security problems." Security policies must be instilled in people or the devices will be useless. 
• "You can air-gap control systems." Communications technologies make many ICSs almost impossible to air-gap.
• "IT cybersecurity policies apply to ICSs." But they often don't address unique ICS issues.
• "Each industry requires a different approach." From an ICS security perspective, instrument and controls vendors supply common hardware with standard software.
• "If we keep our heads down they won't find us." SCADA and ICS security are common terms at hacker meetings and websites.
• "ICS cybersecurity is a North American electric issue." ICSs supplied to all process industries worldwide are pretty much the same. 
• "North American Electric Reliability Corp.'s (NERC) Common Industrial Protocols (CIPs) reduce cyber exposure." NERC CIPs have many exclusions, and even meeting them wouldn't have prevented many cyber incidents.
• "NERC CIPs are being employed uniformly." NERC CIPs allow so much flexibilty by utilities that they don't have common asset definitions.
• "Control system cyber forensics exist." Windows-based HMIs have cyber forensics, but legacy field devices have very little.
• "Control system audit metrics exist." There are no audit metrics specifically for control system cybersecurity.        

Personnel and an ICS-CERT Needed

Arguably, there are less than several hundred people worldwide with expertise that falls in the realm of ICS security experts. Of that very small number, an even smaller fraction exists within the electric power community.
There are many reasons for this imbalance. As opposed to traditional business IT, the area of ICS cybersecurity is a still developing area. It's an interdisciplinary field encompassing computer science, networking, public policy and engineering control system theory and applications. Unfortunately, today's computer science curricula often do not address the unique aspects of control systems. Likewise, most of the electrical, chemical, mechanical, nuclear and industrial engineering curricula don't address computer security.

Consequently, there is a need to form joint programs for ICS security. Presently, the U.S. Department of Homeland Security and Lawrence Livermore National Laboratory are developing an ICS security curriculum at the policy level, but there is still a need to develop the technical curriculum.

In addition, the U.S. Department of Energy funded a project in 2004 that helped establish its Computer Emergency.

Response Team (CERT) for the energy industry's control systems, and this has been expanded to include other industries as the Industrial Control System (ICS) CERT. However, the CERT/Coordination Center (CC) at Carnegie Mellon University's Software Engineering Institute and other existing CERTs have little experience in dealing with the direct cyber impacts of Internet- and other cyber-based attacks on ICSs. What is needed is a non-governmental ICS-CERT capability that deals, not only with traditional Internet-based cyber vulnerabilities and threats, but also with those that arise at the intersection of network-based IT systems and ICSs. This ICS-CERT would collect and process cybersecurity reports for ICS end users, distribute alerts and recommendations, develop and disseminate best practices and training on countermeasures, and analyze new data to support existing activities and form responses to new threats.        

Technical ICS Security Recommendations

Based on my and others' experiences, I'm providing these technical recommendations for improving cybersecurity:

• Determine how much electronic communication traffic your ICS can use efficiently and then prevent excessive traffic that could impact the ICS.
• Because a TCP/IP LAND attack consists of TCP packets with identical source and destination IP addresses and TCP ports, these kinds of packets should never be found in legitimate traffic, and they can and should be safely blocked.
• Port scans can disrupt ICS operations and are often precursors to more sophisticated network attacks because they perform reconnaissance on target devices. So an effective security practice is to simply block port scans and prevent potential attackers from gaining information.
• Because IP fragmentation attacks are common triggers of vulnerabilities, fragmented packets should be limited to slower data rates than unfragmented packets. Ideally, fragmented packets should not be allowed on the control system network. Maximum transmission unit discovery also can be used to prevent the need for fragmentation.
• Some packet header-field value combinations should not occur in valid traffic. For example, in the TCP header, TCP SYN and FIN flags can't both be enabled. Or in the IP header, "don't fragment" and "more fragment" bits can't both be enabled. So any packets with both are almost certainly being sent for a bad purpose and should be blocked.
• Because an Address Resolution Protocol (ARP) Cache Saturation Storm can fill a device under a test's (DUT) ARP cache with unsolicited replies, this test can disrupt many ICS operations. As a result, a device's network stack should add to its ARP cache only when it has sent a corresponding ARP request. All other replies should be ignored.
• Limit memory and central processing unit (CPU) time allocated to non-critical tasks, such as web servers, so they don't take memory and processing time from critical processes, such as those managing process control functions. In fact, all processes running on a controller should be ranked and limited by how essential they are to its operation.
• Examine all input from the network for errors and formatting correctness, such as checking and verifying data lengths and types before processing, and discard any data that doesn't fall into valid formats. However, even expected data can mask a problem if it's not properly identified.
• Proper buffer management is essential. Before any data is moved to a buffer, its size and the buffer must be compared. If the data is larger than the buffer, then a buffer overflow may occur, which can lead to security vulnerabilities.
• Because high-speed network traffic needs lots of processing power and ICSs need less bandwidth, limit data reception rates to appropriate levels. Use firewall devices to limit ICS traffic from all basic network protocols, such as ARP, Internet Message Control Protocol (ICMP), TCP and User Datagram Protocol (UDP).                         

[Next time: Part 3 will feature cybersecurity risk assessments, vendor and governmental recommendations, and ICS cyber incidents and responses.]

Joe Weiss, PE, CISM, of Applied Control Solutions (www.realtimeacs.com) is author of Control's Unfettered blog (community.controlglobal.com/unfettered).