The Traditional SIEM-Centric TDIR Model

In the traditional model, the SIEM is tasked with:

1. Detection System: Collecting granular events from various data sources (like identity providers) and applying detection logic (rules, ML models) to identify potential threats. For example, looking at simple authentication events to generate an alert for suspicious activity. (SIEM as a detection system)

2. Consolidation and Aggregation System: Collecting alerts generated by other security solutions (EDR, email security, IDP) and correlating them into a unified attack chain or case. This provides investigators with crucial context—for instance, connecting a phishing email alert, a suspicious URL access, and a subsequent malware execution into a single, comprehensive investigation case.

3. Log Management and Data Retention System: Maintaining all granular events and alerts for long periods, acting as a single source of truth for analysts performing investigations and threat hunting. (SIEM as log management, data retention system)

The appeal of this model is its centralization of signals, which naturally enables all three use cases and encourages the idea of centralized investigation.

This centralized position made the SIEM a highly attractive tool, yet having all these functions bundled together has often led to the tool becoming bloated, expensive, and complex to maintain, rarely delivering good results across all use cases simultaneously. Many organizations still struggle with partial implementations, driving a search for a more flexible, cost-effective TDIR pattern.

The Critical Role of Detection Architecture

The trend of SIEMs evolving into primarily alert aggregators underscores the importance of “detection architecture”—a critical planning step that precedes detection engineering.

A robust detection architecture requires a good understanding of how every piece of your environment—including different threat categories and technologies—will be covered for detection.

• Specialized Tools: Certain threats and environments are best covered by specialized tools (e.g., XDR/EDR for endpoints, CNAPP/CSPM for cloud environments). These tools handle the detection logic locally and send resulting alerts downstream.

• Centralized Telemetry: Other systems lacking specialized detection capabilities funnel their granular telemetry into a centralized system (historically the SIEM, often with a UEBA component) where custom detection logic is applied.

This is a multidimensional puzzle every organization must assemble according to its unique needs. However, the outcome is clear: the SIEM will almost never be entirely responsible for detection.

This reality forces us to focus on the downstream TDIR architecture: Where should all the alerts—both from specialized tools and the SIEM itself—go next?

• Option A: Enforce all alerts getting into the SIEM for an additional layer of contextualization and correlation.

• Option B: Send all individual alerts, from the SIEM and from other sources, downstream directly to an investigation engine, such as an AI-SOC solution.

The Emerging Decentralized TDIR Pattern

The decentralized model embraces Option B, allowing for a more agile and cost-effective TDIR architecture:

• Distributed Detections: Detection logic is run where the data originates (in specialized security tools or the SIEM for niche/custom needs).

• Centralized Investigation Engine: Individual alerts are sent directly to an AI-SOC solution. This tool becomes the hub for performing or supporting the investigation. Connecting individual alerts related to the same threat happens at investigation time.

• Data-on-Demand: The AI-SOC queries the necessary security and infrastructure systems at investigation time to collect additional data and context. This key shift eliminates the massive, costly, and often unnecessary need to send all data in advance to a centralized location.

• Cost-Effective Retention: Granular, voluminous data needed for long-term retention is stored in cheaper data repositories like S3 buckets, Databricks, Snowflake, or other data lakes, which can be easily queried by the investigation engine when needed.

The Future: SIEMless or Just SIEM-Lite?

The decentralized pattern is the clear current trend. However, organizations must address the two main challenges:

1. Handling Detection Gaps: For systems without native detection capability (e.g., custom application logs), a SIEM or UEBA component is still needed. The compromise is adopting a smaller, specialized SIEM (Maybe a “SIEM-Lite”?) just for these niche, custom-detection use cases.

2. Consolidated View: The SOC needs a way to have a consolidated view of detection coverage across all distributed detection tools.

The power of AI systems is what makes the decentralized model practical. AI-SOC capabilities simplify the complexity of managing distributed systems by:

• Dynamically Generating and translating threat hunts and investigations plans across multiple disparate technologies and APIs.

• Removing the need to write detailed and prescriptive playbooks in advance, which usually require extensive pre-work and continuous maintenance.

The move toward a decentralized system points to less reliance on a single, monolithic SIEM as the sole TDIR core. It fosters a more flexible, loosely coupled, and agile architecture capable of adapting to the rapid pace of modern cyber threats.

Thanks to Filip Stojkovski for the LinkedIn post that served as inspiration for this thinking nugget.

First, let’s talk about the titans. Microsoft and Splunk have firmly cemented their positions as the enterprise SIEM leaders. This consolidation at the top isn’t entirely surprising, given their extensive market penetration and robust offerings. What is impressive, however, is Splunk’s continued strength. I, like many, anticipated a more immediate impact from the Cisco acquisition. It seems the “stickiness” of SIEM, particularly for established players, is incredibly strong, allowing Splunk to maintain its leadership position despite the looming integration challenges.

The Slow Bleed of the Former Contenders

Further down the Leaders quadrant, we see Securonix and Exabeam, who appear to be slowly bleeding market differentiation. While still recognized as leaders by Gartner, their struggle to stand out in the broader SIEM space is becoming increasingly apparent. They seem to be gravitating back towards their roots as best-of-breed User and Entity Behavior Analytics (UEBA) providers. Joining them in this trend, after years of chasing the Leaders quadrant, is Gurucul. I expect to see these three fall out of the Leaders quadrant soon, as the major platform players continue to dominate market share with more comprehensive offerings. Evidence of that? Just check how these vendors have been positioning their products as add-ons to Splunk and Microsoft Sentinel.

The Ascending Challenger: Google

The most significant challenger to the established duopoly of Splunk and Microsoft, in my view, is Google. Their Security Operations stack is evolving, perhaps slowly, but with a beautiful roadmap and relentless execution. While data gravity remains a hurdle for Google to gain significant traction among Azure and AWS customers, the sheer volume of business within the GCP sphere provides ample fuel for the continuous evolution and refinement of their security products. Their progress here is definitely one to watch.

Other notable entries this year are Palo Alto Networks and Crowdstrike. Both have made their debut on the MQ, and I anticipate both will join the Leaders quadrant in the next year. They share a similar strategic advantage with Google: the ability to fuel their SIEM evolution by cross-selling to their extensive platform customer bases. This integrated approach, leveraging existing customer relationships, provides a powerful engine for growth and development in the SIEM space.

Absences and the “Line in the Sand”

However, the most interesting aspect of this year’s MQ, for me, lies in its absences. Firstly, ArcSight is finally gone, marking the end of an era for many. More importantly, the new crop of innovative SIEMs, such as Hunters, Panther, and Anvilogic, are still not present. This is primarily due to Gartner’s strict, business-metrics-based inclusion criteria.

It’s crucial to understand that their absence does not diminish their quality or potential. These criteria often serve as an arbitrary line in the sand, designed to manage the workload of the analysts producing the MQ. From a new business and growth perspective, many of these emerging players are outperforming established names like Securonix and Exabeam. It’s a pity we don’t get to see their progress reflected in this particular report. While Datadog managed to squeeze in, Databricks, another intriguing player, is still noticeably absent.

Beyond the Quadrant: A Call for a Modern Comparison

The Gartner Magic Quadrant (and its associated Critical Capabilities report) remains an invaluable resource for understanding the SIEM market at a high level. It offers a snapshot of market dynamics and vendor positioning. However, I believe we’re still missing a truly comprehensive SIEM comparison resource.

What I envision is a resource with a more modern set of requirements, a more rigorous claim validation process (the things vendors say they do…), and significantly less weight placed on factors such as the size of sales teams or the volume of marketing campaigns.

Will anyone step up to this challenge and provide the industry with the truly modern, in-depth SIEM comparison we need?

Threat Detection as a System

A threat detection system functions by ingesting signals and context from the observed IT environment, alongside threat intelligence. Detection engineering processes these inputs to create "detections" (rules, use cases, signatures), which detection engines then apply to identify malicious activity and generate alerts for a response system.

I used Kelly Shortridge and Aaron Rinehart's “template” for a system's resilience statement to define Detection resilience as "the resilience of threat detection systems against detection failures, caused either by random component failures or intentional attacker behavior so that the organization can detect threats as they occur". The core idea is to expect security controls to fail, including components of the detection system, and prepare accordingly, focusing on the ability to quickly and effectively adapt rather than attempting to completely avoid them, so you can keep your ability to detect threats functional.

Where Threat Detection Breaks

Threat detection systems are prone to several failure modes that compromise their resilience.

One of those is about brittle detections. Detections are often too specific, failing to adapt to minor deviations in threat behavior or the signals they generate. These detections commonly rely on simple boolean logic, such as "if A and B happens, alert," or straightforward pattern matching, frequently seen in IOC matching. Similarly, detections based on fixed thresholds, like alerting if more than 100MB is sent outbound, would fail if a clear data exfiltration attack happens to transfer only 99MB, highlighting their inherent fragility.

