SCADA Security and Deep Packet Inspection – Part 2 of 2
Deep Packet Inspection (DPI) is important for the future of SCADA / ICS security - and in this article I explain why.
DPI SCADA Security: Reviewing the Basics
In Part 1 of this series I explained DPI technology in detail. To review, the traditional IT firewall examines the TCP/IP and Ethernet headers in the network messages it sees. It then makes decisions whether to allow or block a message based on this limited information.
DPI technology allows the firewall to dig deep into the SCADA protocols that sit on top of TCP/IP and Ethernet. The firewall then determines exactly what the SCADA protocol is being used for and makes better decisions on what should be allowed or blocked.
The example I gave in the last article was the seaway management company that used Tofino Modbus DPI firewalls1 to protect the PLCs running its canal locks and bridges. By blocking all Modbus write messages (and programming messages), and allowing Modbus Data read messages, the company could improve the safety of the canal system for both the ships in the canals and the public using the draw bridges at the locks.
Why New Malware Demands DPI Technology
Five years ago I would have said that DPI is just a nice-to-have capability. Now thanks to the current generation of worms like Stuxnet, Duqu and Conficker, it is a must-have technology if you want a secure ICS or SCADA system.
Today’s malware designers know that firewalls and intrusion detection systems will spot the use of an unusual protocol instantly. They know that if the protocols on a network are normally HTTP (i.e. web browsing), Modbus and MS-SQL (i.e. database queries) then the sudden appearance of a new protocol will put the smart system administrator on his or her guard.
Thus worm designers work to stay under the radar by hiding their network traffic inside protocols that are already common on the network they are attacking. For example, many worms now hide their outbound communications in what appear to be normal HTTP messages.
Stuxnet is a particularly good example of this covert use of otherwise innocent protocols. It made heavy use of a protocol called Remote Procedure Call (RPC) for both infecting new victims and for peer-to-peer (P2P) communications between infected machines.
Stuxnet spread many ways, including using the protocol RPC as a vector.
Now RPC is an ideal protocol for SCADA and ICS attacks because it is used for so many legitimate purposes in modern control systems. For example, the dominant industrial integration technology, OPC Classic, is based on DCOM and this in turn requires that RPC traffic be allowed.
Furthermore, control system servers and workstations are routinely configured to share files or printers using the Microsoft SMB protocol, which also runs on top of RPC. Perhaps most relevant in this example, all Siemens PCS 7 control systems make extensive use of a proprietary messaging technology that travels over RPC. So if you were an administrator watching network traffic on a Stuxnet infected network, all you would see was a little more RPC traffic than usual, hardly a cause for alarm.
Even if you suspected something was wrong, you would be stuck if all you had was a normal firewall. The simple blocking of all RPC traffic would likely result in a self-induced denial of service for your entire factory. Without tools to inspect the contents of RPC messages and block suspicious traffic (i.e. deep packet inspection), your hands would be tied.
Deep Packet Inspection Provides Fine-Grained Security
DPI technology is a very powerful tool in the security tool box. It allows the engineer to block the bad stuff, yet avoid needless impact on the control system. Without it, the designers of modern worms clearly have the upper hand.
In order to stay ahead of the bad guys, DPI has become a must-have in industrial firewalls. How is this affecting your ICS security plans?
1 Full Disclosure: The Tofino Modbus TCP Enforcer deep packet inspection firewall is developed by Tofino Security
Related Content to Download
Note: you need to be a member of tofinosecurity.com and logged in to have access to the document below. Register here to become a member.
|
Application Note - "Using Tofino to Control the Spread of Stuxnet Malware"
|
Related Links
- SCADA Security & Deep Packet Inspection – Part 1 of 2
- Tofino Modbus TCP Enforcer Loadable Security Module
- How Stuxnet Spreads
- Summing up Stuxnet in 4 Easy Steps
- Defense in Depth Part 2: Layering Multiple Defenses
- Why VLAN Security isn't SCADA Security at all
Comments
Malware propagation through RPC
Stuxnet wasn't the first malware to use RPC for propagation. All ( including Stuxnet) give themselves away because they use a try and error mechanism to find the next vulnerable server in the network.
Process control networks are very deterministic w.r.t . outbound traffic, all destination addresses are generally known. So proper egress rule settings with some frequent log inspections should have given away that there was an infected node in the network. Problem is very often only inbound traffic is filtered. Therefore I think a properly configured stateful firewall and properly implemented security management processes would also have discovered Stuxnet. Probably within 24 hours after an infection. I think in the Stuxnet case a lot more went wrong then the Siemens exploit.
Malware propagation through RPC
Your points are good. I agree that outbound plant floor traffic is often not filtered and this is a major security gap. Certainly someone on the plant floor accessing web servers with names like mypremierfutbol.com and todaysfutbol.com (the URLs for Stuxnet's command and control servers) should have triggered alarms in any facility. Even if we forgot the malware part of the equation, this would be an obvious "allowed use" violation for most companies. The trouble is, many companies would not detect this sort of activity.
Just as serious, I see many sites setting up non-stateful packet filters on switches and thinking these are "firewalls". Starting this week, Joel Langill will be contributing a few blogs explaining this particular security shortcoming.
Back to basic's series.
Hi Eric I always enjoy reading any words you put together on a given topic. This latest series is worthy of being compiled into a reference guide!
Thanks for putting them on your blog and I hope that you do put them together in a single PDF reference resource.
Ron
Back to basic's series
A "Back to Basics" series of PDFs is a great idea. We will start working on that, so expect to see something soon!
Thanks for the idea.
Regards
Eric
Malware propagation through RPC - response
But, with Stuxnet, the outbound system that the process control network was communicating to was a known, acceptable system. Thus, the communication looked to be normal. That's the way that Stuxnet got into the process control network. It infected a system that was known to the process control system, and used it's communication pathway into the process control network to deliver its payload. Any communication outbound was back to the same, "trusted", infected system.
Malware propagation through RPC - response
The propagation scans for hosts to propagate to, so yes when it connects to the right server it all looks normal, but just like conficker it doesn't hit this server immediatly. It runs an algorithm trying out various addresses, some of which are outside the broadcast domain and would be routed and caught by the egress filter. Also conficker makes use of this vulnerability and leaves a trace.
Malware propagation through RPC - response
The problem I see with the RPC protocol and traditional firewalls, is that it offers too juicy an attack opportunity. At the level of a normal layer 3 firewall, all RPC traffic looks the same. You can't write rules that allow OPC over RPC, but block Stuxnet's P2P system that also runs on RPC.
With a DPI capable firewall that digs into the RPC messages, you can detect these differences. For example, the Tofino OPC Enforcer will only allow OPC traffic and drop any other RPC traffic, including the Stuxnet P2P network. These drops would have generated alarms, warning the victim that something bad was happening.
Deep Packet Inspection
Eric: Your DPI paper is dedicated to the Siemens S7 PLC, the PLC that was attacked by Stuxnet in the Natanz nuclear plant. Your paper mentions Whitelisting, and firewalls, but does not mention the vulnerable, write-always memories of the S7s. If the S7 were equipped with a read-only memory, then I would like to ask which particular items of Tofino software defenses would still be needed to protect control systems?
Deep Packet Inspection and Read-Only Memory
The possibility of using write-once memory for ICS security is an interesting one. I have commented on this in past blogs such as http://www.tofinosecurity.com/blog/air-gaps-won%E2%80%99t-stop-stuxnet%E....
Now to answer your question on whether DPI defences would be needed to protect control systems if they all used write-once memory, the answer is YES.
In all controllers, there will be some memory that is not read-only. For example, the memory containing dynamic information such as the measured process variables and set points cannot be read-only.
This memory will still need to be protected, even if write-once memory is used for the controller operating system (and possibly process logic). So DPI is needed to prevent modification attacks on dynamic variables, such as changing the set point of a critical loop to a dangerous value, or remotely modifying the I/O force tables. DPI is also needed to protect against DoS attacks that send deliberately malformed SCADA messages that take advantage of flaws in the PLC logic.
Also consider that even if all controller manufacturers started using read-only memory tomorrow, the world will still be faced with the issue of securing legacy products. DPI is a good defense for all the existing insecure hardware that we have to live with for another 20 years.
To close, I believe that there is no silver bullet for security, including either DPI or read-only memory. However if used together in an intelligent manner, these and other security technologies can give us true defence in depth and protect our critical system.
Add new comment