John Melton's Weblog
Java, Security and Technology

Year Of Security for Java – Week 18 – Perform Application Layer Intrusion Detection

Print this article

No Gravatar

What is it and why should I care?
Application layer intrusion detection is a simple concept that I believe is very, very powerful when it comes to protecting applications. Most of the topics I’ve covered thus far have focused on the development portion of the software life-cycle, but this topic really covers the entire span of an application, from the requirements and planning to sun-setting.

The basic concept is that you plan for, implement and monitor “bad” things that occur in your application. With this type of system in place, you look for events that appear to be undesirable in some way and then keep track of them. Over time, you can make decisions about whether those individual events turn into an actual attack.

Many developers actually do most of the work of detection already. Consider the following pseudo-code:

if (user has access to record) {
    get data 
    redirect to view/edit page
} else {
    log exception
    send user error message
}

I’ve seen code just like this lots of times. The problem here is the handling exceptional condition. In general, people don’t review logs, so if there’s an attacker trying to break your application, the only person seeing the error you’ve caught is the _attacker_. With one quick addition of sending a message to your intrusion detection engine, you can start tracking these events and actually gaining knowledge into the real-time (and historical if you choose to store it) usage of your application. After you’ve detected an actual intrusion, you also have the ability to respond to the activity in any [legal] way you see fit. Popular options include ideas like: increased logging, manipulating user account (logout, disable), or even blocking access to certain functionality.

What should I do about it?
Let’s assume I’ve sold you on the idea of implementing something like this (hopefully I have). What now?

Well, you have a few options on how to proceed that I’m aware of: ESAPI, AppSensor or roll-your-own.

ESAPI does have an intrusion detection engine built-in that performs some of these ideas. It is admittedly not extensive, but the core is there and can certainly be extended.

AppSensor is one such extension of the ESAPI intrusion detection engine. The implementation is more extensive than what’s available for ESAPI. Additionally, the project offers a book about the overall idea, as well as significant documentation in addition to the code. Lastly, there is actually a significant update being worked on currently on the project to update both the documentation and the code.

Rolling your own analysis engine can be a small or very large project depending on your needs. Nevertheless, you can certainly take the ideas and implement them in your applications and get significant benefit.

By just adding a little bit of effort, you can gain significant insight into the overall security health of your application(s). You can see who attacked/is attacking your application in real-time or the past, and you can actually respond to events as they occur. Who wouldn’t like that?

Author note: I work on the AppSensor project, so this whole topic is near and dear to me. Please take advantage of the idea whether it’s in our implementation or not!

References
———–
https://www.owasp.org/index.php/ApplicationLayerIntrustionDetection
http://www.jtmelton.com/2010/11/10/application-intrusion-detection-with-owasp-appsensor/
http://www.owasp.org/index.php/OWASP_AppSensor_Project
http://www.owasp.org/
http://www.youtube.com/watch?v=6gxg_t2ybcE
http://www.clerkendweller.com/2010/11/12/Application-Intrusion-Detection-and-Response-Planning-Methodology
https://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API

Be Sociable, Share!

Technorati Tags: , , ,

Comments