AE³GIS—An Agile Emulated Educational Environment for Guided Industrial Security Training

Abstract

Industrial Control Systems (ICSs) are the backbone of modern critical infrastructure, such as electric power, water treatment, oil and gas distribution, and manufacturing operations. While the convergence of IT and OT has greatly increased efficiency and observability, it has also greatly expanded the attack surface of these once-isolated systems. High-profile cyber-physical attacks, including Stuxnet (2010), TRITON (2017), and the Colonial Pipeline ransomware attack (2021), have shown that ICS-targeted cyberattacks can cause physical damage, disrupt economic stability, and put public safety at risk. Despite the growing prevalence and intensity of such threats, ICS-based cybersecurity education remains largely under-resourced and underfunded. Traditional ICS training laboratories require highly specialized hardware, vendor-specific tools, and expensive licensing that significantly raise barriers to entry. Traditional labs typically require on-site participation and pose physical safety concerns when cyber-physical attack scenarios are performed. These barriers leave students unable to get necessary security training for ICSs. Therefore, this paper introduces ${\mathrm{AE}}^3$GIS: Agile Emulated Educational Environment for Guided Industrial Security—a fully virtual, lightweight, open-source platform designed to democratize ICS cybersecurity education. Based on the GNS3 network simulation tool, ${\mathrm{AE}}^3$GIS enables rapid deployment of comprehensive ICS environments containing IT and OT systems, industrial communication protocols, control logic, and diverse security tools. ${\mathrm{AE}}^3$GIS is designed to provide practical training for students using realistic ICS cybersecurity scenarios through a local or remote training platform without the cost, safety, or accessibility limitations of hardware-based labs.

1. Introduction

Industrial Control Systems (ICSs) are necessary for the functionality of all of the essential services in modern-day society, including electric power generation, water treatment, oil and gas distribution, and transportation systems. Recently, as companies across the world have increased their need for greater automation, efficiency, and visibility, Information Technology (IT) and Operational Technology (OT) systems have become more and more integrated. IT typically refers to all the systems that are used to support the business and data operations of an organization, such as enterprise workstations, servers, databases, and network services. OT, on the other hand, typically refers to the actual equipment that is responsible for monitoring and controlling physical processes, including programmable logic controllers (PLCs), supervisory control and data acquisition (SCADA) servers, remote terminal units (RTUs), human–machine interfaces (HMIs), and field sensors and actuators.

The consequences of compromised ICS environments have been demonstrated not only in academic research but also in various high-profile real-world incidents. For instance, the Stuxnet worm (2010) [1] showed how malicious actors can cause physical damage by manipulating control logic on operational equipment such as PLCs. In this case, attackers manipulated the logic of a system that controlled centrifuges in Iran’s Natanz nuclear facility, which caused increased physical degradation. Incidents after that further emphasized how serious these risks are. For example, the TRITON malware (2017) [2] targeted the safety-instrumented systems (SIS) in a petrochemical facility in Saudi Arabia, showing that adversaries could disable or manipulate safety mechanisms that may lead to catastrophic outcomes. More recently, the incident at Colonial Pipeline (2021) [3] disrupted fuel supply operations across the Eastern United States. Although the intrusion initially affected the IT network, OT systems were preemptively taken offline to prevent potential spillover, and pipeline operations were at a standstill for days. These events demonstrate that ICS cybersecurity threats can severely disrupt economic activity, degrade critical-infrastructure reliability, and endanger public safety. This highlights the urgent need for accessible and effective cybersecurity training environments.

Although ICS organizations face an increasing volume and complexity of threats, many still struggle to develop a workforce with the skills needed to address them. Traditionally, ICS labs use expensive hardware, proprietary vendor products and licensing requirements which increase the cost to establish, develop and scale. Most of these labs must have direct physical access to the equipment being used, which prevents the feasibility of having remote learners. Simulating failures, logic disruptions, or unsafe operating conditions in a physical ICS lab involves a level of safety and liability concerns that most educational institutions cannot accommodate. As a result, practical ICS-security education is often limited to well-funded universities or industry settings. This paper introduces the Agile Emulated Educational Environment for Guided Industrial Security (${\mathrm{AE}}^3$GIS)—a lightweight virtual, open-source platform designed to increase ease of access and availability for cybersecurity education in the world of ICS. Using the open-source simulation tool known as Graphical Network Simulator-3 (GNS3), ${\mathrm{AE}}^3$GIS contains a variety of containerized ICS and networking components to provide a rapid deployment of complete ICS environments incorporating both IT and OT layers, industrial communication protocols, control logic and integrated security monitoring capabilities. ${\mathrm{AE}}^3$GIS has been developed to ensure ease of use, high scalability, and the ability for remote learners to engage in virtual ICS environments in real time.

1.1. Contributions

${\mathrm{AE}}^3$GIS is a systems-level framework that extends the GNS3 network emulator into a reproducible platform for ICS cybersecurity training. Its primary contribution is providing an orchestration layer that automates the creation, management, and modification of ICS laboratory scenarios, addressing limitations of manual, single-user GNS3 workflows. While the platform is designed with classroom deployment in mind, the contributions presented here concern the design and implementation of the framework itself. Unlike typical GNS3-based network scenarios that depend on manual configurations and static project files, ${\mathrm{AE}}^3$GIS introduces an orchestration layer that automates the creation, management, and modification of such scenarios.

Table 1. Functional comparison of baseline GNS3 and ${\mathrm{AE}}^3$GIS.

Capability	GNS3	${\mathrm{AE}}^3$GIS
Topology creation	Manual drag-and-drop via the desktop GUI; each node and link must be positioned and configured individually	Automated from declarative JSON templates generated programmatically through a web-based form
Scenario management	No native concept of reusable scenarios; instructors distribute static project files that are tied to a specific server configuration	Centralized scenario and topology library with full CRUD operations and portable templates
Multi-student deployment	Single-user application; concurrent students require manual duplication of project files and careful port/IP management	Automated per-student isolation through VM duplication (centralized mode) or coordinated template distribution (distributed mode)
Runtime interaction	Requires opening a manual console session to each node individually; no mechanism for batch operations across nodes	Script injection interface allows deploying and executing scripts on one or more running containers
ICS components	Supports Docker and QEMU nodes generically; users must source, build, and configure industrial appliances themselves	Ships with pre-configured ICS container images (OpenPLC, ScadaBR, historians, firewalls)
Telemetry and assessment	Console access to individual nodes; no centralized logging, log collection, or assessment tooling	Automated syslog-ng collector within each student environment; includes AI-assisted log analysis
Student management	No concept of students, submissions, or educational workflows	Browse students, review submissions, and request AI-generated summaries
Network architecture	Flat canvas; network segmentation and layered design are the user’s responsibility	Purdue Model enforcement (IT, DMZ, OT, Field) with inter-layer connectivity

highlights the differences between the baseline GNS3 and the ${\mathrm{AE}}^3$GIS framework. In further detail, the technical contributions of ${\mathrm{AE}}^3$GIS are as follows:

• Automated Orchestration Middleware: ${\mathrm{AE}}^3$GIS introduces an orchestration subsystem that automates the creation of network topologies from JSON-based templates. In addition, the subsystem allows virtual machine (VM) provisioning and network configuration. This enables reproducible deployments that are not achievable with GNS3 alone, where topologies must be built manually through the desktop GUI or by importing project files.
• Scenario-Centric Template System: Unlike GNS3, which requires instructors to manually configure the laboratory environment, ${\mathrm{AE}}^3$GIS provides reusable templates that define the different layers of the network, including the IT, OT, and DMZ layers, along with their security policies and protocol bindings. This approach ensures that each scenario is deployed in a consistent state, supporting reliable replay of attack-and-defense exercises. In GNS3, instructors are required to either rebuild topologies from scratch or distribute entire project directories, which are not portable across different server installations.
• Classroom-Scale Isolation and Deployment: The ${\mathrm{AE}}^3$GIS framework provides support for two different deployment architectures: centralized instructor-hosted VMs and distributed student-hosted GNS3 instances. In the centralized mode, a separate isolated copy of a scenario is generated for each student or group to prevent IP address conflicts. The framework also provides isolation of identical topologies into separate runtime environments to prevent a student’s actions (crashing a PLC or flooding a network) from impacting other students’ environments. In contrast, GNS3 is designed to run as a single-user application and does not have any features to allow multi-tenant isolation.
• Runtime Control and Dynamic Reconfiguration: The framework provides a separate subsystem to interact with running environments. Instructors and students can inject scripts into running containers to modify device configurations, infect devices with malicious code, or modify PLC logic without shutting down and rebuilding the environment. This feature is useful for implementing evolving scenarios such as multistage advanced persistent threat (APT) emulations that change behavior mid-lab. In contrast, GNS3 lacks any mechanism for injecting runtime scripts or triggering events inside running containers. This can only be achieved by opening a manual console session and executing commands on each node individually.
• ICS-Aware Component Abstraction: ${\mathrm{AE}}^3$GIS ships with a library of industrial system components packed as preconfigured docker containers, including PLCs, HMIs, historians, and intrusion detection systems (IDS). GNS3 supports Docker containers and QEMU VMs as generic nodes but does not include ICS-specific appliances or preconfigured industrial protocol stacks; these must be sourced, built, and configured by the user.
• Centralized Telemetry and AI-Assisted Analysis: ${\mathrm{AE}}^3$GIS is designed to capture command sequences from all active containers by deploying password-protected syslog-ng collector nodes in the environment. At the same time, the platform also integrates a proof-of-concept analysis tool that uses large language models (LLMs), which can automatically summarize the collected telemetry and generate preliminary feedback for the instructors. GNS3 allows console access to individual nodes but does not offer any tools to collect logs centrally, aggregate telemetry, or support any form of assessment.
• Centralized Resource and Student Management: ${\mathrm{AE}}^3$GIS provides instructors with a management interface through which they can create, edit, and distribute topologies, scenarios, and scripts centrally, which is accessible to all the students connected to the environment. The platform also includes a student registry and a telemetry data submission management interface. Instructors can browse all students, review any submissions, and request AI-assisted analysis. GNS3 has no concept of students, submissions, or shared educational content; it’s simply a network emulation tool, not a learning management system.
• Unified IT/OT Stack Implementation: ${\mathrm{AE}}^3$GIS adopts the Purdue Model, virtualizing the entire communication stack from the enterprise workstation to the simulated field devices. Although GNS3 can host heterogeneous nodes on the same project canvas, it provides no network segmentation models or layered architectural templates. These conventions must be designed and enforced manually by the users.

1.2. Motivation Behind an Open-Source Virtual ICS Lab

ICSs are a major part of modern critical infrastructure; however, for many institutions, providing hands-on education in ICS security is difficult. Most existing ICS labs depend on proprietary hardware, vendor-licensed software, and special equipment, which require considerable funding, dedicated physical space, and continuous technical support. This means many universities—especially community colleges, regional campuses, and programs with remote learners—cannot offer hands-on ICS security training. These limitations make for unfair educational opportunities where only well-resourced institutions can expose their students to hands-on cybersecurity exercises.

ICSs incorporate a wide range of IT and OT components such as workstations, IDSs, firewalls, PLCs, HMIs and SCADA servers, creating an environment that is inherently complex. Recreating these environments with real hardware can be costly and challenging to maintain, especially when students experiment with device misconfigurations, protocol misuse, or even performing destructive attacks. A virtual ICS testbed allows for ICS environments to be replicated using open-source tools to introduce different ICS devices and communication protocols without having to purchase new, often expensive hardware.

Virtual testbeds also eliminate the risk and significant maintenance associated with using physical equipment to train students on ICS cybersecurity. Physical ICS labs often require the close supervision of students while they modify PLC logic, run adversarial experiments, or deliberately cause system failures within the ICS environment. With ${\mathrm{AE}}^3$GIS, students can freely practice attacking and defending ICS while being able to instantly reset the environment and learn from their mistakes, without the risk of damaging physical hardware.

One of the biggest challenges to ICS security education is still accessibility. As programs increasingly move to incorporate hybrid and online learning formats, the majority of students lack access to the specialized hardware or on-site facilities generally needed to interact with ICSs. Because ${\mathrm{AE}}^3$GIS depends entirely on open-source tools and virtualized IT/OT components, learners everywhere—regardless of location or institutional resources-can interact with realistic ICS scenarios, experiment with attacks and defenses, and develop practical skills in a safe, scalable, and affordable way.

2. Related Works

Many of the current ICS platforms are well-suited for research or specialized experimentation, but few have been designed with ease of use and accessibility in mind. In particular, educational institutions often lack open-source, lightweight, instructor-friendly environments for teaching ICS security concepts. In this section we review previous work related to cybersecurity testbeds, consisting of physical, hybrid, and virtual implementations. Our main interest is on testbeds developed for ICS education, but we consider also works from related domains such as Internet of Things (IoT) and Cyber-Physical Systems (CPS). We are most interested in physical and hybrid implementations published after 2020; however, we also include several well-established virtual testbeds developed prior to 2020, as these earlier platforms remain influential and are most closely related to our fully virtual approach.

