[Owasp-leaders] Does OWASP need a manifesto?

Eoin eoin.keary at owasp.org
Thu Jan 8 07:40:44 EST 2009


The only "aside" I'd like to make to Rex's comment is that industry exists
outside the US!!
Global adoption is a better approach as opposed to a US centric approach and
we should focus on ISO/CMM etc in order to gain a global foothold.




2009/1/7 Rex Booth <rex.booth at owasp.org>

> Mike,
>
> That's one of the goals of the Industry Committee - to gain acceptance
> from industry, academia and government. OWASP is already referenced by a
> number of federal agencies as best practices, but we're trying to step
> it up a notch and make it mandatory with a direct reference from OMB or
> NIST.
>
>  From a federal perspective, though, NIST does already encourage
> application security but doesn't specify how to implement it (which I
> think is a good thing, not a shortcoming). If you're in a position to
> influence the way an agency implements or assesses application security,
> it's easy for you to reference OWASP as an "industry best practice
> endorsed by NIST, NSA, DISA, and PCI among others, etc" and work it into
> your audit/assessment/implementation plan. I've done this in a few
> agencies and have received positive results.
>
> Rex
>
>
> Mike Boberski wrote:
> > 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!
> > Mike
> >
> > ------------------------------------------------------------------------
> > *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.
> >
> > --Jeff
> >
> > *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 improvement.
> >
> > *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 Science*
> >
> > 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 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
> > conference!
> >
> > *Contact*
> >
> > Jeff Williams, Chair
> >
> > The OWASP Foundation
> >
> > jeff.williams at owasp.org
> >
> > 410-707-1487
> >
> > *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
> > (http://classicvb.org/petition/signatories.asp?lang=en&page=8
> > <http://classicvb.org/petition/signatories.asp?lang=en&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.
> > ************************************************************
> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > OWASP-Leaders mailing list
> > OWASP-Leaders at lists.owasp.org
> > https://lists.owasp.org/mailman/listinfo/owasp-leaders
> >
>
> _______________________________________________
> OWASP-Leaders mailing list
> OWASP-Leaders at lists.owasp.org
> https://lists.owasp.org/mailman/listinfo/owasp-leaders
>



-- 
Eoin Keary CISSP CISA
OWASP Code Review Guide Lead Author
OWASP Ireland Chapter Lead
OWASP Global Committee Member (Industry)

Quis custodiet ipsos custodes
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.owasp.org/pipermail/owasp-leaders/attachments/20090108/744832ee/attachment-0001.html 


More information about the OWASP-Leaders mailing list