Security Assurance Cases -- State of the Art of an Emerging Approach

Security Assurance Cases (SAC) are a form of structured argumentation used to reason about the security properties of a system. After the successful adoption of assurance cases for safety, SACs are getting significant traction in recent years, especially in safety-critical industries (e.g., automotive), where there is an increasing pressure to be compliant with several security standards and regulations. Accordingly, research in the field of SAC has flourished in the past decade, with different approaches being investigated. In an effort to systematize this active field of research, we conducted a systematic literature review (SLR) of the existing academic studies on SAC. Our review resulted in an in-depth analysis and comparison of 51 papers. Our results indicate that, while there are numerous papers discussing the importance of security assurance cases and their usage scenarios, the literature is still immature with respect to concrete support for practitioners on how to build and maintain a SAC. More importantly, even though some methodologies are available, their validation and tool support is still lacking.


Introduction
A security assurance case (a.k.a. security case, or SAC) is a structured set of arguments that are supported by material evidence and can be used to reason about the the security posture of a software system. Security assurance cases represent an emerging trend in the secure development of critical systems, especially in domains like automotive and healthcare. The adoption of security cases in these industries is compelled by the recent introduction of standards and legislation. For instance, the upcoming standard ISO/SAE 21434 on Road Vehicles Cybersecurity Engineering includes the explicit requirement to create 'cybersecurity cases' to show that a vehicle's computing infrastructure is secure.
The creation of a security case, however, is far from trivial, especially for large organizations with complex product development structures. For instance, some technical choices about the security case might require a change of the development process. For example, the security case shown in Figure 1 (and discussed in Section 2) requires that a thorough threat analysis is conducted throughout the product structure and at different stages of the development. If this is not the case, a thorough re-organization of the way of working is necessary, or maybe the security case should have been structured in a different shape. Also, the construction of a security case often requires the collaboration of several stakeholders in the organization, e.g., to ensure that all the necessary evidence is collected from the software and process artifacts.

arXiv:2003.14151v1 [cs.SE] 31 Mar 2020
To summarize, companies are facing the conundrum of making both urgent and challenging decisions concerning the adoption of security cases. Naturally, they could refer to academic research, which has published a relatively large number of papers on the topic in recent years. In order to facilitate such endeavor, this paper presents a systematic literature review (SLR) of research papers on security cases. To the best of our knowledge, this is the first study of this kind in this field. This SLR collects most relevant resources (51 papers) and presents their analysis according to a rich set of attributes like, the types of augmentation structures that are proposed in the literature (threat identification -used in Figure 1-being one option), the maturity of the existing approaches, the ease of adoption, the availability of tool support, and so on. Ultimately, this paper presents a complete guideline to adoption geared towards practitioners. To this aim, we have created a workflow describing the suggested activities that are involved in the adoption process for security cases. Each stage of the workflow is annotated with a suggested reading list, which refers to the papers included in this SLR. We remark that the SLR also represents a useful tool for academics in order identify research gaps and opportunities, which are discussed in this paper as well.
The rest of the paper is structured as follows. In Section 2 we provide some background on assurance cases and discuss the related work. In Section 3 we describe the research questions and the methodology of this study. In Section 4 we list the papers included in this study and present the results of the analysis. In Section 5 we further discuss the results and present the workflow for security cases adoption. Finally, Section 7 presents the concluding remarks.

Assurance cases
Assurance cases are defined by the GSN standard [32] as "A reasoned and compelling argument, supported by a body of evidence, that a system, service or organisation will operate as intended for a defined application in a defined environment.". Assurance cases can be documented in either textual or graphical forms. Figure 1 depicts a very simple example of an assurance case and its two main parts, i.e., the argument and the evidence. The case in the figure follows the GSN notation [67], and consists of the following nodes: claim (also called goal), context, strategy, assumption (also called justification), and evidence (also called solution). At the top of the case, there is usually a high level claim, which is broken down to sub-claims based on certain strategies. The claims specifies the goals we want to assure in the case, e.g., that a certain system is secure. An example of a strategy is to break down a claim based on different security attributes. The breaking down of claims is repeatedly done until we reach a point where evidence can be assigned to justify the claims/sub-claims. Examples of evidence are test results, monitoring reports, and code review reports. The assumptions made while applying the strategies, e.g., that all relevant threats have been identified, are made explicit using the assumption nodes. The context of the claims is also explicitly set in the context nodes. An example of a context is the definition of an acceptably secure system.
Assurance cases have been widely used for safety critical systems in multiple domains [10]. An example is the automotive industry, where safety cases have been used for demonstrating compliance with the functional safety standard ISO 26262 [52,9,36]. However, there is an increasing interest in using these cases for security as well. For instance, the upcoming automotive standard ISO 23434 [37] explicitly requires the creation of cybersecurity arguments. Security assurance cases are special types of assurance cases where the claims are about the security of the system in question, and the body of evidence justifies the security claims.

