Posts Tagged ‘authn’

#Identity as continuity. Thoughts inspired by #CISmcc.

I didn’t get to go to Cloud Identity Summit again this year. At least, not physically. I was there at a distance, attending via the very full twitter feed on #CISmcc. My experience was choppy. There were few slides. Ideas were filtered through the varied perspectives of the people tweeting. Then something odd happened in the middle of the whole experience. It changed the way I assimilated the ideas. Since attending at a distance also cuts off the nightlife, I spent the evening between the two major days of presentations knocking off a long standing item from my Netflix the man who is tall happy I watched a documentary based on conversations with Noam Chomsky called “Is the Man Who Is Tall Happy?” As always, listening to Chomsky talk linguistics and philosophy is a bit mind blowing. Then all these cascading connections began to form between the philosophical ideas and the identity ideas. That’s where the fun began. What struck me was a deep sense of irony. There is a stark contrast between the way ideas are progressing in identity and the advice contained in those ideas.

Walking into CIS, many were already primed with notions swarming around IRM (identity relationship management). That noise reached its pitch with Ian Glazer’s thoughts and the reaction to those thoughts (the links are only examples, there’s a ton more out there). Both implicitly and explicitly it felt like this debate was very present. Thoughts were flying by fast, but I sensed a tension that felt familiar. The notion that focus on relationship was paramount versus a focus on identities (or users) had a dynamic I recognized. It was only watching Chomsky that shook loose where I had felt that before.

At one point, the documentary talks about cognitive science. It treats the subject briefly. But I’ve studied it pretty deeply. That’s where the link is. There are schools of thought that focus on a homunculus based approach to mind, looking at the entities that make up thought mechanisms (e.g. brain cells, ideas). There are other schools of thought that focus on the connections (e.g. networks of neurons, or constellations of notions). I should say here that I know I’m slaughtering the heart of both of these schools of thought for the sake of brevity. Feel free to make me pay for it in the comments. But don’t think that will stop me now – in for a penny, in for a pound. This homunculus versus connectionism dynamic suddenly became very like the identity notions of user/identity centered versus relationship centered. The reasons I rejected the dichotomy of these cognitive science ideas began to seem relevant. The battle line between focus on the points versus focus on the lines that connect the points seems to be too artificial to me. In my mind, you only get realism with all of it included.

Imagine the difference between Abbott and Costello discussing the Middle East versus Mahmoud Abbas and John Kerry discussing the Middle East, or, if you prefer, the difference between Abbott and Costello doing “Who’s on first?” versus Mahmoud Abbas and John Kerry doing “Who’s on First?” Clearly, the people and their relationships both matter when you want a full understanding of how you should react to something. We can’t have a full understanding of how identity should react (in authentication, in authorization, in entitlement management) without understanding both the identity and the relationships in which that identity are currently involved. Both the current state of being and the current state of relationship of Abbas/Abbott and Kerry/Costello are informed – even formed – by the past states of being and the history of their relationships. To imagine understanding either the men or their relationships in some idealized, ahistorical setting is ridiculous. To me, it’s the same with identities and their relationships. It’s all or nothing. You need it all to answer the basic questions. Who’s on first? Exactly*.

I said there was a deep irony here. We need to go a level deeper to root it out.

By the way, if you want a bit more irony, you can go read about how Chomsky is actually a fan of discontinuity in the context of humans acquiring language while still maintaining the importance of continuity as a feature of how we conceptualize the world.

That artificial division of concepts, the burst and stop twitter feed, these discontinuities underlined another idea Chomsky brought into the discussion in the documentary: continuity. Continuity was discussed in many ways, but the basic idea was encapsulated in a children’s story. Sylvester the donkey becomes a rock, and then is turned back into a donkey later. Chomsky uses this to show how children don’t bind words and concepts tightly. If you ask a child if Sylvester is still a donkey, even when he’s been turned into a rock, they will say yes. The identity of Sylvester transcends his physical form. Chomsky calls this continuity. In the child’s mind, and I bet in most of ours, Sylvester is a being that is a donkey and having been turned into a rock doesn’t change that. The story’s dramatic tension is the contrast of form and identity. We’re happy when things are all right: Sylvester is again a donkey in form and identity.

