Cisco impresses with first crack at next-gen firewall

When we tested next-generation firewalls last May, at least one important security vendor wasn’t there: Cisco, because they weren’t ready to be tested. Now that the ASA CX next-generation firewall has had a year to mature, we put the product through its paces, using the same methodology as our last NGFW test.  

When we tested next-generation firewalls last May, at least one important security vendor wasn’t there: Cisco, because they weren’t ready to be tested.  Now that the ASA CX next-generation firewall has had a year to mature, we put the product through its paces, using the same methodology as our last NGFW test.  

We found that Cisco has an outstanding product, with good coverage and strong application identification and control features. Enterprise security managers who have upgraded to the “-X” versions of the ASA firewalls (announced at the RSA Conference in March 2012) can add next-generation features to the hardware in their data centers and branch offices and gain immediate benefits.  

Network managers who haven’t upgraded their hardware or who are considering a switch from a different vendor should make a competitive scan before deciding on the Cisco ASA. We found the ASA CX to be a solid “version 1” effort, but Cisco still has significant work to do in improving the management, integration, threat mitigation and application controls, leaving the ASA CX a work in progress.

Introducing the ASA CX

When Cisco decided to add next-generation features to its ASA firewall, it must have faced a daunting task: how to take a mature firewall architecture and add the next-generation features, especially application identification and control, that security managers were asking for. And by next-generation features, we mean application identification and control. Cisco took a stab at this in 2009, when it added the Modular Policy Framework, which brought many application-layer controls to the ASA. Rather than touch the delicately constructed NAT and policy rules of existing ASA firewalls, the MPF layered on top of existing security policies.

The ASA 5515-X is a standard ASA firewall with an additional processing module, called “CX” (for “context”) that handles application identification and control. In the ASA 5512-X through 5555-X, the CX next-generation firewall runs as a software module. In the high-end ASA 5585-X, Cisco has two hardware accelerators available today (the SSP10 and SSP20) with two additional models (the SSP40 and SSP60) targeted for end-of-year release, designed to take ASA throughput to 10Gbps and beyond.  

Running CX does come with a performance penalty. For example, the ASA 5515-X we tested is rated for 1.2Gbps of raw firewall throughput, but only 350Mbps of next-generation throughput. With a list price of $5,600, the 5515-X delivers very competitive price/performance compared to other next-gen firewalls.

For Cisco engineers, adding the CX set of next-generation features meant either going back to the drawing board on the ASA or wedging the next-generation feature set in without tipping the boat too much. Cisco took a little of each option: the next-generation features are glued on the side of the ASA in a way that leaves the core firewall completely undisturbed. This is the approach Cisco has taken when adding other security features to the ASA, such as IPS and anti-malware scanning, and will continue to take, as add-ons like web security make their way into the ASA.

But Cisco also promised us that it was serious about a unified management system that would bring ASA and next-gen features together in a single GUI before the end of 2013. Even if the security features are run by very separate policy engines, good policy management tools can give a unified experience to security managers building firewall policies.  

But in the current Version 9.1 we tested, network managers will be very aware that there are two distinct policy engines at work. The ASA’s next-generation features don’t even share an IP address with the base ASA firewall — next-gen policies are configured using Cisco Prime Security Manager (PRSM), a completely different management system from the ASA firewall’s Adaptive Security Device Manager (ASDM).

The basic ASA firewall is still handling access control, NAT and VPN. To enable next-generation features, an entry is made in Service Rules, part of the Modular Policy Framework, that defines which traffic is sent over to the CX part of the firewall. This means that any traffic has to be passed first by the normal access control rules, and then is subject to additional checks and controls based on application and user identification information.   

As each connection passes through the CX engine, three different policies come into play. First, the CX engine decodes SSL. Next, it ties user authentication information to the connection. And finally, the access control policies are applied, blocking or allowing the connection based on user identification and application-layer information (including application id, application type, and URL category) and user identification.

Although most application identification and controls are in the new CX policy set, they’re not all there — everything added to the ASA before CX as part of the Modular Policy Framework is still down in the core ASA. This leads to some overlap and confusion, because you have to look in two places to do very similar application controls.

In some places, the CX and the ASA MPF completely overlap; in other areas, the division of labor is more intuitive. Cisco told us that their engineers are working on an 18-month road map to push application-layer features into the CX code, and move common services, such as identity-based access controls, into the ASA base, with progress expected at each release.

The current release of the ASA 5515-X hardware has a choice of running IPS or next-generation firewall (CX), but can’t run both. Cisco told us that IPS will be integrated with the CX code by the end of 2013, with a separate license to enable the IPS feature set. As for anti-malware, Cisco couldn’t give us a definite answer. Like many security companies, they are shying away from traditional anti-virus scanners as being ineffective against many new threats. With reputation services beautifully integrated into the ASA CX policies, along with botnet detection at the ASA level, Cisco thinks it has the luxury of sitting back and looking at alternative approaches to provide anti-malware protection rather than rushing into yet another anti-virus engine.  

How’s that firewall looking?

