=Paper=
{{Paper
|id=Vol-1873/IWPE17_paper_24
|storemode=property
|title=A Metamodel for Privacy Engineering Methods
|pdfUrl=https://ceur-ws.org/Vol-1873/IWPE17_paper_24.pdf
|volume=Vol-1873
|authors=Yod-Samuel Martin,José M. del Álamo
|dblpUrl=https://dblp.org/rec/conf/sp/MartinA17
}}
==A Metamodel for Privacy Engineering Methods==
https://ceur-ws.org/Vol-1873/IWPE17_paper_24.pdf
A Metamodel for Privacy Engineering Methods
Yod-Samuel Martín José M. del Álamo
Departamento de Ingeniería de Sistemas Telemáticos Departamento de Ingeniería de Sistemas Telemáticos
Universidad Politécnica de Madrid Universidad Politécnica de Madrid
Madrid, Spain Madrid, Spain
samuelm@dit.upm.es jm.delalamo@upm.es
ORCID: 0000-0002-0065-5117 ORCID: 0000-0002-6513-0303
Abstract— Engineering privacy in information systems This paper describes our contribution to this effort, by
requires systematic methods to capture and address privacy presenting a conceptual framework which allows arranging the
issues throughout the development process. However, the different concepts that usually underlie the various
diversity of both privacy and engineering approaches, together contributions subsumed under the field of Privacy Engineering.
with the specific context and scope of each project, have spawned This framework has been realized as a metamodel which
a plethora of privacy engineering methods. Method engineering extends SEMDM (the metamodel for software and systems
can help to cope with this landscape, as it allows describing development methodologies described in ISO/IEC 24744
existing methods in terms of a limited variety of method elements [ISO24744]), and provides a controlled vocabulary of privacy
(and eventually enable their recombination into new, customized
engineering methodological elements and a normalized set of
methods). This paper applies method engineering to introduce a
privacy engineering metamodel, whose applicability is illustrated
connection points and relationships to organize those elements.
with a set of popular privacy engineering method elements, and a
Thus, it enables the description of different elements of existent
widely recognized privacy engineering method. privacy engineering methods in comparable terms, so that they
can be further catalogued and assessed. That metamodel can be
Keywords— Privacy engineering metamodel; Method thought of as a labelled rack, to each of whose compartments
engineering; Privacy engineering; Privacy Methods; Methodology; the contributions on privacy engineering can be anchored.
Metamodel; ISO/IEC 24744; SEMDM; Privacy by Design; GDPR; Moreover, by enriching the description of method elements
LINDDUN with well-defined connection hooks, their reuse and integration
is fostered.
I. INTRODUCTION
The remaining of the paper is structured as follows. Section
Despite the increasing urgency in addressing privacy II provides some background on privacy and method
concerns associated with information systems, and the engineering. Then, section III describes our proposal for a
technical developments available, engineering privacy-friendly privacy engineering metamodel based on the extension of the
systems remains a challenge for several reasons. First, privacy SEMDM metamodel, and section IV validates its applicability
is a multi-disciplinary, essentially contested concept [1], which by constructing a representation of LINDDUN, a well-known
can thus be subject to multiple reference frameworks, be them privacy engineering method. Finally, section V discusses the
social, legal, or technical. Second, research efforts have potential applicability of the metamodel we propose so as to
focused on tackling privacy issues by technical means, rather promote the reuse of privacy methodologies, and section VI
than investing in generalizing and systematizing the application concludes by summarizing the significance of our solution and
of said technical solutions so that others can reuse and apply pointing towards future work to overcome its limitations.
them. Third, even when a given privacy framework is set, the
diversity of information systems (platforms, APIs, services, II. BACKGROUND
infrastructures, enterprise systems…) and development process
models (agile, waterfall...) makes it difficult to elaborate a one- A. Privacy engineering
size-fits-all privacy engineering method1. Privacy engineering is a nascent field of research and
practice which pursues systematic approaches for the inception
In this context, dozens of novel contributions in the field of
and application of privacy-oriented solutions throughout
privacy engineering appear every year (of which the papers
systems and software development processes. According to
presented at this workshop represent a sample), each of which
one of the first definitions of privacy engineering [2], the
targets specific aspects and suits different situations. In order to
keystones of the field are:
assess the benefit and adequacy of any such solution, it would
be desirable to have the relevant knowledge systematically • Theories, which deal with privacy from different
organized so as to ease the communication within the approaches. For instance, for different authors, privacy
community of practice and research of privacy engineering. may be a matter of non-intrusion, seclusion, limitation,
control, boundary regulation, system architecture,
policy or interaction, just to mention a few. Following
1 that line, we consider that all privacy theories are born
For our purposes, we use both terms ‘method’ and ‘methodology’
interchangeably.
valid to apply privacy engineering, but different
theories provide different conceptual frameworks to
This work has received funding from the European Union’s Horizon
2020 research and innovation programme under grant agreement No 731711.
which the elements of each privacy-engineering best practices, organizational maturity), isolated processes (e.g.
method adhere. impact assessment, requirements analysis), or specific domains
(Big Data, Internet of Things). Yet they lack a shared, all-
• Methods, that is, processes for capturing and encompassing conceptual framework, independent from
addressing privacy concerns during any of the stages specific privacy engineering methodologies, development
of the lifecycle of information-based systems, which practices and application domains.
include their conception, development, management,
and maintenance. Methods provide directions and rules It is under these circumstances that we introduce our
and help set privacy goals, structured in a systematic approach, which proposes the definition of such a framework
way into tasks and stages with the aid of supporting where the different privacy engineering methodologies may be
tools and techniques. pegged out, by formalizing the definition of a metamodel
which consists of the elements that usually appear in privacy
• Techniques, which refer to procedures, possibly with a engineering methodologies and the relationships between one
prescribed language or notation, to accomplish specific another.
privacy engineering tasks.2
B. Method engineering and SEMDM
• Tools, that is, means (automated or not) that support
privacy engineers in carrying out their responsibilities Our approach is grounded in the discipline of method
within a privacy engineering method. engineering, which is [5] “the engineering discipline to design,
construct and adapt methods, techniques and tools for the
Efforts on privacy engineering usually stick to the “Privacy development of information systems”; and which focuses on
by Design” (PbD) paradigm [3] which summons engineers and designing methods (or methodologies) for specific situations
other stakeholders to integrate privacy aspects into the different (e.g. a specific organization, a specific project) rather than
activities they are involved, throughout the whole development resorting to rigid, existent methodologies.
lifecycle of information-based systems, rather than introducing
them as an afterthought. Several PbD methods have been Any methodology that may be constructed responds to an
developed which define engineering activities that introduce underpinning metamodel, i.e. an abstract model that describes
privacy at different stages of the development lifecycle, the concepts that may be present in the methodology (i.e. the
defining what are usually named whole-lifecycle privacy types of elements it is made of) and their potential relations
methodologies. with one another. Many methodologies may exist that conform
to the same, shared metamodel (i.e. their descriptions can rely
One such effort exemplifies all the concepts described on a common set of terms).
above: LINDDUN [4] is a privacy-engineering method focused
on the privacy assessment of information systems. It One such metamodel is defined by the Software
conceptualizes privacy as seven distinct properties widely Engineering Metamodel for Development Methodologies
recognized by the privacy research community, represented by (SEMDM)[7], standardized as ISO/IEC 24744 [8], and “aimed
its corresponding threats (from whose initials LINDDUN takes to the definition of methodologies in information-based
its name). This method describes a set of techniques to e.g. domains, i.e. areas characterized by their intensive reliance on
identify privacy threats, and provides a tool called “threat information management and processing, such as software,
catalogue” that supports privacy engineers on this process (v. business or systems engineering.”
section 4 below for a detailed description of LINDDUN in SEMDM proposes three layers of abstraction to define and
terms of our privacy engineering metamodel). instantiate methodologies: metamodel, methodology and
Although this conception of privacy engineering seems endeavor (a.k.a. project). The metamodel defines the elements
clearly founded, there is no common standard framework that methods engineers employ to enact methodologies. In turn,
which privacy engineering developments may refer to. As a developers use the methodologies to construct products or
matter of fact, efforts on standards for privacy have long been deliver services in the context of particular endeavors.
undertaken by ISO/IEC JTC1/SC27/WG5 (Joint Technical The SEMDM metamodel describes a set of concepts that
Committee 1 of the ISO and the IE, subcommittee 27 on IT can be part of any methodology, and which cover the three
Security Techniques, working group 5 WG5 on identity dimensions of processes, producers (including people) and
management and privacy technologies), which has delivered products:
general references that engineers and managers addressing
privacy must take into account with regards to terminology, • Work Units describe things to be executed, such as a
institutionalization of practice (i.e. ensuring that organizations Process (large-grained Work Unit that operates within
apply the same good practices), and support for evaluation (i.e. a given area of expertise), a Task (a small-grained
approaches on how privacy is evaluated). However, those work unit that focuses on what must be done), or a
efforts only provide partial views of privacy engineering, as Technique (a small-grained work unit that focuses on
they deal with individual perspectives (e.g. privacy principles, how it has to be done). A methodology may
recommend using specific techniques for a task, with
different degrees of Recommendation (e.g.
2
Note how these Techniques are methodological rather than technological, compulsory, optional, discouraged, etc.).
and hence they are different from the “Privacy Enhancing Technologies”,
which belong to the realm of the technology applied at each endeavor. • Producers describe agents that have the responsibility
to carry out work units, and can be specialized into
Roles (a collection of responsibilities that a producer Thus, SEMDM provides a comprehensive and extendable
can take), Tools (an instrument that helps another metamodel for system and software method engineering. We
producer to execute its responsibilities in an automated have leveraged these features to develop a comprehensive
way) and Teams (a set of producers). privacy engineering metamodel (detailed in the next section)
able to cope with the variety in privacy frameworks, business
• Work Products are artefacts of interest for the project domains, types of systems, and development processes.
which can be used as inputs, intermediate results, or
outputs of a work unit; e.g. Document, Software Item III. PRIVACY ENGINEERING METAMODEL
or Model. In SEMDM, a Model provides an abstract
If privacy engineering promoters want it to be actually
representation of some modelling elements by
adopted, they cannot aim at proposing completely new
aggregating a set of Model Units, which may be related
methodologies from scratch which are disconnected from
with one another according to the grammar defined in
current practice. Rather, privacy engineering needs to be
a Language. Work products may be acted upon by
aligned with more general efforts on software and systems
work units through different Actions (read, create,
engineering, in order to ensure a smooth integration and ease
modify, or delete).
its application and utility.
• Stages represent a managed time frame with a specific
An important step in this direction would be the
objective within a project, either instantaneous such as
formulation of a conceptual framework that focuses on
a Milestone, or with duration such as a Phase (during
generalizing and systematizing privacy engineering
which the same cognitive framework prevails), a Build
methodology elements, so that they can be compared, assessed,
(aimed delivering a version of a work product), or a
and integrated.
Time Cycle (aimed at delivering the final product or
service). Method engineering (and SEMDM in particular) provides
an especially suitable foundation to model the field of privacy
A specific methodology (or a method fragment) will define
engineering. Indeed, the aforementioned definition of privacy
its own set of Work Units, Producers, Work Products, or
engineering matches quite well the SEMDM metamodel, as
Stages (e.g. a method may define a type of Document called
both consider the notions of theories, methods, techniques and
Requirements Specification to be produced when the method is
tools; to which SEMDM adds other concepts such as tasks,
enacted). Each of these elements defined in a methodology
stages, roles, teams and work units, which are also relevant to
holds a dual reality: on the one hand, they are instances of the
privacy engineering methods, as we will show later. Besides,
concepts defined in the metamodel (e.g. Requirements
SEMDM addresses both the process and the product
Specification is a kind of Document); on the other one, they are
dimensions, both which are tackled by privacy engineering
Templates that will be instantiated at each endeavor when the
methodologies.
methodology is enacted (i.e. each project will fulfill its own
instance of Requirements Specification, according to the said In consequence, we have built on and extended SEMDM to
Template). The relation between both perspectives is called a propose a Privacy Engineering Metamodel, by identifying a set
‘powertype’ relationship. (The interested reader can get further of extensions to the standard SEMDM metamodel that support
details on the use of the powertype pattern for methodology the concepts specific to privacy engineering. The standard
metamodeling from [9].) SEMDM metamodel together with our extensions can be used
to describe any privacy-engineering methodology. Of course,
SEMDM also defines Resources, that is, methodology
this can be further extended by specific privacy frameworks
elements that are used ‘as is’ at the project level, without
which refine these concepts or define their own extensions.
requiring any instantiation, namely:
The most relevant extension to SEMDM that allows
• Languages which define a set of Model Unit Kinds dealing with privacy engineering aspects consists in the
focused on one modelling perspective, and the definition of several types of Resources (in grey, Fig. 1)
relations allowed among Model Units of those kinds. present in many privacy engineering methods, and which
A Language can be any complex, structured system of provide the foundations to deal with privacy engineering from
related symbols able to convey meaning (which different perspectives, namely ontological (Privacy Conceptual
encompasses the formal languages that underlie Model), deontological (Privacy Normative Framework),
programming languages, visual languages and natural situational (Privacy Engineering Code), and epistemological
languages alike, but also conceptual languages as in (Privacy Knowledge Base). Besides, an abstract type of role
‘the language of art’). (Privacy Engineering Role) subsumes the common
• Notations which are associated to a Language, and responsibilities that may be expected from privacy engineers.
provide a concrete syntax to represent Models A. Privacy Conceptual Model (PCM) and Units (PCUs)
conforming to that language.
A Privacy Conceptual Model (PCM) provides a conceptual
• Guidelines which tell how to use some methodology description of what ‘privacy’ is in the context of the privacy
elements. theory where a specific privacy-engineering methodology is
grounded. Due to the plurality [10], contextuality [11], and
• Constraints, that is, conditions that hold or must hold contestability [1] of privacy as a social, political and legal
at certain point in time within the methodology. concept and its different translations to the technical domain,
Fig. 1. Structural meta-model of the SEMDM extensions for the Privacy Engineering Framework
we refrain from folding a specific conception of privacy into also affect indirectly the Work Products or Work Units
the definition of our Privacy Engineering Metamodel. We do from the method.
however assume that any defendable privacy engineering
3. Privacy Endeavor Requirements (PER) are set on the
method will draw on some ontological definition of privacy,
which may in turn influence all the methodology elements. system being developed in an endeavor. While both
Existential and Temporal Constraints apply to the
Besides providing a definition for privacy, the PCM may elements of the method itself, these Requirements
answer other questions such as what its subject and object are apply to the products created when the method is
(cf. [1]). For instance, ISO 29100 privacy framework [12] enacted. Although a Requirement Set is typically
defines what can be considered as personal information, which considered one of the Work Products produced during
actors can operate with it and in what interactions they can be an endeavor, in this case we are dealing with high-
involved, etc. level requirements, which are provided by an external
Resource, to be obeyed ‘as is’ by the system.
A PCM is often made of Privacy Conceptual Units (PCUs).
For instance, some models [12] specify privacy into a list of For example, the EU General Data Protection Regulation
privacy principles (fundamental, primary, or general guiding (GDPR) [16] provides a PNF that requires the existence
rules for the implementation of privacy protections), others (Existential Constraint) of a Data Protection Officer (DPO)
[13] as a set of privacy harms (problems that a data subject Role with specifically allocated Tasks, prescribes that any data-
may suffer as a consequence of an activity), yet some others processing-related Task cannot be performed unless an impact
[14] describe it as a set of technical goals (properties of the assessment Process has been carried out before (Temporal
system-to-be). Note how this partition of the concept of Constraint), and mandates a set of Requirements to be met by
privacy into conceptual units is not compulsory, e.g. some any system dealing with personal information. Note how the
theories [15] conceive privacy without resorting to such specific PNF defined by GDPR commits as well to a given
partition, —yet all respond to some given conceptual model. PCM (viz. a set of principles relating to processing of personal
data and a set of rights of the data subject), but these are
B. Privacy Normative Framework (PNF) and its components different Resources even if referenced by the same source.
A Privacy Normative Framework (PNF) provides
normative requirements to be applied by all the methods C. Privacy Engineering Code (PEC)
claiming to abide by it, and it may include binding regulations A Privacy Engineering Code (PEC) refines or clarifies the
as well as non-binding, recommended best practices. A PNF is application of the PNF under specific situations or contexts.
composed of three types of prescriptive elements: The PEC (sometimes known as ‘code of conduct’ or ‘code of
practice’) includes a set of Guidelines that document how a
1. Existential Constraints which require (or preclude) the Constraint or Requirement from the PNF can be applied
existence of specific elements in the methodology
whenever a methodology is enacted on a specific context or
(specific Tasks, Roles, Work Products, etc.). situation. The PEC may be typically subject to compliance or
2. Temporal Constraints 3 on the elements of a audit checks. For example, Art. 40 of the EU GDPR
methodology. They are expressed as entry or exit encourages that different institutions draw up codes of conduct
conditions on Actions, which must hold at a certain “…intended to contribute to the proper application of this
point in time (e.g. setting that an Action cannot be Regulation, taking account of the specific features of the
executed unless the condition is met) —besides they various processing sectors and the specific needs of micro,
small and medium-sized enterprises.”
3
D. Privacy Knowledge Base (PKB)
These are simply called Constraints by SEMDM, but we qualify them as
A Privacy Knowledge Base (PKB) is a piece of generally
Temporal to distinguish them from Existential Constraints.
recognized knowledge that can be reused ‘as is’ in privacy-
engineering endeavors, and whose value and usefulness are responsibilities in the audit and/or certification process, or
collectively accepted. In our metamodel, a PKB is described as independent supervisory authorities with responsibilities e.g. in
a set of Model Units (instances of some kind of element the consultation prior to the processing. These roles need not
defined in a formal or conceptual Language), but which are represent privacy engineers (as they do not meet the aforesaid
provided by a methodology as a Resource rather than created threefold savvy), yet they are part of the privacy engineering
by each endeavor. An analogy could be the set of standard method (as they are involved in some of the tasks there
libraries provided by most programming languages alongside defined).
the language specification itself, which define already
developed software components to be integrated with others IV. DESCRIPTION OF LINDDUN IN TERMS OF THE PRIVACY
developed within an endeavor. A PKB can be used by ENGINEERING METAMODEL.
different types of Work Units defined in the methodology. For the proposed Privacy Engineering Metamodel to be
Although privacy engineering is a nascent field, it has useful, the concepts involved in privacy engineering
already developed certain amount of generally recognized methodologies should be mappable to either SEMDM
knowledge, which is gathered in PKBs. For instance, privacy methodology elements or to the extensions that we have
patterns [17] provide documented design solutions to common introduced above. In particular, as a validation of the
privacy problems in particular contexts. Privacy patterns can applicability of our metamodel, we have applied it to describe
be described according to community-agreed templates and the LINDDUN methodology (a well-known privacy-
pattern languages which define the relations among them, and engineering method) and its main elements, as shown next.
gathered together in privacy pattern repositories to be reused LINDDUN [4] is a model- and knowledge-based privacy
by privacy engineers. Some other examples of currently engineering methodology aimed at systematically identifying
available PKBs are privacy design strategies [18] and privacy the privacy threats in a system and the solutions that mitigate
threats [19]. them, by following six linear steps, namely:
E. Privacy Engineering Roles (PER) 1. Define a data flow diagram (DFD), departing from
Some Privacy Engineering Role (PER) participates in one either the requirements specification or the system
way or another in most privacy engineering methods. It architecture, while focusing on the internal data stores
represents someone who understands the privacy framework, is and the data flows that cross the organization
aware of the privacy engineering methodology elements that boundaries, rather than on the internal processes.
lead to the development of privacy-enhanced systems, and is 2. Map privacy threat categories to DFD elements (just
able to apply them within the endeavor at hand. As such, defined in the step above), according to a predefined
Privacy Engineering Roles are characterized by their table that details potential threat categories for each
multidisciplinarity, being savvy in the three of privacy, type of DFD element; while optionally discarding less
engineering and the domain of the specific endeavor. As stated likely threats, and reducing threats with common
by Cranor [20], “[a] privacy engineer is someone who elements to a single one.
understands the engineering and the privacy sides and works
out strategies that allow people to protect privacy without 3. Identify threat scenarios, according to the guidance
getting in the way of building cool things.” provided by a set of privacy-threat-tree patterns,
describing threats in terms of misuse cases, and
Note that the PER represents an abstract role which shall be documenting any assumptions made.
instantiated by more specific Roles defined by particular
privacy engineering methods (e.g. Privacy Requirements 4. Prioritize threats, depending on the risk associated to
Engineer, etc.), with the specific responsibilities set by the each one, according to the results of a risk assessment
methodology. For instance, the Carnegie Mellon University external to this methodology.
M.Sc. In IT - Privacy Engineering enumerates a wide range of
5. Elicit mitigation strategies, according to a taxonomy of
responsibilities that may be assumed by privacy engineers [21]:
strategies and a table that maps threat types to
“[…]develop technical solutions to help mitigate privacy
strategies.
vulnerabilities; analyze software designs and implementations
from a privacy and UX perspective; research, document, and 6. Select Privacy-Enhancing Technologies (PETs),
help remediate design decisions, operating procedures, or constrained by the mitigation strategies just elicited.
processes that may directly or indirectly contribute to future
privacy risks; create cutting-edge privacy feature prototypes; It is not difficult to realize how LINDDUN methodology
help to lead better on privacy by example; and partner with key can be modelled in terms of the elements of our Privacy
business, technical and legal stakeholders across various Engineering Metamodel (including both native SEMDM
business groups to implement Privacy by Design.” elements and the extensions we have defined).
Besides these Privacy Engineering Roles, any privacy Each of the LINDDUN steps specifies what must be done
engineering method may define additional, concrete roles (and in order to follow the methodology, that is, they define
their associated responsibilities) that must be considered at the different types of Tasks. Besides, most of these steps also detail
methodology level. For instance, the EU GDPR identifies the specific procedures to be followed in order to complete the
roles of: data protection officer (DPO) with responsibilities in respective task, that is, they also define some associated
the privacy impact assessment, certification body with Techniques. These techniques are sometimes mandatory (e.g.
when threats are elicited, they must be refined using threat tree Tasks, Techniques, Work Products and Resources) and
patterns, documented according to a threat description template provides the relations between them.
together with any assumptions made), other times they are
All LINDDUN’s methodology elements are influenced by
merely recommended (e.g. strategies and solutions should be
respectively elicited using LINDDUN-provided mappings, but its underlying Privacy Conceptual Model, which consists of
nine privacy properties (that is, Privacy Conceptual Units), viz.
these are a mere convenience), and others are optional (e.g.
DFDs can be created following specific techniques departing unlinkability, anonymity, pseudonimity, plausible deniability,
undetectability, unobservability, confidentiality, awareness,
from specifications or architecture, but other techniques can be
followed as long as the resulting DFD accurately models the and compliance. LINDDUN Privacy Threats are accordingly
classified into seven categories (after whose initials LINDDUN
data flows in the system). In some cases, LINDDUN does not
even provide any technique for the respective task, but refers is named), depending on the property respectively
compromised: Linkability, Identifiability, Non-repudiation,
the reader to external sources (e.g. threat prioritization depends
on applying techniques specified elsewhere, in order to Detectability, Disclosure of information, user Unawareness,
and Non-compliance. It is through these categories that the
compute the likelihood and impact of privacy threats). The said
Tasks are also grouped into two Processes, namely the influence of the PCM pervades the LINDDUN methodology.
Thus, the structure of several Templates of Documents and
elicitation of privacy threats (which covers the first three steps)
and the selection of mitigating solutions (the three last). These Privacy Knowledge Bases in LINDDUN matches these
same Processes shall be iterated throughout the development
cycle. And from the temporal perspective, these LINDDUN TABLE I. METHOD ELEMENTS IN LINDDUN
Processes can be performed during different Phases of a Tasks Techniques Work Products Resources
Processes
software and systems development methodology. Although the Task Kind Recom. Technique Action Work Product Kind c Privacy
specific phases shall depend on and align with the development Usage a Kind Type b Knowledge
methodology employed, LINDDUN authors themselves Base
suggest that these Processes can be applied several times
Define data R Create DFD R System Requirements
during the “requirements” (i.e. inception) phase, during the flow from Specification
“architecture” (i.e. elaboration) phase, or during the requirements C Data Flow Diagram
maintenance phase (on existing systems). R Create DFD R System Architecture
These Work Units (Tasks, Techniques and Processes) from Document
Architecture C Data Flow Diagram
produce tangible results, i.e. different types of Work Products.
More specifically, the DFD is a type of Model (hence the Map threats M Use threat R Data Flow Diagram
to data flow mapping
Elicitation of privacy threats
description of LINDDUN as “model-based”), whose Model C Threat Mapping
elements template table
Units (viz. external entities, data stores, data flows, and
processes) respond to a Language and are represented O Discard less M Threat Mapping
likely threats Table
(depicted) using a graphical Notation. Likewise, Misuse Cases
O Combine M Threat Mapping
[22] are types of Models employed to describe threats. And threats Table
different types of Documents (the threat mapping table; and the (‘reduction’)
lists of threats, assumptions, mitigation strategies and PETs) Elicit M Refine R Threat Mapping
are created by instantiating the respective Templates. Besides, privacy threats Table
Work Products can be not only created, but also modified or threats C Threat List Privacy
merely read, e.g. when the outputs of a Work Unit are then Threat Tree
used as inputs by another one. LINDDUN even allows for Catalogue
using Work Products that have been created elsewhere (e.g. the M Document C Assumption List
requirements specification or the architecture from which the assumptions M Threat List
DFD can be derived). M Document R Threat List
threats C Misuse Cases
Some of the methodology steps are further supported by
Prioritize – – R Risk Assessment
predefined catalogues of privacy threat trees, mitigation
Selection of mitigating solutions
threats Document
strategies and privacy-enhancing solutions. That is, the
methodology provides three Privacy Knowledge Bases (once M Threat List
again, hence the “knowledge-based” feature of the Elicit R Map threats R Threat List Mitigation
methodology). These knowledge bases include each a list of mitigation to strategies C Mitigation Strategies Strategies
atomic components or Model Units (threats, strategies, strategies List (Taxonomy
solutions), besides defining the relationships among them. & Mapping)
These PKBs can be used by any Producer that applies the Select R Map R Mitigation Strategies Privacy-
method, in order to simplify the elicitation processes by Privacy- strategies to List Enhancing
Enhancing solutions C PETs List Solutions
directly including these Model Units as needed, rather than Techniques Catalogue
coming up ex novo with other threats, strategies and solutions. a.
Recommended Usage: M = Mandatory, R = Recommended , O = Optional, D =
Discouraged, F = Forbidden
Table 1 (below) models the concepts defined by b.
Action Type: C= Create, M = Modify, D = Delete, R = Read-only
LINDDUN in terms of these method elements (Processes, c.
Work Products in italics are not defined by LINDDUN itself but elsewhere (nonetheless,
they are used by LINDDUN).
categories, which guide as well the threat elicitation Process selecting appropriate method elements to the specific context
that yields the Threat List. The latter is employed to elicit the of each endeavor.
mitigation strategies, which in turn guide the selection of PETs,
For instance, and keeping at the LINDDUN example, it
hence both are also indirectly affected by the threat categories.
does not prescribe any Privacy Normative Framework, nor
V. METHOD REUSABILITY AND INTEGRATION THROUGH THE does it feature any Privacy Engineering Code. A methodologist
PRIVACY ENGINEERING METAMODEL might anyway integrate LINDDUN with a specific PNF or
PEC, by introducing the respective Constraints, Requirements
It shall be noted that our Privacy Engineering Metamodel and Guidelines as new method elements, and evaluating their
does not prescribe that all privacy methodologies incorporate impact in LINDDUN-defined elements. Likewise, it happens
all the types of Resources and other elements herein presented. that LINDDUN is only focused on Work Units and Work
Rather, we merely describe those elements which appear Products, but it is agnostic regarding the Producers that
frequently in privacy methods, so as to offer a common perform and act upon them. Nonetheless, it should not be
theoretical model. What is more, as we discuss in this section, difficult to map elements from other methodologies (e.g.
and siding with the objectives pledged by method engineering, analysts, architects, etc.) to Producer ‘placeholders’.
the definition of different methodologies in compatible terms
might ease the integration of elements or fragments from Furthermore, the Tasks defined by LINDDUN may depend
different privacy methods (whether in whole or in part) with on the integration with external methods. For instance,
one another and within generic (i.e. non-privacy-specific) LINDDUN prescribes a Task to prioritize threats, which
software and systems engineering methodologies. Hence a depends on the result of a risk assessment Process. However,
specific privacy method may lack some of the metamodel neither does it tell what Technique to employ for that risk
elements; however, this should not be considered a drawback, assessment, nor does it define the Document Template for the
but rather a feature, which matches the paradigm of method risk assessment document, leaving both to the implementer’s
fragment reusability. decision. Other sources are available that provide techniques to
compute a privacy threat likelihood and its impact which can
We anticipate that different privacy engineering methods be easily introduced, as long as they produce a list of risk
will coexist, which respectively suit better the needs of specific indices for each threat which can be used for prioritization.
fields, organizations, endeavors, legislations or technologies
(i.e. there will not be any overarching method that covers the Moreover, LINDDUN does not even encompass all the
whole of privacy engineering). We assume that engineers may possible privacy-related Tasks either. It only deals with some
be willing to leverage these methods, so as to benefit from their of them, while leaving out of its scope the creation of privacy
usage beyond their initially planned scope, and integrating policies; privacy testing, assessment, and auditing, etc., which
elements picked from different methods. And we posit that the could be specified by other methodologies. This can be eased
definition of privacy methods in terms of the metamodel herein by mapping LINDDUN Tasks onto different Processes from
presented may ease their reuse and integration. generic development methodologies (e.g. system analysis, risk
assessment, architecture engineering), and completing the
Indeed, the declared purpose of method engineering [6] absent Processes with Tasks from other privacy-engineering
consists in enabling the assembly of methodologies from methods.
method fragments coming from different sources, so as to
develop new methods that fit better the endeavor at hand. All in all, LINDDUN elements would need to be integrated
SEMDM facilitates this methodological flexibility regarding with elements from other methodologies in order to cover the
each specific situation, by introducing three distinct layers for whole development lifecycle, and they should be embedded
the metamodel, the methodology and the endeavor. Thus, two within a mainstream development methodology (e.g. Agile,
methods might be more easily integrated as long as they are Unified Process, etc.) where privacy aspects would only play a
described in compatible terms i.e. drawn from the same limited part. All the intervening methods should be first
metamodel (to avoid an apples-and-oranges situation). Yet the modelled in terms of SEMDM so as to allow connecting their
metamodel not only provides a shared terminology, but also elements with one another. And only then, the resulting,
defines a series of hooks or extension points where elements composed methodology might be applied to new projects.
from both methods can interface with each other. Then,
departing from existent method parts or elements (e.g. various VI. CONCLUSION
definitions of tasks, techniques, products), a methodologist can It will be difficult that privacy engineering succeeds unless
design new methods through different strategies (e.g. by there is a common, shared understanding of its underlying
assembling different fragments already available), always concepts and the relationships between one another. We have
taking into account the goals that the method under defined such a common conceptual framework: a Privacy
construction is expected to fulfill. Therefore, method Engineering Metamodel that extends the SEMDM metamodel,
engineering responds to the question of how a method is and which paves the way to reuse and assemble methodologies.
developed in a context where relevance must be given to We have demonstrated the application of our metamodel by
specific domain constraints and goals that the method under decomposing LINDDUN into its constituent elements, defined
construction must fulfill (in our case, privacy constraints and in terms of the SEMDM metamodel plus our extensions, and
goals). The answer comes by tailoring the method (rather than suggesting how these elements might be reused and integrated
sticking to a predefined methodology set in stone) and with other methodological approaches.
Most relevant concepts for privacy engineering can be It is the case, however, that the rigorous application of
mapped onto the elements provided by SEMDM, method engineering principles has been in general limited (e.g.
supplemented with our extensions. It should be noted that we to critical systems), and it remains a tool to organize the
do not claim either the novelty of these additional concepts knowledge rather than a practical way to integrate different
(some of which have long been established in the general methodologies. Anyway, achieving the same result in the field
discipline of Engineering), or its exclusivity to the field of of privacy engineering would still be a success nonetheless.
privacy engineering (as most can be applied to other categories
of non-functional requirements as well); but just that we have REFERENCES
identified them as appropriate to model privacy engineering, [1] D. K. Mulligan, C. Koopman, and N. Doty, “Privacy is an essentially
though they were not available straightaway from SEMDM. In contested concept: a multi-dimensional analytic for mapping privacy:
fact, these extensions might well be considered as relevant Table 1.,” Philos. Trans. R. Soc. A Math. Eng. Sci., vol. 374, no. 2083, p.
20160118, 2016.
contributions in the context of SEMDM itself. [2] S. Gurses and J. M. del Alamo, “Privacy Engineering: Shaping an
Despite the proven need, a potential problem of our Emerging Field of Research and Practice,” IEEE Secur. Priv., vol. 14,
no. 2, pp. 40–46, Mar. 2016.
metamodel is the lack of a guarantee of adoption. It may [3] A. Cavoukian, “Privacy by Design The 7 Foundational Principles,”
happen that some proponents of privacy engineering Toronto, Ontario (Canada), 2009.
methodologies refrain from recognizing other alternatives [4] K. Wuyts and W. Joosen, “LINDDUN privacy threat modeling: a
deemed to be as valid as theirs. We understand that, even if tutorial.” Department of Computer Science, KU Leuven, 2015.
they cannot be reconciled, at least they may still agree on a [5] S. Brinkkemper, “Method Engineering: Engineering of Information
Systems Development Methods and Tools,” Inf. Softw. Technol., vol. 38,
common conceptual metamodel. We also plan to refine our no. 4, pp. 275–280, 1996.
metamodel by providing more examples of specific Work [6] B. Henderson-Sellers and J. Ralyté, “Situational Method Engineering:
Units, Producers and Work Products, aligned to the State-of-the-Art Review.,” J. Univers. Comput. Sci., vol. 16, no. 3, pp.
taxonomies usually employed in the field of method 424–478, 2010.
engineering (e.g. OPFRO), which demonstrate its applicability [7] C. Gonzalez-Perez and B. Henderson-Sellers, “A powertype-based
to further privacy engineering methodologies. metamodelling framework,” Softw. Syst. Model., vol. 5, no. 1, pp. 72–90,
2006.
It may also be the case that our proposed metamodel is only [8] ISO/IEC JTC 1/SC 27, “ISO/IEC 24744:2014. Software engineering --
Metamodel for development methodologies,” Geneva (CH), 2014.
adopted within reduced academic circles, and contributes to
[9] B. Henderson-Sellers and C. Gonzalez-Perez, “On the ease of extending
further fragmentation rather than preventing it. That is why we a powertype-based methodology metamodel,” in Meta modelling and
aim to submit it to active standardization efforts. It is the case ontologies : proceedings of the 2nd International Workshop on Meta-
that the ISO and the IEC have taken the same challenge as Modelling, WoMM 2006, October 12-13, 2006 in Karlsruhe, Germany,
well, by recently approving the work item (i.e. launching the 2006, pp. 11–25.
development of a standard) ISO/IEC AWI 27550 on Privacy [10] D. J. Solove, “Conceptualizing privacy,” California Law Review, vol.
90, no. 4. pp. 1087–1155, 2002.
Engineering. This standard will aim to provide guidelines on [11] H. Nissenbaum, “Privacy as contextual integrity,” Wash. L. Rev., pp.
how to engineer privacy in information systems considering 101–139, 2004.
different domains and under different development processes. [12] ISO/IEC JTC 1/SC 27, “Information technology -- Security techniques -
We aim at contributing our metamodel to this standard, whose - Privacy framework ISO/IEC 29100:2011,” Geneva (CH), 2011.
creation demonstrates the need to tackle the gap we are dealing [13] D. J. Solove, “A Taxonomy of Privacy,” Univ. PA. Law Rev., vol. 154,
no. 3, pp. 477–560, 2006.
with. Making it a de jure standard will foster its de facto [14] A. Pfitzmann and M. Hansen, “A terminology for talking about privacy
adoption. by data minimization: Anonymity, Unlinkability, Undetectability,
Unobservability, Pseudonymity, and Identity Management,” Tech. Univ.
The metamodel we have presented is the result from Dresden, pp. 1–98, 2010.
extracting common features from several methodologies we are [15] S. Petronio, Boundaries of Privacy: Dialectics of Disclosure. New York,
acquainted with. Here we have presented a specific validation New York, USA: State University of New York Press, 2002.
case that exemplifies it (LINDDUN), but it may be well [16] Regulation (EU) 2016/679 of the European Parliament and of the
applied to other methodologies. Not only the existence of a Council of 27 April 2016 on the protection of natural persons with
regard to the processing of personal data and on the free movement of
shared conceptual model is itself key to foster the advance of
such data, and repealing Directive 95/46/EC (General Da. European
the discipline; but also its modularity allows adapting it to Union: Official Journal of the European Union, L 119, pp. 1–88.
specific endeavors or constraints. Rather than aspiring to come [17] “privacypatterns.eu - collecting patterns for better privacy.” [Online].
up with a single catch-all privacy engineering methodology; Available: https://privacypatterns.eu/. [Accessed: 19-Feb-2017].
the modularity allows method engineers to create their own [18] J.-H. Hoepman, “Privacy Design Strategies,” in ICT Systems Security
methodologies. We conjecture that ultimately, if the approach and Privacy Protection SE - 38, vol. 428, N. Cuppens-Boulahia, F.
Cuppens, S. Jajodia, A. Abou El Kalam, and T. Sans, Eds. Springer
we propose succeeds, it will enable the integration of privacy Berlin Heidelberg, 2014, pp. 446–459.
engineering methodological elements with one another and [19] K. Wuyts, R. Scandariato, and W. Joosen, “LIND(D)UN privacy threat
within mainstream software and system development tree catalog.” Department of Computer Science, KU Leuven, 2014.
methodologies, and ultimately, will improve the privacy of the [20] E. Heil, “Q&A: Privacy engineers could hold the key,” TribLIVE.com,
products or projects developed according to methodologies 2012.
[21] “Privacy Engineering Careers-MSIT-Privacy Engineering - Carnegie
based on our metamodel —which is something yet to be Mellon University.” [Online]. Available:
proved in practice, so as to demonstrate the utility and http://privacy.cs.cmu.edu/careers/. [Accessed: 19-Feb-2017].
effectiveness of our approach. In any case, we expect other [22] G. Sindre and A. L. Opdahl, “Templates for Misuse Case Description,”
members from the community to discuss the metamodel and 7th Int. Work. Requir. Eng. Found. Softw. Qual. REFSQ 2001, vol. 6,
enrich it with their own contributions. pp. 125–136, 2001.