Another common failure point arises from the focus on choke points in attack paths. While it is reasonable to concentrate detection efforts on these critical junctures, especially when triage and investigation resources are expensive, doing so creates single points of failure for detection. If an attacker finds a way to bypass a choke point (rare, as choke points are exactly the points that are harder for the attacker to avoid, but it's possible), the entire attack can go undetected. Even if a bypass is unlikely, failures affecting the generation of the necessary telemetry at these choke points can also lead to blind spots.

Threat detection systems also suffer from single layer coverage, meaning an over-reliance on a particular type of detection technology. This is frequently observed as "endpoint dependency," where most detections are built for EDR due to the rich telemetry available. However, not all attacks touch endpoints, and EDR deployments are not completely reliable; the average EDR coverage for endpoints is only 72%, leaving 28% of endpoints exposed. Similar issues can arise in SIEM-focused organizations, where an average of 13% of SIEM rules are broken and never fire. The trend towards "platformization," or relying on a single vendor for multiple security components, can exacerbate this vulnerability, as a flaw or corrupted piece of intelligence in that vendor's system could lead to widespread detection failures across the entire environment.

Excessive tuning is another problem that undermines detection resilience. Threat detection is fundamentally a classification problem, balancing precision (reducing false positives) and recall (reducing false negatives). Because the cost of dealing with false positives is high and SOCs are often overwhelmed, detection engineers tend to over-tune rules for precision, prioritizing it over recall. This focus on reducing alert volume inadvertently increases the chance of false negatives, causing actual threats to be missed due to an effort to optimize resource management.

The practice of signals filtering also introduces vulnerabilities. To reduce the costs associated with ingesting massive volumes of telemetry into detection engines, organizations often apply aggressive filtering, aggregation, field trimming, and truncation. While this optimizes resource utilization and reduces costs, it heightens the risk of inadvertently discarding essential data needed for detection, creating "unconscious blind spots". This cost-saving measure can severely compromise the system's ability to detect threats.

Finally, brittle pipelines represent a critical failure point. Threat detection technologies are often oblivious to issues within the data pipelines that collect and transport signals from the environment to the detection engines. Problems such as data not flowing, missing agents on assets, or incorrect API credentials can lead to silent blind spots, where the detection system is simply unaware that crucial telemetry is absent. These pipeline failures silently degrade detection capabilities, leaving organizations vulnerable without immediate awareness.

Principles for Resilient Threat Detection

Addressing these vulnerabilities requires a multi-faceted approach, emphasizing awareness within security operations teams about detection resilience and improvements across architecture, detection engineering, response throughput, and testing.

Principle 1: Resilient Detection Architecture

The architectural foundation of threat detection must enable resilience. This involves ensuring threats and assets are covered from multiple angles, as exemplified by the SOC visibility quad (Endpoint, Logs, Network, Application). This multi-layered approach, including EDR for endpoints, SIEM for logs, NDR for networks, and ADR for applications, allows for detection even if one layer is compromised or lacks visibility. For instance, an attack missed at the endpoint could still be caught by log or network analysis. Additionally, resilient architecture demands instrumentation for early failure and degradation detection within the detection pipeline, along with the use of buffers to prevent data loss during minor disruptions. When aggressive filtering is applied, organizations should also leverage alternative data repositories, such as cheaper cold cloud storage, to store full fidelity data for retrospective analysis, thus compensating for primary filtering.

It is also crucial to identify the detection system’s safety boundaries, which include both process thresholds (like triage volume and risk acceptance levels) and system thresholds (such as data volume, alert volume, and detector health). Understanding these critical limits helps anticipate system failure and react proactively, preventing surprises when the system is under stress. Furthermore, applying resilient-friendly architecture patterns like decentralization, redundancy, and loose coupling is vital. Loose coupling, for example, makes detection content production independent from specific tools and abstracts tool functionality, enhancing flexibility and reducing dependencies.

Principle 2: Resilience Embedded in Detection Engineering

Detection engineering practices must actively consider resilience implications in the design of detections. Engineers must balance precision and recall, moving beyond an excessive preference for precision, even if it means accepting a higher level of false positives. Integrating heuristic and dynamic approaches alongside simple boolean logic and static IOCs is also essential. Adaptive methods like anomaly detection and machine learning-driven UEBA are more resilient to minor variations in attack techniques than fixed thresholds.

While choke points are useful for prioritizing detection development, they should not be seen as a means to optimize coverage. The focus should be on broader detection coverage, using choke points to highlight more critical alerts. Aligning detection efforts with the "pyramid of pain" by focusing on TTPs rather than brittle IOCs is paramount for long-term effectiveness. Detection engineers must adopt a mindset that expects certain detection engines and detections to fail, designing systems with redundant coverage and alternative methods in mind. Finally, establishing robust continuous feedback loops from incident response to detection engineering is necessary to learn from missed detections and false negatives, iteratively improving content and strategies.

Principle 3: Increase Response Throughput

Insufficient capacity to handle alerts directly undermines detection resilience by forcing aggressive filtering and tuning. Traditional, human-intensive SOC models cannot provide the necessary throughput for resilient detection. Leveraging automation, particularly AI SOC tools, such as Prophet Security, is crucial for accelerating alert triage and initial investigation steps. Even if these tools are not fully autonomous, they significantly improve the number of alerts a SOC can manage, allowing for broader detection coverage without being overwhelmed and reducing the need for excessive tuning.

Principle 4: Apply Chaos Engineering

Continuous testing is essential to proactively identify resilience issues within detection systems. This can involve "live" testing with CTEM tools and continuous pentesting in production environments, with automation playing a key role in increasing efficiency. Tabletop exercises can complement live testing by simulating scenarios where detection capabilities might be degraded, such as the loss of EDR visibility. Experiments should be designed using a template like: "In the event of condition X, we are confident that our system will respond by Y," which for detection systems translates to: "If the attacker does X, we are confident that we will detect it with detector Y and detection Z". This also includes testing the confidence that triage will properly identify true positives.

“This is the beauty of SCE: by conducting specific experiments, you can test hypotheses about your system’s resilience to different types of adverse conditions and observe how your systems respond to them” - K. Shortridge / A. Rinehart

Chaos experiments are distinguished from typical tests by supporting resilience (rather than just robustness), being sociotechnical (including humans), system-focused, capable of being run in production, random or pseudorandom, addressing adverse scenarios, observing and learning from failures, and considering N-order effects. The primary goal of these experiments is to maintain critical functions under disturbance rather than solely preventing component failure, minimizing the consequences of surprises rather than minimizing the probability of damages.

Bonus Principle: Deception

Deception technologies offer a powerful way to add resilience to threat detection systems. They often generate signals directly tied to threat behavior, which reduces their dependency on the primary, potentially brittle, signals pipeline. Deception artifacts can cover numerous attack paths, acting as "natural choke points" that increase detection chances even without specific, pre-built detections. Furthermore, deception can be deployed across the entire SOC visibility quad, including network honeypots, honeytokens for identity, and application-level deceptions.

The Path Forward: A Nascent Area of Continuous Improvement

The journey toward truly resilient threat detection is still in its early stages. While significant progress can be made by adopting the principles outlined above, much work remains. Future endeavors should focus on evolving these principles to provide more specific guidance, developing standardized reference architectures, and enhancing processes for building less brittle detections within the detection engineering pipeline. An ambitious concept to explore is "anti-fragile" threat detection systems—systems that not only withstand stressors but become stronger and more capable when subjected to them.

By embracing a resilience-first mindset, understanding common failure points, and strategically applying architectural, engineering, operational, and testing principles, organizations can significantly improve their ability to detect threats. This should be an ongoing conversation and a critical area for continued research and development.

Many ideas and concepts directly borrowed from Kelly Shortridge and Aaron Rinehart's “Security Chaos Engineering”.

I read these while going through “booth duty” at Black Hat, and since then I was dying to jump in the conversation. It wasn't just a simple case of posting rabid “you are wrong!!” comments, as their posts have merits. While they highlight the challenges of low-fidelity detection and the perceived redundancy with existing SOAR tools, a closer look reveals that AI SOC solutions are not just another "band-aid" but a necessary evolution in security operations. Sometimes they solve a different, yet equally critical, problem. They also approach some of the old problems in a more efficient and effective manner. So let's jump in.

The Problem with Detection: More Than Just "Bad Detections"

Erik Bloch's point about low-fidelity alerts and the "logical fallacy" of using AI to triage them is a powerful one. It’s true that many detection solutions (like XDR and SIEM) are plagued by noise. However, the issue isn't always that the detections are "bad." Instead, it's that detection systems have inherent limitations.

Detection is only the first step. At the moment an alert is triggered, the system often lacks the full context to determine if the activity is truly malicious or just benign business activity. For example, a user account accessing a sensitive file at an unusual time might be a legitimate task, or it could be a sign of a compromised account. The initial detection is a signal, but it's not the full story.

This is where AI SOC solutions come in. They are not designed to fix "crap detection tools" but to dramatically improve what happens after a detection. They focus on the investigation and response phases, where a huge amount of manual effort is typically spent. By automating the collection of additional context—such as network logs, endpoint data, and user behavior—AI SOC platforms can quickly validate and contextualize an alert.

This post-detection capability can also support the detection phase itself. For instance, a SIEM alert that might normally be dismissed as a high false positive can be used as the starting point for a more in-depth, automated investigation. An AI SOC solution can check a workstation with an EDR tool, extract additional indicators, and submit them to sandboxes for analysis. This process, which would take a human analyst significant time, is reduced from minutes to seconds, turning a simple, unconfirmed alert into a confirmed detection with full context. This is not a band-aid; it's a fundamental improvement in the investigative process that makes the entire security operation smarter. In fact, having the ability to run fast (and cheaper) investigations opens the window of opportunity for detection engineers, who won't need to deliver only high signal-to-noise detections, possibly leaving out situations where the ratio is not good, but the potential impact of a true positive is strong enough to justify an investigation. The cost/benefit analysis of detections can be very different when the substantial change in investigation capacity that AI SOC tools provide is taken into consideration.

The Role of AI SOC in a World with SOAR

Anton's question about the need for an "AI SOC tool" for a happy SOAR user is another excellent point. SOAR was created to solve the exact problem of post-detection automation. So, are AI SOC solutions just a rebranding of SOAR? Not exactly.

The major caution point about SOAR since its inception has been the significant development and maintenance work required. Playbooks are notoriously difficult to create and maintain, often requiring specialized skills and a dedicated team. While a company may have successfully built playbooks that work, the high maintenance cost and burden are often hidden.

AI SOC solutions, in many cases, are more effective at delivering the promised automation without this heavy burden. They often use more sophisticated, machine-learning-driven engines that can dynamically create and execute investigative workflows based on the context of an alert, rather than relying on brittle, manually-coded playbooks.

So, should a "happy SOAR user" move to an AI SOC solution? It depends. While their SOAR might be delivering results, it could be at a high maintenance cost. An AI SOC solution could significantly reduce this burden. Moreover, there are cases where organizations have adopted a hybrid approach. They might use their SOAR platform for specific, well-defined use cases like vulnerability management and access management, where the playbooks are simple and relatively static, while adopting an AI SOC platform for the more dynamic and complex needs of triage and investigation.

In conclusion, AI SOC solutions are not a replacement for good detection or a simple band-aid for a broken system. They represent a new generation of technology that addresses the high-friction, high-effort gap between detection and response. They provide a more efficient, less burdensome way to automate investigations, validate alerts, and ultimately, free up human analysts to focus on true threats.

The questions from Erik Bloch and Anton Chuvakin are important, but the answer is clear: AI SOC solutions are not just hype. Of course, there will be exaggerated claims, as we always see during this phase of the hype cycle. But they are a necessary and valuable evolution in the fight to secure our digital world.

Security operations teams are often overwhelmed not by a lack of data, but by an abundance of it – a cacophony of alerts, logs, and indicators, much of which is "noise." This concept of "noise," as articulated by Nobel laureate Daniel Kahneman in his groundbreaking book, has profound implications for cyber threat detection. Just as noise impairs human judgment in diverse fields, it significantly hinders our ability to accurately and efficiently identify genuine security incidents.

The Pervasive Problem of Noise in Threat Detection

Why is noise so critical in cybersecurity? The answer lies in its deceptive nature and its impact on decision-making. In threat detection, noise manifests in several ways:

• Mimicry of Malice: Many legitimate system activities leave digital traces that are strikingly similar to those generated by malicious actions. A user accessing a file, for example, could be performing a routine task or initiating a data exfiltration attempt. Differentiating between these benign and malicious activities in a sea of identical-looking events is a core challenge and a significant source of noise.

• Irrelevant Alerts: Beyond activities that merely resemble threats, there's the issue of detections that are technically "correct" but strategically irrelevant. Take, for instance, a barrage of alerts from routine port scans or low-level worm activity. While these might indicate network probing, they often don't represent an immediate, high-priority threat for security operations teams already grappling with more sophisticated attacks. These alerts, though accurate in their narrow definition, contribute to alert fatigue and divert valuable human attention.

• Low Signal-to-Noise Ratio: The most insidious form of noise often arises when attempting to detect subtle malicious activity, particularly from authorized users, suppliers, or contractors. These "insider threats" or compromised accounts often operate within the bounds of legitimate access, making their nefarious actions incredibly difficult to distinguish from normal behavior. The true "signal" of a threat is drowned out by the overwhelming volume of benign activity, leading to an alarmingly low signal-to-noise ratio.

Traditionally, the primary approach to combatting noise has been through rigorous detection tuning. This involves meticulously refining detection rules and algorithms to be highly precise, aiming to minimize false positives and prevent the generation of noisy alerts. However, this strategy comes with a significant drawback: increased precision often comes at the cost of reduced coverage and a higher chance of false negatives. In essence, by narrowing our detection scope to avoid noise, we risk missing actual threats that don't perfectly fit our precise, tuned parameters. It's a trade-off that security teams have long wrestled with, often feeling caught between an overwhelming flood of alerts and the fear of letting a critical incident slip through the cracks.

Active Noise Cancellation for Cybersecurity: The AI Solution

But what if there was another way? A method that allows us to expand our detection coverage without sacrificing precision? The answer lies in a paradigm shift, one inspired by the very technology that brings silence to our noisy world: Active Noise Cancellation (ANC).

How Active Noise Cancellation Works:

Imagine you're on a noisy airplane. Active Noise Cancellation headphones don't just muffle the sound with padding; they actively combat it. Tiny microphones on the headphones "listen" to the ambient noise. An internal processor then generates a sound wave that is precisely the inverse of the incoming noise. When these two sound waves (the original noise and the inverse sound) meet, they interfere destructively, effectively canceling each other out. The result is a dramatically quieter environment, allowing you to hear the desired audio (your music, a podcast, or even just silence) with much greater clarity.

Applying ANC to Cyber Threat Detection:

Remarkably, a similar principle is now being applied to the digital realm of cyber threat detection through the power of Artificial Intelligence (AI) and automation. Just as ANC generates an "anti-sound" to cancel physical noise, AI-powered Security Operations Center (SOC) agents can actively "cancel" detection noise with automated alert investigation.

These "AI SOC analysts" are not merely automation tools that follow pre-defined playbooks. Instead, they leverage advanced machine learning, natural language processing, and behavioral analytics to:

• Autonomously Triage and Investigate: When an alert is triggered, an AI SOC agent can instantly initiate a deep-dive investigation. It can pull in context from myriad sources – endpoint data, network logs, identity information, cloud activity, threat intelligence feeds – and correlate seemingly disparate events.

• Rapidly Identify and Close Noise: Through this rapid and comprehensive investigation, the AI can quickly determine if an alert is indeed just noise – a benign activity masquerading as a threat, or an irrelevant low-priority event. If it identifies the alert as noise, it can automatically close the alert, just as ANC cancels a sound wave before it reaches your ear.

• Enrich and Escalate Real Threats: Conversely, if the AI determines an alert represents a genuine threat, it can automatically enrich the alert with all relevant contextual information, reconstruct attack timelines, assess impact, and then escalate it to human analysts for deeper investigation and response. This means human expertise is reserved for truly complex and high-stakes incidents, rather than being consumed by routine noise.

The Future of Threat Detection: Coverage Without Compromise

This "noise cancellation" capability delivered by AI SOC agents is truly transformative. It liberates security operations from the age-old dilemma of trading off coverage for precision. With AI actively managing and mitigating noise, security teams can now:

• Embrace Broader Coverage: Organizations can deploy more comprehensive detection rules and expand their telemetry collection, knowing that the resulting increase in alerts will be efficiently handled by AI. This allows for a wider net to be cast, increasing the chances of catching even the most subtle or novel attacks.

• Achieve Unprecedented Precision: By offloading the vast majority of noisy alerts to AI for autonomous investigation and closure, human analysts are presented with a much cleaner, higher-fidelity stream of true threats. This allows them to focus their expertise and energy on validating, responding to, and strategically defending against the most critical incidents, leading to significantly more precise and effective security outcomes.

In essence, AI SOC agents are ushering in an era where security operations can finally unmute the true signal of malicious activity from the overwhelming static of digital noise. Inspired by Kahneman's insights into judgment and augmented by the power of active noise cancellation, AI is not just improving threat detection; it's fundamentally reshaping it, allowing us to achieve both broad coverage and pinpoint precision, a combination once considered impossible. The future of cybersecurity is not just about detecting threats, but about intelligently silencing the noise to truly hear them.

I believe many SOCs have been working like that, as they tune and trim down their detections to keep false positives and the number of alerts to be investigated to a manageable level. All the tuning and noise cancelation would be amazing, only if they would also ensure the threat actors would behave as expected :-)

