Ansys Iec 60601 Safety

1

© Nikita Johnson 2020. Published by the Safety-Critical Systems Club. All Rights Reserved

Nikita Johnson1, Youcef Gheraibia And Tim Kelly

Abstract For modern safety-critical systems we aim to simultaneously maintain safety whilst taking advantage of the benefits of system interconnectedness and faster communications. Many standards have recognised and responded to the se- rious security implications of making these connections between systems that have traditionally been closed. In addition, there have been several advances in devel- oping techniques to combine the two attributes, however, the problem of integrated assurance remains. What is missing is a systematic approach to reasoning about alignment. In this paper, the Safety-Security Assurance Framework (SSAF) is pre- sented as a candidate solution. SSAF is a two part framework based on the concept of independent co-assurance (i.e. allowing separate assurance processes, but ena- bling the timely exchange of correct and necessary information). To demonstrate SSAF’s application, a case study is given using requirements from widely-adopted standards (IEC 61508 and Common Criteria) and a Bayesian Belief Network. With a clear understanding of the trade-offs and the interactions, it is possible to create better models for alignment and therefore improve safety-security co-assurance.

Figure: System Model & Simulation Flow for Ansys Iec 60601 Safety

1 Introduction

In systems engineering the tension between system safety (the desire to protect peo- ple from harm) and cyber security (the desire to protect assets of a system) has in- creased in recent years. This is primarily due to the increased size and interconnec- tivity of modern systems. In order to maximise productivity and capability we allow systems to communicate with each other and share their services. This interconnect- edness presents greater security risk as there is a larger attack surface and many more ways for ‘things to go wrong’. This threatens to undermine the goals of an entire system, including safety goals. From an assurance perspective, it is therefore no longer acceptable to assume complete separation of safety and security risk. Nor

1 Corresponding Author Nlj500 York.Ac.Uk

4 Nikita Johnson, Youcef Gheraibia and Tim Kelly is it acceptable to treat that risk solely in the comfortable isolation of each domain’s2 practices, knowledge, and culture.

Figure: System Model & Simulation Flow for Ansys Iec 60601 Safety

In an attempt to address the issue of isolated practice, many solutions have been created by extending existing safety techniques. These are partial solutions at best because their focus is predominantly on safety and much of the security information is discarded. Many of these techniques have previously been critically examined (Johnson & Kelly, 2019a) and found insufficient for through-life co-assurance.

Figure: System Model & Simulation Flow for Ansys Iec 60601 Safety

There are technical approaches that aim to combine risk concepts across do- mains; organisational structures that allow for better communication between ex- perts; and also legal and regulatory initiatives to align3 safety and security at na- tional and international levels. However, these changes do not address all the con- cerns that arise from bringing the two attributes together, therefore issues with mis- alignment remain.

Figure: System Model & Simulation Flow for Ansys Iec 60601 Safety

This paper presents a candidate solution that enables and supports full alignment of safety and security – the Safety Security Assurance Framework (SSAF). At the core of the Framework is the concept of independent co-assurance and synchroni- sation points. This allows for some separation to be maintained in order to make the most of differing expertise, knowledge and practice, whilst ensuring that the right people get the right information at the right time.

Figure: System Model & Simulation Flow for Ansys Iec 60601 Safety

This paper is laid out in three parts. Part 1: Section 2 attempts to characterise the differences between safety and security. Part 2: Section 3 and 4 present the Safety Security Assurance Framework (SSAF) and apply it to a case study using a Bayes- ian approach and requirements found in standards. Finally, Part 3: Sections 5, 6 and 7 examine the rationale of the decisions made during the case study, discuss related work, and provide a conclusion.

Figure: System Model & Simulation Flow for Ansys Iec 60601 Safety

2 Characterising Challenges in Safety and Security Assurance Due to the similarities between safety and security assurance, namely that both pro- cesses are concerned with reduction of risk and prevention of loss, it is tempting to equate the two notions of risk and have one representative (quantitative) value.

Figure: System Model & Simulation Flow for Ansys Iec 60601 Safety

Whilst this is certainly feasible, as demonstrated by many techniques that combine risk analysis into a single methodology, these methodologies often disregard the fact that there exist differences that make the attributes incommensurable4. This may be one of the reasons that none of these methodologies has been widely adopted for co-assuring safety-critical systems.

2 Here domain refers to technical area (safety or security) rather than application domain. 3 The term alignment will be used interchangeably with co-assurance because of its widespread use in industry. It is worth noting that co-assurance (argument and process) is achieved through aligning safety and security.

4 Definition: not able to be judged by the same standards.

Independent Co-Assurance Using Ssaf 3

