The New Era with Agentic SOC

Agentic SOC: The Separation of detection, enrichment and triage

In recent years, emerging technology has started to pave the way for new SOC architectures. Historically, SIEM platforms have been built around a more monolithic approach: Ingest all the data, run detections, and notify analysts of alerts to investigate. However, this single-system approach is becoming unsustainable due to the increasing volume of telemetry and the growing sophistication of attackers.

Rising technologies are starting to break the mold by enabling architectures that are evolving with today's landscape. Security Data Pipeline Platforms (SDPP) and Generative AI have been two breakthroughs that have given birth to the Agentic SOC. SOC teams are no longer reliant on the outdated SIEM model. The ability to leverage enrichment, storage, detection and triage as their own, independent layers is becoming the new standard.

The monolithic problem

Workflows of the past, and still today, have pushed most of the logic behind data ingestion and processing; Correlation rules are running post-ingest, often during query time; Enrichments are actions taken once an alert has been triggered; And triage is largely done by SOC analysts. What was once the industry-accepted standard is unable to keep pace with today's landscape due to several fundamental issues.

The Analyst's problem: Triaging alerts is predicated on the quantity of hired personnel, skill sets, and bandwidth. If anyone of these is lacking, then the quality and speed of investigations are the first to be impacted. Not to mention, differentiating between noise from true incidents becomes much more difficult. Automations help solve a portion of the problem, but this requires a "human in the loop" approach that faces scaling limitations on many fronts.
Workflows and Detections: Workflows in today's SOC are tied to a single option for storage, schema, and query language which can introduce many native limitations. Unless teams are leveraging passthrough rules for 3rd party sources, detections are also reliant on the vendor. To cover gaps and blind spots that OOTB features don't address, custom correlations and queries can be created. The common issue with this lies within the data. Unless an organization has a complete data strategy, correlating across many data sets can get complicated quickly, especially in "ad-hoc" situations.
Price Tag and Vendor lock-in: With the explosion of telemetry that we see today, the model of ingesting everything is no longer feasible. Traditional SIEM architecture relies on the logs being in their own data lake, which has created the age-old question: "To ingest, or not to ingest". An additional barrier caused by vendor data lakes is that most of these storage solutions are often closed, meaning that no other third parties can access the data. Goodbye, dreams of moving data and leveraging outside AI models; Hello, vendor lock-in.
Alert Fatigue: When enrichment, detection and triaging are all contained within the same model, limitations exist. The lack of flexibility with this architecture keeps us at a stalemate with issues like alert fatigue. For years, two primary options have existed: Automate the redundant or create allow/deny lists. This is also a highly unsustainable model that requires tons of human effort.

These issues have been around for years, and until recently have been somewhat manageable. However, in today's market, these problems are being amplified to a scale that cannot be simply ignored. Allow lists, automation, and tuning ingestion are no longer viable solutions. A major shift has occurred in how we create our data, so a corresponding shift is needed in how we leverage it as well.

The layered approach

The SOC of the Future, also referred to as "The Agentic SOC," is not a product as much as it is a framework. It's a method of examining an architecture and breaking down its primary components into core pillars to isolate and better understand each function. In the past, one platform was used to handle enrichment, storage, detection, and triage.

The biggest weakness is that most vendors excel in only a couple of those pillars and often fall short in the others. Thanks to innovation, technologies have undergone a separation of duties, and the market is left with strong vendors that excel in working together, rather than being independent solutions. Let's take a further look at a layered approach.

Layer 1 and 2: Enrichment and storage

Layer 1 in the Agentic SOC focuses on data and how it's ingested, transformed, and enriched. In the past, this was a stiff process with many limitations. For example, Logs were ingested with minimal transformational abilities. Running real-time analysis on data feeds to drop logs was mediocre at best, often failing to achieve the desired outcomes. The ability to enrich logs prior to ingestion was also a massive shortfall.

The combination of high noise levels combined with low-contextual logs is the perfect storm for alert fatigue, redundant workflows, and high SIEM costs. Security Data Pipeline Platforms have provided a significantly better technology that works in nearly every ecosystem. These solutions are focused on filling the gap where monolithic architecture fails:

Analysis on ingestion to provide much more granularity to what is kept, dropped, and forwarded. Further noise reduction capabilities also allow logs to be deduped, grouped and summarized at ingest.
Dynamic routing of data helps facilitate logging compliance, alleviate SIEM costs, and accelerate technology migrations.
Enrichment of data at ingestion through APIs, lookup tables, files and asset inventory solutions greatly enhances the context of logs. As a result, alerts are more intelligent, correlation rules are easier to create and triage time is reduced.

Simply put, SDPP creates a "shift left" approach. I recently wrote an article that explores this concept further, and I'd refer you to "Building Better Detections with Data Pipelines".

At layer 2 is the storage layer. Several solutions are emerging that move detections away from traditional SIEM products and perform more correlation at the source. The thought process is, "don't bring the data to the rules, bring the rules to the data".

This is a fantastic concept that I wholeheartedly love. However, this presents a gap for compliance requirements and organizations that want to leverage their data with LLMs and Behavioral Analytics. This is where data lakes come to play, and to be honest, capabilities are beginning to blend. Vendors like Snowflake and Databricks are developing search and analytics capabilities ,while companies like Cribl are stepping into the Data Lake space as well.

Layer 3: Detection fabric

Similar to traditional SIEM products, the goal of the detection fabric layer is to identify threats. The difference here is that most of these DE (Detection Engineering) platforms apply logic to the data wherever it's at and in whatever format it's in. This is a much more simplified, streamlined and repeatable approach that alleviates workloads and skillsets from the smallest SOC to the most complex organizations.

Perform correlation across many disparate sets of data
Strongly align with MITRE ATT&CK
Build and leverage "Detection-as-code" libraries and repositories
Natively built to use AI models and Copilots to help write new detections and identify coverage gaps

I don't believe that the SIEM is going anywhere, anytime soon. But vendors in this space are solving very real problems that SIEM owners face today.

Layer 4: Triage and Analysis

Arguably, the most important aspect of a SOC is the ability to triage alerts. Logs can be tuned, and automation can be implemented, but at the end of the day, there is still a large amount of human capital required. Even with highly sophisticated automation, "Human in the loop" models still require efforts that are difficult to scale in today's landscape. Attacks are being discovered and performed at AI speeds and need to be met with the same.

You've likely heard the terms Autonomous SOC or Hyper SOC through industry reports and marketing events. But, if you are anything like me, that can be difficult to accurately define. Being a triage and analysis layer, this is solely focused on post-alert activity. I mentioned before that triaging alerts are predicated on quantity of hired personnel, skill sets, and bandwidth. Autonomous and Hyper SOCs are built to meet the pitfalls between human capital and scaling.

Provide alert summarization with context from past alerts, OSINT, internal models, and reasoning
Assist in providing response actions with awareness technologies and hosts involved
Track and preserve steps taken in an investigation for future reporting
Automate the process of intelligently gathering required evidence to evaluate

Layer overview

Conclusion

With AI and telemetry on this rise, our solutions must be ready to scale and meet the demand that our organizations and threats place on them. Human capital, scalability and cost are three pain points that have been around since the birth of SIEM, but emerging vendors are showing up to combat these in a more intelligible way. Ready or not, change is here. Instead of fearing it, embrace it. We are in a time where organizations must adapt or be overcome.