Threat modelling and security analysis procedure

Threat modelling and security analysis procedure

TH-01 — Purpose and initiation

The security lead coordinates threat modelling to identify how the system could produce unacceptable losses and how its design, operation or dependencies could enable them. The activity supports requirements, architecture, testing and risk decisions. It is initiated for a new system or material change and repeated when the threat or operating context changes. The scope and level of detail are chosen for the decision and recorded.

The lead identifies participants with knowledge of the system, its users, operation, data processing and suppliers. Privacy and safety expertise is included where the system context requires it. The current architecture, requirements, asset and data inventories, supplier information, vulnerabilities and previous decisions are made available. Gaps in those inputs are recorded with their effect on the analysis.

TH-02 — Establish the model

The team identifies the system boundary, components, actors, interfaces, information flows and stores. It marks places where information or authority crosses a trust boundary. The model records deployment and administrative paths as well as the user-facing application. Build systems, update channels, monitoring, recovery facilities and supplier access are included where their compromise or failure affects the system.

The team states the assets, interests and essential functions at risk and the unacceptable outcomes to avoid. It identifies the assumptions being made about identities, privileges, input validity, time, data quality and connected services. The model version and configuration scope are recorded so that later analysis can identify whether it still applies to the system being delivered.

TH-03 — Identify scenarios

For each relevant interface and function, the team asks what an unauthorised actor could cause, what an authorised actor could do outside intended authority, and what could fail through error or disruption. Analysis considers impersonation, unauthorised change, disclosure, service exhaustion, privilege abuse, misleading records and compromised dependencies. The team follows sequences across components rather than assuming each component operates in isolation.

The team considers malicious or mistaken inputs, unexpected ordering, replay, concurrency, resource limits, recovery paths and maintenance operations. It examines whether a trusted component could be induced to perform an action for an untrusted source. For AI-enabled functions, the analysis includes hostile instructions embedded in data, manipulation of retrieved context, exposure through model interactions and effects of model or dataset changes. These are analysis prompts; the record states the actual scenario and conditions identified.

TH-04 — Analyse exposure

The assessor records the prerequisites, accessible path, actor capability or failure condition, affected assets and consequences. Existing controls are identified with evidence of their operation. The assessor states what is known, assumed or untested. The risk owner evaluates significance using the organisation’s criteria and records the relationship to existing risk entries.

Scenarios with common prerequisites or shared controls are linked. The assessment considers whether failure of a shared identity service, build environment or administrative account can defeat several protections together. Absence of a known exploit does not prove that a path is impossible; equally, a speculative path is not reported as an observed compromise. The evidence basis and uncertainty are preserved in the record.

TH-05 — Decide treatments

The team proposes changes to requirements, architecture, implementation, configuration, operations or supplier arrangements. Each proposed treatment identifies the scenario it addresses and the expected effect. The owner records the chosen action, responsible person, target date and verification method. Where the authority chooses to retain the risk, the acceptance follows the risk procedure and includes the operating assumptions on which it depends.

A treatment is connected to a requirement or controlled work item so that it can be implemented and assessed. The team identifies new risks created by the treatment and checks its behaviour when dependencies fail. Controls that reduce likelihood but leave serious consequences possible are described accordingly. A diagram annotated with a control name does not close the treatment action.

TH-06 — Verify and maintain

The verification lead translates relevant scenarios into tests, inspections or analyses with a defined expected result. Testing occurs within the authorised scope and operating constraints. Results identify the exact configuration, tools, inputs and evidence. A negative test result is interpreted in light of the tested path and conditions; it does not demonstrate that all possible attack paths were excluded.

The lead updates the threat record when treatment evidence is available. Open scenarios are carried into release and operational risk decisions. New interfaces, permissions, data uses, deployment patterns, suppliers, model capabilities, incidents or threat information trigger a review of affected scenarios. Superseded models are retained with the releases and decisions they supported.

TH-07 — Assurance

The reviewer checks that the threat model matches the current system boundary and includes material dependencies. Selected scenarios are traced to risk decisions, implementation and verification evidence. The review checks that unresolved assumptions and open treatments reached the release authority. Findings identify omissions, stale models, unsupported closure and places where the scope of the test was narrower than the claim made from it.