How machine learning helps categorize devices and detect anomalies in industrial networks

Device inventory in Kaspersky Industrial CyberSecurity for Networks

What data does MLEP analyze?

From observations to MLEP results

Event identification

Statistics processing in MLEP

MLEP in practice: how behavior helps complete the asset inventory

Anomalous activity and streaming statistics

In an industrial network, malicious activity can be hard to tell apart from normal data exchange between devices. Malicious actors routinely rely on legitimate tools and the Living-off-the-Land technique, so a single network connection may show no known signs of an attack: the device uses a familiar protocol and transmits ordinary data. An anomaly can hide in subtle details: the data source, the time of access, or the volume of transferred data may be atypical for a particular device. However, to detect this kind of anomaly, you need to understand the roles of the devices at both ends of the connection and know which network activity patterns are typical for them.

But an organization’s asset inventory data is often incomplete, which makes it harder to catch unauthorized connections in time. Suppose monitoring detects a host that regularly exchanges data with programmable logic controllers (PLCs). Its IP address is known, but the inventory does not specify what role it plays: is it an engineering workstation, a process data server, or a piece of contractor’s equipment? The host may also have been on the industrial network for a long time, with its record going out of date after a network upgrade.

In the joint OT asset inventory guidance released by CISA and its partners in 2025 , inventorying devices and classifying them by role are treated as part of OT asset management. For organizations, this is one of the most important areas: according to the SANS 2025 ICS security survey , 50% of respondents had deployed or significantly expanded ICS inventory and visibility tools over the previous 12 months, and 54% named them as investment priorities for the next 12–24 months.

In Kaspersky Industrial CyberSecurity for Networks , the Asset Discovery technology is the foundation of asset visibility. Passive network traffic analysis detects devices and their interactions, while recognition rules help determine the device category and extract available information about it, such as the vendor, model, or software version. Exactly which attributes the system can obtain depends on the protocol and the traffic it observes. We covered this in more detail at the Kaspersky Industrial Cybersecurity Conference .

Hardware and software information in the device card

The product also supports active polling modules (APMs): where polling is allowed, they can request additional configuration and firmware version details from devices. This kind of inventory is far more detailed than a list of IP addresses.

Installed modules and their placement in a PLC rack

However, even accurate hardware information doesn’t always explain what function a host performs in a specific industrial facility. Gaps appear for various reasons. Some devices send identifying information only at startup or during configuration, while others rarely communicate. Proprietary protocols can’t always be parsed, and encryption may leave only connection metadata for analysis. If the monitoring system doesn’t receive traffic from every segment of the industrial network, some network activity goes unobserved. Active polling doesn’t suit every device or every operating condition.

Devices of unknown category

When there isn’t enough direct information about a device, its category can be refined by looking at the patterns of its recurring network interactions. Analyzing these interactions is the job of Machine Learning Event Processor (MLEP), a service included in Kaspersky Industrial CyberSecurity for Networks 5.0. This machine-learning-based event processor can both refine device categories and detect anomalies in their network behavior.

To compare device behavior, you don’t need to store every packet as a separate observation (a data object) in the ML model. MLEP represents network sessions as a sequence of short 15-second fragments. For each fragment, MLEP stores information about the endpoints (IP, MAC, and port), the direction of data exchange, the protocol, and the number and size of the packets transmitted. Together these make up an event , which then gets a timestamp. Traffic thus becomes a sequence of events showing which hosts a device communicated with, when, and how communication intensity changed.

Aggregating data into events also sets the method’s limits. An aggregated fragment can’t be used to reconstruct the exact order of individual packets or the content of commands. MLEP can draw conclusions about a new protocol only if another KICS technology has managed to recognize it. That said, comparing stable network connections and changes in exchange volume doesn’t require a detailed record of every packet. These observations form the basis of the device’s behavioral history.

Each object has its own behavioral history, and one object’s history can’t be applied to another. But the principles of behavior analysis, along with some common rules, work across different objects.

Let’s look at how this works in MLEP, which is built on a spiking neural semantic network (NSN).

