TL;DR: Start from a specific technique and the attacker behaviour that cannot easily change, not from a tool's signature. Confirm the data source records that behaviour reliably on the systems you care about. Write logic that targets the behaviour, run it against historical data to measure how often it fires and on what, and add context (asset, user, parent process) and narrow exceptions until precision is acceptable for its severity. Test that it fires by reproducing the technique safely in a lab or with an adversary emulation tool. Ship it with a runbook (what it means, how to triage, what to do), an owner and a review date, and track its true-positive rate in production.
How to approach it
Pick a concrete example and walk the lifecycle: hypothesis, data, logic, tuning, testing, deployment, maintenance. The example below uses a new local administrator created on a server, but any technique works if you go through the same steps.
A strong answer
Technique
and invariant behaviour
Data source
records it reliably?
Logic
behaviour, not tool
Backtest
on history
Ship + tune
runbook, owner
1. Hypothesis and behaviour. "Attackers who gain admin access to a Windows server often create a local account and add it to Administrators for persistence (MITRE ATT&CK: Create Account, Local Account)." The behaviour, an account added to a privileged local group, is necessary for the technique, so it survives changes in tooling.
2. Data source. Windows Security event logs record user creation and group membership changes (event IDs 4720 and 4732), forwarded to the SIEM. Verify coverage: are all servers forwarding these events, with correct time, and is the audit policy enabled? A detection on missing data is silently blind; add a health check that alerts when a host stops sending.
3. Logic. Membership added to the local Administrators group on a server, where the actor is not the configuration management service account, outside approved change windows. Join with the user-creation event within a short window for higher confidence.
4. Measure against history. Run over the last 30 to 90 days. Expect hits from legitimate admin work, provisioning scripts and a backup agent installer. Classify each.
5. Tune with context, not blanket exceptions. Exclude the specific provisioning service account when it acts from the configuration management servers; do not exclude "all admins". Raise severity for domain controllers and servers holding sensitive data; enrich with the actor's normal behaviour (have they done this before?). Each exception has a reason and an owner.
6. Test that it fires. In a lab domain, or with an adversary emulation framework, create a local admin through several methods (GUI, net command, PowerShell, remote management) and confirm the detection fires for each. Add the test to a suite that reruns when the detection or the logging pipeline changes.
7. Ship with a runbook. What the alert means, the first three checks (who did it, from where, was a change ticket open), escalation criteria, and containment options (disable the account, isolate the host).
8. Operate. Track volume, true-positive rate and time to triage per detection. Review quarterly: retire noisy rules that never find anything real, and revisit exceptions.
Choosing what to detect. Prioritise techniques that threat intelligence says are used against your sector, that sit at choke points attackers must pass (credential access, privilege escalation, persistence, exfiltration), and where your telemetry is strong. Coverage maps against ATT&CK help find gaps, but a single rule per technique is not coverage.
Precision versus recall. A high-severity page needs high precision; a low-severity signal can feed correlation or hunting instead of paging anyone. Combining weak signals per entity (risk-based alerting) reduces noise while keeping recall.
What interviewers probe next
- "Your rule fires 300 times a day. What do you do?" Measure what fires: if most are one benign pattern, add a narrow exception with an owner; otherwise lower its severity into a correlation input rather than paging on it.
- "How do you detect when an attacker disables logging?" Alert on audit policy changes, cleared logs, and hosts that stop sending; the absence of data is a signal.
- "How would you write this as code?" In a detection-as-code repository with the rule, its tests, metadata (technique, severity, owner) and CI that runs tests before deploy.
What if?
What if · interview follow-ups
Hold your answer as the constraints change
You want to detect credential dumping from the LSASS process on Windows endpoints across a mixed estate of laptops and servers.
Start here
Where do you start?
What must every credential dumper do?
From the technique and the attacker behaviour that cannot easily change: some process opening LSASS with memory read access, or creating a dump of it. Tools and file names change constantly; the need to read LSASS memory does not. Detect the behaviour, not one tool's signature.
Carry it forwardTarget behaviour attackers cannot avoid.
Weak answerWriting a rule for one tool's file name.
Constraint changes
How do you confirm the data exists?
Do all hosts record the access events?
Check that the endpoint telemetry records process access to LSASS (with access rights and the calling process) on the systems you care about, including servers. If some hosts lack the sensor or the event, the detection has a blind spot that must be fixed or recorded.
Carry it forwardVerify data sources before writing logic.
Weak answerAssuming the SIEM has the field everywhere.
Constraint changes
How do you make it precise enough?
Which legitimate tools access LSASS?
Run the logic against historical data to see how often it fires and on what. Legitimate security and backup tools also touch LSASS, so add context (signed known tools, parent process, asset role) and narrow exceptions until precision suits the severity. Avoid broad exclusions an attacker could abuse.
Carry it forwardTune with history and narrow exceptions.
Weak answerExcluding whole directories to cut noise.
Constraint changes
How do you know it actually fires?
Have you seen it trigger on a real test?
Reproduce the technique safely in a lab or with an adversary emulation tool on a test host, and confirm the alert appears with the right context. Repeat after sensor or rule changes, since detections silently break.
Carry it forwardTest detections by emulating the technique.
Weak answerShipping a rule that has never fired.
Constraint changes
What ships with the rule?
What does the analyst need at 3am?
A runbook (what it means, how to triage, what to do), an owner, severity, the ATT&CK technique and a review date. In production, track its true positive rate and triage time. Pair detection with prevention such as credential protection features on Windows.
Carry it forwardShip detections with runbook, owner and metrics.
Weak answerDeploying a rule with no triage guidance.
Now defend it
How would you deliver the detection?
Target LSASS memory access behaviour, confirm telemetry coverage across laptops and servers, tune against history with context and narrow exceptions, test with safe emulation in a lab, ship with a runbook, owner, severity, technique mapping and review date, measure precision in production, and pair it with preventive credential protection.
How it's scored
Weak: Writes a query matching a malware hash or a tool name.
Hire: Targets behaviour, checks the data source, tests against history, tunes false positives and adds a runbook.
Strong Hire: Walks the full lifecycle with telemetry health checks, context-based tuning with owned exceptions, emulation tests in a suite, severity-appropriate precision, risk-based correlation for weak signals, production metrics and periodic retirement, and prioritises techniques by threat intelligence and choke points.
Common mistakes
- Signature rules that break when the attacker renames a tool.
- Detecting on data that some hosts never send.
- Excluding broad groups to silence noise.
- Shipping rules with no test that proves they fire.