Related work
To the best of our knowledge this study is the first systematic literature review on security assurance cases. However, there have been studies covering the literature on safety assurance cases.
Nair et al. [48] conducted a systematic literature review to classify artefacts which can be considered as safety evidence. The researchers contributed with a taxonomy of the evidence, and listed the most frequent evidence types referred to in literature. The results of the study show that the structure of safety evidence is mostly induced by the argumentation and that the assessment of the evidence is done in a qualitative manner in the majority of cases in contrast to quantitative assessment. Finally, the researchers list eight challenges related to safety evidence, and the creation of safety cases was the second most mentioned one in literature according to the study. Maksimov et al. [43] contributed with a systematic literature review of assurance case tools. The researchers list 37 tools that have been developed in the past two decades, and an analysis of their functionalities. The study also includes an evaluation of the reported tools on multiple aspects, such as creation support, maintenance, assessment, and reporting. In our study, we also review supporting tools for assurance cases' creation, but we focus on the reported tools specifically for SAC.
Gade et al. [25] conducted a literature review of assurance-driven software design. The researchers provide a review of 15 research papers with an explanation of the techniques and methodologies each of these papers provide with regards to assurance-driven software design. This work intersects with our work in that assurance-driven software design can be used as a methodology or approach for creating assurance cases. However, unlike Gade et al. [25] our study focuses on SAC, and is done in a systematic way.

Research Method
We conducted a systematic literature review following the guidelines introduced by Kitchenham et al. [40].

Research questions and assessment criteria
This study aims at answering the following research questions.
[RQ1] RATIONALE -In the literature, what rationale is provided to support the adoption of SAC? In particular, we are interested in whether there are statements that go beyond the intuitive rationale of using SAC "for security assurance". For instance, our initial research [46] indicated that compliance with security standards and regulations is also an important driver. As shown in Table 1, to answer this research question we analyze the surveyed papers and extract two characteristics: (i) Motivation, i.e., the reason for using SAC as stated by the researchers. We used two criteria for determining whether a certain study provides a motivation for using SAC. That is, the wording has to be explicit (i.e., there must be a reference to usage or advantage) and specific (i.e., providing some details). (ii) Usage scenario, i.e., scenarios in which SAC could be used to achieve additional goals, next to to security assurance. We used the same criteria (explicit and specific mention) used for the motivation.
[RQ2] CONSTRUCTION -In the literature, which approaches are reported for the construction of security assurance cases, and which aspects do the approaches cover? This question aims at inventorying the existing approaches for creating SAC, which is a challenging task for adopters. As shown in Table 2, we also assess the coverage of the approach, i.e., whether it can be used for creating the argumentation, for collecting the evidence, or both. Finally, for each covered part of the SAC, we identify the gist of the approach with respect to the suggested argumentation strategy and the types of evidence to be used in creating SACs.
[RQ3] SUPPORT -In the literature, what practical support is offered to facilitate the adoption of SAC? The purpose of this question is to understand the practicalities of creating and working with SAC. With reference to Table 3, first we study the approaches and identify the conditions (i.e., prerequisites) that have to be met in order for the outcome of the paper to be applicable. These prerequisites Second, we check whether the papers propose libraries of patterns or templeteized SAC, as these are extremely usefult for non-expert adopters. Third, we analyze the tool support. We check whether the paper suggests the usage of a tool for any of the activities related to SAC. In case it does, we extract the description of that tool, and whether it was created by the researchers or if it is a third party tool used in the paper. The last characteristic in this research question is the notation used to represent the SAC. The most common ones are GSN [67], and CAE [1], but there are other notations such as plain text.
[RQ4] VALIDATION -In the literature, what evidence is provided concerning the validity of the reported approaches? Our interest is to understand how the approaches and usage scenarios of SAC are validated (or supported by any evidence). We aim at identifying: i The type of the validation conducted in the study, e.g., case study, or experiment. Note that 'case study' is a widely used term to refer to worked examples [19,58]. In this work, we consider a validation conducted in an industrial context to be a case study [81], and those done within a research context to be illustrations. Experiments are studies in which independent variables are manipulated to test their effect on dependent variables [19]. ii The domain (i.e., application area) in which the validation is conducted. iii The source of the data used for the validation, e.g., a research project or a commercial product. iv Whether or not a SAC is created as part of the validation process. v In case a SAC is created, we look for its creators.
This characteristic has three levels, which are academic authors, authors with industrial background, or expert group. vi The validators, i.e., the parties that conducted the validation (similar to the creators).

Performing the systematic review
We performed a search for papers related to SAC by means of 3 scientific search engines: IEEE Xplore, ACM Digital Library, and Elsevier Scopus. We did not use Google Scholar as, in our own prior experience, the results from this search engine overlap with the results of the engines we we mentioned above.

Constructing the search string
To maximize the chance of obtaining all the relevant papers in the field, the search string used in the search engines must contain keywords that are commonly used in said papers. Therefore, prior to constructing the search string, we familiarized ourselves with the specific terminology used by researchers in the field of security assurance cases. To do so, we conducted a manual search for papers related to SAC that were published in the past five years in the following venues: SAFECOMP, CCS, SecDev, ESSOS, ISSRE, ARES, S&P, Asia CCS, and ESORICS. The selection of the venues was based on their high visibility in the security domain. Next, we created the search string. In particular, we used two groups of keywords. The first group (line 1 below) is meant to scope the area of the study, while the second group (lines 2-4) included the terms referring to the parts of an assurance case. As a result, the we formed the search string as follows:  OR a s s u r a n c e ) As a quality check for our search string, we used three relevant known studies [20,8,79], which are listed in IEEE Xplore. We ran the query in the same library and confirmed that those papers were returned.

Inclusion and exclusion criteria
The inclusion and exclusion criteria are shown in table 5. The inclusion criteria are rather straightforward, considering to the nature of this SLR. Concerning the exclusion criteria, we have decided to only consider studies written in English language, as this is the common language among the authors of this SLR. Further, SAC have been the focus of research only in recent times (although assurance cases, in general, have been around for much longer) and the field is rapidly evolving. Hence, we restricted our SLR to the past 15 years, also to to avoid outdated results. We also excluded short papers, as answering our research questions requires studies with results rather than only ideas. Finally, exclusion criteria 4-8 exclude studies that focus on topics that are marginally related to SAC but would not not help us answer our research questions.

Searching and filtering the results
We executed the query on three libraries (IEEE Xplore, ACM Digital Library, and Scopus) in January 2019, and got the results shown in Table 6. In the case of Scopus, we limited the search to the domains of either computer science or engineering. Also, because of the high number of returned results from Scopus, we decided to limit the included studies to the first 2000 after ordering the results based on relevance. We believe that the considered studies were sufficient, as the last 200 papers of the retained set from Scopus (i.e., papers 1801-2000) were all excluded when we applied the first filtering round (see below).
In the first filtering round, we applied the inclusion and exclusion criteria to the titles and keywords of all the results we got from the search (8440 papers). As shown in Table 6 This round reduced the number of studies to 211 papers. In the second filtering round, we applied the inclusion and exclusion criteria 1 to the abstracts and conclusions of the 211 remaining studies. After this step, the number of studies was reduced to 49. In the last filtering round, we fully read the remaining 49 papers, applied the inclusion and exclusion criteria on the whole text, and ended up with 44 included studies.
After finishing the three filtering rounds, we started performing the snowball search method [77]. This step added seven papers. Hence, the total number of included studies was raised to 51 papers.

Results
In this section, we provide a descriptive analysis of the included papers in this SLR, and then present the results and answers to our four research questions. Figure 2 shows the years when our 51 included studies were published. The graph shows a peak of 10 publications in 2015, which indicates an increase in interest in the research filed compared to previous years, especially the time between 2005 and 2012 where the number of publications was three or less each year. Figure 3 shows the venues where the included studies were published. The graph shows that most of the publications were made in conferences and workshops (18 and 17 respectively). 13 of the papers were published in journals, and three were technical reports. We also looked into the authors of the selected papers to find the portion of the papers with at least one author from industry. We found that less than 25% (12 papers) [16,28,51,50,79,24,57,11,49,26,14,38] included at least one author from industry.

RQ1: Motivation
In order to find the rational reported in literature for the adoption of SAC, we looked into motivations and usage scenarios, as explained in 3.1. Some of the identified motivations in RQ1.1 could also be seen as usage scenario. For example, compliance with standards and regulation could be seen as a motivation for using SAC, but also as a purpose for which SAC could be used.

Motivation
Generally speaking, the main reason that motivates usage of SAC is to perform security assurance on a system. In this study, we looked for other motivations, and more specific ones. We extracted this piece of information by looking for motivations to use SAC rather than the suggested approach or method for creating them. In some of the papers, the motivation was made explicit in a separate section, or as the focus of the whole study (e.g. [41,4]). However, in most papers, this was discussed either in the introduction and background sections, or as a part of motivating the used or suggested approach for creating SAC. If a study discusses only the basic SAC benefits, or is not being specific about the motivation (e.g. motivates security assurance in general), then we have categorised this paper as one that did not discuss any motivations for using SAC. Table 7 shows all motivations found in the 51 studies included in this paper. The results show that about 73% of the studies included at least one motivation for using SAC other than security assurance. The most common motivations are: (i) compliance with standards and regulation (8); (ii) it is a proven approach from the safety domain (6); and (iii) compliance with requirements (4). Categorizing the motivations resulted in the following categories: -External forces: Compliance with standards and regulation, and compliance with requirements (in case of suppliers). -Process improvement: SAC helps in integrating security assurance with the development process. Moreover, they help factoring work per work items, and analyzing complex systems.  -Structure and documentation: The structure of SAC implies a way of work that reduces technical risks, and enhances security communication among stakeholders. -Security assessment: SAC help in assessing security and spotting weaknesses in security for the systems in question. Hence, they help building confidence in the those systems. -Knowledge transfer: It is a proven approach in safety which has been used effectively for a long time, and could be similarly in security.

