Application-level firewalls have become a hot topic of conversation among those interested in compliance. The Payment...
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
Card Industry Data Security Standard (PCI DSS), which had only recommended application-level firewalls as a best practice, will require companies to either install them or conduct code reviews as of June 30.
Nowadays, most organizations have some sort of perimeter firewall that protects the network against malicious Internet traffic, but these types of firewalls aren't equipped to protect organizations against threats that come through applications.
Recently, application-layer firewalls have emerged as a defense against Web application attacks, which are the most common type of intrusion, according to reports by antimalware vendors Sophos plc and Symantec Corp. Traditional network firewalls can't detect application attacks because they piggy-back on open ports used by legitimate applications. Network firewalls check ports and packet headers, but they don't check applications and application data, which can hide malicious activity as it zips through open firewall ports unnoticed. Since most Web traffic goes through either port 80 or port 443, blocking these ports isn't realistic.
PCI DSS has also focused attention on application-level firewalls. The infamous Section 6.6, which covers Web application security, calls for companies to protect code used for processing credit cards by either conducting code reviews of their applications or using an application-level firewall.
Unfortunately, PCI DSS Section 6.6 interprets application security as an either-or proposition, but it's more complex than that. Application security isn't about a code review or a firewall; in some cases it could mean both. Unlike network security, which is about closing ports and turning off unneeded services, application security is about secure coding and design.
As with any security tool or practice, an application-layer firewall should only be seen as part of a larger security program, not as a single defense against Web application attacks. It should be one part of a multi-layered defense that includes application vulnerability, penetration testing and reviewing code for security flaws throughout the entire software development lifecycle.
Selecting and deploying application-level firewalls
There are four features every organization should look when considering application-level firewalls. Let's take a look at these features individually, as well as some application level firewalls on the market today.
First, is it really an application level-firewall, or is it just a deep-packet inspector? The distinction is important. To be compliant with PCI, it must be a real application-level firewall, not an imposter.
A true application-layer firewall inspects the traffic from applications for malicious code, such as SQL injection or cross-site scripting (XSS). Sure, this requires deep packet inspection, but deep packet inspection looks only for things like malware and spyware embedded in traffic, not necessarily at malicious code sent through an application.
Unlike traditional network firewalls, which only examine packet headers, deep packet inspection looks inside packets and their contents. While this definitely beefs up the capability of firewalls, and shouldn't be discounted as a defense against attacks, it still has some limitations.
Despite that, Web security gateways, content filtering products and application-level firewalls have been slowly blending together into unified appliances. The evolution is natural, as threats have also blended and now require a multi-layered defense. The content filter may or may not block a malicious site, for example, but the application-level firewall will block the malicious code it carries.
At a bare minimum, an application level firewall should protect against injection attacks, like SQL injection and XSS, session hijacking, scanning and crawling, cookie tampering and path traversal attempts. An application-level firewall can block Denial of Service (DoS) attacks by checking for spikes or irregular traffic patterns and should also be able to handle both standard HTTP, as well as SSL traffic.
Second, does the application-layer firewall allow fine-grained protection through access controls? Access controls are a big part of compliance. Not only PCI, but SOX and HIPAA require a full-accounting of who has access to corporate systems and what they have access to. An application-level firewall can play a role in monitoring that access.
The second feature to look for in an application-level firewall is its ability to integrate with identity and access management systems. This allows the firewall to be tuned to allow employee access to certain Web applications, but not anybody else in the organization. Some employees may need access to Web-based email or WebEx to do their jobs. This can be adjusted if the firewall is integrated with the company's directory service, like Active Directory or LDAP. Access to applications can be added to an employee's profile.
An application-level firewall itself, like its network firewall counterpart, should also have role-based access to only allow authorized system administrators access for maintenance and upgrades.
The third key issue for application-level firewalls is their compatibility with a corporation's network. An application-level firewall is another piece of equipment that can be a drag on a network. If not configured properly, or if it's incompatible with corporate architecture, it can cause performance problems. Will it be a drag on your network, slowing down visitors to your web sites, or will it be transparent, as it were invisible on your network?
Finally, just like their network counterparts, application-level firewalls should have the capability to log traffic. Besides being a security best practice, it's essential for tracking down incidents and, in some cases, may be required for compliance. Will the logging be adequate to track down incidents or produce reports of inappropriate access? PCI is strict in its requirement of network monitoring. This is at the heart of an application-level firewall's features.
The thick of the market application-level firewalls come from Barracuda, Palo Alto Networks, F5 Networks, Breach Security and Imperva. Other vendors with application-level firewall offerings include Juniper, Fortify and SonicWall.
The Barracuda Web Site Firewall bills itself as compliant with both Sections 6.5 and 6.6 of PCI. Section 6.5 requires Web applications to meet the coding guidelines of the Open Web Application Security Project (OWASP). The Barracuda Web Site Firewall proxies all Web traffic, protecting against commonly known Web attacks and session hijacking attempts and validates input from all online forms, the most common source of XSS attacks.
The Palo Alto Networks PA-4000 series bills itself as an application-centric firewall. It can be tuned with a policy editor, which can add a firewall rule based on the vulnerabilities in a particular application, and has App-IDTM, its own traffic classification technology that does real-time analysis of application traffic.
Application-layer firewalls, like other new security technologies, are becoming more popular and getting absorbed into existing security products. And, as application security becomes more important, their popularity increases. But review products carefully to make sure they use the right features to protect your company from application attacks.
About the author:
Joel Dubin, CISSP, is an independent computer security. He is a Microsoft MVP, specializing in web and application security, and is the author of The Little Black Book of Computer Security, Second Edition, available on Amazon. He also hosts a regular radio show on computer security on WIIT in Chicago and runs The IT Security Guy blog at http://www.theitsecurityguy.com.