PROPOSAL FOR A NEW WORK ITEM

Date of presentation of proposal: 2005-06-23	Proposer: ISO/IEC JTC 1/SC 22
Secretariat: ANSI (United States)	ISO/IEC JTC 1 N 3913

A proposal for a new work item shall be submitted to the secretariat of the ISO/IEC joint technical committee concerned with a copy to the ISO Central Secretariat.

Presentation of the proposal - to be completed by the proposer Guidelines for proposing and justifying a new work item are given in ISO Guide 26.

Title Guidance to Avoiding Vulnerabilities in Programming Languages through Language Selection and Use

Scope The guidance could be applicable to any software development project applying the programming languages considered in the TR. The advisability of applying the guidance would vary depending upon the criticality of properties such as safety, security or privacy. In addition to producing a Technical Report, it is possible that the working group might create recommendations for working groups that maintain the standards or specifications for the programming languages considered in the TR.

Purpose and justification - Any programming language contains constructs that are vague or difficult to use. 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. Finally, there are weaknesses in language constructs that can be exploited by attackers, for example, the now-famous "buffer overrun" attacks. As a result, software programs sometimes execute differently than was intended by their developers. These problems can have serious consequences for systems that are intended to implement integrity properties such as safety, security or privacy. Although the consequences may be less severe, there is also the cost of dealing with electronic vandalism enabled by vulnerabilities in programs that are not themselves intended to have high integrity properties. Successful treatment of these problems would result in the production of software codes that exhibit more predictable behav iour in execution. Although an ideal result is currently impractical, "predictable execution" is an ideal toward which we can strive. One criteria for selecting guidance for the report would be whether the guidance improves the predictability of execution. The purpose of this project is to prepare comparative guidance spanning a large number of programming languages, so that application developers will be better informed regarding the vulnerabilities inherent to candidate languages and the costs of avoiding such vulnerabilities. An additional benefit is that developers will be better prepared to select tooling to assist in the evaluation and avoidance of vulnerabilities. In developing the guidance, the project will prefer linguistic means of avoiding vulnerabilities but, when necessary may describe extra-linguistic means (e.g. static analysis or targeted testing). In developing the guidance, the project will prefer the avoidance of identified risks but, when necessary, may describe means to mitigate the risk of vulnerabilities that cannot be economically avoided. Finally, in cases where identified problems can be neither avoided nor mitigated, the report may assist users in understanding the nature of risk that must be accepted. The admission that some problems must be treated via analysis or testing introduces a secondary consideration in recommending linguistic means for avoiding vulnerabilities; in some situations, one construct might be preferred over another on the grounds that it is easier to test or easier to analyze. This relationship between construction and subsequent verification activities makes it clear that the report will be useful both for those emphasizing "correctness by construction" and those who desire to improve the predictability of execution through testing and analysis. Although a strict reliance on empirical evidence of effectiveness and quantified analysis of cost/benefit is not feasible, the project will be guided by both of those notions in its selection of guidance to be included in the report. Because of the dearth of quantifiable evidence, a cautious approach to incorporating guidance may be appropriate. A consequence of this observation is noted in the box labeled, "Preparatory work offered with target date(s)". Finally, the technical report may prove useful as a "registry" of vulnerabilities. For example, if the report provides unique names for identified vulnerabilities, then tool vendors could describe the range of effectiveness of their tools in terms of the names used by the report. Although this is not the primary intended purpose of the report, the project will consider catering to this usage.

Programme of work If the proposed new work item is approved , which of the following document(s) is (are) expected to be developed? ____ a single International Standard more than one International Standard (expected number: ........ ) ____ a multi-part International Standard consisting of .......... parts ____ an amendment or amendments to the following International Standard(s) .................................... __X__ a technical report , type ....3.......

Relevant documents to be considered The programming language standards of ISO/IEC JTC 1/SC 22. For market reasons, the specifications of popular languages that are not the subject of ISO standards. The software engineering standards of ISO/IEC JTC 1/SC 7, as a source of extra-linguistic mitigation methods. Existing documents providing usage guidance for individual languages, e.g. ISO/IEC TR 15942, MISRA C, NUREG/CR-6463. Standards dealing with functional safety, notably, IEC 61508. Existing work on safe programming approaches, e.g. the SPARK language, ISO/IEC draft TR 24731 (Specification for Secure C Library Functions) So far, the study group has assembled a list of 82 resources to be considered.

Cooperation and liaison The proposal recognizes that a normally constituted working group will not suffice to perform the necessary work. In addition, to the usual National Body participants, it is proposed to use experts appointed by each existing working group in JTC 1/SC 22, liaison experts appointed by other organizations maintaining programming language specifications, and liaison experts appointed by other standards committees maintaining related documents.

Preparatory work offered with target date(s) A web site provides a summary of progress to date: http://www.aitcnet.org/isai/. It is proposed to perform the work on the "normal" (36 month) schedule. However, it is recognized that the work may be performed in increments that subdivide the schedule or with refinements that would produce subsequent amendments or revisions.

Signature:

Will the service of a maintenance agency or registration authority be required? ......NO................ - If yes, have you identified a potential candidate? ................ - If yes, indicate name ............................................................. Are there any known requirements for coding? ......NO............... -If yes, please specify on a separate page Are there any known requirements for cultural and linguistic adaptability? .....None beyond those already implicit in the programming languages being treated....... - If yes, please specify on a separate page Does the proposed standard concern known patented items? ........NO........... - If yes, please provide full information in an annex

Comments and recommendations of the JTC 1 Secretariat - attach a separate page as an annex, if necessary

Comments with respect to the proposal in general, and recommendations thereon: It is proposed to assign this new item to JTC 1/SC 22

Voting on the proposal - Each P-member of the ISO/IEC joint technical committee has an obligation to vote within the time limits laid down (normally three months after the date of circulation).

Date of circulation: YYYY-MM-DD

Closing date for voting: YYY-MM-DD

Signature of JTC 1 Secretary: Lisa A. Rajchel

 

 

 

NEW WORK ITEM PROPOSAL - PROJECT ACCEPTANCE CRITERIA
Criterion	Validity	Explanation
A Business Requirement
A.1 Market Requirement	Essential _X__ Desirable ___ Supportive ___	Exploitation of software vulnerabilities is becoming an increasingly expensive problem.
A.2 Regulatory Context	Essential ___ Desirable ___ Supportive __X_ Not Relevant ___	Application of the guidance might be cited in warranties of fitness for particular purposes.
B. Related Work
B.1 Completion/Maintence of current standards	Yes _X__ No___	See explanation of "relevant documents".
B.2 Commitment to other organization	Yes _X__ No___	See explanation of "relevant documents" and "cooperation and liaison".
B.3 Other Source of standards	Yes _X__ No___	See explanation of "relevant documents" and "cooperation and liaison".
C. Technical Status
C.1 Mature Technology	Yes _X__ No___	Guidance has already been prepared for several individual languages. This proposal would provide a uniform approach supporting comparison among languages.
C.2 Prospective Technology	Yes ___ No_X__
C.3 Models/Tools	Yes _X__ No___	Tooling can be used for analysis of vulnerabilities or mitigation of their risks. Both roles are relevant to this work.
D. Conformity Assessment and Interoperability
D.1 Conformity Assessment	Yes ___ No__X_
D.2 Interoperability	Yes ___ No__X_
E. Other Justification