1 Raindrop

The Road to the Security Cliff is Paved with Optionality

I have a regular blog on Dark Reading on Identity and Access Management topics. Three recent ones:

• The Reason the OWASP Top Ten Doesn't Change - turns out six of the OWASP Top Ten are identity and access failures, who knew?
• The Most Important IAM Question: Who Does This? A haunting question that most companies answer with ad hoc resources
• The Identity Cliff: kicking the can down the road on security works, until it doesn't.

The last one is really about how companies in general and security in particular look at hard choices around changing identity architecture as an optional thing, we'll get to it some year, but year after year the password crystal meth pipe is still getting passed around.

The can gets kicked down the road without major changes. 

 

On consulting projects, I am usually brought in on a specific area so its not a competitive bid situation, usually. But sometimes it is. In those cases, if I am bidding on a project of course I would like to win the bid, even though I don't always. But there are plenty of reasons why people would want to go another direction, they want the reassuring embrace of a large vendor (well at least til the invoice and end product come in), or there are other styles/processes/tools they might prefer. Plenty of legit reasons to shop other firms.

Every so often, I will do a bid and not get the project, and there is one type of this scenario that really bothers me. Some years ago, I put together a proposal for helping a company on security architecture, getting better tools and techniques to developers, improving identity architecture and so on. The proposal went in, weeks went by, they came back and said no project. I said no worries, I hope the company you went with does a great job for you. There was a long pause. That was when I realized, they were not going to do the project at all. They treated security and identity as optional and were wishing it would all just go away, and a magic pizza box would save them.

If an 81 year old can dance Gangnam style, you can change and grow your identity and security architecture too.

Security > 140 Conversation with Chuck Mortimore

Chuck Mortimore is Director of Product management for Identity & Security at Salesforce.com. His presentation at last year's Cloud Identity Summit was one of my favorite talks an in depth look at oauth and identity in the Cloud, I believe Eve Maler termed it "mind melting conceptual density." Chuck is presenting at this year's Cloud Identity Summit July 18-21 in Colorado. I will also be there doing a talk and a Cloud Security class, its a high point on the conference lineup.

For this Security > 140 conversation, Chuck and I discuss in some detail the architecture choices and constraints for people moving to the Cloud and what Salesforce.com, who I consider a leader in this space, has learned.

GP: One of the first times I worked on deploying SAML was at a Service Provider who had a large customer ask/tell them they had to support SSO via SAML. The SP was not a technology visionary, but they were good at listening to their customers. I have noticed that Salesforce continually has led the way for many Cloud and SaaS providers in identity options. How much is driven by your own tech arch vision and how much is driven by customers?

CM: It's about 50/50.   Customers tend to articulate pain, and high level direction.  For instance, our customers that have invested in federation consistently ask us to make single sign-on work with mobile and desktop clients.  The actual technology strategy to achieve that is then driven by us.   Inputs are a combination of our own deployments, understanding of our customer's IT landscape, and evolving best practice on the consumer web.  We're also willing to release capabilities and iterate on real feedback.

GP: It seems like SAML and oauth are two standards leading the way currently. Do you see this standards-based trend continuing?

CM: Yes – we see this continuing.   We’ve made great progress with Federation standards, and would like to see this trend continue into user provisioning, audit, etc.

GP: What's the likelihood of proprietary identity like Facebook, Apple, and others being used for certain use cases?

CM:  We’re pretty customer driven, so these Identity providers are important for consumer driven use-cases.   While we don’t have much demand for using these to login directly to our core products, our customers do want to source and maintain relationships with customers from these consumer IDPs.    As such, we increasingly integrate with these sources for CRM purposes.

GP: I remember in the 90s people used to call PERL the duct tape of the Internet. Now computing seems to be bifurcating into two modes humongous (Cloud) and tiny (Mobile); and identity is playing a key role, maybe the key role in linking these two models at runtime.  You recent Android oauth release is a good example of this. I was surprised that Google did not deliver any web identity model and just stopped at the OS level for security, its very good for the industry that your team filled this gap and published yoru work as open source for others to learn from. What design questions should mobile developers think about when integrating Mobile apps into Cloud providers?

CM:  We’ve been focused on a few key challenges with Mobile development

Time to value – we’ve been investing heavily in oauth and optimizing it for mobile experiences.   The mobile development experience is complicated enough on it’s own, and the last think developers want to worry about is first writing a bunch of authentication code before they can focus on their core application.    With oauth we’re trying to take care of all of that on the developer’s behalf – open up a web browser and wait for a callback.

