Ivan Ristic

Bitfrost (OLPC) solved the desktop security problem

I've run into a very interesting presentation from Ivan Krstić (via Risque Management) who, as director of security architecture for the One Laptop per Child (OLPC) project, designed a new code execution platform—Bitfrost—to avoid the security issues that plague the desktop systems in use today. Bitfrost uses capabilities to restrict what each program can do, irrespective of the user account it runs under. You may be familiar with the concept from SELinux, GRsecurity or AppArmour, or, more recently, Caja.

By designing Bitfrost, OLPC did something remarkable: it gave up compatibility (with other platforms) in exchange for a secure execution environment. It's a decision so unusual that it must be applauded. So it's no wonder that Ivan resigned in March of 2008 after OLPC had appeared to have changed focus and Windows XP on its laptops became a reality. Judging from the status page, it appears that Bitfrost is not complete yet, so I wonder how it will progress now that Ivan is not with OLPC any more.

The presentation is full of interesting observations that I fully agree with. For example, the main point:

We have failed as an industry, and modern desktop security is completely broken as a result.

And this statement:

Key symptom: desktop security relies on the user to make informed, sensible choices... About things they don’t at all understand.

And this one:

So we weasel off responsibility to the user, stick our head in the sand, and pretend this was the right thing to do. But the user knows as much about computer security as they do about gravitational waves, closed strings and D-branes.

Please go and read the presentation for yourself so that I don't have to quote it here in its entirety. (What's a D-brane?)

Backward compatibility, by the way, is the main reason why everything is so insecure today. We made these very bad choices years ago, when the circumstances were vastly different, yet we are refusing to put things right today. It is a genuine challenge, even if you put the interests of various industries aside. If you were to come out with a perfectly secure operating system today people wouldn't jump to use it only because it's secure. Only Apple could have pulled that off, by doing things right in Mac OS X, but they wasted that opportunity.

The really sad fact is that the next opportunity to fix things is passing us by at this very moment. The whole world is moving to the Web, where desktop applications don't matter, but, instead of doing things right, we are just moving from one insecure platform to another.

I've come to the conclusion that people (e.g. developers) must be forced to do the right thing by not allowing them to do the wrong thing. The low adoption of the Java security model is a perfect example of this. Java has had a very good capabilities-based security model since version 1.2 (released in 1998), but hardly anyone is using it today. Why? Because it's optional.

Open Source lesson: SpringSource falling from grace

I first encountered (and used, in production) Spring Framework in its pre-1.0 days, and it was love at first sight. I loved it because of its vision, a very good design of its MVC and database libraries, and, most importantly, quality (I am sure it has bugs, but I am yet to encounter one). The licence, Apache Software License version 2, was right too. I had even been a step away from joining the development team, but ultimately decided to focus on ModSecurity instead. Spring had a lot going for it: the Java server-side programming was in a state of disarray. We needed a beacon to guide us.

Fast-forward a few years, and we have Spring firmly established as the leading player in server-side programming. Then, a few more years down the road, the bloat is starting to appear, after the development team (apparently) deciding small and focused is not beautiful after all. In parallel with the evolution of the framework, Rod Johnson (the author of Spring) grew his consultancy business, Interface21.

Then, the inevitable happened. The success of Spring became too tempting. Interface21 sought venture capital, changed its name to SpringSource, and went on to buy Covalent (or merge with, depending on whom you ask), a quiet but persistent company in good standing with the community.

My fear, when I heard the news of funding, was the same as Corby's (from the post at InfoQ):

If anyone had the ability to grow organically, I thought Interface21 did. VC don't give you money unless they're going to grow you 20X. I am very concerned about seeing an explosion of Spring subprojects that lack the quality or the relevance of Spring core. And VC don't give you money unless you're going to cash out. I don't see Interface21 operating as a standalone IPO, so that means they will be actively seeking acquisition. I hate to see one of the big guys get ahold of this very independent entity. I wish the Interface21 folks great financial success, but I hope Spring does not turn into a bloated, slow-release monster. I have already heard rumors that Benchmark Capital is pressuring Rod Johnson to change his name to something more kid-friendly.

