Identity is the New Currency

Text from my keynote talk at the Cloud Identity Summit. Photo credit (Brian Campbell)

1. Problem statement

We have some hard problems in IAM. I wonder if there is sometimes too much focus on the short term and not enough on the long term. And specifically not enough focus on the consequences of the consequences of bringing in a new technology or process.  

One kind of project I work on with companies is building out an IAM Roadmap. In my view, these have to looked at over a 3-5 year time frame . There is a lot to do. No one can predict the next 3-5 years, but its still worth taking a little time to make a long term directional strategy, and then carve up into smaller chunks that you can execute on. 

I worked on a project like this last year, we built out a mid-long term vision, we broke it down into iterations that we can build on quarter over quarter, year over year. With some sequencing and prioritization around all the standard SSO, Provisioning, ABAC and other initiatives. But then the client asked me a question which sent a chill down my spine - he said "who does this?" 

It hit me then that while companies spend six and seven figures on IAM, the do not have a VP for identity, they do not have an architect responsible for identity. We have a strategic problem that we try to tackle with incremental, tactical and outsourced "solutions"

What seems like the easy path often isn't. Patrick Harding said two years ago that passwords are the cheeseburgers of security. They taste great at the time, but eventually you have to get a colonscopy. Yet we still have passwords.  

I think cheeseburgers have a lot to teach us in building identity systems, but before I go into that I have a lesson from Mahogany Row

2. I have had some interesting experiences over the last couple of years with execs on mahogany row

In security we're used to horse trading - features and function versus security. 

Doesn't matter if its Amazon of Google or a big bank, this horse trading happens all the time. Its a passive aggressive game

It devolves to my VP beats your VP.

The developer VP beats the security VP

But one thing I have seen is that middle managers still play this game and security is actually winning some percentage of the time. Your CFO cares about security, so does your CEO. Let the passive aggressive, executive escalation game play out, put security concerns into business risk terms and see what happens. Your security VP may actually win more than they have in the past. 

But here is the next problem we have

3. Taking Yes for An Answer

Security and identity have lost so many battles (did I mentioned that we still have passords?), but if you step back from it, and look around, I think you'll see that we are "getting to yes" way more than we have in the past. Since I am security guy, I always have to ask "yeah but", is what we are doing going to change things for the better? Are we getting to solve the real problems in security and usability?

4. Identity is the New Currency

I would like to talk about identity as the new currency. Identity is currency, in the sense that it has intrinsic value and utility. That makes it valuable to consumers to businesses and, unfortunately, to criminals. Simply put, our job is to increase the value to consumers and businesses while at the same time reducing its value to the criminals. There is an inherent tension in these two goals. Its a dual use problem, what is good for users is mostly also good for criminals. That's where security architecture comes in - finding safeguards that can allow for the positive use case while limiting the impact of the negative case.

To serve consumers and businesses we increase flexibility, choice and integration, companies are valued based on the number and type of users that they have. A Facebook user in the developed world is worth $3.50 to an advertiser, in the emerging market economies its worth $0.50. So there's value associated with every account. However this extensibility and integration is quite useful to criminals as well. User accounts are bought and sold on the criminal black market. Safeguards are necessary to limit the utility of identity to criminals.

Identity strategy has mostly been about integration with the underlying assumption that this improves security. The case can be made this is often true in the short run.

But technology does not progress along a simple, smooth glide path. Too many twists and turns. The underpinnings of our assumptions change and so our architecture's efficacy changes. Advances in security architecture are liking pushing pawns around on a chessboard. They are only good insofar as the other player cannot identify and exploit the position's weakness.

Assumptions drive security. Mainframes were designed to serve large groups of users (employees) who were physically attached to terminals via their finger tips. they were employees and so the HR system had their record and their paychecks. One sunny day someone decided to put a MQ Series and a big honking Websphere instance in front of them and connect them to the web. Was the access control up to the task? Not by a long shot. It was designed to segment resources but not to deal with "external" users, much less propagate identity along the chain of responsibilities necessary to enforce access control in a distributed system.

We build our systems based on a set of assumptions, but successful systems live a long time and when the assumptions change so does our systems' efficacy. 

I mentioned that identity is the new currency, so let's examine some recent financial history. The crash of 2008, brought the global economy to its knees and we are still dealing with the aftershock to this day. The 2008 crash was brought on by many factors, and people can all choose their favorite whipping boy from the rogues' gallery - evil bankers, government policy, perverse incentives - but the active ingredient, the dry timber that allowed it to spread on such a massive, global scale was derivatives. We have had banking crises many times before, but not one that threatened to bring down the entire financial system. However this time was different and the reason was derivatives. 

Derivatives are an obligation, they are extended from one company to another company based on an agreement. Derivatives are a type of security that's exchanged the same way money is exchanged. There is a price and a value associated with each issue. Once they become accepted they become integrated into companies' balance sheet, cash flow and transactional processes - derivatives were treated no different from cash.

What we learned in 2008 is that while they were treated no different from cash, by those relying parties who accepted it; however they were in fact  quite different from cash. Creating the derivative security gave the illusion of cash-like qualities, but once it was accepted as cash and accounted for as such that's where the trouble began. That's when derivative was integrated into process and the assertion became in inarguable, unalloyed coin of the realm , not something like claim that should be "inherently in doubt" in Kim Cameron's wonderful, illustrative phrase. 

