Project topics and materials
Get Complete Project Material File(s) Now! »
Security related SLA
Although traditional SLA focuses on the issues of QoS and performance, SLA-based trust and security management have been investigated in recent liter-ature. The concept of security service level agreement is first proposed by Henning [52] as a mechanism to specify the security services required for an effective enterprise. SLA is used to explicitly state the obligation of the providers in terms of implemented security mechanisms, their effectiveness and the implication of possible mismanagement [53]. There have been some initiatives in the field of Cloud Computing that consider security aspects in SLAs. In [5], the authors present a framework (Figure 2.11) for security is-sues of SLAs in Cloud Computing. The objective of the framework is to help potential Cloud service customer (CSC) to identify the necessary protection mechanisms and facilitate automatic service composition based on a set of predefined security requirements. Chen-Yu et al. describe an ontology [54] for representing security SLAs (SSLA). Based on 13 classes, the proposed ontology can be used to understand the security agreements of a provider, to negotiate the desired security levels, and to audit the compliance of a provider with respect to federal regulations such as HIPAA standards [55].
The Cloud Security Alliance (CSA) [56] is a non profit organization that aims at promoting the use of best practice to increase the security level of Cloud infrastructures. CSA has designed a self-assessment questionnaire framework to define the security information contained in a Security Level Agreement (SecLA): the Consensus Assessments Initiative Questionnaire (CA IQ) [57] which is destined to Cloud service provider (CSP) to document the implemented security measures. Containing more than 200 security relevant questions, CAIQ helps a CSC to understand security coverage and guaran-tees of Cloud offers. In 2014, the European Commission published stan-dardization guidelines for Cloud Computing SLA [58]. In order to improve the clarity and increase the understanding of SLAs for Cloud services in the market, the guidelines provide general recommendations to CSP and CSC about what they could agree on using SLAs. In terms of security SLA, it cov-ers 8 aspects such as authentication, authorization, cryptography and vul-nerability management. Recently, a key Cloud SLA standardization activity is being carried out by ISO/IEC on “19086 – Information Technology (Cloud Computing) SLA Framework and Terminology”. This prospective standard will address (i) the definition of a standardized framework for Cloud SLAs in-cluding both a vocabulary and comprehensive catalogue of commonly used Service Level Objectives (SLOs); (ii) the definition of Cloud SLA-related met-rics; (iii) core requirements for implementation; (iv) security and privacy in Cloud SLAs [59].
Policy Similarity Measure (PSM)
Today the use of similarity measure for comparing security policies becomes a crucial technique in a variety of scenarios, such as finding the SP(s) which satisfies SC’s security concerns. Before a collaboration is conducted be-tween different actors, an actor A may need to know if the other actor guar-antees a similar level of A’s security policies. In case that SPs expose their security policies for a SC to evaluate and select, policy comparison is one of the main mechanisms to that end. It consists in measuring the similarity between two security policies and giving an evaluation score. The first thing to measure the similarity between security policies is to give the mathematical definition of PSM. In [60], Lin et al. propose Equa-tion (2.1) for PSM. In the equation, p1 and p2 are two security policies for measure; Sreq denotes the quantity of the access requests with the same de-cisions from p1 and p2; Req is the quantity of the access requests applicable to either p1 or p2:
Spolicy(p1, p2) = |Sreq|/|Req| (2.1) In an example that we will use in Chapter 3, we consider three XACML policies P1, P2 and P3 illustrated in [60]. These policies are defined for man-aging an information system of a research laboratory.
A Generic Policy Similarity Measure Method
The PSM assigns a similarity score Spolicy for any two given policies, which approximates the percentage of the rule pairs having the same decision. The formal definition is given in Equation (3.1), where N um(sameDecision(r1i, r2j )) denotes the number of the rule pairs having the same decision for the same access requests and N um(allDecision(r1i, r2j )) denotes the amount of the to-tal decision pairs for access requests which are applicable to either policy p1 or policy p2. Spolicy(p1, p2) ≈ N um(sameDecision(r1i, r2j )) , r1i ∈ p1, r2j ∈ p2 (3.1).
The similarity score is a value between 0 and 1. Two equivalent policies are expected to obtain a similarity score equal to 1. We mention that the defi-nition of the policy similarity score in [60] focuses on the percentage of the access requests obtaining the same decisions. Comparing with the former work, our definition of PSM is more fine-grained because the same decision from two policies can be derived from one or multiple rule pairs. Conse-quently, by considering decisions of rule pairs but not final policy decisions, our PSM is more accurate from both calculation and test aspects. More de-tails are shown in Section 3.3.
Policy Structure
As a generic algorithm, our PSM can be applied on different policy models. This requires a transformation process before calculation. Policies are firstly split into different rules and each rule is expressed in the form of: decision_effect(attr_name1 : attr_value1, …, attr_namen : attr_valuen) (3.2) where decision_effect is a decision effect such as permit and deny; attr_name denotes the name of an attribute and attr_value represents an attribute value. We define (attr_namei : attr_valuei) as a rule element and it can be divided into the following two types:
• Categorical element: Attribute value belongs to the string data type
or is a set of string. For example “Role : admin” and “Action : [read, write, create]” are categorical atomic elements.
• Numerical element: Attribute value can be integer, real, date/time data types. The value can be single one or a set or an interval. For example, elements “T ime : {3pm, 4pm, 5pm}”, “F ileSize : (5, +∞) GB », T ime : [8 : 00, 18 : 00] are numerical atomic elements.
Similarity Score of Rule Elements
The score of a rule element pair can be calculated when two elements belong to the same decision effect and share the same attribute name. In Equa-tion (3.3), the score of a rule pair is based on the rule elements having the same attribute name. When an element’s attribute name does not appear in another rule, the access decisions from the two rules are not affected. For this reason, we consider that the score of such element pair is 1. Rule el-ements can be divided into two types: categorical elements and numerical elements.
Similarity Score for Categorical Elements.
For categorical elements, we measure the exact match of two values. A higher score indicates that the two elements share more common attribute values. Equation for similarity score computing between two categorical elements e1 and e2 is defined as follows: Sc(e1, e2) = num(v1 ∩ v2) (3.6) num(v1 ∪ v2 ∪ v3… ∪ vn).
Sc(e1, e2) presents the exact percentage of the same decision for one element pair extracted from the two rules. num(v1 ∩ v2) denotes the quantity of com-mon attribute values between element e1 and e2; num(v1 ∪ v2 ∪ v3… ∪ vn) is the quantity of attribute values among all the elements in two policies and these elements should 1) have the same attribute name 2) belong to the rules of the same decision effect.
Some policy models use abstract elements to represent a set of concrete values. For example, in RBAC, the Role element is an abstraction of Subjects; in OrBAC, a Role is a set of Subjects, an Activity is a set of Actions and a V iew is a set of Objects. In this case, the abstract values should be transformed to their related concrete values. For example, abstraction trees for Role and Resource elements of p1, p2, p3 are shown in Figure 3.2 and Figure 3.3.
Table of contents :
Contents
List of Figures
Nomenclature
1 Introduction
1.1 Motivation and Challenges
1.2 Contributions
1.3 Organization
I Service Provider Selection
2 State of the Art
2.1 Introduction
2.2 Access Control Model
2.2.1 Discretionary Access Control (DAC)
2.2.2 Lattice-based Access Control (LBAC or MAC)
2.2.3 Role-based Access Control (RBAC)
2.2.4 Attribute-based Access Control (ABAC)
2.2.5 Organization-Based Access Control (OrBAC)
2.3 Service Level Agreement (SLA)
2.3.1 WSLA
2.3.2 WS-Agreement
2.3.3 RBSLA
2.3.4 SLAng
2.3.5 Security related SLA
2.4 Policy Similarity Measure (PSM)
2.4.1 Problematic
2.4.2 Use Cases
2.4.3 Existing Approaches
2.5 Virtual Resource Allocation
2.5.1 Problematic
2.5.2 Existing Approaches
2.6 Conclusion
3 Similarity Measure for Security Policies
3.1 Introduction
3.2 A Generic Policy Similarity Measure Method
3.2.1 Policy Structure
3.2.2 Example of Policy Transformation
3.2.3 Overview of PSM Algorithm
3.2.4 Similarity Score of Rule Elements
3.2.4.1 Similarity Score for Categorical Elements
3.2.4.2 Similarity Score for Numerical Elements
3.2.5 Example of Calculation
3.3 Experiment Results
3.4 Implementation
3.4.1 Scenario Description
3.4.2 Architecture
3.4.3 Performance
3.5 Conclusion
4 Expression and Enforcement of Security Policy
4.1 Introduction
4.2 Overview of the User-centric Policy-based Framework
4.3 Expression of Security Policy
4.3.1 SLA Contract Expression
4.3.2 Derivation of Security Policy
4.4 Enforcement of Security Policy
4.4.1 QoS Filtering
4.4.2 Conflict Management
4.4.3 Execution of Virtual Resource Allocation
4.5 Implementation and Evaluation
4.5.1 Experiment 1: contract processing
4.5.2 Experiment 2: policy generation
4.5.3 Experiment 3: allocation latency
4.5.4 Experiment 4: price
4.6 Conclusion
II Negotiation between Service Customer and Service Provider
5 State of the Art
5.1 Introduction
5.2 Trust Negotiation
5.3 Access Negotiation
5.4 Access Control Policy Negotiation
5.5 Meaning Negotiation
5.6 Conclusion
6 The Process of Reaching Agreement in Security Policy Negotiation
6.1 Introduction
6.2 Relation between OrBAC Entities
6.3 Relation between OrBAC Rules
6.4 Negotiation Configuration
6.4.1 Entity Chain
6.4.2 Policy Tree
6.5 Negotiation Algorithm
6.5.1 Algorithm Description
6.5.2 Theoretical Results
6.6 Application
6.6.1 Scenario Description
6.6.2 Process of Security Policy Negotiation
6.6.3 Prototype
6.7 Conclusion
7 Conclusion and Perspectives
7.1 Main Results
7.2 Perspectives
Appendix A 119
Appendix B 123
Appendix C 125
List of Publications
References
