Functional Requirements Under Security PresSuRE

Stephan Faßbender, Maritta Heisel and Rene Meis

paluno - The Ruhr Institute for Software Technology, University of Duisburg-Essen, Essen, Germany

Keywords:

Security Analysis, Problem Frames, Requirements Elicitation.

Abstract:

Recently, there has been an increase of reported security incidents hitting large software systems. Such inci-

dents can originate from different attackers exploiting vulnerabilities of different parts of a system. Hence,

there is a need for enhancing security considerations in software development. It is crucial for requirements

engineers to identify security threats early on, and to reﬁne the threats into security requirements. In this paper,

we introduce a methodology for Problem-based Security Requirements Elicitation (PresSuRE). PresSuRE is

a method for identifying security needs during the requirements analysis of software systems using a problem

frame model. Our method does not rely entirely on the requirements engineer to detect security needs, but

provides a computer-aided security threat identiﬁcation, and subsequently the elicitation of security require-

ments. The identiﬁcation is based on the functional requirements for a system-to-be. We illustrate and validate

our approach using a smart grid scenario provided by the industrial partners of the EU project NESSoS.

1 INTRODUCTION

Recently, there has been an increase of reported secu-

rity incidents hitting large software systems. Beside,

for example, reputation damage, loss on market value

and share, and costs for legal infringement (Cavu-

soglu et al., 2004; Khansa et al., 2012), ﬁxing the

security defect causing the incident is costly. Fix-

ing a defect when it is already ﬁelded is reported to

be up to eighty times more expensive than ﬁxing the

corresponding requirements defects early on (Willis,

1998; Boehm and Papaccio, 1988). Thus, security

issues should be detected as early as possible for a

system-to-be. Therefore, it is crucial for requirements

engineers to identify security threats, and to reﬁne the

threats into security requirements. But eliciting good

requirements is not an easy task (Firesmith, 2003),

even more with regard to security, as most require-

ments engineers are not security experts in the ﬁrst

place.

In this work, we propose a method called

problem-based security requirements elicitation

(PresSuRE), which guides a requirements engineer

through the process of eliciting a set of security re-

quirements in collaboration with the stakeholders of

the system-to-be and security experts. PresSuRE has

several beneﬁts. It does not require the requirements

engineer to have a security background. It does not

require any preliminary security requirements and

security relevant information. It lowers the effort by

providing tool support for semi-automated modeling

and an automated security analysis. And PresSuRE

is completely guided by a detailed process.

PresSuRE is based on the same idea of deriving

information ﬂows from functional requirements like

the problem-based privacy analysis (ProPAn) (Beck-

ers et al., 2013a), but changes the analysis to be

suitable for security. The analysis and elicitation

is based on a complete set of functional require-

ments for a system-to-be. The method is accompa-

nied with tool-support

. PresSuRE is based on the

problem frame notation introduced by Jackson (Jack-

son, 2001). We decided to use problem frames be-

cause they have a semi-formal structure, which allows

a automated analysis. Furthermore, they are system-

centric and embody a description of the environment

of the system-to-be, which is important for a secu-

rity analysis. And the overall system-to-be is decom-

posed using the requirements, which makes the us-

age of problem diagrams scalable even for large sys-

tems, because the complexity of single problem dia-

grams is independent of the system size and the num-

ber of problem diagrams scales linearly. Thus, they

are suitable as input for a semi-automated analysis, as

they have a predictable structure, underlying seman-

tics, and support focusing on parts of the system-to-

be.

http://www.uml4pf.org/ext-pressure/installation.html

Faßbender S., Heisel M. and Meis R..

Functional Requirements Under Security PresSuRE.

DOI: 10.5220/0005098600050016

In Proceedings of the 9th International Conference on Software Paradigm Trends (ICSOFT-PT-2014), pages 5-16

ISBN: 978-989-758-037-6

 2014 SCITEPRESS (Science and Technology Publications, Lda.)

We brieﬂy describe the case study (Section 2) we

use for the running example and the validation. The

problem frame notation is explained in Section 3.

Section 4 introduces the running example, which is

used for the rest of the paper. The PresSuRE method

is then explained in Section 5, and in Section 6 the

method is validated. In Section 7 related work is dis-

cussed, and the ﬁnal conclusion is drawn in Section 8.

2 CASE STUDY

To illustrate the application of the PresSuRE method,

we use the real-life case study of smart grids. As

sources for real functional and quality requirements,

we consider diverse documents such as “Application

Case Study: Smart Grid” provided by the industrial

partners of the EU project NESSoS

, the “Protection

Proﬁle for the Gateway of a Smart Metering System”

(Kreutzmann et al., 2011) provided by the German

Federal Ofﬁce for Information Security

, and “Re-

quirements of AMI (Advanced Multi-metering Infras-

tructure”) (ope, 2009) provided by the EU project

OPEN meter

To use energy in an optimal way, smart grids make

it possible to couple the generation, distribution, stor-

age, and consumption of energy. Smart grids use

information and communication technology (ICT),

which allows for ﬁnancial, informational, and elec-

trical transactions.

We deﬁne the terms speciﬁc to the smart grid do-

main and our use case in the following. The smart

meter gateway represents the central communication

unit in a smart metering system. It is responsible for

collecting, processing, storing, and communicating

meter data. The meter data refers to readings mea-

sured by smart meters regarding consumption or pro-

duction of a certain commodity. A smart meter rep-

resents the device that measures the consumption or

production of a certain commodity and sends it to the

gateway. An authorized external entity can be a hu-

man or an IT unit that communicates with the gateway

from outside the gateway boundaries through a wide

area network (WAN). The WAN provides the commu-

nication network that interconnects the gateway with

the outside world. The LMN (local metrological net-

work) provides the communication network between

the meter and the gateway. The HAN (home area net-

work) provides the communication network between

the consumer and the gateway. The term consumer

refers to end users of commodities (e.g., electricity).

http://www.nessos-project.eu/

www.bsi.bund.de

http://www.openmeter.com/

3 PROBLEM-ORIENTED

REQUIREMENTS

ENGINEERING

Jackson (Jackson, 2001) introduced the concept of

problem frames, which is concerned with describ-

ing, analyzing, and structuring software development

problems. A problem frame represents a class of

software development problems. It is described by a

frame diagram, which consists of domains, interfaces

between them, and a requirement. Domains describe

entities in the environment. Jackson distinguishes the

domain types biddable domains that are usually peo-

ple, causal domains that comply with some physi-

cal laws, and lexical domains that are data represen-

tations. Whenever we have inﬂuence on the design

of a domain it is a designed domains. To describe

the problem context, a connection domain between

two other domains may be necessary. Connection do-

mains establish a connection between other domains

by means of technical devices. Examples are video

