IN PROGRESS
Detection Engineering
Log sources, detection logic, tuning, false positives, and the telemetry gaps nobody notices until an incident.
34/50
16 MORE UNTIL THIS DOMAIN IS COMPLETE
- 01Alert when a log source goes quiet
- 02Why a 99% accurate detection still drowns you
- 03A detection is not an alert
- 04Why the same field has three names
- 05Tuning is scoping, not deleting
- 06Detections belong in version control
- 07What ATT&CK mapping is actually for
- 08You cannot detect what you never collected
- 09The cost of an alert is the pivot
- 10Severity is a routing decision
- 11An untested detection is a hypothesis
- 12A detection has two clocks
- 13A threshold is a claim about your environment
- 14Detect the behaviour, not the tool name
- 15A rule on 60% of hosts is 60% coverage
- 16Logs an attacker can edit are not evidence
- 17The first alert is rarely the first activity
- 18One incident should not be forty alerts
- 19If two analysts would differ, the rule is unfinished
- 20A parse failure looks like silence
- 21Your rule matches strings, not intent
- 22You can only hunt as far back as you keep
- 23Close reasons are your only feedback
- 24A detection with no owner decays
- 25An exclusion without a review date is permanent
- 26Your logs are shorter than you think
- 27A baseline can learn the attacker
- 28If the source samples, silence proves nothing
- 29Routing depends on data nobody owns
- 30Timestamps disagree across sources
- 31Some fields are filled in by the attacker
- 32The same command is not always malicious
- 33Correlation needs a shared identifier
- 34Suppression can hide the second event