Problem-based Elicitation of Security Requirements The

Problem-based Elicitation of Security RequirementsThe ProCOR Method

Roman Wirtz1, Maritta Heisel1, Rene Meis1, Aida Omerovic2 and Ketil Stølen2

1University of Duisburg-Essen, Duisburg, Germany2SINTEF Institute, Oslo, Norway

Keywords: Risk Management, Security, Requirements Engineering, Problem-based, Model-based.

Abstract: Security is of great importance for many software systems. The security of a software system can be com-promised by threats, which may harm assets with a certain likelihood, thus constituting a risk. All such risksshould be identified, and unacceptable risks should be reduced, which gives rise to security requirements.The relevant security requirements should be known right from the beginning of the software developmentprocess. Eliciting security requirements should be done in a systematic way. We propse a method to elicitsecurity requirements that address unacceptable risks. They require a reduction of the risk to an acceptable le-vel. Our method combines the CORAS risk management method with Jackson’s problem-based requirementsanalysis approach. Based on the functional requirements for a software system, security risks are identifiedand evaluated. Unacceptable risks give rise to high-level security requirements. To reduce the risk, treatmentsare selected. Based on the selected treatments, concretized security requirements are set up and represented ina similar way as functional requirements. Thus, both functional and security requirements can then drive thesoftware development process.

1 INTRODUCTION

In a connected world, almost every piece of softwaremay be subject to attacks. Such attacks can causegreat harm to enterprises and individuals. Almostevery week, media report on attacks against publicor private organizations. Therefore, software shouldbe developed with security issues in mind. Neverthe-less, organizations can only spend a limited amountof resources on security. These resources should bespent in a way that maximizes return on investment,i.e., that provides the best possible protection againstattacks.

In this paper, we describe a risk-based method toelicit security requirements. Given the functional re-quirements for a software system, possible threats tosecurity and the corresponding risks are identified andevaluated. A risk is determined by two factors: thelikelihood of the threat leading to harm of an asset,and the severity of the harm, i.e., the consequence.For each identified risk, it has to be determined if itis acceptable or not. Only unacceptable risks needto be treated, thus leading to corresponding securityrequirements for the software system to be develo-ped. Moreover, our method supports the selection of

treatments that are suitable to achieve the necessaryrisk reduction. The result of our method is a set offunctional and corresponding security requirementsthat form the basis for the subsequent software de-velopment process.

Our method is model-based, so that the resultsof the risk analysis can be smoothly integrated ina model-based software development process. Thename of the method is ProCOR – Problem-based CO-RAS, because it combines parts of the model-basedrisk management method CORAS (Lund et al., 2010)with Jackson’s problem frames approach (Jackson,2001). Functional requirements expressed using pro-blem diagrams (according to the problem frames ap-proach) form the starting point of the risk analysis.The elicited security requirements are expressed in asimilar way, using a new kind of diagram, called treat-ment problem diagram. The so enhanced requirementmodel forms the starting point for a software develop-ment that adequately balances functionality and secu-rity.

The paper is structured as follows: In Section2, we explain problem frames and CORAS in moredetail before introducing our running example inSection 3. In Section 4, we discuss all steps of the

26Wirtz, R., Heisel, M., Meis, R., Omerovic, A. and Stølen, K.Problem-based Elicitation of Security Requirements - The ProCOR Method.In Proceedings of the 13th International Conference on Evaluation of Novel Approaches to Software Engineering (ENASE 2018), pages 26-38ISBN: 978-989-758-300-1Copyright © 2018 by SCITEPRESS – Science and Technology Publications, Lda. All rights reserved

ProCOR method in detail. The paper concludes with adiscussion of related work in Section 5 and an outlookon an evaluation we plan for our method in Section 6.

2 BACKGROUND

In this section, we introduce necessary backgroundknowledge. Our proposed method is mainly based onthe two concepts of Problem Frames and CORAS.

2.1 Problem Frames

To model requirements, we make use of MichaelJackson’s problem frames (Jackson, 2001) that can beexpressed using diagrams as shown in Figures 3 and4. Problem frames are patterns to describe subpro-blems of a complex software development problemin the early stages of the software development life-cycle. An instance of such a pattern is called pro-blem diagram and contains a functional requirement(dashed ovals) for the system-to-be. A requirement isan optative statement which describes how the envi-ronment of the software should behave when the soft-ware is in action. The entities related to a requirementare represented as domains (rectangles). There aredifferent types of domains: biddable domains (e.g.,persons), causal domains (e.g., technical equipment),machine domains (representing the software to bedeveloped, rectangle with vertical bars) and lexicaldomains (data representations). There are symbolicphenomena, representing some kind of information ora state, and causal phenomena, representing events,actions, operations and so on. Each phenomenon iscontrolled by exactly one domain and can be obser-ved by other domains. A phenomenon controlled byone domain and observed by another is called a sharedphenomenon between these two domains. Interfaces(solid lines) contain sets of shared phenomena. Such aset contains phenomena controlled by the same dom-ain (indicated by A!{...}, where A is an abbreviationfor the controlling domain). Some domains are refer-red to by a requirement (dashed line) via some phe-nomena, and at least one domain is constrained by arequirement (dashed lines with arrowhead) via somephenomena. The domains and their phenomena thatare referred to by a requirement are not influenced bythe machine, whereas we build the machine to influ-ence the constrained domain’s phenomena in such away that the requirement is fulfilled.

Faßbender et al. describe a way to draw problemdiagrams with regard to security, so that no domainis left out which might be relevant for the analysis(Faßbender et al., 2014).

2.2 CORAS