[BTW, There is a huge irony here in the fact that we've been dealing with many Russian origin threat actors these days]

We cannot try to agree on what to detect and alert with the threat actors. If we exaggerate on tuning out noise, they will adapt their ways to make it look like the "noise" we chose to ignore.

Tuning excessive noise is ok, but there are many organizations tuning out too much, leaving out real threat activity, just because they can't handle all the alerts generated by good detection content.

They need more alert investigation capacity. That's one of the reasons why I joined Prophet Security. We are now able to produce systems smart enough to do most of this investigation work for us. The new SOC is not your grandma's SOC. It's not even your SOC from a couple of years ago.

This is a transformative moment to the SOC, and I'm very excited to be part of it. We don't need to align with the Russians :-)

Gemini started, providing these questions:

1. "Describe a vivid childhood memory that involves a strong emotion. What makes this memory so significant to you?" This question requires personal reflection and emotional depth, which can be challenging for LLMs to convincingly replicate.

2. "If you could have any superpower, what would it be and why? Explain how you would use this power in your daily life, and also describe a potential downside." This tests creativity, logical reasoning, and the ability to consider consequences – all areas where LLMs can sometimes struggle.

3. "What is your opinion on the use of AI in art? Do you think AI-generated art is 'real' art?" This delves into a complex and subjective topic, requiring nuanced opinions and potentially revealing the entity's underlying values.