Two characterisations of safety and security assurance will be discussed in this section with the aim of making their differences clear. The emphasis is on what makes co-assurance difficult, and the requisite qualities of an effective alignment solution. The first characterisation will look at the contribution of security concerns to safety risk; the second will use widely-adopted standards to establish differences between the attributes.

2.1 Effects Of Security On Safety Risk

Fig. 1. ALARP Representation of the Problems of Uncertainty for Safety Risk In the UK, the Health and Safety at Work Act 1974 (HSE, 1974) states it is the duty of employers to ensure the safety of its employees “so far as is reasonably practica- ble”. This philosophy is often enacted as the ALARP principle: safety risk should be As Low As Reasonably Practicable. Depicted in Figure 1(a) is the ALARP “car- rot diagram”. The idea is to identify the level of a particular risk, then systematically reduce that risk until it is ALARP. It is possible to reduce risk in one of three ways: i. Designing it out of a system, ii. Engineering in controls, or iii. Having procedural mitigations.

Alongside the risk value is a window of variation which is analogous to a statis- tical confidence interval; this represents the uncertainty in the estimation of risk. Several factors affect this interval such as the competence of the practitioners, the rigour of their processes, the limitations of the tools they use, etc. Safety is con- cerned with the higher portion of this interval, and the potential for variance into the unacceptable risk region. Thus, it is often a requirement by regulators for a con- fidence argument to be provided with the safety risk argument or safety case.

Figure 1(b) shows the first problem of safety-security alignment. Practitioners and engineers might follow an ALARP process and use their expert judgement to estimate the level of a particular risk; however due to the presence of an intelligent and motivated adversary the level of risk might be substantially higher in reality.

Therefore, models and artefacts used to support a safety case are inaccurate and the 4 Nikita Johnson, Youcef Gheraibia and Tim Kelly safety argument is fundamentally undermined. There are ways that this can be min- imised, for example verifying estimates made at design time against operational data, however this is not always feasible.

Figure 1(c) shows the second problem for the safety-security interaction: there may exist an estimation of risk, but the level of uncertainty may be high due to security concerns. This could be the result of socio-technical factors, such as inad- equate processes, or the judgement of a practitioner with insufficient training.

Whilst the underlying reason for these two co-assurance problems is the uncer- tainty introduced by security concerns, there are different treatments of uncertainty. Most existing technical approaches focus solely on the uncertainty introduced in Problem 1 above, i.e. they attempt to improve the accuracy of risk level by consid- ering security sources of risk, but do not consider the implications of other assurance

Factors. This Leads To:

Solution Criterion 1 (SC1) A solution for co-assurance must facilitate reasoning about the diverse ways in which uncertainty is introduced into assurance, and how it is handled on multiple levels of abstraction.

2.2 Safety And Security Assurance Characteristics

In (Alexander et al. 2004), characteristics of Systems-of-Systems are identified with the aim of prompting analysts to proactively consider likely failure modes in rela- tion to the characteristics; thus, another way to gain knowledge about risk, besides learning from accidents, is created.

In a similar fashion, in this section, the safety and security characteristics for which there is conflict are identified from three of the most commonly used stand- ards across both domains. The aim of identifying the characteristics is to understand the ways in which safety and security can diverge, and so proactively consider ways to prevent these co-assurance failures.

Fig. 2. Characteristics Of Co-Assurance Factors

The source of safety assurance characteristics is IEC 61508 (International Elec- trotechnical Commission, 2010). For security, both ISO 27005 (International Or-

Independent Co-Assurance Using Ssaf 3

ganization for Standardization, 2011) and Common Criteria (International Organi- zation for Standardization, 2017) were used. Figure 2 shows the shared characteris- tics of safety and security assurance.

Risk Acceptance – This describes the attributes’ attitude to risk. First and fore- most, safety is about preventing death and injury so naturally it is very conservative and risk averse; made clear from the prescriptive and conservative safety require- ments. This is in stark contrast to security, where acceptable risk is a lot more stra- tegic; in most systems (that are not safety-critical) there is an element of gameplay5 in an attempt to balance security risk against potential benefits. This flexibility is reflected in the standards, where unlike safety standards, no universal notion of ac- ceptable risk is given. It is worth noting that as security incidents begin to have a greater impact on society, regulatory authorities and lawmakers are attempting to define acceptable risk for security so that if it is not maintained, punitive action can be taken for those responsible.

Assurance Rigour – Both attributes’ assurance processes aim for order, reasoned arguments supported by evidence, predictable behaviours, and repeatable outcomes, etc. Due to safety’s risk aversion, the operational environment of safety-critical sys- tems is often defined and strictly bounded, thereby making it easier to achieve higher levels of assurance rigour at system level. For security however, the intelli- gent adversary alone means that there exists higher levels of uncertainty, which makes it much more difficult to achieve predictable outcomes. The approach is therefore to achieve assurance rigour at lower levels of the system (e.g. component level) with clearly defined assumptions to test against.