CORAS (Lund et al., 2010) is a model-based met-hod for risk management. It consists of a step-wiseprocess and different kinds of diagrams. The met-hod follows the ISO 31000 risk-management standard(ISO, 2009). Each step provides guidelines for the in-teraction with the customer on whose behalf the riskmanagement activities are carried out and how to addthe results to the model using the CORAS language.The method starts with the establishment of the con-text and ends up with the suggestion of treatments toaddress the risk.

The CORAS language consists of several ele-ments. In this work, we make use of the followingones: Direct Assets are items of value. There areHuman-threats deliberate, e.g. a network attacker,as well as Human-threats accidental, e.g. an em-ployee pressing a wrong button accidentially. To des-cribe technical issues Non-human threats are used,e.g. power loss of a server. A Threat scenario des-cribes a state, which may possibly lead to an unwan-ted incident, where an Unwanted incident describesthe action that harms an asset. Risk is defined as thecombination of a likelihood and a consequence accor-ding to ISO 31000 (ISO, 2009). In CORAS, the like-lihood of an unwanted incident which harms an assetand the consequence on the asset is used to derive arisk. Treatment scenarios are used to describe coun-termeasures to reduce the risk. The symbols we makeuse of in CORAS diagrams are shown in Figure 1.

The relations between CORAS and problem fra-mes we developed for this work are described inSection 4.1, using a conceptual model.

3 CASE STUDY

To exemplify out method, we use a running examplefor which we apply the different steps of the ProCORmethod.

The running example is a subsystem of a smartgrid system inspired by the OPEN meter project(OPEN meter Consortium, 2009). A smart grid isan intelligent power supply network, in which diffe-rent participants are able to interact and control the

Figure 1: CORAS Language (Lund et al., 2010).

Problem-based Elicitation of Security Requirements - The ProCOR Method

27

Unwanted Incident

Threat Scenario

Threat

initiates

leads to

Asset

Consequence

Risk

Likelihood

harms

has a

Security Requirement

aims toprotect

High-Level SR!addresses

Concretized SR

!specifies

Treatmentimplementedby

Requirement

Functional Requirement

Domain

applied at

refers toconstrains

associated with

associated with

CORAS elements Problem Frames ProCOR

reduction

for

Phenomenon

related to

**

*

***

*

* *

Figure 2: ProCOR Conceptual Model.

grid. For example, it is possible to retrieve the me-asurements of the power consumption remotely. Inthe following, we describe the main components ofthe scenario. The system-to-be (i.e., the machine) isthe Communication Hub. It serves as the connectionbetween all other components and actors and is usedto perform some calculations, e.g. to provide invoi-ces to the customer for consumed energy. Smart Me-ters measure the consumption of energy with sensors.They are connected to the Communication Hub usinga local metrological network (LMN) which might bewired or realized with a wireless connection. TheEnergy supplier is the provider of the smart grid. Itis able to do an initial setup locally on the communi-cation hub to be able to initiate a remote connectionfor later interaction. The End customer is the onewho pays the energy supplier’s invoices and in whosehome the communication hub is installed.

In this paper, we focus on two functional require-ments:

Setup: The energy supplier performs an initial setupfor the communication hub. The personal data of theclient and tariff parameters are stored in a configura-tion. Figure 3 shows the problem diagram for Setup.The requirement refers to a phenomenon of Energy-Supplier and constrains a phenomenon of Configura-tion.

Measuring: In given intervals, the communicationhub receives measured data from smart meters andstores it persistently. Figure 4 shows the problem dia-gram for Measuring. The requirement refers to a phe-nomenon of SmartMeter and constrains a phenome-non MeterData.

Configuration

Communi-cationHub Setup

EnergySupplier

a a

b c

a: ES!{insertConfiguration} b: CH!{storeConfiguration} c: C!{configuration}

Figure 3: Case study: Problem diagram for Setup.

MeterData

Communi-cationHub Measuring

SmartMeter

LMN

aa

b

c d

a: SM!{sendData} b: LMN!{forwardData} c: CH!{storeData} d: MD!{meterData}

Figure 4: Case study: Problem diagram for Measuring.

4 ProCOR METHOD

The ProCOR method consists of five steps. We firstintroduce a conceptual model which describes the dif-ferent terms used in the method and their relations.Next, we give an overview of the method which isfollowed by a detailed description of each step. Foreach step, we illustrate the method on the case studyintroduced in Section 3.

4.1 Conceptual Model

The conceptual model is shown in Figure 2 as a UMLclass diagram. All multiplicities not specifically men-tioned are considered as 1. The elements containedin CORAS are drawn in white. The meaning of theelements has already been described in Section 2.2.A Threat initiates some Threat Scenarios. Both ele-

ENASE 2018 - 13th International Conference on Evaluation of Novel Approaches to Software Engineering

28

ments are associated with a Domain, which is partof Jackson’s problem frames terminology. That ter-minology is shown in light gray. The association isused to identify risks based on the functional requi-rements. A Threat Scenario leads to some UnwantedIncidents. An Unwanted Incident harms some Assetswhich is related to a phenomenon with a specific Con-sequence, which is part of a Risk. A Risk exists for anAsset. A Likelihood is also part of a Risk. A Requi-rement can be of type Functional Requirement or Se-curity Requirement (SR) and refers to and constrainsDomains. A Security Requirement aims to protect anAsset. A High-Level SR is a specialization and addres-ses a Risk, whereas a Concretized SR specifies howthe risk is reduced. A Concretized SR is implementedby some Treatments, which are applied at a Domain.Thus, a Treatment is used to avoid or mitigate a ThreatScenario or Threat contained in this Domain.

4.2 Overview

