Wednesday Dec 16, 2009

Never Use Emails As A Unique Identifier

This blog could just be the title and thats it. Nuff said.

One recurring major mistake I see over and over again is the use of email as a way to track unique user accounts.

Seems like a good idea.  When a new user is created, email is usually one of the first accounts they get provisioned. The email string is unique to the user, so why not use it as a way to identify user accounts across all systems? Its almost always a data element in the LDAP directory, so its available across the network for any user looking to authenticate a user.   Next thing you know, the ERP system uses it to track user accounts, the healthcare web site uses it, etc.

So what's the big deal?

The problem is two fold. First, by using a user's email account name, you are compromising the overall security of your domain.  Give me your business card and I already have one half of your login sequence.  Email account names are easy to guess, leaving one only to work out the password to gain access to many corporate systems.

And secondly, email account names may not be permanent.  Names change when one gets married. Users may want mail aliases to use nicknames or variations. Or even bigger (and this one hits close to home at this current time), the name of the mail domain may change.   If and when Sun gets acquired, everyone employee of Sun will most likely get a mail account in the domain. becomes  All audit trails become much more complex because you have to track across muliple UserID's to recreate a user's access.

So what is recommended?  An employee number, preferably greater than six digits. Most HR systems assign each employee a unique number.  The number is usually not easily known.  And its stays the same when the employee gets married or changes their name.  And it stays with the employee forever, even if they leave and then return later.  Add a few letters as well, say initials, would help insure uniqueness across all identity domains.

Thursday Dec 10, 2009

Agent Smith, SOD....

So lets start talking about current identity issues.

Good evening, MR. Anderson.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 complexity.

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 monitoring.

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.

Monday Dec 07, 2009

Identity Crisis is Back Online

Identity Crisis is back on line with some changes.[Read More]

Sean ONeill


« December 2009 »