Let's go back a bit further, where did these derivatives come from. The story is very instructive. The very first derivative was created in the 1990s as a response to Exxon Valdez disaster. Exxon had a massive spill and a massive, pending liability. Exxon came to its banker, JP Morgan, with a call no banker wants to get - a request for an huge loan ($6 Billion) over a long duration. Exxon needed this to ringfence its obligations for spill damage claims. However, lIke any bank, JP Morgan did not want to carry an oil tanker sized liability on its balance sheet.

On the other hand, JP Morgan did not want to lose Exxon as a client, they were the bluest of blue chip, and JP Morgan didn't want them to go elsewhere. What to do? 

JP Morgan's team came up with an innovative solution. They gave Exxon the loan, then they chopped the loan up into smaller chunks and sold of pieces of the loan to other banks. The chopped up pieces were collateralized debt obligations (CDOs), derivative securities. This kept one of their most important client's happy by giving them the loan they needed. Other banks were only too happy to buy slices of Exxon's debt obligations because after all, they were Exxon, they were good for it. Derivatives played their role well. They moved trust and cash around in the system, from where it existed (the banks) to where it was needed (Exxon). It was win, win, win.

Now let's fast forward to a boiler room in 2007. housing loans with variable rate mortgages are being thrown at people who cannot make even the first payment. These loans are then chopped up and sold to other banks via CDOs, the same way as the Exxon loan was. One small difference though, the assumption as to the creditworthiness of original issue is 180 degrees different. 

Back in the 90s JP Morgan begrudgingly took on a loan from one of the most credit worthy businesses in the world. But by 2007, banks were using the same mechanism to forcefeed garbage loans to distinctly uncreditworthy individuals. 

The mechanism - CDO -  was the same, the CDO derivative structure was identical, but the system around it morphed. The up front proofing, quality checks and the acceptance were 180 degrees different.

What might we learn from this for identity architecture?

I can see a couple of things. We spend so much time on the identity standards - OAuth, SAML, and so on. Which one is live, which one is dead. The standard, though, is like the CDO derivative security, its only so useful. Much more important to the system as a whole is how its integrated.

its easy to imagine a widely integrated identity system with limited safe guards around it. A token structure that sends unsigned and unhashed identity tokens all over the internet to connect things. It works great until it doesn't. How do we avoid a catastrophic success? How do we not repeat derivatives in 2008?

Some things we do today

1. Up front integration 

Automated Provisioning

Stronger authentication

2. Backend integration

Force reauthentication

Integration to fine grained authorization

3. Keep malicious actors at bay

TLS/SSL

OAuth revocation

I would like to suggest that these and other areas get as much or more focus that we traditionally reserve for protocols and standard wars. The system is not governed by an identity token. Its a permutation that encompasses full lifecycle.

5. How well positioned are we for the next shift?

This conference is the Cloud Identity summit. But the Cloud is only one of the major movements in computing today. We have some excellent progress in Cloud identity. But what about Big Data? What about Mobile?

In practice, big data has next to no security. And mobile could in theory but again in practice mostly doesn't.

6. We still have more to learn from cheeseburgers

Two years ago, Patrick Harding said that passwords are the cheeseburgers of the internet. In the short run they taste great but in the long run you have to get a colonscopy. It was a good point then and now, and yet passwords live on. Still I think there is more that the identity community can learn from cheeseburgers. 

Five Guys is tremendously successful, their menu is dead simple. Cheeseburgers and fries. They have franchisees that beg them to add milkshakes to the menu, but they don't. The reason why is pretty interesting.

Five Guys' marketing budget is zero dollars and zero cents. Think about how many fast food ads you see on a daily basis for McDonald's or Burger King, but Five Guys has grown with a budget of nothing, nada, nyet. How do they get the word out to build such a successful franchise?

They rely on food critics. Go into any Five Guys and its covered in Zagat and every other  local and national write up. What does this have to do with a simple menu? Five Guys' founder, Jerry Murrell, explains that critics write about what they like. They also write about what they do NOT like. So the menu is designed to be operated by a 17 year old - simple, simple, simple. Has to be excellent every time. 

This is the same reason Five Guys does not offer coffee. People have begged for that too. Jerry Murrell asked a prescient question - have you ever had coffee made by a 17 year old? He ran a test. He made coffee left it out over night, heated it up the next day and served it to his sons, how did you like it? tastes great they said. Presto - still no coffee at FIve Guys.

It may seem far afield to think about cheeseburgers, milkshakes and coffee, but its anything but. We've all had great coffee and milkshakes but can you _operationalize_ it with your developers and operational team? Usability is much more than users, how easy it it to program? Most identity systems aren't

API Gateways are helping here, especially on provisioning. But how easy is to  debug? THis is often harder still

What about testing and verification? 

Do I hear crickets and curl scripts? Yes.

We need identity systems with better usability. Not just for users, but for developers who have to implement and test them. They need to be brain dead simple. 

In identity these days we are having to take yes for an answer. We have to mediate a dual use problem - we have something value, and its our job to make it successful for users and companies, limit its utility for criminals, today and tomorrow.

Comments

[Identity_guy]

Great preso Gunnar. It was pleasure to meet you yesterday at CIS.