Welcome to Volume 4, Issue 9 of The Internet Security Conference Newsletter, Insight. Insight provides commentaries and educational columns, authored by some of the best minds in the security community.
TISC is about sharing clue. So is this newsletter. We promise to provide something useful each issue. If we don't, flame me. If you like the issue, let us know!
Enjoy, and be safe,
Dave
Application stream attacks attract more attention today than network-based attacks. Whether this is the result of considerably improved defenses against network-based attacks is a matter of opinion. Maybe itís true. Maybe port 80 based attacks are the not only the low-hanging fruit, but the only-hanging fruit. Security curmudgeons are more likely to conclude that thereís a veritable green field of opportunity for HTTP-based attacks, given the ìapproaches infinityî ratio of web programmers to ìsecurity-awareî programmers.
Whatever the reason, application stream attacks are widespread and costly. In todayís column, Abhishek Chauhan describes some of the issues related to (web) application protection, and describes some of the alternative means of mitigating application attacks, including his own.
Abhishek Chauhan
I remember, about five years ago, I recommended to a Fortune 100 company that they convert their trading application from client-server to a web application, so they wouldnít have to worry about intervening firewalls when rolling it out to the large audience they had in mind. ìWhen you do it as a web application,î I said, ìyour users can access it from anywhere, without running into firewall issues. Ý It is as if the firewall is not there.î
As if the firewall is not there. I reflect upon these words often these days, because as a security practitioner, the immediate question to ask is ñ if the firewall is not there, whatís protecting the web application?
The short answer to this simple question used to be "Nothing! Web applications don't need any protection." That is not the case any more. Today, the web has evolved into the predominant medium for information exchange and the nature of the threat has changed so significantly that an unprotected web application might well be the biggest security vulnerability in your infrastructure. /p>
A more useful question to ask is, ìwhen the firewall acts as if it is not there, how can I get firewall-like protection for my web applications? In this article, I will expand on the notion of firewall-like protection for web applications, and the significance of speed and performance in any solution that attempts to provide such protection.
A solution for application protection that offers firewall-like protection, must behave in the following firewall-like ways. It must:
Now, I might actually also harden some of my servers and install IDS sensors on and around them, but I would be very wary to have malicious traffic hit my application as a matter of routine. While these practices provide a secondary line of defense, without a primary line of defense - a gatekeeper - these don't pass my risk tolerance level.
Surely there are other alternatives for securing a web application. However, none of these alternatives comes close to the level of protection, simplicity, and cost of ownership that a good firewall-like solution can provide today. Let's review these alternatives:
Effective application protection is real-time, always on and acts to block the first intrusion attempt before it can ever reach your web application.
The only reason some of these alternatives even exist is that until recently, real-time application stream analysis and attack rejection have been infeasible or prohibitively expensive to own because of the large demands these solutions place on computing power.
What we require of a real-time application protection solutionis an application-level data path device.
Let me give you an over-simplified analogy. A Cisco router is an IP-level data path device. It understands IP packets, and is specific to the IP protocol. If you wanted to route AppleTalk, you'd probably have to get a different beast. An Alteon load balancer is a TCP-level data path device, it understands TCP sessions, and is specific to the TCP protocol. If you wanted to load balance RTP, you'd probably have to look for a different beast.
You see where I am going. Let us carry the analogy to our application-level data path device. This device understands application requests and responses, and is specific to the application. If you wanted to protect a different application, youíd probably have to look for a different device.
Application protection solutions are closely-coupled to the applications that they protect. This is the proverbial fly in the ointment. Ý While there might be a handful of network protocols and a handful of transport protocols web applications are boundless. Do I have to find a different application protection solution for each one? And who is going to build this solution that works for only one application?
But my analogy taken to the extreme is paradoxical: We want an application-level data path device, that is not application specific?
Several engineering solutions to this paradox do exist. Each solution requires significant processing capacity to overcome the close coupling paradox. What is this coupling anyway? Recall that the desirable security properties of the solution stem from its ability to separate normal traffic from malicious traffic in real-time. It is this discretionary understanding of the application specific traffic, which results in the close coupling.
An application protection scheme can get this discretionary understanding in one or more of the following three ways:
Armed with this, we classify Application Protection Solutions based on the techniques that these solutions employ to identify traffic as normal or malicious.
Declarative solutions have a generic traffic processing engine coupled with a flexible configuration mechanism. Through this mechanism, one can declare enough application specific information, to allow the system to separate normal traffic from malicious.
The advantage of declarative solutions is that there is not much application-level traffic analysis required in real-time. As a result, these solutions have enough speed and performance to be worthy of being deployed in the data path. In fact, one of the fastest commercial real-time application protection solutions takes the declarative approach.
Declarative solutions hide the close-coupling within the configuration task. The configuration is intricate, detailed, and application specific. Consequently, it requires an extensive knowledge of the application being protected. The total cost of ownership of such a solution is prohibitive.
Solutions in this class can work in two ways.
Interpretive solutions have an interpretive traffic processing engine. Ý These solutions are capable of gathering semantic information from the traffic that flows through them, and interpreting the policy for normal application behavior from the gathered information, in real-time.
We believe here are many advantages to an interpretive solution. Ý Most of the work happens in real-time. Configuration requirements are fewer than declarative solutions. Ý Further, since the policy is constructed in real-time, we believe it tends to be more accurate, and can be more finely-grained than policies applied or derived using other solutions. Certain solutions in this class are capable of implementing a per-user security policy. i.e. different users of the same application can be treated differently in these systems, because all decision criteria are derived from a real-time analysis of the usersí actions. Ý These tend to be robust against small changes to the application because they do not depend on an a priori knowledge of the application and infer their policy in real-time.
To get away from the close coupling, these solutions devote an enormous amount of processing power in interpreting application behavior in real-time. Ý As a result, a straightforward implementation of these ideas can be unacceptably slow, and not worthy of your data path unless you have a lightly trafficked application. Ý After all, the device wonít be much of a gatekeeper, if you need one such device for every web server you wish to protect.
Interpretive solutions must parse the application traffic stream and break it out into its semantic components. Ý The performance-limiting factor for interpretive solutions is the HTML parsing engine. Any speeding of this process will directly reflect in the overall performance of an interpretive solution. We believe that recent advances in interpretive systems have made it possible to achieve simplicity of configuration and deployment without sacrificing speed or performance.
Web applications have become one of the largest vulnerabilities today. Ý Some application protection solutions promise to provide firewall-like protection for web applications. Ý To date, the adoption of application protection solutions are limited because you commonly must make a tradeoff between speed in the data path, and total cost of ownership. Ý However, recent application protection solutions have trimmed this tradeoff curve with a combination of interpretive stream analysis and automated configuration techniques. Ý
My colleagues and I have developed a solution with speed and performance as major considerations from the outset. Our solution is deployed in the data path and filters all traffic between web browsers and the web server. Ý It blocks all HTTP packets that do not conform to the constantly-evolving definition of what normal traffic looks like, before threats even get to the web server. We have constructed an interpretive engine that identifies normal traffic on a web server and then suggests rules which will allow only this acceptable traffic to pass through to the APS. This engine uses a combination of several W3C standards and web application design best practices as a basis upon which it builds a set of application specific deviations. Ý The learning engine is self-configuring, allowing for quick deployment and minimum customization over the life of the product.
To yield the speed and performance we believed was essential for a product of this nature, we constructed what we think is an innovative HTTP packet filtering engine. Our design objective was to reduce transaction latency to less than five milliseconds, which we believe is acceptable for any e-commerce application. This range of performance should give companies the ability to deploy a real-time protection device in the data path to filter all malicious web attacks before they reach a web server.
Only real world deployment will prove whether interpretive application protection technology is innovative, viable and scalable. We are optimistic Ý this solution will ultimately do for your web applications what the network firewall couldnít ñ provide real-time application protection.
© 2002 - 2006 Core Competence & Mactivity, Inc.