« March 2005 | Main | May 2005 »

April 26, 2005

The effect of legislation

The register has an article which mentions the approaching deadline (June 30th) for merchants to comply with the PCI Data Security Standard for credit cards, which unifies requirements from VISA, MasterCard, Discover and American Express. The deadline has already passed for the really large merchants, those who have over 6 million transactions a year - that was September 30th, 2004. It generated a lot of pressure on larger companies as they rushed to comply - we could see it clearly in our customer base at Sana Security - and this deadline for smaller merchants is having a similar effect.

But I'm not sure how much these requirements help. Some of them are too technologically specific, for example, "Install and maintain a firewall configuration to protect data", and some seem far too vague, such as "Develop and maintain secure systems and applications". I think the merchants should be left to protect their networks as they see fit, without having to comply with requirements that may not make sense in any given environment, or that may not represent the most effective use of security dollars. For example, the Jericho Forum is promoting "deperimeterisation", and the requirement for firewalls goes against their thesis that we need to abandon the idea of a secure perimeter.

Those who drew up the PCI standard should learn from the lessons of the California disclosure act (SB 1386), which simply requires companies to inform customers when their personal information has been exposed. 1386 has resulted in many hacking incidents becoming news lately, including Polo Ralph Lauren, LexisNexis, DSW, and PayMaxx. (For a full list of recent publically announced data breaches see here). The effect of public knowledge of these incidents upon a company can be profound, leading to loss of confidence and customers. In fact, analysis has shown that publically known hacking incidents can cause a significant drop in stock price for the targeted company.

1386 provides a huge incentive for companies to secure their systems, without restricting or constraining the way in which they should do so, leaving companies to choose the most effective way. This encourages innovation in defense, because should new, more effective defense strategies become available, companies are more likely to adopt them, whereas if they are restricted to using specific technologies and practices, they won't be able to take advantage of new developments.

So, having said all that, my suggestion to the credit card companies would be to impose heavy penalties on merchants that get compromised, but not to specify what exactly those merchants should do to make themselves secure. And to offset the impact of losses, they should continue to incorporate the notion of quarterly scans by independent assessors, which is one of the few good things about the PCI Data Security Standard.

April 22, 2005

Built-in not bolt-on

I just gave a talk at the Systems and Software Technology Conference, the major IT conference for the Department of Defense. I had an interesting conversation with someone from a branch of the military, who told me about their need to have security "built-in" and not "bolt-on."

The reason? Laptops that are used on the battlefield can be in storage for prolonged periods of time in between usage. If they are reliant on security systems that need updating, such as Antivirus signature-based systems, they could be out-of-date each time they are deployed.

This could be a serious risk, since such machines may become internet exposed, depending on their location in the network. And of course, it only takes a worm in one of the laptops to infect all the others. Furthermore, they may also be vulnerable via wireless.

Consequently, they would prefer it if they could have systems that are immediately protected when they are deployed. An interesting application of the Innate Defense concept indeed - the idea that you have inbuilt protections for common classes of security threats, such as buffer overflows. Innate defenses are generally not comprehensive, but solve one problem effectively, without requiring updates or tuning.

April 05, 2005

Red Hat Linux vs Microsoft Windows: what really matters

Many people have been talking about the recent paper that compares Microsoft Windows with Red Hat Linux. The paper does a role-based comparison of Windows Server 2003 with Red Hat Enterprise Linux ES 3, meaning that they are compared when functioning just as web-servers. The conclusion of the report is that Windows in its default installation was more secure than Red Hat during 2004, with 52 vulnerabitlities for Windows vs 132 for Red Hat during the year, and 31 days of risk vs 70.

Of course, this paper created quite a firestorm, not least because the ongoing argument of whether Linux is more secure than Windows is like a religious war, and the paper was funded by Microsoft, which only increases the controversy.

After reading the paper, I have to say that I think it is a very valuable contribution to the debate, because it tries to quantify the difference between the two systems. Perhaps the data is not accurate, as some would argue, but the paper gives a full description of the methodology used, and so should be easily replicable. I'd love to see some of the naysayers repeat the analysis with their own data and see what comes up.

