A SIEM full of default rules produces noise that analysts learn to ignore, and a bill that grows with every log source. We decide which logs earn their cost, write detections as code with tests, map coverage to MITRE ATT&CK, and automate the first steps of response.
SOAR playbooksenrich · ticket · containAnalysts and MDRtriage · approval
Microsoft Entra IDOktaCyberArkTerraform
in short·20-second read
Threat detection engineering is the work of turning logs into alerts that catch real attacks and rarely fire falsely.
Cohash onboards log sources and filters them, then writes detections as code in Microsoft Sentinel, Splunk and other SIEMs and tests them. Coverage is mapped to MITRE ATT&CK, and we build SOAR playbooks. Platform moves get planned too, like taking Sentinel from the Azure portal to the Microsoft Defender portal ahead of Microsoft's deadline.
you probably need this if
Analysts close most alerts without reading them because the default rules are noisy.
SIEM ingest costs rise every quarter and nobody knows which logs feed a detection.
Detection rules are edited in the console with no record of who changed what.
From the first call to a setup your own team can run.
Here's what usually prompts a call about your Threat Detection, what we do about it and in which order, and where you end up.
01 · where it hurts02 · what we change03 · how it runs04 · where you end up
incident board · threat detection3 open
openAnalysts close most alerts without reading them because the default rules are noisy.
recurringSIEM ingest costs rise every quarter and nobody knows which logs feed a detection.
blockedDetection rules are edited in the console with no record of who changed what.
exposure
Log source strategyDetection as codeATT&CK coverage mappingAlert tuningSOAR playbooksSentinel move to the Defender…
startrehearsehandover
Assess
Prioritize
Build
Measure
we are here
ready to hand over
Analytics-tier ingest now matches the data rules actually use.
Every rule change now has an author and a reason, plus a test.
Log source value and cost analysis
Detection-as-code repository and pipeline
chapter 01 · where it hurts
Why teams reach out
Analysts close most alerts without reading them because the default rules are noisy.
SIEM ingest costs rise every quarter and nobody knows which logs feed a detection.
Detection rules are edited in the console with no record of who changed what.
chapter 02 · what we change
How we solve it
Log source strategy
Detection as code
ATT&CK coverage mapping
Alert tuning
SOAR playbooks
Sentinel move to the Defender portal
chapter 03 · how it runs
Our approach
Assess
Prioritize
Build
Measure
chapter 04 · where you end up
What changes
Analytics-tier ingest now matches the data rules actually use.
Every rule change now has an author and a reason, plus a test.
Log source value and cost analysis
Detection-as-code repository and pipeline
what we do
Where we spend the hours
6 areas of work, each one done by an engineer who has run it in production.
We look at every log source and ask whether what it catches is worth what it costs to ingest. The loud ones get filtered, summarized or moved to a cheaper storage tier.
Rules stored in Git, reviewed in pull requests, tested against sample events and deployed by pipeline, so every tuning change has an author and a reason.
Your detections, mapped to MITRE ATT&CK techniques and checked against the groups known to go after your industry. Whatever is missing becomes a prioritized backlog.
Noisy rules get measured by true-positive rate and fixed with allow-lists, thresholds or better correlation. They don't get quietly switched off.
Enrichment and ticket creation, plus containment such as isolating a host or disabling an account. Wherever the action is disruptive, a human approves it first.
The cutoff is 31 March 2027. Well before then, we onboard your workspaces to the Defender portal, check analytics rules, automation and workbooks for changed behavior, and train analysts.
capability 01 / 06in production
Log source strategy
We look at every log source and ask whether what it catches is worth what it costs to ingest. The loud ones get filtered, summarized or moved to a cheaper storage tier.
Rules stored in Git, reviewed in pull requests, tested against sample events and deployed by pipeline, so every tuning change has an author and a reason.
Your detections, mapped to MITRE ATT&CK techniques and checked against the groups known to go after your industry. Whatever is missing becomes a prioritized backlog.
Enrichment and ticket creation, plus containment such as isolating a host or disabling an account. Wherever the action is disruptive, a human approves it first.
The cutoff is 31 March 2027. Well before then, we onboard your workspaces to the Defender portal, check analytics rules, automation and workbooks for changed behavior, and train analysts.
We pieced these together from Threat Detection situations that come up a lot. They're patterns. You won't find a specific client in them.
case file 01
Sentinel ingest doubled after firewall and DNS logs were added
composite · not a client story
Beforethe situation
A Sentinel workspace sends firewall allow logs, DNS queries and verbose Windows events to the analytics tier. Ingest cost doubled in a year, and fewer than half the analytics rules read those tables.
What we dothe work
Map every analytics rule and hunting query to the tables it reads. Filter firewall allow logs and noisy Windows event IDs with data collection rules at ingest, and send the rest to a lower-cost tier kept for hunting. Rules that still need the data read summary tables.
Afterwhere you end up
Analytics-tier ingest now matches the data rules actually use. Hunting data stays searchable, and every new log source has to justify its detection value before it gets onboarded.
case file 02
300 analytics rules tuned by hand in the portal, with no history
composite · not a client story
Beforethe situation
Around 300 Sentinel analytics rules, many from Content hub templates, have been tuned by hand in the portal by several analysts. Nobody can say who changed a threshold or why, and the Defender portal move hasn't started.
What we dothe work
Export every rule to a Git repository, add sample-event tests for the rules with the most alerts, and deploy through a pipeline with Sentinel repositories or your own CI. Then onboard the workspace to the Defender portal and compare rule behavior there well before the March 2027 cutoff.
Afterwhere you end up
Every rule change now has an author and a reason, plus a test. That means the Defender portal move starts from a known rule set instead of whatever was in the console that week.
How logs become tested detections and response actions
High-volume sources get filtered before ingest, and the raw copy goes to a cheaper tier for hunting. Rules deploy from Git into the SIEM. Alerts kick off SOAR playbooks, with a human approval step for anything disruptive.
01 · Log sources
Identity logsEntra ID · Okta → SIEM analytics · connector
Ingest filtering → Low-cost storage tier: raw copy
Detection rules in Git → SIEM analytics: deploy rules
SIEM analytics → SOAR playbooks: alert
SOAR playbooks → Analysts and MDR: approval step
how it runs
A typical engagement
We don't start a step until the last one has produced something you can check.
step 01
Assess
Current sources, rules, alert volumes, response times and ingest costs.
step 02
Prioritize
A threat-informed list of detections and log sources, ranked by value.
step 03
Build
Detections and playbooks written, tested and deployed through a pipeline.
step 04
Measure
A monthly review of alert quality, ATT&CK coverage and cost.
you keep
What you're left with
We write these for your Threat Detection setup, and they're working documents. Your team should be able to keep things running from them long after we've gone.
Some clients want a project team, some want a couple of engineers on theirs. Either works. Onsite, nearshore or offshore, with handovers across time zones that keep things moving.
Put these to anyone bidding on your Threat Detection work. The ones who've done it answer differently from the ones who've read about it.
Q1
If you filter some of our log sources or move them to cheaper storage, which ones? What do we give up?
Cutting ingest saves money but can blind an investigation. Ask for a table-by-table map of which rules and hunting queries depend on each source.
Q2
How will you test a detection before it's deployed?
Rules without test events break silently when a schema or parser changes. Each one should ship with sample malicious and benign events that run in the pipeline.
Q3
How do you decide which ATT&CK gaps matter for us?
Full ATT&CK coverage isn't realistic. Priorities should come from the groups targeting your sector, your crown-jewel systems and your identity setup.
Q4
What changes for our automation rules and playbooks in the Defender portal?
After 31 March 2027, Sentinel is gone from the Azure portal. Incident handling, automation and permissions work differently in the Defender portal, so test them before you move.
Q5
Who answers the alerts you build if our MDR provider doesn't cover them?
A custom detection that routes nowhere is wasted. The handoff to the MDR provider or internal on-call has to be agreed per rule.
01When does Sentinel stop working in the Azure portal?
Microsoft says that after 31 March 2027 Sentinel will no longer be supported in the Azure portal and will be available only in the Microsoft Defender portal. That date was pushed back from July 2026. Use the extra time to test rules, automation and permissions in the Defender portal rather than moving everything in the final month.
02How can we cut SIEM costs without losing detection?
Start by finding out which sources feed rules that actually fire usefully. Firewall allow logs and debug-level app logs are the usual suspects, and they can often be filtered at ingest, aggregated, or kept in a cheaper tier for hunting. Filtering tends to save more than dropping a source, and you still have the data when an incident comes.
03Should we build detections in-house or rely on an MDR provider?
Many teams use both. MDR gives you round-the-clock triage. Custom detections are for what's specific to you, like your crown-jewel apps, how your identity is set up and how your business runs. We build them and route them to whoever answers the alert.
04Which SIEM platforms do you write detections for?
Microsoft Sentinel and Splunk, mainly, and the detection-as-code approach works on other SIEMs too. Still picking a platform? We'll compare the candidates on your actual log volumes, retention needs and what your team already knows.
05Do you write detections for identity attacks specifically?
Yes. Token replay, MFA fatigue, risky OAuth consents and Active Directory attack paths are covered by our identity threat detection and response work. Those rules live in the same detection-as-code repository as everything else.
related
Often paired with
Projects on Threat Detection usually end up touching one of these, so they're worth a look.
