Posted 9:41 AM (1) comments

Will NSTIC stick it to us?

My colleague, Craig Burton recently blogged about the five pilot projects to be funded via the NSTIC (National Strategy for Trusted Identities in Cyberspace) initiative from the US National Institute of Standards and technology (NIST). While Craig covered the announcement very well, I'd like to take a closer look at the groups getting the grants.

I'm a member of the Identity Ecosystem Steering Group (IdESG) also set up by NIST to help create a trust framework for NSTIC. Many of the members of IdESG were surprised that the pilot projects were to  be started before we had defined a framework. Even more, they were thunderstruck that there was no requirement for IdESG to oversee or contribute to the pilots.

According to Jeremy Grant (in the press release for the pilot projects), senior executive advisor for identity management and head of the NSTIC National Program Office, which is led by NIST: “By clearly aligning with core NSTIC guiding principles and directly addressing known barriers to the adoption of the Identity Ecosystem, the pilot projects will both promote innovation in online identity management and inform the important work of the Identity Ecosystem Steering Group.”

Yes, they will "inform" the work of the IdESG. Which, of course, means absolutely nothing.

Now, according to the mission statement on the IdESG web site: "The Mission of the Steering Group shall be to govern and administer the Identity Ecosystem Framework". To mean, that means that the IdESG should be overseeing the implementation of the pilot projects to ensure that they embody the guiding principles of the Identity Ecosystem which the IdESG is creating. We'll probably discuss this more when the IdESG meets in October.

The second point I wish to make is that the five grantees for the pilot project could all be labeled "Beltway insiders". While they do involve partners from the commercial world, this is what they do all the time in selling "solutions" to government and quasi-government organizations. Add to that the group hired by NIST to be the secretariat for IdESG (Trusted Federal Systems, Inc., a "systems integrator serving the federal government") and we can identify part of the problem - government regulators are most comfortable talking to former government regulators. The five grantees are:

Criterion Systems - a "systems integrator that delivers innovative, technology-enabled business solutions for government agencies to leverage existing and new technology, protect infrastructure and share secure information."

Daon - "provides software and services to governments and organizations to assist them in managing the identities of their citizens, customers or employees. "

Resilient  Networks - "Resilient’s partners are using the Trust Network to deliver innovative solutions in a variety of industries including healthcare, media, information security, government and financial services."

University Corporation for Advanced Internet Development -  "Internet2 is an advanced technology community, owned and led by the U.S. research and education community"

American Association of Motor Vehicle Administrators -  the name says it all.

Only Resilient Networks could really qualify as a "vendor in the marketplace" rather than a grant chasing, GSA-scheduled quasi-government agency. And their customers are the quasi-government agencies!

There's a fair bit of disappointment with these choices, especially among the consumer representatives and the traditional identity community. The October meeting could be very interesting.

Posted 6:56 AM (0) comments

It's not about data

Making the rounds of identity and security blogs and tweets is the news that a repository of all credit card PIN codes had been leaked. My friend Mark Dixon posted a selection of them. The joke is, of course, that the list is every four digit number from 0000 to 9999. The punch line urges you to go out and change your PIN right away.

I've no proof, but think this was suggested by the recent breach at Yahoo! According to a story in the Washington Post, the usernames and passwords of over 400,000 accounts were taken by a hacking group recently. Incredibly, the file was stored in clear text!

But what was mostly overlooked by the press was that there was little, if any, chance of damage from this breach. The malefactors  had stolen data, true, but they hadn't stolen information.

A list of passwords, like a list of PINS, is data but really only useful as the basis of a dictionary attack on an account. Does it improve a hacker's chance of accessing your account? Only if your unique or obscure password is in the list - and the thief can guess your account name.

Put together the password with the account name, though, and you have information. And information is always useful. A list of telephone numbers is data. List the numbers with the address associated with them and you've got information. A list of women's maiden names is data. Put it together with their children's names and it's information.

Even a list of persons' names and the a password they use is data, good data but just data. Add the company they work for and you might have information - if you can discover the email address template for that company, for example, or the account name template (e.g., first initial + first 7 letters of last name). That information isn't an automatic entree into the account but it gives the experienced cracker enough to be getting on with - much more so than the data alone.

Don't worry so much about losing data, but be scared to death of leaking information.

Posted 7:44 AM (0) comments

Hacker pwns Apple and Amazon

WIRED journalist Mat Honan suffered the hack heard round the world last week. My friend, Identropy's Nishant Kaushik wrote up an excellent summary of what occurred, why it occurred and what steps 3rd parties (like Apple & Amazon) have taken to prevent a recurrence as well as ways you can combat such an occurrence.

As I said, it's an excellent piece, with only one or two minor flaws but flaws that need to be discussed and, hopefully, corrected.

As part of the remediation, Nishant says:

"Nonetheless, every business dealing with identity management of customers in any way needs to review their model, and if they can’t externalize identity by allowing customers to Bring Your Own Identity, then they need to review their processes and put much better controls in place than those demonstrated by Apple and Amazon in this case."

But the complete failure of 3rd parties (such as Amazon & Apple) to even attempt reasonable security should lead to more mistrust of 3rd party identites (which is what BYOI is all about), not more trust. The Identity Providers (IdPs) failed to do their job.

In fact, this entire episode would appear to justify all those enterprises which refused to get on the Relying Party bandwagon for OpenID and its ilk.

