The ACSE Control Plane — Operating Surface Mutation at Estate Scale

Abstract

The Polymorphic Mutation Engine (PME) enforces the Kali Invariant on a single node; ASMP/1.0 coordinates that enforcement across an estate. Neither, on its own, is something an enterprise can operate. The ACSE Control Plane is the fourth architectural layer — the management surface through which operators discover assets, onboard them into the catalog, monitor live state, set policy, integrate with existing security infrastructure, and produce a tamper-evident record of every action.

This paper covers Control Plane v0.4.0. It specifies live authentication (API-key + RBAC) and the MSG-005 node-grant design (modelled in ProVerif; gating one protected action today, not yet integrated into authentication), the live estate dashboard, the Auto-Discovery pipeline (22 source types), the zero-config agent self-registration mechanism, the push protocol, outbound firewall and SIEM integration, the policy engine and estate REST API, and the cryptographic audit chain — followed by deployment, operations, and the v2 roadmap.

1. From Engine to Operable System

A mutation engine that no one can deploy, monitor, or audit is a research artifact, not a product. The journey from PME to a fielded defence runs through a set of unglamorous but decisive operational requirements: how do you discover the hundreds of assets that need protecting? How do you watch their state in real time? How do you change policy across an estate without touching every node by hand? How do you feed events into the SOC's existing SIEM? And how do you prove, later, exactly what happened and who authorised it?

The Control Plane answers each of these. Crucially, it does so without weakening the security model of the layers beneath it. A management plane is the highest-value target in any system — compromise it and you inherit the estate. The Stryker–Handala wiper attack of March 2026 is the canonical example: the attackers did not break encryption, they weaponised the victim's own MDM management console to issue estate-wide wipe commands.

2. Control Plane Architecture

The Control Plane sits atop the three runtime layers — PME, ASMP/1.0, and the profile layer (ten bio-inspired domain profiles plus TorpedoRay) — as the operator-facing management layer. It is a single Rust binary (acse-cp) backed by PostgreSQL, exposing a REST API on port 9000 and the pme-console live dashboard, with four families of connectors: inbound discovery, inbound agent push, outbound firewall orchestration, and outbound SIEM dispatch.

3. Authentication & RBAC (MSG-005 — Specified, Not Yet Live)

Authentication in the Control Plane today is single-factor at the transport layer: an operation requires an authenticated identity (API-key) with sufficient role (RBAC). ASMP message MSG-005 specifies a stronger, two-factor design — identity-plus-role and a fresh hardware attestation, binding a management trust token to a Trusted Execution Environment quote with a time-to-live of exactly one mutation cycle. MSG-005's node-grant property is proven in ProVerif (see WP-07; no TEE is modelled), but it is not currently wired into any live API authentication path — production authentication is API-key + RBAC only, and MSG-005 is planned for a future release.

3.1 Role-Based Access Control

• Admin — full estate authority: policy changes, node registration, profile assignment, connector configuration, user management.
• Operator — day-to-day operations: trigger defensive leaps, acknowledge anomalies, run discovery, configure SIEM and firewall adapters, read all state.
• ReadOnly — observation only: dashboard, audit chain, and reports, with no mutating operations.

3.2 The Six TEE/TPM Adapters

