CIoTSP cheat sheet

Reference model layers: perception/device (sensors, actuators), network/transport (gateways, protocols), processing/edge, application, and business/management; each layer has distinct trust boundaries.

Purdue/ISA-95 levels for OT-IoT: L0 process, L1 controllers, L2 supervisory, L3 site operations, L3.5 DMZ, L4 enterprise, L5 cloud; conduits between levels are where security controls are enforced.

CIA plus IoT-specific properties: safety, availability-first for OT, privacy for consumer telemetry, and physical tamper resistance.

Constraint triangle: energy, compute/memory, and bandwidth. Security controls must fit the weakest node; asymmetric crypto and TLS handshakes are the usual cost drivers.

Edge vs fog vs cloud: edge = on or near device, fog = local network aggregation, cloud = centralized. Data residency and latency requirements drive placement.

Trust boundary rule: any transition between physical access, local network, gateway, and cloud is a boundary requiring authentication and integrity checks.

Common attack surface inventory: firmware, boot chain, debug interfaces (UART/JTAG), radio links, web/API endpoints, mobile apps, cloud APIs, and supply chain.

Defense in depth for IoT: secure boot, signed firmware, network segmentation, mutual authentication, least-privilege identity, monitoring, and recoverable update path.

Secure boot chain: immutable root of trust (ROM) verifies bootloader signature, bootloader verifies OS, OS verifies applications; a break anywhere invalidates downstream trust.

Debug and test interfaces (JTAG, SWD, UART consoles, test pads) must be disabled, fused off, or physically protected in production; they are the top hardware extraction path.

Firmware update must be signed, version-anti-rollback protected, encrypted in transit, and applied atomically with A/B partitions so a failed update can roll back.

Credential hygiene: no shared or default passwords, unique per-device secrets injected at manufacture, and secrets stored in TPM, secure element, or protected key storage.

Hardening baseline: disable unused services and ports, change defaults, enforce least privilege, enable logging, lock down bootloader, and remove debug symbols from production images.

Side-channel and fault-injection resistance: constant-time crypto, masking, voltage/clock monitoring, and tamper detection for devices in physically accessible locations.

Memory safety: use stack canaries, ASLR, NX, and bounds-checked languages where feasible; buffer overflows in C-based firmware remain a leading device compromise vector.

Device decommissioning: wipe keys and credentials, revoke certificates, and reset to factory state so retired hardware cannot rejoin the fleet.

Protocol-to-transport mapping: MQTT over TLS (8883), CoAP over DTLS (5684), HTTPS (443), AMQP over TLS (5671); plaintext ports 1883 and 5683 are for isolated test only.

MQTT security: TLS for transport, client certificates or token auth, per-topic ACLs, and disable anonymous access; broker is a high-value single point of compromise.

CoAP uses UDP and DTLS; DTLS 1.2/1.3 with PSK or certificates; block-wise transfer and observe need replay protection via timestamps or sequence numbers.

Zigbee, Z-Wave, BLE, and LoRaWAN have link-layer keys; network keys must be rotated and per-device keys preferred over shared network keys.

Network segmentation: IoT VLANs, microsegmentation, and egress filtering; IoT devices should not reach management planes or each other unless required by function.

Wireless risks: rogue APs, evil twin, deauth/jamming, and key sniffing during join; use join-time encryption, out-of-band pairing, and monitor for anomalous associations.

Industrial protocols (Modbus, DNP3, BACnet) lack native authentication and encryption; protect with compensating controls such as deep packet inspection, serialization gateways, and unidirectional gateways.

Zero trust for IoT: authenticate and authorize every flow, mTLS between devices and brokers, short-lived credentials, and deny-by-default network policy.

Identity options ranked by assurance: hardware-backed per-device certificate (TPM/secure element) > software certificate > derived key > shared key > password.

X.509 device certificates with mTLS are the default for scalable fleets; use a private PKI with an offline root and issuing intermediates per manufacturing site or product line.

Key lifecycle: generate in hardware where possible, distribute securely, rotate on schedule or on compromise, revoke via CRL or OCSP, and destroy at decommission.

Symmetric alternatives: unique pre-shared keys per device (DTLS-PSK, LoRaWAN AppKey) scale cheaply but complicate revocation and group operations.

Credential injection at manufacture must be auditable; a compromised factory or enrollment service compromises the whole fleet, so enrollment should be per-batch scoped.

Cloud IoT identity: device registry with per-device identity, X.509 or token auth, and policy bindings; use short-lived tokens and rotation for cloud API access.

