See

discussions, stats, and author profiles for this publication at: https://www.researchgate.net/publication/273635349

A Sticky Policy Framework for Big Data Security

CONFERENCE PAPER MARCH 2015

READS

544

3 AUTHORS:
Jerry Gao

Younghee Park

San Jose State University

San Jose State University

177 PUBLICATIONS 2,033 CITATIONS

20 PUBLICATIONS 56 CITATIONS

SEE PROFILE

SEE PROFILE

Shuyu Li
Shaanxi Normal University
1 PUBLICATION 0 CITATIONS
SEE PROFILE

All in-text references underlined in blue are linked to publications on ResearchGate,

letting you access and read them immediately.

Available from: Jerry Gao

Retrieved on: 23 March 2016

A Sticky Policy Framework for Big Data Security

Shuyu Li, Tao Zhang

Jerry Gao, Younghee Park

School of Computer Science

Shaanxi Normal University
Xian, China
lishuyu@snnu.edu.cn, zhangtao.fufeng@gmail.com

Department of Computer Engineering

San Jose State University
San Jose, USA
jerry.gao@sjsu.edu, younghee.park@sjsu.edu

Abstract Big data security is one of the hottest research

topics in big data computing and service applications, because of
the lack of research results and mature security technologies and
solutions to provide adequate big data security. Big data security
faces the need to effectively enforce security policies to protect
sensitive data. Trying to satisfy this need, a security policy
solution is presented in the paper. Firstly, an implementationindependent and fine-grained policy meta-model is proposed for
abstraction from underlying technologies and better reuse. Then,
a sticky policy framework is adopted with policy enforcement
and evaluation discussed in detail. Finally, a healthcare scenario
is used to evaluate the process of policy modeling and
enforcement.
Keywords Big Data Security; Security Policy; Sticky Policy;
Policy Enforcement

I. INTRODUCTION
The term big data has recently come into use to refer to the
ever-increasing amount of information that organizations are
storing, processing and analyzing, owing to the growing
number of information sources in use [1]. Much big data
already resides in the cloud, and this trend will increase in the
future. For example, IT research and advisory firm Gartner
estimates that by 2016 more than half of all large company data
will be stored in the cloud [2]. This trend means that the cloud
must provide a suitable infrastructure for implementing big
data analytics platforms.
Currently, big data is increasingly generated and utilized
across diverse domains in fields such as healthcare, education,
and finance, and also brings opportunities to discover new
values and understand hidden values of big data. While big
data can yield extremely useful information, it also presents
new challenges with respect to security issues. The
effectiveness and efficiency of traditional security mechanisms
are being reconsidered as big data introduces its own particular
characteristics and security requirements. Current technologies
being developed to manage massive data sets often are not
designed with adequate security measures, in part because we
lack an adequate policy mechanism to be compatible with
current approaches to security.
In general, policy refers to guidelines or regulations that
encourage user engagement and protect participants data
reports. Security policy is defined according to the National
Institute of Standards and Technology as the [a]ggregate of
directives, regulations, rules, and practices that prescribes how
an organization manages, protects, and distributes information
[3].
Sponsored by China Scholarship Council.

To adequately pave the way for robust, secure big data

