How to run an incident with Cyber Battle Pro

Before you start

Cyber Battle Pro is the command layer during an incident. Your playbooks still tell you what to do technically. This tool helps the incident commander issue tasks, change them, confirm that people understood, report up, and keep one timeline that holds up afterwards.

There are two parts. The app is a single web page that runs in any modern browser. The Field HQ is a small server the IC runs on a laptop so the whole section can work on the same incident over a local network. You can use the app on its own, or with the Field HQ.

What you need

Once per IC laptop, before the exercise

1. Download the Field HQ for your system and check its SHA-256. Unzip it into a folder you can write to, such as Documents. The HQ keeps its certificate in a certs folder next to the executable.
2. Connect to the exercise network. In Windows, set that network to Private (Settings, Network and internet, then the network's properties).
3. Start CBP-HQ.exe once. If Windows asks about the firewall, choose Allow for private networks. If you dismissed that prompt earlier, the network check in the Section panel finds the blocking rule and offers to fix it.
4. Join from a second device, a phone is fine, to prove that the section can reach the HQ. Then press Ctrl+C in the HQ window or close it.

Quick start

Solo mode

Solo mode is the app with no Field HQ behind it. The header shows Solo where the team status would be. Everything works except live sync: you can declare, issue orders, record findings, run the whole flow and export.

Ways to open it

• From this site. Go to cyberbattlepro.ca/app.
• Offline. Download the single HTML file and open it from a laptop, a USB key or a shared drive. No installation and no network needed for the forms and the log.

Getting your work to the IC

Analysts who cannot reach the Field HQ still contribute. Press Send to IC under the session log. On a phone this opens the share menu so you can send the file over Signal or Teams. On a laptop it saves a .json file you can pass on by any approved means. The IC imports these files in Consolidate logs.

Running the Field HQ

The Field HQ runs on the IC laptop. It serves the app to the section over the local network and relays the shared log between devices. It holds everything in memory, so when it stops, the session is gone.

Start it

1. Double click CBP-HQ.exe. On Linux, run the binary from a terminal.
2. Type the team for this session, for example CPT 1, and press Enter. The label becomes the local address, so CPT 1 gives cpt1.local. Nothing is saved between sessions, so you type it every time.
3. The HQ asks for the White Cell exercise code. Type the code the exercise staff gave you, or press Enter if there is no White Cell.
4. The HQ window shows the team, a generated incident ID, the access code, the addresses the section can use and the first characters of the certificate fingerprint. Keep this window open. Closing it ends the session for everyone.
5. The app opens in your browser at http://localhost:8443 with no certificate warning. Enter your name and callsign. You join as IC and the Section panel opens.

The incident ID is generated in the form INC-261014-27. If the exercise gave you one, type it in the Declare step, or start the HQ with --incident.

The Section panel

Click the team status in the header, for example CPT 1 · 4, to open it. It is only available on the IC laptop and shows:

• a QR code for phones, and the addresses for computers. Click an address to copy a join link;
• the access code and the certificate fingerprint;
• the network check, with a Fix it button when something will stop people from connecting;
• who is on the net, with buttons to make a member 2IC or Intel;
• Projector view, a large page with the QR code, addresses and code for the briefing screen;
• End session.

Network check and Fix it

On Windows the HQ checks three things when it starts and every time you open the Section panel: whether the network is set to Public, whether a firewall rule is blocking the HQ, and whether the laptop has a Wi-Fi or Ethernet connection at all.

Fix it sets the network to Private, removes rules that block the HQ, and adds two rules named CBP Field HQ for TCP 8443 and UDP 5353. Windows asks for administrator approval once. On a managed laptop the fix may be refused, and IT has to make the change.

Briefing the section

Give the section three things: the address, the access code and the first characters of the fingerprint. The quickest way is to put the Projector view on the screen. If people are not in the room, click an address in the Section panel to copy a join link and send it over your out of band channel. The link contains the access code, so treat it like the code.

Ending the session

Press End session in the Section panel. Everyone gets a red bar with a 60 second countdown to send their log or export what they need. You can cancel during the countdown. When it reaches zero, the HQ clears its memory and closes. Each device keeps its own copy until that page is closed.

Joining the section

From a phone

1. Connect to the section network.
2. Scan the QR code on the IC screen. It opens the app with the access code already in it.
3. Accept the certificate warning after checking the fingerprint (see below).
4. Enter your name and callsign. You join the net.

From a computer

1. Connect to the section network.
2. Type one of the addresses on the IC screen, for example cpt1.local:8443 or 192.168.10.20:8443. You do not need to type https://; the HQ redirects you.
3. Accept the certificate warning after checking the fingerprint.
4. A join box opens. Check the team label at the top so you know you are on your own team's HQ. Then enter the access code, your name and your callsign, and press Enter.

Checking the certificate

Every device shows a certificate warning the first time, because the HQ makes its own certificate. Open the certificate details from the warning page or from the address bar, and compare the SHA-256 fingerprint with the characters on the IC screen. Accept only if they match.

The address cpt1.local is announced on the local network and works on most Windows, macOS, Linux and iOS devices. If it does not open, use the IP address.

Once you are on the net

• The header shows the team and the number of people connected, for example CPT 1 · 4. Click it to see who is on the net or to leave.
• Reconnecting in the header means the link dropped. Keep working; the app retries by itself and sends what you entered when it reconnects.
• If you reload the page, you go straight back onto the net with the same name and callsign. Your device remembers this for 12 hours, for that HQ only, and forgets it when you leave or the IC ends the session.
• Drafts stay on your device until you submit them. Updates from others never interrupt what you are typing.

Roles and command rights

The IC laptop is always the IC. From the Section panel the IC can make one member 2IC and one member Intel. The member sees a message when their role changes.

The HQ enforces this. If someone else sends an order or a change to the incident, the HQ refuses it and they see Only the IC or 2IC can issue orders or change the incident. In solo mode there is no one to check against, so every step is open.

Working an incident

Finding your way around

The left rail lists every step in four groups: Orders, Declare, Execute and Close. Open any step at any time. A tick means the step has been done; a count such as ×3 shows how many SITREPs or RFIs have been issued. On a phone the rail becomes a row you can scroll sideways.

There is no fixed order. On an exercise the usual run is the warning order, the back brief and the orders, then the declaration, then the Execute steps over and over as the incident unfolds, and Close at the end. In a real incident you would normally declare first. Use the steps in whatever order the situation calls for.

• Set operator in the header holds your name and callsign. They sign your findings and log entries.
• The top bar shows the incident ID, the severity, Zulu time, and the H clock once the incident is declared.
• Every step has Copy text, which gives you the formatted order or report, ready to paste into chat or email.
• Times are written as a DTG, 1442 14 Oct 26, with local time next to them. Fields that ask for a time say which zone they expect.

Warning order

Gets the section moving before the full orders are ready. Fields: Situation, Mission and probable tasks, Time and location of orders, No move before, Special instructions and Administration. The times are filled in for you, 30 and 15 minutes ahead. Press Issue warning order. Every member gets a banner with View and Acknowledge, and each acknowledgement is logged.

Back brief

The IC's back brief to the company commander, in four parts: Situation (has it changed, confirm the intent, the mission), CONOPS (intent, scheme of manoeuvre, main effort, end state), key coordinating instructions (timings and locations) and concerns. The mission and the timings come over from the warning order, so you only adjust them. Press Deliver back brief.

Orders (SMESC)

The full order, section by section:

• Situation: enemy, friendly forces, threat, and extra lines if you need them.
• Higher intent: 2UP intent, 1UP intent, 1UP main effort and scheme of manoeuvre.
• Attachments and detachments.
• Mission.
• Execution: your intent, main effort, end state and scheme of manoeuvre, then the Gentlemen, pens down, eyes up line, tasks by team or individual with deadlines, coordinating instructions and the schedule.
• Service support: dress, food, tools and access, escalation path if blocked.
• Command and signal: squadron and team IC and 2IC, reporting cadence and channel. The cadence defaults to a SITREP every 30 minutes for SEV1 and every 60 minutes otherwise.

Press Issue orders. Each member assigned a task gets a New task banner on their device, with a short vibration and tone, until they acknowledge it.

Download PDF on the warning order, back brief and orders produces a formatted document with numbered paragraphs, a signature line and ACKNOWLEDGE at the end.

Declare incident

Classify the incident, capture the 5W and start the clock.

Identification

Incident ID, Incident Commander, detection source and the time it was detected.

Severity

Pick one of the four severity cards. Each card shows the escalation that goes with it.

5W

Who, what, where, when and why: actor and people affected, the nature of the event, systems and sites, detection and first activity, impact on the mission.

Section

The roster: name, role and callsign for each member. Under the Field HQ it fills itself as people join.

Press Declare incident. H hour is set, the H clock starts, the phase is set to Identification and a command entry goes in the log. You can change the severity later in Operations.

Operations

The running picture: the PICERL phase, the severity and the task board.

• Phase: Preparation, Identification, Containment, Eradication, Recovery, Lessons learned. Tasks belong to a phase. When you move to the next phase with no tasks in it yet, Carry over tasks copies the previous ones.
• Severity: reclassify if the scope changes. The new escalation shows underneath and the change is logged.
• Task board: each task has a status, Assigned, In progress, Blocked or Done. Anyone can update the status of a task, and every change goes in the log. Blocked tasks show up in the next SITREP.

Findings journal

Where analysts record what they find. Each entry is stamped with the local time and signed with the analyst's name.

Time of the event

Zulu time the event happened, if known, as HHMM DD Mon YY.

Indicator and type

Indicator of attack, and the incident type from the list.

Machines

Affected and remote machines, by hostname or IP address. Affected machines go on the host board.

Details

Malicious executables, compromised users, impact, assistance required and notes.

MITRE ATT&CK

Pick one or more common techniques, grouped by tactic.

You need the analyst name and at least an indicator or a host to record a finding. Fields start empty with example hints, so placeholder text never ends up in the IOC list.

Artifacts and chain of custody

• Attach file or Take photo: files up to 10 MB are attached and hashed with SHA-256 straight away.
• Reference only: for memory images, disk images and packet captures. Record the name, the SHA-256, the size and where the original is stored.
• Executables, scripts, memory dumps, disk images and captures are always kept as references, never carried as files. So is anything over 10 MB.
• Every artifact writes a CUSTODY entry in the log with its hash and storage location.

Download journal (PDF) builds a PDF of all findings. Images get a page each at full resolution, and the original attached files are embedded in the PDF. Open your PDF reader's attachments panel to get them out.

Host board

Every machine named under affected machines in a finding appears here with a status: Compromised, Isolated, Cleaned or Restored. Anyone can change a status, and each change is logged with the name and the time. Add a host by hand if it is not in a finding yet. The SITREP fills its Hosts line from this board, and the PowerPoint has a host board slide.

Request for information

Ask for something you need to keep going. Fields: addressed to (IC stays in the team, WC goes to the White Cell), unit, time of request, location or network or host, details, reason (Urgent, Time Sensitive or Non-Time Sensitive) and the time you need the answer by. Urgent RFIs show amber in the log. When the White Cell answers, you and the IC get a banner and the answer is added to the record.

Request for change

Submit before any change to production: title, targeted asset, justification, whether it needs down time, planned start (or Immediately) and end, implementation plan, backout plan, risk and impact analysis, and test plan. RFCs addressed to WC are approved or rejected by the White Cell, with a comment or a request for more information.

SITREP

The situation report, issued again on every reporting cycle. Most of it fills itself:

• Precedence defaults to IMMEDIATE for SEV1 and PRIORITY otherwise.
• Hosts counts the host board by status.
• Status follows the phase: Active, Contained, Eradicating, Recovering or Closed.
• Since last SITREP lists new findings and tasks completed since the previous one.
• Current actions and Blockers come from tasks in progress and blocked tasks.
• Next SITREP due is 30 minutes ahead for SEV1 and 60 minutes otherwise.

Read it over, change what needs changing, and press Issue SITREP.

FRAGO

Changes the plan, and states only what changes: the reason, changes to the situation, mission, tasks and coordinating instructions, and a closing line that everything else stands. FRAGOs are numbered and reach the section as a banner to acknowledge.

Consolidate logs

For the IC, to bring in logs from analysts who worked without the HQ.

1. Press Import logs and select the .json files the section sent. You can import more later; anything already in is skipped.
2. Check the summary: files read, new entries, exact duplicates skipped, identical artifacts stored once, unique IOCs and pairs to review.
3. Under Possible duplicates, compare each pair side by side. Two entries from different analysts show up here when they share an indicator, use similar words and are less than 30 minutes apart. Choose Merge (keep earlier) or Keep both. Merged entries are hidden, never deleted.
4. Use the IOC table: Export CSV, or Copy defanged list to paste into a report.

The IOC table collects IP addresses, domains, URLs, hashes, files, hosts and accounts from findings and log entries. Values are normalized and deduplicated, and shown defanged, such as 203.0.113[.]7.

Stand down

Confirms the end state and hands over: end state achieved (yes, partially or no), systems restored, evidence and chain of custody, residual risk and who it was handed over to. Press Stand down and confirm. The H clock stops and turns green, and the phase moves to Lessons learned.

After action review

Five questions: what was supposed to happen, what actually happened, why the difference, sustain and improve. Write one improve item per line, with what to change and who should own it. The IC and 2IC record the full AAR. Every other member can submit their own sustain and improve points, which appear in the AAR history and in the PowerPoint.

Session log and outputs

The session log sits on the right, or behind the Log button on a narrow screen. Every command action writes to it by itself. To add your own entry, pick a type and type what happened, then press Enter.

Each entry shows Zulu time, local time, H+ time and who wrote it. Tick Show merged duplicates to see entries hidden by consolidation.

What you can take out of a session

Clear session wipes everything on that device after you confirm. It cannot be undone.

Several teams on one network

At an exercise, three or four teams often share one network. Each team's IC runs their own HQ. Sessions are completely separate: each HQ has its own incident ID, access code and certificate, and a device can only join with that HQ's code.

The join box shows the team label, so members can see they are on the right HQ before they type the code. A wrong address shows the wrong label and refuses the code. If two HQs start with the same name, the second one switches to name-2.local by itself and says so in its window.

Good practice

• Brief each team on its own address, code and certificate fingerprint.
• Never reuse an access code between teams.
• If the exercise network may carry a red team, give each team its own Wi-Fi or VLAN. Traffic is encrypted, but a hostile device on the same network can still try to disrupt an HQ.
• Some exercise networks block multicast, so .local names do not resolve. Use the IP address shown in the HQ window.

The HQ only lists real Wi-Fi and Ethernet addresses. Virtual adapters from VMware, Hyper-V, WSL, Docker or a VPN are hidden because other computers cannot reach them. Start with --all-interfaces if you need to see them.

White Cell

On an exercise, the White Cell plays the higher HQ and everyone else the teams do not have. It sees what a higher HQ would see: each team's status, and the RFIs and RFCs addressed to WC. It does not see findings, logs, SITREPs, orders or tasks.

Setting up the White Cell laptop

1. Double click CBP-HQ.exe and type WC when it asks for the team.
2. Press Enter to generate an exercise code, or type your own. Give this code to every IC.
3. The White Cell console opens in the browser. HQs started with the exercise code on the same network appear by themselves. The console looks them up by local name and also checks its own subnet on port 8443 every 45 seconds. Scan network runs the check now.
4. If an HQ uses another port, start the White Cell with --scan-ports 9443, or add the HQ by address.

From the console

• Answer RFIs.
• Approve or reject RFCs, with a comment, or ask for more information.
• Send injects to one team or to all of them, now or at a set time.
• Follow response times, and use Export log (CSV) to keep a record for the hot wash.

On each team's side

• When the HQ asks for the White Cell code at start, the IC types the exercise code.
• An orange WC · White Cell badge shows in the header of every device while the White Cell is connected. The IC's log records when it connects and disconnects.
• Injects appear as a banner for the IC and 2IC with Acknowledge. The White Cell sees who acknowledged, and how fast.
• When the White Cell answers an RFI or decides on an RFC, the author and the IC get a notification and the answer is added to the record.

Security and data

• Memory only. The session is held in memory on the HQ, capped at 512 MB, and in each browser tab. The HQ writes nothing from the session to disk; the only files it keeps are its certificate and key in certs. A member's browser remembers the access code, name and callsign for 12 hours so they can rejoin after a reload.
• Access code. Joining needs the code; the incident number is not a password. Ten wrong attempts from one address block it for ten minutes.
• Code kept out of logs. In a join link the code travels after the #, so it never reaches the server's request logs.
• Origin check. Live connections from other web origins are refused.
• IC console. The Section panel, the code, the network fix and End session only answer to the IC laptop itself.
• Limits. 25 devices per HQ by default. Record large evidence as a hash reference instead of attaching it.

Certificates

By default each HQ makes a self signed certificate for its current addresses. It is valid for 30 days, kept in certs, and renewed by itself when the address changes. Browsers warn once per device, and members confirm the fingerprint before they accept it.

For exercises, install a training CA on the devices and start the HQ with that certificate. In production, use a certificate from your organization's PKI.

CBP-HQ.exe --cert training-hq.pem --key training-hq-key.pem

iPhones may refuse the live connection with a self signed certificate, even after you accept the warning. Install a training certificate profile on iOS devices, or have iPhone users work solo and use Send to IC.

Firewall

Allow inbound TCP on the HQ port (8443 by default) and UDP 5353 for the .local name, on the section network only. On Windows, Fix it in the Section panel does this for you.

If the IC laptop fails

Every device keeps a full copy of the session. Start the HQ on any laptop with the same incident ID and the same code:

CBP-HQ.exe --incident INC-261014-27 --code RAVEN-4721

Devices that reconnect push their copy, and the new HQ is reseeded by itself. A device that loaded the app from the old laptop's address has to open the app again at the new address.

Troubleshooting

Command line options

Most people never need these. Add them after CBP-HQ.exe when you start it from a terminal. --help lists them all.

Example, two HQs on one network, each started on its own IC laptop:

CBP-HQ.exe --name cpt1 --team "CPT 1" --incident INC-261014-01
CBP-HQ.exe --name cpt2 --team "CPT 2" --incident INC-261014-02

Release notes

The HQ window shows the version it is running at the top of its banner, for example FIELD HQ v1.8.0.

Glossary

1UP, 2UP

The headquarters one and two levels above you.

2IC

Second in command. In the app, the member the IC trusts to issue orders too.

5W

Who, what, where, when and why.

AAR

After action review.

Back brief

The IC's confirmation to higher command of how the task will be carried out.

CPT

Cyber protection team.

DTG

Date time group, written 1442 14 Oct 26 in Zulu time.

FRAGO

Fragmentary order. Changes to orders already issued.

H hour

The moment the incident is declared. The H clock counts from it.

IC

Incident commander.

Inject

An event the White Cell adds to the exercise.

IOC, IoA

Indicator of compromise, indicator of attack.

NMB

No move before.

PICERL

Preparation, identification, containment, eradication, recovery, lessons learned.

RFC

Request for change.

RFI

Request for information.

SITREP

Situation report.

SMESC

Situation, mission, execution, service support, command and signal. The format of full orders.

White Cell

Exercise control. Plays higher HQ and everyone outside the teams.

Zulu

UTC, the time zone used for every DTG.