Cisco impresses with first crack at next-gen firewall

In our case, we evaded the Skype filter using the oh-so-stealthy “wait for a few minutes” uber-hacker technique. While the ASA CX blocked Skype initially, if we simply waited a few minutes, calls would go through. In other cases, such as H.323 conferencing, Microsoft Exchange, and Sophos anti-virus updates, the ASA CX didn’t work at all even though these applications were part of its repertoire.  

Our testing from a year ago was all based on laptop clients, both Mac and Windows. With the ASA CX, though, we added a new twist by trying handheld devices for two commonly mentioned applications: Facebook and LinkedIn. The ASA CX didn’t do its job when we used the native applications to connect to these services.  

We did see that the ASA CX team learned from the mistakes of their peers. For example, in our testing last year we were able to work around all the other next-generation firewalls attempts to block Google Mail by simply using the basic HTML interface. That trick didn’t work with the ASA CX, which stubbornly blocked us no matter what we tried.  

The ASA CX also was fully IPv6 aware, and if it blocked an application on IPv4, the same block worked with IPv6, whether we used a laptop or an iPad.  

We also tested the ASA CX’s ability to use user- and group-based identification as part of application controls. Anyone who has tried to deploy identity-based networking or NAC knows that one of the hardest parts is gathering the identity from the user or device.  

The ASA CX has two mechanisms available to it: one is a captive portal approach, which works in certain guest user environments where people don’t have much opportunity to complain. The other is called “passive authentication” and it depends on installing a Cisco agent on Windows domain controllers in a network. When a Windows user logs onto their domain-connected PC, this generates an incidental log entry in the Windows Event Logs which happens to have the apparent IP address of the PC as well as the user name used to login. We installed this agent on our lab’s domain controllers very easily and were able to link the ASA CX authentication controls to user identity. Sort-of.

It happens that our lab has some internal NAT going on to simplify routing when we build networks quickly for tests like this and this confounded the ASA CX, as the user-to-IP mappings were not correct. The same issue would happen in any network with NAT between the PC and the domain controllers. Of course, there are also scalability issues — if one domain is all you need, that’s great, but some enterprises have dozens or even hundreds of domains running around on their wide area network. Of course, this only works for domain-attached Windows PCs — still a dominant force in enterprise networks, but not the only way to deliver computing nowadays. And let’s not even mention that there’s no real tracking of when someone disconnects from the LAN.

None of this is Cisco’s fault -- any vendor who tries the hokey pokey of sniffing Windows logins or capturing the information from the logs is going to have the same problem. There are other tricks and techniques various NAC vendors have created to work around this fundamental problem, but the only 100% real solution is having a client tool on the connecting PC which collects authentication information and interacts actively with enforcement devices.

And this brings us to a serious problem in the ASA CX: all of Cisco’s products for NAC, and all of Cisco’s products for Secure Mobility, don’t interact with the ASA CX. The problem is especially ludicrous when it comes to remote access VPN -- even if the remote access tunnel is connected to the ASA CX, it stubbornly won’t pass user identity information up to the CX.   

Failing to make this obvious link even in a v1.0 product like the ASA CX is poor product management.

SSL decryption

If one of the main advantages of a next generation firewall is application and protocol identification and control, then SSL decryption is a basic requirement. In the ASA CX, SSL Decryption is handled by a separate set of policy rules, essentially defining which traffic is decrypted and which is not. From a management point of view, configuration and control of the SSL Decryption part of the ASA CX is outstanding. We started by installing our own certification authority, which is trusted by all systems in our lab, into the ASA CX, a simple matter. Then, we enabled decryption for all traffic and let ‘er rip.

At first glance, the ASA CX worked great, catching SSL on non-standard ports, and extending application identification even into encrypted sessions. And for the most part, the ASA CX SSL decryption is just fine and didn’t create any performance problems in our limited lab testing. But it’s not perfect.  

The biggest issue we ran into was application identification of encrypted traffic. Although the ASA CX does a good job of decrypting and re-encrypting SSL traffic, the application identification engine doesn’t work properly for many protocols. It’s not a complete failure -- the most important protocol that most people care about, HTTP, is successfully unpacked and identified. But security managers who want to identify and control non-HTTP other protocols which might be blocked by policy can’t see into the encrypted session. For example, the ASA CX was great at identifying unencrypted IMAP on standard and non-standard ports. But if we opened up a connection to an IMAP server on the standard IMAP-over-SSL port, the ASA CX didn’t identify the traffic as IMAP, but just as SSL. We had the same issue with SMTP using standard ports. Once the traffic was encrypted, the ASA CX didn’t identify these protocols. For HTTP traffic, there wasn’t a problem -- the ASA CX unpacked encrypted HTTP just fine and identified applications, such as Google Mail and Facebook inside of the encrypted session.  

