A Business-Oriented Approach to Automated Threat Analysis for Large-Scale Infrastructure Systems

Abstract

Security design for large-scale infrastructure systems requires substantial effort and often causes development delays. In line with NIST guidance, such systems should consider security design throughout a system development lifecycle. Nevertheless, performing security design in early phases of the lifecycle is difficult due to frequent specification changes and variability in analyst expertise, which causes repeated rework. The workload is particularly critical in threat analysis, the key activity of security design, because rework can inflate the workload. To address this challenge, we propose an automated threat-analysis method. Specifically, (i) we systematize past security design cases and develop “templates” that organize the system-configuration and security information required for threat analysis into a reusable 5W-based format (When, Where, Who, Why, What); (ii) we define dependencies among the templates and design an algorithm that automatically generates threat-analysis results; and (iii) observing that threat analysis of large-scale systems often yield overlaps, we introduce “business operations” as an analytical asset, which includes encompassing information, function, and physical resources. We apply our method to an actual large-scale operational system and confirm that it reduces the workload by up to 84% relative to conventional manual analysis, while maintaining both the coverage and the accuracy of the analysis.

1. Introduction

Critical infrastructure systems—including electricity, gas, and water networks that underpin modern society—are increasingly vulnerable to cyberattacks, which may result in catastrophic consequences such as loss of life and environmental contamination. Consequently, ensuring robust cybersecurity protection for these systems has become a paramount concern [1]. To address these vulnerabilities, multiple international standards and frameworks have been established to guide infrastructure protection efforts. These include IEC 62443, the international standard for industrial control system security [2]; NERC-CIP, which governs large-scale power generation and transmission facilities across North America [3]; and NIST IR 7628, which provides comprehensive cybersecurity guidelines for smart grid systems [4]. These standards mandate that organizations conduct systematic risk assessments and develop appropriate security countermeasures.

Risk assessment methodology encompasses the identification of critical assets within target systems (assessment scope definition), analysis of potential threats and attack vectors (threat analysis), and quantitative evaluation of associated risks (risk evaluation) [5]. In this paper, these processes are collectively referred to as “security design.” Security design implementation is recommended throughout the entire system development lifecycle. Prior research demonstrates that conducting security design during upstream development phases—specifically requirements definition and basic design stages—substantially reduces rework costs and implementation complexity associated with retrofitting security measures in later phases [6]. For large-scale infrastructure systems designed for extended operational lifespans, early-stage security risk consideration is essential for achieving comprehensive safety and security objectives.

However, upstream development phases present significant challenges for effective security design implementation. System requirements and configurations remain fluid during these stages, resulting in insufficient information for comprehensive analysis. This information deficit complicates efforts to maintain both analytical efficiency and accuracy in security design processes. Empirical observations from actual projects reveal that iterative specification changes during upstream phases necessitate multiple security design iterations. Consequently, delays in security design have emerged as primary contributors to schedule compression across overall system development, establishing workload reduction in security design as a critical industry need.

To address this challenge, this study proposes a novel business-operation-based threat analysis methodology designed to reduce the workload of security design, particularly within the labor-intensive threat analysis process. Unlike conventional manual approaches that rely heavily on expert judgment and iterative rework, the proposed method systematizes previous security design outcomes and structures system configuration and security information into reusable formats based on the 5W framework (When, Where, Who, Why, What). The methodology defines dependencies among 5W elements and incorporates an algorithm that automatically generates threat analysis results from specified information, thereby minimizing reliance on individual expertise. To prevent analytical redundancy, “business operations” are introduced as analytical units that encompass informational, functional, and physical system elements.

A case study conducted on an operational large-scale system demonstrates that the proposed methodology achieves workload reductions of approximately 84% compared to conventional manual analysis approaches, while maintaining analytical completeness and accuracy. This advancement establishes a practical and cost-effective foundation for promoting early-stage security design implementation in long-lifespan infrastructure systems.

Furthermore, comprehensive security design must address requirements across organizational, system, and component levels [7]. This paper specifically focuses on system-level security design, as defined in IEC 62443-3-3 [8], which establishes technical security requirements for integrated system architectures.

The main contributions of this paper are summarized as follows:

• Proposal: Introduction of a novel business-operation-based threat analysis methodology that can be applied in upstream system development phases, enabling systematic and reusable security design.
• Methodology: Development of a structured approach that leverages the 5W framework and an automated algorithm to reduce reliance on individual expertise and minimize redundant analysis.
• Effectiveness: Demonstration through a case study that the proposed method achieves approximately 84% workload reduction compared to conventional manual approaches, while preserving analytical completeness and accuracy.
• Significance: Provision of a practical foundation that facilitates efficient security design from the upstream stages of system development, thereby promoting the construction of secure and resilient infrastructure systems.
• Scope: Focus on system-level security design as defined in IEC 62443-3-3, emphasizing technical requirements for integrated system architectures and industrial applicability.

The remainder of this paper is organized as follows. Section 2 discusses the challenges in security design for infrastructure systems and reviews existing technologies. Section 3 details the proposed business-operation-based threat analysis methodology and its automated algorithm. Section 4 presents the evaluation results regarding workload reduction and analytical accuracy through case studies of actual systems. Finally, Section 5 concludes the paper and summarizes future research directions.

2. Challenges in Security Design for Social Infrastructure Systems

Existing research on security design and threat analysis, particularly within upstream development phases, can be systematically classified into five fundamental categories based on methodological approaches and application contexts. This classification provides a comprehensive foundation for understanding the current state of the field and positioning the contributions of this research.

2.1. Threat Modeling Methodological Approaches

Threat modeling methodologies can be categorized into two primary paradigms: analytical framing and classification approaches that systematically organize threats and attack pathways, and structural model–based approaches that visualize threat scenarios based on system architecture. Analytical approaches, including the 5W framework [9], attack trees [10], and STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Elevation of Privilege) [11], offer broad threat coverage but exhibit substantial dependence on individual analyst expertise, often resulting in variability and iterative rework. Similarly, risk-centric methodologies such as PASTA (Process for Attack Simulation and Threat Analysis) [12], and misuse cases [13] offer broad threat coverage but exhibit substantial dependence on indivisual analyst expertise, often resulting in variability and iterative rework. Simiraly, Template- and case-based approaches [14,15] enable semi-automated threat extraction; however, they still require manual provisioning of target system information, limiting overall workload reduction. Structual approaches utilizing established standards [16,17], security requirements analysis [18], and visual modeling with DFDs (data flow diagrams), sequence diagrams, and BPMN (Business Process Model and Notation) [19,20,21,22,23] enhance visualization and consistency, particularly in collaborative environments.

2.2. Asset Definition and Granularity Frameworks

Asset definition represents a critical determinant of threat analysis scope and analytical granularity. Existing research approaches can be classified into three categories:

(a)

Information-centric approaches [16,17], focusing on confidentiality, integrity, and availability of data.

(b)

Function/component-centric approaches [18], emphasizing vulnerabilities of hardware and software components.

(c)

Business process-centric approaches [19,20,21,22,23,24], extracting threats per workflow or BPMN model.

Process-oriented methods primarily visualize threats along workflow sequences and rely on detailed BPMN modeling, which makes them less applicable during early requirements and design phases. These methods are generally not designed for automation or workload reduction but rather emphasize manual task-level threat mapping. In contrast, this research defines business operations as integrated analytical units that encompass informational, functional, and physical assets, and introduces a systematic 5W-based algorithm for automated threat derivation, enabling practical, reproducible analysis in upstream phases.

2.3. Development Phase Integration Perspectives

