So lets start talking about current identity issues.
The first that comes to mind is the us of Agent Smith, SOD (from the Separation of Duty Services Department).
Several months ago, there was a discussion about building "persona" on the web by
my colleague Mark Dixon. This was as the rising tide of social
networking was rising. Similar to a user account, which is prevalent
inside the corporate firewall, the persona was instantiation of a
user's , being across the web. Its "what you project you are" through
your online presence, represented by the intersection of your different
entities on the web.
So this got my attention. Not only are we the sum of our user
accounts on emails, Blogs, Facebook, YouTube, Twitter, etc., but what
we do with them. And most interesting is we can be what we choose to
be. We can be what we are in person or we can "avatar" up our image to
be what we want to project. Any online gamer knows "ColBiggles"
probably doesn't have any military experience. But I can follow his
progress, listen to his rants, read his prognostications and even talk
directly to his disembodied voice without ever really knowing who or
what is really driving the online persona.
This led me to think of Agent Smith from the Matrix movies, a rogue
computer program that become sentient and keeps growing in power in the
Matrix, learning and adding to his capabilities. Eventually, he becomes
enemies with both the human and machine worlds.
So why bring this up in a blog about identities. Because this idea
of persona can be used to help implement one of the hardest of identity
projects, Separation of Duties. SOD policies are usually simple to
dream up, but a devil to implement.
The idea is no one user should have certain combinations of
attributes that allows that one user the ability to commit fraud or
damage. The classic case is the ability to create a vendor in the
accounts payable system and release payments to that vendor. Else, my
cousin may suddenly find himself being sent sizeable checks to his
fictious company to cash and enjoy.
Okay, simple. Set an SOD policy that says one user, regardless of how they acquired the abilities (via assignment or roles), cannot
have that particular combination of entitlements or at least it is
recorded as a exception for the auditors. Its fairly simple to do if
the accounts payable system is the same enterprise system that releases
the checks. But many times, SOD conflicts can occur accross systems.
The problem is trying to figure out if an enterprise has the correct
SOD policies and monitoring in place. Imagine having to monitor a
major bank IT operation of 8,000 different systems, 100,000's of
entitlements across those systems. First is the daunting task of
thinking of all the combinations of SOD entitlements and then building
in the rules/policies into the provisioning, role management, and
compliance systems to test and find these rogue users. Just standing
it up the first time could be a career. And as entitlement management
becomes more prevalent, this will only grow in significance and
And then remember that identity domains in the enterprise are
amorphous. They are constantly changing. Users are coming and going,
changing jobs, and the dreaded SOD scenario of transfer between
business units (often requires them to have overlapping SOD
capabilities until the transition is complete). New businesses are
acquired, new systems are brought on line. Local admins add
capabilities on the fly without seeing the bigger security picture
Often, an SOD conflict is only discovered after the fact, after the
venerability has been exploited.
And once the SOD fabric has been laid onto the identity topology of
the enterprise, how do you test it. How can you be sure your systems
are working? Most identity suites, including ours, have SOD monitoring
in their compliance packages, not in their provisioning engines. So
there is a built in lag where a user can gain SOD violation status and
not be detected for a cycle when the compliance review is run.
Also, testing in production is tough to do. In staging, you can
create an SOD situation for a user and test to see if the violation is
flagged. But in production, if you create a SOD test on a production
system, particularly on a SOX or HIPPA controled system, it becomes an auditing event. The
security and audit teams will be notified and someone will have to
remediate the condition. Up go the incident levels on your dashboards
and everyone gets involved.
And lastly, even if everything is up and running 100%, how do you
monitor if delegated administrators are doing their job during
compliance reviews? The weakest link in any security system is the
human factor. Had a situation recently dealing with a contracting
manager who ran the third party bench of contractors. In the identity
system, she had 384 direct reports with access to a variety of
entitlements across the enterprise. For certification reviews, she
had no idea, would do a "select all" and approve.
So how to test accross the production environment without sending up
SOD violations to answer for? This is where Agent Smith comes in.
Create a rogue user persona, a la Agent Smith, that everyone is aware
of and knows is a non-existant user of the company's systems. Actually
create this user account downstream of your HR system (the company
would not want to fund healthcare or stock benefits to a non-existant
employee) and use that one user account to test your controls and
As new SOD policies are enacted, try and see if your Agent Smith can
attain an entitlement status that triggers the monitoring policy. If
the violation is triggered, security and auditing will realize, from
seeing the Agent Smith persona as the violator, that it is a test
account and will not raise an official violtion instance.
Also encourage delegated administrators to try and utilize the Agent
Smith persona to improve its capabilities and entitlements. Have them
have Agent Smith request access to systems they should not to see if
the human approvers are doing their job. Anyone looing down the list
of user entitlements should be able to pick out First Name: Agent, Last
Name: Smith and deny them certification.
Granted Agent Smith, if properly treated as a real person, will
consume real resources. They will get issued a laptop or email account,
they will consume an ERP seat license, a MS Office allocation, etc.
This could run into several thousands of dollars (what you would spend
on a real human), but this is a small cost compared to an SOD
violation. Well worth the investment.
And yes, you will have system admins, security, and auditing teams
complaining about having a ficticious persona within their systems.
But they will have to understand that for the good of the SOD review at
an enterprise level, it is the only way to be sure.
But be forewarned. Just like the Agent Smith in the Matrix movies,
it can take on a dangerous life of its own. Most SOD policies involve
powerful entitlements and a malicious person could assume the Agent
Smith persona (this is different from the movies where the Agent
assimilated humans) and actually commit fraud using his capabilities.
So, if you choose to unleash an Agent Smith, insure accees to that
account is considered root level enterprise status. Only a few should
have access to the login and insure the password is religiously reset
on at a minimum a weekly basis. Be sure to test deactivating the good
agent regularly and be ready to morph that one account at least once a
year into Agent Jones or whatever to insure the good agent hasn't "gone
rogue" within your enterprise systems.