Usage Reporting and Forensics in tiCrypt Audit

Why Audit Is Not Optional

Compliance frameworks like CMMC 2.0 Level 2 do not treat audit logging as a best practice. They treat it as a requirement. The Audit and Accountability (AU) domain of CMMC, mapped directly from NIST SP 800-171 Revision 2, defines nine controls that govern how systems must create, retain, protect, correlate, and report on audit records. These controls exist for a reason: without a trustworthy audit trail, there is no forensics, no accountability, and no way to prove that CUI was actually protected.

tiCrypt was designed from the start with the assumption that every action must be recorded and that records must be resistant to tampering. This article explains how tiCrypt's audit system works, what it captures, how it supports forensic investigation, and how it maps to the CMMC AU controls that organizations are assessed against.

What tiCrypt Records

tiCrypt's audit schema defines over 150 distinct event types, each with structured attributes that capture the full context of an operation. These events span every layer of the platform:

• Session lifecycle: Session requests, challenges, creation, invalidation, deletion, temporary sessions, subsession creation, permission additions, and session downgrades. Every login, logout, and privilege change is recorded with the user identity, source IP, timestamps, actions granted, expiration, and MFA token usage.
• File operations: File creation, deletion, chunk-level reads and writes, encryption key additions and retrievals, ownership changes, and project tagging. Each file event captures the session, file ID, and the specific key type and owner involved in the cryptographic operation.
• Directory operations: Entry additions, removals, renames, directory creation and deletion, root assignments, and project tagging. The full path context (directory ID, entry name, entry type, and target) is preserved.
• Virtual machine lifecycle: VM creation, registration, shutdown, deletion, proxied connection registration, authorized user changes, configuration management (create, verify, run, kill, update), and inter-VM messaging. VM events capture the VM Hardware Setup template, host registration details, and the user who initiated the action.
• Drive and storage: Drive creation, attachment, detachment, deletion, key management, ownership transfers, and project tagging. Storage-level reads and writes record transfer IDs, byte counts, and object identifiers.
• Group and team management: Group and team creation, deletion, member additions and removals, permission changes, quota assignments, and ownership transfers.
• Project governance: Project creation, modification, deletion, membership management (including expiration tracking), security level assignments, security requirement definitions, and user certification tracking.
• Key escrow: The complete escrow lifecycle, from escrow user and group creation through public key registration, escrowed key generation, recovery key set creation, and key retrieval. Every escrow operation records the authentication type, authorizer identity, and cryptographic parameters.
• Forms and data ingress: Form creation, token-based and session-based submissions, attachment reads, key management, and form metadata changes.
• Infrastructure: VM Hardware Setup management, libvirt host provisioning, realm restarts, image lifecycle, reservations, large uploads, and external server/SFTP configurations.
• System administration: Global settings and info changes, external server definitions, MFA token creation, notification delivery, service restarts, maintenance operations (clearing old accounts, keys, and drives), and device manager events.

Every event records a success or failure indication, the acting session or authentication context, and an error code when applicable. Version fields in the schema ensure backward compatibility as the audit format evolves across tiCrypt releases.

info

There is no notion of a non-audited action within the tiCrypt environment. If a user, administrator, or system process performs an operation, it produces an audit record.

How the Audit Trail Is Protected

An audit trail is only useful if it can be trusted. If an attacker or rogue administrator can modify or delete log entries, the trail becomes unreliable as evidence. tiCrypt addresses this with a cryptographic chaining mechanism.

Each audit record is hashed using SHA-256, and each hash incorporates the hash of the previous record. This creates a chain where any modification to a historical entry invalidates all subsequent hashes. The mechanism is structurally identical to the hash chaining used in blockchain systems: the integrity of the entire chain can be verified by recomputing hashes forward from any checkpoint.

This design has several practical consequences:

• Tamper evidence: Modifying, inserting, or deleting a log entry breaks the hash chain. The inconsistency is detectable automatically.
• Non-repudiation: Because every action is tied to a cryptographic identity (session, user, or authentication context) and protected by the hash chain, users cannot plausibly deny actions attributed to them.
• Independent verification: Because tiCrypt Audit runs as a separate system from the tiCrypt backend, and multiple independent audit installations can consume the same log stream, independent system log consumption is possible.

warning

