Another area still out for discussion is exactly how application (and other next-generation) controls are integrated into the next-generation firewall. One school of thought suggests that they should be folded directly into the firewall rule base, creating a single unified policy that can refer to IP addresses and ports, users, and applications all at once. The other approach seems to be pulling application controls out into a separate rule base.
In testing four products, we found four approaches to this question. All four left user-based (and user group-based) controls in the main firewall rule base. From there, though, we found lots of variation. The Fortinet approach integrates everything into a single rule base, which we found the easiest to manage and the most intuitive from a basic security point of view. This approach is potentially the most powerful because it allows traffic to flow only when all attributes match up, and it allows you to interleave rules with and without application controls.
Check Point and SonicWall broke the application rules out from normal firewall rules, meaning that traffic must first pass through the firewall rules and be allowed before any application controls come into play. In the Check Point model, application and URL filtering rules are integrated into a single rule base, while SonicWall has a standalone application firewall module.
Barracuda's NG Firewall puts separate application rule sets in their HTTP and HTTPS proxy software. We found this problematic, not only because you have to define duplicate policies, but also because the way that policy definitions are created makes it impossible to mix "pass" and "block,'' severely limiting the flexibility of the engine. Barracuda told us they had this slated for a fix in Version 5.4.
Check Point and SonicWall engineers both defended their choices by pointing out a problem in application firewalls: you can't decide what application is being run without allowing some traffic through the firewall, including, perhaps, traffic that the network manager might want to have blocked.
An example might be helpful. Suppose you have a corporate policy that says "SMTP outbound is allowed only on Port 25." Taken in isolation, this means that you'd have to write two rules, one to allow SMTP on Port 25 and the other to block SMTP on all other ports. Then, you could have additional allow rules, such as allowing HTTP or IM outbound traffic on multiple ports. The result of this policy would be that the firewall would have to allow all other traffic outbound to connect and transfer data long enough to decide whether or not it was SMTP traffic. Our vendor engineers were concerned that this could easily result in unintended consequences and insecure configurations — a valid concern.