Analytics

• Analytics
  • Visualizations
    • Trees
    • Connections Tree
      • Features
    • SSH Tree
    • RDP Tree
    • Troubleshooting
    • Trends
      • BACnet
      • Modbus
      • DNP3
    • Troubleshooting
  • Dashboards
    • IP Connections Tree Dashboard

The Analytics described here are developed by the internal Malcolm Analytics team to assist in highlighting aspects of a network. The purpose of this page is to explain aspects of visualizations or dashboards that may not be intuitive or that would benefit from more in-depth explanation of features.

All analytics are subject to overarching OpenSearch filters, including the Time Range filter and the search query bar.

Visualizations

• Trees
  • Connections Tree
  • SSH Tree
  • RDP Tree
• Trends
  • Bacnet
  • Modbus
  • DNP3

Trees

All Trees share similar functionality and features.

Connections Tree

The purpose of the Connections Tree visualization is to help identify potential avenues for lateral movement within a network, it allows you to visually focus in on Cyber Key Terrain (CKTs) and IP addresses that the user-defined root node communicates with.

Communications between nodes A → B → C implies that lateral movement could potentially happen from node A → C

In Connections Tree, the root node is only ever the source IP. In Connections Tree (Mirrored), the root node is only ever a destination IP. The dashboard displaying these visualizations side-by-side is named IP Connections Tree (see documentation below at Connections Tree Dashboard).

An example use case is if an Engineering Workstation of interest is identified, or an unknown device, entering the IP address as the root node will visualize observed communications between the source device of interest and any other devices/IP addresses.

Features

Example Image	Description
	Set the root IP address Change the Tree height/depth up to 15 levels Time Filter On only allows sequential connections to be displayed Node Color provides several color options in order to take pretty screenshots
	The Average Bytes transferred between nodes/devices are represented by a dotted link for communications transferring 0 bytes, and a solid line for communications transferring one or more bytes. The heavier the line, the greater the average number of bytes transferred between nodes/devices across all their communications. The line thicknesses are normalized; if a node is collapsed, all the other line thicknesses will be adjusted.
	Hovering over a Node provides additional enrichment. Some of this enrichment is provided by Netbox, and will not display unless Netbox enrichment is turned on and populated. IP address of the node/device Detected MAC address of the node/device (if available) Detected OUI of the node/device (if available) Netbox-enriched name of the node/device Netbox-enriched role of the node/device
	Hovering over a Link line provides additional enrichment. Some of this enrichment is provided by Netbox, and will not display unless Netbox enrichment is turned on and populated. Time of the first observed connection between the two nodes Netbox-enriched name of the source segment of the communication Netbox-enriched name of the destination segment of the communication Average bytes transferred during communications between the nodes/devices
	When hovering over a link, additional details will appear in the top right corner, detailing the following for each individual communication between the src-dst IP pair: The Connection State The number of bytes transferred The protocol(s) observed during the communication
	Other quality-of-life features include: You can collapse nodes to hide their communications by clicking on the node. Collapsed nodes are indicated by a dotted line encircling the node You can zoom in and out on the tree, and click and drag the tree around in order to get a better look at crowded communications Double-clicking in any blank space will reset the visual -- all nodes will be uncollapsed and the zoom will reset to default

SSH Tree

Protocol-specific Trees have the same visual features as Connections Tree (zoom, collapse, etc), but the enriched data is specific to SSH. This visualization is now located on the SSH dashboard.

Example Image	Description
	Hovering over a Node provides additional enrichment. Some of this enrichment is provided by Netbox, and will not display unless Netbox enrichment is turned on and populated. IP address of the node/device Detected MAC address of the node/device (if available) Detected OUI of the node/device (if available) Netbox-enriched name of the node/device Netbox-enriched role of the node/device
	Hovering over a Link line provides additional enrichment. Some of this enrichment is provided by Netbox, and will not display unless Netbox enrichment is turned on and populated. Time of the first observed connection between the two nodes Netbox-enriched name of the source segment of the communication Netbox-enriched name of the destination segment of the communication Average bytes transferred during communications between the nodes/devices
	When hovering over a link, additional details will appear in the top right corner, detailing the following for each individual SSH session between the src-dst IP pair: Whether the SSH session authenticated successfully How many authorization attempts were made The protocol(s) observed during the communication

RDP Tree

Protocol-specific Trees have the same visual features as Connections Tree (zoom, collapse, etc), but the enriched data is specific to RDP. This visualization is now located on the RDP dashboard.

Example Image	Description
	Hovering over a Node provides additional enrichment. Some of this enrichment is provided by Netbox, and will not display unless Netbox enrichment is turned on and populated. IP address of the node/device Netbox-enriched name of the node/device Netbox-enriched role of the node/device
	Hovering over a Link line provides additional enrichment. Some of this enrichment is provided by Netbox, and will not display unless Netbox enrichment is turned on and populated. Time of the first observed connection between the two nodes The most common result of the RDP connections The most commonly observed RDP session cookie The security protocol being used Netbox-enriched name of the source segment of the communication Netbox-enriched name of the destination segment of the communication The event ID of the first observed communication
	When hovering over a link, additional details will appear in the top right corner, detailing the following for each individual RDP session between the src-dst IP pair: The cookie for each individual RDP session The security protocol for the RDP session (if observed) The result of the RDP session

