=Paper=
{{Paper
|id=None
|storemode=property
|title=A Tool for Managing Evolving Security Requirements
|pdfUrl=https://ceur-ws.org/Vol-734/PaperDemo07.pdf
|volume=Vol-734
|dblpUrl=https://dblp.org/rec/conf/caise/BergmannMPTVY11
}}
==A Tool for Managing Evolving Security Requirements==
https://ceur-ws.org/Vol-734/PaperDemo07.pdf
A Tool for Managing
Evolving Security Requirements?
1 2 2
Gábor Bergmann , Fabio Massacci , Federica Paci ,
3 1 3
Thein Tun , Dániel Varró , and Yijun Yu
1
DMIS - Budapest University of Technology and Economics,
{bergmann,varro}@mit.bme.hu
2
DISI - University of Trento,
{fabio.massacci,federica.paci}@unitn.it
3
DC - The Open University
{t.t.tun,y.yu}@open.ac.uk
Abstract. Requirements evolution management is a daunting process.
Requirements change continuously making the traceability of require-
ments hard and the monitoring of requirements unreliable. Moreover,
changing requirements might have an impact on the security properties a
system design should satisfy: certain security properties that are satis ed
before evolution might no longer be valid or new security properties need
to be satis ed. This paper presents SeCMER, a tool for requirements
evolution management developed in the context of the SecureChange
project. The tool supports automatic detection of requirement changes
and violation of security properties using change-driven transformations.
The tool also supports argumentation analysis to check security proper-
ties are preserved by evolution and to identify new security properties
that should be taken into account.
Keywords: security requirements engineering, secure i*, security argu-
mentation, change impact analysis, security patterns
1 Introduction
Modern software systems are increasingly complex and the environment where
they operate is increasingly dynamic. The number and needs of stakeholders is
also changing constantly as they need to adjust to the changing environment. A
consequence of this trend is that the requirements for a software system increases
and changes continually. To deal with evolution, we need analysis techniques that
assess the impact of system evolution on the satisfaction of requirements such
as security of the system which is very sensitive to evolution: security properties
satis ed before evolution might no longer hold or new security properties need
to be satis ed as result of the evolution.
Another important aspect is the change management process itself which
is a major problem in practice. Changes make the traceability of requirements
?
Work parly supported by the project EU-FP7-ICT-FET-IP-SecureChange.
50 Pre-proceedings of CAISE'11 Forum
hard and the monitoring of requirements unreliable: requirements management
is di cult, time-consuming and error-prone when done manually. Thus, a semi-
automated requirements evolution management environment, supported by a
tool, will improve requirement management with respect to keeping requirements
traceability consistent, realizing reliable requirements monitoring, improving the
quality of the documentation, and reducing the manual eort.
4
In this paper we present SeCMER , a tool developed in the context of the Se-
5
cureChange European project . The tool supports the dierent steps of SeCMER
methodology for evolutionary requirements [4]. The methodology allows to model
requirement evolution in dierent state of the art requirement languages such as
SI* [6], Problem Frames (PF) [9] and SeCMER that is a requirement language
that includes concepts belonging to SI*, PF and security such as asset. The
methodology also supports the automatic detection of requirement changes and
violation of security properties and argumentation analysis [9] to check security
properties are preserved by evolution and to identify new security properties that
should be taken into account. Change driven transformations based on evolution
rules [3] are leveraged to check argument validity, to automatically detect vio-
lations or ful lment of security properties, and to issue alerts prompting human
intervention, a manual analysis or argumentation process, or trigger automated
reactions in certain cases.
In the next section (2) we describe the tool architecture, then we illustrate
the tool features based on an industrial example of evolution taken from the air
tra c management domain (3) and nally conclude the paper (4).
2 SeCMER Tool architecture
SeCMER is an Eclipse-based heterogeneous modeling environment for managing
evolving requirements models. It has the following features (See also Fig. 1):
Modeling of Evolving Requirements. Requirement models can be drawn
in SI*, Problem Frames or SeCMER. Traceability and bidirectional synchro-
nization is supported between SeCMER and SI* requirements models.
Change detection based on evolution rules. Violations of formally de-
ned static security properties expressed as patterns can be automatically
identi ed. Detection of formal or informal arguments that has been invali-
dated by changes aecting model elements that contributed to the argument
as evidence is also supported.
Argumentation-based security analysis. Reasoning about security prop-
erties satisfaction and identi cation of new security properties is supported.
These capabilities of the tool are provided by means of the integration of a
set of EMF-based [7] Eclipse plug-ins written in Java, relying on standard EMF
technologies such as GMF, Xtext and EMF Transaction.
4
A detailed description of the tool implementation is reported in [5]
5
www.securechange.eu
A Tool for Managing Evolving Security Requirements 51
Fig. 1. Models and features in the SeCMER tool
SeCMER integrates Si* [6] as a graphical modeling framework for security
requirements, with OpenPF [8] that supports formal and informal manual ar-
gumentation of security properties. Change detection for security patterns and
evolution rules, as well as the detection of invalidated arguments are performed
using EMF-IncQuery [2].
The core trigger engine plug-in oers an Eclipse extension point for de ning
change-driven rules. Multiple constituent plug-ins contribute extensions to regis-
ter their respective set of rules. The graph pattern-based declarative event/con-
dition feature of the rules is evaluated e ciently (see measurements in [2]) by the
incremental graph pattern matcher plug-ins automatically generated from the
declarative description by EMF-IncQuery . At the commit phase of each EMF
transaction, the rules that are found to be triggered will be executed to provide
their reactions to the preceding changes. These reactions are implemented by
arbitrary Java code, and they are allowed to modify the model as well (wrapped
in nested transactions) and could therefore be reacted upon.
So far, there are three groups of change-driven rules as extension points:
transformation rules that realize the on-the- y synchronization between mul-
tiple modeling formalisms,
security-speci c evolution rules that detect the appearance of undesired se-
curity patterns, raise alerts and optionally oer candidate solutions.
rules for invalidating arguments when their ground facts change.
52 Pre-proceedings of CAISE'11 Forum
A major feature is the a bi-directional synchronizing transformation between Si*
and the SeCMER model with changes propagated on the y, interactively. Since
the languages have dierent expressive power, the following challenges arise:
1. some concepts are not mapped from one formalism to the other or vice versa,
2. some model elements may be mapped into multiple (even an unbounded
amount of ) corresponding model elements in the other formalism, and nally
3. it is possible that a single model element has multiple possible translations
(due to the source formalism being more abstract); one of them is created
as a default choice, but it can later be changed to the other options, which
are also tolerated by the transformation system.
3 Demo Scenario
We are going to illustrate the features supported by our prototype using the
ongoing evolution of ATM systems as planned by the ATM 2000+ Strategic
Agenda [1] and the SESAR Initiative.
Part of ATM system's evolution process is the introduction of the Arrival
Manager (AMAN), which is an aircraft arrival sequencing tool to help manage
and better organize the air tra c ow in the approach phase. The introduc-
tion of the AMAN requires new operational procedures and functions that are
supported by a new information management system for the whole ATM, an
IP based data transport network called System Wide Information Management
(SWIM) that will replace the current point to point communication systems with
a ground/ground data sharing network which connects all the principal actors
involved in the Airports Management and the Area Control Centers.
The entities involved in the simple scenario used for this demo are the AMAN,
the Meteo Data Center (MDC), the SWIM-Box and the SWIM-Network. The
SWIM-Box is the core of the SWIM information management system which
provides access via de ned services to data that belong to dierent domain such
as ight, surveillance, meteo, etc. The introduction of the SWIM requires suitable
security properties to be satis ed: we will show how to protect information access
on meteo data and how to ensure integrity of meteo data.
1. Requirements evolution. We show how SeCMER supports the represen-
tation of the evolution of the requirement model as eect of the introduction
of the SWIM.
2. Change detection based on evolution rules.
a Detection of a security property violation based on security patterns. We
show how the tool detects that the integrity security property of the
resource MD Meteo Data is violated due to the lack of a trusted path.
b Automatically providing corrective actions based on evolution rules. We
show how evolution rules may suggest corrective actions for the detected
violation of the integrity security property.
3. Argumentation-based security analysis. We show how argumentation
analysis [9] can be carried to provide evidence that the information access
property applied to the meteo data is satis ed after evolution.
A Tool for Managing Evolving Security Requirements 53
Fig. 2. Annotated screenshot fragments showing requirements evolution
The steps of the demo were chosen such that they follow a typical require-
ments evolution work ow, also featuring the contributions of WP3.
Requirements evolution. Fig. 2 shows the evolution of the model. The before
model includes two actors the AMAN and MDC : MDC provides the asset Meteo
Data (MD ) to the AMAN. The AMAN has an integrity security goal MDIntegrity
for MD, and MDC is entrusted with this goal. AMAN also performs an Action,
SecurityScreening, to regularly conduct a background check on its employees to
ensure that they do not expose to risk the information generated by the AMAN.
54 Pre-proceedings of CAISE'11 Forum
Listing 1 Pattern to capture violations of the trusted path property
1 shareable pattern
2 noTrustedPath ( ConcernedActor , SecGoal , Asset , UntrustedActor )={
3 Actor . wants ( ConcernedActor , SecGoal );
4 SecurityGoal ( SecGoal );
5 SecurityGoal . protects ( SecGoal , Asset );
6 Actor . provides ( ProviderActor , Asset );
7 find
8 transitiveDelegation ( ProviderActor , UntrustedActor , Asset );
9 neg Actor . trust *( ConcernedActor , UntrustedActor );
10 neg find
11 trustedFulfillment ( ConcernedActor , AnyActor , AnyTask , SecGoal ); }
As the communication between the AMAN and MDC is mediated by the
SWIM, the before model evolves as follows:
The Actors SWIM, SWIMBox_MDC and SWIMBox_AMAN are intro-
duced in the SI* model
As the meteo data is no longer directly provided by MDC to AMAN, the
delegation relation between the two is removed.
Delegation relationships are established between the Actors MDC, SWIM-
Box_MDC, SWIM, SWIMBox_AMAN, AMAN.
As the SWIM network can be accessed by multiple parties, the AMAN has
a new security goal MDAccessControl protecting MD resource.
Detecting violations of security properties based on security patterns. SeCMER
includes facilities that allow for the declarative de nition of security patterns
that express situations that leads to the violation of a security property. For
example, if a concerned actor wants a security goal that expresses that a resource
must be protected, then each actor that the resource is delegated to must be
trusted (possibly transitively) by the concerned actor. An exception is made if a
trusted actor performs an action to explicitly ful ll the security goal, e.g. digital
signature makes the trusted path unneccessary in case of an integrity goal. See
Lst. 1 for the de nition of the pattern using the declarative model query language
of EMF-IncQuery [2].
According to this pattern the integrity property for MD is violated because
AMAN entrusts MDC with the integrity security goal, but the communitation
intermediary actors SWIMBox_MDC, and SWIMBox_AMAN are not.
Automatic corrective actions based on evolution rules. The security pattern in
Lst. 1 can be used to de ne evolution rules that de ne automated corrective
actions to be applied to the model in order to re-establish the integrity security
property. Possibile examples of corrective actions are:
Add a trust relationship between MDC and SWIM Network having the in-
tegrity security goal as dependum.
Alternatively, an Action such as MD is digitally signed can be created to
protect the integrity of MD even when handled by untrusted actors.
A Tool for Managing Evolving Security Requirements 55
Fig. 3. Screenshot fragment showing the argumentation model
Argumentation for the information access property. Fig. 3 shows the dierent
rounds of the argumentation analysis that is carried out for the infomation access
security property applied to MD resource.
The diagram says that the AMAN system is claimed to be secure before
the change (Round #1), and the claim is warranted by be the facts the system
is known to be a close system (F1), and the physical location of the system
is protected (F2). This argument is rebutted in Round #2, in which another
argument claims that the system is no longer secure because SWIM will not
keep AMAN closed. The rebuttal argument is mitigated in Round #3 by three
arguments, which suggest that the AMAN may still be secure given that the
56 Pre-proceedings of CAISE'11 Forum
physical infrastructure is secure, personnel are trustworthy and access to data is
controlled.
4 Conclusions
The paper presented SeCMER, a tool for managing evolving requirements. As
shown by the ATM-based demo scenario, the tool supports visual modeling of se-
curity requirements. Additionally, argument models can be constructed manually
to investigate the satisfaction of security properties; the tool detects invalidated
arguments if the requirements model evolves. Finally, the tool performs contin-
uous and automatic pattern-based security properties violation detection, with
quick x corrective actions speci ed by evolution rules.
We are planning to extend the tool in order to support other set of security
patterns and evolution rules to automate the detection and handling of secu-
rity violations in a wider range of application scenarios. We will also realize a
tighter integration with additional modeling formalisms (Problem Frames ) and
industrial tools e.g DOORS-TREK. The usability and the features of the tool
are going to be evaluated through a study involving ATM-domain experts.
References
1. EUROCONTROL ATM Strategy for the Years 2000+ Executive Summary (2003)
2. Bergmann, G., et al.: Incremental evaluation of model queries over EMF models. In:
Model Driven Engineering Languages and Systems, MODELS'10. Springer (2010)
3. Bergmann, G., et al.: Change-Driven Model Transformations. Change (in) the Rule
to Rule the Change. Software and System Modeling (2011), to appear.
4. Bergmann et al.: D3.2 Methodology for Evolutionary Requirements,
http://www.securechange.eu/sites/default/files/deliverables/D3.2-%
20Methodology%20for%20Evolutionary%20Requirements_v3.pdf
5. Bergmann et al.: D3.4 Proof of Concept Case Tool, http://www.securechange.
eu/sites/default/files/deliverables/D3.4%20Proof-of-Concept%20CASE%
20Tool%20for%20early%20requirements.pdf
6. Massacci, F., Mylopoulos, J., Zannone, N.: Computer-aided support for secure tro-
pos. Automated Software Engg. 14, 341364 (September 2007)
7. The Eclipse Project: Eclipse Modeling Framework, http://www.eclipse.org/emf
8. Tun, T., et al.: Early identi cation of problem interactions: A tool-supported ap-
proach. In: Glinz, M., Heymans, P. (eds.) Requirements Engineering: Foundation
for Software Quality, 15th International Working Conference, pp. 7488. No. 5512
in Lecture Notes in Computer Science, Springer (2009)
9. Tun, T.T., et al.: Model-based argument analysis for evolving security requirements.
In: Proceedings of the 2010 Fourth International Conference on Secure Software
Integration and Reliability Improvement. pp. 8897. SSIRI '10, IEEE Computer
Society, Washington, DC, USA (2010)