A New Method for Writing Assurance Cases

1. INTRODUCTION

There have been growing concerns for cyber security as our daily lives now heavily depend on cyber systems, and numerous threats to those systems and our assets have been reported. For example, the Japan National Police Agency (National Police Agency, 2012) reported that the number of cyber criminals arrested in Japan during January through June in 2012 is 3268, an increase of 755 from the same period in 2011. The number of cyber security criminals arrested for offenses such as unauthorized access and falsification totals 338, an increase of 186 from the same period in 2011. Cyber systems interact with each other and involve a wider range of stakeholders. Also, threats to systems come from diverse threat agents, often in unexpected ways. Therefore, it is important to assure stakeholders of the security of cyber systems to the greatest extent possible. In the Build Security In project (Build Security In, 2012) hosted by the U.S. Department of Homeland Security, software assurance is stated as one of the most important topics.

System assurance has become of great importance in many industry sectors too. Safety cases (assurance cases concerning the safety of systems) must be submitted to certification bodies when developing and operating safety-critical systems, e.g., those involving the automotive, railway, defense, nuclear plants, and off-shore petroleum industries (Howell, 2004). Several relevant standards, such as EUROCONTROL (Eurocontrol, 2006), the Rail Yellow Book, and MoD Defense Standard 00-56 (MoD, 2007), mandate the use of safety cases. Currently, assurance cases have been used mostly in the safety area; now, however, they are beginning to be used in various other areas, including the cyber security area.

There are several definitions of assurance cases. One such definition as follows:

An assurance case is called a safety case when arguing the safety of a system. Similarly, it is called a dependability case, security case, reliability case, or availability case when arguing the dependability, security, reliability, or availability of a system, respectively. The basic structure of assurance cases is shown in Figure 1 (slightly modified from the Figure in Bishop & Bloomfield, 1998).

Figure 1.

Basic structure of an assurance case

As shown in Figure 1, an assurance case is often structured as a goal-based document. The top goal is a claim about one of the system’s properties, such as dependability, safety, or security. The top goal is decomposed into sub-goals. Each piece of evidence is called a leaf, all of which ultimately support the top goal. The structure of decomposed goals is called an argument structure.

A recent report by The National Academies of the U.S.A. (Jackson, Thomas, & Millett, 2007) suggests the need for dependability cases based on broad surveys of recent serious incidents. Dependability has been considered an umbrella term that includes multiple attributes such as safety, reliability, availability, integrity, and maintainability. As quoted in (Lipson & Weinstock, 2008), the report said “The committee thus subscribes to the view that software is ‘guilty until proven innocent,’ and that the burden of proof falls on the developer to convince the certifier or regulator that the software is dependable. This approach is not novel and is becoming standard in the world of systems safety, in which an explicit safety case (and not merely adherence to good practice) is usually required. Similarly, a software system should be regarded as dependable only if it has a credible dependability case.” This observation now seems to be shared widely, and assurance cases are getting attention in many areas, including the cyber security area (Lipson & Weinstock, 2008).

Assurance cases are often written using a graphical notation to ease the difficulty of writing and certifying them. Goal Structuring Notation (GSN) is one such graphical notation system (Kelly & Weaver, 2004). Writing assurance cases and reusing them in a cost effective way is a critical issue for organizations. Patterns and their supporting constructs are proposed in GSN for the reuse of existing assurance cases, which include parameterized expressions (Alexander, Kelly, Kurd, & McDermid, 2007).

For several notation systems, including GSN, methods and guidelines for writing assurance cases using the notation have been proposed. Unfortunately, so far only experts have written assurance cases, and it is difficult for ordinary engineers to write them unassisted. We found this was also true when we introduced assurance cases to engineers of some major companies in our country.

We observed that the reason why there is such difficulty in writing assurance cases is that an appropriate method for writing assurance cases has still not been well developed. Several assurance (safety) case development manuals have been published. However, they are sometimes limited to specific kinds of systems such as air traffic control or nuclear systems, and seem applicable only to domain experts. More fundamentally, it is still difficult to explain what assurance cases actually are. How they are different from other kinds of documents such as Fault Tree Analysis (FTA) results and Unified Modeling Language (UML) diagrams still seems unclear to ordinary engineers.

Based on the above observations, this paper presents our initial ideas for developing a method for writing assurance cases. The main ideas are that (1) documents generated and used during the system lifecycle must either be used in the assurance cases or be referred to in the assurance cases, and (2) typical patterns of assurance cases exist and these patterns have not yet been well discussed.

The structure of this paper is as follows. In Section 2, we review related work. Section 3 introduces our method for writing assurance cases. Section 4 illustrates an example of using our method for a web server system. Section 5 states concluding remarks.