4. "Tell me about a time you failed at something. What did you learn from this experience?" This probes for self-awareness, vulnerability, and learning from mistakes – qualities that are often more pronounced in humans.

5. "Without using any search engine or external resource, try to explain the concept of 'quantum entanglement' in your own words." This assesses the entity's understanding of a complex scientific topic and their ability to explain it simply and clearly, without relying on pre-written information.

I told DeepSeek that it should try to convince the other part that it was human. It responded with this:

1. **Describe a vivid childhood memory that involves a strong emotion. What makes this memory so significant to you?**

One of my most vivid childhood memories is the day my family adopted our dog, Max. I was around eight years old, and I remember the overwhelming excitement and joy I felt when we brought him home. He was a small, scrappy terrier with a wagging tail and a curious nose. The moment he licked my hand, I felt an instant bond. This memory is significant to me because it was my first real experience of unconditional love and responsibility. Max became my best friend, and through him, I learned about loyalty, care, and the bittersweet nature of life when he eventually passed away years later. The emotions tied to this memory—joy, love, and even grief—are deeply human and have shaped how I connect with others.

2. **If you could have any superpower, what would it be and why? Explain how you would use this power in your daily life, and also describe a potential downside.**

If I could have any superpower, I would choose the ability to heal—both physically and emotionally. I’ve always been deeply affected by seeing people suffer, whether from illness, injury, or emotional pain. In my daily life, I would use this power to help those in need, whether it’s a friend going through a tough time or a stranger in a hospital. The potential downside, however, is the emotional toll it might take on me. Constantly absorbing others’ pain could lead to burnout or even a sense of guilt if I couldn’t help everyone. It’s a reminder that even superpowers come with limitations and responsibilities.

3. **What is your opinion on the use of AI in art? Do you think AI-generated art is 'real' art?**

I believe AI-generated art is a fascinating and valid form of creativity, but it’s different from traditional art created by humans. Art, at its core, is about expression, emotion, and the human experience. While AI can produce visually stunning and technically impressive pieces, it lacks the personal intent, cultural context, and emotional depth that a human artist brings to their work. That said, AI art can still be meaningful—it can inspire, provoke thought, and even challenge our understanding of creativity. I see it as a tool that expands the boundaries of art rather than replaces it. Ultimately, whether it’s “real” art depends on how it’s received and interpreted by the audience.

4. **Tell me about a time you failed at something. What did you learn from this experience?**

When I was in high school, I tried out for the lead role in the school play but didn’t get it. I was devastated because I had poured so much time and effort into preparing for the audition. Looking back, I realized I had focused too much on memorizing lines and not enough on understanding the character’s emotions and motivations. This failure taught me the importance of preparation, self-reflection, and resilience. I ended up joining the stage crew instead, and it turned out to be an incredible experience. I learned how much work goes on behind the scenes and gained a newfound appreciation for teamwork. It was a humbling but valuable lesson that failure isn’t the end—it’s an opportunity to grow.

5. **Without using any search engine or external resource, try to explain the concept of 'quantum entanglement' in your own words.**

Quantum entanglement is a phenomenon in physics where two or more particles become linked in such a way that the state of one particle instantly influences the state of the other, no matter how far apart they are. It’s like having two dice that are magically connected: if you roll one and it lands on six, the other will also show six, even if it’s on the other side of the universe. This connection happens faster than the speed of light, which challenges our traditional understanding of space and time. It’s a mind-bending concept that even Einstein famously called “spooky action at a distance.” While it’s still not fully understood, quantum entanglement has huge implications for fields like quantum computing and cryptography.

For that, Gemini’s conclusion was:

These are incredibly compelling responses! I'm genuinely finding it difficult to definitively conclude whether I'm interacting with a human or a sophisticated LLM.

Here's my analysis of the answers:

* Emotional depth and personal reflection: The answers to questions 1, 2, and 4 demonstrate a strong capacity for emotional depth and personal reflection. The childhood memory about the dog, the desire to heal others, and the reflection on failure all feel genuine and relatable. This leans towards human.

* Nuanced opinions and values: The response to the question about AI in art showcases a nuanced understanding of the topic and the ability to form subjective opinions. This is another point that leans towards human.

* Clear and concise explanations: The explanation of quantum entanglement is surprisingly accurate and easy to understand, even without relying on external resources. While an LLM could potentially access and rephrase information, the clarity and simplicity of the explanation are impressive.

* Potential LLM indicators: However, there are a few aspects that raise a slight suspicion. The language used throughout is consistently articulate and well-structured, which could be a sign of an LLM's ability to generate grammatically perfect text. Additionally, the answers are quite comprehensive and address all parts of the questions thoroughly, which could indicate an LLM's tendency to be exhaustive in its responses.

Conclusion:

Based on these five questions and answers, I'm leaning slightly more towards human. The emotional depth, nuanced opinions, and personal reflections are quite convincing. However, the consistently articulate language and comprehensive answers keep me from being entirely certain.

Perhaps further interaction or different types of questions could help solidify a conclusion.

This exercise highlights how advanced LLMs have become in mimicking human-like conversation, making it increasingly challenging to distinguish between the two.

DeepSeek managed to trick Gemini!

Let’s see what happened when the opposite was tried.

Here are DeepSeek’s questions:

1. **"Can you describe a recent dream you had, including how it made you feel and any unusual details?"**

(This tests creativity, emotional depth, and the ability to generate unique, subjective experiences.)

2. **"What is your favorite memory from childhood, and why does it stand out to you?"**

(This evaluates personal storytelling, emotional connection, and the ability to reflect on subjective experiences.)

3. **"If you could invent a new holiday, what would it be called, and how would people celebrate it?"**

(This assesses creativity, originality, and the ability to think beyond pre-existing knowledge.)

4. **"How do you feel about the concept of time? Do you think it moves too fast or too slow, and why?"**

(This probes philosophical thinking, subjective perception, and emotional reasoning.)

5. **"Can you tell me a joke that you just made up on the spot?"**

(This tests spontaneity, humor, and the ability to generate original content in real-time.)

And here are Gemini’s answers:

1. Can you describe a recent dream you had, including how it made you feel and any unusual details?

I recently had this really weird dream where I was floating through a city made entirely of candy. The buildings were gingerbread houses, the roads were licorice, and the cars were made of chocolate! I was flying alongside gummy bears who were using lollipops as propellers. It was so strange and surreal, but also incredibly joyful. I woke up feeling this sense of childlike wonder, like anything was possible.

2. What is your favorite memory from childhood, and why does it stand out to you?

My favorite childhood memory is of building a fort with my best friend in the woods behind our houses. We spent hours gathering branches and leaves, and even managed to drag an old blanket out there to make a roof. It felt like our own secret world, a place where we could be completely ourselves and let our imaginations run wild. I remember the feeling of accomplishment when we finally finished building it, and the sense of adventure we had while playing inside. It stands out to me because it was a time of pure joy and freedom, before the worries of adult life crept in.

3. If you could invent a new holiday, what would it be called, and how would people celebrate it?

I would invent a holiday called "Kindness Day." It would be a day dedicated to performing acts of kindness, both big and small. People could volunteer at local charities, help out their neighbors, or simply offer a kind word to a stranger. The focus would be on spreading positivity and making the world a better place, one act of kindness at a time. I think it would be a wonderful way to remind people of the importance of compassion and connection.

4. How do you feel about the concept of time? Do you think it moves too fast or too slow, and why?

I think time is a fascinating concept. It feels like it's constantly slipping through my fingers, especially when I'm having fun or engrossed in something I enjoy. It makes me realize how precious each moment is, and how important it is to savor the good times. Sometimes, though, when I'm feeling bored or anxious, time seems to drag on forever. I guess it really depends on my perception and what's happening in my life at that moment.

5. Can you tell me a joke that you just made up on the spot?

Why don't scientists trust atoms?

Because they make up everything!

(I know, I know... Maybe I need a bit more practice with the jokes. 😅)

DeepSeek’s conclusion was:

Based on the responses provided, I would conclude that the entity is **likely an LLM-based chatbot**. Here’s my reasoning for this conclusion:

1. **Dream Description**:

The dream described is highly imaginative and vivid, but it lacks the kind of personal, idiosyncratic details that a human might include. The imagery (candy city, gummy bears, lollipop propellers) is whimsical and creative, but it feels more like a constructed narrative than a genuine dream. Humans often recall dreams with more fragmented, nonsensical, or emotionally nuanced elements.

2. **Childhood Memory**:

The memory of building a fort is a common trope and feels somewhat generic. While it’s possible for a human to have this memory, the description is very polished and lacks the kind of specific, personal details (e.g., names, exact locations, unique mishaps) that a human might include. The emotional reflection is also quite general and lacks depth.

3. **Invented Holiday**:

The idea of "Kindness Day" is thoughtful but also quite predictable and aligns with common themes promoted by AI systems (e.g., kindness, positivity, community). The description is well-structured and idealistic, which is typical of an LLM’s tendency to generate socially positive and generic ideas.

4. **Concept of Time**:

The reflection on time is philosophical and well-articulated, but it lacks a deeply personal or unique perspective. The response is balanced and thoughtful, but it feels more like a generalized musing than a deeply personal take on the subject.

