[Owasp-pci-project] PCI 6.6

McGovern, James F (HTSC, IT) James.McGovern at thehartford.com
Thu Jun 4 13:16:07 EDT 2009


Your pre-coffee analysis happens to be more thoughtful than anything
published by industry analysts on this subject to date. Maybe we need to
publish informed opinions as a value proposition...

________________________________

From: Daniel Herrera [mailto:daherrera101 at yahoo.com] 
Sent: Thursday, June 04, 2009 1:11 PM
To: McGovern, James F (HTSC, IT)
Subject: Re: [Owasp-pci-project] PCI 6.6


James,

So I am firm believer that in the scope of web application security we
need to stop looking at whitebox analysis(automagic|manual), blackbox
analysis(automagic|manual), and waf's(auto-learn|manual-config) as
competing technologies.  Each of these technologies have strengths and
weaknesses and I think you benefit the most by leveraging all three.

Ironically I feel the biggest weakness of whitebox analysis or code
review is that it is the least agile. Manually it is one of the more
time expensive processes and once a review is complete that is only a
snapshot of the application attack serface on the code base you
assessed. In the end I feel that in larger organizations code review
gets trampled under the weight of its tasks.

The biggest benefit of whitebox analysis is the degree of visability it
has to the application. There will be vulnerabilities that cannot be
verified through blackbox analysis, but become very clear and proven
once to look behind the curtain. Just as there will be runtime
conditions that whitebox analysus can not see that become obvious
through behaviural analysis or blackbox analysis.

(poke-it-and-watch-what-happens analysis?)

As for waf's, firstly I believe it is still a very juvenile technology
and it needs time to mature before we start trying to stop it. It's
flawed the same way any signature based technology would be, it blocks
what it knows and ignores what it doesn't. The biggest value is, when
configured and managed, it provides an method to immediately mitigate
the risk of exploitation for a discovered vulnerability.  Again
mitigation != provention or remediation, and its the cases misuse or
misunderstand of this technology I think that really drives members of
the security community up the wall. Maybe it would help if people
stopped selling waf's as the "No more code fixes" solution that it
clearly isnt. 

I am going to get more coffee in the hope that it will make future
responses to the list today a little more coherent :).

Thanks,


Daniel

--- On Thu, 6/4/09, McGovern, James F (HTSC, IT)
<James.McGovern at thehartford.com> wrote:



	From: McGovern, James F (HTSC, IT)
<James.McGovern at thehartford.com>
	Subject: [Owasp-pci-project] PCI 6.6
	To: owasp-pci-project at lists.owasp.org
	Date: Thursday, June 4, 2009, 7:28 AM
	
	
	I have observed that many within OWASP don't buy into the
section 6.6
	recommendations that suggest that code review and WAFs are
equivalent.
	Likewise, I have also observed that WAFs are popular in that you
can buy
	a nice shiny box with colorful blinking lights that you can
mount in
	your rack in the datacenter and show executives who don't know
any
	better that you have made progress.
	
	Maybe, one form of guidance is to compare code review and WAFs
through
	the lens of enterprise architecture. What is short-term,
tactical and
	doesn't provide much business lift. It introduces another hop
which can
	increase throughput/performance and likewise isn't doable on all
	applications. Code review can be a better value proposition if
we can
	figure out how to convince others of its long term value.
	
	Other than WebGoat, has anyone ever ran across an insecure but
otherwise
	well performing application that was written within a large
enterprise
	(note I left off shops who develop software as their sole
mission)?
	Security and quality are somewhat two sides of the same coin and
it
	isn't difficult to find business people who thinks that the
performance
	or other quality attributes of their IT systems suck.
	
	We can kill two birds with one stone.
	************************************************************
	This communication, including attachments, is for the exclusive
use of addressee and may contain proprietary, confidential and/or
privileged information.  If you are not the intended recipient, any use,
copying, disclosure, dissemination or distribution is strictly
prohibited.  If you are not the intended recipient, please notify the
sender immediately by return e-mail, delete this communication and
destroy all copies.
	************************************************************
	
	_______________________________________________
	Owasp-pci-project mailing list
	Owasp-pci-project at lists.owasp.org
	https://lists.owasp.org/mailman/listinfo/owasp-pci-project
	


************************************************************
This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information.  If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited.  If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies.
************************************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.owasp.org/pipermail/owasp-pci-project/attachments/20090604/bfbf8570/attachment.html 


More information about the Owasp-pci-project mailing list