Enterprise Application Roles Management –

cleansing and segregation of duties approach

G. Mateescu*, M.Vladescu*, V.Dache* and M.Caraivan*
*
Faculty of Automatics and Computer Science
Polytechnic University of Bucharest
Bucharest, Romania
georgiana.mateescu@gmail.com, vladescumariusnicolae@yahoo.com, caraivanmitrut@yahoo.com ,
valisor02@yahoo.com

Abstract— The present paper aims to present an approach

to manage the enterprise application roles during their life
cycle. The paper starts with a brief introduction that
presents the need and the importance of role management in
a healthy and secured enterprise. In the second section, we
detailed each step performed in order to ensure a sanitized
role environment. Starting from job title analysis, we
performed role engineering based on relevant statistics and
we targeted the majority of the company population.

Based on risk ranking algorithm, the roles are provisioned

to specific users ensuring in this way that the segregation of
duties is efficiently performed. At the end of our process we
adopt a certification based strategy for the migration
between current situation and the new role access matrix
built with this approach.
The paper ends with the main points and conclusions.
I. INTRODUCTION
The primary purpose of application roles is to allow
users to perform operations that require certain access
rights in the enterprise application. From security
perspective, all operations must be “safe” – in terms of
protecting the data involved from cyber attacks and being
compliant with the regulation specific in each domain.
The reason why application roles management is always a
hot topic in all internal and external security audits is its
main purpose: to emphasize the whole picture of the
company‘s everyday workflows and processes (the roles
are the mean by which critical and non-critical operations
executed on sensitive or non-sensitive data are related to
the people who are executing them).
RBAC [1] it’s a concept introduced in 1992 that offered
at that time a new approach regarding the access
management– starting from network access and ending
with application access. David Ferraiolo and Rick Kuhn
explained in their paper [1] why this model is optimal and
why a non-discretionary access control is more
appropriate in non-military environments.
II. ENVIRONMENT ROLES MODEL
The main characteristics of RBAC model – that we
will leverage in this paper are:
1. Role assignment – one person can perform a
specific operation on a specific data set only if
the appropriate role is assigned to him.
Figure 1. RBAC Model[8]
2. Role authorization – the role assignment must be
first authorized by the proper person. The role
authorization is made usually based on specific
rules that describe in their substance a measure
of role criticality.
3. Permission authorization – one person can
exercise permission in an application only if the
authorized role that has been assigned to him
contains that permission.
Moving deeper into this model, in order to ensure its
full efficiency and success in creating a secured
enterprise application context, the roles themselves must
have several characteristics. Among these properties we
can mention:
 A new role should appear as need to streamline
an existing workflow in the application – and
should be created after all interacting data
workflows and involved actors and systems
where analyzed – this analysis should be prior to
the creation of the role and should target the
areas where the application that owns the role is
running.
 A new role should be created for a considerable
population ( a role should be created when at
least 10% of the active population in the
application will have benefits of it or when the
role will be used to simplify existing workflow –
this may include decommission other roles ).
  A role should have a defined list of specific
properties of its members – meaning that from
audit perspective is very important to have
specific target that ensures a correct Segregation
of Duties. We will talk more about Segregation
of Duties in third section.
 A role should have specific rules assigned to it
depending on the targets defined in the previous
step. These rules include both assignment and
decommission phases in the role lifecycle.
 A role should include the description of all its
permissions together with the data that can be
processed using the role.
 A role should have attached the authorization
policies stating the types of authorizer, the
authorization periodicity and authorization
workflow (the approvers and the approval
levels).
III. ROLE CLEANSING PROCESS
The role cleansing process started with the following
facts:
 Our scope included a number of six applications
that covers different areas in a telecom company
including: retention, billing, customer
management, fraud, service desk application,
ordering.
 In application the implemented access model
was RBAC.
 The role in each application was driven by the
employee job title – and as exception the
employee could request account in an
application by following an two levels approval
workflow.
 Each role was composed by atomic permission
in four of the six applications and in each one of
these there were specific rights that could not be
combined (from segregation of duties
perspective). Because of these a lot of roles were
very similar, the only difference between their
permissions was the discriminator specified
earlier.
 There was one application where the roles were
not rules driven and because of that a lot of
duplicates were found.
 In one application there were two different
