Data Driven Vulnerability Exploration for Design Phase System Analysis

1 Data Dr iv en V ulnerability Exploration f or Design Phase Sy stem Anal ysis Georgios Bakir tzis, Brandon J. Simon, Aidan G. Collins, Cody H. Fleming, and Carl R. Elks Abstract —Appl ying security as a lifecy cle practice is becoming increasingl y important to combat targeted attacks in safety - critical systems. Among others there are two significant challenges in this area: (1) the need for models that can char acterize a realistic sy stem in the absence of an implementation and (2) an automated way to associate attack vector information; that is, historical data, to such system models. W e propose the cybersecurity body of knowledg e (CYBOK), which takes in sufficiently characteristic models of sy stems and acts as a search engine f or potential attack vectors. CYBOK is fundamentally an algorithmic appr oach to vulnerability exploration, which is a significant extension to the body of know ledge it builds upon. By using CYBOK, security analy sts and sy stem designers can w ork together to assess the ov erall secur ity posture of systems earl y in their lifecy cle, during major design decisions and before final product designs. Consequently , assisting in applying security earlier and throughout the systems lifecycle. Index T erms —Cyber-ph ysical sy stems, security , safety , model- based engineer ing. I. I N T ROD U CT IO N It has been estimated that 70% of secur ity flaw s are intro- duced pr ior to coding, most of which are due to the traditional practice of application dev elopers sharing and reusing third party , legacy softwar e—that is assumed to be reasonably secure and trustw orthy . These fla ws usually end up in the application software and not, as might be expected, in network - based sof tw are [1, 2, 3]. Most security fla ws are introduced as earl y design or development decisions. Both the academic and practicing cybersecur ity community agree that security engineer ing and analysis as a full life- cycle practice, especiall y early in the design process allo w s better a wareness and leverag e at managing the challenges sur - rounding t he unintentional introduction of security flaw s into complex systems. This is especially impor tant in t he domain of cyber -physical sy stems (CPS), where the e xploitation of software fla ws and hardware weaknesses—intr oduced by eit her importing software of unknown pedigree, incomplete secur ity specifications, or general unaw areness of security characteris- tics of given software, fir mw are, and/or hardware—can lead to unf oreseen physical beha viors that hav e consequences in terms of saf ety , loss of vit al ser vice, and other societal impacts. As modern CPS evol ve into tightly integ rated, extensible, and netw orked entities, we significantl y increase the att ac k surface of these systems. CPS now routinely employ a wide variety of netw orks, for e xample, cloud, mobile services, industrial, inter ne t of t hings to realize a range of applications G. Bakirtzis and C.H. Fleming are with the U niversity of Vir ginia, Char - lottesville, V A US A. E-mail: {bakir tzis,fleming}@vir ginia.edu B.J. Simon, A.G. Collins, and C.R. Elks are wit h Vir ginia Commonwealth Univ ersity, Richmond, V A USA. Email: {simonbj,collinsag,crelk s}@v cu.edu from real time data analytics to autonomous vehicles control. The use of extensible operating systems and software to update code through loadable device dr iv ers enhances productivity , but it exposes the system to considerable risks from att ac k injections. With t hese insights and obser vations, we posit t hat secure system design and deployment requires (1) planning f or cyber - security from the outset as a strategic lifecycle activity , and (2) t aking the att ac kers perspectives to best understand how to def end a system from threats and e xposing w eaknesses bef ore they become vulnerabilities. T o achie ve this goal methods and tools are needed to allow secur ity assessment throughout the systems lifecy cle and especially at t he concept dev elopment phase, where decision effectiveness is highest [4, 5]. In recent years, a promising and rapidl y g ro wing approach to enhancing aw areness and managing challeng es of cybersecu- rity fla w s in ev olving complex CPS is model-based engineer- ing [6]. Model-based analysis is fir ml y entrenched in safety , dependability , and reliability engineering world as evidenced by suc h standards as IEC 61508 and ISO 26262, how ev er model-based engineer ing is a late comer to security [7]. Models are generall y treated as living documents maintained to reflect design choices and system revisions. These models can be a valuable resource f or the secur ity specialist b y pro viding what IT prof essionals consider the “what ’ s ”; that is, the rationale behind design choices and not simply the resulting architecture of a system [8]. An additional benefit of model-based secur ity is it tends to look at secur ity from a strategic point of view , which means it attempts to secure a system based on its expected ser vice. Rather than beginning with tactical questions of how to protect a system against att ac k s, a strategic approach begins with questions about what essential ser vices and functions must be secured against disr uptions and what represents unaccept able losses. This is cr itical f or CPS where losses or disr uptions to service can hav e dire societal or safe ty impacts [9, 10]. How ev er , one of the major impediments to effectivel y tran- sition security assessment into the model-based engineer ing realm has been associating system models to applicable att ac k vect ors. These models reside in a higher-le vel of abstraction than what is typically present in cybersecur ity analy sis. Our aim is to use t he model to dr iv e the attack vector analy sis in the design phase. There are two t hings necessar y to achiev e this cong ruence: (1) understand the dat a a v ailable to secur ity researchers and decide on which of those can inf orm early on and (2) capture low er -lev el inf ormation in the model, such that it can be used to associate the av ailable data with t he model. Such an approach br idges the gap betw een existing curated attack vector inf or mation and models of systems. Indeed, 2 Elicited: • expert input & • stakeholder requirements System T opology Σ graph Attack V ectors extra design information Produces: • applicable attacks, • attack surface, & • exploit chains Assess Via ble Exploits Initial Design Solution Fig. 1. CYBOK depends upon stakeholder requirements and expert input to constr uct t he initial design solution. Then, extra design information is added by a system designer. CYBOK t ak es as input t he g raph representation of that design and descr iptions of attack vectors to produce all applicable attacks throughout the topology of the system, the attack sur f ace of t he system, and the e xploit chains tra versing the sy stem topology . this paper presents one answer to examining cybersecurity concerns in the model-based engineer ing setting. T o w ards t his goal we hav e previousl y [11] presented a CPS model t hat includes a schema wit h extra design inf ormation to manually associate attack vector data describing attac k patterns, weaknesses, and vulnerabilities. The previous work proposed just a model, not an algor ithmic solution to the vulnerability exploration problem. To explore the larg e amount of data compiled by security prof essionals, it is helpful to associate attack vectors algorithmically . This is precisely the topic of this paper . Contributions. The contr ibutions of this wor k are: ∙ an algor ithmic implementation, called cybersecurity body of know ledge (CYB OK), that accepts as input such mod- els and produces: – a component-wise attac k v ector analysis using attack vect or data, – a notion of att ac k sur f ace, which only depends on t he model, and – all exploit chains applicable to subsystems of the system model and ∙ a demonstration of the method on an unmanned aer ial system (U AS). II . M O DE L -B A SE D S EC U RIT Y A N ALY SI S Model-based secur ity analysis is a relatively new field t hat attempts—as t he name implies—to understand system threats through the use of models. In t his paradigm, models are used either as an augment ation to other secur ity strategies during deployment or as evidence to support design decisions early in the systems lif ecycle. How e ver , most cur rent models are probabilistic in nature and, theref ore, require a ground tr uth. These models also hea vil y depend on the modelers expertise and experience. Any such model captures exactl y that expertise such that it is communicated to other stak eholders. T o our know ledge, models used at t he design phase hav e not achie v ed fidelity wit h security data collected and other wise used in already realized systems, which would consist of an impor- tant addition to defending against increasingly sophisticated threats. But why is t hat? T o understand the difficulty of find- ing vulnerabilities in system models—instead of a deploy ed product—it is impor tant to first define the difference between bugs, vulnerabilities, and exploits. Successful exploits t ak e advantage of flaw s (eit her ser ious design fla w s or unexpected system behavior that is implementation specific). These fla w s in the system are called bugs. How ever , not all bugs are vul- nerabilities. Only a subset of bugs t hat can lead to e xploit ation are vulnerabilities. This notion leads to the first problem that is addressed in t his paper . Problem 1. V ulnerabilities are explicitl y f ound at the level of code or hardw are. How ever , to address system secur ity early in t he design cycle, there need to be methods that can identify potential vulnerabilities bef ore code dev elopment. T o bridge t he gap between models and realized solutions requires constr ucting an initial design of t he system. This design needs to include both t he what’ s , the components of the system, for example GPS, and the how’ s ; that is a par ticular hardw are, fir mw are, and software solution t hat implements some desired function. Additionall y , any such model needs to include t he interaction between components as is defined by their communication and dat a transfer . One wa y to fulfill t hose requirements is to model CPS as a graph of assets but with added information in the form of de- scriptive ke ywords. This is a reasonable and appropr iate model as it per tains to secur ity analysis. Attackers typically t hink in terms of g raphs, through a ser ies of increasing violations based on concepts of connectivity , reachability , and dependence, not in lists of assets as—most commonly —def enders do [12]. In addition, this model must include extra inf ormation in the form of keyw ords t hat augment t he model, resulting in a system model t hat captures the choices a designer is considering about hardware, firmw are, and software. These augmentations can be done without ov erl y specific details about its final implementation. This is a key feature that reflects how designs ev olv e in the constr uction of a system, where choices of specific hardware and software are done early in the development cycle. Furt hermore, the ease of changing those keyw ords to descr ibe a functionally equivalent system allow s for modeling flexibility that is not av ailable after code has been wr itten and designs are finalized. Formally , an architectural model of a CPS can be captured in a g raph, Σ ≜ (  ,  ,  ) , where,  ≜ { 𝑣 ∣ 𝑣 = a system asset } ,  ≜ { 𝑒 ∣ 𝑒 = ( 𝑣 𝑖 , 𝑣 𝑗 ); 𝑣 𝑖 , 𝑣 𝑗 ∈  dependent assets } , and 3  ≜ { 𝑑 ∣ 𝑑 = ( 𝑤 1 , 𝑤 2 , … , 𝑤 𝑛 ) descriptive ke yw ords } . In order to extract and use the descriptive inf ormation; that is, the e xtra ke ywords, from a given vertex or edge, we define the descr iptor function, desc ∶  ∪  →  . The above definitions lead to the first practical challeng e, which is to deter mine if a model is sufficient for security assessment (Fig. 2). It is impor tant at these earl y design stages f or a system model to sufficiently describe functionally complete system—b y adding hardware and software informa- tion that, if put together , implements the desired functional beha viors expected from the system. Any model used f or secur ity analysis contains tw o main challeng es. The first challenge, is the amount of data associated with the model. When using a realized system it is possible to mine all possible configuration settings including software and fir m ware versions. In the absence of t he implementation such inf ormation can still be reflected in a modeling setting but it requires significant modeling cost in ter ms of time and expertise. It can also be less inf or mativ e at the design phase t han a more general model because a slight change in versioning will hide a class of weaknesses and vulnerabilities. The second challenge, is the le vel of abstraction the model resides in. No model is a direct reflection of a realized system but any model needs to be specific enough to be informativ e. This is a difficult t ask and largel y depends on the given abstraction set ov erall by t he modeling process as well as the expertise of t he modeller . These are precisely the challenges that t he added keyw ords address. By changing the specificity and amount of ke ywords, we change the ov erall fidelity of the system model, Σ . It is through that extr a design information that our solution, CYBOK, is able to take t he graph of a system model and map applicable attacks from secur ity databases (Fig 1). While there ma y be a number of different cr iteria for selection, in pre vious w ork we hav e found that the extra design inf ormation can be categorized t hrough the f ollowing practical schema: operating system, device name, communication, hardw are, firmw are, software, and entr y points [11]. Each of the categor ies is expected to cont ain a str ing of keyw ords, 𝑑 ∈  that collectivel y descr ibe a given system solution. A given categor y can also duplicate the descr iptiv e ke yw ords present in another category or simply cont ain t he null set, ∅ . The fidelity of t he model is still based on t he choices of the modeller . On the one side of the model sufficiency spectrum there are designs that are too general and do not contain inf ormation about the system t hat would aid in deter mining security posture. On t he other side of the spectr um there are designs that are too specific, to the e xtent that the effor t to create and potentiall y modify is equiv alent to constr ucting an actual implementation of the system and its functionality . Such systems are complete but impractical. There is a spot in the middle of t he spectr um, where t he information cont ained in the model can pro vide a reasonable idea about the system’ s threat space without being so detailed it is inflexible and costly to construct and maintain throughout its lifecy cle. A perhaps less obvious but equally impor tant challenge ref ers to t he information necessary to associate the model, Σ , 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. 2. The fidelity of the attributes describing a CPS has to associate to the attack vector information (reproduced from Bakir tzis et al. [11]). to potential attack vectors. Problem 2. How can w e associate vulnerability , weakness, and attack patter n inf ormation t hat is intended to be used by security analy sts to a model? This problem is difficult because of t he wa y security experts record vulnerabilities. While several attempts hav e been made to standardize the form of an att ac k v ector entry , the cur rent situation is such that the different databases are based on a different schema, because they rel y on the deduction and inf erence capabilities of a human. This means there is no straightf or w ard approach to feeding that data into a machine to automatically find those mapping. Our solution is based on t he set of descr iptors,  , present in the model and using standard practices from natural lan- guage processing to deconstr uct and associate the contents of an attack vector entr y—in t he f or m of text—to the models ke ywords, 𝑑 ∈  . This requires a separate set of attack v ector entries,  ≜ { 𝑎𝑣 ∣ 𝑎𝑣 = a set of stemmed words } . There- f ore, the fundament al problem that CYBOK attempts to solv e is then formalized as the function, associate ∶ desc →  . By doing so, the problem is reduced to associating keyw ords describing the system (which exist within t he model) to stemmed words descr ibing attack vector information (which are constr ucted using the contents of t he database entr ies and natural language processing). Applying secur ity consideration to model-based engineering is difficult for several reasons. Three of the most impor tant difficulties are: the curation of inf ormation (both from the model and the att ac k v ector dat abases), t he intuition sur round- ing the fidelity of t he system model, and the dev elopment of an algorit hmic approach t hat allow s f or filter ing through a larg e number of att ac k vectors produced at the design phase. Finding attack vectors f or individual vertices or edges 4 ov ercomes these challeng es. Ho we ver , it can be daunting to see the big picture when confronted with suc h a larger amount of data. Security professionals frequentl y use complimentar y metrics to understand t he ov erall secur ity posture of a given system. T wo such useful metrics for secur ity analysis are: 1) The attack sur f ace captures all the entry points into a given system [13]. 2) The potential f or furt her spread; t hat is, fur ther viola- tions, after an element of the attack surface has been compromised, known as an exploit chain . Proposed Solution . In general, CYBOK is an algorit hmic solution that takes as input a sufficient sys tem model (of Σ f orm) to associate to t he body of know ledge of attack vectors (of  f orm). By knowing the associated attack vectors it then produces secur ity metrics only based on the model; t hat is, the att ac k sur f ace of the system model and the exploit chains for a par ticular element of the model. Intrinsic Limitations . Model-based security analysis is grounded on early design information. This earl y design in- f ormation is usuall y incomplete and abstracted with respect to the final design solution. This leads to result spaces; that is, as- sociated attack vectors, that are significantly larg er than when analyzing a realized system. Na vigating through the results can be challenging for systems engineers t hat are not familiar with security practices. Our aim is to pro vide a framewor k in which security analy sts and systems engineers work synergistically to understand both necessary design decisions (that might affect potential secur ity mitigations) and secur ity considerations (that might affect the design of t he system). An additional limitation is the fidelity of the model. The model can only be as good as the person who is modeling the system. Therefore, a poorly constr ucted model might mislead instead of pro viding insight into the secur ity posture of the system. II I. S YST E M M O DE L T o address t he challeng es in t he previous section and con- struct a sufficient model with respect to vulnerability analy sis, first w e must elicit information from the stakeholders. The stakeholders of the system include the owners of the eventual system, the sys tem designers, the saf ety engineers, and the security analysts. While it is outside the scope of t his paper to address t he systematic process in which such information is elicited (see Car ter et al. [14] for fur ther details on the topic), it is impor tant t o place CYBOK within its larger framew ork. Without t his framew ork it would not be possible to ha ve complete or cor rect inf ormation to apply vulnerability exploration t his early in t he system’ s lifecy cle. Based on this elicitation, an initial design solution is modeled in t he systems modeling language (SysML). SysML uses visual representations to capture the system design process through objects. The main benefit of SysML is that it presents the same information in different view s, which allow s the same system to be modeled based on its requirements (through the requirements diagram), t hrough its behavior (t hrough, for e xample, the activity and/or s tate machine diagrams), and/or through its architecture (through block definition diagram (BDD) and/or internal block diagram (IBD)). T o model CPS architectures in Sy sML the system structure is captured as a set of BDD and IBD. The BDD view of the sy stem sho ws the composition of the sys tem. The IBD view refines those compositions to interconnections within the system and how those interconnections compose the system beha vior . How ev er , each element of the sy stem model is described b y a standardized schema as presented by Bakir tzis et al. [11]. It is, therefore, not necessar y to capture this model in SysML. This model is flexible to design chang es and has suppor ted vulnerability anal ysis in a manual setting. In t his work we use the modeling methodology to suppor t automated vulnerability analy sis. Security specialists usually constr uct t he follo wing informa- tion implicitly through expertise. To automate t his t ask this implicit information needs to be captured explicitl y in t he model. This information will also assist in constructing a living document descr ibing the what’ s of t hose choices. T o recap, t he schema is composed by the follo wing categor ies that describe each system element: ∙ operating system, ∙ device name, ∙ communication, ∙ hardw are, ∙ firmw are, ∙ software, and ∙ entry points. It is through that extr a design inf or mation—gathered by eliciting s takeholder information and inspecting design documentation—that CYBOK is able to take t he graph of a system model and map potential attacks from dat abases (Section IV). This is done by using t he ke y ter ms presented in the schema for each element and chec king if t he y are present in the documents composing the databases. Reasoning in terms of the diagrams has several benefits during the design process that hold for secur ity anal ysis in general (see Oates et al. [15]), which is the benefit of star ting with a SysML model instead of its g raph representation. This is less tr ue f or matching attack v ectors to the model. The exporting of models in a s tandardized f ormat is, therefore, beneficial. The translation of IBD diagrams into a graph is encoded into GraphML —a simple XML f ormat that is widel y used to impor t and export graph structures [16]. The two models—i.e., the visual representation in SysML and the graph s tructure—-must be isomorphic. This means that the transf ormation between the SysML model and the GraphML representation mus t not chang e the model of the system. To achie v e an isomor phic transformation we apply a model transformation on t he IBD model. This transf or mation produces a sufficient g raph model for secur ity anal ysis (Fig. 5 in Section VI-B). 5 Property 1 (Model T ransf ormation). An IN T ER NA L B LO CK D IAG RA M is the graph 𝐼 ≜ (  ,  ,  ) , where  is t he se t of vertices of 𝐼 and  is the set of por ts of 𝐼 . Fur ther ,  represents the assets of a cyber-ph ysical system,  the dependence between assets, and 𝐷 the descr iptors of each asset. Therefore, the g raph 𝐼 is isomorphic to our system graph Σ ; that is to say 𝐼 ≅ Σ . This system model represented as a g raph allow s us to think similarl y to attackers and to construct connections that would not be ob vious if treated as simple decoupled components. The g raph of the system model assists wit h not only finding vulnerable subsystems individually but also with finding t he attack surface of the sy stem and composing e xploit c hains. Exploit chains are a subset of attacks that could trav erse though the system model g raph and elev ate the impact to deter iorate system behavior . All exploit chains star t at elements of the attack sur f ace. The attack surface,  is composed b y all vertices that an att ac k from t he databases is found to be potentiall y applicable at t he entr y point descr iption. In par ticular the graph model allow s us to define the att ac k surface and exploit chains ov er t he system model Σ in a straightf or w ard manner. Definition 1 (Attack Sur f ace). W e define the attack surface of a system model, Σ as  ⊆  , which is composed by all vertices that can be entry points into the system and allow the attacker to cause fur ther spread wit hin t he system structure. Definition 2 (Exploit Chain). To construct the exploit chain we define a function, paths ∶  × 𝑡 × Σ →  , where  the sources of all pat hs and 𝑡 a used specified targe t and  , the set of all simple paths from the source to the targ et over Σ . Then to constr uct a single e xploit chain, 𝑒𝑐 ∈   , the set  is filtered b y checking if ev ery vertex and edge within each individual path associates to some att ac k vector from  . IV . A T T A CK V E CT OR D AT A S ET CYBOK is composed by sev eral databases to address tw o main challenges. The first challeng e is finding applicable attack vect ors based on a system model. The second challenge is to present a reasonable amount of dat a to the security analys t, such that they can erect bar riers or add resilience solutions to strengthen the design of CPS using an e vidence-based approach. T o address t hese challenges, CYBOK incor porates t hree collections curated by t he MITRE corporation: CVE [17, 18], CWE [19], and CAPEC [20]. CVE is t he low est lev el of attack vect or expression, defining tested and recorded vulnerabilities on specific sy stems. CWE presents a hierarch y of known system weaknesses at different le v els of abs traction, from which e xploits can be der iv ed. Finally , CAPEC pro vides a high lev el view of attacks against systems at varying levels of abstraction, in the form of a hierarch y organized by t he goal or mechanism of each attack. These t hree collections also include relationships to one another (Fig. 3). Formally CAPEC, CWE, and CVE constr uct the set of attack patter ns, w eaknesses, and vulnerabilities 𝐴 × 𝑊 × 𝑉 ≅  . Perspective Attacker System CAPEC CWE CVE Platform Specificity HIg h Low ExploitDB CPE Fig. 3. The collection of t he most common open attack v ector datasets and their interconnections in the sense of topical relationships with regard to attacker and def ender perspectives and level of specificity they cont ain about platf orm information. Edges denote which datasets hav e explicit relationships with one another. CYBOK only uses a subset of these dat abases marked by a ◊ . Other known datasets include t he MITRE Common Plat- f orm Enumeration (CPE) [21] and the Exploit Database (exploit-db) [22]. The f ormer includes information that is platf orm specific, including par ticular versions of sof tw are that a particular exploit is associated with. The latter provides samples of exploits for given CVE entr ies. The reasons for not including t hese two datasets is because CPE requires knowing the specific versions of sof tw are that are going to be on the system—whic h are not known at design phase—and exploit-db requires a realized system to test exploits against. Using CVE entr ies has the benefit of finding additional attack vectors because the specificity of their descr iptions ma y more closely associate to t he descr iptions in the model than t hose of CAPEC and CWE. When CVEs are matched to the system model, CYBOK uses t hat information to abstract upw ards tow ards the weaknesses and the att ac k patterns. This is especially useful in the case where multiple CVE entr ies are associated with a subsystem that has the same associated weakness or att ac k patter n. In general the CWE and CAPEC abstractions are more useful to designers over CVE entr ies because CVEs are too specific to be useful at t he design phase. For ex ample, being a ware of a vulnerability in a specific version of software is less illuminating than kno wing that a specific class of softw are bugs might consist of a vulnerability in the implementation of the system—and therefore can construct more concrete requirements or define specific mitigations. On the other hand, a number of applicable attack vectors from the model are going to reside in CVE. At the same time, CVE contains a significantly larger number of entr ies t han both CAPEC and CWE ( ∼100 , 000 vs. ∼1500 ), meaning the addition of CVE entries will explode the number of results for a given system Σ . Therefore, all three are needed: CVE entr ies to be more thorough and comple te in analyzing the sy stem model and CAPEC, CWE to abstract to useful inf ormation to system designers. 6 A × W × V Attack V ectors Search Index SysML IBD Σ Model GraphML Σ Model Match A × W × V for Σ Command Line Interface Attack Surface, Exploit Chain Visualization & Full Attack V ector Report Fig. 4. The architecture of CYBOK is modular, meaning that each of the functions can be replaced without needing to inter f ere with other functions. While the three selected collections are complete in relation to the sufficient model, CVE is cert ainl y not e xhaustiv e. There are certainly instances where companies or gov ernment agencies curate more exhaustiv e databases from t heir non- disclosed findings. In t hose cases, the design of CYBOK can be extended to use the information cont ained in these pr ivate databases. V . A RCH IT EC T UR E The ov erall architecture of CYBOK is designed to be modular and robust wit h respect to potential arc hitectural chang es (Fig. 4). For ex ample, the specific implementation of searching can be chang ed without needing to chang e the rest of the core tool functionality . A. Data Extraction, Pr epr ocessing, & Indexing The first step to associating models to att ac k v ector databases is to extract and pr eprocess the inf or mation con- tained in sev eral individual databases. An automated mech- anism for downloading the latest set of data is built into CYBOK because of the CVE, CWE, and CAPEC update cycle. Specifically , CAPEC is refactored and potentially updated ev er y six months to a year , CWE is extended ev er y one month to three months, and CVE adds new entr ies daily . By doing automatic updates, t he analy st is sure to hav e t he latest set of data t hat might inform about new system violations. All dat abase files are encoded in a standard xml file format. The steps that f ollow after updating the dat a files include preprocessing and constructing the search inde x to be used to associate system models to attack vectors. The preprocessing step extracts t he name of the database, the identification number, name of att ac k v ector, associated attack patter ns (if an y), associated weaknesses (if an y), as- sociated vulnerabilities (if an y), and the contents; that is the descr iption, f or each entry . These consist of the full search index sc hema; that is, all the inf ormation necessar y to construct 𝐴 × 𝑊 × 𝑉 . After preprocessing CYBOK keeps a persistent record of all att ac k vectors,  , by constr ucting a searc h index t hrough the schema defined abo ve. This allow s for efficient information retriev al of all attack vector information and a voids having to rebuild  for each new search quer y . B. Syst em Models as Graphs Graph structures provide an impor tant vie w in a computing system, and can extend t he notion of violation to more than just a singular view of components. Indeed, the violation of a single component by an attacker might not be detr imental to the systems expected ser vice. How ev er, t his component might be connected to other critical infrastructure. Therefore, this singular component could be a point of lateral pivot for an attacker . This in tur n can cause significant malfunction during operation with catastrophic consequences. This is how attackers operate and, therefore, reasoning in graphs of assets pro vides an attac ker’ s view to def enders. For this reason, CYBOK views the system topology; that is, the design ar tif act, as a g raph. C. F inding Applicable Attac k V ectors from a System Model Algorithm 1 Finding att ac k vectors 1: function A SS O CIAT E ( Σ ,  ) 2:  ← [] 3: for all desc ( 𝑣 ) ∈  (Σ) ∧ desc ( 𝑒 ) ∈  (Σ) do 4: for all 𝑑 ∈  do 5: for all 𝑎𝑣 ∈  do 6: if 𝑑 ∈ 𝑎𝑣 then 7:  .append({ 𝑣 ∨ 𝑒, 𝑑 , 𝑎𝑣 }) 8: return  T o find applicable att ac k vectors, CYB OK extracts the descriptive keyw ords t hat define each vertex and edge. Then, using t he descr iptiv e ke yw ords of the system CYBOK look s at all attack vector entr ies from  to associate the descr iptiv e ke ywords. A list of results is retur ned for the full system model, Σ , including the vertex or edge t he attack vector can exploit, the descr iptiv e ke yw ord, 𝑤 𝑖 , that produced the att ac k vect or , and the attack vect or itself (Algor ithm 1). The search functionality of CYBOK cur rentl y uses a com- pound w ord filter . Other candidates f or appl ying the searching include n-grams and Shingle filter . D. F inding Attac k Sur f ace Elements Algorithm 2 Finding att ac k sur f ace elements 1: function A T T A CK S U RFAC E ( Σ ,  ) 2:  ← [] 3: for all entr y_points ( desc ( 𝑣 )) ∈  (Σ) do 4: if { 𝑣, 𝑑 , _ } ∈  then 5:  .append({ 𝑣 , 𝑑 }) 6: return  CYBOK view s the attack surf ace as any vertex that has an associated attack vector specifically at t he entr y point. It constructs this set by going t hrough all vertices and chec king if a descriptive keyw ord, entr y_points ( 𝑤 𝑖 ) , associatess to an applicable attack vector (Algor ithm 2). 7 E. F inding Exploit Chains Algorithm 3 Finding exploit chains 1: function E X PL OIT C HA IN S ( Σ ,  ,  , 𝑡 ) 2:   ← [] 3: for all 𝑎𝑠 ∈  do 4: for all 𝑝 ∈ paths ( 𝑎𝑠, 𝑡, Σ) do 5: for all 𝑣 ∈ 𝑝 ∧ 𝑒 ∈ 𝑝 do 6: if { 𝑣 ∨ 𝑒, _ , _ } ∈  then 7: admissible_path ← ⊤ 8: else 9: admissible_path ← ⊥ 10: break 11: if admissible_path == ⊤ then 12:   .append({ 𝑝 }) 13: return   Exploit chains are paths from a source to a t ar get that contain violation for ev er y vertex or edge in that path. CYBOK finds exploit chains from all elements of the attack sur f ace,  to a user input target, 𝑡 (Algor ithm 3). These pat hs are not necessarily t he most efficient or direct paths from the elements of the attack sur f ace to t he given t ar ge t. This is because it is often the case that att ac kers mov e laterally from t he att ac k surface to a specific target without having full obser vability of the system. This w ay the analyst can be aw are of all paths t hat are valid based on t he system model and be better informed about potential mitigations. Furt hermore, not all paths fr om  to 𝑡 are admissible. Admissible exploit chains require each v ertex and each edge in that path has produced at least one result from  . Other wise the path is not fully exploitable based on evidence and, t heref ore, does not consist of an exploit chain under this definition. F . Visualizations T o facilitate t he analysis of results, CYBOK includes t hree main visualizations: (1) the system topology , (2) the system attack sur f ace, and (3) the system exploit chains. This is an import ant feature of CYBOK because it allow s both secur ity analy sts and system designers to project how exploits propa- gate ov er the system model, Σ . This wa y , they can be better inf ormed about potential mitigation strategies. For example, changing t he definition of a single element to one that has no recorded attacks might significantl y increase t he secur ity posture of the overall CPS. 1 Moreov er, a full GUI is dev eloped based on this method- ology to implement fur ther interactivity functions on top of CYBOK [23]. This is a natural progression of CYBOK since in-depth anal ysis req uires the analys t t o interact with the data t hrough interactivity functions, for example, filter ing, to f acilitate effective exploration of the diverse types of data input and output to and by CYBOK [24]. 1 W e assume that a component with no recorded attacks is less susceptible to exploitation ov er one that has a lar ge number of recorded att ac ks. Primary Application Processor Differential Pressure Sensor Absolute Pressure Sensor Safety Switch Processor Accelerometer Gyroscope Magnetometer NMEA GPS FCS Radio Module GCS Radio Module Imagery Radio Module Imagery Application Processor Camera Laptop Control Surface System Topology Fig. 5. The system topology , Σ , shows a static view of the system model. V I. E V A LUATI ON T o e valuate CYB OK w e will discuss in some detail the vulnerability analy sis of one potential design solution for a U AS that contains a full set of descr iptors. There is ongoing w ork in applying CYBOK to sever al other systems in the militar y and nuclear pow er domain [25]. A. System Model While modular approaches to flight control systems (FCS) ha v e been demonstrated to provide flexible choices in hard- w are [26], it is not cur rentl y possible to assess the secur ity of one design o ver another bef ore building the system. By using models of systems it is possible to assess sev eral sys tem designs and pro vide evidence ov er the use of one hardw are solution ov er another . In this wor k one such hardware solution is evaluated—through its system model (Fig. 5)—and present the evidence t hat stems from assessing the model’ s secur ity posture using CYBOK. The potential design solution present in this paper uses sev eral XBee radio modules to communicate between com- ponents, Dell Latitude E6420 ground control station (GCS) laptop, an ARM STM32F4 pr imary application processor, a BeagleBone Black imag er y application processor , an ARM STM32F0 safe ty switch processor , MPU9150 accelerometer , gyroscope, and magnetometer, MS4525DO differential and absolute pressure sensors, a GoPro Hero5 camera, and an Adafruit Ultimate GPS. This inf ormation is par t of the descr ip- tive ke yw ords captured in the vertices of the model. Fur ther inf ormation is given f or both vertices and edges to dr iv e this analy sis per the schema above (Section II). 2 B. Example Analysis SysML is used as the modeling language and tool because it is of ten familiar to Systems Engineers. How ever , CYBOK 2 The model is publicly distributed [27]. 8 Primary Application Processor Differential Pressure Sensor Absolute Pressure Sensor Safety Switch Processor Accelerometer Gyroscope Magnetometer NMEA GPS FCS Radio Module GCS Radio Module Imagery Radio Module Imagery Application Processor Camera Laptop Control Surface GPS ZigBee Wi-Fi System Attack Surface Fig. 6. The att ac k sur f ace,  , extends the sys tem topology , Σ , by adding in the descriptive keyw ords at the entr y point that associate to att ac k vectors. is not restricted to SysML models, it merely requires a graph representation of the system that includes extra design inf ormation (see Bakir tzis et al. [11] and graphml_e xpor t [28] on how t his translation is ac hieved in practice). Inputting the U AS sys tem topology to CYBOK first cons tr ucts t he attack sur f ace (Fig. 6). The attack sur f ace is extended to show all the descriptive keyw ords at the entry points that attac k vect ors are f ound. For ex ample, by inspection the use of the XBee module with the ZigBee prot ocol f or all three radio modules can be problematic because an att ac ker can exploit the system remotely . Ot her such entry points ha ve a different degree of potential exploitation. It is unlikel y that the GPS will be violated but attacks for GPS exis t and, theref ore, are reported b y CYBOK. Additionall y , the anal yst might be aw are of hardening tec hniques on the Wi-Fi netw ork used b y the GCS laptop. Consequentl y , t he analy st might decide that they consist of no threat to the systems mission. From this initial understanding of the sy stems security posture (t hr ough its composition and att ac k sur f ace) an analys t can fur ther inter rogate t he model by finding all the potential exploit chains from the attack sur f ace elements to t he pr imary application processor . This is because violation of the primar y application processor will cause full degradation of sys tem functions and, therefore, full mission deg radation ov erall. Specifically , an analyst might want to ex amine a potential exploit chain stemming from t he XBee element of the att ac k surface. By pro viding a targe t, 𝑡 , CYB OK finds the admissible paths and, t heref ore, e xploit c hains from the imag er y radio module to the primar y application processor . This path is admissible if each vertex and each edge wit hin that path has produced evidence; t hat is, att ac k vectors. Examining the results produced by CYBOK w e find the f ollo wing three associated entries: CAPEC-67 “Str ing For mat Overflo w in syslog(), ” CWE-20 “Improper Input V alidation, ” and CVE-2015-8732 a specific att ac k on the ZigBee proto- col used by XBee t hat allow s remote attackers to cause a denial Primary Application Processor Differential Pressure Sensor Absolute Pressure Sensor Safety Switch Processor Accelerometer Gyroscope Magnetometer NMEA GPS FCS Radio Module GCS Radio Module Imagery Radio Module Imagery Application Processor Camera Laptop Control Surface GPS ZigBee Wi-Fi System Exploit Chains for Primary Application Processor Fig. 7. Exploit chains,   , show a possible lateral paths an attack er might take over t he system topology to reach a specific system element. This is but one exam ple of such exploit chain from t he attack surface,  , to some t ar get 𝑡 —in this case the primar y application processor . of ser vice (DOS) via a crafted pack et. Fur ther, for the edges from the radio module to the pr imary application processor there are t he follo wing attack vectors produced by CYBOK, CVE-2013-7266 , which is a specific att ac k that t ak es advan- tage of not ensur ing lengt h values matching the size of the data structure, CWE-20 “Improper Input V alidation, ” CWE-789 “Uncontr olled Memory Allocation, ” CWE-770 “ Allocation of Resources without Limits or Throttling, ” and CAPEC-130 “Excessiv e Allocation. ” Finall y , the primar y application pro- cessor uses the I2C and RS-232 protocols to communicate with t he rest of the hardware (these are descriptive ke yw ords contained in t he edges of the graph), which produce the f ollow- ing, CAPEC-272 “Protocol Manipulation” and CAPEC-220 “Client-Server Pro tocol Manipulation. ” All this inf or mation is used as evidence for the feasibility of one exploit chain from the attack surface to the pr imary application processor (Fig. 7). By projecting the attack over t he system str ucture it is evident when the same att ac ks are applicable to sever al par ts of the system.This is important because attackers cont ain a specific skill set and they do not usually de viate from it if not necessary . Additionall y , CYBOK allow s flexible “what-if ” analy sis by changing the descriptive keyw ords in the model. For ex ample, by changing the radio module definition from XBee using the ZigBee protocol to some other radio module offered in the marke t might exclude it from t he attack surface. Since a lar ger attack sur f ace implies more access points and, t heref ore, a less secure system an analys t might decide to propose changing t he design of the system. A full analy sis consists of first identifying the import ant elements of the system; t hat is, the assets that might require protections. This might be inf ormed from the outputs produced by CYBOK or from expert input and inf ormation elicit ation. Then, of filtering the large space of attack vectors t hat asso- 9 T ABLE I A F RAG M EN T O F R EL EV AN T R ESU LTS FO R T HE UAS A S PRO DU CE D BY C YB OK . Model Element Attack V ector Description Radio Modules CVE-2015-6244 Relies on length fields in packet dat a, allows att ac ks from craf ted packets CWE-20 Improper input validation CAPEC-67 String format ov erflow in syslog() NMEA GPS C APEC-627 Counterfeit GPS signals CAPEC-628 Carr y -Off GPS attack Primar y Application Processor CVE-2013-7266 Does not ensure length v alues match size of data str ucture CWE-20 Improper input validation CWE-789 Uncontrolled memor y allocation CWE-770 Allocation of resources wit hout limits or throttling CAPEC-130 Ex cessive allocation I2C & RS-232 Protocols CAPEC-272 Protocol manipulation CAPEC-220 Client-server protocol manipulation Imagery Application Processor CWE-805 Buffer access with incorrect length value CAPEC-100 Ov erflow buffers Saf ety Switch Processor CWE-1037 Processor optimization removal or modification of secur ity-critical code Laptop CAPEC-615 Evil twin Wi-Fi attack CAPEC-604 Wi-Fi jamming Camera CVE-2014-6434 Allow s remote attackers to ex ecute commands in a restart action ciate to t he model to find the most relev ant and strong evidence (T able I). This e vidence is what ultimatel y informs o ther stakeholders, such that t he y can devise mitigative actions— changing the sy stem solution to conform to mission needs, erecting secur ity bar riers at strategic points, or applying re- silience solutions dur ing operation. V II. R EL ATE D W O R K Little research has been done f or evidence-based secur ity assessment in a model-based setting. Usually work in this area requires transcribing already known vulnerabilities to a modeling tool and assessing if it might apply to a system design. Instead, the aim of this w ork is to emplo y models that can—by their fidelity—immediatel y produce a larg e number of potential attack vectors. These attack v ectors stem from the model itself and are not inf ormed from some a pr iori secur ity know ledge. W e ackno w ledge that some cur rent att ac k vector search tools could be repur posed for model-based systems engineer ing. One such search tool is cve-searc h [29]. How ever , cve-searc h cannot input a system model. It onl y provisions security datasets in one search engine. It is also limited wit h respect to visualization techniques. Noel et al. [30] propose CyGraph which also is based on a graph-based understanding of the sy stem but this work funda- mentally differs in scope (mainly t ar ge ts traditional networ ked systems) and approach (uses a traditional notion of attack graphs). Adams et al. [31] propose topic modeling for finding applicable attack vectors given a system model. How ev er, they only examine CAPEC as a potential source of attack vectors, which is necessary but insufficient. Ford et al. [32] propose using t he ADVISE secur ity method- ology [33] on top of t he Möbius tool [34] to provide an attackers ’ s view . How ev er , the quantitativ e analysis is based on profiling and modeling attacker actions. The framew ork is larg el y una ware of a specific sy stem model that could be used to implement a realized system. The analy sis presented in this paper is qualitativ e. This is because quantitative information f or cyber-ph ysical att ac ks is limited and ultimately expert input is necessar y to understand what it means for a metric to show that a system is more susceptible to attac ks o ver another . For ex ample, a number of q uantitative approaches incor porate CVSS as a potential metric for risk [35, 36, 37]. But, CVSS only defines sev erity of a given vulnerability and not r isk [38, 39]. In general, to t he best of the aut hors ’ know ledge, there is no direct compar ison betw een the work in this paper and exis ting work in the literature. It is challenging to do a direct comparison with any existing models because previous work is based on an already implemented system or does not apply attack vector inf ormation directly to t he model. V III . C ON CL US IO N In this paper we propose a method and implement a tool to suppor t t his method, CYBOK, that is able to find associated att ac k v ectors given a sufficient system model. CYBOK provides flexibility in modifying t he system model to represent different design solutions that implement t he same desired beha viors. Theref ore, moving secur ity analysis earlier in the systems lifecy cle—particularly at t he design phase— and, therefore, building systems with security by design. T wo import ant metr ics are used f or assessing a sy stems secur ity posture; the attack surface and exploit chains. The results of this method and toolkit is illustrated and e v aluated using a U AS—an impor tant area f or secure system design because exploits can cause hazardous behavior . As a final obser v ation we note the experience of using a systematic, model-driven process to conduct attack vector analy sis often yields more information t han just quantifying 10 the vulnerability aspects of the system. The process itself is an iterative lear ning experience, allowing circumspection into how a system behav es in response to potential exploits. IX . A CK NOW L ED G ME N TS This mater ial is based upon work suppor ted in par t by the Center for Complex Systems and Enter prises at t he Stev ens In- stitute of T echnology and in part by the United States Depar t- ment of Defense through t he Systems Engineer ing Researc h Center (SERC) under Contract HQ0034-13-D-0004. SERC is a federall y funded Univ ersity Affiliated Research Center managed by Stev ens Institute of T echnology . An y opinions, findings and conclusions or recommendations expressed in this material are those of the authors and do not necessar il y reflect the view s of the United States Department of Defense. R EF ER EN CE S [1] E. Fong and V . Okun, “W eb application scanners: Definitions and func- tions, ” in Proceedings of the 40th Haw aii International International Confer ence on Sys tems Science (HICSS-40 2007) , 2007. [2] S. Wisseman, “Third-party libraries are one of the most insecure par ts of an application, ” A vailable from T echBeacon, https:// tec hbeacon.com/ security/t hird- party- libraries- are- one- most- insecure- par ts- application. [3] P . Bisht, M. Heim, M. Ifland, M. Scove tta, and T . Skinner, “Managing security r isks inherent in the use of third-par ty components,” SAFECode, T ech. Rep., 2017. [4] F . Frola and C. Miller, “System safety in aircraf t acquisition, ” Logistics Manag ement Institute , 1984. [5] A. Straf aci, “What does BIM mean for civil engineers, ” CE New s, T ransportation , 2008. [6] P . H. Nguyen, S. Ali, and T. Y ue, “Model-based security engineering f or cyber-ph ysical systems: A systematic mapping study , ” Information & Software T echnology , 2017. [7] D. M. Nicol, W . H. Sanders, and K. S. Trivedi, “Model-based evaluation: From dependability to secur ity , ” T ransactions on Dependable and Secure Computing , 2004. [8] B. Chapman, “What are your intentions?” ;login: , 2001. [Online]. Av ailable: https://www .usenix.org/publications/login/ july - 2001- volume- 26- number - 4/what- are- your - intentions [9] H. Alemzadeh, R. K. Iyer , Z. Kalbarczyk, and J. Raman, “ Analy sis of saf ety-critical computer failures in medical devices, ” IEEE Security & Privacy , 2013. [10] N. Kshetr i and J. M. V oas, “Hacking power gr ids: A cur rent problem, ” Computer , 2017. [11] G. Bakirtzis, B. T . Carter, C. R. Elks, and C. H. Fleming, “ A model- based approach to security analysis for cyber -phy sical systems, ” in Proceedings of the 2018 Annual IEEE International Systems Confer ence, SysCon 2018 , 2018. [12] J. Lamber t, “Defenders think in lists. Attackers think in graphs. As long as this is true, attackers win.” https://per ma.cc/6NZ2- A2HY, 2015. [13] P . K. Manadhata and J. M. Wing, “ An attack surf ace metric, ” IEEE T ransactions on Sof tw ar e Engineering , 2011. [14] B. T . Carter, G. Bakirtzis, C. R. Elks, and C. H. Fleming, “ A sys tems approach for eliciting mission-centric secur ity requirements, ” in 2018 Annual IEEE International Sy stems Conference (SysCon 2018) , 2018. [15] R. Oates, F . Thom, and G. Herr ies, “Secur ity -awar e, model-based sys- tems engineering with SysML, ” in Proceedings of the 1st Inter national Symposium on ICS & SC ADA Cyber Security Resear ch , 2013. [16] U. Brandes, M. Eiglsperger , J. Ler ner , and C. Pich, Graph markup languag e (GraphML) . CR C Press, 2013. [17] “Common V ulnerabilities and Exposures (CVE), ” A vailable from MITRE, https://cve.mitre.org/. [18] “National V ulnerability Database (NVD), ” A vailable from NIS T, https: //nvd.nist.go v/. [19] “Common W eakness Enumeration (CWE), ” A vailable from MITRE, https://cwe.mitre.org/. [20] “Common Attack P attern Enumeration and Classification (CAPEC), ” A vailable from MITRE, https://capec.mitre.org/. [21] “Common Platform Enumeration (CPE), ” A vailable from MITRE, https: //cpe.mitre.org/. [22] “Exploit database (exploit-db), ” A vailable from Offensive Security , https://www .exploit- db.com/. [23] G. Bakir tzis, B. J. Simon, C. H. Fleming, and C. R. Elks, “Looking f or a black cat in a dark room: Secur ity visualization for cyber-phy sical system design and analysis, ” arXiv preprint , 2018. [24] J. Jacobs and B. Rudis, Data-driven secur ity: analysis, visualization and dashboards . John Wile y & Sons, 2014. [25] P . Beling, B. Horowitz, C. Fleming, S. Adams, G. Bakir tzis, B. Carter, T . Sherburne, C. Elks, A . Collins, and B. Simon, “Model-based en- gineering for functional r isk assessment and design of cyber resilient systems, ” Systems Engineering Resear ch Center (SER C), T ech. Rep., 2019. [26] G. L. W ard, G. Bakir tzis, and R. H. Klenke, “ A modular sof tw are platf orm for unmanned aer ial vehicle autopilot systems, ” in 52nd Aer ospace Sciences Meeting , ser . AIAA SciT ech. American Institute of Aeronautics and Astronautics, Jan. 2014. [27] G. Bakir tzis, “bakir tzisg/cybok -cli: first release, ” 2018. [Online]. A vailable: https://doi.org/10.5281/zenodo.1313696 [28] G. Bakirtzis and B. J. Simon, “bakir tzisg/graphml_export: first release, ” 2018. [Online]. A vailable: https://doi.org/10.5281/zenodo.1308914 [29] “cve-searc h, ” A vailable from CIRCL, https://cve.circl.lu/. [30] S. Noel, E. Harle y , K. T am, M. Limiero, and M. Share, “CyGraph: graph-based analytics and visualization f or cybersecurity, ” in Handbook of Statistics . Elsevier , 2016, v ol. 35. [31] S. Adams, B. Carter, C. Fleming, and P . A. Beling, “Selecting system specific cybersecurity attac k patterns using topic modeling, ” in 2018 17th IEEE International Confer ence On T r ust, Security And Privacy In Computing And Communications/12th IEEE International Conf erence On Big Data Science And Engineering (T r ustCom/BigDataSE) . IEEE, 2018. [32] M. D. F ord, K. Keef e, E. LeMay , W . H. Sanders, and C. Muehrc ke, “Implementing the advise secur ity modeling f ormalism in möbius, ” in Proceedings of the 2013 43r d Annual IEEE/IFIP International Confer - ence on Dependable Systems and Netw orks (DSN) . IEEE, 2013. [33] E. LeMay , M. D. F ord, K. Keef e, W . H. Sanders, and C. Muehrc ke, “Model-based security metrics using adversary view secur ity evaluation (advise), ” in Proceedings of the 2011 Eighth International Conf er ence on Quantitative evaluation of sys tems (QEST) . IEEE, 2011. [34] T . Cour tney , S. Gaonkar, M. Griffith, V . Lam, M. McQuinn, E. Rozier, and W . H. Sanders, “Data analysis and visualization within t he m¨ obius modeling environment, ” in Proceedings of the 2006 Third Inter national Confer ence on Quantitative Evaluation of Syst ems (QEST) . IEEE, 2006. [35] M. Fr igault, L. W ang, A. Singhal, and S. Jajodia, “Measur ing networ k security using dynamic ba yesian network, ” in Pr oceedings of the 4th A CM workshop on Quality of Protection . A CM, 2008. [36] S. H. Houmb, V . N. Franqueira, and E. A. Engum, “Quantifying security risk lev el from CVSS estimates of frequency and impact, ” Journal of Systems and Sof tw are , 2010. [37] P . W ang, A. Ali, and W . Kelly , “Dat a security and threat modeling f or smart city infrastructure, ” in Cyber Security of Smart Cities, Industrial Control Syst em and Communications (SSIC), 2015 International Con- fer ence on . IEEE, 2015. [38] J. Spring, A. H. E. Hatleback, A. Manion, and D. Shic, “ T owards improving CVSS, ” Sof tw are Engineer ing Institute, Car negie Mellon Univ ersity, Tec h. Rep., December 2018. [39] Z. A. Collier, D. DiMase, S. W alters, M. M. Tehranipoor , J. H. Lamber t, and I. Linkov , “Cybersecurity standards: Managing risk and cr eating resilience, ” Computer , 2014.