Last week we changed the license of LibHTP from the Apache Software License version 2 (ASLv2) to a BSD 3-clause. We did this to work around GPLv2 incompatibilities in the Apache license (incompatibilities acknowledged in the Apache Licensing FAQ). In particular, the old licensing impeded collaboration with the excellent folks at the OISF: they couldn’t move to a more recent version, nor could they give back necessary improvements that they’d made.

We debated and discussed several strategies, for example, dual licensing or specific exceptions, but in the end settled on re-licensing as the simplest change that got both FOSS projects “unstuck.” Further, with LibHTP being a library, we wished to use a license that would enable as many projects as possible to rely on it.

So, please, use and enjoy LibHTP.

Ohloh statistics

February 21, 2012

Brian reminds me that Ohloh tracks our development progress, so if you're interested you can have a look (there are two projects, tracking IronBee and LibHTP separately). Here's a screenshot of IronBee contributors:

And here's a screenshot of the contributors to LibHTP:

IronBee reboot

February 20, 2012

We announced IronBee, our next-generation web application firewall engine, exactly one year ago at the RSA Conference in San Francisco. Although we had expected to have a fully working product by now, it did not happen. In this post I will explain why.

This time last year, we had a core of the product built on top of LibHTP, our security-aware HTTP parsing library. We had also put the project infrastructure out in the public, on GitHub and SourceForge. The initial public release was 0.2, and the state of the project was pretty much what you would expect (except for LibHTP, which had been worked on earlier and was pretty decent). The goal of the early announcement was to get the word out and hopefully get interested parties to join us. It didn't work. The feedback was overwhelmingly positive and many were genuinely interested in working on IronBee, but, at the end of the day, no one followed through.

The lack of contributors did not stall our project. What did stall it was the fact that our entire development team was busy with other projects, and our inability to hire a full-time developer for IronBee. It was not until November that we had hired Nicholas LeRoy to fill the developer role, and that's when the development started to pick up. We were also able to free additional resources for work on IronBee.

The official reboot happened internally about a month ago, but we are making it public now. This year's RSA Conference is next week, and we're aware that people will be asking questions about our progress. If it weren't for that, we would probably keep quiet for another month or so, until we had more to show.

In the following weeks, we will start to make regular releases, improve the documentation, and start to write here about our progress and, especially, the new interesting features we have in IronBee. Finally, we will start to track our progress on the development roadmap.

After spending a couple of weeks talking about IronBee to anyone willing to listen, I have assembled a list of commonly asked questions. Not unexpectedly, the question that tops the list is about the difference between ModSecurity and IronBee.

With IronBee we had a luxury of starting a brand new project with a wealth of experience and a clear idea of what we want to achieve long-term. (This is completely the opposite from where I was when I started ModSecurity.) Thus, we were able to look at our goals and choose the best path to reach them. Because so much of our lives were spent with ModSecurity, the first thing we did was look at its successes and limitations, with the idea that we should keep what's good and improve what's not as good. Two not so good things of ModSecurity stuck out: the lack of a community of developers and the fact that ModSecurity runs only in the Apache web server.

To deal with that, we do two core things differently:

  • Community focus. We are making IronBee as open as it can be, not only by using a non-viral open source licence (Apache Software License v2), but also by adopting a transparent community-oriented approach to project management and development. We have also designed IronBee to be highly modular, so that adding to it does not have to mean having to understand the entire architecture and operation. Time will tell, but the idea is that giving up tight control will make for a better open source project in the long run.
  • Abstracted data acquisition and host-container interaction model. IronBee is built as a framework from ground up, with focus on portability among web servers and a variety of deployment models (embedded, proxy, passive, batch, etc). Hence the universal application security sensor wording. We want you to have access to IronBee no matter what your platform is.

These two things are actually tightly related. For example, we can't succeed with the second goal without first succeeding with the first one. There are so many platforms (potential host containers) out there, so it is not possible for a small team to support all of them. However, by being open and by structuring the code base to make it easy to add new platforms, we create the right conditions for others to port IronBee to other platforms as the need arises.

It is my great pleasure to announce the launch of IronBee, a brand new open source web application firewall. It's a project whose main goal is build a universal application security sensor through focus on community-building first, with code second. To that end, not only is the project open source, but it uses the Apache Software License 2 and does not require copyright assignments from contributors. How's that for a conversation starter?

If you head out to the project web site now, you'll find there a whitepaper that goes into detail about why we believe in application security monitoring, why we are taking this particular approach with IronBee, as well as an overview of our key directions. There's no need to repeat all that on this blog. I hope that the whitepaper will give you enough information to get you excited about where we're heading, and excited enough that you will join us on the mailing list for a discussion.

Of course, if you follow my blog you probably know about my work of at least 8 years on ModSecurity, which is a very good and popular open source web application firewall. I will freely admit that it feels a bit awkward to start what is effectively a competing project. Make no mistake, ModSecurity is a fantastic tool (and one very dear to my heart). IronBee exists because we want to do more and go further, and for that we need to start with a foundation different to that of ModSecurity.

Further, the existence of IronBee does not mean that we cannot collaborate with ModSecurity (the project and the community). In fact, we can and want to. I imagine that a good chunk of our work (e.g., security research) will be useful to ModSecurity users. And, for the record, I intend to continue to keep ModSecurity Handbook up-to-date.

IronBee is an open source project to build a universal web application firewall engine.


IronBee  LibHTP  ModSecurity