Trainers · Facilitation guide

Facilitating the brute-force lab

A complete lesson plan for the flagship lab — T1110 · Brute Force. Pre-brief, hands-on, and debrief, timed for a single class. Bring this page to the session and run it top to bottom.

Learning objectives

By the end of the lab, a student can:

• Recognise an SSH brute-force attack from authentication telemetry.
• Identify the four evidence dimensions of any alert: what, from where, how much, how fast.
• Commit to a disposition and justify it with specific, cited evidence.
• Compare their own verdict against an independent AI analyst and articulate why they agree or disagree.

Timing block (45–60 minutes)

The pre-brief — what to say

Keep it short and don't spoil the verdict. Something like:

"In a moment you'll start a lab. Real activity will be generated in your own sandbox, a detection will fire an incident within about a minute, and your job is to figure out what's going on and call it. You'll submit a disposition — true positive, false positive, benign, or duplicate — and a short rationale. Before you decide anything, answer four questions about the evidence: what happened, from where, how much, and how fast. Don't rush to a verdict; let the evidence get you there."

That's enough. Resist the urge to describe the attack — discovering it is the exercise.

The four-questions framework to coach

As you move around the room, steer students back to these four questions rather than handing them conclusions:

• What happened? Repeated failed authentications — for which account?
• From where? How many source IPs? Is it one or many?
• How much? How many attempts, and how does that compare to the detection threshold?
• How fast? Over what window? Is this a human pace or a machine pace?

When a student can answer all four, the verdict tends to fall out on its own.

Common mistakes to watch for

• Calling it a false positive. Some students assume any noisy alert is the detection over-firing. Push them to the evidence: the volume and speed are real and abnormal.
• Thin rationale. A correct disposition with a one-line "it's a brute force" loses the rationale points. Coach them to cite the specifics — the account, the source IP, the count, the window.
• Ignoring the timing signal. Students often fixate on the failure count and miss that the speed is what proves it's automated. The 5-minute window is the tell.

Discussion questions

• Why are speed and volume a signal at all? What would normal failed logins look like?
• What single change would turn this into a false positive or benign event? (e.g. the same volume from an internal scanner, or a known automation account.)
• The detection threshold here is 20 attempts. What are the costs of setting it too low? Too high?

The debrief — built on AI vs human

Open the Cohort progress table and sort for the student-vs-AI disagreements. Those rows are your lesson:

1. Pick a row where a student's disposition differs from the AI analyst's verdict. Open the incident with the class.
2. Ask the student to defend their call out loud using the four questions. Then read the AI's verdict and confidence.
3. Resolve it against ground truth — this is a true positive — and draw the lesson: confidence is not correctness; evidence decides.
4. Close with a row where student and AI agreed and both were right, to show what a clean, well-justified call looks like.

Run this once and you'll have your own rhythm. Next: Reading results for deeper progress-table reading, or Running a cohort to set up the next class.