From KAOS to RBAC: a Case Study in DesigningAccess Control Rules from a Requirements Analysis

Yves Ledru, Jean-Luc Richier, Akram Idani, and Mohamed-Amine LabiadhUJF-Grenoble 1/Grenoble-INP/UPMF-Grenoble2/CNRS,

Laboratoire d’Informatique de Grenoble UMR 5217, F-38041, Grenoble, FranceTelephone : 33 (0) 4 76 82 72 16 - Fax : 33 (0) 4 76 82 72 87

email : {Yves.Ledru,Jean-Luc.Richier,Akram.Idani,Mohamed-Amine.Labiadh}@imag.fr

Abstract—This paper presents the KAOS2RBAC approach forSecurity Requirements Engineering. Starting from functionalrequirements, linked to a data model, the approach first identifieshigh level security goals. It then refines these security goals intosecurity requirements linked to the functional model. Finally,these security requirements lead to the design of access controlrules. An informal verification step checks that the rules giveenough permission to enable all functional requirements. Theapproach takes benefit of the KAOS notations to link functionaland non-functional goals, agents, data, and access control rules ina single requirements model. This enables traceability betweensecurity goals and the resulting access control rules. The ap-proach is illustrated by a case study: an information system formedical urgency, taken from a real project.

I. INTRODUCTION

One of the difficulties in the development of secure in-formation systems is to design an adequate security policy.The design of such a policy often results from an extensiverisk analysis, based on ISO 27000 [1] or EBIOS [2]. Thisleads to the identification of high level security goals, and theidentification of potential attacks. Several methods have beenproposed to get from these high level security goals down tosecurity requirements. For example, SQUARE [3] defines anine step process to elicit and prioritize security requirements.The process remains rather informal and can be instantiated inseveral ways. Other approaches build on existing requirementsengineering methods, which usually mix functional and non-functional requirements in their models. KAOS [4] is such arequirements engineering method, based on the construction ofa hierarchy of goals, including functional and non-functionalaspects. Mouratidis et al [5] adapt the Tropos methodology tothe modeling of secure information systems. Like KAOS, itbenefits from a rich formalism to identify goals, agents andtheir dependencies, and refine this model down to securityrequirements, and later to an architectural description. Haleyet al [6] propose a so-called “framework” for the represen-tation and analysis of security requirements. They build onthe problem frames method of Jackson [7] and propose a4-step iterative process to identify functional goals, securitygoals, derive security requirements and verify that securityrequirements fulfill their corresponding goals.

The approach presented in this paper uses similar stepsas Haley et al, but uses KAOS as underlying requirementsengineering method. Moreover, like Tropos, it goes beyond

the identification of security requirements and addresses thedesign of access control rules. Access control rules are atypical way to enforce a security policy. A recent survey [8]reveals that Role-Based Access Control (RBAC) is widelyadopted in organisations with more than 500 employees. InRBAC [9], access is granted to a given resource on the basisof the current roles associated to the user. RBAC has given riseto several variants. In this work, we target SecureUML[10],a UML security profile based on RBAC. RBAC’s notion ofrole is actually close to the notion of agent or actor whichappears in requirements engineering methods such as KAOSor Tropos. Therefore, we believe that such methods are well-adapted to support requirements engineering of secure systemsand the design of an RBAC model.

The proposed methodology builds on the KAOS method toidentify and locate high level security goals. Then, it refinesthese goals into security requirements and links them to accesscontrol rules, expressed in the UML class diagram.

This paper is organized as follows. Sect. II briefly introducesour case study. Sect. III presents the main concepts of KAOS,and discusses its appropriateness to support the design of aRBAC model. Sect. IV presents the steps of the KAOS2RBACapproach and illustrates these on the case study. Finally Sect. Vdraws the conclusions and perspectives of this work.

II. A BRIEF INTRODUCTION TO THE CASE STUDY

