Firewall technology has evolved significantly since the days of basic packet filters and network address translation. We now have not just firewalls but “intrusion detection devices”, which do far more complex things to the traffic they see in an attempt to prevent the network from being attacked. So where are firewalls going?

The main problem with today’s firewall technology is that it’s doing so much work that as the capacity of the average Internet connection grows, the firewall becomes a bottleneck. This is hardly surprising. Many of today’s firewalls don’t just filter packets but also do clever stuff like checking whether incoming Java applets contain dangerous code, or decoding email messages and passing their attachments to an AV package for analysis.

The other problem with doing loads of different functions within a single firewall is that no one product will manage to be the "best of breed". Generally, you find that a multi-function device does all things averagely, instead of doing any one function brilliantly. This is addressed by some firewall manufacturers, who instead of doing advanced work such as AV protection internally, pass the task to an external system running a mainstream application with a reputation for excellence in its field. Strangely, though, the current penchant for bundling firewalls as all-in-one "appliances" goes against this idea, and security can only suffer as a consequence.

Sharing the load

So how do we address these issues of bottlenecking and fitness for purpose? It seems to us that the obvious way is to move away from having a firewall device, toward having an "edge network" of smaller devices. Each of these would perform their own particular function under the supervision of a "master" device, possibly the firewall itself, but not necessarily relying on the firewall for intercommunication. Transmissions have to negotiate their way through all relevant components of this "edge network" before being allowed into the corporate network.

Imagine an email arrives in the network. The firewall checks that it’s destined for the right server, on the right port, and verifies that it’s passed the basic entry criteria. It then passes it on to an email decoder for the attachments to be extracted. The email decoder knows that before it can do anything with the message, it needs to examine the attachments for viruses, so it unbundles them and passes them to an AV package. The AV package verifies that the files are clean, and notifies this fact to the email decoder, which knows it can now pass the original message on to the email server for delivery. For each type of incoming and outgoing traffic, a similar type of workflow arrangement is implemented, with each device in the network knowing (a) how to do its own job and (b) what to do with the results should the test it’s performing pass or fail.

Learn from ERP

This kind of workflow implementation is commonplace in corporate ERP systems. Since network protection is no longer a basic filtering exercise but a vast pile of intricate logic with some nasty, nondeterministic heuristics thrown in for good measure, it’s not unreasonable to think that ERP-style workflow management might be a useful addition. Because there’s a large amount of processing to be done to analyse the traffic, it’s also sensible to think that there would be several separate machines sharing the load and passing messages between each other. Some machines would be dedicated to one task (e.g. AV processing) while others could handle two or three lesser tasks.

Taking the concept to extremes, one can imagine the "edge network" as comprising a collection of general-purpose machines that simply do the jobs they’re asked to do by a central scheduler. So far, we’ve mentioned the concept of having (say) an AV machine that does AV processing on request, and an email decoder for extracting attachments, with the data that needs processing being passed in by external devices. Imagine for a moment that we simply have a cluster of general purpose machines, with no specific purpose. Instead of passing data in for processing, the external device passes in both the data and the code it wants to run on the data. So one minute a machine is receiving a message that says: "Here’s some data to check for viruses and here’s the code you need to use to do the check" and the next it’s hearing: "Please decode these emails and pull out the attachments - here’s a lump of code you can use to do it".

Barking mad?

This idea might appear crazy but bear one important thing in mind: it’s what IBM (and others) want to do to the entire enterprise. For instance, instead of having a payroll machine that’s idle for all but one day per month why not simply share the payroll processing task among the various computers in the enterprise by sending a load of them some code to run and some data to process with it?

The vision of the Grid Computing community is that the enterprise computing platform - probably a heterogeneous mix of everything from PDAs to minicomputers, perhaps even mainframes - should become a single, virtual computer that controls its own scheduling. You drop work onto the virtual machine, it goes away and figures out which bits are available to service the job most effectively in the available time and, when it’s finished, out pops the answer.

Now consider that the traffic flowing in and out of an Internet connection is varied in its content, and different types of traffic require different amounts of analytical processing. It’s not hard to see a correlation with this "virtual computer" type of approach. Obviously you don’t want to be passing potentially virus-laden data to random machines inside your enterprise (which is why you have a "closed" edge network), but the concepts fit and it may well solve the problem.

In short

Firewalls are bottlenecks, Internet connections are getting faster, and the techniques for detecting potential issues are getting more complicated. More and more processing power is required just to stand still and the technologies already exist to do all this stuff. So it may just be the way forward, for large enterprise security systems at least.