Since around 2016 there has been a term thrown around in the OT cybersecurity world that is a classic case of marketing naming a segment well.
I am of course talking about passive monitoring. This started out with admirable goals to add visibility into the cybersecurity of OT networks. It evolved from the early days of OT protocol firewalls and OT aware signature-based network intrusion detection. This technology has been a driving factor behind the explosion of the OT security market, which is set to surpass $12 billion by 2026. In full disclosure, it is available in our solution, and in the opinion of this author, an invaluable piece of the modern cybersecurity toolkit.
But what is passive monitoring really? Because that’s a non-descriptive marketing term. It has all the feel of cookies, cozy blankets and a roaring fire in a remote log cabin. It is soothing wellness yoga in a world full of Fear, Uncertainty and Doubt (FUD). What it really is, and I how I refer to it for the rest of the article is network protocol analysis. This is the term MITRE uses when describing it as data source tool for discovery of techniques. More Cylon or Dalek sounding, and less stuffed teddy bear. It’s also way harder to say it three times fast, which is a requirement for any word or phrase a sales engineer says.
Network protocol analysis was rebranded because OT engineers for years suffered outages from well-meaning, if ill-informed, IT security staff performing “ACTIVE network scans”. I did it, way back in the early days of Network Security Scanner and free Nessus. I ran my first wide-open Nessus scan, and promptly sent the audit department’s printer off-line. It ended up requiring a full power cycle to recover and left more than few of my co-workers irritated at having to re-run print jobs. Now do that at a power plant or chemical factory, and you see why OT engineers are a bit nervous about anything cybersecurity-related coming through their doors. So, to make everyone feel a lot better with what was happening, the early purveyors of this technology called it “passive” in one of the most brilliant marketing moves since Leonardo DiCaprio was cast in Titanic.
So why am I so bent out of shape about this? Why does this require a blog? Because “Passive Monitoring” is not so passive in a lot of cases, especially as its evolved from its original intent and morphed into “ASSET VISIBILITY” (deep voice in an echoing canyon implied.)
To make this point we need to understand exactly how network protocol analysis even works. Essentially you make a copy of all the network traffic flowing in your OT environment, and then you tear it apart into bits and pieces and try to decode information from it. A lot of that data is really useful to know.
In the early OT network protocol analysis days, everyone focused on some giant industry standards, like Modbus, DNP3, EthernetIP, etc. These have open published specs which allow developers to quickly build some relatively insightful analysis. Sometimes it is about events and actions, like blocks of codes on a PLC being updated, or someone told the device to reset itself. Sometimes it is about the device itself. Some protocols are really good about telling everyone everything about themselves, like a 10 year old on social media. This is great data, and it has significant value to operators who often view the control system delivered to them as a black box with some levers and dials they use to perform a limited set of actions. Now they could see what really was happening when they pushed that button on the HMI screen.
These early implementations were simple, and cast light into some dark shadowy areas. Like a candle in a pitch-black room, you could get a lot from a little. These early solutions used one or two sensors, and they were put where it was convenient and whatever they discovered was usually pretty insightful. There were no expectations and promise of 100% coverage.
The problem was, it was too good at its job and a lot of little companies jumped on this technology and started to press it for more and more use cases. To the point where now people are saying you can run an entire security program or solve all your compliance problems with it.
Now this is where our nice, helpful, insightful little tool, network protocol analysis, starts to evolve and becomes more intrusive.
I do say. Why? Because people were told that only passive was safe in an OT environment, but now it is being asked to push the boundaries of what makes sense. Let us take a look at a few scenarios related to the number one purchase driver for these solutions.
This use case is described as the ability to identify an asset as it appears on the network. There are four major reasons why asset visibility alone sheds light on some of issues with pushing network protocol analysis too far.
As you can see, when you push any great tool beyond its design limitations you start to make compromises, and if you’re not willing to compromise on which tool to use, then you will make other, less favorable compromises to your budgets and overall security.
It’s time to change our language. Passive is not precise language. Network protocol analysis is a must-have tool in any OT security and compliance toolbox, but it cannot be your only one. “Active” methods are not the evil they are portrayed as. They can bring deep, rich insights that are simply not achievable with network protocol analysis. You cannot do file integrity monitoring or removable media detection with network protocol analysis, but the MITRE ATT&CK for ICS Matrix lists both of those critical capabilities, early on in the kill chain. Heck, you cannot even do simple software vulnerability analysis on anything with an operating system instead of firmware.
To be very clear you will never see me advocate for nmap or a broad spectrum vulnerability scan in a production network, but that doesn’t mean we should throw the cheese sauce out with the broccoli. Select the right tool for the right job, and you will go from compromising to thriving.
To understand what a more comprehensive approach to detecting anomalous network and device activity might look like, check out our MITRE ATT&CK for ICS infographic.