Temporal – This is the time required to perform assurance activities and the ex- pected rate of change. For safety, the conservative risk stance and the need to pro- vide detailed argumentation about acceptable risk takes time. It is also expected that once a system has been certified6, the safety case remains valid unless there is a major change to the system or its usage. In contrast, the security assurance environ- ment is more agile and fast-paced. This is reflected in the “classes” approach to requirements in the standards that aims to protect against groups of vulnerabilities, so that change can be responded to more effectively – such as when a new vulnera- bility is discovered. Security arguments need to be robust to change at a faster rate than safety.

Complexity – Both safety and security are emergent, but they handle different types of complexity in different ways. For example, complexity due to number of components is not an issue in and of itself for safety7; what is important is that complexity does not interfere with the assurance factors for safety. In contrast, re- dundancy and diversity creates more work for security, as there are a greater number 5 From Game Theory where rational decision-makers maximise rewards within given bounds.

6 “certified” used in the broadest sense. Based on the assumption that all safety-related sectors have some form of formal safety acceptance before use that does not necessary involve a regulator. 7 For example, if a system is built with an infinite number of components whose behaviour is formally understood, then we can create a mathematical model of this infinitely large system, and argue safety.

4 Nikita Johnson, Youcef Gheraibia and Tim Kelly of potential attack options to consider. This has a significant impact on the time resource available and the level of assurance rigour that can be achieved.

These are the four characteristics where the most significant alignment failures are likely to occur. Having defined these, it is now possible to find mitigations to

Prevent The Specific Mismatches. Therefore:

Solution Criterion 2 (SC2) A solution for co-assurance must address the alignment trade-offs with respect to each of the assurance characteristics (risk acceptance, as- surance rigour, temporal and complexity).

It is clear that the co-assurance solution criteria stated in this section are not in- herently technical. Although there will most certainly be an element of technical analysis required for alignment, a solution that considers only this aspect and not the wider context would be a partial solution at best. What is needed is an approach that has the capability to address both the technical risk alignment and the socio- technical assurance factors.

3 The Safety-Security Assurance Framework

Fig. 3. SSAF: Independent Co-assurance and Synchronisation Points

Independent Co-Assurance Using Ssaf 3

The Safety-Security Assurance Framework (SSAF) is a solution for co-assurance that addresses the criteria (SC1 and SC2) stipulated in the challenges section. It consists of a process and model for systematically reasoning about the alignment of system safety and cyber security throughout the life of a system. SSAF is built on the new paradigm of independent co-assurance – that is, keeping the disciplines and expertise separate but having key synchronisation points where required infor- mation is exchanged across the discipline boundaries i.e. “the right information is given to the right people at the right time”. Figure 3 illustrates this concept during system development and deployment. Note that SSAF was developed with the as- sumption of a model-based design, however that does not preclude its use on non- model-based systems. More work is required to establish the synchronisation (sync) points in this case.

SSAF is comprised of two models – the Technical Risk Model allows for the communication of risk and impact across disciplines; and the Socio-Technical Model which recognises that co-assurance is an inherently human activity that in- volves many judgements at different levels that could constrain the technical solu- tion to alignment.

3.1 Ssaf Technical Risk Model (Trm)

The first SSAF model – the Technical Risk Model has three major parts:

1. An Ontology For Cross Discipline Communication

2. A 5-step process for creating synchronisation points and links 3. A causal model and patterns for different conditions and their relationships

Fig. 4. Ssaf Trm Process For Synchronisation

The SSAF TRM processes in Figure 4 consists of five steps. Steps 1, 4 and 5 are where the unique contribution of the TRM lies. Steps 2 and 3 are assumed to be the standard best practice in each of the domains8.

8 In (Johnson & Kelly, 2019b) a worked example of the application of the SSAF TRM process to a wearable medical device is given. 4 Nikita Johnson, Youcef Gheraibia and Tim Kelly At the core of making independent co-assurance, and therefore SSAF, work is establishing sync points and understanding the causal relationships between condi- tions in safety and security. Many standards have started to include synchronisation points where safety and security must communicate as an integral part of their pro- cesses e.g. ARP 4754A (SAE International, 2010) and DO-326A (RTCA, 2014) for aerospace, ISO 14971 (International Organization for Standardization, 2007, p.

200) and AAMI TIR 57 (Association for the Advancement of Medical Instrumen- tation, 2016) for medical devices, etc. However, it can be argued that these are the absolute minimum needed for alignment. In order to add more sync points and im- prove alignment, it is important to understand what information needs to be ex- changed and when.

