A.Cisco ASA CX Context-Aware Security is a modular security service that extends the ASA platform by blending a proven, stateful inspection firewall with next-generation capabilities and a host of additional network-based security controls - for end-to-end network intelligence and streamlined security operations. Cisco ASA CX enables organizations to rapidly adapt to dynamic business needs while maintaining the highest levels of security. ASA CX delivers application and user ID awareness capabilities for enhanced visibility and control of network traffic, which is essential for next-generation firewalls. In addition, ASA CX enables administrators to control specific behaviors within allowed micro-applications, restrict web and web application usage based on reputation of the site, proactively protect against Internet threats, and enforce differentiated policies based on the user, device, role, and application type.
Q. What are the benefits of Cisco ASA CX Context-Aware Security?
A. Cisco ASA CX Context-Aware Security empowers enterprises to finally say Yes to applications, devices, and the evolving global workforce. Most next-generation firewalls differ from classic firewalls in that they can identify which applications are being requested and which user has requested them. While application and user awareness can be effective, with so much more happening in the network, these firewalls simply cannot provide the complete level of visibility and control administrators need to help them effectively manage their complex network security challenges. Cisco ASA CX Context-Aware Security is different. While ASA CX provides the application and user ID awareness that is essential for any next-generation firewall, it also delivers:
• Granular application visibility and control, including behavior controls within allowed micro-applications
• Reputation-based web security
• Passive and active authentication
• User device information
• Near real-time threat protection
Q. Does ASA CX protect against zero-day threats and other malware?
A. Yes. ASA CX uses threat intelligence feeds from Cisco Security Intelligence Operations (SIO), which employ the global footprint of Cisco security deployments (more than 2 million devices) to analyze 70 percent of the world's Internet traffic from email, IPS, and web threat vectors. The feeds are updated every three to five minutes for near-real-time protection from zero-day threats.
Q. Will I have to overwrite my existing classic firewall policies?
A. No. ASA CX enables organizations to continue to use their existing firewall rules and objects while adding richer, context-aware rules that can act intelligently on contextual information. ASA CX supports Layer 3 and Layer 4 stateful firewall features, including access control, network address translation, and stateful inspection, so organizations can keep their existing stateful inspection firewall policies while adding rich Layer 7 context-aware rules.
Q. How does ASA CX fit into the Cisco SecureX Architecture®?
A. The Cisco SecureX Architecture is a context-aware, network-centric approach to security that enables consistent security enforcement throughout the organization, greater alignment of security policies with business needs, integrated global intelligence, and simplified delivery. The result is intelligent security enforcement - from endpoints to the data center to the cloud. The Cisco SecureX Architecture is delivered through a set of security solutions, including:
• Cisco AnyConnect® Secure Mobility to provide detailed information on the type, location, and posture of mobile devices before they can access the network
• Cisco Security Intelligence Operation (SIO) for near-real-time protection from zero-day threats
Cisco ASA CX uses these SecureX technologies to provide deep insights about what is happening throughout the network, to enable enterprises to make more informed security decisions.
Q. Which ASA platforms support ASA CX?
A. ASA CX is delivered in two form factors: as a hardware module on the Cisco ASA 5585-X SSP 10 and ASA 5585-X SSP 20 security appliances, and as a software module supported on the Cisco ASA 5500-X Series of midrange security appliances.
Q. Can ASA CX be deployed as a virtual machine on an ESX host?
A. No. ASA CX is not available in a virtual form factor. The Cisco ASA 1000V Cloud Firewall is Cisco's solution for securing virtual and cloud environments.
Q. What is the best deployment scenario for ASA CX?
A. The majority of the application signatures that are currently supported by ASA CX are focused on protecting Internet activity. In addition, ASA CX bundles powerful URL filtering and reputation-based filtering that are most useful at the network edge. Future releases will include signatures and capabilities that will be more useful in data center deployments.
Q. How is ASA CX managed?
A. ASA CX is managed using Cisco Prime™ Security Manager, which supports both single- and multi-device manager form factors.
Q. How are applications recognized?
A. ASA CX provides visibility and control into more than 1000 applications and 75,000 micro-applications, enabling organizations to provide individual or group-based access to specific components of an application while disabling other components (such as allowing Facebook for general use, while blocking Facebook games). Specific behaviors can also be blocked within allowed micro-applications for an additional layer of control. Application recognition is based on signatures, heuristics, and content scanning, removing the need to tie applications to ports. As a result, administrators can easily block port- and protocol-hopping applications such as Skype and other peer-to-peer (P2P) applications for more effective security, while writing fewer policies.
Q. What about nonstandard ports?
A. Cisco ASA CX can identify traffic even when it is using nonstandard ports. As an example, if HTTP is running on Port 8080 or SSH is running on Port 16022, ASA CX will still identify the traffic correctly as HTTP or SSH.
Q. What if there are multiple applications in a single flow?
A. ASA CX employs deep packet inspection for application recognition, and therefore does not require a separate connection per application. As an example, modern browsers send multiple HTTP GET requests over the same persistent TCP connection. ASA CX will subject each of these requests to classification and threat analysis using application signatures, URL filtering, and web reputation. If two different transactions share the same connection, they will still be identified as separate transactions, each having its own deep packet inspection results.
Q. How is unidentified (unknown) traffic handled?
A. Once administrators create rules for the applications they care about, the rest of the traffic will fall to the bottom policy, and administrators will be able to choose an action for that policy. Also, with ASA CX, the Layer 3 and Layer 4 rules on the ASA security appliance will continue to run, reducing the surface area of traffic (for example, inbound access can still be controlled very tightly with Layer 3/Layer 4 rules). In a future version, ASA CX will enable administrators to create rules for unknown traffic on a per-policy basis.
Q. Does Cisco deliver newer application recognition signatures?
A. Yes. New application signatures are usually released on a monthly basis. Once the new application signatures are updated in the Cisco cloud infrastructure, ASA CX devices are updated within a few minutes.
Q. How can I determine what applications are supported?
A. Cisco Prime Security Manager provides an application browser, which enables administrators to identify all applications and micro-applications that are supported by ASA CX. Cisco Prime Security Manager also includes quick filtering capabilities, so administrators can search for specific applications.
Q. Can I create my own (custom) application signatures?
A. Not with the current release. Currently, ASA CX includes a robust set of more than 1000 applications and 75,000 micro-applications. The ability for administrators to create their own application signatures is a feature that will be included in a future release.
Q. Can I create my own (custom) application categories?
A. Yes. ASA CX supports custom objects that are based on existing applications.
Q. Some applications like Skype use port hopping and other evasive techniques. Can ASA CX recognize these applications?
A. Yes. ASA CX recognizes applications based on signatures, heuristics, and content scanning, removing the need to tie applications to ports. As a result, administrators will be able to easily block port- and protocol-hopping applications such as Skype.
Q. How are users identified?
A. Users can be identified via both passive and active methods. Passively identified users are determined using the Cisco Active Directory (AD) agent to create an IP-to-user mapping from the AD logs. This is the same process used by the Cisco ASA Identity Firewall feature available in Cisco ASA Software Release 8.4.2 and later. ASA CX can also actively identify users through true authentication via schemes such as Microsoft Windows NT LAN Manager (NTLM), Kerberos, and Lightweight Directory Access Protocol (LDAP). This type of authentication can either prompt the user for credentials, or it can be handled transparently by the browser. Future releases of ASA CX will also use the 802.1x authentication performed in the network by the Cisco TrustSec® infrastructure to identify users and devices.
Q. Does ASA CX work with the Cisco Identity Services Engine for identity enforcement?
A. Not with the current release. Currently, ASA CX uses the Cisco AD agent, which is a component of the Identity Services Engine, for identification. The AD agent tracks all users who are logged into the network and maps the source IP addresses. In a future release, ASA CX will also support access control based on TrustSec tags.
Device Type Enforcement
Q. How are devices identified?
A. ASA CX uses the Cisco AnyConnect Secure Mobility Client to determine the specific types of devices attempting to gain access to the network, as well as their locations (on-premises versus off-premises), to enable administrators to confidently allow devices while maintaining high levels of network protection and control. If AnyConnect is not used, ASA CX will use the UserAgent field of the HTTP header for this identification.
Q. Can ASA CX use device-type enforcement for nonweb traffic?
A. Yes. ASA CX can get device-type information from devices running the Cisco AnyConnect Secure Mobility Client. ASA CX can use this information for access control enforcement, even if the traffic from these clients is not web-based.
Q. Can ASA CX use device posture information to enforce access?
A. Not currently. Posture-based enforcement will be implemented in a future version.
Q. What about IP phones, video streaming servers, and other devices that do not support browsers or AnyConnect?
A. Currently, ASA CX cannot identify the device type for traffic that is not web-based, if the source device is not running AnyConnect. In a future release, ASA CX will also support access control based on TrustSec tags, at which point this use case will be supported.
Q. Can ASA CX decrypt Transport Layer Security/Secure Sockets Layer (TLS/SSL) or Secure Shell (SSH) traffic for inspection?
A. Currently, ASA CX is able to decrypt TLS/SSL. Decryption of SSH will be enabled in a future release. ASA CX will decrypt HTTPS traffic to identify encrypted applications. This decryption can be intelligently performed based on rich context parameters such as source (user, subnet), destination (fully qualified domain name [FQDN], web category, subnet), and reputation of the destination servers.
Q. What about remote-access (VPN) users? Do they get all the same protection?
A. Yes. ASA CX works with AnyConnect to provide seamless, secure mobility, regardless of user's location. When the user is located outside the firewall, AnyConnect will recognize that the user is in an untrusted network, and will establish a connection to the most optimal network scanning element (that is, the most optimal ASA CX). As a result, consistent access rules can be applied to the user's traffic, even when the user is located outside the office.
Q. Does ASA CX support intrusion protection system (IPS) functionality?
A. Not currently. IPS capabilities will be embedded in ASA CX in a near-term future release.
Q. Is quality of service (QoS) supported?
A. Yes. QoS is supported on ASA CX, but it is handled by the ASA firewall blade. Customers can create QoS rules on the ASA firewall, just as they do now. QoS based on applications, users, and other context will be supported by ASA CX in a future release.
Q. Are TrustSec Security Group Tags (SGTs) supported?
A. Not currently. This feature will be supported by ASA CX in a future release.
Q. Does ASA CX support multiple security contexts like the ASA firewall?
A. No. ASA CX does not support multiple security contexts.
Q. How about performance? Will the CX blade slow down my ASA firewall?
A. As with any device performing deep packet inspection, performance will be lower than with devices that only route traffic or perform stateful inspection. However, all ASA CX devices will provide gigabit and multigigabit throughput levels. Unlike competitive offerings, which require application control to be continuously active for all the traffic, ASA CX does not create any such restriction. Administrators can determine which traffic will be inspected by ASA CX, and continue to use Layer 3/Layer 4 rules where deep packet inspection is not required. This capability provides the flexibility for servers requiring low-latency performance to be exempted from deep packet inspection and still benefit from ASA stateful inspection. As a result, much more efficient and higher-performance firewalling is possible, compared with only creating application-based rules.
Q. Do I have to recreate my existing ASA access lists on ASA CX?
A. No. ASA CX allows administrators to use existing Layer 3/Layer 4 rules and network objects. For example, if an administrator has defined 5000 network objects on the ASA firewall, these objects can be reused in the rich rules on ASA CX. Administrators can migrate their current rule set to Layer 7 rules over time, as it makes sense to do so.
Q. Can ASA CX be used in multicontext mode?
A. Not currently. In the current release, the ASA stateful inspection firewall must be in single-context mode to use ASA CX. However, multicontext mode will be supported in a future release.
Q. Can ASA CX be used in transparent mode?
A. Yes. The ASA firewall can be placed in transparent mode as normal; no configuration is required on ASA CX.