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.

To put it simply, the classic logic of a SIEM system works as follows: if event A occurs, followed by event B, this may be a sign of an attack, and an information security specialist should be notified. But in today’s environment, this simple scenario is increasingly failing. Just recently, our experts analyzed a high-profile incident: attackers compromised the update infrastructure of the popular Notepad++ software, and distributed malware via the update mechanism. It’s simply impossible to have rules in place in advance that are specifically designed to counter such scenarios.

The attacks themselves have become more sophisticated: attackers use legitimate tools, they attack through the supply chain by compromising software outside the corporate perimeter, stretch out their scenarios over time, and disguise their actions as normal activity. In other words, they do not “break into” the infrastructure; more often than not, they log in and use legitimate software. As a result, the classic fixed rules of the past either fail to trigger, or generate too many false alerts. This is what prompted the shift toward more flexible correlation scenarios.

Dynamically updated SIEM content

Correlation content today isn’t a static set of rules, but a process: it’s constantly evolving and adapting to current threats. In 2025 alone, we released 55 rule-package updates for different versions and languages of our Kaspersky SIEM system. In just one year, we added 10 new rule packs, as well as 250 detection rules and numerous improvements to existing content. This year, we’ve already added 43 new rules and refined another 63. In total, this amounts to over 850 rules covering a significant portion of the MITRE ATT&CK framework.

Kaspersky SIEM rules are written based on insights from our experts who analyze real-world, recent attacks: we primarily draw on the findings of our managed detection and response (MDR) service and our threat research. As a result, our rules cover scenarios — from reconnaissance to privilege escalation — that involve the latest approaches used by attackers. For example, we detect the use of new attack techniques such as ToolShell.

In addition to scheduled updates, the team regularly releases so-called emergency content — rule sets for rapid response to new and unexpected attack techniques. In February, for example, detection rules were released for authentication bypass in Fortinet products via the SSO mechanism: attackers used specially crafted SAML requests to gain access to systems without credentials.

From events to attack chains

Moreover, modern SIEM rules no longer describe individual events, but rather sequences of actions. Scenarios are built around the stages of an attack: from initial access, to privilege escalation and persistence. Kaspersky SIEM’s effectiveness is enhanced through integration with Kaspersky EDR and dedicated rule sets for Active Directory, which implement dozens of attack detection scenarios at various stages. This approach allows us to see not just individual signals, but the full picture.

Integration and internal visibility

Another way to improve the effectiveness of an SIEM system is to expand data sources. A classic SIEM aggregates events from different levels of the infrastructure: from logs to telemetry from endpoints and internal systems. In addition to this, our SIEM system includes specialized rule sets for our other solutions (Kaspersky Security Center, Kaspersky Security for Mail Groups, K Anti-Targeted Attack platform), which allow monitoring of administrator actions, authentication, and service status. As a result, the system becomes a tool not only for detecting attacks, but also for monitoring internal activity.

Overall, SIEM is no longer just a set of rules, but has evolved into a continuously updated detection system. Its effectiveness is determined not by the number of detections, but by their relevance, coherence, and how accurately they reflect the actual actions of attackers. Stay up to date regarding our Kaspersky Unified Monitoring and Analysis Platform (SIEM) on its official product page.

Over the past two months researchers have reported three vulnerabilities that can be exploited to bypass authentication in Fortinet products using the FortiCloud SSO mechanism. The first two – CVE-2025-59718 and CVE-2025-59719 – were found by the company’s experts during a code audit (although CVE-2025-59718 has already made it into CISA’s Known Exploited Vulnerabilities Catalog), while the third – CVE-2026-24858 – was identified directly during an investigation of unauthorized activity on devices. These vulnerabilities allow attackers with a FortiCloud account to log into various companies’ FortiOS, FortiManager, FortiAnalyzer, FortiProxy, and FortiWeb accounts if the SSO feature is enabled on the given device.

To protect companies that use both our Kaspersky Unified Monitoring and Analysis Platform and Fortinet devices, we’ve created a set of correlation rules that help detect this malicious activity. The rules are already available for customers to download from Kaspersky SIEM repository; the package name is: [OOTB] FortiCloud SSO abuse package – ENG.

Contents of the FortiCloud SSO abuse package

The package includes three groups of rules. They’re used to monitor the following:

• Indicators of compromise: source IP addresses, usernames, creation of a new account with specific names;
• critical administrator actions, such as logging in from a new IP address, creating a new account, logging in via SSO, logging in from a public IP address, exporting device configuration;
• suspicious activity: configuration export or account creation immediately after a suspicious login.

Rules marked “(info)” may potentially generate false positives, as events critical for monitoring authentication bypass attempts may be entirely legitimate. To reduce false positives, add IP addresses or accounts associated with legitimate administrative activity to the exceptions.

As new attack reports emerge, we plan to supplement the rules marked with “IOC” with new information.

Additional recommendations

We also recommend using rules from the FortiCloud SSO abuse package for retrospective analysis or threat hunting. Recommended analysis period: starting from December 2025.

For the detection rules to work correctly, you need to ensure that events from Fortinet devices are received in full and normalized correctly. We also recommend configuring data in the “Extra” field when normalizing events, as this field contains additional information that may need investigating.

Learn more about our Kaspersky Unified Monitoring and Analysis Platform at on the official solution page.

A significant number of modern incidents begin with account compromise. Since initial access brokers have become a full-fledged criminal industry, it’s become much easier for attackers to organize attacks on companies’ infrastructure by simply purchasing sets of employee passwords and logins. The widespread practice of using various remote access methods has made their task even easier. At the same time, the initial stages of such attacks often look like completely legitimate employee actions, and remain undetected by traditional security mechanisms for a long time.

Relying solely on account protection measures and password policies isn’t an option. There’s always a chance that attackers will get hold of employees’ credentials using various phishing attacks, infostealer malware, or simply through the carelessness of employees who reuse the same password for work and personal accounts and don’t pay much attention to leaks on third-party services.

As a result, to detect attacks on a company’s infrastructure, you need tools that can detect not only individual threat signatures, but also behavioral analysis systems that can detect deviations from normal user and system processes.

Using AI in SIEM to detect account compromise

As we mentioned in our previous post, to detect attacks involving account compromise, we equipped our Kaspersky Unified Monitoring and Analysis Platform SIEM system with a set of UEBA rules designed to detect anomalies in authentication processes, network activity, and the execution of processes on Windows-based workstations and servers. In the latest update, we continued to develop the system in the same direction, adding the use of AI approaches.

The system creates a model of normal user behavior during authentication, and tracks deviations from usual scenarios: atypical login times, unusual event chains, and anomalous access attempts. This approach allows SIEM to detect both authentication attempts with stolen credentials, and the use of already compromised accounts, including complex scenarios that may have gone unnoticed in the past.

Instead of searching for individual indicators, the system analyzes deviations from normal patterns. This allows for earlier detection of complex attacks while reducing the number of false positives, and significantly reduces the operational load on SOC teams.

Previously, when using UEBA rules to detect anomalies, it was necessary to create several rules that performed preliminary work and generated additional lists in which intermediate data was stored. Now, in the new version of SIEM with a new correlator, it’s possible to detect account hijacking using a single specialized rule.

Other updates in the Kaspersky Unified Monitoring and Analysis Platform

The more complex the infrastructure and the greater the volume of events, the more critical the requirements for platform performance, access management flexibility, and ease of daily operation become. A modern SIEM system must not only accurately detect threats, but also remain “resilient” without the need to constantly upgrade equipment and rebuild processes. Therefore, in version 4.2, we’ve taken another step toward making the platform more practical and adaptable. The updates affect the architecture, detection mechanisms, and user experience.

Addition of flexible roles and granular access control

One of the key innovations in the new version of SIEM is a flexible role model. Now customers can create their own roles for different system users, duplicate existing ones, and customize a set of access rights for the tasks of specific specialists. This allows for a more precise differentiation of responsibilities among SOC analysts, administrators, and managers, reduces the risk of excessive privileges, and better reflects the company’s internal processes in the SIEM settings.

New correlator and, as a result, increased platform stability

In release 4.2, we introduced a beta version of a new correlation engine (2.0). It processes events faster, and requires fewer hardware resources. For customers, this means:

• stable operation under high loads;
• the ability to process large amounts of data without the need for urgent infrastructure expansion;
• more predictable performance.

TTP coverage according to the MITRE ATT&CK matrix

We’re also systematically continuing to expand our coverage of the MITRE ATT&CK matrix of techniques, tactics, and procedures: today, Kaspersky SIEM covers more than 60% of the entire matrix. Detection rules are regularly updated and accompanied by response recommendations. This helps customers understand which attack scenarios are already under control, and plan their defense development based on a generally accepted industry model.

Other improvements

Version 4.2 also introduces the ability to back up and restore events, as well as export data to secure archives with integrity control, which is especially important for investigations, audits, and regulatory compliance. Background search queries have been implemented for the convenience of analysts. Now, complex and resource-intensive searches can be run in the background without affecting priority tasks. This speeds up the analysis of large data sets.

We continue to regularly update Kaspersky SIEM, expanding detection capabilities, improving architecture, and adding AI functionality so that the platform best meets the real-world conditions of information security teams, and helps not only to respond to incidents, but also to build a sustainable protection model for the future. Follow the updates to our SIEM system, the Kaspersky Unified Monitoring and Analysis Platform, on the official product page.