[Owasp-testing] Add new tools
dinis.cruz at owasp.org
Tue Sep 22 05:01:52 EDT 2009
Great thread and comments
Technically speaking how are you going to store the tool's metadata?
We really need this to be on a 'consumable format' so that we can
create multiple WIKI views.
I recomend that you use the new 'Template driven WIKI' solution we
came up at the GPC to manage Owasp projects :)
You should also check Wikipedia for examples on how to present this
type of information
On 21 Sep 2009, at 23:08, Vishal Garg <vishalgrg at gmail.com> wrote:
> Hi Juan,
> Thanks for your suggestions on OWASP Tools Project. This feedback is
> very useful to us as an assurance that we are working in the right
> direction and to pin point any issues that we might have missed. The
> points mentioned in the mail below are very valid points and infact
> we have already discussed some of these points on the project's
> mailing list. Please see my comments in the mail below.
> On Mon, Sep 21, 2009 at 2:52 PM, Calderon, Juan Carlos (GE,
> Corporate, consultant) <juan.calderon at ge.com> wrote:
> Hello Guys
> Here are a few challenges and proposed solutions as I though on this
> the past for OWASP.
> All the time I see a tool list my first question is "which of this
> (regardless of license) is best?", I am a lazy person and wonder
> this so
> I don't have to spend lots of time with the ones in very early
> stages or
> with very limited scope. And that question is the one OWASP cannot
> answer without falling in "preferring" (no mater how big, colorful and
> blinking the disclaimer is) an specific tool. To solve this problem I
> recommend you not only list the tool, but link to sites with reviews
> that tool.
> Actually I myself had the problem of finding a best tool for a
> particular job and that was my main reason to start this project.
> Therefore we just wouldn't be listing the tools in different
> categories, but we'll also be defining a rating criteria to rate
> these tools. We are still working on defining the rating criteria
> and the different possible ways to rate these tools:
> - We may rate the tools ourselves.
> - We may seek other users' feedback based on their experiences
> - and we may also seek other independent reviews, as suggested by
> you here.
> Notice that regardless of how useful is one over another we should
> always list them alphabetically or any other "democratic" way without
> taking in consideration those reviews. People will tend to add their
> old, clunky or to-be tool in the list as an intend to catch attention
> and there is nothing you can do to remove them. But at least having
> reviews from other independent sources will put them apart since it is
> fairly hard they have any.
> As we'll be listing both commercial and open source tools, we want
> to keep this as unbiased as we can, and thus would only be listing
> the tools in alphabetical order. We'll be listing the tools in
> different categories as mentioned by you below and any information
> related to the tools would potentially be listed in a tabular form.
> So the intended structure would be to have the category as a heading
> (such as scanners, sniffers, proxy, WAF etc.), then listing all the
> tools in that category in an alphabetical order along with all the
> properties of a tool in a tabular form.
> The idea is to not allow the list to be too big and clutter with
> or partially working tools or it will be easily dismissed.
> We have decided to include only the release quality webapp related
> tools in the list. We are also going to take great care that only
> properly working tools are listed here.
> Mentioning the license is fine but do not use that as a category, use
> the tool type instead (port scanner, sniffer, App Firewall, etc). I
> putting that information in a table as the license type that is fine
> do not put it as a header before the actual list or you will tend to
> have "Commercial" before "Open Source". But if the tools are listed
> alphabetically and the license is mentioned in a column then maybe you
> have a good mixture to avoid any appearance of biasing the list (I
> is not the objective).
> Having a table is also a good idea as it allows you to show much more
> information like the technologies and platforms supported, the version
> and release level (Alpha, Beta, RC, production) and much more.
> All this has already been discussed on the project mailing list and
> would soon appear on Wiki as well.
> One final one, specialize the list, this is, make sure you focus
> exclusively in tools for web applications as there are hundreds of
> for network security and you will end up being another security tools
> list on the net.
> Yes, you're right, and surely we'll only be discussing about tools
> that are related to web application security and nothing else.
> Good luck, I hope it helps,
> Juan C Calderon
> -----Original Message-----
> From: owasp-testing-bounces at lists.owasp.org
> [mailto:owasp-testing-bounces at lists.owasp.org] On Behalf Of Pavol
> Sent: Domingo, 20 de Septiembre de 2009 04:11 p.m.
> To: dinis cruz
> Cc: Paulo Coimbra; owasp-testing at lists.owasp.org
> Subject: Re: [Owasp-testing] Add new tools
> On Sun, Sep 20, 2009 at 10:05:12PM +0100, dinis cruz wrote:
> > This information on tools is valuable to our community, the
> challenge is
> > to do it in a way that we keep our 'vendor independence'
> For this reason I think we should distinguish between opensource and
> commercial tools (maybe prefer opensource tools).
> Pavol Luptak, CISSP, CEH
> OWASP Slovakia chapter leader
> Owasp-testing mailing list
> Owasp-testing at lists.owasp.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Owasp-testing