![](bg6.png)
Security Mechanisms: this criterion describes
how and through which security and privacy
mechanisms privacy can be expressed by the
particular approach. We identified two
characteristics:
▪ Information flow and access control: this
characteristic establishes privacy by
introducing concepts that restrict the
information flow or the access to information,
functions or system parts by imposing rights.
These approaches introduce concepts of
confidentiality in various ways and to different
degrees. The introduced concepts are used
either directly or can be used to express privacy
in a certain way. Examples are Chinese Wall
policy and confidentiality levels. The following
approaches contribute to this characteristic
[(Jürjens, 2002), (Heldal et al., 2004), (Goudalo
and Seret, 2008), (Simsons, 2007), (Fernandez-
Medina et al., 2004), (Zhang et al., 2006), (Sun,
et al., 2009), (Lai et al., 2008), (Accorsi and
Wonnemann, 2011), (Accorsi et al., 2015), (Li
et al., 2009), (Knorr, 2001), (Atluri and Huang,
2000), (Mülle et al., 2011)].
▪ General structures: approaches with these
characteristics use abstract structures to
express either several or a particular security
and privacy principle. For example, problem
frames used in (Hatebur and Heisel, 2010) give
the ability to express a problem and, through
this, express an actual security principle.
Another example, common in the security area,
is policies. We identified the following
approaches contributing to this characteristic:
[(Jutla et al., 2013), (Basso et al., 2015),
(Hatebur and Heisel, 2010), (Mouheb et al.,
2009), (Huang and Kirchner, 2013), (Mixia et
al., 2005), (Akbarzadeh and Azgomi, 2010),
(Bouroulet et al., 2008), (Henry et al., 2010),
(Atluri and Huang, 2000)].
Each approach is assigned to one characteristic.
The approaches we reviewed focus either on
confidentiality to express privacy or on introducing
various other structures through which privacy can be
expressed. The first are grouped under the
characteristic ‘information flow and access control’
and the latter ones under the characteristic ‘general
structures’. We determined that nearly half of the
reviewed architecture oriented and business process
oriented approaches contribute to the first
characteristic. They all introduce elements to model
confidentiality. Some of them use confidentiality
mechanisms to establish privacy in a certain way
[(Fernandez-Medina et al., 2004), (Zhang et al.,
2006), (Sun et al., 2009), (Lai et al., 2008), (Accorsi
and Wonnemann, 2011), (Accorsi et al., 2015), (Li et
al., 2009), (Knorr, 2001)]. The others only introduce
modelling elements for confidentiality and not
directly for the purpose of privacy [(Jürjens, 2002),
(Heldal et al., 2004), (Goudalo and Seret, 2008),
(Simsons, 2007), (Mülle et al., 2011)]. The other half
of the reviewed approaches utilises various other
mechanisms to model privacy. [(Julta et al., 2013)]
introduce new structures like super containers and
problem frames to express privacy. Some others use
policies [(Basso et al., 2015), (Huang and Kirchner,
2013)].
Different views: this criterion describes the view
of the model for which the approach is developed. As
there are various stakeholders with different concerns
to express, different views arise that can be
specialised for the specific needs of a stakeholder.
Typical examples from the field of security are the
attacker view and security specialist view. While the
attacker view introduces model elements showing
how the attacker could intrude into the system, the
security specialist view would highlight the security
measures in place.
The criterion ‘different views’ divides the
approaches according to their use by stakeholders.
Common views are:
• Attacker view: models the attacker with the
attacks, threats, and vulnerabilities of a
system, or analyses the given model for flaws
in the information flow [(Jürjens, 2002),
(Akbarzadeh and Azgomi, 2010), (Bouroulet
et al., 2008), (Henry et al., 2010), (Accorsi and
Wonnemann, 2011), (Accorsi et al., 2015), (Li
et al., 2009), (Atluri and Huang, 2000)].
• Requirements & Implementation view:
introduces elements to express requirements
pertaining to security and privacy aspects and
elements, which model security and privacy
solutions [(Julta et al., 2013), (Basso et al.,
2015), (Heldal et al., 2004), (Goudalo and
Seret, 2008), (Hatebur and Heisel, 2010),
(Simsons, 2007), (Mouheb et al., 2009),
(Fernandez-Medina et al., 2004), (Mixia et al.,
2005), (Zhang et al., 2006), (Sun et al., 2009),
(Lai et al., 2008), (Atluri and Huang, 1996),
(Atluri and Huang, 2000), (Mülle et al.,
2011)].
• Verification view: allows users to check
whether a model fulfils certain requirements
by checking them against the model. This is
realised, for example, with constraints, which
are checked for correct implementation or the
Identifying Needs for a Holistic Modelling Approach to Privacy Aspects in Enterprise Software Systems
79