In the first part of our series on Understanding and Selecting an Enterprise Firewall, we talked mostly about use cases and new requirements (Introduction, Application Awareness Part 1, and Part 2) driving a fundamental re-architecting of the perimeter gateway.

Now we need to dig into the technical goodies that enable this enhanced functionality and that’s what the next two posts are about. We aren’t going to rehash the history of the firewall – that’s what Wikipedia is for. Suffice it to say the firewall started with application proxies, which led to stateful inspection, which was supplemented with deep packet inspection. Now every vendor has a different way of talking about their ability to look into packet streams moving through the gateway, but fundamentally they’re not all that different.

Our main contention is that application awareness (building policies and rules based on how users interact with applications) isn’t something that fits well into the existing firewall architecture. Why? Basically, the current technology (stateful + deep packet inspection) is still focused on ports and protocols. Yes, there are some things (like bolting an IPS onto the firewall) that can provide some rudimentary application support, but ultimately we believe the existing firewall architecture is on its last legs.

Packet Processing Evolves

So what is the difference between what we see now and what we need? Basically it’s about the number of steps to enforce an application-oriented rule. Current technology can identify the application, but then needs to map it to the existing hierarchy of ports/protocols. Although this all happens behind the scenes, doing all this mapping in real time at gigabit speeds is very resource intensive. Clearly it’s possible to throw hardware at the problem, and at lower speeds that’s fine. But it’s not going to work forever.

The long term answer is a brain transplant for the firewall, and we are seeing numerous companies adopting a new architecture based not on ports/protocols, but on specific applications and identities. So once the application is identified, rules can be applied directly to the application or to the user/group for that application. State is now managed for the specific application (or user/group). No mapping, no performance hit.

Again, at lower speeds it’ll be hard to decipher which architecture a specific vendor is using, but turn on a bunch of application rules and crank up the bandwidth, and old architectures will come grinding to a stop. And the only way to figure it out for your specific traffic is to actually test it, but that’s getting a bit ahead of ourselves. We’ll talk about that at the end of the series when we discuss procurement.

Application Profiles

For a long time, security research was the purview of the anti-virus vendors, vulnerability management folks, and the IDS/IPS guys. They had to worry about these “signatures,” which were basically profiles of bad things. Their devices enforce policies by looking for bad stuff: a typical negative security model.

This new firewall architecture allows rules to be set up to look only for the good applications, and to block everything else. A positive security model makes a lot more sense strategically. We cannot continue looking for, identifying, and enumerating bad stuff because there is an infinite amount of it, but the number of good things that are specifically authorized is much more manageable. We should mention this does overlap a bit with typical IPS behavior (in terms of blocking stuff that isn’t good), and clearly there will be increasing rationalization of these functions on the perimeter gateway.

In order to make this architecture work, the application profiles (how you recognize application one vs. application two) must be correct. If you thought bad IPS rules wreak havoc (false positives, blocked traffic, & general chaos), wait until you implement a screwy firewall application profile. So as we have mentioned numerous times in the Network Security Operations Quant series on Managing Firewalls, testing these profiles and rules multiple times before deploying is critical.

It also means firewall vendors need to make a significant and ongoing investment in application research, because many of these applications will be deliberately difficult to identify. With a variety of port hopping and obfuscation techniques being used even by the good guys (to enhance performance mostly, but also to work through firewalls), digging deeply into a vendor’s application research capabilities will be a big part of choosing between these devices.

We also expect open interfaces from the vendors to allow enterprise customers to build their own application profiles. As much as we’d like to think all of our applications are all web-friendly and stuff, not so much. So in order to truly support all applications, customers will need to be able to build and test their own profiles.

Identity Integration

Take everything we just said about applications and apply it to identity. Just as we need to be able to identify applications and apply certain rules to those application behaviors, we need to apply those rules to specific users and groups as well. That means integration with the dominant identity stores (Active Directory, LDAP, RADIUS, etc.) becomes very important.

Do you really need real-time identity sync? Probably not. Obviously if your organization has lots of moves/adds/changes and those activities need to impact real-time access control, then the sync window should be minutes rather than hours. But for most organizations, a couple hours should suffice. Just keep in mind that syncing with the firewall is likely not the bottleneck in your identity management process. Most organizations have a significant lag (a day, if not multiple days) between when a personnel change happens and when it filters through to the directories and other application access control technologies.

Management Evolution

As we described in the Application Awareness posts, thinking in terms of applications and users – rather than ports and protocols – can add significantly to the complexity of setting up and maintaining the rule base. So enterprise firewalls leveraging this new architecture need to bring forward enhanced management capabilities. Cool application awareness features are useless if you cannot configure them. That means built-in policy checking/testing capabilities, better audit and reporting, and preferably a means to check which rules are useful based on real traffic, not a simulation.

A cottage industry has emerged to provide enterprise firewall management, mostly in auditing and providing a workflow for configuration changes. But let’s be clear: if the firewall vendors didn’t suck at management, there would be no market for these tools. So a key aspect of looking at these updated firewalls is to make sure the management capabilities will make things easier for you, not harder.

In the next post, we’ll talk about some more nuances of this new architecture – such as scaling, hardware vs. software considerations, and embedding firewall capabilities into other devices.