How does mobile impact your traditional security posture – it’s pretty difficult to really know what applications you’re communicating with to any degree of certainty in a mobile environment.   That has ripple effects across traditional perimeter security postures with things like IP restrictions – you want to relax them to some decree for your mobile devices, but are you sure they really are your mobile devices. 

We’ve been working on activation and registration protocols to return some degree of control to our customer’s administrations and security staff while still dealing with the influx of consumer mobile devices into IT.

Credentials – a lot of our want to use their own credentials for usability, policy, and lifecycle management reasons, which generally leads to federation or delegation protocols being used.  At the same time these same customers are uncomfortable with that credential on mobile devices.    This is particularly challenging in the mobile and desktop space, as the well deployed federation protocols tend to use HTTP and web browsers as a substrate for moving messages around.   We’ve been investing a lot to weave together oauth and SAML, such that a single investment in federation can be used across a wide variety of device types.

GP:  So in weaving these together are you looking to the SAML Bearer Assertion Grant Type Profile to help solve some of this?

CM: We actually took a somewhat simpler route.    We have the customer get setup to support SP initiated SAML.   We then just treat the Oauth protocol flow like any other deeplink into our site.  If the user is un-authenticated, they go through SP Initiated SAML.   The Oauth protocol passes through RelayState and once we complete the SAML exchange, we pass them along to complete the Oauth flow.   Pretty straightforward.  Goal being federate once, and use the same pattern anywhere.   We actually can support using the same SAML assertions against our API endpoints as well.

GP: What's been the response from customers and developers on ease of use and implementation? Are the identity concepts easy to grok and something that they understand quickly or is  there a lot involved to go from standards, protocols and abstractions to a developer-friendly view?

CM: We’re still feeling this out.   The largest usability issue we have is that it requires connecting to a custom url for the customer, and we’re still working on the best model for users or their admins to easily express to the client the url they want to connect to.   So – conceptually it’s well received, but we’re still gaining experience on how best to scale the administration/deployment.

GP: What is your current guidance on protecting tokens once they are minted? It seems like the community would benefit from thinking about where the protocol security ends and where host/app security begins.

CM: In general, I try and simplify the language for people new to oauth.   Treat refresh_tokens like passwords, and access_tokens like sessions.   Use native mechanisms like iOS keychain where ever possible.

Its the Quality, Stupid

My friend Farhang Kassaei summarizes Ashish Jain's Paypal Identity Services talk. Farhang raises an important concern (emphasis added):

Too often people responsible for building an identity provider argue endlessly  about merits of protocols, compare OpenID to OAuth and talk about how complex SAML is. In the process they miss the much bigger point: what matters is the quality of identity provided not the means by which it is provided.

Who cares how its delivered if the payload is unreliable data? 

The reality is what's needed in computer security is not new standards - its better integration and engineering. What matters about, say SAML, is not digital signatures, message encryption, and so on. Those have been around for decades. What matters about SAML is that its better integrated to relying party code like webapps and Web services, and identity providers.

But even here this integration is the beginning not the end. The integration itself needs to be to something with reliable qualities. 

Let's take Kerberos, it was built up in the 80s, but as anyone who tried to deploy Kerberos in Unix environments in the 90s it took decades of engineering incremental improvements to get to now where Active Directory can be operated by non-guru IT folks. As much as the industry chases latest and greatest protocols and standards, without integration and engineering to authoritative IdPs and RPs, those dogs won't hunt.

