Pros
- • Custom detection use-case design tailored to organizational threats
- • Direct mapping of active alerts to the MITRE ATT&CK framework
- • Strategic log-source prioritization to manage ingest costs
- • Aggressive false-positive reduction to combat analyst fatigue
- • Role-based dashboarding for SOC analysts, managers, and executives
- • Enriched incident triage context to accelerate response times
- • Continuous purple-team validation of detection logic
Cons
- • Heavily dependent on reliable, normalized log ingestion
- • Requires up-to-date asset context and network topology maps
- • Necessitates continuous stakeholder feedback to refine alert thresholds
- • A SIEM is never 'done'; requires ongoing lifecycle management
A SIEM is only as good as the rules you put in it. Dump terabytes of logs into Splunk or Elastic and do nothing else? Congratulations—you’ve built an expensive, useless data swamp. Your analysts get 1,000 alerts a day, most of them garbage. They get burned out. Real attackers slip through.
This is about turning logs into actual answers. We design detection rules that work. Rules that trigger on real threats, not noise. Rules that give your SOC something to actually act on.
Splunk vs. Elastic—Different Tools, Same Goal
The rules are different depending on your platform, but the goal is the same.
- Splunk: You’re writing in SPL (Search Processing Language). You’ve got data models for speed. You can build complex, multi-step correlation searches. It’s powerful, but you have to be smart about query performance.
- Elastic/ELK: You’re writing in KQL. It’s faster for raw search. Open-source flexibility. Their native detection engine and ML can do heavy lifting.
We know both. We’ll optimize your rules for whatever you’re running.
How We Build A Detection
It’s a process. You can’t just write one and be done.
- Start With a Hypothesis: What specific attack are we looking for? Based on your threat landscape and recent pen tests.
- Find Your Data: Do you even have the logs we need? Windows Event Logs? Sysmon? EDR? Are they actually being logged?
- Write the Query: SPL or KQL. Get it fast enough that it doesn’t blow up your SIEM.
- Tune the Thresholds: Too sensitive = false positives. Too loose = you miss the real thing. Test against historical data.
- Add Context: Make the alert useful. Tell your analysts which assets matter, who the user is, what the threat intel says.
- Test It: Purple team exercise. Does it actually trigger on the attack you’re trying to catch?
- Deploy & Monitor: Put it live. Watch how it performs. Tweak as needed.
Threat Hunting—Finding What The Rules Miss
Once you’ve got working alerts, your team can hunt for the sophisticated stuff that hides from automated rules.
Example hunt: Looking for unusual outbound connections
- The Question: Suspicious traffic on weird ports?
- Data You Need: VPC Flow Logs, firewall logs, DNS queries
- The Filter: Remove legitimate traffic (office IPs, 80/443). What’s left?
- What To Examine: Destination IPs, how much data moved, user-agents
- What To Do: Found something? Block the domain. Alert your threat intel team.
Give your analysts good search templates and they’ll find threats your rules would miss.
Dashboards That Actually Matter
Everyone needs different information:
- For Your Analysts: A triage queue. Here’s what needs action. Give them context: is the user suspicious? Which assets are critical? It all goes on one screen.
- For Your SOC Manager: How fast are we detecting threats? How fast are we triaging? Are analysts drowning in work? Trend lines over time.
- For Your Executives: Which MITRE ATT&CK techniques are we covering? What does this cost us? Are we getting safer?
Sample Detection Matrix
| Rule Name | MITRE Tactic | Log Source | Alert Logic (High-Level) | False Positive Risk |
|---|---|---|---|---|
| Suspicious PowerShell Download | Execution (TA0002) | Sysmon (EID 1) / EDR | Detects powershell.exe execution combined with known download flags (Net.WebClient, Invoke-WebRequest). | Medium (Requires tuning against admin scripts) |
| Mass File Deletion / Modification | Impact (TA0040) | Windows Event (4663) | High volume of file modification events by a single user within a 5-minute window. | Low |
| Geographically Improbable Login | Initial Access (TA0001) | Azure AD / Okta | Successful authentication from two distinct countries within an impossible travel timeframe. | Low |
| AWS CloudTrail Configuration Modification | Defense Evasion (TA0005) | AWS CloudTrail | Detects API calls targeting logging infrastructure (StopLogging, DeleteTrail). | Low (High severity, low volume) |
Get It Done in 90 Days
- Weeks 1-4 (Audit): Check your logs. Are they even parsing right? Look at your existing rules. Map them to MITRE ATT&CK. Find gaps. Kill the top 10 noisy alerts.
- Weeks 5-8 (Build): Write 10-15 good detection rules. Add context so alerts are actually useful. Build the analyst dashboard they’ll actually use.
- Weeks 9-12 (Test & Hunt): Run a purple team exercise. Does your detection catch the attack? Set up threat hunting. Build an executive dashboard showing coverage.
Good SIEM engineering bridges offense and defense. You turn logs into answers. Your SOC catches threats instead of drowning in noise.
