Introdution: Why Protocol Support Matters¶
Operation Technology networks are built around specialized protocols. They are not standard IT protocols like HTTP or DNS. Instead, they are things like Modbus, Profinet, DNP3, and many many more. Many of these protocols were designed 10+, 20+ years ago, in a time where there wasn't much consideration or need for security. These protocols run critical infrastructure, carry sensitive control industructions, all while often being unencrypted and unauthenticated. If an actor with malicious intent were to gain access to this environment, serious things can go wrong.
Using Malcolm, analists can gain insight into what exactly is happening in their network, in this case more specifically, Industrial Environments. But if Malcolm is used in an OT environment, the first question is whether Malcolm actually understands the protocols OT environments use. The research on this page aims to answer that question.
Overview of Protocols in OT Environments¶
OT environments are different from IT environments. Where in IT environments emails and web traffic are being moved around, in OT physical machines are being controlled, sensor data is being monitored, and real-time decisions are made in all kinds of OT environments like (but are not limited to) factories, water plants, and energy grids. Because of these specialized actions, OT networks use specialized communication protocols, many of which are foreign to IT tools and monitoring systems.
To figure out what protocols Malcolm needs to support to stay viable for this project, first the types of communication that happen within an OT network need to be understood.
Level 1: Information Network¶
This level is responsible for the exchange of data and information across different systems and devices within an OT environment. It enabled Data analysis, decision-making, and overall management. Common information network protocols are the following:
| Protocol | Description |
|---|---|
| Ethernet/IP | High-speed plant communication |
| Profinet | Real-time data exchange, IT-OT integration |
| Modbus TCP | Ethernet-based Modbus variant |
| OPC UA | Secure industrial data exchange between OT and IT |
Level 2: Control Network¶
This network level is primarily concerned with the control and monitoring of industrial processes. It ensures that the data collected from various devices and sensors is relayed to the control systems, like PLCs, DCS, and SCADA, for decision-making and process control. Some control network protocols are the following:
| Protocol | Description |
|---|---|
| Modbus RTU | Serial communication for low-level devices |
| Profibus | Fast and reliable fieldbus communication |
| DNP3 | SCADA and RTU communication in utilities |
| BACnet | Building automation (HVAC, lighting, etc.) |
Level 3: Device Network¶
This is the lowest level, where communication happens directly to sensors, valves, actuators, motors, etc. These protocols are serial-based, and designed for speed and reliability over complexity. Examples:
| Protocol | Description |
|---|---|
| DeviceNet | Factory floor communication protocol |
| CAN | Automotive/embedded control networks |
| HART | Smart device communication over analog lines |
| Fieldbus | Real-time distributed device communication |
In addition to these commonly used protocols, there are loads of protocols which are used for very specific things, that are still in use in a lot of critical industries.
What Protocols Are Needed for OT Monitoring¶
Not all protocols in an OT network need monitoring. For example, monitoring low-level sensor feedback or analog signals add little to no value to security. But for others that carry command and control instructions, authentication data, or high level coordination between machines or operations, are very important to monitor, and are the most prone to attacks because of their functions and responsibilities.
Criteria for Security-Relevant Protocols
A protocol is considered necessary to monitor if it meets any of the following conditions:
-
It's used for control
-
It's used for coordination
-
It's a common attack vector
-
It's foundational
Selected Protocols That Need To Be Supported¶
| Protocol | Why it matters |
|---|---|
| Modbus (TCP/RTU) | Old but still widespread. Used for direct control and sensor feedback. |
| DNP3 | Backbone of utility SCADA. Carries control and telemetry. Secure mode optional. |
| OPC UA | Key IT-OT integration protocol. Complex, but high-value visibility. |
| S7comm (Siemens) | Common in European manufacturing. High-value target for attacks. |
| Profinet | Used in real-time automation. Often invisible to traditional tools. |
| EtherNet/IP (CIP) | Dominant in Allen-Bradley ecosystems. Control protocol. |
| BACnet | Widely deployed in building automation. Lacks built-in security. |
| MQTT | Lightweight protocol for IIoT telemetry. Not always encrypted or authenticated. |
| FINS | Omron PLC control protocol. Often overlooked. |
| GE SRTP | Used in legacy GE installations. Proprietary, but still active. |
This is a relatively small list. It doesn't include a lot of protocols which are still widely used, but it still includes protocols where lack of support for them would mean that Malcolm would not be able to be used on a large scale, as these protocols are very widely and very commonly used.
What Protocols Malcolm Supports¶
Since Malcolm is a stack of components, when evaluating protocol support, it is important to know which part of the stack actually has to interpret traffic.
Malcolm uses Zeek, Suricata and Arkime for interpreting traffic. Zeek is responsible for deep protocol parsing. Suricata handles threat detection based on traffic signatures. Arkime is focused on storing and indexing traffic metadata and PCAPs. This division of responsibilities means that protocol support depends more on Zeek than on Suricata and Arkime.
The reason protocol support depends more on Zeek¶
Arkime only extracts basic metadata from PCAPs (source/destination IPs, ports, transport protocols, etc.), but it does not provide deep protocol parsing/dissection. Instead, Malcolm uses Zeek to interpret complex application-layer protocols. Malcolm uses Arkime primarily for PCAP storage, fast session indexing, and its rich search capabilities. Arkime acts as the high-performance session indexing and search engine for both PCAPs and Zeek logs in Malcolm. Arkime's role is thus to organize, search, correlate, and visualize both Zeek-generated metadata and native PCAP session data.
Zeek and Arkime cannot do malware detection, which is why suricata is necessary. but suricata cannot read most protocols, so it cannot parse those protocols to read the data to see if its malicious. The problem is that Suricata is not optimal for malware detection in OT environments, since it does not support most common OT protocols. The thing is that Malcolm was not designed to be used in OT environments, even tho the devs said thats what they were trying to aim towards, for malcolm to be a cheap solution for OT environments instead of those expensive licenses.
"Malcolm captures traffic at the Ethernet link layer: it's focus is primarily in IP network traffic. "Malcolm does not have built-in support for capture and dissection of serial-only protocols". Malcolm is optimized for IP-based Ethernet traffic, which is where Suricata works at its best. Malcolm doesnt use suricata for deep OT protocol parsing, but instead uses it to for general-purpose network threats, where it can detect malware over HTTP/S, DNS, FTP, SSH, etc., detect malicious activity on the IT side of OT environments, like engineering laptops, remote access tools, internet-exposed assets, etc.. It adds value without touching the serial-only protocols, by aiding in security on the IT side of OT environments.
Adding support for these protocols for Suricata has 2 very big downsides and wouldnt work anyways. so adding support for these protocols in suricata is a massive undertaking. Youd have to build full protocol dissectors for the most common protocols. Even building ONE is so much work. Then, Even if you HAVE done that and can parse those protocols into suricata, suricata doesnt have malicious signatures for these protocols like it does for HTTP and DNS, since Suricata just wasnt built for Malware Detection in OT Protocols. Lastly, OT malware doesn't really follow signatures. It can just look like normal data, but have malicious intent. Creating signatures for this kind of data is just almost not possible. This is why using Zeek, which first of all can actually parse and read these protocols, is way better for monitoring for malicious intent in the data of these protocols because it can detect anomalous behavior. If a machine usually always ticks 3 times per second, but then very suddenly it has to tick 30 times a second, that is very strange and Zeek is way better at detecting this. Not only is Zeek just 'better', Suricata litterly cannot do anything. It just sees that the machine suddenly has to tick 30 times per second, but how does it know this is malicious? there are signatures on this, and since suricata works primarily on signature-based detection, this just doesnt work. (Suricata DOES use anamoly detection somewhat, but when it cannot even parse and read the OT protocols, that functionality becomes useless)
This means that Suricata will be used for the Detection of general malware, lateral movement, and remote access abuse, etc. on the IT side. Zeek will give deep visibility into OT protocol behavior, and can detect anomalous behavior in these protocols. Lastly, Arkime is used for packet capture and correlation between logs and raw sessions.
Limits of Protocol Support (Purdue Model)
Malcolm can provide strong visibility into network activity, but its visibility relies on whether the data is sent through IP, as it has no native support for serial-based communication protocols.
The purdue model breaks industrial environments down into hierarchical layers, from business systems (level 5) down to phyiscal processes (Level 0)
Malcolms visibility mostly ends at level 2 which is the control network layer. This layer includes systems like SCADA, DCS and HMI software, where communications typically use IP-based OT protocols such as Modbus TCP, DNP3, or Ethernet/IP. These protocols can be parsed by Zeek, since they are IP-based and Zeek supports these protocols.
However, Level 1 and 0 involves the use of PLCs, field devices, and the phyisical systems themselves, which do not use IP-based protocols, but are serial-based only. Malcolm does not support serial-based protocols, which means Malcolm will not be able to monitor the data here. Malicious activity can even occur entirely within the PLC, such as tampering with ladder logic or internal logic blocks, something that isnt easily detectable by monitoring communications between systems. That would require firmware inspection or even physical access, not just network monitoring.
Even if those protocols were captures within Malcolm, Suricata does not have the signatures for OT protocol misuse, and Zeek has no context on what is safe or unsafe logic inside a PLC. Because of this, Malcolm will not be able to monitor level 1 or 0 activity. Things like Special ICS security tooling and PLC-integrated defenses should be used to monitor and secure this domain.
In the case of protocol support, Malcolm can still be viable for OT environments, but only in the intended scope:
-
IT IS NOT a full ICS intrusion PREVENTION system.
-
IT IS NOT a PLC firewall
-
It is purely for passive monitoring, protocol parsing, anomaly logging, and malware detection on Level 5, 4, 3, and 2 of the purdue model.
Can Malcolm be extended to support level 1 and 0?¶
Malcolm is not built to monitor Purdue model levels 1 and 0, since those levels often rely on serial-based communications between PLCs, sensors, and field devices. They basically use protocols that Malcolm cannot see or interpret.
However, there are some workarounds like protocol conversion, external tools, or log forwarding, which all have their limits.
Protocol Conversion
If the serial protocols are converted to Ethernet, for example Modbus RTU to Modbus TCP, then Malcolm can see and analyze them, but converting these protocols does not happen perfectly.
First you'd need a converter which can convert a serial-based protocol to an IP-based protocol which Malcolm can ingest. This does not exist for a lot of common serial-based protocols. (need sources to prove)
By converting a serial-based protocol to an IP-based protocol, the data can be stripped. This happens very often, and is insanely tricky to get working. An example of this is Modbus RTU to Modbus TCP. On serial to ethernet converters, long RTU responses (about 240 bytes) can often get cut off, because parts get dropped in the tcp stream.1 2 3 4 5 6 7
Another example between those two are Header vs CRC differences. Modbus RTU frames include a CRC at the end, while Modbus TCP uses a 7-byte MBAP header. The conversion results in the CRC being removed.
Another example is about sequence misalignment, where TCP streams may reorder messages, meaning Modbus masters/slaves cant tell which transaction a reply belongs to.
This is just for Modbus RTU to Modbus TCP. There are many more problems regarding serial-based to IP-based protocol conversion. (need some sources here to prove this statement)
Okay so lets conclude that even if it were to work, Malcolm just is not optimal for monitoring serial-based protocols. Even if you would make it work, it would cost a lot of time and work, which is not worth it.
Conclusion¶
Malcolm is viable for OT environments, but only up to level 2 of the Purdue Model. Malcolm is good for passive monitoring, protocol parsing, anomaly detection, and malware detection in IT zones. But it will not work for Level 1 and 0 zones, since it cannot parse and analyze serial protocols sufficiently, and it cannot see malicious logic in PLCs. For lower-level monitoring, purpose-built ICS tools are best.
Other Industrial Protocols¶
Process Automation Protocols
AS-i, BSAP, CC-Link, CIP, ControlNet, DF-1, DirectNet, EtherCAT, EGD, EtherNet/IP, Ethernet Powerlink, FINS, FOUNDATION Fieldbus, HostLink, Interbus, MECHATROLINK, MelsecNet, Modbus PEMEX/Plus, MPI, OSGP, OpenADR, Optomux, PieP, Profibus, PROFINET, RAPIEnet, SDS, SERCOS, GE SRTP, Sinec H1, SynqNet, TTEthernet
Industrial Control System Protocols
DDS, EPICS (Channel Access, PVA), MTConnect, OPC UA, Open Platform Communications
Building Automation Protocols
1-Wire, BACnet, BatiBUS, C-Bus, CC-Link, DALI, DSI, Dynet, EnOcean, EHS, EIB, INSTEON, KNX, LonTalk, Modbus, oBIX, UPB, VSCP, XAP, X10, Z-Wave, Zigbee
1 - https://control.com/forums/threads/modbus-rtu-over-ethernet-data-loss.36031/
2 - https://www.plctalk.net/threads/modbus-rtu-over-tcp-vs-modbus-tcp.139489/
3 - https://www.reddit.com/r/PLC/comments/xusp10/modbus_rtu_vs_modbus_rtu_over_tcp/
4 - https://www.iotrouter.com/detailed-explanation-of-the-difference-between-modbus-rtu-and-modbus-tcp-protocols/
5 - https://www.reddit.com/r/PLC/comments/1fndgdg/modbus_rtu_to_mqtt/
6 - https://www.reddit.com/r/PLC/comments/s63pqc/ethernetip_vs_modbus_tcp/
7 - https://support.industry.siemens.com/forum/nl/en/posts/modbus-rtu-over-tcp/146544