Looking Past Governance

The next frontier of identity

So you have managed to conquer the world of governance and provisioning. Congratulations! You have increased visibility into what access users have and shortened the on boarding process from weeks to minutes. Your work here is done, right? Wrong. Lucky for you the work of an IAM professional is never done. The security world is full of data breaches and vulnerabilities, and we are well aware of the insider threat, so while you are off to a good start, you have to start looking at extending the reach of your IAM solution. However, where could I possibly go next you ask? Well, what kind of expert would I be if I didn’t have the answer?

Data Access Governance

Your first stop on your path to IAM dominance is a little place we call Data Access Governance ( DAG). It’s the technical term for all the file shares, SharePoint sites, presentations, and other files that are most likely dispersed throughout your organization.


Those files contain everything from corporate financial information to competitive analysis documents, to your CFO’s super secret chocolate chip cookie recipe, so you probably want some controls around them. We will start with the basics: who can access those files, and should they be accessing them? Since we’ve already won half the battle by putting our governance solution in place we have a pretty good idea of who has what access, now by extending our governance model out into the DAG world, we can start to answer the first question of what they have access to We accomplish this by using the identity context from our IAM solution to augment the information we’ll pull back from our DAG toolsets. This information will usually consist of audit type data that lets us know what files are being accessed and how they are being accessed. Let’s give an example to make things a little clearer. Using our DAG tool we see that the file named “AllImportantFinancialData.xls” is accessed by the group CFO-members. Awesome! Now let’s check our IAM solution and see how many users have access to the CFO-members group. Hopefully, it should return all members of the CFO organization, but for the sake of argument let’s say it does not. In fact, we find two users; we will call them John and Jane, are members of the CFO-members group but not a part of the CFO organization. Now, this may not be an issue because maybe John and Jane have been authorized by members of the CFO organization to be in that group and have access to that file. However it’s the inverse of this statement that proves the value add for extending your IAM solution: John and Jane have been authorized to have the group, but not access to the file, because users were not aware of the correlation between access to the group and access to the file. So by extending your governance solution to work with DAG products you begin to give your users deeper insight into the what access is really being granted, and allow for richer policies and process to be developed around managing that access.

Security Information and Event Management


All right, so the next stop on our journey is to the wonderful world of Security Information and Event Management, otherwise known as SIEM ( pronounced “seem”). Why do I care about this, you ask? This is your connection to everything else IT, as most SIEM products sit across applications, devices, network equipment, etc., and collect log and audit information for these items. In addition to collection, they provide correlation and intelligence about events across those products, allowing you to detect anomalies in user activity in near real time. So we have our IAM solution on hand providing a comprehensive view of identities and their access, monitoring and our SIEMmonitoring user activity across applications and devices alerting us of any odd behavior. Seems like a good place to extend our governance model right? By providing identity context to our SIEM solution we can get similar results to that of our DAG-IAM integration, in that we allow our SIEM solution to provide better correlation between events and identities. This allows us to see that user login jdoe is showings some suspicious activity on application A, and because of our identity context we know jdoe to be John Doe, additionally we know that John Doe has access to several other high privileged accounts. With this added information we can raise the risk profile of this activity significantly and, if we so choose, take automated action by talking back to our governance platform and disabling John Doe’s accounts.


Identity has quickly become an important pillar in the foundation of a solid security infrastructure. Data breaches are becoming front page news and happening more and more each year, the ability to know who has access to what and what they are doing with that access has become paramount to every security professional as well as the IAM professional. So dust off that project plan, and get the team back together because have still got a lot of work to do.

David LeeIAM