2.3 Threat modelling

Threat modelling is a structured activity that supports security decision-making and may inform risk assessment by helping teams identify credible threats and attack paths. Combined with the product context and an appropriate prioritisation method, the outputs can help in selecting appropriate security requirements and controls, including secure by default settings.

One commonly used approach to identifying and categorising security threats is STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service and Elevation of Privilege) (11). STRIDE is presented in this report as an illustrative example, but other suitable threat-modelling approaches may also be used(12).

Threat modelling should align with widely accepted threat-modelling principles (13), recognising that it is a collaborative and iterative activity focused on understanding and reducing real security risks, rather than simply producing documentation artefacts. Common anti-patterns to avoid include treating threat modelling as a one-off compliance exercise, over-engineering models that do not influence design or secure by default decisions and failing to review the model following substantial product modifications or changes in the threat landscape. For products incorporating artificial intelligence (AI) / machine learning (ML) components, threat identification should also consider relevant AI-specific attack patterns, such as prompt injection, model poisoning and adversarial inputs (14).

For SMEs, particularly those developing products intended for non-critical or lower-risk environments, the objective is not exhaustive analysis; it is a minimum viable model that is fast to produce, easy to refresh and tightly coupled to delivery (architecture decisions, default configuration and release gates).

A lightweight threat-modelling exercise can be organised around four questions (Shostack’s four-question framework) (15).

• What are we working on?
• What can go wrong?
• What are we going to do about it?
• Did we do a good enough job?

Table 3 provides an illustrative example of how these questions can be translated into practical activities and deliverables for SMEs.

Table 3: Threat modelling for SMEs

Define scope, Time-box a short scoping stage to One-page (or equivalent assumptions and make the exercise decision ticket/wiki) ‘Threat model security objectives focused. Capture what is in and out scope and objectives’ note, of scope (e.g. devices, apps, cloud covering: services, admin tools), the

• purpose (what decisions deployment context(s) and the this will drive); assumptions and constraints you ▪ scope boundaries are working under (e.g. ‘device may (components and be physically accessible’, ‘customer environments); network is untrusted’, ‘cloud APIs ▪ assumptions/constraints;
• security objectives and are internet-exposed’, ‘advanced ‘crown jewels’ (what must user capabilities’). Then state the not fail). security objectives that matter for this product (e.g. confidentiality, integrity, availability, plus privacy/safety if applicable).

the system that answers Shostack’s

core question, ‘What are we

working on?’ This may be an

architecture diagram, a data-flow

diagram or another suitable

representation. It should show the

main components, data stores,

external entities, key data flows,

entry points and trust boundaries in

sufficient detail to assess exposure.

Complementary techniques, such

as misuse cases or attack trees,

may also be used where helpful.

Consider reusing the architecture

and trust-boundary diagram

developed during the design phase

described in Table 1.

Mark trust boundaries Annotate the diagram with (a) trust Diagram showing: and privilege paths; boundaries (a) (boundaries between

• trust boundaries (internet– identify key assets environments with different security back end, device–cloud, properties) and (b) the highest- user–admin, tenant– privilege operations (e.g. firmware / tenant); OTA updates, remote admin, key ▪ privileged paths (updates, provisioning, identity issuance). auth, key management, admin actions); This is the step that turns
• top assets architecture into security-relevant (credentials/keys, sensitive architecture.

data, device control functions, availability).

of the answers to the question

‘What can go wrong?’, mapped to

entry/exit points, data flows and

trust boundaries (e.g. ‘credential

stuffing → account takeover →

remote control’, ‘malicious update’,

‘API authorisation bypass’, ‘man-in-

the-middle attacks during

onboarding’). Prioritise them using

a lightweight, documented method

appropriate to the product. This

might take into account impact,

likelihood, plausibility, exploitability

and exposure or use predefined

severity criteria. OWASP (b)

describes this as threat

identification and ranking as a core

step in most threat-modelling

approaches.

Define mitigations and Next, focus on ‘What are we going Controls, defaults and secure defaults, verify to do about it?’ For each top verification checklist, including: their effectiveness and threat, specify the mitigation

• Control/default decision set refresh triggers strategy, the required control(s) and for each top threat; the secure by default settings that ▪ test/verification mapping the product should ship with (e.g. (automation first); ‘admin interface disabled by ▪ explicit refresh triggers default’, ‘no default passwords’, (so that the model stays current). ‘signed updates enforced’, ‘least-privilege roles’, ‘authentication attempts rate-limited’). Then map each control to how it will be verified (e.g. CI checks, tests, configuration validation, release gates), which will help to answer the question ‘Did we do a good enough job?’ Finally, define the triggers that require rerunning the model (e.g. a new internet-exposed interface, a new auth model, new sensitive data, a new critical dependency, a major architecture change).

( a ) https://owasp.org/www-community/Threat_Modeling_Process ;. ( b ) https://cheatsheetseries.owasp.org/cheatsheets/Threat_Modeling_Cheat_Sheet.html .

A practical starting point could be to identify a small number of the highest-impact adverse-effect scenarios for users, operators or other affected parties and a manageable number of credible threat scenarios (e.g. the top 5 to 10) that could lead to them. These scenarios should be prioritised based on impact and likelihood. As part of their release review, teams should determine whether product changes affect the scenarios, assumptions or controls. Where products are intended for higher-risk or critical use cases, depending on the product’s intended use and associated risks, a more comprehensive analysis will be required.

Lightweight threat modelling does not necessarily require special threat-modelling expertise. Product expertise, on the other hand, is essential, because an accurate understanding of the product, its intended use and its deployment context is the foundation of a useful threat model. However, specialist security expertise is likely to be needed for higher-risk products or more complex threats.

Threat-modelling outputs can vary depending on aspects like the product’s scope, the assumptions, the methodology selected and analyst judgement. These inputs should be documented and applied consistently, to increase repeatability and support review.

Threat modelling and risk assessment should be revisited throughout the product lifecycle. For example, reviews could be performed at initial product design, implementation of the technical architecture, and verification, validation, maintenance and operation, where discovered vulnerabilities and field evidence can inform subsequent assessments.

1. Ülevaade

1.1 Viited

1.2 Tuvastatud nõuded

1.3 Seotud regulatsioonid

2. Tuvastatud nõuded

3. Seotud regulatsioonid

• ENISA -