QinetiQ Proprietary

www.QinetiQ.com

AN ISO standard AN ISO standard for high integrity for high integrity

softwaresoftware

QinetiQ Proprietary

www.QinetiQ.com

ISO OWGVISO OWGV“Guidance to Avoiding Vulnerabilities in “Guidance to Avoiding Vulnerabilities in

Programming Languages through Language Programming Languages through Language Selection and Use”Selection and Use”

• The intent is to produce guidance

• a type 2 technical report, not strictly an ISO standard

• Begs the questions:

• What is a vulnerability?

• How will it address language selection?

• How will it address language use?

QinetiQ Proprietary

www.QinetiQ.com

ScopeScopeParaphrased from latest draft document

In Scope:

• Applicable to the computer languages covered in the document

• (Ada, C/C++, Fortran, MUMPS)

• Applicable to software production review and maintenance

• Applicable where assured behaviour is required

• security, safety, mission/business criticality

Out of Scope:

• Software engineering and management issues, e.g.

• Code design, configuration control, managerial processes

QinetiQ Proprietary

www.QinetiQ.com

What is a vulnerability?What is a vulnerability?

During the first meeting two distinct views on vulnerabilities emerged:

• The US view is primarily concerned with security and lead by DHS

• The ‘keynote’ speaker was Joe Jarzombek , DHS

• The chair and vice chair are funded by DHS

• A major contributor was CERT – with a DHS funded research programme into security issues

• The UK view was more based on:

• safety concerns (self and Rod Chapman, Praxis)

• General ‘computer science’ concerns (Brian Wichmann ex-NPL, Derek Jones – UK convener)

As can be seen in the scope statement, we were successful in arguing that both need to be considered

QinetiQ Proprietary

www.QinetiQ.com

Why this is important!Why this is important!

Benefits from a strong and agreed international standard (should be):

• Easier international purchasing

• suppliers and customers working to the same standards

• Potentially easier international sales

• developed to standards recognised by the customer

• Prevent/Reduce arguments with suppliers over what is necessary for high integrity software

but…

QinetiQ Proprietary

www.QinetiQ.com

RisksRisks

If too narrowly focused – say principally on security – may lead to the argument ‘this has been developed to ISO24772, so that should be good enough’

Hence important that all significant issues get incorporated

QinetiQ Proprietary

www.QinetiQ.com

Strategy from first meetingStrategy from first meeting

The first meeting was a gathering of ideas

Representatives from national bodies: US, UK, and Canada

ISO language standards: Ada, C, MUMPS, Fortran

Others: DHS

The chair’s desire was to identify and provide mitigations for all popular/represented software languages

The main aim was seen as to ‘raise the floor’ for all software development – particularly for those that are not aware that they are writing critical code (e.g. an application that has no critical function, but which contains a flaw that can be exploited by an attacker, because it is co-located with a critical system)

QinetiQ Proprietary

www.QinetiQ.com

Strategy from first meeting #2Strategy from first meeting #2

The aim would be aim to provide potential users (who may be company software policy/guideline writers, rather than programmers) with a list of issues (the vulnerabilities) and possible mitigations for each language, from which they can form policy

It is not intended that the standard would say:

For this sort of application use language X

For this sort of application, don’t use language Y

QinetiQ Proprietary

www.QinetiQ.com

‘‘Challenges’ to first meeting strategyChallenges’ to first meeting strategy

Given the effort that has gone into SPARK Ada, MISRA C/C++ etc., is ISO really capable of not only duplicating that effort – but extending it to more languages

Where issues are already addressed in subsets, such as SPARK or MISRA, how does ISO develop sensible guidance that doesn’t infringe IPR?

How do you get developers to adopt the guidelines, given that there is already a lot of guidance out there that isn’t being used (certainly enough to ‘raise the floor’)

QinetiQ Proprietary

www.QinetiQ.com

Revised strategyRevised strategy

Develop a generic list of vulnerabilities based around predictable execution

Provide annexes for each supported language that shows how the vulnerabilities manifest – together with an outline of what is necessary to avoid them

This addresses the level of effort required and IPR issues (by not trying to provide complete solutions within the guidelines) – but still making it clear that language X is going to cause you far more problems than language Y

As far as adoption is concerned, one possible US approach is to insist that all software purchased for federal programmes is compliant.

QinetiQ Proprietary

www.QinetiQ.com

Process and TimescalesProcess and Timescales

Submissions through national bodies – UK’s organised by BSI

Membership of the UK panel is open to all

Submissions can be position papers, discussion documents or specific proposed words for the final document

When agreed by the UK panel – added to the international panel database for consideration at that panel

International meetings planned:

July, Ottawa

October, Kona Hawaii

December, Pittsburgh

2008 (sometime) Netherlands

Originally planned for a draft release January 2008

– mid/late 2008 more realistic?

QinetiQ Proprietary

www.QinetiQ.com

Getting involvedGetting involvedVia the UK (BSI) feeder panel

contact the convener to get put on the mailing list

derek@knosoft.co.uk

Useful URLs:

ISO OWGV website

http://www.aitcnet.org/isai

CERT have draft C and C++ guidance:

https://www.securecoding.cert.org/confluence/pages/viewpage.action?pageId=637