This work takes place within one of the case studies of theANR Selkis project1 dedicated to the development of securemedical information systems. The case study is an informationsystem for medical urgency. It covers every stage of a medicalurgency situation, from the initial call to a medical urgencycenter, to the management of emergency teams and vehiclesduring a mission. The information system stores medical dataabout the patients concerned by an emergency situation. Inthis paper, we elicit security requirements about these medicaldata, and describe the security policy as an RBAC model.

Our starting point is a set of UML diagrams (class diagramsand use case diagrams), prepared by the domain experts ofIFREMMONT, a non-profit organisation which develops vari-ous solutions for remote care. The UML diagrams describe theinformation model and its major functionalities. They feature

1http://lacl.univ-paris12.fr/selkis/

978-1-4577-0737-7/11/$26.00 ©2011 IEEE

ManagementAct+id+dateTime+preHospitalActor+patient+validated

+validate()+getManagementActInfos()+modifyManagementActInfo()

Care+TISS+wording+location+drugAdministration

Patient+id+managements+attachments+interventions+scheduledInterventions+name+firstName+sex+birthDate+socialInsuranceNumber+dmpNumber+regionalKey+telephoneNumbers+weight+size+address+localId

+getPatientInfos()+getName()

PreHospitalActor+id+person+unit+managementActs+state+team+teamMemberChangements+mobile+operator+medicalRole

Instruction+TISS+wording+location+drugAdministration+care

Diagnosis+CIM10+wording+type

MedicalAdvice+advice

DrugAdministration+id+drug+routeOfAdministration+dosage+dosageUnit

Prescription+length+lengthUnit+frequency+frequencyUnit+drugAdministration

g+instruction

Fig. 1. Class diagram for ManagementAct and the relevant linked classes.

77 classes and more than 100 use cases. The identification ofsecurity requirements for the whole information system wouldbe a huge task, so we decided to focus on a critical issue: theprotection of medical data.

In the class diagram, medical data are exclusively stored inclass “ManagementAct” and its numerous subclasses (Fig. 1).Each management act corresponds to a single medical act(analysis, prescription, instruction, care,. . . )2. It is linked by acomposition relation to class Patient, representing the patientwho received the medical act, and to class PreHospitalActor,representing the member of the medical emergency teamwho achieved this medical act. Since management acts storeconfidential and critical information about patients, we focuson the security requirements linked to this class.

III. KAOS AND RBAC

A. Goal Refinement

KAOS [4] is a goal-oriented requirements engineeringmethod. The main KAOS diagram identifies a hierarchy ofgoals which motivate the development of the system. Highlevel goals capture overall motivation for the system, such asbusiness needs. Lower level goals provide more operationalobjectives. A refinement hierarchy leads from high level tolower level goals. These lower level goals can be distributedamongst the various agents of the system. Agents can behuman beings, or software to develop. In this paper, weuse the syntax of the RE-Tools3 extension of StarUML4,which slightly differs from the original KAOS syntax. Fig. 2summarizes the main graphical notations used in this paper.

To illustrate these concepts, let us consider Fig. 3. It detailshow a patient can be managed remotely, by phone. This isrepresented by the goal “Achieve[Remote care of patient]”.This goal is refined into three subgoals:

2For simplicity reasons, we only display five subclasses of class Manage-mentAct. The original UML diagram features 9 subclasses.

3http://www.utdallas.edu/∼supakkul/tools/RE-Tools/index.htm4http://staruml.sourceforge.net

Non-functional Goal<<Goal>>

High-level Goal

Refinement links(between goal and subgoals)

Conflict between goals

Subgoal 1

Human agent

Subgoal 2

Software agentRBAC Permission

<<SecUML.Permission>>

UML Class

Responsibility links(between goals and agents)

Links between KAOS and SecureUML elements

Fig. 2. Graphical Notations for KAOS

• “Medical advice given”. This corresponds to the casewhere the patient makes an emergency call, but hisproblem is rather simple and does not require the help ofa doctor. The operator on the phone simply gives someadvices to the patient. Two categories of agents may issuea medical advice: the PARM is an operator of the callcenter who followed a specific training, and the regulatoris the doctor on duty at the call center.