I see continuity echoed in so many of the themes from CIS – and the wider identity threads with which we all weave our thoughts. My friend Nishant (if one can call a man who depicts you as a bizarre mix of Jedi and nun in front of large crowds a friend) raised the ever present specter of killing IAM, making the ultimate break in continuity. Bob Blakley (who gets a halo, not a habit, from Nishant) again pointed us to a future of continuous authentication. The heart of a dichotomy like IdM versus IRM suggests a lack of continuity. Make no mistake, the breaks in continuity also fit the trend. Chomsky brings up continuity specifically because so many people wish to set up a dualistic relationship between ideas labeled by words that map intimately to “real” objects in the “real” world. But, if Sylvester the “donkey” is still a “donkey” when he is a rock, that sort of dualism doesn’t fly. The map is in the mind and it’s drawn using the continuity we all sense. When we want to label things neatly, as we so often do in technical circles, we try to break the messy continuities that come naturally in a messy world. Identity is a messy business. Anything that attempts to sum identity up neatly must betray its core features. Sylvester is always a donkey because being a donkey is part of his identity. I am always Sander regardless of my company, my relationships to other people at given times, or the avatars with which I present myself to the world (habits and Jedi robes notwithstanding). We get so frustrated with these messy threads and the knots they tie us into that we want to burn the whole thing, kill IAM off in favor of a new shiny thing that will fix all the problems. Identity is an attempt to bind a narrative that spans a lifetime to single concept. That means we will have to deal with messy continuity, and all the things we killed trying to neaten up our ideas will rise up like zombies to join us again.

Continuity is a core feature of identity. The attributes, the relationships, the actions, the entitlements, the policies, the authentications have all been about something that has been a continuous thread. You can choose to describe it through the lens of its kinetic relationships and actions; you can choose to describe it through the lens of its associated attributes. The thing you describe remains the same. It’s the continuity of that thing which binds all those other concepts. This is where the irony sets in. As we try to capture this continuity over time, we try to break the threads, disrupt the stories. We worry about picking one of the two lenses, when we need both to correct our collective vision. We want to destroy what we’ve built to rid ourselves of the messy parts we didn’t like, but those are the parts that likely came closest to the essence of what we wanted to capture. “Things that let you do anything make it hard to do anything” said Ian from the stage. And I agree. Does that mean we look for a simple solution? What if we need to get close to that level of fluidity, that ability to do anything, to truly capture the kind of continuity that can let a rock be a donkey that’s physically a rock at the moment? If that sort of extreme continuity is a core feature of identity, then our identity management teapot needs to be strong enough to hold a tempest that strange. We can’t run away from the hard bits of our approaches to identity. Those may be the bits that are the best reflection of how hard it is.

This is not meant to be a Luddite’s cry. Bring on new standards. Bring on new ideas. Bring on new technologies. It is a word of caution. If our new ideas are simply about banishing the bits we didn’t like in the old ones, if we forego dealing with the messy continuity in identity or the complicated wisdom that may be buried in our old ideas, then we’re simply falling in love with novelty. We are hopping from one engineer’s honeymoon to the next. Here we find the deepest irony. It is ironic that we would take identity, which attempts to bind with continuity a myriad of disparate things, and attempt to break it up into neat pieces. The advice we scream at those building new systems is do not simply pick up the easy, familiar identity bits they know or fall in love with the novelty of a shiny new library. We tell them to consider the larger, likely messier whole. Use the standards even if that’s a bit harder for you right now. Take from the complicated (in appearance) fabric of identity that already exists in your organization or the wider web. Do it for the sake of continuity so you can reap the benefits later. It’s advice we should all keep in mind.

