Filed under: IIS & HTTP
Tags: WAF, web application firewall, Web Security Tools
The Information Security community has been buzzing this week with talk of the newly released CWE/SANS Top 25 Most Dangerous Programming Errors. The goal of the report is to identify not just security vulnerabilities (think OSASP Top Ten), but the programming errors that create those holes.
The result is much discussion about preventative coding (the state of New York has already drafted requirements for future government web applications based on this list). The idea is to get software developers to certify in writing that their code is free of the errors mentioned in the list, SANS said.
While everyone in InfoSec is thrilled with any improvement in security-minded programming, those of us on the ground know this isn’t the end of the story. It helps, but a layered security approach is still key. Even top-notch coding from here on out won’t eliminate the need for a good Web Application Firewall:
- First, there’s a time gap between finding a hole and writing the fix — In a recent blog post, Jeremiah Grossman summarized some advice in a great informIT article: “Use WAFs to quickly reduce the immediate exposure (time-to-fix), then fix the root cause (the code) as time and budget allow.”
- Second, there’s always the problem with legacy code — even the best of best practices can’t use time travel to go back and fix problems in legacy code; practically, what you face is a choice between costly refactoring of that code under the new policies or using a WAF.
- Third, it’s hard to control what you don’t write yourself — a lot of Web apps use and depend on 3rd party components and while you can certainly beef up your due diligence to try to make sure the vendor uses best practices (which is the point of the report), ultimately you rely on trust — and ‘trust but verify’ is better than ‘trust and hope for the best’
- Finally, some vulnerabilities might require solutions at the architecture layer rather than in implementation. This is clear if you look at the “prevention and mitigations” sections of the Top 25 list. The most diligent coders can’t overcome fundamental application vulnerabilities by, say, writing really secure classes and functions. In cases like this, even refactoring existing code under a regime of best practices might not be enough; you might be looking at starting from scratch.
All of these scenerios are common enough to be proof that WAF’s aren’t going anywhere anytime soon. That said, hopefully these new changes will mean insecure legacy code will eventually find itself extinct.
Jenny @ Port80 Software
PS – If you’re in the market for a good WAF, you know where to turn… Port80’s ServerDefender1 Comment »