JD

So for us the solution of havinf a tools that provide us with monthly reports and defirential report is a great security issue.

D

Thanks for reminding us of this reality. I believe these are actually parallel efforts. We must acknowledge, understand and put into motion efforts to produce and procure more secure applications. At the same time, we have inherited a legacy portfolio of insecure apps in production that are very likely insecure. These must be tested as well, ASAP especially for those that are externally accessible and host sensitive data. Its likely the security organization that will take on this responsibility and DAST tools are a way to do this.

To take this further, if the DAST tools find a vulnerability in an already-deployed app, what do you do? That’s where the discussion of WAFs as a short-term shield came in:

http://blogs.gartner.com/neil_macdonald/2009/08/19/security-no-brainer-9-application-vulnerability-scanners-should-communicate-with-application-firewalls/

That created a lot of discussion, but I remain convinced of the value of WAFs for this (and a few others that are in the comments) scenario.

Current generation DAST have arespectably low false positive rate and do, as the article points out, provide efficiency and repeatability in the testing process. As a result, they can be used to produce reasonbly high quality metrics. Metrics are an excellent tool to drive change.

The problem most security practitioners face is slow adoption which, at least in part, results from weak management buy-in. In trying to build a secure application practice or to improve the maturity of a development process, it makes great sense to start with something that can produce straight forward metrics that can be redily communicated to management.

I believe that incorporating DAST early in the growth of a SSDL can help to demonstrate value and improve the chances of long term success.

Agree that web application security testing tools can’t prove an application is secure. But, neither can the full SDLC process changes. There is no silver bullet.

Given the choice between doing nothing and only doing web application security testing after-the-fact, I’d take the testing.

Given the choice between doing web application security testing after-the-fact and doing the full SDLC process changes you describe, there is no doubt I’d go with the full SDLC process change.

The latter gives a higher degree of “trustability” in the application…

DAST/SAST tools are a great way to reduce outside attacks, as most of these attacks are based exactly in the same rules the tools are made for (ie.: SQLi, XSS, XSF, …).

Unfortunately, we have another threat that come from “inside the company” (example: the system analyst or the developer himself) that knows many more about the software (and the systems that hosts it) them anyone… Of course, an attack that came from these guys can’t be stimulated or reproduced with no tool…

My point is: If you can trust your people and apply a secured SDLC, secure coatch, culture, etc., the use of a DAST/SAST tool can help a lot the production of secure code… but if you didn’t, do your homework first or no tool can help you.

Another thing is: If your company likes to use outsource staff to develop, consider pay more for a “trusted” (or at least a big) company, as the have CMM, and well defined process to develop and review the code. Please, eliminate the “small companies” (one-team guy) from your process to develop sensible software or software that connects to sensible systems… Otherwise, you can find some Easter eggs where you won’t like to.

Thanks a lot,

Mario Lacroix