A Credible SOC: What Lies Behind the Promise of Visibility

Many SOC offerings promise total visibility. In reality, three levers determine the actual ability to detect an intrusion: how logs are collected and filtered, the number and quality of detection use cases, and how AI amplifies the work of analysts. Here's the breakdown.

Introduction

A SOC's (Security Operations Center) job comes down to one word: seeing. Seeing what is happening across the information system, in near real time, and telling normal noise apart from an attack signal. But between the sales promise and operational reality, the gap can be considerable.

A SOC can ingest terabytes of logs and remain blind to what matters. It can display an impressive dashboard while letting an intrusion go unnoticed for weeks. The difference doesn't come down to the volume on display, but to three foundations that reinforce one another. That's what we unpack here.

1. Collect, Centralize, Filter: The Heart of the Battle

Why centralize everything

A SOC's reason for being is the centralization of events. By gathering logs from across the whole IS into a single point (the SIEM, or a security data lake platform), you can correlate events that, taken in isolation, mean nothing. A failed authentication on a server is just a log line. Fifty failures followed by a success, then a connection from an unusual country, then access to a sensitive share: that's an attack chain. Only centralization makes it possible to reconstruct it.

The ultimate goal is not to accumulate logs, but to produce the finest possible detection use cases. And a fine-grained use case needs the right data, properly structured.

The constraint no one can ignore: volume

This is where reality reasserts itself. Most SIEMs are billed by volume:

• by GB/day ingested (the model used by Microsoft Sentinel, Splunk by indexed volume, etc.),
• or by EPS (events per second).

The direct consequence: every log costs money, in licensing, storage, and performance. The naive "collect everything" approach quickly hits a wall: budget blowout, slower searches, and above all analysts drowning in noise.

The mature approach is to collect the right data, not all the data.

Filter intelligently, without creating blind spots

A few practices that make the difference:

• Prioritize high-detection-value sources: identity (Active Directory, IAM, identity provider), endpoints/EDR, firewalls, proxy/DNS, cloud control plane, critical applications. These carry the bulk of the use cases.
• Filter at the source: strip out verbose noise with no detection value (certain purely informational events, health checks, known high-volume internal flows). But beware: this filtering must be a documented and reversible risk decision, never a cost-cutting reflex.
• Normalize to a common schema (ECS, ASIM, OCSF). Normalized data makes detection rules portable and correlation possible across heterogeneous sources.
• Enrich: IP geolocation, threat intelligence, asset criticality, identity context. One enriched log is worth ten raw ones.
• Tier your storage: a "hot" tier that is searchable for detection, and a low-cost "cold"/archive tier for compliance and forensics. This way you keep raw data for retro-hunting without paying full price for it.

⚠️ The over-filtering trap. Filtering to cut the bill is legitimate, but every source you cut is a window closed. DNS-based exfiltration, for example, will be invisible if the DNS logs were dropped "because they generated too much volume." The golden rule: document what you discard and why, and keep the raw data in cheap storage where possible.

When the platform's model changes the equation

Part of this cost/visibility trade-off comes from the billing model itself. That is precisely what we set out to remove when choosing our platform, Sekoia. Rather than billing by volume or EPS, Sekoia relies on a pricing model based on the number of protected assets, not on data volume. The concrete consequence: you are no longer financially penalized for every additional source you connect, and the question "is this log worth its ingestion cost?" comes up far less often.

Beyond the economic model, several characteristics directly serve detection precision:

• Native CTI integrated into the rules. Detection rules incorporate threat intelligence, which makes it possible to spot weak signals and anticipate threats rather than react after the fact.
• An open XDR approach with a broad integration catalog — more than 200 integrable third-party tools and several hundred verified and maintained rules — which drastically reduces source onboarding time and normalization effort.
• An open rule format: the open format lets you know exactly why a rule fired and how to triage it. This is a major asset for fine-tuning and reducing false positives.
• A European sovereign solution, an argument that is far from anecdotal in the NIS2 / DORA regulatory context and for organizations subject to strong trust requirements.

(Note: we cite our own tooling here as a concrete example; the principles described hold regardless of the SIEM/XDR you choose.)

2. Use Cases: The True Measure of a SOC

The "showcase" offering problem

