In the first part of our Enterprise Firewall technical discussion, we talked about the architectural changes required to support this application awareness stuff. But the reality is most of the propaganda pushed by the firewall vendors still revolves around speeds and feeds. Of course, in the hands of savvy marketeers (in mature markets), it seems less than 10gbps magically becomes 40gbps, 20gbps becomes 100gbps, and software on an industry-standard blade becomes a purpose-built appliance. No wonder buying anything in security remains such a confusing and agonizing endeavor.

So let’s cut through the crap and focus on what you really need to know.

Scalability

In a market dominated by what I’ll call lovingly “bit haulers” (networking companies), everything gets back to throughput and performance. And to be clear throughput is important – especially depending on how you want to deploy the box and what security capabilities you want to implement. But you also need to be very wary of the religious connotations of a speeds and feeds discussion, so be able to wade through the cesspool without getting lost, and determine the best fit for your environment.

Here are a few things to consider:

• Top Speed: Most of the vendors want to talk about the peak throughput of their devices. In fact many pricing models are based on this number – which is useless to most organizations in practice. You see, a 100gbps firewall under the right circumstances can process 100gbps. But turn anything on – like more than two filtering rules, or application policies, or identity integration, and you’ll be lucky to get a fraction of the specified throughput. So it’s far more important to understand your requirements, which will then give you a feel for the real-world top speed you require. And during the testing phase you’ll be able to ensure the device can keep up.
• Proprietary or industry-standard hardware: Two camps exist in the enterprise firewall market: those who spin their own chips and those who don’t. The chip folks have all these cool pictures that show how their proprietary chips enable all sorts of cool things. On the other hand, the guys who focus on software tell stories about how they take advantage of cool hardware technologies in industry-standard chips (read: Intel processors). This is mostly just religious/PR banter, and not very relevant to your decision process. The fact is, you are buying an enterprise firewall, which needs to be a perimeter gateway solution. How it’s packaged and who makes the chips don’t really matter. The real question is whether the device will provide the services you need at the speed your require. There is no place for religion in buying security devices.
• UTM: Many of the players in this space talk about their ability to add capabilities such as IDS/IPS and content security to their devices. Again, if you are buying a firewall, buy a firewall. In an enterprise deployment, turning on these additional capabilities may kill the performance of a firewall, which kind of defeats the purpose of buying an evolved firewall. That said there are clearly use cases where UTM is a consideration (especially smaller/branch offices) and having that capability can swing the decision. The point here is to first and foremost make sure you can meet your firewall requirements, and keep in mind that additional UTM features may not be important to the enterprise firewall decision.
• Networking functions: A major part of the firewall’s role is to be a traffic cop for both ingress and egress traffic passing through the device. So it’s important that your device can run at the speeds required for the use case. If the plan is to deploy the device in the data center to segment credit card data, then playing nice with the switching infrastructure (VLANs, etc.) is key. If the device is to be deployed on the perimeter, how well it plays with the IP addressing environment (network address translation) and perhaps bandwidth rate limiting capabilities are important. Are these features that will make or break your decision? Probably not, but if your network is a mess (you are free to call it ‘special’ or ‘unique’), then good interoperability with the network vendor is important, and may drive you toward security devices offered by your primary network vendor.

So it’s critical that in the initial stage of the procurement process you are very clear about what you are buying and why. If it’s a firewall, that’s great. If it needs some firewall capabilities plus other stuff, that’s great too. But figure this out, because it shapes the way you make this decision.

Product Line Consistency

Given the significant consolidation that has happened in the network security business over the past 5 years, another aspect of the technical architecture is product line consistency. By that, we mean to what degree to the devices within a vendor’s product line offer the same capabilities and user experience. In an enterprise rollout you’ll likely deploy a range different-sized devices, depending on location and which capabilities each deployment requires.

Usually we don’t much care about the underlying guts and code base these devices use, because we buy solutions to problems. But we do have to understand and ask whether the same capabilities are available up and down the product line, from the small boxes that go in branches to the big box sitting at HQ. Why? Because successfully managing these devices requires enforcing a consistent policy across the enterprise, and that’s hard if you have different devices with different capabilities and management requirements.

We also need to mention the v-word – virtualization. A lot of the vendors (especially the ones praying to the software god) offer their firewalls as virtual appliances. If you can get past the idea that the anchor of your secure perimeter will be abstracted and run under a hypervisor, this opens up a variety of deployment alternatives. But again, you need to ensure that a consistent policy can be implemented, the user experience is the same, and ultimately all the relevant capabilities from the appliances are also available from the VM version.

As we’ve learned through the Network Security Operations Quant research, there is a significant cost to operating an enterprise firewall environment, which means you must look to streamline operations when buying new devices. Consistency is one of the keys to making your environment more efficient.

Embedded Firewalls

Speaking of consistency, we also see a number of offerings that run not on a traditional appliance, dedicated device, or VM – but instead embedded on another device. This might be a WAN optimization device which lets you do everything from a single device in the branch office, or a network switch to provide more granular segmentation internally, or even on a server device (although it’s always a bad idea to make your server Internet-visible). The same deal applies here as to a vendor’s own dedicated hardware. Can you manage the firewall policy on an enterprise-wide basis? Do you have all the same capabilities? And even more important, what are the performance characteristics of the device with the firewall capabilities active and fully configured? It’s very interesting to think about integrated WAN optimizers with firewall, but not if the firewall rules add latency to the connection. That would be silly, no?

Trust, but Verify

What all this discussion really boils down to is the need to test the device as you’ll be using it before you buy. It makes no difference what a product testing lab says about throughput. Based on how you’ll use the device, what rules and capabilities you’ll implement (especially relative to application awareness), and what size device you deploy, your real performance may be slower or faster than the spec. The only way to figure that out is to actually run a proof of concept to verify the performance characteristics. Again, we’ll discuss this in great deal when we look at the selection process, but it needs to be mentioned repeatedly because most enterprises make the mistake of figuring “a firewall is a firewall” and believing performance metrics provided by marketing folks.

Next we’ll tackle issues around deployment, including high availability, clustering, and supporting small offices.