Softw Syst Model DOI 10.1007/s10270-016-0560-y

REGULAR PAPER

Holistic security requirements analysis for socio-technical systems Tong Li1 · Jennifer Horkoff2 · John Mylopoulos1

Received: 26 October 2015 / Revised: 22 April 2016 / Accepted: 23 August 2016 © Springer-Verlag Berlin Heidelberg 2016

Abstract Security has been a growing concern for large organizations, especially financial and governmental institutions, as security breaches in the systems they depend on have repeatedly resulted in billions of dollars in losses per year, and this cost is on the rise. A primary reason for these breaches is that the systems in question are “socio-technical” a mix of people, processes, technology, and infrastructure. However, such systems are designed in a piecemeal rather than a holistic fashion, leaving parts of the system vulnerable. To tackle this problem, we propose a three-layer security analysis framework consisting of a social layer (business processes, social actors), a software layer (software applications that support the social layer), and an infrastructure layer (physical and technological infrastructure). In our proposal, global security requirements lead to local security requirements, cutting across conceptual layers, and upper-layer security analysis influences analysis at lower layers. Moreover, we propose a set of analytical methods and a systematic process that together drive security requirements analysis across the three layers. To support analysis, we have defined corresponding inference rules that (semi-)automate the analysis, helping to deal with system complexity. A prototype tool has been implemented to support analysts throughout the analysis

Communicated by Prof. Ruth Breu.

B

Tong Li [email protected] Jennifer Horkoff [email protected] John Mylopoulos [email protected]

1

University of Trento, Trento, Italy

2

City University, London, UK

process. Moreover, we have performed a case study on a real-world smart grid scenario to validate our approach. Keyword Security requirements · Goal model · Enterprise architecture · Socio-technical system · Security pattern

1 Introduction Socio-technical systems (STSs) are organizational systems consisting of people, business processes, software applications, and hardware components. Such systems often include a rich physical infrastructure consisting of not only computers, but also buildings, cable networks, and the like. Due to their ever-increasing complexity, STSs have been experiencing a growing number of security breaches [20], caused by security flaws and vulnerabilities. A common theme for many of these breaches is that security solutions are not designed in a holistic fashion. Rather, they are dealt with in a piecemeal fashion, by different analysts, and at different times, using different analysis techniques, focusing on only one conceptual “layer” of the system at a time. Specifically, Mouratidis [50] and Liu [46] analyze security issues at an organizational level; Herrmann [28] analyzes security requirements at a business process level; Lamsweerde investigates security requirements for software [68]. Without taking into account the interactions among different layers of a system, a piecemeal security analysis leads to gaps and vulnerabilities for parts of an STS, while other parts may be over-protected. For example, when dealing with the security of energy consumption data within a metering system, the security features of a physical meter cannot be correctly determined without considering the business processes of data metering. If data metering is performed by a human who can detect physical tampering on meters,

123

T. Li et al.

then the physical meter does not require additional security protections. On the contrary, if data metering is performed automatically and remotely by a smart meter, then appropriate anti-tampering treatments have to be deployed to protect the meter. To address this problem, we propose a framework which holistically analyzes security requirements for STSs based on system functional requirements. In particular, we consider three STS layers: a social layer (business processes, social actors), a software layer (software applications that support the social layer), and an infrastructure layer (physical and technological infrastructure). Within this framework, each layer focuses on particular concerns and has its own requirements and specifications, which are captured by goaloriented requirements models. Specifically, specifications in one layer dictate requirements in lower layers, and such dependencies are captured by cross-layer links. As a result, the proposed framework not only performs security requirements analysis at each of the three layers, but also takes into account the interdependencies among layers. As a final output, the framework generates holistic security solutions that can satisfy security requirements at all layers, achieving robust security protection. Using this three-layer framework, a systematic process is proposed to drive security analysis both within each layer and across layers. In particular, we take system functional requirements and high-level security requirements as input, iteratively perform security requirements analysis throughout the three layers in order to generate holistic security solutions. To support analysts without much security knowledge, we propose a collection of formal inference rules, which have been implemented in a prototype tool [44]. In addition, we adopt security patterns from the literature [3,59] to help analysts to tackle known security problems. We have presented elements of our framework in previous work, consisting of conference papers. In particular, the overall three-layer framework and security analysis process were presented in [42], and a prototype tool was later developed to support part of the analysis process [44]. During subsequent evaluation of the three-layer framework, we discovered challenges to selecting security patterns during the analysis of security goal operationalization. In subsequent research, we studied the systematic modeling and selection of security patterns [43], while [45] exclusively investigated the impact of security mechanisms on requirements specifications. This paper extends and improves our initial proposal of the three-layer framework [42] and leverages the prototype tool [44] to perform a case study in order to evaluate the framework. In particular, the current work (1) revises the security requirements analysis process, describing each step in more detail; (2) defines a collection of formal inference rules to (semi-)automate the analysis process; (3) evaluates our framework over a number of research questions using

123

a large and realistic case study; and (4) includes in-depth discussions on the motivation, benefits, and potential of the framework. Two further papers [43,45] that deal with details of selecting and applying security patterns are not covered here. In the remainder of this paper, we first describe a smart grid scenario in Sect. 2, part of which is used to illustrate our approach throughout the paper. Next, we describe and explain existing techniques which are taken as the baseline of our framework in Sect. 3. Section 4 presents the threelayer security analysis framework, while Sect. 5 describes a set of security requirements analysis methods and a systematic analysis process for using these methods. In Sect. 6, we introduce a prototype tool which has been implemented to support our analysis. To evaluate our approach, in Sect. 7 we present the full smart grid scenario. We discuss the benefits and potential of our framework in Sect. 8 and compare our proposal with related work in the literature in Sect. 9. Finally, we conclude and discuss future work in Sect. 10.

2 Motivating scenario In this section, we introduce a smart grid real-time pricing scenario, where an energy supplier collects real-time energy consumption data and balance loads on the power grid. This is a typical scenario for a socio-technical system. Firstly, it includes a business process for price generation. Specifically, the energy supplier periodically collects load information for the power grid and sets appropriate energy prices accordingly in order to regulate the load of the power grid. Energy consumers adjust their energy usage based on real-time prices. Secondly, a number of applications are deployed to support the interactive process. In particular, a home energy management system is used by the energy consumer to communicate with the energy supplier and control the smart appliances in her apartment. Thirdly, physical devices (e.g., personal PC) are required to deploy the software applications, and the network needs to be appropriately configured to support communications. A schematic overview of the smart grid scenario is shown in Fig. 1, while detailed information of this scenario can be found in [10]. As our approach does require detailed information (Sect. 4.2), we also refer to other complementary sources of information (e.g., [52]). As this system involves a wide range of artifacts that vary from business processes to physical devices, it is difficult to carry out a thorough security analysis to protect the entire system. As reported by the National Vulnerability Database, on average, 15 new vulnerabilities of the Supervisory Control And Data Acquisition (SCADA, a system for remotely monitoring and controlling power grids) are publicly disclosed each day. Not surprisingly, the presence of these vulnerabilities leads to many attacks on smart grid systems [20]. As

Holistic security requirements analysis for socio-technical systems Customer Home Energy Supplier Servcer

Energy Generator

Home Energy Generator

Internet

Network Gateway

Home Gateway

Home Energy Consumption Application

Data Communication Network

Smart Meter

Smart Appliance

Fig. 1 An overview of the smart grid scenario [10]

such, our approach aims to provide a systematic and holistic way to analyze security requirements for all parts of the system. In this paper, a small piece of the scenario is used to illustrate our framework (in Sects. 4, 5), while the complete scenario is used for our case study (in Sect. 7).

World

Machine

R-requirement D-domain assumption

S-spec

Program, algorithm etc.

Fig. 2 An illustration of the requirements problem from [72]

3 Baseline In this section, we introduce existing work that is serving as the baseline for our research. We first introduce the requirements problem, which specifies fundamental tasks that need to be addressed during requirements analysis. Then, we describe several requirements modeling languages, intended to capture (security) requirements or tackle the requirements problem, offering modeling details for our holistic requirements framework. Finally, we introduce security patterns which are leveraged to operationalize security requirements. 3.1 Requirements problem Zave and Jackson [72] propose a Requirements Engineering (hereafter RE) ontology in order to define the requirements problem. Their definition consists of three concepts: A Requirement is an optative property that specifies stakeholder needs, expected to be satisfied by the system-to-be; a Domain Assumption is an indicative property that is relevant to the system-to-be; a Specification is an optative property, which can be directly implemented by the system-to-be in order to satisfy stakeholder needs. On the basis of these three concepts, the requirements problem amounts to finding a specification S, which can satisfy given requirements R under domain assumptions D. Thus, the requirements problem is represented as D, S  R, meaning that domain assumptions and specifications together entail the requirements.

As illustrated in Fig. 2, requirements are phenomena in the problem domain (aka world), and specifications offer a way for phenomena in the system-to-be to satisfy the requirements. Due to the complexity of STSs, the requirements problem needs to be extended to account for the conceptual layers used in our holistic framework (Sect. 4.1). 3.2 Goal-oriented requirements models Goal-Oriented Requirements Engineering has received much attention in RE research, as an intuitive means of capturing stakeholder goals and understanding underlying motivations for functional and non-functional requirements [34]. Goal-oriented requirements modeling languages have been proposed, offering modeling and analysis techniques that are adopted for our holistic security requirements analysis. Firstly, many such languages, including i* [70], Tropos [5], and all their variations, provide the concepts of means-ends/and-refinement/or-refinement to capture alternative ways of satisfying stakeholder goals. Once a model has been created, many satisfaction analysis techniques can be used to select the best alternative for fulfilling root level goals [35]. In particular, softgoals and contributions links play an important role during the decision-making process. Secondly, Techne [38], a recently proposed requirements modeling language, maps Zave and Jackson concepts

123

T. Li et al.

into corresponding goal model concepts. In addition, it extends the requirements problem with priorities among stakeholder requirements, improving selections among alternative requirements specifications [30]. Thirdly, security requirements analysis has been addressed by a number of proposals, which incorporate security-related concepts. In particular, Chung adopts the NFR framework to analyze security requirements, which are represented as security goals and are specified in terms of sort and parameter [8]. In this work, we base our three-layer models on a combination of these approaches in order to model both functional and non-functional requirements (including security ones), as well as social interactions. In particular, we borrow the following concepts and relations from i* and Techne: actor, goal, softgoal, task, resource, domain assumption, refinement relation, dependency relation, and contribution relation. A goal is a state of affairs that is desired by an actor and has clear-cut criteria of achievement; a softgoal is similar to a goal but does not have clear-cut criteria for its satisfaction. A task represents an action that is executed by an actor in order for achieving some goal. A resource is an entity (either physical or informational) that is required by an actor in order to perform a task. A domain assumption states an indicative property of a domain. A refinement relation is a generic relationship, which represents the hierarchical structure of requirements elements (e.g., goals and tasks). In particular, there are two types of refinement: (or-)refine and and-refine. For the first type, the fulfillment of at lease one child node can satisfy the parent node, while for the second type, the fulfillment of all child nodes is required to satisfy the parent node. A dependency relation represents a social relationship between two actors, i.e., a depender depends on a dependee upon a dependum. A contribution relation represents an effect of a goal/task on a softgoal, assisting analysts in the decisionmaking process among alternative goals and tasks. In the next section, we describe in detail how we combine these concepts and relations in our framework.

3.3 Security patterns Security patterns consist of pairs that capture a particular way of solving a security problem. They constitute an effective way to encapsulate security knowledge for analysts with little security expertise. Various security patterns have been proposed at different abstraction levels. For example, Yodar, and Barcalow describe seven architectural patterns to address application security [69]. Fernandez et al. have invented the secure three-tier pattern [17], the physical access control pattern [16], and the web service security patterns [15]. In addition to individual patterns, a number of repositories have been established to collect patterns from

123

the literature, such as the work done by Scandariato et al. [59], Hafiz et al. [23], Asnar et al. [3], and Fernandez [18]. In this paper, we make use of security patterns to operationalize security goals in terms of security mechanisms within each of the three layers. Different knowledge sources are used to cover security concerns in different layers. In particular, we leverage organizational security patterns [3], software security patterns [59], and physical security patterns [16] for the three layers, respectively. As there are only a few physical security patterns, we also exploit security knowledge from ISO 27002 [36] as a complement.

4 Three-layer security analysis framework In this section, we propose a three-layer security analysis framework to deal with security issues for STSs in a holistic way. Specifically, we first explain why we choose to structure an STS into three layers, specify how we do so, and then describe concepts of the three-layer framework in detail. 4.1 Three-layer structure When dealing with STSs, compared to traditional software systems, there is a plethora of artifacts that need to be accounted for in order to make the entire system work effectively. In particular, we focus on three important aspects of STSs which have received much attention from the security community, and structure them into three layers. At the most abstract level, we consider a social layer conceptualized in terms of social actors, social dependencies, and business processes. At the next layer, we consider software applications that support the social layer, conceptualized in terms of architectural components. Finally, we consider an infrastructure layer that focuses on the technical and physical infrastructure that supports deployment of software applications and business processes. We argue that each layer involves different phenomena and calls for different solutions to deal with security requirements for STSs. Thus, each layer has its own requirements, which are satisfied by layer-specific specifications under corresponding domain assumptions. In order to formulate the requirements problem for STSs, we extend the original requirements problem (Fig. 2) to deal with the requirements problem of each layer, respectively (as shown in Fig. 3). In particular, the Machine in the original requirements problem has been generalized into Artifacts. Each of these Artifacts is designed by layer-specific phenomena and satisfies corresponding requirements under specific domain assumptions in the World. For example, social-layer requirements (Rs ) are satisfied by business process specifications (Ss ) under sociallayer domain assumptions (Ds ), i.e., Ss , Ds  Rs , and other layers have their own requirements problem, likewise.

Holistic security requirements analysis for socio-technical systems

World

Artifacts

Rs

Ss

Business Process

Sa

Software Application

Ds Ra Da Ri Di

Si Infrastructure

Fig. 3 The requirements problem extended for STSs

Stakeholder's high-level security needs Social Goal Model [Ds, Ss Rs]

Social layer security analysis Security-Enhanced Social Goal Model

Software Goal Model [Da, Sa Ra]

Software layer security analysis Security-Enhanced Software Goal Model

Infrastructure Goal Model [Di, Si Ri]

Infrastructure layer security analysis

Holistic security solutions Fig. 4 An overview of the three-layer analysis framework

Given the three-layer structure, the specifications of one layer determine the requirements of lower layers. In particular, as shown in Fig. 3, social-layer specifications (Ss ) determine the requirements of software applications (Ra ), while application specifications (Sa ) affect the requirements of the infrastructure (Ri ). The semantics of these dependencies is that achievement of the specification in one layer requires the satisfaction of requirements in its lower layer. These dependencies are captured in our three-layer models. Through them, we can connect security requirements across layers and analyze them from a holistic viewpoint. We base our security analysis on the proposed three-layer architecture. As shown in Fig. 4, our framework starts with stakeholder security requirements and analyzes them across layers with regard to layer-specific goals and specifications, resulting in a set of holistic security solutions encompassing all three layers.

4.2 A three-layer model for STSs In this section, we present models for capturing requirements and specifications across three layers. Our framework extends existing approaches with additional concepts and relationships. Figure 5 shows an overview of our proposed metamodel for the three-layer requirements framework, where the newly introduced concepts are highlighted with dashed rectangles. Note that definitions of existing concepts are aligned with corresponding modeling languages (i.e., i* and Techne), as presented in Sect. 3.2, while each of the new concepts will be defined and explained in detail below. Figure 6 presents an excerpt of the three-layer requirements model of the smart grid scenario, showing how requirements of STSs are structured and modeled in three layers, which will be used for illustrating relevant concepts. Note that we do not capture non-security-related softgoals and contribution links in either the illustrating example or the later case study, as we here exclusively focus on analyzing security requirements and deriving alternative security specifications from a holistic viewpoint. Our approach could be easily extended to capture non-security-related requirements trade-offs with these concepts. 4.2.1 Extended requirement concepts As we build goal models for different layers capturing different concerns, we specialize Goal into layer-specific goals that focus on a particular aspect of stakeholder needs. Specifically, in the social layer, Business Goals represent a stakeholder’s high-level requirements for his business. For example, the energy supplier has a business goal about applying real-time pricing strategy to regulate loads on the power grid (i.e., BG1 in Fig. 6). Software Goals represent stakeholder requirements for software applications that support corresponding business activities. For example, the energy control application needs to include functions to support price calculation (i.e., AG1 in Fig. 6). Likewise, Infrastructure Goals represent stakeholder requirements on technical and physical infrastructure that supports the execution of software applications. For example, the energy supplier server needs to set up a channel to enable communications between the energy control application and the smart meter firmware (i.e., IG2 in Fig. 6). Accordingly, we assign Tasks at different layers with specific operational definitions reflecting the layer. In particular, a task amounts to a Business Activity in the social layer, while in the software layer it is a Software Function, and in the infrastructure layer it is a Deployment setting. For example, in the social layer, to satisfy the business goal BG1, a collection of business activities (i.e., BT1-3) should be performed, which are captured as tasks in this layer. Note that when identifying and modeling tasks in the social layer,

123

T. Li et al. Fig. 5 Meta-model of the three-layer security requirements framework (new concepts in dashed rectangles)

Legend

Extended Concept

Imported Concept

Business Goal Software Goal Infrastructure Goal

depend

Actor

has

Requirement Element Goal operationalize support

Business Activity Software Function Infrastructure Deployment

analysts should only focus on layer-specific phenomena, while ignoring lower-layer concerns. In this example, analysts only consider what business activities are required to achieve the business goal, regardless of whether and how software applications are used within the activities. The benefits of assigning the operational definitions to tasks at different layers are as follows: Firstly, the operational definitions can help analysts to distinguish tasks among layers. Secondly, such operational definitions also help us to determine the granularity of the tasks that we need to model in each layer, i.e., knowing when we should stop refining tasks and finish modeling in a particular layer. Thirdly, tasks with operational definitions can be connected to concepts within additional design models, such as the tasks of the social layer correspond to the business process activities of BPMN (Business Process Modeling Notation). As such, the layerspecific goal models can be transformed into corresponding design models by using available techniques, facilitating system development in later lifecycle stages. For example, Halleux et al. propose an approach to derive business process models from goal models [25], while Pimentel et al. [54] propose an approach to transform a goal model into a software architecture model. Specifically, a roadmap of goal model transformation techniques has been summarized by Horkoff et al. [31,32], in which they have surveyed 243 publications that map/integrate/transform goal models to later stage software artifacts. Apart from the above concepts, two relations are also included in the proposed framework. Operationalize relates a goal to a task that operationalizes it within the same layer. For example, in Fig. 6, business goal Customer is notified about the price (BG5) is operationalized by business activity

123

Task Security Mechanism

Resource

Domain Assumption contribute

operationalize

Softgoal Security Goal

Energy Supplier sends price to customer (BT3). Support is a cross-layer relation, which indicates that a goal in one layer supports a task one layer higher. Thus, the completion of the task requires the satisfaction of the goal. When determining whether or not a task requires support from the next layer down, analysts should take into account the layer-specific operational definition of the task. In particular, as a task is a business activity in the social layer, analysts should determine whether or not the execution of the activity requires any software applications. If so, a support link should be added to capture such relation. For example, in Fig. 6, as Energy Supplier intends to send price data to the customer using the application ESSA, the requirements goal AG5: Price can be sent to customer is introduced to the application layer which supports this business activity (i.e., BT3). Thus, the application ESSA will refine the goal into more detailed tasks and goals within the application layer. Moreover, in the application layer, since a task is an application function, by default all such tasks require support from the physical hardware that deploys the software application. As shown in Fig. 6, to deal with the modeling scalability problem, instead of modeling the support link for each task in the application layer from the infrastructure layer, we graphically model the support link from the lower-layer goal IG1 to the application agent ESSA. Semantically, that support link indicates that all the tasks of the application ESSA are supported by the goal IG1. In addition to this default support link, for each application task (within or out of the ESSA actor), analysts also need to identify whether the task requires additional support from the infrastructure layer. For instance, the application task AT5: Receive and store energy consumption data from SMF requires the Energy Supplier Server to be

Holistic security requirements analysis for socio-technical systems

Social Layer

SG1

Resource

BT1 Calculate price

D Dependency

the price

BT2 Receive energy consumption data from SM

D

Energy consumption data

BT3 ES sends price to customer

BT4 Measure energy consumption

D D

operationalize

Historical price data

AT3 Communicate with SMF

AG3 New price is generated

D

Send price info to HEMS

AT5 Receive energy consumption data from SMF AT4

D

IT4 Connect ESS to DCN

Data Communic ation Network (DCN)

IG1 Support ESSA

IT1 Deploy ESSA to ESS

AT7 Send energy consumption data to ESSA D

Send AT8 measurement requests to SMF

D

Smart Meter Device (SMD) Support IG2 communication between ECA and SMF

IG3 Connection between ESS and SMD is established

PT2 Connect ESS to DCN

IG4 Support communication between ECA and HEMS

IT7 Connect PC to HAN

IG5 Connection between ESS and PC is established

Home Area Network (HAN)

PT3 Connect ESS to Internet

D

D

Energy Supplier Server (ESS)

Energy consumption data

AT6

Send measurement requests to SMF

Infrastructure Layer

Smart Meter Firmware (SMF)

D

AT1 Retrieve data from AT2 Database Generate price

Energy Supplier Database (ESD)

AG5 Price can be sent to customer

D

AG2 Historical price is obtained

D

AG4 Be able to communicate with SM

D

AG1 Support calculate price

D

Energy Supplier Server Application (ESSA)

Application Layer

D

support

BG5 Customer is

BG4 Load info is available

BG3 New price is available

(S) Security Goal

Smart Meter (SM)

D

Goal

Real-time BG2 price is obtained

Task

(S) High Integrity [energy consumption data, interval(BG1)]

D

Energy Supplier (ES)

legend

Actor

Real-time BG1 pricing is applied

D

IT5 Connect HG to DCN

D

Home Gateway (HG)

D

IT6 Connect HG to HAN

Fig. 6 An excerpt of the three-layer requirements model of the smart grid scenario

123

T. Li et al.

connected with SMF; otherwise, this function cannot be correctly executed. This is captured in Fig. 6 via the support link from IG3 to AT5.

Security ISA ISA

ISA

Availability Integrity

4.2.2 Extended security requirement concepts Chung [8] leverages analysis of non-functional requirements to deal with security requirements, which are represented as security goals. Each security goal consists of one sort and one or more parameters. In our framework, we further extend security goals to express more detailed and specific security requirements, and introduce security mechanisms which represent security solutions. A Security Goal represents stakeholder security needs with regard to an asset and time interval. We define a security goal as a specialization of softgoal that focuses on security concerns. Since security requirements notoriously interact with system functional requirements, we denote security goals with a graphical separation from their functional counterparts, as shown in Fig. 6. However, security goals are semantically connected with the goals/tasks via an Interval attribute (explained below). Each security goal is represented by a template: [, ]. Taking security goal SG1 as an example (Fig. 6), High Integrity [energy consumption data, interval(BG1)] represents the security requirement “protecting integrity of energy consumption data during the execution interval of BG1 to a high degree.” More specifically: – The Security Property specifies a characteristic of security. In this paper, we exclusively focus on confidentiality, integrity, and availability, which are the three main dimensions of information security [37]. In addition, we detail sub-properties of these three security properties based on the taxonomy defined by Firesmith [19], as shown in Fig. 7. For example, under the security property integrity, there are four sub-properties data integrity, service integrity, application integrity and hardware integrity. Note that the security properties we consider in our work constitute a starting point that can be extended in the future. – The Asset is anything that has value to an organization, such as data or services. Figure 8 shows an overview of types of assets accommodated by our framework, as well as the interrelationships among them. In particular, we consider services as assets at the social layer; applications that execute services are considered as assets in the software layer; in the infrastructure layer, we analyze hardware as an asset which deploys applications. Moreover, data is an asset that is considered in all three layers. – The Interval of a security goal indicates the time period when the security goal applies. Haley et al. [24] have

123

ISA

ISA ISA

Application Integrity

ISA ISA

Data

ISA ISA

ISA

Data Integrity

ISA

Data Availability

Hardware Availability

Service Availability

Service Integrity

Application Availability

Hardware Integrity

Fig. 7 Hierarchy of security properties Social Layer

Service

involve

Data

execute

Software Layer

Application

process

Data

deploy

Infrastructure Layer

Hardware

store

Data

Fig. 8 Overview of assets

pointed out that “Threats can have a ‘time’ element, stating that the harm will occur only if the violation occurs before or after some point, or within some interval.” We agree that the time dimension does affect system security requirements analysis. In particular, we specify an interval in terms of the execution period of a task, i.e., interval(task). Note that a goal can also be used to represent an interval, which is the execution period of all tasks that operationalize this goal. In this way, the security goals are implicitly connected with the system functional requirements. For example, the security goal SG1 in Fig. 6 is concerned during interval(BG1), and thus there is an implicit connection between SG1 and BG1. Such implicit connections are managed by our prototype tool (Sect. 6) and are taken into account during our security analysis. – The Importance of a security goal indicates the priority of a security goal. Possible values include {very low, low, medium, high, very high}. A Security Mechanism is a method that operationalizes a security goal. We define the security mechanism as a specialization of task. The operationalization relation between security mechanisms and security goals is a many-to-many relation, i.e., one security mechanism can satisfy multiple security goals, and one security goal may require more than one security mechanisms. More details will be introduced in Sect. 5.3. In our framework, security mechanisms are also applied in different layers and become part of the specification of the corresponding layer. It is worth noting that, in

Holistic security requirements analysis for socio-technical systems

Single-Layer Security Analysis Three-layer requirements models

Detailed security goals

security goals (Sect.5.1)

Reference models

User Task Simplify security goals (Sect.5.2)

Computeraided Task Critical security goals

Security patterns

Legend

Operationalize security goals (Sect.5.3)

Data Object

Sequence Flow Data Flow

Transfer security concerns across layers (Sect.5.4)

Obtain global security solutions (Sect.5.5)

Fig. 9 An overview of the three-layer security requirements analysis process

this paper, we do not determine what is or is not a mechanism, but take it from established sources, i.e., the solutions offered by existing security patterns [3,59]. In particular, the layer-specific security mechanisms correspond to layerspecific security patterns, which will be detailed in Sect. 5.3. For example, Auditing is a security mechanism which can be applied in the social layer to ensure the integrity of a business activity [3], while Input Guard is a software-specific security mechanism, which checks all inputs of a software application [59]. As such, a security mechanism may also impose corresponding requirements at a lower layer. For a formal treatment of the application of mechanisms, see our companion paper [45].

sible operationalizations in terms of security mechanisms. Cross-layer analysis aims to propagate the security concerns from one layer to the next layer down. After security analysis has been performed for all layers, a collection of alternative security solutions are produced, which cover holistic security concerns across three layers. A set of inference rules is proposed to support the security analysis, which have been implemented in Disjunctive Datalog [13]. A prototype tool has been developed to semiautomate the inference tasks. As indicated in Fig. 9, analysis tasks which are annotated with only a gear icon can be fully automated, while the ones that are annotated with both human and gear icons can be performed semiautomatically.

5.1 Refinement methods

5 Security requirements analysis methods In this section, we propose a systematic process and a set of security requirements analysis methods to guide security analysis both within one and across layers. Figure 9 shows an overview of the analysis process, which starts from security requirements analysis at the social layer and follows to analyze security requirements at the software layer and the infrastructure layer, respectively. Specifically, within each layer, we refine and concretize security goals to identify pos-

Having stakeholder’s initial security needs as input, analysts should iteratively refine them into more concrete counterparts in order to capture the exact needs of stakeholders and eventually operationalize such needs. Our framework supports three refinement methods that respectively operate on the three attributes of security goals (i.e., security property, asset, and interval). These refinement methods have been formalized in terms of inference rules in order for semiautomation, which are shown in Table 1. In particular, the

123

T. Li et al. Table 1 Inference rules for refinement methods

No.

Content

REF.P

#cr eate(sec_goal(SG2)) ∧ sg_attributes(SG2, IMP, SP2, AS, INT) ∧ and_r e f ine(SG2, SG1) ← is_a(SP2, SP1) ∧ sg_attributes(SG1, IMP, SP1, AS, INT)

REF.A #cr eate(sec_goal(SG2)) ∧ sg_attributes(SG2, IMP, SP, AS2, INT) ∧ and_r e f ine(SG2, SG1) ← par t_o f (AS2, AS1) ∧ sg_attributes(SG1, IMP, SP, AS1, INT) REF.I.1 #cr eate(sec_goal(SG2)) ∧ sg_attributes(SG2, IMP, SP, AS, INT2) ∧ and_r e f ine(SG2, SG1) ← inter val_o f (INT1, G1) ∧ inter val_o f (INT2, G2) ∧ and_r e f ine(G2, G1) ∧ sg_attributes(SG1, IMP, SP, AS, INT1) REF.I.2 #cr eate(sec_goal(SG2)) ∧ sg_attributes(SG2, IMP, SP, AS, INT2) ∧ r e f ine(SG2, SG1) ← inter val_o f (INT1, G1) ∧ inter val_o f (INT2, G2) ∧ r e f ine(G2, G1) ∧ sg_attributes(SG1, IMP, SP, AS, INT1) REF.I.3 #cr eate(sec_goal(SG2)) ∧ sg_attributes(SG2, IMP, SP, AS, INT2) ∧ r e f ine(SG2, SG1) ← inter val_o f (INT1, G) ∧ inter val_o f (INT2, T ) ∧ operationali ze(T, G) ∧ sg_attributes(SG1, IMP, SP, AS, INT1)

predicate has_attributes describes the four attributes of a security goal SG, i.e., importance IMP, security property SP, asset AS and interval INT; the predicate is_a describes the specialization relation between two security properties; the predicate par t_o f describes the part-of relation between two assets; the predicate and_r e f ine, r e f ine, operationali ze describe relations between requirements elements (goals G and tasks T ). Figure 10 presents a series of examples of security goal refinements based on security goal High Integrity [energy consumption data, interval(BG1)] (Fig. 6), involving all three refinement methods. The type of each refinement is explicitly annotated in the figure, and the reference models that are used for corresponding refinements are presented in the left part of the figure. Using this example, we explain the three refinements methods and their corresponding inference rules (Table 1) in detail below.

Refinements of security goals can also be done by refining assets according to their corresponding part-of relations. Thus, a security goal can be and-refined to sub-security goals, each of which concerns part of the asset of the original security goal and remains other attributes unchanged (i.e., rule REF.A). Note that the part-of here stands for an abstract relation, which can apply to various objects, such as data schema, software architecture, etc. As shown in Fig. 10, security goal SG3 that concerns asset Energy consumption data is refined by applying the rule REF.A based on the part-of relations (shown in the reference model Fig. 10b). Thus, the derived security goals SG6, SG7 concern assets Water consumption data and Electricity consumption data, respectively.

5.1.1 Security property-based refinement

5.1.3 Interval-based refinement

Refining security goals via security properties helps the security analysis to cover all possible aspects of security. The rule REF.P means: If the security property SP2 is a specialization of the security property SP1 (according to the hierarchy of security properties shown in Fig. 7), then the security goal SG1 that concerns the security property SP1 will be andrefined into a sub-security goal SG2, which concerns SP2 and inherits all other attributes from SG1. For example, in Fig. 10, security goal SG1 that concerns security property Integrity is refined into four sub-security goals by applying rule REF.P. In particular, in accordance with the reference model Fig. 10a, the derived security goals SG2, SG3, SG4, SG5 concern security properties Application Integrity, Data Integrity, Service Integrity, Hardware Integrity, respectively.

Since an interval specifies the temporal period for which a security goal is concerned, a security analyst can put more detailed constraints on a particular time interval by refining a long interval into short ones. As we use the execution period of requirement goals/tasks to specify intervals, the intervalbased security goal refinements are carried out based on the structure of the system requirements model. Specifically, the rules REF.I.1 and REF.I.2 say if interval INT1 of security goal SG1 can be (and-)refined into INT2, then we can obtain a new security goal SG2 which (and-)refines SG1 via its interval; rule REF.I.3 has similar meaning but focuses on the operationalization relation. As shown in Fig. 10, the security goals SG6 and SG7 have been and-refined via the interval attribute according to the reference model (Fig. 10c).

123

5.1.2 Asset-based refinement

Holistic security requirements analysis for socio-technical systems SG1

(S) High Integrity [energy consumption data, interval(BG1)]

Reference Models Integrity ISA

Application Integrity

ISA

Hardware Integrity

ISA ISA

Service Integrity

Data Integrity

SG2 (S) High Application Integrity [energy consumption data, interval(BG1)]

Energy consumption data

Interval-based SG8

(S) High Data Integrity [water consumption data, interval(BG2)]

Real-time pricing is applied

BG2 Real-time price is obtained BG3 New price is available

Asset-based (S) High Data Integrity [water consumption data, interval(BG1)]

Electricity consumption data

(b) BG1

SG4 (S) High Service Integrity [energy consumption data, interval(BG1)]

SG6

part-of

Water consumption data

SG5 (S) High Hardware Integrity [energy consumption data, interval(BG1)]

SG3

(S) High Data Integrity [energy consumption data, interval(BG1)]

(a)

part-of

Property-based

BG5 Customer is

SG9 (S) High Data Integrity [water consumption data, interval(BG5)]

Interval-based SG12

BG4

the price

Load info is available

SG11

(S) High Data Integrity [water consumption data, interval(BG3)]

(c)

SG7 (S) High Data Integrity [electricity consumption data, interval(BG1)]

(S) High Data Integrity [water consumption data, interval(BG4)] SG13

Interval-based SG10

SG10 (S) High Data Integrity [electricity consumption data, interval(BG2)]

(S) High Data Integrity [electricity consumption data, interval(BG5)]

Interval-based

(S) High Data Integrity [water consumption data, interval(BG3)]

SG14 (S) High Data Integrity [water consumption data, interval(BG4)]

Fig. 10 Security goal refinements

5.1.4 Refinement strategies Note that a refinement process can be flexible in the sense that different refinement methods can be applied in any sequence and to any extent. For example, Fig. 10 represents only one particular way of refining the root security goal SG1, which first performs property-based refinement, and then performs asset-based refinement, and finally performs interval-based refinement. Apart from this particular way of refinement, there are many other ways for refining the same security goal, and it is upon analysts to determine the way of refinement. In order to make the refinement analysis systematic, we need specific refinement strategies for determining how to proceed the refinement analysis. In particular, we propose two strategies for refining security goals. Firstly, a selective refinement strategy: Given a to-be-refined security goal, analysts determine a particular dimension for refining a security goal based on his expertise. After performing such a refinement, analysts should check with stakeholders whether all the refined security goals are needed. If a refined security goal is not required by stakehold-

ers, analysts must exclude it from subsequent refinement. In such a way, analysts are able to capture stakeholders’ precise security needs which normally cannot be easily expressed during the initial stages of security analysis. Pruning uninteresting goals allows analysts to reduce the refinement space. With the support of our prototype tool, once analysts choose a refinement dimension for a selected security goal, the tool can automatically perform the refinement analysis and graphically create sub-security goals. For example, the security goal model, shown on the right side of Fig. 10, is derived from a selective refinement analysis, representing one possible way to refine the root security goal SG1. Secondly, analysts can choose an exhaustive refinement strategy, which is intended to explore all the possible refinements of one security goal. In this case, no refinement dimensions are pruned by the user. Such refinement can also be automated by using the prototype tool. For example, considering the same root security goal SG1 and corresponding reference models in Fig. 10, we have created an exhaustive refinement model to show all the possible refinement paths, which contains 117 security goals and 264 refinement

123

T. Li et al. Table 2 Inference rules of applicability analysis

No.

Content

APP.1

is_applicable(SG) ← (sg_attributes(SG, _, data_con f identialit y, AS, INT) ∨sg_attributes(SG, _, data_integrit y, AS, INT) ∨sg_attributes(SG, _, data_availabilit y, AS, INT)) ∧ inter val_o f (INT, T ) ∧ data(AS) ∧ (has_input (T, AS) ∨ has_out put (T, AS))

APP.2

is_applicable(SG) ← ser vice(AS) ∧ (sg_attributes(SG, _, ser vice_integrit y, AS, _) ∨ sg_attributes(SG, _, ser vice_availabilit y, AS, _))

APP.3

is_applicable(SG) ← application(AS) ∧ (sg_attributes(SG, _, application_integrit y, AS, _) ∨ sg_attributes(SG, _, application_availabilit y, AS, _))

APP.4

is_applicable(SG) ← har dwar e(AS) ∧ (sg_attributes(SG, _, har dwar e_integrit y, AS, _) ∨ sg_attributes(SG, _, har dwar e_availabilit y, AS, _))

links in total.1 This strategy contributes to the completeness of analysis, but the exhaustive refinement may result in many redundant security goals and complicate the subsequent analysis. Some form of pruning is necessary to manage such complexity. Based on the advantages and disadvantages of these two strategies, we propose to adopt a hybrid strategy to refine security goals. In particular, analysts should first apply the selective strategy to identify stakeholders’ precise security needs. Based on such precise security needs, analysts can then apply the exhaustive refinement strategy to explore the refinement space of the security needs. In Sect. 7, we will further report our experience of using such a hybrid strategy. 5.2 Simplification methods Once security goals have been refined to more precise goals, either selectively or exhaustively, we introduce additional methods to help prune the space of security goals under consideration. It is worth noting that the pruning analysis mentioned in the refinement analysis concerns whether or not a security goal is desired by stakeholders, while here we focus on analyzing the criticality of desired security goals. Specifically, we perform applicability analysis and threat analysis to identify critical security goals that need to be further treated, allowing us to exclude others. 5.2.1 Applicability analysis By saying that a security goal is applicable, we mean it is sensible with regard to the meaning of its attributes (security property, asset, etc.); otherwise, it is inapplicable. To determine the applicability of security goals, firstly, we consider 1

A full version, http://disi.unitn.it/~li/SoSyM/exhaustive_refine.pdf.

123

whether the security property is applicable to the type of asset. For example, the security property Hardware Integrity is only concerned with hardware asset. If a security goal aims to protect the Hardware Integrity of a Data asset, then it is inapplicable. Secondly, we check the data-related security property (e.g, Data Integrity) based on the involvement of the data during the target interval. For example, if a security goal concerns the Data Integrity of a data asset during a specific time interval, but the data are not actually involved in that time interval, then the security goal is inapplicable. To accommodate this analysis, we specify data flow information for each task, i.e., the input and output of each task. On the basis of the above rationales, we have proposed five inference rules to facilitate the applicability analysis, which are shown in Table 2. Take rule APP.1 as an example: Given a security goal SG, which considers data-related security properties for an asset AS during the execution interval of a task T, if the asset is a data asset and it is an input/output of the task T, then this security goal is determined as applicable. According to these rules, in Fig. 10, security goal High Data Integrity [water consumption data, new price is available (BG3)] is inapplicable, because the asset water consumption data is not involved in the execution period of BG3. The applicability analysis is fully automated according to the inference rules. As the rules are defined based on semantics of the attributes of security goals, the “precision” of this applicability analysis is 100 %, i.e., if our analysis classifies a security goal as applicable, then goal is indeed applicable. For the “recall” of the applicability analysis, i.e., whether all applicable goals have been identified, we assume it is 100 % based on the case study we have carried out thus far, in which we have not noticed any corner cases yet.

Holistic security requirements analysis for socio-technical systems Table 3 Inference rules of threat analysis

No.

Content

T H.1

threaten(T H, SG) ← sg_attributes(SG, _, SP, AS, INT) ∧ is_a(SP, con f identialit y)

T H.2

threaten(T H, SG) ← sg_attributes(SG, _, SP, AS, INT) ∧ is_a(SP, integrit y)

T H.3

threaten(T H, SG) ← sg_attributes(SG, _, SP, AS, INT) ∧ is_a(SP, availabilit y)

∧ th_attributes(T H, in f ormation_disclosur e, AS, INT) ∧ th_attributes(T H, tampering, AS, INT) ∧ th_attributes(T H, denial_o f _ser vice, AS, INT)

5.2.2 Threat analysis For each applicable security goal, we identify threats that impair the satisfaction of the goal, which helps us to determine its criticality. To this end, we need to either incorporate existing threat analysis approaches (e.g., [4,62]) or import threat knowledge about the target system from existing reports, if available. Each identified threat is specified with its name, type, threatened asset and threatened interval, based on which we can automatically identify security goals that are threatened by the threat. Note that we specify the threat type using the STRIDE threat categories, as each of these categories can be matched to a particular type of security property [27], e.g., the threat type Tampering is mapped to the security property Integrity. We have defined a series of rules T H.1-3 (Table 3) to automate such threat analysis. For example, as specified in T H.1, if a security goal SG concerns a security property SP which is a type of con f identialit y, and there is a threat T H that belongs to the type of in f ormation_disclosur e and targets the same asset AS and interval INT of SG, then we identify that T H threatens SG. The threat analysis is automated by our prototype tool. 5.2.3 Criticality analysis Based on the results of applicability analysis and the threat analysis, we determine whether or not a security goal is critical: (1) if a security goal is applicable and is threatened by certain threats, then it is a critical security goal; (2) if a security goal is applicable but has not been associated with any threats, then the analyst needs to manually determine the criticality of the security goal. Note that in the second case, for analysts with little security knowledge, a conservative solution is to treat all applicable security goals as critical, which ensures the completeness of the analysis but will increase the complexity of subsequent analysis. We will further discuss this trade-off based on our case study in Sect. 7. 5.2.4 Refinement and simplification combined As with two strategies for security goal refinements, the simplification analysis can also be applied in two ways. Firstly, analysts can apply the simplification analysis together with

the selective security goal refinements, which helps to determine whether or not a security goal needs to be further refined. In particular, if a refined security goal is not applicable, then it will be excluded from subsequent refinements. Moreover, if a refined security goal is identified as critical, then it does not need to be further refined and will be analyzed for operationalization in the next step of analysis. For a refined security goal which is applicable but not critical, analysts can keep refining it and further evaluate its refinements; if this goal cannot be refined anymore, then analysts have to manually determine whether it is critical. Secondly, analysts can apply the simplification analysis to all the exhaustively refined security goals with the help of the prototype tool. For example, by applying the simplification analysis to the the aforementioned exhaustively refined security goal model, which contains 117 security goals and 264 refinement links, we identify two critical security goals (i.e., both applicable and threatened) and seven applicable security goals (that have not been threatened). Although this analysis helps to quickly identify critical security goals, the analysts need to manually evaluate all other applicable security goals in order to determine their criticality, which is a non-trivial task. Since we have proposed to adopt a hybrid refinement strategy, the simplification analysis should be performed accordingly. We will further demonstrate and discuss the application of the simplification analysis based on practical evidence we have gained from the case study (Sect. 7). 5.3 Operationalization methods For each identified critical security goal, we propose operationalization methods to generate possible security mechanisms that can satisfy the critical security goal. In particular, we leverage existing security patterns to help analysts with few security knowledge to operationalize security goals. Security patterns describe provable security solutions to known security problem under particular context. The security patterns that are used by our approach are taken from existing pattern repositories [3,16,59], each of which fits a particular layer in our framework. Figure 11 shows the catalog of security patterns we used in three layers, as well as

123

T. Li et al. Service Availability

Service Integrity

Data Availability

Data

Data Integrity

Social Layer Alternative service

Client Checking

Application Integrity

Software Layer Input Guard

Application Availability

Hardware Integrity

Equipment siting and protection

Supervision Relation

authority

Data Availability

Replicated System

Load Balancer

Hardware Availability

Full View with Errors

Data Availability

Supporting Utility

Access Control

Data

Limited View

Firewall

Server sandbox

Infrastructure Layer

Separation of Duty

Data Integrity

Secure Access Layer

Data

Physical Entry Control

Auditing

Storage Encryption Secure Pipe

Data Integrity

Legend Security Property Security Pattern

Cabling security

Protect

Fig. 11 The employed catalog of security patterns in three layers Fig. 12 An example of the operationalization of critical security goals (red crosses indicate the corresponding security patterns are inapplicable) (color figure online)

SG1

(S) High Integrity [energy consumption data, interval(Realtime pricing is applied)]

SG3

SG2

(S) high data integrity [energy consumption data, interval(sends energy consumption data to es)]

(S) high data integrity [energy consumption data, interval(measure energy consumption)]

(S) Auditing

the corresponding security properties achieved by those patterns. As indicated by Fig. 11, one pattern can be applied to multiple security goals and one security goal can have multiple patterns. In total, we include 21 security patterns in our framework thus far, where 7 patterns are at the social layer, 10 patterns are at the software layer, and 4 patterns are at the infrastructure layer. Note that the current catalog of security patterns is not intended to be exhaustive and can evolve and

123

(S) Access Control

X

(S) Auditing

X

(S) Access Control

X

expand over time. We will further discuss this issue in the discussion section. To operationalize a security goal, we first identify all candidate security patterns based on the protection security property of the pattern. For example, as shown in Fig. 12, two critical security goals SG2 and SG3 concern security property data integrity, according to which two candidate security patterns are identified for each security goal (refer

Holistic security requirements analysis for socio-technical systems Fig. 13 Security mechanisms cross-layer analysis

Legend SG1 (S) High Data Integrity [Energy consumption data, Measure energy consumption]

Business Layer

Application Layer

SM1 (S) Auditing

Auditing Application G1 Measurement is audited

to Fig. 11). This analysis can be automated by our prototype tool. Having the candidate security patterns, analysts then need to manually check the applicability of such patterns. In particular, the analysts should check the target system and environment against the context and forces of the candidate patterns and then determine which pattern to apply. In our example (Fig. 12), we have determined that Auditing is applicable to achieve security goal SG2, while others are inapplicable (indicated by red crosses). Note that if a security goal cannot be operationalized in one layer using layer-specific security patterns, there may be two possible reasons. Firstly, potential threats to the security goal may not exist in the current layer, and thus the security goal needs to be further elaborated and analyzed in lower layers, which will be shown in the next subsection. Secondly, the catalog of security patterns (shown in Fig. 11) may not be sufficient to satisfy the security goal, raising the need for expansion of the catalog. More detailed discussion about this issue will be presented in Sect. 8. 5.4 Cross-layer analysis methods After finishing the security analysis within one layer, we switch the focus of our security analysis to the next layer down, i.e., generating a set of security goals at the next layer based on the analysis results of this layer. Then, a new round of security analysis will be performed for the next layer using the newly available information there, as indicated in Fig. 9. In particular, the cross-layer analysis focuses on analyzing the influences of applied security mechanisms and critical security goals in one layer.

(S) Critical security goal Goal

(S) Security goal (S) Security Mechanism

operationalize support

and-support

SG2 (S) High Security [Auditing application, interval(G1)]

5.4.1 Influences of applied security mechanism When a security goal has been operationalized into a specific security mechanism in one layer, the analyst first needs to manually check whether this security mechanism needs support from the lower-layer artifacts based on the specification of the security mechanism. If so, the security mechanism, as a specialization of Task, will introduce a functional requirement in the next layer down. Such support analysis is performed based on the instructions we have described in Sect. 4.2.1. As shown in the left part of Fig. 13, in the illustrating example, the applied security mechanism Auditing is determined to be implemented by an Auditing Application in the software layer. Thus, a new software goal Measurement is audited (G1) is introduced to the application correspondingly. When it comes to cross-layer analysis, a security mechanism is different from a general task for its satisfaction, it requires not only functional support but also security support from the next layer down. Otherwise, the security mechanism can be impaired and thus fails to protect the system. As such, given the functional support we have identified above, our analysis will also cover security support, introducing a security goal to protect corresponding artifacts. As illustrated in Fig. 13, security goal SG2 is introduced into the software layer in order to ensure the Security of the Auditing Application. Thus, SG2, together with G1, supports security mechanism SM1 in the social layer. The inference rule CRO.1 (in Table 4) has been defined to automate this analysis.

123

T. Li et al. Table 4 Inference rules of cross-layer analysis

No. CRO.1

Content #cr eate(sec_goal(SG2)) ∧ sg_attributes(SG2, IMP, securit y, A, INT ) ∧suppor t (SG2, S M) ← operationali ze(S M, SG1) ∧ sg_importance(SG1, IMP) ∧ suppor t (G, S M) ∧ has(A, G) ∧ inter val_o f (INT , G)

CRO.2

#cr eate(sec_goal(SG2)) ∧ sg_attributes(SG2, IMP, SP, AS, INT 2) ∧#cr eate(sec_goal(SG3)) ∧ sg_attributes(SG3, IMP, securit y, A, INT 2) ∧and_r e f ine(SG2, SG1) ∧ and_r e f ine(SG3, SG1) ← inter val_o f (INT 1, T ) ∧ sg_attributes(SG1, IMP, SP, AS, INT 1) ∧ suppor t (G, T ) ∧ has(A, G) ∧ inter val_o f (INT 2, G)

Legend SG1

Smart Meter

Social Layer

T1 Sends energy consumption data to ES

(S) high data integrity [energy consumption data, interval(T1)]

(S) Critical security goal (S) Security goal

Goal

Task

support

Software Layer

Smart Meter Firmware (SMF) G1 Be able to send messages to ES

(S) SG2 High data integrity [energy consumption data, interval(G1)]

SG3 (S) High Security [SMF, interval(G1)]

Fig. 14 Cross-layer security analysis for security goals

Note that the above analysis should be performed for all security mechanisms that operationalize security goals. If a security goal is operationalized into several alternative security mechanisms, all of them need to be analyzed. Thus, we are able to holistically analyze alternative security solutions once the security analysis has been performed in all layers. 5.4.2 Influences of critical security goals For each critical security goal that has been identified in one layer, we check whether it involves security issues in the lower layer. If a critical security goal concerns an interval which involves support from the next layer down, then we further elaborate the critical security goal to cover corresponding security issues. Firstly, we want to analyze layer-specific threats to the original asset in the next layer; secondly, we need to take into account security of the supporting artifacts in the next layer (e.g., software applications and hardware devices), as attackers can indirectly impair the original asset by exploiting vulnerabilities of the supporting

123

artifacts. For example, as shown in Fig. 14, SG1 is concerned during the execution interval of T1, which is supported by software goal G1 owned by Smart Meter Firmware (SMF). Thus, SG1 is and-refined to SG2 and SG3. Specifically, SG2 concerns the same asset and security property of SG1 but focuses on the execution interval of G1, while SG3 concerns security of SMF. We have defined rule CRO.2 which can be used to automate such analysis. Once this cross-layer analysis is performed for one layer, iterative security analysis will be performed for the next layer down until reaching the bottom layer. 5.5 Obtain global security solutions Once security analysis has been performed in all three layers, we can derive a holistic security goal model that involves various security concerns about the system. By performing backwards analysis [33] on the goal model, which searches for solutions from root goals to leaf goals, we are able to generate a set of holistic security solutions. Such inference can

Holistic security requirements analysis for socio-technical systems SG1

(S) High Integrity [energy consumption data, interval(realtime pricing is applied)]

*AP = Alternative Point

SG2

(S) high data integrity [energy consumption data, interval(measure energy consumption)]

Social Layer

SG3

(S) high data integrity [energy consumption data, interval(sends energy consumption data to es)]

SM1 (S) auditing

Software Layer

Energy Supplier Server Application (ESSA)

SG4

(S) high security [ESSA, interval(Measure ment is audited)]

Measurement is audited

(S) high application integrity [smart meter application, interval(be able to send messages to ES)]

AP.1

SM2

(S) Input Guard

(S) Firewall

Infrastructure Layer

Home Gateway

component)]

(S) Secure access layer

SM4

Smart Meter Device

SMF is deployed

support

SG10

SG9 SG8

(S) high hardware integrity [Home Gateway, interval(Integrate

(S) Equipment siting and protection

(S) high hardware availability [Smart meter device, interval(deploy SMF)]

(S) high hardware integrity [smart meter device, interval(deploy SMF)]

AP.3

AP.2 SM5

(S) high data integrity [energy consumption data, interval(send energy consumption data to essa)]

SM3

SG7

(S) high hardware availability [Home Gateway,

SG6

SG5

Physical Entry Control

SM6

(S) Physical Entry Control

SM7

Equipment siting and protection

SM8

Fig. 15 Partial view of a holistic security goal model

be automated with the help of our prototype tool, and each of the resulting solutions consists of a number of security mechanisms that vary from the social layer to the infrastructure layer. An example of a holistic security goal model is presented in Fig. 15, which only presents the related security goals and

security mechanisms due to space limitation. In particular, each alternative point (AP) in the figure indicates that there are alternative security mechanisms that can be applied to satisfy a security goal. Note that choosing security mechanism SM2 over SM3 at AP.1 leads to different influences on security analysis of the infrastructure layer, further resulting

123

T. Li et al.

in different holistic solutions. In this example, by performing the backwards analysis, we derive in total four holistic security solutions which can achieve the root security goal. For example, one holistic solution is to have auditing at the social layer for ensuring the integrity of the energy consumption data when measuring energy consumption, to use firewall at the software layer to protect the integrity of the smart meter application, and to place physical entry control at the infrastructure layer in order to protect the home gateway. It is worth noting that our approach focuses on generating all holistic security solutions, while the selection of such alternatives is not covered by our approach. Instead, different existing goal-oriented satisfaction analysis techniques can be applied to complete such analysis [35]. Specifically, most of these techniques require to capture the positive/negative influences of security solutions on the system non-functional requirements (i.e., softgoals) by using contribution links. Since our framework leverages security solutions from existing security pattern repositories (e.g., [59]), we can elicit the above contribution links from the security pattern specifications, which is detailed in our companion paper [43].

6 A prototype tool We have developed a prototype tool MUSER (MUltilayer SEcurity Requirements analysis tool) to support the application and evaluation of our approach [44]. MUSER is a Java-based program, which is developed on top of a professional diagramming application OmniGraffle2 in order to leverage its powerful modeling features and efficiently build requirements models in three separate layers. The constructed models are stored as formal expressions, which can be inferred by the inference engine DLV.3 Specifically, upon the requests from analysts, the tool passes the models together with the analysis requests to the inference engine, which performs corresponding reasoning tasks. The inference results are then interpreted as corresponding graphical models in the canvas, and presented to users. In such a way, analysts can interactively and iteratively operate MUSER in order to perform the proposed holistic security requirements analysis. It is worth noting that the loose-coupled architecture of MUSER allows us to easily and incrementally add new inference rules, when necessary. Thus far, MUSER has been implemented with the following features: – Security goal refinement. The tool can automatically perform both selective refinement and exhaustive refinement. – Security goal simplification. The tool can automatically check the applicability of a security goal and identify 2

http://www.omnigroup.com/omnigraffle.

3

http://www.dlvsystem.com/.

123

threats that are related to the security goal. Based on such analysis results, analysts can determine the criticality of the security goal. – Security goal operationalization. Given a critical security goal, MUSER can automatically identify candidate security patterns according to the security property of the security goal. After that analysts need to manually analyze the candidates and determine whether they are applicable. – Cross-layer analysis. MUSER can automatically generate requirements in the next layer down, based on which analysts can iteratively perform security analysis there. – Holistic security solution generation. Once the entire security goal model is produced, which covers security concerns in all three layers, our tool can automatically generate all the alternatives that achieve the root security goal.

7 Validation In this section, we validate our approach by applying it to the real-time pricing scenario of the smart grid, which we have used for illustration throughout the paper. Our illustration focuses on a small part of this scenario, while here, we consider the full details. A different security goal that concerns the confidentiality of customer billing information is analyzed in this case study. By targeting the entire scenario, we intend to investigate scalability and efficacy of our approach, each of which corresponds to one research question as presented below. In particular, we decompose these questions into fine-grained ones, which can be measured and answered during the case study. – RQ1: Is our approach scalable for large-scale STSs? • RQ1.1: Can we efficiently construct three-layer requirements models for large-scale STSs? ∗ RQ1.1.1: Is it easy to collect domain information for constructing the models? ∗ RQ1.1.2: How much effort is required to build the models? • RQ1.2: Can we efficiently perform holistic security analysis for large-scale STSs? ∗ RQ1.2.1: Is additional security knowledge/ expertise required? ∗ RQ1.2.2: Are there any difficulties in applying the analysis methods? ∗ RQ1.2.3: How much effort is required to perform the security analysis? – RQ2: To what extent can our approach contribute to holistic security protection?

Holistic security requirements analysis for socio-technical systems ES sends price to customer

D

D Sends energy consumption data to ES D

Energy Supplier

D Realtime pricing is applied

Realtime price is obtained

New price is available

Calculate price

Energy usage is adjusted in real time

Custom er

Smart Meter

Current energy usage is known

Customer is the price

Load info is available ES sends price to customer

ES has the realtime load info

Sends energy consumption data to ES

Realtime load info is available

Measure energy consumption

Receive energy consumption data from SM

Energy usage is adjusted according to the realtime price

Realtime price info is known

Support smart gird

ES sends price to customer

Apply policy based adjustment

Collect smart appliance info

Control smart appliances

Execute adjustment policy

Fig. 16 The requirements model in the social layer

• RQ2.1: Can holistic security solutions be identified? • RQ2.2: How many security solution alternatives are identified? • RQ2.3: Which factors can affect the security analysis results? This case study was performed based on the information of the scenario we have presented in Sect. 2. In particular, we first constructed a three-layer requirements model, which captured requirements of different artifacts involved in this scenario, as well as connections among them. On the basis of this three-layer requirements model, we applied our holistic security analysis framework step by step, establishing a three-layer security goal model. Finally, we explored alternative security solutions that can provide comprehensive protections to the entire system. 7.1 Building three-layer requirements models As the first step of the case study, we built the three-layer requirements model for the smart grid by following the conceptual model proposed in Sect. 4.2. We constructed the requirements models layer by layer, starting from the social layer. Since we have separated concerns into different layers, in this first layer, we exclusively focused on the social and business aspects of the scenario, while ignored technical issues. In particular, we modeled three social actors Energy Supplier, Customer, and Smart Meter, where Customer depends on Energy Supplier for sending the real-time price of energies and Energy Supplier depends on Smart Meter for measuring energy consumption information. Figure 16 shows the requirements model we have built for the social layer. When elaborating the requirements model inside each actor, we respected the operational definition we have defined for tasks in the social layer, i.e., a

task is a business process activity. Benefiting from the operational definition, we are able to know when to finish the requirements modeling in the social layer. For example, we iteratively elaborated the business goal Realtime pricing is applied until obtaining concrete business process activities that are performed within this scenario, such as Calculate price. It is worth noting that we here followed a top-down process to create the requirements model; however, it can also be performed in a bottom-up manner (or a hybrid way) by using existing business process models, if available. In particular, we can first model each business process activity as a task in the social layer and then identify goals achieved by such tasks by asking “why” questions. Once the requirements model in the social layer was finished, we then analyzed support links between the social layer and the to-be-created application layer, following the instructions we presented in Sect. 4.2.1. Specifically, we checked whether each leaf-task is purely performed by people. If not, we then identified the software applications involved in this activity, based on which we model elements of the application layer, including support links relating the two layers. For example, based on the domain specification, we identified that the task Receive energy consumption data from SM is executed by using Energy Supplier Server Application. Thus, we modeled this application as an actor in the software application layer and further identified a requirements goal of the application, i.e., Be able to communicate with SM, which supports the task in the social layer. By analyzing the support links between layers, we obtained a list of application actors, each of which has one or several requirements goals. Based on such models, we then elaborated requirements for each actor in the software layer, until reaching detailed application functions (i.e., the operational definition of software tasks). Similar to the analysis in the social layer, the construction of requirements model in

123

T. Li et al. ES sends price to customer

D

D Sends energy consumption data to ES D Realtime pricing is applied

Energy Supplier

Social Layer

New price is available

Send measurement requests to SMA

Store data

Measure energy consumption

Support calculate price

History price is obtained

Query service is provided

Be able to communicate with SM

Send price info to HEMS

Send appliance info to HEMS

D D

D

New price is generated

Retrieve data from Database

Respond to request from ESSA

Generate price

Send measurement requests to SMA

Smart Meter Firmware

Price can be sent to customer

Communicate with SMA

Execute adjustment policy

Control smart appliances

D

Energy Supplier Server Application

Apply policy based adjustment

Collect smart appliance info

D

Send energy consumption data to ESSA

D

Database service is provided

Storage service is provided

Sends energy consumption data to ES

ES sends price to customer

D

D

Energy Supplier Databas e

Current energy usage is known ES sends price to customer

Realtime load info is available

Receive energy consumption data from SM

D

Provide database service

ES has the realtime load info

the price

[customer personal info, Energy usage is adjusted in real time]

Energy usage is adjusted according to the realtime price

Realtime price info is known

Support smart gird

Customer is

Load info is available

Calculate price

Application Layer

Smart Meter

Realtime price is obtained

(S)

Energy usage is adjusted in real time

Custom er

D

Send price info to HEMS

Energy consumption data is obtained Receive requests from ESSA

Send energy consumption data to ESSA

D

Be able to communicate with SAA

Measure energy consumption

Energy consumption data is stored

Status information is obtained

Communicate with ESSA Store energy consumption data

Collect appliance info

SAA are controled

Remote control component

Policies can be created and edited

Support SMA

Support communication between ESSA and HEMS

DCN is available

Deploy SAA

D Connect PC to HAN

Connect ESS to Internet

Support SAA

Appliance info is monitored by HEMS

Send appliance info to HEMS

Support communications between SAA and HEMS

Connection between SA and PC is established

Connect SA to HAN D

Connect SMD to HAN

Connect ESS to DCN

Execute remote control command

Smart Appliance

Support communications between HEMS and SAA

Connection between PC and SA is established

Connection between PC and ESS is established

D

D

Support communications between HEMS and ESSA

Deploy HEMS Connection between SMD and ESS is established

Deploy SMA to SMD

Connection between ESS and PC is established

D

D

Connection between ESS and SMD is established

Support communications between SMA and ESSA

D

Support communication between ESSA and SMA

D

Deploy ESSA to ESS

Support HEMS

Smart Meter Device

Support ESSA

Can be remotely monitored and controlled

Be able to be controlled by HEMS

Policy can be executed

Execute policies

Manage policies

Personal Computer Energy Supplier Server

Infrastructure Layer

Smart Appliance Application

Support execute adjustment policy

Support customer communicates with ES

Communicate with ESSA

Receive energy consumption data from SMA

D

Remote control component

D

Home Energy Manageme nt System

Support measure energy consumption

Be able to send messages to ES

HAN is available

D

Connect ESS to DCN Connect PC to HAN

Connect ESS to Internet

Connect SA to HAN

HAN is available

D

HAN is available

D

D

Connect PC to HAN

D

D

D

D

D Connect HG to DCN D

Internet is available Connect ESS to Internet

Connect HG to Internet

Set up wireless DCN

Connect ESS to DCN

D

Connect devices to Internet

D

D DCN is available

Home Gateway

D

Connect HG to HAN

D

Home Area Network

D

DCN is available

D

Data Communicati on Network

Connect devices

D

Connect HG to DCN

Internet

Connect devices

Connect devices to DCN

HG is installed

Support communications between DCN and HAN

Connect HAN with DCN Install HG inside home

Connect HG to DCN

Connect HG to DCN

Connect HG to HAN

Support communications between HAN and Internet

Connect HAN with DCN

Connect HG to Internet

HAN is available

Set up Wireless HAN

Connect SMD to HAN

Connection between home devices and HG is established Home area devices are in HAN Connect home devices to HAN

HG is in HAN

Connect HG to HAN

Connect PC to HAN Connect SA to HAN

Fig. 17 A three-layer requirements model of the smart grid

this layer can be done via a bottom-up manner, particularly, if there are software architecture models available for use as inputs. Once the requirements model in the software layer was finished, we then moved to the infrastructure layer, building this requirements model in a similar way. Eventually, we obtained the complete three-layer requirements model of the smart grid scenario, shown in Fig. 17.4 7.1.1 Evaluation The modeler (the first author) spent around four days gathering information from different sources. Most available specifications do not provide information required for all of the layers, as they were not originally developed for holistic analysis. Therefore, we have to synthesize such information for modeling and analysis purposes. Additional effort is required in order to make information from different sources 4 The full model can also be found here, http://disi.unitn.it/~li/SoSyM/ model_rtp.pdf.

123

consistent. In particular, in this case study, we started from a smart metering scenario [10], which was used in an empirical study of security analysis. Although this document provided the overview of the scenario, it did not cover enough information in the social layer. Thus, we searched for additional specifications about the smart grid scenarios, resulting in several papers and specifications, e.g., [6,20,52]. Although the additional documents can complement scenario information in the social layer, we realized that part of their software and infrastructure design were not the same with our starting document. As a result, when synthesizing the information from different documents, we had to carefully check the consistency of the imported knowledge. Overall, in this case study, it was not easy to collect related domain information (RQ1.1.1). The main reason for this difficulty is the method of data collection. According to Lethbridge et al. [41], data collection technique can be classified into three levels: directly interacting with subjects to collect data in real time; directly collecting raw data without interacting with subjects; reusing

Holistic security requirements analysis for socio-technical systems Table 5 Statistics of the three-layer requirements model

Layer

Actor

All

Goal

Task

(and)Refine

Operationalize

Dependency

16

60

57

44

43

21

Social

3

12

9

11

8

2

Software

5

22

20

14

16

6

Infrastructure

8

26

28

19

19

13

available information from other independent studies. Our data collection belongs to the third level, which leads to the difficulties that we have to synthesize information from different sources while make them consistent. We argue the other two levels would reduce these difficulties and simplify the data collection, which we plan to adopt in subsequent studies. After collecting and understanding sufficient information for this scenario, the modeler took one day to construct the three-layer requirements model (RQ1.1.2), as shown in Fig. 17. The statistics of the model is presented in Table 5, which shows the entire model contains 133 nodes and 108 links. Thanks to the conceptually divided layers, the modeler only needed to take into account layer-specific concerns when constructing models for a particular layer. In addition, the prototype tool can easily show/hide particular layers, enabling us to quickly switch views between a specific layer and the whole model. In particular, as we build our tool on top of a professional diagramming tool, our prototype tool inherits good usability of that tool and thus easily facilitates the graphical modeling task. Overall, thanks to both the conceptually separated layers and the prototype tool, we believe a typical analyst is able to tackle the complexity of STSs and build the three-layer requirements model once related information has been collected and available (RQ1.1).

7.2 Analyze security requirements in three layers Having the above three-layer requirements model as input (Fig. 17), we applied our approach step by step to generate the holistic security goal model, starting from the root security goal. In particular, we started from analyzing a high-level security need of stakeholders, i.e., protecting confidentiality of customer information during the time interval of applying realtime pricing. We iteratively performed security requirements analysis throughout all three layers in order to construct a holistic security goal model, based on which we generated a collection of holistic security solutions that satisfy the root security goal. In the remaining part of this subsection, we report our experiences about the application of our approach, as well as evaluate our approach based on the research questions defined earlier.

7.2.1 Security goal refinement and simplification Given a high-level security goal, we need to refine it until we are able to identify critical security goals. We applied a hybrid refinement strategy (as described in Sect. 5.1), leveraging the advantages of both the selective and the exhaustive strategies. We first adopt the selective strategy to elaborate an initial security goal into more fine-grained goals, in order to better understand the precise security needs of stakeholders. In particular, we followed an intuitive order for performing the refinement analysis, i.e., first refined the initial security goal via security properties (reference to the taxonomy in Fig. 7), then via assets (reference to a full resource schema shown in Fig. 18), and finally via interval (reference to Fig. 17). Our prototype tool can automate such refinement and pop up an alert if one dimension cannot be further refined, i.e., achieving the bottom elements in the reference model. After each refinement, we evaluated the results by asking “are all elaborated security goals needed by stakeholders?”. If a refined security goal is not needed by stakeholders, then it is excluded from subsequent analysis. As shown in the top part of Fig. 19, after elaborating security goal SG2 via the asset dimension, we found that the stakeholder’s precise security need was to protect the confidentiality of customer personal information, and the stakeholder did not care about other parts of customer information, e.g., smart appliance information. Thus, in the subsequent refinement analysis, we exclusively focused on elaborating the security goal SG4. It is worth noting that, as we did not directly interact with stakeholders, we used our collected knowledge of the case to judge whether a fine-grained security goals was needed by stakeholders. As we decided that the security goal SG4 can reflect the stakeholder’s needs, we performed exhaustive refinement analysis to explore all possible refinements of SG4. Once the exhaustive refinements were obtained, we then performed the simplification analysis over all the exhaustively refined security goals (Sect. 5.2), which was automated by the prototype tool. It is worth noting that the simplification analysis requires threat knowledge about the smart grid system, which we imported from several existing reports [7,20,64] that cover threats in different layers. The results of the simplification analysis are shown in the bottom part of Fig. 19, where SG12 was identified as a criti-

123

T. Li et al.

Billing information Part of

Part of

Customer information Part of Part of

Price information Part of

Part of

Energy production data Energy consumption data Customer personal information

Part of

Water consumption data

Smart appliance information

Part of

Electronic consumption data

Fig. 18 A full resource schema considered in this case study

cal security goal (highlighted in red), SG14 was identified as an applicable one (highlighted in green) that requires manual assessment for its criticality, and all other security goals are not applicable and should be excluded from subsequent analysis. As SG14 expresses the security need for protecting data confidentiality of customer personal information during the energy usage adjustment, we determined that it would be very likely to be threatened by threats from lower layers. As a result, we classified SG14 as a critical security goal. 7.2.2 Security goal operationalization Once critical security goals are identified, we performed the security pattern-based operationalization analysis (Sect. 5.3) to operationalize such goals. We first automatically generated a list of security pattern candidates for each critical security goal and then manually checked the context of each candidate in order to determine whether it is applicable. In particular, among the current catalog of security patterns in the social layer (Fig. 12), there was only one security pattern (i.e., access control) that can be applied for tackling data confidentiality. As such, each of the two critical security goals identified from the last step (as shown in Fig. 19) was first operationalized by an access control mechanism. Then, we manually checked the context of access control, i.e., “Any environment in which we have resources whose access needs to be controlled” [3]. Note that for our approach, such context holds by default, which can be inferred by the attributes of security goals (i.e., security property and asset). As such, according to our pattern analysis method, this access control pattern was applicable.

123

7.2.3 Cross-layer analysis Once we finished operationalization analysis in one layer, we then performed the cross-layer analysis (Sect. 5.4). Based on cross-layer links modeled in the three-layer functional goal model, we automatically performed such analysis which transferred security concerns to lower layers, targeting corresponding system components there (e.g., software applications and physical devices). In particular, the critical security goal SG12 high data confidentiality [customer personal information, interval(ES sends price to customer)] (i.e., the highlighted security goal in Fig. 19) was and-refined into two security goals in the application layer: One goal concerned the same asset and security property with SG12, but focused on a particular interval when the supporting application sends the price to customer; the other security goal exclusively concerned the security of the supporting application (i.e., energy supplier server application) instead of the original asset (i.e., customer personal information). Similarly, we performed such cross-layer analysis for another critical security goal SG14 (i.e., the highlighted security goal in Fig. 19). We did not encounter any difficulties at this step. 7.2.4 Holistic security solution analysis By iteratively performing the security analysis in each of the three layers, we finally ended up with an entire holistic security goal model, which is shown in Fig. 20.5 We performed backwards satisfaction analysis over this holistic 5

A more viewable version of the model can be found here, http://disi. unitn.it/~li/SoSyM/hsgm.pdf.

Holistic security requirements analysis for socio-technical systems

Selective

SG1

(S) [customer information, interval(Energy usage is adjusted in real time)]

SG2

SG3

(S) high data

[customer information, interval(Energy usage is adjusted in real time)]

(S) high data

(S) high data

SG4

(S) high data

SG5

[customer personal information, interval(Energy usage is adjusted in real time)]

consumption data, interval(Energy usage is adjusted in real time)]

Exhaustive

(S) high data

SG9

SG7

[customer personal information, interval(Current energy usage is known)]

(S) high data

SG8 [customer personal information, interval(Realtime price info is known)]

SG10

(S) high data

production data, interval(Energy usage is adjusted in real time)]

appliance information, interval(Energy usage is adjusted in real time)]

(S)

[customer personal information, interval(Energy usage is adjusted according to the realtime price)]

(S) high data

[customer personal information, interval(Obtain price info from ES)]

SG12

SG6

(S) high data

[customer personal information, interval(ES sends price to customer)]

(S) high data

SG11

SG15

(S) high data

[customer personal information, interval(Collect smart appliance info)]

[customer personal information, interval(Apply policy based adjustment)]

SG13

(S) high data

[customer personal information, interval(Control smart appliances)]

SG14

(S) high data

[customer personal information, interval(Execute adjustment policy)]

Fig. 19 Refine security goals in the social layer

123

T. Li et al. (S) [customer information, Energy usage is adjusted in real time]

(S) high data [customer information, Energy usage is adjusted in real time]

(S) high data

(S) high data

Social Layer

production data, Energy usage is adjusted in real time]

appliance information, Energy usage is adjusted in real time] (S) high data

(S) high data

[customer personal information, Energy usage is adjusted in real time]

consumption data, Energy usage is adjusted in real time]

(S) high data (S) high data

[customer personal information, Current energy usage is known]

(S)

[customer personal information, Realtime price info is known]

[customer personal information, Energy usage is adjusted according to the realtime price]

(S) high data (S) high data

[customer personal information, Obtain price info from ES]

[customer personal information, Apply policy based adjustment]

(S) high data

(S) high data

[customer personal information, ES sends price to customer]

[customer personal information, Control smart appliances]

(S) high data [customer personal information, Execute adjustment policy]

protection is applied (S) access control to energy adjustment

(S)

Software Layer

[energy consumption data, interval(price can be sent to customer)]

(S) high security [HEMS, interval(Support apply policy based adjustment)]

(S) high security [ESSA, interval(price can be sent to customer)] Home Energy Manageme nt System

(S) high integrity [ESSA, interval(price can be sent to customer)]

(S)

(S) high availability [ESSA, interval(price can be sent to customer)]

(S) high application integrity [ESSA, interval(price can be sent to customer)]

support access control

(S)

Control access to all the functions of HEMS

[energy consumption data, interval(Send price info to HEMS)]

(S) Firewall (Server)

(S) Server sandbox

(S) Input Guard (to ESSA)

are not critical

This security goal and

This security goal and

(S)

are not critical

are not critical

This security goal and

(S) high application integrity [HEMS, interval(Support apply policy based adjustment)]

This security goal and (S) high application integrity [HEMS, interval(support access control)]

[customer billing data, interval(Support execute adjustment policy)]

(S) [customer billing data, interval(Be able to communicate with SAA)]

[customer billing data, interval(Support viewing energy consumption data)]

(S) high integrity [HEMS, interval(support access control)]

are not critical

protection is applied

(S) Security Pipe (between ESSA and HEMS)

(S) high availability [HEMS, interval(Support apply policy based adjustment)]

(S) high integrity [HEMS, interval(Support apply policy based adjustment)]

(S) high availability [HEMS, interval(support access control)]

This security goal and

protection is applied

(S) Security Access Layer (on ESSA2)

(S) [customer billing data, interval(Support apply policy based adjustment)]

(S) high security [HEMS, interval(support access control)]

(S)

are not critical

[customer billing data, interval(Show energy data)]

protection is applied

protection is applied protection is applied

Infrastructure Layer

(S)

(S) high application integrity [ESSA, interval(Support communication between ESSA and HEMS)]

(S) high security [ESS, interval(Support communication between ESSA and HEMS)]

[energy consumption data, interval(Support communication between ESSA and HEMS)]

ESS Gateway

support ESS

(S) high security [ESS Gateway, interval(support

(S) high application integrity [HEMS, interval(Support HEMS)]

Integrate This security goal is not applicable in this layer

(S) [customer billing data, interval(Connection between ESS and PC is established)]

(S) [customer billing data, interval(Connect ESS to Internet )]

(S) high integrity [ESS, interval(Support communication between ESSA and HEMS)]

(S) high hardware integrity [ESS, interval(Support communication between ESSA and HEMS)]

component

This security goal and

(S) high integrity [ESS Gateway, interval(support

(S) high hardware integrity [ESS Gateway, interval(support ESS

(S) high availability [ESS Gateway, interval(support

(S) Equipment sitting and protection (ESS)

(S) Equipment sitting and protection (ESS Gateway)

(S) high application integrity [HEMS, interval(Support communications between HEMS and SAA)]

(S) high security [Home Gateway, interval(support Home Gateway

This security goal is not applicable in this layer

(S) high availability [PC, interval(Support HEMS)]

(S) high integrity [PC, interval(Support HEMS)]

This security goal is not applicable in this layer

component

(S) high integrity [Home Gateway,

(S) high availability [Home Gateway, interval(support

This security goal and are not critical

(S) high hardware integrity [PC, interval(Support HEMS)]

(S) high security [PC, interval(Support communications between HEMS and SAA)]

(S) [customer billing data, interval(Support HEMS)]

support home

Integrate

(S) high availability [ESS, interval(Support communication between ESSA and HEMS)]

are not critical

(S) Cabling security (Company2)

(S) high security [PC, interval(Support HEMS)]

(S) Full View with Errors (HEMS) (S) Limited View (HEMS)

(S) Firewall (Home)

This security goal and are not critical

(S) Physical entry control (to ESS Gateway)

(S) high integrity [PC, interval(Support communications between HEMS and SAA)]

(S) high hardware integrity [PC, interval(Support communications between HEMS and SAA)]

(S) high availability [PC, interval(Support communications between HEMS and SAA)]

(S) [customer billing data, interval(Deploy HEMS)]

This security goal and are not critical

This security goal and (S) high hardware integrity [Home Gateway,

are not critical

(S) Physical entry control (to ESS)

(S) Cabling security (Home)

(S) Equipment sitting and protection (Home Gateway)

(S) Equipment sitting and protection (PC)

(S) Physical entry control (to home)

Fig. 20 The entire holistic security goal model across three layers

security goal model in order to identify all possible holistic security solutions for the entire system (Sect. 5.5). Finally, the analysis resulted in 21 holistic security solutions in total. Each of these holistic security solutions consists of specific solutions from different layers, covering different system components. For example, we list one holistic security solution below, which consists of ten security mechanisms (each mechanism is a solution introduced by a security pattern). In particular, there is one security mechanism in the social layer, four security mechanisms in the software layer, and five security mechanisms in the infrastructure layer. It is worth noting that the satisfaction of the stakeholder’s root security goal requires all these ten security mechanisms to be implemented, which may cost a large amount of money. This is mainly because we have taken a holistic viewpoint, considering all the related system components.

123

Solution 1(10 mechanisms): – Social Layer: Access control to energy adjustment – Software Layer: Firewall (Home), Security Pipe (between ESSA and HEMS), Server sandbox, Limited View (HEMS) – Infrastructure Layer: Cabling security (Home), Equipment sitting and protection (PC), Equipment sitting and protection (Home Gateway), Equipment sitting and protection (ESS), Cabling security (Company2)

7.2.5 Evaluation Throughout the entire case study, we realized that additional security expertise was required in several places (RQ1.2.1).

Holistic security requirements analysis for socio-technical systems

Firstly, during the simplification analysis, for security goals that were classified as applicable but not critical according to our inference rules, we manually assessed their criticality. In particular, we needed to assess whether or not the security goal was threatened by threats originated from lower layers, which required additional security expertise. Secondly, during the security pattern analysis, we manually checked the applicability of security pattern candidates. In particular, we noticed that the expertise of analysts can affect their performance during such checks, because analysts must first well understand a security pattern in order to assess its applicability and to correctly apply the pattern. In other words, the application of security patterns would require analysts to have a certain level of security knowledge. Note that such a demand is not particular to our approach, but it is common across all approaches that leverage security patterns. Despite this challenge, we contend that our approach has aided what would be a knowledge-intensive analysis by using security patterns, providing advantages over approaches which do not use this established knowledge. When performing the security goal refinement, we noticed that refining a security goal in the social layer was more complicated and difficult than the analysis in other layers, as it involved more manual analysis (RQ1.2.2). In the social layer, we started from a high-level security goal, which is by nature broad and may not reflect the stakeholder’s real needs. Thus, we needed to adopt a hybrid refinement strategy, which first uncovers the stakeholder’s security needs more precisely. In the software layer and the infrastructure layer, the root security goals were derived from the security concerns in the upper layers, which had already captured stakeholder’s more precise security needs. As such, we can directly apply the exhaustive refinement strategy, which is fully automated by our tool. After collecting all required information and constructing the three-layer requirements goal model, the first author spent 6 h performing the holistic security analysis (RQ1.2.3). Considering the scale of this scenario (Table 5), the time span was reasonable. Although there were several difficulties we encountered during the case study (as discussed above), overall, we argue that our approach can be efficiently applied to dealing with holistic security requirements analysis of largescale systems (RQ1.2). As we have specified and illustrated before, our case study finally resulted in 21 holistic security solutions in total (RQ2.2), each of which consisted of specific solutions that provide security protection to all three layers (RQ2.1). Moreover, we have identified two factors that can affect the quality of the analysis results, which should be carefully improved in future work (RQ2.3). Firstly, the catalog of security patterns directly can affect the holistic security solutions we produced at the end of our security analysis. If the catalog misses some important security patterns, the obtained secu-

rity solutions may not be optimal. Secondly, a comprehensive set of threats is important for ensuring the completeness of our holistic security analysis, because such threats are used to determine the criticality of security goals. Based on the above answered research questions, we argue our security analysis results have a good coverage of security concerns and can effectively contribute to holistic security protection of large-scale systems (RQ2). 7.3 Threats to validity As there are different ways of classifying validity in the literature, we here adopt the classification used by Runeson et al. [58], which has an focus on case study research in software engineering. In particular, we discuss internal validity, external validity, construct validity, and reliability, respectively. 7.3.1 Internal validity Internal validity considers the causal relations between factors investigated in the case study. When evaluating the difficulty of modeling three-layer requirements models, we focused on whether or not the modeler is able to conceptually build the three-layer requirements model. However, in practice, both the utility of the modeling tool and the analyst’s modeling experiences with the tool can affect the overall difficulty of this modeling task, introducing a threat to internal validity. Although our tool is developed on top of a professional diagramming tool which has very good usability, people who are not familiar with this tool or have little experience with modeling may encounter difficulties when building the three-layer requirements model. In the future, we intend to evaluate the difficulty of conceptually modeling the threelayer model and the difficulty of graphically modeling the three-layer model, respectively. 7.3.2 External validity External validity is concerned with to what extent it is possible to generalize the findings of our case study. Because of the inherent complexity of STSs (e.g., our analysis model contains more than two hundred elements), a holistic security requirements analysis takes a considerable amount of effort. As a result, our validation so far involves only one case study and focuses on one particular security goal, imposing a threat to external validity. To tackle this threat, we plan to perform more case studies and take into account more security goals. Another threat concerns the security background of the analyst. The case study reported in this paper is performed by the first author, who was a PhD student focusing on Security Requirements Engineering. However, we have not evaluated our approach with participants with little security knowledge. As such, we do not have practical evidence yet that shows our

123

T. Li et al.

approach can be applied by those who are not experts in security, although our approach does incorporate security patterns to help analysts to reuse security knowledge. Therefore, in subsequent research, we aim to have participants who have little security knowledge to apply and evaluate our approach, observing differences in their performance when compared to those knowledgeable in security.

on the cross-layer relations. It is worth noting that, in order to exert the power of our approach, a group of people with specialized domain knowledge of all three layers is required, e.g., business analysts, software architects, and infrastructure designers.

7.3.3 Construct validity

An important advantage of our approach is systematically guiding analysts through a comprehensive security analysis process, covering different layers of an STS. In particular, during our case study, we have observed that the support links captured in the three-layer requirements model were especially important for relating security analysis across layers. In addition, by capturing and arranging security requirements in the a holistic security goal model, we can identify alternative security solutions. Since implementing holistic security solutions is likely to be expensive, it is particularly important to identify and evaluate all the possible alternatives upfront, among which analysts can select the most appropriate solution within their budget.

Construct validity concerns to what degree a test measures what it claims to be measuring. In our case study, we measure both the number and coverage of holistic security solution alternatives, based on which we determine the effectiveness of our analysis results. We acknowledge that the quality of the obtained security solutions is a further factor, which may play a role in assessing the effectiveness of our approach. As a countermeasure to this threat, we intend to have security experts to assess the quality of the generated holistic security solutions.

8.2 Advantages

7.3.4 Reliability 8.3 Potential Reliability is concerned with to what extent the data and the analysis are dependent on the specific researchers. Since the case study is performed by only one person (i.e., the first author), there is a threat to reliability of the analysis results. To tackle this issue, in the future, we first plan to have peer researchers to evaluate the analysis results. In addition, for subsequent case studies, we will include more than one analysts who work together to apply our approach.

8 Discussion In this section, we discuss several aspects of the proposed framework in more detail. 8.1 Motivations The essence of our framework is to separate (security) requirements analysis of STSs into three different layers, each of which is associated with a specific solution domain. In particular, each layer corresponds to specific artifacts that are involved in STSs, such as business processes, software applications, and physical infrastructure, etc. In particular, the different domains of artifacts involve their own phenomena, which are normally analyzed by different people who have specific knowledge backgrounds. Such phenomena motivate us to apply the Divide and Conquer paradigm [39] to deal with the complexity of the requirements analysis of STSs, i.e., dealing with the requirements problem of each layer separately and merging the analysis results based

123

Our three-layer requirements framework is an initial effort to deal with complicated (security) requirements problems via a multilayer manner, which can be further extended in the future. In particular, the number and content of layers can be flexible, depending on the scope and the complexity of the system. For instance, if the target system is a technical-oriented system and does not involve the design of the business process, then the framework can only focus on the application layer and the infrastructure layer. Cyberphysical systems (CPSs), which are designed as a network of interacting elements with physical input and output instead of as standalone devices, are a typical example in this respect. For another example, if the target system not only deals with the software applications, but also intensively involves issues about operating systems, then it is better to add an additional operating system layer between the application layer and the infrastructure layer. Regardless of the structure of layers, the analysis provided by the multilayer framework remains the same. Furthermore, although the current framework is designed to analyze the influences between layers via a top-down manner, it is possible to have the influences to go bottom-up. For example, an infrastructure task can create software or social requirements. After enabling the bottom-up analysis, the overall analysis is much more complicated, as there can be an analysis loop among layers. Thus, a criterion for ending the analysis would be required. Lastly, our framework can be extended by seamlessly incorporating the recent advances of threat analysis methods

Holistic security requirements analysis for socio-technical systems

in order to support the simplification analysis of security goals, as presented in Sect. 5.2. Specifically, we have described a generic process for identifying critical security goals, as well as interfaces for interacting with external threat analysis methods. Because the analysis results of such external analysis methods can affect the overall quality of the results of our holistic security analysis, it is important to continuously update our framework with regard to the recent advances in the corresponding research fields in order to timely deal with new challenges. For example, as we have discussed in the case study, multistage attacks to STSs are imposing a new research challenge, which has not been tackled by existing approaches. As such, in the future, we also intend to develop a holistic security attack analysis approach as part of our holistic security requirements framework, dealing with this particular challenge. 8.4 Security knowledge reuse Due to the intrinsic complexity and heterogeneity of STSs, the holistic security analysis involves a wide spectrum of security issues, which requires a large amount of security knowledge and thus makes the analysis even more complicated. In particular, this challenge is exacerbated by the fact that security knowledge is difficult to acquire, as reported in [63]. As a response to this challenge, our approach has a particular focus on knowledge reuse, facilitating this knowledge-intensive analysis. Firstly, we have encapsulated part of required security knowledge into corresponding inference rules, which can be automatically inferred by the prototype tool. It is worth noting the inference rules we defined in this paper are domainindependent, which can be applied to all types of systems. In the future, we can incrementally define more inference rules to capture domain-specific knowledge in order to facilitate analysis in the corresponding domains. Secondly, we leverage reusable security patterns to help analysts to effectively generate proved security solutions that operationalize security goals. As a result, the security analysis results depend on the employed catalog of security patterns. Although reusing existing security patterns can facilitate our knowledge-intensive security analysis, analysts are required to grasp a full understanding of a security pattern before applying it, as reported in [2]. We have also identified this challenge during our case study. Because of this issue, although there are more than 100 security patterns available from the repositories we use [3,18,59], our approach does not incorporate all of them. Instead, we currently incorporate 21 patterns from those repositories (as shown in Fig. 11), covering different layers and different security concerns, which serve as the baseline of our approach. The importance of an appropriate catalog of security patterns has been emphasized by many security pattern

researchers, and a number of catalogs have been developed [23,29]. However, there are no catalogs that include all security patterns and have been commonly accepted by all security pattern researchers. For example, Scandariado et al. present Full View with Errors as a security pattern [59], while other researchers may think this is a pseudo-pattern and exclude it from the catalog of security patterns. It is worth noting that our approach makes use of existing security patterns from the literature [3,59], which we assume as qualified patterns. In other words, assessing the quality of these patterns is out of the scope of this paper. Overall, the current catalog of security patterns used by our approach is by no means the best one and can be evolved based on subsequent evaluations of our approach and future advances of security pattern research. When applying our approach in practice, practitioners can customize the catalog of security patterns according to their security expertise. For example, if practitioners have in-depth understanding of a specific set of the security patterns in the repositories, they can expand the catalog of security patterns with this set in order to produce more comprehensive security analysis results. 8.5 Scalability Estrada et al. [14] have acknowledged the scalability problem of the i* modeling language based on their empirical evaluation. In particular, they have identified that the lack of mechanisms for modularization is the main cause to this problem. Our framework, as an extension, in part, of i*, also needs to deal with this scalability problem. To relieve this problem, we have produced interventions which optimize the modularity of the entire analysis model. Firstly, the division of the three layers appropriately separates concerns related to different artifacts, and each layer can be modeled separately. With the prototype tool, analysts can determine the visibility of each layer and thus can either browse the entire three-layer model or focus on a particular layer. Secondly, we visually separate the security requirements model from the functional requirements model, while maintain the semantic connection between them. Many approaches have proposed to model and analyze security requirements together with functional requirements, e.g., misuse cases [62] and Secure Tropos[49]. However, given the complexity of STSs, putting all these models together can further exacerbate the scalability problem. As such, we semantically connect the functional requirements model with the security requirements model via the interval attribute of security goals, without graphically connecting these models. Each security goal actually targets a particular element in the functional requirements model. Such connections can be easily maintained and analyzed with the support of our prototype tool. Apart from the above methodological designs, we also implement our prototype tool with specific features that

123

T. Li et al.

contribute to relieving the scalability problem. Firstly, our prototype tool is specifically designed to offer high usability. As reported by Gea et al. [12], “Requirements modeling is one of the categories of features most poorly supported by the RE tools.” In addition, many existing modeling tools do not have a sufficient level of usability to accommodate modelers’ needs [47]. As a result, the lack of usability of other prototype tools has prevented modelers from building large-scale models. As a response to this challenge, we have developed our prototype tool on top of a professional diagramming application OmniGraffle, making use of its powerful modeling features. In particular, with the support of the application, we are able to model complex scenarios with hundreds of elements in an efficient manner, as described in the case study. Secondly, our tool not only performs security analysis on existing models but also automatically creates security goal model elements, helping analysts to incrementally construct the three-layer security goal model. As such, analysts can avoid laborious modeling tasks, especially when dealing with large-scale models. Benefiting from both the methodological designs and the prototype tool, we are able to model and analyze complex STSs with hundreds of elements as illustrated in the case study.

threats that appear at different system layers can be combined by attackers to perform more damaging attacks (i.e., multistage attacks), imposing new research challenges. As a result, in the future, we plan to investigate how to holistically identify system threats and capture potential multistage attacks.

9 Related work 9.1 NFR-based requirements analysis Chung proposes to treat security requirements as a class of NFRs and apply a process-oriented approach to analyze security requirements [8]. In subsequent research, Chung and Supakkul integrate NFRs with FRs in the UML use case model, enabling NFRs to be refined through functional requirement models [9]. Another complementary approach introduced by Gross and Yu proposes to relate NFRs to system architecture using design patterns [22]. However, all of these NFR-based approaches mainly focus on information system analysis and do not support requirements analysis in the social layer and the infrastructure layer. 9.2 Security requirements analysis

8.6 Room for improvement Based on our experience in applying the three-layer framework, we have identified two limitations that require further improvements. Firstly, we discovered in our case study that the current catalog of security patterns is not enough for tackling some threats. For example, the critical security goal SG12 we identified in the social layer (Fig. 19) was threatened by a social threat “Inappropriately post customer data to public media” [20, Chap.2], which needed to be tackled by security solutions such as security training. However, our catalog of security patterns (Fig. 11) only included access control as a candidate solution to this problem, which was not suitable to tackle that threat. Therefore, in the future, we need to incorporate more patterns so as to have a better coverage. Secondly, we have identified the need for having a sophisticated and holistic threat analysis method, which can efficiently identify threats at different system layers. In this case study, we imported threat information from reports in literature, as the smart grid scenario has been analyzed by many security approaches. However, for other STSs that have not been much investigated, obtaining such threat information may not be easy. We contend that existing threat analysis methods, such as misuse cases [62], cannot effectively analyze system threats from a holistic viewpoint. In addition,

123

A large number of security requirement analysis approaches have been proposed over last two decades. Most of these approaches focus on analyzing security requirements with regard to a particular aspect of information system. In particular, there are many approaches that focus on the social and organizational aspect: Mouratidis et al. capture security intentions of stakeholders and interdependence among stakeholders [50]; Giorgini et al. investigate social relationships by integrating trusts and ownership into security analysis [21]; Paja et al. capture and analyze security requirements of STSs in terms of commitments, using three views [53]; Liu et al. analyze organizational risks by analyzing dependencies among social actors [46]. Another branch of work deals with security requirements for business processes. Rodríguez et al. propose an extension of UML activity diagram to model security requirements as part of the business process model [56], while Altuhhova et al. [1] use BPMN constructs to represent security-related concepts and model secure business process models. Herrmann et al. [28] propose a systematic process to elicit and analyze security requirements from business processes models. Most work is dedicated to analyzing security requirements of software, such as Attack Tree [60], Misuse case [62], and obstacle analysis [68]. Compared to our approach, all the above approaches target a particular conceptual layer of STSs and cannot holistically analyze STSs as a whole.

Holistic security requirements analysis for socio-technical systems

9.3 Security pattern-based analysis As security patterns have been recognized as an efficient way of designing system security, over a dozen security methodologies have been proposed based on security patterns [66]. As a representative of these methodologies, Uzunov et al. propose a comprehensive pattern-driven security methodology (ASE) [67], which is designed for general distributed systems based on a significant number of well-documented security patterns [18]. This methodology covers both the requirements gathering and analysis stage and the design stage of software development lifecycle. In the requirements analysis stage, they first elicit secure use cases based on misuse activities. To satisfy these secure use cases, they then identify corresponding security solutions by using security patterns. After passing the security solutions to the design phase, they apply security solution frames, which consist of architectural level security patterns and micro process patterns, to generate security system design. Compared to their methodology, our framework has following advantages: Firstly, our analysis targets STSs, which involve more heterogeneous components and are more complicated than general distributed systems. In particular, both social and physical security concerns are taken into account in our methodology. As such, our analysis can provide more comprehensive security protection. Moreover, building on goal modeling languages, our approach can capture and analyze alternative security solutions from a holistic viewpoint and would eventually come out with the best possible solution according to the model. Lastly, our methodology is supported by a prototype tool, enabling us to deal with the complexity of large-scale STSs, while their methodology is performed manually, and they “believe it can be used without tool-support on at least small- to mid-size projects” [67].

9.4 Security requirements transformation Many approaches have been proposed to transform security requirements captured in a high-abstraction level to the security design in a low-abstraction level in order to maintain security throughout the entire life-cycle of system development. To name a few, Mouratidis and Jürjen relate security requirements to security designs by integrating Security Tropos with UMLsec [51]; Menzel et al. propose a model-driven approach that transfers security requirements, which are captured at the business process layer, to concrete security implementations/configurations by using patterns [48]; Rodríguez et al. apply MDA techniques to transform secure business process model into analysis class diagram and use case diagram [57]; Uzunov et al. propose to achieve such transition by using security requirements patterns and security architectural security patterns.

Different from these approaches, which deal with the transition between security requirements and security design, our approach focuses on the requirements analysis stage and holistically analyzes security requirements components of various system levels (e.g., business processes, software applications, and physical infrastructure). We acknowledge that it is a non-trivial task to relate our approach to later system development stages, although much effort has been placed into transforming goal models into downstream design artifact [31]. However, the transition between security requirements and security design can introduce new threats, particularly in the absence of a systematic methodology. In this respect, the above approaches can be complementary to our framework. 9.5 Multilayer requirement analysis A number of approaches have been proposed to analyze requirements in multiple levels. Lankhorst et al. [40] provide an integrated view for enterprise architecture, consisting three layers, to enable impact and change analysis covering all relevant aspects. Within each of the three layers, they consider both external services that are delivered by one layer and internal services that specify how the layer is implemented. Cui and Paige propose an integrated framework for system requirement developments, which consists of six levels and aligns requirements with business motivations [11]. Specifically, their framework is intended to cover organizational requirements, product requirements, and hardware/software requirements. Ranjan and Misra argue that the goal-based analytical technique should be applied to different level of abstraction in order to better understand requirements of specific domains [55]. Although these approaches have conceptually presented the multilayer structure, none of them have pragmatically developed analysis methods for analyzing (security) requirements of STSs. Going beyond the above approaches, we delve into influences of security requirements in different layers and have proposed a systematic process and a collection of analysis methods to pragmatically analyze security requirements in a holistic manner. 9.6 Mappings between the three-layer framework and enterprise architecture frameworks Enterprise architecture frameworks were first investigated by Zachman with the aim of efficiently aligning business requirements with IT systems. In particular, the Zachman framework provides a comprehensive taxonomy of artifacts of an enterprise, which is specified in terms of an user’s perspective (e.g., business owner) and a descriptive focus (e.g., function), forming 36 intersecting cells [71]. Based on this taxonomy, The Open Group Architectural Framework (TOGAF) divides an enterprise architecture into

123

T. Li et al.

four categories, i.e., business architecture, data architecture, application architecture, technical architecture [26]. Although these enterprise architecture models connect enterprise artifacts at different layers, they do not capture and analyze alternative security solutions across layers. We argue that our framework and the TOGAF framework can complement each other. On the one hand, the architecture categories defined in TOGAF can be intuitively mapped to our three-layer requirements framework, facilitating the construction of the three-layer requirements framework. In particular, the business architecture can be mapped to the social layer, each business activity in the business architecture will be modeled as a business task; the application architecture corresponds to the software application layer, an application function is then modeled as an application task; the technical architecture is mapped to the infrastructure layer, helping analysts to identify deployment tasks in this layer. On the basis of such mappings, when TOGAF architecture models are available for use, analysts are able to build the three-layer functional requirements models in a bottom-up fashion by asking “why” questions [70]. It is worth noting that, as The Open Group has provided detailed mappings between the TOGAF architectures and the Zachman framework [65], we can thus indirectly establish the mappings between our three analysis layers and the Zachman framework.

10 Conclusions and future work In this paper, we propose a holistic approach to analyze security requirements for STSs. Our approach consists of a three-layer conceptual model, a systematic analysis process, a number of security analysis methods, and corresponding inference rules. This approach is applied in the requirements analysis stage of system development lifecycle, which analyzes high-level security requirements of an STS, iteratively refines and propagates them across all three layers of the requirements model, and finally generates holistic security solutions. Such security solutions will be designed and implemented in later system development stages. By capturing the influence of upper-layer specifications on the requirements of lower layers, our approach avoids a piece-meal treatment of security and provides comprehensive protection to STSs. In addition, our approach incorporates existing security patterns for reusable security knowledge, hard to acquire for requirements analysts. A prototype tool has been developed to support the entire analysis process, allowing analysts to semiautomatically perform the holistic security requirements analysis. In particular, the tool is designed with particular features that can effectively support modeling of large-scale systems.

123

To validate our approach, we have completed a smart grid case study, based on which we conclude that our proposal is scalable for large-scale STSs. In particular, we have evaluated both the construction of the three-layer requirements model and the holistic security analysis performed based on that three-layer model. The analysis results produced by our approach are able to cover security solutions across three layers, contributing to holistic protection of STSs. Also, through the case study, we have accumulated practical experiences which help us to more effectively apply our approach. On the other hand, we have also discovered, reported, and discussed several challenges to the effectiveness of our approach. Accordingly, we have identified a number of countermeasures, which can prevent or mitigate those challenges and should be accommodated in our future work. – Firstly, we intend to collect more empirical evidence about the effectiveness of our approach. In particular, we plan to evaluate our approach with more case studies, using a wider variety of analysts and letting a security expert validate the final analysis results. – Secondly, our approach relies on external threat knowledge sources to determine the criticality of security goals. However, existing threat knowledge sources do not cover multistage attacks, imposing an emerging challenge to the security of STSs. As such we aim to develop a systematic approach to identify (multistage) attacks that spread across layers, constituting as an important part of our holistic security requirements framework. – Finally, we want to enhance the analytical capability of the current framework by including more security patterns based on recent advances in the field [18,61]. As reported in the paper, the application of security patterns requires additional security knowledge, we also aim to develop techniques to further facilitate such analysis. As another branch of future work, we plan to further explore the potential of our framework in tackling requirements evolution problems. In particular, the support links captured in the three-layer goal model can shed light on how a change in one layer affects requirements in other layers. As such, based on the three-layer framework, we want to develop a systematic approach to efficiently evolve holistic security solutions once an STS has changed at any of the three layers. Acknowledgments Trento authors are supported by the ERC advanced Grant 267856, titled “Lucretius: Foundations for Software Evolution”. Jennifer Horkoff is supported by an ERC Marie Sklodowska-Curie Intra-European Fellowship (PIEF-GA-2013-627489), and by a Natural Sciences and Engineering Research Council of Canada Postdoctoral Fellowship (Sept. 2014–Aug. 2016).

Holistic security requirements analysis for socio-technical systems

References 1. Altuhhova, O., Matuleviˇcius, R., Ahmed, N.: Towards definition of secure business processes. In: Bajec, M., Eder, J. (eds.) Advanced Information Systems Engineering Workshops, pp. 1–15. Springer, Berlin (2012) 2. Araujo, I., Weiss, M.: Linking patterns and non-functional requirements. In: Proceedings of the Ninth Conference on Pattern Language of Programs (PLOP 2002) (2002) 3. Asnar, Y., Massacci, F., Saidane, A., Riccucci, C., Felici, M., Tedeschi, A., El-Khoury, P., Li, K., Séguran, M., Zannone, N.: Organizational patterns for security and dependability: from design to application. Int. J. Secur. Softw. Eng. 2(3), 1–22 (2011) 4. Asnar, Y., Li, T., Massacci, F., Paci, F.: Computer aided threat identification. In: 2011 IEEE 13th Conference on Commerce and Enterprise Computing (CEC), pp. 145–152. IEEE (2011) 5. Bresciani, P., Perini, A., Giorgini, P., Giunchiglia, F., Mylopoulos, J.: Tropos: an agent-oriented software development methodology. Auton. Agents Multi-Agent Syst. 8(3), 203–236 (2004) 6. Brown, B., Singletary, B., Willke, B., Bennett, C., Highfill, D., Houseman, D., Cleveland, F., Lipson, H., Ivers, J., Gooding, J., et al.: Ami System Security Requirements. UCA Int. Users Group, US Dept. Energy, Washington, DC, USA, Tech. Rep. UCAIUG: AMI-SEC-ASAP (2008) 7. Carpenter, M., Goodspeed, T., Singletary, B., Skoudis, E., Wright, J.: Advanced Metering Infrastructure Attack Methodology. InGuardians white paper (2009) 8. Chung, L.: Dealing with security requirements during the development of information systems. In: Rolland, C., Bodart, F., Cauvet C. (eds.) Advanced Information Systems Engineering. LNCS, vol. 685, pp. 234–251. Springer, Berlin (1993) 9. Chung, L., Supakkul, S.: Representing nfrs and frs: a goal-oriented and use case driven approach. In: Dosch, W., Lee, R., Wu, C. (eds.) Software Engineering Research and Applications, LNCS, vol. 3647, pp. 29–41. Springer, Berlin (2006) 10. Cuellar, J., Suppan, S.: A smart metering scenario. In: Network of Excellence on Engineering Secure Future Internet Software Services and Systems, eRISE, vol. 2013, (2013) 11. Cui, X., Paige, R.: An integrated framework for system/software requirements development aligning with business motivations. In: 2012 IEEE/ACIS 11th International Conference on Computer and Information Science (ICIS), pp. 547–552 (2012) 12. De Gea, J.M.C., Nicolás, J., Alemán, J.L.F., Toval, A., Ebert, C., Vizcaíno, A.: Requirements engineering tools: capabilities, survey and assessment. Inf. Softw. Technol. 54(10), 1142–1157 (2012) 13. Eiter, T., Gottlob, G., Mannila, H.: Disjunctive datalog. ACM Trans. Database Syst. (TODS) 22(3), 364–418 (1997) 14. Estrada, H., Rebollar, A.M., Pastor, O., Mylopoulos, J.: An empirical evaluation of the i* framework in a model-based software generation environment. In: Dubois, E., Pohl, K. (eds.) Advanced Information Systems Engineering, pp. 513–527. Springer, Berlin (2006) 15. Fernandez, E.B.: Two patterns for web services security. In: International Conference on Internet Computing, pp. 801–807 (2004) 16. Fernandez, E.B., Ballesteros, J., Desouza-Doucet, A.C., LarrondoPetrie, M.M.: Security patterns for physical access control systems. In: Barker, S., Ahn G.J. (eds.) Data and Applications Security XXI, pp. 259–274. Springer, Berlin (2007) 17. Fernandez, E.B., Fonoage, M., VanHilst, M., Marta, M.: The secure three-tier architecture pattern. In: CISIS, pp. 555–560 (2008) 18. Fernandez-Buglioni, E.: Security Patterns in Practice: Designing Secure Architectures Using Software Patterns. Wiley, New York (2013) 19. Firesmith, D.: Specifying Reusable Security Requirements. J. Object Technol. 3(1), 61–75 (2004)

20. Flick, T., Morehouse, J.: Securing the Smart Grid: Next Generation Power Grid Security. Elsevier, Amsterdam (2010) 21. Giorgini, P., Massacci, F., Zannone, N.: Security and trust requirements engineering. In: Aldini, A., Gorrieri, R., Martinelli, F. (eds.) Foundations of Security Analysis and Design III. LNCS, vol. 3655, pp. 237–272. Springer, Berlin (2005) 22. Gross, D., Yu, E.: From non-functional requirements to design through patterns. Requir. Eng. 6(1), 18–36 (2001) 23. Hafiz, M., Adamczyk, P., Johnson, R.E.: Organizing security patterns. IEEE Softw. 24(4), 52–60 (2007) 24. Haley, C.B., Laney, R.C., Nuseibeh, B.: Deriving security requirements from crosscutting threat descriptions. In: Proceedings of the 3rd International Conference on Aspect-Oriented Software Development, pp. 112–121. ACM, New York (2004) 25. Halleux, P., Mathieu, L., Andersson, B.: A method to support the alignment of business models and goal models. Proc. BUSITAL 8, 121 (2008) 26. Haren, V.: TOGAF Version 9.1. Van Haren Publishing, Berlin (2011) 27. Hernan, S., Lambert, S., Ostwald, T., Shostack, A.: Threat modeling-uncover security design flaws using the stride approach. In: MSDN Magazine-Louisville, pp. 68–75 (2006) 28. Herrmann, P., Herrmann, G.: Security requirement analysis of business processes. Electron. Commer. Res. 6(3–4), 305–335 (2006) 29. Heyman, T., Yskout, K., Scandariato, R., Joosen, W.: An analysis of the security patterns landscape. In: Proceedings of the Third International Workshop on Software Engineering for Secure Systems (SESS), pp. 3–10. IEEE Computer Society (2007) 30. Horkoff, J., Aydemir, F.B., Li, F.L., Li, T., Mylopoulos, J.: Evaluating modeling languages: an example from the requirements domain. In: Conceptual Modeling (ER 2014), pp. 260–274. Springer, Berlin (2014) 31. Horkoff, J., Li, T., Li, F.L., Salnitri, M., Cardoso, E., Giorgini, P., Mylopoulos, J.: Using goal models downstream: a systematic roadmap and literature review. Int. J. Inf. Syst. Model. Des. 6(2), 1–42 (2015) 32. Horkoff, J., Li, T., Li, F.L., Salnitri, M., Cardoso, E., Giorgini, P., Mylopoulos, J., Pimentel, J.: Taking goal models downstream: a systematic roadmap. In: 2014 IEEE Eighth International Conference on Research Challenges in Information Science (RCIS), pp. 1–12. IEEE (2014) 33. Horkoff, J., Yu, E.: Finding solutions in goal models: an interactive backward reasoning approach. In: Parsons, J., Saeki, M., Shoval, P., Woo, C., Wand, Y. (eds.) Conceptual Modeling-ER 2010, pp. 59–75. Springer, Berlin (2010) 34. Horkoff, J., Yu, E.: Analyzing goal models: different approaches and how to choose among them. In: Proceedings of the 2011 ACM Symposium on Applied Computing, pp. 675–682. ACM, New York (2011) 35. Horkoff, J., Yu, E.: Comparison and evaluation of goal-oriented satisfaction analysis techniques. Requir. Eng. 18(3), 199–222 (2013) 36. ISO/IEC 27002: Information Technology—Security Techniques— Code of Practice for Information Security Management (2005) 37. ISO/IEC 27000: 2012 Information Technology—Security Techniques—Information Security Management Systems— Overview and Vocabulary. http://www.27000.org/ (2012) 38. Jureta, I., Borgida, A., Ernst, N., Mylopoulos, J.: Techne: Towards a new generation of requirements modeling languages with goals, preferences, and inconsistency handling. In: Proceedings of the RE’10, pp. 115–124 (2010) 39. Knuth, D.E.: The Art of Computer Programming: Sorting and Searching, vol. 3. Pearson Education, New York (1998) 40. Lankhorst, M.M., Proper, H.A., Jonkers, H.: The architecture of the archimate language. In: Halpin, T., Krogstie, J., Nurcan, S., Proper, E., Schmidt, R., Soffer, P., Ukor, R. (eds.) Enterprise,

123

T. Li et al.

41.

42.

43.

44.

45.

46.

47.

48.

49. 50.

51.

52. 53.

54.

55.

56.

57.

Business-Process and Information Systems Modeling, pp. 367– 380. Springer, Berlin (2009) Lethbridge, T.C., Sim, S.E., Singer, J.: Studying software engineers: data collection techniques for software field studies. Empir. Softw. Eng. 10(3), 311–341 (2005) Li, T., Horkoff, J.: Dealing with security requirements for sociotechnical systems: a holistic approach. In: Advanced Information Systems Engineering (CAiSE 2014), pp. 185–200. Springer, Berlin (2014) Li, T., Horkoff, J., Mylopoulos, J.: Integrating security patterns with security requirements analysis using contextual goal models. In: The Practice of Enterprise Modeling (PoEM 2014), pp. 208– 223. Springer, Berlin (2014) Li, T., Horkoff, J., Mylopoulos, J.: A prototype tool for modeling and analyzing security requirements from a holistic viewpoint. In: The CAiSE’14 Forum at the 26th International Conference on Advanced Information Systems Engineering, pp. 185–192 (2014) Li, T., Horkoff, J., Mylopoulos, J.: Analyzing and enforcing security mechanisms on requirements specification. In: Requirements Engineering: Foundation for Software Quality (REFSQ 2015). Springer, Berlin (2015) Liu, L., Yu, E., Mylopoulos, J.: Security and privacy requirements analysis within a social setting. In: Proceedings of the RE’03, vol. 3, pp. 151–161. Monterey, CA (2003) Massacci, F., Paci, F.: How to select a security requirements method? A comparative study with students and practitioners. In: Jøsang, A., Carlsson, B. (eds.) Secure IT Systems, pp. 89–104. Springer, Berlin (2012) Menzel, M., Thomas, I., Meinel, C.: Security requirements specification in service-oriented business process management. In: Proceedings of International Conference on Availability, Reliability and Security, 2009 (ARES’09), pp. 41–48. IEEE (2009) Mouratidis, H.: Secure software systems engineering: the secure tropos approach. J. Softw. 6(3), 331–339 (2011) Mouratidis, H., Giorgini, P.: A natural extension of tropos methodology for modelling security. In: Proceedings of the Agent Oriented Methodologies Workshop (OOPSLA 2002), Citeseer (2002) Mouratidis, H., Jurjens, J.: From goal-driven security requirements engineering to secure design. Int. J. Intell. Syst. 25(8), 813–840 (2010) NIST: Roadmap for Smart Grid Interoperability Standards, Release 2.0. NIST Special Publication 1108R2 (2012) Paja, E., Dalpiaz, F., Giorgini, P.: Managing security requirements conflicts in socio-technical systems. In: Ng, W., Storey, V.C., Trujillo, J.C. (eds.) Conceptual Modeling, pp. 270–283. Springer, Berlin (2013) Pimentel, J., Lucena, M., Castro, J., Silva, C., Santos, E., Alencar, F.: Deriving software architectural models from requirements models for adaptive systems: the stream-a approach. Requir. Eng. 17(4), 259–281 (2012) Ranjan, P., Misra, A.K.: Agent based system development: a domain-specific goal approach. ACM SIGSOFT Softw. Eng. Notes 31(6), 1–6 (2006) Rodríguez, A., Fernández-Medina, E., Trujillo, J., Piattini, M.: Secure business process model specification through a UML 2.0 activity diagram profile. Decis. Support Syst. 51(3):446–465 (2011) Rodríguez, A., de Guzmán, I.G.R., Fernández-Medina, E., Piattini, M.: Semi-formal transformation of secure business processes into analysis class and use case models: an mda approach. Inf. Softw. Technol. 52(9), 945–971 (2010)

123

58. Runeson, P., Höst, M.: Guidelines for conducting and reporting case study research in software engineering. Empir. Softw. Eng. 14(2), 131–164 (2009) 59. Scandariato, R., Yskout, K., Heyman, T., Joosen, W.: Architecting Software with Security Patterns. Tech. rep, KU Leuven (2008) 60. Schneier, B.: Attack trees. Dr. Dobb’s J. 24(12), 21–29 (1999) 61. Schumacher, M., Fernandez-Buglioni, E., Hybertson, D., Buschmann, F., Sommerlad, P.: Security Patterns: Integrating Security and Systems Engineering. Wiley, New York (2013) 62. Sindre, G., Opdahl, A.L.: Eliciting security requirements with misuse cases. Requir. Eng. 10(1), 34–44 (2005) 63. Souag, A., Mazo, R., Salinesi, C., Comyn-Wattiau, I.: Reusable knowledge in security requirements engineering: a systematic mapping study. Requir. Eng. 21(2), 251–283 (2016) 64. Suleiman, H., Svetinovic, D.: Evaluating the effectiveness of the security quality requirements engineering (square) method: a case study using smart grid advanced metering infrastructure. Requir. Eng. 18(3), 251–279 (2013) 65. TOG: Mapping the togaf adm to the zachman framework (2002). http://www.opengroup.org/architecture/0210can/togaf8/ doc-review/togaf8cr/c/p4/zf/zf_mapping.htm 66. Uzunov, A.V., Fernandez, E.B., Falkner, K.: Engineering security into distributed systems: a survey of methodologies. J. UCS 18(20), 2920–3006 (2012) 67. Uzunov, A.V., Fernandez, E.B., Falkner, K.: Ase: a comprehensive pattern-driven security methodology for distributed systems. Comput. Stand. Interfaces 41, 112–137 (2015) 68. Van Lamsweerde, A., Letier, E.: Handling obstacles in goaloriented requirements engineering. IEEE Trans. Softw. Eng. 26(10), 978–1005 (2000) 69. Yoder, J., Barcalow, J.: Architectural patterns for enabling application security. In: Fourth Conference on Patterns Languages of Programs (PLoP’97) (1997) 70. Yu, E.: Towards modelling and reasoning support for early-phase requirements engineering. In: Proceedings of the Third IEEE International Symposium on Requirement Engineering, pp. 226–235. IEEE Computer Society Press (1997) 71. Zachman, J.A.: A framework for information systems architecture. IBM Syst. J. 26(3), 276–292 (1987) 72. Zave, P., Jackson, M.: Four dark corners of requirements engineering. ACM Trans. Softw. Eng. Methodol. 6(1), 1–30 (1997)

Tong Li holds a lecturer position in the Department of Computer Science at the Beijing University of Technology. He received a Ph.D. degree in Computer Science from the University of Trento in 2016. His thesis, under the supervision of Prof. John Mylopoulos, focused on holistic security requirements modeling and analysis for sociotechnical systems. His research interests are in the areas of security requirements engineering and conceptual modeling, concentrating on the use of goal modeling techniques for designing secure socio-technical systems.

Holistic security requirements analysis for socio-technical systems Jennifer Horkoff is a Postdoctoral Fellow at the Cass Business School, City University, London. She is the holder of a 2-year Marie Sklodowska-Curie Intra-European Fellowships for career development (IEF), working under the supervision of Prof. Neil Maiden. She is also a holder of a Natural Sciences and Engineering Research Council of Canada Postdoctoral Fellowship. Jennifer received her Ph.D. in Computer Science from the University of Toronto, under the supervision of Prof. Eric Yu. She spent 2.5 years at the University of Trento, Italy, as part of the Lucretius: Foundations for Software Evolution project, working with Prof. John Mylopoulos and colleagues. She has been an author or co-author of more than 20 papers in peerreviewed journals, conferences, or workshops. Her research interests lie in enhancing the use of conceptual modeling for requirements engineering and business analysis, focusing on creativity, interactive analysis, uncertainty, scalability, and the application of RE-inspired conceptual modeling to business intelligence. Jennifer has been on program committees and organizing committees of several international conferences, and has been a (co-)organizer of several international workshops.

John Mylopoulos holds a professor emeritus position at the University of Trento, and the University of Toronto. He earned a Ph.D. degree from Princeton University in 1970 and joined the Department of Computer Science at the University of Toronto that year. His research interests include conceptual modelling, requirements engineering, data semantics, and knowledge management. Mylopoulos is a fellow of the Association for the Advancement of Artificial Intelligence (AAAI) and the Royal Society of Canada (Academy of Sciences). He has served as programme/general chair of international conferences in Artificial Intelligence, Databases and Software Engineering, including IJCAI (1991), Requirements Engineering (1997), and VLDB (2004). During the period 2011–2016, Mylopoulos held an advanced grant from the European Research Council for a project titled “Lucretius: Foundations for Software Evolution.”

123