User access profiling model

June 2017
USER ACCESS PROFILING MODEL
DATA PROTECTION
JOSE GUERRERO, MS
CISSP
For Comments and Collaboration: https://www.linkedin.com/in/jose-guerrero-aa16a01

User Access Profiling Model
Executive Summary
This document presents a practical model for documenting, supporting, designing and
implementing access profiles of various types to cover all sorts of information assets within an
organization. What User Access Profile means for the sake of this document is simply the configuration of
a user directory, database security access module or any other application or software access module,
that allows an end user, like an employee, access by means of an interactive or batch process, to the
information or function is looking for on the organization’s computer network.
User Access Profiles is typically how Authorization is handled within most organizations’
technology platforms. Once an employee, or more generally speaking a user, is authenticated against the
network and/or application and so on, that user is given authorization to access certain functions, network
resources and information within the network through the configuration of a certain number and types
of User Access Profiles.
The different types of information assets and the even more number of technologies there are to
get to them, represents an overwhelming security challenge for most organizations. This document
stablishes what you will require and how you can make this model work, to efficiently overcome this
challenge.
Authorization to the Data.
Proliferation
The Data is and has always been the most valuable asset that technology dependent company
have, and which company now doesn´t have a level of dependency from technology? But in the beginning
things were easier for a company that wanted to protect its data. Probably had one or a couple of servers
with few applications and their own data each, so each individual peace of data you’ll find in no more than
one or couple of places.
To define and implement controls around the data was simple enough in those days. Yet, now we
have a whole different situation, after applications interfaces, file servers, file sharing, data bases, ETLs,
etc. the same individual data is everywhere. It’s so much the case that data integrity and consistency is a
difficult issue to tackle, and also just knowing where the data is sitting at, is in itself a challenge.
Now, because there is no going back when we talk about data proliferation, it’ll get even more
complicated when we consider Cloud Computing and Mobility, solutions and controls that will be capable
of protecting the data where it stands, based on the data and not the action or function, is a must.

Application Access
Your organization most likely started out with just a few main and most critical applications. As
time passes by, new needs and more people come up which demand new applications or new uses of the
same applications. As this goes on for a while, you now have hundreds or thousands of applications with
an even much greater amount of users accessing them, which need to be authorized to access certain
functions so they can do their jobs. And the company keeps growing.
So the one day you realize all these applications are filled with tons of data everywhere, the first
issue that you find is that almost all applications are designed to manage authorization by using access
profiles that are defined based on a group of functions. Functions that are required to be executed and
used by the users to run the company. So what is wrong with that? Well, if access is based on application
functions, how do you make sure that all confidential data is accessed only by the users who are really
authorized to see it, process it or use it? Well, you don’t, not through these applications at least.
Unless you have an application that is capable of handling a cross matrix access profile with
functions on one side and data on the other, which most applications won’t, then you will have no luck
with achieving data access protection through the application. Even if you have a few applications that do
incorporate some level of data field access control, how many applications are these, out of your whole
application inventory? How many fields can those applications protect? Is it only SSN and PAN, because
of regulatory obligations? Are these all the PII or data fields in your applications that you should protect?
You will certainly need a bigger coverage.
Data Analysis Software
Then, on another hand, there is all this new technology coming into your organization that is great
for power users, because it gives them flexibility and processing power, but that has even less capabilities
in regards of an access profile definition based on data field access control. Technologies and concepts
like Business Intelligence, Data Mining, Data Warehouse, Data Analysis, have gotten great positive impact
to organizations’ growth, but if their security and access is not handled carefully, it can become the
greatest security liability for the organization as well.
Now all of these technologies are great at data analysis on a large scale, but the question remains
if you can rely on them to authorize data field level access? These technologies and software are business
driven, and therefore putting a lot of data, with an easy handle, to the hands of business users, is what
they are designed to do. So data field access control within these software is a one by one task, out of
hundreds of thousands or millions of tasks, in a way that when you are done, you will still have to start
over again because you are already outdated. Something that is even worse, is the disruption of business
while doing all these security tasks to control access at the data field level.
Maybe applications and data analysis technologies, including the databases themselves, are not
built to take care of information security issues. Maybe they were created to do something else, help the
business men to analyze the customer base for example, even now they continue their evolution to be
better at what they are designed to do. I can agree with that! Maybe they wouldn’t be good at secure
data access, even if they tried, because is not why those applications and technologies exist, is not their
purpose. I can agree with that too! One needs to focus in order to excel in a competitive world. So then

the question is, can you wait for the applications and data analysis technologies to cover your information
security needs?
Network Resources
Then there is also the need for using certain network services and technical personnel need
powerful access to the technology platform in order to maintain it. How is their authorization level being
controlled and managed? As with the other cases, how can you provide data level access profiles to these
powerful users? Used to be that the amount of users that fall into this category where of a manageable
size, but how many users, insourced and outsourced, are in your organization these days under the
Technology role alone?
A Database administrator need to access and manage the database to do his job. What about the
operating system administrator, is he also a DBA? But do they need access to the data on the Database to
do his job? But the real question now is, can you manage, from a single point, an organization’s wide
access profile for DBAs and SysAdmins, where specific data, from any database, of any kind, will be out of
reach for these roles? Or are we still depending and counting on the technology that is designed to do
something else, rather than information security?
So maybe you are thinking to yourself, as you read along; “we trust our administrators”, “we make
them sign NDAs”, “we have to trust someone”, “it´s always been like this”… These are all paradigms from
the past, when no other solutions where available, but just to accept the risk or treat it with corrective
controls, instead of preventive ones. Of course, to accept the risk, or use corrective controls (legal
amongst others), is always an option, and if based on your risk assessment, the result is to treat this risk
that way, then you should, and all accountable C-Level should be in agreement.
This paper is suggesting a preventive and more effective approach to managing this risk, that your
risk assessment should consider. Because, like with all other matters of security, commonly is not until we
have something bad enough happen to our assets, that we do something to prevent it… the next time… if
there is a next time. On the other hand, regulators and auditors, or compliance in general, might be driving
your business to mitigate this risk in a preventive way, given reported incidents worldwide.
Cloud Computing
Computing in the cloud has brought new challenges for information security specially data
protection. While the adoption of Cloud Computing is ever increasing, some Cloud Service Providers are
doing more to offer a secure service than others.
So we as security professionals are faced with the issues as described above, but with the Cloud
Computing, more dispersion of the data, now within third party infrastructure or control, more
administrators with potential access to your data, administrators now from third parties, applications with
security functions out of your reach or under a third party control.
In short, Cloud Computing brings more challenges to this matter and a solid, stable and flexible
model is needed to undergo these challenges together with all the rest described above. Yet, in terms of

how to create a user access profiling scheme, the same basics apply to Cloud applications or deployment.
You will have to manage application profiles to access application functions, data profiles direct access
data and technical profiles for management functions, at least in an IaaS implementation for sure. So keep
this in when you read through.
It’s a different matter if we want to talk about protecting the data from unauthorized use in the
Cloud environment, rather than the security of accessing the data for authorized use. Protecting the data
in a Cloud environment is a topic out of the scope for this document, but I will talk about it in a future
paper.
The Model
The first thing to say is that this model relies on identities and roles. The way I define this two
terms for the purpose of this document is as follow: Identity is a one to one representation to a person,
or within an organization, an employee. So the identity can have several user ids associated with it, one
user id per system, software or application, they all relate to one identity which uniquely reference the
person. So a person or employee could have several user ids, depending on the number of systems he has
access to, but on the other hand every person or employee has only one identity with the organization,
which identifies only that person or employee.
A role is usually a one to one representation of the title or position an employee has within the
organization. Although is also possible to see several roles assigned to a person or employee in certain
use cases. So the user id might have a user profile, or group profile, assigned within a certain system,
software or application. But the same is true for each profile, its reach is limited to that one system,
software or application. So a higher level concept should be used to assign the identity, which will
reference all its profiles within any system, software or application. So a role is assigned to an identity and
will include all profiles for all systems, software or application that the identity have access to through all
its user ids. If the identity should have several roles assigned to it, then the aggregated authorizations of
all assigned roles should be given to that identity.
An important remark is that while the user id and profiles are system, software or application
wide concepts, the identities and roles are organization or corporate wide concepts, and therefore applies
to all the technological infrastructure within the organization.

These concepts are depicted in the following diagram:
Application Profile (AP)
This type of profile is the typical setup we see in most applications now a days, where a set of
application functions for a certain application are grouped into an AP. So then, when the AP is assigned to
a user within the application, that user is authorized to execute or use the applications functions within
that profile. There could be several terms for this concept, when it comes to a specific application; group
profile, user group, etc.
So the AP is created or defined on a system wide basis, meaning that the profile is only good for
that one application where it is defined and that it has to be defined per application, so each application
will have its own set of profiles. It can also be created on a role based scheme, meaning that profiles
correspond to specific roles within the organization and so the reference is clear and well documented,
which is what it´s recommended for years now.
So these APs are assigned by application functions, the more functions an application might have,
the more APs might be necessary to define. Also the more type of users need to use the application, the
more profiles might also be needed to appropriately segregate their authorizations within the application.
Also, these APs will usually need to be managed within the application itself. Sometimes the application
will support an integration with an Authorization or Access Manager solution, or even a Network
Operating System or Directory Server software, where the APs themselves are managed with that external
software to the application.
Most importantly, the configuration, definition and maintenance of the AP respond specifically to
business needs. So based on the needs of a particular individual within an organization, to allow him to
do his job, he will need to be assigned to a certain AP. Otherwise, that individual might not be able to do
his job the way is expected of him.
For example; a teller within a bank´s branch will need access to the withdrawal function within
the core banking system, where the savings accounts are handled. This is so that the teller can properly
process a withdrawal request for a customer. This means that one of the profiles that includes

authorization for this function, will have to be assigned to this teller, so he or she can have access to that
function, and therefore be able to service the customer.
Data Access Profile (DAP)
This type of profiles might be recent to some organizations. It refers to the authorization to access
certain groups of data; for example tables within a database, or database within a database server. So a
specific employee might need access to the master customer table, amongst others, in order to do direct
analysis on the customer base. This kind of employee might need to do some form of Data Mining to the
data and they will use special tools and software for that matter, capabilities that are not inherently
present on the applications the data is stored in. The analysis of all these data will result in very useful
information for decision making of the management team.
These profiles are used on a system wide level, meaning that the profiles are created on a specific
software or system, so that the scope of its definition stays within that software or system. Sometimes,
these profiles are defined within the Database engines themselves, so that the user will access the
database directly with the tool of his choice, take the data and process it within another software. Other
times the software might be server based, like a Business Intelligence software, and the data will go from
the database to that software repository, for Big Data processing like in a Data Warehouse. In this case
the DAP might end up being defined within the BI, Big Data or Data Warehouse software.
In this model, a DAP is set based on business needs. So there are positions within most
organizations where their job is to process data, to understand the business through the data, to do data
mining, to extract key information from their customer base, on a regular basis, because it pays to have
this key information and be able to act on it on time. These employees´ needs come in the form of a set
of data, most likely corresponding to certain applications, or sometimes not. But the truth is that the
employee will need direct access to a big enough set of data, hence a table, database, etc. Otherwise, the
analyst won´t be able to do his job, or will be limited when doing it, not being able to produce the right
information for management to use.
Now these kind of software are designed to work with huge amounts of data at the same time,
process it and give results in a timely matter. This is true for database engines as well as BI, Data Mining
and all other software dedicated to that purpose. So is virtually painful to try and define profiles on a field
level for authorizations on these software, also considering that users with the same profiles to access the
same data sets, might have different needs to access specific fields. Efforts will also be multiplied when
there are various kinds of software like this being used within the organization; BI, Data Mining, Big Data,
Data Warehouse and Database Engines of different brands. In addition, regardless of the different kinds
of software being used and instances of these software, a field level access will have to be setup on each
of the instances and/or kinds of software being used, even though they could be repeatable setups. Field
level access profiles for these employees, through these software, will cause great productivity issues for
them and great burden to the access management and help desk teams, is simply unmanageable and a
path that is destined to fail for security, on any medium size or greater organization.
A simple example; the Market Analytics Team will need access to the master customer table, all
product based tables and all transactions tables, at least, to do its job. They will process all this data,

