9) and misuse cases in order to collect

9)  LINDDUN:
LINDDUN 28 was first introduced in 2010 by Deng et al. as a privacy threat
analysis framework in order to support the elicitation and fulfillment of
privacy requirements in software-based systems. According to the LINDDUN
methodology, after designing a data flow diagram (DFD) of the system, privacy
threats are related to the listed elements of the DFD. Threats in LINDDUN are
categorized in seven types: Linkability, Identifiability, Non-repudiation, Detectability,
Information Disclosure, Content Unawareness, Policy and consent Non-compliance.
The method uses privacy threats trees and misuse cases in order to collect the
threat scenarios of the system. Trough these misuse cases, privacy requirements
can be extracted. Also, LINDDUN supports the prioritization and validation of
privacy threat through the process of risk-assessment, before eliciting the
final privacy requirements and before selecting the appropriate
privacy-enhancing technologies. The authors of LINDDUN also map
privacy-enhancing technologies to each privacy requirement in order to support
system designers to select the appropriate techniques that satisfy privacy
requirements.

 

10) 
SQUARE for privacy: After noting that, apart from security,
privacy needs more attention during developing soft-ware systems, the authors
of SQUARE methodology 14 adapted their approach in order to support the
elicitation of privacy requirements at the early stages of software
develop-ment process 29. The extended framework includes the same steps as
the original SQUARE method in conjunction with the Privacy Requirements
Elicitation Technique (PRET) 30, a technique that supports the elicitation
and prioritization of privacy requirements. This technique uses a database of
privacy requirements based on privacy laws and regulations. However, the
authors note that the database needs to be updated as the laws change and
conclude that a new integrated tool is needed in order to support the
elicitation of security and privacy requirements in parallel.

 

11)
PriS: PriS 31 has been introduced by Kalloniatis et al. as a
goal-oriented approach in order to integrate privacy requirements into the
system design process. The main idea of this methodology is that privacy
requirements are considered as organizational goals and adopts the use of
privacy-process patterns in order to describe the impact of privacy goals to
the affected organizational processes, to model the privacy-related
organizational processes and to support the selection of the system
architecture that best satisfies these processes. Thus, the authors of PriS
cover the gap between system design and implementation phase. According to
PriS, the identification of privacy goals is based on eight privacy concepts
namely authentication, authorization, identification, data protection,
anonymity, pseudonymity, unlinkability and unobservability.

 

12)
Secure Tropos and PriS metamodel: According to the above
methodologies, most of the approaches in requirements engineering tend to
consider security and privacy separately or consider privacy as a subset of
security. However, a number of research efforts 6-7 support that security
and privacy are two different concepts that have to be examined separately but
under the same unified framework. Under these circumstances, Islam et al. 9
introduced a model-based process that considers security and privacy concepts
in parallel at the early stage of system analysis. This process integrates two
different engi-neering methods. Secure Tropos is used as the main method in
order to identify and analyse security requirements of the system under
consideration. However, as privacy concepts are not considered through this
method, Secure Tropos is extended integrating the PriS solution. Thus, security
and privacy requirements can be identified and analysed in order
to meet the goals but also the appropriate architecture and implementation
technique can be selected in order for privacy goals to be satisfied.

 

B. A Comparison of Security
and Privacy Requirements En-gineering Methods

 

Many different approaches in
the area of security and privacy requirements engineering have been presented
in the previous section. Table 1 summarizes and compares the afore-mentioned
methodologies. A table entry that is labeled with Y or N means that the
relevant criterion is considered or not by the relevant method.

 

A first remark is that most
methods consider explicitly security or privacy requirements in order to design
secure systems. On the other hand, the extension of KAOS method considers
privacy as a subset of security. However, as privacy has separate aspects than
security and a security incident might have a serious impact in user’s privacy
and vice versa, security and privacy requirements have to be examined in
parallel under the same framework in order to design secure systems6-8. The
meta-model presented by Islam et al. 9 is able to support security and
privacy requirements as it combines concepts from Secure Tropos and PriS
methodologies that deal with security and privacy issues separately.

 

It is worth noting that all
the aforementioned method-ologies can be applied at the early stage of system
analysis and design as a late reconsideration of security and privacy
requirements can be extremely costly and time-consuming. LINDDUN, PriS
methodology and therefore Secure Tropos and PriS metamodel include steps in
order to fill the gap between system design and implementation stage and to
sup-port developers to select the most appropriate implementation technique.

 

Each methodology has been
build by using a different approach. MOSRE, Secure Tropos, KAOS, PriS and the
Secure Tropos and PriS meta-model have been introduced as goal-oriented
methodologies as security and privacy requirements are considered as
organizational goals that have to be satisfied by the system into
consideration. On the other hand, SQUARE methodology and SQUARE extension for
integrating privacy requirements have been based on risk analysis results. It
is worth noting that even if SQUARE method supports the identification of
system threats and the corresponding vulner-abilities, the assets of the system
that have to be secured are not considered by the method. On the contrary, the
proposed methods by Ahmed et al. 17, MOSRE, SREF and SREP support risk
analysis on business assets in order to elicit security requirements. Additionally,
as many methodologies have integrated steps in order to support threat
identification, SREP and LINDDUN put threat analysis in the center of their
attention in order to elicit security or privacy requirements. SREF and
presSure have been introduced as problem-based methods as the analysis and the
elicitation of security require-ments comes from the analysis of problem
diagrams.

 

Regarding the
categorization/prioritization criterion, it could be noticed that for many
methods this step is a log-ical extension of a risk analysis process. A
categorization and prioritization of security or privacy requirements is an
important aspect of many approaches, as, during this process, system designers
have to decide if the implementation cost of a requirement is comparable with
the value of the secured

asset. SQUARE, MOSRE, SREP, LINDDUN and PriS sup-port
categorization/prioritization of requirements. Additionally, most of the
approaches, SQUARE, MOSRE, SREF, SREP, PriS and the Secure Tropos with PriS
metamodel include steps for requirements inspection. Finally, MOSRE, Secure
Tropos, PriS and Secure Tropos with PriS meta-model examine the existence of
any conflicts between requirements and security or privacy goals.

 

Table 2 presents the
security and privacy requirements that each method aspires to cover. Where is
labeled, that means that the author of the method does not specify the
requirements.