Data-Flow-Based Extension of the System-Theoretic Process Analysis for Security (STPA-Sec)
11 Data-Flow-Based Extension of the System-TheoreticProcess Analysis for Security (STPA-Sec)
Jinghua Yu, Stefan Wagner,
Member IEEE, and Feng Luo
Abstract —Security analysis is an essential activity in secu-rity engineering to identify potential system vulnerabilities andachieve security requirements in the early design phases. Dueto the increasing complexity of modern systems, traditionalapproaches, which only consider component failures and simplecause-and-effect linkages, lack the power to identify insecureincidents caused by complex interactions among physical systems,human and social entities. By contrast, a top-down System-Theoretic Process Analysis for Security (STPA-Sec) approachviews losses as resulting from interactions, focuses on controllingsystem vulnerabilities instead of external threats and is applicablefor complex socio-technical systems. In this paper, we proposedan extension of STPA-Sec based on data flow structures toovercome STPA-Secs limitations and achieve security constraintsof information-critical systems systematically. We analyzed aBluetooth digital key system of a vehicle by using both theproposed and the original approach to investigate the relationshipand differences between both approaches as well as their appli-cability and highlights. To conclude, the proposed approach canidentify more information-related problems with technical detailsand be used with other STPA-based approaches to co-designsystems in multi-disciplines under the unified STPA processframework.
Index Terms —Security Analysis, Complex Interaction,Information-critical System, Data Flow Structure, STPA-Sec
I. I
NTRODUCTION S YSTEM security is an emergent property of the system,which represents a state or condition that is free fromasset loss and the resulting loss consequences. System securityengineering, as a special discipline of system engineering, co-ordinates and directs various engineering specialties to providea fully integrated, system-level perspective of system securityand helps to ensure the application of appropriate securityprinciples and methodologies during the system life cyclefor asset protection [1]. Violating system security constraintscauses unexpected incidents, like mission failure or leakingsensitive information, and finally leads to financial or even lifelosses. Therefore, security needs to be considered carefullyin system design. Security analysis, referring to the activityof analyzing systems in security-related aspects to achievesecurity requirements in this research, is performed in the early
J. Yu is with School of Automotive Studies, Tongji University, 201804Shanghai China (e-mail: [email protected]).S. Wagner is with Institute of Software Technology, University of Stuttgart,70569 Stuttgart, Germany (e-mail: [email protected])F. Luo is with the School of Automotive Studies, Tongji University, 201804Shanghai, China (e-mail: luo [email protected])This research was supported by the China Scholarship Council and funds ofthe German Federal Ministry of Education and Research under grant number16KIS0995.This version has been submitted to IEEE System Journal on 22 May 2020. security engineering phase and helps to manage system risksand make decisions.Traditional security analysis approaches, being designed forformer relatively simple systems, are not effective to ana-lyze increasingly complex systems. Today’s Cyber-PhysicalSystems (CPS) or Socio-Technical Systems (STS) consist ofnot only physical components but also software and evensocial elements, in which components in multi-disciplinesinteract with each other deeply. For example, an autonomousvehicle (as a CPS) consists of tens of thousands of physicalcomponents as well as lines of codes. A vehicle Over-The-Air(OTA) software update system (as an STS) refers to not onlythe technical part but also social entities like data providersand regulations. However, most traditional approaches startwith system decomposition and focus on component failures,which leads to overlooking impacts of interactions since com-ponents are analyzed individually. Traditional causality modelsattribute accidents to an initial component failure cascadingthrough a set of other components (like dominos) [2] and cannot address causes of losses with non-linear cause-and-effectlinkages.To meet the requirements of modern systems, a relativelynew approach for safety engineering called System-TheoreticProcess Analysis (STPA) was proposed [3] and the extensionfor security named STPA-Sec was presented later [4]. How-ever, we recognized some limitations of STPA-Sec when im-plementing it, especially for data-flow-based systems. There-fore, this research aims to work out an extended approachbased on the unified STPA process framework for complexinformation-critical systems to overcome the identified limita-tions of STPA-Sec.The rest of this paper is organized as follows. In sectionII, we introduce traditional approaches and the STPA serieswith research gaps and our contributions. In section III, weintroduce the original STPA-based approaches and proposethe extension in detail. In section IV, we present the analysisprocess of a use case by using both original and extendedapproaches to demonstrate how to use them and make thecomparison. Finally, we summary this paper in section V.II. R
ELATED W ORK
A. Traditional Security Analysis Approaches
The purpose of the security analysis in the early design stageis to achieve security requirements. The Threats Analysis andRisk Assessment (TARA) is normally the main activity in thesecurity analysis to identify potential threats and assess threatrisks [5]. The SAE (Society of Automotive Engineers) J3061 - a r X i v : . [ c s . CR ] J un Cybersecurity Guidebook for Cyber-physical Vehicle systems[5] provides a list of approaches, which contain completeprocess frameworks of TARA, like the EVITA approach [6]and TVRA [7]. Besides, techniques are proposed for onlythreat identification or risk assessment and can be used inthe previously mentioned TARA frameworks, including AttackTree Analysis (ATA) [8], STRIDE threat models [9], Threatand Operability Analysis (THROP) [5], Threat Matrix [10]and BDMP-based (Boolean logic Driven Markov Processes)Modelling [11] for threat identification, as well as Binary RiskAnalysis (BRA) [12] and NIST SP 800-30 Guide [13] forrisk assessment. Other than methods originally invented forsecurity, some approaches are evolved from the safety fieldby introducing security awareness into the process and supportthe co-analysis of both safety and security.Table I summarizes both original and evolved approacheswith brief introductions. They are all bottom-up approachesbuilding upon physical or functional decomposition instead ofanalyzing the system as a whole initially. They focus moreon the tactic level and may overlook issues at the strategylevel. The tactics are means to accomplish a specific actionand focused on physical threats, while the strategy is regardedas the art of gaining continuing advantages and is focusedon abstract outcomes [2]. The latter one is useful to broadenthe mind and includes more aspects like organizational andmanagerial ones in the analysis.
B. System-Theoretic Process Analysis (STPA) Approach andExtensions
To overcome the limitations of traditional approaches, STPAwas created as a hazard analysis approach based on theSystem-Theoretic Accident Model and Process (STAMP),which views losses as results from interactions among varioussystem roles that lead to violations of safety constraints andanalyzes issues at the strategy level. STPA provides a powerfulway to deal with complexity by using traceable hierarchicalabstraction and refinement [2].Other than safety engineering, STPA has also been extendedinto other fields with the same system-theoretic thought.Young and Leveson [4] firstly presented STPA for Security(STPA-Sec), which shares similar steps with STPA and fo-cuses on controlling system vulnerabilities instead of avoidingthreats. To perform co-analysis of safety and security underthe STPA framework better, Friedberg et al. [19] proposeda novel analysis methodology called STPA-SafeSec, whichintegrated STPA and STPA-Sec into one concise frameworkand overcomes limitations of original approaches (e.g. noconsiderations about non-safety security issues) by introducingsecurity constraints and mapping abstract control structuresto real components. Shapiro [20] proposed STPA for Privacy(STPA-Priv), which extends STPA into privacy engineeringby introducing privacy concepts and consideration into thegeneral STPA process steps.The most significant highlight of STPA-based approachesis that they shift from focusing on preventing failures andavoiding threats to enforcing safety constraints and controlsystem vulnerabilities. Identifying and controlling system vul-nerabilities rather than brainstorming and reacting to threats is a more efficient way to achieve system safety and security,because controlling a vulnerability may be effective to reduceseveral threats. Besides, threats are dynamic. Newly emergedthreats can not always be detected in time, but controllingvulnerabilities can protect the system against even unknownthreats, just like defending a castle by reinforcing walls and notcaring who is the enemy. Another highlight is that the STPA-based approaches are applicable for socio-technical systems,which are systems that consider requirements spanning hard-ware, software, personal, and community aspects [21]. Theanalysis scope of the STPA series includes not only physicalsystem components but also humans, natural or social envi-ronment and their interactions, which makes the approachesmore suitable for todays complex systems. Furthermore, dueto the numbers of extensions of STPA in various disciplines,it is easier to perform co-design with similar STPA frameworkand the same system model.
C. STPA-Sec Applications and Gaps
The STPA-Sec approach or its extensions have been usedto identify system security constraints in various industries.Khan, Madnick and Moulton [22] demonstrated the imple-mentation of STPA-Sec to identify security vulnerabilitiesof a use case (Central Utilities Plant Gas Turbine) in in-dustrial control systems. Carter [23] used STPA-Sec with aprevious information elicitation process to analyze a smallreconnaissance unmanned aerial vehicles. Sidhu [24] appliedan STPA-Sec extension with modified attack tree method toanalyze cybersecurity of autonomous mining systems. Wei andMadnick [25] analyzed a use case (Over-The-Air softwareupdate) in the automotive industry by using both STPA-Sec and CHASSIS and compared analysis outcomes, whichshowed that STPA-Sec can identify more hazards compared toCHASSIS, while CHASSIS is more suitable for informationlifecycle analysis.Nevertheless, researchers also pointed out several limita-tions of STPA-Sec. Schmittner, Ma and Puschner [26] reportedthat the original STPA-Sec lacks guidance for intended causalscenarios, excludes considerations of the data exchange whichis not directly connected to the process control and cannotcover more information-security centric properties such asconfidentiality. Torkildson, Li and Johnsen [27] also found thatsome essential security issues can be overlooked and recom-mended to strengthen STPA-Sec by combining it with data-flow-based threat models. However, Torkildson’s approachconverts the STPA control structure into a data flow diagramby simply replacing control actions and feedback paths withdata channels. Although such a data flow diagram helps toidentify more data-related threats than using STPA-Sec alone,this diagram based on the original control loop does not viewthe system from the data aspect initially and may also missdata-related information. Besides, the STPA-Sec approachregards the security issue as one of the key threats affectingsystem safety [25] and only supports the identification ofsafety-related security goals [28]. Non-safety-related securityissues like confidentiality may be overlooked.To sum up, existing STPA-Sec is not effective to identifynon-safety but information-related issues since it does not con-
TABLE IS
UMMARY OF T RADITIONAL S ECURITY A NALYSIS A PPROACHES
Type Approach Brief Introduction
Original Approaches withcomplete processframeworks E-Safety Vehicle Intrusion ProtectedApplications (EVITA) EVITA approach considers four security objectives (safety, privacy, financial,operational) and uses attacks trees to identify threats and assess risks [6].Threat, Vulnerabilities, and implementationRisks Analysis (TVRA) TVRA is a process-driven TARA approach to systematically identifyunwanted incidents which need to be avoided [7].Operationally Critical Threat, Asset, andVulnerability Evaluation (OCTAVE) OCTAVE is a process-driven TARA method which is best suited forenterprise information security risk assessments [14].HEAling Vulnerabilities to ENhanceSoftware Security and Safety (HEAVENS) HEAVENS is a systematic approach of deriving security requirements forvehicle E/E systems, including processes and tools supporting for TARA [15].Approaches evolved fromother disciplines andsupport co-analysis A Security-Aware Hazard and RiskAnalysis Method (SAHARA) SAHARA is a combined approach of the Hazard Analysis and RiskAssessment (HARA) with the STRIDE model and outlines the impacts ofsecurity issues on safety concepts [16].Failure Mode, Vulnerabilities and EffectsAnalysis (FMVEA) FMVEA is an approach evolved from the Failure Mode and Effect Analysis(FMEA) to identify vulnerability cause-effect chains for security [17].Combined Harm Assessment of Safety andSecurity (CHASSIS) CHASSIS is a unified process for safety and security by using UML-basedmodels (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 ofSTPA-Sec (named STPA-DFSec) with elicitation guide wordsto overcome STPA-Sec’s limitations. The analysis process ofa vehicle digital key system is presented to demonstrate howto use STPA-DFSec. We also analyze the same system byusing the original STPA-Sec and compare outcomes thoughsynthesis and mapping. Finally, we discover the relationshipbetween both approaches and conclude the highlights andapplicability of them.III. M
ETHODOLOGY
A. Brief Introduction of STPA and STPA-Sec
We briefly introduce the original STPA framework as thebasis of the proposed approach in this section.STPA starts with defining the purpose of the analysis,including system-level losses, hazards and constraints. Lossesare about something valuable and unacceptable to the stake-holders. A hazard is a system state or set of conditions that,together with a particular set of worst-case environmentalconditions, will lead to a loss. Finally, system constraints canbe derived from identified hazards, which specifies systemconditions or behaviors that need to be satisfied to preventhazards and ultimately prevent losses [3].Then, the control structure needs to be built to describerelationships and interactions by modelling the system as aset of control loops (show in Figure 1).The third step is to identify unsafe control actions, whichwill lead to a hazard in a particular context and worst-caseenvironment [3], based on the previously built structure. Fourways of being unsafe are provided in STPA as guide wordsfor the identification (listed in Table V).Finally, loss scenarios, which describe the causal factorsthat can lead to unsafe control actions, will be identified.Two types of loss scenarios must be considered, which arescenarios that lead to unsafe control actions and scenarios inwhich control actions are improperly executed or not executed
Fig. 1. General Control Loop [3] [3]. Each identified scenario represents a system failure whichneeds to be controlled by designers.STPA-Sec, as the extension for security considerations,shares the same basic steps. Vulnerabilities, instead of hazardsare identified in the first step since vulnerabilities lead tosecurity incidents, which is just like hazards lead to safetyincidents [4]. Similarly, final identified loss scenarios representsystem vulnerabilities which need to be controlled.
B. STPA-DFSec Approach
The proposed STPA-DFSec follows the general STPAframework but introduces a data-flow-based structure for infor-mation security considerations. The main steps are describedas follows.
1) Step 1 - Define the purpose of the analysis:
Just beingsimilar with the STPA-Sec, the first step of the analysis isto identify system-level losses, vulnerabilities and constraintsto figure out what are unacceptable results that need to beavoided at the system strategy level.General security attributes like Confidentiality, Integrityand Availability (C.I.A. Triad Model) are guide words forthe vulnerability identification, which classify the securityproblems and elicit potential vulnerabilities.Furthermore, to help to identify losses, STPA-DFSec pro-vides general guidance for loss identification based on thestudy of various safety- and security-related definitions fromstandards and technical documents in industries including ISO26262 [29], EVITA project report [6] and J3061 guideline [5].All possibilities of losses at a high abstract level are listed in
Table II. Losses of a particular case are a subset of this generallist and can be described concretely according to practicalsituations.
TABLE IIG
ENERAL L IST OF L OSSES
Label Loss Description
L-1 Loss of life or causeinjury to life Includes human and animal lifeL-2 Loss of physicalproperty Represents physical objects belongingto stakeholders (e.g. devices)L-3 Loss of non-physicalproperty Represents virtual properties belong-ing to stakeholders (e.g. sensitive in-formation, reputation)L-4 Loss of environment Includes the natural or artificial world
2) Step 2 - Model Functional Interaction Structure:
Insteadof the control structure, a Functional Interaction Structure(FIS) based on data flows is created to interpret how thesystem works from the perspective of data flows. The basicelement of the FIS is the Function, which works based on itsinputs and algorithms inside and outputs process results. Theprocessing environment, together with inputs and algorithms,will affect function behaviors and final outputs. Inputs andoutputs, instead of control actions and feedback, are interac-tions between components in FIS. Figure 2 shows a generalinteraction structure and the function element, in which arrowsrepresents data flows.
Function
Component BComponent A AlogrithmsFunctionInputs OutputsEnvironmentFunction A-1Function A-2 Function B-1Function B-2
General FIS
Fig. 2. General FIS and Element ’Function’
3) Step 3 - Identify Insecure Function Behaviors:
Based onthe FIS, we can identify Insecure Function Behaviors (IFB)for the target system by following the basic technique inSTPA. Insecure behaviors are identified with the help of GuideWords (GW), which are slightly modified to fit the proposedapproach. Table III is the template for identifying IFBs.
TABLE IIIT
EMPLATE FOR I DENTIFYING
IFB S Function(F) GW:
Not beingExecuted CausesVulnerabilities(NECV) GW: beingExecuted CausesVulnerabilities(ECV) GW:
TimingIssues (TI) S F n S F n IFB m S F n IFB m S F n IFB m Notes: Represents that the function is not executed successfully. Represents that the function is executed with improper conditions(e.g. incorrect inputs or algorithms, process with data leakage risks). Represents that the execution exceeds the timing limits. S F n IFB m is the label of each IFB, in which S represents thesubject of the function.
4) Step 4 - Identify Loss Scenarios:
Finally, Loss Scenarios(LS), as possible causes of IFBs, are identified by usingoptimized guide words. Table IV is the template for identifyingLSs with two classes of guide words. The Function itself classhelps to identify scenarios caused by unexpected behaviorsinside the function, while the Execution environment (Env)class refers to external conditions outside.
TABLE IVT
EMPLATE FOR I DENTIFYING LS S IFBs GW:
FunctionItself
GW:
Env-FunctionInputs
GW:
Env-CallingBehaviors
GW:
Env-ComputingResources
GW:
Env-LinksS F n IFB m S F n IFB m LS p S F n IFB m LS p S F n IFB m LS p S F n IFB m LS p S F n IFB m LS p Each loss scenario represents a system vulnerability whichshould be controlled by designers or operators. Detailed sys-tem constraints can also be derived from loss scenarios bysimply inversing the conditions of loss scenarios or definingwhat the system must do in case the incident occurs [3].System constraints are inputs of further design phases.
C. Summary
Table V summarizes the process steps of both STPA-DFSecand STPA-Sec with highlights of differences, in which ’+’donates added features of the STPA-DFSec and ’* representsmodified steps in comparison with the original STPA-Sec.IV. C
ASE S TUDY
A. Use Case Definition and Assumption
In this section, a Bluetooth digital key system of a vehicleis introduced as the target system in this research. The systemconsists of three main physical components and aims to lock orunlock vehicle doors by using smartphones. Communicationbetween different entities are through wireless channels andprotected by cryptographic mechanisms. The system sketchand sequence diagram of two main services are shown inFigure 3 to describe how this system works.In this example case, we assume that the connectionsbetween components have been established via Wi-Fi orBluetooth in advance, but the connection is not ensured to besecure, and the prerequisites in Figure 3 are regarded trusted.In this research, we only focus on security issues, which meansthat the system can work properly without intended externaldisturbances and the system development errors and hardwarerandom failures are out of scope.
B. Analysis by STPA-DFSec
The analysis of the target system by using STPA-DFSecis presented in this section. First, system-level Losses (L),Vulnerabilities (V) with linked losses and security attributesand derived System Constraints (SC) are listed in Table VI.Second, the functional interaction structure is created inFigure 4 based on the system data flows. Two functions withidentified IFBs are shown in Table VII as examples. In contrast
TABLE VS
UMMARY OF
STPA-DFS
EC AND
STPA-S EC S TEPS
Basic Four Steps STPA-DFSec Details STPA-Sec Details
Step 1 - Define the pur-pose of the analysis Identify system-level losses, vulnerabilities andconstraints, link vulnerabilities with corre-sponding losses and security attributes + . Ageneral losses list is provided + . Identify system-level losses, vulnerabilitiesand constraints.Step 2 - Model the sys-tem structure Model the system by functional interactionstructure based on data flows ∗ . Model the system by functional control struc-ture based on control loops.Step 3 - Identify inse-cure items Use modified guide words ∗ (not being exe-cuted, being executed and timing issues) toidentify insecure function behaviors. Use guide words (not providing, providing,too early, too late, out of order, stopped toosoon, applied too long) to identify insecurecontrol actions.Step 4 - Identify lossscenarios Use modified guide words ∗ (function itself, ex-ecution environment(incl. function inputs, call-ing behaviors, computing resources and links)to identify loss scenarios. Use guide words (unsafe controller behavior,inadequate feedback and information, involv-ing the control path, related to the controlledprocess) to identify loss scenarios. System Sketch Sequence Diagram prerequisiteslock or unlock doorsuser register or login
User Smart Phone Cloud Server Door Controller register or login send register or login datapk_u, sk_u and pk_s are prepared pk_s, sk_s and vehicle order records are prepared pk_d, sk_d and pk_s are preparedverify and execute register or login based on the vehicle order records m = D(sk_s, c) register or login result c = E(pk_u, result) register or login resultlock/unlock doors request a session key s_u = S(cmd+UID_v)c = E(pk_s, UID_v + s_u) verify signature,generate a session key for the communicationresponse the session key c = E(pk_u, k_se+UID_v) c = E(pk_d, k_se+ID_u) D(sk_d, c)D(sk_u, c) get the session keysend lock/unlock command c = E_sym(k_se, cmd) D_sym(k_se, c) get and execute command result = D(sk_u, E(pk_u, c) get register result
V(s_u)m = D(sk_s, c)k_se = process_2(m)c = E(pk_s, pk_u + ID_u + pw_u / ID_u + pw_u) result = process_1(m)
Notations pk_u, pk_s, pk_dsk_u, sk_s, sk_dE(pk, m)D(sk, c)E_sym(k, m)D_sym(k, c)S(m)V(s)process_1/2(m)k_seID_upw_uUID_vcmdmcs Public key of the user, cloud server and door controllerSecret key of the user, cloud server and door controllerAsymmetric encryption functionAsymmetric decryption functionSymmetric encryption functionSymmetric decryption functionSignature function Signature verification function Data process functionSession key for the symmetric communicationUser IDUser passwordUnique ID of the vehicleLock or unlock commandPlain textCipher textSignature assign the session key get the session keyDoor Controllerin the Vehicle Smartphone(User)Cloud Server
Fig. 3. Sequence Diagram of the System to most traditional approaches, this analysis includes partic-ipants (user and manufacturer) outside the physical systemboundary. Functions in a human operator can also be refinedinto more detailed movements like ’decision in the mind’,’pressing button’ or ’recording password’. Since we focuson the physical part in this analysis, human movements aresimplified as one human operation function. Note that thefirst letter of the IFB labels in Table VII represents systemcomponents including smartphone (P), cloud server (S), doorcontroller (D), user (U) and manufacturer (M).Finally, LSs are identified for each IFB. Example LSs withrelated guide words in the bracket are listed in Table VIII.Note that the IFBs and LSs of various subjects are merged tomake the list concise since different system components may contain the same functions and different insecure behaviorsmay have the same causalities. In practice, it is also mean-ingful to describe each function or LS separately to achievesecurity constraints for corresponding engineers, who mightonly have access to a part of design information due to securityreasons.
C. Analysis by STPA-Sec
We also analyzed this use case by STPA-Sec. Due to thesame system model, the identified losses, hazards and systemconstraints are the same as those in the STPA-DFSec analysis.Therefore, the work here starts with drawing the systemcontrol structure shown in Figure 5, and then Insecure Control
TABLE VIL
OSSES , V
ULNERABILITIES AND C ONSTRAINTS OF THE U SE C ASE
L-1: Loss of physical property (The vehicle and properties in it)L-2: Loss of non-physical property (Manufacturers reputation)V-1: Fail to lock the vehicle without being detected. [L-1/2, Integrity]V-2: Fail to lock or unlock the vehicle, which can be detected by theuser. [L-2, Availability]V-3: Leak sensitive information. [L-1/2, Confidentiality]SC-1: Missions should be completed successfully. [V-1/2]SC-2: If the mission fails, it must be detected by the user. [V-1]SC-3: Sensitive information should be protected from leaking. [V-3]SC-4: If sensitive information is leaked, it should be detected andreactions need to be taken to minimize losses. [V-3]
Smartphone (P)Cloud Server (S) Door Controller (D)encrypt by pk_stransmit to cloud decrypt by sk_ddecrypt by k_sessionencrypt by pk_dencrypt by pk_u decrypt by sk_sverify user’s signaturetransmit to user encrypt by pk_sdecrypt by sk_u calculate user’s signaturetransmit to cloudencrypt by k_sessionplain data process plain data process plain data processtransmit to vehicletransmit to vehicle I/O signal
Main data flows from the smartphone, cloud server and door controllerOptional data flows from the smartphoneData flows from operators
Manufacturer (M)human operationUser (U)human operation
Fig. 4. Functional Interaction Structure based on Data FlowsTABLE VIII
DENTIFIED I NSECURE F UNCTION B EHAVIORS
F GW:
NECV
GW:
ECV
GW:
TIP/S/D F2: Datatransmission P/S/D F2IFB1 P/S/D F2IFB2 P/S/D F2IFB3U/M F7: humanoperation / U/M F7 IFB1,U/M F7 IFB2 /
IFB Description:
P/S/D F2 IFB1: The required data fails to be transmitted. [V-1/2]P/S/D F2 IFB2: The data is attacked (e.g. eavesdrop, tamper)during the transmission. [V-1/2/3]P/S/D F2 IFB3: Function execution violates the timing limits. [V-2]U/M F7 IFB1: The invalid entity operates with valid data. [V-1/2]U/M F7 IFB2: The valid entity operates with invalid orincorrect data. [V-1/2]
Actions (ICA) are identified. ICAs of example Control Actions(CA) are shown Table IX, in which the first letter of the labelrepresents the control action’s controller.Finally, loss scenarios of each ICAs are identified. Someexample LSs are shown in Table X.
D. Outcome Comparison
The functions and control actions are basic elements in theSTPA-DFSec and STPA-Sec respectively. Normally, a controlaction includes several functions to provide a service. Forexample, the control action D CA1 (Door controller registersat the server) consists of functions of data process, transmision,
TABLE VIIIL
OSS S CENARIOS OF
IFB S IFBs GW:
FunctionItself
GW:
EnvironmentP/S/D F2 IFB3 P/S/D F2 IFB3 LS1 P/S/D F2 IFB3 LS2,P/S/D F2 IFB3 LS3,P/S/D F2 IFB3 LS4U/M F7 IFB2 U/M F7 IFB2 LS1 /
LS Description:
P/S/D F2 IFB3 LS1: The function algorithm is modified tocause corresponding insecure function behaviors.P/S/D F2 IFB3 LS2: The input data size is modified, whichrequires more time to compute. (Env -Function Inputs)P/S/D F2 IFB3 LS3: Computing resource is occupied to causeviolation of execution timing limitations. (Env -Computing Resources)P/S/D F2 IFB3 LS4: Transmission is slowed down by additionalmechanisms on links (e.g. additional switches). (Env -Links)U/M F7 IFB2 LS1: The valid entity is fooled intendedly to useinvalid or incorrect data.
Smartphone (P) Door Controller (D) output (un)lock signal(un)lock doorsCloud Server (S)register or login, request a session key register or login result, responsed session key assign a session keyUser (U)register, login,(un)lock doors register or login result Manufacturer (M)register register resultregister register result control actionsfeedbackoutputs execution feedback key assignment feedback
Fig. 5. Control Structure of the SystemTABLE IXI
DENTIFIED I NSECURE C ONTROL A CTIONS
CA GW:
NotProviding
GW:
Providing
GW:
TimingIssues D CA1: Register D CA1 ICA1 D CA1 ICA2 D CA1 ICA3U CA2: Lock orunlock doors / U CA2 ICA1 /
ICA Description:
D CA1 ICA1: The door controller fails to register at the server. [V-2]D CA1 ICA2: The door controller registers with data leakage risks.(e.g. UID, public key leakage). [V-3]D CA1 ICA3: The action violates the timing limits. [V-1]U CA2 ICA1: The user is fooled to send wrong commands. [V-1/2]
Notes: : Two GWs about timing in STPA-Sec are merged as timing issues. encryption and decryption. Therefore, the relationship betweenthese two elements is that a sequence of the execution offunctions forms a control action.To find out how different approaches work on the same usecase, we mapped the analysis outcomes in both analyses. Forexample, D CA1 ICA3 LS1 and D CA1 ICA3 LS3 in theSTPA-Sec analysis can be mapped to P/S/D F2 IFB3 LS1.U CA2 ICA1 LS1 and U CA2 ICA1 LS2 can be mappedto U F7 IFB2 LS1. After performing the mapping for allanalysis outcomes, we found that each loss scenario in theSTPA-Sec analysis can be mapped to a corresponding onein the STPA-DFSec analysis from the perspective of data TABLE XL
OSS S CENARIOS OF
ICA S ICAs GW:
Controller
GW:
ControllerPath
GW:
ControlledProcess
GW:
FeedbackPathD CA1ICA3 D CA1ICA3 LS1 D CA1ICA3 LS2 D CA1ICA3 LS3U CA2ICA1 / / U CA2ICA1 LS1 U CA2ICA1 LS2
LS Description:
D CA1 ICA3 LS1: The algorithm at the controller is tampered,which requires more calculating time.D CA1 ICA3 LS2: The link is modified to slow down thedata transmission.D CA1 ICA3 LS3: The algorithm at the controlled process istampered, which requires more calculating time.U CA2 ICA1 LS1: The user interface of the smartphone ismodified to guide the user to send wrong commands.U CA2 ICA1 LS2: The vehicle state is presented wrongly,which leads to the users wrong behaviors. process, which means that the proposed approach can find allpossibilities identified by the original approach. Furthermore,more loss scenarios can be identified in the STPA-DFSecanalysis. For example, the scenario ’Computing resource isoccupied to cause violation of execution timing limitations.’(P/S/D F2 IFB3 LS3 in Table VIII) cannot be identified bythe STPA-Sec. Therefore, more technical details related to thedata process can be revealed by the data-flow-based analysis.Another finding is that an STPA-DFSec loss scenario canbe mapped to several STPA-Sec ones because a function isalways called by various control actions for different applica-tions. This explains why STPA-Sec can reveal more detailedinformation from the perspective of applications.
E. Discussion
After the comparison, we concluded the differences andhighlights of both approaches. The STPA-DFSec focuses oninformation flows and discusses possible vulnerabilities alongthe whole data flow paths, which helps to identify moredetailed loss scenarios from the perspective of informationflows. By contrast, since control actions in STPA-Sec arederived from system functionalities, STPA-Sec can revealmore insecure details linked to concrete application scenarios.STPA-DFSec addresses where (in which function) a lossscenario occurs, while STPA-Sec addresses when (in whichapplication scenario) a loss scenario occurs.Since both approaches have different advantages, how tochoose an approach depends on particular cases. Two princi-ples can be used to help the decision. The first one is accordingto system purposes. If the data is the core asset in a system,STPA-DFSec is suitable for analysis insecure issues with moreconsiderations on the information. If providing proper andsecure services is the main object of a system, STPA-Sec isapplicable to identify insecure issues linking with applicationscenarios. The second principle is to consider who uses it.STPA-DFSec is suitable for designers who are responsible fortechnical structure and design, while STPA-Sec is more useful for ones who design the system functionalities and make morehigh-level decisions.Actually, system security engineering is not able to ensureabsolute security but provides a sufficient base of evidencethat supports claims that the expected level of trustworthinesshas been achieved [1]. The analysis in security engineeringis also not able to be proven complete, and the analysisresults normally depend on the analyst’s knowledge and designemphasis. However, a proper systematic approach can help theanalyst to be more confident in the analysis completeness [2].Proper guide words help to reduce the dependency on personalexperience and subjective thinking and lead to objective andvalid results with less effort. Although the case study in thispaper represents the authors’ understanding of the system, theanalysis results are comparable and meaningful because bothanalyses were performed by the same group of analysts.V. C
ONCLUSION
In this paper, we have proposed a data-flow-based approachfor security analysis of information-critical systems based onthe STPA framework to overcome STPA-Sec’s limitations.The analyses of a vehicle digital key system by using boththe STPA-DFSec and STPA-Sec have been presented andcompared to show how to use the approaches and how wellboth approaches work on the same use case.We have found that the proposed STPA-DFSec focuseson data flows and can reveal more details in informationsecurity aspects, which are hard to be addressed in the STPA-Sec analysis, while the STPA-Sec analyzes systems from theperspective of applications and more concerns safety-relatedsecurity issues. Besides, since STPA-based approaches werecreated for high-level decisions rather than tactical details [2],the proposed STPA-DFSec extends considerations into lowerlevels with technical details. Furthermore, as an extension ofthe STPA series, the proposed approach, together with otherSTPA-based approaches, can be used to co-design complexsystems in multi-disciplines from high to low system levelsunder the unified STPA framework. Social aspects and humanfactors can be included in the analysis, which are excluded intraditional analysis approaches.In the future, we will study more industry cases and conductexperiments with different groups of analysts to validate andrefine the proposed approach in practices since we performedboth analyses in this paper, which might influence the validityof analysis outcomes. Furthermore, we will formalize theanalysis process and design tools to achieve analysis resultsautomatically for higher working efficiency.R
EFERENCES[1] R. Ross, M. McEvilley, and J. Oren, “Nist special publication 800-160:Systems security engineering considerations for a multidisciplinary ap-proach in the engineering of trustworthy secure systems,”
Gaithersburg:National Institute of Standards and Technology , 2016.[2] W. Young and N. Leveson, “Inside risks-an integrated approach to safetyand security based on system theory: Applying a more powerful newsafety methodology to security risks,”
Communications of the ACM ,vol. 57, no. 2, pp. 232–242, 2014.[3] N. Leveson and J. Thomas, “Stpa handbook (2018),” 2019. [4] W. Young and N. Leveson, “Systems thinking for safety and security,”in
Proceedings of the 29th Annual Computer Security ApplicationsConference , 2013, pp. 1–8.[5] SAE, “J3061: cybersecurity guidebook for cyber-physical vehicle sys-tems,” Nr , vol. 1, p. 52, 2016.[6] A. Ruddle, D. Ward, B. Weyl, S. Idrees, Y. Roudier, M. Friedewald,T. Leimbach, A. Fuchs, S. G¨urgens, O. Henniger et al. , “Securityrequirements for automotive on-board networks based on dark-sidescenarios,” EVITA Deliverable D , vol. 2, no. 3, 2009.[7] T. ETSI, “102 165-1: Cyber methods and protocols. part 1: Method andpro forma for threat, vulnerability,”
Risk Analysis (TVRA). TechnicalSpecification. 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 potentialsecurity threats in modern automobiles: A composite modeling ap-proach,” United States. National Highway Traffic Safety Administration,Tech. Rep., 2014.[11] L. Pi`etre-Cambac´ed`es and M. Bouissou, “Modeling safety and securityinterdependencies with bdmp (boolean logic driven markov processes),”in . IEEE, 2010, pp. 2852–2861.[12] B. Sapiro,
Binary Risk Analysis , 2011. [Online]. Available: https://binary.protect.io/ .IEEE, 2015, pp. 621–624.[17] C. Schmittner, T. Gruber, P. Puschner, and E. Schoitsch, “Securityapplication of failure mode and effect analysis (fmea),” in
InternationalConference 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,2017.[20] S. S. Shapiro, “Privacy risk analysis based on system control structures:Adapting system-theoretic process analysis for privacy engineering,” in
Cybersafety Analysis of a CentralUtilities Plant (CUP) Gas Turbine using STPA-SEC , 2018.[23] B. T. Carter, G. Bakirtzis, C. R. Elks, and C. H. Fleming, “A systemsapproach for eliciting mission-centric security requirements,” in . IEEE, 2018,pp. 1–8.[24] A. S. Sidhu, “Application of stpa-sec for analyzing cybersecurity ofautonomous mining systems,” Ph.D. dissertation, Massachusetts Instituteof Technology, 2018.[25] L. C. Wei and S. Madnick,
A System Theoretic Approach to Cybersecu-rity Risk Analysis and Mitigation for Autonomous Passenger Vehicles ,2018.[26] C. Schmittner, Z. Ma, and P. Puschner, “Limitation and improvement ofstpa-sec for safety and security co-analysis,” in
International Conferenceon Computer Safety, Reliability, and Security . Springer, 2016, pp. 195–209. [27] E. N. Torkildson, J. Li, and S. O. Johnsen, “Improving security andsafety co-analysis of stpa,” in
Proceedings of the 29th European Safetyand Reliability Conference (ESREL). 22–26 September 2019 Hannover,Germany . Research Publishing Services, 2019.[28] H. Martin, R. Bramberger, C. Schmittner, Z. Ma, T. Gruber, A. Ruiz,and G. Macher, “Safety and security co-engineering and argumentationframework,” in
International Conference on Computer Safety, Reliabil-ity, and Security . Springer, 2017, pp. 286–297.[29]