Executive Advisory Program

IdM anyone? Anyone? Notes from RSA

Posted by Chris Howard

I have a new respect for my Identity, Privacy, Security, and Risk Management brethren. They get to come to San Francisco in a heatwave and banter about the state and future of security. This year I got to come with them, and it has been very enlightening.

As you can probably tell from my other posts, I try to find the big picture. Honestly, identity management, role management, and other arcane aspects of the security space can be a bit "cryptic". But lately, the relationship of these topics to larger-level issues has been coming into focus for me. What I've learned this week is that confusion is more common than not when it comes to Identity Management (IdM) initiatives within large enterprises.

I spent an intense day with our identity and privacy team harvesting through data gathered from their ongoing research on role management. Kevin Kampman, Ian Glazer, and I will be writing at length about these findings in the coming months.One thing that struck me as I stared at thousands of post-it notes is this: "No one really wants to own this." The technology guys want the business to take ownership, the business guys say, "no, this is a technology thing." This confusion about accountability makes it virtually impossible to formalize a system of roles and processes that actually works. Even though the tooling appears to be quite functional in support of IdM, it really doesn't matter. Until the enterprise determines ownership and authority, those tools may as well be Tinker Toys.

This is an uncomfortable truth, no surprise to IdM professionals, I'm sure. But the current economic situation is exacerbating the issue. Highly fluid workforces (i.e., people getting laid off) introduces risk to the organization if deprovisioning processes are broken. Provisioning and deprovisioning processes emerge from larger initiatives like Role and Entitlement Management that give the organization insight into who they have, what they do, what they access, and what they did.

As I ponder the research, another thing comes clear. The complexity that often kills IdM initiatives could be mitigated with effective data modeling. The nest of relationships binding users to roles and entitlements is not easy to grok, and starting to build bottom-up will only make the complexity more intransigent. And risk increases. Start with great data modeling, and the tools will be easier to apply. Also, you will have an artifact that your business partners can begin to understand.

The lack of ownership, IdM as a hot potato, stems from lack of insight and control. Data modeling of roles increases control and stabilizes the use of tools. Processes like deprovisioning then should become easier. Risk decreases. Easy, right?

Off to dinner now, to chew on these ideas some more.

Architecting for SaaS - Down with Federated Provisioning

Posted by Mike Rollings

I wanted to point out a recent post in the Identity Management and Privacy blog by Ian Glazer Down with federated provisioning. If you read my post The dynamic data center, the cloud, and stormy weather, I stated that the ability to realize a vision to move workloads wherever you want is dependent upon a number of other capabilities -- infrastructure abstraction, identity, architected solution patterns, mature provisioning, federation -- and their integration with application development and solution delivery.  Ian's recommendation is consistent with the type of change we need to make.

You can also see movement in the virtualization market to enable fluid movement of workloads if you read the various posts by Chris Wolf - most recently one about changes to licensing that remove some previous barriers Microsoft Licensing Revisions for Virtualization are Imminent.

Ian's recommendation to have SaaS vendors provide SPML interfaces to their applications is also consistent with the vision for a need to Eliminate Boundaries Created During the Pre-Industrial Age of IT. I discuss this in my Burton Group document Architecting for SaaS. I discuss that architectural principles have changed about the structure of applications and the associated infrastructure. In addition to Saas, the change was accelerated by other factors, including:

• Alterations in the way employees work and use social software
• Consumer comfort with pieces of applications available for Facebook, iPhones, and other environments where small applications are readily available
• The move to implement shared functionality as reusable services

I think user expectations for a fluid environment without distinction to it being externally or internally provided is accelerating. Along with this expectation, IT should change its expectations about how it manages a combined environment (e.g. SPML interfaces for SaaS).

If we really want to enable the fluid movement of workloads, the management of internal and external applications, and to combine internal and external functionaliy, we need applications to become virtual sets of policy-governed services instead of pure internal or external solution patterns. Business demands to combine internal and external services into applications transforms fundamental architectural principles that influence design. As a result, a different IT environment emerges to support a different meaning for “application” and the composition of virtual sets of policy-governed services.

Thanks to Ian and Chris for being part of this transformation!

Data Breach in the Locker Room

Posted by Chris Howard

When I was in Junior High, my friends and I went to band camp at Mount Allison University in New Brunswick every summer. I know, we were the band geeks, but we were tight. None of us was particularly athletic, but we had to take a mandatory phys-ed (PE) class every day. It still gives me a sinking feeling almost 30 years later.

