Red Hat and Windows - Defining an Apples-to-Apples Workstation Build

re: Red Hat and Windows - Defining an Apples-to-Apples Workstation Build

PeteLind — Sat, 07 Oct 2006 05:18:13 GMT

Jeff - why are you suggesting that more vulnerabilities found equals less secure? I thought the whole point of vuln discovery was to make systems more secure, not less secure. You are going down the right path, but should have a look at CMU's RASQ (originally developed with Michael Howard) for a better way to think about this.

Pete

re: Red Hat and Windows - Defining an Apples-to-Apples Workstation Build

jrjones — Sat, 07 Oct 2006 20:42:54 GMT

I am not sure we're talking about the same thing.

More vulns disclosed publicly after ship raises customer security risk.

More vulns found and fixed improve risk, but with a lot of caveats. If found and fixed before ship, super. If found and fixed very quickly, also good. If disclosed and unfixed for a while, not so good.

An additional practical security issue also applies in terms of work required. Let's say it takes 15 days to roll out a patch to all machines in an enterprise. Then if you deal with one patch every 46-60 days (on average), then the team can probably do well at reducing risk. On the other hand, if you have to react to a new security patch every 7 days, it may be a challenge to manage it, and certainly more work.

I've read the Howard, Pincus, et al. paper on RASQ and it might be a better metric, but it also would require several orders of magnitude more work to complete. I'll ask Mike why he's not doing this ;-)

On the other hand, the general RASQ process is driven from the base set of vulns found and disclosed, so I find the easier metrics I *can* measure to be reasonable for comparisons, especially the comparisons that weight the scores for higher severity vulns.

re: Red Hat and Windows - Defining an Apples-to-Apples Workstation Build

PeteLind — Thu, 12 Oct 2006 20:41:35 GMT

"More vulns disclosed publicly after ship raises customer security risk."

If this is true, how do you feel about public bugfinding? It sounds like you think it is a bad idea.

"the general RASQ process is driven from the base set of vulns found and disclosed"

Huh? What part of RASQ uses known vulns (or any vulns, for that matter)?

re: Red Hat and Windows - Defining an Apples-to-Apples Workstation Build

jrjones — Fri, 13 Oct 2006 00:24:03 GMT

Pete,

I'm not against finding bugs, I love the fact that more and more finders are out there and that the science of security testing is improving. However, I would say that I am a proponent of responsible disclosure for purposes of minimizing customer risk.

As for RASQ, my statement was based on readings from Howard/Pincus/Wing "Measuring Relative Attack Surfaces" like:

"... we want a measure—at a higher abstraction

level—that gives more weight to bugs that are more likely to be exploited." and "...model

an attack as a sequence of executions of actions that ends in a state that satisfies the adversary’s goal, and in which one or more of the actions executed in an attack involves a

vulnerability."

My interpretation is that measuring "attackable area" works because, assuming equal code quality, more areas to attack means more potential for an attacker to find "behavior that deviates from the intended design", or in other words, vulnerabilities.

If we were looking at systems having a vastly different code quality (1 vuln per 100 lines of code versus 25 vulns per 100 lines of code), then I think "attackability" calculations would need to take that into consideration along with surface attack area, enablers, etc.

I admit I'm not a very deep expert on RASQ though, so I may be overlooking something key.

Windows vs Linux - Workstation Comparison - Q3 2006

Jeff Jones Security Blog — Tue, 07 Nov 2006 22:03:35 GMT

NOTE: I am not asserting that my vulnerability analysis demonstrates that Windows is more secure. Rather,