generate results that will allow the organization to segment all customers, based on the profitability for
the organization. This is in order to focus market efforts and budget, to create specific marketing
campaigns targeting specific customer segments. Therefore increasing marketing return on investments.
A DAP can be set on the databases holding these tables, so it can be assigned to the Market Analytics
Team and they have access to all the data needed using the software of their choice. Better yet, a DAP
can be setup on a BI Software for the Market Analytics Team to access and process the data, if such
software exists within the organization.
Lastly on DAPs, is recommended to standardize the place or software where these profiles are
managed all around the organization. If there is a BI or Data Warehouse, that should be the first choice to
manage DAPs. This is important to avoid access or profile collisions. If for example DAPs are setup within
a BI, and also DAPs are setup directly within the same database that the BI is connected to, then collisions
should be easy and common to come by. Also DAPs should apply to a limited amount of super users, since
the majority of the users should be happy with using the application. So both the amount of users of DAPs
and the number of active DAPs within the organization should be limited based on bulked data and
manageable through a centralized standardized software or console.
Technical Profile (TP)
Almost all employees within an organization will need some form of access to at least some form
of computer network resource. One of the most commonly used network resources is email. Like email,
you can have Internet access, USB access, VPN or remote access, amongst other network resources. In
order to manage authorizations to the use of these resources you will need a TP to be defined and
managed. Also including, in a more granular level, the way in which these resources are used, for some of
them. Email for example, you could have profiles that will allow an employee access to internal email, but
not to be able to communicate outside the organization. Or Internet Access for example, one profile to
let an employee access social networks, while others won´t be needing this access to do their jobs.
TPs are also the types of profiles used to define operating system wide administrators and
operators, as well as database administrators (DBAs) and other server side software outside the realm of
business applications, like Web Servers. So you can manage TPs within the different operating systems to
define authorization for administrators to do major updates and other tasks, system operators to execute
backup and maintenance tasks, system monitors to collect performance data, monitor services and
resources, and much more.
These profiles are defined system wide, meaning they are configured within a system and the
scope of this definition will stay within that system. A Network Based Operating System or User Directory
Software are the usual places to find these profiles setup, for the network resources management. As well
as the Operating System itself for other types of authorizations within that system. With either Operating
System, these profiles can be setup using different terms, like Security Groups for example.
The setup of TPs are also driven by Business needs. So certain employees need access to Email
and the Internet in order to do their work, for innumerable reasons like internal and external
communications, research, analysis, investigation, information search, running specific tasks, etc. In the
same way business needs a technology team to maintain and resolve issues within the technology

platform, TPs should be setup to meet those needs, like for database administrators, system operators
and administrators, and so on.
For example; a service representative within the organization is responsible for serving the
customer. Most customers today prefer to communicate through email since is a cost effective, easy,
commonly used and written way of communication. Although for certain services other communication
mediums will be preferred, like chat, phone or web browser, email still is the method of choice for certain
communications and services. So a service representative will need access to external email in order to
serve any customer this way. But then other employees might only need internal email access. TPs can be
defined to assign and manage these two different set of authorizations within the organization.
User Level Access Profile (ULAP)
Every employee within an organization with any type of access to an application, database or data
storage software has access to a certain amount of data. It could be a lot of different data fields, or just a
certain amount of data fields within different applications or software. All of these access authorizations
are business driven and are given based on application functions (AP), data groups or tables (DAP) or
network and system resources (TP), and this is the way it should be so business can be dynamic enough
and set appropriate authorizations for all job roles that exists. If data security is forced within these
authorization processes, where business is key, dynamic and is the main driver for these processes to
exist, then security is going to slow down these business processes, impacting on the agility and fast
adaptation of the organization. But also, data security will fail.
But there is a better way for achieving data level security authorization. ULAPs are defined based
on data classification, user trust level and roles. These profiles are composed of specific Data Types and
the level of access that is allowed; either Original, Masked or Prohibited. Other levels of access could be
defined as well, like Scrambled, but these three should be the minimum to use. So you can define a ULAP
with specifications for certain Data Types and their authorization levels, in compliance with their Data
Classifications, to be assigned to the users or roles with the corresponding trust level. A default ULAP
should exist so that any Data Type classified as Confidential would be Masked or Prohibited.
ULAPs are set corporate wide, meaning that they will apply across the whole technological
infrastructure and their scope cover the whole organization. They have to be defined within a software
that can reach the whole technological platform; databases, data storage, applications, etc. They also have
to apply and be enforced as close to the data as possible, in order to be effective. This software will also
need to enforce the ULAP rules over any other authorization profile, of any type. This is the way you make
sure the data will only get to the authorize personnel, no matter all other authorization the employee has
or need to have, based on application functions, data groups or network and system resources.
ULAPs, rather than the other types of profiles, is security and compliance driven. So they are
defined based on security policies as well as compliance requirements. By applying these authorization
rules through ULAPs, the organization will ease their way to compliance. At the same time, security
policies are met and the security for the most precious asset on the organization, the data, will be greatly
increased, reducing the risks and costs of Data Compromise. This is the only corporate wide profile and

