Security Meets Software Engineering

ARTICLE IN PRESS

0306-4379/$ - se

doi:10.1016/j.is.

$This is an e

Security and S

Secure Informa

International C

Engineering (Ca

tion Systems E

Springer LNCS�Correspondi

ogy, University

Road, Dagenha

fax: +44-20-82

E-mail addre

paolo.giorgini@

ac.uk (G. Mans

Information Systems 30 (2005) 609–629

www.elsevier.com/locate/infosys

When security meets software engineering: a case of modellingsecure information systems$

Haralambos Mouratidisa,�, Paolo Giorginib, Gordon Mansona

aDepartment of Computer Science, University of Sheffield, UKbDepartment of Information and Communication Technology, University of Trento, Italy

Received 27 February 2004; accepted 7 June 2004

Abstract

Although security is a crucial issue for information systems, traditionally, it is considered after the definition of the

system. This approach often leads to problems, which most of the times translate into security vulnerabilities. From the

viewpoint of the traditional security paradigm, it should be possible to eliminate such problems through better

integration of security and software engineering. This paper firstly argues for the need to develop a methodology that

considers security as an integral part of the whole system development process, and secondly it contributes to the

current state of the art by proposing an approach that considers security concerns as an integral part of the entire

system development process and by relating this approach with existing work. The different stages of the approach are

described with the aid of a real-life case study; a health and social care information system.

r 2004 Elsevier B.V. All rights reserved.

Keywords: Information system design; Requirements analysis; Security engineering

e front matter r 2004 Elsevier B.V. All rights reserve

2004.06.002

xtended and revised version of the ‘‘Integrating

ystems Engineering: towards the Modeling of

tion Systems’’ paper presented at the 15th

onference on Advanced Information Systems

iSE 2003) and published in Advanced Informa-

ngineering, J. Eder and M. Missikiff (Eds.),

2681, 2003.

ng author. School of Computing and Technol-

of East London, Barking Campus, Longbridge

m RM8 2AS, UK. Tel.: +44-20-8223-3315;

23-2963

sses: [email protected] (H. Mouratidis),

dit.unit.it (P. Giorgini), [email protected].

on).

1. Introduction

As information systems (IS) become more andmore critical in every aspect of the human society,from the health sector to military, so does thedemand to secure these systems. This is mainlybecause private information is stored in computersystems and without security, organisations (andindividuals) are not willing to share information oreven use the technology.Consider, for example, a health and social care

information system containing health data of

d.

www.elsevier.com/locate/infosys

ARTICLE IN PRESS

H. Mouratidis et al. / Information Systems 30 (2005) 609–629610

different individuals. Security in such a system, asin any health and social care information system,is very important since security breaches mightresult in medical history to be revealed, andrevealing a medical history could have seriousconsequences for particular individuals.Software Engineers consider security as a non-

functional requirement, but unlike other non-functional requirements, such as reliability andperformance, security has not been fully integratedwithin the development lifecycle and it is stillmainly considered after the design of the system.However, security introduces not only qualitycharacteristics but also constraints under whichthe system must operate. Ignoring such constraintsduring the development process could lead toserious problems [1], since security mechanismswould have to be fitted into a pre-existing design,therefore leading to design challenges that usuallytranslate into software vulnerabilities [2].We believe that security should be considered

during the whole development process and itshould be defined together with the requirementsspecification. By considering security only incertain stages of the development process, morelikely, security needs will conflict with functionalrequirements of the system. Taking security intoaccount along with the functional requirementsthroughout the development stages helps to limitthe cases of conflict, by identifying them very earlyin the system development, and find ways toovercome them. On the other hand, addingsecurity as an afterthought not only increases thechances of such a conflict to exist, but it requireshuge amount of money and valuable time toovercome it, once they have been identified(usually a major rebuild of the system is needed).However, current methodologies for IS devel-

opment do not meet the needs for resolving thesecurity related IS problems [3], and fail to provideevidence of integrating successfully security con-cerns throughout the whole range of the develop-ment process.There are at least two reasons for the lack of

support for security engineering [4]:

1.
Security requirements are generally difficult toanalyse and model. A major problem in
analysing non-functional requirements is thatthere is a need to separate functional and non-functional requirements yet, at the same time,individual non-functional requirements mayrelate to one or more functional requirements.If the non-functional requirements are statedseparately from the functional requirements, itis sometimes difficult to see the correspondencebetween them. If stated with the functionalrequirements, it may be difficult to separatefunctional and non-functional considerations.

2.
Developers lack expertise for secure softwaredevelopment. Many developers, who are notsecurity specialists, must develop systems thatrequire security features. Without an appro-priate methodology to guide those developerson the development processes, it is likely thatthey will fail to produce effective solutions [5].
In this paper we present an approach thatintegrates security and systems engineering, usingthe same concepts and notations, throughout theentire system development process. This work fallswithin the context of the Tropos methodology [6,7]in which security requirements are considered asan integral part of the whole development process.The paper is structured as follows. Section 2

provides an introduction to the Tropos methodol-ogy describing briefly the methodology stages andits concepts. Section 3 describes the securityextensions to the Tropos methodology to enableit to model security issues, whereas Section 4describes a health and social care informationsystem that is used as a case study throughout thepaper. Section 5 illustrates how our approachintegrates security and systems engineering withinthe Tropos development process and Section 6relates our work to the literature by providing anoverview of related work. Finally, Section 7provides directions for future work and it con-cludes the paper.

2. Tropos methodology

Tropos is a development methodology tailoredto describe both the organisational environmentof a system and the system itself. Tropos is

ARTICLE IN PRESS

Fig. 1. Graphical representation of Tropos concepts.

H. Mouratidis et al. / Information Systems 30 (2005) 609–629 611

characterised by three key aspects [6,8]. Firstly, itdeals with all the phases of system requirementsanalysis and system design and implementation1

adopting a uniform and homogeneous way.Secondly, Tropos pays great deal of attention tothe early requirements analysis that precedes thespecification of the perspective requirements,emphasising the need to understand the how andwhy the intended system would meet the organisa-tional goals. This allows for a more refinedanalysis of the system dependencies, leading to abetter treatment not only of the system functionalrequirements but also of its non-functional re-quirements, such as security, reliability, andperformance [8]. Thirdly, Tropos is based on theidea of building a model of the system that isincrementally refined and extended from a con-ceptual level to executable artefacts, by means of asequence of transformational steps [10].Tropos adopts the i* modelling framework [11],