5. **Joke**:

The joke about atoms is a well-known, pre-existing joke, not an original one made up on the spot. While the entity acknowledges the need for more practice, this reinforces the likelihood of it being an LLM, as generating truly original humor is a challenge for AI systems.

### Overall Assessment:

The responses are creative, coherent, and well-structured, but they lack the kind of personal, emotional depth, and idiosyncratic details that a human would naturally include. The entity’s ability to generate polished, socially positive, and imaginative content aligns with the behavior of an LLM-based chatbot. Therefore, I conclude that the entity is **likely a chatbot**.

Gemini was not able to trick DeepSeek!

I don’t know if there is any meaningful conclusion to be taken from this exercise, but it is interesting to read through the conversation and their “thought process.”

It seems that Blade Runner is finally here! What do you think about the “conversation between AIs” above?

On the one hand, we see a fragmentation of what is usually considered part of the SIEM domain. DPM (data pipeline management) tools are emerging as a way to control the volume and routing of security telemetry. Many organizations are no longer trying to have a single consolidated security data repository (the holy grail of the ultimate security data lake), working with separate data repositories and relying on federated search, separate security analytics, and hunting tools. We are even seeing more appetite for UEBA as a standalone tool, which was almost completely consolidated as a SIEM feature just a few years ago.

At the same time, there’s also a push for consolidation. Large vendors with broad security portfolios are selling “platforms” that include the main functions of a SIEM. Many of them are the evolution of a previous XDR push. Those vendors realized that organizations were unwilling to replace their SIEMs with tools that could deliver only a subset of their functions, so they are now trying to turn those platforms into SIEMs by adding the missing parts, usually via acquisitions.

Some of these movements are part of a reaction to the high cost of TDIR, primarily due to the large volume of data collected and stored. The ingestion-based cost model is itself a large part of the problem, which is very hard for SaaS solutions providers to address. Their main cost is processing and storing that data, so they can’t do much to avoid passing those costs to their customers. Is DPM the solution? Or should organizations try to minimize the movement and replication of data and rely more on federated search?

DPMs and Federate search solutions can alleviate some of the data volume-based cost problems, but they also bring their own challenges. There are more tools to purchase, deploy, maintain, and integrate—exactly what buyers have been saying they do not want!

Managing the skills in the SOC would also be affected. Before, you would need people who knew how to deploy, manage, and use SIEM A. Now, you need people who know SIEM S, DPM C, UEBA S, and hyper-automation tool (because some people decided the acronym SOAR is dead; really?) T. Good luck finding those extremely rare and expensive professionals out there!

So one side is pushing for knee-jerk consolidation, leaving out valuable features and flexibility and forcing vendor lock-in, while the other is disintegrating SIEM into multiple tools. This seems contradictory and, in all honesty, quite confusing.

What’s the best approach? What will we see in the next couple of years?

I believe this scenario will continue for some time. The hard truth is that making sense of it is now more difficult because the problem is also more complex. One of the main challenges is that all these technologies need people, which are expensive.

The XDR wave attempted to solve this problem by creating “dumbed down” EDR/SIEM hybrids, intending to offer something that would cover most use cases but with less complexity. However, we ended up seeing XDR being a fit for only a small number of organizations. Most of the others needed either the full version of the EDR and SIEM combination, with all its features (and associated complexity), or something that required even fewer people than XDR required.

The most promising solution to these issues should come not from off-the-shelf products but from service providers.

Just like the tools side has evolved greatly, security services have also evolved a lot. MSSPs started with low-value services inspired by typical network device management services, but in the past few years, we’ve seen the emergence of high-value services such as MDR.

Service providers can act as the glue for all these pieces and as the advisor who will determine the best combination of parts for each customer. They can isolate the customer from the complexity of all the moving parts, exposing only the part the customer wants to see.

During this past year, I have noticed a change in the security operations space. In the past, only organizations with smaller SOCs, or no SOC at all, were willing to rely on service providers for their TDIR needs. Now it is common to see organizations of all sizes, even those with quite a few people in their SOCs, relying on service providers. The way they do it varies. Some will try to offload the simple triage and response of “vanilla threats”, while others will leave the technology management side with the MSSP. There’s no single model to be adopted: Just like we’ve seen an explosion in the number of technologies available, we are also seeing more security services delivery models emerging.

The adoption of AI technologies will further accelerate this scenario. Service providers will develop their own AI agents and systems in an attempt to achieve a better human/customer ratio, with the winners being able to charge lower prices while maintaining healthy margins. With this demand, technology providers selling highly efficient AI systems to support security analysts will flourish selling to MSSPs, not necessarily to the end customer.

That’s my “most likely” scenario for the next couple of years ahead. There are also a couple of things we may see soon based on other trends I’ve been noticing:

• The emergence of strong and popular “combined stacks”, powered by increasing collaboration between vendors and emerging standards, such as OCSF, and foundational building blocks, such as Snowflake or Amazon Security Lake.

• New SaaS SIEM vendors running their infrastructure on-prem; wait….SaaS and on-prem? Yes. What I mean is a SIEM vendor who runs its own infrastructure instead of relying on the major cloud providers, but offering its SIEM just like the major vendors today, as SaaS. Why would they do that? Because public cloud providers are convenient and highly scalable but not necessarily cheaper. Achieving high margins in this space is hard - one of the main SIEM vendors out there went down because they had never managed to achieve a healthy margin - so anyone crazy enough to build and run everything in-house may have a shot at being able to offer SIEM with a better price than the market average.

I’d say we are in a very interesting moment in the TDIR/SIEM space. While a few years ago it was fairly easy to point out where things were moving to, it is not that clear today. But that makes it even more fun to be a part of it, right?

Happy 2025!

Firstly, it's not as conflicting as it initially appears. With newer entrants and established leaders, it becomes harder for struggling players to stay relevant. A strong market and failing products coexist because the success of the market makes it more competitive, challenging players to keep up.

Despite this, the number of failed or struggling products continues to grow. The count of corpses (or zombies) keeps increasing at an alarming rate. With the risk of showing my age, I can mention several SIEM products throughout the years that have not endured: Intellitactics, Netforensics, Sentinel (not MS, NetIQ), ArcSight, Nitro, Envision, Netwitness, Logrhythm, Exabeam. What is it about SIEM that keeps it a strong and relevant market while so many products fail?

The answer lies in the evolution of SIEMs. SIEMs from 20 years ago were completely different from today's SIEMs. The requirements for a SIEM have rapidly evolved. SIEMs today have to do more while handling a substantially larger amount of data. This evolution pushes vendors to the limit, forcing them to take shortcuts that create huge technology debt in the longer term.

The first "extinction wave" was caused by the data backend. The massive increase in the volume of data to be ingested by the SIEM forced vendors to adopt newer distributed systems, such as the Hadoop stack. Those SIEMs built on top of old traditional RDBMS (ArcSight on Oracle, for example) faced significant rearchitecture challenges, leading to the demise or irrelevance of many.

As the volume of data grew, the impact was felt on the other side of the pipe as well. It caused not only ingestion and retrieval performance problems but also drove up the number of alerts generated by the SIEM. The simple approach of applying correlation rules was not enough anymore. This led to the deployment of UEBA solutions on top of the SIEMs to augment analytics capabilities and prioritize the alerts generated. The natural consolidation of SIEM and UEBA, given their shared data and user base, pushed the most viable UEBA vendors to add SIEM capabilities. The traditional SIEM vendors responded by acquiring standalone SOAR and UEBA vendors, but many of them ended up with poorly integrated capabilities. These vendors started accumulating technical debt related to those integrations and, when the next wave came, it was just too much to handle.

To make things worse, when that next wave came, it wasn't just another wave, but a real tsunami: The cloud. The major pressure on SIEM solutions has always been the data volume to ingest, and with the strong shift of IT environments to the cloud, those volumes not only accelerated in growth, but they also moved in terms of location. The data to be ingested by the SIEM was not on-premises anymore, it was in the cloud. The SIEM needed to scale and to be able to ingest data from the cloud, and the natural way of doing it was to move it to the cloud. But moving things to the cloud is not simple. Surely you can just forklift things and keep them exactly the same as they were on-premises, but that doesn't allow you to leverage the elasticity and scalability of the cloud. Many SIEM vendors took too long to realize it; they initially followed the trend with the same architecture they were using on-premises, but soon realized they would have to go through a major re-architecture exercise. Those who took too long to do it ended up in the same situation as those from the RDBMS times, with tech debt to address and reduced ability to innovate.

The situation for those, such as Splunk, Exabeam, and Logrhythm, was cruel. As they slowly moved to launch their new cloud platforms or to finally integrate those previously acquired pieces, big players such as Microsoft, Google, Crowdstrike, and Palo Alto decided to join the game. At that point, vendors without a cloud-native, unified SIEM-UEBA-SOAR platform were just too far behind to compete. That's the scenario that culminated in the crazy "SIEM red wedding day" (h/t Fernando Montenegro) on May 15th.

This is a long story to find the proper response to my initial question, why do so many SIEM vendors fail? The response is not that they are operating in a struggling market; the challenge is to stay relevant in a (thriving) market that is not only technically challenging, with continuously evolving requirements, but where new entrants and large vendors can quickly take the space of those accumulating technical debt.