The IEC 62443 standard series establishes three hierarchical analytical perspectives—organizational, system, and component levels—providing aligned guidance across development lifecycles [2,8,24]. STPA-Sec (Systems-Theoretic Process Analysis for Security) [25] offers a safety-oriented framework for integrating security considerations during early design phases; however, its hazard-driven scope remains limited for comprehensive threat enumeration. The proposed approach focuses primarily on security rather than safety, targeting systematic threat derivation applicable during the earliest stages of system design.

2.4. Automation and Tool Integration Research

Research on analytical automation through template frameworks and algorithmic approaches has expanded significantly, including IEC 62443 3-3 [8] process automation [24] and BPMN-based automated threat extraction methodologies [19,20,21,22,23]. These developments represent important advances in reducing manual analytical effort and improving consistency. However, most existing automation studies target mid- to downstream phases after system specifications have been finalized. Few approaches address automation capabilities from minimal upstream information inputs (e.g., roles, locations, high-level functions, business objectives), representing a significant gap in current research.

2.5. Industrial Control System-Oriented Research

For industrial control system (ICS) environments, several research initiatives have explored STRIDE-based threat modeling [26], and integrated STRIDE-DREAD (Damage Potential, Reproducibility, Exploitability, Affected Users, Discoverability) evaluation methodologies [27], and automated threat template generation [28]. These specialized approaches address unique characteristics of industrial environments and operational technology contexts. However, they are often domain-specific (e.g., oil refining, power distribution) and exhibit limited generalization and reusability across diverse infrastructure domains. This specialized nature constrains broader applicability and scalability.

2.6. Research Gap and Positioning

Building on the above insights, this research extends analytical applicability to upstream development phases through reusable 5W-based templates and systematic automation, enabling generalized threat analysis from minimal information inputs. It addresses three fundamental limitations in existing approaches:

• Upstream automation: Providing automated threat analysis capabilities from minimal upstream information (roles, locations, high-level functions, business objectives).
• Integrated asset definition: Introducing business operations as comprehensive analytical units that encompass informational, functional, and physical assets.
• Systematic workload reduction: Demonstrating quantifiable workload reduction (up to 84%) while maintaining analytical completeness and accuracy.

This positioning aligns with the paper’s contributions outlined in Chapter 1 and establishes a practical foundation for early-phase security design in long-lifespan infrastructure systems.

3. Proposed Business-Based Threat Analysis Method

We propose a business-oriented threat-analysis method that shortens project schedules in the upstream phases of system development so that security design does not become a bottleneck. Section 3.1 outlines the problem-solving approach; Section 3.2 defines the assets used in this paper; Section 3.3 describes the templates—one of the key compo-nents toward automating threat analysis; and Section 3.4 presents the minimal information to be collected for a target system together with the automation algorithms.

3.1. Policy for Solving the Issues

Security design implementation typically adheres to established international standards and regulatory frameworks. For instance, IEC 62443-3-3 [8] specifies a comprehensive set of security requirements, including foundational measures such as “SR 1.1: Implement authentication.” Previous security design implementations employed detailed threat analysis methodologies that specified granular attacker profiles, such as “meter readers” or “data analysts.” However, empirical analysis revealed that multiple distinct threats frequently converged upon identical security requirement sets. Similarly, comprehensive analysis of additional threat parameters, including attack timing, often produced non–value-adding redundancy. Consequently, iterative detailed analyses do not necessarily yield proportional increases in design value or security enhancement. This research aims to develop an automated threat analysis framework capable of efficiently and comprehensively deriving countermeasure requirements as defined in system-level security design standards, particularly IEC 62443-3-3 [8]. The proposed business-operation-based threat analysis methodology is founded upon three design principles.

• Principle 1: Business Operations as Analytical Assets

Given that threat analysis is conducted for each identified asset, the total number of assets directly correlates with analytical workload requirements. Historical analyses necessitated individual examination of over 200 information assets, resulting in substantial consolidation efforts and resource allocation challenges. To optimize both analytical coverage and operational efficiency, this research defines “business operations” as the primary analytical unit, integrating information, functional, and physical assets into cohesive analytical entities. This research defines”business operations” as the primary analytical unit, int Unlike previous studies that marely treated business processes as contextual elements, this approach formalizes them as reusable analytical assets for security design. This conceptual framework extends previous research by [29], which emphasized business processes as fundamental elements in comprehensive risk evaluation methodologies.egrating information, functional, and physical assets into cohesive analytical entties.

• Principle 2: Systematic Organization of System Information for Threat Analysis

Comprehensive threat analysis requires diverse categories of system-related information, encompassing system configurations, device characteristics, communication pathways, and operational parameters. Prior studies proposed template-based methodologies enabling the systematic reuse of security design knowledge derived from historical implementations [14,15,20,23,28]. Building upon this foundational approach, the present study identifies critical information requirements for threat analysis and develops a structured data collection instrument. This instrument employs compact closed-ended formats (primarily Yes/No) to enable efficient data gathering while maintaining inter-analyst consistency.

• Principle 3: Algorithmic Design for Automated Threat Analysis

Interdependencies exist among the 5W analytical elements (When, Where, Who, Why, What) within threat analysis frameworks. Specifically, the threat occurrence location (Where) significantly influences both attacker motivation (Why) and the nature of threat events (What). The proposed algorithm generates comprehensive threat analysis results by systematically processing structured interview responses according to these established dependencies. This approach leverages the generalized template framework proposed by [29], which integrates system-specific information with predefined threat pattern libraries to automatically generate consistent and comprehensive analytical outcomes.

Based on these methodological principles, the subsequent sections provide detailed descriptions of the proposed business-operation-based threat analysis methodology’s structural components and implementation procedures.

3.2. Asset Definition Framework

3.2.1. Selection of Modeling Notation

We adopted Sequence Diagrams to model business processes because they provide the optimal balance for automated threat extraction. First, regarding structural suitability, unlike BPMN or SysML which lack a strictly unified structure for resource placement, Sequence Diagrams provide “Lifelines” that explicitly map interactions to specific devices. This allows for the mechanical and unambiguous extraction of the “Where”(Asset) attribute. Second, regarding chronological context, unlike DFD which lack temporal information, Sequence Diagrams explicitly capture the chronological order of interactions. This is essential for determining the “Execution Flow” of threats (e.g., distinguishing pre-authentication from post-authentication attacks). While Sequence Diagrams may have limitations in representing internal data processing logic compared to DFDs, we prioritized their ability to structurally define “Where” and “When” for automation purposes.

Based on this notation strategy, comprehensive threat analysis necessitates the systematic definition of “assets” that constitute the analytical scope and serve as the foundational units for threat and risk evaluation. Within this research context, an asset represents the primary analytical entity upon which potential security threats and associated risks are systematically assessed. Traditional methodologies, as specified in established standards including IEC 62443 [8] and ISO/IEC 27005 [16], conventionally treat informational, functional, and physical system elements as discrete analytical targets. However, as contemporary systems exhibit increasing scale and complexity, the proliferation of such discrete elements results in exponential growth of analytical workload requirements. Furthermore, iterative specification modifications during system development lifecycles necessitate comprehensive asset redefinition and reanalysis, thereby generating substantial rework overhead and operational inefficiencies. Empirical observations from previous implementation projects demonstrate that operational characteristics are fundamentally determined by the complex interrelationships among informational, functional, and physical resources. For instance, operations processing confidential data inherently exhibit high confidentiality requirements, while those prioritizing operational continuity demonstrate elevated availability demands. Consequently, this research establishes business operations as the primary analytical assets, comprehensively capturing the interdependencies among informational, functional, and physical resource categories.

3.2.2. Business Operation Definition