Band camp also gave us a chance to practice our opposite-sex-relationship "chops". As a drummer, I hoped the cute flutist would notice how well I paraddidled. My friend Mark had an easier time: he was a trumpet player, tall, blonde, perpetually tanned, good looking, and acne-free. He confided in me about his band camp crush (at least on that day), and swore me to secrecy. Not a day later, I told someone his secret in the locker room at PE -- and here's the sinking feeling part -- while Mark stood behind me. I broke his trust. I was a schmuck. Silly as it sounds, that incident put up walls between us for a long time, at least until the next girl came along.

Now, outing someone's secret crush at band camp didn't really hurt anyone. But breakage of trust is primal. Consider recent breach news like that of Bank of NY Mellon, where lost tapes have led to the potential exposure of 12 million customer records. Whether or not the data gets used for malicious purposes, the cat is out of the bag. Once broken, trust is difficult to retrieve, especially when it involves risk to our money. But what are the options? The days of stuffing bills into matresses are (hopefully) over. The big safes in some branches are mostly symbolic. As financial instruments become increasingly virtual and complex, risk increases alongside benefits. Our wealth is primarily stored as 1's and 0's in seemingly permeable locations, and it appears that risk management practices are having trouble keeping up. Attrition goes right to the bottom line.

As Phil Schacter on my team wryly commented: It seems like a never ending stream of bad news... Maybe we should just assume that our identity data is out there, and put in place better controls so that it can't be used to harm us. Bob Blakley from our Identity and Privacy area is providing thought leadership on this topic, so keep your eyes on the identity blog for more information.

So, to conclude this quasi-confessional post: Sorry Mark, I spilled the beans. But I honestly don't remember the actual subject  (i.e. girl) of the secret. I do remember that it happened, and I still feel like a schmuck. Chances are you didn't trust me with other secrets, and I lost out on a deeper relationship as a result. Oh, and bank-of-mine, I'll be listening in the locker room, so keep your trap shut.

Who am I, and who are you?

Posted by Chris Howard

A former colleague, Wim Guerden, is fond of saying: "You know all about me, but I'm in control." It is a statement about how comfortable we are giving over information to a company (in Wim's case, he's usually talking about a bank), as long as we retain control of the information. This implies an underlying trust relationship. What does it mean to be in control? How much more complex is control when innovation reigns in the hands of sophisticated users? How do I know if I can trust? What is the right amount of information to expose in a given context?

The drive to place greater control in the user's hands is obvious in the consumer electronics space. But to be "in control" means to give the user better control over their data. That data may be spread across multiple providers, and some of it held solely by the user. Access to the data relies on strong identity management (IdM) strategies, but whose responsibility is IdM? A single enterprise may have an IdM strategy to cover users of its systems, but that may not suffice to support all end user scenarios. So, the question arises, should the enterprise even be in the IdM strategy business at all? Or should they focus on authentication and application of identity provided from an external trusted source?

A few weeks ago, I met with a senior architect from a European company over coffee in Amsterdam. I paraphrase, but his comment was: "IdM is a pain, and I shouldn't have to do it." He had more colorful things to say about Role Based Access Control (RBAC), but I'll come back to that another time. From there, the discussion branched into IdM in the "cloud", meaning that IdM would be accessible as a service and that the user (i.e. owner of the identity) is ultimately in control. That user could choose how and what to expose to trusted parties on the web in order to fulfill their cross-provider experience.

Bob Blakley, research director from our IdPS team, is writing extensively on a Relationship Layer for the Web (and enterprises too), recently concluding:

An identity is a model of a person. Only an organization which has a close relationship with an individual knows enough about that individual to build an identity which is an accurate model; the more intimate the relationship is, the more accurate the identity will be. Organizations have only casual relationships with most of the individuals they deal with, so they build inaccurate identities which create risks for individuals and for themselves. Building accurate identities on the Internet will require new relationship technology and a new set of intermediaries who have sufficiently intimate relationships with individuals to construct identities for them.

Like Jack (see this post, for example) , I am loathe to blithely toss things into the nebulous "cloud" because it is currently cool to do so. In conversation, the "cloud" can be a stand-in for the classic meeting "parking lot" where we dump things that we either don't want to discuss, haven't figured out, or don't want to waste any more time on. In fact, the "cloud" concept is (literally) drawn from software and network diagrams when we needed to represent something that happened (usually on the web), but we didn't want to specify the details. Perhaps we didn't know them.The cloud just magically did its work and handed us the results and life was good. (See the beautifully meaningless image here as an example.)

When it comes to identity in the cloud, we have to come to grips with ownership. If the user -- who is mobile and uses multiple applications that require identity -- is the  "system of record" for their identity, then it makes sense for identity management to fall outside enterprise walls. But, as Bob indicates, the mechanics and intermediaries to provide ubiquitous, external IdM facility need to be put in place. For related insights from Bob and his team, start here.