LEARN. PRACTICE. GROW.Start with the person and decision
At month-end in a fictional fund service, a supplier asks to extend an exception. Before discussing a tool, identify the permitted change, covered data, duration, and who may accept the risk. Expired approval does not renew because the task remains incomplete. If policy requires two people, comparing usernames is insufficient: one person can control two accounts. Record the accountable identity for each approval and check prohibited duty combinations. This exercise imposes no universal banking model; it starts from explicit conditions to show how implementation can satisfy a form while missing the control objective.
Check the object on the effective path
A team may view its own reports but not another team’s. Model the decision using subject, action, object, and context. Login does not answer the relationship between the person and the requested report. If the interface hides a link while the download endpoint accepts any identifier, the direct path retains the flaw. Prepare positive and negative tests using objects belonging to different teams and observe server decisions. For a proxy-supplied identity header, also check trusted origin: a client reaching the backend directly must not be able to choose the identity accepted by the service.
Prepare usable emergency access
A recovery credential stored in a vault unavailable without the failed IdP can be well protected yet useless during the intended incident. Analyze dependencies of the emergency path, including networking, equipment, and authorization. The design should be approved in advance, bounded, and observable. In an exercise, establish that it can recover the required function during the stated failure and that use is recorded. Automatic expiry helps prevent access persisting through oversight. The team should not confuse this preparation with open permission to ignore controls during any urgent event. Activation and closure conditions are part of the mechanism itself.
Recovery also establishes trust
A phishing-resistant authenticator does not protect an account if recovery binds it to the wrong person. In a helpdesk request, knowing a name, team, or internal number may establish familiarity but not legitimate identity control. Use the method approved for the context and retain notifications through the established channel. Distinguish verification before binding from later detection of improper recovery; notification does not replace the former. During a maintenance window, an alternate on-call person may perform the task under their own authorization. This avoids turning operational pressure into a reason to share credentials or invent weaker identity proof.
A valid signature is not enough to accept an assertion
A federation assertion carries a claim from the identity provider to the relying application. The application should evaluate recipient, issuer, lifetime, and protocol controls. In the exercise, the same assertion may be accepted only once by the same RP. Rechecking its signature does not detect reuse: signed content can remain intact and within its lifetime. Replay protection should fit the protocol rather than being an improvised rule for every token. Do not confuse authentication assertions with API credentials that may have different semantics. State the object and rule explicitly before building the test.
A small matrix makes policy testable
Use a synthetic matrix: active user, team membership, permitted action, and an exception still within its validity. Change one condition at a time and write the expected result before running a test. Add cases bypassing the portal, losing a role, or using two accounts belonging to the same approver. The purpose is not to prove complete security with a table; it is to expose the specific rule and counterexamples that could violate it. At RUN handover, provide the matrix with owners, attribute sources, and expected change-propagation time. The summary is to test the actual boundary, not only the interface happy path.
Exercise: active=true, team=FUNDS-A, report=FUNDS-A, action=read permits reading. Changing only the report team to FUNDS-B must deny it. Two usernames with the same accountable person do not satisfy a two-person rule.
Common pitfalls
Counting accounts as people; implicitly approving extensions; treating hidden buttons as controls; placing recovery behind the failed dependency; treating signatures as replay protection.
Related topics: IAM and federation · Separation of duties · Authorization testing
A policy is established through correct decisions on permitted and prohibited paths, with explicit identity, object, and duration.
Reference: Security and Privacy Controls · CISSP outline effective April 15, 2024; current AI guidance consulted 2026-09-29