Data-Flow-Based Extension of the System-Theoretic Process Analysis for Security (STPA-Sec)

Security analysis is an essential activity in security engineering to identify potential system vulnerabilities and achieve security requirements in the early design phases. Due to the increasing complexity of modern systems, traditional approaches, which only consider component failures and simple cause-and-effect linkages, lack the power to identify insecure incidents caused by complex interactions among physical systems, human and social entities. By contrast, a top-down System-Theoretic Process Analysis for Security (STPA-Sec) approach views losses as resulting from interactions, focuses on controlling system vulnerabilities instead of external threats and is applicable for complex socio-technical systems. In this paper, we proposed an extension of STPA-Sec based on data flow structures to overcome STPA-Sec’s limitations and achieve security constraints of information-critical systems systematically. We analyzed a Bluetooth digital key system of a vehicle by using both the proposed and the original approach to investigate the relationship and differences between both approaches as well as their applicability and highlights. To conclude, the proposed approach can identify more information-related problems with technical details and be used with other STPA-based approaches to co-design systems in multi-disciplines under the unified STPA process framework.

💡 Research Summary

The paper addresses a critical shortcoming of the original System‑Theoretic Process Analysis for Security (STPA‑Sec), namely its limited ability to capture data‑centric vulnerabilities in complex socio‑technical systems. While STPA‑Sec improves upon traditional fault‑tree or threat‑tree methods by focusing on system‑level interactions and controlling system vulnerabilities rather than enumerating external threats, it still relies on a control‑loop representation that emphasizes control actions and feedback paths. This representation often overlooks the flow of information, making it difficult to identify confidentiality, integrity, and availability (CIA) issues that arise from data exchange, transformation, and storage.

To overcome this limitation, the authors propose an extension called STPA‑DFSec (Data‑Flow‑Based STPA‑Sec). The core innovation is the replacement of the conventional control structure with a Functional Interaction Structure (FIS). In the FIS, the system is decomposed into “functions” that consume inputs, apply internal algorithms, and produce outputs. Data channels replace control actions, and the surrounding environment and operational assumptions are explicitly modeled as influences on function behavior. This shift enables analysts to view the system from a data‑flow perspective from the earliest design stages.

The methodology follows the familiar STPA workflow but adapts each step to the data‑flow context:

1. Define analysis purpose – Identify system‑level losses, vulnerabilities, and constraints. The authors compile a generic loss taxonomy (life, physical property, non‑physical property, environment) derived from standards such as ISO 26262, J3061, and EVIT‑A. Security attributes are guided by the CIA triad, providing a structured way to elicit potential vulnerabilities.

2. Model Functional Interaction Structure – Build a diagram where each function is linked by data arrows. Inputs and outputs represent the actual information exchanged, while algorithms capture processing logic. This model makes explicit where data is created, transformed, stored, or transmitted, and highlights where security controls must be applied.

3. Identify Insecure Function Behaviors (IFB) – Using a set of guide words adapted from STPA (Not Executed Causes Vulnerability – NECV, Executed Causes Vulnerability – ECV, Timing Issues – TI, etc.), analysts systematically examine each function and its data interfaces to uncover insecure behaviors. A template (Table III in the paper) records the function, guide word, and specific insecure behavior.

4. Derive Loss Scenarios – Connect each IFB to the loss taxonomy, producing concrete causal scenarios that illustrate how a particular data‑flow flaw can lead to a loss (e.g., loss of non‑physical property such as sensitive information). Both “missing or incorrect execution” and “data‑processing errors” are considered.

The authors validate STPA‑DFSec on a Bluetooth digital key system for a vehicle and compare the results with those obtained using the original STPA‑Sec approach. The traditional STPA‑Sec analysis primarily uncovers control‑action‑related hazards, such as failure to send an authentication request or improper command transmission. In contrast, STPA‑DFSec reveals additional data‑centric issues: plaintext transmission of cryptographic keys over the Bluetooth channel, replay‑able authentication tokens, and timing windows that permit unauthorized re‑authentication. By mapping the two sets of findings, the authors demonstrate that both approaches share the same high‑level loss and constraint definitions, but STPA‑DFSec provides richer, more detailed security constraints (e.g., “key‑exchange data must be encrypted in transit”).

A significant contribution of the paper is the demonstration that STPA‑DFSec remains compatible with the broader family of STPA‑based methods (e.g., STPA‑SafeSec, STPA‑Priv). Because all these techniques share a common top‑down framework, the same functional interaction model can be reused to address safety, security, and privacy concerns simultaneously, facilitating multidisciplinary co‑design. This unified modeling reduces duplication of effort, improves traceability of requirements, and helps manage the growing complexity of cyber‑physical systems.

In conclusion, the data‑flow‑based extension enriches the STPA‑Sec methodology by systematically incorporating information‑security considerations, enabling early detection of CIA‑related vulnerabilities, and providing actionable constraints for designers. Future work suggested includes tool support for automated FIS generation, application to other domains such as smart grids or medical devices, and integration with established threat‑modeling languages (e.g., ATT&CK, STRIDE) to further enhance the comprehensiveness of security analyses.