Security Engineering / Fundamentals / Detection engineering
Fundamental 09

Detection
engineering The discipline that connects every other page: getting the right telemetry, normalising it, turning adversary behaviour into rules that fire, and proving the whole thing works. This is also how you hold an MSSP to account rather than trusting a coverage slide.

vendor-neutralread before SecOps SIEM
Tier 0 · Groundpipeline

From event to alert

Module 0.1

The pipeline, and where it breaks

Six stages, five common failures
1 GenerateThe source must actually emit the event. Failure: auditing not enabled (command lines, script blocks, data events).
2 CollectForwarder, API poll or webhook. Failure: silent feed death — nobody notices a source stopped.
3 ParseMap vendor fields into a common schema. Failure: a vendor format change breaks parsing and fields go empty.
4 EnrichAdd identity, asset, geo, intel, prevalence. Failure: no asset context, so every alert needs manual lookup.
5 DetectRules and analytics. Failure: rules written against fields that are never populated.
6 RespondTriage, case, action. Failure: alerts with no documented response, closed as informational.
Log source health monitoring is a detection. Write a rule that alerts when a critical source stops sending for N hours. Attackers disable logging; more often, a certificate expires or an agent breaks. Either way, you want to know in hours rather than at the next audit.
Module 0.2

Why normalisation exists

One schema, many products

Five products describe the same failed login five ways. Without a common schema you write five rules and maintain five rules forever.

Windows   EventID 4625, TargetUserName, IpAddress, LogonType
Okta      eventType=user.session.start, outcome.result=FAILURE
AWS       eventName=ConsoleLogin, errorMessage=Failed authentication
SSH       "Failed password for invalid user root from 1.2.3.4"

  ↓ normalise ↓

metadata.event_type = USER_LOGIN
security_result.action = BLOCK
principal.user.userid / principal.ip / target.hostname

Every SIEM has a schema of this shape — Google SecOps calls it UDM, others use ECS, OCSF or CIM. Learning your platform's schema is the highest-leverage investment you can make in it, because rules, dashboards and searches all speak it.

Tier 1 · Mechanicsrule craft

Writing detections that hold up

Module 1.1

The pyramid of pain and detection types

Choosing what to detect on
TTPs / behaviour ← expensive to change ★ aim here Tools / utilities Network / host artefacts Domain names IP addresses Hashes ← free to change
TypeExampleStrengthWeakness
Atomic / IOCKnown-bad hash or domainZero false positivesObsolete instantly
BehaviouralOffice spawns PowerShell with -encDurable across toolingNeeds FP tuning
StatisticalData volume 10× the user's baselineCatches the unknownBaseline drift, seasonality
CorrelationPhish click → new-ASN login → inbox ruleVery high fidelityDepends on multiple healthy feeds
Threat huntingHypothesis-driven searchFinds what rules missHuman time, not scalable
Module 1.2

Anatomy of a good rule

Everything that ships alongside the logic

The query is maybe a third of the work. A detection is only production-ready with all of this:

  • Name and description in plain English — what an on-call engineer reads at 3am.
  • ATT&CK technique ID — for coverage measurement and reporting.
  • Data sources required — so a broken feed can be traced to the affected rules.
  • Severity and confidence, and whether it pages or queues.
  • Known false positives from your own estate — backup agents, RMM tools, vulnerability scanners, installers, IT scripts.
  • Triage steps — the three pivots to make first.
  • Response actions — isolate, revoke, block, escalate.
  • Validation evidence — how it was tested, and when it was last confirmed to fire.
  • Version control — detections belong in Git with review, like any other code.
Detection-as-code: rules in a repository, peer-reviewed, tested against sample events in CI, deployed via API. This is the difference between a rule set that improves over years and one that rots because nobody dares touch it.
Module 1.3

Tuning without going blind

Narrow the rule, not the coverage

Tuning hierarchy, best to worst:

  1. Fix the environment — if a legitimate tool causes the noise, change the tool's behaviour or path.
  2. Refine the logic — add a condition that excludes the benign pattern specifically (this parent, this signed publisher, this argument).
  3. Scope the exclusion — exclude a specific host or account, with an expiry date and an owner.
  4. Lower severity — keep it visible for correlation without paging.
  5. Disable — only with a documented decision and a review date.
The exclusion that kills you: "exclude all activity from any process signed by Microsoft" or "exclude the whole servers OU". Broad exclusions are exactly where attackers operate, and they are invisible six months later. Every exclusion needs a reason, an owner and an expiry — treat the exclusion list as a risk register.

Metrics worth tracking: alert volume per rule, true/false positive ratio, time to triage, percentage of alerts closed as "informational" (a high number means your severity assignment is broken), and rules that have never fired at all (either brilliant or broken — test them).

Drill 1

A rule for "credential dumping via LSASS access" fires 40 times a day, all from your backup agent. Best action?

Narrow, documented exclusion. Exclude the specific signed binary at its specific path — not the host, not the whole vendor, not the rule. Record who approved it and when it will be reviewed, because an attacker who learns you exclude that path will simply use it. Disabling loses a high-value detection entirely, and demoting to informational quietly does the same thing while looking active.
Tier 2 · Engineercoverage & assurance

Proving the programme works

Module 2.1

ATT&CK coverage without lying to yourself

Depth beats coloured squares

Mapping detections to techniques is useful for gap analysis and for communicating with stakeholders. It becomes theatre when a green square means "we have one rule that mentions this".

Honest coverage requires three things per technique

  1. Telemetry — do we collect the data needed to see it at all? (No process command lines = no coverage of half the matrix, regardless of rules.)
  2. Logic — is there a rule, and does it cover the common procedure variations rather than one tool's default?
  3. Validation — has it been made to fire, deliberately, recently?

Scope the matrix before measuring it: techniques relevant to your platforms and threat model. A UK FinTech on Macs, Workspace and AWS should not be graded on ICS techniques, and pretending otherwise makes the whole exercise unfalsifiable.

MSSP accountability questions: which log sources feed each claimed detection; when was each technique last validated and how; what is the alert volume and true-positive rate per rule; which techniques have zero detections against the current sources; and can we see the rule logic. Vague answers to these are the finding.
Module 2.2

Validation: atomic tests and purple teaming

Making detections fire on purpose
1Pick techniques relevant to your threat model and platforms.
2Execute safely — atomic tests in a controlled scope, with change approval and the EDR in detect-only if needed.
3Observe at three levels: was the telemetry generated, did the rule fire, did an analyst act?
4Fix the weakest link — usually telemetry or triage, not the rule.
5Record the date and result per technique. This is the artefact that turns a coverage claim into evidence.

That record is genuinely useful in three places at once: internal roadmap prioritisation, MSSP performance reviews, and the resilience-testing evidence regulators and clients ask for.

Referencesearchable

Glossary