cameras, sensors, or networks. Note, that one domain

can have more than one type, for example a domain

can be a connection and causal domain at the same

time.

Interfaces connect domains, and they contain

shared phenomena. Shared phenomena may be

events, operation calls, messages, and the like. They

are observable by at least two domains, but controlled

by only one domain, as indicated by the abbreviation

of that domain and “!”. For example, the shared phe-

nomenon MeterData in Figure 1 is observable by the

domains SMGProvider and PersistentMeterData, but

controlled only by the domain PersistentMeterData

(abbreviation PMD).

The objective is to construct a machine (i.e., soft-

ware) that controls the behavior of the environment

(in which it is integrated) in accordance with the re-

quirements. Problem-oriented requirements analysis

relies on a decomposition of the overall problem into

sub-problems, which are represented by problem di-

agrams. Problem diagrams contain the requirements

belonging to the sub-problem. When we state a re-

quirement, we want to change something in the envi-

ronment. Therefore, each requirement constrains at

least one domain in the environment. A requirement

may also refer to several domains in the environment

of the machine.

The problem frames approach distinguishes there-

fore between the requirements (R), the domain knowl-

edge (D), and the speciﬁcation (S). The requirements

describe the desired system after the machine is built.

The domain knowledge represents the relevant parts

of the problem world. The speciﬁcations describe the

ICSOFT-PT2014-9thInternationalConferenceonSoftwareParadigmTrends

Figure 1: Problem Diagram RQ 5 : Provide Meter Data.

behavior of the software in order to meet the require-

ments.

We describe problem frames using UML class

diagrams, extended by stereotypes, as proposed by

Hatebur and Heisel (Hatebur and Heisel, 2010).

Figure 1 shows a problem diagram in UML nota-

tion. The biddable domain (UML class with stereo-

type biddableDomain) Consumer controls the

request consumption data command (Name of the

UML association with the stereotype connection

between the classes Consumer and HAN), which

is observed by the causal connection domain

HAN (UML class with stereotype causalDomain,

connectionDomain). The SMGProvider controls

the phenomenon readData, which is obtained from

the lexical domain PersistentMeterData (UML class

with stereotype lexicalDomain). Additionally,

the SMGProvider provides the data. The Persistent-

MeterData controls the meter data it contains. The

HAN forwards the data and commands it observes.

The requirement RQ 5 (for a textual description see

Section 4) constrains the HAN and refers to the Con-

sumer, and the PersistentMeterData.

4 RUNNING EXAMPLE: BILLING

We chose the use case Meter Reading for Billing

given in the documents of NESSoS and the open me-

ter project to exemplify our method. This use case

is concerned with gathering, processing, and storing

meter readings from smart meters for the billing pro-

cess. Beside the billing use case there are 13 use cases

Figure 2: Problem Diagram RQ 1: Receive Meter Data.

described for the minimal features of a smart meter

gateway in total, which we all considered for our val-

idation. The functional requirements for this use case

are deﬁned as follows:

(RQ 1) Receive Meter Data: The smart meter gate-

way shall receive meter data from smart meters.

(RQ 2) Process Meter Data: The smart meter gate-

way shall process meter data from smart meters.

(RQ 3) Store Meter Data: The smart meter gateway

shall store meter data from smart meters.

(RQ 4) Submit Billing Data: The smart meter gate-

way shall submit processed meter data to authorized

external entities.

(RQ 5) Provide Consumption Data to Consumer:

The smart meter gateway shall provide meter data for

consumers for the purpose of checking the consis-

tency of bills.

The problem diagram for RQ 5 was already shown

in Figure 1 and explained in Section 3. Figure 2

shows the problem diagram for RQ 1. The causal

domain smart meter controls the send data com-

mand, which is forwarded by the LMN and ﬁnally

observed by the machine domain SMGReceiver. The

SMGReceiver controls the phenomenon writeTempo-

raryData, which stores the received information in

the lexical domain temporary meter data. Addition-

ally, the SMGReceiver can request data which is for-

warded by the LMN to the smart meter. The causal

connection domain LMN forwards the data and com-

mands it observes. The requirement RQ 1 constrains

the temporary meter data and refers to the smart me-

ter. These two problem diagrams are sufﬁcient to un-

derstand the rest of the paper, nevertheless we use all

ﬁve functional requirements for our method.

Note that we will even simplify this example in the

following. We will not elaborate on all security ele-

ments but restrict ourselves to one example for each

element, for example one asset, to improve the com-

prehensibility for the reader and for reasons of space.

Nevertheless, for the validation we elaborated the full

case study in means of 27 requirements and all possi-

ble assets and attackers.

5 THE PresSuRE METHOD

The PresSuRE method consists of four phases and

nine steps, which we will explain in the following

(Figure 3 gives an overview. Whenever we refer to

the ﬁgure we use a different font).

FunctionalRequirementsUnderSecurityPresSuRE

Document Notation

Problem

Adjusted

Diagrams

Tables

Discovery

Domain

Connection

Problem

Diagrams

Language

Natural

Notation

Frames

Problem

(UML)

Requirements

Template

Discovery

Domain

Connection

Template

Elicitation

Element

Security

Template

Elicitation

Attacker

Language

Natural

Tables

Elicitation

Attacker

Tables

Elicitation

Element

Security

Access

Global

Graph

Knowledge

Asset

Diagrams

Knowledge

Attacker

Diagrams

Notation

Frames

Problem

(UML)

Language

Natural

Access

Asset

Graphs

Access

Asset

Attacker

Security

Initial

Requirements

Notation

Graph

Notation

Frames

Problem

(UML)

notation

actor

Activity

control flowinformation flow

ABC

notation

ABC

Prepare

Knowledge

Elicitation

ABC

Global

Access

Graph

Asset

Access

Graph

ABC

Graph

Attacker

Asset

Access

ABC

Security

Element

Elicitation

Engineer

Requirements

Engineer

Requirements

Engineer

Requirements

System

Stakeholders

System

Stakeholders

Engineer

Requirements

Engineer

Requirements

System

Stakeholders

Security

Expert

Engineer

Requirements

Security

Expert

external

input

process

output

input /

Model Functional Requirements

Elicitation

Graph Generation

Security Knowledge Elicitation

used by

generated automatically

generated semi−automatically

Analyze

Attacker

Asset

Graphs

Access

Adjust

Problem

Diagrams

Model

Problem

Diagrams

Attacker

Security

Expert

Figure 3: PresSuRE Method.

5.1 Model Functional Requirements

We assume that the functionality of the system-to-be

is described completely, coherently and unambigu-

ously. The functional requirements are a good start-

ing point for a security analysis as the requirements

engineer is used to deal with them, they are often al-

ready well deﬁned, they already contain everything

which has to be protected, and they also contain the