Neurosemantic networks structure information as a multilayer ordered graph, where the data in each consecutive layer builds on the data in the previous one. The nodes of this graph — that is, the units of information in each layer — act as neurons.The NSN creates dedicated channels to handle different event parameters (port, IP, and so on). Unique parameter values for each channel are stored as neurons in layer 0. The event itself, which consists of a set of parameter values, is stored as a neuron in layer 1 of the network. If an event occurs for the first time, neurogenesis creates a new neuron with input connections to the corresponding parameter neurons. This lets the network learn and operate on the event stream at the same time. If the event has occurred before, the network activates the same neuron that was created when the event first appeared. This way, the network identifies each event precisely. Each neuron that corresponds to an event also collects basic statistics: when it was last activated and how many times it has been activated.

In NSN-based event processing, layer 2 and above store sequences of events over time: recurring patterns and the full history. However, categorization and statistical anomaly detection don’t require storing the full packet sequence or a detailed timeline of every network event. As we noted earlier, events are themselves aggregates, which means the order of network packets has already been averaged out. So MLEP keeps history only temporarily, within each episode (30,000 aggregated events by default), which saves computing resources.

MLEP processes statistics mainly through specialized listener neurons on layer −1 (minus one) of the network. Attention heads and monitors are built on these neurons.

Key components of the NSN

When an event arrives, the corresponding neuron is activated, and the network instantly knows whether that neuron is new or was created earlier. Each attention head subscribes to the events or event features it needs and takes in only the activations of the matching neurons. If an event occurs for the first time, all heads are notified and then decide whether to subscribe (grow a connection to the relevant neuron) and receive information about activations of such neurons from then on.

It is called a spiking network because activation information is a spike, not a number. This spike tells the head that something it’s interested in has happened.

An attention head is configured according to scenarios — the situations that MLEP should send alerts about. The core of a head’s configuration is a query, which filters incoming information and serves as the subscription criterion. Unlike regular database queries, this query runs on the stream, so it can react to an event instantly.

Attention heads work very much like the semantics of ordinary human language. A query has a subject of attention (one or more grammatical subjects) and conditions (the other parts of the sentence). In the infrastructure of an industrial enterprise, the subjects are devices on the network, and the conditions are various aspects of network communication, such as ports, protocol, and average packet size. If a head has many subjects (for example, if it’s interested in every device on an industrial network), it fans out: it creates a child head for each individual value of the subject of attention, that is, each device. The child head then watches a specific device and reports to the parent head.

Attention heads don’t accumulate or process statistics. They only filter event streams. When an attention head receives a relevant event, it activates and sends a spike to the monitor subscribed to that head.

Monitors, in turn, have stacks for accumulating and processing events. They can also have their own queries and post-filter information from the head. For example, they can select only new events from those filtered by the head.

There are several types of monitors:

Stat monitors track changes in the average count of specific events (for example, device activity) over time intervals typical for those events, or in the average values of numeric event parameters (for example, changes in device traffic volume).

Monitors work from the event alone: they fire when an event has occurred a certain number of times within a given interval, or has occurred for the first time.

Similar-behavior monitors work with heads that can generalize events, that is, extract just a few parameters whose combination is shared (generalized) across many events.

MLEP uses these monitor types to implement scenarios for categorizing devices and detecting their anomalous behavior:

For categorization, MLEP uses attention heads and monitors that identify common behavior across different assets and group devices accordingly. MLEP then takes information from Asset Discovery about the known categories of some assets and extends those categories to other assets in the same group. Because a device can show different types of activity, it may land in several groups. MLEP then makes a weighted assessment across all relevant groups. Groups of devices with similar network behavior At the final stage, the system verifies that assigning the category to the asset is permissible. This is again done by special rule monitors loaded into the NSN at system startup. The rules rely on asset metadata available from Asset Discovery and APMs.

Groups of devices with similar network behavior

At the final stage, the system verifies that assigning the category to the asset is permissible. This is again done by special rule monitors loaded into the NSN at system startup. The rules rely on asset metadata available from Asset Discovery and APMs.

