Detection Engineering Methodologies

The talk comes from the lead of a detection program at Atlassian, which started after a red team exercise led leadership to ask for rules that would stop a similar intrusion from happening again. The speaker describes the team's early, loosely organized approach, where detections were tracked in a cluttered table that discouraged analysts from contributing. The group cut its process back to the fields responders actually need, then drew on Palantir's alerting and detection strategy framework to build its own standard.

The middle of the talk walks through that methodology. Each detection records its logic, scope, a MITRE ATT&CK tactic, a short human-readable name, its data source, its strategy, known blind spots and accepted false positives, plus a response runbook. Peer review asks whether an analyst who did not write the rule has enough context to act on its alerts. Automation carries much of the weight: every Splunk search is syntax-checked in a CI/CD pipeline and run daily to catch fields that have changed. Work is planned in four-week cycles focused on one tactic, with mid-cycle check-ins where engineers review each other's detections. Breach readiness documents gather architecture, log sources and contacts for products the team does not know well.

The closing advice is to start small, keep names descriptive, document blind spots rather than hiding them, and adapt any framework to your own environment instead of adopting it unchanged. The Q&A covers build versus buy decisions and the difficulty of enforcing logging standards across development teams.