If you’ve read this far, then congratulations for navigating the deep waters of my odd mind! It’s taken over a week to get this out. If you think this was complex, you should ask for some of the notes.


This is linked to from above. It’s an entertaining side note from writing this I had to share. When I quoted “Who’s on first?” as saying “Who’s on first? Exactly.” I didn’t realize I was mixing up the actual script of “Who’s on first?”, where “exactly” never appears, with the lines from Purple Rain where they mimic “Who’s on First?” The funny synchronicity is that in Purple Rain the theme they use to mimic the routine is about remembering a password! Identity really is everywhere…

IdP risks, social engineering customer service, & Mat Honan

The blogosphere is on fire with tales of Mat Honan’s being hacked (does anyone say “blogosphere” anymore?). The source most seem to be pointing back to is Wired’s article. The best thing I’ve seen is my bud @NishantK‘s writeup where he breaks it all down. And I’m not just saying that because he points back to my own piece about IdPs and their risks relative to upcoming NSTIC style requirements. But that is part of why I’m writing this short piece. I won’t attempt to say again what others have no said very well about the #mathonenhack and what it means you should do (but I know I finally turned on Google two factor authentication – have you?). I would like to answer a question asked by Dave Kearns on twitter, though:

@dak3 question about IdP risk

@dak3 question about IdP risk

He was asking in the original context of the NSTIC comments. But I think it’s underlined by the eerie timing of discussing those risks and them watching this whole #mathonenhack play itself out in the media. In light of what happened and what it means for the risk and responsibility for an IdP, my answer stays the same. I don’t think NSTIC makes any IdP a bigger target then if they are already in the business of maintaining valuable assets for their own profit today. Later on, Dave also stated: “poor 3rd party IDP security practices means IT mgr (& CISOs) will draw the line.” There’s no doubt that there were some poor policies in place. And, as Nishant notes in his piece, Amazon and Apple have both changed some of that. But the key to making this happen comes down to the exploit of the brain of an Apple customer service rep when they decided that they would try to be helpful in the face of ambiguous results from their identity proofing procedures. Has that rep ever even been exposed to the concept of “identity proofing”? I can’t speak for Apple, but I’ve asked others and the answer has always been “no”. Apple in particular goes out of their way to be “friendly” when they can. Here it was used against them with terrible results. In the end, all the best process in the world can be exploited by getting to the right person and getting them to do the wrong thing for what they think is the right reason. At least, that will be true so long as we have people in the position to override our IAM systems.

Is the ID ecosystem #NSTIC wants too much risk for an IdP?

August 6, 2012 1 comment

I’m gearing up to go to the NSTIC convened steering group meeting in Chicago next week. Naturally, my inner nerd has me reviewing the founding documents, re-reading the NSTIC docs, and combing through the by laws that have been proposed (all fo which can be found here). I am also recalling all the conversations where NSTIC has come up. One trend emerges. Many people say they think the NSTIC identity provider responsibilities are too much risk for anyone to take on. With identity breaches so common now that only targets with star power make the news, there does seem to be some logic to that. If your firm was in the business of supplying government approved identities and you got hacked then you are in even hotter water, right?

The more it rolls around in my head, the more I think the answer is: not really. Let’s think about the types of organization that would get into this line of work. One that is often cited is a mobile phone provider. Another is a website with many members. One thing these two classes of organization – and most others I hear mentioned – have in common is that they are already taking on the risk of managing and owning identities for people. They already have the burden of the consequences in the case of a breach. Would having the government seal of approval make that any less or more risky? It’s hard to say at this stage, but I’m guessing not. It could lessen the impact in one sense because some of the “blame” would rub off on the certifying entity. “Yes, we got hacked – but we were totally up to the obviously flawed standard!” If people are using those credentials in many more places since NSTIC’s ID Ecosystem ushers in this era of interoperability (cue acoustic guitar playing kumbaya), then you could say the responsibility does increase because each breach is more damage. But the flipside of that is there will be more people watching, and part of what this should do is put in place better mechanisms for users to respond to that sort of thing. I hope this will not rely on users having to see some news about the breach and change a password as we see today.

