Get 20M+ Full-Text Papers For Less Than $1.50/day. Start a 14-Day Trial for You or Your Team.

Learn More →

CASCADE: An Asset-driven Approach to Build Security Assurance Cases for Automotive Systems

CASCADE: An Asset-driven Approach to Build Security Assurance Cases for Automotive Systems CASCADE: An Asset-driven Approach to Build Security Assurance Cases for Automotive Systems MAZEN MOHAMAD, Chalmers and University of Gothenburg, Sweden RODI JOLAK, Chalmers and University of Gothenburg, Sweden ÖRJAN ASKERDAL, Volvo Trucks, Sweden JAN-PHILIPP STEGHÖFER, Chalmers and University of Gothenburg, Sweden RICCARDO SCANDARIATO, Hamburg University of Technology, Germany Security Assurance Cases (SAC) are structured arguments and evidence bodies used to reason about the security of a certain system. SACs are gaining focus in the automotive industry as the needs for security assurance are growing in this domain. However, the state of the arts lacks a mature approach able to suit the needs of the automotive industry. In this paper, we present CASCADE, an asset-driven approach for creating SAC, which is inspired by the upcoming security standard ISO/SAE-21434 as well as the internal needs of automotive Original Equipment Manufacturers (OEMs). CASCADE also diferentiates itself from the state of the art by incorporating a way to reason about the quality of the constructed security assurance case. We created the approach by conducting an iterative design science research study. We illustrate the results using the example case of the road vehicle’s headlamp provided in the ISO standard. We also illustrate how our approach aligns well with the structure and content of the ISO/SAE-21434 standard, hence demonstrating the practical applicability of CASCADE in an industrial context. Additional Key Words and Phrases: security, assurance cases, automotive systems 1 INTRODUCTION Assurance cases are structured bodies of arguments and evidence used to reason about a certain property of a system. Security Assurance Cases (SAC) are a type of assurance case for the ield of cyber-security. In this paper, we turn our attention to the creation of a SAC, with a particular focus on the domain of automotive applications. As vehicles become more advanced and connected, security scrutiny has increased in this domain. Furthermore, new standards and regulations push towards assuring security for vehicular systems by using SAC. Similar to safety cases, which are required in safety standards, e.g., ISO-26262 19], SACs [ are explicitly required in ISO/SAE-2143420 [ ]. Additionally, SACs are required for all systems in production. In literature, some studies suggest the creation of SAC based on requirements derived from security standar 6, 9ds ]. Ho [ wever, there is no approach which helps to achieve conformance with the upcoming ISO/SAE-21434 standard. Additionally, since the requirements for SAC are new, there is no evidence in the literature that the knowledge base in industry is mature enough to achieve conformity to these requirements. Moreover, quality assurance of the SACs is missing in the reported approaches in literature, even though it is a very important aspect. In order for diferent stakeholders to use an SAC, it is essential to trust that the SAC’s argument is built with a suicient level of completeness, and that the evidence provides a suicient level of conidence to justify the targeted claims. Finally, Authors’ addresses: Mazen Mohamad, mazen.mohamad@gu.se, Chalmers and University of Gothenburg, Gothenburg, Sweden; Rodi Jolak, rodi.jolak@cse.gu.se, Chalmers and University of Gothenburg, Gothenburg, Sweden; Örjan Askerdal, orjan.askerdal.3@volvo.se, Volvo Trucks, Gothenburg, Sweden; Jan-Philipp Steghöfer, jan-philipp.steghofer@gu.se, Chalmers and University of Gothenburg, Gothenburg, Sweden; Riccardo Scandariato, riccardo.scandariato@tuhh.de, Hamburg University of Technology, Hamburg, Germany. Permission to make digital or hard copies of part or all of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for proit or commercial advantage and that copies bear this notice and the full citation on the irst page. Copyrights for third-party components of this work must be honored. For all other uses, contact the owner/author(s). © 2022 Copyright held by the owner/author(s). XXXX-XXXX/2022/11-ART https://doi.org/10.1145/3569459 ACM Transactions on Cyber-Physical Systems 2 • Mazem Mohamad et al. we identiied that the lack of industry involvement is a signiicant issue in current approaches. This results in gaps between research and industry. To bridge these gaps, we have worked together with Volvo Trucks and Volvo Cars, two international automotive OEMs located in Sweden, to develop CASCADE, the asset-driven approach for SAC creation presented in this paper. CASCADE is inspired by the structure of requirements and work products of ISO/SAE-21434. It is asset- driven, i.e., the resulted SACs have assets as drivers of the structure of the security arguments. Therefore, it allows creating security assurance based on what is valuable in the system. Additionally, we integrated quality assurance in SACs created with CASCADE by distinguishing between product-related claims and case quality-claims, as well as building arguments for both. CASCADE also governs where in the argument these case quality-claims need to be introduced. From a methodological standpoint, we created and validated our approach in a three cycle design science research study as follows. First, we created a high-level structure of an asset-driven SAC, which included the identiication of the assets, the tracing of such assets to system elements (e.g., processing, communication, and storage operations), and the identiication of the relevant security assets for each asset. Second, we improved the structure of CASCADE to better align with the development activities at automotive companies and better cover their needs for SAC including the need to confront with ISO/SAE-21434. We then illustrated the approach using the exemplary case study mentioned in ISO/SAE-21434. Finally, we presented the resulting approach to the security experts from an industrial automotive OEM and gathered their feedback. Lastly, we further evaluated CASCADE by mapping the requirements and work products of ISO/SAE-21434 standard to the corresponding CASCADE elements. We analyzed the results and created a guideline for practitioners and researchers to enable the replication of the mapping activity on the same or a diferent standard. The results are presented in Sections 4ś7, after discussing the related work in Section 2 and the methodology in Section 3. This work is an extension of a previously published23study ]. The[overall contributions of this work are the following: • CASCADE, an asset-driven approach for the creation of the security assurance cases, which is inspired by the upcoming security standard in the automotive domain. CASCADE also diferentiates itself from the state of the art by incorporating a way to reason about the quality of the constructed security assurance case. • A validation of the CASCADE approach by (i) involving an automotive OEM located in Sweden and (ii) illustrating how CASCADE aligns with the structure and content of the ISO/SAE-21434 standard, hence demonstrating the practical applicability of CASCADE in an industrial context. • A guideline to map items of security standards to the elements of a CASCADE security case. This guideline helps practitioners to fulill their compliance requirements. 2 BACKGROUND AND RELATED WORK In this section, we provide background information about SAC, security assets in automotive, and their corre- sponding security threats and attacks. We also review related work of asset-based approaches in the literature. 2.1 Security Assurance Cases Assurance cases are bodies of evidence organized in structured arguments, used to justify that certain claims about a system’s property hold [11]. They are deined by the GSN standard [12] as A ł reasoned and compelling argument, supported by a body of evidence, that a system, service or organisation will operate as intended for a deined application in a deined environment.ž ACM Transactions on Cyber-Physical Systems CASCADE: An Asset-driven Approach to Build Security Assurance Cases for Automotive Systems • 3 Security Assurance Case (SAC) are a special type of assurance cases where the argument consists of claims about security for the system in question, and the evidence justiies these security-related claims. SAC consist of the following primary components [5, 21]: • Security claims: These claims vary in terms of abstraction level. At the beginning of the argument, they are high level, but then they get more ine-grained as the argument evolves. The claims are usually derived from requirement speciications of the system in question. • Context: This refers to the context in which the claims should hold. In other words, it sets the scope of the argument. For example, a context could be a document that deines the required level of security desired by the organization creating the SAC. • Strategy: Building the argument means that the claims are decomposed into sub-claims in an iterative manner until they reach a point where evidence can be assigned to support them. During this process, decisions have to be made on how to decompose a certain claim, e.g., by considering the diferent security properties or diferent possible threats. These decisions are called strategies in SAC. • Evidence: A body of evidence is provided to prove the claims created in the argument. An example of a piece of evidence is a test report showing that the code base of a certain ECU passes all the tests. Another example is a report created by a security expert which proves that a realization of a vulnerability is not possible. SAC can be expressed in a textual or graphical format 5]. The [ most common graphical formats are the Goal Structure Notation (GSN, [27]), and the Claims, Arguments, and Evidence notation (CAE, [1]). 2.2 Automotive Assets and Related Security Threats According to26 [ ], there are four categories of assets in automotive systems that are targeted by security threats and attacks. These assets are hardware, software, network and communication, and data storage. • Hardware: This asset category includes sensors, actuators, and the hardware part of the Electronic Control Units (ECUs). These assets are often threatened by disruption or direct interventions that inluence their availability and integrity. Examples of attacks on these assets include fault injection through the installation of malicious hardware leading to compromising availability. • Software: This category includes external libraries, Operating Systems (OS), applications, virtualization, and the software part of the ECUs. Security threats and attacks on software assets include the manipulation of software, such as tampering attacks which often target software availability and integrity. • Network/Communication : Refers to internal or external communication. Internal communication assets are busses such as CAN, FlexRay, LIN, MOST, and automotive Ethernet. External communication assets are WiFi, Bluetooth, and Vehicle to Everything (V2X) communication. Examples of attacks on these assets include fabrication or jamming attacks, spooing, message collision, eavesdropping, hijacking, and denial of service (DoS). These attacks might compromise the conidentiality, integrity, and availability of the these assets. • Data storage: Sensitive data including user data, backups, cryptographic keys, forensics logs, and system information and reports. These assets are targeted by unauthorized access and malicious manipulation that often inluence the conidentiality, integrity, and availability of the data. 2.3 Asset based approaches Researchers have been exploring several asset-based approaches for creating the argument part of SAC. Biao et al. [29] suggest dividing the argument into diferent layers, and using diferent patterns (one per layer) to create the part of the argument that corresponds to each layer. Assets are considered as one of these layers, and the pattern used to create it includes claims that the assets are łunder protectionž, and strategies to break ACM Transactions on Cyber-Physical Systems 4 • Mazem Mohamad et al. down critical assets. Biao et29 al. ], ho [ wever, do not consider the quality of the cases and only focus on creating arguments without touching upon the evidence part. Luburic et22al. ] also [ present an asset-centric approach for security assurance. The info used in their approach is taken(i) frasset om: inventories; (ii)Data Flow Diagrams (DFD) of particular assets and the components that manipulate them;(iii) andthe security policy that deines protective mechanisms for the components from the previous point. They propose a domain model where assets are the center pieces. The assets are linked to security goals. The argument considers the protection of the assets throughout their life-cycles by arguing about protecting the components that store, process, and transmit those assets. The SAC they provide is very high level and includes two strategies: łreasonable protection for all sensitive assetsž and arguing over the data-low of each related component. The authors state that the main limitations of their approach are asset and data low granularity. In our study, we consider the assets to be the driver of our approach, but we extend the argument to reach the level of concrete security requirements. We also derive our strategies from an industrial standard and validate our approach in collaboration with an OEM. Furthermore, we extend our approach to include case-quality aspects. 2.4 Standard-based approaches Multiple researchers have explored extracting requirements from security standards for the creation of the arguments of SAC. None of these studies have, however, targeted the upcoming standard ISO/SAE-21434 for cybersecurity in automotive. Finnegan et4,al. 10][present a framework for the creation of security cases for medical devices. Their framework incorporates multiple security documents, e.g., standards and best practices, in order to develop a security argumentation pattern. The pattern provides a compr ł ehensive matrix showing the link between the security risks, associated causes, the mitigating security controls and evidence of those controls being implemented to establish the security capability.ž Ankrum et al. [7] studied the mapping of security and safety standards in safety-critical domains to assurance cases. They used the Goal Structuring Notation (GSN) and ASCAD (Claims ś Arguments ś Evidence) which are the most common notations for documenting assurance cases. The security standard used in the study was the Common Criteria for Information Technology Security Evaluation, ISO/IEC 15408:1999 17]. Ankrum [ et. al describe challenges they encountered while conducting the mapping as well as lessons learned. In this work, we are using the upcoming ISO/SAE 21434 standard to structure an approach for creating SAC, while also considering the industrial needs from the automotive domain. The reason for using this particular standard is that it includes a requirement that explicitly requires a security case to be created. Hence, if a company wants to conform with the standard, it needs to create security cases for its products. However, conformance with the standard is not the only need of automotive OEMs when it comes to assurance cases. We have identiied multiple usage scenarios in our previous 24 work ]. In[order to create SAC that are suitable for these scenarios, the quality aspect of the cases needs to be considered, which we cover in our approach. Birch et al.8][ suggest a layered model for structuring arguments of automotive safety assurance cases. The model is built to help satisfying the requirement to build safety cases in 19ISO ]. It 26262 consists [ of a core argument layer representing the rationale behind safety requirements, as well as three other layers of arguments representing the relationship of the requirements to the corresponding artefacts, the means used in their development and the environment in which safety activities are undertaken. The core argument proposed by Birch et al. serves a similar purpose to our case quality-claims in terms of completeness, but only on the requirements level. In our work, we require such claims to be added every time a decomposition takes place. This diference is due to the diferent natures of functional safety and security. In functional safety assurance cases, the arguments are driven by the requirements, while in our approach, we drive it by assets and only reach the requirements after going through multiple levels of arguments. Moreover, the layered approach includes a layer for the environment and another for the means used in developing. In our approach, we regard these as ACM Transactions on Cyber-Physical Systems CASCADE: An Asset-driven Approach to Build Security Assurance Cases for Automotive Systems • 5 being claims that potentially apply to diferent cases and would be reused, and hence document them in a special argumentation block we call the generic-sub case. Additionally, we consider another type of case quality-claims, which is the conidence claims associated with the evidence. 3 METHODOLOGY Iteration 1: Inception Inception Improvement Mapping Awareness of the Need for an approach to Need to further consider Need for evaluation against problem conform with ISO/SAE internal needs upcoming standards Suggestion Asset-based approach Integrate quality assurance Mapping to ISO/SAE-21434 Development Initial approach CASCADE Mapping table and guidelines Iteration 2: Improvement developed Evaluation Discussion with Illustration on ISO/SAE Lessons learned from the industrial partners 21434 use case + mapping activity evaluation at OEM Conclusion Need to further consider Need for evaluation Potential enhancement and internal needs against upcoming future work standards Iteration 3: Mapping Fig. 1. Three-iteration Design Science Research Design science research is a problem-solving methodology, which aims at developing artefacts to extend existing boundaries in a given conte 15].xtW[e conducted three research iterations, following the design science guidelines proposed by Hevner et al. 15].[ In each iteration we followed the ive-step process proposed by Vaishnavi and Kuechler 28],[ which consists awar of eness of the problem, suggestion, development, evaluation, and conclusionsteps. The three-iteration process is depicted in Figure 1. The igure also shows a brief summary of each design science research step for each cycle. In the irst iteration, Inception, our aim was to address the needs for security assurance cases that were identiied in a previous study 24[]. Speciically, we investigated how an asset-based approach for the creation of security assurance cases can assist automotive companies to fulill their needs to conform with the upcoming ISO/SAE- 21434 standard. We suggested an initial asset-based approach and used an open-source system speciication of a supermarket management system [3] to illustrate it. The approach and the outcome of the illustration were discussed and evaluated with security experts at two large automotive OEMs. The main input from the experts was focused on the need to align the structure of the approach with the internal way of working at the companies, which is also one of the needs identiied in our previous 24].wAnother ork [ aspect of improvement that emerged from the evaluation of the inception iteration is the need for a mechanism to assure the quality of the approach’s outcome. We concluded that there is a need to further consider the internal needs of companies when designing an approach for creating SAC. In the second iteration Improvement, we aimed at incorporating the experience and feedback gathered in the irst iteration in order to improve the asset-based approach. The suggestion of this iteration was to integrate ACM Transactions on Cyber-Physical Systems 6 • Mazem Mohamad et al. quality assurance aspects within the approach. Hence, in the development phase, we created CASCADE, an asset-based approach for SAC creation with built-in quality assurance. The structure of CASCADE is inspired by the structure of requirements and work products of ISO/SAE-21434, and incorporates the need to assure the quality of the SAC. It is based on the requirements that emerged from applying the initial approach as well as on the way of working at the automotive companies we consulted in the irst iteration. To evaluate CASCADE, we applied it on an example case of a vehicle’s headlamp item from ISO/SAE-21434 and presented the outcome to the security experts at two OEMs we also consulted in the irst iteration. As a conclusion of the second iteration, we identiied areas for enhancement of CASCADE to fulill a wider range of the internal needs of the company, as well as the need to assess whether CASCADE has the capacity to include the items of the security standard ISO/SAE-21434. In the third iteration Mapping, we aimed at further validating CASCADE by analyzing the mapping of the requirements and work products from ISO/SAE 21434 to CASCADE elements. The mapping allows us to evaluate CASCADE’s coverage of the items of the standard (requirements and work products) and to point out potential improvements of CASCADE. For each requirement and work product in ISO/SAE 21434 (168 in total), we identiied the corresponding SAC element, CASCADE element, CASCADE block, and CASCADE level it belongs to. Two researchers contributed to the mapping activity to avoid assessment bias. First 17 (10%) of the requirements and work products were selected using the stratiied random sampling method where each clause in the standard was treated as one strata. The two researchers then independently mapped the requirements and work products to CASCADE, and reached an agreement of 71%. For the remaining 29%, there was a calibration exercise where the disagreement was discussed and an agreement on the mapping was achieved for all 17 requirements and work products. The researchers then each worked on half of the requirements and work products, and reviewed the other half. The mapping results are available in the Table in Appendix A. As an evaluation step, we studied the lessons learned from the process and results of the mapping activity and came up with potential enhancements on CASCADE. The result of this step is available in Section 7. Based on the experience gained during the mapping, we constructed a guideline to enable the replication of the mapping activity we conducted in this study, or to test it on other security standards in automotive or other safety critical domains. As conclusion, we identiied areas for future work to further improve CASCADE and its applicability in the automotive domain. 4 CASCADE In general terms, assets are artifacts of interest to a certain entity. In computer security, these artifacts can be hardware, software, network and communication, or data 26].[ The importance of assets makes them the target of attackers. The CASCADE approach for creating security assurance cases takes the importance of assets to organizations into consideration. Hence, it builds the argumentation by putting assets in focus, with the goal to show that these assets are secure from cybersecurity attacks. Our aim is to prove that a given artefact is secure by arguing that its assets are secure. An important design principle in the CASCADE approach is the integration of quality assurance of the cases in terms of argumentation completeness and evidence conidence. Each level of argumentation (i.e., strategy) is associated with at least one claim about the completeness, and each level of evidence is associated with at least one claim about conidence. A similar concept is used by Hawkins 14]ettoal. argue [ about the conidence of safety cases. We use the same security terminologies and concepts used in ISO/SAE 21434. The only exception Security is Goal concept in the standard, which we split up in CASCADE in two diferent levels (security goals and threat ACM Transactions on Cyber-Physical Systems CASCADE: An Asset-driven Approach to Build Security Assurance Cases for Automotive Systems • 7 Top Claim White-hat Block Level 1: Asset identification and decomposition Level 2: Security goals Black-hat Block Level 1: Threat scenarios QA Level 2: Attack paths Resolver Block Level 1: Risk assessment Level 2: Security requirements Evidence QA Fig. 2. The CASCADE approach for creating security assurance cases scenarios). Appendix B includes a table with the core security terms and concepts in CASCADE, their deinitions, and the corresponding ISO/SAE 21434 concepts. 4.1 Elements of an SAC in CASCADE We use GSN [27] to create SAC using the CASCADE approach. The elements of the notation ar (i)e:Claim: a security claim about the artefact in question; (ii)Strategy: a method used to decompose a claim into sub-claims; (iii) Evidence / Solution: a justiication of a Claim / set of (ivclaims; )Context: used to set a scope of a given claim; and (v) Assumption: used to document the assumptions made for a certain claim. In addition to these, we have created additional types of elements to be used in our appr (vi)oach: Case Quality- claims (CQ-claims): represent claims about the quality of the created case (vii) itself; Case Quality-evidence (CQ-evidence): represent evidence used to justify CQ-claims; (viii) andGeneric sub-case: consist of claims, strategies, contexts, assumptions, and evidence that are not bound to a speciic artifact, but instead are applicable to a wider range of artifacts in the context of a product, program, or organization. 4.2 Building blocks of the CASCADE approach The asset-based approach consists of building blocks, as shown in Figure 2. Each block contains a sub-set of the case. In the following sub-sections, we explain the blocks and their contents. 4.2.1 Top claim. This block consists of the top security claim of the artefact in question. It also includes the context of the claim and assumptions made to set the scope of the claim. If we are considering a software In GSN, the terms goal and subgoal are used to refer to high and low abstraction levels of argumentation claims respectively. To avoid confusion, we refer to these as claims. ACM Transactions on Cyber-Physical Systems Generic Sub-case 8 • Mazem Mohamad et al. system, e.g., we might make an assumption that the hardware is secure. The top claim difers between diferent organizations and drives the granularity of the SAC. For example a service provider might consider the security of a service to be the top claim, but an automotive OEM might need to consider the whole vehicle’s security, which requires the incorporation of diferent services or user functions. Similarly, depending on the intended usage of the SAC, the top claim might include back-end systems, or only on-board systems. For example to assure the security of a complete vehicle, it is important to make sure that not only the vehicle’s components are secure, but also the back-end systems which communicate with the vehicle. In contrast, to ensure that a certain end-user function in the vehicle is secure, it might be enough to only consider the corresponding sub-systems in the vehicle itself. As CASCADE does not specify an abstraction level for the top claims of the SACs. Hence, it is possible to create SACs for complete products or for various components or functionalities of a system. However, in the latter case, there is a need for compositional claims combining two or more components, especially when there are inter-dependencies among the components. This might cause the emergence of new assets, security goals, threats... etc. CASCADE does not speciically handle these dependencies, but rather relects the applied security measures and controls. However, it is important to document the scope of the claims in context nodes, as well as all the assumptions made when creating the argument. 4.2.2 Generic sub-caseThis . block contains a sub-case that is applicable not only to the artefact for which the SAC is being created but instead to a larger context. For example, if a company deines a cybersecurity policy, enforced by cybersecurity rules and processes, then the policy can be used in security claims for all its products. These claims can be re-used when creating SAC for individual artefacts. Another example is when certain claims can be made on a product level. Then these claims can be reused for all SAC of individual components of that product. Our aim with this block is to make the approach scalable in larger organizations with complex products and multiple teams. Each team can work on a part of the SAC which corresponds to their artefact. On a higher level, these SAC can be combined together, and generic arguments that are applicable to the sub-SAC can be provided. 4.2.3 White-hat block. This block starts with the identiication of assets, which is the driver of our approach. Asset identiication is done by conducting an analysis to ind the artefacts of the system that are likely to be subject to an attack. When the assets are identiied, they can be further decomposed during the diferent phases of the development life-cycle. For example in an OEM, a high-level asset analysis is done at the concept phase, and later a low-level analysis is conducted during implementation, where more information about the assets and their usage is known. Linking assets to higher-level claims. To link the assets to the main claim, we identify which assets exist and which components use or have access to these assets. For example, in a vehicle, the driver’s information can be considered an asset that is accessible by the infotainment system of the vehicle. Hence, we link this asset to the claims of the security of the infotainment system. To make this more concrete, we look at the traceability of the asset. For example, we consider the assets (i)łat restž, which refers to where the assets are stored; (ii)on ł the move,ž when the asset is in transition between two entities, e.g., when sensor data is being transferred from the sensor to an ECU; and (iii) łin use,ž which is when the asset is being used, e.g., when some diagnostics data is being processed by a back-end system. Decomposition of assets.To decompose assets, we look into the types of the identiied assets. This gives an indicator of whether the asset would have implications on the local part of the vehicle (one electronic control unit/ECU), or on a bigger part of the vehicle (multiple ECUs). We also look into the relations among assets, e.g., dependability. ACM Transactions on Cyber-Physical Systems CASCADE: An Asset-driven Approach to Build Security Assurance Cases for Automotive Systems • 9 Linking assets to the lower level.To link the asset to the lower level in the approach, i.e., the security goals, we identify the relevant security properties for the assets. Speciically, we look into the Conidentiality, Integrity, and Availability (CIA) triad. For example, the vehicle engine’s start functionality is an asset that has relevant integrity and availability properties. Identiication of security goals. When we have identiied the relevant security properties for each asset, we create claims representing the security goals . Following our example of the engine start request, a claim about the achievement of a security goal would be that the availability of the request is preserved. One combination of asset/security property might lead to several goals, for example that the engine start is available using a connected mobile app and a web portal. To make sure the relevant properties are covered when identifying security goals, we consider damage scenarios that lead to compromising the security goals, e.g., that the engine start request is unavailable, or an unintended start of the engine occurs, which would damage the integrity of the asset. 4.2.4 Black-hat block. In this block, we aim to identify the scenarios that might lead to not fulilling the identiied security goals and hence cause harm to our identiied assets. Identiication of threat scenarios. When we have identiied the claims about the achievement of security goals, we proceed by identifying the threat scenarios and creating claims for negating the possibility of these scenarios. We connect these claims to the corresponding claims about achieving security goals. For example, a claim handling a threat scenario connected to the claim łUnintended request for engine start is not possible,ž might be identiied by considering a threat model, e.g., STRIDE 16].[ Hence a claim might look like: łSpooing a request for engine start is not possible.ž Identiication of possible attack paths. In this step, we identify possible attack paths which can lead to the realization of a threat scenario. Each threat scenario might be associated with multiple attack paths. We then claim the opposite of these attack paths. An example of an attack path is An ł attacker compromises the cellular interface and sends a request to start the engine,ž and the claim would be to negate the possibility for that. 4.2.5 Resolver block. This block is the last one in the argumentation part of the CASCADE approach. It links the claims derived from the attack paths to the evidence. Risk assessment.In this level, we assess the risk of the identiied attack paths. Based on the risk level, the creators of the SAC create claims to treat the risk by, e.g., accepting, mitigating, or transferring it. Requirements.At this point, requirements of risk treatments identiied in the previous level are to be expressed as claims. This level may contain multiple decompositions of claims, based on the level of detail the creators of the SAC wish to achieve, which is driven by the potential usage of the SAC. For instance, if the SAC is to be used by a development team to assess the security level, this might require a ine-grained requirement decomposition which might go all the way to the code level. In contrast, if the SAC is to be used to communicate security issues with outside parties, a higher level of granularity might be chosen. In either case, it is important to reach an łactionablež level, meaning that the claims should reach a point where evidence can be assigned to justify them. 4.2.6 Evidence. The evidence is a crucial part of an SAC. The quality of the argument does not matter if it cannot be justiied by evidence. In our approach, evidence can be provided at any block of the argumentation. For example, if it can be proven in the black-hat block that a certain asset is not subject to any threat scenario, then evidence can be provided, and the corresponding claims can be considered justiied. If the creators of the SAC cannot assign evidence to claims, this is an indicator that either the argument did not reach an actionable point A security goal is preserving a security concern (CIA) for an asset [13] ACM Transactions on Cyber-Physical Systems 10 • Mazem Mohamad et al. or that there is a need to go back and make development changes to satisfy the claims. For example, if we reach a claim which is not covered by any test report, then there might be a need to create test cases to cover that claim. 4.2.7 Case uality AssuranceW . e consider two main aspects of quality assurance for SAC in CASCADE. The irst aspect is completeness which refers to the level of coverage of the claims in each argumentation level of the SAC. Each level in CASCADE includes at least one strategy. For each strategy, we add at least one completeness claim that reines it. The role of this claim is to make sure that the strategy covers all and only the relevant claims on the argumentation level. These completeness claims in CASCADE are used to gain conidence in the provided arguments. We have identiied the strategy elements in the arguments to be attention points where these claims need to be made. The content of the completeness claims depends on the way of working in a company, i.e., the documented activities and procedures that are expected to be formed. This dependency should be documented in a context node which sets the scope for the completeness claim. For example, if a company uses pre-deined catalogues of known attack patterns, e.g., the Common Attack Pattern Enumeration and Classiication (CAPEC) catalogue 2], then [ the context node should refer to the catalogue, and the claim would hence take the form: "All attack paths have been considered in accordance to document X", where the document refers to the catalogue. Another example is when a company deines a Deinition of Done (DoD) for their activities, then the context nodes should refer to the corresponding DoD. Additionally, working with cybersecurity always involves uncertainties. This is due to multiple factors, e.g., the limited knowledge of the capabilities of an attacker or unforeseen vulnerabilities. This again emphasizes the importance to set a scope for the completeness arguments. In addition to the context nodes, assumption nodes also need to be speciied. These together provide the information needed to determine if the completeness claim is fulilled or not within the scope of knowledge the company has given the assumptions made by the adopting organization. It is also important to phrase the claims in a way that relects its scope and limitations. The second aspect isevidence-conidencewhich indicates the level of certainty that a claim is fulilled based on the provided evidence. This is used in each level of a security assurance case where at least one claim is justiied by evidence. The evidence-conidence aspect is expressed as a claim, which takes the form: łThe evidence provided for claim X achieves an acceptable level of conidence.ž What makes an acceptable level of conidence is deined in the context of the strategy. The conidence claim itself must be justiied by evidence. 5 EXAMPLE CASE To validate our approach, we apply CASCADE on the headlamp item use case from ISO/SAE-21434 which includes the headlamp system, navigation ECU, and gateway ECU. Figures 3,4,5 present the resulted part of the SAC that correspond to each block of CASCADE. The ile shapes in the top-right corners of each level in Figures 3,4,5 indicate the requirement in ISO/SAE-21434 which mainly drives the argument in the corresponding level. The strategies used to form the argument of the headlamp example case are created to demonstrate the structure of a security assurance case built with CASCADE. We believe that it would be beneicial to have an initial set of strategies for each block as a starting point. However, we this requires an industrial application of CASCADE resulting multiple SACs, from which patterns can be extracted, and hence a set of strategies. This is a future work that we intend to do. 5.1 Top Claim We start by constructing the Top Claim block consisting of: • C:1 the top security claim for the headlamp item, which is that the headlamp item is adequately secure. • Cnxt:1.1 a context node setting the scope of the claim. This scope is set by the headlamp item boundary description, which is available in the example case in ISO/SAE-21434 ACM Transactions on Cyber-Physical Systems CASCADE: An Asset-driven Approach to Build Security Assurance Cases for Automotive Systems • 11 White-hat CQ:1.1.1 Asset identification and decomposition S:1.1 All relevant asset are Argue over RQ-06-02 identified identified assets of the headlamp item C:1.1.2 C:1.1.1 CAN Frame is acceptably Firmware is acceptably secure secure CQ:1.2.1.1 S:1.2.1 S:1.2.2 CQ:1.2.2.1 All relevant decompositions All relevant decompositions Argue over the decomposition of the Argue over the decomposition of the of the CAN frame are of the firmware are CAN frame asset Firmware asset considered considered Text C:1.2.1.1 C:1.2.1.2 C:1.2.2.1 C:1.2.2.2 C:1.2.2.3 C:1.2.2.4 The CAN message The oncoming car The CAN message The lamp low ON/HI The power switch control is The headlamp control is transmission is acceptably information Yes/No CAN transmission is acceptably ON/OFF request CAN acceptably secure acceptably secure secure in the body control message is acceptably secure in the power switch message is acceptably ECU secure actuator secure Security goals CQ:1.3.2.1 S:1.3.2 S:1.3.3 RQ-09-05 All relevant security properties of the Argue over the security properties of the Argue over the security properties of the CAN message transmission in the CAN message transmission in the CAN message transmission in the body control ECU are considered body control ECU power switch actuator S:1.4.2 C:1.3.2.1 C:1.3.2.2 C:1.3.3.1 Argue over identified damage scenarios that might results The Integrity of the The Availability of the The Integrity of the from the loss of integrity of the CAN CAN message transmission in the CAN message transmission in the CAN message transmission in the message transmission body control ECU is preserved body control ECU is preserved power switch actuator is preserved in the body control ECU CQ:1.4.2.1 CQ:1.4.2.2 Unintended turning off of Unintended turning off of headlamps headlamps during IGN switch's during night driving is not possible turn-off is not possible Fig. 3. White-hat block of the headlamp use case - The file shaped box in the top-right corner of each level indicates the requirement in ISO/SAE-21434 which drives the argument in that level • Assmp:1.1 an assumption node, stating that the item is physically protected. Hence, we only consider the security of the software part of the headlamp item in our argument. The context node refers to an external document, which is the item boundary and preliminary architecture of the headlamp item, as identiied in ISO/SAE-21434. 5.2 White-hat Block The White-hat block is presented in Figure 3. We irst apply a strategy S:1.1 to decompose our main claim based on the identiied assets of the headlamp item. In our example, the main assetsCAN are the Frame, which holds transmitted messages, and theFirmware which includes control functions of the artifacts inside the headlamp system, e.g., the power switch. We create two claims C:1.1.1 and C:1.1.2 indicating that the two assets are acceptably secure. The strategy S:1.1 is associated with a case quality-claim CQ:1.1.1, to ensure the completeness of the decomposition associated with it, and hence the completeness of the case in general. The two identiied assets are further decomposed into sub-assets. This decomposition is based on the com- ponents and functions the asset belongs to. For example, based on claim C:1.1.2 we apply strategyS:1.2.2 and decompose the CAN Frame asset into a number of sub-assets. Moreover, we create security claims for the identiied ACM Transactions on Cyber-Physical Systems 12 • Mazem Mohamad et al. sub-assets: C:1.2.2.1, C:1.2.2.2, C:1.2.2.3, and C:1.2.2.4. Lastly, strategyS:1.2.2 is associated with case quality-claim CQ:1.2.2.1. At this point, we link the assets to the security goals (i.e., second level). To do so, we apply an argumentation strategy (e.g., S:1.3.2) to decompose the security claims of the sub-assets based on the CIA triad attributes. As a result, we create claims about the achievement of security goals such C:1.3.2.1 as : ł The integrity of CAN message transmission in the body control ECU is preserv.ž eTdo make sure that we cover the relevant properties, we create a case quality-claim CQ:1.3.2.1 and argue (S:1.4.2) about possible damage scenarios that could invalidate the claims. Accordingly, we create case quality-claims which make sure that these damage scenarios do not happen. An example of these claimsCQ:1.4.2.1 is : ł Unintended turning of of headlamps during night driving is not possible .ž At this point, the claim is ine-grained enough and counts as a security goal. Next, we create the black-hat block. 5.3 Black-hat Block Here we argue over the threat scenarios that could lead to compromising a security goal. Figure 4 shows a part of the black-hat block of the headlamp use case. This part is associated with the claim about achieving a security goal C:1.4.2.1 that is shown in Figure 3. We start by creating strategy S:1.5.1 to argue over the used threat model. If e.g., STRIDE is used as a threat model, then the strategy would be to create a claim for each STRIDE category. In our example case, we create claim C:1.5.1.1: ł Spooing of a signal leading to loss of integrity of the CAN message of Lamp Request signal of power switch actuator ECU is not possible .ž To ensure the completeness of the case, we further associate the strategy S:1.5.1 with a case quality-claim CQ:1.5.1.1 ( ). At this point, our claims become more concrete as we have a speciic item, asset, container component, security property, damage scenario, and threat scenario. We use the analysis of attack paths to further decompose and populate the example case. We apply strategy S:1.6.1 to argue over the attacks and create attack path claims. The resulting claims negate the possibility for an attack path to take place C:1.6.1.4 , e.g.,ł It is not possible for an attacker to compromise the Navigation ECU from a cellular interface .ž As for all strategies in CASCADE, we associate the strategy used in the attack path with a case quality-claim CQ:1.6.1.1 ( ) to ensure the completeness of the case. To set a scope for the case quality-claims, we add the context noCN desTX:1.5.1 ( ) and (CNTX:1.6.1). These nodes refer to pre-deined catalogues of known threat scenarios and attack paths, and are used to make sure that they have been considered, and hence, gain conidence in the completeness of the SAC. 5.4 Resolver and Evidence Blocks In this stage, we create the resolver block by investigating ways to resolve the attack paths based on a risk assessment and creating requirements for the intended risk treatments. Figure 5 shows a part of the resolver block for our example case associated with the attack C:1.6.1.4 path . The outcome of the risk assessment would be to accept, mitigate, transfer, or solve the risk. When a risk is accepted, then there is no need to further decompose the claim. In the other cases, a strategy S:1.7.1 ( ) to decompose the risk of an attack path has to be created. In our example, we create claim C:1.7.1.1 to mitigate the risk as follo The ws: ł risk of an attacker compromising the Navigation ECU from a cellular interface is r.žeduced This leads to the stage where we argue on the requirements in order to specify how the risk has to be reduced or mitigated. An example of a requirement claim C:1.8.1.1 is: ł The received data is veriied if it is sent from a valid entityž. Figure 5 also shows the evidence block which provides examples of evidence to justify the requirement’s claims. The evidence (e.g.,E:1.1) is supported by case quality-evidence (CQE:1.1 e.g., ) which, in turn, is complemented with case quality-claims CQ:1.8.1.1 (e.g., ) to conidently justify the associated requirement claims. ACM Transactions on Cyber-Physical Systems CASCADE: An Asset-driven Approach to Build Security Assurance Cases for Automotive Systems • 13 Fig. 4. Black-hat block of the headlamp use case - The file shaped box in the top-right corner of each level indicates the requirement in ISO/SAE-21434 which drives the argument in that level 5.5 Generic Sub-case Block Figure 6 shows the last block in our example; the generic sub-case. This block includes claims that are relevant to the example case but are not speciic to it. For example, claim C:G2 states that ł The company has a security-aware culture,ž which is supported by two evidence statements; E:G2.1 and E:G2.2 to prove that the employees of the company were given a security training. The evidence provided to support C:G2 claim in this example are used to demonstrate the type of evidence that can be used in the generic sub-case block. In a real-world scenario, these evidence might not suice and additional contexts, assumptions, and evidence might need to be provided in order to justify the security culture of the company, e.g., in terms of trade-ofs that have to be made between spending resources for security or other activities. When all the evidence are provided, it’s important to assess the conidence they provide, and create a conidence CQ-claim and support it with relevant evidence. Similar to other blocks, the generic sub-case block might include strategies S:G1 (e.g., ) to break down claims. Moreover, these strategies are associated with case quality-claims QC:G.1.1 (e.g., ) as shown in Figure 6. 6 MAPPING TO ISO/SAE-21434 This section provides a set of guidelines that are extracted during the mapping exercise from the requirements and work products of ISO/SAE-21434 to elements of security assurance cases according to the GSN notation. The mapping exercise is based on the FDIS (Final Draft International Standard) version of ISO/SAE-21434. Figure 7 shows a mapping worklow that can be used to map each ISO/SAE-21434 item to a CASCADE element. Given an ISO/SAE-21434 item, it is irst classiied into Reeither quirement a or Work Product: • Requirement: As a general rule of thumb, requirements form the argument part of the SAC. A requirement is irst checked whether or not it includes an implication. If an implication (A implies B) is included, then it means that there are two possible outcomes: łnot A or Bž. Here the corresponding SAC element is either an assumption of the negation of A, or a requirement B. For example let us consider the following requirement: ACM Transactions on Cyber-Physical Systems 14 • Mazem Mohamad et al. Resolver S:1.7.1 Risk assessment CQ:1.7.1.1 Argue over the treatment based on RQ-08-11 The top down concept design the assigned risk level has to be verified by a bottom up analysis of the risks C:1.7..1.1 The risk of an attacker compromises Navigation ECU from a cellular interface is reduced S:1.8.1 Requirements RQ-12-01 Argue over cybersecurity requirements to handle risk treatment C:1.8.1.1 C:1.8.1.2 CQ:1.8.1.1 Unauthenticated entities are Evidence E:1.1 , E:1.2 The received data is verified if it is acceptably justify associated prevented from accessing the sent from a valid entity claims cellular network Evidence E:1.1 E:1.2 CQE:1.1 Verification Verification Test coverage report report xx report xy Fig. 5. Resolver and evidence blocks of the headlamp use case - The file shaped box in the top-right corner of each level indicates the requirement in ISO/SAE-21434 which drives the argument in that level łIf the cybersecurity activity X is applied, then a rationale R shall be providedž. If the cybersecurity activity X is not applied, then this requirement is mapped Assumption to an . If otherwise X is in fact applied (i.e., that a rationale R is provided), then the requirement is checked whether it is a process- or product-oriented. If the requirement is process-oriented (e.g., refers to the overall cybersecurity management or culture in the organization), then it is considereClaim d as a within the Generic sub-case . Otherwise, the requirement is considered as product-oriented. At this point, the product-oriented requirement is checked whether it targets the quality of the item in question. If the requirement is targeting the quality, then it is mapp Case ed Quality-Claim to a (CQ Claim) . Otherwise, it is mapped toClaim a . For instance An ł assessment shall judge whether the available evidence provides conidence in the cybersecurity of the itemž would be mapped into a conidence claim. In contrast, a requirement such as łThe validation of the item shall conirm that all the risks identiied during the phase X are handledž would be a case quality-claim for completeness. ACM Transactions on Cyber-Physical Systems CASCADE: An Asset-driven Approach to Build Security Assurance Cases for Automotive Systems • 15 Generic sub-case C:G1 C:G2 The company has a The company has a RQ-05-01 working security security aware culture policy CQ:G1.1 S:G1 All elements to enforce enable and ensure the Argue by security governance elements cybersecurity policy are addressed C:G1.1 C:G1.2 security security resources CQE:G1.1 responsibilities are are provided assigned All the elements mentioned in ISO E:G2.2 21434 have been E:G2.1 addressed E:G1.1 Basic security Mandatory security training ID: xy is a course ID:xx was part of new HR report no. 123 given to every employment relevant position procedure Fig. 6. Generic sub-case block of the headlamp use case - The file shaped box in the top-right corner indicates the requirement in ISO/SAE-21434 which drives the argument • Work Product: Work products form the evidence part of the resulting SAC. The work product can be either a (i) document which sets a scope to the cybersecurity work, which in this case is consider Conteextd as or (ii) document which includes sources for, e.g., cybersecurity monitoring, which in this case is considered as an Evidence. The mapping of the ISO/SAE-21434 requirements into diferent blocks of CASCADE is rather a straightforward task. The used rules are the following: • requirements about security goals and asset identiication fall into the white-hat block, • requirements about risk assessment, e.g., identiication and analysis of attack paths, attack feasibility, or impact rating, would fall into the black-hat block. Similarly, requirements about vulnerability analysis also fall into the black-hat block, and • requirements about risk treatment fall into the resolver block. Table 1 shows the requirements and work products in ISO/SAE-21434 which drive the arguments in each of CASCADE block and level. More detailed results of the conducted mapping between CASCADE and ISO/SAE-21434 items are reported in Appendix A. The irst two columns in the table of the Appendix A refer to item ID and type from the ISO/SAE- 21434 standard. The third column shows the corresponding SAC element, which is then speciied for CASCADE in column 4. Columns 5 and 6 include the corresponding block and level for the item in CASCADE’s structure. Finally, the last column shows the work products which support the elements that emerge from the corresponding requirement items, as per the speciication of ISO/SAE-21434. 7 VALIDATION In order to evaluate our approach, we reached out to a security expert from the cybersecurity team at Volvo Trucks, which is a leading OEM that manufactures trucks in Sweden. We conducted several sessions during the development of CASCADE where we discussed the approach, its limitations, and possible enhancements. When ACM Transactions on Cyber-Physical Systems 16 • Mazem Mohamad et al. Item of Start Context ISO/SAE 21434 Work product Sets a scope Yes Type of item for the item? No Evidence Requirement Includes an No implication? End Specific to a Claim within the No product? generic sub-case Yes True Yes Implication Contributes to CQ Claim Yes Value quality? False Claim No Assumption Fig. 7. The workflow of mapping ISO/SAE-21434 items to elements of CASCADE (in grey) the approach was fully developed, we conducted a inal evaluation session with the expert. We irst discussed the way of working of the company when it comes to security activities and security assurance. We used the headlamp example from ISO/SAE-21434 as a context for this discussion. We then presented our approach and the example case for the headlamp item. The expert evaluated the approach by discussing how the overall structure of an SAC should look from the company’s perspective in order to satisfy the requirement for security cases in ISO/SAE-21434 and mapping the diferent elements of the example case to the internal way of working. The expert also provided insights on how to further enhance the approach. Figure 8 shows the diferent security activities at the company along with the corresponding CASCADE block. A link between an activity and a block indicates that the outcomes of the activity are used to create the SAC elements in the corresponding block. Software products at Volvo Trucks contain both on-board and of-board parts. The of-board parts establish the communication between the vehicles and the back-end systems. For example, the diagnostics services receive data from the vehicle’s ECUs and store and use it in a back-end system. The on-board parts are software components installed in the ECUs of the vehicle, e.g., the engine control and the head-up display unit. These parts are divided into items to facilitate the security-related analysis. The items of the of-board systems can be seen as individual services which communicate with the vehicles, whereas the on-board items are end-user functionalities, e.g., external lighting and automated parking assistance. In order to argue about the security of a complete product, ACM Transactions on Cyber-Physical Systems CASCADE: An Asset-driven Approach to Build Security Assurance Cases for Automotive Systems • 17 Table 1. Requirements and work products from ISO/SAE 21434 which are relevant to the arguments in each CASCADE block Colons indicate ranges of requirements and work products CASCADE Block CASCADE Level Requirements and Work products Top Claim RQ-11-01, RQ-15-05, RQ-15-06 Generic sub-case RQ-05-01:RQ-05-15, RQ-06-01, RQ-06-04, RQ-06-23, RQ-06-24, RQ-07-01, RQ-08-01, RQ-08-04:RQ-08-07, RQ-09-01:RQ-09-04, RQ-10-19:RQ-10-21, RQ-13-06, RQ-15-01:RQ-15-03, WP-05-01:WP-05-05, WP-07-01, WP-10-07, WP-10-08, WP-13-03, WP-15-01 White hat Asset ID RQ-06-02, RQ-07-03, RQ-08-02 Security Goals RQ-06-03:RQ-06-17, RQ-06-19, RQ-06-20, RQ-06-22, RQ-06-25:RQ-06-27, RQ-07-02, RQ-07-04, RQ-09-05, RQ-09-07, RQ-09-09, RQ-11-01, RQ-11-02, RQ-14-01 Black hat Threat Scenarios RQ-08-03, RQ-08-08, RQ-11-03, RQ-13-03, WP-13-02 Attack Paths RQ-08-09, RQ-08-10 Resolver Risk Assessment RQ-07-05:RQ-07-07, RQ-08-11, RQ-08-12, RQ-09-06, RQ-09-08, RQ-10-09:RQ-10-11, RQ-10-13, RQ-10-16:RQ-10-18, RQ-11-04, Security Requirements RQ-06-29, RQ-07-08, RQ-09-10:RQ-09-12, RQ-10-01:RQ-10-08, RQ-10-12, RQ-10-14, RQ-10-15, RQ-12-01, RQ-13-01:RQ-13-05, RQ-15-04, RQ-15-07 Product Primary assets' TARA analysis Definition identification Security activities Security Testing and at Volvo Trucks Requirements verification Attack paths Item definition Security goals identification Align with CASCADE blocks Top Claim White-hat Black-hat Resolver Evidence Fig. 8. Mapping of the company’s security activities to CASCADE blocks both of-board and on-board items have to be considered. Hence, if the company wants to adopt CASCADE to create an SAC for a complete product, then the top claim block would contain claims for the individual items of that product. The Generic sub-case block of CASCADE helps to remove the redundancy of arguments and evidence applicable to diferent items. The assets of a product are identiied by considering damage scenarios on the items. In general, these assets can be generalized into the following categories: • Vehicle’s functionality (the attackers want to use the vehicle or tamper with the vehicle’s functionality for their own purpose or impede the rightful user from utilizing the vehicle functionality); • Information (the attackers want to gain access to sensitive information); and • Brand (the attackers want to discredit the brand and/or credit themselves). ACM Transactions on Cyber-Physical Systems 18 • Mazem Mohamad et al. The identiied assets are further categorized into primary and secondary assets in accordance with the deinitions in ISO-27005 18].[Considering the headlamp example case, two possible damage scenarios would be łLosing the headlamp will drastically reduce the driver’s sight and the vehicle’s visibility, which may result in a severe accidentž and Applying ł the headlamp at incorrect times could dazzle other vehicles, which may increase the risk of an accidentž. These lead to considering the headlamp functionality as a primary asset. Then, relevant security attributes for the primary asset are identiied and security goals are derived: • The integrity of the headlamp control functionality shall be preserved. • The availability of the headlamp control functionality shall be preserved. The identiication of assets and security goals corresponds to the white-hat block of CASCADE, as shown in Figure 8. These goals only take relevant security properties into consideration, i.e., integrity and availability. Hence, other properties such as conidentiality and authenticity are not considered. During the concept design phase, a Threat Assessment and Remediation Analysis (TARA) is performed on the item’s primary assets using STRIDE, which will result in cybersecurity requirements on certain components which are considered as supporting assets. These requirements are converted to claims in the black-hat block of CASCADE, as shown in Figure 8. After that, attack path analyses are performed bottom-up using an attack library, including but not limited to: • Intended over-the-air connection (e.g., 2,5G, 3G, 4G or 5G, Wi-Fi, WPAN, Bluetooth, IrDA, Wireless USB, and UBW); • Intended physical connection points (e.g., OBD, USB, and CD-Rom); • Unintended over-the-air disturbances (e.g., Radar, Laser, electro-magnetic, microwaves, infra-waves, ultra- sound, and infra-sound); • Unintended physical connection points (e.g., ECU, network, sensors, and actuators). These attack paths are also expressed as claims in the Black-hat block. Then the component design will be started considering all requirements, including cybersecurity. The components and systems are described in łproduct descriptionsž. These are veriied against the requirements, including cybersecurity. The cybersecurity requirements in the product description correspond to the requirements of the Resolver block in CASCADE. The components and systems are then tested against the product descriptions, and the test results are considered as evidence in CASCADE. Other SAC requirements also emerged from the discussion with the security expert. For instance, they emphasised the need to validate that production, operation, service and decommissioning are all adequately handled. We believe that this would be covered by QA claims in the resolver block. Another requirement is that the product along with the SAC is maintained throughout the life-cycle. This is not covered by CASCADE, and we consider it to be an important complementary aspect for future work. In particular, we will be looking into methods to ensure traceability between the elements of SACs and the corresponding development artefacts. This traceability allows impact analysis for maintaining SACs. Lastly, the expert stressed that it is important to argue that the performed product work is adequate with respect to cybersecurity policies and practices adopted by the company. We believe that to cover this, both product related arguments should be in place, as well as claims about the adequacy of the applied security policy, which is covered by the generic sub-case block of CASCADE. To get a deeper insight of how applicable CASCADE would be in an industrial context and what the strengths and weaknesses of it are, we extended our evaluation and included another large OEM in Sweden, Volvo cars. We did an open discussion session with a security expert at the company where we presented CASCADE and the example case. Here, we present the main discussion points and the expert’s input: • The work of work products is done in an iterative manner at Volvo Cars. In the design phase, for instance, there sometimes could be uncertainties, which would be cleared in the next phases, hence there is a need to go back and rework on work packages. This might also be the case within a phase in diferent development iterations. The interviewee stated that CASCADE allows the creationon ofthe SArun C , referring to the ACM Transactions on Cyber-Physical Systems CASCADE: An Asset-driven Approach to Build Security Assurance Cases for Automotive Systems • 19 structure of CASCADE being aligned with the security activities and the iterative way of working applied in the company. Hence, CASCADE does not require complete artifacts and work products to be in place to start building the case, but can rather be built and compiled progressively during the product development phases, e.g., concept, design, and implementation. During these phases the SAC provides an overview of the security of the ongoing work, which supports: – Early identiication of potential issues and decrease the cost of ixing these issues – Simplifying the change impact analysis to make decisions regarding the integration of new development in terms of: (i)what needs to be addressed in regards to updated artefacts/work products, e.g., TARA, concept, V&V needs; (ii)what needs to be updated in the assurance case;(iii) the needed reviews and re-assessments needed to account for the change. – Gaining a faster understanding of the security impact and posture of a change to support decisions on deployment • Quality of security artefacts, is done at the company as reviews. There are reviews to make sure that the analysis is complete and the scope is covered (boundaries). The expert agrees that the case should relect that, which is done through the case quality assurance part of CASCADE. SACs have the potential to be used in multiple usage scenarios 24]. Hence [ , there are many stakeholders to SACs. These stakeholders require diferent abstraction levels of the SAC. For some stakeholders the detailed case quality arguments and evidence might not be required, but rather an abstracted view where the quality of the case is indicated and visualised using a metric. The complete case quality arguments must, however, be in place to measure the completeness of the SAC’s argument. Distinguishing the case quality-claims in CASCADE is good as it enables the possibility for the abstraction. However, there should be a property on the case level that directly indicates the quality of the case rather than having to go through all the corresponding elements. This has been implemented in some of the tools used for creating and managing assurance cases, 25], e.g., [ and is considered a state of practice. • There is no clear distinction between what is speciic to CASCADE, and what is an one to one mapping to the structure of ISO/SAE-21434. Moreover, it is unclear whether the approach would suiciently cover the requirements of the standard. A more in-depth analysis between the standard and CASCADE is needed according to the expert. Areas of Improvement The mapping of ISO/SAE-21434 has enabled us to pinpoint areas of improvement as well as strong points in CASCADE. In this section, we discuss our main indings of the evaluation cycle. • Re-usability: the separation of item-related and generic arguments in CASCADE enabled us to consider the re-usability of the claims already while creating them, i.e., in an early stage. The standard does not explicitly distinguish b(i) etwpreoen duct-related requirements and work products; and (ii)process-related requirements and work products. However, by deriving claims from the requirement and determining the CASCADE corresponding block, this could easily be achieved. Re-using claims is very important to reduce the overhead of creating SAC for diferent products. Re-use of process-related claims is, however, not the only type of re-usability possible in creating SAC. The other type is the re-use of product-related claims that are applicable to multiple items. For example, if there are multiple items in a vehicle that are connected to the outside world through a gateway, then a security argument about that gateway would be applicable to all the connected items and should be re-used in each of their corresponding security arguments. This type of re-usability is only possible to achieve when the architecture of the system is known and the relations and dependencies of diferent items are known. ACM Transactions on Cyber-Physical Systems 20 • Mazem Mohamad et al. To improve CASCADE, we should restructure the generic sub-case block in order to be able to cover both types of re-usability. Additionally, we need to establish the techniques and mechanisms needed to shift parts of arguments between diferent SAC. • Uncertainty: Throughout the mapping activity, we encountered several occasions where there were uncer- tainties. This is the case when a requirement includes a condition in it, e.g., in a form of an if statement. As discussed in Section 6, we consider this type of requirement to either lead to an assumption or to a claim (we have mapped them to assumptions in Appendix A). This leads us to the need for capturing these uncertainties in an SAC at an early stage of its creation. As SAC should follow the development life-cycle, it is important to make sure to tag the parts of a given SAC which need further development. Uncertainties certainly lead to incomplete arguments in the early stages of SAC creation. To resolve this issue, we could introduce a mechanism to tag a scope of a given argument as incomplete, as well as providing alternative solutions based on a certain condition. In our case, that would be the condition in the requirement. This would be similar to how behavioral views (sequence diagrams in particular) in UML handles alternatives. This change would afect the process of creating a SAC. However, the end result would be the same once the development of the item in question is inalized and the SAC is fully created. It might, however, also be interesting to keep a history log of the choices that have been made in the process. This log can be relected in the case to show arguments that were subject to decision points during the development process. • Adequacy: the items in the standard are not enough to cover the case quality claims and evidence. In CASCADE we have a rule that every level of argumentation (when a claim is broken down into sub-claims) must be examined for completeness, and every piece of evidence must be examined for conidence. However, the items of the standard do not suice to cover these quality needs. Additionally, the creation of a SAC requires introducing contexts and assumptions which are not necessarily captured by the standard. Moreover, the items of the standard might not even be enough to claim the required level of security according to an organization’s standard. Hence, conforming with the standard and relecting the work in a SAC does not mean that the SAC is complete. There is a need for a deinition of done for the SAC work, which would have to be considered as a context for the top claim. As a summary of the validation of this work, we showed that CASCADE is well aligned with the internal way of working at automotive OEM’s which makes it suitable for the creation of SAC on the run and during the development life-cycle. We also found that the generic sub-case and quality blocks help to serve the abstraction and completeness requirements of the evaluating companies. We have identiied points of improvement in the approach, especially when we attempted to map the requirements and work products of ISO/SAE-21434 to elements and structure of CASCADE. These include the need for a concrete mechanism for reusing arguments, handling the uncertainty in the requirements, and the need to have a deinition of done for the outcome. These will be the basis for future work. 8 CONCLUSION AND FUTURE WORK In this work, we presented CASCADE, an asset-driven approach for the creation of security assurance cases with built-in quality assurance. CASCADE is geared towards automotive companies that have the need to conform with the upcoming ISO/SAE-21434 security standard. We illustrated CASCADE using an example case from ISO/SAE-21434 and validated it at two industrial OEMs. We also mapped the requirements and work products of the standard to elements of the approach and evaluated ACM Transactions on Cyber-Physical Systems CASCADE: An Asset-driven Approach to Build Security Assurance Cases for Automotive Systems • 21 its capability to include these items. Additionally, we synthesized the knowledge gained during the mapping activity and created a guideline for practitioners who want to conduct a similar activity. As a future work, we plan to further enhance the approach to take into consideration the maintenance of SAC. We will also work on deining the mechanisms and techniques required for the re-usability and the quality assurance of the outcome of CASCADE. Additionally, we plan on incorporating additional requirements sources to better cover the needs of the automotive industry. ACKNOWLEDGEMENT This work is partially supported by the CASUS research project funded by VINNOVA, a Swedish funding agency. We sincerely thank four anonymous reviewers whose comments and suggestions helped improve and clarify this manuscript. REFERENCES [1] [n. d.]. Claims, Arguments and Evidence (CAE). https://www.adelard.com/asce/choosing-asce/cae.html [2] [n. d.]. Common Attack Pattern Enumeration and Classiication (CAPEC). http://capec.mitre.org/. Accessed: 2022-02-07. [3] [n. d.]. The Common Component Modeling Example - CoCoME. https://www.cocome.org/downloads/documentation/cocome.pdf. Accessed: 2020-04-09. [4] A. Finnegan and F. McCafery. 2014. Towards an International Security Case Framework for Networked Medical Devices. International In Conference on Computer Safety, Reliability, and Security . Springer, 197ś209. [5] Rob Alexander, Richard Hawkins, and Tim Kelly. 2011. Security assurance cases: motivation and the state of High theIntegrity art. Systems Engineering Department of Computer Science University of York Deramore Lane York YO10 5GH (2011). [6] T Scott Ankrum and Alfred H Kromholz. 2005. Structured assurance cases: Three common standards. In Ninth IEEE International Symposium on High-Assurance Systems Engineering (HASE’05) . IEEE, 99ś108. [7] T. S. Ankrum and A. H. Kromholz. 2005. Structured assurance cases: three common standards. InNinth IEEE International Symposium on High-Assurance Systems Engineering (HASE’05) . 99ś108. https://doi.org/10.1109/HASE.2005.20 [8] John Birch, Roger Rivett, Ibrahim Habli, Ben Bradshaw, John Botham, Dave Higham, Helen Monkhouse, and Robert Palin. 2014. A Layered Model for Structuring Automotive Safety Arguments (Short Paper2014 ). In Tenth European Dependable Computing Conference . 178ś181. https://doi.org/10.1109/EDCC.2014.24 [9] Lukasz Cyra and Janusz Gorski. 2007. Supporting compliance with security standards by trust case templates. 2nd International In Conference on Dependability of Computer Systems (DepCoS-RELCOMEX’07) . IEEE, 91ś98. [10] Anita Finnegan and Fergal McCafery. 2014. A security argument pattern for medical device assurance cases. 2014 IEEE In International Symposium on Software Reliability Engineering Workshops . IEEE, 220ś225. [11] John Goodenough, Howard Lipson, and Chuck Weinstock. 2007. Arguing Security - Creating Security Assurance Cases. (2007). [12] GSN Community Standard Working Group. 2011. GSN community standar Available d. at www.goalstructuringnotation.info/ (2011). [13] C. Haley, R. Laney, J. Mofett, and B. Nuseibeh. 2008. Security Requirements Engineering: A Framework for Representation and Analysis. IEEE Transactions on Software Engineering 34, 1 (2008), 133ś153. https://doi.org/10.1109/TSE.2007.70754 [14] Richard Hawkins, Tim Kelly, John Knight, and Patrick Graydon. 2011. A new approach to creating clear safety arguments. AdvancesIn in systems safety . Springer, 3ś23. [15] Alan R. Hevner, Salvatore T. March, Jinsoo Park, and Sudha Ram. 2004. Design Science in Information Systems Resear MIS Qch. . 28, 1 (March 2004), 75ś105. [16] Michael Howard and Steve Lipner. 2006. The security development lifecycle . Vol. 8. Microsoft Press Redmond. [17] International Organization for Standardization. 1999. Information technology Ð Security techniques Ð Evaluation criteria for IT security Ð Part 1: Introduction and general model. [18] International Organization for Standardization. 2018. ISO 26262 Information technology Ð Security techniques Ð Information security risk management. [19] International Organization for Standardization. 2018. ISO 26262 Road vehicles ś Functional safety, 2nd Edition. [20] International Organization for Standardization and Society of Automotive Engineers. 2018. ISO / SAE 21434 Road vehicles ś Cybersecurity Engineering, CD Draft. [21] J. Knight. 2015. The Importance of Security Cases: Proof Is Good, But Not Enough. IEEE Security Privacy13, 4 (July 2015), 73ś75. https://doi.org/10.1109/MSP.2015.68 [22] Nikola Luburić, Goran Sladić, Branko Milosavljević, and Aleksandar Kaplar. 2018. Demonstrating Enterprise System Security Using an Asset-Centric Security Assurance Framework. 8th In International Conference on Information Society and Technology . 16. ACM Transactions on Cyber-Physical Systems 22 • Mazem Mohamad et al. [23] Mazen Mohamad, Örjan Askerdal, Rodi Jolak, Jan-Philipp Steghöfer, and Riccardo Scandariato. 2021. Asset-driven Security Assurance Cases with Built-in Quality Assurance ICSEW’21: . In Proceedings of the IEEE/ACM 43rd International Conference on Software Engineering Workshops June 2021. https://www.rodijolak.com/asset-driven/pre-print.pdf [24] Mazen Mohamad, Alexander Åström, Örjan Askerdal, Jörgen Borg, and Riccardo Scandariato. 2020. Security Assurance Cases for Road Vehicles: An Industry Perspective.Pr Inoceedings of the 15th International Conference on Availability, Reliability and Se(Virtual curity Event, Ireland)(ARES ’20). Association for Computing Machinery, New York, NY, USA, Article 29, 6 pages. https://doi.org/10.1145/ 3407023.3407033 [25] Gdansk University of Technology. 2010ś2019. NOR-STA. https://www.nor-sta.eu/en/. [26] Thomas Rosenstatter, Kim Strandberg, Rodi Jolak, Riccardo Scandariato, and Tomas Olovsson. 2020. REMIND: A Framework for the Resilient Design of Automotive Systems. 2020In IEEE Secure Development (SecDev). IEEE, 81ś95. [27] John Spriggs. 2012.GSN-The Goal Structuring Notation: A Structured Approach to Presenting Arguments . Springer Science & Business Media. [28] V. Vaishnavi and B. Kuechler. 2004. Design research in information A systems. ssociation for Information Systems (2004). [29] B. Xu, M. Lu, and D. Zhang. 2017. A Layered Argument Strategy for Software Security Case Development.2017 In IEEE International Symposium on Software Reliability Engineering Workshops (ISSREW) . 331ś338. https://doi.org/10.1109/ISSREW.2017.52 ACM Transactions on Cyber-Physical Systems CASCADE: An Asset-driven Approach to Build Security Assurance Cases for Automotive Systems • 23 Appendix A ISO/SAE-21434–CASCADE MAPPING Correspond- Correspond- Corresponding Corresponding Support- Item ID Item type ing SAC ing CASCADE CASCADE block CASCADE level ing WP element element RQ-05-01 Requirement Claim Claim Generic Sub-case WP-05-01 RQ-05-02 Requirement Claim Claim Generic Sub-case WP-05-01 RQ-05-03 Requirement Claim Claim Generic Sub-case WP-05-01 RQ-05-04 Requirement Claim Claim Generic Sub-case WP-05-01 RQ-05-05 Requirement Claim Claim Generic Sub-case WP-05-01 RQ-05-06 Requirement Claim Claim Generic Sub-case WP-05-01 RQ-05-07 Requirement Claim Claim Generic Sub-case WP-05-02 RQ-05-08 Requirement Claim Claim Generic Sub-case WP-05-02 RQ-05-09 Requirement Claim Claim Generic Sub-case WP-05-02 RQ-05-10 Requirement Claim Claim Generic Sub-case WP-05-01 RQ-05-11 Requirement Claim Claim Generic Sub-case WP-05-03 RQ-05-12 Requirement Claim Claim Generic Sub-case WP-05-01 RQ-05-13 Requirement Claim Claim Generic Sub-case WP-05-04 RQ-05-14 Requirement Claim Claim Generic Sub-case WP-05-04 RQ-05-15 Requirement Claim Claim Generic Sub-case WP-05-05 Work prod- WP-05-01 Evidence Evidence Generic Sub-case uct Work prod- WP-05-02 Evidence Evidence Generic Sub-case uct Work prod- WP-05-03 Evidence Evidence Generic Sub-case uct Work prod- WP-05-04 Evidence Evidence Generic Sub-case uct Work prod- WP-05-05 Evidence Evidence Generic Sub-case uct RQ-06-01 Requirement Claim CQ claim Generic Sub-case WP-06-01 RQ-06-02 Requirement Claim CQ claim White hat Asset ID WP-06-01 RQ-06-03 Requirement Claim CQ claim White hat Security goals WP-06-01 RQ-06-04 Requirement Claim CQ claim Generic Sub-case Security goals WP-06-01 RQ-06-05 Requirement Claim Claim White hat Security goals WP-06-01 RQ-06-06 Requirement Claim CQ claim White hat Security goals WP-06-01 RQ-06-07 Requirement Claim CQ claim White hat Security goals WP-06-01 RQ-06-08 Requirement Claim CQ claim White hat Security goals WP-06-01 RQ-06-09 Requirement Claim CQ claim White hat Security goals WP-06-01 RQ-06-10 Requirement Claim CQ claim White hat Security goals WP-06-01 RQ-06-11 Requirement Context Context White hat Security goals WP-06-01 ISO/SAE-21434śCASCADE Mapping ś Continued on next page ACM Transactions on Cyber-Physical Systems 24 • Mazem Mohamad et al. ISO/SAE-21434śCASCADE Mapping ś Continued from previous page Correspond- Correspond- Corresponding Corresponding Support- Item ID Item type ing SAC ing CASCADE CASCADE block CASCADE level ing WP element element RQ-06-12 Requirement Context Context White hat Security goals WP-06-01 RQ-06-13 Requirement Context Context White hat Security goals WP-06-01 RQ-06-14 Requirement Claim CQ claim White hat Security goals WP-06-01 RQ-06-15 Requirement Claim CQ claim White hat Security goals WP-06-01 RQ-06-16 Requirement Claim Claim White hat Security goals WP-06-01 RQ-06-17 Requirement Claim CQ claim White hat Security goals WP-06-01 RQ-06-18 Requirement WP-06-02 RQ-06-19 Requirement Claim CQ claim White hat Security goals WP-06-03 RQ-06-20 Requirement Claim CQ claim White hat Security goals WP-06-03 RQ-06-21 Requirement Claim CQ claim Evidence WP-06-03 RQ-06-22 Requirement Context Context White hat Security goals WP-06-03 RQ-06-23 Requirement Claim Claim Generic sub-case WP-06-03 RQ-06-24 Requirement Claim Claim Generic sub-case WP-06-03 RQ-06-25 Requirement Context Context White hat Security goals WP-06-03 RQ-06-26 Requirement Claim CQ claim White hat Security goals WP-06-03 RQ-06-27 Requirement Claim Claim White hat Security goals WP-06-03 RQ-06-28 Requirement Assumption Assumption Top claim WP-06-04 Security require- RQ-06-29 Requirement Claim CQ claim Resolver WP-06-04 ments Work Prod- WP-06-01 Evidence Evidence uct Work Prod- WP-06-02 uct Work Prod- WP-06-03 Evidence Evidence uct Work Prod- WP-06-04 Evidence Evidence uct WP-07-01 RQ-07-01 Requirement Claim Claim Generic sub-case WP-07-05 RQ-07-02 Requirement Claim CQ claim White hat Security goals WP-07-02 Work Prod- WP-07-01 Context Context Generic sub-case uct Work Prod- WP-07-02 Evidence Evidence uct RQ-07-03 Requirement Claim Claim White hat Asset ID ISO/SAE-21434śCASCADE Mapping ś Continued on next page RQ-06-18 is the requirement to create the cybersecurity case WP-06-02 is the work-product referring to the cybersecurity case ACM Transactions on Cyber-Physical Systems CASCADE: An Asset-driven Approach to Build Security Assurance Cases for Automotive Systems • 25 ISO/SAE-21434śCASCADE Mapping ś Continued from previous page Correspond- Correspond- Corresponding Corresponding Support- Item ID Item type ing SAC ing CASCADE CASCADE block CASCADE level ing WP element element Work Prod- WP-07-03 Evidence Evidence uct RQ-07-04 Requirement Claim Claim White hat Security goals Work Prod- WP-07-04 Evidence Evidence uct RQ-07-05 Requirement Claim CQ claim Resolver Risk assessment RQ-07-06 Requirement Claim CQ claim Resolver Risk assessment RQ-07-07 Requirement Claim Claim Resolver Risk assessment Security require- RQ-07-08 Requirement Assumption Assumption Resolver ments Work Prod- WP-07-05 Evidence Evidence uct RQ-08-01 Requirement Claim Claim Generic sub-case WP-08-01 RQ-08-02 Requirement Assumption Assupmtion White hat Asset ID WP-08-02 Work Prod- WP-08-01 Evidence Evidence uct Work Prod- WP-08-02 Evidence Evidence uct RQ-08-03 Requirement Claim Claim Black hat Threat scenarios WP-08-03 Work Prod- WP-08-03 Evidence Evidence uct RQ-08-04 Requirement Claim CQ claim Generic sub-case WP-08-04 RQ-08-05 Requirement Assumption Assumption Generic sub-case WP-08-04 RQ-08-06 Requirement Claim CQ claim Generic sub-case WP-08-04 RQ-08-07 Requirement Claim CQ claim Generic sub-case WP-08-04 Work Prod- WP-08-04 Evidence Evidence uct RQ-08-08 Requirement Claim Claim Black hat Threat scenarios WP-08-05 RQ-08-09 Requirement Claim Claim Black hat Attack paths Work Prod- WP-08-05 Evidence Evidence uct RQ-08-10 Requirement Claim CQ claim Black hat Attack paths WP-08-06 Work Prod- WP-08-06 Evidence Evidence uct RQ-08-11 Requirement Claim CQ claim Resolver Risk assessment WP-08-07 Work Prod- WP-08-07 Evidence Evidence uct RQ-08-12 Requirement Claim CQ claim Resolver Risk assessment WP-08-08 ISO/SAE-21434śCASCADE Mapping ś Continued on next page ACM Transactions on Cyber-Physical Systems 26 • Mazem Mohamad et al. ISO/SAE-21434śCASCADE Mapping ś Continued from previous page Correspond- Correspond- Corresponding Corresponding Support- Item ID Item type ing SAC ing CASCADE CASCADE block CASCADE level ing WP element element Work Prod- WP-08-08 Evidence Evidence uct RQ-09-01 Requirement Claim Claim Generic sub-case WP-09-01 RQ-09-02 Requirement Claim Claim Generic sub-case WP-09-01 RQ-09-03 Requirement Claim Claim Generic sub-case WP-09-01 RQ-09-04 Requirement Claim Claim Generic sub-case WP-09-01 Work Prod- WP-09-01 Evidence Evidence uct RQ-09-05 Requirement Claim CQ claim White hat Security goals WP-09-02 RQ-09-06 Requirement Claim CQ claim Resolver Risk assessment WP-09-03 RQ-09-07 Requirement Assumption Assumption White hat Security goals WP-09-04 RQ-09-08 Requirement Context Context Resolver Risk assessment WP-09-05 RQ-09-09 Requirement Claim CQ claim White hat Security goals WP-09-06 Work Prod- WP-09-02 Evidence Evidence uct Work Prod- WP-09-03 Evidence Evidence uct Work Prod- WP-09-04 Evidence Evidence uct Work Prod- WP-09-05 Evidence Evidence uct Work Prod- WP-09-06 Evidence Evidence uct Security require- RQ-09-10 Requirement Claim Claim Resolver WP-09-07 ments Security require- RQ-09-11 Requirement Context Context Resolver WP-09-07 ments Security require- RQ-09-12 Requirement Claim CQ claim Resolver WP-09-08 ments Work Prod- WP-09-07 Evidence Evidence uct Work Prod- WP-09-08 Evidence Evidence uct Security require- RQ-10-01 Requirement Claim CQ claim Resolver WP-10-01 ments Security require- RQ-10-02 Requirement Claim CQ claim Resolver WP-10-01 ments ISO/SAE-21434śCASCADE Mapping ś Continued on next page ACM Transactions on Cyber-Physical Systems CASCADE: An Asset-driven Approach to Build Security Assurance Cases for Automotive Systems • 27 ISO/SAE-21434śCASCADE Mapping ś Continued from previous page Correspond- Correspond- Corresponding Corresponding Support- Item ID Item type ing SAC ing CASCADE CASCADE block CASCADE level ing WP element element Security require- RQ-10-03 Requirement Claim CQ claim Resolver WP-10-01 ments Security require- RQ-10-04 Requirement Claim Claim Resolver WP-10-01 ments Security require- RQ-10-05 Requirement Claim Claim Resolver WP-10-02 ments Security require- RQ-10-06 Requirement Assumption Assumption Resolver WP-10-02 ments Security require- RQ-10-07 Requirement Claim CQ claim Resolver WP-10-03 ments Security require- RQ-10-08 Requirement Claim CQ claim Resolver WP-10-03 ments RQ-10-09 Requirement Claim Claim Resolver Risk assessment WP-10-04 RQ-10-10 Requirement Claim CQ claim Resolver Risk assessment WP-10-04 RQ-10-11 Requirement Claim CQ claim Resolver Risk assessment WP-10-04 Security require- RQ-10-12 Requirement Claim CQ claim Resolver WP-10-06 ments RQ-10-13 Requirement Claim Claim Resolver Risk assessment WP-10-05 Security require- RQ-10-14 Requirement Assumption Assumption Resolver WP-10-06 ments Security require- RQ-10-15 Requirement Claim Claim Resolver WP-10-06 ments RQ-10-16 Requirement Claim CQ claim Resolver Risk assessment WP-10-06 RQ-10-17 Requirement Assumption Assumption Resolver Risk assessment WP-10-06 RQ-10-18 Requirement Assumption Assumption Resolver Risk assessment WP-10-06 RQ-10-19 Requirement Claim Claim Generic sub-case WP-10-07 RQ-10-20 Requirement Claim CQ claim Generic sub-case WP-10-07 RQ-10-21 Requirement Claim CQ claim Generic sub-case Work Prod- WP-10-01 Evidence Evidence uct Work Prod- WP-10-02 Evidence Evidence uct Work Prod- WP-10-03 Evidence Evidence uct Work Prod- WP-10-04 Evidence Evidence uct Work Prod- WP-10-05 Evidence Evidence uct ISO/SAE-21434śCASCADE Mapping ś Continued on next page ACM Transactions on Cyber-Physical Systems 28 • Mazem Mohamad et al. ISO/SAE-21434śCASCADE Mapping ś Continued from previous page Correspond- Correspond- Corresponding Corresponding Support- Item ID Item type ing SAC ing CASCADE CASCADE block CASCADE level ing WP element element Work Prod- WP-10-06 Evidence Evidence uct Work Prod- WP-10-07 Evidence Evidence Generic sub-case uct Work Prod- WP-10-08 Evidence Evidence Generic sub-case uct RQ-11-01 Requirement Claim CQ-Claim White hat Security goals WP-11-02 RQ-11-02 Requirement Context Context White hat Security goals WP-11-01 RQ-11-03 Requirement Claim Claim Black hat Attack paths WP-11-02 RQ-11-04 Requirement Claim CQ-Claim Resolver Risk assessment WP-11-02 Work Prod- WP-11-01 Context Context Top claim uct Work Prod- WP-11-02 Evidence Evidence uct Security require- RQ-12-01 Requirement Claim CQ-Claim Resolver WP-12-01 ments Work Prod- WP-12-01 Evidence Evidence uct Security require- RQ-13-01 Requirement Claim CQ-Claim Resolver WP-13-01 ments Security require- RQ-13-02 Requirement Claim Claim Resolver ments RQ-13-03 Requirement Context Context Black hat Threat-scenarios WP-13-02 Work Prod- WP-13-01 Evidence Evidence uct Work Prod- WP-13-02 Context Context Black hat Threat-scenarios uct Security require- RQ-13-04 Requirement Claim CQ-Claim Resolver ments Security require- RQ-13-05 Requirement Claim CQ-Claim Resolver ments RQ-13-06 Requirement Claim Claim Generic sub-case WP-13-03 Work Prod- WP-13-03 Context Context Generic sub-case uct RQ-14-01 Requirement Claim CQ-Claim White hat Security goals RQ-15-01 Requirement Claim Claim Generic sub-case Recommen- RC-15-01 Evidence Evidence Generic sub-case dation ISO/SAE-21434śCASCADE Mapping ś Continued on next page ACM Transactions on Cyber-Physical Systems CASCADE: An Asset-driven Approach to Build Security Assurance Cases for Automotive Systems • 29 ISO/SAE-21434śCASCADE Mapping ś Continued from previous page Correspond- Correspond- Corresponding Corresponding Support- Item ID Item type ing SAC ing CASCADE CASCADE block CASCADE level ing WP element element RQ-15-02 Requirement Claim Claim Generic sub-case RQ-15-03 Requirement Claim Claim Generic sub-case WP-15-01 Security require- RQ-15-04 Requirement Assumption Assumption Resolver WP-15-01 ments RQ-15-05 Requirement Assumption Assumption Top Claim WP-15-01 RQ-15-06 Requirement Assumption Assumption Top Claim WP-15-01 Security require- RQ-15-07 Requirement Assumption Assumption Resolver WP-15-01 ments Work Prod- WP-15-01 Context Context Generic sub-case uct ACM Transactions on Cyber-Physical Systems 30 • Mazem Mohamad et al. B CASCADE CONCEPTS Definition of CASCADE core security concepts and correspondence to ISO/SAE 21434 terminology CASCADE Concept Deinition Corresponding ISO/SAE 21434 concept A structured body of arguments and evidence Security Assurance used to reason about the security of a certain Cybersecurity case Case item. Any piece of tangible or intangible artifact that has a value to an organization. Compro- Asset Asset mising an asset might lead to damage scenar- ios An attribute of an asset including the CIA Security Property Cybersecurity Property triad A requirement to preserve a security property Security Goal Cybersecurity Goal of a certain asset An action that would lead to a compromising Threat Scenario Threat Scenario a security goal A set of actions that might lead to the realiza- Attack Path Attack Path tion of a threat scenario A combination of probability and impact of Risk Risk an uncertainty to the security of an asset The Cybersecurity Goal in ISO/SAE 21434 associates the cybersecurity requirement with one or more threat scenario. In CASCADE we capture the same concept in two diferent levels (Security Goals, and Threat Scenarios) to form the argumentation part of the SAC. ACM Transactions on Cyber-Physical Systems http://www.deepdyve.com/assets/images/DeepDyve-Logo-lg.png ACM Transactions on Cyber-Physical Systems Association for Computing Machinery

CASCADE: An Asset-driven Approach to Build Security Assurance Cases for Automotive Systems

Loading next page...
 
/lp/association-for-computing-machinery/cascade-an-asset-driven-approach-to-build-security-assurance-cases-for-BpGFnCrsup

References

References for this paper are not available at this time. We will be adding them shortly, thank you for your patience.

Publisher
Association for Computing Machinery
Copyright
Copyright © 2023 Copyright held by the owner/author(s).
ISSN
2378-962X
eISSN
2378-9638
DOI
10.1145/3569459
Publisher site
See Article on Publisher Site

Abstract

CASCADE: An Asset-driven Approach to Build Security Assurance Cases for Automotive Systems MAZEN MOHAMAD, Chalmers and University of Gothenburg, Sweden RODI JOLAK, Chalmers and University of Gothenburg, Sweden ÖRJAN ASKERDAL, Volvo Trucks, Sweden JAN-PHILIPP STEGHÖFER, Chalmers and University of Gothenburg, Sweden RICCARDO SCANDARIATO, Hamburg University of Technology, Germany Security Assurance Cases (SAC) are structured arguments and evidence bodies used to reason about the security of a certain system. SACs are gaining focus in the automotive industry as the needs for security assurance are growing in this domain. However, the state of the arts lacks a mature approach able to suit the needs of the automotive industry. In this paper, we present CASCADE, an asset-driven approach for creating SAC, which is inspired by the upcoming security standard ISO/SAE-21434 as well as the internal needs of automotive Original Equipment Manufacturers (OEMs). CASCADE also diferentiates itself from the state of the art by incorporating a way to reason about the quality of the constructed security assurance case. We created the approach by conducting an iterative design science research study. We illustrate the results using the example case of the road vehicle’s headlamp provided in the ISO standard. We also illustrate how our approach aligns well with the structure and content of the ISO/SAE-21434 standard, hence demonstrating the practical applicability of CASCADE in an industrial context. Additional Key Words and Phrases: security, assurance cases, automotive systems 1 INTRODUCTION Assurance cases are structured bodies of arguments and evidence used to reason about a certain property of a system. Security Assurance Cases (SAC) are a type of assurance case for the ield of cyber-security. In this paper, we turn our attention to the creation of a SAC, with a particular focus on the domain of automotive applications. As vehicles become more advanced and connected, security scrutiny has increased in this domain. Furthermore, new standards and regulations push towards assuring security for vehicular systems by using SAC. Similar to safety cases, which are required in safety standards, e.g., ISO-26262 19], SACs [ are explicitly required in ISO/SAE-2143420 [ ]. Additionally, SACs are required for all systems in production. In literature, some studies suggest the creation of SAC based on requirements derived from security standar 6, 9ds ]. Ho [ wever, there is no approach which helps to achieve conformance with the upcoming ISO/SAE-21434 standard. Additionally, since the requirements for SAC are new, there is no evidence in the literature that the knowledge base in industry is mature enough to achieve conformity to these requirements. Moreover, quality assurance of the SACs is missing in the reported approaches in literature, even though it is a very important aspect. In order for diferent stakeholders to use an SAC, it is essential to trust that the SAC’s argument is built with a suicient level of completeness, and that the evidence provides a suicient level of conidence to justify the targeted claims. Finally, Authors’ addresses: Mazen Mohamad, mazen.mohamad@gu.se, Chalmers and University of Gothenburg, Gothenburg, Sweden; Rodi Jolak, rodi.jolak@cse.gu.se, Chalmers and University of Gothenburg, Gothenburg, Sweden; Örjan Askerdal, orjan.askerdal.3@volvo.se, Volvo Trucks, Gothenburg, Sweden; Jan-Philipp Steghöfer, jan-philipp.steghofer@gu.se, Chalmers and University of Gothenburg, Gothenburg, Sweden; Riccardo Scandariato, riccardo.scandariato@tuhh.de, Hamburg University of Technology, Hamburg, Germany. Permission to make digital or hard copies of part or all of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for proit or commercial advantage and that copies bear this notice and the full citation on the irst page. Copyrights for third-party components of this work must be honored. For all other uses, contact the owner/author(s). © 2022 Copyright held by the owner/author(s). XXXX-XXXX/2022/11-ART https://doi.org/10.1145/3569459 ACM Transactions on Cyber-Physical Systems 2 • Mazem Mohamad et al. we identiied that the lack of industry involvement is a signiicant issue in current approaches. This results in gaps between research and industry. To bridge these gaps, we have worked together with Volvo Trucks and Volvo Cars, two international automotive OEMs located in Sweden, to develop CASCADE, the asset-driven approach for SAC creation presented in this paper. CASCADE is inspired by the structure of requirements and work products of ISO/SAE-21434. It is asset- driven, i.e., the resulted SACs have assets as drivers of the structure of the security arguments. Therefore, it allows creating security assurance based on what is valuable in the system. Additionally, we integrated quality assurance in SACs created with CASCADE by distinguishing between product-related claims and case quality-claims, as well as building arguments for both. CASCADE also governs where in the argument these case quality-claims need to be introduced. From a methodological standpoint, we created and validated our approach in a three cycle design science research study as follows. First, we created a high-level structure of an asset-driven SAC, which included the identiication of the assets, the tracing of such assets to system elements (e.g., processing, communication, and storage operations), and the identiication of the relevant security assets for each asset. Second, we improved the structure of CASCADE to better align with the development activities at automotive companies and better cover their needs for SAC including the need to confront with ISO/SAE-21434. We then illustrated the approach using the exemplary case study mentioned in ISO/SAE-21434. Finally, we presented the resulting approach to the security experts from an industrial automotive OEM and gathered their feedback. Lastly, we further evaluated CASCADE by mapping the requirements and work products of ISO/SAE-21434 standard to the corresponding CASCADE elements. We analyzed the results and created a guideline for practitioners and researchers to enable the replication of the mapping activity on the same or a diferent standard. The results are presented in Sections 4ś7, after discussing the related work in Section 2 and the methodology in Section 3. This work is an extension of a previously published23study ]. The[overall contributions of this work are the following: • CASCADE, an asset-driven approach for the creation of the security assurance cases, which is inspired by the upcoming security standard in the automotive domain. CASCADE also diferentiates itself from the state of the art by incorporating a way to reason about the quality of the constructed security assurance case. • A validation of the CASCADE approach by (i) involving an automotive OEM located in Sweden and (ii) illustrating how CASCADE aligns with the structure and content of the ISO/SAE-21434 standard, hence demonstrating the practical applicability of CASCADE in an industrial context. • A guideline to map items of security standards to the elements of a CASCADE security case. This guideline helps practitioners to fulill their compliance requirements. 2 BACKGROUND AND RELATED WORK In this section, we provide background information about SAC, security assets in automotive, and their corre- sponding security threats and attacks. We also review related work of asset-based approaches in the literature. 2.1 Security Assurance Cases Assurance cases are bodies of evidence organized in structured arguments, used to justify that certain claims about a system’s property hold [11]. They are deined by the GSN standard [12] as A ł reasoned and compelling argument, supported by a body of evidence, that a system, service or organisation will operate as intended for a deined application in a deined environment.ž ACM Transactions on Cyber-Physical Systems CASCADE: An Asset-driven Approach to Build Security Assurance Cases for Automotive Systems • 3 Security Assurance Case (SAC) are a special type of assurance cases where the argument consists of claims about security for the system in question, and the evidence justiies these security-related claims. SAC consist of the following primary components [5, 21]: • Security claims: These claims vary in terms of abstraction level. At the beginning of the argument, they are high level, but then they get more ine-grained as the argument evolves. The claims are usually derived from requirement speciications of the system in question. • Context: This refers to the context in which the claims should hold. In other words, it sets the scope of the argument. For example, a context could be a document that deines the required level of security desired by the organization creating the SAC. • Strategy: Building the argument means that the claims are decomposed into sub-claims in an iterative manner until they reach a point where evidence can be assigned to support them. During this process, decisions have to be made on how to decompose a certain claim, e.g., by considering the diferent security properties or diferent possible threats. These decisions are called strategies in SAC. • Evidence: A body of evidence is provided to prove the claims created in the argument. An example of a piece of evidence is a test report showing that the code base of a certain ECU passes all the tests. Another example is a report created by a security expert which proves that a realization of a vulnerability is not possible. SAC can be expressed in a textual or graphical format 5]. The [ most common graphical formats are the Goal Structure Notation (GSN, [27]), and the Claims, Arguments, and Evidence notation (CAE, [1]). 2.2 Automotive Assets and Related Security Threats According to26 [ ], there are four categories of assets in automotive systems that are targeted by security threats and attacks. These assets are hardware, software, network and communication, and data storage. • Hardware: This asset category includes sensors, actuators, and the hardware part of the Electronic Control Units (ECUs). These assets are often threatened by disruption or direct interventions that inluence their availability and integrity. Examples of attacks on these assets include fault injection through the installation of malicious hardware leading to compromising availability. • Software: This category includes external libraries, Operating Systems (OS), applications, virtualization, and the software part of the ECUs. Security threats and attacks on software assets include the manipulation of software, such as tampering attacks which often target software availability and integrity. • Network/Communication : Refers to internal or external communication. Internal communication assets are busses such as CAN, FlexRay, LIN, MOST, and automotive Ethernet. External communication assets are WiFi, Bluetooth, and Vehicle to Everything (V2X) communication. Examples of attacks on these assets include fabrication or jamming attacks, spooing, message collision, eavesdropping, hijacking, and denial of service (DoS). These attacks might compromise the conidentiality, integrity, and availability of the these assets. • Data storage: Sensitive data including user data, backups, cryptographic keys, forensics logs, and system information and reports. These assets are targeted by unauthorized access and malicious manipulation that often inluence the conidentiality, integrity, and availability of the data. 2.3 Asset based approaches Researchers have been exploring several asset-based approaches for creating the argument part of SAC. Biao et al. [29] suggest dividing the argument into diferent layers, and using diferent patterns (one per layer) to create the part of the argument that corresponds to each layer. Assets are considered as one of these layers, and the pattern used to create it includes claims that the assets are łunder protectionž, and strategies to break ACM Transactions on Cyber-Physical Systems 4 • Mazem Mohamad et al. down critical assets. Biao et29 al. ], ho [ wever, do not consider the quality of the cases and only focus on creating arguments without touching upon the evidence part. Luburic et22al. ] also [ present an asset-centric approach for security assurance. The info used in their approach is taken(i) frasset om: inventories; (ii)Data Flow Diagrams (DFD) of particular assets and the components that manipulate them;(iii) andthe security policy that deines protective mechanisms for the components from the previous point. They propose a domain model where assets are the center pieces. The assets are linked to security goals. The argument considers the protection of the assets throughout their life-cycles by arguing about protecting the components that store, process, and transmit those assets. The SAC they provide is very high level and includes two strategies: łreasonable protection for all sensitive assetsž and arguing over the data-low of each related component. The authors state that the main limitations of their approach are asset and data low granularity. In our study, we consider the assets to be the driver of our approach, but we extend the argument to reach the level of concrete security requirements. We also derive our strategies from an industrial standard and validate our approach in collaboration with an OEM. Furthermore, we extend our approach to include case-quality aspects. 2.4 Standard-based approaches Multiple researchers have explored extracting requirements from security standards for the creation of the arguments of SAC. None of these studies have, however, targeted the upcoming standard ISO/SAE-21434 for cybersecurity in automotive. Finnegan et4,al. 10][present a framework for the creation of security cases for medical devices. Their framework incorporates multiple security documents, e.g., standards and best practices, in order to develop a security argumentation pattern. The pattern provides a compr ł ehensive matrix showing the link between the security risks, associated causes, the mitigating security controls and evidence of those controls being implemented to establish the security capability.ž Ankrum et al. [7] studied the mapping of security and safety standards in safety-critical domains to assurance cases. They used the Goal Structuring Notation (GSN) and ASCAD (Claims ś Arguments ś Evidence) which are the most common notations for documenting assurance cases. The security standard used in the study was the Common Criteria for Information Technology Security Evaluation, ISO/IEC 15408:1999 17]. Ankrum [ et. al describe challenges they encountered while conducting the mapping as well as lessons learned. In this work, we are using the upcoming ISO/SAE 21434 standard to structure an approach for creating SAC, while also considering the industrial needs from the automotive domain. The reason for using this particular standard is that it includes a requirement that explicitly requires a security case to be created. Hence, if a company wants to conform with the standard, it needs to create security cases for its products. However, conformance with the standard is not the only need of automotive OEMs when it comes to assurance cases. We have identiied multiple usage scenarios in our previous 24 work ]. In[order to create SAC that are suitable for these scenarios, the quality aspect of the cases needs to be considered, which we cover in our approach. Birch et al.8][ suggest a layered model for structuring arguments of automotive safety assurance cases. The model is built to help satisfying the requirement to build safety cases in 19ISO ]. It 26262 consists [ of a core argument layer representing the rationale behind safety requirements, as well as three other layers of arguments representing the relationship of the requirements to the corresponding artefacts, the means used in their development and the environment in which safety activities are undertaken. The core argument proposed by Birch et al. serves a similar purpose to our case quality-claims in terms of completeness, but only on the requirements level. In our work, we require such claims to be added every time a decomposition takes place. This diference is due to the diferent natures of functional safety and security. In functional safety assurance cases, the arguments are driven by the requirements, while in our approach, we drive it by assets and only reach the requirements after going through multiple levels of arguments. Moreover, the layered approach includes a layer for the environment and another for the means used in developing. In our approach, we regard these as ACM Transactions on Cyber-Physical Systems CASCADE: An Asset-driven Approach to Build Security Assurance Cases for Automotive Systems • 5 being claims that potentially apply to diferent cases and would be reused, and hence document them in a special argumentation block we call the generic-sub case. Additionally, we consider another type of case quality-claims, which is the conidence claims associated with the evidence. 3 METHODOLOGY Iteration 1: Inception Inception Improvement Mapping Awareness of the Need for an approach to Need to further consider Need for evaluation against problem conform with ISO/SAE internal needs upcoming standards Suggestion Asset-based approach Integrate quality assurance Mapping to ISO/SAE-21434 Development Initial approach CASCADE Mapping table and guidelines Iteration 2: Improvement developed Evaluation Discussion with Illustration on ISO/SAE Lessons learned from the industrial partners 21434 use case + mapping activity evaluation at OEM Conclusion Need to further consider Need for evaluation Potential enhancement and internal needs against upcoming future work standards Iteration 3: Mapping Fig. 1. Three-iteration Design Science Research Design science research is a problem-solving methodology, which aims at developing artefacts to extend existing boundaries in a given conte 15].xtW[e conducted three research iterations, following the design science guidelines proposed by Hevner et al. 15].[ In each iteration we followed the ive-step process proposed by Vaishnavi and Kuechler 28],[ which consists awar of eness of the problem, suggestion, development, evaluation, and conclusionsteps. The three-iteration process is depicted in Figure 1. The igure also shows a brief summary of each design science research step for each cycle. In the irst iteration, Inception, our aim was to address the needs for security assurance cases that were identiied in a previous study 24[]. Speciically, we investigated how an asset-based approach for the creation of security assurance cases can assist automotive companies to fulill their needs to conform with the upcoming ISO/SAE- 21434 standard. We suggested an initial asset-based approach and used an open-source system speciication of a supermarket management system [3] to illustrate it. The approach and the outcome of the illustration were discussed and evaluated with security experts at two large automotive OEMs. The main input from the experts was focused on the need to align the structure of the approach with the internal way of working at the companies, which is also one of the needs identiied in our previous 24].wAnother ork [ aspect of improvement that emerged from the evaluation of the inception iteration is the need for a mechanism to assure the quality of the approach’s outcome. We concluded that there is a need to further consider the internal needs of companies when designing an approach for creating SAC. In the second iteration Improvement, we aimed at incorporating the experience and feedback gathered in the irst iteration in order to improve the asset-based approach. The suggestion of this iteration was to integrate ACM Transactions on Cyber-Physical Systems 6 • Mazem Mohamad et al. quality assurance aspects within the approach. Hence, in the development phase, we created CASCADE, an asset-based approach for SAC creation with built-in quality assurance. The structure of CASCADE is inspired by the structure of requirements and work products of ISO/SAE-21434, and incorporates the need to assure the quality of the SAC. It is based on the requirements that emerged from applying the initial approach as well as on the way of working at the automotive companies we consulted in the irst iteration. To evaluate CASCADE, we applied it on an example case of a vehicle’s headlamp item from ISO/SAE-21434 and presented the outcome to the security experts at two OEMs we also consulted in the irst iteration. As a conclusion of the second iteration, we identiied areas for enhancement of CASCADE to fulill a wider range of the internal needs of the company, as well as the need to assess whether CASCADE has the capacity to include the items of the security standard ISO/SAE-21434. In the third iteration Mapping, we aimed at further validating CASCADE by analyzing the mapping of the requirements and work products from ISO/SAE 21434 to CASCADE elements. The mapping allows us to evaluate CASCADE’s coverage of the items of the standard (requirements and work products) and to point out potential improvements of CASCADE. For each requirement and work product in ISO/SAE 21434 (168 in total), we identiied the corresponding SAC element, CASCADE element, CASCADE block, and CASCADE level it belongs to. Two researchers contributed to the mapping activity to avoid assessment bias. First 17 (10%) of the requirements and work products were selected using the stratiied random sampling method where each clause in the standard was treated as one strata. The two researchers then independently mapped the requirements and work products to CASCADE, and reached an agreement of 71%. For the remaining 29%, there was a calibration exercise where the disagreement was discussed and an agreement on the mapping was achieved for all 17 requirements and work products. The researchers then each worked on half of the requirements and work products, and reviewed the other half. The mapping results are available in the Table in Appendix A. As an evaluation step, we studied the lessons learned from the process and results of the mapping activity and came up with potential enhancements on CASCADE. The result of this step is available in Section 7. Based on the experience gained during the mapping, we constructed a guideline to enable the replication of the mapping activity we conducted in this study, or to test it on other security standards in automotive or other safety critical domains. As conclusion, we identiied areas for future work to further improve CASCADE and its applicability in the automotive domain. 4 CASCADE In general terms, assets are artifacts of interest to a certain entity. In computer security, these artifacts can be hardware, software, network and communication, or data 26].[ The importance of assets makes them the target of attackers. The CASCADE approach for creating security assurance cases takes the importance of assets to organizations into consideration. Hence, it builds the argumentation by putting assets in focus, with the goal to show that these assets are secure from cybersecurity attacks. Our aim is to prove that a given artefact is secure by arguing that its assets are secure. An important design principle in the CASCADE approach is the integration of quality assurance of the cases in terms of argumentation completeness and evidence conidence. Each level of argumentation (i.e., strategy) is associated with at least one claim about the completeness, and each level of evidence is associated with at least one claim about conidence. A similar concept is used by Hawkins 14]ettoal. argue [ about the conidence of safety cases. We use the same security terminologies and concepts used in ISO/SAE 21434. The only exception Security is Goal concept in the standard, which we split up in CASCADE in two diferent levels (security goals and threat ACM Transactions on Cyber-Physical Systems CASCADE: An Asset-driven Approach to Build Security Assurance Cases for Automotive Systems • 7 Top Claim White-hat Block Level 1: Asset identification and decomposition Level 2: Security goals Black-hat Block Level 1: Threat scenarios QA Level 2: Attack paths Resolver Block Level 1: Risk assessment Level 2: Security requirements Evidence QA Fig. 2. The CASCADE approach for creating security assurance cases scenarios). Appendix B includes a table with the core security terms and concepts in CASCADE, their deinitions, and the corresponding ISO/SAE 21434 concepts. 4.1 Elements of an SAC in CASCADE We use GSN [27] to create SAC using the CASCADE approach. The elements of the notation ar (i)e:Claim: a security claim about the artefact in question; (ii)Strategy: a method used to decompose a claim into sub-claims; (iii) Evidence / Solution: a justiication of a Claim / set of (ivclaims; )Context: used to set a scope of a given claim; and (v) Assumption: used to document the assumptions made for a certain claim. In addition to these, we have created additional types of elements to be used in our appr (vi)oach: Case Quality- claims (CQ-claims): represent claims about the quality of the created case (vii) itself; Case Quality-evidence (CQ-evidence): represent evidence used to justify CQ-claims; (viii) andGeneric sub-case: consist of claims, strategies, contexts, assumptions, and evidence that are not bound to a speciic artifact, but instead are applicable to a wider range of artifacts in the context of a product, program, or organization. 4.2 Building blocks of the CASCADE approach The asset-based approach consists of building blocks, as shown in Figure 2. Each block contains a sub-set of the case. In the following sub-sections, we explain the blocks and their contents. 4.2.1 Top claim. This block consists of the top security claim of the artefact in question. It also includes the context of the claim and assumptions made to set the scope of the claim. If we are considering a software In GSN, the terms goal and subgoal are used to refer to high and low abstraction levels of argumentation claims respectively. To avoid confusion, we refer to these as claims. ACM Transactions on Cyber-Physical Systems Generic Sub-case 8 • Mazem Mohamad et al. system, e.g., we might make an assumption that the hardware is secure. The top claim difers between diferent organizations and drives the granularity of the SAC. For example a service provider might consider the security of a service to be the top claim, but an automotive OEM might need to consider the whole vehicle’s security, which requires the incorporation of diferent services or user functions. Similarly, depending on the intended usage of the SAC, the top claim might include back-end systems, or only on-board systems. For example to assure the security of a complete vehicle, it is important to make sure that not only the vehicle’s components are secure, but also the back-end systems which communicate with the vehicle. In contrast, to ensure that a certain end-user function in the vehicle is secure, it might be enough to only consider the corresponding sub-systems in the vehicle itself. As CASCADE does not specify an abstraction level for the top claims of the SACs. Hence, it is possible to create SACs for complete products or for various components or functionalities of a system. However, in the latter case, there is a need for compositional claims combining two or more components, especially when there are inter-dependencies among the components. This might cause the emergence of new assets, security goals, threats... etc. CASCADE does not speciically handle these dependencies, but rather relects the applied security measures and controls. However, it is important to document the scope of the claims in context nodes, as well as all the assumptions made when creating the argument. 4.2.2 Generic sub-caseThis . block contains a sub-case that is applicable not only to the artefact for which the SAC is being created but instead to a larger context. For example, if a company deines a cybersecurity policy, enforced by cybersecurity rules and processes, then the policy can be used in security claims for all its products. These claims can be re-used when creating SAC for individual artefacts. Another example is when certain claims can be made on a product level. Then these claims can be reused for all SAC of individual components of that product. Our aim with this block is to make the approach scalable in larger organizations with complex products and multiple teams. Each team can work on a part of the SAC which corresponds to their artefact. On a higher level, these SAC can be combined together, and generic arguments that are applicable to the sub-SAC can be provided. 4.2.3 White-hat block. This block starts with the identiication of assets, which is the driver of our approach. Asset identiication is done by conducting an analysis to ind the artefacts of the system that are likely to be subject to an attack. When the assets are identiied, they can be further decomposed during the diferent phases of the development life-cycle. For example in an OEM, a high-level asset analysis is done at the concept phase, and later a low-level analysis is conducted during implementation, where more information about the assets and their usage is known. Linking assets to higher-level claims. To link the assets to the main claim, we identify which assets exist and which components use or have access to these assets. For example, in a vehicle, the driver’s information can be considered an asset that is accessible by the infotainment system of the vehicle. Hence, we link this asset to the claims of the security of the infotainment system. To make this more concrete, we look at the traceability of the asset. For example, we consider the assets (i)łat restž, which refers to where the assets are stored; (ii)on ł the move,ž when the asset is in transition between two entities, e.g., when sensor data is being transferred from the sensor to an ECU; and (iii) łin use,ž which is when the asset is being used, e.g., when some diagnostics data is being processed by a back-end system. Decomposition of assets.To decompose assets, we look into the types of the identiied assets. This gives an indicator of whether the asset would have implications on the local part of the vehicle (one electronic control unit/ECU), or on a bigger part of the vehicle (multiple ECUs). We also look into the relations among assets, e.g., dependability. ACM Transactions on Cyber-Physical Systems CASCADE: An Asset-driven Approach to Build Security Assurance Cases for Automotive Systems • 9 Linking assets to the lower level.To link the asset to the lower level in the approach, i.e., the security goals, we identify the relevant security properties for the assets. Speciically, we look into the Conidentiality, Integrity, and Availability (CIA) triad. For example, the vehicle engine’s start functionality is an asset that has relevant integrity and availability properties. Identiication of security goals. When we have identiied the relevant security properties for each asset, we create claims representing the security goals . Following our example of the engine start request, a claim about the achievement of a security goal would be that the availability of the request is preserved. One combination of asset/security property might lead to several goals, for example that the engine start is available using a connected mobile app and a web portal. To make sure the relevant properties are covered when identifying security goals, we consider damage scenarios that lead to compromising the security goals, e.g., that the engine start request is unavailable, or an unintended start of the engine occurs, which would damage the integrity of the asset. 4.2.4 Black-hat block. In this block, we aim to identify the scenarios that might lead to not fulilling the identiied security goals and hence cause harm to our identiied assets. Identiication of threat scenarios. When we have identiied the claims about the achievement of security goals, we proceed by identifying the threat scenarios and creating claims for negating the possibility of these scenarios. We connect these claims to the corresponding claims about achieving security goals. For example, a claim handling a threat scenario connected to the claim łUnintended request for engine start is not possible,ž might be identiied by considering a threat model, e.g., STRIDE 16].[ Hence a claim might look like: łSpooing a request for engine start is not possible.ž Identiication of possible attack paths. In this step, we identify possible attack paths which can lead to the realization of a threat scenario. Each threat scenario might be associated with multiple attack paths. We then claim the opposite of these attack paths. An example of an attack path is An ł attacker compromises the cellular interface and sends a request to start the engine,ž and the claim would be to negate the possibility for that. 4.2.5 Resolver block. This block is the last one in the argumentation part of the CASCADE approach. It links the claims derived from the attack paths to the evidence. Risk assessment.In this level, we assess the risk of the identiied attack paths. Based on the risk level, the creators of the SAC create claims to treat the risk by, e.g., accepting, mitigating, or transferring it. Requirements.At this point, requirements of risk treatments identiied in the previous level are to be expressed as claims. This level may contain multiple decompositions of claims, based on the level of detail the creators of the SAC wish to achieve, which is driven by the potential usage of the SAC. For instance, if the SAC is to be used by a development team to assess the security level, this might require a ine-grained requirement decomposition which might go all the way to the code level. In contrast, if the SAC is to be used to communicate security issues with outside parties, a higher level of granularity might be chosen. In either case, it is important to reach an łactionablež level, meaning that the claims should reach a point where evidence can be assigned to justify them. 4.2.6 Evidence. The evidence is a crucial part of an SAC. The quality of the argument does not matter if it cannot be justiied by evidence. In our approach, evidence can be provided at any block of the argumentation. For example, if it can be proven in the black-hat block that a certain asset is not subject to any threat scenario, then evidence can be provided, and the corresponding claims can be considered justiied. If the creators of the SAC cannot assign evidence to claims, this is an indicator that either the argument did not reach an actionable point A security goal is preserving a security concern (CIA) for an asset [13] ACM Transactions on Cyber-Physical Systems 10 • Mazem Mohamad et al. or that there is a need to go back and make development changes to satisfy the claims. For example, if we reach a claim which is not covered by any test report, then there might be a need to create test cases to cover that claim. 4.2.7 Case uality AssuranceW . e consider two main aspects of quality assurance for SAC in CASCADE. The irst aspect is completeness which refers to the level of coverage of the claims in each argumentation level of the SAC. Each level in CASCADE includes at least one strategy. For each strategy, we add at least one completeness claim that reines it. The role of this claim is to make sure that the strategy covers all and only the relevant claims on the argumentation level. These completeness claims in CASCADE are used to gain conidence in the provided arguments. We have identiied the strategy elements in the arguments to be attention points where these claims need to be made. The content of the completeness claims depends on the way of working in a company, i.e., the documented activities and procedures that are expected to be formed. This dependency should be documented in a context node which sets the scope for the completeness claim. For example, if a company uses pre-deined catalogues of known attack patterns, e.g., the Common Attack Pattern Enumeration and Classiication (CAPEC) catalogue 2], then [ the context node should refer to the catalogue, and the claim would hence take the form: "All attack paths have been considered in accordance to document X", where the document refers to the catalogue. Another example is when a company deines a Deinition of Done (DoD) for their activities, then the context nodes should refer to the corresponding DoD. Additionally, working with cybersecurity always involves uncertainties. This is due to multiple factors, e.g., the limited knowledge of the capabilities of an attacker or unforeseen vulnerabilities. This again emphasizes the importance to set a scope for the completeness arguments. In addition to the context nodes, assumption nodes also need to be speciied. These together provide the information needed to determine if the completeness claim is fulilled or not within the scope of knowledge the company has given the assumptions made by the adopting organization. It is also important to phrase the claims in a way that relects its scope and limitations. The second aspect isevidence-conidencewhich indicates the level of certainty that a claim is fulilled based on the provided evidence. This is used in each level of a security assurance case where at least one claim is justiied by evidence. The evidence-conidence aspect is expressed as a claim, which takes the form: łThe evidence provided for claim X achieves an acceptable level of conidence.ž What makes an acceptable level of conidence is deined in the context of the strategy. The conidence claim itself must be justiied by evidence. 5 EXAMPLE CASE To validate our approach, we apply CASCADE on the headlamp item use case from ISO/SAE-21434 which includes the headlamp system, navigation ECU, and gateway ECU. Figures 3,4,5 present the resulted part of the SAC that correspond to each block of CASCADE. The ile shapes in the top-right corners of each level in Figures 3,4,5 indicate the requirement in ISO/SAE-21434 which mainly drives the argument in the corresponding level. The strategies used to form the argument of the headlamp example case are created to demonstrate the structure of a security assurance case built with CASCADE. We believe that it would be beneicial to have an initial set of strategies for each block as a starting point. However, we this requires an industrial application of CASCADE resulting multiple SACs, from which patterns can be extracted, and hence a set of strategies. This is a future work that we intend to do. 5.1 Top Claim We start by constructing the Top Claim block consisting of: • C:1 the top security claim for the headlamp item, which is that the headlamp item is adequately secure. • Cnxt:1.1 a context node setting the scope of the claim. This scope is set by the headlamp item boundary description, which is available in the example case in ISO/SAE-21434 ACM Transactions on Cyber-Physical Systems CASCADE: An Asset-driven Approach to Build Security Assurance Cases for Automotive Systems • 11 White-hat CQ:1.1.1 Asset identification and decomposition S:1.1 All relevant asset are Argue over RQ-06-02 identified identified assets of the headlamp item C:1.1.2 C:1.1.1 CAN Frame is acceptably Firmware is acceptably secure secure CQ:1.2.1.1 S:1.2.1 S:1.2.2 CQ:1.2.2.1 All relevant decompositions All relevant decompositions Argue over the decomposition of the Argue over the decomposition of the of the CAN frame are of the firmware are CAN frame asset Firmware asset considered considered Text C:1.2.1.1 C:1.2.1.2 C:1.2.2.1 C:1.2.2.2 C:1.2.2.3 C:1.2.2.4 The CAN message The oncoming car The CAN message The lamp low ON/HI The power switch control is The headlamp control is transmission is acceptably information Yes/No CAN transmission is acceptably ON/OFF request CAN acceptably secure acceptably secure secure in the body control message is acceptably secure in the power switch message is acceptably ECU secure actuator secure Security goals CQ:1.3.2.1 S:1.3.2 S:1.3.3 RQ-09-05 All relevant security properties of the Argue over the security properties of the Argue over the security properties of the CAN message transmission in the CAN message transmission in the CAN message transmission in the body control ECU are considered body control ECU power switch actuator S:1.4.2 C:1.3.2.1 C:1.3.2.2 C:1.3.3.1 Argue over identified damage scenarios that might results The Integrity of the The Availability of the The Integrity of the from the loss of integrity of the CAN CAN message transmission in the CAN message transmission in the CAN message transmission in the message transmission body control ECU is preserved body control ECU is preserved power switch actuator is preserved in the body control ECU CQ:1.4.2.1 CQ:1.4.2.2 Unintended turning off of Unintended turning off of headlamps headlamps during IGN switch's during night driving is not possible turn-off is not possible Fig. 3. White-hat block of the headlamp use case - The file shaped box in the top-right corner of each level indicates the requirement in ISO/SAE-21434 which drives the argument in that level • Assmp:1.1 an assumption node, stating that the item is physically protected. Hence, we only consider the security of the software part of the headlamp item in our argument. The context node refers to an external document, which is the item boundary and preliminary architecture of the headlamp item, as identiied in ISO/SAE-21434. 5.2 White-hat Block The White-hat block is presented in Figure 3. We irst apply a strategy S:1.1 to decompose our main claim based on the identiied assets of the headlamp item. In our example, the main assetsCAN are the Frame, which holds transmitted messages, and theFirmware which includes control functions of the artifacts inside the headlamp system, e.g., the power switch. We create two claims C:1.1.1 and C:1.1.2 indicating that the two assets are acceptably secure. The strategy S:1.1 is associated with a case quality-claim CQ:1.1.1, to ensure the completeness of the decomposition associated with it, and hence the completeness of the case in general. The two identiied assets are further decomposed into sub-assets. This decomposition is based on the com- ponents and functions the asset belongs to. For example, based on claim C:1.1.2 we apply strategyS:1.2.2 and decompose the CAN Frame asset into a number of sub-assets. Moreover, we create security claims for the identiied ACM Transactions on Cyber-Physical Systems 12 • Mazem Mohamad et al. sub-assets: C:1.2.2.1, C:1.2.2.2, C:1.2.2.3, and C:1.2.2.4. Lastly, strategyS:1.2.2 is associated with case quality-claim CQ:1.2.2.1. At this point, we link the assets to the security goals (i.e., second level). To do so, we apply an argumentation strategy (e.g., S:1.3.2) to decompose the security claims of the sub-assets based on the CIA triad attributes. As a result, we create claims about the achievement of security goals such C:1.3.2.1 as : ł The integrity of CAN message transmission in the body control ECU is preserv.ž eTdo make sure that we cover the relevant properties, we create a case quality-claim CQ:1.3.2.1 and argue (S:1.4.2) about possible damage scenarios that could invalidate the claims. Accordingly, we create case quality-claims which make sure that these damage scenarios do not happen. An example of these claimsCQ:1.4.2.1 is : ł Unintended turning of of headlamps during night driving is not possible .ž At this point, the claim is ine-grained enough and counts as a security goal. Next, we create the black-hat block. 5.3 Black-hat Block Here we argue over the threat scenarios that could lead to compromising a security goal. Figure 4 shows a part of the black-hat block of the headlamp use case. This part is associated with the claim about achieving a security goal C:1.4.2.1 that is shown in Figure 3. We start by creating strategy S:1.5.1 to argue over the used threat model. If e.g., STRIDE is used as a threat model, then the strategy would be to create a claim for each STRIDE category. In our example case, we create claim C:1.5.1.1: ł Spooing of a signal leading to loss of integrity of the CAN message of Lamp Request signal of power switch actuator ECU is not possible .ž To ensure the completeness of the case, we further associate the strategy S:1.5.1 with a case quality-claim CQ:1.5.1.1 ( ). At this point, our claims become more concrete as we have a speciic item, asset, container component, security property, damage scenario, and threat scenario. We use the analysis of attack paths to further decompose and populate the example case. We apply strategy S:1.6.1 to argue over the attacks and create attack path claims. The resulting claims negate the possibility for an attack path to take place C:1.6.1.4 , e.g.,ł It is not possible for an attacker to compromise the Navigation ECU from a cellular interface .ž As for all strategies in CASCADE, we associate the strategy used in the attack path with a case quality-claim CQ:1.6.1.1 ( ) to ensure the completeness of the case. To set a scope for the case quality-claims, we add the context noCN desTX:1.5.1 ( ) and (CNTX:1.6.1). These nodes refer to pre-deined catalogues of known threat scenarios and attack paths, and are used to make sure that they have been considered, and hence, gain conidence in the completeness of the SAC. 5.4 Resolver and Evidence Blocks In this stage, we create the resolver block by investigating ways to resolve the attack paths based on a risk assessment and creating requirements for the intended risk treatments. Figure 5 shows a part of the resolver block for our example case associated with the attack C:1.6.1.4 path . The outcome of the risk assessment would be to accept, mitigate, transfer, or solve the risk. When a risk is accepted, then there is no need to further decompose the claim. In the other cases, a strategy S:1.7.1 ( ) to decompose the risk of an attack path has to be created. In our example, we create claim C:1.7.1.1 to mitigate the risk as follo The ws: ł risk of an attacker compromising the Navigation ECU from a cellular interface is r.žeduced This leads to the stage where we argue on the requirements in order to specify how the risk has to be reduced or mitigated. An example of a requirement claim C:1.8.1.1 is: ł The received data is veriied if it is sent from a valid entityž. Figure 5 also shows the evidence block which provides examples of evidence to justify the requirement’s claims. The evidence (e.g.,E:1.1) is supported by case quality-evidence (CQE:1.1 e.g., ) which, in turn, is complemented with case quality-claims CQ:1.8.1.1 (e.g., ) to conidently justify the associated requirement claims. ACM Transactions on Cyber-Physical Systems CASCADE: An Asset-driven Approach to Build Security Assurance Cases for Automotive Systems • 13 Fig. 4. Black-hat block of the headlamp use case - The file shaped box in the top-right corner of each level indicates the requirement in ISO/SAE-21434 which drives the argument in that level 5.5 Generic Sub-case Block Figure 6 shows the last block in our example; the generic sub-case. This block includes claims that are relevant to the example case but are not speciic to it. For example, claim C:G2 states that ł The company has a security-aware culture,ž which is supported by two evidence statements; E:G2.1 and E:G2.2 to prove that the employees of the company were given a security training. The evidence provided to support C:G2 claim in this example are used to demonstrate the type of evidence that can be used in the generic sub-case block. In a real-world scenario, these evidence might not suice and additional contexts, assumptions, and evidence might need to be provided in order to justify the security culture of the company, e.g., in terms of trade-ofs that have to be made between spending resources for security or other activities. When all the evidence are provided, it’s important to assess the conidence they provide, and create a conidence CQ-claim and support it with relevant evidence. Similar to other blocks, the generic sub-case block might include strategies S:G1 (e.g., ) to break down claims. Moreover, these strategies are associated with case quality-claims QC:G.1.1 (e.g., ) as shown in Figure 6. 6 MAPPING TO ISO/SAE-21434 This section provides a set of guidelines that are extracted during the mapping exercise from the requirements and work products of ISO/SAE-21434 to elements of security assurance cases according to the GSN notation. The mapping exercise is based on the FDIS (Final Draft International Standard) version of ISO/SAE-21434. Figure 7 shows a mapping worklow that can be used to map each ISO/SAE-21434 item to a CASCADE element. Given an ISO/SAE-21434 item, it is irst classiied into Reeither quirement a or Work Product: • Requirement: As a general rule of thumb, requirements form the argument part of the SAC. A requirement is irst checked whether or not it includes an implication. If an implication (A implies B) is included, then it means that there are two possible outcomes: łnot A or Bž. Here the corresponding SAC element is either an assumption of the negation of A, or a requirement B. For example let us consider the following requirement: ACM Transactions on Cyber-Physical Systems 14 • Mazem Mohamad et al. Resolver S:1.7.1 Risk assessment CQ:1.7.1.1 Argue over the treatment based on RQ-08-11 The top down concept design the assigned risk level has to be verified by a bottom up analysis of the risks C:1.7..1.1 The risk of an attacker compromises Navigation ECU from a cellular interface is reduced S:1.8.1 Requirements RQ-12-01 Argue over cybersecurity requirements to handle risk treatment C:1.8.1.1 C:1.8.1.2 CQ:1.8.1.1 Unauthenticated entities are Evidence E:1.1 , E:1.2 The received data is verified if it is acceptably justify associated prevented from accessing the sent from a valid entity claims cellular network Evidence E:1.1 E:1.2 CQE:1.1 Verification Verification Test coverage report report xx report xy Fig. 5. Resolver and evidence blocks of the headlamp use case - The file shaped box in the top-right corner of each level indicates the requirement in ISO/SAE-21434 which drives the argument in that level łIf the cybersecurity activity X is applied, then a rationale R shall be providedž. If the cybersecurity activity X is not applied, then this requirement is mapped Assumption to an . If otherwise X is in fact applied (i.e., that a rationale R is provided), then the requirement is checked whether it is a process- or product-oriented. If the requirement is process-oriented (e.g., refers to the overall cybersecurity management or culture in the organization), then it is considereClaim d as a within the Generic sub-case . Otherwise, the requirement is considered as product-oriented. At this point, the product-oriented requirement is checked whether it targets the quality of the item in question. If the requirement is targeting the quality, then it is mapp Case ed Quality-Claim to a (CQ Claim) . Otherwise, it is mapped toClaim a . For instance An ł assessment shall judge whether the available evidence provides conidence in the cybersecurity of the itemž would be mapped into a conidence claim. In contrast, a requirement such as łThe validation of the item shall conirm that all the risks identiied during the phase X are handledž would be a case quality-claim for completeness. ACM Transactions on Cyber-Physical Systems CASCADE: An Asset-driven Approach to Build Security Assurance Cases for Automotive Systems • 15 Generic sub-case C:G1 C:G2 The company has a The company has a RQ-05-01 working security security aware culture policy CQ:G1.1 S:G1 All elements to enforce enable and ensure the Argue by security governance elements cybersecurity policy are addressed C:G1.1 C:G1.2 security security resources CQE:G1.1 responsibilities are are provided assigned All the elements mentioned in ISO E:G2.2 21434 have been E:G2.1 addressed E:G1.1 Basic security Mandatory security training ID: xy is a course ID:xx was part of new HR report no. 123 given to every employment relevant position procedure Fig. 6. Generic sub-case block of the headlamp use case - The file shaped box in the top-right corner indicates the requirement in ISO/SAE-21434 which drives the argument • Work Product: Work products form the evidence part of the resulting SAC. The work product can be either a (i) document which sets a scope to the cybersecurity work, which in this case is consider Conteextd as or (ii) document which includes sources for, e.g., cybersecurity monitoring, which in this case is considered as an Evidence. The mapping of the ISO/SAE-21434 requirements into diferent blocks of CASCADE is rather a straightforward task. The used rules are the following: • requirements about security goals and asset identiication fall into the white-hat block, • requirements about risk assessment, e.g., identiication and analysis of attack paths, attack feasibility, or impact rating, would fall into the black-hat block. Similarly, requirements about vulnerability analysis also fall into the black-hat block, and • requirements about risk treatment fall into the resolver block. Table 1 shows the requirements and work products in ISO/SAE-21434 which drive the arguments in each of CASCADE block and level. More detailed results of the conducted mapping between CASCADE and ISO/SAE-21434 items are reported in Appendix A. The irst two columns in the table of the Appendix A refer to item ID and type from the ISO/SAE- 21434 standard. The third column shows the corresponding SAC element, which is then speciied for CASCADE in column 4. Columns 5 and 6 include the corresponding block and level for the item in CASCADE’s structure. Finally, the last column shows the work products which support the elements that emerge from the corresponding requirement items, as per the speciication of ISO/SAE-21434. 7 VALIDATION In order to evaluate our approach, we reached out to a security expert from the cybersecurity team at Volvo Trucks, which is a leading OEM that manufactures trucks in Sweden. We conducted several sessions during the development of CASCADE where we discussed the approach, its limitations, and possible enhancements. When ACM Transactions on Cyber-Physical Systems 16 • Mazem Mohamad et al. Item of Start Context ISO/SAE 21434 Work product Sets a scope Yes Type of item for the item? No Evidence Requirement Includes an No implication? End Specific to a Claim within the No product? generic sub-case Yes True Yes Implication Contributes to CQ Claim Yes Value quality? False Claim No Assumption Fig. 7. The workflow of mapping ISO/SAE-21434 items to elements of CASCADE (in grey) the approach was fully developed, we conducted a inal evaluation session with the expert. We irst discussed the way of working of the company when it comes to security activities and security assurance. We used the headlamp example from ISO/SAE-21434 as a context for this discussion. We then presented our approach and the example case for the headlamp item. The expert evaluated the approach by discussing how the overall structure of an SAC should look from the company’s perspective in order to satisfy the requirement for security cases in ISO/SAE-21434 and mapping the diferent elements of the example case to the internal way of working. The expert also provided insights on how to further enhance the approach. Figure 8 shows the diferent security activities at the company along with the corresponding CASCADE block. A link between an activity and a block indicates that the outcomes of the activity are used to create the SAC elements in the corresponding block. Software products at Volvo Trucks contain both on-board and of-board parts. The of-board parts establish the communication between the vehicles and the back-end systems. For example, the diagnostics services receive data from the vehicle’s ECUs and store and use it in a back-end system. The on-board parts are software components installed in the ECUs of the vehicle, e.g., the engine control and the head-up display unit. These parts are divided into items to facilitate the security-related analysis. The items of the of-board systems can be seen as individual services which communicate with the vehicles, whereas the on-board items are end-user functionalities, e.g., external lighting and automated parking assistance. In order to argue about the security of a complete product, ACM Transactions on Cyber-Physical Systems CASCADE: An Asset-driven Approach to Build Security Assurance Cases for Automotive Systems • 17 Table 1. Requirements and work products from ISO/SAE 21434 which are relevant to the arguments in each CASCADE block Colons indicate ranges of requirements and work products CASCADE Block CASCADE Level Requirements and Work products Top Claim RQ-11-01, RQ-15-05, RQ-15-06 Generic sub-case RQ-05-01:RQ-05-15, RQ-06-01, RQ-06-04, RQ-06-23, RQ-06-24, RQ-07-01, RQ-08-01, RQ-08-04:RQ-08-07, RQ-09-01:RQ-09-04, RQ-10-19:RQ-10-21, RQ-13-06, RQ-15-01:RQ-15-03, WP-05-01:WP-05-05, WP-07-01, WP-10-07, WP-10-08, WP-13-03, WP-15-01 White hat Asset ID RQ-06-02, RQ-07-03, RQ-08-02 Security Goals RQ-06-03:RQ-06-17, RQ-06-19, RQ-06-20, RQ-06-22, RQ-06-25:RQ-06-27, RQ-07-02, RQ-07-04, RQ-09-05, RQ-09-07, RQ-09-09, RQ-11-01, RQ-11-02, RQ-14-01 Black hat Threat Scenarios RQ-08-03, RQ-08-08, RQ-11-03, RQ-13-03, WP-13-02 Attack Paths RQ-08-09, RQ-08-10 Resolver Risk Assessment RQ-07-05:RQ-07-07, RQ-08-11, RQ-08-12, RQ-09-06, RQ-09-08, RQ-10-09:RQ-10-11, RQ-10-13, RQ-10-16:RQ-10-18, RQ-11-04, Security Requirements RQ-06-29, RQ-07-08, RQ-09-10:RQ-09-12, RQ-10-01:RQ-10-08, RQ-10-12, RQ-10-14, RQ-10-15, RQ-12-01, RQ-13-01:RQ-13-05, RQ-15-04, RQ-15-07 Product Primary assets' TARA analysis Definition identification Security activities Security Testing and at Volvo Trucks Requirements verification Attack paths Item definition Security goals identification Align with CASCADE blocks Top Claim White-hat Black-hat Resolver Evidence Fig. 8. Mapping of the company’s security activities to CASCADE blocks both of-board and on-board items have to be considered. Hence, if the company wants to adopt CASCADE to create an SAC for a complete product, then the top claim block would contain claims for the individual items of that product. The Generic sub-case block of CASCADE helps to remove the redundancy of arguments and evidence applicable to diferent items. The assets of a product are identiied by considering damage scenarios on the items. In general, these assets can be generalized into the following categories: • Vehicle’s functionality (the attackers want to use the vehicle or tamper with the vehicle’s functionality for their own purpose or impede the rightful user from utilizing the vehicle functionality); • Information (the attackers want to gain access to sensitive information); and • Brand (the attackers want to discredit the brand and/or credit themselves). ACM Transactions on Cyber-Physical Systems 18 • Mazem Mohamad et al. The identiied assets are further categorized into primary and secondary assets in accordance with the deinitions in ISO-27005 18].[Considering the headlamp example case, two possible damage scenarios would be łLosing the headlamp will drastically reduce the driver’s sight and the vehicle’s visibility, which may result in a severe accidentž and Applying ł the headlamp at incorrect times could dazzle other vehicles, which may increase the risk of an accidentž. These lead to considering the headlamp functionality as a primary asset. Then, relevant security attributes for the primary asset are identiied and security goals are derived: • The integrity of the headlamp control functionality shall be preserved. • The availability of the headlamp control functionality shall be preserved. The identiication of assets and security goals corresponds to the white-hat block of CASCADE, as shown in Figure 8. These goals only take relevant security properties into consideration, i.e., integrity and availability. Hence, other properties such as conidentiality and authenticity are not considered. During the concept design phase, a Threat Assessment and Remediation Analysis (TARA) is performed on the item’s primary assets using STRIDE, which will result in cybersecurity requirements on certain components which are considered as supporting assets. These requirements are converted to claims in the black-hat block of CASCADE, as shown in Figure 8. After that, attack path analyses are performed bottom-up using an attack library, including but not limited to: • Intended over-the-air connection (e.g., 2,5G, 3G, 4G or 5G, Wi-Fi, WPAN, Bluetooth, IrDA, Wireless USB, and UBW); • Intended physical connection points (e.g., OBD, USB, and CD-Rom); • Unintended over-the-air disturbances (e.g., Radar, Laser, electro-magnetic, microwaves, infra-waves, ultra- sound, and infra-sound); • Unintended physical connection points (e.g., ECU, network, sensors, and actuators). These attack paths are also expressed as claims in the Black-hat block. Then the component design will be started considering all requirements, including cybersecurity. The components and systems are described in łproduct descriptionsž. These are veriied against the requirements, including cybersecurity. The cybersecurity requirements in the product description correspond to the requirements of the Resolver block in CASCADE. The components and systems are then tested against the product descriptions, and the test results are considered as evidence in CASCADE. Other SAC requirements also emerged from the discussion with the security expert. For instance, they emphasised the need to validate that production, operation, service and decommissioning are all adequately handled. We believe that this would be covered by QA claims in the resolver block. Another requirement is that the product along with the SAC is maintained throughout the life-cycle. This is not covered by CASCADE, and we consider it to be an important complementary aspect for future work. In particular, we will be looking into methods to ensure traceability between the elements of SACs and the corresponding development artefacts. This traceability allows impact analysis for maintaining SACs. Lastly, the expert stressed that it is important to argue that the performed product work is adequate with respect to cybersecurity policies and practices adopted by the company. We believe that to cover this, both product related arguments should be in place, as well as claims about the adequacy of the applied security policy, which is covered by the generic sub-case block of CASCADE. To get a deeper insight of how applicable CASCADE would be in an industrial context and what the strengths and weaknesses of it are, we extended our evaluation and included another large OEM in Sweden, Volvo cars. We did an open discussion session with a security expert at the company where we presented CASCADE and the example case. Here, we present the main discussion points and the expert’s input: • The work of work products is done in an iterative manner at Volvo Cars. In the design phase, for instance, there sometimes could be uncertainties, which would be cleared in the next phases, hence there is a need to go back and rework on work packages. This might also be the case within a phase in diferent development iterations. The interviewee stated that CASCADE allows the creationon ofthe SArun C , referring to the ACM Transactions on Cyber-Physical Systems CASCADE: An Asset-driven Approach to Build Security Assurance Cases for Automotive Systems • 19 structure of CASCADE being aligned with the security activities and the iterative way of working applied in the company. Hence, CASCADE does not require complete artifacts and work products to be in place to start building the case, but can rather be built and compiled progressively during the product development phases, e.g., concept, design, and implementation. During these phases the SAC provides an overview of the security of the ongoing work, which supports: – Early identiication of potential issues and decrease the cost of ixing these issues – Simplifying the change impact analysis to make decisions regarding the integration of new development in terms of: (i)what needs to be addressed in regards to updated artefacts/work products, e.g., TARA, concept, V&V needs; (ii)what needs to be updated in the assurance case;(iii) the needed reviews and re-assessments needed to account for the change. – Gaining a faster understanding of the security impact and posture of a change to support decisions on deployment • Quality of security artefacts, is done at the company as reviews. There are reviews to make sure that the analysis is complete and the scope is covered (boundaries). The expert agrees that the case should relect that, which is done through the case quality assurance part of CASCADE. SACs have the potential to be used in multiple usage scenarios 24]. Hence [ , there are many stakeholders to SACs. These stakeholders require diferent abstraction levels of the SAC. For some stakeholders the detailed case quality arguments and evidence might not be required, but rather an abstracted view where the quality of the case is indicated and visualised using a metric. The complete case quality arguments must, however, be in place to measure the completeness of the SAC’s argument. Distinguishing the case quality-claims in CASCADE is good as it enables the possibility for the abstraction. However, there should be a property on the case level that directly indicates the quality of the case rather than having to go through all the corresponding elements. This has been implemented in some of the tools used for creating and managing assurance cases, 25], e.g., [ and is considered a state of practice. • There is no clear distinction between what is speciic to CASCADE, and what is an one to one mapping to the structure of ISO/SAE-21434. Moreover, it is unclear whether the approach would suiciently cover the requirements of the standard. A more in-depth analysis between the standard and CASCADE is needed according to the expert. Areas of Improvement The mapping of ISO/SAE-21434 has enabled us to pinpoint areas of improvement as well as strong points in CASCADE. In this section, we discuss our main indings of the evaluation cycle. • Re-usability: the separation of item-related and generic arguments in CASCADE enabled us to consider the re-usability of the claims already while creating them, i.e., in an early stage. The standard does not explicitly distinguish b(i) etwpreoen duct-related requirements and work products; and (ii)process-related requirements and work products. However, by deriving claims from the requirement and determining the CASCADE corresponding block, this could easily be achieved. Re-using claims is very important to reduce the overhead of creating SAC for diferent products. Re-use of process-related claims is, however, not the only type of re-usability possible in creating SAC. The other type is the re-use of product-related claims that are applicable to multiple items. For example, if there are multiple items in a vehicle that are connected to the outside world through a gateway, then a security argument about that gateway would be applicable to all the connected items and should be re-used in each of their corresponding security arguments. This type of re-usability is only possible to achieve when the architecture of the system is known and the relations and dependencies of diferent items are known. ACM Transactions on Cyber-Physical Systems 20 • Mazem Mohamad et al. To improve CASCADE, we should restructure the generic sub-case block in order to be able to cover both types of re-usability. Additionally, we need to establish the techniques and mechanisms needed to shift parts of arguments between diferent SAC. • Uncertainty: Throughout the mapping activity, we encountered several occasions where there were uncer- tainties. This is the case when a requirement includes a condition in it, e.g., in a form of an if statement. As discussed in Section 6, we consider this type of requirement to either lead to an assumption or to a claim (we have mapped them to assumptions in Appendix A). This leads us to the need for capturing these uncertainties in an SAC at an early stage of its creation. As SAC should follow the development life-cycle, it is important to make sure to tag the parts of a given SAC which need further development. Uncertainties certainly lead to incomplete arguments in the early stages of SAC creation. To resolve this issue, we could introduce a mechanism to tag a scope of a given argument as incomplete, as well as providing alternative solutions based on a certain condition. In our case, that would be the condition in the requirement. This would be similar to how behavioral views (sequence diagrams in particular) in UML handles alternatives. This change would afect the process of creating a SAC. However, the end result would be the same once the development of the item in question is inalized and the SAC is fully created. It might, however, also be interesting to keep a history log of the choices that have been made in the process. This log can be relected in the case to show arguments that were subject to decision points during the development process. • Adequacy: the items in the standard are not enough to cover the case quality claims and evidence. In CASCADE we have a rule that every level of argumentation (when a claim is broken down into sub-claims) must be examined for completeness, and every piece of evidence must be examined for conidence. However, the items of the standard do not suice to cover these quality needs. Additionally, the creation of a SAC requires introducing contexts and assumptions which are not necessarily captured by the standard. Moreover, the items of the standard might not even be enough to claim the required level of security according to an organization’s standard. Hence, conforming with the standard and relecting the work in a SAC does not mean that the SAC is complete. There is a need for a deinition of done for the SAC work, which would have to be considered as a context for the top claim. As a summary of the validation of this work, we showed that CASCADE is well aligned with the internal way of working at automotive OEM’s which makes it suitable for the creation of SAC on the run and during the development life-cycle. We also found that the generic sub-case and quality blocks help to serve the abstraction and completeness requirements of the evaluating companies. We have identiied points of improvement in the approach, especially when we attempted to map the requirements and work products of ISO/SAE-21434 to elements and structure of CASCADE. These include the need for a concrete mechanism for reusing arguments, handling the uncertainty in the requirements, and the need to have a deinition of done for the outcome. These will be the basis for future work. 8 CONCLUSION AND FUTURE WORK In this work, we presented CASCADE, an asset-driven approach for the creation of security assurance cases with built-in quality assurance. CASCADE is geared towards automotive companies that have the need to conform with the upcoming ISO/SAE-21434 security standard. We illustrated CASCADE using an example case from ISO/SAE-21434 and validated it at two industrial OEMs. We also mapped the requirements and work products of the standard to elements of the approach and evaluated ACM Transactions on Cyber-Physical Systems CASCADE: An Asset-driven Approach to Build Security Assurance Cases for Automotive Systems • 21 its capability to include these items. Additionally, we synthesized the knowledge gained during the mapping activity and created a guideline for practitioners who want to conduct a similar activity. As a future work, we plan to further enhance the approach to take into consideration the maintenance of SAC. We will also work on deining the mechanisms and techniques required for the re-usability and the quality assurance of the outcome of CASCADE. Additionally, we plan on incorporating additional requirements sources to better cover the needs of the automotive industry. ACKNOWLEDGEMENT This work is partially supported by the CASUS research project funded by VINNOVA, a Swedish funding agency. We sincerely thank four anonymous reviewers whose comments and suggestions helped improve and clarify this manuscript. REFERENCES [1] [n. d.]. Claims, Arguments and Evidence (CAE). https://www.adelard.com/asce/choosing-asce/cae.html [2] [n. d.]. Common Attack Pattern Enumeration and Classiication (CAPEC). http://capec.mitre.org/. Accessed: 2022-02-07. [3] [n. d.]. The Common Component Modeling Example - CoCoME. https://www.cocome.org/downloads/documentation/cocome.pdf. Accessed: 2020-04-09. [4] A. Finnegan and F. McCafery. 2014. Towards an International Security Case Framework for Networked Medical Devices. International In Conference on Computer Safety, Reliability, and Security . Springer, 197ś209. [5] Rob Alexander, Richard Hawkins, and Tim Kelly. 2011. Security assurance cases: motivation and the state of High theIntegrity art. Systems Engineering Department of Computer Science University of York Deramore Lane York YO10 5GH (2011). [6] T Scott Ankrum and Alfred H Kromholz. 2005. Structured assurance cases: Three common standards. In Ninth IEEE International Symposium on High-Assurance Systems Engineering (HASE’05) . IEEE, 99ś108. [7] T. S. Ankrum and A. H. Kromholz. 2005. Structured assurance cases: three common standards. InNinth IEEE International Symposium on High-Assurance Systems Engineering (HASE’05) . 99ś108. https://doi.org/10.1109/HASE.2005.20 [8] John Birch, Roger Rivett, Ibrahim Habli, Ben Bradshaw, John Botham, Dave Higham, Helen Monkhouse, and Robert Palin. 2014. A Layered Model for Structuring Automotive Safety Arguments (Short Paper2014 ). In Tenth European Dependable Computing Conference . 178ś181. https://doi.org/10.1109/EDCC.2014.24 [9] Lukasz Cyra and Janusz Gorski. 2007. Supporting compliance with security standards by trust case templates. 2nd International In Conference on Dependability of Computer Systems (DepCoS-RELCOMEX’07) . IEEE, 91ś98. [10] Anita Finnegan and Fergal McCafery. 2014. A security argument pattern for medical device assurance cases. 2014 IEEE In International Symposium on Software Reliability Engineering Workshops . IEEE, 220ś225. [11] John Goodenough, Howard Lipson, and Chuck Weinstock. 2007. Arguing Security - Creating Security Assurance Cases. (2007). [12] GSN Community Standard Working Group. 2011. GSN community standar Available d. at www.goalstructuringnotation.info/ (2011). [13] C. Haley, R. Laney, J. Mofett, and B. Nuseibeh. 2008. Security Requirements Engineering: A Framework for Representation and Analysis. IEEE Transactions on Software Engineering 34, 1 (2008), 133ś153. https://doi.org/10.1109/TSE.2007.70754 [14] Richard Hawkins, Tim Kelly, John Knight, and Patrick Graydon. 2011. A new approach to creating clear safety arguments. AdvancesIn in systems safety . Springer, 3ś23. [15] Alan R. Hevner, Salvatore T. March, Jinsoo Park, and Sudha Ram. 2004. Design Science in Information Systems Resear MIS Qch. . 28, 1 (March 2004), 75ś105. [16] Michael Howard and Steve Lipner. 2006. The security development lifecycle . Vol. 8. Microsoft Press Redmond. [17] International Organization for Standardization. 1999. Information technology Ð Security techniques Ð Evaluation criteria for IT security Ð Part 1: Introduction and general model. [18] International Organization for Standardization. 2018. ISO 26262 Information technology Ð Security techniques Ð Information security risk management. [19] International Organization for Standardization. 2018. ISO 26262 Road vehicles ś Functional safety, 2nd Edition. [20] International Organization for Standardization and Society of Automotive Engineers. 2018. ISO / SAE 21434 Road vehicles ś Cybersecurity Engineering, CD Draft. [21] J. Knight. 2015. The Importance of Security Cases: Proof Is Good, But Not Enough. IEEE Security Privacy13, 4 (July 2015), 73ś75. https://doi.org/10.1109/MSP.2015.68 [22] Nikola Luburić, Goran Sladić, Branko Milosavljević, and Aleksandar Kaplar. 2018. Demonstrating Enterprise System Security Using an Asset-Centric Security Assurance Framework. 8th In International Conference on Information Society and Technology . 16. ACM Transactions on Cyber-Physical Systems 22 • Mazem Mohamad et al. [23] Mazen Mohamad, Örjan Askerdal, Rodi Jolak, Jan-Philipp Steghöfer, and Riccardo Scandariato. 2021. Asset-driven Security Assurance Cases with Built-in Quality Assurance ICSEW’21: . In Proceedings of the IEEE/ACM 43rd International Conference on Software Engineering Workshops June 2021. https://www.rodijolak.com/asset-driven/pre-print.pdf [24] Mazen Mohamad, Alexander Åström, Örjan Askerdal, Jörgen Borg, and Riccardo Scandariato. 2020. Security Assurance Cases for Road Vehicles: An Industry Perspective.Pr Inoceedings of the 15th International Conference on Availability, Reliability and Se(Virtual curity Event, Ireland)(ARES ’20). Association for Computing Machinery, New York, NY, USA, Article 29, 6 pages. https://doi.org/10.1145/ 3407023.3407033 [25] Gdansk University of Technology. 2010ś2019. NOR-STA. https://www.nor-sta.eu/en/. [26] Thomas Rosenstatter, Kim Strandberg, Rodi Jolak, Riccardo Scandariato, and Tomas Olovsson. 2020. REMIND: A Framework for the Resilient Design of Automotive Systems. 2020In IEEE Secure Development (SecDev). IEEE, 81ś95. [27] John Spriggs. 2012.GSN-The Goal Structuring Notation: A Structured Approach to Presenting Arguments . Springer Science & Business Media. [28] V. Vaishnavi and B. Kuechler. 2004. Design research in information A systems. ssociation for Information Systems (2004). [29] B. Xu, M. Lu, and D. Zhang. 2017. A Layered Argument Strategy for Software Security Case Development.2017 In IEEE International Symposium on Software Reliability Engineering Workshops (ISSREW) . 331ś338. https://doi.org/10.1109/ISSREW.2017.52 ACM Transactions on Cyber-Physical Systems CASCADE: An Asset-driven Approach to Build Security Assurance Cases for Automotive Systems • 23 Appendix A ISO/SAE-21434–CASCADE MAPPING Correspond- Correspond- Corresponding Corresponding Support- Item ID Item type ing SAC ing CASCADE CASCADE block CASCADE level ing WP element element RQ-05-01 Requirement Claim Claim Generic Sub-case WP-05-01 RQ-05-02 Requirement Claim Claim Generic Sub-case WP-05-01 RQ-05-03 Requirement Claim Claim Generic Sub-case WP-05-01 RQ-05-04 Requirement Claim Claim Generic Sub-case WP-05-01 RQ-05-05 Requirement Claim Claim Generic Sub-case WP-05-01 RQ-05-06 Requirement Claim Claim Generic Sub-case WP-05-01 RQ-05-07 Requirement Claim Claim Generic Sub-case WP-05-02 RQ-05-08 Requirement Claim Claim Generic Sub-case WP-05-02 RQ-05-09 Requirement Claim Claim Generic Sub-case WP-05-02 RQ-05-10 Requirement Claim Claim Generic Sub-case WP-05-01 RQ-05-11 Requirement Claim Claim Generic Sub-case WP-05-03 RQ-05-12 Requirement Claim Claim Generic Sub-case WP-05-01 RQ-05-13 Requirement Claim Claim Generic Sub-case WP-05-04 RQ-05-14 Requirement Claim Claim Generic Sub-case WP-05-04 RQ-05-15 Requirement Claim Claim Generic Sub-case WP-05-05 Work prod- WP-05-01 Evidence Evidence Generic Sub-case uct Work prod- WP-05-02 Evidence Evidence Generic Sub-case uct Work prod- WP-05-03 Evidence Evidence Generic Sub-case uct Work prod- WP-05-04 Evidence Evidence Generic Sub-case uct Work prod- WP-05-05 Evidence Evidence Generic Sub-case uct RQ-06-01 Requirement Claim CQ claim Generic Sub-case WP-06-01 RQ-06-02 Requirement Claim CQ claim White hat Asset ID WP-06-01 RQ-06-03 Requirement Claim CQ claim White hat Security goals WP-06-01 RQ-06-04 Requirement Claim CQ claim Generic Sub-case Security goals WP-06-01 RQ-06-05 Requirement Claim Claim White hat Security goals WP-06-01 RQ-06-06 Requirement Claim CQ claim White hat Security goals WP-06-01 RQ-06-07 Requirement Claim CQ claim White hat Security goals WP-06-01 RQ-06-08 Requirement Claim CQ claim White hat Security goals WP-06-01 RQ-06-09 Requirement Claim CQ claim White hat Security goals WP-06-01 RQ-06-10 Requirement Claim CQ claim White hat Security goals WP-06-01 RQ-06-11 Requirement Context Context White hat Security goals WP-06-01 ISO/SAE-21434śCASCADE Mapping ś Continued on next page ACM Transactions on Cyber-Physical Systems 24 • Mazem Mohamad et al. ISO/SAE-21434śCASCADE Mapping ś Continued from previous page Correspond- Correspond- Corresponding Corresponding Support- Item ID Item type ing SAC ing CASCADE CASCADE block CASCADE level ing WP element element RQ-06-12 Requirement Context Context White hat Security goals WP-06-01 RQ-06-13 Requirement Context Context White hat Security goals WP-06-01 RQ-06-14 Requirement Claim CQ claim White hat Security goals WP-06-01 RQ-06-15 Requirement Claim CQ claim White hat Security goals WP-06-01 RQ-06-16 Requirement Claim Claim White hat Security goals WP-06-01 RQ-06-17 Requirement Claim CQ claim White hat Security goals WP-06-01 RQ-06-18 Requirement WP-06-02 RQ-06-19 Requirement Claim CQ claim White hat Security goals WP-06-03 RQ-06-20 Requirement Claim CQ claim White hat Security goals WP-06-03 RQ-06-21 Requirement Claim CQ claim Evidence WP-06-03 RQ-06-22 Requirement Context Context White hat Security goals WP-06-03 RQ-06-23 Requirement Claim Claim Generic sub-case WP-06-03 RQ-06-24 Requirement Claim Claim Generic sub-case WP-06-03 RQ-06-25 Requirement Context Context White hat Security goals WP-06-03 RQ-06-26 Requirement Claim CQ claim White hat Security goals WP-06-03 RQ-06-27 Requirement Claim Claim White hat Security goals WP-06-03 RQ-06-28 Requirement Assumption Assumption Top claim WP-06-04 Security require- RQ-06-29 Requirement Claim CQ claim Resolver WP-06-04 ments Work Prod- WP-06-01 Evidence Evidence uct Work Prod- WP-06-02 uct Work Prod- WP-06-03 Evidence Evidence uct Work Prod- WP-06-04 Evidence Evidence uct WP-07-01 RQ-07-01 Requirement Claim Claim Generic sub-case WP-07-05 RQ-07-02 Requirement Claim CQ claim White hat Security goals WP-07-02 Work Prod- WP-07-01 Context Context Generic sub-case uct Work Prod- WP-07-02 Evidence Evidence uct RQ-07-03 Requirement Claim Claim White hat Asset ID ISO/SAE-21434śCASCADE Mapping ś Continued on next page RQ-06-18 is the requirement to create the cybersecurity case WP-06-02 is the work-product referring to the cybersecurity case ACM Transactions on Cyber-Physical Systems CASCADE: An Asset-driven Approach to Build Security Assurance Cases for Automotive Systems • 25 ISO/SAE-21434śCASCADE Mapping ś Continued from previous page Correspond- Correspond- Corresponding Corresponding Support- Item ID Item type ing SAC ing CASCADE CASCADE block CASCADE level ing WP element element Work Prod- WP-07-03 Evidence Evidence uct RQ-07-04 Requirement Claim Claim White hat Security goals Work Prod- WP-07-04 Evidence Evidence uct RQ-07-05 Requirement Claim CQ claim Resolver Risk assessment RQ-07-06 Requirement Claim CQ claim Resolver Risk assessment RQ-07-07 Requirement Claim Claim Resolver Risk assessment Security require- RQ-07-08 Requirement Assumption Assumption Resolver ments Work Prod- WP-07-05 Evidence Evidence uct RQ-08-01 Requirement Claim Claim Generic sub-case WP-08-01 RQ-08-02 Requirement Assumption Assupmtion White hat Asset ID WP-08-02 Work Prod- WP-08-01 Evidence Evidence uct Work Prod- WP-08-02 Evidence Evidence uct RQ-08-03 Requirement Claim Claim Black hat Threat scenarios WP-08-03 Work Prod- WP-08-03 Evidence Evidence uct RQ-08-04 Requirement Claim CQ claim Generic sub-case WP-08-04 RQ-08-05 Requirement Assumption Assumption Generic sub-case WP-08-04 RQ-08-06 Requirement Claim CQ claim Generic sub-case WP-08-04 RQ-08-07 Requirement Claim CQ claim Generic sub-case WP-08-04 Work Prod- WP-08-04 Evidence Evidence uct RQ-08-08 Requirement Claim Claim Black hat Threat scenarios WP-08-05 RQ-08-09 Requirement Claim Claim Black hat Attack paths Work Prod- WP-08-05 Evidence Evidence uct RQ-08-10 Requirement Claim CQ claim Black hat Attack paths WP-08-06 Work Prod- WP-08-06 Evidence Evidence uct RQ-08-11 Requirement Claim CQ claim Resolver Risk assessment WP-08-07 Work Prod- WP-08-07 Evidence Evidence uct RQ-08-12 Requirement Claim CQ claim Resolver Risk assessment WP-08-08 ISO/SAE-21434śCASCADE Mapping ś Continued on next page ACM Transactions on Cyber-Physical Systems 26 • Mazem Mohamad et al. ISO/SAE-21434śCASCADE Mapping ś Continued from previous page Correspond- Correspond- Corresponding Corresponding Support- Item ID Item type ing SAC ing CASCADE CASCADE block CASCADE level ing WP element element Work Prod- WP-08-08 Evidence Evidence uct RQ-09-01 Requirement Claim Claim Generic sub-case WP-09-01 RQ-09-02 Requirement Claim Claim Generic sub-case WP-09-01 RQ-09-03 Requirement Claim Claim Generic sub-case WP-09-01 RQ-09-04 Requirement Claim Claim Generic sub-case WP-09-01 Work Prod- WP-09-01 Evidence Evidence uct RQ-09-05 Requirement Claim CQ claim White hat Security goals WP-09-02 RQ-09-06 Requirement Claim CQ claim Resolver Risk assessment WP-09-03 RQ-09-07 Requirement Assumption Assumption White hat Security goals WP-09-04 RQ-09-08 Requirement Context Context Resolver Risk assessment WP-09-05 RQ-09-09 Requirement Claim CQ claim White hat Security goals WP-09-06 Work Prod- WP-09-02 Evidence Evidence uct Work Prod- WP-09-03 Evidence Evidence uct Work Prod- WP-09-04 Evidence Evidence uct Work Prod- WP-09-05 Evidence Evidence uct Work Prod- WP-09-06 Evidence Evidence uct Security require- RQ-09-10 Requirement Claim Claim Resolver WP-09-07 ments Security require- RQ-09-11 Requirement Context Context Resolver WP-09-07 ments Security require- RQ-09-12 Requirement Claim CQ claim Resolver WP-09-08 ments Work Prod- WP-09-07 Evidence Evidence uct Work Prod- WP-09-08 Evidence Evidence uct Security require- RQ-10-01 Requirement Claim CQ claim Resolver WP-10-01 ments Security require- RQ-10-02 Requirement Claim CQ claim Resolver WP-10-01 ments ISO/SAE-21434śCASCADE Mapping ś Continued on next page ACM Transactions on Cyber-Physical Systems CASCADE: An Asset-driven Approach to Build Security Assurance Cases for Automotive Systems • 27 ISO/SAE-21434śCASCADE Mapping ś Continued from previous page Correspond- Correspond- Corresponding Corresponding Support- Item ID Item type ing SAC ing CASCADE CASCADE block CASCADE level ing WP element element Security require- RQ-10-03 Requirement Claim CQ claim Resolver WP-10-01 ments Security require- RQ-10-04 Requirement Claim Claim Resolver WP-10-01 ments Security require- RQ-10-05 Requirement Claim Claim Resolver WP-10-02 ments Security require- RQ-10-06 Requirement Assumption Assumption Resolver WP-10-02 ments Security require- RQ-10-07 Requirement Claim CQ claim Resolver WP-10-03 ments Security require- RQ-10-08 Requirement Claim CQ claim Resolver WP-10-03 ments RQ-10-09 Requirement Claim Claim Resolver Risk assessment WP-10-04 RQ-10-10 Requirement Claim CQ claim Resolver Risk assessment WP-10-04 RQ-10-11 Requirement Claim CQ claim Resolver Risk assessment WP-10-04 Security require- RQ-10-12 Requirement Claim CQ claim Resolver WP-10-06 ments RQ-10-13 Requirement Claim Claim Resolver Risk assessment WP-10-05 Security require- RQ-10-14 Requirement Assumption Assumption Resolver WP-10-06 ments Security require- RQ-10-15 Requirement Claim Claim Resolver WP-10-06 ments RQ-10-16 Requirement Claim CQ claim Resolver Risk assessment WP-10-06 RQ-10-17 Requirement Assumption Assumption Resolver Risk assessment WP-10-06 RQ-10-18 Requirement Assumption Assumption Resolver Risk assessment WP-10-06 RQ-10-19 Requirement Claim Claim Generic sub-case WP-10-07 RQ-10-20 Requirement Claim CQ claim Generic sub-case WP-10-07 RQ-10-21 Requirement Claim CQ claim Generic sub-case Work Prod- WP-10-01 Evidence Evidence uct Work Prod- WP-10-02 Evidence Evidence uct Work Prod- WP-10-03 Evidence Evidence uct Work Prod- WP-10-04 Evidence Evidence uct Work Prod- WP-10-05 Evidence Evidence uct ISO/SAE-21434śCASCADE Mapping ś Continued on next page ACM Transactions on Cyber-Physical Systems 28 • Mazem Mohamad et al. ISO/SAE-21434śCASCADE Mapping ś Continued from previous page Correspond- Correspond- Corresponding Corresponding Support- Item ID Item type ing SAC ing CASCADE CASCADE block CASCADE level ing WP element element Work Prod- WP-10-06 Evidence Evidence uct Work Prod- WP-10-07 Evidence Evidence Generic sub-case uct Work Prod- WP-10-08 Evidence Evidence Generic sub-case uct RQ-11-01 Requirement Claim CQ-Claim White hat Security goals WP-11-02 RQ-11-02 Requirement Context Context White hat Security goals WP-11-01 RQ-11-03 Requirement Claim Claim Black hat Attack paths WP-11-02 RQ-11-04 Requirement Claim CQ-Claim Resolver Risk assessment WP-11-02 Work Prod- WP-11-01 Context Context Top claim uct Work Prod- WP-11-02 Evidence Evidence uct Security require- RQ-12-01 Requirement Claim CQ-Claim Resolver WP-12-01 ments Work Prod- WP-12-01 Evidence Evidence uct Security require- RQ-13-01 Requirement Claim CQ-Claim Resolver WP-13-01 ments Security require- RQ-13-02 Requirement Claim Claim Resolver ments RQ-13-03 Requirement Context Context Black hat Threat-scenarios WP-13-02 Work Prod- WP-13-01 Evidence Evidence uct Work Prod- WP-13-02 Context Context Black hat Threat-scenarios uct Security require- RQ-13-04 Requirement Claim CQ-Claim Resolver ments Security require- RQ-13-05 Requirement Claim CQ-Claim Resolver ments RQ-13-06 Requirement Claim Claim Generic sub-case WP-13-03 Work Prod- WP-13-03 Context Context Generic sub-case uct RQ-14-01 Requirement Claim CQ-Claim White hat Security goals RQ-15-01 Requirement Claim Claim Generic sub-case Recommen- RC-15-01 Evidence Evidence Generic sub-case dation ISO/SAE-21434śCASCADE Mapping ś Continued on next page ACM Transactions on Cyber-Physical Systems CASCADE: An Asset-driven Approach to Build Security Assurance Cases for Automotive Systems • 29 ISO/SAE-21434śCASCADE Mapping ś Continued from previous page Correspond- Correspond- Corresponding Corresponding Support- Item ID Item type ing SAC ing CASCADE CASCADE block CASCADE level ing WP element element RQ-15-02 Requirement Claim Claim Generic sub-case RQ-15-03 Requirement Claim Claim Generic sub-case WP-15-01 Security require- RQ-15-04 Requirement Assumption Assumption Resolver WP-15-01 ments RQ-15-05 Requirement Assumption Assumption Top Claim WP-15-01 RQ-15-06 Requirement Assumption Assumption Top Claim WP-15-01 Security require- RQ-15-07 Requirement Assumption Assumption Resolver WP-15-01 ments Work Prod- WP-15-01 Context Context Generic sub-case uct ACM Transactions on Cyber-Physical Systems 30 • Mazem Mohamad et al. B CASCADE CONCEPTS Definition of CASCADE core security concepts and correspondence to ISO/SAE 21434 terminology CASCADE Concept Deinition Corresponding ISO/SAE 21434 concept A structured body of arguments and evidence Security Assurance used to reason about the security of a certain Cybersecurity case Case item. Any piece of tangible or intangible artifact that has a value to an organization. Compro- Asset Asset mising an asset might lead to damage scenar- ios An attribute of an asset including the CIA Security Property Cybersecurity Property triad A requirement to preserve a security property Security Goal Cybersecurity Goal of a certain asset An action that would lead to a compromising Threat Scenario Threat Scenario a security goal A set of actions that might lead to the realiza- Attack Path Attack Path tion of a threat scenario A combination of probability and impact of Risk Risk an uncertainty to the security of an asset The Cybersecurity Goal in ISO/SAE 21434 associates the cybersecurity requirement with one or more threat scenario. In CASCADE we capture the same concept in two diferent levels (Security Goals, and Threat Scenarios) to form the argumentation part of the SAC. ACM Transactions on Cyber-Physical Systems

Journal

ACM Transactions on Cyber-Physical SystemsAssociation for Computing Machinery

Published: Feb 20, 2023

Keywords: Security

References