MLEP takes a similar approach to anomaly detection: an attention head and a monitor define an anomaly scenario, often loosely. When a monitor activates on such a scenario, MLEP generates an alert about unusual behavior.

The current version of MLEP ships with preconfigured heads and monitors.

The functional dynamic diagram below shows how events from devices on an industrial network are processed. Event processing flow

Event processing flow

At a facility with several similar production lines, device information may be more complete on some lines than on others. On one line, devices are identified as PLCs, while on another, after an upgrade, some hosts show up only as addresses: the available traffic didn’t provide enough information to determine their category. Still, these devices communicate with the same types of HMIs and process data collection servers. Their communication directions, frequency, and volumes may be similar.

That’s where MLEP comes in. It takes the categories of already known assets and matches recurring features of their network behavior against those of uncategorized devices. When the observed interactions turn out to be similar, MLEP can add a category for that host to the inventory.

Device category suggested by MLEP

Once the category is refined, the industrial network map provides more context about the equipment on the network. When analyzing network activity, the analyst immediately sees the device’s suggested category and can skip looking up each IP address in the design diagrams. This approach is especially useful where equipment changes faster than the documentation is updated.

The suggested category is also checked against existing device information and defined constraints. This helps filter out some contradictory options, but prediction quality still depends on how much of the traffic is visible, especially if the device communicates only rarely.

Investigations of real-world attacks show that attackers actively use both standard tools and permitted protocols. You don’t always need to know an attacker’s specific technique in advance to spot potentially malicious activity. Signature-based detection helps find known signs of an attack, but it doesn’t assess how typical an observed interaction is for a particular device. MLEP compares current activity with the device’s usual network profile: which hosts it communicates with, which protocols it uses, when and how much data it transmits, its average packet size, and so on. The changes it detects help guide the direction of the investigation. Correlating these changes with other events and the operational context helps determine whether malicious actions could be behind them. When investigating an incident that has already been detected, anomalies help reconstruct the sequence of actions.

The first version of MLEP comes with six preconfigured monitors, one for each type of deviation from the device’s usual network profile:

During an investigation, anomalies help reconstruct the sequence of changes: when a specific host established new connections, switched protocols, increased its data transfer volume, or shifted its operating hours. Matching events by device and time shows an analyst how activity unfolded around an incident that has already been detected.

This is especially useful when some of the attacker’s actions fell outside the monitored scope or didn’t trigger other KICS technologies. Correlating these changes with the device’s role, protocol analysis data, and events from other technologies gives the analyst a more complete timeline. Behavioral anomalies show exactly where to look for the missing links and which network interactions need attention.

Atypical Activity Time anomaly card

In the event list, anomalies detected by MLEP are marked with an AI label. Each event shows its name, source, destination, timestamp, and the ID of the triggered scenario.

In an industrial network, whether behavior is anomalous depends on the host where it occurs and that host’s place in the industrial process. The repetitive nature of many communications makes a change in normal data exchange easier to spot, while knowing a device’s function and criticality helps gauge the possible consequences. Taken together, these observations make network traffic more than a list of connections: it helps assess new events in the context of a specific facility, even without an attack scenario known in advance. Machine learning technologies are well suited to this kind of comprehensive analysis, as they can process and organize huge streams of heterogeneous data. Starting with version 5.0, Kaspersky Industrial CyberSecurity for Networks handles this function with MLEP, which works effectively alongside the product’s existing functionality.

Industrial control systems

Operational Technology

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

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Kaspersky Industrial Cyber​​Security for Networks 中的设备清单

MLEP 分析哪些数据？

从观察到MLEP结果

事件识别

MLEP中的统计处理

MLEP实践：行为如何帮助完成资产清单

异常活动和流媒体统计信息

在工业网络中，恶意活动很难与设备间正常的数据交换区分开来。恶意攻击者通常会利用合法工具和“借力打力”的策略，因此单个网络连接可能不会显示出任何攻击迹象：设备使用熟悉的协议并传输普通数据。异常情况可能隐藏在一些细微之处：数据源、访问时间或传输的数据量对于特定设备而言可能不寻常。然而，要检测这类异常情况，需要了解连接两端设备的角色，并掌握它们典型的网络活动模式。

