IT departments increasingly push the standardization and amalgamation of security tools, as well as services on scale (outsourced or automation). They work to extend this model further into the Operational Technology (OT) side of the house. On paper, this sounds like a good idea, but in practice it has some inherent dangers.
When IT has a budget and mandate, they typically turn to industry research tools like the Gartner magic quadrant. IT departments look to extend toolsets they are familiar with and can easily automate. Unfortunately, this overlooks what is really needed and security is unintentionally broken in the process.
Four Mistakes IT Departments Make When Selecting OT Security Tools
#1 Selection Process: Measuring OT tools with IT measuring sticks
Reputable analyst firms tend to rate products based on their own vision, market share, technical excellence, as measured by thousands of IT practitioners using these tools in homogenous IT environments. Those same IT tools have not had the same exposure or deployment in OT environments, so the accuracy of product coverage, stability, applicability, etc is inherently skewed to an IT perspective. Looking at IT tools that thrive in IT environments and have no comparative OT representation is not useful. Do not select OT cyber tools with IT measuring sticks.
#2 Standardizing Security Tools Falls Short When IT-Led
Using seven different cyber security tools for software patching or three different malware tools to manage protection, standardizing our tools is ideal. While I agree with standardization, the problem with this philosophy is with IT choose the tools in the first place.
Why not let OT pick a tool and have IT adopt it? If you are going out for dinner and one of you has allergies or doesn’t like Italian why would the one who will eat anything from anywhere be the one to pick the place? The person with the allergies would offer multiple options, and the second person would happily play along. Or, we let OT pick their own tool and we choose to support two tools where required.
#3 Asset Inclusion Differs Between IT and OT
The IT mantra requires OT to identify and exclude their assets by providing information, insight and even justification for why certain assets should not be included in certain IT practices such as scan-based tools. The challenge with this approach is many OT asset owners will either err on the side of caution and include wide swaths of assets to be excluded, or they will miss assets to be excluded and potentially take outages if those assets get knocked over.
This begs two questions: Why do we need to automate as opposed to staged testing and growth? If a tool is going to break things in the OT world, why are we using this tool in the first place?
#4 Cost of Ownership
The final mistake made in IT selecting tools, is that all the exceptions listed in the faulty mental model are still expected to be kept up to a certain minimum level of security controls. If IT uses invasive or non-friendly tools for OT, all exceptions in the OT world need manual intervention – or a second set of tools.
This makes it harder for the OT world to keep up. After all, we started this process with the notion of better security in OT, right? Expecting OT to keep asset patching and system hardening to a much higher standard while also having multiple assets excluded from the desired toolset means OT just got an even bigger task list than before this new OT security project started.
There are many exceptions to the observations in this article, but these are the most common, challenging topics observed in varying degrees from operating clients.
While IT departments don’t intend harm when working together with OT, it is often higher level decisions being forced down that provide the rank and give IT teams their marching orders. Until there is stronger insight at the top, OT teams will continue to struggle under these circumstances.