which uses the concepts of actors, goals, tasks,resources and social dependencies for defining theobligations of actors (dependees) to other actors(dependers). Actors have strategic goals andintentions within the system or the organisationand represent (social) agents (organisational, hu-man or software), roles or positions (represent aset of roles). A goal represents the strategicinterests of an actor. In Tropos we differentiatebetween hard (only goals hereafter) and soft goals.The latter having no clear definition or criteria fordeciding whether they are satisfied or not [11]. Atask represents a way of doing something. Thus,for example, a task can be executed in order tosatisfy a goal. A resource represents a physical oran informational entity while a dependencybetween two actors indicates that one actordepends on another to accomplish a goal, executea task, or deliver a resource. Fig. 1a shows thegraphical representation of the above-mentionedconcepts.Because of these concepts, in Tropos, the system

(as well as its environment) is seen as a set ofactors, who depend on other actors to help themfulfil their goals. The type of the dependency

1In this paper we do not consider the implementation stage.

Readers interested in this stage can refer to [9].

describes the nature of an agreement (calleddependum) between dependee and depender. Goaldependencies represent delegation of responsibilityfor fulfilling a goal; softgoal dependencies aresimilar to goal dependencies, but their fulfilmentcannot be defined precisely; task dependencies areused in situations where the dependee is requiredto perform a given activity; and resource depen-dencies require the dependee to provide a resourceto the depender. Fig. 1b illustrates a graphicalrepresentation of a goal dependency.Tropos covers four main software development

phases:Early requirements analysis, concerned

with the understanding of a problem by studyingan existing organisational setting. The output ofthis phase is an organisational model, whichincludes relevant actors, their respective depen-dencies and the security constraints imposed tothose actors.Late requirements analysis, where the

system-to-be is described within its operationalenvironment, along with relevant functions andsecurity requirements; this description models thesystem as a (small) number of actors, which have anumber of dependencies and security constraints.These dependencies define the system’s functionalrequirements, while the security constraints definethe system’s security requirements.Architectural design, where the system’s

global architecture is defined in terms of subsys-tems, interconnected through data and controlflows. Within the framework, subsystems are

ARTICLE IN PRESS


represented as actors and data/control intercon-nections are represented as (system) actor depen-dencies. In addition, during this stage, differentarchitectural styles are analysed taking intoaccount security and other non-functional require-ments of the system and secure capabilities areidentified and assigned to the different actors ofthe system to satisfy the secure entities.Detailed design, where each architectural

component is further defined in terms of inputs,outputs, control, and the security aspects analysedin the previous stages. For this stage, Tropos isusing elements of agent unified modelling language(AUML) [12] to complement the features of i*.

3. The security extensions

Although Tropos was not conceived withsecurity on mind, a set of security concepts, suchas security constraint, secure entities and securedependencies have been proposed [13] to enable itto consider security aspects throughout the wholedevelopment process.To enable developers to adequately capture

security requirements the concept of constraint[13] is introduced and it is extended it with respectto security. In addition, the Tropos concepts ofdependency, goal, task, resource, and capabilityare also extended with security in mind. All theseconcepts are defined within the Tropos project assecure entities.In the context of our work, a security constraint

is defined as a restriction related to security issues,

such as privacy, integrity and availability, of an

information system that it can influence the analysis

and design of the system under development by

restricting some alternative design solutions, by

conflicting with some of the requirements of the

system, or by refining some of the system’s

objectives.A security constraint contributes to a higher

level of abstraction, meaning that security con-straints do not represent specific security protocolrestrictions,2 which restrict the design with the use

2Such security restrictions should be specified during the

implementation of the system.

of a particular implementation language. Thishigher level of abstraction allows for a generaliseddesign free of models biased to particular im-plementation languages.Moreover, the term secure entity is used within

the context of our work to describe goals, tasks,and resources related to the security of the system.In other words, a secure entity represents a securegoal, a secure task or a secure resource.Secure goals are introduced to the system to

help in the achievement of a security constraint. Asecure goal does not particularly define how thesecurity constraint can be achieved, since (as in thedefinition of goal, see [11]) alternatives can beconsidered. However, this is possible through asecure task, since a task specifies a way of doingsomething [11]. Thus, a secure task representsa particular way for satisfying a secure goal. Forexample, for the secure goal Authorise Ac-cess, we might have secure tasks such as CheckPassword or Check Digital Signatures. Aresource that is related to a secure entity or asecurity constraint is considered a secure re-source. For example, an actor depends onanother actor to receive some information andthis dependency (resource dependency) is re-stricted by a constraint Only Encrypted Info.All these security-related concepts are graphicallyrepresented as illustrated in Fig. 2.The only difference in the representation of non-

secure Tropos concepts and secure concepts is an S(Security) within brackets that appears in thebeginning of the security concept description toindicate that the concept is related to the securityof the information system.A secure dependency [13] introduces secur-

ity constraint (s), proposed either by the dependeror the dependee in order to successfully satisfy thedependency. Both the depender and the dependee

Fig. 2. Graphical representation of security-related concepts.

ARTICLE IN PRESS

Fig. 3. Secure dependencies.


must agree for the fulfilment of the securityconstraint in order for the secure dependency tobe valid. That means the depender expects fromthe dependee to satisfy the security constraint (s)and also that the dependee will make an effort todeliver the dependum by satisfying the securityconstraint (s).Secure Tropos differentiates three different

types of secure dependency:

�
A Dependee Secure Dependency, in whichthe depender depends on the dependee and thedependee introduces security constraint (s) forthe dependency.
�
A Depender Secure Dependency, in whichthe depender depends on the dependee and thedepender introduces security constraint (s) forthe dependency.
�
A Double Secure Dependency, in which thedepender depends on the dependee and both thedepender and the dependee introduce securityconstraints for the dependency.
To better understand the concept of securedependency, consider a dependee secure depen-dency where a doctor (depender) depends on apatient (dependee) to obtain health infor-

mation (dependum), and that the patientimposes to the doctor the security constraint toshare health information only ifconsent is obtained. Both the depender andthe dependee must agree in this constraint(or constraints) for the secure dependency to bevalid. That means, the doctor must satisfy theshare health information only if con-sent is obtained security constraint intro-duced by the patient in order to help in theachievement of the Obtain Health informa-tion secure dependency. The different types ofsecure dependency are graphically illustrated inFig. 3.

4. Case study

This section introduces the case study that willbe used in the rest of this paper to describe thesecurity analysis process throughout the differentstages of the Tropos methodology.We consider the electronic Single Assessment

Process (eSAP) system [14], an integrated healthand social care information system for the effectivecare of older people. Security is a very importantfactor in the development of the electronic single

ARTICLE IN PRESS

3For a reminder of the graphical representation of the Tropos

concepts please refer to Fig. 1.


assessment process, since security of personalhealth information is considered a priority bymany health care unions in different countries ofthe world including England. This is due to thefact that in cases where patients (in the case ofthe eSAP older people) do not trust the securityof the system, they will refuse to provide completeinformation about their health and social careneeds, and this could lead to many problems suchas wrong assessment of needs, which could lead towrong care plans.Therefore privacy of health and social care

information, such as the health and social careplans used in the electronic single assessmentprocess, is the number one security concern insuch a system. According to Good MedicalPractice, patients have a right to expect that youwill not pass on any personal information, whichyou learn in the course of your professional dutiesunless they agree. In addition to that, the Englishgovernment and health and social care unionshave agreed that electronic health care recordsshould be at least as well protected as the paperones.Other important concerns are integrity and

availability. Integrity assures that information isnot corrupted and availability ensures the infor-mation is always available to authorised healthand social care professionals. If assessment in-formation is corrupted or it is not available thecare provided to the older people (in the case of theeSAP) by the health and social care professionalswill not be efficient or accurate. Therefore, it isnecessary to find ways to help towards the privacy,the integrity and the availability of personal healthand social care information.It must be noticed that, in our example, many

functionalities of the system are omitted, since ouraim is not to explore the complexity of the system,but rather to demonstrate how the Troposmethodology integrates security and systems en-gineering.Throughout our case study, the security policy

principles identified in [1] are used. In addition,some more principles are added: (1) SystemAuthorisation, only authorised professionals andpatients can access the system; (2) access control,each Care Plan shall be marked with an access

control list naming the people or groups who mayread it and append data to it. The system shouldprevent anyone not on the list from accessing therecord in any way; (3) care plan opening, aprofessional may open a care plan with themselvesand the older person on the access control list.When an older person has been referred, theprofessional might open a record with themselves,the older person, and the referring professional onthe access control list; (4) control, only one of theprofessionals (most likely the professional respon-sible for the older person) may alter the controllist, and add other professionals; (5) informationflow, information derived from care plan A may beappended to care plan B if and only if B’s Accesscontrol list is contained in A’s; and (6) availability,the information must be available whenever aperson included in the access control list requiresany information.

5. The development process

5.1. Early requirements

During the early requirements stage, the goals,dependencies and the security constraints betweenthe stakeholders (actors) are modelled with the aidof an actors’ diagram [8].In such a diagram, actors (graphically repre-

sented as circles) are modelled together with theirgoals (represented as ovals), soft-goals(represented as bubbles), their dependencies(represented as links between the actors indicatingthe dependum3) and their security con-straints (modelled as clouds).In the actor’s diagram, imposed security con-

straints are expressed in high-level statements.For the eSAP case study, we consider the

following actors (see Fig. 4)

�
Professional: the health and/or social careprofessional;
�
Older Person: the older person (patient) thatwishes to receive appropriate health and socialcare;

ARTICLE IN PRESS

Fig. 4. Actors diagram.


�

wh

DoH: the English Department of Health;
� R&D Agency: a Research and DevelopmentAgency interested in obtaining medical informa-tion;
�
Benefits Agency: an agency that helps theOlder Person financially.
The main goal for the Older Person Actor isto Maintain Good Health4 and a secondarygoal is to Receive Appropriate Care. Sincethe Older Person cannot guarantee either ofthose goals alone, they depend on the Profes-sional to help them satisfy them. In addition,the Older Person depends on the BenefitsAgency to Receive Financial Support.However, the Older Person worries about theprivacy of their finances so they impose aconstraint to the Benefits Agency actor, to keeptheir financial information private. The Profes-sional depends on the Older Person to

4It is captured as a soft goal since we cannot precisely define

at ‘‘good health’’ means for different individuals.

Obtain OP (Older Person) Information.However one of the most important and delicatematters for the Older Person is the privacy oftheir personal medical information, and the shar-ing of it. Therefore, most of the times, theProfessional is imposed a constraint toshare this information if and only ifconsent is obtained. On the other hand, oneof the main goals of the R&D Agency is toObtain Clinical Information in order toperform tests and research. To get this informationthe R&D Agency depends on the Profes-sional. However, the Professional is im-posed a constraint (by the Department ofHealth) to Keep Patient Anonymity.When the stakeholders, their goals, the depen-

dencies between them, and the security constraintshave been identified, the next step of this phase isto analyse in more depth each actor’s goals and thesecurity constraints imposed to them. In addition,secure entities are introduced to help towards thesatisfaction of the imposed security constraints. Inthis example, since the paper is focused on the

ARTICLE IN PRESS

Fig. 5. Partial analysis of the professional actor.


secure Tropos and not in Tropos in general, wefocus only in the analysis of the securityconstraints, and not in the goal or taskanalysis of each individual actor.To model this, goal diagrams are used. In a goal

diagram, each actor is represented as a dashed-lineballoon within which the actor’s goals anddependencies are analysed. The nodes of thediagram represent goals, soft-goals, and/ortasks whereas the links identify the differentkinds of relationships between those nodes. More-over, these links can be connected with externaldependencies (identified in the actor diagram)when the reasoning of the analysis goes beyondthe actor’s boundary [11].The analysis of the security constraints starts by

identifying which goals of the actor they restrict.This case is known as security constraintassignment. The assignment of a securityconstraint to a goal is indicated using a con-straint link (a link that has the ‘‘restricts’’

tag). In addition, different alternatives can beconsidered for achieving the goals and the securitygoals of the stakeholders. For example, during theearly requirements analysis (shown in Fig. 4), theProfessional actor has been imposed twosecurity constraints (Share Info Only IfConsent Achieved and Keep Patient Anon-ymity). By analysing the Professional actor(as shown in Fig. 5) we have identified the ShareMedical Info goal. However, this goal isrestricted by the Share Info Only If ConsentObtained constraint imposed to the Profes-sional by the Older Person. For the Pro-fessional to satisfy the constraint, a secure goalis introduced Obtain Older Person Consent.However, this goal can be achieved with manydifferent ways, for example a Professional canObtain the Consent Personally or canAsk a Nurse to obtain the consent on theirbehalf. Thus a sub-constraint is introduced,Only Obtain Consent Personally. This

ARTICLE IN PRESS


sub constraint introduces another secure goalPersonally Obtain Consent. This goal isdivided into two sub-tasks Obtain Consent byMail or Obtain Consent by Phone. TheProfessional has also a goal to ProvideMedical Information for Research. How-ever, the constraint Keep Patient Anonymityhas been imposed to the Professional, whichrestricts the Provide Medical Informationfor Research goal. As a result of this constrainta secure goal is introduced to the Profes-sional, Provide Only Anonymous Info.

5.2. Late requirements

