This article can also be found in the Premium Editorial Download "Information Security magazine: An expert guide to tokenization and using it effectively."
Download it now to read this article plus other related content.
At its core, unified threat management (UTM) brings together three main ideas: multiple
Managers of small and medium-sized business (SMB) networks have been quick to adopt unified threat management devices. By activating UTM firewall features such as antimalware, Web content filtering, and intrusion prevention, network managers have reduced costs, simplified configurations, and gained a unified view of their security policy. In response, almost every significant firewall vendor has added UTM features to their product line.
Large enterprise networks use the same firewall software (but different hardware) as many SMB networks, but enterprise network managers have not been so quick to enable UTM features. Look at the edge of most large enterprise networks, and you’ll see devices with UTM features, but most will not be enabled. Why not? Mainly it comes down to history. Since UTM products were originally designed to satisfy SMB requirements, the term UTM has become associated with small networks. Firewall vendors have tried hard to break out of the “UTM is for SMBs” mindset, partially with a marketing blitz designed to create a new buzzword including “integrated security appliances” and “next-generation firewalls.”
But vendors have done more than create new buzzwords -- they’ve worked hard to incorporate enterprise-class security features into their products. The goal is to give enterprise network managers greater security, simpler configuration, unified management and reduced costs in their firewalls, factors SMB managers have enjoyed in their networks.
Enterprise network managers need a different set of evaluation criteria to decide when and how to turn on the UTM features in their existing appliances. There are four key requirements any network manager should use in deciding when and how to deploy UTM in the enterprise: performance, enterprise-class threat mitigation, network integration and management.
The single most significant requirement for UTM is adequate and predictable performance. Business-critical enterprise networks cannot tolerate slow-downs caused by improperly sized security products. Performance is the “make or break” criterion for UTM adoption in the enterprise.
If anything has scarred the reputation of UTM, it has been the poor performance of branch firewalls with all threat protections enabled. Independent tests have shown that typical UTM firewalls can have a 90 percent decrease in performance capability when features such as antimalware and IPS are enabled. This performance slow-down isn’t just in the branch office; a core device for large enterprise networks that runs at 120 Gbps without UTM enabled can slow down to 25 percent of that speed when IPS is turned on.
When a UTM firewall has a 100 Mbps speed rating and is being used on a 10 Mbps cable modem Internet link, the slowdown isn’t an issue. But enterprise firewalls run much closer to their rated speeds, and there isn’t as much room for error.
Getting performance testing numbers can be surprisingly difficult. Vendors all use different methodologies, and the exact feature set you plan to use may not be on their data sheets. However, all reputable vendors have internal performance test results, often only available under a non-disclosure agreement, which usually can give you the numbers you need to properly size devices.
When examining performance of enterprise-class firewalls with UTM features, make sure to:
- Determine the UTM feature set you plan to use. Most deployments will want antimalware, or IPS, or both. Pick a feature set and stick with it when comparing all products and vendors.
- Test with your own traffic in a real-world setting. If you can’t, make sure you review the vendor’s test results very carefully to see if they match your traffic load.
- Don’t mix server protective and client protective firewall testing, as many enterprises are deconsolidating their server and user firewalls to gain separate feature sets. Focus on each separately to understand how everything will fit in.
If you select a UTM firewall, performance considerations affect how you deploy the firewall within your network. These dos and don’ts will help you deploy with an eye to performance:
- DON’T apply UTM features where they aren’t appropriate. For example, a firewall acting in the network core probably shouldn’t have antimalware turned on.
- DO set UTM protections, such as IPS, as close to the device being protected as possible. If you have two layers of firewall, turn the IPS on at the firewall closer to the servers, not closer to the Internet.
- DO apply protections to VPN tunnels in a consistent manner. It can be hard, however, to decide where to put those protections. When applying UTM protections to branch offices protected by tunnels, you usually want to turn the protections on at the branch end of the VPN, not at the headquarters, for best performance. However, licensing costs and different feature sets may change your mind. For example, the IPS and antimalware features in the headquarters firewall may have better management and features or may be more economical, even with higher hardware requirements.
2. Enterprise-class threat mitigation
UTM and other buzzwords for new firewalls don’t really describe what their firewall feature sets do. In any case, the goal is to meet your requirements for traffic control, visibility and threat mitigation -- not “turn on UTM.” All UTM firewalls have IPS, URL filtering, and antimalware (sometimes called antivirus) features available. Firewalls that grew up out of the branch office environment may have a slew of other threat mitigation and traffic control capabilities, including antispam, wireless guest portals, load balancing and some application-layer filtering.
The key difficulty is to differentiate between simple UTM features appropriate for branches and ones that are enterprise-ready -- especially when “enterprise-ready” doesn’t have any clear definition by itself. Your best strategy is to dive deep into the features of each product you’re considering to see whether they are ready for your enterprise.
The classic example is IPS, which all UTM firewalls include. Early UTM products included very simple IPSes that were no match for the capabilities of standalone IPS products. If you’re proposing to rip out a standalone IPS and turn on the IPS feature set within your firewall, you’ve got to be sure you’re getting the same level of manageability and protection.
This is a good opportunity to look at your existing IPS deployment and decide what features you’re really using. For example, if the management system for the IPS sits in a corner and never gets used for forensics or incident resolution, then your true requirements for IPS are simple. On the other hand, if you are leveraging the power of a standalone IPS to improve your network security posture, make sure the IPS capabilities of the firewall are aimed at the enterprise, not at branch offices.
Web security gateways are also easy candidates for replacement by enterprise-class UTM firewalls, especially firewalls with application control features (these are usually called next-generation firewalls). Again, you need to decide which Web security gateway features you’re using. Intercepting traffic and applying URL filters and antivirus is easy for a UTM firewall; making different policies based on user identification or single sign-on is much more difficult. When evaluating UTM features to see if they’re “enterprise class,” make sure to:
- Check each UTM feature you want from start to finish. For example, if you’re already using IPS in the network, run through typical false positive and true positive events to be sure the workflow supported by the UTM can match your existing IPS tools.
- Watch for bugs. Application control, the holy grail of next-generation firewalls, is probably a lot buggier than the rest of your firewalls. Be careful when testing to verify that both configuration and behavior are correct. Don’t be surprised if you find bugs in a mature product.
- Check to see if the UTM coverage includes the applications you use. UTM coverage varies from protocol-to-protocol. If you’re looking for antimalware in email, for example, you may find that SMTP is scanned but IMAP isn’t. Read specifications carefully or, if necessary, test for yourself.
- Validate the ability to apply fine-grained UTM policies, giving each interface and zone a different UTM policy. Beware of “box-wide” policies that must be applied to all traffic or cannot differentiate between different types of traffic.
Deploying UTM features in an enterprise network can be a little frightening because the potential disruption caused by false positives may affect many staff members. Here are best practices to consider when deploying an enterprise-class UTM feature set:
- DON’T turn everything on at once. When enabling UTM features, set up a series of small, well-documented changes so you can quickly identify any problems and back out, adjust configurations, or compensate. Make sure logging is enabled to help debug.
- DO plan on SSL decryption if you are using application control features. With the growing trend towards universal encryption, application control is useless without SSL interception (so-called “sanctioned man-in-the-middle”).
- DON’T turn on features if they don’t truly provide a benefit. For example, if you have a two-tier antimalware scanner for your email, you’re not likely to get any advantage from scanning a third time -- and you may run into bugs. Make an argument for every single feature, even the ones with no marginal cost.
3. Network integration
An important differentiator between branch office firewalls and enterprise firewalls is their ability to integrate into more complicated network topologies. Branch offices may have a requirement for load balancing among multiple DSL or cable Internet connections, but enterprise networks will require high interface counts, dynamic routing, high availability and scalability.
More network security info
What should an enterprise security manager look for when evaluating UTMs?
Determine which next-generation firewall features best suit your needs.
These four enterprise requirements help differentiate between lower-end UTM firewalls trying to reach into the enterprise space and ones truly ready to sit in the core of gigabit and multi-gigabit speed networks. An enterprise-class UTM firewall should be able to act as both a security device and as a network device.
Discovering whether a UTM’s features are “enterprise-ready” can be difficult. If you simply look at long feature lists on product data sheets, every firewall will claim to meet enterprise requirements. However, you’ll find that many SMB-focused firewalls have thrown in these features without documentation, support or testing. Just because it says, “Supports BGP (Border Gateway Protocol)” on the spec sheet doesn’t mean it will work in your network. In fact, the track record of firewall vendors in this area has not been good.
Using firewalls as significant network elements remains controversial among network managers. When a large network based on a single vendor has a third-party device such as a firewall thrown into it, the network manager’s first impulse is to protect his or her own network from any routing and switching problems that could be caused by the firewall. They’ll do that by adding routing and switching elements around the firewall, rather than integrating the firewall into the network infrastructure. That attitude has developed from long years of being burned by sub-standard network implementations on firewalls.
Even if network managers won’t agree to add a firewall to their dynamic routing configuration, they will agree that high availability, scalability and flexible configurations are important parts. Most enterprise firewall deployments have chosen active/passive high availability to reduce uncertainty during device outages, or to lessen the impact of software upgrades or system maintenance. Ideally, active/passive clusters should be scalable, enabling increases in speed by swapping out individual devices, activating additional interfaces, or adding in accelerator cards -- without taking the entire firewall cluster down or requiring downtime. Of course, high availability goes beyond an active/passive cluster, and should include other design elements, such as the ability to hot-swap power supplies, interface cards and fans. No single point of failure should be able to interrupt network traffic flow, and no downtime should be required to replace failed components.
When looking at network integration of UTM firewalls in enterprise networks, make sure to:
- Evaluate dynamic routing in depth -- if it will be needed -- to ensure the firewall can integrate into your network. However, be prepared to be disappointed in this area.
- Verify high availability options, such as multi-unit clusters or scalability within a cluster to increase speed or schedule maintenance without downtime. Look at hardware carefully to validate true “high availability” design is not just a software feature, but permeates the product.
- Check for support of high-interface counts, 10Gig interfaces and VLANs, allowing the firewall to work both at the edge and deep in the core of the network.
Deploying UTM firewalls into enterprise networks should, like any enterprise network change, be done carefully and with adequate testing. Follow these best practices to smooth the path:
- DO test every high availability scenario before considering an installation “final.” Simply unplugging the active firewall isn’t good enough -- you need to check each of the different failure possibilities. Remember that it’s the 69 cent patch cable that’s most likely to fail, not the $69,000 firewall. Be sure to add each of the interfaces and devices to your monitoring system so you can detect failures. Failing to notice a firewall that’s been down for months is embarrassing.
- DON’T try and jam a firewall outside the comfort zone of the networking team. In the long run, network reliability and maintainability is more important than an elegant design that looks good on paper, but can’t be debugged by the networking team.
- DO make use of advanced networking tools such as VLANs and link aggregation. The former reduces interface count, while the latter solves the problem of a heavily used interface failing.
Firewall vendors have struggled for years to bring adequate management capabilities to their products. Most have done a poor job of building a unified GUI to configure and manage everything from IP routing configurations to firewall and application control policies up to the IPS console.
Enterprises have reacted to the poor management functions offered by most firewall vendors by adding compensating products: SIEMs and log analyzers are popular, but configuration analyzers and archivers, reachability monitors and report writers also are needed to properly manage a large network of firewalls.
The reality you have to face is the perfect management system is often not available for a large enterprise firewall deployment. This makes understanding your own management requirements, and how the enterprise UTM devices will integrate with your management systems critical.
One of the biggest issues with enterprise UTM is in IPS management. While tools such as antimalware don’t have significant management requirements -- they don’t throw a lot of false positives, and there is little tuning needed -- the IPS side of an enterprise firewall is no less demanding of good management than a standalone IPS device. If you have selected an IPS “super-console” such as a SIEM to manage your IPS/IDS events, then check that the firewall’s IPS will integrate smoothly with existing workflows.
When evaluating management capabilities of enterprise UTM firewalls, make sure to:
- Understand how the management will be partitioned. Without a “super-manager,” you will need multiple tools, some from the firewall vendor and some that may already exist in the company. Check that all bases are covered.
- Check role-based management capabilities. Enterprise-class UTM management requires both functional separation (keeping the networking team out of the way of the security team) and privilege separation (keeping operators from making changes to security policy). This goes far beyond what normal SMB firewalls have offered, and helps differentiate enterprise tools from small business ones.
Deploying UTM firewall management often means a radical change, especially if multiple devices or large VPNs are being covered. Follow these best practices to avoid problems:
- DO be flexible in breaking your deployment into pieces. Don’t force all firewalls into the same console if that’s not going to fit from an organizational point of view. Just because an über-console is available doesn’t mean it’s the right answer for your organization.
- DON’T forget about regulatory requirements. Firewall logs and audit trails can be an important part of whatever regulatory regime covers your organization. Be sure you plan for compliance up front, rather than trying to bolt it in after everything is installed and working. Engage with your audit and compliance teams early to learn their requirements.
- DO understand that different parts of the firewall management team have different requirements. A single tool is unlikely to meet the needs of security, networking and help desk/operations users. Consider firewall management a “package deal” and don’t be afraid to put together pieces from multiple vendors where appropriate.
The world of firewalls is moving to a unified feature set: integrated threat mitigation combined with layer-7 visibility and control features such as application identification. No one wants to have one brand of firewall for the branch and a different brand at HQ, and firewall vendors are slowly but surely moving to support this need. Because firewall products are seeing rapid change and development to support next generation UTM, picking the right firewall and deploying it in your network takes more planning and evaluation than in the past.
About the author:
Joel Snyder is a senior partner with consulting firm Opus One in Tucson, Ariz. He has worked in IT for more than 25 years. Send comments on this article to firstname.lastname@example.org.
This was first published in March 2012