[Owasp-leaders] Does OWASP need a manifesto?
rex.booth at owasp.org
Thu Jan 8 10:14:53 EST 2009
(disclaimer - this is a US Federal-centric reply)
True, but I highly doubt you'll ever see a contract specifically require
OWASP-based assessments. I've responded to dozens of contracts over the
past few years, and even those who very obviously require an 800-53
approach (or something similar) hardly ever specify as such. There are
simply too many degrees of separation between the knowledgeable
technical resource and the person writing the contract. The best-case
scenario (in my opinion) is one in which a regulation or NIST points to
OWASP standards and you receive an RFP asking for help fulfilling the
requirements of that regulation.
The onus is on us as service providers to be aware of industry best
practices (like OWASP) and to creatively work them into the solutions we
provide our clients. IMO, doing so is perhaps as important as any other
promotion activity OWASP undertakes. Not only do we have the
opportunity to raise awareness of the OWASP brand and "products", but we
also have the opportunity to demonstrate them in action - the latter
goes a long way in developing support for OWASP among those whom we seek
to be regulated by it.
Mike Boberski wrote:
> Unfortunately lots of folks live by the mantra of if it's not in 800-53 etc.
> then it's not a project task, requiring creative solutions as you suggest.
> That's in my mind like dating someone who says they're leaving their spouse.
> Yes it may be ok for a while but it's seldom a venture that works out in the
> end. I want to see contracts and legislation that say they require OWASP
> ASVS Level x, using OWASP project methodology y for ASVS task z.
> -----Original Message-----
> From: owasp-leaders-bounces at lists.owasp.org
> [mailto:owasp-leaders-bounces at lists.owasp.org] On Behalf Of Rex Booth
> Sent: Wednesday, January 07, 2009 10:12 AM
> To: owasp-leaders at lists.owasp.org
> Subject: Re: [Owasp-leaders] Does OWASP need a manifesto?
> 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.
> 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!
>> *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
>> 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
>> 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
>> 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
> OWASP-Leaders mailing list
> OWASP-Leaders at lists.owasp.org
> OWASP-Leaders mailing list
> OWASP-Leaders at lists.owasp.org
More information about the OWASP-Leaders