2.1. Physical Testbeds

Physical testbeds use real hardware and networking equipment to mimic industrial processes at a smaller scale. They are valuable for replicating real-world conditions with high accuracy and for identifying hardware vulnerabilities or network latency issues. However, they are costly to build and require significant expertise to operate and maintain.

The Low-cost ICS Security Testbed (LICSTER) [4] addresses the cost barriers associated with ICS security education through a physical implementation using affordable components. It is built using Raspberry Pi devices, STM32F7 controllers, and OpenPLC software, creating a tangible ICS that costs about 500 euros to assemble. This setup gives students direct experience working with real hardware and observing how industrial protocols like Modbus/TCP operate in practice. However, because LICSTER relies on physical hardware, it faces challenges in scalability and accessibility. The number of students who can participate is limited by the number of devices that are available, making it difficult to use in larger classes. Geographic accessibility becomes a critical concern, as students in remote or online learning environments cannot access the physical hardware. The physical components also require ongoing maintenance, replacement, and technical support that adds operational overhead for educational institutions already struggling with limited resources. Furthermore, the physical constraints of LICSTER limit the types of attack scenarios that can be safely demonstrated.

The Security Water Processing (SWaP) testbed [5] implements a three-stage water process controlled by programmable logic controllers (PLCs), sensors, and actuators connected through wired and wireless channels. Its main goal is to create datasets of both normal and attack operations. The authors record every network packet, along with sensor and pin data, and provide a dataset containing around six hours of normal operation data as well as various attack scenarios that could cause damage to the system. These attacks include Water Theft, State Machine DoS, Stealthy Fake Sensor Injection and others. Unlike ${\mathrm{AE}}^3$GIS, which focuses on providing a virtualized testbed for education, SWaP is fully physical and built primarily for dataset generation. Another limitation the authors highlight is the lack of a remote operational interface to give other researchers access to the testbed to run experiments and collect their own data. ${\mathrm{AE}}^3$GIS, being fully virtualized, doesn’t require a remote operational interface since it can be easily replicated, distributed, and used by both researchers and educators.

The Naval Defense Cybersecurity Testbed [6] models a warship to benchmark cyberattacks and evaluate the corresponding countermeasures. It includes physical components that represent the ship’s operational subsystems—such as propulsion and artillery—corresponding to Level 0, 1, and 2 devices of the Purdue model.

In comparison, ${\mathrm{AE}}^3$GIS extends across all five levels of the Purdue model. The testbed also defines several attack scenarios, grouped into two main types: network attacks, such as introducing rogue devices or sending malformed packets, and process attacks that target physical devices like PLCs to disrupt normal system behavior.

Waraga et al. [7] present an open-source platform for identifying weaknesses in IoT networks and communications. Their system automatically evaluates the vulnerabilities of IoT devices without human intervention. The authors test their approach on two IoT devices—a wireless camera and a smart bulb—by launching several types of attacks, including downgrade, brute-force, SQL injection, and replay attacks. The results show that the platform can effectively evaluate the security of IoT devices. However, it was not designed for educational or ICS environments and does not provide a broader framework for testing ICS scenarios like ${\mathrm{AE}}^3$GIS does.

In general, physical testbeds are constrained by cost, scalability, maintenance requirements, and safety concerns. They are highly specialized, expensive to replicate, and are not meant for general-purpose or classroom-scale deployment. In contrast, ${\mathrm{AE}}^3$GIS relies entirely on virtualized components and open-source tools.

2.2. Hybrid Testbeds

Hybrid testbeds are a combination of virtual simulations along with physical components. In the context of ICS, these testbeds are generally used to create testing environments for cybersecurity research and education that integrate real hardware (e.g., PLCs, sensors, and embedded devices) with emulated networking and ICS components.

CyberVAN (Cybersecurity Virtual Assured Network) [8] is a testbed that is designed for creating and running high-fidelity cybersecurity scenarios. It supports physical machines, VMs, and simulated networks which are all managed through a graphical user interface (GUI). CyberVAN combines three key methodologies, which are software-in-the-loop simulation for routing real traffic through simulated networks, transparent packet forwarding for seamlessly integrating physical and virtual devices, and host virtualization that supports both containers and full VMs. For large-scale experiments, CyberVAN might suffer from timing delays due to discrete-event simulation running slower than real time. To handle this issue, it includes a custom synchronization system, TimeSync that aligns VMs with the simulated time to ensure consistency. Although CyberVAN is an advanced and flexible platform, it was developed for advanced research at the U.S. Army Research Laboratory for studying malware propagation or botnet detection, and therefore it is not intended for educational use.

KYPO4INDUSTRY [9] is an ICS cybersecurity testbed and is mainly used for educational purposes. The authors propose a hybrid testbed and design a course that teaches undergraduate students about ICS threats through hands-on experiments and structured exercises. It integrates simulated and real components to emulate ICS networks and processes, allowing students and researchers to practice attack and defense strategies using real hardware elements like PLCs and virtualized software elements using docker containers. Compared with ${\mathrm{AE}}^3$GIS, KYPO4INDUSTRY relies on a heavier virtualization framework and requires specialized infrastructure, whereas ${\mathrm{AE}}^3$GIS was designed to be lightweight and easily deployed in educational settings.

Cui et al. [10] introduce a CPS testbed for monitoring and wide-area control in power systems. The setup presented here integrates a real-time digital simulator (RTDS) with software-defined networking (SDN) and VMs to study control stability and resilience against cyber-attacks. The testbed emulates realistic wide-area power grid scenarios, thus testing both the monitoring and defense mechanisms against possible DoS or even false data injection attacks. Unlike ${\mathrm{AE}}^3$GIS, which generalizes across industrial domains for education, this CPS Power System testbed is highly specialized to the electric grid and requires very expensive RTDS hardware, thus limiting its accessibility for classroom use.

Das et al. [11] present the design of a scalable cyber-physical testbed for testing the cybersecurity of synchrophasors in power systems. Their testbed leverages an Opal-RT real-time digital simulator and VMs with the CORE network emulator. This combination is used to study attacks on phasor measurement units (PMU) and the IEEE C37.118 protocol [11]. They also create an open-source tool, pySynphasor, to manipulate synchrophasor packets and inject false data. Advanced attack scenarios such as man-in-the-middle and false data injection are demonstrated with this testbed. This testbed is primarily geared toward research because it requires a high level of expertise, hardware, and is specialized toward PMU security. ${\mathrm{AE}}^3$GIS, on the other hand, falls well within the realm of ICS, with no reliance on hardware simulators, and is suited for teaching a vast number of concepts related to ICS security.

The HAI (Hardware-in-the-Loop Augmented ICS) testbed [12] combines three physical control systems-a GE turbine, Emerson boiler, and FESTO water treatment plant-with a hardware-in-the-loop (HIL) simulator. Attacks are defined at the process control loop level, enabling stealthy manipulations of setpoints, process variables, and control outputs. The main goal of HIL is dataset generation for anomaly detection research rather than providing flexible, scenario-driven exercises for ICS education.

Brown-IIoTbed [13] is a cybersecurity testbed, focused on brownfield industrial IoT (IIoT) that integrates legacy devices with modern IoT technologies. The testbed combines physical components, including Raspberry Pi, Arduino controllers and sensors, along with virtualization for cloud and edge services, and it supports several protocols found within common IIoT systems such as Modbus/TCP, CoAP, and MQTT. It evaluates a wide range of attack scenarios by using the Spoofing, Tampering, Repudiation, Information Disclosure, DoS, and Elevation of Privilege. Although Brown-IIoTbed provides great realism and is a great value for research in the area of IIoT, reliance on hardware makes it less scalable for use in the classroom.

2.3. Virtual Testbeds

There are a number of virtual testbeds that have been proposed in the recent years for different objectives, leading to different design choices. We compare ${\mathrm{AE}}^3$GIS with other notable virtual testbeds in this section.

One prominent example of a virtual testbed is the Graphical Realism Framework for Industrial Control Simulations (GRFICS) [14], which has evolved through three major versions and stands as one of the most advanced virtual ICS security training platforms available. GRFICS uses the Unity 3D game engine to create a realistic chemical process simulation that shows the physical impact of cyberattacks. It demonstrates scenarios such as buffer overflow exploits, man-in-the-middle attacks, and command injection. Despite its strengths, GRFICS faces several limitations as an educational platform for wider institutional use. Its dependence on Unity 3D and multiple VMs require high-performance hardware that may exceed the resources of many institutions. GRFICS is also built around a single chemical process model, making it difficult for educators to design varied learning scenarios that reflect the diverse nature of real-world industrial systems. This limitation is compounded by its focus on control-logic attacks rather than network-based security concepts, which means students may not gain sufficient exposure to the broader network security challenges present in modern environments where IT and OT systems are increasingly connected.

Similarly, the Virtualised ICS Open-source Research Testbed (VICSORT) [15] is a research-oriented platform developed to address some of GRFICS’s limitations. Built as a modified version of GRFICS using lightweight containers managed by Linux container daemon, VICSORT follows the Purdue model across levels 0–2 and includes six types of virtualized components such as PLCs, HMIs, Engineering Workstations (EWS), and firewalls. Its container-based design reduces hardware demands compared to full VM setups, making it somewhat more accessible for educational use. However, VICSORT still targets cybersecurity researchers and advanced students rather than general classroom adoption. Although VICSORT improves accessibility compared to GRFICS, it still assumes a level of technical skill and infrastructure that many institutions may not have, especially those without dedicated IT support or faculty with deep virtualization experience.

The Gotham testbed [16] emulates large-scale IoT environments with up to 100 devices, including 30 switches and 10 routers. It operates as a GNS3 client with orchestration tools that leverage the GNS3 REST API to automate node creation, configuration, and scenario deployment. This testbed includes an IoT testbed orchestrator, a template creation engine for building Dockerfiles and ISO images, a topology builder, and a scenario generator that launches nodes sequentially based on predefined scenarios. To emulate realistic network conditions, Gotham uses Linux’s tc/netem utility to control link bandwidth and reproduce realistic traffic behavior, addressing GNS3’s limitation of not supporting bandwidth control. The testbed supports real communication through MQTT, CoAP, and RTSP (with RTP/RTCP) implementations deployed within its layered architecture, which consists of edge, network, and cloud layers. While Gotham offers a flexible environment for IoT experimentation and dataset generation, its focus remains on IoT/IIoT systems rather than ICS. Moreover, it relies on a static network topology for data collection, whereas our work enables dynamic topology creation and a wider range of experimental scenarios.

Labtainers [17] is a cybersecurity lab framework that uses Docker containers to deliver Linux-based exercises to students. The framework is designed to be lightweight and easy to deploy, running directly on a student’s system without the need for a full VM per lab. One major limitation of Labtainers is the lack of a GUI. Students cannot easily visualize the network topology they are working with, which can make it harder to understand the structure and flow of the exercises. Another limitation is that students must manually package and send their work to the instructor for assessment. This can be tedious and error-prone, especially for large classes or students working remotely. Labtainers attempts to reduce plagiarism by parameterizing each student’s lab environment through configuration files. This ensures students receive slightly different versions of each exercise. While ${\mathrm{AE}}^3$GIS does not support parameterization, it takes a different approach by logging all activity centrally so that instructors can monitor and verify each student’s actions.

The ICSSIM framework [18] takes a different approach by offering a development framework rather than a complete testbed solution. It provides base classes for simulating virtual control system components and supports deployment across various environments, utilizing Raspberry Pi hardware, Docker containers, and GNS3 simulations. Although this framework allows for extensive customization and its built-in support for GNS3 aligns well with our proposed approach, ICSSIM is primarily designed for developers rather than educators. As a result, building meaningful educational scenarios with ICSSIM requires programming and system development skills that go beyond what most cybersecurity or industrial engineering instructors typically possess.

ICSRange [19] is a cyber range platform specifically designed for simulating ICS in cybersecurity training and research. It is built using VMs and relies on open-source technologies to replicate an enterprise network connected to an ICS environment. The platform is used to train red teams, improve defense strategies for blue teams, and explore cybersecurity methodologies related to risk mitigation. The architecture of ICSRange includes several core components: A firewall gateway for protecting the network, a web server placed in a Demilitarized Zone (DMZ), a bastion login node for controlled access to the ICS, an ICS network featuring a SCADA Master Terminal Unit (MTU) and a PLC that interfaces with sensors, actuators, and valves. To demonstrate its effectiveness, the authors of ICSRange simulate a multi-stage attack that mimics real-world advanced persistent threats (APTs). The scenario includes lateral movement from an enterprise network into an ICS that controls water tanks, ultimately causing a shutdown and unintended emptying of the tanks. While ICSRange is a powerful platform for cybersecurity training and research, it differs from ${\mathrm{AE}}^3$GIS in that it is dependent on heavier VMs, as well as the advanced experience and knowledge required to use ICSRange.

MiniCPS [20] is a framework designed for research on cyber-physical systems (CPS), with a focus on communication and physical-layer interactions. It is built on top of Mininet, a lightweight network emulator, and extends it by adding tools that simulate key CPS components such as PLCs, industrial protocols, and basic physical processes. One of the main features of MiniCPS is its simple API, which enables the simulation of physical-layer interactions. It also provides tools written in Python 2.7 that allow real-time emulation of network traffic in a virtual CPS environment. Similar to ${\mathrm{AE}}^3$GIS, MiniCPS utilizes an emulated network environment to model the behavior of devices found in industrial systems. However, MiniCPS uses a very basic model for physical-layer simulation. For example, it transfers sensor data over UDP without accurately modeling the behavior of serial or industrial communication links. In addition, MiniCPS is built on Mininet, which is mainly suitable for lightweight emulations and lacks support for more complex topologies and full VM integration, while ${\mathrm{AE}}^3$GIS is built on GNS3, making it more suitable for hands-on educational use with diverse and complex lab scenarios.

${\mathrm{AE}}^3$GIS takes a different approach in that it seeks to provide realistic cybersecurity scenario simulations in ICS environments through the orchestration of GNS3-based labs. Unlike most of the work in this field, which focuses on providing realistic simulations of physical processes, ${\mathrm{AE}}^3$GIS focuses on providing simulations of multi-layer ICS environments. Thus, the proposed platform is more pertinent in educational environments in which dozens of students need identical, yet isolated testbeds simultaneously. In addition, this approach frees up instructors from infrastructure burdens such as topology provisioning, student isolation, telemetry collection, and lab assessment.

Table 2. Comparison of Related Testbeds.

Testbed (Year)	Type	Primary	Educational	Graphical	Remote	Scenario	Purdue Model	Monitoring	Modular	Licensing	Relative
		Domain	Focus	Interface	Access	Library	Levels	/Logging	/Extensible		Cost
${\mathrm{AE}}^3$GIS (2026)	V	ICS	✓	✓	✓	✓	IT + OT	✓	✓	Open-source	Low
Gotham (2023) [16]	V	IIoT	×	✓	—	✓	OT	✓	✓	Open-source	Low
MiniCPS (2015) [20]	V	CPS	×	×	—	×	OT	—	✓	Open-source	Low
ICSRange (2019) [19]	V	Water ICS	✓	×	—	×	IT + OT	—	—	Mixed	Medium
GRFICS (2018) [14]	V	ICS	✓	✓	—	×	OT	—	—	Open-source	Low
VICSORT (2022) [15]	V	ICS	✓	✓	—	×	OT	—	✓	Open-source	Low
ICSSIM (2023) [18]	V	ICS	×	✓	—	×	OT	—	✓	Open-source	Low
Labtainers (2017) [17]	V	Generic IT	✓	×	✓	✓	IT	✓	✓	Open-source	Low
CyberVAN (2016) [8]	H	Generic	×	✓	✓	✓	IT	✓	✓	Proprietary	High
KYPO4INDUSTRY (2020) [9]	H	ICS	✓	✓	✓	✓	IT + OT	✓	✓	Mixed	High
Cui CPS testbed (2020) [10]	H	Power CPS	×	×	×	×	OT	✓	—	Proprietary	High
Synchrophasor (2025) [11]	H	Power CPS	×	×	×	×	OT	✓	✓	Mixed	Med–High
HAI 1.0 (2020) [12]	H	ICS	×	—	×	×	OT	✓	—	Proprietary	High
Brown-IIoTbed (2021) [13]	H	IIoT	×	—	×	×	OT	✓	✓	Mixed	Med–High
LICSTER (2019) [4]	P	ICS	✓	✓	×	×	OT	✓	—	Open-source	Low
SWaP (2023) [5]	P	Water ICS	✓	✓	×	×	OT	✓	✓	Proprietary	High
Naval Defense (2022) [6]	P	Naval ICS	×	✓	×	×	OT	—	—	Proprietary	High
Waraga IoT (2020) [7]	P	IIoT	×	✓	×	×	OT	✓	✓	Open-source	Medium

Legend: Type: V = fully virtual, H = hybrid (virtual + physical), P = physical. Educational Focus indicates whether the testbed is explicitly designed for teaching or training. Purdue Levels denotes whether the architecture spans only IT segments, only OT segments, or both IT and OT. Scenario Library refers to built-in support for reusable, pre-defined scenarios. Monitoring/Logging captures whether centralized monitoring, logging, or traffic capture is supported. Licensing indicates whether the implementation is primarily open-source, proprietary, or a mix. Relative Cost is a qualitative estimate based on the descriptions provided in the respective publications. Symbols: ✓ = feature present; × = feature not present; — = not stated. Note: Feature flags were determined from explicit statements in the cited publications where available, supplemented by examination of publicly accessible source code repositories and reasonable inference from the described system architectures. In cases where a capability could not be determined with confidence, it is marked as —.

compares ${\mathrm{AE}}^3$GIS with previous work on cybersecurity testbeds.

3. ${\mathbf{AE}}^{\mathbf{3}}$GIS Architecture and Design Tenets

This section describes the layered architectural design behind ${\mathrm{AE}}^3$GIS. The chosen design is driven by the need to support high-fidelity ICS experimentation spanning the entire Purdue Model while ensuring that scenarios remain reproducible, lightweight, and open-source.

3.1. Testbed Architecture

${\mathrm{AE}}^3$GIS was developed to emulate realistic industrial cyber-physical environments while maintaining full virtualization and pedagogical control. The primary design goal is to support reproducible, scalable cybersecurity experimentation in ICS contexts with no dependence on specialized physical equipment. The testbed architecture embraces software-defined infrastructure, open-source components, and emulated device logic to drive attack and defense workflows in fully virtualized environments.

${\mathrm{AE}}^3$GIS takes the Purdue model [21] as its reference architecture, implementing the network layers of OT, IT, and DMZ using virtual network appliances. PLCs, sensors, and actuators in the OT domain, firewalls, and jump servers in the DMZ, enterprise workstations are deployed using Docker containers and orchestrated through the GNS3 platform. GNS3 provides the necessary graphical and logical framework, but ${\mathrm{AE}}^3$GIS extends it with scripting interfaces, telemetry systems, and topology generation tools to introduce dynamism and scalability beyond GNS3’s capabilities.

3.1.1. Foundational Technologies

${\mathrm{AE}}^3$GIS is built on top of widely adopted open-source platforms to ensure portability, reproducibility, and accessibility. The two main technologies on which ${\mathrm{AE}}^3$GIS is built are discussed below.

Graphical Network Simulator-3 (GNS3)

GNS3 is a network emulation platform that allows users to build virtual network topologies using existing and user-defined networking appliances. These networking appliances include custom VMs and docker containers, as well as ready-made networking appliances available in the GNS3 appliance marketplace. GNS3’s network simulation capability can offer a more accurate representation of the network when compared to other network simulators since it does not attempt to simulate the network but actually uses the network stack to forward the actual network packets. In ${\mathrm{AE}}^3$GIS, GNS3 operates as the connectivity platform, which handles the connectivity between the devices while abstracting the complexity of the network. This allows for the accurate simulation of realistic network environments, such as enterprise and ICS networks.

Docker and Containerization

Docker is a platform for building and running applications across different operating systems (OS) such as Windows, MacOS and Linux. It uses OS-level virtualization to create multiple isolated environments on the same physical machine. Software applications can be encapsulated into containers, which include the necessary libraries and dependencies required for the program to execute while sharing a common kernel with other containers on the same host. Containers are much lighter than VMs since they take only a few seconds to start as opposed to VMs, which can take several minutes to initialize. This lightweight nature enables us to run hundreds of containers on a single physical host. Docker containers are used to simulate most of the ICS and networking appliances in ${\mathrm{AE}}^3$GIS, including PLCs, HMIs, servers, firewalls, workstations, etc.

3.1.2. Topology Structure and Layered Composition

The topology of the Purdue model seen in Figure 1 and the corresponding topology deployed inside GNS3 seen in Figure 2 are segmented into distinct layers. Each layer is dedicated to provide a specific function within an ICS environment. These levels contain virtual appliances that are configured to emulate the behavior of their real-world counterparts.

At level 0 of the Purdue model, ${\mathrm{AE}}^3$GIS simulates the physical sensors and actuators using the Python Sub-Module (PSM) that is included as a hardware option in OpenPLC Runtime [22]. The PSM exposes a python interface for users to implement any custom behavior between the OpenPLC Runtime and device hardware. This flexibility of PSM allows for writing simple python functions to model physical component behaviors, such as serial communication.

At Level 1 of the Purdue model, the logic control layer is implemented using OpenPLC instances that interact with the physical devices via the PSM. It can expose physical device behavior using simple Python functions for sensors and actuators. The communication between the logic control layer and the supervisory layer is performed via the Modbus/TCP protocol, with the OpenPLC instances operating as Modbus servers and the SCADA/HMI components operating as Modbus clients. In addition, since the entire topology of the ${\mathrm{AE}}^3$GIS is implemented on virtual devices only, Modbus/TCP protocol communication occurs over standard Ethernet interfaces within the GNS3 topology. It is also important to note that although Modbus/TCP protocol is used in the default configuration of the topology, other industrial communication protocols such as DNP3 and OPC UA are also supported by OpenPLC.

Levels 2–3 include the Supervisory and DMZ layers. The Supervisory layer hosts ScadaBR [23], which functions as an HMI component, utilizing an Ubuntu-based container to display field measurements, operator command functions, and system trends. EWS and update/patch servers are achieved through lightweight Ubuntu containers with custom Python script-based automation, simulating software update, configuration, signature distribution, and periodic polling of Level 1 PLCs. DMZ-based services include security-related functions, including SMB file servers, OpenSSH/VPN servers, and intrusion detection using either Suricata or Snort 3. These functions allow for hands-on exercises on topics including secure remote access, host pivoting, log analysis, and malware propagation. Firewalls within this layer can utilize any of the following tools: iptables, nftables and FireHOL.

Levels 4–5 include simulated Enterprise IT Services, which include common IT services within an enterprise network. These include ISC-DHCP servers, Samba SMB file servers, NGINX and Apache web servers, VSFTPD FTP servers, MySQL historian databases, and Ubuntu desktop workstations with remote access capabilities. These services provide an operational environment to support adversarial scenarios, including lateral movement, directory traversal, and remote exploitation. The modular design allows for additional services, including Bind9 DNS, Windows clients, Active Directory, and centralized log servers.

All devices communicate on software-defined VLANs that are interconnected via switches (e.g., Open vSwitch) and routers. The virtualized network infrastructure implements segmentation, firewall rules, and routing that mimic typical ICS segmentation. The rules for access control, port filtering, and communication zones can be tailored to accommodate a wide variety of offense and defense scenarios.

3.1.3. Network Architecture and Communication Patterns

The communication patterns in ${\mathrm{AE}}^3$GIS are designed to mimic IP-based virtual networks and have specific bandwidth restrictions that mimic the real-world environment. The restrictions include latency, jitter, packet loss, and bandwidth limitations achieved via the use of Linux-based tc (traffic control) commands. Such restrictions are imposed on specific network interfaces.

Communication among the devices have been designed to mimic real-world ICS scenarios. The field devices periodically send updates or respond to PLC polling. The PLC then sends control signals to sensors and actuators that are defined using the PSM. The SCADA and HMI periodically poll PLCs and show the results graphically. The EWSs upload new logic or perform maintenance. The IT workstation connects via a jump server or VPN entry points.

To account for the diversity of components found in an ICS environment, there are multiple alternative technologies for equivalent functions. For the network layer, switching and routing can be achieved via Open vSwitch and Linux-based bridge-router solutions. This allows for a comparison of switching and routing behaviors and access control enforcers. For the firewall function, there are three alternative technologies such as iptables, nftables, and FireHOL. For the protocol layer, there is default support for Modbus/TCP. The support for other protocols such as DNP3 and OPC UA via OpenPLC’s communication driver framework is also possible. This allows for a demonstration of the differences that different protocols have on polling and attack vectors.

Telemetry is implemented at the host level. Syslog-ng collectors are deployed as log monitoring tools on both the IT and OT layers. These collectors are connected to the IT and OT switches and are configured to accept and save logs along with the timestamps for every ICS component in the topology. This provides instructors with the telemetry data they need to monitor students’ activities and perform assessment.