Things started to go wrong after SpringSource decided to experiment with their licensing choices. They introduced a number of proprietary products and started using other open source licences. Their most recent product, SpringSource Application Platform, is licensed under GPLv3, in stark contrast to ASLv2 used for the framework itself. (GPL essentially allows businesses to retain control of the code base.) The changes made many members of the community feel insecure, and lead to heated exchanges on the forums. Prior to the changes the company was often called a darling of Open Source (it sounds like something I would have said), because they were a rare example of a business (the Interface21 consultancy) built around the restriction-less Apache Software Licence. I can only conclude that, under the changed circumstances, their business was not growing fast enough, and that they felt that they needed to do things differently.

This story is a clear demonstration of the challenges facing open source commercialisation, especially when funding comes into play. Where we previously had a clean separation of the project and the company, now we have a company that is using the project to build a proprietary business model around it. They may still be contributing to the open source parts—today—but do you trust them they will continue to do so? SpringSource are saying they are on the same path they have always been. Maybe they believe it, but they are not on the same path, and the users see it. SpringSource are saying they will keep the Spring Framework alive and open source. I actually believe they are being honest when they say that. But I also know that people come and go and that, eventually, the prosperity of the company may matter more at some point in the future. There is no doubt that Rod Johnson cares deeply about the project, but there is also no doubt the VC company behind the funding cares only about the money.

Let me be clear when I say there is nothing wrong with making money of your work, be it open source or not. It's the change of direction that's making everyone nervous. For many people open source is about freedom and certainty. They don't want to have vendors to depend on. They've chosen to work with Spring Framework on the basis it's vendor-free. So it's not surprising that they are starting to feel twitchy now that they've realised the company behind their favourite project is a vendor too. If SpringSource want to preserve their hard-earned credibility they need to act fast to insulate themselves from the core Spring Framework project. It's certainly a tough thing to do (convincing the VCs, I mean), but it's the only thing that would bring the user trust back and preserve the developer community (as in those developing the framework itself).

Ultimately, it may not matter. Spring Framework has already built a momentum. It is a very good product, so there is no reason to not use it. But there's no help but feel a bit cheated. We are never going to have the same warm feeling about Spring, as we did back in the old days.

Firefox 3 improves handling of invalid SSL certificates

I have downloaded the beta of Firefox 3 to check out the improvements related to SSL. First, there's the added support for Extended Validation SSL certificates, but I am not very excited about that (I wrote about this previously in Extended Validation SSL certificates not going anywhere, as predicted). It's a nice feature, but it's not going to bring much good overall. On the other hand, I am very happy with the improvements to the handling of invalid SSL certificates.

Firefox 2.x allows users to simply click-through their way to a site that uses an invalid certificate.  There is a warning of some sort, but who reads warnings anyway? (Internet Explorer is not much better in this respect, although at least its warning is very clear about not recommending the user to proceed.)

With Firefox 3.x, the situation is much better. First you get the same style of error response as you would for any other network problem:

The beauty of this page is that it does not allow you to proceed to the site. To go through you have to create an exception, which is a multi-step process that you can start by clicking on that link at the bottom. You then get the following:

Another warning; very good. Clicking the Add Exception... button gives you the form that is used to actually create exceptions. There's a nice final warning on the top of the form, which will hopefully deter those who will be attempting to create an exception for the wrong reasons:

The changes represent a great step forward, and significantly reduce the likelihood of successful man-in-the-middle attacks. Still, I wouldn't mention exceptions at all on the error page: advanced users will find a way to do what they must, but normal users are better-off not knowing anything about exceptions.

Update (7 May 2008): My request to make hide the functionality to create exceptions from the error page was rejected. It's good to know that the issue was considered, even if the decision is not the one I would have made. Daniel Veditz pointed me to Johnath's blog post, which describes the history behind the new SSL error page. Very interesting.

 

Microsoft vs. Yahoo analysis on Marc Andreessen's blog

