Industrial Protocols Can be Dangerous, and Should Never be Trusted.
I promised in my initial column that I would talk about SCADA and Industrial Control Protocols, and how to protect a process control network from misuse of these protocols. For those that aren’t paying attention, the context is our good friend Mr. Stuxnet, who found his way into a PLC (Programmable Logic Controller) to listen to and influence a control loop. How did it do this? Simple: industrial protocols are (with a few exceptions) designed for two things: listening to inputs from the process loop; and issuing commands back to it. This, of course, is a problem.
I’m going to generalize here and collapse Modbus, Profinet, ICCP, and other industrial and field bus protocols into one generic use case (for the sake of example). My newly fabricated generic SCADA protocol works like this: there is a Master device (an RTU or PLC, typically) that communicates to any number of Slave devices (relays, sensors … basically any intelligent electronic device, or IED). The communication goes like this:
Master (a gnarly pirate of a PLC): You, slaves! Tell what the values or your registers are! (sound of whipping)
Slave 1 (a pressure sensor): My register reads 123.4PSI, Master! Slave 2 (a pressure relief valve): My register reads 15%, Master! Master: What! Slave 1, that’s too high! Slave 2—change yourself to 35%! (more whipping;
Slave 2 opens itself to allow more pressure to escape)
Master: You, slaves! Tell me what the values of your registers are!
Slave 1: My register reads 115.6 PSI, Master!
Slave 2: My register reads 35%, Master!
(the Master device then grins an evil grin and puts fresh lemon juice and salt on the whip, ready to repeat this process ad infineum).
How the exact communication occurs varies, of course. Sometimes the master requests values, to which the slaves reply; sometimes the slaves provide updates unsolicited; sometimes the slaves are queried in sequence, while in some cases all slaves update a single message in serial, appending each update to the tail end of the last … it’s not a question of how the conversation happens, though, the point is that the information is freely provided, and commands are given and explicitly obeyed.
Note that certain finicky steps are missing: the Master Device never asks the slave to verify it’s identify (i.e., there is no authentication), or for that matter the values that it is reporting; the commands are also being shouted clearly for all to hear (i.e., they are not encrypted). Basically, once you compromise a slave device, you can manipulate the data being read, withhold expected data, send out-of-sequence responses, or otherwise confuse the rigid structure of the protocol until it fails. Once you compromise a master device, you can eavesdrop on the process, and if you so desire, manipulate that process—up to and including the deliberate sabotage of that process. This is what Stuxnet did: it infected a PLC, and listened to the process loop for an indication that a certain motor was operating a certain speed. Once it found that very specific condition, it sabotaged the process.
How in the heck do you stop that? Well, you can try to stop the PLC from becoming infected to begin with, which means protecting the HMI that controls it … and those are excellent ideas—however, there’s another way: listen to the process loop yourself, and simply disallow the unauthorized behavior. Sounds easy, right?
Well, the folks developing the tools might disagree. Digital Bond has done a lot of work developing SCADA signatures for Snort compatible Intrusion Prevention Systems, and it’s not easy. In fact, my company—NitroSecurity—does threat research and signature development that includes SCADA protocols as well; we contribute our work to Digital Bond’s much larger pool of resources and can testify to the effort involved. Companies like Byres Security and Secure Crossing have gone even further, building out deep taxonomies based on the specific command and function codes used within these protocols, so that very specific behaviors can be identified and—if necessary—blocked. Luckily, a lot of these tough real-time decisions are masked from the asset owners, who are left with the much simpler task of determining what ‘normal’ is, so that security controls—SCADA firewalls, Intrusion Prevention Systems, transaction whitelisters, or even data diodes—can operate more accurately and efficiently:
• Assess the assets that make up the control process to determine any potential vulnerabilities. Don’t panic when there are plenty of them (yet). The next few steps will help to compensate for many of them, and hopefully all of them.
• Assess the control process that you’re aiming to protect. What protocols are in use (legitimately)? If the system exclusively uses Modbus+, for example, there’s no need to allow Modbus TCP. So, put filters in place that only allow necessary protocols to access the loop.
• What is the nature of the process? Is there ever any reason to write data to slave devices? Are there specific hours of operation? Specific times when lines are changed? Understand how the process should behave, so that you can block any commands that would make it behave differently. Again, using the right security controls can make this relatively simple.
Some basic controls such as intrusion prevention systems can be configured to block certain protocols outright (easy), or to block protocol traffic containing unknown or unauthorized function codes (harder). More specialized security controls, like Byres’ Tofino security appliances, make this easier by providing a degree of translation, allowing you to block “all write codes”, for example—a significant improvement over building specific function codes into the appropriate snort syntax. Others, like Secure Crossing’s Zenwall product, can take things even further and be told to learn a process, then whitelist that exact process to prevent all other behaviors.
Remember that this type of security control is much closer to the actual industrial process than what we think of as “SCADA,” or the supervisory elements. By being closer, it’s going to be better able to stop the cyber incidents that are attempting to sabotage a system. Industrial protocols, after all, are like pirates—they can be dangerous, and should never be trusted.
Related Reading: Are Industrial Control Systems Secure?
Related Reading: How to Make the Smart Grid Smarter than Cyber Attackers
Related Reading: The Increasing Importance of Securing The Smart Grid
Related Reading: Stuck on Stuxnet – Are Grid Providers Prepared for Future Assaults?
