View
215
Download
0
Tags:
Embed Size (px)
Citation preview
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
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