In the late requirements stage, the functional,security, and other non-functional requirementsfor the system-to-be are described. The system-to-be is introduced as one or more actors who have anumber of dependencies with the other actors ofthe organization (defined during the early require-ments stage) and it (the system) contributes to thegoals of the stakeholders.More specifically, from the security point of

view, during the late requirements analysis stage,security constraints are imposed to the system-to-be. These constraints are further analysed andsecurity goals and entities necessary for the systemto guarantee the security constraints are identified.In the presented case study, one of the main

aims of the Department of Health is to allowolder people to get more involved in their care andalso help professionals provide more efficient care.For this reason, the Department of Healthdepends on the electronic Single Assess-ment Process (eSAP) system to automate care.Therefore, the eSAP system has been introduced

as another actor that receives the responsibility forthe fulfilment of some of the goals identifiedduring the early requirements analysis for theactors of the system. In other words, some goalsthat the actors of the system cannot fulfil or arebetter fulfilled by the eSAP system are delegated tothe eSAP System.To satisfy all the delegated dependencies, the

main goal of the eSAP system has been identifiedas to Automate Care. By performing a means-end analysis, presented in Fig. 6, it was identified

that for the eSAP System to fulfil the AutomateCare goal, the following sub-goals must beaccomplished: Assist with Assessment Pro-cedures, Provide Older Person Informa-tion, Manage Care Plans and ScheduleMeetings.Each of those sub-goals can be furthered

analysed employing means-end analysis. For ex-ample, the Manage Care Plans goal can beaccomplished with the fulfilment of the GenerateCare Plan, Manage Care Plan Updates,Provide Care Plan Information, ManageReferrals and Identify Care Assistantssub-goals.From the security point of view, and taking into

consideration the security policy (presented in theprevious section) there are three main securityconstraints imposed, by the desired securityfeatures of the system Privacy, Integrityand Availability, to the eSAP’s main goal.These are Keep System Data Private,

Keep Integrity of the Data and MaintainData Availability. In addition, the eSAPsystem must satisfy the Share InformationOnly if Consent Obtained security constraintimposed to the eSAP by the secure dependenciesdelegated by the other actors.Each of these secure constraints can be satisfied

with the aid of one or more secure goals. Forexample, the Keep System Data Privatesecurity constraint can be fulfilled by blockingaccess to the system, by allowing access only froma central computer, or by ensuring system privacy.However, the two first contribute negatively to theusability of the system, i.e. the system will besecure but it will not be used. On the other hand,the Ensure System Privacy secure goal isconsidered the best solution since it providessecurity to the system and it doesn’t affect(dramatically) its usability.Thus, for the eSAP to satisfy its security

constraints the following secure goals havebeen identified as shown in Fig. 6 EnsureSystem Privacy, Ensure Data Integrity,Ensure Data Availability and EnsureConsent has been Obtained. These can befurthered analysed. For example, the EnsureSystem Privacy goal is further analysed into

ARTICLE IN PRESS

Fig. 6. eSAP analysis.

5To avoid confusion we must note that architectural styles

differ from architectures in that ‘‘a style can be thought of as a

set of constraints on an architecture’’ [16, p. 13].


the Perform Authorisation Checks andPerform Cryptographic Procedures securegoals. Both of those goals must be fulfilled for theEnsure System Privacy goal to be satisfied.Each of those tasks can be achieved by

considering different alternatives. For example,in order to check authorisation differentalternatives can be considered such as checkpasswords, check biometrics or checkdigital signatures. An approach to evaluatethe different alternatives could be to use themeasures of complexity and criticality[15]. Complexity represents the effort requiredfrom an actor for achieving a (security) task, whilecriticality represents how the (security) goalsof the actor will be affected if a (security) task isnot achieved. Thus, by knowing how complex andhow critical the different alternatives are, we candecide which alternative is the best solution.

5.3. Architectural design

The architectural design phase defines thesystem’s global architecture. During architecturaldesign the first step is to identify the overallarchitectural organization by selecting amongalternative architectural styles5 using as criteriathe non-functional requirements of the systemidentified in the previous stage.However, quality characteristics (non-functional

requirements) are difficult to measure since it isdifficult to get empirical evidence during the designstages. Nevertheless, a technique is required toallow developers to reason about alternative

ARTICLE IN PRESS


design solutions according to the security require-ments of their system.For this reason, we have developed an analysis

technique to enable developers to select amongalternative architectural styles using as criteria thenon-functional requirements of the multiagentsystem under development.Our analysis process is based on an independent

probabilistic model, which uses the measure ofsatisfiability proposed by Giorgini et al. [17].In our example, satisfiability represents theprobability that the non-functional requirementwill be satisfied. Thus, the evaluation results incontribution relationships from the architecturalstyles to the probability of satisfying the non-functional requirements of the system identified inthe late requirements stage.To express the contribution of each style to the

satisfiability of each non-functional requirement ofthe system, a weight is assigned. Weights take avalue between 0 and 1. For example, 0.1 means theprobability that the architectural style will satisfythe non-functional requirement is very low (thestyle is not suitable for satisfying the requirement).On the other hand, a weight of 0.9 means theprobability that the architectural style will satisfythe non-functional requirement is very high (thestyle is suitable for satisfying the requirement).The analysis involves the identification of more

specific non-functional requirements, by refiningthe ones identified during the late requirementsstage, and the evaluation of different architecturalstyles against those requirements. It must be noticedthat the refinement of the security requirementstook place during the late requirements analysiswith the identification of secure tasks, so from thesecurity point of view, the alternative architecturalstyles are evaluated against those tasks.In the eSAP system, the security of the system is

one of the most important factors and it is thecriterion that will guide the selection process, inthis example, for the appropriate architecturalstyle. As derived from the analysis of the eSAP,security is decomposed to privacy, integrity andavailability.We consider two architectural styles for our

analysis, a hierarchical style—client/ser-ver—and a mobile code style—mobile agents.

We decided to consider those two since client/server is the most frequently encountered of thearchitectural styles for network-based applications[18], while mobile agents form a growing andquite different architectural style. In client/serverstyle, a node is acting as a server that represents aprocess that provides services to other nodes,which act as clients. The server listens for requestsupon the offered services. The basic form of client/server does not constrain how application state ispartitioned between client and server components[18]. Client/server architectural style is also re-ferred to by the mechanisms used for theconnector implementation such as remote proce-dure call (RPC) [18]. RPC is appropriate for client/server architectural styles since the client can issuea request and wait for the server’s response beforecontinuing its own processing. On the other side,in mobile agents style, mobility is used in order todynamically change the distance between theprocessing and source of data or destination ofresults. The computational component is moved tothe remote site, along with its state, the code itneeds and possibly some data required to performthe task [18].As shown in Fig. 7, each of the two styles

