Draw the security architecture views: global system view, multi-patient harm view when it applies, updatability view and security use case views, all keyed to the item and connection IDs. Run STRIDE per element over those items and connections, trace the credible threats to security risks scored on exploitability and severity, and write each chosen control as a numbered requirement in the SRS so it is verified like any other requirement.
On the map: STRIDE threat model. Security architecture views. Cyber requirements into the SRS.
Rows are disciplines, columns are stages 1 to 8. Select a square to open that task.
Back to the full map
Feed each security control into engineering's requirements and quality's risk file under the same IDs. Security risks that live only in the threat model are invisible at the Phase 1 review.
Top-level system items and connections, including build and update infrastructure. Finer detail adds rows without adding threats. Assume the hospital network is hostile.
Keep anything that could affect patient safety. Drop threats that are improbable and cannot be verified when they have no safety impact. Keep mitigated threats that are easy to verify, because they show the controls working.
The engineers who know the system, with a security specialist reviewing. An outside firm working alone has trouble tying its findings into design controls and the safety risk file.
One testable control per requirement, for example block outbound network access, or run the container as a non-root user with a read-only root filesystem. Each requirement traces to the security risk it controls and to a verification protocol.
See the open positions and apply.