IronBee, Community and SSL
An interview with Ivan Ristić
by Dj Walker-Morgan
Ivan Ristić is all about security. Author of Apache Security, the guide to securing Apache web servers; developer of ModSecurity, the open source web application firewall and founder of SSL Labs which surveyed the state of SSL security on the web. Last year he joined security firm Qualys and is
now heading up the recently announced IronBee open source web application firewall project. The H caught up with Ristić and talked about how that and his SSL Labs survey projects are developing.
The H: You launched IronBee in February. How's the project developing?
Ivan Ristić: I think it's going pretty well. The big thing with IronBee is we want to be open and community-oriented. Many, many people got in touch with us after the announcement saying that they are interested in joining the project. Initially I wanted to have someone on board when we launched and we had Akamai, and now what I'm doing is running around trying to get as many people interested as possible, because I think community is what is going to make or break IronBee. I think it's crucial.
The H: Are you taking advice from anyone on the community side?
IR: I ran ModSecurity for about eight years – ModSecurity is open source of course – so I have plenty of experience on the community side; more in the sense of what not to do, I think. All the IronBee team are long-term open source contributors and very experienced.
The H: Are you going to be needing copyright assignment from contributors or will you be avoiding that?
IR: What we'll aim for is that everything we produce is going to be Apache 2 licensed and then not having copyright assignment, just a contributor's agreement saying everything that is contributed will be Apache 2 licensed, and then we don't care. The only situation where I see us having copyright assignment is if we had an independent foundation or something like that. However it is too early to spend too much time on governance because we don't have any (external) contributors yet; we are focusing on the code first. I'm actually open to the idea of having some formal governance in place, but I want to see what's going to happen first, so we don't waste everyone's time.
Going back to my earlier comments, ModSecurity was pretty open, but I think it has a flaw which all GPLv2 programs have, which is that if you have a single entity owning the code and asking people who contribute to assign the IP of their contributions to them, you get a certain asymmetry in the community.
So I have good theories on why a community of developers didn't form around ModSecurity; one is the licence and the other is that the program itself is monolithic, so there was a barrier to entry there which stopped people from being able to do something useful. I want to address that too with IronBee; we've made it very modular and we are going to have good documentation, so that if you have an itch to scratch, if you have a particular problem that you need to solve, you don't have to understand the whole thing.
We have very well-defined APIs so you can write a module for IronBee in a couple of hours. You can download it, compile it, there's a skeleton module there for you and you start from there. One thing I really liked with ModSecurity is that it was a very organic and incremental process; I had no plan, which is great, you just do whatever you need, day-in day-out, and the software just grows. Programming is like gardening. Of course with IronBee we can't really take that approach because we have certain goals we want to reach so we have to plan the architecture and put in that work.
The H: What is Qualys's role in the development of IronBee?
IR: Qualys is mostly on the scanning side of the business right now, but scanning, even if you do it daily, leaves a gap in time where you don't exactly know what's happening and where you can't really enforce anything. We thought that complementing scanning with real time access control and having this to collaborate and communicate would provide comprehensive coverage for various security issues. So once we established we wanted this, we looked at what is the best way to develop an application security engine or a sensor. We looked, and of course I had lots of experience with open source, so we decided that open source would be the best way because you create a community around a software commons where you have the same model as Linux and Apache; many entities contributing to the same pot and drawing from the same pot.
This achieves two things. One is you reduce your research and development costs and the other is that you actually gain relevance. Another ambition that we have is that we want IronBee to go everywhere; we want it in the cloud, we want every cloud provider to adopt IronBee as an open source tool with no strings attached because we believe that having de-facto standards would significantly improve security for everyone. If you have a good solid, well-researched, well-developed engine you raise the bar and companies can still compete on other levels. Also, users can have this functionality wherever they go; so if they take their virtual machine to Amazon or Rackspace or any third party, hopefully they'll see the same application security everywhere.
The way I see it, every commercial entity will contribute those features that interest them, and so if we have multiple entities, we ensure that no single party will dominate. Everyone who is interested in collaborating is using the same licence. I think it is very important that we use a non-viral licence because we want IronBee to be commercially usable.
What we want to do with IronBee is two-fold; one is the engine itself and the other is creating a community where we exchange information and intelligence. So someone can detect an attack, and that person can take a trace of the attack and upload it to a common place; others can then analyse it and write the rules and they, in turn, can upload and share those rules with others. I'm perfectly fine with that information being converted into other groups' formats, for example, ModSecurity. I see it as two parts of the same project but others don't have to work exclusively on both parts.
Of course, we are limited in the resources that we have, so my team is going to focus on IronBee because that's what we need for Qualys. Qualys is going to have a commercial equivalent of IronBee at some point.
I think I am doing everything I can to make Qualys' intentions very clear; we are doing this for ourselves and then sharing everything we do so that others can benefit, and in the long term we will reduce R&D costs. The goal now is to find these other parties [to share with] so as to move ourselves from being the only contributor to IronBee.