NetSim Cyber Overview¶
NetSim Cyber is a protocol-aware cyber-attack simulation and emulation platform for power-system communication networks. It allows users to model communication paths between power-system devices, insert an attack node into the communication path, and evaluate the effect of cyber-attacks on protocol traffic and power-system measurements.
In a typical NetSim Cyber experiment, a source device sends protocol traffic to a destination device. The source may be a PMU, IED, RTU, PLC, relay, software simulator, or hardware-in-the-loop system. The destination may be a PDC, SCADA master, HMI, subscriber, or monitoring application. NetSim Cyber places a Threat Agent between the source and destination. The Threat Agent intercepts selected traffic streams and applies user-configured attack logic before forwarding the modified traffic.
NetSim Cyber supports experiments using both real devices and built-in protocol simulators. This allows users to begin with a simple same-system setup and then move to more realistic distributed testbeds involving separate physical systems, HIL platforms, or field devices.
NetSim Cyber high-level architecture
Operating Modes¶
NetSim Cyber can be used in different operating modes depending on the test objective, available hardware, and required level of realism. The same attack workflow can be applied in simple simulator-based studies as well as in distributed laboratory testbeds with real devices.
The two primary operating modes are:
Single-system deployment
Distributed deployment
In Host-system deployment, the source simulator, NetSim Cyber, Threat Agent, and destination simulator run on a single computer. This mode is useful for early-stage validation, training, protocol testing, and attack logic development.
In distributed deployment, the source and destination run on separate systems or devices, while NetSim Cyber operates as an intermediate system in the communication path. This mode is useful for realistic cyber-physical testing, hardware-in-the-loop integration, and experiments involving real PMUs, PDCs, IEDs, RTUs, PLCs, SCADA systems, or HIL platforms.
NetSim Cyber can therefore support a progressive testing workflow. Users can first develop and validate the attack in a host-system setup and then repeat the experiment in a distributed setup with real or hardware-based systems.
| Operating Mode | Description | Typical Use Case | Systems Required |
|---|---|---|---|
| Single-system deployment | Source, destination, and NetSim Cyber run on one computer | Early-stage testing, protocol validation, training, attack logic development | One PC |
| NetSim Cyber uses built-in open-source protocol simulators | Quick protocol testing without external devices | ||
| Distributed deployment | Source and destination run on separate systems, with NetSim Cyber placed in the communication path | Real-device testing, HIL integration, laboratory cyber-physical experiments | Two or more systems |
| NetSim Cyber interfaces with real devices or external simulators | Realistic testing with PMUs, PDCs, IEDs, RTUs, PLCs, SCADA, Typhoon HIL, OPAL-RT, or RTDS | Multiple systems/devices |
NetSim Cyber operating modes
Single-System Deployment¶
Single-system deployment is the simplest way to use NetSim Cyber. In this mode, all major experiment components run on a single computer. The source simulator generates traffic, the destination simulator receives traffic, and NetSim Cyber applies the selected attack through the Threat Agent.
This mode is useful when the user wants to validate protocol behavior, test an attack configuration, generate datasets, or demonstrate cyber-attack effects without setting up multiple machines or physical devices.
A host-system setup may include:
A built-in PMU simulator sending IEEE C37.118 synchrophasor data.
A built-in or external PDC subscriber receiving synchrophasor data.
A Modbus master and slave simulator.
A DNP3 master and outstation simulator.
IEC 61850 GOOSE publisher and subscriber tools.
A NetSim Cyber Threat Agent configured between the source and destination traffic flow.
The main advantage of same-system deployment is reduced setup complexity. Users can quickly create and test attack scenarios without configuring external routing, multiple network interfaces, or physical communication links. This is especially useful during training, demonstration, and initial attack development.
However, single-system deployment may not capture all timing, routing, device behavior, and network-interface characteristics of a real laboratory testbed. Therefore, once the attack logic is validated, users may repeat the experiment in distributed deployment for higher realism.
Single-system deployment
Multiple-System Deployment¶
Multiple-System deployment is used when the source and destination are located on separate systems or physical devices. In this mode, NetSim Cyber is placed between the communicating endpoints and acts as an intermediate network system. Traffic from the source is routed through NetSim Cyber before reaching the destination.
This mode is suitable for realistic cyber-physical experiments involving actual power-system devices, hardware-in-the-loop simulators, or operational technology testbeds. For example, a PMU simulator running on one system may send IEEE C37.118 data to an openPDC instance running on another system, while NetSim Cyber runs on a third system and modifies the traffic in transit.
A multiple-system setup may include:
System 1: Source device or simulator: Example: PMU, IED, RTU, PLC, Typhoon HIL, RTDS, OPAL-RT, or protocol simulator.
System 2: NetSim Cyber system: Runs the NetSim Cyber GUI, network scenario, and Threat Agent.
System 3: Destination device or application: Example: PDC, SCADA master, HMI, GOOSE subscriber, DNP3 master, or IEC-104 master station.
In Multiple-system deployment, correct network configuration is essential. The source and destination traffic must pass through the NetSim Cyber system. This can be achieved through static routing, automatic configuration using NetSimCyberClient.exe, or a two-NIC gateway setup where the NetSim Cyber PC routes traffic between two separate networks.
Multiple-System deployment provides a more realistic test environment because it includes real network interfaces, actual device communication, system-level timing, and external application behaviour. It is recommended for validation studies, HIL testing, device interoperability testing, and cyber-resilience evaluation.
Multiple-System Deployment
| System | Role | Example Component | Function |
|---|---|---|---|
| System 1 | Source | PMU simulator, IED, RTU, PLC, Typhoon HIL, RTDS | Generates power-system protocol traffic |
| System 2 | NetSim Cyber | NetSim Cyber PC with Threat Agent | Intercepts, modifies, delays, replays, or forwards traffic |
| System 3 | Destination | PDC, SCADA master, HMI, subscriber, control application | Receives and processes protocol traffic |
Example distributed deployment components
Threat Agent Concept¶
The Threat Agent is the logical attack node in NetSim Cyber. It represents an adversarial or test-controlled entity placed in the communication path between a source and a destination. The Threat Agent intercepts selected packets, applies attack logic, and forwards the resulting traffic.
The Threat Agent does not simply drop or corrupt packets randomly. It can perform protocol-aware manipulation based on the selected protocol and attack type. For example, in a Synchrophasor experiment, the Threat Agent may modify voltage magnitude, current magnitude, frequency, ROCOF, or timestamp fields while keeping the frame valid. In a Modbus TCP experiment, it may alter register values. In a GOOSE experiment, it may replay or manipulate event-related fields.
The Threat Agent is configured using the NetSim Cyber GUI. The user selects the source node, destination node, protocol port, attack protocol, and attack type. Once the simulation starts, the Threat Agent monitors matching traffic streams and applies the selected modification logic.
The Threat Agent can be used to emulate attacks such as:
False data injection
Replay attacks
Delay attacks
Packet drops
Random noise injection
Ramp attacks
Increment and decrement attacks
Pulse or surge attacks
Frequency and ROCOF manipulation
Timestamp manipulation
Protocol-specific payload modification
User-defined custom payload modification
The Threat Agent is useful for studying how cyber-attacks affect monitoring, control, protection, and situational-awareness applications in power-system networks.
Threat Agent packet-processing workflow
| Function | Description |
|---|---|
| Traffic filtering | Selects packets based on source, destination, protocol, and port |
| Packet interception | Captures matching packets flowing between endpoints |
| Protocol parsing | Identifies protocol fields that can be modified |
| Payload modification | Applies selected attack logic to measurement or control data |
| Timing manipulation | Introduces delay, replay, or time-related modifications |
| Frame forwarding | Sends the modified or unmodified packet to the destination |
| Custom attack support | Allows user-defined payload modification through scripts |
Threat Agent functions
Protocol-Aware Attack Emulation¶
Protocol-aware attack emulation is one of the main capabilities of NetSim Cyber. Instead of treating packets as generic byte streams, NetSim Cyber understands the structure of supported power-system protocols and allows attacks to be applied to meaningful protocol fields.
This is important because many attacks on power-system communication networks do not need to break communication. A more realistic attack may keep the protocol session active while changing selected values inside valid frames. From the receiver’s point of view, the communication may appear normal, but the measurement or control information may be incorrect.
For example:
In IEEE C37.118 traffic, the attack may modify phasor magnitude, phase angle, frequency, ROCOF, or timestamp information.
In Modbus TCP traffic, the attack may modify coil status, register values, or response data.
In DNP3 traffic, the attack may alter object values, status indications, or measurement data.
In IEC 61850 GOOSE traffic, the attack may replay messages or manipulate status/event-related fields.
In IEC 60870-5-104 traffic, the attack may modify telemetry or telecontrol information.
Protocol-aware emulation allows NetSim Cyber to create realistic attack scenarios while preserving the communication format expected by the receiving application. This helps users evaluate whether monitoring systems, control logic, protection applications, or detection algorithms can identify abnormal data even when the communication session remains active.
This capability is useful for:
Studying false data injection attacks.
Evaluating anomaly detection and intrusion detection methods.
Testing device and application response to abnormal protocol values.
Generating labelled datasets for AI/ML-based cybersecurity research.
Understanding the cyber-physical impact of communication attacks.
Validating protocol implementation robustness.
| Protocol | Example Target Field | Example Attack | Possible Power-System Impact |
|---|---|---|---|
| IEEE C37.118 Synchrophasor | Voltage, current, frequency, ROCOF, timestamp | False data injection, ramp, noise, time-shift | Incorrect wide-area monitoring, false event interpretation, state-estimation errors |
| Modbus TCP | Holding registers, coils, input registers | Register value modification, replay | Incorrect SCADA/HMI display or control logic response |
| DNP3 | Analog inputs, binary inputs, counters | Measurement manipulation, replay | Incorrect outstation data at SCADA master |
| IEC 61850 GOOSE / R-GOOSE | Status, event, sequence-related fields | Replay, spoofing, event manipulation | False protection or automation event indication |
| IEC 60870-5-104 | Telemetry and telecontrol information | Data manipulation, replay, delay | Incorrect control-center visibility or command interpretation |
| Custom TCP/IP protocol | User-defined payload fields | Custom payload modification | Protocol-specific cyber-physical effect |