Distilling this down, it looks like just 2 documents need to be worked =
2 and 4 as per the prior posting.
As part of this process, I recommend reading and assessing the "OWASP =
Ten is really the OWASP Top 6.5" post at http://secureme.blogspot.com/ =
past the humour for the meat of the post), then think about the outcomes =
want people/testers to achieve.
Input validation issues, in all its guises and impacts (SQL injection, =
parameter abuse, query abuse, buffer overflows etc)
Denial of service (network, http, app and custom code 'levels')
Authentication and Session management
Configuration management (not really a pen-test thing, imho)
I think we need to discuss way to test at the different app layers i.e.
Infrastrcture (network, switches, firewalls, storage etc) Http, App =
layer, custom-code layer, then database layer
In LAMP/OSS terms, this might mean different techniques of testing and
result analysis aimed at the following:
Iptables, Snort etc
Of course, this list above is useless if the architecture is based on
different products, but I hope you can get the drift.
I'm happier as a reviewer/critique-er of any output from this exercise, =
will can contribute what wording and ideas along the way that I can.
Sent: Friday, 30 December 2005 4:53 AM
Subject: Re: [Owasp-standards] Re: New OWASP project - PCI Web Security
I think that this is a great project and something that we have =
about for a while in the OWASP-Washington chapter. The Top Ten should =
be referenced by other standards like the PCI Standards and the best way =
convince the PCI people is to come up with a better document.
That being said, I think that there should be some clarification what
this Standard is going to address. In my opinion, OWASP has (or should
have) essentially four different but related projects in this
1. A document on how to build secure web applications (we already have =
in the OWASP Guide). Target audience: developers
2. A document with suggested requirements for sourcing web application
development (and corresponding test plans for those requirements). This
would be essentially a distillation of the Guide to just include _what_ =
do, but not _how_ to do it. This seems to be what Mike is going for =
the OWASP Standards project and I think that this is an important =
but not what the PCI standard should reference. I think these =
would be fairly easy to pull out of the Guide and it makes sense for a
direct correspondence between them and the Guide. Target audience: =
who are contracting for web application development
3. A document on how to do a web application penetration test. The =
testing project seems to be going in that direction, but it doesn't seem =
be going anywhere - Part Two was supposed to provide this in detail. =
audience: web application penetration testers / security auditors
4. A document on what should be tested on a completed web application. =
think that this is what the PCI standard should reference. This =
could perhaps be distilled from the testing project. The Testing =
and Part One of the testing project provide some of this, but it doesn't
look complete to me. Target audience: managers who are contracting for =
security audit (and other documents like the PCI standard)
I guess the difference here is that the PCI standard should not =
the existence of requirements or the adherence to a particular =
methodology. It should basically assume that the auditor/tester is =
in at the end of the process when the application is already built and =
wants to look for security issues. It would include traditional black =
testing, but also source code review, etc.
I also think that this standards (2 and 4) should not be specific to =
PCI, but could be used in any web application.
What do you all think?
This SF.net email is sponsored by: Splunk Inc. Do you grep through log =
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
Owasp-standards mailing list Owasp-standards@...