arXiv CS open access

An Emulation Anchored Digital Twin Testbed for Cyberattack and Defense Analysis in Hospital IT OT Environments

2026 · arxiv_cs

arXiv CS · Papers · 2026

cryptography cybersecurity privacy security

Conceptio Open Archive

Analyze & explore related research in Conceptio

Connect this record directly into your research workflow or AI agent. Explore citations across open repositories, query full text, and export structured proof bundles.

Explore in Search →Connect via MCP / API ↗

An Emulation-Anchored Digital Twin Testbed for Cyberattack and Defense Analysis in Hospital IT–OT Environments

In parallel, hospitals rely extensively on Information Technology (IT) systems, such as servers, databases, EHR systems [4], and Personal Health Gateways (PHGs). Communication among healthcare systems and medical devices commonly uses standardized protocols such as FHIR/HL7 [5]. Although IT–OT convergence improves connectivity and operational efficiency, it also introduces cross-domain cyberattacks. A compromised Internet-facing or enterprise IT service may provide an entry point for lateral movement toward OT networks and, consequently, life-critical hospital infrastructure. Vendors regularly release software patches to address functional issues and security vulnerabilities in IT and OT products. However, deploying patches, firewall rules, or artificial intelligence-generated mitigation strategies directly on operational hospital infrastructure can disrupt essential medical services [6]. Fully autonomous cyber-defense mechanisms may also introduce unintended consequences when they alter network access policies or isolate operational components without adequate contextual awareness [7]. Therefore, healthcare cybersecurity requires controlled environments in which defensive strategies can be evaluated safely before deployment and Artificial Intelligence (AI)-generated recommendations can be reviewed by human operators [8]. This need is aligned with the broader transition from fully automated systems toward human–AI symbiosis in industrial decision-making. In safety-critical environments, AI should augment rather than replace human expertise. AI agents can rapidly analyze system states, identify attack propagation patterns, and recommend mitigation actions, while human operators retain supervisory control over decisions that may affect service continuity [9], [10]. Such collaboration is particularly important in hospitals, where an aggressive mitigation action may contain an attack but simultaneously interrupt a critical healthcare service. Existing cyber-physical testbeds primarily focus on Industrial Control Systems (ICS), particularly power grids, microgrids, and manufacturing environments. These platforms often employ simulation tools and Hardware-in-the-Loop setups to analyze OT-centric attacks [11], [12], [13]. Although such approaches provide high-fidelity experimentation, they are often difficult to reconfigure and remain largely limited to specific industrial domains. Furthermore, many existing platforms do not adequately represent the interactions among hospital IT systems, healthcare services, and SCADA-controlled infrastructure. Effective cybersecurity evaluation requires continuous mon-

Abstract—Modern hospitals increasingly rely on integrated Information Technology (IT) and Operational Technology (OT) infrastructures to support critical healthcare services. However, this convergence expands the cybersecurity attack surface and makes safe validation of defensive mechanisms difficult on live systems. Existing testbeds often focus on isolated IT or OT environments and do not capture realistic cross-domain healthcare interactions. This work presents a hospital IT–OT cybersecurity testbed coupled with a digital twin for monitoring, experimentation, and validation of countermeasures. The testbed emulates a central server, Electronic Health Record (EHR) systems, SCADAbased infrastructure, and segmented IT, OT, and DMZ networks. It supports controlled cyberattack execution, software-patch evaluation, and training of RL-based defense agents. The testbed is further extended to a digital twin that models the real-time state of the environment using log and network statistics and enables bidirectional interaction through command execution and container lifecycle orchestration. Modbus/TCP and FHIR/HL7 support realistic communication across healthcare and industrial components. Experimental evaluation shows low computation overhead, with average normalized CPU utilization below 0.4% per container and most lightweight services operating below 0.01%. OpenPLC Modbus TCP operations achieve a median round-trip latency of 0.901 ms. The testbed also captures a multistage SSH-based attack propagating from the DMZ to the IT and PLC networks. The framework provides a foundation for extending the emulated environment toward a hardware-enabled hospital digital twin. Index Terms—IT–OT convergence, ICS security, Security testbed, Cyber-physical systems, Digital twin.

I. I NTRODUCTION Cyberattacks targeting Operational Technology (OT) systems have emerged as a major threat to public services and critical infrastructure [1]. Modern OT environments are exposed to a broad range of attacks, including Man-in-the-Middle (MITM) attacks, command injection, sensor spoofing, replay attacks, Denial-of-Service (DoS) attacks, firmware tampering, and Programmable Logic Controller (PLC) logic manipulation [2]. In hospital environments, such attacks can disrupt lifecritical services, including power distribution, water supply, and Heating, Ventilation, and Air Conditioning (HVAC) systems. These services are commonly monitored and controlled through Supervisory Control and Data Acquisition (SCADA) platforms comprising Master Terminal Units (MTUs), Remote Terminal Units (RTUs), PLCs, and Human-Machine Interfaces (HMIs) [3].

arXiv:2608.17650v1 [cs.CR] 18 Aug 2026

Prashant Rawat, Ravi Kumar Bairagi, Arunima, Geeta Yadav

Prashant Rawat, Ravi Kumar Bairagi, Arunima and Geeta Yadav are with the Indian Institute of Technology Ropar, Rupnagar, Punjab, India. Corresponding author: Geeta Yadav (geeta@cse.iitd.ac.in).

TABLE I L IST OF ABBREVIATIONS Definition

API CPS CVSS DMZ DQN IDS JWT LogQL MDP MRI PACS RBAC RIS RL SOC WAF

Application Programming Interface Cyber-Physical System Common Vulnerability Scoring System Demilitarized Zone Deep Q-Network Intrusion Detection System JSON Web Token Log Query Language Markov Decision Process Magnetic Resonance Imaging Picture Archiving and Communication System Role-Based Access Control Radiology Information System Reinforcement Learning Security Operations Center Web Application Firewall

Abbreviation

tion, and Modeling, followed by the creation and propagation of attack scenarios in the testbed in Section IV. In Section V, we discuss the evaluation of the testbed and the digital twin in detail. We discuss the scope and limitations of fidelity details in Section VI. We conclude the paper in Section VII. We list the abbreviations used in the paper in Table I.

itoring and command-and-control capabilities to observe system behavior, assess attack impact, and evaluate defensive actions without disrupting the experimental setup. Digitaltwin capabilities provide a useful foundation for this purpose by enabling dynamic system-state representation, monitoring, and controlled interaction with cyber-physical components. Recent digital-twin research has explored formal modeling and system-level abstractions [14]; however, existing solutions remain predominantly manufacturing-oriented and often lack a security-driven and human-centric focus [15]. This work addresses these gaps by developing an emulation-anchored hospital IT–OT cybersecurity testbed with digital-twin capabilities. The platform provides a reproducible representation of hospital IT and OT components, supports continuous monitoring, and enables controlled interaction through command execution and container lifecycle orchestration. We use the term emulation-anchored testbed to avoid implying real-time bidirectional synchronization with a deployed hospital infrastructure. Extending the platform toward live integration with physical devices and operational systems remains part of future work. The proposed environment supports realistic multi-stage cyberattack scenarios and controlled evaluation of AI-assisted defense strategies. As a proof of concept, a Reinforcement Learning (RL) agent is trained to mitigate SSH-based bruteforce attacks by learning firewall-hardening policies over multiple training episodes. The agent demonstrates how AI can support security operators by rapidly identifying appropriate mitigation actions. To support this transition, the proposed architecture provides the control and audit mechanisms required for future humansupervised defense. By securely logging events and enabling granular command-and-control, the testbed serves not only as an experimentation platform but also as a foundational infrastructure for studying trustworthy, risk-aware, and humanin-the-loop cybersecurity workflows. Contributions: The main contributions of this work are as follows: • Design and implementation of a unified emulationanchored hospital IT–OT cybersecurity testbed integrating enterprise systems, healthcare services, and SCADAbased industrial components. • Development of digital-twin capabilities for continuous monitoring, system-state representation, command execution, and container lifecycle orchestration. • Implementation of a realistic multi-stage cross-domain attack scenario demonstrating lateral movement from an Internet-facing network through the IT environment toward PLC-controlled OT infrastructure. • Training and evaluation of an RL-based cyber-defense agent that learns firewall-hardening policies to mitigate SSH-based brute-force attacks. • Development of control and audit mechanisms within the digital twin architecture, establishing the foundational infrastructure required for future human-supervised, AIassisted cybersecurity decision support. Paper organization: In Section II, we study related work in brief. In Section III, we discuss Testbed Design, Implementa-

