Die Beispieldokumente und Projektpläne sind bewusst nur auf Englisch veröffentlicht: Sie sind Vorlagen zum Übernehmen, und eine Übersetzung wäre nicht die Fassung, mit der Sie am Ende arbeiten.
Fiktives Beispiel. Die ACME Embedded GmbH, ihre Produkte, Nachweise und Dokument-IDs sind zur Veranschaulichung erfunden. Nutzen Sie das als strukturelles Vorbild, nicht als unverändert zu übernehmende Vorlage — und nicht als Rechtsberatung.
SEC-RA-S300 — Product Cybersecurity Risk Assessment (Pre-Development Version)
| Document ID | SEC-RA-S300, version 0.1 (pre-development baseline) |
| Product | SensorNode S300 (project P-2026-04) |
| Reference | CRA Annex I I(1); method per SDL-TMP-010; input to threat model SEC-TM-S300 |
| Prepared by | Product Security Lead, 2026-07-10 |
| Reviewed by | Team Lead Firmware, QA Engineer |
| Versioning rule | All versions are retained in the QM repository. This v0.1 is a fixed part of the technical documentation (Annex VII) and must never be overwritten — updates create v0.2, v1.0 (release), etc. |
1. Method
Risk = Likelihood (1–4) × Impact (1–4), assessed against the Annex I Part I security properties. Scales and acceptance thresholds per SDL-TMP-010: risk ≥ 9 requires a design measure; 4–8 requires a documented decision; ≤ 3 acceptable. Assessment performed in a 2-hour workshop (PSL, firmware lead, QA, product manager) before any architecture decisions were frozen — that is the point: results below may still change the hardware selection and system design.
2. Security context and assumptions
- Deployment: industrial halls; network = private 802.15.4 mesh to ACME Gateway G50; no direct internet exposure of the S300.
- Physical access: devices mounted on machinery, reachable by on-site personnel; theft of a unit is plausible.
- Data processed: vibration/temperature telemetry (low confidentiality), device credentials and network keys (high confidentiality), measurement history buffered locally up to 72 h.
- Foreseeable misuse: re-pairing a stolen node to an attacker's gateway; use of the radio as an entry point into the mesh.
3. Risk register (pre-development)
| ID | Threat scenario | L | I | Risk | Decision / derived requirement |
|---|---|---|---|---|---|
| R-01 | Network key extracted from stolen node's flash → mesh compromise | 3 | 4 | 12 | Data-at-rest encryption + key storage in secure element or MCU key vault → feeds ENG-REC-032 (hardware feasibility) |
| R-02 | Malicious firmware installed via update channel | 2 | 4 | 8 | Signed updates with rollback protection (secure boot chain); requirement SR-S300-04 |
| R-03 | Unauthenticated node joins the mesh / node impersonation | 3 | 3 | 9 | Per-device identity, authenticated join procedure; requirement SR-S300-05 |
| R-04 | Debug interface (SWD/UART) used to dump firmware and secrets | 3 | 3 | 9 | Production fuse lock, no shell on UART → checklist SDL-CHK-030 items A3/A4 |
| R-05 | Telemetry manipulation → wrong maintenance decisions at customer | 2 | 3 | 6 | Integrity protection on radio link (AEAD); documented decision D-2026-11 |
| R-06 | DoS by radio jamming | 3 | 2 | 6 | Out of product scope (physical layer); detection + "stale data" flag at gateway; documented decision D-2026-12 |
| R-07 | Vulnerable third-party stack (radio/crypto lib) during 7-year support period | 3 | 3 | 9 | Component policy SDL-POL-005 + EOL check ENG-REC-031 mandatory before component selection |
| R-08 | Local measurement buffer read from stolen device | 2 | 2 | 4 | Covered by R-01 measure (encrypted storage); no extra measure |
4. Conclusions for pre-development
- Hardware selection is constrained by R-01: candidate MCUs without usable at-rest encryption/key storage are excluded (see ENG-REC-032).
- Four security requirements (SR-S300-01…05) enter the Security Requirements Sheet as mandatory before architecture freeze.
- R-07 makes the component policy and EOL screening a blocking pre-development task, not a later hygiene item.
- Support period target for S300: 7 years — all component decisions must hold against that horizon.
5. Version history
| Version | Date | Stage | Note |
|---|---|---|---|
| 0.1 | 2026-07-10 | Pre-development baseline | Retained unchanged as part of technical documentation |
| 0.2 (planned) | after architecture freeze | Update with concrete design | — |
| 1.0 (planned) | release gate | Final assessment for DoC | — |