How Machine Learning Improves Visibility in OT Networks

Industrial network defenders face a basic problem before they can investigate suspicious activity: they need to know what each device is and what normal communication looks like. In many facilities, that information is incomplete. A host may have a known IP address but no reliable record of whether it is an engineering workstation, a process-data server, or contractor equipment. Network upgrades, infrequent device communication, proprietary protocols, encryption, and incomplete monitoring coverage can all make static inventories less dependable.

Securelist, the research publication operated by Kaspersky, describes how the Machine Learning Event Processor (MLEP) in Kaspersky Industrial CyberSecurity for Networks 5.0 is intended to address this gap. The technology uses passive network observations and behavioral analysis to refine device categories and identify deviations from an individual device’s established network profile. It is not presented as a replacement for asset management, protocol analysis, or analyst judgment. Instead, it adds a behavioral layer that can help turn incomplete network data into investigative context.

Why asset identity matters in an industrial environment

In enterprise networks, an unfamiliar connection can be concerning on its own. In operational technology (OT), its significance depends heavily on the role of the communicating devices. A connection involving a programmable logic controller (PLC), human-machine interface (HMI), historian, or engineering workstation has different implications depending on the process and the expected data flows.

According to Securelist, Kaspersky’s Asset Discovery technology builds an initial inventory through passive traffic analysis. Recognition rules can identify device categories and extract attributes such as vendor, model, or software version when the observed protocol exposes that information. The product also supports active polling modules that can request additional configuration and firmware details where polling is appropriate.

Those methods do not eliminate uncertainty. Some devices reveal identifying information only during startup or configuration. Others communicate too rarely to provide enough evidence. Proprietary protocols may not be parsed, encrypted traffic may expose only metadata, and monitoring that does not cover every network segment cannot account for unseen activity. Active polling may also be unsuitable for certain devices or operating conditions.

MLEP is designed to help with the remaining classification problem. Rather than relying only on direct device identifiers, it examines recurring communication patterns and compares less clearly identified hosts with devices whose categories are already known.

What MLEP observes

Securelist says MLEP does not retain every packet as an individual machine-learning observation. It divides network sessions into 15-second fragments and records attributes including the endpoints’ IP and MAC addresses, port, communication direction, protocol, and packet counts and sizes. Each fragment becomes a timestamped event.

This representation allows the system to track which devices communicate, when they communicate, and how the intensity of those exchanges changes. It is also an important boundary on what the technology can determine. Aggregated events cannot reconstruct the exact sequence of packets or the contents of commands. MLEP can draw conclusions about a new protocol only when another KICS capability has recognized that protocol.

Each monitored object has its own behavioral history. Securelist explains that the system uses a spiking neural semantic network to identify recurring event patterns and process event statistics. The network can recognize whether an event is new or has appeared before, while specialized components filter relevant activity and evaluate changes over time.

The event history is temporary rather than an indefinite packet-level archive. Securelist states that an episode contains 30,000 aggregated events by default. This design reduces resource requirements, but it also means organizations should not treat MLEP as a substitute for packet capture, protocol-specific logging, or long-term forensic storage.

From behavior to device classification

The classification process is based on similarity. Devices that repeatedly communicate with comparable hosts, use similar protocols, exchange data in similar directions, and show comparable timing or volume patterns can be grouped together. Categories from known assets can then help inform the classification of less clearly identified devices.

Securelist gives the example of similar production lines where one line has better-documented devices than another after an upgrade. If an uncategorized host communicates with the same types of HMIs and process-data collection servers, and does so with comparable frequency and volume, its behavior may support a suggested category.

A device can belong to more than one behavior group because it may perform multiple types of activity. MLEP makes a weighted assessment across relevant groups and then checks the result against asset metadata and defined constraints. That final validation is important: a behaviorally similar device is not automatically identical in function, and the suggested category still depends on the quality and completeness of the observed traffic.

This approach can be particularly useful where documentation has fallen behind physical or logical changes in the plant. It can help analysts see a more informative network map than one based only on addresses. However, Securelist explicitly notes that prediction quality depends on traffic visibility and can be weaker when a device communicates only occasionally.

How behavioral anomalies support investigations

