Threat model records and reports
Sytance · Updated
A threat model records the product architecture, attack scenarios, security controls and verification results. Linking these records lets a reviewer follow the reasoning from an attack to the measure chosen to address it. The gateway example shows how these records fit together; the sections below explain what to record and how to review it.
How to organise the model
Keep the diagram and analysis together, or connect them using stable identifiers. A document is suitable for a small review; structured records become useful when the same control addresses several threats or the team needs to compare releases.
In Sytance, the team edits the architecture and threat records in the workspace, then links the relevant security requirements, designs and verification records. The documentation module uses the workspace information to prepare reports.
Product information and assumptions
Identify the product version, deployment, purpose and people who use it. State the parts included in the analysis, external dependencies and any exclusions that affect an attack path.
OWASP’s decomposition guidance distinguishes entry points, assets and trust levels. Use those distinctions to explain the architecture rather than turning every asset into a separate process on the diagram.
- Context: product, release, environment, purpose and review owner.
- Architecture: diagram revision, processes, stores, external entities and flows.
- Protection goals: the data and functions that need confidentiality, integrity or availability.
- Assumptions: each uncertain condition, its owner and a way to confirm it.
Write one attack scenario per record
Give each threat a stable identifier and link it to the relevant diagram element or flow. Describe who could attack, the access they need, the action, the weakness and the consequence. State any conditions the scenario depends on.
Example TM-01: a read-only gateway user calls the configuration-write API. If the API checks authentication without checking write permission, the user can change the telemetry destination. The affected flow is browser to management API, and the attack threatens the integrity of stored configuration.
An entry saying only “elevation of privilege, high risk” cannot explain this scenario. Add the risk reasoning: the account needed, exposure of the endpoint, realistic impact and the existing controls considered.
Controls, implementation and verification
For TM-01, proposed control AC-01 requires the management API to check action and resource permissions on every configuration write. The implementation record should identify the relevant change. The verification record should include the actual test result for the named release.
- Decision: reduce, remove or accept the risk, with a reason and owner.
- Control: the required behaviour and the threat steps it addresses.
- Implementation: the component, change reference and product version.
- Verification: setup, action, expected result, observed result and evidence link.
- Remaining risk: unresolved conditions and the authorised review decision.
Expected and observed results
For the fictional gateway, the expected result is that a read-only write request is rejected and the stored configuration remains unchanged. The observed result records what happened during the test. Until the test runs, that field remains pending.
The same distinction applies to controls. “Signature verification planned” and “signature verification implemented and tested” communicate different levels of confidence. Preserve that difference when transferring the record to a report or another tool.
Reviewing the completed model
Ask a reviewer to follow one attack from the diagram to the selected control and test result. If the links cannot be followed, identify whether a record is missing or the attack needs a clearer explanation.
Check that the named release matches the diagram, that each scenario has a treatment decision, and that accepted risks identify who accepted them. Unresolved assumptions remain listed with an owner and a way to confirm them.
After updating the workspace records, open Documentation and select the relevant report. Sytance provides HTML previews and PDF or DOCX output according to the workspace configuration and plan. Check the rendered report against the current product version, analysis and verification evidence before using it in a review.