Within this analytical framework, a “business operation” represents a cohesive sequence of system processes executed to deliver specific services or functionality. Each business operation encompasses three integrated resource categories: transmitting and receiving devices (physical resources), communication data exchanged between system components (informational resources), and computational functions executed based on processed data (functional resources). Through comprehensive modeling of business operations that integrates informational, functional, and physical resources, this approach achieves balanced and efficient threat analysis while eliminating analytical omissions and redundancies. This integrated perspective enables more accurate risk assessment by considering the holistic security implications of interconnected system components.

3.2.3. Sequence Diagram Modeling Approach

This research adopts sequence diagram methodology as the primary modeling approach for business operations representation. Sequence diagrams provide clear visualization of device interactions (physical resources), information flows (informational resources), and functional execution sequences (functional resources), thereby enabling intuitive comprehension of resource interdependencies and system behavior patterns. Additionally, sequence diagram modeling offers several practical advantages for large-scale system analysis. These include simplified configuration change management, enhanced review processes for system modifications, and maintained analytical practicality across complex systems where multiple operations exhibit intricate interrelationships. The visual clarity and structural consistency of sequence diagrams make them particularly suitable for collaborative analysis and stakeholder communication. Based on these methodological considerations, this study employs sequence-diagram-based business operation modeling as the foundation for systematic threat analysis. To illustrate this modeling approach, Figure 1 presents a representative system configuration example, while Figure 2 demonstrates the corresponding business operation modeling implementation.

3.2.4. Handling Complex Process Structures

Real-world infrastructure systems often involve intersecting, nested, or dynamic processes. To manage this complexity, our method employs a “Scenario Splitting” strategy, which aligns with standard practices in the Requirements Definition and Basic Design phases.

Specifically, instead of using complex conditional operators (e.g., alt or opt fragments) within a single diagram, distinct paths are modeled as separate sequence diagrams (e.g., creating individual diagrams for Success and Failure cases). Similarly, nested or intersecting processes are subdivided and modeled as independent business operations. This approach allows complex dynamic behaviors to be “linearized” into simple, verifiable sequences, enabling the automated algorithm to process them without ambiguity while maintaining comprehensive coverage of system scenarios.

The robustness of this strategy is supported by extensive empirical application. We have deployed this methodology in dozens of actual projects, including automotive manufacturing and railway systems. Throughout these engagements, we have not encountered a single case where business processes could not be modeled using this decomposition approach. This track record empirically demonstrates that the method possesses sufficient adaptability to handle the diverse structural complexities of real-world infrastructure systems.

3.3. Template Structure Construction and Definition

3.3.1. Hybrid Construction Approach

To ensure both practical validity and objective transparency, the template structure was developed using a hybrid approach combining empirical analysis of past security design cases with international security standards. The core threat scenarios were derived empirically from past large-scale infrastructure projects. We adopted a countermeasure-oriented grouping approach, where threat scenarios that led to identical security countermeasures (e.g., mutual authentication, encryption) in actual designs were grouped and generalized. This ensures that every generated threat is “actionable” and directly linked to a practical solution. Building upon the foundational premise that comprehensive security design culminates in systematic countermeasure planning, this research advances the concept of automatically generating threat analysis results through this systematic template composition.

3.3.2. Standardization of Analytical Elements (5W)

To eliminate subjective bias in the definitions, each element of the 5W framework was standardized by mapping it to established security taxonomies (summarized in

Table 1. Threat Characteristics Template except Threads Events (What). Note: ^*1: This template is not required for threat analysis but is necessary for countermeasure planning, so it is retained. ^*2: This template is added to avoid unnecessary threat extraction during threat analysis.

Item	Template
Where	Attack Path Type		Source
			Target
			External Network
	Machine Type	Device	Portable Device
			Stationary Device
		NW device	Wide area network-compatible
			Local area network-compatible
	Intrusion Method Type *1		Local
			Adjacent
			Network
	Functional Complexity Type *2		Single-function
			Multi-function
	Placement Type *2		Internal
			External
When	Development
	Operation
	Maintenance
Who	Authorized Insider
	Unauthorized Insider
	Outsider
Why	Intentional
	Accidental

and

Table 2. Threat Characteristics What-Template [Simple version]. Note: Attacks are represented as a tree: starting from Unauthorized Access on the Source, then either a DoS Attack against the Target or another Unauthorized Access on the Target leading to Spoofing. Each attack is leveled with the corresponding confidentiality, integrity, and availability (CIA) impact. levels. Although the tables presented in this section are simplified for clarity, the actual Knowledge Base employs descriptive definitions based on the MITRE CAPEC taxonomy. Furthermore, distinct “What” tables are pre-defined for each specific combination of the Where Who, Why, and When templates.

Source	Target			CIA
Step1: Unauthorized Access	Step2-A: Denial of Service			A
	Step2-B: Unauthorized Access			-
		Step3-A: Spoofing		C
		Step3-B: Tampering		I
		Step3-C: Privilege Escalation		-
			Step4-A: Spoofing	C
			Step4-B: Tampering	I

):

• Where (Asset Characteristics and Attack Surface): This element characterizes the “Attack Surface” and physical/logical attributes of the target. To ensure objective classification, the attributes in the “Where” template were standardized based on established security taxonomies:

  ○

  Machine Type: The distinction between Portable and Stationary devices incorporates the concepts from NIST SP 800-53 [29] (AC-19: Access Control for Mobile Devices) [A2] and NIST SP 800-124 [30], reflecting the specific physical security risks associated with mobile assets.

  ○

  Intrusion Method: To align with vulnerability assessment standards, the classification of intrusion paths (Network, Adjacent, Local) strictly follows the CVSS (Common Vulnerability Scoring System) [31] Attack Vector definitions.

  ○

  Functional Complexity Type (Refinement): Furthermore, supported by NIST SP 800-82 [32] regarding ICS component characteristics, we distinguish between “single-function” (e.g., sensors, actuators) and “multi-function” devices. Single-function devices typically execute exclusively predetermined control operations with limited external interface availability. Consequently, they demonstrate minimal susceptibility to confidentiality-related threats (e.g., large-scale data exfiltration) compared to multi-function devices (e.g., servers). Incorporating this distinction enables the framework to reduce analytical redundancy by filtering out unrealistic threats for specific device types.

  ○

  Placement Type: The Internal/External classification is based on the NIST SP 800-82 [32] “Zones and Conduits” model and NIST SP 800-53 [29] (SC-7: Boundary Protection), defining whether an asset resides within the trusted management boundary.

• Who (Attacker): This element is mapped to CVSS [31] (Common Vulnerability Scoring System) metrics, specifically focusing on the “Privileges Required” (e.g., Network, Adjacent, Physical) and attacker attributes.
• Why (Motivation): This element categorizes the attacker’s intent, mapped to NIST SP 800-30 [33] definitions (Adversarial vs. Non-adversarial/Accidental).
• What (Attack Description): “What” defines the specific nature of the attack targeting the asset. To ensure comprehensive yet contextual descriptions, we integrated STRIDE (for coverage) with the concept of “Execution Flow” from MITRE CAPEC [34]. While STRIDE categorizes the “means” (e.g., Spoofing), our templates adopt the CAPEC narrative structure to describe the full attack context as a chronological sequence: (1) Prerequisites → (2) Execution → (3) Impact. For example, instead of a static label, a threat is described as: “A privileged insider acquires credentials (Prerequisite) → Impersonates a legitimate user (Execution) → Exfiltrates confidential data (Impact).” This bridging of abstract categories with concrete execution flows ensures the templates are robust for system design.

3.3.3. Functional Classification of Templates

Finally, to implement the automatic generation algorithm, the templates are functionally classified into two categories based on their role in the derivation process:

