Cybersecurity
Detection engineering
A good detection is specific, tested and has an owner. We help you build a pipeline that produces rules like that, so alerts become something analysts trust rather than ignore.
The problem this service solves
Out-of-the-box rules generate noise. Teams respond by turning them off, and the SOC ends up with detections nobody understands. The fix is treating detections as software: each one has a purpose, a data requirement, a test, a tuning history and a response procedure.
We build that discipline with your team and then help fill the highest-value gaps in coverage.
What is in scope
-
Coverage assessment
Map existing rules to ATT&CK, identify blind spots and rank them by relevance to your threats.
-
Rule development
Write and test new detections for identity, endpoint, cloud and network behaviors.
-
Tuning
Reduce false positives with evidence from your logs, not guesses.
-
Detection-as-code pipeline
Source control, peer review, automated testing and deployment for rules.
-
Runbooks
For each detection: what it means, how to triage, what to do next.
-
Data engineering
Parsing, normalization and enrichment that make detections possible.
How the work runs
Assess
Know what you have.
-
1
Rule inventory
Catalog rules, owners, firing rates and outcomes.
-
2
Coverage mapping
Identify which techniques are covered and which only look covered.
Build
Write detections that work.
-
3
Threat-driven backlog
Prioritize behaviors by relevance and by the data you have.
-
4
Develop and test
Write rule logic and test it with simulated activity.
-
5
Peer review
Another engineer checks logic, performance and documentation.
Operate
Keep them working.
-
6
Deployment and monitoring
Release through the pipeline and watch firing rates.
-
7
Review cycle
Re-test periodically and retire what no longer works.
What you receive
- Coverage map before and after
- Detection rules with documentation, in your platform’s format
- Test cases for each rule
- Detection-as-code repository and pipeline
- Triage runbooks
- Tuning report
Tooling and technique
Tool categories describe how we work. They are not a claim of vendor partnership or certification.
Standards we map to
Mapping findings to a framework is not the same as certification against it.
Before we start
What we need from you
- Platform access and a sample of log data
- Existing rules and incident history
- Engineering time for peer review and testing
What this service is not
- Operating a SOC or responding to alerts for you
- A rules pack sold without understanding your data
What changes afterwards
- Alerts map to specific behaviors and have runbooks
- False positives fall because rules are tuned with your data
- Analysts trust the queue
Questions people ask
What is detection-as-code?
Managing detections the way software is managed: stored in version control, reviewed by peers, tested automatically and deployed through a pipeline. It makes quality repeatable and changes auditable.
Can you migrate our rules from Splunk to Sentinel?
Yes. Migration is a good moment to retire useless rules. We translate what is valuable, test it against the new data model and drop what is not.
Related
-
SIEM consulting
Architecture, data onboarding, cost control and migration for Microsoft Sentinel, Splunk, Elastic and Google Security Operations.
-
Purple teaming
Collaborative exercises where attackers and defenders work side by side to test and improve detections, technique by technique.
-
Threat hunting
Hypothesis-driven searches through your telemetry for attacker behavior that automated detections missed.
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