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.
All Trees share similar functionality and features.
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.
| Example Image | Description |
|---|---|
 |
|
 |
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.
|
 |
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.
|
 |
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:
|
 |
Other quality-of-life features include:
|
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.
|
 |
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.
|
 |
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:
|
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.
|
 |
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.
|
  |
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:
|
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 addess 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 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. |
The BACnet Trends graph plots the write_property + present_value.
 |
BACnet-specific enrichment is available when you hover over the node.
|
|
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.
|
 |
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. |
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.
|
 |
Node shapes help differentiate between different DNP3 functions at a glance.
The size of the nodes also scale according to the execute_count |
No known issues at this time. If you encounter a bug, please submit a bug report or an issue to the Malcolm repository.
The IP Connections Tree dashboard's purpose is to help identify potential avenues for lateral movement within a network, it allowsd 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.