SimpleIDS

I’ve posted a Windows Powershell script on my web site today that checks directories for file additions, deletions and changes. Its intended purpose is to act as a simple audit tool to detect unauthorised content change. It’s called SimpleIDS and can be downloaded here.

Although I think that intrusion detection systems (IDS) are a necessary part of any web application infrastructure, many of the commercial tools out there are expensive and in my opinion often do not give value for money. There are some excellent free systems out there such as Snort but even these can require a significant investment in man hours. If you are unsure of how cost effective a particular IDS control or system is, a quick way to assess its value is to consider the Annual Loss Expectancy (ALE). Subtract the ALE after a control is implemented from the ALE before the control and then compare the result to the cost of the IDS. If the ALE reduction is less than the IDS cost then it’s probably not worth having.

My approach to IDS has always been to keep it as simple as possible. Where feasible, it’s a good idea to build it directly into your application, something I’ll blog about later on. SimpleIDS is also a good example. If performs a single function, to detect content change, and so is easy to understand. It is a script and so doesn’t require any installation of software.

SimpleIDS is rather primitive at the moment and I intend to evolve it over the coming months with more command line options and an alerting function as the priorities. Feedback would be appreciated.

IDS and HTTP decoding

I’ve recently been doing some work on intrusion detection systems (IDS). As anyone who has ever discussed the subject with me will know, I am somewhat sceptical about the value they add to protecting an application, particularly when HTTP is involved. Part of the reason for the sceptism is the complexity of many of the tasks an IDS needs to carry out. Take for example decoding a URL. It’s claimed in a paper by Daniel Roelker at IDSResearch.org that there are over 8 different types of encoding possible for HTTP despite only two being defined in the relevant RFCs. An IDS needs to be able to understand each of these methods before it can hope to identify a malicious request. The task is complicated further by different products supporting different methods, with IIS perhaps being the worst offender. Whether such deviance from the standards is due to irresponsible software manufacturers or due to limitations or ambiguities in the standards, it is hard to tell. Note IIS7 now seems to disable many of the encoding techniques although they can easily be reactivated. IDS Research also has some useful tools for testing which encoding methods are supported by your web server and to allow you to see if your IDS can pick up the various types of encoding. It’s well worth testing your systems. You might be surprised what shows up.