STRIDE Threat Model

This document is a formal threat-modelling artifact produced for Singapore CLS Level 3 assessment under SS 711:2025 Rigour in Defence and the IMDA IoT Cyber Security Guide threat-modelling checklist. It covers all attack surfaces of the EdgeSentry-RS system: API, communication channel, and storage.

Methodology: STRIDE (Microsoft) Scope: edgesentry-rs library and edgesentry-bridge FFI crate — device-side signing, cloud-side ingest, HTTP transport, operation log, and audit ledger. Assessor reference: SS 711:2025 §4.2 Rigour in Defence; IMDA IoT Cyber Security Guide §3 Threat Modelling Checklist

System Overview

┌─────────────────────────────────────────────────────────────────┐
│  Field Device (edge)                                            │
│  ┌────────────────────────────────────────────────────────────┐ │
│  │  build_signed_record()                                     │ │
│  │  payload → BLAKE3 hash → Ed25519 sign → AuditRecord       │ │
│  └────────────────────────────────────────────────────────────┘ │
└────────────────────────────┬────────────────────────────────────┘
                             │ POST /api/v1/ingest (JSON over HTTPS)
                             ▼
┌─────────────────────────────────────────────────────────────────┐
│  Cloud Ingest Layer                                             │
│  ┌────────────────┐  ┌─────────────────┐  ┌─────────────────┐  │
│  │ NetworkPolicy  │  │ IntegrityPolicy │  │ AsyncIngest     │  │
│  │ IP/CIDR gate   │→ │ Gate            │→ │ Service         │  │
│  │ (deny-default) │  │ (signature +    │  │ (hash chain +   │  │
│  └────────────────┘  │  chain verify)  │  │  sequence)      │  │
│                      └─────────────────┘  └────────┬────────┘  │
│                                                     │           │
│            ┌────────────────────────────────────────┤           │
│            ▼                          ▼             ▼           │
│  ┌──────────────────┐  ┌─────────────────────┐  ┌──────────┐   │
│  │  Raw Data Store  │  │  Audit Ledger       │  │ Op. Log  │   │
│  │  (S3 / memory)   │  │  (Postgres / memory)│  │          │   │
│  └──────────────────┘  └─────────────────────┘  └──────────┘   │
└─────────────────────────────────────────────────────────────────┘

STRIDE Threat Analysis

S — Spoofing (Device Identity)

Threat: An attacker impersonates a legitimate field device by forging the device_id field or replaying records signed by a compromised key.

Attack surface: POST /api/v1/ingest — AuditRecord.device_id and AuditRecord.signature fields.

Mitigations:

Residual risk: If a device’s private key is physically extracted, records can be forged with valid signatures. Hardware-backed key storage (TPM/SE) is a device-layer control outside the scope of this library; it is noted in the Roadmap.

T — Tampering (Audit Records)

Threat: An attacker modifies an audit record or its raw payload in transit or at rest.

Attack surface: Wire format (JSON body), raw data store (S3 objects), audit ledger (database rows).

Mitigations:

Residual risk: Tampering of stored objects after acceptance is a storage-layer concern. Enabling S3 Object Lock (WORM) or database row-level checksums at the deployment layer eliminates this residual.

R — Repudiation (Operation Logs)

Threat: A device or operator denies that a specific ingest event occurred, or claims a record was never sent / was rejected without evidence.

Attack surface: OperationLog entries written during ingest; audit ledger append operations.

Mitigations:

Residual risk: The library provides the operation log data; protecting that data from privileged insider deletion requires database-level controls (role separation, audit logging at the DB layer).

I — Information Disclosure (Payload Storage)

Threat: Sensitive inspection payload data is exposed to an unauthorised party.

Attack surface: HTTP request body (raw_payload_hex), raw data store (S3), audit ledger, operation log.

Mitigations:

Residual risk: Encryption at rest for S3 objects and Postgres rows is a deployment-layer control (S3 SSE-KMS, Postgres pgcrypto or TDE). TLS 1.3 for the ingest HTTP endpoint is addressed in the Roadmap (issue #73).

D — Denial of Service (Network Policy)

Threat: An attacker floods the ingest endpoint to exhaust resources and prevent legitimate devices from submitting records.

Attack surface: POST /api/v1/ingest HTTP endpoint; NetworkPolicy check; AsyncIngestService tokio task pool.

Mitigations:

Residual risk: Rate limiting per source IP and per device is not yet implemented in the library layer; it should be added at the reverse proxy or API gateway layer in production deployments. Issue #73 (TLS, P2) is the planned follow-up milestone.

E — Elevation of Privilege (Ingest Gate)

Threat: An attacker bypasses the ingest validation gate to write arbitrary records to the ledger or raw data store.

Attack surface: IntegrityPolicyGate, ingest_handler, and the service registration API (register_device).

Mitigations:

Residual risk: If the application layer that calls register_device is compromised, arbitrary devices can be registered. This is an operational security control: registration should be gated behind a separate privileged API with strong authentication.

Binary Analysis Evidence

cargo audit — Advisory Database Scan

Command and output captured at document generation time (advisory database commit: current):

cargo audit

Result: All detected advisories are pre-approved in deny.toml (see table below):

All remaining scanned crate dependencies: no known CVEs.

To reproduce:

cargo install cargo-audit --locked
cargo audit

cargo deny check — Policy Enforcement

Command:

cargo deny check

Result: advisories ok, bans ok, licenses ok, sources ok

The deny.toml policy enforces:

• Advisories: all vulnerabilities denied by default except explicitly ignored entries with documented reasons
• Bans: multiple crate versions warned; wildcard dependencies warned
• Licenses: only MIT, Apache-2.0, BSD-2-Clause, BSD-3-Clause, Unicode-3.0, CC0-1.0, Zlib permitted; one exception: cbindgen (MPL-2.0, build-only header generator — copyleft does not extend to generated artifacts or source)
• Sources: only crates.io and trusted git sources

To reproduce:

cargo install cargo-deny --locked
cargo deny check

Threat-to-Mitigation Traceability Summary

Legend: ✅ Implemented in library code — ⚠️ Deployment-layer control (outside library scope)