LINDDUN Threat Modelling
So far, we have threat modelled in terms of STRIDE (spoofing, tampering, repudiation, identification, denial of service, escalation of privileges). LINDDUN is the other main type in industry and instead of looking from a security perspective, the main focus is on privacy.
We know that compliance to standards (e.g., ISO27001) doesn't guarantee privacy or security, as many large companies still get hacked each year. We also know that security doesn't guarantee privacy.
Security is the safeguarding of data and systems against those not granted access. Privacy, on the other hand is the right to decide who has access to our data.
Privacy can be described in many ways, but largely is understood as a social good, is widely protected by legislation, and is often a right. LINDDUN helps us to achieve privacy by design, by incorporating PETs into our software.
We also include the following as part of our privacy by design:
- Proactive, not reactive
- Preventative, not remedial
- Privacy as the default
- Privacy embedded into the design (e.g., privacy impact and risk assessments, impacts minimised)
- Full functionality of application without requiring data sharing
- E2E security
- Visibility and transparency
- Respect for user privacy (e.g., obtaining user consent)
What is LINDDUN?
LINDDUN is a mnemonic:
- Linkability (issue of unlinkability)
- Identifiability (issue of anonymity, pseudonymity)
- Non-repudiation (plausible deniability)
- Detectability (undetectability)
- Disclosure of Information (confidentiality)
- Unawareness (awareness)
- Non-compliance (compliance)
It is a methodology that we can use to introduce privacy early in the SDLC, and similar to STRIDE, it is model, and knowledge-based.
Process
We initially start similar to STRIDE by giving DFDs and identifying threat scenarios. We can then prioritise these threats, find ways to mitigate them, then select PETs to incorporate.
PETs
Privacy enhancing technologies can help aid privacy by design. LINDDUN has a list of these, and directs the user as to what to use as a mitigation strategy for the possible privacy issue.
Therefore, as LINDDUN gives the user a list of technologies to use, we avoid the use of experimental technologies, and it is clear what needs to be done to address the problem.
DFD Elements
Similar to the STRIDE DFD, we have entities (in rectangles), processes (in circles), data stores (two horizontal lines, one above and one below the data store name), and data flows, which show the direction that data travels.
Mapping LINDDUN to DFD Elements
Not all LINDDUN properties apply to all element types in the DFD. Therefore, we first consult a matrix, to establish which elements have which LINDDUN properties:
| DFD Element | L | I | N | D | D | U | N |
|---|---|---|---|---|---|---|---|
| External Entity | ✓ | ✓ | ✓ | ||||
| Process | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | |
| Data Store | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | |
| Data Flow | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
Assumptions
When we add DFD elements, the number of threats grows exponentially. Assumptions are explicit or implicit choices to trust an element of the software to behave as expected. If a DFD element is trusted, then it will not be subject to threats.
For example, we can opt to assume that the processes and data flows within the trust boundaries are trusted, but not to trust the user and communication with the portal or the datastore.
Threat Tree Catalogue
We can then create our mapping table, with the in scope items and the properties they need to have threat analysis done for. For each of these possible threats, we then need to identify a threat.
LINDDUN has a catalogue of possible threats, which is a tree pertaining to each DFD element type and the LINDDUN property we are looking at.
The tree gives a list of preconditions that need to hold for a threat category to materialize. The threat trees can be found on the LINDDUN website.
Prioritisation
The risk level is a combination of the likelihood and the impact of a threat materialising. LINDDUN doesn't specify how to do that, and instead relies on the organisation performing the threat analysis to make their own assumptions.
This then allows the organisation to do what they think is best first, but can cause LINDDUN to be applied differently based on the way it is applied.
Threats to Mitigation Strategies
We can use the mapping table that links mitigation strategies and LINDDUN threat trees, then look at a mitigation strategy taxonomy to select a mitigation approach.
Taxonomy
There is a taxonomy of different mitigation strategies, which we can think of as a tree. At the top of the tree is privacy, which then splits into some sub trees for concealing association and guarding association. This taxonomy can be seen below:
Given this taxonomy, we can then compare our mitigation strategies to the threats that we see. For example, for a database, we might have thre threat of linkability. The threat tree leaf nodes could include storing too much data, or information disclosure of the data store.
Therefore, the mitigation strategy we implement is to minimise the collected data by generalising it, and implementing access control.
We can finally add a column for a particular PET that we could implement as part of that mitigation strategy.