Early on, we also had smaller issues with some SSL negotiation that the ASA CX didn’t like, and hence inappropriately blocked. This first showed up in our lab’s iPhone and iPad, which started behaving poorly and couldn’t communicate back to the iCloud mother ship. The problem was easy to see in the ASA CX logs, but there was no simple solution other than to exempt certain IP addresses at iCloud from SSL decryption. Problem solved, but maintenance and documentation headache begun. And we didn’t know how that would affect other controls. For example, we tried blocking iTunes installation of applications, which didn’t work. Was that because the SSL wasn’t being properly decrypted, or was it just a bug in the iTunes blocking?

A different issue that slowed us is related to the list of trusted root certification authorities pre-loaded by Cisco. The ASA CX will engage in man-in-the-middle SSL decryption only if the server presents a certificate trusted by the ASA CX. Cisco doesn’t release the list of CAs that it will trust, leaving you to guess and debug. Most of our tests were fine, but we did run into a  few perfectly legitimate servers that the ASA CX wouldn’t trust until we tracked down their CA and intermediate CA certificates. The lack of a list of CAs makes debugging hard, and there is no legitimate reason to keep this list secret -- every other product with similar trust settings, such as Windows and Mac OS X, is happy to let you see and edit the list of trusted CAs.

The ASA CX did not fare well in our test of invalid certificates, potentially hiding revoked or incorrect certificates from the end user. When a server hands a certificate to the ASA CX as part of the SSL handshake, the ASA does not do full checks on that certificate. Then, it replaces the certificate with one that it creates — and any revocation information is lost. In simpler terms, the main mechanisms in place in the world of digital certificates and X.509 are not correctly implemented by the ASA CX, leading to a small but very significant vulnerability, especially in the world of spear-phishing attacks.

Next generation visibility and management

We found the ASA CX with Cisco Prime Security Manager (PRSM) provides outstanding visibility into application type and flow statistics, with a strong drill-down capabilities and a well-designed interface. However, ASA overall management is in rapid motion, and we found it difficult to evaluate the rest of the management interface.

The ASA’s standard management interface, for those who don’t want to use the command line interface, is ASDM (Adaptive Security Device Manager), a Java-based GUI that is used to handle most aspects of ASA configuration and management. ASDM has evolved into a stable and powerful product. ASDM isn’t the most elegant interface for managing a firewall and is tightly tied to the command-line configurations it generates, but it’s solid and gets the job done fairly quickly.  

Prime is Cisco’s new management interface, designed to work across security, switching and routing product lines. When managing firewalls, Cisco calls it PRSM, a web-based GUI that can be run either on-box directly on the ASA or on a separate management server. Although on-box operation is supported, we think that any manager with more than a single ASA CX should elect for a separate management appliance, even though there is an additional modest cost ($3,000 list price for five devices).  

Without a separate management server, PRSM presents a risk to the firewall by running hosting reporting, log storage, and management all on the same CPU that is handling packets. On-box PRSM makes for a fast demo of PRSM capabilities, but we prefer to ship logs to a separate server so that any analysis and debugging won’t risk slowing down a production device.  

The ASA CX is only managed by PRSM, which creates a disconnect between the next-generation firewall rules and the rest of the ASA management. However strange this interface is, it’s a bit unfair to grade the ASA down because of it -- Cisco told us that migration of firewall configuration to PRSM (from ASDM) is their No.1 priority for 2013 for the ASA line.  

So, yes, today, network managers need to go through contortions to manage a firewall, but we are looking at a product in transition. Even though PRSM’s visibility capabilities are excellent, network managers will find PRSM’s configuration capabilities to be clumsy and disappointing compared to ASDM. Firewall rules are spread sparsely across a web page without critical information, making policy analysis and editing difficult; policy objects are named with the least helpful terms possible, and redundant and inconsistent terminology pervades the interface. We hope that this poor configuration interface is cleaned up as part of the migration of ASDM functionality into PRSM.  

How We Tested

We used the methodology from our 2012 Next Generation firewall test so that readers could evaluate the Cisco ASA CX against competition from Barracuda, Check Point, Fortinet, Palo Alto Networks, and SonicWALL.  

Because the Cisco ASA CX does not support anti-malware and traditional IPS, we did not repeat those tests.  

We also changed our application identification testing slightly to include a wider range of clients, including smart phone and tablet devices. We highlighted the performance of those clients so that readers can more fairly compare coverage and accuracy of the ASA CX against competitive products.