In describing SIEM features, vendors almost invariably focus on numbers: how many correlation rules come out of the box, how many were added over the past year, and how many MITRE ATT&CK techniques they cover. Admittedly, these numbers matter. They do help gauge how effective a system is, and we share them from time to time too. But correlation rules aren’t a magic amulet, and having more of them doesn’t make a SIEM more effective. In fact, the total number of available rules says more about the variety of use cases the system supports. The question a hands-on SIEM analyst cares about first of all is different: which of these rules will actually work and be useful at my company? The answer is far from always obvious, and the reason isn’t even rule quality.

How correlation rules work

A rule first and foremost describes the logic: what to match against what, in what order, and within what time window. It also specifies particular event types from particular sources. For example, a rule for Active Directory group creation waits for events from the Windows Security log; a rule for suspicious network activity — DNS queries; a rule for process manipulation — triggers on events from endpoint telemetry. In other words, whether a rule works depends on whether the SIEM receives the right data in the first place.

The Active Directory rule above would be completely pointless at a company that avoids Windows on principle. It would load without errors, show up in the interface, and technically “exist” — but it would never fire. The reason is simple: the events it was built for never reach the system.

That dictates the only correct order of steps when setting up an SIEM. Don’t start out from the list of rules and then work your way toward your infrastructure. Go the other way around: first pin down which event sources are actually connected and feeding data into the SIEM, and only then see which rules will work on that data. Doing it the other way around leads to one of two outcomes: unmet expectations (hundreds of rules, almost no detections), or a laborious rule-by-rule manual slog, where the analyst opens every rule’s description, checks its event requirements, and decides whether the rule is worth using.

What the MITRE ATT&CK coverage percentage means

MITRE ATT&CK coverage is much the same story: it’s often used without a second thought as a yardstick for product effectiveness. The catch is that these are numbers in a vacuum, with no real-world conditions behind them. Coverage only makes sense for a specific set of working rules. And as we saw above, that set of rules depends on the set of event sources. That’s why the same SIEM will show different MITRE ATT&CK coverage at two different companies. Where Windows logs, endpoint telemetry, an email gateway, and network equipment are all connected, coverage will be noticeably broader than at a company with fewer sources.

Here’s the right way to read this metric: it’s not a score for the SIEM content, but a map of what your SIEM can see with its current telemetry. A tactic with low coverage is a signal that detecting it requires data you don’t have yet. Framed this way, it becomes a clear argument for a management conversation. Not “we need one more event source”, but “this part of the matrix is currently invisible to us, and here’s what it takes to close the gap”.

What’s worth checking in your SIEM

To get the most out of a SIEM, it’s worth asking yourself a few questions — not just when deploying the system, but regularly:

• Is every connected event source being handled by rules? Infrastructure changes constantly: new systems appear and new integrations get connected. Every change like this is a reason to check again whether there are now rules you should enable.
• Do I know exactly which events are required for which rules? Sometimes a rule doesn’t fire not because a whole event source is missing, but because a single event type isn’t being collected: the audit policy simply isn’t set up to capture it. Fix that oversight as soon as possible.
• Do I understand my coverage in terms of MITRE ATT&CK? The point isn’t to produce good-looking reports. It’s to prioritize which event sources to add next: which ones will give the biggest gain in visibility?

But how can you answer these questions without spending ages digging into every rule description? We have a solution.

How we can help

To help analysts find their way around the detection logic of our solution more easily, we’ve added a knowledge base section with the complete set of Kaspersky SIEM rules. In essence, it’s a tool that holds data from the official documentation for the SOC Package rule set, and makes it easy to work with that data. It has three sections:

Library. A table of all correlation rules that you can sort and filter per any column: category, MITRE tactic and technique, event source, and event type. Search works across all fields, including descriptions. Double-clicking a rule opens a card with detailed information about it.

Builder. A tool for assembling a rule set that suits the event sources you already have. The analyst just checks the boxes for the sources the company has, and gets a list of matching rules, brief statistics, and the event types that need to be set up for collection. The tool also generates a regular expression that you can paste into the search bar of the Kaspersky SIEM web interface to link all the matching rules to the correlator in a single step, with no manual picking.

