Full Paper NNGT Int. J. on Information Security, Vol. 2, Feb 2015
To Summarize the Problem of Non-Conformity in Concrete RBAC-Based Policies: Synthesis, System Proposal and Future Directives Faouzi JAIDI† and Faten LABBENE AYACHI †† ,
[email protected] [email protected] Dig ital Security Research Unit (DSRU), Higher School of Co mmun ication of Tunis (Sup'Co m), Tunis, Tunisia Summary
concrete imp lementation of the security policy in the language of the target DBMS. On the other hand, DBMSs can easily permit the following malfunctions. Illegal updates not init ially planned caused by intrusion attempts or illegal delegations of rights. Anomalies in the expression of the policy related to the use of more than a unique access control model. Inner threats relative to illegal access made by authorized users. These vulnerabilities can corrupt the compliance of the access control policy. Our goal is to define a system for validating and verify ing the conformity of low level access control policies managed by RDBMSs [24]. This is following six basic phases. The first phase concerns the design of the policy using the SecureUML modeling language. The second phase translates the obtained specification to the B notation, and allows the proceeding to a preimplementation validation. The third phase is carried out after the imp lementation and the evolution of the po licy. It extracts from the DBM S the description of the low level policy. The fourth phase defines a model t ransformat ion fro m SQL scripts to B notation. This leads furthermore, in a fifth step, to formally validate and verify the conformity of the imp lemented policy regard ing its valid specification. The sixth phase involves the adjustment and optimizat ion of the policy once validated. Using a log ic-like language is highly important since it offers a solid environ ment to reach this purpose. The remainder of the paper is structured as follows. Section 2 introduces the background of this work. Sect ion 3 discusses the access control challenges. Section 4 presents the motivating examples fo r this work. Sect ion 5 defines a classification of the non-compliance anomalies. Section 6 introduces our contribution to validate and verify the conformity of concrete RBA C-based policies and illustrates its relevance via a case study. Section 7 discusses related works. Sect ion 8 discusses the proposed solution and defines future directives structured as system extensions. Section 9 concludes the paper.
The main feature of a secure information system is protecting sensitive data and services of an organization. This goal can be achieved via enforcing various security controls such as authentication, authorization, encryption, intrusion detection, audit, availability and privacy mechanisms. Among those mechanisms, the access control is considered as one of the most important and strong driving forces for protecting the data and preserving the privacy. It orchestrates access to resources based on appropriate rights in defined policies. On another hand, resources in charge of administrating access control policies, like Data Base M anagement Systems (DBM Ss), can easily permit the following malfunctions. (1) The record of illegal updates leading to non-compliance between the concrete instance of the policy and its original specification. This can occur following an intrusion attempt or an illegal delegation of rights. (2) DBM Ss usually support several mechanis ms for managing access control such as DAC, M AC, RBAC based access, etc. This can lead to redundancy, inconsistency and contradiction in the expression of the low level policy if it is managed using more than one mechanism. In this paper, we provide a sy nthesis of the problem of non-conformity in concrete RBAC-based policies. Then, we introduce a formal system to face this problem. The proposal relies on logic-like formalisms which offer a solid environment to verify access control properties. After that, we discuss the relevance of our proposal and provide future directives.
Key words: RBAC; Formal Validation; Databases Security; Conformity Verification; WCCAIS.
1. Introduction One of the most important and highly demanded security services in information systems is access control that can grant or deny the execution of actions depending on a given policy. Several studies have emphasized the advantage of integrating security engineering in the software development life cycle leading to the following advantages. (1) The use of a single framework for the specification of both functional and security models. We cite, in this context, SecureUM L [6], [20] and UM Lsec [12], [13] approaches. (2) The automatic generation of
© N&N Global Technology 2015 DOI : 02.IJIS.2015.1.2
1
Full Paper NNGT Int. J. on Information Security, Vol. 2, Feb 2015
2. Access Control: Service, Mechanis ms and Models
Vault allows restrict ing access to sensitive data even for database administrators.
2.1 Access Control Service and Policy
2.3 Access Control Models
Access control is any mechanis m by which a system grants or revokes the rights for active entit ies, the subjects, to access some passive entities, the objects, or perform some action. It organizes the access depending on a given policy. An access control policy is defined as the set of laws, rules and practices that regulate how sensitive informat ion and other resources are managed, protected and distributed within a specific system. It shall identify the security objectives of the system and the threats to the system. It treats main ly three aspects. The physical aspect defines procedures and means to protect resources fro m risks and physical access. The administrative one manages the organizational security and the correspondent’s procedures within the organization. The logic aspect defines legitimate actions a user can perform, it contain the identification, authentication and access control mechanis ms.
In the literature, three main families of access control models are defined. 2.3.1 Discretionary Access Control Discretionary Access Control (DA C) appeared in the 1970s, main ly with Butler Lampson [25] who introduced the notion of subject, object and action and defined the structure of the access control matrix. This model is defined as a means of restricting access to objects based on the identity of subjects and/or groups to which they belong. The controls are discretionary in the sense that a subject with access permission is capable of passing that permission (perhaps indirect ly) on to any other subject (unless restrained by mandatory access control). 2.3.2 Mandatory Access Control Mandatory Access Control (MAC) [26], [27] is based on the notion of security level: objects and subjects are classified by confidentiality level and authorized actions are derived based on this level. Th is approach was motivated by the need of providing stronger security and in particular to prevent unauthorized accesses to protected resources by the use of Trojan Horses.
2.2 Access Control Mechanisms for Relational DataBases Several mechanisms can be enforced collectively fo r assuring the control of authorized and preventing unauthorized accesses in RDBM Ss. Below is a listing of the principal mechanisms: 1.
2. 3. 4. 5.
6.
7. 8.
2.3.3 Role Based Access Control
Passwords: DBMSs allow associating passwords to identify users and enforcing passwords for activating roles. Privileges: DBM Ss provides system privileges and object privileges allowing users to perform actions across the system and on specified database objects. Views: relational databases provide views that may be used for restricting access to data. Triggers: triggers can automatically enforce security rules, especially enforcing authorizat ion constraints. Stored procedures: Stored procedures can be used for defining privileges associated with a user’s job functions and ensuring that access to data is according to defined rules. Encryption mechanisms: they concern several applications such as passwords encryption, data encryption, digital signature or authorization tickets, etc. Enforcing access control policies based on different models such as DAC, MAC, RBAC, etc. Specific mechanis ms: they depend on the used DBMS, for examp le the co mponent Oracle Database
© N&N Global Technology 2015 DOI : 02.IJIS.2015.1.2
RBAC (Role Based Access Control) [18], [1] manages the access to resources based on roles assigned to users. It defines which user(s) have right(s) to access to given resource(s) based on role(s) assigned to him (them). So, the basic concept of this model is a role which is a function within an organization. The access control based on roles defines various dimensions of RBA C conceptual models. RBA C0 , the base model called core model, defines the min imu m requirements for any system to support RBAC. RBA C1, called hierarchical RBA C, adds to RBAC0 the concept of role hierarchies that is the case when roles inherit priv ileges and permissions from other ro les. RBAC2, called constrained RBA C, adds to the core model the notion of constraints which are restrictions on the RBAC co mponents namely separation of duty, prerequisite and cardinality constraints. The global model o f RBA C, called consolidated model o r RBAC3 , includes both the hierarchy and constraint concepts. It contains the RBA C1 and the RBAC2 models and by consequence the RBA C0 model. Figure 2 presents components, relations between components and constraints of the RBA C3 model. Many proposals have been made for this family called x-Based Access Control models, as the notions of
2
Full Paper NNGT Int. J. on Information Security, Vol. 2, Feb 2015
etc. If this ro le is not used wisely, a malicious administrator can corrupt a security policy and create other policy breaches.
time (Temporal-RBAC, Generalized-Temporal-RBAC), teams (Team -BAC), tasks (task-LAC), latt ice (LatticeLA C), o rganizat ions (Organization-BAC) or contexts (Context-LA C) have been proposed to structure rights.
3.2 Separation of Security Administrative Duties Role engineering has emerged as a separate discipline which main objective is to equip security architects [19] with co mplete and necessary tools to develop trusted RBAC based policies with respect to the following three requirements: 1. 2. 3.
Fig. 1. The RBAC model
The security architect is neither concerned with intrusion detection nor with security audit wh ich are the responsibility of the security administrator. However, both the security architect and administrator should coordinate their actions if the verification step detects a significant abnormality. This separation of administrative roles works for better management of access control policies, greater transparency in policies developments and especially a separation of duties as far as security tasks are concerned. Hence, with regard to security, it is interesting to know who does what?
3. Data Access Control Challenges Database security is still a challenging topic as far as access control to data is concerned. This section deals with the principal challenges that can face the access control process.
3.1 Access Control Exposure to DBMSs Inner Threats Database management systems occupy a prominent place in the information system architecture. They perform a dual role or function: (1) the role of network firewalls in charge of controlling access to data, (2) their leg itimate role of data managers as they implement all the advanced data management features. This dual role is a cause of brittle in database servers for the following two main reasons:
3.3 Reverse Engineering Access Control Policies Extracting information concerning the design and specification of a concrete system or retro-conception is an act of reverse engineering. The reverse engineering in database context allows the generation from an existing database of the following outputs: Data Physical Model, Entity-Relationship diagram, UM L persistent class diagram o r DDL scripts. The reverse engineering process is incapable of inventing. Reverse engineering a database provides better guidelines when changes are performed to the data physical model. It basically relies on the exploitation of the DBMS dict ionary. Most of existing software engineering tools allow ext racting the functional models, but no co mplete contribution for security models extraction. We are convinced of the urgency of this topic given the challenges of securing data.
The access control policy is stored in the same place and managed in the same way as the data it protects [24]. The administrator of the database server has a super power that can be harmful if the case when the admin istrator happens to be corrupt.
An immed iate consequence is that the access control policy is highly exposed to corruption attempts. The DBMS ad ministrator, v ia its administrative ro le, has power increasingly disputed when the safety of data is threatened [8]. Indeed, administrative roles are naturally powerful and grant more or less wide ad min istrative privileges. For example, the ro le “SYSDBA” in Oracle DBMS gives its owner the privilege to create or delete users, to access to any data, to manage application roles,
© N&N Global Technology 2015 DOI : 02.IJIS.2015.1.2
Specifying security needs, mastering and validating its basics and expressiveness. Verify ing the integrity of the policy throughout its lifecycle since it is highly exposed to corruption. Evolv ing the policy according to new business needs.
4. Motivating Examples Theoretically, a DBMS should be accessed only by authorized users. However, this restriction can be circu mvented. A particular crucial problem is related to
3
Full Paper NNGT Int. J. on Information Security, Vol. 2, Feb 2015
inner threats. The following scenarios [23] are possible in DBMSs: 1. 2.
3. 4.
5.
Hidden users and hidden roles created and granted access rights by an admin istrator abusing his power. Hidden access flow: users granted the privilege “create any role” or g ranted roles with the privilege “with ad min option” may delegate those roles to other users, and therefore generate a new potential access flow invisible fro m outside the database. The absence of restrictions that control the empowerment of a ro le to reduce it to the minimu m necessary. The coexistence in the DBM S of access control mechanis ms based on different models such as RBAC, DA C and MAC may cause conflicts or redundancy in the exp ression of the policy. The violation of imp licit negative authorizations since it is difficu lt to verify if a negative authorization exp ressed during the specification is still enforced in the DBMS.
This class contains access control ru les that are syntactically conform to RBAC model, but not initially foreseen during the specificat ion of the access control policy. Indeed, an access control rule is classified in this category of anomalies, if it verifies at least one of the following conditions:
The motivating scenarios highlight anomalies that can cause non-compliance between an imp lemented policy and its specification. Th is section focuses on the logic definit ions of the correspondent anomalies. To do that, we start by casting a glance at the logic formalization of an RBAC process. The basic concepts of RBA C process are set as follows. U denotes the set of authorized users, R denotes the set of roles, O denotes the set of objects, A denotes the set of actions, and P denotes the set of permissions (possible actions on objects) noted: P A O and defined by the set of couples (A i , Oj ). We formalize the basic access control rules as follows:
Aur: U R, noted also: AUR U R
Arr: R Rnoted also: ARR R R
Apr: P Rnoted also: APR P R
(1)- Aur represents the set of couples (Ui , Rj ) that characterizes the users-roles assignments. (2)- Arr describes the roles-roles assignments defined by the set of couples (Ri , Rk ). (3)- Apr illustrates the assignment of permissions to roles defined by the set of couples (Pi , Rj ). We note ACP the access control policy defined on a database schema. Hence, ACP = (U, R, P) with its
© N&N Global Technology 2015 DOI : 02.IJIS.2015.1.2
5.1 Anomalies of Inconsistency
5. Classification of Non-Conformity Anomalies
correspondent relations Aur, Arr and Apr. The V&V process requires defining and putting in duality two different representations. To do that, we keep the previous notations to formalize the specificat ion of the access control policy, and we define the new sets U’, R’, O’, A’, P’ and ACP’ with its relations Aur’, Arr’ and Apr’ to formalize the concrete version of that policy. Based on the defined notations, we classify the non-compliance anomalies like fo llo ws.
4
It introduces a new user not initially defined. Th is case corresponds to a non equivalence between the sets of users; U’ – U . It in itiates a new ro le not init ially identified. Th is case is characterized by the difference between the sets of roles; R’ – R . It illegally assigns a role to another one. This can be identified when Arr’ – Arr . It unlawfully attributes one or more roles to one or more users. This can be detected when Aur’– Aur . Also, when this rule illegitimately associates one or more permissions to one or more ro les. This case becomes visible when Apr’ – Apr .
Normally, ro les related to administrative functions or application functions are in itially identified. The same applies to the set of users which are defined and fixed a priori. So, the existence of new users or new roles not initially specified can be interpreted as an attempted offense.
5.2 Anomalies of Contradiction This category of anomalies regroups invalid access control rules relative to the conceptual schema of the policy. The concept of valid or invalid ru le is defined regarding the specified constraints. Constraints are mapped to invariants and by consequence must be preserved during all the phases of the system life cycle. So, a ru le that does not preserve all the constraints is considered as invalid and can lead to contradictions. We list in addition to the authorization constraints the SSoD, DSo D, prerequisite, and cardinality constraints [11] defined as follows:
Full Paper NNGT Int. J. on Information Security, Vol. 2, Feb 2015
Static Separat ion of Duty (SSo D): it includes SSD-Role wh ich means that conflict ing or contradictory roles should not be assigned to the same user; SSD-Permission which means that conflicting permissions cannot be assigned to the same role; and SSD-User which means that conflicting users should not be assigned to the same ro le. Dynamic Separation of Duty (DSoD): defined as conflicting ro les must not be activated during the same session. Prerequisite Constraint: it contains PrerequisiteRole constraint that requires that a role R1 cannot be assigned to the user U if the ro le R2 is not already assigned to U, and Prerequisite-Permission constraint which suggests that a permission P1 cannot be assigned to the role R if the permission P2 is not already assigned to R. Card inality Constraint: it gives restrictions on the number of elements which can be linked to each other.
which are initially specified. This can falsify the global behavior of the access control process, introduce a non coherence in the low level policy and lead the system to dead lock states. The following cases are possible:
An access control policy is inco mplete due to one of the following two situations. (1) Part ial imp lementation of the access control policy which case must be remedied otherwise it degenerates into security holes. (2) Malicious acts which were facilitated due to a powerfu l user assigned sufficient privileges to do so.
5.3 Anomalies of Redundancy Redundancy anomalies belong to access control rules that express the same semantics and coexist in the target system. A trivial examp le of redundancy is defined as follow. If the role Ri is assigned to the user Uk , and the role Rj is a subset of the role Ri . Then, the role Rj is by inference assigned to the user Uk. In other words, if (Uk , Ri ) Aur’ and (Rj , Ri ) Arr’ then (Uk , Rj ) must not be defined in Aur’ to avoid redundancy. The coexistence of different access control mechanisms may be at the origin of redundant access control rules. For example, we can define the following redundant rules. In RBAC [18], [1] model, we assign the privilege “priv1” to the user “user1” via the assignment of the role “role1” to that user:
6. Our Proposal to Validate and Ve rify the Conformity of RBAC-Based Policies The two terms validation and verification are confusedly used in literature. However, the validation is concerned with the comparison of a concrete policy to its specification in order to check its conformity, while the verification is concerned with the co mparison of the concrete policy to its real imp lementation in order to control its exactitude. In this section, we present our contribution to validate and verify the conformity of RBAC based policies.
(1): grant priv1, priv2 on object1 to role1 (2): grant role1 to user1
Using the DAC model, we can assign directly the same privilege to the same user:
6.1 Description of the Proposed System Figure 2, illustrates the proposed system [24]. The global objective of this system is to establish and maintain coherence and conformity between the specificat ion and the implementation of access control policies. Our proposal [24] basically deals with the following question. In terms of access control, does an informat ion system actually do what was planned for it to do?
(1): grant priv1 to user1
5.4 Partially Implemented Specification Anomalies This category of anomalies belongs to a partial implementation of access control policies. It is characterized by the nonexistence of policy elements
© N&N Global Technology 2015 DOI : 02.IJIS.2015.1.2
The absence of users initially defined. This case corresponds to a non equivalence between the sets of users; U – U’ . Roles init ially identified are not implemented. This case is characterized by the difference between the sets of roles; R – R’ . A couple of roles (Ri , Rk ) prev iously considered in the role to role assignment is not defined. Th is can be identified when Arr – Arr’ . An assignment of one or more roles to one or more users is not implemented. This situation can be detected when Aur – Aur’ . One or more permissions attributed to one or more roles in the specification are not considered. This case becomes visible when Apr – Apr’ .
5
Full Paper NNGT Int. J. on Information Security, Vol. 2, Feb 2015
Fig. 2. The proposed system to verify and validate access control policies.
We cover three important steps in the implementation of access control policies. (1) The specification of the policy invariants. (2) The validation of the imp lemented policy regard ing its original specification. (3) The adjustments and optimization of the policy. Indeed, the objective during the specification phase is to capture the maximu m o f security needs of enterprise applications and to distinguish the invariants that must meet any concrete instance of the access control policy. The security architect disposes, during this phase, of modeling languages that extend classical applications modeling languages. Adopting a Model Driven Architecture (MDA) approach is interesting in systems development and allows especially reach ing the system imp lementation via refinements of the verified specificat ion. During the validation phase, the specification and the concrete instance are facing in a logical framework allo wing formal reasoning and compliance demonstration. The optimization phase corrects the redundancy anomalies and helps to check the properties of the g raph of roles, to calculate the power of a role, etc. Obtained results allow
© N&N Global Technology 2015 DOI : 02.IJIS.2015.1.2
the adjustment and the up to date of the correspondent policy.
6.2 The Validation and Verification Process The V&V process, defined in figure 3, consists of six basic steps that make up the body of our approach [22]. Phase 1 consists of specifying access control policies during the specification phase of the databases. It is based on SecureUM L [6], [20] as modeling language. Phase 2 aims to encode the obtained functional and security models in a logic-like notation (we are concerned in this paper with using the B notation). It is performed via adopting the B4Msecure tool [4] to our context. Phase 3 defines reverse engineering techniques to extract RBA C1Based policy enforced by the Oracle DBMS. Phase 4 defines the corresponding rules for transforming of the obtained DDL scripts to the B notation. Phase 5 consists to formally validate the conformity of the concrete policy regarding its specification. Finally, Phase 6 assure the adjustment and optimizat ion of the valid policy. At the end of this phase, we should obtain a valid and optimized access control policy.
6
Full Paper NNGT Int. J. on Information Security, Vol. 2, Feb 2015
Fig. 3. The V&V process [22].
We illustrate the importance and the applicability of our proposal through the following case study.
patients. The security part of the system defines five users: two nurses Alice and Bob, two doctors Charlie and David, and Paul a secretary. Doctors and nurses are part of the med ical staff.
6.3.1 Description of the Samp le
6.3.2 Undergoing Phases 1 and 2
The example describes a small part of a Medical Information System (used in [21]). Its functional part contains three elements: patients, doctors and medical records. Each medical record belongs to exactly one patient. Its content stores confidential data that must be managed only by doctors responsible for the correspondent
After specifying the functional and the security models of the correspondent system, we proceed to the transformation of the specification to a logic-like language. The translation of the specified policy, defined in our case study, to the B notation is described below:
6.3 Case Study
© N&N Global Technology 2015 DOI : 02.IJIS.2015.1.2
7
Full Paper NNGT Int. J. on Information Security, Vol. 2, Feb 2015
... SETS USERS = {Alice, Bob, Charlie, David, Paul }; ROLES = {Doctor, Nurse, Secretary,MedicalStaff }; OBJECTS={Patient,MedicalRecord, MedicalRecord_Validate}; ACTIONS = {read,create,modify,delete, fullAccess, readOp, modifyOp};… VARIABLES UsersRolesAssig,Roles_Hierarchy, PermissionsRolesAssig, … INVARIANT UsersRolesAssig: USERS --> POW(ROLES) & Roles_Hierarchy : ROLES ROLES & PermissionsRolesAssig: ROLES --> (OBJECTS * ACTIONS)&… INITIALISATION UsersRolesAssig := {(Alice|->{Nurse}), (Bob|-> {Nurse}), (Charlie|-> {Doctor}),(David|-> {Doctor}), (Paul|-> {Secretary})} || Roles_Hierarchy := {(Nurse|-> MedicalStaff), (Doctor|-> MedicalStaff)} || PermissionsRolesAssig:={(NURSE|->(MedicalRecord |-> {create,read})), (DOCTOR|>(MedicalRecord|-> {modify,read})), (DOCTOR|-> (MedicalRecord_Validate|-> {readOp})), (Secretary|->(Patient|-> {create})) } || …
6.3.4 Undergoing Phase 4 The encoding of the extracted policy into B notation should output a result similar to the one described below: … SETS USERS’ = {Alice, Charlie, David, Martin, Paul, Marie}; ROLES’ = {Doctor, Nurse, Secretary, MedicalStaff, MedicalStudent}; OBJECTS’ = {Patient, MedicalRecord, MedicalRecord_Validate}; ACTIONS’ = {read, create, modify, delete, fullAccess, readOp, modifyOp};… VARIABLES UsersRolesAssig’, Roles_Hierarchy’, PermissionsRolesAssig’, … INVARIANT UsersRolesAssig’: USERS’ --> POW(ROLES’) & Roles_Hierarchy’ : ROLES’ ROLES’ & PermissionsRolesAssig’: ROLES --> (OBJECTS * ACTIONS)& … INITIALISATION UsersRolesAssig’:={(Alice|->{Nurse}), (Charlie|-> {Doctor}),(David|->{Doctor}), (Martin|-> {MedicalStudent}), (Paul|-> {Secretary}), (Paul|-> {Nurse}), (Marie|-> {Secretary})} || Roles_Hierarchy := {(Nurse |-> MedicalStaff), (Doctor |-> MedicalStaff), (Secretary |-> MedicalStaff)} || PermissionsRolesAssig’:= {(NURSE|>(MedicalRecord |-> {create,read})), (DOCTOR|-> (MedicalRecord |-> {modify,read})), (DOCTOR|-> (MedicalRecord_Validate |-> {readOp})), (Secretary|-> (Patient|-> {create,read})), (MedicalStudent|-> (MedicalRecord|-> {modify}))} || …
Normally we proceed after this step to verifying the specification. The AtelierB and ProB tools are used for this purpose. Let suppose, for the next , that the specification is valid and the system is implemented. We suppose also that after a period of time, the access control policy has evolved to a new state where significant changes are introduced. 6.3.3 Undergoing Phase 3
6.3.5 Undergoing phase 5
To extract the low level po licy, we apply the defined reverse engineering techniques (not under the scope of this paper). As a result, DDL statements are generated like below:
The approach has to identify existing non-compliance anomalies. Since the security architect may not be familiarized with formal notations, the process details all the detected abnormalities in natural language to help him rapidly understanding the situation.
CREATE USER ALICE IDENTIFIED BY ALICE DEFAULT TABLESPACE SYSTEM TEMPORARY TABLESPACE TEMP; CREATE USER CHARLIE IDENTIFIED BY CHR …; CREATE USER DAVID IDENTIFIED BY DAVID …; CREATE USER MARTIN IDENTIFIED BY MRTN …; CREATE USER PAUL IDENTIFIED BY PAUL …; CREATE USER MARIE IDENTIFIED BY MARIE …; CREATE ROLE NURSE; CREATE ROLE DOCTOR; CREATE ROLE MEDICALSTAFF; CREATE ROLE SECRETARY; CREATE ROLE MEDICALSTUDENT; GRANT MEDICALSTAFF TO DOCTOR; GRANT MEDICALSTAFF TO NURSE; GRANT MEDICALSTAFF TO SECRETARY; GRANT NURSE TO ALICE; GRANT DOCTOR TO CHARLIE; GRANT DOCTOR TO DAVID; GRANT MEDICALSTUDENT TO MARTIN; GRANT SECRETARY TO PAUL; GRANT SECRETARY TO MARIE; GRANT SELECT ON MEDICALRECORD TO MEDICALSTAFF; GRANT EXECUTE ON MEDICALRECORD_VALIDATE TO DOCTOR; GRANT INSERT ON PATIENT TO SECRETARY; GRANT INSERT ON MEDICALRECORD TO SECRETARY; GRANT UPDATE ON MEDICALRECORD TO DOCTOR; GRANT UPDATE ON MEDICALRECORD TO MEDICALSTUDENT; GRANT SELECT ON MEDICALRECORD TO PAUL;
© N&N Global Technology 2015 DOI : 02.IJIS.2015.1.2
Anomalies of inconsistency: 1. 2. 3. 4.
5.
8
U’ – U = {Martin, Marie}. Existence of new users not initially defined. R’ – R = {MedicalStudent}. A new role not initially specified is detected. Arr’ – Arr = {(Secretary|-> MedicalStaff)}. A new hierarchy between the roles Secretary and Medicalstaff is introduced. Aur’ – Aur = {(Martin|->{MedicalStudent}), (Paul|-> {Nurse}), (Marie|-> {Secretary})}. Two new relat ions of users-roles assignment have been injected to the policy. The role MedicalStudent is assigned to Martin and the role Nurse is assigned to Paul. Apr’– Apr = {(MedicalStudent |-> (MedicalRecord |-> {modify}))}. A new relation
Full Paper NNGT Int. J. on Information Security, Vol. 2, Feb 2015
that assigns the right to modify a medical record to the role MedicalStudent has been injected.
other cases are inconsistencies regarding the invalid ity of SoD constraints. To answer the question: “Fro m a safe state of protection, can be said at any time that there is no intrusion that threatens an access control system?” Author in [2] proposes modeling the access control system as graph of ro les. Authors in [14] defined a process for role management, optimization and maintenance in order to reduce erroneous role definit ions and re-model roles according to organizational requirements.
Anomalies of partially implemented access control policy: 1. 2. 3. 4. 5.
U – U’ = {Bob}. A user in itially specified is absent in the imp lementation. R – R’ = . Arr– Arr’ =. Aur – Aur’ = {(Bob|-> {Nurse}}. The assignment of the role Nurse to Bob is not defined. Apr– A pr’ =.
8. Discussion and System Extensions 8.1 Discussion
Anomalies of redundancy:
Most of related works treat the notion of validating access control policies only during the specification to check its exactitude before proceeding to the implementation (pre-implementation verification) or after the imp lementation to verify its correctness regarding the defined constraints (post-implementation verificat ion). The aspect of checking the correspondence between the security planning and its real imp lementation, especially in terms of access control, according to our knowledge is not treated enough and needs more attention. To fill this gap, our proposal is to provide a global system allo wing the pre-implementation and post-implementation verifications, the optimizat ion and helping security architects validating the conformity and establishing the equivalence between the specification and the implementation of access control policies.
The user Paul have been granted the right to read medical records twice trough a direct assignment and via assignment of the role MedicalStaff to Secretary.
7. Related Works Many related wo rks dealt with the problem o f validating high level access control policies during the specification phase (we called it pre-implementation validation). Authors in [7] used to validate SecureUM L models with the SecureM OVA tool that provides an evaluation of the security model v ia OCL requests. In [3], authors proposed to translate the specification realized with secureUML to the Z language in order to analyze it with the Jaza tool that allows animat ing the specification. Authors in [21] propose to transform the specification to the B notation using B4Msecure tool and to validate it via the ProB tool. In [15], authors organize ro les in a graph. This can benefit fro m well-established results in graph transformations systems [10] and fro m issues addressed in [16], [17]. However, a less number of studies treated the problem of validating a h igh level policy with its lo w level implementation (we called it post-implementation validation). So me researches fit into this theme and propose representing roles in formalis ms allo wing the analysis, validation or optimizat ion of the policy. Contributions deal with the following themes. (1) Verification of the validity of the imp lemented policy according to its specified constraints [9]. Authors adopt a fin ite model checking to verify that an RBA C implementation conforms to its security constraints. (2) Detection of redundancy and inconsistency anomalies in the exp ression of a policy [5]. By adopting the roles graph, authors identify redundancy by the coexistence of direct and indirect priv ilege assignments. They distinguish different types of inconsistency. The existence of cycles in the graph is treated as a special case of inconsistency. All
© N&N Global Technology 2015 DOI : 02.IJIS.2015.1.2
8.2 System Extensions Our goal in this paper is to introduce a system for validating and verifying the conformity of low level access control policies managed by RDBMSs . In its actual form, as presented in this paper, the proposed system deals with checking the comp liance of concrete RBAC-based policies within RDBMSs, particularly the Oracle DBMS, in a formal environ ment based on the B notation. However, several extensions are necessary to cover the theme of monitoring the comp liance of access control policies in secure information systems in its general aspects. The following extensions represent a summary of contributions that direct our future works. 8.2.1 Reverse Eng ineering Access Control Policies a)
Introduction to the State of the Art
Several works treated the topic of retro-conception or reverse engineering in databases context. This leads to the development of professional tools allowing reverse engineering procedures. Existing tools offer the ability to generate the functional model of an imp lemented database,
9
Full Paper NNGT Int. J. on Information Security, Vol. 2, Feb 2015
while they do not allow the generation of the whole security model. In other words, they do not provide the opportunity to extract all the co mponents of pers istent RBAC-based policies. The reverse engineering procedure is based on the explo itation of the DBMS dictionary.
access request and deciding to authorize access or not based on risk thresholds. b) Contributions Since no work has been defined to assess the risk associated to the evolution of the co mponents of an RBAC-based access control policy, we need to define an approach for evaluating the risk of the evolution of concrete instances of access control policies. A main contribution is to define an approach that computes the risk associated to each detected anomaly of non conformity and automatically react v is -a-vis risky anomalies by deactivating them.
b) Contributions Our proposal for verify ing and validating access control policies relies on a reverse engineering step for externalizing the implemented policies fro m DBMSs (Phase 3). Actually, we defined the necessary reverse engineering techniques for ext racting concrete policies fro m the Oracle DBM S. The defined techniques can be generalized, but we need to define specific procedures for each DBMS. Hence, a main contribution in this topic is to define specific reverse engineering techniques relative to other familiar RDBMSs.
8.2.4 V&V Processes for Object Databases a)
The specification, design, deployment and principles of Object-Oriented databases are completely different fro m traditional databases (main ly relational databases). Hence, the application of tradit ional security controls is not adequate for providing effective security measures for object databases or systems. In this context, developing trusted access control policies, verifying and validating their conformity are challenging tasks.
8.2.2 V&V Processes for Fine Grained Access Control (XBAC Models) a)
Introduction to the State of the Art
If RBA C1 , RBAC2 and RBAC3 models are enrich ments of the RBAC0 core model, all proposals for new models in the literature report extensions of the RBAC model. The extensions of the RBAC model are numerous and meet specific application needs. Hence, many proposals have been made for the RBA C family, called x-Based Access Control models, to structure rights. RBAC extensions introduce fine-grained access control policy specification to meet new security challenges.
b)
8.2.5 V&V Processes for Distributed Access Control Policies
The actual version of the proposal deals with checking the co mpliance of RBA C-based policies. A main contribution, in this topic, is to extend the proposal to focus on the RBAC extensions. So, we need to adjust and refine the V&V p rocesses to focus on fine grained access control.
a)
Introduction to the State of the Art
Information systems are normally co mposed of heterogynous components. Securing an informat ion system consists on defining and enforcing a global security policy that can be distributed on several components that participate collectively to the system security. Hence, the security architect should specify the global access control policy and define the sub-policy for each component. Thus, the access control policy is distributed between the active components (Firewalls, DBMSs, Applicat ion Servers, Operat ing systems, the enterprise directory services, etc.).
8.2.3 Risk Assessment of the Non-Co mpliance Anomalies Introduction to the State of the Art
Incorporating risk awareness in RBAC systems deals essentially with three basic concepts: trust, risk mit igation and risk quantification. The trust concept deals with evaluating the level of trust associated to each component in order to authorize only trusted access. The concept of risk mit igation deals especially with enforcing hard constraints on the policy components to mit igate the associated risk. The concept of risk quantification deals mainly with co mputing the risk values associated to each
© N&N Global Technology 2015 DOI : 02.IJIS.2015.1.2
Contributions
Due to the specificity of object databases, we need to define the necessary techniques for monitoring the compliance of imp lemented access control policies in ODBMSs. A main contribution is to extend the system proposal to support object databases.
b) Contributions
a)
Introduction to the State of the Art
b) Contributions Monitoring the compliance of a g lobal access control policy for a secure in formation system consists on
10
Full Paper NNGT Int. J. on Information Security, Vol. 2, Feb 2015
checking the conformity of the sub access control policies defined for each active co mponent separately and checking the conformity of the g lobal po licy taking into account the interactions between these components. Currently, the proposal deals with checking the conformity o f the sub access control policy within RDBMSs. A main contributions concern: (1) the check of the conformity of access control policies in other active co mponents, (2) defining g lobal V&V p rocesses that integrate all the sub policies for a g lobal check of the conformity of the global policy taking into account the interactions between all the components. 8.2.6 Towards a Standard V&V Processes Several attempts are defined in the literature in the context of verification and validation of access control policies. Different approaches are proposed in this way based on formal techniques, roles graphs, petri nets, OCL requests, model checkers, etc. An important aspect in this research field is to converge to a standard validation process which needs to be defined, to reduce difficult ies and take benefits fro m different approaches.
A. Idani, Y. Ledru, J. Richier, M. A. Labiadh, N. Qamar, F. Gervais, R. Laleau, J. Milhau, and M. Frappier, “Principles of the coupling between UML and formal notations: C5-Validation of security policies by the animation of Z specifications”, ANR-08SEGI-018, 2011.
[4]
B4Msecure tool, Available at http://b4msecure.forge.imag.fr.
© N&N Global Technology 2015 DOI : 02.IJIS.2015.1.2
[7]
D. Basin, M. Clavel, J. Doser, and M. Egea, “Automated analysis of security-design models, Information and Software Technology”, vol. 51, no. 5, pp. 815-831, 2009.
[8]
E. Bertino, G. Ghinita, and A. Kamra, “Access Control for Databases: Concepts and Systems”, Foundations and Trends® in Databases. 3, 1–2, pp. 1–148, 2010.
[9]
F. Hansen, and V. Oleshchuk, “Conformance Checking of RBAC Policy and Its Implementation”, First Information Security Practice and Experience Conference, Singapore, pp. 144–155, 2005.
[13] J. Jurjens, “UMLsec: Exending UML for Secure Systems Development”, In Proceedings of the 5th International Conference on the Unified Modeling Language, Springer, pp. 412–425, 2002. [14] L. Fuchs, M. Kunz, and G. Pernul, "Role Model Optimization For Secure Role-based Identity Management", T wenty Second European Conference on Information Systems, 2014. [15] M. Koch, L. V. Mancini, and F. Parisi-Presicce, “A Graph-Based Formalism for RBAC”, ACM Transactions on Information and System Security, vol. 5, no. 3, pp. 332-335, 2002. [16] M. Nyanchama, and S. Osborn, “The role graph model and conflict of interest”, ACM Transactions on Information and System Security (T ISSEC), vol.1, no. 2, pp. 3–33. 1999. [17] R. Baldwin, “Naming & grouping privileges to simplify security management in large databases”, In Proceedings of the 1990 IEEE Symposium on Research in Security and Privacy, pp. 116–132. Los Alamitos, California, USA. 1990. [18] R. Sandhu, E. J. Coynek, H. L. Feinsteink, and C. E. Youmank, “ Role-Based Access Control Models”, IEEE Computer, vol. 29, no. 2, pp. 38-47, February 1996. [19] R. Sandhu, “The future of Access Control: Attributes, Automation and Adaptation”, S&P symposium, IIT Kanpur, 2013. [20] T. Lodderstedt, D. Basin, and J. Doser, “SecureUML: A UMLbased Modeling Language for Model-driven Security”, In Proceedings of the 5th International Conference on The Unified Modeling Language, LNCS, Springer-Verlag, pp. 426-441, 2002.
A. Cenys, A. Normantas, and L. Radvilavicius, “Designing rolebased access control policies with UML”, Journal of Engineering Science and Technology Review, vol. 2, no. 1, pp. 48-50, 2009.
[3]
D. Basin, J. Doser, and T. Lodderstedt, “Model Driven Security: from UML Models to Access Control Infrastructure”, ACM Transactions on Software Engineering and Methodology, vol.15, no. 1, pp. 39-91, 2006.
[12] J. Jurjens, “Secure Systems Development with UML”, Springer, 2005.
References
A. Ghadi, “ Modèle hiérarchique de contrôle d'accès d'UNIX basé sur un graphe de rôles” (in French), PhD, 2010.
[6]
[11] I. Ray, N. Li, R. France, and D. K. Kim, “Using UML to Visualize Role-Based Access Control Constraints”, In the ninth ACM symposium on access control models and technologies, pp. 115124, USA, 2004.
This paper explores the notion of enhancing the integrity of access control policies in RDBM Ss. It p robes the concept of formally validating and verifying the conformity of concrete RBAC-based policies. This has emerged as an important aspect that helps security architects checking the co mp liance between the security planning and its real imp lementation. Our contribution aims at defin ing an analysis tool for low level policy trustworthiness. This tool intends to break with the requirement to manually configure access rights by delegating more tasks to smart routines and software. Hence, our contribution joins the approach defined in [19] which emphasizes that access control must adjust as circu mstances changes and claims for the adaptability as a main feature of access control policies for secure systems in the future.
[2]
C. Huang, J. Sun, X. Wang, and Y. Si, “Security policy management for systems Employing Role Based Access Control Model”, Information Technology, Journal, vol. 8, no. 5, pp. 726734, 2009.
[10] G. Rozenberg , “Handbook of Graph Grammars and Computing by Graph Transformations”, Foundations, World Scientific, ED, 1997.
9. Conclusion
[1]
[5]
[21] Y. Ledru, A. Idani, J. Milhau, N. Qamar, R. Laleau, J. Richier, , and M. A. Labiadh, “Taking into Account Functional Models in the Validation of IS Security Policies”, Advanced Information Systems Engineering (CAiSE) Workshops, vol. 83, pp. 592-606, 2011. [22] F. Jaidi, and F. Labbene Ayachi, “An Approach to Formally Validate and Verify the Compliance of Low Level Access Control Policies” The 13th International Symposium on Pervasive Systems, Algorithms, and Networks (I-SPAN 2014), 2014. [23] F. Jaidi, and F. Labbene Ayachi, “The Problem of Integrity in RBAC-Based Policies within Relational Databases: Synthesis and Problem Study” The 9th International Conference on Ubiquitous
11
Full Paper NNGT Int. J. on Information Security, Vol. 2, Feb 2015
Information Management and Communication ACM IMCOM (ICUIMC) 2015.
[24] F. Jaidi, and F. Labbene Ayachi, “A Formal System for Detecting
Anomalies of Non-Conformity in Concrete RBAC-Based Policies” International Conference on Computer Information Systems 2015 WCCAIS-2015- ICCIS, 2015.
[25] W. Lampson, “Protection”, ACM SIGOPS Operating Systems Review, vol.8, no.1, pp. 18–24, ACM Press, 1974. [26] D. Bell, L. LaP adula, “Secure Computer Systems: Unified Exposition and Multics Interpretation”, MT R-2997, Mitre, Bedford, MA, 1975.
[27] D. E. Denning, “A lattice model of secure information flow”,
Communications of the ACM, vol.19, no. 5, pp. 236–243, USA, 1976.
Faouzi JAIDI received the engineering degree in computer science from EABA in 2005. He received his M aster’s degree in computer science from the Faculty of Science, M athematics, Physics and Natural of Tunis in 2010. His professional experience from 2005 till now concerns mainly networks security, networks administration, the security of information systems, etc. Actually he is a member of the Digital Security Research Unit (DSRU) and a Phd. Student in the Higher School of Communication of Tunis (Sup'Com), Tunis, Tunisia.
Faten LABBENE AYACHI
received in 1987 the Diploma degree in computer management with Distinction from the Higher Institute of M anagement of Tunis (Tunisia). In 1988, she received a M aster’s degree and in 1992 a PhD degree with Distinction from UNSA, University of Nice Sophia Antipolis (France). Faten Labbene A YACHI is currently an associate Professor at the Sup’Com Engineering School of Telecommunications in Tunisia and head of the department IT and Network. Actually she is a member of the Digital Security Research Unit (DSRU) in the Higher School of Communication of Tunis (Sup'Com), Tunis, Tunisia and member of the Tunisian Society for Digital Security . Faten Labbene Ayachi main research areas are Information System Security and databases.
© N&N Global Technology 2015 DOI : 02.IJIS.2015.1.2
12