This reminds me of conversations I have with clients and prospects about single sign on in the enterprise. An analogy, in the form of a question, a co-worker came up with is a good conversation piece: would you rather have a house with many poorly locked doors or one really strongly locked door? I like it because it does capture the spirit of the issues. Getting in one of the poorly locked doors may actually get you access to one of the more secure areas of the house behind one of the better locked doors because once you’re through one you may be able to more easily move around from the inside of the house. Some argue that with many doors there’s more work for the attacker. But the problem is that also means it’s more work for the user. They may end up just leaving all the doors unlocked rather than having to carry around that heavy keychain with all those keys and remember which is which. If they had only one door, they may even be willing to carry around two keys for that one door. And the user understands better that they are risking everything by not locking that one door versus having to train them that one of the ten doors they have to deal with is more important than the others. All of this is meant to say: having lots of passwords is really just a form of security through obscurity, and the one who you end up forcing to deal with that obscurity is the user. And we’ve seen how well they choose to deal with it. So it seems to me that less is more in this case. Less doors will mean more security. Mostly because the users will be more likely to participate.

SAML joins the IT zombie legions?

I’ve had the privilege to witness many IT funerals. By my reckoning, Mainframes, CORBA, PKI, AS400, NIS+, and countless others are all dead according to the experts. Of course, that means nearly every customer I talk with is overrun with zombies. Because these technologies are still very much alive, or at least undead, in their infrastructures. They are spending tons of money on them. They are maintaining specialized staff to deal with them. And, most importantly of all, they are still running revenue generating platforms on them. Now some of the the venerable folks speaking at CIS2012 want to count SAML among the undead. It’s a sign of the ever increasing pace of IT. SAML, if it’s dead, will be leaving a very handsome corpse. But I think it’s safe to say SAML will be with us for a very long time to come. This meme feels like another flashpoint in the tensions between thought leaders like the list of folks discussing this on twitter (myself included) and the practitioners who have to answer to all the folks in suits who just want to see their needs met. I try to split the difference. It seems to me that the only thing that makes something dead is when people are actively trying to get away from it because they are losing money on it. SAML is nowhere near that. But if dead is defined as not being a destination but rather a landmark in a receding landscape, then maybe it has died. But it’s chasing after us hungry for our budgets and offering being impervious to pain as a trade for that funding, which sounds like some kind of zombie to me. Using SAML will make you impervious to the pain of being so far ahead of the curve there is no good vendor support, impervious to the pain that there are not enough people with talent in your platform that you can’t get things done – or have to pay so much to get things done you may as well not do them, and impervious to the pain of being unable to get what you need done because there aren’t enough working examples of how to do it. Based on what i hear from practitioners, they may like being impervious to all those pains. So the IT zombie legions grow…

Categories: iam Tags: , , , , , ,

What I learned at @kuppingercole’s #EIC11: #identity #IAM #privacy and secrets

I must admit to being very selfish at this year’s EIC. Instead of going to the sessions that would likely have been most useful to Quest, I went to those that spoke most strongly to my own curiosities. The first thing I did was explore how vendors, users, and analysts feel about standards. It seems like it’s a chicken and egg subject – still. Users wait for vendors to adopt standards. Vendors wait for users and analysts to put force behind them. And in the mean time, only obvious success (SAML) and obvious need (XACML) seem to get standards investment and attention. The most interesting moment of this leg of the journey was when @OASISopen‘s Dr. Laurent Liscia asked from the keynote stage how many people in the audience were vendors to “make sure we’re not talking to ourselves.” Apparently we weren’t, but it was an interesting glimpse into how the whole notion is perceived even by those most dedicated to that cause of standards.

