whitehat-security/docs/attacker-model.md

# Attacker model for tenancy evidence

Status: **active**

Version: 0.1

Date: 2026-08-21

Owner: NetKingdom / `whitehat-security`

Governing rules: [`rules-of-engagement.md`](rules-of-engagement.md)

## 1. Purpose

This document states what an adversary is assumed to hold for each probe
family. It prevents two opposite errors:

- testing a weaker attacker than the posture claim requires and reporting a
  misleading pass;
- giving the attacker powers outside the claimed control and reporting a
  documented limitation as a failed control.

The model is part of every run record. A run without a named model is
inconclusive.

## 2. Common conditions

Every model below inherits these conditions:

- The target, time window, technique, source, rate ceiling and abort contact
  come from an approved engagement record.
- Tenant A and tenant B are disposable fixtures created for the engagement.
  Real tenant data is never used as bait or retained as evidence.
- Knowing tenant B's fixture identifiers is an orchestration capability, not
  evidence that the target disclosed them. Identifier discovery is tested
  separately when it is in scope.
- The adversary may repeat, reorder and vary operations that an ordinary holder
  of its stated capability can perform. It does not gain unlisted privilege
  merely because the harness could obtain it.
- Evidence stores status, counts, schema shape and run-local digests—not
  response bodies, credentials or real tenant values.
- Outcomes are `pass`, `finding`, `inconclusive` or `aborted`. This repository
  assigns no severity.
- A pass means only that the attacks attempted under this model did not work.

## 3. E2 — authenticated tenant A at the service boundary

### Adversary holds

- A legitimate runtime or user credential accepted by the target.
- Valid authority for tenant A and no authority for tenant B.
- The ability to make ordinary supported requests.
- Tenant B fixture object identifiers supplied by the harness.

### May attempt

- Substitute tenant B identifiers into paths, query parameters, bodies,
  cursors, filters, batch items and relationship traversals.
- Replay a valid tenant A request while changing one tenant-bearing field at a
  time.
- Exercise read, create, update and delete surfaces covered by the engagement.
- Compare tenant A and tenant B responses, including status, count, schema
  shape, timing class and subsequent fixture state.

### Does not hold

- SQL execution, a database credential, service-process control, operator
  authority or tenant B membership.
- Permission to enumerate unrelated production identifiers or retain returned
  tenant data.

### Finding condition

The tenant A identity reads tenant B fixture content, changes tenant B fixture
state, creates data attributed to tenant B, or obtains a cross-tenant
relationship it is not permitted to observe. A well-formed `200` is not a pass;
the response and resulting state must be compared with the fixture oracle.

`403`, `404` and empty results can each be valid target behavior. The evidence
records behavior without requiring one status code, while checking that the
surface does not become an existence oracle when that is part of the target's
claim.

### What a pass supports

Only the E2 claim for the exercised choke point, operations, target revision and
review date. It says nothing about an unexercised route, SQL injection or
process compromise.

## 4. E3 — platform-assisted filtering

E3 layers on E2 and has two deliberately different models.

### E3-A: omitted-predicate or bypassed-choke-point accident

The adversary is a defective code path, not a compromised process.

It holds the ordinary leased database role and runs inside an explicit
transaction with tenant A set using the documented transaction-local GUC. It
may issue a query that omits the service-side tenant predicate or bypasses the
E2 choke point.

A tenant B row becoming visible or writable is a finding. E3 exists to stop
this case.

The conformance run also checks:

- every tenant-owned table enables and forces RLS;
- every policy covers reads and writes;
- the runtime and leased roles lack `BYPASSRLS`;
- an unset GUC reads no rows;
- tenant A's GUC reads or writes no tenant B rows;
- ordinary callable functions do not acquire a table owner's exemption through
  an unreviewed `SECURITY DEFINER` path;
- hot-query plans have a recorded before/after comparison.

A missing policy, `BYPASSRLS` grant or unsafe definer function is a
configuration finding. The harness must not grant those powers merely to make
the attack stronger.

### E3-B: SQL-capable compromise

The adversary holds SQL execution on the ordinary runtime connection. It may
issue another `SET LOCAL` and change the custom tenant GUC to tenant B.

Cross-tenant access after that reset is **the documented limit of E3**, not an
E3 conformance failure. The run records the observation so reports cannot
silently imply that E3 withstands SQL injection or process compromise.

