As mentioned in the Introduction to Understanding and Selecting an Enterprise Firewall, we see three main forces driving firewall evolution. The first two are pretty straightforward and don’t require a lot of explanation or debate: networks are getting faster and thus the perimeter gateways need to get faster. That’s not brain surgery.

Most end users have also been dealing with significant perimeter security sprawl, meaning where they once had a firewall they now have 4-5 separate devices, and they are looking for integrated capabilities. Depending on performance requirements, organizational separation of duties, and good old fashioned politics, some enterprises are more receptive than others to integrated gateway devices (yes, UTM-like things). Less devices = less complexity = less management angst = happier customers. Again, not brain surgery.

But those really just fall into the category of bigger and faster, not really different. The one aspect of perimeter protection we see truly changing is the need for these devices to become application aware. That means you want policies and rules based on not just port, protocol, source, destination, and time – but also on applications and perhaps even specific activities within an application.

This one concept will drive a total overhaul of the enterprise perimeter. Not today and not tomorrow – regardless of vendor propaganda to the contrary – but certainly over a 5 year period. I can’t remember the source of the quote, but it goes something like “we overestimate progress over a 1-2 year period, but usually significantly underestimate progress over a 10 year period.” We believe that is true for application awareness within our network security devices.

Blind Boxes and Postmen

Back when I was in the email security space, we used a pretty simple metaphor to describe the need for an anti-spam appliance. Think about the security guards in a typical large enterprise. They are sitting in the lobby, looking for things that don’t belong. That’s kind of your firewall. But think about the postman, who shows up every day with a stack of mail. That’s port 25 traffic (SMTP). Well, the firewall says, “Hey Mr. Postman, come right in,” regardless of what is in the mail bin. Most of the time that’s fine, but sometimes a package is ticking and the security guard will miss it.

So the firewall is blind to what happens within port 25. Now replace port 25 with port 80 (or 443), which represents web traffic, and you are in the same boat. Your security guard (firewall) expects that traffic, so it goes right on through. Regardless of what is in the payload. And application developers know that, so it’s much easier to just encapsulate application-specific data and/or protocols within port 80 so they can go through most firewalls. On the other hand, that makes your firewall blind to most of the traffic coming through it. As a bat.

That’s why most folks aren’t so interested in firewall technology any more. It’s basically a traffic cop, telling you where you can go, but not necessarily protecting much of anything. This has driven web application firewalls, web filters, email gateways, and even IDS/IPS devices to sit behind the firewall to actually protect things. Not the most efficient way to do things.

This is also problematic for one of the key fundamentals of network security – Default Deny. That involves rejecting all traffic that is not explicitly allowed. Obviously you can’t block port 80, which is why so many things use port 80 – to get that free ride around default deny policies.

So that’s the background for why application awareness is important. Now let’s get into some tangible use cases to further illuminate the importance of this capability.

Use Case: Visibility

Do you know what’s running on your networks? Yeah, we know that’s a loaded question, but most network/security folks don’t. They may lie about it, and some actually do a decent job of monitoring, but most don’t. They have no idea the CFO is watching stuff he shouldn’t be. They have no idea the junior developer is running a social network off the high-powered workstation under his desk. They also don’t know the head of engineering is sending critical intellectual property to an FTP server outside the country.

Well, they don’t know until it’s too late. So one of the key drivers for application awareness is visibility. We’ve seen this before, haven’t we? Remember how web filters were first positioned? Right, as employee productivity tools – not security devices. It was about making sure employees weren’t violating acceptable use policies. Only afterwards did folks realize how much bad stuff is out there on the web that should be blocked.

In terms of visibility, you want to know not just how much of your outbound traffic is Facebook, or how much of your inbound traffic is from China, or from a business partner. You want to know what Mike Rothman is doing at any given time. And how many folks (and from where) are hitting your key Intranet site through the VPN. The questions are endless once you can actually peek into port 80 and really understand what is happening. And alert on it. Cool, right?

The possibility for serious eye candy is also attractive. We all know senior management likes pie charts. This kind of visibility enables some pretty cool pie charts. You can pinpoint exactly what folks are doing on both ingress and egress connections, and isolate issues that cause performance and security problems. Did I mention that senior management likes pie charts?

Use Case: Blocking

As described above, the firewall doesn’t really block sophisticated attacks nowadays because it’s blind to the protocols comprising the bulk of inbound and outbound traffic. OK, maybe that’s a bit of a harsh overgeneralization, but it certainly doesn’t block what we need it to block. We rely on other devices (WAF, web filter, email security gateway, IPS) to do the blocking. Mostly via a negative security model, meaning you are looking for specific examples of bad behavior (that’s how IPS, web filters, and email gateways work). Obviously that means you need to profile every bad thing that can possibly happen, learn to recognize them, and then look for them in every packet or message that comes in or goes out. Given the infinite possibilities for badness that’s a tall order – actually, completely ridiculous and impossible.

But if we have the ability to look into the traffic and profile applications we can build policies and rules to govern how they applications can be used. We can also block the traffic unless the rules are followed, which represents a positive security model. Now that would be cool. In fact, this kind of capability really enhances one of the network security fundamentals, egress filtering. Being able to both profile and block traffic going out, based on application characteristics, adds a lot of power to disrupt typical exfiltration techniques before you have to disclose to all your pissed-off customers.

So the other main use case for application awareness is to block certain traffic (both ingress and egress) that violates policies. Obviously this opens up a world of possibilities in terms of integration with identity stores. For example, the marketing group can use Facebook during business hours, but the engineering team cannot. You could also enforce specific application activity, such as Finance can enter payroll into the payroll SaaS system, but factory workers can only view pay stubs. You can even enforce privileged user monitoring via this type of capability, monitoring DBA attempts to access the back-end database from remote locations and (possibly) allowing them, but blocking anyone else. The possibilities are endless. In the next post we’ll address the downside of these possibilities.