html5-img
1 / 12

AN ISO standard for high integrity software

AN ISO standard for high integrity software. 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?

mills
Télécharger la présentation

AN ISO standard for high integrity software

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. AN ISO standard for high integrity software

  2. 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?

  3. 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

  4. 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

  5. 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…

  6. 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

  7. 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)

  8. 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

  9. ‘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’)

  10. 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.

  11. 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?

  12. Getting involved • Via 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

More Related