7 Reasoning About Safety and Security The Logic of Assurance

A common definition of assurance is certainty about something. Assurance has synonyms like guarantee, certainty, certitude, surety, confidence, expectation and antonyms like doubt and uncertainty. Since many of the systems that we design, build, and maintain have safety-critical or security-critical functions or both, we strive to provide assurance about these systems’ safety and security and perhaps also assurance of other characteristics.This chapter will outline the structure of reasoning about assurance of systems. Assurance is tasked with addressing both individual concerns and composite or compound concerns. Assurance demands that we analyze a system in order to identify risks and take steps in design and design process to mitigate or render “acceptable or reasonable” those risks.A case for the adequate assurance of a system, or an assurance case, consists of several distinct elements. It consists of requirements (asserting that the system has a set of assurance properties), test, design elements (with test results), and finally argumentation/reasoning about those requirements, tests, design elements, and test results. Aside from calling out this evidence and design artefacts, this argumentation may appeal to standards, regulations, and even expert opinion to justify the conclusion that this evidence is sufficient to assure us that the residual risk is “reasonable.”The key challenge to understanding the safety and security risks involved in designing, realizing, and deploying cyber-physical systems (CPS) is to understand and evaluate the argument for the acceptability or reasonableness of those risks. Safety has to do with the potential harm that can be caused by the system’s behaviors, while security has to do with the adverse impact that can occur as a result of unauthorized access or modification of the system. The behaviors of a system refer to how the system performs in the variety of operational settings. This is partially determined by the system design and partially by the everchanging environment in which the system operates. Certain intended behaviors are stated or described in the design and others are discovered in the course of conceiving of the system (identifying the requirements), constructing the system, and testing to determine whether the requirements are met (realization, including verification) and, finally, running the system in what we understand to be its operating environment (validation). An assurance case reasons about all of these activities, and their outcomes, and should provide us with a level of confidence that the system will perform as intended.An approach that emphasizes the work products of the design, verification, and validation activities forces us, in evaluating a system, to reconstruct the argument and even then there is currently no “gold standard” or “true north” against which to assess the reasoning used. Standards frequently strive to express or proscribe on the kind of reasoning and the consensus associated with standard is itself compelling evidence that those proscriptions are sound.Standards frequently describe conceptualization, realization, and assurance activities that need be performed but only implicitly in the dictates of the standards and not through explicit descriptions of the argument itself.In this chapter we will review an approach to safety or security assurance that clearly distinguishes the nature of assurance reasoning. We do this by means of an example of a safety concern, functional, or software safety for automotive systems, and with reference to a specific standard, ISO 26262. Though this discussion focuses on an aspect of safety, much of the analysis of assurance reasoning is general and common to the assurance of any system with respect to a variety of other concerns. The extension of these methods to general CPS or the Internet of Things (IoT) will be taken up in future publications.In the annex we provide a graphic representation of the general safety case strategy for electronic throttle control.