Figure 5 provides an overview of the five steps of theProCOR method. For each step, we define the neces-sary external inputs, as well as the outputs. The gene-rated output serves as an input for the following stepsand can be used for documentation purposes. We dis-tinguish three stakeholder roles: analysts take part ineach step of the method. Therefore, we do not showthem explicitly in Figure 5. Customers are the oneson whose behalf the analysts perform the risk analy-sis. Experts are persons with specific knowledge, e.g.,about threats.

The method is structured as follows: (1) First, thescope and focus of the risk analysis are defined, basedon the security goals of the customer and the functi-onal requirements, which are expressed as problemdiagrams. (2) The risks for the assets are identifiedand are documented with a CORAS threat diagram.(3) To evaluate the risks, likelihoods and consequen-ces are estimated and annotated in the threat diagram.For each unacceptable risk, a high-level security re-quirement is set up. (4) To fulfill the high-level se-curity requirements, treatments that reduce the risksare selected. These treatments are evaluated with re-spect to their costs, which should not be higher thanthe value of the asset they protect. The selected treat-ments are then added to the threat diagram. (5) Foreach high-level security requirement, a concretizedsecurity requirement is set up, which reflects the cho-sen treatments. Finally, for each concretized securityrequirement, a treatment problem diagram is set up.Such a diagram is similar to a problem diagram. Itstates which domains are referred to and constrainedwhen fulfilling the concretized security requirements

using the selected treatment. Thus, security require-ments can be incorporated in the subsequent softwaredevelopment process in a similar way as functionalrequirements.

In addition, we identified validation conditions foreach step that check the coherence of the results ofeach step, thus helping to identify errors in the appli-cation of the method as early as possible. We giveexamples of such validation conditions in the follo-wing. For reasons of space, we cannot present all ofthem.

We now describe each of the above steps in detail.

4.3 Step 1: Definition of Scope & Focus

In the first step, we define the focus (assets to be pro-tected) and scope (domains which shall be conside-red) of the analysis.

4.3.1 Description

With ProCOR, we aim to support the protection ofinformation in a software-based system with regardto the three security properties confidentiality, inte-grity and availability. In problem diagrams, informa-tion is represented by symbolic phenomena, whereascommands or events are represented by causal pheno-mena. Hence, we define an asset as a combination ofa symbolic phenomenon and a security property. Theresults are documented in a table, such as Table 1. Wealso document the value of the asset for the customerto make it comparable with the costs of a treatment.

The scope of the analysis is defined as the setof domains where the information to be protected isavailable. “Available” means that the domain obser-ves or controls the symbolic phenomenon represen-ting the information to be protected, as specified inthe set of problem diagrams that is part of the inputfor this step. However, it does not suffice to onlyconsider symbolic phenomena, because valuable in-formation can also be part of commands or events,i.e., causal phenomena. For example, there may bean interface with a causal phenomenon to store someuser data. This phenomenon is a command, but con-tains information in form of user data. Hence, it isnecessary to document that a phenomenon is contai-ned in another to decide whether an interface containssome information or not.

To document the availability of information at adomain and the information flow between domains,we developed the concept of an Information FlowGraph, which is a directed graph. Its nodes are dom-ains, and its edges denote the information flowingfrom one domain to another. To create this graph, weconsider all interfaces contained in the set of problem


29

Step 1: Definition of Scope & Focus

- Security goals of customer- Problem diagrams

- List of assets- Information flow graph- Domains in scope

Step 2: Risk Identification

Step 3: Risk Evaluation & High-Level SR

- Threat expertise

- Threat diagram- Annotated threat diagram- Set of high-level security requirements- Risk matrices

Step 4: Treatment Selection & Evaluation

- Augmented threat diagram

External

Inpu

tMetho

dInpu

t/Outpu

t

Step 5: Concretized SR & Treatment

Problem Diagrams

- Set of concretized security requirements- Treatment problem diagrams

C

E

Customer

Expert

C E E EC

Legend:

Figure 5: ProCOR Method Overview.

diagrams. A domain is contained in the graph iff itobserves or controls a phenomenon that is related toan asset. Either, the phenomenon is a symbolic one,which contains the asset directly. Or the phenomenonis related to such a symbolic phenomenon, as explai-ned earlier.

The directed edges of the graph indicate an asset-related information flow. The starting nodes of theedges are the domains which control the asset-relatedsymbolic phenomenon or the one in which it is con-tained. The end nodes are the domains that observethe respective phenomenon.

As a result, the domains that are contained in thegenerated graph are considered to be in scope of theanalysis, because the information to be protected isavailable there. In the next step, risks for the assetsare identified at these domains.

4.3.2 Validation Conditions

We identified the following validation conditions(VCs) for the definition of focus and scope:

VC1 All interfaces contained in the set of problem di-agrams are considered for the information flowgraph.

VC2 Only domains on which an asset-related in-formation is available are considered to be inscope.

VC3 For all information to be protected, the desiredsecurity goals (confidentiality, integrity, availa-bility) are documented.

4.3.3 Case Study

The ProCOR method is carried out based on the pro-blem diagrams shown in Figures 3 and 4. We assumethat a fictitious customer has specified the assets to beprotected as given in Table 1. The values of the assets

are estimated in Euros per year according to the follo-wing reasoning: (1) The integrity of tariff parametershas a value of 20.000 Euros because without correctparameters, the invoicing cannot be performed cor-rectly. Because of periodical updates of the parame-ters, incorrect parameters will be overwritten at sometime. Therefore, the incorrect values exist only fora limited amount of time. This results in a relativelysmall value of the asset. (2) The availability of measu-red data is important for invoicing, too. The absenceof measured data leads to the case that an invoicing isnot possible. In this case, an employee needs to col-lect the data manually. For this reason, we estimatethe overall costs for all clients to 10.000 Euros. (3)A harm of the integrity of stored measured data leadsto an incorrect invoicing. Due to the high number ofclients of an energy supplier, the financial consequen-ces are estimated with 50.000 Euros.

