The SSEI is currently undertaking a task to provide guidance for designing and implementing software for use in systems complying with Defence Standard 00-56 Issue 4. One of the major principles of this standard is an emphasis on the evidential approach to safety. This approach requires the provision of a compelling safety argument, supported by rigorous evidence, to justify the inclusion of all software.
Thales have provided a case study (the CIPHER project) to assist in validation of the Initial stage of software development (as shown in the swim-lane diagram of Section 2). The relevant decisions which the Thales personnel were asked to consider include selecting a supplier, and setting acceptance criteria. In addition, where possible, they have provided information on the preliminary activities involved with structuring a safety case to meet the requirements of Def Stan 00- 56.
A.6.1 CIPHER Introduction
The CIPHER project, is run by a consortium of companies led by Thales UK. CIPHER is intended to deliver the future MOD crypto capability and sustain current capabilities until the out of service date (OSD) of current devices is met or a replacement capability is available. CIPHER brings together a number of existing projects within the Defence Cryptographic Authority DCA and looks to manage them to produce a coherent capability for future crypto equipment and support.
The Interoperable Electronic Key Distribution (IEKD) project and the Future Crypto Programme (FCP) separately passed Initial Gate (IG) in August 2007, but have been combined within CIPHER due to their interconnected nature, the synergies in taking a single capability approach and the possibility that future crypto and its management could be provided under common service arrangements. In addition, the CIPHER project is intended to address the requirements of the Security Management Infrastructure (SMI) project.
Currently, the Thales consortium is in the assessment phase for the CIPHER project. Down-selection and Main Gate approval for CIPHER are planned for 31 December 2010 with an Initial Operational Capability by 2012 and a Full Operational Capability by 2015.
A.6.2 Suppliers and Standards
The CIPHER project extends across land, sea and air domains, and consequently there are in excess of 60 platform types which require crypto capability. The intention is to rationalise the present number of crypto devices, but because there are domain specific issues, it is highly likely that a large number of sub-contractors
will be required to both provide the necessary capability in terms of equipment, bearer infrastructure and associated expertise. The extent of the software requirement will depend upon the amount of COTS is employed, the extent to which it needs to be modified and the degree of functionality and performance is required. At this stage of the project, all of these facets are under consideration, so the extent to which new software is required and its degree of integrity have yet to be determined. However, it is not unreasonable to expect that some software will be required to enable functionality of specific crypto devices, the management of crypto keys and the overall control and administration of CIPHER. The system integrity requirements will depend upon meeting both safety and security requirements.
The primary safety standard applicable on the CIPHER project is Def Stan 00-56 Issue 4, which will be applied to sub-contractors. However, it is expected that other safety standards will have to be assessed for their ability to comply with Def Stan 00-56, particularly where COTS is procured from overseas. The Safety and Environmental Plan contains a complete list of anticipated standards to cover safety, environmental, and where necessary international requirements of the project. This question of using other standards to comply with Def Stan 00-56 is addressed in Section 4.2 and has also informed some of the criteria in Section 2.4.2.
The safety requirements for CIPHER are likely to be unique because of the complexity of a system, which needs security and safety to be harmonised across multiple platforms and multiple operating environments. So, whilst the consortium has an existing Safety Management System from Thales, it is proposed to take advantage of a number of ongoing developments in the UK within the system safety domain. The consortium would like to determine – with the Authority – what opportunities these developments may offer to benefit CIPHER.
A.6.2.1 Supplier Assessment
The CIPHER project has not yet entered a formal stage of supplier assessment. A number of potential suppliers have been approached, but there is as yet no formal relationship (i.e. contractual or pre-contractual agreements) with these potential suppliers. The information contained in this section is therefore obtained from the CIPHER Safety and Environmental Plan (SEMP).
When selecting a COTS component for use in a system, the intent is to select the candidate which most nearly satisfies all requirements, including safety requirements. Because performing tests on all candidates can be time-consuming and expensive, existing evidence can be used to estimate the component’s ability to meet safety requirements. Existing evidence is evidence about the safety of the COTS component which is obtained from the vendor or other third parties. Existing evidence therefore encompasses the following types:
Certification packs provided by the vendor
Test results, lifecycle data, development information or product analyses provided by the vendor (not necessarily in the form of a certification pack)
Third-party testimonials
Historical (in-service) evidence.
The CIPHER project anticipates the use of some or all of these forms of existing evidence. Further analysis of this topic is provided in Section 4.1 and previous SSEI work [4], in which we propose a gap analysis to determine the sufficiency of such existing data.
In terms of assessing supplier capability, the CIPHER project will depend heavily upon their previous track record together with any previous experience of working together. This is reflected in the Comparator Data of section 2.4.2, as well as the discussion of supplier track record in Annex A.4.1. Third party testimonials may also be utilised, however, CIPHER is not sufficiently advanced as a project to provide specific instances or examples.
Capability assessments are another method of determining the ability of suppliers to carry out the proposed work. Thales is dedicated to progressing through CMMI accreditation with various business units having achieved differing levels of CMMI accreditation. This reliance on CMMI has informed the guidance of Annex A.4.1. In dealing with external suppliers, Thales recognises that CMMI can apply on both a capability and maturity axis. That is, CMMI assess the ability of the supplier to carry out the work, as well as the maturity of the processes which are proposed. However, the CIPHER project has not yet determined what levels should apply to both axes, and this will almost certainly depend upon the service being supplied. Whilst CMMI is the Thales preferred capability assessment, this is not the case across all countries and projects. In particular, personnel involved with the CIPHER project have stated that latitude will be given for accepting alternative methodologies. To reflect this experience, this guidance does not recommend the use of a particular capability assessment.
Another form of assessment, mentioned briefly above, is the use of domain and safety experts. Because of the complexity of the CIPHER system, this project requires significant domain expertise across all aspects of secure data transfer provision in order to assess suppliers and tenders. This guidance addresses the input which may reasonably be expected from domain and safety experts in Section 2.4.2 and Annex A.4.1. In particular, domain experts may provide invaluable input when considering the credibility of supplier claims.
A.6.2.2 Safety Considerations and Visibility
Thales personnel have indicated that traditionally, for projects which are not safety-critical, safety has tended to be considered at a later stage of the project
than might be ideal. However, CIPHER has been determined from the outset to fully involve safety expertise in all aspects of the project and develop a greater emphasis on safety culture within the project. This emphasis on safety has highlighted some areas of conflict which might otherwise have gone undetected. As a result of this experience, the need for safety assessment throughout project development has been stressed in this guidance. The swim-lane diagram of Section 2.4.2 is intended to enforce safety considerations, beginning in the Initial phase.
Thales personnel were also asked about the importance – and credibility – of an indication by suppliers of the level of visibility into their development processes. The judgement - from experience in previous projects, as the CIPHER project is not yet at this stage – is that this greatly depends upon the complexity and integrity of the component or system being procured. Generally, the higher the integrity or complexity, the greater the need for visibility of development and safety management processes, including invitations to participate in internal safety reviews and witness testing, etc. Most reputable suppliers are keen to demonstrate these facets to their customers, although experience has also shown that where COTS is concerned, this level of visibility is more difficult to obtain. This guidance discusses the need for determining the level of visibility proposed at an early stage. It is assumed from this response that – although the level of visibility provided may not be ideal – in general, it is expected that the supplier will indicate the transparency of their processes. Section A.4.1 contains more information on this.
A.6.2.3 Assessment of Tenders
This section contains information obtained from Thales personnel about the methods which will be used on the CIPHER project to assess tenders. Where CIPHER-specific information is not available (for reasons of security, or because of the current stage of the project), recommendations have been given based on previous development experience at Thales.
To date no Invitations To Tender have been published on the CIPHER project. However, it is anticipated that the content of the requested information within the ITT would be specific to the system or component in question. Smaller components would be expected to provide safety data sheets, whilst larger components and systems would need to provide safety cases with relevant supporting safety documentation. In this guidance we have indicated some of the relevant inputs which may be expected for a tender (Section 2.4.2), but stress that this is not intended to be an exhaustive list.
Certain aspects of a tender must be able to show conformity or an intention to conform to relevant statutory requirements. In addition, for the CIPHER project there may well be additional contractual requirement place upon Thales by its
customers, which in turn have to be met by sub-contractors. As a result, sub- contract management on the CIPHER project may be undertaken by specialist staff dedicated to ensuring that a consistent approach is taken across all sub- contractors
In terms of the additional information which might be expected in a tender, Thales personnel have indicated this is again completely dependant upon the service being requested. As discussed in Annex A.3, it is important to realise that an ITT will be seeking a lot more information other than purely safety information.
In Section 2.4.2 we discuss some relevant comparator data for assessing tenders. From a safety perspective, the primary means of assessing a tender on CIPHER is intended to be via a questionnaire. However, Thales personnel stress that it must be understood that safety is but one criterion under assessment. There will be many other factors which determine whether a tender is accepted such as ISO 27001 accreditation and the ability for the supplier to provide fully trained, and qualified support through the life of the project. As a consequence, this guidance emphasises that comparator data may originate from a wide range of sources (Section 2.1).
A.6.3 CIPHER recommendations
One of the major points which came out of the Thales response is the need to consider issues which are not necessarily related to safety when selecting suppliers. That is, there are many criteria which determine the suitability of a potential supplier and whilst safety is an important consideration, it is not the sole consideration, and is not always the primary consideration.
Other SSEI tasks (e.g. Task 2 and Task 3) are intended to consider the importance of the supply chain, and the difficulties involved in managing the flow of information over contractual boundaries. These difficulties can sometimes give rise to the need to “trade-off” safety for other properties, such as security. As a consequence of the Thales response, it is anticipated that the SoBP – although a document which has a primary focus on software safety – will be informed by the consideration of these issues. In particular, there is a need for further guidance and case studies on the ways in which the trade-off between safety and other parameters can be adequately addressed at the stage of tender assessment.
The following Annexes are taken from previous SSEI work as listed in the references. They may be subject to updates.
ANNEX B Technical SoBP
This Annex contains the full version of the Technical SoBP, intended to support the summary provided in Section 3. The Technical SoBP provides guidance of relevance to anyone involved in the development or assessment of safety arguments for software in the context of Def Stan 00-56. The material is drawn from the SSEI deliverable “A Systematic Approach to Software Safety Argument Construction” [6]. All references in this Annex are to internal sections and citations are to the list of references in Annex B.6.
EXECUTIVE SUMMARY
Creating safety arguments for the software aspects of safety related or safety critical systems has the potential to bring many benefits over a more traditional prescriptive approach. Constructing compelling software safety arguments can however be challenging, and there is considered to be cur- rently a lack of guidance available.
This report helps to address this need by describing a systematic ap- proach to the construction of software safety arguments. This approach is based upon an extended argument construction method which explicitly considers assurance throughout the development of the software safety argument. This methodology is supported by a software safety argument pattern catalogue which proposes clear and coherent structures for soft- ware safety arguments through which it is easier to demonstrate that the resulting argument is sufficiently compelling.
INITIAL DISTRIBUTION
Name Role/Organisation Location
John McDermid SSEI Technical Director, (Uni-
versity of York)
York
Sqd Ldr Mike
Place
SSEI Customer Interface Di- rector, (MOD, DE&S)
Abbey Wood
Rob Brockie SSEI Contract Holder, (BAE
Systems, MAS)
Warton
Jane Fenn SSEI Programme Manager,
(BAE Systems, MAS)
VERSION HISTORY
ChangeNo.
Incorporated By: Date Reason
Issue 1
Draft A
Richard Hawkins December
2008
First Release
Issue 1
Draft B
Richard Hawkins December
2008
Updated in response to comments
Issue 1 Richard Hawkins January
2009
First issue
Issue 2
Draft A
Richard Hawkins May 2009 New version created to re-
flect comments received in response to SoBP
Note to users:
Contents
1 INTRODUCTION 110
2 SOFTWARESAFETY ARGUMENTS 111
2.1 The challenge of software safety argument construction . . 113 2.2 The nature of safety arguments . . . 114 2.3 An assurance-centric view of software safety arguments . . 118
3 CONSTRUCTINGSOFTWARE SAFETYARGUMENTS 120
3.1 Extending the six-step method - An assurance-based ap- proach . . . 121
3.1.1 Step 1 - Identify goals . . . 123
3.1.2 Step 2 - Define basis for goals . . . 125
3.1.3 Step 3 - Identify strategy . . . 126
3.1.4 Step 4 - Define basis for strategy . . . 128
3.1.5 Step 5 - Elaborate strategy . . . 131
3.1.6 Step 6 - identify solutions . . . 131
3.2 Addressing Assurance Deficits . . . 139
4 SOFTWARESAFETY ARGUMENTPATTERNS 143
4.1 An introduction to argument patterns . . . 143 4.2 Modular extensions to GSN . . . 147
4.2.1 The use of modular GSN in software safety arguments147
4.3 A software safety argument pattern catalogue . . . 150
4.3.1 High-level software safety argument pattern . . . 151
4.3.2 Software contribution safety argument pattern . . . . 156
4.3.3 SSR identification software safety argument pattern 164
4.3.4 Hazardous contribution software safety argument pat-
tern . . . 169
4.3.5 Argument justification software safety argument pat-
tern . . . 173
4.3.6 Evidence selection . . . 178
5 CONCLUSIONS AND FURTHERWORK 179
6 LISTOF REFERENCES 180
A SOFTWARE SAFETYARGUMENT STAKEHOLDER CONSULTATION 184 A.1 Introduction . . . 184 A.2 The consultation process . . . 184 A.2.1 Consulted stakeholders . . . 184 A.2.2 Stakeholder projects . . . 184 A.3 Consultation results . . . 185 A.3.1 The software safety case product . . . 185
A.3.2 The software safety case process . . . 190
A.3.3 Specific issues . . . 191 A.3.4 Guidance requirements . . . 192 A.4 Conclusions . . . 194
B EXAMPLESOFTWARE SAFETYARGUMENTDEVELOPED USING AN
1
INTRODUCTION
Creating safety arguments for the software aspects of safety related or safety critical systems has the potential to bring many benefits, as de- scribed in this report. Constructing compelling software safety arguments can however be challenging, and there is considered to be currently a lack of guidance available. These positions are supported by the results of a set of interviews conducted with a cross-section of software safety case stakeholders (see Annex A)
This report helps to address this need by providing guidance on the construction of compelling software safety arguments. The document be- gins by discussing the nature of software safety arguments and the chal- lenges they raise. In Appendix B an example software safety argument is developed using an existing approach. This illustrates some of the typical features of a software safety argument, as well as highlighting many of the potential weaknesses of existing approaches. Section 3.1 then goes on to describe a systematic approach to developing software safety ar- guments. This approach extends the existing six-step method to explicitly consider the assurance of the software safety argument throughout its cre- ation. Section 4 then provides a set of software safety argument patterns. These patterns can be used within the framework of the extended six-step method in order to ensure that a sufficiently compelling software safety argument is generated.
2
SOFTWARE
SAFETY
ARGUMENTS
For any safety related, or safety critical system containing software, it is necessary to gain sufficient confidence that the potential contributions that the software may make to system hazards are sufficiently controlled. There are two main approaches that can be adopted to demonstrate the safety of the software aspects of a system. These are a prescriptive ap- proach (often referred to as a process-based approach) and a goal-based approach (often referred to as a product, or evidence based approach). With a prescriptive approach, the developer of the software demonstrates the safety of the system by demonstrating compliance with requirements set out by the appropriate regulatory authority, generally in the form of a prescribed process in a standard. This has traditionally been the most common approach, and is the basis of the standards most commonly used for developing software used in safety related applications, such as [26] and [10]. With a prescriptive approach, the process to be followed will nor- mally be varied according to the risk associated with the software, or the criticality of the outcome of software failure. The greater the risk, or more critical the outcome, the more onerous the prescribed process is. For soft- ware with which a lower risk is associated, many of the requirements will not be required to be met.
With a goal-based approach, the regulatory authority does not pre- scribe a method for demonstrating that the software is acceptably safe. In- stead it is the responsibility of the developer of the software to demonstrate to the regulatory authority that the software is acceptably safe to operate. A goal-based approach has a number of advantages over a prescriptive approach. The philosophy of a prescriptive approach is heavily focussed on controlling the processes that are used to develop the software. Gen- erally the processes that are specified in prescriptive standards are very sensible, and the software evidence produced may be of a high level of in-