Thought I might read up on ASA+firepower and maybe look a bit more like a genuine CCNP-Sec since my ASA-fu was getting seriously rusty....
http://www.thegurleyman.com/shortcomings-of-cisco-asa-5500-x-with-firepower-services/ (http://www.thegurleyman.com/shortcomings-of-cisco-asa-5500-x-with-firepower-services/)
Am I reading this right? The latest and greatest ASA with FIREPOWER(tm) and oh btw don't forget to throw out the CX stuff we were pushing just a couple of years again, its not like Cisco decides to arbitrarily can security products/lines all the time with no seeming overall direction....
- can't do SSL inspection. WTF
- can see user ID but only via agents (HA HA HA HA HA Palo just needs 'domain join' basically) AND you can't actually write any rules against it
- FIREPOWER fails close, can't fail open
- overall nastiness of running as a separate VM so you are still running 2 devices with 2 configs, 2 touchpoints, 2 syntaxes/GUIs etc. and have to manage the linkage (good old inspect maps)
Surely the 800 pound gorilla of networking can't have a NGFW that's THIS, er, how do I put it... not NG?
On the plus side the article and our friends in NSS labs rate it quite highly purely on the inspection bit (but the lack of HTTPS is really really poor).
Or do most of the big boys don't care because they run real IPSes and let the firewalls just do the traditional stuff/VPN?
I was actually not aware they couldn't do SSL inspection. Isn't that something just about every other "NGFW" can do?
Did some Google-Fu. Sourcefire 5.4 and up can do SSL inspection, same as Palo - via SSL Proxying.
Fail close is scary where unintended.
However, IPS devices already don't do SSL inspection... unless one buys the additional module/license for it.
An issue with SSL inspection is to answer the question of where one does it, since all that decryption and then re-encryption is going to take a lot of CPU spin cycles and will make for a network chokepoint. You don't want it *everywhere*, that's for certain.
According to that article, its not that sourcefire can't, its that the sourcefire bolt-on for ASA can't on current software, speculation it will be enabled on v6 but its done in software and will take a big speed hit.
https://supportforums.cisco.com/discussion/12318926/asa-firepower-ssl-decryption (https://supportforums.cisco.com/discussion/12318926/asa-firepower-ssl-decryption)
I guess you'd want to inspect internal user HTTPS excluding banking/medical, and inbound HTTPS to your servers. Guest HTTPS can just to out and wreak havok assuming you have isolated them to a guest VRF or segment. This is becoming more and more important as facebook etc. starts turning on HTTPS.
Side note, had an argument with a senior engineer in a very large org (50k + endpoints) who claimed that you don't need HTTPS decryption for proper URL filtering..... I'ma ware some vendors let you do certain things by inspecting parameters in the cert but at the end of the day you can't get a the full URL without cracking the HTTPS open... which he just oculd not understand lol
You can do basic URL checking based on DNS or using explicit proxy (the CONNECT is in clear text). That being said it does not add any real security because the stream is still encrypted. So no SSL inspection is just very poor, I agree Wintermute. I knew one company considering offloading incoming HTTPS on another device, sending the unencrypted stream through the ASA and perhaps adding encryption back again after it. I don't know if they went through with it. Nevertheless, it sounds ridiculous.