The Sad World of Passwords

Some commentary on John Fontana’s recent article on this topic. First, I wanted to give John some credit for saying (below) that the basic structure is to have a trusted identity provider but, as he states, there is still a single point of failure argument.

The very basic structure is to have a trusted identity provider (IdP) that vouches for you when other sites -known as relying parties - go looking for your authentication credentials. Nearly every site gets out of the password game - LinkedIn, eHarmony, Last.fm, etc. etc. and the number of IdPs shrinks to four or five major sites.

Yes, there is a single point of failure argument, but liability contracts are the incentives IdPs have to protect your data. Protecting your identity will be their core competency as opposed to holiday cheese balls and wrapping paper.

An interesting analogy of this was my drive into Seattle today. It’s June 26 and it’s 56F and raining. What a crappy day for summer. But, as I was crossing the 520 bridge, there was a mature bald eagle sitting on a light pole just above the road. What a sight to behold. Unfortunately, I think we are going to be in 56F and raining weather (passwords) for a while with the occasional bald eagle (IdP) seen in-use to brighten our day.

Secondly, I wanted to state that passwords aren’t dead. Until every IdP is SUPER EASY to install and operate passwords and password synchronization will live long into the future. And yes, there will ALWAYS be the potential for a single point of failure. How do you protect against that? Redundancy and protecting the keys to your kingdom with two-factor authentication (like Quest Defender).

And finally, let’s not forget that in order to use an IdP in this brave new world your application must be written to support (federated) claims. No re-write required for password synchronization or to continue to use in-app passwords.

I agree with John that it is time to change the movie but few seem to be ready to pay another admission charge. At least not at the moment.

Compliance and Office365

My fascination with compliance issues and Office365 is not abating. A few months ago I blogged about a data breach at the State of Utah. I was doing a bit more research about this breach and the fact that Utah’s Governor fired the State’s CIO over the breach and it got me thinking more specific to Office365: Is there a capability to enforce “at-rest” encryption of data stored in Office 365?

As far as I can tell from all the documents I’ve read there is no “at-rest” encryption of data except potentially within e-mail. I did download Microsoft’s “Security in Office 365” whitepaper and didn’t find anything that really addressed at-rest encryption but the whitepaper was written in June, 2011 so perhaps things have changed since then. Apparently you can copy RMS/IRM protected files to Office365 but that seems rather hackish and not subject to a general policy like “everything in Office 365 must be encrypted.”

So in a situation like what happened in Utah there’d be no difference if the data was stored in Office365.

More on this topic later – like maybe a punch list of what a customer might want for compliance.

Half our audit findings are identity related!

Last week I meet with a big bank in Manhattan. We spent a morning talking about privileged account management, identity and access management and what the bank was trying to achieve.

One of the most interesting data points they raised was that they have approximately 1,600 audit findings that they are working on. The most interesting point was that of the 1,600 approximately half of them were directly related to identity. The bank employs over 200 people who are responsible for cleaning up these audit findings so one could assume that there are 100 people or so working on the identity side of the audit issues. Another interesting tidbit was that this was pretty much in reactive mode related to the findings. They were trying to fix the findings but figuring out WHY something happened was extremely complex in their environment. Furthermore, after figuring out the why they then had to implement processes to ensure the problem was prevented in the future. Needless to say they are having some pretty difficult times coping with the problem.

Now obviously a large bank can’t be compared to what everyone else might experience but it does speak volumes about how much compliance is driving people crazy – and driving firms to spend big bucks to fix it. Imagine the cost of having 200 people doing nothing other than fixing compliance issues.

Also, not that I want to get into the fray with Nishant Kaushik and Kim Cameron on governance but I have to say, as Kim titles his blog entry: Governance is key. But, as Kim states:

they (identity and access management products) continued to require extensive manual intervention by security experts to coax ”compliant” behaviors out of them

I am going to be a more-than-just-interested party sitting at the sidelines watching how this develops. Office 365 is a great use case. It’s new and it’s not like Kim (and therefore Microsoft) don’t know the issues that companies like the bank I visited are facing.

How Microsoft solves this problem for Office 365 is going to be very, very, very interesting indeed.

Re-using Defender tokens

Great example of a customer that is re-using their Defender tokens. One of our guys stumbled across this sign while visiting them in their Manhattan offices. We don’t know if the customer is recycling their BlackBerry’s or…

I just returned from a few days in Manhattan and have a couple of additional posts I want to get out about my visit.

1. The high cost of compliance.

2. Re-engineering 10-year old Active Directory architectures.

Stay tuned.