Audit and evidence

Summary. WKL TrustBridge separates three kinds of records by their evidential value: an operations log for troubleshooting, a security audit log of what people, services, and connections did, and a tamper-evident ledger of issuance, revocation, approvals, and relationships. A hash chain proves only as much as its head lies outside the reach of whoever it is meant to prove against; that is why chain heads are anchored externally. The second half of the page maps the requirements of the regulatory frameworks to the measures and separates the evidence TrustBridge supplies from the evidence the operating organization provides itself.

• Hash chain – a sequence of entries in which each one contains the hash of its predecessor; changing an entry breaks the chain from that point on.
• Chain head – the hash of the most recent entry.
• External anchor – a copy of the chain head in append-only storage outside the reach of the database and worker-host administrators.
• Truncation – deleting the most recent entries; invisible without an external anchor, because the remaining chain is intact.

An event belongs in the highest level it concerns; a copy in a lower level is allowed but does not replace it.

graph TD
  subgraph PL [TrustBridge installation]
    DB[(Security audit log<br/>chained per tenant)]
    REG[(Worker ledger)]
    RR[(Root ledger)]
  end
  subgraph EX [Outside the administrators' reach]
    ANK[(Append-only storage)]
  end
  DB -->|continuous copy<br/>and chain head| ANK
  REG -->|chain head, periodically| ANK
  REG -->|chain head into every ceremony| RR
  classDef ex fill:#dff6dd,stroke:#107c10,color:#201f1e
  classDef pl fill:#f3f2f1,stroke:#605e5c,color:#201f1e
  class ANK ex
  class DB,REG,RR pl
  style PL fill:#ffffff,stroke:#8a8886,color:#201f1e
  style EX fill:#ffffff,stroke:#8a8886,color:#201f1e

For each issuance, the ledger holds the order hash, the approval or attestation signatures with the identifier of the key, the rule set version the order was checked against, and the tenant. With that, a third party can establish without the database: person X approved bytes Y, verifiable with the public key from the rule set; certificate Z matches those bytes and carries the CA's signature.

TrustBridge's sign-in components (personal key, second factor, session) deliberately emit no events of their own; they return results. Management turns those results into security events and writes them in one transaction together with the state change. Passwords, codes, and keys never appear in an event; for personal keys, only the identifier and the last four characters are kept.

If an organization's support staff or its operating partner can see several tenants, it is traceable who opened or exported which partner's data and when: for visibility scopes spanning more than one tenant, management writes every opening of an individual record and every export to the security audit log.

An auditor who receives an extract from an organization can trace an issuance without access to the database: the chain, the approval, the match between order and certificate, and the revocations. The same procedure applies to relationships; every relationship, every change, and every revocation can be matched against the signed trust bundle the TLS adapters used at that time.

For this, TrustBridge provides a ledger extract in a published format, the rule set versions with their public keys, and a verification tool that performs these steps without access to the installation. The four steps are in Verify an issuance as a third party.

• No conformity. The table shows which measures address a requirement and which evidence TrustBridge contributes. A certification or attestation is obtained by the operating organization with its own evidence.
• No retention periods for any particular organization. The defaults are in Operations and emergencies; each organization sets its own periods (M-74 in Security measures).