Recently I’ve been thinking about
what happens to an identity through its life cycle and how the identity data is
treated during this process. I think you
will also see that the Enterprise itself has differing methods of dealing with
it as well. I am considering this to be the beginning of a framework and
nomenclature that one can use for expressing how people relate to their
Identity data on a number of different levels. I think we can pretty much
consider this to be a “work in progress,” and I would greatly appreciate
feedback.
So why do we need this, anyway? I
have observed that organizations, consulting groups, and other industry experts
relate to Identity based information. It seems that we all have our own set of
assumptions about what is supposed to happen to this information based on our
roles and responsibilities and that such a framework will help to organize our
thinking a little better.
First off we have what I refer to as
the Pre-Identity. During this time
the data that will become the identity is in its most undefined form. Data in
this stage might sit in a number of different silos or systems before moving on
but is mostly used by Employment and HCM systems. Typically this data has some
form in that it can identify and maybe even describe an individual in terms of
the Enterprise, but it does not say anything about what it can actually
do. At this stage there are no
entitlements that are associated with the user. The primary relationships held
by this data are mostly legal ones as this data is used to connect with
government and other systems to prove data on a legal / governmental level,
such as the IRS, Department of Motor Vehicles, etc.
Once we have connected the data and
accepted it into the Enterprise, the Identity information moves out of
Pre-Identity systems into what I refer to as Dynamic Identity. This is the phase of Identity Management that
most of us work with full time. We will
analyze this data, transform, populate (and de-populate) it in our Enterprise
systems. This is also the time that we will grant, modify and revoke
entitlements and apply that extra “dimension” that did not exist in the
Pre-Identity stage. As the relationship between people, their Enterprise
Identity and their organization(s) change, so will the Dynamic Identity.
Systems and Processes will constantly be changing based on the need for access
based on geography, roles, titles, responsibilities and other enterprise
requirements.
Happening mostly at the same time as
Dynamic Identity is that of Interrogative
Identity. This stage of Identity
encompasses some of the latest trends in the field of Identity Management. As
there is an increasing need to clarify, document and ultimately define what an
Identity has access to and ensure that the Identity is compliant with internal
enterprise rules (governance) and governmental rules (compliance) it is
essential that there is a defined set of processes that enable this to occur.
There are now several sets of guidance on these practices established by
governments and standards bodies and a growing set of application vendors to
help navigate their processes.
As another dimension of
Interrogative Identity, there is the constant need by the Enterprise to
understand its own data. Access to data through Enterprise Systems and linking
the elements of Pre-, Dynamic and even Interrogative Identities is increasingly
being managed by Business Intelligence (BI) systems. Our understanding of how the Identity and
Enterprise are connected is being enhanced as BI is extended into Identity
models. This trend will only continue to grow; however its management through
will need to be maintained and monitored by Dynamic and Interrogative systems
to ensure that Identity and Access data is properly protected.
Finally, we must define what happens
when an Identity is no longer associated with the Enterprise. The Post Identity phase is one that is
often overlooked, and is the cause of many exploits and Identity Management
related crises. Ensuring that there are ways to properly separate the user from
the Enterprise systems while maintaining their existence for ongoing
Interrogative Identity practices is required properly complete Dynamic Identity
operations.
Throughout this article I have made
references to “the Identity” without going into much detail. This is done this on purpose so that there
are no preconceptions as to what can be managed by this model. Any type of
Enterprise object could be managed in this framework, whether it is people,
groups, roles, privileges or other objects such as systems, phones and other
hardware, and the relationships therein.
I have also been somewhat vague
about what constitutes the Enterprise.
For far too long, the field of Identity Management has been confined to
the Corporate Enterprise. However with ongoing initiatives to “Cloud” and
“Service” based systems, there is a greater need to manage and monitor these
relationships as one would in a Corporation or Government system. Our
increasing reliance on systems such as Google, Facebook, LinkedIn, Yahoo!, etc.
to store our data and provide next generation service such as Federated access
makes this all the more essential.
This does not mean that non-cloud
methods and repositories do not benefit from this type of organization. These
relationships are just as important when considering ERP, LDAP and other
"classic" Enterprise systems as I have referenced earlier in this
article. The organization of this data is
still among the leading determinants in the choice of both ERP and Identity
Management systems. It is my hope that in defining and expanding this framework
in terms of Pre-, Dynamic, Interrogative and Post Identity stages (PDIP) that
we can find a way to address all types of Identities in all possible systems.
There has been quite a bit of discussion about the potential futures of SAP IDM and SAP GRC. SAP has just started a survey so that they can get customer input. I would encourage all customers using or considering these products to take the poll.
So how should this be addressed? I think through either a tighter integration that is more direct and thicker, that is one where more information is passed, so that IDM becomes the "face" of GRC allowing for mitigation and remediation activities. However I do not know that the current SAP architecture really supports this. therefore I think it makes more sense for IDM to "consume" GRC and make the GRC functionality part of IDM.
IDM already has a very basic concept of Segregation of Duties through Role Mutual Exclusion functionality. Having logic that determines what should be "Mutually Excluded" from GRC type functionality makes sense.
