I spent a number of years acting as a Line Manager for a team of Identity & Access Management specialists at a time when there was increasing focus on compliance controls within the organisation. Certifying that my employees only had the systems' access rights that they required for their job was a quarterly event to look forward to.
Being told that Joe Bloggs can access System X with a role of Developer might seem like sufficient information for me to testify that the this is appropriate, but I would have to have made an assumption that developer access on System X has been correctly configured by whomever configured the system. What would the impact be if the administrator of System X had inadvertently given superuser access to those users in the developer group?
Traditionally, we have merely accepted that assigning users to groups is enough to satisfy our legislative requirements. But this is not the case! We also need to attest that the lower level permissions have been configured appropriately.
So what if we could find a way to deliver the lower level permissions to the Line Manager during his quarterly certification? What if I could see that superuser access had been inadvertently granted to my set of developers on System X?
This raises another problem, though. Lower level permissions on various systems take the form of data values which may be meaningless in their own right and therefore not in a format that would allow a Line Manager to understand them. As an example, informing a Line Manager that their employee has access to a system which means they have been assigned the value of S to the attribute ACCESS_RIGHTS. What does S mean? Standard? Super? Something-Else?
So what if we could provide the details in a manner which is more meaningful for the Line Manager?
I've spent some time in the recent past working on a mechanism to augment these lower-level permissions to provisioning data in such a format, thus enhancing the attestation experience of access certifiers but also as a means of validating that systems have been configured properly (and, as a consequence, the ability to perform lower-level Segregation of Duties checking).
The result of this work has been documented by Alan Harrison and is now available on the Pirean website. The work shows how low-level attributes held in RACF can be presented in a meaningful way through the IBM Tivoli Identity Manager interface. The principles, however, can be applied to any credential storage mechanism.
How I wish I had had that ability when I was a Line Manager!
Sunday, March 14, 2010
Monday, March 08, 2010
ITIM Provisioning with SPML
I had an interesting day last week playing with IBM Tivoli Identity Manager and IBM Tivoli Directory Integrator. The brief was to send provisioning requests from ITIM via ITDI as SPML requests to a target credential store. Sounds easy, doesn't it?
SPML parsing support has been available within ITDI since v6.1.1 (Fix Pack 1) and dropping the openspml2-toolkit.jar into ITDI's JAR directory should've been enough for me to get motoring with the requirement. And there is a certain amount of truth in that statement in that it was easy to put together a Proof Of Concept showing an ITDI Assembly Line sending SPML formatted provisioning requests to a SPML listener.
That was fine until I elevated the Assembly Line into ITIM. Sending the AL to an ITDI RMI Dispatcher as part of an ITIM provisioning request has been a feature of the ITIM setup since its v4.6 days and there hasn't been any reason to suspect that ALs invoked via the dispatcher mechanism would behave any differently than ALs invoked from either the command line or through the ITDI GUI.
But there is...
Unfortunately, I had created an Assembly Line that was made up the following:
There's nothing wrong in what I did. I could've attached the SPML parser to the HTTP Client Connector, but I didn't. I wanted to build up my AL slowly and show what was happening during the SPML creation process.
The AL worked fine through the GUI. But it did not work when "dispatched" as it throw a nullPointerException during the attempt to call the parser. My RMI Dispatcher had all the required JARs at its disposal and the environment variables were identical to my GUI environment. I even tried to use the CSV parser rather than SPML (thinking that maybe a parser introduced as part of a Fix Pack may not have full support) but I got the same result.
If only I had attached the parser to my HTTP Client Connector because guess what? You guessed it. That worked! It seems that (in my environment) parser functions cannot be instantiated when the AL is invoked by the RMI Dispatcher. NOTE: I did upgrade my RMI Dispatcher code to the very latest version during my investigations.
So a note to all - Parser Functions may not behave as you expect when dispatched!
SPML parsing support has been available within ITDI since v6.1.1 (Fix Pack 1) and dropping the openspml2-toolkit.jar into ITDI's JAR directory should've been enough for me to get motoring with the requirement. And there is a certain amount of truth in that statement in that it was easy to put together a Proof Of Concept showing an ITDI Assembly Line sending SPML formatted provisioning requests to a SPML listener.
That was fine until I elevated the Assembly Line into ITIM. Sending the AL to an ITDI RMI Dispatcher as part of an ITIM provisioning request has been a feature of the ITIM setup since its v4.6 days and there hasn't been any reason to suspect that ALs invoked via the dispatcher mechanism would behave any differently than ALs invoked from either the command line or through the ITDI GUI.
But there is...
Unfortunately, I had created an Assembly Line that was made up the following:
- Parser Function (to parse my work entry into SPML format)
- HTTP Client Connector (to send my SPML formatted string to a SPML listener)
- Parse Function (to parse the response to my connector above)
There's nothing wrong in what I did. I could've attached the SPML parser to the HTTP Client Connector, but I didn't. I wanted to build up my AL slowly and show what was happening during the SPML creation process.
The AL worked fine through the GUI. But it did not work when "dispatched" as it throw a nullPointerException during the attempt to call the parser. My RMI Dispatcher had all the required JARs at its disposal and the environment variables were identical to my GUI environment. I even tried to use the CSV parser rather than SPML (thinking that maybe a parser introduced as part of a Fix Pack may not have full support) but I got the same result.
If only I had attached the parser to my HTTP Client Connector because guess what? You guessed it. That worked! It seems that (in my environment) parser functions cannot be instantiated when the AL is invoked by the RMI Dispatcher. NOTE: I did upgrade my RMI Dispatcher code to the very latest version during my investigations.
So a note to all - Parser Functions may not behave as you expect when dispatched!
Monday, February 22, 2010
No Matter How Diligent You Are...
Today, I got an email from a service provider I have only rarely used stating that they had been the victim of a successful hacking attempt. They reassured me that they didn't store any credit card details but I should change my password as soon as possible.
This is the second time this has happened in the past year and both sites are fairly insignificant in the grand scheme of things. They aren't, for example, financial services sites so I shouldn't panic unduly.
I have no changed my password on the offending website so all's well, right?
Wrong!
Whoever hacked this site may now have my name, address, email address and a password they know I have used in the past. Matching this password and email address may grant them access to other services I use online. That's not an unreasonable assumption on the part of the hacker, of course. How many people reuse their "favourite" password on each service they sign up to?
I think of myself as fairly diligent, though. I do have a "favourite" password. In fact, I have 3/4 "favourite" passwords! But NONE of them are used for my mission critical services: banking, being one!
However, I should now consider that one of my "favourite" passwords has been compromised and should be decommissioned. That now means I should take a look through my password safe and change the password on those services that make use of this now redundant password. What a pain!
The personal damage has been contained somewhat. My mission critical services are still safe. (In fact, I have no idea what the password is for these services and have no intention of ever "learning" what I have them set to!) If only everyone else behaved as responsibly. In fact, if only I behaved even more responsibly by having a separate password for every service I use!
My tips for the day, then, are:
This is the second time this has happened in the past year and both sites are fairly insignificant in the grand scheme of things. They aren't, for example, financial services sites so I shouldn't panic unduly.
I have no changed my password on the offending website so all's well, right?
Wrong!
Whoever hacked this site may now have my name, address, email address and a password they know I have used in the past. Matching this password and email address may grant them access to other services I use online. That's not an unreasonable assumption on the part of the hacker, of course. How many people reuse their "favourite" password on each service they sign up to?
I think of myself as fairly diligent, though. I do have a "favourite" password. In fact, I have 3/4 "favourite" passwords! But NONE of them are used for my mission critical services: banking, being one!
However, I should now consider that one of my "favourite" passwords has been compromised and should be decommissioned. That now means I should take a look through my password safe and change the password on those services that make use of this now redundant password. What a pain!
The personal damage has been contained somewhat. My mission critical services are still safe. (In fact, I have no idea what the password is for these services and have no intention of ever "learning" what I have them set to!) If only everyone else behaved as responsibly. In fact, if only I behaved even more responsibly by having a separate password for every service I use!
My tips for the day, then, are:
- Even if you have a high-quality password, always consider it vulnerable as you have no idea how your service provider stores your password
- Try to create a different password for each of the services that you use (and avoid prefixing or suffixing your "favourite" password with the service details - passw0rdebay and passw0rdfacebook are stupid passwords)
- If you still feel confident reusing your "favourite" password, avoid the temptation to use it for your banking services
- Re-evaluate what a mission-critical service is. Banking is definitely mission-critical, but your reputation is also critical and having your Facebook or Twitter accounts compromised because of a slack password policy isn't clever either
- Invest in a password management tool - even something as simple as Password Safe ought to do the trick and it is free!
Thursday, January 07, 2010
Y2K Memories
I remember what I was doing on January 31st, 1999. I'm sure a lot of people do but I bet not many were doing what I was doing because I was being sick!
I was supposed to be working that night. Sitting patiently waiting for the world to end as the Y2K bug bit hard. I was a mainframe developer back in those days but I worked on a fantastic banking platform that had been Y2K compliant since its inception in the early 1980s. I was supposed to sit in work as an insurance policy. As it turned out, there were no issues. Not one. Nothing. Nada. Zero. Zilch. But I missed even that because I was driven home by my manager because of my illness.
I was reminded of this event because my O2 Connection Manager software for mobile broadband stopped working this week. On attempting to start it up, it would immediately die with no real explanation as to why it was being so fussy about doing some work on my behalf.
Of course, this week is the first week of 2010. Setting my system clock back to some date/time in 2009 enabled the O2 Connection Manager software to initialise successfully. In effect, this is the same as the Y2K bug, except it is ten years late!
Clearing out all files under "Documents and Settings/All Users/Applicatoin Data/O2CM-CE/O2 Connection Manager" resolved the issue (after I had reset my system date, of course).
So it would seem that back in the 1980s, we had a clearer idea of how to build software fit for purpose and with a view that it would still be around 20 years later. These days, code is hacked into existence and wobbles at the first sign of any kind of change. How depressing.
I was supposed to be working that night. Sitting patiently waiting for the world to end as the Y2K bug bit hard. I was a mainframe developer back in those days but I worked on a fantastic banking platform that had been Y2K compliant since its inception in the early 1980s. I was supposed to sit in work as an insurance policy. As it turned out, there were no issues. Not one. Nothing. Nada. Zero. Zilch. But I missed even that because I was driven home by my manager because of my illness.
I was reminded of this event because my O2 Connection Manager software for mobile broadband stopped working this week. On attempting to start it up, it would immediately die with no real explanation as to why it was being so fussy about doing some work on my behalf.
Of course, this week is the first week of 2010. Setting my system clock back to some date/time in 2009 enabled the O2 Connection Manager software to initialise successfully. In effect, this is the same as the Y2K bug, except it is ten years late!
Clearing out all files under "Documents and Settings/All Users/Applicatoin Data/O2CM-CE/O2 Connection Manager" resolved the issue (after I had reset my system date, of course).
So it would seem that back in the 1980s, we had a clearer idea of how to build software fit for purpose and with a view that it would still be around 20 years later. These days, code is hacked into existence and wobbles at the first sign of any kind of change. How depressing.
Monday, January 04, 2010
Identity & Access Management Predictions For 2010
I should point out that I am not psychic. I haven't found a way to see into the future just yet. (If I had managed to do that, I'm quite sure I wouldn't be writing this article!)
Identity and Access Management has promised much in recent years and in the case of Identity Management, the promise has yet to be realised in a lot of deployments. I hear potential customers making claims that there has never been a successful identity management project and any organisation intent on attempting to realise the benefits of such a project are doomed.
Thankfully, I have been involved in many successful deployments that have realised some, if not all, of the anticipated benefits. The problems I've seen have typically been political issues rather than technical issues. Does that sound familiar?
It would seem to me that there is a disconnect between what technology can offer, what businesses can afford and the political will-power to ensure that an IAM programme will succeed. Which brings me on to my predictions...
1. Ding-Ding - Round 2
The early adopters of IDM technology went through the pain and heartache of spending big on new technology in an effort to leverage their legacy technology in the "always connected" world. Their 18 month programmes a number of years ago are probably starting to provide some benefit around about now and the political collateral required to leverage their infrastructure will be in place because it has become too darn expensive to rip out all that kit that was deployed all those years ago. In other words, the initial hype surrounding the technology that was followed by disillusionment is now starting to pay for itself.
The rotation of staff around the various enterprises that exist will ensure that every enterprise now has "someone" in their team who has been involved in a successful IDM deployment. These people will become crucial in pushing their new employers down the path of embracing IDM as a workable solution.
2. Risk
I'm on thin ice with this one but the days of locking down everything because a manual said it could be locked down are disappearing. We used to live in a world which had adopted the 80/20 rule. An 80% delivery rate on a project was usually enough to get businesses working effectively and the remaining 20% was usually too expensive and made a mockery of the original business case. I see those days returning. For example, a two-factor authentication system for high-net worth banking users or treasury departments may be a great idea bearing in mind the risk of a security breach for either user but such a system may not be necessary for the thousands of people who only have a few coppers in their deposit account.
The same rule can be applied within the enterprise as well. Do we want to lock-down our enterprise systems to the point where they become difficult to use? Do we want our users fed-up with the tedium of trying to do their job with a system that seems hell-bent on preventing them to do so?
IT Security professionals will finally find the word pragmatism in their dictionary and understand that they are there to help rather than hinder.
3. Personal Ownership
For many, the notion of an Identity Management System may seem crazy. Surely it is up to the individual to manage their identity properly rather than delegate such responsibility to a "system". 2010 will see IT users taking ownership of their identities (and not just those binary-speaking geeks we all like to poke fun at). Real people performing real duties in the real world will start to take more care of their online persona. Facebook and Twitter have become vital tools - they are no longer being used to merely jabber on about what was on television the previous night!
Most people are sensitive about how others perceive them. Now is the time to protect our online personae. It is time to manage our own identities.
4. Compliance
Enterprises need to demonstrate that they have control over their processes. In a nutshell, that seems to be what Sarbanes Oxley is all about. How an enterprise demonstrates their control, however, is up to the enterprise. Quill and Parchment record keeping may actually suffice.
There are tools available which can help an enterprise keep control over its systems. Identity Management systems typically look after the provisioning aspect of a system and can certainly be beneficial in achieving compliance. But what about those systems that aren't managed by such a clever tool? Log file scraping and database dumps can provide an auditor with the necessary data to determine how an application is being managed but unless she is super-human, she will need an analysis tool to help her make sense of the information.
Compliance has always been a tricky topic because there are legacy bespoke systems which contain data that nobody else on Earth could possibly understand. How do you build a tool capable of analysing information from every possible application without major customisation and significant up-front consultancy fee hell. How can "SOX IN A BOX" be achieved?
This year should see the major vendors of IDM solutions attempt to address this area.
5. The Cloud
I've written about "The Cloud" before and 2009 has already seen a quickening in pace of Cloud Services and IDM solutions specifically for The Cloud. I can see one or two niche players operating in the "IDM proxy" world being gobbled up by the big boys.
Until now, enterprises have attempted to manage access to The Cloud from within their perimeter. 2010 will see the start of a mirror-imaging of this approach, ie The Cloud will start to manage access within the enterprise.
Conclusion
The above five predictions are safe bets, to be honest. All of these things are already happening so I guess my predictions aren't really predictions. Maybe they are "realisations"? This year will be the year that the IT user base will become more aware of the above.
Identity and Access Management has promised much in recent years and in the case of Identity Management, the promise has yet to be realised in a lot of deployments. I hear potential customers making claims that there has never been a successful identity management project and any organisation intent on attempting to realise the benefits of such a project are doomed.
Thankfully, I have been involved in many successful deployments that have realised some, if not all, of the anticipated benefits. The problems I've seen have typically been political issues rather than technical issues. Does that sound familiar?
It would seem to me that there is a disconnect between what technology can offer, what businesses can afford and the political will-power to ensure that an IAM programme will succeed. Which brings me on to my predictions...
1. Ding-Ding - Round 2
The early adopters of IDM technology went through the pain and heartache of spending big on new technology in an effort to leverage their legacy technology in the "always connected" world. Their 18 month programmes a number of years ago are probably starting to provide some benefit around about now and the political collateral required to leverage their infrastructure will be in place because it has become too darn expensive to rip out all that kit that was deployed all those years ago. In other words, the initial hype surrounding the technology that was followed by disillusionment is now starting to pay for itself.
The rotation of staff around the various enterprises that exist will ensure that every enterprise now has "someone" in their team who has been involved in a successful IDM deployment. These people will become crucial in pushing their new employers down the path of embracing IDM as a workable solution.
2. Risk
I'm on thin ice with this one but the days of locking down everything because a manual said it could be locked down are disappearing. We used to live in a world which had adopted the 80/20 rule. An 80% delivery rate on a project was usually enough to get businesses working effectively and the remaining 20% was usually too expensive and made a mockery of the original business case. I see those days returning. For example, a two-factor authentication system for high-net worth banking users or treasury departments may be a great idea bearing in mind the risk of a security breach for either user but such a system may not be necessary for the thousands of people who only have a few coppers in their deposit account.
The same rule can be applied within the enterprise as well. Do we want to lock-down our enterprise systems to the point where they become difficult to use? Do we want our users fed-up with the tedium of trying to do their job with a system that seems hell-bent on preventing them to do so?
IT Security professionals will finally find the word pragmatism in their dictionary and understand that they are there to help rather than hinder.
3. Personal Ownership
For many, the notion of an Identity Management System may seem crazy. Surely it is up to the individual to manage their identity properly rather than delegate such responsibility to a "system". 2010 will see IT users taking ownership of their identities (and not just those binary-speaking geeks we all like to poke fun at). Real people performing real duties in the real world will start to take more care of their online persona. Facebook and Twitter have become vital tools - they are no longer being used to merely jabber on about what was on television the previous night!
Most people are sensitive about how others perceive them. Now is the time to protect our online personae. It is time to manage our own identities.
4. Compliance
Enterprises need to demonstrate that they have control over their processes. In a nutshell, that seems to be what Sarbanes Oxley is all about. How an enterprise demonstrates their control, however, is up to the enterprise. Quill and Parchment record keeping may actually suffice.
There are tools available which can help an enterprise keep control over its systems. Identity Management systems typically look after the provisioning aspect of a system and can certainly be beneficial in achieving compliance. But what about those systems that aren't managed by such a clever tool? Log file scraping and database dumps can provide an auditor with the necessary data to determine how an application is being managed but unless she is super-human, she will need an analysis tool to help her make sense of the information.
Compliance has always been a tricky topic because there are legacy bespoke systems which contain data that nobody else on Earth could possibly understand. How do you build a tool capable of analysing information from every possible application without major customisation and significant up-front consultancy fee hell. How can "SOX IN A BOX" be achieved?
This year should see the major vendors of IDM solutions attempt to address this area.
5. The Cloud
I've written about "The Cloud" before and 2009 has already seen a quickening in pace of Cloud Services and IDM solutions specifically for The Cloud. I can see one or two niche players operating in the "IDM proxy" world being gobbled up by the big boys.
Until now, enterprises have attempted to manage access to The Cloud from within their perimeter. 2010 will see the start of a mirror-imaging of this approach, ie The Cloud will start to manage access within the enterprise.
Conclusion
The above five predictions are safe bets, to be honest. All of these things are already happening so I guess my predictions aren't really predictions. Maybe they are "realisations"? This year will be the year that the IT user base will become more aware of the above.
Wednesday, December 02, 2009
The Power Of Twitter & God's IT Usage
When I posted my musings on "Identity & Access Management In The Cloud" the other day, I did something I don't normally do. I advertised the fact that I had posted something via Twitter.
Now, my blog is mainly a way of recording my own thoughts as I travel through space and time and I treat it like an online diary that I can look back on with fondness. I don't really expect anyone to read the stuff. I certainly don't expect anyone to agree with my thoughts. And the notion that people would even take the time to comment on the ramblings never entered my head. But then there was Twitter!
My "tweet" mentioned the words identity, access, management and cloud and seems to have been picked up by quite a large number of people - comparatively speaking! I had 3x more visitors in one day than I normally do in a month!
If anything, this turn of events impresses upon me the following:
Facebook & Twitter
There has been a lot of online discussions surrounding the management of identity with regards to online services such as Facebook & Twitter. While enterprises won't be too impressed with this notion, it is quite understandable that the likes of Facebook & Twitter could emerge as identity provider kings! I can't afford to have my Facebook account suspended and I certainly don't want my Twitter feed to suffer any kind of service interruption. As such, behaving appropriately when using these services is important to me. And, of course, because I'm a well behaved boy on these services, there's a good chance that they could be used to assert my identity quite faithfully.
Think about it. Would I be keen to authenticate myself to a dubious website using my reputable Facebook credentials? Reputation management, for me, is just as important as identity management (if not more so).
God
DISCLAIMER: If Pope Benedict and Richard Dawkins were lined up in the school playground pulling together their "gangs", I'd line up behind Dawkins. Sorry Benny.
Someone told me today that they doubted whether they would make it to heaven because they reckoned that God's choice of IT components would be akin to how government's go about their purchasing of IT components. It got me thinking...
And what about Dawkins? Presumably he would prefer to select IT services based on the survival of the fittest model?
I'm having a laugh, of course. But the selection of any IT component can't possibly be determined to be right or wrong based on the component itself. It can be determined to be right or wrong based on how it interacts with the user and other IT components but I can't tell you that Macs are better than PCs. I can't tell you that Apache HTTP Server is better than Sun's offering. I can't tell you that PHP is better than Python which is better than COBOL which is better than C#, etc.
And the point? Well, I was asked yesterday whether I could help a customer select a database vendor and the options were Oracle and IBM. My answer? Technically, I come from the "a DBMS is a DBMS". The real questions are:
Technically? Maybe I'm past caring. The "religious" questions are so much more important!
NOTE: The answer is DB2. No. Oracle. No. MySQL. Yeah. That's the one. Oh. Maybe not :-)
Now, my blog is mainly a way of recording my own thoughts as I travel through space and time and I treat it like an online diary that I can look back on with fondness. I don't really expect anyone to read the stuff. I certainly don't expect anyone to agree with my thoughts. And the notion that people would even take the time to comment on the ramblings never entered my head. But then there was Twitter!
My "tweet" mentioned the words identity, access, management and cloud and seems to have been picked up by quite a large number of people - comparatively speaking! I had 3x more visitors in one day than I normally do in a month!
If anything, this turn of events impresses upon me the following:
- People are interested in the Cloud
- People are interested in security when it comes to the Cloud
- If people are interested in what I have to say, I need to be very careful what I say!
Facebook & Twitter
There has been a lot of online discussions surrounding the management of identity with regards to online services such as Facebook & Twitter. While enterprises won't be too impressed with this notion, it is quite understandable that the likes of Facebook & Twitter could emerge as identity provider kings! I can't afford to have my Facebook account suspended and I certainly don't want my Twitter feed to suffer any kind of service interruption. As such, behaving appropriately when using these services is important to me. And, of course, because I'm a well behaved boy on these services, there's a good chance that they could be used to assert my identity quite faithfully.
Think about it. Would I be keen to authenticate myself to a dubious website using my reputable Facebook credentials? Reputation management, for me, is just as important as identity management (if not more so).
God
DISCLAIMER: If Pope Benedict and Richard Dawkins were lined up in the school playground pulling together their "gangs", I'd line up behind Dawkins. Sorry Benny.
Someone told me today that they doubted whether they would make it to heaven because they reckoned that God's choice of IT components would be akin to how government's go about their purchasing of IT components. It got me thinking...
- Would God choose Oracle, DB2, MS SQL Server or MySQL? Nobody ever got fired by buying IBM, but who could fire God?
- Would God choose Windows, AIX, Solaris or Linux for his servers?
- Would God go Mac?
- Would God deploy IIS or WebSphere?
- Would God embrace open-source?
And what about Dawkins? Presumably he would prefer to select IT services based on the survival of the fittest model?
I'm having a laugh, of course. But the selection of any IT component can't possibly be determined to be right or wrong based on the component itself. It can be determined to be right or wrong based on how it interacts with the user and other IT components but I can't tell you that Macs are better than PCs. I can't tell you that Apache HTTP Server is better than Sun's offering. I can't tell you that PHP is better than Python which is better than COBOL which is better than C#, etc.
And the point? Well, I was asked yesterday whether I could help a customer select a database vendor and the options were Oracle and IBM. My answer? Technically, I come from the "a DBMS is a DBMS". The real questions are:
- Do you have in-house skills in one of the technologies
- Do you have existing relationships with either vendor
- What is the cost to you - TCO-wise
Technically? Maybe I'm past caring. The "religious" questions are so much more important!
NOTE: The answer is DB2. No. Oracle. No. MySQL. Yeah. That's the one. Oh. Maybe not :-)
Monday, November 30, 2009
Identity & Access Management In The Cloud
Last week I was asked to give a presentation at the IBM Tivoli User Group on Identity & Access Management In The Cloud to IBM employees, IBM Business Partners and customers of IBM Tivoli Security products. I soon realised that my first problem was going to be defining The Cloud. Not everyone I spoke to in advance of the presentation knew what The Cloud was!
So What Is The Cloud?
The Cloud seems to be a term bandied about all too readily these days and for many people it merely represents everything that happens on the Internet. Others, however, are a little more strict with their definition:
Wikipedia, naturally, has its own definition.
Of course, there are different levels of computing that a provider in the Cloud can offer. The usage of a particular software application (eg Google Docs) is just one such offering. Another would be akin to a software development platform (think Google App Engine, Microsoft Azure and Salesforce's force.com). Then, of course, there are the raw infrastructure services - servers provisioned "on-tap" for end-user usage (eg Amazon Ec2).
We are probably all users of Cloud services if we think about it. A quick look inside my Password Safe vault reveals almost 300 different User ID & Password combinations for services on the net including:
While it is easy to see how personal usage of Cloud applications has grown over recent years, it may come more of a surprise to learn how the Enterprise is adopting Cloud usage.
According to EDL Consulting, 38% of enterprises will be using a SaaS based eMail service by December 2010. Incisive Media report that 12% of Financial Services firms have already adopted SaaS, mainly in the CRM, ERP & HR fields. And our friends at Gartner reckon that one-third of ALL new software will be delivered via the SaaS model by 2010.
My guess? SaaS is already happening in the enterprise. It's here and it's here to stay.
With any change to the enterprise operating model there will be implications - some real and, just as critical, some perceived.
In the Perceived Risks category, I'd place risks such as loss of control; storing business critical data in the Cloud; reliability of the Cloud provider; longevity of the Cloud provider. Of course, these are only perceived risks. Who is to say that storing business critical data in the Cloud is any less risky that storing in the enterprise's own data centre? There may be different attack vectors that need to be mitigated against, but that doesn't mean the data is any less secure, does it? And who says the enterprise has to lose control!
Real risks, however, would include things like the proliferation of employee identities across multiple providers; compliance to company policies; the new attack vectors (already described); privacy management; the legislative impact of data storage locations; and, of course, user management!
Cloud Standards
As with any new IT delivery methodology, a raft of "standards" seem to appear. This is great as long as there is wide-spread adoption of the standards and the big suppliers can settle on a specific standard. Thanks goodness for:
Access Control
And on that point, the various Cloud providers should be congratulated on their adoption of security federation. Security Assertion Markup Language (SAML) has been around for over 6 years now and is an excellent way of providing a Single Sign On solution across the enterprise firewall. OpenID, according to Kim Cameron, is now supported by 50,000 sites and 500 million people have an OpenID (even if the majority don't realise it!)
The problem, historically, has been the problem of identity ownership. All major providers want to be the Identity Provider in the "federation" and Relying Parties were few and far between. Thankfully, there has been a marked shift in this stance over the last 12 months (as Kim Cameron's figures support).
Then there are the "brokers". Those companies designed to make the "federation" process a lot less painful. The idea is that a single-authentication to the broker will allow wider access to the SaaS community, as such:
Symplified (http://www.symplified.com/) and Ping Identity (http://www.pingidentity.com/) seem to be the thought leaders in this space and their marketing blurb comes across as comprehensive and impressive. They certainly tick the boxes marked "Speed To Market" and "Usability" but again those perceived risks may be troublesome for the wary enterprise. The "Keys To The Kingdom" issue rears its ugly head once more!
Identity Management
SPML is to identity management as SAML is to access management. Right? Well, almost. Service Provisioning Markup Language (SPML) was first ratified in October 2003 with v2.0 ratified in April 2006. My guess? We need another round of ratification! Let's examine the evidence. Who is currently using it? A Google search returns precious little. Google Apps uses proprietary APIs. Salesforce uses proprietary APIs. Zoho uses proprietary APIs. What is the point of a standard if nobody uses it?
Compliance & Audit
Apparently, forty times more information will be generated during 2009 than during 2008 AND the "digital universe" will be ten times bigger in 2011 than it was in 2006! Those are staggering figures, aren't they? And the bulk of that data will be quite unstructured - like this blog or my tweets!
The need for auditing the information we put out into the digital universe is greater than ever but there is no standards based approach to Compliance & Audit in the Cloud!
Service Providers are the current custodians of the Compliance & Audit process and will likely continue to do so for the time being. Actually, the Service Providers are quite good at this as they already have to comply with many different regulations across many different legislative jurisdictions. Typically, however, they present Compliance & Audit dashboards tailored to vertical markets only.
It's understandable, I guess, that for a multi-tenancy service there will be complications separating out relevant data for the enterprise compliance check.
Moving To The Cloud
There are providers out there who claim to be capable of providing an Identity Management as a Service (IDaaS) which sounds great, doesn't it? Take away all that pain of delivering an enterprise robust IdM solution? In practice, however, it works well for enterprises who operate purely in the Cloud. These solutions already understand the provisioning requirements of the big SaaS operators. What they can't do quite as well, though, is the provisioning back into our enterprise systems! It's not enough to assume that an enterprise runs everything from their Active Directory instance, after all. Also, we have to remember that using an IDaaS is akin to giving away the "Keys To The Kingdom". Remember our perceived risks?
An alternative is to move the enterprise IdM solution into the Cloud. Existing installations of IBM Tivoli Identity Manager or Sun Identity Manager or {insert your favourite vendor here} Identity Manager could be moved to the cloud using the IaaS model - Amazon EC2. The investment in existing solutions would be retained with the added benefit of scalability, flexibility and cost-reduction. Is this a model that can be adopted easily? Most certainly, as long as the enterprise in question can get its head around the notion of moving the "Keys To The Kingdom" beyond its firewall.
Conclusion
The next generation of user is already web-aware - SaaS is here to stay - and SSO is finally within our grasp with only a handful of big players dragging their heels when it comes to implementing standards such as SAML v2.0. It was also intriguing to play with Chrome OS last week (albeit an early prototype version). Integrating desktop sign on with the web just tightens things that bit further (in a Google way, of course).
Provisioning (whether it is Just-In-Time or Pre-Populated) is still the pain-point. Nobody seems to be using SPML and proprietary APIs abound. Nailing this is going to be critical for mass adoption of SaaS solutions.
While Provisioning is the current pain-point, however, Governance, Risk & Compliance will be the next big-ticket agenda item. The lack of standards and proliferation of point solutions will surely start to hurt. Here, though, I run out of ideas.... for now. Seems to me that there is an opportunity for a thought leader in this space!
So What Is The Cloud?
The Cloud seems to be a term bandied about all too readily these days and for many people it merely represents everything that happens on the Internet. Others, however, are a little more strict with their definition:
"For me, cloud computing is a commercial extension of utility computing that enables scalable, elastic, highly available deployment of software applications while minimizing the level of detailed interaction with the underlying technology stack itself."
"Computing on tap - you get what you want literally from a socket in the wall."
"Cloud computing is just a virtual datacenter."
Wikipedia, naturally, has its own definition.
Cloud computing is Internet based development and use of computer technology. In concept, it is a paradigm shift whereby details are abstracted from the users who no longer need knowledge of, expertise in, or control over the technology infrastructure "in the cloud" that supports them.
Of course, there are different levels of computing that a provider in the Cloud can offer. The usage of a particular software application (eg Google Docs) is just one such offering. Another would be akin to a software development platform (think Google App Engine, Microsoft Azure and Salesforce's force.com). Then, of course, there are the raw infrastructure services - servers provisioned "on-tap" for end-user usage (eg Amazon Ec2).
- Blogger [blogging platforms]
- Twitter [divulging incoherent thoughts]
- Facebook [staying in touch]
- LinkedIn [professional networking]
- Google Docs [MS Office Alternative]
- Gmail [eMail]
- Screenr [screencasting]
- ChartGo [charting application]
While it is easy to see how personal usage of Cloud applications has grown over recent years, it may come more of a surprise to learn how the Enterprise is adopting Cloud usage.
According to EDL Consulting, 38% of enterprises will be using a SaaS based eMail service by December 2010. Incisive Media report that 12% of Financial Services firms have already adopted SaaS, mainly in the CRM, ERP & HR fields. And our friends at Gartner reckon that one-third of ALL new software will be delivered via the SaaS model by 2010.
My guess? SaaS is already happening in the enterprise. It's here and it's here to stay.
With any change to the enterprise operating model there will be implications - some real and, just as critical, some perceived.
In the Perceived Risks category, I'd place risks such as loss of control; storing business critical data in the Cloud; reliability of the Cloud provider; longevity of the Cloud provider. Of course, these are only perceived risks. Who is to say that storing business critical data in the Cloud is any less risky that storing in the enterprise's own data centre? There may be different attack vectors that need to be mitigated against, but that doesn't mean the data is any less secure, does it? And who says the enterprise has to lose control!
Real risks, however, would include things like the proliferation of employee identities across multiple providers; compliance to company policies; the new attack vectors (already described); privacy management; the legislative impact of data storage locations; and, of course, user management!
Cloud Standards
As with any new IT delivery methodology, a raft of "standards" seem to appear. This is great as long as there is wide-spread adoption of the standards and the big suppliers can settle on a specific standard. Thanks goodness for:
- The Open Cloud Manifesto (http://www.opencloudmanifesto.org/)
- The Cloud Security Alliance (http://www.cloudsecurityalliance.org/)
Access Control
And on that point, the various Cloud providers should be congratulated on their adoption of security federation. Security Assertion Markup Language (SAML) has been around for over 6 years now and is an excellent way of providing a Single Sign On solution across the enterprise firewall. OpenID, according to Kim Cameron, is now supported by 50,000 sites and 500 million people have an OpenID (even if the majority don't realise it!)
The problem, historically, has been the problem of identity ownership. All major providers want to be the Identity Provider in the "federation" and Relying Parties were few and far between. Thankfully, there has been a marked shift in this stance over the last 12 months (as Kim Cameron's figures support).
Then there are the "brokers". Those companies designed to make the "federation" process a lot less painful. The idea is that a single-authentication to the broker will allow wider access to the SaaS community, as such:
Symplified (http://www.symplified.com/) and Ping Identity (http://www.pingidentity.com/) seem to be the thought leaders in this space and their marketing blurb comes across as comprehensive and impressive. They certainly tick the boxes marked "Speed To Market" and "Usability" but again those perceived risks may be troublesome for the wary enterprise. The "Keys To The Kingdom" issue rears its ugly head once more!
Identity Management
SPML is to identity management as SAML is to access management. Right? Well, almost. Service Provisioning Markup Language (SPML) was first ratified in October 2003 with v2.0 ratified in April 2006. My guess? We need another round of ratification! Let's examine the evidence. Who is currently using it? A Google search returns precious little. Google Apps uses proprietary APIs. Salesforce uses proprietary APIs. Zoho uses proprietary APIs. What is the point of a standard if nobody uses it?
Compliance & Audit
Apparently, forty times more information will be generated during 2009 than during 2008 AND the "digital universe" will be ten times bigger in 2011 than it was in 2006! Those are staggering figures, aren't they? And the bulk of that data will be quite unstructured - like this blog or my tweets!
The need for auditing the information we put out into the digital universe is greater than ever but there is no standards based approach to Compliance & Audit in the Cloud!
Service Providers are the current custodians of the Compliance & Audit process and will likely continue to do so for the time being. Actually, the Service Providers are quite good at this as they already have to comply with many different regulations across many different legislative jurisdictions. Typically, however, they present Compliance & Audit dashboards tailored to vertical markets only.
It's understandable, I guess, that for a multi-tenancy service there will be complications separating out relevant data for the enterprise compliance check.
Moving To The Cloud
There are providers out there who claim to be capable of providing an Identity Management as a Service (IDaaS) which sounds great, doesn't it? Take away all that pain of delivering an enterprise robust IdM solution? In practice, however, it works well for enterprises who operate purely in the Cloud. These solutions already understand the provisioning requirements of the big SaaS operators. What they can't do quite as well, though, is the provisioning back into our enterprise systems! It's not enough to assume that an enterprise runs everything from their Active Directory instance, after all. Also, we have to remember that using an IDaaS is akin to giving away the "Keys To The Kingdom". Remember our perceived risks?
An alternative is to move the enterprise IdM solution into the Cloud. Existing installations of IBM Tivoli Identity Manager or Sun Identity Manager or {insert your favourite vendor here} Identity Manager could be moved to the cloud using the IaaS model - Amazon EC2. The investment in existing solutions would be retained with the added benefit of scalability, flexibility and cost-reduction. Is this a model that can be adopted easily? Most certainly, as long as the enterprise in question can get its head around the notion of moving the "Keys To The Kingdom" beyond its firewall.
Conclusion
The next generation of user is already web-aware - SaaS is here to stay - and SSO is finally within our grasp with only a handful of big players dragging their heels when it comes to implementing standards such as SAML v2.0. It was also intriguing to play with Chrome OS last week (albeit an early prototype version). Integrating desktop sign on with the web just tightens things that bit further (in a Google way, of course).
Provisioning (whether it is Just-In-Time or Pre-Populated) is still the pain-point. Nobody seems to be using SPML and proprietary APIs abound. Nailing this is going to be critical for mass adoption of SaaS solutions.
While Provisioning is the current pain-point, however, Governance, Risk & Compliance will be the next big-ticket agenda item. The lack of standards and proliferation of point solutions will surely start to hurt. Here, though, I run out of ideas.... for now. Seems to me that there is an opportunity for a thought leader in this space!
Subscribe to:
Posts (Atom)