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.

Executable calibration is whitehat e4-fixtures. It is in-process, projects no credential, and is not target assurance. No live E4 target is registered. Tenancy Posture §13 classifies the live E4 artifact as Mechanical. This calibration does not perform that demonstration. A live demonstration waits on WHITEHAT-WP-0012-T03.

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. A live exercise waits on WHITEHAT-WP-0012-T04.

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.

Executable calibration is whitehat r4-fixtures. It is in-process, opens no store, and is not target assurance. An incomplete copy inventory stays inconclusive. No live R4 target is registered.

8. Axes outside this adversarial facility

Tenancy Posture v0.1 §13 classifies the evidence, and this section follows that classification. A run under this document must not claim an axis merely because it observed related behavior.

Identity (I) and authorization (A)

I2, I3, A2, A3, and A4 evidence is Mechanical. It belongs in the declaring service's CI: identifier validation, a rejection test, a verified-token binding, a live re-query on an aal2-class path, a choke point that refuses an unbound request, a denial observed at the endpoint, and a second PDP substituted without a PEP change. This repository does not build an adversarial probe for those artifacts. whitehat cadence has no I or A family.

Availability (V)

V1 is a Mechanical exercise: enumerate critical dependencies, restart or recreate, and record the interruption and recovery time. A restart is not V2. V2, V3, and V4 are Adversarial and failure-injected. Decision 4.6 says V is end-to-end and names the operation; the delivering service owns the declaration.

whitehat v-fixtures judges a supplied observation. It does not terminate an instance, remove a failure domain, or make a region unavailable. A pass means the observation record has the shape §13 requires. It does not mean a service recovered. A V2 claim that is only a restart, a claim with no failure injected, and traffic that did not continue or recover are findings. A claim that omits the operation, measured RTO/RPO, or the remaining shared failure domain stays inconclusive. V1 stays inconclusive here. A live exercise waits on WHITEHAT-WP-0012-T05 and needs the separate operator approval required by the rules of engagement §1.

R4

R4 remains Adversarial. The in-process calibration is whitehat r4-fixtures. No live R4 target is registered. A live exercise waits on WHITEHAT-WP-0012-T04. audit-core targets R2 and is not that owner.

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.