You can reply the webcast and get copies of the slides here.

The jist of the presentation is that SOA Security often gets equated to WS-Security (or perhaps devolves into WS-Security). The problem with WS-Security is that it’s often applied at the wrong level, so there needs to be a better architectural approach to addressing security within an SOA. By combining SDL, ARA and SAE, we’ve found that it’s possible to look at a layered approach to security based on trust zones and SOA governance tooling.

I’ve been continuing to work on documenting the details of the SDL, ARA and SAE integration with John Butler from Everware-CBDI. We’ll be doing something more formal when we have something that can be published.

We’re unveiling some statistical results at RSA this week that will enhance and expand the dataset published in the article. We’ll do an official BSIMM2 launch within the next couple of months.

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.

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.

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).

One question that comes up in the BSIMM work fairly consistency is the difference between BSIMM and other maturity models for software security. To answer that question, I wrote an article for informIT entitled “Cargo Cult Computer Security: Why we need more description and less prescription.”

Download audio [mp3]

David Rice, the author of Geekonomics (as well as the 46th Silver Bullet Security podcast victim), and I discuss the BSIMM in a webcast about the upcoming SANS software security event in San Francisco.

The time for science is upon us. And the first step in any scientific approach is measurement.

Application software lives in a bubble too. Quite literally, the bubble itself are all of the network security controls, but there’s also all of that airspace inside. That air space is the set of invisible assumptions that the software is built on.

One of the assumptions that’s been on the top of my mind is “our software runs behind the firewall”. This isn’t an indictment of this statement, it’s true and there’s a wonderful, liberating set of assumptions that a designer can make. Where do those assumptions materialize in software development artifacts? For many of them, the answer is nowhere. They are passed on through the airspace because everyone knows them. There’s no need to write them down.

What assumptions exist in the security of an application when it gets ported to a cloud computing environment? Multi-tenant versus Single-tenant infrastructure – check. Externalization of IAM for SSO – check. The 20 other “well duh” generic security items that pundits (myself included) will dwell and pontificate on. What are the important ones? Damned if I know.

But you know and only you will know. Why? Because you’re inside the bubble and we’re not. So, start writing them down. And when I come in a pull out my generic (I called tried and true) solution for migrating to the cloud pull out that list. It’s that list of assumptions that stand between you and migrating your application to a the cloud.

There are certainly security risk for applications migrating to the cloud. These risks involve both security concerns such as the confidentiality of the information stored in cloud services as well the legal implications concerning the liabilty if a system is unavailable. This focus of cloud computing risks on the consumers of cloud services by both of these organizations seems justified. After all, how many companies are going to be cloud service provides?

Well, that’s what I thought.

Now, I’m thinking that if Cloud Computing really catches on (beyond everyone writing about it and attaching the word “Cloud” to any product or service that’s connected to a network) then I suspect that most “consumers” of Cloud Computing will want to be service providers too.

What caused this change in thinking was the article I read about how Larry Ellison “created” the network computer back in the 90s. The network computer really is what we call Cloud Computing today. Combine that with how SOAs evolve within an enterprise. They start as disparate web services, but then eventually the business units provide services that are their key data to the organization. With Cloud Computing it will be your business (not just your business unit) providing services (data) to other businesses.

The question is how you’re going to do that. I suspect that youll be exposing some kind of PaaS environment that your partners will write application-lettes in. These application-lettes are going to be doing the combining of data from your two systems. On which PaaS the application-lette runs is going to depend on which the amount and sensitivity of the data.

AI had a second coming in the 80s, aren’t we ready for a second coming of “The Internet is the Computer” in the 10s?

Technorati Tags: software security, cloud computing

Every year since 2006, Jeremiah Grossman has organized a contest to recognize the Top Ten Hacking Techniques of the year. This year, I had the privilege of being one of the security professionals asked to judge along with Rich Mogull, Dinis Cruz, Chris Hoff, HD Moore, Billy Rios, Dan Kaminsky, Steven Christey, Jeff Forristal, and Michal Zalewski.

