Assurance Case: a reasoned safety case

source



What is the best way to assess security and not miss anything? Is it possible to collect all the variety of security artifacts in one document (or diagram) and organize them in such a way that any aspect can be visualized with an understandable level of detail?



Technicians would be happy to invent such a “philosopher's stone” that, even if it did not provide security, at least would assess it with the required level of completeness. Such developments have existed for over 20 years, however, they are practically unknown to the Russian-speaking reader. It will be about the Assurance Case (or Safety Case) methodology, which means a structured set of arguments and documentary evidence justifying the compliance of a system or service with specified requirements.

Introduction

Before reading the article, I would like to draw your attention to a couple of important points. The stated material is applicable, first of all, for objects of critical information infrastructure (CII). For such objects, in particular for information and control systems, a security analysis must be performed. The results of the safety analysis are presented in the form of appropriate reports. All this has been done for decades, however, reports, as a rule, have an arbitrary text form, the logic of which is not always easy to understand.



The main idea of ​​the presented approach is that the results of security analysis can be presented in graphical form using semiformal notations, with all the ensuing advantages. Thus, the Assurance Case is a way of an integrated presentation of all measures for ensuring and assessing security, without replacing or canceling such private methods as, for example, testing, static code analysis, reliability calculation, FMEA, risk analysis, etc. This article continues the previously published security series .

Argument maps and their philosophical origins

How can we understand or assert that some object is safe? Obviously, a number of criteria must be introduced for this. However, for these criteria, we need to determine how reliable our knowledge of the object is? Why can we trust this knowledge? What makes our reasoning and reasoning truly credible? Having delved into such problems, one cannot do without philosophical disciplines such as ontology, epistemology, epistemology, logic, and also, without great thinkers who were worried about these questions. In the ancient world, such were Aristotle and Plato, and in the era of "modern times" Francis Bacon is considered the founder of the modern scientific method.



What can be done to justify or assess safety in a reasonable and logical way? This approach is based on the theory of argumentation. A new impetus to the modern development of argumentation was given in the work of the British philosopher Stephen Toulmin entitled "The Uses of Argument", published in 1958. Tulmin extended the logical implicative inference with additional parameters and proposed to represent this operation in graphical form. Tulmin's notation operates with the following entities: data (D) - initial data for analysis, claim () - the purpose of logical implication inference (If D So C), warrant (W) - an additional argument, qualifier (Q) - the degree of confidence in the results of the logical output, rebuttable (R) is an additional counterargument (Figure 1).





Figure 1. Notation by Stephen Tulmin



Maps of arguments or argument ( Argument the Map ) used for the purpose of visualization and reasoning to Toulmin, but it was he who most successfully summarized the structural model for the analysis and verification of arguments. Note that modern argument maps, as a rule, do not use Tulmin's notation, everything is simplified, for example, as in the figure below. This is the notation used by the paid online service Rational (there is a free version, but it is extremely limited in functionality) (Figure 2). The paid version is able to transform the resulting diagrams into logically structured text. There are also free guides & tutorials available on the site on critical thinking and argument mapping.





Figure 2. An argument map developed with the serviceRational



As you can see, everything is quite transparent, there are only four entities and three types of relationships between them. The result of logical input is called Contention, confirming the argument - Reason (connection because), counter-argument - Objection (connection but), but the counterargument for the counter-argument has a special name - Rebuttal (connection however).



There is currently no generally accepted notation for constructing argument maps. There is no uniformity in the notation used for the structure of arguments. For example, the inference result can be called claim, contention, conclusion, goal. Arguments can be called premise, justification, etc. There are a number of international initiatives and communities in the field of argument modeling (e.g. Argument Interchange Format, AIF), but they did not solve the questions of unification. There is research that draws parallels between argument maps and mind maps (Mind Map, everyone's probably heard of them). Indeed, the capabilities of the Mind Map editors allow you to build an analog of the argument map.

Assurance Case history and concept

What does all this have to do with security? To answer this question, let us turn to the second half of the twentieth century, where the modern theory and practice of ensuring security originates. Then, as a result of the development of complex technogenic industries, such as nuclear energy, space technology, oil and gas and chemical industries, transport, mankind was faced with man-made disasters of unprecedented scale.



Then the first safety analysis reports appeared, which brought together all the relevant requirements, as well as information confirming their compliance. Later, the term Safety Case (in fact, an analytical report on safety) appeared, which was the predecessor of the Assurance Case. Note that the terms "Safety Case" or "Assurance Case" cannot be directly translated into Russian; in this context, the most logical translation is "safety case". Although, for example, in Russian translations of the ISO / IEC 15026 series of standards (Systems and software engineering - Systems and software assurance) "Assurance Case" is translated as "guarantee case".



It should be noted that in some industries the term Safety Case is still used, along with the Assurance Case. Assurance Case, being a more modern term, is opposed to Safety Case in the sense that today the system must meet not only safety requirements, but also security requirements. Therefore, it is proposed to use the concept of Assurance Case, and consider the Safety Case as a special case.



Assurance Case, in the modern sense of this term, means a report on the safety analysis performed, including a visual representation in the form of a graph or table, obtained using semiformal notations (the notations will be discussed below). At the same time, some discrepancy of the same term is obtained, since it is possible to interpret the Assurance Case, on the one hand, as a document (safety analysis report or safety case report), and, on the other hand, as an argumentation system using semiformal notation ... Ideally, an Assurance Case can include both components, that is, the document evaluating security is built on the basis of an argument model.



Let's go back, however, to the 20th century. The first regulatory document requiring the development and analysis of a Safety Case for potentially hazardous industrial facilities was the CIMAH (Control of Industrial Major Accidents Hazards) Regulations, originally issued in the UK in 1984 and then adapted in several other countries. The wider implementation of the Safety Case into practice began after the unprecedented accident at the Piper Alpha oil platform in the North Sea, which killed 167 people in 1988.



In the 1990s, researchers continue to seek new approaches to assessing safety. The idea seems to be on the surface: let's develop a special notation to justify the compliance of man-made objects and systems with safety requirements. Two British university teams took over, the University of London, where the spin-off company Adelard was formed, and the University of York. I must say that today Adelard and the University of York occupy leading positions in the promotion of Assurance Case.



For the development of notations, the emphasis was placed on the logical reasoning that a property or component of the system meets the stated requirements. The works of Stephen Toulmin, which we have already considered, were chosen as a theoretical basis. As a humanist, Toulmin hardly thought about man-made systems, however, he went down in history, among other things, as the founder of the argumentation for the Assurance Case.



Taking Toulmin's notation as a basis, the British soon developed the Assurance Case methodology (called the Safety Case at that time) and brought the results to practical industrial implementations. At the University of York, Goal Structuring Notation (GSN) was developed and promoted by PhD student Tim Kelly under the guidance of Professor John McDermid. As a result, there was that rare case when the dissertationArguing Safety: A Systematic Approach to Managing Safety Cases. PhD thesis. University of York, 1998 ” has been considered a classic for over 20 years, and it continues to be actively cited. However, the approach to solving the security problem was, in my opinion, more academic, and as a result, for some reason, a seemingly understandable and logical step was not taken related to the development of a software tool to support Assurance Case.



In contrast, Adelard, led by Robin Bloomfield and Peter Bishop, was primarily concerned with commercializing the results. In parallel with York, the notation Claim, Argument and Evidence (CAE) was developed in London, as well as the Adelard ASCE software tool(Assurance and Safety Case Environment), which supports both CAE and GSN. In the UK, the development of an Assurance Case (Safety Case) is required by laws and standards in many areas related to safety, so ASCE has a fairly strong market here. ASCE has been and remains the most used Assurance Case development tool. The main part of the tool is a graphic editor, in which additional text or hyperlink information can be attached to graphic blocks (Figure 3). You cannot download the ASCE software from the Adelard website yourself. You must complete a request for a 30-day trial or academic license, after which the request will be reviewed by the company.





Figure 3. The interface of the Adelard ASCE program



Now let's look at the two basic notations used to develop an Assurance Case (CAE and GSN).

CAE (Claim, Argument and Evidence) notation

The CAE (Claim, Argument and Evidence) notation operates on three specified entities: goals indicate the achievement of the required properties of the system, confirmations provide a documented basis for argumentation, demonstrating the achievement or non-achievement of goals, arguments are built using inference rules and connect confirmation with purposes. Arguments such as deterministic (or logical), probabilistic and qualitative are commonly used. To designate goals, arguments and evidence, graphic primitives are introduced that have various shapes (Figure 4).



Figure 4. Claim, Argument and Evidence (CAE) Notation: Main Components



Building a hierarchy of goals and subgoals is the first step in developing an Assurance Case. As shown in the diagram, the structure of goals, arguments, and assertions is not necessarily three-tiered, for example, additional subgoals can be used to support argumentation. CAE notation is also easily transformed into tabular form. The columns of such a table will be all the same targets, arguments and confirmations, between which links will now be established within the table records. A similar approach to the development of an Assurance Case is used, for example, by exida .

GSN (Goal Structuring Notation)

GSN operates with such components as a goal (a goal, denoted by a rectangle and is an analogue of a claim in CAE), an argumentation strategy (a strategy, denoted by a parallelogram, and is an analogue of argument), and a solution (denoted by a circle and is analogous to evidence) (Figure 5). The context is used for information support of goals. Assumptions and justifications can be used to support the argument. The structure of goals is hierarchical.





Figure 5. Goal Structuring Notation (GSN): main components



When comparing CAE and GSN, it should be noted that CAE pays more attention to the rationale for individual arguments. For this, a detailed design of the argumentation steps is performed. GSN focuses more on generic argument structures (patterns). Due to the larger number of entities, GSN is less strict, and at the same time, with a more concise description, it can be reduced to CAE. The use of each of the notations can be quite subjective, since the approach to constructing arguments depends on the person who performs this task. Some Assurance Case practitioners note that there are a number of gaps in the notations associated with the completeness of the definition of semantic elements.



It happened so that today GSN is more common. GSN format fixed in the standardGoal Structuring Notation (GSN) Community Standard , as well as the Structured Assurance Case Metamodel (SACM) data model from the Object Management Group (OMG).

Knowledge base: industries, standards, research, tools, alternative notations

Assurance Case is used primarily in those industries in which its use is regulated by regulatory documents. The leader here is Great Britain and some other countries of the British Commonwealth. The UK Health Foundation 's report Using Safety Cases in Industry and Healthcare (2012) reports on the regulatory experience of the Assurance Case (Safety Case) in the healthcare, aviation, nuclear power, automotive, defense, petrochemical and rail industries.



Considering the requirements for applying an Assurance Case outside the UK, it should be noted:

• automotive standard ISO 26262: 2011, Road vehicles - Functional safety, part of the family of functional safety standards detailing the requirements of IEC 61508;
• European Organisation for the Safety of Air Navigation (EUROCONTROL): “Safety Case Development Manual, 2006”, “EAD (European Aeronautical Information System Database) Safety Case, 2009”, “EAD (European Aeronautical Information System Database) Safety Case Guidance, 2010”;
• “Licensing of safety critical software for nuclear reactors – Common position of international nuclear regulators and authorised technical support organisations, 2018”, (, , , , , , , , );
• standards of the ISO / IEC 15026 series, Systems and software engineering - Systems and software assurance, which includes four parts: Part 1: Concepts and vocabulary (2019); Part 2: Assurance case (2011); Part 3: System integrity levels (2015); Part 4: Assurance in the life cycle (2012).
  
  

Also worth noting are a number of organizations (besides the already mentioned Adelard and the High Integrity Systems Engineering Group from the University of York) that are actively working in the field of Assurance Cases. These include:

• US-CERT (United States Computer Emergency Readiness Team), they call their methodology Security Assurance Cases ;
• SEI/CMU (Sofrware Engineering Institute – Carnegie Mellon University), , CERT Division, SEI, Assurance Case US-CERT;
• NASA (National Aeronautics and Space Administration) Scientific and Technical Information (STI) Assurance Case ;
• , , John Rushby, SRI International ( Stanford Research Institute), , “The Interpretation and Evaluation of Assurance Cases”, .

Adelard ASCE (Case Case and Safety Case Environment) remains the best known Assurance Case support software . Most of the projects mentioned in different years have not reached any serious level. NASA announced the creation of AdvoCATE software , but they use it for their own purposes, and do not plan to release it to the market. Given the simplicity of the notation, you can use, for example, MS Visio to draw up Assurance Case diagrams and supplement them with hyperlinks.



Alternative approaches to developing Assurance Case include the NOR-STA software tool... It would be developed by the Polish company Argevide (spinoff of the Gdansk University of Technology). NOR-STA supports its own TRUST-IT notation. The difference is that instead of a graphical representation, the NOR-STA uses a structured hierarchical list (Figure 6).







Figure 6. Trust-IT Notation: Core Components and Case Study



Entities in the Assurance Case hierarchical list of objectives are denoted by different icons. An argumentation strategy is used to confirm compliance with a statement, and facts or observations, justifications, assumptions and additional statements are used as an analogue of evidence. Unlike the desktop Adelard ASCE, NOR-STA is used online and supports distributed teamwork.



In addition, the Assurance Case is used to solve the following applications:

• evaluation of attributes of complex properties, such as Quality, Dependability, Security;
• support certification and standardization by transforming the requirements of the standards into an argument structure;
• Assurance Based Development (ABD) or warranty-based product development is a form of Model-Based Development (MBD);
• knowledge management, for example, modeling the structure of documentation or determining structural links in any area of ​​activity (business processes, workflow, change management, etc.).

Assurance Case for Information Security

Security (Trustworthiness) Case is known as one of the varieties of Assurance Case. If necessary, the Security Case can be supplemented with Safety Case components. In fact, the idea behind the Assurance Case is to combine the safety & security attributes. In the certification area, there is a track record for ISO / IEC 15408 (General Criteria), for which the requirements have been converted to a structure compatible with the Assurance Case structure. This conversion can be done for other relevant standards, such as ISO 27000, or IEC 62443, or any other framework.



An example is the Security Assurance Cases snippetposted on the US-CERT website. This snippet reviews the proof of implementation of the Software Development Life Cycle (SDLC). The focus is on eliminating coding defects (in particular, Buffer Overflow), for which methods such as training programmers, code reviews, static analysis and testing are used. One can, of course, argue with the completeness of this fragment, but it is given only as an illustration (Figure 7).





Figure 7. Security Assurance Cases Fragment



Thus, although information security is the application where the Assurance Case could be most in demand, it should be noted that despite its potential and a number of pilot studies, the Assurance Case has not become a well-known practice in this area.

Case Study Assurance Case

Finally, let's look at an example of how this can work. It is based on an approach based on the development of structured arguments .

Structured arguments

Let's imagine the process of developing arguments in two sequential steps (Figure 8). The first step, called the Reasoning Step (RS), is an analysis of subgoals (SC), which are aimed at achieving the main goal (C). At this step, the structure of argumentation develops. In the second step, called the Evidential Step (ES), confirmations (Evidece, E) are formulated in support of the subgoals (SC) generated in the previous step. To further formalize the RS and ES steps, typical Structured Text (ST) templates are used.





Figure 8. Steps and components of structured arguments

Hierarchy of requirements

Imagine a hierarchy or pyramid of requirements that form a structure that corresponds to the Assurance Case column. Most regulatory requirements for computer systems or software have a 3 or 4 level requirement structure (Figure 9).





Figure 9. The hierarchy of requirements and its relationship to the steps of argumentation



Level zero is a meta-goal, according to which the system under assessment must meet all security requirements. At the first level, global safety objectives are achieved, for example, the following objectives derive from the IEC 61508 functional safety requirements :

• a safety management system must be implemented;
• during system (or software) development, the security lifecycle must be applied;
• a sufficient set of measures to protect against accidental failures must be applied to the system;
• for the system (or software), a sufficient set of measures must be applied to protect against systematic and software failures, including protection against cyber attacks.

At the second level, requirement groups support a specific global goal. For example, security management requirements(according to IEC 61508) include groups of requirements for personnel management, configuration management, document management and others. The structure of links between the zero, first and second levels is a fairly simple tree. This structure does not require detailed elaboration of the arguments, since these arguments are typical and have been repeatedly tested in various projects. However, when moving from the second level to the lower ones, structured arguments are required. In this case, the requirements of the lower levels can be composite (that is, include a number of separate requirements) or simple (atomic). If all requirements are atomic (there are no composite requirements), then this level becomes the third, and then it is directly related to the subgroups of requirements. If there are compound requirements, then we get a more complex four-level structure.



For the lowest level, besides RS, ES should also be applied. Since it is inconvenient to add detailed information about the content of the arguments to the structure of the graph, each of the nodes of the Assurance Case graph, starting from the second level, is marked with a description of the arguments using structured text (ST). The lower level Assurance Case graph is no longer a tree, because the same confirmation (E) can support different subgoals (SC).

Assurance Case for a group of HR requirements (IEC 61508)

As an illustration, consider the Assurance Case snippet in relation to the IEC 61508 HR requirements ( IEC 61508-1 clause 6 ).





A total of seven personnel management requirements have been extracted from IEC 61508. From the point of view of structured argumentation, these requirements are sub-objectives (SC1, ..., SC7). Only one of the subgoals (SC5) is composite, all the others are atomic. In order to move from a composite subgoal (SC5) to atomic (SC5.1, ..., SC5.11), one more step of reasoning (RS) is performed. It is understood that in accordance with the requirements of IEC 61508, a Human Resource Management Plan was developed for a project related to the creation of an abstract product. This plan interprets the requirements of the standard in the context of the project.





For all confirmation steps (ES), it is proposed to use a common structured text indicating the links between subgoals (SG) of confirmations (E). We will use the relation SG -> E to denote the relationship between the corresponding subgoal (SG) and the confirmations (E) that support it.





All obtained relations SG -> E can be transformed into an Assurance Case column, according to GSN notation modified for structured argumentation (Figure 10). This graph reflects the entire group of requirements related to personnel management according to IEC 61508. This graph can also be used as a template for assessing compliance with the requirements of IEC 61508.





Figure 10. Assurance Case graph derived from structured arguments for the group of HR requirements (IEC 61508)



At first glance, all this is long and difficult, but, nevertheless, the Assurance Case has its practical application. This is the approach we used when certifying the RdICS PLC for compliance with IEC 61508 .

Conclusion

The Assurance Case (Safety Case) method has been used for over 20 years to analyze the safety of CII facilities. This method is most widely used in the UK and a number of British Commonwealth countries for such industries as healthcare, aviation, nuclear energy, automotive, defense, petrochemical and railroad industries.



The advantages of the Assurance Case include all the advantages achieved by visualizing relationships in a complex subject area, by improving our perception and understanding. The disadvantages are due to the subjectivity of the method in terms of its dependence on the expertise of the persons performing the assessment. The most famous "epic fail" in Assurance Case application is described here... In short: On September 2, 2006, a fire broke out in Afghanistan aboard a British Air Force Nimrod. The problem arose from a fuel leak. All 14 people on board were killed. An earlier Safety Case report confirmed the safety of the aircraft. The investigation showed that the modification of the fuel system was not quite correct on production aircraft, and similar problems had arisen before, but for some reason no one paid attention to them as a system error. In a 600-page report released, this incident was named nothing more than "a failure of leadership, culture and priorities."



By the way, graphical notations were not used in the report for Nimrod. One of the consequences of this catastrophe was the deepening of research in the area of ​​argumentation construction. However, a general approach that satisfies everyone has not been developed.



Today, the main driver of Assurance Case implementation is regulatory and legal requirements, not convenience, feasibility or cost-effectiveness. Obviously, there are great opportunities for artificial intelligence in the field of Assurance Case, but somehow I have not come across publications on this topic.

Nevertheless, the problem associated with assessing the security of complex systems remains open. It is possible that some progress in this area can be achieved with the active implementation of the Assurance Case, because this method is based on all those important points that have occupied humanity from the very beginning of philosophical research.