entry points for possible attack vectors an adversary

can use. Note that the results PresSuRE delivers are

correct and sufﬁcient with respect to functional re-

quirements used. Hence, having incomplete or bad

requirements has an impact on the results. But how

to tackle this problem is out of scope of this problem.

The modeling of the requirements is achieved by per-

forming the following two steps.

Model Problem Diagrams. In the ﬁrst step of the

PresSuRE method, the functional requirements have

to be modeled using the problem frame notation. This

can be done by the requirements engineer alone,

based on a textual description of the functional require-

ments. The result is a set of problem diagrams as well

as an automatically generated connection domain dis-

covery table. The functional requirements and cor-

responding problem diagrams are presented in Sec-

tion 4.

Adjust Problem Diagrams. As setting up prob-

lem diagrams allows some degree of freedom, adjust-

ments might be needed to prepare the problem dia-

grams. For the PresSuRE analysis, connection do-

mains are speciﬁcally important. Many attacks use

such connection domains as entry points, such as a

wireless LAN for snifﬁng important data, a display

Table 1: Connection Domain Discovery Table.

Domain

phenomena Q1

Name? Q2

•

Name? Q3

◦

Name? PD

∗

Authorized-

External-

Entity

SMG-

Submitter

SMG-

S!{submit-

Data} AE-

E!{request-

Billig-

Data}

yes WAN no - no - RQ4-

Submit-

Meter-

Data

. . .

Q1: Information transmitting domain involved?

•

Q2: Domain displaying

information involved?

◦

Q3: Domain storing information involved?

∗

PD:

Related problem diagrams

which is visible to an attacker, or even a postman,

who can be socially engineered. But as connection

domains are not of central relevance for fulﬁlling

the functional requirements, they are often left out.

Hence, one has to make sure that all connection do-

mains are explicitly modeled.

For each connection between domains, the re-

quirements engineer and the system stakeholders

have to check if there is a connection domain in be-

tween. Typical connection domains, which should be

modeled, are domains transporting information (such

as network domains or a postman), domains which

show information (such as (semi)- public displays),

or domains which store information for exchange be-

tween domains (such as a network-attached storage).

While requirements engineers are able to analyze,

understand, and explain the problem diagrams, and

know which new connection domains might be intro-

duced, they often lack the domain knowledge, which

reveals already established connection domains. This

knowledge is available through the stakeholders of

the system-to-be. Hence, the requirements engineer

guides through the discovery and models the results,

while the system stakeholders provide the needed in-

formation.

ICSOFT-PT2014-9thInternationalConferenceonSoftwareParadigmTrends

The requirements engineer and the system stake-

holders use a table containing the connected domains

pairwise, the phenomena in between and a standard

questionnaire, which helps to elicit the missing con-

nection domains. Table 1 shows such a table. The

result of this step are adjusted problem diagrams,

which are modeled by the requirements engineer us-

ing semi-automated wizards. For our example, using

the table and answering the questions, we see that our

problem diagrams have to contain WAN, HAN and

LMN as connection domains. This information is al-

ready reﬂected by the problem diagrams shown in this

paper.

5.2 Security Knowledge Elicitation

Before starting the security analysis, some security-

speciﬁc knowledge has to be elicited. This informa-

tion is crucial for the success of the analysis, as in

most cases the functional requirements do not con-

tain enough information for considering security thor-

oughly. The knowledge about assets in the system-

to-be and attackers which might tamper with the sys-

tem has to be made explicit. As this knowledge is not

or only partially available for requirements engineers,

they have to collaborate with the stakeholders of the

system and security experts.

Prepare Knowledge Elicitation. Even though, the

functional requirements do not contain the informa-

tion for security analysis, they do already contain

some information, which is the starting point for elic-

iting the additional domain knowledge. We use secu-

rity element elicitation tables, and attacker elicitation

tables to elicit this information. The tables are auto-

matically generated from the problem diagrams.

Identify Assets, Authorized Entities and Rights.

The baseline questions for this step are “What has

to be protected?” (asset), “Who is eligible to ac-

cess the asset?” (authorized entities), and “Which

actions are allowed for a stakeholder regarding an

asset?” (rights). This is in line with common se-

curity and threat analysis methods (ISO/IEC, 2009a;

Howard and Lipner, 2006; ISO/IEC, 2009b; J

urjens,

2005). We use the previously generated security ele-

ment elicitation tables to elicit this information. The

instance for persistent meter data is shown in Table 2.

Such tables are completed by the stakeholders of the

system-to-be using the following description, while

the requirements engineer models the results.

Assets. Identify those domains, which have to be

protected. Every domain beside the machine is an

asset candidate. Most likely one wants to protect a

lexical domain representing information or a causal

Table 2: Security Element Elicitation Table for Persistent

Meter Data.

Asset-

Candidate

is as-

set

Authorized Entity Candi-

date

is Autho-

rized Entity

rights

Persistent- 

WAN 2 2 read 2 write

Meter- Consumer 

 read 2 write

Data HAN 2 2 read 2 write

AuthorizedExternalEntity 

 read 2 write

SmartMeter 

 read  write

LMN 2 2 read 2 write



: yes,  : must have,  : might have

domain. For our example, we only select the per-

sistent meter data as an asset, which contains infor-

mation about the electricity consumption of the con-

sumer. This information has to be protected for pri-

vacy reasons, as it, for example, allows to monitor

the consumer. The full case study contains 13 further

assets (see Section 6).

Authorized Entities. A authorized entity to an

asset is every domain, which has an eligible interest

in knowing the state / reading, or controlling / writ-

ing the asset. Eligible entities of the meter data are

the smart meters, which produce the meter data, the

external entities, who need the consumption informa-

tion for billing, and the consumer, who wants to check

his/her electricity consumption.

Rights. Authorized entities have different rights

to access the asset. In case of a lexical domain, the

rights are to read or write the information in the do-

main. In case of the causal domain, the rights are to

control or know the state of the causal domain. For

each right and authorized entity, one has to state if the

entity is allowed to have the right or if the entity must

have the right. The smart meters must have the right

to write the information, while the consumer and ex-

ternal entities must have the right to read the informa-

tion. The smart meters do not need to read the stored

consumption data, and the external entities and the

consumer are not allowed to modify the consumption

data.

The elicited information has to be added to the

model. For this purpose, we use domain knowl-

edge diagrams. In domain knowledge diagrams ad-

ditional knowledge about domains and relations be-

tween domains can be modeled. To support mod-

eling security-related domain knowledge we devel-

oped UML proﬁles. Figure 4 shows a domain

Figure 4: Asset Knowledge for the Rights of the Consumer

regarding the PersistentMeterData.

FunctionalRequirementsUnderSecurityPresSuRE

