Today we announced an array of new data collection capabilities in our market-leading Claroty Platform, making it even more effective in protecting your OT environments from cyber-attacks, reducing your risk of plant downtime, and streamlining your SOC and other key security processes. We call this new capability “multispectral data acquisition” and it takes Claroty’s visibility into OT networks even further. Our visibility is now so extreme, to quote the famous mockumentary Spinal Tap, “it goes to 11”.
Some in the industry may question if this level of granular detail is really necessary for monitoring OT network assets. “Isn’t device name, net flow data and basic details like IP and MAC address, good enough?” The short answer is no; what may be “good enough” for basic IT and IoT networks is certainly not good enough to protect your most critical, revenue-producing infrastructure from the range of sophisticated cyber-attacks it now faces and I’ll explain why.
I’ve detailed our new multispectral capabilities below, but I think it’s important to first explain the “why” in order to fully understand the “what”.
When we refer to “extreme visibility” we’re talking about seeing all the assets in the OT environment, knowing what they are and what function they perform. Further it is about understanding granular configuration information for each asset, how the assets are communicating in the network and specific details about the application-level (layer 7) process automation “conversations”.
Extreme visibility is a foundational element for protecting critical industrial processes and it provides definitive business value. The difference between limited, not good enough visibility, and extreme visibility is stark, and it matters financially. In a nutshell, “extreme visibility” is about reducing risk and empowering individuals who manage and secure these critical networks and the operational personnel who manage and monitor industrial processes.
You may have heard the old security axiom “you can’t protect what you can’t see”, and it’s hard to argue with that. It also stands to reason that, beyond simply seeing OT network assets, the more you know and understand about them, the better equipped you are to detect and investigate suspicious behavior. Here are just a few examples of how extreme visibility translates into tangible risk reduction ROI and improved TCO:Reduced plant/operations downtime:
Specifically, we’ve made our existing Active (query-based) data collection capability generally available. We have also released App DB collection, a rich new capability which enables our system to automatically ingest and parse data from the configuration files that automaton and other 3rd party applications generate as OT systems are modified. Multispectral combines the power of Passive, Active and App DB acquisition into one integrated platform. These new capabilities deliver on Claroty’s promise of providing our customers with the best visibility possible into industrial control networks and maintains Claroty’s industry-leading track record of innovation.
With the latest release, the Claroty Platform and our Continuous Threat Detection product now support the following:
Passive: Continuous, real-time monitoring of OT Networks
That’s right, but it is not entirely correct. First, we continue to believe passive detection is the best starting-point for most industrial environments. Second, while we are making our active capability “generally available” today, the truth is, Claroty has had active data collection in production environments for more than two years. It’s true! Let that sink in as we let a wry, Cheshire cat-like grin escape for a moment. Multiple large refinery customers, and a few other industrial plants, have had our active, query-based asset data collection capabilities in production for quite some time. We’ve been keeping this on the down-low, but there is a good reason–safety!
“So, why did you wait so long to release your active capabilities,” you ask?
When we started our journey into ICS cybersecurity, design goal number one was the ICS version of the “Hippocratic Oath”; that is, “first, do no harm to the operational environment”. By the way, design goal number two was “see design goal number one”, and we moved on from there.
Our team is a collection of OT and cybersecurity professionals, and we knew if cybersecurity products continued to break things and cause plant downtime in OT environments–as was often the case when trying to use IT-oriented security technologies in an ICS network–we would never be able to convince industrial asset owners and operators to let us help them protect these critical systems. We’d watched this play out too often in the past and decided to go “all in” on passive monitoring–an approach we knew would absolutely “do no harm”. It’s important to note also, this echo’s what we heard from the market; most enterprises flat out refused to bring active scanning into their industrial environment.
So, we invested very heavily in our passive technology and went wider and deeper than anyone else in the industry. And we proved it in numerous customer POCs, very thorough competitive evaluations from the likes of Rockwell Automation, Schneider Electric, Siemens and Belden/Tripwire. We proved it again in a public forum by winning the S4 ICS Detection Challenge earlier this year (read about it here). As you can tell, we are more than a little bit proud of our industry-leading passive technology.
However, there is important data that passive collection does not have access to, and some use cases where approaches other than passive were simply necessary. The question for us has always been, “how can we safely implement active?”, and what other safe data collection techniques can we leverage to provide the richest possible collection of information from an ICS environment. After working in true production environments, collaborating with automation asset owners and vendors, we’ve crossed that bridge and now have the safety features we needed to comfortably take the next step and make our active capability generally available.
There are two primary ways in which traditional active collection can cause harm in OT networks. First, queries across an overly broad address range with many endpoints, or multiple concurrent queries, can end up saturating the often modest “small pipes” that make up many industrial networks. Further, even if the scan does not fully saturate the network it can still impact the legitimate OT traffic on the network as these industrial automation systems often have tight tolerances and expect that various communications between assets will be acknowledged and answered within certain time-frames.
Second, sending the incorrect type of query to a particular OT device–such as a PLC or RTU for example–can cause the device to shut down or stop communicating. Windows and Linux endpoints, as well as many modern controllers, are capable of responding to WMI or SNMP queries without issue. And while older controllers and other OT devices can respond to the correct queries in their native protocol, if these older devices are incorrectly asked to respond to a query from a non-supported OT or IT protocol, they can fail in unexpected ways.
Thus, in order to practice “safe active” the system needs to take these factors into account. We invested the time and worked with customers and our automation vendor partners to design safety features into our system. To avoid the saturation issue, the system has the ability to rate limit the number of concurrent queries, plus other methods detailed below to keep the network load within the appropriate boundaries.
For the incorrect protocol issue, we employ a combined passive/active approach. The system leverages passive collection to understand which endpoints are running which protocols, and which firmware versions are present, and then sends the appropriate “safe” query. This passive/active approach is particularly important for older ICS devices.
Claroty’s passive capability provides a rather impressive, and often startling, array of data about the assets on an ICS network, and for many environments, this level of detail is adequate. But some use cases need more lower-level detail, and this type of passive scanning can’t discover everything. Passive techniques are not able to yield some endpoint configuration data–which patch level a Windows or Linux machine is running, which software packages are installed on these nodes, or the version of virus definition files, for example.
There are also instances where devices don’t communicate on the network, or communicate very infrequently, so passive is not able to capture data about these nodes. And in a few situations, we simply don’t have access to devices– for example, because they are on a different network segment or because the customer has an unmanaged switch without SPAN or mirror capabilities. In these cases, the use of multispectral data collection can serve to enrich our already robust data-set and better inform these important use cases.
Lastly, and very importantly, some plants or operational environments simply cannot easily, or cost effectively, deploy passive DPI. For instance, some plants don’t yet have modern switching infrastructure that supports SPAN/Mirror. And even in plants that do, internal change management processes add substantial time constraints. In these cases Active and App DB may prove to be more cost effective or substantially reduce the time to deploy.
While this announcement, coming from Claroty, may come as a bit of a surprise to the industry, it is not at all surprising to us or a few select customers. We have always intended to provide the most “extreme visibility” into ICS environments so that we can significantly mitigate the risk of attacks and the cost of plant downtime. But we also were keenly aware of our oath to “do no harm”. We believe our latest release makes good on both promises and sets a new high-water mark for the industry.