MITRE. A view of the ATT&CK matrix where tactics expand into techniques and sub-techniques. Each matrix item has a card with the description from the MITRE website, and SOC Package coverage details. Covered and uncovered items are color-coded, and charts show coverage per tactic.

One more point worth stressing: the content in our SIEM is updated constantly, so it makes sense to check your setup against it not only at deployment, but after every notable change in your infrastructure. To follow the development of the Kaspersky Unified Monitoring and Analysis Platform, visit the official product page.

According to global research, the market share of highly automated, driverless vehicles is growing rapidly. Analysts estimate that the next 10 to 15 years will mark a major shift from pilot projects to the mass adoption of autonomous transport. The momentum is building worldwide: Europe has already rolled out over 35 autonomous vehicle pilots, while the U.S. and China log more than 450 000 and 250 000 commercial trips per week, respectively. However, the report notes several roadblocks slowing down this progress. One such hurdle is the uncertainty surrounding legal liability and regulation, including in the areas of safety and security. The allocation of responsibility among suppliers, manufacturers, enterprise clients, and end users remains a major point of discussion.

Each market stakeholder sees the issue of ensuring the safety of autonomous vehicles differently. For automakers, it means taking responsibility for how a vehicle behaves on the road and for vetting their suppliers. For the suppliers themselves, it means designing security mechanisms directly into their solution architecture from day one and guaranteeing their adequacy. For insurance companies, it means completely overhauling their risk models to account for not just accidents, but also potential software glitches and cyberattacks. Ultimately, everyone agrees on one fundamental point: security must be a foundational feature of the vehicle — not an optional add-on.

Ensuring vehicle security in the modern era

For years, discussions around automotive safety focused strictly on functional safety. In other words, the goal was to ensure that vehicle systems operated correctly, and that risks associated with potential failures were fully mitigated or reduced to an acceptable level. The ISO 26262 standard “Road vehicles — Functional safety” helps address this very challenge, and serves as the baseline for the automotive industry.

However, the modern connected vehicle is a complex cyberphysical system that stores and processes massive amounts of data, including sensitive information. And this leads to the emergence of new basic needs. To draw an analogy with two levels of Maslow’s hierarchy of needs, a modern vehicle must:

• Satisfy the need for “esteem” — meaning it must securely and reliably store user profile data, such as account credentials, biometric data, payment details, and more.
• Satisfy the user’s cognitive needs — meaning it must provide secure internet connectivity, transmit vehicle telemetry, and send reminders for scheduled or emergency maintenance.

All of this means equipping vehicles with a wide array of interfaces — telematics, Bluetooth, Wi-Fi, cellular connectivity, OTA updates, and V2X — which opens the door to remote attacks. Therefore, it becomes necessary to ensure not only the functional security, but also the information security of the vehicle. As a result, specialized industry standards that help address automotive cybersecurity challenges have emerged in most countries. The key international standards are ISO/SAE 21434 “Road vehicles — Cybersecurity engineering”, UNECE R155, and UNECE R156.

China’s regulations are evolving too. In 2024, the country published the national standard GB 44495-2024 “Technical Requirements for Vehicle Cybersecurity”, which went into effect on January 1, 2026. The document introduces mandatory cybersecurity requirements for vehicles, including communications protection, security event management, threat monitoring, and secure vehicle interaction with external infrastructure.

Understanding and applying these standards is becoming absolutely critical. Research shows that cybersecurity risks are escalating daily, and their impact on functional safety can sometimes trigger far more dangerous incidents than an internal system failure. What happens if an attacker gains access to a self-driving truck’s remote-control system, or manages to reflash a critical electronic control unit during an unauthorized diagnostic session?

One of the key components for mitigating these scenarios is a security gateway, which isolates the vehicle’s architecture into different domains based on criticality, while providing secure routing, filtering, and traffic control. Developing this type of software solution is precisely what our team focuses on as we build the Kaspersky Automotive Secure Gateway based on KasperskyOS.

Why Kaspersky Automotive Secure Gateway?

