diff --git a/INTENT.md b/INTENT.md index 62e4b83..7e4a069 100644 --- a/INTENT.md +++ b/INTENT.md @@ -2,11 +2,15 @@ ## Why this repo exists -`whitehat-security` is the estate's **adversarial evidence facility**. It -attacks the estate's own systems, on a schedule, to find out whether the -security properties they claim are actually true. +`whitehat-security` is **NetKingdom's offensive security facility**. It attacks +IT infrastructure and surfaces we choose to point it at — our own estate among +them — and reports what it finds to whoever is responsible for fixing it. -It exists because of a specific gap. NetKingdom's *Tenancy Posture* standard +The discipline is offensive because offence is how you find out. A control is +believed until someone tries it. Everything else in the estate's security work +describes what should be true; this repo establishes what is. + +It was seeded to close a specific gap, which remains its first job. NetKingdom's *Tenancy Posture* standard splits evidence into two kinds: **mechanical** — a structural assertion a machine can make, which belongs in each repo's own CI — and **adversarial** — a semantic claim that requires setting up hostile conditions and observing what @@ -19,27 +23,29 @@ Two repos were asked and both correctly declined, on the grounds that a service which grows fleet responsibilities because it happened to be nearby is how boundaries erode. They were right. The work needed a home of its own. -## Independence is the point +## Owner: NetKingdom -A repo testing its own boundary grades its own homework. +`whitehat-security` is a NetKingdom capability, alongside the IAM Profile, +SSO/MFA and the canonical security architecture. Offensive security is security +work, and it belongs with the repo that owns security. -`rapp-postgres` wrote fifteen adversarial probes against its own isolation -model and found four real defects in its own provisioning SQL. That is good -work and it is still the author checking their own homework — the probes most -worth having are the ones an author would not think to write, because the same -assumption that produced the defect produces the blind spot. +**Separation of concerns still applies, one level down.** A repo testing its own +boundary grades its own homework. `rapp-postgres` wrote fifteen adversarial +probes against its own isolation model and found four real defects in its own +provisioning SQL — good work, and still the author checking their own work. The +probes most worth having are the ones an author would not think to write, +because the assumption that produced the defect produces the blind spot. So: -So this repo is **independent by construction**: +- This facility does not take a repo's declared posture as true. It tests it. +- It does not decide how bad its own findings are. Severity and disclosure are + `risk-nexus`'s, which is `the-custodian`'s, not NetKingdom's. -- It does not take a repo's declared posture as true. It tests the claim. -- It is not owned by the repo whose canon it verifies. NetKingdom owns the - tenancy framework; a facility verifying conformance to that framework must - not report to it, or the self-grading problem simply moves up one level. -- It reports findings to `risk-nexus`, which owns severity and disclosure. It - does not decide how bad its own findings are, for the same reason. - -**Proposed owner: `the-custodian`**, consistent with `policy-nexus` and -`risk-nexus`, and deliberately not NetKingdom. To be confirmed. +**One residual tension, recorded rather than argued away.** NetKingdom owns the +Tenancy Posture framework *and* this facility. When whitehat tests conformance +to that framework, NetKingdom is assessing NetKingdom. The mitigation is the +routing above: findings leave for `risk-nexus` under separate ownership rather +than being resolved inside NetKingdom. That is proportionate, not perfect, and +worth revisiting if conformance findings ever start getting quietly closed. ## What it owns @@ -58,9 +64,16 @@ So this repo is **independent by construction**: - **Differential testing between tenant contexts.** Running the same request as two tenants and comparing responses is the mechanically reproducible core of cross-tenant testing, and it is this repo's principal technique. +- **Target selection and authorization.** Which infrastructure or surface the + facility is pointed at, and the authorization that permits it. See the + targeting rule below — this is the repo's most important control. - **Rules of engagement.** What may be probed, where, with what credentials, and what must never be done. An automated facility without this is indistinguishable from the threat it models. +- **Findings delivery to the responsible party.** For our own estate that is + `risk-nexus`, which routes to the owning repo. For any other target it is + whoever is responsible for that infrastructure, on the terms agreed in the + engagement. ## What it does not own @@ -77,6 +90,41 @@ So this repo is **independent by construction**: - **Blocking delivery.** In build mode a finding is information. If that changes it will be a recorded decision, not a habit that accretes. +## The targeting rule + +The facility can be pointed at infrastructure we do not own. That is the point +of it, and it is also the single thing that could turn this repo from an asset +into a liability, so the rule is structural rather than cultural. + +**No target is probed without recorded authorization from whoever is +responsible for it. No exceptions.** + +- **Our own estate, build mode** — standing authorization, within the declared + scope. This is the current situation. +- **Our own estate, production** — a separate recorded authorization. Build-mode + standing consent does not carry across; the blast radius is different and so + is the decision. +- **Anything we do not own** — written authorization from the responsible party, + per engagement, recorded in this repo *before a packet is sent*. Scope, + window, permitted techniques, and named contacts on both sides. + +Three things that do **not** constitute authorization, written down because +each is a way teams talk themselves into it: a commercial relationship with the +target; the target being publicly reachable; and a belief that the owner "would +obviously be fine with it". Unauthorized probing of someone else's +infrastructure is a criminal matter in most jurisdictions regardless of intent, +and a white-hat facility that gets this wrong is simply an attacker with better +paperwork. + +**The authorization record is part of the finding.** A report that cannot name +the authorization it ran under is not a finding — it is an incident, and it +gets treated as one. + +**Scope creep during an engagement is prohibited.** A probe that discovers an +adjacent system stops at the boundary and reports what it saw. Following the +interesting thing is exactly how an authorized test becomes an unauthorized +one. + ## Honest limits on "automated" The word in the repo's description is *automated*, and it must not be oversold @@ -123,9 +171,13 @@ whitehat-security → risk-nexus → policy-nexus disclosure) addressable) ``` -It reads posture claims and canon from the repos that own them, attacks the -running systems those claims describe, and hands what it finds to `risk-nexus`. -It publishes nothing directly and fixes nothing. +For our own estate it reads posture claims and canon from the repos that own +them, attacks the running systems those claims describe, and hands findings to +`risk-nexus`. For any other target, findings go to that infrastructure's +responsible party on the engagement's agreed terms; `risk-nexus` still records +that the engagement happened and what it means for us. + +It publishes nothing directly and fixes nothing, in either case. The first work is already specified and waiting: the E2 cross-tenant evidence artifact, which is Tenancy Posture's highest-severity unowned gap, and the diff --git a/README.md b/README.md index 4b421f4..f15ddb7 100644 --- a/README.md +++ b/README.md @@ -1,6 +1,8 @@ # whitehat-security -Automated white hat IT-security, pen-testing and isolation-probing. +NetKingdom's offensive security facility. Automated white hat IT-security, +pen-testing and isolation-probing — pointed at infrastructure we choose, +including our own. The estate's **adversarial evidence facility**: it attacks our own systems, on a schedule, to find out whether the security properties they claim are actually diff --git a/workplans/WHITEHAT-WP-0001-cross-tenant-evidence.md b/workplans/WHITEHAT-WP-0001-cross-tenant-evidence.md index 1054a30..7b391f0 100644 --- a/workplans/WHITEHAT-WP-0001-cross-tenant-evidence.md +++ b/workplans/WHITEHAT-WP-0001-cross-tenant-evidence.md @@ -5,7 +5,7 @@ title: "Produce the adversarial evidence the Tenancy Posture ladders require" domain: infotech repo: whitehat-security status: proposed -owner: the-custodian +owner: net-kingdom topic_slug: whitehat-security created: "2026-08-17" updated: "2026-08-17" @@ -42,9 +42,16 @@ An automated facility that probes systems without written scope is indistinguishable from the threat it models. This is the gating task and it is not paperwork. -- **Scope.** Which systems, which namespaces, which credentials. Explicitly: - build-mode environments now; production requires a separate, recorded - authorization. +- **Target authorization**, the control that matters most now the facility is + scoped to any surface we choose rather than only our own. No target without a + recorded authorization from its responsible party. Our estate in build mode + has standing authorization; production needs its own; anything we do not own + needs written per-engagement authorization recorded here before a packet is + sent. A commercial relationship, public reachability, and "they would + obviously be fine with it" are each explicitly not authorization. +- **Scope.** Which systems, which namespaces, which credentials — and a hard + stop at the engagement boundary. A probe that discovers an adjacent system + reports what it saw and does not follow it. - **Prohibited actions**, stated as hard rules rather than intentions: no destructive operations against data the estate did not create for the test; no exfiltration of real tenant data even as proof of a finding — @@ -179,8 +186,11 @@ findings route out, work does not come in. ## Open questions -1. **Owner confirmation.** Proposed `the-custodian`, deliberately not - NetKingdom, whose framework this verifies. Needs the operator's yes. +1. **Owner: NetKingdom** — settled 2026-08-17. Offensive security is security + work. The residual tension (NetKingdom owning both the Tenancy Posture + framework and the facility that tests conformance to it) is mitigated by + findings routing out to `risk-nexus` under separate ownership, and is + recorded in INTENT rather than argued away. 2. **Where probes run from.** In-cluster gives realistic network position; outside gives independence from the substrate under test. Probably both, eventually; pick one to start.