USING SECURITY ATTACK SCENARIOS TO ANALYSE
SECURITY DURING INFORMATION SYSTEMS DESIGN
Haralambos Mouratidis
School of Computing and Technology, University of East London, England
Paolo Giorgini
Department of Information and Communication Technology, University of Trento, Italy
Gordon Manson
Department of Computer Science, University of Sheffield, England
Keywords:
Information Systems Analysis, Systems Engineering Methodologies, Security, Scenarios
Abstract:
It has been widely argued in the literature that security concerns should be integrated with software
engineering practices. However
, only recently work has been initiated towards this direction. Most of this
work, however, only considers how security can be analysed during the development lifecycles and not how
the security of an information system can be tested during the analysis and design stages. In this paper we
present results from the development of a technique, which is based on the use of scenarios, to test the
reaction of an information system against potential security attacks.
1 INTRODUCTION
In previous papers, we have presented a process that
allows developers to identify the security
requirements of an information system (Mouratidis,
2003), reason about a suitable architectural style
(Mouratidis, 2003a), and successfully transform
security requirements to design (Mouratidis, 2003b).
However, an important issue is to test how the
sy
stem under devel
opment copes with possible
attacks. Testing is widely considered an important
activity that helps to identify errors in a system and
techniques such as control and data flow testing,
formal specifications, special testing languages, and
test tools have been used for many years in testing
systems, and they are considered valuable solutions
for many projects. However, most of these
approaches are difficult to apply, they require
special training and skills, and they employ their
own concepts and notations (Ryser, 1999).
These requirements usually conflict with many of
the c
haracteristics that a security orie
nted process
should demonstrate, such as to be clear and well
guided, to allow non-security specialists to consider
security issues in the development process and to
employ the same concepts and notations throughout
the development lifecycle of a software system.
This paper presents results from the development
of a
scenario-based
technique to test how an
information system under development copes
against potential security attacks. Section 2 provides
a brief overview of the Tropos methodology
necessary for readers non-familiar with the
methodology. Section 3 discusses our approach by
describing the Security Attack Scenarios, whereas
Section 4 illustrates our approach with the aid of an
example taken from the health care sector. In
Section 5 we present a discussion of related work
and Section 6 presents some concluding remarks and
future work.
2 THE TROPOS METHODOLOGY
Tropos is a development methodology tailored to
describe both the organisational environment of a
system and the system itself.
10
Mouratidis H., Giorgini P. and Manson G. (2004).
USING SECURITY ATTACK SCENARIOS TO ANALYSE SECURITY DURING INFORMATION SYSTEMS DESIGN.
In Proceedings of the Sixth International Conference on Enterprise Information Systems, pages 10-17
DOI: 10.5220/0002599000100017
Copyright
c
SciTePress
Tropos adopts the i* modelling framework (Yu,
1995), which uses the concepts of actors, goals,
tasks, resources and social dependencies for defining
the obligations of actors (dependees) to other actors
(dependers). Actors have strategic goals and
intentions within the system or the organisation and
represent (social) agents (organisational, human or
software), roles or positions (represent a set of roles.
A goal represents the strategic interests of an actor.
In Tropos we differentiate between hard goals
(simply called goals hereafter) and soft goals. Soft
goals represent non-functional requirements and
have no clear definition or criteria for deciding
whether they are satisfied or not (Yu, 1995). An
example of a soft goal is “the system should be
scalable”. A task represents a way of doing
something. Thus, for example a task can be executed
in order to satisfy a goal. A resource represents a
physical or an informational entity while a
dependency between two actors indicates that one
actor depends on another to accomplish a goal,
execute a task, or deliver a resource.
Therefore, in Tropos we consider the system as
an actor, which can be decomposed to sub-actors,
and we delegate to it goals to be satisfied (functional
requirements). In order to satisfy such goals we can
design the system in different ways and these can
have different affect on the non-functional
requirements, such as performance, reliability and
security.
In previous papers (Mouratidis, 2003 –
Mouratidis, 2003a – Mouratidis, 2003b), we have
presented how we extended the Tropos
methodology, by introducing the concepts of
security reference diagram and security constraints
and by redefining existing Tropos concepts such as
secure entities, secure dependencies, and secure
capabilities to enable it to consider security aspects
throughout the whole development process.
A security diagram (Mouratidis, 2002)
represents the connection between security features,
threats, protection objectives, and security
mechanisms that help towards the satisfaction of the
objectives. Security features represent security
related features that the system-to-be must have.
Protection objectives represent a set of principles
that contribute towards the achievement of the
security features. Threats on the other hand represent
circumstances that have the potential to cause loss or
problems that can put in danger the security features
of the system, while security mechanisms identify
possible protection mechanisms of achieving
protection objectives.
A security constraint (Mouratidis, 2002) is
defined as a constraint that is related to the security
of the system, whereas secure entities represent any
secure goals/tasks/resources of the system. Secure
goals are introduced to the system to help in the
achievement of a security constraint. A secure goal
(Mouratidis, 2002) does not particularly define how
the security constraint can be achieved, since (as in
the definition of goal) alternatives can be
considered. However, this is possible through a
secure task, since a task specifies a way of doing
something (Yu, 1995). Thus, a secure task
represents a particular way for satisfying a secure
goal. For example, for the secure goal Authorise
Access, we might have secure tasks such as Check
Password or Check Digital Signatures. A resource
that is related to a secure entity or a security
constraint is considered a secure resource
. For
example, an actor depends on another actor to
receive some information and this dependency
(resource dependency) is restricted by a constraint
Only Encrypted Info.
A secure dependency (Mouratidis, 2003)
introduces security constraint(s), proposed either by
the depender or the dependee in order to
successfully satisfy the dependency. For example a
Doctor (depender) depends on a Patient (dependee)
to obtain Health Information (dependum). However,
the Patient imposes a security constraint to the
Doctor to share health information only if consent is
obtained. Both the depender and the dependee must
agree in this constraint (or constraints) for the secure
dependency to be valid. That means, in the depender
side, the depender expects from the dependee to
satisfy the security constraints while in the dependee
side, a secure dependency means that the dependee
will make an effort to deliver the dependum by
satisfying the security constraint(s).
A secure capability (Mouratidis, 2003b)
represents the ability of an actor to achieve a secure
goal, carry out a secure task and/or deliver a secure
resource. For example, consider an actor that is
responsible for providing cryptographic services in
an information system. This actor should posses
(amongst other) secure capabilities to decrypt
incoming data and encrypt outgoing data.
3 ATTACK SCENARIOS
The popularity of scenarios have been increased
among software engineers and are proven to be
valuable for eliciting information about systems
requirements, communicating with stakeholders and
providing context for requirements (Ryser, 2000).
As a result, scenarios have been applied in many
different areas of computer science research, such as
software engineering (Potts, 1994), business-process
reengineering (Anton, 1994), and user interface
design (Carroll, 1991). In particular, many cases can
USING SECURITY ATTACK SCENARIOS TO ANALYSE SECURITY DURING INFORMATION SYSTEMS
DESIGN
11
be found in the literature (Ryser, 1999 – Ryser 2000
– Lalioti, 1995), where scenarios have been used for
the validation of requirements.
We have decided to choose a scenario-based
approach because scenarios can be easily integrated
within development methodologies and can be
adapted to the methodology’s notation and concepts.
This is due to the fact that scenarios can be
represented in various ways (Ryser, 2000). In this
research, a scenario, called Security Attack Scenario,
is represented as an enhanced Tropos diagram,
which aims to analyse how the system copes in
different kinds of security attacks.
Therefore a scenario should include enough
information about the system and its environment to
allow validation of the system’s security
requirements with respect to particular attacks. As
such, we define a Security Attack Scenario as an
attack situation describing the actors of a software
system and their secure capabilities as well as
possible attackers and their goals, and it identifies
how the secure capabilities of the system’s actors
prevent (if they prevent) the satisfaction of the
attackers’ goals.
The presented approach aims to identify the goals
and the intentions of possible attackers, identify
through these a set of possible attacks to the system
(test cases), and apply these attacks to the system to
see how it copes. By analysing the goals and the
intentions of the attackers the developer obtains
valuable information that helps to understand not
only the how the attacker might attack the system,
but also the why an attacker wants to attack the
system. This leads to a better understanding of how
possible attacks can be prevented. In addition, the
application of a set of identified attacks to the
system contributes towards the identification of
attacks that the system might not be able to cope
(failed test cases) and this leads to the re-definition
of the actors of the system and the addition of new
secure capabilities to enable them to protect against
those attacks.
A Security Attack Scenario involves a possible
attacker, possible attack(s), the resources that are
attacked, and the actors of the system related to the
attack together with their secure capabilities.
An attacker is depicted as an actor who aims to
break the security of the system. The attacker
intentions are modelled as goals and tasks and their
analysis follows the same reasoning techniques that
the Tropos methodology employs for goal and task
analysis. Attacks are depicted as dash-lined links
(called attack links) that contain an “attacks” tag,
starting from one of the attackers goals and ending
to the attacked resource.
For the purpose of a Security Attack Scenario, a
differentiation takes place between internal and
external actors of the system. Internal actors
represent the core actors of the system whereas
external actors represent actors that interact with the
system. Such a differentiation is essential since it
allows developers to identify different attacks to
resources of the system that are exchanged between
external and internal actors of the system.
The process is divided into three main stages:
creation of a scenario, validation of the scenario, and
testing and redefinition of the system according to
the scenario. Even though the presented process is
introduced as a sequence of stages, in reality is
highly iterative and stages can be interchanged
according to the perception of the developers. The
following three sub-sections describe each of those
stages.
3.1 Scenario Creation
There are two basic steps in the creation of a
scenario. The first step involves the identification of
the attackers’ intentions and the possible attacks to
the system and the second step involves
identification of possible countermeasures of the
system to the indicated attacks.
3.1.1 Identify the intentions of a possible
attacker
During the first step, the intentions of an attacker are
analysed in terms of goals and tasks. Some of these
goals can be identified by the threats modelled on
the security reference diagram. For example, a
possible threat to a system could be the application
of cryptographic attacks, i.e. attacks aiming to
modify the content of messages transmitted across
the network. Such a threat could introduce the goal
“perform cryptographic attacks” to a potential
attacker. However, other goals (apart from the ones
introduced by the threats identified in the security
reference diagram) could be derived from the
analysis of a possible attacker’s intentions. This is
due to the fact that an attack is an exploitation of a
system’s vulnerability, whereas a threat is a
circumstance that has the potential to cause loss or
harm (Schneier, 2000). Therefore, an attack can lead
to a threat only if the exploitation of the
vulnerability leads to a threat. This means that some
attacks can be successful but do not lead to threats as
other system features protect the system.
When the analysis of the attacker’s intentions has
been completed, possible attacks to the resources of
the system are indicated using attack links.
ICEIS 2004 - INFORMATION SYSTEMS ANALYSIS AND SPECIFICATION
12
3.1.2 Identify possible countermeasures
The next step in the creation of a security attack
scenario involves the identification of the actors of
the system that posses capabilities to prevent the
identified, from the previous step, attacks.
Secure capabilities can prevent attacks in the
information system in the sense that an actor with
such capabilities can react to the attacks.
Therefore, the actors (internal and external) of the
system related to the identified attack(s) are
modelled. The secure capabilities, of each actor, that
help to prevent the identified attacks are identified
and dashed-links (with the tag “help”) are provided
indicating the capability and the attack they help to
prevent. As an example, consider an internal actor
that depends on an external actor to obtain some
private information. An attacker aims to read the
transmitted data (eavesdropping). However, the
external and the internal actors could have been
assigned with secure capabilities to encrypt any data
transmitted between them. As a result,
eavesdropping becomes very difficult, since the data
is transmitted across the network only encrypted.
3.2 Scenario Validation
When the scenarios have been created, they must be
validated. Therefore, the next stage of the process
involves the validation of the scenario. Software
inspections are proved as effective means for
document-based validation (Kosters, 2001) and as
such are the choice of this research for the validation
of the security attack scenarios. The inspection of
the scenarios involves the identification of any
possible violations of the Tropos syntax and of any
possible inconsistency between the scenarios and the
models of the previous stages. Such an inspection
involves the use of validation checklists. Consider,
for instance, the following checklist.
1. Is a name defined for each scenario?
2. Are actors represented using the correct
notation?
3. Are attack links and help links correctly
denoted?
4. Do the attack scenarios capture all possible
attacks?
5. Do different scenarios exist for the same kind
of attacks?
6. Are there any missing parts on the identified
scenarios? (Any links missing or any actors
missing?)
7. Are there any secure capabilities identified in
the previous stages not present in the scenarios?
8. Are there any actors, identified in the
previous stages, related to the attacks not present
in the scenarios?
9. Are there any threats identified on the
security reference diagram not present on the
scenarios?
10. Are all the resources that can be attacked
present in the scenarios?
11. Are the non-prevented attacks correctly
marked?
It must be noticed that although inspections have
been proposed by this research for the validation of
the security attack scenarios, different techniques
could be applied depending on the developers and
the nature of the system. As an example, validation
techniques to requirements specification are (apart
from inspections) walkthroughs and prototyping
(Kosters, 2001).
When the scenarios have been validated, the next
step aims to identify test cases and test, using those
test cases, the security of the system against the
potential attacks. Each test case is derived from a
possible attack depicted in the security attack
scenarios. For each test case a precondition is
necessary (the state of the system before the attack),
an expected system reaction (how the system reacts
in the attack), and also a discussion that forms the
basis for the decision regarding the test case.
The test cases are applied and a decision is
formed to whether the system can prevent the
identified attacks or not. The decision whether an
attack can be prevented (and in what degree) or not
lies on the developer. However as an indication of
the decision it must be taken into consideration that
at least one secure capability must help an attack, in
order for the developer to decide the attack can be
prevented. Attacks that cannot be prevented are
notated as solid attack links (as opposed to dashed
attack links).
For each attack that it has been decided it cannot
be prevented, extra capabilities must be assigned to
the system to help towards the prevention of that
attack. In general, the assignment of extra secure
capabilities is not a unique process and depends on
the perception of the developer regarding the attack
dangers. However, a good approach could be to
analyse the capabilities of the attacker used to
perform the attack and assign the system with
capabilities that can revoke the attacker’s
capabilities.
4 AN EXAMPLE
To illustrate our approach we apply it to a case study
from the medical area. This case study is part of a
USING SECURITY ATTACK SCENARIOS TO ANALYSE SECURITY DURING INFORMATION SYSTEMS
DESIGN
13
real-life system, called the electronic Single
Assessment Process (eSAP), under development at
the University of Sheffield (Mouratidis, 2003c). The
electronic Single Assessment Process (eSAP) system
is a health and social care information system for the
effective care of older people. To make this example
simpler and more understandable, we consider a
substantial part of the eSAP system.
The application of the Security Attack Scenarios
to the eSAP aims to analyse the security of the
system by considering the intentions of possible
attackers and the secure capabilities that have been
assigned to the actors of the system and provide
recommendations to improve the system’s security.
As derived from the analysis of the eSAP system
(Mouratidis, 2003d), the three main security features
are privacy, integrity and availability. According to
Stallings (Stallings, 1999), the following categories
of attacks can be identified that can put in danger the
above security features.
Interception, in which an unauthorised party,
such as a person, a program or a computer, gains
access to an asset. This is an attack on privacy.
Modification, in which an unauthorised party not
only gains party to but also tampers with an asset.
This is an attack on integrity.
Interruption, in which an asset of the system is
destroyed or becomes unavailable or unusable. This
is an attack on availability.
Due to lack of space in this paper we present only
scenarios regarding interception and interruption
attacks.
Let us first consider an interception attack
scenario in which a possible attacker wishes to
attack the privacy of the system, in other words to
obtain information such as assessment information
or a care plan. As identified in the analysis of the
eSAP system, social engineering, password sniffing
and eavesdropping are the main threats to the
privacy of the system.
Therefore, the attacker’s main goal can be
decomposed to Read Data and Get Access to the
System sub-goals as shown in Figure 1. The first
sub-goal involves the attacker trying to read the data
that it is transmitted to and from the eSAP system,
whereas the second sub-goal involves the attacker
trying to break into the system and gain access to it.
To accomplish the first sub-goal the Attacker
should try to read the data transferred between the
Social Worker and the eSAP system’s actors such as
the Assessment Evaluator and the Authenticator.
To accomplish the second sub-goal, the Attacker
might use password sniffing or social engineering.
In the first case, the Attacker scans all the
resources that flow in the network looking for
passwords whereas in the case of social engineering,
the Attacker tries to deceive the Social Worker in
order to obtain valuable information, such as their
authorisation details that will allow them to gain
access to the system. Therefore, for the presented
attack scenario the reaction of the system should be
tested (amongst other) against three test cases, read
data, password sniffing and social engineering.
Test Case 1: read data
Precondition: The Social Worker actor tries to
obtain an assessment evaluation. The Attacker tries
to read the transmitted data.
System expected security reaction: The
system should prevent Attacker from reading any
(S)Change
Cryptographic
algorithm
(S)
Ask for Consent
(S) Secure
Capability
Fi
g
ure 1: Interce
p
tion attacks scenario
ICEIS 2004 - INFORMATION SYSTEMS ANALYSIS AND SPECIFICATION
14
important information.
Discussion: The Attacker will try to read the
data from any resource transmitted between the
external actors and the eSAP system. However,
curerntly the system and its external actors have
capabilities to encrypt and decrypt data. As a result
all the important data is transmitted across the
network encrypted and therefore it is difficult for
the Attacker to read it. However, the Attacker
might try to obtain (or sometimes even guess) the
encryption key.
Test Case Result: The system is protected
against read data attacks. However, a
recommendation would be for the system to
change the cryptographic algorithm often.
Test Case 2: Password sniffing
Precondition: The Social Worker tries to
obtain access to the eSAP system by providing
their authorisation details. The Attacker tries to
intercept the authorisation details.
System expected security reaction: prevent
attacker from obtaining users’ passwords
Discussion: the main target of the Attacker
would be all the resource transmitions between the
Social Worker and the eSAP system. Currently the
system does not have any kind of protection in this
kind of attack. A good technique to defend against
password sniffing is to use one-time-passwords. A
one-time-password is a password tha is valid for
only one use. After this use, it is not longer valid,
and so even if the
Attacker obtains such a password it is useless.
However, the users must be able to gain access to
the system more than once. This can be
accomplished with, what is commonly known as,
a password list. Each time a user tries to access the
system they provide a different password from a
list of passwords.
Test Case Result: Currently the system fails to
protect against password sniffing attacks. For the
eSAP system to be able to react in a password
sniffing attack, the external actors of the system
(such as the Nurse, the Social Worker, the Older
Person) must be provided with capabilities to
provide passwords from a password list.
Test Case 3: Social engineering
Precondition: The Attacker tries to obtain
system information directly from the Social
Worker.
System expected security reaction: help
towards the prevention of social engineering
Discussion: The Attacker will try to deceive
any external actors (such as the Social Worker in
the presented scenario) into giving any
confidential, private or privileged information. It is
worth mentioning that the Attacker will not
directly ask for this information but they will try to
gain the trust of the actors and then exploit this
trust.
Test Case Result: Currently the system helps
towards the prevention of social engineering by
requesting consent for any information to be
shared. However, this alone does not guarantee the
successful prevention against social engineering. A
primary defence measurement against software
engineering is security awareness training. Good
resistance training will help to prevent actors from
being persuaded to give information away.
As mentioned above, interruption attacks
mainly aim the availability of the system. From an
Attacker’s point of view, such attacks can be
mainly categorised into two main categories,
physical attacks and electronic attacks (Figure 2).
Physical attacks include any attacks to the
infrastructure of the system, whereas electronic
attacks involve attacks such as denial of service
attacks.
Therefore, the Attacker’s main goal (attack
eSAP availability) can be decomposed to physical
and electronic attacks.
Physical attacks involve the cutting of a
communication line, or the destruction of a part of
the system.
On the other hand, one of the most popular
electronic attacks to the availability of a system is
denial of service attacks. Since physical attacks to
the eSAP system are outside the focus of this
research project, only a test case involving a denial
of service attack is considered.
Test Case: denial of service
Precondition: The Attacker tries to make the
eSAP system unavailable by performing a denial
of service attack.
System expected security reaction: the eSAP
should be able to detect the attack and recover.
Discussion: During a denial of service attack,
the Attacker tries to prevent the normal operation
of the communication facilities of the system.
Since a denial of service attack is an active attack,
the main goal of the eSAP system is to detect the
attack and recover from any disruption it may
cause as fast as possible. Towards this direction,
the actors of the system must have capabilities to
operate even if some other actors have become
unavailable. Mostly, denial of service attacks
USING SECURITY ATTACK SCENARIOS TO ANALYSE SECURITY DURING INFORMATION SYSTEMS
DESIGN
15
Figure 2: Interruption attacks scenario
require from Attackers to steal an administration
account of a hose computer in the network.
Therefore, an efficient way to prevent such attacks
is to secure the system. In addition, the Attacker
might make use of spoofed source address. To stop
this, the system must perform filtering mainly
when internal actors communicate with external
ones.
Test Case Results: The eSAP system provides
authorisation mechanisms and therefore helps
towards the effective security of the system and in
turn the prevention of denial of service attacks.
However, filtering is required to make the
protection against denial of service attacks even
better. Therefore, an actor should be introduced to
the system that will perform such filtering.
4.1 Discussion on the use of
scenarios in the eSAP system
In order to test the security of the system, two
different kinds of scenarios were identified
involving four different test cases. By applying
these test cases many useful results were obtained
about the security of the eSAP system. First of all,
it was identified that the system provides enough
protection against some of these attacks. Secondly,
for the attacks that the system did not provided
adequately protection, extra actors and extra secure
capabilities were identified and the following
modifications (amongst other) took place in the
eSAP system.
Capabilities were given to the external actors
as well to the Cryptography Manager to enable
them to change the cryptographic algorithm often.
The lack of such capabilities was identified during
the read data test case of the interception attack
scenario.
The external actors of the system were given
the capability to provide passwords from a
password list, and the Authenticator was given
capabilities to successfully process such
passwords. The lack of such capabilities was
identified by the application of the password-
sniffing test case of the interception attack
scenario.
An actor was introduced to the system to filter
the eSAP in order to help towards the protection of
denial of service attacks. The lack of such an actor
was identified by the application of the denial of
service test case of the interruption security attack
scenario.
5 RELATED WORK
Scenarios have been used in many areas of
software engineering, from requirements
modelling (Potts, 1994) to requirements validation
(Ryser, 2000).
Our idea of analysing the intentions of possible
attackers is similar to the one presented by Liu et
al (Liu, 2002). However, the way that our
scenarios are created, verified and applied is totally
different.
Yu’s work is basically used to identify security
requirements; the Security Attack Scenarios in our
work are used to test the security requirements of
the system identified in the previous development
stages. So a very similar idea is applied in a
different stage of the development lifecycle.
Yu argues that when the intentions of the
attackers are identified we can equip the system
with countermeasures, however it is never
mentioned how we can do this neither provides a
kind of process for providing such
countermeasures.
Moreover, in our approach we consider test
cases, in other words we provide ways to test each
scenario for specific test cases, reason about the
reaction of the system and take a final decision if
the system can react to the specific attack. In cases
that the system cannot react to the attack, possible
countermeasures are discussed and secure
capabilities are introduced to the actors of the
system to satisfy them.
Yu’s analysis takes place in a higher level than
the one proposed by us. Yu proposes the analysis
to take place during the early requirements. This
could be a bit superficial for security since
modelling security requirements as softgoals does
not adequately model security (Mouratidis, 2002).
ICEIS 2004 - INFORMATION SYSTEMS ANALYSIS AND SPECIFICATION
16
In our case, we know the secure capabilities of the
actors of the system (and therefore we have a more
precise idea of what security measurements our
system has) and we can reason about the security
attacks according to those capabilities.
6 CONCLUSIONS AND FUTURE
WORK
In this paper we have presented results from the
development of a scenario-based approach to test
how a software system under development copes
against potential security attacks.
The introduction of security attack scenarios to
test the system’s response to potential attacks
provides developers the ability to realistically
check how the developed system will react to
possible security attacks. This, in turn, allows
developers to re-consider particular system
functions with respect to security until the system
under development satisfies all the security
requirements.
The presented work is part of our efforts aiming
to extend the Tropos methodology in a degree that
will allow developers to successfully consider
security issues during the whole development
lifecycle of an information system.
Therefore, future work includes the full
integration of the presented technique within the
security oriented process of the Tropos
methodology, and its application to more case
studies in order to further assess its validity.
REFERENCES
Anton, A.I., McCracken W.M., Potts C., 1994. Goal
Decomposition and Scenario Analysis in Business
Process Reengineering, Proceedings of the 6
th
Conference on Advanced Information Systems
(CAiSE-1994), The Netherlands.
Carroll, J.M., Rosson, M.B., 1991. Getting Around the
Task-Artifact Cycle: How to Make Claims and
Design by Scenario, IBM Research Report, Human
Computer Interaction, RC 17908 (75365).
Kosters, G., Pagel, B.U., Winter, M., 1997. Coupling
Use Cases and Class Models, Proceedings of the
BCS-FACS/EROS workshop on "Making Object
Oriented Methods More Rigorous", Imperial
College, London-England.
Lalioti, V., Theodoulidis, C., 1995. Visual Scenarios for
Validation of Requirements Specification,
Proceedings of the 7th International Conference on
Software Engineering and Knowledge Engineering
(SEKE'95), Rochville, Maryland-USA.
Liu, L., Yu, E., Mylopoulos, J., 2002. Analyzing
Security Requirements as Relationships Among
Strategic Actors, Proceedings of the 2
nd
Symposium
on Requirements Engineering for Information
Security (SREIS’02), Raleigh-North Carolina.
Mouratidis, H., 2002. Extending Tropos Methodology to
Accommodate Security, Progress Report, Computer
Science Department, University of Sheffield.
Mouratidis, H., 2003d. Analysis and Design of a
Multiagent System to Deliver the Single Assessment
Process for Older People, RANK Report, Computer
Science Department, University of Sheffield.
Mouratidis, H., Giorgini, P., Manson, G., 2003a.
Integrating Security and Systems Engineering:
Towards the Modelling of Secure Information
Systems, Proceedings of the 15
th
Conference on
Advance Information Systems (CAiSE-2003),
Velden-Austria.
Mouratidis, H., Giorgini, P., Manson, G., 2003b.
Modelling Secure Multiagent Systems, Proceedings
of the 2
nd
International Joint Conference on
Autonomous Agents and Multiagent Systems
(AAMAS-2003), Melbourne-Australia.
Mouratidis, H., Giorgini, P., Manson, G., Gani A., 2003.
Analysing Security Requirements of Information
Systems Using Tropos, Proceedings of the 5
th
International Conference on Enterprise Information
Systems (ICEIS-2003), Angers-France.
Mouratidis, H., Philp, I., Manson, G., 2003c. A Novel
Agent-Based System to Support the Single
Assessment Process of Older People, (to appear)
Journal of Health Informatics.
Potts, C., Takahashi, K., Anton A.I., 1994. Inquiry
Based Requirements Analysis, IEEE Software,
March 1994.
Ryser, J., Glinz, M., 1999. A Practical Approach to
Validating and Testing Software Systems Using
Scenarios, Proceedings of the Third International
Software Quality Week Europe (QWE'99), Brussel-,
Belgium.
Ryser, J., Glinz, M., 2000. SCENT - A Method
Employing Scenarios to Systematically Derive Test
Cases for System Test, Technical Report 2000.03,
Institut für Informatik, University of Zurich.
Schneier, B., 2000. Secrets and Lies: Digital Security in
a Networked World, John Willey and Sons.
Stallings, W., 1999. Cryptography and Network
Security: Principles and Practice, Prentice-Hall,
Second Edition.
Yu, E., 1995. Modelling Strategic Relationships for
Process Reengineering, PhD thesis, Department of
Computer Science, University of Toronto, Canada.
USING SECURITY ATTACK SCENARIOS TO ANALYSE SECURITY DURING INFORMATION SYSTEMS
DESIGN
17