Threat model summer 2026

(This kind of collaborative document may not be a perfect fit for a GitHub issue, but it's not really an ADR either. I'm open to suggestions for migrating this somewhere else; particularly somewhere that supports tables.)

While ADR-0015 contains the results of a security review done in April 2026, it's not clear whether the system has ever been subjected to a full threat-model analysis.

Threat modelling

A code review can unearth some security issues, and penetration testing other kinds. Still, such tests are incomplete because they fail to surface necessary security trade-offs.

For example, a code review may 'reveal' that an application can be viewed by anyone on the internet, only for the product owner to confirm that this is by design, being the system's entire raison d'être. Other systems may have a mix of publicly visible data, and data that must be protected from unauthorised access. Being explicit about such distinctions can help developers make good security decisions.

The STRIDE analysis model is an easy yet effective way of capturing and discussing security threats to a system.

STRIDE is an acronym for

• Spoofing
• Tampering
• Repudiation
• Information disclosure
• Denial of service
• Elevation of privilege

The idea is to consider each of these categories and ask: Is the system threatened in this category? Why? Why not? How likely is a security breach? What is the impact of a breach? What mitigations are possible? What do we decide to do about it?

Trade-offs

As the saying goes, the only secure system is one that doesn't exist. The next-most secure system is one that is turned off.

No practicable working system is secure. The purpose of threat modelling is not to make a system 'secure', since that is impossible. Rather, the purpose is to identify threats and make informed decisions about them.

STRIDE analysis

This section should be edited collaboratively whenever anyone thinks of threat, or mitigation thereof.

A threat could fit into more than one category, or one threat could lead to another: For example, an information disclosure vulnerability could lead to users' passwords being leaked, which then leads to a spoofing vulnerability.

Spoofing

The spoofing category includes threats to the system that involve users pretending to be someone they are not.

• [Add threats here]

Tampering

The tampering category includes threats where data may be changed in detrimental ways. This involves ransomware attacks, plain vandalism, but could also involve someone giving him or herself some advantage, such as a discount in a web shop, etc.

• GenPRES currently transports patient information as URL query parameters. Anyone with access to a browser's address bar can change these values.
• [Add more threats here]

Repudiation

The repudiation category includes vulnerabilities where users may deny having performed an action, and the system has no way of proving otherwise. The canonical example is a shopper who denies having received an ordered item.

• (GenPRES currently doesn't send out prescriptions, but when this feature is implemented, it may become relevant to consider whether it involves a threat.)
• [Add threats here]

Information disclosure

The information disclosure category includes vulnerabilities where information is visible to actors who should not have access to that information. Examples includes transporting cleartext data over the network (e.g. HTTP), or someone being able to read a database via a SQL-injection attack.

• Error messages include internal code-base details, as seen e.g. #418. Granted, Error: getDataResult Exception is only a hint that the underlying implementation is written in F#. From the use of camelCase and the word Exception, it could, I suppose, have been Java instead. Still, if other examples make it more evident which platform the site runs on, an attacker may use this information to focus his or her attacks.
• [Add more threats here]

Denial of service

The denial of service category includes threats that overwhelm or crash a system, thereby making it inaccessible to legitimate users. All web-facing systems are, to a degree, vulnerable to DDoS attacks, but other DoS attacks include buffer overruns (a subcategory that mostly involves unmanaged code).

• [Add threats here]

Elevation of privilege

The elevation of privilege category includes threats where users attain powers they should not have. Usually, this means malicious actors being able to act as administrators.

• [Add threats here]