Sooner or later, every company faces the need to upgrade its infrastructure — whether to accommodate expansion, optimize processes, or keep up with the latest trends in IT. When such a decision is made, company management typically thinks first and foremost about broad changes at the platform level — assuming that applications can simply be reinstalled and everything will work as before. And to a certain extent, that’s actually true. In an era when corporate security could be ensured solely by antivirus software on workstations, that would have worked; however, modern cyberthreats require protection at a fundamentally different level.

In this post, we explore why platform migration should be discussed with the security team as well, and why simply “installing a program” isn’t enough to ensure modern-day protection.

Security is no longer just a single program

In the past, securing endpoints was enough to prevent most attacks. In today’s environment, endpoint protection is just one layer of cybersecurity. A modern extended detection and response (XDR) solution isn’t a single application installed on a computer; it’s a set of components that work in conjunction. They provide protection for workstations and servers, event logging and storing, infrastructure-level threat detection mechanisms, investigation tools, automated response, reporting, and asset management. Each component serves a specific purpose and places different demands on the hardware and platform.

For the event storage system, disk speed is the most critical factor. In a large company, the security system generates millions of records per day, and all of them must be written quickly and then retrieved just as quickly when needed. The bottleneck here usually isn’t processor capabilities, but rather how fast the system can read and write data.

Threat detection requires computing power. The system compares events in real time and determines what can be a sign of an attack, and what is normal operational activity.

Response time is critical for investigation tools. When an analyst investigates an incident and pieces together what happened, they work in real time, and every second of waiting adds to the overall response time to the attack.

What does this mean? When a company switches platforms, it’s not enough to simply verify that the company’s existing cybersecurity solutions support the new architecture. The answer “yes, it’s supported” is too vague. It’s essential to clearly understand exactly which parts of the cybersecurity architecture are supported — starting from which version, and what is still under development.

What to ask before it’s too late

To avoid unexpected complications during implementation and operation, we recommend asking the right questions in advance — during the planning phase. Here are those questions:

Which specific components have been tested on the new platform?

The question shouldn’t be phrased as “Is the platform supported?”; the compatibility of each part of the system should be verified. Different components of a modern information-security solution operate under different rules, which is why their compatibility is tested separately. A one-word “yes” answer should raise a red flag: a reputable vendor will always provide a detailed response — including a list of components and any caveats (where applicable).

Will there be sufficient resources to handle the company’s workload?

“It will run” and “it will handle needed data volume” are two fundamentally different statements. The former is verified in a lab on a test bench; the latter depends on how many events specific infrastructure generates per day, and how long the company is required to retain them under regulatory or internal policies. It makes sense to ask the vendor for recommendations on calculating resources based on specific data volumes rather than relying on general minimum resource requirements when planning.

Is the security solution up to date?

It’s always important to clearly understand which version of the cybersecurity solution supports the new platform. It’s not uncommon for different parts of the infrastructure to be protected by different builds of the same solution. Sometimes this is because new features didn’t seem particularly critical; other times it’s because the IT security team was waiting for a convenient time to update so as not to disrupt business processes. If the security team won’t verify right away that all builds already support the new platform, the IT department may suddenly find itself having to make urgent changes to the migration schedule because updating the security solutions will require its own maintenance window and approvals. It’s better to find this out at the start of the project rather than deep into the process.

Are there any licensing restrictions?

Sometimes the availability of certain features depends not only on the product version but also on the specific licenses the company has purchased. It’s more cost-effective to clarify this during the design phase.

None of these questions require in-depth technical knowledge; a project manager can easily ask them. But when asked at the right time, they eliminate most of the unpleasant surprises that usually surface during the implementation of a new platform.

How do we help?

We’re constantly expanding the list of platforms supported by our solutions, and strive to describe their compatibility in as much detail as possible — like versions, component composition, and honest disclaimers where applicable. For example, the latest versions of Kaspersky NEXT XDR Expert and Kaspersky NEXT EDR Expert now support the Nutanix 7.3 hypervisor.

For companies planning to build their infrastructure on this platform (or migrate over to it) this means one thing: the compatibility issue goes from being a roadblock to being resolved. There’s no need to postpone securing the infrastructure until the migration is complete, or to deploy cybersecurity solutions in an untested configuration — cybersecurity is now integrated into the migration project on a par with other systems.

The full technical requirements for our security solutions are always available in the documentation; it’s always worth reviewing them before deployment schedules are finalized.

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.

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.