Cisco just released the latest version of the Firepower software aka Firepower 6.0. You can now download this from Cisco.com or directly from your Firepower manager under the update section. A summary of new features include having all ASA models can now use ASDM to manage Firepower services for that individual ASA with Firepower (however best practice is using the centralized manager), SSL Decryption for ASA with Firepower, DNS sink holing, Identity services engine (ISE) integration and much more. Details on each new feature are found below.
URL and DNS-based Security Intelligence: New Security Intelligence feeds based on URLs and Domain Name System (DNS) servers are provided to enhance the existing IP-based Security Intelligence capability.
DNS Inspection and Sinkholes: The same way that attackers use the SSL protocol to hide their activity, attackers use the DNS protocol with the same intentions. For that reason, and as another way to address fast flux-type attacks, the Firepower system provides the ability to intercept DNS traffic requests and take appropriate action based on the policy setting.
On-box SSL Decryption for ASA Servers: Cisco’s next-generation firewall (NGFW), Cisco ASA with FirePOWER Services, now has the ability to locally manage SSL communications and decrypt the traffic through ASDM before performing attack, application, and malware detection against it.
Support for OpenAppID-Defined Applications: OpenAppID is Cisco’s open source, application-focused detection language that enables users to create, share and implement new application detection signatures for custom, localized, and cloud applications, without being dependent upon a NGFW vendor’s release cycle or roadmap. In Version 6.0, the Firepower application detection engine that identifies and controls access to over 3,000 applications has been enhanced to recognize OpenAppID-defined applications. In the same way that Snort was an effort to open source the intrusion detection game, OpenAppID is a way to open source the application detection game. Support for OpenAppId-defined applications demonstrates Cisco’s commitment to the open source initiatives and the flexibility that it provides to our customers.
Captive Portal and Active Authentication: In order to provide better visibility in mapping users to IP addresses and their associated network events, the Captive Portal and Active Authentication feature can be configured to require users to enter their credentials when prompted through a browser window. The mapping also allows policies to be based on a user or group of users. This feature supplements the existing Sourcefire User Agent (SUA) integration with Active Directory to address non-Windows environments, BYOD users, and guests
Integration with Cisco Identity Services Engine (ISE): The integration with Cisco ISE enhances the user identity data available to the system to use in analysis and policy control. By subscribing to Cisco’s Platform Exchange Grid (PxGrid), the Firepower Management Center is able to download additional user data, device type data, device location data, and Security Group Tags (SGTs —a method used by ISE to provide network access control). Beyond the added visibility into the users on your network, this data is also actionable intelligence because it extends the control you can provide by creating policies based on SGTs, or on device type, or any of the other information provided by ISE.
Local Malware Checks: This feature provides the ability to identify popular/common malware directly on the Firepower appliance, and reduces the need to send files for dynamic analysis (sandboxing), either in the cloud or on-prem (see Intergration with AMP Threat Grid). Using high-fidelity ClamAV signatures, files whose SHA-256 lookup return a disposition of Unknown will be analyzed locally on the Firepower appliance to identify common characteristics associated with malware, reducing the need for dynamic analysis.
File Property Analysis: Because certain file types support nested content that can be used to hide malware, this feature provides local analysis of files to determine the viability of malware hidden within. For example, a PDF file can contain different types of files nested inside the file. A file composition report is then run that identifies if nested data exists within the file, what file types those nested files represent, and how likely each nested file is to contain malware. Based on this in formation, you can choose whether or not to send the file on for dynamic analysis
Integration with AMP Threat Grid: Cisco’s acquisition of ThreatGrid in June 2014 increased our abilities in helping our customers address advanced persistent threats, and that technology has now been fully integrated in Firepower v6.0. AMP Threat Grid now provides our sandboxing capabilities in the cloud when using our AMP for Firepower option. Files sent to the cloud for dynamic analysis are securely analyzed and correlated against hundreds of millions of other analyzed malware artifacts to provide a global view of malware attacks, campaigns, and their distribution. Detailed reports identify key behavioral indicators and determine threat scores for faster prioritization and recovery from advanced attacks.
In addition, we have greatly expanded the file types we support for automatic dynamic analysis from just executable files to include PDF and Office documents.
Multiple Domain Management: To address the service provider market which must manage separate customer environments, as well as enterprises with acquisitions (resulting in overlapping IP addresses) or geographic business units that need to be managed separately, the Firepower Management Center now has the ability to create multiple
Policy Hierarchy and Inheritance: To support multiple domain management and make policy administration more efficient, Version 6.0 provides the ability to create a hierarchy of policies. Global policies (e.g., access control) can be established that will apply to all management environments. A policy hierarchy can then be constructed underneath the global policy level to represent different environments, different companies, different business units, or different parts of the organization. Each of these policy environments will inherit the policies of the hierarchy above it, allowing for more consistent and efficient policy management.
Expanded ASDM Management Availability: Cisco’s Adaptive Security Device Manager (ASDM) is the local management feature for Cisco ASA with FirePOWER Services. It was introduced as part of the Cisco ASA 5506-X, ASA 5508-X, and ASA 5516-X appliances. With Firepower v6.0, ASDM is now available on the remaining Cisco ASA with FirePOWER Services appliances (ASA 5512-X / ASA 5515-X / ASA 5525-X / ASA 5545-X / ASA 5555-X / ASA 5585-X)
I was told by CISCO that no one should enable the SSL features of version 6.0 or your ASA will automatically consume 80% of its processing power. I was only told this based out of frustration with the sales tactics used by CISCO to sell sourcefire and its licensing for URL blocking. The only GOTCHA is that it only works on HTTP pages. If you are blocking pages with HTTPS ? the sourcefire will block the page, however leaving you with 404 errors and not telling your users why the page was blocked. Therefore leaving all the techs scrambling for phones the next day because all your users trying to get to facebook think that the internet is down when truly you have no way of decryting the SSL traffic which is required for true URL blocking. Now Cisco recommends that if you want to use it as advertised they recommend buying one of their SSL appliances such as the SSL 2000. Did I mention that this device also runs in the range of near $60,000.00 (OUCH). Since I didn’t have and extra 60k to whip out of my pocket…. Whats the next best option ? Just use a proxy appliance to block traffic with based on URL’s the way you were prior to buying this next gen appliance and its applicable licenses to miss lead you into believe you can do something you really can’t .
On the side note. Traffic inspection work as should . malware detection is So-So and there is always the issue with rules overlapping causing other rules to fail.
A VERY OVERLY complicated scenario for something soooo simple.
Hi Mike,
The numbers have been all over the place since it is hard to pin point the impact of enabling SSL. This is a industry problem meaning all vendors see this. The reason doesn’t have to do with process power. It has to do with decrypting a ton more traffic IE increasing the traffic being seen.
Regarding 80%, that depends. Most people use selective decryption meaning the are not decrypting things like Banking since it may be illegal to do so and most admins don’t care what happens between the bank connection as long as they see the source and destination. Things like facebook on the other hand are areas people tend to decrypt. Firepower 6.0 can do this and if you are selective about what you decrypt, you probably will be way under 80% the performance hit. You are right though, a possible work around is using a separate appliance such as either the dedicated SSL appliance you mentioned or sizing down the firewall and going with the firewall followed by IPS deployment where the IPS also does the application controls including SSL decryption.
If a vendor promises you they won’t see a hit on a UTL appliance, they are not telling you everything.
Regarding the other feedback, glad to hear traffic inspection works. When you say malware detection, I assume this is network AMP. Make sure to have a policy for both local and cloud as well as verify how you are setting it up. You should have a default monitor policy for IDS and Malware so it isn’t overlapping with other things. Worst case, open a TAC case and have them tune it for you so it functions better.
Hope this helps
Cant do SSL inspection using a external device to a routed ASA running Sourcefire. It wont work. They require you to do multi-context mode, which is buggy and doesn’t work.
Only options are:
1. Have two physical separate ASAs, one for the routing/vpn and a second inline running transparent mode with sourcefire on it.
2. Get the actual Sourcefire appliance and place the SSL appliance after ASA.
3. Run the SSL decryption on the box (which isnt great).
The real problem i am seeing is that it seems to be no way of manually whitelisting domain to not be inspected by the current ssl policy. Even if you right click the url under the connections view and click white-list the system doesn’t take it.
Hi Guy that knows. This depends on what version of ASA and Firepower you are looking at. If you use the separate ASA running firepower, then traffic has to be routed via a policy map from the ASA through Firepower hence your dilemma. The unified image now available with 6.0.1 and soon 6.1 doesn’t require this policy map since its all the same image. Another work around is considering a F5 or A10 that can provide SSL for everything within your network.
Do understand SSL is very performance heavy due to decryption everything meaning increasing the traffic by X fold. For example, if you size a unified threat management security solution for 1 gig and turn on SSL for everything, you increase that traffic to multiple gigs. Any solution that is sized for 1 gig handling 10 gigs for example would start crawling. Selective decryption can sort of help but its still a bear that all vendors providing next gen firewall type stuff deal with. The ones that say they don’t see this performance hit are not truly decryption all traffic.
My final point to make is SSL isn’t necessary a security feature. Its more about visibility. The top concern people state is an attack over SSL that a IPS won’t be able to detect. Well first off, many attacks do not happen over SSL since the attacker would have to use certificates hence revealing info about him/herself. Also IPS looks for known threats so just one detection method. What about DNS? Reputation Security IE evaluating the link you are connecting to before the attack? What about evaluating the traffic once it hits the endpoint. By layering security, even an attack over SSL would have to beat other layers before owning the endpoint. Point is I see some people spend a lot of money beefing up things to do SSL where it could be invested in layering security on top of the IPS functionality at half the cost with double the effectiveness. That or vendors providing dedicated SSL tools such as F5 and A10 typically are cheaper than sizing up and UTM just to handle large SSL numbers. Hope this helps
Hey I just happened to read your blog and this discussion catched my attention.
I’ve read a while ago about SSL Appliances from Cisco with it’s “features” that can decrypt SSL packet and encrypt it again, but for the inspection it still has to send the traffic to Security appliances, which in this case is ASA-Firepower.
What am I asking is, if I have ASA-Firepower inspect anything from internet to inside, then where would I put my SSL Appliances? I just don’t get how the traffic will flow if I’m using SSL appliances too.