| Security knowledge can be organized according to the taxonomy introduced in the box Software Security Unified Knowledge Architecture. Seven knowledge catalogs (principles, guidelines, rules, vulnerabilities, exploits, attack patterns, and historical risks) are grouped into three knowledge categories (prescriptive knowledge, diagnostic knowledge, and historical knowledge). Two of the seven catalogs are likely to be familiar to software developers with only a passing familiarity with software securityvulnerabilities and exploits. These catalogs have been in common use for quite some time and have even resulted in collection and cataloging efforts serving the security community.[3] Similarly, principlesstemming from the seminal work of Saltzer and Schroeder [1975]and rulesidentified and captured in static analysis tools, such as ITS4 (see Appendix B)are fairly well understood. Knowledge catalogs only more recently identified include guidelines (often built into prescriptive frameworks for technologies such as .NET and J2EE), attack patterns [Hoglund and McGraw 2004], and historical risks. Together, these various knowledge catalogs provide a basic foundation for a unified knowledge architecture supporting software security. [3] Mitre's CVE <http://www.cve.mitre.org/>, the CERIAS database <https://cirdb.cerias.purdue.edu/coopvdb/public/>, and CERT's alert data <http://www.cert.org> are three popular collections.
Software Security Unified Knowledge Architecture Figure 11-1 shows a basic software security knowledge schema relating the seven catalogs. Figure 11-1. The basic schema displayed here shows one way to organize and interrelate software security knowledge. There are seven distinct knowledge catalogs, which can be divided into three knowledge categories. 
The category prescriptive knowledge includes three knowledge catalogs: principles, guidelines, and rules. These sets span a continuum of abstraction from high-level architectural principles at the level of philosophy (e.g., the principle of least privilege [Saltzer and Schroeder 1975]) to very specific and tactical code-level rules (e.g., avoid the use of the library function gets() in C). Guidelines fall somewhere in the middle of this continuum (e.g., make all Java objects and classes final(), unless there's a good reason not to [McGraw and Felten 1999]). As a whole, the prescriptive knowledge category offers advice for what to do and what to avoid when building secure software. The category diagnostic knowledge includes three knowledge catalogs: attack patterns, exploits, and vulnerabilities. Rather than prescriptive statements of practice, diagnostic knowledge helps practitioners (including operations people) recognize and deal with common problems that lead to security attack. Vulnerability knowledge includes descriptions of software vulnerabilities experienced and reported in real systems (often with a bias toward operations). Exploits describe how instances of vulnerabilities are leveraged into particular security compromise for particular systems. Attack patterns describe common sets of exploits in a more abstract form that can be applied across multiple systems. Such diagnostic knowledge is particularly useful in the hands of a security analyst, though its value as a resource to be applied during development is considerable (e.g., consider the utility of attack patterns to abuse case development). The category historical knowledge includes the knowledge catalog historical risks and, in some cases, vulnerabilities (e.g., the collection in the CVE <http://www.cve.mitre.org/>). Rather than derivations or abstractions, this catalog represents detailed descriptions of specific issues uncovered in real-world software development efforts and must include a statement of impact on the business or mission proposition. As a resource, this knowledge offers tremendous value in helping to identify similar issues in new software efforts without starting from scratch. It also provides a continuing source for identifying new instances of other knowledge catalogs described here: principles, guidelines, rules, vulnerabilities, and attack patterns. |
Table 11-1 provides a bird's-eye view of each knowledge catalog. Each entry includes a brief description, a sample schema for tracking instances, and a short list of software artifacts (arising from most software lifecycles) that the knowledge impacts the most. The idea here is to create a number of inter-related catalogs for use throughout the software lifecycle. Table 11-1. A Bird's-Eye View of Software Security Knowledge CatalogsKnowledge Catalog | Description | Sample High-Level Schema | Relevant SDLC Artifacts |
|---|
Principles | A principle is a statement of general security wisdom derived from experience. Though principles exist at the level of philosophy, they stem from real-world experience building secure systems. Principles are useful for both diagnosing architectural flaws in software and practicing good security engineering. | Title Definition (1..n) Description Examples Reference
Related guidelines Related rules
| Security requirements Software architecture Software design
| Guidelines | A guideline is a recommendation for things to do or to avoid during software development, described at the semantic level. Guidelines exist for a specific technical context (e.g., J2EE, .NET, Linux kernel module, and so on). Guidelines are best enforced and evaluated through human analysis. Guidelines can help uncover both architectural flaws and implementation bugs. | | Security requirements Software design Code
| Rules | A rule is a recommendation for things to do or to avoid during software development, described at the level of syntax. A rule can be verified through lexical scanning or constructive parsing of software (source or binary). Rules exist for specific programming languages (e.g., C, C++, PHP, Java, and so on). Rules can help uncover implementation bugs. | | | Attack patterns | An attack pattern is a generalized pattern developed by reasoning over large sets of software exploits. Attack patterns are useful for identifying and qualifying the risk that a given exploit will occur in a software system. They are also useful in designing misuse and abuse cases and specific security tests. | | | Historical risks | A historical risk is a risk identified in the course of an actual software development effort. At its core, a risk is a pairing of a condition/event with a quantification of the likelihood that it will occur and a quantification of the impact it will have. Historical risks are good resources for early identification of potential issues in a software development effort, for potential clues to effective mitigations, and for improvements to the consistency and quality of risk management in the software development process. | Title Type (business/technical) Subcategory (taxonometric sorting) Author Owner Project Risk status Likelihood Impact Severity Risk context Risk description Realization indicators Impact description Estimated impact date Potential cost Contingency plan/workaround Related business goals Related risks Related mitigations Diagnostic methods
| Software architecture Software design Test plans Deployed software
| Vulnerabilities | A vulnerability is the result of a defect in software that can be used by an attacker to gain access to or negatively affect the security of a computer system. | Context description (platform, OS, language, application, version, and so on) Title Description Severity Vulnerability type Loss type Reference
| Code Software architecture Software design Penetration tests Fielded system
| Exploits | An exploit is a particular instance of an attack on a computer system that leverages a specific vulnerability or set of vulnerabilities. | Context description (platform, OS, language, application, version, and so on) Title Description Preconditions Motivation Exposure type Exploit code Blocking solution Related vulnerabilities
| Penetration tests Fielded system
|
Work on fleshing out the knowledge catalogs identified here has been underway for some time by various groups. Makers of static analysis tools have pushed the envelope when it comes to rules, for example, while work sponsored by the Department of Homeland Security (and carried out by Cigital and SEI) has focused on principles and guidelines. The results of these efforts are available on the Web at <http://buildsecurityin.us-cert.gov/portal/> and should prove very useful for software security practitioners. More on the DHS effort can be found later in this chapter. |
