detection engineering

Detection quality is decided before the first alert, by what you logged and how you set the threshold. The scored answer derives both from the questions an investigator will ask.

Four open-source tools, four different questions: what happened, what is the state now, is this behaviour forbidden, and can the kernel stop it. Choosing well starts with knowing which question each answers.

Anyone can write a query that matches an attack. The interview is about everything else: the data source you trust, the benign activity that looks the same, how you proved it fires, and what the analyst does when it does.

Detections are production code that pages people. Treating them that way means version control, tests that prove they fire, review, staged rollout and metrics that decide which ones live.

A green heatmap is the easiest thing in security to fake. Interviewers want ATT&CK used to plan and test, with coverage that means 'proven to fire on the variants we expect', not 'a rule exists'.

Analysts closing ten thousand alerts a week will miss the one that matters. The fix is not more analysts; it is fewer, better alerts and automation for the rest, measured by outcomes rather than throughput.

A credential that nobody legitimate ever uses produces an alert with almost no false positives. The craft is in placing it where an intruder looks and making sure it grants nothing.

Importing hashes and IP addresses from a report feels productive and changes almost nothing. The answer climbs from indicators to behaviours and ends with a test that proves the change.

Headlines promised self-writing AI malware. The reports show something narrower and more useful to defenders: malware with a dependency on someone else's API. The scored answer separates hype from evidence and turns that dependency into detections.