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

Sandeep Singh Nain nainsandeep at gmail.com
Mon Jun 8 23:00:01 EDT 2009


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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.owasp.org/pipermail/owasp-guide/attachments/20090609/8e69f9b8/attachment.html 


More information about the Owasp-guide mailing list