Many SOCs, particularly some MSSPs, sell a limited and fixed number of use cases — often a few dozen generic correlation rules. It looks appealing on paper, but it mechanically produces wide blind spots across the attack surface. Concretely: entire families of attack techniques trigger no alert at all. The intrusion gets through, not because it's sophisticated, but because no one was watching in that direction.

The right lens is not the raw number of rules, but coverage measured against MITRE ATT&CK: which tactics and techniques are actually detected, and where the gaps are.

Examples of essential use cases, by technology

Network / Firewall 

• Port scans and network sweeps 
• Traffic to malicious IPs/domains (threat intel) and C2 beaconing (regular, periodic communications) 
• Abnormal spike in denied connections 
• Exfiltration: abnormal outbound volume, DNS tunneling 
• Connections from unexpected geographies - Unusual east-west lateral movement (SMB, RDP between hosts)

System / Endpoint (Windows & Linux) 

• Brute force and password spray against authentication 
• Privilege escalation and additions to privileged groups 
• Persistence: scheduled tasks, services, Run keys, cron 
• Credential dumping (access to the LSASS process) 
• Suspicious execution: encoded/obfuscated PowerShell, LOLBins (mshta, rundll32, certutil…) 
• Disabling EDR/antivirus, clearing event logs

Identity / Active Directory / IAM 

• Kerberoasting and AS-REP roasting 
• DCSync / abnormal replication from a non-DC account 
• Kerberos anomalies (golden/silver ticket) 
• Off-hours logins, from dormant accounts

Cloud (AWS / Azure / GCP / M365) 

• Impossible travel and login from a new IP/geography 
• MFA disabled or security policy modification 
• Creation of a role or a highly privileged account 
• Access keys created or used abnormally 
• Publicly exposed storage (public S3 bucket / Blob) 
• OAuth consent to a suspicious application, email forwarding rules (a classic Business Email Compromise signal) 
• Mass data download

Web / Proxy / Email 

• Access to newly registered domains 
• Application-layer beaconing 
• Malicious URLs and attachments (phishing)

How many use cases for a credible SOC?

Let's be clear: pitting quantity against quality is a false trail. It is better to deploy broadly and clean up during onboarding than to start with too few. The reason lies in an asymmetry of costs: a missing rule is a guaranteed, silent blind spot, you'll never know what you're missing, whereas an overly noisy rule is still a signal you can refine, suspend, or remove. Disabling is reversible and cheap; a missed detection is irreversible.

The right doctrine is therefore to enable broad coverage from the outset, then tune it continuously, with the onboarding phase being the ideal window to learn the environment's baseline and calibrate thresholds. Just one condition so it doesn't turn against the analysts: have the tuning capacity to actually do that cleanup. The proven approach is to deploy broadly in audit / monitoring mode (or with severity gating), then promote rules to alerting as they get tuned. The trap is never the number of rules: it's "set and forget."

What matters, then, is not a raw figure, but broad coverage that is steered and refined. As a guide, here are the orders of magnitude to aim for once tuning has stabilized:

Rather than a magic number, set a coverage floor: aim for the 20 to 30 most prevalent ATT&CK techniques (depending on your sector and threat reports), spread across all tactics: initial access, execution, persistence, privilege escalation, defense evasion, credential access, discovery, lateral movement, collection, C2, exfiltration, impact. In practice, this translates to 50 to 100 tuned use cases at a minimum.

To make that floor actionable, here is an indicative breakdown by category, ranges, not dogma, to weight according to your exposure:

The total naturally lands in the 50 to 100 tuned use case range. Note: the identity category is deliberately the most heavily weighted, it is today the primary compromise vector, and the mandatory waypoint of most attacks.

Sector-specific CTI: moving from generic to relevant

A generic use case detects a technique "in the abstract." Sector-specific CTI (Cyber Threat Intelligence) turns it into detection targeted at the threats that actually aim at you. The difference is far from cosmetic:

• Real-risk prioritization. A banking player doesn't face the same groups as a hospital or an industrial firm. Finance is over-exposed to banking trojans, wire-transfer fraud, and specialized ransomware groups; healthcare, to data theft and ransomware; industry, to OT/ICS-targeting threats; the public sector, to state-sponsored espionage. Sector CTI focuses detection and hunting effort on those specific TTPs.
• Weak-signal detection and anticipation. IOCs and TTPs qualified before they hit you make it possible to detect upstream, or even block proactively.
• Noise reduction. By contextualizing alerts (is this IOC linked to an actor active in my sector?), you reduce false positives and speed up triage.
• Context for decision-making. Verified, enriched CTI also helps the CISO prioritize patching, allocate budgets, and raise awareness with management.

This is precisely the value of native CTI integrated into the platform (see Part 1): the rules don't just match a pattern, they know who that pattern is associated with and how relevant it is to you.

A SOC's true metric is not the number of rules, but: its ATT&CK coverage percentage, its false-positive rate, and its ability to detect a red team / purple team exercise. A SOC that cannot say what it does not cover is not a mature SOC.

3. AI and Agents in the SOC: What Do They Actually Solve?

The ills of the classic SOC

Before talking solutions, let's recall the structural problems: 

• Alert fatigue: thousands of alerts a day, a majority of them false positives. 
• Analyst shortage and high turnover, with knowledge lost at every departure. 
• Slow triage and investigation: detection (MTTD) and response (MTTR) times that are sometimes measured in days.

What AI brings

• Automated triage and prioritization: scoring, deduplication, grouping of alerts into coherent incidents.
• False-positive reduction: by leveraging context and the history of past decisions.
• Behavioral detection (UEBA): establishing baselines per user/entity to spot the anomaly — useful against unknown threats, where static rules fail.
• Faster investigation: automatic enrichment, context retrieval, and incident summaries in natural language.
• Natural-language interface: querying logs without mastering the SIEM's query language.
• 
  

What agents bring (agentic AI)

This is the recent breakthrough. An agent doesn't merely classify an alert, it runs the investigation: 

• it takes an alert and gathers evidence (enriches IOCs, queries the EDR, cross-references identity logs, pulls related events), 
• it reconstructs a timeline, proposes a verdict and recommended actions, 
• it can orchestrate the response (SOAR logic), isolate a host, disable an account, block an IP, with human approval gates on sensitive actions, 
• it assists detection engineering by suggesting new rules and pinpointing coverage gaps against ATT&CK.

The problems solved

• Scaling without linear headcount growth.
• Significantly reducing MTTD and MTTR.
• Freeing analysts for complex threats, hunting, and detection engineering.
• Bringing consistency: reproducible triage that doesn't depend on how tired the on-call analyst is.

The limits to keep in mind

AI is not a magic wand, and saying so reinforces the credibility of the approach: 

• The human in the loop remains essential for impactful response actions. 
• Risk of hallucination and over-trust: verification and explainability are needed. 
• Data governance and confidentiality: what do you send to an AI engine, and with what guarantees? 
• Garbage in, garbage out: AI plugged into poor telemetry or holed coverage (Parts 1 and 2) will only automate the blindness. 
• A new attack surface: adversaries use AI too, and agentic workflows expose you to the risk of prompt injection.

The real arbiter: detection quality, not headcount

This is the point worth hammering home. A SOC is measured neither by the number of analysts on the org chart nor by the number of AI agents deployed. Those figures are means, not results. You can pile analysts onto mediocre detection and produce nothing but triage of noise; you can multiply AI agents over holed coverage and merely industrialize the blind spot faster.

What matters is the detection quality actually produced, and it is measured by: 

• real ATT&CK coverage and its acknowledged gaps, 
• MTTD / MTTR (detection and response speed), 
• the true-positive rate and control over false positives, 
• dwell time (how long an attacker stays undetected), 
• and performance against red team / purple team exercises.

A five-person SOC with well-designed detection and relevant CTI will outperform a fifty-person SOC that is poorly equipped. AI and agents don't change this rule: they amplify it, in both directions.

Conclusion: Three Inseparable Pillars

A credible SOC comes down to none of these three elements taken in isolation. Rich, well-filtered telemetry (Part 1) feeds broad, ATT&CK-mapped use cases (Part 2), which AI and agents then amplify (Part 3).

Weakness in one caps the others: collecting without detecting is pointless, detecting without being able to handle the volume exhausts the teams, and automating on a flawed base merely industrializes the blind spots. And none of these pillars is judged by its size, neither by log volume, nor by the number of rules, nor by the number of analysts or AI agents, but by the detection quality it produces at the end of the chain. 

The real question to ask a SOC, your own as much as a provider's, is not "how much?", but: "what aren't you seeing, and how do you know?"