| |||||||||||||
RHEL, kernel vulnerabilities, and days of riskRHEL, kernel vulnerabilities, and days of riskPosted Mar 25, 2005 0:38 UTC (Fri) by giraffedata (subscriber, #1954)Parent article: RHEL, kernel vulnerabilities, and days of risk Those who want to poke holes in this study should be able to find ample opportunity. Microsoft vulnerabilities are less likely to be disclosed prior to patching, to the point that the median "days of risk" for Windows was zero. That's not a hole. It shores up the conclusion by offering an explanation. If Microsoft can keep vulnerabilities secret until there's a fix for them, that's a reason to run your web server on Microsoft products instead of open source.
(Log in to post comments)
RHEL, kernel vulnerabilities, and days of risk Posted Mar 25, 2005 3:26 UTC (Fri) by bronson (subscriber, #4806) [Link] Starting the clock from the moment of disclosure isn't very informative. Risk starts well before then. Microsoft has proven better at keeping secrets from its own customers than it is at keeping secrets from black hat attackers...
RHEL, kernel vulnerabilities, and days of risk Posted Mar 25, 2005 3:41 UTC (Fri) by giraffedata (subscriber, #1954) [Link] Don't you think the risk is many times greater after it has become public knowledge?If only a few people know about a vulnerability, the chance is far less that one of them will attack my particular system than if the whole world knows. If I could have a system that is vulnerable only to bugs that are a closely held secret, I think I've eliminated a substantial portion of my risk.
RHEL, kernel vulnerabilities, and days of risk Posted Mar 25, 2005 8:08 UTC (Fri) by khim (subscriber, #9252) [Link] Ahh, good old "Security Through Obscurity" argument. It does work this way for small-scale systems (something like 10 or 100 installations). It does not work this way for widely deployed systems like Linux and Windows. "Black hats" do have incentive to find and use holes in Windows, "white hats" do not (what good will it do if you can not even ask for patch and doing it yourself is out of question?). Since most security problems are found in Linux with code auditing it's usually not exactly clear how to exploit hole at all for a long time but Windows holes are only ever acknowleadged when exploit is shown: there are still unpatched holes with obvious "buffer overflow crash" symptoms going back to NT 4.0 - but since exploits and not flying around Microsoft can claim "it's not a security problem - it's a feature". So in effect you are not having a system with a "bugs that are a closely held secret" but rather you are having a system with a "bugs that are not widely exploited yet" - quite a difference.
RHEL, kernel vulnerabilities, and days of risk Posted Mar 28, 2005 17:35 UTC (Mon) by giraffedata (subscriber, #1954) [Link] Those are all good points about security, but don't address the topic of this thread: whether the days of risk measurement in this study is a valid measurement for comparing security risk among programs. The article suggests that some bugs have an unfairly low days of risk measurement. The bugs you describe that are not a closely held secret, but just not widely exploited, would have a high days of risk measurement. So they're not the ones we're talking about. Also, I don't think whether Microsoft acknowledges a bug is part of the measurement. But one could imagine that the study biased the measurement by looking only to the easy sources -- Microsoft announcements -- to find out when bugs became known. That would make the issue moot.
RHEL, kernel vulnerabilities, and days of risk Posted Mar 28, 2005 16:45 UTC (Mon) by Ross (subscriber, #4065) [Link] What you say would only be true if the only way to find out about thevulnerability were from Microsoft. Obviously that is not true given that Microsoft is usually made aware of problems by third parties.
Obscurity is a poor substitute for security.
RHEL, kernel vulnerabilities, and days of risk Posted Mar 28, 2005 17:16 UTC (Mon) by giraffedata (subscriber, #1954) [Link] What you say would only be true if the only way to find out about the vulnerability were from Microsoft.You misread my comment. When I said "if Microsoft can keep vulnerabilities secret," I didn't mean if Microsoft can avoid telling people about them (though I understand that's sometimes what "keep secret" means). I meant if Microsoft can keep the vulnerabilities from becoming general knowledge. To the extent that Microsoft can't do that, because other people find and expose the vulnerabilities, my comment doesn't apply. But the article suggests that Microsoft can to some extent keep the vulnerabilities secret, because it says Microsoft lessens its "days of risk" measurement by not disclosing bugs.
RHEL, kernel vulnerabilities, and days of risk Posted Mar 28, 2005 17:23 UTC (Mon) by giraffedata (subscriber, #1954) [Link] Obscurity is a poor substitute for security.On the other hand, it's a great subsitute for no security and public knowledge of that fact. So I think the obscurity is worth measuring and using to gauge one's risk of using particular software.
|
|||||||||||||