BigSavantLEARN. PRACTICE. GROW.
← CISA: audit IT, controls, and resilience
22 / 27 · 110 MIN

Auditing cloud identities and permissions

Reconstruct who can perform an operation, directly or through a service, and choose tests that distinguish authorization, trust and log coverage.

Turn a claim into observable criteria

The claim “the provider has read-only access” leaves important questions open. Read access to what, for which customer, during which period and through which paths? In a fictional bank cost service, separate four criteria: the authenticated customer reaches only their account; cost retrieval remains available; the provider cannot write data through direct or delegated paths; internal maintenance retains approved repair capability. Record identities, operations, resources, conditions and versions before selecting tests. A screenshot of a read policy covers only part of this model. Audit evaluates evidence against agreed criteria. The accountable team approves and implements changes; knowing the solution does not grant audit operational authority.

A grant and a limit serve different purposes

Consider a user with GetObject in the identity policy and both GetObject and PutObject in the permissions boundary. With no other applicable grants, reading is within the limit and granted; writing is within the limit but has not been granted. The boundary does not supply that capability. Now add a GetObject deny when aws:SecureTransport=false: the same object and user can produce an allowed HTTPS read and a denied HTTP read. Retain request context in the workpaper because the condition explains the difference. This matrix has a defined scope: resource policies, principal type, sessions and organizational controls can change the analysis. Before using an intersection rule as a universal formula, identify the mechanisms actually participating in the request.

Follow the principal across accounts

In direct access, a role in account A attempts to write to a bucket in account B. B already permits the operation on the approved prefix, but A grants only reading. Broadening the prefix in B increases exposure without supplying the missing grant in A. A useful test compares the approved write before and after the specific identity change while holding other conditions constant. Distinguish this path from assuming a role in B: that second case requires assessment of trust for assumption and then the assumed identity’s permissions. The auditor’s diagram should show when the principal changes. A line connecting only “account A” and “account B” hides that distinction and may direct remediation to the wrong policy.

Audit who controls attributes

In a fictional document repository, a rule permits reading when the user’s department matches the document’s department. Repeatedly testing that comparison does not assess who can change its inputs. If a user can assign themselves another department, they can correctly satisfy a predicate whose input is not trustworthy. Use synthetic documents for two departments and an identity authorized for the test: confirm expected reading, try changing the identity’s own attribute through the exposed path, and repeat the second document read. Record authorization to change the attribute separately from the read decision. For AWS implementations, check tag and condition-key support for the particular service and operation; a rule demonstrated in one service does not establish uniform support across all services.

ExternalId depends on customer binding

The bank-7 identifier is a fictional exercise label, not a password. The bank’s policy may require that value while a weakness remains if the provider portal copies any customer-supplied ARN and ExternalId. The cloud comparison does not know the portal’s authenticated session. The provider needs to obtain the identifier from the association it administers for that customer. The negative test should attempt a combination belonging to another customer through the same broker, with authorization and synthetic data. A test omitting ExternalId entirely assesses the cloud condition but does not independently test the portal’s customer binding. Retain both results and explain which boundary each observed.

OIDC: issued identity, trust and operation

In GitHub Actions, id-token: write permits requesting an OIDC token; it does not itself grant AWS writes. If issuance works but role assumption fails, compare the issued aud and sub with expected trust before changing object permissions. The consulted documentation distinguishes legacy subjects from subjects containing immutable IDs, including repositories created after July 15, 2026 and those opting into the format; this change does not apply to GitHub Enterprise Server. Confirm the particular repository’s configuration. In the legacy subject repo:lab/payments:environment:prod, the environment is identified but main does not appear. To demonstrate deployments restricted to main, assess environment branch protection and test one permitted and one denied origin. Accepting the entire organization to resolve a format mismatch unnecessarily broadens trust.

Delegated permissions can reach further resources

