High integrity Systems and Cyber-Physical Systems (CPS) often integrate a diverse set of hardware and software components to provide critical service capabilities. These components include advanced computing platforms, sensors, control systems and communication networks to monitor operation conditions and control system assets as required for their underlying mission. Examples of their every day but include energy operation centers, wearable devices, connected automobiles, defense and military coordinated operations and homeland security monitoring centers, to name a few. The critical nature of these systems requires thorough, effective, and affordable security analysis throughout their lifecycle but especially at the early concept development phase.
This is supported by the defense community where it is estimated that 70-80% of the decisions affecting safety and security are made in the early concept development phase of any project[1, 2]. Based on the above insights, we identify two distinct needs in the area of CPS security: (i) the need to derive resilience from both a system’s and a mission context and (ii) the need to establish systematic risk-based security analysis early in a systems lifecycle that goes beyond security compliance checklists.
The above needs are illustrated by recent reports on vulnerabilities in systems that are not just critical to infrastructure but could also lead to potential loss of life. One such example is the Boeing 757 which has been shown to have serious exploitable vulnerabilities in a non-laboratory environment .
Perimeter-based security approaches demonstrate some success in protecting CPS but they tend to be prescriptive (e.g., use a firewall, encrypt communication channels, etc.) without being aware of the nature and purpose of the system and its mission. In contrast, mission-centric cybersecurity presupposes that there is a specific expected service that needs to be protected and, hence, provides adequate justification for potential defenses. Therefore, mission-centric cybersecurity provides awareness of how sophisticated cyber attacks can influence mission success and, consequently, focuses system designers’ resources and efforts in mitigating potential vulnerabilities .
To directly address the above challenges we propose mission aware, a strategic, model-based, and proactive cybersecurity approach. A strategic approach starts by understanding the mission of the system, what it is expected to do and what potential hazards it might face, who it is expected to serve, and for what purpose. By answering these questions, we can then model top-to-bottom (1) the mission requirements, (2) the admissible functional behaviors, and a potential realized model of a (3) system structure that can fulfill the defined service. This approach results in systematic analysis by combining all three domains in a well-formed mission specification. Finally, we use public vulnerability repositories (e.g., CAPEC,111Common Attack Pattern Enumeration & Classification, capec.mitre.org CWE,222Common Weakness Enumeration, cwe.mitre.org CVE,333Common Vulnerabilities and Exposures, cve.mitre.org etc.) to assess the security posture of the critical subsystems that directly relate to potential mission degradation which we term evidence.
The main contributions of this paper are:
provision of information and the analysis of system information to build assurance artifacts on mission survivability in the presence of intelligent threat actors;
well-formed, traceable modeling framework that captures the mission requirements, admissible behaviors, and architectural elements;
identification and reduction of system components that need to be analyzed in order to assure mission success; and
utilization and application of realistic threat information, termed evidence, to assess mission impact.
We evaluate mission aware on a military mission, specifically an Unmanned Aerial Vehicle (UAV) reconnaissance mission.
Ii Mission-Centric Security Approach
The mission aware methodology, as the name implies, is grounded on understanding the expected service of the system, i.e. mission, and the goals of the mission from various stakeholders’ perspectives (Fig 1). In this section we discuss the basic elements and workflow of mission aware.
mission aware begins with a structured elicitation process from various stakeholders, termed the war room, that first defines the mission scenarios and then identifies both the possible mission hazards and the type of threat space that is going to be associated with the system architecture (Fig. 1 (a) and Fig. 2). The war room is the driving concept in mission aware. The typical stakeholders ensemble are supervisory staff, commanders, operations staff, end users, and subject domain experts.
Following the war room the methodology branches into two paths. The first path addresses the modeling of the target system architecture with respect to functionality, mission constraints and requirements of CPS, admissible behaviors, restrictions, and hazards of the mission. The second path identifies and assesses threats to the specified mission. Along this path, the mission aware
methodology discovers relevant attack information at the earliest possible stage of systems development. Threat information (e.g., attack patterns, vulnerabilities, and weaknesses) mined from public attack vector databases are used to drive system vulnerability detection and mission impact.
Modeling. The purpose of the modeling effort in mission aware is to capture the stakeholders’ beliefs in the form of records and artifacts, provide a systematic framework to analyze these artifacts, and construct a specification in SysML that can grow and be modified throughout the lifecycle of the system. Specifically, these artifacts are analyzed in a systematic approach based on Systems-Theoretic Accident Model and Process (STAMP), which is detailed in Section IV, which captures the potential hazards the mission might face in a tabular format (Fig. 1 (b)). The outcomes of this systems-theoretic analysis are, then, captured into a hierarchical Systems Modeling Language (SysML)  model of the target system. The target system model is segmented in three domains: mission, behavior, and architecture (Fig. 1 (c) and Fig. 3). The SysML model can be further extended and modified to represent the changes in the mission of the system, the behaviors, as well as architectural changes.
Attack Vector Space. The attack vector space allows us to provide real information about attack patterns, weaknesses, and vulnerability associated with the model. This allows us to not only find the hazards that might cause mission degradation but also assess how likely the threat is based on evidence. Using the elicited information the analyst is, also, informed on which databases are applicable to the system and its corresponding mission (Fig. 1 (e)). Through the databases, we extract vulnerability information that can potentially violate the mission-level requirements and the corresponding system architecture (Fig. 1 (f)). This step can be complemented with further information after the system architecture has been modeled.
Impact. The final step in mission aware is to ascertain through the model and its corresponding attack vector space, if there can be significant impact on the mission. To assess this impact and relate attacks to potential hazards, the outputs of both paths are transformed into graph metamodels that represent the mission specification and its associated evidence. The use of graph metamodels are important for two specific reasons. First, graphs in mission aware carry important model attribute information that can map to attack vectors of the components of a system. Second, graphs are a common formalism for both attack and system models and have been proven practical in several contexts in cybersecurity . This allows us to assess the impact of an adversarial event by finding the paths that violate mission-level requirements (Fig. 1 (g)).
Feedback. The analysis can be repeated as many times as needed to provide confidence in mission success by feeding back the results (mission impact) to the war room.
Iii Requirements & Mission Information Elicitation
The war room is a guided elicitation activity that leverages the strengths of different stakeholders to identify mission goals, objectives, unacceptable outcomes, expectations, and procedures. It also makes an initial prognosis for the threat level that the mission and the system might combat. Such stakeholders include the mission owner, the system operator, attack analysts, and the acquisition cost experts. Analysts engage these stakeholders by asking a series of queries and proposing hypothetical scenarios to generate the information listed above (Fig. 2). For example, an analyst may ask a UAV operator how they might handle the malfunction of an imaging payload, or ask an attack analyst how mission timing can affect the types of threats to the system. By maturing from the fuzzy front end of a narrative description to a rough block diagram to a robust system model, we are able to concretely capture the diverse information in a single SysML model.
Through the war room
exercise, we are able to encode mission requirements as high-level properties to be preserved. Additionally, through expert input about mission objectives and unacceptable outcomes we are able to pinpoint and classify critical components of a system, their interaction with users and the environment, and the relationship between those critical assets and the mission. Thewar room directly informs the subsequent hazard analysis in the next step of the mission aware process with unacceptable outcomes, potential hazards, and procedural behaviors. This is advantageous as this information is now produced explicitly by the stakeholders rather than derived or assumed by the analysts. The results of the war room are also important in deciding which databases are applicable to the mission and its corresponding system based on the threat analysis information provided by the stakeholders.
Iv Disturbance and Consequence Modeling
Systems theory views a system as a hierarchy, with each level imposing a set of constraints on the behavior of the level below. When these constraints break down, so does the safety and security of the system. STAMP  is an accident causality model that describes these breakdowns. In the context of mission aware, an adversary exploits vulnerabilities to ultimately change the behavior of a system and affect the outcome of a mission. STAMP allows us to analyze unintended system behavior as a control problem rather than a component failure problem, which enables a holistic investigation of both safety and security.
More specifically, STAMP extends traditional causality modeling beyond component failures to include human interactions, the environment, organizational structures, and hazardous interactions with non-failing components. Inadequate control or handling of these factors lead to losses, not just simple component failure. This concept proves useful for the mission aware approach as it shifts focus from preventing failures to enforcing constraints; in other words, it helps strategize how functionality can be preserved in the face of disruptions, rather than attempting to prevent all disruptions.
While STAMP mainly focuses on system safety, its principles can be applied to help foster a holistic approach to increasing system security and resilience. However, Systems Theoretic Process Analysis for Security (STPA-Sec) is an extension of STAMP that applies the same concepts of enforcing safety constraints to control vulnerabilities [8, 9]. STPA-Sec shifts the focus of STAMP from designing against unintentional disruptions (safety) to protecting against intentional disruptions (security). More specifically, STPA-Sec operates from the top-down by outlining unacceptable losses or outcomes within the mission to establish clear priorities that both guide later analysis as well as influence potential future solutions. Furthermore, the STPA-Sec model systematically encodes these unacceptable losses, the hazardous conditions that could lead to these losses, and the control actions and circumstances under which these actions become hazardous.
The STPA-Sec model generates the links between the mission requirements and information from the war room and the behavior of the system while attempting to complete that mission. The stakeholder inputs about the mission directly feed into the top levels of the STPA-Sec analysis, and in particular the unacceptable losses and the prioritization of each. Furthermore, the behavior and functionality described in the model provides the basis for a model of the system’s architecture which helps create the traceability between hardware and software through mission requirements. This allows the analysis to identify and evaluate potential vulnerabilities with respect to their effects on the outcome of the mission rather than blindly trying to eliminate gaps in security, a key tenet to the mission aware approach.
V Hierarchical SysML Modeling
System models are developed to simultaneously achieve two objectives. The first is to ensure fidelity to an actual system’s (or system-of-systems’) behavior. The second is to allow the model to be “virtually attacked”, and it is this latter objective that requires additional semantics compared to a typical SysML modeling effort.
The SysML modeling starts by constructing the mission requirements, system functions, and system structure. These are the baseline models that correspond to each of the domains (Fig. 3) and include all the attributes and behaviors above. Mission requirements, system functions, and system structure are as encoded in the following standard SysML diagram types, respectively: requirements diagrams; activity diagrams, which also encode behavior related to STAMP and STPA from Sec IV; and block definition and internal block diagrams.
A second modeling pass completes the mission specification by tracing mission requirements to system functions and system structure (in SysML this is achieved by extending the requirements diagrams). This allows an analyst to identify vulnerabilities of system components and then find all trace paths that impact mission requirements and better understand the security needs not only based on the utilized system but also on the mission requirements. Ideally it causes a reduction of the architectural elements that need to be considered in the security evaluation; however, in the worst-case scenario a mission might be impacted by all elements in the system architecture model.
In order for the model to be “attackable” we construct the following semantics, i.e., descriptors and behaviors, that capture:
Information flow: Types of information flow for Input and Output ports.
Properties: Information flows or components associated with confidentiality, integrity, availability, and also, restrictions, sharing, etc.
Functionality: What function a sub-system has relative to the whole system and what service it provides
Non-functional attributes: Timeliness, responsiveness, user interaction, etc.
Interface interactions How a component interacts with users and entities.
These semantics allow us to map potential attack vectors using the architectural specification of the system. This in turn, provides evidence that the impact to the mission specification is realizable based on historic reported attack patterns, weaknesses, and vulnerabilities.
Vi Graph Metamodels
In this section, we construct graph-theoretic formalisms that act as metamodels for assessing the overall security posture of CPS based on their mission-level requirements, admissible behaviors, and system architecture.
We produce a common language formalism for security assessment for mission-centric CPS. This formalism is both an extension and a generalization of the language presented by Bakirtzis et al. , making connections to the SysML encapsulation and the hierarchy produced by the systems-theoretic approach. It also introduces the notions of attack chain and mission impact. The following terminology is one of potentially several ways to represent the concepts present in this paper.
Definition 1 (Mission Requirements)
The mission requirements of a cyber-physical system is a graph , where the vertices of ; the arrows of ; . represents the requirements; the relations of each requirements; and the type of relation, i.e., prerequisite or refinement.
Definition 2 (System Function)
The function of a cyber-physical system is a graph , where the set of verices of ; the set of arrows of ; and . represents the admissible behaviors, i.e., functionality, non-functional attributes, and interface interactions, based on the requirements in , defines the admissible decision flow allowed by , and the possible directionality between admissible decisions that exist in .
Definition 3 (System Structure)
The structure of a cyber-physical system is a graph , where is the set of vertices of ; is the set of arrows of ; , and is the set of descriptors of . represents the components of a cyber-physical system that implement the admissible behaviors defined by , the information flow communication links to fully implement the admissible behaviors defined in , the directionality of the possible cyber or physical interactions between components, and the associated cyber attributes, i.e., properties, for a given vertex or interaction that map to potential attack vectors.
In this instance, the mission requirements are encoded in requirement diagrams, the system function is encoded in activity diagrams, and the system structure of the CPS is encoded in internal block and block definition diagrams. Thus, we utilize all three fundamental categories in SysML, namely, behavior, requirements, and structure diagrams. These define the primitive artifacts in mission aware.
Definition 4 (Mission Specification)
The mission specification of a cyber-physical system is a graph , where such that completing the specification by including all the information presented in the mission requirements, how those relate to the system function, and finally how they are realized through the system structure; the set of arrows that define associativity between any of the elements presented in the vertices that compose the mission, i.e., mission requirements, system function, and system structure; define the directionality of the arrows in , and the descriptors derived from system structure, , such that .
The implication of the mission specification definition is that once all primitive artifacts are constructed, the mission requirements are traced to their necessary behavioral and architectural elements. This constructs a fully traceable model without changing the completeness of the model. This way, we are able to potentially reduce the number of architectural components that are assessed for their security posture. It follows that if the analysis is systematic, the number of security tools or resilient preemption and mitigation strategies can be reduced to just the architectural components that are present in and not necessarily the full graph .
Definition 5 (Attack Vector Space)
An attack vector space is a graph , where the set of vertices of AV; is the set of relationships of AV, , in which represents the attack vectors, the related attack vectors of a given component, the directionality of the relationship, that is which one is more abstract, and the possible types of a relationship between two vertices.
We model possible attacker actions through the attack vector graph defined above. This model captures all information relevant to the system (as defined in the war room) and its mission but is largely a superset that is constructed by using public vulnerability repositories. For example, in the case that CAPEC, CWE, CVE are used for the analysis, then the vertices, , will be instances of each of the databases and the arrows the relations between entries. We introduce the concept of types, , that further categorize what a relation means. These can take the form of intrarelationship if they are within the same database and interrelationship if they are not. We assume that the text that describes each entry is encoded in each vertex within .
Vi-B Finding Applicable Attacks
One of the major subgoals of mission aware is to assess the security posture of a CPS model so that we can ultimately produce systems that are secure by design with respect to mission objectives. To do so we need to be able to map attack vectors from the attack vector space to subsystems from the system structure. Therefore, we require a clear formalism that defines the path in which attacks match subsystems. We term such a path the attack chain, which not only defines orphan nodes or single edges but also, possible sequential attacks that could lead to full mission degradation even if the attacks applied singularly would not.
Definition 6 (Evidence)
The evidence associated with a given system structure vertex or arrow is a function , where is the set of descriptors specified in and the power set of the vertices describing the attack vectors in .
An immediate consequence of the definition for evidence is that the set of attacks associated with a descriptor, , will produce a variety of evidence, some of which is relevant and some of which is irrelevant. Specifically, some evidence is applicable to the subcomponent and therefore the system architecture, while some of it will be false-positive entries associated with that system, , and specifically with some descriptor, .
Definition 7 (Relevant Evidence)
Relevant evidence is evidence that is truly applicable to the mission and its corresponding system, i.e. the true-positives that result from the function . A piece of evidence’s relevance is a function of both the descriptions in the attack vectors and the descriptions of the system components. However, an attack, , such that is in , may not be applicable due to other aspects of the system component that contains . Therefore, relevant evidence is a function , where .
A descriptor, , is unique and applies to a single element of a system; even if multiple components have the same or similar attributes, a namespace demarcates the descriptor for those components. The method of how these descriptors are chosen to sufficiently represent a component and how they map to potential attacks is described by Bakirtzis et al. .
Property 1 (Attack Chain)
Let the system structure graph be . An attack chain in is a path, denoted , which is a head-to-tail sequence
of arrows in , denoted . This path is constructed if and only if there exists an attack vector belonging in the attack vector space that can attach to a given arrow or vertex. Any given set of vulnerable paths in is denoted by:
A single attack at any given vertex defines a trivial path , while a single attack on an edge defines a path of length . These define the canonical isomorphisms and .
Vi-C Mission Impact
An important notion in mission aware is that of mission impact. This impact trace spans across the primitive artifacts that define the mission specification and can inform analysts and stakeholders about the possible mission-level violations in the presence of a specific attack or attack combination. This is a property of the top-to-bottom modeling approach, which is encoded in the mission specification graph .
Property 2 (Impact Trace)
Let the mission specification graph be . Then, the impact trace is a path in that spans across the architecture, functions, and requirements associated with the mission specification. This path is denoted , which is a head-to-tail sequence
of arrows in , denoted . This path is constructed if and only if there exists evidence for a given architectural element in . Any given set of impact traces in is denoted by:
Ultimately, the set of impact traces, , is the result of the analysis that is reported to the stakeholders and facilitates which preemption and mitigation strategies will be utilized to assure mission success.
Vi-D Standard Input to Other Analysis Techniques
By constructing this formalism, we are able to encode all inputs of our analysis in a common format, that is GraphML . GraphML is one of the more mature graph formats. It is, also, valid XML thus allowing us to use standard general-purpose libraries to easily parse and modify it, and is fully extensible.
In general, there are two specific reasons for adopting graph theory as a common language of system security assessment. The first reason is to allow us to define certain properties and constraints of mission aware. The second reason is to share a standard schema for encoding and accessing such types of information.
|L1||Loss of resources, e.g., human, matériel, due to inaccurate, wrong, or absent information|
|L2||Loss of classified or otherwise sensitive technology, knowledge, or system(s)|
|L3||Loss of strategically valuable matériel, personnel, or civilians due to loss of control of system(s)|
|Hazard||Worst-case Environment||Associated Losses|
|H1—Absence of information||Imminent threat goes undetected||L1: Manpower, matériel, territory, etc.|
|H2—Distributing wrong or inaccurate information||Threat is incorrectly identified or characterized||L1: Manpower, matériel, territory, etc.|
|H3—Loss of control in unacceptable area||UAV is lost in enemy territory and suffers minimal damage in crash/landing||L2, L3: Compromise of critical systems, intelligence, and/or other potentially classified information or technology|
|Control Action||Not ProvidingCauses Hazard||ProvidingCauses Hazard||Incorrect Timingor Order||Stopped Too Earlyor Applied Too Long|
|CA 4.1Move control surface||H1, H2, H3: UAV does not avoid inappropriate area, or field of view not adjusted properly||H1, H2, H3: UAV enters inappropriate area||H1, H2, H3: UAV fails to avoid inappropriate area||H1, H2, H3: UAV temporarily enters inappropriate area|
|CA 4.2Take picture or collect data||H1, H2: Needed information not collected||H1, H2: Wrong information collected||H1, H2: Needed information not collected||H1, H2: Needed information not collected or inadequate information collected|
|CA 4.3Send data/feedback||H1, H2: Information not supplied to controller||H2, H3: Wrong information sent to controller||H1, H2, H3: Information not sent to controller at correct time||H1, H2, H3: Inadequate information sent to controller|
|Related Control Action||Safety Constraint|
|SC 4.1Move Control Surface||Control surfaces shall only move upon receiving authentic commands from the flight control system|
|SC 4.2Take Picture or Collect Data||Data collection shall only occur upon authentic command from the operator|
|SC 4.3Send Data/Feedback||The component shall relay collected data or send feedback to the appropriate monitors at regular intervals|
We evaluate the methodology in a military use case, specifically an Unmanned Aerial Vehicle (UAV) reconnaissance mission. We start by producing the results of the war room structured discussion and continue by applying STPA-Sec hazard analysis to identify the losses, hazards, and control actions associated with the mission. This allows us to create representative models of the mission, behavior, and structure in requirements diagrams, activity diagrams, and internal block definition and block definition diagrams in SysML respectively, which we then represent as graphs through GraphML. Through the graph structures we produce the evidence for the mission-critical components, potential vulnerable paths, and impact traces.
Vii-a Experimental Setting
We start by producing the war room artifacts through a structured elicitation of information. First, we produce the mission and system description by conducting a structured discussion between stakeholders. (In this case segmented to groups acting as military commanders, system designers, and analysts.) Once this is completed the analysts further query the rest of the mission stakeholders about the specific mission objectives, potential causes of failure, and other various hypothetical scenarios, such as impact of system functionality loss. Through this structured discussion the stakeholders provide the analysts with the possible threat-space associated with the specific mission. This recorded, informal information produced by the war room allows the analysts to produce a systems-theoretic hazards analysis where a more formal model begins to emerge to describe potential consequences and disturbances to the mission given a system fault (intrinsic to the system or constructed maliciously by an intelligent threat actor).
The output of the hazards analysis is then represented in a tabular format. The information present in those tables is encoded in the SysML model of the mission requirements in requirements diagrams, admissible functional behaviors in activity diagrams, and system architecture in block definition diagrams and internal block diagrams using the standard semantics provided in each diagram definition. The subsequent modeling step is to produce the complete mission specification by creating the traces between all model domains in the requirements diagram to encode the rest of the information provided by the war room and hazard analysis.
Finally, following the definitions in Section VI, we represent the mission requirements as the graph , the system functions as the graph , and the system structure as the the graph . Through these primitive artifacts we construct the mission specification as the graph and use the system structure to find all evidence that can violate the mission objectives and admissible behaviors. This evidence, constructed through cve-search,444CVE-SEARCH PROJECT, cve-search.org is then assessed as relevant or irrelevant by the analysts, the relevant evidence then constructs the attack vector space graph, . Relevant evidence from is then used to find potential vulnerable paths, in the system structure, that can violate mission objectives in and produce the impact traces with the highest likelihood of mission degradation, .
The war room exercise begins with the definition of a tactical reconnaissance mission utilizing a small UAV with an on-board imagery payload. This particular mission requires that military commanders receive visual information about enemy activities, or lack thereof, in an area of interest to support other future or ongoing missions. Mission failures results from the absence of the reconnaissance information that the UAV would provide. Thus, the GPS and imaging payload are the critical components to mission success since the visual information needs to be linked to a location. Furthermore, vehicle loss or capture is of little concern if the reconnaissance information is relayed up to that point because of the UAV’s small size and lack of strategically sensitive information. The military commanders indicate that failing to receive the reconnaissance information would require either a manned secondary mission or the supported mission go without the information; both are undesirable alternatives.
The most likely threats are a function of inputs from the stakeholders and the experience of the attack analysts. In this case, denial-of-service style attacks pose the greatest threat to the failure of the UAV mission and would likely be an adversary’s preferred method of attack. This is due to the supportive nature of the tactical reconnaissance mission, which would give an adversary little time to be aware of the mission or plan a persistent attack to meaningfully impede mission success.
Using the information from the war room, we conduct consequence and disturbance analysis using STPA-Sec as described in Section IV. In this mission, the information collected and distributed by the UAV is of more importance than the UAV itself, hence the top priority unacceptable loss is the loss of life or other resources due to the lack of or inaccuracy of the UAV reconnaissance as indicated by the war room stakeholders. Furthermore, the war room informs the remaining unacceptable losses, which are placed in order of decreasing priority (Table I). Next, the STPA-Sec analysis produces a set of hazardous conditions that could lead to these unacceptable losses (Table II). These hazards do not necessarily lead to the unacceptable losses mentioned above; the occurrence of these hazards, however, is an indicator of possible full mission degradation.
After identifying the hazards that could lead to an unacceptable loss, we identify the conditions under which a particular control action becomes hazardous. These control actions show how different actors or controllers within the system alter the behavior of a lower level component or controlled process. For example, the UAV pilot sets and controls the flight plan of the UAV. For the purposes of this paper, a fragment of the control actions and their hazardous circumstances are outlined (Table III). The component-level in this case refers to the UAV’s subsystems: its control surfaces and payload.
We further identify a set of safety constraints for the subset of control actions (Table IV). These constraints serve as a mechanism to help prevent the system from entering a hazardous state without the consent of the operator. This information is modeled in SysML555The full SysML model will be distributed online and referenced here. Because of the size of the diagrams we cannot include them here. as system behavior that needs to be preserved in order to ensure mission success. While SysML provides a common framework to construct and modify models by Systems Engineers, our analysis is exercised by utilizing the graph structures and the evidence associated with them.
For the UAV mission, we produce the graphs , , , and but present only the ones applicable to the vulnerability analysis and impact trace, namely, and (Fig. 4 and Fig. 5). Using the information present in graph we take the descriptors of , and through evidence and rel-evidence we produce the potential attacks (Fig. 6).
We now examine the system structure and mission specification, . At this stage the analyst can already observe several paths that are going to cause partial or full mission degradation. The final piece of information to find the subsystems most critical to the mission is the subgraph of that’s constructed through the war room elicitation and further refined using the system architecture (Fig. 6). This leads us to segment out three subsystems: (1) Global Positioning System (GPS), (2) XBee radio communication, and (3) GoPro Hero5 camera. The first is concerned with the flight control system. The second is concerned with the ground control station, flight control system, and imagery payload. The third is concerned with just the imagery payload. In a different simulated mission we might have concluded that a different set of subsystems was critical for the same system architecture, .
GPS. The attack vectors associated with the GPS are CVE-2016-6788 and CVE-2016-3801. While both of them are targeting the Android operating system it is possible to misconfigure the implementation of the UAV to be exploited in such a manner. Since our analysis starts early and is exercised often in a system’s lifecycle we can be conservative with what we consider a vulnerability, so that we can report it back to the war room. The first attack vector can violate the communication based on I2C based on the Mediatek 3339 present in the GPS and the drivers that are necessary for it to operate. The second has to do with crafting an application to increase the attackers privilege level within the system structure. This would require operator action. The set
contains all relevant evidence from AV for the GPS. It also shows that attacks can be used individually or in combination. Using this set of attacks in combination would yield complete violation of the GPS but also the primary microcontroller ARM STM32F4. Hence the two attacks used in sequence would construct the attack chain,
This specific attack chain, if successful, would cause mission degradation by violating the flight control system based on the mission specification and would construct the impact trace,
Furthermore, the CAPEC and CWE entries present in inform the analyst about classes of weaknesses or general attack patterns that might derive from the reported CVE entries. These can then be encoded more concretely in the requirements documentation and handled at the deployment phase appropriately. In this case, CWE-264 is a category of weaknesses for “Permissions, Privileges, and Access Controls” and CAPEC-17 an attack pattern “Accessing, Modifying or Executing Executable Files.” This way, the analyst can report the results more concretely to the stakeholders and discuss about potential classes of attack vectors instead of specific instances of them.
XBee. The imagery payload communicates with the ground control station by utilizing the XBee radio module, which in turn requires the use of the ZigBee protocol to communicate to the Beaglebone Black imagery processor. A potential attack that can violate the imagery processor is directly correlated with the drivers it needs to run in order to properly implement the ZigBee IEEE 802.15.4 protocol. Two potential attacks present in relevant evidence from are CVE-2015-8732 and CVE-2015-6244 (Fig. 6). The two attacks rely on two separate bugs on the driver implementation but have the same causal effect, namely, that an attacker can send a set of packets that cause out-of-bound read and application crashes, which results in a successful denial-of-service. The corresponding CWE-20 “Improper Input Validation” and CAPEC-10 “Buffer Overflow via Environment Variables” further define the possible type of violation. Similarly with the GPS the evidence is,
In this instance the attack chain is reliant on the use of multiple XBee devices,
where and the impact traces associated with this violation are:
GoPro Hero5. The reconnaissance mission depends on the camera. The GoPro Hero series is reported to be susceptible to hijacking variables on start and restart operations that are controlled by the ground control station and are likely to be executed in flight. There are two attacks from the relevant evidence in applicable to this camera, CVE-2014-6433 and CVE-2014-6434. The first allows any arbitrary code to be run during the start command of the camera. The corresponding CWE-94 “Improper Control of Generation of Code (Code Injection)”, CAPEC-35 “Leverage Executable Code in Non-Executable Files”, and CAPEC-77 “Manipulating User-Controlled Variables” provide higher-level description of the attack and its side effects. The second allows any arbitrary code to be run on the camera during the restart command and, hence, can cause an attack chain with the Beaglebone Black or simply stop its operation in the duration of the mission. Similarly with the first it is associated with CWE-78 “Improper Neutralization of Special Elements used in an OS Command” and CAPEC-6 “Argument Injection.” Therefore, the evidence
No attack chain can be deduced from the given relevant evidence for this case study. However, there still exists an impact trace,
Mission Impact. From the analysis above the vulnerable paths are:
Finally, we construct the complete impact trace that is going to be reported to the war room for further analysis,
In the case of further defenses or architectural changes are present the analysis can be repeated to take them into account. In this use-case, the system contains no specific set of defenses. This means that it is vulnerable to the full set of relevant evidence. This is not an unrealistic assumption even for safety-critical systems, since there exist deployed systems that consider cybersecurity as an after-thought. This ends up promoting reactive approaches to security, while mission aware is a proactive methodology that is used to design security by design.
mission aware can significantly minimize the amount of inspected subsystems compared to a purely perimeter-oriented approach while also still enabling mission success. mission aware should scale to complex systems, and even systems-of-systems, due to the modeling framework, the evidence associated with the model, and the implication of the evidence on the mission.
Model. The model is constructed in the SysML environment, a language familiar and often used by Systems Engineers to develop large-scale systems. The main motivation behind using SysML is that a designer can easily capture all the domains we utilize in this paper but also that diagram modifications, for example the construction of the mission specification after requirements, admissible behaviors, and system architecture are defined, is possible without having to reconstruct the domains or use different language semantics. It also assists in the graph representation because it relies on a visual language. Additionally, the model transformation, from SysML to GraphML, does not cause any information loss.
Evidence. The evidence collected for a given analysis is dependent on the mission and specifically the threats that are expected to be counteracted during the mission. Therefore, an exhaustive analysis of attack vectors is not necessary. However, since mission aware is model-driven and does not rely on a realized system, the descriptors associated with the corresponding system might produce more evidence than needed. This is the reasoning behind the relevant evidence. Namely, relevant evidence is only the subset of those database entries that is deemed to be truly applicable to the system. This set, as is the case in this paper, is much smaller than the collective amount of evidence an analyst might investigate using a more perimeter-based approach.
Impact. We note that assessing the impact to the mission does not (most of the time) require an exhaustive assessment of the system. Rather, the analyst has confidence that there are certain subsystems that are more important to the mission than others—this is a direct result of using systems theory to find the potential hazards in a top-down fashion from the higher level mission hazards. Ideally, mission aware always produces a set of vertices for the vertices that are derived from . This means that the subsystems directly correlated with mission degradation are a smaller set that the whole system structure.
Viii Related Work
The security community has developed approaches and methods addressing the problem of vulnerability and security assessment varying in intent, scope, and objectives. A relatively recent surge of academic efforts attempt to exercise concepts from dependable and safe computing to the realm of security. Model-based quantitative security analysis with techniques from dependability are motivated by Nicol et al. . Safety and security, however, can often be difficult to assure through a purely quantitative framework , particularly when developing new systems or missions. In contrast, we use STAMP to capture the potential hazardous scenarios the system might face during its deployment and assess the security posture qualitatively by using evidence and the model.
Hong et al.  present a comprehensive survey of graph-theoretic approaches, including but not limited to attack trees, attack defense trees, attack graphs, etc. While our elicitation process and model can assist with any of the above tool-based approaches, we gain new insights by finding the impact to the mission instead of focusing just on the system itself with no awareness of its expected service. Other graph-based approaches target the compliance of policy or standard . Further notable work in this area is described by Chen et al. , where workflows are used to assure the security of the system in a given scenario. Jauhar et al. produce security argument graphs through CyberSAGE models to assess failure scenarios in the smart grid .
Systems-theoretic approaches in the area of safety-critical CPS include STPA-Sec  and STPA-SafeSec . The former is a general methodology that can be applied to any critical system. The latter shows the application of STPA-SafeSec in the context of the powergrid. In this work we utilize STPA-Sec to identify the hazards and encode them in the model but do not limit ourselves to the method. Instead, in this paper the hazards are captured in a hierarchical model to assess the impact of reported evidence, through vulnerability databases, on a specific system architecture. Additionally, Jones et al. propose a technique called System-Aware that follows a system modeling methodology specific to risk analysis through voting techniques using spreadsheets .
Ouchani et al. describe a model-based approach to security using SysML . Their approach relies in representing both the model and the attack in SysML and is simulated within that framework. Lemaire et al. propose a formal verification scheme using vulnerability data and a SysML system description . Brunner et al. proposed a combined model for safety and security based on Unified Modeling Language (UML) diagrams .
In the context of space missions, Pecharich et al. propose a mission-centric approach to analyzing the security posture of systems and how to use the assessment to make informed decisions about system deployment . However, the method and corresponding toolset relies on the construction of attack trees. Similarly, Jakobson presents a more general motivation for a shift from the current methods to mission-centric cybersecurity [4, 23].
Finally, Mead and Woody use existing information about malware to inform, at the early stages of a systems development, the requirements elicitation process . This constitutes an evidence-based elicitation process but requires knowledge of specific malware architectures and how they are used to infect the system under analysis. mission aware could integrate these principles in the war room.
In this paper, we have described a methodology, called mission aware, that is grounded in systems theory as well as evidence-based vulnerability assessment of the resulting system architecture. mission aware provides strategic, model-based cybersecurity analysis, where cybersecurity is framed according to the mission that the technical system is intended to fulfill, and what potential hazards the mission might face. The key innovations of mission aware are:
a formal, traceable modeling framework that captures the mission requirements, admissible behaviors, and architectural elements;
model-driven identification of attack vectors that are applicable to elements of system; and
reduction in the number of system elements that need to be analyzed in order to assure mission success by explicitly focusing the evidence related to mission objectives.
These innovations are achieved by connecting the mission requirements, the admissible functional behaviors, and the system structure that can fulfill the defined service via a guided elicitation process we termed the war room. Both the elicitation process and the resulting outputs are grounded in systems theory and leverage recent work in safety analysis.
All of this information is formally encoded in a mission specification, which uses set-theoretic and graph-theoretic formalisms. The security posture of the overall mission is then directly traced to the security posture of the critical subsystems that relate to potential mission degradation. We assess the security posture of individual subsystems, and their connections, through the use of vulnerability repositories using CAPEC, CWE, and CVE.
As a final observation we note the experience of using a systematic, model-driven process to conduct vulnerability analysis often yields more information than just quantifying the vulnerability aspects of the system. The process itself is an iterative learning experience, allowing circumspection into how a system behaves in response to potential threats and attacks. Therefore, with mission-oriented perspectives we attempt to bring “what-if” analysis across the wide range of stakeholders from command level to acquisition to engineering support. The inclusion of this information into review processes and mission activities can enlighten how managers and operators implement defense capabilities from a mission perspective.
-  F. Frola and C. Miller, “System safety in aircraft management,” Logistics Management Institute, Washington DC, 1984.
-  M. Saravi, L. Newnes, A. R. Mileham, and Y. M. Goh, “Estimating cost at the conceptual design stage to optimize design in terms of performance and cost,” in Proceedings of the 15th ISPE International Conference on Concurrent Engineering. Springer, 2008, pp. 123–130.
-  “Boeing 757 testing shows airplanes vulnerable to hacking, DHS says,” https://perma.cc/KEE4-GLBV, accessed: 2017-11-09.
-  G. Jakobson, “Mission-centricity in cyber security: Architecting cyber attack resilient missions,” in 2013 5th International Conference on Cyber Conflict (CYCON 2013), Jun. 2013, pp. 1–18.
-  M. Hause, “The SysML Modelling Language,” in Fifteenth European Systems Engineering Conference, 2006.
-  J. B. Hong, D. S. Kim, C.-J. Chung, and D. Huang, “A survey on the usability and practical applications of graphical security models,” Computer Science Review, vol. 26, no. Supplement C, pp. 1–16, 2017.
-  N. Leveson, Engineering a safer world: systems thinking applied to safety. Cambridge, Mass.: The MIT Press, 2012.
-  W. Young and N. Leveson, “Systems thinking for safety and security,” in Proceedings of the 29th Annual Computer Security Applications Conference, ser. ACSAC ’13. ACM, pp. 1–8.
-  B. T. Carter, G. Bakirtzis, C. R. Elks, and C. H. Fleming, “A Systems Approach for Eliciting Mission-Centric Security Requirements,” ArXiv e-prints, Nov. 2017.
-  G. Bakirtzis, B. T. Carter, C. R. Elks, and C. H. Fleming, “A Model-Based Approach to Security Analysis for Cyber-Physical Systems,” ArXiv e-prints, Oct. 2017.
-  U. Brandes, M. Eiglsperger, J. Lerner, and C. Pich, Graph markup language (GraphML), 2013.
-  D. Nicol, W. Sanders, and K. Trivedi, “Model-based evaluation: from dependability to security,” Dependable and Secure Computing, IEEE Transactions on, vol. 1, no. 1, pp. 48–65, January 2004.
-  E. Harkleroad, A. Vela, J. Kuchar, B. Barnett, and R. Merchant-Bennett, “Risk-based modeling to support nextgen concept assessment and validation,” Lincoln Lab Report, ATC-405, 2013.
-  G. A. Weaver, C. Cheh, E. J. Rogers, W. H. Sanders, and D. Gammel, “Toward a Cyber-physical Topology Language: Applications to NERC CIP Audit,” in Proceedings of the First ACM Workshop on Smart Energy Grid Security, ser. SEGS ’13. New York, NY, USA: ACM, 2013, pp. 93–104.
-  B. Chen, Z. Kalbarczyk, D. M. Nicol, W. H. Sanders, R. Tan, W. G. Temple, N. O. Tippenhauer, A. H. Vu, and D. K. Y. Yau, “Go with the Flow: Toward Workflow-Oriented Security Assessment,” in Proceedings of New Security Paradigm Workshop. New York, NY, USA: ACM, 2013, pp. 65–76.
-  S. Jauhar, B. Chen, W. G. Temple, X. Dong, Z. Kalbarczyk, W. H. Sanders, and D. M. Nicol, “Model-based cybersecurity assessment with nescor smart grid failure scenarios,” in Dependable Computing (PRDC), 2015 IEEE 21st Pacific Rim International Symposium on. IEEE, 2015, pp. 319–324.
-  I. Friedberg, K. McLaughlin, P. Smith, D. Laverty, and S. Sezer, “STPA-SafeSec: Safety and security analysis for cyber-physical systems,” Journal of Information Security and Applications, Jun. 2016.
-  R. A. Jones and B. Horowitz, “A System-Aware Cyber Security architecture,” Syst. Engin., vol. 15, no. 2, pp. 225–240, Jun. 2012.
-  S. Ouchani and G. Lenzini, “Attacks Generation by Detecting Attack Surfaces,” Procedia Computer Science, vol. 32, pp. 529–536, 2014.
-  L. Lemaire, J. Vossaert, J. Jansen, and V. Naessens, “A logic-based framework for the security analysis of industrial control systems,” Automatic Control and Computer Sciences, vol. 51, no. 2, pp. 114–123, Mar 2017.
-  M. Brunner, M. Huber, C. Sauerwein, and R. Breu, “Towards an integrated model for safety and security requirements of cyber-physical systems,” in 2017 IEEE International Conference on Software Quality, Reliability and Security Companion (QRS-C), pp. 334–340.
-  J. Pecharich, S. Stathatos, B. Wright, A. Viswanathan, and K. Tan, “Mission-centric cyber security assessment of critical systems,” in AIAA SPACE 2016, 2016, p. 5603.
-  G. Jakobson, “Mission resilience,” in Cyber Defense and Situational Awareness. Springer, 2014, pp. 297–322.
-  N. R. Mead and C. C. Woody, Cyber Security Engineering: A Practical Approach for Systems and Software Assurance. Addison-Wesley, 2017.