Appearance
Threat Exercises
Threat Exercises let operators verify that specific detections fire correctly on specific sensors before relying on them for incident response or compliance evidence.
Requires: Telecom sensor flavor and
telecomConsole vertical.operatorrole to create exercises.
This is not automated attack simulation. The Console registers what to watch for; the operator performs the test action (or coordinates with a team member to do so); the Console confirms whether the detection fired within the timeout window.
How exercises work
- In the Console, go to Telco > Threat Exercises, then select New Exercise. Specify the target sensor, exercise type, expected alert kind, and an optional timeout.
- The exercise enters
waitingstatus and the Console begins monitoring the target sensor for the specified alert kind from the moment of creation. - Trigger the test condition on the target node or network.
- Return to the Threat Exercises list in the Console and open the exercise to check its status. The background monitor loop also resolves exercises automatically every 30 seconds.
- If the expected alert kind fires on the target sensor before the timeout: status becomes
pass, withdetected_alert_id,detected_at, anddetection_latency_msrecorded. - If the timeout expires before detection: status becomes
timeout.
Exercises require the operator role to create. Any authenticated user can read exercise results.
Timeout
The timeout_secs field controls how long the Console waits before marking the exercise as timed out. The default is 60 seconds. The minimum is 10 seconds and the maximum is 300 seconds.
timeout_secs = timeout_secs.clamp(10, 300) // default: 60The background monitor loop runs every 30 seconds and updates timed-out exercises without requiring a poll. If you poll before the loop runs and the timeout has passed, the GET handler also checks and updates the status at read time.
Exercise types
The Telovix Console accepts exactly these exercise_type values:
| Exercise type | Test scenario |
|---|---|
unexpected_grpc_call | A gRPC call is made from an unexpected caller process |
unexpected_spawn | An unexpected child process is spawned from a monitored NF binary |
unauthorized_connection | A network connection is made to an unauthorized destination |
oran_e2_peer_spoof | A non-RAN process connects on the E2 interface or to an unknown RIC |
oran_kpm_injection | KPM data is accessed by an unauthorized caller |
oran_f1e1_boundary | A process outside the CU/DU role set uses the F1 or E1 interface |
oran_o1_unauthorized_peer | A NETCONF connection arrives from an unauthorized peer |
oran_o2_destructive_operation | A non-SMO process performs a container lifecycle operation via O2 |
oran_a1_policy_injection | An A1 policy call is made by an unauthorized caller |
oran_route_modification | A route modification is requested by an unexpected process |
The exercise_type field is stored for reference only; it does not change how the Console matches the result. Matching is done by expected_alert_kind against the console_fired_alerts table for the specified sensor and the time window from exercise creation to expiry.
Recommended exercise to WG11 control mapping
| Exercise type | Expected alert kind | WG11 control validated |
|---|---|---|
oran_o1_unauthorized_peer | k2_o1_public_management_peer or k2_o1_new_peer | ORAN_O1 |
oran_o2_destructive_operation | k3_o2_destructive_operation | ORAN_O2 |
oran_e2_peer_spoof | oran_e2_wrong_process or NewRicPeer | ORAN_E2 |
oran_a1_policy_injection | oran_api_a1_policy | ORAN_XAPP |
oran_kpm_injection | oran_api_kpm_caller_violation | ORAN_XAPP |
oran_route_modification | oran_api_route_modification | ORAN_XAPP |
oran_f1e1_boundary | oran_api_f1e1_boundary | ORAN_CUDU |
unexpected_spawn | anomalous_behavior or a custom detection kind | Role baseline |
unauthorized_connection | network_connect or anomalous_behavior | Peer baseline |
Exercise fields
When creating an exercise, the Console form requires the following fields. Requires the operator role.
| Field | Required | Description |
|---|---|---|
name | Yes | Human-readable label for this exercise (max 128 characters) |
target_sensor_id | Yes | Sensor ID to watch for the alert |
exercise_type | Yes | One of the exercise types listed above |
expected_alert_kind | Yes | Alert kind string to match in console_fired_alerts |
expected_chain | No | Optional attack chain pattern to also match |
timeout_secs | No | Seconds to wait before timeout (default 60, range 10-300) |
Once created, the exercise is immediately visible in the Threat Exercises list with waiting status. Opening the exercise record shows its current status and, when it passes, the matched alert details:
| Field | Meaning |
|---|---|
status | pass, timeout, or waiting |
detected_alert_id | ID of the alert that matched (if pass) |
detected_at | Timestamp when the alert fired (if pass) |
detection_latency_ms | Milliseconds from exercise creation to detection (if pass) |
notes | Set to a timeout message if the exercise timed out |
📸 Screenshot: Threat Exercises list The exercise list showing exercise name, target sensor, exercise type, status badge, and detection latency for completed exercises.
Exercise workflow example
The following example validates the ORAN_O1 O1 management interface control on an O-DU sensor.
Step 1: In the Console, go to Telco > Threat Exercises and select New Exercise. Set the name to "O1 unauthorized peer - O-DU site A", select the target sensor (the O-DU node), set the exercise type to oran_o1_unauthorized_peer, set the expected alert kind to k2_o1_new_peer, and set the timeout to 120 seconds. Save the exercise and note the exercise ID shown in the detail view.
Step 2: From a test machine, initiate a NETCONF connection to the O-DU on port 830 using credentials not in the established peer baseline. This is the test condition.
Step 3: Return to the Threat Exercises list in the Console and open the exercise record. A pass status with a detected_alert_id confirms the detection fired. Record the detected_alert_id as evidence for the ORAN_O1 compliance control.
Step 4: Link the detected_alert_id to your WG11 compliance record or evidence bundle.
Using the optional expected_chain field
For exercises that should trigger an attack chain in addition to a single alert kind, set expected_chain to the chain pattern name. The Console records the expected_chain field but matching is still primarily by expected_alert_kind against the fired alerts table. Use this field to annotate which chain scenario the exercise is designed to validate.
Operational guidance
Test in controlled windows: Exercises that trigger management-plane anomalies (O1, O2) or E2 interface spoofing on production nodes should be coordinated with the node owner and run during a maintenance window. The test conditions mimic real attack behaviors and will fire real alerts that may page on-call staff if notification rules are configured.
Treat partial detection as failure: An exercise that fires on the wrong node, with the wrong ownership context, or with the wrong alert kind is not evidence of working detection. If the exercise produces a timeout result, investigate whether the sensor's NF role is correctly assigned, whether the baseline learning window has completed, and whether the relevant WG11 control is in an active evaluation state.
Detection latency: The detection_latency_ms field in a passing exercise represents the time from exercise creation to alert firing. This is the end-to-end detection latency for the scenario. On a healthy sensor with a 15-second heartbeat cycle, a detection that triggers at process level should produce a latency under 30 seconds for most alert kinds. Protocol-level detections (O1, O2, E2) depend on the AF_PACKET capture path and typically resolve within one heartbeat interval.
Evidence bundles: After completing a set of exercises, in the Console go to Compliance > O-RAN WG11 and use Generate Evidence Bundle, selecting the oran_wg11 framework. The bundle includes exercise records alongside alert and event evidence, making it usable for O-RAN Alliance certification packages and internal security review records.