Ivan Ristić

Security is difficult; open source security sometimes even more so

I have prepared a presentation on Open Source security for the Open Source Specialist Group of British Computer Society (BCS OSSG):

• A_Look_at_Open_Source_Security  (PDF)

The main aim of the presentation is to give an overview of the current state of security in open source projects. I discuss why security is difficult (hint: it's because few people care), and why security in open source is sometimes even more difficult. At the end, I give a simple 3-point strategy for quick evaluation of the security posture of open source projects.

ModSecurity training at OWASP AppSec Europe 2009

Looking at the OWASP AppSec Europe 2009 schedule, I was happy to notice the attendees will be offered a ModSecurity training course. I taught the ModSecurity training course at AppSec Europe last year, but that was essentially a vendor-given session. This year, however, we have a member of community, Christian Folini (also known as the author of REMO) teaching the course, and I think that's a significant step forward!

Read ChangeThis and you may not need to buy a business book ever again

ChangeThis is a fantastic place that has tons of high quality content (essentially condensed books, often very well known), with each piece packaged as an attractive and easy to read PDF:

Weʼre betting that a significant portion of the population wants to hear thoughtful, rational, constructive arguments about important issues. Weʼre certain that the best of these manifestos will spread, hand to hand, person to person, until these manifestos have reached a critical mass and actually changed the tone and substance of our debate.

What is a manifesto?

ChangeThis doesnʼt publish e-books or manuscripts or manuals. Instead, we facilitate
the spread of thoughtful arguments…arguments we call manifestos. A manifesto is a five-, ten- or twenty-page PDF file that makes a case. It outlines in careful, thoughtful language why you might want to think about an issue differently.

I came across it several years ago, loved it, and then somehow managed to let it slip. I was lucky to re-discover it a few days ago. This post is to make sure this never happens again.

Signing the ModSecurity Contribution Agreement

Two months after leaving it, I went back: I signed the ModSecurity Contribution Agreement. If you read my blog post on open source dual licensing from a few days ago, the one where I explain how it is difficult to get user contributions to a dual-licensed open source project, you may wonder if I had told the truth. I had. I had said it was difficult to get contributions, but not impossible.

This is an interesting position for me to be in because I used to be on the other side, explaining to others why dual-licensing should not be a barrier to their contributing. It's only fair that I sign on the dotted line, isn't it? But—with the discussion on dual licensing in mind—why did I do it? It all comes down to motivation.

When you have big ideas it makes sense to start your own project, work hard, and benefit from your work. But when your ideas are not of the new-project sort, and generally not worth changing your life for, then the best thing to do is share your ideas (in the form of a code contribution) to a well-established project. By doing that you scratch your itch and get other people to benefit from your work.

And I don't feel bad about giving my time and code to Breach Security (who owns ModSecurity). Not in the slightest. After all, many man-years have been invested in ModSecurity. What do you think my contributions are going to be worth compared to what has already been given away to me?

A taxonomy of open source business models

If you liked my previous post, where I shared my experience with the use of dual licensing in open source, you'll love the taxonomy of open source business models that was recently published by Conecta (via 451 CAOS Theory) .

Dual-licensing for open source businesses

When I started to build a business around ModSecurity, back in 2004, I chose to keep complete ownership of the ModSecurity code base.  This business model is better known as dual-licensing. Keeping ownership of the code has the following advantages:

1. The product becomes (or remains) an asset; it increases the value of your business.
2. You can license the product under a different licence. For example, you can sell a version under a closed-source licence to the companies who are not fond of (or familiar with) open source licences. Similarly, you can sell OEM licences, which may be quite an interesting possibility, depending on the type of product you have.
3. Finally, you can bundle your open source product with another closed-source component and release the whole as a commercial closed-source product. This is quite a common strategy today.

Dual-licensing only makes sense when combined a viral licence such a GPLv2, in which case it helps you make your software freely available to your users, simultaneously creating a shield to guard you from your competitors—with only the open source licence to work with, the only way for them to benefit from your code is to embrace open source (which seldom happens).

As you can see, the advantages are many. But they are not free.

In return for the above benefits, you create a community of users rather than of a community of users and developers. The people interested in joining an open source project will largely do so for the reasons of passion, but the asymmetrical relationship of dual-licensed projects often stands in the way. Not only they have to justify giving you something (code rights) for nothing, but they can never hope to truly become part of the development team.

End result? You may end up with no contributors at all.

On the other hand, if you give everything away for free, you may find it difficult to pay for further development.

I spent months and years thinking about the above conundrum, and ended up believing that dual-licensing is an acceptable compromise and a viable business approach. At the end of the day, the approach probably won't give you that warm and fuzzy feeling only the participation in the open source community can, but, if successful, your project will be made available to everyone for free and it will pay you salary to keep on doing what you love.

D.J. Bernstein, I salute you!

I have long held a view that we get the software we deserve. The lack of quality, which manifests itself through defects, crashes, security and usability problems, is just a result of our buying decisions. By accepting to use crappy software we encourage software publishers to continue to give us more crap.

So it is a breath of fresh air to see D.J. Bernstein respond to a security report for djbdns:

Even though this bug affects very few users, it is a violation of the expected security policy in a reasonable situation, so it is a security hole in djbdns. Third-party DNS service is discouraged in the djbdns documentation but is nevertheless supported. Dempsky is hereby awarded $1000.

Not only that, but he apologises:

In the meantime, if any users are in the situation described above,
those users are advised to apply Dempsky's patch and requested to accept
my apologies. The patch is also recommended for other users; it corrects
the bug without any side effects.

D.J. Bernstein, I salute you!

Is that open source project secure (enough)?

Type the words "open source security" into a search engine and you will get dozens of links to articles, blog posts, emails, forum messages, and research papers. You can try to read them all, but I don't think you should bother. The opinions mostly fall under one of the following categories:

1. Having access to source code is better than not having access to source code.
2. Community-produced software is better than vendor-produced software.
3. The freedom to modify source code is a fundamental right of every software user.
4. Open source developers are careless, disorganised and fickle.
5. Commercial vendors only care about money.
6. Who are you going to blame when an open source product fails?
7. Open source is dangerous, but you can pay us to help you deal with it.

Most of these claims have a grain of truth in them, but they almost always miss the point in trying to distil complex realities into simple convenient truths. That just doesn't work. The simple truth is that every single project is unique, and must be observed on its own merits. But therein lies the difficulty: how do you determine if a given software product is secure?

I know the proper answer: design an assessment methodology (or use one that already exists—the Software Assurance Maturity Model is nearing completion; Building Security In Maturity Model is expected in a week or so), then use it to make informed decisions. While this approach is suitable for academia, it is too inefficient in real life, where you need to make your decisions quickly and effectively. So what do you do?

Did I mention that I spent almost 6 years of my life working on a fairly popular open source project? In that time I struggled to use my limited resources to do what's best for the project, security being only one of my concerns. I did reasonably well, but made many mistakes along the way. That experience (along with a similar experience in developing closed-source software) has given me an insight into what makes software developers tick and, especially, what makes open source software tick.

So I came up with an idea to avoid measuring the quality of code itself (because that's too difficult and time consuming), instead focusing on the external manifestations of good and bad practices. I call it a Project Security Posture Review. A review might focuses on the following aspects:

1. Does the organisation follow good software development practices?
2. How are security issues handled?
3. Are there any public-facing services available (e.g. source code repository, issue tracking, wiki, etc.)?
4. Is the source code tidy?
5. Is the project mature and popular?
6. Does the project have a reputation for quality?

The idea is that you can answer most of the questions by simply looking at the project's web site, browsing through its code and documentation, and looking at the experiences of other people with it. The obvious advantage of this approach is that it is quick, even though it may be somewhat inaccurate.

If you think the above list is, well, vague—you are absolutely right. I am currently working on a comprehensive list, which I will present during the Open Source Security talk for the Open Source Specialist Group (OSSG) on March 30th.

Update (March 5th): BSSIM is available at http://bsi-mm.com.

Application security, Italian style

Matteo Meucci writes to let us know that the presentations from OWASP - Italy Day III are now online. If you follow the link you will find not only the presentations, but the pictures from the event too. Look closely at the pictures and you'll see how application security in Italy is different, because over there people still dress properly. Elsewhere in the application security world people prefer to dress casually. While I don't have a problem with that (less and less so as I grow older, interestingly enough), I still long for the suit & tie days.