The exercise operator cannot read documents directly but can create a function, choose its code, execute it and pass VaultReader within the same account. The service can assume that role and read the documents. A conclusion that reading is impossible would ignore the combination of those capabilities. The test should follow who controls code, who authorizes creation, which role is passed and what the service can do. For historical investigation, inspect creation or modification of the resource receiving the role: PassRole is a permission, not an API call with its own standalone event. Restricting session duration reduces a window but does not remove the described capability while the session is valid.

Distinguish service origin from log coverage

A logging bucket authorized for account A may remain too broad if the requirement permits only trail T in that account. Service identity and source account do not necessarily distinguish T from another trail; assess the supported source-resource condition. Separately, the absence of GetObject in a trail does not prove that no reads occurred. In the exercise, the selector covers only writes under /inbound/, while audit asks about reads under /archive/. Fixing only the prefix leaves the operation outside the selector. The acceptance test uses a synthetic object at the correct prefix, performs an authorized read and confirms the received event. Document observed delay and retention without inventing a universal delivery guarantee.

Explain divergence between simulation and environment

An Allow simulation and an AccessDenied test may evaluate different policy sets. In the example, simulation omitted the SCP present at the destination. Record identity, action, resource, conditions, included policies, time and versions for both tests. Then identify the difference that predicts their results. Repeating the same simulation does not add the missing rule; removing the SCP to obtain success may undermine the purpose it protects. Agree a new authorized test with the accountable team while preserving required controls. The simulator helps separate hypotheses. An observed environment result also has a scope: one permitted operation on a test resource does not automatically establish every combination in the production account.

Guided case: separate cost access from maintenance

Return to the cost service, with Meter, Repair and the job service in the same AWS account. Meter reads costs but also creates jobs containing provider-chosen code and passes Repair, which writes data. Remediation needs to address two causes: the broker accepts customer context chosen in the request, and Meter controls a write path through Repair. In the proposed design, the broker binds context to the authenticated customer and Meter loses job creation and PassRole; maintenance retains its independent path. Test the correct customer, a mismatched customer, attempted delegated writing and authorized maintenance. A global deny on Repair might protect data while simultaneously failing operational continuity. The conclusion should state which criteria were demonstrated, which results remain missing and who decides acceptance.

Local practice: compare five delegation designs

Download and extract this lesson’s lab. The README presents exercises; start with the delegation model, policy_model.py. Before execution, predict four outcomes for each configuration: correct-customer reading, access under a mismatched context, indirect provider writing and internal maintenance. Compare original, broker-only, meter-only, global-write-deny and separated-paths. Explain why removing all writes fails the continuity requirement. The model evaluates only supplied Boolean edges: it does not interpret IAM policies, issue credentials or call AWS. In a real environment, you would need to establish each edge and the absence of additional paths with appropriate authorization. Record these assumptions in your workpaper.

Exercise files

exercises with code and synthetic data. Requires Python 3.9 or later; no Docker, Internet or cloud account is needed.

Download the CISA lab (ZIP)

# Run from the extracted lab directory.
python3 -c "from policy_model import run_models; import json; print(json.dumps(run_models, indent=2))"
IN PRACTICE

Build a four-row matrix: correct-customer costs, another customer’s costs, writing through Repair and internal repair. Predict the outcomes before consulting the case solution.

Common pitfalls

Confusing a limit with a grant; ignoring principal changes; testing a predicate without testing control over attributes; treating token issuance as operation authorization; inferring absent activity from unconfigured logging.

Related topics: Identity, data and boundaries · Third-party assurance · Pipeline evidence

Take this idea with you

An access conclusion requires identifying relevant paths, the controls that actually constrain them and tests distinguishing authorized success from inappropriate access.

Create account
PreviousNext lesson

References

CISA® is a registered trademark of ISACA. bigsavant.com is an independent preparation platform and is not affiliated with, associated with, sponsored, authorised or endorsed by ISACA. Content and questions are original, are not official exam questions, and completing our tests does not award or guarantee any certification. Names are used only to identify the subject. All other trademarks belong to their respective owners.