Risk Management on Deevnet IoTaaS

Vulnerability Management

Mon, 01 Jan 0001 00:00:00 +0000

Vulnerability Management #

How Deevnet learns about vulnerabilities in what it runs, checks its own code before it reaches a site, and decides when a patch goes in. Parts of this are practice today; parts are planned, and are marked so.

Knowing what is running #

Vulnerability management starts with an inventory, and Deevnet’s is the code: every host, OS image, container image and firmware version is declared in inventory or in an image factory, pinned by version or tag. “Are we affected?” is answered by searching the repositories, not by surveying hosts.

Security Controls

Mon, 01 Jan 0001 00:00:00 +0000

Security Controls #

The controls that bound what a mistake or a compromise can reach. Each is summarized here with the record that decided or built it; the design itself lives in those records.

Network segmentation #

The site network is split into zones by trust — management, trusted, platform, storage, tenant transit, IoT, IoT vendor and guest ( Network Segmentation).

Default deny between zones. The core router allows only the inter-zone flows that are declared in inventory, and removes anything it did not declare ( CHG-0007)
Joining a network is not authorization. A device on the IoT network still needs a credential for every service it uses ( ADR-0020)
Guest is internet-only; IoT reaches the broker and the internet, not tenant workloads or management

Tenant isolation #

A routing domain per tenant. Tenants are separated by VRF, not by a firewall rule — there is no route between them to filter ( ADR-0001)
Every tenant-facing service is partitioned by the platform, not by the tenant. DNS updates are bound to the tenant’s own zone by server-side key metadata; MQTT topics are prefixed by the API; log partitions are selected by the proxy from routes the API wrote. A tenant cannot claim another tenant’s identity in a payload
Tenants hold no substrate credential — one API token, nothing else ( ADR-0015)

Encryption #

	In transit	At rest
The Deevnet API	TLS, site CA	registry secrets in OpenBao
MQTT broker	TLS only; no plaintext listener	—
Log store	TLS through an authenticating proxy	on the observability VM’s disk
Substrate secrets	—	ansible-vault in the inventory; OpenBao for runtime secrets ( ADR-0016)
Build secrets (the Proxmox token for Packer and the fabric)	TLS to OpenBao	OpenBao’s runtime copy; the inventory vault is authoritative. Never on disk on the Builder
Terraform state store	plain HTTP today — see the register	on one disk
Wi-Fi	WPA2 with a per-tenant key (PPSK) on the IoT SSID	—

The site runs its own certificate authority; clients trust site-ca.pem rather than a public CA, because nothing Deevnet serves is public.

Traceability

Mon, 01 Jan 0001 00:00:00 +0000

Traceability #

Every configuration choice in Deevnet should be explainable from records: why it was decided, what was changed to make it so, and what happened when it went wrong. Traceability is a risk control — the risk it treats is a future operator (often the same person, months later) undoing a deliberate choice because nothing said it was deliberate.

The chain #

graph LR
 A[ADR
why] --> B[Change record
what, and how to undo it] --> C[Pull requests
the code]
 B --> D[Incident record
what it cost, if it failed]
 D --> A

Record	Answers	Numbered	Lives in
ADR	why this design, what else was considered, what it costs	`ADR-NNNN`	Decisions
Change record	what was changed, the end state, the procedure, the undo, what actually happened	`CHG-NNNN`, by year	Change Records
Incident record	what broke, how it was found, why, what prevents a repeat	`INC-NNNN`, by year	Incident Records
Pull request	the exact code, reviewed and merged	per repository	GitHub

The rules #

Every significant change has a record, opened before the change, closed with the outcome — including what was not tested ( Change Management)
Every incident has a record, even when the change that caused it already has one ( Incident Management)
Records link both ways. A change names the ADR it implements and the PRs that carry it; an incident names the change that caused it and the changes that fix it
Index pages are updated in the same commit as the record whose state changed, so the list and the record never disagree
Numbers are never reused, and a superseded ADR stays, marked superseded, so the reasoning that led to today is still readable
Standards and ADRs win over code. If a repository conflicts with them, the repository is the defect

Using it #

“Why does the router drop this?” → the rule is in inventory → its commit → the PR → the change record → the ADR. If any link is missing, that is worth a follow-up, because the next person asking will not have the context you have now.

Resiliency & Limits

Mon, 01 Jan 0001 00:00:00 +0000

Resiliency & Limits #

This page is the resiliency half of Risk Management: the risks Deevnet accepts by running on the hardware it does, stated so the acceptance is deliberate. The larger ones are also tracked in the risk register.

The architecture describes the platform as designed. This page describes what the hardware underneath it cannot do.

Both are true at once, and the second is the easier one to forget, because the first reads like a datacenter: tenants, fabrics, authority boundaries, everything reproducible from code. The design philosophy already notes that Deevnet operates at a smaller scale than the platforms it borrows from — but scale is not the interesting constraint. Resilience is. Deevnet runs on consumer hardware with no redundancy anywhere in the critical path, and its recovery model is rebuild, not failover.

Risk Register

Mon, 01 Jan 0001 00:00:00 +0000

Risk Register #

The known risks, how likely and how bad each is, how it is being treated, and the record that owns it. An entry is added when a risk is identified — in an ADR, a change or an incident — and reviewed when a related record changes state.

Likelihood and impact are low / medium / high. Treatment is one of reduce (something is being done), accept (deliberately lived with), avoid (the design routes around it) or transfer.