[Owasp-leaders] Does OWASP need a manifesto?

Jeff Williams jeff.williams at aspectsecurity.com
Wed Jan 14 07:25:26 EST 2009

Hi James,


Actually I wasn't suggesting that those seven were the manifesto.  They
were just a list of things that are possible for us to do.  #7 is make
appsec a movement, which I think we should focus on.


A movement should have a name and a manifesto.  The name is important -
Agile Development, Green Computing, etc... and we don't have one.  If it
doesn't have a name, it's difficult for people and companies to "adopt".
The manifesto should be more like the Agile Manifesto, state our
collective beliefs, such as:


*        Assurance generated across the lifecycle over testing at the

*        Proven security controls over custom development

*        Priorities based on business risk over checklists and

*        Transparency about security over secrecy and contracts


"That is, while there is value in the items on the right, we value the
items on the left more."




From: owasp-leaders-bounces at lists.owasp.org
[mailto:owasp-leaders-bounces at lists.owasp.org] On Behalf Of McGovern,
James F (HTSC, IT)
Sent: Monday, January 12, 2009 5:16 PM
To: jeff.williams at owasp.org; owasp-leaders at lists.owasp.org
Subject: Re: [Owasp-leaders] Does OWASP need a manifesto?


Everything is important, but what is more important?


Do we believe that static analysis and rigorous code review is more
important than pointing blackbox scanning tools? Should the list be more
like the agile manifesto to help folks realize what is more important?


One could realize that we are also become our own worst enemy. Our
methodologies are way too rigorous. How do security folks embrace agile
software development especially when they might not have ever written a
single line of code?


I kinda cringed on #2 as I would acknowledge that it needs to exist but
could never really champion this type of activity. Maybe, we should
simply acknowledge the value proposition of sharing experiences? For
example, if the guys at Sovereign Bank wanted to pick my brain, I would
be more open than say some vendor who later wanted to sell me something.
More importantly, could we twist this into something more actionable. I
have always said that Government Enterprise Architecture is a big fat
joke but in all reality, I don't know how they could learn from us or
vice versa.


for #3, I feel that there is merit in teaching security in universities
and am definetely an advocate but believe that this is still incomplete.
If you were to survey OWASP chapter leaders and ask what their majors
are in, I bet the vast majority of us aren't computer science (FYI,
mines is business admin). Security needs to be a lifelong activity. We
need something in the spirit of continual education kinda like the CISSP
but only credible.


For #4, have the problem with security isn't the code but is do to some
bozo enterprisey architect drawing bad cartoons and calling them design.
Can we somehow have a conversation that starts with requirements,
information protection policies and design patterns? I have drunk the
Kool-aid and believe that code can be generated but design can't.


For #5, part of the call to action is one of what Doc Searls refers to
as vendor relationship management. It isn't just about point-to-point
relationships but changing the model as to how end customers interact
with vendors. The word "influence" sometimes works, sometimes doesn't.
Maybe a collective that can throw vendors under the bus is what will
help move the needle (aka bad press that is consumable by the masses)


for #6, don't think reaching out to tech groups is sufficient. I believe
we need to reach out to non-tech groups who can aid in our evangelism.
How can we encourage the Society for Information Management (SIM), and
other executive "roundtables" to pay attention. Stop talking about techy
stuff (point #1) and start talking about things in context of business



From: owasp-leaders-bounces at lists.owasp.org
[mailto:owasp-leaders-bounces at lists.owasp.org] On Behalf Of Jeff
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 cyberspace!


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 platform.


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 not?


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


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 F (HTSC, IT)
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


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.
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/20090114/58d0b903/attachment-0001.html 

More information about the OWASP-Leaders mailing list