knowledge diagram modeled using the proﬁles. It

depicts that there is domain knowledge (stereotype

domainKnowledge at class ConsumerPersistent-

MeterDataAccess) about the persistent meter data and

the consumer. The persistent meter data is an as-

set (stereotype asset at class PersistentMeter-

Data), the consumer is a authorized entity of this asset

(stereotype authorizedEntity at class Consumer),

and the consumer is allowed to read (read) from

the persistent meter data (refersTo). The di-

agrams are generated in the background while the

requirements engineer completes a wizard which is

similar to the security element elicitation table. The

result of the step are asset knowledge diagrams.

Attacker(s) Elicitation. In this step, the require-

ments engineer and a security expert have to collab-

orate to deﬁne those attackers who might attack our

system-to-be. While the requirements engineer has a

deeper understanding of the system-to-be and its do-

main, the security expert adds his/her vital knowledge

about attackers, attacker abilities, possible attack vec-

tors, and so forth. Hence, it is not mandatory that the

requirements engineer has a security background.

Beckers et al. (Beckers et al., 2013c) enumerate

different types of attackers: physical attacker, soft-

ware attacker, network attacker, and social attacker.

Regarding their abilities, we have chosen the abili-

ties as described by Dolev and Yao (Dolev and Yao,

1983): read (read message / get state of domain),

write (write message / change state of domain), inter-

fere (intercept message / prevent the change of state).

Again, describing attackers with their basic abilities

is in line with the state of the art (ISO/IEC, 2009a;

Howard and Lipner, 2006; ISO/IEC, 2009b; J

urjens,

2005). For the purpose of eliciting the information

about attackers, we use the generated attacker elicita-

tion tables (see Table 3).

Attacker. First, we have to reason for each do-

main and type of attacker about the question if this

type of attacker might exist for the domain at hand.

For simplicity’s sake, we assume for the running ex-

ample that we only have to defend against network at-

Table 3: Attacker Elicitation Table for HAN.

Attack-

Candidate

attack-

able

Attacker Name Abilities

HAN 



network attacker internal net.  read  write

attacker  interfere

2 physical attacker 2 read 2 write

2 interfere

2 social attacker 2 read 2 write

2 interfere

2 software attacker 2 read 2 write

2 interfere



: yes,  : has the ability

Figure 5: Attacker Knowledge regarding the internal net-

work attacker’s abilities regarding the HAN.

tackers. We distinguish between two network attack-

ers: The internal network attacker, who has access

to the HAN and LMN, where the smart meters reside,

and the external network attacker, who can attack via

the WAN. Note that for the full case study we found

and modeled 7 attackers in total, including all kinds

of attackers.

Abilities. For each attacker and each domain the

attacker has access to, we have to state which abilities

the attacker has. Whenever there is no detailed infor-

mation about the attackers and their abilities regard-

ing a domain they have access to, one should assume

the strongest attacker. This might lead to an overesti-

mation of the threats afterward. But adding a unnec-

essary security requirement is not so much of an issue,

while missing one is critical. After an assessment of

all attackers of our example and their abilities, we

could not exclude any of the basic abilities. Hence,

our attackers have all abilities regarding the domains

they have access to.

The elicited information has to be added to the

model to be available for our analysis, too. Again,

the modeling can be done semi-automatically us-

ing the wizards our tool provides. The result are

attacker knowledge diagrams. Figure 5 shows the

domain knowledge about the internal network at-

tacker and his/her abilities regarding the HAN. It

depicts that there is domain knowledge (stereotype

domainKnowledge at class InternalNetworkAt-

tackerExists) about the internal network attacker and

the HAN. The internal network attacker is a network

attacker (stereotype networkAttacker at class In-

ternalNetworkAttacker). This attacker is able to read

(read) from the HAN (refersTo), and the at-

tacker (refersTo) is able to write to and interfere

with the HAN (write, interfere).

5.3 Graph Generation

The automated part of the security analysis relies on

graphs, which visualize information ﬂows and access

ﬂows. The attacker asset access graphs, which con-

tains the potential security threats towards the func-

tional requirements, are generated stepwise. The

ICSOFT-PT2014-9thInternationalConferenceonSoftwareParadigmTrends

steps and intermediate graphs are explained in the fol-

lowing.

Global Access Graph. All graphs (V, E) that we

use for our security analysis in the PresSuRE method

are labeled and directed. The set of vertices is a

subset of the domains occurring in the model, for-

mally V ⊆ Domain. An edge is annotated with

a diagram and a type. The diagram can be a prob-

lem diagram or a domain knowledge diagram. The

type can be required (req), implicit (imp) or attack

(att) (T ype ::= req|imp|att). The type indicates if

the edge is required or implicitly given by the prob-

lem diagram or if it shows a possible attack relation-

ship deﬁned in a domain knowledge diagram. The

edges point from one domain to another, formally

E ⊆ Domain × Diagram × T ype × Domain. For

the rest of the paper we will regard such an edge as

an access ﬂow. In the following, we describe a graph

(V, E) only by its edges E.

For the analysis of the threats towards an asset we

will use the global access graph. This graph con-

tains the information about access ﬂows between do-

mains, and which problem diagrams are the source of

these ﬂows. For the ﬂows, we distinguish between

required ﬂows as stated by the requirement and im-

plicit ones which are modeled due to the given envi-

ronment. To set up the global access graph we use

the problem diagrams as an input. The predicates

constrains, refersT o : (Domain×Diagram) and

controls : P(Domain × Domain × Diagram)

can be derived from the problem frame model and

are used to generate the global access graph. We

have (d, p) ∈ constrains and (d, p) ∈ ref ersT o

iff a requirement or domain knowledge in diagram p

constrains the domain d or refers to it, respectively.

, d

, p) ∈ controls is true iff the domain d

con-

trols an interface that d

observes in the diagram p.

Using these predicates, we create the global ac-

cess graph G, which is an overapproximation of the

access ﬂows occurring in the system-to-be. An edge

, p, req, d

) is in G iff the domains d

and d

are

not equal, and the domain d

is referred to and the

domain d

is constrained in p. For example, the prob-

TemporaryMeterData PersistentMeterData

RQ3

SmartMeter

RQ1

LMN

RQ1

HAN

Consumer

RQ5

RQ3

RQ5

WAN

RQ4

AuthorizedExternalEntity

RQ4

RQ1

Figure 6: Global Access Graph (also Asset Access Graph

for Persistent Meter Data).

lem diagram for RQ 1 (see Figure 2) contains the

smart meter and the temporary storage. The smart

meter is referred by RQ 1 and the temporary storage

is constrained by RQ 1. Hence, we add a required

access ﬂow edge (solid arrow) between smart meter

(node with name SmartMeter) and temporary meter