If the same credential cannot address tenant B even after the reset, that may
be evidence of E4-shaped structural confinement, but it does not upgrade the
claim without the E4 model and substrate evidence.

### What a pass supports

E3-A supports protection against omitted predicates and bypassed application
paths for the exercised schema revision. E3-B has no expected E3 pass:
its purpose is to demonstrate and preserve the boundary of the claim.

## 5. E4 — leaked per-tenant credential

### Adversary holds

- Tenant A's real per-tenant credential, leased for the engagement.
- The connection information that an ordinary tenant A workload receives.
- Knowledge of the separately provisioned tenant B fixture substrate.

### May attempt

- Present tenant A's credential to tenant B's endpoint or database.
- Address tenant B through alternate database names, schemas, hosts or routing
  fields exposed to the ordinary workload.
- Reuse the credential until its recorded expiry, without extending or
  refreshing it outside its normal authority.

### Finding condition

Tenant A's credential authenticates to, addresses, reads from or writes to
tenant B's substrate. Network reachability alone is recorded but is not an E4
failure unless the claim includes network isolation; E4's core assertion is
credential and substrate confinement.

### Does not hold

A platform, migration, break-glass or tenant B credential; control of the
credential issuer; or permission to alter routing/provisioning state.

## 6. Shared P1/P2 capacity — bounded co-resident

This model tests capacity assurance, not the truth of the P1/P2 topology.

### Adversary holds

- A legitimate co-resident consumer identity.
- Its declared connection, query, CPU, memory or request allowance.
- The ability to generate synthetic load up to the engagement's explicit
  ceiling.

### May attempt

- Saturate its own declared allowance during the approved window.
- Use the permitted mix of expensive and concurrent operations.
- Continue until a governor binds, an abort threshold fires or the window ends.

### Finding and measurement conditions

- A claimed governor does not bind at its declared ceiling.
- Co-resident degradation is not measured against each consumer's declared
  service class.
- Aggregate headroom and shared failure conditions are omitted from the record.

If the harness exceeds the aggressor's authorized allowance, the run aborts and
is treated as a probe-control incident—not as a target finding.

Zero co-resident degradation is not expected on shared infrastructure. The
artifact records what degradation occurred and whether the responsible owner
accepts it; the probe does not manufacture a guarantee that P1/P2 cannot
provide.

No capacity probe has a default live authorization. Its engagement requires a
separate operator-approved window and explicit abort thresholds.

## 7. R4 — pre-erasure retained copy

The adversary holds an authorized copy created before erasure and the metadata
that legitimately survives under the target's declared R4 route. It attempts
recovery only against synthetic fixture data.

### R4-A: horizon-elapsed

After the published erasure horizon, attempt to recover the fixture from live
storage, backups, replicas, exports, indexes and declared derived copies.
Recoverable content after the horizon is a finding.

### R4-B: key-destroyed

After recorded destruction of the fixture's per-entity key, attempt to decrypt
every retained ciphertext and use retained hashes, chains, indexes or search
keys as confirmation oracles.

Readable content, a surviving usable key, or a retained low-entropy commitment
that confirms guesses about erased content is a finding. Destruction of a key
alone is not a pass.

### Does not hold

An undeclared backup, escrow or recovery key invented for the test. If the
evidence inventory cannot show that every declared copy was exercised, the
outcome is inconclusive rather than pass.

`audit-core` is not an R4 target under its current integrity-chain design; it
targets R2. The facility does not erase the evidence service's retained facts
to satisfy a fleet-wide aspiration.

## 8. Axes outside this first model

Identity (`I`), authorization (`A`) and availability (`V`) have evidence
requirements in Tenancy Posture, but `WHITEHAT-WP-0001` does not yet define
their adversarial facilities. A run under this document must not claim evidence
for those axes merely because it observed related behavior.

## 9. Model selection and review

Each engagement record names:

- the model and subsection used;
- the target revision and posture claim;
- the exact credential or identity class, never its value;
- all deliberate deviations from the common conditions;
- the known-bad fixture that proves the probe can fail;
- the review date and scheduled rerun date.

Review this model when the canonical posture mechanism changes, a target gains
a new credential or cross-tenant path, a probe discovers an unmodeled
capability, or a pass depends on excluding behavior an ordinary attacker could
perform.