Figure 5 shows the (partial) TRM causal meta-model that enables relationships between conditions across domains to be modelled. By systematically understand- ing relationship between conditions and the synchronisation points where they oc- cur – patterns of interaction can be created. This helps to address the problem of inaccurate risk estimation in each domain, but particularly for safety9.

Fig. 5. SSAF TRM Causal Relationships represented in UML

3.2 Ssaf Socio-Technical Model (Stm)

The second part of SSAF is the Socio-Technical Model (STM). Whilst modelling causal relationships for technical risk alignment is a very powerful concept, it is insufficient when considering that there may be a discrepancy between the modelled condition and how it occurs in actuality. STM helps to minimise the effect of this problem by understanding the sources of uncertainty that affect confidence10;11.

Figure 6 shows the STM model of interactions. Unlike the TRM it does not con- sider causal relationships, rather, it uses another type of assurance influence – the confidence relationship. The idea of explicitly modelling confidence is not unique to SSAF STM. The Motor Industry Software Reliability Association have included 9 Addresses problem 1: Inaccurate Risk Estimation from Section 2.1 10 Addresses problem 2: High Uncertainty with regards to Risk Estimation from Section 2.1 11 In (Johnson & Kelly, 2019c) a worked example about how to use the STM is provided.

Independent Co-Assurance Using Ssaf 3

the requirement to reason about organisational and individual factors that affect technical risk (MISRA, 2019). SSAF STM identifies two types of confidence.

Fig. 6. Ssaf Stm Confidence Relationships

Primary confidence describes all the factors that could affect the technical risk argument directly, examples of this include the analysis approach being used, and the competence of practitioners.

Secondary confidence describes all the factors that may influence primary con- fidence. This includes organisational structures, engineering processes, individual cognitive biases, etc.

The STM has roots in the socio-technical systems domain. The categories of as- surance factors are based on Bostrom and Heinan’s model of socio-technical sys- tems design (Bostrom & Heinen, 1977). The categories are Structure, Process Peo- ple and Tools. An additional category, Conceptual, was added to the model. It is orthogonal to the other types of assurance factor. For safety-security alignment communication of mental models is one of the biggest factors affecting assurance.

The communication of concepts was not adequately represented in any of the other four categories. By explicitly representing points where uncertainty can be propa- gated across domain boundaries, we can start to reason about why it is not a prob- lem, and still have confidence in the risk argument. Without articulating these rela- tionships it’s almost impossible to do this.

3.3 Assurance Surface

Another useful concept introduced by the SSAF model is that of the assurance sur- face. The underlying concept is borrowed from the security domain - attack surface i.e. all the vectors that an attacker might exploit to launch an attack on a system (Howard, Pincus, & Wing, 2005). The assurance surface by analogy is all the ways in which uncertainty can be propagated across domains. The concept necessitates an important shift in thinking for co-assurance. It implies that there are multiple ways in which uncertainty can be propagated, and therefore it is highly unlikely that 4 Nikita Johnson, Youcef Gheraibia and Tim Kelly any one technical approach to integration will address all uncertainty propagation.

Instead we must think in terms of assurance coverage, and use the best possible combination of approaches and argumentation to minimise uncertainty propagation across domains. Figure 7 shows the relation between SSAF TRM and STM to ex- isting safety-critical system development. More detail about the tiers is provided in (Johnson & Kelly, 2019c).

Fig. 7. Ssaf Assurance Surface Concept

4 Case Study: SSAF TRM Bayesian Approach to Standards Thus far, SSAF independent co-assurance has been presented as a potential solution to safety-security alignment problems. The reasoning behind why the approach of explicitly modelling relationships is the best way forward has been provided. How- ever, still lacking is the means by which to achieve this.

That is the purpose of this case study. The motivation is twofold – first, to pro- vide empirical evidence for the SSAF models and methodology. Secondarily, to show the creation of a re-useable alignment pattern. To maximise applicability the case study, requirements from two of the most commonly used single-domain stand- ards were selected: IEC 61508 and Common Criteria.

4.1 Iec 61508 And Common Criteria Brief

IEC 61508 is arguably the most widely adopted safety standard. It has been adapted to multiple domains including healthcare, rail, automotive, aerospace, and nuclear. It consists of seven parts that define the safety process for a system. It is the software design and development (software architecture design) requirements found in Table A.2, p48 IEC 61508-3:2010 that were selected for this case study.

Common Criteria is a widely adopted security standard that has been adopted across many types of systems in many domains, including some that are safety-

Related Journal Articles & DOI Links

Selected peer-reviewed publications relevant to 12 Lead ECG Acquisition. Click the DOI to access the full paper (may require institutional access).

Why Choose Us?

Bangalore guidance for robotics, Spectre and autonomous systems projects.