Documentation

Running a lab

How to start a lab, the three kinds of experience you will meet, how your detection and response times are measured, and where to find your results.

Starting a lab

Open the Labs catalogue, pick an incident that matches your role and level, and select Start. The platform loads the incident's evidence and objectives, and for the labs that need one it leases a private environment just for you. Most labs need none: they replay captured evidence, so there is nothing to build and nothing to wait for. Your run is yours alone either way, so you can work at your own pace without affecting anyone else.

The moment your lab opens, your personal clock starts. That start point belongs to you: if you begin an hour later than a colleague, your times still reflect only the time you actually spent working, not the time you waited before you began.

Four ways you will work a lab

Every lab places you inside a realistic cloud incident, but the way you interact depends on what you are practising. You will meet four kinds of experience:

  • An investigation from captured evidence. You work through a fixed set of captured logs and artefacts (sign-in records, audit events, files) that were gathered ahead of time. You hunt through what is there, tag the evidence that matters, and submit your findings. Because the evidence is captured in advance, the lab is fast, repeatable, and identical for everyone. This is the only kind that produces your detection and response times.
  • A live lab you are graded on. You work a real, running environment in a terminal in your browser, where the lab shell is offered, and you carry out genuine response steps. You are graded on the end state you leave behind, for example that a compromised session is now revoked, not on which keys you pressed to get there. The environment is reclaimed when the run passes its time limit, so finish it or come back the same day.
  • A CTF with challenges and flags. You solve challenge-style tasks against a pre-captured artefact set and submit flags to earn points, working at your own pace. Most are sequenced, so you are shown one question at a time and move on by answering it, passing it, or handing in a report. When you finish, a grade report shows your score, which challenges you solved, and how many attempts you used.
  • A shared cloud range. One real cloud environment, built once for the lab and read by everyone taking it rather than one per trainee. You open it in the Azure portal with your own lab account and answer the lab's questions on the run's page. Everyone answers the same questions over the same data, so a run here is training rather than assessment and produces no individual measurement.

How your work is scored

The platform checks your answers against evidence it already holds, so scoring is quick and consistent for everyone. Depending on the lab, a correct answer might be a flag you submit, a piece of evidence you tag as significant, or the verified end state of a live lab.

For live labs it helps to remember that the grade is about the result, not the route. There is usually more than one valid way to contain an incident; what counts is that you reach the correct, verifiable end state.

Report challenges

Some challenges ask for a written deliverable rather than a flag. You write your findings directly in the challenge and submit them for review. They earn no automatic points: an instructor from your organisation reads what you wrote and records a verdict, which appears on your run alongside any feedback they leave.

A verdict is either accepted, or returned for revision with a note explaining what to change. Work that was returned you can revise and resubmit whenever you are ready, with no deadline; resubmitting clears the previous verdict and puts your work back in the review queue, so a verdict always refers to the version the instructor actually read. Accepted work is settled and cannot be revised: accepting it ends the exchange, so a sign-off cannot quietly vanish months later.

How detection and response are measured

Two headline numbers describe your work on each lab: time to detect (MTTD) and time to respond (MTTR). Detection is the moment you first correctly identify the incident. Response is the moment you submit a containment decision, whether or not the actions you chose were the right ones: the response clock measures how quickly you acted, and the score beside it measures how well. Both are measured from your own personal start.

Only actions the platform can see and confirm are counted, such as a graded submission or an evidence tag. Nothing you self-report is used, which keeps your figures honest, reproducible, and comparable across runs. In practice this means you get credit the instant you do the work.

These are measured programme metrics to help you track your own growth over time. They describe how you perform on the Academy's labs; they are not a statistically powered scientific claim about real-world outcomes.

Where to see your results

Your Dashboard gives you the at-a-glance view of recent activity and progress. The KPIs page shows your detect and respond times per lab and how they trend as you complete more of the programme, so improvement becomes visible.

Your investigation work lives in Cases, where the timeline, artefacts, and findings for each run stay together in one place. A CTF run keeps its own grade report, with your score and per-challenge results. Nobody else can open that report, though the solve rate it produces does appear on your progress page, which your administrators can read.

We use only essential and functional cookies to run the platform and remember your settings, with no tracking, analytics, or advertising. See our Cookie Policy.