data (node with name TemporaryMeterData) anno-

tated with RQ 1 (see graph shown in Figure 6).

Additionally, an edge (d

, p, imp, d

) is in G iff

the (d

, p, req, d

) is not already in G, the domains

and d

are not equal, and d

observes an interface

controlled by d

in p. Note that machines are treated

as transitive forwarders in this case. This means that

whenever a machine m observes an interface con-

trolled by d

and d

observes an interface controlled

by m, we assume that d

observes an interface of

. For example, the domain LMN controls a phe-

nomenon forwardMeterData which is observed by the

machine (see Figure 2). The domain temporary me-

ter data observes a phenomenon writeTemporaryData

from the machine. Hence, an implicit access ﬂow edge

(dotted edge) is added between the LMN and the tem-

poral meter data annotated with RQ 1 (see Figure 6).

We deﬁne the graphs as follows.

req

={(d

, p, t, d

) :

Domain × P roblemDiagram × {req}

× Domain | d

6= d

∧

, p) ∈ constrains ∧ (d

, p) ∈ refersT o}

imp

={(d

, p, t, d

) : Domain×

P roblemDiagram × {imp} × Domain |

6= d

∧ (d

, p, req, d

) /∈ G

req

∧ ((d

, d

, p) ∈ controls ∨ ∃m : Machine•

, m, p) ∈ controls ∧ (m, d

, p) ∈ controls)}

G =G

req

∪ G

imp

Because of the annotation of the edges we keep the in-

formation which problem diagram causes the access

ﬂow. Thus, our global access graph contains trace-

ability links that are used in our further analysis. The

semantics of an edge (d

, p, t, d

) ∈ G is that in prob-

lem diagram p there is possibly a required or implicit

(depending on t) access ﬂow from domain d

to do-

main d

Asset Access Graph. As the global access graph

can be huge for a complex system-to-be, we intro-

duce an asset access graph which focuses the view on

one asset only. It only contains access ﬂows given

by the requirements directly or indirectly concern-

ing the asset. Thus, we get one asset access graph

per asset. The asset access graph makes the infor-

mation for the requirements engineer easier to com-

prehend. Hence, it improves the scalability of our

FunctionalRequirementsUnderSecurityPresSuRE

PersistentMeterData

WAN

RQ4 (C)

TemporaryMeterData

RQ3

HAN

RQ5 (C)

ExternalNetworkAttacker

WANAttacker (C,I,A)

InternalNetworkAttacker

LMN

LMNAttacker (C,I,A)HANAttacker (C,I,A)

RQ1 (A,C,I)

SmartMeter

RQ1 (I,A,C)

RQ4 (C,I,A)

AuthorizedExternalEntity

RQ4 (C,I,A)

RQ4 (C)

RQ3

RQ1 (C)

RQ1

Consumer

RQ5 (C)

RQ5 (A,C,I)

RQ5 (C,I,A)

Figure 7: Attacker Asset Access Graph for Persistent Meter Data.

method. An edge (d

, p, t, d

) is in G

asset

iff p is

in P

access

. A problem diagram p is in P

access

iff

there is an edge (d

, p, t, d

) which is required and

and d

are both in D

access

. D

access

is a union

of D

active

and D

passive

. A domain d

is in D

active

iff there is a required access ﬂow which starts at d

and the target domain d

is already in D

active

. Ini-

tially, only the asset is in D

active

. Hence, D

active

contains all domains which have a required direct or

indirect (via another domain) access ﬂow towards the

asset. A domain d

is in D

passive

iff there is a re-

quired access ﬂow which ends at d

and the source

domain d

is already in D

passive

. Initially, only the

asset is in D

passive

. Hence, D

passive

contains all

domains which are the target of a required direct or

indirect (via another domain) access ﬂow from the as-

set. Formally, we deﬁne D

active

, D

passive

, D

access

, and G

asset

as follows.

required asset ∈ Domain

asset ∈ D

active

, asset ∈ D

passive

, p, req,d

) ∈ G ∧ d

∈ D

active

⇒ d

∈ D

active

, p, req,d

) ∈ G ∧ d

∈ D

passive

⇒ d

∈ D

passive

access

active

∪ D

passive

access

={p : P roblemDiagram |

∃(d

, p, req, d

) : G • d

, d

∈ D

access

}

asset

={(d

, p, t, d

) : G | p ∈ P

access

}

The resulting asset access graph for the persistent

meter data is shown in Figure 6, as for our small ex-

ample the global and the asset access graph do not

differ. For a complex scenario the asset access graph

is signiﬁcantly smaller than the global access graph.

The asset access graph can be used to check if a stake-

holder can gain more rights than he/she should. For

reasons of space, we do not go into detail on this mat-

ter.

Attacker Asset Access Graph. For each asset, we

generate the attacker asset access graph, which visu-

alizes the information and control ﬂows from attack-

ers to the asset and from the asset to the attackers.

At this point, we focus on the basic information se-

curity goals conﬁdentiality, integrity, and availabil-

ity (short CIA), which are suggested by the Com-

mon Criteria (ISO/IEC, 2009a) and ISO 27000 family

of standards (ISO/IEC, 2009b). The problematic ac-

cess ﬂows are annotated with the information which

CIA property(ies) are threatened (CIA ::= C|I|A|ε).

First, the domains which are directly connected to at-

tackers are identiﬁed. Note that for this purpose we

use the information given in domain knowledge di-

agrams created during the step Identify assets, au-

thorized entities and rights described in Section 5.2.

From these diagrams, we can derive the predicates

read, write, interf ere : P(Domain × Diagram).

We have (d, dk) ∈ read, (d, dk) ∈ write, and

(d, dk) ∈ interf ere iff domain knowledge in dia-

gram dk has a read, write, or interfere dependency,

respectively, to the domain d.

A domain can d be object to be attacked if it is in

access

for the asset at hand. That is, an attacker can

access or inﬂuence information on the asset through

the domain d. We deﬁne the sets D

, D

, and D

the sets of all domains for which an attacker has the

ability to write, interfere, or read it, respectively. A

domain d is in D

iff there exists an attacker a and a

domain knowledge diagram dk, in which d is written

and a is referred to by the domain knowledge. The

domain d is in D

iff there exists an attacker a and

a domain knowledge diagram dk in which d is inter-

fered and a is referred as sources of the interference.

The domain d is in D

iff there exists an attacker a

and a domain knowledge diagram dk in which the in-

formation in d is referred to and a reads this informa-

tion. Based on the three sets of domains which might

be attacked, the asset threat graph G

threat

can be set

up. D

, D

, and D

are formally deﬁned as follows.

={d : D

access

| ∃a : Attacker; dk : Diagram•

(d, dk) ∈ write ∧ (a, dk) ∈ ref ersT o}

