# Pathrule Pattern: Security Audit Logging (1.0.0) # ::pathrule:package:security-audit-logging ### [RULE] Sensitive operations emit one canonical audit event (path: /src/audit) Audit coverage is defined from security-relevant actions, not from whatever application logs already happen to exist. Every sensitive operation emits a canonical event at the authoritative boundary with event type, event id, occurred time, recorded time, actor, delegated actor, tenant, action, protected object reference, result, safe reason, policy version, request correlation, and trusted source context. - Record denied and failed attempts as well as successful changes when they carry security meaning. - Emit after the authoritative result is known, or link separate attempt and outcome events through one operation id. - Use controlled event names and fields so investigations do not depend on parsing prose. - Keep clocks synchronized and preserve both event occurrence and ingestion times. Verification: Enumerate protected capabilities and fail tests when any success, denial, failure, or delegated path lacks its required canonical event. --- ### [RULE] Audit events exclude secrets and sanitize untrusted fields (path: /src/audit) An audit store is widely retained and highly searchable, so a useful event must still minimize exposure. Define an allowlisted schema for each event family and reject or redact fields outside it. Never record authentication secrets, access tokens, refresh tokens, API keys, passwords, connection strings, full payment data, or raw sensitive request and response bodies. - Use stable internal references or approved pseudonymous identifiers instead of copying personal content. - Sanitize carriage returns, line feeds, delimiters, control characters, and encoding ambiguity before serialization. - Serialize structured events with a trusted library and prevent callers from supplying severity, event type, actor, or tenant fields they do not own. - Test redaction and schema rejection against nested values, exceptions, URLs, headers, and provider payloads. Verification: Inject secrets and log-forging characters through every untrusted field; confirm no forbidden value or forged record reaches storage or export. --- ### [RULE] Audit evidence is append-only and separately protected (path: /infra/logging) Evidence cannot be trustworthy when the same compromised application or administrator can edit the record of its own behavior. Send audit events to a separate append-only or immutability-controlled destination through a narrowly scoped writer identity. Restrict search, export, retention change, and deletion to separately approved roles and record their use. - Buffer or queue safely so temporary destination failure is visible and governed by a defined fail-open or fail-closed policy per event class. - Monitor event volume gaps, schema rejection, delivery lag, clock drift, writer changes, retention changes, and privileged reads. - Protect transport integrity and validate source identity at ingestion. - Test restoration and export so retained evidence remains usable during an incident. Verification: Compromise a test application identity and attempt read, overwrite, delete, disable, retention change, and forged-source writes; confirm each is denied or detected. --- ### [MEMORY] Audit, security, transaction, and diagnostic logs have different purposes (path: /src/security) Audit events support accountability and investigation, security events support detection and response, transaction records support business truth, and diagnostic logs support operation and debugging. One action may create linked records in several systems, but their schemas, access, retention, mutability, and sensitive-data policies differ. Use shared event or correlation ids to connect them rather than copying entire payloads. Do not treat an application info log as an audit record or make the audit store a replacement for the financial ledger. Define which system owns each fact and how an investigator crosses the boundary under authorization. See /src/audit for the canonical event schema and /infra/logging for protected storage. --- ### [MEMORY] Retention and export follow event risk and investigation needs (path: /infra/logging) Keeping every audit event forever increases exposure, while deleting too early destroys investigation and accountability. Classify event families by security value, regulatory or contractual need, subject rights, operational volume, and expected investigation window. Assign a retention period and authorized exception process to each class. Preserve schema versions and export field definitions so older records remain interpretable. Test legal hold, approved deletion, restoration, and export integrity without granting broad production access. Record changes to retention and access policy in the audit system itself. Review low-value high-volume fields that raise cost or privacy risk without improving decisions. See /src/security for separation from diagnostics and transaction records.