• Analytical Templates (“Where”): Given that threat occurrence locations exhibit system-specific variations due to differences in device nomenclature and network topology, “Where” serves as an input template (Analytical Template) for internal processing to characterize the target system.
• Output Templates (“Who”, “Why”, “What”): These elements serve as output templates for materializing the analytical results. These templates encapsulate domain-specific characteristics, enabling direct reuse for reporting and result generation.

The comprehensive structure and specifications of these template categories are systematically presented in Table 1 and Table 2.

3.3.4. Maintenance and Expansion Policy

The Threat Knowledge Base is managed through a continuous improvement cycle to ensure its currency and coverage. The expansion process is triggered by two events:

• Project Feedback: When a new threat scenario is identified during manual analysis in actual projects, it is reviewed by a committee of security experts. If the threat is deemed generic and applicable to other systems, it is formalized as a new template and added to the library.
• Standard Updates: The templates are periodically reviewed and updated in alignment with revisions to the underlying standards (e.g., updates to MITRE CAPEC or CVSS metrics). This mechanism minimizes the “proprietary bias” by constantly validating the library against both external standards and real-world field data.

3.4. Target System Information Collection Format and Threat Analysis Algorith

Previous research examined data-conversion templates designed to generalize threat analysis results, enabling the systematic reuse of countermeasures derived from historical security design implementations. This research leverages those established templates for security information processing. For each of the 5W analytical elements, we systematically organized the target system information requirements for comprehensive threat analysis, incorporating the decision hierarchy and interdependencies among the 5W elements (Figure 3).

To minimize dependency on individual analyst expertise, data collection instruments are structured to elicit binary “Yes/No”responses or selections from predefined categorical options. Given that this research treats business operations as the fundamental analytical unit, the temporal element (When) is uniquely determined as “during business operation execution,” enabling focused analysis on the remaining four critical elements.

3.4.1. Information Collection Framework

(1)

Where: Threat Occurrence Point Identification

Threat occurrence point determination requires system-specific information collection for each implementation project. Within infrastructure environments, availability constraints may preclude certain devices from implementing security measures such as encryption or message authentication protocols. Consequently, this research extracts attack pathways as comprehensive sets of potential occurrence points spanning from entry devices (sources) to ultimate targets (destinations). The methodology first systematically enumerates source–destination device pairs and subsequently determines connecting pathways. Source devices are systematically identified through evaluation of whether each device:

• Provides user interface capabilities (e.g., mouse, keyboard, monitor interfaces);
• Supports external media connections (e.g., USB ports, removable storage);
• Maintains Internet connectivity capabilities.

Destination devices encompass all components constituting the business operation asset, as compromise of any constituent device can potentially degrade the asset’s confidentiality, integrity, and availability (CIA) objectives. Attack pathway derivation necessitates comprehensive network topology information acquisition for each project, which is systematically collected through structured interview processes.

(2)

Who: Threat Actor Classification

For each identified occurrence point, appropriate threat actors are systematically assigned. Although previous implementations derived granular internal role specifications (e.g., data collector, system maintainer) from detailed system documentation, prior research [8] demonstrated that system-level countermeasure requirements remain invariant across such role granularities. Consequently, this research simplifies actor categorization into three fundamental classes: Privileged Insider, Unprivileged Insider, and External Actor, applying the standardized actor template established in [8].

(3)

Why: Intent and Motivation Analysis

Motivational analysis is systematically derived from the combination of occurrence point and threat actor characteristics. Previous implementations analyzed diverse motivational factors (e.g., financial gain, retaliation, intellectual curiosity); however, research [8] established that countermeasure planning requirements are adequately distinguished by categorizing threats as non-malicious (error/omission) versus malicious (intentional). Accordingly, this research employs the standardized motivation template from [8]. Given that non-malicious threats occur exclusively where human operators interact with system devices, the methodology additionally confirms operator presence for each device component.

(4)

What: Threat Event Determination

Threat event identification is systematically determined through integration of business operation assets, occurrence points, threat actors, motivational factors, and temporal considerations. Additionally, the CIA value assignment for business operation assets—aggregated from constituent information, functional, and physical resources—influences threat type relevance; therefore, asset CIA characterization must be established prior to analysis. Through application of threat event templates defined in [8] combined with systematically collected system information, this methodology enables comprehensive and efficient threat analysis execution.

Based on these analytical requirements, the target system information collection format is systematically defined in

Table 3. Items of Information to be collected on the Target System.

#	Items to Be Collected		Description
1	Asset		Business operations constituting assets
2	Confidentiality, Integrity, and Availability (CIA) Impact of Assets (Operations)		Impact Level When Confidentiality, Integrity, or Availability of Operations Is Compromised
3	Network configuration		Network Information Accessible by device Composing the Target System
4	Workflow		Information flow exchanged between devices constituting the operation
5	Device constituting the operations	What is the device type?	Is it a network device, a fixed-installation device, or a portable/mobile device?
6		Does it have a IF?	Does the device constituting the operation have a user interface?
7		Can external devices be connected?	Can devices be connected to the device constituting the operation?
8		Is an internet connection available?	Is internet connectivity available for the device constituting the operation?
9		Is an operator present?	Is there an operator available during operation?
10		Is the device single-functions?	Does the device support large-scale recording/logging?
11		Is the device located external?	Is the device in a location accessible to third parties without physical access control?

. Items No. 5–11 require confirmation for each device component constituting the business operation asset.

Table A1. Mapping of Target-System Information Items to 5W Templates.

Map ID	Question ID (Table 3)	Template Field (Table 1 and Table 2)
M-01	Q1	When
M-02	Q2	What
M-03	Q3	WhereAttack Path Type
M-04	Q4	WhereAttack Path Type (Identify candidate targets)
M-05	Q5	WhereMachine Type
M-06	Q6	WhereAttack Pathe Type (Identify candidate sources within the target system)
M-07	Q7	WhereAttack Pathe Type (Identify candidate sources within the target system)
M-08	Q8	WhereAttack Path Type (Access whether Internet-besed entry points may exist)
M-09	Q9	Who
M-10	Q10	WhereFunctional Complexity Type
M-11	Q11	WherePlacement Type

shows which 5W template each question in Table 3 relates to.

3.4.2. Automated Threat Analysis Algorithm

Building upon the established information collection framework, this research developed an automated algorithm that systematizes the threat analysis process through integration of collected system information (Table 3) with 5W-based templates (Table 1 and Table 2). Unlike previous work [8], which employed templates to streamline countermeasure planning without automating the threat analysis process itself, this algorithm formalizes 5W reasoning logic and generates threat events (What) through systematic computational procedures. Crucially, this automation is implemented as a deterministic rule-based algorithm, distinct from probabilistic AI models or Large Language Models (LLMs). This design choice ensures that the analysis is strictly governed by pre-defined logic, guaranteeing the explainability required for safety-critical infrastructure.

