IT departments are increasingly pushing the standardization (and amalgamation) of security tools and are also pushing services on scale - (outsourced or automation). And lately they are working to extend this model further into the OT side of the house. On paper this sounds like a good idea but in practice it has some inherent dangers.
IT has the budget and the mandate - so they do what they know how to do - they turn to industry research tools like the Gartner magic quadrant, they look to extend toolsets they already know, they look to automate and, unfortunately, the overlook what is really needed and they break things in the process.
Why is this happening? There are 4 mistakes I am seeing occurring.
First - the selection process - Gartner and other ranking/reputation tools like it rate products on their vision, market share, technical excellence, as measured by thousands of IT practitioners using these tools in homogenous IT environments. Those same tools have not had anywhere near the exposure or deployment in OT environments so the accuracy of product coverage, stability, applicability, etc is inherently skewed to an IT perspective. So right out of the gate we are looking at IT tools that thrive in IT environments and have no comparative OT representation! And this is how we pick OT tools? With IT measuring sticks?
Second, because nobody wants 7 different tools for patching or 3 or 4 different malware tools to manage we want to standardize on our Gartner endorsed tools. I agree wholeheartedly and support this idea (the part about standardization, obviously!) The problem with this philosophy is that IT is the one who chose the tools in the first place. Why not let OT pick a tool and have IT adopt it? I mean 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 usually offer 2 or 3 or 4 options and the second person would happily play along. Or, we let OT pick their own tool and we choose to support 2 tools where required.
Third - a faulty mental model. The IT mantra in many cases seems to be to require 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 that 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. My question is two-fold - a) why do we need so badly to automate as opposed to staged testing and growth and b) if a tool is going to break things in the OT world why are we using this tool in the first place? If OT got to pick the tools….
Fourth - Cost of Ownership. The last thing not really picked up on (or at least, if it is understood it has little sway in decision making) 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 now need manual (or a second set of tools) intervention. Thus making the OT world harder to keep up. After all, we started this process with the notion of better security in OT right? So expecting OT to keep asset patching and system hardening to a much higher standard and 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!
I know there are many exceptions to the observations in this article. What I have extracted above are some of the more challenging topics I have seen at work in varying degrees in a number of operating clients. And while all IT people I deal with don’t want to do harm and do want to work together with OT, it is often higher level decisions that are being forced down that provide the rank and file IT team their marching orders. Until we can get better insight at the higher levels of these initiatives the OT teams will continue to struggle under these circumstances. And while I point a lot at the IT types who are causing havoc, I have to admit - at least IT has a plan!
Want to continue this conversation? Reach out to me or comment on our article. Stay tuned! firstname.lastname@example.org