Higher Education & Research
A cyber range that a person can actually run on a Tuesday
Building an isolated hundred-machine training environment is a project. Running one every week, for cohorts and for a multi-institution competition, is a system. We built the second thing.
Verified engagement. Every claim on this page traces to a document, a publication or a system somebody can open, and we can arrange a direct reference call for a shortlisted engagement. The work was done by the engineers who founded this firm, in most cases before the firm existed, which is why the dates below predate it. Client names and identifying details are withheld under NDA unless the client has agreed to be named.
- Client
- A university cybersecurity center and its federal program sponsor
- Duration
- Built over two years, still operating
- Team
- 3–4 engineers plus program staff
- Year
- 2023–2025
The situation
What we walked into.
The center had capable instructors, a real hardware budget and a range that nobody used, for the ordinary reason: standing up a scenario took two days of manual virtual-machine work, so it only happened when someone was willing to lose two days.
The requirements pulled in opposite directions. Students needed genuine administrative control inside their environments, which is exactly the capability you would otherwise spend a security budget preventing. Every team’s environment had to be identical at the start and completely isolated from every other team’s throughout.
The competition side was harder still. Running a timed event across multiple institutions means per-team challenge instancing, a scoring model that resists both cheating and accidental unsolvability, and infrastructure that will not need an engineer during the event, because during the event there is no engineer available.
And underneath the technical problem was an administrative one. Cohorts, placements, completion evidence and sponsor reporting were tracked in spreadsheets maintained by whoever had least time, which is how funded programs quietly die.
Approach
How it was sequenced.
Each step had to be independently valuable. That constraint is what let the client stop at any point without being stranded.
- Step 01
Make provisioning a template, not a task
Topologies became versioned definitions: machines, networks, firewall policy and seeded state, applied by automation. Standing up a scenario went from a two-day manual build to a scheduled job, which is the change that made everything after it possible.
- Step 02
Isolation as the default posture
Per-team segmentation enforced at the firewall with an explicit egress policy, so a student with full administrative rights inside their environment still cannot reach another team’s, the campus network or the internet except where the scenario intends it.
- Step 03
Build the competition platform for the day it runs
Per-team challenge instancing, dynamic scoring, anti-cheat and a health-check surface, plus the deliberately dull discipline of rehearsing the whole event twice on the real infrastructure before opening it. Challenges spanned forensics, reverse engineering and cryptography, written and peer-reviewed by the people who would grade them.
- Step 04
Then fix the paperwork
A cohort and program tracking application replaced the spreadsheets: enrolment, progress, completion evidence and the sponsor reports that had previously been assembled by hand each cycle. It outlived the team that built it, which is the outcome we were aiming for.
What was built
The parts that mattered.
- Templated topologies with automated provisioning, snapshot and reset
- Per-team network isolation enforced at the firewall, not by convention
- Competition platform with per-team instancing, dynamic scoring and anti-cheat
- Beginner and advanced challenge tracks, peer-reviewed before every event
- Cohort and program tracking with sponsor-ready completion reporting
- Instructor runbooks, so events run without the engineers who built the platform
Results
Measured, with the method stated.
Every figure below has a defined measurement window and a comparable baseline. Numbers without those are just adjectives.
- Scenario stand-up
- 2 daysscheduledScenario stand-up
- Concurrent isolated machines
- 100+Concurrent isolated machines
- Cross-team isolation failures
- 0Cross-team isolation failures
- Platform and program
- Handed overPlatform and program
“The measure of the thing is that we stopped calling the people who built it.”
Built with
More work
Related engagements.
- 2024About four weeks
The scanner read every barcode except theirs
They had no way to say who was holding what, and a barcode scanner that would not decode their own label format — the capability was licensed separately and they had declined to buy it. Writing the decoder in C cost less than the licence and made the rest of the system possible.
Read the case study- Trackable, in and out, by holder
- Every item
- Bought to read their own labels
- No licence
- 2023–202520 months, four phases
One codebase for the public site and the platform behind it
A public-facing site and an internal student-tracking platform, built years apart on stacks nobody still owned. We consolidated them into one application with one design system and one authorization model, and shipped it without a production regression.
Read the case study- Production regressions across the release window
- 0
- Unit and integration tests at handover
- 600+
Next step
Tell us what’s breaking.
Forty-five minutes, no charge, no deck. We’ll tell you what we’d do, what it would likely cost, and whether you should be building this at all.