• “Prescription or instruction issued”. In this case, thepatient makes an emergency call, or the call is performedby some emergency team which does not include adoctor. The phone operator must be a doctor (i.e. theregulator). Doctors are allowed to issue a prescription oran instruction for the patient to take some drug or getsome care from the emergency team.5

• “Implicit validation”. Medical advices, prescriptions andinstructions are all management acts, and must be vali-dated by the medical actor who took responsibility for it.

5As shown in Fig. 1, an instruction is always associated to a care, performedby some medical actor, which guarantees that drug administration really takesplace. A prescription relies on the cooperation of the patient to take the drugas prescribed.

Achieve [Remote care of patient]

[Prescription or instruction issued][Medical advice given] [Implicit validation][Prescription or instruction issued][Medical advice given] [Implicit validation]

Res@muREGULATORPARM

Fig. 3. Refinement of goal “remote care of patient”

DOCTORRESCUER SAMU DIRECTORSYSTEM ENGINEER

USERTEAM MEMBERADMINISTRATOR

CA C SNURSE

PARM

OPERATOR

REGULATORRescuers are Fire fighters,Ambulance drivers,...

TEAM DOCTOR

CALL CENTER MEMBERS

Doctors may issue prescriptionsand instructions.

Fig. 4. Human agents of the medical urgency system

In the case of remote care, these acts are entered in thesystem by the telephone operator or the regulator, whoare the persons responsible for the act. These acts do notrequire explicit validation by the agent and are implicitlyvalidated by the system agent, named Res@mu.

KAOS diagrams, such as Fig. 3 express thus the decom-position of abstract goals into more concrete ones. Concretegoals may be associated to the agent in charge of this goal.

B. KAOS Agents

Concrete KAOS goals are associated to agents who areresponsible for fulfilling the goals. Fig. 4 gives the hierarchyof roles involved in the medical urgency system. This rolehierarchy results from discussions with the domain experts atIFREMMONT, as explained in Sect. IV-A. These goals givea subset of the agents which appear in the KAOS diagrams.KAOS agents also include non-human agents, i.e. softwareagents. The original KAOS method does not feature special-isation links between agents. The only link is an aggregationlink. In this project, we felt the need for specialisation. Forexample, in Fig. 6 the OPERATOR agent can either be anordinary operator or a PARM. Our agent hierarchy also usesmultiple inheritance. For example, a regulator is a call centermember, i.e. a phone operator, who is also a doctor.

In Fig. 3, the three lower level goals are associated to agents.The goal “Medical advice given”, is associated to two agentswho may give such advices: PARM and REGULATOR. Bothare specialisations of call center members who are qualifiedfor such medical advices: the regulator is a doctor, while thePARM is an operator who followed a specific training. Wemight have defined an abstract agent MEDICAL OPERATORwhich includes both categories. However this agent would onlybe used in this particular context and was not perceived asdefinitely needed. Here again, we deviate a little from theKAOS method which prescribes that a lower level goal mustbe associated to exactly one agent. Other lower level goalsare associated to a human or software agent: prescriptions andinstructions are issued by the regulator, and implicit validationis automatically performed by the system.

Achieve [Remote care of patient]

[Prescription or instruction issued][Medical advice given] [Implicit validation]

ManagementAct+id+dateTime+preHospitalActor+patient+validated

+validate()+getManagementActInfos()+modifyManagementActInfo()

Fig. 5. Goals can be linked to classes

C. Link to the Data Model

KAOS goals can also be linked to the data concerned bythe goal. In Fig. 5, we link the three lower level goals to theManagementAct class, since they all involve the creation ormodification of such objects.

KAOS also allows to link goals to operations, but thisfeature was not used in this case study. At a later stage, wewill also express links from goals to access control rules.

D. Security Goals

KAOS goals may be non-functional. This allows to useKAOS to express security goals. In our example, a goal canexpress that “medical data should be kept confidential”. In theSelkis project, high level security properties are sorted into thefour ACIT categories:

• Availability: security measures should not prevent theuser from accessing data when needed;

