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

Learn More →

Data-Flow-Based Extension of the System-Theoretic Process Analysis for Security (STPA-Sec)

Data-Flow-Based Extension of the System-Theoretic Process Analysis for Security (STPA-Sec) Data-Flow-Based Extension of the System-Theoretic Process Analysis for Security (STPA-Sec) Jinghua Yu, Stefan Wagner, Member IEEE, and Feng Luo Abstract—Security analysis is an essential activity in secu- security engineering phase and helps to manage system risks rity engineering to identify potential system vulnerabilities and and make decisions. achieve security requirements in the early design phases. Due Traditional security analysis approaches, being designed for to the increasing complexity of modern systems, traditional former relatively simple systems, are not effective to ana- approaches, which only consider component failures and simple lyze increasingly complex systems. Today’s Cyber-Physical cause-and-effect linkages, lack the power to identify insecure incidents caused by complex interactions among physical systems, Systems (CPS) or Socio-Technical Systems (STS) consist of human and social entities. By contrast, a top-down System- not only physical components but also software and even Theoretic Process Analysis for Security (STPA-Sec) approach social elements, in which components in multi-disciplines views losses as resulting from interactions, focuses on controlling interact with each other deeply. For example, an autonomous system vulnerabilities instead of external threats and is applicable vehicle (as a CPS) consists of tens of thousands of physical for complex socio-technical systems. In this paper, we proposed an extension of STPA-Sec based on data flow structures to components as well as lines of codes. A vehicle Over-The-Air overcome STPA-Secs limitations and achieve security constraints (OTA) software update system (as an STS) refers to not only of information-critical systems systematically. We analyzed a the technical part but also social entities like data providers Bluetooth digital key system of a vehicle by using both the and regulations. However, most traditional approaches start proposed and the original approach to investigate the relationship with system decomposition and focus on component failures, and differences between both approaches as well as their appli- cability and highlights. To conclude, the proposed approach can which leads to overlooking impacts of interactions since com- identify more information-related problems with technical details ponents are analyzed individually. Traditional causality models and be used with other STPA-based approaches to co-design attribute accidents to an initial component failure cascading systems in multi-disciplines under the unified STPA process through a set of other components (like dominos) [2] and can framework. not address causes of losses with non-linear cause-and-effect Index Terms—Security Analysis, Complex Interaction, linkages. Information-critical System, Data Flow Structure, STPA-Sec To meet the requirements of modern systems, a relatively new approach for safety engineering called System-Theoretic I. I NTRODUCTION Process Analysis (STPA) was proposed [3] and the extension for security named STPA-Sec was presented later [4]. How- YSTEM security is an emergent property of the system, ever, we recognized some limitations of STPA-Sec when im- which represents a state or condition that is free from plementing it, especially for data-flow-based systems. There- asset loss and the resulting loss consequences. System security fore, this research aims to work out an extended approach engineering, as a special discipline of system engineering, co- based on the unified STPA process framework for complex ordinates and directs various engineering specialties to provide information-critical systems to overcome the identified limita- a fully integrated, system-level perspective of system security tions of STPA-Sec. and helps to ensure the application of appropriate security The rest of this paper is organized as follows. In section principles and methodologies during the system life cycle II, we introduce traditional approaches and the STPA series for asset protection [1]. Violating system security constraints with research gaps and our contributions. In section III, we causes unexpected incidents, like mission failure or leaking introduce the original STPA-based approaches and propose sensitive information, and finally leads to financial or even life the extension in detail. In section IV, we present the analysis losses. Therefore, security needs to be considered carefully process of a use case by using both original and extended in system design. Security analysis, referring to the activity approaches to demonstrate how to use them and make the of analyzing systems in security-related aspects to achieve comparison. Finally, we summary this paper in section V. security requirements in this research, is performed in the early J. Yu is with School of Automotive Studies, Tongji University, 201804 II. R ELATED WORK Shanghai China (e-mail: yujinghua@outlook.com). A. Traditional Security Analysis Approaches S. Wagner is with Institute of Software Technology, University of Stuttgart, 70569 Stuttgart, Germany (e-mail: stefan.wagner@iste.uni-stuttgart.de) The purpose of the security analysis in the early design stage F. Luo is with the School of Automotive Studies, Tongji University, 201804 Shanghai, China (e-mail: luo feng@tongji.edu.cn) is to achieve security requirements. The Threats Analysis and This research was supported by the China Scholarship Council and funds of Risk Assessment (TARA) is normally the main activity in the the German Federal Ministry of Education and Research under grant number security analysis to identify potential threats and assess threat 16KIS0995. This version has been submitted to IEEE System Journal on 22 May 2020. risks [5]. The SAE (Society of Automotive Engineers) J3061 - arXiv:2006.02930v1 [cs.CR] 4 Jun 2020 2 Cybersecurity Guidebook for Cyber-physical Vehicle systems is a more efficient way to achieve system safety and security, [5] provides a list of approaches, which contain complete because controlling a vulnerability may be effective to reduce process frameworks of TARA, like the EVITA approach [6] several threats. Besides, threats are dynamic. Newly emerged and TVRA [7]. Besides, techniques are proposed for only threats can not always be detected in time, but controlling threat identification or risk assessment and can be used in vulnerabilities can protect the system against even unknown the previously mentioned TARA frameworks, including Attack threats, just like defending a castle by reinforcing walls and not Tree Analysis (ATA) [8], STRIDE threat models [9], Threat caring who is the enemy. Another highlight is that the STPA- and Operability Analysis (THROP) [5], Threat Matrix [10] based approaches are applicable for socio-technical systems, and BDMP-based (Boolean logic Driven Markov Processes) which are systems that consider requirements spanning hard- Modelling [11] for threat identification, as well as Binary Risk ware, software, personal, and community aspects [21]. The Analysis (BRA) [12] and NIST SP 800-30 Guide [13] for analysis scope of the STPA series includes not only physical risk assessment. Other than methods originally invented for system components but also humans, natural or social envi- security, some approaches are evolved from the safety field ronment and their interactions, which makes the approaches by introducing security awareness into the process and support more suitable for todays complex systems. Furthermore, due the co-analysis of both safety and security. to the numbers of extensions of STPA in various disciplines, Table I summarizes both original and evolved approaches it is easier to perform co-design with similar STPA framework with brief introductions. They are all bottom-up approaches and the same system model. building upon physical or functional decomposition instead of C. STPA-Sec Applications and Gaps analyzing the system as a whole initially. They focus more on the tactic level and may overlook issues at the strategy The STPA-Sec approach or its extensions have been used level. The tactics are means to accomplish a specific action to identify system security constraints in various industries. and focused on physical threats, while the strategy is regarded Khan, Madnick and Moulton [22] demonstrated the imple- as the art of gaining continuing advantages and is focused mentation of STPA-Sec to identify security vulnerabilities on abstract outcomes [2]. The latter one is useful to broaden of a use case (Central Utilities Plant Gas Turbine) in in- the mind and includes more aspects like organizational and dustrial control systems. Carter [23] used STPA-Sec with a managerial ones in the analysis. previous information elicitation process to analyze a small reconnaissance unmanned aerial vehicles. Sidhu [24] applied B. System-Theoretic Process Analysis (STPA) Approach and an STPA-Sec extension with modified attack tree method to Extensions analyze cybersecurity of autonomous mining systems. Wei and To overcome the limitations of traditional approaches, STPA Madnick [25] analyzed a use case (Over-The-Air software was created as a hazard analysis approach based on the update) in the automotive industry by using both STPA- System-Theoretic Accident Model and Process (STAMP), Sec and CHASSIS and compared analysis outcomes, which which views losses as results from interactions among various showed that STPA-Sec can identify more hazards compared to system roles that lead to violations of safety constraints and CHASSIS, while CHASSIS is more suitable for information analyzes issues at the strategy level. STPA provides a powerful lifecycle analysis. way to deal with complexity by using traceable hierarchical Nevertheless, researchers also pointed out several limita- abstraction and refinement [2]. tions of STPA-Sec. Schmittner, Ma and Puschner [26] reported Other than safety engineering, STPA has also been extended that the original STPA-Sec lacks guidance for intended causal into other fields with the same system-theoretic thought. scenarios, excludes considerations of the data exchange which Young and Leveson [4] firstly presented STPA for Security is not directly connected to the process control and cannot (STPA-Sec), which shares similar steps with STPA and fo- cover more information-security centric properties such as cuses on controlling system vulnerabilities instead of avoiding confidentiality. Torkildson, Li and Johnsen [27] also found that threats. To perform co-analysis of safety and security under some essential security issues can be overlooked and recom- the STPA framework better, Friedberg et al. [19] proposed mended to strengthen STPA-Sec by combining it with data- a novel analysis methodology called STPA-SafeSec, which flow-based threat models. However, Torkildson’s approach integrated STPA and STPA-Sec into one concise framework converts the STPA control structure into a data flow diagram and overcomes limitations of original approaches (e.g. no by simply replacing control actions and feedback paths with considerations about non-safety security issues) by introducing data channels. Although such a data flow diagram helps to security constraints and mapping abstract control structures identify more data-related threats than using STPA-Sec alone, to real components. Shapiro [20] proposed STPA for Privacy this diagram based on the original control loop does not view (STPA-Priv), which extends STPA into privacy engineering the system from the data aspect initially and may also miss by introducing privacy concepts and consideration into the data-related information. Besides, the STPA-Sec approach general STPA process steps. regards the security issue as one of the key threats affecting The most significant highlight of STPA-based approaches system safety [25] and only supports the identification of is that they shift from focusing on preventing failures and safety-related security goals [28]. Non-safety-related security avoiding threats to enforcing safety constraints and control issues like confidentiality may be overlooked. system vulnerabilities. Identifying and controlling system vul- To sum up, existing STPA-Sec is not effective to identify nerabilities rather than brainstorming and reacting to threats non-safety but information-related issues since it does not con- 3 TABLE I S UMMARY OF T RADITIONAL S ECURITY A NALYSIS A PPROACHES Type Approach Brief Introduction E-Safety Vehicle Intrusion Protected EVITA approach considers four security objectives (safety, privacy, financial, Original Approaches with Applications (EVITA) operational) and uses attacks trees to identify threats and assess risks [6]. complete process Threat, Vulnerabilities, and implementation TVRA is a process-driven TARA approach to systematically identify frameworks Risks Analysis (TVRA) unwanted incidents which need to be avoided [7]. Operationally Critical Threat, Asset, and OCTAVE is a process-driven TARA method which is best suited for Vulnerability Evaluation (OCTAVE) enterprise information security risk assessments [14]. HEAling Vulnerabilities to ENhance HEAVENS is a systematic approach of deriving security requirements for Software Security and Safety (HEAVENS) vehicle E/E systems, including processes and tools supporting for TARA [15]. Approaches evolved from A Security-Aware Hazard and Risk SAHARA is a combined approach of the Hazard Analysis and Risk other disciplines and Analysis Method (SAHARA) Assessment (HARA) with the STRIDE model and outlines the impacts of support co-analysis security issues on safety concepts [16]. Failure Mode, Vulnerabilities and Effects FMVEA is an approach evolved from the Failure Mode and Effect Analysis Analysis (FMVEA) (FMEA) to identify vulnerability cause-effect chains for security [17]. Combined Harm Assessment of Safety and CHASSIS is a unified process for safety and security by using UML-based Security (CHASSIS) models (e.g. misuse cases and sequence diagrams) [18]. sider security from the perspective of data flows. Furthermore, STPA-Sec lacks guidance for identifying security concepts. D. Contributions In this paper, we propose a data-flow-based extension of STPA-Sec (named STPA-DFSec) with elicitation guide words to overcome STPA-Sec’s limitations. The analysis process of a vehicle digital key system is presented to demonstrate how Fig. 1. General Control Loop [3] to use STPA-DFSec. We also analyze the same system by using the original STPA-Sec and compare outcomes though synthesis and mapping. Finally, we discover the relationship [3]. Each identified scenario represents a system failure which between both approaches and conclude the highlights and needs to be controlled by designers. applicability of them. STPA-Sec, as the extension for security considerations, shares the same basic steps. Vulnerabilities, instead of hazards III. M ETHODOLOGY are identified in the first step since vulnerabilities lead to A. Brief Introduction of STPA and STPA-Sec security incidents, which is just like hazards lead to safety We briefly introduce the original STPA framework as the incidents [4]. Similarly, final identified loss scenarios represent basis of the proposed approach in this section. system vulnerabilities which need to be controlled. STPA starts with defining the purpose of the analysis, including system-level losses, hazards and constraints. Losses B. STPA-DFSec Approach are about something valuable and unacceptable to the stake- The proposed STPA-DFSec follows the general STPA holders. A hazard is a system state or set of conditions that, framework but introduces a data-flow-based structure for infor- together with a particular set of worst-case environmental mation security considerations. The main steps are described conditions, will lead to a loss. Finally, system constraints can as follows. be derived from identified hazards, which specifies system 1) Step 1 - Define the purpose of the analysis: Just being conditions or behaviors that need to be satisfied to prevent similar with the STPA-Sec, the first step of the analysis is hazards and ultimately prevent losses [3]. to identify system-level losses, vulnerabilities and constraints Then, the control structure needs to be built to describe to figure out what are unacceptable results that need to be relationships and interactions by modelling the system as a avoided at the system strategy level. set of control loops (show in Figure 1). General security attributes like Confidentiality, Integrity The third step is to identify unsafe control actions, which and Availability (C.I.A. Triad Model) are guide words for will lead to a hazard in a particular context and worst-case the vulnerability identification, which classify the security environment [3], based on the previously built structure. Four problems and elicit potential vulnerabilities. ways of being unsafe are provided in STPA as guide words for the identification (listed in Table V). Furthermore, to help to identify losses, STPA-DFSec pro- Finally, loss scenarios, which describe the causal factors vides general guidance for loss identification based on the that can lead to unsafe control actions, will be identified. study of various safety- and security-related definitions from Two types of loss scenarios must be considered, which are standards and technical documents in industries including ISO scenarios that lead to unsafe control actions and scenarios in 26262 [29], EVITA project report [6] and J3061 guideline [5]. which control actions are improperly executed or not executed All possibilities of losses at a high abstract level are listed in 4 Table II. Losses of a particular case are a subset of this general 4) Step 4 - Identify Loss Scenarios: Finally, Loss Scenarios list and can be described concretely according to practical (LS), as possible causes of IFBs, are identified by using situations. optimized guide words. Table IV is the template for identifying LSs with two classes of guide words. The Function itself class helps to identify scenarios caused by unexpected behaviors TABLE II GENERAL L IST OF L OSSES inside the function, while the Execution environment (Env) class refers to external conditions outside. Label Loss Description L-1 Loss of life or cause Includes human and animal life TABLE IV injury to life TEMPLATE FOR I DENTIFYING LSS L-2 Loss of physical Represents physical objects belonging property to stakeholders (e.g. devices) IFBs GW: GW: Env- GW: Env- GW: Env- GW: L-3 Loss of non-physical Represents virtual properties belong- Function Function Calling Computing Env- property ing to stakeholders (e.g. sensitive in- Itself Inputs Behaviors Resources Links formation, reputation) S F S F S F S F S F S F n n n n n n L-4 Loss of environment Includes the natural or artificial world IFB IFB LS IFB LS IFB LS IFB LS IFB LS m m p1 m p2 m p3 m p4 m p5 Each loss scenario represents a system vulnerability which 2) Step 2 - Model Functional Interaction Structure: Instead should be controlled by designers or operators. Detailed sys- of the control structure, a Functional Interaction Structure tem constraints can also be derived from loss scenarios by (FIS) based on data flows is created to interpret how the simply inversing the conditions of loss scenarios or defining system works from the perspective of data flows. The basic what the system must do in case the incident occurs [3]. element of the FIS is the Function, which works based on its System constraints are inputs of further design phases. inputs and algorithms inside and outputs process results. The processing environment, together with inputs and algorithms, will affect function behaviors and final outputs. Inputs and C. Summary outputs, instead of control actions and feedback, are interac- Table V summarizes the process steps of both STPA-DFSec tions between components in FIS. Figure 2 shows a general and STPA-Sec with highlights of differences, in which ’+’ interaction structure and the function element, in which arrows donates added features of the STPA-DFSec and ’* represents represents data flows. modified steps in comparison with the original STPA-Sec. General FIS Function IV. C ASE S TUDY Component A Component B Function Inputs Outputs A. Use Case Definition and Assumption Function A-1 Function B-1 Alogrithms In this section, a Bluetooth digital key system of a vehicle Function A-2 Function B-2 Environment is introduced as the target system in this research. The system consists of three main physical components and aims to lock or Fig. 2. General FIS and Element ’Function’ unlock vehicle doors by using smartphones. Communication between different entities are through wireless channels and 3) Step 3 - Identify Insecure Function Behaviors: Based on protected by cryptographic mechanisms. The system sketch the FIS, we can identify Insecure Function Behaviors (IFB) and sequence diagram of two main services are shown in for the target system by following the basic technique in Figure 3 to describe how this system works. STPA. Insecure behaviors are identified with the help of Guide In this example case, we assume that the connections Words (GW), which are slightly modified to fit the proposed between components have been established via Wi-Fi or approach. Table III is the template for identifying IFBs. Bluetooth in advance, but the connection is not ensured to be secure, and the prerequisites in Figure 3 are regarded trusted. In this research, we only focus on security issues, which means TABLE III TEMPLATE FOR IDENTIFYING IFBS that the system can work properly without intended external disturbances and the system development errors and hardware Function GW: Not being GW: being GW: random failures are out of scope. (F) Executed Causes Executed Causes Timing Vulnerabilities Vulnerabilities Issues (TI) 1 2 (NECV) (ECV) B. Analysis by STPA-DFSec S F S F IFB S F IFB S F IFB n n n n m1 m2 m3 The analysis of the target system by using STPA-DFSec Notes: Represents that the function is not executed successfully. is presented in this section. First, system-level Losses (L), Represents that the function is executed with improper conditions Vulnerabilities (V) with linked losses and security attributes (e.g. incorrect inputs or algorithms, process with data leakage risks). 3 and derived System Constraints (SC) are listed in Table VI. Represents that the execution exceeds the timing limits. Second, the functional interaction structure is created in S F IFB is the label of each IFB, in which S represents the n m subject of the function. Figure 4 based on the system data flows. Two functions with identified IFBs are shown in Table VII as examples. In contrast 5 TABLE V S UMMARY OF STPA-DFSEC AND STPA-SEC S TEPS Basic Four Steps STPA-DFSec Details STPA-Sec Details Step 1 - Define the pur- Identify system-level losses, vulnerabilities and Identify system-level losses, vulnerabilities pose of the analysis constraints, link vulnerabilities with corre- and constraints. sponding losses and security attributes . A general losses list is provided . Step 2 - Model the sys- Model the system by functional interaction Model the system by functional control struc- tem structure structure based on data flows . ture based on control loops. Step 3 - Identify inse- Use modified guide words (not being exe- Use guide words (not providing, providing, cure items cuted, being executed and timing issues) to too early, too late, out of order, stopped too identify insecure function behaviors. soon, applied too long) to identify insecure control actions. Step 4 - Identify loss Use modified guide words (function itself, ex- Use guide words (unsafe controller behavior, scenarios ecution environment(incl. function inputs, call- inadequate feedback and information, involv- ing behaviors, computing resources and links) ing the control path, related to the controlled to identify loss scenarios. process) to identify loss scenarios. System Sketch Sequence Diagram pk_u, sk_u and pk_s, sk_s and vehicle pk_d, sk_d and prerequisites pk_s are prepared order records are prepared pk_s are prepared Cloud Server Smart Cloud Door Phone Server Controller User register or login send register or login data verify and execute register c = or login based on the E(pk_s, pk_u + ID_u + vehicle order records pw_u / ID_u + pw_u) user m = D(sk_s, c) Door Controller Smartphone register result = process_1(m) in the Vehicle (User) register or login result or login c = E(pk_u, result) get register result result = D(sk_u, register or login result E(pk_u, c) Notations pk_u, pk_s, pk_d Public key of the user, cloud lock/unlock doors server and door controller request a session key verify signature, sk_u, sk_s, sk_d Secret key of the user, cloud generate a session key s_u = S(cmd+UID_v) server and door controller c = E(pk_s, UID_v + s_u) for the communication E(pk, m) Asymmetric encryption function V(s_u) D(sk, c) Asymmetric decryption function m = D(sk_s, c) E_sym(k, m) Symmetric encryption function response the k_se = process_2(m) D_sym(k, c) Symmetric decryption function S(m) Signature function session key assign the session key get the lock or V(s) Signature verification function c = E(pk_u, k_se+UID_v) c = E(pk_d, k_se+ID_u) session key process_1/2(m) unlock doors Data process function get the session key k_se Session key for the symmetric D(sk_d, c) D(sk_u, c) communication ID_u User ID pw_u get and execute User password send lock/unlock command UID_v Unique ID of the vehicle command c = E_sym(k_se, cmd) cmd Lock or unlock command Plain text D_sym(k_se, c) Cipher text s Signature Fig. 3. Sequence Diagram of the System to most traditional approaches, this analysis includes partic- contain the same functions and different insecure behaviors ipants (user and manufacturer) outside the physical system may have the same causalities. In practice, it is also mean- boundary. Functions in a human operator can also be refined ingful to describe each function or LS separately to achieve into more detailed movements like ’decision in the mind’, security constraints for corresponding engineers, who might ’pressing button’ or ’recording password’. Since we focus only have access to a part of design information due to security on the physical part in this analysis, human movements are reasons. simplified as one human operation function. Note that the first letter of the IFB labels in Table VII represents system C. Analysis by STPA-Sec components including smartphone (P), cloud server (S), door controller (D), user (U) and manufacturer (M). We also analyzed this use case by STPA-Sec. Due to the Finally, LSs are identified for each IFB. Example LSs with same system model, the identified losses, hazards and system related guide words in the bracket are listed in Table VIII. constraints are the same as those in the STPA-DFSec analysis. Note that the IFBs and LSs of various subjects are merged to Therefore, the work here starts with drawing the system make the list concise since different system components may control structure shown in Figure 5, and then Insecure Control 6 TABLE VI TABLE VIII L OSSES, V ULNERABILITIES AND C ONSTRAINTS OF THE U SE CASE LOSS S CENARIOS OF IFB S L-1: Loss of physical property (The vehicle and properties in it) IFBs GW: Function GW: Environment Itself L-2: Loss of non-physical property (Manufacturers reputation) P/S/D F2 IFB3 P/S/D F2 IFB3 LS1 P/S/D F2 IFB3 LS2, V-1: Fail to lock the vehicle without being detected. [L-1/2, Integrity] P/S/D F2 IFB3 LS3, V-2: Fail to lock or unlock the vehicle, which can be detected by the P/S/D F2 IFB3 LS4 user. [L-2, Availability] U/M F7 IFB2 U/M F7 IFB2 LS1 / V-3: Leak sensitive information. [L-1/2, Confidentiality] SC-1: Missions should be completed successfully. [V-1/2] LS Description: P/S/D F2 IFB3 LS1: The function algorithm is modified to SC-2: If the mission fails, it must be detected by the user. [V-1] cause corresponding insecure function behaviors. SC-3: Sensitive information should be protected from leaking. [V-3] P/S/D F2 IFB3 LS2: The input data size is modified, which SC-4: If sensitive information is leaked, it should be detected and requires more time to compute. (Env -Function Inputs) reactions need to be taken to minimize losses. [V-3] P/S/D F2 IFB3 LS3: Computing resource is occupied to cause violation of execution timing limitations. (Env -Computing Resources) P/S/D F2 IFB3 LS4: Transmission is slowed down by additional User (U) Manufacturer (M) mechanisms on links (e.g. additional switches). (Env -Links) human operation human operation U/M F7 IFB2 LS1: The valid entity is fooled intendedly to use Smartphone (P) Door Controller (D) decrypt by invalid or incorrect data. transmit to vehicle k_session encrypt by calculate user’s k_session signature User (U) Manufacturer (M) plain data process encrypt by pk_s encrypt by pk_s plain data process register, login, register or login register I/O signal register (un)lock doors result result output decrypt by sk_u transmit to cloud transmit to cloud decrypt by sk_d (un)lock doors (un)lock signal Smartphone (P) Door Controller (D) execution verify user’s transmit to user decrypt by sk_s transmit to vehicle feedback signature assign a key assignment register or login session key feedback register or login, plain data process encrypt by pk_u encrypt by pk_d result, request a register responsed Cloud Server (S) session key register result session key control actions Main data flows from the smartphone, cloud server and door controller feedback Optional data flows from the smartphone Cloud Server (S) outputs Data flows from operators Fig. 4. Functional Interaction Structure based on Data Flows Fig. 5. Control Structure of the System TABLE VII TABLE IX IDENTIFIED I NSECURE F UNCTION BEHAVIORS IDENTIFIED I NSECURE CONTROL ACTIONS F GW: NECV GW: ECV GW: TI CA GW: Not GW: GW: Timing Providing Providing Issues P/S/D F2: Data P/S/D F2 P/S/D F2 P/S/D F2 transmission IFB1 IFB2 IFB3 D CA1: Register D CA1 ICA1 D CA1 ICA2 D CA1 ICA3 U/M F7: human / U/M F7 IFB1, / U CA2: Lock or / U CA2 ICA1 / operation U/M F7 IFB2 unlock doors IFB Description: ICA Description: P/S/D F2 IFB1: The required data fails to be transmitted. [V-1/2] D CA1 ICA1: The door controller fails to register at the server. [V-2] P/S/D F2 IFB2: The data is attacked (e.g. eavesdrop, tamper) D CA1 ICA2: The door controller registers with data leakage risks. during the transmission. [V-1/2/3] (e.g. UID, public key leakage). [V-3] P/S/D F2 IFB3: Function execution violates the timing limits. [V-2] D CA1 ICA3: The action violates the timing limits. [V-1] U/M F7 IFB1: The invalid entity operates with valid data. [V-1/2] U CA2 ICA1: The user is fooled to send wrong commands. [V-1/2] U/M F7 IFB2: The valid entity operates with invalid or Notes: incorrect data. [V-1/2] : Two GWs about timing in STPA-Sec are merged as timing issues. Actions (ICA) are identified. ICAs of example Control Actions encryption and decryption. Therefore, the relationship between (CA) are shown Table IX, in which the first letter of the label these two elements is that a sequence of the execution of represents the control action’s controller. functions forms a control action. Finally, loss scenarios of each ICAs are identified. Some To find out how different approaches work on the same use example LSs are shown in Table X. case, we mapped the analysis outcomes in both analyses. For example, D CA1 ICA3 LS1 and D CA1 ICA3 LS3 in the D. Outcome Comparison STPA-Sec analysis can be mapped to P/S/D F2 IFB3 LS1. The functions and control actions are basic elements in the U CA2 ICA1 LS1 and U CA2 ICA1 LS2 can be mapped STPA-DFSec and STPA-Sec respectively. Normally, a control to U F7 IFB2 LS1. After performing the mapping for all action includes several functions to provide a service. For analysis outcomes, we found that each loss scenario in the example, the control action D CA1 (Door controller registers STPA-Sec analysis can be mapped to a corresponding one at the server) consists of functions of data process, transmision, in the STPA-DFSec analysis from the perspective of data 7 TABLE X for ones who design the system functionalities and make more LOSS S CENARIOS OF ICAS high-level decisions. Actually, system security engineering is not able to ensure ICAs GW: GW: GW: GW: absolute security but provides a sufficient base of evidence Controller Controller Controlled Feedback Path Process Path that supports claims that the expected level of trustworthiness has been achieved [1]. The analysis in security engineering D CA1 D CA1 D CA1 D CA1 ICA3 ICA3 LS1 ICA3 LS2 ICA3 LS3 is also not able to be proven complete, and the analysis U CA2 / / U CA2 U CA2 results normally depend on the analyst’s knowledge and design ICA1 ICA1 LS1 ICA1 LS2 emphasis. However, a proper systematic approach can help the LS Description: analyst to be more confident in the analysis completeness [2]. D CA1 ICA3 LS1: The algorithm at the controller is tampered, Proper guide words help to reduce the dependency on personal which requires more calculating time. experience and subjective thinking and lead to objective and D CA1 ICA3 LS2: The link is modified to slow down the data transmission. valid results with less effort. Although the case study in this D CA1 ICA3 LS3: The algorithm at the controlled process is paper represents the authors’ understanding of the system, the tampered, which requires more calculating time. analysis results are comparable and meaningful because both U CA2 ICA1 LS1: The user interface of the smartphone is modified to guide the user to send wrong commands. analyses were performed by the same group of analysts. U CA2 ICA1 LS2: The vehicle state is presented wrongly, which leads to the users wrong behaviors. V. C ONCLUSION In this paper, we have proposed a data-flow-based approach process, which means that the proposed approach can find all for security analysis of information-critical systems based on possibilities identified by the original approach. Furthermore, the STPA framework to overcome STPA-Sec’s limitations. more loss scenarios can be identified in the STPA-DFSec The analyses of a vehicle digital key system by using both analysis. For example, the scenario ’Computing resource is the STPA-DFSec and STPA-Sec have been presented and occupied to cause violation of execution timing limitations.’ compared to show how to use the approaches and how well (P/S/D F2 IFB3 LS3 in Table VIII) cannot be identified by both approaches work on the same use case. the STPA-Sec. Therefore, more technical details related to the We have found that the proposed STPA-DFSec focuses data process can be revealed by the data-flow-based analysis. on data flows and can reveal more details in information Another finding is that an STPA-DFSec loss scenario can security aspects, which are hard to be addressed in the STPA- be mapped to several STPA-Sec ones because a function is Sec analysis, while the STPA-Sec analyzes systems from the always called by various control actions for different applica- perspective of applications and more concerns safety-related tions. This explains why STPA-Sec can reveal more detailed security issues. Besides, since STPA-based approaches were information from the perspective of applications. created for high-level decisions rather than tactical details [2], the proposed STPA-DFSec extends considerations into lower levels with technical details. Furthermore, as an extension of E. Discussion the STPA series, the proposed approach, together with other After the comparison, we concluded the differences and STPA-based approaches, can be used to co-design complex highlights of both approaches. The STPA-DFSec focuses on systems in multi-disciplines from high to low system levels information flows and discusses possible vulnerabilities along under the unified STPA framework. Social aspects and human the whole data flow paths, which helps to identify more factors can be included in the analysis, which are excluded in detailed loss scenarios from the perspective of information traditional analysis approaches. flows. By contrast, since control actions in STPA-Sec are In the future, we will study more industry cases and conduct derived from system functionalities, STPA-Sec can reveal experiments with different groups of analysts to validate and more insecure details linked to concrete application scenarios. refine the proposed approach in practices since we performed STPA-DFSec addresses where (in which function) a loss both analyses in this paper, which might influence the validity scenario occurs, while STPA-Sec addresses when (in which of analysis outcomes. Furthermore, we will formalize the application scenario) a loss scenario occurs. analysis process and design tools to achieve analysis results Since both approaches have different advantages, how to automatically for higher working efficiency. choose an approach depends on particular cases. Two princi- ples can be used to help the decision. The first one is according REFERENCES to system purposes. If the data is the core asset in a system, [1] R. Ross, M. McEvilley, and J. Oren, “Nist special publication 800-160: STPA-DFSec is suitable for analysis insecure issues with more Systems security engineering considerations for a multidisciplinary ap- considerations on the information. If providing proper and proach in the engineering of trustworthy secure systems,” Gaithersburg: secure services is the main object of a system, STPA-Sec is National Institute of Standards and Technology, 2016. [2] W. Young and N. Leveson, “Inside risks-an integrated approach to safety applicable to identify insecure issues linking with application and security based on system theory: Applying a more powerful new scenarios. The second principle is to consider who uses it. safety methodology to security risks,” Communications of the ACM, STPA-DFSec is suitable for designers who are responsible for vol. 57, no. 2, pp. 232–242, 2014. technical structure and design, while STPA-Sec is more useful [3] N. Leveson and J. Thomas, “Stpa handbook (2018),” 2019. 8 [4] W. Young and N. Leveson, “Systems thinking for safety and security,” [27] E. N. Torkildson, J. Li, and S. O. Johnsen, “Improving security and in Proceedings of the 29th Annual Computer Security Applications safety co-analysis of stpa,” in Proceedings of the 29th European Safety Conference, 2013, pp. 1–8. and Reliability Conference (ESREL). 22–26 September 2019 Hannover, [5] SAE, “J3061: cybersecurity guidebook for cyber-physical vehicle sys- Germany. Research Publishing Services, 2019. tems,” Nr, vol. 1, p. 52, 2016. [28] H. Martin, R. Bramberger, C. Schmittner, Z. Ma, T. Gruber, A. Ruiz, [6] A. Ruddle, D. Ward, B. Weyl, S. Idrees, Y. Roudier, M. Friedewald, and G. Macher, “Safety and security co-engineering and argumentation T. Leimbach, A. Fuchs, S. Gur ¨ gens, O. Henniger et al., “Security framework,” in International Conference on Computer Safety, Reliabil- requirements for automotive on-board networks based on dark-side ity, and Security. Springer, 2017, pp. 286–297. scenarios,” EVITA Deliverable D, vol. 2, no. 3, 2009. [29] ISO 26262-1 Road Vehicles - Functional Safety - Part 1: Vocabulary, [7] T. ETSI, “102 165-1: Cyber methods and protocols. part 1: Method and ISO Std., 2018. pro forma for threat, vulnerability,” Risk Analysis (TVRA). Technical Specification. European Telecommunications Standards Institute, 2017. [8] B. Schneier, Secrets & Lies: Digital Security in a Networked World. John Wiley & Sons, 2003. [9] Microsoft. (2009) The stride threat model. [On- line]. Available: https://docs.microsoft.com/en- us/previous-versions/ commerce- server/ee823878(v=cs.20)?redirectedfrom=MSDN [10] C. McCarthy, K. Harnett, A. Carter et al., “Characterization of potential security threats in modern automobiles: A composite modeling ap- proach,” United States. National Highway Traffic Safety Administration, Tech. Rep., 2014. [11] L. Pietre-Cambac ` ed ´ es ` and M. Bouissou, “Modeling safety and security interdependencies with bdmp (boolean logic driven markov processes),” in 2010 IEEE International Conference on Systems, Man and Cybernet- ics. IEEE, 2010, pp. 2852–2861. [12] B. Sapiro, Binary Risk Analysis, 2011. [Online]. Available: https: //binary.protect.io/#literature [13] R. S. Ross, “Guide for conducting risk assessments (nist sp)-800-30 rev 1,” National Institute of Standards and Technology, Tech. Rep., 2012. [14] C. J. Alberts, S. G. Behrens, R. D. Pethia, and W. R. Wilson, “Op- erationally critical threat, asset, and vulnerability evaluation (octave) framework, version 1.0,” CARNEGIE-MELLON UNIV PITTSBURGH PA SOFTWARE ENGINEERING INST, Tech. Rep., 1999. [15] M. Olsson, “Healing vulnerabilities to enhance software security and safety,” Volvo Technology AB, Tech. Rep., 2016. [Online]. Available: https://www.vinnova.se/globalassets/mikrosajter/ffi/dokument/ slutrapporter-ffi/elektronik- mjukvara-och- kommunikation-rapporter/ 2012- 04625eng.pdf [16] G. Macher, H. Sporer, R. Berlach, E. Armengaud, and C. Kreiner, “Sahara: a security-aware hazard and risk analysis method,” in 2015 Design, Automation & Test in Europe Conference & Exhibition (DATE). IEEE, 2015, pp. 621–624. [17] C. Schmittner, T. Gruber, P. Puschner, and E. Schoitsch, “Security application of failure mode and effect analysis (fmea),” in International Conference on Computer Safety, Reliability, and Security. Springer, 2014, pp. 310–325. [18] C. Raspotnig, P. Karpati, and V. Katta, “A combined process for elici- tation and analysis of safety and security requirements,” in Enterprise, business-process and information systems modeling. Springer, 2012, pp. 347–361. [19] I. Friedberg, K. McLaughlin, P. Smith, D. Laverty, and S. Sezer, “Stpa-safesec: Safety and security analysis for cyber-physical systems,” Journal of Information Security and Applications, vol. 34, pp. 183–196, [20] S. S. Shapiro, “Privacy risk analysis based on system control structures: Adapting system-theoretic process analysis for privacy engineering,” in 2016 IEEE Security and Privacy Workshops (SPW). IEEE, 2016, pp. 17–24. [21] Socio-technical systems. Interaction Design Foundation. [On- line]. Available: https://www.interaction-design.org/literature/topics/ socio- technical- systems [22] S. Khan, S. Madnick, and A. Moulton, Cybersafety Analysis of a Central Utilities Plant (CUP) Gas Turbine using STPA-SEC, 2018. [23] B. T. Carter, G. Bakirtzis, C. R. Elks, and C. H. Fleming, “A systems approach for eliciting mission-centric security requirements,” in 2018 Annual IEEE International Systems Conference (SysCon). IEEE, 2018, pp. 1–8. [24] A. S. Sidhu, “Application of stpa-sec for analyzing cybersecurity of autonomous mining systems,” Ph.D. dissertation, Massachusetts Institute of Technology, 2018. [25] L. C. Wei and S. Madnick, A System Theoretic Approach to Cybersecu- rity Risk Analysis and Mitigation for Autonomous Passenger Vehicles, [26] C. Schmittner, Z. Ma, and P. Puschner, “Limitation and improvement of stpa-sec for safety and security co-analysis,” in International Conference on Computer Safety, Reliability, and Security. Springer, 2016, pp. 195– http://www.deepdyve.com/assets/images/DeepDyve-Logo-lg.png Computing Research Repository arXiv (Cornell University)

Data-Flow-Based Extension of the System-Theoretic Process Analysis for Security (STPA-Sec)

Yu, Jinghua; Wagner, Stefan; Luo, Feng
Computing Research Repository , Volume 2021 (2006) – Jun 4, 2020
Download PDF
8 pages

Loading next page...
 
/lp/arxiv-cornell-university/data-flow-based-extension-of-the-system-theoretic-process-analysis-for-TQGo555LdB

References (40)

ISSN
2376-5992
eISSN
ARCH-3344
DOI
10.7717/peerj-cs.362
Publisher site
See Article on Publisher Site

Abstract

Data-Flow-Based Extension of the System-Theoretic Process Analysis for Security (STPA-Sec) Jinghua Yu, Stefan Wagner, Member IEEE, and Feng Luo Abstract—Security analysis is an essential activity in secu- security engineering phase and helps to manage system risks rity engineering to identify potential system vulnerabilities and and make decisions. achieve security requirements in the early design phases. Due Traditional security analysis approaches, being designed for to the increasing complexity of modern systems, traditional former relatively simple systems, are not effective to ana- approaches, which only consider component failures and simple lyze increasingly complex systems. Today’s Cyber-Physical cause-and-effect linkages, lack the power to identify insecure incidents caused by complex interactions among physical systems, Systems (CPS) or Socio-Technical Systems (STS) consist of human and social entities. By contrast, a top-down System- not only physical components but also software and even Theoretic Process Analysis for Security (STPA-Sec) approach social elements, in which components in multi-disciplines views losses as resulting from interactions, focuses on controlling interact with each other deeply. For example, an autonomous system vulnerabilities instead of external threats and is applicable vehicle (as a CPS) consists of tens of thousands of physical for complex socio-technical systems. In this paper, we proposed an extension of STPA-Sec based on data flow structures to components as well as lines of codes. A vehicle Over-The-Air overcome STPA-Secs limitations and achieve security constraints (OTA) software update system (as an STS) refers to not only of information-critical systems systematically. We analyzed a the technical part but also social entities like data providers Bluetooth digital key system of a vehicle by using both the and regulations. However, most traditional approaches start proposed and the original approach to investigate the relationship with system decomposition and focus on component failures, and differences between both approaches as well as their appli- cability and highlights. To conclude, the proposed approach can which leads to overlooking impacts of interactions since com- identify more information-related problems with technical details ponents are analyzed individually. Traditional causality models and be used with other STPA-based approaches to co-design attribute accidents to an initial component failure cascading systems in multi-disciplines under the unified STPA process through a set of other components (like dominos) [2] and can framework. not address causes of losses with non-linear cause-and-effect Index Terms—Security Analysis, Complex Interaction, linkages. Information-critical System, Data Flow Structure, STPA-Sec To meet the requirements of modern systems, a relatively new approach for safety engineering called System-Theoretic I. I NTRODUCTION Process Analysis (STPA) was proposed [3] and the extension for security named STPA-Sec was presented later [4]. How- YSTEM security is an emergent property of the system, ever, we recognized some limitations of STPA-Sec when im- which represents a state or condition that is free from plementing it, especially for data-flow-based systems. There- asset loss and the resulting loss consequences. System security fore, this research aims to work out an extended approach engineering, as a special discipline of system engineering, co- based on the unified STPA process framework for complex ordinates and directs various engineering specialties to provide information-critical systems to overcome the identified limita- a fully integrated, system-level perspective of system security tions of STPA-Sec. and helps to ensure the application of appropriate security The rest of this paper is organized as follows. In section principles and methodologies during the system life cycle II, we introduce traditional approaches and the STPA series for asset protection [1]. Violating system security constraints with research gaps and our contributions. In section III, we causes unexpected incidents, like mission failure or leaking introduce the original STPA-based approaches and propose sensitive information, and finally leads to financial or even life the extension in detail. In section IV, we present the analysis losses. Therefore, security needs to be considered carefully process of a use case by using both original and extended in system design. Security analysis, referring to the activity approaches to demonstrate how to use them and make the of analyzing systems in security-related aspects to achieve comparison. Finally, we summary this paper in section V. security requirements in this research, is performed in the early J. Yu is with School of Automotive Studies, Tongji University, 201804 II. R ELATED WORK Shanghai China (e-mail: yujinghua@outlook.com). A. Traditional Security Analysis Approaches S. Wagner is with Institute of Software Technology, University of Stuttgart, 70569 Stuttgart, Germany (e-mail: stefan.wagner@iste.uni-stuttgart.de) The purpose of the security analysis in the early design stage F. Luo is with the School of Automotive Studies, Tongji University, 201804 Shanghai, China (e-mail: luo feng@tongji.edu.cn) is to achieve security requirements. The Threats Analysis and This research was supported by the China Scholarship Council and funds of Risk Assessment (TARA) is normally the main activity in the the German Federal Ministry of Education and Research under grant number security analysis to identify potential threats and assess threat 16KIS0995. This version has been submitted to IEEE System Journal on 22 May 2020. risks [5]. The SAE (Society of Automotive Engineers) J3061 - arXiv:2006.02930v1 [cs.CR] 4 Jun 2020 2 Cybersecurity Guidebook for Cyber-physical Vehicle systems is a more efficient way to achieve system safety and security, [5] provides a list of approaches, which contain complete because controlling a vulnerability may be effective to reduce process frameworks of TARA, like the EVITA approach [6] several threats. Besides, threats are dynamic. Newly emerged and TVRA [7]. Besides, techniques are proposed for only threats can not always be detected in time, but controlling threat identification or risk assessment and can be used in vulnerabilities can protect the system against even unknown the previously mentioned TARA frameworks, including Attack threats, just like defending a castle by reinforcing walls and not Tree Analysis (ATA) [8], STRIDE threat models [9], Threat caring who is the enemy. Another highlight is that the STPA- and Operability Analysis (THROP) [5], Threat Matrix [10] based approaches are applicable for socio-technical systems, and BDMP-based (Boolean logic Driven Markov Processes) which are systems that consider requirements spanning hard- Modelling [11] for threat identification, as well as Binary Risk ware, software, personal, and community aspects [21]. The Analysis (BRA) [12] and NIST SP 800-30 Guide [13] for analysis scope of the STPA series includes not only physical risk assessment. Other than methods originally invented for system components but also humans, natural or social envi- security, some approaches are evolved from the safety field ronment and their interactions, which makes the approaches by introducing security awareness into the process and support more suitable for todays complex systems. Furthermore, due the co-analysis of both safety and security. to the numbers of extensions of STPA in various disciplines, Table I summarizes both original and evolved approaches it is easier to perform co-design with similar STPA framework with brief introductions. They are all bottom-up approaches and the same system model. building upon physical or functional decomposition instead of C. STPA-Sec Applications and Gaps analyzing the system as a whole initially. They focus more on the tactic level and may overlook issues at the strategy The STPA-Sec approach or its extensions have been used level. The tactics are means to accomplish a specific action to identify system security constraints in various industries. and focused on physical threats, while the strategy is regarded Khan, Madnick and Moulton [22] demonstrated the imple- as the art of gaining continuing advantages and is focused mentation of STPA-Sec to identify security vulnerabilities on abstract outcomes [2]. The latter one is useful to broaden of a use case (Central Utilities Plant Gas Turbine) in in- the mind and includes more aspects like organizational and dustrial control systems. Carter [23] used STPA-Sec with a managerial ones in the analysis. previous information elicitation process to analyze a small reconnaissance unmanned aerial vehicles. Sidhu [24] applied B. System-Theoretic Process Analysis (STPA) Approach and an STPA-Sec extension with modified attack tree method to Extensions analyze cybersecurity of autonomous mining systems. Wei and To overcome the limitations of traditional approaches, STPA Madnick [25] analyzed a use case (Over-The-Air software was created as a hazard analysis approach based on the update) in the automotive industry by using both STPA- System-Theoretic Accident Model and Process (STAMP), Sec and CHASSIS and compared analysis outcomes, which which views losses as results from interactions among various showed that STPA-Sec can identify more hazards compared to system roles that lead to violations of safety constraints and CHASSIS, while CHASSIS is more suitable for information analyzes issues at the strategy level. STPA provides a powerful lifecycle analysis. way to deal with complexity by using traceable hierarchical Nevertheless, researchers also pointed out several limita- abstraction and refinement [2]. tions of STPA-Sec. Schmittner, Ma and Puschner [26] reported Other than safety engineering, STPA has also been extended that the original STPA-Sec lacks guidance for intended causal into other fields with the same system-theoretic thought. scenarios, excludes considerations of the data exchange which Young and Leveson [4] firstly presented STPA for Security is not directly connected to the process control and cannot (STPA-Sec), which shares similar steps with STPA and fo- cover more information-security centric properties such as cuses on controlling system vulnerabilities instead of avoiding confidentiality. Torkildson, Li and Johnsen [27] also found that threats. To perform co-analysis of safety and security under some essential security issues can be overlooked and recom- the STPA framework better, Friedberg et al. [19] proposed mended to strengthen STPA-Sec by combining it with data- a novel analysis methodology called STPA-SafeSec, which flow-based threat models. However, Torkildson’s approach integrated STPA and STPA-Sec into one concise framework converts the STPA control structure into a data flow diagram and overcomes limitations of original approaches (e.g. no by simply replacing control actions and feedback paths with considerations about non-safety security issues) by introducing data channels. Although such a data flow diagram helps to security constraints and mapping abstract control structures identify more data-related threats than using STPA-Sec alone, to real components. Shapiro [20] proposed STPA for Privacy this diagram based on the original control loop does not view (STPA-Priv), which extends STPA into privacy engineering the system from the data aspect initially and may also miss by introducing privacy concepts and consideration into the data-related information. Besides, the STPA-Sec approach general STPA process steps. regards the security issue as one of the key threats affecting The most significant highlight of STPA-based approaches system safety [25] and only supports the identification of is that they shift from focusing on preventing failures and safety-related security goals [28]. Non-safety-related security avoiding threats to enforcing safety constraints and control issues like confidentiality may be overlooked. system vulnerabilities. Identifying and controlling system vul- To sum up, existing STPA-Sec is not effective to identify nerabilities rather than brainstorming and reacting to threats non-safety but information-related issues since it does not con- 3 TABLE I S UMMARY OF T RADITIONAL S ECURITY A NALYSIS A PPROACHES Type Approach Brief Introduction E-Safety Vehicle Intrusion Protected EVITA approach considers four security objectives (safety, privacy, financial, Original Approaches with Applications (EVITA) operational) and uses attacks trees to identify threats and assess risks [6]. complete process Threat, Vulnerabilities, and implementation TVRA is a process-driven TARA approach to systematically identify frameworks Risks Analysis (TVRA) unwanted incidents which need to be avoided [7]. Operationally Critical Threat, Asset, and OCTAVE is a process-driven TARA method which is best suited for Vulnerability Evaluation (OCTAVE) enterprise information security risk assessments [14]. HEAling Vulnerabilities to ENhance HEAVENS is a systematic approach of deriving security requirements for Software Security and Safety (HEAVENS) vehicle E/E systems, including processes and tools supporting for TARA [15]. Approaches evolved from A Security-Aware Hazard and Risk SAHARA is a combined approach of the Hazard Analysis and Risk other disciplines and Analysis Method (SAHARA) Assessment (HARA) with the STRIDE model and outlines the impacts of support co-analysis security issues on safety concepts [16]. Failure Mode, Vulnerabilities and Effects FMVEA is an approach evolved from the Failure Mode and Effect Analysis Analysis (FMVEA) (FMEA) to identify vulnerability cause-effect chains for security [17]. Combined Harm Assessment of Safety and CHASSIS is a unified process for safety and security by using UML-based Security (CHASSIS) models (e.g. misuse cases and sequence diagrams) [18]. sider security from the perspective of data flows. Furthermore, STPA-Sec lacks guidance for identifying security concepts. D. Contributions In this paper, we propose a data-flow-based extension of STPA-Sec (named STPA-DFSec) with elicitation guide words to overcome STPA-Sec’s limitations. The analysis process of a vehicle digital key system is presented to demonstrate how Fig. 1. General Control Loop [3] to use STPA-DFSec. We also analyze the same system by using the original STPA-Sec and compare outcomes though synthesis and mapping. Finally, we discover the relationship [3]. Each identified scenario represents a system failure which between both approaches and conclude the highlights and needs to be controlled by designers. applicability of them. STPA-Sec, as the extension for security considerations, shares the same basic steps. Vulnerabilities, instead of hazards III. M ETHODOLOGY are identified in the first step since vulnerabilities lead to A. Brief Introduction of STPA and STPA-Sec security incidents, which is just like hazards lead to safety We briefly introduce the original STPA framework as the incidents [4]. Similarly, final identified loss scenarios represent basis of the proposed approach in this section. system vulnerabilities which need to be controlled. STPA starts with defining the purpose of the analysis, including system-level losses, hazards and constraints. Losses B. STPA-DFSec Approach are about something valuable and unacceptable to the stake- The proposed STPA-DFSec follows the general STPA holders. A hazard is a system state or set of conditions that, framework but introduces a data-flow-based structure for infor- together with a particular set of worst-case environmental mation security considerations. The main steps are described conditions, will lead to a loss. Finally, system constraints can as follows. be derived from identified hazards, which specifies system 1) Step 1 - Define the purpose of the analysis: Just being conditions or behaviors that need to be satisfied to prevent similar with the STPA-Sec, the first step of the analysis is hazards and ultimately prevent losses [3]. to identify system-level losses, vulnerabilities and constraints Then, the control structure needs to be built to describe to figure out what are unacceptable results that need to be relationships and interactions by modelling the system as a avoided at the system strategy level. set of control loops (show in Figure 1). General security attributes like Confidentiality, Integrity The third step is to identify unsafe control actions, which and Availability (C.I.A. Triad Model) are guide words for will lead to a hazard in a particular context and worst-case the vulnerability identification, which classify the security environment [3], based on the previously built structure. Four problems and elicit potential vulnerabilities. ways of being unsafe are provided in STPA as guide words for the identification (listed in Table V). Furthermore, to help to identify losses, STPA-DFSec pro- Finally, loss scenarios, which describe the causal factors vides general guidance for loss identification based on the that can lead to unsafe control actions, will be identified. study of various safety- and security-related definitions from Two types of loss scenarios must be considered, which are standards and technical documents in industries including ISO scenarios that lead to unsafe control actions and scenarios in 26262 [29], EVITA project report [6] and J3061 guideline [5]. which control actions are improperly executed or not executed All possibilities of losses at a high abstract level are listed in 4 Table II. Losses of a particular case are a subset of this general 4) Step 4 - Identify Loss Scenarios: Finally, Loss Scenarios list and can be described concretely according to practical (LS), as possible causes of IFBs, are identified by using situations. optimized guide words. Table IV is the template for identifying LSs with two classes of guide words. The Function itself class helps to identify scenarios caused by unexpected behaviors TABLE II GENERAL L IST OF L OSSES inside the function, while the Execution environment (Env) class refers to external conditions outside. Label Loss Description L-1 Loss of life or cause Includes human and animal life TABLE IV injury to life TEMPLATE FOR I DENTIFYING LSS L-2 Loss of physical Represents physical objects belonging property to stakeholders (e.g. devices) IFBs GW: GW: Env- GW: Env- GW: Env- GW: L-3 Loss of non-physical Represents virtual properties belong- Function Function Calling Computing Env- property ing to stakeholders (e.g. sensitive in- Itself Inputs Behaviors Resources Links formation, reputation) S F S F S F S F S F S F n n n n n n L-4 Loss of environment Includes the natural or artificial world IFB IFB LS IFB LS IFB LS IFB LS IFB LS m m p1 m p2 m p3 m p4 m p5 Each loss scenario represents a system vulnerability which 2) Step 2 - Model Functional Interaction Structure: Instead should be controlled by designers or operators. Detailed sys- of the control structure, a Functional Interaction Structure tem constraints can also be derived from loss scenarios by (FIS) based on data flows is created to interpret how the simply inversing the conditions of loss scenarios or defining system works from the perspective of data flows. The basic what the system must do in case the incident occurs [3]. element of the FIS is the Function, which works based on its System constraints are inputs of further design phases. inputs and algorithms inside and outputs process results. The processing environment, together with inputs and algorithms, will affect function behaviors and final outputs. Inputs and C. Summary outputs, instead of control actions and feedback, are interac- Table V summarizes the process steps of both STPA-DFSec tions between components in FIS. Figure 2 shows a general and STPA-Sec with highlights of differences, in which ’+’ interaction structure and the function element, in which arrows donates added features of the STPA-DFSec and ’* represents represents data flows. modified steps in comparison with the original STPA-Sec. General FIS Function IV. C ASE S TUDY Component A Component B Function Inputs Outputs A. Use Case Definition and Assumption Function A-1 Function B-1 Alogrithms In this section, a Bluetooth digital key system of a vehicle Function A-2 Function B-2 Environment is introduced as the target system in this research. The system consists of three main physical components and aims to lock or Fig. 2. General FIS and Element ’Function’ unlock vehicle doors by using smartphones. Communication between different entities are through wireless channels and 3) Step 3 - Identify Insecure Function Behaviors: Based on protected by cryptographic mechanisms. The system sketch the FIS, we can identify Insecure Function Behaviors (IFB) and sequence diagram of two main services are shown in for the target system by following the basic technique in Figure 3 to describe how this system works. STPA. Insecure behaviors are identified with the help of Guide In this example case, we assume that the connections Words (GW), which are slightly modified to fit the proposed between components have been established via Wi-Fi or approach. Table III is the template for identifying IFBs. Bluetooth in advance, but the connection is not ensured to be secure, and the prerequisites in Figure 3 are regarded trusted. In this research, we only focus on security issues, which means TABLE III TEMPLATE FOR IDENTIFYING IFBS that the system can work properly without intended external disturbances and the system development errors and hardware Function GW: Not being GW: being GW: random failures are out of scope. (F) Executed Causes Executed Causes Timing Vulnerabilities Vulnerabilities Issues (TI) 1 2 (NECV) (ECV) B. Analysis by STPA-DFSec S F S F IFB S F IFB S F IFB n n n n m1 m2 m3 The analysis of the target system by using STPA-DFSec Notes: Represents that the function is not executed successfully. is presented in this section. First, system-level Losses (L), Represents that the function is executed with improper conditions Vulnerabilities (V) with linked losses and security attributes (e.g. incorrect inputs or algorithms, process with data leakage risks). 3 and derived System Constraints (SC) are listed in Table VI. Represents that the execution exceeds the timing limits. Second, the functional interaction structure is created in S F IFB is the label of each IFB, in which S represents the n m subject of the function. Figure 4 based on the system data flows. Two functions with identified IFBs are shown in Table VII as examples. In contrast 5 TABLE V S UMMARY OF STPA-DFSEC AND STPA-SEC S TEPS Basic Four Steps STPA-DFSec Details STPA-Sec Details Step 1 - Define the pur- Identify system-level losses, vulnerabilities and Identify system-level losses, vulnerabilities pose of the analysis constraints, link vulnerabilities with corre- and constraints. sponding losses and security attributes . A general losses list is provided . Step 2 - Model the sys- Model the system by functional interaction Model the system by functional control struc- tem structure structure based on data flows . ture based on control loops. Step 3 - Identify inse- Use modified guide words (not being exe- Use guide words (not providing, providing, cure items cuted, being executed and timing issues) to too early, too late, out of order, stopped too identify insecure function behaviors. soon, applied too long) to identify insecure control actions. Step 4 - Identify loss Use modified guide words (function itself, ex- Use guide words (unsafe controller behavior, scenarios ecution environment(incl. function inputs, call- inadequate feedback and information, involv- ing behaviors, computing resources and links) ing the control path, related to the controlled to identify loss scenarios. process) to identify loss scenarios. System Sketch Sequence Diagram pk_u, sk_u and pk_s, sk_s and vehicle pk_d, sk_d and prerequisites pk_s are prepared order records are prepared pk_s are prepared Cloud Server Smart Cloud Door Phone Server Controller User register or login send register or login data verify and execute register c = or login based on the E(pk_s, pk_u + ID_u + vehicle order records pw_u / ID_u + pw_u) user m = D(sk_s, c) Door Controller Smartphone register result = process_1(m) in the Vehicle (User) register or login result or login c = E(pk_u, result) get register result result = D(sk_u, register or login result E(pk_u, c) Notations pk_u, pk_s, pk_d Public key of the user, cloud lock/unlock doors server and door controller request a session key verify signature, sk_u, sk_s, sk_d Secret key of the user, cloud generate a session key s_u = S(cmd+UID_v) server and door controller c = E(pk_s, UID_v + s_u) for the communication E(pk, m) Asymmetric encryption function V(s_u) D(sk, c) Asymmetric decryption function m = D(sk_s, c) E_sym(k, m) Symmetric encryption function response the k_se = process_2(m) D_sym(k, c) Symmetric decryption function S(m) Signature function session key assign the session key get the lock or V(s) Signature verification function c = E(pk_u, k_se+UID_v) c = E(pk_d, k_se+ID_u) session key process_1/2(m) unlock doors Data process function get the session key k_se Session key for the symmetric D(sk_d, c) D(sk_u, c) communication ID_u User ID pw_u get and execute User password send lock/unlock command UID_v Unique ID of the vehicle command c = E_sym(k_se, cmd) cmd Lock or unlock command Plain text D_sym(k_se, c) Cipher text s Signature Fig. 3. Sequence Diagram of the System to most traditional approaches, this analysis includes partic- contain the same functions and different insecure behaviors ipants (user and manufacturer) outside the physical system may have the same causalities. In practice, it is also mean- boundary. Functions in a human operator can also be refined ingful to describe each function or LS separately to achieve into more detailed movements like ’decision in the mind’, security constraints for corresponding engineers, who might ’pressing button’ or ’recording password’. Since we focus only have access to a part of design information due to security on the physical part in this analysis, human movements are reasons. simplified as one human operation function. Note that the first letter of the IFB labels in Table VII represents system C. Analysis by STPA-Sec components including smartphone (P), cloud server (S), door controller (D), user (U) and manufacturer (M). We also analyzed this use case by STPA-Sec. Due to the Finally, LSs are identified for each IFB. Example LSs with same system model, the identified losses, hazards and system related guide words in the bracket are listed in Table VIII. constraints are the same as those in the STPA-DFSec analysis. Note that the IFBs and LSs of various subjects are merged to Therefore, the work here starts with drawing the system make the list concise since different system components may control structure shown in Figure 5, and then Insecure Control 6 TABLE VI TABLE VIII L OSSES, V ULNERABILITIES AND C ONSTRAINTS OF THE U SE CASE LOSS S CENARIOS OF IFB S L-1: Loss of physical property (The vehicle and properties in it) IFBs GW: Function GW: Environment Itself L-2: Loss of non-physical property (Manufacturers reputation) P/S/D F2 IFB3 P/S/D F2 IFB3 LS1 P/S/D F2 IFB3 LS2, V-1: Fail to lock the vehicle without being detected. [L-1/2, Integrity] P/S/D F2 IFB3 LS3, V-2: Fail to lock or unlock the vehicle, which can be detected by the P/S/D F2 IFB3 LS4 user. [L-2, Availability] U/M F7 IFB2 U/M F7 IFB2 LS1 / V-3: Leak sensitive information. [L-1/2, Confidentiality] SC-1: Missions should be completed successfully. [V-1/2] LS Description: P/S/D F2 IFB3 LS1: The function algorithm is modified to SC-2: If the mission fails, it must be detected by the user. [V-1] cause corresponding insecure function behaviors. SC-3: Sensitive information should be protected from leaking. [V-3] P/S/D F2 IFB3 LS2: The input data size is modified, which SC-4: If sensitive information is leaked, it should be detected and requires more time to compute. (Env -Function Inputs) reactions need to be taken to minimize losses. [V-3] P/S/D F2 IFB3 LS3: Computing resource is occupied to cause violation of execution timing limitations. (Env -Computing Resources) P/S/D F2 IFB3 LS4: Transmission is slowed down by additional User (U) Manufacturer (M) mechanisms on links (e.g. additional switches). (Env -Links) human operation human operation U/M F7 IFB2 LS1: The valid entity is fooled intendedly to use Smartphone (P) Door Controller (D) decrypt by invalid or incorrect data. transmit to vehicle k_session encrypt by calculate user’s k_session signature User (U) Manufacturer (M) plain data process encrypt by pk_s encrypt by pk_s plain data process register, login, register or login register I/O signal register (un)lock doors result result output decrypt by sk_u transmit to cloud transmit to cloud decrypt by sk_d (un)lock doors (un)lock signal Smartphone (P) Door Controller (D) execution verify user’s transmit to user decrypt by sk_s transmit to vehicle feedback signature assign a key assignment register or login session key feedback register or login, plain data process encrypt by pk_u encrypt by pk_d result, request a register responsed Cloud Server (S) session key register result session key control actions Main data flows from the smartphone, cloud server and door controller feedback Optional data flows from the smartphone Cloud Server (S) outputs Data flows from operators Fig. 4. Functional Interaction Structure based on Data Flows Fig. 5. Control Structure of the System TABLE VII TABLE IX IDENTIFIED I NSECURE F UNCTION BEHAVIORS IDENTIFIED I NSECURE CONTROL ACTIONS F GW: NECV GW: ECV GW: TI CA GW: Not GW: GW: Timing Providing Providing Issues P/S/D F2: Data P/S/D F2 P/S/D F2 P/S/D F2 transmission IFB1 IFB2 IFB3 D CA1: Register D CA1 ICA1 D CA1 ICA2 D CA1 ICA3 U/M F7: human / U/M F7 IFB1, / U CA2: Lock or / U CA2 ICA1 / operation U/M F7 IFB2 unlock doors IFB Description: ICA Description: P/S/D F2 IFB1: The required data fails to be transmitted. [V-1/2] D CA1 ICA1: The door controller fails to register at the server. [V-2] P/S/D F2 IFB2: The data is attacked (e.g. eavesdrop, tamper) D CA1 ICA2: The door controller registers with data leakage risks. during the transmission. [V-1/2/3] (e.g. UID, public key leakage). [V-3] P/S/D F2 IFB3: Function execution violates the timing limits. [V-2] D CA1 ICA3: The action violates the timing limits. [V-1] U/M F7 IFB1: The invalid entity operates with valid data. [V-1/2] U CA2 ICA1: The user is fooled to send wrong commands. [V-1/2] U/M F7 IFB2: The valid entity operates with invalid or Notes: incorrect data. [V-1/2] : Two GWs about timing in STPA-Sec are merged as timing issues. Actions (ICA) are identified. ICAs of example Control Actions encryption and decryption. Therefore, the relationship between (CA) are shown Table IX, in which the first letter of the label these two elements is that a sequence of the execution of represents the control action’s controller. functions forms a control action. Finally, loss scenarios of each ICAs are identified. Some To find out how different approaches work on the same use example LSs are shown in Table X. case, we mapped the analysis outcomes in both analyses. For example, D CA1 ICA3 LS1 and D CA1 ICA3 LS3 in the D. Outcome Comparison STPA-Sec analysis can be mapped to P/S/D F2 IFB3 LS1. The functions and control actions are basic elements in the U CA2 ICA1 LS1 and U CA2 ICA1 LS2 can be mapped STPA-DFSec and STPA-Sec respectively. Normally, a control to U F7 IFB2 LS1. After performing the mapping for all action includes several functions to provide a service. For analysis outcomes, we found that each loss scenario in the example, the control action D CA1 (Door controller registers STPA-Sec analysis can be mapped to a corresponding one at the server) consists of functions of data process, transmision, in the STPA-DFSec analysis from the perspective of data 7 TABLE X for ones who design the system functionalities and make more LOSS S CENARIOS OF ICAS high-level decisions. Actually, system security engineering is not able to ensure ICAs GW: GW: GW: GW: absolute security but provides a sufficient base of evidence Controller Controller Controlled Feedback Path Process Path that supports claims that the expected level of trustworthiness has been achieved [1]. The analysis in security engineering D CA1 D CA1 D CA1 D CA1 ICA3 ICA3 LS1 ICA3 LS2 ICA3 LS3 is also not able to be proven complete, and the analysis U CA2 / / U CA2 U CA2 results normally depend on the analyst’s knowledge and design ICA1 ICA1 LS1 ICA1 LS2 emphasis. However, a proper systematic approach can help the LS Description: analyst to be more confident in the analysis completeness [2]. D CA1 ICA3 LS1: The algorithm at the controller is tampered, Proper guide words help to reduce the dependency on personal which requires more calculating time. experience and subjective thinking and lead to objective and D CA1 ICA3 LS2: The link is modified to slow down the data transmission. valid results with less effort. Although the case study in this D CA1 ICA3 LS3: The algorithm at the controlled process is paper represents the authors’ understanding of the system, the tampered, which requires more calculating time. analysis results are comparable and meaningful because both U CA2 ICA1 LS1: The user interface of the smartphone is modified to guide the user to send wrong commands. analyses were performed by the same group of analysts. U CA2 ICA1 LS2: The vehicle state is presented wrongly, which leads to the users wrong behaviors. V. C ONCLUSION In this paper, we have proposed a data-flow-based approach process, which means that the proposed approach can find all for security analysis of information-critical systems based on possibilities identified by the original approach. Furthermore, the STPA framework to overcome STPA-Sec’s limitations. more loss scenarios can be identified in the STPA-DFSec The analyses of a vehicle digital key system by using both analysis. For example, the scenario ’Computing resource is the STPA-DFSec and STPA-Sec have been presented and occupied to cause violation of execution timing limitations.’ compared to show how to use the approaches and how well (P/S/D F2 IFB3 LS3 in Table VIII) cannot be identified by both approaches work on the same use case. the STPA-Sec. Therefore, more technical details related to the We have found that the proposed STPA-DFSec focuses data process can be revealed by the data-flow-based analysis. on data flows and can reveal more details in information Another finding is that an STPA-DFSec loss scenario can security aspects, which are hard to be addressed in the STPA- be mapped to several STPA-Sec ones because a function is Sec analysis, while the STPA-Sec analyzes systems from the always called by various control actions for different applica- perspective of applications and more concerns safety-related tions. This explains why STPA-Sec can reveal more detailed security issues. Besides, since STPA-based approaches were information from the perspective of applications. created for high-level decisions rather than tactical details [2], the proposed STPA-DFSec extends considerations into lower levels with technical details. Furthermore, as an extension of E. Discussion the STPA series, the proposed approach, together with other After the comparison, we concluded the differences and STPA-based approaches, can be used to co-design complex highlights of both approaches. The STPA-DFSec focuses on systems in multi-disciplines from high to low system levels information flows and discusses possible vulnerabilities along under the unified STPA framework. Social aspects and human the whole data flow paths, which helps to identify more factors can be included in the analysis, which are excluded in detailed loss scenarios from the perspective of information traditional analysis approaches. flows. By contrast, since control actions in STPA-Sec are In the future, we will study more industry cases and conduct derived from system functionalities, STPA-Sec can reveal experiments with different groups of analysts to validate and more insecure details linked to concrete application scenarios. refine the proposed approach in practices since we performed STPA-DFSec addresses where (in which function) a loss both analyses in this paper, which might influence the validity scenario occurs, while STPA-Sec addresses when (in which of analysis outcomes. Furthermore, we will formalize the application scenario) a loss scenario occurs. analysis process and design tools to achieve analysis results Since both approaches have different advantages, how to automatically for higher working efficiency. choose an approach depends on particular cases. Two princi- ples can be used to help the decision. The first one is according REFERENCES to system purposes. If the data is the core asset in a system, [1] R. Ross, M. McEvilley, and J. Oren, “Nist special publication 800-160: STPA-DFSec is suitable for analysis insecure issues with more Systems security engineering considerations for a multidisciplinary ap- considerations on the information. If providing proper and proach in the engineering of trustworthy secure systems,” Gaithersburg: secure services is the main object of a system, STPA-Sec is National Institute of Standards and Technology, 2016. [2] W. Young and N. Leveson, “Inside risks-an integrated approach to safety applicable to identify insecure issues linking with application and security based on system theory: Applying a more powerful new scenarios. The second principle is to consider who uses it. safety methodology to security risks,” Communications of the ACM, STPA-DFSec is suitable for designers who are responsible for vol. 57, no. 2, pp. 232–242, 2014. technical structure and design, while STPA-Sec is more useful [3] N. Leveson and J. Thomas, “Stpa handbook (2018),” 2019. 8 [4] W. Young and N. Leveson, “Systems thinking for safety and security,” [27] E. N. Torkildson, J. Li, and S. O. Johnsen, “Improving security and in Proceedings of the 29th Annual Computer Security Applications safety co-analysis of stpa,” in Proceedings of the 29th European Safety Conference, 2013, pp. 1–8. and Reliability Conference (ESREL). 22–26 September 2019 Hannover, [5] SAE, “J3061: cybersecurity guidebook for cyber-physical vehicle sys- Germany. Research Publishing Services, 2019. tems,” Nr, vol. 1, p. 52, 2016. [28] H. Martin, R. Bramberger, C. Schmittner, Z. Ma, T. Gruber, A. Ruiz, [6] A. Ruddle, D. Ward, B. Weyl, S. Idrees, Y. Roudier, M. Friedewald, and G. Macher, “Safety and security co-engineering and argumentation T. Leimbach, A. Fuchs, S. Gur ¨ gens, O. Henniger et al., “Security framework,” in International Conference on Computer Safety, Reliabil- requirements for automotive on-board networks based on dark-side ity, and Security. Springer, 2017, pp. 286–297. scenarios,” EVITA Deliverable D, vol. 2, no. 3, 2009. [29] ISO 26262-1 Road Vehicles - Functional Safety - Part 1: Vocabulary, [7] T. ETSI, “102 165-1: Cyber methods and protocols. part 1: Method and ISO Std., 2018. pro forma for threat, vulnerability,” Risk Analysis (TVRA). Technical Specification. European Telecommunications Standards Institute, 2017. [8] B. Schneier, Secrets & Lies: Digital Security in a Networked World. John Wiley & Sons, 2003. [9] Microsoft. (2009) The stride threat model. [On- line]. Available: https://docs.microsoft.com/en- us/previous-versions/ commerce- server/ee823878(v=cs.20)?redirectedfrom=MSDN [10] C. McCarthy, K. Harnett, A. Carter et al., “Characterization of potential security threats in modern automobiles: A composite modeling ap- proach,” United States. National Highway Traffic Safety Administration, Tech. Rep., 2014. [11] L. Pietre-Cambac ` ed ´ es ` and M. Bouissou, “Modeling safety and security interdependencies with bdmp (boolean logic driven markov processes),” in 2010 IEEE International Conference on Systems, Man and Cybernet- ics. IEEE, 2010, pp. 2852–2861. [12] B. Sapiro, Binary Risk Analysis, 2011. [Online]. Available: https: //binary.protect.io/#literature [13] R. S. Ross, “Guide for conducting risk assessments (nist sp)-800-30 rev 1,” National Institute of Standards and Technology, Tech. Rep., 2012. [14] C. J. Alberts, S. G. Behrens, R. D. Pethia, and W. R. Wilson, “Op- erationally critical threat, asset, and vulnerability evaluation (octave) framework, version 1.0,” CARNEGIE-MELLON UNIV PITTSBURGH PA SOFTWARE ENGINEERING INST, Tech. Rep., 1999. [15] M. Olsson, “Healing vulnerabilities to enhance software security and safety,” Volvo Technology AB, Tech. Rep., 2016. [Online]. Available: https://www.vinnova.se/globalassets/mikrosajter/ffi/dokument/ slutrapporter-ffi/elektronik- mjukvara-och- kommunikation-rapporter/ 2012- 04625eng.pdf [16] G. Macher, H. Sporer, R. Berlach, E. Armengaud, and C. Kreiner, “Sahara: a security-aware hazard and risk analysis method,” in 2015 Design, Automation & Test in Europe Conference & Exhibition (DATE). IEEE, 2015, pp. 621–624. [17] C. Schmittner, T. Gruber, P. Puschner, and E. Schoitsch, “Security application of failure mode and effect analysis (fmea),” in International Conference on Computer Safety, Reliability, and Security. Springer, 2014, pp. 310–325. [18] C. Raspotnig, P. Karpati, and V. Katta, “A combined process for elici- tation and analysis of safety and security requirements,” in Enterprise, business-process and information systems modeling. Springer, 2012, pp. 347–361. [19] I. Friedberg, K. McLaughlin, P. Smith, D. Laverty, and S. Sezer, “Stpa-safesec: Safety and security analysis for cyber-physical systems,” Journal of Information Security and Applications, vol. 34, pp. 183–196, [20] S. S. Shapiro, “Privacy risk analysis based on system control structures: Adapting system-theoretic process analysis for privacy engineering,” in 2016 IEEE Security and Privacy Workshops (SPW). IEEE, 2016, pp. 17–24. [21] Socio-technical systems. Interaction Design Foundation. [On- line]. Available: https://www.interaction-design.org/literature/topics/ socio- technical- systems [22] S. Khan, S. Madnick, and A. Moulton, Cybersafety Analysis of a Central Utilities Plant (CUP) Gas Turbine using STPA-SEC, 2018. [23] B. T. Carter, G. Bakirtzis, C. R. Elks, and C. H. Fleming, “A systems approach for eliciting mission-centric security requirements,” in 2018 Annual IEEE International Systems Conference (SysCon). IEEE, 2018, pp. 1–8. [24] A. S. Sidhu, “Application of stpa-sec for analyzing cybersecurity of autonomous mining systems,” Ph.D. dissertation, Massachusetts Institute of Technology, 2018. [25] L. C. Wei and S. Madnick, A System Theoretic Approach to Cybersecu- rity Risk Analysis and Mitigation for Autonomous Passenger Vehicles, [26] C. Schmittner, Z. Ma, and P. Puschner, “Limitation and improvement of stpa-sec for safety and security co-analysis,” in International Conference on Computer Safety, Reliability, and Security. Springer, 2016, pp. 195–

Journal

Computing Research Repository – arXiv (Cornell University)

Published: Jun 4, 2020

There are no references for this article.