Slashdot Mirror
Windows vs. Linux Security, Once More
TAGmclaren writes "The Register is running a very interesting article about Microsoft and Linux security. From the article: 'until now there has been no systematic and detailed effort to address Microsoft's major security bullet points in report form. In a new analysis published here, however, Nicholas Petreley sets out to correct this deficit, considering the claims one at a time in detail, and providing assessments backed by hard data. Petreley concludes that Microsoft's efforts to dispel Linux "myths" are based largely on faulty reasoning and overly narrow statistical analysis.' The full report is available here in HTML form, and here in PDF. Although the article does make mention of OS X, it would have been nice if the 'other' OS had been included in the detailed analysis for comparison."
Ask some people that admin a mixed environment. Our Linux boxes get owned just the same as our Windows boxes do. When comparing older version of windows there is no doubt Linux owns windows but 2003 server it a pretty big improvement in security over NT 4.0 or 02. SP2 (with firewall) is also a huge improvement, just too bad it took MS this long to get it.
Saying Java is nice because it works on all OS's is like saying that anal sex is nice because it works on all genders.
Nice fuzzy logic there. How many of those 40 Microsoft vulnerabilities were related to Internet Explorer? Yes, it's Microsoft's fault for integrating it in the OS, but if you are using Server 2003 O/S to cruise the web with an admin rights role, you are the security problem, not the OS.
Why don't we look instead at security vulnerabilities in a Server OS that are relative to functions a server should be performing. How many vulnerabilities has IIS 6.0 had versus Apache in the year and a half Server 2003 has been out?
Hmmm one of those has had zero, and it sure the hell ain't Apache.
http://www.infoworld.com/articles/hn/xml/02/09/05/ 020905hnmssecure.html
Now, take a recent Linux box (the distro doesn't matter) and apply all official patches and upgrades, as released by the distro and the various package maintainers.
Each machine must have directly comparable software installed. Where possible, this should actually be the same software. You don't want to have too many variables in this. You're going to have some, but by keeping things uniform, you should be able to keep things sane. The other thing is that you want SOME closed-source software on Linux and SOME open-source software on Windows.
Before we do the tests, we need some diagnostics software on the machines. Memory bounds checkers, system load monitors, host intrusion detection software, etc. This will tell us what impacts we are having, beyond simply seeing if the servers and/or OS fall over or not.
At this point, we get to the tests themselves. Throw absolutely everything you can at the computers. Use every vulnerability scanner on the planet, every worm or trojan you can locate, use stress-testers, etc. Find DoS and DDoS packages, if any have been openly released.
Now we have some actual data, based on comparable usage and comparable attacks. The data will show that the different OS' respond differently to different attacks. (Surprise there, Sherlock!) We now need to determine which of the remaining variables are important.
The remaining variables are "underlying flaws within the OS", "inherent flaws, due to errors in the design methodology itself" and "unequal reporting of equal errors".
What you want to do then is a four-way analysis of variance. The first of the three components is the different vulnerabilites found within the different applications. The second way is looking at the variation between the different vulnerabilities within the OS' themselves. The third way is the variation of bugs reported for any given application, OS or combination, vs. what actually gets reported by groups such as CERT. The fourth way would be the difference in licensing policy.
The NULL Hypothesis for the applications is that all applications will have roughly the same number of vulnerabilities, regardless of what they do, what they're written for, the philosophy of the programmer, and the company producing the software.
It's doubtful you'd find enough applications, and enough vulnerabilities in each, to split the study in sufficient ways to cover all these points. However, it should be possible to collect enough to do a statistically meaningful study on a few of them.
The problem with AOVs is that you've got to have a lot of data, and that the amount of data you need increases very rapidly. You do get plenty of idiots out there who ignore the confidence level and even the methods of the study, looking for any slight comment that proves whatever they're wanting to say. Other times, even nominally sane people will do this, because they want/need the results too fast or too cheaply to do the work properly.
Let's say, for example, that the number of vulnerabilities found within the applications, when studying the variance between them, is pretty random. There's no discernable pattern. Let's also say that there's no significant variance found between FOSS and Closed Source. Then, let's say that we're in the 1% confidence level for both of these, which means that this will likely hold true 99% of the time.
We could then conclude that Closed Source vs. Open Source is purely a matter of personal choice. The net difference simply isn't significant to warrant going for one and ignoring the other.
Continuing with this fictional scenario, let's say that Linux and Windows showes a VERY signficant level of variance. We know, at this point, that it's not the Closed vs. Open nature,
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)