• Confidentiality: data should not be disclosed to unautho-rized persons;

• Integrity: unauthorized users should not be allowed tomodify or delete data;

• Traceability: accesses to the data by users should belogged.

Fig. 6 shows that the high level goal “Quality Samu”6

includes two sub-hierarchies: a functional one (on the right)and a non-functional one dedicated to security (on the left).We use blue rectangles to denote non-functional goals.

Availability, Confidentiality, Integrity, and Traceability(ACIT) are high level properties that must be enforced by anadequate security policy. In Selkis, we use RBAC (or variantsof it) to express the rules of such policy properties.

In Role-Based Access Control (RBAC) [9], security policiesare expressed by rules which define the permissions of userson resources which can be objects or operations. RBACintroduces the intermediate notion of roles between users and

6SAMU: Service d’aide medicale urgente - Urgency medical help service

Achieve [Call Managed]

Patient’s data availability<<Goal>>

Quality Samu

Secure Samu Functional SAMU

Data integrity <<Goal>>

Achieve [Patient managed locally]

PriorityScore assigned to the call

Achieve [Call Information recorded] Achieve [Patient managed]

Achieve [Remote care of patient]OPERATOR

Patient’s data confidentiality <<Goal>>

Traceability of any access to the patient’s data

<<Goal>>

Fig. 6. The most abstract goals of the hierarchy, including security and functional goals

permissions. As a result, all users playing the same role havethe same permissions. It is possible for users to play severalroles, and depending on their current role to be granted variouspermissions.

E. Designing RBAC Rules from KAOS Diagrams

Besides security goals, KAOS provides the notions of agentand links to the data. Agents are close to the RBAC notionof role, except that we expect roles to correspond to humanagents. Data correspond to the resources controlled by theRBAC permissions. KAOS models can thus be used as astarting point to identify the elements which need to be securedusing RBAC rules.

IV. METHODOLOGY FOLLOWED IN OUR CASE STUDY

We now review the process applied to refine security goalsinto security requirements and define our RBAC securitypolicy for this case study. As already mentioned, the startingpoint of our case study was a functional model, made up of aset of class diagrams, associated to use cases. This functionalmodel was built by domain experts. Building this functionalmodel corresponds to the first step proposed by Haley et al[6]. Our methodology is composed of the following steps:

1) Construction of an agent hierarchy from interviews withthe domain experts.

2) Identification of use cases related to the security target,i.e. management acts.

3) Construction of a KAOS functional goal hierarchy basedon the structure of these use cases.

4) Identification of security goals linked to the data toprotect (here, ManagementAct).

5) Identification of functional goals linked to the dataprotected by security goals. These functional goals arerefined into functional sub-goals which enforce the secu-rity rules. These subgoals are our security requirements.

6) Expression of RBAC rules enforcing security goals;these rules are linked to the corresponding KAOS goals.

7) Check that every functional goal remains satisfiable inthe context of RBAC rules.

Fig. 7 relates these steps to the ones of Haley et al [6].

Our KAOS2RBAC approach Haley et al[6]0. Build a functional model1. Construct agent hierarchy2. Identify relevant use cases 1. Identify functional

requirements3. Construct a functional goal hierarchy4. Identify security goals 2. Identify security goals5. Refine into security requirements 3. Identify security

requirements6. Design RBAC rules7. Check satisfiability of functional

goals4. Construct satisfactionarguments

Fig. 7. The main steps of KAOS2RBAC compared to Haley et al [6]

A. Construction of an Agent Hierarchy

The identification of agents plays a crucial role in bothRBAC and KAOS. In KAOS, it selects the stakeholders whichinteract with the system. Reasoning on each of them helps to

elicit the goals of interest for this agent. In the case of oursecurity application, one can also review each of these agentsand question whether he has some interest in breaking securityrules and so become an attacker.

In this case study, our discussions with the domain expertsof IFREMMONT (who also provided the class diagrams anduse cases) helped us identify the agents of Fig. 4. Please notethat these focus on human agents, and don’t include the systemor software to develop (Res@mu).

