A Client-Oriented OWASP

Right now there are tons of thoughts, ideas, and discussions on where OWASP should go. I'm beginning to see an image of a Client-Oriented OWASP (thanks Dinis, for finding the word). In that image there are great initiatives as well as a few things we have to set straight.

Current New Initiatives
A few samples of the thoughts going around: Jeff Williams sent his OWASP 4.0 email, I wrote about the gap between appsec and developers, Mark Curphey wrote about OWASP reaching a tipping point, and Michael Coates wrote about a vision for OWASP.

Since then Michael started the Defenders Community and I started the Developer Outreach Initiative which will become the Builders Community shortly.

Client-Oriented Part 1 – Builders and Defenders
If you combine the Defenders and Builders initiatives, a new, more client-oriented OWASP emerges. Client-oriented in the sense that we put more effort into understanding and helping the IT industry who builds, operates and maintains web applications. On the less technical side we're doing this already with processes and guides – great!

But on the more technical side, OWASP needs to mix up the pentesting and appsec tooling with how to defend and how to build secure webapps. And that for me means Builders and Defenders projects but also gearing our conferences and chapters more towards builders and defenders.

I'm not saying we should cut down on pentesting or scanning tools. I love pentesters and ethical hackers. Heck, I read and retweet your blogs daily. I'm also very interested in static analysis tools, proven by my publications in the area in 2002 and 2005. I'm just saying we need to address a larger crowd and get more balance into our efforts.

Client-Oriented Part 2 – Dealing With Independence
"Our freedom from commercial pressures allows us to provide unbiased, practical, cost-effective information about application security." —About OWASP

Independent or unbiased has two parts in my opinion:

1. OWASP should be independent in the statements it publishes, all the way from chapters to the board.
2. OWASP should not avoid certain projects, results, or discussions only because some individual/corporate member or sponsoring organization will be upset.

Right now I think OWASP is doing fine on number one. I hear no bashing nor promoting of brands or vendors except for publicly thanking them for their support. Thank you supporters!

But number two is worrying me. At AppSec NYC 2008 there was a talk on comparing static analysis tools called "NIST and SAMATE Static Analysis Tool Exposition" (video). Some well-known brands were in the study. But the speaker refused to show figures for individual tools. There seemed to be a consensus in the community that we should not present anything that could be interpreted as negative for certain vendors, not even if the test setup was made totally transparent. That's a violation of point two above, in my opinion.

2.5 years have gone and we're still not using our independence to compare and test appsec tools. Why? John Steven, an OWASP leader with immense experience in static analysis has published serious obstacles to comparing static analysis tools but they are all saying "Just don't make your tool choices based on a general comparison" which is good advice. We should tell people that. But we still need to start putting appsec tools to the test.

Creating the Client-Oriented OWASP means we'll have to start doing independent, client-oriented research. And if OWASP has been implicitly silenced before I will not take it anymore. Here's a list of ideas:

• Commit to Stefano Di Paola's brand new OWASP Myth Breakers Project.
• Create a space for customer comments on appsec tools (free as well as commercial). Something like AppStore reviews, good and bad.
• Start to compare blackbox and whitebox scanning tools. I suggest we go for a synthesized testbed (i.e. a controlled environment) and invite tool vendors/builders to take part. They get a workday to configure their tools and then we go. The testbed, configurations, and versions will all be published along with due reservations such as John Steven's.
• Start to organize free pentests and design reviews of open platforms. In the best case we cooperate, in the worst case we make our information public in an ethical way to help clients make the right choices.
• Sign the Open Letter to WebAppSec Tool and Services Vendors: Release Your Schemas and Allow Automation

Developer Outreach Initiative

Today I sent out an email to hopefully kick start OWASP's developer outreach. Recipients were an interesting mix of developers and appsec experts. If you want to join us just subscribe to the Developer Outreach mailing list.

Here's the content of the initial email:

The Problem

The web is developing at great speed and I love it. But when I read that the average website has nearly 13 serious vulnerabilities I get sad [1]. It's hindering us from doing more stuff on Internet. Douglas Crockford even suggested we scrap the current HTML5 spec and fix cross-site scripting first [2]. We have a problem.

Developer Outreach

