I read a question on one of the cloud mailing lists asking which of the federated authentication protocols (SAML, OpenID, Oauth, WRAP, etc) would win. My initial reaction was to reply, “Isn’t the question which ones won’t lose?” Okay, that’s snarky and perhaps a double negative, but I find it a rather dubious notion to think that there will be one winner. Aren’t authentication protocols like camera lens mounts? There are several types and all that’s important is that you can share lenses with the people you hang with? Why does there have to be a winner?

If you’re consuming a SaaS, it would seem like the service will support N protocols and you can either support one of those N. It seems like the big SaaS vendors will have some set of standards in place and it will take a couple of big customers to get them to expand that set. What’s it going to take for Force.com to implement something other than SAML?

For PaaS and SaaS, your organization is in control of the application, so you can handle authentication by whatever scheme you choose. If you’re working with some business partners, then you implement whatever protocol you both can agree to.

The protocols/mechanisms so far is only for user authentication. What would be helpful is if there were some way to enable authentication to include the cloud service itself. Cloud services all require some form of account information to do anything. If it’s a service like Amazon, there are also the private keys that have to be maintained, managed and passed to just gain access to the infrastructure. What all of the different delivery models have in common is the problem of authenticating to the cloud service. Is this a problem for identity management or just a (not so) simple credential management problem?

So, the question is not which one protocol wins, but which ones lose since you can only hurt yourself by implementing something that dies off. Then you can turn your attention to the problem of securing the authentication to the cloud service itself.

Apparently the time has come to re-release the SANS/CWE 25 — something that we can expect annually. The good news is that exercises like this do plenty to hype up software security and its importance. In fact, in many ways the target of these lists is “the reporters who cover software security.” So hype = good.

So why am I not a big fan of these lists? Well, I wrote that down a year ago and what I said then still applies. Sure would be nice to see a reasoned response to my criticisms instead of repetition of the same tired ideas. If you haven’t had a chance yet, go read my January 2009 informIT column “Top 11 Reasons Why Top 10 (or Top 25) Lists Don’t Work.”

There are some important improvements in this year’s top25 list that have been discussed on sc-l. But there is also a problem that really bothers me. The SANS guys are trying to tie the top25 list to software liability (?!) and apparently think they can hold developers accountable for their bugs..well, 25 of them at least. I think this is a wrongheaded approach to software security. I would much rather talk about the real progress the field has made than to hype up yet another list and make the list a critical aspect of software contracts?! Can you imagine what such a move (if it succeeded) would do to the price of software and to the hourly rates of developers? Developers would be compensated like lawyers!

Top-n lists do have their place. In the BSIMM we note 10 firms (of 30) who follow activity [CR1.1]. Here is the activity cut from the BSIMM:

Create a top N bugs list (real data preferred). The SSG maintains a list of the most important kinds of bugs that need to be eliminated from the organization’s code. The list helps focus the organization’s attention on the bugs that matter most. A generic list could be culled from public sources, but a list is much more valuable if it is specific to the organization and built from real data gathered from code review, testing, and actual incidents. The SSG can periodically update the list and publish a “most wanted” report. (For another way to use the list, see [T2.2] Create/ use material specific to company history.)

In my view, a tailored top-n bugs list is way more useful than a generic “world list” like the SANS/CWE25. To think about why this is, consider the differences between code bases from Intel, Microsoft, Symantec, and Nokia (not to mention Wells Fargo)…all BSIMM participants. Whose bugs do you want to eradicate? Yours? Or your neighbors?

Press coverage of the “controversy”:

• SANS Institute, MITRE release new top 25 dangerous coding errors list, TechTarget.
• Top 25 Programming Errors: Should Software Developers be Liable?, Bank Info Security.
• Hold vendors liable for buggy software, group says, ComputerWorld.
• 25 ways to better secure software from cyber attacks, Scientific American Observations.
• Security agencies release Top 25 programming errors, Washington Technology.
• Proposal Would Hold Software Developers Accountable For Security Bugs, Dark Reading.
• Group Proposes Suits Over Faulty Code, Gov Info Security.

I had been reading about Gartner’s prediction that 1 out of every 5 businesses were going to dump all of their physical IT infrastructure when Sammy Migues sent me a thread from LinkedIn about it. The thread contained many of the common sense views about Cloud Computing that you’d expect: IT should be based on strategic value and should outsource the commodity pieces. That day, I was also reading about the Forrester survey that states that 43% of their respondants said that they had no interest in cloud storage and another 43% (perhaps the same 43%) had no plans adopt it.

Some of the difference in these two reports has to do with hype versus reality. I recall in “the naughts” that SOA was touted as a way for IT to bring business agility. Then all of the vendors got on the SOA band-wagon. Now it seems like Cloud has taken up where SOA left off in terms of hype. On the reality side, I wish I could tell whether the lag is because of people’s increased awareness of security (the optimist) or whether it’s a reflection of the sorry state of storage implementations (the pessimist).