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.

Our sincere congratulations to Howard Schmidt for taking on one of the most important jobs in computer security—US Cybersecurity Coordinator for the White House. Howard knows what he’s getting into, because he already did it once. (You’re crazy Howard!)

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!

The BSIMM study focuses attention on software security in large organizations and just at the moment covers the work of 1554 full time employees working every day in 26 software security initiatives. One phenomenon we observed consistently in the BSIMM is that every large initiative has a Software Security Group (SSG) to carry out and lead software security activities.

I wrote about our observations around SSGs in my December informIT article.

Simply put, an SSG is a critical part of a software security initiative in all companies with more than 100 developers. (We’re still not sure about SSGs in smaller organizations, but the BSIMM Begin data (now hovering at 75 firms) may be revealing.)

Cigital’s SSG was formed in 1997 (with John Viega, Brad Arkin, and me as founding members). Since its inception, we’ve helped plan, staff, and carry out ten large software security initiatives in customer firms. One of the most important first tasks is establishing an SSG.

A short one ‘real quick’:

I get simultaneously nostalgic and aspirational as holidays and year-end planning bear down on me. Wondering how to innovate and how to get that innovation into use takes a fair amount of my attention. I wrote a blog post in ‘07 on how to get some of that innovation stuff in your own security group.

McGraw collaborated with Routh recently on an article (“Lifestyle Hackers”) for CSO Online. While the article focuses on what a CSO must do to more intelligently deal with social-media savvy employees, it also elucidates what we all know implicitly: consumers and those building sites to cater to them directly are driving innovation faster than the big guys (who used to do the bulk of this driving out of their research labs) are.

This was driven home by a recent “Daily Chart” from the Economist. Microsoft is #2 in spend. I might argue we’ve gotten a lot of value as an industry out of their security initiative too. CAS has always seemed dead-on-arrival to me but, I don’t see progress as a result of research that’s taking us in a fundamentally different direction in Software Security (look at their stated areas of interest for both “Security and Privacy” and “Software Development”). IBM made the list too, but is last (see my last post, in which I discuss my impression of how quickly IBM will adopt innovations like O2).

Other than IBM and Microsoft, you’ll not find software companies on the chart at all. And, while communities might bring together experts and provide progress, I fear it will be all-too incremental. Security is plainly in the hands of consumers. Yet, as the bevy of Facebook security/privacy concerns indicate, their demands too leave us well short of the goal line.

As I drove Dinis to the final day of AppSecDC he (as often is the case) had his laptop open. We traded ideas regarding the future of O2, support, and other broader issues about the future of software security. As we discussed or machinated over word choice, I found myself in near-complete agreement with him: not an unusual circumstance.

In his post RSnake muses:

I’ll be curious to see if any big companies step up to the plate here and takes ownership. It’s a bit unclear about Dinis’ fate within IBM – I think he’s a bit on the fence.

I characterize O2 as a platform that facilitates a highly-experienced or expert-reviewer in understanding software. While Dinis has taken a few runs at automation and work-flow support (before with his WCF stuff and now with his XRules) I think the principal benefit of his current state of development remains unshackling the reviewer from limitations of a SA tool often in terms of data-flow across language boundaries and through framework / generated code. So important is this concept to myself and Cigital that we’ve built our own framework which we call ‘The Factory‘. We use it for a similar purpose as one might use O2. As Dinis consistently reminds me though it is not open source. And, yes, there’s a lot of other wicked-cool stuff in O2 (the Visual Studio debugger integration is my favorite).

Cigital believes in O2 enough that we’ve conducted hands-on O2 training with a bunch of our guys even after Ounce training. I personally believe in the technical value to code reviewers of O2 enough that I put a modicum of code towards it when Dinis needed it in a pinch. I’ve also agreed to build and publish O2 training for the masses; ‘training that makes it seem less scary.

Taking a step back for a second, there’s a large leap between where the world is and the world Dinis describes in his recent blog post. Unfortunately, I see a lot of organizations doing software assessment driven by (and in pursuit of) compliance only.

So, it doesn’t shock me that IBM hasn’t dived head-first into the O2 pool, regardless of the opportunity it may represent. I believe they will fully embrace it when the market can support it. In the meantime, O2 can continue to find hospitality and support in the welcome arms of assessment experts like Cigital.

I’ve been thinking about this for a while and the tone of this year’s OWASP Global Summit has brought the topic to the forefront. OWASP, as many of you know, is a fiercely open source community. At times, participants defend its open and freeness a bit aggressively for my taste. Sure, open and free are founding principals of the community. I think these principals are essential, valuable, and worth protecting. However, I also believe the community-more broadly-would benefit from an evolved perspective.

Specifically, I believe OWASP should welcome branded security vendors and named individual practitioners into its arms openly. There are three reasons and as I outline them, think to yourself about what vendors like RedHat did for the Linux community.