therefore should take priority over the other profiles in any case, although no conflict is foreseen since
the profiles actually complement each other and work in their own aspects of access management.
You might have certain data types in your organization with the need to protect them, or if you
have to comply with any of the security regulations or standard, other data types might have this need as
well. An example would be the need to comply with PCI-DSS, where the Credit Card Number or Primary
Account Number (PAN), needs to be treated and protected as confidential. Yet, there will certainly be
personnel within the company that will need to have access to the PAN in order to do his job, while the
rest of the employees might get away without it. This would be a typical scenario to the needs of most
Confidential information in your organization. Of course there might be other Data Classifications within
your organization security policies, this model will be able to fit any needs of those classifications in
respects of its access management.
So in the example above, you can create a ULAP allowing access to the PAN in its original form,
apply it to the users with the corresponding role to a user level access for confidential information.
Meanwhile the rest of the roles will have restricted access to the same data type, the PAN. Restricted
access is either in a masked form or no access at all. So the users with the correct ULAP will have access
to the PAN no matter where they get it from, while users with other ULAPs or no ULAP won´t have access
to the PAN no matter where they come from; any application, BI software, data warehouse, database,
and without regards to any other profiles (application, data access or technical) they might have assigned
to. So in this example a database administrator that is logged into the database with the highest
authorization level for a TP, won´t be able to access the PAN if he doesn´t have the correct ULAP assigned.
Conditional access can also be applied at this level, based on IP Geolocation for example, which could be
required to meet compliance for some organizations, amongst other use cases.
The same example will apply to any data type you deem confidential within your organization. Of
course, ULAPs can contain different records of data types with specific actions allowed for each. In this
manner, you can set the ULAPs in whichever way you need them, protecting all data types considered
confidential.

Model Diagram
How to make it work
So taking it one step at a time, to set your APs like described in this model, you´ll need to have all
profiles, for all major application, well documented and assigned based on specific roles within the
organization. Only then you´ll have them ready to implement this model. Then you´ll need to do the same
for all DAPs, well documented and assigned based on specific roles. Then the TPs, same documentation
and assignment based on role. For the ULAPs you´ll need the data types that are classified as confidential
or any other level of classification that will require special treatment and access controls. Then, have clear
documentation of the roles that are allowed access to each of these data types and in what format will
they need this access.
Next you will setup all the different profiles in their own environment. For the APs, if you don´t
have them already, set the role based application profiles within each application. The data access role
based profiles, if not yet setup this way, will need to be set in all data storage and processing software
you have; databases, BI software, data warehouse, data mining, etc. Then the technical role based profiles
will be set within network user directory software, network operating system or any other operating
system.
ULAPs will be deployed through a security software, usually supporting different architectural
designs and deployments. Enforcement of ULAPs should be done as close to the data as possible, so then

you set the ULAPs within the security software and as the deployment of this software expands to cover
more applications, systems and software, all ULAPs will be enforced every time covering more and more
of the organization´s technological infrastructure.
Following is a diagram that shows an example of a simple deployment of the model to show how
it works.
What else is needed?
After generating all documentation and system level profile configurations needed, then building
and designing the model for your organization, you will now need the tools, software and technology
necessary to implement and deploy the model.
To set the APs you only need at least the native capabilities of the application, which will allow
you to set user profiles at your convenience. If the application will be able to integrate with an
Authorization Manager Software or delegate authorization assignments to the Network OS, then better
yet, since is more secure and is a centralized management. To set TPs, operating systems, network