Usage Scenarios
While SACs are usually used to establish evidence-based security assurance for a given system, researchers have reported cases where SAC could be used to achieve dif- Ankrum et al. [5] External forces Comply with standards and regulation Calinescu et al. [12] External forces Comply with security requirements of safety-critical systems Cyra et al. [18] External forces Comply with standards and regulation Finnegan et al. [20] External forces Comply with regulation and maintain confidence in the product in question Finnegan et al. (2) [21] External forces Comply with regulation He et al. [35] External forces Reason about cybersecurity policies and procedures Mohammadi et al. [47] External forces Learn from the safety domain where it is a proven approach Ray et al. [56] External forces Comply with regulation and internal needs from cyber-physical systems' manufacturers Sklyar et al. (2) [63,65,64] External forces Comply with standards Sljivo et al. [66] External forces Comply with standards and regulation Strielkina et al. [69] External forces Comply with security regulation Goodger et al. [28] Knowledge transfer Learn from the safety domain to integrate oversight for safety and security Ionita et al. [38] Knowledge transfer Learn from the safety domain where it is a proven approach Netkachova et al. (2) [49] Knowledge transfer Learn from the safety domain where it is a proven approach Poreddy et al. [55] Knowledge transfer Learn from the safety domain, where it is a proven approach Sklyar et al. [62] Knowledge transfer Learn from the safety domain, where it is a proven in-use approach Ben Othmane et al. [7] Process improvement Trace security requirements and assure security during iterative development. Ben Othmane et al. [8] Process improvement Assure security during iterative development Cheah et al. [14] Process improvement Cope with the increasing connectivity of systems Cockram et al. [16] Process improvement Reduces both technical and program risks through process improvement Gallo et al. [26] Process improvement Factor analytical and implementation work per component, requisite, technology, or life-cycle Lipson et al. [42] Process improvement Help analyzing complex systems Netkachova et al. [50] Process improvement Tackle security issues which have intensified challenges of engineering safety-critical systems. Weinstock et al. [75] Process improvement Include people and processes in security assurance in addition to technology Alexander et al. [4] Security assessment Help security evaluators to focus their attention on critical parts of the system Bloomfield et al. [11] Security assessment Ensure the fulfillment of security requirements Finnegan et al. [21] Security assessment Improve overall security practices and demonstrate confidence in security Hawkins et al. [34] Security assessment Justify and assess confidence in critical properties Knight [41] Security assessment Spot security related weaknesses in the system Poreddy et al. [55] Security assessment Assist in identifying security loopholes while changing the system Rodes et al. [57] Security assessment Measure software security Strielkina et al. [69] Security assessment Acquire an input for decision making of requirement conformity Vivas et al. [74] Security assessment Acquire confidence that the security of the system meets the requirements Agudo et al. [3] Structure & documentation Incorporate certifications and evaluation methods in an evidence-based structure Alexander et al. [4] Structure & documentation Summarize security thinking when vendors are involved Finnegan et al. [22] Structure & documentation Communicate and report achieved security level Knight [41] Structure & documentation Document rational for security claims Netkachova et al. [51] Structure & documentation Aid in communication as it provides a summary of issues and their interrelationship Patu et al. [54] Structure & documentation Aid in the survival of modern system, with respect to security challenges Ray et al. [56] Structure & documentation Comply with internal needs from cyber-physical systems' manufacturers ferent goals. We looked into studies that focus on using SAC for a purpose other than security assurance, or that is specific to a certain domain (e.g. security assurance for medical devices), or context (e.g. security assurance within the agile framework). Table 8 shows the usage scenarios of SAC found in literature. We were able to extract usage scenarios from 14 different papers (28% of the total number of papers). The usage scenarios found show a wide range of applications of SAC. Seven of the papers suggest using SAC for evaluating different parts of the system or its surroundings. This includes evaluating the system architecture [80], security in a specific context [49], confidence in security [57], trustworthiness of the system [47], validation of service grade [44], satisfaction of requirements [33], and security standards [30]. The remaining seven papers suggest using SAC for process improvement [3], development of security features [7,8], development of security policies and strategies [11], asset management [28], and teaching information security [26].

RQ2: Approaches
We were able to find 26 different approaches in the literature. These studies focus on creating either complete security assurance cases, or parts of them (argumentation, or evidence). Table 9 shows the found approaches, which part/s of SAC they cover, argumentation strategies used to divide the claims and create the arguments, and the evidence used to justify the claims in the approaches. We categorize the approaches as follows: -Integrating SAC in the development life-cycle: These approaches suggest mapping the SAC creation activities to the development activities to integrate SACs in the development and security processes [3,8,56,74], as well as assurance case driven design [62,63,65,64]. -Using different types of AC for security: These approaches suggest using different types of assurance cases other than SAC for security assurance. These types are: trust cases [18], trustworthiness cases [29,47], combined safety and security cases [16],dynamic assurance cases [12],multiple viewpoint assurance cases where security is treated as an assurance viewpoint [66], and dependability cases [53]. -Documenting and visualizing SAC: These studies give guidelines of how to document a SAC, and visualize it [55,17,75]. In this category there are papers that focus on a specific part of SAC. These are: Argumentation-centric: These approaches focus on the argumentation part of the SACs. Different strategies are suggested in literature: security standards-based argument [18,20,5], and satisfaction argument [33]. Structures of argumentation found in literature are: model-based [34], and layered structure [51,79]. Moreover, we have one study which suggests an automatic creation of argument graphs [72].
Evidence-centric: These approaches focus mainly on different aspects of SACs' evidence. These aspects are: searching for evidence [15], collecting and generating evidence [60,42], and rating of potential artifacts to be used as evidence [14].

Coverage
As shown in Table 9, 16 of the found approaches cover the creation of complete SACs, six focus on argumentation, and the remaining four on evidence. Five out of the 16 studies to create complete security cases did not include any examples of evidence used to justify the claims.

