The big OT asset visibility misconception

You have heard it a dozen times: You cannot protect what you don’t see. You need asset visibility! Based on this trivial insight, OT security vendors usually explain how you can achieve such visibility with their products.

Let’s check what that actually means in concrete terms. Most of the time it means: IP addresses, vendor names, perhaps a firmware version and the device type.

Which takes us directly to the big misconception.

The basic technical details about your OT devices, the low hanging fruit that you can pick up using passive sniffing, yields next to nothing.

It doesn’t result in a useful OT asset inventory.

For starters, you must be able to establish network identity, as a prerequisite for establishing device identity. Guess what, the typical manufacturing operation has a dozen or more devices with an IP address of 192.168.0.5 (substitute your favorite IP address from a private network). If you cannot tell if that endpoint .5 belongs to the network in machine line 3, or to that HVAC network in building C, it’s useless. It’s not asset visibility, it’s asset fog. You see something, but you don’t see exactly what it is. It’s not actionable.

This brings us to the next insight, which will shock you:

You will never arrive at a useful OT asset inventory without manual augmentations of basic technical asset properties.

That’s not unique for OT security products. It applies as well to the OTbase OT asset management software. As detailed and accurate OTbase’s automatic discovery is, it still isn’t enough for doing anything useful with it. Users still need to provide context data to pull OT asset management off the ground, and this step cannot be automated.

Going back to basics, how can OTbase know which network the endpoint with address 192.168.0.5 belongs to, given that you have a dozen 192.168.0.0/24 networks? By informing OTbase about the physical location of those networks. Once that it knows the location of each network, it knows how to separate the endpoints in the global asset inventory. As a result, the user can easily see that this particular device with 192.168.0.5 is in the network of machine line 3, for example. So by this simple trick we can now establish both network identity and device identity.

Now that we have the capability to collect and store geolocation data, this can easily be extended and further put to good use. OTbase users can slap a geolocation tag onto individual devices, to indicate that these devices are located in a particular control system cabinet, for example. The location of that cabinet, or room, or whatever, can easily be visualized in interactive floor maps. It literally takes about ten minutes, and it’s going to enhance usability for years to come.

Getting back to networks, OTbase also invites users to qualify networks. Different from IT, OT networks often have very distinct characteristics. Think about safety networks, which is dedicated networks where some or all endpoints have a safety function. Or I/O networks with their specific bandwidth and latency requirements. You want to make sure that extra scrutiny is exercised for such networks. In OTbase, they can be identified easily by using network group assignments that include different color codes.

Taking it a bit further, one of the most important context items is the process function of an OT device, which is often related to its system association. Different from IT devices, one cannot easily guess the function of a given PLC, or even printer. If I know that this PLC is part of machine line 3, that information goes a long way, no matter if I’m interested in a cyber security angle, or maintenance, or system retrofit. But that detail cannot be guessed; it must be explicitly provided by an SME.

Equipped with this information, which remains valid usually for ten to twenty years until the machine line gets decommissioned, we can better address various use cases from cyber security to maintenance. For example, an SME can qualify a particular machine line (or pant component, for that matter) as critical, which is an important attribute when it comes to OT security – critical components deserve better protection than others. OTbase will automatically inherit the system’s criticality attribute for all the devices associated with that system, and factor it into automatic risk computations.

These are just simple examples to show how metadata augmentation goes a long way when it comes to actually getting value from an OT asset inventory. Other examples include adding file attachments to device profiles, such as backup images, technical manuals etc. Or using custom database fields to put all existing device data that was stored elsewhere in OTbase, to have everything in one global platform that also acts as supercharged OT documentation. Quite a feat when you have to worry about knowledge capture from senior engineers who are about to retire. The bottom line is this:

The OTbase OT asset management software provides a platform that allows users to easily augment automatically discovered technical asset data with SME metadata that ties the asset data to use cases. It turns visibility into knowledge.

To learn more about OTbase please check our web site at https://langner.com.