[Owasp-guide] Comments

Boberski, Michael [USA] boberski_michael at bah.com
Tue Jan 12 13:45:20 EST 2010


Hi Pekka. Great points! 

Two comments below caught my eye in particular, to paraphrase:

* How will requirements be deprecated?
* Where will tables that define e.g. document codes be located?

For the first item, the short answer is that I don't know, we've not yet talked about this, other than how it might work from an identifier perspective. There should be some discussion about this on the wiki page though, at least as a placeholder.

For the second item, again I don't know, we've got it on the one wiki page, we've not yet talked about this. Perhaps that is sufficient, keeping it as an article linked to the ASVS project, perhaps something additional/different will need to be done.

Any other comments, keep 'em coming!
 
Best, 
 
Mike B.

-----Original Message-----
From: Mike Boberski [mailto:mike.boberski at gmail.com] 
Sent: Tuesday, January 12, 2010 8:23 AM
To: Boberski, Michael [USA]
Subject: Fwd: Comments

---------- Forwarded message ----------
From: Pekka Sillanpää <pekka.sillanpaa at nixu.com>
Date: Tue, 12 Jan 2010 09:41:37 +0200
Subject: Comments
To: mike.boberski at owasp.org

Hello!

I like the idea of a global/common unique identifier for the requirements to be shared within all Owasp documentation! I also like the idea that you can directly see which requirement category is in question.

As you requested comments, I have some ideas that could be considered.
In my opinion, the current suggestion does not well address this
principle:
"carefully consider the range of values that your ID space supports, and if possible, allow it to expand"

Some questions:
- Which are the benefits of a static length? Why not to "allow it to expand"?
- How is DEPRECATED used? (in asvs, what code does the replacing requirement get?) Why is it included in the id, if it's deprecated (no- one will use such id:s anyway)? I would not include this in the identifier syntax, but there should definitely be a table that shows also deprecation with a "deprecated by" field.
- What if a category becomes deprecated?
- How is the "grand table of identifiers" maintained with all deprecated id's etc.?

I would consider e.g. the following format for a Common identifiers that could be referenced with similar syntax in any document .

OWASP-x-y(-v)

x = requirement category (e.g. 4 for Access control) y = requirement number (e.g. 5 "Verify that directory browsing is disabled unless deliberately desired.") v = version (e.g. 1) (latest, if not shown)

Which would make it OWASP-4-5-1.

This way, new categories could be created easily. And as a new is invented, it would be just OWASP-(n+1). Similarly, when a new requirement is invented, it's just OWASP-n-(m+1)-1. In the future, if some requirement seems to better suit in another category, it will get the next "free slot" in that category's number space. (and gets "deprecated by" tag in the previous category)

The structure of every release of ASVS or any other document could be different, if the identifier was not directly tied with the hierarchical order of the document. This way it would also be easier to change the structural order of the requirements to more logical in the future, if required.

Every time the requirement text changes (e.g. to more specific, in the next ASVS release), the last number is increased by one.

It is probably a good idea to give a unique identifier (document code) for each document as well, and let each document to specify their own identifier space e.g. DG-v1.x-DV-005 for mapping with OWASP-codes. But could this just be a separate mapping table instead, with a column for each document? Would this be any better than having multiple identifiers pointing to the same requirement in the same namespace?

I am not sure, if this kind of "safety" is required, or if the syntax I suggested is any better, but I just wanted to think how this syntax will work in the future, as changes will happen anyway.

Thanks for the good work!

Regards,
Pekka




--
Mike


More information about the Owasp-guide mailing list