Looking for a Web-time Consigliere to Avoid Creeping Security and Privacy Vulnerabilities

 There's an old saying that at any given time the current politicians are never so bad that if you live long you won't want to see them come back and replace the current crew. Likewise, in the 90s Microsoft was pretty universally viewed as about the biggest problem in security. Now we have web companies like Facebook and businesses that run web front ends like banks that are hosing consumers in ways Microsoft never did. (Note - just heard a great radio commercial for GoToMyPC - "Use GoToMyPC its just as safe as internet banking" couldn't have said it better myself! I guess it beats "GotoMyPC Considered Harmful" anyway).  

The latest abuse has been dealt to consumers via Google, Kim Cameron has a series of must read posts, that describe Google's willful violation of both the third (Law of justifiable parties) and fourth (Law of directed identity) Laws of Identity. In Misuse of network identifiers was done on purpose, Kim identifies some of the core issues:

Yet Google consciously decided to abscond with, tabulate and monetize the identities of our personal, business and home devices.  The identifiers are persistent and last for the lifetime of the devices.  Their collection, cataloging and use is, in my view, more dangerous than the payload data that was collected. Why? The payload data, though deeply personal, is transient and represents a single instant.  The identifiers are persistent, and the Street View WiFi plan was to use them for years.  

Let’s be clear:  Identity has as much to do with devices, software, services and organizations as with individuals.  And equally important, identity is about the relationships between these things.  In fact identity can only be adequately expressed through the relationships (some call it context).

When Google says, “MAC addresses are a simple hardware ID assigned by the manufacturer” and “We cannot identify an individual” using those “simple hardware IDs”,  it sounds like the devices found in your home and briefcase and pocket have nothing to do with you as a flesh and blood person.  Give me a break!  It reminds me of an old skit by “Beyond the Fringe” where a police inspector points out that “Once you have identified the criminal’s face, the criminal’s body is likely to be close by…”  Our identities and the identities of our devices are related, and understanding this relationship is essential to getting identity and privacy right.

One great thing about blogging is you find out when you haven’t been clear enough.  I hope I’m making progress in expressing the real issues here:  the collection of device identifiers was purposeful, and this represents precisely the kind of ”systemic privacy design flaw” to which Ben refers.  

It bothers me that this disturbing systemic privacy design flaw - for which there has been no apology - is being obscured through the widely publicized apology for a completely separate and apparently accidental sin.  

In contemporary networks, the hardware ID of the device is NOT intended to be a “universal identifier”.  It is intended to be a “unidirectional identifier” (see The Fourth Law) employed purely to map between a physical machine and a transient, local logical address.  Many people who read this blog understand why networking works this way.  In Street View WiFi, Google was consciously misusing this unidirectional identifier as a universal identifier, and misappropriating it by insinuating itself, as eavesdropper, into our network conversations.

Because of connectivity, poor engineering and just lots and lots of dollars, data and digits, I think we're at the beginning of any number of companies that are in a position to deal more harm to consumers' security and privacy than what people were worried that Microsoft would effect in the 90s. 

What's more worrying is that Microsoft for all its historical baggage operated under a microscope. Everyone was watching for them, waiting for them to pull some Dr. Evil move. They were called to account.

But go back 5 or 10 years, Facebook is treated as a place to store photos and hang out with friends. Google is a search engine and hey(!) they now have maps! You hang up a slogan like "Don't be Evil" or whatever and you get a free pass. Only later do people figure  what the problems are, the vulnerabilities creep in and by the time you realize they are there its too late - all your data, friends, MACs whatever are uploaded. With Microsoft in the 90s consumers were on guard, ready to deal with issues (even if they had minimal control), but in the Web we back into security and privacy problems, not realizing it.

I think you can look at what is happening and see that things have changed a lot on the Web, what got you here to this point is not what you need to get there going forward. We're sowing the seeds for an identity oil spill.

Remember when Michael Corleone dismissed Tom Hagen -"You're not a wartime consigliere, Tom. Things may get rough with the move we're trying." Expertise in one area don't necessarily carry over and can sometimes make things worse. Maybe its time to say to the various web platforms out there that are overstepping in harmful ways - "hey you were a great social networking site, search engine, whatever but you're not really a web-time consigliere. Things can get rough out there - and your promiscuous collection of context and data can come back to bite us."

Update 6/4: Google says they screwed up and will turn over intercepted data. They blamed a "rogue software engineer" for the issue.

Shipping News

I guess my all time favorite quote on software engineering would be, and no its not "build security in" but that's on the list, my favorite quote would be "real artists ship", so that makes this news courtesy Pamela Dingle, doubly disappointing:

Microsoft announced last Tuesday that CardSpace 2.0 beta would not be releasing at the same time as ADFS 2.0.  That fact may not have immediate significance to you, but it certainly does to me.  Microsoft, you’ve blown it.

On one hand, I’m immensely relieved. A premature release of CardSpace 2.0 would have removed personal card support from the desktop, meaning that CardSpace would have been relegated to nothing more than Home Realm discovery.

On the other hand…  We won’t know for sure until ADFS 2.0 ships, but from what I and other people have seen from the beta and release candidate versions, Microsoft has broken backward compatibility with CardSpace 1.0.  This means that unless Microsoft has taken recent steps to regress their information card issuance code, ADFS 2.0 will ship in information card limbo

Why is this a big deal? In a word: adoption.

But see, people were waiting.  Big companies, waiting to run information card pilots.  Governments, excited to use ADFS 2.0 to implement higher-assurance consumer identity projects.  There weren’t a huge number of interested parties, but dammit, they were BIG interested parties.  Those interested parties need a sustainable closed circle — a production server and a production client.   Not a production server that can only work with a client that “isn’t done yet”.

The Web is still waiting for the critical mass of players to work together. As Pamela says it creates an opportunity for small players to build shims, but I don't think anyone assumed there'd ever be just one vendor here, there would always be room for niche players to deliver an extra 10%, however it would have been excellent for Microsoft to ship an integrated solution to really get the party started.

Killer Identity App Unleashed in Cloud

Remember the 90s, when everyone was in search of the next killer app? Whatever happened to that? I guess it got replaced with lots of little microservices, all mashed up together; well anyhow I just found one-  PingConnect is game changer - sign on to Google Apps, Salesforce, Cisco Webex, Rearden, and a number of other SaaS vendors. Check the demo video and the data sheet. Given this level of integration, PingConnect lets us realize the promise of SAML and enables companies to get the benefits of SaaS and cloud.

I quite like Hoff and CSO Andy's A6 model which proposes a Security API for the cloud. One of the things I like about it is that the A6 model has identity as a first class citizen for security architecture in the Cloud. This avoids a trap that many security and application models fall into, thinking that identity can be dealt with later or even worse that our current username/password identity super soaker model (accounts/identity/secrets sprayed ever) can be reused again. The above diagram would feature a minimum of eight accounts and eight passwords, and likely much more to accomplish routine tasks. Does this seem like a scalable model to you? Does this seem like a good model to foster going forward?

To me, it seems like one that's more than ready to consign to the dustbins of history. Hey kids, gather around and let Grandpa tell you about the days when he had to sign on to eight systems with eight different passwords...

If we are going to get the benefits of the cloud we need to think different about identity, before you think you have a Cloud you better think about how you are mediating subjects and objects, and even more than thinking we need tools that enable it to work. Assertions are only good if they can be simply generated, communicated, and understood. This is integration engineering. PingConnect is a concrete step in the direction and has all the markings of a next killer app.

Prawo Jazdy

If you are looking at ways to propagate identity data in a distributed system, consider the mysterious case of Ireland's worst driver - Prawo Jazdy.

He had been wanted from counties Cork to Cavan after racking up scores of speeding tickets and parking fines.

However, each time the serial offender was stopped he managed to evade justice by giving a different address.

But then his cover was blown.

It was discovered that the man every member of the Irish police's rank and file had been looking for - a Mr Prawo Jazdy - wasn't exactly the sort of prized villain whose apprehension leads to an officer winning an award.

In fact he wasn't even human.

"Prawo Jazdy is actually the Polish for driving licence and not the first and surname on the licence," read a letter from June 2007 from an officer working within the Garda's traffic division.
...
"It is quite embarrassing to see that the system has created Prawo Jazdy as a person with over 50 identities."

Claims, even verified claims, need to be evaluated to be any good. They can never be better than your verification process, but they can be worse.

Free as in download it and read it

Good stuff - the Burton Group made Bob Blakley's Identity Relationship paper freely available. I posted my thoughts on it here.

Identity Relationships

First off, I am of the opinion that many of Infosec's ills begin and end with the failure to see relationships and instead pass off binary notions of secure/insecure with silver bullet "solutions". 

Phil Windley's interview with Bob Blakley on identity relationships describes some very important subtle differences in identity. The distinctions Bob describes are very valuable to unlock some ways we can differentiate identity, threat models, protections, and use cases. Hattip to Adam for pointing this out, here are my notes.

* Identity as a standalone artifact is unsatisfactory. Identity creates relationships. Hannaford, TJX, Heartland stored more data than they needed. When it was breached it created a set of business relationships for those companies. There is no free lunch.

* When we are talking about identity, we are talking about people not data or programs but people (note - one trick I have used several times in the past is when a programmer is taking a shortcut on a security design and says "X will be good enough" I then ask if we can test X using his SSN or bank number. This often produces a design change. If that doesn't work ask if you can use their Mom's SSN or bank number, you get the idea)

* Bob describes three types of identity relationships - 1) custodial for high value - like a banks' large customers, 2) contextual - for a specific use 3) transactional relationships - where you need a minimal data set to accomplish a specific often point in time task

