There are a lot of things to think about around application security. First, what exactly does it mean? Then, can something that one already possesses do the trick? And, what about using an application-layer firewall - is that the same as application security? Logical questions all, and for us old-timers in our easy chairs, easy to answer. But for those who are attacking the problem of keeping applications online and safe, maybe not so.
Application security is, functionally, a lot like a firewall, but a firewall for applications. And, in fact, many of these products call themselves firewalls. I think that I like the firewall analogy because, in many respects, that is exactly what is happening. Users following legitimate paths and doing legitimate things get through; others need not apply.
Now, let's step back a bit and look at what, exactly, we are protecting. When we talk about applications, what do we include? It is easier, perhaps, to ask: What we do not include. The answer: We do not include backend databases. They have special requirements so they are protected by their own security tools and, in the other Group Test this month, we address those tools. Other than databases, just about any application is fair game.
The reality, though, is that most applications are web apps, meaning they are internet-facing. There are exceptions, of course, and I for one would like to see more security architects protect web applications on the organization's intranet, as well as on the internet. Today's web applications are ubiquitous. They also are of many kinds - from standalone to database front-ends. What they all have in common is that they are active, whether they are based on Java, ActiveX or whatever the flavor of the month happens to be.
They also may access resources using a privileged port. That implies that compromising the app means the bad guy can compromise the internals of the network. So, the web interface itself may be vulnerable, and the application(s) sitting behind it may be as well. The solution is to use good design principles and - in the spirit of defense-in-depth - put a barrier between the application, or the path to it, and any interlopers.
How about repurposing something one already has to act as application protection? That is a little like asking, "How long is a piece of string?" It's pretty hard to answer that without some details on the environment. The fact is that unless one has a robust current-generation application security tool, don't try it. Get a new one that is appropriate to the environment and the applications it is protecting.
One final query: Is an application firewall the same as an application-layer firewall? Not usually. In fact, an application firewall more closely resembles unified threat management (UTM). Web applications are targets of hackers, to be sure, but they also are targets of malware. In fact, arguably, they are more likely to be malware targets than anything else. That said, the UTM analogy is the closest to a practical solution to the challenge.
We tested these products this month in a standard firewall test bed. The review was straightforward and concentrated on rule sets, policies, ease of use and management, and the breadth and depth of protection available.
When buying an application firewall, be sure to understand what is needed to protect, both now and in the foreseeable future. If the web applications touch internal resources, configuration is a critical aspect of deployment. Be sure that the product bought is clean to configure and deploy. Rule sets and policies that are misconfigured can spell disaster for internal resources.
Finally, be sure that there are adequate reporting and analysis functions so that admins can not only analyze attack attempts, but meet applicable regulatory requirements. That's all there is to it. It sounds like a lot, but one likely will soon discover that it's just another security tool that demands knowing what is needed, what it is needing protecting, and what the enterprise looks like. We've all been here before.
