What is Entitlement

Management?

Entitlement Management is a term used to define important aspects of Access Control

procedures and technologies in modern IT infrastructures. The term is fairly new and not
always used consistently.

Entitlement Management — a new access control

paradigm

Axiomatics defines Entitlement Management as a policy-based approach to enterprise-

wide access control. Our products support the following aspects of policy-based
authorization:

1. Access Policy Management - designing and maintaining access

control policies
2. Access Policy Enforcement - controlling access requests and
enforcing access decisions in real-time
3. Access Policy Auditing - reviewing and verifying the effectiveness
and efficiency of access controls and policy compliance

Moreover, an entitlement management solution needs to meet the following

requirements:

• Standards-based - ensuring interoperability between platforms,

applications and organizations, i.e. no more proprietary solutions and
vendor dependencies.
• External to applications - providing access control to other services
and applications, lowering the cost of application development and
enabling consistent and enterprise-wide access policies.
• Fine-grained - defining access policies in terms of attributes of
subjects (users), resources and the environment in which access is
requested. This approach goes beyond all the previous access control
models including Role Based Access Control (RBAC).

• Context-aware - defining access policies not only to answer the

question "who can do what on which resource?", but also "Why?",
"When?", "Where?" and "How?". Rules and policies combining various
attributes define the context for a permitted access.

What is ABAC?

Attribute-Based Access Control (ABAC) uses attributes to describe access control rules
and access requests in a structured language. Attributes are sets of labelled properties
which can be used to describe any entity (not only the subject) that needs to be
considered for authorization purposes. ABAC thus offers fine-grained and context-aware
access control that adapts to dynamically changing needs.

An abstract view of access control requests can be summarized as follows:

A subject… … wants to … with a … in a given
do something… resource …. environment or under
given circumstances
Examples:
Medical … wants to … patient A. … in the hospital's
doctor on edit… Smith's health emergency reception
duty… record… office.
Mr. Brown, … wants to … an online … from his home
father, … access… absence report computer via the
from his daughters Internet at 11 pm.
school…
Bank … wants to … from bank … via ATM machine
account withdraw €200 account xyz… A located in city B.
holder… …

Thus, any syntactically correct and semantically meaningful sentence describing an

access request in one way or the other will include building blocks which can be
described with attributes:

What is XACML?
eXtensible Access Control Mark-up Language (XACML) is a structured language for
expressing access policies and a query-response protocol for access requests and
decisions. XACML develops as standard within the Organization for the Advancement
of Structured Information Standards (OASIS).

The XACML language is constructed by a number of building blocks.

A Rule defines an effect (permit or deny) for a target that is described in terms of
attributes of subject, resource, action and environment and the conditions for these
attributes.
A Policy consists of rules and a rule-combining algorithm that defines how effects of
rules override each other.

A Policy Set consists of policies and a policy-combining algorithm that defines how
effects of policies override each other.

Besides the structured language and the query-response protocol, XACML has a higher
level architecture consisting of a number of functions (components) as follows.

• Policy Decision Point (PDP) - the heart of an XACML solution that makes the
access decisions.
• Policy Enforcement Point (PEP) - the most security-critical component in the
solution, which protects the resources and enforces the PDP's decision.
• Policy Information Point (PIP) - the external information store providing the
attribute data needed for access decisions.
• Policy Repository (PR) - the XACML policy storage.
• Policy Administration Point (PAP) - the XACML-policy editor.

The relations and the interactions between these components are described in the figure
below.
How does ABAC (Attribute-Based Access Control)
compare to RBAC (Role-Based Access Control)?
Role Based Access Control (RBAC) was originally introduced to simplify the
administration of access permissions, by avoiding direct assignment of them to
individual users, and increasing the level of security by facilitating a mechanism to
enforce Least Privilege and Separation of Duty principles.

Although RBAC is a well-defined model, most large RBAC projects turn out to be very
costly and almost impossible to finalise. The main issues with these projects are:

• Interoperability - difficulties to agree on a set of roles with a common meaning

that can be shared between applications, platforms, domains and enterprises.
• Role explosion - too many roles without clear organisational definitions need to
be administered. In some cases the number of roles has become larger than the
number of users in the enterprise.

The interoperability issue is due to the fact that "role" is used in many different ways
and there is no real consensus regarding the terminology. A role can refer to a job
function within an organisational structure, a group and or a name for a collection of
access permissions. However, a job function may have more than one name in different
applications and domains, which of course, leads to confusion and a large number of
non-interoperability issues.

The role explosion issues is due to the fact that RBAC, similar to traditional access
control models Access Control List (ACL) and Mandatory Access Control (MAC),
defines access permissions statically in the form of a snap-shot without considering the
context of the access. Capturing the context, including the dynamics of the environment
in which access permissions can be defined, would mean defining a large set of roles
including permissions for each possible context. Moreover, defining fine grained access
permissions would also create many sets of permissions causing role explosion.

RBAC only focuses on subjects and the permissions granted to them. A user can be
assigned multiple roles and thereby indirectly acquire permissions to related resources.
However, ABAC is quite the opposite, all aspects of an access request are considered
and identified by attributes: the subject who is demanding access, the action which the
subject wants to perform, the resource being accessed and the environment or context in
which access is requested.

This all-inclusive approach makes ABAC an ideal choice when finer granularity and
context-aware authorizations are required. ABAC can be used to create portable and
reusable policies which need to be enforced consistently across multiple platforms and
applications.

In ABAC permissions are defined in terms of privilege-giving attributes. Instead of

defining new roles to represent sets of access permissions ABAC defines the permission
sets by combining the privilege-giving attributes. For example, the three attributes being
an employee, having a driving license and being a Swedish citizen may in different
combinations give different sets of access permissions. Potentially there would be 8 (23)
different sets of access permissions, hence in RBAC 8 different roles that can be named
and need to be managed. But in ABAC we only need to manage the 3 well understood
privilege-giving attributes, which is of course a much simpler task than managing 8
different roles that in most cases do not have any meaning in the organisation.

Governance, Risk and Compliance Management Simplified

Modern IT infrastructures empower their users and thereby introduce new risks. With a
few clicks a single user can subvert a business-critical process and cause considerable
financial loss.

Governance, Risk and Compliance Management (GRC) programs used to implement

efficient and effective control frameworks are therefore becoming an increasingly
important focus area for IT and business managers alike.

However, GRC initiatives tend to be reactive, striving to optimize the existing

monitoring, surveillance and auditing capabilities of an organization. Streamlining and
merging control frameworks from different compliance regimes is one common
approach. Nonetheless, even if the GRC overhead becomes more efficiently managed, it
keeps growing.

To achieve a sustainable solution to this problem we need to attack the root cause.
Risk-intelligence must be built into our IT-infrastructures.

This is where Attribute-Based Access Control (ABAC) and Entitlement Management

play an important role by providing:

• A standardized way to translate regulatory requirements into access control

policies
• Automated and distributed real-time enforcement of policies at every entry point
• Enterprise-wide and consistent policy modelling from a central point
• Context-aware policy interpretation to adapt to dynamically changing conditions
• Centralized auditing capabilities to answer questions such as "who can do what?"
and "who has done what?"

Entitlement Management with ABAC thereby offers real-time enforcement of access

control policies which implement regulatory compliance and risk mitigation plans as a
component of normal day-to-day processing. It enables a shift from reactive surveillance
to proactive enforcement which in turn reduces the GRC overhead and improves control
efficiency.

Why Axiomatics?
All right, I'm convinced. Entitlement Management, Attribute Based Access Control
(ABAC) and XACML all make sense. But why Axiomatics rather than one of the full
suite Identity & Access Management vendors?

Entitlement Management solutions provide essential infrastructure base components and

the fundamental building blocks for future information security strategies. The integrity,
confidentiality and availability of your most sensitive information is at stake. Hence,
trust is key. Procurement procedures need to establish strict requirements to ensure
selected vendors are trustworthy.

These are some of the conclusions that existing Axiomatics customers have drawn:

• Commitment. XACML simplifies authorization, yet the technology solution is

complex. Vendors need to be fully committed. Simply adding XACML request-
response capabilities to existing access control engines is insufficient. You need
truly vendor-independent, portable and native XACML policy management in
addition to the capabilities of version 3.0 to handle delegation of administrative
privileges. Axiomatics is the only vendor committed to supporting the full scope
of the XACML standard and thus the only vendor capable of meeting these
requirements.
• Know-How. In most organizations the introduction of Attribute Based Access
Control (ABAC) means switching paradigms. This can be a daunting task
without the expertise and support from people who truly understand the profound
effects of transition towards a more sustainable infrastructure. The Axiomatics
team has successfully delivered technology for some of the largest XACML
deployments worldwide. Furthermore, Axiomatics products have developed out
of research projects and several members of the company have Ph.Ds in areas
relating to XACML and Attribute Based Access Control (ABAC).
• Vendor-independence for sustainability. One major advantage with a move in
the direction of XACML and ABAC is that what formerly required proprietary
code implemented in each single application, becomes standards-compliant and
open in future infrastructures. Axiomatics is a dedicated vendor without a legacy
of former proprietary solutions and vested interests, an ideal partner when future-
proof access control solution are needed.

Axiomatics is the choice of organisations that require a dedicated vendor capable of

offering a long-term partnership.

SOA developers standardizing their

authorization services

Service Oriented Architectures (SOA) have rapidly evolved and matured in recent years.
Many organizations have standardized all new development within their infrastructures
on SOA concepts. Hence, SOA governance is becoming increasingly important to avoid
the chaos that emerges out of uncoordinated initiatives. SOA developers need to
externalize authorization management, while ensuring local enforcement of access
policies to meet new security and governance requirements.
XACML addresses essential SOA security requirements by introducing authorization as
a service. In fact, effective SOA governance can hardly be achieved without some kind
of shared authorization service as suggested by XACML. The Open Group, for instance,
with its Service Integration Maturity Model (OSIMM), suggests service security policies
should be "dynamic and managed in real-time" if a maturity level of 7 is to be achieved.
This is a strong business case for XACML.

In many enterprises, the SOA reality represents a patchwork of processes as illustrated

below. Layers of overlapping services are added as needs evolve. These are usually
delivering data from a base of legacy information systems to users. The dangers of
separate access control mechanisms being implemented in each single service becomes
obvious, especially in scenarios where data from multiple services is combined into
mashups. The perspective of one single component is simply too narrow for a valid
access control decision.

Fortunately, the
solution lies
within the SOA
technology itself.
Authorizations
and access control
can be deployed
as yet another
service. Moreover,
the authorization
service inherently
has the benefits of
the SOA concept.

This is achieved
by consolidating and centralizing administration of authorizations and externalizing real-
time access enforcement as opposed to what is commonly provided through proprietary
solutions in siloed applications.

Let the walls come tumbling down

The benefits of breaking the wall of silos and providing authorizations as a centralized
service to other services and applications are:

1. Simplified administration of policies.

2. Enterprise-wide access policies through design and enforcement
of policies which implement dependencies across applications.
3. Efficient compliance and auditing through elimination of
inconsistencies between policies in different applications.
4. Faster and more cost-efficient adaptation to changing
requirements by implementing access control in terms of policies and
not as part of the application code.

One of the main drivers of SOA based IT solutions is to make the enterprises agile and
ready to adapt to organizational changes and the dynamics of their environment. This
puts a lot of pressure on selected security solutions, including authorization management
and access control. Information security should not be a bottleneck. Authorization
mechanisms need to be as agile as the SOA concept itself, yet handle access policies
which can dynamically adapt to a changing context.

In terms of OSIMM, maturity level 7 "Dynamically Re-Configurable Services",

implicitly makes an architectural solution corresponding to the XACML standard a
necessity. Even with lower maturity levels, the advantage becomes obvious if the
selected architecture offers authorization as a centralized service.

Entitlement Management and Attribute Based Access Control (ABAC) based on

XACML provides an ideal policy based solution for SOA environments. It provides
efficient policy enforcement within each service while enabling a transfer of access
policy management from IT to the business. Partners of Axiomatics have successfully
incorporated XACML based authorization in their models, enabling a high level of
maturity in their solutions and providing cost savings through efficient reuse of
components.

Delegating access management for data shared on the ground or in the cloud
Operating environments owned and managed by an entity other than the information
owner, be it an outsourcing partner or a service provider in the cloud, often become the
information security manager's nightmare. Data processing resources can be outsourced,
but liability of information security and privacy always remain with the information
owner. Axiomatics delivers solutions based on XACML 3.0, with flexible delegation of
administrative privileges ideally suited to meet the needs of modern federated
environments.

Cloud computing is a new term for an established phenomenon. Services hosted by

external partners have been used for quite some time. Yet, cloud computing does imply
an escalation in terms of service distribution via virtualization of data processing and
storage, and access management certainly has not become any less complex.

In these new environments, many organizations have tried to resolve their access
management issues by means of federation. However, federated identities only address
issues with regard to authentication. To handle access permissions within the service
provided, delegation of authorization management privileges must also be achieved.

Service providers typically do not want to manage their client users' authorizations and
moreover, even if they are willing, the service provider may not be trusted. At the same
time, confidentiality and integrity requirements would be severely violated if other
clients were able to impact the authorization policies controlling user access.

A hierarchy of authorization management can help resolve difficult management tasks

by delegating management authority to the proper information owner entity. Hence, with
delegation of administrative access control privileges, Axiomatics XACML 3.0 based
solutions offer robust authorization services well suited to meet the needs in operating
environments where multiple information owners share services for data processing and
storage, or possibly even for mutual data exchange.

Using solutions based on XACML 3.0 and Attribute-Based Access Control (ABAC), a
service provider can configure the overall and general authorization schemes and then
delegate administrative privileges to the respective data owners within the realm of their
respective data processing needs.

Cloud Computing Security

by Sanjeev Verma |  Discuss this article »»

Before diving into the security aspects of cloud computing, let us first understand the
basic concept of cloud computing. In cloud computing, cloud stands for internet and
computing means using computer technology, hardware, and software, i.e. using or
sharing the computer technology, hardware and software over the internet. Different
cloud service models are as follows:

1. Cloud Software as a Service (SaaS): In this service model, the

consumer uses the provider’s applications on a cloud infrastructure.
The consumer does not manage or control the underlying cloud
infrastructure including network, servers, operating systems, storage,
or even individual application capabilities. However, the consumer
might have access to limited user-specific application configuration
settings.
2. Cloud Platform as a Service (PaaS): This service model allows the
consumer to deploy consumer-created or acquired applications onto
the cloud infrastructure, using programming languages and tools
supported by the provider. The consumer does not manage or control
the underlying cloud infrastructure including network, servers,
operating systems, or storage, but controls deployed applications and
possibly application-hosting environment configurations.
3. Cloud Infrastructure as a Service (IaaS): This service model
allows the consumer to provision processing, storage, networks, and
other fundamental computing resources. The consumer is hence able
to deploy and run arbitrary software, which an include operating
systems and applications. The consumer does not manage or control
 the underlying cloud infrastructure, but controls operating systems,
storage and deployed applications.

Let us see an example of the PaaS cloud service model with the help of a diagram
(shown below). In this example, Demo Bank is a cloud user (consumer) and his vendor
(cloud service provider) is ABC. ABC is providing PaaS (Platform as a Service) to
Demo Bank and Demo Bank has deployed his application (http://public.demobank.com)
on an ABC server called CCServer. Here, Demo Bank doesn’t have to worry about the
infrastructure cost and maintenance, and has control over the deployed application and
possibly application-hosting environment configurations. Eventually, a Demo Bank
client accesses the http://public.demobank.com application as if the application is
hosted by Demo Bank itself.

Diagram: Example of PaaS - Demo Bank Using PaaS cloud service provided
by ABC

Now we know what cloud computing is, but why do we need cloud computing? Well,
the answer is simple - it facilitates deployment of applications without the cost and
complexity of buying and managing the underlying hardware and software layers.

However, due to security issues, the benefits of cloud computing are not being reaped to
their fullest. Some of the important security issues are:

1. In cloud computing, a single server hosts multiple applications of

different users. Now, if any of the applications hosted on the server is
vulnerable, it might lead to compromise or unavailability of other
applications as well.
2. Since a variety of applications are hosted on a single server, it is very
likely that a large number of ports are open on the server, thus
widening the network-level attack surface. If any of the services
 running on these ports are vulnerable, the server can be
compromised.
3. Many cloud vendors use virtual machines to run different OS
instances on a single hardware platform for serving multiple users,
which opens up a new attack vector. These virtual machines have
multiple flaws that can be exploited in order to compromise the
server.
4. If an application with critical data is hosted on cloud, all sensitive and
critical information remain with the cloud service provider and there
is always a threat of theft of company proprietary information by the
cloud provider itself.
5. Due to lack of transparency, auditing is very difficult and at times not
possible in cloud computing. If something goes wrong with your
application or there is a possibility of unauthorized access, it would be
very difficult to conduct forensic investigations in cloud environment.
6. It is difficult to ensure the integrity of computational results of an
application in a cloud environment.
7. It is difficult to enforce the enterprise authentication and
authorization framework in cloud.

Furthermore, the accumulative effects of the above-mentioned issues result in many

legal implications and noncompliance to the industry standards for cloud consumers.
Hence, as with any security area, organizations should adopt a risk-based approach of
moving to the cloud and selecting security options. Some of the important security
options are:

• Identify the asset for the cloud deployment: Identify wherever it

is possible to shift only part of the application functions to the cloud
rather than the complete application and data. Evaluate the criticality
of these assets and the corresponding impact on business in case of
unavailability of these assets due to whatsoever reason.
• Take Back Authentication Control: Most of the time, the
authentication mechanism used for accessing (for management,
administration, or usage) cloud application is too weak. This results in
a breach, in which case, taking the authentication control back from
the cloud service provider is a good option. Obviously, it reduces
some of the benefits of the cloud, but it allows you to use strong
authentication mechanisms and implement the company standard
password policy, etc.
• Data storage and segregation: Typically the data in the cloud is in
a shared environment, which is why it is important to find out what is
done to segregate data at rest. The cloud provider should provide
evidence that encryption schemes were designed and tested by
experienced specialists.
• Transparency: Data owners wish to audit how their data is being
handled at the cloud, and in particular, ensure that their data is not
being abused or leaked, or at least have an unalterable audit trail
when it does happen. Hence, ensure that the cloud vendor provides
enough transparency.
• Choose Appropriate Cloud Deployment Model: Regardless of the
service model utilized (SaaS, PaaS, or IaaS), there are four
deployment models for cloud services. The appropriate cloud
deployment model is selected depending on the criticality of the
asset and specific requirements. Different cloud deployment models
are:
1. Public Cloud: The cloud infrastructure is owned by an
organization selling cloud services and is made available to the
general public or a large industry group.
2. Private Cloud: The cloud infrastructure is operated solely for
a single organization. It may be managed by the organization
or a third party, and may exist on premises or off premises.
3. Community Cloud: The cloud infrastructure is shared by
several organizations having similar requirements. Since the
cloud infrastructure is shared among fewer organizations, it
provides a higher level of security and privacy in comparison
with public clouds. Community cloud may be managed by the
organizations or a third party, and may exist on premises or off
premises.
4. Hybrid Cloud: The cloud infrastructure is a composition of two
or more clouds (private, community, or public). The objective of
hybrid cloud is to provide the local data benefits of the private
clouds with the economies, scalability, and on-demand access
of the public cloud.