Threat model

A real threat model, not a marketing sheet. We list each adversary class, what they can do, what we do about it, and where we deliberately do not harden.

Adversaries

A — Curious internet

Random scanners and bots that scrape every exposed HTTPS endpoint looking for misconfigurations.

Capabilities: send arbitrary HTTP to our edge. No insider access, no targeted persistence.

What we do:

• TLS 1.3 only; SSL Labs A+.
• All routes require either a session cookie or a bearer token; no unauthenticated GET to api.opensense.murzin.digital/v1/*.
• Aggressive rate limit on /auth/* (per-IP, 10 req / min).
• The dashboard does not leak account-existence (auth/request always returns 200).
• All errors carry no stack traces; the body is the structured error envelope.

What we do not do: bot-blocking by JA3 fingerprint or Cloudflare- style challenge pages. Caddy is in front of the API; we accept the extra load from idle bot traffic.

B — Ex-employee of a customer

Someone who once had access to a customer account, now no longer should.

Capabilities: still knows the magic-link email; may know an old session cookie; may have copies of past PDFs.

What we do:

• Magic-link tokens expire after 10 min and are single-use.
• Session cookies can be revoked centrally (Account → Sessions → Sign out everywhere).
• API tokens can be rotated; old tokens fail immediately.
• Account holder can change the login email.
• Audit log shows every login and is exportable.

What we do not do: SAML SSO with org-level provisioning. The operator is responsible for changing the login email when staff turn over. We will add this at the Team tier.

C — Compromised device on customer LAN

A device on the customer's LAN that has been firmware-tampered or replaced.

Capabilities: can send arbitrary payloads to the ingest URL with the captured device token; can fabricate readings.

What we do:

• The token is per device. A leaked token for fridge01 cannot ingest as fridge02 — the device id is bound to the token server-side.
• Sanity-range checks reject implausible values at ingest. A compromised device cannot inject "+9999 °C" successfully.
• Audit log records every measurement; a customer reviewing past history can spot a step-discontinuity that doesn't match the physical world.
• The customer can rotate the token any time; on rotation, the old token is immediately invalid.

What we cannot do: tell a fabricated-but-plausible reading apart from a real one. If the attacker reports +4.3 °C for a freezer set to −18 °C, the reading is rejected as out-of-range. If the attacker reports −18.3 °C when the real freezer is at +9 °C, OpenSense believes the attacker. That is a physical-security problem, not a software one.

For high-stakes cases (pharmaceutical cold chain), the regulated practice is independent calibration probes plus physical seals on the sensor enclosure. We support that workflow; we do not hardware-attest sensors ourselves.

D — Network attacker on the device-to-edge path

Someone in the path between the sensor and our edge.

Capabilities: passive observation, active modification of unencrypted traffic.

What we do:

• Refuse non-TLS connections on the API entirely (Caddy redirects 80 to 443 then HSTS).
• MQTT bridge is mTLS-only.
• LoRaWAN uplinks are AES-128 encrypted on the radio layer (LoRaWAN 1.0.3+).

What we cannot do: protect Shelly Gen1 over plain HTTP on a hostile LAN. Gen1 firmware does not do HTTPS. We accept Gen1 traffic from the LAN to our edge over HTTPS — the gen1 is on a LAN, our edge is on the internet; if your AP is hostile, you have bigger problems.

E — Network attacker between our edge and the database

"Insider on Hetzner network" or similar.

Capabilities: passive observation of bytes between our nodes.

What we do:

• All inter-process communication is on 127.0.0.1 of the same Hetzner VPS. There is no cross-host service mesh.
• LUKS at rest on the data volume.

What we cannot do: defend against a Hetzner staff member with physical KVM access if the machine is powered on. The LUKS key is loaded at boot; if an adversary gets KVM with the machine running, the key is in RAM. This is a residual single-VPS risk; the customer base accepts it.

F — Our own engineer making a mistake

The biggest realistic threat for any small-team SaaS.

Capabilities: production access via SSH; can deploy anything.

What we do:

• All deploys via a tagged release. Rollback is a one-command revert.
• Postgres is backed up hourly to a separate volume and weekly to a separate storage box.
• Schema migrations are tested in a dev environment before being applied to production.
• Audit log is hash-chained — even with prod DB access, silent history rewrites invalidate the daily-published head.

What we cannot do: prevent every footgun from a sleep-deprived solo founder. We minimise blast radius (small, focused services, immutable measurement storage), but a "DROP TABLE measurements" by typo is recoverable only from backup, with a measurement gap.

G — Legal / Govt order

EU jurisdiction, lawful order to disclose customer data.

Capabilities: a court order delivered to Murzin Digital s.r.o.

What we do:

• We are an EU entity in Slovakia. We will comply with valid EU jurisdiction orders. We will not voluntarily disclose to non-EU authorities.
• We disclose only what the order requires; we push back on overly broad orders via counsel.
• We will notify the affected customer unless the order forbids notification.

What we do not do: claim "we cannot decrypt your data" — that is not true. Customer data is at-rest encrypted at the disk layer but the application has plaintext access by design (we need it to render charts and PDFs).

Out of scope

We are explicit about the threats we do not address:

• Side-channel attacks on the sensor (laser-microphone, RF emanations). Not a small-business risk model.
• Long-haul cryptographic resistance. We do not signed-store measurements with a quantum-safe scheme. Audit hashes are SHA-256; if SHA-256 falls, the audit chain is rebuilt under a stronger primitive at that time.
• Customer-side device firmware integrity. We do not run a firmware-signing program for Shelly / Aqara devices; the vendors do.