It is also interesting to notice that patients are not agentsin this system. Actually, they play a passive role and don’tinteract directly with the system. Each of their interactionsgoes through a member of the medical organisation.

As already mentioned, we felt the need for inheritancerelations in this diagram. This is consistent with the fact thatRBAC defines a hierarchy of roles. Moreover, we neededmultiple inheritance since there is a double partitioning of themain agents: those located in the call center vs those in directcontact with the patient, and the doctors vs non-doctors.

B. Identification of Use Cases Related to Management Acts

In order to identify the hierarchy of functional goals, weexploited the structure of use cases. As already mentioned,the initial UML diagrams include more than 100 use cases,and most of them are structured hierarchically. Fig. 8 gives asample of these diagrams. The full diagram corresponding tothe use cases linked to management acts is given in Fig. 12.These use cases express that there are two ways to take careof a patient: in-place and remotely. We omit the details of in-place operations and only detail remote care, which includesthree cases: medical advice, prescription and instruction. Bothin-place and remote operations must be validated.

Manage a patient

Manage a patient Manage a patient Performlid ti f

<<extend>>

locallyg p

remotely

Record aninstruction

Record aprescription

<<extend>><<extend>>

Record amedical advice

<<extend>>

validation of ManagementActs

<<extend>>

<<extend>>

…

…

Fig. 8. Use cases related to the remote care of patients

C. Construction of a KAOS Functional Goal Hierarchy

Use cases correspond to functionalities of the target system.In KAOS, they are close to goal operationalisation. So itmakes sense to use them to identify the functional goals of oursystem. In this case study, we exploited the use case hierarchyto build our goal hierarchy.

The structure of these use cases has inspired the goalstructure proposed in Fig. 3 and Fig. 5. In the goal diagram,

prescriptions and instructions have been grouped in a singlegoal, because they share the common characteristic that theymust be performed by a doctor, and because we did not feelthe need to further distinguish between these for our securityanalysis purposes. Also, validation has been included as a sub-goal of the remote care. In the full diagram (Fig. 9), it is alsolinked to in-place care.

D. Identification of Security Goals linked to Data to Protect

The security goals are identified by reviewing the need forACIT properties. They are non-functional goals which applyto large parts of the system. Here, we decided that each ACITproperty makes sense with respect to management acts:

• Availability: the medical data must be available to allmembers of the teams involved in emergency operationslinked to the patient. This means that the informationsystem must grant access to these data for all thesepersonal. This availability remains after the emergencymission is closed to enable feedback to all emergencypersonal on how the whole mission ended.

• Confidentiality: the medical data are confidential infor-mation, and may not be disclosed to actors not involvedin the emergency operations linked to the patient.

• Integrity: it must be ensured that original data are notcorrupted when transmitted or copied, and not lost. Al-though it seems that it is only possible to add informationto the system, some integrity properties remain. First, itmust be possible to modify incorrect input, although thisis not clearly supported in the use cases. It appeared thatensuring that the right person does the validation is alsoan integrity issue.

• Traceability: every access to medical data, both for con-sulting and modifying should be logged.

These security goals appear on the KAOS diagram (Fig. 6,Fig. 9). This diagram also expresses that availability andconfidentiality may be in conflict. Obviously, too strict confi-dentiality rules may prevent the rescue teams from accessingthe necessary information. Conversely, too much availabilitymay lead to disclose information to non-authorized actors.

The identification of these ACIT properties led to manydiscussions. The result is captured by the KAOS diagrams(Fig. 6, Fig. 9). In Fig. 9, these non-functional goals areattached to the related secure data (here ManagementAct).They may also be related to some functional goals. Forexample, goal “Patient data availability” is required to perform“Patient managed remotely”. Nevertheless, these security goalsappear as rather abstract and need further refinement.

One of the results of these discussions was that a potentialsecurity hole may appear in the way emergency teams arebuilt, and subsequently modified. Since access is granted to allmembers of the emergency team, one way to access medicaldata is to join the team. Care must thus be taken to makesure that nobody joins the team after the mission is completed(actually, the team is dedicated to a single mission), andnobody joins the team during the mission without explicitauthorisation from an authorized stakeholder, i.e. the regulator.

