Cisco ASA Next-Generation Firewall Services

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.

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:

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.

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.

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:

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.

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.

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.

A. ASA CX is managed using Cisco Prime^™ Security Manager, which supports both single- and multi-device manager form factors.

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.

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.

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.

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.

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.

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.

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.

A. Yes. ASA CX supports custom objects that are based on existing 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.

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.

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.

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.

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.

A. Not currently. Posture-based enforcement will be implemented in a future version.

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.

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.

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.

A. Not currently. IPS capabilities will be embedded in ASA CX in a near-term future release.

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.

A. Not currently. This feature will be supported by ASA CX in a future release.

A. No. ASA CX does not support multiple security contexts.

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.

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.

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.

A. Yes. The ASA firewall can be placed in transparent mode as normal; no configuration is required on ASA CX.