As you can see with the above list of relationships when you confuse the storage, usage and security profile of these three types - i.e. aggregate as if you are custodial and then protect like its low value you get a bad business outcome. The job of security and identity architects then is to calibrate cost and effort versus the value created. This an extremely useful way to think about identity information because it leads to distinct actions and outcomes

 

To summarize, identity like security begins with knowing your assets. You can use Bob's categories as a way to think about and value your identities, then your job is to find countermeasures that are commensurate with your value and risk apetite. The classic anti pattern is mismatching weak controls as if you are only using a low value transactional identity but instead you are aggregating tons of high value custodial identity data in a CRM. 

Not Your Father's Data Breach

I am surprised this doesn't happen more often, or become public when it does happen, and I suspect it will:

Corporate custodians of confidential medical data should be closely monitoring events connected to a nightmarish computer security breach in the St. Louis region.

Express Scripts is one of the nation’s largest pharmacy benefits managers. The company, with headquarters in St. Louis County, handles approximately 500 million prescriptions per year for 50 million workers at 1,600 American companies. Early in October, it received an extortion letter, the details of which it released on Nov. 6.

The letter included personal information on about 75 Express Scripts clients — Social Security numbers, dates of birth and, in some cases, information about prescription medications. Whoever sent the letter demanded money from the company — the amount has not been disclosed — and threatened to use the Internet to reveal personal and medical information about millions of people if the demands were not met.

