Security Audit Log Review Workflow
Review privileged actions in audit logs on a schedule, with queries per concern class, anomaly flags, and escalation paths that close the loop.
Objective
Turn audit logs from a write-only compliance archive into a reviewed signal source that detects misuse and errors in privileged actions.
Environment
- Audit logging enabled for privileged systems (IAM, prod access, secrets)
- A log store with query capability
- A scheduled review slot and escalation contacts
Steps
1. Define the concern classes
Enumerate what the review looks for: permission grants, elevation outside hours, secret access spikes, break-glass usage, and bulk exports.
Expected state: A checklist of concern classes with a query per class exists.
2. Run scheduled reviews with queries
Execute the class queries over the review window, producing a bounded result set per class rather than raw log reading.
Expected state: Each review pass outputs per-class results small enough to actually read.
3. Annotate and disposition each hit
For every flagged action, record the disposition: expected (matches change ticket), benign (routine automation), or unknown (needs escalation).
Expected state: Every hit closes with a disposition, and unknowns route to the owner within the day.
4. Escalate unknowns with context
Route unknown actions to the account owner and their manager with the exact log lines, requiring an explanation that joins back to authorized work.
Expected state: Escalations produce documented explanations or access freezes, never silence.
5. Tune from the misses
When post-incident analysis shows an action the review should have flagged, add or adjust the query for that class, keeping the checklist living.
Expected state: The concern-class list grows from real incidents instead of staying static.
Expected outcome
Audit logs actively reviewed by class with every flag dispositioned, unknowns escalated and answered, and the query set improving after each incident.
Verification
A deliberately injected odd-hour permission grant is flagged in the next review cycle; recent incidents show their precursor actions captured by a class query.
Logs nobody reads are an archive, not a control
Audit logging satisfies compliance the day it is enabled, and satisfies security only when someone reviews it. Class-based queries make the review bounded and repeatable; dispositions and escalations make it a control with a closed loop.
-- class: permission grants (review window: 7d)
SELECT event_time, actor, action, target, ticket_ref
FROM audit_iam
WHERE action IN ('CreateRole', 'AttachPolicy', 'AssumeRole')
AND event_time > now() - interval '7 days'
ORDER BY event_time DESC;
-- hits:
-- 10-21 02:14 svc-deployer AttachPolicy S3Full ticket: NONE -> UNKNOWN
-- 10-21 14:02 wei@team CreateRole db-ro ticket: #4821 -> expected
-- 10-20 09:30 automation AssumeRole backup ticket: n/a -> benign
-- UNKNOWN -> escalated to owner + manager (same day)Bounded results force real review
A review that dumps thousands of raw log lines guarantees skim-then-sign. Queries per concern class keep each result set small enough to genuinely read, which is the difference between a control and a ritual.
Dispositions create the feedback data
Classifying every hit as expected, benign, or unknown generates the statistics that tune the process: a class producing 95 percent unknowns needs better change-ticket joins; a class with zero hits for months may be querying the wrong event names. The review improves itself from its own output.