dimensions regarding the mean to process data
in the system: a user could operate the data using
his specific roles, but he had some additional
privileges depending on the group he was
member in (in fact the groups were the
implementation of the geographical dimension
in the role access matrix – the same job title had
different access in the application based on part
of the country the user works in).
 All roles in the application in scope will be
granted automatically to a user according to his
job title and if the user requires in his every day
job more roles, he can request them via self
service and specific approval workflow is
triggered before the role is provisioned.
Our process (Appendix 1 Figure 3 – Role Cleansing
Process) begun with a strong analysis regarding the
existing job titles and their population. From this
perspective we made the following statistics:
 Total number of job titles vs. the population –
this analysis revealed a lot of useful information:
20% of the actual job titles covered 80% of total
population, while 60% of them have less than 10
members. Finally the other 20% of the job titles
has a mean coverage. After this analysis we
decided to decommission 30% of the job titles –
mainly these were very similar job titles and the
only difference between them was the specific
period of the year as these job titles were
assigned to promoting personnel.
 For the remaining job titles, we analyzed how
many have direct impact in our target
application – here the number of the job titles
went even slower because only half on them
were in our scope.
 We grouped in scope job titles based on
departments and we tried to make a hierarchy of
the job titles in order to help us on a future
hierarchy in the application roles.
The next step was to analyze each application in
order to establish a criterion for roles compatibility
ranking in that specific application. In order to that we
used the following terminology:
 discriminator – one permission belonging to a
role that makes that role incompatible with other
one very similar with it, the similarity residing in
the others permissions – two roles having one
discriminator cannot be combined;
 differentiator – one permission belonging to a
role that makes that role different from other
one – two or more roles having differentiators
can be combined;
 duplicate – a role very similar with other role.
Related to the second role, the first one has no
discriminator, but insignificant differentiator.
 container – a role that includes the main
permissions of other role and ensures that by
assigning it to a user that previously had the
 included role, he will be able to perform all
required operations on the specific set of data
without broking the segregation of duties
principles. The roles from this category have as
discriminators mainly the ability to generate
specific type of report that the user having the
included role is not able to run, but the reports
data in the data the user operates.

In this phase we analyze each application and define

for each of them discriminators, differentiators,
duplicates and containers. This analysis is made based on
two different dimensions: the job titles to which the roles
are assigned and the department where the job titles
Segregation of duties may be within an application or
belong.
within the infrastructure. In this section I will talk about
The output of this phase was the decommissioning of
segregation of duties in enterprise applications.
30% of the roles – mainly the duplicates and the roles
From security perspective, segregation of duties is a
included in containers, but also some deprecated roles.
key fact that ensures:
Other 20% of the roles were combined based on their
differentiators – this category affected 30% of total job
titles number and was the hardest process because it had a
lot of dimensions: permissions in application, job title,
department, and interaction with other application in
scope. The main strategy adopted was to give more
permissions rather than to cut them because, from the
business perspective there was no one affected in terms of
not being able to do their everyday jobs and in terms of
security the additional permissions were very specific
ones, that in order to be exploited require additional
training and the awareness of the user that he has the
specific permission.
The last step was to associate each of the new/old
roles to the specific job titles and the specific department
and analyze them together from the Segregation of Duties
perspective taking in count the interaction between in
scope applications and their specific.
This step will be detailed in the next section and it
had as output the new role-access matrix that was tested
and validated by business people.
IV. SEGREGATION OF DUTIES
Segregation of Duties [3] is the separation of
incompatible roles and permissions associated with roles
that could allow one person to commit and conceal fraud
that may result in financial loss or misstatement to the
company
Figure 2. Segregation of Duties Components[9].
 Regulatory Compliance – in each domain there
are laws protecting the confidential and sensitive
data of being processed by anyone. The
regulatory compliance is a point of interest in
every single company and it can be easily
achieved using a proper approach and strategy
regarding segregation of duties process.
 Security and Data Management –monitoring
and controlling security and access to data
within the organization is harder to achieve
because of all advanced hacking methods. This
characteristic refers to all data source involved
in an enterprise – starting from the authoritative
or trusted source of information, continuing with
the data processed in enterprise applications and
ending with data target systems. In order to
ensure a high level of the security, automatic
provision processes defined by rules and
authorization workflows must be implemented,
processes that make the overall activity from
both business and security perspective more
efficient and optimal.
 Access Management – Provisioning and
management of users access to applications have
not been enforced, resulting in authorization
processes prior to provisioning process that
based on the specific criticality of the user
requires fewer or more steps of approvals
performed by security staff within the company.