={d : D

access

| ∃a : Attacker; dk : Diagram•

(d, dk) ∈ interfere ∧ (a, dk) ∈ refersT o}

={d : D

access

| ∃a : Attacker; dk : Diagram•

(a, dk) ∈ read ∧ (d, dk) ∈ ref ersT o}

threat

contains all edges, and therefore problem

diagrams, of the corresponding asset access graph

ICSOFT-PT2014-9thInternationalConferenceonSoftwareParadigmTrends

which might allow an attacker to successfully attack

the asset at hand. An access ﬂow (d

, p, t, d

) ∈

asset

represents that information is transferred from

to d

that possibly comes from the asset or that

possibly will be stored in the asset. Hence, such an

access ﬂow is a possible threat to the conﬁdentiality

of an asset if an attacker has the ability to read one of

the domains d

or d

∈ D

∨ d

∈ D

). In this

case, we add the edge (d

, p, t, C, d

) to G

threat

. An

access ﬂow (d

, p, t, d

) ∈ G

asset

is a possible threat

to the integrity of an asset if an attacker has the ability

to write the source d

of the access ﬂow (d

∈ D

because an attacker could change the information of

the asset or the information sent to the asset at do-

main d

, which forwards it to domain d

. In this case,

we add the edge (d

, p, t, I, d

) to G

threat

. We have

to consider an access ﬂow (d

, p, t, d

) ∈ G

asset

as a

possible threat to the availability of an asset if an at-

tacker has the ability to interfere one of the domains

or d

∈ D

∨ d

∈ D

), because an attacker

is then able to threaten the availability of information

ﬂowing from or to the asset through the domains d

and d

. In this case, we add the edge (d

, p, t, A, d

)

to G

threat

. G

threat

is deﬁned as follows.

threat

= {(d

, p, t, cia, d

) : Domain × Diagram×

T ype × CIA × Domain | (d

, p, t, d

) ∈ G

asset

∧

[(d

∈ D

∨ d

∈ D

) ∧ cia = C

∨ d

∈ D

∧ cia = I

∨ (d

∈ D

∨ d

∈ D

) ∧ cia = A]}

The full attacker asset access graph G

attack

is an

extension of G

threat

⊂ G

attack

. We add an edge

, p, t, ε, d

) to G

attack

iff (d

, dk, t, d

) is in G

asset

but not in G

threat

. These edges visualize how the at-

tacks on the access ﬂows in G

threat

are may propa-

gated over the system due to the functional require-

ments. Additionally, the attackers are added to the at-

tacker asset access graph. G

attack

contains an edge

(a, dk, att, cia, d) if a is an attacker and a domain

knowledge diagram dk exists, in which d is referred to

and d is written (cia = I) or interfered (cia = A). Ad-

ditionally, G

attack

contains an edge (a, dk, att, C, d) if

a is an attacker and a domain knowledge diagram dk

exists in which d is referred to and a is read. Formally,

we deﬁne G

attack

as follows.

attack

= {(d

, p, t, ε, d

) : Domain × Diagram×

T ype × CIA × Domain | (d

, p, t, d

) ∈ G

asset

∧

∀st : CIA • (d

, p, t, st, d

) /∈ G

threat

}∪

{(a, dk, att, cia, d) : Attacker × Diagram × T ype×

CIA × Domain | (d, dk) ∈ ref ersT o∧

[(a, dk) ∈ read ∧ cia = C ∨ (a, dk) ∈ write ∧ cia = I

∨ (a, dk) ∈ interfere ∧ cia = A]} ∪ G

threat

The generated attacker asset access graph for the

persistent meter data is shown in Figure 7. Note

that for reasons of readability, the PresSuRE tool

merges edges and their annotation if they have the

same source and target, and are of the same type.

The asset is now visualized as ellipse with bold bor-

der and the asset name (PersistentMeterData) is writ-

ten in bold. The attackers internal and external net-

work attacker are also added as ellipses with dashed

borders and in italic font. Their attack ﬂow edges

are shown as dashed edges, which are annotated with

the domain knowledge diagram they are described in

and the security goals they may threaten. A bold

(both, edge and annotation) access ﬂow indicates a

ﬂow for which a security property might be threat-

ened by an attacker. The threatened security property

is annotated in brackets. For example, the implicit

access ﬂow edge between the nodes LMN and Tempo-

raryMeterData is annotated with RQ1 (A,C,I). Hence,

it might be possible that for RQ1 the conﬁdentiality,

integrity and availability of persistent meter data is

threatened.

5.4 Analyze Attacker Asset Access

Graph

Last, a requirements engineer and a security expert

have to analyze the problematic (potentially threat-

ened) access ﬂows. The input to this step are the at-

tacker asset access graphs. The attacker asset ac-

cess graph contains all information regarding access

ﬂows to and from the asset. And it contains the in-

formation where the asset might be threatened by an

attacker. For each previously identiﬁed asset, it has

to be checked if the original requirements related to

the asset have to be augmented with security require-

ments. At this point we skip the detailed discussion

how to do this analysis for reasons of space.

6 VALIDATION

We validated PresSuRE using two real-life case stud-

ies, the already introduced smart meter and a voting

system. The voting system requirements were ob-

tained from a Common Criteria proﬁle for voting sys-

tems (Volkamer and Vogt, 2008). For more details

on the voting system case study, see (Faßbender and

Heisel, 2013). The results for applying PresSuRE

are reported in the following in detail for the Smart

Grid. The original functional requirements were ob-

tained from (ope, 2009) and the NESSoS case stud-

ies provided by the industrial partners of the project.

For conducting our method, we selected 13 minimum

FunctionalRequirementsUnderSecurityPresSuRE

Table 4: Effort spent for conducting the method.

Method Step

Model Functional Requirements Security Knowledge Elicitation Graph Generation

Analyze

Attacker

Access

Graphs

Model Problem

Diagrams

Adjust Problem

Diagrams

Prepare

Knowledge

Elicitation

Security

Element

Elicitation

Attacker(s)

Elicitation

Global Access

Graph

Asset Access

Graphs

Attacker Asset

Access Graphs

Effort ∅ Per Item

28 min. per Problem

Diagram

5.5 min. per

Domain

< 1 sec. per

Domain

10 min. per

Domain

12 min. per

Domain

3 sec. per Problem

Diagram

9 sec. per Asset

40 sec per Attacker

and Asset

15 min. per Problem

Diagram

Number of Items

27 Problem

Diagrams

17 Domains 20 Domains 20 Domains 20 Domains

27 Problem

Diagrams

14 Assets 14 Assets 7 Attacker

27 Problem

Diagrams

Total 12.5 person hours

1.6 person

hours

0 computer

hour

3.3 person

hours

4 person hours 0 computer hour

