Came across this list on attrition.org today of reported data loss incidents since 2000.
It's a rather long and scary list. Keep in mind these are ONLY the reported incidents that have been found by attrition.org. Who knows how many have not been reported. I'd also dare say there's a heck of a lot more where companies just don't know that an incident's occurred.
Saturday, July 21, 2007
Friday, July 20, 2007
IBM the leader in Identity and Access Management
I didn't say it...not lately anyway (I've previously said it many many many many many times in front of customers). At least now I can prove I wasn't lying :)
IBM are the worldwide Enterprise Identity and Access Management vendor in terms of revenue share according to analyst firm IDC.
They may not be for long however. Oracle just became a very formidable opponent with their acquisition of Bharosa yesterday. Don't get me wrong. I'm not saying Oracle wasn't formidable before the acquisition. But the issue now is that Bharosa does things that IBM's suite does not.
That's right. I said it. An IBM competitor has useful functionality that IBM Tivoli does not provide (here comes all the abuse from my ex-IBM colleagues).
More on this later.
IBM are the worldwide Enterprise Identity and Access Management vendor in terms of revenue share according to analyst firm IDC.
They may not be for long however. Oracle just became a very formidable opponent with their acquisition of Bharosa yesterday. Don't get me wrong. I'm not saying Oracle wasn't formidable before the acquisition. But the issue now is that Bharosa does things that IBM's suite does not.
That's right. I said it. An IBM competitor has useful functionality that IBM Tivoli does not provide (here comes all the abuse from my ex-IBM colleagues).
Tuesday, July 17, 2007
A case for data leakage prevention at IBM
I used to work for IBM. If you know me or have been reading this blog for at least the past few months, you know this.
It should come as no surprise that from time to time, I keep an eye on what IBM does. I also read Robert X Cringely's blog. I've been catching up on my reading (I'm way behind) and came across this post regarding IBM's LEAN program. It generated over 1000 responses on Bob Cringely's blog so it obviously touched a nerve. I was once a cynical IBM employee so I can identify with some of the comments. At the risk of getting flamed by my ex-IBM colleagues, I shall comment no more on this :)
Bob followed that post with another the following week containing an IBM internal email circulated to employees in response to Bob's blog post from the previous week. That IBM management felt the need to respond to a "rumour" as they call it makes one wonder if Bob's on to something. But what I really want to know is this...
How the heck did that email leak outside of IBM walls?!?! Lotus Notes has protection against emails being forwarded, printed and even copying of email contents. Did those check-boxes not get ticked before sending the email? And if they DID get ticked then someone must have found a way around it (a Lotus Notes expert could probably figure it out). If there is no way around it in Lotus Notes (I'm not a Lotus Notes expert) then did someone just take a screen shot and have Bob painstakingly re-type the entire email? Perhaps. But I doubt it was that difficult. My guess is that all Bob had to do was copy from his email inbox straight into his blog post.
Does IBM have a Data Leakage Prevention (DLP) strategy in place? Maybe. Do they have a working solution in place? That was a rhetorical question. They don't. Will they have one soon? I'd put money on the answer being "yes". And yeah. I know something you don't. Don't ask or I'll have to go "James Bond" on you.
It should come as no surprise that from time to time, I keep an eye on what IBM does. I also read Robert X Cringely's blog. I've been catching up on my reading (I'm way behind) and came across this post regarding IBM's LEAN program. It generated over 1000 responses on Bob Cringely's blog so it obviously touched a nerve. I was once a cynical IBM employee so I can identify with some of the comments. At the risk of getting flamed by my ex-IBM colleagues, I shall comment no more on this :)
Bob followed that post with another the following week containing an IBM internal email circulated to employees in response to Bob's blog post from the previous week. That IBM management felt the need to respond to a "rumour" as they call it makes one wonder if Bob's on to something. But what I really want to know is this...
How the heck did that email leak outside of IBM walls?!?! Lotus Notes has protection against emails being forwarded, printed and even copying of email contents. Did those check-boxes not get ticked before sending the email? And if they DID get ticked then someone must have found a way around it (a Lotus Notes expert could probably figure it out). If there is no way around it in Lotus Notes (I'm not a Lotus Notes expert) then did someone just take a screen shot and have Bob painstakingly re-type the entire email? Perhaps. But I doubt it was that difficult. My guess is that all Bob had to do was copy from his email inbox straight into his blog post.
Does IBM have a Data Leakage Prevention (DLP) strategy in place? Maybe. Do they have a working solution in place? That was a rhetorical question. They don't. Will they have one soon? I'd put money on the answer being "yes". And yeah. I know something you don't. Don't ask or I'll have to go "James Bond" on you.
New look and name for the blog
This won't affect those of you reading this via an RSS feed. For those that usually get to my posts directly on the site, you'll notice a different look. No reason behind the change in look and feel other than to keep it fresh. It's just a standard template that is available via Blogger so it's not as if I spent any time or money to do it. I also started to notice that lots of people were using the same template (as my old one) so that was yet another reason for the change.
The most observant among you may also have noticed that I've renamed the blog. I hope the new name reflects what this is all about more clearly. The old name was a bit open ended. There's been nothing random about my posts for awhile so that didn't really make sense. This blog is really about IT security with a strong bias around Identity related issues (and probably data security in the months to come).
I'm not sure what that does to my blog's entry in Google's index. Hopefully nothing too painful (like getting thrown into supplemental result oblivion for example).
P.S. Could you please let me know (via comments or the "Email Me" form on the right hand side of the page) if you find any peculiarities with the blog (apart from anything stupid I may say in a blog post...even then write a comment to tell me what you think). Who knows what didn't get migrated over properly.
The most observant among you may also have noticed that I've renamed the blog. I hope the new name reflects what this is all about more clearly. The old name was a bit open ended. There's been nothing random about my posts for awhile so that didn't really make sense. This blog is really about IT security with a strong bias around Identity related issues (and probably data security in the months to come).
I'm not sure what that does to my blog's entry in Google's index. Hopefully nothing too painful (like getting thrown into supplemental result oblivion for example).
P.S. Could you please let me know (via comments or the "Email Me" form on the right hand side of the page) if you find any peculiarities with the blog (apart from anything stupid I may say in a blog post...even then write a comment to tell me what you think). Who knows what didn't get migrated over properly.
Friday, July 13, 2007
Data security and leakage prevention landscape
I've been focusing purely on this data security game for 2 months now (hence my lack of blog posts in June) so I thought it would be a good time to take a snapshot of my views. I didn't think it was appropriate to do it after a month because it was still too early for me to have an informed view of the marketplace and what the issues really are. At the 2 month mark, I've seen quite a few customers and am now able to understand what the typical use cases are, the varied approaches and attempts at solving the issue and how much demand there is in the market for solutions.
A few high level views I have of this space are as follows:
A few high level views I have of this space are as follows:
- It's the Wild West - Everyone tries to solve the issue in different ways. This includes organisations trying to prevent data leakage and vendors trying to solve the issue with their solutions. The reason is because it's a very new area and everyone's just coming to grips with the enormity of the task at hand. As a result, there's many a vendor who claims to solve the data leakage problem, but most are point solutions and any organisation wanting to make a decent attempt at tackling the issue will either need to come up with a holistic approach and plug the gaps with the point solutions or purchase a product that does most of what is required and decide if they want to spend money on plugging whatever holes remain. This concept and landscape is nothing new of course. Every new type of issue exhibits this early stage characteristic and as maturity of the marketplace sets in, you inevitably see consolidation and more holistic and complete approaches. The most recent example is obviously the Identity and Access Management industry. Just look at how the large vendors built their product suites. Needless to say, I'm in the camp that says the most holistic approach is the way to go. Don't buy point solutions because a year or 2 from now, you'll find that the next version of the 10 different products you just bought will overlap like crazy and upon further analysis, you realise you only needed to spend half as much...and that's not including the integration costs you had to bear by trying to tie all the disparate products together.
- Deja vu - Agents vs Agentless. Sounds frighteningly familiar. Identity and Access Management vendors had many a debate about the 2 approaches and which was actually better. Before that, it was the Systems Management bunch. It's the age old architectural and management simplicity vs visibility on the targets. In this case, it's the argument between having a network appliance watching network traffic between nodes and at the network perimeter and deploying agents at all relevant endpoints. If you monitor the network, you don't need to install anything on the endpoints. Problem is, you lose complete visibility once machines are no longer on the network. You are also blind to anything users do that doesn't involve the network (consider leakage via USB devices or CD burns). In the modern IT environment, there are too many mobile users that aren't on the network most of the time to ignore this as an issue. In trying to gain ease of deployment and management of the IT infrastructure, you lose security at the endpoint. On the other hand, placing agents on the endpoints means that your systems management and software distribution/asset management costs go up. There are more moving parts and it's yet another thing for the operations team to worry about. That is offset by the fact that you have visibility of your users regardless of whether they are on the network and whether they perform network operations. In this scenario, you are almost always protected (I'll explain the "almost" in the next point). I know which approach I'd rather take. In case I need to spell it out, consider that the concept that there is a perimeter around your organisation. It just isn't true anymore. You need to open up the network to do business. So just monitoring the network won't cut it. You need to place a virtual perimeter around your data to prevent it from going where it should not. This means you need agents.
- It is almost impossible to stop someone If they REALLY want to steal something - It's simple. Take a picture. No agent will be able to stop that. Until the day where each monitor has a sensor that can sense when an image capturing device (e.g. a camera) is being used and feed it back to the operating system, this cannot be fully stopped. You can however, slow down the speed at which thieves can get at the data. They may still get what they need, but it'll take them quite a bit longer and by then, you have a good chance of catching them because any solution worth buying will be able to tell that someone is doing a lot of things they shouldn't be doing. For example, for someone to realise that there is a way around the system, they would have had to either have lots of inside information (in which case the problem is not technical, but social) or have tried many things on the system to figure out where the gaps are. All the attempts should be noticed and relevant administrators notified. What this does is buy you time to catch a thief. 1 out of 10 may still get away with it, but you've stopped the other 9.
- It's an educational process - Most employees want to do the right thing. Problem is, most don't have time to read the 1000 page corporate data security policy. Putting measures in place can at least alert managers when employees do things they should not be doing or tell the users themselves. How many times have you emailed something to your home email account because it was the easiest way to get it there to work on it? Most people may think this is ok, but any experiences security professional will tell you that doing such a thing is probably a policy breach of some sort. If you just tell the users that are doing the wrong things that they should not be doing them, they'll usually stop. After all, who wants to get into trouble? Because of the lack of user education, many data leakage incidents are accidental. They don't know any better.
- At the forefront of everyone’s mind – Almost everyone is at least thinking about data leakage and what they can do to address the issue (see my notes from Infosecurity Europe 2007 days 1, 2 and 3). This does not mean organisations have the budgets to implement anything yet. There are still many that are stuck in the 90s and busy playing with firewalls and anti-virus/spyware products and have not moved on to other activities because of budgetary constraints. That being said. even these organisations are thinking about data leakage. The media obviously has a lot to do with this sentiment in the market thanks to constant reports of major incidents in all sorts of institutions (TK Maxx anyone?) and the fines being dished out to the organisations due to their lack of appropriate measures. It’s a real issue. Organisations will inevitably have to address it one way or another. This is also not just limited to large companies anymore. We have the PCI data standards to thank for that. Compound this with the fact that people are also thinking about identity theft (not always caused by data leakage, but data leakage usually leads to identity theft) and everyone has a real compelling reason to act.
- Not just about compliance – Sure this is a driver, but it’s not always the compelling reason. In fact, compliance as a justification for data leakage solutions is less common than most might think. Actually, I worry when a company wants to protect data simply because they have to be compliant (a good security department should not be driven only by compliance). More commonly, it’s about knowing what’s going on and just plain old good security best practice. Of course, there are those that use compliance as the official reason, but often that’s for budgetary reasons rather than any actual real business or technical reason.
- A good leakage prevention solution enables business – Why has security always been so hard to justify when it comes to asking management for a budget? Because it’s not easy to show return on investment (ROI). Security is also seen as annoying. After all, it just stops people from doing work right? That’s exactly what a draconian security environment does. Productivity suffers because things are just difficult to do due to security measures put in place. With data leakage prevention, the ROI is a little easier. I’m not saying it’s easy, but it’s much more effective when you go to management and say “if we don’t protect our data, we get fined millions if a single piece of information gets out.” Also, wouldn’t it be nice if you could let people do slightly risky things to be more productive as long as there’s accountability? Traditional measures take an all or nothing approach. The main reason being the inability to track fined grained activities. Yes, it sounds like authorisation/entitlement management. Why? Because that’s exactly what it is, but using a data centric view instead of an identity centric one. If only you could monitor, control and react (if required) to all user activities when dealing with data. Controls could be loosened slightly.
Thursday, July 05, 2007
SAP would do well to buy Ping
Ping Identity's been doing a lot of good work in the Identity space of late. Their latest is being first to market (at least I think they are) to launch a cross-over solution for Microsoft Windows Cardspace and OpenID in the form of SignOn.com.
They are perhaps the most active startup in the Enterprise Identity Management space (the guys at Securent might beg to differ) and are crossing over into the User Centric Identity arena of late, most notably with their interoperability tests at the RSA Conference earlier this year. They're also frequently mentioned by Kim Cameron on his blog in relation to work they do with Federated Identity and Cardspace, so it's not really surprising that they've launched SignOn.com
I was browsing their site when I came across a press release from mid June which mentions that their PingFederate product is now SAP NetWeaver certified. This jumped out at me because of my recent train of thought relating to SAP.
I wonder if SAP has its eyes on Ping Identity as an acquisition target? It would have fit right in with the NetWeaver story even without having PingFederate certified against it. Add the foray into the User Centric Identity space and it would give SAP a competitive advantage against the other established Enterprise Identity Management vendors. Why? Because very few of them are doing very much about it. Novell and Sun come to mind. The other vendors are too busy trying to acquire more companies to fill out their risk and compliance portfolios.
If I made the decisions at SAP, this is something I'd be pursuing aggressively. Then again, I don't run a multi-billion dollar company so what would I know.
They are perhaps the most active startup in the Enterprise Identity Management space (the guys at Securent might beg to differ) and are crossing over into the User Centric Identity arena of late, most notably with their interoperability tests at the RSA Conference earlier this year. They're also frequently mentioned by Kim Cameron on his blog in relation to work they do with Federated Identity and Cardspace, so it's not really surprising that they've launched SignOn.com
I was browsing their site when I came across a press release from mid June which mentions that their PingFederate product is now SAP NetWeaver certified. This jumped out at me because of my recent train of thought relating to SAP.
I wonder if SAP has its eyes on Ping Identity as an acquisition target? It would have fit right in with the NetWeaver story even without having PingFederate certified against it. Add the foray into the User Centric Identity space and it would give SAP a competitive advantage against the other established Enterprise Identity Management vendors. Why? Because very few of them are doing very much about it. Novell and Sun come to mind. The other vendors are too busy trying to acquire more companies to fill out their risk and compliance portfolios.
If I made the decisions at SAP, this is something I'd be pursuing aggressively. Then again, I don't run a multi-billion dollar company so what would I know.
Wednesday, July 04, 2007
SAP Identity will take time
I gave my 2 cents on the SAP acquisition of MaXware when it happened and noted that it wouldn't be long before they officially announce their entry as an Identity Management vendor.
Well they've now publically stated their intent. It'll take them awhile before they truly understand the space however. It's not surprising given that this is new to them and they've been too busy milking the SAP R/3 cash cow for so long. Oracle's Identity Architect Nishant Kaushik points this out (the "not understanding the space" part, not the cash cow bit) in his latest blog post following his observations from the recent Burton Group Catalyst conference. He's right, although he does have a vested interest in pointing this out given that SAP and Oracle go head to head in almost everything.
What SAP may not yet realise (but will soon enough) is that they have a distinct advantage over many of the other Identity Management (IDM) vendors when it comes to user management and provisioning, especially around anything to do with people and entitlements. In other words, what people should be getting access to within the environment and how they get this access.
Their competitive advantage is actually SAP R/3 itself. Almost every IDM deployment drives their user provisioning, updates and de-provisioning processes through their HR systems. In most cases this is going to be SAP or Oracle (typically Peoplesoft). It makes sense of course. If a person is hired, the first place they appear is in the HR system. When they leave, they get taken out of HR. It is for this reason that Oracle wasted no time in closely integrating their IDM suite with their HR applications and also took the trouble to cross certify them.
If SAP is to become a serious IDM vendor and challenge the likes of IBM, Oracle, Sun, CA and BMC they need to start with their existing R/3 install base. This seems like a no-brainer. Sales 101. Go after the people you already have relationships with and up-sell your products. What they'll need to be able to do however, is convince the install base that SAP IDM is the way to go because of the tight coupling with R/3 right from the underlying technology through to the business processes. SAP will not beat the other vendors on functionality, at least not for now.
They've essentially bought a meta/virtual directory product with synchronisation capabilities and minimal provisioning functionality (MaXware) and another product to tie in compliance (Virsa). There isn't enough functionality to compete from a holistic standpoint. They will need to prove that they hook into the SAP platform better than anyone else out there (and they really should because it's their own software) and they will also need to sell customers on their commitment to an overall IDM strategy and then go out and buy companies to fill the gaps, of which there are many.
In short, SAP need to focus on 2 things before being able to be a serious threat in the IDM game:
Well they've now publically stated their intent. It'll take them awhile before they truly understand the space however. It's not surprising given that this is new to them and they've been too busy milking the SAP R/3 cash cow for so long. Oracle's Identity Architect Nishant Kaushik points this out (the "not understanding the space" part, not the cash cow bit) in his latest blog post following his observations from the recent Burton Group Catalyst conference. He's right, although he does have a vested interest in pointing this out given that SAP and Oracle go head to head in almost everything.
What SAP may not yet realise (but will soon enough) is that they have a distinct advantage over many of the other Identity Management (IDM) vendors when it comes to user management and provisioning, especially around anything to do with people and entitlements. In other words, what people should be getting access to within the environment and how they get this access.
Their competitive advantage is actually SAP R/3 itself. Almost every IDM deployment drives their user provisioning, updates and de-provisioning processes through their HR systems. In most cases this is going to be SAP or Oracle (typically Peoplesoft). It makes sense of course. If a person is hired, the first place they appear is in the HR system. When they leave, they get taken out of HR. It is for this reason that Oracle wasted no time in closely integrating their IDM suite with their HR applications and also took the trouble to cross certify them.
If SAP is to become a serious IDM vendor and challenge the likes of IBM, Oracle, Sun, CA and BMC they need to start with their existing R/3 install base. This seems like a no-brainer. Sales 101. Go after the people you already have relationships with and up-sell your products. What they'll need to be able to do however, is convince the install base that SAP IDM is the way to go because of the tight coupling with R/3 right from the underlying technology through to the business processes. SAP will not beat the other vendors on functionality, at least not for now.
They've essentially bought a meta/virtual directory product with synchronisation capabilities and minimal provisioning functionality (MaXware) and another product to tie in compliance (Virsa). There isn't enough functionality to compete from a holistic standpoint. They will need to prove that they hook into the SAP platform better than anyone else out there (and they really should because it's their own software) and they will also need to sell customers on their commitment to an overall IDM strategy and then go out and buy companies to fill the gaps, of which there are many.
In short, SAP need to focus on 2 things before being able to be a serious threat in the IDM game:
- Integrate the current capabilities seamlessly into their application software stack and do it better than anyone else out there and sell customers on the fact that IDM should be driven by their existing SAP R/3 deployments.
- Fill out the big gaps in their IDM portfolio. There are many holes.
Managed Identity Services are a hard sell
I came across an announcement today where Wipro and Oracle have apparently partnered to offer customers Managed Identity Services and found it a rather curious move to make on Oracle's part. The only question I have for them is...why?!
I can understand Wipro wanting to explore the opportunities in Identity Management (IDM) outsourcing (they're an Indian company and are trying to get into IDM with a vengeance so it seems a logical move on their part), but Oracle doesn't need something like this. Why? Because they'll fail. The market is not ready for outsourced IDM and may never be. Most are still busy trying to work out their internal processes. Even the companies that have IDM software solutions are still working the kinks out of their processes.
The concept of outsourcing IDM has been around for a while. Access360 (now IBM Tivoli Identity Manager) explored the concept by designing their Enrole product to support the potential that someone might want to outsource their IDM. This feature got quietly thrown out not long after IBM acquired Access360. The reason (I'm guessing) is because there wasn't enough market demand for such a feature.
Think about it. If you outsource your IDM, you're outsourcing the keys to your kingdom. It's akin to giving someone the keys to your front door and asking them to decide who to let in and what they can do in your house. Are they really going to understand that the vase you have on the coffee table is an antique from the Ming dynasty and should under no circumstances be touched and that no kid under the age of 13 should go within 2 metres of it? You really have to trust your outsourcing provider not to screw things up because your business operations rely on the IDM infrastructure being there and functioning properly. Imagine if all of a sudden no one could change passwords or the authentication and access control mechanisms weren't working? Business would just stop.
What about the security implications and risks? Taking the house analogy further, outsourcing your IDM is like giving someone your keys and an inventory of all the things in your house and everything about what can be done to those things. This inventory will also contain the details of every inhabitant within your house or that has a right to visit your house. The keys and this inventory with all this private, sensitive information is now sitting in someone else's place. Sure they tell you it's "locked in a safe"...one which you've never actually seen and have no actual control over who can get to this safe. What assurances do you have that they have the right security measures in place to protect this safe? Or that they have the adequate screening processes to ensure that people that can get into this safe are trustworthy and will not compromise your keys and inventory? These security risks should be enough for an organisation to say "thanks but no thanks."
But if for some insane reason these risks are not compelling enough to say no, let's explore the other issues...
Take into account the experiences most people have in outsourced IT environments and it's not a pretty picture. I've been in enough outsourced accounts to know (and not just ones managed by IBM) that customers tend to be bitter about the outsourcing provider and cannot wait until the day the contract re-negotiations are due so they can throw them out of the account. In fact, I know of a few ex-customers of mine back in Australia that have done just that (some are big financial institutions so the size of the contracts are going to make a dent in someone's ledger). You throw in giving an outsourcing provider the responsibility to manage your IDM processes and infrastructure and it gets a whole lot more complicated.
Outsourcing IT operations is just that. You let someone else worry about where to put those Unix servers and how to connect those cables. You just need to know that there is a server room full of Unix servers that are guaranteed to be up 99.9999999% of the time and they run your business applications which just need to keep running (yes I'm over-simplifying, but you get what I mean). When you outsource a critical function like IDM, you are outsourcing a whole bunch of business processes that are very specific to your organisation and throwing into the mix a whole bunch of IT management issues. Add to that the political and cultural issues prevalent in all IDM projects (most will say this is the hardest part) and you've got a heck of a problem.
Yes people outsource business processes, but they are usually very standard, mature business functions like Payroll or HR. These don't get thrown into the IT management mix. IDM is like taking HR functions, "one-of-a-kind" custom business processes, all your people and all your IT systems and throwing these together into a mixing bowl and hoping you get a nice cake out of it. It usually takes a few attempts before you can even get a simple sponge cake. The first few attempts usually result in some inedible mess of a cake that you give to the dog to eat while you go try again. Problem with IDM is that there is no dog. You have to eat it yourself while trying to figure out why you've got dog food.
All the variables make IDM outsourcing destined to fail (for now). There are too many moving parts. Business processes are too specific to your organisation (e.g. every bank has different processes for the same thing). You're kidding yourself if you think you can make it someone else's problem just by outsourcing it. IDM will never be someone else's problem. It is always your own problem because you're managing YOUR users using YOUR business processes.
Wipro may be on to something because there's definitely a business opportunity for those not put off by the security risks. Who wouldn't want to make their IDM problems someone else's? But until the whole market works on standards and the solutions are commoditised, IDM outsourcing is just too difficult and is destined for failure.
Until IDM can be defined end-to-end as a set of standardised services from IT all they way through to business processes, you can't outsource your IDM with any level of confidence that it'll all hang together. Standardisation is only beginning with things like XACML, SAML, SPML, OpenID etc. But you can't escape the fact that these are technology focused standards. Real life use cases are not about technology.
When the day comes where all the underlying standards to support an IDM SOA infrastructure are there (and we're still working out the whole picture here), then we can start to get somewhere. And even then it'll still be difficult to make IDM someone else's problem. Sure, someone can probably host the stuff for you, but the business process issues are still going to be yours and you'll still need the technologists around to facilitate everything. The day when you can comfortably outsource all your IDM functions is the day where you are able to hire a bunch of business analysts to model and maintain your internal identity , access, security, audit and compliance related processes in an industry ratified and standardised fashion that can be sent straight to the IDM service and enforced with immediate effect. And this is ONLY after you can be assured that the sensitive data you are letting out of your environment is adequately protected.
I can understand Wipro wanting to explore the opportunities in Identity Management (IDM) outsourcing (they're an Indian company and are trying to get into IDM with a vengeance so it seems a logical move on their part), but Oracle doesn't need something like this. Why? Because they'll fail. The market is not ready for outsourced IDM and may never be. Most are still busy trying to work out their internal processes. Even the companies that have IDM software solutions are still working the kinks out of their processes.
The concept of outsourcing IDM has been around for a while. Access360 (now IBM Tivoli Identity Manager) explored the concept by designing their Enrole product to support the potential that someone might want to outsource their IDM. This feature got quietly thrown out not long after IBM acquired Access360. The reason (I'm guessing) is because there wasn't enough market demand for such a feature.
Think about it. If you outsource your IDM, you're outsourcing the keys to your kingdom. It's akin to giving someone the keys to your front door and asking them to decide who to let in and what they can do in your house. Are they really going to understand that the vase you have on the coffee table is an antique from the Ming dynasty and should under no circumstances be touched and that no kid under the age of 13 should go within 2 metres of it? You really have to trust your outsourcing provider not to screw things up because your business operations rely on the IDM infrastructure being there and functioning properly. Imagine if all of a sudden no one could change passwords or the authentication and access control mechanisms weren't working? Business would just stop.
What about the security implications and risks? Taking the house analogy further, outsourcing your IDM is like giving someone your keys and an inventory of all the things in your house and everything about what can be done to those things. This inventory will also contain the details of every inhabitant within your house or that has a right to visit your house. The keys and this inventory with all this private, sensitive information is now sitting in someone else's place. Sure they tell you it's "locked in a safe"...one which you've never actually seen and have no actual control over who can get to this safe. What assurances do you have that they have the right security measures in place to protect this safe? Or that they have the adequate screening processes to ensure that people that can get into this safe are trustworthy and will not compromise your keys and inventory? These security risks should be enough for an organisation to say "thanks but no thanks."
But if for some insane reason these risks are not compelling enough to say no, let's explore the other issues...
Take into account the experiences most people have in outsourced IT environments and it's not a pretty picture. I've been in enough outsourced accounts to know (and not just ones managed by IBM) that customers tend to be bitter about the outsourcing provider and cannot wait until the day the contract re-negotiations are due so they can throw them out of the account. In fact, I know of a few ex-customers of mine back in Australia that have done just that (some are big financial institutions so the size of the contracts are going to make a dent in someone's ledger). You throw in giving an outsourcing provider the responsibility to manage your IDM processes and infrastructure and it gets a whole lot more complicated.
Outsourcing IT operations is just that. You let someone else worry about where to put those Unix servers and how to connect those cables. You just need to know that there is a server room full of Unix servers that are guaranteed to be up 99.9999999% of the time and they run your business applications which just need to keep running (yes I'm over-simplifying, but you get what I mean). When you outsource a critical function like IDM, you are outsourcing a whole bunch of business processes that are very specific to your organisation and throwing into the mix a whole bunch of IT management issues. Add to that the political and cultural issues prevalent in all IDM projects (most will say this is the hardest part) and you've got a heck of a problem.
Yes people outsource business processes, but they are usually very standard, mature business functions like Payroll or HR. These don't get thrown into the IT management mix. IDM is like taking HR functions, "one-of-a-kind" custom business processes, all your people and all your IT systems and throwing these together into a mixing bowl and hoping you get a nice cake out of it. It usually takes a few attempts before you can even get a simple sponge cake. The first few attempts usually result in some inedible mess of a cake that you give to the dog to eat while you go try again. Problem with IDM is that there is no dog. You have to eat it yourself while trying to figure out why you've got dog food.
All the variables make IDM outsourcing destined to fail (for now). There are too many moving parts. Business processes are too specific to your organisation (e.g. every bank has different processes for the same thing). You're kidding yourself if you think you can make it someone else's problem just by outsourcing it. IDM will never be someone else's problem. It is always your own problem because you're managing YOUR users using YOUR business processes.
Wipro may be on to something because there's definitely a business opportunity for those not put off by the security risks. Who wouldn't want to make their IDM problems someone else's? But until the whole market works on standards and the solutions are commoditised, IDM outsourcing is just too difficult and is destined for failure.
Until IDM can be defined end-to-end as a set of standardised services from IT all they way through to business processes, you can't outsource your IDM with any level of confidence that it'll all hang together. Standardisation is only beginning with things like XACML, SAML, SPML, OpenID etc. But you can't escape the fact that these are technology focused standards. Real life use cases are not about technology.
When the day comes where all the underlying standards to support an IDM SOA infrastructure are there (and we're still working out the whole picture here), then we can start to get somewhere. And even then it'll still be difficult to make IDM someone else's problem. Sure, someone can probably host the stuff for you, but the business process issues are still going to be yours and you'll still need the technologists around to facilitate everything. The day when you can comfortably outsource all your IDM functions is the day where you are able to hire a bunch of business analysts to model and maintain your internal identity , access, security, audit and compliance related processes in an industry ratified and standardised fashion that can be sent straight to the IDM service and enforced with immediate effect. And this is ONLY after you can be assured that the sensitive data you are letting out of your environment is adequately protected.
In good company
The guys over at Securent have started a blog dedicated to discussion around entitlement management (EM). It'll be interesting to see what type of content gets posted on there and exactly how much discussion it will facilitate. They're off to a decent start I suppose, getting Gerry Gebel from the Burton Group to contribute. There's no real meaty content yet however. Securent CEO Rajiv Gupta's entry is the stock standard spiel about EM.
The only reason I found out about this site was through referrals to my blog. I'm starting to see traffic from www.entitlementblog.com and was wondering how in the world this was happening. So I checked it out and was surprised to see my name on the blogroll amongst some illustrious company.
I thought I should take a screen shot before they realise I'm not worthy of being amongst the names on that list :)
The only reason I found out about this site was through referrals to my blog. I'm starting to see traffic from www.entitlementblog.com and was wondering how in the world this was happening. So I checked it out and was surprised to see my name on the blogroll amongst some illustrious company.
I thought I should take a screen shot before they realise I'm not worthy of being amongst the names on that list :)
Subscribe to:
Posts (Atom)