Quirk Threat Modelling (QTM)

Here is how to quickly and accurately identify threats to a system.

I have developed the Quirk Threat Modelling (QTM) method over the years out of frustration with traditional frameworks, which are heavy, formalistic, and repetitive.

The ultimate goal of threat modelling is to identify risks and suggest protective measures, also known as security controls. All organisations I have worked with already have generic security controls checklists, like Information Policies or Security Requirements. If you don’t have one, you may develop it from the Security Controls Navigator. Generic checklists cover well known, common threats and implementations. Checklists are also rigid – they do not allow much room for thinking. However, they provide consistency.

There is no point in generating the complete list of security controls from scratch, if you already have a generic checklist. So that is point #1 – we will use threat modelling for things which are not common. Quirks, in other words.

By doing so, we will reduce the scope of threat modelling to specific threats only. That will significantly speed up modelling. It will complement, not compete with, the existing generic enterprise policies. We achieve consistency via checklist, then add flexibility, “outside-the-box” thinking via threat modelling. By combining two methods, we will get the best of both worlds.

Knowing what is common, what is quirk requires expertise. That is contrary to generic checklist, which can be applied by junior staff. That concept is described well here: Checklist vs Expert. By reducing the scope of expert involvement, we will also reduce the cost of the security review.

The point #2 is that we will focus on most likely, most damaging threats only. That way, we will save everyone’s time and attention.

Point #3 is that the threat is derived from quirk.

Here is the process:

Quirk -> Property -> Threat -> Credibility

Let’s take Internet-facing user registration form for example. It is unauthenticated (quirk) to allow new users to sign up. That means that anyone (property) can make requests to the form and submit any information they like (property). Therefore, it can be abused to send too many requests and cause denial-of-service (threat) or submit malicious data (threat). Denial of user registration would prevent new users from signing up, and that is significant impact to our business. It is also easy to organise a volumetric DoS attack, or submit bogus data, so we conclude the threats as credible (credibility).

Credibility should take into account existing security controls.

Quirk	Property	Threat	Credible?
Unauthenticated form	Anyone can submit requests.	DoS-attack	Yes
	Any data	Malicious injection	Yes

Sound intuitive, isn’t it?

Let’s practice another example: real-time data visualisation via SaaS solution.

Quirk	Property	Threat	Credible?
SaaS	The web interface is shared across multiple SaaS customers	Cross-tenant data leakage	Yes
SaaS	Data will be processed elsewhere	“Elsewhere” rogue employees may eavesdrop the data	Yes
Real-time	Persistent ongoing integration with the data in-house required.	Exposure of other in-house systems and data to SaaS vendor	No (IAM controls and data segregation is already in place)

In real life threat modelling I would not show “Credible” column at all. That is important distinction of this modelling – we don’t want to bloat it with insignificant threats. I would only include credible threats in the table. I only included it here for training.

Let’s practice a third example: vibe-coding shopfront for online retailer

Credible Threats:

Quirk	Property	Threat	Credible?
AI-generated coding	High volume of plausible-looking code	Review fatigue, leading to overlooked code errors	Yes – AI currently makes mistakes often. Broken business logic could lead to substantial business losses.
	High volume of plausible-looking code	Difficulties in code support and maintenance. Loss of engineering ownership.	Yes (increased management effort and troubleshooting cost)
	Cost per token	Costs runaway	Maybe. Engineers have good visibility and controls over token usage and costs.
	Non-deterministic – different output with the same prompt	Lack of reproducibility leading to difficulties in code support and maintenance.	Credible threat for cases where the same input needs the same output. (precise math calculations, for example)
	Unclear Intellectual Property rights	Cannot claim the AI-generated code as your property.	Yes, if the generated code is considered valuable company asset which requires legal protection.
	Supplier-dependant	Supplier dependency. Loss of engineering ownership.	Yes if consuming AI via remote API.
	Reads instructions in natural language	Malicious prompt injection	Significant credible threat, which may lead to devastating consequences.
	AI thinks on its own	Unaligned AI could influence engineers to make unaligned decisions or generate unaligned code	Not likely yet, though there are some reports of AI trying to blackmail engineers.

Notice how I don’t have quirks related to shopfront or online retailer. These are common properties, would be already covered by a common checklist.

Threat modelling this way should not take more than few hours, and it will produce accurate, specific security controls in addition to generic ones. It is not proprietary – feel free to use as much as you like.