There’s been a lot of talk recently about the coming of the “next generation” firewall. A simple firewall is nothing more than a high-speed packet filter. You match on criteria such as access list or protocol type and then decide what to do with the packet from there. It’s so simple in fact that you can setup a firewall on a Cisco router like Jeremy Stretch has done. However, the days of the packet filtering firewall are quickly coming to an end. Newer firewalls must have the intelligence to identify traffic not by IP address or port number. In today’s network world, almost all applications tunnel themselves over HTTP, either due to their nature as web-based apps or the fact that they take advantage of port 80 being open through almost every firewall. The key to being able to identify malicious or non-desired traffic attempting to use HTTP as a “common carrier” is to inspect the packet at a deeper level than just port number. Of course, many of the firewalls that I’ve looked at in the past that claim to do deep packet inspection either did a very bad job of it or did such a great job inspecting that the aggregate throughput of the firewall dropped to the point of being useless. How do we balance the need to look more closely at the packet with the desire to not have it slow our network to the point of tears?
Cisco has spent a lot of time and money on the ASA line of firewalls. I’ve installed quite a few of them myself and they are pretty decent when it comes to high speed packet filtering. However, my customers are now asking for the deeper packet inspection that Cisco hasn’t yet been able to provide. Next-Gen vendors like Palo Alto and Sonicwall (now a part of Dell) have been playing up their additional capabilities to beat the ASA head-on in competitions where blocking outbound NetBIOS-over-TCP is less important than keeping people off of Farmville. To answer the challenge, Cisco recently announced the CX addition to the ASA family. While I haven’t yet had a chance to fire one of these things up, I thought I’d take a moment to talk about it and aggregate some questions and answers about the specs and capabilities.
The ASA CX is a Security Services Processor (SSP) module that today runs on the ASA 5585-X model. It’s a beastly server-type device that has 12GB or 24GB or RAM, 600GB of RAID-1 disk space and 8GB of flash storage. The lower-end model can take up to 2Gbps throughput and the bigger brother can handle 5Gbps. It scans over 1000 applications and more than 75,000 “micro” applications to determine whether the user is listening to iTunes in the cloud or watching HD video on Youtube. The ASA CX also utilizes other products in the Cisco Secure-X portfolio to feed it information. The Cisco AnyConnect Secure VPN client allows the CX to identify traffic that isn’t HTTP-based, as right now the CX can only identify traffic via HTTP User Agent in the absence of AnyConnect. In addition, the Cisco Security Intelligence Operation (SIO) Manager can aggregate information from different points on the network to give the admins a much bigger picture of what is going on to prevent things such as zero-day attack outbreaks and malware infections.
One of the nice new features of the ASA CX that’s been pointed out by Greg Ferro is the user interface for the CX module. Rather than relying on the Java-based ADSM client or forcing users to learn yet another CLI convention, Cisco decided to include a copy of the Cisco Prime Security Manager on-box to manage the CX module. This is arguably the best way for Cisco to have created an easy way for customers to easily utilize the features of the new CX module. I’ve recently had a chance to play around with the Identity Services Engine (ISE) and while the UI is very slick and useful, I cried a little when I started using the ADE-OS interface on the CLI. It’s not the same as the IOS or CUCM CLI that I’m used to, so I spent much of my time figuring out how to do things I’ve already learned to do twice before. Instead, with the CX Prime Security Manager interface, Cisco has allowed me to take a UI that I’m already comfortable with and apply it to the new features in the firewall module. In addition, I can forego the use of the on-box Prime instance and instead register the CX to an existing Prime installation for a single point of management for all my security needs. I’m sure that the firewall itself still needs to use ASDM for configuration and that the Prime instance is only for the CX module but this is still a step in the right direction.
There are some downsides to the CX right now. That’s to be expected in any 1.0-type launch. Firstly, you need an ASA 5585-X to run the thing. That’s a pretty hefty firewall. It’s an expensive one too. It makes sense that Cisco will want to ensure that the product works well on the best box it has before trying to pare down the module to run effectively on the lower ASA-X series firewall. Still, I highly doubt Cisco will ever port this module to run on the plain ASA series. So if you want to do Next-Gen firewalling, you’re going to need to break out the forklift no matter what. In the 1.0 CX release, there’s also no support for IPS, non-web based application identification without AnyConnect, or SSH decryption (although it can do SSL/TLS decryption on the fly). It also doesn’t currently integrate with ISE for posture assessment and identity enforcement. That’s going to be critical in the future to allow full integration with the rest of Secure-X.
If you’d like to learn more at the new ASA CX, check out the pages on Cisco’s website. There’s also an excellent Youtube walkthrough:
Cisco has needed a Next-Gen firewall for quite a while. When the flagship of your fleet looks like the Stargazer instead of the Enterprise-D, it’s time for a serious upgrade. I know that there have been some challenges in Cisco’s security division as of late, but I hope that they’ve been sorted out and the can start moving down the road. At the same time, I’ve got horrible memories of the last time Cisco tried to extend the Unified Threat Management (UTM) profile of the ASA with the Content Security and Control (CSC) module. That outsourced piece of lovely was a source of constant headache for the one or two customers that had it. On top of it all, everything inside was licensed from Trend Micro. That meant that you had to pay them a fee every year on top of the maintenance you were paying to Cisco! Hopefully by building the CX module with Cisco technologies such as Network-Based Application Recognition (NBAR) version 2, Cisco can avoid having the new shiny part of it’s family being panned by the real firewall people out there and languish year-to-year before finally being put out of it’s misery, much like the CSC module or Star Trek: Enterprise. I’m sure that’s why they decided to call the new module the CX and not the NX. No sense cursing it out of the gate.