The SIEM Problem Is an Architecture Problem. So Is the Answer.

Network detection and response

For years, security teams tried to make the SIEM the center of the SOC.

Send the data there. Normalize it. Index it. Detect against it. Search it. Investigate the alerts. Then connect the SIEM to another system for response.

That model worked when security data volumes were smaller and the SOC technology stack was simpler. It is increasingly strained by the amount of telemetry security teams generate, the cost of moving and retaining it, and the number of systems involved in an investigation.

SACR captures the issue well in its recent report, The SIEM Problem Has Become an Architecture Problem. The question is no longer simply whether the SIEM has enough features. The larger question is how security data, detection, investigation, AI, and response fit together as a system.

And the telemetry itself keeps changing.

A vulnerability such as PHP2Shell may appear to be a specific detection problem. Architecturally, it is something broader: another source of evidence the SOC needs to absorb and correlate with everything it already knows. Today that evidence may come from an application, IDS, network sensor, endpoint, identity system, cloud service, or AI application. Tomorrow it will come from somewhere else.

A modern security platform therefore cannot be designed around a fixed set of telemetry sources. It has to assume that new evidence will continually appear — and be able to ingest it, normalize it, correlate it, and place it into the context of an existing incident.

That is the architectural shift.

Not Every Byte Needs to Live in the SIEM

A modern SOC generates evidence across endpoints, identities, networks, cloud infrastructure, applications, SaaS platforms, firewalls, and many other sources.

Treating every byte the same is neither technically necessary nor economically efficient.

Some telemetry needs to be immediately available for detection. Some provides investigation context. Some can remain in its original platform or lower-cost storage until an investigation requires it.

The architecture therefore needs to separate having access to evidence from copying all evidence into one repository.

That is especially important with high-volume sources such as EDR. Stellar Cyber can combine endpoint evidence with network, identity, cloud, and log data without requiring the SIEM to become the permanent home for every piece of endpoint telemetry.

Detection Is Only the Beginning

A detection is rarely the complete incident.

An analyst needs to know which user was involved, what asset was affected, what happened on the network, what occurred before and after the detection, and whether apparently separate signals are connected.

This is why native NDR has been fundamental to Stellar Cyber’s architecture from the beginning.

Network flow, session, protocol, and file-movement evidence can expose activity an endpoint alert or identity event alone may not show. Stellar Cyber correlates that evidence with endpoint, identity, cloud, application, vulnerability, threat-intelligence, and log telemetry in a common data and case model.

The case, rather than the individual alert, becomes the operational object.

That preserves evidence and context as an incident moves from detection through investigation, triage, decision, and response.

AI Makes Architecture More Important

Agentic AI raises the stakes further.

An AI agent can investigate only the evidence it can reach. Its conclusions depend on the context available to it. And the architecture must determine what data the agent can access, what actions it can take, and when a human needs to approve the next step.

Stellar Cyber applies different forms of AI across that operating loop.

Machine learning detects suspicious behavior. GraphML connects relationships among users, assets, alerts, and activity. LLMs support investigation and explanation. Agentic AI handles increasingly complex triage, hunting, and orchestration.

Crucially, they operate against shared evidence and a common case model rather than as another AI assistant sitting above an alert queue.

ISOC Is the Architectural Answer

The answer is not a bigger SIEM surrounded by more tools.

It is a platform designed with the assumption that new telemetry will keep appearing, that evidence will remain distributed across the environment, and that detection, investigation, AI, and response still need to operate from shared context.

That is the idea behind an Integrated Security Operations Center, or ISOC.

Integrated does not mean single-vendor. Existing endpoint, identity, firewall, cloud, application, and other security controls can remain in place. What changes is the operating architecture connecting their evidence, decisions, and actions.

Your security tools can stay different.

Your telemetry will keep changing.

Your SOC architecture has to be ready for both.

If the SIEM problem has become an architecture problem, ISOC is the architectural answer.

Scroll to Top