I'd like to get rid of those 13 vulnerabilities per site and I'm convinced designers and developers of web frameworks and applications are the ones who can make it happen. We just have to get the right things into their toolboxes. This has been called "developer outreach" and currently it's a failure.

Proposed Solution – Security Itches

My first proposition is this: Instead of pushing coding guidelines and security tools onto developers I think we should start by asking them "What are your security itches?". Whatever we get back will be our starting point. Maybe we'll pick ten itches and publish good solutions.

   What if they have the *wrong* itches? Well, the goal of the outreach is 1) to find out what developers think, and 2) address their itches to build some well-needed credibility. Before we have credibility we cannot push coding guidelines. And if developers think SSL certs are their primary problem that *is* important.

Proposed Solution – Open Test Data

Security people tell developers to "do input validation". Input validation is no news to developers. The problem is defining the data model and testing the input validation. We can do something important here – building opentestdata.org. I own the domain and dream about the following beautiful community effort:

   You go to the site and can either "submit test data" or "download test data". On the submission page you can anonymously enter e.g. a Portuguese postal address, an Indian human name, a Swedish postal/zip code ... or 100 SQL injection strings. The effort is almost zero.

   On the download page you choose your format and download in context. "We have European customers so we want European human names, postal addresses, and phone numbers". Developers will love it. And that's where we can start promoting security testing!

Questions for You

• First question – do you like these ideas? Are they the right way forward? Would you like to be part of making it happen?
• How should we ask for security itches? And how do we collect answers? Email? Remember we'll probably get one-liners as well as small essays.
• How do we get the test data site flying? App and infrastructure? Auditing à la Wikipedia with a couple of dedicated moderators?

References:

[1] https://www.whitehatsec.com/home/assets/WPstats_fall10_10th.pdf

[2] http://blip.tv/play/g_MngeaxVgI (jump to 20:55)

Fears & Hopes for OWASP

As I leave the OWASP Summit 2011 in Portugal several questions and thoughts are tumbling around in my head. Is the Summit format the right way to do productive conferences? Are we becoming a paperware organization? Will the right people run for the board considering all the formalities? Is the appsec community failing because of an attitude problem towards developers?

I don't like long blog posts so I have split it up. Here's the menu:
1. New OWASP Board – My 10 Questions
2. Security People vs Developers – Does OWASP Have an Attitude Problem?
3. OWASP Paperware Project – Will Non-Code Projects Take Over OWASP?
4. The Summit Is the Right Direction

The OWASP Summit Is the Right Direction

I was on the organizing team for the OWASP Summit 2011. Not as deeply involved as Sarah, Dinis, Lorna, Jason, Deb, Sandra, and Paulo ... but I did organize the four Browser Security sessions.

I truly believe that the Summit format is the way OWASP conferences should go. We should not try to compete with Black Hat, Defcon, BSides or whatever conference out there. We should do something different, geared towards productivity.

Below is how I setup the browser security track and my humble suggestion for making a difference:

1. Prioritize People when Planning
The success of your session boils down to people. If you're at a workshop and "the guy who has all the answers" is not there the workshop is not going to be productive. So my overall goal was to get the right people there. However, you cannot start by inviting people, you only need to start with it as your top priority.

2. Build a Draft Agenda
To be able to successfully invite the right people I had to have a relevant draft agenda. So I spent a weekend watching various webcasts of talks from the people I wanted to invite. From that I built my draft agenda. I basically adopted their agenda and tweaked it with some personal stuff.

3. Reach Out to Key Players
Now that you have a draft agenda you can reach out to key players you already know and that are likely to say yes. Ask them what they think of the draft agenda and more importantly, ask if they would consider co-chairing a topic or two. Get their names up there.

4. Market Your Heroes
When you have a first couple of key players onboard it's time to get the buzz started. Tweet about it. Blog about it. Talk about it. And make use of the heroes who are already booked.

5. Reach Out in Waves
Now you need to get key players onboard that you did not previously know. It's time consuming so I do it in waves. A good weekend with the right inspiration you can hunt down a few more of the people you need to get there, explain the agenda and who else is going. Make use of your network and CC people who might be able to vouch for your workshop. As soon as you get people hooked ask if they want to be involved.

6. Have Faith
A lot of the so called key players are very busy. You may have gotten a confirmation four weeks ago but not heard anything since. Just make sure you send them updates every other week anyway. They'll come. Have faith.