Argumentation
Argumentation is a very important part of SAC, and forms the bigger part of it. The argumentation starts with a security claim, and continues as the claim is being broken down into sub-claims. The strategy is used to provide a means by which the breaking down of claims is being done. Each level of the argumentation could be done with a different strategy than the other levels. Hence, one SAC might have one or more argumentation strategies, which is the case in some of the included studies in this SLR. We looked for an explicit mention of the used strategy. If none was provided, we looked into the example cases to find the used argumentation strategy. Here, we look at the argumentation strategies used in the different approaches. We could not find any correlation between the approach, and the argumentation strategy used in the approach. For instance, the approaches which integrate SAC within the development life-cycle can have different argumentation strategies, e.g., requirements [3] and development phases [56]. The most common strategy depends on the output of a threat, vulnerability, asset or risk analysis (8 papers). Other popular strategies are: breaking down the claims based on the requirements, or more specifically quality requirements and even more specifically security requirements (5 papers), and arguing based on security properties (5 papers). Additionally, researchers also used system and security goals (4 papers), software components or features (3 papers), security standards and principles (2 papers), pre-defined argumentation model (1 paper), and development life-cycle phases (1 Agudo et al. [3] Integrating security engineering and assurance based development using SAC Ben Othmane et al. [7] Controlling the impact of incremental development on security assurance using SAC Ben Othmane et al. (2) [8] Developing iterative security features using SAC for security assurance Bloomfield et al. [11] Using SAC in the development of security strategies and policies Finnegan et al. [22] Reporting the achieved security level using SAC Gallo et al. [26] Using SAC to teach information security Goodger et al. [28] Asset management Graydon et al. [31] Evaluation of security standards Haley et al. [33] Using SAC to prove achieving satisfaction of security requirements Masumoto et al. [44] SAC is used to validate that a service satisfies a certain service grade Mohammadi et al. [47] Ensuring trustworthiness in cyber-physical systems using trustworthiness cases. Netkachova et al. (2) [49] Evaluation of security of critical infrastructures using SAC Rodes et al. [57] Measuring software security based on confidence in security argument Yamamoto [80] Evaluation of system architecture based on security claims paper). Table 9 shows the approaches we found in literature with the respective argumentation strategies used in each of them.

Evidence
Even though evidence is a very important part of SAC, and a complex one as well, only four of 26 included approaches focused on it. Even in the generic approaches, there was a much deeper focus on the argumentation than the evidence. This explains why five out of the 16 generic approaches did not even include an example of what evidence would look like in their approach. We found evidence either by looking for explicitly mentioned ones in the articles, or by extracting the evidence part from the reported SACs. Cheah et al. [14] present a classification of security test results using security severity ratings. This classification can be included in the security evaluation, which may be used to improve the selection of evidence when creating security assurance cases. Chindamaikul et al. [15] investigate how information retrieval techniques, and formal concept analysis can be used to find security evidence in a document corpus. Shrott and Weber [60] present a method to apply fuzz testing to support the creation of evidence for security assurance cases. Lipson and Weinstock [42] describe how to understand, gather, and generate multiple kinds of evidence that can contribute to building SAC. The most common types of evidence reported in literature are testing results (12 papers) [7,12,14,15,42,55,60,62,63,65,64,66], and different types of analysis. These analysis include threat and vulnerability [16,20,21,53], code and bug [15,7,62,63,65,64], security standards and policies [3,51], risk [47], and log analysis [47,53]. Other types of evidence reported in literature include process documents [42], design techniques [47], and security awareness and training [53,42]. Table 9 shows the approaches we found in literature with the respective evidence types used in each of them.

Tools:
We found 16 software tools which have been used one way or another in the creation on security assurance cases in literature. Seven out of the found tools were created by the researchers. Four of these seven target assurance cases in general [23,24,34,72], while the remaining three are created to be used in the creation of SAC specifically [7,14,60]. Table 10 shows the found tools, and the respective studies in which the tools are used. A brief description of the main functionalities of the tools, as well as whether the tools are created or used by the authors are also presented. There are four main types of reported tools:  [76,7,14], maintenance of SAC [23], and management of different parts of SAC [71].
In addition to these software tools, a concept called concept lattice was used as a tool to help users determine the relevance of a given document to be used as an evidence [15].

Prerequisites:
Prerequisites are the conditions that need to be met in order for the outcome of a study to work or be applied. We found prerequisites in the included studies by checking the inputs of the proposed outcomes (approaches, usage scenarios, tools, and patterns). If an input is not a part of the outcome itself, we considered it to be a prerequisite to that outcome. Table 11 shows the found prerequisites, and the respective type of study for each. There are 17 reported prerequisites. The majority belong to approaches (11) and the remaining belong to usage scenarios (3), patterns (2), and tools (1). We categorize the prerequisites in four categories as follows: -Usage of specific format [24,34,66] -Existence of analysis and modelling [14,28,54,79] -Usage of specific documents and repositories [15,16,35,53,72,74], and security standards [5,31,18] -Existence of special expertise [11]

Patterns
Patterns of SAC exist, as there are reoccurring claims and arguments. Using patterns can save the creators of SACs a lot of time and effort. We found ten studies which deal with patterns. Six of these create their own argumentation patterns [20,21,35,54,55,79]. The remaining four include usage of patterns [34,72], a guideline for creating and documenting security case patterns [75], and a catalogue of security and safety case patterns [70]. In some studies, the examples are taken from the safety domain, and there is a usage of safety patterns e.g. [12]. However, in this study, we only considered patterns created and used for security assurance cases. Table 12 shows the papers that deal with security assurance case patterns.

Notations
41 out of our 51 included papers specify at least one notation to be used for expressing and documenting a SAC. The most common notation is the Goal Structure Notation (GSN) [67] which is suggested by 26 studies. Another popular notation is the Claim Argument Evidence (CAE) [1] notation which is suggested by nine studies. Other notation are: text (6 studies), concept maps [17] (1), and Claim-Argument-Evidence Criteria Table 11 RQ3 -Papers discussing the prerequisites of SAC approaches, usage scenarios, and tools.

Study Type of study Prerequisites
Ankrum et al. [5] Approach Security standards Bloomfield et al. [11] Usage scenario Special expertise (regulator in this case) Cheah et al. [14] Approach Threat model Chindamaikul et al. [15] Approach Evidence corpus Cockram et al. [16] Approach Module boundary contract Cyra et al. [18] Approach Security standards Gacek et al. [24] Tool Use of AADL (Architecture Analysis and Design Language) Goodger et al. [28] Usage Scenario Asset and vulnerability analysis Graydon et al. [31] Usage Scenario Security standards Hawkins et al. [34] Approach Argument patterns, and models containing needed information for instantiation He et al. [35] SAC Pattern Lessons learned Patu et al. [54] SAC patterns Asset analysis Patu et al. (2) [53] Approach A pre-defined list of common risks/vulnerabilities and solutions in the domain Sljivo et al. [66] Approach Contracts in the extended SEooCMM format (a special format) Tippenhauer et al. [72] Approach Graph extension templates, and sub-graphs derived from security assessment Vivas et al. [74] Approach Well defined SDLC (Software Development Life-Cycle) process Xu et al. [79] Approach Threat model, and asset model

Study Description of the pattern-based approach
Finnegan et al. [20,21] Creation of security capability argument pattern which takes a risk based approach, and argues for each security capability defined in a technical report for risk management in medical devices. Hawkins et al. [34] Usage of argument patterns as input to the model-based approach for building assurance case arguments. A suggested pattern argues over individual software components. He et al. [35] Creation of generic cases which use security arguments that are informed by security incidents in healthcare organizations. Patu et al. [54] Creation of security patterns at the requirement phase of the system development life-cycle. One suggested pattern argues over security attributes. Poreddy et al. [55] Creation of assurance case patterns, suggested argumentation strategies are: integrity, availability, reliability, confidentiality and maintainability. Taguchi et al. [70] A catalogue of safety and security case patterns. The patterns are derived from process patterns through a literature survey. Tippenhauer et al. [72] Usage of argument patterns to automatically generate argument graphs. The paper includes five different patterns categorized into two categories: inter-type, and intra-type. Weinstock et al. [75] A guideline of how to create and use security assurance case patterns is presented. An example pattern is also presented. Xu et al. [79] Creation of different argument patterns to be used in different layers to form a layered argument structure.

RQ4: Validation
We consider validation to be the process to confirm the applicability of an outcome in the selected studies as validation. In case validation is performed in a selected study, we looked for the type of validation, the domain of application, the source of data, whether a SAC is created during the validation, the creators of the SACs, and who performed the validation. Table 13 shows the results of RQ4. As shown in the table, 36 studies include a validation of the outcome. The majority of the outcomes (21) were validated using illustrative cases, 11 were validated using case studies, and the remaining four used experiments (3) and observation as a part of an Action Design Research (ADR) [59] study. The data sources vary among the validations, as can be seen in Table 13. We categorize these sources into three main categories: -Research, open source, and in-house projects (20) [5,15,16,17,24,33,34,47,51,53,55,56,57,60,64,66,69,72,74,26] -Commercial products / systems (9) [7,8,12,14,28,29,44,79,49] -Standards, regulation, and technical reports (7) [11,18,21,23,31,35,65] SACs were presented in 31 out of the 36 validations. Representing a complete SAC is in most cases not possible even in small illustration cases, because of the amount of information required to build one. However, the scale of SAC representation in the included validations varies to a large extent. Some validations present an example of a full branch of SAC, i.e., a claim all the way from top to evidence (e.g., He and Johnson [35]), while others present very brief examples of SACs (e.g., Gallo and Dahab [26]). Table 13 also shows the creators of the SACs in each study. In only two cases, experts were used to create the SACs. In the majority of the studies (28), the authors created the SACs. However, eight of these had authors from industry. These are shown in Table 13 as Authors* in the Creators column. Table 13 also shows the domains in which the validation was conducted. The most common domains are: Software Engineering (7), and Medical (7).
The last column in Table 13 shows the persons which performed the validation in each study. Out of the 36 included validations, only five used 3rd parties to validate the outcomes. In the remaining 31 validations, the authors performed the validation. However, eight out of these had authors from industry. These are shown in Table 13 as Authors* in the Validator column.