applications, big data infrastructures must consider richer,
semantics-aware policy approaches that provide flexible,
distributed enforcement strategies and evidence of enforcement
to the users whose data security is at stake.
This paper has the following two main technical
contributions:
- An implementation-independent and fine-grained metamodel for security policy is proposed;
- A sticky policy framework supporting the proposed metamodel at the IaaS (Infrastructure as a Service) level is designed
and being implemented.
The rest of the paper is organized as follows. Section 2
reviews related work in security, mainly focusing on policy
models and policy languages. Section 3 discusses the
requirements of our security policy meta-model and proposes
an implementation-independent meta-model for security
policies. Section 4 proposes a framework that adopts sticky
policy for IaaS, and discusses policy enforcement and
evaluation in details. Section 5 presents its application in
healthcare to illustrate security policy enforcement. Finally, our
conclusion and future work are included in section 6.
II. RELATED WORK
The era of big data (with cloud computing as the
fundamental infrastructure) has not only ushered in a wealth of
opportunities for different domains across different fields, but
has also brought many challenges related to data security and
privacy. A lot of promising work has been done to address
these challenges, Rong [4], Ryan [5], and Chen [6] have
reviewed some of these, each from a different perspective.
A. Security Policy Model
Recently, a number of published security policy models
have been proposed to express user privileges, e.g. Role Based
Access Control (RBAC) [7] or Organization Based Access
Control (OrBAC) [8]. Karadsheh [9] discusses the role of
security policies, service level agreements, and compliance for
enhancing the security of IaaS services. Furthermore, a
conceptual model for security policies has been proposed and
several applicable policies
have been presented.
Oulmakhzoune et al. [10] has proposed a privacy-aware access
control model (known as PrivOrBAC) that allows for the
definition of fine-grained privacy policies and preferences for
each data element, using a query rewriting algorithm to
enforce privacy preferences.

B. Security Policy Framework

Several policy frameworks have been suggested in the
literature. Singhal et al. [11] proposes an ongoing framework
that uses proxies to act as mediators between applications in
multiple clouds for dynamic collaborations and resource
sharing. In this framework, policy heterogeneity and conflicts
resulting in security breaches are taken into consideration.
Takabi [12] focuses on issues related to policy management
and access control in the cloud, and proposes a semantic-based
policy management framework that enables users to specify
access control policies using semantic web technologies and
helps address heterogeneity issues in the cloud. A conceptual
framework for implementation of the security policy and
performance evaluation are also presented in this work..
C. Policy supporting Multi-tenancy
Taking multi-tenancy into consideration, Calero [13]
propose a multi-tenancy authorization system in the PaaS layer.
The proposed authorization model supports multi-tenancy,
RBAC, hRBAC, path-based object hierarchies, and federation.
Almutairi et al. [14] propose the architecture for the cloud to
address problems of distributed access control, side-channel
attacks and noninterference in the presence of multi-tenancy,
and resource virtualization. An XML-based declaration of
access control policies is used in this architecture.
D. Policy as a Service
Treating policy as a service, Lang [15] analyzes security
and compliance concerns, and points out the need for a novel
cloud service that automates security policy and compliance
implementation. He believes that model-driven security policy
automation is an ideal policy implementation for cloud
applications. A solution of policy as a service has been
implemented using ObjectSecurity OpenPMF. Hussain [16]
presents Security as a Service (SECaaS), a service-oriented
architecture (SOA) that handles security of cloud computing,
SECaaS takes a user-centric approach and allows users of the
cloud to rely on the security measures provided elsewhere in
the cloud. But this work lacks implementation details and fails
to address communication overhead between different parts of
the cloud, not a trivial issue.
E. Sticky Policy
Policies that attach conditions and constraints to data to
define allowed usage and obligations are called sticky policies.
The sticky policy paradigm was first proposed by Karjoth,
Schunter, and Waidner [17]. Pearson and Mont [18] apply
sticky policies for enabling accountable management and
disclosure of confidential data across boundaries. They
developed core mechanisms for managing sticky policies
within the EnCoRe project along with a public-key-encryptionbased implementation. Tang [19] provides an overview and
comparison of sticky policy enforcement using different
encryption techniques, including Public-Key Encryption
(PKE), Identity-Based Encryption (IBE), Attribute-Based
Encryption (ABE), and Proxy Re-Encryption (PRE). As a

