The LINDDUN methodology is a threat modeling technique that encourages analysts to consider privacy issues in a systematic fashion.
LINDDUN consists of six steps, as illustrated in the LINDDUN methodology steps illustration below. The first three steps are considered the core LINDDUN steps, as they focus on the problem space and aim at identifying the privacy threats in the system. The three remaining steps are more solution-oriented and aim at translating the threats that were identified into viable strategies and solutions that can mitigate the threats.
A more schematic overview of the different LINDDUN steps applied to an example is depicted below. The scenario in the example represents a rather simplistic social networking system. Each of the LINDDUN steps is illustrated. The picture clearly shows that LINDDUN is a knowledge-based approach. In (almost) every step, the methodology provides the required privacy knowledge to the analyst (depicted in blue).
First of all, a data flow diagram (DFD) is created based on the high-level system description. A DFD is a structured, graphical representation of the system using 4 major types of building blocks: external entities, data stores, data flows, and processes.
The DFD for the Social Network application is shown in the figure below (and in step 1 of the step-by-step example). In the DFD, the user is represented as an entity to interact with the system. The social network application contains two processes (the portal and the service) and one data store that contains all the personal information of the users.
Note that the model in this tutorial has been kept high-level for the sake of simplicity in this example. In practice, the DFD will be more detailed.
The second step of the methodology uses the LINDDUN mapping template as shown in the table below (and in step 2 of the step-by-step example) as a guide to determine the threats that correspond to the DFD created in the previous step.
The analyst should create a "personalized" table, based on LINDDUN's mapping table, which contains a row for each of the individual elements of the created DFD. This table can then be used as checklist throughout the elicitation phase, as each "x" in the table highlights a potential threat to the system that requires further analysis.
|Entity||Xonly applicable when anonymous use of the system is required (e.g. anonymous credentials, anonymous communication, ...)||Xonly applicable when anonymous use of the system is required (e.g. anonymous credentials, anonymous communication, ...)||X|
|Data store||X||X||Xmainly related to application with specific deniability requirements (e.g. e-voting, whistleblowing, ...)||X||X||Xapplies to system as a whole|
|Data flow||X||X||Xmainly related to application with specific deniability requirements (e.g. e-voting, whistleblowing, ...)||X||X||Xapplies to system as a whole|
|Process||Xoften not applicable or low priority||Xoften not applicable or low priority||Xoften not applicable or low priority||Xoften not applicable or low priority||Xoften not applicable or low priority||Xoften not applicable or low priority|
The third step of the LINDDUN methodology consists of a number of substeps.
Each of the X's in the mapping table of step 2 are examined to determine whether they pose a threat to the system. To this aim, LINDDUN provides a set of privacy threat tree patterns. These trees represent the most common attack paths for a specific LINDDUN threat category and DFD element type. An example tree is shown below.
The latest version of these privacy threat tree patterns is available in the LINDDUN privacy threat tree catalog.
The analyst should examine each of the branches of the tree with the specifid DFD element in mind. Each of the leaf nodes (or branches) that are applicable should be documented as threat description (LINDDUN suggest misuse cases as appropriate description template).
Leaf nodes and branches that are not applicable should be explicitly documented as assumptions. When one of the assumptions is altered in the process, it is important to easily track the required changes in the privacy analysis results.
Furthermore, all the potential privacy threats that are suggested by the privacy threat trees are evaluated and prioritized via risk assessment (step 4). Note that LINDDUN does not provide explicit risk analysis support. We merely refer the analyst to established risk assessment techniques.
Hereafter, in order of importance (determined during step 4), the suitable mitigation strategy for each threat is determined (step 5).
Finally, the classification of privacy enhancing technologies according to the mitigation strategies to which they adhere enables a more focused selection of suitable privacy enhancing solutions (step 6). If required, the mitigation strategies can also be translated into privacy requirements, instead of being directly implemented as solutions.
We refer to the webpage on mitigation strategies and solutions for more information on steps 5 and 6.
You can access the LINDDUN paper here. Please note that some of the steps have been updated after the original LINDDUN paper was released (i.e. see step 5 above). A step-by-step tutorial of the current version can be found on the download page.
An overview of LINDDUN, the studies performed to empirically validate LINDDUN, and the creation of the updated LIND(D)UN 2.0, can be found in the PhD thesis "Privacy Threats in Software Architectures"