ASA CX SSP management

The Context aware modules for the Cisco ASA provide enhanced functionality for L7 services. These include but are not limited to URL category/reputation databases, HTTP inspections, AVC, TLS proxy, TCP Proxy, and Multiple Policy decision points.

The management of these devices when loaded with a CX module different from the traditional firewalls and require some thought when scaling in a large environment. The CX modules are configured by PRSM – Prime Security Manager. It is a HTML5 based Web UI that is comes in two flavors. The PRSM install on a local ASA provides a cut down amount of features. It is limited to Configuration, Eventing, and reporting. When PRSM is installed as a standalone product on a dedicated service, included are the above plus multi-device support, RBAC, device and object import, push and pull deployments, historical event analysis, distributed deployment and configuration synchronization across HA environments. This lends itself to large-scale management.

Not quite your plug and play.

Not quite your plug and play.

This picture shows the management architecture that supports the Cisco CX when looking at it from an end to end solution. Firstly, the Administrator will have the client installed for Prime Security Manager. This will allow access to the firewall and PRSM. This is different to the old CLI method. To present the information requested by the administrator the ASA-CX talks to PRSM via a RESTful XML lookup. This two-way transaction provides information as well as deployment through an administrators interactions.

Cisco SIO support the ASA-CX and PRSM by offering up the latest information surrounding threats and emerging online trends by pushing down information manually or automatically. These updates include Application signatures, Web reputation scores, URL filters, and trusted CA root revocation. It is important to note that all but CA root revocation requires a subscription based licensing.

When building out a Cisco firewall edge solution you need to consider the method of which you manage your hardware and the method in which this will increase your firewalls functionality. Ensuring an adequate management environment exists for the CX is important as it provides Administrators the ability to use this Next Generation Firewall to its full potential.

ASA SSP and CX SSP interactions

The ASA SSP module is the traditional firewall module found in the 5585-x chassis. It performs the default firewall roles and has the standard firewall features. If you’re looking to do some detailed L7 work with focus on user authentication, encryption, and policies, you need to look at the CX SSP module.



When configured to process through the context module, the ASA will perform a pass off. This pass off is how the ASA SSP module and the CX SSP module interact. When a flow enters an ASA port it moves through the switch fabric. This is passed into the CPU for processing. Traffic matched for context inspection is then, via the firewall backplane, sent into the CX SSP switch fabric. Processed against another set of rules and a different command set, the context module will then pass an accepted flow back down through the backplane and out the ASA SSP as egress traffic.

Redirection to the ASA CX SSP is done as a service policy leveraging the ASA Modular policy framework. These frameworks allow an administrator to match traffic for inspection based on criteria such as protocol ports, user identity (IDFW), interface, and source/destination address. Traffic segments can be matched step by step which gives control in migrations and deployments.

There are three policies of the ASA CX SSP in which an administrator can look at their user traffic. The access policy – Firewall styled allow or deny, Identity policy – who are you and matching the relevant flows, and a Decryption policy – when and what to decrypt. As always, policies are evaluated top down and works on a first match basis. The order is important to remember. It is Identity, Decryption, and Access. The implicit policies are applied to a flow if there are no policy matches. Access policy sets end with an implicit allow all, decryption policies end with a do no encrypt, and identity policies end with a do not authenticate.

Placement and design is important when considering the position of the CX in your network. The CX is a set of technologies focussed for Internet and Edge deployments. Security controls focus around user and client outbound protection. You could gain visibility into your network with the CX positioned in a Remote Access WAN point, Centralised desktop environment, or specific DC use cases. Though I personally would spend FAR more time on the latter considering throughput, protocol support, and load place on the device before using it there.

Once you gain insight into how the ASA CX performs its functions and works to process its flows, an administrator can look to use the technologies of the platform. I personally cannot stress enough the importance of understanding your applications that run through the ASA SSP and the CX SSP as many will require granular permits or exceptions based on the application architecture.