Requirements Eng (2010) 15:7–40

DOI 10.1007/s00766-009-0092-x

SPECIAL ISSUE - SECURITY REQUIREMENTS ENGINEERING

A comparison of security requirements engineering methods

Benjamin Fabian • Seda Gürses • Maritta Heisel •

Thomas Santen • Holger Schmidt

Received: 30 October 2008 / Accepted: 4 November 2009 / Published online: 26 November 2009

Springer-Verlag London Limited 2009

Abstract This paper presents a conceptual framework for Keywords Security requirement

security engineering, with a strong focus on security Security requirement engineering
Comparison

requirements elicitation and analysis. This conceptual Framework for security requirement engineering
framework establishes a clear-cut vocabulary and makes
explicit the interrelations between the different concepts and
notions used in security engineering. Further, we apply our 1 Introduction
conceptual framework to compare and evaluate current
security requirements engineering approaches, such as the The long-standing credo of requirements engineering
Common Criteria, Secure Tropos, SREP, MSRA, as well as reads: ‘‘If you don’t know what you want, it’s hard to do it
methods based on UML and problem frames. We review right.’’ This statement has particular significance for
these methods and assess them according to different crite- security requirements, because unless we know what to
ria, such as the general approach and scope of the method, its secure, against whom, and to what extent, it is obviously
validation, and quality assurance capabilities. Finally, we very hard to construct a secure system or to make a sub-
discuss how these methods are related to the conceptual stantial statement about its security.
framework and to one another. Today, the established way for describing security
requirements, as reflected for example in the Common Cri-
teria [1], an international standard to achieve comparability
of independent IT security evaluations, starts with a
description of the functional requirements, the system
B. Fabian architecture, and its working environment. It then continues
Institute of Information Systems, Humboldt-Universität zu with a threat analysis that describes envisaged threats, pos-
Berlin, Berlin, Germany sibly followed by an evaluation of the severity of threats
e-mail: [email protected]
through a risk analysis and ends with the definition of a
S. Gürses security policy.
ESAT/COSIC, K.U. Leuven, Leuven-Heverlee, Belgium This view on security requirements gives rise to the
e-mail: [email protected] conjecture that a proper security requirements elicitation is
not part of the best practice, today. We present two further
M. Heisel
H. Schmidt (&)
Software Engineering, University of Duisburg-Essen, observations supporting this judgment. The first observa-
Duisburg, Germany tion concerns the current process of establishing a security
e-mail: [email protected] policy, which is supposed to document security require-
M. Heisel ments. The security policy is derived from a threat analysis
e-mail: [email protected] whose subject necessarily is a structural description—an
architecture or a design—of the technical system to be
T. Santen
European Microsoft Innovation Center, Aachen, Germany built. Without information about the intended technical
e-mail: [email protected] solution, which will implement the functional requirements,

123
8 Requirements Eng (2010) 15:7–40

there is no handle for a threat analysis to identify possible Furthermore, the Common Criteria, and most other
targets of an attack. Thus, the security policy logically relies suggestions for a security requirements process, identify
on the design of the system. the stakeholder with the owner of the asset and assign the
The second observation concerns the content and role of responsibility to protect the asset to its owner. As a result,
a security policy, which apparently has flavors of require- the owner of the asset must also be the owner of the IT
ments and design to it: system. How could he or she otherwise assume responsi-
bility for protecting the asset?
• ‘‘A security policy is a statement of what is, and what is
But nowadays, the world is not as simple as that: in
not, allowed’’ [2, p. 9];
civil systems, in which we are interested, there are many
• ‘‘for us, security boils down to enforcing a policy that
more stakeholders who have an interest in an asset than
describes rules for accessing resources’’ [3, p. 14];
just the owner of the IT system. More often than not,
• ‘‘the security policy of a system or an organizational
stakeholders have conflicting interests with respect to
unit fixes the set of technical and organizational rules,
assets. The paradigm of multilateral security [7]
rules of conduct, responsibilities, and roles, as well
acknowledges this fact. Multilateral security contradicts
as measures to achieve the desired protection goals’’
the traditional view, which assumes that there is a
[4, Def. 1.14, in German]; but also:
‘‘trusted tribe’’ who has a homogeneous set of security
• ‘‘based on the risk analysis, the security requirements of
requirements against the rest of the world. But this tra-
the system to be built need to be derived and the
ditional assumption still heavily influences common
security policy needs to be fixed’’ [4, p. 205, in
approaches toward security engineering.
German].
To take multilateral security seriously in security
• ‘‘security policy is a [...] policy that mandates system-
requirements engineering (SRE), a requirements engi-
specific [...] criteria for security [...]’’ [5, p. 34]
neering process must support engineers in identifying
In the terminology of the Common Criteria, a security security goals of the security stakeholders, and in resolving
policy refers to organizational requirements restricting the conflicts among them—and in the reconciliation of security
environment of the technical system. The security goals and other, notably functional, requirements. This
requirements are documented in the security objectives, process must establish a coherent set of security require-
which ‘‘counter the identified threats and address identified ments for the entire system, which is complete and con-
organisational security policies and assumptions’’ [1, Part sistent within itself and with the other kinds of
1, p. 29], and the IT security requirements, which ‘‘are the requirements that are relevant for the system. All this must
refinement of the security objectives into a set of security be done before the design of the system is fixed, because
requirements for the TOE [Target of Evaluation] and the security requirements have an influence on the func-
security requirements for the environment which, if met, tional requirements, which in turn (hopefully) determine
will ensure that the TOE can meet its security objectives’’ the design of the system. Only after all kinds of require-
[1, Part 1, p. 29]. ments have been fixed, threats against assets can be iden-
In those views, security requirements are consequences tified, and countermeasures be designed.
of threats to the system, which can only be derived from Having thus motivated the need for an explicit
the design of the system. But what makes a threat a threat? requirements engineering process for security, this paper
There must be an adversary, i.e. someone or something contains two contributions. First, we establish a concep-
who threatens, and something the threat is directed at—the tual framework for security requirements engineering in
asset, which is a piece of information or a resource. There Sect. 2, followed by Sect. 3 on related work. This con-
also must be someone who values that information or ceptual framework contains all notions we deem relevant
resource and wants it to be protected: the security stake- for SRE, as well as their interrelationships. Second, in
holder. But most importantly, the security goal that the Sects. 4–9, we give descriptions of currently available
stakeholder has with respect to the asset must be described methods for SRE and relate these methods to our con-
in detail. Just to state that the confidentiality, integrity, or ceptual framework. However, not only currently available
availability of the information or resource must be pro- methods can be assessed and compared using our
tected is as useful a ‘‘requirement’’ as the often cited pro- framework but also helps to classify newly developed
totype of a would-be non-functional requirement: ‘‘The approaches to SRE. Already today, there is a wide variety
system shall have a simple and comprehensible architec- of methods covering different aspects of SRE (see Sect.
ture; its usage must be intuitive’’ [6, p. 274, in German]. 10). However, important aspects of SRE deserve further
Those ‘‘requirements’’ are not verifiable. It is impossible to research, especially those concerning a multilateral view
set up criteria under which a system meets those require- and conflict resolution. These issues are discussed in the
ments, because they lack information and are imprecise. final section.

123
Requirements Eng (2010) 15:7–40 9

Table 1 Distribution of SRE papers to years and did not consider articles that were solely about risk
1999 2000 2001 2002 2003 2004 2005 2006 2007 2008
management or security engineering. Last, we picked those
methods which were described and validated in multiple
1 1 5 6 9 13 14 28 11 6 papers. Hence, we did not consider one-shot articles on
security requirements engineering methods.
Figures 1 and 2 illustrate the relationships between the
foundational concepts of security requirements engineer-
2 Conceptual framework ing. The concepts are denoted by boxes, which are related
by different kinds of lines. Larger boxes make up concept
This section introduces a conceptual framework for secu- groups. A simple line denotes a relationship between
rity requirements engineering. This conceptual framework concepts that belong to the same group. A solid arrow
(CF) is not an attempt to suggest a universal method that denotes a logical dependency between concepts or concept
composes existing SRE approaches. In contrast, it groups, pointing from an antecedent to a consequent.
describes the central concepts of SRE and their Often, this dependency is a concretization, leading from a
relationships. more abstract to a more concrete concept. Note that the
The CF should serve as a guideline for comparing dif- term concretization constitutes a generalization of the
ferent SRE methods, and is itself the result of an iterative term operationalization. We use concretization to
process. It started out from reconciling Zave and Jackson’s describe a refinement step, i.e., a concept becomes more
influential terminology [8] with basic concepts from detailed; a similar, but restricted sense is sometimes used in
security engineering. Then, we conducted a broader survey requirements engineering for the term operationalization,
on SRE methods (see Sect. 3 for a description of the lit- e.g., turning goals into an operation model (KAOS,
erature survey), and refined the CF iteratively to cover new GBRAM), which can be verified through testing or formal
concepts encountered during this process. The SRE meth- verification.
ods were analyzed again for the survey in Sects. 4–9, based In contrast, there is also another established meaning of
on the final version of the CF. operationalization (cf. [9–11]), i.e., to express the trans-
The utility of the framework lies in the uniform basis it formation of non-functional requirements into functional
provides to elaborate the specifics of the SRE methods that ones. Typically, in both cases, the operationalization of
we investigate in the sections to follow. In particular, requirements generates a specification (see Sect. 2.4) or the
mapping the diverse nomenclatures of different methods to initial system design elements. The term concretization in
the concepts that the framework describes eases the com- our sense can be applied to every refinement step.
parison of the methods. Similar surveys of security The solid arrows are labeled when they refer to addi-
requirements engineering concepts do exist, which we tional activities in the given dependency such as recon-
discuss in Sect. 3. ciliation or validation of the requirements. The dashed
The scope of the survey was developed following a arrow in Fig. 1 concerns the fulfillment of system
literature review for which we queried google scholar1, requirements by the conjunction of specification, assump-
IEEE Explore2 and Citeseer3. We also consulted the pro- tions, and facts, which is discussed in Sect. 2.4 below.
grams of the International Requirements Engineering In general, none of the arrows should imply a temporal
Conference.4 After duplicates—i.e., articles with the same order of requirements engineering activities. It is under-
title and similar content in different outlets—were stood that all activities to elaborate the different aspects of
removed, we obtained 94 publications that matched our security requirements take place throughout the entire
‘‘security requirement’’ queries and in fact were related to development process, though with differing intensities.
methods for SRE. In the following, we describe the conceptual framework
The distribution of the papers according to years are depicted in Figs. 1 and 2 in detail.
given in Table 1. In order to limit the scope of the survey,
we included only those articles which had a fully devel- 2.1 A system is a machine in its environment
oped method for security requirements engineering. We put
the emphasis on software engineering-oriented approaches Using Zave’s and Jackson’s terminology [8], a system
consists of a machine in its environment. The machine is
the technical IT system that is to be constructed and that
1
http://www.scholar.google.com communicates with its environment. Adopting a holistic
2
http://www.ieeexplore.ieee.org view, we consider security to be a system property. Secu-
3
http://www.citeseer.ist.psu.edu rity can only be regarded as a characteristic of a system. It
4
http://www.re09.org is not a characteristic of the machine alone.

123
10 Requirements Eng (2010) 15:7–40

Stakeholder View 1 Stakeholder View n

Stakeholder View 1 ... Stakeholder View 1 ... Security

Goals
Asset ... Security
Goals
Asset
Stakeholder View n Stakeholder View n

Non-functional
Functional Goals
Goals

Stakeholder S1 Stakeholder Sn

Functional Non-functional
Requirements Requirements
Information Information

Security Counter- Security Counter-

Requirement R1 stakeholder Requirement Rn stakeholder

Circumstances Circumstances

Reconciliation between Stakeholders Reconciliation between Stakeholders

Functional Non-functional
Security ... Security
Requirement R'1 Requirement R'n
System System
Requirements Requirements Security
System Requirements

Reconciliation of Interacting System Requirements

Functional Non-functional Security

Requirements Requirements Requirements

System Requirements (consistent)

Fulfillment
AND

Domain Knowledge

Specification
(Requirements the Machine can fulfill) Assumptions Facts

Assumptions Facts
Design of the Machine
(Design Level) (Design Level)

Facts
Implementation of the Machine
(Implementation
(incl. Deployment & Configuration)
Level)

(Organizational)
Procedures &
Processes

Use

Note: An arrow primarily denotes a concretization and logical dependancy between concepts,
not necessarily a temporal succession of actual process steps.

Fig. 1 Conceptual framework for SRE

123
Requirements Eng (2010) 15:7–40 11

High
Goal

Requirement Only applicable to

"high-level" Security Properties

Resource
System
Stakeholder
Requirement

object requires suffers subject to

of
Specification

