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

 

 

 

 

 

Notes to Proforma

A. Business Relevance. That which identifies market place relevance in terms of what problem is being solved and or need being addressed.

A.1. Market Requirement. When submitting a NP, the proposer shall identify the nature of the Market Requirement, assessing the extent to which it is essential, desirable or merely supportive of some other project.

A.2 Technical Regulation. If a Regulatory requirement is deemed to exist - e.g. for an area of public concern e.g. Information Security, Data protection, potentially leading to regulatory/public interest action based on the use of this voluntary international standard - the proposer shall identify this here.

B. Related Work. Aspects of the relationship of this NP to other areas of standardization work shall be identified in this section.

B.1 Competition/Maintenance. If this NP is concerned with completing or maintaining existing standards, those concerned shall be identified here.

B.2 External Commitment. Groups, bodies, or fora external to JTC1 to which a commitment has been made by JTC for cooperation and or collaboration on this NP shall be identified here.

B.3 External Std/Specification. If other activities creating standards or specifications in this topic area are known to exist or be planned, and which might be available to JTC1 as PAS, they shall be identified here.

C. Technical Status. The proposer shall indicate here an assessment of the extent to which the proposed standard is supported by current technology.

C.1 Mature Technology. Indicate here the extent to which the technology is reasonably stable and ripe for standardization.

C.2 Prospective Technology. If the NP is anticipatory in nature based on expected or forecasted need, this shall be indicated here.

C.3 Models/Tools. If the NP relates to the creation of supportive reference models or tools, this shall be indicated here.

D. Any other aspects of background information justifying this NP shall be indicated here.

D. Conformity Assessment and Interoperability

D.1 Indicate here if Conformity Assessment is relevant to your project. If so, indicate how it is addressed in your project plan.

D.2 Indicate here if Interoperability is relevant to your project. If so, indicate how it is addressed in your project plan.