What comes after IDM?

People often ask me what comes after Identity Management? My answer is that it depends.

As I've discussed before, it's really up to what the organization requires and simply tacking on new workflows, approvals, and functionality is only really useful if it will actually be used.  However, I think we can make a few generalizations about what might occur as part of a far reaching and comprehensive IdM program.

Assuming that the initial project succeeded in its goal of creating an authoritative data store and basic provisioning, there's always the goal of adding more applications and additional attributes in existing applications that can be provisioned as part of workflow.

Password management is always popular.  If your application allows password provisioning or linking into a SSO or password management solution, this is a great place to add in further automation.  Your organization's help desk will appreciate it, I'm sure.

Adding in a compliance solution (sometimes referred to a certification or attestation) is always something organizations look into as a part of that overall IdM program. Some applications such as SailPoint IIQ have this built in, while others such as SAP GRC or Oracle Identity Governance are separate, but complementary modules to the Identity Management offering.

However what I think is one of the key places that the IdM program manager should be looking at is automation of IT processes. Every day the Help Desk and the System/Network administrators are using untrackable and un-auditable tools for editing user accounts. IT Management and Audit staff have no idea exactly what these people are doing as they are on the job.  At the very least, there is the possibility that users will be accidentally granted the wrong entitlements, and in the worst case, there could be the creation of undocumented SuperUsers. If we can direct these actions through the user provisioning application, then we can have an audit trail that tells us:

• Who was worked with
• What was done to them
• Who did the work
• When the work happened

It also becomes a lot easier to do these tasks when they are placed in the IdM solution.  This lets our Server Admin and Help Desk teams work on the more detailed analysis and troubleshooting that they were hired for rather than mundane user management, all while creating a more secure and audited environment.

Some quick reads in SAP IDM and IdM in general.

Reporting, Metrics, Audit, whatever you want to call it, relies on being able to extract information from your identity management systems.  This article is a brief discussion on the topic.  I was fortunate to meet one of the authors, Gerlinde, during TechEd last year.

It's also nice to know our market is growing!

2010 and the Year in Identity

As the year draws down, I've been thinking a bit about the year and what's it's meant in Identity Management. There's certainly been a bit of discussion about the nature of Identity, authentication and authorization controls.  As technology, process and legislation grow closer, there's a greater need for Governance and Compliance controls than ever before.  We're also seeing the beginning of the Cloud truly being a part of the IdM solution.

We're also seeing consolidation on the business side in both the product and implementation branches with Oracle, SAP and Microsoft all making purchases.

Related to this, one thing I've been wondering is what will happen with SAP systems if you rely on either CUA or SUN Identity Manager. What are your plans, if any, for migrating off?  I've started a discussion on LinkedIn about this. Please take a moment and  share your thoughts about what you are considering or planning.

On a personal note, I wish all of my readers a happy and healthy New Year.

The meaning of Identity?

I’ve been involved in a number of conversations lately with colleagues and the Identity Commons mailing list about the nature of identity. The fact of the matter is that as far as the Information Technology / Information Security arena is concerned, there truly is no such concept as an identity. Rather what we truly have is a collection of descriptors or “attributes” that when brought together and agreed upon by an organization or group of organizations that describes what we choose to call the identity. Why the vagueness here? Well that’s because an identity can be more than just people, but that’s another story. Regardless, once we have determined what goes into an identity, we can begin to discuss how technology can process it.

The thing that I’m hearing more and more is that just having an identity is not enough. As mentioned previously, the identity is just an agreed on set of descriptors and does not really do anything. So how do we make this happen?

Well it is rather easy when everything is within the same domain. Agreements are easy (well, easier) to make when there is only one organization involved. Once we get outside of the domain, there greater complexity due to meeting the diverse needs of each organization, including (but not limited to) audit requirements, privacy rules, establishing common protocols and, of course, determining a description of what the identity is in the first place.

It’s great that we’re linking in tightly to ERP suites as Oracle and SAP tell us we should do. Leveraging repositories for use in authentication is great as Microsoft says we should do. Federation would be fantastic if we could get folks to come to quick agreements. What we really need is more actions that are associated with what we do with these identities. From what I’m seeing / hearing, there’s not enough being done with the actual identities once we’ve constructed them based on the authoritative sources in the organization’s IT infrastructure.

I think a great example of what can be done is shown in an article in CIO magazine that I saw on Jackson Shaw’s blog the other day.

