> ## Content Index > Fetch the complete content index at: https://f4n6.co.uk/llms.txt > Use this file to discover other available public pages before exploring further. # Kaspersky details MLEP in KICS 5.0 for OT anomaly detection - URL: https://f4n6.co.uk/security-feed/kaspersky-details-mlep-in-kics-5-0-for-ot-anomaly-detection/ - Published: 2026-11-03T15:13:12.000Z - Updated: 2026-11-03T15:13:12.000Z - Author: Jeff Davies - Tags: #security-feed ## 1\. Executive summary Kaspersky published a product description of the Machine Learning Event Processor (MLEP), a service included in Kaspersky Industrial CyberSecurity for Networks 5.0 that refines OT device categories and flags deviations from a device's usual network behaviour. The item is vendor product documentation, not a report of an intrusion, a vulnerability or a campaign: no CVE, no affected or fixed version, no victim and no threat actor are named. No exploitation is described and no CISA KEV entry applies. The relevance to EMEA financial services is indirect and limited to institutions that run OT or industrial control networks, such as data-centre facilities management, physical security and building management, where the described anomaly categories (new external host, new protocol, scanning-like activity) map to behaviours an intrusion would produce; for those clients it is a detection-engineering input, not an incident to respond to. ## 2\. Regulatory framing No specific DORA/NIS2 article is directly engaged by this item. ## 3\. Technical analysis & attack chain There is no attack chain. The source describes a defensive analytics component and the detection logic behind it. What follows is the mechanism as Kaspersky documents it, because that is what a detection engineer can act on. MLEP sits alongside the Asset Discovery technology in KICS for Networks. Asset Discovery uses passive traffic analysis and recognition rules to identify devices and extract vendor, model and software version, and active polling modules (APMs) can request additional configuration and firmware detail where polling is permitted. Gaps remain: some devices send identifying information only at startup or during configuration, some rarely communicate, proprietary protocols cannot always be parsed, encryption may leave only connection metadata, and segments the monitoring system does not see go unobserved. MLEP addresses the case where a host's role is unknown, for example a host that regularly exchanges data with PLCs but whose inventory record does not say whether it is an engineering workstation, a process data server or contractor equipment. The data model aggregates rather than captures packets. Network sessions are represented as a sequence of 15-second fragments. For each fragment MLEP stores the endpoints (IP, MAC and port), the direction of exchange, the protocol, and the number and size of packets transmitted; the combination forms an event with a timestamp. This sets a hard limit: an aggregated fragment cannot reconstruct the exact order of individual packets or the content of commands, and MLEP can only reason about a protocol that another KICS technology has already recognised. The engine is a spiking neural semantic network (NSN), a multilayer ordered graph in which nodes act as neurons. Layer 0 holds unique parameter values per channel (port, IP and so on). Layer 1 holds the event as a neuron with input connections to its parameter neurons; a first-seen event triggers neurogenesis to create that neuron, and a repeat event activates the existing one, which also tracks when it was last activated and how many times. Layers 2 and above hold sequences over time. History is kept only within an episode, 30,000 aggregated events by default, which bounds memory use. Layer -1 holds listener neurons on which attention heads and monitors are built. Activation is a spike rather than a value. An attention head subscribes to the events or features it needs through a query evaluated on the stream; a head with many subjects fans out into a child head per subject, each watching one device and reporting to the parent. Monitors hold stacks for accumulating and processing events and can post-filter, for example selecting only new events. At the categorisation stage, rule monitors loaded at system startup check that assigning a category to an asset is permissible against asset metadata from Asset Discovery and APMs. Categorisation works by comparison. Where one production line has devices identified as PLCs and another line, after an upgrade, shows hosts only as addresses, MLEP matches the recurring behavioural features of the uncategorised devices against known assets and adds a category when the observed interactions are similar. Kaspersky states prediction quality depends on how much traffic is visible, particularly for devices that communicate rarely. The first version ships with six preconfigured monitors, one per deviation type: a new external host not previously seen in the device's behaviour, even if the IP is not on a known-IoC list; a new combination of destination address and port; an unusually large volume of data sent; activity at a time atypical for the device; a new protocol, including to familiar hosts; and activity with signs of scanning, meaning the device contacts an unusually large number of neighbouring hosts. In the event list these are marked with an AI label and show name, source, destination, timestamp and the ID of the triggered scenario. Kaspersky frames the value as investigative: anomalies help reconstruct the sequence of changes around an already-detected incident and point to where attacker actions that fell outside monitored scope or triggered no other KICS technology may sit. Adverse Trace assesses that the six anomaly categories are generic behavioural signals, not signatures of a specific toolset, and the source names no actor, malware family or campaign that MLEP was tested against. The claim that the approach helps against living-off-the-land activity is Kaspersky's stated rationale; the item contains no measured detection results, false-positive rates or customer telemetry to support it. Treat the capability description as vendor-stated. ## 4\. Mitigation & containment The item names no vulnerability and no fixed release, so there is nothing to patch on its account. The steps below apply only to clients running KICS for Networks or evaluating it. P1 (within 24h) - Establish whether KICS for Networks is deployed and at which version. MLEP is included from 5.0; earlier versions do not have it, and the source names no upgrade path or fixed build, so confirm availability with Kaspersky support rather than assuming an in-place upgrade. - If 5.0 is deployed, confirm the six preconfigured monitors are enabled and that MLEP events carrying the AI label are routed into the SOC queue rather than left in the product console. P2 (within 72h) - Map each MLEP anomaly type to an existing detection or triage playbook: new external host to egress review, new destination and port combination to firewall change verification, unusually large data volume to data-flow baselining, atypical activity time to shift-aware monitoring, new protocol to protocol allow-list review, scanning-like activity to east-west reconnaissance alerting. - Close the visibility gaps the source identifies, since MLEP's categorisation and anomaly quality depend on them: confirm traffic from every industrial segment reaches the monitoring system, and review where APMs are permitted so device metadata is as complete as operating conditions allow. P3 (within 7 days) - Where inventory records are stale after network upgrades, use MLEP's suggested categories as a reconciliation input, and record that a suggested category is a prediction checked against Asset Discovery and APM metadata, not an authoritative asset record. - Record in the OT monitoring risk register that MLEP aggregates traffic into 15-second fragments and cannot reconstruct packet order or command content, so it complements rather than replaces protocol-aware and signature detection. ## 5\. Indicators of compromise No indicators of compromise available in the source material. ## 6\. Detection Insufficient indicators to author detection rules. The source describes product behaviour (event aggregation, anomaly categories, the AI label in the event list) but gives no artefact of a threat: no file names, paths, command lines, registry keys, mutexes or network values. A rule built from product or anomaly-category names would detect the reporting, not malicious activity. ## 7\. Sources - Kaspersky Securelist, "MLEP in KICS for Networks 5.0: how machine learning helps track network behavior of OT devices", https://securelist.com/tr/machine-learning-event-processor-in-kics-for-networks/121794/, 2026-11-03 - Kaspersky Securelist, "How machine learning helps categorize devices and detect anomalies in industrial networks", https://securelist.com/tr/machine-learning-event-processor-in-kics-for-networks/121794/ (alternate title of the same article; no separate date given) ## 8\. Adverse Trace position Adverse Trace assesses this as vendor product documentation with no threat, vulnerability or victim attached, so it carries no incident severity and no CISA KEV or EPSS state applies. Client impact is confined to institutions with OT or industrial control estates, and there it is a monitoring-coverage question rather than an exposure: the six anomaly categories are worth wiring into OT triage, but the effectiveness claims are Kaspersky's own and single-sourced, with no detection metrics published, so verify before relying on them. We will track KICS for Networks release notes for any security-relevant fix to MLEP or Asset Discovery and reissue if Kaspersky publishes detection results or incident data tied to the feature. --- [Read the original source →](https://securelist.com/tr/machine-learning-event-processor-in-kics-for-networks/121794/?ref=f4n6.co.uk) *Published via PulseTrace — Adverse Trace threat intelligence.*