result of the comparison, an extension of PRE called Typebased PRE (TPRE) is proposed for enhancing sticky policy
enforcement.
F. Policy language
Policy language is also a hot topic, and a number of policy
languages have been presented in the last few years, for
example, the eXtensible Access Control Markup Language
(XACML) and its extending authorization profile XSPA.
XACML [20] provides a mechanism for specifying security
and privacy policies. XSPA [21] fosters interoperability in the
healthcare context and introduces mechanisms to enforce
authorization policies controlling access to information,
possibly stored across enterprise boundaries. Kuang et al. [22]
review recent research approaches that focused on security
policy integration and conflict reconciliation among various
healthcare organizations. Based on the results of their analysis,
they proposed an approach for integrating security XACML
policies based on an RBAC policy model considering both
constraints and meta-data information. They also focus on
solution of policy redundancy and conflicts. Hu et al. [23]
present a Semantic Access Control Policy Language (SACPL)
for cloud computing environments. They introduce Access
Control Oriented Ontology System (ACOOS) as the semantic
basis of SACPL, aiming to solve the interoperability issue of
distributed access control policies. The ACOOS is used to
annotate the syntax elements of XACML with semantic
information. The authors also add some syntax elements such
as priority and confidentiality.
G. Policy applied in Healthcare Domain
Security policies in healthcare applications have been a
popular research topic among researchers since data security
and patient privacy are always very important to healthcare
service vendors and practice. Katt et al. [24] propose an
architecture that enables access control for cross-domain
document exchanges according to policies that are stored in a
central repository. Jin et al. [25] propose an access control
scheme that supports patient-centric selective sharing of EHRs
(Electronic Health Records). This work discusses policy
specifications that take into consideration distributed data
integration and privacy protection and provide a mechanism to
identify and resolve policy anomalies in the process of policy
composition. Ardagna et al. [26] propose an access control
solution based on the definition of policy spaces, aiming at
better regulating break the glass exceptions that occur in
healthcare systems. Policy space is defined as a policy
repository for policies that regulate access to resources. In this
solution, the policies are defined, composed and evaluated in
different spaces by means of algebra. Deng et al. [27] propose
an approach to build a trustworthy cloud platform motivated by
the specific requirements of healthcare applications and the
trustworthiness of healthcare platforms. The proposed solution
is based on using federated cloud architecture to enforce
common security and data protection policies in various cloud
layers.

A. Reasons for Using Security Policy Meta-model

A security policy meta-model defines the underlying
vocabulary and relations to describe policy contexts in the
security domain. Adopting such a meta-model is based on the
following considerations:

C. A Meta-model for Security Policies

As shown in figure 1 with UML(Unified Modeling
Language) notations, a security policy set contains multiple
security policies, and each one consists of several policy rules.
A policy rule is composed of six parts: rule ID, security goal,
priority, claim, effect, and condition. The specification of our
meta-model can be formally defined as follows:

- A meta-model can abstract from underlying technology

and assess more generic domain models. Being more generic
leads to better reuse of domain concepts.

Definition 1 (Action) An action defines the type of access.

Examples of actions are read, write, execute and so on. ACT
stands for the set of actions.

- A meta-model can support automatic/semi-automatic

transformation of a conceptual model of a policy context to
generate concrete policy models.

An action can be further divided into two sub-actions:

policy action and obligation action. Policy action defines the
type of access that subjects can perform on objects; obligation
action defines what must be carried out before or after an
access is approved.

III. A SECURITY POLICY META-MODEL

- A meta-model helps to partition the problem domain.

B. Requirements of Security Policy Meta-model
A meta-model should satisfy the following requirements:
- Implementation-independent: it is not limited to a
particular access control model, language, or security policies.
It should be separate from the details of enforcement.
- Fine-grained granularity: big data may have a complex
structure and require different and high-granular policies for
data access control and handling; hence, a meta-model must
provide fine-grained authorization features, based not only on
request context attributes, but also on data content and
constraints.
- Better integration: as scenarios of big data applications
vary greatly, a meta-model should incorporate solutions that
better suit the requirements of particular application situations
from the perspective of big data users.

An action can be optionally associated with a service,

which is an implementation of the action. A service contains
two attributes: information about the service provider, and the
detailed service address.
Definition 2 (Object) An object is an entity that is accessed
by a subject. An object could be documents, data or other
resources. For example, for a distributed key-value-store, the
value of a key-value-pair will be referred to as data and should
hold an arbitrary byte sequence. OBJ stands for the set of
objects.
An object is defined as a tuple obj=<dtype, datri, dsens,
dpurp> where,