The communication paths have been designed to cover all layers of the Purdue Model and include field-level interactions and enterprise-level IT services. The support of multiple protocol families and interchangeable network and security components provides instructors with a broad range of choices for building scenarios for instructional purposes.

Table 3. Protocols supported at each Purdue Model level in ${\mathrm{AE}}^3$GIS.

Purdue Model Level	Supported Protocols
Level 0: Physical Process *	Modbus/TCP, Ethernet/IP
Level 1: Control	Modbus/TCP, DNP3, Ethernet/IP, S7
Level 2: Supervisory Control	Modbus/TCP, HTTP/HTTPS, SSH
Level 3: Operation Management	SMB, FTP/FTPS, SSH
Level 3.5: OT DMZ	SMB, SSH, FTPS, HTTPS
Levels 4/5: IT Systems	DHCP, DNS, SMB, HTTP/HTTPS, FTP, SSH

* Level 0 behavior is simulated internally via OpenPLC’s PSM. Note: Modbus/TCP is the primary protocol that is demonstrated in the current pre-configured scenarios. Other protocols listed (DNP3, Ethernet/IP, S7) are supported by the underlying OpenPLC backend.

shows a summary of the communication paths.

3.1.4. Deployment Architectures

${\mathrm{AE}}^3$GIS offers two deployment options to meet the varied resource needs of different institutions. Both options utilize the same scenario, ensuring that the same learning objectives are met in both cases.

Mode  A: Centralized Infrastructure Deployment

In this mode, the instructor leverages a dedicated server, either physical or cloud-based, that hosts multiple isolated GNS3 environments, with one environment allocated per student or student group. The instructor provisions a single QEMU-based VM that is preloaded with GNS3 templates and scenario definitions. The orchestration layer then duplicates this VM on demand, assigning each instance a unique IP address. Students access their isolated GNS3 environments remotely by configuring their GNS3 client to connect to the IP address associated with their assigned instance. The primary trade-off is that the institution must provision server hardware that scales linearly with the size of classes; the associated resource requirements are evaluated in the experiments presented in Section 5.3.

Mode B: Distributed Student-Hosted Deployment

In the alternative deployment mode, students run GNS3 servers locally on their own machines. The instructor hosts only the ${\mathrm{AE}}^3$GIS web frontend and backend API, which are lightweight and can run on an instructor’s laptop or an inexpensive cloud instance. In this configuration, the instructor’s service is responsible only for orchestrating access to scenarios and coordinating deployments, while all network emulation and container execution occurs on the student’s machine. The trade-offs include variability in student hardware capabilities and the need for local configuration, although detailed installation guides are provided in the repository.

3.1.5. Simple Instantiation and Access Workflow

Figure 3 shows the implementation architecture of ${\mathrm{AE}}^3$GIS. The GUI offers a seamless method for loading, editing and instantiating the scenarios using the ${\mathrm{AE}}^3$GIS REST API. Furthermore, the GUI allows users to easily generate ${\mathrm{AE}}^3$GIS instances with GNS3 servers executed inside an isolated VM. The created ${\mathrm{AE}}^3$GIS instances come pre-configured with the templates needed to for students to execute the ICS scenarios. This system makes it possible for entire classes to execute similar scenarios simultaneously, while preserving separation of students to work individually in isolated environments. This set up allows GNS3 to be used in a classroom setting with several student or groups, without requiring much configuration by the students or the instructor.

Instructors use the ${\mathrm{AE}}^3$GIS front-end to define ICS scenarios to select device types (e.g., PLCs, HMIs, file servers, sensors, firewalls) and specifying network configurations. The front-end then generates a structured, machine-readable file describing the entire environment. This file is handed over to the ${\mathrm{AE}}^3$GIS orchestration API, which deploys the scenario locally or remotely in one or more ${\mathrm{AE}}^3$GIS instances. The API initiates the scenario by setting up all the elements that are necessary—such as virtual switches, routers, and firewalls—along with containerized IT/OT components, and applies the networking rules that have been defined by the instructor. Each student will be assigned an isolated environment for working on their copy of the ICS scenario. In every ${\mathrm{AE}}^3$GIS instance, there is a fully containerized model of an ICS environment made up of different components, such as OpenPLC, ScadaBR HMIs, Ubuntu EWS, Suricata, Zeek, MySQL historian, SMB/FTP server, and other IT/OT components. GNS3 manages link constraints, routing behavior, and inter-device communication that are necessary for the ICS operating conditions to be as realistic possible. By connecting to their respective virtualized servers, students can get access to the ${\mathrm{AE}}^3$GIS instance that has been allocated to them and they can operate the ICS topology like they would in a real ICS testbed. This enables practical exercises such as uploading PLC logic, telemetry analysis, red/blue team activities, and playing with defensive or adversarial techniques across the whole ICS stack.

3.1.6. Scalability and Template-Based Extensibility

${\mathrm{AE}}^3$GIS addresses the problem of the complexity of large-scale topologies through a dedicated tool for topology generation. This tool utilizes the GNS3 API to deploy preloaded components, assign configurations, and link multiple components to form the ICS stack based on the Purdue model. The topology customization interface shown in Figure 4 allows instructors to specify the types and numbers of components they want in an ICS network scenario that will be generated dynamically.

The workflow for configuring and building topologies via the ${\mathrm{AE}}^3$GIS GUI starts with defining the main network domains. First, the user configures the types and number of nodes needed in the IT Layer (1). Then the user defines the devices and parameters of the OT Layer (2). After that, the user defines the network devices that make up the DMZ between the IT and OT domains (3). Once the structure of the network is set, the workflow proceeds to specific device configuration, where the user needs to assign the protocol or service implementation of each device from the pre-defined docker templates (4). Finally, the user saves the topology which creates a JSON object with dynamically generated links and node positions, which is used to build the actual topology in GNS3 (5). Students can access this saved topology and trigger the build process for any configuration to be deployed to their GNS3 instance.

Topologies generated from the configuration interface assume positions inside the GUI based on the Purdue level it represents and automatically connect to the necessary network components such as switches, firewalls, and routers. This means that the students and teacher would only require minimal interaction during the creation of the topology.

Apart from dynamic generation, ${\mathrm{AE}}^3$GIS provides a range of reusable templates that can be applied for the generation of common ICS scenarios. These reusable templates help ensure that the generation of scenarios not only becomes repeatable, but becomes extendable as well. Teachers can utilize the base-level reusable templates to design lab exercises based on learning objectives, enabling ${\mathrm{AE}}^3$GIS to serve both educational and research purposes in ICS domains.

3.2. Overcoming Significant Challenges and Providing Technical Solutions

Although GNS3 provides an adaptable graphical interface for virtualized networking and has emerged as popular software for IT laboratory emulation, it would prove particularly challenging for ICS networks for the following reasons concerning the delivery of structured educational scenarios. These are some of the hurdles that our development process had to overcome.

3.2.1. Scenario Creation and Dynamic Reconfiguration

Although ${\mathrm{AE}}^3$GIS provides support for predefined scenarios, an important aspect of the tool is the capability for dynamic scenario definition. In the conventional GNS3 simulation setup, any kind of topology and configuration modification must be made before starting the simulation, making it difficult for the instructor to implement live network traffic, configuration, and/or topology modifications during the simulation. In ${\mathrm{AE}}^3$GIS, the instance interacts with GNS3 to push scripts and apply node configurations. Custom scripts can be uploaded into ${\mathrm{AE}}^3$GIS and later applied to the nodes in the ICS scenario while it is running. This gives the instructor the capability to implement state and configuration modifications of devices during live simulations. Some potential uses of pushing custom scripts include injecting malicious code, modifying firewall rules, removing nodes from the network, and uploading malicious PLC code.

In the interface depicted in Figure 5, the instructors or students can deploy personalized scripts on selected nodes of the topology. During this process, the user selects the target device from the list of active nodes in GNS3 (1). Then, the user needs to define script to be executed on the target nodes (2). The storage location of each script can be specified on the target device to allow for flexibility in defining executable scripts and their dependencies in a user-defined directory structure (3). At this point, the user gets to decide if the script should be executed immediately after being uploaded to the target nodes (4). The system also offers the option of adding instructional notes for the deployment of the scripts and allowing multiple scripts to be deployed sequentially on multiple nodes (5). These scenario definitions will be compiled and saved as JSON objects so that they can be easily distributed among students, ensuring every student has access to the same scenario definition and allowing reproducibility for research purposes.

3.2.2. Inadequate Mechanisms for Modeling Variable Network Conditions

Simulating an environment that accurately represents network conditions would be difficult for most general network simulators. In an industrial setting, the nature of operations that require control performance and the use of timing mechanisms for implementing various security controls make the system prone to network conditions such as latency, jitter, network loss, and low bandwidth. Therefore, simulations that include network timing for attacking, alert delays, and suboptimal system operations are necessary. However, GNS3 does not implement the intentional limits for simulating network performance, but rather it expects an underlying network that provides efficient and low-latency connectivity. This makes it difficult for GNS3 to accurately simulate an important aspect of ICS security.

${\mathrm{AE}}^3$GIS overcomes this by implementing scripts that simulate the network degradation features in virtualized network appliances. These scripts use tools, such as the Linux tc command, the Open vSwitch package, and the VyOS router package, are used to create simulations of the network degradation characteristics for the OT layers based on factors such as network bandwidth, delay, jitter, and losses. This deliberate limitation makes the simulation model far more representative of how an ICS would actually operate, where the presence of communications instabilities are not anomalies but rather design elements that would be expected and mitigated by security engineers.

3.2.3. Generating Background Activity

In the practical world of ICS networks, there are many network activities that are produced as a result of interaction between the user and other processes that are running on IT and OT. The continuous operation of these devices can be used to construct a baseline for normal network traffic. This would help train students to detect anomalies that deviate from the baseline to maintain the security of networks. In traditional GNS3 environments, network traffic only appears as a result of user interaction, so these scenarios lack the functionality that would help students understand the process through which network activity is affected by malicious activities.

For the purposes of simulating background traffic, ${\mathrm{AE}}^3$GIS makes use of scripts that automatically create significant traffic between the various devices. These scripts mimic actual control system processes and their operations. Sensors produce dummy readings, actuators react based on signal thresholds, and HMI units initiate periodic requests. By adding the semantic and state transition information into the network, the system provides students with the dynamic setting wherein they must deal with actual traffic patterns, understand the nature of the background activity, and decode the actual and malicious system state.

Apart from automating operations, ${\mathrm{AE}}^3$GIS also reproduces the realistic interaction of the enterprise side user with the IT component. Scripts are written to replicate activities such user login on workstations, executing administration commands, and accessing update repositories. This aspect of ${\mathrm{AE}}^3$GIS gives the students an understanding of how the IT component of the network works, as well as the process by which the attacker pivots from the IT network to the DMZ and then the OT network.

3.2.4. Limited Support for Multi-Tenant or Classroom-Scale Use

Attempting to scale a simulation within a single infrastructure introduces the risk of interference across users, accidental misconfiguration, and resource competition. GNS3 was not designed as a multi-user platform. It does not provide functionality for session isolation, user namespaces, and access control. All projects use the same resource pool, and the whole network space consists of one flat namespace. This makes it impossible to provide simultaneous access for students and lecturers without the risk of having conflicts in IP addressing, network state, and logging.

${\mathrm{AE}}^3$GIS overcomes this limitation by redesigning the deployment model. Prior to the initiation of the scenario, instructors provide a list of students or groups, and pre-configured virtual ${\mathrm{AE}}^3$GIS instances are automatically deployed through the ${\mathrm{AE}}^3$GIS configuration interface. All ${\mathrm{AE}}^3$GIS instances are created on the QEMU host [24] and are populated automatically with the predefined topology, template, and configuration as assigned by the instructor.

3.2.5. Simulating Physical Devices with Minimal Logic

Level 0 components such as sensors and actuators monitor underlying physical processes and often communicate using analog 4–20 mA loops or serial protocols such as Profibus. On the other hand, GNS3 assumes that every node is an IP-based networking device and provides no native support for analog or serial signaling. Another challenge is mapping individual virtual sensors and actuators to PLC I/O in a way that remains both flexible (easy to change or extend) and scalable (supporting many devices across multiple scenarios).

${\mathrm{AE}}^3$GIS addresses this gap by separating physical behavior from network plumbing and implementing the former directly in the PLC layer. Instead of attempting to emulate raw electrical signals, we model Level 0 devices as simple software processes that drive PLC inputs and outputs. Concretely, ${\mathrm{AE}}^3$GIS uses Python scripts embedded within OpenPLC’s PSM hardware layer to compute the values that sensors and actuators would expose to the control logic. Each script is responsible for updating a small set of variables that are bound to specific PLC I/O addresses, effectively acting as a lightweight “physics engine” for that subset of the process.

The modeled behaviors are intentionally minimal but realistic enough for educational use. For example, sensor values can be generated using sinusoidal functions with added noise to represent periodic measurements, while other devices can use mathematical relationships that approximate effects such as the dependency between torque and slip in a motor. Because these behaviors are defined in Python at the hardware abstraction layer, instructors can easily adjust parameters, add new devices, or couple multiple signals together without changing the underlying network topology. Students can then observe how changes in the virtual process values propagate through the PLC logic and into the wider ICS network. This, in turn, allows them to study how attackers could manipulate physical processes via exploitation and lateral movement in the OT network, and to appreciate how seemingly “dumb” field devices play critical roles in the overall security posture of an ICS.

3.2.6. Unsupported Communication Protocols and Legacy Interfaces

Industrial networks frequently rely on serial communication standards such as RS-232, RS-485, and fieldbus protocols like Modbus RTU or Profibus. These technologies depend on precise electrical signaling, deterministic timing, and shared physical media. By design, GNS3 does not support such interfaces, its nodes expose Ethernet interfaces only and expect IP-based traffic. As a result, GNS3 cannot directly emulate low-level serial bitstreams, polling cycles, or the electrical behaviors that underlie many legacy industrial protocols.

Within ${\mathrm{AE}}^3$GIS, the goal is not to reproduce the physical signaling of these serial protocols, but rather to preserve the logical behavior and operational semantics that matter for cybersecurity education. Instead of attempting to emulate RS-232 or RS-485 at the electrical layer, the platform implements a behaviorally accurate abstraction model. Serial protocols are represented using their TCP-based equivalents (e.g., Modbus/TCP) while retaining the essential master–slave interactions, register structures, and timing assumptions found in their serial counterparts.

In this model, communication still follows the same request–response cycles and device roles that students would observe in a real serial network; what changes is only the transport mechanism. This approach provides a practical balance between realism and feasibility: it enables learners to study the logic, vulnerabilities, and attack patterns of serial protocols—such as register manipulation, unauthorized polling, or replay behavior—without requiring full electrical-layer emulation that GNS3 cannot support.

Thus, ${\mathrm{AE}}^3$GIS does not eliminate the concept of serial communication; rather, it simulates its operational behavior through an IP-friendly abstraction that integrates cleanly with GNS3, preserves the educational value of serial protocol logic, and scales across classroom-wide deployments.

3.2.7. Real-Time Control and Flexibility During Active Labs

A major limitation of traditional GNS3 setups is that once a topology is running, it becomes largely static. Instructors cannot easily modify device behavior, inject traffic, or introduce new events without stopping the project or manually reloading configurations. This makes it difficult to create spontaneous, reactive, or evolving scenarios—such as simulating a system failure, introducing malware, or altering network policies mid-lab.

${\mathrm{AE}}^3$GIS removes these constraints by providing real-time control through its unified web interface. Instead of interacting directly with individual nodes or using low-level tools, instructors simply select the desired actions through the GUI. Behind the scenes, ${\mathrm{AE}}^3$GIS orchestrates the necessary operations using a combination of the GNS3 REST API and scripted Telnet interactions. Instructors can deploy scripts, change configurations, start or stop nodes, and trigger background processes with only a few clicks, without needing to access devices manually.

Each lab begins with a shared base topology, but instructors and students can extend or modify it dynamically through the interface. Nodes can be added or removed, behaviors can be customized, and automated tasks can be scheduled as part of the scenario. Actions may be triggered manually or set to occur automatically at predefined times or conditions. This design creates highly interactive labs where instructors can introduce new challenges on demand, adapt scenarios based on student progress, and simulate evolving real-world conditions—all while the underlying automation infrastructure handles the complexity.

3.2.8. Lack of Built-In Assessment and Feedback Tools

While GNS3 provides robust network emulation capabilities, it lacks built-in assessment tools for tracking student activity or measuring learning progress, as it was not originally designed with educational objectives in mind. Instructors can deploy realistic network simulations, but they have no easy way to see which commands students ran, whether they configured devices correctly, or how they responded to specific events. As a result, grading often relies on manual inspection or screenshots, which becomes tedious and infeasible across large classes.

In ${\mathrm{AE}}^3$GIS, every container and VM is configured to send its system logs to the instructor’s machine. This gives instructors full visibility into what happens inside each student’s environment—commands executed, configurations applied, and network activities recorded in real time. These logs can then be reviewed to verify whether students completed required steps or to trace how they approached a given task. After all telemetry data are obtained from the students, the instructor can evaluate the students by looking through the output of the logs for each student.

3.2.9. Guided Instruction, Telemetry, and AI-Assisted Assessment

The purpose of ${\mathrm{AE}}^3$GIS is to provide students with a framework for performing ICS cybersecurity exercises. At the same time, it gives instructors a view of the students’ activities. This is achieved through three different means.

Scenario-Based Guided Learning

Each scenario in ${\mathrm{AE}}^3$GIS is accompanied by detailed documentation that guides the student through the process of completing the exercise. This documentation is step-by-step in nature and addresses the student from the beginning to the end of the exercise. The documentation explains the objectives of the exercise, the network layout and the different elements in the network, the specific actions the student is to perform (such as creating the environment, exploring the network, launching an attack, defending the network, etc.), and the expected results. The student then proceeds to work on the scenario on their own.

Centralized Telemetry Collection

To allow the instructor to have access to the student’s activities, password-protected containers using syslog-ng are created for each student’s isolated GNS3 project. One container resides on the IT segment, and one resides on the OT segment, as shown in Figure 6. Each node in the containerized network is configured to transmit the full command history and system logs to the collector. This provides the instructor with a centralized view of the student’s activities. Students may preview their logs using the web interface but cannot edit the data, as shown in Figure 7.

AI-Assisted Analysis of Student Activity

To reduce the instructor’s workload when reviewing unfiltered log data related to student activity within a class, ${\mathrm{AE}}^3$GIS introduces an LLM-based analysis tool, as shown in Figure 8. The instructor initiates a request through the dashboard, and the backend system retrieves the student’s log data and sends a request to an LLM endpoint. The results are returned as a summary identifying relevant student activity, security decisions, misconceptions, and areas for further exploration. To interact with an LLM, ${\mathrm{AE}}^3$GIS uses the OpenAI Python Client Library, since it has become a standard interface within the industry. For our early experiments and the initial version of the platform, we relied on the OpenAI API. However, other open-source model-serving solutions, such as vLLM, Ollama, and LM Studio, also offer endpoints compatible with OpenAI’s API. This allows institutions to use a local open-source model, such as LLaMA or Mistral, to run the analysis pipeline entirely within their own infrastructure, which may be preferable for data privacy or cost-related reasons. In its current form, this feature is presented as a proof of concept, and instructors should not rely solely on the results provided by the model to make grading decisions. In addition, instructors should verify all the generated summaries against the original telemetry data provided to the model. Finally, if instructors decide to use a proprietary model provider, they should avoid submitting students’ personally identifiable information to the model.

3.2.10. Limited Support for Programmatic Topology Generation

Traditional GNS3 environments are built around a drag-and-drop interface, which works well for small labs but quickly becomes impractical for complex or large-scale topologies. Building an industrial network with multiple PLCs, HMIs, routers, firewalls, and workstations through the GUI can take time and is difficult to reproduce or share with others. There is no straightforward way to automate this process of creating large topologies, saving different versions this topology, and sharing this topology along with its configurations to others.

${\mathrm{AE}}^3$GIS solves this by introducing its own orchestration API that automates how network scenarios are created and managed. The API reads JSON-based scenario files that describe every part of the environment, including the nodes, links, configurations, and scripts to perform different actions. The ${\mathrm{AE}}^3$GIS API uses the GNS3 REST API, and telnet connections to each node’s terminal to build and configure everything automatically. Each scenario can include pre-defined templates so that instructors can quickly reuse common components like firewalls, monitoring nodes, or industrial controllers without having to build them from scratch.

Through the ${\mathrm{AE}}^3$GIS web interface, instructors and students can create, edit, or extend these scenario files dynamically and deploy them directly into their respective ${\mathrm{AE}}^3$GIS instance. This makes it easy to build consistent, repeatable topologies across multiple student machines, customize them on the fly, and save multiple variations of these topologies based on their needs.

3.3. Relationship of ${AE}^3$GIS with GNS3

${\mathrm{AE}}^3$GIS is not meant to replace GNS3 but is instead developed as an orchestration middleware that uses GNS3. This provides the underlying foundation for network emulation, with functionality for packet forwarding, virtualization, and containerization. ${\mathrm{AE}}^3$GIS communicates with the GNS3 Controller API and with nodes running within GNS3 via Telnet connections. The middleware converts GNS3, which is designed for single-user environments, into a multi-user educational tool via five different mechanisms:

• Programmatic Topology Synthesis: Rather than relying upon static GNS3 project files created manually via the GNS3 GUI, ${\mathrm{AE}}^3$GIS uses ICS scenarios defined as JSON files. The middleware takes in JSON templates created by the instructor and uses a topology synthesis tool to automatically create node definitions, link constraints, and port bindings.
• Automated Instance Provisioning: To implement student isolation, the orchestration logic in ${\mathrm{AE}}^3$GIS automates the creation of GNS3 server instances. In centralized mode, dedicated QEMU VMs are created and then replicated for each student. In distributed mode, students use GNS3, and the templates are distributed and managed by the middleware. This removes the need for students to handle system administration tasks.
• Runtime Control Interface: ${\mathrm{AE}}^3$GIS introduces a runtime control interface, enabling events to be injected into an active network simulation by utilizing external Telnet connections. Such can trigger events of a scenario such as unleashing a Stuxnet logic payload, changing firewall settings, or injecting network faults.
• Telemetry Aggregation Layer: To facilitate assessment, ${\mathrm{AE}}^3$GIS introduces a telemetry layer in which password-protected syslog-ng collector containers are instantiated within each student’s isolated network simulation. These collectors gather logs of command sequences from all active network nodes, thereby establishing a feedback mechanism to monitor student activities. The collected telemetry data streams are further processed by an AI-assisted analysis pipeline to generate summary reports for the instructor, assisting in assessment and grading.
• Centralized Resource and Student Management: GNS3 has no concept of students, submissions, or educational content sharing. ${\mathrm{AE}}^3$GIS includes a resource management system where students submit logs through the web interface, with each submission stored under the corresponding student record. Instructors can view the full list of students, review submissions, request AI-based analysis, and manage or reset student data as needed.

In this architecture, GNS3 acts as the hypervisor engine, while ${\mathrm{AE}}^3$GIS is responsible for scenario definition, user isolation, orchestration, student management, and instructional assessment logic. We have not modified the source code of GNS3 but instead rely on GNS3’s REST API, Docker integration, and project management capabilities as building blocks for a higher-level educational platform.

4. Example Cybersecurity Exercises

In this section, we present two representative scenarios of cybersecurity problems, which were implemented using the ${\mathrm{AE}}^3$GIS platform. These scenarios are intended to illustrate how ${\mathrm{AE}}^3$GIS can support the creation of realistic, hands-on cybersecurity exercises.

4.1. Example Stuxnet Scenario

The Stuxnet worm is a very sophisticated computer worm designed to target ICSs. It was first detected in 2010 and was particularly used to damage the ICSs used to manage uranium enrichment facilities in Iran [25]. Figure 9 shows an overview of Stuxnet’s infection mechanism, which is discussed in detail as follows. In Stage 1, Stuxnet infected air-gapped local area networks (LANs) containing the target PLCs through an infected USB device. In Stage 2, Stuxnet used several zero-day exploits to infect computers running Windows OSs with installed copies of Siemens SIMATIC Step7 versions prior to V5.5 Service Pack 1 (V5.5.1 equivalent), which is a software used to program Siemens PLCs [1]. Stuxnet then used Profibus to query the infected PLCs to determine what devices were connected to the I/O interface of the infected PLC. The infected PLC was connected to Variable Frequency Drives (VFDs) manufactured by Fararo Paya, which were installed in uranium enrichment facilities in Iran, or Vacon, which were installed in Finland. Stuxnet proceeded to Stage 3, where it installed the first known rootkit on the infected PLC to gain complete control over it [1,26]. In Stage 4, Stuxnet disabled normal logic and executed malicious logic to oscillate VFDs between high and low frequencies [26], while supplying benign, pre-recorded data to the HMI to avoid detection. This oscillation degraded the quality of uranium enrichment and caused centrifuges to fail more often, requiring operators to replace them frequently.

Figure 9 shows the four stages of the Stuxnet attack as implemented in the ${\mathrm{AE}}^3$GIS scenario. The first stage introduces a program resembling Stuxnet into the air-gapped network via a malicious script uploaded to the enterprise workstation. The second stage involves lateral movement across the enterprise workstations to locate machines running OpenPLC v3. The third stage deploys malicious logic to the targeted PLC runtimes while recording baseline sensor readings during normal operation. The fourth stage issues commands to the VFDs to oscillate the motor speed outside normal ranges, simultaneously replaying the previously recorded baseline readings to the HMI to conceal the sabotage.

4.1.1. Implementation Details of the Stuxnet Scenario

• Level 0: Field Devices
• Level 0 of the Stuxnet scenario implementation corresponds to the physical modeling of a gas centrifuge controlled by a VFD. Instead of simulating the electrical signals to the motor, the implementation of the ${\mathrm{AE}}^3$GIS scenario utilizes the PSM hardware layer provided by OpenPLC to model the physical response of the rotational speed of the motor to changes in the frequency of the VFD. The implementation of this physical modeling is provided by the function shown in Listing 1. The function takes a target frequency and the current motor speed as parameters and implements a control law to adjust the frequency of the VFD without exceeding the ramp rate. The function then computes the motor speed by converting the frequency to motor speed and accounting for slip. The computed motor speed is then returned to the PLC as an analog input or intercepted by other code if the PLC is infected by Stuxnet.

• Level 1: Programmable Logic Controllers
• Level 1 is made up of PLC logic that directly controls the emulated VFD. In ${\mathrm{AE}}^3$GIS, this is accomplished with OpenPLC running in a container. Under normal operations, the control program will read speed and status information from the motor in Level 0 (via PSM variables), compare this information to a desired setpoint, and make adjustments to the output frequency of the VFD.

In order to replicate the essence of the Stuxnet sabotage, a second malicious routine is incorporated that periodically overrides the normal control behavior. From a conceptual standpoint, the PLC logic cycles through a “normal control” and a “sabotage” phase. During the sabotage phase, the PLC issues dangerous VFD frequency values while still reporting values that appear to be normal to the HMI at Level 2. A simplified representation of this concept is shown in Listing 2. This is not a replica of the original Stuxnet source code but rather an approximation of its time-based sabotage routine.

Listing 1. Simplified VFD–motor interaction model implemented in OpenPLC’s PSM layer.

def vfd_to_motor_rpm(
    vfd_freq_hz,
    current_rpm,
    dt: float = time_delta,
    ramp_rate_hz_per_s: float = 5.0,
    poles: int = 4,
    load_torque: float = 0.5,
    rated_torque: float = 1.0,
    rated_slip_percent: float = 3.0
):
    # Convert current mechanical RPM back to electrical frequency 
    # so we can apply a realistic ramp limit.
    sync_rpm_per_hz = 120.0 / poles
    current_vfd_freq_equiv = current_rpm / sync_rpm_per_hz
     
    # Apply VFD ramp limit (simulate acceleration/deceleration)
    freq_diff = vfd_freq_hz - current_vfd_freq_equiv
    max_delta = ramp_rate_hz_per_s * dt
    if abs(freq_diff) > max_delta:
        max_delta = max_delta * (1 if freq_diff > 0 else -1)
        current_vfd_freq_equiv += max_delta
    else:
        current_vfd_freq_equiv = vfd_freq_hz
            
    # Compute synchronous speed (no slip)
    sync_speed_rpm = current_vfd_freq_equiv * sync_rpm_per_hz
          
    # Simulate slip (drops proportional to torque)
    slip = rated_slip_percent * (load_torque / rated_torque)
    actual_rpm = sync_speed_rpm * (1 - slip / 100.0)
     
    return int(actual_rpm)
        

In ${\mathrm{AE}}^3$GIS, the implementation of the attack and/or changing the sabotage window can be automated via scripts that are executed through the GUI.

• Level 2: Engineering, SCADA, and HMI Systems
• Level 2 consists of the HMI and the EWS. The HMI is implemented using a containerized ScadaBR server that periodically queries OpenPLC for process variables such as motor speed and alarm status. From the HMI’s point of view, it simply shows the values that are provided by the PLC, which are either true measurements or forged data during the sabotage windows described above.

The EWS is modeled via an Ubuntu client that runs tools for uploading and changing PLC logic and Python tools for routine maintenance. In the Stuxnet-inspired attack scenario, “infection” at this level is simulated via a script that adds malicious code to the PLC scan cycle. The educational scenario illustrates the concept of how malware can spread from the EWS to the PLC and how it evades detection without relying on zero-day exploits to infect the PLC.

Through ${\mathrm{AE}}^3$GIS, instructors can:

• Give the student a baseline project where the EWS deploys only benign logic.
• Introduce the student to the modified project or script that silently replaces the PLC program with the sabotage routine shown in Listing 2.
• Ask the student to compare the HMI, PLC program, and logs before and after the change.

This scenario illustrates the capability of high-value targets such as the EWS to become potent tools for manipulating physical systems when compromised.

Listing 2. Illustrative PLC-level sabotage logic used to emulate Stuxnet-inspired behavior at Level 1.

(* Pseudocode / structured-text-style logic: Level 1 sabotage routine *)
               
IF attack_enabled THEN 
    IF within_sabotage_window THEN 
        (* Command unsafe frequencies to the VFD *) 
        IF phase = 1 THEN 
            vfd_freq_setpoint := HIGH_FREQ;     (* e.g., overspeed *) 
        ELSIF phase = 2 THEN 
            vfd_freq_setpoint := LOW_FREQ;      (* e.g., underspeed *) 
        ELSE 
            vfd_freq_setpoint := NORMAL_FREQ;   (* recovery phase *) 
        END_IF;
               
        (* Feed forged values to Level 2 tags *)
        hmi_rpm_display := recorded_baseline_rpm;
        hmi_status      := NORMAL_STATUS;
    ELSE 
        (* Normal control behavior outside sabotage window *) 
        vfd_freq_setpoint := control_loop_output;
        hmi_rpm_display   := measured_rpm;
        hmi_status        := NORMAL_STATUS;
    END_IF; 
ELSE 
    (* Scenario without attack: purely normal control *)
    vfd_freq_setpoint := control_loop_output;
    hmi_rpm_display   := measured_rpm;
    hmi_status        := NORMAL_STATUS;
END_IF;
        

• Level 3 and 3.5: Operations and Patch Management
• While the primary physical ramifications of Stuxnet operate at Levels 0–2, the Purdue model’s higher levels are included to reflect the propagation of the malware toward the control network. The operations level (Level 3) contains several operations-related programs and services, including the Suricata IDS and the MySQL historian service, which collects and stores historical process and network activity information. The DMZ segment (Level 3.5) contains the iptables firewall and the Ubuntu Patch Server, which facilitates shared file service between the enterprise network and the OT network. A scheduled task on the patch server periodically copies the modified PLC project file into the shared directory used by the EWS for periodic updates. This demonstrates the way in which trusted update mechanisms can be exploited to distribute malicious code into secure zones at the lower levels of the Purdue hierarchical model.

In the ${\mathrm{AE}}^3$GIS topology, network traffic passes through segmented networks and firewalls connecting Level 4, the DMZ, and Level 2, with network artifacts for students to understand how the Stuxnet payload traveled from higher-level services to the control network.

• Level 4: Enterprise Workstations
• Level 4 contains Ubuntu workstations and VSFTPD file servers that make up the IT network of the enterprise environment. In the context of the Stuxnet-inspired scenario that we used, this level represents the point of entry of the attack, such as when the user opens the “tool” that stages the malicious project file on the Level 3 patch server. The purpose of the ${\mathrm{AE}}^3$GIS framework is not to replicate the original exploitation path but rather to offer the learner a glimpse of how the initial compromise of the enterprise zone might impact the behavior of the PLC further down the OT zone.

• Level 5: External and Cloud-Based Services
• Level 5 represents the external services that are typically located outside of the ICS environment. This includes the containerized NGINX server that represents a remote update or staging repository and the Samba share that represents a trusted external file distribution service. While these systems are not used in the direct exploitation of the PLC or other devices in the OT zone, they are intended to offer the learner a realistic representation of how digitally signed payloads, configuration updates or malicious software packages originating from outside the OT zone might be used in a supply-chain attack against devices found in Levels 0–3.

This Stuxnet-inspired scenario clearly demonstrates the complete spectrum of the attack by simulating all the relevant levels of the Purdue model. This scenario demonstrates the full path from external cloud services (Level 5) to logic manipulation (Level 1) and, finally, to the physical world (Level 0), while fully utilizing open-source components within ${\mathrm{AE}}^3$GIS.

Table 4. Equipment and Software Components by Purdue Model Level (Stuxnet-Inspired Scenario).

Level	Component Type	Examples/Description
Level 0	Sensors and Actuators	Simulated via Python functions within OpenPLC’s PSM hardware layer as shown in Listing 1.
Level 1	PLCs	OpenPLC executing normal and malicious control logic. Models the PLCs targeted by Stuxnet.
Level 2	SCADA System	ScadaBR with custom mappings and visualizations.
	Engineering Workstation	Ubuntu host running PLC programming tools and scripts; an equivalent of the Step7 workstation Stuxnet compromised.
	Industrial Switch (L2)	Open vSwitch acting as a dedicated PLC/SCADA network switch.
Level 3	Historian	MySQL is used to collect and store historical data like process values or network activity.
	OT Intrusion Detection System	Suricata provides an interface for students to analyze the state of the OT network before and after Stuxnet begins compromising devices.
Level 3.5	ICS DMZ/Security Boundary	iptables firewall and Ubuntu Patch Server separating OT from IT. Models the cross-boundary where Stuxnet crossed via removable media and infected hosts.
Level 4	Enterprise/Business Network	Ubuntu hosts representing corporate systems Stuxnet initially infected. These include Ubuntu workstations and VSFTPD file server.
Level 5	External/Cloud Services	External infrastructure, which include Nginx Web Server and Samba Server used to contextualize how Stuxnet used digitally signed payloads and external command triggers.

summarizes the equipment and software components utilized at each level of the Purdue Model for this Stuxnet-inspired scenario.

4.1.2. Simplifications and Assumptions of the Stuxnet Scenario

In order to maintain simplicity and ease of use, the scenario has abstracted some of the intricacies of the Stuxnet malware, while maintaining the core functionality and educational value of the attack. Instead of implementing the complex and sophisticated features of Stuxnet, such as the stolen digital certificates, zero-day exploits targeting the Windows kernel, or the firmware-level rootkits, the ${\mathrm{AE}}^3$GIS implementation focuses on the high-level functionality mirroring the strategic goals of the original attack.

In this regard, the manipulation of the logic controller is implemented by modifying the OpenPLC Runtime PSM Python script, which simulates the cyclic and stealthy behavior of the Stuxnet malware and sending alternating control commands to destabilize the operation of the centrifuges (e.g., frequency spikes in the simulated VFD registers), while maintaining the illusion of normalcy in the HMI layer. This is accomplished by utilizing additional registers that are only accessible to the OpenPLC Runtime and simulating the “real” frequency setpoint and motor speed as perceived by the OpenPLC controller.

4.1.3. Learning Outcomes of the Stuxnet Scenario

The Stuxnet-inspired scenario allows the learner to have hands-on experience with the behavior of such a sophisticated cyber-physical threat against ICS environments. Students can learn how EWSs, HMIs, and PLCs interact with each other and how they are used to perform operations within the industrial environment, allowing them to develop an understanding of the workflows and data-flows within the industrial environment. Students can interact with OpenPLC, modify logic files and send Modbus/TCP commands to manipulate processes and observe how insecure industrial protocols are used by threat actors to modify process operations without being detected. Students are challenged to consider how the lack of native authentication within industrial protocols impacts process operations and how this can be exploited by threat actors.

This Stuxnet-inspired case promotes interdisciplinary skill acquisition and reinforces essential skills in cybersecurity, network engineering, and automation systems. This helps learners develop proficiency in ICS cybersecurity, threat hunting, and incident response. By creating a detailed and accurate emulation of Stuxnet, the lab not only helps learners demystify this famous cyber weapon but also engages students with the thought processes and limitations that existed during the creation of complex CPSs. This allows learners to acquire a theoretical and practical understanding of the operations and strategies of cyber attackers and defenders.

4.2. Example ARP Spoofing Scenario

Address Resolution Protocol (ARP) spoofing is a common network-layer attack where an attacker sends spoofed ARP messages to link its own Media Access Control (MAC) address with the IP address of a benign host on the same subnet. Because ARP doesn’t maintain any state, any node on the same local network can spoof the identity of another simply by broadcasting unsolicited ARP replies. Once this is successful, the attacker can secretly intercept the traffic between benign nodes in the local network.

In this exercise scenario, we focus only on the IT layer of the Purdue model. We will show how ARP cache poisoning allows an attacker to perform a man-in-the-middle (MITM) attack between a benign workstation node and a web server node. In this lab, students will carry out the attack, observe the outcomes, identify the anomalies, and apply techniques to mitigate against ARP spoofing attacks. The students will be able to perform these activities within the ${\mathrm{AE}}^3$GIS environment using the topology builder and the script injection functionalities. This scenario will be pre-defined by the instructor with all the step by step lab instructions and executable scripts so that students can simply follow along and perform the exercise.

4.2.1. Implementation Details of the ARP Spoofing Scenario

• Network Topology

The network topology for this scenario consists of three nodes in the IT network layer. These nodes will all be connected to a single Open vSwitch node. The three nodes include a web server, which runs an Nginx HTTP service, an Ubuntu client that acts as the benign workstation and another Ubuntu client node that acts as the malicious attacker. An example topology of this scenario is shown in Figure 10.

• Baseline Verification

Before starting the attack exercise, the students will verify the baseline network conditions by sending HTTP requests to the server from the workstation using the curl command. Moreover, they will also check the ARP table entries on the workstation to take a note of the legitimate MAC address of the web server using the (arp -a) command. This will help students identify the discrepancies before and after the attack has been executed.

• Attack Execution

To perform the attack, the students will deploy the script shown in Listing 3 on the malicious client node. This script is used to enable IP forwarding on the attacker so that any packets that are intercepted by the attacker will still be delivered to the intended destination. This is done to avoid any immediate detection by the benign nodes. Then, the script runs arpspoof in both directions, i.e., from the web server to the workstation, and from the workstation to the web server. Once the ARP cache on both the web server and the workstation is compromised, all the traffic between these two nodes will be diverted through the attacker. At this point, students can confirm that network traffic is being intercepted successfully by executing the tcpdump command on the attacker, which should show all HTTP traffic between the workstation and the web server.

Listing 3. ARP spoofing attack script deployed to the Malicious-Client node.

#!/bin/bash
                
# Enable IP forwarding so intercepted packets still reach their intended destination.
echo 1 > /proc/sys/net/ipv4/ip_forward
               
# Impersonate the server (192.168.1.100) to the workstation
arpspoof -i eth0 -t 192.168.1.10 192.168.1.100 &
               
# Impersonate the workstation (192.168.1.10) to the server
arpspoof -i eth0 -t 192.168.1.100 192.168.1.10 &
               
# Capture redirected traffic for inspection
tcpdump -i eth0 -w /tmp/captured_traffic.pcap &
        

• Detection

Students can use two methods to detect this attack from the benign workstation. First, they can inspect the ARP table on the workstation and notice that the MAC address associated with the web server’s IP has changed to a different MAC address that belongs to the attacker. Second, they can capture network traffic on the workstation to observe any unsolicited ARP replies that claim ownership of the web server’s IP address. Now, it should be obvious to students that the workstation’s ARP cache has been compromised and the unsolicited ARP replies are likely originating from the attacker’s MAC address. The detection commands are shown in Listing 4.

Listing 4. Detecting ARP spoofing by inspecting the ARP table and monitoring traffic.

# Inspect the ARP table
arp -a
               
# Monitor ARP traffic for suspicious activity
tcpdump -i eth0 arp
        

• Mitigation

To defend against this attack, students will configure static ARP entries on both the workstation and the web server nodes. Doing this will map the IP addresses of the benign nodes to their respective legitimate MAC addresses. The mitigation commands are shown in Listing 5.

Listing 5. Configuring static ARP entries on the workstation and server.

# On the workstation:
arp -s 192.168.1.100 <server_real_mac>
               
# On the server:
arp -s 192.168.1.10 <workstation_real_mac>
        

Once the static ARP entries have been configured, the students will execute the attack script (Listing 3) on the attacker node and the detection script on the workstation (Listing 4) once again to confirm that the ARP tables no longer change and the attacker no longer intercepts traffic between the workstation and the web server.

4.2.2. Simplifications and Assumptions of the ARP Spoofing Scenario

This scenario is set up in an environment that is typical of a local network topology in the same subnet. In a production enterprise network, there could be many other variables that could affect the success of an ARP spoofing attack. For example, a network can have a managed switch with dynamic ARP inspection, port-based authentication, etc., which can prevent these kinds of attacks from occurring. However, in order to keep things simple and to ensure that students get to understand the basic ARP spoofing technique, we have not taken this into consideration for this particular scenario.

4.2.3. Learning Outcomes of the ARP Spoofing Scenario

This scenario allows students to gain hands-on experience in exploiting a foundational network-layer vulnerability using the ARP spoofing attack. Students get to carry out the full attack life-cycle and develop a practical understanding of how stateless protocols can be abused to intercept traffic in a local network. In addition, students get to learn the basic techniques to detect these kinds of attacks and how to mitigate them.

5. Experiments and Results

This section discusses the experiments performed to evaluate the effectiveness and usability of ${\mathrm{AE}}^3$GIS. The experiments focus on three main aspects: the efficiency of the proposed approach in terms of CPU and memory usage, the scalability of the proposed approach on commodity high-performance hardware, and the quality of service perceived by the students when interacting with the lab environment.

5.1. Baseline Performance Across Deployment Platforms

To evaluate the performance of ${\mathrm{AE}}^3$GIS under different deployment scenarios, automated benchmarking evaluations were conducted across three different platforms: an M4 MacBook Air (10-core, 32 GB RAM), a Microsoft Surface Laptop with an Intel Core Ultra 7 processor (8-core, 32 GB RAM), and an M4 Max Mac Studio (16-core, 128 GB RAM). All the platforms ran the GNS3 VM locally and had different resource allocations: the MacBook Air hosted a VM with 4 vCPUs and 10 GB of RAM allocated, the Surface Laptop hosted a VM with 6 vCPUs and 10 GB of RAM allocated, and the Mac Studio hosted a VM with 8 vCPUs and 30 GB of RAM allocated.

Each experiment conducted on these platforms deployed the IT/OT network topology based on the Purdue model architecture. The OT layer had several PLCs that ran Modbus/TCP services, each serving 10 holding registers. A SCADA server polled all the PLCs at 1-s intervals and sent the aggregate data to a MariaDB historian node in the DMZ layer at 30-s intervals. The IT layer had several enterprise workstations that periodically requested static web pages (2–20 KB each) from the web server at randomized intervals between 5 and 30 s and periodically downloaded sample files (30–100 KB each) from the FTP server at randomized intervals between 60 and 120 s. The IT layer also had a dedicated monitoring workstation that queried the historian database at 30-s intervals. The DMZ layer had a firewall that regulated the traffic between the IT layer, DMZ layer, and OT layer. This architecture ensured that there was continuous traffic in both the IT and OT layers, with data flowing bidirectionally through the DMZ layer.

Three scenarios of increasing complexity were used throughout the evaluation. The Small scenario had 5 PLCs, 10 IT workstations, and 8 infrastructure nodes (1 SCADA server, 1 historian, 1 firewall, 1 web server, 1 FTP server, 1 monitoring workstation, and 2 switches), summing up to 23 nodes in total. The Medium scenario had 8 infrastructure nodes, 20 PLCs and 50 IT workstations, summing up to 78 nodes in total. The Large scenario had 8 infrastructure nodes, 100 PLCs and 200 IT workstations, summing up to 308 nodes in total. The same infrastructure nodes and traffic patterns were used across all scenarios, and only the number of PLCs and workstations varied.

The topology was programmatically created, run, measured, and destroyed using the GNS3 REST API for each test run. This ensured a clean slate between test runs and no lingering state from previous tests. Each scenario was run 20 times independently on each platform.

5.1.1. Boot Time Measurements

The boot time is programmatically measured by the time it takes from the first GNS3 API call until all the nodes in the topology have started and their services are configured. This measures how quickly an instructor or student can begin working with the lab scenario. The results are categorized into two phases: topology construction, which includes node provisioning and link wiring via the GNS3 API, and scenario initialization, which includes Docker container startup, network configuration, and service startup. The results are summarized in

Table 5. Boot time (seconds) across platforms. Each row reports the mean ± std over 20 trials.

Scenario	Platform	Total Boot	Topology Construction	Scenario Initialization
	Surface Laptop	$55.1\pm 1.3$	$6.0\pm 1.1$	$49.1\pm 0.8$
Small	MacBook Air	$32.2\pm 0.9$	$1.2\pm 0.2$	$31.0\pm 0.8$
	Mac Studio (remote)	$33.0\pm 0.5$	$1.0\pm 0.2$	$32.0\pm 0.4$
	Surface Laptop	$161.3\pm 3.5$	$26.1\pm 3.2$	$135.2\pm 2.5$
Medium	MacBook Air	$90.7\pm 2.5$	$8.2\pm 2.0$	$82.5\pm 1.8$
	Mac Studio (remote)	$86.7\pm 1.5$	$5.4\pm 0.8$	$81.3\pm 1.2$
	Surface Laptop	$1003.7\pm 7.5$	$232.1\pm 4.3$	$771.6\pm 5.5$
Large	MacBook Air	$538.9\pm 6.0$	$136.0\pm 3.5$	$402.9\pm 5.0$
	Mac Studio (remote)	$419.2\pm 3.3$	$108.6\pm 2.5$	$310.6\pm 3.0$

.

The results show that scenario initialization, which includes Docker container startup and service configuration, accounts for 75–95% of the overall boot time across all platforms, while the construction of the topology accounts for the remaining percentage. The Surface Laptop consistently has the lowest performance of all the platforms tested: from 1.7× slower than the MacBook Air for the Small scenario to 1.9× slower for the Large scenario. The Apple Silicon platforms perform similarly at the Small scale; however, the Mac Studio outperforms the MacBook Air at the Large scale by 1.3×. This is expected, given the increased VM resource availability for the Mac Studio compared to the MacBook Air. A notable observation is that despite the MacBook Air accessing the Mac Studio remotely via the LAN, the boot times of the Mac Studio are the same as or better than the MacBook Air, which means that network overhead is not meaningfully affecting the topology construction. The scenario compositions and boot-time measurements are summarized in Figure 11.

5.1.2. Network Latency Measurements

For the local deployment mode, where both the GNS3 client and server are on the same host, the API’s network latency is negligible since there is no network between the client and the server. The network latency of interest is for the remote deployment mode, where a student interacts with a remote GNS3 server over a network. For benchmarking network latency under different loads, four operations were measured after starting each scenario: listing all nodes in the topology, retrieving a single node from the topology, stopping and restarting a node, and executing a command through Telnet on a node’s console. The results are given in

Table 6. Remote network latency (milliseconds) between the client and server. Each row reports the mean ± std over 20 trials.

Scenario	Fetch All Nodes	Fetch Single Node	Stop/Start	Telnet Cmd
Small	$40\pm 15$	$20\pm 8$	$6300\pm 60$	$5\pm 3$
Medium	$85\pm 30$	$25\pm 10$	$6400\pm 80$	$8\pm 5$
Large	$200\pm 45$	$30\pm 12$	$6450\pm 90$	$10\pm 8$

.

Retrieving the full list of nodes scales linearly with the size of the topology because the amount of data retrieved increases proportionally, so time increases from 40 ms for the Small scenario to 200 ms for the Large scenario, whereas getting a single node from the topology returns a fixed-size payload and takes a constant time of approximately 20–30 ms regardless of the size of the topology. Moreover, the time to stop and restart a container is around 6.3–6.5 s and is not dependent on the size of the topology. This time is related to the lifecycle operation of a Docker container rather than the network overhead of the GNS3 API call. Notably, executing a Telnet command on a node’s console remains under 10 ms for all three scenarios, indicating that the Telnet connection is responsive even when more than 300 containers are concurrently running on the server.

5.1.3. Data Transfer Measurements

The amount of data transferred between the GNS3 client and the GNS3 server during the topology boot increases linearly in proportion to the number of nodes in the topology, at a rate of around 15–20 KB per node, as shown in

Table 7. Data transferred (Kilobytes) between the client and server during boot and a representative student workflow.

Scenario	Boot Transfer (KB)	Workflow Transfer (KB)
Small	607	244
Medium	1252	462
Large	4509	1623

.

For the Large scenario, the amount of data transfer during the boot phase is around 4.5 MB for the entire process. The data transfer for the representative student workflow of listing all the nodes in the topology, viewing the status of different nodes, and restarting one of the containers in the topology is around 1.6 MB and takes around 6 s. Once the scenario is running and the user has no further interaction with the system, the data transfer between the client and the GNS3 server approaches zero because all the simulated network communications between the IT, DMZ, and OT networks remain within the GNS3 VM. This shows that the system has minimal bandwidth requirements and can be deployed in a remote setting where students access the system through the centralized server over standard network connections. Figure 12 provides a visual summary of the network latency and data transfer characteristics for the three scenarios.

5.1.4. Resource Utilization Measurements

On the lower-spec platforms, the amount of memory allocated to the GNS3 VM was the primary limiting factor for the number of containers that could be deployed in the topology. In practice, each container consumed approximately 25–30 MB of memory when accounting for the application process as well as Docker runtime and networking overhead. The large topology contains around 308 nodes, which requires roughly 7.5–9 GB of memory for all containers to run within the VM. On the MacBook Air, where the VM was allocated 10 GB of memory, total memory utilization reached around 90% for the large scenario, while CPU utilization remained around 40%. Similarly, on the Surface Laptop, which was also allocated 10 GB of memory, memory utilization reached approximately 94%, with CPU utilization around 65%. However, the Mac Studio was allocated 30 GB of memory for the VM and exhibited significantly lower resource utilization, with approximately 32% memory usage and 15% CPU utilization for the large topology. This indicates substantial headroom to support multiple students concurrently, as discussed in Section 5.2.

5.2. Large-Scale Scalability Experiments

To evaluate how ${\mathrm{AE}}^3$GIS performs under multi-student workloads, three deployment scenarios were tested on the M4 Max Mac Studio (16-core CPU, 128 GB RAM). Each scenario involved provisioning multiple concurrent ${\mathrm{AE}}^3$GIS instances, each running an ICS-based network topology, with instance creation and configuration managed automatically through the ${\mathrm{AE}}^3$GIS controller. The objective was to identify the practical scaling limits of the system under realistic educational scenarios as well as under high-density research workloads.

• Scenario 1: Scaled Educational Deployment (Large Classes)

This scenario represents a large introductory course in which each student receives a lightweight ${\mathrm{AE}}^3$GIS instance allocated 2 vCPUs and 2 GB of RAM, running 64 containers per instance. Each container represents a distinct network component such as a PLC, web server, firewall, router, or workstation. At 50 concurrent instances, host CPU reached full utilization and memory usage reached approximately 111 GB. The interface remained functional at this point, but operations such as adding new components or starting and stopping existing ones exhibited noticeable slowdowns.

CPU was the primary bottleneck in this scenario. Extrapolating from the observed saturation at 50 instances, a deployment of approximately 35 instances would maintain CPU utilization below 60%, preserving a responsive interface. For a typical classroom setting, this capacity is more than sufficient.

• Scenario 2: Realistic Educational Deployment (Medium-to-Large Classes)

This scenario models a conventional educational setting in which each student works with a larger ICS project. Each ${\mathrm{AE}}^3$GIS instance was allocated 4 vCPUs and 6 GB of RAM, running 256 containers per instance. A total of 19 instances were deployed before CPU reached full utilization, at which point memory consumption was approximately 107 GB. During the initialization phase—when all instances were booted simultaneously and all containers were created concurrently—CPU saturation was observed, along with GUI delays of approximately one second. During steady-state operation, however, CPU utilization decreased substantially, as each student typically interacts with only a subset of their topology at any given time.

Based on these observations, the system can effectively support a class of at least 20 students under this configuration, with a projected capacity of approximately 25 active students provided that all instances are pre-initialized before the start of the class.

• Scenario 3: High-Density Stress Test (Research Scenarios)

This scenario represents an intentionally heavy configuration designed to identify the upper limits of the system rather than reflect typical classroom usage. Each ${\mathrm{AE}}^3$GIS instance was allocated 4 vCPUs and 12 GB of RAM, running 512 containers. A total of 5 instances were successfully deployed, but the 6th could not be started due to memory exhaustion (approximately 115 GB in use). CPU utilization remained at roughly 60% throughout, confirming that memory was the limiting resource in this configuration. The startup process was lengthy (approximately one hour per instance), but once initialized, the system was stable in its operation.

This configuration is not intended for classroom exercises. It is more appropriate for large-scale research experiments requiring dense containerized environments, or for stress-testing the system’s boundaries.

Table 8. Performance and Scalability Results on M4 Max Mac Studio.

Scenario	VM Spec	VMs	Nodes per VM	System Usage	Limiting Resource
Scaled Educational Deployment	2 vCPU/2 GB	50	64	CPU: 100%; RAM: 111 GB	CPU saturation
Realistic Educational Deployment	4 vCPU/6 GB	19	256	CPU: 100%; RAM: 107 GB	CPU saturation
High-Density Research Stress Test	4 vCPU/12 GB	5	512	CPU: 60%; RAM: 115 GB	Memory saturation

summarizes the performance and scalability results across these three deployment scenarios and Figure 13 illustrates the relationship between the number of VMs and nodes, alongside the corresponding CPU and RAM usage for each scenario.

5.3. Quality of Service

Responsiveness was measured from the point of both instructors and students to get more accurate data on how the system performs under load. When the CPU of the host was under 70% utilization, operations such as the creation, starting, or linking of nodes were executed almost instantly, which means students could work with the environments seamlessly. As the CPU utilization approached 100%, delays in the GUI as well as in API responses appeared, occasionally triggering timeouts in the ${\mathrm{AE}}^3$GIS controller.

At the higher end of this range, node operations such as opening terminals, starting or stopping appliances, issuing configuration commands, etc. still responded within one to two seconds. Such a level of response time is enough for the majority of the educational activities, including network configuration, packet analysis, or intrusion detection experiments. We give explanations for our observations in

Table 9. Quality of Service Levels Used in ${\mathrm{AE}}^3$GIS Evaluation.

QoS Level	Definition
Excellent	Near-instant responsiveness with no noticeable delay in node creation, link configuration, or console access. API queries complete in under 30 ms and console commands return in under 5 ms. Suitable for fully interactive classroom use and fast-paced lab exercises. Observed when host CPU is well below 70% utilization.
Good	Brief delays of less than one second for most actions. API queries complete in under 100 ms, and students can work without meaningful interruptions. Suitable for both local and remote instruction. Observed when CPU and RAM utilization are around 80%.
Moderate	Noticeable but manageable delays of one to two seconds for common operations such as opening terminals and starting appliances. API response times may exceed 100 ms with occasional spikes. Still usable, but rapid iteration and large hands-on labs become impractical. Observed as CPU approaches saturation (around 90% utilization) while RAM remains below 80%.
Poor	Significant lag in node interactions, with API timeouts occurring frequently. The system is only suitable for stress testing or demonstration purposes where students are not actively interacting. Observed when CPU or RAM are at or near full saturation.

which summarizes how the system’s responsiveness changes at various levels of resource utilization. ${\mathrm{AE}}^3$GIS remains quite smooth under standard classroom operations and only noticeably slows down as the system gets closer to full CPU saturation.

5.4. Discussion

The experiments presented in this section demonstrate that ${\mathrm{AE}}^3$GIS can operate large-scale, virtualized ICS environments on a single physical machine while maintaining acceptable responsiveness for educational use. The baseline performance experiments established that the platform’s client-server data footprint is lightweight (under 4 MB for a 250-node topology boot, near-zero during steady-state operation), API queries remain responsive at under 30 ms for local deployments and under 250 ms for remote access, and console interactions complete in single-digit milliseconds regardless of topology size. The multi-instance scalability experiments confirmed that a single Mac Studio can support between 20 and 50 concurrent students depending on the complexity of the assigned scenario, with CPU as the bottleneck for lightweight instances and memory for heavyweight ones.

For practical classroom deployments, maintaining host CPU utilization below 70% and host memory utilization below 90% preserves smooth interaction across all measured dimensions—API responsiveness, console access, and node operations. The Apple Silicon platforms demonstrated measurable advantages over the Intel-based Surface Laptop, booting scenarios approximately 1.6× faster and responding to API queries 2–3× more quickly at the same topology sizes. These performance characteristics, combined with the platform’s minimal bandwidth requirements, make remote deployment over a local network a practical alternative to requiring each student to run GNS3 on their own machine.

6. Limitations

While this approach offers several advantages in terms of accessibility, scalability, and reproducibility, it also introduces limitations related to physical fidelity and real-time behavior. This section outlines the primary limitations of the platform and clarifies the scope for which ${\mathrm{AE}}^3$GIS is intended.

• Physical Process and Hardware Fidelity: ${\mathrm{AE}}^3$GIS focuses more on the virtual representation of industrial environments than the accurate reproduction of physical processes or proprietary hardware behavior. As a result, the platform does not model detailed physical dynamics, sensor behavior, actuator characteristics, or the specific hardware implementations of different vendors. The current version of the platform is scoped around network- and application-layer training scenarios.
• Real-Time Constraints and Determinism: ICSs often operate under strict real-time constraints, particularly in motion control systems and high-speed manufacturing environments. In ${\mathrm{AE}}^3$GIS, PLC logic is executed within containers running on general-purpose OSs, which introduces variability due to scheduling, virtualization overhead, and process contention. Consequently, the platform does not provide hard real-time determinism at microsecond or sub-millisecond resolution. From the perspective of ${\mathrm{AE}}^3$GIS’s educational objectives, this limitation is generally acceptable, as most cybersecurity scenarios focus on protocol misuse, unauthorized command injection and logic modification.
• Protocol and Vendor Support: The platform primarily supports open and widely used industrial communication protocols. Modbus/TCP is used as the baseline protocol across all provided scenarios. Additional protocols, such as DNP3 and S7, are supported by the underlying OpenPLC Runtime but are not pre-configured in the default scenario library. Moreover, ${\mathrm{AE}}^3$GIS does not attempt to emulate the full range of vendor-specific protocol extensions or proprietary management interfaces commonly found in operational industrial environments.

7. Conclusions and Future Work

${\mathrm{AE}}^3$GIS is designed to enable educators to provide ICS cybersecurity education easier and to create more opportunities for students to participate in this growing field. By virtualizing the entire Purdue stack and providing tools for automatization and customization of these labs, it allows instructors to create realistic labs without the requirement of the instructor having to purchase specialized hardware, and allows students to perform cybersecurity exercises on ICS environments without the threat of damaging actual systems.

There is no doubt that the continuous operation of ICS is essential in modern society. The continued push toward IT/OT convergence, combined with malware specifically aimed at ICS such as Stuxnet and Triton, and incidents like the attack on Colonial Pipeline, make clear both the fragility of critical infrastructure and the requirement for more and better cross-disciplinary training in the security of ICS. One promising direction is the utilization of large language models as teaching assistants. When fine-tuned on ICS documentation, protocol specifications, and ${\mathrm{AE}}^3$GIS’s architecture, these models have the potential to provide real-time, context-aware support. Students could ask questions about MODBUS behavior, get suggestions for firewall rules, debug PLC logic, or interpret Suricata alerts. For instructors, LLMs might help in generating various scenarios, finding common mistakes, and reducing the overhead of giving individual feedback for each student.

Beyond intelligent teaching assistants, the platform would also profit from a collaborative scenario repository. A set of modular, well-documented exercises-including scenarios inspired by real incidents such as TRITON, Industroyer, or Colonial Pipeline-would keep course material current and relevant. Over time, ${\mathrm{AE}}^3$GIS could be a common foundation for educators and researchers alike, serving a growing community of educators focused on practical, hands-on ICS cybersecurity education.

A primary area for future work will be the formal evaluation of the effectiveness of ${\mathrm{AE}}^3$GIS in a classroom environment. While this study focuses on the quantitative evaluation of the platform in terms of resource usage, scalability, and ease of deployment on a variety of hardware configurations, it does not include a formal study on educational effectiveness. This gap can be fulfilled by conducting a longitudinal evaluation spanning multiple semesters across undergraduate and graduate courses in ICS cybersecurity. This approach will allow us to capture variations across student populations, course structures, and instructor workflows to iteratively refine the platform based on observed outcomes. Future plans for evaluating the effectiveness of the platform will include: (a) evaluating students’ knowledge of ICS cybersecurity concepts before and after usage of the platform using pre- and post-assessment instruments aligned with established ICS security competency frameworks, (b) conducting a pilot study to evaluate the perceived ease of use from students’ perspective, (c) evaluating time for instructors to setup and evaluate lab exercises in comparison to a traditional manual-based approach, (d) collecting qualitative feedback from instructors on the usefulness of the AI-assisted telemetry analysis and the degree to which they reduce grading workload, and (e) comparing student performance and engagement metrics between cohorts using ${\mathrm{AE}}^3$GIS and those using conventional lab setups.

Another area of future work involves the advancement and validation of the AI-assisted analysis of telemetry data feature. In order to do this, a set of specialized artificial intelligence (AI) agents will need to be created, each responsible for a distinct stage of the analysis pipeline: telemetry collection, log analysis, identification of discrete procedural steps taken by students, and structured assessment of student work. Rather than producing open-ended narrative summaries, the agents will operate on a specific output schema with well-defined fields, enumerated value sets, and explicit field descriptions to prevent the model from improvising the results. Each decision made by the model will come with a confidence score associated with it, which will enable instructors to quickly identify the results that need to be analyzed more carefully. The results provided by the model will include a detailed breakdown of the actions taken by each student, along with direct references to the corresponding telemetry data. In addition to this, the use of AI will be disclosed to students as part of the overall course evaluation policy and they will have access to the AI-generated report used to evaluate their work.