The audit system is architecturally separated from the tiCrypt backend. The tiaudit-logger service receives log entries pushed from the backend and writes them to ClickHouse. The backend does not have write access to the audit database, and the audit system does not have access to the backend. This separation ensures that compromising one does not grant the ability to tamper with the other.

Architecture of tiCrypt Audit

tiCrypt Audit consists of three independent components:

1. tiaudit: The main service that hosts the audit interface and reporting engine. Administrators interact with this to run queries, generate reports, and configure alerts.
2. tiaudit-logger: A background service that listens for new log entries pushed from the tiCrypt backend, parses them according to the audit schema, validates the hash chain, and inserts structured records into ClickHouse.
3. tiaudit-log-uploader: A utility for backfilling historical logs during initial deployment or recovery.

ClickHouse serves as the backing database. It is a column-oriented analytics engine optimized for the kind of queries audit work demands: filtering millions of records by time range, user, event type, or object ID and returning results in seconds. In practice, queries across large datasets complete in one to two seconds.

tip

Multiple independent tiCrypt Audit installations can serve a single tiCrypt backend. Deploying audit on a separate server from the backend is a recommended practice that strengthens both availability and tamper resistance.

Usage Reporting

tiCrypt Audit's reporting engine provides three layers of access to audit data, designed for different roles and use cases:

Reports

Pre-built compliance reports can be generated with a single action. Each report is parameterized by time range and optionally scoped to specific objects (users, teams, projects, VMs, or files). Output is in .xlsx format with charting for visual analysis. These reports are designed to satisfy the documentation requirements of CMMC assessments, NIST 800-171 self-assessments, and ITAR reviews.

Reports answer questions like:

• Which users accessed which files during a given period?
• What VM sessions were active and what actions were taken?
• Which administrative changes were made to team memberships or project configurations?
• What encryption keys were created, retrieved, or revoked?

Queries

Built-in parameterized queries provide targeted interrogation of the audit database. Queries are filterable by teams, users, query type, time range, and result status (success or failure). These are the primary tool for day-to-day monitoring and investigation.

Direct SQL Access

For ad-hoc analysis beyond what pre-built queries and reports cover, tiCrypt Audit exposes direct SQL access to the ClickHouse database. This allows administrators and auditors to write custom queries against the full audit schema, useful for forensic investigations or building custom dashboards.

Programmatic Access

The tiCrypt Audit REST API provides token-based access to all reporting and query functions. This enables integration with external SIEM platforms, automated compliance workflows, and custom tooling.

Forensic Investigation

When an incident occurs, whether it is an unauthorized access attempt, a data exfiltration concern, or a compliance inquiry, the audit trail must support rapid, targeted investigation. tiCrypt's audit system is built for this.

Reconstructing user activity: Every session event records the user identity, source IP, timestamps, granted actions, and MFA tokens used. By querying session events for a specific user or IP range, an investigator can reconstruct the complete sequence of sessions, what permissions were granted, and when sessions were terminated or downgraded.

Tracing data access: File key retrieval events (record type FG) capture the session, file ID, key type, key owner, and an intent field that records why the key was accessed. Combined with chunk-level read events (FR), an investigator can determine exactly which files a user accessed, when, and at what granularity.

Detecting privilege escalation: Group member additions (GA), permission modifications (GB), and role changes (UM) are all recorded with the acting session. Any attempt to grant unauthorized access produces a traceable record.

Identifying infrastructure changes: VM creation, host provisioning, VM Hardware Setup template modifications, and external server configurations are all recorded. Changes to the infrastructure that hosts CUI are as auditable as changes to the data itself.

Hash chain verification: If there is any suspicion of log tampering, the SHA-256 hash chain can be verified programmatically. A break in the chain pinpoints the exact record where tampering occurred.

Alerts vs Logging

tiCrypt Audit draws a clear distinction between alerts and logging. They serve different purposes and operate on different timescales.

Alerts are triggered by system events that require immediate attention. They are not records to be reviewed later; they are notifications that something has happened that a security team needs to act on now. Examples of alert-generating events include:

• User added — a new account has been created in the system
• User role change — a user's permissions or role has been modified
• Hash chain interruption — the SHA-256 audit chain has been broken, indicating possible tampering
• File downloaded — a file has been retrieved from the secure environment
• Account deactivation — a user account has been disabled
• XSS attack detected — a cross-site scripting attempt has been identified
• Account locked — a user account has been locked due to failed authentication or administrative action

