Towards Automatic Update of Access Control Policy

Transcription

1 Towads Automatic Update of Access Contol Policy Jinwei Hu, Yan Zhang, and Ruixuan Li Intelligent Systems Laboatoy, School of Computing and Mathematics Univesity of Westen Sydney, Sydney 1797, Austalia Intelligent and Distibuted Computing Laboatoy, School of Compute Science and Technology Huazhong Univesity of Science and Technology, Wuhan , China Coesponding autho Abstact Role-based access contol (RBAC) has significantly simplified the management of uses and pemissions in computing systems. In dynamic envionments, systems ae subject to changes, so that the associated configuations need to be updated accodingly in ode to eflect the systems evolution. Access contol update is complex, especially fo lage-scale systems; because the updated system is expected to meet necessay constaints. This pape pesents a tool, RoleUpdate, which answes administatos high-level update equest fo olebased access contol systems. RoleUpdate is able to automatically check whethe a equied update is achievable and, if so, to constuct a efeence model. In light of this model, administatos could fulfill the changes to RBAC systems. RoleUpdate is able to cope with pactical update equests, e.g., that include ole hieachies and administative ules in effect. Moeove, RoleUpdate can also povide minimal update in the sense that no edundant changes ae implemented. 1 Intoduction Role-based access contol (RBAC) [11, 35] simplifies access contol management. In an RBAC system, uses ae assigned to oles such as manage and employee, and a ole in tun is defined as a set of pemissions. The key to RBAC is that uses ae assigned to oles and thus obtain oles pemissions, instead of being assigned pemissions diectly. Essentially, an RBAC configuation manages thee kinds of elations: a use-ole elation, a ole-ole elation, and a ole-pemission elation. The use-ole elation assigns uses to oles. The ole-ole elation descibes how oles pemissions ae inheited by othe oles. The ole-pemission elation descibes which pemissions ae accoded to each ole. An RBAC system consists of two components, the RBAC configuation and the administation configuation. A unning example RBAC system, which is used thoughout the pape, is compised of the RBAC configuation in Figue 1 and the administation configuation in Figue 2. The ole-ole elation needs to be a patial ode ove oles; usually we efe to the ole-ole elation as a ole hieachy. The ole hieachy embodies two inheitance elationships among oles. Take the RBAC configuation in Figue 1 fo example. ( 1, 7 ) belongs to the hieachy and we say 1 is senio to 7 ; it means that 1 inheits all pemissions of 7 (i.e., p 3 and p 4 ) and that all membes of 1 ae also membes of 7 o in othe wods, 7 inheits all uses of 1. RBAC is able to model a wide ange of access contol equiements, including discetionay and mandatoy access contol policies [30]. Hence, RBAC is widely suppoted in commodity opeating systems and database systems [15, 17, 25], and is deployed inside many oganizations [37]. We call a snapshot of an RBAC system an RBAC state. We denote the cuent state of the unning example RBAC system as γ. Administatos can pefom administative actions to take an RBAC system fom one RBAC state to anothe. Usually, the administation configuation is supposed to be static; that is, only the RBAC configuation may be changed. The actions available to administatos we conside ae two types: admin assign p to, and admin evoke p fom. Administatos powes ae egulated by the administation configuation. We suppot vaiants of the PRA97 component of the ARBAC97 administative model fo RBAC [34]. The administative model is instantiated by a set of assignment ules and a set of evocation ules. Figue 2 pesents the administation configuation of γ. An assignment ule is of the fom a can assign p to if p assigned to c, which means an administato in ole a can assign a pemission p to, if p is also assigned to

2 u 1 u 2 u 3 u p 3 p 4 p 5 p 6 p 7 p 8 p 9 Figue 1: An example RBAC configuation. Uses ae epesented as ellipses, oles as cicles, and pemissions as ectangles. Aows between uses and oles denote use-ole assignments, aows between oles and pemissions denote ole-pemission assignments, and dashed aows between oles denote ole-ole elationships (ole hieachy). c. The expession c is constucted by oles and the connecto. Fo example, conside the ule a 2 can assign p to 1 if p assigned to 2 3 ; then the administato admin 2 can assign a pemission p to 1 if p is assigned to 2 and 3. 1 A evocation ule is of the fom a can evoke p fom, expessing that an administato in ole a can evoke a pemission p fom. Update of RBAC systems is complex and challenging, especially fo lage-scale RBAC deployments. Existing tools mainly help administatos analyze and manage the RBAC system; they put little emphasis on suggesting to administatos how to configue the system. As shown in Figue 3a, with existing tools, administatos may have to update the system in a manual way. Figue 3b shows a typical pocess of manual update when one administato is pesent. The administato fist detemines and specifies, in some language, the update objective and the constaints that the final esulting system should satisfy. Usually, an update objective is initially fomulated as high-level objectives (e.g., being able to assign {p 5, p 8, p 9 } to a use). Abitay update may hinde the secuity and availability of the RBAC system. Fo example, evocation of a docto s pemission to wite to a patient s medical ecod as a esult of updating is not 1 Conside, fo example, the following situation: an administato wants to enable an enginee to elease the souce code of a piece of softwae; howeve, the administato can not do so unless the poduct manage and the quality manage ae authoized to elease the souce code. assignment ules: a 1 can assign p to 6 if p assigned to 1 2; a 2 can assign p to 1 if p assigned to 2 3; a 2 can assign p to 1 if p assigned to 2 4; a 0 can assign p to 1; a 0 can assign p to 6; evocation ules: a 1 can evoke p fom 4; a 1 can evoke p fom 6; a 2 can evoke p fom 1; a 2 can evoke p fom 2; a 2 can evoke p fom 3; a 3 can evoke p fom 5; a 3 can evoke p fom 6; a 0 can evoke p fom 1; a 0 can evoke p fom 6; administative ole assignments: admin 0 in a 0; admin 1 in a 1; admin 2 in a 2; admin 3 in a 3; Figue 2: An example administation configuation. 2