The scoring process was intentionally simple: given the list of 82 hacking techniques or selected exploits, we each nominated our top 15, in order. Appearing in a judge’s number one position would score the technique 15 points. Being ranked as a judge’s number two scored 14 points and so on. The techniques which received the most total points from all judges became the top ten.

Judges were given broad latitude in making their selections, but candidate techniques were judged primarily on pervasiveness, impact, novelty and coolness. I know a few judges who used a more formal evaluation methodologies than I did, rating each candidate individually and then sorting them. I didn’t.

Since I was already familiar with many of the candidate techniques listed, I didn’t have to go through them again and I was able to focus on the techniques I didn’t have time to follow or to dive into during the year.

After a few hours, I had a reasonable knowledge about of all the candidates. In order to get a more manageable list of candidates, I decided to do a first pass and create a list of techniques that I believed must be in a top 15. I came up with a list of about 30 finalists.
With this smaller list, I went back to the papers and blog posts to rate the techniques. I decided to combine some of the factors that Jeremiah sent us to simplify my evaluation and because I thought it suited correctly the goal of this contest. I used the Risk and the Originality of the techniques to rate them:

• Risk: pervasiveness and impact
• Originality: novelty and coolness

I considered those two factors to have the same weight. Even if in my daily job the risk represents the most important part of the evaluation, for the contest, the originality is a very important part.

The list of top ten winners can be found in Jeremiah’s blog post. Some of the candidate techniques were de facto winners because they would have such an impact and coolness. This is especially true for the research from Alexander Sotirov et al. on the Rogue CA certificate: totally elite. I’m sure most of the readers will remember the buzz of this attack last year at the 25c3 (Chaos Communication Congress). They started by teasing everyone and then, explained how, with a cluster of 200 PlayStation3, they were able to create a rogue certificate: way to go for a perfect man-in-the-middle or phishing attack!

With a different scoring vector (lower originality, but higher risk due to high likelihood than #1), we have our number two, the research from Luca Carettoni and Stefano Di Paola which is a the newly-named HTTP parameter pollution (HPP). This attack exploits HTTP request parameters (query string, POST variables, etc.) parsing discrepancies between different layers of the application (input/output handling, encoding issues) or server-side application stack (front-end/back-end, WAF, etc.). Even if this attack doesn’t look über-cool, it can facilitate a lot other type of injection-based attacks (XSS, SQLi, etc.) by, for example, hiding the payload from one of the defense layer (WAF for example).

I am a bit disappointed not to see any PDF related attacks in the final list (yes, it was in my top 15), because it was such a big deal in 2009. Most of those attacks come from the JavaScript support. For example, the PDF Silent HTTP Form Repurposing Attacks paper explains how an attacker can create a malicious PDF file executing JavaScript in the same domain. This is a great follow-on work to what Didier Stevens and others did on the PDF format. Some others techniques from my list didn’t make the final top ten such as the Socket Capable Browser Plugins Results in Transparent Proxy Abuse from Robert Auger. I find them both very interesting in reflecting discrepancies between server-side application stack and new client-side attack surfaces.

But anyway, this was a great year with many different attacks, some new, some really elite, others are improvements of already known techniques. Attacks are targeting different flavors of web security: cryptography, protocol design and abuse and software misbehavior. Research into techniques like these allows us to better understand the security problems we face right now and catalyzes joint work between vendors and the security community.

Finally, I’d like to congratulate my Cigital colleague, David Lindsay who, along with Eduardo Vela, came in at number 8 with cross-site scripting research that yielded surprising and sophisticated ways to evade filters and web application firewall (WAF) rules.

Here’s what the White House has to say.

Back in July I talked about what I would like to see in the position in a Justice League post and a video for Gartner. I stand by my statements from July. However, I am psyched that Howard is taking the job. He understands the importance of building security in and will be a powerful advocate for software security.

What a great way to start 2010!