These alerts are designed to be pushed into an organization's existing security infrastructure. tiCrypt Audit includes a dedicated Splunk driver for direct integration, as well as support for email (SMTP) and console output. Organizations using other SIEM platforms such as LogRhythm can receive alerts through their standard ingestion pipelines.

Logging, by contrast, is the complete, tamper-evident record of every operation in the system. The secure logs protected by the SHA-256 hash chain are not for real-time response. They exist for historical analysis, forensic investigation, and compliance reporting. When an auditor asks "what happened in this project over the last six months," the answer comes from the logs. When a security team needs to reconstruct the full sequence of events surrounding an incident, the logs provide the authoritative timeline.

The distinction matters operationally. Alerts tell you something is happening. Logs tell you everything that happened. A well-configured tiCrypt deployment uses both: alerts routed to the SOC for immediate triage, and logs retained indefinitely for the investigative and compliance work that follows.

tip

Organizations undergoing CMMC assessment should ensure that alert integration with their SIEM is documented in their System Security Plan. Assessors evaluating AU.L2-3.3.4 (audit failure alerting) and AU.L2-3.3.5 (audit correlation) will look for evidence that alerts are actively monitored, not just available.

Mapping to CMMC AU Controls

The nine Audit and Accountability controls in CMMC Level 2 map directly to tiCrypt capabilities:

CMMC Control	Requirement	tiCrypt Implementation
AU.L2-3.3.1	Create and retain system audit logs	150+ event types with structured attributes; lifetime retention (logs are never discarded)
AU.L2-3.3.2	Trace actions to individual users	Every event is tied to a session or authentication context with cryptographic identity; no shared or anonymous actions
AU.L2-3.3.3	Review and update logged events	Pre-built queries, custom SQL, and configurable alert rules; schema versioning supports evolving event definitions
AU.L2-3.3.4	Alert on audit process failure	Alert drivers (Email, Splunk, console) notify on hash chain breaks, logging failures, and anomalous conditions
AU.L2-3.3.5	Correlate audit records	ClickHouse enables cross-event correlation by user, session, time range, object ID, or any combination; sub-second query performance
AU.L2-3.3.6	Reduction and reporting	One-click compliance reports in .xlsx; parameterized queries with filtering; REST API for programmatic access
AU.L2-3.3.7	Authoritative time source	Millisecond-precision timestamps on all events; system time synchronized to NTP
AU.L2-3.3.8	Protect audit information	SHA-256 hash chain provides tamper evidence; architectural separation of audit and backend systems; role-based access to audit data
AU.L2-3.3.9	Limit audit management	Only designated administrators can configure logging, manage alerts, or access the audit interface; role-based access enforced at the application level

note

CMMC Level 2 does not prescribe a specific log retention period, but DFARS 252.204-7012 requires preserving cyber incident data for at least 90 days from incident report submission. tiCrypt exceeds this by retaining all audit logs for the lifetime of the installation. No records are ever discarded.

Mechanism Over Policy

Many compliance approaches rely on written policies and manual procedures: "administrators shall review logs weekly," "users shall not share credentials," "systems shall be configured to log events." These policies are necessary for governance, but they are only as reliable as the people who follow them.

tiCrypt takes a different approach. The audit system is not something an administrator enables or configures per-policy. It is a structural property of the platform. Every operation produces an audit record because the backend emits log entries as part of its normal processing. There is no flag to disable logging. There is no way to perform an action without producing a record. The hash chain ensures that records, once written, cannot be silently altered.

This is the distinction between mechanism and policy. Policy says "you should log events." Mechanism means events are logged whether or not anyone remembers to configure it. For organizations undergoing CMMC assessment, this distinction matters: assessors are looking for evidence that controls are implemented, not just documented.

Audit in tiCrypt is not a feature you turn on. It is a property of how the system operates.

Audit as Infrastructure

Audit logging is often treated as an afterthought, something bolted on to satisfy a compliance checkbox. tiCrypt treats it as foundational infrastructure. The combination of comprehensive event capture, cryptographic chain protection, architectural separation, and high-performance analytics creates an audit system that serves both compliance and real forensic investigation.

For organizations handling CUI under CMMC 2.0, the audit system provides direct, demonstrable coverage of all nine AU controls. For administrators and security teams, it provides the tools to answer hard questions quickly: who did what, when, to which data, and can we prove it.