Suggestions for Keunwoo from Caroline for this tech intro

From PublicWiki
Revision as of 01:43, 8 December 2004 by 128.95.208.57 (talk)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Not to explain CS to you but rather to give you an idea of what you are up against and the sort of issues that will be news to many in a policy/law crowd as I've discovered them to be. some random thoughts/questions:


  • Where do security vulnerabilities come from?
    • design and implementation flaws
  • What are some common bugs that cause problems: explain buffer overflows, perhaps, using Schneier that I pasted somewhere here.
    • 85 percent of bugs in CERT database are integer overflows, buffer overflows, input validation
  • Why do you write buggy code: tell me more specifically than the stock answer that "software is complex"?
    • human imperfections
    • unpredictable software behavior in different configuations on different machines, different inputs from users and software, different interactions creates exponential explosion in ways in which we expect our software to behave perfectly
  • Ok, how can you keep yourself from writing buggy code?
    • You can't, provably impossible for all but most simple programs. Wow, why is this true?-I still don't have my mind around this
  • But can't you test the stuff?
    • Testing will never catch all errors since you need to test for an unlimited number of possible things the software might do. If you want to keep your cat fenced up in your backyard, you have to anticipate all possible ways the wily cat might escape. You can climb on the roof and guess whether the cat would be willing to jump off it over the fence. You can crouch down and guess whether a cat can slink under the fence. And still, the cat will probably escape via the route you overlooked. It’s very hard to prove definitively that something is not going to happen, that the cat cannot possibly escape the yard, that a piece of software has no vulnerabilities.
  • Two other problems make building secure software extremely difficult and unique from other complicated engineering tasks
    • little correlation between the magnitude of error in the software and the problems that the error will cause.
    • The second problem is that software is constantly being probed for vulnerabilities by attackers because spectacular attacks can be carried out while incurring little cost—they require minimal skill and effort, and the risk of detection is quite slim.
  • How do you measure software quality and how useful are these different methods?
    • evaluating spec/design
    • evaluating the SE practices
    • testing, static analysis
    • NONE of these is a comprehensive solution