Tip

Best practices for application-level firewall selection and deployment

Application-level firewalls have become a hot topic of conversation among those interested in compliance. The Payment Card Industry Data Security Standard (PCI DSS), which had only recommended application-level

    Requires Free Membership to View

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.

Another common misconception is to confuse application-level firewalls with Web security gateways and content filtering products. Don't turn off your Blue Coat, Vontu or Vericept systems just because you installed an application-level firewall. The two products do different things. Content filtering products block inappropriate websites, or Web-based email, all of which can contain malware. But again, they can't catch Web application attacks, which are only sometimes part of a website's content. Both products may use URL filtering, but an application-level firewall looks for malicious code in the URL, like JavaScript used in XSS attacks, while a content filter only looks at the Web address itself.

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?

For more information:
In this tip, discover how an application firewall can plug a critical hole in an enterprise's defenses.

Learn if firewall technology will have to adapt to applications that use port 80.

Mike Chapple provides three important points to consider before buying an enterprise firewall.
Generally, application-level firewalls run in tandem with network firewalls, usually behind them inside the network. Incoming traffic passes first through the network firewall, then through the application-level firewall. Always check the firewall's throughput and thoroughly load test it in your environment before considering a full production installation. Any slowdowns, bottlenecks or performance issues should be straightened out before deployment to production.

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.

This was first published in June 2008

Disclaimer: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.