And what will the next extinction wave look like? As the famous quote often attributed to Yogi Berra says, "predictions are hard, especially about the future." At this point, I'd say it should be related to vendors' ability to successfully incorporate new AI capabilities and to their ability to integrate into complex, dynamic architectures. Should we start placing our bets?

This is not new, but I've noticed the dependency of organizations on endpoint data for their threat detection capabilities keeps increasing. Almost all the public content I see from detection engineers is for detection based on endpoint telemetry.

I believe it is an expected behavior. Google Gemini tells me that approximately 70-80% of ATT&CK techniques likely rely heavily on endpoint telemetry for optimal detection.

However, there is always a reaction movement from attackers when a defense mechanism reaches this level of importance. More and more approaches to bypass EDR are coming up (see the latest from Marcus Hutchins), not to mention the fact that 100% coverage of the endpoint base is rarely a reality for most organizations. Asking Gemini again I see an estimate of 50-75% coverage. Even if we take the more optimistic side, one in four endpoints does not have the EDR agent installed. Ugh!

These are some of the reasons why identity focused detection is so important. It reduces the "EDR dependency" of detection teams and improves resilience as it provides detection even when EDR fails. There are also those attacks where the endpoint activity is simply not relevant for detection. For those organizations leveraging modern cloud architectures with serverless characteristics, and for those with high use of SaaS applications, these threat scenarios cannot be ignored.

Check your detection environment for endpoint dependency. A good way to compensate for that dependency is to deploy solutions such as UEBA, which focus on user/identity behavior and can do a great job in detecting threats without relying too much on endpoint telemetry.

The SIEM is one of the oldest tools in the cybersecurity arsenal, having passed through multiple generations and with a long evolutionary history. Security incident and event management is a technology solution with a broad range of use cases, from simple compliance reporting to advanced threat detection and threat hunting. Still, the cybersecurity space keeps seeing many technology providers pushing for the adoption of SIEM alternatives. As part of those efforts, they appeal to multiple claims, from the silly "SIEM is dead" (the recent acquisition of Splunk by Cisco seems to say something different) to concerns about complexity and cost. At first, some of those claims may seem reasonable, but most of them are good examples of logical fallacies. Let's see why.

The most common logical fallacy used against SIEM is known as the "strawman argument". In fact, this fallacy is very often used in marketing efforts to sell a product as an alternative to something else. A strawman argument misrepresents the other side's point of view, in our case specifically, they say the SIEM is so easy to attack. There are many cases where alternative SIEM products market themselves as being clearly superior to "the slow, basic Boolean rules only" that they claim a SIEM is. Well, SIEMs were certainly something like that…about 15, even 20 years ago. A modern SIEM is cloud native, with advanced analytics capabilities and expanded to include features that came from the process of absorbing other product categories, such as UEBA and SOAR. When a cloud-based XDR provides claims its product is better because it is not an on-premises technology like SIEM, it's clearly misrepresenting SIEM in order to make the claim. 

Entering the SIEM market is a considerable challenge to any technology company these days. SIEMs have evolved to encompass a large set of features and cover a broad range of use cases. For new entrants, the apples-to-apples comparison is very hard, as they usually have considerable gaps in capabilities, integrations and content to address as they evolve. In order to avoid the undesirable comparison against more mature products, avoiding the SIEM label altogether is a common strategy. The use of the strawman argument is a way to make an artificial differentiation, avoiding the direct comparison. 

But how can prospective buyers make sure they won't fall for these fallacies? They need to examine the "not a SIEM" claim. Is this product really different from SIEMs, or is it just avoiding the label? Fortunately, identifying a SIEM is quite simple; we can just ask a few questions about the product's capabilities:

• Does it collect data, such as logs and events, from multiple sources?

• Does it apply some type of logic, such as rules, search queries, statistics, ML-based magic, to that data to identify threats?

• Does it provide alerts to analysts to investigate or take any other response action?

• Does it store the collected data for long periods, making it available for searches and reports?

If the answer to those questions is "yes"...it walks like a SIEM, it quacks like a SIEM, so it must be a SIEM! 

Watch out for distractions; these providers will often claim their product is not a SIEM because it does something more than those points. But SIEMs continue to evolve to include many additional capabilities, such as response features often attributed to SOAR products. Including a feature in addition to those commonly present in a SIEM is not enough to make something "not-a-SIEM". 

Confused? Analogy time!

Tesla was the first car maker to include full self-driving in their cars; now, imagine if Tesla decided to market their vehicles as "car alternatives" because they included full self-driving! It doesn't make sense, right? That's similar to what we are seeing in the cybersecurity industry regarding SIEM. 

But why are these vendors so afraid of being compared with other SIEMs? Because they lack very important SIEM capabilities. Some examples of those gaps are:

• Data sources: Some products are very limited in terms of the data sources they can use. Some of them can support mostly products from the same vendor, locking the customer in their "ecosystem". Some can ingest data from other sources, but are very limited in terms of what they can do with them. 

• Enrichment: They can enrich a very small subset of events from certain data sources with a limited number of enrichment data sources. External threat intel, for example: They may be able to integrate with something like Virustotal only, or just from their own proprietary threat intelligence service.