Now some of this disagreement comes thru a confusion of terms. Nishant views each of the entities that gave up information about Honan as a primary partner in his identity and is arguing that each should have allowed him to "bring" an identity from a 3rd party IdP which would do a better job of protecting the identity information.

But I look at it as those companies being 3rd party IdPs (with themselves as RPs) because Honan had little or no cotrol over the data they handed out. Had Honan controlled his own information, it's hoped he would have done a better job than those enterprises in protecting his valuable data. And that's what companies of all sizes in all industries have been saying (or, at least, their CISOs have been saying): No thanks, 3rd party, I'll protect my own assets if you please.

The second point I wanted to make wasn't really about something Nishant said, but a point Jonathan Sander made (and Kaushik referred to) in a blog post. But I'll get to that seperately.

Labels: BYOI, hack, IdP, passwords, RP

Posted 10:51 AM (0) comments

R.I.P. SAML

My colleague, Craig Burton, caused quite a stir at the rcent Cloud Identity Summit when he declared "SAML is dead". The Twitterverse exploded in comment. After reflecting for a few days, I'd like to add a bit of doggerel to the discussion. To the tune of "Poor Jud is Dead" (and with apologies to Oscar Hammerstein II):

To the Future - and beyond!

Posted 11:14 AM (0) comments

Wednesday afternoon in the mountains

If you're going to be attending the Cloud Identity Summit next week I've got a tip for you. But first, if you're NOT going to CIS 2012, why not?? Everyone who's anyone in identity will be there (well, OK, mostly everyone) because while it's called the CLOUD Identity Summit, we all know that the cloud is simply another platform, so almost everything you learn will  be applicable to your datacenter as well s to any SaaS you might be using. Plus, it's in Vail - high up in the mountains of Colorado.

Now for that tip -

On Wednesday, right after lunch, head for the Cascade Room. There I'll be hosting what's called the "Analyst Perspectives Track" and I'll be joined by some of the best in the business:

Craig Burton (Kuppinger-Cole)
Mark Diodati (Gartner, formerly Burton Group)
Andras Csar (Forrester)
Sally Hudson (IDC)
Steve Coplan (451 Research)

And, to keep us all in line, Ping Identity's own (and my former Network World colleague) John Fontana.

Why is this a "must see"? Because most other presentations will be by either a vendor or a user. In either case, they'll be looking at one (or possibly) two products. But when the analysts get together, then you'll hear about everybody in the sector, what's hot and what's not and how to structure your system so you know you'll be secure.

Just looking at Mark's presentation title, "Strategies for Thriving in the World of Hybrid Cloud Computing, Device
Independence, and Social Networking" takes your breathe away in its sweeping nature. Then, after presentations from both Craig (Authentication's future) and Andras (Identity Intelligence), Sally, Steve and I will  dissect their theories and expound upon our own looking at "Challenges, hurdles and where we are headed".

It's just a great place to spend the afternoon. See you there! And I will be taking names :)

Posted 6:37 AM (0) comments

Chicken Little and LinkedIn

Unless you live under a rock (and I think even those people heard about it) you know that LinkedIn and eHarmony both reported the leak of millions of hashed passwords this week. Millions of your friends urged you to change those passwords. People you've never heard of offered to check to see if your password was one that was "stolen."

How gullible are you?

You were being urged to go to some website you didn't know and enter your LinkedIn and/or eHarmony password. The screen would shift and you'd be told whether or not your password was one of those taken. In the meantime, of course, you've handed you're unencrypted password to someone you don't even know. But, you say, they don't know your username, do they?

Well, the people who stole the passwords from LinkedIn and eHarmony don't know your username either - all they got were hashed passwords. As such, it's akin to stealing a specialized dictionary. Yes, if they discover (or guess) a valid username then they can test each and every one of the passwords against that account. But they don't need to steal passwords to do that - any half-baked dictionary attack would do as well.

The events at LinkedIn and eHarmony were data leaks - but they weren't information leaks. Data is simply binary bits which have little meaning in and of themselves. Had the hackers gotten usernames with the passwords, well, then they'd have information - usable data. But they didn't, so they don't.

Should you change your password? Probably, but not to another that was in the stolen data - that would leave you no  better off. Maybe you should just run around and yell "the sky is falling, the sky is falling!" like the technically illiterate media.

Posted 6:53 AM (1) comments

CBAC to the rescue, once again

Nishant Kaushik posts today ("How Do Governance Controls Fit Into IDMaaS?"), commenting and expanding on the issue of Identity Management as a Service first raised by Kim Cameron (and extended here) and elaborated on by Craig Burton.

Nishant's main issue with the IDMaaS discussion is that it omits the governance layer:

"What I was surprised to find missing from Kim’s and Craig’s discussion about IDMaaS were the governance controls one needs in identity management (and therefore IDMaaS) – like approval workflows, access request and access recertification."

 He concludes by saying:

"I’ve always felt that one of the biggest challenges facing Enterprise IDaaS was the need to compose, in real-time and at scale, a context sensitive identity that combines assertions from various authoritative sources (selected based on the usage context) with a core identity from the users chosen identity provider."

 This is just Context-based Access Control (CBAC, sometimes called ABAC for Attribute-based Access Control) extended to the cloud environment. The cloud-based IDMaaS would need a virtual engine with connectors to the relevant sources of authority for the attributes as well as a policy enforcement point (PEP) to actually grant the access token if justified. Moving to the cloud changes the platform, changes some protocols and changes some (small r) roles, but the abstracted architecture remains the same. It's just a question of extending the reach of the governance rules we already have.