Troubleshooting

If an IP address does not exist in the data being examined, a message will appear above the "Root IP" input bar stating "IP address not found. Try adjusting the time range".

This message can also appear due to object number limitations. Vega and Opensearch limit loading ten thousand object into the Vega table. If the IP address for certain exists elsewhere and cannot be found in Trees, consider limiting the time range further or utilize Malcolm's filters and reload the analytic.

If the IP address was initially loaded into the Vega table but not all of its connections/connection IP addresses were loaded an error bar will appear at the top of the analytic, stating "Maximum data response reached. Data my be truncated. Try adjusting timeframe".

If you encounter a bug, please submit a bug report or an issue to the Malcolm repository.

Trends

Trends purpose is to standardize protocol behavior for analyst review. Analysts shouldn't necessarily have to understand what "normal" behavior looks like, or thoroughly understand the OT protocol, but given enough "normal" traffic, the analyst should be able to visually identify outlying traffic and can then take the data to an OT engineer to confirm whether the traffic is expected.

This analytic draws upon lessons learned from Stuxnet. The network traffic visualized on Trends should be unable to lie to an operator like an HMI may be able to.

The Trends graph plots the values for the PLc's addresses over time, as set by write functions for each of the covered OT protocols.

	Descriptor
Who	Devices leveraging protocol
What	Behaviors being invoked on the devices
When	Session/scope of the device behavior
Where	Logical address on device
How	Function invoking behavior

The "Trends" Analytics share many features, described below.

Protocol-agnostic features	Details
PLC Address	On the left side of the analytic are the PLC addresses observed for the selected IP address. Click on it to hide all other PL addresses on the analytic, and double click in an empty space.
IP Selection	All IP addresses identified to be either the src or dst of the OT protocol are in a selection box on the right side of the analytic. Click one to select it.
Hover over node	Hover over a node for protocol-specific enrichment. See the sections below to see lists of the enrichment/information for each protocol.
Overview Selection graph	The overview selection graph shows a scaled-down version of all the PLC addresses for the selected IP address, you can zoom in on the primary graph by dragging and clicking to select a section on the Overview Selection Graph. To reset the view, double click on and blank space in the Overview Selection.

BACnet

The BACnet Trends graph plots the write_property + present_value.

	BACnet-specific enrichment is available when you hover over the node. Dataset denotes which log The IP address/port of the communications Which PLC address is being observed The BACnet function The value being read/written/changed Date/Time of communication The Malcolm Event ID tied to this communication

Modbus

The Modbus Trends graph plots the write_single_coil, write_single_register, write_multiple_coils, and write_multiple_registers.

	Modbus-specific enrichment is available when you hover over the node. Dataset denotes which log the data is pulled from The IP address/port of the communications Unit ID associated with the communication Which PLC address is being observed The Modbus function The value being communicated Date/Time of communication The Malcolm Event ID tied to this communication
	If there is more than one modbus Unit ID available for the selected IP address, the Unit Selection box will appear below the IP Selection.
	Node shapes help differentiate between different Modbus functions at a glance. Square - Single Register Write Circle - Single Coil Write Diamond - Multi-Register Write Triangle - Multi-Coil Write

DNP3

The DNP3 Trends graph plots the OPERATE, DIRECT_OPERATE, RESPONSE, and SELECT function sets.

	DNP3-specific enrichment is available when you hover over the node. Dataset denotes which log this data node originates from The IP address/port of the communications Which PLC address is being observed The DNP3 function The Execute count The duration of the function in milliseconds Date/Time of communication The Malcolm Event ID tied to this communication
	Node shapes help differentiate between different DNP3 functions at a glance. Square - "OPERATE", "OPERATE:Pulse On", or "OPERATE:Pulse On:Trip" Circle - OPERATE: unknown function Diamond - "DIRECT_OPERATE:Latch On", "DIRECT_OPERATE_NR:Latch On", or "DIRECT_OPERATE:Pulse Off" Triangle - "RESPONSE:Latch On", "RESPONSE:Pulse On:Trip", or "RESPONSE:Pulse Off:Close" Upside-down Triangle - "SELECT:Latch On", "SELECT:Pulse On:Trip", or "SELECT:Pulse Off:Close" The size of the nodes also scale according to the execute_count

Troubleshooting

No known issues at this time. If you encounter a bug, please submit a bug report or an issue to the Malcolm repository.

Dashboards

• IP Connections Tree Dashboard

IP Connections Tree Dashboard

The IP Connections Tree dashboard's purpose is to help identify potential avenues for lateral movement within a network, it allowed you to visually focus in on Cyber Key Terrain (CKTs) and IP addresses that the user-defined root node communicates with.

The root node exhibits different behaviors in the two visuals. On the left, the root node is only ever the source of communications. On the right, the root node is only ever a destination for communications.

An example use case would be if a Engineering Workstation (EWS) was identified, inputting the IP address of the EWS in both the left and right visuals would allow an analyst to see what devices the EWS is communicating with, and what devices communicate with the EWS. Another devices of interest may include jump boxes, domain controllers, or PLCs.