I don't have a habit of making posts consisting merely of links to interesting content elsewhere, but this one is just too good to pass: Marc Andreessen published an analysis of how the takeover fight between Microsoft and Yahoo may play out. Fascinating!

PCI Council clarifies Requirement 6.6, ends ambiguities

The PCI Council has just published the clarifications for the Requirement 6.6 of the PCI DSS 1.1 standard. The 8-page document dated April 15th (but not yet released in an electronic form, which is expected to happen tomorrow, on the 18th) significantly expands on the 7 lines of text of the original requirement. [Update (Apr 23): the document is now available for download.]

Overall, the clarification document comes across as very useful and well balanced. It basically lays down the options for the organisations looking for compliance, saying they can choose how to handle 6.6 for as long as they do it properly and stay within the spirit of the requirement.

Here are the highlights:

• Vendors of web vulnerability scanners and source code analysis tools are going to benefit from the clarification, because both are now explicitly mentioned as offering an adequate approach.
• Overall, I think the Council has gone to a great length to discuss how they don't want to see the automated tools (of any sort) used to just tick a few boxes away. Throughout the document they emphasize the importance of doing the job properly, and by qualified personnel. That is very encouraging.
• It is now clear that it is all right for an internal resource to perform a scan and/or a review, for as long it is not within the same organisational unit as those in charge of developing and maintaining the application.
• More than half of the document discusses web application firewalls, but doesn't really say much new, except to those who are not familiar with the technology. Although there is plenty of content—some of which is very useful—there is not enough space to cover everything one needs to know about WAFs. I think a better approach would have been to focus on what is expected of a WAF to do in the PCI role, leaving to other efforts (such as WAFEC, which is referenced in the document) to discuss what WAFs are and what they can do.
• By far the best sentence in the web application firewall section demands proper use of the technology, not mere installation: "Note that compliance is not assured by merely implementing a product with the capabilities described in this paper. Proper positioning, configuration, administration, and monitoring are also key aspects of a compliant solution." Well said. I would write it in the document in big bold letters.
• I also very much liked the mentioning of the fact that there are many products out there advertised as containing application firewall functionality, but that the organisation needs to ensure they are doing what is required from them—actually making sense of the application-layer traffic.

Overall, the document is a significant step forward. It expands what was a brief mention of several very diverse technologies into a solid recommendation how they are to be used to achieve compliance.

No such thing as Open Source business model

I started my open source project, ModSecurity, back in 2002. It was initially just a hobby, something I did in my spare time. ModSecurity grew in popularity, so in 2004 I decided to form a business around it. Thinking Stone was born. I sold Thinking Stone to Breach Security in 2006, and that was the end of my first start-up. (But not the end of ModSecurity, which continues to flourish.)

I will freely admit that I didn't have a business plan. I knew instinctively that the product was good, and I generally focused on improving the product while supporting the growing user base. Everything else I let happen organically. This "strategy" worked out all right in my case, but, in retrospective, I should have invested more effort into commercialising the user base. My luck could have went the other way just as well.

In researching how Open Source relates to business today, I've discovered a very peculiar fact: there is no such thing as an Open Source business model. There are a few companies promoting themselves as open source, but if you dig deeper you uncover that, if they are making any money, it is coming from the proprietary bits, not from open source. If there are any companies making money today from supporting their open source products, chances are they are just in a transient phase moving away from that model because there's essentially no money in it.

A typical lifecycle of an open source company looks like this:

1. Build a product people want to use. Make it free and open source, because you want to grow the user base as quickly as possible.
2. Perfect lead generation and nurturing, which is the key skill you need to have in order to be able to convert users into customers.
3. Sell training and support, because that's easy to start with.
4. Sell subscriptions, because support does not scale well and is just not sticky enough.
5. Create proprietary versions/add-ons/tools, because everything else you did so far failed to make you any real money.

It seems to me that companies are now open sourcing products because it's an effective distribution strategy, and also because they have to—everyone else is doing it. However, because there's no money in true open source, they end up selling proprietary versions, and we (the consumers) are essentially back where we were prior to the open source revolution.