Fig.1 A meta-model for security policy

dtype refers to the type of data object, for example, text,

audio or image ;
datri refers to attributes of an object, an object can have
multiple attributes, for example, data identifiers, access path
and so on;
dsens refers to the sensitivity classification of an object;
dpurp refers to the intended purposes/reasons for data
access and it is domain specific, for example, in the healthcare
domain, possible purposes include payment, treatment,
research, and so on.
Definition 3 (Subject) A subject is an active entity that
requests permissions to perform some actions over objects. A
subject could be a user, a user group, a process or a service and
so on. Let ROL and CRE be the sets of roles and credentials
(for example, user ID or X.509 Certificate), respectively. A
subject sub is defined as a tuple sub = <rol, cre>, where, rol
ROL and cre CRE. Overall, the subject set SUB is defined as
SUB = ROLCRE.
Definition 4 (Rule Claim) A rule claim is a statement that
describes who can execute which action on which data object;
a rule claim is defined as a tuple cla =<sub, obj, act > where,
sub stands for a subject, sub SUB;
obj stands for an object, obj OBJ;
act stands for actions, act ACT;
Definition 5 (Policy Rule) A policy rule is defined as a
tuple pol =< rid, gol, pri, cla, eff, rcd > where,
rid refers to a rule identifier of policy rule and should be
globally unique.

gol refers to a security goal, gol G, G is set of different

type of security goals including confidentiality, integrity,
privacy and so on.
pri refers to a priority level of a policy rule, pri P, P is
the set of priority levels, for example, P= {very high, high,
medium, low, very low};
cla is a main element of a policy rule, describing which
subject (entity requesting access) wishes to do which
actions(the type of access and its related security service) to
which object (data) under certain constraints, cla CL, CL is
the set of claims;
eff refers to the authorization effect of a policy rule, eff E,
E is set of effects, for example, E = {permit, deny} is one
popular definition;
rcd refers to conditions or constraints of a policy rule as a
boolean formula that evaluates conditions of the context as
well as of subject and object; context information includes
temporal, spatial or meta-data information, for example, the
state of the application, the number of accesses to a given
object, time/date and so on.
IV. A POLICY FRAMEWORK FOR BIG DATA SECURITY
A. Stick- policy-based framework
We have designed a sticky-policy-based framework for big
data security. There can be different degrees of stickiness, but
we adopt a loose-couple binding in which data fragments and
their sticky policies are stored separately, as this provides
better infrastructure compliance. The architecture of this
framework is depicted in figure 2.

Fig.2 Sticky policy based framework

The architecture of our framework can be logically divided

into two parts: the trusted authority domain and the data center
domain. The trusted authority domain includes two
components: an identity & key management engine and a
policy engine. The Data center domain stores the encrypted
data. Depending on different deployment models in the cloud,
the data center domain can be a trusted domain (in the case of
private cloud) or an untrusted domain (in the case of public
cloud or hybrid cloud). In the case of the private cloud, the
trusted authority domain and data center domain can be
logically deployed together and there is no need for data
encryption. For completeness, the data center deployed in the
public cloud is assumed in figure 2 and in the following
sections.
In the data center domain, data can be stored in either
database or hadoop distributed files system (HDFS) and
accessed through a corresponding access library. An
encryption/decryption algorithm may be performed if needed.
In the trusted authority domain, the identity & key
management engine is responsible for management of users,
their authentication, authorization, and privileges. It is also
responsible for management of keys stored in the key
repository.
The policy engine is the core component of the trusted
authority domain. It provides security by keeping track of
promises the involved parties make to access data, along with
controlling access to such data. The data is encrypted and is
only accessible upon the acceptance and satisfaction of
specified constraints and duties imposed by the policies. This
includes several sub-components: the policy portal, policy
controller, policy negotiation component, policy update
component, enforcement component and policy store.
- Policy portal: the entryway to the policy engine,
receiving requests from the data owner/user and sending the
response to them.
- Policy controller: the control component of the policy
engine; it decides and forwards the request to the responding
component;
- Policy negotiation component: as implied by its name,
policy negotiation is its function.
- Policy updating component: In practice, the data owner
may need to update security policies on his/her data from time
to time, such requirements can be satisfied by this component.
- Enforcement component: asserts whether the data user
has fulfilled customized sticky policies or not. Only after
satisfying all the requirements will policy action and obligation
action be executed. Obligation actions may be required before
policy actions are performed, after the policy action has been
performed, or simultaneously with the performance of the
policy action. The enforcement component will then notify the
identity & key management component to release the keys for
decrypting data. In addition, policy negotiation and policy
updating also need an efficient enforcement mechanism to do
their jobs.
- Policy store: deals with policy storage, mapping between
sticky policy and data, and policy audit. It contains three parts:

(i) Policy database: the location where policy rules can be

safely stored and retrieved. According to definition 5, each
rule has a rule identifier (RID), which the policy database
returns to the data owner when he/she asked to store a rule. The
data owner can subsequently use the RID when asking the
sticky database to stick this rule to certain data. This design
cleanly separates the implementation details of the policy
database from the rest of the infrastructure, and allows different
types of policy database to be constructed e.g. built on an
LDAP directory or RDBMS.
(ii) Sticky database: holds the mapping between sticky
policy rules and the data objects to which they are stuck. This
is a many to many mapping so that one rule can apply to many
data objects and one data object can have many rules applied to
it. The design requires that each RID be globally unique so that
when a rule is moved from system to system, the receiver can
determine if it needs to analyze each received rule or not.
Already known RIDs dont need to be analyzed, whereas
unknown RID will need to be evaluated to ensure that they can
be supported, otherwise the incoming data and sticky policy
rule will be rejected.
(iii) Audit database: audits policy fulfillment, it logs and
tracks what happens to data, consent, and revocation during
operational and administrative activities. This audit trail is
available to user and the trusted authority afterward in case of
policy violations or misbehavior.
B. Policy Enforcement
Figure 2 shows the basic mechanisms to manage sticky
policies, which can be achieved using various cryptographic
techniques, including identity-based encryption (IBE), publickey encryption and other approaches. In other words, we can
potentially use any encryption mechanism to associate policies
with data.
Taking IBE as an example, the main concept of policy
enforcement using IBE is letting the data owner encrypt the
data using the data user's IBE identity, letting the trusted
authority enforce the remaining constraints, while letting the
trusted authority enforce the policy for issuing the data user's
private key. An IBE schema can use any kind of string as a
public encryption key, including names, roles, terms, or
conditions. The generation of the corresponding IBE
decryption key can be postponed. The trusted authority can
generate this decryption key on the fly, under specific
circumstances.
We adopt IBE by mapping a rule to an IBE encryption key.
The trusted authoritys role is expanded to check the integrity
and trustworthiness of the data users credentials and its
environment before releasing the decryption key. The trusted
authority also logs and audits disclosures of confidential data.
Figure 2 shows an example of this process, in which the
labeled stages are as follows:
1. The data owner describes which data user will be granted
access to certain data under specified constraints, and generates
a policy rule, then sends the rule to the trusted authority.
2. The data owner encrypts the data by using the selected
identity as public encryption key, and then stores encrypted

data in the data center. If desired, different data fragments can

be encrypted separately by using different identities selected at
this stage.

- Unconditional permit, which corresponds to policies

regulating all access requests not covered by the previous
policies, authorization effect of those polices is permit.

3. The trusted authority establishes the mapping relation

between the rule and the data object to which it is stuck and
stores the mapping relation into the sticky database.

When an access request is received, the sets of applicable

policies in policy database are selected by evaluating
constraints and conditions.

4. The data user sends a request to the trusted authority for

data access, which involves passing on the sticky policy and
identity.

Figure 3 shows a general security policy evaluation flow

(using IBE as an example). Since a data owners job is simple,
we will focus on the trusted authoritys view and data users
view.

5. The trusted authority checks policies, potentially

including challenges to the data user. The data user might need
to provide signed statements about its policy rules.
6. If all the policy checks are fulfilled and identity is
validated, the trusted authority releases the private decryption
key to the data user.
7. The data user can get the encrypted data from the data
center and decrypt it by using the private decryption key.
C. Policy Evaluation
Policy evaluation refers to the process of checking whether
a request satisfies a policy rule and thus determining the
authorization effect of this rule. In our proposed framework,
policy evaluation is performed in the policy enforcement
component. In common scenarios, the authorization effect of a
policy rule is either permit or deny. But in some special
scenarios of a certain domain, this is not enough. For example,
more complicated scenarios can be found in healthcare, in
cases of emergency, although the requester does not have the
authorization to perform the action requested, the request is
always permitted to save patients. This is the famous breaking
the glass (BTG) rule in the healthcare domain.
Taking these special scenarios into consideration, we define
five security rule effects listed below, including: common
deny, common permit, domain deny, domain permit,
unconditional permit, with precedence from high to low. These
effects are listed below:
- Common deny, which corresponds to domain
independent policies (representing common practice in real life)
that are used to prevent abuses, they must be strictly enforced
without any exceptions.
- Common permit, which corresponds to domain
independent policies (representing common practice in real life)
that are used positively to grant authorizations.
- Domain deny, which corresponds to domain dependent
policies that can be divided into two types: all default deny
policies in a domain and policies that must strictly enforced in
complicated scenarios. These policies reflect actions that
cannot help even in complicated scenarios such as emergency
situation of a domain, but can only cause privacy breaches and
must be avoided.
- Domain permit, which corresponds to domain dependent
policies that can be divided into two types: all default permit
policies in a domain and policies which are applicable to all
requests that happen in complicated scenarios, such as
emergency situation.

Fig.3 A General security policy evaluation flow

After having received a policy request, the trusted authority

will evaluate what kind of policy (classified by authorization
effects) it belongs to and make a response. We assume that the
policy evaluation can result in three outcomes: i) true, positive
evaluation; ii) false, negative evaluation; iii) unknown, no
applicable policy has been found. The evaluation process
works as follows.
Firstly, policies that fit into the common deny category
are evaluated against the request. If the evaluation result is
true, the request is denied. Otherwise, the request is evaluated
against the set of applicable policies with common permit
effect. Then, if the evaluation result is true, the request is
granted. Otherwise, the request is evaluated against the set of
applicable policies with domain deny effect. Similarly, if the
evaluation is true, the request is denied. Otherwise, the
request is evaluated against the set of applicable policies with
domain permit effect. If the evaluation is true, the request is
granted, for example, BTG rule will be permitted at this step.
Otherwise, the request will finally be forwarded and evaluated
against the set of applicable policies with unconditional permit
effect, and the request is granted. The request and evaluation

result will create a log record, which will be inserted into audit
log database. The trusted authority is then able to perform a
subsequent analysis to possibly individuate abuses or access
requests that should be regulated by defining a proper set of
policies. Depending on the evaluation result, the trusted
authority decides whether to release the private decryption key
or refuse.
From the data users perspective, after sending a data
access request, he/she will get a response that is either permit
or deny. If the result of response is permit, he/she can get the
private decryption key from the trusted authority, then
downloads the data required from data center and decrypts it
by using the key. Otherwise, he/she will be denied to access the
data.
V. AN APPLICATION USE CASE IN HEALTHCARE
This section uses a scenario in healthcare to illustrate an
application of the proposed framework. The scenario is
described as follows:
Suppose there is a child (no more than 12 years old) who
has a broken leg and some contusions on his body (indicating
that he may have been abused) is brought into a hospital by
ambulance late one night, and his mother accompanies with
him. He is taken to the emergency room and is seen by
emergency room doctors.
In this scenario, several users are involved and each user
has a different role and access control requirements for
accessing the hospitals EHR(Electric Health Record) data.
These users include: (1) the child who needs treatment; (2) the
childs parent; (3) the emergency doctors; (4) the nurses; (5)
the social workers who are possibly responsible for helping the

children in case of abuses; (6) the police officers who are

responsible for investigating and establishing possible criminal
charges, in case of abuses.
Table 1 shows the security policies that regulate the access
of different users to the hospitals EHR data or payment data.
For simplicity, a security policy rule can have multiple actions.
Each users request will be evaluated by the flow depicted in
figure 3.
Let us walk through the events that would occur in this
scenario. Initially, the emergency doctor takes a history, fills in
the electronic patient record, assigns the child to a nurse, and
orders a series of examinations. These actions are allowed,
because this is an emergency situation and authorization of rule
R8, R9 evaluates them as true. Nevertheless, both the doctor
and nurse need fill out a report form.
When the emergency doctor has received the examination
results, he suspects the child of having been abused. As a
consequence, the police and social services are informed of
possible abuse. Now, the police are responsible for the abuse
investigation and require access to the childs EHR data for
investigation purposes. The access request of the police is
allowed because authorization of rule R11 evaluates it as true,
but the police men need to fulfill their obligations by informing
the hospital.
At the same time, the social worker who is responsible for
helping the abused child also requests access to the childs
HER data. As with the police, the social workers request is
allowed because authorization of rule R11 evaluates it as true.

TABLE 1 POLICIES FOR A FICTIONAL HOSPITAL

VI. CONCLUSION
This paper presents a meta-model for security policies and
a comprehensive framework for access management at the IaaS
level. The advantages to using our meta-model include easy
upgrading, customization, automatic evaluation and validation
of security policies. The proposed framework is being
implemented on the open source IaaS platform OpenStack,
using HDFS and MySQL for data storage and adopting IBE as
the encryption method. However, we must address several
challenges including policy heterogeneity and policy
aggregation in order to implement a fully secure and trusted
policy framework for big data infrastructure. For future work,
we plan to address these challenges by developing automated
security policies, mediation for conflict resolution of
heterogeneous policies, and auditing and compliance for policy
enforcement.
REFERENCES
[1]
[2]

