Вы находитесь на странице: 1из 14

Abstract:

Because of the limitations of condition configuration and execution mechanism, the exiting access control models are not flexible and cannot support multi-policy. Policy-based access control model (PBAC) is different from the traditional models which restrict session only with subject authorization, PBAC realizes policy based access control by defining attribute to describe session property, performing a new policy management method that is free from application logic, and advocating an independent access control decision mechanism. As a consequence, PBAC is more flexible on restricting session, and makes great progress on multi-policy supporting. The comparison analysis indicates that PBAC is superior to the current access control models.

Access Control Model Considered for DoD is Policy Based Access Control Model. The criterion of selecting this model is mentioned below:

Motivation:
By configuring access restriction of subject, access control technology realizes the sharing of information and resource, and enhances security of system. So it gets more and more attention. Focusing on different requests of security, researchers design many access control models, such as Discretionary Access Control (DAC), Mandatory Access Control (MAC)[2], Role-based Access Control (RBAC), and Extended Role-based Access Control (ERBAC). Among these models, RBAC is the most popular. Though they have made great progress on access control, there are still some shortages. Firstly, the restraint of session is not comprehensive. Most of current models control session by configuring restriction only on subject. They do not consider other elements of session such as object and circumstance. Secondly, current models are not very flexible. The control mechanism of current models is hard-coded on application logic and difficult to adjust at runtime. At the same time, because the types of session restriction, such as the role of RBAC, have been fixed when designing application, they are difficult to be modified. Finally, the most important shortage results from the management method of policy. Since in most current models policy is described indirectly by configuring subjects role and privilege, this representation method is limited. The models have not the ability of multi-policy supporting which means model can make a decision on one session based on more than one policy. To resolve these problems, this paper presents a policy based access control model (PBAC). Different from RBAC controlling session with configuring role privilege (as Fig.1a), PBAC defines attribute to describe property of session, and issues a method of policy management independent from application logic, then realizes a new independent mode of session decision (as Fig. 1b). Therefore, PBAC is more flexible and multi-policy supporting.

Overview of PBAC

Most organizations have some kind of policy and governance structure in place to ensure the successful execution of the organizations mission, to mitigate risk, and to ensure accountability and compliance with relevant law and regulations. Many organizations are discovering that they need to put into place tighter policies and uniform controls across the enterprise in order to stay in compliance. They need to create and enforce policies that define who should have access to what resources, and under what circumstances. They also need to put in place mechanisms so that access can be easily audited. Policy-based Access Control (PBAC) is an emerging model that seeks to help enterprises address the need to implement concrete access controls based on abstract policy and governance requirements. In general, PBAC can be said to be a harmonization and standardization of the ABAC model (Attribute Based Access Control) at an enterprise level in support of specific governance objectives. PBAC combines attributes from the resource, the environment, and the requester with information on the particular set of circumstances under which the access request is made, and uses rule sets that specify whether the access is allowed under organizational policy for those attributes under those circumstances. In an ABAC-only model, the attributes required to gain access to a particular resource are determined on a local level and can vary greatly from one organizational unit to the next. For example, one organizational unit might determine that access to a sensitive document repository requires credentials with a username, organizational role and password; another unit might require that the credentials necessary to access its repository also include a digital certificate issued by a trusted Certificate Authority. If documents are transferred from the latter repository to the former one, they lose the protection afforded by the digital certificates, and thus can be more easily compromised. Under the PBAC model, the organization would likely have one policy governing access to all resources that meet particular sensitivity criteria, and this policy would be enforced across the board for all attempts to access the resource, no matter where the documents are housed at any given point. Although PBAC is an evolution of ABAC, it is a much more complicated model. Since the attributes have to be maintained across the enterprise, it is necessary to design and deploy enterprise-level systems to accommodate PBAC. This includes databases, directory services, and other middleware and management applications, all of which must be seamlessly integrated. In contrast to the other access control models, PBAC requires not only complicated application-level logic to determine access based on attributes, but also a mechanism to specify policy rules in unambiguous terms. It is extremely important that policies be unambiguous; otherwise, there is the potential for unintended, unauthorized access to a resource with which a particular policy is associated.

The Definition of PBACs Basic Elements PBAC has some elements as follows: i) ii) iii) SUBJECT: set of models subjects. TARGET: set of models objects. ACTION: set of models actions.