I also went to an absolutely fascinating deep dive into EU privacy and data protection law, which was hosted by Dr. Jörg Hladjk of Hunton & Williams LLP. Perhaps the most interesting thing I walked away with was a new sense of how fragile these protections really are. I think people in the US tend to think about these laws as being very intimidating and forceful. But that likely comes from the vastly complicated contract, audit, and procedure (paperwork) that is needed to deal with the laws. However, two shocking things became clear over the course of the day. First, any reasonable legal basis can be used as a basis to get at the data. A person can sign away all the protection in a single stroke – as anyone who agreed to the terms to get an iPhone in the EU has done in some part. And, because the framework is so much more comprehensive, things like a EULA, which is routinely cast aside in US cases since it’s seen as so flimsy, is much more forceful in the EU since the user is deemed to be so much better informed and protected by the framework. Second, there are cases where protections in the US are stronger than in the EU. A good example is when it comes to breech notification, where a data steward is forced to notify you of some event that may have compromised your PII. It seems that between NSTIC, efforts at the state level (like California’s new proposed “social media” law), and other things in the works, the US may actually come out ahead of the game in a practical sense within the decade.

The last lesson was a pleasant surprise: nearly all identity minded people are closet philosophers. Anyone reading this is likely to know my undergraduate (and only) degree is in philosophy, and perhaps also that I still indulge that impulse heavily as often as I can. Dr. Emilio Mordini, CEO of the Centre for Science, Society and Citizenship (CSSC), gave a keynote on the nature of secrets that was a HUGE hit. Not to say everyone agreed with all his views. In fact, @NishantK and @ggebel both took shots at his ideas from the same keynote stage later. The idea that drew the most criticism was Dr. Mordini’s very unpopular conclusion that one shouldn’t worry about securing data, but rather tracking data. He feels it’s less important to worry about keeping a secret than keeping track of who knows the secret. All of this flows from his central thesis that all secrets are Pulcinella secrets – not really secrets but rather, like a secret in a small town, something everyone knows but no one says so long as the parties involved have the power to motivate everyone to not say it in the town square. Tim Cole goes into all the details of the Pulcinella story on his own blog. The truth of all of it is left as an exercise for the reader. But the thing that made me happy was the abstract conversations in the hallways and bars for the rest of the conference as everyone digested the deeply interesting issues that were raised and what they meant in our shared context of identity, access, privacy, and technology.

Policy Translation – The Art of Access Control Transcends RBAC, ABAC, etc.

After some holidays, lots of internal meetings, and some insane travel schedules, things are settling back down this week just in time for me to head to TEC. So I can get back to spending time with Quest’s customers, partners, and having great discussions with people. In the last week, I had three excellent conversations, one with a panel of folks moderated by Martin Kuppinger from Kuppinger & Cole set up by ETM [link to podcast site], another with Don Jones and an audience of folks asking questions set up by [link to webcast], and the third just today with Randy Franklin Smith [link to webinar site]. All these discussions revolved around managing identity (of course); they focused on the business’s view of IAM, wrapping proper security controls around Active Directory, and controlling privileged user access, respectively. Even though the subjects seemed quite far apart, a common question emerged: how do you translate the policy the business has in mind (or the auditor has in mind) into something actionable which can be enforced through a technical control? Put another way, the problem is how to take wishes expressed in business terms and make the come true with technology. To me, this is the central question in the IAM world. We have many ways to enforce controls, many ways to create compound rules, many ways to record and manage policies. But the jump from a policy to a rule is the tricky bit.

Let’s take an example and see what we can do with it. Everyone in the US and many around the world know SOX, and most that know it are familiar with section 404. There is a great wikipedia article about SOX section 404 if you want to brush up. Section 404 makes the statement that it is “the responsibility of management for establishing and maintaining an adequate internal control structure and procedures for financial reporting.” While this makes sense, it’s hardly actionable. And businesses in the US have relied on many layers of committees and associations to distill this. What is that process? It’s lawyers and similarly minded folks figuring out what executives can be charged for if they don’t do things correctly in the face of vague statements like the one above. So they come up with less and less vague statements until they have something they feel is actionable. Of course, what they feel is actionable and what some specific IT department sees as actionable may be quite different.