In our role management process we had to deal with

the Segregation of Duties concept in all six applications.
In order to achieve it we used criticality ranking attributes
for the roles involved that associate to each role a score
from 1 (least critical) to 5 (most critical). In terms of
correlations of roles, after a strong comparison between
the roles we decided that several roles in combination
will increase the criticality rank and because of that we
developed a simple logic that correlates the roles and
generates the criticality score based on the roles that are
automatically provisioned in the application based on the
job title and on the others applications provisioned for
that job title.
If the user request a specific role in one application,
the ranking algorithm computes the criticality score and
based on this one an approval workflow is triggered – if
the score is behind 3 the requester manager and the
requested application owner approve and if the score is
above 3 additional approval step is performed and it is
assigned to one member of audit team.
Also we implemented access policies – both positive
and negative – meaning that, depending on his job title,
several roles were automatically granted to the user, but
also the incompatible roles from segregation of duties
perspective were denied. This means that the user will not
be able to request the specified roles and the only way he
could have them provisioned would be if his manager
requests on behalf on him. In this last case, the first level
of approval is the application owner and the second one is
one member of audit team.
In order to ensure that an employee doesn’t have too
many critical roles associated with it, we used several
techniques that monitor user’s activity in terms of
exception role requests:
 Each manager receives on a monthly bases a
report that presents the situation of the users
under his supervision additional roles in
applications (additional roles refer to the roles
that are not automatically provisioned based on
job title).
 Each manager receives yearly a certification
requests that reports the existing roles in the
application for all his direct reports and ask the
manager to take an action for each one these
roles: either to attest, to reject or to delegate the
attestation.
roles in the business context and they can provide either big
improvement in business processes which leads to increase
of profitability, either big losses through fraud or cyber
attacks.
Our approach aims to sanitize the existing environment
from un-useful and us-secured roles and to standardize the
role provisioning process in order to automate it. We
managed to clean the roles in the applications in scope
making them more reliable on everyday business
workflows. Also we decreased the number of service desk
tickets with 30% because of the automatic provisioning
ensuring a stable system that will no longer be vulnerable
on human errors or intended malicious actions.
From the audit perspective we managed to offer a real
and transparent picture of the environments ensuring that all
the certification actions are taken based on correlated and
complete data.
REFERENCES
[1] Role-Based Access Controls - David F. Ferraiolo and D. Richard
Kuhn
[2] Role-Based Access Control Models Ravi S. Sandhu Edward J.
Coyne Hal L. Feinstein and Charles E. Youman
[3] http://isacahi.org/downloads/Deloitte_SOD.pdf
[4] Defining Strategies and Roles - A. Scott DuPree and David
Winder with Cristina Parnetti, Chandni Prasad and Shari Turitz
[5] Segregation of duties - Governance, Risk and Compliance Starter
Pack;
http://www.pwc.com/en_SG/sg/advisory/assets/GRC2009QuickSt
art.pdf
[6] http://docs.oracle.com/cd/E21764_01/doc.1111/e14309/segduties.
htm
[7] http://docs.oracle.com/cd/E24179_01/doc.1111/e23369/oiaidentity
certs.html
[8] http://www.openiam.com/products/access-manager/features/rbac/
[9] http://www.auditbots.com/sox-sap-audit-solution/

These two types of activities were meant to prepare

the company compliance from the security audit
perspective and to give to the management chain a more
accurate image about the real situations in the target
systems.
In order to be able to propagate this approach in as-is
context we used the certification process that generates a
comparison between what roles should a user have
according to the new role access matrix and what does he
really have in the system. All the requests for certification
were sent to each manager and we used notification to
inform the user about the new legitimate accesses.

SUMMARY AND CONCLUSIONS

Nowadays most of enterprise applications implement
the RBAC model in order to ensure compliance and
efficiency in executing business workflows. Because of
this, the application roles play one of the most important
 APPENDIX 1
Role Management Process Flow

Start
System
HRSystem

Analyze Job
Titles
HR

Generate Role
Access Matrix
Systems

Analyze
TargetSystems

Application
Roles

Define
Target

discriminators,
differentiators,
duplicates
and containers
management
management
system
system

Generate
Role

Decommission Apply new Implement

Role

criticality Implement
and Update Roles on Role Segregation of End
ranking Certification
Roles Access Matrix Duties
algorithm

Figure 3. Role Cleansing Process