Strengthening Cyber Resilience Across Northern Europe
Across Northern Europe, organizations are redefining how they work, innovate and compete. From the Netherlands’ smart logistics hubs to Finland’s AI-driven public services and the UK’s digital-first financial sector, this region is setting the global pace for responsible, data-driven transformation.
Yet behind this progress lies a growing challenge: security complexity.
According to the IBM Institute for Business Value (IBV), the average enterprise now manages 83 security tools from 29 vendors, leading to fragmented visibility, slower responses and rising risk exposure. In contrast, 96% of organizations that have unified their security platforms say they now view cybersecurity as a driver of business value, not a barrier to it.
That’s where the IBM and Palo Alto Networks partnership is making an impact. Together they are helping Northern European enterprises simplify, secure and accelerate their digital transformation with unified, AI-powered cybersecurity.
From Fragmented Tools to an Integrated Security Foundation
Northern Europe’s strength lies in its strong culture of trust and transparency, advanced digital infrastructure, as well as progressive regulatory frameworks. But as the EU NIS2 Directive, DORA and the AI Act come into force, achieving both compliance and cyber resilience require board-level oversight.
IBM and Palo Alto Networks are helping organizations lead this change. They combine IBM’s deep consulting and industry expertise with Palo Alto Networks market-leading security platforms and solutions, including Cortex XSIAM®, Cortex® Cloud™ and Prisma® Access. This integrated approach protects innovation, enables compliance efforts, and enhances operational efficiency.
The partnership not only secures organizational estates, but empowers faster decision-making, measurable ROI and sustainable transformation.
Five Capabilities Powering Secure Transformation
Organizations want to strengthen cyber resilience without slowing innovation. IBM and Palo Alto Networks help them do just that, through five connected capabilities that turn complex challenges into measurable outcomes.
1. Unified Security Platform: Simplify and See More
The Challenge: Too many tools, too little visibility.
The Reality: Most enterprises run more than 80 security tools from nearly 30 vendors.
By consolidating with IBM’s unified security approach and the Palo Alto Networks platforms, organizations are cutting total product costs by up to 19.4% and gaining a single, trusted view of their security posture.
The Outcome: Streamlined operations, faster decision-making and improved compliance enablement for frameworks like NIS2, all while reducing the energy footprint of sprawling infrastructure.
2. Cloud Security: Innovate Without the Risk
The Challenge: Cloud transformation introduces new risks and blind spots.
The Reality: 82% of breaches now involve cloud data, and nearly 40% span multiple environments.
IBM and Palo Alto Networks secure the journey from code to cloud to SOC, embedding security early in design and automating protection across environments. IBM’s AI deployment accelerators slash rollout time, while Cortex Cloud™ provides continuous visibility and compliance enablement.
The Outcome: Faster innovation with cloud operations that are secure by design, from day one.
3. Security for AI: Build Trust in Every Algorithm
The Challenge: Rapid AI adoption without consistent oversight.
The Reality: 82% of executives say trustworthy AI is critical to success, yet few have the controls in place.
IBM and Palo Alto Networks help organizations govern and protect their use of AI, securing data pipelines, scanning models and preventing adversarial attacks.
The Outcome: Confident AI adoption aligned to the EU AI Act requirements, where innovation can move forward without compromising data integrity or customer trust.
4. Security Service Edge (SSE): Connect People Securely, Anywhere
The Challenge: Hybrid work models demand reliable secure access everywhere.
The Reality: Human risk, not technology alone, is now the dominant factor in breaches, with 95% of data breaches involving human error, such as insider missteps, credential misuse and careless actions, underscoring how remote and hybrid workers’ behaviors significantly expand exposure.
With Palo Alto Networks Prisma Access and IBM’s consulting expertise, enterprises across Europe are simplifying secure connectivity through a unified zero trust framework.
The Outcome: Simpler, more efficient policy management and stronger protection across hybrid environments, where risk exposure is reduced, visibility is enhanced, and a seamless user experience is delivered.
The Challenge: SOC teams are overwhelmed, missing as many as two thirds of daily alerts due to alert fatigue and limited resources.
The Reality: Over half of organizations report they can’t hire or retain enough skilled analysts, leaving gaps in coverage and consistency.
By combining IBM’s Autonomous Threat Operations Machine (ATOM) with Palo Alto Networks Cortex XSIAM, organizations can streamline and automate core SOC workflows, reducing response times by more than half and enabling analysts to focus on the most critical incidents.
The Outcome: Faster detection, shorter resolution times and a more proactive, resilient security posture. AI-driven automation not only boosts accuracy but can also shorten breach lifecycles by more than 100 days, helping teams defend smarter.
Built for Northern Europe’s Next Decade of Growth
As Northern Europe is a leader in digital innovation, the stakes for cybersecurity have never been higher. Trust, transparency and compliance are not simply checkboxes, but are competitive advantages.
IBM and Palo Alto Networks are helping organizations across the region turn that reality into action. By uniting AI-powered automation, cloud-native security and deep industry expertise, they’re enabling enterprises to move faster, reduce complexity and strengthen resilience. This is achieved while enabling alignment with the region’s evolving frameworks, such as NIS2, DORA and the EU AI Act.
To stay ahead, security can no longer be a fragmented layer sitting outside transformation; it must be the foundation that powers it. With IBM and Palo Alto Networks, organizations gain a unified security platform built for the next decade of digital progress – one that protects every connection, every line of code and every moment of innovation.
Resilient. Compliant. Unified.
That’s the future of cybersecurity in Northern Europe.
Modernizing Vulnerability Sharing for a New Class of Threats
In cybersecurity, vulnerability information sharing frameworks have long assumed that conventional threats exploit flaws in software or systems, and they can be resolved with patches or configuration updates. AI and machine learning (ML) models upend that premise as adversarial attacks, like poisoning and evasion, target the unique way AI models process information. Consequently, the risks for AI systems include tactics like model poisoning (from evasion attacks) in datasets and training, which are not conventional software vulnerabilities. These new vulnerabilities fall outside the scope of traditional cybersecurity taxonomies like the Common Vulnerabilities and Exposures (CVE) Program.
There is a need to bridge the gap between the existing cybersecurity vulnerability sharing structure and burgeoning efforts to catalog security risks to AI systems. Provisions in the White House AI Action Plan, which Palo Alto Networks supports, call for the creation of an AI Information Sharing and Analysis Center (AI-ISAC), reinforcing the importance of addressing that disconnect. This integration is essential, as leveraging the existing, widely adopted cybersecurity infrastructure will be the fastest path to ensuring these new standards are accepted and operationalized.
Established Construct for Vulnerability Management and Disclosure
The global cybersecurity community relies on a mature infrastructure for sharing standardized vulnerability intelligence. Central to this ecosystem is the CVE List, established in 1999 as the authoritative catalog of cybersecurity vulnerabilities. Through CVE IDs and a network of CVE Numbering Authorities (CNAs), this framework enables consistent vulnerability documentation and disclosure.
While this infrastructure has served the cybersecurity community effectively for over two decades, it was designed around traditional threat models that AI systems substantially upend. Attacks on AI systems represent a critical departure from traditional cybersecurity threats as they operate insidiously, subtly corrupting core reasoning processes, causing persistent, systemic failures, some of which only become evident over time. Most traditional cybersecurity tools are not equipped to recognize those breakdowns because they assume deterministic behavior and rules-based logic. AI systems defy those assumptions because AI is probabilistic, not deterministic. Consequently, attacks on AI models may remain hidden for extended periods.
Unlike traditional cybersecurity threats that target code, adversarial AI attacks target the underlying data and algorithms that govern how AI systems learn, reason and make decisions. Consider the following predominant adversarial attack methodologies on machine learning:
Poisoning attacks inject malicious data into training datasets, corrupting the model's learning process and creating deliberate vulnerabilities or degraded performance.
Inference-related attacks exploit model outputs to extract sensitive information or learn about its training data. This includes model inversion, which reconstructs sensitive data from the model's outputs, as well as membership inference, which identifies whether specific data points were used in training.
The expansion of existing security frameworks and programs is necessary to cover the enumeration, disclosure and downstream management of security risks to AI systems.
Advancing AI Security Through the AI Action Plan
In July, the Administration unveiled the AI Action Plan, an innovation-first framework balancing AI advancement with security imperatives. The Plan prioritizes Secure-by-Design AI technologies and applications, strengthened critical infrastructure cybersecurity and protection of commercial and government AI innovations.
Notably, it recommends establishing an AI Information Sharing and Analysis Center (AI-ISAC) to facilitate threat intelligence sharing across U.S. critical infrastructure sectors and encourages sharing known AI vulnerabilities, “tak[ing] advantage of existing cyber vulnerability sharing mechanisms.” These provisions affirm that AI security underpins American leadership in the field and, where possible, should be built upon existing frameworks.
Redefining Boundaries for AI Threats
To position the CVE Program for the AI-driven future, Palo Alto Networks is engaging directly with industry and program stakeholders to chart the path forward. Traditionally, the CVE Program serves as an ecosystem-wide central warning system. It provides a unified source of truths for security risks. A security risk catalog and identification system are needed for AI systems, as they currently fall outside the traditional scope of the CVE Program that has focused exclusively on vulnerabilities rather than on malicious components. The historical aperture of the current CVE Program excludes harmful artifacts, such as backdoored AI models or poisoned datasets, which represent fundamentally different attack vectors, in turn creating security blind spots.
Securing AI’s Promise
The United States leads in AI innovation and must equally lead in securing it. As momentum builds behind the AI Action Plan and the establishment of the AI-ISAC, we have a critical window to shape information sharing frameworks of the future. The goal is to ensure that cybersecurity and AI security infrastructure advance in unison with the technology itself. Integrating new AI vulnerability standards into trusted frameworks like the CVE Program aligns with industry focus and needs. Through proactive, coordinated action, we can unlock AI’s full promise while safeguarding the models that are embedded in the critical systems on which our nation depends.
Simplifying Cloud Network Security When securing cloud landscapes, it’s critically important to eliminate any downtime or performance degradation that firewall or gateway implementation may cause. To address these challenges, Check Point is proud to announce our support for Google Cloud Network Security Integration. This innovation creates a nondisruptive approach to cloud firewall deployment, increasing network security without negatively impacting performance. Scaling Hybrid Cloud Network Security Network security and performance are critical to any organization, but this is especially true for industries under heavy regulations like financial services, healthcare, and government. So over time these organizations gain comfort, expertise, and confidence […]
A SIEM is a complex system offering broad and flexible threat detection capabilities. Due to its complexity, its effectiveness heavily depends on how it is configured and what data sources are connected to it. A one-time SIEM setup during implementation is not enough: both the organization’s infrastructure and attackers’ techniques evolve over time. To operate effectively, the SIEM system must reflect the current state of affairs.
We provide customers with services to assess SIEM effectiveness, helping to identify issues and offering options for system optimization. In this article, we examine typical SIEM operational pitfalls and how to address them. For each case, we also include methods for independent verification.
This material is based on an assessment of Kaspersky SIEM effectiveness; therefore, all specific examples, commands, and field names are taken from that solution. However, the assessment methodology, issues we identified, and ways to enhance system effectiveness can easily be extrapolated to any other SIEM.
Methodology for assessing SIEM effectiveness
The primary audience for the effectiveness assessment report comprises the SIEM support and operation teams within an organization. The main goal is to analyze how well the usage of SIEM aligns with its objectives. Consequently, the scope of checks can vary depending on the stated goals. A standard assessment is conducted across the following areas:
Composition and scope of connected data sources
Coverage of data sources
Data flows from existing sources
Correctness of data normalization
Detection logic operability
Detection logic accuracy
Detection logic coverage
Use of contextual data
SIEM technical integration into SOC processes
SOC analysts’ handling of alerts in the SIEM
Forwarding of alerts, security event data, and incident information to other systems
Deployment architecture and documentation
At the same time, these areas are examined not only in isolation but also in terms of their potential influence on one another. Here are a couple of examples illustrating this interdependence:
Issues with detection logic due to incorrect data normalization. A correlation rule with the condition deviceCustomString1 not contains <string> triggers a large number of alerts. The detection logic itself is correct: the specific event and the specific field it targets should not generate a large volume of data matching the condition. Our review revealed the issue was in the data ingested by the SIEM, where incorrect encoding caused the string targeted by the rule to be transformed into a different one. Consequently, all events matched the condition and generated alerts.
When analyzing coverage for a specific source type, we discovered that the SIEM was only monitoring 5% of all such sources deployed in the infrastructure. However, extending that coverage would increase system load and storage requirements. Therefore, besides connecting additional sources, it would be necessary to scale resources for specific modules (storage, collectors, or the correlator).
The effectiveness assessment consists of several stages:
Collect and analyze documentation, if available. This allows assessing SIEM objectives, implementation settings (ideally, the deployment settings at the time of the assessment), associated processes, and so on.
Interview system engineers, analysts, and administrators. This allows assessing current tasks and the most pressing issues, as well as determining exactly how the SIEM is being operated. Interviews are typically broken down into two phases: an introductory interview, conducted at project start to gather general information, and a follow-up interview, conducted mid-project to discuss questions arising from the analysis of previously collected data.
Gather information within the SIEM and then analyze it. This is the most extensive part of the assessment, during which Kaspersky experts are granted read-only access to the system or a part of it to collect factual data on its configuration, detection logic, data flows, and so on.
The assessment produces a list of recommendations. Some of these can be implemented almost immediately, while others require more comprehensive changes driven by process optimization or a transition to a more structured approach to system use.
Issues arising from SIEM operations
The problems we identify during a SIEM effectiveness assessment can be divided into three groups:
Performance issues, meaning operational errors in various system components. These problems are typically resolved by technical support, but to prevent them, it is worth periodically checking system health status.
Efficiency issues – when the system functions normally but seemingly adds little value or is not used to its full potential. This is usually due to the customer using the system capabilities in a limited way, incorrectly, or not as intended by the developer.
Detection issues – when the SIEM is operational and continuously evolving according to defined processes and approaches, but alerts are mostly false positives, and the system misses incidents. For the most part, these problems are related to the approach taken in developing detection logic.
Key observations from the assessment
Event source inventory
When building the inventory of event sources for a SIEM, we follow the principle of layered monitoring: the system should have information about all detectable stages of an attack. This principle enables the detection of attacks even if individual malicious actions have gone unnoticed, and allows for retrospective reconstruction of the full attack chain, starting from the attackers’ point of entry.
Problem: During effectiveness assessments, we frequently find that the inventory of connected source types is not updated when the infrastructure changes. In some cases, it has not been updated since the initial SIEM deployment, which limits incident detection capabilities. Consequently, certain types of sources remain completely invisible to the system.
We have also encountered non-standard cases of incomplete source inventory. For example, an infrastructure contains hosts running both Windows and Linux, but monitoring is configured for only one family of operating systems.
How to detect: To identify the problems described above, determine the list of source types connected to the SIEM and compare it against what actually exists in the infrastructure. Identifying the presence of specific systems in the infrastructure requires an audit. However, this task is one of the most critical for many areas of cybersecurity, and we recommend running it on a periodic basis.
We have compiled a reference sheet of system types commonly found in most organizations. Depending on the organization type, infrastructure, and threat model, we may rearrange priorities. However, a good starting point is as follows:
High Priority – sources associated with:
Remote access provision
External services accessible from the internet
External perimeter
Endpoint operating systems
Information security tools
Medium Priority – sources associated with:
Remote access management within the perimeter
Internal network communication
Infrastructure availability
Virtualization and cloud solutions
Low Priority – sources associated with:
Business applications
Internal IT services
Applications used by various specialized teams (HR, Development, PR, IT, and so on)
Monitoring data flow from sources
Regardless of how good the detection logic is, it cannot function without telemetry from the data sources.
Problem: The SIEM core is not receiving events from specific sources or collectors. Based on all assessments conducted, the average proportion of collectors that are configured with sources but are not transmitting events is 38%. Correlation rules may exist for these sources, but they will, of course, never trigger. It is also important to remember that a single collector can serve hundreds of sources (such as workstations), so the loss of data flow from even one collector can mean losing monitoring visibility for a significant portion of the infrastructure.
How to detect: The process of locating sources that are not transmitting data can be broken down into two components.
Checking collector health. Find the status of collectors (see the support website for the steps to do this in Kaspersky SIEM) and identify those with a status of Offline, Stopped, Disabled, and so on.
Checking the event flow. In Kaspersky SIEM, this can be done by gathering statistics using the following query (counting the number of events received from each collector over a specific time period):
SELECT count(ID), CollectorID, CollectorName FROM `events` GROUP BY CollectorID, CollectorName ORDER BY count(ID)
It is essential to specify an optimal time range for collecting these statistics. Too large a range can increase the load on the SIEM, while too small a range may provide inaccurate information for a one-time check – especially for sources that transmit telemetry relatively infrequently, say, once a week. Therefore, it is advisable to choose a smaller time window, such as 2–4 days, but run several queries for different periods in the past.
Additionally, for a more comprehensive approach, it is recommended to use built-in functionality or custom logic implemented via correlation rules and lists to monitor event flow. This will help automate the process of detecting problems with sources.
Event source coverage
Problem: The system is not receiving events from all sources of a particular type that exist in the infrastructure. For example, the company uses workstations and servers running Windows. During SIEM deployment, workstations are immediately connected for monitoring, while the server segment is postponed for one reason or another. As a result, the SIEM receives events from Windows systems, the flow is normalized, and correlation rules work, but an incident in the unmonitored server segment would go unnoticed.
How to detect: Below are query variations that can be used to search for unconnected sources.
SELECT count(distinct, DeviceAddress), DeviceVendor, DeviceProduct FROM events GROUP BY DeviceVendor, DeviceProduct ORDER BY count(ID)
SELECT count(distinct, DeviceHostName), DeviceVendor, DeviceProduct FROM events GROUP BY DeviceVendor, DeviceProduct ORDER BY count(ID)
We have split the query into two variations because, depending on the source and the DNS integration settings, some events may contain either a DeviceAddress or DeviceHostName field.
These queries will help determine the number of unique data sources sending logs of a specific type. This count must be compared against the actual number of sources of that type, obtained from the system owners.
Retaining raw data
Raw data can be useful for developing custom normalizers or for storing events not used in correlation that might be needed during incident investigation. However, careless use of this setting can cause significantly more harm than good.
Problem: Enabling the Keep raw event option effectively doubles the event size in the database, as it stores two copies: the original and the normalized version. This is particularly critical for high-volume collectors receiving events from sources like NetFlow, DNS, firewalls, and others. It is worth noting that this option is typically used for testing a normalizer but is often forgotten and left enabled after its configuration is complete.
How to detect: This option is applied at the normalizer level. Therefore, it is necessary to review all active normalizers and determine whether retaining raw data is required for their operation.
Normalization
As with the absence of events from sources, normalization issues lead to detection logic failing, as this logic relies on finding specific information in a specific event field.
Problem: Several issues related to normalization can be identified:
The event flow is not being normalized at all.
Events are only partially normalized – this is particularly relevant for custom, non-out-of-the-box normalizers.
The normalizer being used only parses headers, such as syslog_headers, placing the entire event body into a single field, this field most often being Message.
An outdated default normalizer is being used.
How to detect: Identifying normalization issues is more challenging than spotting source problems due to the high volume of telemetry and variety of parsers. Here are several approaches to narrowing the search:
First, check which normalizers supplied with the SIEM the organization uses and whether their versions are up to date. In our assessments, we frequently encounter auditd events being normalized by the outdated normalizer, Linux audit and iptables syslog v2 for Kaspersky SIEM. The new normalizer completely reworks and optimizes the normalization schema for events from this source.
Execute the query:
SELECT count(ID), DeviceProduct, DeviceVendor, CollectorName FROM `events` GROUP BY DeviceProduct, DeviceVendor, CollectorName ORDER BY count(ID)
This query gathers statistics on events from each collector, broken down by the DeviceVendor and DeviceProduct fields. While these fields are not mandatory, they are present in almost any normalization schema. Therefore, their complete absence or empty values may indicate normalization issues. We recommend including these fields when developing custom normalizers.
To simplify the identification of normalization problems when developing custom normalizers, you can implement the following mechanism. For each successfully normalized event, add a Name field, populated from a constant or the event itself. For a final catch-all normalizer that processes all unparsed events, set the constant value: Name = unparsed event. This will later allow you to identify non-normalized events through a simple search on this field.
Detection logic coverage
Collected events alone are, in most cases, only useful for investigating an incident that has already been identified. For a SIEM to operate to its full potential, it requires detection logic to be developed to uncover probable security incidents.
Problem: The mean correlation rule coverage of sources, determined across all our assessments, is 43%. While this figure is only a ballpark figure – as different source types provide different information – to calculate it, we defined “coverage” as the presence of at least one correlation rule for a source. This means that for more than half of the connected sources, the SIEM is not actively detecting. Meanwhile, effort and SIEM resources are spent on connecting, maintaining, and configuring these sources. In some cases, this is formally justified, for instance, if logs are only needed for regulatory compliance. However, this is an exception rather than the rule.
We do not recommend solving this problem by simply not connecting sources to the SIEM. On the contrary, sources should be connected, but this should be done concurrently with the development of corresponding detection logic. Otherwise, it can be forgotten or postponed indefinitely, while the source pointlessly consumes system resources.
How to detect: This brings us back to auditing, a process that can be greatly aided by creating and maintaining a register of developed detection logic. Given that not every detection logic rule explicitly states the source type from which it expects telemetry, its description should be added to this register during the development phase.
If descriptions of the correlation rules are not available, you can refer to the following:
The name of the detection logic. With a standardized approach to naming correlation rules, the name can indicate the associated source or at least provide a brief description of what it detects.
The use of fields within the rules, such as DeviceVendor, DeviceProduct (another argument for including these fields in the normalizer), Name, DeviceAction, DeviceEventCategory, DeviceEventClassID, and others. These can help identify the actual source.
Excessive alerts generated by the detection logic
One criterion for correlation rules effectiveness is a low false positive rate.
Problem: Detection logic generates an abnormally high number of alerts that are physically impossible to process, regardless of the size of the SOC team.
How to detect: First and foremost, detection logic should be tested during development and refined to achieve an acceptable false positive rate. However, even a well-tuned correlation rule can start producing excessive alerts due to changes in the event flow or connected infrastructure. To identify these rules, we recommend periodically running the following query:
SELECT count(ID), Name FROM `events` WHERE Type = 3 GROUP BY Name ORDER BY count(ID)
In Kaspersky SIEM, a value of 3 in the Type field indicates a correlation event.
Subsequently, for each identified rule with an anomalous alert count, verify the correctness of the logic it uses and the integrity of the event stream on which it triggered.
Depending on the issue you identify, the solution may involve modifying the detection logic, adding exceptions (for example, it is often the case that 99% of the spam originates from just 1–5 specific objects, such as an IP address, a command parameter, or a URL), or adjusting event collection and normalization.
Lack of integration with indicators of compromise
SIEM integrations with other systems are generally a critical part of both event processing and alert enrichment. In at least one specific case, their presence directly impacts detection performance: integration with technical Threat Intelligence data or IoCs (indicators of compromise).
A SIEM allows conveniently checking objects against various reputation databases or blocklists. Furthermore, there are numerous sources of this data that are ready to integrate natively with a SIEM or require minimal effort to incorporate.
Problem: There is no integration with TI data.
How to detect: Generally, IoCs are integrated into a SIEM at the system configuration level during deployment or subsequent optimization. The use of TI within a SIEM can be implemented at various levels:
At the data source level. Some sources, such as NGFWs, add this information to events involving relevant objects.
At the SIEM native functionality level. For example, Kaspersky SIEM integrates with CyberTrace indicators, which add object reputation information at the moment of processing an event from a source.
At the detection logic level. Information about IoCs is stored in various active lists, and correlation rules match objects against these to enrich the event.
Furthermore, TI data does not appear in a SIEM out of thin air. It is either provided by external suppliers (commercially or in an open format) or is part of the built-in functionality of the security tools in use. For instance, various NGFW systems can additionally check the reputation of external IP addresses or domains that users are accessing. Therefore, the first step is to determine whether you are receiving information about indicators of compromise and in what form (whether external providers’ feeds have been integrated and/or the deployed security tools have this capability). It is worth noting that receiving TI data only at the security tool level does not always cover all types of IoCs.
If data is being received in some form, the next step is to verify that the SIEM is utilizing it. For TI-related events coming from security tools, the SIEM needs a correlation rule developed to generate alerts. Thus, checking integration in this case involves determining the capabilities of the security tools, searching for the corresponding events in the SIEM, and identifying whether there is detection logic associated with these events. If events from the security tools are absent, the source audit configuration should be assessed to see if the telemetry type in question is being forwarded to the SIEM at all. If normalization is the issue, you should assess parsing accuracy and reconfigure the normalizer.
If TI data comes from external providers, determine how it is processed within the organization. Is there a centralized system for aggregating and managing threat data (such as CyberTrace), or is the information stored in, say, CSV files?
In the former case (there is a threat data aggregation and management system) you must check if it is integrated with the SIEM. For Kaspersky SIEM and CyberTrace, this integration is handled through the SIEM interface. Following this, SIEM event flows are directed to the threat data aggregation and management system, where matches are identified and alerts are generated, and then both are sent back to the SIEM. Therefore, checking the integration involves ensuring that all collectors receiving events that may contain IoCs are forwarding those events to the threat data aggregation and management system. We also recommend checking if the SIEM has a correlation rule that generates an alert based on matching detected objects with IoCs.
In the latter case (threat information is stored in files), you must confirm that the SIEM has a collector and normalizer configured to load this data into the system as events. Also, verify that logic is configured for storing this data within the SIEM for use in correlation. This is typically done with the help of lists that contain the obtained IoCs. Finally, check if a correlation rule exists that compares the event flow against these IoC lists.
As the examples illustrate, integration with TI in standard scenarios ultimately boils down to developing a final correlation rule that triggers an alert upon detecting a match with known IoCs. Given the variety of integration methods, creating and providing a universal out-of-the-box rule is difficult. Therefore, in most cases, to ensure IoCs are connected to the SIEM, you need to determine if the company has developed that rule (the existence of the rule) and if it has been correctly configured. If no correlation rule exists in the system, we recommend creating one based on the TI integration methods implemented in your infrastructure. If a rule does exist, its functionality must be verified: if there are no alerts from it, analyze its trigger conditions against the event data visible in the SIEM and adjust it accordingly.
The SIEM is not kept up to date
For a SIEM to run effectively, it must contain current data about the infrastructure it monitors and the threats it’s meant to detect. Both elements change over time: new systems and software, users, security policies, and processes are introduced into the infrastructure, while attackers develop new techniques and tools. It is safe to assume that a perfectly configured and deployed SIEM system will no longer be able to fully see the altered infrastructure or the new threats after five years of running without additional configuration. Therefore, practically all components – event collection, detection, additional integrations for contextual information, and exclusions – must be maintained and kept up to date.
Furthermore, it is important to acknowledge that it is impossible to cover 100% of all threats. Continuous research into attacks, development of detection methods, and configuration of corresponding rules are a necessity. The SOC itself also evolves. As it reaches certain maturity levels, new growth opportunities open up for the team, requiring the utilization of new capabilities.
Problem: The SIEM has not evolved since its initial deployment.
How to detect: Compare the original statement of work or other deployment documentation against the current state of the system. If there have been no changes, or only minimal ones, it is highly likely that your SIEM has areas for growth and optimization. Any infrastructure is dynamic and requires continuous adaptation.
Other issues with SIEM implementation and operation
In this article, we have outlined the primary problems we identify during SIEM effectiveness assessments, but this list is not exhaustive. We also frequently encounter:
Mismatch between license capacity and actual SIEM load. The problem is almost always the absence of events from sources, rather than an incorrect initial assessment of the organization’s needs.
Lack of user rights management within the system (for example, every user is assigned the administrator role).
Poor organization of customizable SIEM resources (rules, normalizers, filters, and so on). Examples include chaotic naming conventions, non-optimal grouping, and obsolete or test content intermixed with active content. We have encountered confusing resource names like [dev] test_Add user to admin group_final2.
Use of out-of-the-box resources without adaptation to the organization’s infrastructure. To maximize a SIEM’s value, it is essential at a minimum to populate exception lists and specify infrastructure parameters: lists of administrators and critical services and hosts.
Disabled native integrations with external systems, such as LDAP, DNS, and GeoIP.
Generally, most issues with SIEM effectiveness stem from the natural degradation (accumulation of errors) of the processes implemented within the system. Therefore, in most cases, maintaining effectiveness involves structuring these processes, monitoring the quality of SIEM engagement at all stages (source onboarding, correlation rule development, normalization, and so on), and conducting regular reviews of all system components and resources.
Conclusion
A SIEM is a powerful tool for monitoring and detecting threats, capable of identifying attacks at various stages across nearly any point in an organization’s infrastructure. However, if improperly configured and operated, it can become ineffective or even useless while still consuming significant resources. Therefore, it is crucial to periodically audit the SIEM’s components, settings, detection rules, and data sources.
If a SOC is overloaded or otherwise unable to independently identify operational issues with its SIEM, we offer Kaspersky SIEM platform users a service to assess its operation. Following the assessment, we provide a list of recommendations to address the issues we identify. That being said, it is important to clarify that these are not strict, prescriptive instructions, but rather highlight areas that warrant attention and analysis to improve the product’s performance, enhance threat detection accuracy, and enable more efficient SIEM utilization.
This report describes a phishing campaign in which attackers impersonate legitimate Google generated messages by abusing Google Cloud Application Integration to distribute malicious emails that appear to originate from trusted Google infrastructure. The emails mimic routine enterprise notifications such as voicemail alerts and file access or permission requests, making them appear normal and trustworthy to recipients. In this incident, attackers sent 9,394 phishing emails targeting approximately 3,200 customers over the past 14 days. All messages were sent from the legitimate Google address noreply-application-integration@google.com, which significantly increased their credibility and likelihood of reaching end users’ inboxes. Method of attack Based on […]
Login
