Hazem Elbaz

Before You Build Detection… Make Sure You Have Collection

Before You Build Detection… Make Sure You Have Collection

“There’s no detection without collection.”
This simple truth is one of the most overlooked principles in modern SOC operations.


🧠 Introduction

In every SOC I’ve seen, teams are eager to start writing use cases, mapping them to MITRE ATT&CK, creating SIEM rules, and claiming, “We’re ready to detect any attack.”

But too often, they skip the step that makes all of this possible: data collection.

Before your detection rules can work, your SOC must have a solid foundation of telemetry — without it, even the best detection logic will fail silently.


⚙️ Collection Comes Before Detection

A Security Operations Center is an engineered system. The detection layer can’t function if the foundation layer (Telemetry & Collection) is unstable.

You can have the most advanced correlation engine in the world, but if your critical systems aren’t generating or forwarding enough logs, your SOC will see nothing.

Every detection depends on observable facts from your sensors, agents, and integrations.
Missing even one essential source — such as Windows Security Event Logs, EDR process telemetry, or DNS traffic — can create massive blind spots.

This becomes critical during lateral movement or privilege escalation attempts, where visibility gaps can completely hide attacker activity.


🔍 Step One: Log Source Review

Before writing any detection rules, conduct a comprehensive log source review — not a superficial checklist, but a technical validation that answers:

  1. Is the source actually enabled and sending logs to the SIEM?
  2. Are the events complete, or are they truncated?
  3. Do the logs cover all necessary audit categories (authentication, file access, process creation, etc.)?
  4. Are the fields properly parsed and normalized?

This gives you a true view of data coverage, not the assumed one.
Only then can you safely connect your detection use cases to the log sources that actually support them.


🗺️ When There’s No Asset Inventory or Network Diagram

This is one of the most common challenges for new SOC teams.
You enter an environment with thousands of devices and servers — but no updated CMDB, and no clear network map.

In that case, use a Bottom-Up Visibility Mapping approach: build visibility from the telemetry you already have.

Start from your existing logs in the SIEM or EDR and gradually reconstruct the environment:

  1. Identify active devices from endpoint data (DeviceName, Hostname, or AgentID).
  2. Map communication patterns from firewall or proxy logs.
  3. Extract user-to-device associations from Active Directory sign-ins.
  4. Analyze outbound connections to spot systems exposed to the internet.

By doing this, you build a real-world inventory based on evidence — not assumptions — which becomes the backbone of your detection strategy.


📡 Are You Collecting the Right Data?

The more diverse your telemetry, the stronger your detection capabilities.

Examples:

Regularly review your schema coverage:
Make sure critical fields like UserPrincipalName, DeviceId, IPAddress, and Timestamp exist and are normalized.

Such consistency allows your correlation logic to connect dots accurately — the difference between catching an incident or missing an attack entirely.


🧩 Key Takeaways

No Collection, No Detection.
Every SOC’s power begins with what it can see.


If you’re building your own SOC or starting your journey into SIEM and detection engineering, check out:
👉 Microsoft Sentinel Home Lab Setup | Step-by-Step Guide
A complete hands-on tutorial to deploy Microsoft Sentinel, connect data sources, and simulate real detections.


#CyberSecurity #SIEM #SOC #ThreatDetection #SecurityOperations
#MicrosoftSentinel #IncidentResponse #DetectionEngineering #CloudSecurity #SOCAnalysis