LEARN. PRACTICE. GROW.Declared configuration and effective access
A policy can look restrictive while another path grants access. In a fictional service, the team removes a person from the main group, but the account remains in a nested group granting the same privilege. A screenshot of the first group does not demonstrate effective revocation. Identify subject, resource, action, conditions and test time. Assess direct, inherited and local paths relevant to the objective. Do not assume every technology combines permissions identically; obtain the product rule and test authorized behavior. An audit lesson does not replace each authorization engine’s specific semantics.
Revoke issuance and revoke use
Disabling an account can prevent new authentication without immediately invalidating every existing session or token. Audit should distinguish these properties and compare them with requirements. Request an inventory of relevant mechanisms, validity periods, supported revocation and observed behavior. A positive test after disabling shows that the tested path still worked at that time; it does not prove earlier misuse. A negative test with a malformed credential may fail because of format rather than the intended control. Include an authorized positive path to establish that the test reaches the intended service.
Protect the evidence as well
If production administrators can alter every record used to detect their own activity, that dependency needs assessment. Do not automatically conclude that logs were manipulated; evaluate access, retention, copies and alteration detection. A hash calculated after collection helps check stability from that point but does not reconstruct earlier provenance. Corroborate with suitable sources and preserve originals under authorization. The auditor should avoid creating new exposure by copying sensitive information into personal tools or unapproved channels merely to accelerate analysis.
Keys, recovery and boundaries
Encryption at rest protects a specific boundary. An export produced by an authorized application may contain readable data without an algorithm failure. Evaluate access control and export destination against the requirement. For retained encrypted backups, also confirm authorized availability of keys and the dependencies needed to use them. R2 from the previous exercise illustrates that an existing file with an unavailable key does not demonstrate a usable restoration option. Do not recommend keeping secrets unprotected to simplify recovery; design should meet authorized availability and restricted access together.
Test-design exercise and conclusion
Design a revocation test for a synthetic account: establish allowed access, perform authorized revocation, test new authentication and existing sessions separately, and record resource, action, time and result. Retain impact limits and stop criteria. If a session remains valid within a documented lifetime, compare that behavior with the requirement rather than declaring universal failure. If immediate revocation is required, the same observation may reveal a relevant gap. Summarize evidence without claiming exploitation, independence of all paths or protection of untested resources.
The account cannot obtain a new session, but an earlier token still reads the resource. The conclusion distinguishes issuance, use and the revocation requirement.
Common pitfalls
Group removal as revoked access; format failure as authorization denial; hash as complete provenance; encryption as protection of every use.
Related topics: Identity and sessions · Log and key protection
Protection should be assessed on the relevant path and at the relevant time. An isolated configuration does not demonstrate every access or recovery behavior.
Reference: Assessing Security and Privacy Controls in Information Systems and Organizations · CISA outline effective August 1, 2024