The BSIMM study data set has more than tripled in size and now includes data from 30 firms. We are busy working with Betsy Nichols to crunch the numbers now that we have a statistically significant data set. The plan is to announce our results at RSA.

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.

I’ve lived in a bubble all of my life. My parents created a bubble to grow up in and then I wrote commercial software products. It’s only recently that I’ve stepped out of that bubble and seen just how messy the real world is. Yes, I’ve looked at bubbles from both sides now (sorry, but I couldn’t resist the not so veiled reference to Joni Mitchell).

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.

The European Network and Information Security Agency (ENISA) published their analysis of security risks from cloud computing. It’s a well thought through paper and it complements the work on cloud security guidance being written by the Cloud Security Alliance. What I like about both the ENISA report and the CSA Guidance (I’m an author of one of the sections and, yes, I like my eating my own cooking) is that both documents take the point of view that Cloud Computing is going to happen and that security is going to have to deal with it.

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

This is a guest post by Cigital consultant Romain Gaucher.

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.