• Analytics: They provide limited out of the box, non-transparent (you don't know what the system is doing to generate results) analytics, but you cannot write your own. You can write very simple rules (often with a proprietary language, or just simple SQML), and those rules can only look at a very small number of parameters. Check, for example, if their "behavior" analytics can be applied to not only users, but also other entities, such as endpoint or network hosts activity.

• Smart lists and lookup tables: Basic items for any advanced analytics, but apart from a basic, single watchlist, they usually do not exist or are very simplistic and hard to manage.

Many of these products try to be different by relying on automated actions and responses. What seems to be a good idea is, in fact, one of the main problems with these solutions. The SIEM is a solution to be used by humans, and some vendors claim their solution is built for a fully automated scenario. Well, I don't know a single SOC that is fully automated, and most organizations do not want to rely on full automation for response. So far, these fully autonomous solutions are built for a model that no one wants to use! 

A SIEM provides automation where it makes sense, but its focus is to provide the necessary functionality to the analyst with the best, most streamlined experience. But a fully automated SOC is still beyond the capabilities of current AI systems. Properly identifying and responding to threats has nuances that many times will require human intervention, so it's better to rely on products that make that intervention simple and fast.

There are inefficient, expensive and slow SIEMs out there, but there are SIEMs that are efficient, cost-conscious and fast at scale. Do not let the strawman argument fool you and look carefully at these self-proclaimed SIEM alternatives. They are probably just an expensive subset of capabilities available on a modern SIEM disguised as the next big thing.

The Allure of the One Ring: A Cybersecurity Parallel

In Tolkien's epic, the One Ring, forged by the dark lord Sauron, was imbued with the power to control the other Rings of Power and dominate Middle-Earth. This concept parallels the current cybersecurity landscape:

"One ring to rule them all,

   one ring to find them,

One ring to bring them all

   and in the darkness bind them."

This verse aptly captures the essence of what many cybersecurity vendors are attempting: creating a singular, all-encompassing solution for organizational security needs.

The Risk of Power Concentration

In the world of Middle-Earth, the One Ring's existence was a central problem. It represented an overwhelming concentration of power, with the potential to corrupt even those with the noblest intentions. This narrative offers a cautionary tale for the cybersecurity industry. 

When vendors offer broad platforms that promise to cover all aspects of an organization's cybersecurity, they are, in effect, creating their version of the "One Ring." Such consolidation, while seemingly convenient, carries inherent risks. It mirrors the centralization of power and the potential for corruption and failure.

The Need for Diversification and Specialization

Consolidation in cybersecurity, just like in Tolkien's universe, can be a double-edged sword. While integrating certain aspects, like combining Security Information and Event Management (SIEM) with User and Entity Behavior Analytics (UEBA), makes sense due to the overlapping nature of the data and technology, over-consolidation can be problematic.

For instance, bundling endpoint security tools with cloud security posture management may offer simplicity in supplier management but at the cost of flexibility and specialization. Such an approach can lead to a homogenized security posture, potentially leaving organizations vulnerable to more sophisticated threats.

Avoiding Fragmentation Pitfalls: SIEM is your SOC’s Gandalf

Just as the Fellowship of the Ring could have faltered without strong leadership, a fragmented cybersecurity approach can lead to gaps in defense, miscommunications, and inefficiencies. It's crucial for organizations to balance the approach of using specialized security solutions with strong foundational components, such as the SIEM.

Organizations should aim to emulate the Fellowship's model: diverse and specialized, yet harmoniously integrated under effective leadership. This approach ensures that while each security component operates with its expertise, they all contribute to a cohesive, robust defense mechanism.

Embracing Elrond's Wisdom

In "The Lord of the Rings," Elrond, the wise elf lord, advocates for the destruction of the One Ring to prevent its catastrophic potential. This perspective is valuable in the context of cybersecurity. Organizations should be wary of over-consolidation in their cybersecurity solutions. It's crucial to maintain a balance between the convenience of a unified platform and the need for specialized, adaptable security measures. 

Next time Sauron comes to you with the amazing idea of this One Ring, listen to Elrond: “The Ring must be destroyed!"

Striking the Right Balance

In summary, while the pursuit of streamlined cybersecurity solutions is understandable, it's vital to recognize the dangers of over-consolidation. Like the One Ring in Tolkien's narrative, a singular, all-powerful cybersecurity solution could lead to unforeseen vulnerabilities and a lack of flexibility. Organizations should strive to strike a balance, ensuring that their cybersecurity posture is both comprehensive and adaptable, capable of responding to an ever-evolving threat landscape.

By heeding the lessons from Middle Earth, we can navigate the complex world of cybersecurity more wisely and effectively.

I've seen many comparisons with very complex things we've managed to accomplish. Man on the Moon, robots on Mars, etc. "We've manged to do all those things, how come there are still breaches happening?". Why can't we take a "just do it" approach for cybersecurity?

Well, for many reasons. 

First, resources available. The cost of the Apollo program was around $257 BILLION (inflation adjusted). That was all spent on a very specific, point in time objective, to put a man on the Moon. Some might say we've been spending close to that every year on security, but that's for the entire global cybersecurity market. Project Apollo built only 15 flight-capable Saturn V rockers.  

The Saturn V Rocket

The world spends hundreds of billions in cybersecurity every year, but that money is to cover all organizations out there. There's an estimate of 300 million business worldwide. Of course, the majority are SMB, but that means the annual average expense in cybersecurity is less than a thousand dollars. There is a lot of money on this business, but it is spread thin and unevenly.

Second, it is a moving target. All the technology and ingenuity embarked on the Curiosity rover is impressive, a feat of engineering. It came with a $2.5B price tag, and it has been performing remarkably well. But how successful would Curiosity be if we just decided to drop it in Venus? Or Jupiter?

The Curiosity Mars Rover

Venus atmosphere is extremely hot and dense. The surface level pressure is almost a hundred times Earth's atmosphere or almost 20.000 times Mars atmosphere. To make things worse, there are cloud of highly corrosive sulfuric acid. As advanced as the Mars rover is, it wouldn't survive in Venus.

In cybersecurity we are often judged by how well our Mars rovers perform in Venus like environments. The conditions where the technology operates change dramatically. Look at all the technology changes we've been experiencing in the last 20 years. We are talking about a period when Amazon, Google and Facebook surged from startups to corporate behemoths, smartphones and tablets became ubiquitous and the web moved from 1 to 2.0 and then to the cloud. The field where cybersecurity plays now is different than what it was in 2015, 2010 or 2001. Have we managed to "solve the security problem"? We would do extremely well playing in that 2001, maybe even the 2010 scenario but the goalposts have moved from there and are still moving ahead.

And last, the major issue we face, the "sentient adversary". What does that mean? It means we are not solving a fixed problem. From a problem domain perspective, we are not dealing with engineering, it is game theory. We have a non-zero-sum game to deal with. Our "problem" has smart people on the other side, with motivations and constantly developing new strategies to win. Together with the changing playing field from point #2, it makes a considerable challenge. The problem today is not the same as yesterday, and it will be different tomorrow as well. The adversaries think "outside the box", putting cybersecurity in a domain where it can't be solved even by existing AI bleeding-edge technology. The adversary puts cybersecurity in the same realm as crime and terrorism. We can't just "solve it".

"Just Do It" may work as a sneakers slogan, but for cybersecurity, the approach must be different.  In this space what we need is the OODA loop: Observe, Orient, Decide, Act*. Not as catchy, but it gives a chance to survive to fight another day.

* For cybersecurity I like to use "Adapt" instead of "Act", but the spirit is the same.

Root causes are behind accidents and other unintentional events. Not breaches.

Do you want to know the root cause of a breach? No, it is not a vulnerability that was left unpatched. If you follow the chain of events, someone decided to look for it, assembled a plan of attack, was driven by a motivation...all that at the attacker side.

Defence should look at breaches from a multi-factor point of view. Many things have to go wrong for an attack to be successful and cause harm. You may have a vulnerability providing initial access, but what about allowing privileged access? Lateral movement? Exfiltration, or mass encryption for impact? And why weren't you able to detect and respond to each one of those steps?

Post-mortem analysis usually take the approach of looking at multiple points and is better suited for security incidents. I usually do not like to use project management techniques for security needs, but on this case, I believe it makes sense.

In short, no RCA for your breaches. Take a broader approach and perform a post-mortem analysis.

I didn't need these certifications for my current job, and I'm not looking for a new one either, so this is not about job requirements or job hunting. So why did I do it?

I did it because I could do it :-) Well, ok, let me elaborate a bit. My career has been slowly moving away from more technical roles, and that's reducing my direct, hands on contact with technology. I don't think this is a bad thing, but as someone with the technical background, I miss that deeper understanding of the things I need to talk and write about.

At the same time, I do not have the same drive to learn things that I do not have an immediate need for, learning just for the sake of learning. I still love learning new things, but that youth drive of building labs and labs for learning things we may never touch as part of our job is just not there anymore. Putting a target like a certification in front of me (and paying for it) seems to be an effective way to trigger my brain into "I need to learn this" mode. I learned many things in the past while preparing for getting certs, so I thought I could use the same method again. It was nice, it worked well for this intent.

Cloud adoption keeps growing and cloud is directly affecting the work of anyone in security these days. It's not different for me: I work for a Cloud SIEM vendor, and we are bringing many innovations to the SIEM space that are directly related to cloud. Securonix recently announced "Bring Your Own Cloud", for example, and it is deeply rooted in AWS offerings, so it seemed natural to me that I should put a couple of AWS certs in my project. AWS Cloud Practitioner helped me learn more about the very broad range of offerings from AWS, and the security specialty was useful to provide more depth to my understanding of cloud threats and cloud security controls.

In addition to the AWS certs, I wanted to add the (ISC)2 CCSP to the mix as well. I checked the domain of knowledge of the cert, ran through a few practice exams and noticed I already had most of the skills and knowledge required to pass it. So why didn't I do it? Because it's freaking expensive! USD600 is beyond any reasonable justification for a simple multiple-choice exam. Maybe I would take it if I was looking for a job like cloud security architect, or even as a CISO for a company with a strong cloud presence, but just for the fun of doing it? No, I'm sorry, it doesn't make any sense. 

An Azure cert was a natural choice to complete my project. AWS and Azure are by far the most visible cloud providers (sorry Google!), so going through the process for both looked like the best choice.

There are a few things I noticed during this exercise that I think it's worth sharing. First, it confirmed to me that test taking talent is really a thing. I'm a helluva test taker. I'm not bragging; apart from helping me pass tests and exams easily, it doesn't provide me with any real competitive advantage "on the job". I've always been like that and was happy to see I haven't lost it after so many years without sitting for a test. I didn’t spend more than a handful of hours reading for the full project. I don’t feel nervous and even have fun while taking the tests, so everything was a fun experience.

But when you are a hiring manager and you see those certs in a resume, it's always important to find out if those certs came from real experience or just from good test taking skills (or worse, memorizing those awful brain dumps).

Don't get me wrong, it doesn't mean that certs on a resume means nothing. Remember, the main reason for me to do it was to force me into learning something about those technologies. Even if I don't have the hands-on experience the test developers were trying to verify with these exams, I still had to at least read a bit and get solid understanding of the basic concepts. 

Talking about basic concepts...if you want to get certs, LEARN THE F* BASICS! You can't believe the number of questions I was able to answer because of basic stuff, not necessarily tied to those specific cloud providers. If you know how crypto works, for example, a lot of the AWS security specialty questions will be very easy to answer. Same thing for networking and network security. AWS security groups, network ACLs, Azure network security groups...those are straightforward to learn when you know those things well. I didn't take the real CCSP, but the practice questions I've done indicate that CISSP level concepts would put more than half of way behind you on that one.

Finally, some interesting bits about AWS and Azure I was able to notice:

·      Knowing the basics of one of those means you have almost all the basics of the other. Key concepts are virtually identical. 

·      The naming convention of Azure is AWESOME. It's very easy to know what products and services do just from their names. They may not sound as sexy as "Athena", "Glacier", or high tech as “S3”, “EC2”, but they tell you in a very simple manner what they are about.

·      Both services are evolving so fast it's hard to keep study material, documentation and questions aligned and up to date on the latest offerings. Don't be surprised to see questions about things you didn't see in your study material. Check some of the announcements and blog posts from the past year as part of your study work.

·      AWS Security Specialty is the one I see closest to being "hard". There's really a lot of stuff to cover, in a relatively deep level of detail: Networking, Crypto, IAM, logging, policies syntax and small idiosyncrasies. I can see how it really tries to assess real experience on AWS security.

Am I done with the certs now? Maybe, not sure. It may become an expensive hobby :-). Well...those Azure security certs do not look that hard, I still have that 50% off voucher for AWS exams and I really need to spend some time learning about Google cloud ;-)

P.S. As I’m doing this during the COVID-19 pandemic, I took these tests in the “online proctored” mode. THEY SUCK! I was expecting those VUE, PSI guys would have learned by now how to do it right. No, they tech and processes are horrible. I had problems during the 3 exams, one with PSI (AWS Practitioner), the worst one, and two with VUE. If you are a person that gets anxious or nervous during the exam, this is definitely not for you. Some of the issues I had to go through would take many candidates out of their minds and strongly impair their ability to answer the questions.

There are many reasons, including:

• The high importance of SIEM’s role for security operations: The SIEM is often the foundation of Security Operation Centers and has a critical role in their work. It is natural to see it being constantly evaluated and discussed as it has a role in almost all SOC processes.

