One of the most common questions I get asked while I am on a panel or after a conference presentation is on the topic of information technology/operational technology (IT/OT) convergence. A lot has been written on it, from how should we manage it, to how we can avoid it, to everything in between. One industry peer, upon seeing this article, will likely remind me (again) that even talking about it or giving it a label is dangerous. He would contend that IT is merely a supporting or tangential component of an otherwise purely engineering environment, and to suggest that IT should ever be involved in anything to do with how OT functions (read: engineering principles of temperature, pressure, etc.) is missing the point. However, I strongly believe IT/OT convergence is fundamentally required and needs to be embraced.
I have written on this topic before (as have many others), so if you are looking for my pitch to OT types, read this blog post. Or if you wish to learn about how you can get IT and OT to work together, read my colleague John Livingston’s article “Four key steps to help your organization achieve IT-OT convergence.”
Now, I am going to offer three day-to-day functions where IT/OT convergence — or, more appropriately, IT and OT working together — is not only better for risk reduction, but also required to achieve any modicum of success. The alternative is to have your offshore IT support inadvertently reboot a seemingly innocuous firewall that just happened to be shuttling critical safety information to an automatic shutdown command. Yes, it is 2021, and, yes, we still have these situations.
There are three obvious scenarios where IT/OT convergence is critical to success: vulnerability mapping/identification, patching (or not) and threat/incident detection.
Vulnerability mapping/identification for IT/OT convergence
It seems straightforward. We all want to know about the vulnerabilities that exist in our operational environment. While IT prefers to use scan-based tools, in OT, there are two very real restrictions on scans:
- They can knock fragile systems offline
- They don’t get data on embedded assets (relays, PLCs, etc.).
As such, we are not getting the full vulnerability picture, which means we are ill-equipped to protect ourselves. What we really need is OT-safe tools for vulnerability identification, which would mean IT needs to abandon their preferred method for an alternative one. This is not typically how things unfold. Nonetheless, this is where I share my mantra with IT: We will collectively get OT to where it needs to be security-wise, but we are going to take a different path and will likely need different tools. The reality is, we need IT to help us track, decipher and understand the risk once identified.
To patch or not to patch
Patching or, more likely, compensating controls (because patching is not always an option in OT) is where IT knowledge really benefits OT in risk reduction. When something like BlueKeep comes out (wide in scope, high risk, not a lot of time to test), the clock is ticking, and the stakes are high. Most OT types can and will likely patch some systems (e.g., those that are low impact, like DMZ-based domain controllers). But what about the crown jewels? Like the laboratory information management system (LIMS) server, the safety system, critical human machine interfaces (HMIs) or the Layer 2 file server with all our programmable logic controller (PLC) ladder logic copies and backups?
This is where IT and OT must work together, because if we cannot patch, we want to provide second or third line of defense protections like disabling a remote desktop. Without a thorough consultation between IT and OT — OT showing which systems need the patch, and IT helping to provide technical analysis and offering suggestions for Plan B or Plan C alternatives — we are left with either patching and crossing our fingers, or not patching at all. I don’t like the odds of either approach.
Threat/incident detection
Many companies have bought into the lofty promises of anomaly or threat detection tools to both inventory AND protect OT environments. Others are looking to get all OT data into existing (and capable) security operations center (SOC) instances. The challenge with either technology is that you are only as effective as the technician looking at the data. In both cases, you will absolutely need an OT review of what either technology might flag as problematic. Finding system-specific (read: proprietary OT behavior) indicators to ignore or escalate can only come from IT and OT actively working together on inbound data to properly tune your monitoring program.
To me it is clear: From initial discovery and identification, to proactive patching and risk reduction, through to live events, IT and OT need one another to be able to navigate their respective domains. Suggesting OT has the time or resources to duplicate IT skill sets in detail, or that an IT skill set can fully understand the nuances and fragilities of a complex OT environment, is inviting a major incident into your facility. To truly be successful, you must marry the two disciplines to foster collaboration in day-to-day management, maintenance and response activities. It is the fastest, most effective path to significant risk reduction and security maintenance in OT available to you.
– Verve Industrial is a CFE Media content partner.
Do you have experience and expertise with the topics mentioned in this article? You should consider contributing content to our CFE Media editorial team and getting the recognition you and your company deserve. Click here to start this process.
