Access Log Review¶
Procedure — instantiates Least-Privilege Access Design
Examines records of how permissions were actually used — successful accesses, failed attempts, escalations, and anomalies — to detect misuse, dormant grants, and scope failures after the fact.
Access Log Review is a detective procedure that works from evidence of use. It reads the logs of what actually happened — who opened what, when, from where, what was denied, what was escalated — and looks backward for problems: misuse, dormant grants, anomalous patterns, and toxic combinations actually exercised. The one idea that makes it this mechanism and separates it sharply from its nearest twin, Access Recertification: it audits the record of use, never the record of entitlement. It never asks a human "is this still needed?" It reads what the human did. Access that is correctly scoped on paper can still be abused; the log review is the only control that sees the abuse, because it looks at behavior rather than grants.
Example¶
A hospital's privacy office runs a monthly access-log review over its electronic health record. Clinicians hold broad "break-the-glass" reach so no rule blocks a click in an emergency — which means scope alone cannot catch snooping; only the pattern of use can. The review joins the access logs against the care-assignment roster and flags an anomaly: an oncology nurse opened the record of a patient admitted to a different unit — a locally-admitted public figure — four times over two days, with no care relationship on file. No permission was violated; the behavior was. It is routed to investigation. In the same pass the review finds a contractor account that has not authenticated in 200 days — dormant access nobody remembered to remove. Neither finding was visible in any grant list; both were visible only in the logs. This kind of monitoring is exactly what the HIPAA Security Rule's audit-controls standard requires.[1]
How it works¶
The distinctive machinery is retrospective analysis of behavior. Collect the access and authentication logs; establish what "normal" looks like for each role; then scan for four things — misuse (access with no legitimate relationship), dormant grants (permissions that were never exercised), anomalies (off-hours access, bulk export, unexpected escalation), and exercised toxic combinations (one actor's log showing two actions that must never be performed by the same person). Findings are routed onward to investigation, response, or revocation. Everything about it is after-the-fact and evidence-driven: it detects, but it does not itself grant, expire, or attest. That is the line against its twin — the recertification asks owners about future need; the log review reads the past.
Tuning parameters¶
- Review cadence — continuous alerting vs. periodic batch. Real-time catches active abuse but floods with noise; batch is calmer but slower to react.
- Anomaly sensitivity — how far from baseline trips a flag. Tight thresholds catch more and cry wolf more; loose ones stay quiet and miss the subtle snoop.
- Log scope and retention — which events are captured and how far back. Deeper logs enable investigation but cost storage and privacy exposure of their own.
- Sampling vs. census — spot-check a subset vs. examine every event. Census is thorough but heavy; sampling is affordable but leaves gaps.
- Enrichment — whether logs are joined with relationship data (rosters, tickets, HR) to judge legitimacy. Enrichment separates a legitimate look from a snoop; raw logs cannot.
When it helps, and when it misleads¶
Its strength is that it is the only control that sees what people actually did with their access — it catches the misuse that perfectly-scoped-on-paper permissions still allow, and it surfaces dormant grants for cleanup that no static list would reveal.
Its failure mode is that logs show access, rarely intent: a legitimate emergency look and a snoop can be byte-for-byte identical, so the procedure produces suspicions, not verdicts. Alert fatigue then buries the real signal under false positives. And the classic dead-end the archetype names is audit without revocation — you detect diligently and nothing ever changes, so the finding is theater. A related misuse is logging everything and reading none of it. The discipline that guards against this is to wire every finding to a real response and revocation owner, and to calibrate thresholds against a genuine baseline so that signal survives the noise.
How it implements the components¶
access_audit— the procedure is the audit: it checks whether access was appropriate by reading the record of actual use for dormant, misused, unexplained, or anomalous access.segregation_of_duties_check— because it reads what was done, it catches a single actor who actually exercised a forbidden combination (created a vendor and released its payment), a violation visible only in behavior, not in the grant.
It detects problems but does not itself expire access (revocation_trigger) nor ask an owner to re-attest continued need (task_need_definition re-applied on a cadence) — that forward-looking attestation-and-expiry work belongs to its nearest twin, Access Recertification; and it reads use rather than laying grants out for inspection (resource_map, actor_role_map — that's Permission Matrix).
Related¶
- Instantiates: Least-Privilege Access Design — the log review is the design's feedback loop, revealing where scope failed in practice.
- Consumes: Access Control List — the recorded grants are the entitlement baseline that actual use is judged against.
- Sibling mechanisms: Access Control List · Permission Matrix · Need-to-Know Policy · Access Recertification · Attribute-Based Access Policy · Role-Based Access Control · Approval Workflow
Editorial Notes¶
Form Classification¶
Form family: Assessment, Review & Assurance
Rationale: The mechanism examines records of how permissions were actually used — successful accesses, failed attempts, escalations, and anomalies — to detect misuse, dormant grants, and scope failures after the fact, so its operative form is a bounded assessment of existing evidence or work.
Independent corroboration: The frozen evidence defines Access Log Review as 'Examines records of how permissions were actually used — successful accesses, failed attempts, escalations, and anomalies — to detect misuse, dormant grants, and scope failures after the fact', so its operative form is Assessment, Review & Assurance.
Review outcome: Independent reviewer agreement; high confidence.
Origin Attribution¶
Primary origin: Computer Science & Software Engineering
Origin pattern: Convergent development
Present-day reach: Specialized
Rationale: Authentication and resource-access logs, anomaly detection, privilege-escalation traces, and incident investigation are information-security and computing practices.
Related originating lineages:
- Accounting & Auditing — Detective controls, segregation-of-duties checks, evidence retention, and findings routed to remediation come from audit and internal control.
- Law & Governance — Privacy and sectoral compliance requirements make review, retention, and response mandatory in many settings.
- Security Studies & Intelligence Analysis — Behavioral baselining and investigation of suspicious access patterns contribute a threat-detection and intelligence dimension.
Review resolution: The mechanism operates on authentication and resource-access events and is explicitly standardized as a computer-security audit-record control; audit assurance, compliance law, and threat investigation are genuine convergent lineages.
Attribution caveat: The data source and enforcement context are computational, although the review procedure borrows heavily from audit practice.
Review outcome: Researched adjudication after independent review; high confidence.
Sources consulted:
- NIST SP 800-53 control AU-6: Audit Record Review, Analysis, and Reporting — Requires review of system audit records for inappropriate or unusual activity, reporting findings, correlation, and automated analysis.
Notes¶
A log review is a detective control, not a preventive one — it can only ever tell you what already happened, so its value is entirely downstream of whoever acts on the finding. Detached from a response and revocation path it becomes the archetype's "audit without revocation" failure: perfectly kept logs, faithfully reviewed, changing nothing. The complementary preventive move — deciding on a cadence whether a standing grant should still exist at all — is Access Recertification, and the two work best cross-checked: a grant a manager just re-confirmed but that shows 200 days of no use is a contradiction only the pairing exposes.
References¶
[1] The HIPAA Security Rule "Audit Controls" standard (45 CFR §164.312(b)) requires covered entities to implement mechanisms that record and examine activity in information systems containing electronic protected health information — the regulatory basis for exactly this kind of after-the-fact access-log review. registry ↩