« Lua Programming Gems PDF now available from Feisty Duck | Main | Apache Security 1ed now available from Feisty Duck »

The state of ModSecurity in March 2010 (Part 2)

April 13, 2010

By now you should have a good understanding of where ModSecurity has been. (If you don't, you should read part 1 of my analysis of the state of ModSecurity.) I will now focus on where ModSecurity is, and where it can go.

The key issue to consider is that of motivation. A major loss for ModSecurity is the fact that the interests of its owner, Breach Security, are not aligned with the interests of ModSecurity itself. (Disclaimer: I left left Breach Security more than a year ago; my judgement is based entirely on the publicly available information, and I may be wrong. Feel free to correct me.) Despite the misalignment, Breach Security continues to spend significant resources on ModSecurity. Brian Rectanus and Ryan Barnett continue to spend their time improving ModSecurity and Core Rules and support the community.

Let's look at the individual components:

  • ModSecurity. ModSecurity is developed by Brian Rectanus and myself. Brian, employed by Breach Security, does most of the work. I contribute only from time to time, mostly when I have an itch to scratch.

    The last major version of ModSecurity, 2.5, was released in February 2008, more than two years ago. At present there is no sign of work on the version 3.0. The good news is that ModSecurity is very well maintained. The current version is 2.5.12 (and there's 2.5.13 in the trunk), which means that there's been a new version released every 2 months. That's very good. The analysis of the CHANGES file shows that some of the versions have had substantial improvements, especially the most recent ones. In addition, from personal experience I can tell you that the work done on ModSecurity (by Brian Rectanus) is more extensive than the CHANGES file make it appear. ModSecurity is under active development, even if there's currently no sign of any major improvements.

  • Rules. The second generation of ModSecurity Core Rules was released in mid-2009 as a project of OWASP. Ryan Barnett, who works for Breach Security, leads the Core Rules project. The Core Rules is a substantial project, and it's very encouraging to see it move forward. One of the biggest weaknesses of ModSecurity is the lack of an easy to use rule set.
  • Management (GUI). On the management front, things have been quite boring for very long. ModSecurity Community Console, first released in 2006, remains free for up to three sensors. With a bit of tweaking, the console can handle thousands of alerts and it provides adequate monitoring facilities, but there's no management. There's a promising new development from Christian Bockermann: his AuditConsole implements similar functionality to that of ModSecurity Community Console, but has no sensor limits.
  • Documentation. Now that my own ModSecurity Handbook has been released, I can, for the first time ever, honestly say that ModSecurity has adequate documentation. My book documents pretty much everything I know about ModSecurity. Furthermore, I've pledged to keep the book up-to-date as ModSecurity evolves. Having good documentation is always very important, but especially so for ModSecurity, which is a very low-level tool.
  • Community. My personal perception is that the interest in ModSecurity is on the rise, although a look at the number of messages per month (in the list archives) does not seem to support my view. Still, there's almost 900 people subscribed to the mailing list, and that's not an insignificant number.

So now you know the facts, but what do they tell us? Here's my analysis:

  • ModSecurity is a mature product that generally does what it wants to do, and it does it well. There are currently no major features in the works, but there's an ongoing effort to improve the features that are already there. (Although I no longer influence the development, the current approach is consistent with my own philosophy, which is about quality rather than quantity.)
  • The primary use cases for ModSecurity are logging, real-time monitoring, access control, and virtual patching. If you need any of those, you need not look any further, because ModSecurity supports them all.
  • Because of its low-level nature, ModSecurity is useful to a small number of expert users, but now that the extensive documentation is available, the hope is that it will can be useful to a wider group.
  • The major missing features are learning (automated policy generation), easy-to-use rules and management GUIs. I suspect that a well-maintained fairly simple rule set that promises to deal with known worms and exploits could be the killer application for ModSecurity.