Solution blueprint
SIEM modernization and detection engineering
A SIEM full of logs and empty of useful detections costs money and gives false comfort. The work is choosing what to ingest, writing detections that fire for a reason, and knowing what to do when they fire.
The situation
A company has a SIEM, a rising bill and a security team that does not trust the alerts. Most alerts are closed as noise. Some important sources are not ingested at all, usually because of cost.
Modernization here does not mean replacing the platform. It means deciding what detection you want, ingesting the data that supports it, writing detections that are tested, and giving analysts a documented response for each one.
Constraints that shape the plan
- Ingestion cost is a real constraint and has to be part of the design.
- Some log sources cannot be added without work by other teams.
- The team is small, so detections that need constant tuning will not survive.
- Compliance requirements set minimum retention for some sources.
- Analysts are sceptical, so early wins matter.
The detection pipeline
Sources
- Identity: directory and cloud identity sign-ins and audit
- Endpoint: detection and response telemetry
- Cloud: control plane audit logs
- Network: firewall, DNS, proxy and flow data
- Applications: authentication and administrative actions
Chosen by what you want to detect, not by what is easiest to connect.
Ingestion and shaping
- Collectors and connectors per source
- Filtering at the edge to drop what has no detection or investigation value
- Normalization to a consistent schema
- Enrichment with asset, identity and criticality context
Filtering and tiered storage are where cost is controlled without losing investigation ability.
Detection
- Use cases mapped to MITRE ATT&CK techniques
- Rules in the platform query language, in version control
- Severity and deduplication logic
- Testing against historical data before enabling
A detection that has never been tested against real data is a guess.
Response
- A playbook per detection: what it means, how to confirm, what to do
- Enrichment automation before a human looks at it
- Containment with approval where it affects users
- Feedback loop so closed alerts improve the rule
The playbook is what turns an alert into a decision.
The approach, phase by phase
Phase 1: Assess
Two to three weeks.
-
1
Inventory log sources
What is ingested, what it costs, and what is missing.
-
2
Review detections
What exists, what fires, what analysts do with it, and what has never fired.
-
3
Threat-informed priorities
Which techniques matter for your business, sector and architecture.
-
4
Baseline the cost
By source and by volume, so design decisions have numbers attached.
Phase 2: Design
Three to four weeks.
-
5
Detection roadmap
Use cases in priority order, each mapped to the data it needs.
-
6
Ingestion plan
Sources to add, data to filter, retention and storage tiers per source.
-
7
Normalization and enrichment
Schema, asset and identity context, and how it is maintained.
-
8
Alert handling model
Severity, routing, deduplication and what an analyst is expected to do.
-
9
Cost model
Projected cost of the new design, agreed before building.
Phase 3: Build
Six to ten weeks.
-
10
Onboard sources
In priority order, with parsing verified against real events.
-
11
Write and test detections
Against historical data, measuring true and false positives before enabling.
-
12
Tune
Suppress known-good patterns with documented reasons rather than broad exclusions.
-
13
Write playbooks
One per detection, written so a new analyst can follow it.
-
14
Automate enrichment
Identity, asset and reputation context attached before a human sees the alert.
Phase 4: Transition and improve
Four weeks and ongoing.
-
15
Hand over to operations
With the playbooks, the rule repository and an owner for each.
-
16
Measure coverage
Against the ATT&CK techniques you chose, with honest gaps shown.
-
17
Review the noisy rules
Monthly, with changes made in version control and tested.
-
18
Validate with purple teaming
Run the techniques and confirm the detections fire. See purple teaming.
-
19
Keep the cost under review
Monthly, with an owner, because volume grows on its own.
Phase names and order change with the engagement. This is a typical shape, not a fixed method you would be held to.
The kind of team this needs
Roles can be ours, yours or shared. Where you only need people rather than a project owner, the same roles are available through staffing.
Typical deliverables
- Log source inventory with cost and coverage
- Detection roadmap mapped to ATT&CK techniques
- Ingestion, filtering and retention design with a cost model
- Normalization and enrichment design
- Detection rules in version control, with test results
- A playbook per detection
- Coverage report with honest gaps
- Operations handover and review cadence
What usually goes wrong, and what we do about it
-
Ingesting everything
Sources are chosen by the detections and investigations they support, with a cost model agreed before building.
-
Detections that nobody tunes
Rules live in version control with an owner, and noisy ones are reviewed monthly rather than muted.
-
Alerts with no playbook
A detection is not finished until the playbook exists.
-
Broad suppressions hiding real activity
Suppressions are specific, documented and reviewed.
-
Coverage claimed rather than tested
Purple team exercises confirm that the detections fire for the techniques they target.
-
Cost growing back
A monthly cost review with a named owner, because log volume grows without anyone deciding.
Questions people ask
Do we need to change platform?
Often not. Most of the value is in source selection, detection quality and playbooks, which are platform-independent. If the platform is genuinely the constraint, we will say so with the numbers.
Which platforms do you work in?
Our consultants have worked with Microsoft Sentinel, Splunk, Elastic Security and Google SecOps. We will tell you at intake which we have hands-on experience with for the work you need.
Can you monitor it for us?
Only under a written agreement that sets out hours and responsibilities. We do not advertise around-the-clock monitoring we have not contracted for.
How do you measure success?
Detection coverage for the techniques you chose, tested by exercise, plus analyst time per alert and the share of alerts that lead to an action. Not alert volume.
Related
-
SIEM consulting
Architecture, data onboarding, cost control and migration for Microsoft Sentinel, Splunk, Elastic and Google Security Operations.
-
Detection engineering
Design, write, test and maintain detections tied to specific attacker behaviors, with false-positive control and documented response steps.
-
Threat hunting
Hypothesis-driven searches through your telemetry for attacker behavior that automated detections missed.
-
Purple teaming
Collaborative exercises where attackers and defenders work side by side to test and improve detections, technique by technique.
Need to understand your security exposure?
Speak with a security expert
Talk through your environment and goals. We reply to scope the work before anything is tested.
Speak with a security expertPlan an assessment
Answer a few questions and get a structured preliminary scope you can send us.
Use the plannerUnder attack right now?
Call the US office and tell us what you are seeing. Do not wait for a form reply.
Incident response