Changes to British law target criminals, but affect the entire security industry

Back in 2006, at a computer security panel at Infosecurity London, I found myself criticising the proposed changes to the Computer Misuse Act (CMA), which would essentially outlaw any tool or information that could be used to assist in computer crime. Two years later things are pretty much as they were, and the changes are expected to become effective in England some time this year. They are already in effect in Scotland. There's been an attempt late last year, by the Crown Prosecution Service (CPS), to clear things up by releasing the promised Guidance to Prosecutors, but that did not help (see here and here, with additional coverage at Heise Security).

The key proposed addition in reads as follows (a marked-up copy of the changes is available, courtesy of Clive Feather):

3A Making, supplying or obtaining articles for use in offence under section 1 or 3

1. A person is guilty of an offence if he makes, adapts, supplies or offers to supply any article intending it to be used to commit, or to assist in the commission of, an offence under section 1 or 3.
2. A person is guilty of an offence if he supplies or offers to supply any article believing that it is likely to be used to commit, or to assist in the commission of, an offence under section 1 or 3.
3. A person is guilty of an offence if he obtains any article with a view to its being supplied for use to commit, or to assist in the commission of, an offence under section 1 or 3.
4. In this section “article” includes any program or data held in electronic form.
5. A person guilty of an offence under this section shall be liable—
   • on summary conviction in England and Wales, to imprisonment for a term not exceeding 12 months or to a fine not exceeding the statutory maximum or to both;
   • on summary conviction in Scotland, to imprisonment for a term not exceeding six months or to a fine not exceeding the statutory maximum or to both;
   • on conviction on indictment, to imprisonment for a term not exceeding two years or to a fine or to both.

The main issue is the ambiguity of the word likely in "[...] likely to be used to commit, or to assist in the commission of, and offence [...]", which effectively criminalises a large number of security professionals who are just doing their jobs.

As any computer security professional will tell you, criminals use essentially the same articles (tools, books, papers and sources of information) as those in charge of making things secure. Making the articles illegal is not going to stop the criminals from using them—they will be too busy committing the actual offences to care—it will just push the articles underground and out of the reach of the good guys. I am guessing the intention of the proposed changes is to reduce the availability of such "dangerous" stuff by restricting the distribution channels. That, however, is a pointless exercise, as it cannot possibly succeed.

A much bigger problem is that the new law leaves too much to interpretation. The risk is just too high: do you want to be in a position to defend your actions in front of a jury that will almost certainly fail to understand the subject matter? Even if you are successful in your defence, such an event will require significant financial resources, disrupt your life, cause you and your family endless pain, and most certainly kill your career.

What are the possible outcomes?

Possession it not likely to be criminalised (from the Guidance: "[...] does not criminalise possession per se unless an intent to use it to commit one of the other offences in section 1 or 3 CMA can be shown.") so it will probably still be safe to research computer security in private, but exchanging information with others might become dangerous. With the threat of persecution hanging over their heads, most people in the UK are likely to stop publicly discussing what they know.

Full disclosure—no matter what you think of it—will be criminalised, but it won't go away. Those who believe will continue to release vulnerability information, but they will likely take precautions to keep their identities secret.

Tool authors will have a choice to make. If they don't change their distribution practices they will risk becoming a target of investigation and, possibly, prosecution. The Guidance seems to imply the safe way to distribute the tools is via a vetted list of computer security professionals. This is not feasible for most tool writers as they cannot afford the overhead of such a process. On top of that, even if such practices are followed, there is still no guarantee that you won't be persecuted. Each case will be reviewed on its own merits. Thus the alternatives—ending further development or moving the tools underground—seem far more likely.

Criminals are taking over the Internet

A parallel world is being created on the Internet, as many science fiction writers had predicted. Our faults and virtues, the same ones that have existed for thousands of years, are now shaping the virtual world, and it's not pretty. The criminals are taking over. To commit crime on the Internet is so easy, so convenient, that they are abandoning their real-life efforts in great numbers.

