QinetiQ Proprietary AN ISO standard for high integrity software

QinetiQ Proprietary ISO OWGV “Guidance to Avoiding Vulnerabilities in Programming Languages through Language 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 Scope Paraphrased 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 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 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 Risks 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 Strategy 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 Strategy 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 ‘Challenges’ 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 Revised 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 Process 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 Getting involved Via the UK (BSI) feeder panel contact the convener to get put on the mailing list Useful URLs: ISO OWGV website CERT have draft C and C++ guidance: