Firewalls are arguably the “granddaddy” technology of the current IT security world. In the late 1980s, the earliest...
firewalls were little more than filtering rule sets on routers. As more organizations connected to the Internet in the early to mid-90s, the demand for firewalls evolved and companies like DEC, Raptor and TIS introduced commercial products. These early firewalls monitored connections for what were, at the time, the most popular application-layer protocols: FTP, Gopher, SMTP (email), and Telnet.
Around the mid-90s, something interesting happened to the firewall market. A massive debate erupted around which technology implementation was more secure for network perimeter firewalls: Stateful protocol filtering (sometimes referred to a multilayer stateful inspection or “MLSI”) or application proxy gateways? While stateful inspection firewalls checked source IP, destination IP and port, application proxy firewalls were privy to the entire transaction and could be configured with more granular, context-based rules to examine types of activities within the application protocol stream.
So who won the late 90s firewall battle? No contest, stateful inspection, right? But did it really? What’s at the center of the “next generation” of firewalls? It’s granular, tunable application awareness: one of the major selling points for application proxy firewalls back in 90s. Admittedly, the level of application awareness that organizations want in 2012 differs considerably from what they wanted 20 years ago. As a firewall admin back then, I never dreamed of needing to filter Mafia Wars 2 traffic out of the Facebook stream through a Google Chrome browser. But like their predecessors, next-gen firewalls (NGFW) aim to increase utility of the firewalls by providing a deeper level of application awareness.
However, there’s a lot of hype about next-gen firewalls. Organizations need to cut through the marketing jargon to understand what an NGFW can provide and determine which next-generation firewall features best suit their needs.
Although a more granular and context-aware understanding of the application traffic is a hallmark of the next-generation firewalls from vendors like Check Point Software Technologies, Cisco Systems, Fortinet, Juniper Networks and Palo Alto Networks, it’s not the only one. Precisely what constitutes a NGFW depends on who’s talking. Some analysts have put forth their own criteria; for example, Gartner published a definition note in October of 2009 that highlighted a close connection between IPS devices and functions in the NGFWs. Other analysts have argued that unified threat management (UTM) devices are essentially NGFWs, while vendors like Palo Alto and Juniper have offered their own definitions.
Rather than attempt to define the “definitive” parameters of a shifting feature set, it makes more sense to enumerate the various functions an NGFW can have so an organization can make its own decision regarding which ones are right for them. While the next-generation firewall features each organization requires will vary, there is one general rule of thumb: The more deep-inspection or rules the perimeter firewall is expected to process and enforce, the more horsepower and resources required. In other words, choose requirements wisely to reduce the risk of traffic slowdowns.
Port filtering has limited utility when the majority of a company’s Internet traffic goes through the browser using the same standard protocol (HTTP or HTTPS). Internet services from mail and streaming video to social networking and micro-blogging all flow through the browser on a limited number of ports, and as a result, NGFWs need to be able to inspect session activity to perform context-specific decisions. If your organization is interested in filtering attachments from Gmail or blocking Flash or Silverlight content, look for an NGFW with this functionality. This capability has turned into something of a garbage pail term – “application aware” – that’s used loosely, so it’s critical to put products to the test before making a purchase decision.
Before speaking with vendors, create a short list of rules you’d like the firewall to be able to implement. If you don’t have a set of rules already but you do have some kind of traffic analysis capability, take a look at flows from your analysis tools to help formulate NGFW rules. And then have the vendor show the product performing the blocking or checking rules on your network. The reason for this is that application aware can cover a variety of policies from the very coarse (block all Skype traffic) to the more granular (block video in Google+ hangouts but allow video in Skype). Make sure your needs and what the NGFW can deliver are in sync.
Intrusion prevention systems (IPS) deliver in-line, application-aware blocking on the network. While some analysts and vendors define fully integrated IPS as part of a NGFW, others believe the two technologies will remain separate. What matters for your organization is whether or not IPS and active blocking is part of your current or future plans and if you already have IPS solutions in place. If you do have an IPS and you’re happy with it, think through whether it’s truly beneficial to replace these systems with new firewalls.
Integration rather than replacement might be more cost-conscious. For example, can infrastructure improvements be realized by integrating intelligence from the IPS with the NFGW?
Gartner Research Director Eric Maiwald cites the ability to monitor for command- and-control traffic as one of the major benefits of NGFWs. Though messaging hygiene gateways perform inspections on traffic coming into the organization, they aren’t much help if malware has already slipped in. But an NGFW that can detect unusual outbound activity, such as communications over port 80 that don’t go to a legitimate website or traffic that matches a known command-and-control signature, can help. It can help identify and block outbound communications from malware that is currently active inside of an organization and putting the environment at risk.
Another aspect of becoming more context-aware in NGFW rules is identity awareness. This can translate to policies that enforce use requirements for a single user or to apply group and partner policies for large populations. Identity information can be hard-coded into the firewall rules or, more commonly, consumed from an identity repository like Active Directory.
For example, a company that is outsourcing customer service activities may need to give its partner access to small portions of its internal network and services. Using identity-based rules, the NGFW can manage the inbound traffic securely and monitor the activity traffic with the outsourcer. Again, consider your organization’s use cases in advance and then confirm with the vendor that its NGFW will be able to support your needs.
Integration with other security tools
Beyond the security devices already mentioned, there are a few others organizations might want to consider integrating with their NGFW architecture. Though network NGFWs are not intended to be a replacement for a Web application firewall (WAF), it is possible to create granular Web application rules on them. If an organization has only one or two Web apps and can’t afford to invest in a WAF, it’s worth investigating whether or not the NGFW can be used to perform some basic Web app protection using custom rules.
Another potential intersection point for the NGFW is with vulnerability scanning and management tools or services. For example, if a server behind the firewall can’t be patched for a few days, can a rule be sent to the firewall (either manually or automatically) to protect that server? Finally, if your organization has access to repositories of black or whitelisted sites from an on-premise source or subscription list, and you are not already using a Web hygiene gateway to enforce them, ask the NGFW vendor if its product can import and use the black/white lists. Some NGFW vendors supply black/whitelist information themselves. If your company wants to use a combination of its own black/whitelists and the vendor’s, make sure the firewall is able to blend the two lists without creating conflicts or overriding one rule set with another. Also, ask how frequently the lists will be updated and if changes can be made via the firewall console to the listings. Some organizations have legitimate reasons to open commonly blocked sites and the rule enforcement needs to be flexible enough to accommodate business requirements.
Paying for a NGFW and using it for basic port filtering isn’t the smartest move, but not all network operations teams and firewall managers are comfortable with granular application blocking rules yet. In the 90s, not only were application proxies slower than stateful inspection firewalls but their setup and management time was slower too. That’s because new proxies had to be written when the applications and services changed and the firewall rules had to be updated to keep pace.
While NGFWs don’t have to deal with extensive proxy rewrite times, the complexity of rule creation remains. If you flinched a little at the prospect of generating a short list of application-specific rules to test with vendors, you already know what this means. If you haven’t spent time thinking through application specific rules, consider whether or not your organization has the time and resources available, either on-site or through a third party, to configure and maintain a complex rule-set on an NFGW.
Also, keep in mind the need for speed is increasing. Companies have bigger pipes, faster connections, and more bandwidth intensive application needs like streaming video. Ten, 40, 100 Gbps are the new norm for throughput and devices at the perimeter need to keep up, especially for services like voice and video that cannot tolerate latency. For smaller organizations or remote and branch sites, throughput considerations are less critical. But for main headquarters and backhaul sites, make sure the NGFW you consider can keep up with traffic today and with any plans for growth in the next 12-18 months. Don’t forget to stress test the system with a loaded rule set to ensure it can handle throughput needs in your production environment.
And don’t lose sight of the fact that despite all their technical advances, NGFWs are perimeter firewalls. Mobile devices connect to the Internet from outside the corporate network and outside of the NGFW. Some organizations backhaul remote and mobile traffic to a corporate site, but this approach is bandwidth intensive and expensive. Gartner’s Maiwald recommends companies consider how much control they’re going to force on their employees because NGFWs don’t help with mobile device management or policy enforcement on Web surfing and cloud access from mobile devices unless all of the traffic is sent back through (or backhauled to) the corporate NGFW.
For backhauling and cloud access, Maiwald notes that organizations are implementing “mostly secure Web gateways,” rather than NGFWs, “because you can’t apply the same architecture and approach that you did on-premise.” On-premise corporate architectures can leverage a single perimeter enforcement point because all of the inbound and outbound on-premise corporate traffic flows through that point. But mobile and cloud architectures distribute the traffic over multiple networks, like cellular and public Wi-Fi, and geographic locations. For mobile and distributed access through the cloud, companies are exploring use of distributed, managed secure Web gateways from cloud providers. For on-premise access, very large organizations continue to split secure Web gateway and firewall duties for performance and management reasons even though some NGFWs can perform basic secure Web gateway duties.
Not a cure-all
There’s no doubt that firewall technology has advanced in the past couple of decades from basic filters on routers to purpose-built application-aware devices. Next-generation firewalls are, ultimately, more than marketing hype: They are faster and able to process more complex rule sets than their last generation counterparts. But NGFWs are not a panacea or cure-all. To avoid buying the wrong product or paying for more functionality than you can use or need, determine which features your organization requires and make sure the vendors’ claims can be realized in your production environment. Don’t forget the firewall rule sets can be complex and adding in application-specific rules only ups the ante. Do you have the resources, either in-house or from an outsourcer, to manage and maintain these rules?
And finally, keep in mind that NGFWs are perimeter devices. They do an excellent job of gatekeeping from the corporate network(s) to the Internet but not much for mobile security. To maintain policy, application, and data protection parity across the corporation, augment NGFWs in the perimeter with cloud-based and mobile security solutions.
Speed vs. security
Back in the 90s, when experts debated the merits of stateful protocol filtering vs. application proxies, the argument boiled down to one of speed vs. security.
On one side of the debate were companies like Check Point who built its reputation on MLSI type firewalls and on the other were vendors like TIS (sold to Network Associates/McAfee in February 1998) and Raptor (sold to Axent/Symantec in December 1997), which sold application proxy gateway type firewalls.
Stateful inspection firewalls were faster than their application proxy counterparts in tests and bake-offs largely because there was not a whole lot of inspection going on beyond source IP, destination IP, and port. Application proxy firewalls were privy to the entire transaction and could be configured with more granular, context-based rules. Source, destination and port were still examined, but rules for types of activities within the application protocol stream could also be applied. For example, basic HTML traffic from an approved website would be allowed through the application proxy firewall, but ActiveX content from the same site could be blocked. While this represents a valuable security feature, it came at the expense of throughput speeds.
Next-generation firewalls are faster than their predecessors, but organizations should stress test any system they’re evaluating to make sure it can handle their throughput needs.
About the author:
Diana Kelley is a partner with Amherst, N.H.-based consulting firm SecurityCurve. She formerly served as vice president and service director with research firm Burton Group. She has extensive experience creating secure network architectures and business solutions for large corporations and delivering strategic, competitive knowledge to security software vendors. Send comments on this article to firstname.lastname@example.org.
Can having too many features in an NGFW do more harm than good? Learn more here.
Considering a next-gen firewall? Discover the features that will facilitate changes in your data center
Best practices for evaluating next-generation firewall features
Next-gen firewall management features: What to look for during vendor assessments