Security Experts:

Bridging the Air Gap: Examining Attack Vectors into Industrial Control Systems

Enterprise and ICS networks should at least be separated at layer 3, so it’s probably more accurate to say that we’ve routed the air gap, but I didn’t want to give up the double entendre of bridging the gap. Terrible network jokes aside, the simple truth is that digital networking has displaced the air gap, blowing it into the distant places of legend. It is a myth. It does not exist.

I’m not trying to be controversial, although I know many will disagree with me. I’ll concede that the ideal of the air gap is valid and I’ll even concede that true separation is a viable goal. However, “air” is no longer an effective method of security because there is always a way into and out of a control system, whether over wired connections (where the air gap is purely figurative) or wireless (where the air is a contributor rather than a deterrent) or via sneaker-net (where the air gap is irrelevant). To avoid the inevitable comment, “we don’t need to do this because we are air-gapped,” this needs to be understood prior to talking about how to protect our SCADA and ICS environments against network-based attacks.

Here are two examples of digital bridges: a secured network connection established between SCADA systems and the business network for monitoring purposes, and a secured wireless access point within the SCADA network. Note that both are “secured.” Note that each has at least one direct vector of attack, as well.

One vector is common, one is clever. The first and most obvious is a simple case of network penetration. The “authorized” information flow of SCADA information to the business network has been secured by a correctly configured firewall, allowing only Modbus TCP traffic from a small collection of HMIs to communicate to a particular monitoring workstation. The firewall rule explicitly denies all traffic except for this supervisory channel, which is locked between source and designation IPs, using only TCP port 502. Because inbound and outbound communications are so well controlled, the attack vector is clear: attacks will most likely occur over TCP port 502 from the monitoring workstation, and those attacks will target a small collection of HMIs. Of course, there’s always the chance that the firewall will be compromised, and additional paths will be opened up as well. So what do you do?

First, monitor everything inbound on TCP port 502. Use deep session inspection to verify that all port 502 traffic is properly formed Modbus TCP traffic, and that there are no hidden binaries or payload inside of the authorized communications. This is because advanced attackers will hijack Modbus, mess with its insides, and use it to smuggle malicious code through the firewall. Inbound manipulated Modbus might include malware hidden deep within the session, while outbound command and control channels might be masquerading as Modbus even though they’re actually using IRC or HTTP. The technology of choice here is deep session inspection—next generation intrusion detection systems that perform layer 7 deep packet inspection against entire application sessions. Deep session inspection will tell you that HTTP is running over port 502, for example, or that the Modbus payload contains Base64 encoded binaries. In other words, by looking past a single packet (as most IDS and IPS products do) to examine an entire session, you can be assured that your authorized information flow is valid and un-compromised.

So all it takes is a product? That would be nice, but we all know that security is a process and not a product. This is true here as well—if you read back to the beginning of the last paragraph you’ll note that there are other ways in, such as altering the configuration of the firewall to open a backdoor through which an attack could occur. To protect against this, write the following keywords on a banner and start waving it over your head: “Situational Awareness.” More on that in a moment.

The second example is the clever one. In Digital Bond’s published research from the 2010 SCADA Security Scientific Symposium (S4), there’s an interesting use case of jamming Wi-Fi signals using some commercial electronic components. A wireless access point will typically broadcast itself when no connection exists, so a wireless jammer can cause an endless cycle of WAP discovery, creating extra network traffic that is excessive enough to disrupt certain real-time Ethernet protocols, like Modbus TCP. The attacker doesn’t need to access the network at all, or even enter the building: simply deploy a jammer through your creative mechanism of choice (mine would be an AR Drone Quadricopter) and let the control system sabotage itself. As promised, another attack vector that will ignore an air gap. How do you protect against this one? Look up at that banner you’ve been waving for the last paragraph: Situational Awareness.

Situational awareness, in the context of threat detection, means monitoring all activity on the network. In this example, monitor network flows and compare those against the allowed information flows, per your firewall configuration (and, hopefully, per your internal security plan). If traffic is seen originating from the business network on a port other than 502, or from a source IP that is not your monitoring workstation, or that is not destined to that small handful of HMIs, something must be amiss. Inspection of the firewall may just reveal that it has been manipulated, and is letting rogue traffic into your supervisory network. Better yet, use configuration management to watch that firewall and notify you immediately if any change is detected, thereby giving you a better chance of mitigating the inevitable attack. In our second example, intermittent loss of connectivity of one or more wireless access points can be detected by monitoring network health using SNMP. If we go a bit further, we can correlate that to process failures in the control loop, right? You bet … but that’s another topic for another day. Next time we’ll dig into Situational Awareness and provide some examples of what to monitor, how to monitor it, and how to best utilize that monitoring for threat and risk detection.

Subscribe to the SecurityWeek Email Briefing
view counter
Eric D. Knapp (@ericdknapp) is a recognized expert in industrial control systems cyber security, and continues to drive the adoption of new security technology in order to promote safer and more reliable automation infrastructures. Eric is currently the Director of Cyber Security Solutions and Technology for Honeywell, and is the Chief Technical Advisor, North America for the Industrial Cybersecurity Center. He is also the author of “Industrial Network Security: Securing Critical Infrastructure Networks for Smart Grid, SCADA and Other Industrial Control Systems.” His new book, “Applied Cyber Security for Smart Grids” was co-authored with Raj Samani, McAfee CTO EMEA. The opinions expressed here represent Eric's own and are not those of his employer.