Detection and monitoring

Incident response assumes someone noticed. Most organizations that respond well to incidents found out from a customer, a vendor, or an extortion note, and the gap between compromise and discovery is where nearly all of the damage accumulates.

Decide what to log by asking what you would need afterward

Work backwards from the questions an investigation asks: who authenticated, from where, and what did they then do. That points at a short list that matters far more than volume.

• Identity events — authentication success and failure, MFA changes, privilege grants, new API keys and tokens, consent grants to applications.
• Endpoint process activity — what ran, what spawned it, what it connected to.
• Administrative actions in the platforms that hold your data, especially permission and sharing changes.
• Network egress where you have it, and DNS, which is cheap and unusually informative.

Retention decides whether you can investigate at all. Intrusions are commonly discovered months after entry, so logs kept for thirty days answer none of the useful questions. Split it: a short hot window you can search fast, and a longer cold archive you can still reach.

Centralize, and make the copy hard to erase

Logs stored only on the system that produced them are logs the attacker controls. Ship them off the host as they are written, to a destination with different credentials from the systems it collects from — otherwise one compromised administrator account ends both the intrusion and the evidence of it.

Write detections for behavior, not for events

A single event is almost never an incident. What distinguishes an attacker is a sequence: authentication from a new location, followed by a mailbox rule creation, followed by a bulk download.

• Start from the techniques that actually apply to you. Coverage is a property of your own estate, not of a vendor's rule count.
• Detect the steps an attacker cannot skip — persistence, privilege escalation, credential access, and exfiltration — rather than the tools they might use, which change.
• High-signal detections available cheaply: inbox rules that forward or delete externally, new federation or identity-provider trust, disabled logging, impossible travel on administrative accounts, and mass file access by a single principal.

Every detection needs a documented response. A detection that fires with no defined next step becomes noise on its second occurrence.

Tune ruthlessly, because alert fatigue is the real failure mode

An alert that is wrong most of the time trains people to close it without reading. The team stops noticing, and the eventual real one closes the same way.

Measure the proportion of alerts that are actually actioned. Anything consistently below roughly half is a tuning problem, and the fix is narrowing or suppressing the rule rather than adding another analyst. A smaller number of trustworthy detections beats broad coverage nobody believes.

Decide who is watching, and when

Coverage hours are an explicit decision with a cost. Business-hours monitoring means an intrusion starting on Friday evening runs unobserved for two days, which is exactly why attacks are timed that way. If you cannot staff around the clock, say so, and choose a small number of detections that page a human at any hour rather than pretending the queue is monitored.

Outsourcing detection is legitimate and does not outsource the decision. The provider escalates; someone inside still has to be reachable and authorized to disconnect something.

Test that it would actually fire

Detection coverage is assumed far more often than it is verified. Run the behavior — a benign version of the technique — and confirm the alert arrives, reaches a person, and carries enough context to act on. Coverage claimed from a configuration page is not coverage.

Never

• Retain logs for a window shorter than the time it typically takes to discover an intrusion.
• Store the only copy of a log on the system it describes.
• Ship a detection with no defined response.
• Claim coverage for a technique nobody has tested end to end.