Mission Aware Cyber-physical Security

TL;DR

Perimeter cybersecurity often fails against coordinated cyber-physical attacks; this paper proposes Mission Aware, a systems-theoretic, graph-based framework that anchors security analysis in mission objectives. It combines stakeholder elicitation, SysML-based modeling across mission $R$, function $F$, and structure $Σ$, STAMP/STPA-Sec hazard analysis, and an attack-vector space built from public repositories ($CAPEC$, $CWE$, $CVE$) to trace evidence to mission requirements. The method yields attack chains and impact traces that identify high-impact vulnerabilities, enabling risk-based defense planning early in the lifecycle. The work demonstrates the approach on a UAV use-case and argues for security-by-design with targeted, evidence-driven mitigation.

Abstract

Perimeter cybersecurity, while essential, has proven insufficient against sophisticated, coordinated, and cyber-physical attacks. In contrast, mission-centric cybersecurity emphasizes finding evidence of attack impact on mission success, allowing for targeted resource allocation to mitigate vulnerabilities and protect critical assets. Mission Aware is a systems-theoretic cybersecurity analysis that identifies components which, if compromised, destabilize the overall mission. It generates evidence by finding potential attack vectors relevant to mission-linked elements and traces this evidence to mission requirements, prioritizing high-impact vulnerabilities relative to mission objectives. Mission Aware is an informational tool for system resilience by unifying cybersecurity analysis with core systems engineering goals.

Figures (6)

• Figure 1: The Mission Aware approach conducts requirements elicitation, hazard analysis, SysML modeling, and analyzes the security posture through evidence and graph representation to provide a holistic mission-centric view.
• Figure 2: The guided stakeholder elicitation seeks different information from varying stakeholders.
• Figure 3: The hierarchy is modeled top-to-bottom and traced bottom-to-top.
• Figure 4: The $\Sigma$ graph represents the architectural topology of the system. This graph is initially constructed in SysML in internal block and block definition diagrams and then extracted to graph form for analysis. (Further information, e.g., descriptors, are not visualized but are accessible through the schema.)
• Figure 5: The $S$ graph represents the full mission specification including the requirements, the subset of applicable admissible behaviors, and the subset of subsystems providing these behaviors. This graph is a one-to-one mapping with the SysML model but some of the information, e.g., mission requirement text or structure descriptors $\mathcal{D}_\Sigma$ are encoded as attributes that can be accessed but are not visually shown. The losses (L) and hazards (H) are encoded in the requirements diagram and are derived from $R$. The safety constraints (SC) and control actions (CA) are encoded in activity diagrams and are derived from $F$. All other elements are part of the system structure $\Sigma$, which is encoded in block definition and internal block definition diagrams. Trace interactions are top-to-bottom following our modeling methodology, while impact is measured bottom-to-top.

Theorems & Definitions (7)

• definition 1: Mission Requirements
• definition 2: System Function
• definition 3: System Structure
• definition 4: Mission Specification
• definition 5: Attack Vector Space
• definition 6: Evidence
• definition 7: Relevant Evidence