Signature-based detection remains useful for known indicators, but industrial attackers may use permitted protocols and standard tools. In those cases, the traffic can look technically valid while still being unusual for the specific device, time period, or operational role.

MLEP compares current activity with a device’s established profile. Securelist describes six preconfigured monitor types in the first version:

• New external host: identifies an external connection not previously observed for the device.
• New destination-and-port combination: highlights use of a service the device has not previously used.
• Unusually large outbound data volume: identifies transfers that differ from the device’s normal behavior.
• Atypical activity time: flags activity during a period unusual for that device.
• New protocol: identifies a communication method not previously associated with the device.
• Activity resembling scanning: highlights contact with an unusually large number of neighboring hosts.

These signals are not, by themselves, proof of compromise. A maintenance window, production change, system migration, vendor intervention, or legitimate troubleshooting can produce the same type of deviation. Securelist presents the anomalies as investigation aids: analysts can correlate them by device and timestamp with protocol information, other security events, and operational context to reconstruct how activity unfolded.

For example, a new destination may be more meaningful if it appears alongside an unusual operating hour and a sharp increase in outbound traffic. Conversely, a new connection during a documented engineering change may be expected. The value comes from combining the behavioral signal with the device’s role and the facility’s change records.

Visibility limits and false-positive considerations

Behavioral analytics are only as reliable as the behavior they can observe. A sensor that does not receive traffic from a relevant segment cannot establish a complete baseline for that segment. Encrypted or proprietary communications may reduce the available context. Rarely active devices may take longer to profile, and a baseline formed during an unusual operating period may not represent normal production.

Industrial environments also change for legitimate reasons. Firmware updates, line upgrades, new remote-access arrangements, seasonal schedules, and contractor work can alter destinations, protocols, timing, or data volumes. These changes should be recorded and reviewed rather than automatically treated as malicious.

Securelist does not report a victim set, campaign, malware family, vulnerability, CVE, or threat-actor attribution in this research. The article is a technical discussion of MLEP and OT monitoring capabilities, not an incident report. It also does not establish that any one anomaly represents an attack.

What organizations should do now

• Improve coverage before tuning alerts. Identify which OT segments, conduits, and critical devices are visible to monitoring. Document blind spots and avoid treating an incomplete baseline as a complete representation of plant activity.
• Validate suggested asset categories. Compare behavioral classifications with engineering diagrams, control-system documentation, maintenance records, and responsible asset owners. Record confidence and unresolved identity questions.
• Build baselines around operating context. Account for shifts, planned maintenance, production changes, remote support, and seasonal operating patterns. A single “normal” profile may be insufficient for facilities with materially different operating modes.
• Correlate anomalies rather than escalating them in isolation. Review the device role, destination, protocol, timing, traffic volume, authentication or access records, and change-management data together. Prioritize combinations of deviations that affect critical assets.
• Preserve complementary evidence. Because aggregated behavioral events cannot reconstruct packet contents or every packet ordering detail, retain appropriate protocol logs, firewall records, remote-access logs, and other evidence needed for investigation.
• Use controlled validation. Work with operations and engineering teams to confirm whether a new protocol, destination, or activity period is expected. Do not perform intrusive testing against live control equipment without an approved safety and change process.
• Integrate results into existing response workflows. Route high-value alerts to the team responsible for OT triage, define escalation criteria, and document how analysts verify or close behavioral findings. Organizations can map confirmed activity to their existing ICS security framework after validating the underlying evidence.
• Review model performance over time. Track recurring benign alerts, newly introduced equipment, and changes in network architecture. Update asset records and monitoring assumptions when the plant changes.

Conclusion

Securelist’s discussion of MLEP illustrates a practical role for machine learning in OT security: improving asset context and highlighting behavior that differs from a device’s own history. The approach is useful because it does not require defenders to know every possible attack pattern in advance. At the same time, it remains dependent on visibility, accurate context, and human validation.

For industrial organizations, the strongest use of behavioral analytics is as one layer in a broader monitoring and response program. Better device identity, complete network coverage, disciplined change records, and correlated investigation are what turn an anomaly into a defensible security finding.

Sources

Securelist: “MLEP in KICS for Networks 5.0: how machine learning helps track network behavior of OT devices”