Discussion
Our findings show that the area of security assurance cases has not yet reached the same level of maturity as their safety counterpart has. In the following subsections, we will list the various reasons for that.
We also realised through our study that there is agreement about how security assurance cases are constructed in the literature. However, this agreement is not expressed in sufficient level of detail in any one paper yet. Therefore, we have synthesised the existing knowledge into a generic workflow for the construction of SAC that is presented in Section 5.5.
Main insights into the body of knowledge: -Many good motivations and usage scenarios, but not reflected. -Room for creativity, and making use of the knowledge in safety in the approaches.
-Room for improvement on the support (tools and patterns) -Lack of industrial validation of both approaches and usage scenarios Synthesis is workflow which combines the different ideas and approaches from the body of knowledge

Motivation and usage scenarios
We were able to identify many motivations and usage scenarios from literature for using SAC. However, our impression is that these are on a high level and lack detailed studies to show how realistic and applicable they are. For example, many papers motivate SAC for compliance with regulation and standards. However, they do not pinpoint the specific requirements for using SAC in these regulation and standards. It is hard to determine whether SACs are explicitly required, or if it is recommended as a way to create a structured argument for security without having previous knowledge of the specific regulation or standard.

Approaches
Most of the reported approaches to create complete assurance cases (including the argumentation and evidence) are top-down. That is, they start building from a top claim, all the way to sub-claims and evidence. Yamamoto [80] who made an evaluation of architecture based on security and safety claims used a bottom-up technique starting from the evidence all the way up to the strategy and first claim. No approach suggests a bottom-up approach starting from the evidence, i.e., building up from the existing evidence to form the argumentation and conclude what can be claimed about the system's security. This approach can be useful if the SAC is built for an already existing system. The evaluation can be then done between the "what we can claim", and the "what goals and requirements does the system have" questions. However, some of the selected studies used a hybrid approach where the SACs were still created top-down, but some parts of them were built using bottom-up techniques. An examples of a bottomup technique used in literature is FMEA [68] used in two studies [34,22]. Many of the approaches presented in literature treat security and safety cases as the same artifacts, e.g., [15,31,34,66,28,23,5,24,64,65]. We believe that since assurance cases in general are mature in the safety domain and have been used for a long time, it is natural to consider the gained knowledge and transferring it into other domains, such as the security domain. However, this knowledge transfer has to take into consideration the differences between safety and security e.g. in terms of field maturity and nature. Although we decided to include these studies in this SLR, we still think that their applicability in security needs further investigation taking into consideration the differences between the domains. Alexander et al. [4] have a discussion on the differences between safety and security both from theoretical, and practical aspects. Other studies combine security and safety assurance by creating combined arguments or security-informed safety arguments [70,50,16,51]. Another observation we made is the lack of quality assurance in the approaches. The approaches to create the arguments for example do not discuss the ability of the approach to assure the quality of the argumentation when it comes to its completeness, i.e., does the argumentation cover all and only the relevant security claims of the system? When it comes to the evidence creation approaches, there is a lack of quality assurance of confidence of the evidence, i.e., how confident are we that the provided evidence are enough to justify the claims associated with it?

Validation
Our results show a clear domination of illustration as the chosen type of validation in the included literature, which is an indicator of lack of industrial involvement. This explains why the majority of data used for validation are from research projects and example systems. Furthermore, the creation and validation of SAC in literature is mainly done by the authors of the studies, except for a few cases. We believe that this contributed heavily to the lack of studies that address challenges and drawbacks of applying SACs in an industrial context.
It is fair to say that based on literature, applying SAC is not a trivial task, and doing so in an industrial context increases the complexity drastically. However, most of the reported motivations and usage scenarios are applicable in industry. Hence, there is a clear gap between research and industry, which needs to be addressed and closed.

Tools
Despite the fact that many of the selected papers included an example of a SAC, only a few reported on supporting tools for creating these cases. By extracting tool support information, it became clear that there is no set of commonly used tools for performing security cases tasks, such as creation documentation and maintenance. In fact only one tool, ASCE [2], has been reported to be used in more than one study. Moreover, there is a lack of tools addressing complex issues in SAC, such as claims dependencies, traceability, and quality control, e.g., evidence coverage. We did identify tools that address some of these matters [23,60], but we believe there is a need for validating these in industry and specifically for security cases.