Of these, only TpmAdapter has been run against real hardware and produces a verified audit-signing key today (KeyCustody::Tpm). SGX, Nitro, and SEV-SNP have real, unit-tested implementations but have not been validated against physical hardware of their respective kind — that is a funded-hardware-access gap, not further engineering. ARM CCA is a harder limit: no commercially purchasable ARM CCA hardware exists to test against at all, so the adapter is retained for interface completeness (see Patent Claim 2's detection-order enumeration) but cannot be verified on anything. Selecting an adapter is a one-line change at construction; all Control Plane logic is adapter-agnostic.

4. The Estate Dashboard

The pme-console dashboard presents a live organ-state view across every registered node, refreshing every five seconds. It is the operator's primary situational-awareness surface, and the same data is available programmatically through the REST API (GET /v1/estates).

Asset rows are auto-classified — firewall, server, or network device — so an operator can tell at a glance which surfaces are under which profile, and which discovered nodes are still awaiting onboarding.

5. Auto-Discovery — 22 Source Types

Most deployments stall at inventory: nobody has a complete, current list of the assets that need protecting. Auto-Discovery removes that obstacle by enumerating the estate from the identity and network systems an organisation already runs — then cataloguing, classifying, and suggesting the appropriate mutation profile for each asset.

v0.2.2 ships with 22 source types across six categories, up from 6 in v0.1.0. The expansion covers HCI management planes (Nutanix, Cisco UCS, VMware vCenter, Azure Stack HCI) and storage fabric controllers (Pure Storage, NetApp ONTAP, Dell EMC, Brocade FC, Cisco MDS, Ceph) — surfaces that carry catastrophic blast radii and have historically been protected by static, never-rotated credentials.

6. Estate Catalog — Discover → Decide → Protect

Every node discovered by any source lands in the discovered_nodes catalog table. The catalog is the intermediate state between "found" and "protected." The admin reviews, approves, and clicks Protect — the Control Plane creates an estate and api_key automatically.

The POST /v1/discovery/catalog/:id/protect endpoint returns the estate record, api_key, and platform-specific install instructions in a single response — the operator copies the key to the node, installs the agent, and that node is under the Kali Invariant within minutes.

7. Estate Lifecycle

An estate is the Control Plane's representation of a protected node. It is the join point between the PME agent (which executes mutations) and the Control Plane (which aggregates, dispatches, and monitors).

1. Registration: POST /v1/estates (manual) or via catalog Protect (auto). Returns a per-estate api_key — shown once, SHA3-256 hash stored only.
2. Agent push: The PME agent calls POST /v1/estates/:id/push every 30 seconds with mutation count, EWMA score, organ state, and audit records.
3. SIEM dispatch: On every push, the bridge module dispatches CEF-formatted events to all configured SIEM sinks.
4. Firewall sync: When a TorpedoRay surface mutates, the CP pushes the new channel fingerprint to connected firewall adapters automatically.
5. Audit chain: Every mutation record is appended to the estate's SHA3 audit chain in PostgreSQL. Each record contains the SHA3-256 hash of its predecessor — the chain is tamper-evident.
6. Kali Invariant: The CP continuously checks that every active estate is in a valid mutation state. A violation (estate offline, chain gap) flags the global invariant.

8. Agent Self-Registration — New in v0.3.0

Self-registration is the zero-config deployment model introduced in v0.2.1. It eliminates the manual register-then-install workflow for large fleets: set a pre-shared registration token on the CP and on each agent. On first boot, the agent registers itself and receives its api_key.

The self-register endpoint is the only /v1/ path that is public (not behind the Bearer auth middleware). It is disabled by default — only enabled when ACSE_REGISTRATION_TOKEN is set on the CP. This makes it opt-in and auditable.

9. Agent Push Protocol

The PME Agent pushes its status to the Control Plane every ACSE_PUSH_INTERVAL_S seconds (default: 30). The push is a single authenticated POST with the estate's api_key as a Bearer token.

POST /v1/estates/:id/push
Authorization: Bearer acse_XXXXXXXXXXXXXXXXXXXX
Content-Type: application/json

{
  "organ_state":    "sachs",
  "ewma_score":     0.08,
  "torpedo_count":  0,
  "mutation_count": 2880,
  "transport_mode": "asmp",
  "audit_records": [
    {
      "cycle_seq":           2880,
      "surface_fingerprint": "sha3hex...",
      "record_hash":         "sha3hex...",
      "tee_signature":       "base64...",
      "trigger_reason":      "timer",
      "mutation_result":     "success"
    }
  ]
}

On receiving a push, the CP: (1) updates estate_live_status in PostgreSQL, (2) appends audit records to the SHA3 chain, (3) dispatches CEF events to all enabled SIEM sinks, (4) checks the Kali Invariant. Response: {"status":"ok"}.

10. Firewall & SIEM Integration

10.1 Firewall Orchestration

When a protected surface mutates, the perimeter must follow — otherwise a firewall rule references an identity that has changed. The Control Plane can push the updated surface identity to a connected firewall through an operator-triggered sync (POST /v1/firewalls/:id/sync); what it pushes is a fingerprint tag, and automatic per-mutation firewall sync is pilot work, not yet wired to each cycle.

10.2 SIEM Dispatch

Every mutation event and every Torpedo firing is dispatched to the SOC's SIEM, enriched with node, profile, organ state, and audit-chain references so analysts have full context without leaving their console.

11. Policy Management & the Estate REST API

Policy is defined per estate and applied across nodes in a single call: mutation schedules, EWMA thresholds that govern organ-state transitions, and the active profile for each class of asset. The REST API is the substrate for everything — the dashboard, automation, and third-party integrations all speak to it, and every privileged route carries the API-key + RBAC gate described in Section 3 (MSG-005 is specified and modelled in ProVerif, not yet integrated into this gate).

# Assign a profile across an estate (Admin role required; TEE token not yet enforced — see §3)
POST /v1/estates/{estate_id}/policies/{policy_id}

# Create a policy
POST /v1/policies
{
  "name":              "production-default",
  "schedule_secs":     30,
  "ewma_threshold":    0.70,
  "hunter_threshold":  0.35,
  "active_profiles":   [11]
}

# Trigger an estate-wide defensive leap (Operator role)
POST /v1/invariant/leap

# Read live estate state (any role)
GET  /v1/estates/{estate_id}

# Browse discovery catalog
GET  /v1/discovery/catalog?status=discovered&node_type=windows_server

# Protect a discovered node
POST /v1/discovery/catalog/{id}/protect

Policy changes are themselves audited — a policy change is a privileged operation and appears in the audit chain alongside the operations it governs.

12. The Cryptographic Audit Chain

The audit chain is the Control Plane's answer to "what happened, and who authorised it?" Every mutation event and every management operation from every node is aggregated into an append-only log, persisted in PostgreSQL, with each entry cryptographically linked to its predecessor by a SHA3-256 hash — the same chaining property as ASMP MSG-001. Removing or altering any entry breaks every subsequent hash, making tampering detectable rather than merely discouraged.

The chain is exposed through a paginated REST API designed for compliance review, incident forensics, and regulatory reporting — the evidentiary spine for SEC, NIS2, DPDP, CERT-In, and HIPAA obligations.

Where a TPM 2.0 is present, the chain is signed by a non-extractable key held inside the TPM, and a TPM2_Certify assertion binds that signing key to the TPM. Entries do not each carry a hardware platform quote; there is no PCR / boot-state attestation and no manufacturer endorsement-key chain, and the Control Plane does not yet verify the assertion (#143, #146). So the chain is verifiable for integrity (the SHA3 chain) and is signed by a TPM-held key where one is present — not accompanied by a per-record hardware quote.

13. Deployment & Operations

The Control Plane ships as a single binary with platform-native installers, so it drops into existing enterprise estates without bespoke packaging.

Operationally, the Control Plane is designed to sit alongside an existing stack — firewalls, EDR, SIEM, Zero Trust — rather than replace any of it. It makes those tools more effective by ensuring the surfaces they protect are no longer static.

14. Roadmap — Control Plane v2

v0.2.2 establishes the full operable core including Auto-Discovery, self-registration, and the HCI/Storage Wave 2 connectors. v2 extends toward multi-tenant operation, richer analytics, and executive-grade reporting. The flagship v2 deliverable is the Reporting Module — ACL-scoped historical reports covering EWMA spikes, attack/defence timeline, and audit-log extracts formatted for CISO-level review and compliance submission.

15. Patent Claims Coverage

The Control Plane contributes directly to multiple claims in Patent IN202641070690:

• ACSE Control Plane (ACSE-CP): The Control Plane itself is claimed as a core component of the system described in the application — the management layer that makes the PME estate operable.
• Estate management and profile assignment: The mechanism by which profiles are assigned to estates and the Kali Invariant is enforced estate-wide.
• ASMP/1.0 MSG-005 — Management Binding: The TEE-attested two-gate authentication design discussed in the Stryker MDM weaponisation case (WP-06/CS-01): admin credential (necessary) + TEE-attested token (sufficient). ProVerif confirms CORRECT under Dolev-Yao as a protocol design. MSG-005 is not yet integrated into the live Control Plane authentication path — production auth today is API-key + RBAC.
• Tamper-evident audit chain: The SHA3-256-chained audit chain stored in PostgreSQL, signed by a key that can be held non-extractably in a TPM where one is present, is the tamper-evident forensic record described in the application. Whether it is admissible as evidence in a given regime is for that regime to determine; no legal-admissibility claim is made here.
• Auto-Discovery with profile suggestion: The 22-source discovery engine and automated profile assignment are novel contributions. No prior art exists for cryptographic surface mutation profile assignment from enterprise discovery data.
• Agent self-registration protocol: The zero-config deployment mechanism using a pre-shared registration token to bootstrap a TEE-bound estate key is a novel architectural contribution to the estate management domain.

16. Conclusion

The Control Plane completes the ACSE stack. The four-layer architecture — Control Plane, PME, ASMP/1.0, and the profile layer (ten bio-inspired domain profiles plus TorpedoRay) — is now operable end to end: an estate can be discovered (22 source types), catalogued, onboarded (manually or zero-config), monitored, governed by policy, integrated with existing security infrastructure, and audited, all under a management plane gated today by API-key + RBAC.

The same invariant that protects the data plane already protects reconnaissance of the management plane's data surfaces: the map an attacker builds expires before they can act on it. The stronger management-plane gate — a TEE attestation quote as a second, hardware-rooted factor on every privileged operation — is specified (MSG-005; its node-grant property is proven in ProVerif, the hardware binding is not modelled) but not yet wired into the live path; it is planned for a future release.