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.
(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.
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.
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.
We would cross-reference the vulnerability to other enumerations and taxonomies, such as CWE. The audience for this section is general.
This section adds detail to the generic description that is dependent upon the programming language in question. The audience for this section is general.
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.
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.
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.
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.)
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.
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:
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.
[Action 01-10 - Moore, Waggoner, Jones]: Produce a more complete proposal for Moore's "half-baked" idea for organizing the report.
B Factors that need to be covered in a proposed guideline recommendation
These are needed because circumstances might change, for instance:
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