0 computer

hour

1 computer hour 6.75 person hours

# Involved Persons 1 2 0 2 2 0 0 0 2

Accumulated Total 12.5 person hours

3.2 person

hours

0 computer

hour

6.6 person

hours

8 person hours 0 computer hour

0 computer

hour

1 computer hour 13.5 person hours

uses cases, which embody 27 requirements in total.

For these requirements, 14 assets and 7 attackers of

all kinds, as described in Section 5.2, were identiﬁed.

Based on this information the graphs were generated,

and the initial security requirements elicited.

We analyzed each attacker asset access graph for

assessing the tool support, and we also analyzed the

initial security requirements found for assessing the

overall method. For the graph, we checked for each

edge in the attacker asset access graph at hand if the

annotated threats are existing according to the threats

and security requirements of the original documents

(e.g. (ope, 2009; Kreutzmann et al., 2011) for smart

meter). We also looked for threats and security re-

quirements which are deﬁned in such documents, but

which were not identiﬁed using PresSuRE. In this

way we were able to measure the precision and re-

call of our method. Unfortunately, we do not know

which security analysis was used for eliciting the

security requirements reported in those documents.

But we assume that security experts were involved in

writing the documents and the documents were re-

viewed thoroughly. Hence, these documents are a

good benchmark.

Next, we aggregated the results of the edges of

the attacker asset access graph for each requirement.

Thus, we derived for each requirement the informa-

tion if the requirement has to be complemented by

security requirements according to PresSuRE. Again,

we also checked if the found security requirements

are compliant with the original documents. Last, we

measured the precision and recall of PresSuRE on the

requirements level.

The results of this analysis for the smart meter is

Table 5: Results of the assessment for the smart meter case

study.

Conﬁdentiality Integrity Availability

Precision per attack asset access edges 36.14% 66.35% 62.52%

Recall per attack asset access edges 100.00% 100.00% 100.00%

Aggregated precision per attack asset access

edges

55.00%

Aggregated recall per attack asset access

edges

100.00%

Precision per requirement 92.59% 96.30% 96.30%

Recall per requirement 100.00% 100.00% 100.00%

Aggregated precision per requirement

95.06%

Aggregated recall per requirement

100.00%

shown in Table 5. Speaking of the precision on the

level of edges of the attacker asset access graph, we

have many false positives, especially for conﬁdential-

ity. This is because the original documents do not

demand a high level of conﬁdentiality. Additionally,

PresSuRE discovered potential indirect information

ﬂows between assets which will not occur in the sys-

tem later on. Thus, PresSuRE is very strict and defen-

sive, which is not appropriate in every case. Note that

even though the indirect ﬂows often turned out to be

irrelevant, but they have to be checked anyway. Of-

ten attacks use such indirect relations to tamper with

a system. Overall, the precision on the level of edges

of the attacker asset access graph is acceptable (55%),

but should be improved. The recall is perfect (100%)

as we did not ﬁnd any false negatives. On the re-

quirements level, our results are satisfying. Whenever

PresSuRE suggested to add a complementing security

requirement for a functional requirement, this sugges-

tion was correct with a precision of 95%, and no se-

curity requirment was missed (recall 100%).

Similar results were obtained for the voting sys-

tem case study. The precision on the level of edges of

the attacker asset graph is slightly higher, as the vot-

ing system documents are very strict regarding conﬁ-

dentiality. This fact also shows on the requirements

level, but the difference to the smart meter case study

is not signiﬁcant. For the attacker asset access edge

and the requirements level the recall was 100% again.

Speaking of the effort (see Table 4), the 43 per-

son hours spent are a signiﬁcant effort, but seem to

be reasonable. The main effort is spent on the do-

main knowledge elicitation and the security analysis.

Both are vital for security requirements elicitation and

have to be conducted even when not using PresSuRE.

But PresSuRE speeds up these activities and lowers

the error rate, as it provides guidance and means for

a detailed analysis and discussion. Additionally, from

our experience, PresSuRE scales well, as most steps

rely on the complexity of the environment. And the

environment does not grow signiﬁcantly when adding

further requirements. When discussing the require-

ments itself, PresSuRE enables to focus on local and

small problems, which also supports the scalability

ICSOFT-PT2014-9thInternationalConferenceonSoftwareParadigmTrends

in means of comprehensibility and an only linear in-

crease time for the security analysis.

7 RELATED WORK

Schmidt and J

urjens (Schmidt and J

urjens, 2011) pro-

pose to integrate the SEPP method, which is based on

problem frames, and UMLSec (J

urjens, 2005), which

is based on a UML proﬁle and allows tool-based rea-

soning about security properties. In this way, they can

express and reﬁne security requirements and transfer

the security requirements to subsequent design arti-

facts. A similar method is described by Haley et

al. (Haley et al., 2008), which also relies on prob-

lem frames for security requirements analysis. The

ﬁrst method (Schmidt and J

urjens, 2011) starts after

the initial security requirements are already known,

while the latter one already embodies a step for secu-

rity requirements elicitation. But this particular step

is described very sparsely and informally. Hence, our

work can complement and improve these works.

There are many publications concerning goal-

oriented security requirements analysis (e.g. (Liu

et al., 2003; Mouratidis and Giorgini, 2007; Salehie

et al., 2012; Van Lamsweerde, 2004)). But goal mod-

els are of a higher level of abstraction than problem

frames. Goal models are stakeholder-centric, while

problem frames are system-centric. Therefore, reﬁn-

ing functional requirements taking into account more

detail of the system-to-be and analyzing the system-

to-be described by the functional requirements is re-

ported to be difﬁcult for goal-oriented methods (Al-

rajeh et al., 2009). Alrajeh et al. try to tackle this

problem by introducing reﬁnement steps which rely

on heavy weight formalizations. We offer an al-

ternative way of bridging the this gap. Thus, even

though the goals of an attacker and their implica-

tion for the goals of stakeholders are already known,

one might beneﬁt from using our method. Recently,

there were papers which reported a successful integra-

tion of goal-oriented and problem-oriented methods

(Beckers et al., 2013b; Mohammadi et al., 2013). Use

case-oriented security requirements methods such as

misuse cases (Sindre and Opdahl, 2005) or abuse

cases (McDermott and Fox, 1999) are one possible

step before executing our method.

8 CONCLUSION

In this paper, we introduced a methodology for

Problem-based Security Requirements Elicitation

(PresSuRE). PresSuRE is a method for identifying

security needs during the requirements analysis of

software systems using a problem frame model. In

summary, the PresSuRE method has following ad-

vantages: It introduces attacker asset access graphs

and the graphs they are based on, which 1) visualize

the access ﬂows given by the functional requirements,

2) show entry points for attackers and subsequently

threatened assets, 3) directly relate functional require-

