The First Trust Boundary: A Working Model

HyperAudit’s design becomes easier to judge once the earlier problem is expressed as a model of evidence states rather than a list of attacks. The focus here is to connect three facts: events begin in a guest kernel, pending records can remain mutable, and HyperAudit assigns collection and persistence to different authorities. The useful result is a boundary test anyone can apply to this architecture: who generates the evidence, who can alter it while it is pending, who commits it, and what time period the guarantee covers?

Those questions do not add a new mechanism. They make the existing design legible. They also prevent two opposite mistakes: treating every remote record as trustworthy because it eventually reaches protected storage, or treating a higher-privilege collector as automatically complete because it is harder for the guest to reach.

One event, several evidence states

An audit event is not a single object that moves unchanged from a program to a database. It begins as an action in the workload, becomes a set of facts observed at the syscall boundary, becomes a pending record in a buffer, and later becomes a processed and persistent record. At each transition, the record can gain context, lose information, wait for capacity, or become harder—or easier—for an attacker to alter.

The first distinction is between generation and collection. The guest kernel executes the system call and is close to the information needed to describe it. A collector then assembles a record from that information. If the collector and its buffer are guest-kernel objects, the attacker who later gains kernel privilege can reach both the mechanism and the pending state. If the collector is isolated by the hypervisor, the guest still generates the event, but the guest kernel no longer controls every representation of that event.

The second distinction is between pending and committed evidence. A record in a buffer may be complete in format and still provisional in authority. It is committed only when the relevant transition places it beyond the attacker’s ability to rewrite it under the stated threat model. This is why a protected database does not answer the whole integrity question. The database controls the record after arrival; it does not control the record’s earlier custody.

The third distinction is between interpretation and preservation. A collector may capture low-level facts while a later component reconstructs process, file, or descriptor context. That division can reduce work on the syscall path, but it also means that a persistent byte stream is not automatically a meaningful investigation record. Context depends on the relationships preserved across events, and those relationships depend on what the collector actually captured.

A compromise can affect several states differently. It can change what the guest kernel exposes, alter a guest-owned buffer, delay or flood submissions, or generate new events after the compromise. HyperAudit’s claim is not that all those states become equally trustworthy. Its claim is that selected pre-compromise records can remain protected even after the guest kernel itself is no longer trustworthy.

This state model also separates four kinds of failure that are easy to conflate. Visibility asks whether the collector can see the event at all. Content asks whether the facts in the record are accurate. Ordering asks whether related events can be placed in the sequence that gives them meaning. Availability asks whether the record arrives in time and survives load.