Guide to Unified Threat Management
Five tips on deploying enterprise UTMFeature By Joel Snyder, Network World, 08/30/07Early rounds of testing in our upcoming 10-vendor shootout of enterprise unified-threat-management firewalls have shown that deploying enterprise UTM has its own pitfalls. Here are some tips to help you avoid those issues in your network.
Although you can buy UTM firewalls of almost unlimited power, that doesn't mean you should try and consolidate all your firewalls into a single system. It's important to logically distribute firewall functionality, because of the difficulty of building a single, coordinated, enterprisewide policy. Even though firewall vendors have made huge strides in centralized management, no product easily handles many zones of control with differing firewall rules, network address translation rules and VPN tunnels in a single policy. Add in the axes of intrusion detection/prevention systems (IDS/IPS) or other UTM features and the policy becomes even less manageable. UTM devices can support consolidation, but it's easy to go too far. Make sure you don't "over-consolidate" into an unmanageable device.
Performance is one of the biggest gotchas in UTM devices: As you turn on features, performance can drop dramatically - or not at all. Security product vendors don't hide these performance costs, but they don't make it easy for you to understand what the impact of enabling different UTM features will be on your system performance. Make sure you know exactly what your UTM configuration will be, and test it to be sure that performance matches your requirements. Speed drops of 75% to 90% are common with a single check box. Be sure you also have plenty of headroom. IPS rules, for example, will only get more complex over time, so your IPS will get slower and slower over time.
UTM firewalls have a lot to say, with each layer of the firewall logging information about the traffic flowing through it. Enterprises are increasingly being asked to capture and retain these voluminous firewall logs for months or years. Make sure you plan for a dedicated management server with plenty of disk space, memory and CPU power to handle these chatty boxes. Although some enterprise vendors still allow management to be handled via a Web GUI or through a management server running co-resident with a firewall, don't be tempted to skip a properly separated and sized management system.
As firewalls take on more functions and become more central to correct network operation, ensuring high availability and scalability also is more important. Because performance is more likely to be a bottleneck in UTM, active/active configurations are more attractive than active/passive - but such configurations are more difficult to build and test. Simulating all the different failures, and making sure that you test them in all the different states of the cluster, can be a five-day and not a five-minute job. We also found that not every feature in our UTM devices works in the same way. For example, the basic firewall and VPN functions are usually shared cleanly across a cluster, but dynamic routing may not be as well thought out. If the VPN tunnels stay up across an individual device failure but the cluster doesn't know how to route the packets, that's not "highly available."
During our testing, we found that the firewalls often were not doing what we thought we had asked for, especially in the area of UTM add-ons such as antivirus and IPS. You should be prepared for a second round of training on system management and configuration, because what you thought you knew about your enterprise firewall may not be enough to get a proper UTM configuration in place. Even if you think you know what you're doing, it's valuable to run simple tests to validate that the protections you've asked for are actually activated. The terminology and protocol coverage varies wildly across different products, and a simple check box for a UTM feature may need an hour of testing to understand.
How to select enterprise UTM firewallsFeature By Joel Snyder, Network World, 08/30/07
Selecting UTM firewalls in an enterprise environment is more work than just picking a standard firewall, because the "UTM" moniker doesn't offer much information about what the firewall actually does. When evaluating enterprise UTM firewalls, there are four key issues to consider: performance, UTM feature set, network integration and management. Many of these overlap traditional firewall requirements but must be considered in the light of specific needs for very high-reliability, high-performance, enterprise-class products.
Performance is the key starting point for UTM firewalls, because the UTM features exact such a heavy performance cost. Without accepted metrics on how to measure UTM firewall performance, network managers are left to determine how fast a UTM device will go by turning it on and putting it in the middle of their network. No matter what you do, don't skip this step or some reasonable approximation in a test lab. The performance of UTM devices is very dependent on exact configuration and traffic flows, and without some testing, you could easily end up with a device that can't handle the loads you throw at it.
UTM firewalls that let you scale up without a forklift upgrade, either by upgrading in the chassis or by adding systems in an active/active load balancing configuration, are especially attractive when the performance card is on the table. But it's better to start with a system that can run as fast as you need the day you turn it on, and save upgrading for another year.
UTM features are near the top of the list for selection criteria. The idea seems simple enough: If you want antivirus, it should do antivirus. But within UTM firewalls, there's considerable variation in how a simple feature such as antivirus is implemented. For example, not every firewall can examine every protocol for virus signatures, and even those that do cover the top protocols can't always be configured to work on non-standard ports. One firewall we tested only looks for viruses in certain defined Multi-purpose Internet Mail Extensions types as a way to keep performance peak, opening the potential for future exploits to slip directly past. A critical exercise before buying is understanding exactly what coverage is included and how that coverage relates to your own traffic patterns and requirements.
A small number of UTM firewalls offer a choice in threat mitigation products, such as multiple antivirus vendors, but most lock you into a single vendor. While antivirus (as an example) is considered a commodity service, other services, such as IPS and antimalware, are in more active development - which makes the choice of vendor and consistency of implementation significantly more important.
Network integration includes the aspects of a UTM firewall that let it sit securely within an existing network. For example, enterprise UTM firewalls are more likely to need some support for dynamic routing protocols such as Open Shortest Path First to integrate within an existing infrastructure. Virtual LAN support, high port density, WAN support and expandability of interfaces over time are all similar network integration features. While most of these also are relevant in a pure enterprise firewall without UTM features, the tendency to use UTM firewalls as points of consolidation of security control raises their importance.
Another aspect of network integration includes the equipment and interfaces required for high availability and scalability. If you've got a specific set of load balancers or switches, the UTM firewalls have to be able to integrate with that equipment with a minimum of re-engineering and additional equipment. Similarly, with the additional requirements for active/active clustering that UTM performance brings, full support for upward scalability should be considered a UTM evaluation criterion.
Management is one of the most difficult parts of a UTM firewall to evaluate, because you don't know how good or bad the management is until you've had lots of experience with the product. While most management systems strive for glitzy interfaces for the novice, the real evaluation comes with consistent and continued use. Unfortunately, by that time, it's too late to choose another product.
In UTM products, one of the most important features of management is the ability to bring UTM features into play in a flexible and controlled way. For example, a management system that requires all traffic to flow through the IPS, or none of it, is not suitable for an enterprise UTM device. At the same time, the management system must allow for different profiles for the same UTM feature. For example, an IPS might be configured in a liberal way for internal users browsing the Internet, while turned up to strict levels for guest users coming from a different subnet.
While UTM management systems will be mostly of interest to the security manager, there are aspects of configuration that will fall to a desktop manager (such as antivirus) or network manager (such as dynamic routing). Separating function and privilege level horizontally and vertically across the domain of management is difficult. However, if your UTM deployment will have people from three (or more) teams peering into the same management system, features in this area can be critical to successful long-term operation.
UTM firewalls: Ready for the enterprise
Our testing shows that unified threat management appliances aren't just for the SMB market anymoreFeature By Joel Snyder, Network World, 08/30/07
IT managers at small and midsize businesses like unified threat management appliances - firewalls that layer on antimalware protection, content filtering, antispam and intrusion prevention - because deploying a single, multi-function device reduces costs and simplifies configuration.
However, deciding whether and where to deploy UTM appliances in a large enterprise is a more complicated and difficult decision. The idea of a single point through which all traffic flows as an obvious locus for threat mitigation doesn't work when a network has dozens, hundreds or thousands of distinct locations. Also, because performance is a critical issue in large networks, savvy network managers often seek to distribute threat protection rather than centralize it, simply to reduce the likelihood of a performance bottleneck.
Similarly, the style and quality of threat mitigation features one commonly sees in an SMB UTM may not be of interest to an enterprise, where requirements are more exacting and security architectures are more complex. For example, the antispam features and functionality in UTM firewalls pale compared with those in stand-alone enterprise-class dedicated antispam/antivirus appliances.
With such dramatic differences between SMB and enterprise requirements, is there a place for enterprise UTM firewalls? The answer is definitely "yes," for these three reasons: reduced complexity, simplified management and increased flexibility.
Enterprise network managers have long sought to include additional threat protection, especially intrusion detection/prevention systems (IDS/IPS) functions, both at the core and at the perimeters of their networks. However, the complexity of dropping standalone IDS/IPS boxes into a network has made them wary.
Building the "firewall sandwich," with load balancers surrounding a core of clustered firewalls, is well understood, but trying to scale that sandwich up with another layer of protection dramatically increases architectural complexity and potential instability.
A simple sandwich is considered science by network architects, but adding layers takes it from craft to art, dramatically increasing the difficulty of the project and opening a window for failure and problems. It's like adding just one more piece of cheese to that Dagwood sandwich: Not only will you be unable to get it in your mouth, but the whole thing may fall apart on your plate.
Enterprise UTM with integrated IDS/IPS can give network managers additional security throughout the network without the massive increase of complexity that stand-alone IPS devices would create.
It's pleasant to imagine the concept of a single UTM console that can handle everything from IP routing to IDS alerts, but enterprise security teams often want different management systems for a reason: different people are responsible for different kinds of threats and configuration.
Nevertheless, some level of management integration can reduce the task of handling these different functions. For example, every management console must have different network objects in it that are used to define policy: here are my mail servers, here are my users, this is the guest network, here is where the Internet is.
Each time those same objects must be typed into a different management system, and each time these objects are updated and adjusted, there is an opportunity for human error or miscommunication to create a security hole. A single management console that shares objects across different functions simplifies the complex task of management.
This single management view is especially valuable when firewall, VPN and IDS/IPS are considered together because all three of these functions act on the same policy. Each of these functions needs to have some view of the topology of the network, what applications are running on different servers and what different groups of users are allowed to do. Completely separate management for all three functions makes coordinated policy maintenance difficult, if not impossible.
A single UTM-ready management console realistically enables a fine-tuning of policy across all three functions, increasing total security.
Enterprise security architects generally scoff at the plethora of features, such as antivirus, antispam, antimalware and antiphishing, that are being built into SMB UTM devices. With a "best of breed" mentality and correspondingly large budgets, they are barely interested in activating IPS features in their existing firewalls. However, there are always specific situations where the ability to turn on, for example, antivirus, may be a huge benefit.
Having additional security features latent in large firewalls that can be activated with the click of a mouse gives the network manager increased flexibility, which is of significant value. For example, blocking incoming viruses in a UTM firewall may be a life-saver when the normal antivirus appliances suddenly stop working because of hardware, software or update failure.
Or consider the requirements of a guest user network: Most enterprises have chosen HTTP proxies to provide content filtering and antiphishing protection but may want to let guest users choose a different kind of protection and not take on the support burden of making sure they're properly working with the enterprise proxy. It may be simpler and more effective to enable these features in a UTM firewall for those networks.
The flexibility to bring security services in and out of the equation quickly using a UTM firewall supports threat response requirements - even if those features are rarely used.
Why Do UTM Firewalls Work So Slowly?By Joel Snyder, Network World Lab Alliance, 10/1/07
From the outside, a UTM firewall looks like an amalgamation of different security features, all smooshed into a single box. However, there are some significant limits that come from combining firewalls and application-aware security services. Knowing how these things are put together from the inside out will help you understand what UTM firewalls can, and cannot, do.
Thinking about UTM firewalls should start with the realization that most firewalls use stateful packet filtering to control flows. The early 1990's firewall "wars" between packet filter vendors and proxy vendors were decided fairly firmly in favor of the packet filter camp: Check Point, most prominently, but nowadays also including Cisco, SonicWALL, and Juniper. These companies went on to take the lion's shares of the firewall market,. This leaves what are now the two main proxy firewall vendors, Secure Computing and WatchGuard, to take what's left of that pie. Although there are many reasons enterprise buyers voted for packet filters, one of them was speed: packet filters could keep up with the rapidly increasing speed of Internet connections, while proxy firewalls could not.
The speed of packet filtering firewalls stems from the fact that they don't need to keep track of, and check, every bit of information going through them. Packet filtering firewalls operate fairly low in the TCP/IP stack, doing most of their work at the IP and-to some extent-TCP layers, with only an occasional foray into the application layer during connection setup and the first few packets of a connection. A proxy firewall, properly implemented, has awareness and control all the way up to the application layer. This means that, in theory, an attacker can slip more application-layer badness through a packet filtering firewall than through a proxy. On the other hand, the proxy firewall is going to be slower because it has more work to do all the way up the stack.
The result of this performance win is that packet filtering firewalls can be made incredibly inexpensively. All leading packet-filtering vendors offer sub-$1000 products that can handle speeds nearing 100 Mbps, because they just don't require that much CPU speed. In the open source world, people often brag of using 100MHz systems that were destined for the scrap heap as their firewalls, just because that turns out to be plenty of speed for a simple packet filter.
Security, though, continues to be just as important as speed in the firewall business. Both camps have come to compromise positions. Packet-filtering firewall vendors are looking higher and higher in the application stack to catch common attacks, giving them some of the security features already offered in proxy firewalls. At the same time, proxy vendors have made short-cuts here and there, sometimes reducing their product's ability to look at or control the application layer, in order to achieve competitive performance.
The difficulty for security managers comes when UTM features are added. While UTM add-ons can occur at any layer, the ones of greatest value to network managers require application-layer awareness: anti-virus and anti-spam definitely sit at the application layer, while effective intrusion prevention also requires application layer awareness. Add to that the structure of anti-virus and anti-spam products: many thousands of signatures, all running across a single complete data stream, and you're now on the wrong side of the CPU and memory power curve. You've got a firewall of an entirely different architecture. The result is a massive performance hit. In our testing, adding UTM features to a standard firewall typically causes a 10:1 performance hit: if it used to do 1000 Mbps, you're lucky if it will do 100 Mbps with any other UTM features turned on.
To counteract this performance penalty, vendors have turned to a combination of tricks to keep their collective CPUs above water without adding in a co-processor or separate IPS blade. A common one is to require the network manager to pre-configure all the different applications on the firewall, indicating which ones should be scanned and which application is running on which port. That works fine in certain cases, such as incoming SMTP mail, which is on a predictable port going to a predictable system. However, except for the small business case where the UTM firewall is the only threat protection in place, scanning incoming SMTP mail for viruses is one of the least useful features of a UTM firewall. Where network managers need additional protection is in all the other ways that end users have of getting information off the Internet, such as via Web traffic, IM traffic, personal mail accounts being checked at work, and peer-to-peer applications.
The result is that UTM firewalls fail pretty miserably where they are most needed. For example, in our testing, UTM firewalls were outstanding at catching viruses being downloaded from Web servers on TCP port 80, the most common port for web traffic. However, as soon as we moved the Web server to a different port, the firewalls missed the traffic entirely. We didn't even bother to try encrypted Web traffic, since the firewalls definitely can't see into an encrypted session without breaking the end-to-end security model. The exact same class of problems occurs in the IPS engines inside of UTM firewalls: without predictable applications on predictable ports, UTM IPS generally won't catch application-layer attacks. This means that a malware distributor simply needs to add ":81" to the end of links in phishing messages to bypass most UTM protections.