SAC creation workflow
Based on the results of this systematic literature review, we have found that the outcomes of the literature fall in one or more parts of the workflow depicted in Figure 4. Our flow diagram follows the top-down approach used in most reported approaches in literature.
Ankrum et. al. [5] created a non-deterministic workflow for developing a structured assurance case. However, the proposed flow does not include anything related to tools or patterns usage. It does not consider the preliminary stage of considering a SAC either. Cyra and Gorski [18] present the life-cycle, derivation procedure, and application process for a trust case template. All these artifacts, however, build on the argumentation strategy being derived from a standard, which is not always the case.
There are five main blocks in the workflow. We will list and describe them in the remainder of this subsection. Additionally, we recommend papers to read which focus on aspects related to the individual blocks.
Study and understand SAC: Building SACs is not trivial. It requires a lot of work and dedication. Hence, before going ahead and creating them, it is important to understand what they are and what they can be used for. This step includes studying the structure of SACs, their benefits, what needs to be in place to create them, and their potential usage scenarios, e.g., standards and regulation compliance. Figure 5 shows the corresponding entity in the workflow with the recommended papers, which are [4,75,41,3,10,26,8].
Argumentation: This block, which is depicted in Figure 6, includes selecting the top claim to achieve, and the strategy to decompose this claim into sub-claims. This is a very important step, as selecting an argumentation strategy decides to a big extent what activities are needed to complete the SAC. For example, if a strategy where the decomposition is based on vulnerabilities is adopted, a vulnerability analysis of the system in question has to be conducted. The papers we recom-  [74,79,47,72,34,17,3,7] A subblock of the argumentation is the usage of patterns. Patterns help the creators of SACs to save time and effort by using pre-defined and proven structures. The creators could, however, decide not to use a pattern, and create their own unique structure if the situation requires that. Creating a pattern is done based on the knowledge gathered while creating SACs. It is outside the scope of this workflow. However, this is discussed in the recommended papers [75,70,54,20,21]. Evidence: This block is shown in Figure 7, and includes locating, collecting, and assigning evidence to the claims of the SAC. In some cases, the evidence is not present when the SAC is being built; hence, they need to be created. In our workflow, this would be a part of the collect evidence activity. Moreover, these activities might be done in an iterative manner. We consider the iterations to include an assessment of the SAC, e.g., to determine whether a claim needs extra evidence to reach a certain confidence level. For this block, we recommend these papers [42,15,14,60]. Documenting: This block is depicted in Figure 8. It includes making a decision of whether or not to use a tool for modelling the argument and documenting the SAC. If a tool is used, then the notation to be used is limited to the one/s supported by the tool. If a manual representation is to be done, then the creators will have the freedom to use an existing notation, extend one, or even create their own. We recommend the papers [38,72,7,55] for this block.
Assessment: This block is shown in Figure 9 and focuses on assessing SACs. This is done to check the quality of the created SAC, and determine whether it OK Assess SAC Chindamaikul et al. [15] Rodes et al. [57] Fig. 9 Corresponding entities and recommended studies for the Validation block is sufficient, or needs additional work. Assessment starts after the claims have been identified and the evidence is assigned to the corresponding claims. The result of this step might require the creators of the SAC to go back to the point where they assess a claim and make a decision whether or not to further decompose it or assign evidence to it. Since there is a lack of studies that focus on quality assurance of SAC, we have recommended studies which include some metrics to help assessing SACs [57,15].

Validity Threats
In this study, we consider the internal and external categories of validity threats as defined in [13], and described in [78,40]. The work of conducting the review was done by one researcher. This means that applying the inclusion / exclusion criteria in each of the four filtering rounds was done by one person. This imposes a risk of subjectivity, as well as a risk of missing results, which might have affected the internal validity of this study. To mitigate this, a preliminary list of known good papers was manually created and used for a sanity check of the selected and included papers. Additionally, a quality control was performed periodically by the other authors to check the included and excluded studies.
Restricting our search to three digital libraries could have increased the probability of the risk of missing relevant studies. This was mitigated by performing the snowballing search to search for papers that are not necessarily included in the databases of the three considered libraries.
Another threat to validity is publication bias [40]. This is due to the fact that studies with positive results are more likely to get published than those with negative results. This could compromise the conclusion validity of this SLR, as in our case we did not find any study that is, e.g., against using SAC, or which reported a failed validation of its outcome. To mitigate this, we have scanned gray literature as part of the snowballing search. Additionally, in our preliminary work, we scanned the proceedings of eight conferences in the past five years.
External validity depends on the internal validity of the SLR [40], as well as the external validity of the selected studies. We did scan gray literature to mitigate publication bias, but we excluded studies that are under 3 pages, and old studies as exclusion criteria to mitigate the risk of including studies with high external validity threats.
When it comes to the reliability of the study, we believe that any researcher with access to the used libraries will be able to reproduce the study, and get similar results plus additional results for the studies which get published after the work of this SLR is done.

Conclusion and future work
In this study, we conducted a systematic review of the literature on security assurance cases. We used three digital libraries as well as snowballing to find relevant studies. We included 51 studies as primary data points, and extracted the necessary data for the analysis. The main findings of our study show that many usage scenarios for SAC are mentioned, and that several approaches for creating them are discussed. However, there is a clear gap between the usage scenarios and approaches, on one side, and their applicability in real world, on the other side, as the provided validations and tool support are far from being sufficient to match the level of ambition. Based on the results of this systematic literature review, we created a workflow for working with SAC, which is a useful tool for practitioners and also provides a guideline on how to approach the study of the literature, i.e., which paper is relevant in each stage of the workflow.
Based on our results and findings, in the future we will be working to close the gap between research and industry when it comes to applying security assurance cases. We will be looking into exact needs and challenges for these cases in specific domains, e.g., automotive. We believe that introducing SAC in large organizations needs appropriate planning to, e.g., find suitable roles for different tasks related to SAC, and integrating with current activities and way of working. Hence, we see a potential direction of future work in that area.
When it comes to the technical work, we believe that there is room for improvement in the approaches for SAC creation, especially when it comes to the evidence part. For instance, a possible future work direction is to look into ways to automatically locate, collect, and assign evidence to different claims.
Finally, we believe that quality assurance of SAC has not been addressed sufficiently in literature. As a future work, we will look into ways to ensure the completeness of a security case when it comes to the argumentation, as well as the confidence in how well the provided evidence justify these claims.