Our last nine months of research into identity and access management have yielded quite a few surprises – for me at least. Many of these new perspectives I have shared piecemeal in various blogs, and others not. But it occurred to me today, as we start getting feedback from the dozen or so IAM practitioners we have asked to critique our Cloud IAM research, that some key themes have been lost in the overall complexity of the content. I want to highlight a few points that really hit home with me, and which I think are critical for security professionals in general to understand.

  • BYOD. MDM. MAM. That’s all BS. Mobile security is fundamentally an identity problem. Once you appreciate that a smartphone is essentially a multi-tenant smart card, you start to get a very different idea what mobile security will ultimately look like.
  • How very little IAM and security people – and their respective cultures – overlap. At the Cloud Identity summit last year, the security side was me, Gunnar, and I think one other person. The other side was 400 other IAM folks who had never been to RSA before. This year at the RSA Conference was the first time I saw so many dedicated identity folks. Sure RSA, CA, Oracle, and IBM have had offerings for years, but IAM is not front and center. These camps are going to merge … I smell a Venn diagram coming.
  • Identity is as glamorous as a sidewalk. Security has hackers, stolen bank accounts, ATM skimmers, crypto, scary foreign nationals, Lulz, APT, cyberwar, and stuff that makes it into movies. Identity has … give me a minute … thumbprint scanners? Anyone? Next time security complains about not having a “seat at the management table”, just be thankful you have C-level representation. I’m not aware of a C-level figure or Identity VP in any (consumer) firm.
  • Looking back at directory services models to distribute identity and provide central management … what crap. Any good software architect, even in the mid-90s, should have seen this as a myopic model for services. It’s not that LDAP isn’t a beautifully simplistic design – it’s the inflexible monolithic deployment model. And yet we glued on appendages to get SSO working, until cloud and mobile finally crushed it. We should be thankful for this.
  • Federation with mobile is disruptive. IT folks complain about the blurring of lines between personal and corporate data on smartphones. Now consider provisioning for customers as well as employees. In the same pool. Across web, mobile and in-house systems. Yeah, it’s like that.

On to the Summary:

Webcasts, Podcasts, Outside Writing, and Conferences

Favorite Securosis Posts

Other Securosis Posts

Favorite Outside Posts

Project Quant Posts

Top News and Posts

Blog Comment of the Week

This week’s best comment goes to Nate, in response to Who’s Responsible for Cloud Security?

I think the second quote here is a biggy. A lot of folks use the “address it in contract” line. I have to admit at first my thinking went along the lines of: “how is all this ‘cloud’ stuff really any different than application service providers?” For SaaS at least, it seemed like a fancy rename for an ASP. Now a cloud head would probably tear me up over how the difference is in the layers of abstraction and elasticity really running underneath, but I’ve seen plenty of things labeled ‘SaaS’ that are still just a couple web servers running some niche app. As a security guy the biggest difference turned out be the purchasing and contracting model. ASPs used to go through something resembling a real purchasing process with real contract negotiations. There was an opportunity to request specific evidence of security controls, and I’ve even done independent auditing and penetration testing of an ASPs wares. The legal folks also had an opportunity to be specific about damages. For many ‘cloud’ applications no such purchasing process exists. Someone is just slapping down a credit card and running. You get whatever documentation of controls and audit proof the provider feels like publicly disclosing and whatever damages are in their take it or leave it SLA. That means you have a lot less opportunity to shluff off responsibility by contract. Which isn’t necessarily a bad thing if the end result is more people being more responsible for their own data. It is very different though, and it means actually having to think about stuff…