operating systems and user directory systems are all you need to allow for profile configurations in the
way is necessary. Then, to set DAPs, it will depend on the technology your organization is using to take
advantage of Big Data. If direct access to databases are given to power users for data analysis, then DAPs
will be defined and managed within the database engine itself. If other software are used, like a BI, data
mining or data warehouse, amongst others, then these software will have the capabilities you need to set
and configure the profiles in accordance of what´s described above.
On the other hand, to be able to define, configure and deploy ULAPs you will need the necessary
security software with the right capabilities. These capabilities can be found in mature Dynamic Data
Masking Software, as a known example. This software should be able to at least accomplish the following:
- Define and manage profiles based on classified data and actions set for each.
- Define data types and ways to treat them based on rules, when encountered.
- Have excellent data discovery capabilities; incorporating several technics and great precision.
- Deploy in different architectures; agent-based or proxy-based, so it can adapt to all use cases, like
customized in-house, cloud based, COTS (Commercial Of The Shelf) applications, and so on.
- Sit as close to the data as possible to act on real-time accesses from anywhere and from whoever.
- Make itself transparent to the applications, software and users accessing the data.
Because implementing this model will have you manage a lot of profiles of different kinds and all
over the technological platform, it will be very easy and frequent to see a lot of mistakes in profile
assignments when all this model is managed manually. So is strongly recommended that if you don’t yet
have one, implement a User Provisioning software to automate the process of provisioning and de-
provisioning all these profiles of different types. Otherwise you should expect a lot of gaps on the security
of your model´s implementation. The User Provisioning software should be flexible enough to be able to
integrate all necessary applications, software, operating systems and security software, also support most
common COTS applications and cloud-based applications, it should be able to automate major and
common processes for access management with the flexibility needed in all your use cases. Require
demonstrations of all this capabilities from the provider.
Another aspect of this proposed model that I want to mention briefly, is the fact that all
components of the model need to be managed. How and by who is going to be managed, depends on
several variables, including the original organizational chart, defined roles, distribution of responsibilities
and functions, internal culture, etc. So just a few notes on this topic, you might now have the following
responsibilities regarding this topic somewhere assigned within the organization: people to define the
Application Profile to users, to configure the AP on the application and finally people to assign the AP to
a number of employees or better yet, to a role, which then is assigned to a number of employees either
manually or automatically. In the best scenario, these three responsibilities (Define, Configure and Assign)
are each assigned to different personnel, so Segregation of Duties protects these processes for Access
Management.
TPs and DAPs should be treated like APs as described in the paragraph above and in regards with
its administration. So each will have their own assignments for TPs and also DAPs, all three responsibilities
in each case; Define, Configure and Assign. Segregation of Duties, as described above, should be around
all processes, as well as access management for DAPs and TPs.

Now, ULAPs should be handled a little differently in some aspects of the administration. The role
based Definition of ULAPs should be done by Infosec or at least be in the approval process. Configure
should be with the personnel that also handles administration for all Infosec solutions, or the same
personnel that configure APs, DAPs and TPs. The same personnel that Assigns the other types of profiles
to users, should be the ones to assign ULAPs to final users, always based on roles rather than per user.
With all requirements, processes, people, the software and technology in your hands, you are on
the path to successfully implement the User Access Profiling Model.
Conclusions
The User Access Profiling Model is the right balance between security and business, bringing
productivity, agility, flexibility to business, in a secure way. This model builds upon RBAC for flexibility,
agility and business alignment. On the other hand uses a mandatory access control to comply with security
and compliance requirements, while at the same time leveraging on the RBAC scheme. All benefits
together for business, productivity, security and compliance is rarely seen, but when you find it, like in the
User Access Profiling Model, it translates in organization’s growth, stability, endurance and success.
For Comments and Colaboration: https://www.linkedin.com/in/jose-guerrero-aa16a01

User access profiling model

More Related Content

What's hot

Similar to User access profiling model

Recently uploaded

User access profiling model