The Identity Trifecta...
How badly is your identity project going right now?
People are starting to come back from vacation and those Identity Management project decisions that got pushed off until 'after vacation', like which vendor, consultant, approach, project team, etc. are staring people square in the eyes. They are also starting to realize that Labor Day is approaching, and then they have 3 months TOPS to get a project done before everyone is more concerned about what to wear to the company holiday party than how far along their projects are.
I was reading some blogs this morning about IdM projects and approaches and I found myself grinning. Grinning and squirming actually. Squirming because I was saying the same thing up until a year and a half ago – Identity Management applications and the projects that are tied to them are larger than you think, will take more time than you think and if you hire the right consultants they will fix it. Full disclosure here folks – I was one of those consultants.
Why I was grinning is that these folks are still holding onto old truths. There was a time when projects took thousands of hours of consultants time, because the space as a whole was in its infancy and nobody knew anything. Myself included. Guess what? There are best practices now. The products have matured (somewhat). Right and wrong approaches are taken. People know what not to do as part of a project. Why is the mantra still these are big, expensive, complex, projects.
Is it the software (partly - you need to configure an adapter even if you don't build it)? Is it experience level of implementors (maybe, but less of an excuse today than 18 months ago)? Is it picking the wrong use case to build for (maybe)? Or is it that there is no real knowledge base (except vendors and consultants) of best practices, do’s and don’t’s for those of us looking at how to ‘do’ an identity management project?
Here is my two cents. My two cents based on my experience of licensing over 500,000 users of Identity Management software, being involved in varying degrees with 8 IdM application deployment projects, and watching millions of dollars spent at other firms to solve one specific problem that was drowned out by competing interests and misguided approaches.
Figure out what the end result is, specifically.
This doesn’t mean ‘SOX compliance’ or ‘HIPAA Compliance’ it means things like ‘Showing a 50% reduction in faults on our year over year audits for our IT controls’ or ‘Reducing our Audit costs by 30% over two years’. Make sure that if you do an ROI that the clock starts from when you FINISH your IdM deployment, not when you start it.
Make sure you ask the vendors how they control access to applications outside of the provisioning process. Can a DB administrator write directly to an HR system, or can a Windows admin add an AD account by talking to the provisioned application directly? Know all the risk and decide if it’s tolerable.
Also the industry has matured. Applications are not the only game in town. There are other vendors that have taken the best of provisioning, solid components of identity, and flattened business process out and deploy in the network. Why is this important?
It’s important because when you manage identity and ultimately control access based on identity at the network layer, you are controlling access to 3 layers not just one. That’s right – it’s an Identity Trifecta.
When you decide and control who has access in the network layer, you protect your network, your infrastructure (servers), AND your applications. With an IdM application, you are still allowing access to the network and the servers, but are ‘controlling’ access to the applications. Which if you can write directly to a database outside of the IdM/provisioning app, what good is the IdM app?
Also if you deploy in the network layer there is typically a handful of network gurus to deal with that all speak the same language. Not so with Application based identity. You will end up having to talk to every application owner about the configuration of their app (which you are threatening their loss of control over by the way), and then building (or at the very least configuring) an adapter as part of the project. That may be attractive for some organizations, for others, not so much.
Anyway, my point here is to look at why you need Identity management, where it should be implemented (network vs. app), and how complicated do you want to make it for specific reasons.
I’ll take the payout on a Trifecta any day…
identitystuff @ gmail.com
People are starting to come back from vacation and those Identity Management project decisions that got pushed off until 'after vacation', like which vendor, consultant, approach, project team, etc. are staring people square in the eyes. They are also starting to realize that Labor Day is approaching, and then they have 3 months TOPS to get a project done before everyone is more concerned about what to wear to the company holiday party than how far along their projects are.
I was reading some blogs this morning about IdM projects and approaches and I found myself grinning. Grinning and squirming actually. Squirming because I was saying the same thing up until a year and a half ago – Identity Management applications and the projects that are tied to them are larger than you think, will take more time than you think and if you hire the right consultants they will fix it. Full disclosure here folks – I was one of those consultants.
Why I was grinning is that these folks are still holding onto old truths. There was a time when projects took thousands of hours of consultants time, because the space as a whole was in its infancy and nobody knew anything. Myself included. Guess what? There are best practices now. The products have matured (somewhat). Right and wrong approaches are taken. People know what not to do as part of a project. Why is the mantra still these are big, expensive, complex, projects.
Is it the software (partly - you need to configure an adapter even if you don't build it)? Is it experience level of implementors (maybe, but less of an excuse today than 18 months ago)? Is it picking the wrong use case to build for (maybe)? Or is it that there is no real knowledge base (except vendors and consultants) of best practices, do’s and don’t’s for those of us looking at how to ‘do’ an identity management project?
Here is my two cents. My two cents based on my experience of licensing over 500,000 users of Identity Management software, being involved in varying degrees with 8 IdM application deployment projects, and watching millions of dollars spent at other firms to solve one specific problem that was drowned out by competing interests and misguided approaches.
Figure out what the end result is, specifically.
This doesn’t mean ‘SOX compliance’ or ‘HIPAA Compliance’ it means things like ‘Showing a 50% reduction in faults on our year over year audits for our IT controls’ or ‘Reducing our Audit costs by 30% over two years’. Make sure that if you do an ROI that the clock starts from when you FINISH your IdM deployment, not when you start it.
Make sure you ask the vendors how they control access to applications outside of the provisioning process. Can a DB administrator write directly to an HR system, or can a Windows admin add an AD account by talking to the provisioned application directly? Know all the risk and decide if it’s tolerable.
Also the industry has matured. Applications are not the only game in town. There are other vendors that have taken the best of provisioning, solid components of identity, and flattened business process out and deploy in the network. Why is this important?
It’s important because when you manage identity and ultimately control access based on identity at the network layer, you are controlling access to 3 layers not just one. That’s right – it’s an Identity Trifecta.
When you decide and control who has access in the network layer, you protect your network, your infrastructure (servers), AND your applications. With an IdM application, you are still allowing access to the network and the servers, but are ‘controlling’ access to the applications. Which if you can write directly to a database outside of the IdM/provisioning app, what good is the IdM app?
Also if you deploy in the network layer there is typically a handful of network gurus to deal with that all speak the same language. Not so with Application based identity. You will end up having to talk to every application owner about the configuration of their app (which you are threatening their loss of control over by the way), and then building (or at the very least configuring) an adapter as part of the project. That may be attractive for some organizations, for others, not so much.
Anyway, my point here is to look at why you need Identity management, where it should be implemented (network vs. app), and how complicated do you want to make it for specific reasons.
I’ll take the payout on a Trifecta any day…
identitystuff @ gmail.com
posted by Mark Mac Auley at 8/01/2006
Get My Identitystuff Newsletter
0 Comments:
Post a Comment
<< Home