Chapter 1 - Software Vulnerability Fundamentals
blog December 19th, 2006
Overview
This chapter sets the stage for the rest of the book. We explain software security vulnerabilities in terms of the violation of a software security policy, and discuss how such a policy is typically centered around the users’ expectations of confidentiality, integrity, and availability. We briefly outline why software auditing is important, and then explain the distinction between design vulnerabilities, implementation vulnerabilities, and operational vulnerabilities. Finally, we look at common threads tying together software vulnerabilities, such as input, data-flow, trust relationships, interfaces, program environments, and exceptional conditions.
External Resources
Matt Bishop’s Computer Security: Art and Science
Matt Bishop’s home page
Further Reading and Discussion
There are a few different approaches to explaining software security, but most software security literature roughly follows similar conventions. Our approach lines up closely in many respects with Matt Bishop’s, hence our references to his works. Definitely check out the presentations, articles, and papers available on his web site.
Other resources worth checking out include: Seacord’s Secure Coding in C and C++, McGraw’s Software Security: Building Security In, Howard and Lipner’s The Security Development Lifecycle, SecureSoftware’s CLASP standards, Microsoft’s Threat Modeling, and Ross Anderson’s Security Engineering. Also check out David Wheeler’s Secure Programming for Linux and Unix HOWTO.
One idea we introduce in this chapter is that software vulnerabilities can be thought of as a subset of the larger phenomenon of software bugs, which essentially equates to "security is a subset of reliability." We qualify it slightly, and don’t try to present it as a universal truth, but we do think it’s a valuable idea for explaining security vulnerabilities.
This is a generally accepted concept, but Howard and Lipner present a slightly different world-view in The Security Development Lifecycle, and we think there’s merit to it. We’ll add a link to their Venn diagram once we get a chance, but basically they isolate three concerns that affect overall software quality: privacy, security, and reliability. These are all subsets of overall software quality, and are mostly independent sets, but they do overlap with each other, and, furthermore, they can be at odds with each other. Auditing for privacy issues is something we’ve explored before in our day-to-day jobs, and it’s a slightly different challenge than auditing for security flaws. So, there’s definitely something to this idea, as privacy requirements aren’t really a subset of reliability requirements. We’ll have to mull over this one for a while and perhaps revisit it later.
McGraw more or less agrees with us in spirit, but he has strong ideas on proper nomenclature. McGraw defines the larger class of software quality problems as software defects. The defects with security ramifications are divided into bugs and flaws. Bugs are implementation vulnerabilities, and flaws are design vulnerabilities. We don’t adopt his terminology in our book for a number of reasons, but we probably agree with him far more than we disagree. Those who control the language control the debate, so, in so far as there is a debate, we’re a little hesitant to accept these new definitions. This will probably make for an interesting blog post at some point.
Another idea we introduce is that security issues can be explained and understood in the terms of a violation of a security policy, which ultimately works out to a violation of user expectations. We explain these expectations in terms of the CIA model. There are other ways to approach this which all probably have value. Microsoft uses the STRIDE model, and other authors use different taxonomies.