7. Work Onsite
At the workshop you need to tend to practical stuff. I think I was the only session chair who cleaned all the tables up on stage before my sessions. Fresh blocks of paper, new water glasses, no garbage. Also make sure you have an announcement up on the big screen and walk around reminding people that it's only 10 minutes to you session. Do not underestimate what this kind of lightweight service can do for your session.

Another OWASP Paperware Project, Anyone?

Summing up the OWASP 2011 Summit I fear OWASP is becoming more and more paperware and less and less software. On the Summit's fixed schedule we had 15 technical sessions and 27 non-technical sessions (my interpretation). That's almost two thirds non-tech.

The only guys I saw actually coding at the summit were people we had invited and that are not OWASP leaders (Powerpoint slides with code do not qualify as coding). At the same time OWASP is getting desperate about not reaching developers.

The solution is in my opinion to cut down on paperware, pdfs, Powerpoint presentations, guidelines, and policies. Developers want code, not Word documents. I tried to bring this up during the OWASP Secure Coding Practice session but failed to convey my view. Who would have thought a coding guide did not contain code?

If you hand a document to a developer that says "Do canonicalization" you will not get canonicalization in the application. But if you hand a developer code snippets in a relevant language that show a couple of instances of canonicalization problems and how the solution could look you will get a change.

So, why do we still have all these guidelines and policies that talk about code? I believe the reason is that the authors don't know how to program. Guys writing appsec guidelines typically cannot code themselves and developers can smell it a mile away.

Do you believe OWASP needs to reach developers?
Are you right now working in a word processor rather than an IDE?
Stop!

Developers believe in other developers and working code. You want to change how they play? Get in their game.

New OWASP Board – My 10 Questions

At the OWASP 2011 Summit I attended some of the sessions on OWASP Bylaws and OWASP Governance. I agree we need to update and define roles and duties but there are more urgent issues.

Discussing the board is complicated if you're not natively English speaking. Asian, South American, and European OWASPers tend to know English appsec terms but they do not know the nuances in what's being said about governance. This effectively means only English speaking people will define how OWASP should be governed and mainly English speaking people will run for the board. Today the board consists of 4 Americans, 1 Irish, 1 Portuguese living in London, and 1 Belgian. That is neither representative nor good for OWASP.

I'd like to see the OWASP board grow more diverse. Therefore I will ask the questions below to the members who run for the board. Note, this is not a requirements list, rather parameters I'd like to see diversity in.

1. Which human languages do you speak?
2. In which parts of the world have you lived at least 3 months?
3. Have you shipped production code? How long ago?
4. Please provide a list of web technologies you consider yourself proficient in (markup, styling, scripting, server-side code, server configuration and operational setup ...)
5. What is your typical appsec role (pentester, trainer, developer, project manager ...)? Are you a consultant, vendor, or do you have an appsec role within an organization?
6. Please provide a list of appsec activities you consider yourself proficient in (code auditing, threat modeling, SDLC implementation ...)
7. Have you run or are you running an OWASP chapter? Which?
8. Have you run or are you running any OWASP projects? Which?
9. Do you have a college or university degree? (No requirement, I just want the right mix)
10. Do you have a postgraduate degree? (I'd like to have at least one on the board)

There are no correct or preferred answers to the questions above. I only want to ensure we have people from as many parts of the appsec community as possible. For me that's more important than knowing all the English terms in our bylaws or policies.

Countdown Challenge for OWASP Summit

The official OWASP Summit Challenge is out – a JavaScript fighting arena where your script should show its name more prominently than its competitors. The first round attracted 8 contestants and "dross" scored the first point. Check out all the scripts and the next round of competition: http://makeXORbreak.com

The challenge starts the countdown to one of the most important meetings in application security history. February 8-11 we invite you all to join round-table discussions with industry and research leaders on how to solve XSS and enhance browser security, which appsec metrics work, security of HTML5 and EcmaScript 5 and more. We truly believe that crucial things can happen in a social, productivity-oriented environment. That's why OWASP is going all-in on the Summit.

Google will be there. Mozilla will be there. Microsoft will be there. Facebook will be there. PayPal will be there. Apache will be there. The world's top appsec companies will be there. The authors of (my) favorite appsec books will be there.

OWASP Summit 2011

Best thing of all? You are most welcome to join!