First – Commercial entities can provide professional and enterprise-level support for OWASP projects to willing commercial entities. Code-based projects (like AppSensor, ESAPI, or other) are easier to imagine the impact of than others.

Second – Large entities seeking to participate within OWASP need assurances which the OWASP community hasn’t itself provided. Things I’ve heard loud-and-clear include:

1. Anonymous participation for industry players working for sensitive organizations
2. Structured feedback, steering, and funding for OWASP projects

Vendors do not uniquely possess the ability to provide these capabilities. The community could provide this value but has not prioritized it nor has it been able to convince industry it could appropriately address their security/anonymity concerns or provide tangible value. Vendors have much better luck in these regards.

Third, finally, and most Importantly – vendors desiring to enter the space should be seen as a welcome sign of maturity to the space. Maturity, to me, will mean key advancements:

1. Larger and less ad-hoc budgets within organizations for application security
2. The emergence of higher and more explicit standards for quality for the community’s free and open software/tools
3. Convergence of the security community’s message, which will allow it to be taken more seriously

To facilitate this, I suggest the OWASP board do the following things:

1. Explicitly endorse vendor participation, as long as it meets the community’s code of ethics and conduct
2. Stop ‘the crank’ over people’s personal / corporate emails being used on OWASP lists
3. Protect a commitment to technical quality by avoiding vendor pitches at conferences in chapter meetings, and in posting

I really don’t mind when people use their corporate email addresses when they mail public lists (OWASP or otherwise). As a chapter leader, I don’t (personally) mind when presenters show up with their company’s slide stock though I push them to use the chapter template. To me, corporate emails and slide stock help audience members identify and appropriately couch bias. Given my own profession and employer, my own biases should be evident.

On the community front, my roles spanning the gamut between OWASP Member, Chapter Leader, and invited industry advisor. I see my professional life and my community involvement as being mutually reinforcing and beneficial, rather than conflicts of interest. I enjoy having two outlets for my time and work. And, while, Yes there’s bad individual behavior out there, I’d like to see people more comfortable with their dual-roles. Again, I think their professional career, their volunteer community, and the industry as a whole will benefit.

Today we officially launch BSIMM Europe, a study of 9 EU firms’ software security initiatives. We continue to focus our inital data gathering on large-scale software security initiatives at major software firms. Firms in the study include: Nokia, Standard Life, SWIFT, Telecom Italia, and Thomson Reuters.

An informIT article can be found here.

The article describes our findings regarding European software security by contrast with the original BSIMM. Overall, we have tripled the size of the BSIMM study to 27 firms with several more under way. We hope to reach 30 firms by year end.

We released BSIMM v1.5 as part of the BSIMM Europe push. The document (released under the Creative Commons) is available for download and now includes an appendix about BSIMM Europe. The original document (v1.0) has been translated into Italian (by Minded Security) and German (by Virtual Forge).

We are very excited about BSIMM progress and look forward to sharing more real data with the community. No more faith based software security!

After what must have been an incredible amount of leg-work a cabal of folk from the DC OWASP chapter are putting on the AppSec DC conference. The conference will also play host to the ‘09 OWASP Global Summit. I hope to see you there. Especially those of you practitioners from within organizations’ security groups–I feel like you provide essential perspective from the trenches of our security war.

Elections
Elections will be held to add another board member to OWASP and I’m anxious to see how the process plays out. Knowing all four announced candidates, I imagine different outcomes based on who receives the nod. In an odd turn of events, I actually like all the candidates; I think they’re great guys. In particular, I’ve known Pravir for many years, I’ve worked with him off-and-on, and respect him deeply.

I’d like to point out Eoin Keary’s bid in particular, because I like his focus on quality and governance. I perceive OWASP be at an inflection point in its development and growing pains are already evident. Selecting particular projects on which to focus, placing them under more rigorous quality control, and working towards maturity criteria others have begun to define can really increase the reach and impact of OWASP. This idea is essential to Mr. Keary’s platform.

Tesauro and Chandra, contributors to project assessment criteria, appear to place importance on this as well. Consider the draft criteria their committee is working on.

Again, I think quality is an ever-more-important imperative as the OWASP community grows and I’d like to see the assessment criteria expand to contain some more explicit and rigorous technical quality gates for a project. As I look at popular existing projects, I am beginning to feel a pressing need for outside review/revision.

Talks
As the Java EE persona of the ESAPI project nears release, I’m anxious to see a more hands-on, more technical, and more developer-focused presentation on the project at AppSec DC. Recent presentations/commentary has felt a bit more like cheerleading to me.

Of course, I’ll be dying to know what Dinis has added to O2 recently and it appears he’ll be presenting on this topic.

Threat Modeling
I’ll be presenting on Threat modeling on Wednesday but I’m also very interested in discussing the topic with the guys from SecurityCompass, who will be giving all-day training on the topic. Rohit in particular, has made what I consider to be top-notch start on his Java EE Security Patterns document and I’m anxious to see the methodology that back-ended their work.