Next, we have to identify the phenomena in Fi-gures 3 and 4 that are related to the assets givenin Table 1. The results of that identification pro-cess are shown in Figure 6. The symbolic pheno-mena which are considered as an asset are shownin gray. An arrow pointing from one phenome-non to another means that it is contained in the ot-her one. For example, ES!{clientData} representingthe personal information of a client is contained inES!{insertConfiguration}.

The corresponding information flow graph isshown in Figure 7. Below a domain name, the avai-lable asset-related information is given in gray. For

Table 1: Asset documentation.

Symbolic Phe-nomenon

Security Pro-perty

Value

tariffParameters Integrity 20.000 EurosmeasuredData Availability 10.000 EurosmeasuredData Integrity 50.000 Euros


30

ES!{insertConfiguration} CH!{storeConfiguration}

C!{configuration}

ES!{tariffParameters} ES!{clientData}

SM!{measuredData}

MD!{meterData}

SM!{sendData} LMN!{forwardData}

CH!{storeData}

Figure 6: Case study: Phenomena relations.

ConfigurationtariffParameters

Communi-cationHub

measuredData,tariffParameters

EnergySuppliertariffParameters

SmartMetermeasuredData

LMNmeasuredData

MeterDatameasuredData

a

a

a

b

b

a: measuredDatab: tariffParameters

Figure 7: Case study: Information flow graph.

example, at the domain Configuration the informationtariffParameters is available, and there is a correspon-ding information flow to this domain from the Com-municationHub.

4.4 Step 2: Risk Identification

Based on the definition of focus and scope, we nowidentify possible risks for the assets.

4.4.1 Description

To identify risks, we make use of a structured brain-storming process as proposed by CORAS (Lund et al.,2010). The analysts moderate a meeting with expertswhich have different expertises. The results of thisbrainstorming session are documented in a threat di-agram. Such a diagram (see Figure 8) contains CO-RAS elements as described in Section 2.2, and rela-tions between them, as described in the conceptualmodel given in Section 4.1.

The domains that are contained in the informationflow graph are inspected in this meeting, and possibleattacks on these domains have to be elicited. For ex-ample, a domain representing an employee needs in-vestigation for social engineering attacks. However,it might be the case that additional domains have tobe considered for risk identification. This is becausethe information flow graph has been created based onthe functional requirements. These requirements only

Integrity of tariffParameters

Integrity of measuredData

Availability of measuredData

Changed tariff parameters

Bribe EnergySuppli

erEndCustomer

Disrupt frequency of

LMN

Incorrect transmission of data

No transmission of data

EndCustomer

Figure 8: Case study: Threat diagram.

describe the desired behavior. For example, the at-tacker who performs a social engineering attack onthe employee is not part of the desired behavior andis hence not contained in the information flow graph.This threat is then newly introduced in the threat dia-gram, even though it is not contained in any problemdiagram.


We identified the following validation conditions forthe risk identification:VC1 All domains contained in the information flow

graph have to be investigated for some threat orthreat scenario.

VC2 Only domains on which an asset-related infor-mation is available can have a threat or threatscenario which can harm the asset.

4.4.3 Case Study cont’d

Figure 8 shows the outcome of the risk identificationprocess for our case study. There is one human-threatdeliberate EndCustomer who bribes the energy sup-plier (threat scenario) to change the tariff parameters(unwanted incident). This harms the integrity of thetariff parameters (asset). The end customer is also ahuman-threat accidental who disrupts the frequencyof the local metrological network (threat scenario),for example by using the same frequency for otherpurposes. This leads to two unwanted incidents. First,the integrity of measured data (asset) is harmed byan incorrect transmission of data (unwanted incident).Second, the availability of measured data (asset) isharmed by no transmission of data (unwanted inci-dent).

4.5 Step 3: Risk Evaluation &High-Level Security Requirements

In this step, we evaluate the identified risks and set upa high-level security requirement for each unaccepta-


31

ble risk, based on a given risk matrix.

4.5.1 Description

The risk evaluation process is performed as propo-sed by CORAS (Lund et al., 2010). Based on thethreat diagram and the knowledge of experts, likeli-hoods and consequences are estimated. There is a li-kelihood for the following elements of the threat dia-gram: (1) for a threat to initiate a threat scenario, (2)for a threat scenario to occur, (3) for a threat scenarioleading to an unwanted incident and (4) for an unwan-ted incident to occur. The likelihoods for (2) and (4)are derived from the likelihoods of the incoming ed-ges (i.e., (1) and (3)) based on empirical knowledgeabout the dependencies between the different likeli-hoods. The consequences for an asset are annotatedon the relation between an unwanted incident and anasset. Thus, it describes what consequence an unwan-ted incident has on an asset.

The likelihoods and consequences are expressedusing scales. These scales can for example be definedbased on intervals. To evaluate the risks, we make useof a risk matrix. For each asset, a risk matrix mustbe defined. On the x-axis of the matrix, the differentvalues of the consequence scale and on the y-axis thevalues for the likelihood scale are annotated. Since arisk consists of a likelihood and a consequence, a cellin the matrix denotes a risk level. For each risk le-vel, it must be decided whether the risk is acceptableor not. Each risk of the threat diagram, representedas the likelihood of an unwanted incident and the cor-responding consequence on an asset, is added to therisk matrix. Using the matrix, it is now possible todecide whether a risk is acceptable or not. For eachunacceptable risk, a high-level security requirement(HL-SR) is set up, which describes the necessary riskreduction. Such a requirement is expressed using thefollowing textual pattern:

Ensure that the risk for A due to UI caused byT S and initiated by T is acceptable accor-ding to the risk matrix of the asset.

A stands for the asset, UI for the unwanted incident,T S for the set of threat scenarios that lead to the un-wanted incident and T for the set of threats that initi-ate the threat scenarios.

To achieve such a likelihood reduction and the-reby fulfill the HL-SR, we select treatments in thenext step.


We identified the following validation conditions forthe risk evaluation and the instantiation of high-levelsecurity requirements:





Bribe EnergySuppli

erEndCustomer


LMN



EndCustomer

20.000

50.000

10.000

10/y

10.000/y

0.02

0.5

0.01

0.2/y

5.000/y

100/y

10/y

10.000/y

Figure 9: Case study: Threat diagram with annotated risks.

VC1 All likelihoods and consequences are documen-ted in the threat diagram to ensure a correct es-timation of the risks.

VC2 For each asset, a risk matrix is defined whichspecifies the acceptable and unacceptable risksfor that asset.

VC3 The likelihood scales and consequence scalesused for the documentation in the threat dia-gram are consistent with the ones used in therisk matrices.

VC4 For each risk that is considered as unacceptableaccording to the corresponding risk matrix, ex-actly one high-level security requirement is setup.


In Figure 9, we show the threat diagram with anno-tated likelihoods and consequences. We express thelikelihood of an event as the frequency of the eventper year. We assume that ten times a year some endcustomer tries to bribe the energy supplier, which issuccessful in 2% of the cases and leads to a change oftariff parameters. The consequence is given in Eurosas a value loss, here 20.000 Euros. There are 10.000disruptions of the local metrological network by theend customer per year, because the local metrologicalnetwork and most of the wireless equipment used inprivate areas make use of the 2.4GHz band. In 50%of the cases, this leads to an incorrect transmission ofdata and a value loss of 50.000 Euros for the integrityof measured data. In one percent of the cases it leadsto no transmission of data, which harms the availabi-lity of measured data completely and hence, producesa value loss of 10.000 Euros.

Since there is only at most one incoming edge perelement, the likelihood for each unwanted incident iscalculated by multiplying both previous likelihoods.The risk for each pair of unwanted incident and assetis documented in Table 2. The risks are then added tothe risk matrix as shown in Table 3. Here, we assume


32

that the values for the risk matrix are the same foreach asset. The unacceptable risks are marked withgray. Hence, there are three unacceptable risks, and itis necessary to provide a high-level security require-ment for each of them:HL-SR1. Ensure that the risk for Integrity of tariff-

Parameters due to Changed tariff parameters cau-sed by {Bribe EnergySupplier} and initiated by{EndCustomer} is acceptable according to therisk matrix of the asset.

HL-SR2. Ensure that the risk for Integrity of mea-suredData due to Incorrect transmission of datacaused by {Disrupt frequency of LMN} and ini-tiated by {EndCustomer} is acceptable accordingto the risk matrix of the asset.

HL-SR3. Ensure that the risk for Availability of me-asuredData due to No transmission of data cau-sed by {Disrupt frequency of LMN} and initiatedby {EndCustomer} is acceptable according to therisk matrix of the asset.

Table 2: Case study: Risk calculation.

No. UnwantedIncident

Asset Risk( f requ./y× consequ.)

(1) Changedtariffparameters

Integrity oftariffPara-meters

(0.2, 20.000)

(2) Incorrecttransmis-sion ofdata

Integrity ofmeasured-Data

(5.000,50.000)

(3) No trans-mission ofdata

Availabilityof measu-redData

(100,10.000)

Table 3: Case study: Risk matrix.

4.6 Step 4: Treatment Selection &Evaluation

In this step, we first select treatments based on thethreat diagram to fulfill the previously determinedhigh-level security requirements. Then, the treat-ments are evaluated to decide whether an applicationis worthwhile or not, based on the overall costs com-pared to the value of the asset.

4.6.1 Description

For each high-level security requirement, treatmentshave to be selected to achieve the necessary risk re-duction. The elements which a treatment can possiblyaddress are described in the high-level security requi-rement (threats and threat scenarios) and can also befound in the threat diagram. As shown in the concep-tual model (see Section 4.1) a threat or threat scena-rio, respectively, is associated with a domain. The-refore, a treatment is applied at that domain. A tre-atment either leads to a likelihood or a consequencereduction. To express this in a threat diagram, we ex-tend the CORAS language with a new arrow type for atreatment scenario, called addresses, which points tothe likelihood or consequence to be reduced, whereasthe treats arrow points to the threat or threat scenarioon whose domain the treatment is applied.

The treatments can be selected in a brainstormingsession. It is necessary to add treatments until all riskshave been reduced to an acceptable level. If such a re-duction is not possible, the high-level security requi-rement cannot be fulfilled. The customer then has todecide whether to accept a higher risk (changing therisk matrix), change the functional requirements, e.g.by not offering risky services any more, or search forother possibilities to mitigate the unacceptable risk.

Furthermore, the treatments should not cost morethan the value of the asset they protect. Therefore, itis necessary to calculate the overall costs for all tre-atments that are related to a high-level security requi-rement. The overall costs are then compared to thevalue of the asset to be protected. If the costs are hig-her than the value, the customer has to decide how toproceed with the development, similarly as describedabove.


We identified the following validation conditions forthe selection of treatments:

VC1 Treatments are selected in the way that they re-duce a certain risk (consequence and/or likeli-hood) and are applied to a domain that is relatedto a threat or threat scenario which leads to therisk.

VC2 The costs for treatments are not higher than thevalue of the asset to be protected.

VC3 All risks are reduced to an acceptable level ac-cording to the risk matrices.


33


We selected three treatments to illustrate the fourthstep of our method, using fictitious values for theircosts. (1) To reduce the likelihood that bribing theenergy supplier will be successful, there is a treatmentproviding better working conditions, e.g. more mo-ney. There are only few employees who are able tochange the tariff parameters. Hence, the costs of thetreatment are 5.000 Euros. This is less than the va-lue loss of 20.000 Euros. The likelihood reduction isestimated to be 80%. The residual likelihood for theunwanted incident is then 10∗(1−0.8)∗0.02 = 0.04.According to the risk matrix (see Table 3), the risk isnow acceptable. (2) To avoid disruption of the localmetrological network (LMN), the frequency is repla-ced by a 5GHz band. As there are major changes tothe LMN, the costs are estimated with 40.000 Euros.This treatment addresses two likelihoods, because thethreat scenario leads to two unwanted incidents. Bothlikelihoods are reduced by 99,9%, because the 5GHzband allows much more concurrent connections. Thevalue loss for an incorrect transmission of data is50.000 Euros, and for no transmission of data it is10.000 Euros. Hence, the costs of the treatment areless than the value loss. Recalculating the likelihoodsfor the unwanted incidents leads to 5/y for an incor-rect transmission and 0.1/y for no transmission. Ac-cording to the risk matrix, the likelihood for an incor-rect transmission is still too high, so we need an addi-tional treatment. (3) The implementation of a check-sum can be realized by an existing component thatcan be applied at the LMN. The costs are 1.000 Euros.Since a checksum makes it possible to detect modifi-cations of data, the consequences for the integrity ofmeasured data are reduced by 99%. In fact, the incor-rect data is still transmitted, but the communicationhub as the receiver is able to detect the incorrectness.The incorrect data will not be used for the invoicing.There is still a value loss, because the data has to beretrieved in a different way. The residual consequenceis (1−0.99)∗50000 Euros = 500 Euros. Accordingto the risk matrix and the likelihood reduction by thesecond treatment, the risk is now acceptable.

There are no unacceptable risks left in our exam-ple, and hence all high-level security requirementscan be fulfilled. The augmented threat diagram con-taining all treatment scenarios is shown in Figure 10.

4.7 Step 5: Concretized SecurityRequirements & TreatmentProblem Diagrams

Based on the previously determined high-level secu-rity requirements and the proposed treatments, weconcretize the security requirements and close the ci-rcle to the functional requirements by setting up treat-ment problem diagrams.

4.7.1 Description

A Concretized Security Requirement (C-SR) adds in-formation about selected treatments to a high-level se-curity requirement. For this reason, there is one C-SRfor each HL-SR set up in step 4. A C-SR has the fol-lowing form:

The risk for A due to UI caused by T S andinitiated by T is reduced to an acceptable le-vel according to the risk matrix of the asset byapplying T R.

There, T R describes the required treatments as aset of tuples domain× treatment where domain des-cribes the domain to which the treatment is applied.To align the concretized security requirements withthe functional ones, we introduce a new type of pro-blem diagram, called Treatment Problem Diagram. Incontrast to a functional requirement, a C-SR is not im-plemented by a machine but by a treatment. This tre-atment can be technical. In this case, it could lead to asoftware development problem, similar to the functi-onal requirements. But treatments can also be non-technical, for example training personnel to resist so-cial engineering attacks. Therefore, a new type of pro-blem diagrams is needed to specify the treatments to





Bribe EnergySuppli

erEndCustomer


LMN



EndCustomer

20.000

50.000

10.000

10/y

10.000/y

0.02

0.5

0.01

Better working conditions, e.g.

more money

5.000 0.8

40.0000.999

Replace frequency by

5GHz

0.999

Implement Checksums

1.000

0.99

0.2/y

5.000/y

100/y

0.04/y

5/y

0.1/y

500

10/y

10.000/y

Figure 10: Case study: Threat diagram with treatments.


34

be implemented and their effects on the relevant dom-ains.

As a counterpart of the machine domain in pro-blem diagrams, we introduce a new domain type cal-led treatment for treatment problem diagrams. Foreach C-SR, one treatment problem diagram must beset up. All domains and treatments given by the C-SR are added to the diagram. To indicate that a treat-ment treats a domain, we add an interface between thetreatment domain and treated domain. These dom-ains share a phenomenon controlled by the treatmentdomain, which describes how the treated domain isinfluenced. The C-SR constrains the treated domainand refers to all other domains related to the elementsmentioned in the C-SR. The referring edges of the re-quirement are annotated with a phenomenon that iscontrolled by the domain and describes the harm onthe asset.

The result of the last step is an extended require-ment model consisting of a set of functional requi-rements, expressed as problem diagrams, and a setof security requirements, expressed as treatment pro-blem diagrams. In subsequent phases of a softwaredevelopment lifecycle, it is now possible to considerboth types of requirements directly and to ensure thatthe security requirements are considered right fromthe beginning of the software development process,instead of treating them as an add-on.


We identified the following validation conditions forthe instantiation of concretized security requirementsand the creation of treatment problem diagrams:

VC1 For each high-level security requirement, thereis exactly one concretized security requirement.

VC2 Each concretized security requirement is repre-sented by exactly one treatment problem dia-gram.

VC3 Only domains that are related to the concretizedsecurity requirement are contained in the treat-ment problem diagram.

VC4 A domain in a treatment problem diagram isconstrained iff a treatment is applied to it.

VC5 For each applied treatment, a treatment domainis contained in the treatment problem diagram.


We had identified three high-level security require-ments. Hence, we have to set up three concretizedsecurity requirements (C-SR).

EndCustomer

