Most cyber ranges teach IT incident response against IT systems. Very few represent a building: BACnet traffic, a Niagara station, cameras, access control, and the awkward reality that the “compromised device” might be controlling air handling in an occupied hospital. Defenders trained only on corporate networks meet OT for the first time during a real incident.
Status: product concept, in active development. This is something we are building, not something you can buy today. We publish our roadmap because the engineering thinking behind it is the useful part — and because we would rather show you the design than imply a finished product.
Designed Capabilities
- Virtual BAS and OT network — a building that behaves like a building.
- Niagara, BACnet and Modbus emulation — the protocols actually in scope.
- Camera and access-control systems — the parts of the estate everyone forgets.
- Attack and misconfiguration scenarios — rogue devices, unsafe commands, drifted config.
- Packet capture and log telemetry — realistic evidence to investigate.
- SOC investigation workbench — work the incident with proper tooling.
- Instructor campaign builder — multi-stage exercises rather than one-off puzzles.
- Evidence-based after-action reporting — what was found, missed, and how fast.
Where Three Practices Meet
This is the clearest example of the group working as one: SoftwarePile supplies authentic building-system behaviour, BulletproofSoft the attack scenarios and forensic realism, SoftwareSplash the simulation and training engine. Very few organisations can assemble all three, which is precisely why OT defenders are under-trained.
Tell us if this matches a problem you have — early input shapes what we build first, and we will give you an honest view of where it stands.
Related services
- Simulation and Training Software Development — Scenario-based training we deliver today: simulation and training software development.
Why IT Incident Response Does Not Transfer Cleanly
The instincts that make a strong IT responder can be actively wrong in a building. Isolating a suspect host is standard practice on a corporate network. Isolating a controller that is sequencing air handling in an occupied space is a decision with physical consequences, and it is rarely a decision the responder should be making alone.
The priority order inverts too. IT response is ordered around confidentiality first. Operational technology doctrine puts safety and availability ahead of it, and a responder trained only on the IT ordering will reach for containment actions that a facilities manager will refuse. Rehearsing that argument, with the facilities side in the room, is a large part of why a range like this would be worth building.
Status, Stated Plainly
This is a product in development. It is not available to buy, license, pilot, or schedule today. Everything on this page describes design intent for something still being engineered.
We publish it because the design questions are the interesting part, and because feedback from people who defend real building networks changes what gets built first. Nothing here should be read as a commitment to a feature set or a date.
Who This Is Designed For, and Who Should Skip It
The design assumes an organization with a real operational technology footprint, a campus, a hospital, a manufacturing site, or a multi-site portfolio, and a security function that would actually be expected to respond to an incident in it. Integrators and service providers whose technicians touch these systems are the other obvious audience.
Several situations argue against it, and they are worth checking before anyone builds a business case.
- Your operational technology is a handful of controllers on an isolated network with no remote access. An asset inventory and a segmentation review will do more.
- There is no one who would respond. A range trains responders; it does not create the function.
- The immediate gap is policy and authority. A facilitated tabletop with facilities, IT, and security in one room will surface more, sooner.
- Your team has never worked an IT incident either. Build the general capability first.
The Design Problem We Care Most About
Telling a fault from an attack. A stuck damper, a failing sensor, a bad integration, and a malicious write can present almost identically on an alarm console. Real work starts inside that ambiguity, and an exercise labeled an attack before it begins has skipped the part that is hard.
So scenarios are being designed to include benign faults with no adversary present at all, and to score the decision to escalate with the same care as the decision to act. A responder who declares an incident on every failed sensor creates a different and equally real problem, and a range that only ever contains attacks trains exactly that behavior.
A Range Does Not Replace the Fundamentals
If a building network has flat segmentation, unmanaged vendor remote access, no asset inventory, and default credentials on controllers, exercise time is not the binding constraint. Those are the fixes that change outcomes, and a range is for a team that already has a defensible environment and needs practice defending it.
The scenario based training we deliver today, built around your own systems and procedures, is described on Simulation and Training Software Development. The other concepts on the roadmap sit under Solutions in Development, with the same status.
What Would Have to Be True Before This Ships
Three problems sit between the design and a usable product. Modeling building systems faithfully enough that a fault behaves the way a technician expects, without modeling an entire plant. Scoring a judgment call, which is much harder than scoring a completed step. And building instructor controls that let one person run a room without scripting every branch in advance.
We would rather describe those openly than publish a feature list. Anyone evaluating a range, ours or anyone else’s, should ask how each of the three is handled, because the answers separate a training environment from a demonstration.
Frequently Asked Questions
What is this, and what is it not?
The confusion worth clearing up is the second half. It is not an assessment of your estate, not a penetration test of your building, and not a monitoring or detection product that would sit on your network and watch traffic. It produces no findings about your systems; the output is a record of how people performed against a scenario, which makes it a training instrument and nothing else. Treat any result it generates as evidence about the team, not evidence about the environment. It is also not something that can be bought, licensed, or deployed today.
What does it connect to, and does it need access to our building systems?
The design goal is no connection to a live building at all. The emulated estate is generated inside the range rather than mirrored from a production system, so there is no gateway, no read-only tap, and no vendor remote access path into your controls network. Where a customer wants an environment that resembles their own site, the intent is to accept exported artifacts, a sanitized device inventory or point list, rather than credentials or a network path. Device counts, protocol mix, and naming conventions are enough to shape an environment. The actual controllers do not need to be reachable, and connecting the range to them is not a design being pursued.
What has to already exist on our side?
Beyond the environment fundamentals described above, one organizational prerequisite is easy to overlook: a named person who can authorize a containment action with physical consequences, identified by title rather than by committee. Exercises are designed to force that call, and if nobody holds it, a scenario stalls on an escalation with nowhere to go. The related choice is whether your facilities or controls counterpart takes part as a player, able to approve or refuse an action in the moment, or as an observer watching the security team work. Those are two different exercises, and it is a customer decision rather than a setting in the tool.
How is a rollout designed to proceed?
In this order. Scope the estate profile first, meaning which protocols, device classes, and integration points are in scope, since that determines what has to be emulated at all. Build and validate the environment second, with a technician from the customer side confirming that a modeled fault presents the way the real equipment would, because a fault that behaves wrongly teaches the wrong instinct. Rehearse the instructor third, running the campaign builder against the built environment before any trainee sees it, because an instructor who has not rehearsed it cannot adapt an exercise once it goes off script. Run the exercise fourth, and hold the after-action review while the packet captures and logs are still in front of people rather than summarized for them afterward.
How is it designed to work with the tooling we already run?
Two integration paths are designed in. The first is working an exercise in your own tooling instead of the bundled workbench: the range is meant to generate real packet captures and log records rather than pictures of them, so a pcap opens in Wireshark or Zeek unchanged and syslog output follows RFC 5424 so an existing collector or SIEM can ingest it the way it would ingest a real sensor. No scenario should depend on the trainee using our analysis tools, because the muscle memory worth building is on the console the team will actually have during an incident. The second path is on the reporting side, where after-action results are designed to leave as structured records, including xAPI statements to a learning record store, so completion and scoring can live in whatever training system already holds that data instead of only inside the range.
Does the environment cover cameras and access control, or only the controls side?
On the video side, ONVIF devices announce themselves over WS-Discovery on UDP 3702 and expose configuration through SOAP services, which makes both device enumeration and unauthorized configuration change realistic to practice against. Recorder networks reachable from the building automation network are a common design outcome, so scenarios are built to include that path. On access control, the gap between Wiegand and OSDP is the point: Wiegand carries card data unauthenticated and unencrypted from reader to controller, so a device spliced in at the reader can capture and replay credentials, while OSDP with Secure Channel authenticates and encrypts that link. An estate part way through that migration has both behaviors present at once, and the intent is for the emulated environment to represent that mixed condition rather than an idealized one.
Who sees the results, and what happens to what the range records?
The design treats exercise output as customer data. What gets recorded is decisions and timing: who acted, what they queried, when they escalated, what they missed. The decision worth settling before a first exercise is visibility. Per-person scoring is employment-sensitive information, and who may see an individual's decisions, as opposed to team results, is a policy question for whoever owns that in your organization rather than something to inherit from a default. The design intent is that scoring granularity and retention of exercise recordings are both configurable, and that an organization can choose to keep team-level results only.