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

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.