In our last post on application awareness as a key driver for firewall evolution, we talked about the need and use cases for advanced firewall technologies. Now let’s talk a bit about some of the challenges and overlap of this kind of technology. Whether you want to call it disruptive or innovative or something else, introducing new capabilities on existing gear tends to have a ripple effect on everything else. Application awareness on the firewall is no exception.
So let’s run through the other security devices usually present on your perimeter and get a feel for whether these newfangled firewalls can replace and supplant, or just supplement, these other devices. Clearly you want to simplify the perimeter where you can, and part of that is reducing the device footprint.
- IDS/IPS: Are application aware firewalls a threat to IDS/IPS? In a nutshell, yes. In fact, as we’ll see when we examine technical architectures, a lot of the application aware firewalls actually use an IPS engine under the covers to provide application support. In the short term, the granularity and maturity of IPS rules mean you probably aren’t turning IPSes off, yet. But over time, the ability to profile applications and enforce a positive security model definitely will impinge on what a traditional IDS/IPS brings to the table.
- Web application firewall (WAF): Clearly being able to detect malformed web requests and other simple attacks is possible on an application aware firewall. But providing complete granular web application defenses, such as automated profiling of web application traffic and specific application calls (as a WAF does) are not as easily duplicated via the vendor-delivered application libraries/profiles, so we still see a role for the WAF to protect inbound traffic directed at critical web apps. But over time it looks pretty certain that these granular capabilities will show up in application aware firewalls.
- Secure Email Gateway: Most email security architectures today involve a two-stage process of getting rid of the spammiest email using reputation and connection blocking, before doing in-depth filtering and analysis of message content. We clearly see a role for the application aware firewall to provide reputation and connection blocking for inbound email traffic, but believe it will be hard to duplicate the kind content of analysis present on email security gateways. That said, end users increasingly turn to service providers for anti-spam capabilities, so over time this feature is decreasing in importance for the perimeter gateway.
- Web Filters: In terms of capabilities, there is a tremendous amount of overlap between the application aware firewall and web filtering gateways. Obviously web filters have gone well beyond simple URL filtering, which is already implemented on pretty much all firewalls. But some of the advanced heuristics and visibility aspects of the web security gateways are not particularly novel, so we expect significant consolidation of these devices into the application aware firewall over the next 18 months or so.
Ultimately the role of the firewall in the short and intermediate term is going to be as the coarse filter sitting in front of many of these specialized devices. Over time, as customers get more comfortable with the overlap (and realize they may not need all the capabilities on the specialized boxes), we’ll start to see significant cannibalization on the perimeter. That said, most of the vendors moving towards application aware firewalls already have many of these devices in their product lines. So it’s likely about neutral to the vendor whether IPS capabilities are implemented on the perimeter gateway or a device sitting behind the gateway.
Complexity is not your friend
Yes, these new devices add a lot of flexibility and capabilities in terms of how you protect your perimeter devices. But with that flexibility comes potentially significant complexity. With your current rule base probably numbering in the thousands of rules, think about how many more you’d need to set up rules to control specific applications. And then to control how specific groups use specific applications. Right, it’s mind numbing. And you’ll also have to revisit these policies far more frequently, since apps are always changing and thus enforcing acceptable behavior may also need to change.
Don’t forget the issues around keeping application support up to date, either. It’s a monumental task for the vendor to constantly profile important applications, understand how they work, and be able to detect the traffic as it passes through the gateway. This kind of endeavor never ends because the applications are always changing. There are new applications being implemented and existing apps change under the covers – which impacts protocols and interactions. So one of the key considerations in choosing an application aware firewall is comfort with the vendor’s ability to stay on top of the latest application trends.
The last thing you want is to either lose visibility or not be able to enforce policies because Twitter changed their authentication process (which they recently did). It kinds of defeats the purpose of having an application aware firewall in the first place.
All this potential complexity means application blocking technology still isn’t simple enough to use for widespread deployment. But it doesn’t mean you shouldn’t be playing with these devices or thinking about how leveraging application visibility and blocking can bolster existing defenses for well known applications. It’s really more about figuring out how to gracefully introduce the technology without totally screwing up the existing security posture. We’ll talk a lot more about that when we get to deployment considerations.
Next we’ll talk about the underlying technology driving the enterprise firewall. And most importantly, how it’s changing to enable increased speed, integration, and application awareness. To say these devices are receiving brain transplants probably isn’t too much of an exaggeration.
Comments