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:
This outreach brings a million thoughts to mind, but in order to get anything said at all, I restrict myself to starting with an observation on culture, and a corollary.
ReplyDeleteA characteristic of the developer profession is that its sub-culture carry strong anti-authoritarian currents; currents that border to, and sometimes cross over to, anarchism. A simple literature study should make that obvious: have a look at "Matrix", think about why "Blade Runner" or "V for Vendetta" are so popular within this sub-culture; and follow the traces back to "Neuromancer" at one root and the hacker culture at MIT as another root. Then think about Lisbeth Salander.
I do not claim that all developers are anarchists - just that the sub-culture of developers have a stronger anti-authoritan trait than other fields. My guess is that BAs in economics do not tend to read mentioned books to the same degree.
Now the corollary, based on the above observation and my own experience: every initiative touching developers must have "by in" as the first-order concern.
A coding guideline on where to put the '}'s, thresholds on the amount of unit test, directives on how the apps are to be split architecturally, or security cannot be given as a directive - it will simply be silently rejected by not being followed. This is not "by-in as first order concern". There is simply no effective and efficient way to "enforce" what is handle down from above.
Instead, any architectural framework or coding practice, must start with building some multilaterally accepted first version ("the code must compile" perhaps), and then grow it together in a community fashion.
When working with developers, getting "by-in" for the policy is harder than writing the policy. Thus "by-in" should be the first-order concern. Any process not embracing this attitude will fail - I have personally seen it happen more times than I can keep track or.
This Developer Outreach Initiative is working in the right way: it has the potential to succeed. I believe in it.
This is something I believe is critical if we're going to secure web apps.
ReplyDeleteThings like pentesting and WAFs are just sticky plasters (although very important ones right now).
I think education and the right tools are key.
If devs know about the problems and have easy to use and effective tools then they will use them.
The vast majority of developers care about their apps. They want them to work, perform well, be reliable and usable. And they _will_ want them to be secure if and when they find out that they arent.
Psiinon
-First question – do you like these ideas? Are they the right way forward? - Would you like to be part of making it happen?
ReplyDeleteI think it's time for this to happen, so yes, the right way forward. Happy 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.
Email might be hard to manage, we need some collaborative solution that allows a few to moderate and do something with the data thats being received.
-How do we get the test data site flying? App and infrastructure? Auditing à la Wikipedia with a couple of dedicated moderators?
The Wikipedia approach might work well here.
You're right - and even better, it already exists at a decent level of maturity. This has been one of my main research projects for the last couple years:
ReplyDeleteHTTP://fuzzdb.googlecode.com
I am a developer with interest in app sec. I believe developers are already expressing their 'itches' - its just that security folks aren't looking at the right places.
ReplyDeleteWhen developers face problems, they go to stackoverlow.com. Or they go to the mailing list of the framework they use. Or they google for information. But they don't come to OWASP website to learn more - that's their general nature.
So, if we want to learn about developer's security itches, we have to listen to them, not ask them. We should register on developer forums and set filters for security questions. And then lets answer them to the best of our abilities. Build a reputation among developers and earn their respect.
Over time, we'll have a general idea about the challenges developers face. And thats when we try to fix them. The solution could be better documentation, or security extensions for existing frameworks or better continous integration tools.
I don't know what the solutions are, but I am confident we can only learn by listening to developers.
A library of test tools for web apps sounds good. Pick a few common ones and build some good tests. See how much they get used. Go for it.
ReplyDeleteJohn,
ReplyDeleteI'm a development manager who cares about software security. I like the idea of a developer outreach program at OWASP, I think that there are a number of steps that could be taken to get developers and security people working together.
As sripathikrishnan said above, the key is to go to the developers, to where they work, where they look for answers. Don't expect them to come to you with questions: not many of them will. Security experts need to get involved in development conferences, and get involved with development experts: in forums and in one-on-one meetings and whatever else it takes.
I've blogged about some of my own ideas on how to do this before at Building Real Software.
Jeremiah Grossman (and others) also had some interesting ideas about this at Open Letter to OWASP.
And you may want to get involved with the Rugged Software thinkers too who are trying to do something similar. The more people working together on this, the better.