The primary purpose of Kaspersky Automotive Secure Gateway (KASG) is to secure the vehicle’s CAN domain, since the CAN bus is used to transmit a vast number of critical control commands. This impacts nearly 80% of the electronic control units inside the car, which handle engine management, braking, body electronics, and more. Because of this, we utilize the Safety-Aware Cybersecurity approach — a unified architecture that accounts for both functional safety and cybersecurity requirements.

For example, standard End-to-End Protection (E2E) mechanisms are typically used to mitigate risks associated with dropped, out-of-order, or corrupted CAN messages. However, these mechanisms were not originally designed to counter targeted cyberattacks. If an attacker manages to construct a malicious frame that conforms to the required E2E format, the system may accept it as valid.

This introduces a new factor: it’s critical not only to verify that a message was delivered without errors, but also to ensure that it was actually generated by a trusted electronic control unit (ECU), and was not altered in transit. This is particularly vital for transmitting control commands — such as those sent to the vehicle’s braking system — or for implementing keyless entry (NFC) systems.

To address that challenge, Secure Onboard Communication (SecOC) mechanisms are integrated into the vehicle’s architecture. They use cryptographic methods to verify message authenticity and integrity, protecting the system against message spoofing and replay attacks. KASG successfully implements these mechanisms, which, in addition to message verification, perform the crucial function of centralized key management. This allows encryption keys to be distributed and updated from a single point within the vehicle, reducing both the cost and the processing load on the ECUs involved in SecOC-backed data exchange.

Automotive IDS

However, in complex systems, it’s no longer enough to apply security mechanisms only to individual messages or separate network segments. It’s essential to provide vehicle-wide monitoring and control, tracking behavioral anomalies, unusual cross-domain interactions, and unauthorized tampering attempts. In the IT domain, this is known as an Intrusion Detection System (IDS). These systems have been successfully adopted by the automotive industry as well.

At the same time, it’s important to realize that for a modern vehicle, an IDS is not a single magic point of data collection and analysis; the vehicle requires a distributed monitoring system. Monitoring is carried out at various architectural levels: within domains, at the individual controller level, and at network boundaries.

The security gateway becomes a critical monitoring point because all cross-domain interaction passes through. Additionally, the gateway provides visibility into data exchange across different segments of the vehicle network. Its job is to detect deviations from normal behavior and generate security events.

When it comes to the CAN domain monitoring implemented in KASG, the IDS looks at the following criteria for traffic analysis:

• Alignment of CAN message parameters (CAN ID, DLC) with their descriptions in the DBC specification.
• Frequency and periodicity of CAN messages.
• Allowable ranges for CAN signals.

In practice, however, an important limitation becomes clear: even with an onboard IDS, more context is required to determine the exact characteristics of an attack. Furthermore, when operating highly automated vehicles — where fleet-wide monitoring is essential — such isolated analysis becomes inherently insufficient.

Connecting a vehicle to an SIEM

Multi-object monitoring, data correlation, and data analysis can be efficiently handled externally — specifically in SIEM (Security Information and Event Management) systems, which are traditionally used in corporate and industrial cybersecurity operations centers. Therefore, utilizing a SIEM system fleet-wide is a logical step that makes it possible to:

• Collect security events from multiple vehicles.
• Correlate events over time and across contexts.
• Detect advanced and distributed attacks.
• Provide incident auditing and investigation.
• Respond to individual incidents and manage cyber-risks fleet-wide.

When integrating with external SIEM systems, several critical tasks must be addressed: ensuring a secure connection, tuning the security event transmission process, and establishing baseline rules for event processing and correlation. We are actively working through all of these challenges using our own SIEM system — Kaspersky Unified Monitoring and Analysis Platform — as a blueprint.

There are still many issues ahead that need to be resolved. This article covered only a fraction of the approaches currently used in KASG to ensure vehicle safety and security. Yet even this small part demonstrates that automotive security cannot be achieved by solving a single problem or applying a single mechanism. Achieving it requires an approach that enables methodical architecture development — balancing diverse requirements for vehicle functionality, security, and reliability.