Let's Get the Outreach Started

The developer outreach mailing list now has 52 subscribers. And we're starting right now. Here's the plan in which you can join directly.

Reach out to developers you know or work with, asking what their security itches are. A two week first iteration, so "deadline" is March 10. Whatever you get back you can dump to john.wilander[@]owasp.org and I'll organize it. Please ask developers:

1. Years in software development:

2. Programming languages most used:

3. What are your software security itches in design & code (not working, too complex, can't find it etc):

(And please make sure we don't taint this by asking ninja security guys. ;)

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.

Security People vs Developers

"Developers don't know shit about security". That may very well have been the most retweeted quote from the 2011 OWASP Summit. I heard it from stage firsthand and I wrote the original tweet about it, adding "Well, I got news. You don't know shit about development".

I truly believe this is one of OWASP's biggest problems. I hear it all over the place – frustrated appsec people claiming that developers and managers are ignorant, lazy, or untrained since they don't prioritize security. But it's we, the appsec people who are ignorant, lazy, and untrained! And that's why we're failing in developer outreach. We keep going to our own conferences, pushing Powerpoint slides, discussing unsexy web 1.5 code, and still think we're on the top of the hill. We're at the bottom, guys!

I've done surveys with 200+ developers to figure out how security is prioritized. In general, this is the picture:

Software Priorities According to Developers

1. Functions and features as specified or envisioned
2. Performance
3. Usability
4. Uptime
5. Maintainability
6. Security

When I tell appsec people this they typically go "Yeah! See, that's the problem. We should be much higher on that list!" No. No, no, no. We belong at level six and unless we appreciate and understand how security fits in with functions, performance, usability, uptime, and maintainability we will keep being ignored by developers.

Why? Well, a featureless system is useless. A security feature that hits performance notably is out. A system with poor usability will bring no business so usability is above security. "Uptime, hey that's a security thing!" No. Just because DoS attacks hit your uptime doesn't mean we own the issue. Many things affect uptime such as release and deploy cycles, maintainability, caching, scalability, configuration, and patching (no, not just security patching). Finally, maintainability affects ROI much more than security in the general case. Thus, security == level six.

Appsec friends, let 2011 be the year where you go to training to learn what's important in software and where security fits in the big picture. Then we won't hear anymore jokes on ignorant developers in 2012. Instead we'll be humble and get things done.

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.