We started our testing by reviewing the ASA CX’s basic firewall capabilities. As the great-grandchild of Cisco’s PIX and VPN Concentrator 3000 series, the ASA remains a significant presence in many enterprises. When we tested the ASA as an end-user VPN concentrator with the AnyConnect Secure Mobility Solution v3.0 two years ago, we knew enterprise network managers would be happy -- Cisco delivered solid client support across multiple platforms, end-point posture assessment, integration with their WSA web security gateways and solid performance.  

Although we didn’t dive deep into this part of the ASA, things haven’t changed, and the ASA still looks great as a VPN concentrator for remote access.

For this review, we tested firewall features in 10 areas and found a mixed bag with strong plusses and a few minuses.

Unfortunately, our biggest complaint is in the most important part of any basic firewall: policy management. The core ASA firewall has to filter traffic before it gets to the next-generation application controls, making policy management important. We found this part of the ASA policy, called ACLs (access control lists), to be problematic.

The ASA is unusual among enterprise firewalls because it’s not zone-based (although Cisco IOS firewall is), which means that any deployment with more than two interfaces (or security zones) can get very complicated, very quickly. For example, to build our policy which differentiated between three types of trusted users, servers and the Internet, we had to write more rules than one would use in a zone-based firewall, in some cases defining two rules in different directions on different interfaces to cover the same traffic. This is rules to cover both traffic going into an interface and traffic going out of the same interface — a strange way of thinking that takes a while to get used to and, more importantly, leads to larger rule sets.  

The larger the rule set, the more likely it is to have an error, and the more difficult it is to understand. Since the default behavior for the core firewall is “drop everything” and the next-generation firewall is “permit everything,” you don’t want anything to percolate up to the next-generation part that you’re not comfortable with.  

The ASA’s lack of integration of VPN access controls with other ACLs is also a complicating factor that can lead to human error in networks where the same ASA is used both for VPN and standard firewalling. Our advice: don’t do that, at least not in any complicated network. These devices are inexpensive enough that you can get one for remote access and a another one for firewalling and avoid potential security problems at very little cost.

Areas of the base firewall that we take for granted, such as NAT, VLAN support, dynamic routing, joint Layer 2/Layer 3 support, and IPv6 capabilities are all done very well in the ASA.   

We were disappointed that Cisco still hasn’t pushed BGP routing into the ASA, especially since they’ve done a really incredible job with the routing protocols (OSPF, OSPFv3, EIGRP, RIP and several multicast routing protocols) which come already inside the ASA. It took a while for the outstanding routing feature set we all know and love from IOS to migrate into the ASA, but it was worth the wait, and network managers looking for the ASA to be a strong participant in their dynamic routing will be happy with its capabilities.  

Since we couldn’t test BGP according to our standard NGFW test methodology, we used OSPFv3 instead to integrate the ASA into our existing IPv4 and IPv6 network, a very painless experience. The ASA is also missing full integration between the VPN and dynamic routing. Network managers hoping to use dynamic routing to build large VPN-based WANs will need to stick with IOS for their site-to-site tunnels. We did not test high availability, but Cisco told us that the ASA CX currently supports active/passive failover and will support active/active clustering next year.

Aside from the firewall ACLs, we found two other areas lacking: QoS enforcement, and central management. We’ll cover central management separately, but our testing of QoS enforcement found that the ASA has a very weak feature set. Most firewalls have some ability to help prioritize and control traffic during periods of congestion, but not the ASA. We found that the ASA has only simple policing (limiting bandwidth of a particular application, even when there is plenty available) and queuing without any attempt to manage traffic. QoS is one big area where the ASA could pick up a lot of great features from Cisco IOS.

We think that security managers who have grown up with other firewalls and are not used to the ASA’s quirks will find it a more difficult product to integrate into complicated networks. However, in simpler topologies and especially in environments with a lot of remote-access VPN, the ASA fits in with the rest of the basic firewall marketplace and remains a competitive solution.

Next generation application identification and control

If anything defines next-generation firewalls, it’s application identification and control, and the ASA CX next-generation features aim squarely at that target. To evaluate how well the ASA CX could identify and control applications, we used the same set of 41 test scenarios in nine categories that we tried in our next-gen firewall test last year.  

In the ASA CX, application control is straightforward and simple: “block” or “allow.” There are no other options, such as redirecting to a warning page or sending an alert (although this could be done by scanning the logs). With that in mind, we dove in and started testing the ability of the ASA CX to dive deep into applications.

Compared to our test of other NGFW appliances a year ago, the ASA CX did surprisingly well with a 60% identification and block rate, essentially tying with our top performer (SonicWALL) and narrowly edging our second-best performer, Check Point.

The ASA CX has nice granularity for many applications. For example, with LinkedIn, the ASA CX lets you allow most of LinkedIn, but block job searches or posts. In some cases, the ASA CX divides applications into multiple categories -- for example, there are five LinkedIn applications and 10 Facebook ones. In popular applications, the ASA CX let us focus on more specific application behaviors, such as posting vs. reading or uploading vs. downloading. The design is well thought-out from a security manager’s perspective trying to map a security policy to a firewall rule set.

Failure to identify and block applications can come from two sources: bugs, or just not supporting the application in the first place. With the ASA CX, we found a little of each. For example, with Skype, the ASA CX just didn’t work if we engaged in any type of evasion.