Achieve [Patient managed locally]

Achieve [State of the patient recorded]Achieve [Provision of medical care dealt with]

Achieve [Call Managed]

PriorityScore assigned to the call

Achieve [Call Information recorded]

Achieve [Patient managed]

Achieve [Remote care of patient]

i i i i[Care recorded]Patient’s data availability

<<Goal>>

Secure SAMU

[Prescription or Instruction issued]

[Medical advice given]

[Care recorded]

[Care or Instruction or Prescription validated]

[Implicit validation]

Patient’s data confidentiality<<Goal>>

Patient s data availability

Traceability of any access to the patient’s data<<Goal>>

ManagementAct+id+dateTime+preHospitalActor+patient+validated

+validate()+getManagementActInfos()+modifyManagementActInfo()

[Validation carried out explicitly]

Data integrity<<Goal>>

Fig. 9. The goals related to management acts

This motivates the need to extend the functional coverageof our goal diagrams and also include the team modificationfunctions. This extended diagram is not shown in this paper.It corresponds to the iterative character of the requirementselicitation process described by Haley et al [6].

E. Identification of Functional Goals Linked to Protected data

The functional goals linked to ManagementAct appear inFig. 9. In the restricted scope of Fig. 5, all lower level goals areconcerned by these data. For each of these goals, security mustbe enforced by several additional checks or actions, which willtake the form of functional subgoals, refining the concernedfunctional goal. For example, Fig. 10 considers goals “Medicaladvice given”, and “Prescription or instruction issued” whichboth correspond to the creation of a management act. Dataintegrity mandates that management acts may only be createdby authorized personal i.e. PARM and regulator. Therefore, anadditional goal is added to “Achieve[Remote care of patient]”to check that the issuer of a management act is an authorizedperson. This goal, named “Right granted to add managementact” is also a refinement of “Data integrity” and is associatedto the system to build (Res@mu).

F. Expression of RBAC Rules which Enforce Security Goalsin the Context of each Functional Goal

The next step is to express the RBAC rules in the classdiagram. Fig. 10 tells us that two RBAC rules (AccessRight1

Achieve [Remote care of patient]

[Implicit validation]

Data integrity<<Goal>>

[Prescription or instruction issued]

[Medical advice given]

REGULATOR

PARM

Res@mu

Res@mu

AccessRight1<<SecUML.permission>>

+addValidManagementAct: execute

<<MethodAction>>+addValidManagementAct()

AccessRight2<<SecUML.permission>>

+addValidManagementAct: execute

<<MethodAction>>+addValidManagementAct()

[Right granted to add management act]

Fig. 10. From security goals to RBAC permissions

and AccessRight2) are needed to perform “Right granted toadd management act”. These rules are further described inFig. 11. We use a graphical syntax similar to SecureUML[10] where permission rules take the form of stereotyped

Patient

+id+managements+attachments+interventions+scheduledInterventions+name+firstName+sex+birthDate+socialInsuranceNumber+dmpNumber+regionalKey+telephoneNumbers+weight+size+address+localId

+getPatientInfos()+getName()

ManagementAct

+id

<<secuml.context>>

PARM

AccessRight1<<SecUML.permission>>

+ActionName: addValidManagementAct

AccessRight2<<SecUML.permission>>

+ActionName: addValidManagementAct

A Regulator can only create a ManagementAct of types Instruction, Prescription or MedicalAdvice. To be able to do it, he must take part in one of the interventions of the patient.

PatientView<<secuml.resourceView>>

+managements

+addManagementAct()+addValidManagementAct()

+getName()+id+dateTime+preHospitalActor+patient+validated

+validate()+getManagementActInfos()+modifyManagementActInfo()

REGULATOR

MedicalAdvice

+advice

A PARM can only create a ManagementAct of type MedicalAdvice. To be able to do it, he must take part in one of the interventions of the patient.