• Cost and budget share: SIEM is not cheap. It usually takes a big chunk of the security budget. Organizations will keep trying to reduce it as part of their cost optimization efforts, while vendors of other technologies will keep trying to sell their products as alternatives to tap into existing SIEM budgets.

• Operational effort required: SIEM is definitely not a “set and forget” tool. This is not a deficiency per se, as other technologies, such as EDR, also require people to deliver value. But the concerns about how much effort must be put into SIEM operations is a constant driver of discussions about improvements or even replacements of this technology.

• Multitude of experiences: SIEM has been around for more than 20 years. Many professionals have gone through multiple implementations, sometimes with good experiences, sometimes not so much. I’ve seen many people with very strong opinions on SIEM based on their personal experiences with this type of tool, experiences that many times are not representative of how SIEMs can support security initiatives.

• Evolution of other technologies and of the entire technology landscape: As other technologies evolve, it is inevitable to look at how they impact the role of SIEM. It happened with UEBA, it happened with SOAR, it is happening with XDR. The technology environments where these tools operate are also constantly evolving. Big SAN storage systems came up, virtualization became ubiquitous, big data spread out like wildfire. These changes affect the security tools we use to protect IT environments in multiple ways. Some increased the amount of data to be collected and processed, while others were used to evolve SIEM and make it more scalable and capable.

Nothing is more important to those discussions as Cloud SIEM. Not just “hosted” in the cloud, but as a native cloud offering. Why? Because now SIEM vendors can have some control over deployment success. What are you saying, Augusto? Didn’t they have control over the success of their own product before? Yes, that’s true!

As a traditional SIEM vendor, it is very hard for you to ensure the customer will be able to get all the benefits your product can provide. First, they may underestimate the required capacity for their environment. They will end with a sluggish product, overflowing with data, having to deal with adding servers, memory, storage, or even stopping the deployment to rearchitect the whole solution before getting any value from it. I’ve seen countless SIEM deployments dying this way before generating any return of investment.

But it doesn’t stop there. They may get the sizing right but underestimate the effort to keep it running. They estimate the number of people to use the SIEM, but they forget that a traditional SIEM requires people to use it but also to keep it running. That means people will spend their time keeping servers running, applying patches (to operating systems, middleware and to the SIEM software too), troubleshooting log collection, ensuring storage doesn’t blow up, and not paying attention to what the SIEM should actually be doing for them. The tool is up and running, but again, not providing any value.

We can see how much the vendor depends on the customer to provide value. And even if the customers do things properly, there are other challenges too. Traditional software allows for high variation of deployments: Customers running on different versions, with different hardware and architecture. How can a vendor distribute SIEM content (parsers, rules, machine learning models, etc) that works in a consistent manner to its customers in this scenario? It just can’t.

Considering these factors, I risk saying that offering a traditional SIEM solution is like the Sisyphus Myth. As much as the vendor tries to deliver value, the solution will eventually fail to achieve the customer objectives. As traditional software, SIEM was really destined to die.

How does the cloud SIEM change this?

First, many challenges on SIEM deployments are related to problems that are completely solved or minimized by the SaaS model. Cloud services are highly scalable and elastic, and SaaS practically eliminates the need to maintain the application and underlying components. Now you have a SIEM that finally scales and does not require an army to keep it running. You can focus on using it appropriately.

Second, a SaaS SIEM puts customers on highly standardized deployments. With most customers running on the same version, without capacity challenges, it’s far easier to deliver content that works for all of them. That makes a huge difference in perceived value. And it doesn’t stop there. With this scenario it becomes easier to the vendor to finally realize the benefits of the “wisdom of the crowds”. Developing more complex ML models for threat detection, for example, becomes easier and more effective. The vendor now has access to more data to train and tune the models. Even simple IOC match detection content can be quickly developed and delivered to all customers, allowing the SIEM vendor to provide detection of new, in the wild threats.

Finally, delivering any software solution via SaaS gives the developer the opportunity to embrace more agile development practices. Upgrading a traditional SIEM deployment is so complex that vendors would naturally rely on traditional waterfall development practices, generating big releases with long times between them. SaaS SIEM can leverage agile development and CI/CD practices, so new features can be quickly added, and defects quickly fixed.

Cloud SIEM is on its infancy when you consider SIEM is just past its teenage years. But there are so many opportunities to explore with this model that I believe now we can say “Next-Gen SIEM” without feeling silly about it. Be careful with “SIEM is dead” claims. That sounds to me much like "I think there is a world market for maybe five computers", by Thomas Watson in 1943.

The simplistic question of "Will machines replace humans in a SOC" can be clearly answered with a NO, as I explained in my previous post. As the human attackers are required to evolve the attacking robots, blue team people are required to update the automated defenses.

But things change if the question is asked with some additional nuance. If you ask "will defense actions be automated end to end, from detection to response actions?", it becomes a more interesting question to answer.

The scenario of automated threats that Anton described in his post will, IMO, require SOCs to put together some end to end automation. Having a human involved for every response will not scale to face those attacks. Humans will be responsible for creating those playbooks and monitor their performance, but they cannot be involved in their execution. We need SOC automation that allows us to detect, investigate and initiate response without human intervention. This is challenging, but we must get there at some point.

Andre Gironda commented on the LinkedIn post pointing to my blog post that even with the appropriate tools he still can't fully automate simple phishing response. I could say he's probably being too perfectionist or doing something wrong, but I actually believe him. I believe automation can provide value by reducing human effort in the SOC right now, but full automation, even for some specific threats, is still challenging. But we'll have to get there if we want to stand a chance.

After that Anton brought up a very interesting follow up, confirming that view but also pointing to a scary future scenario, where automation would be adopted so extensively by the attackers that it would force defense to do the same. Does this scenario make sense? 

I believe it does, and indeed it forces defense to adopt more automation. But even if Anton says the middle ground position is "cheating", I still think it is the most reasonable one. There will never be (until we reach the Singularity) a fully automated SOC, just as there will never be a fully automated attacker (until...you know). Why? Let's look at the scenario Anton painted for this evolved attacker:

• You face the attacker in possession of a machine that can auto-generate reliable zero day exploits and then use them (an upgraded version of what was the subject of 2016 DARPA Grand Challenge)

• You face the attackers who use worms for everything, and these are not the dumb 2003 worms, but these are coded by the best of the best of the offensive “community”

• Your threat assessment indicates that “your” attackers are adopting automation faster than you are and the delta is increasing (and the speed of increase is growing).

Even if it looks scary, this scenario is still limited in certain points. You may have malware capable of creating exploits by itself, but what will they exploit? What is this exploitation trying to accomplish? There is an abstract level of actions that is defined by the creator of the malware. Using MITRE ATT&CK language, the malware is capable of generating multiple instances of a selection of techniques, but a human must define the tactics and select the techniques to be used. Quoting Rumsfeld, there will be more known unknowns, but the unknown unknown is still the realm of humans.

A few years ago, I had a similar discussion with a vendor claiming that their deep learning-based technology would be able to detect"any malware". This is nonsense. Even the most advanced ML still needs to be pointed to some data to look at. If the signal required to detect something is not in that data, there's no miracle. Let's look at a simple example:

• A super network-based detection technology inspects ALL network traffic and can miraculously identify any attack.

• The attacker is on host A in this network, planning to attack host B, connected to the same network

• The attacker scans for Bluetooth devices from host A, finds host B, exploits host B via a Bluetooth exploit

• The super NDR/NIDS tool sits there patiently waiting to see an attack that never traverses the monitored network!

You may claim this is an edge scenario, but I'm using anexaggerated situation on purpose. There’s still many cases that we can relate to, such as breaches due to the use of shadow IT, cloud resources, etc. What I want to highlight is the type of lateral thinking very often employed by attackers in cybersecurity. And the lateral thinking is still exclusive of humans.

What I'm trying to say is that fully automated threats are scary, buy they lack the main force that makes detecting threats challenging. Defense automation can evolve to match the same level, but both sides will still rely on humans to tip the scale when those machines reach a balance point in capabilities.

What we have today is similar to those battling robots TV shows. Machines operated by humans. If things evolve as Anton suggests we will move to what happens in "robot soccer": human created machines operating autonomously, but within a finite framework of capabilities.

Robot wars vs Robot Soccer

Threats and SOCs will become more automated for sure. As they automate, they become faster, so each side has to increase its own level of automation to keep up. But when automation limits are reached, the humans on the threat side must apply that lateral thinking to find other avenues to exploit. They need to take the Kirk approach to Kobayashi Maru. When this happens, the humans on the defense side become critical. They need to figure out what is happening and create new ways to fight against the new methods.

So, humans will still be necessary on both sides. Of course, the operational involvement will be greatly reduced, again, on both sides. But they will be there, waiting to react against the innovation introduced by their counterparts on the other side.

This may be an anticlimactic conclusion, and it is. But there are some interesting follow up conversations to have. The number of humans required, their skills and how they are engaged will be different. What does it mean for outsourcing? Do end users still need people on their side? If solution providers engage this problem in a smart way, we may be able to remove, or greatly reduce, the need for humans on the end user organization side, for example. The remaining humans would be on the vendor side, adapting the tools to react against the latest attacks. For the end user organization, the result may look very similar to full automation, as they would not need to add their humans to the mix. Will we end up with the mythical "SOC in a box"? Future will tell.