Blog
Independent
Security Engineer
Those who need to monitor and defend operational technology (OT) need to understand what is on their network. It doesn’t matter whether we’re talking about generating electricity or providing working elevators in an office building, knowing what systems we are dealing with is essential for security and operational continuity.
In this blog post we’re going to dive into how to get asset information out of an OT network protocol using open-source tools.
Asset Identification In a Nutshell
Asset identification means learning as much about a given device on the network as possible. These are facts like the device vendor, series, model and even serial number, as well as configuration details like firmware or program version number.
Other information like physical locations, or organizational ownership are also useful. From these concrete facts we can infer attributes such as the asset’s role, such as a human machine interface (HMI). This kind of information is critical for situational awareness and feeds into activities such as threat modeling.
Depending on the approach, a user might have low, moderate or high confidence in what we know about an asset.
Asset identification often starts with something simple like passive operating system fingerprinting or identifying a network card vendor from the Organizationally Unique Identifier (OUI) in the MAC address. This kind of high-level information is relatively easy to discover, although it doesn’t provide many details.
Traditional IT protocols can provide valuable information about both IT and OT devices in the environment. For instance, Simple Network Management Protocol (SNMP) allows administrators to query devices to retrieve identifying information.
SNMP is largely used by IT networking equipment (e.g., routers, switches), but is also found in some OT products. Likewise, link layer (OSI model level 2) discovery protocols such as the Cisco Discovery Protocol (CDP) or the vendor agnostic Link Layer Discovery Protocol (LLDP) let devices advertise their capabilities to neighbors within their immediate network.
As before, these protocols are usually found on IT assets, but in some cases they manifest on OT devices as well. For example, PROFINET devices are required to support LLDP. Other application-layer (OSI level 7) protocols can provide asset ID information based on things like SSH banners or HTTP headers, but these often require specific work on given devices to parse the information and make it usable.
Moving away from the IT side of the house, OT protocols can also provide a wealth of identifying information to the savvy observer. At a high level, knowing what protocols a device is using can give us hints about what it might be doing.
For example, a device using the BACnet protocol is likely performing a building automation task of some kind, or a proprietary vendor protocol like Siemens S7 will at least point us to the product vendor.
OT protocols can also provide more detailed information. For instance, protocols such as Modbus, BACnet and DNP3 provide mechanisms for an operator to query details like device vendor and model.
Diving Deeper: Asset Details in BACnet
As promised, let’s dive into how to extract asset identification information from an OT protocol using open-source tools.
BACnet is a building automation and control protocol. It is used to run everything from Heating, Ventilation and Air Conditioning (HVAC) systems, to lighting controls and elevators. We don’t have time to cover every single way asset information can be extracted from BACnet, but we can talk about the biggest one: the BACnet Device object.
The BACnet protocol uses the concept of objects as a means to encapsulate and organize information. Each object is made of properties, or fields, that contain information relevant to the object. The Device object represents the physical BACnet device, often a controller of some kind. The Device object properties contain device specific information about the device (see table below).
These device properties can be read with a ReadProperty Request, to which the device will respond with a ReadProperty Response. This requires a user or device to issue the ReadProperty Request in the first place, and they may not be common in the environment after installation occurs. Passive monitoring is preferable in OT environments, but getting this asset information may require action by an operator or network scanning tools.
For open protocols this kind of information can be extracted from the protocol specification. In our case BACnet is specified in the ASHRAE 135-2020 standard. Open-source parsers, which we’ll talk more about shortly, are also an excellent source of information. These two sources work hand in hand.
The specification gives us the “theory”, how the protocol should act, while the parser provides an implementation that is (ideally) tested against actual data. Taken together they provide valuable insights into how the protocol works.
Selected BACnet Device Object Properties
Using Open-Source Tools to Extract Asset Information
With some knowledge about how the protocol operates we can dive into manual network analysis to begin working through an example.
The screenshot below shows the Wireshark view of an example network capture.
The selected packet shows a ReadProperty Response with the device’s model name, in this case BEC-985. Because BACnet uses arrays to encapsulate information Wireshark shows array items such as “{[3]” in the detailed packet view, but they are an encoding detail.
Other packets show information like the firmware revision:
Or the user defined location of the device, assuming it has been set on install or by an administrator:
Wireshark is a wonderful tool for manual analysis, but no one has time to look at hundreds or thousands of devices manually. The command line version of the tool, TShark, can be used for more automated analysis. It can be executed programmatically from a script by executing a manual subprocess or using a language specific interface such as Python’s pyshark.
For those who want more turn-key automation, need to capture at higher network speeds, or require other features (e.g., file extraction or complex alerting logic) Zeek is another valuable open-source monitoring tool to keep in the metaphorical toolbox. It does not have nearly as many protocol parsers as Wireshark, but it ships with several ICS protocol parsers by default. Although it does not parse BACnet out of the box, the US Cybersecuirty and Infrastructure Security Agency (CISA) has created a number of third-party packages for additional ICS protocols, including BACnet.
We installed the plugin using Zeek’s package manager, following the instructions in the parser’s readme. From there we can use Zeek from the command line to read our example pcap, tell it to output the logs in JSON format (rather than the default tab delimited format), and load the parser we just installed:
zeek -C -r ./bacnet_example.pcap LogAscii::use_json=T icsnpp/bacnet
As documented in the readme, the Zeek parser produces several log files based on BACnet traffic. For our purposes today we’re interested in the bacnet_property.log. It contains the read property requests along with the responses that contain the information we’re interested in.
We can extract the log line with the device model, showing the same information we got earlier from Wireshark:
{
“destination_h”: “172.20.32.200”,
“destination_p”: 47808,
“id.orig_h”: “172.20.32.200”,
“id.orig_p”: 47808,
“id.resp_h”: “172.20.32.122”,
“id.resp_p”: 47808,
“instance_number”: 652,
“invoke_id”: 82,
“is_orig”: false,
“object_type”: “device”,
“pdu_service”: “read-property-ack”,
“property”: “model-name”,
“source_h”: “172.20.32.122”,
“source_p”: 47808,
“ts”: 1580238031.43028,
“uid”: “CNrNBq282UyTJcieYk”,
“value”: “BEC-985”
}
The log contains some Zeek-specific fields that are beyond the scope of this blog post, but the ones that are germane to our discussion are the property “model-name” and the value “BEC-985”. This is the same data from our first Wireshark screenshot.
Caveats Abound
There are a few other details we should cover when discussing how to extract network information from these tools.
Firstly, network analysis tools including Wireshark and Zeek, are implementations of a network protocol standard that vendors implement.
Although the device object we looked at is straightforward, vendors can and do violate protocol specifications in fun and exciting ways.
In Zeek, these kinds of oddities manifest in the Weird log when protocol parsers have defined what is “weird.” The log isn’t well populated for OT protocols, but underlying protocols such as TCP and UDP will show up there.
More importantly though, network parsers may only implement certain portions of a protocol. As an example, BACnet has a concept of segmentation at the application level. It is used to split a message across multiple UDP segments in the event a message is too large for underlying network devices.
A simple parser may not appropriately buffer and reconstruct segments and therefore would not correctly handle these segmented messages. Although that’s not a problem with Wireshark or Zeek in this case, it requires the user to understand the limitations of the tools they’re using.
Beyond the complexities of protocol reconstruction, how the information is encoded in the protocol may vary. Our examples focused on a simple ReadProperty Request and ReadProperty Response.
In BACnet, the ReadPropertyMultiple and ReadRange commands can be used to read many properties with a single request and response. Users should ensure that parsers can support commands like these, along with knowing how the output will vary with these commands.
This was a deep dive into just one facet of BACnet asset identification in BACnet. Digging into the weeds on a protocol to pull out such information can be extremely beneficial to asset owners and operators.
However, it usually requires some research that takes effort to scale across the many, many OT-specific protocols found in use across and within an industry. Now get out there and identify some assets!
Interested in accessing asset information automatically? SynSaber’s software-based sensors (Sabers) automatically process packet capture data to extract asset data from a variety of sources, including OT protocols.
Become a Subscriber
SYNSABER WILL NEVER SELL, RENT, LOAN, OR DISTRIBUTE YOUR EMAIL ADDRESS TO ANY THIRD PARTY. THAT’S JUST PLAIN RUDE.
