During Cisco Live 2017, Cisco made promises of significant changes to its security portfolio, including many feature enhancements for its next generation firewall (NGFW) platform, Firepower Threat Defense (FTD).
These new features will be released first, in unison with the new 2100 series FTD appliances, which will be the first platform to run the 6.2.1 code. Soon after, 6.2.2 code will be released for all models, unifying the feature set across all FTD hardware platforms.
While most of these enhancements will be check-box enabled via the GUI, some of them are so nascent, they will have to be enabled via FlexConfig, which is Cisco’s special enablement system for features not yet built into the GUI. The FTD product line has been languishing in the desert of half-hearted functionality for quite some time now. And for those of us long comfortable with the stability and consistency of the classic ASA architecture, the idea of migrating to the Cisco NGFW platform just has not been, well, exciting — until now.
Here are my top 10 reasons why I’m (finally) excited about Cisco’s NGFW platform, Firepower Threat Defense.
-
Multi-context functionality
This feature is huge. Multi-context is not only a must-have for multi-tenancy, it is a commonplace virtualization strategy in the enterprise core and data center to limit the security failure domain between business organizations. Proven business applications for multi-context functionality on ASA classic are numerous and have been successfully executed on Cisco’s entire product line (those supporting the feature). Lacking multi-context has given cause for many organizations to hold back on upgrading to FTD; this addition will be very well received!
-
Improved SIEM integration (true Splunk integration)
Previously, FTD’s SIEM integration has been limited to whatever functionality could be implemented by third parties, using the e-streamer API. Like most custom solutions, the quality of results varied. However, Cisco is now releasing its own SIEM integration functionality and tools, which will guarantee a higher quality experience with leading SIEM products, such as Splunk. Very nice!
-
Local console and web GUI management alternatives to centralized FMC
When assessing a next-generation product, you inevitably begin by comparing it to the previous generation’s product — assuming it’s still apples to apples. Personally, I was dumbfounded when I heard that FTD would not have a fully functional local CLI, and the only way you could configure FTD was through a GUI running on centralized management device, called the Firepower Management Console (FMC). As a career Cisco engineer, I lived on the ASA CLI for all things, except configuring RA VPNs and re-ordering ACLs. To no longer have CLI functionality and to now be required to go through another appliance for device configuration was a significant mental hurdle for me. Thankfully, this will no longer be the case. Cisco has developed a classic ASA-like CLI for the FTD appliance, in addition to a free-standing web GUI for the box, called Firepower device management (FDM).
Now, there is a catch: You cannot run both stand-alone and centralized GUI access, so you will have to decide between them. Cisco recommends deploying FMC for centralized management, which makes sense. But personally, I wouldn’t get hung up on the specific path for HTTP management; as long as there is a solid CLI to fall back on, we’ll be golden.
-
IPv6 prefix delegation (via FlexConfig)
Items 4, 5 , 6, and 7 are all related in my opinion, because they represent an investment by Cisco to make the FTD platform equally viable as both an internet edge UTM solution and enterprise class NGFW. IPv6 PD (prefix delegation) is essentially DHCPv6 but for public IPv6 ranges rather than host addresses — it allows a global prefix (unique IPv6 public address range) to be dynamically assigned to the customer device, from a service provider (mostly likely). IPv6 PD enhances FTD’s IPv6 feature compatibility and is a nice-to-have for those ready to wade into IPv6 waters.
-
EIGRP, IS-IS, BGP-BFD and PBR (via FlexConfig)
I realize that FTD was born from the Sourcefire acquisition, and I also realize that several other Cisco product lines still don’t support EIGRP (I won’t mention names … but they rhyme with Peraki). However, I think we can agree that supporting EIGRP is about as Cisco as is it gets! Since the early days of deploying ASAs, organizations have taken advantage of the speed, flexibility, and convenience of running EIGRP from distribution switch all the way to internet edge, and we would expect that same option on newer platforms. EIGRP on Cisco’s NGFW is a must! And I’m excited we will finally be getting it.
Bi-directional forwarding detection (BGP-BFD) and policy-based routing (PBR) are two additional nice-to-have features if FTD is going to be deployed at a real-world internet edge. BFD allows for extremely efficient neighbor/link-down detection, dramatically reducing re-convergence for IGPs and BGP. PBR allows for very granular routing control, and creating exceptions to how the routing table would naturally route traffic. PBR can really come in handy when you are multi-homed to the internet or WAN. It is also a valuable network design tool when organizations demand separate northbound/southbound paths depending on the end host or traffic flow.
Oh, and in addition to the features listed above, customers will now also be able to make all their wildest dreams come true by running IS-IS with their FTD appliance.
-
ALG inspection engine (via FlexConfig)
Application layer gateway (ALG) is a security feature that allows devices to perform layer 7 inspection by acting as liaison, or proxy, for that protocol to the internet. ALG is essentially the same concept as SSL inspection, a purposeful man-in-the-middle. The intended use is for protocols such as SIP and FTP, which can sometimes require substantial port-ranges to be open on the firewall to work correctly, due to dynamic port selection. SIP providers or FTP servers on the internet establish a connection with the firewall, and the firewall creates a connection to the voice gateway or internal server. This allows the firewall to perform layer 7 inspection of the traffic and prevent any funny business from going one. This is a common feature on other vendor NGFW platforms, and will be a welcome addition to FTD.
-
NGFW QoS
The term NGFW is used generously, and in a multitude of contexts. A simple fly-by definition: NGFW refers to a device’s ability to identify the application, regardless of the port being used, and to identify the user/consumer of the traffic, rather than simply identifying an IP address. So, for example, if the NGFW is permitting HTTP web traffic, it will permit TCP:80 as well as TCP:8080 (as long as the traffic is genuine web browser traffic). In addition, if the NGFW is permitting HTTP web traffic (and identity sources are configured such as Microsoft Active Directory), the NGFW will also know whether John Smith is the consumer of the HTTP traffic, or if it is Jane Doe.
NGFW quality of service (QoS) takes the above concepts a step further. It can now permit genuine web traffic on any port, based on specific active directory users (or groups, more likely), and in addition, it can rate-limit their traffic to prevent the sales team from using the entire internet pipe for Netflix. Nice!
-
VxLAN integration (via FlexConfig)
There weren’t many specifics mentioned on this item, so I don’t know where exactly FTD will fit into the VxLAN ecosphere. Will it be capable of being an additional spine on the network? Or maybe an additional leaf node, where ACI contracts will be enforced? Or maybe FTDv (the virtual FTD instance) will have automation and programmability features built in for VMware + ACI scenarios? I’m not sure, but what I know is that Cisco is thinking ahead and developing a plan to closely knit and future-proof its product line.
-
Significant user experience (UX) upgrade
While less straightforward to quantify, this bullet is no less exciting. Anyone who has dealt with the legacy ASDM interface knows how reluctant Cisco has been to give products a visual facelift. Just hearing that Cisco is concerned with quality of users’ GUI experience is exciting to me. A few specific items called out at CL2017 were continued visual improvements to the web interface, advanced options for user interface customizations (to expedite repetitive tasks), a more feature-rich and functional REST API interface, and the ability to more easily build reports straight from customized dashboard widgets. To me, specific interface feature improvements we’re not as exciting as just hearing from product engineers that Cisco has a strong commitment to improving users’ visual experience while using their firewall, and not just the firewall features themselves.
-
Evolution of philosophy
I have been working with Cisco network security since the days of PIX. Cisco has given us powerful, stable, and efficient network security devices via the ASA product line for many years. Cisco has achieved so much success in the firewall market that it’s difficult to find an organization that isn’t running an ASA somewhere in its network — or hasn’t at one point. But the long-standing success Cisco had with its firewall line lead to some complacency. As the firewall landscape began to evolve, expectation for the baseline functionality of firewalls also changed. Firewalls could no longer just be VPN termination devices, routers, IDS/IPS, and layer 4 security filters — they had to be “next-generation.” In the course of this evolution, Cisco firewalls fell behind. But rather than give up or sell off the product line, Cisco doubled-down and recommitted. Cisco’s security philosophy has evolved, and continues to evolve, and it is showing in the FTD product line.
FTD is not the NGFW we want it to be yet, but it’s coming. Through committed focus in new areas (APIs, UX, cloud-based management and security products), continued strategic acquisitions (CloudLock, OpenDNS, SourceFire), and investment in future-proofing its product line, Cisco will do what it always does — deliver.
(Information sampled and taken from BRKSEC-2058, BRKSEC-2013, BRKSEC-2050 — search Cisco Live for these presentations and more information)