Level of
Security Property
Abstraction
{ Security Property
violation of
implies (Potential) Loss
constitutes
Risk

Assumption reduced
potentially
violated by by

mitigated by
Vulnerability Countermeasure
Design Property

actually potentially
exploited by exploited by

Implementation
Property realizes
Attack Threat

actually potentially
Usage initiated by
initiated by
Low Property

Counter-
Attacker Threat Agent
Stakeholder

Fig. 2 Security concepts for SRE

2.2 Stakeholder views Stakeholders can express security concerns at different

levels of detail. Therefore, we distinguish security goals
A stakeholder is an individual, a group, or an organization (abstract) from security requirements (more detailed)—
that has an interest in the system under construction. A with the caveat that such a distinction is not readily
stakeholder view describes the requirements of a particular established in the requirements engineering community,
stakeholder. The stakeholders may express different types and probably cannot be made completely precise due to
of requirements. vagueness of subjective intuitions and semantic intricacies
For the purpose of our paper, we assume an intuitive of natural languages. We give a working description of the
distinction between functional (‘‘what the system does’’ differences between security goals and security require-
[12, p. 483]) and non-functional requirements, ‘‘global ments in the following.
requirements on its development or operational costs, per- A stakeholder’s security goal expresses his or her
formance, reliability, maintainability, portability, robust- security concerns towards an asset. The Common Criteria
ness and the like’’ [12 p. 483]. This intuitive dichotomy is [1] define an asset as an ‘‘entity that the owner of the target
also part of established (rather practical) guidelines on the of evaluation places value upon’’. Similarly, ISO/IEC FDIS
subject [13, p. 119]. However, we have to acknowledge that 17799:2005 [16] and ISO/IEC 13335-1:2004 [17] consider
this distinction is heavily debated in the requirements ‘‘anything that has value to the organization’’ an asset.
engineering community because of terminological and Thus, an asset is any entity that a stakeholder puts a value
conceptual difficulties (see [14] for a comparison of dif- upon with respect to security. We prefer this definition of
ferent interpretations), and new categories have been pro- an asset over more technical ones that emphasize the value
posed, see e.g. [14, 15]. We consider security requirements of a technical system to its owner, such as the definition
to be a part of the non-functional-requirements. used in NIST SP 800-26 [18], which considers a ‘‘major
The top row of Fig. 1 distinguishes security stakeholder application, general support system, high impact program,
views from views concerned with functional requirements or physical plant, mission critical system, or a logically
non-functional requirements other than security requirements. related group of systems’’ an asset. During the security

123
12 Requirements Eng (2010) 15:7–40

requirements engineering process, assets will be concret- adversary who tries to attack the system. The concept of an
ized by more detailed concepts, which we subsume under adversary only becomes relevant in the context of a threat
the term resource, see Sect. 2.5. analysis, which we discuss in Sect. 2.5.
Security goals are traditionally classified into integrity, A third important aspect of a security requirement
confidentiality, and availability goals. Very influential concerns the circumstances in which it must be satisfied.
examples are the following ISO/IEC 13335-1:2004 These describe application conditions of functionality,
definitions: temporal, or spatial aspects, the social relationships
between stakeholders—in general, the ‘‘context’’ to which
• Integrity is the property of safeguarding the accuracy
the requirement refers.5
and completeness of assets.
In the banking example, a customer’s security require-
• Confidentiality is the property that information is not
ment states that the exact balance of his or her account
made available or disclosed to unauthorized individu-
must not become known to arbitrary bank employees or
als, entities, or processes.
other customers. Here, the information is the account bal-
• Availability is the property of being accessible and
ance, and the counter-stakeholders are bank employees and
usable upon demand by an authorized entity.
other customers. The circumstances describe, e.g., that an
This so-called CIA triad is sometimes extended by authorized bank employee who needs to know the balance
concepts such as accountability, non-repudiation, and for a specific purpose may nevertheless get to know it, or
authentication. In this paper, however, we subsume these that the balance must be kept confidential for at least
further concepts under those of the CIA triad to streamline 50 years after the account has been closed.
our presentation. For example, accountability and non-
repudiation can be classified as integrity goals, authenti- 2.3 System requirements
cation as a design mechanism to achieve confidentiality or
integrity, and anonymity or unobservability may be sub- Multiple requirements are interdependent and interact with
sumed under confidentiality goals. We emphasize that our one another. These interactions may be positive, negative
conceptual framework could also be applied to different (conflicts), or result from conflicts during implementation
taxonomies and hierarchies of security goals. [20]. Analysis and management of requirements interac-
Independently of their taxonomy, security goals are tions is a necessary and fruitful part of requirements
defined as very general statements about the security of an engineering [20]. Although analysis of positive interactions
asset. For example, the customers of a bank may have the may be useful in prioritizing requirements or reiterations in
confidentiality goal that their financial situation remains requirements analysis, focus in requirements interaction
confidential. The public, represented by a government has been on negative interaction, or simply requirements
agency, may have the integrity goal that electronic finan- conflicts.
cial transactions do not change the total amount of circu- Conflicts may arise for a number of reasons at different
lating money. Security goals are therefore too vague to be stages of requirements engineering. The views of different
considered verifiable requirements. stakeholders are in general inconsistent, e.g., because they
Security requirements capture security goals in more have different and contradicting requirements. Inconsistent
detail. A security requirement refines one or more security requirements are the starting point for deriving useful
goals. It refers to a particular piece of information or ser- information that might otherwise go unnoticed, cf. [21] (as
vice that explicates the meaning of the asset it concretizes cited by [20]). Inconsistencies resulting from differing
in the context of the system under construction. This views have been addressed by view-point-oriented
information itself does in general not directly correspond to requirements engineering methods [22, 23]. Conflict of
data that is processed by the machine, e.g., the entries in a interest, the case in which an individual’s personal interest
database. In turn, it describes a more abstract concept, conflicts with the requirements assigned to their roles is
which the more detailed data will concretize. Concretiza- addressed by Giorgini et al. [24].
tion of goals to requirements to specifications is accom-
plished in parallel to the concretization of resources, for 5
We propose to avoid the use of ‘‘context’’, because it is an
example, from assets to information to data.
overloaded term within software engineering. Often in requirements
A security requirement also indicates the counter- engineering context is used to refer to the specific environment in
stakeholder against whom the requirement is directed. This which the machine is situated [19]. Context has also increasingly
is particularly important for confidentiality requirements, become a concept in newer branches of computer science. One
example being ‘‘context-aware systems’’ modeling the properties of a
where the counter-stakeholder is the party who must not
given context, which may or may not be the physical environment.
get to know the information to which the requirement Context is then used to adapt the machine or the environment to the
refers. A counter-stakeholder is not necessarily an users’ needs.

123
Requirements Eng (2010) 15:7–40 13

Even when the differences between stakeholders and the unconditionally. It can provide security mechanisms that
roles that are assigned to them are consolidated, the satis- contribute to system security, but cannot enforce system
faction of one requirement can aid or detract from the security on its own.
satisfaction of another, and the environment can increase or In the example, the specification will prescribe access
reduce requirement satisfaction. These kinds of conflicts control mechanisms to prevent unauthorized access to bank
have been addressed in goal-oriented requirements analysis account information. However, access control can only
[25] and in non-functional requirements engineering (NFR) contribute to achieving the requirement that other cus-
[12]. tomers do not get to know the balance of an account. It is
In the security community, the integration of stake- furthermore necessary to know that there is no physical
holder views has lead to the paradigm of multilateral access to the servers of the bank (a fact), and to assume that
security [7], which acknowledges that different stake- no customer can collect information about all bank trans-
holders have different, but equally justified security goals. fers related to a particular account and thereby restrict the
Similarly, different types of requirements may interact. probable balance of that account beyond the limits that the
Therefore, it is necessary to consider all views for each security requirement permits.
type of requirement, i.e., functional and non-functional At the design level, not only the design of the machine
requirements, to come up with a consistent set of system must refine the specification, but also additional facts and
requirements, shown at the center of Fig. 1. The figure assumptions need to be considered. Here, trust is relevant.
shows two steps of requirements reconciliation: in the first, Often, stakeholders cannot enforce their requirements
the stakeholder views for requirements of the same classes alone but need to delegate tasks to other actors in the
are reconciled. In particular, the security stakeholder views environment of the machine. Consequently, they need to
are reconciled to a set of security system requirements. In trust those actors to accomplish the tasks in a secure way.
the second step, interacting requirements of different types For example, if the machine design stipulates that admin-
are reconciled to come up with a consistent set of system istrators can override access control mechanisms, then the
requirements that contains requirements of all types. ordinary users necessarily need to trust system adminis-
The reconciliation process may require stakeholders to trators to only use their rights securely.
compromise on their initial requirements. For example, the At the implementation level, assumptions are refined to
requirement of keeping the balance of a bank account organizational procedures and processes that prescribe how
confidential against all other customers contradicts the fact the implemented machine must be used in order to achieve
that a bank transfer (which would be described in the security.
functional requirements) necessarily leaks information
about the account of which the transfered amount is 2.5 Threat analysis concepts and the concretization
withdrawn. Therefore, the customer may relax the confi- process
dentiality requirement and be content with restricting the
precision with which other customers can estimate the Figure 1 describes security requirements engineering pri-
balance. marily from a software engineering perspective. On the
other hand, the right-hand side of Fig. 2 presents a com-
2.4 Specification and domain knowledge plementary view, emphasizing concepts from security
engineering and management, such as threats and risks, see
The system requirements describe properties the system for example, the Common Criteria [1] and Fig. 12. Those
must have after the machine has been built. They do not threat or risk analysis concepts are used by some of the
prescribe how the machine or the environment contribute SRE approaches discussed later in this paper (see Sect. 8).
to achieve such a system. Therefore, the system require- From a threat analysis perspective, a stakeholder
ments are refined into a machine specification, as well as requires a security property to hold for a resource, whose
domain knowledge, consisting of facts and assumptions violation implies a potential loss to the stakeholder. This
about the environment [8, 26–28]. Conjoined, those three violation can be caused by a vulnerability, which could
sets of properties (specification, facts, assumptions) must potentially be exploited by a threat initiated by a threat
be sufficient to satisfy the system requirements, indicated agent. An attack actually exploits a vulnerability, and is
by the dashed arrow in Fig. 1. initiated by an attacker. Attackers are a subset of threat
The specification constrains the machine to be built. agents (often also called adversaries), which in turn con-
The facts and assumptions describe or constrain the stitute a subset of the counter-stakeholders discussed in
environment of the machine. This distinction is particu- Sect. 2.2. The potential loss constitutes a risk for the
larly important for security requirements. A machine stakeholder, but can be reduced by countermeasures miti-
usually cannot satisfy security requirements gating the vulnerability.

123
14 Requirements Eng (2010) 15:7–40

How does this perspective relate to the concretization contributes. Therefore, the threats and countermeasures for
process of SRE depicted in Fig. 1? The main insight refers low-level properties cannot be evaluated per se, but need to
to the nature of the security property, which can embody be related to the corresponding high-level properties. In
various abstraction levels. The left-hand side of Fig. 2 general, the exact relationships between security properties
shows examples of security properties, ordered by their at different levels of abstraction must be maintained; it
level of abstraction. Corresponding to the concretization should also be established how low-level threats affect
process described in Fig. 1, the highly abstract stakeholder higher-level security goals or requirements [29].
goals become more concrete during the requirements
engineering process. A goal is a security property of an
asset, in which the stakeholder is interested. Goals get more 3 Related work
detailed by transforming them into requirements, and from
there to system requirements. Those get more concrete by Our conceptual framework is comparable to the work of
the conjunction of specification and assumptions (sup- Moffett et al. [30] that defines core security requirements
ported by facts). A security specification is a property that artifacts. Their framework is intended to eventually derive
the machine must satisfy in order to achieve a security an SRE process rather then to facilitate the comparison of
requirement. An assumption is a security property different security requirements engineering methods.
addressing the same level of abstraction as a specification. Hence, the authors use certain definitions of concepts while
A fact itself, however, is not a security property, because deliberately leaving others out, and define dependencies
facts are true without any precondition (otherwise, they such that concrete process steps can be stabilized.
would be assumptions). This process leads to design, In the framework of Moffet et al., an artefact is defined
implementation, and usage properties that are the most as any object created as part of the process of system
concrete representations of the abstract goals. development: starting with documents and prototypes all
At the same time, the resource, to which the security the way down to the working system itself. A distinction is
property refers, becomes less abstract during the process. made between core and supportive artifacts. Core
As Fig. 1 shows, the resource of a security goal is an asset, requirements engineering artifacts consist of goals,
and the resource of a security requirement is a piece of requirements, and the components and structure of the
information. The resource of a low-level property such as a system, while core security requirements engineering arti-
design property may be a data record or a communication facts consist of assets, threats, and control principles.
protocol between components of the machine. Our understanding of functional and security goals
An important point is that all abstraction levels of overlaps with that of Moffet et al. In comparison, the
security properties can be subject to threats imposed by definition of security requirements as constraints is too
threat agents. This allows for an integration of iterative restricted for our purpose: our objective is to keep the
threat analysis processes into the likewise iterative pro- conceptual framework general enough to account for other
cesses of requirements engineering. At multiple concreti- approaches and hence enable comparison between the
zation levels, threat analysis processes could produce different methods.
insights for the requirements engineering process, for The control principles mentioned by the authors, e.g.,
example, if countermeasures are integrated into a new separation of duties or principle of least privilege, we
version of functional requirements. interpret as design principles rather than as core security
However, the consequences of threats, e.g. a potential requirements artifacts. We do have a comparable ‘‘(orga-
loss, and the effects of countermeasures on the security of nizational) procedures and processes’’ concept (see Fig. 1)
the system cannot be evaluated uniformly for all abstraction to accommodate some of the control principles. We agree
levels of security properties. For example, a stakeholder can that considering organizational principles from the begin-
assign a potential loss to a security goal or a security ning may be useful, as suggested by the authors and also by
requirement, and thus (quantitatively or qualitatively) [11, 31], if an organizational setting is the starting point of
express the value of that security property. To assign a loss analysis.
to security properties at a high level of abstraction can be The conceptual framework is also similar to the taxonomy
useful to justify compromises when reconciling conflicting provided by Firesmith [5], which is based on [30]. We use
requirements. However, it is hardly possible to directly this taxonomy as a comparative model for the main security
assign a loss to a security property of the machine or the concepts in our conceptual framework. Note that [5] actually
environment at a lower level of abstraction. The conse- concludes with an information model of defensibility engi-
quences of violating such a property for the security of the neering—including safety, security, and survivability qual-
system as a whole cannot be determined without knowing to ity factors. None of the methodologies that we study conflate
what high-level security properties a low-level property these three fields. Our focus hence remains on security

123
Requirements Eng (2010) 15:7–40 15

engineering, and we, therefore, compare our conceptual framework. Nonetheless, these are not always one-to-one
framework to the ‘‘information model for security engi- correspondences. In Table 2, we compare the concepts in
neering’’ given in the same paper. In our conceptual frame- the ‘‘information model’’ and the concepts in our concep-
work, other ‘‘quality factors’’ besides security are subsumed tual framework. If we have differing definitions for the
under the title other ‘‘non-functional requirements’’. We note concepts these are mentioned in the table.
this as an important area to explore in future research. Our concepts stem from literature analysis of terminol-
The conceptual framework is different from the taxon- ogy as used in different security standards, security
omy in [5], since it is not only about static relationships, but requirements engineering methods, and the occasional need
also includes references to reconciliation or validation to emphasize the differences in meaning between our
activities that need to be executed to move from one concept concepts and existing security concepts. For example,
to the other. At the same time, since the conceptual frame- although the importance of the different views of the
work is not a universal process model for SRE, the activities stakeholders is mentioned in [5], the information models
can occur in different orders throughout the development never include stakeholders. People in the information
process. The emphasized activities and the order in which models only appear as those who may be subject to harm.
they are executed is likely to depend on the emphasis of the In our CF, we emphasize multilaterality and hence point to
chosen method on security engineering (driven by assets and the difficulty of determining what should count as an asset,
risks) or software engineering (driven by stakeholder needs and of what value it is to whom.
and stepwise development). The dependencies can also be Another comparable study emphasizes the need for an
traversed in different directions, e.g. in the example of val- alignment of security engineering concepts [32, 33]. The
idating the fulfillment of system requirements. Further, the authors’ objective is to align concepts in information sys-
concepts we study may change depending on the abstraction tems risk management methods, to analyze which concepts
level, and hence are not easily mapped to relationships on are supported by existing security requirements engineer-
one level of abstraction as is the case with [5]. The impor- ing methods, and to define a language with solid concep-
tance of abstraction levels is discussed in Sect. 2.5. tual foundations based on the prior activities. Similar to [5],
All concepts in the information model of security the language used in [33] to model core security concepts is
engineering have a correspondence in our conceptual based on UML class diagrams and models the concepts at a

Table 2 Comparison of concepts in the information model for security engineering [5] and our CF
System The system in [5] refers to the machine and the people that interact with the machine.
In the CF, the system is the machine and the environment. It is less machine centric.
In the case of risk and threat analysis, we talk of system security properties that
are breached, rather than the states of the system.
Environment The environment in [5] is the physical environment, which may be subject to harm.
In the CF it is where the machine is embedded and plays an important role
in the definition of the functionality and security requirements of the system.
Asset ... is an asset in CF. However, we take a multilateral approach and do not consider assets only
to be threatened by malicious attacks. In order to distinguish assets in the different abstraction levels,
generically we call it resource.
Security goal In the CF, security goals are called the same and refer to the security goals defined towards
the assets important to the different stakeholders.
Security policy In [5], security policies mandate security criteria. We refer to a similar phenomena in a specification,
which mandates all the security requirements that need to be included in the design of the system.
Further, we assume that there are security policies defined in the organizational procedures
and processes, which mandate protection of security within the environment.
Security requirement Same definition
Threat Same definition
Attack Same definition
Attacker ... is in the CF called attacker in the case of actual exploitation, or threat agent
if the exploitation is potential. The concept of counter-stakeholder generalizes both concepts.
Harm ... is called a loss.
Security mechanism ... is called a countermeasure.
Property ... are subsumed under loss.
People
Service

123
16 Requirements Eng (2010) 15:7–40

Table 3 Comparison of concepts in the information system security risk management domain model [32] and our CF
Asset ... is an asset in CF. In contrast to the definition in the CF that involves multilaterality, the definition by Mayer only involves
malicious attacks. Mayer refers to an asset as a general concept similar to what is called resource in the CF. Concrete assets
are business assets (e.g., information, processes, skills) and information system assets (i.e., a part of the information system
that has value to the organization).
Security criterion ... is called a security goal.
Vulnerability Same definition
Threat Mayer defines a threat as a composition of a threat agent and an attack method. The latter represents the means used to carry
out a threat. Our CF does not explicitly mention attack methods. However, they are subsumed under the term threat.
Threat agent Same definition
Security Mayer’s definition is similar to our definition with the difference that our definition does not (directly) refer to risk. In our CF,
requirement risk is not considered on the low levels of abstraction, i.e., risk comes into play when the security property can be
considered on a level of abstraction higher than that of system requirements (cf. Sect. 2.5).
Control ... is called a countermeasure.

fixed level of abstraction. It does not address different The authors add that there will be multiple subsets of
levels of abstraction as necessary in a software engineering domain assumptions and specifications that will fulfill the
approach. We include and extend the core security con- requirements. In order to deal with these alternatives, they
cepts defined in [32, 33] in our conceptual framework. suggest determining which of the goals and quality con-
In Table 3, we compare the concepts in the information straints are optional or mandatory. This dichotomous
system security risk management domain model presented classification can then be used to facilitate the negotiation
in [32] and the concepts in our conceptual framework. If of stakeholder preferences between different solutions to
we have differing definitions for the concepts, these are the problem.
mentioned in the table. Our description of the concretization process in Sect. 2.2
Further, a survey of SRE methods has also been pro- explicates some of the aspects of what the authors in [15]
vided in [34], but the review predominantly focuses on call justified approximation e.g., refining information that a
methods for risk management and analyzes them with goal refers to, stakeholders, counter-stakeholders, circum-
respect to their compliance to the Common Criteria. In [35] stances, etc. Section 2.5 relates how the different security
and [36], the authors provide two short surveys of security concepts like harm, risk, and threats apply at the different
requirements engineering methods, but the analysis in both levels of abstraction to these aspects. In contrast to the
articles is limited in scope and in detail. In addition, they authors, we do not assume that all non-functional goals will
lack a reference like the conceptual framework through only lead to approximating quality constraints, but may
which detailed comparisons can be conducted. also lead to additional or modified functional requirements,
Recently, an critique has been raised by Jureta et al. [15] as also described in [30] and [37].
with respect to the terminology by Jackson and Zave that In the following Sects. 4–9, we present the survey of
states that the requirements problem amounts to finding the existing SRE approaches based on our conceptual framework.
specification and domain assumptions that suffice to satisfy We start with multilateral approaches, followed by UML-
the requirements. The authors argue that this model does based and goal-oriented methods, approaches using problem
not facilitate alternative articulations of domain assump- frames, risk-oriented, and Common Criteria-based methods.
tions, specifications and requirements, and does not For each of the selected approaches, we describe the method,
capacitate the stakeholders to make preferences between its scope in terms of the system development tasks and
these alternatives. security goals it covers, the validation and quality assurance
According to the core requirements engineering ontol- aspects it entails, and the relation to our conceptual frame-
ogy by Jureta et al. [15], functional requirements describe work concerning the nomenclature used by the methods.
what the system does, while non-functional requirements
how well the system does it (i.e., quality requirements).
Non-functional requirements are then divided into two: 4 Multilateral approaches
those which provide measurable ‘‘objective’’ qualities and
structured quality values (quality constraints), and those 4.1 Multilateral security requirements analysis
which provide subjective and unstructured or ill-defined (MSRA)
quality values (called softgoals). Softgoals are not satisfi-
able but ‘‘satisficable’’ by justifiably approximated quality (1) Description: The objective of the Multilateral Security
constraints. Requirements Analysis (MSRA) method [38, 39] is to

123
Requirements Eng (2010) 15:7–40 17

apply the principles of multilateral security [7] during the defining how long the security concern must be preserved, is
requirements engineering phase of systems development. seen as an attribute, but is not handled in the tables.
This is done by analyzing security and privacy needs of all An episode comprises system functionality that relates to
the stakeholders of a system-to-be, identifying conflicts, similar security interests of a single or a group of stake-
and consolidating the different stakeholder views. The holder(s). They are useful for identifying conflicts between
method borrows both from theories on multilateral security the security goals. Several kinds of conflicts between security
and viewpoint-oriented requirements engineering. goals can exist: for a single stakeholder, between the different
In order to articulate the different security needs of the requirements she has towards multiple episodes; between the
stakeholders, MSRA users elaborate security requirements different stakeholders of an episode; and between the
from the perspectives of the different stakeholders with requirements of episodes regardless of stakeholders.
respect to bundled functionalities of a system. Security Once the conflicts and inconsistencies are addressed, the
requirements result from the reconciliation of multilateral security goals are said to be refined into security require-
security goals. Security goals are selected from a rich ments. Further, additional conflicts may exist between
taxonomy derived from the CIA triad, which also includes security requirements, functional requirements, and other
properties such as accountability and pseudonymity etc. non-functional requirements. The method proposes ana-
Security goals, and later requirements, contain the attri- lyzing conflicts carefully and solving them either during
butes stakeholders who have an interest in the requirement, requirements analysis, through design, or using negotiation
counter-stakeholders towards whom a requirement is sta- mechanisms at runtime.
ted, and a number of other attributes that are defined in the The following are the main steps of the multilateral
following paragraphs. security requirements analysis method, once an initial
A stakeholder is defined as any person or organization functional requirements analysis for the main functional-
that has an interest in the system-to-be. Therewith, the ities of the system is concluded:
elaboration of the security requirements is not limited to the
1. Identify stakeholders: Stakeholders are all parties that
functional users of the system-to-be, the latter being refer-
have functional, security, privacy, or information
red to as actors. Rather, a distinction is made that allows the
interests in the system-to-be.
elaboration of both, those who have a stake in the system
2. Identify episodes: Episodes are similar to scenarios,
security, and those who will be using the system.
but are of a lower granularity, identifying sets of
The variant Confidentiality Requirements Elicitation
functionalities as would be meaningful to users.
and Engineering (CREE) of MSRA [40] considers only
Episodes are used to partition the security goals and
confidentiality requirements. Later work has focused on the
are later useful in identifying conflicts between
formalization of the confidentiality requirements in CREE
multiple security goals.
and the use of defeasible logic6 to analyze ambiguities and
3. Elaborate security goals: Identify and describe the
conflicts [41]. Counter-stakeholders refer to those stake-
security goals of the different security stakeholders for
holders whom the security goals are directed at. These may
each of the episodes.
or may not be malicious attackers or actors of the system.
4. Identify facts and assumptions: These are the proper-
Further, MSRA works with an information model, the
ties of the environment that are relevant for stating
elements of which are the objects of the different security
security goals.
requirements. The information model is of a higher level of
5. Refine stakeholder views on episodes: Elaborate the
abstraction than a data model, as would be necessary for a
stakeholder views taking facts, assumptions, and the
functional specification of the system-to-be.
relationships between episodes into account.
Additional attributes of a security requirement are: the
6. Reconcile security goals: Identify conflicts between
owner of the security requirement; the degree of agreement
security goals, find compromises between conflicting
among stakeholders towards the security requirement; the
goals, and establish a consistent set of security system
goal of the requirement (in CREE this is only confidentiality
requirements.
or consent); the information the requirement addresses; the
7. Reconcile security and functional requirements: Trade
strictness, stating if the security requirement makes a state-
functionality for security and vice versa in case of
ment about the security of information that it is not explicitly
conflicting functional and security requirements.
addressing; and the rationale, articulating why the infor-
mation needs to be secured. Further, temporal validity, (2) Scope: MSRA is integrated into the requirements
analysis phase and can be applied as soon as the initial
6 functional requirements of the system are identified.
A non-monotonic logic in which defeasible rules can be overridden
by others when certain conditions hold. For example, in the case of an All CIA goals are considered, although the emphasis on
emergency, certain confidentiality rules can be overridden. privacy has put the focus on confidentiality and integrity

123
18 Requirements Eng (2010) 15:7–40

Table 4 Example requirements table in MSRA/CREE

Id Own. Degree agree. Goal Counter-stakeh. Strict. Info Context Ration.

E.1 Patient Unanim. Consent Clinician Strict PII New patient Admin/care
E.2 Patient Partial Confid. Govern. Non-strict PII Aggregate data Anon

goals. MSRA puts an emphasis on multilateral security, applicability in real software development projects and
focusing on stakeholder views, the circumstances of secu- thus provides an organizational framework for carrying out
rity requirements, and reconciliation of conflicting security requirements engineering activities. It is assumed
requirements. MSRA uses UML models to capture epi- that SQUARE is carried out jointly by requirements engi-
sodes, the information model, as well as the functional and neers and stakeholders. It consists of 9 steps:
security requirements. In CREE, tables are used to denote
1. Agree on definitions: This step serves to enable a clear
the attributes of security requirements as shown by the
communication between requirements engineers and
example in Table 4.
stakeholders.
(3) Validation and quality assurance (QA): MSRA does
2. Identify security goals: Initially, the stakeholders will
not provide explicit validation methods. It does not guaran-
state different security goals. In this step, the goals are
tee completeness of security requirements, although multi-
aligned, and conflicts are resolved.
lateral security is an attempt to define security and privacy
3. Develop artifacts: The authors name the following
requirements in a system for all stakeholders, with the
artifacts that should be collected: system architecture
intention of discovering requirements that from a monolithic
diagram, use case scenarios/diagrams, misuse case
technical perspective could else have been missed.
scenarios/diagrams (see Sect. 5.1), attack trees, and
Through the multilateral view to security, conflicts are a
standardized templates and forms. These artifacts form
central concern of the method. The method explicitly
the basis for the subsequent steps of the method.
addresses interactions among security requirements, as
4. Perform risk assessment: In this step, the vulnerabil-
well as between security and functional requirements. Later
ities and threats related to the system are identified, as
formalization work with defeasible logic proposes auto-
well as the likelihood that the threats will lead to
mated analysis of the requirements for conflicts and
attacks. The authors propose to apply existing risk
ambiguities. Non-functional requirements other than
assessment methods.
security are not considered. The method is iterative, in the
5. Select elicitation technique: The method selected in
sense that after the reconciliation of security goals into
this step will be applied in the next step to perform the
security requirements, interactions are expected to affect
actual security requirements elicitation. Again,
the functional requirements of the system, requiring a
SQUARE recommends to apply an existing technique
review of the security requirements.
to be chosen for the project at hand.
(4) Relationship to the conceptual framework: The
6. Elicit security requirements: A crucial point in this
stakeholders and counter-stakeholders in MSRA corre-
step is to ensure that the requirements are verifiable
spond to the same terminology in our conceptual frame-
and that they are not implementations or architectural
work. The information model captures the information
constraints instead of requirements.
associated with a security requirement in Fig. 1. Security
7. Categorize requirements: The elicited requirements are
goals refer to goals as in the conceptual framework,
categorized (at least) according to the following
whereas security requirements refer to the security system
criteria: essential, non-essential, system-level, soft-
requirements. Episodes map to circumstances in the CF.
ware-level architectural constraint. Since the latter are
Facts and assumptions map one-to-one to the same CF
not considered as requirements, their existence indi-
terminology.
cates that the previous steps should be executed again.
8. Prioritize requirements: It is assumed that not all
4.2 Security quality requirements engineering requirements can be implemented; hence, the most
methodology (SQUARE) important requirements must be identified.
9. Requirements inspection: In this last step, the require-
(1) Description: SQUARE [42] is a comprehensive meth- ments are checked for ambiguities, inconsistencies,
odology for security requirements engineering. Its aim is mistaken assumptions, and the like. Its result is the
to integrate security requirements engineering into soft- final security requirements documents for the
ware development processes [43]. SQUARE stresses stakeholders.

123
Requirements Eng (2010) 15:7–40 19

(2) Scope: SQUARE is a comprehensive security

requirements engineering methodology that recommends to
make use of other techniques developed in the field, and
that covers all CIA goals.
(3) Validation and QA: Each step of SQUARE closes
with some exit criteria, which have to be fulfilled before
the next step is begun. Moreover, the last step is exclu-
sively dedicated to validating the requirements. However,
no formal validation is performed.
(4) Relation to conceptual framework: Although
SQUARE uses notions of our conceptual framework, they
are often used in a narrower sense. Stakeholders are iden-
tified with clients. It seems that ‘‘system-level require-
ments’’ correspond to requirements as defined in the
conceptual framework, whereas ‘‘software-level require-
ments’’ correspond to specifications. ‘‘System’’ seems to
mean the IT infrastructure in which the software to be Fig. 3 Use case diagram containing misusers and misuse cases (taken
developed will operate. Hence, this term is also used in a from [45])
narrower sense than in the conceptual framework. Domain
knowledge is not mentioned explicitly. However, step 1 of security cases represent security requirements, and misuse
the method seems to be related to it. Also, the notions asset cases represent security threats. Since use case diagrams
and vulnerability are not mentioned. On the other hand, the only give an overview of the system functionality, the
terms security goal, threat and risk are used in the same essence of the contained uses cases is captured in an
way as in the conceptual framework. associated textual description. This textual description is
based on a template to be filled out by an analyst. Sindre
and Opdahl extend the template, making it suitable for
5 UML-based approaches describing misuse cases, supporting detailed elicitation and
analysis of security threats. Furthermore, they present an
In this section, we discuss approaches to security require- iterative method based on common risk and threat analysis:
ments engineering that make use of Unified Modeling
1. Identify critical assets in the system.
Language (UML) [44] notation.
2. Define security goals for each asset.
3. Identify threats for each security goal by identifying
5.1 Misuse cases
stakeholders that may intentionally harm the system or
its environment. Identify sequences of actions that may
(1) Description: Sindre and Opdahl [45] extend the tradi-
result in intentional harm.
tional use case approach to also consider misuse cases,
4. Identify and analyze risks for the threats (using
which represent behavior not wanted in the system to be
standard techniques).
developed. Misuse cases are initiated by misusers. A use
5. Define security requirements for the threats to match
case diagram (see Fig. 3) contains both, use cases and
risks and protection costs.
actors (notated as named ellipses and named stick figures,
respectively), as well as misuse cases and misusers (notated Applying misuse cases results in a use case diagram
as graphically inverted use cases and actors).7 including use cases, security uses cases, and misuse cases.
A use case is related to a misuse case using a directed The approach neither considers a formal foundation nor an
association. An association pointing from a misuse case to attacker model.
a use case has the stereotype\\threaten[[. A use case (2) Scope: Misuse cases are applicable to design a sys-
diagram can contain security use cases, which are special tem that covers different security needs. It is possible to
use cases. An association pointing from a security use case consider all three CIA goals. It incorporates common risk
to a misuse case has the stereotype \\mitigate[[. It is and threat analysis techniques.
stated that ordinary use cases represent requirements, (3) Validation and QA: The interaction between func-
tional and security needs is considered in terms of linked use
7 cases and security use cases in a use case diagram. The
The definition of mal-activity diagrams [46] is based on a similar
idea. In this recent work, malicious activities and actors are added to approach does not consider elicitation of requirements (in the
UML activity diagrams in order to model potential attacks. sense of security requirements in the conceptual framework),

123
20 Requirements Eng (2010) 15:7–40

completeness of the set of requirements, validation, verifi- considered as a notation to specify and design secure soft-
cation, conflicting requirements, nor the interaction of ware systems, rather than a security requirements engineer-
security and other non-functional requirements. ing method. SecureUML deals with users, which can be
(4) Relation to conceptual framework: Sindre and Opdahl considered as stakeholders in our conceptual framework.
state that a critical asset is ‘‘either information that the The notions security goal and requirement, domain knowl-
enterprise possesses, virtual locations that the enterprise edge, asset, threat, vulnerability, and risk as defined in our
controls, or computerized activities that the enterprise per- conceptual framework are not considered by SecureUML.
forms’’. Hence, their definition is close to the ISO/IEC
13335-1 definition: anything that has a value to the organi- 5.3 UMLsec
zation. Their definition of a security goal is vague and refers
to the ‘‘security criteria’’ of the Common Criteria. What they (1) Description: Jürjens [49] introduces a UML-based
call ‘‘stakeholder that may intentionally harm...’’ is repre- modeling language for the development of security-critical
sented by the notion of a counter-stakeholder in the con- systems named UMLsec. His approach considers several
ceptual framework. Misuse cases use the terms actor and security requirements according to the CIA triad. These
stakeholder synonymously. They only describe a narrower requirements are depicted in different UML diagrams using
view of the notion stakeholder of our conceptual framework. stereotypes, constraints, and tagged values, which are
The notions threat and risk of the misuse case approach defined in a UML profile. The UMLsec extensions are
can be mapped to the equally named notions of our con- precisely defined and have a formal semantics. Jürjens’
ceptual framework. Furthermore, the authors call security work considers an attacker model based on the adversary
requirements what according to our conceptual framework tag. The approach also considers domain knowledge in
are specifications (or even design solutions) to the men- terms of assumptions.
tioned security goals. The notions security requirement, (2) Scope: Jürjens’ approach focuses on the design of a
domain knowledge, and vulnerability as defined in our machine, and it covers all three CIA goals.
conceptual framework are not considered by the misuse (3) Validation and QA: Jürjens states that the formal
case approach. foundation makes it possible to apply traditional verifica-
tion techniques. For this purpose, a tool suite is provided.
5.2 SecureUML UMLsec does not consider elicitation of requirements (in
the sense of CF security requirements), completeness of the
(1) Description: Lodderstedt et al. [47] present a UML- set of requirements, verification, conflicting requirements,
based modeling language for the development of secure, nor possible interaction of security, functional, and other
distributed systems called SecureUML. In particular, their non-functional requirements.
approach focuses on embedding role-based access control (4) Relation to conceptual framework: The definition of
policies in UML class diagrams using a UML profile. The the notion security requirement in UMLsec matches the
UML profile defines a vocabulary for annotating class definition of the notion specification of our conceptual
diagrams with relevant access control information. Fur- framework presented in Sect. 2. Hence, similar to Secure-
thermore, authorization constraints in terms of OCL [48] UML, UMLsec can be considered as a notation to specify
preconditions are developed. They make it possible to and design secure software systems rather than a security
formally express role-based access control policies for requirements engineering method. The notions stakeholder
certain class components. SecureUML does not consider an and domain knowledge of our conceptual framework are
attacker model. partly covered by the UMLsec notions actor and assump-
(2) Scope: Lodderstedt et al. focus on the design of role- tion, respectively. The UMLsec notions threat, vulnerabil-
based access control policies, a rather partial mechanism to ity, and risk can be mapped to the equally named notions of
fulfill confidentiality and integrity goals. Availability is not our conceptual framework. The notions of security goal and
covered by this method. requirement as well as asset are not considered by UMLsec.
(3) Validation and QA: SecureUML does not consider
requirements (in the sense of security requirements in the
conceptual framework) elicitation, completeness of the set 6 Goal-oriented approaches
of requirements, validation or verification, nor interaction
and conflicts of requirements. 6.1 Keep all objectives satisfied (KAOS) with
(4) Relation to conceptual framework: The definition of intentional anti-models
the notion security requirement in SecureUML matches the
definition of the notion specification of our conceptual (1) Description: In his paper on ‘‘Engineering requirements
framework presented in Sect. 2. SecureUML can be for system reliability and security’’ [37], van Lamsweerde

123
Requirements Eng (2010) 15:7–40 21

pulls together all his previous research on the goal-oriented the authors describe the elaboration of security require-
requirements analysis method KAOS [50], formalization of ments in more detail. An anti-model is constructed after the
requirements using linear time temporal logic [51], goals of the system-to-be have been elaborated and refined.
requirements conflict analysis [25], and the use of anti- This is done through the execution of the following steps:
models for elaborating security requirements [52]. There-
1. Obtain the initial goals by negating existing security
fore, van Lamsweerde does not suggest a method specifi-
goals (roots of the anti-goal refinement trees).
cally for elaborating security goals, but extends KAOS to
2. Elicit potential attacker agents.
include the elaboration of security requirements.
3. Perform an AND/OR refinement of anti-goals. When
KAOS takes into consideration that there are multiple
the anti-goal refinement trees are generated, assign
stakeholders in and multiple views towards a system-to-be.
anti-requirements to attackers and vulnerabilities to
The views here do not refer to the differing views of the
attackers.
stakeholders, but to the goal, object, agent, system opera-
4. Derive the object-agent anti-model.
tion, obstacle, security-threat and agent behavior models—
5. AND/OR operationalize all anti-requirements.
each model stands for a different view of the system. In the
goal model, the goal of a stakeholder is refined using an The first activity includes not only the generation of
AND/OR refinement tree by asking the questions why (for obstacles through negating existing goals, but also the use
upward elaboration) and how (for downward refinement) to of logical techniques to capture obstacles. These obstacles
the leaves of the goal-refinement tree. These leaves are are then refined using fault trees, whose roots are the goals
then assigned to the agents. A requirement is a goal and leaves are vulnerabilities, into an obstacle model. Such
assigned to a single agent in the software-to-be. It is a model shows how security goals can be obstructed by
acknowledged that conflicts can exist among the goals of linking negated goals to the attacker’s malicious goals,
the different stakeholders, and these conflicts are man- called anti-goals, and capabilities. These capabilities define
aged—detected, analyzed, and resolved—using a number the interface between the attacker and its own environment,
of heuristics. The integration of the multiple views is including the threatened software-to-be. The properties of
performed systematically by stepping through the follow- the attacker’s environment comprise the properties of the
ing activities: software-to-be, including vulnerabilities that can be
exploited for anti-goal achievement. The elicitation of
1. Domain analysis, part 1: consists of a goal model of
potential attacker agents and the refinement of the obstacle
the current system-as-is.
model are completed in steps two and three respectively.
2. Domain analysis, part 2: consists of deriving an object
Once an anti-model stands and the resulting obstacles
model of the system-as-is.
have been identified, the requirements engineers are
3. System-to-be analysis: replay of Step 1 for the system-
expected to develop countermeasures so that the precon-
to-be.
ditions of the anti-goals are no longer fulfilled. Counter-
4. System-to-be analysis: replay of Step 2 for the system-
measures are selected based on (a) the severity and
to-be.
likelihood of the corresponding threat, and (b) non-func-
5. Obstacle and threat analysis: consists of building
tional goals that have been identified prior to the anti-
obstacle and threat models and exploring resolutions
model. Alternative countermeasures can be produced using
to enrich and update the goal model.
goal substitution, agent substitution, goal weakening, goal
6. Conflict analysis: consists of detecting conflicts among
restoration, and anti-goal mitigation.
goals and exploring resolutions to enrich and update
All requirements in KAOS are written by default using
the goal model.
semi-formal graphical notations and, if needed, using for-
7. Responsibility analysis: exploring alternative assign-
mal notation. This also holds for the anti-goals and security
ments of leaf goals to system agents, selecting best
threats posed by an attacker. A linear real-time temporal
alternatives based on non-functional goals from the
logic is used to formalize the goals, domain properties, and
goal model, and building an agent model.
required trigger conditions. A simple state-based Z-like
8. Goal Operationalization: build an operation model
language is used to express preconditions and
ensuring that all leaf goals from the goal model are
postconditions.
satisfied.
(2) Scope: KAOS is a requirements engineering method
9. Behavior analysis: is about building a behavior model
concerned with the elaboration of the objectives to be
for the system as a parallel composition of behavior
achieved by the system-to-be, the operationalization of
models for each component.
such objectives into requirements and assumptions, the
The steps of the KAOS method are re-iterable and assignment of responsibilities for those specifications to
cyclic, although they contain data dependencies. In [52], agents such as humans, devices or software, and the

123
22 Requirements Eng (2010) 15:7–40

evolution of such requirements over time and across sys- implementation activities in a software development pro-
tem families. Nevertheless, we observe that the method cess, with a strong focus on the early phases of software
focuses less on the elicitation of requirements, but more on development. Tropos incorporates many of the concepts of
the completeness, consistency, and feasibility of require- Yu’s i*-modeling framework [56–58]. For that reason, the
ments as well as their successful operationalization in following description of Tropos also applies to a large
specifications. extent to the i*-modeling framework8.
(3) Validation and QA: The completeness, consistency, Models in Tropos are instances of a metamodel [54].
and validation of the elaborated requirements are an This metamodel consists of the following concepts and
important objective of the KAOS method and its formal- relationships:
ization mechanisms. Goals provide a criterion for com-
• Actor: An actor is an entity that has goals within the
pleteness. A goal is fulfilled if it is satisfied by the
system or the organization of interest. This can be a
requirements in view of the domain properties and under
physical or a software agent, as well as a role (an agent
certain expectations. Obstacle analysis and the derived
can play a role) or a position (a set of roles, a position
countermeasures are also used to reach goal completeness.
covers roles).
The method also suggests a number of activities for the
• Goal: Goals represent actors’ interests towards the
verification of requirements. A first kind of verification
system. Tropos distinguishes hard goals and soft goals.
consists in checking that the refinements of non-soft goals
Hard goals describe conditions that an actor would like
in the goal model are correct and complete so that missing
to achieve. Soft goals have no formal, clear-cut
subgoals can be avoided.
definition or satisfaction criteria. Soft goals are typically
A second approach to model verification consists of
used to model non-functional requirements [59, p. 4].
checking the correctness of operationalizations of goals
• Plan or task: an abstraction of doing something. If the
from the goal model into specifications of operations from
task has dependencies to the machine, it refers to the
the operational model. Formal methods and formal
specification.
refinement patterns are offered to execute both types of
• Resource: represents a physical or informational entity.
verification.
If the resource has dependencies to security goals it
Further, consistency is addressed through the analysis of
refers to an asset (respectively, to information).
conflicts among multiple requirements.
• Dependency: Dependencies model the fact that one
(4) Relation to conceptual framework: The terminology
actor depends for some reason on another to attain a
of the KAOS framework maps to the terminology of the
goal, execute some plan, or deliver a resource. Thus a
conceptual framework as follows. Goals refer to functional
dependency is a ternary relationship between a de-
and non-functional goals. Objects refer to information or
pender, a dependee and a dependum.
system components. Agents refer to stakeholders with
functional assignments or functional system resources. The Tropos concepts are graphically represented as
Obstacles refer to either conflicting goals or requirements shown in Fig. 4.
of the different stakeholder views in the conceptual Tropos distinguishes five main development phases:
framework, or to goals that conflict with the security early requirements, late requirements, architectural
properties as defined in Fig. 2. Security threats are the design, detailed design, and implementation. During the
threats as posed by threat agents. All the analysis that development process, the models are incrementally refined
KAOS proposes with respect to the operationalization of and extended until executable development artifacts
goals refers to the consistency, validation, and complete- emerge. The early requirements phase is concerned with
ness analyses of the specification of the system, namely, analyzing and understanding the organizational context.
analyses that occur after the system requirements have During this phase the actors are identified and modeled.
been elaborated. Actors have goals and depend on each other to fulfill goals,
The KAOS method considers also domain properties perform tasks, and to furnish resources. Next, during the
and expectations, which correspond to facts and assump- late requirement phase, the system-to-be is described
tions in the conceptual framework. As a result, threat within its environment. This is done by representing the
analysis encompasses an analysis of the environment. system-to-be as a number of actors who have dependencies
to other elements of the model. These dependencies define
6.2 Secure i* and Secure Tropos the machine’s functional and non-functional requirements.
Architectural design is concerned with the overall structure
Tropos is a software development methodology based on
the paradigm of agent-oriented software development [53– 8
Details about the i*-modeling framework can be found online:
55]. Tropos deals with all analysis, design, and http://www.istar.rwth-aachen.de/

123
Requirements Eng (2010) 15:7–40 23

(S)
Depender Constraint Dependum Dependee
Actor Agent Role A AA
Position Label
A

(S)
Soft Task Depender Dependum Constraint Dependee
Goal Resource
Goal Label

Dependum (S) (S)

Depender Dependee Depender Constraint Dependum Constraint Dependee
(Goal) Label Label

Fig. 4 Graphical representation of Tropos concepts (cf. 60) Fig. 5 Graphical representation of secure dependencies (cf. [60])

analyze and model the new concepts. These activities

of the machine. Subsystems and system components of the produce different kinds of diagrams, which are used as
machine are represented as actors, too. Each architectural input to the later activities.
component is further detailed in terms of inputs, outputs, Security reference modeling deals with the security
and control. Finally, the implementation phase comprises features of the system-to-be, the protection objectives of
the mapping of the detailed design to the implementation the system, the security mechanisms, and also the threats to
platform. the system’s security features. These concepts are graphi-
There exist two extensions of Tropos called Secure cally represented as shown in Fig. 7, and they can be
Tropos: one by Mouratidis et al. [60–62], and another one connected by two different kinds of links: a positive con-
by Massacci et al. [63]. Furthermore, there exists an tribution link when one node helps in the fulfillment of
extension of the i*-modeling framework called Secure i* another, and a negative contribution link when a node leads
[64]. to the denial of another. Using these concepts and links, a
(1) Description: developer can construct a security reference diagram.
(a) Secure Tropos by Mouratidis et al.: Mouratidis et al. Security constraint modeling covers the modeling of the
extend the Tropos methodology with new concepts to security constraints, which involves the following
cover security modelling: activities:
• Security constraint: A security constraint is defined as • Security constraint delegation: allows the delegation of
‘‘a restriction related to security issues, such as privacy, a security constraint among actors.
integrity and availability, which can influence the • Secure constraint assignment: indicates the assignment
analysis and design of a multiagent system under of a security constraint to a goal.
development by restricting some alternative design • Security constraint analysis: comprises the decompo-
solutions, by conflicting with some of the requirements sition of a security constraint into subconstraints and
of the system, or by refining some of the system’s the introduction of new security goals caused by the
objectives.’’ [60]. They are graphically represented as security constraint.
clouds that are labeled with a constraint.
Secure entities modelling is an activity complementary
• Secure dependency: A secure dependency describes
to the security constraint modelling activity, which
one or more security constraints that must be fulfilled
involves the analysis of secure goals, tasks, and resources.
for a dependency to be satisfied: ‘‘... the depender
Secure capabilities modelling covers the identification
expects from the dependee to satisfy the security
of the capabilities of the concerned actors and agents
constraint(s) and also that the dependee will make an
necessary to fulfill the security constraints.
effort to deliver the dependum by satisfying the security
In [65], the authors combine Secure Tropos by Mou-
constraint(s).’’ [60].
ratidis et al. with the model-based information system
• Secure entity: A secure entity represents any secure
security risk management (ISSRM) approach by Mayer
goal/task/resource of the system.
et al. [66] presented in Sect. 8.
The Secure Tropos concepts are graphically represented For formal analysis, the Formal Tropos approach is
as shown in Figs. 5 and 6. inspired by KAOS [51]. For the detailed design, Agent-
The Secure Tropos process is similar to the earlier- UML [67] is used. To analyze security attacks a scenario-
mentioned Tropos process, but is extended with phases to based approach is used [68].

123
24 Requirements Eng (2010) 15:7–40

(S) Goal (S) Task (S) Resource

In addition to the notions originally supported by the i*-
Label Label Label modeling framework, Si* introduces the notions of delega-
tion and trust. Delegation is defined as a relation between
Fig. 6 Graphical representation of secure entities (cf. [60]) two actors (the delegator and the delegatee) and a goal, task,
or resource (the delegatum). The authors distinguish two
Security Protection Security
Threat
types of delegation: delegation of execution, which consid-
Feature Objective Mechanism
ers the delegation of the responsibility to achieve a goal,
execute a task, or deliver a resource. In contrast, delegation
Fig. 7 Graphical representation of security reference diagram con-
of permission considers the delegation of the permission
cepts (cf. [60])
achieve a goal, execute a task, or use a resource. The two
types are graphically represented as edges between delega-
b) Secure i*: Yu et al. [64, 69] present an extension of
tor, delegatee, and delegatum that are labeled with De
Yu’s i*-modeling framework for modeling and analyzing
(delegation of execution) or Dp (delegation of permission).
security trade-offs. The authors argue that security mea-
The notion of trust is used to separate delegation
sures may be in conflict with usability, performance, and
between trusted and untrusted actors. Similarly to delega-
functional requirements. Hence, Secure i* focuses on the
tion, trust is defined as a relation between two actors (the
alignment of security requirements with other requirements.
trustor and the trustee) and a goal, task, or resource (the
Secure i* [64] is based on a metamodel of security con-
trustum). Again, the authors distinguish two types of trust:
cepts, which considers important notions and their relation-
trust of execution, which indicates the belief of one actor
ships. It is centered around actors that have or seek goals.
that the trustee will achieve the goal, accomplish the task,
Special security goals prevent or detect threats, or recover
or deliver the resource. Furthermore, trust of permission
the system from threats. Assets are targeted by threats (or
indicates the belief of one actor that the trustee will not
attacks), and actors are interested in them, actors own them,
misuse the goal, task, or resource. The two types are
or actors delegated the usage permission of the assets to other
graphically represented as edges between trustor, trustee,
actors. Threats occur through vulnerabilities. Threats might
and trustum that are labeled with Te (trust of execution) or
be unintentional, or result from accident or human error.
Tp (trust of permission).
Natural disasters are another type of threats against the
systems. Most of these notions cannot be modeled using the (2) Scope:
i* notation. Therefore, Elahi and Yu extend this graphical
(a) Secure Tropos by Mouratidis et al.: The Secure
notation by malicious representations of the original i*
Tropos methodology by Mouratidis et al. can be
notions, e.g. malicious actor, vulnerability, and threat/
applied in all activities in the software development
attack. The graphical representation of the malicious mod-
process and all three CIA goals can be considered and
eling elements is similar to the i* elements, with the differ-
analyzed. Furthermore, by using security attack
ence that the malicious modeling elements have a black
scenarios [68], threat and attacker analysis is possible.
background. An exception are vulnerabilities. They are
(b) Secure i*: The Secure i* methodology can be applied
graphically represented by a labeled black dot at resources,
in all activities in the software development process.
and they are connected to threats/attacks via a dashed arrow
Through the security extensions of Secure Tropos, all
pointing from threats/attacks to vulnerabilities.
three CIA goals can be considered and analyzed.
Additionally, Elahi and Yu present a trade-off analysis
(c) Secure Tropos by Massacci et al.: The Secure Tropos
method that makes use of the Secure i* notation. Following
methodology by Massacci et al. can be applied in all
their method, software engineers must balance trade-offs to
activities in the software development process and
mitigate threats/attacks. The denial of a goal can be ana-
authorization, availability, and privacy goals can be
lyzed and expressed through negative contribution links.
considered and analyzed.
Then, alternative security solutions can be examined by
analyzing the impact of each of the solutions on threats/ (3) Validation and QA:
attacks and goals. Finally, a security solution that best fits
(a) Secure Tropos by Mouratidis et al.: In order to test the
with the goals of multiple actors can be selected.
developed solution, security attack scenarios are
(c) Secure Tropos by Massacci et al.: Secure Tropos by
proposed [68]. A security attack scenario describes
Massacci et al. [63] makes use of the Secure i* (Si*) lan-
the attacker as an actor of the system, as well as the
guage9 (not to be confused with Secure i* by Elahi and Yu
actors’ goals. The aim is to test which solution could
[64]).
cope with different kinds of attacks. After the creation
of the scenario the models are validated, e.g., by using
9
Details about Si*: http://www.sesa.dit.unitn.it/sistar_tool/ software inspections and checklists.

123
Requirements Eng (2010) 15:7–40 25

(b) Secure i*: The proposed qualitative trade-off analysis (b) Secure i*: Security goals correspond to security goals,
method can be seen as an informal validation security requirements, and specifications of our CF.
procedure accomplished by assessing the impact of Assets directly correspond to assets in our CF. Secure
security solutions on the goals of actors and on threats i* does not provide a clear-cut definition of the
or attacks. notions threat and attack. It seems that they can be
(c) Secure Tropos by Massacci et al.: To automatically mapped to the equally named notions of our CF. The
verify the correctness and consistency of functional Secure i* notion vulnerability matches the similarly
and security requirements, the Secure Tropos con- named notion of our CF. Secure i* does not consider
cepts were formalized based on Datalog [70], and domain knowledge (except for distinguishing honest
integrated into the CASE-Tool ST-Tool [71]. In and malicious actors) and risk.
particular, Secure Tropos assists in verification of (c) Secure Tropos by Massacci et al.: Security constraints/
availability, authorization, and privacy requirements properties correspond to security goals, security require-
and in the detection of trust conflicts [72]. ments, and specifications of our CF. Secure Tropos by
Massacci et al. does not consider domain knowledge
Furthermore, Massacci et al. define a formal semantics
(except for distinguishing trusted and untrusted actors),
of their Secure Tropos extension [63] using the Answer Set
assets, threats, vulnerabilities, or risk.
Programming (ASP) paradigm [73]. ASP is based on facts
and rules expressed as Horn clauses. Facts are atomic
statements and are used to formalize an ‘‘intuitive’’
6.3 Goal-based requirements analysis method
description of the system. Rules can be axioms that are
(GBRAM)
used to extend the formalization of the system description.
They can also be properties that are used to formalize
(1) Description: The objective of the Goal-Based Require-
security goals as constraints. The formal foundation of
ments Analysis Method (GBRAM) [11] is to utilize goal-
Secure Tropos by Massacci et al. is sufficient to verify
and scenario-driven requirements engineering methods to
security goals represented as ASP properties.
formulate privacy and security policies, as well as
(4) Relation to conceptual framework: Several notions
requirements for e-commerce systems. Furthermore, the
common to all three presented approaches can be related to
method targets change management in organizational pri-
our conceptual framework as follows: actors partly corre-
vacy and security policies, and system requirements. Lastly
spond to stakeholders of our CF. In contrast to stakehold-
the method is used to assure compliance of these system
ers, actors are always directly linked to the machine. Goals
requirements to the privacy and security policies.
correspond to goals as well as requirements, since the goals
In a later work building upon GBRAM, He and Antòn
in Tropos are incrementally refined. Hard and soft goals
introduce a role-engineering framework. In this ‘‘Frame-
correspond to functional and non-functional requirements.
work for Modeling Privacy Requirements in Role Engi-
Furthermore, resources correspond to the same notion of
neering’’ [74], goals and scenarios are adopted in order to
our CF.
analyze permissions and establish role hierarchies, which
(a) Secure Tropos by Mouratidis et al.: Security con- then can be used to define a role-based access control
straints and security features as well as secure entities model (RBAC). Further, in [31], the authors suggest a
correspond to security goals, security requirements, context-free grammar for formalizing privacy goals artic-
and specifications of our CF. The considered threats ulated in natural language. The formalized goals are used
can be mapped to the threats defined in our CF. to analyze and compare the system goals stated through
Threats, as well as vulnerabilities and risk, are them. We focus only on the earlier description of GBRAM
covered by the combination of Secure Tropos by as a privacy and security requirements analysis method.
Mouratidis et al. and the model-based ISSRM Change management in policies and the business envi-
approach by Mayer et al. [66] presented in Sect. 8. ronment is accomplished through the analysis of changes
As a consequence, the notions threat, vulnerability, made to the long- and short-term goals of the organization.
and risk correspond to the equally named ISSRM Strategic Changes refer to long-term, broadly based initia-
notions, which in turn can be directly mapped to the tives, and Tactical Changes refer to short-term changes.
notions of our CF. Protection objectives describe Comparably, Strategic Goals are those that reflect high-level
abstract solution mechanisms such as encryption, enterprise goals. These are useful for deriving requirements
whereas security mechanisms denote the concrete and are expected to be stable. In contrast, Tactical Goals are
mechanisms such as AES (Advanced Encryption those goals that support an organization’s strategic goals.
Standard). Secure Tropos by Mouratidis et al. does GBRAM contains a number of heuristics that can be
not consider domain knowledge and assets. applied to the various activities, as they are listed in Fig. 8.

123
26 Requirements Eng (2010) 15:7–40

The GBRAM is mainly based on existing organizational

Information Allocate
Sources Resources
Privacy Policy
policies, and hence does not provide the means to deal with
different stakeholder views. The authors nevertheless
Identify Elaborate Refine Assess
Goals Goals Goals
Operationalize
Goals
Security Policy
Compliance emphasize the importance of reconciling conflicts among
Security system requirements during the refinement phase.
Assess Risks Requirements
& Impacts (3) Validation and QA: Conflicts among goals are con-
sidered during the refinement activities. Although the
Fig. 8 GBRAM activities
authors state that stakeholders and their privacy concerns
are important for the generation of privacy policies, no
The heuristics are used to identify, refine, and operation- explicit reference is made as to how conflicts of interest
alize security and privacy goals. These are: between stakeholders can be solved using the method.
Similarly, negotiation methods for solving goal conflicts
• Identification heuristics are used by the requirements
are not offered, although goal conflicts and their solutions
analyst to study existing security and privacy policies,
are an important part of goal-driven requirements engi-
requirements analysis, and design documentation in
neering [25]. In general, no formal notation or semantics
order to identify both strategic and tactical goals related
are introduced in the method.
to the organizational assets. These goals are annotated,
The authors state the necessity of compliance assess-
including information about stakeholders and
ment by pointing out that risk and impact assessment
responsibilities.
alone are not enough to guarantee that the system
• Classification heuristics are used to classify the iden-
requirements are aligned with enterprise security and
tified goals according to their type and dependencies.
privacy policies. Hence, they introduce a compliance
• Elaboration heuristics are used to further analyze the
assessment activity, which is to be iteratively applied as
classified goals by studying scenarios, goal obstacles,
the requirements or the policies are updated. In the
constraints, preconditions, postconditions, questions,
compliance activity, the authors suggest identifying con-
and the underlying rationale.
flicts and inconsistencies between the policies and the
• Refinement heuristics are used to remove synonymous
requirements using the ‘‘House of Quality’’ approach [76].
and redundant goals. Inconsistencies among goals are
This activity guarantees the alignment between the poli-
solved, and the goals are operationalized into a
cies and the system requirements.
‘‘requirements specification’’.
No activities are suggested for attaining the complete-
ness of the policies or the requirements themselves. A
Once the goals have been identified, refined and oper- validation of both policies and system requirements is
ationalized, asset-based risk assessment and compliance conducted through their empirical application to multiple
assessment activities are applied. These activities may e-commerce Web sites. Further, the authors have collected
result in further goal refinement or the addition of new privacy statements from over 100 commercial web sites
goals to respond to the risks. In this case, the previous using their Privacy Goal Management Tool in order to
activities need to be reiterated to identify conflicts, avoid analyze common and conflicting goals.
inconsistencies, and re-assess for resulting risks. (4) Relation to conceptual framework: The terminol-
GBRAM is specifically useful for analyzing and elabo- ogy of GBRAM can be mapped onto our conceptual
rating organizational goals—which are already integrated framework in the following manner: security- and pri-
into policies—to elicit system requirements. By empha- vacy-related statements from corresponding policies are
sizing and integrating the management of changes in the security goals in the CF. The GBRAM definition of
technology and the business environment to their method, security requirements, which the authors call the
the authors manage to include important aspects that many requirements specification, corresponds to system
other methods ignore. requirements in the conceptual framework. Stakeholders
(2) Scope: Antòn et. al. suggest using GBRAM at the can be elicited from the organizational policy documents,
beginning of the design phase in order to achieve the but no use of views is offered by the method. Require-
security of sensitive data. The heuristics are used to iden- ments conflicts are considered: these are expected to
tify new, as well as previously overlooked, goals based on occur as a result of new technologies being introduced to
the results of risk assessment activities. The method is the application domain. Hence, stakeholder conflicts are
asset-centered and builds on the PFIRES approach for not attended to. Asset refers to all the objects of interest
assessing risk in eCommerce systems [75]. There is no centered around software, hardware, people, and docu-
explicit mention of the use of all CIA goals. The focus in mentation, whereas information refers to information
GBRAM papers is on confidentiality goals. assets in the CF.

123
Requirements Eng (2010) 15:7–40 27

7 Problem frame-based approaches Sender SD!Y1 Sent

machine data Y1
X
In this section, we present approaches to security require-
ments engineering that make use of the ideas underlying SM!E1 Transmitted
Jackson’s problem frames [77]. Problem frames are pat- data
X
Y2
terns to classify software development problems. TD!Y2
SR
A problem frame is described by a frame diagram (see
Figs. 9 and 10), which basically consists of rectangles, a
Malicious Y4
dashed oval, and lines between these. The task is to con- subject
B
struct a machine that improves the behavior of the envi-
ronment it is integrated in. The environment is described Receiver Received Y3
by domains. Jackson distinguishes between different machine data
B RM!E2 X
domain types, which are depicted by differently decorated
rectangles (e.g., a machine domain is denoted as a rect- Fig. 10 Security problem frame for confidential data transmission
(taken from [80])
angle with two vertical lines).
The connecting lines between domains represent inter-
faces that consist of shared phenomena. Shared phenomena security requirements. Figure 9 shows an abuse frame,
may be events, operation calls, messages, and the like. which constitutes a pattern to be instantiated. The instances
They are observable by at least two domains, but controlled are called abuse frame diagrams.
by only one domain. For example, if a user types a pass- It is stated that initially security objectives must be
word to log into an IT system, this is a phenomenon shared derived by identifying critical assets to be protected. The
by the user and the IT system, which is controlled by the notion of an asset is not defined, but it seems that it is used
user. The requirements are denoted using a dashed oval. A similarly to the ISO/IEC 13335-1 definition: anything that
dashed line between requirements and a domain represents has a value to the organization.
a requirements reference, and an arrow pointing to a Based on a set of functional requirements and security
domain shows that it is a constraining reference. objectives, the authors propose an iterative threat analysis
The problem frames approach also establishes a well- method consisting of four steps:
formed vocabulary for the notions of requirement, speci-
1. Identify the problems and subproblems using common
fication, domain knowledge, and so on. This vocabulary
problem frames. Describe the security needs as
constitutes the basis for the conceptual framework pre-
constraints on the identified functionality.
sented in Sect. 2. For this reason, unless otherwise noted,
2. Identify the threats and construct abuse frame diagrams.
the vocabulary of the different approaches discussed in this
Anti-requirements are obtained by negating the security
section fits the vocabulary of the CF.
needs and capturing them in an abuse frame diagram.
3. Identify security vulnerabilities.
7.1 Abuse frames
4. Address security vulnerabilities. It is stated that
security requirements are derived, e.g. ‘‘Limit the
(1) Description: Lin et al. [78] define so-called anti-
number of tries for entering passwords’’.
requirements and the corresponding abuse frames. An anti-
requirement expresses the intentions of a malicious user, No formal foundation or attacker model are considered
and an abuse frame represents a security threat. The by the approach.
authors state that the purpose of anti-requirements and (2) Scope: The method is applicable to designing a
abuse frames is to analyze security threats and derive machine. Since the authors show only a small set of the
abuse frames, it is not clear if all three CIA goals are
considered.
(3) Validation and QA: Abuse frames do not consider
requirements elicitation, completeness of the set of require-
ments, validation, verification, nor interaction between secu-
rity, other non-functional, and functional requirements.
(4) Relation to conceptual framework: The notion of a
security objective is comparable to the security goals in our
conceptual framework described in Sect. 2. Negated anti-
requirements correspond to security requirements in our
Fig. 9 Abuse frame (taken from [78]) CF. It becomes clear that what Lin et al. call security

123
28 Requirements Eng (2010) 15:7–40

requirements are (according to the definition in our CF) initial set of

security
specifications. Biddable domains can describe stakeholders requirements
and counter-stakeholders. Abuse frames consider the select
notions asset, threat, and vulnerability, which can be map-
SPF SPF
ped to the equally named notions of our CF. In contrast, the instantiate instance
notions domain knowledge and risk of our CF do not have a Step 1

counterpart considered by the abuse frames approach. match select

postconditions from catalogue
of
7.2 Security engineering process using patterns (SEPP) CSPF CSPF
instantiate instance
Step 2
(1) Description: To meet the special demands of software
development problems occurring in the area of security from catalogue extract
engineering, Hatebur et al. [77] introduce security problem preconditions
frames (SPF) and concretized security problem frames to be fulfilled

(CSPF). SPF are special kinds of problem frames, which

consider security requirements. They strictly refer to the consolidated set of
problems concerning security, without anticipating solu- security requirements
and solution approaches
tions. As an example, Fig. 10 shows the frame diagram of
the security problem frame for confidential data transmis- Fig. 11 Security engineering method using (C)SPFs (taken from
sion. The security requirement SR states that the Malicious [81])
subject should not be able to derive Sent data and Received
data using Transmitted data.
Solving a security problem is achieved by choosing and To solve a security problem characterized by an instance
instantiating a CSPF. These frames are derived from the of a security problem frame, the process continues with
security problem frames by considering generic security choosing a solution approach (e.g., symmetric or asym-
mechanisms (such as using encryption for confidential data metric encryption to keep data confidential during its
transmission). transmission), thereby instantiating appropriate CSPFs.
The authors equip both kinds of frames with a formal Afterwards, the preconditions of the instantiated CSPFs
description consisting of preconditions and postconditions must be inspected. To guarantee that the preconditions
[79]. These are expressed using logical formulas. The hold, two alternatives are possible: either they can be
preconditions express what conditions must be met by the assumed to hold, or they have to be established by using
environment for a frame to be applicable; the postcondi- some security problem frame whose postconditions match
tions are a formal representation of a (concretized) security the preconditions to be established.
requirement, i.e., they describe what (concretized) security In the second case, one must instantiate appropriate
requirement will be achieved by the machine to be built. SPFs, and the earlier-mentioned procedure is repeated until
A pattern system is derived by matching the precondi- all preconditions of all applied CSPFs can be proved or
tions of the CSPFs with the postconditions of the SPFs. assumed to hold. Therefore, the security requirements
The security engineering process using patterns (SEPP) engineering process will result in a set of security problems
[80] is illustrated in Fig. 11. Developing a secure system and solution approaches that additionally contains all
using (C)SPFs starts after the security goals and an initial dependent security problems and corresponding solution
set of security requirements are elicited. Then, each elicited approaches, some of which may not have been known
security requirement must be compared to the informal initially.
descriptions of the security requirements of the SPFs (e.g., The authors extended their method by linking the
if it turns out that data must be kept confidential during its solution approaches to security component templates,
transmission, the security problem frame of Fig. 10 is which can be connected to construct a secure software
applicable). After appropriate SPFs are identified for each architecture [82]. Furthermore, formal behavioral descrip-
given security requirement, these frames must be tions of SPFs and CSPFs can be used to formally describe
instantiated. security requirements and to prove refinement relations
To instantiate those domains that represent potential between SPF and CSPF instances [83].
attackers, a certain level of skill, equipment, and determi- (2) Scope: Hatebur et al. have defined a pattern-based
nation that a potential attacker might have must be security requirements engineering method that is applica-
assumed. Via these assumptions, threat models are inte- ble after the security goals and an initial set of security
grated into the method. requirements are elicited, resulting in a specification and a

123
Requirements Eng (2010) 15:7–40 29

software architecture consisting of component templates of (b) Generate threat descriptions: It is stated that
a secure system. Since no frames addressing availability security goals can be found by connecting the
goals are defined so far, the method can currently be used CIA concerns to the assets, which can be violated
to treat confidentiality and integrity goals. by certain actions to cause harm. Afterwards,
(3) Validation and QA: The pattern system is self-con- applying prevention to the resulting threat
tained in the sense that for any precondition of a frame descriptions leads to the security goals.
covered by the pattern system, there exists at least one (c) Apply management principles: According to the
frame contained in the pattern system that provides a authors, such principles can be separation of
matching postcondition. Therefore, the (C)SPFs contained duties, separation of function, etc.
in the pattern system can be used to completely analyze a
3. Identify security requirements: It is stated that
given security problem, whose initial security requirement
security requirements are constraints on functions
is covered by one of the frames.
of the system, where these constraints operationalize
Since Hatebur et al. use a graphical notation including
one or more security goals. The authors recommend
formal descriptions, tool support as well as automated
to draw problem diagrams to demonstrate the
validation and verification for their method is conceivable,
functional requirements and to support capturing
but not yet provided. The approach does not consider the
the security requirements in terms of constraints on
elicitation of the initial set of security requirements (only
the functions. The security requirements are denoted
dependent security requirements are elicited), a concrete
textually.
attacker model, conflicting requirements, nor interaction of
4. Construct satisfaction arguments: They show that the
security and other non-functional requirements. However, a
system can satisfy the security requirements (see
first paper addressing the latter two issues has already been
‘‘Validation and QA’’ for details).
published [84].
(4) Relation to conceptual framework: The notion of The framework for security requirements engineering
security requirement matches the same notion in our CF neither considers a formal foundation nor an attacker
presented in Sect. 2. The domain representing a potential model.
attacker, such as the Malicious subject domain in Fig. 10 (2) Scope: Haley et al. consider security requirements
correspond to the notions of a threat agent. Furthermore, elicitation and analysis, using their security engineering
the asset or information to be protected is represented as framework. It covers all three CIA goals.
(lexical) domains or shared phenomena. The notions of (3) Validation and QA: In [86], Haley et al. introduce
assumptions and facts (domain knowledge), specification, the notion of a trust assumption, which is ‘‘an assumption
naturally have the same meaning as the notions in our CF. by an analyst that the specification of a domain can
In contrast, the notions security goal, threat, vulnerability, depend on certain properties of some other domain in
and risk of our conceptual framework do not have a order to satisfy a security requirement’’. To decide
counterpart considered by SEPP. whether a system can satisfy the security requirements,
Haley et al. make use of structured informal and formal
7.3 Security requirements engineering framework argumentation [87]. A two-part argument structure for
(SREF) security requirement satisfaction arguments is proposed,
consisting of an informal and a formal argument. In
(1) Description: Haley et al. [28, 85] present a framework combination with trust assumptions, satisfaction argu-
for security requirements engineering. It defines the notion ments facilitate showing that a system can meet its
of security requirements, considers security requirements security requirements.
in an application context and helps answering the question The framework for security requirements engineering
whether the system can satisfy the security requirements. does not consider completeness of the set of requirements,
Haley et al. describe an iterative process consisting of four conflicting requirements (although it is mentioned that such
steps that integrates ordinary requirements engineering and conflicts can lead to inconsistent requirements), nor inter-
security requirements engineering: action between security and other non-functional
requirements.
1. Identify Business (Functional) Requirements.
(4) Relation to conceptual framework: The notions of
2. Identify security goals:
security goal and security requirement match the notions
(a) Identify candidate assets: The stated definition of of our conceptual framework. Haley et al. also distinguish
an asset is close to the ISO/IEC 13335-1 defini- quality and functional goals and requirements, which
tion: anything that has a value to the organization. matches the notions of non-functional and functional

123
30 Requirements Eng (2010) 15:7–40

goals and requirements of our conceptual framework. Again, 8.2 Tropos goal-risk framework
the notions of (trust) assumptions and facts (domain knowl-
edge), specification, asset, threat, and risk naturally have the (1) Description: Asnar et al. [90] propose the Tropos Goal-
same meaning as the notions of our CF. In contrast, the notion Risk Framework, an extension of earlier work [91], to
vulnerability of our CF is not considered by SREF. assess risk based on trust relations among actors. More
precisely, the extension comprises the introduction of the
notion trust as a ‘‘subjective probability that defines the
8 Risk analysis-based approaches
expectation of an actor about profitable behavior of another
actor’’ [90]. Trust, combined with the concept of delega-
In this section, we present approaches to security require-
tion of the fulfillment of a goal, enables the modeling of
ments engineering that are based on risk or threat analysis.
responsibility transfer from one actor to another. The
The presented techniques mainly focus on the elicitation of
authors introduce a three-layer model that comprises the
security goals and requirements, rather than analyzing them
goal, event, and treatment layers as an extension of the
with respect to further refinement or reconciliation of
original Tropos goal model. Goals are AND/OR decom-
possible conflicts.
posed and related to external events that can negatively
influence their satisfaction. Treatments are introduced to
8.1 CORAS
mitigate the effects of such events. The authors propose
qualitative risk reasoning techniques to support the analyst
(1) Description: CORAS [88] is a model-based method
in evaluating and choosing among different possible sub-
for security risk analysis. The CORAS method con-
goal trees. Additionally, the method is tool supported by
sists of seven steps:
the GR-Tool10. The method is described by a set of algo-
1. Introductory meeting between analysts and client to
rithms written in pseudo code notation.
clarify the client’s overall goals.
(2) Scope: The proposed Goal-Risk Framework by
2. Meeting with representatives of the client to clarify
Asnar et al. [90] comprises all software development steps
insights from first meeting and reading relevant
covered by Tropos. It covers security requirements elici-
documentation.
tation and analysis based on risk analysis.
3. More precise description of the target to be evaluated
(3) Validation and QA: QA is included in the approach
including assumptions made.
by integrating risk analysis techniques into security
4. Experts workshop to identify unwanted incidents such
requirements engineering. Risk analysis is used to evaluate
as threats and vulnerabilities.
alternative goals and to assess countermeasures to mitigate
5. Workshop to determine consequences and likelihoods
risks.
of the previously identified incidents.
(4) Relation to conceptual framework: Since Asnar
6. Presentation of a first risk analysis to the client to
et al. make use of the Tropos modeling framework, the
apply corrections.
notions security goal and security requirement correspond
7. Treatment Identification.
to the equally named notions of our conceptual frame-
The artifacts produced by analysts when applying the work. The notion security requirement is also used to
CORAS method are denoted in the CORAS security risk refer to a specification. Furthermore, the notions risk and
modelling language [89], which is inspired by UML [44]. threat (also called event) match the equally named
(2) Scope: CORAS is an organizational method that notions of our conceptual framework. The work by Asnar
covers threat, vulnerability, and risk analysis. It also covers et al. does not consider the notions domain knowledge,
the elicitation of security goals. asset, and vulnerability given in the conceptual
(3) Validation and QA: CORAS supports QA by framework.
intensive communication between analysts and clients. The
feedback from analysts and clients leads to improvements 8.3 Model-based information system security risk
in the quality of the artifacts produced. The CORAS management (ISSRM)
security risk modelling language [89] is equipped with a
structured semantics, which explains step-by-step how a (1) Description: Mayer et al. [66] propose a security
graphical CORAS model can be interpreted and how it can requirements engineering process that consists of the fol-
be translated into an English text. lowing four steps: context analysis and asset identification,
(4) Relation to conceptual framework: The notions security goal determination, refinement of these goals to
security goal, assumption, risk, threat, attack, and vulner- security requirements, and countermeasures selection. Both
ability match the notions of our CF. Most other notions
10
given in our CF are not considered by CORAS. http://www.troposproject.org/tools/grtool/

123
Requirements Eng (2010) 15:7–40 31

of the latter two steps are based on a risk analysis approach Owner
impose value
named model-based ISSRM. wish to
minimize
Thereby, Mayer et al. propose to make use of Yu’s i*
[57, 58] requirements engineering techniques, which can
reduce
also be used to deal with security requirements [69]. Countermeasure Risk

(2) Scope: The proposed method by Mayer et al. com-

prises security requirements elicitation driven by a risk increase to

analysis method. It also supports analyzing security give rise to

Threat Agent Threat to Asset
requirements through context and asset analysis.
(3) Validation and QA: The work by Mayer et al. does wish to abuse and / or may damage

not describe special QA treatments. Since it makes use of

the i* modeling framework, possibly QA procedures from Fig. 12 Common Criteria—general model
this requirements engineering approach can be applied.
(4) Relation to conceptual framework: Mayer et al. modification, however, it is less suited to be used as a
make use of the i* modeling framework. Hence, the notions single common ground for security requirements engi-
security goal and security requirement correspond to the neering (as proposed by [34]). Further, the General Model
equally named notions of our CF. The notion security does not consider multilateral security.
requirement is also used to refer to a specification. Fur- The main concepts in Fig. 12 are defined as follows.
thermore, the notions assumption, risk, threat, attack, and Assets are defined as entities that the owner of the TOE
vulnerability match the equally named notions of our CF. places value upon; protecting assets is the responsibility of
The work by Mayer et al. does not consider the remaining the TOE owner. Other stakeholders and their security goals
notions given in our CF. are not considered here, though in further documents on
SFR (see below) the protection of user data is mentioned.
Threat agents seek to abuse assets in a manner contrary to
9 Common criteria-based approaches the goals (interests) of the owner, leading to potential
reduction of the asset value for the owner.
9.1 Common Criteria (CC) Threats include the loss of asset confidentiality, integrity
or availability—but these threatened security goals are not
(1) Description: The Common Criteria are an international made explicit in the CC model. This is a drawback for
standard to achieve comparability between the results of requirements engineering and gives also rise to CC-internal
independent security evaluations of IT products inconsistencies between asset definition and asset examples
(machines). Such a machine, which may consist of hard- (e.g., in [1], Part 1, p. 34).
ware and software, is called Target of Evaluation (TOE). Threats imply risk to the assets, based on the likelihood
The name Common Criteria is an abbreviation for the and the impact of the threat being realized. Countermeasures
Common Criteria for Information Technology Security are imposed by the owner to reduce the risks. These coun-
Evaluation [1]. The current version is 3.1, dating from termeasures comprise IT countermeasures (e.g., firewalls)
September 2006. The CC are also known as ISO/IEC and non-IT countermeasures (e.g., guards, procedures).
15408. The CC are compiled by a consortium of govern- Three main phases can be identified in a CC process (cf.
mental organizations. Contributing countries include Aus- Fig. 13). Potential TOE owners infer from their security
tralia/New Zealand, Canada, France, Germany, Japan, goals (called security needs in the CC) the need for specific
Netherlands, Spain, United Kingdom, and the United types of security machines, which are types of TOE. These
States. are refined into documents called Protection Profiles (PP).
With respect to notation, the CC use natural language On the other hand, we have TOE developers or vendors
for all of its concepts, as well as for the TOE and its who claim that their specific machine conforms to abstract
properties. However, some concepts such as Security PP. They publish their claims in documents called Security
Functional Requirements (SFR) are formulated using a Targets (ST). In between, there is the actual CC evaluation
standardized language for enhanced exactness and process that checks these claims and can describe the
comparability. confidence into its evaluation results according to standard
The CC standards present a General Model of some assurance levels.
basic concepts (see Fig. 12, cf. [1]) that are drawn from The specific concepts of the CC used in this evaluation
traditional security engineering concepts. This model process are defined as follows. The Target of Evaluation
reflects the main scope and origin of the CC (evaluation of (TOE) is a set of software, firmware, and/or hardware
specific IT security products). Without adaptation and possibly accompanied by guidance. For requirements

123
32 Requirements Eng (2010) 15:7–40

Fig. 13 Common Criteria—

Asset Owner Security Needs
specific concepts

Need for Security

Product Type
Security Needs
User Groups

Protection Profile
PP Evaluation PP Catalogues Governments
(PP)

Corporations

Conformance ST/TOE
Evaluation Claim Evaluation
Evaluator

Development Security Target TOE Developer /

(ST) (Specific Product) Vendor

Security Problem TOE Summary Security

Definition Specification Objectives

TOE Security Operational Environment

Threats Assumptions
Objectives Security Objectives

Security Functional Security Assurance

Requirements (SFR) Requirements (SAR)

engineering purposes, it can be considered as the machine, Security Target

or as part of a larger machine that is responsible for
security functionality.
A Protection Profile (PP) is an implementation-inde- ST Introduction

pendent statement of security needs for a TOE type. A PP

describes a TOE type (e.g. firewalls). A PP is described as a
Conformance Claims PP / Package Conformance Claim
security specification on a relatively high level of
abstraction and should not contain detailed protocol
Threats
specifications, or concrete descriptions of algorithms or Security Problem
Organisational Security Policy (OSP)
Definition
operations. There are attempts to extend the PP concept to Assumptions

very large systems using system-level protection profiles

SO for TOE
(SLPP). For challenges involved in this approach, cf. [92]. Security Objectives (SO)
SO for Operational Environment
In contrast to a PP, the Security Target (ST) describes a
specific TOE (see Fig. 14). It is an implementation-depen-
dent statement of security needs for a specific identified Extended Components
Definition
TOE. PP and ST have nearly the same structure. They
contain an introduction, which includes descriptions of the Security Functional Requirements (SFR)
Security Requirements
TOE on different levels of abstraction. The Conformance Security Assurance Requirements (SAR)

Claim shows whether and to which PP the ST claims con-

formance. The Security Problem Definition includes the TOE Summary
Specification
threats to be countered, the Organisational Security Policies
(OSP) to be enforced, and assumptions to be fulfilled by the Fig. 14 Common Criteria—security target (ST)
combination of the TOE and its operational environment.
Further, the ST and PP contain Security Objectives for
the TOE and for the operational environment to solve the specifications for a security machine) that provide a
security problem at hand. These are refined into Security translation of the security objectives for the TOE into
Requirements (in terms of the CC, that is functional Security Functional Requirements (SFR) and that use a

123
Requirements Eng (2010) 15:7–40 33

standardized language. In addition, Security Assurance such as the Evaluation Assurance Levels (EAL 1-7) can be
Requirements (SAR) for the evaluation process are stated. used, cf. [1] Part 3.
Finally, the ST (but not the PP) contains a TOE Summary Security requirements in the CC are functional (or
Specification that indicates how the SFRs are implemented assurance) requirements; other functional or non-functional
in the TOE. requirements are not considered if they are not ‘‘relevant’’
The CC make use of patterns. The SFR used in the CC to the security functionality. However, no systematic
are textual patterns for specifications. SFR can be com- approach is presented to identify this relevance. Require-
bined into named sets in the CC, for example, packages, ments conflicts in general are not explicitly considered, and
families, and classes. One explicit goal of the CC is to correspondingly there are no ideas or methods for negoti-
make these patterns available in public catalogs for reuse. ation presented in the CC.
In a different sense, the whole PP is a pattern for a type of (4) Relation to conceptual framework: The CC security
(security) machine and its specification. needs correspond to security goals in our CF. The security
(2) Scope: The CC standard itself does not present an objectives in the PP could be mapped not only to our
actual requirements engineering method. security requirements, whereas the security objectives in the
However, it is an important standard in the field of ST and especially the SFR correspond to specifications, but
security engineering, and establishes its own body of also to more detailed design and implementation properties.
security engineering concepts and standardized language. It The CC assumptions and security objectives for the oper-
influences security requirements engineering methods such ational environment refer to domain knowledge in our CF.
as SREP [93] (discussed in the next section).
The CC are mainly concerned with security function-
9.2 Security requirements engineering process (SREP)
ality and its assurance.
The CC are not concerned with legal aspects, evaluation
(1) Description: Mellado et al. [93, 94] present a Security
of cryptographic algorithms or administrative security
Requirements Engineering Process (SREP). SREP is an
measures. Assumptions on the operational environment are
iterative and incremental security requirements engineering
to be stated explicitly.
process, which is based on the Unified Process [95] soft-
CC evaluations can comprise all three major high-level
ware life-cycle model with multiple phases. Further, SREP
goals of information security (confidentiality, integrity,
is asset-based, risk driven, and, following the Common
availability), as well as many subaspects, which are refined
Criteria [1] (CC) supports the reuse of security require-
in high detail using the corresponding catalogs. Threats, risk,
ments, as well as the reuse of knowledge on assets, threats,
and countermeasures are an integral part of the method as
and countermeasures.
well. These concepts are included in the General Model of
In SREP, UML [44] use cases are used to model security
the CC (cf. Fig. 12). Threats are an important part of a CC
objectives, and misuse cases (see Sect. 5.1) are used to
evaluation and are included in the corresponding documents,
elicit threats [96]. Furthermore, a template is suggested for
such as the Protection Profile and the Security Target. The
ranking threats, attacks, and risks. Security objectives and
actual evaluation methodology is described separately.
threats are modeled with use case and misuse case dia-
(3) Validation and QA: In general, it is the task of the
grams, threat specification is done using template-based
(potential) TOE owners to check for the completeness of
misuse cases, while security requirements are specified
the requirements, as well as to check if their security needs
using template-based use cases.
are met by the security target. Large user groups, corpo-
Based on the CC, the authors propose a Security
rations, and governments can develop and evaluate Pro-
Resources Repository (SRR), which stores all the reusable
tection Profiles that can be incorporated into public PP
security elements. A metamodel of the SRR is shown in
catalogs and reused. This procedure should increase their
Fig. 15 where the darker objects identify the extension of
soundness and relative completeness. In addition, depen-
SREP to the repository metamodel as suggested by [96].
dencies between Security Functionality Requirements
SREP is applied by working through the following nine
(SFR) are explicitly considered, which aids in achieving
activities:
completeness. However, the CC standard does not provide
a formal semantic model. 1. Agree on definitions: The development or security
The actual evaluation method for the CC is not part of analysis teams agree on a set of security definitions,
the main standard. But one of the main goals of the CC is to organizational security policies, and the security
assign an assurance level to the result of evaluation pro- visions of the information system. These definitions
cedures. Assurance in CC terms is defined as grounds for are then built into the Security Vision Document,
confidence that a TOE meets the SFRs. To express and which lists the most important assets of the informa-
compare this degree of confidence, assurance packages tion system.

123
34 Requirements Eng (2010) 15:7–40

Fig. 15 SREP metamodel for

the security resources repository Plain Security
Use Case UMLSec
(SRR) Text
Misuse Threat/ Plain
Cases Attack Tree Text

attached to
Security Requirement
broken
Cluster Specification
Security down to
Threat Objective
Specification target 1..*
by Asset 1
1..* 1..*
Security
1 0..* Security
Requirement
mitigate Test
Cluster
Threat
0..* 0..*

1..*

Counter
req-req Security 1..* 0..* Measure
Generic Specific 0..* Requirement
Threat Threat
1 0..*

Generic Specific
Security Security
Requirement Requirement

1 0..*

2. Identify vulnerable and/or critical assets: An analysis well as the possible frequency of an attack. The results
of the functional requirements identifies important are captured in the Risk Assessment Document.
assets. Assets can be information, tangible assets 6. Elicit security requirements: Each security objective is
(money, products), or intangible assets (reputation). analyzed for possible relevance and the threats it
The result is a more in-depth analysis of assets than in poses. This analysis is then used to identify the suitable
the Security Vision Document. security requirements that mitigate the threats at the
3. Identify security objectives and dependencies: If the necessary levels according to the risk assessment.
type of assets identified in the previous activity can be Here, the interaction between security objectives,
found in the SRR, then their associated security functional requirements, and threats are handled. The
objectives are retrieved. If not, the security objectives results are collected in the Security Requirements
for each asset are determined, also taking into account Specification Document.
organizational and legal restrictions. The list of security 7. Categorize and prioritize requirements: According to
objectives should be refined in subsequent iterations by the risk, the security requirements are ranked.
establishing dependencies between the security objec- 8. Requirements inspection: The CC assurance require-
tives. These are then compiled in the Security Objec- ments are used to validate the security requirements. If
tives Document, using the CC assurance classes. all security objectives are fulfilled, all security require-
4. Identify threats and develop artifacts: If the assets can be ments are satisfied, and all the threats are countered,
found in the SRR, then it is possible to retrieve their then the security problem is assumed to be solved. This
associated threats from the repository. If not, use cases, result is then captured in the Security Requirements
misuse cases, and threat-attack trees can be applied. Rationale Document.
Further, public-domain sources and threat lists for the 9. Repository improvement: The SRR can be extended with
type of assets selected and following the CC assurance new elements. Part of this activity is the writing up of the
requirements for identifying potential vulnerabilities are Security Target (ST) document as it is defined in the CC.
utilized.
None of the SREP activities has a formal foundation.
5. Risk assessment: The probability of each threat is
The analysis of threats, attacks, and risks are indispensable
determined, as well its potential impact and risk. The
to the method. They are used to elicit the security objec-
authors use tables (based on the method MAGERIT
tives and the security requirements.
[97]), in which they quantify the impact and risk as

123
Requirements Eng (2010) 15:7–40 35

(2) Scope: The method can be applied once the func- functional goals are not a focus of the method. The spec-
tional requirements analysis has been completed. Since ification refers to both system requirements and the spec-
SREP is based on the CC, it considers all three CIA goals. ification in the CF. Further, the specification is supposed to
(3) Validation and QA: SREP considers the complete- come close to a specification of the design of the security
ness of the set of requirements in Activity 8. If all security mechanisms to be implemented in the machine.
requirements are satisfied, and all security objectives are The analysis is made at the level of use cases, and hence
achieved, and all the threats are countered, then the secu- circumstances or similar abstractions are not used. The
rity problem is assumed to be solved. The consistency and authors perform a much more detailed taxonomy of assets and
completeness of requirements are improved by reusing a continuous analysis of the interplay between risks, threats,
(and iteratively refining) requirements in the SRR over and countermeasures. Preconditions in the use cases can be
several projects. interpreted in some cases as environmental assumptions.
The interaction with functional requirements is consid-
ered in Activity 6. Other non-functional requirements are
mentioned as important, but are not picked up in the 10 Comparison of security requirements engineering
method description. Conflicts are mentioned in the meta- methods
model [93]. But, although the authors address the impor-
tance of analyzing conflicts, they do not come back to the Tables 5, 6, and 7 present mappings of main concepts of
topic in any of their activities. our CF to notions used by the previously presented SRE
(4) Relation to conceptual framework: The terminology methods. Here, the notion security requirement (CF) for
of SREP is mapped onto our conceptual framework in the simplicity encompasses both the levels of security
following manner. Security objectives stand for both the requirement and security system requirement in the
security goals and security requirements in the CF. The abstraction hierarchy of security properties (Fig. 2), with-
agreement of stakeholders is mentioned in the ‘‘require- out referring to the state of reconciliation in detail.
ments inspection’’ activity. Otherwise, stakeholder views A table entry labeled with  means that the notion
are not part of the method. It is assumed that the elabora- defined in the considered approach is used in a narrower
tion of functional goals are completed. Other non- sense than the notion defined by our CF. An empty entry

Table 5 Mapping of notions used in SRE methods to our conceptual framework

Method Notions of our conceptual framework
Security goal (CF) Security requirement (CF) Specification (CF)

MSRA * * *
SQUARE * System-level req. Software-level req.
Misuse cases * – Security req.
SecureUML – – Security req.
UMLsec – – Security req.
KAOS ? anti-models * * *
Secure Tropos (Mouratidis et al.) Softgoal, security constraint/feature, cf. Security goal cf. Security goal
Secure entity
Secure i* Softgoal / * cf. Security goal cf. Security goal
Secure Tropos (Massacci et al.) Softgoal, security constraint/property cf. Security goal cf. Security goal
GBRAM * * *
Abuse frames Security objective Negated anti-req. Security req.
SEPP – * *
SREF * * *
CORAS * – –
Tropos goal-risk FW Softgoal / * cf. Security goal cf. Security goal
Model-based ISSRM Softgoal / * cf. Security goal cf. Security goal
CC Security need Security objective (PP) Sec. objective (ST),
SFR
SREP Security objective * *

123
36 Requirements Eng (2010) 15:7–40

Table 6 Mapping of notions used in SRE methods to our conceptual framework

Method Notions of our conceptual framework
Stakeholder (CF) Domain knowledge (CF) Asset (CF)

MSRA * * Information
SQUARE  Client – –
Misuse cases  Actor – *
SecureUML  User – –
UMLsec  Actor Assumption –
KAOS ? anti-models  Agent Domain properties,  object
Expectation
Secure Tropos (Mouratidis et al.)  Actor – –
*
Secure i  Actor – *
Secure Tropos (Massacci et al.)  Actor – –
GBRAM * – Asset/information
Abuse frames  Biddable domain – *
SEPP  Biddable domain Fact, assumption  Lexical domain,
Phenomenon
SREF  Biddable domain  Fact, trust assumption *
CORAS – Assumption *
Tropos goal-risk FW  Actor – –
Model-based ISSRM  Actor Context *
CC TOE owner (general model), user (SFR) Assumption, oper. env. *
Security objective
SREP – *

Table 7 Mapping of notions

Method Notions of our conceptual framework
used in SRE methods to our
conceptual framework Threat (CF) Vulnerability (CF) Risk (CF)

MSRA – – –
SQUARE * – *
Misuse cases * – *
SecureUML – – –
UMLsec * * *
KAOS ? anti-models * * –
Secure Tropos (Mouratidis et al.) * * *
Secure i* * * –
Secure Tropos (Massacci et al.) – – –
GBRAM * * *
Abuse frames * * –
SEPP – – –
SREF * – *
CORAS * * *
Tropos goal-risk FW event / * – *
Model-based ISSRM * * *
CC * * *
SREP * * *

means that a comparison is not possible because the con- notion in the considered approach. Entries labeled with *
sidered notion is not defined in detail in this method. An denote that the notion used in this approach matches the
entry labeled with—indicates that there is no comparable notion defined by our CF.

123
Requirements Eng (2010) 15:7–40 37

Table 8 Comparison of security requirements engineering methods

Method Criteria
Considers: Stakeholder views? Multi-lateral? Oriented toward Includes QA? Formality?
CIA Other reqs. System Machine Threats Risks

MSRA 9 9 9 9 9
SQUARE 9 9 9 9 9 9 9 9 9
Misuse cases 9 9 9 9 9
SecureUML 9 9
UMLsec 9 9 9 9 9
KAOS ? anti-models 9 9 9 9 9 9 9 9 9
Secure Tropos 9 9 9 9 9 9 9 9
(Mouratidis et al.)
Secure i* 9 9 9 9 9 9 9 9
Secure Tropos 9 9 9 9 9 9 9 9
(Massacci et al.)
GBRAM 9 9 9 9 9
Abuse frames 9 9 9
SEPP 9 9 9 9 9
SREF 9 9 9 9 9 9 9
CORAS 9 9 9 9 9
Tropos goal-risk FW 9 9 9 9 9 9 9 9
Model-based ISSRM 9 9 9 9 9 9 9
CC 9 9 9 9 9 9
SREP 9 9 9 9 9 9

Table 8 summarizes the presentation of the methods in There is no clear-cut distinction between methods
the preceding sections. The criteria in the table correspond addressing mostly security goals and requirements, and
to the central concepts of the framework presented in Sect. methods that are more oriented toward the machine and its
2. An entry in the table indicates that the authors of a specification. Only the UML-based methods do not take
method explicitly consider a criteria. However, the free environmental issues into account, whereas only MSRA
cells of the table do not imply that a method could not does not derive a specification of the machine.
cover a criteria. All methods but MSRA and SecureUML consider
Most methods consider the complete CIA triad. Some of threats. The concept of a counter-stakeholder in MSRA
them also address other requirements than security cannot be considered a threat agent, because it does not
requirements. imply that the counter-stakeholder will threaten the system.
Although it is generally accepted that a unilateral view SecureUML is concerned with access control only.
to security is outdated and the views of different stake- Therefore, general threat analysis is out of the scope of this
holders must be taken into account in SRE, only MSRA, method.
SQUARE, KAOS and the Secure Tropos variants explicitly Risk analysis is often considered an important aspect
address this issue. This does not mean that it is impossible of security requirements engineering. Hence, the risk-
to consider the views of different stakeholders using the based approaches, CC, SREP, and Misuse Cases put it
other methods. However, they do not capture this issue in into the center of attention. SQUARE devotes two steps
their various activities. to risk analysis. To some extent, GBRAM also considers
Multilateral security stresses the fact that stakeholders risks.
do not only have justified different security concerns, but The majority of the methods provide means for quality
that these concerns also are often inherently contradictory, assurance.
and a compromise must be established between them in a Finally, while several methods cover most of the criteria
way that incorporates all stakeholders, explicitly. MSRA is mentioned in Table 8, the UML-based approaches and
the only method that proposes steps to address this issue. Abuse Frames have a narrower scope of application.

123
38 Requirements Eng (2010) 15:7–40

11 Conclusion and perspectives 2. Bishop M (2003) Computer security. Addison-Wesley, New York
3. Viega J, McGraw G (2001) Building secure software: how to
avoid security problems the right way. Addison-Wesley, New
This article contributes to security requirements engineering York
in two major aspects: first, it introduces a conceptual frame- 4. Eckert C (2004) IT-Sicherheit, 3rd edn. Oldenbourg-Verlag,
work for security requirements engineering that relates the München
central concepts used in this field; second, it maps the diverse 5. Firesmith DG (2003) Common concepts underlying safety,
security, and survivability engineering. Carnegie Melon Univer-
terminologies of different methods to that framework, facil- sity. Technical report SEI-2003-TN-033
itating access to those methods and their comparison. 6. Rupp C, SOPHIST GROUP (2003) Requirements-engineering
There, apparently, is no established terminology for the und -management, 3rd edn. Carl Hanser Verlag
field of security requirements engineering. The literature 7. Rannenberg K, Pfitzmann A, Müller G (1999) IT security and
multilateral security. In: Müller G, Rannenberg K (eds) Multi-
often uses the same notions, such as ‘‘requirement’’ or lateral security in communications—technology, infrastructure.
‘‘asset’’, for different, though related, concepts. The con- Economy Addison-Wesley, pp 21–29
ceptual framework of Sect. 2 distinguishes the different 8. Zave P, Jackson M (1997) Four dark corners of requirements
concepts such as security goals, requirements, specifica- engineering. ACM Trans Softw Eng Methodol 6(1):1–30
9. Fricker S, Gorschek T, Glinz M (2008) Goal-oriented require-
tions, and security properties, and thus provides a consis- ments communication in new product development. In: Pro-
tent terminology. Mapping the terminology of a particular ceedings of the international workshop on software product
method to the conceptual framework allows to assess the management. IEEE Computer Society, Los Alamitos, pp 27–34
scope of the method—and, therefore, also its usefulness for 10. Liu L, Yu E (2001) From requirements to architectural design
using goals and scenarios. In: Proceedings of the international
a given purpose. workshop from software requirements to architectures (STRAW).
We consider a common case study to compare these Toronto
methods as a very desirable effort for the future. A common 11. Antòn AI, Earp JB (2000) Strategies for developing policies and
illustrative example could help practitioners and academia requirements for secure electronic commerce systems. Depart-
ment of Computer Science, North Carolina State University.
to select a method that fits their application area best. Technical report TR-2000-09. [Online]. Available: cite-
Moreover, the integration of the different SRE methods seer.ist.psu.edu/anton00strategies.html
comprises a challenging, but worthwhile improvement for 12. Mylopoulos J, Chung L, Nixon B (1992) Representing and using
future research directions. In fact, methods such as the Tropos non-functional requirements: a process-oriented approach. IEEE
Transactions on Software Engineering pp 483–497
variants, KAOS, i*, and SEPP have strong focus on 13. Sommerville I (2007) Software Engineering, 8th edn. Addison
requirements engineering. Still, the artifacts produced during Wesley, New York
this development phase involve the difficulty of how to use 14. Glinz M (2007) On non-functional requirements. In: Proceedings
them as a basis for the design phase. Therefore, the methods of 15th IEEE international requirements engineering conference
(RE ’07), pp 21–26
focusing on security requirements engineering should be 15. Jureta I, Mylopoulos J, Faulkner S (2008) Revisiting the core
combined with those that focus on the design of secure soft- ontology and problem in requirements engineering. In: Proceed-
ware and systems, such as UMLsec and SecureUML. ings of 16th IEEE international requirements engineering con-
Also, the key features of the rather new developments ference (RE ’08), pp 71–80
16. Information technology—security techniques—code of practice
such as the risk-driven approach model-based ISSRM, and for information security management (ISO/IEC FDIS 17799:2005)
the multilateral methods MSRA and SQUARE, should be (2005) International Organization for Standardization
integrated into the more sophisticated methods such as the 17. Information technology—security techniques—management of
Tropos variants and KAOS. A first attempt in this direction information and communications technology security—part 1:
Concepts and models for information and communications
constitutes the Tropos Goal-Risk Framework [90]. technology security management (ISO/IEC 13335-1:2004)(2004)
Not least, the consideration of further quality require- International Organization for Standardization
ments besides security, adaption to continuous changes in 18. NIST SP 800-26: Security Self-Assessment Guide for Informa-
technology and business demands, and methods for tion Technology Systems (2001) National institute of standards
and technology
requirement conflict resolution are important directions for 19. Berry DM, Lawrence B (1998) Guest editors’ introduction:
future work. requirements engineering. IEEE Softw 15(2):26–29
20. Robinson WN, Pawlowski SD, Volkov V (2003) Requirements
Acknowledgments We thank the anonymous reviewers for their interaction management. ACM Comput Surv 35(2):132–190
helpful comments and suggestions. 21. Finkelstein A, Baggay D, Hunter A, Kramer J, Nuseibeh B (1994)
Inconsistency handling in multi-perspective specifications. IEEE
Trans Softw Eng (20):569–578
22. Easterbrook S, Nuseibeh B (1996) Using viewpoints for incon-
References sistency management. Softw Eng J 31–43
23. Kotonya G, Sommerville I (1996) Requirements engineering with
1. Common Criteria for Information Technology Security Evalua- viewpoints. BCS/IEE Softw Eng J 11(1):5–18
tion, Version 3.1. (2006) [Online]. Available: http://www. 24. Giorgini P, Massacci F, Mylopoulos J, Zannone N (2006)
commoncriteriaportal.org/public/expert/ Detecting conflicts of interest. In: Proceedings 14th IEEE

123
Requirements Eng (2010) 15:7–40 39

international requirements engineering conference (RE ’06). 42. Mead N, Hough E, Stehney T (2005) Security quality require-
IEEE Computer Society, pp 308–311 ments engineering (SQUARE) methodology. Carnegie Mellon
25. van Lamsweerde A, Darimont R, Massonet P (1998) Managing Software Engineering Institute, Technical report CMU/SEI-2005-
conflicts in goal-driven requirements engineering. IEEE Trans TR-009
Softw Eng 24 43. Mead N, Viswanathan V, Padmanabhan D, Raveendran A (2008)
26. Jackson M, Zave P (1995) Deriving specifications from require- Incorporating security quality requirements engineering
ments: an example. In: Proceedings 17th international conference (SQUARE) into standard life-cycle models. Carnegie Mellon
on software engineering. ACM Press, Seattle, pp 15–24 Software Engineering Institute. Technical report CMU/SEI-2008-
27. Haley B, Laney C, Moffett D, Nuseibeh B (2006) Using trust TN-006
assumptions with security requirements. Requir Eng 11(2):138– 44. UML Revision Task Force (2006) OMG unified modeling lan-
151 guage: superstructure. http://www.omg.org/docs/ptc/06-04-02.pdf
28. Haley CB, Laney R, Moffett J, Nuseibeh B (2008) Security 45. Sindre G, Opdahl AL (2001) Capturing security requirements by
requirements engineering: a framework for representation and misuse cases. In: Proceedings of the 14th Norwegian informatics
analysis. IEEE Trans Softw Eng 34(1):133–153 conference (NIK’2001)
29. Santen T (2006) Stepwise development of secure systems. In 46. Sindre G (2007) Mal-activity diagrams for capturing attacks on
Górski J (ed) International conference on computer safety, reli- business processes. In: Sawyer P, Paech B, Heymanns P (eds) Pro-
ability and security (SAFECOMP), ser. LNCS 4166. Springer, pp ceedings of REFSQ 2007, ser. LNCS 4542. Springer, pp 355–366
142–155 47. Lodderstedt T, Basin DA, Doser J (2002) SecureUML: a UML-
30. Moffett JD, Haley CB, Nuseibeh B (2004) Core security based modeling language for model-driven security. In: Pro-
requirements artifacts. The Open University, UK (technical ceedings of the 5th international conference on the unified
report) modeling language (UML’02). Springer, London, pp 426–441
31. Breaux TD, Antòn A (2005) Analyzing goal semantics for rights, 48. UML Revision Task Force (2006) OMG object constraint lan-
permissions, and obligations. In: Requirements engineering, pp guage: reference. http://www.omg.org/docs/formal/06-05-01.pdf
177–188 49. Jürjens J (2003) Secure systems development with UML.
32. Mayer N (2009) Model-based management of information system Springer, New York
security risk. Ph.D. dissertation, University of Namur [Online]. 50. Bertrand P, Darimont R, Delor E, Massonet P, van Lamsweerde
Available: http://www.nmayer.eu/publis/Thesis_Mayer_2.0.pdf A (1998) GRAIL/KAOS: an environment for goal drivent
33. Mayer N, Heymans P, Matulevičius R (2007) Design of a mod- requirements engineering. In: ICSE’98—20th international con-
elling language for information system security risk management. ference on software engineering
In: 1st International conference on research challenges in infor- 51. Dardenne A, van Lamsweerde A, Fickas S (1993) Goal-directed
mation science (RCIS 2007) requirements acquisition. Sci Comput Program 20(1–2):3–50
34. Mellado D, Fernandez-Medina E, Piattini M (2006) A compari- 52. van Lamsweerde A (2004) Elaborating security requirements by
son of the Common Criteria with proposals of information sys- construction of intentional anti-models. ICSE pp. 148–157
tems security requirements. In: ARES ’06: proceedings of the 53. Bresciani P, Perini A, Giorgini P, Giunchiglia F, Mylopoulos J
first international conference on availability, reliability and (2004) Tropos: an agent-oriented software development meth-
security (ARES’06). IEEE Computer Society, Washington, DC, odology. Auton Agent Multi Agent Syst 8(3):203–236
pp 654–661 54. Giorgini P, Susi A, Perini A, Mylopoulos J (2005) The tropos
35. Kalloniatis C, Kavakli E, Gritzalis S (2004) Security require- metamodel and its use. Inf J 29:401–408
ments engineering for e-government applications: analysis of 55. Fuxman A, Liu L, Mylopoulos J, Pistore M, Roveri M, Traverso
current frameworks. Springer, Berlin P (2004) Specifying and analyzing early requirements in tropos.
36. Tøndel I, Jaatun M, Meland P (2008) Security requirements for Requir Eng J 9(2):132–150
the rest of us: asurvey. Softw IEEE 25(1):20–27 56. Yu ES-K (1996) Modelling strategic relationships for process
37. van Lamsweerde A (2007) Engineering requirements for system reengineering. Ph.D. dissertation, University of Toronto, Toronto
reliability and security. In: Broy JGM, Hoare C (eds) Software 57. Yu ESK (1997) Towards modeling and reasoning support for
system reliability and security, ser. NATO security through sci- early-phase requirements engineering. In: RE ’97: proceedings of
ence series-D: information and communication security, vol 9. the 3rd IEEE international symposium on requirements engi-
IOS Press, pp 196–238 neering. IEEE Computer Society, Washington, DC, p 226
38. Gürses S, Santen T (2006) Contextualizing security goals—a 58. Yu ESK, Liu L (2001) Modelling trust for system design using the
method for multilateral security requirements elicitation. In: i* strategic actors framework. In: Proceedings of the workshop on
Dittmann J (ed) Proceedings of Sicherheit 2006—Schutz und deception, fraud, and trust in agent societies held during the
Zuverlässigkeit, ser. Lecture notes in Informatics. Gesellschaft autonomous agents conference. Springer, London, pp 175–194
für Informatik, pp 42–53 59. Giorgini P, Mouratidis H, Zannone N (2007) Modelling security
39. Gürses S, Berendt B, Santen T (2006) Multilateral security and trust with secure tropos. In: Integrating security and software
requirements analysis for preserving privacy in ubiquitous envi- engineering: advances and future vision. IDEA
ronments. In: Berendt B, Menasalvas E (eds) Proceedings of 60. Mouratidis H, Giorgini P (2007) Secure tropos: a security-ori-
workshop on ubiquitous knowledge discovery for users ented extension of the tropos methodology. Int J Softw Eng
(UKDU’06) [Online]. Available:http://www.vasarely.wiwi. Knowl Eng 17(2):285–309
hu-berlin.de/UKDU06/Proceedings/UKDU06-proceedings.pdf 61. Mouratidis H, Giorgini P (2004) Enhancing secure tropos to
40. Gürses S, Jahnke JH, Obry C, Onabajo A, Santen T, Price M effectively deal with security requirements in the development of
(2005) Eliciting confidentiality requirements in practice. In: multiagent systems. In: Proceedings of the 1st international
CASCON ’05: Proceedings of the 2005 conference of the centre workshop on safety and security in multiagent systems, SASEMAS
for advanced studies on collaborative research. IBM Press, pp 62. Mouratidis H, Giorgini P (2005) Secure tropos: dealing effec-
101–116 tively with security requirements in the development of multi-
41. Onabajo A, Weber-Jahnke J (2008) Stratified modeling and agent systems. In: Proceedings of the 2nd international workshop
analysis of confidentiality requirements. In: 41st Annual Hawaii on safety and security in multi-agent systems, SASEMAS, ser.
international conference on system sciences Computers & Security, vol 24, no.8. Elsevier, pp 614–617

123
40 Requirements Eng (2010) 15:7–40

63. Massacci F, Mylopoulos J, Zannone N (2007) Ontologies for international conference on availability, reliability and security
business interaction. Information science reference, ch. An (AReS). IEEE Computer Society, pp 356–365
ontology for secure socio-technical systems pp 188–207 81. Hatebur D, Heisel M, Schmidt H (2007) A security engineering
64. Elahi G, Yu E (2007) A goal oriented approach for modeling and process based on patterns. In: Proceedings of the international
analyzing security trade-offs. University of Toronto, Department workshop on secure systems methodologies using patterns
of Computer Science. Technical report (SPatterns). IEEE Computer Society, pp 734–738
65. Matulevičius R, Mayer N, Mouratidis H, Dubois E, Heymans P, 82. Hatebur D, Heisel M, Schmidt H (2008) Analysis and compo-
Genon N (2008) Adapting secure tropos for security risk man- nent-based realization of security requirements. In: Proceedings
agement in the early phases of information systems development. of the international conference on availability, reliability and
In: CAiSE ’08: proceedings of the 20th international conference security (AReS). IEEE Computer Society, pp 195–203
on advanced information systems engineering. Springer, Berlin, 83. Schmidt H (2009) Pattern-based confidentiality-preserving
pp 541–555 refinement. In: Engineering secure software and systems—first
66. Mayer N, Rifaut A, Dubois E (2005) Towards a risk-based international symposium (ESSoS), ser. LNCS, vol 5429.
security requirements engineering framework. In: Proceedings of Springer, Berlin, pp 43–59
the 11th international workshop on requirements engineering: 84. Schmidt H, Wentzlaff I (2006) Preserving software quality
foundation for software quality (REFSQ’05), in conjunction with characteristics from requirements analysis to architectural design.
the 17th conference on advanced information systems engineer- In: Proceedings of the European workshop on software archi-
ing (CAiSE’05) tectures (EWSA), vol 4344/2006. Springer, Berlin, pp 189–203
67. Bauer B, Müller JP, Odell J (2001) Agent UML: a formalism for 85. Haley CB, Moffett JD, Laney R, Nuseibeh B (2006) A framework
specifying multiagent software systems. Int J Softw Eng Knowl for security requirements engineering. In: SESS ’06: proceedings
Eng 11(3):207–230 of the 2006 international workshop on Software engineering for
68. Giorgini P, Manson G, Mouratidis H (2004) Using security attack secure systems. ACM Press, New York, pp 35–42
scenarios to analyse security during information systems design. 86. Haley C, Laney R, Moffett J, Nuseibeh B (2004) Picking battles:
In: The 6th international conference on enterprise information the impact of trust assumptions on the elaboration of security
systems. Porto requirements. In: Jensen CD, Poslad S, Dimitrakos T (eds)
69. Liu L, Yu E, Mylopoulos J (2003) Security and privacy iTrust’04, pp 347–354
requirements analysis within a social setting. In: Proceedings of 87. Haley CB, Moffett JD, Laney R, Nuseibeh B (2005) Arguing
11th IEEE requirements engineering conference. IEEE Press, pp security: validating security requirements using structured argu-
151–161 mentation. In: Proceedings of the 3rd symposium on require-
70. Abiteboul S, Hull R, Vianu V (1995) Foundations of databases. ments engineering for information security (SREIS’05). Paris
Addison-Wesley, New York 88. Braber F, Hogganvik I, Lund MS, Stølen K, and Vraalsen F
71. Giorgini P, Massacci F, Mylopoulos J, Zannone N (2005) St-tool: (2007) Model-based security analysis in seven steps—a guided
a case tool for security requirements engineering. In: RE-05. tour to the CORAS method. BT Technol J 25(1):101–117
IEEEP, pp 451–452 89. Dahl HEI, Hogganvik I, Stølen K (2007) Structured semantics for
72. Massacci F, Zannone N (2006) Detecting conflicts between the CORAS security risk modelling language. SINTEF infor-
functional and security requirements with secure tropos: John mation and communication technology Technical report STF07
rusnak and the allied irish bank A970
73. Leone N, Pfeifer G, Faber W, Eiter T, Gottlob G, Perri S, Scar- 90. Asnar Y, Giorgini P, Massacci F, Zannone N (2007) From trust to
cello F (2006) The DLV system for knowledge representation and dependability through risk analysis. In: Proceedings of the
reasoning. ACM Trans Comput Logic 7(3):499–562 international conference on availability, reliability and security
74. He Q, Antòn AI (2003) A framework for modeling privacy (AReS). IEEE Computer Society, pp 19–26
requirements in role engineering. In: International workshop on 91. Asnar Y, Giorgini P, Mylopoulos J (2006) Risk modelling and
requirements engineering for software quality (REFSQ 2003) reasoning in goal models. University of Trento. Technical report
75. CERIAS Technical Report (1999) Policy framework for inter- DIT-06-008
preting risk in ecommerce security 92. Keblawi F, Sullivan D (2006) Applying the common criteria in
76. Hauser J, Clausing D (1988) The house of quality. Harv Bus Rev systems engineering. IEEE Secur Priv 4(2):50–55
32(5) 93. Mellado D, Fernandez-Medina E, Piattini M (2006) Applying a
77. Jackson M (2001) Problem frames. Analyzing and structuring security requirements engineering process. In: ESORICS’06
software development problems. Addison-Wesley, New York 94. Mellado D, Fernander-Medina E, Piattini M (2006) A comparison
78. Lin L, Nuseibeh B, Ince D, Jackson M (2004) Using abuse frames of the common criteria with proposals of information systems
to bound the scope of security problems. In: Proceedings of 11th security requirements. In: First international conference on
IEEE international requirements engineering conference (RE’04). availability, reliability, and security (ARES’06). pp 654–661
pp 354–355 95. Booch G, Rumbaugh J, Jacobson I (1999) The Unified Software
79. Hatebur D, Heisel M, Schmidt H (2006) Security engineering Development Process. Addison-Wesley, New York
using problem frames. In: Müller G (ed) Proceedings of the 96. Sindre G, Firesmith DG, Opdahl AL (2003) A reuse-based
international conference on emerging trends in information and approach to determining security requirements. In: Ninth inter-
communication security (ETRICS’06), ser. LNCS 3995. national workshop on requirements engineering (REFSQ’03).
Springer, pp 238–253 http://www.citeseer.ist.psu.edu/580371.html
80. Hatebur D, Heisel M, Schmidt H, (2007) A pattern system for 97. MAP (2005) Metodologı̀a de anàlisis y gestiòn de riesgos de los
security requirements engineering. In: Proceedings of the sistemas de informaciòn (magerit-v 2)

123