[Owasp-leaders] Does OWASP need a manifesto?

Mike Boberski mike.boberski at cox.net
Tue Jan 6 18:59:14 EST 2009

On a somewhat related note, as someone working in the US Fed Gov't space, I
would like to propose we need something equivalent on the legislative side,
perhaps an OWASP lobbyist. I need law not technical or management buy-in to
perform verifications!


From: owasp-leaders-bounces at lists.owasp.org
[mailto:owasp-leaders-bounces at lists.owasp.org] On Behalf Of Jeff Williams
Sent: Tuesday, January 06, 2009 3:43 PM
To: owasp-leaders at lists.owasp.org
Subject: Re: [Owasp-leaders] Does OWASP need a manifesto?

Hi James,


I absolutely think OWASP does need a manifesto.  I called for the creation
of one at the NYC conference.  In case anyone missed it, here's a transcript
of that talk.  It's in point number 7.  I'd love to work on this.





The Promise of Software

Jeff Williams - OWASP Chair

Delivered 9/24/2008 at the OWASP AppSec 2008 Conference in New York City


I first discovered software 25 years ago in the Exploratorium in San
Francisco. They had Conway's Game of Life set up - and I got that first
awesome sense of the power of software to create whatever we want.  David
Gerlenter calls software the "virtual machine" - like a nuts-and-bolts
physical machine, but infinitely malleable. Since that day, I've loved
software.  I hate computers - but I love software.  I know we're only
scratching the surface of what software can do.  We are going to see truly
awesome applications that enable us to reach far beyond our human
capabilities. That's software's promise.


We Are at a Tipping Point!


As we speak, a major financial organization is building software to create
an online space where their associates and their clients can work together
to perform transactions in the cloud through their browsers. It's fantastic
- like you're in this perfect monogamous relationship with your bank in


Except that the bank application is sleeping around with thousands of other
browsers.  And let's face it - your browser is sleeping around with lots of
different web applications too. And nobody is using protection. Here's the
problem. As we make more connections like this, the attack surface expands
exponentially. At the same time, we're dramatically increasing the value of
the assets involved.


AND we're using technology so new that we have no idea whether it's secure
or not.  AND quite frankly, we're still struggling with the very simplest
aspects of security. All of this together creates enormous security risk -
risk that is already hampering software's promise.  So I'm torn..we're
starting to build the software I always dreamed of, but it only works if
everyone trusts everyone else.


So Let's Confront the Brutal Facts Facing Application Security!


Here in this room we know something the rest of the world only vaguely
understands. We know that we're taking crazy risks with our software. We
know that the past 15 years has seen the threat rocketing forward and almost
no changes in the way we create software.  So here it is.  WE, you and I,
are failing.  We know the software market is producing insecure code and
we've done basically nothing to change it. So I'm here today to challenge
you.  What CAN we do to change our market, minimize our risk, and fulfill
software's promise?  I'm going to talk about a few ideas to get you thinking
about what we CAN do.


1)           We CAN Get Our Priorities Straight


Many organizations spend almost their entire security budget on hacking
stuff - automated tools and pentesting.  That's important but we're not
going to "hack our way secure." We can perform all of our activities in the
context of an organizational risk model.  With this understanding, we can
prioritize what we do, not by what's easy for a tool to find, but by what
actually makes a difference to the business.


We can guide organizations to focus on the most critical problems in the
most critical applications!

And when we find a problem we can't just report it and move on.  We can
track down how that problem happened and eliminate the root cause in the
organization, so the problem never happens again.  That's the path to


2)           We CAN Set a Useful Research Agenda


We have an amazing pool of brilliant security researchers around the world.
But we seem to spend a ridiculous amount of our time searching for obscure
vulnerabilities that would make Rube Goldberg proud.

The really hard research problems are in figuring out what the security
rules should be in the new massively connected, high value asset, cloud
computing models. How do we deal with distributed identity, access control,
encoding, and the rest.


We can create new tools that take a positive approach - verifying that
applications do the right thing - instead of searching for negative
signatures. Talking about research, I need to send a huge thank you to all
the participants in OWASP's most recent Summer of Code. OWASP will be
releasing 31 new tools and documents next month and they are awesome.


3)           We CAN Turn Application Security from a Black Art into a


It's still a black art today. Even with the books, tools, and papers being
written, it is extremely difficult to become an application security expert.
A lot of knowledge is locked up in people's heads.

We need to organize, link, and simplify the knowledge that's out there.
OWASP has hired a technical editor and we're putting ALL of OWASP's content
through a massive refactoring.


Go find Leo Cavalleri and ask him about the OWASP Application Security Desk
Reference - like the physician's desk reference - that captures all the
foundational knowledge in application security. Check out the draft on Lulu.
And find Juan Carlos Calderone to talk about the OWASP Internationalization
Project.  We've internationalized the wiki and have translations for most of
the main OWASP documents - almost a full set in Spanish and many languages
for the Top Ten.


If you just stand around, Dinis Cruz will probably start talking to you
about the OWASP in School Program where we're going to facilitate free
one-day lectures in application security at schools around the world.


4)           We CAN Enable Secure Coding


