In many organizations, the internal security professionals are adept at finding and responding to information about the latest vulnerabilities to the commercial software products employed within business critical systems under their supervision. A great many security resources, both online and printed, are available from Security Information Providers, ready to help explain and address the potential vulnerabilities of the known products, or the off-the-shelf vulnerabilities, as described in Chapter 6. However, those who are responsible for the security and integrity of your systems face two problems: (1) the hit-or-miss disclosure of vulnerabilities in commercial software, and (2) presence of unknown vulnerabilities in the custom (in-house developed) applications that connect to and run on the top of commercial software.

Most organizations can do very little about the hit-or-miss disclosure of vulnerabilities in the off-the-shelf software deployed throughout the business. Your organization must rely on the software provider to have initiated appropriate quality controls and security testing, and provide bug-fixes or patches as necessary.

In the case of custom (in-house developed) applications, some organizations conduct a thorough security review of the system by performing a multi-tier assessment application assessment that consists of four levels: secure coding assessment, component-level assessment, security architecture assessment, and policy compliance assessment. Each level provides a progressively higher level of assurance. The organization selects which level best fits its assurance need.

A secure coding assessment focuses on the implementation layer of the application to identify code-level vulnerabilities. It tends toward more of an audit of coding practices (especially if the organization conducts manual reviews). While a coding assessment often initially appears to be more valuable, most organizations soon find that such a review often fails to identify most deployment issues.

Component-level assessment focuses on both the structural flaws that impact the security of an application's physical architecture and implementation security vulnerabilities that spread through key architectural/structural components affecting the application's architecture. To identify these flaws, component-level assessment performs the discovery of architectural components, applications entry points, data access points, third-party services (including the runtime platform), and data flows between them.

Security architecture assessment focuses on validating that safeguards are meeting security objectives. This assessment level utilizes and further deepens analysis of the previous two assessment levels to identify component-level threats, vectors of attack into application, and safeguards. The next step is to perform an analysis to uncover the adequacy and efficiency of identified safeguards.

Policy compliance assessment focuses on validating that the application and processes deployed to build applications are in compliance with outlined security polices. It validates that security engineering principles are followed in identifying security controls required by security polices, and by utilizing the previous three assessment levels it establishes traceability links to policies. Any discrepancy is marked as a possible vulnerability.

This four-level assessment approach focuses at detecting and eliminating vulnerabilities. The first three levels of the assessment deal with formal artifacts, such as the source and binary code, or the system in operation, and involve automated search for known vulnerability patterns either by analyzing code or by testing the system in operation. It is important to mention that these are not simple patterns of text; vulnerability patterns describe a unit of behavior that usually includes one or more statements and a pattern rule that describes constraints for a data-flow path connecting those statements. Patterns can describe desired or undesired units of behavior. A pattern that describes an undesired unit of behavior is very often referred to as an antipattern; however, an antipattern that has security implications is referred to as security weakness or a vulnerability pattern. An example of a desired pattern associated with security would be an “authentication pattern,” while a vulnerability pattern from the same class would be an “authentication bypass.” Vulnerabilities that can be described by a pattern that can be recognized in one of the system views were referred to in Chapter 6 as discernable vulnerabilities.

Knowledge of identifiable vulnerability patterns can be embedded into automated tools that provide deep analysis of the formal artifacts or interact with the system in operation and detect potential vulnerabilities. Improvements to the entire cyberdefence ecosystem can be achieved when the knowledge of vulnerability patterns is developed independently of the tools, as machine-readable vendor-independent content that is accumulated, updated, accredited, and then distributed to multiple vulnerability analysis tools.

The SCAP Ecosystem [NIST SP800-126] described in Chapter 6, successfully addresses the exchange of knowledge related to the off-the-shelf vulnerabilities that is simply a record of a certain security issue in a certain version of a commercially available product. The description of the problem itself in SCAP is informal. A larger ecosystem for vulnerability management (beyond the current SCAP) has to involve machine-readable vulnerability patterns as content that can be consumed by code analysis tools and web scanning tools. As shown in Figure 1, SCAP could be extended to include formalized vulnerability patterns described in the following scenario:

The above scenario describes the current SCAP, and is illustrated at the bottom part of Figure 1. The next step is to go deeper into the nature of the vulnerability and describe it in terms of identifiable system facts in the form of a machine-readable vulnerability pattern. This new scenario is illustrated at the top part of Figure 1.

The researcher creates a machine-readable pattern, describing the vulnerability in terms of system facts. This pattern can be used to search for the same vulnerability in other systems by inspecting their elements and looking for the occurrences of the vulnerability pattern. The vulnerability pattern can be made available to other researchers and can be imported into a vulnerability analyzer tool. The difference between a SCAP-based vulnerability scanner and a vulnerability analyzer is that the input to the scanner is the inventory of the system, including its configuration settings, while the input to the analyzer is an internal representation of the system, the implementation facts, or some logical model of the system. The SCAP OVAL language addresses vulnerability scanners by providing a common machine-readable format for describing off-the-shelf vulnerabilities that can be imported into scanner tools that determine versions of products and product configuration settings. On the other hand, vulnerability analyzers must understand the internal logical elements of the products either by parsing the source code, or by reverse engineering the binaries, or by dissecting the communication protocols. When the vulnerability analyzer is available, it can process many more systems systematically, regardless of whether these systems are off-the-shelf or in-house, already deployed or still under development, while the SCAP-based scanner can only deal with known off-the-shelf commercial products and their configurations.

There are multiple existing approaches to the classification of software vulnerabilities, but they all suffer from the fact that they do not enable automation. Rather than focusing on the high-fidelity description of systems traceable to the artifacts (code, binaries or protocols), they focus on informal descriptions of vulnerabilities themselves.

It is important to understand that vulnerability patterns are described in terms of the system facts. Since many automated vulnerability detection tools utilize a proprietary internal representation of the system under analysis, their vulnerability patterns are wedded to their proprietary internal formats, which creates a technical barrier to sharing vulnerability patterns. The key contribution of the OMG Software Assurance Ecosystem is the vendor-neutral standard protocol for exchanging system facts, described in Chapter 11. This protocol can be used as the foundation for the vendor-neutral formalization of vulnerability patterns. This chapter provides the introduction into formalization of vulnerability patterns as vendor-neutral machine-readable content for analysis tools, while further practical details of this approach are discussed in Chapters 9, 10 and 11.

Current SCAP lacks the protocol for exchanging machine-readable vulnerability patterns. In order to introduce such protocol, descriptions of vulnerabilities must be first generalized and then formalized as vendor-neutral machine-readable vulnerability patterns so that they can be turned into a commodity, unlocked from proprietary tools into a normalized, interconnected ecosystem.

The Common Weakness Enumeration (CWE) project led by MITRE [CWE], [Martin 2007] gathered and generalized many known off-the-shelf vulnerabilities, including informal descriptions of some vendor-specific patterns as well as the existing theoretical classifications of vulnerabilities into a comprehensive catalog of software weaknesses. Formalization of informal descriptions of vulnerabilities into machine-readable vulnerability patterns has started by the Department of Defense (DoD) research project focused on developing formal white-box vulnerability patterns (i.e. patterns that are based on system facts) and linking them to informal descriptions from the CWE catalog. These patterns are referred to as software fault patterns (SFPs). SFP is described as a faulty computation, where the computation is defined by system artifacts such as code, database schemas, and platform configuration and, formalized as a fact-oriented statement, focusing at the characteristic structural elements (identifiable locations in some system views or footholds) and the necessary conditions for the connecting elements of code (the code path) that can be systematically determined by data-flow analysis tools. Computations and the corresponding discernable vocabulary for various system views was described in Chapter 4.

The vendor-neutral protocol for system facts used in this approach is defined in ISO 19506 Knowledge Discovery Metamodel (KDM) [KDM 2006], [ISO 19506], described in Chapter 11. The project focused at the faulty computations that directly cause injury or those that are related to failed safeguards. Figure 2 shows how vulnerability patterns are using the Knowledge Discovery Metamodel.

The SFP is a generalized description of a family of faulty computations in the software. SFPs map to multiple elements of the CWE in such a way that each individual CWE element in the family can be defined as a specialization of the SFP. A specialization of an SFP is characterized by the same generic foothold and same generic pattern rules, and may add one or more specific footholds and pattern rules. Thus the extent of the specialized SFP is the subset of the extent of the base SFP. The descriptions from CWE were used as a source of definitions of all the “faulty computations” in order to determine SFPs.

SFP descriptions consist of footholds (easily identifiable locations in the system that are necessary elements of the corresponding computations, and that can be detected by linear queries into the fact repository); and pattern rules (conditions that determine the rest of the computation between the footholds, and which typically require comprehensive control- and data- flow analysis to detect). Footholds are identifiable characteristics of certain common “steps” performed by software systems.

Certain sequences of steps are common to large families of systems. For example, such common sequences are related to input processing, authentication, access control, cryptography, information output, resource management, memory buffer management, and exception management. The catalog of faulty computations should focus on computations that are common to large families of systems. However, it should scale well to enable customization for a very targeted assessment. In order to express SFPs as identifiable footholds and associated pattern rules that enable grouping by specialization in a consistent, measurable, and comparable way, conceptual and logical models are developed that follow the fact-oriented approach described in Chapter 9 and focus on essential characteristics expressed as:

Multiple physical models can be automatically derived from the logical model for selected implementation and imported into existing analyzer tools.

A conceptual model of an SFP is presented in Figure 3. The conceptual model facilitates white-box definitions of SFPs. It removes any ambiguity from the SFP and focuses on white-box discernable properties of the vulnerability traceable to the program elements. Each pattern has a start and an end statement connected by a path constrained by particular conditions. The start statement determines the source of data, while the end statement determines the data sink and the complete pattern describes any computation between the start and end statements that propagates certain data properties satisfying the given end-to-end data condition associated with the computation. The start- and/or end- statement contain at least one identifiable foothold.

The logical model expands on the conceptual model to show how the computation is presented in the code and also to show what properties are taken into account when the code path is computed. The logical model adds concrete details to the definition of a “computation” and a “property” in white-box terms. The logical model in Figure 4 shows how the SFP patterns are further formalized to produce machine-readable SFPs by further mapping the corresponding elements to the standard protocol for representing system facts.

These models facilitate a certain structure of the definition of each weakness and provide a natural separation point between the definition of a weakness from the apparatus required to determine the corresponding computation (illustrated in Figure 5). This is the key to using weakness definitions as the common content for the multitude of weakness detection tools. In particular, Software Fault Patterns involve an Application Programmer Interface (API) to the control- and data flow analysis capabilities that search for the code path based on the start- and end-statement patterns and the conditions. The structure of the definition facilitates clustering based on specialization, which is essential for the process that creates a natural clusterization of the CWE based on the common footholds and conditions, outlined later in this chapter.

Vulnerability is defined as “a bug, flaw, weakness, or exposure of an application, system, device, or service that could lead to a failure of confidentiality, integrity, or availability.” It can therefore be technically interpreted as a computation that can be exploited to produce injury. Certain computations in the system are designed to mitigate the vulnerabilities. These computations and the corresponding mechanisms and “locations” in the code are called “safeguards.” A “faulty computation” is defined as either a computation that has direct injury or a computation that corresponds to an incorrect safeguard.

A “computation foothold” is an identifiable construct, an entry point, or an Application Programming Interface (API) call present at a specific location recognizable in the system's artifacts, which is a necessary element of the computation. Certain constructs in the code can directly cause injury under certain conditions. Such locations are footholds for the corresponding faulty computation sequences. Safeguards (as computation sequences) also have footholds related to the safeguard itself, as well as to the protected region. SFPs are elements of the catalog of the unique locations in the code associated with faulty computations that either directly cause injury or cause safeguards to be ineffective. Software Fault Patterns are parameterized by the concrete platform knowledge because the start- and end-statement often involve concrete system call signatures.

This viewpoint is constructive and systematic and therefore enables automation. A uniform viewpoint makes the SFP approach systematic and repeatable.

As the DoD research in this area is still on going, in the following sections of this chapter we present detailed views of a few SFPs arranged into natural clusters based on common footholds and conditions that could be further classified into two categories: safeguard and direct injury. The following sections illustrate the search for the identifiable footholds for the SFPs. The entire collection of 640 CWE elements was analyzed and grouped into clusters based on the common characteristics mentioned in the informal descriptions from CWE, then these characteristics were further analyzed to identify discernable footholds, if any.

To illustrate software fault patterns as machine-readable content we describe a single concrete SFP from the Tainted Input into Command (TIV) cluster. This SFP is a formalization of the CWE 134 “Uncontrolled Format String.”

The description of this weakness available in CWE is very informal; it reads as follows: “The software uses externally-controlled format strings in printf-style functions, which can lead to buffer overflows or data representation problems.”

The white-box content can be distilled from this description, under the guidance provided by the conceptual weakness model shown in Figure 3.

where “incorrectly validated” is defined through the following scenarios:

This content can be further formalized by the following statement in SBVR Structured English (further described in Chapter 10):