satisfies differently each of the non-functionalrequirements of the system.For instance, the mobile agents style allows

more scalable applications (weight 0.8), because ofthe dynamic deployment of the mobile code. Forexample, a doctor wishes to access a large numberof medical information, filtered according to thecontent. In the (pure) client/server architecturalstyle (weight 0.4), the doctor would accessthe server data (medical information) and all theretrieved information would be transferred tothe client. Then the filtering would be performedat the doctor site. In the mobile agents architec-tural style, such a filtering can be performed in theserver site, where redundant information can beidentified early and thus does not have to betransferred to the client. The latter approach ismore scalable since the required filtering isdistributed and can be performed close to theinformation sources.As concluded from our analysis (illustrated in

Fig. 7), the client/server style satisfies more the

ARTICLE IN PRESS

Fig. 7. Selecting amongst different architectural styles.


privacy requirements of the system than themobile agents style. This is mainly becausemobility is involved in the mobile agents style.Therefore, although protection of a server frommobile agents, or generally mobile code, is anevolution of security mechanisms applied in otherarchitectural styles, such as client/server; themechanisms focused on the protection of themobile agents from the server cannot, so far,prevent malicious behaviour from occurring butmay be able to detect it [19]. Consider for example,the Check Information Flow secure task ofthe eSAP. The information flow property is moreeasily damaged by employing mobile agents(weight 0.4) since possible platforms that a mobileagent could visit might expose sensitive informa-tion from the agent [19,20]. In the case of theclient/server style (weight 0.8) sensitive informa-tion is stored in the server and existing well-provensecurity measures could be taken to satisfy theinformation flow attribute.On the other hand, the mobile agents style

satisfies more, than the client/server style, theavailability requirements of the system. Considerfor example the recoverability secure task ofthe eSAP. The mobile agents style contributes with

a weight of 0.8. This is due to the fact that mobileagents adapt dynamically. Mobile agents can reactto changes in their environment and maintain anoptimal configuration for solving a particularproblem [21].From the integrity point of view, the client/

server style contributes better than the mobileagents style. In the mobile agents style mobility isinvolved and therefore checking the integrity ofthe data becomes a more difficult task. This isbecause mobile agents cannot prevent a maliciousagent platform from tampering with their code,state or data, but they can only take measures todetect this tampering [19,20]. Moreover, in themobile agent style, the integrity of both the localand remote agent platforms must be checked.From the above, it can be concluded that

the client/server styles contributes more towardsthe privacy and integrity of the eSAP, whereas themobile agents style contributes more towards theavailability.It is worth mentioning that the weights of

the contribution links reported in Fig. 7, ofeach architectural style to the different non-functional requirements of the system, have beenassigned after reviewing different studies [16,22],

ARTICLE IN PRESS


evaluations [18], and comparisons [23] involvingthe architectural styles. We must also note thatFig. 7 represents a partial illustration of thecomparison process. For example, we haveomitted, in order to keep the figure simple andeasy to understand, the contributions and theconflicts amongst the different non-functionalrequirements. For example, although privacycontributes negative to the mobility requirement,this is not shown in the figure.When the contribution weights for each archi-

tectural style to the different non-functionalrequirements of the system have been assigned,the best-suited architectural style is decided. Thisdecision involves the categorization of the non-functional requirements according to the impor-tance to the system and the identification of thearchitectural style that best satisfies the mostimportant non-functional requirement using apropagation algorithm, such as the one presentedby Giorgini et al. [17].In our example, privacy and integrity are

more important (in the case of the eSAP) thanavailability (most of the times, not real-timeinformation is needed). As a result, the client/server style has been chosen as the architecturalstyle of the system.In the case that two or more non-functional

requirements are of the same importance, thepresented approach can be integrated with otheranalysis techniques, such as the SAAM [24], toindicate which architectural style is best suited forthe system-to-be.As mentioned by Castro et al. [7], an interesting

decision that comes up during the architecturaldesign is whether fulfilment of an actor’s obligationswill be accomplished through assistance from otheractors, through delegation, or through decomposi-tion of the actor into component actors. Thus, whenvarious architectural styles have been evaluated, andone has been chosen, the next step of the architec-tural design stage involves the introduction of newactors and their dependencies, as well as thedecomposition of existing actors into sub-actorsand the delegation of some (security) responsibilitiesfrom the existing actors to the introduced sub-actors.In the presented example, the eSAP actor is

decomposed, as shown in Fig. 8, to internal actors

and the responsibility for the fulfilment of theeSAP’s goals is delegated to these actors.For instance, the Evaluate Assessment

Information goal is delegated to the Assess-ment Evaluator, whereas the Provide As-sessment Information goal is delegated tothe Assessment Broker. In addition, the Old-er Person Broker and the Consent Manageractors have been introduced to the eSAP system tofulfil the responsibility (identified during the laterequirements analysis—see Fig. 6) of the eSAPsystem to satisfy the secure dependency Obtain

Older Person Information together with theShare Information Only if Consent Ob-tained security constraint.Moreover, the eSAP delegates responsibility

(see Fig. 8) for the fulfilment of the PerformAuthorisation Checks security goal tothree new actors, the eSAP Guard (delegatedthe Check Information Flow secure task),the Authenticator (delegated the CheckAuthentication secure task), and theAccess Controller (delegated the CheckAccess Control secure task) as shown inFig. 8.In addition, the Tropos methodology introduces

extended actor diagrams, in which the new actorsand their dependencies with the other actors arepresented. Consider for instance, the extendeddiagram with respect to the Assessment Eva-luator actor, as depicted in Fig. 9. TheAssessment Evaluator has been delegatedthe responsibility to satisfy the goal EvaluateAssessment Information. To fulfil this goal,the Assessment Evaluator depends on twointernal actors, the Assessment Analyser andthe Evaluation Synthesiser. The first isresponsible for obtaining the Assessment In-formation secure resource, identify the pro-blems of the Older Person according to theAssessment Information and provide theProblems to the Evaluation Synthesi-ser. The latter is responsible for obtaining theEvaluation Request, and the Problems andproviding the Assessment Evaluation secureresource to the actor requesting the information(in the presented analysis to the Social Worker)after considering the Problems, the Available

ARTICLE IN PRESS

Fig. 8. eSAP decomposition.


Professionals, the Required Skills andthe Proposed Actions resources.Each of those actors can be furthered decom-

posed to model more precisely the actor’s goalsand how the actor will achieve these goals. Forinstance, the Assessment Synthesiser sub-actor of the Assessment Evaluator, can befurthered analysed as shown in Fig. 10. The maingoal of the Assessment Synthesiser is toProvide an Assessment Evaluation.To satisfy this goal, the Assessment Eva-