Last week, the criminal activity expanded: Express Scripts said that individual clients had received extortion letters directly.

Express Scripts is cooperating with the FBI in the case. It issued a statement saying it would not pay any extortion demands. The company is offering a $1 million reward for information leading to the arrest and conviction of the extortionist or extortionists.

Beyond the scale of the problem for Express Scripts — and the potential impact on the company is enormous — the issue extends well beyond the mounting concerns about identity theft, a phenomenon with which most people have become at least somewhat familiar.

The greater problem is the unique nature of personal medical records, the importance of moving to computerization of such records to improve health safety and reduce costs and the irreversibility of the damage people can suffer if confidential medical information becomes public. The stakes are so high that a federal law establishes strict standards for maintaining the privacy of medical information and stiff fines for failing to do so.

Medical records of all kinds — paper and, especially, electronic — must be protected with the most sophisticated kinds of security systems available, including backup protections and automatic alerts of security violations. Yet Express Scripts learned of this breach in the “worst way,” as InformationWeek.com security correspondent George Hulme put it in an online report: “via an extortion letter.”

The Express Scripts breach raises many questions for all elements of the health industry: hospitals, clinics and doctors’ practices, benefits management firms, insurance companies, pharmacies, employers and government agencies:
Are they using the most advanced information security technology possible? Do they minimize the amount of data they collect and keep it only as long as necessary? Do they have strict protocols governing access to personal and medical data — and systems to enforce those protocols? If criminals were to hack into their systems, how would the companies know? How soon? And are the systems capable of instantly cutting off illegal access as soon as a breach is discovered?

Confronted with a grave breach of electronic security, Express Scripts has responded by contacting law enforcement, establishing an informational website, offering a substantial reward and hiring a private consulting firm to help clients who have privacy concerns and investigate situations that “appear to be tied to identity theft” and provide “identity restoration services.” There is no question that the company is taking the situation extremely seriously.
Given the ongoing criminal situation, information about how Express Scripts’ data systems were compromised — and whether it could have been avoided — has yet to be disclosed. But the American people have the right to expect that their sensitive personal and medical information is zealously protected and kept secure — not only by Express Scripts but also by every person or company entrusted with it.

The reason I am surprised this doesn't happen more often is that many Fortune 500 companies have oceans and oceans of personal data. Almost the only companies that have even tried to get to a medium level assurance are financial companies, yet many of the other companies have as much or even more data, with lower assurance. All that was lacking in the mix was an incentive and a bit of creativity and risk taking by the bad guys.

I posted this to the security metrics list and Andy Jaquith quoted it in his great book Security Metrics:

"Customers and customer relationships...have tangible measurable value to businesses, and their value is much easier to communicate to those who fund projects. So in an enterprise risk management scenario, their vlaue informs the risk management process...[For example, consider] a farmer deciding which crop to grow. A farmer interested in short term profits may grow the same high yield crop every year, but over time this would burn the fields out. The long term focused farmer would rotate the crops and invest in things that build the value of the farm and soil over time. Investing in security on behalf of your customers is like this. The investment made in securing your customer's data build current and future value for them. Measuring the value of the customer and relationships helps to target where to allocate security resources."

Of course this is the opposite of how most organizations do risk management and security architecture, and now, the fields have turned brown.

I was teaching a training class on App Sec and someone asked how do you get developers to care about security. One technique I use when a developer is saying "well this is not great but its good enough to pass this sensitive data over the wire unencrypted or store it in the clear", I simply ask, "well can we use your Mom's SSN to test this then?" its works more often than you might think.

(Thanks to Chris for pointing me to this story)