# 🎬 U4O2 Cyber Security — Booklet 1 Videos Five short videos for **Booklet 1 — Investigate**, the first of the three U4O2 cyber security booklets. We don't have class time for this part, so you're doing it at home — but do it the way we'd do it together. **45:47 of playback all up**, plus your own writing time. Video 1 suggests splitting them over two sittings. Watch them **in order** — each one hands the next one something. Across the three booklets you're playing a security consultant hired by a game studio: **investigate** (what does this organisation do, and what's wrong?), **judge** (how good are its practices, and what could they cost?), **advise** (what should it do, and why?). Those are the same three parts as your SAC, in the same order. > [!TIP] > **Don't just press play.** Before you start: Booklet 1 open, printed or on a second screen. A pen. Two highlighters, one green and one orange. > > For each video: read the **🎯 Watch for** line first, keep the **✍️ Before you play** artefact beside you, actually stop at the **⏸** marks and write, then do the **Check Your Understanding** questions from memory. Unfold (`▸`) only after you've answered. > > The writing is the learning. Watching someone else write is not. --- ## 1. How You're Marked: The Verb Ladder Booklet 1, section 1 · 6:28 **🎯 Watch for:** why two students who know *exactly the same facts* can finish four marks apart. The whole video is one fact from the case — "PixelForge uses MFA" — written five ways. Listen for the formula in the margin. **📊 The ladder — same fact, five very different marks** ```mermaid flowchart BT R1["1 · Identify<br/>PixelForge uses MFA"] R2["2 · Outline<br/>+ what it actually means"] R3["3 · Explain<br/>+ 'so' — the mechanism"] R4["4 · Analyse<br/>+ a second case fact held against it"] R5["5 · Link to goals<br/>+ a named goal + a finished because"] R1 --> R2 --> R3 --> R4 --> R5 ``` {{Video|src=https://www.youtube.com/watch?v=xgEIwztv7t4}} **✍️ Before you play:** Booklet 1 open at the table on page 2, pen in hand. **⏸ Pause and do** - **4:34** (20s) — Take this fact, quoted from the case: *there is no schedule for checking logs; in fact, login logs are switched off to save storage space.* Write it at **rung 3**, then write it again at **rung 5**. For rung 5 use the goal *keep player trust*. Two sentences each is plenty. >| ### What a rung 3 looks like >| PixelForge switches its login logs off to save storage, **so** there is no record of who signed in or from where. This means an account takeover can happen without the studio being able to detect it. >| >| If your sentence has a *"so"* or a *"this means"* in it, you're on rung 3. If it just says the logs are off, you're on rung 1. >| ### What a rung 5 looks like >| Switching login logs off leaves PixelForge unable to see who accessed which account, so a breach can run unnoticed — as it did in Season 9, when the studio learned the true size of the hijack from an angry Discord thread rather than its own systems. This directly threatens the goal of **keeping player trust**, because without logs PixelForge could not identify the 800 affected accounts and had to force a password reset on every player, publicly admitting it did not know who had been hurt. >| >| Not the exact words — three things: **a case detail, a named goal, and a because that finishes.** **Check Your Understanding** 1. Write the rung 5 formula from memory. >| ### Answer >| **Rung 5 = rung 4 + a goal + a because.** Name the *specific published goal* it touches — not "problems for the business" — and finish the because: what happens, to what, and why the organisation should care. 2. Which single word does the work at rung 3? >| ### Answer >| **"So."** It turns a fact into a consequence. ("This means" does the same job.) 3. What makes a strong *because* longer than a weak one? >| ### Answer >| Not padding — it's longer because it actually says something. The weak version stops at "which could cause problems"; the strong one names what happens and to whom. --- ## 2. The PixelForge Case: A Guided First Read Booklet 1, section 2 · 11:06 **🎯 Watch for:** the four published goals — they're the spine of the entire outcome, and every later answer hangs off one of them. Also listen for the one sentence worth quoting **word for word** in the SAC. > [!NOTE] > **This video does not replace reading the case.** Read section 1 of your booklet yourself first, with the two highlighters — green for what PixelForge does well, orange for what worries you. About ten minutes. *Then* play this and check your marks against mine. {{Video|src=https://www.youtube.com/watch?v=dLBMh6IaDdE}} **✍️ Before you play:** the case marked up in green and orange, from your own first read. **⏸ Pause and do** - **8:38** (25s) — You've just heard the Season 9 incident in full. Use the move from video 1: name a goal, and finish the because. >| ### The shape you're aiming for >| A quoted case fact → what it let happen → **the named goal it threatens** → why that matters to this studio specifically. Season 9 is the richest example in the case because the breach *and* the failure to detect it both land on the same goal. **Check Your Understanding** 1. Why does the player base turn this from a business case into a *security* case? >| ### Answer >| Most of the ~600,000 players are **13–17 years old**, and every account stores a username, email address, date of birth and purchase history. That's minors' personal data. 2. Which single fact is most worth quoting word for word? >| ### Answer >| That Stackline's game traffic, **including usernames and passwords at login, travels over the internet unencrypted.** Quote it exactly — paraphrasing costs you the precision. 3. How did a bad incident become a *worse* one in Season 9? >| ### Answer >| The breach: attackers on public Wi-Fi intercepted unencrypted logins. The escalation: because **login logs were switched off**, PixelForge couldn't tell who had been affected — so it had to reset every player's password and admit publicly that it didn't know who was hurt. --- ## 3. Part A — Goals, Objectives & Sourcing Booklet 1, Part A · 6:41 **🎯 Watch for:** the part most students throw marks away on, because it looks like the boring bit before the security content. Listen for the one-line principle: *a list of problems is just a list; advice is a problem connected to a goal.* {{Video|src=https://www.youtube.com/watch?v=fN9I2BELMas}} **✍️ Before you play:** Drills A1 and A2 open. **⏸ Pause and do** - **1:44** (20s) — **Drill A1.** Row one is done for you. Complete the other three: a case fact, then a consequence that lands on the goal. Case facts only, nothing from outside it. >| ### Sample lines >| **Eight-week seasons:** a breach mid-cycle forces unplanned emergency work that eats the release window. >| >| **Fair play:** unencrypted traffic and hardcoded keys enable account theft and cheating — a leaderboard and a store anyone can forge. >| >| **Console launch:** handing source code to an external studio, while access management is already sloppy, multiplies exposure. >| >| **The band-5 move almost nobody makes:** the deadline culture protecting goal 2 — *"after the next update ships"* — is the exact reason the encryption fix kept slipping, which broke goal 3. **One of their goals is eating another one.** If you can see that and say it, you're writing at band 5. - **4:38** (25s) — **Drill A2.** Both columns, pros and cons, case facts only. Then one sentence: *developing the console port, in-house or externally, would help PixelForge meet its goal of ___, but risks ___, because ___.* **Keep that sentence** — Booklet 3 upgrades it into a full recommendation. >| ### The model sentence >| Developing the console port externally would help PixelForge meet its goal of launching on consoles next year without growing the team, but risks exposing Stackline's source code to a studio whose security habits it does not control, because handing over full code access repeats the failure that left ex-contractors inside the repository — access granted, never governed. >| >| **If you argued for in-house, you are not wrong.** Either choice scores. The marks live in the *because*, and the because has to be a case fact, not an opinion. **Check Your Understanding** 1. Goal or objective — which is which? >| ### Answer >| A **goal** says *where*: reach one million active players. An **objective** says *how much, by when*: grow to 700,000 players by June. If a question asks about objectives and you write goals, you've answered a different question. 2. What turns a list of problems into advice? >| ### Answer >| Attaching each problem to one of the organisation's **own published goals**. Hand a client a list of problems and you've given them a list; hand them a problem attached to their goal and you've given them advice. 3. Name the six trade-offs examiners expect for the in-house vs external decision. >| ### Answer >| **Control and oversight · cost · expertise · speed · security · knowledge and IP.** That table is general knowledge — what turns it into marks is anchoring each one to a case fact. --- ## 4. Part B — The Six Security Controls Booklet 1, Part B · 7:45 **🎯 Watch for:** the most learnable part of the whole outcome — the list is fixed and it's short. Then listen for the most useful sentence in Part B: **"Partial, because…" is where top marks live.** > [!TIP] > Try to name all six *before* you unfold this. Struggling to recall is worth far more than reading the list a second time. >| ### The six controls >| 1. **Version control & code repositories** — every change tracked and reversible >| 2. **Robust identity and access management (IAM)** — right people, right access, *and revoking it when people leave* >| 3. **Encryption** — in transit (HTTPS/TLS) *and* at rest (databases, disks) >| 4. **Code review** — a second programmer reads every change before it merges >| 5. **Regular updates and patches** — on a schedule, covering everything you run >| 6. **Separated development, testing and production environments** — three walls, so a test explosion can't touch real players {{Video|src=https://www.youtube.com/watch?v=HrjG2kXbztg}} **✍️ Before you play:** Drill B1 open. **⏸ Pause and do** - **4:07** (15s) — Look away from the screen and name all six controls from memory. Actually look away. - **5:18** (25s) — **Drill B1, the controls audit.** Rate PixelForge on each control: **✓** in place · **◐** partial · **✗** absent. Every rating needs **evidence from the case**. >| ### Why this drill is worth doing properly >| A rating you argued for will stick; one you copied off the slide won't. And note which rating is hardest: a **✓** or **✗** needs one fact — quote it and move on. A **◐ partial** needs *two* facts and a judgement: the half that works, the half that doesn't, and why the gap matters. That's why partial is where the top marks live. **Check Your Understanding** 1. Which control does everyone forget half of? >| ### Answer >| **IAM** — people remember strong passwords, MFA and role-based access, and forget **revoking access when people leave**. That omission is the whole ex-contractor problem at PixelForge. 2. Encryption has two flavours and you need both. Name them and what each protects. >| ### Answer >| **In transit** (HTTPS/TLS — the padlock in your browser) protects data moving across the network. **At rest** (encrypted databases and disks) protects data sitting on storage. 3. Why is "partial" the most valuable rating to be able to write? >| ### Answer >| Because it's the only one that forces two facts plus a judgement — the working half, the failing half, and why the gap matters. That's analysis, not identification. --- ## 5. Parts C & D — Ten Risks & a Band-5 Paragraph Booklet 1, Parts C and D · 13:47 **🎯 Watch for:** the longest video, with two jobs — the ten risk types, then the move that actually shifts your score: writing them up as a paragraph. Listen for the exam-saver: **there is no eleventh card.** > [!TIP] > **Ten is too many to hold. Hold four clusters — 3, 2, 2, 3.** ```mermaid flowchart LR T(("10 risk types")) T --> C1["Outside<br/>connections · 3"] T --> C2["Software<br/>hygiene · 2"] T --> C3["People and<br/>access · 2"] T --> C4["Development<br/>habits · 3"] ``` >| ### All ten, by cluster >| **Outside connections:** use of APIs · man-in-the-middle (MITM) attacks · software acquired from third parties >| >| **Software hygiene:** malware · unpatched software >| >| **People and access:** poor identity and access management practices · insider threats >| >| **Development habits:** ineffective code review practices · combined development, testing and production environments · cybersecurity incidents {{Video|src=https://www.youtube.com/watch?v=eoZNudAoHVU}} **✍️ Before you play:** Drill C1 open, and a separate sheet for the exit questions. **⏸ Pause and do** - **4:23** (20s) — Look away and name all ten, cluster by cluster: outside connections, software hygiene, people and access, development habits. Three, two, two, three. - **6:22** (25s) — **Drill C1, the core drill of the booklet.** Four problems from the case. For each: **quote the fact · name the risk type · state what could happen · name the goal it threatens.** Four columns, and the fourth is the one that scores. >| ### The standard to aim for >| **Four complete rows beat eight thin ones every time.** >| >| *Band 2:* "contractors keep access" / IAM / "someone could get in" / — nothing in the goal column. >| >| *Band 5:* the quoted fact, the named risk type, a specific consequence, **and the named goal it threatens.** The gap between those two is the fourth column. - **11:42** (15s) — The exit questions, on a separate sheet. Give these a proper go. **Check Your Understanding** 1. You meet a problem in a case that doesn't fit any of the ten. What do you do? >| ### Answer >| **There is no eleventh card.** Describe the mechanism and map it onto the nearest existing risk type — don't invent a new category. 2. Which cluster is "PixelForge to the letter", and why? >| ### Answer >| **Development habits.** All three apply: the code review rule exists but reviews are rubber stamps; development, testing and production share one server; and Season 9 is a cybersecurity incident in its own right. 3. What are the four columns of a band-5 risk row? >| ### Answer >| **Quote the fact · name the risk type · state what could happen · name the goal it threatens.** Miss the fourth and you cap yourself in the middle bands. --- ## What's next Booklets 2 (**Judge**) and 3 (**Advise**) have their own five-video sets — links will appear here once they're published. --- ## Related pages - [VCE Software Development Hub](/sd/VCE%20Software%20Development%20Hub) - [C2 and C3 Assessment Explained](/sd/C2%20and%20C3%20Assessment%20Explained) - [C4 Design Ideas and Evaluation Explained](/sd/C4%20Design%20Ideas%20and%20Evaluation%20Explained) --- *Narration in these videos is a synthetic voice, not a recording. Mascot illustrations after Dorothy Wall (1894–1942), public domain in Australia.*