Unit 7.4 · about 3 h
286 / 324Audit records, fail-open versus fail-closed and supply chain
Assumes the Programming unit on logs, metrics and traces (bounded labels, secret exclusion, OpenTelemetry) as background. This unit adds the audit contract around it: tamper-evident records, explicit failure defaults, and build-to-deploy provenance.
- explain
You can now
- Write audit records that state who did what with which parameters, and redact secrets before they reach telemetry.
- Choose fail-closed versus fail-open per operation, and defend the default when policy or time data is missing.
- Name the supply-chain control points from code review to provenance-checked deployment, and the adversary each one stops.
Covers
- Audit records, redaction and sensitive telemetry
- Fail-open versus fail-closed behavior
- Dependency and software-supply-chain risk vocabulary
Study, in this order
4 steps
- Collecting auditable recordsBuilding Secure and Reliable Systems - selected design route
Chapter 5, Best Practices: Auditing (Collecting good audit logs, Choosing an auditor); Graceful Failure and Breakglass Mechanisms
- Failing safe versus failing secureBuilding Secure and Reliable Systems - selected design route
Chapter 8, Automate Responsibly: Failing safe versus failing secure (allow-all versus deny-all default ACLs when integrity is unverified)
- Revocation, failing open and intended stateBuilding Secure and Reliable Systems - selected design route
Chapter 9, Design Principles for Recovery: Use an Explicit Revocation Mechanism (centralized revocation service, Failing open with the time-service outage example, Revoking credentials at scale); Know Your Intended State, Down to the Bytes
- Supply-chain threat model and provenanceBuilding Secure and Reliable Systems - selected design route
Chapter 14, Deploying Code: Threat Model (benign insiders, malicious insiders, compromised accounts); Best Practices (Require Code Reviews, Verify Artifacts, Not Just People); Advanced Mitigation Strategies (Binary Provenance, Provenance-Based Deployment Policies); Deployment Choke Points
Depth · Read for control points and vocabulary, not build-system implementation.
Focus on
- Audit the useful parameters: small APIs make each record one granular action, while broad sessions cannot be audited meaningfully.
- Failing open trades lockout risk for attacker reuse: a revocation service that accepts stale credentials during a time-service outage revalidates revoked keys.
- Prefer cached revocation data with best-known state over timeout-and-allow. State which clock or freshness assumption each choice keeps.
- Verify artifacts, not people: reviews, tests, provenance and deployment choke points each stop a different supply-chain adversary.
Reproduce closed-book
Traps
- Logging secrets to make audit complete. Completeness never justifies credentials in logs; record the key id and the decision instead.
- Assuming fail-open is the reliable choice everywhere. Chapter 8 says security-critical operations should not fail open, because a denial of service alone would then weaken security; revocation keeps last-known-good data instead.
- Trusting build-time checks while deployments bypass them. Controls must reject artifacts that skip the chain.
Practice
The section mini-project covers this: audit tests for unauthorized and cross-tenant attempts, plus backup and restore verification with integrity checks.
Self-test
-
The certificate validity database cannot reach the time service. Why is accept-on-timeout dangerous?
Revoked certificates read as valid for the whole outage, and a cheap DoS on the time service extends it. Cache revocation data instead. -
What must an audit record of a grant contain, and what must it never contain?
Actor, action, scope and parameters such as key id; never the secret itself. -
A binary reaches production without passing CI. Which control failed?
The deployment choke point. Build checks cannot help if deployment accepts unprovenanced artifacts. -
ACLs fail to load. What default does a reliability-first design assume, what does a security-first design assume, and which wins for a security-critical operation?
Allow all versus deny all. Security-critical operations should not fail open; they may degrade to a lower-cost component that applies stronger controls, not weaker ones.
Completion criterion
Stop when
You can defend the fail-open versus fail-closed default of each gate and trace one artifact from review to provenanced deployment.
Mark passed, then open 7.5 Only mark this when you can do it without notes.Leads to
- 7.7 Compatibility, rollback and revocation during changes Carry audit and revocation behavior through rollback and migration.
- 6.8 Backups, runbooks, incident timelines and postmortems Feed audit trails into incident timelines and postmortems.
Comes after
- 7.3 Tenant isolation, input validation and injectionLog tenant-scoped decisions with redacted telemetry.
Resources for this unit
- Building Secure and Reliable Systems - selected design route Read Chapters 1, 2, 4-9 and 12-14: adversaries, trade-offs, least privilege, understandability, changing landscapes, resilience, recovery, code, tests and deployment. Apply the chapter questions to the same RPC, store, tenant and migration boundary.
Also in this section
- OpenDP theory - one bounded privacy mechanism Read A Framework to Understand DP and Differential Privacy with OpenDP (in the 0.16.0 user guide, Framework API), then Accuracy: Pitfalls and Edge Cases and the Differencing, Membership and Reconstruction attack notebooks. Define one privacy unit, clamp an aggregate, add calibrated noise, record \(\epsilon\) and \(\delta\) inputs, measure utility and list everything outside the guarantee.
- OWASP Threat Modeling Cheat Sheet Model trust boundaries, data flows, data stores, processes and external entities, and list the assets they carry. Write misuse cases for unauthorized mutation, cross-tenant reads, stale credentials, sensitive logs and restore or migration paths, then turn each into a test or explicit residual risk.
- OSTEP - introductory security chapters Use Chapters 53-56 for introductory security, authentication, access control and cryptography vocabulary. Connect process and container isolation to the threat model and state where those boundaries do not protect the system.
- Systems Foundations Checkpoint - security and privacy slice Use only the tenant-access, privacy aggregate, abuse, migration, backup and residual-risk requirements as the final assessment. A toy privacy mechanism is evidence for its stated aggregate, not a claim that the service or model is private.
- Data Privacy and Security (MIT Data-Centric AI) Read the threat-model examples, shadow-training and metrics-based membership attacks, extraction by sampling plus perplexity ranking, empirical-defense evaluation, and the \((\epsilon, \delta)\) definition with DP-SGD.
- A Survey of Privacy Attacks in Machine Learning Use the attack taxonomy and threat model (adversarial knowledge, assets under attack) plus the causes of leaks and the defenses overview; skip the per-paper catalog.
- Targeted Backdoor Attacks on Deep Learning Systems Using Data Poisoning Read the weak threat model (no model or training-set knowledge, about 50 poisoning samples) and the reported result of above 90 percent attack success; skip the optimization details.
- OWASP Input Validation Cheat Sheet Apply allowlist validation, parse-safely-then-validate, structured-data rules, and the common pitfalls (client-only checks, trusted internal sources, denylisting, logging rejected input).
- OWASP Deserialization Cheat Sheet Apply the Python clear-box rules (
pickle, unsafe YAML loaders,jsonpickle) and the language-agnostic methods (pure-data formats, signed data).