luator has to synthesise any information relatedto the assessment. To achieve this, the Assess-ment Evaluator must obtain the problemsassociated with the assessment, the proposedactions required to deal with the identifiedproblems, the skills required to carry out theseactions, and the available professionals thatdemonstrate the required skills. However, theAssessment Evaluator cannot achieve these

tasks without help. Therefore, the AssessmentEvaluator depends on the Assessment Ana-lyser, the Actions Manager, the SkillsManager and the Professional DatabaseManager respectively to satisfy the above men-tioned tasks.The last step of the architectural design aims to

identify capabilities for each of the actors bytaking into account dependency relationships ofthe actors. A capability represents the ability of anactor of defining, choosing and executing a planfor the fulfilment of a goal, given certain worldconditions and in presence of a specific event [8].For example, the Assessment Evaluatorshould have capabilities such as get assessmentinformation, get proposed actions, and Provideassessment evaluation. However, the process ofidentifying capabilities for each actor has beenextensively described in the literature [6,8,25] andthus it is not described here.

ARTICLE IN PRESS

Fig. 9. An example of an extended diagram.

Fig. 10. Analysis of the assessment evaluator.


From the security point of view, secure cap-abilities are introduced to the actors to guaranteethe satisfaction of the security constraints. Asecure capability represents the ability of an

actor/agent to achieve a secure goal, carry out asecure task and/or deliver a secure resource.For example, as identified in the early require-

ments analysis, for the eSAP system to satisfy the

ARTICLE IN PRESS


Ensure System Privacy secure goal, onlyencrypted data transfers across the network shouldbe allowed. Therefore, the Assessment Infor-mation resource sent from the Professionalto the Assessment Analyser (as illustrated inFig. 9) must be encrypted. Because of this, theProfessional actor should be provided withcapabilities to encrypt and decrypt data. Later inthe detailed design, each agent’s capabilities arefurther specified and then coded during theimplementation phase.

5.4. Detailed design

During the detailed design each component ofthe system, identified in the previous stages, isfurther specified. In Tropos the detailed designstage is based on the specifications resulted fromthe architectural design stage, and the reasons fora given component can be traced back to the earlyrequirements analysis. In particular, from thesecurity point of view, during the detailed designthe developers specify in detail the actors’ cap-abilities and interactions taking into account thesecurity aspects derived from the previous steps ofthe analysis.

Evaluate AssessmentEvaluation

Accept AssessmentEvaluation

IE: (Assessment Evaluation Valid)

EE: Recei

Fig. 11. Capability diagram for the receiv

For the detailed design stage, Tropos adapts asubset of the AUML diagrams proposed in [12].These are:

�

IE:(

ve (

e a

Capability Diagrams. We use AUMLactivity diagrams to model a (secure) capabilityor a set of capabilities for a specific actor. Ineach capability diagram, the starting state isrepresented by external events, activity nodesmodel plans, transition arcs model events, andbeliefs are modelled as objects. For instance, inour case study, the Receive AssessmentEvaluation capability (see Fig. 9) of theProfessional actor is illustrated in Fig. 11.The Professional receives (external event –EE) the Assessment Evaluation from theeSAP System. She/he then evaluates the As-sessment Evaluation and either accepts itor rejects it.

�
Plan Diagrams. Plan Diagrams are used tofurther specify each plan node of a capabilitydiagram. Fig. 12 illustrates the plan diagram forthe Evaluate Assessment Evaluationplan belonging to the capability depicted in thediagram of Fig. 11. The plan is activated withthe receipt of the Assessment Evaluationfrom the Professional and it ends by
Reject AssessmentEvaluation

Assessment Evaluation Invalid)

eSAP, Professional, Assessment Evaluation)

ssessment evaluation capability.

ARTICLE IN PRESS

EE: Receive (eSAP, Professional, Assessment Evaluation)

Decrypt AssessmentEvaluation

CheckIntegrity

Not Valid AssessmentEvaluation

Valid AssessmentEvaluation

Read AssessmentEvaluation

Not Encrypted

Integrity Check Failed

Assessment Evaluation not Readable

Fig. 12. Plan diagram example.


deciding if the Assessment Evaluation isvalid or invalid (In addition the plan can beterminated if Assessment Evaluation isnot readable). The integrity of the Assess-ment Evaluation is checked. If the check issuccessful the Assessment Evaluation isreceived as Valid, else the AssessmentEvaluation is considered Invalid fromthe Professional.

�
Agent Interaction Diagrams. We applyin our case sequence diagrams modelling agentInteraction Protocols as proposed by [16]. Anexample of an Agent Interaction Diagram isshown in Fig. 13. This diagram illustratesinteractions (illustrated as arrow-lines) betweenthe Professional, the eSAP Guard, theCryptography Manager and the Authen-ticator agents (graphically illustrated asrectangles at the top of the diagram). TheProfessional sends a system access requestto the eSAP Guard. The eSAP Guard decryptsthe incoming request (with the aid of theCryptography Manager) and checks if theProfessional has authentication clearance(with the aid of the Authenticator).
However, it would be useful to denote underwhat constraints authentication clearance and

system access are granted. For our example, theAuthenticator provides authentication clear-ance if the details of the Professional arevalid, and the eSAP Guard provides access to theeSAP system if authentication clearance is pro-vided. To indicate these constraints, we introducesecurity rules. These are similar to the businessrules that UML has for defining constraints on thediagrams. Graphically, security rules are placed onNotes and attached to the related structure asshown in Fig. 13.

6. Related work

Literature provides only few approaches inconsidering security requirements as anintegral part of the whole software developmentprocess.Chung applies a process-oriented approach [26]

to represent security requirements as potentiallyconflicting or harmonious goals and using themduring the development of software systems. Theproposed framework, which is called the NFR(Non-Functional Requirements) framework, re-presents and uses security requirements as a classof non-functional requirements and it allowsdevelopers to consider design decisions and relate

ARTICLE IN PRESS

Professional eSAP Guard CryptographyManager

Authenticator

eSAP Access Request

Send Encrypted Request

Plain Text Request

Send Authentication Request

Ask for Authentication Details

Provide Authentication Details

Authentication Clearance

eSAP Access Reply

IF authentication DetailsValid then Provide Clearance ELSE RejectAuthentication Clearance

IF AuthenticationClearance isProvided then Accept SystemAccess RequestELSE RejectSystem Access Request

Fig. 13. An example of an agent interaction diagram including security rule notation.


these decisions to the represented non-functionalrequirements.Rohrig [27] proposes an approach to re-use