The algorithm comprises four integrated procedures aligned with 5W analytical reasoning: Threat Occurrence Extraction (Where, Attacker Extraction (Who), Motive Extraction (Why), and Threat Event Extraction (What). The methodology produces reproducible analytical results through systematic binding of input parameters to established templates. The overall algorithmic structure is presented in Figure 4, with detailed implementation specified in Algorithms 1–3.

Algorithmic Procedures

(1)

Threat Occurrence Extraction (Where)

This procedure systematically identifies attack sources through device property evaluation while treating all devices within business operations as potential compromise targets. The algorithm begins by processing the Target System Info Sheet (Ans), the Sequence Diagram (D), and the Network Topology (Topo) to establish possible attack pathways (Algorithm 1). subsequent processing stages (Algorithm 1).

First, to identify potential attack sources (Srcs), the algorithm extracts devices that answered “Yes” to either “Does it have a IF? (#6)”, or “Can external devices be connected? (#7)” are extracted as candidate attack sources. If the answer to “Is an internet connection available? (#8)” is “Yes,” the Internet itself is also treated as an attack source (Algorithm 1 Lines 4–7).

Next, all devices composing the business operation (Devs) are treated as attack target candidates. For each source–target pair, the algorithm enumerates all possible attack paths based on topology. Each path is then classified into an attack-route pattern (rp): “Direct” for immediate connections, “External” for paths originating from the Internet or segments labeled as external (based on Q11), and “Internal” for other interior paths (Algorism Lines 11–19). An example of this process for the production monitoring operation (Figure 2) is summarized in

Table 4. Example Responses to Information Items for Extracting “Where”.

Target System Info	Answer Results
	Production Control Server	Client PC	Data Historian	Monitoring and Control Server	PLC
Does it have a IF? (#6)	Yes	Yes	Yes	Yes	No
Can external devices be connected? (#7)	Yes	Yes	Yes	No	No
Is an internet connection available? (#8)	Yes	Yes	No	No	No

, and the resulting attack-route patterns are categorized in

Table 5. Examples of Attack Path Pattern Assignment.

Attack Vectors		Attack Path Patterns
Source	Target
Client PC	Data Historian	Source ≠ target
Client PC	Client PC	Source = target
Internet	Monitoring and Control Server	Source = Internet

.

Algorithm 1 Threat Occurrence Extraction

Input: Sequence Diagram D, Interview Answers Ans, Topology Topo Output: List of Potential Attack Paths L_where   1: L_where ← ∅ 2: for each operation op ∈ D do 3:    Devs ← ExtractDevices(op) 4:    Srcs ←{d ∈ Devs|(Ans[d].Q6 = “Yes”∨Ans[d].Q7 = “Yes”) 5:    if ∃ d ∈ Devs: Ans[d].Q8 = “Yes” then 6:      Srcs ← Srcs ∪ {“Internet”} 7:   end if 8: 9:   for each source s ∈ Srcs do 10:     for each target t ∈ Devs do 11:        Paths ← EnumeratePaths(s, t, Topo, op) 12:        for each p ∈ Paths do 13:         if IsDirect(p) then 14:           rp ← “Direct” 15:         else if s=“Internet” ∨ Ans[s].Q11=“External” then 16:           rp ← “External” 17:         else 18:           rp ← “Internal” 19:         end if 20:         L_where.append({op, s, t, p, rp}) 21:        end for 22:     end for 23:    end for 24: end for 25: return L_where

(2)

Attacker Extraction (Who)

For each identified attack pathway, the algorithm assigns standardized actor categories (Privileged Insider, Unprivileged Insider, External Actor) as established in [8] and generates comprehensive combinations of occurrence points and threat actors. This systematic approach ensures complete analytical coverage independent of individual analyst intuition or experience (Algorithm 3).

(3)

Motive Extraction (Why)

The algorithm systematically combines Where (attack path) and Who (threat actors) characteristics to assign intentional motivations for External Actors and both intentional/unintentional motivations for Insider categories. Unintentional motivations are applied exclusively when human operators are confirmed present for corresponding devices, maintaining consistency with [8] findings that mitigation requirements align across these motivational classifications (Algorithm 2).

The results of answering the “Is an operator present?(#9)” is used to extract motives. For example, the results of answering shown in Figure 2 are presented in

Table 6. Example Responses to Information Items for Extracting “Why”.

Target System Info	Answer Results
	Production Control Server	Client PC	Data Historian	Monitoring and Control Server	PLC
Is an operator present? (#9)	Yes	Yes	Yes	Yes	No

Responses marked “Yes” indicate that an insider performed the operation, and thus negligence is also considered to exist. In the example in Table 6, negligence exists except for the PLC.

Algorithm 2 Attacker & Motivation Extraction

Input: Path List L_where, Interview Answers Ans Output: List of Threat Triples L_triples //Note: Each Triple consists of {Where (Path), Who (Attacker), Why (Motivation)}   1:   L_triples ← ∅ 2:   for each entry x ∈ L_where do 3:      //Who (Attacker) Extraction 4:       Actors ← GetCandidateActors(x.source) 5:       for each actor ∈ Actors do 6:           entry’ ← x ∪ {actor} 7: 8:          //Why (Motivation) Extraction 9:           if actor ∈ ExternalCategory then 10:              L_triples.append(entry’ ∪ {Motive: “Intentional”}) 11:          else 12:              src ← GetFirstHop(x.path) 13:              L_triples.append(entry’ ∪ {Motive: “Intentional”}) 14:             //If an operator is present, unintentional errors are also possible 15:              if Ans[src].Q9 = “Yes” then 16:                  L_triples.append(entry’ ∪ {Motive: “Unintentional”}) 17:              end if 18:          end if 19:      end for 20: end for 21: return L_triples

(4)

Threat Event Extraction (What)

This procedure integrates Where (attack path, etc.), Who (threat actors), Why (motivation), and business operation asset CIA values to systematically match What (threat event) templates (Table 2) and instantiate concrete threat scenarios (Algorithm3).

Given the answers to “What is the device type?(#5)”, “Is the device single-functions?(#10)”, and “Is the device located external?(#11)”—together with the previously derived combination of When (attack path), Who (threat actor), and Why (motivation)—the algorithm selects the most appropriate What (threat event) by joining against the What-template primary key {route_pattern, route_context, actor, motive, device_type, machine_type, deploy_loc, CIA}.

In particular, for Q10 = Yes (single-function device), the algorithm suppresses confidentiality-only variants because such devices (e.g., PLCs) typically do not retain large volumes of sensitive information. For example, as illustrated in

Table 7. Example Responses to Information Items for Extracting “What”.

Target System Info	Answer Results
	Production Control Server	Client PC	Data Historian	Monitoring and Control Server	PLC
What is the device type? (#5)	Stationary Device	Stationary Device	Stationary Device	Stationary Device	Stationary Device
Is the device single-functions? (#10)	No	No	No	No	Yes
Is the device located external? (#11)	No	No	No	No	No

, single-function PLCs are not used as high-capacity data stores; therefore, confidentiality-focused threats are not instantiated for this class of device. For Q5 (machine type), the concrete threat content varies across network equipment, fixed-installation equipment, and portable/mobile equipment, and the template match reflects these differences. For Q11 (deployment location type), devices located externally are more readily reachable by non-organizational parties, so the candidate threat set is adapted accordingly via the deploy_loc key. Representative threat-analysis outputs produced by this selection logic are partially reported in Section 4 (Evaluation).

Algorithm 3 Threat Event Extraction

Input: Threat Triples L_triples, Asset Values CIA, Knowledge Base KB, Interview Answers Ans Output: Final Threat List T_final 1: T_final ← ∅, Seen ← ∅ 2: for each t ∈ L_triples do 3:    dev ← DecisiveDevice(t.path) 4:    Context ← ExtractContext(t, Ans[dev]) 5: 6:   //Ambiguity Resolution/Pruning Rule 7:   //Skip confidentiality threats for simple single-function devices unless sensitive 8:    if Ans[dev].Q10 = “Yes” and CIA[t.op] = {“C”} then 9:      if not (HoldsSensitiveData(t)) then 10:        continue 11:     end if 12:   end if 13: 14:   Matches ← QueryKB(KB, Context) 15: for each ev ∈ Matches do 16:   sig ← (t.op, t.path, t.actor, t.motive, ev) 17:      if sig ∉ Seen then 18:        T_final.append(sig) 19:        Seen.add(sig) 20:      end if 21:   end for 22: end for 23: return T_final

Algorithm Implementation Notes

The proposed algorithm accepts UML-style sequence diagrams, network topology configurations, and interview responses as inputs. It systematically parses constituent lifelines and message flows identify potential attack paths (L_where and attribute them to specific actors and motives (L_triples). Subsequently, during the template matching process, the system queries the Knowledge Base (implemented as the What Template CSV repository) using the extracted contexts. This repository contains declarative pattern definitions that map the identified threat occurrence (where, attackers (who), and motivation (why) to corresponding threat events (what). Crucially, the algorithm incorporates ambiguity resolution rules to prune irrelevant threats for single-function devices, reducing false positives.

While representative threat event templates are presented within this research, the complete template repository contains proprietary methodological knowledge and cannot be disclosed publicly due to intellectual property considerations. The algorithm maintains comprehensive internal traceability information; however, the primary exported artifact is the Final Threat List (T_final) (stored as AttackStepList.csv). This output document contains minimal identification parameters, ensuring analytical transparency while protecting proprietary implementation details.

Implementation Availability and Reproducibility

The complete algorithmic implementation and comprehensive threat event template repository remain proprietary and are not publicly available due to their incorporation of specialized business logic and methodological know-how employed in operational security design implementations. Nevertheless, this research provides comprehensive algorithmic structure specifications, input data requirements, and output format definitions to ensure methodological reproducibility to the maximum extent feasible within intellectual property constraints.

Computational Complexity

Since the core logic relies on deterministic pattern matching against a finite set of templates, the computational complexity is linear O(n) with respect to the number of elements (messages and devices) in the sequence diagram. This ensures that the analysis remains computationally efficient and scalable even for large-scale infrastructure systems.

4. Evaluation Framework

This section evaluates the proposed method along two axes aligned with our overarching objective of schedule compression. First, we quantify how much project time (and analyst effort) can be reduced compared to a conventional, manual threat-analysis workflow. Second, because the method automates a business-oriented threat analysis, we assess analytical quality—i.e., coverage and correctness of identified threats—against expert-produced baselines to confirm that no material loss of accuracy occurs.

4.1. Evaluation Methodology and Targets

This section presents a comprehensive overview of the evaluation framework established to systematically verify the effectiveness of the proposed business-operation-based threat analysis methodology. To ensure high fidelity, this evaluation is based on a retrospective analysis of actual project records rather than a controlled laboratory experiment. The evaluation assesses two dimensions: Qualitative Accuracy and Quantitative Efficiency.

4.1.1. Qualitative Accuracy Evaluation Methodology

To evaluate the semantic validity and completeness of the extracted threats, we adopted a comparative analysis approach rather than subjective questionnaires.

• Ground Truth Definition: The threat lists finalized in the actual projects, which passed multiple design reviews by senior security experts, were defined as the “Ground Truth.”
• Verification Procedure: We compared the output of the proposed automation method against this Ground Truth to verify Coverage (whether critical threats were successfully extracted) and Consistency (whether the generated threat descriptions were semantically consistent with expert analysis).

4.1.2. Quantitative Workload Reduction Evaluation Methodology

The experimental conditions for measuring workload reduction were defined as follows:

(1)

Quantitative Workload Reduction Evaluation

• Baseline Procedure ($T_{manual}$)

The baseline values were derived from empirical data collected during the actual project execution. The manual analysis was performed by a team of eight security experts in network security and threat modeling. The manual verification followed a structured protocol using STRIDE and the 5W method. For each device in Use Case X, the researchers performed information gathering, spreadsheet-based asset identification, and threat analysis. Due to the high complexity and scale of the analysis, detailed activity logs were maintained to track the total man-hours and ensured the quality of the outputs.

• Proposed Procedure ($T_{proposed}$)

The proposed method was applied to the exact same scope. The metric $T_{proposed}$ includes the total man-hours required for information gathering, modeling the sequence diagrams, and executing the automation tool.

• Metrics

“Load” is defined as the Man-hours required to complete the workflow. The reduction rate was calculated as (${ T}_{manual}$ − $T_{proposed}$)/${ T}_{manual}$ ×100, where ${ T}_{manual}$ and $T_{proposed}$ denote the total man-hours for the baseline and proposed methods, respectively.

(2)

Qualitative Accuracy Evaluation

To evaluate the semantic validity and completeness of the extracted threats, we adopted a comparative analysis approach rather than subjective questionnaires.

• Ground Truth Definition: The threat lists finalized in the actual projects were defined as the “Ground Truth.” These lists were developed and refined through multiple design reviews by a team of eight security researchers (with experience ranging from 2 to 20+ years, including a lead with 20+ years, three seniors with 8–10 years, and four mid-levels with 5–7 years).
• Verification Procedure: We compared the output of the proposed automation method against this Ground Truth to verify Coverage (whether critical threats were successfully extracted) and Consistency (semantic alignment). The verification followed a structured protocol:

  1.

  Manual Analysis: Researchers independently performed threat identification for each device in Use Cases X and Y using the STRIDE and 5W methods.

  2.

  Comparative Analysis: The automated results were evaluated based on the consistency of the 5W elements. A threat was considered “semantically consistent” only if its 5W components and STRIDE categories matched the expert-generated Ground Truth.

• Documentation: To ensure the reproducibility of the assessment, detailed activity logs were maintained, and the comparison results for each device were summarized in a matrix, providing a transparent view of the overlap between automated and manual analysis.

4.1.3. Evaluation Targets

The evaluation focused on two simplified evaluation systems, designated System (A) and System (B), which were constructed based on actual industrial implementations Case X and Case Y, respectively. These cases do not represent exceptional or atypical scenarios, but rather typical system configurations within their respective infrastructure domains. To verify the method’s adaptability, we deliberately selected these two real-world systems representing fundamentally contrasting architectural characteristics, particularly regarding “Where” attributes and physical accessibility.

• Case X: Electric Power System (System A)
  This case represents an “Open/Public” environment characterized by High Physical Exposure and Mobility. It constitutes a large-scale power control infrastructure involving multiple distributed controllers and servers executing production monitoring and remote metering operations.

  ○

  Characteristics: Operations involve Smart Meters (SM) located outdoors (accessible to third parties) and portable Handy Terminal (HT).

  ○

  Data References: The business-operation assets for evaluation are shown in Figure 5. Representative input data samples collected via the established format are provided in

  Table 8. Response to Information Items for Evaluation System (A).

  Items to Be Collected	Answer Results
  	SM	HT	MDM	MAM
  What is the device type?	Stationary Device	Portable Device	Stationary Device	Stationary Device
  Does it have a IF?	No	Yes	Yes	Yes
  Can external devices be connected?	Yes	Yes	Yes	Yes
  Is an internet connection available?	No	No	No	Yes
  Is an operator present?	No	Yes	Yes	Yes
  Is the device single-functions?	Yes	Yes	No	No
  Is the device located external?	Yes	No	No	No

  . In this evaluation, the security objectives for the target operational asset were defined as Confidentiality: Required, Integrity: Required, and Availability: Not Required. The detailed CIA value assignments for the specific information and functional assets constituting these operations are provided in Appendix B.

  ○

  Verification Methodology: To establish a rigorous “Ground Truth” for this complex environment, a team of eight security researchers (with 5–20+ years of experience, including one lead, three seniors, and four mid-level experts) performed a manual threat analysis. They applied the STRIDE and 5W methods to all operational assets identified in Figure 5. The proposed method’s accuracy was then quantitatively evaluated by comparing its output against this expert-generated baseline, focusing on the semantic consistency of the 5W elements for each identified threat.

• Case Y: Hydroelectric System (System B)
  This case represents a “Closed/Private” environment characterized by Stationary assets. It constitutes a medium-scale energy management system focused on data collection, aggregation, and command transmission functionalities within an Industrial Control System (ICS).

  ○

  Characteristics: Operations involve typical pump controls using single-function devices located within secure facilities (secure zones).

  ○

  Data References: The business-operation assets are shown in Figure 6. Representative input data samples are provided in

  Table 9. Response to Information Items for Evaluation System.

  Items to Be Collected	Answer Results
  	Level Sensor	PLC	Pump	Operator PC
  What is the device type?	Stationary Device	Stationary Device	Stationary Device	Stationary Device
  Does it have a IF?	No	No	No	Yes
  Can external devices be connected?	Yes	Yes	No	Yes
  Is an internet connection available?	No	No	No	Yes
  Is an operator present?	No	No	No	Yes
  Is the device single-functions?	Yes	Yes	Yes	No
  Is the device located external?	No	No	No	No

  . In this evaluation, the security objectives for the target operational asset were defined as Confidentiality: Not Required, Integrity: Required, and Availability: Required. The detailed CIA value assignments for the specific information and functional assets constituting these operations are provided in Appendix B.

  ○

  Verification Methodology: The verification for this case was conducted by a team of five experts: one lead researcher (20+ years of experience), one security researcher (5 years), and three security engineers from the industrial security division. Following the same protocol as Case X, the team performed a manual threat analysis using the STRIDE and 5W methods for all assets depicted in Figure 6. The consistency between these expert-identified threats and the automated results was evaluated based on the semantic alignment of the 5W elements.

By selecting these opposite environments—ranging from complex, distributed public infrastructures to secure, stationary private systems—we aimed to minimize bias toward a specific system configuration and verify the methodology’s generalizability across diverse implementations.

4.2. Accuracy Evaluation Results

The proposed methodology automates threat analysis through systematic clarification of interdependencies among threat elements and required system information collection, incorporating enhanced and extended templates specifically designed for automated threat analysis based on previous research [29]. The analytical accuracy of the proposed approach was systematically verified through comparative analysis between automatically generated results and the manual results produced by the experts described in Section 4.1.3.

To ensure a high-resolution comparison, we focused the evaluation on a representative business operation (one specific workflow) for each case.

In this verification, we compared approximately 2100 threat entries for Case X and 1500 for Case Y. These numbers reflect our granular analysis approach, which defines information, hardware, and functional components as distinct assets. The evaluation measured the semantic consistency of the 5W elements between the automated output and the Ground Truth.

As a result, the evaluation using STRIDE categories combined with unauthorized access classifications revealed no significant differences from the expert outcomes. Thus, the analytical accuracy was considered equivalent and without practical issues (

Table 10. Accuracy Comparison with Security Experts [Evaluation System (A)]. Note: Pattern I: Baseline Procedure, Pattern II: Proposed Procedure, App: Applicable, N/A: Not Applicable.

Threat Category	Means of Analysis	MDM	MAM	HT	SM	HE
Unauthorized Access	Pattern I	App	App	App	App	App
	Pattern II	App	App	App	App	App
Spoofing	Pattern I	App	App	App	App	App
	Pattern II	App	App	App	App	App
Tampering	Pattern I	App	App	App	App	App
	Pattern II	App	App	App	App	App
Repudiation	Pattern I	App	App	N/A	N/A	App
	Pattern II	App	App	N/A	N/A	App
Information disclosure	Pattern I	App	App	N/A	N/A	App
	Pattern II	App	App	N/A	N/A	App
Denial of service	Pattern I	N/A	N/A	N/A	N/A	N/A
	Pattern II	N/A	N/A	N/A	N/A	N/A
Elevation of privilege	Pattern I	App	App	N/A	N/A	App
	Pattern II	App	App	N/A	N/A	App

and

Table 11. Accuracy Comparison with Security Experts [Evaluation System (B)]. Note: Pattern I: Baseline Procedure, Pattern II: Proposed Procedure, App: Applicable, N/A: Not Applicable.

Threat Category	Means of Analysis	Water Level Sensor	PLC	Pump	Operator PC
Unauthorized Access	Pattern I	App	App	App	App
	Pattern II	App	App	App	App
Spoofing	Pattern I	N/A	App	N/A	App
	Pattern II	N/A	App	N/A	App
Tampering	Pattern I	App	App	App	App
	Pattern II	App	App	App	App
Repudiation	Pattern I	N/A	App	N/A	App
	Pattern II	N/A	App	N/A	App
Information disclosure	Pattern I	N/A	N/A	N/A	N/A
	Pattern II	N/A	N/A	N/A	N/A
Denial of service	Pattern I	App	App	App	App
	Pattern II	App	App	App	App
Elevation of privilege	Pattern I	N/A	App	N/A	N/A
	Pattern II	N/A	App	N/A	N/A

).

4.3. Workload Reduction and Development Period Effectiveness Evaluation

This section presents a comprehensive evaluation of the proposed methodology’s impact on overall workload reduction and development period optimization in security design implementations. The evaluation was conducted using an actual large-scale industrial project, Case X (Power Control System), providing realistic assessment conditions. Regarding the system scale, it comprised 15 types of devices, approximately 200 information assets, 60 functional assets, and 25 business assets.

4.3.1. Baseline Performance Assessment

In Case X, the conventional methodology employed traditional 5W-based threat analysis [9]+ STRIDE [11] approaches. Under this baseline approach, approximately 3 person-months were required for evaluation target definition (system modeling) and 7 person-months for comprehensive threat analysis execution, totaling approximately 10 person-months of direct effort (approximately 12.5 person-months including rework activities).

4.3.2. Proposed Methodology Performance

When the proposed business-operation-based methodology was systematically applied to the identical project scope, the complete analytical process—encompassing business-level modeling and automated threat analysis execution—was completed in approximately 1.56 person-months. This represents an approximately 84% reduction in total workload compared to conventional manual approaches. A comprehensive summary of these quantitative results is presented in

Table 12. Effect of the Proposed Method on Case X Duration Reduction.

Work Items		Proposed Procedure		Baseline Procedure
		Whole	1 Business (Average Value)	5W Method + STRIDE (Overall)
Definition of evaluation target	Information gathering & asset modeling	0.84 man-month	2 h	3 man-months
	CIA Value Definition of Assets	0.21 man-month	0.5 h
Threat Analytics	Threat Analytics	0.0008 man-months (about 8 min) (Automation)	0.00186 h (approx. 6.7 s) (Automation)	7 man-months
	Summary of analysis results	0.5 man-month	3 h
Total		1.56 man-month	5.5 h	10 man-months

.

4.3.3. Comparative Accuracy Assessment

The evaluation results demonstrate that the proposed methodology achieved analytical accuracy equivalent to manual expert analysis, with no significant deviations that would compromise operational effectiveness in practical implementations. Furthermore, consistent accuracy levels were confirmed across diverse application domains (Case X and Case Y), indicating robust methodological generalizability.

4.3.4. Asset Granularity Comparison

A systematic comparison was conducted between Pattern I, which treats individual business operations as the primary analytical unit, and Pattern II, which analyzes information, functional, and physical resources as discrete components. Pattern I generated approximately 2100 threat scenarios, while Pattern II yielded approximately 500 threats, demonstrating a 75% reduction in threat enumeration when analysis is conducted at the operational level. Detailed analytical review revealed that the majority of observed differences resulted from variations in asset categorization methodologies rather than fundamental analytical discrepancies. The threat occurrence points and underlying causal factors remained largely identical across both approaches and could be systematically consolidated. Accordingly, as demonstrated in Section 4.3, when viewed from the threat occurrence points (Where) as the starting reference, no differences were observed in the threats derived. Therefore, business-operation-based analysis was confirmed to maintain comprehensive analytical coverage without significant omissions.

4.3.5. Risk Assessment Considerations

When analysis is conducted at the operational level, scenarios where operations process highly confidential data only partially may result in the entire operation being classified as a highly confidential asset, potentially yielding slightly overestimated risk assessments compared to granular component-level analysis. Nevertheless, this level of analytical abstraction proves practically advantageous for facilitating consensus building among system designers and operational personnel in real-world development projects. This operational-level approach effectively aligns stakeholder perspectives across interdisciplinary teams and enables efficient decision-making processes regarding security requirement specifications. The practical effectiveness of this approach has been systematically verified through multiple actual security design implementations.

4.4. Discussion and Practical Validity

4.4.1. Practical Validation and Industrial Track Record

The methodology and associated automation technologies have been deployed in dozens of actual infrastructure projects, including automotive manufacturing plants and railway systems, improving process efficiency and analytical quality. This extensive track record across diverse domains qualitatively supports the method’s robustness beyond the specific configurations evaluated in the quantitative section. Furthermore, the threat templates (Knowledge Base) utilized in this method were constructed from a dataset of past security design cases and countermeasure data. This approach reflects the collective knowledge of experts regarding threats that were deemed necessary to mitigate in actual projects, ensuring that the identified threat scenarios are grounded in practically relevant threats validated through professional security design practices. The template development technology described in Section 3.3 was granted a patent and received the Regional Invention Award (Patent Technology Division) from the Japan Institute of Invention and Innovation (JIII), with support from MEXT and the Japan Patent Office (JPO). Building on this patented technology, the present study extends automation to business operations as integrated analytical units and demonstrates the development of a security design foundation function, confirming the approach’s practical and industrial value.

4.4.2. Limitations and Scope of Application

We identify two primary limitations in the proposed method:

• Trade-off in Granularity: While the proposed method significantly improves efficiency in the upstream phase, the abstraction of assets into business operations implies a trade-off regarding granularity. Specific implementation details (e.g., buffer overflows in specific software stacks) or vulnerabilities independent of operational flows may be homogenized during the modeling process. Consequently, there is a potential risk of underestimating threats that rely on low-level technical specifics. Therefore, this method is best utilized as a screening tool for system-level security design. For critical subsystems or during the subsequent detailed design and implementation phases, we recommend complementing this approach with conventional, fine-grained threat analysis methods.
• Dependency on Knowledge Base Completeness: A fundamental limitation of this rule-based approach is that the analysis accuracy (specifically recall) is strictly bounded by the completeness of the Knowledge Base. Unlike AI-based anomaly detection, this method cannot identify novel threat patterns that do not exist in the predefined templates. Consequently, if the Knowledge Base lacks a specific attack scenario, the analysis will result in a False Negative. To mitigate this, the proposed method relies on the STRIDE model to ensure that, at a minimum, high-level threat categories are comprehensively covered, even if specific novel variants are missed.

5. Conclusions

This research presents a business-operation-based threat analysis methodology that substantially reduces the workload and time required for security design in large-scale system development. The approach targets system-level threat analysis as defined in IEC 62443-3-3, focusing on security design from a system integrator’s operational perspective. In addition, it is designed for upstream development phases, enabling analysis to begin from minimal information inputs. An example of the analysis results is shown in

Table 13. Example results of Threat Analysis of the proposed method. Note: Due to space constraints, elements common to all except “What” have been merged.

#	Asset & When	Where (Source)	Where (Target)	Who	Why	What
1	Remote Meter Reading Business Process	SM	HT	Privileged insider	Intentional	(Step 1) The privileged insider logs in to the source.
						(Step 2) Logging into the target.
						(Step 3) Stealing the target’s confidential information (Information Disclosure).
2		MDM	SM	Privileged insider	Unintentional	(Step 1) The privileged insider logs in to the source.
						(Step 2) Sending requests that cause the target to cease operations.
3, 4		SM	HT	Privileged insider	Intentional	(Step 1) The privileged insider logs in to the source.
						(Step 2-1) Sends a request to collect target information(Information Disclosure).
						(Step 2-2) Sends a request to cause malfunction in the target system(Tamparing).
						(Step 2-3) Sends a request to cause unauthorized behavior in the target system(Tempering).
5, 6		SM	HT	Privileged insider	Intentional	(Step 1) The privileged insider accesses the source.
						(Step 2-1) Sends a request to collect information of the target system(Information Disclosure).
						(Step 2-2) Sends a request to cause malfunction in the target(Tempering).
7, 8		MDM	SM	Non-privileged insider	Intentional	(Step 1) The non-privileged insider accesses the source.
						(Step 2-1) Sends a request to collect target data(Information Disclosure).
						(Step 2-2) Sends a request that causes malfunction or false data transmission(Tempering).
9		SM	HT	External actor	Intentional	(Step 1) The external actor accesses the source.
						(Step 2) Launches a cyberattack on the target system via the source.
						(Step 3) Sends multiple unauthorized requests causing system malfunction or data falsification(Tempering).

; due to space constraints, items common to all except “What” are merged for brevity.

5.1. Research Contributions

By clarifying the minimum information required for comprehensive threat analysis and integrating it with reusable templates from prior work, this study developed an automated algorithm that generates consistent and comprehensive threat analysis results. Defining business operations as the primary analytical unit—encompassing integrated informational, functional, and physical assets—enables balanced analytical completeness and accuracy while significantly reducing redundant analysis efforts.

5.2. Quantitative Validation Results

Applying the methodology to an operational large-scale system demonstrated substantial workload reduction, decreasing total effort for system scoping and threat analysis by approximately 84% (from about 10 person-months to 1.56 person-months). Evaluations across multiple real-world implementations, including representative operational systems with diverse architectural and physical accessibility characteristics, confirmed that the methodology maintains analytical completeness and accuracy without operational compromises. In addition to the representative use cases X and Y, the proposed methodology was also applied to other real-world operational systems in different infrastructure domains. Across these applications, the methodology could be applied using the same analysis process, indicating that it is not limited to specific system configurations or domains and is practically applicable in diverse industrial security design contexts.

5.3. Future Research Directions

While this study confirmed the methodology’s effectiveness in infrastructure domains, its application to fundamentally different fields, such as purely algorithmic financial systems or consumer-facing Web applications, remains a subject for future verification. Consequently, future research initiatives will aim to validate and extend the methodology’s applicability across these diverse domains. Simultaneously, we will focus on developing advanced analytical support techniques to systematically summarize and visualize the extensive threat inventories identified for each operational unit, thereby enabling systematic identification of system vulnerabilities and emergent security trends. Additionally, subsequent investigations will also explore automated assistance capabilities for countermeasure selection and documentation processes to enhance collaborative workflows and reporting effectiveness.

Furthermore, we plan to develop integration frameworks for emerging cybersecurity standards and regulatory requirements. The systematic automation approach established in this research provides a foundational platform for broader industrial deployment and continued methodological advancement.

Research Significance: The proposed business-operation-based threat analysis methodology has demonstrated effectiveness across both academic research contexts and practical industrial implementations, establishing a robust foundation for scalable security design processes. This systematic approach addresses critical industry needs for efficient, accurate, and reproducible threat analysis capabilities while maintaining the analytical rigor necessary for complex infrastructure system security requirements.

The research contributes to the broader cybersecurity field by providing a systematic framework that bridges the gap between theoretical security analysis methodologies and practical implementation requirements in large-scale system development contexts. Through demonstrated workload reduction of approximately 84% while maintaining analytical accuracy, this methodology enables more widespread adoption of comprehensive security design practices during upstream development phases, ultimately contributing to enhanced infrastructure security across diverse industrial applications.

6. Patents

Chiaki Otahara: Hitachi Ltd., Security Design Support Device and Security Design Support Method. Japan Patent JP6342748B2, 2018.

Note: this patent to template development (Section 3.3), which forms part of the idea proposed in this paper.