The other side of the article

It’s seldom that I publish more than one blog post on a single piece, but Mark Diodati’s article “Changing times for identity management ” (login required) spoke of two main themes that I felt needed to be discussed.  In an article on IdM Thoughtplace, I looked into some issues of what composes “New School” Idm.

In this piece, I’d like to comment on a couple of points that Mark makes that I particularly agree with.

First off, Mark mentions that thorough analysis and review of IdM offerings is essential.  The selection team/steering committee  needs to remember that no IdM product exists in a vacuum.  Testing against ERP, enterprise LDAP/AD and other key systems is essential, and involving a pilot group is key as well.  I’d go a step beyond what Mark specifies, by adding that your pilot group needs to be multi-disciplinary. Just IT or Help Desk folks won’t cut it here.  Make sure there’s some HR and ERP users along with other “typical” users in your organization.  You’ll need to do a little more hand holding and training earlier that you’d like, but you’ll get better responses and metrics in return.

I’m also in agreement that you should review all offerings and available features/upgrades from current infrastructure. That “buried treasure” could be the key to keeping your infrastructure secure and compliant. Also find every way possible to use and reuse your current infrastructure., it can pay off in the long run.

It’s a tough economy out there, but that does not mean that you should stop your review of  IdM improvements.  Use the current time for evaluation and planning.  Bring some vendors in for a PoC to make sure it fits into current infrastructure.  The best place to start looking is right in your server rooms and data centers.  Go to it!

The Transition from CRG to GRC

I’m an Identity and Access Management kind of guy.  I don’t pretend to deny it, however sometimes it does cloud some of my views of the rest of the enterprise. Take the GRC concept for example. As an Identity Management guy, I always looked at GRC as CRG:

• Compliance – How to I show an auditor changes that happen to a user’s identity throughout the identity life-cycle?
• Risk – How do I make sure that there’s no conflict of interest and ensure Segregation of Duties (SoD), ensuring Compliant User Provisioning
• Governance – What are the rules put into place that govern Compliance and Risk?

I also never considered how GRC works outside of the IAM world or why it’s important.  After listening to a great presentation from SAP, I got a nice, if basic education which has gotten me to change my thinking from CRG to GRC.

A firm set of governance principles and procedures must be determined before engineering any mitigation processes for risk and compliance. Without this the potential for “Compliance Creep” (risk  is assumed) will run amok.  And without regular discussion and review there is no way to make sure that all items subject to risk and compliance review will be monitored and prioritized.

The fact is that we need to be continuously checking compliance.  Almost any potential work-flow needs these checks and not always the risks that we consider in the IAM world.  We’re well ware of the issues involved with granting elevated privileges, but what about ensuring that the links to partner sites remains secure?  This are also part of ensuring compliance.

My view of risk has not changed as much, we know from a purely IAM perspective, that we need to consider segregation of duties, administrator accounts, service accounts, SSL, etc. But of course we need to think about the larger level as well.  Who provides authorization, approvals and ensures accuracy?  What do we do to make sure that users, approvers and administrators are using the system correctly?

What I got out of this is that all three concepts must be considered together and entail a three part process:

• Governance – What are our priorities in managing Risk and Compliance
• Risk – What are our risks at the process level and the operational level? How are they to be mitigated?
• Compliance – How do we monitor and record these risks?

I’m thinking this will be a large part of  Identity and Enterprise Architecture discussions for some time to come.

Part II of Security Architecture and Design

The second part of my series on security architecure and design is up a Risk Intelligence.  In this post I look at the modular operators and give examples of how they have been used in security engineering.

Identity Theft and Enterprise Identity Management

When I tell people that I work in the Identity Management field, the first comment is usually something like, “Wow, identity theft, cool stuff.  What should I be doing to protect myself?” Sometimes I’ll try to explain about user life cycle provisioning, role management, meta directories, compliance, audit and the other technologies and concepts that I consider for Enterprise customers, but for some reason that’s not terribly interesting to most people.

However, I recently started thinking about it. What are we really doing here? At the very core, it’s all about defining and ensuring the enterprise user’s identity within the organization. So in essence, we are concerned with the idea of Identity theft when you think about it.  Making sure the right individuals are logging in with the right credentials. Then making sure that these individuals do not have more access then they are entitled to.

So maybe now my new answer will be: “Yeah, kind of, except that I deal with preventing identity theft at the corporate level, reducing fraud and eliminating risk”  Then I can go on and explain about user life cycle provisioning, role management…

A Need for Standards

I came across an interesting eWeek Blog entry.  In it, Michael Vizard makes some interesting points about lack of standards in Identity Management. He makes some valid points in that there is no real standard for creating physical means proving identity. While a comprehensive framework makes sense for physical provisioning and Access Management, I have some concerns.  If we have a published framework for creating Access Management tokens, that makes it that much easier to compromise those standards.

Mitigating this concern is the fact that there are several ways to ensure the validity of the issued token.  The FIPS standard cited in the blog entry makes heavy use of PKI technologies.  I would assume other hashed attributes would be a part of the token as well.

My other primary concern is that the examples that Vizard cites are both governmental in nature.  It would make much more sense to me if there was a public sector standard cited as well.

It will be interesting to see how this develops in both the public and private sectors.

System Shock

The negative sell is always the hardest to make, ”Do this to prevent this horrible outcome”. You rarely know if you were successful or not. The great leader stands on the rubble of the collapse with his call to action, inspiring the people to pull together, however, the man that prevents the collapse to begin with is never known.

