[Owasp-guide] ASVS 1.0 Released - Time to Move

Mike Boberski mike.boberski at cox.net
Mon Jun 8 22:59:02 EDT 2009

Thanks so much for your ASVS support!!

I'd like to offer minor note, that the info you're proposing isn't "lacking"
in ASVS, it is out of scope of ASVS.


On Mon, Jun 8, 2009 at 10:42 PM, Andrew van der Stock <vanderaj at owasp.org>wrote:

> Hi there,
> *Call to Action!*
> I am pleased to see the ASVS 1.0 Release Has occurred. What I would like is
> for folks to grab the ASVS 1.0 Release, and let's go through each of the
> Guide's major chapters, and bring it into line.
> We need to re-write the Guide to be positive about ASVS verifications and
> provide the detail the ASVS lacks. I would like it if we could stick to the
> ASVS's headings to make a mapping possible. If we have additional material
> (historical or not yet in the ASVS), it should come after the ASVS controls.
> This will allow us to make a call as to whether it survives or we ask for it
> to be included in ASVS 1.1.
> *Long term - the Guide needs a new leader. *
> You might have noticed, but I don't have a lot of time due to family
> commitments. It's time to hand the baton over. This time, I'm only going to
> project lead until we can find someone to replace me. I asked the relevant
> folks last month to find a new leader, but I've not heard anything back, so
> let's do it the old fashioned way - doing some work.
> **The way to become the Guide project leader is by DOING. It's how I got
> the job. This is a meritocracy. I want to see contributors produce their
> best work, provide a strong conceptual model and commitment to research -
> don't just parrot received wisdom - you should demonstrate why the received
> wisdom is good, or even better, come up with a stronger model through
> research and development. For example, back in 2004, I researched exactly
> why questions and answers were so bad and did some basic research as to how
> strong they are (roughly equivalent to a 9 bit password). That's why Guide
> 2.0 has language against them.
> Once we have been through this process, I will be making recommendations to
> the OWASP Leaders / Global Projects committee as to who will take over the
> Guide. Of course, I am one voice, but realistically, demonstrating to
> everyone why you should be chosen is easy if you've done high quality work,
> and lots of it.
> *What needs to happen between now and then*
> The ASVS 1.0 has controls like this:
> V8.1 - Verify that the application does not output error messages or stack
> traces containing sensitive data that could assist an attacker, including
> session ID or personal information
> So in the Error Handling section, we need to discuss design (how to design
> an error handling system that simply cannot disclose such error messages to
> the screen or user traffic (i.e. headers, cookies, hidden comments or
> variables, viewstate, etc) and then how to do it using ESAPI (if possible)
> or if ESAPI doesn't do that, then some snippets that *actually* work in at
> least J2EE, .NET and PHP.
> We need to ensure our positive controls meet ALL of the ASVS requirements.
> Edits should come to the list, so we can all see them. Do not change the
> Wiki. As we need to move things carefully as folks have deep linked us
> outside, I will be asking Larry our Wiki guru to help me create the final
> 3.0 version in the Wiki. So let's just do the text file thing and send them
> to this list. Once we have a new structure that meets the ASVS requirements,
> I will put the edits into the Wiki.
> *I need at least 14 authors for this version.* If you've done work for me
> in the past, such as the folks who did some work on the session management
> and SQL chapters, can you please re-do it based on the ASVS?
> V1 Architecture - S
> V2 Authentication - L
> V3 Session Management - L
> V4 Access Control - L
> V5 Input Validation - L
> V6 Output Encoding - L
> V7 Cryptography - Specialist
> V8 Error Handling - M
> V9 Data Protection - S
> V10 Communications Security - M
> V11 HTTP Security - S
> V12 Security Configuration - S
> V13 Malicious Code - S
> V14 Internal Security Verification - S
> S = Short < 8 controls, M = Medium 9-13 controls, L = Long 13+ controls
> When you ask for a chapter, please reply to this list with a brief outline
> of how you'd approach each of the topics covered in the ASVS, and if there's
> existing material you can use or adopt. Chapter adoption is on a first come
> first served basis. You'll have two weeks (short topics), three weeks
> (medium topics), and four weeks (long topics) to provide a first draft to
> the list. Please submit your draft here, and we'll all look at it together.
> It doesn't have to be perfect, and we're all here to make it the best it
> possibly can be.
> DO NOT LET PERFECT GET IN THE WAY OF GOOD. Release whatever you have at the
> end of your deadline. That allows us to give that work to someone else to
> continue so it's not wasted if you can't continue. Let us know as early as
> possible if you can't do the work you've been assigned so we can re-assign
> it as quickly as possible.
> If you need help with what a control should say, that's what this list is
> for. Don't hesitate to ask. There's a lot of really talented folks on this
> list.
> Each chapter author can re-use what we already have (and I encourage this),
> but you need to re-write it to be completely positive. Think like a
> developer - is there ANY information in there that is better off in the
> testing guide or the code review guide? If so, let us know and I'll help get
> it across to that reference unless it's already there (in which case we drop
> ours). There's no point in telling a developer what NOT to do. Tell them
> ONLY *what to do*. They can only code the stuff we want them to do.
> Bad:
> Don't log credit cards.
> *Good. *
> Log non-sensitive information - as necessary - to provide accountability.
> Non-sensitive information includes usernames, actions, and so on.
> Log sensitive information carefully in a highly protected logging
> mechanism. For example, If you are going to create an audit log of credit
> card transactions, please review PCI DSS 1.2 requirements as to separation
> of protected data elements and storage requirements. Such usage usually
> requires encrypted logs, and high levels of protection such as access
> controls, and so on.
> *Is anyone here good at diagrams?* If so, please let me know as we need a
> lot of diagrams in EXACTLY the same style the entire way through.
> *Deadline - OWASP USA 2009 - November 10-11 2009. *
> *
> *
> This means:
> * Early drafts should be posted to this list by the end of July
> * Final drafts should completed and be in the Wiki by no later than end of
> August
> * Diagrams and snippets should be in by no later than end of September
> * Final edits done by end of October so we can release to the translators
> * Word and PDF version will be put together by me by the conference
> thanks,
> Andrew
> _______________________________________________
> Owasp-guide mailing list
> Owasp-guide at lists.owasp.org
> https://lists.owasp.org/mailman/listinfo/owasp-guide
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.owasp.org/pipermail/owasp-guide/attachments/20090608/5b1d19c6/attachment-0001.html 

More information about the Owasp-guide mailing list