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

Mon Jun 8 22:42:56 EDT 2009

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