Image

Image

1. The Ostrich Algorithm
This is one of my favourite references from computer science. When I had to learn all about operating systems and schedulers, I always remembered this: “The ostrich algorithm is a strategy of ignoring potential problems on the basis that they may be exceedingly rare.”Image

2. A Central Firewall is Enough
There is a common misconception that having a single central firewall is all you really need. I have heard this many times, as well. In reality, it is never good to rely on a single point of failure, such as in a firewalling case. In fact, there is a reason that defense-in-depth has been a proven methodology for thousands of years. (I touched on defense in depth earlier.) Generally, if you have segmented your network in logical groupings of actions and protected each zone and conduit with a firewall, you could limit the impact of a potential issue and receive an alert pointing to where exactly the problem occurred. In the case of a single firewall, the network has no internal stop-gaps, which could allow a threat like malware to propagate easily. So, I have to discredit this argument.3. Security Certainty
“Oh, we have a firewall” or “That area is air-gapped.” That's all well and good… until they put an additional firewall in place and find out X IP address from network Y is sending multicast information that is somehow making its way across the air-gap. How can this be?!Image

4. Cost
I often think of selling firewalling products (like Tofino) as selling insurance. Insurance costs money, and in the lucky cases, you will never actually end up using it. If you did need insurance and you did not have it, you would most likely be kicking yourself that you did not have it. That's because most incidents will cost far more in the end than if you had insurance in the first place. I hear the cost argument a lot. The truth is in many companies, the security budget is minuscule, especially compared to the cost of the PLCs and HMI software, which is ironic because one would think that if the controllers are the most important element for reliability, then the budget to secure them should surely be more (utopia?). While the up-front cost may seem expensive, if something negative were to happen to a production network, the lost revenue (in most cases) would far exceed the initial cost of a firewalling device that could have prevented the downage in the first place.5. Ignorance
I do not mean this in a derogatory way. This is merely the sheer fact of “Where do I begin?” If you look at how many companies provide stateful firewalls, deep packet inspection firewalls, next-generation firewalls, anomaly detection firewalls, monitoring tools and change detection mechanisms, it can be a daunting task. Especially if you are the controls engineer who is an expert at controls but not a security or IT expert tasked with designing your security framework. As I mentioned above, you cannot just buy a device and BOOM, you are now secured. Job done. It has to be an iterative approach, one that takes a myriad of tools and processes to truly understand and secure your network. Coincidently (I swear), Belden does have this 1-2-3 approach of where to start to help guide a user or company along the path to securing their OT network.6. (Bonus) IT enforcement in an OT world
You have an IT expert attempting to apply IT paradigms to an OT network. “Let’s just reboot that switch!” As we all know, the IT world does not have the same stringent requirements of uptime that an OT network has. I have seen cases where the IT and OT people cannot even sit in the same room, let alone devise a security policy that fits nicely in the OT environment. This is a very real barrier… one that only a gradual convergence of IT and OT can solve.Image
