Securing Industrial Protocols – It Can Be Done
Recently there was a thread on SCADASEC news, a restricted access critical infrastructure mailing list, about the challenges of firewalling BACnet networks. If you only work in the industrial automation space, you may not have heard of this protocol, but it is big in building automation. Regardless, the discussion around BACnet applies to many industrial protocols.
The question raised was whether or not BACnet traffic can be managed by a firewall. The problem is that BACnet, like many other automation protocols, doesn’t play by the usual IT rules. In BACnet’s case, it does not use TCP/IP at all, so trying to secure it with a typical IT firewall that looks for TCP port numbers is a lost cause.
BACnet is a non-TCP /IP protocol used in building automation systems that cannot be secured by typical IT firewalls. Image courtesy of Schneider Electric.
Furthermore, the point was raised that if a security device has the ability to secure BACnet, it would be so complicated that an industrial engineer could not manage it. And, if you get the IT “security guru” involved then you create a reliability nightmare. So SCADASEC contributors asked “Can a non-TCP/IP industrial network be realistically secured?”
Several people in the SCADASEC discussion independently brought forward that the Tofino Industrial Security Solution can secure BACnet and do it easily. It was nice to read how our products, which are part of Belden’s industrial networking solutions, can be used in ways we haven’t even tried yet. For example:
The SCADASEC thread on securing the BACnet indicates the Tofino Firewall does the job nicely. Thread presented here with permission.
Note that you can click on the image to make it bigger.
Which brings up an interesting point. How is it that engineers in the field know that Tofino can handle protocols that we don’t? The answer is that if you design a product to both meet the needs of a specific environment and yet be flexible, then the users will find all sorts of ingenious ways to use it that the designers never imagine.
It turns out that to really work on the plant floor (or building site), an industrial cyber security solution must be:
- Capable of reliably securing industrial protocols as they exist in the real world (not in an ideal world)
- Easily configurable by a controls technician, yet extensible to handle unusual situations
1. Designed for How Industrial Networks are used in the Real World
In order to protect manufacturing processes, an industrial firewall needs built-in smarts for understanding some unusual protocols. Industrial protocols emerged in the 1970’s and they were designed to provide data from PLCs, DCS and other devices to help monitor processes and make them as efficient as possible. They were not designed with security in mind. Nor were they designed to operate like IT networks. They had a job to do and the designers focused on making sure that the system worked “good enough” to safely make product.
The result wasn’t always pretty when looked at closely. It was not always to the letter of the specifications. Nor did these industrial protocols bother with a lot of the IT expectations of what a network should do. For example, who needs to manage wide area routing if your network is going to stay inside a building?
Thus extras like a TCP/IP layer got removed from industrial protocols like BACnet and GOOSE. And features like robust authentication were left out of nearly all the industrial protocols. After all, who would ever want to hack a control system?
Now twenty years later things have changed. Industrial networks do extend outside a single building. And (unfortunately) people do want to hack a control system and cause trouble. However the equipment and protocols have not. Modbus is still basically the same protocol it was when it was specified in the ‘70s. BACnet is much the same as it was in 1989.
This means that any industrial security system has to offer the flexibility to work with some unusual networks. The BACnet case is a perfect example.
2. SCADA Security that a Control Engineer can Configure
Industrial security needs to be simple in order to be effective. Highly complex and cumbersome configuration, as required by some IT firewalls just does not work in facilities staffed by engineers, technicians and maintenance people.
Using a product with a graphical interface, terminology and templates that make sense to them, control specialists can build traffic rules using terms and concepts that are familiar to them. For example, most engineers that use Rockwell control products do not have any idea what CIP objects and services are flowing over their network. The system just works.
They might not even know what TCP and UDP port numbers their PLC to HMI traffic uses. But they do know that they want EtherNet/IP messages to go from a PLC to an HMI so they can read a set of Analog Values.
So the answer is to have the firewall configuration displayed in terms that make sense to the engineer, not the creator of the protocols. Replace “TCP Port 44818” with “EtherNet/IP (CIP) Explicit Msg” in the software. Replace “CIP Object Class ID 0x28” with “Motor Data Object”. And replace a mess of different ODVA Services with “Read data”.
The Tofino Firewall makes it easy for controls engineers to configure rules that secure industrial protocols. Note that you can click on the image to make it bigger.
But even with the easiest to understand screens and wizards, mistakes can be made. So once rules are created, engineers can then safely try them out in “test mode”. This makes sure the rules are correct for the process without any risk of accidentally blocking communications that are critical to plant operation.
The Tofino Firewall also provides pre-defined templates for over 25 families of popular industrial controllers, including rule definitions to protect devices with known vulnerabilities.
In addition to pre-defined templates, Tofino Security firewalls can be extended using a Special Rules feature where rules can be developed and be applied to “unusual” protocols like BACnet.
Securing Industrial Protocols – It Can be Done
I hope this article gives you a sense of how current industrial security technology can truly secure manufacturing networks. If you want to read the SCADASEC thread yourself, register to become part of the mailing list and then go to its archives and search on BACnet.
If you have tips or remarks you would like to share regarding securing difficult industrial protocols, please let me know.
This article is a collaboration between Heather MacKenzie and Eric Byres.
Related Content to Download
White Paper - "Solving the SCADA/ICS Security Patch Problem" |
Related Links
- Webpage: SCADASEC Mailing List
- Blog: SCADA Security Basics: Why are PLCs so Insecure?
- Blog: S4 SCADA Security Symposium Takeaway: Time for a Revolution
- Blog: Securing SCADA systems from APTs like Flame and Stuxnet – Part 1
- Blog: Patching for SCADA and ICS Security: The Good, the Bad and the Ugly
- Blog: Securing SCADA Systems: Why Choose Compensating Controls?
- Webpage: Tofino Modbus TCP Enforcer LSM
- Webpage: Tofino Firewall LSM
- Webpage: Tofino Security Appliance
Comments
Miss the turn and opportunity
While the final display of the E/IP enforcer is nice, I feel since the article was on Non-IP protocols, it would have been more beneficial to show how the BACnet protocol would have been firewalled in the Tofino. That would have made for a much more fluid article and not a sharp right turn at the end to an IP based protocol. Thanks,
Good point - some non-IP examples to follow
Hi
You make a good point. The blog was talking about a non-IP protocol and then we switched to an IP-based example... bad us.
Since we don't have a lot of BACnet experience (which was one of the points Heather was making in the blog, namely we actually don't know all the applications for the Tofino that engineers dream up!), we will do a bit of research and publish a blog providing more details on firewalling non-IP protocols. Look for it sometime after the summer vacation season. Might be on BACnet or might be something like GOOSE.
Regards
Eric
My Thoughts on this
Hi Eric B. et al,
I agree with the first comment, and your answer. Even if it isn't necessarily a IN protocol example. One that comes to mind I have run into is IPX or AppleTalk get NetInfo. The exercise of identifying it and then either allowing it or Deny-No-Log would be beneficial to many. A special rule and a user entered rule solution. The concept would then apply to IN protocols. . IPX is easy to find in real life. Misconfigure one printer and everyone notices :)
Also, Your image spam filter below works a little too good.
Thanks
Eric P.
My thoughts
Hi
As I understand it, BACnet/IP is used over the vast majority of BACnet installations (ones that aren't using serial MS/TP anyway). Since BACnet/IP uses UDP for communication, I'm not sure how it would be difficult to firewall. UDP may not be ideal for a stateful firewall, but it would work just fine in a typical IT firewall. Of course, it would have the same issues as any UDP based protocol with spoofed source IP, etc, but these are problems faced everyday by enterprise IT staff.
If you're referring to BACnet over Ethernet, I've almost never seen that used in a production environment, almost all new installations prefer BACnet/IP.
Just my thoughts, thanks!
Eric
BACnet/IP vs. BACnet
Hi Eric F.
Being a process control guy and not a building automation guy, I really don't know how much BACnet/IP is used, or whether it is used in the majority of BACnet installations. If that is the case, you are right - most firewalls could handle BACnet over UDP.
That said, the blog was driven by a specific thread on the SCADAsec newsgroup where the writer was very clear - he had to secure non-IP BACnet and was struggling to determine the best way to do it.
What caught our attention was that it was a great example of the challenges of securing automation protocols in the real world. After three decades in automation/process/SCADA networking business, I am constantly surprised at the strange variations of "so called" standard protocols I discover "on the wire". Things get especially interesting when non-IP protocols show up. Eric P's example (see comments below) of IPX is a great one "Misconfigure one printer and everyone notices :)".
So if it turns out that non-IP BACnet is a rare bird, maybe a more widely applicable example of a non-IP protocol on the plant floor might be IXP. Another is Spanning Tree :-(. The power industries' GOOSE protocol is always fun, as are the older ABB and Siemens Ethernet protocols.
So if any one has ideas for some non-IP protocols we should feature in our Fall blog on securing non-IP protocols, send us your suggestions. We will do our best to figure out how to secure them.
Regards,
Eric
Add new comment