MedicalAdvicePerm<<SecUML.permission>>

+ActionType: read

ManagementActPerm1<<SecUML.permission>>

+actionType: Read

Fig. 11. The RBAC rules related to MedicalAdvice

associative classes. For example, rule AccessRight1 tells usthat the regulator has the right to create any management act.A condition, expressed in natural language restricts this per-mission to the regulator who is in charge of this patient. RuleAccessRight2 applies to PARM and restricts this permissionto the creation of medical advices. Besides class Manage-mentAct, there is a need to represent subclass MedicalAdvicein Fig. 11, because specific permissions apply to that class(PARMs have the right to access medical advices).

G. Check Satisfiability of Functional Goals

The last step of our approach is to systematically revieweach functional goal linked to ManagementAct, and check thatthe associated permissions are sufficient to fulfill the goal.

For example, let us consider goal “Medical advice given”and the rules of Fig. 11. This goal can be achieved by a PARMor the regulator, who is a doctor. It only involves subclassMedicalAdvice of ManagementAct. It requires to be able tocreate a medical advice object, and once created, there is nopossibility to modify it because it is instantly validated. Theonly remaining right for regulators and PARM is to read it.One can easily check that Fig. 11 features two such RBACrules for both actors. One of these rules is a read permissionon Medical Advice, the other one is a permission to createsuch a Medical Advice for a given patient.

Each functional goal related to ManagementAct must bechecked against the RBAC rules to ensure that the goal canbe satisfied. In a later verification or validation activity, it willmean that a proof obligation may be expressed to check that

the goal can be fulfilled (maybe in given circumstances), orthat at least one test case should be associated to the goal todemonstrate that the goal can be fulfilled.

V. CONCLUSION

We have presented the KAOS2RBAC approach which helpsdesign access control rules from security goals. The structureof the approach goes through similar steps as the frameworkof Haley et al [6]: identification of functional requirements,security goals and security requirements. Haley et al use theproblem frames notation of Jackson [7], while we use thenotations of KAOS [4]. We felt that KAOS provides a richerframework to link various kinds of goals, to actors, data andeven access control rules. The KAOS diagrams establish thelink between high level security goals and the RBAC rules.They allow traceability between goals and RBAC rules.

Haley et al complete their process with a more elaborateverification step than ours, where formal proofs are carriedout using causal logic. Further work on this step is currentlyconsidered in the ANR Selkis project.

Huang et al also investigate the use of KAOS to designRBAC rules [11]. They focus on role engineering and make adistinction between agents and roles. Their work is still pre-liminary, and does hardly address the modelisation of securityconcerns. Compared to this work, KAOS2RBAC addresses theidentification of non-functional goals and their refinement intoconcrete goals linked to permission rules.

Our approach was applied to protect one of the classes ofa real case study: an information system for medical urgency.

From this case study, it appears that valuable information canbe extracted from the initial UML diagrams (class diagramand use cases) which express only the functional aspects ofthe problem. Still, security properties are absent from thesedescriptions. In our case study, they were first elicited froman extensive discussion with the domain experts of IFREM-MONT. This discussion was mainly guided by the need toidentify the relevant actors, and the relevant ACIT properties.

Perspectives: KAOS promotes a security analysis techniquewhich was not used in this study, but can probably beapplied to the resulting diagrams. Actually KAOS arguesfor the systematic identification of obstacles for every leafgoal. Obstacles correspond either to hazards or to attacks. Inthe case of attacks, they are led by malicious actors. Thissystematic identification of obstacles is actually similar to theidentification of abuse cases [12] or misuse cases [13]. It canalso take benefit from the outcome of a risk analysis, based ona list of standard attacks. In section III-B, we mentioned thatthe actor model could be studied in order to identify potentialmalicious actors. Further work should be led to identify suchactors and their corresponding attacks, and integrate theseanalyses in our verification step.

Management of a patient

Manage a patient

Manage a patient locally

Manage a patientremotely

Manage transport ofA patient

Registerbiomedical

data

Attach a file toa patient