3 acceptable. To modify system configuations, an administato needs to obseve the system and the constaints, and devises an update plan, which consists of a sequence of administative actions. The administato implements those actions, which take the system to a new state. Thee is no guaantee that all constaints ae met and that this new state is the desied one. Hence, the administato poceeds to check if these two conditions hold. When eithe one does not hold, the administato may need to undo some pevious actions and epeat the pocess. Roughly speaking, this is a tial-and-eo appoach. Fo lage and complex systems, one can fail to achieve update afte seveal tials; in this case, the question is whethe to give up o not. Thus thee aises a question: is the update achievable at all? An answe to this question helps the administato make pope decisions. A positive answe implies that the update can be achieved and that the administato should pesevee in tying, wheeas a negative one saves the administato fom continuing with pointless attempts. On the othe hand, suppose that the administato finally manages to update the system without violating constaints. In this case, how diffeent is the updated system fom the oiginal one? The less diffeent it is, the moe easie fo one to undestand and maintain the system, and thus the moe pefeable the update is. In othe wods, we may pusue an update that incus minimal diffeences. When multiple administatos ae involved, the poblem become moe complicated. The actions an administato can take might depend on othes actions. That is, administatos have mutual influence on each othe in tems of administative powe. Coopeation among administatos is equied in this case, which inceases the complexity and cost of manual update. In summay, manual administation fo update is wok-intensive, inefficient and, when the objective is not achievable at all, vey fustating. Access contol update is demanded when secuity equiements ae changed. In addition, RBAC systems may need updating in esponse to the following developing situations: Misconfiguation Repai Misconfiguations in access contol systems can esult in sevee consequences [4]. In a health-cae situation, fo instance, lack of legal authoization could lead to the delay of teatment. Moden access contol systems include hundeds of ules, which ae managed by diffeent administatos in a distibuted manne. The inceasing complexity of access contol systems gives ise to moe likelihood of misconfiguations [2, 3]. As such, coecting misconfiguations is essential to systems usability and secuity. Updating is necesadministato administation tools RBAC system undo opeations yes no (a) specify update constaints obseve the system and update constaints pefom some opeations check system and constaints constaints violated? no update achieved? no yes z give up? end y Question: ae all changes necessay? z Question: is update achievable? yes y (b) Wokflow of manual update. infomation that administatos view update constaints plans of how to update the system system in a new state epot about the system and constaints Figue 3: Illustation of updating without RoleUpdate. say when misconfiguations in RBAC systems ae detected. Task Assignments To accomplish a task, a set of pemissions should be assigned to a set of uses to empowe them to pefom task opeations [13]. Fo a new task, it is likely that the pesent RBAC configuation fails to enable exactly the needed usepemission assignments. In this case, administatos may esot to adjusting ole configuations. Popety satisfaction An RBAC system should ex- 3

4 hibit vaious popeties, including simple availability/safety and containment availability/safety [14, 22, 23, 24]. A simple availability/safety popety asks whethe a use Alice has a pemission, e.g., access to a confidential file. Containment safety popeties encode queies such as whethe any use who can access pintes ae membes of staff, wheeas containment availability popeties may ask whethe all students have pemission to use a libay. If an RBAC system was not designed with these popeties in mind, it is unlikely that all popeties would happen to hold. Paticulaly, fo legacy systems, thee is no guaantee of automatic establishment of secuity popeties when they ae migated to RBAC management. On the othe hand, even if all desied secuity popeties hold cuently, equiements ae not static. Fo example, it may be desied that now only manages, instead of employees, have access to an intenal document. To assue these popeties, one may have to update the RBAC system. Updating is a key component of maintenance in the RBAC life-cycle [18], and accounts fo a geat popotion of the total cost of maintenance [29]. RoleUpdate assists administatos with update tasks. As shown in Figue 4a, pio to updating the system, the administato fist inteacts with RoleUpdate, and then manipulates the system using suggestions fom RoleUpdate. Figue 4b shows the wokflow of updating with RoleUpdate. The administato still needs to specify the update constaints, and invoke RoleUpdate with the equest. Role- Update checks, in an automatic way, whethe the equest achievable o not; and if so, a sequence of actions, which take the system to the expected state, is epoted. Role- Update can also deal with the case whee multiple administatos ae involved. RoleUpdate makes novel use of model checking techniques [6]. Figue 5a illustates the basic idea of model checking. A model checke takes a desciption of a system and a popety as inputs, and examines the system fo the popety. If the system exhibits the popety, the checke epots that the popety is tue. If the system is found to lack the popety, the model checke poduces one counte-example. The counte-example, usually a sequence of system state tansitions, explains how the system tansits to a state whee the popety fails. Figue 5b illustates how to use model checking as the basis fo update. We check the popety that the equested state is neve eached; when the popety does not hold, one is not only infomed of the existence of an update but also a counte-example that coesponds to the update. Role- Update tansfoms update poblems into model checkadministato administation tools RBAC system specify update constaints un RoleUpdate with the system and constaints pefom opeations end RoleUpdate (a) infomation that administatos view update constaints epot of update being un achievable o of a sequence of opeations (b) Wokflow of update with RoleUpdate. Figue 4: Illustation of updating with RoleUpdate. ing poblems, whee the failue of the model is synonymous with existence of a solution: if the popety is detemined to be tue, the update objective is not achievable; othewise, the model checke etuns a counteexample, fom which an update is constucted. RoleUpdate employs NuSMV [5] to pefom model checking. NuMSV is a open-souce symbolic model checke. Fo bette pefomance, a collection of eductions and optimization techniques ae implemented in RoleUpdate. The est of this pape is stuctued as follows. Related woks ae given in Section 2. We demonstate the use of RoleUpdate by showing how it handles a highlevel update equest specification in Section 3. Section 4 pesents the design and implementation of RoleUpdate. We show some expeimental esults of unning RoleUpdate in Section 5, illustating its effectiveness and efficiency. Section 6 concludes the pape. 4