We talk about these things all the time, but it seems many organizations barely get out of the Authentication / ERP stage since that’s perceived to have more direct impact.
I disagree. Truly actionable items that result in a direct decrease in getting employees functional should be the first effort in any Identity Management project after the data has been cleaned and a definition of what an identity is.

This is an ongoing discussion that’s not going away anytime soon. Not the definition of Identity, not what to do with the Identity, or how to protect the Identity.

Conflicting Views on IdM Acceptance

Within a span of a couple of days I saw an interesting contradiction regarding the adoption rate of Identity related technologies, particularly in Europe. This contradiction came through a couple of articles I found on Identity Management through my trusty Google Search agent.

The first article, basically states that adoption rates have not been as high as they should be since everyone is acknowledging their importance. Additionally the prevalence of cloud technology brings about a new wrinkle in managing Identity which has yet to be properly addressed and might be a way of pushing acceptance of IdM. It also states that the inherent complexity in IdM creates additional acceptance and execution barriers.

The second article, takes a more positive approach to the acceptance of IdM technologies. Particularly when considering Privileged User Management.

Interestingly enough, both articles referenced the same Forrester report, Identity and access management adoption in Europe.

What should we take away from these article?

1. While both articles mentioned that the Cloud could be a great IdM enabler, there was not much mentioned in the way of Architecture models by which this could be addressed. Guess you have to engage Forrester for that information.
2. Looking for IT and IS goals such as Privileged User Management can be a great way to gain additional acceptance for an IdM project.
3. Another issue that the articles do not mention is that acceptance can be promoted by leveraging established ERP application. Both Oracle and SAP now have Identity Management Systems that have specific functionality to provision in their respective internal landscapes as well as to the Enterprise in general. IBM also features similar tools for their infrastructure. Seems to me that along with Privileged User Management as discussed above, this could be another tool to gain IdM project acceptance (and more importantly, budget dollars) Quite a few project proposals I've come across lately are adopting this methodology.

Finally, I'd like to comment on the complexity issue. IdM is made complex when organizations do not execute from an agreed upon game plan. This plan does not need to be all that complex, and briefly consists of the following:

• Understanding the Identity related needs of the organization
• Prioritizing those needs based on potential return which could be based on, time savings, monetary return (ROI through reduced Help Desk calls) or consolidation of workflow, portals and other IT infrastructure, and ability / time needed to design and develop the parts of the solution
• Executing a Project Plan based on these criteria

Like I said it does not need to be complex, but does require a certain amount of Project Management and, perhaps more importantly, buy in from the various project sponsors. Avoiding complexity in determining objectives, results in lower complexity of the finished product.

More on SailPoint

In reviewing yesterday's post, I realized I got a little off my intended track of talking about my SailPoint training, and spent more time talking about IdM Architecture.

In light of that, let me talk a little bit more about SailPoint and what they have to offer.

The SailPoint product seems pretty darn interesting. It does a fantastic job of linking in to various types of repositories (LDAP, Database, ERP, flat files, etc) that are found in the Enterprise and brings them into a common repository known as the Identity Cube (love this name, BTW)

Once the data is in the Identity Cube, all the fun begins, we can then do Role Mining, Segregation of Duties and other forms of Compliance analysis, and most importantly, Certification/ Attestation. It's easy to do all sorts of searches and analysis on the information held within the Cube and produce everything from application centric user role reports to IT Security oriented Risk scores based on role, application and group membership.

I'm going to find it pretty darn hard to believe that Enterprise IT and auditing departments will be able to work without a tool such as this in the future. This application is a great add on to add to current Identity and Risk Management projects and I'm looking forward to working with it.

201 CMR 17

I've been hearing some buzz about this legislation lately. For those that have not heard, 201 CMR 17 is a Massachusetts state law that specifies standards for the access, storage and management of personal information for state residents. (Full text of the law can be found here.)

While this blog has been more of a forum about Identity Management rather than Identity Theft, I still thought this was an interesting thing to discuss.

For the first time there is real comprehensive discussion of how data should be managed for the general public. While HIPAA and SOX mandate similar practices, this is the first legislation that says all personal information is important, not just the information as it pertains to specific groups or industries.

I do think that this is good for the Identity Management industry for a few basic reasons:

• There's no such thing as too much security
• Laws like this promote development of good access management infrastructure
• It gives us a chance to reexamine existing role / access assignments

Of course this is always interesting to an old fashioned provisioning guy like me since it means we need to develop the existing User Life-cycle process to make sure that we are building in stronger access management as noted above. Laws like this will make us think again about concepts of:

• Attestation / Recertification
• Role Assignment / Segregation of Duties

Sometimes this will be an audit of what rights / permissions users have over various File System / ERP / Database objects. Sometimes it will be a complete reassignment of these rights.

Planning for complying with this law will require planning and forethought. The state of Massachusetts has provided a FAQ and a checklist to help begin the planning process. However, I think at the very least a complete review of current processes combined with a through gap analysis from a knowledgeable project team.

As I think more on this, I will be posting my thoughts on what the 201 CMR 17 planning process will look like.

The Bigger Picture

In the Identity Management field, there's a lot of thought placed on how to provision users, and even more thought (rightly placed) on de-provisioning users. After all, if users can't get into the systems, you get no return from them since they are not as productive. Similarly, we also know that leaving user accounts active in the system leaves an organization open to data loss, financial and legal risk, and loss of productivity.

However, what of the middle of the user life cycle? User profiles and access need to be maintained as they change titles, departments and locations. It is also important to record this information for compliance/audit reasons.

IdM provisioning tools are probably the best tools for managing these changes in access for enterprise systems. While tools such as SAP's GRC are excellent for work in SAP systems, they are useless outside of them. Same goes for Active Directory / LDAP specific tools, PeopleSoft specific tools, etc. IdM systems have the ability to connect to all of these (and more) systems.

Leave the provisioning, role assignment and management to the IdM system and rely on specialty tools for specialty needs.

Where are the controls

I got this "joke" email from a family member, which I think proves some interesting points in the field of Identity Management, especially where governance controls are involved:

Outside the Bristol Zoo, in England, there is a parking lot for 150 cars and 8 coaches, or buses.

It was manned by a very pleasant attendant with a ticket machine charging cars £1 (about $1.40) and coaches £5 (about $7).

This parking attendant worked there solid for all of 25 years. Then, one day, he just didn't turn up for work.

"Oh well", said Bristol Zoo Management - "we'd better phone up the City Council and get them to send a new parking attendant..."

"Err ... no", said the Council, "that parking lot is your responsibility."

"Err ... no", said Bristol Zoo Management, "the attendant was employed by the City Council, wasn't he?"

"Err ... NO!" insisted the Council.

Sitting in his villa somewhere on the coast of Spain, is a bloke who had been taking the parking lot fees, estimated at A£400 (about $560) per day at Bristol Zoo for the last 25 years. Assuming 7 days a week, this amounts to just over A£3.6 million ($7 million)!

So what's the point here? Without governance controls anyone can come in and rule the roost. There is no accountability, control or record. I know I've been harping on this a lot lately, but it just seems to me that if controls are not in place and a means for reviewing the implementation and usage of the controls, anyone can walk away with the keys to the kingdom as it were.

This is much like what happened with Abdirahman Ismail Abdi or even Terry Childs, both of whom I have commented on before. If either one of them had been subject to some sort of governance process it would have been much more difficult for them to execute their schemes.

After all, you know what they say, "a million here, a million there and soon we're talking about real money."

Central Management

One of the objectives in my trip to Europe is to consider what additional systems an Identity Management system should be supporting.

Perhaps the biggest area that is not being supported is security applications. One wonders why this is so. Being able to centrally manage Smart Cards, Certificates, and Tokens is critical in maintaining security and regulatory compliance.

Take this example, where Abdirahman Ismail Abdi, managed to resign and commit 9.2 million dollars in fraudulent wire transfers with his still active electronic key card.

From an IdM perspective, we need to realize that de-provisioning must cover all sensitive Enterprise systems in a prompt and thorough manner.

It's also not enough to say that an email notification issued by the provisioning/de-provisioning system is sufficient for anything less than a first phase in an overall Identity Management project.

By completely automating the process we make sure that everything gets done at termination time. Going with the classic provisioning arguments, we make sure it's done in a timely manner, without the chance of manual operator errors and recorded in the audit/compliance database for future reference.

Realistically, we make sure that the barn door is closed before the horse can get out.

New School Identity Management?

I'm all for a discussion of changes in the Identity Management world, in fact I encourage them. I think it's a pretty dynamic world. As Mark Diodati mentions in his article "Changing times for identity management" (login required) There are elements of IdM that are established parts of IT infrastructure, and then there is "New School Identity Management, where he talks about Privileged account Management, AD Bridges and Virtual Directories"

All due respect to Mark, who I know has been around the IdM world for some time, but none of these elements should be considered New School and have been around for quite some time.