C-SR1EnergySupplier a

c

a: ES!{insertConfiguration} b: WC!{payMoreMoney} c: EC!{bribeEnergySupplier}

Working Conditions

b

Figure 11: Case study: Treatment problem diagram for C-SR1.

C-SR1. The risk for Integrity of tariffParameters dueto Changed tariff parameters caused by {BribeEnergySupplier} and initiated by {EndCustomer}is reduced to an acceptable level accordingto the risk matrix of the asset by applying{(EnergySupplier, Better working conditions e.g.more money)}.

C-SR2. The risk for Integrity of measuredData dueto Incorrect transmission of data caused by{Disrupt frequency of LMN} and initiated by{EndCustomer} is reduced to an acceptable levelaccording to the risk matrix of the asset by ap-plying {(LMN, Implement checksums),(LMN, Re-place frequency by 5GHz)}.

C-SR3. The risk for Availability of measuredDatadue to No transmission of data caused by{Disrupt frequency of LMN} and initiated by{EndCustomer} is reduced to an acceptable levelaccording to the risk matrix of the asset by ap-plying {(LMN, Replace frequency by 5GHz)}.We have to set up three treatment problem dia-

grams, one per concretized security requirement. Amachine domain is represented by a rectangle withtwo vertical bars. Similarly, we represent the ne-wly introduced treatment domain with two horizontalbars.

Figure 11 shows the treatment problem diagramfor C-SR1. The domain EnergySupplier is constrai-ned, because the application of the treatment Wor-kingConditions, describing a better payment for theemployees, influences that domain. The domain En-dCustomer is referred to by C-SR1, because the endcustomer is mentioned in the requirement.

Figure 12 shows the treatment problem diagramfor C-SR2. Since there is no treatment for domainEndCustomer, the requirement only refers to it. Forthe domain LMN, there are two treatments. Thus, it isconstrained by the requirement. The treatment New-Frequency enables the LMN to make use of a 5GHzband. The treatment ImplementChecksums allows thegeneration of message codes to verify the correctnessof transmitted data.

Figure 13 shows the treatment problem diagram


35

EndCustomer

C-SR2

LMN a

c

a: LMN!{forwardData} b: NF!{use5GHz} c: EC!{disruptFrequency} d: IC!{generateMessageCode}

NewFrequency

b

Implement Checksums

d


EndCustomerC-SR3

LMN a

c

a: LMN!{forwardData} b: NF!{use5GHz} c: EC!{disruptFrequency}

NewFrequency

b


for C-SR3. It is similar to the one for C-SR2, exceptthat the implementation of a new frequency sufficesto fulfill the requirement.

The final requirements model now consists of thefunctional requirements represented as problem dia-grams and the security requirements represented astreatment problem diagrams.

5 RELATED WORK

Faßbender et al. (Faßbender et al., 2014) propose thePresSuRE method. The method provides a process toelicit security requirements. The starting point of theprocess are functional requirements, represented asproblem diagrams. The authors define an elicitationprocess which consists of an identification of assetsand an elicitation of attackers and their abilities basedon attacker templates. The security requirements arederived from graphs that are created based on the in-formation about the functional requirements and theelicited knowledge about attackers. The process doesnot cover a risk estimation or risk evaluation. Theselection of treatments is not part of the method, aswell.

The CORAS method (Lund et al., 2010) (seeSection 2.2) is a model-based method for risk mana-gement. For each step, the input and output is definedas well as a language to describe the results in a mo-del. The method is used for existing software. The se-curity requirements are not explicitly stated, but thereis a risk-based selection of treatments to achieve anacceptable risk level.

MAGERIT (Ministerio de Administraciones Pu-

blicas, 2014) is a methodology for Information Sys-tems Risk Analysis and Management. It consists ofseveral books. Book 1 describes the risk managementmethod itself, which covers all steps of the risk mana-gement process and provides detailed mechanisms toevaluate the risk. There are no security requirements,and the method is not model-based.

Mayer et al. provide a risk-based security engi-neering framework (Mayer et al., 2005). The frame-work is used in the earliest stages of a software deve-lopment life-cycle. It describes a way to extend exis-ting requirements engineering methods with securityaspects. The framework describes an iterative way toperform this extension. It is not model-based, and nosecurity requirements are produced.

Herrmann et al. propose a method for managingIT risks (Herrmann et al., 2011). This method pro-vides a risk identification with a corresponding riskprioritization and a selection of countermeasures toaddress the identified risk. The security requirementsare elicited based on business goals. Business goalsdescribe the expectations of different stakeholders forthe software. For each business goal, one has to de-cide whether it is related to security. The method isnot based on functional requirements, and is appliedto an existing software. It is not model-based.

In Section 6.1, we refer to Microsoft’s STRIDE(Shostack, 2014). STRIDE is a popular security fra-mework which is used to identify security threats.Using data flow diagrams for modeling the systemand its behavior, threats are elicted based on existingthreat categories. In the end, threats are documen-ted as a basis for the instantiation of security requi-rements. The security requirements are not part ofSTRIDE.

6 CONCLUSION AND OUTLOOK

In this paper, we have described a step-wise methodto derive security requirements from functional requi-rements based on a risk analysis to protect valuableinformation. We make use of models to document theresults of each step and to express the relations be-tween the functional requirements and the identifiedrisks. The relations between the models are clearlydefined using a conceptual model. The risk evaluationand the resulting high-level security requirements en-sure that only unacceptable risks are treated. This isachieved by selecting appropriate treatments and set-ting up concretized security requirements that specifyhow the necessary risk reduction can be achieved. Toensure that the security requirements can be taken intoaccount in the software development process in a si-


36

milar way as the functional requirements, we repre-sent the elicited security requirements in a similar wayas the functional ones. Finally, the validation condi-tions of our method assist analysts in detecting errorsin the application of the method as early as possible.

6.1 Experimental Evaluation

We plan to evaluate the ProCOR method with an ex-periment. With this evaluation, we aim to measurethe performance and success rate of our method. Ourexperimental setup is inspired by an evaluation ofMicrosoft’s STRIDE (Scandariato et al., 2015). Inthis study, the authors evaluate Microsoft’s method,e.g. with regard to its performance, but do not com-pare it with other methods. Since we introduce no-vel elements such as treatment problem diagrams, itis not possible to compare our ProCOR method di-rectly with existing ones. The cited study can there-fore serve as a blueprint for our experiment.

The experiment will be carried out as an applica-tion of the ProCOR method. As an initial input, weprovide a document describing a case study. It con-sists of a detailed textual description of the scenario,the security goals of the customer and the set of initialproblem diagrams. These elements represent the in-put of Step 1 of the ProCOR method. We plan to haveseveral groups of five participants which perform theexperiment independently. All groups start with thesame amount of (virtual) money and time that is avai-lable for the analysis. The comparison of the differentgroups is used to avoid statistical flaws. During theexperiment, there will be some experts available forthe participants who can be asked for help. Asking anexpert for help will cost money.

We define the following research questions (RQ)to be addressed during the experiment:

RQ1 How many correct threats can be identified byapplying the ProCOR method?Scandariato et al. define an expected rate of onethreat per hour (Scandariato et al., 2015). Wewill adapt this assumption. The threats that areconsidered as correct have to be defined beforeexecuting the experiment.

RQ2 How long does each phase of the method take?Does the method help to reduce the effort forthe steps?We define a maximum time for the analysis inperson hours. We will not assign a specific timeslot to any step. Hence, the participants are freein their time management. We will record thetime that is used for each step. Additionally,we will make use of camcorders to record the

performance. Together with the measured time,we will be able to identify problems during theapplication of the method.

RQ3 How much interaction between the experts andthe participants takes place during the experi-ment?A certain amount of money is available for theanalysis. For each consultation of an expert,the participants have to pay which limits theamount of expert help the participants can re-ceive. Based on the money that is left in theend, we will be able to measure the contributionof the participants compared to the input that isprovided by the experts.

RQ4 How confident are the participants of their per-formance?After the experiment, we plan to make inter-views with the participants and ask them abouttheir feelings and their self-confidence aboutthe results. The results of these interviews willbe compared with the actual results as desribedin the other research questions.

6.2 Future Work

In the future, we will investigate in more detail howthe treatments are considered in the subsequent de-sign and implementation phases. Moreover, we in-tend to support some of the brainstorming processeswith further methods, e.g., a systematic risk identifi-cation method. Currently, we assume that there areexperts with a deeper background knowledge aboutthreats. Our vision is to provide a library of possiblethreats and to assist the analysts in identifying the re-levant threats by searching the library. Such a libraryhas been proposed by Uzunov and Fernandez (Uzu-nov and Fernandez, 2014). The search process shallbe based on problem diagrams or problem frames, asthese are reusable patterns.

We intend to provide a web-based tool which as-sists analysts in enacting the method. The results ofeach step are documented in a model. This allowsthe analysts to generate a documentation automati-cally and to ensure consistency between the differentdiagrams. Some of the proposed validation conditi-ons can be checked automatically. The documenta-tion can be used to certify the developed software ac-cording to a standard. The tool will provide a walk-trough of the steps described in Section 4. For addingnew diagrams, we will provide a graphical diagramcreation tool.


37

REFERENCES

Faßbender, S., Heisel, M., and Meis, R. (2014). FunctionalRequirements Under Security PresSuRE. In ICSOFT-PT 2014 - Proceedings of the 9th International Confe-rence on Software Paradigm Trends, Vienna, Austria,29-31 August, 2014. SciTePress.

Herrmann, A., Morali, A., Etalle, S., and Wieringa, R.(2011). Riskrep: Risk-based security requirementselicitation and prioritization. In 1st Intern. Works-hop on Alignment of Business Process and SecurityModelling, ABPSM 2011, Lect. Notes in Business In-form. Processing. Springer Verlag.

ISO (2009). ISO 31000 Risk management – Principles andguidelines. International Organization for Standardi-zation.

Jackson, M. (2001). Problem Frames: Analyzing and Struc-turing Software Development Problems. Addison-Wesley Longman Publishing Co., Inc.

Lund, M. S., Solhaug, B., and Stølen, K. (2010). Model-Driven Risk Analysis. The CORAS Approach. Sprin-ger.

Mayer, N., Rifaut, A., and Dubois, E. (2005). Towards arisk-based security requirements engineering frame-work. In In Proc. of REFSQ’ 05.

Ministerio de Administraciones Publicas (2014). MAGERIT- version 3.0. Methodology for Information SystemsRisk Analysis and Management. Book I - The Method.Ministry of Finance and Public Administration.

OPEN meter Consortium (2009). Report on the identifi-cation and specification of functional, technical, eco-nomical and general requirements of advanced multi-metering infrasturcture, including security require-ments.

Scandariato, R., Wuyts, K., and Joosen, W. (2015). A des-criptive study of Microsoft’s threat modeling techni-que. Requirements Engineering, 20(2):163–180.

Shostack, A. (2014). Threat Modeling: Designing for Se-curity. Wiley.

Uzunov, A. and Fernandez, E. (2014). An extensiblepattern-based library and taxonomy of security thre-ats for distributed systems. Computer Standards &Interfaces, 36.


38

Documents

Problem-based Elicitation of Security Requirements The