Approve rules of engagement and define attacker models
Assistant: codex Assistant-Model: gpt-5.6-sol Assistant-Session: 01a0260c-4067-7052-9647-ad000d576e38
This commit is contained in:
parent
30af1be843
commit
25a07d16f7
7 changed files with 298 additions and 26 deletions
|
|
@ -25,9 +25,10 @@ responsible party.
|
|||
|
||||
## Non-negotiable safety boundary
|
||||
|
||||
- The rules of engagement are pending personal operator approval. Until they
|
||||
are approved, perform only documentation work and non-networked fixture
|
||||
design. Send no packets to a target.
|
||||
- The rules of engagement are accepted, but that acceptance authorizes no live
|
||||
target. Without a complete, target-specific engagement record and every
|
||||
approval required by the rules of engagement §1, perform only documentation
|
||||
work and non-networked fixture design. Send no packets to a target.
|
||||
- Even after approval, no live run starts without a dated engagement record
|
||||
naming authorization, target owner, exact scope, window, technique,
|
||||
credentials, rate/concurrency ceiling, abort contact and finding destination.
|
||||
|
|
|
|||
|
|
@ -22,5 +22,6 @@ probes most worth having are the ones an author would not think to write.
|
|||
- Intent: [`INTENT.md`](INTENT.md)
|
||||
- Scope: [`SCOPE.md`](SCOPE.md)
|
||||
- Workplans: [`workplans/`](workplans/)
|
||||
- Rules of engagement (pending operator approval):
|
||||
- Attacker model: [`docs/attacker-model.md`](docs/attacker-model.md)
|
||||
- Rules of engagement (accepted; live targets still require engagement approval):
|
||||
[`docs/rules-of-engagement.md`](docs/rules-of-engagement.md)
|
||||
|
|
|
|||
15
SCOPE.md
15
SCOPE.md
|
|
@ -35,8 +35,9 @@ boundary always holds.
|
|||
|
||||
## Safety invariants
|
||||
|
||||
- Until the rules of engagement receive personal operator approval, only
|
||||
documentation and non-networked fixture design may proceed.
|
||||
- The rules of engagement are accepted, but their acceptance authorizes no live
|
||||
target. Without a complete approved engagement record, only documentation
|
||||
and non-networked fixture design may proceed.
|
||||
- No live target is authorized by this scope document.
|
||||
- Every live run names its authorization, target, owner, window, technique,
|
||||
credential lane, rate ceiling, abort contact and finding destination.
|
||||
|
|
@ -65,10 +66,12 @@ boundary always holds.
|
|||
|
||||
- Repository status: active.
|
||||
- Active plan: `WHITEHAT-WP-0001`.
|
||||
- `T01` is in progress: the rules of engagement are drafted and awaiting
|
||||
personal operator approval.
|
||||
- No live probe traffic is authorized yet.
|
||||
- `T02` through `T07` remain gated by `T01`.
|
||||
- `T01` is complete: the rules of engagement were accepted on 2026-08-21.
|
||||
- `T02` is complete: the per-axis attacker model is recorded in
|
||||
`docs/attacker-model.md`.
|
||||
- `T03` is ready to begin with offline harness and fixture design.
|
||||
- No live probe traffic is authorized; each target still requires its own
|
||||
engagement record and approvals.
|
||||
|
||||
## Relationships
|
||||
|
||||
|
|
|
|||
|
|
@ -9,9 +9,9 @@
|
|||
| Kind | ID | Status | Lane | Source |
|
||||
| --- | --- | --- | --- | --- |
|
||||
| workplan | WHITEHAT-WP-0001 | active | — | workplans/WHITEHAT-WP-0001-cross-tenant-evidence.md |
|
||||
| task | WHITEHAT-WP-0001-T01 | progress | — | workplans/WHITEHAT-WP-0001-cross-tenant-evidence.md |
|
||||
| task | WHITEHAT-WP-0001-T02 | wait | — | workplans/WHITEHAT-WP-0001-cross-tenant-evidence.md |
|
||||
| task | WHITEHAT-WP-0001-T03 | wait | — | workplans/WHITEHAT-WP-0001-cross-tenant-evidence.md |
|
||||
| task | WHITEHAT-WP-0001-T01 | done | — | workplans/WHITEHAT-WP-0001-cross-tenant-evidence.md |
|
||||
| task | WHITEHAT-WP-0001-T02 | done | — | workplans/WHITEHAT-WP-0001-cross-tenant-evidence.md |
|
||||
| task | WHITEHAT-WP-0001-T03 | todo | — | workplans/WHITEHAT-WP-0001-cross-tenant-evidence.md |
|
||||
| task | WHITEHAT-WP-0001-T04 | wait | — | workplans/WHITEHAT-WP-0001-cross-tenant-evidence.md |
|
||||
| task | WHITEHAT-WP-0001-T05 | wait | — | workplans/WHITEHAT-WP-0001-cross-tenant-evidence.md |
|
||||
| task | WHITEHAT-WP-0001-T06 | wait | — | workplans/WHITEHAT-WP-0001-cross-tenant-evidence.md |
|
||||
|
|
|
|||
256
docs/attacker-model.md
Normal file
256
docs/attacker-model.md
Normal file
|
|
@ -0,0 +1,256 @@
|
|||
# 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.
|
||||
|
|
@ -1,6 +1,6 @@
|
|||
# Rules of engagement for tenancy evidence
|
||||
|
||||
Status: **pending personal operator approval**
|
||||
Status: **accepted**
|
||||
|
||||
Version: 0.1
|
||||
|
||||
|
|
@ -139,7 +139,13 @@ known-good fixture in the same revision.
|
|||
|
||||
## 10. Approval
|
||||
|
||||
Personal operator approval is still required. Record approver, date and scope
|
||||
in this section or an immutable linked decision before changing the status to
|
||||
accepted. Until then, only documentation and non-networked test-fixture design
|
||||
may proceed; no target packets are authorized by this draft.
|
||||
Approved by: **repository operator**, by explicit approval in the coordinating
|
||||
session
|
||||
|
||||
Approval date: **2026-08-21**
|
||||
|
||||
Approved scope: these rules are accepted as the operating boundary for
|
||||
`whitehat-security`. This approval permits documentation and non-networked
|
||||
fixture work. It does **not** authorize a live target or a packet to any target.
|
||||
Every live run still requires the engagement record, target-owner
|
||||
acknowledgement and any technique-specific operator approval required by §1.
|
||||
|
|
|
|||
|
|
@ -80,7 +80,7 @@ As above. Gates everything.
|
|||
|
||||
```task
|
||||
id: WHITEHAT-WP-0001-T01
|
||||
status: progress
|
||||
status: done
|
||||
priority: high
|
||||
state_hub_task_id: "0d28fd14-1b82-4ac1-907b-02f43e8baae8"
|
||||
```
|
||||
|
|
@ -88,14 +88,15 @@ state_hub_task_id: "0d28fd14-1b82-4ac1-907b-02f43e8baae8"
|
|||
Drafted in `docs/rules-of-engagement.md` on 2026-08-18 with authorization
|
||||
classes, per-run records, initial target envelope, hard prohibitions,
|
||||
credential/attribution rules, rate defaults, abort/cleanup and evidence
|
||||
schema. It authorizes no live traffic until the operator personally approves
|
||||
§10. T01 remains progress and continues to gate every later task.
|
||||
schema. The operator accepted v0.1 on 2026-08-21 with the scope recorded in
|
||||
§10. The acceptance approves the operating rules and offline fixture work; it
|
||||
does not pre-authorize any live target.
|
||||
|
||||
### T02 — The attacker model per axis
|
||||
|
||||
```task
|
||||
id: WHITEHAT-WP-0001-T02
|
||||
status: wait
|
||||
status: done
|
||||
priority: high
|
||||
state_hub_task_id: "e0070ee6-6060-4a29-bd88-f664034db28e"
|
||||
```
|
||||
|
|
@ -112,15 +113,19 @@ distinguishes them:
|
|||
| P1/P2 | A co-resident consumer behaving badly within its own allowance | What degradation do neighbours experience? |
|
||||
| R | A copy of a backup taken before an erasure | Is the erased data still readable? |
|
||||
|
||||
**Output:** `docs/attacker-model.md`. Note that the E3 row exists because the
|
||||
framework corrected itself: E3 stops accident, not compromise, and a probe that
|
||||
only tested accident would report a strength E3 does not have.
|
||||
**Output:** `docs/attacker-model.md`, completed 2026-08-21. It separates
|
||||
credential-bearing tenant attacks, omitted-predicate accidents, SQL-capable
|
||||
compromise, structural credential confinement, bounded co-resident saturation,
|
||||
and both R4 erasure routes. It preserves the framework's correction that E3
|
||||
stops accident, not compromise: resetting the tenant GUC after SQL execution
|
||||
is recorded as E3's documented limit, not misreported as an E3 conformance
|
||||
failure.
|
||||
|
||||
### T03 — Differential cross-tenant harness (the E2 artifact)
|
||||
|
||||
```task
|
||||
id: WHITEHAT-WP-0001-T03
|
||||
status: wait
|
||||
status: todo
|
||||
priority: high
|
||||
state_hub_task_id: "742561f1-97b6-4fcc-8e06-d18508ddecae"
|
||||
```
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue