Security breaches in large socio-technical systems cost billions. Many breaches can be attributed to the piecemeal security design, leaving parts of the system vulnerable while others are over-protected. We advocate holistic security design, and have introduced techniques to support security analysis across multiple layers. This paper presents MUSER, a prototype that assists security requirements analysts dealing with security requirements from a holistic viewpoint based on a three-layer framework. Our prototype analyzes security requirements and related security mechanisms in business layer, application layer, and physical layer. The prototype captures the influences of security mechanisms, which one layer enforces on the other layers, and supports deriving holistic security solutions that tackle security concerns in all layers. We demonstrate the usage of MUSER via a smart grid scenario. Keyword: Security Requirements Goal Model Multilayer SocioTechnical System Demo Tool
Socio-technical systems (STSs) are organizational systems consisting of people,
business processes, software applications, and hardware components. As the
complexity of STS increases over time, a growing number of security breaches
are reported [
A common theme for many of these breaches is that security solutions are
dealt with in a piecemeal fashion, in which security analysis carried out in
one part of the system does not take into account security designs in other
parts. For example, when designing an encryption function, a smart meter
application can either implement encryption by itself or depend on an external
component implemented in a specialized chip. If the system is viewed in a
piecemeal fashion, for example, focusing only on the software issues, these two
security mechanisms deliver the same function. However, these two alternatives
have di erent influences on requirements of the physical devices, as the latter
one requires that the related hardware device should not be accessed by
nonauthorized people [
In this paper, we present MUSER (MUltilayer SEcurity Requirements
analysis tool), a prototype that supports analyzing security requirements of STSs
from a holistic point of view, implementing our technique proposed in [
In the reminder of this paper, we first describe our analysis approach in Sec. 2, according to which we design our prototype. Next, we introduce the architecture and functionality of our prototype in Sec. 3, and illustrate the utility of the prototype in Sec. 4. Finally, Sec. 5 concludes the paper. 2
Three-Layer Security Requirement Analysis Approach
Our previous work [
Business Goal Model [S, K ⊢ R] Application Goal Model [S, K ⊢ R] Physical Goal Model [S, K ⊢ R]
Analysis process
Security-Enhanced Business Goal Model
Security-Enhanced Application Goal Model
Asset-based Refinement Rule Content: If an asset consists of sub-assets, a security goal that concerns this asset could be refined to more detailed ones, which focus on the sub-assets.
Datalog Rule: and_re f ined_sec_goalpIMP; SA; AS2; INT; SGq : sec_goalpSGq; importancepIMPq; sec_attributepSAq; assetpAS2q; intervalpINTq; part_o f pAS2; AS1q; assetpAS1q; has_propertiespSG; IMP; SA; AS1; INTq: Graphical Transformation Pattern:
(S) Security attribute [asset 1, interval] Securit(ySa)ttribute asset 1 [asset 1, intervaals]septa2rt-of paart-sosfet 3 [Saescsuertit2(yS,a)intttreibrvuatel] [Saescsuertit3(yS,a)intttreibrvuatel] R, which are satisfied by its own specifications S, under layer-specific domain assumptions K, i.e. S; K $ R. In particular, specifications in one layer dictate requirements in lower layers, indicated in Fig. 1. By capturing the cross-layer interactions and analyzing the requirements problem within each individual layer, our approach aims at dealing with security requirements of STSs from a holistic viewpoint. Taking stakeholder’s high-level security requirements and layer-specific goal models as input, the approach analyzes detailed security requirements throughout the three layers and finally produces holistic security solutions, which tackle security issues in all three layers (Fig. 1).
The approach includes 23 transformation rules, which guide the
corresponding security analysis tasks. Specifically, the rules support refining, simplifying
and operationalizing security goals within individual layers, as well as
transferring security concerns across layers. All of these rules have been implemented in
Datalog [
MUSER (MUltilayer SEcurity Requirements analysis tool) is a prototype, which is designed to support the application of the approach summarized in Sec. 2. The prototype is a Java-based program, which is developed on the top of a specialized and powerful diagramming application OmniGra e 2. Fig. 2 shows the architecture of the prototype, which consists of four components: control, view, model, and inference. We introduce them respectively as below. Control Component controls the logic of the whole prototype and coordinates other components to deliver inference functions to users. When receiving users’ inference requests, it imports related models from the view component, generates a formal model specification in terms of text files, and calls the inference component to carry out corresponding reasoning tasks. According to the reasoning results returned by the inference component, the control component updates related model information and reflects them on the view component. View Component supports users with graphic modeling, as well as shows graphical inference results to users. The main requirements for this component include: 1) support goal-oriented modeling and allow customized notations; 2) support multilayer modeling, i.e. modeling in di erent views; 3) be connected with inference component to support reasoning. Although there are a number of available goal modeling tools, such as Open OME, STS-ml 3, none of them can support 1 http://goo.gl/Pd0TGw 2 http://www.omnigroup.com/omnigra e 3 http://istar.rwth-aachen.de/tiki-index.php?page=i*+Tools
OmniGraffle Modeling
User
Model Information Updated
Model Reasoning Formal Model Specification
Formal Model Specification Inference Result Inference Request
Datalog
Rules DLV Inference
Engine our multilayer goal modeling and reasoning. We choose a specialized modeling application OmniGra e as the view component of our prototype, meeting all requirements. Particularly, this application has many useful modeling features, such as automatic layout, outline view, and various export formats. As we have defined a number of interfaces for the view component, through which it interacts with the control component, the view component can be replaced by other applications that comply with the interfaces.
Inference Component implements the security analysis rules proposed in our
approach and automates corresponding analysis tasks. All the rules are
implemented in terms of Datalog rules and facts. Particularly, we leverage DLV
inference engine [
Functionality Building on the above architecture, we implement a number of functions, which assist the security analysis tasks. As shown in Fig. 3, within one single layer, we first refine and simplify security goals to identify concrete and critical ones. Then, the critical security goals are operationalized into possible security mechanisms and left to security analysts to select. After that, we transfer security concerns downward to its lower layer and iteratively carry out all above security analysis there. The main features of the tool are as follows: – Security Goal Refinement: As a coarse-grained security goal is normally more di cult to analyze and operationalize than a fine-grained one, security analysts need to refine an abstract security goal into sub-goals. The prototype Automatic refinement
Manual refinement
Single-Layer Security Analysis Simplify security goals
Operationaliz e security goals
Select a security alternative Refine security concerns in next layer
Transfer security concerns across layers
No Yes Analysis reaches bottom layer?
Obtain Holistic
security
solutions
legend
User Task
Computeraided Task
Parallel Exclusive
Gateway Gateway
Sequence Flow
supports automatically refining a security goal via any of these three
dimensions: security attribute, asset, and interval. Particularly, it provides two ways
to automate this analysis. First, it supports a single step of refinement with
regard to a particular dimension. Secondly, the prototype could simulate
an exhaustive analysis, which explores all possible refinements for the
target security goals, to cover all related security goals. Not surprisingly, this
simulation could produce a very huge refinement trees, such as shown in
Fig. 5. Thus, this analysis has to rely on simplification analysis for filtering
non-critical security goals.
– Security Goal Simplification: When dealing with a large number of security
goals, analysts may not have enough time to go through each of them to
determine which is critical and requires further treatments. To release analysts
from scrutinizing all security goals, our prototype supports automatic
identification of critical security goals, which takes into account the applicability
and risk level of security goals. For example, if a security goal concerns data
confidentiality of energy production data during the execution of measure energy
consumption, which does not involve with the energy production data, then
this security goal is not applicable and is further identified as non-critical.
In addition, for an applicable security goal, if its risk level is low or medium,
it is identified as non-critical.
– Security Goal Operationalization: To e ectively achieve critical security goals,
our prototype assists analysts in designing security mechanisms based on
existing security patterns [
Current Layer Layer List
Canvas
Customized
Stencil
We demonstrate the utility of our prototype by holistically analyzing the security requirements of a smart grid example. Particularly, we focus on the real-time pricing scenario.
Real-time Pricing Scenario: To continuously provide energy to customers, the energy provider needs to balance the load on the power grid to avoid blackouts. To this end, the provider applies a real-time pricing strategy, which adjusts energy price according to current load of the power grid. This strategy requires periodically collecting customer’s energy consumption data, based on which a new price is calculated. In this scenario, the energy provider highly relies on the integrity of the energy consumption data.
According to the detailed analysis procedure shown in Fig. 3, we use our
prototype to analyze the security requirements for the above scenario. Our
analysis technique will apply to each layer, here we present the security analysis
within the business layer, with steps as follows:
1. Building An Initial Requirements Model: We first build the requirements model
within the business layer, including the high-level security requirements.
Fig. 4 shows the graphical modeling interface, which consists of several key
components that are highlighted in rectangles. The Layer List shows three
canvases that are intended for modeling requirements in the three layers.
A customized stencil is shown in the bottom part of Fig. 4. Elements in the
stencil are used to draw the requirements models, which is presented in the
center of the canvas. Due to space limitation Fig. 4 only shows a part of the
requirements model.
2. Refine High-Level Security Goals: Given the high-level security goal High
Integrity[customer information, Have current load info] (Fig. 4). We use the
prototype to adopt an exhaustive refinement strategy to cover all potential
security concerns introduced by this security goal. Not surprisingly, this
strategy results in a large refinement tree, which contains 72 potential
security goals, shown in Fig. 5. Limited by space, we replace the content of each
(S)
high integrity
[energy production
data, have current
load info]
security goal with its id, and only show the details of one security goal in
the upper right corner.
3. Simplify Security Goals: As the exhaustive refinement analysis generates a
large refinement tree of security goals, which are almost impossible to be
analyzed manually, we use our prototype to automatically identify critical
security goals. As highlighted by the rectangle in Fig. 5, 2 out of 72 security
goals (the filled elements) are identified as critical. Based on these critical
security goals, the prototype follows a bottom-up algorithm to calculate
the best refinement path, which refines the top-level security goal into the
critical ones with minimum steps (the filled elements above the rectangle
in Fig. 5). After this simplification analysis, our prototype can generate a
simplified security goal model, which contains only the critical security
goals and the corresponding best refinement paths.
4. Operationalize Security Goals: Facing the two critical security goals, our
prototype automatically generates four potential security mechanisms for each of
them according to the security patterns [
(S) high data integrity
[energy consumption data, measure energy consumption] (S) secure office help
make (S) auditing help
(S) access control make
(S) cryptograp hic control
(S) Cryptog make raphic control Application SM
Layer Application Encrypt data
(S) high data integrity [energy consumption
data, measure energy consumption]
(S) high Application Integrity [SM Application, Encrypt data] (S) high Application Availability [SM Application, Encrypt
Data]
In this paper, we present MUSER, a prototype for analyzing security
requirements of STSs from a holistic viewpoint. This prototype is designed to
implement our proposed three-layer analysis approach [
Acknowledgements This work is supported by ERC advanced grant 267856, titled “Lucretius: Foundations for Software Evolution”.