A Model-Based Approach to Security Analysis for Cyber-Physical Systems

A Model-Based Approac h to Secur ity Anal y sis f or Cyber -Ph y sical Sy stems Georgios Bakir tzis, ∗ † ‡ Bryan T . Car ter , † § Carl R. Elks, ∗ ¶ and Cody H. Fleming † ‖ ∗ Dependable Cyber -Phy sical Sy stems Lab, Electrical & Computer Engineer ing, VCU , Richmond, V A USA † Coordinated Systems Lab, Systems & Information Engineer ing, UV A, Charlottesville, V A US A ‡ bakirtzisg@ieee.org § bcarter@virginia.edu ¶ crelks@vcu.edu ‖ fleming@virginia.edu Abstract —Evaluating the secur ity of cyber-ph ysical systems throughout their life cy cle is necessar y to assure that they can be deploy ed and operated in safety-critical applications, such as infrastructure, militar y , and transport ation. Most safety and security decisions that can hav e major effects on mitigation strategy options after deployment are made early in the system’ s life cy cle. T o allow for a vulnerability analysis befor e deployment, a sufficient w ell-formed model has to be constructed. T o construct such a model we produce a taxonomy of attributes; that is, a generalized schema for system attr ibutes. This schema captures the necessary specificity that characterizes a possible real system and can also map to the att ack vector space associated with the model’s attributes. In this way , w e can match possible attack vectors and pro vide architectural mitigation at the design phase. W e present a model of a flight control system encoded in the Systems Modeling Language, commonly known as SysML, but also show agnosticism with respect to the modeling language or tool used. I. I N TR OD U CT IO N A major challenge in Cyber -Physical Systems (CPS) [1] is the assessment of t he system’ s secur ity posture at the early stages of its life cycle. In t he def ense community , it has been estimated that 70-80% of the decisions affecting safe ty and security are made in the early concept development stages of a project [2]–[5]. Theref ore, it is advantageous for this assessment to t ak e place bef ore lines of code are wr itten and designs are finalized. T o allow for secur ity anal ysis at the design phase, a system model has to be constr ucted, and that model must reasonably characterize a sys tem and be sufficiently det ailed to enable matching attack v ectors mined from dat abases. Matching possible attack vectors to the system model facilitates detection of possible secur ity vulnerabilities in timely f ashion. One can then design systems that are secure by design instead of potentially ha ving to add bolt-on security f eatures later in the process, an approach that can be prohibitivel y expensiv e and limited in its mitigation options. Consequentl y , emplo ying a model reduces costs and highlights the impor tance of secur ity as part of the design process of CPS. W e propose a model encoded in the Systems Modeling Language (SysML), a graphical object oriented modeling language [6]. Our justification f or using a solution based on SysML is tw of old: it facilitates the implementation of any changes to This research is based upon work suppor ted by the Systems Engineer ing Researc h Center under A ward No. 2017-RT -172. the design of CPS and is a tool f amiliar to and often used by systems engineers. How ev er , as we do not want to limit the core ideas to SysML, we show t hat t he model is transformable to a graph str ucture, thus demonstrating t hat it is agnostic to the particular modeling language or tool used. T o accurately characterize the system with respect to its associated secur ity audit, the model requires a taxonomic scheme consisting of predefined categor ies. This schema is necessary to descr ibe a potentially realizable or realized system. By extension the model, then, represents a r eal system without necessarily requiring one to be built. To develop this schema, we in vestigate attack vect or dat abases and examine their entries and their intra and inter connections. T o represent the reality of the system, t he chosen categories and their corresponding attributes need to cor rectly capture the hardware and software elements controlling the CPS as well as the interactions in the system model. The categor ies must be chosen in such a wa y that t he model has sufficient fidelity and can be used to find attack vectors from open databases. Since t he model drives t he vulnerability analy sis, it needs to reflect relev ant cyber-oriented information required to match possible attack vectors within the aforementioned categories. This additional inf or mation is encoded in the attributes of a subsystem and normally comes from preexisting design documentation, subject matter expertise, and requirements documentation. The amount and lev el of specificity that needs to be embodied in t he attr ibutes of each component depends on whether it matches the natural language that describes the attack vect ors within the vulnerability databases. Theref ore, the attributes need to represent t he system’ s hardw are and software composition so t hat they match possible entr ies in the databases. Onl y then can a system model become att ac kable, enabling us to infer possible vulnerabilities in the system’ s architecture and propose preemption and mitigation strategies. Construction of a model with the characteristics descr ibed abov e giv es rise to tw o main challeng es. The first is t he com- plexity in creating a complete schema that is able to capture— through the attr ibutes—the necessar y detail to represent the cyber aspects of an actual system. This first challeng e also needs to take into account the impor tance of reasonably allowing the maintenance of an y giv en CPS model that contains both cyber attributes and non-cyber attributes. The second is t he difficulty in coordinating the av ailable vulnerability data, the hierarc hy within the databases that contain that data, and finally , the wa y 978-1-5386-3664-0/18/$31.00 © 2018 IEEE Both unrealistic and insu ffi cient in detail to provide attack vector results Insu ffi cient detail to provide attack vector results Unrealistic—not repr esentative of the actual system—model Increases modeling e ff ort and complexity (ideal but possibly prohibitive) Low High High Low Number of Attributes Specificity of Attributes Fig. 1. The fidelity of the attributes describing a CPS has to achieve a balance between the amount of information that is captured in the model and the difficulty of producing it. At the extremes, the attributes can either be uninf ormative and incomplete or too detailed, requiring a prohibitive amount of modeling effor t. Part of the challenge to being model sufficient is producing a sound, well-f ormed model for vulnerability assessment that can be practically utilized by systems engineers. in which t he information is captured in their entr ies. A. The Challeng e of Captur ing a Sufficient Set of Attributes Indeed, there are tradeoffs between specificity and the number of attributes we can impose on a modeling methodology bef ore it becomes impr actical. This tradeoff can be illustrated by considering the extremities of model fidelity (Fig. 1). On the one side of the spectr um (Low -Low) the model does not cor rectl y characterize an actual system and its potential vulnerability to existing threats, while on the other side of the spectrum (High-High) the model requires a prohibitive amount of modeling effort. Being model-dr iv en in the context of cybersecurity has an additional requirement bey ond ensuring fidelity to the real system. It also requires integ rating the attributes taken from a design specification documentation, such that an analys t can match possible attack patterns to the model. This challeng e is partially solv ed by understanding and using several repositories of attacks and vulnerabilities (Section V). How ev er, it still does not guarantee that possible query words—w ord lists that are used to associate potential vulnerabilities with a given set of attributes—will produce attack vectors applicable to that subsystem. Theref ore, we need to capture the design documentation only to a point where there is ag reement between tw o perspectiv es; (i) fidelity to the system’ s beha vior and structure and (ii) the sys tem’ s cor responding attack vectors. B. Challeng e of Understanding Diverse V ulnerability Data Unf ortunately , there is no single repository that cont ains all possible exploitation techniques or vulnerabilities that can apply to complex systems like CPS. If there was one, it would ha ve to span across sev eral domains—e.g., embedded devices, netw orks, humans in the loop—and hav e multiple lev els of specificity for each entr y in order to match e very element in the system model. W e lev erage se veral dat abases wit h the goal of addressing all domains and at different levels of specificity , thus leading to new insights about the system’ s secur ity posture. W e then need to understand the different possible repositories, what inf or mation they contain, how they capture that information in natural language and what the t ar geted scope of each dat abase is. By gaining that understanding, we extend the schema to incorporate data from diverse resources and ensure a thorough and r igorous secur ity assessment. Finally , the level of abstraction of each repository has to match the attributes in t he model. At the very least, this requires a dat abase that matches the attr ibutes in the model. Ideally , how ev er, t here would be several databases that provide lay ers of abstraction. This is the case wit h a set of databases that are hierarchical and interconnected, e.g., CAPEC, 1 CWE, 2 CVE. 3 For this set of databases, CVE can match to the model attributes (since its vulnerability entr ies resides at a lo wer lev el of abstraction than the other tw o) and then be used to inf er possible classes of att ac k s by mapping CVE entr ies to their cor responding, higher-le vel, CWE and/or CAPEC entries. The utility of t his hierarch y is also impor tant when reasoning about the threat space associated wit h t he system. By abstracting the individual exploited vulnerabilities to more general weaknesses and/or patterns, this approach reduces the amount of information an analys t has to parse and reason with when they inspect a complex sys tem model for applicable attacks. C. State of the Art Model-based techniques for assessing cybersecurity hav e been at the for efront of recent researc h in CPS. These traditionally stem from dependability and saf ety analysis. Nicol et al. [7] ha ve stated the need f or model-based methods f or assessing security that come from the general area of dependability . Fur ther , Chen et al. [8] ha ve proposed a model- based graph oriented anal ysis techniq ue f or assessing a system f or accept able saf ety based on a w orkflow . Kopetz [9] presents the notion of categor ies of inter f aces to model real-time systems. Da vis et al. [10] present a framew ork that extends the notion of dependability to include possible secur ity violation f or the pow er grid that utilizes state estimation and is ev aluated in a simulated model of the po wer grid. More recentl y , Br unner et al. [11] proposed a combined model for saf ety and secur ity that is based on U nified Modeling Language (UML) diagrams. These models reside in a higher lev el of abstraction than 1 Common Attack Pattern Enumeration & Classification, capec.mitre.org 2 Common W eakness Enumeration, cwe.mitre.org 3 Common V ulnerabilities and Exposures, cve.mitre.or g our proposed model; they do not contain t he structure of the system, do not consider evidence-based secur ity assessment, assessment based on previous reported vulnerability data, and the e valuation t arg ets cer tification of policy standards. In general, little wor k has been done to deter mine whether a model contains t he necessar y attributes stemming from t he design documents and encoded through a structural model to be used in evidence-based cyber -vulnerability assessment. Even less work has been done in t ar ge ting t he model sufficiency of CPS and how that is used at t he early stages of the design process. For the cybersecurity assessment of CPS, no standard rule-of-t humb, or otherwise generall y accepted procedure has been established. D. Contributions of this Researc h The central contr ibution of this paper is the char acterization and definition of the problem of ag reement betw een system model and historic att ac k vector dat abases and t ac kling the difficulty of matching t he tw o when it comes to CPS. Theref ore, this research presents solutions to the two main challenges outlined abov e. First, it show s how to capture the relevant inf or mation within those schema categor ies based on design documentation t hat pree xists the model. Second, it demonstrates how to appropriately handle historic dat a to identify possible vulnerabilities in the sys tem’ s design. Both challeng es can be solved by methodically constructing a model through a predefined taxonomic scheme. T ow ard those objectives, t he model is built based on t he follo wing insights: 1) a necessar y understanding of historic information is needed to match against a system descr iption; 2) a sy stem description needs to be e valuated as being realistic and it is characterized by attr ibutes to an extent that can match possible attack vectors; and 3) agnos ticism tow ard modeling language or tool. This paper f ocuses on model sufficiency with respect to vulnerabilities, with the explicit recognition that these vulnerabilities can give rise to unsafe or undesired beha vior in the over all, coupled CPS. Moreov er, this paper demonstrates how vulnerabilities propagate to physical system beha vior but it is outside the defined scope to analyze t he physical behavior and/or deter mine whether it is (un)saf e or (un)desirable. T o assess t he sufficiency of the model we present a model of a generic Flight Control System (FCS) and assess the possible secur ity violations of tw o system components using open vulnerability databases. II . A T AXO NO M IC S CH E M E FO R C P S A T TR IB U TE S Our main objective is to constr uct a general pur pose taxonomic scheme that can be used to characterize the cyber components of a CPS and t heir interactions, for t he purpose of relating to attack v ectors. To t his end, we use preexisting design specification document ation to descr ibe the attributes of t he cyber components and encode this inf or mation in the model. T o methodically achie ve t his we first present definitions f or cyber component, attack vector , cyber attr ibute, evidence, and t ax onomic scheme. These definitions pro vide common ground on the relatively gener ic term “cyber, ” which is used in se veral contexts and, therefore, can hold different meanings. A. Pr imitiv es Our model of CPS makes a distinction between cyber and physical components. Caution is necessar y because the components of a CPS can reside in between the cyber and phy sical realms but their beha vior and f or m can be descr ibed by either . This paper is intended onl y to identify t he minimum set of attr ibutes necessar y to assess a CPS’ s cybersecurity posture. Definition 1. A C YB E R CO M PO N E NT of a cyber-ph ysical system is any device that is programmable and whose associated computation obser v es or controls physical quantities, e.g., velocity , altitude, etc. Definition 2. An A TTAC K V E CT OR is a specific descr iption of an att ac k on a giv en subsystem. It presents t he features of the exploited vulnerability , the privilege access lev el required for an att ac ker to perform the att ac k , and t he steps to perform it. Definition 3. A C YB ER ATT R IB UT E defining a subsys tem of a cyber-ph ysical system represents possible specification of beha vior, form, or structure. Hence, t he set of attr ibutes produce an architectural definition of t he subsystem and represent the part(s) of t he model that maps to possible attack vectors. Definition 4. E VI DE N CE is all instances of historic vulnera- bility data—att ac k vectors—that can be mapped to a cyber component through any cyber attribute or a combination of cyber attr ibutes. Definition 5. A TAXO NO M IC S C HE M E , or schema, is a discrete set of c ategories that can capture the structure of any cyber component in a cyber-ph ysical sys tem to produce evidence. Follo wing the above definitions, the tax onomic scheme should inform the follo wing questions: 1) What is the subsystem? 2) How is it implemented? 3) Who does it talk to? 4) Why is it there? The first question informs the model about the identity of the subsystem. The second question provides the design details, used by the model to characterize a possible real subsystem. The t hird question identifies the required interactions betw een the subsystem, ensur ing that the composition of t he full system can provide its expected ser vice—an impor tant aspect of CPS as indicated throughout the literature [12]. The f our th and last question addresses t he function of the subsystem and, therefore inf or ms about its relative cr iticality to the ov erall behavior of CPS. Answering the abo ve questions sufficientl y and constr ucting a t ax onomic scheme directed by them allo ws us to base our analy sis in methodical reasoning. Further more, by utilizing methodical reasoning we are able to view t he threat spaces of a system holistically and t ak e into account that a single segregated component acts differently t han when it coordinates with other subsystems to compose a CPS. By using this approach, one is better informed about t he ov erall system secur ity posture than by analyzing just the system’ s components individually . B. Realization of the T axonomic Scheme Using the abov e questions as a guide and being aw are of t he intrinsic str ucture and specificity contained in open vulnerability databases, t he follo wing tax onomic scheme composes t he structure of any CPS and can assist in producing evidence: ∙ Operating System. Since CPS is composed of hardware and software, it is impor tant to be aw are of the system software hosted, such as Real- Time Operating Systems (RT OS), ex ecutives, debuggers. In some cases, t he em- bedded devices may be programmed without an operating system, a common term f or which is “programmed on bare metal. ” Knowing t his information—that is, CPS r unning an embedded operating system—inf orms on possible vulnerabilities, e.g., bugs in the Linux kernel. ∙ Device Name. The specific naming of a subsystem can assist in finding device-specific vulnerabilities. ∙ Hardwar e. The decomposition of t he specific device to its possible e xploit able hardware elements, e.g., what chipset is on board. ∙ Firmw are. The possible firmware and cor responding drivers necessar y to run the de vice. ∙ Softwar e. In t he ev ent that the subsys tem r uns an RTOS it is of impor tance to kno w the possible software that is installed and can potentiall y introduce furt her vulnerabili- ties. ∙ Communication. Any cyber or physical interaction the CPS must implement in to provide its expected ser vice. ∙ Entry Points. All possible accessible entr y points to t he system. This attr ibute allow s us to filter components t hat are par t of the attack surface. C. Attributes In accordance with the taxonomic scheme above, a minimum set of attr ibutes is presented in T able I. The example comes from an NMEA GPS and its corresponding attr ibutes stem from design documents and are refined using data sheets. Fur ther refinement of t hose attributes is allow ed. This dissemination is mostly based on the inf ormation pro vided in the design requirements documents but can also include inf or mation pro vided by subject matter experts. II I. S YS M L M O DE L Consider , for exam ple, an Unmanned Aerial Sys tem (U AS) that is used to assist in search and rescue operations where minutes (or ev en seconds) count. In this domain, losing a U AS is cert ainl y going to risk longer mission times and can potentiall y lead to an unsuccessful search and rescue operation. For these types of safety -cr itical missions, it is essential to assess t he security posture of a given FCS design, so that a t hreat actor cannot interfere with saf ety-critical operations. For that reason we construct and ev aluate an FCS model f or possible secur ity violation in an evidence-based f ashion. T able I A G PS EX A MP LE O F T HE M INI MU M SE T O F ATTR IB UT ES N EC ESSA RY T O CR EAT E A SO U ND , W EL L - FO RM E D M O DE L O F C P S. T H ESE ATT RI BU TE S N EE D TO B E U SE D F OR A NY G IV EN SU BSYST EM T HAT IS PE RTI NE NT T O IT S EX PE CT ED S ERVIC E . T HE M ATCH ING O F AT T A CK VE CT OR S D ER IV ES F ROM TH E ATTR IB UT ES SP EC IF IED IN T HI S TAB LE . NMEA GPS Category Attributes Operating system Bare metal Device Name Adafruit Ultimate GPS Hardwar e Mediatek MTK 3339 chipset Firmw are Communication protocol drivers Software ∅ Communication I2C, RS232, UAR T, RF Entry Points RF In the most general sense an FCS implements all the capabilities and control surfaces needed to operate an au- topilot [13], [14]. This autopilot is used to fly U AS and is usually controlled through a ground control station. An FCS is composed of sev eral compromisable cyber subsys tems whose intended function is to modify and control physical parameters, e.g., control of engine t hro ttle f or speed, changing the direction based on a na vigational goal by controlling the aileron, etc. By this definition, an FCS is a CPS and prime example of analy sis given its ubiquity and utility in many domain areas. An FCS is safety -cr itical system, in t he sense that if there is a hazard, either ar tificial through a cyber att ac k or by natural faults, it can cause sev ere consequences. The model of the FCS is encoded in an Inter nal Bloc k Diagram (IBD) (Fig. 2). An IBD representation is used to define a system’ s str ucture. T raditionally , this model contains only generic represent ations of subsys tems, e.g., pow er system, en- gine sensor , magnetometer and general inf or mation about flow s of inf or mation, e.g., energy , command, sensor measurement. The t ax onomic scheme described in the pre vious section adds specific implementation information that assists t hreat analy sts in finding possible vulnerabilities and, consequentl y , associated attack vectors. This specific implementation information is encoded using par t proper ties for component attr ibutes, e.g., what type of GPS, and connectors for interaction attr ibutes, e.g., using the I2C protocol. Part proper ties encode further attribute inf or mation in a manner that is easy to parse by t hreat analysts. Par t properties, as the name implies, are attr ibutes that can fur ther characterize an IBD block and take t he f or m of ⟨ part name ⟩ ∶ ⟨ type ⟩ . Additionall y , they can be decomposed to fur ther par t proper ties to make general categories of attributes—t his can be seen by the decomposition of the Operating System type in the Primar y Application Processor to fur ther par t properties (Fig. 2). Moreov er, part proper ties can constr uct a new IBD by themselv es to define the connectivity betw een components in a collection of part properties. This is useful in more complex systems where the connections might ha ve different levels of abstraction. Par t proper ties define t he str ucture and composition FCS Hardware Stack connections Hardware Stack [Block] ibd [ ] UART or RS232 protocol drivers and ZigBee IEEE 802.15.4 : Firmware RF or Local Access through UART : Entry Point API to change mode of operation : Software XBee PRO 900 MHz ISM : Hardware Bare Metal : Operating System XBee : Radio Module comm port radio I2C and SPI and UART and SDIO low-level drivers : Firmware Autopilot Navigation and Control Algorithms : Software ChibiOS : Operating System ARM STM32F4 : Primary Application Processor comm port radio comm port eth comm port i2c I2C or RS232 or UART protocol drivers : Firmware Mediatek MTK 3339 chipset : Hardware RF or Local Access : Entry Point Bare Metal : Operating System Adafruit Ultimate GPS : NMEA GPS comm port i2c MPU 9150 : Accelerometer Gyroscope Magnetometer comm port i2c MS4525DO 1 : Differential Pressure Sensor comm port i2c MS4525DO 2 : Absolute Pressure Sensor comm port i2c ARM STM32F0 : Safety Switch Processor comm port actuators comm port i2c DP83848 Ethernet : Wireless Modem comm port ethernet Servos : Actuators actuator port comm port actuators Throttle : Control Surface Elevator : Control Surface actuator port Rudder : Control Surface Aileron : Control Surface Physical Movement PWM MII protocol over RMII bus I2C Protocol RS232 Protocol Fig. 2. The Internal Block Diagram (IBD) SysML model of the Flight Control System (FCS) with all the necessar y attributes to characterize t he primary application processor, the NMEA GPS, and the radio module. This model can inform about possible architectural chang es at t he earl y stages of design to a void using components t hat ha ve repor ted vulnerabilities or clearly mitigate against these vulnerabilities through better informed requirements. As such, we are able to construct systems that are secure by design. of t he system. Finall y , connector types define source and targ et relationships as well as t he type of interaction, digit al protocols, analog inputs, or possibl y phy sical actions. For ex ample, t he connection betw een t he Safe ty Switch Processor is digit al and uses Pulse Width Modulation (PWM) commands to mov e the ser v os (Fig. 2). The ser v os then provide the phy sical pull to either open the throttle fur ther —to gain v elocity—or change the direction of mov ement by controlling the aileron. IV . M O D EL T RA N SF O RM ATI ON A model transf or mation is used so t hat t he modeling methodology presented in this paper is agnostic to specific modeling tools and languages. T o achiev e this transformation, ARM STM32F4 DP83848 Ethernet MII protocol over RMII bus XBee RS232 Protocol Adafruit Ultimate GPS I2C Protocol ARM STM32F0 I2C Protocol MS4525DO 1 I2C Protocol MS4525DO 2 I2C Protocol MPU 9150 I2C Protocol Servos PWM Aileron Physical Movement Rudder Physical Movement Throttle Physical Movement Elevator Physical Movement Fig. 3. The Internal Block Diagram (IBD) (Fig. 2) of the Flight Control System (FCS) maps directly to a graph structure (the par t property type is omitted f or visualization pur poses). This allow s us to extract the elements in an inter nal block diagram without loss of any information vital for cybersecurity assessment. The graph structure can be fur ther input to other analy sis techniques and provide a schema for the topological definition of a Cyber-Phy sical System (CPS). In this instance t he v ertex attributes can be accessed t hrough t he GraphML specification ev en though they are not visualized here. we constr uct a generic formalism for SysML IBD based on graph str uctures. The formalism is used as a basis for a tool which extracts the inf or mation from the IBD and encodes it in GraphML. GraphML is based on XML and consists of t he de facto schema f or sharing graphs [15]. Tr ansf or ming SysML models to a graph should allo w , in the future, the model to be anal yzed with a variety tec hniques. This is potentially beneficial because SysML has limited verification capabilities and requires a specific modeling methodology to produce validated results. The f ollowing formalism assur es that all SysML information and their cor responding proper ties are not lost in the transformation to GraphML. A. F ormal Semantics of Internal Bloc k Diagr ams Computing netw orks are typically reasoned about using graph structures, where the vertices represent assets and the edges represent t heir immediate connections. This is no different f or CPS [16]. This paper extends t he definition of assets to encompass ev er y subsystem in a CPS, which compr ises of more t han t he computing systems, including but not limited to imagery pa yload, actuators, sensors and their data links to the computing systems. W e f or malize these definitions, which are initially encoded in a SysML IBD, using standard graph notation below . Definition 6. An I NT E RN AL B L OC K D IAG RA M is a graph 𝐺 ∶ = ( 𝑉 , 𝑃 , src , tgt ,  ) , where 𝑉 is the set of vertices of 𝐺 ; 𝑃 is the set of ports of 𝐺 ; src , tgt ∶ 𝑃 → 𝑉 functions source and targe t f or 𝐺 respectiv ely , and  is the set of attributes of 𝐺 . 𝑉 represents the components of a cyber -physical system, 𝑃 the inputs and outputs cor responding to t he components, src , tgt the directionality of t he possible cyber or ph ysical interactions betw een components, and  the associated descriptors for a given vertex or connection. An example transformed system graph is depicted in Fig. 3 where not all inf or mation is necessar ily visualized but is encoded in the GraphML f or mat and can be accessed pro- gramatically . Definition 7. A P A RT P RO PE RT Y in an internal block diag ram is a function attr 𝑣 ∶ 𝑉 →  𝑣 , where 𝑉 is the set of vertices of 𝐺 and  𝑣 the set of vertex attr ibutes, such that  𝑣 ⊆  . Consider a single mapping f or the attr ibutes of the NMEA GPS, (Table I and Fig. 2): attr 𝑣 ( GPS ) ↦ { Bare Metal , A dafruit Ultimate GPS , Mediatek MTK 3339 chipset , … , RF } . Definition 8. A C O NN E CT OR in an internal block diag ram is a function attr 𝑝 ∶ 𝑃 →  𝑝 , where 𝑃 is the set of por ts of 𝐺 and  𝑝 the set of por t attr ibutes, such t hat  𝑝 ⊆  . For example, t he tuple of vertices below passed into t he por t attribute function will pro vide the edge-specific attr ibutes for that tuple: attr 𝑝 ({ GPS , STM32F4 }) ↦ { I2C Protocol } . Given t he abov e definitions, we transf orm the SysML model to t he neutral GraphML f or mat and can furt her use it as input to other analy sis techniq ues, including finding attack vectors. V . M ATC H ING P OT E NT IA L A T T A CK V EC T OR S T o evaluate the model we find and map applicable attack vect ors f or subsy stems of the FCS model descr ibed abo ve (Fig. 2 and Fig. 3). This analysis is based on analyzing open vulnerability dat abases to find possible att ac k s and provide possible design mitigation strategies. For example, given a component wit h an associated set of attack vectors, one can then assess t he risk and potentially find another component that pro vides the same expected service without an y repor ted vulnerabilities. A. Exper imental Setting T ow ard the e valuation of the model’ s fidelity we find potential attack vectors f or the subsys tems of t he FCS model using cv e-search. 4 This online database not onl y pro vides possible CVE entries that are applicable based on t he query strings produced by t he models attr ibutes, but can also relate to 4 CVE-SEARCH PROJECT, cve-search.or g (perma.cc/5J2M- V AGC) CWE-264: Permissions, Privileges, and Access Control CVE-2016-6788 CVE-2016-3801 Fig. 4. The two possible Adafruit Ultimate GPS att ac k vectors found in CVE share the same CWE categor y . This can inform t he designer about general issues with t he specific, chosen subsystem and to possibly look at substitutes with no reported vulnerabilities. Other wise, the designers might choose to clearly document this class of vulnerabilities and constr uct solid requirements to mitigate such possible violation of system assets. higher levels of abstraction, e.g., CWE or CAPEC, to fur ther understand t he possible impact of a given attack. W e assume that a system is vulnerable if any single att ac k vect or from the dat abases maps to any single attribute of t he system model. For example, if an attack vector targ ets Operating System ‘ A ’ with Driver ‘B’ , we consider it a vulnerability ev en if t he model includes onl y ‘ A ’ or ‘B’; it does not hav e to contain both, ev en if the attack patter n specifies them together . This assumption is reasonable because a larg e number of vulnerabilities that are repor ted ha ve to do with systems that are popular and widely used, e.g., the Android operating sys tem and cor responding dr ivers. This assumption allow s f or extrapolation from such (specific) repor ts to better understand the secur ity posture of t he model where, at the moment, no embedded system vulnerability database exists. Furt hermore, it is uncommon f or users to update their embedded devices, and t his assumption still allow s the analy st to take into account vulnerabilities t hat may hav e been fixed in newer versions of fir m ware or softw are. Finall y , we assume that a subsystem that has no repor ted attack vectors is more secure t han one t hat does. This work does not f ocus on zero-da ys because there is cur rently no w a y—at the design phase—to assess zero-day vulnerability just by analyzing the architecture of t he system. How ev er, our approach also works using private or proprietar y vulnerability databases. As long as t here exist historic data on the given subsystem, t his approach allo ws an analyst to identify them and better inform system designers. In attempting to violate the secur ity posture of a system, a given intelligent threat actor will, most likely , use a set of tec hniques t he y are familiar with rather t han come up with new techniques tailored to the individual system [17]. B. Results This section descr ibes a security assessment of two compo- nents in the FCS that can cause full degradation of expected service through exploiting historic vulnerabilities. Specifically , this anal ysis f ocuses on (1) the NMEA GPS device, which is necessary to provide location data and (2) the radio module, which is necessar y to communicate with the ground control station or in t he instance of manual control, the operator . NMEA GPS. Given the specification of the Adafruit Ultimate GPS (T able I and Fig. 2) we search through CVE to find two possible att ac k vectors (Fig. 4). The first is CVE-2016- 3801, which is a repor ted vulnerability specific to Android devices and targ ets the Mediatek GPS driver in the embedded operating system by crafting an application that can exploit the driver to g ain system privileges. Even if an Android device is not specifically in use, it is possible to misconfigure or program the FCS in such a w ay that the att ac k vect ors are applicable, making this a threat one must account for when designing t he system. The second is CVE-2016-6788, an attack t hat targe ts MediaT ek I2C dr iv ers and subsequently allow s an att ac ker to elevate their privileges and execute arbitrar y code. This vulnerability was also repor ted for Android but, again, it can be applicable to the design of the FCS. Whilst both attacks take advantage of t he GPS, they actuall y target t he primar y application processor (Fig. 5) with possibly dev astating effects to the system’ s expected ser vice. Furt her , the two vulnerabilities can form an attack c hain by first using CVE-2016-3801 to gain access to t he system, which would require an operator possibly accepting a request from the attack er, and then using CVE-2016-6788 to furt her elev ate their pr ivileges without ha ving to go through operator input. It w ould be difficult to find these attacks without decomposing the NMEA GPS device down to its specific implementation including the chipset it is emplo ying and the required fir mw are to operate. Hence, system designers would ha ve been unaw are of t his possible attack chain and w ould hav e to add fur ther security considerations for this component post-deployment, instead of switching it with another that has no historic repor ted vulnerabilities and, theref ore, presumably less risk. Radio Module. Another par t of t he system that could be att ac ked is the XBee radio module, which requires drivers f or the ZigBee IEEE 802.15.4 protocol. Its specification can be seen in the SysML diag ram (Fig. 2). One of the possible attacks is described in CVE-2015-8732 and CVE-2015-6244 (these att ac k s ha ve different bugs associated with them but result in the same effect), where an intelligent t hreat actor constructs pack ets that cause out-of-bound read and application crashes, resulting in a successful denial of ser vice. Without radio communication t he FCS would not be able to coordinate with the ground control station and it would go to a f ail- saf e mode, which could be detrimental to the mission it w as planned to car ry out. Know ledge of such att ac ks to t he system’ s designers can lead to c hoosing a more robust, secur ity wise, radio module f or the implementation of the FCS. C. Discussion The aforementioned exam ple results fur ther illustrate the need for early detection of vulnerabilities. While t his work has not f ocused on ev aluating elements of t he attack sur f ace– that is, components exposed to intelligent threat actors that can act as entry points into t he systems str ucture–this paper demonstrates that a model can assist in generating secur ity by design. This approach generates evidence (the histor ic data from open dat abases) and in future work will be used to design CVE-2016-3801 ARM STM32F4 : Primary Application Processor CVE-2016-6788 Adafruit Ultimate GPS : NMEA GPS Fig. 5. An intelligent t hreat actor can potentiall y take advantage of t he use of the Adafr uit Ultimate GPS dr iv ers and can completely violate the systems expected service by escalating t heir privileges by either using the attack vectors presented individually or for a higher impact in sequence (att ac k chain). The dashed red edges indicate a given attack step, while the red solid edges indicate violation of data exc hange. Since one of the att ac k s can lead to arbitrary code ex ecution it can violate any path from the microcontroller to t he sensory systems, meaning that such an attack would cause full degradation of expected service. the systems with hardware and software that is historically more secure at no additional cost, ex cept t hose costs required f or the security analysis. If architectural changes are not an option, it is still cr ucial to be aw are of possible vulnerabilities and impose clear system requirements to preempt or mitigate against classes of attacks. Without the generalized taxonomic scheme and its generated specification for the system, we would not hav e been able to match evidence to subsystems. This could ha ve led to insecure systems ge tting deploy ed f or saf ety-critical applications, which in tur n can cause hazardous behaviors or, in the worst-case scenario, controlled accidents by intelligent threat actors. V I. C O NC LU S IO NS & B EYO ND In this paper we hav e presented a framew ork t hat character - izes a characteristic set of attributes f or each given subsystem in a CPS. These attributes construct well-f or med models that are sufficiently detailed to allow for secur ity posture evaluation of the system they specify . This framew ork is built on t he ex amination of historic vulnerability data from databases, termed evidence, which apply to t he system model based on those attributes. W e hav e shown that this framew ork produces model sufficiency by mapping att ac k vectors f or a possible NMEA GPS and radio module. While the method is agnostic to t he modeling language, we represent t he system in SysML, which is ubiquitous in systems engineer ing. A future direction can use the findings of t his research to automate t he process of matc hing attack vectors. T ow ards t his automation, we hav e shown the v ersatility of the method by transf or ming t he SysML model to a generic g raph metamodel using a standard graph schema based on XML, GraphML. A possible extension in this direction is to use t he e xtracted system structure and apply techniques from computational linguistics to automatically produce attack vectors for each subsystems. This may allow t hreat analy sts to assess the security posture of increasingly complex systems. Finall y , through this work we hav e pro vided an answer to a larg ely open question in the field of CPS. Namel y , what lev el of design detail does the system model hav e to capture to allow f or the ev aluation of its secur ity proper ties? The advantage of our model is that it view s the system from its characteristic and identifiable attr ibutes and does not depend on its function to provide a holistic view of its security posture. R EF ER E NC ES [1] National Research Council, “Interim repor t on the 21st century cyber- phy sical systems education, ” National Academies of Sciences, Engineer- ing, and Medicine, Tec h. Rep., 2015. [2] F . Frola and C. Miller , “System saf ety in aircraft management, ” Logistics Manag ement Institute, W ashington DC , 1984. [3] M. Kutz, Mechanical Engineers’ Handbook, V olume 2: Design, Instr u- mentation, and Controls . John Wiley & Sons, 2015. [4] J. Corbett and J. R. Crookall, “Design f or Economic Manufacture, ” CIRP Annals - Manufacturing T echnology , v ol. 35, no. 1, pp. 93–97, Jan. 1986. [5] M. Sara vi, L. Newnes, A. R. Mileham, and Y . M. Goh, “Estimating cost at the conceptual design stage to optimize design in ter ms of per f ormance and cost, ” in Proceedings of the 15th ISPE International Confer ence on Concurrent Engineer ing . Springer , 2008, pp. 123–130. [6] M. Hause, “The SysML Modelling Language, ” in Fifteenth European Systems Engineering Confer ence , 2006. [7] D. M. Nicol, W . H. Sanders, and K. S. Trivedi, “Model-based ev aluation: from dependability to secur ity , ” IEEE T ransactions on Dependable and Secure Computing , vol. 1, no. 1, pp. 48–65, 2004. [8] B. Chen, Z. Kalbarczyk, D. M. Nicol, W . H. Sanders, R. T an, W . G. T emple, N. O. Tippenhauer, A. H. V u, and D. K. Y . Y au, “Go with the flow : To ward workflo w-oriented security assessment, ” in Proceedings of New Security P aradigm W orkshop (NSPW) , 2013. [9] H. Kopetz, Real-time systems: design principles for distributed embedded applications . Springer Science & Business Media, 2011. [10] K. R. Davis, C. M. Davis, S. A. Zonouz, R. B. Bobba, R. Ber thier, L. Garcia, and P . W . Sauer, “ A cyber -phy sical modeling and assessment framew ork for pow er gr id infrastructures, ” IEEE T r ansactions on Smart Grid , vol. 6, no. 5, pp. 2464–2475, 2015. [11] M. Brunner, M. Huber, C. Sauerwein, and R. Breu, “ T owards an integrated model for safe ty and secur ity requirements of cyber-ph ysical systems, ” in 2017 IEEE International Conference on Software Quality, Reliability and Security Companion (QRS-C) , 2017, pp. 334–340. [12] C. Sun, J. Ma, and Q. Y ao, “On the architecture and dev elopment life cycle of secure cyber -phy sical systems, ” Jour nal of Communications and Information Netw orks , vol. 1, no. 4, pp. 1–21, Dec. 2016. [13] G. L. W ard, G. Bakir tzis, and R. H. Klenke, “ A modular softw are platf or m for unmanned aerial vehicle autopilo t systems, ” in 52nd Aer ospace Sciences Meeting , ser . AIAA SciTec h. Amer ican Institute of Aeronautics and Astronautics, Jan. 2014. [14] G. L. W ard, “Design of a small f orm-factor flight control system, ” Master’ s thesis, Virginia Common wealth University , 2014. [15] U. Brandes, M. Eiglsperger , J. Ler ner , and C. Pich, “Graph markup language (GraphML), ” in Handbook of gr aph drawing visualization , ser . Discrete mathematics and its applications, R. Tamassia, Ed. Boca Raton, FL: CRC Press, 2013, pp. 517–541. [16] G. A. W eav er, C. Cheh, E. J. Rogers, W . H. Sanders, and D. Gammel, “To ward a cyber-phy sical topology language: Applications to NERC CIP audit, ” in Proceedings of the Firs t ACM Wor kshop on Smart Energy Grid Security , ser . SEGS ’13. ACM, 2013, pp. 93–104. [17] L. Allodi, F. Massacci, and J. M. Williams, “ The work -av erse cyber attacker model: Theory and evidence from two million attack signatures, ” Social Science Research Network, SSRN Scholarly Paper ID 2862299, 2017. [Online]. A vailable: https://papers.ssr n.com/abstract=2862299