existing business process descriptions for theanalysis of security requirements and the deriva-tion of necessary security measures. The proposedapproach consists of four main steps. During thefirst step, the general security objectives of thebusiness process are defined, whereas duringthe second step the security objectives of all theconstructs, such as actors and artefacts, areexamined. The third step examines whether thesespecifications are consistent and during the fourthstep a list of necessary security measures for eachprocess component is generated.In addition, Jurgens proposes UMLsec [28], an

extension of the Unified Modelling Language(UML), to include modelling of security relatedfeatures, such as confidentiality and access control.In his work, Jurgens uses four different UMLdiagrams; class diagrams to ensure that exchangeof data obeys security levels, state-chart diagrams

to prevent indirect information flow from high tolow values within an object, interaction diagramsto ensure correctness of security critical interac-tions between objects and deployment diagrams toensure that security requirements on communica-tion are met by the physical layer.Lodderstedt et al. [29] also extend UML to

model security. In their work, they present asecurity modelling language called SecureUML[29]. They describe how UML can be used tospecify information related to access control in theoverall design of an application and how thisinformation can be used to automatically generatecomplete access control infrastructures.McDermott and Fox adapt use cases [5] to

capture and analyse security requirements, andthey call the adaption an abuse case model [5]. Anabuse case is defined as a specification of a type ofcomplete interaction between a system and one ormore actors, where the results of the interactionare harmful to the system, one of the actors, or oneof the stakeholders of the system [5].

ARTICLE IN PRESS


Sindre and Opdahl [30] define the concept of amisuse case, the inverse of a use case, whichdescribes a function that the system should notallow. They also define the concept of a mis-actoras someone who intentionally or accidentallyinitiates a misuse case and whom the systemshould not support in doing so. In their approachsecurity is considered by analysing security relatedmisuse cases.The concept of obstacle is used in the KAOS

framework [31] to capture undesired properties ofthe system, and define and relate security require-ments to other system requirements. In this work,two set of techniques, based on a temporal logicformalisation, are employed to reason aboutobstacles to the satisfaction of goals, requirements,and assumptions elaborated in the requirementsengineering process.These (above-mentioned) approaches provide a

first step towards the integration of security andsoftware engineering and have been found helpfulin modelling security requirements. However, theyonly guide the way security can be handled withina certain stage of the software developmentprocess. For example, McDermott and Fox’sapproach is used only during the requirementsanalysis, whereas Jurgen’s analysis take place in afairly low level and it is suited to a moreoperational analysis. In other words, Jurgen’sapproach is only applicable during the designstage.Differently than them, this paper proposes an

approach that covers the whole developmentprocess using the same concepts and notations.As mentioned in the Introduction, consideringsecurity issues throughout the development pro-cess helps to limit the cases of conflict, byidentifying them very early in the system develop-ment, and find ways to overcome them.Moreover, some of the above mentioned

approaches only deal with specific security issues.For example, UMLSec is focused more in accesscontrol policies and how these policies can beintegrated into a model-driven software develop-ment process. Although such an analysis isimportant, it is very specific and it is applicableonly on the design stage of the modelling process.In contrast, the approach presented in this paper

considers the whole range of security issues, fromaccess control to authentication and integrity.In addition to the above approaches, existing

formal methods [9,32] support the verification of asecurity protocol, which has already been specified[33]. However, such approaches are only applic-able by security specialists and cannot be easilyapplied by software developers. On the otherhand, the approach presented in this paper usesconcepts and notations derived mainly from therequirements engineering area and as a result canbe applied by software developers with minimumknowledge of security engineering.It is worth mentioning that the technique

presented for the evaluation of the differentarchitectural styles, is similar to the evaluationprocess for organisational styles proposed by Kolpet al. [34]. The main difference is that Kolp’sprocess is based on a qualitative reasoning, whilethe technique proposed by this research is basedon an independent probabilistic model, which usesthe measure of satisfiability proposed by Giorginiet al. [17].

7. Conclusions and future work

Although Security is an important issue in thedevelopment of information systems, currently thecommon approach towards the inclusion ofsecurity within a system is to identify securityrequirements after the definition of a system.However, as pointed earlier, this approach leadsmany times to problems and systems full ofsecurity vulnerabilities. It should be possible toeliminate such problems through the integration ofsecurity concerns at every phase of the systemdevelopment. To achieve this goal, methodologiesmust provide developers (even those not expert onsecurity) guidance through a systematic process,which will integrate security and systems engineer-ing at every phase of the system developmentcycle.The main contribution of this paper is the

introduction of a process that integrates securityand systems engineering, using the same conceptsand notations, in the entire system developmentprocess. The integrated, in Tropos, security

ARTICLE IN PRESS


process is one of analysing the security needs of thestakeholders and the system in terms of securityconstraints imposed to the system and thestakeholders, identify secure entities that guaran-tee the satisfaction of the security constraints andassign capabilities to the system to help towardsthe satisfaction of the secure entities. The pre-sented approach is characterised by five key ideas.Firstly by considering the overall software devel-opment process it is easy to identify securityrequirements at the early requirements stage andpropagate them until the implementation stage.This introduces a security-oriented paradigm tothe software engineering process. Secondly, Tro-pos allows a hierarchical approach towardssecurity. Security is defined in different levels ofcomplexity, which allows the software engineer abetter understanding while advancing through theprocess. Thirdly, iteration allows the re-definitionof security requirements in different levels there-fore providing a better integration with systemfunctionality. Fourthly, consideration of the orga-nisational environment facilitates the understand-ing of the security needs in terms of the securitypolicy. In addition, functional and non-functionalrequirements are defined together however a cleardistinction is provided.However, this work is by no means complete.

Future work includes providing a process to verifythe security of the developed information systemsduring the design stage and also applying ourprocess to different case studies to refine it. Wealso aim to integrate our extensions to the FormalTropos [35] specification language to enable us toformally evaluate it. The formal part of the workwill also allow us to prove and check the propertiesof the system.

References

[1] R. Anderson, Security Engineering: A Guide to Building

Dependable Distributed Systems, Wiley Computer Pub-

lishing, New York, 2001.

[2] W. Stallings, Cryptography and Network Security: Prin-

ciples and Practice, second Ed., Prentice-Hall, Englewood

Cliffs, NJ, 1999.

[3] T. Tryfonas, E. Kiountouzis, A. Poulymenakou, Embed-

ding security practices in contemporary information

systems development approaches, Inform. Manage. Com-

put. Secur. 9 (4) (2001) 183–197.

[4] B. Lampson, Computer Security in the real world, Annual

Computer Security Applications Conference 2000.

[5] J. McDermott, C. Fox, Using abuse care models for

security requirements analysis, Proceedings of the 15th

Annual Computer Security Applications Conference,

