| Slide 1 |
| The Problem With Current Security Assesments |
| On one end: highly formal assurance | ||||
| Common Criteria: | ||||
| Extremely expensive: about $1M for initial assessment | ||||
| Meaningless answer: | ||||
| 3 bits: EAL0-7 | ||||
| A Òhigh assuranceÓ OS can be rooted the next day by a buffer overflow | ||||
| So how much of this is ÒenoughÓ? | ||||
| On the other end: Bugtraq Whack-a-mole | ||||
| Chronic chain of ÒgotchaÓ vulnerability disclosures | ||||
| Each disclosure tells you that you are not secure, but when you are secure is undecided | ||||
| Not very helpful :) | ||||
| Assessing the Assurance of Retro-Fit Security |
| Commodity systems (UNIX, Linux, Windows) are all highly vulnerable | ||
| Have to retrofit them to enhance security | ||
| But there are lots of retrofit solutions | ||
| Are any of them effective? | ||
| Which one is best? | ||
| For my situation? | ||
| Instead of ÒHow much security is enough for this purpose?Ó, we get ÒAmong the systems I can actually deploy, which is most secure?Ó | ||
| Consumer says ÒWe are only considering solutions on FooOS and BarOSÓ | ||
| Relative figure of merit helps customer make informed, realistic choice | ||
| Proposed Benchmark: Relative Vulnerability |
| Compare a ÒbaseÓ system against a system protected with retrofits | ||
| E.g. Red Hat enhanced with Immunix, SELinux, etc. | ||
| Windows enhanced with Entercept, Okena, etc. | ||
| Count the number of known vulnerabilities stopped by the technology | ||
| ÒRelative InvulnerabilityÓ: % of vulnerabilities stopped | ||
| Can You Test Security? |
| Traditionally: no | ||
| Trying to test the negative proposition that Òthis software wonÕt do anything funny under arbitrary inputÓ, I.e. no surprising Òsomething elseÕsÓ | ||
| Relative Vulnerability transforms this into a positive proposition: | ||
| Candidate security enhancing software stops at least foo% of unanticipated vulnerabilities over time | ||
| Vulnerability Categories |
| Local/remote: whether the attacker can attack from the network, or has to have a login shell first | ||
| Impact: using classic integrity/privacy/availability | ||
| Penetration: raise privilege, or obtain a shell from the network | ||
| Disclosure: reveal information that should not be revealed | ||
| DoS: degrade or destroy service | ||
| Impact |
| Lower barriers to entry | ||
| Anyone can play -> more systems certified | ||
| Real-valued result | ||
| Instead of boolean certified/not-certified | ||
| Easy to interpret | ||
| Can partially or totally order systems | ||
| Empirical measurement | ||
| Measure results instead of adherence to process | ||
| Implementation measurement | ||
| CC canÕt measure most of the Immunix defenses (StackGuard, FormatGuard, RaceGuard) | ||
| RV can measure their efficacy | ||
| Issues |
| Does not measure vulnerabilities introduced by the enhancing technology | |||
| Actually happened to Sun/Cobalt when they applied StackGuard poorly | |||
| Counting vulnerabilities: | |||
| When l33t d00d reports Òth1s proggie has zilli0ns of bugsÓ and supplies a patch, is that one vulnerability, or many? | |||
| Dependence on exploits | |||
| Many vulnerabilities are revealed without exploits | |||
| Should the RV test lab create exploits? | |||
| Should the RV test lab fix broken exploits? | |||
| Probably yes | |||
| Exploit success criteria | |||
| Depends on the test model | |||
| Defcon Òcapture the flagÓ would not regard Slammer as a successful exploit because payload was not very malicious | |||
| Work-factor View |
| Assume that well-funded attacker can penetrate almost any system eventually | ||
| The question is ÒHow long can these defensive measures resist?Ó | ||
| RV may probabilistically approximate the work factor to crack a system | ||
| foo% of native vulnerabilities are not actually exploitable | ||
| Therefore foo% of the time a well-funded attacker canÕt get in that way | ||
| Attacker takes foo% longer to get in??? | ||
| Lessons Learned the Hard Way |
| Security advisories lie | ||
| often incomplete, or wrong | ||
| Published exploits are mostly broken, deliberately | ||
| Compiled-in intrusion prevention like StackGuard makes it expensive to determine whether the defense is really working, or if it is just an incompatibility | ||
| Also true of diversity defenses | ||
| Technology Transfer |
| ICSA Labs | ||
| traditionally certify security products (firewalls, AV, IDS, etc.) | ||
| no history of certifying secure operating systems | ||
| interested in RV for evaluating OS security | ||
| ICSA issues | ||
| ICSA needs a pass/fail criteria | ||
| ICSA will not create exploits | ||