Friday, May 21, 2010
Application Layer Intrusion Detection
The conversations around intrusion detection have traditionally occured within the world of network. I fundamentally believe that the conversation needs to move higher up the stack and be incorporated into enterprise applications.
I am a big fan of Static Analysis and other application security methods, but this doesn't cover all security challenges. The conversation needs to include the need to implement robust attack detection within the application to identify malicious users before they are successful in their attack. Just like in the real world, we would prefer to detect and prevent an attack instead of just responding after a compromise has occurred.
In order to detect and respond to malicious activity at the application layer we need to be able to monitor and understand a user’s actions within the application. This cannot be accomplished by either firewall or SSL as they provide no protection in this regard. A network-based intrusion detection platfor also will have no insight to our application specific traffic. Antivirus is also out of the question since this is a signature based approach that knows nothing of custom web application vulnerabilities.
Some may think that a web application firewall is a potential solution. A WAF is able to detect generic application attacks such as basic SQL injection attacks or common actions of a known attack sequence. While some detection is better than none, a generic product could never fully understand the intricacies of each custom web application.
Detection and response needs to be incorporated into the application itself. Ideally, it would be great if frameworks such as Spring, Struts, Ruby on Rails or other web application frameworks incorporated this, but this is missing in action. Within the application, there is unambigious visibility into the user initiating an action, the target of that action and whether that action should be allowed for that user.
The application is best positioned to identify attempts to circumvent security controls or use the application in an unintended manner. After we have determined that a particular user has malicious intent and is attempting to identify weaknesses, the application can respond and block the user from future access to the application, or take whatever other action is appropriate.
The rigor of response is a decision for each organization in relation to their tolerance for risk and specific needs for an application. However, it is clear that this level of detection capability is a must for any organization wishing to prevent skilled and persistent attackers from compromising their critical applications.
We of course must acknowledge that we don't just build applications but also buy them. The enterprise priority should include asking your strategic vendors to incorporate this as a requirement for future releases. Sadly, many security-oriented product offerings lack this type of capability. Ideal targets for such a deployment include federated identity platforms, identity provisioning and entitlements management products. In turn, product vendors should figure out how to include this type of scenario within conversations at security conferences and standards bodies. Events such as BlackHat, DefCon, Gartner Enterprise Security, Kantara and others come to mind.
Anyway, the OWASP community has been thinking on this challenge and I encourage people reading this blog to consider at least noodling what are the appropriate detection points. This conversation is equally relevant to the identity community as it is to the security community as it is to the privacy community as it is to the community who cares about uptime. Let's get the conversation started...
| | View blog reactionsI am a big fan of Static Analysis and other application security methods, but this doesn't cover all security challenges. The conversation needs to include the need to implement robust attack detection within the application to identify malicious users before they are successful in their attack. Just like in the real world, we would prefer to detect and prevent an attack instead of just responding after a compromise has occurred.
In order to detect and respond to malicious activity at the application layer we need to be able to monitor and understand a user’s actions within the application. This cannot be accomplished by either firewall or SSL as they provide no protection in this regard. A network-based intrusion detection platfor also will have no insight to our application specific traffic. Antivirus is also out of the question since this is a signature based approach that knows nothing of custom web application vulnerabilities.
Some may think that a web application firewall is a potential solution. A WAF is able to detect generic application attacks such as basic SQL injection attacks or common actions of a known attack sequence. While some detection is better than none, a generic product could never fully understand the intricacies of each custom web application.
Detection and response needs to be incorporated into the application itself. Ideally, it would be great if frameworks such as Spring, Struts, Ruby on Rails or other web application frameworks incorporated this, but this is missing in action. Within the application, there is unambigious visibility into the user initiating an action, the target of that action and whether that action should be allowed for that user.
The application is best positioned to identify attempts to circumvent security controls or use the application in an unintended manner. After we have determined that a particular user has malicious intent and is attempting to identify weaknesses, the application can respond and block the user from future access to the application, or take whatever other action is appropriate.
The rigor of response is a decision for each organization in relation to their tolerance for risk and specific needs for an application. However, it is clear that this level of detection capability is a must for any organization wishing to prevent skilled and persistent attackers from compromising their critical applications.
We of course must acknowledge that we don't just build applications but also buy them. The enterprise priority should include asking your strategic vendors to incorporate this as a requirement for future releases. Sadly, many security-oriented product offerings lack this type of capability. Ideal targets for such a deployment include federated identity platforms, identity provisioning and entitlements management products. In turn, product vendors should figure out how to include this type of scenario within conversations at security conferences and standards bodies. Events such as BlackHat, DefCon, Gartner Enterprise Security, Kantara and others come to mind.
Anyway, the OWASP community has been thinking on this challenge and I encourage people reading this blog to consider at least noodling what are the appropriate detection points. This conversation is equally relevant to the identity community as it is to the security community as it is to the privacy community as it is to the community who cares about uptime. Let's get the conversation started...
