| ISO/IEC JTC 1/SC 22/OWG:Vulnerabilities |
Jim Moore, James.W.Moore@ieee.org |
|
This set of
frequently asked questions and answers was originally based on
[22-OWGV-N0024].
Last update: 26 September 2006 following decisions made a Meeting
#2.
The intent of the project is to write a document containing guidance to users of programming languages on how to avoid the vulnerabilities that exist in the programming language selected for a particular project. Implicitly, the guidance may also be helpful in selecting a language for a particular project. Finally, the report may be helpful in choosing tooling to assist in evaluating and avoiding vulnerabilities.
[Tentative - subject to discussion.]
"A flaw in a product that makes it infeasible, even when using the product properly, to prevent an attacker from usurping privileges on the user's system, regulating its operation, compromising data on it, or assuming ungranted trust."
-- From Microsoft, "Definition of a Security Vulnerability": http://www.microsoft.com/technet/archive/community/columns/security/essays/vulnrbl.mspx?mfr=trueSome standards documents contain "normative" provisions - requirements that a user must obey in order to be allowed to make a claim of conformance to the standard. This document will not contain such provisions; it will contain only information and suggestions for users.
No. When one considers a number of vulnerabilities, the severity of their consequences may vary and the resource necessary to avoid them or mitigate their consequences may also vary. Users need to make an informed selection of vulnerabilities to be treated based on the need of the system and its component software to preserve critical properties and the cost of preserving those properties.
Of course, we hope that all software works correctly. However, consequences of system failure can be particularly severe when the failure compromises safety, security, or privacy. These are examples of critical properties. A critical property is a property of system and its component software that must be preserved in order to avoid failures that present unacceptably severe consequences. A software component might not have been intended to preserve a critical property when it was developed; sometimes criticality is introduced because of the way in which the software is used or the system into which it is integrated.
Well, there's the obvious fact that software is now being used in more devices, including devices with critical properties. In addition to this, the increasing connectivity provided by the internet increases the vulnerability of all software. An intruder can attack any piece of software that is executing on a machine, and then use that software as a springboard to attack other software on the machine or on the network. So it becomes important to decrease the vulnerability of all software - even software with low criticality.
No, there will always be software where additional development effort is justified to increase safety, security, or privacy. However, it is now appropriate for all software to exhibit greater resistance to attack and exploitation.
Any programming language contains constructs that are vague or difficult to understand, use, or analyze (hence affecting coders, compiler writers, and tool developers.) Many language definitions include "implementation dependencies" that can affect their semantics in different execution environments. There is a set of "common mode" failures that occur across a variety of languages, for example, problems with pointers. Finally, there are weaknesses in constructs provided by particular languages, for example, "buffer overflow" in C. There was a time when many of these weaknesses might have been regarded as benign. In a connected world, though, the weaknesses can be exploited by attackers. "buffer overflow" is simply the most famous example.
The general idea is that a particular program code should execute the behaviour that the programmer intended, even when stimulated in unanticipated ways by external parties or events. We call this property "predictable execution". We will consider providing guidance on a feature of a programming language if that guidance can serve to reduce the amount of knowledge needed to predict execution, hence improving the predictability of execution of program codes containing the feature.
The goal is to provide guidance helping coders improve the predictability of the execution of their code, even in the face of attempted exploitation. Complete success is infeasible, so the goal of fully predictable execution represents an ideal. Nevertheless, practical guidance can help to reduce the frequency and the consequences of successful attack.
The plan is to organize the report by type of vulnerability along with generic discussion of the nature of the vulnerability. Then the Technical Report would describe how each type of vulnerability manifests itself in various programming languages. For each language the report would contain an annex providing techniques for avoiding the vulnerability or guidance for mitigating its ill effects. Of course, cross-referencing may cater to other forms of usage.
In the simplest of cases, the report will suggest alternative coding patterns that are equally effective but which avoid the vulnerability or which otherwise improve the predictability of execution. When that is not possible, the report may suggest the use of static analysis techniques and may provide guidance for coding in a manner that will improve the effectiveness of the analysis. When static analysis is not feasible, the report may suggest the use of other testing or verification techniques. Whenever possible, the report will assist users in understanding the cost and benefits of avoiding risks and the nature of any residual risks.
No. In some cases, it may be difficult to avoid the vulnerability through coding techniques. One might have to rely on static analysis or testing in order to evaluate the vulnerability. In some cases, though, naively coded constructs cannot be effectively analyzed. In such cases, it may be preferable to design the program in a particular way - not because it avoids the vulnerability - but because it allows the analysis or testing to be performed more effectively. A balanced approach to dealing with the vulnerabilities will involve design, construction, testing, verification and risk management.
Two products are envisioned. One is a Type 3 Technical Report [but see the next FAQ] intended for users of programming languages. The Technical Report will contain guidance explaining different kinds of vulnerabilities and how they can be avoided in different programming languages. The second product might be liaison with the standards committees responsible for programming language standards regarding issues that might be examined in their languages.
The most important point is that it is not a standard. ISO/IEC JTC 1 develops two types of documents: standards and technical reports--three types of them. A Type 3 Technical Report is a document that is inherently unsuitable to be a standard. The planned document precisely fits that category because it will not include normative provisions.
[This decision is tentative. There is some support for writing a Type 2 TR. This type of document can be regarded as a "trial use" standard.]
Ideally, yes. However, in many areas empirical data is simply not available and the collective judgment of experts may be used.
Currently, there are various non-ISO efforts underway (some represented in the OWGV) to identify and categorize vulnerabilities and other forms of weaknesses. These projects involve a partnership among developers, tool makers and users to provide common names to vulnerabilities and weaknesses, permitting parties to communicate about their nature. The project hopes to build upon these efforts. If all else fails, we might have to develop an ad hoc list based on the judgment of the working group.
Any of the programming languages maintained by JTC 1/SC 22 are candidates. Also, popular languages maintained by groups outside ISO are also candidates, e.g. C# and Java. The working group will have to make a cost/benefit judgment regarding which languages to include. This judgment will depend, in part, upon the ability to obtain participation by experts in those languages.
In some cases, programming language vulnerabilities cannot be feasibly avoided. In such cases, one might apply other software engineering, risk management, or safety engineering techniques to deal with the problem. The software engineering standards of ISO/IEC JTC 1/SC 7 may be relevant in this area, as well as the functional safety standard, IEC 61508.
As is normally the case, the Technical Report will have to be approved by a consensus of national bodies. Therefore, participants in the working group will be representatives of those NBs. However, it is clear that this group will need additional sources of expertise. Therefore, the working groups of SC22 have also been asked to name experts to participate in the group. We are also seeking to establish liaisons to provide experts for non-ISO languages.
The tentative schedule for the work is:
A web site provides a summary of progress to date: http://www.aitcnet.org/isai/
| Disclaimer | Most of the items contained in this web site and its associated files and directories are preliminary working material of ISO/IEC JTC 1/SC 22, subject to review and correction. |
The web site is maintained for the convenience of the participants in SC 22/OWG:Vulnerabilities by:
James W. Moore, The MITRE Corporation, 7515 Colshire Drive, McLean, VA 22102, +1.703.983.7396, moorej@mitre.org, James.W.Moore@ieee.org.