December 1999.

[6] P. Bresciani, P. Giorgini, F. Giunchiglia, J. Mylopoulos,

A. Perini, TROPOS: an agent-oriented software develop-

ment methodology, J. Autonomous Agents Multi-Agent

Systems 8 (3) (2004) 203–236.

[7] J. Castro, M. Kolp, J. Mylopoulos, A Requirements-

driven development methodology, Proceedings of the 13th

International Conference on Advanced Information Sys-

tems Engineering (CAiSE’01), Interlaken, Switzerland,

June 2001.

[8] A. Perini, P. Bresciani, P. Giorgini, F. Giunchiglia, J.

Mylopoulos, Towards an agent oriented approach to

software engineering. in: A. Omicini, M. Viroli (Eds.),

WOA 2001—Dagli oggetti agli agenti: tendenze evolutive

dei sistemi software, Modena, Italy, September 2001.

[9] M. Burrows, M. Abadi, R. Needham, A logic of

authentication, Proc. Roy. Soc. Lond. A 426 (1989)

233–271.

[10] P. Bresciani, P. Giorgini, The Tropos analysis process as

graph transformation system, Proceedings of the Work-

shop on Agent-oriented methodologies, at OOPSLA 2002,

Seattle, WA, USA, Nov, 2002.

[11] E. Yu, Modelling Strategic Relationships for Process

Reengineering, Ph.D. Thesis, Department of Computer

Science, University of Toronto, Canada, 1995.

[12] B. Bauer, J. Muller, J. Odell, Agent UML: a formalism for

specifying multiagent interaction. in: P. Ciancarini, M.

Wooldridge (Eds.), Agent-Oriented Software Engineering,

Springer, Berlin, 2001, pp. 91–103.

[13] H. Mouratidis, P. Giorgini, G. Manson, I. Philp, A natural

extension of Tropos methodology for modelling security,

Proceedings of the Agent Oriented Methodologies Work-

shop (OOPSLA 2002), Seattle-USA, November 2002.

[14] H. Mouratidis, I. Philp, G. Manson, Analysis and design

of eSAP: an integrated health and social care information

system, Proceedings of the Seventh International Sympo-

sium on Health Information Managements Research

(ISHIMR2002), Sheffield, June 2002.

[15] M. Garzetti, P. Giorgini, J. Mylopoulos, F. Sannicolo,

Applying tropos methodology to a real case study:

complexity and criticality analysis, Proceedings of the

Second Italian workshop on ‘‘WOA 2002 dagli oggetti agli

agenti dall’informazione alla conoscenza’’, Milano, 18–19

November 2002.

[16] L. Bass, P. Clements, R. Kazman, Software Architecture

in Practice, SEI Series in Software Engineering, Addison-

Wesley, Reading, MA, 1998.

[17] P. Giorgini, J. Mylopoulos, E. Nicchiarelli, R. Sebastiani,

Reasoning with Goal Models, Proceedings of the 21st

ARTICLE IN PRESS


International Conference on Conceptual Modeling

(ER2002), Tampere, Finland, October 2002.

[18] R.T. Fielding, Architectural Styles and the Design of

Network-based Software Architectures, Doctoral Disser-

tation, University of California, Irvine, 2000.

[19] W. Jansen, Countermeasures for Mobile Agent Security,

Computer Communications, Special Issue on Advanced

Security Techniques for Network Protection, Elsevier

Science BV, November 2000.

[20] W. Jansen, T. Karygiannis, Mobile Agent Security,

National Institute of Standards and Technology, Special

Publication 800-19, August 1999.

[21] D.B. Lange, M. Oshima, Seven good reasons for mobile

agents, Commun. ACM 42(3) (March 1999).

[22] J. Bosch, Design and Use of Software Architectures:

adopting and Evolving a Product-line Approach, ACM

Press, Addison-Wesley, Reading, MA, 2000.

[23] A. Puliafito, S. Riccobene, M. Scarpa, Which paradigm

should I use?: an analytical comparison of the client-server,

remote evaluation and mobile agents paradigms, IEEE

Concurr. Comput.: Pract. Exper. 13 (2001) 71–94.

[24] R. Kazman, G. Abowd, L. Bass, M. Webb, SAAM: A

Method for Analyzing the Properties of Software Archi-

tectures, Proceedings of ICSE-16, Sorrento, Italy, May

1994.

[25] H. Mouratidis, P. Giorgini, G. Manson, I. Philp, Using

tropos methodology to model an integrated health

assessment system, Proceedings of the Fourth Interna-

tional Bi-Conference Workshop on Agent-Oriented In-

formation Systems (AOIS-2002), Toronto-Ontario, May

2002.

[26] L. Chung, B. Nixon, Dealing with non-functional require-

ments: three experimental studies of a process-oriented

approach, Proceedings of the 17th International Confer-

ence on Software Engineering, Seattle- USA, 1995.

[27] S. Rohrig, Using process models to analyze health care

security requirements, International Conference Advances

in Infrastructure for e-Business, e-Education, e-Science,

and e-Medicine on the Internet, L’Aquila, Italy, January

2002.

[28] J. Jurjens, Towards Secure Systems Development with

UMLsec, Fundamental Approaches to Software Engineer-

ing (FASE/ETAPS) 2001, International Conference, Gen-

oa, 4–6 April 2001.

[29] T. Lodderstedt, D. Basin, J. Doser, SecureUML: A UML-

Based modelling language for model-driven security,

Proceedings of the Fifth International Conference on the

Unified Modeling Language, 2002.

[30] G. Sindre, A.L. Opdahl, Eliciting Security Requirements

by Misuse Cases, Proceedings of TOOLS Pacific 2000,

November 2000.

[31] A. Dardenne, A. Van Lamsweerde, S. Fickas, Goal-

directed requirements acquisition. Science of computer

programming, Special issue on Sixth International Work-

shop of Software Specification and Design, 1991.

[32] P. Ryan, S. Schneider, Analysis and Design of Security

Protocols, Pearson Professional Education, 2000.

[33] C. Meadows, A model of computation for the NRL

protocol analyser, Proceedings of the 1994 Computer

Security Foundations Workshop, 1994.

[34] M. Kolp, P. Giorgini, J. Mylopoulos, A goal-based

organizational perspective on multi-agent architectures,

Proceedings of the Eight International Workshop on

Agent Theories, Architectures, and Languages (ATAL-

2001), Seattle-USA, August 2001.

[35] A. Fuxman, M. Pistore, J. Mylopoulos, P. Traverso,

Model Checking Early Requirements Specification in

Tropos, Proceedings of the Fifth International Symposium

on Requirements Engineering, RE’ 01, Toronto, Canada,

August 2001.