SOC and SIEM detection engineering
We improve what your security operations centre can see and act on. That means checking which logs actually arrive, tuning the SIEM so real alerts are not buried, and writing detections that fire on attacker behaviour rather than on noise. We work in the platform you already have, whether your SOC is in-house or run by a managed provider.
What is detection engineering?
Detection engineering is the work of deciding what a security operations centre should be able to see, writing the rules that turn those logs into alerts, and testing that the alerts fire and mean something. It treats detections as code: written, reviewed, tested and retired on purpose.
The gaps are usually in coverage and signal. A SIEM that has run for a year can still be blind to the identity provider, silent on the VPN, and raising hundreds of alerts a day that analysts close without reading.
Where SIEM detection usually breaks
- Missing log sources. The firewall is in, the cloud control plane is not. Endpoint telemetry covers Windows and skips the Macs.
- Broken parsing. Events arrive but fields are not extracted, so a rule that matches on user name never matches anything.
- Vendor defaults left on. Hundreds of stock rules, most irrelevant to your environment, all competing for the same analyst.
- No feedback loop. Alerts are closed as false positives and the rule that raised them is never changed.
None of these is fixed by buying another product.
What the engagement covers
Log source coverage
We map what you collect against what you would need to see an intrusion unfold: identity, endpoint, email, cloud, network and the business systems that hold sensitive data. Gaps are ranked by what they would hide.
SIEM tuning
We work in Splunk, Microsoft Sentinel, Elastic (the ELK stack) and Graylog. Tuning covers parsing, field normalization, retention settings and the suppression logic that decides what an analyst sees.
Detection rules
New and rewritten rules, each with a stated purpose, the data it depends on, a test that proves it fires, and triage notes for the analyst who receives it. Rules are mapped to attacker techniques so coverage can be measured, as described in threat-informed defence with MITRE ATT&CK.
Alert triage quality
We sample closed alerts and read how they were handled. The question is whether a real intrusion, arriving as one of those alerts, would have been escalated.
Packet and log analysis
Where needed, we read raw packet captures and logs to confirm what a detection should have seen and why it did not.
Can you help if our SOC is run by an MSSP?
Yes. Many organizations buy monitoring from a managed provider and never check what it actually detects in their environment. We review the log sources you send, the rules the provider runs against them, and the alerts that reach you, then write the gaps into a request the provider can act on.
If you are still deciding between building a SOC and buying one, vCISO, CISO or MSSP sets out what a managed provider covers and what it leaves to you.
What you receive
| Deliverable | What it is for |
|---|---|
| Coverage map | Which sources you collect, which you do not, and what each gap would hide |
| Tuning changes | Parsing, suppression and retention fixes, applied with your team or written up for them |
| Detection rules | Tested rules with triage notes, in your platform’s own query language |
| Prioritized backlog | What to build next, ordered by what it would catch |
When a detection fires on something real, the next step is incident response and digital forensics. Rehearsing that hand-off before a real alert is part of incident response readiness.
How the work is bounded
The scope is agreed in writing before work starts, and the engagement is quoted in writing with it.
SecHB does not issue certifications, attestations or audit opinions: those come from accredited certification bodies, CPA firms and QSAs. The work here is what an organization does to be ready for them.
Nothing here is legal advice. Where a question turns on the law, the work is done alongside the client’s counsel, not instead of them.
Questions we are asked
Do you sell or recommend a particular SIEM?
No. We do not sell, resell or host a SIEM, and nothing we earn depends on which platform you choose. We work in the one you already run, whether that is Splunk, Microsoft Sentinel, Elastic or Graylog. If you are choosing one, Splunk vs Sentinel vs Elastic vs Graylog compares the four.
Will you monitor our alerts for us?
No. We do not run a 24x7 monitoring service. The work leaves your analysts, or your provider, with better rules, a tuned platform and a documented backlog, and they keep operating it.
Find out what your SOC can actually see
Tell us which SIEM you run, roughly how much data it takes in, and who works the alerts. The reply says what a review would cover. See also all security services.