There are voices in the blogosphere arguing that we should give up on secure
coding and fall back to scanning and virtual patching with WAFs. This is one
possible future.  It's a future of forever chasing vulnerabilities, managing
blacklists, and being frustrated.  I want a future where security is a
primary requirement for applications. Where we follow some building codes
and use standard controls that have high assurance. Where development teams
want our help, and aren't resentful of security. We need more focus on
"building" and less on "breaking." Breaking things is easy.  If you want
some real street cred, secure something and publish the details.


Find Arshan Dabirsiaghi and talk to him about the AntiSamy project. He
tackled an extremely hard problem and now AntiSamy is being used in dozens
of large organizations. Even Microsoft has used this approach in their
AntiXSS project.  We should be pouring more effort into the small number of
security controls that can be used to address the vast majority of
vulnerabilities. If you're interested in standardizing security controls,
I'm easy to find in a crowd and there's nothing I'd rather talk about than
OWASP's Enterprise Security API project.


5)           We CAN Fix the Software Market


Buying software today is like buying drugs off the street - no assurance,
crazy risks. Our developers are totally addicted to new code. I talk to code
junkies strung out on Ajax or Java and jonesing for their next library fix.
Who knows - the code you just bought just might be laced with PHP?


We can't go on blindly trusting applications. As long as security is
invisible, market forces guarantee insecurity.  Before I buy software, I
want some visibility. I want to know what language was used, how many lines
of code, and what libraries and tools were used.  I also want some
information about who built it, what security controls are in place, and how
it was tested.


We can create standards for software buyers to ask for security information
and for software producers to tell them. See if you can find Mike Boberski,
talk with him about the new OWASP Application Security Verification Standard
that defines 4 levels of security review.


6)           We CAN Work with Technology Groups


If you use Mitre's CWE as a rough measure of the number of types of
weaknesses, the score is 695 to 0.  We can make these security mistakes a
lot less likely. We can reach out to groups responsible for key
technologies, like HTML, CSS, Web Services, Flash, Java, .NET, PHP, Struts,
and Rails to help them build easy to use, high assurance security into their


Track down Arshan Dabirsiaghi and talk to him about the OWASP Intrinsic
Security Working Group. We are already building connections to these groups
and providing key recommendations on improving security in their
technology.And it is working.  We've already convinced the Java Servlet Team
to eliminate the possibility of header injection, improve cookie security,
and provide a suite of encoding methods for developers. We're even
discussing building CSRF protection right into the Servlet 3.0 spec!


7)           We CAN Make Application Security into a Movement


If we work together, we have an opportunity to change things.Because no one
else is going to do it.  Look around this room.  If application security is
going to have large scale success, it will be because of the dedicated
people in this room.


Let's compare our progress against the "Agile Movement." We have
conferences, they have conferences, we have tools, they have tools.  We have
process (sort of), they have process (sort of).  I think security is a much
more urgent business driver, so we have an opportunity to be much more
influential than them.


Yet Agile has made major inroads into software development organizations and
we're mostly just preaching.  We can learn a lot from Agile. We can create a
manifesto for application security that everyone can get behind.  And we
should back that up with a clear set of core principles and activities.
Essentially, we need to tell people what a responsible application security
program IS. Otherwise, how will anyone know if they are "doing AppSec" or


If you get a chance to talk with James McGovern, he's started an OWASP
project to define what a responsible application security program looks like
and you're going to see a draft very soon.  It's not too late.  I'm inspired
to be here today with the leading experts in application security and the
owners of some of the most critical applications on the planet.


We Do Have a Choice


None of these things we CAN do will happen unless YOU get involved. I'm
asking you to join in and help us achieve software's promise. It's easy to
start a project, create a local chapter, or just update the wiki. So even if
you don't agree with anything I've said, please join us and help us get it
right.  We can't afford not to!


I'm looking forward to meeting all of you!  Thank you and have a great



Jeff Williams, Chair

The OWASP Foundation

jeff.williams at owasp.org




From: owasp-leaders-bounces at lists.owasp.org
[mailto:owasp-leaders-bounces at lists.owasp.org] On Behalf Of McGovern, James
Sent: Tuesday, January 06, 2009 12:42 PM
To: owasp-leaders at lists.owasp.org
Subject: [Owasp-leaders] Does OWASP need a manifesto?


Ever heard of the Agile Manifesto (http://www.agilemanifesto.org)? The
notion of signatories to a set of principles is one way to drive additional
traffic and gain visibility for OWASP. I like the way that the Cluetrain
Manifesto did it (http://www.cluetrain.com) and believe there are some
themes we can borrow from. Here is one from Solaris
(http://www.save-solaris.org/signatories.html) and another to Microsoft
<http://classicvb.org/petition/signatories.asp?lang=en&page=8> &page=8)


Can we and should we have our own?

This communication, including attachments, is for the exclusive use of
addressee and may contain proprietary, confidential and/or privileged
information.  If you are not the intended recipient, any use, copying,
disclosure, dissemination or distribution is strictly prohibited.  If you
are not the intended recipient, please notify the sender immediately by
return e-mail, delete this communication and destroy all copies.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.owasp.org/pipermail/owasp-leaders/attachments/20090106/07ae1315/attachment-0001.html 

More information about the OWASP-Leaders mailing list