← Back to Articles

Network Monitoring and SIEM Best Practices: Building a Detection Pipeline That Actually Works

February 4, 2024•Monitoring & Detection•4 min read

I once inherited a SIEM instance with over 14,000 daily alerts. The security team had stopped checking it months ago. The tool wasn't the problem—the architecture was. After rebuilding the detection pipeline from the ground up, we reduced alert volume by 93% while increasing confirmed incident detections. Here's the framework I used, and how you can apply it in your own environment.

Start With Log Source Prioritization, Not Total Ingestion

The most common mistake in SIEM deployments is the "ingest everything" approach. Storage costs explode, correlation rules choke on irrelevant data, and analysts develop alert fatigue within weeks.

Instead, tier your log sources by detection value:

  • Tier 1 (Critical): Firewall logs, EDR/AV alerts, Active Directory authentication events, VPN logs, DNS query logs
  • Tier 2 (High Value): Proxy logs, email gateway logs, cloud platform audit trails (AWS CloudTrail, Azure Activity Log)
  • Tier 3 (Contextual): Application logs, DHCP/IPAM, asset inventory feeds

Start by fully integrating and tuning Tier 1 before expanding. A well-correlated subset of logs will always outperform a poorly tuned firehose.

Structure Your Detection With the MITRE ATT&CK Framework

Every correlation rule should map to a specific ATT&CK technique. This forces intentional detection design and makes coverage gaps visible. For example, to detect credential dumping (T1003), you might create a Splunk query like:

index=windows EventCode=4688 (CommandLine="*sekurlsa*" OR CommandLine="*lsass*" OR CommandLine="*mimikatz*" OR CommandLine="*procdump*lsass*")
| stats count by src_ip, user, CommandLine
| where count > 0

For Elastic Security users monitoring suspicious PowerShell execution (T1059.001):

process.name: "powershell.exe" AND process.command_line: (*EncodedCommand* OR *-enc* OR *bypass* OR *IEX* OR *DownloadString*)

Maintain a living detection coverage matrix. Tools like the DeTTECT framework can visualize your ATT&CK coverage and highlight blind spots.

Network Monitoring: Capture the Right Traffic

Full packet capture is ideal but rarely feasible at scale. Focus network monitoring on strategic chokepoints:

  • North-South traffic at the perimeter (ingress/egress)
  • East-West traffic between VLANs and security zones
  • DNS traffic, which is often the single richest source for detecting C2, data exfiltration, and tunneling

Deploy Zeek (formerly Bro) on a network tap or SPAN port for protocol-level metadata:

# Deploy Zeek on interface eth1 monitoring a SPAN port
sudo zeekctl deploy
# Key logs to forward to SIEM: conn.log, dns.log, http.log, ssl.log, notice.log

Zeek's conn.log alone can power dozens of detection rules—long-duration connections, beaconing patterns, and unusual port usage all become visible without full packet capture overhead.

Tune Relentlessly: The 30-Day Rule

After deploying any new detection rule, run it in log-only mode for 30 days. Analyze the output for false positive patterns, then add suppression logic before promoting it to alerting status.

Document every tuning decision. A simple format works:

rule_id: DCR-047
technique: T1003.001
tuned_on: 2025-01-15
suppression: Excluded service account "svc_backup" from lsass access alerts
reason: Scheduled backup process triggers legitimate lsass handle requests
reviewed_by: jsmith

This creates an auditable tuning log that's invaluable during incident reviews and compliance audits.

Build Runbooks for Every Alert

An alert without a response procedure is just noise with a timestamp. For every promoted detection rule, create a runbook covering:

  1. What triggered it — plain-language explanation
  2. Validation steps — how to confirm if it's a true positive
  3. Containment actions — immediate steps (isolate host, disable account)
  4. Escalation path — who to contact and when

Final Thoughts

Effective network monitoring and SIEM operations aren't about having the most expensive tools or the largest data lake. They're about intentional design: knowing what you're looking for, ingesting the right data, writing precise detections, and continuously tuning. Treat your detection pipeline like production code—version it, test it, review it, and iterate. That discipline is what separates a noisy dashboard from a genuine security capability.

Have questions about network monitoring and siem best practices? I'm always happy to talk shop — reach out or connect with me on LinkedIn.

← Back to Articles