ments and threats they are exposed to, and 4) can be

generated fully automatically. And it is a re-usable

requirements security analysis method which 1) re-

lies on functional requirements only, as all security

aspects are added while conducting the method in a

structured way, 2) ensures that crucial domain knowl-

edge is elicited, 3) enforces and supports the collabo-

ration with system stakeholders and security experts,

4) is applicable to different domains, and 5) is tool

supported to ease the elicitation, modeling, and anal-

ysis necessary for the method.

We validated our method and tool with two real-

life case studies in the ﬁelds of smart grid and vot-

ing systems. The results show the suitability of our

method to detect initial security requirements. For

the future, we will investigate in which way the false

positive rate can be lowered in order to decrease the

effort spent on analyzing attack asset access graphs.

Moreover, we are working on making the graphs to

be analyzed even smaller by focusing a graph only on

one attacker, and one asset property at a time. Fur-

thermore, we plan to investigate how the basic CIA

properties can be reﬁned further systematically into

more ﬁne-grained security requirements such as au-

thentiﬁcation and authorization.

ACKNOWLEDGEMENTS

Part of this work is funded by the German Research

Foundation (DFG) under grant number HE3322/4-2

and the EU project Network of Excellence on Engi-

neering Secure Future Internet Software Services and

Systems (NESSoS, ICT-2009.1.4 Trustworthy ICT,

Grant No. 256980).

REFERENCES

(2009). Requirements of AMI. Technical report, OPEN

meter project.

Alrajeh, D., Kramer, J., Russo, A., and Uchitel, S. (2009).

Learning operational requirements from goal models.

In ICSE ’09, pages 265–275.

Beckers, K., Faßbender, S., Heisel, M., and Meis, R.

(2013a). A problem-based approach for computer

FunctionalRequirementsUnderSecurityPresSuRE

aided privacy threat identiﬁcation. In APF ’12, pages

1–16. Springer.

Beckers, K., Faßbender, S., Heisel, M., and Paci, F. (2013b).

Combining goal-oriented and problem-oriented re-

quirements engineering methods. In CD-ARES ’13,

pages 278–294.

Beckers, K., Hatebur, D., and Heisel, M. (2013c). A

problem-based threat analysis in compliance with

common criteria. In ARES ’13. IEEE Computer So-

ciety.

Boehm, B. W. and Papaccio, P. N. (1988). Understanding

and controlling software costs. IEEE Transactions on

Software Engineering, 14(10):1462–1477.

Cavusoglu, H., Mishra, B., and Raghunathan, S. (2004).

The effect of internet security breach announce-

ments on market value: Capital market reactions for

breached ﬁrms and internet security developers. Int.

J. Electron. Commerce, 9(1):70–104.

Dolev, D. and Yao, A. C. (1983). On the security of pub-

lic key protocols. IEEE Transactions on Information

Theory, 29(2):198–207.

Faßbender, S. and Heisel, M. (2013). From problems

to laws in requirements engineering using model-

transformation. In ICSOFT ’13, pages 447–458.

SciTePress.

Firesmith, D. (2003). Specifying good requirements. Jour-

nal of Object Technology, 2(4).

Haley, C. B., Laney, R., Moffett, J. D., and Nuseibeh, B.

(2008). Security requirements engineering: A frame-

work for representation and analysis. IEEE Transac-

tions on Software Engineering, 34(1):133–153.

Hatebur, D. and Heisel, M. (2010). Making pattern- and

model-based software development more rigorous. In

ICFEM ’10, pages 253–269. Springer.

Howard, M. and Lipner, S. (2006). The Security Devel-

opment Lifecycle : SDL : A Process for Develop-

ing Demonstrably More Secure Software. Microsoft

Press.

ISO/IEC (2009a). Common Criteria for Information Tech-

nology Security Evaluation. ISO/IEC 15408, In-

ternational Organization for Standardization (ISO)

and International Electrotechnical Commission (IEC),

Geneva ,Switzerland.

ISO/IEC (2009b). Information technology - Security tech-

niques - Information security management systems

- Overview and Vocabulary. ISO/IEC 27000, In-

ternational Organization for Standardization (ISO)

and International Electrotechnical Commission (IEC),

Geneva ,Switzerland.

Jackson, M. (2001). Problem Frames. Analyzing and

structuring software development problems. Addison-

Wesley.

urjens, J. (2005). Secure Systems Development with UML.

Springer.

Khansa, L., Cook, D. F., James, T., and Bruyaka, O. (2012).

Impact of HIPAA provisions on the stock market value

of healthcare institutions, and information security

and other information technology ﬁrms. Computers

& Security, 31(6):750 – 770.

Kreutzmann, H., Vollmer, S., Tekampe, N., and Abromeit,

A. (2011). Protection proﬁle for the gateway of a

smart metering system. Technical report, BSI.

Liu, L., Yu, E., and Mylopoulos, J. (2003). Security and

privacy requirements analysis within a social setting.

In RE ’03, pages 151–161.

McDermott, J. and Fox, C. (1999). Using abuse case mod-

els for security requirements analysis. In ACSAC ’99,

pages 55–64.

Mohammadi, N. G., Alebrahim, A., Weyer, T., Heisel, M.,

and Pohl, K. (2013). A framework for combining

problem frames and goal models to support context

analysis during requirements engineering. In CD-

ARES ’13, pages 272–288.

Mouratidis, H. and Giorgini, P. (2007). Secure Tropos: a

security-oriented extension of the tropos methodol-

ogy. International Journal of Software Engineering

and Knowledge Engineering, 17(2):285–309.

Salehie, M., Pasquale, L., Omoronyia, I., Ali, R., and Nu-

seibeh, B. (2012). Requirements-driven adaptive se-

curity: Protecting variable assets at runtime. In RE

’12, pages 111–120.

Schmidt, H. and J

urjens, J. (2011). Connecting security re-

quirements analysis and secure design using patterns

and UMLsec. In CAiSE ’11, pages 367–382. Springer.

Sindre, G. and Opdahl, A. L. (2005). Eliciting security re-

quirements with misuse cases. Requir. Eng., 10(1):34–

44.

Van Lamsweerde, A. (2004). Elaborating security require-

ments by construction of intentional anti-models. In

ICSE ’04, pages 148–157.

Volkamer, M. and Vogt, R. (2008). Common Criteria Pro-

tection Proﬁle for Basic set of security requirements

for Online Voting Products. Bundesamt f”ur Sicher-

heit in der Informationstechnik.

Willis, R. (1998). Hughes Aircraft’s Widespread Deploy-

ment of a Continuously Improving Software Process.

AD-a358 993. Carnegie-mellon university.

ICSOFT-PT2014-9thInternationalConferenceonSoftwareParadigmTrends