Secure by Design Example Threat Model
This example threat model is based on a fictional organisation, the Department of Artificial Intelligence and Robotic Technologies (DAIRT). It illustrates what the output of a typical threat modelling activity might look like.
It includes:
- a description of the scenario, outlining the situation being analysed
- an application diagram, showing the system’s components and 14 identified threat events
- a threat summary table, where each threat is categorised using STRIDE categories (spoofing, tampering, repudiation, information disclosure, denial of service, elevation of privilege)
- potential mitigation actions, each linked to the relevant MITRE enterprise security mitigations
- a risk register, summarising the key findings and proposed actions
The scenario
One of DAIRT’s most important objectives is to provide joint investment with industry. To do this, DAIRT wants to create the Grant Management Service to manage grants available to small and medium enterprises (SME) and sole traders operating within the AI and robotics field.
We’ll award grants based on criteria that include business and personal finances, and we’ll offer additional funding to offset tax.
This service will be accessed by:
- members of the public applying for grants
- department business users
It will be developed based on a Software as a Service (SaaS) application and will be administered by the department’s IT team.
The main business processes will include:
- grant applicants applying for a grant, and tracking their applications and proposals
- grant applicants updating their grant application and providing the final grant report
- business users pre-screening incoming applications, sending reminders and assigning applications to reviewers
- reviewers evaluating the applications and submitting reviews
- the business users awarding and paying the grant
The service has the following key characteristics:
- data classifications include OFFICIAL and OFFICIAL SENSITIVE
- public users expect to be able to access the web interface at any time of the day and perform actions quickly
- government users expect the information provided to be accurate and reliable
- government users expect any bank or payment information to be correct
Application diagram
Following a series of discovery workshops, we’ve identified 14 threat events that could impact the Grants Management Service. They’re documented in the following diagram with 14 yellow squares at points where they might impact the service.
The threat summary table after the diagram provides a key and STRIDE category for each identified threat.
View a larger version of the diagram
Link to threat: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14
Use the ‘Back to diagram’ links in the table to go back to this part of the page.
Threat summary table
Each identified threat event has been assigned an ID and a STRIDE category. The STRIDE categories are:
- spoofing
- tampering
- repudiation
- information disclosure
- denial of service
- elevation of privilege
| ID | Threat event | STRIDE category |
|---|---|---|
| 1 | Spoof user login (password reuse) | Spoofing |
| Back to diagram | ||
| 2 | Spoof active directory login (password reuse) | Spoofing |
| Back to diagram | ||
| 3 | DAIRT user could deny that they authorised a grant | Repudiation |
| Back to diagram | ||
| 4 | Users could upload malware and compromise the integrity of the system | Tampering |
| Back to diagram | ||
| 5 | Frontend could be overwhelmed, preventing legitimate access | Denial of service |
| Back to diagram | ||
| 6 | Man-in-the-middle attack to gain information by sniffing traffic | Information disclosure |
| Back to diagram | ||
| 7 | Frontend users could elevate privileges to levels of DAIRT users or system admins and access sensitive data | Elevation of privilege |
| Back to diagram | ||
| 8 | Cloud service provider users could exfiltrate data | Information disclosure |
| Back to diagram | ||
| 9 | VPN could be overwhelmed, preventing legitimate access | Denial of service |
| Back to diagram | ||
| 10 | Malicious users could alter data to set an alternative payee bank account for grant funds | Tampering |
| Back to diagram | ||
| 11 | Malicious users could steal sensitive information from the database | Information disclosure |
| Back to diagram | ||
| 12 | Malicious users could alter, remove or clear logs to cover their tracks | Repudiation |
| Back to diagram | ||
| 13 | Actors could target supply chains to gain unauthorised access to grants systems | Elevation of privilege |
| Back to diagram | ||
| 14 | Hardware could fail or malfunction, leading to loss of service | Denial of service |
| Back to diagram | ||
Potential mitigation actions
This table shows proposed security controls, with links to the relevant MITRE enterprise mitigations.
| Control description | MITRE link and ID | Effort | Potential challenges |
|---|---|---|---|
| Multi-factor authentication (MFA) | Multi-factor authentication (M1032) | Medium (several weeks) | Negative impact on user experience |
| Content delivery network (CDN) to cache and reduce origin load | Network segmentation (M1030) | Low (several days) | Configuring and managing a CDN can be complex and require specific expertise |
| Web Application Firewall (WAF) to prevent known malicious payloads | Filter network traffic (M1037) | Low (several days) | Possible false positive and performance throughput |
| Enhanced authorisation controls include actioning by 2 or more people | Privileged process integrity (M1025) | High (several months) | Negative impact on user experience |
| Logging for more verbose tracking of logins and actions | Account use policies (M1036) | Low (several days) | Performance issues and storage costs |
| Remove VPN for accessing backend service directly, use frontend instead | Limit access to resource over network (M1035) | High (several months) | User resistance and increased complexity |
| Check bank account details match grant organisation | User account management (M1018) | High (several months) | User experience, resource constraints, integration challenge |
| Prevent users from changing their bank details through self-service. Instead, they must raise a support request where they will be validated and checked through a manual process | Environment variable permissions (M1039) | Low (several days) | Integrity issues, such as incorrect or delayed updates |
| Reduce storage of sensitive data | Remote data storage (M1029) | Medium (several weeks) | Identification of what can and cannot be stored, as well as the overhead of retrieving data |
| Remove data after needed | Remote data storage (M1029) | Medium (several weeks) | Identification and location of data that should be removed |
| Prevent individual developers from accessing the production systems. Instead use build or deployment systems to make changes | Network segmentation (M1030) | Medium (several weeks) | Harder to debug issues |
Risk register
This risk register provides an overview of the key threat events uncovered in the threat model and how they should be managed.
| ID | Threat event | STRIDE type | Vulnerability | Mitigation, MITRE link and ID |
|---|---|---|---|---|
| 1 | Spoof user login (password reuse) – unauthorised user is able to gain access to the Grant Application System, undermining confidentiality or integrity of data | Spoofing | Weak authentication protocols, weak passwords, stolen credentials | To mitigate this threat:
|
| 2 | Spoof active directory login (password reuse) – unauthorised user is able to authenticate through Active Directory, undermining confidentiality or integrity of data | Spoofing | Weak authentication protocols, weak passwords, stolen credentials | To mitigate this threat:
Multi-factor authentication (M1032) |
| 3 | DAIRT user could deny that they authorised a grant | Repudiation | Weak or no log file protection controls or processes | To mitigate this threat:
|
| 4 | User uploads malware compromising integrity of system | Tampering | Weak or no network data filtering or scanning for malware. No regular updates of anti-malware signatures | To mitigate this threat:
|
| 5 | Frontend could be overwhelmed preventing legitimate access | Denial of service | No or weak controls to protect or detect denial-of-service (DoS) attack on application | To mitigate this threat:
|
| 6 | Man-in-the-middle attack to gain information by sniffing traffic | Information disclosure | Data transmitted or stored in the clear | To mitigate this threat, protect sensitive information with strong encryption. |
| 7 | Front-end users could elevate to DAIRT user or system admin and access sensitive data | Elevation of privilege | Misconfigured access control systems within database can mean a break of least privilege principle and enable elevated rights or access | To mitigate this threat:
|
| 8 | Cloud service provider users could exfiltrate data | Information disclosure | Insider threat actor within cloud service provider could use privilege to exfiltrate, change or delete data | To mitigate this threat, protect sensitive information with strong encryption and a customer encryption key. |
| 9 | VPN could be overwhelmed preventing legitimate access | Denial of service | No or weak controls to protect or detect DoS attack on VPN | To mitigate this threat:
|
| 10 | Malicious users could alter data to set an alternative payee bank account for grant funds | Tampering | Lack of access controls to sensitive files, folders or variables | To mitigate this threat, prevent unauthorised users and groups modifying environment variables. |
| 11 | Malicious users could steal sensitive information from the database | Information disclosure | Lack of access controls to database records | To mitigate this threat, restrict access by setting directory, record and file permissions that are not specific to users or privileged accounts. |
| 12 | Malicious users could alter, remove or clear logs to cover their tracks | Repudiation | Weak or no log file protection controls or processes | To mitigate this threat:
Restrict file and directory permissions (M1022) |
| 13 | Actors target supply chain to gain unauthorised access to grants systems | Elevation of privilege | Weak authentication protocols, weak passwords, stolen credentials | To mitigate this threat, use capabilities to prevent successful credential access by adversaries, including blocking forms of credential dumping. |
| 14 | Hardware failure or malfunction leading to loss of service | Denial of service | No failover capability or backup / restore functionality | To mitigate this threat:
|
- NCSC: Threat Modelling
- NCSC: Building a Security Operations Centre (SOC)
- Government Digital Service (GDS): Threat modelling
- Threat Modelling Manifesto
- Open Worldwide Application Security Project (OWASP) Threat modeling
- Department for Science, Innovation & Technology (DSIT): Conducting a STRIDE-based threat analysis