<>p>Jeremiah Grossman, our number one Web security chap, has some interesting words as we jump into 2009:

It’s unanimous. Web application security is the #1 avenue of attack according to basically every industry data security report available (IBM, Websense, Sophos, MessageLabs, Cisco, APWG, MITRE, Symantec, Trend Micro, SecureWorks, ScanSafe, IC3). This is in addition to reports specifically focusing on custom Web application vulnerabilities (WhiteHat Security, WASC, Accunetix). SQL Injection and Cross-Site Scripting are routinely cited as the biggest issues, the ones we can’t apply patches to defend against. Perhaps what we’ve learned in 2008, as pointed out by Gunnar Peterson and Gary McGraw, is we’re spending on the wrong problem. Roughly $150MM in software security products & services versus the lopsided billions annually on network security. 2009 will give us another opportunity to make a difference.

From the mountain of statistics available I’ve saved several interesting quotes to reference in 2009.

He goes on to use quotes from various sources to tell the tale. It appears that most of the attacks are there to put something on your machine. With business models where the malware doesn’t need to popup and try to sell you something, but rather just use you CPU as part of a botnet. The fight will continue in 2009!

I think this is going to become a major item for commercial web app customers in 2009. We recently for the first time were informed by a corporate customer that they would be doing an independent security audit of our web app before deploying it on their network. I suspect some sort of security certification or audit is going to become a mandatory requirement for commercial web apps.

Even for internal-only applications we can’t elevate to production if the code to be elevated hasn’t passed an automated security audit scan and the results attached to the official deployment documentation. That’s been the policy here for nearly a year now, so I think Joeri is completely correct, this is going to be the norm in the industry in short order for, I suspect, ANY application deployed to production, third-party or otherwise, public-facing or not.
.
You can certainly imagine the legal scenarios that may arise out of this too, especially when talking about third-party applications. Should be an interesting ride, if by “interesting” you mean “right up there with an alien anal probe” (just the paperwork alone!)
.
Tangentially, some of the automated testing tools out there today are surprisingly good at catching things you’d never imagine an automated tool could. I suggest all developers, even if there’s no policy that says you have to, get yourself such tools and use them as part of each deployment. To be sure, they’re absolutely not a cure-all, you’ll be dealing with false-positives in many cases and obviously they aren’t going to catch everything, but it seems to me to be a good CYA move none the less… some of those legal scenarios I can imagine could end with YOU being on the receiving end of a lawsuit, especially for you consultant-types.

Err, I *was* going to say WatchFire’s AppScan was the one we use at work that I’ve found to be very good… but, it seems it’s now *Rational( AppScan because watchfire.com redirects to a IBM Rational software security products page that lists it there.
-
Geez, is there any developer tool IBM *won’t* buy and slap the name Rational on?!?
-
So, maybe I should say AppScan *was* very good… IBM/Rational’s track record, in my experience, doesn’t bode well for the future of that product.