但组织的资产清单数据通常并不完整，这使得及时发现未经授权的连接变得更加困难。假设监控系统检测到一台主机定期与可编程逻辑控制器 (PLC) 交换数据。虽然知道它的 IP 地址，但清单中并未明确指出它的具体用途：是工程工作站、过程数据服务器，还是承包商的设备？此外，该主机可能已接入工业网络很长时间，网络升级后其记录可能已经过时。

在CISA及其合作伙伴于2025年联合发布的OT资产清单指南中，设备清单的编制和按角色分类被视为OT资产管理的一部分。对于企业而言，这是最重要的领域之一：根据SANS 2025 ICS安全调查，50%的受访者在过去12个月中部署或大幅扩展了ICS清单和可视化工具，54%的受访者将其列为未来12-24个月的投资重点。

在卡巴斯基工业网络安全解决方案中，资产发现技术是资产可见性的基础。被动网络流量分析能够检测设备及其交互，而识别规则则有助于确定设备类别并提取可用信息，例如供应商、型号或软件版本。系统能够获取的具体属性取决于协议及其监控的流量。我们在卡巴斯基工业网络安全大会上对此进行了更详细的介绍。

设备卡中的硬件和软件信息

该产品还支持主动轮询模块 (APM)：在允许轮询的情况下，它们可以从设备请求额外的配置和固件版本信息。这种清单信息比 IP 地址列表要详细得多。

已安装模块及其在PLC机架中的位置

然而，即使是准确的硬件信息也并非总能解释主机在特定工业设施中执行的具体功能。信息缺失的原因多种多样。有些设备仅在启动或配置期间发送识别信息，而另一些设备则很少通信。专有协议并非总能被解析，加密可能只留下连接元数据供分析。如果监控系统无法接收到来自工业网络每个部分的流量，则部分网络活动将无法被监测到。主动轮询并非适用于所有设备或所有运行条件。

未知类别的设备

当缺乏关于设备的直接信息时，可以通过分析其反复出现的网络交互模式来细化其类别。分析这些交互是机器学习事件处理器 (MLEP) 的职责，MLEP 是 Kaspersky Industrial Cyber​​Security for Networks 5.0 中的一项服务。这款基于机器学习的事件处理器既可以细化设备类别，也可以检测其网络行为中的异常情况。

为了比较设备行为，您无需将每个数据包都作为单独的观测值（数据对象）存储在机器学习模型中。MLEP 将网络会话表示为一系列 15 秒的短片段。对于每个片段，MLEP 存储有关端点（IP、MAC 和端口）、数据交换方向、协议以及传输数据包的数量和大小的信息。这些信息共同构成一个事件，并为其添加时间戳。因此，流量就变成了一系列事件，显示了设备与哪些主机通信、通信时间和通信强度的变化情况。

将数据聚合为事件也限制了该方法的适用范围。聚合后的片段无法用于重建单个数据包的确切顺序或命令内容。只有当其他 KICS 技术能够识别新协议时，MLEP 才能得出关于该协议的结论。也就是说，比较稳定的网络连接和交换量的变化并不需要详细记录每个数据包。这些观察结果构成了设备行为历史记录的基础。

每个物体都有其自身的行为历史，一个物体的行为历史不能直接套用到另一个物体上。但是，行为分析的原理以及一些通用规则，可以应用于不同的物体。

让我们看看 MLEP 是如何工作的，MLEP 是基于脉冲神经网络语义网络 (NSN) 构建的。

神经语义网络将信息结构化为一个多层有序图，其中每一层的数据都建立在前一层的数据之上。该图的节点——即每一层的信息单元——充当神经元。神经语义网络创建专用通道来处理不同的事件参数（端口、IP地址等）。每个通道的唯一参数值存储在第0层，作为神经元。事件本身（由一组参数值组成）存储在网络的第1层，作为神经元。如果一个事件是首次发生，神经发生会创建一个新的神经元，并将其输入连接到相应的参数神经元。这使得网络能够同时学习和处理事件流。如果事件之前已经发生过，网络会激活事件首次出现时创建的同一个神经元。通过这种方式，网络可以精确地识别每个事件。每个与事件对应的神经元还会收集一些基本统计信息：上次激活的时间以及激活次数。