The definitions of SUBJECT, TARGET and ACTION are the same as RBACs. SESSION: Set of Models sessions, which means a subject takes an action on a target. Session has three Elements as Subject, Target and Action, SESSION SUBJECT TARGETACTION. ATTRIBUTE: Set of Models attributes, which describes property of models session, the concrete definition is represented in Part B. ENTITY: Set of entities. The entity refers to subject, target or action. POLICY : Set of policies. Policy is the core of PBAC. It is used to restrict session request. The concrete definition is represented in Part C of Section . Different from the existing models, PBAC represents policy with a direct description method instead of configuring role of subject indirectly.

The Description of PBACs Attribute PBAC describes attribute with variable. Each variable means one type of attribute.
Attribute (s_attribute, t_attribute, se_attribute): access control attribute, which includes of subject attribute (s_attribute), target attribute (t_attribute) and session circumstance attribute (se_attribute). All of the elements have a uniform description: (object_own, attr_var), object_own is the owner of the attribute, it can be a subject, target or session circumstance. attr_var is set of attribute variables, the formal description is {variablei| 0iniN, n is the number of attr_vars variable}. Most attribute variables are described by XML independent from application logic (the concrete management method is in Part D of Section). Because XML is able to be modified easily, the session property can be represented in fine-grained. Nevertheless, some other attribute variables can also be defined in application logic according to the requirement of environment, such as circumstance attribute. Different from the existing models as RBAC only restricts subject, PBAC manages attribute of all sessions elements, such as subject, target and circumstance. And the attribute variable of PBAC does not represent privilege. For example, an attribute variable role in PBAC only represents subjects

property (its privilege is restricted in policy). Comparatively, the role in RBAC refers to the privilege of subject. The relationship of entity and attribute is denoted as: SA: attribute assigned to subject, SA SUBJECT ATTRIBUTE. TA: attribute assigned to target, TA TARGET ATTRIBUTE. SEA: attribute assigned to session circumstance, SEA SESSIONATTRIBUTE. The Description of PBACs Policy According to the definition of IETF/DMTF, policy includes a series of condition and action, which is if condition then action. Based on this, PBAC makes a formal description of policy as follows. Policy (subject, target, action condition, flag): access control policy, which includes subject, target, action, condition and flag. Among the 5-tuple, the definitions of subject, target and action are the same as sessions, the other two is as follows. Condition (s_condition, t_condition, c_condition): policys restraint condition about session, which includes subject restriction condition (s_condition), target restriction condition (t_condition) and session circumstance restriction condition (c_condition). The formal description of three restriction conditions is consistent with attribute: (object_own, cond_var): object_own is the owner of the restriction condition, such as subject, target or session circumstance. cond_var is set of attribute variables, the formal description is: {variablei| 0in iN, n is the number of variable in cond_var}. Flag: type of policy, the value can be true or false. true means the policy allows subject to execute the action on target in the condition, and false is the opposite. The relationship of policy, session and attribute is denoted as: SAP: policy is assigned to the combination of session and attribute. SAPSESSION ATTRIBUTEPOLICY PBAC uses XML as a policy language based on the formal description as above. Since XML is extensible and allows its users to define their own element, it can be used to describe policy in fine-grained.

The Decision of PBAC In order to ensure the consistent and effectiveness of policy, PBAC sets several decision rules of access control. Rule 1: If none of policies regulates the request related to the session, which means the system does not restrict the session, the session request will be denied. Rule 2: If there is not less than one policy that prohibits the session request, the request will be denied. Rule 3: When all policies about the session allow it to be carried out, it will be performed. PBAC Architecture The access control architecture presented by XACML standard from OASIS specifies four main actors to handle access decisions: (1)Policy Enforcement Point (PEP), (2)Policy Decision Point (PDP), (3)Policy Information Point (PIP), (4)Policy Administration Point (PAP), and (5)Context handler [1]. The XACML architecture actors and the steps of the communication between them are illustrated in Fig.1 and presented as follow: Policy Enforcement Point (PEP) is responsible for enforcing policy decisions. It processes an event and sends a formatted request to the PDP. The PDP responds with a decision and the associated actions which the PEP will carry out. The PEP then acts upon the returned result by allowing the request to proceed or by denying the action in case of respectively a positive or a negative authorization decision. Policy Decision Point (PDP) is a policy evaluation engine. The PDP receives authorization requests from PEP and evaluates these requests against authorization policies retrieved from the PAP.

Policy Information Point (PIP) is the point where the necessary attributes for the policy evaluation are retrieved from several external or internal actors. The attributes can be retrieved from the resource to be accessed, environment (e.g., time), subjects, and so forth. Policy Administration Point (PAP) holds all the policies used by PDP. Context handler mediates between the different components of the XACML access control architecture. XACML standard does not present any details about PAP Scenario:

End-user requests access to an application / service. Request is routed through a Policy Enforcement Point. Policy Enforcement Point transfers the request details to a Policy Decision Point for evaluation and authorization decision. The Policy Decision Point refers to a Policy Store and possibly a Policy Information Point. Policy is administered through a central Policy Administration Point. The Policy Enforcement Point enforces the decisions of the Policy Decision Point.

PEP

USER REQUEST

RESOURCES

PDP

PIP

Resource

Environment PAP Subject

PBAC Framework for Dept of Defense Organaisation

User Request

IPSEC

Policy Enforcement Point (PEP)


DRDO Unit 1 De- Militize Zone

Protected CLOUD SERVICES

DRDO Firewall cum Server

Global Authentication / Authorize Server

Policy Decision Point (PDP)

Policy Information Point (PIP)

LDAP / Active Directory

Policy Manager

Policy Administration Point (PIP)

XACML Subject

Resource

Access Control Policy Tool (ACPT)

Environment

For Implementation of Cloud Server in Dept. of Defense Environment following are considered: a) b) c) d) e) Cloud Type Cloud Services Network Security Ip Address : Private Cloud ( only DoD purpose) : PaaS, SaaS & IaaS : Dedicated to DoD : Ip Sec : Manual allocated

Cloud Access Methods are categorized in to the following: a) Model 1. b) Model 2. c) Model 3. Centralized Cloud Server at HQ Cloud Server based on Region Cloud Server based on Project Group

For Any Access Control Mechanism, there are two things are required before accessing the resource. i.e a) Authentication

b) Authorise Authentication Authentication of USER through LDAP (Lightweight Directory Access Protocol) and it is based on X.500 standard. To access the LDAP service, the LDAP client first must authenticate itself to the service. That is, it must tell the LDAP server who is going to be accessing the data so that the server can decide what the client is allowed to see and do. If the client authenticates successfully to the LDAP server, then when the server subsequently receives a request from the client, it will check whether the client is allowed to perform the request. This process is called access control. The Schematics are shown below:

LDAP Client

TCP/IP

LDAP Server

Client performing protocol operations against servers: Client sends protocol request to server Server performs operation on directory Server returns response (results/error)

Active Directory

To get the user authentication, following details / attributes are required: o o o i) User Registration Computer / System Registration Security Checks / Updates User must register his / her details in Active Directory for proper authentication: Example : User : Pradeepraja, Designation : Scientist D (Aero) Organization : Centre for Airborne System (CABS) Division : Div-5 (IT & Networking) Post : Officer-in-charge ( Networking) DRDO ID No : A- xxxxxxx User Name Password : : SC - 1200 abcd@#$ 123 (Periodically changed)

ii)

Computer / System need to be registered to avoid the unauthorized access of intruder / guest machine. Computer Host Name : Div-5 - 211 MAC Address Allotted IP Address Domain Name : BCA3321423 : 192.168.2.100 : cabs.org

iii)

Security Checks need to be undertaken for Operating System critical patch updates and the latest Antivirus Definition patch updates. If not updates, it redirects the user to the web server where all the updates are available and does the updates automatically. Critical Security Patch Updates (OS) Antivirus Definition Patch Updates : Yes : Yes

All the above details are considered as a Attributes and the Attribute values. With these details policies can be developed and forced either as a GROUP / INDIVIDIAL user and can be access / modify through LDAP.

Authorization :

Authorization is to give permission to give user to access to the information / object. Consider the following sentence: "A user wants to do something with an information asset in a given context". A sentence like this includes four grammatical building blocks, a subject, an action, a resource and the environment in which the request is made. Each of these can be described using attributes:

Access Control Policy Tool (ACPT) - Overview This Software was developed by the National Institute of Standards of Technology (NISIT) in corporation of Computer Science Department of North Carolina State University. The Access Control Policy Tool (ACPT) is a took kit written in JAVA. ACPT allows one to simulate different policies in a particular environment. A simulation environment is built up of three inputs : Subjects,

Resources and Actions. After one establishes their environement, he or she can apply one of three models: Attribute Based Access Control Mode (ABAC), Multilevel Security Model (MLS) and WorkFlow Policy Model. The user can set up different properties and use the NuSMV verification tool to see how a specific rule complies. This software will also run your policy(s) through a series of tests powered by Advanced Combinatorial Testing System. Once the policy is complete it can be exported to an eXtensible Access Control Markup Language (XACML) file.

Rules and Concepts 2.1 Subject, Resource, Action, and Environment Attributes
The ACPT uses attributes to help create a policy. The attributes including the subject/users, resources, actions, and environments. Then the ACPT user will define a model and tested on pre-define attribute set. All attributes have a name, type and attribute value(s). One can have as many attributes as desired. The ACPT only supports up to one level of classification for its attributes. An attribute is the root and it can only have one level of children for its attribute values. For DoD Environment Roles is the subject name of type string with attribute values: Director, Scientist, Admin Assistant, and Finance Staff.

