Protecting ICSs from Electronic Threats, II

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).