在基于网络状态网络（NSN）的事件处理中，第 2 层及以上层会存储随时间变化的事件序列：包括重复出现的模式和完整的历史记录。然而，分类和统计异常检测并不需要存储完整的包序列或每个网络事件的详细时间线。正如我们之前提到的，事件本身就是聚合数据，这意味着网络包的顺序已经被平均化了。因此，MLEP 仅临时地在每个事件周期内（默认包含 30,000 个聚合事件）保留历史记录，从而节省计算资源。

MLEP主要通过网络-1层（减一层）上的专用监听神经元处理统计信息。注意力头和监控器就构建在这些神经元之上。

NSN的关键组成部分

当事件发生时，相应的神经元会被激活，网络会立即判断该神经元是新创建的还是之前已经创建的。每个注意力头都会订阅它所需的事件或事件特征，并且只接收匹配神经元的激活信息。如果某个事件是首次发生，所有注意力头都会收到通知，然后决定是否订阅（建立与相关神经元的连接），并从此接收有关这些神经元激活的信息。

它之所以被称为脉冲神经网络，是因为激活信息是一个脉冲，而不是一个数字。这个脉冲告诉大脑，它感兴趣的事情发生了。

注意头是根据场景进行配置的——场景指的是MLEP应该发送警报的情况。注意头配置的核心是一个查询，它用于过滤传入信息并作为订阅条件。与常规数据库查询不同，该查询在数据流上运行，因此可以对事件做出即时反应。

注意力头的工作原理与普通人类语言的语义非常相似。一个查询包含一个关注对象（一个或多个语法主语）和条件（句子的其他部分）。在工业企业的基础设施中，关注对象是网络上的设备，条件是网络通信的各个方面，例如端口、协议和平均数据包大小。如果一个注意力头关注多个关注对象（例如，如果它对工业网络上的每个设备都感兴趣），它就会展开：它会为关注对象的每个值（即每个设备）创建一个子注意力头。子注意力头随后监视特定设备并向父注意力头报告。

注意力头不会累积或处理统计数据，它们只负责过滤事件流。当注意力头接收到相关事件时，它会被激活，并向订阅该注意力头的监视器发送一个脉冲信号。

监视器则拥有用于累积和处理事件的堆栈。它们还可以拥有自己的查询，并对来自头部的信息进行后处理。例如，它们可以从头部过滤后的事件中选择新事件。

显示器有几种类型：

统计监视器跟踪特定事件（例如设备活动）的平均计数在典型时间间隔内的变化，或者跟踪数值事件参数的平均值（例如设备流量的变化）。

监视器仅根据事件工作：当事件在给定的时间间隔内发生一定次数，或者首次发生时，监视器就会触发。

相似行为监视器使用能够概括事件的头部，也就是说，提取几个参数，这些参数的组合在许多事件中是共享的（概括的）。

MLEP 使用这些监控类型来实现对设备进行分类和检测其异常行为的场景：

为了进行分类，MLEP 使用注意力头和监控器来识别不同资产的共同行为，并据此对设备进行分组。然后，MLEP 从资产发现中获取有关某些资产已知类别的信息，并将这些类别扩展到同一组中的其他资产。由于设备可能表现出不同类型的活动，因此它可能属于多个组。MLEP 随后对所有相关组进行加权评估。具有相似网络行为的设备组。在最后阶段，系统验证将类别分配给资产是否允许。这同样由在系统启动时加载到 NSN 中的特殊规则监控器完成。这些规则依赖于从资产发现和 APM 获取的资产元数据。

具有相似网络行为的设备组