Attribute: Roles

Attribute Value: Scientist

Subject Attribute & Value The subject who is demanding access to an information asset. General attributes describing the subject, for instance roles, group memberships, the department / company to which the user belongs, management level, certifications or competencies, user ID, etc.,

Sl. No

SUBJECT ATTRIBUTES ATTRIBUTE TYPE

ATTRIBUTE VALUES

01

Role

String

Director Scientist (Aero) Scientist (Navel) Scientist (Army) Admin Staff Finance Staff

Resource Attribute & Value The resource identifying the information asset or object impacted by the action. Resource attributes render the characteristics that identify the information asset. In the online banking example directly above, the resource most likely is your "debit account=<your account number>", in a document management system, attributes typically correspond to the metadata or tags entered when the document is checked-in, in eHealth applications the resource is probably a part of the health record identified by the patient ID etc. RESOURCE ATTRIBUTE TYPE String

Sl. No 01

ATTRIBUT ES Apps

ATTRIBUTE VALUES Project_Apps_Aero Project_Apps_Navel Project_Apps_Army Admin_Apps Finance_Apps

Environment Attribute & Value The environment identifying the context in which access is requested. Common environment attributes are related to the current time and location from where access is requested, to the type of communication channel, such as protocol or encryption strength, or client type (PC, smart phone, etc.). Authentication strength may also be relevant to authorization.

Sl. No 01 02

ATTRIBUT ES Timing Division

ENVIRONMENT ATTRIBUTE ATTRIBUTE VALUES TYPE String Office_Hours Non_Office_Hours String Aero_Division Naval_Division

Army_Division Admin_Division Finance_Division

Action Attribute & Value The action that the user wants to perform. Common action attributes in authorization requests are "read" and/or "write". In more complex scenarios, the action may be described by a combination of attributes.

Sl. No 01

ACTION ATTRIBUTES ATTRIBUTE TYPE Actions String

ATTRIBUTE VALUES Read Write Read with Note

Policy Generation During Policy Generation, it is to be developed in XACML and it is three stages Rule Rule Set Policy For developing Rule, we need to use any one of the following algorithms

Algorithms

The ACPT uses three different algorithms to help the ACPT user specify the way to handle duplicate rules in the same model or if multiple models are merged together. First Applicable First applicable takes the permission decision of the first occurrence of a particular variable if the same variable was in the policy twice with a different Permission. For example if two policies were merged, it would take the permission decision of the first one. Deny Override Deny Override scans through the entire model to find all the duplicate variables. Once a deny permission of duplicate variable is found it will deny the access to that particular rule in the model.

Permit Override Permit Override scans through the entire model to find all the duplicate variables. Once a grant permission of duplicate variable is found it will permit the access to that particular rule in the model.

Rule Sets Model implementation For the individual unit of DoD , Attribute based Access Control Model (ABAC) is suitable for setting the rule. For the enterprise policy governance and implementation Multi level Security Model is chosen for PBAC implementation. ABAC Model The ABAC model template allows ACPT users to define access control rules based on their environment variables (Subject, Resource, and Action). Unlike MLS and Workflow, ABAC template consists of rules without any embedded access control model. MultiLevel Security Model The MultiLevel Security Model (MLS) enforce Bell-LaPadula and Biba models, which protect resources from being accessed from unauthorized ranking members. This particular model uses rule properties: No read up, No write down. These properties ensure no subject cannot read a resource above their access level or write to a resource lower than their current rank. No Read Up

This property handles, which subjects can have access to read the resource. Any subject can read their current ranked resource and any resource below their current rank. It is forbidden to read any resource above its rank. No Write Down This property protects information from being changed from unauthorized subjects. A subject can write to a resource as long as they are the same rank level or above their current rank. However, a higher ranked subject cannot write to a lower ranked resource. Higher ranked subjects have access to more classified information so if they are not allowed to write down this will help prevent information leaking to unauthorized subjects.

No Read Up a)

No Write Down

Access Rules for Director---- {Director has a full access to all Apps at any time} Algorithm Used : First Applicable (Permission given based on the first Occurrence of a particular variable if the same variable was in the policy twice with a different permission)
SUBJECT ENVIRONMENT ACTION RESOURCE AUTHORISE

Timing
Role Director

Any Timing & Division Any Division

Action Write

Apps All Appa

Authorise Permit

Вам также может понравиться