A first look at Cyber Aware, the working title for a Red Team / Blue Team educational game currently in development at Wolf Interactive
For a while now, I’ve been thinking about how cyber security is taught.
We can explain phishing. We can demonstrate logs. We can talk about authentication, compromised accounts, suspicious activity and incident response. We can give learners scenarios and ask them what they think should happen next.
But there is a big difference between being told that a decision has consequences and actually having to make that decision while other things are happening around you.
That thought eventually turned into a game project.
Its current working title is Cyber Aware.
The idea is to create a single-player educational cyber security game where learners don’t simply answer questions about an incident.
They experience one.
Cyber Aware is currently being developed as a Python/PySide6 desktop prototype, with Red Team and Blue Team experiences built around the same underlying cyber incidents.
A game first, not a worksheet wearing a costume
One of the earliest design rules for the project was that it needed to actually feel like a game.
I didn’t want to build something where a fictional company gets “hacked”, a paragraph appears describing what happened, and the learner is presented with:
What should you do?
A) Reset the password B) Investigate the endpoint C) Ignore it D) Panic dramatically
That can test knowledge, but it doesn’t necessarily recreate the reasoning involved in dealing with an incident.
Instead, I wanted the player to be given incomplete information and the tools required to investigate it.
The player needs to decide what matters.
And sometimes they will be wrong.
That’s important.
Making the wrong decision and then seeing the consequences can be considerably more memorable than being told that Option B was worth one mark.
Welcome to Aurelius Dynamics
The first scenario currently being developed is Corporate Espionage.
It takes place inside a fictional Australian technology and engineering company called Aurelius Dynamics.
For the Blue Team experience, the player effectively becomes part of the company’s IT/security operation.
Instead of displaying traditional game choices, the prototype presents the player with a simulated Aurelius corporate workstation.
The Blue Team player’s main gameplay environment is a simulated Aurelius Dynamics corporate workstation.
The workstation currently contains applications including:
Sentinel Security Console
Log Viewer
Endpoint Manager
Corporate Directory
User Management
Service Desk
Evidence Locker
Incident Manager
These aren’t intended to perfectly reproduce particular commercial security products.
They are fictional tools designed around recognizable concepts and workflows.
The important part is what the player does with them.
An alert appearing in Sentinel doesn’t necessarily tell you exactly what happened.
You might need to identify the user involved.
You might search authentication records.
You might inspect their workstation.
Another piece of evidence might appear completely unrelated until you connect it with something you found earlier.
Eventually, you have to decide whether there is actually an incident and what you’re going to do about it.
Sentinel provides information, not the solution. The learner still needs to determine what the alert means and whether further investigation is justified.
The company doesn’t stop because you’re investigating an incident
This became one of my favourite parts of the design.
Aurelius Dynamics isn’t supposed to feel like an empty network waiting for the player to save it.
It’s a company.
People are working.
Someone can’t access their account.
Someone has an email problem.
A workstation isn’t behaving properly.
A Service Desk ticket arrives.
Another employee needs something.
Meanwhile, somewhere underneath that ordinary activity, the actual security incident continues developing.
Not everything happening during a cyber incident is part of the cyber incident. Routine Service Desk activity creates operational noise and forces the player to prioritise.
That creates an interesting educational problem.
Do you investigate everything?
Do you delegate routine work?
Do you ignore a ticket because you’re concentrating on an alert?
What if the ticket that looked routine actually contained useful evidence?
And what did the attacker do while you spent twenty simulated minutes investigating a printer?
The game uses a simulated working clock, so actions can consume time and the incident can continue developing while the player investigates.
The objective isn’t to make learners click as quickly as possible.
It’s to make time itself part of the decision.
Sometimes the safest technical decision isn’t the best response
Cyber security also doesn’t exist separately from the organisation it protects.
Imagine discovering suspicious activity on an important corporate system.
The obvious response might be:
Isolate it.
Great.
Threat contained.
Except that system was supporting an important business process and you’ve just taken it offline.
People begin calling.
Work stops.
Management wants to know what’s happening.
Someone might even try to work around the restriction you’ve put in place.
The player therefore has to consider both security risk and business impact.
Business Impact progresses through qualitative states:
Normal → Strained → Disrupted → Critical
There isn’t a giant percentage bar saying Aurelius is currently 63% annoyed with you.
The player sees the consequences through the environment.
Containment actions change the state of the simulated environment. On harder difficulties, some actions can also be reversed, forcing the learner to consider the consequences of reconnecting or re-enabling something.
A technically successful containment can still be a poor incident response if it unnecessarily cripples the organisation.
Likewise, keeping everybody happy while an attacker wanders through the network isn’t exactly a career highlight.
The interesting learning happens between those extremes.
Difficulty isn’t just “the enemies have more health”
Another area I’ve been working on is the difficulty system.
Because this is an educational game, I didn’t want difficulty to simply mean making everything faster or punishing beginners for not already knowing the material.
There are currently three planned difficulty levels:
Introductory
This is designed for learners who may have limited cyber security experience.
Indicators are clearer, guidance is stronger, fewer competing pressures occur simultaneously and mistakes are generally more forgiving.
The learner still has to investigate and make decisions, but the game provides more scaffolding around that process.
Standard
Standard begins removing some of those training wheels.
Information becomes more ambiguous, competing priorities become more significant and the player needs to correlate more of the evidence themselves.
Containment and recovery decisions can also become more consequential.
Advanced
Advanced is intended for learners who are comfortable working with less guidance.
Signals can be noisier, resources and time matter more, multiple events can compete for attention and poor decisions can create chained consequences later in the incident.
The underlying incident can therefore feel very different even though the player is working inside the same fictional organisation.
But difficulty is only one half of that system.
How much technical information do you want to see?
One of the problems with designing a cyber security game for education is that learners can enter with wildly different levels of technical experience.
One learner might understand:
Windows Security Event 4624, Logon Type 10
Another might reasonably respond:
…what?
I didn’t want the solution to be removing authentic technical information.
I also didn’t want beginners to need a Windows Event ID reference sheet just to understand what the game was trying to teach them.
So the project separates Difficulty from something called Experience Mode.
Difficulty controls how demanding the incident is.
Experience Mode controls how that incident is presented to the player.
There are currently three modes.
Game Mode
Game Mode translates technical information into more immediately understandable language.
Instead of expecting the learner to already recognise every event, protocol or security term, the interface provides the important meaning in accessible language.
The underlying incident hasn’t changed.
Only the presentation has.
This allows somebody with relatively little technical experience to participate in the same investigation and begin developing the reasoning behind incident response.
Game Mode translates technical evidence into accessible information while preserving the underlying event.
Hybrid Mode
Hybrid is currently the intended default.
This mode gives the learner an understandable explanation but also allows them to inspect the more authentic technical evidence underneath it.
For example, the player might be told that a particular authentication event represents an interactive remote login.
But they can also inspect the fictional Windows-style event and begin recognizing the terminology, event structure and information that produced that interpretation.
Hybrid Mode acts as a bridge between game-readable information and recognizable real-world technical artifacts.
Educationally, this is probably the mode I’m most interested in.
The game isn’t simply telling the learner:
Remember that Event ID X means Y.
Instead, they repeatedly encounter technical evidence in context.
Eventually the scaffolding can disappear.
Authentic Mode
Authentic Mode removes much of that translation.
The player receives realistic but completely fictionalized logs, alerts, terminology and system information and is expected to interpret more of it themselves.
Authentic Mode exposes considerably more of the fictional technical artifact and provides less interpretation.
Importantly, Authentic Mode isn’t automatically a harder incident.
You could play an Introductory scenario using Authentic presentation.
Likewise, you could play an Advanced scenario using Game Mode.
They’re two separate decisions.
That gives us combinations such as:
Introductory + Game A learner-friendly incident with translated evidence and stronger guidance.
Introductory + Hybrid A learner-friendly incident where authentic evidence starts becoming visible.
Standard + Hybrid The intended middle ground, requiring more independent investigation while retaining technical scaffolding.
Advanced + Authentic Minimal interpretation, noisy information, competing events and substantially more independent reasoning.
Most importantly, all of those players are still interacting with the same underlying fictional truth.
We aren’t maintaining a “beginner version” of the attack and a completely different “expert version”.
The simulation knows what happened.
The presentation layer determines how much help you receive interpreting it.
Learning to investigate instead of learning to click
This distinction has influenced a lot of the interface design.
If the game highlights every suspicious account in bright red, we’ve already done half the investigation for the learner.
If Sentinel immediately says:
THIS ACCOUNT HAS BEEN COMPROMISED. CLICK HERE TO DISABLE IT.
there isn’t much reasoning left.
Instead, the game should give the player enough information to ask:
Why is this unusual?
Where did this login come from?
Is this normal behavior for this user?
What endpoint was involved?
Is there another event that supports this?
Do I have enough evidence to contain it?
And eventually:
What happens to the organization if I do?
Technical evidence is based on recognizable real-world structures while all organizations, identities, systems, credentials and targets remain fictional.
That last point is particularly important.
This game is about cyber security education.
It isn’t intended to become a procedural guide for attacking real systems.
The Red Team side will teach attacker mindset, reconnaissance, attack-path reasoning, human security and the consequences of weak controls without turning the game into a collection of real-world exploitation instructions.
The other side of the screen
Everything I’ve described so far largely concerns the Blue Team prototype.
But Cyber Aware is being designed around two perspectives on the same incident.
Eventually the player can choose:
🔵 BLUE TEAM / DEFENDER
or
🔴 RED TEAM / ATTACKER
The clever bit, and the part I’m particularly looking forward to developing further, is that these aren’t separate stories.
They’re different views of the same story.
Information Blue struggled to reconstruct might have been something Red deliberately created.
An employee Blue thought was simply careless might have been deliberately selected and manipulated by Red.
An alert that seemed insignificant during one play through might suddenly make complete sense after seeing what caused it from the other side.
The aim is for replaying the opposite role to produce those:
“Wait… THAT’S what that was!”
moments.
Both roles eventually experience the same underlying incident from opposite sides, with different information, objectives and available actions.
That’s where I think the rogue like structure becomes useful educationally too.
People, opportunities, routine events and some incident conditions can vary between runs.
Learning the game shouldn’t simply mean memorizing that you click buttons 4, 7 and 2 in that order.
The learner should be developing a way of thinking about the problem.
Getting things wrong is part of the design
The game currently uses a 1,000-point scoring system.
Points can reward useful investigation, evidence correlation, sensible containment, operational triage and maintaining business continuity.
Poor investigation, unnecessary disruption, premature incident closure and other decisions can cost points.
There are also tiered hints.
A learner who becomes stuck can ask for help.
The first hint might gently point them toward an area worth investigating.
Further hints become progressively more explicit.
Using them costs score, but it doesn’t stop the learner from completing the scenario.
I prefer that to leaving somebody staring at a screen for twenty minutes because they missed one clue.
The objective is still learning.
And after the incident finishes, the score isn’t supposed to be the final lesson.
The after-action report is.
It can reconstruct the incident, identify important turning points, show evidence the learner used or missed, explain why particular decisions mattered and suggest things worth exploring on another run.
The important question isn’t:
“Did you get 842 points?”
It’s:
“Do you understand why you got 842 points?”
Where the project is now
Cyber Aware is still very much in development.
The current Windows prototype is being built in Python using PySide6, which has allowed me to experiment quickly with the desktop environment, scenario systems and gameplay ideas.
At this stage I’m deliberately concentrating on one complete vertical slice rather than trying to build ten half-finished scenarios.
Corporate Espionage needs to work.
The investigation needs to be enjoyable.
The consequences need to make sense.
The educational feedback needs to actually teach something.
And somebody who has never seen the project before needs to be able to launch it, play it and understand what happened without me standing beside them explaining what all the unfinished buttons are supposed to do.
Only then does expanding it make sense.
The current prototype is being used to prove the core investigation, consequence and learning loop before the project expands into additional scenarios.
Longer term, I want to explore other organizations and incident types, each creating different pressures.
A small business won’t have the same resources as a technology company.
A school has different users and priorities.
A health service introduces very different consequences when systems become unavailable.
Financial services brings another set of risks again.
The cyber concepts change, but so does the organisation around them.
Why I’m building it
I’m a game developer and educator, and this project sits in an interesting space between those two worlds.
I’ve spent a lot of time thinking about how we move learners from:
“I remember being told this.”
to:
“I understand why this matters.”
Games give us an interesting tool for doing that.
We can create safe environments where decisions have consequences.
We can let learners fail without breaking a production network.
We can let them investigate something that initially doesn’t make sense.
We can give them competing priorities.
We can let curiosity take them somewhere we didn’t explicitly point toward.
And then we can reset the world and let them try again.
That’s what I’m hoping to explore with this project.
Cyber Aware is only a working title, and there is still a lot to build.
But Aurelius Dynamics is beginning to feel less like a collection of buttons and more like a workplace where something has gone wrong.
And that’s when this experiment started becoming a game.
Cyber Aware is the current working title of an educational cyber security game in development by Wolf Interactive. All organisations, characters, systems and security incidents depicted in the game are fictional.