在最后阶段，系统会验证将资产类别分配给该资产是否合法。这一步骤同样由系统启动时加载到 NSN 中的特殊规则监控程序完成。这些规则依赖于资产发现和 APM 提供的资产元数据。

MLEP采用类似的异常检测方法：一个注意力头和一个监控器共同定义一个异常场景，通常定义较为宽泛。当监控器在此类场景下被激活时，MLEP会生成一条关于异常行为的警报。

当前版本的 MLEP 出厂时已预配置了显示器和监视器。

下图所示的功能动态图展示了如何处理来自工业网络中设备的事件。事件处理流程

事件处理流程

在拥有多条类似生产线的工厂中，不同生产线的设备信息可能存在差异。例如，一条生产线上的设备被识别为PLC，而另一条生产线在升级后，部分主机仅显示为地址：现有流量不足以确定其设备类别。尽管如此，这些设备仍然与相同类型的HMI和过程数据采集服务器进行通信。它们的通信方向、频率和数据量可能也相似。

这就是 MLEP 的作用所在。它会根据已知资产的类别，将这些资产网络行为的重复特征与未分类设备的特征进行匹配。当观察到的交互行为相似时，MLEP 就可以将该主机添加到资产清单中。

MLEP建议的设备类别

类别确定后，工业网络拓扑图可以提供更多关于网络设备的信息。分析网络活动时，分析人员可以立即看到设备的建议类别，而无需在设计图中查找每个 IP 地址。这种方法在设备更新速度快于文档更新速度的情况下尤为有效。

系统还会将建议的类别与现有设备信息和已定义的约束条件进行比对。这有助于过滤掉一些相互矛盾的选项，但预测质量仍然取决于可见流量的大小，尤其是在设备通信频率较低的情况下。

对真实攻击的调查表明，攻击者会积极使用标准工具和允许的协议。您并不总是需要事先了解攻击者的具体技术才能发现潜在的恶意活动。基于特征码的检测有助于发现已知的攻击迹象，但它无法评估观察到的交互对于特定设备而言是否典型。MLEP 将当前活动与设备的常用网络配置文件进行比较：例如，设备与哪些主机通信、使用哪些协议、何时传输数据以及传输多少数据、平均数据包大小等等。它检测到的变化有助于指导调查方向。将这些变化与其他事件和运行环境关联起来，有助于确定其背后是否存在恶意行为。在调查已检测到的事件时，异常情况有助于重构事件的操作序列。

MLEP 的第一个版本预配置了六个监视器，每个监视器对应设备偏离其常用网络配置文件的一种类型：

在调查过程中，异常情况有助于重现变更顺序：例如特定主机何时建立新连接、切换协议、增加数据传输量或改变运行时间。通过按设备和时间匹配事件，分析人员可以了解已检测到的事件发生前后的活动情况。

当攻击者的某些行为超出监控范围或未触发其他KICS技术时，这种方法尤其有用。将这些变化与设备的角色、协议分析数据以及来自其他技术的事件关联起来，可以为分析人员提供更完整的事件时间线。行为异常能够准确地指出缺失环节所在以及需要关注的网络交互。

非典型活动时间异常卡

在事件列表中，MLEP 检测到的异常情况会用 AI 标签标记。每个事件都会显示其名称、来源、目的地、时间戳以及触发场景的 ID。

在工业网络中，行为是否异常取决于异常发生的主机及其在工业流程中的位置。许多通信的重复性使得正常数据交换的变化更容易被发现，而了解设备的功能和关键性则有助于评估可能造成的后果。综合这些观察结果，网络流量不仅仅是连接列表：它有助于在特定设施的背景下评估新事件，即使事先没有已知的攻击场景。机器学习技术非常适合这种综合分析，因为它们可以处理和组织海量的异构数据流。从 5.0 版本开始，卡巴斯基工业网络安全软件通过 MLEP 处理此功能，该功能与产品现有的功能协同工作。

工业控制系统

运营技术

KICS for Networks 5.0 中的 MLEP：机器学习如何帮助跟踪 OT 设备的网络行为

本网站使用 Akismet 来减少垃圾邮件。了解您的评论数据如何处理。