Enterprise firewall protection: Where it stands, where it's headed
A comprehensive collection of articles, videos and more, hand-picked by our editors
NATIONAL HARBOR, Md. – Enterprise information security teams have long tried to champion secure software development,...
but for many it’s been a losing battle. That’s why one Gartner Inc. analyst believes it’s time to shift the strategic emphasis toward fortifying applications with Web application firewalls as part of broader application security architectures.
I have an increasing number of customers starting to question whether putting a Web application firewall in front of an application to fix something is all that much worse than fixing the code.
Ramon Krikken, Gartner Inc.
During a secure application development strategy session last week at the Gartner Security & Risk Management Summit, speaker Ramon Krikken, a research vice president with the Stamford, Conn.-based firm, said plainly that the state of enterprise application security isn’t good.
Krikken cited statistics from WhiteHat Security Inc. indicating that, as of last year, nearly one out of every three Web applications is vulnerable to SQL injection attacks, and more than two out of three Web apps contain cross-site scripting flaws. Similarly, WhiteHat estimates the banking industry, cited by Krikken as perhaps the best vertical at patching applications, would still need 400 days to patch 90% of the flaws in its applications.
“There isn't a lot of research on this beyond surveys, but from a lot of anecdotal evidence, from my discussions with customers and colleagues, it seems there isn't good collaboration” between enterprise security and development teams, Krikken said. “Security guys create a report, toss it over the wall and say to the developers, ‘Here, take a look at this.’ It just doesn’t seem like it's very conducive to getting things done.”
The grim reality for security teams, Krikken said, is that developers have never been motivated to address secure application development unless forced to do so in the wake of a security incident or compliance initiative.
“If you look at how people are measured, they will do whatever is asked of them based on how they’re measured; nothing more, nothing less,” Krikken said. “If I’m measured on getting software built on time, and nobody is really measuring me on security, then I’m going to deliver software that’s on time and on point, but it’s going to have vulnerabilities; it’s just how it works.”
The recent, rapid proliferation of enterprise mobile application development has only further solidified this mindset, Krikken added, because most companies’ success is measured not by how secure a mobile app may be, but instead by how quickly it can get its new version up for sale in the online app stores.
The application security challenge has become so difficult to address through development, Krikken said, that he instead encouraged enterprises to consider an alternative strategy that relies less on developers and more on integrating defensive technologies – like Web app firewalls (WAFs), database audit and protection (DAP) products and XML gateways – into the enterprise application architecture. He said externalized components such as WAFs should be used in concert with code frameworks and platform features to fill in security functions.
Krikken said simply from a dollars-and-cents standpoint, constantly implementing new patches is becoming cost-prohibitive for many organizations, especially for mission-critical systems. That’s why, he added, it may be time to ask whether it’s faster, cheaper and ultimately just as effective to use a device like a WAF to shield an application from a security flaw than face the unending cycle of developing, testing and implementing software patches.
A WAF is an appliance or server software add-on that can monitor and block traffic to and from applications. They have become common in many enterprises, especially those that must comply with the Payment Card Industry Data Security Standard (PCI DSS), which calls for either use of a WAF or frequent application code reviews.
“I’m usually the last one to recommend – if you have a problem – throwing a piece of technology at it or putting something in front of it and filtering it, because it’s a good idea to build secure applications right from the start,” Krikken said, “but you can’t do that with all applications.”
Krikken emphasized that it remains important for information security teams to push for secure software development internally, and to encourage updates to insecure application code as frequently as possible. However, that challenging task of winning the hearts and minds of developers must be complemented by surrounding applications with additional security technology.
“I have an increasing number of customers starting to question whether putting a Web application firewall in front of an application to fix something is all that much worse than fixing the code.”
Krikken said it will require more time and work for enterprises to understand the importance of adding new application security technologies to their architectures, but the concept of defending instead of patching applications, despite being nascent, seems to be better understood and accepted every day. He said some enterprises question whether it’s wise to depend so heavily on a WAF or similar security product. It also remains to be seen whether PCI DSS Qualified Security Assessors (QSA) would condone it.
Baltimore-based attendee Louis Robinson of Excelon Corp. said Krikken’s approach seemed reasonable, particularly for enterprises to make a better effort to balance where application security functions exist, within an application vs. alongside it.
“In working with developers,” Robinson said, “you can’t put everything in the code, especially for performance reasons.”
He said the PCI DSS ramifications, as with any major IT strategy change, are always a concern, but indicated it wouldn’t necessarily be a deal-breaker for some organizations because many question how effective PCI DSS is in augmenting overall enterprise information security.
While Krikken sought to hold firm on the need to proselytize security to developers, he implored security pros to understand that developers, even those with the best intentions, will never be experts in security.
“Building security in is something you’ve heard a lot, but it’s something I’ve been struggling with. It’s a mistaken impression,” Krikken said, and one that developers often reject because they think it means they must build all the necessary security functions into the applications. “I don’t want them doing that; I want them focusing on the stuff they do well.”