5 System Popety holds. Popety {z } Model Checking z } { Popety fails; A counte example is geneated. (a) The basic illustation of model checking. RBAC System Popety holds. Popety: Requested state is neve eachable. {z } Model Checking z } { No. Requested state is neve eachable. Popety fails; A counte example is geneated. update achievable? Yes. Requested state is not neve eachable, and can be constucted fom the counte example. (b) Update via model checking. Figue 5: Illustation of model checking and its usage fo updating. 2 Related Wok RBAC administation and analysis Many convenient RBAC administation models (e.g., [8, 21, 34]) ae at ou disposition. They povide significant advantages in access contol management. They define administative ules, e.g., specifying which administato can pefom what opeations. Howeve, high-level update is aely suppoted. It is geneally difficult and eo-pone, because usually the esulting state is expected to meet vaious constaints. To help administatos undestand RBAC policies, vaious RBAC policy analysis tools (RPATs) have been invented [4, 14, 23, 38, 39, 44]. RPATs usually answe if an RBAC system satisfies a popety. Howeve, little effot has been devoted to answeing the question: what if the RBAC system fails to meet the popety? When administatos find abnomalities with RPATs, RoleUpdate can assist in coecting them. Most secuity analysis poblems in liteatue basically can be stated as: given the cuent state γ, a quey q (e.g., whethe accesses to intenal documents ae only available to employees), and a state-change ule ϕ, can γ be taken to a state γ whee q evaluates to tue? If this is the case, the steps taking γ to γ may also be epoted to administatos so that they can follow them to make γ. Howeve, as the objectives ae diffeent, we believe this kind of epoting could hadly be consideed sufficient fo the ole updating poblem. RPATs objective is to analyze the system. So, thei input is just the popety to be examined. By contast, RoleUpdate aims to update the system; the input is the update equest. RPATs exploe evey possible sequence of actions, as long as they ae allowed by ϕ, to test if thee is such a γ whee q is tue. In this case, administatos do not have any contol of the esulting state. By contast, RoleUpdate seeks a esulting state that complies with administatos equest. In addition, most RPATs focus on use-ole assignments. Although it is agued that the ole-pemission elation might be teated similaly to the use-ole elation, the ole-pemission elation also deseves its own attention [29], especially in tems of ole updating. Vaious access contol popeties ae poposed and veification schemes ae devised to check the satisfiability of popeties. In [23], authos popose a tool to answe a set of inteesting popeties, including simple availability/safety, bounded safety and containment availability/safety. The tool povides a means to guaantee that secuity equiements ae always met as long as tusted uses abide by cetain behavio pattens [22, 23]. Howeve, an assumption is needed fo the usage of secuity analysis: the popeties hold in the cuent RBAC state [22, 23]. As mentioned above, this is not always the case. Role updating can be used to adjust the cuent RBAC state so as to exhibit desied popeties, while keeping the changes to the customized extent. 5

6 1 update 2 make P = {p 5, p 8, p 9} available via T = { 1, 2, 3, 4, 5, 6} 3 with 4 administatos admin 1, admin 2; 5 use-pemission constaints 6 (u 1, no-less-than {p 1}, no-moe-than {p 1, p 3, p 4}), 7 (u 2, no-less-than {p 1, p 3, p 4, p 5}, no-moe-than {p 1, p 3, p 4, p 5}), 8 (u 3, no-less-than {p 3, p 4, p 5}, no-moe-than {p 3, p 4, p 5, p 6, p 8}), 9 (u 4, no-less-than {p 7, p 8, p 9}, no-moe-than {p 3, p 5, p 6, p 7, p 8, p 9}); 10 esticted-ole constaints 11 ( 4, no-less-than {p 6, p 7}, no-moe-than {p 6, p 7, p 8, p 9}), 12 ( 8, no-less-than {p 5, p 6}, no-moe-than {p 5, p 6}); 13 ole-hieachy = {( 2, 8), ( 3, 7)}; 14 minimal; Figue 6: An example high-level update equest specification. Role engineeing Role engineeing attacts much eseach effot [7, 10, 26, 40, 41, 45]. Existing ole engineeing tools (erets) take use-pemission assignments as input and output use-ole assignments and olepemission assignments. erets may take into account some othe infomation such as business meanings, semantics, and uses attibutes. Taxonomically, RoleUpdate can be viewed as a ole engineeing tool. Howeve, ole updating woks when RBAC states have been defined and possibly deployed, wheeas erets usually define oles fom scatch. The focuses ae also diffeent. Role updating aims to answe administatos question whethe an update is achievable with espect to update constaints and how to geneate one, if any. By contast, erets put moe emphasis on how to define an appopiate set of oles. In the context of a ole life cycle, RoleUpdate is fo ole maintenance, while erets help with ole design. Thus, one may conside RoleUpdate as a complement to erets; RoleUpdate can be used to fine-tune the ideal state geneated by erets. RBAC udpate Ni et al. [29] studied the ole adjustment poblem (RAP) in the context of ole-based povisioning via machine-leaning algoithms. Though simila, the ole updating poblem diffes fom the RAP in seveal aspects. Fist, customized constaints on updates ae enfoced in RoleUpdate, wheeas it is unclea if these constaints could be suppoted in RAP. Second, ou ole updating is equest-diven, wheeas RAP is a leaning pocess. RAP and RoleUpdate ae both assistant tools fo administatos but with diffeent usage and oientation. Fisle et al. [16] investigated the semantic diffeence of two XACML policies and the elated popeties. Howeve, they do not conside how to make a diffeent desied state fom the cuent one. Ray [32] studied the admin 2 assign p 8 to 1; admin 2 assign p 8 to 2; admin 1 assign p 8 to 6; admin 2 evoke p 8 fom 1; admin 2 evoke p 8 fom 2; admin 1 evoke p 6 fom 6; admin 2 assign p 5 to 1; admin 1 assign p 5 to 6; admin 2 evoke p 5 fom 1; Figue 7: The update etuned by RoleUpdate when unning with the equest in Figue 6. eal-time update of access contol policies, in the context of database systems. They focused on tansaction popeties, instead of RBAC policies. 3 High-Level Update Request Specifications We do not conside the update of use-ole assignments, because uses ole membeships ae detemined by thei attibutes, jobs, titles, etc. When this infomation is enewed, administatos can accomplish use-ole assignments staightfowadly. Suppose the administatos want to update the RBAC configuation in Figue 1. Suppose futhe that the administatos specify the update equest as in Figue 6. This specification expesses the customized conditions on the potential updated system. In the est of this section, we illustate the use of RoleUpdate though this example. Running with this example, RoleUpdate etuns the steps, as shown in Figue 7, that the administatos can follow to make the changes; in the updated state, the administatos can assign {p 5, p 8, p 9 } to uses via 6. 6

7 Administative powe Line 4 specifies which administatos ae going to update the system. As mentioned befoe, it is common fo administative ules to egulate administatos opeations; that is, administatos have limited administative powe. A poposed update does not make sense unless the needed changes lie within administatos capabilities. RoleUpdate appeas moe useful when multiple administatos ae involved. Obseve the five actions by admin 1 and admin 2 : admin 2 assigns p 8 to 1 and 2, admin 1 assigns p 8 to 6, and admin 2 evokes p 8 fom 1 and 2. These inteleaving opeations equie close coopeation between admin 1 and admin 2 and caeful examination. By contast, RoleUpdate takes the coopeation among administatos into account automatically. Suppose that we eplace Line 4 with the following. administatos admin 3 ; That is, the administato admin 3, instead of admin 1 and admin 2, wants to update the system. Then RoleUpdate suggests an altenative: fist evoke p 6 fom 5 and then evoke p 6 fom 6. Howeve, admin 1 and admin 2 ae not authoized to pefom this altenative. Note that administatos powes ae configued in Figue 2. Contollable effects Administatos should be able to confine the effects of an update. With RoleUpdate, administatos can specify a cetain set of uses U and define what changes could happen to uses pemissions. Fo example, Alice at least has access to files unde /foo/ba1 but at most /foo/ba1 and /foo/ba2. Line 5 to Line 9 ae constaints on uses pemissions afte update. Fo example, by Line 6, administatos equies that u 1 have at least pemission p 1, but at most p 1, p 3, and p 4 in the potential new state. Note that uses still obtain pemissions via oles and even that uses ole assignments emain the same. Fo anothe example, Line 7 pescibes that u 2 s pemissions ae exactly {p 1, p 3, p 4, p 5 }. Conside the solution in Figue 7; administatos have to evoke p 8 fom 1, fo u 2 is assigned to 1 and cannot have pemission p 8, as equied by Line 7. By popely specifying constaints, administatos guaantee the tasks associated with uses in U pogess smoothly. Suppose that u 2 and u 4 coopeate to finish a task t, which equies that u 2 and u 4 ae entitled to pivileges {p 1, p 3, p 4, p 5 } and {p 7, p 8, p 9 }, espectively. Then Line 7 and Line 9 guaantee that the updated state, if any, would not disable t. When administatos ae specifying U, U often contains those uses fo whom the administatos ae not esponsible so that they have to ensue that the potential update does not affect such uses, and/o those uses whose pemissions ae designated by the administatos and vay within a ange. Fo uses outside the set U, thei cuent ole assignments and pemissions in γ ae neglected by RoleUpdate; that is, updates may change thei ole-assignments and pemission-assignments. Resticted update The pinciple of least pivilege is impotant in compute secuity and well suppoted by RBAC. Uses activate only the oles necessay to finish the undelying wok, but not all assigned oles. Fo example, a use Alice may activate the ole manage when she wants to evaluate an employee unde he depatment, and activates the employee ole fo outine woks. As a esult, uppe bounds should be put on oles pemission sets in compliance with the least pivilege pinciple. On the othe hand, some oles ae designed with expected functions; uses should be able to pefom a paticula job with such a ole. If associating with the ole a set of pemissions less than necessay, administatos may make the ole useless. Hence, it would be handy if administatos ae able to set the pemission sets of cetain oles within a ange. Line 10 to Line 12 shows constaints on oles pemissions afte update. Fo each selected ole (e.g., 4 ), administatos can impose a lowe bound (e.g., {p 6, p 7 }) and an uppe bound (e.g., {p 6, p 7, p 8, p 9 }) on the ole s pemissions. RoleUpdate assues that the ole is assigned to pemissions no less than those in the lowe bound and also no moe than those in the uppe bound. A equiement is that, the uppe bound (o the lowe bound) of the ange should be a supeset (o subset) of the set of all pemissions that is cuently assigned in γ. This is easonable, because the pemissions has cuently in γ ae enough to make it useful. We also find that, without this equiement, RoleUpdate s efficiency degades. Line 12 indicates that 8 s pemissions must still be {p 5, p 6 } afte update, because the lowe bound equals the uppe bound. We call oles like 8 invaiant oles. Despite the impotance of update, it is likely that administatos demand some oles be invaiants in ode to, fo example, peseve oles intuitions, business meanings o definitions. In this case, by letting the lowe bound of be its uppe bound, administatos equest RoleUpdate to find an update which does not change s pemission assignments. In othe wods, RoleUpdate may change those non-invaiant oles pemission assignments in the hope to find an update. In pactice, non-invaiant oles ae usually the ones unde administatos contol; othewise, even though an update is found, administatos would not be able to implement it and thus the update is of little value. If the administatos impose anothe esticted-ole 7

8 admin 2 assign p 8 to 1; admin 2 assign p 8 to 2; admin 1 assign p 8 to 6; admin 2 evoke p 8 fom 1; admin 2 evoke p 8 fom 2; admin 1 evoke p 6 fom 6; admin 2 evoke p 3 fom 3; admin 2 evoke p 4 fom 3; Figue 8: An altenative when the ole hieachy ( 3, 7 ) is not equied. constaint besides those in Figue 6. ( 6, no-less-than {p 6, p 9 }, no-moe-than {p 6, p 9 }) Then RoleUpdate epots that the equested update does not exist, which is indeed the case. Role hieachy Role hieachy is ecognized by the poposed NIST standad fo RBAC as one of the fundamental citeia [11]. It futhe mitigates the buden of secuity administation and maintenance. Usually, thee could be a natual mapping between ole hieachy and oganization s stuctue. It is impudent to alte a ole hieachy abitaily. Administatos can ask RoleUpdate to peseve the whole o pat of the oiginal ole hieachy. Line 13 tells that 2 and 3 ae still senio to 8 and 7, espectively, in the updated system. The equiement that 3 be senio to 7 stops RoleUpdate fom suggesting anothe solution, as shown in Figue 8. If following this appoach, administatos can assign {p 5, p 8, p 9 } via 3 and 6 ; howeve, 3 is no longe a senio ole of 7. Minimal update As long as an update is implemented, some changes ae made to the system. When two update solutions ae available, which one is moe pefeable? One pespective is to compae the changes they ecommend. The fewe changes ae needed, the close the esulting state to the oiginal state. Ideally, we may find an update such that none of its changes is edundant; that is, failue to implement any change theeof gives ise to a disqualified state. We say the update is minimal. Minimal update is valuable in seveal ways. Fist of all, minimal update causes few difficulties fo administatos to undestand the new RBAC state. The administatos ae esponsible fo the maintenance of the RBAC system. It is essential fo them to compehend the system s behavio. We can assume that administatos undestand the system well befoe updating. Howeve, changes to the system configuation have the poadmin 2 assign p 8 to 1; admin 2 assign p 8 to 2; admin 1 assign p 8 to 6; admin 2 evoke p 8 fom 1; admin 1 evoke p 6 fom 6; admin 2 assign p 5 to 1; admin 1 assign p 5 to 6; admin 2 evoke p 5 fom 1; Figue 9: Update in esponse to the equest in Figue 6 but without the minimality equiement. tential to obfuscate the system. Obviously, a smalle gap between the updated state and the oiginal one usually means a smalle degee to which administatos have to e-examine and e-lean the system. Secondly, minimal update possibly peseves moe peviously computed analysis esults. It is easonable to assume that the cuent RBAC state satisfies necessay popeties (othewise, it should have been adjusted). It is likely that moe popeties might be peseved with minimal update. Finally, minimal update is also desiable when authoization ecycling is deployed in access contol implementation [42, 43]. 2 In RoleUpdate, administatos can choose to equie each etuned update to be minimal in the sense that no change is edundant. Howeve, thee is a tadeoff between doing this and incuing exta computing ovehead. In Figue 6, Line 14 indicates administatos willingness to find a minimal update. If tuning the minimal equiement off, RoleUpdate would possibly not insist on the evocation of p 8 fom 2, fo p 8 being assigned to 2 does not contadict with the constaints. That is, RoleUpdate etuns the update in Figue 9. 4 Design and Implementation Figue 11 shows the achitectue of RoleUpdate. Its inteface accepts administatos input and pases the equest. We say a equest is canonical if (1) all administative opeations ae available, (2) uses pemissions ae equied to emain unchanged, and (3) no ole hieachy is equied to be peseved. Figue 10 shows an example canonical equest, whee P i is the set of pemissions that use u i has pio to updating. 2 Authoization decision-making is time-consuming and costly. Authoization ecycling caches the authoization decisions that ae made peviously and infe decisions fo fothcoming authoization equests. As an impotant mechanism fo access contol implementation, authoization ecycling makes use of cache to enhance pefomance; thee, policy update is a majo concen. Fo details, eades ae efeed to [9, 42, 43]. 8

9 update make P available via T with administatos all-administatos use-pemission constaints (u 1, no-less-than P 1, no-moe-than P 1), (u 2, no-less-than P 2, no-moe-than P 2), ; esticted-ole constaints ; ole-hieachy = ; Figue 10: An example canonical equest. Inteface update Update Constucto non canonical equests canonical equests counte example Update Tansfome canonical equests NuSMV Tanslato NuSMV pogams NuSMV Contolle NuSMV Figue 11: The achitectue of RoleUpdate. If canonical, the equest is fowaded to the NuSMV Tanslato; othewise, it is fist pocessed by the Update Tansfome, whee non-canonical equests ae tansfomed into canonical ones. Aftewads, the NuSMV Tanslato convets equests into NuSMV pogams. The NuSMV Contolle invokes NuSMV to execute those pogams. Accoding to the esults etuned fom NuSMV, the Update Constucto geneates an update epot, eithe a sequence of administative opeations which lead to desied RBAC system state o a message that the equest is unachievable. Algoithm 1 pesents RoleUpdate s pseudo-code. Line 2 belongs to the Inteface module. Line 3 epesents the Update Tansfome. Line 4 and Line 5 ae the main components of the NuSMV Tanslato module. Nomally, the NuSMV Tanslato would ceate a set G of NuSMV pogams fo each canonical equest. Howeve, since the execution of the NuMSV pogams tanslated diectly fom the equest easily esult in state explosions and memoy cashes, some eductions ae pefomed in advance [12]. The set G has the popety: an update is found, if and only if, the un of NuSMV with at least one pogam in G epots a counte-example. As indicated by Line 6, on eceiving the NuSMV pogams, the NuSMV Contolle schedules NuSMV pogams in inceasing ode by the numbe of vaiables, because NuSMV s pefomance highly depends on the numbe of vaiables in the input pogam. The NuSMV Contolle poceeds to execute each pogam with NuSMV; if any execution etuns a counte-example, it infoms the Update Constucto of the counte-example. The Update Constucto geneates the needed update and administative opeations necessay to institute the changes (Line 10 to Line 12). If minimal update is equied, futhe pocessing (Section 4.3) will be done. In the est of this section, we give details of each component. 4.1 Handling non-canonical equests We tied to use the model checking appoach diectly to evaluate non-canonical update equests. Ou expeience is that, an extensive numbe of vaiables ae needed to model complex equests, which often gives ise to state explosions and memoy cashes. The easons ae twofold. Fist, non-canonical equests enable much moe potential combinations of ole-pemission assignments than canonical equests do. Second, some eductions in [12] ae not applicable to non-canonical ones. It is not clea how to educe non-canonical equests effectively. Conside a non-canonical update equest issued against γ in Figue 12. Non-canonical equests ae tansfomed into canonical ones by adding dummy elements (e.g., uses, oles, use-ole assignments, and olepemission assignments) to γ; these dummy elements simulate those non-canonical conditions on the update. Usually, the obtained RBAC state, against which the canonical equest is checked, is moe complicated than γ. Fotunately, the constuction is polynomial. We tade off the simplicity of RBAC states fo the ability to cope with complex updates. By this modeling, we need only to focus on one unified poblem: evaluating canonical equests. 4.2 NuSMV pogam geneation NuMSV is the symbolic model checke that RoleUpdate employs to pefom model checking. The NuSMV Tanslato convets update equests into NuSMV pogams. A set of boolean vaiables ae defined to model the RBAC system. To use NuSMV, let φ denote the statement that a use could acquie exactly the pemissions in P via oles in T ; we ask if φ is always tue in all each- 9

10 Algoithm 1: Algoithm of RoleUpdate. Input: High-level update equest H, γ, and NuSMV popety type: AG o AX AG Output: update epot 1 begin /* Pase(H,Q) pases H and eads infomation into Q; it etuns a boolean value showing if any eo happened. */ 2 if!pase(h, Q) then show eo message; 3 if Q is non-canonical then Q TansCanonical(Q); /* pefom eductions on Q */ 4 Reduce(Q); 5 G TansNuSMV(Q, type); /* NuSMV s pefomance highly depends on the numbe of vaiables in the input pogam; so schedule NuSMV pogams in inceasing ode by the numbe of vaiables. */ 6 S G Schedule(G); 7 foeach g S G do 8 Invoke g with NuSMV; 9 if a counteexample is etuned then 10 constuct an update γ fom the counte-example; 11 if Minimal update is equied then γ Minimize(Q, γ, γ ); /* compute the needed administative opeations that take the RBAC system fom γ to γ */ 12 AdminOp computeadminopeation(γ, γ ); 13 show AdminOp and γ ; 14 etun γ ; show update unachievable epot; etun ɛ; end noncanonical update equest tansfomation canonical update equest Figue 12: An illustation of the tansfomation fom non-canonical update equests to canonical ones. able (NuSMV) states; 3 If it evaluates as tue, the use can neve obtain exactly all pemissions in P via oles in T, indicating that one cannot fulfill the equest without violating the update constaints. Othewise, NuSMV will geneate a counte-example, fom which RoleUpdate constucts an update. In the cuent implementation of RoleUpdate, only boolean vaiables and TRANS declaations ae used. An RBAC state is epesented by a valuation of boolean vaiables, wheeas TRANS declaations captue tansitions among RBAC states. Futhe exploations of NuSMV featues and othe model checking techniques could impove RoleUpdate s efficiency. 4.3 Minimal Update Inteestingly, the minimal update can be obtained in the same way we seek an update. Once an update is found, denote the RBAC state afte update as γ. As illustated in Figue 13, if a ole-pemission assignment appeas in exactly one of γ and γ, this assignment is changed 3 φ is defined ove the boolean vaiables. The checked popety is AG φ, whee A means always and G means globally; AG φ is a CTL (Computational Tee Logic) fomula, which is used to specify popeties in NuSMV. 10

11 (eithe emoved o added); denote the set of all such changed assignments as CA. Then the minimal update equiement is to detemine if all changes in CA ae necessay. The basic idea is to ask if the same goal could be achieved with a pope subset of CA. To answe this, we define vaiables to simulate CA and teat assignments outside CA as constants. This is done by adding dummy elements and imposing new update constaints. A new update equest is issued against RoleUpdate; this equest is the same as the oiginal one except that new esticted-ole constaints ae added. Howeve, the checked popety is whethe, stating fom the next state of γ, all eachable states satisfy φ. 4 If so, then γ itself is minimal. Othewise, fom the etuned counte-example, we could obtain γ. This γ is close to the minimal update than γ, because only a pope subset of CA is implemented. Note that this is a ecusive pocess; and thus a minimal update could be eached. Take the equest in Figue 6 fo example. Figue 14 shows an example calling stack of RoleUpdate. Receiving a equest with the minimality equiement, Role- Update fist emoves this equiement and seaches fo an update. Suppose that RoleUpdate finds the update shown in Figue 9; it poceeds to compute CA, which is CA = {( 6, p 8 ), ( 2, p 8 ), ( 6, p 5 ), ( 6, p 6 )}. By composing a new update equest, RoleUpdate goes on checking if thee exists such an update that the esulting changes ae a pope subset of CA. This stats a ecusive call. Then the same pocesses ae applied. This time, an update shown in Figue 7 is found and CA is computed to be {( 6, p 8 ), ( 6, p 5 ), ( 6, p 6 )}. Again, anothe ound commences. This time, RoleUpdate could not find any update, which implies that the update in Figue 7 is minimal; RoleUpdate etuns this update in esponse to the oiginal equest. 0 (a) (, p 1 ) CA 0 (c) (, p 1 ) CA 0 (b) (, p 1 ) CA 0 (d) (, p 1 ) CA Figue 13: Examples of assignments in CA. input update equest w/ minimality equiement (Figue 6) handle the equest w/t minimality equiement geneate update (Figue 9) input update equest w/ minimality equiement handle the equest w/t minimality equiement geneate update (Figue 7) input update equest w/ minimality equiement handle the equest w/t minimality equiement geneate update (un achievable) 5 Expeiments We implemented a pototype of RoleUpdate in Java. Expeiments wee pefomed with andomlygeneated RBAC systems on a machine with an Intel(R) Coe(TM)2 CPU 1.66GHz, and with 2GB of RAM unning Micosoft Windows XP Home Edition Sevice Pack 3. compute CA, y constuct new update equest etun the latest update compute CA, z constuct new update equest etun the latest update etun the latest update Data geneation To geneate each RBAC system, we adapted algoithms fom [41, 45] 5 ; γ is paameteized by nou (the numbe of uses), nor (the numbe of oles), nop (the numbe 4 In NuSMV, this is expessed by AXAG φ in CTL. 5 The latte is accessible via zhangd/oledata/. y CA = f( 6 ;p 8 ); ( 2 ;p 8 ); ( 6 ;p 5 ); ( 6 ;p 6 )g z CA = f( 6 ;p 8 ); ( 6 ;p 5 ); ( 6 ;p 6 )g Figue 14: The ecusive calling pocedue. 11

12 1 update 2 make P = input available via T = γ.r 3 with 4 administatos all-administatos 5 use-pemission constaints 6 (u 1, no-less-than P 1, 7 no-moe-than P 1), 8 (u 2, no-less-than P 2, 9 no-moe-than P 2), esticted-ole constaints ; 12 ole-hieachy = γ.rh; Figue 15: Expeimental update equest specification. of pemissions), nou R (the maximum numbe of oles that a use may be assigned to), and norp (the maximum numbe of pemissions that a ole may be assigned to). γ s use-ole elation (esp. γ s ole-pemission elation) is geneated by associating a numbe k of oles (esp. pemissions) with each use (esp. ole), whee k is andomly fom [1, nour] (esp. [1, norp ]). Without othewise stated, the paametes used fo tests ae nou = 2000, nor = 500, nop = 2000, nour = 5, norp = 150, noreqps = 200 and the ole hieachy is empty. One o moe paametes ae made vaiable in each goup of tests. Update equests ae paameteized by noreqps (the numbe of equested pemissions) and is geneated by andomly choosing a numbe noreqps of pemissions fom γ s pemission set. We let T be γ s ole set. Figue 15 shows the expeimental update equest, lines of which may be eplaced in each goup of tests and whee P i is the set of pemissions that use u i has pio to updating. Results Figue 16 shows the computing time equied fo each test. Since the data set is andomly ceated, fo each configuation of paametes, we an the test 5 times. The times in Figue 16 ae aveaged ove the 5 uns. Administative ules Figue 16a shows pefomance with espect to vaying numbe of administative ules (norules). We let an administato admin be a membe of ole a and eplace Line 4 of Figue 15 with the following. administatos admin Each assignment ule a can assign p with if p assigned to c is constucted as follows: (1) denote the numbe of oles in c as c and we let c [1, 4], and (2) andomly choose oles in c. Fo evocation ules a 12 Time (sec) Time (min) Time (min) Time (min) administative ules numbe of ules (a) vaying pecentage of exta pemissions 10% 20% 30% :2:3 1:1:1 3:2:1 (b) nor vaying ole hieachies (c) nor minimal update (d) nor Figue 16: The computing time fo evaluating update equests.

13 can evoke p fom, is also andomly chosen. Note that we guaantee that ules have effects on the oles that might be changed. The speed of RoleUpdate is quite good as fa as administative ules ae concened. The easons ae two-fold: (1) The tansfomation into canonical equests is fast. (2) Duing the tansfomation, Role- Update only inceases nou and nor but not nour; fotunately, RoleUpdate is scalable to nou and nor [12]. Contollable effects To test RoleUpdate s pefomance with espect to contollable effects, we geneated a atio α of exta pemissions. Fo each use u i, we define the following constaint and substitute it fo the coesponding line (u i, no-less-than P l,i, no-moe-than P m,i ) whee P l,i P i and P l,i = (1 α) P i, and P m,i P i and P m,i = (1+α) P i. Exta pemissions wee andomly chosen. Recall that P i is the set of pemissions that u i has pio to updating. Figue 16b shows the esults when α takes 10%, 20%, and 30%, espectively. It seems fom this expeiment that RoleUpdate is not sensitive to α, especially when nor 800. Role hieachy Figue 16c gives the test esults when the RBAC state involves ole hieachies. Role hieachies wee ceated in the following way. We ceated thee sets of oles R 1, R 2, and R 3 such that R i R j = fo i, j [1, 3] and i j; we andomly ceated γ.rh (R 1 R 2 ) (R 2 R 3 ) (whee γ.rh denotes γ s ole hieachy) such that each ole may have only a numbe h of junio oles whee h [1, 3]. This two-level layeed ole hieachy is common in pactical systems [19, 27, 31]. The x-axis is R 1 + R 2 + R 3. We tested thee configuations by vaying R 1 : R 2 : R 3. As the RBAC configuation needs to be flattened, nou R is inceased by 2 on aveage. This esults in notable ovehead. Howeve, the time taken was sensitive to the stuctues of ole hieachies: almost all uns with 1 : 2 : 3 wee much faste than 3 : 2 : 1. That is, the less senio oles thee wee, the faste RoleUpdate dealt with ole hieachies. Minimal update To evaluate how well RoleUpdate teats minimal update, the minimality equiement is inseted into the specification in Figue 15. Figue 16d epots the computing time when minimal update is pusued. Note that the time was aveaged ove 5 achievable equests. When nor = 600, the computing time could be almost 18 times geate than the case without the minimal update equiement. This is because RoleUpdate has to compute a numbe of intemediate updates, with the numbe depending on CA. It would be inteesting and useful to investigate how to educe the numbe of intemediate steps. In eal-wold lage-scale RBAC systems, we expect that only a small potion of uses have a numbe nour of oles and that the numbe of oles that ae unde specified administatos contol will be small. Hence, we conjectue RoleUpdate will be able to handle update equests in these RBAC systems, especially with the advances in model checking. 6 Conclusion To update an access contol system, we have pesented a tool RoleUpdate, which accepts and answes highlevel update equests. Expeiments confim the effectiveness and efficiency of RoleUpdate. We have epoted the theoetical esults of RoleUpdate in [12], including the computational complexity, the fomal tansfomation into model checking poblem, and the eductions. Howeve, the full-fledged RoleUpdate is fist epoted hee. RoleUpdate is still expeimental and we eget that it is not yet available to the public. Thee ae seveal avenues fo futue wok. RoleUpdate becomes awkwad when dealing with administative ules with negations, e.g., a can assign p if p assigned to 1 but not 2. The poblem with moe sophisticated administative models, whee negative conditions ae allowed, deseves futhe investigation. In addition, sepaation-of-duty (SoD) policies ae impotant in RBAC systems; howeve, enfocing SoD policies is difficult by itself [20]. The inteaction between updating and SoD policies poses new challenges. On the othe hand, if a seies of update equests ae issued, the final updated RBAC state may depend on the ode of the equests. These composite equests may take place in distibuted RBAC systems. We plan to investigate popeties of composite update equests and extend RoleUpdate to addess this poblem. 7 Acknowledgment We would like to thank D. Alva L. Couch fo shepheding this pape and the anonymous eviewes fo thei helpful comments. This wok is suppoted by National Natual Science Foundation of China unde Gant , , , National High Technology Reseach and Development Pogam of China unde Gant 2007AA01Z403, and Natual Science Foundation of Hubei Povince unde Gant 2009CDB298. This eseach is suppoted in pat by an Austalian Reseach Council Discovey Gant (DP ). This publication was made possible by a gant fom the Qata National Reseach Fund unde its NPRP Gant No

14 Its contents ae solely the esponsibility of the authos and do not necessaily epesent the official views of the Qata National Reseach Fund. Autho Biogaphies Jinwei Hu is a PhD student in School of Compute Science and Technology at Huazhong Univesity of Science and Technology, when submitting this pape. His cuent inteests ae the specification and analysis of access contol policies. Yan Zhang is a pofesso of School of Computing and Mathematics at Univesity of Westen Sydney. His eseach inteests ae in the aeas of knowledge epesentation, logic, and model checking. Ruixuan Li is an associate pofesso of School of Compute Science and Technology at Huazhong Univesity of Science and Technology. His eseach inteests ae in the aeas of distibuted computing and distibuted system secuity. Refeences [1] AHMED, T., AND TRIPATHI, A. R. Static veification of secuity equiements in ole based cscw systems. In SACMAT 03, pp [2] AL-SHAER, E., MARRERO, W., EL-ATAWY, A., AND ELBADAWI, K. Netwok configuation in a box: Towads end-to-end veification of netwok eachability and secuity. In ICNP (2009), pp [3] ALIMI, R., WANG, Y., AND YANG, Y. R. Shadow configuation as a netwok management pimitive. In SIG- COMM (2008), pp [4] BAUER, L., GARRISS, S., AND REITER, M. K. Detecting and esolving policy misconfiguations in accesscontol systems. In SACMAT 08, pp [5] CIMATTI, A., CLARKE, E., GIUNCHIGLIA, E., GIUNCHIGLIA, F., PISTORE, M., ROVERI, M., SEBAS- TIANI, R., AND TACCHELLA, A. NuSMV Vesion 2: An OpenSouce Tool fo Symbolic Model Checking. In Poc. Intenational Confeence on Compute-Aided Veification (CAV 2002) (2002), LNCS, pp [6] CLARKE, E. M., GRUMBERG, O., AND PELED, D. A. Model Checking. MIT Pess, [7] COLANTONIO, A., PIETRO, R. D., OCELLO, A., AND VERDE, N. V. A fomal famewok to elicit oles with business meaning in bac systems. In SACMAT 09, pp [8] CRAMPTON, J. Undestanding and developing olebased administative models. In CCS (Alexandia, VA, USA, Nov. 2005), pp CCS 05. [9] CRAMPTON, J., LEUNG, W., AND BEZNOSOV, K. The seconday and appoximate authoization model and its application to bell-lapadula policies. In ACM Symposium on Access Contol Models and Technologies (2006), pp [10] ENE, A., HORNE, W. G., MILOSAVLJEVIC, N., RAO, P., SCHREIBER, R., AND TARJAN, R. E. Fast exact and heuistic methods fo ole minimization poblems. In SACMAT 08, pp [11] FERRAIOLO, D. F., SANDHU, R. S., GAVRILA, S. I., KUHN, D. R., AND CHANDRAMOULI, R. Poposed NIST standad fo ole-based access contol. ACM Tans. Inf. Syst. Secu. 4, 3 (2001), [12] HU, J., ZHANG, Y., LI, R., AND LU, Z. Role updating fo assignments. In Poceedings of 15th ACM symposium on access contol models and technologies (SAC- MAT 2010) (Pittsbugh, USA, June ), pp [13] IRWIN, K., YU, T., AND WINSBOROUGH, W. H. Enfocing secuity popeties in task-based systems. In SAC- MAT 08, pp [14] JHA, S., LI, N., TRIPUNITARA, M., WANG, Q., AND WINSBOROUGH, W. Towads fomal veification of olebased access contol policies. IEEE Tans. Dependable Secu. Comput. 5, 4 (2008), [15] KARJOTH, G. The authoization sevice of tivoli policy diecto. In ACSAC 01: Poceedings of the 17th Annual Compute Secuity Applications Confeence (Washington, DC, USA, 2001), IEEE Compute Society, p [16] KATHI FISLER, SHRIRAM KRISHNAMURTHI, L. M., AND TSCHANTZ, M. Veification and change impact analysis of access-contol policies. In ICSE (May 2005). [17] KERN, A. Advanced featues fo entepise-wide olebased access contol. In ACSAC 02: Poceedings of the 18th Annual Compute Secuity Applications Confeence (Washington, DC, USA, 2002), IEEE Compute Society, p [18] KERN, A., KUHLMANN, M., SCHAAD, A., AND MOF- FETT, J. D. Obsevations on the ole life-cycle in the context of entepise secuity management. In SACMAT (2002), pp [19] KERN, A., SCHAAD, A., AND MOFFETT, J. D. An administation concept fo the entepise ole-based access contol model. In SACMAT (2003), pp [20] LI, N., BIZRI, Z., AND TRIPUNITARA, M. V. On mutually-exclusive oles and sepaation of duty. In CCS (2004), pp [21] LI, N., AND MAO, Z. Administation in ole-based access contol. In ASIACCS (2007), pp [22] LI, N., MITCHELL, J. C., AND WINSBOROUGH, W. H. Beyond poof-of-compliance: secuity analysis in tust management. J. ACM 52, 3 (2005), [23] LI, N., AND TRIPUNITARA, M. V. Secuity analysis in ole-based access contol. In SACMAT (2004), pp

15 [24] LI, N., TRIPUNITARA, M. V., AND WANG, Q. Resiliency policies in access contol. In CCS (2006), pp [25] MCPHERSON, D. Role-based access contol fo multi-tie applications using authoization manage: [26] MOLLOY, I., CHEN, H., LI, T., WANG, Q., LI, N., BERTINO, E., CALO, S. B., AND LOBO, J. Mining oles with semantic meanings. In SACMAT (2008), pp [27] MOLLOY, I., LI, N., LI, T., MAO, Z., WANG, Q., AND LOBO, J. Evaluating ole mining algoithms. In SACMAT (2009), pp [28] MONDAL, S., SURAL, S., AND ATLURI, V. Towads fomal secuity analysis of gtbac using timed automata. In SACMAT 09, pp [29] NI, Q., LOBO, J., CALO, S. B., ROHATGI, P., AND BERTINO, E. Automating ole-based povisioning by leaning fom examples. In SACMAT (2009), pp [30] OSBORN, S. L., SANDHU, R. S., AND MUNAWER, Q. Configuing ole-based access contol to enfoce mandatoy and discetionay access contol policies. ACM Tans. Inf. Syst. Secu. 3, 2 (2000), [31] PARK, J. S., COSTELLO, K. P., NEVEN, T. M., AND DIOSOMITO, J. A. A composite bac appoach fo lage, complex oganizations. In SACMAT (2004), pp [32] RAY, I. Applying semantic knowledge to eal-time update of access contol policies. IEEE Tans. Knowl. Data Eng. 17, 6 (2005), [33] REITH, M., NIU, J., AND WINSBOROUGH, W. H. Towad pactical analysis fo tust management policy. In ASIACCS 09, ACM, pp [34] SANDHU, R. S., BHAMIDIPATI, V., AND MUNAWER, Q. The ARBAC97 model fo ole-based administation of oles. TISSEC 2, 1 (1999), [35] SANDHU, R. S., COYNE, E. J., FEINSTEIN, H. L., AND YOUMAN, C. E. Role-based access contol models. IEEE Compute 29, 2 (Febuay 1996), [36] SCHAAD, A., LOTZ, V., AND SOHR, K. A modelchecking appoach to analysing oganisational contols in a loan oigination pocess. In SACMAT 06, pp [37] SCHAAD, A., MOFFETT, J. D., AND JACOB, J. The ole-based access contol system of a euopean bank: a case study and discussion. In SACMAT (2001), pp [38] SOHR, K., DROUINEAUD, M., AHN, G.-J., AND GOGOLLA, M. Analyzing and managing ole-based access contol policies. Knowledge and Data Engineeing, IEEE Tansactions on 20, 7 (July 2008), [39] STOLLER, S. D., YANG, P., RAMAKRISHNAN, C., AND GOFMAN, M. I. Efficient policy analysis fo administative ole based access contol. In CCS 07. [40] VAIDYA, J., ATLURI, V., AND GUO, Q. The ole mining poblem: Finding a minimal desciptive set of oles. In SACMAT (2007), pp [41] VAIDYA, J., ATLURI, V., AND WARNER, J. Rolemine: mining oles using subset enumeation. In CCS (2006), pp [42] WEI, Q., CRAMPTON, J., BEZNOSOV, K., AND RI- PEANU, M. Authoization ecycling in bac systems. In SACMAT (2008). [43] WEI, Q., RIPEANU, M., AND BEZNOSOV, K. Coopeative seconday authoization ecycling. In HPDC (2007). [44] XU, W., SHEHAB, M., AND AHN, G.-J. Visualization based policy analysis: case study in selinux. In SAC- MAT 08, pp [45] ZHANG, D., RAMAMOHANARAO, K., EBRINGER, T., AND YANN, T. Pemission set mining: Discoveing pactical and useful oles. In ACSAC (2008), pp