| |||||||||||||
RHEL, kernel vulnerabilities, and days of riskRHEL, kernel vulnerabilities, and days of riskPosted Mar 25, 2005 3:41 UTC (Fri) by giraffedata (subscriber, #1954)In reply to: RHEL, kernel vulnerabilities, and days of risk by bronson Parent article: RHEL, kernel vulnerabilities, and days of risk 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.
(Log in to post comments)
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.
|
|||||||||||||