Threat Level: green Handler on Duty: Xavier Mertens

SANS ISC: InfoSec Handlers Diary Blog - Internet Storm Center Diary 2007-09-05 InfoSec Handlers Diary Blog


Sign Up for Free!   Forgot Password?
Log In or Sign Up for Free!

Dealing with application in-security

Published: 2007-09-05
Last Updated: 2007-09-06 19:27:18 UTC
by Jason Lam (Version: 5)
0 comment(s)

At the recent SANS Application Security Summit, I had the pleasure to chat with some of the brightest minds in the webappsec field. Aside from educating the developers, everyone seems to agree that we need to roll security into development lifecycle and make sure we test the security aspects of applications before letting them move into production. On the testing front, there has been lots of activity in the product space.

You can have static code scanner which is able to scan code for vulnerability. The approach is obviously more thorough but can generate tons of alerts which could overwhelm the user. Rolling it into the development lifecycle can be a big challenge, organizations are struggling to place it between developer and QA, some organizations are more successful than others. Overall, organizations have to really change their development culture to adopt a static source scanning product.

The runtime analysis tools (commonly known as web application scanners) have been around for a long while. There has been some M&A happening in that space recently (here and here). The principles of application security scanners are simple, you throw the bad input at the application and see how it reacts. Some scanners obviously perform better than others on doing the scanning but at the end of the day, they perform similar functions.

The industry is now waking up to the fact that identifying the vulnerabilities is only the first step, fixing the vast numbers of vulnerabilities in a short period of time while keeping the false positives at bay is ridiculously difficult. Jeremiah Grossman from Whitehat Security revealed in the summit how many vulnerabilities he has seen in the past months, "there's just so many vulnerabilities." This feeling is shared by most others in the field. Most vendors in the testing field are tackling the problem of addressing things at a large scale, answering to the need to find vulnerabilities quickly and accurately across many applications.

False positives is one huge issue that organizations are facing. It is not surprising to have a tool produce a few hundred false positives for one single application. It takes time and expertise to eliminate the false positives. The work of false positives elimination has become a burden for some organization. There is a movement towards service model for vulnerability assessment especially for shops that are lacking app sec expertise. In the service model, the owner of the application get a report of vulnerabilities in the application with most of the false positives eliminated already.

Testing result is still not the end state of securing applications. Finding vulnerabilities is one thing, fixing them is another. Industry is in serious need to have expertise to fix applications, experts who can guide the developer to the proper solution for fixing the vulnerabilities. For lack of a better term, "the application security janitor" A lot of times, the developer just get handed vulnerabilities that they cannot easily fix. Some vulnerabilities are not even meant to be fixed by the developer as those flaw are introduced at the design time (eg. lack of encryption). Some of those tasks require going back to the drawing board (involving the architects) to fix. This is where the "janitor" role get to become very useful in helping to distingush the flaws and assist in getting the right parties involved.

As the goal of application security had been well defined, the industry is slowly moving towards the goal while figuring out the exact path to get there.

Shameless plug: SANS published two videos (video 1 and video 2) related to AJAX security on Youtube (featuring Johannes Ullrich and myself)

Keywords:
0 comment(s)
Diary Archives