DE.AE-02 says potentially adverse events are analyzed to better understand associated activities. An alert alone tells you something looked odd. Analysis tells you what happened, to which systems, by whom, and whether it matters. This outcome asks that someone, or some tool, does that work routinely.
CSF is voluntary guidance. There is no CSF certification.
What good looks like
Logs are watched continuously for known malicious and suspicious activity, using a SIEM or comparable tools. Threat intelligence improves detection accuracy and helps characterize attackers and indicators of compromise. For systems that cannot be monitored automatically, a person reviews logs on a schedule.
How to implement it
- Start from the logs you already collect under PR.PS-04: identity, cloud audit, endpoint, email, and application logs.
- Pick a small set of detections that matter most: impossible travel logins, new admin accounts, disabled logging, mass downloads, and malware alerts.
- Write a short triage routine for each: what to check, which tool, and when to escalate.
- Add an owner and a rota. Even a two person weekday rota is better than none.
- For systems without automated monitoring, schedule a manual review and record who did it.
- Record the outcome of each analyzed event, including false positives.
A worked example
An endpoint tool flags a script launched by a spreadsheet on a sales laptop. An analyst on a part time security rota opens the runbook. Step one: check the process tree and file hash in the endpoint console. Step two: search the identity and email logs for that user in the last hour. Step three: look up the hash and domain in the threat intelligence the team subscribes to. The hash is known commodity malware. The analyst isolates the laptop, notes the finding, and escalates under the incident criteria.
The whole analysis took twenty minutes because the steps were written down.
Building a minimum detection set
Choose detections that map to the most likely ways a small company is breached: stolen credentials, malicious email attachments, exposed cloud storage, and changed security settings. For each, define the signal, where it comes from, and what the analyst does next. Five good detections with runbooks beat fifty without.
Manual review for the leftovers
Some systems cannot feed a central platform. NIST's examples include regular manual review for technologies that cannot be sufficiently monitored by automatic means. Put these on a calendar, assign a reviewer, and keep a one line record of each review, even when nothing was found.
Measuring analysis quality
Track how many alerts were analyzed, how long the average took, and what share were false positives. If analysis time grows, improve the runbooks. If false positives dominate, tune the detections. These simple numbers show improvement over time.
Evidence to collect
- Detection rule list.
- Triage runbooks.
- Samples of analyzed events with notes and outcomes.
- Manual review sign offs.
Common gaps
Alerts that pile up unread. No written triage steps, so quality depends on who is on call. Analysis that stops at the alert text. No record of false positives, so noise never decreases.
Quick check
Do we need a SIEM?
Not strictly. NIST names SIEM or other tools. What matters is that events are analyzed and the work is repeatable.
Sources
- NIST Cybersecurity Framework 2.0 (NIST CSWP 29), DE.AE-02 and its implementation examples.