I do have a few quibbles though. Firstly, this paper compares two vendors, Microsoft and Red Hat, which doesn't necessarily give a good idea of how secure Linux itself is. As the authors point out:

One interesting aspect of the challenge faced by Red Hat that is not obvious from a simple examination of the raw numbers is the delay between a fix becoming available within a product, and the inclusion of that product as an "approved" Red Hat package.

They go on to give an example of a MySQL bug that was fixed in June but only incorporated in the Red Hat package in November. And since they only look at fixes that come officially from Red Hat, this introduces a vendor specific bias. One of the reasons that this bias has an impact is that there are many vendors of Linux, but only one of Windows. With many - if not most - Windows vulnerabilities, Microsoft is given advance warning by the people who discovered the vulnerability, and given time to fix it before the vulnerability is made public. By contrast, Red Hat would not be given such advance warning, since it doesn't control the source code of Linux. Hence the task faced by Red Hat is much more daunting.

This has interesting ramifications for the security of open source. Firstly, it is potentially less secure because vulnerabilities are publically known before the community has time to fix them, unlike closed source. On the flip side, though, there is more knowledge about the existence of vulnerabilities. The thing that I find unnerving is that if a third party finds a vulnerability in Windows, and reports it to Microsoft to give them time to fix it before making it public, someone else could also have found that same vulnerability, and could be actively exploiting it without anyone knowing. How much this happens we don't know, and will probably never know, but it's certainly possible. What this could mean is that closed source will have less exposure to known vulnerabilities, but potentially more exposure to zero-day or unknown vulnerabilities, although of course this is wild speculation.

Another major potential issue with regard to the vulnerabilities count is that they only consider vulnerabilities that were fixed by the vendor during 2004. If the vulnerability existed in 2003 and was not fixed then, it is counted, and any vulnerabilities discovered in 2004 that were not fixed are not counted. To quote the paper:

we will not consider vulnerabilities announced in 2004 but fixed in 2005.

Of course, what this means is that if a vendor gets a 1000 vulnerabilities in 2004 and doesn't fix any of them, then they will not show up in the analysis. The authors try to iron out this effect by including vulnerabilities from 2003 that were not fixed in 2003, but I think what would make more sense is to consider all vulnerabilities from 2004, and make a note of which were fixed, and which weren't, including those carried over from earlier years. After all, if we want to know the days of risk during 2004, we have to include all vulnerabilities discovered during 2004 and not fixed.

And now a comment on methodology: they compared the systems in their default "out-of-the-box" configurations, without any security hardening. That is a fair way to go about it, but one objection that I have is that they totally disregarded the effect of the firewalls that exist on both these systems. I can't imagine anyone would actually deploy these servers without the firewalls turned on, especially on the Red Hat box since the firewall is on by default.

So what I'd like to see is a comparison in more meaningful terms, i.e. if I deploy these servers in default mode, connected to the internet, what are the chances that someone out there can own my box? Let's forget password stealing, and rather focus on application level vulnerabilities. Just reporting the total number of vulnerabilities, and using the ICAT severity ratings, doesn't give me much idea of the risk. In particular, ICAT calls a vulnerability severe if an attacker can remotely get root or user access, or a local user can get root access. Now these are all quite different things. If there are no remotely exploitable vulnerabilities, I don't care about local vulnerabilities. On the other hand, if there are no local rootable vulnerabilites, then the remote non-rootable vulnerabilities are so much less severe.

What I would suggest is the following metrics:

1. The total number of remote rootable vulnerabilities, assuming the firewall is on.

2. The total number of remote user access vulnerabilities, assuming the firewall is on.

3. The total number of local rootable vulnerabilities.

4. The days of risk for each category above.

These metrics would give a much more understandable idea of the risk than those in the paper. And who knows, Microsoft Windows may turn out to be more secure than Red Hat Linux...