I've recently had a pleasure of attending a talk by Merlin, the Earl of Erroll, where he discussed the changes forced upon our society by rapid adoption of technology. The talk was sponsored by Breach Security, as part of a promotional party organised here in London, at the Company of Information Technologists. Merlin is a well-know figure in Britain, and it was refreshing to hear someone give an honest opinion about where we are heading, and about the state of security and privacy in the UK.

One thing that made an impact on me was his account of how criminals are actively taking advantage of Internet technologies, and exploiting the loopholes in the current organisation of the police force and the justice system. One problem is that these organisations were designed to tackle large problems, whereas most crime that takes place on the Internet is, individually, low in value. The cost of pursuing a large number of small cases is simply prohibitive. In aggregate, however, the cost to the society is much higher, but we are lacking mechanisms to deal with it. It's even worse when you take into account inefficiencies of collaboration across jurisdictional boundaries. These have a significant impact even within one country, but really are devastating when crime crosses over.

Can we do anything to deal with the problem? It's obvious that we stand no chance to investigate and prosecute most of such crime cases, so we should focus on prevention. We should focus on making it more difficult for criminals to make money. What that exactly means is not clear, but I'd really like us to start by adopting a method of payment more secure than credit cards. The technology is already available, all we now need is will.

Open Source wants to ruin my life

One of the side effects of Open Source is that it effectively pushes the cost of software down to zero. You can argue that I can charge whatever I want for the software I license as open source, but that argument doesn't work very well. For as long as my licensees have the right to distribute my product free of charge, an informed market is not going to want to pay to get it. Open Source seems to be very good at preserving the rights of users, but not any good at preserving the rights of authors.

I can cheat, as many companies do these days, scaring people with words such as warranty, indemnification and support. I can also repackage my product as a subscription, which seems to work for some companies. But that just wouldn't feel right. It's essentially doing the same thing as before, just calling it something else. Furthermore, doing business this way creates an incentive to make the software just good enough to attract the user base, but not really solid to enable them to use it without my help. Other companies prefer to leave the critical piece out of the open source package for the same reason.

While I can do all these other things—I do not want to. It is just not the life I want to lead. You see, I believe in one's right to make a living by doing what they love. I love writing software and I am good at it—it's only natural to expect to be able to write (and sell) software for a living.

But Open Source wouldn't let me have none of that. I am condemned to a life of compromise instead.

Threat modelling: real-life asset devaluation example

Threat modelling is a risk assessment technique. Simplified, you systematically assess your environment to identify your true assets and the likely adversaries, along with the possible ways for them (the adversaries) to obtain the assets. The main point is to base the analysis in reality, allowing you to identify what is likely to happen while ignoring the ever-present noise. At the end of the process you end up with a prioritised list of threats, and then use your budget (resources) to address the most dangerous one, using one of the mitigation strategies available to you. You then repeat the process until you run out of resources. It is a simple and elegant technique, and one of my favourite security tools.

One of the most useful generic mitigation strategies is asset devaluation. The logic behind the concept is simple. Attackers are typically driven by their desire to obtain assets. If you remove the asset from your environment, or lower its value, then you also remove the reason the attacker is looking at your system. Without the asset to obtain, he will simply go elsewhere.

One of the best examples of asset devaluation is not storing credit card numbers on e-commerce web sites. While some merchants do need to store them, most need the credit card numbers only initially—to process the transactions they were submitted with—and never use them again. What a wonderful opportunity to reduce one's attractiveness to attackers! By removing the credit card numbers from your systems, and telling the adversaries about it, you stay out of trouble.

Although I've used this example many times during my talks on threat modelling, yesterday was the first time I actually saw the technique used in real life, as I was making a purchase from Introversion, an indie game developer from Britain. Here's a partial screenshot:

An added bonus is that this kind of thinking also makes consumers happy. When I saw the note, I instantly perked up, happy in knowing my beloved credit card number is not going to be stored at yet another web site.

Wouldn't it be great if all web sites disclosed details of their inner workings in a similar manner?