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

Gary Wong garywhw at gmail.com
Mon Jun 8 23:12:55 EDT 2009

Thanks but i would like to remove all mailing list. Kindly remove me, thanks
May your work be extended too ;-)


On Tue, Jun 9, 2009 at 11:00 AM, Sandeep Singh Nain
<nainsandeep at gmail.com>wrote:

> Hi Andrew,
> I'll be more than happy to *REDO *the SQL chapter (Guide to Data Security)
> I wrote as per your advise. So it will be "V9 Data Protection" chapter for
> me.
> Kind Regards
> Sandeep
> On Tue, Jun 9, 2009 at 12: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
> _______________________________________________
> 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/20090609/a1021e01/attachment-0001.html 

More information about the Owasp-guide mailing list