From the filtering at the high levels of the interbusiness activities you get a statement like “Understand the flow of transactions, including IT aspects, sufficient enough to identify points at which a misstatement could arise,” which comes from the work done by the SEC and POCAB to interpret SOX section 404. That approaches something IT can dig into, but it’s hardly actionable as is. But now a business can take that, bring it inside the organization, and have their executive management and IT work out what it means to them. Of course, there are scads of consultancies, vendors, and others who would love to assist there. Your results may vary when it comes to those folks, or your own folks, being able to make these statements more or less actionable. With this specific statement about the “flow” of data and not allowing “misstatement” to arise, there is general agreement that having IT staff with administrative powers that could, in theory, alter financial data is a risk that needs to have a control. And from that general agreement has risen an entire market for privileged access management products that allow you to restrict people who need administrative rights to do operational tasks in IT infrastructure from using those rights to somehow change data that would be used in any kind of financial reporting (or use that access to do any number of other things covered by other sections of SOX or other regulations like PCI, etc.).

What should be apparent is that things like RBAC, ABAC, and rules based approaches to access control are all simple and straightforward when compared to taking policy and making it actionable. Putting an RBAC system into place is taking action. But, as anyone who has been through an RBAC roll out will tell you, the hardest bit is figuring out the roles. And figuring out the roles is all about interpreting policies. So what is the answer for all those folks on these webcasts who wanted to know how to master this art? The short answer is like the old joke about how you get to Carnegie Hall: practice. The medium length answer is to find a consultancy and a vendor that you trust and that have had the right amount of practice and make them do it for you. The long answer is to follow the path I took above trying to explain the question. You need to analyze the requirements, break them down, and keep doing that until you start getting statements that look slightly actionable. Of course, that takes a huge amount of resources, as evidenced by all the money that’s been spent on SOX alone in the US (that same wikipedia article quotes one study that says the cost may have been 1.7 trillion USD). And the final trick is to take your actions and breakdowns back to the top, your auditor or CISO or whomever started the chain, and validate them. That’s a step that gets skipped all too often. And then you see million dollar projects fail with one stroke of an auditor’s pen.

Identity Myth: SSO is Hard; Truth: Old Apps Suck

December 1, 2010 Leave a comment

I sat down with a very smart group of folks and they were saying how they think SSO is very, very hard. If your world is all Active Directory (AD), it’s easy. But that is true in a tiny percent of the world. Everywhere there is some odd ball application and in most places there are just as many applications not using AD as there are using it (even if they buy Quest solutions, sadly). The cloud, something everyone is forced to mention in every tech blog post, also complicates this. How do you do SSO when the identities aren’t under your control? Or, reverse that, how do you get SSO from your cloud vendor when your on premise applications aren’t under their control? But every time I have the SSO conversation at length with people the conclusion is always the same. If all you have are applications from the last 10 years and some cloud stuff, there are approaches, including Quest’s, that can fully solve that problem. You can integrate into your commodity AD authentication, put up SSO portals, or use widely adopted standards like SAML – or all of the above in a clever combination. Even thick client GUI applications can be tamed with enterprise SSO (ESSO) solutions at the desktop. The things that always end up falling through all the cracks are older applications. Things that are often the crown jewels of the business. Applications that are so old because they are so critical that no one can touch them without huge impact to the business. But the older technologies resist almost every attempt to bring them under control. Even ESSO, which is the catch all for so many other laggards, can’t tame many of the odd green screens, complex multi field authentications, or other odd things that some of these applications demand at the login event. When I’ve spoken to our SSO customers, they always seem happy with 70-80% adoption on their SSO projects. They know they will never get that last group until the applications change. But there doesn’t seem to be any compelling event for those applications to be changed. So SSO continues to seem hard, but we all know that’s not exactly true.

%d bloggers like this: