Proposal for Vulnerability Descriptions

This proposal is produced in response to Action Item 01-10 from Meeting #1 of OWGV. The relevant source material is quoted in the Appendix to this proposal.

This is not a proposal for the gross organization of the document to be produced by OWGV. It is assumed that the gross outline will serve to organize a set of vulnerability descriptions. This proposal suggests an outline for the individual vulnerability descriptions. Different parts of the proposed outline should appeal to different audiences, as explained below.

Proposed Outline of a Vulnerability Description

Generic description of the vulnerability

(Depending on the overall organization of the document, this might occur at a level higher than the individual vulnerability description.) The audience for this section is general.

Categorization

At the moment, I don't know what these categories are, but I'm sure that we will want to categorize vulnerabilities in some way. The audience for this section is general.

Language and dialect

This section will explain to which languages (and dialects of those languages) this description is applicable. Implementation dependency would also be discussed here. (Depending on the overall organization of the document, this might occur at a level higher than the individual vulnerability description.) The audience for this section is general.

Cross-references to enumerations, etc.

We would cross-reference the vulnerability to other enumerations and taxonomies, such as CWE. The audience for this section is general.

Specific description of the vulnerability in the context of the language

This section adds detail to the generic description that is dependent upon the programming language in question. The audience for this section is general.

Coding mechanisms for avoidance

This section would provide coding examples, including examples that have the vulnerability and examples that avoid the vulnerability. The description would consider the effectiveness of the various code work-arounds that are offered.

The audience for this section would be programmers and those who perform quality assurance activities on code. Tool-makers might also be interested.

Analysis mechanisms for avoidance

For vulnerabilities that cannot be avoided by coding, and for those situations where a code-based solution is undesirable, this section discusses analysis techniques for avoiding the vulnerability. It would consider different types of analysis (perhaps drawing on the categories in TR 15942) and their effectiveness in finding and avoiding the vulnerability. The audience for this section would be tool-makers and those who use the tools.

Other mechanisms for mitigation

For vulnerabilities that cannot be avoided--by either coding or analysis--this section discusses other prospects for locating and mitigating the vulnerability. The text might recommend specific review techniques or dynamic techniques (such as testing and simulation) to search for and mitigate vulnerabilities. The audience for this section would be those performing verification, validation, quality assurance and safety/security planning. In addition, those who need to estimate the cost of mitigation would be in the audience.

Nature of risk in not treating - supporting use by risk managers

Sometimes it is not practical or cost-effective to avoid or mitigate a vulnerability. This section would describe the nature of the risk that must be accepted and the nature of the threats and/or hazards against which the software cannot be defended. The relationship to application security techniques might be discussed here. The audience for this section would include risk managers, those who effect the transition of systems to operation, acquirers, regulators, and operators.

(In the preceding sections, you see that there is a progression of risk treatment mechanisms that start with the small and local, but end with the large and global. As we progress down the list, the concerned audience grows larger and becomes less technical and more managerial.)

Profiles

In addition to the descriptions of the vulnerabilities, the document may want to "profile" collections of vulnerabilities for various purposes. For example, the profile for a system in a relatively secure environment, which does not contain confidential information, and which offers no safety implications might have a different profile than a system that is connected to the internet, contains classified data, and which has safety implications. Profiles might allow us to treat raise-the-floor/raise-the-ceiling differences.

Appendix: Relevant Source Material

Extract from Minutes of OWGV Meeting #1:

Moore offered a "half-baked" idea for finessing the audience/usage issue. The report would be a list of vulnerabilities, annotated in various ways such as the following: Alternative coding - supporting use by coders and by verifiers Other mechanisms for avoidance - supporting use by those who choose tools Other mechanisms for mitigation - supporting use by verifiers and supporting use by those who are estimating cost of mitigation Nature of risk in not treating - supporting use by risk managers Others Different annotations would support different forms of usage, hence different audiences. Audiences could be added from time to time by incorporating additional annotations. Jones noted that Annex B of UK document addresses this subject. [snip] [Action 01-10 - Moore, Waggoner, Jones]: Produce a more complete proposal for Moore's "half-baked" idea for organizing the report.

Extract from UK Proposed Base Document at OWGV Meeting #1:

B  Factors that need to be covered in a proposed guideline recommendation B.0 These are needed because circumstances might change, for instance: Changes to language definition. Changes to translator behavior. Developer training. More effective recommendation discovered. B.0.1  Expected cost of following a guideline How to evaluate likely costs. B.0.2  Expected benefit from following a guideline How to evaluate likely benefits. B.1  Language definition Which one to use. For instance, an ISO Standard, Industry standard, a particular implementation. Position on use of extensions. B.2  Measurements of language usage Occurrences of applicable language constructs in software written for the target market. How often do the constructs addressed by each guideline recommendation occur. B.3  Level of expertise How much expertise, and in what areas, are the people using the language assumed to have? Is use of the alternative constructs less likely to result in faults? B.4  Intended purpose of guidelines For instance: How the listed guidelines cover the requirements specified in a safety related standard. B.5  Constructs whose behavior can vary The different ways in which language definitions specify behavior that is allowed to vary between implementations and how to go about documenting these cases. B.6  Example guideline proposal template B.6.1  Coding Guideline Anticipated benefit of adhering to guideline Cost of moving to a new translator reduced. Probability of a fault introduced when new version of translator used reduced. Probability of developer making a mistake is reduced. Developer mistakes more likely to be detected during development. Reduction of future maintenance costs.