It is a well worn cliché that crisis is the best opportunity. Preventing crisis, however, is no opportunity at all. Often, whether the crisis is prevented or not becomes a game of speculation. Claims of success are frequently met with incredulity; it was never a threat to begin with, it was a matter of chance, fate, you got lucky. As long as quotidian affairs continue there is very little recognition to be found in prevention.

Despite the foregoing which is all painfully obvious, many still focus on ill conceived notions like ROI for security. One should focus instead on what the true by product of information security and risk management is, to wit, survivability. A well executed risk management program permits a company to survive situations like the current one or specific freak accidents. One cannot predict the event or its magnitude, but it will arrive and those whose sole focus is growth invariably fail. The world is unpredictable and unforgiving.

Project Scope and Sustainability

(This post was written by Matt Pollicove)

One thing I’ve noticed when talking to people about Identity Management projects involves how to determine the project’s overall scope.  “How do I scope this?” they will say to me.  Now that’s kind of tough to answer right off the cuff, especially when considering Pollicove’s Law of Provisioning  which basically says there’s no guarantee that companies that are in the same vertical will work the same way.

 

However, I think there are some best practices that can be worked with when considering implementing an Identity Management solution:

 

1.       Make sure you have executive sponsorship.  C-level support is going to be important in balancing the needs of your stakeholders and their budget dollars.

2.       Make sure you have a good plan of what you want your Identity Management solution to cover.   An essential part of this is conducting a thorough assessment.  Document everything, diagram existing processes, then take them apart and put them back together the way they should be, then do it again.  This should be done with a combination of internal and external sources.  Internal resources know how current systems are configured and interact.  External resources will offer an impartial assessment of how these systems can interact more efficiently. External resources will also be helpful in determining which Identity Management products will work best in your infrastructure.

3.       When building your plan, know where you’re starting from.  What will be used as your authoritative store?  How will it be built?

4.       Where are you going to? What will you provision to?  What will you control access to?

5.       How are you going from 2 to 3?  How will you engineer your changes?  What will the phases of your project consist of?

 

Item 4 is probably the most important part of the process.  Many a project has suffered due to overreaching phase objectives. Carefully define what you want to achieve in each phase. 

 

Data cleansing and analysis is almost always your first phase.  If you don’t have clean data, you won’t have a clean project.  Future phases can deal with:

·         Creating an Authoritative Store

·         Provisioning to essential systems

·         Password management

·         Role management

·         Provisioning to secondary systems

·         Etc.

 

So the big question is what order does this happen in?  How long will it take?  I always suggest attacking “low hanging fruit” first by attacking the easiest objectives that will show the biggest net gain?  As a part of number 1 above, think about solving automation needs, compliance needs, addressing password management request costs to the helpdesk? 

 

How long will it take?  As long as it has to.  This is going to be a major project that will affect many systems and departments.  Take it slow and easy.  Test it thoroughly and make sure there’s a good knowledge management/training initiative to let your users know what happening and how everyone will benefit.  It’s never good if your users equate an Identity Management initiative with a foul tasting medicine.  This includes your stakeholders.

When Enterprise Systems Collide…

It’s no secret that there are many systems in the Enterprise and that sometimes they seemingly come into conflict.  How many places are there where one can:

• Change information about themselves
• Change information about others
• Change a password
• Add new roles
• Add  new access

Well there are many.  One of the challenges of Identity Management is to examine, balance and ultimately limit what a given user can do from a given interface. Ultimately it is in the best interest of administrators and users to do this so that workflows and processes are as streamlined as possible.

This means that the IdM system does not need to be the center of the universe for updating information if prior to its introduction the HCM system had a perfectly good Self Service Module.  It also means that not every application needs to have its password maintenance functionality turned on, especially if passwords are being sent from another interface (i.e., OS password change, HD Delegated Administration, IdM password self serviceIn a heterogenous environment, evaulate all functionality, then act.

There’s no need to reinvent or reuse the wheel more than necessary.

Identity Management 2.0

I saw an interesting article that discusses the concept of Identity Management 2.0.

The article starts with a good recap of current, or Identity Management 1.0 capabilities, that we are all familiar with, access management, LDAP, Provisioning, etc.

Where the article gets really interesting, of course is when the Author delves into what he considers to be the revolution of Identity Management.  As the article states:

The core platform of Identity Management 1.0 capabilities such as authentication, authorization, user provisioning, password management and the like has provided a base for improving security and automating manual processes to drive down operational costs. Identity Management 2.0 extends the core platform to offer stronger forms of authentication, risk-based authorization and fine-grained entitlements, user provisioning based on roles and relationships, as well as the ability to virtualize identities, all in an effort to address the next generation of requirements and threats.

What, to me, is even more interesting is that an old IdM technology, Virtual Directory, is considered to be a core component of IdM 2.0.  Dubbed “Identity Virtualization,” the article likes using this technology for creating customized user repositories for applications. Maybe the oft-quoted “Year of the Virtual Directory” is finally coming to pass.

It should be interesting to see how this concept matures over the next 12-18 months, particularly as we’re going into what many consider to be tight times in the IT world.

Whitepaper Download

For those of you looking to download a copy of Strategies for Creating an Authoritative Store, it is now available from the SECUDE Global Consulting website.  The paper was initially released through Business Trends Quarterly.

The paper is intended to be a discussion of creating an Authoritative Store for use in an Identity Management Infrastructure.  It provides a good starting point for those considering implementing or revising their IdM landscape.