• Privileged Account Management - I don't know of an engagement I've worked on in the last 5 years that did not have some concern about the creation and management of both Privileged and Service accounts. If anything, because of their nature, these accounts have a greater need to be created in such a way that they are done according to mandated processes and recorded for audit and review.
• AD Bridges - While not a technology I've gotten to work with a lot I know that many a mixed UNIX/Microsoft shop consider the Vintella/Quest tools to be indispensable.
• Virtual Directories - Again, a technology that's been around for a long time. I've been working with Virtual Directory technologies since 2004, where I would commonly show customers how to map information, provide access controls and even used the Virtual Directory as a write back mechanism to supported repositories.

I can say that I'm glad these Identity Management technologies are finally getting their time in the sun. Some of these technologies have not been considered as interesting or sexy since they worked with a subset of users. I think we can all agree that there are more end users than UNIX accounts or system accounts so they should receive some more attention.

However, in the end, the design and implementation of an Identity Management solution must be holistic in nature. Regardless of one's opinion on the New School qualities of the all the technologies Mark mentions in his article, they must all be considered and planned for in the final design.

I've been thinking

I've been thinking a lot on what Identity Management means lately. Certainly my posts and thinking have been revolving around Provisioning. No big surprise given my background. But in reading other blogs, articles and papers I'm starting to think more about the "bigger" picture.

Certainly, we'd be nowhere without the infrastructure of IdM. Managing data held in directories and application stores are the basis of our challenges in the field. The fact is there's information about users all over the IT/Web Landscape. Finding ways of managing this information is absolutely critical.

This brings us to the topic of tools. We can think of all kinds of tools for managing identity information. Self Service Kiosks, provisioning UIs and HR applications are all ways of obtaining information. Work-flow engines, Virtual and meta-directories help to synchronize and process data, SSO applications allow us to increase the reach of our identity information. There is also the concept of managing and reducing the numbers of data repositiories using these tools as well.

This is all old news to those of us in the IdM world, however I'm getting more interested in what happens next and I've blogged on this several times before. The way I see it, there's two things that have to happen:

1. The continuing maintenance of Data. This has to happen on multiple levels.

From the perspective of the enterprise, information from all sources in the enterprise should be brought into a unified structure. I won't even touch the question of this structure's format. For the purposes of this discussion, acknowledging the store is enough. This store should be kept up to data with respect to all connected repositories, becoming the central authoritative store.

There's another perspective that I have not really addressed in the past, which is the personal perspective. For too long, I've only looked at the enterprise perspective, but given recent trending I think it's important to look at personal identity management as well. By this, I'm referring to the ability of a given person to build the components of their identity for use by the outside world. What information should be public, what information should be private with respect to other people and organizations.

• Do my friends need to know my work telephone number or will my mobile suffice?
• Do the people in my office need to know my IM handle that I use after work?

I think you get the point. I know there's a lot of people out there thinking about this and it is something I plan on learning more about in the coming months.

2. How do we know that our data, applications and access are secure?

This is another big question and touches on the topic of GRC, which I've also been blogging on recently. There's some debate on this at the moment which I'm not going to go into in detail. However whether you look at this as one discipline or three (or four if you subscribe to GRCE). For the purposes of this discussion, it does not really matter. The fact is that all organizations must manage risk and that includes risk to ones IAM data. The fact is that one's identity data is directly tied into one's access management data and therefore this needs to be watched closely.

SaaS: The Series

As you might know from reading the SECUDE Global Consulting Blog, I am at the Burton Catalyst Conference this week. One topic that I got into a lot during the first evening was about Software as a Service (Saas)

I heard a number of arguments, both Pro and Con about this topic. Over the next few days I plan on discussing a number of things about SaaS on this blog.

Rather than starting off with Pros and Cons of SaaS (those who know me, know my feelings, but I'll hold off for the moment) I'd like to start with what I call the Chicken and the Egg issue.

In some way shape or form, SaaS will come to IdM as it will to other areas of the IT world. However, I believe that IdM has some specific challenges that need to be addressed, namely in security and reliability.

Due to these considerations I'm thinking that only firms that specialize in the IdM space will be able to be successful hosts. However will firms be willing to be early adopters? This is where the Chicken and Egg argument comes in. Customers are going to want experienced hosts, but I do not believe there are any hosts out there that are ready.

I'll be discussing some of the details of what an experienced host will offer and some potential stratgegies for mitigating the risks in the coming days.