Cisco ASA CX delivers strong application awareness; weaknesses in management, integration and threat mitigation are being addressed
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.