Comments on: OWASP 2008 and Fortify http://www.itsecpackets.com/blog/2008/10/06/owasp-2008-and-fortify/ A Progammer explores the IT Security field; offering packets of useful information he picks up along the way. Tue, 05 Jan 2010 01:34:42 -0700 http://wordpress.org/?v=2.8.4 hourly 1 By: John Moyaree http://www.itsecpackets.com/blog/2008/10/06/owasp-2008-and-fortify/comment-page-1/#comment-355 John Moyaree Tue, 05 Jan 2010 01:34:42 +0000 http://itsecpackets.com/blog/?p=59#comment-355 There is also this program which I recommend: http://www.netsparker.com/ There is also this program which I recommend: http://www.netsparker.com/

]]> By: Ben Rothke http://www.itsecpackets.com/blog/2008/10/06/owasp-2008-and-fortify/comment-page-1/#comment-257 Ben Rothke Wed, 08 Oct 2008 16:49:06 +0000 http://itsecpackets.com/blog/?p=59#comment-257 Ron, As always, good post on a timely topic. I am not an applications guy, but in speaking with those who are experts in that area, one thing they caution is for people to put too much trust into the app scanning tools. One issue of many is that the tools often don’t catch code logic errors. While they can easily identify the common family of application errors (for a good list, see www.ouncelabs.com/pdf/Redefining_Software_Security_Audit.pdf), what happens when the code is perfect, yet failures due to errors in the design, construction, or use of the system cause it to fail under particular combinations of conditions? Really tough problem for which there are no simply answers or software tools to fix. Ben Ron,

As always, good post on a timely topic.

I am not an applications guy, but in speaking with those who are experts in that area, one thing they caution is for people to put too much trust into the app scanning tools. One issue of many is that the tools often don’t catch code logic errors.

While they can easily identify the common family of application errors (for a good list, see http://www.ouncelabs.com/pdf/Redefining_Software_Security_Audit.pdf), what happens when the code is perfect, yet failures due to errors in the design, construction, or use of the system cause it to fail under particular combinations of conditions?

Really tough problem for which there are no simply answers or software tools to fix.

Ben

]]> By: Erik Klein http://www.itsecpackets.com/blog/2008/10/06/owasp-2008-and-fortify/comment-page-1/#comment-256 Erik Klein Mon, 06 Oct 2008 18:20:09 +0000 http://itsecpackets.com/blog/?p=59#comment-256 Ron, Glad we had a chance to meet and talk at OWASP. I received a link to your blog through two other intermediaries, one of which read your blog and forwarded it to our company. I’m glad that you were able to get a copy of Fortify SCA at your company (though I can’t remember which firm you’re with). Thank you for the positive write up on your blog of our static analysis product. I’m not sure of the license that your company has with Fortify, but you may to check to see if you also have access to Fortify PTA (Program Trace Analyzer). You may recall from our discussion that this analyzer is a grey-box runtime (rather than static) analyzer that works against a running Java or .NET web application. The unique proposition that PTA provides is that it identifies security vulnerabilities in your application without the need for you to attack the application … all you need to do is run any type of standard quality test against it … anything from sanity testing to full blown automated regression testing … basically, the testing you need to do ANYWAY only with PTA you get Security Results in addition to the Quality Results. Then the results can be exported into your defect tracking system and viewed/merged with the SCA results in Audit Workbench or your IDE. Taking it a step further, it can even be used to help reprioritize the SCA results that you have received since there is runtime evidence of the ability to exploit such vulnerabilities. http://www.fortify.com/products/detect/in_testing.jsp Best wishes, Erik Klein Software Security Consultant (W) 732-936-0573 (M) 650-810-6102 (F) 650-358-4708 Fortify Software Local: NY/NJ/CT/PA/DE Area HQ: 2215 Bridgepointe Parkway, 4th Flr San Mateo, CA 94404 USA www.fortify.com Ron,

Glad we had a chance to meet and talk at OWASP. I received a link to your blog through two other intermediaries, one of which read your blog and forwarded it to our company. I’m glad that you were able to get a copy of Fortify SCA at your company (though I can’t remember which firm you’re with). Thank you for the positive write up on your blog of our static analysis product.

I’m not sure of the license that your company has with Fortify, but you may to check to see if you also have access to Fortify PTA (Program Trace Analyzer). You may recall from our discussion that this analyzer is a grey-box runtime (rather than static) analyzer that works against a running Java or .NET web application. The unique proposition that PTA provides is that it identifies security vulnerabilities in your application without the need for you to attack the application … all you need to do is run any type of standard quality test against it … anything from sanity testing to full blown automated regression testing … basically, the testing you need to do ANYWAY only with PTA you get Security Results in addition to the Quality Results.

Then the results can be exported into your defect tracking system and viewed/merged with the SCA results in Audit Workbench or your IDE. Taking it a step further, it can even be used to help reprioritize the SCA results that you have received since there is runtime evidence of the ability to exploit such vulnerabilities.

http://www.fortify.com/products/detect/in_testing.jsp

Best wishes,

Erik Klein
Software Security Consultant
(W) 732-936-0573
(M) 650-810-6102
(F) 650-358-4708 Fortify Software
Local: NY/NJ/CT/PA/DE Area
HQ: 2215 Bridgepointe Parkway, 4th Flr
San Mateo, CA 94404 USA
http://www.fortify.com

]]>