E6 ยท Publication Volume 28
Security, Identity and Audit
authentication, authorisation, least privilege and logs
*authentication, authorisation, least privilege and logs*
Learning objectives
This lesson is general and institution-neutral. It uses no real company, individual, property, project or identifiable place. Generic roles describe responsibilities only, and SYN-ARCH identifiers denote explicitly synthetic teaching evidence.
- Frame the decision governed by authentication, authorisation, least privilege and logs.
- Model the relevant boundaries, states and contracts before selecting an implementation.
- Define measurable invariants, failure evidence and a safe release consequence.
- Produce a threat-informed permission matrix and auditable control specification from synthetic evidence and defend its trade-offs.
Decision boundary
Protect decisions and evidence according to consequence, not merely by hiding a user interface. Identify subjects, resources, actions, context, trust boundaries and disclosure effects. Authentication establishes a bounded claim about an identity; authorisation decides whether that identity may perform one action on one resource version in the current context. Least privilege limits both ordinary access and automated execution. Approval, publication, policy change and audit administration require stronger separation than routine viewing. Security controls support professional responsibility but cannot decide scientific fitness or confer competence on a role.
Core concepts
Separate human, workload, device and service identities and record which claims are trusted at each boundary. Role-based rules are useful for stable responsibilities; attribute and resource policies add project, classification, version, extent, purpose or approval context. Default denial makes omissions visible. A complete decision considers confidentiality, integrity, availability, provenance and accountability. Audit is not unrestricted surveillance: collect events needed to reconstruct consequential actions, minimize personal data, protect records from alteration and define retention. Continuous verification re-evaluates subject, resource and context instead of granting permanent trust after one login.
System model and contracts
Create an asset and decision register linked to threats, vulnerabilities, controls, evidence and residual risk. A permission matrix uses subject class, action, resource class, state, version, spatial scope and conditions, with explicit deny and approval rules. Trust-boundary diagrams show identity issuance, credential use, policy decision, enforcement point, data movement and audit sink. Consequential audit events record stable event identity, time source, acting and delegated identities, action, resource identity and version, policy result, request correlation, outcome and reason while excluding secrets and unnecessary content.
Invariants and acceptance criteria
| Invariant | Test evidence | Release consequence | |---|---|---| | Every consequential action is authorised for one identity, resource version and scope. | contract test and recorded counterexample | block publication | | Execution identities cannot approve or publish their own outputs. | replay comparison and digest check | quarantine the artefact | | Revocation and permission reduction take effect through tested paths. | role-based acceptance trace | return the decision unresolved | | Audit records are complete, integrity protected and free of secrets. | failure injection and recovery record | retain the last verified version | | Residual security risk remains visible to the accountable review role. | domain review against declared evidence | record an explicit review finding |
Quantitative engineering
Control coverage is C_c=n_{verified}/n_{applicable}, reported by risk class rather than as one comforting total. Measure privileged-path count, unused grants, denied-action class, revocation delay, policy-evaluation failure, audit-event completeness, time synchronization error and restoration of protected evidence. Access review samples both allowed and denied cases. A low denial count may mean correct design or missing enforcement, so interpret it with test and workload evidence. Risk scores are decision aids only when likelihood, consequence, uncertainty and review authority are declared.
Data quality, evidence and uncertainty
Security evidence combines threat scenarios, configuration and policy review, permission tests, dependency records, vulnerability findings, attack simulation, audit replay, backup restoration and incident exercises. Synthetic fixtures include an expired credential, changed role, restricted extent, cross-branch request, delegated job, forged token, replayed command and tampered audit event. Test negative paths as deliberately as successful access. A passed scanner or checklist does not prove that domain resources, version semantics or professional approvals are protected; reviewers trace controls to concrete decisions and residual risks.
Interoperability and versioning
Identity contracts define issuer class, subject identifier, audience, validity, assurance and delegation without exposing credentials. Authorisation contracts define policy inputs, decision values, enforcement behaviour and failure mode. Resource contracts carry classification and ownership role independent of storage path. Audit schemas use stable controlled action and result codes, versioned event fields and correlation identities. Policy and control packages are versioned, reviewed and linked to releases. If the policy service is unavailable, each operation has a declared fail-closed or carefully bounded degraded behaviour; silent permit is not a default.
Security and professional responsibility
Layer controls so one mistake does not expose every version or operation: validate inputs, authenticate identities, authorise the exact action, isolate execution, protect data in transit and storage, verify artefact integrity, constrain export and record consequential outcomes. Rotate and revoke credentials through tested procedures. Administrative access is temporary, justified and independently reviewed. Logs never contain passwords, private keys, raw tokens or unrestricted payloads. Break-glass access has narrow scope, strong recording, explicit expiry and retrospective review; it does not bypass immutable scientific history.
Operational workflow and observability
Continuously reconcile identities, grants, resource classifications and policy versions. Alert on impossible transitions, repeated denied high-consequence actions, use after revocation, audit gaps, unexpected export volume and policy drift, but tune alerts against known workload to avoid unusable noise. Review dormant privileges and machine identities. Preserve an evidence chain from alert through triage, containment, correction, recovery and lessons learned. Security updates follow controlled build, test and release paths; urgency changes priority, not the need to know what changed and how to reverse it safely.
Integration checkpoint
Connect the security, identity and audit artefact to the preceding volume architecture. Trace one synthetic object from source identity through the new boundary to a reviewed output, then trace one rejection or failure back to the earliest violated invariant. Update the architecture decision record with the chosen option, alternatives, assumptions, evidence, consequences, owner role, review state and triggers for reconsideration. A checkpoint passes only when another reviewer can reconstruct both the successful path and the blocked path without oral explanation.
Synthetic worked example
SYN-ARCH-09 initially grants every reviewer one broad read role and lets the processing identity publish results. A synthetic restricted extent appears in a collection count, and a compromised job could approve its own output. The revised policy authorises metadata, content, execution and publication separately by resource version and scope. The job identity writes only candidate artefacts; an independent review role approves one manifest. Revocation tests remove access without waiting for cache expiry, and an audit replay reconstructs the request, policy decision, candidate digest, approval and publication without exposing the protected geometry.
Practice and assessment
- Which decisions and evidence require protection from which consequences?
- What exact subject, action, resource, version and context form each policy rule?
- How are privileged transitions separated and independently reviewed?
- Can an audit replay reconstruct an action without exposing protected content?
Assessed artefact: a threat-informed permission matrix and auditable control specification. Submit the artefact with its source manifest, acceptance evidence, unresolved risks and a short explanation of why one plausible alternative was not selected.
Common failure modes
- Treating successful login as permission for every resource and action.
- Using one broad role without resource, version or spatial scope.
- Allowing the same identity to execute, verify and approve a result.
- Recording secrets or protected payloads in audit logs.
- Counting a checklist as evidence that controls work in operation.
Sources and further reading
- NIST SP 800-53 Rev. 5 control catalogue, covering access control, audit, configuration, recovery and system integrity.
- NIST SP 800-207 Zero Trust Architecture, focusing trust decisions on identities, assets and resources rather than network location.
- NIST SP 800-218 Secure Software Development Framework 1.1, providing high-level secure-development practices across the life cycle.
- ISO 31000:2018 risk-management guidelines, providing principles, a framework and a process for risk-informed decisions.
- RFC 9562 Universally Unique Identifiers, defining identifier layouts and operational considerations for distributed generation.