Access control models: RBAC for human operators, ABAC/policy engines for device-to-service flows, and per-topic/per-resource ACLs for messaging.

Bootstrap trust: first-boot enrollment (EST, SCEP, cloud provisioning) must verify device attestation or a factory-issued secret before issuing operational credentials.

Data states: at rest (storage encryption, key separation), in transit (TLS/DTLS), and in use (minimize plaintext exposure, use secure enclaves where justified).

Classification drives controls: telemetry, PII/PHI, credentials, and firmware each need distinct retention, encryption, and access rules.

Privacy principles for IoT: data minimization, purpose limitation, consent where required, retention limits, and transparency; sensor data such as location and occupancy is often personal data.

Aggregation and de-identification reduce risk but are reversible when combined with auxiliary data; treat pseudonymized data as sensitive.

Integrity for telemetry: message signing or MACs, sequence numbers, and timestamps defend against replay and injection; validate ranges at the ingest layer.

Key separation: never reuse device authentication keys for data encryption; use envelope encryption with per-tenant or per-device data keys.

Regulatory touchpoints commonly cited: GDPR for EU personal data, HIPAA for health data in the US, and sector rules for utilities and automotive; map data flows before designing controls.

Deletion and retention: secure erase of storage media, revocation of access tokens, and documented retention schedules per data class.

Shared responsibility: cloud provider secures infrastructure; the customer secures device identity, data, IAM policy, and application code.

Cloud IoT core services use per-device registries, policy-based authorization, and broker ACLs; a misconfigured policy that allows wildcard publish is a common exposure.

Edge nodes extend the trust boundary: they must be hardened like devices, authenticated to the cloud, and able to operate offline with cached credentials and local policy.

API security: OAuth2/OIDC for users, scoped tokens, rate limiting, input validation, and no secrets in mobile apps or firmware images.

Serverless and container workloads need least-privilege roles, image scanning, and immutable deployments; secrets belong in a managed secret store, not environment files.

Edge analytics should filter and pre-process data to reduce cloud exposure and bandwidth; keep sensitive raw data local when residency rules require it.

Cloud logging and monitoring: enable audit trails, alert on anomalous device behavior, and centralize logs in an immutable store.

Multi-tenant isolation: separate credentials, keys, and data namespaces per tenant; test for cross-tenant access in policy reviews.

STRIDE categories map to IoT: spoofing (device identity), tampering (firmware/data), repudiation (logging gaps), information disclosure (telemetry), DoS (radio/battery), elevation (privilege escalation).

Threat modeling steps: define assets and trust boundaries, enumerate threats per boundary, rank by likelihood and impact, then select mitigations.

Risk scoring commonly uses CVSS for severity plus environmental context; a CVSS 9.8 on an isolated sensor may rank below a 6.5 on an internet-facing gateway.

Attack surface inventory: firmware SBOM, open ports, cloud endpoints, mobile apps, and third-party components; track versions to match CVEs.

Vulnerability management for constrained devices: firmware SBOM tracking, CVE monitoring, patch windows defined by criticality, and compensating controls when patching is impossible.

Supply chain risk: verify component provenance, review third-party SDKs, and require signed artifacts from suppliers.

Penetration testing scope for IoT includes hardware interfaces, radio protocols, firmware extraction, cloud APIs, and mobile apps, not just network services.

Risk acceptance must be documented with owner, rationale, expiry, and compensating controls; unpatched OT devices are typically handled this way.

IoT IR phases: preparation, detection and analysis, containment, eradication, recovery, and lessons learned; containment for a compromised device often means network isolation and credential revocation.

Key containment actions: revoke certificates and tokens, rotate keys, block device at network policy, isolate VLAN, and push a clean firmware image.

Detection sources: device logs, broker and gateway logs, network flow analysis, anomaly detection on telemetry, and cloud audit trails.

Baseline behavior is essential: normal publish rates, destinations, and timing; deviations such as sudden fan-out or beaconing indicate compromise.

Forensics on constrained devices is limited; preserve gateway, broker, and cloud logs, and capture firmware and memory images where hardware permits.

Governance artifacts: device security policy, acceptable use, patch SLAs, asset register, and supplier security requirements.

Metrics that matter: percentage of devices on current firmware, mean time to patch, number of devices with default credentials, and certificate expiry horizon.

Regulatory and contractual reporting: breach notification timelines and sector reporting duties should be pre-mapped so IR playbooks include notification steps.