<<extend>>

<<extend>>

Register a Care

<<extend>>

<<extend>><<extend>><<extend>> Register

MedicalAdvice

<<extend>>

View patient’s management acts <<extend>>

Management of teams

Manage team’s journeys

<<include>>

Patients Management

Manage patient information

View teams<<extend>>

<<extend>>

Manage provision of medical care

for a patient

Manage follow-up

of a patient

Register anobservation

<<extend>>

<<extend>>

<<extend>><<extend>>

Register aninstruction

Register aprescription

<<extend>>

<<extend>>

<<extend>>

<<extend>>

<<include>>

Management of the validation of Management acts

Managevalidation

of care

Managevalidation ofa diagnosis

Managevalidation ofobservation

<<extend>>

<<extend>><<extend>> <<extend>>

<<extend>>

<<extend>>

Performvalidation ofManagement

Acts

<<extend>>

Register a care

Manage Validation

of score

<<extend>>

Managevalidation ofprescription

Managevalidation ofinstruction

Register adiagnosis Register

administrationof a drug

Manage validation ofbiomedical

data

Fig. 12. The use cases related to management acts

ACKNOWLEDGMENT

We’d like to thank Quentin Switsers and Pascal Zellner,our colleagues of IFREMMONT, for providing this case studyand the associated UML diagrams, and for their availability todiscuss it and help identify the requirements. This work wassponsored by the Selkis project (ANR-08-SEGI-018).

REFERENCES

[1] Information technology – Security techniques – Information securitymanagement systems – Overview and vocabulary, ISO, 2009.

[2] Expression des Besoins et Identification des Objectifsde Securite - EBIOS - Methode de gestion desrisques, 2010. [Online]. Available: http://www.ssi.gouv.fr/IMG/pdf/EBIOS-1-GuideMethodologique-2010-01-25.pdf

[3] N. R. Mead, “Security quality requirements engineering (square)methodology,” in ACM SIGSOFT Software Eng. Notes, 2005, pp. 1–7.

[4] A. van Lamsweerde, Requirements Engineering: From System Goals toUML Models to Software Specifications. Wiley, 2009.

[5] H. Mouratidis, P. Giorgini, and G. A. Manson, “Integrating securityand systems engineering: Towards the modelling of secure informationsystems,” in Advanced Information Systems Engineering, 15th Int. Conf.,CAiSE 2003, ser. LNCS, vol. 2681. Springer, 2003, pp. 63–78.

[6] C. B. Haley, R. C. Laney, J. D. Moffett, and B. Nuseibeh, “Securityrequirements engineering: A framework for representation and analysis,”IEEE Trans. Software Eng., vol. 34, no. 1, pp. 133–153, 2008.

[7] M. Jackson, Problem frames: analyzing and structuring software de-velopment problems. Boston, MA, USA: Addison-Wesley LongmanPublishing Co., Inc., 2001.

[8] A. C. Connor and R. J. Loomis, “Economic analysis of role-based accesscontrol,” RTI, prepared for NIST, Tech. Rep. 0211876, 2010.

[9] D. Ferraiolo, D. Kuhn, and R. Chandramouli, Role-Based Access Con-trol, ser. Computer Security Series. Artech House, 2003.

[10] D. A. Basin, J. Doser, and T. Lodderstedt, “Model driven security: FromUML models to access control infrastructures,” ACM Trans. Softw. Eng.Methodol., vol. 15, no. 1, pp. 39–91, 2006.

[11] C. Huang, J. Sun, X. Wang, and Y. Si, “Role Engineering with SKAOSfor Systems Employing RBAC,” in Int. Conf. on Networking and DigitalSociety, 2009.

[12] J. P. McDermott and C. Fox, “Using abuse case models for securityrequirements analysis,” in 15th Annual Computer Security ApplicationsConference (ACSAC 1999). IEEE Computer Society, 1999.

[13] I. F. Alexander, “Misuse cases: Use cases with hostile intent,” IEEESoftware, vol. 20, no. 1, pp. 58–66, 2003.