[OWASP-TESTING] Comment on testing guide and contrib for part 2

Mark Curphey mark at curphey.com
Wed Aug 4 06:49:05 EDT 2004

I think there are a couple of things that might be worth considering. 

1. Consider testing to be split (down the road) for 3rd party reviews and 1st party reviews. 

The original intent of this project was from a 1st party perspective ie I wor for bank x and want tobuild a testing program for my own company.

I guess we have mainly people who do third party reviews on the list.

2. Gary McGraw says it best;

"If you fail a penetration test you know you have a problem. If you pass a penetration test you have no idea that you dont have a bad problem."

I am working on building some tools that benchmark the automated scanners. You know they typically find less than 10% of vulns in a standard site right ?

---- orac <orac at uncon.org> wrote:
> Hi Mauro,
> I have a similar issue in when I can get at the SDLC for testing. The
> end-user organisation I am working in at the moment officially "does not
> do in-house development". All the line of business applications (And
> there are many) are sourced from external vendors and the closest we get
> to a SDLC is the system design stage where off-the-shelf components are
> glued together. 
> There is a certain amount of completed system penetration testing but I
> am finding the value of that to be fairly low as the vendors either
> cannot fix the bugs at that late stage or want so much money to do it
> that the business decides to take the risk.
> I am seeing some value in component level tests during the design phase.
> The result being that we may not be able to alter the source of a COTS
> component but if we spot the problems early enough we can architect
> around them in the glue code. 
> Due to the fact that these are limited in scope and custom to the
> component and it's role in the architecture they tend to be tested
> in-house as it is barely worth it for a 3rd party testing company to get
> involved. 
> Given the time and cost of code reviews we just don't get to do them
> unless serious problems are thrown up by any testing that is performed.
> It is a frustrating position sometimes that could be helped by having
> automated scanning tools for glue-code languages like (in my experience
> here) ASP, JSP, T-SQL and PL-SQL. Being able to at least run an
> automated scanner over code that is unlikely to be manually reviewed can
> at least identify vendors who have code quality issues that can then be
> used as justification for more detailed work.
> Anyway just throwing in the perspective from the end users.
> Regards
> Orac
> <snip>
> > Concerning SQL Injection, actually those
> > vulnerabilities were
> > found and exploited during pen tests (all of them).
> > In my experience, clients are not very keen in having 
> > grey/white box assessments, not to mention let you snoop 
> > through their code. I'm not saying they don't do this, but 
> > usually when we were called in it was for pen test or 
> > application assessments black-box style. People dealing with 
> > security - the guys who called us
> > - usually managed deployed applications;
> > intervening in the SDLC is somehow harder for an
> > external organization,
> > partly because one tends to "wash dirty laundry at
> > home", as an
> > italian saying puts it.
> > Maybe others have different experiences...
> > 
> > Mauro
> > 
> <snip>
> -------------------------------------------------------
> This SF.Net email is sponsored by OSTG. Have you noticed the changes on
> Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
> one more big change to announce. We are now OSTG- Open Source Technology
> Group. Come see the changes on the new OSTG site. www.ostg.com
> _______________________________________________
> owasp-testing mailing list
> owasp-testing at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/owasp-testing

More information about the Owasp-testing mailing list