Tankard, Colin. "Big data security". Network Security, 2012, no.7: 5-8.
Domenico Talia. "Clouds for Scalable Big Data Analytics". IEEE
Computer, 2013, vol.46, no.5: 98-101.
[3] Karadsheh, Louay. "Applying security policies and service level
agreement to IaaS service model to enhance security and transition".
Computers & Security, 2012, vol.31, no.3: 315-326.
[4] Chunming Rong , Son T. Nguyen , Martin Gilje Jaatun. "Beyond
lightning: A survey on security challenges in cloud computing".
Computers and Electrical Engineering, 2013, vol.39, no.1:47-54.
[5] Mark Dermot Ryan. "Cloud computing security: the scientific challenge,
and a survey of solutions". Journal of Systems and Software, 2013,
vol.86, no.9: 2263-2268.
[6] Min Chen, Shiwen Mao, Yunhao Liu. "Big data: a survey". Mobile
Networks and Applications, 2014, vol.19, no.2: 171-209.
[7] David Ferraiolo, Janet Cugini and Richard Kuhn "Role-based Access
Control (RBAC): Features and motivations". Proceedings of 11th
Annual Computer Security Applications Conference, 1995, pp. 241248.
[8] Abou ElKalam A, El Baida R, Balbiani P, Benferhat S, Cuppens F,
Deswarte Y, Mi`ege A, Saurel C, Trouessin G. "Organization based
access control". Proceedings of IEEE 8th international workshop on
policies for distributed systems and networks, 2003, pp. 1-12.
[9] Louay Karadsheh. "Applying security policies and service level
agreement to IaaS service model to enhance security and transition".
Computers & Security, 2012, vol.31, no.3: 315-326.
[10] Said Oulmakhzoune, Nora Cuppens-Boulahia, Frdric Cuppens,
Stephane Morucci, Mahmoud Barhamgi, Djamal Benslimane. "Privacy
query rewriting algorithm instrumented by a privacy-aware access
control model". Annales des Tlcommunications, 2014, vol.69, no.1: 319.
[11] Mukesh Singhal, Santosh Chandrasekhar, Tingjian Ge, Ravi S. Sandhu,
Ram Krishnan, Gail-Joon Ahn, Elisa Bertino. "Collaboration in
multicloud computing environments: framework and security issues".
IEEE Computer, 2013, vol.46, no.2: 76-84.

[12] Takabi Hassan. "A semantic based policy management framework for
cloud computing environments". Doctoral Dissertation, University of
Pittsburgh, 2013.
[13] J. M. Alcaraz Calero, N. Edwards, J. Kirschnick, L. Wilcock, M. Wray.
"Toward a multi-tenancy authorization system for cloud services". IEEE
Security and Privacy, 2010, vol.8, no.6: 48-55.
[14] Abdulrahman Almutairi, Muhammad I. Sarfraz, Saleh Basalamah, Walid
G. Aref, Arif Ghafoor. "A distributed access control architecture for
cloud computing". IEEE Software, 2012, vol.29, no.2: 36-44.
[15] Ulrich Lang, Rudolf Schreiner. "Analysis of recommended cloud
security controls to validate OpenPMF policy as a service".
Information Security Technical Report, 2011, vol.16, no.3: 131-141.
[16] Mohammed Hussain , Hanady Abdulsalam. "SECaaS: security as a
service for cloud-based applications". Proceedings of the Second Kuwait
Conference on e-Services and e-Systems, 2011, pp. 1-4.
[17] G. Karjoth, M. Schunter, M. Waidner. "Platform for enterprise privacy
practices: privacy-enabled management of customer data". Proceedings
of 2nd Workshop on Privacy Enhancing Technologies, 2002, Springer,
LNCS, vol.2482, pp. 69-84.
[18] Siani Pearson, Marco Casassa Mont. "Sticky policies: an approach for
managing privacy across multiple parties". IEEE Computer, 2011,
vol.44, no.9: 60-68.
[19] Tang Qiang. "On using encryption techniques to enhance sticky policies
enforcement". Technical Report TR-CTIT-08-64, Centre for Telematics
and Information Technology University of Twente, Enschede, 2008,
ISSN 1381-3625.
[20] eXtensible Access Control Markup Language (XACML) Version 2.0.
http://docs.oasis-open.org/xacml/2.0/access_control-xacml-2.0-corespec-os.pdf, February 2005.
[21] Cross-Enterprise Security and Privacy Authorization (XSPA) Profile of
XACML v2.0 for Healthcare Version 1.0. http://www.oasisopen.org/committees/document.php?document_id=34164&wg_abbrev=
xacml, August 2009.
[22] T. P. Kuang, H. Ibrahim, N. I. Udzir, F. Sidi. "Security extensible access
control markup language policy integration based on role-based access
control model in healthcare collaborative environments". American
Journal of Economics and Business Administration, 2011, vol.3, no.1:
101-111.
[23] L. Hu, Sh. Ying, X. Jia, K. Zhao. "Towards an approach of semantic
access control for cloud computing". Proceedings of First International
Conference on Cloud Computing (CloudCom09), 2009, pp. 145-156.
[24] B. Katt, R. Breu, M. Hafner, T. Schabetsberger, R. Mair, F. Wozak.
"Privacy and access control for ihe-based systems". Proceedings of First
International Conference Electronic Healthcare, 2008, pp. 145153.
[25] Jing Jin, Gail-Joon Ahn, Hongxin Hu, Michael J. Covington, Xinwen
Zhang. "Patient-centric authorization framework for electronic
healthcare services". Computers & Security, 2011, vol.30, no.2: 116127.
[26] Claudio Agostino Ardagna, Sabrina De Capitani di Vimercati, Sara
Foresti, Tyrone Grandison, Sushil Jajodia, Pierangela Samarati. "Access
control for smarter healthcare using policy spaces". Computers &
Security, 2010, vol.29, no.8: 848-858.
[27] Deng, M., Nalin, M., Petkovic, M., Baroni, I., Marco, A. "Towards
trustworthy health platform cloud". Proceedings of Secure Data
Management Workshop, 2012, Springer, LNCS, vol.7482, pp. 162175.