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.