II. R ELATED WORK A. Cyber-Physical Testbeds and Digital-Twin Capabilities Cyber-physical testbeds provide controlled environments for analyzing attacks, evaluating defensive mechanisms, and studying the operational consequences of cybersecurity decisions. Existing testbeds have predominantly focused on Industrial Control Systems (ICS), particularly power grids, microgrids, and manufacturing environments. Table II summarizes representative studies and compares their domains, architectures, supported attacks, strengths, and limitations. O’Toole et al. [11] present a cyber-physical testbed that integrates an energy management system with the OPALRT real-time power-system simulator. The platform supports the emulation of grid behavior and enables the evaluation of attacks such as false data injection and Denial-of-Service (DoS). Communication among cyber and physical components relies on protocols such as DNP3 and IEC 61850. By employing an IEEE 14-bus system, the testbed demonstrates the importance of coordinated cyber-physical modeling for attackimpact assessment. Park et al. [12] develop a Hardware-in-theLoop (HIL) testbed for Distributed Energy Resources (DERs). Their platform incorporates physical hardware and Real-Time Digital Simulator (RTDS)-based components to evaluate cyberattack resilience. The study uses a cyber kill-chain model aligned with the MITRE ATT&CK framework to analyze multi-stage Advanced Persistent Threats (APTs). This work demonstrates the value of hardware-assisted environments for high-fidelity experimentation. Wu et al. [16] further extend hybrid cybersecurity experimentation by integrating industrial hardware with simulated ICS components. Their platform evaluates protocol-level attacks, including GOOSE-message spoofing in an IEC 61850enabled environment. Protocols such as Modbus and DNP3

TABLE II C OMPARISON OF C YBER S ECURITY F OCUSED T ESTBEDS FOR ICS Domain

Testbed Type

Key Components

Attacks Studied

Strengths

O’Toole et al. [11]

Power Grid (IEEE-14)

Real-time HIL

EMS, Network Sim, OPAL-RT, RTU/IEDs, IDS

False Data Injection, Denial-of-Service

Scalable design, IDS integration

Park et al. [12]

Distributed Energy

Hardware + RTDS

DERMS, Inverters, ESS, Aggregator

APT chain, penetration tests

Strong attack modeling; detailed kill chain

Wu et al. [16]

Hybrid Microgrid

Hybrid Simulation + IEDs

ABB relays, switches, hybrid infra

GOOSE spoofing, microgrid threats

Industrial devices; practical demo

Oyewumi et al. [17]

Smart Grid

Large-scale hardware

RTDS, substations, SEL IEDs, SDN

Wide-area attacks

Realistic, scalable multi-substation setup

Fritz et al. [18]

Synchrophasor System

Simulation (FPGA)

PMU, PDC, FPGA

MITM manipulation; phasor tampering

Novel FPGA model

Our Paper

Hospital IT–OT

Docker simulation

MTU/RTU, PLCs, HVAC sim, WAF, PHG, DMZ

MITM; PLC maniupulation

IT–OT integration; patch & WAF testing

Author(s)

facilitate communication across the testbed. The combination of physical and simulated components improves experimental realism and enables detailed analysis of industrial communication vulnerabilities.

Oyewumi et al. [17] present the ISAAC testbed, which supports large-scale cyber-physical experimentation across multiple substations. The platform integrates RTDS-based grid simulation, SCADA components, software-defined networking, and wide-area monitoring. Its modular architecture supports scalable experimentation and the evaluation of distributed cyberattacks. However, such hardware-intensive environments are costly to deploy, difficult to reconfigure, and primarily tailored to power-system use cases.

Digital-twin research provides a complementary foundation for monitoring and controlled interaction with cyber-physical environments. Tao et al. [19] identify four important modeling dimensions for digital twins: geometry, physics, behavior, and rules. They further classify digital twins according to unitlevel, system-level, and system-of-systems representations. Such frameworks provide a structured basis for describing complex environments, although much of the existing work remains oriented toward manufacturing applications.

Fritz et al. [18] adopt a simulation-oriented approach for studying attacks on synchrophasor communication systems. They develop an FPGA-based MITM attack model targeting IEEE C37.118 Phasor Measurement Unit (PMU)-to-Phasor Data Concentrator (PDC) streams. Their results illustrate how manipulated phasor measurements may evade conventional error-detection mechanisms. Although this approach reduces dependency on extensive physical infrastructure, it remains focused on a specific protocol and application domain. The reviewed platforms offer important capabilities for high-fidelity OT experimentation. Nevertheless, they primarily emphasize industrial or electrical-system behavior and provide limited coverage of enterprise IT services, healthcare applications, and cross-domain attack propagation. Hardwareheavy environments also impose practical constraints related to cost, scalability, repeatability, and rapid reconfiguration. These limitations are particularly significant in healthcare environments, where cybersecurity evaluation must account for the interaction among IT services, medical-data platforms, segmented networks, and SCADA-controlled infrastructure.

In healthcare, digital twins have been explored for predictive analytics, resource optimization, and data-driven decision support. Jameil et al. [20] integrate real-time sensor data and historical records to support predictive modeling using Multilayer Perceptron (MLP) networks and XGBoost. In a related study, Jameil et al. [20] address latency reduction in cloud-enabled healthcare digital twins through a Pyomo-based optimization model. Their framework uses the Digital Twin Definition Language (DTDL) and twin graphs to represent relationships among sensors, devices, and virtual models. Suhail et al. [21] propose a methodology for developing Security-Enhancing Digital Twins (SDETs) for CPS. Their framework includes the prerequisite, design-and-engineering, operation-and-maintenance, and end-of-life phases. It also incorporates security risk management practices and distinguishes between replication-oriented and simulation-oriented digital twins. Replication provides higher fidelity but may be impractical in healthcare due to proprietary systems, heterogeneous devices, and operational constraints. In contrast, simulation- and emulation-based approaches offer greater controllability and repeatability. Formal modeling techniques further support the systematic design of digital twins. Hu et al. [14] employ timed colored Petri nets to represent the discrete dynamics of cooperative

Ahmed et al. [10] investigate the integration of Large Language Models (LLMs) with RL to improve contextual awareness during agent training. Their framework pairs RL agents with LLM-based critics that evaluate actions and influence reward shaping. Compact agents monitor individual subsystems, while a central LLM maintains system-level awareness. The study also examines Retrieval-Augmented Generation(RAG)based knowledge sharing and the integration of external cybersecurity knowledge sources such as the MITRE ATT&CK framework. Peter et al. [25] develop an RL-based defense mechanism for power-grid infrastructures. Their framework combines GNNs with PPO in the Grid2Op simulation environment. A dual-policy learning strategy separates normal operating conditions from critical scenarios, including cascading failures and cyberattacks. This approach demonstrates how RL can support adaptive resilience in safety-critical industrial environments, although the evaluation remains specific to power systems. Kuri et al. [26] propose a specialized multi-agent framework for phishing detection and mitigation. Their system combines detection, deception, collaboration, and response agents. Transformer-based models identify semantic anomalies, honeypots support behavioral analysis, and response agents recommend or implement actions such as IP blocking, email quarantine, and proxy updates. The framework illustrates how multiple agents can coordinate across the detection and mitigation lifecycle. The reviewed studies demonstrate that RL-based cyberdefense mechanisms can improve adaptability, response speed, and scalability. Explainable AI methods, contextual reasoning, and multi-agent architectures can further improve the transparency and effectiveness of AI-generated mitigation actions. However, fully autonomous deployment remains challenging in safety-critical environments. A mitigation action that blocks traffic or isolates a service may limit attack propagation, but it may also disrupt essential hospital operations. Therefore, cybersecurity decision-making in healthcare requires a balance between rapid AI-assisted response and human supervisory control. This requirement motivates a human–AI symbiotic approach in which the RL agent assists security operators rather than unconditionally replacing them. The AI agent can monitor network statistics, identify attack patterns, and generate firewall-hardening actions, while operators retain the authority to validate, modify, override, or approve highimpact changes. Such a workflow combines machine-speed analysis with human contextual judgment and accountability. The proposed testbed provides a controlled environment for investigating this interaction. As a proof of concept, an RL agent is trained to mitigate SSH-based brute-force attacks by learning dynamic firewall-hardening policies. The current implementation evaluates the learned mitigation actions within an emulated hospital IT–OT environment. It also establishes a foundation for future human-in-the-loop extensions, including operator approval workflows, risk-aware recommendations, explainable action summaries, and audit logs for AI-assisted mitigation decisions. Overall, existing literature has not sufficiently addressed the combined need for cross-domain hospital IT–OT experimentation, emulation-anchored digital-twin

manipulation systems. Similarly, the framework in [22] uses Unified Modeling Language State Machines (UMLSMs) to describe digital-twin states and transitions within a Digital Twin Runtime Environment (DTRE). In healthcare environments, interoperability standards such as FHIR/HL7 [5] additionally support structured data exchange among heterogeneous systems. A human digital twin framework for monitoring and modeling individual health and occupational well-being was developed [23]; however, unlike their human-centric approach, our work develops a healthcare digital twin testbed for cyberattack simulation, attack impact assessment, and safe validation of defensive countermeasures. Existing work demonstrates the value of cyber-physical testbeds and digital-twin technologies. Current platforms rarely combine hospital IT services, healthcare-data systems, segmented network zones, and SCADA-based OT components within a unified cybersecurity experimentation environment. The proposed emulationanchored testbed addresses this gap through a containerized and reconfigurable architecture. It enables safe execution of cross-domain attack scenarios, continuous system monitoring, and iterative evaluation of defensive mechanisms. Unlike a fully synchronized digital twin of a deployed hospital, the current platform provides digital-twin capabilities anchored in emulation. This design choice improves reproducibility and safety while establishing a foundation for future integration with physical devices and live operational data. B. Human-Supervised Reinforcement-Learning-Based Cyber Defense

Traditional cybersecurity mechanisms often rely on static rules and manually configured response strategies. Although these approaches remain important, they may be insufficient in dynamic IT–OT environments where attacks evolve rapidly and propagate across interconnected systems. RL offers a complementary approach by enabling agents to learn mitigation policies through repeated interaction with simulated or emulated environments. Table III summarizes representative AI- and RL-based cyber-defense approaches. Rajgopal et al. [9] propose an agentic AI framework in which RL agents learn defense policies by interacting with dynamic cyber environments. The problem is modeled as an MDP, in which system states represent packet flows, anomalies, and intrusion attempts, and mitigation actions include blocking suspicious IP addresses, isolating compromised nodes, and initiating sandbox analysis. A DQN is used to learn defense policies through an ϵ-greedy exploration strategy. Saeed et al. [24] introduce a hybrid multi-agent cybersecurity framework combining machine learning, deep learning, and RL. The framework includes agents for anomaly detection, classification, prediction, and automated response. Isolation Forest and XGBoost support anomaly detection and classification, respectively, while a Graph Neural Network (GNN) captures structural and temporal relationships. A CNN–LSTM model combined with federated learning supports privacypreserving prediction, and a Proximal Policy Optimization (PPO) agent generates adaptive response actions. SHAP-based explainability is incorporated to improve transparency.

TABLE III C OMPARISON OF EXISTING RL- AGENT- BASED AUTONOMOUS CYBER RESILIENCE SYSTEMS Techniques Used

Key Contribution

Limitations

Rajgopal et al. [9]

RL-based autonomous cyber defense

Deep Q-Network, MDP, TensorFlow

Automated mitigation with faster response time

Limited contextual reasoning

Saeed et al. [24]

Hybrid multi-agent cybersecurity framework

Isolation Forest, XGBoost, CNN-LSTM, PPO, Federated Learning

Integrated detection, prediction, and response with explainability

Complex system architecture

Ahmed et al. [10]

Hierarchical RL with LLM critics

RL agents, LLM critics, RAG, MITRE ATT&CK integration

Context-aware reward shaping and adaptive learning

High computational requirements

Peter et al. [25]

RL-based defense for cyber-physical systems

PPO, Graph Neural Networks, Grid2Op

Dual-policy RL for resilient infrastructure defense

Focus is limited to power grid systems

Kuri et al. [26]

Multi-agent phishing detection system

NLP, Transformer models, Honeypots, Threat intelligence feeds

Collaborative agents phishing detection response

Limited focus on broader cyber attacks

Our Agent

Network statisticsbased detection

Dynamic Firewall hardening

for and

Detection of SSH-based attacks and their mitigation

Focused only on SSHbased attacks

The testbed integrates component-level realism via Opensource tools to model core hospital services, such as RapidSCADA, OpenEMR, Orthanc, and the OpenPLC runtime environment. The security state Si (t) of component i within the testbed at time t is defined as   0, normal Si (t) = 1, suspicious   2, compromised.

capabilities, RL-based defensive decision support, and human oversight. The proposed framework contributes toward this gap by providing a safe and reconfigurable platform for studying AI-assisted cybersecurity decisions in safety-critical healthcare environments.

Main Approach

Paper

III. T ESTBED DESIGN , IMPLEMENTATION , AND MODELING A. Testbed State Representation The testbed is implemented using Docker as the base platform for simulating an integrated hospital IT–OT environment. Docker provides lightweight containerization, more efficient resource usage, lifecycle management, state observability, and easier deployment compared to virtual machine–based approaches. The testbed is modeled as a directed graph G = (V, E),

where V = {P1 , P2 , . . . , Pn } is the set of hospital components. Each component is modeled as a node Pi , and E ⊆ V × V is the set of directed edges representing the permitted communication links between them.

B. Routing and Traffic Control Based on security zoning principles [27], the architecture is divided into four networks: IT, OT, DMZ, and Internet. Routing and network management are implemented using Alpinebased firewall containers configured with ip and iptables. Firewalls and routers maintain the required network topology, ensuring that the IT network is directly connected to the OT network while preventing direct access to OT from the DMZ and the Internet. The set of permitted communication links between network components is denoted by E, where E ⊆ V × V . For each pair of nodes (Pi , Pj ), adjacency indicator is defined as follows: ( 1, (Pi , Pj ) ∈ E Eij = 0, otherwise.

To effectively evaluate the performance of software patches and attack mitigation strategies, a digital twin continuously maintains the testbed’s state and provides the user with command-and-control capabilities. Each component of the testbed is represented by a tuple Pi (t) = Si (t), V uli , hi (t), Yi (t) , where the elements are defined as follows: Si (t) : Inferred discrete security state V uli : Static vulnerability profile and known software exploits. hi (t) : security-relevant Loki hit count for Pi Yi (t) : tshark-derived runtime counter vector. The vulnerability score (V uli ) of node Pi is defined as the average CVSS score [28] of known vulnerabilities affecting that component: The testbed security state vector is T X(t) = S1 (t), S2 (t), . . . , Sn (t) .

C. Testbed Architecture Figure 1 depicts the proposed hospital architecture, logically divided into five segments: Part A (IT), Part B (OT), Part C (DMZ), Part D (INTERNET), and Part E (Digital Twin).

Fig. 1. Hospital IT-OT Testbed Architecture. The hospital architecture diagram, with 5 sections (A, B, C, D, and E), depicts the IT, OT, DMZ, Internet, and Digital Twin, respectively.

health-related data components, such as Personal health devices like insulin pumps and pacemakers, are emulated using the pymodbus module that generates realistic event streams. To aggregate the data from these devices, a Personal Health Gateway (PHG) acts as a protocol mediator, normalizing inputs from heterogeneous medical devices and forwarding validated data to patient-specific health monitors using FHIR/HL7 [5]. Furthermore, the radiology subsystem includes MRI, CT, and X-ray workflows, with imaging data stored in a PACS server implemented using Orthanc and metadata maintained in a RIS, both integrated with the EHR. The framework supports standard Modbus operations, including read-coil, write-coil, read-register, and write-register transactions. These interactions enable the emulation of HVAC monitoring and control workflows while also supporting cybersecurity experimentation targeting industrial communication channels. For example, unauthorized Modbus write-coil payloads can be issued to alter HVAC operational states such as fan activation, alarm conditions, or environmental control logic. The resulting operational changes propagate through the SCADA visualization layer, allowing observation of telemetry deviations, actuatorstate transitions, and anomalous operational behavior. Rather than attempting hardware-faithful industrial simulation, the framework reproduces protocol-level communication patterns and operational workflows sufficient for cybersecurity experimentation. Consequently, network traces generated within the environment preserve observable communication semantics that can support intrusion detection system (IDS) evaluation, attack-propagation analysis, and anomaly-detection research.

Segmentation facilitates controlled experimentation with various cyberattack scenarios while preserving a realistic hospital environment. Table IV provides a detailed mapping of the software components to their corresponding implementations within the testbed environment. TABLE IV M APPING OF VARIOUS SYSTEMS AND THEIR IMPLEMENTATION

Implementation

PLC

OpenPLC Runtime [29], [30]

MTU, HMI, Historian Database

Rapid Scada [31]

Firewall

ip and iptables rules[32]

System

EHRs

OpenEMR [33], [34]

Sensors and Actuators

Pymodbus (Python) [35]

Public Facing Servers

Linux Machine

1) IT Network: Figure 1 Part A hosts the core hospital IT infrastructure and is logically separated from the OT and DMZ networks. At its core is a central server connected to a dedicated database for persistent storage and integrated with an Electronic Health Record (EHR) system for medical record management. The EHR is implemented using an OpenEMR instance backed by an external MariaDB container. To ensure controlled administrative operations, access is facilitated through an admin jump box modeled as an Ubuntu container with SSH-based access. Extending beyond core IT services,

2) OT Network: Figure 1 Part B represents the OT network and models industrial and SCADA-based systems. It includes a

Fig. 2. (A) Emulation-based testbed—simulated sensors, actuators, PLC, and backend; (B) Hospital digital twin—2D dashboard for monitoring and control.

(normal, warning, alert, offline) based on the status of the container and the indicators derived from the logs. The interface explicitly shows the logging pipeline and the IT–OT routing bridge. The containerized architecture establishes the functional foundation required for controlled cybersecurity experimentation. However, evaluating attack propagation and defensive mechanisms requires continuous visibility into component states, system logs, and network behavior. To support this requirement, the testbed is extended with an emulationanchored digital-twin layer that provides real-time monitoring, controlled interaction, and centralized orchestration.

SCADA control station, field devices, sensors, and actuators. An HVAC system is implemented using OpenPLC runtime and Rapid SCADA, enabling real-time monitoring and control of physical processes. Each sensor is accessible through a web-based interface that allows control of its output. The OT environment uses OpenPLC to emulate programmable logic controller (PLC) behavior within the HVAC control workflow. The PLC executes cyclic control logic involving input acquisition, communication handling, logic execution, and output updates, similar to operational PLC workflows used in industrial environments. Although software-based PLCs cannot reproduce the deterministic hardware timing characteristics of industrial controllers, the framework maintains cyclic control execution behavior suitable for controlled cybersecurity experimentation. This enables the study of attack scenarios involving command injection, unauthorized write-coil operations, register manipulation, and operational state modification within a reproducible environment. The preservation of scan-cycle behavior is particularly important because many ICS attacks rely on interactions between controllers, SCADA servers, and operational processes. By maintaining operationally meaningful control execution sequences, the framework enables experimentation involving process-state manipulation and attack-propagation analysis across OT infrastructure. The web interface is powered by Python-based backend scripts leveraging the PyModbus library to update the PLC values, thereby generating real OT traffic. In parallel, Rapid SCADA is integrated into the environment to provide core supervisory functionalities, including the Master Terminal Unit (MTU), historian database, and Human–Machine Interface (HMI) for real-time monitoring and control. The traffic is secured by an OT firewall, which allows internal OT traffic and permits network packets from IT. This selective IT and OT interaction is essential for advanced data analytics and software updates. Simultaneously, the firewalls restrict and rate-limit potential propagation of cyber attacks, including PLC manipulation attacks. As a result, the OT environment maintains operational efficiency while preserving critical industrial processes. 3) DMZ Network: Figure 1 Part C represents the DMZ network, which isolates the IT and OT networks from external entities through a layered firewall architecture. It hosts a dedicated router for its internal networking. The DMZ-externalfirewall acts as the public interface, exposing limited services to the Internet, and is responsible for directing incoming and outgoing traffic. DMZ hosts two major services, one of which is a public-facing web server that hosts the hospital’s homepage. Another service is SSH-based access to the Admin jump box, provided by the bastion host. It acts as an intermediary node, enabling administrators to access the internal admin jump box for remote management of IT components. On the internal side, a secondary firewall connects the DMZ to a common router, which connects IT, OT, and DMZ with selective traffic control. This layered design enforces strict access control, allowing restricted communication. The SOC interface mirrors the logical topology of the testbed, grouping the nodes into Internet, DMZ, IT and OT zones. Each node dynamically shows its operational status

D. Emulation-Anchored Digital-Twin Layer The emulation-based Hospital IT–OT testbed is extended with a closed-loop digital twin that provides an interactive representation of the system (Figure 1 part E). The current implementation provides a 2-D interface, as shown in Figure 2, that couples the emulated OT plant (PLC, sensors, actuators, and SCADA) with an interactive dashboard for monitoring and control. Key emulated components are interactive, allowing users to inspect real-time operational state and access live system logs. The digital twin continuously ingests system state logs from the testbed and allows the controller to manually execute commands on the testbed components. This feedback mechanism helps to test various countermeasures against cyberattacks. The digital twin maintains the inferred state vector X(t) using logs, telemetry, and operator feedback from the emulated testbed. The SOC interface renders Si (t), inferred attack paths, and anomaly scores returned by the propagation engine. The digital twin is secured with JWT-based authentication and a three-level RBAC model: admin, operator, and viewer. Tokens are time-bound to reduce session exposure. Permissions are enforced at multiple levels: container-level isolation (each role has an allowlist of containers it may access), command allowlisting for remote execution (with dangerous patterns blocked for all roles), and role-specific operational

limits such as per-role command timeouts and request rate limiting. This ensures that only authorized actions are performed and reduces the impact of compromised credentials or misuse. A secure WebSocket terminal allows authenticated users to run commands inside testbed containers from the digital twin. The endpoint accepts a JWT in the query string and applies the same RBAC rules: access is restricted to containers allowed for the user’s role, and each command is validated against a rolespecific allowlist and a global blocklist of dangerous patterns (e.g., shell metacharacters, privilege escalation). Rate limiting is applied per session (e.g., per-role caps on commands per minute). All terminal activity is logged for audit (username, role, container, command, exit code, and result), supporting both real-time monitoring and post-incident analysis. Service management is implemented via the Docker API: start, stop, and restart actions are mapped to the corresponding container lifecycle operations. Environmental control allows operators to set temperature and humidity setpoints for logical healthcare zones. Setpoints are stored in the digital twin’s control state and can drive or reflect the behavior of the simulated HVAC and sensors. Network orchestration enforces connectivity between node pairs by dynamically adding or removing iptables FORWARD rules on the IT–OT router container (e.g., block or allow traffic between specified source and destination IPs), enabling experimentation with segmentation and isolation without modifying static firewall configs. The logging pipeline is implemented as a Loki–Promtail (PLG-style) stack. Promtail discovers running Docker containers, scrapes their logs from the host, and pushes them to Loki with labels such as service, network, and log type as shown in Figure 3 and 4. The backend queries Loki’s LogQL API to supply the digital twin with recent logs per node; this powers the real-time diagnostic display in the node-detail view and supports historical audit and security event analysis across the testbed. A web-based Command-and-Control (C2) capability is implemented within the testbed to enable centralized management and control of system components. The platform provides real-time system status and the ability to control the component life cycle. A feedback mechanism is provided for executing commands via the Docker command-line interface, as shown in Figure 5. The feedback mechanism allows testing and evaluation of countermeasures against a particular attack

Fig. 4. Digital Twin: File-based container-specific logs

Fig. 3. Digital Twin: Runtime container Logs from Docker

Fig. 5. Digital Twin: Command-and-Control interface, configuring firewall rules to block a particular IP.

scenario. A logging pipeline is engineered to update the control center with the latest system logs for detailed testbed component visualization. Together, these access controls and comprehensive logging pipelines form the architectural control and audit mechanisms required to safely implement future human-supervised, AI-driven defense strategies. The objective is to replicate real-world scenarios and determine the optimal solution based on performance metrics. The digital twin extends the static hospital topology with a dynamic state that is rendered in the SOC interface through an SOC visualization tab. The tab displays the network as a Mermaid diagram split into zones (INTERNET, DMZ, IT, and OT), where each compromised hop is recorded and overlaid on the diagram in near real-time, as shown in Figure 6. Analysts can also select any node to highlight it and its direct connections, giving both a live view of propagation across the twin and a simple way to inspect local connectivity. The monitoring and control capabilities of the emulationanchored digital-twin layer enable operators to observe the evolving state of the environment and apply mitigation actions in a controlled manner. Building on this capability, the next subsection introduces an RL-assisted firewall-defense mechanism that learns mitigation policies from network observations and dynamically responds to SSH-based brute-force attacks

Fig. 6. Lateral movement visualization: Simulated attack path across zones. The attacker brute-forces the DMZ bastion, tunnels into the admin jump box, stages a Modbus payload, and pivots to OpenPLC in the OT network. Where the red arrow shows the compromise chain.

within the emulated environment.

1) RL-based Firewall Defense Mechanism: It is difficult to defend against AI-driven attacks because of their speed and versatility. Existing rule-based defense mechanisms have a limited scope and are static. In contrast, a Reinforcement Learning (RL) agent is adaptive and provides a faster response time. Autonomous decision-making provides real-time defense against attacks [9]. An RL-based Orchestration System is developed that helps the digital twin to autonomously countermeasure the SSH-based attacks. Figure 7 illustrates the flow of RL agent training. It consists of MainObserverAgent, NetworkObserverAgent, HealthObserverAgent, DetectionAgent, AgentEnv, Orchestrator, and ResponseAgent. The NetworkObserverAgent collects network packet data from various firewalls present in the testbed and creates statistics for the MainObserverAgent. The MainObserverAgent has a provider method that provides statistics to the DetectionAgent for learning. The ResponseAgent performs the chosen action. The AgentEnv acts as an interface between the testbed and other agents to perform the training of the RL agent. The following subsections describe these elements in detail, beginning with the state and action spaces used by the agent.

Fig. 7. RL Agent Design

2) State and Action space: The primary focus is networkbased intrusion detection through firewalls. Tshark is installed on all firewalls and routers to capture the network packets. The NetworkObserverAgent maintains statistics for different firewalls in the form of a dictionary. The source IP, destination port, and protocol are used as keys, and the value is a counter that keeps track of the number of times the particular set of

The RL agent is validated by the mitigation of attacks by the agent, as shown in Figure 8. E. Operator Interface and Security Operations View

Figure 9 presents the integrated operator view of the Hospital Security Digital Twin. The main dashboard offers a consolidated health summary, including device online status, alerts, and warnings, and exposes operational controls for representative IT and OT assets. These controls include medicaldevice lifecycle commands and HVAC setpoint adjustments via OpenPLC. Complementing the supervisory dashboard, the per-node monitoring panels provide two complementary levels of observability. Live application logs capture runtime behavior in near real time (e.g., authentication events and HTTP traffic on the central server; see Figure 3), while filebased container logs enable post-hoc inspection of systemlevel activity (see Figure 4). Finally, the SOC visualization maps the segmented network topology—spanning the Internet, DMZ, IT, and OT zones—and overlays lateral movement paths annotated with node-level risk scores. This provides analysts with a spatial perspective on how a compromise could propagate across firewalls, jump hosts, clinical systems, and industrial controllers. Collectively, these views integrate dayto-day simulation control, continuous monitoring, and attackpath reasoning into a unified interface, without duplicating the component-level details presented in the preceding sections.

values is encountered. In each step of the training process, the AgentEnv incrementally gets the network statistic for a firewall and performs mapping to integer values to provide input to the model. The output of the model is the expected reward for each action, and the action with the highest reward is passed on to the ResponseAgent. The ResponseAgent receives extra information from the AgentEnv, which includes the source IP and firewall, so that it can perform the following actions on the firewall: Block IP, Block Port, Allow IP, Allow Port, and No Action. The DQN architecture provides the learning mechanism required to estimate effective mitigation actions under changing network conditions. To train the agent, the environment repeatedly executes SSH-based attacks and assigns rewards according to the success or failure of the selected defensive actions. The training procedure and reward design are described next. The detection agent is based on a DQN method [36]. It receives input as network statistics based on the protocol and the number of times it is used by a particular IP. The neural network approximates the Q-function. To remove temporal correlation between samples, a replay buffer is used to store experiences of the RL agent [37]. These experiences are randomly sampled and used for training the neural network. A target network is maintained and updated using parameter τ to stabilize learning. θtarget ← τ θonline + (1 − τ )θtarget

(1)

IV. ATTACK S CENARIO

A. Attack Propagation

For successful attack propagation from node Pi to Pj , we consider that the attacker has the minimum privilege level required to exploit a vulnerability. For each vulnerability, we calculate the pre-requisite and post-condition based on [38]. Thereafter, we consider the possible attack propagation from node Pi to Pj only if the privilege of the attacker at node Pj ¿= the privilege required to exploit vulnerability vul and communication from Pi to Pj is permitted. a) Direct anomaly estimation: Each node computes a direct anomaly score from runtime observations. The log anomaly score is

For efficient learning, the balance between exploration and exploitation is maintained through an ϵ-greedy strategy.   with probability ϵ random action, (2) at =   arg maxa Q(st , a), with probability 1 − ϵ

Q-values are updated using the Bellman equation based on rewards from the environment, where Q(st , at ) denotes the action-value function for state st and action at , rt represents the immediate reward received from the environment, γ is the discount factor controlling the importance of future rewards, and maxa′ Q(st+1 , a′ ) denotes the maximum predicted future Q-value for the next state st+1 .

Q(st , at ) = rt + γ max Qtarget (st+1 , a′ ) ′ a

(3)

3) Training and Rewarding the Agent: The RL agent learns through a series of episodes. Each episode is a new start for the attack. The AgentEnv starts the attack at the beginning of the episode, and when the attack ends or the maximum number of steps is reached, the episode ends. During the episode, the agent performs various actions and receives rewards. The reward mechanism differs from the inputs given to the RL agent. A positive reward of +1 is given when the number of failed SSH attempts on the Bastion Host and Admin Jump Box is zero in the last 5 seconds, which shows that they are not under attack. A negative reward of -1 is given when these two systems are considered under attack. The RL agent begins with exploration and builds logic to understand the consequences of its actions. With the increase in episodes, it moves towards exploitation of its learning and uses it to mitigate the attacks.

Alog i (t) = min(1, α hi (t))

(4)

where hi (t) is the security-relevant Loki hit count for Pi in the monitoring window and α is normalization constant. The process anomaly score is ! X proc Ai (t) = min 1, ϕk (Yi,k (t)) , (5) k

where Yi,k (t) is the k-th tshark-derived counter in Yi (t), and ϕk (·) is a piecewise capped scoring function. Representative deployed terms are ϕcz (y) = min(0.35, 0.08 y), ϕssh (y) = min(0.45, 0.12 y), ϕmod (y) = min(0.55, 0.20 y),

Fig. 8. RL agent attack mitigation across training

c) Compromise propagation: Compromised nodes may influence neighbouring nodes through permitted communication links in G. For each directed edge (Pi , Pj ) ∈ E, the edge influence term is Iij (t) = 1{S (1) (t)=2} V ulj , (7)

If only one signal is non-zero, that score is used directly. b) First-pass state estimation: In the first pass, each node is classified using only log hits hi (t) and network counters Yi (t) without considering compromise on neighboring nodes. (1) This yields a preliminary state Si (t) from the direct anomaly score Ai (t). Global thresholds are

and the propagated compromise probability is ( 1 − e−Ij (t) , Ij (t) > 0, comp pj (t) = 0, otherwise.

for cross-zone inbound flows, SSH inbound flows, and non-OT Modbus traffic, respectively. Additional capped terms cover admin-port access, unique peer IPs, and failed SSH logins on bastion/admin nodes. The weights and caps are heuristic calibration constants tuned so benign traffic remains below ω1 , while SSH and IT-origin Modbus events in the implemented attack chain contribute more strongly without saturating the score. When both signals are available, the fused direct anomaly score is proc Ai (t) = 1 − 1 − Alog (t) . (6) i (t) 1 − Ai

ω1 = 0.55,

ω2 = 0.75,

where ω1 is the suspicious cutoff (above benign steadystate scores) and ω2 is sufficiently above ω1 for confident compromise classification. The first-pass state is  2, Ai (t) ≥ ω2 ,    (1) Si (t) = 1, ω1 ≤ Ai (t) < ω2 ,    0, Ai (t) < ω1 .

(1)

where 1{·} is the indicator function, Si (t) = 2 means source node Pi is compromised in the first pass. The cumulative attack influence on node Pj is X Ij (t) = Iij (t), (8) i: (Pi ,Pj )∈E

(9)

d) Final state estimation: The final anomaly score and state are Afinal (t) = 1 − 1 − pcomp (t) 1 − Aj (t) , (10) j j  2, Afinal (t) ≥ ω2 ,  j   Sj (t) = 1, ω1 ≤ Afinal (t) < ω2 , j    0, Afinal (t) < ω1 . j The vector X(t) is updated from {Sj (t)} at each monitoring interval and displayed in the SOC visualization. This two-pass procedure first detects locally anomalous nodes, then refines states using graph-based propagation across the hospital IT–OT network.

Fig. 9. Digital Twin Dashboard: Container Lifecycle Management

A patch is considered effective if it reduces the overall anomaly in the system Pj : X

Afinal (t + 1) < j

Afinal (t). j

j∈P

TABLE V BASELINE ANOMALY SUMMARY UNDER NORMAL OPERATION (300 S , 56 SNAPSHOTS ).

B. Case Study: Multi-stage SSH Attack

a) Baseline Initialization: We evaluated the propagation model of Section IV under normal operation before executing attack scenarios. Constants α = 0.08, ω1 = 0.55, and ω2 = 0.75, together with the caps in ϕcz (·), ϕssh (·), and ϕmod (·), were selected so that benign DMZ web traffic remained below the suspicious threshold. Table V summarizes the resulting baseline scores. We collected 300 s of idle traffic in 56 snapshots at 5 s intervals, with a 30 s tshark capture window on firewall/router taps while the full Docker stack ran normally. Throughout this period, the propagation API reported no inferred lateralmovement path and Si (t) = 0 for all monitored nodes. When benign HTTP traffic was injected (user → dmzexternal-firewall → public-facing-server), only the publicfacing server exhibited a stable elevated score, with Aproc (t) = i Afinal (t) = 0.35. This is consistent with the cross-zone i inbound counter yicz (t) = 7, which yields an uncapped contribution of 0.56 but is limited to 0.35 by ϕcz (·). Table V summarizes mean and maximum final anomaly scores. All monitored nodes remained below the global suspicious threshold ω1 = 0.55, so Si (t) = 0 throughout baseline operation. (1) Because no node reached Si (t) = 2, graph propagation terms satisfied Iij (t) = 0 and pcomp (t) = 0 for all nodes. i b) Attack Execution: A multi-stage lateral movement attack scenario is developed. The attack originates on the

Node Pi

Āfinal i

max Afinal i

Public-facing-server

0.35

User, DMZ-ext. firewall, router, staff-pc

0.00

Internet and propagates through the DMZ to access the admin jump box within the IT network. The first target is the bastion host in the DMZ network, which is hijacked via a brute-force SSH attack. Once the attacker establishes control of the bastion host, it creates an SSH tunnel for lateral movement to the IT network. As shown in Figure 10, dmz-external-firewall and dmz-router start receiving SSH traffic as the attack starts on the bastion host. Around the 145th timestep, the bastion host is compromised, and the attacker proceeds to the admin jump box via a secure tunnel. The internal DMZ firewall and router also start observing SSH traffic. Around the 178th timestep, the admin jump is compromised, and the attacker has successfully gained control of the IT network. It then starts the attack on the PLC network inside the OT network by using the lack of authentication in the OpenPLC module. The attacker script sends random sensor values to various registers in OpenPLC. The increase in the number of Modbus/TCP calls is observed in the OT firewall from the 178th timestep onwards. The proposed testbed considers a hospital IT–OT environment consisting of clinical IT services, DMZ-facing gateway components, SCADA infrastructure, PLC-based HVAC control logic, and segmented network zones. The threat model focuses

Fig. 10. Multi-stage SSH attack propagation. Initially, increased SSH-based traffic is observed in the DMZ-external-firewall and the DMZ-router. After the bastion host is compromised, traffic starts increasing in the DMZ-internal firewall and the main router, indicating lateral movement within networks. Consequently, the OT firewall captures PLC manipulation attacks from IT to OT.

PLC, or Modbus/TCP endpoints due to weak segmentation or misconfigured routing, or exposed services; and (4) Remote administrative access abuse, involving the Misuse of SSH, default credentials, shared accounts, or insufficiently protected jump-box access.

on cyberattacks that originate from compromised IT-facing services or exposed gateway components and propagate toward operational technology systems. The adversary aims to compromise hospital IT–OT operations by: disrupting clinical or operational service availability, manipulating HVAC/SCADA control states, modifying PLC coil or register values, bypassing weak segmentation between IT, DMZ, and OT zones, generating stealthy attack traces for evading detection, and creating cascading effects across healthcare IT and OT workflows. The primary objective is not physical destruction but operational disruption, unsafe control manipulation, and degradation of hospital service continuity. Adversary Capabilities: We assume the adversary can: scan reachable services across segmented zones, exploit vulnerable IT or DMZ services, obtain a limited foothold on a compromised container or host, perform lateral movement within allowed network paths, issue unauthorized Modbus/TCP commands if OT access is obtained, manipulate read/write coil or register operations, and observe network traffic visible from compromised nodes. The attacker may exploit misconfigurations, weak credentials, exposed services, insecure communication protocols, or insufficient firewall rules. Attack Entry Points: The considered entry points include: (1) IT zone compromise, involving the compromise of hospital-facing applications such as EHR, PACS, database services, or administrative workstations; (2) DMZ compromise, involving the compromise of gateway components responsible for mediating communication between clinical IT and OT-facing services; (3) OT network exposure, resulting from unauthorized access to SCADA, MTU, Open-

V. E VALUATION The hospital simulation runs as a multi-container Docker stack spanning IT clinical systems (EHR, PACS, MariaDB), OT/ICS components (OpenPLC, MTU, smoke-detector PLC), and DMZ security appliances (firewalls, routers). Before the environment can be reliably used for security experiments, lateral-movement scenarios, or SOC training, its operational viability on commodity hardware must be confirmed. We therefore evaluate per-container CPU and memory consumption during a representative steady-state run. All measurements were collected on a single evaluation host equipped with an AMD Ryzen 5 7535HS processor (6 physical cores, 12 logical CPUs) and 16 GB of system RAM, running the full Docker stack under Linux. Docker reports CPU utilization (CPUPerc) as a percentage of a single logical CPU core, which allows individual containers to exceed 100% on multi-core systems. To express usage as a fraction of the total machine capacity, we normalize the value using the following formula:

CPUPerc (11) host logical cpus where host logical cpus is the number of logical processors on the machine that runs the Docker host during evaluation. cpu normalized percent =

A logical processor is one schedulable CPU thread exposed to the OS. Average normalized CPU is the arithmetic mean of all normalized samples over the evaluation window. Peak normalized CPU is the maximum instantaneous value observed. Memory usage is derived from Docker’s MemUsage 1 field. We report: • Average memory (MB): the mean of MemUsed values, converted to megabytes. • Peak memory (MB): the maximum instantaneous MemUsed recorded during the run.

TABLE VI AVERAGE R ESOURCE C ONSUMPTION OF M AJOR C ONTAINERS (S TEADY-S TATE )

Avg CPU

Avg Memory (MB)

Role

MTU (Rapid SCADA)

0.31%

384 (peak 478)

OT supervisory / HMI layer

Openplc

0.21%

159

PLC runtime and Modbus services

PACS (Orthanc)

0.05%

MariaDB

0.009%

Container

Medical archive

imaging

166

Shared database

clinical

historian functions, and a web interface, it is substantially more resource-intensive than lightweight network appliances or single-purpose medical device simulators. OpenPLC ranks as the second-highest CPU consumer, consistent with its role as a soft-PLC runtime that continuously executes structured text logic and serves Modbus/TCP requests on a fixed scan cycle. MariaDB and PACS (Orthanc) primarily contribute through memory rather than CPU. MariaDB maintains clinical database schemas and connection pools, while Orthanc caches DICOM metadata and imaging buffers. Their low CPU usage indicates they remain largely idle or lightly queried during steady state, yet they reserve a meaningful amount of RAM for operational readiness. Clinical endpoints (EHR, insulin-pump, MRI, PHG) and supporting IT infrastructure (central-server, public-facingserver, admin-jump-box) form a middle tier, typically consuming 0.002–0.008% normalized CPU and 20–55 MB of memory.

Fig. 11. Average normalized CPU utilization per container.

A. System Stability Over Time

Fig. 12. Average memory usage per container.

The simulation demonstrates exceptionally light resource requirements. Average normalized CPU utilization per container remains below 0.4%, with the majority of services consuming less than 0.01%. On the 12-logical-CPU host used for evaluation, the full stack represents only a small fraction of available compute capacity. Notably, the security and networking infrastructure including the router, DMZ external firewall, DMZ internal firewall, and DMZ router, each averages below 0.001% normalized CPU. This confirms that network segmentation and security policy enforcement impose negligible overhead compared to application workloads. As shown in Figures 11 and 12, the MTU is the dominant consumer of both CPU and memory. Running a full .NET-based SCADA server with real-time polling, 1 https://docs.docker.com/reference/cli/docker/container/stats/

Figure 13 presents the aggregate CPU and memory utilization for the complete 1-hour-45-minute evaluation window with all simulation components active. The total normalized CPU remains highly stable throughout the run, maintaining a baseline near 0.6%. Brief periodic spikes reach 1.0–1.1%, with the highest observed peak at 1.35%. These excursions are consistent with scheduled SCADA polling cycles and routine background processes rather than uncontrolled load. Overall, aggregate CPU never exceeds 1.4% of total host capacity. Memory usage begins at approximately 1,100 MB and rises gradually to 1,250 MB. This modest increase aligns with normal JVM/.NET warm-up and database buffer pool growth rather than a memory leak. A sharp drop to 1,200 MB immediately following the largest CPU spike likely indicates garbage collection or cache flushing in the MTU or MariaDB. At the end of the monitoring window, memory decreases sharply to 800 MB, corresponding to the orderly shutdown of simulation components.

Fig. 13. Aggregate CPU and memory utilization of the entire stack over time (1 hour 45 minutes).

Collectively, the flat CPU baseline, bounded periodic spikes, and controlled memory growth demonstrate that the testbed operates in a stable, steady-state condition. The large margin between observed utilization and host capacity provides ample headroom for concurrent red-team activities, log ingestion, and SOC tooling without compromising system stability. This lightweight and stable resource profile makes the hospital simulation environment well-suited for extended cybersecurity research and training on commodity hardware.

TABLE VII BACKEND API LATENCY (50 REQUESTS PER ENDPOINT ).

Endpoint

log-structure endpoints

nodes endpoint

p95 (ms)

min (ms)

max (ms)

2.74

3.35

2.52

3.64

125.30

142.43

106.05

198.95

TABLE VIII L OG QUERY LATENCY (20 REPEATS PER QUERY ).

B. End-to-End Latency Evaluation

We report latency representing end-to-end round-trip times measured at the client side. Each experiment was repeated multiple times under identical conditions. We characterize the latency distribution of each workload using the following metrics: • p50 (median): The 50th percentile. Half of all requests are completed in or before this value. It serves as a robust measure of central tendency. • p95: The 95th percentile. Only 5% of requests are slower than this value. It is used to characterize tail latency while remaining robust against rare outliers. 1) Backend API Latency: We repeatedly invoked representative backend endpoints and recorded the response time for each request. Table VII summarizes the results for two key endpoints measured over 50 requests each. The log-structure endpoints return a comparatively small, fixed-size payload and therefore exhibit very low and stable latency. In contrast, the nodes endpoint is substantially slower as it must enumerate and inspect container states, parse detailed metadata, and return a significantly larger result set. 2) Log Query Latency: We evaluated several representative log queries designed to stress different parts of the monitoring stack and query language. Results are based on 20 repeats per query and are presented in Table VIII. To evaluate these

p50 (ms)

Query

p50 (ms)

p95 (ms)

min (ms)

max (ms)

All logs baseline

17.48

41.45

8.99

43.78

Central server auth signals

5.58

16.96

3.48

24.21

SOC services

6.43

14.57

4.75

16.64

4.80

8.40

3.50

13.63

critical

Segmentation firewall signals

results, the queries were categorized into four distinct baselines based on the targeted log streams: All logs baseline: A broad log selection constrained to streams with an assigned service identifier, avoiding a full scan of the entire log dataset. • Central server auth signals: Authentication-related events originating from the central server. • SOC critical services: Restricted to the main IT, DMZ, and SOC services in the scenario. • Segmentation firewall signals: Router and firewall logs, with emphasis on denied or blocked traffic. •

ACKNOWLEDGMENT

This work was supported by the Anusandhan National Research Foundation ECRG under Grant No. ANRF/ECRG/2024/006514/ENS.

The proposed framework is designed as a cybersecurity experimentation and attack-analysis environment rather than as a hardware-faithful industrial simulator or a fully synchronized digital twin of a deployed hospital infrastructure. Its objective is to reproduce the communication patterns, segmented network behavior, and operational workflows required to study cybersecurity interactions across hospital IT and OT domains in a safe and reconfigurable setting. The current implementation emulates protocol-level interactions and observable cyberphysical behavior using containerized services, software-based PLCs, and representative sensors and actuators. However, it does not claim deterministic timing equivalence with physical PLC hardware or deployment-grade industrial control systems. In particular, the present framework does not model hardware-specific PLC execution characteristics, physical sensor noise, electrical or thermodynamic process dynamics, actuator inertia, or vendor-specific firmware behavior. Instead, the framework prioritizes operationally meaningful communication semantics and security-relevant system behavior. This level of abstraction is sufficient for evaluating cross-domain attack propagation, intrusion-detection mechanisms, softwarepatch validation, firewall-hardening strategies, and AI-assisted mitigation approaches in hospital IT–OT environments. The architecture also provides a foundation for future extensions involving physical devices, hardware-in-the-loop integration, and real-time synchronization with operational infrastructure.

VI. S COPE AND L IMITATIONS OF F IDELITY

and repeatable evaluation of multi-stage cyberattacks, system monitoring, firewall-hardening strategies, and RL-assisted mitigation mechanisms without disrupting operational healthcare services. As a proof of concept, the RL agent demonstrates the ability to learn firewall-defense policies for mitigating SSHbased brute-force attacks and limiting lateral movement across network segments. Future work will extend the framework through hardware-in-the-loop integration using physical PLCs, sensors, and actuators, as well as real-time synchronization with operational devices. The RL agent will also be enhanced with a richer observation space, an expanded action set, and support for a broader range of attack scenarios. In addition, human-in-the-loop decision support will be incorporated to allow security operators to review, validate, modify, or override AI-generated mitigation actions before their deployment in safety-critical hospital environments.

3) OpenPLC Modbus TCP Control-Plane Latency: We measured a lightweight control-plane interaction against OpenPLC over Modbus TCP. The test consisted of writing three holding registers followed by an immediate read-back. Across 20 trials, the measured round-trip latency showed a minimum of 0.753 ms, a median (p50) of 0.901 ms, a 95th percentile (p95) of 3.435 ms, and a maximum observed value of 47.445 ms. The occasional high tail latency (maximum of 47.445 ms) is attributed to normal system-level variability such as OS scheduling, TCP stack behavior, and measurement overhead. This low-latency profile confirms that the simulated industrial control systems remain responsive and suitable for realistic security experimentation and operator training.

R EFERENCES

[1] C.-T. Lin, S.-L. Wu, and M.-L. Lee, “Cyber attack and defense on industry control systems,” in 2017 IEEE Conference on Dependable and Secure Computing, 2017, pp. 524–526. [2] A. Ayub, H. Yoo, and I. Ahmed, “Empirical Study of PLC Authentication Protocols in Industrial Control Systems,” in 2021 IEEE Security and Privacy Workshops, May 2021, pp. 383–397. [3] G. S. O.V., A. Karthikeyan, K. Karthikeyan, P. Sanjeevikumar, S. Karapparambil Thomas, and A. Babu, “Critical review of SCADA and plc in smart buildings and energy sector,” Energy Reports, vol. 12, pp. 1518– 1530, 2024. [4] V. Gurupur, “Understanding An Electronic Health Record System and Its Applicable Data Quality Measures,” Understanding An Electronic Health Record System and Its Applicable Data Quality Measures, pp. 1–14, Mar. 2024. [Online]. Available: https://ieeexplore.ieee.org/servle t/opac?punumber=10482889 [5] D. Bender and K. Sartipi, “HL7 FHIR: An agile and RESTful approach to healthcare information exchange,” in Proceedings of the 26th IEEE International Symposium on Computer-Based Medical Systems, 2013, pp. 326–331. [6] G. Yadav, P. Gauravaram, and A. K. Jindal, “Smartpatch: a patch prioritization framework for SCADA chain in smart grid,” in Proceedings of the 26th Annual International Conference on Mobile Computing and Networking, ser. MobiCom ’20. New York, NY, USA: Association for Computing Machinery, 2020. [7] A. K. Ligo, A. Kott, and I. Linkov, “Autonomous cyberdefense introduces risk: Can we manage the risk?” Computer, vol. 54, no. 10, pp. 106–110, 2021. [8] “Ethics and governance of artificial intelligence for health,” http://iris.w ho.int/server/api/core/bitstreams/f780d926-4ae3-42ce-a6d6-e898a5562 621/content, World Health Organization, Geneva, Tech. Rep., 2021. [9] P. R. Rajgopal, “Agentic AI for Autonomous Cybersecurity Threat Mitigation,” in 2025 2nd International Conference on Artificial Intelligence and Knowledge Discovery in Concurrent Engineering. Chennai, India: IEEE, Oct. 2025, pp. 1–7. [10] H. Ahmed, S. Iqbal, E. C. Pinto Neto, S. Buffett, M. Sultana, and A. Taylor, “Autonomous Multi-agent Cyber Defense: A Novel Approach Using Reinforcement Learning with Hierarchical LLM Critics,” in 2025 Cyber Awareness and Research Symposium. Grand Forks, ND, USA: IEEE, Oct. 2025, pp. 1–5. [11] Z. O’Toole, C. Moya, C. Rubin, A. Schnabel, and J. Wang, “A CyberPhysical Testbed Design for the Electric Power Grid,” in 2019 North American Power Symposium. Wichita, KS, USA: IEEE, Oct. 2019, pp. 1–5.

VII. C ONCLUSION AND F UTURE W ORK

The proposed framework provides a containerized hospital IT–OT cybersecurity testbed that integrates isolated services, segmented networks, healthcare applications, and SCADAbased OT components within a unified experimentation environment. Although the current implementation relies on software-emulated PLCs, sensors, and actuators, it preserves the protocol-level interactions, communication semantics, and operational workflows required for studying cross-domain attack propagation and defensive mechanisms. The framework is therefore positioned as an emulation-anchored cybersecurity testbed with digital-twin capabilities rather than as a hardwarefaithful industrial simulator or a fully synchronized digital twin of a deployed hospital infrastructure. The testbed enables safe

[34] O. Project, “OpenEMR documentation,” https://www.open- emr.org/, 2026, accessed: June 2026. [35] Pymodbus Developers, “Pymodbus documentation,” https://pymodbus.r eadthedocs.io/, 2026, accessed: June 2026. [36] P. K. Mahapatro, P. Yaswanth, C. Meghana, T. Rushanth, and P. Somesh, “Cartpole balancer using deep q-network,” in 2025 IEEE Wireless Antenna and Microwave Symposium, 2025, pp. 1–5. [37] T. Zhao, “Exploring a reinforcement learning agent with improved prioritized experience replay for a confrontation game,” in 2022 International Conference on Big Data, Information and Computer Network, 2022, pp. 373–381. [38] G. Yadav and K. Paul, “Global monitor using spatiotemporally correlated local monitors,” in 2021 IEEE 20th International Symposium on Network Computing and Applications (NCA), 2021, pp. 1–10.

[12] K. Park, B. Ahn, J. Kim, D. Won, Y. Noh, J. Choi, and T. Kim, “An Advanced Persistent Threat (APT)-Style Cyberattack Testbed for Distributed Energy Resources (DER),” in 2021 IEEE Design Methodologies Conference. Bath, United Kingdom: IEEE, Jul. 2021, pp. 1–5. [13] N. K. Kandasamy, S. Venugopalan, T. K. Wong, and N. J. Leu, “An electric power digital twin for cyber security testing, research and education,” Computers and Electrical Engineering, vol. 101, p. 108061, 2022. [14] F. Hu, W. Wang, and J. Zhou, “Petri nets-based digital twin drives dual-arm cooperative manipulation,” Computers in Industry, vol. 147, p. 103880, 2023. [15] P. Ding, S. Q. Liu, R. Chiong, S. Dhakal, D. Chen, D. Li, H.-L. Ma, and S.-H. Chung, “A review of digital twins in smart industries: Concepts, milestones, trends, applications, opportunities and challenges,” Computers in Industry, vol. 174, p. 104398, 2026. [16] Y. Wu, X. Ma, F. Yang, R. B. Basaran, P. R. Stork, I. L. Glasbrenner, C. A. Thornton, and A. Schmidt, “Cybersecurity in A Hybrid Microgrid Testbed,” in 2023 IEEE 20th International Conference on Mobile Ad Hoc and Smart Systems (MASS). Toronto, ON, Canada: IEEE, Sep. 2023, pp. 610–611. [17] I. A. Oyewumi, A. A. Jillepalli, P. Richardson, M. Ashrafuzzaman, B. K. Johnson, Y. Chakhchoukh, M. A. Haney, F. T. Sheldon, and D. C. De Leon, “ISAAC: The Idaho CPS Smart Grid Cybersecurity Testbed,” in 2019 IEEE Texas Power and Energy Conference. College Station, TX, USA: IEEE, Feb. 2019, pp. 1–6. [18] J. J. Fritz, J. Sagisi, J. James, A. S. Leger, K. King, and K. J. Duncan, “Simulation of Man in the Middle Attack On Smart Grid Testbed,” in 2019 SoutheastCon. Huntsville, AL, USA: IEEE, Apr. 2019, pp. 1–6. [19] F. Tao, B. Xiao, Q. Qi, J. Cheng, and P. Ji, “Digital twin modeling,” Journal of Manufacturing Systems, vol. 64, pp. 372–389, 2022. [20] A. K. Jameil and H. Al-Raweshidy, “Implementation and evaluation of digital twin framework for internet of things based healthcare systems,” IET Wireless Sensor Systems, vol. 14, no. 6, pp. 507–527, 2024, cited by: 9. [21] S. Suhail, M. Iqbal, K. McLaughlin, B. Lee, and B. Imtiaz, “A framework for enhancing cyber incident response with security-enhancing digital twins in cyber–physical systems,” Internet of Things, vol. 31, p. 101547, 2025. [22] D. Krummacker, M. Reichardt, C. Fischer, and H. D. Schotten, “Digital twin development: Mathematical modeling,” in 2023 IEEE 6th International Conference on Industrial Cyber-Physical Systems, 2023, pp. 1–8. [23] S. Lyu, K. Y. H. Lim, C.-H. Chen, K. Youcef-Toumi, and X. J. Yang, “Human digital twins in healthcare and occupational well-being: Enabling techniques, applications, datasets and future trends,” Computers in Industry, vol. 177, p. 104463, 2026. [24] M. Saeed, H. Shafique, H. Manzoor, M. Ibrar, M. Javed, and A. Kanwal, “Agentic AI for Cybersecurity: Explainable Graph Neural Networks with Federated and Reinforcement Learning for Threat Prediction and Mitigation,” in 2025 International Conference on Frontiers of Information Technology. Islamabad, Pakistan: IEEE, Dec. 2025, pp. 1–6. [25] B. M. Peter and M. Korkali, “Robust Defense Against Extreme Grid Events Using Dual-Policy Reinforcement Learning Agents,” in 2025 IEEE Texas Power and Energy Conference. College Station, TX, USA: IEEE, Feb. 2025, pp. 1–6. [26] M. Kuri, S. Deshmukh, M. Nimbalkar, H. Hingoliwala, V. Vanarote, and P. Chandre, “Agent AI in Cybersecurity: A Novel Multi-Agent Architecture for Proactive Phishing Detection,” in 2025 IEEE 5th International Conference on ICT in Business Industry & Government. Indore, Madhya Pradesh, India, India: IEEE, Dec. 2025, pp. 1–8. [27] B. C. Belev, “Purdue Model Implementation in the Shipping Control Systems,” in 2022 10th International Scientific Conference on Computer Science, May 2022, pp. 1–4. [28] National Institute of Standards and Technology, “Vulnerability metrics: Common vulnerability scoring system,” https://nvd.nist.gov/vuln-metri cs/cvss, 2024, national Vulnerability Database, accessed: 7 July 2026. [29] T. R. Alves, “OpenPLC: An open source alternative to automation,” in IEEE Global Humanitarian Technology Conference, 2014. [30] OpenPLC Project, “OpenPLC runtime,” https://autonomylogic.com/, 2026, accessed: June 2026. [31] Rapid SCADA Development Team, “Rapid scada documentation,” https: //rapidscada.org/, 2026, accessed: June 2026. [32] Netfilter Project, “The netfilter project,” https://netfilter.org/, 2026, accessed: June 2026. [33] S. Purkayastha et al., “Comparison of open-source electronic health record systems based on functional and user performance criteria,” Health Informatics Journal, vol. 25, no. 4, pp. 1798–1810, 2019.

An Emulation Anchored Digital Twin Testbed for Cyberattack and Defense Analysis in Hospital IT OT Environments

Analyze & explore related research in Conceptio

Related documents