CYBER-PRE-GAME-BRIEFING-V1.md
# CYBER COMMAND — Pre-Game Briefing V1
Status: **kontrakt treści dydaktycznej** (nie kod, nie slajdy, nie UI)
Data: **2026-09-12**
Karta: **E-02**
Organizacja: **COMPANY-01** (NEXORA Logistics S.A. — nazwa robocza)
Handoff: `docs/games/cyber/CYBER-HANDOFF.md`
Nadrzędny kontrakt: `docs/games/cyber/CYBER-CURRICULUM-MAP-V1.md` (**E-01**)
Dwie równoważne wersji dostawy: **TEACHER-LED** i **SELF-GUIDED**.
Ta sama treść merytoryczna. Różny nośnik i głos.
Nie uczymy jednej poprawnej sekwencji decyzji.
Przykłady zachowań w grze są **ilustracją**, nie facitem.
---
## 1. Purpose
Przygotować uczestnika **BEGINNER** do pierwszej sesji CYBER COMMAND w **10–13 minut**.
Po briefingu uczestnik:
- rozumie, że **alert ≠ incydent ≠ cyberatak**;
- odróżnia **pewność informacji** od **stanu systemu**;
- zna minimum organizacji logistycznej 24/7 i trzech systemów operacyjnych (WMS, TMS, EDI/API);
- wie, czym jest **containment** i **recovery** — i że to nie to samo;
- rozumie napięcie **bezpieczeństwo vs ciągłość działania**;
- zna rolę **Incident Commandera** i podstawowy odczyt **Mission Control**;
- może rozpocząć symulację bez poczucia „nie rozumiem połowy ekranu”.
Briefing **nie** zastępuje gry, debriefu ani Teacher Guide.
---
## 2. Timing
| Element | Czas |
|---|---|
| Otwarcie sytuacyjne | **0:30–0:45** |
| Bloki 1–9 (treść merytoryczna) | **~10:30** |
| Blok 10 + Mission Control onboarding | **~1:30** |
| **Razem (teacher-led, spokojne tempo)** | **~12:45** |
| **Self-guided (czytanie + NEXT)** | **~11:00–12:30** |
Teacher-led może skrócić bloki 5–7 o ~30 s u grupy INTERMEDIATE.
Self-guided: uczestnik kontroluje tempo; punkty ekranowe skracają narrację.
**Realny czas teacher-led (szacunek po redakcji):** **12 min 45 s** (+ otwarcie 40 s).
**Realny czas self-guided (szacunek):** **11 min 30 s** (bez pauz na pytania grupy).
**Liczba bloków merytorycznych:** **10** (+ otwarcie osobno).
---
## 3. Otwarcie sytuacyjne (0:30–0:45)
Wspólne dla obu wersji. Nie liczy się do dziesięciu bloków E-01.
### CANONICAL CONTENT
Firma logistyczna pracuje całą dobę. Towar wjeżdża na magazyn, system mówi, co skompletować, auta wyjeżdżają w okienka załadunku. Nagle coś w IT zaczyna wyglądać nienormalnie — alert, dziwne logowanie, skarga ze zmiany.
To może być atak. Awaria. Pomyłka. Albo fałszywy alarm.
Za chwilę **Ty** będziesz dowodzić reakcją — nie czekając, aż ktoś inny „domknie sprawę”.
### TEACHER DELIVERY
> Wyobraźcie sobie magazyn, który nie śpi. Zlecenia wpadały automatycznie, rampa jechała, kierowcy mieli swoje okna. I nagle — sygnał z monitoringu albo telefon ze zmiany: „coś jest nie tak z systemem albo z dostępem”.
>
> Czy to atak? Awaria? Ktoś kliknął źle? A może nic poważnego?
>
> Za kilka minut w tej grze to **wy** będziecie musieli zdecydować — jako dowódca incydentu. Nie musicie być hackerami. Musicie prowadzić firmę przez chaos informacji.
**Pytanie do grupy (opcjonalne):** „Kiedy ostatnio słyszeliście o cyberataku w wiadomościach — co najpierw padło: alert, incydent, czy od razu ‚wszystko padło’?”
**VISUAL CUE:** Noc / zmiana magazynowa. Rampa, wózki, ekran z ikoną alertu — bez logów technicznych.
### SELF-GUIDED DELIVERY
**Headline:** Za chwilę poprowadzisz firmę przez incydent.
**Punkty:**
- Logistyka 24/7: towar, magazyn, transport — non stop.
- Pojawia się nietypowy sygnał IT.
- Atak, awaria i pomyłka wyglądają podobnie na początku.
- Twoja rola: decyzje przy niepełnej wiedzy.
**NEXT** → Blok 1
---
## 4. Canonical briefing blocks
Każdy blok: **CANONICAL CONTENT** → **TEACHER DELIVERY** → **SELF-GUIDED DELIVERY**.
---
### BLOK 1 — ALERT / INCYDENT / CYBERATAK
**Czas:** 1:00
**Kompetencje:** K1, K2 · **LO:** LO-01
#### CANONICAL CONTENT
- **Alert** — sygnał, że coś **może** wymagać uwagi. Nie jest jeszcze werdyktem.
- **Incydent** — sytuacja wymagająca **skoordynowanej reakcji** zespołu (IT, bezpieczeństwo, biznes, prawo).
- **Cyberatak** — **celowe** działanie przeciw systemom, danym albo dostępowi.
**Najważniejsza lekcja:** alert **nie** jest automatycznie dowodem ataku.
Niektóre incydenty mogą prowadzić do szyfrowania, blokady systemów albo żądania okupu — ale to **nie** oznacza automatycznego końca misji. W tej grze liczy się to, co zrobisz dalej, nie sama etykieta „ransomware”.
#### TEACHER DELIVERY
> W monitoringu coś zabłyśnie — to jest **alert**. Dopiero gdy zaczynacie organizować reakcję — kto patrzy, kto decyduje, co zatrzymać, komu zadzwonić — mówimy o **incydencie**.
>
> **Cyberatak** to sytuacja, w której ktoś **celowo** chce zaszkodzić: ukraść dostęp, zablokować system, wyciągnąć dane. Ale pierwszy alert może być równie dobrze dziwnym logowaniem albo błędem integracji.
>
> W grze macie za zadanie **nie panikować na pierwszy sygnał** i **nie udawać**, że nic się nie dzieje, gdy sygnałów jest już kilka.
>
> I jedno zdanie na marginesie: czasem w realnych incydentach pojawia się szyfrowanie albo żądanie okupu. To nie jest magiczny „game over” — nadal trzeba dowodzić reakcją.
**Pytanie do grupy:** „Czy każdy alert z antywirusa to atak?” (oczekiwane: nie)
**VISUAL CUE:** Trzy karty: ALERT → INCYDENT → CYBERATAK. Strzałka „alert ≠ werdykt”.
#### SELF-GUIDED DELIVERY
**Headline:** Alert to sygnał — nie wyrok.
**Punkty:**
- **Alert** — coś może być nie tak.
- **Incydent** — trzeba skoordynować reakcję.
- **Cyberatak** — celowe działanie przeciw IT / danym / dostępowi.
- Okup i szyfrowanie **mogą** się zdarzyć w incydentach — nie kończą misji z definicji.
**NEXT** → Blok 2
---
### BLOK 2 — NIEPEŁNA INFORMACJA
**Czas:** 1:00
**Kompetencje:** K3 · **LO:** LO-06, LO-07
#### CANONICAL CONTENT
W prawdziwym incydencie **nikt** nie ma pełnego obrazu od pierwszej minuty. Monitoring pokazuje fragment. Użytkownik coś zgłasza. SOC widzi inny wycinek. Magazyn czuje skutek, zanim IT zna przyczynę.
**Czekanie** też jest decyzją — ma koszt (czas, rampa, zaufanie klienta).
**Działanie** przy niepełnej wiedzy też ma koszt (możesz odciąć za dużo albo za mało).
Gra **celowo** nie daje pełnej prawdy od razu. To nie błąd — to warunek ćwiczenia.
#### TEACHER DELIVERY
> W filmach ktoś wpisuje trzy komendy i wie wszystko. W firmie logistycznej o trzeciej w nocy wie ktoś inny coś innego.
>
> W tej grze **decydujecie bez pełnego obrazu** — tak jak w realnym IR. Możecie poprosić o dowód, poczekać na SOC, zadzwonić na zmianę. Ale magazyn nie czeka w nieskończoność.
>
> Pamiętajcie: **„nie wiemy jeszcze”** to uczciwa informacja dla zarządu. Lepiej niż udawanie pewności.
**Pytanie do grupy:** „Czy lepiej czekać na 100% pewności, czy działać na 60% — i skąd wiecie, że to już 60%?”
**VISUAL CUE:** Mapa firmy w mgle — widoczne 2–3 obszary, reszta szara. Napis: „To, co widzisz ≠ cała prawda”.
#### SELF-GUIDED DELIVERY
**Headline:** Decydujesz bez pełnego obrazu.
**Punkty:**
- Każdy widzi inny fragment sytuacji.
- Czekanie ma koszt; działanie też.
- „Nie wiemy jeszcze” — OK w komunikacji wewnętrznej.
- Gra **nie** ukrywa błędu — mgła informacji jest zamierzona.
**NEXT** → Blok 3
---
### BLOK 3 — PEWNOŚĆ INFORMACJI
**Czas:** 1:30
**Kompetencje:** K1 · **LO:** LO-01, LO-02, LO-03
#### CANONICAL CONTENT
Statusy **pewności informacji** (to, co wie organizacja o danym fakcie):
| Status | Znaczenie dla ucznia |
|---|---|
| **SIGNAL** | Jest ślad — to **nie** wyrok. |
| **SUSPECTED** | Sensowna hipoteza — **nie** fakt. |
| **PARTIALLY VERIFIED** | Część się potwierdza; obraz nadal niepełny. |
| **CONFIRMED** | Informacja **sprawdzona** — ale **nie** oznacza „wiemy wszystko o incydencie”. |
| **RETRACTED** | Późniejsza informacja **koryguje** wcześniejszą — to nie „bug w grze”. |
**Najważniejsze zdanie:** CONFIRMED dotyczy **konkretnej informacji**, nie całego incydentu.
Dwa niezależne sygnały zwykle podnoszą pewność. Jeden sygnał — to materiał do analizy, nie materiał do paniki.
#### TEACHER DELIVERY
> Na ekranie zobaczycie chipy przy informacjach: SIGNAL, SUSPECTED, CONFIRMED i inne. To mówi **jak bardzo organizacja ufa danej wiadomości** — nie „czy magazyn jest zdrowy”.
>
> **SIGNAL** — coś mrugnęło: log, alert, telefon ze zmiany.
> **SUSPECTED** — mamy hipotezę: „może to konto”.
> **PARTIALLY VERIFIED** — część się zgadza, reszta jeszcze nie.
> **CONFIRMED** — ten **konkretny fakt** został zweryfikowany.
> **RETRACTED** — ups, wcześniejsza informacja była nieprecyzyjna. **Zmieniacie zdanie** — to dobra reakcja.
>
> **CONFIRMED nie znaczy „sprawa zamknięta”.** Możecie potwierdzić „dziwne logowanie”, a nadal nie wiedzieć, co dotknęło magazyn.
**Pytanie do grupy:** „SOC mówi CONFIRMED na ‚podejrzane logowanie’. Czy możecie już odciąć cały magazyn?” (oczekiwane: niekoniecznie — to inna decyzja)
**VISUAL CUE:** Pasek Feed z chipami SIGNAL → SUSPECTED → CONFIRMED. Osobno RETRACTED ze strzałką „zmiana oceny”.
#### SELF-GUIDED DELIVERY
**Headline:** Pewność informacji — osobna skala.
**Punkty:**
- **SIGNAL** → ślad, nie werdykt.
- **SUSPECTED** → hipoteza.
- **PARTIALLY VERIFIED** → częściowo potwierdzone.
- **CONFIRMED** → ten fakt sprawdzony — **nie** „cały incydent rozwiązany”.
- **RETRACTED** → korekta — zmień ocenę.
**NEXT** → Blok 4
---
### BLOK 4 — KONTO / PHISHING / MFA
**Czas:** 1:30
**Kompetencje:** K2, K4 · **LO:** LO-04
#### CANONICAL CONTENT
**Konto użytkownika** to cyfrowy klucz: ktoś zalogowany może czytać pocztę, zatwierdzać zmiany, wchodzić do systemów zgodnie ze swoimi uprawnieniami.
**Phishing** — próba skłonienia kogoś do podania hasła, kodu albo kliknięcia w coś, co daje atakującemu dostęp **jako legalny użytkownik**.
**MFA** (wieloskładnikowe logowanie) — drugi krok potwierdzenia (telefon, aplikacja). Utrudnia **nowe** logowanie; **nie** anuluje już otwartej sesji.
W incydencie często zaczyna się od pytania: **czy to naprawdę ta osoba?** — zanim dotkniecie całej firmy.
#### TEACHER DELIVERY
> Atakujący często nie „łamie muru” od razu. Czasem **używa czyjegoś konta** — bo ktoś kliknął w fałszywy link, albo zdradził kod z SMS-a.
>
> **Phishing** to nie tylko „głupi mail”. To scenariusz: podszywasz się pod IT, szefa, dostawcę — i prosisz o coś, co daje dostęp.
>
> **MFA** pomaga — ale pamiętajcie: jeśli ktoś **już** jest zalogowany, samo MFA nie magicznie go wyrzuca.
>
> W grze będziecie czasem musieli **potwierdzić tożsamość** zanim zetniecie coś większego — np. cały kanał zleceń od klientów.
**Pytanie do grupy:** „Co groźniejsze: skompromitowane konto magazyniera czy konto bez MFA w biurze — czy to zależy od uprawnień?”
**VISUAL CUE:** Ikona klucza + skrzynka „Phishing?” + telefon MFA. Bez prawdziwych nazw kont.
#### SELF-GUIDED DELIVERY
**Headline:** Konto to klucz — phishing go kradnie.
**Punkty:**
- Konto = logowanie + uprawnienia w systemach.
- Phishing = wyłudzenie dostępu jako „legalny” user.
- MFA = drugi krok; chroni **nowe** logowanie.
- Najpierw często weryfikujesz **kto** — potem **co** odciąć.
**NEXT** → Blok 5
---
### BLOK 5 — ORGANIZACJA (COMPANY-01)
**Czas:** 1:30
**Kompetencje:** K5 · **LO:** LO-09
#### CANONICAL CONTENT
**COMPANY-01** (NEXORA Logistics — nazwa robocza) to polski operator logistyczny, ok. 800 osób. Centrala w biurach; **główne centrum magazynowe pracuje 24/7**; mniejsze lokalizacje regionalne.
Łańcuch fizyczny, który musi być w głowie:
**ZLECENIE → MAGAZYN → KOMPLETACJA → ZAŁADUNEK → TRANSPORT**
Cyber **dotyka towaru**: postój IT może oznaczać wolniejszą rampę, błędne etykiety, opóźnione auta, telefony od klientów.
Zespoły w grze (jako źródła informacji, nie inni gracze): SOC zewnętrzny, IT, tożsamość, sieć, magazyn, transport, zarząd (CEO, COO), DPO.
#### TEACHER DELIVERY
> Gramy w firmie, która **nie jest „tylko IT”**. To magazyn, rampa, auta, klienci z umowami SLA.
>
> Zlecenie wpada — ręcznie albo automatycznie. Magazyn **kompletuje** towar. **Ładuje** na pojazd. **Transport** dowozi w oknie czasowym.
>
> Gdy coś padnie w systemie, fizyczny świat **nie znika** — ludzie próbują jechać na papierze, telefonie, Excelu. Tylko **wolniej**, z błędami i presją.
>
> Wy jesteście dowódcą incydentu — nie siedzicie w serwerowni sami. Macie SOC, IT, magazyn, COO, który pyta „czy rampa jedzie”.
**Pytanie do grupy:** „Co wcześniej odczuje klient: że padł monitoring, czy że nie ma statusu przesyłki?”
**VISUAL CUE:** Schemat 5 kroków (zlecenie → transport). Zdjęcie rampy / wózka — nie diagram 29 węzłów.
#### SELF-GUIDED DELIVERY
**Headline:** Logistyka 24/7 — cyber ma cenę w towarze.
**Punkty:**
- COMPANY-01: operator logistyczny, magazyn non stop.
- Łańcuch: zlecenie → kompletacja → załadunek → transport.
- Postój IT = wolniejsza lub chaotyczna operacja.
- Ty koordynujesz zespoły — SOC, IT, magazyn, zarząd.
**NEXT** → Blok 6
---
### BLOK 6 — WMS / TMS / EDI·API
**Czas:** 1:30
**Kompetencje:** K5 · **LO:** LO-09, LO-16
#### CANONICAL CONTENT
Trzy systemy operacyjne — minimum przed pierwszą decyzją:
| System | Jedno zdanie |
|---|---|
| **WMS** (Warehouse Management System) | Mówi magazynowi, **co znaleźć, skompletować, zapakować i przygotować do wysyłki**. |
| **TMS** (Transport Management System) | Pomaga **zaplanować transport**: trasy, auta, okna załadunku. |
| **EDI / API** (hub integracji) | **Automatyczny kanał zleceń** i statusów między klientami a firmą — bez ręcznego przepisywania każdego zamówienia. |
WMS i TMS **współpracują**, ale **można je dotknąć osobno** — decyzja o odcięciu jednego nie jest automatycznie decyzją o drugim.
Na **Situation Board** zobaczysz m.in. te obszary — nie musisz pamiętać całej mapy IT.
#### TEACHER DELIVERY
> **WMS** — mózg operacji magazynowej: lokacje, picking, etykiety. Bez niego magazyn **może** jechać ręcznie — ale wolno i ryzykownie.
>
> **TMS** — dyspozycja transportu: które auto, która trasa, które okno. Transport może żyć chwilę **osobno** od magazynu — ale bez danych z rampy szybko się rozjedzie.
>
> **EDI/API** — automatyczne zlecenia od klientów. Utniesz hub — nowe zamówienia **nie wpłyną same**. Stare mogą jeszcze być w kolejce.
>
> Na planszy zobaczycie te bloki jako **węzły organizacji** — to wasz obraz „jak wygląda firma”, nie lista do wykucia na pamięć.
**Pytanie do grupy:** „Co bardziej boli w pierwszej godzinie: brak WMS czy brak TMS — zależy od fazy dnia?”
**VISUAL CUE:** Trzy ikony: regał (WMS), ciężarówka (TMS), strzałka między firmami (EDI/API). Podpis: „Operacje, nie serwerownia”.
#### SELF-GUIDED DELIVERY
**Headline:** Trzy systemy, które łączą IT z rampą.
**Punkty:**
- **WMS** — co kompletować i wysyłać z magazynu.
- **TMS** — jak planować transport.
- **EDI/API** — automatyczne zlecenia i statusy.
- Można ograniczyć jeden bez automatycznego cięcia wszystkiego.
**NEXT** → Blok 7
---
### BLOK 7 — TOŻSAMOŚĆ (IDENTITY)
**Czas:** 1:00
**Kompetencje:** K4 · **LO:** LO-04
#### CANONICAL CONTENT
**Tożsamość** w tej firmie to ludzie i ich konta — w biurze (poczta, Teams), w magazynie (terminale), u administratorów.
W świecie gry występują m.in. **Entra ID** (chmura, MFA, M365) i **Active Directory** (środowisko lokalne: stacje, serwery, część aplikacji magazynowych). To **dwa powiązane światy logowania** — awaria albo blokada po jednej stronie **nie zawsze** gasi drugą od razu.
Incident Commander **nie** konfiguruje tych systemów ręcznie — **decyduje**, kiedy poprosić zespół tożsamości o blokadę konta, sesji albo roli — i **jak szeroki** ma być zakres.
#### TEACHER DELIVERY
> Kto może się zalogować — i **gdzie** — to tożsamość. Biuro na poczcie w chmurze. Magazyn na terminalu. Admin na serwerze.
>
> W firmie hybrydowej macie **Entra** i **Active Directory**. Nie musicie tego dziś konfigurować — musicie wiedzieć, że **„wyłączyć logowanie”** może znaczyć coś innego dla biura niż dla rampy.
>
> Wasza rola: **kiedy** i **jak szeroko** prosić o cięcie dostępu — nie wpisywanie komend.
**VISUAL CUE:** Dwa obłoki: „Chmura (Entra, M365)” i „Lokalnie (AD, magazyn)”. Strzałka „sync” — bez technikaliów sync.
#### SELF-GUIDED DELIVERY
**Headline:** Tożsamość — kto wchodzi i z jakim prawem.
**Punkty:**
- Konta ludzi: biuro, magazyn, admini.
- Entra ID (chmura) i Active Directory (lokalnie) — powiązane, nie identyczne.
- Ty decydujesz o zakresie blokady — IT ją wykonuje.
**NEXT** → Blok 8
---
### BLOK 8 — CONTAINMENT / RECOVERY
**Czas:** 1:00
**Kompetencje:** K4, K6 · **LO:** LO-08, LO-11
#### CANONICAL CONTENT
**Containment** (ograniczenie wpływu) — działania, które **ograniczają dalszy wpływ** incydentu: odcięcie konta, izolacja urządzenia, ograniczenie dostępu, odłączenie systemu od sieci.
**Recovery** (odtwarzanie) — **przywracanie działania** po awarii, izolacji albo ataku. To **osobny tor** — nie to samo co containment.
Recovery **nie** jest: „backup → wszystko działa jak wczejniej”.
**Odtwarzanie również jest procesem decyzyjnym** — kolejność, zaufanie do kopii, ludzie na zmianie.
Nie ma jednej uniwersalnej reguły typu „zawsze tnij najwężej” albo „zawsze tnij najszybciej”.
**Dobierasz zakres działania do tego, co wiesz, ryzyka czekania i kosztu dla firmy** — i potrafisz to **uzasadnić**.
#### TEACHER DELIVERY
> **Containment** — „nie pozwólmy, żeby rosło”. Odcięcie konta. Izolacja komputera. Odłączenie systemu. Czasem to konieczne — ale **szersze cięcie** może **zatrzymać magazyn**.
>
> **Recovery** — „wróćmy do jazdy”. Ale nie ma magicznego przycisku. Kopia może być stara, brudna albo niedostępna. Ludzie muszą wiedzieć, **co** przywracamy **najpierw**.
>
> W grze **nie ma jednej poprawnej sekwencji**. Są decyzje z kosztem. Przykład z późniejszej rozgrywki: czasem wąskie cięcie konta wystarczy; czasem trzeba dotknąć systemu operacyjnego — **ale to wasza ocena**, nie sztywna reguła tutoriala.
**Pytanie do grupy:** „Containment czy recovery — co robisz, gdy magazyn jeszcze jedzie, ale masz podejrzenie na koncie admina?”
**VISUAL CUE:** Dwa tory: CONTAINMENT (tarcza — „ogranicz”) vs RECOVERY (strzałka w górę — „przywróć”). Nie timeline restore.
#### SELF-GUIDED DELIVERY
**Headline:** Najpierw ogranicz wpływ — potem odtwarzaj.
**Punkty:**
- **Containment** — ograniczenie dalszego wpływu (konto, urządzenie, system).
- **Recovery** — przywracanie działania; **nie** instant fix.
- To dwa **osobne** tory decyzyjne.
- Zakres dobierasz do wiedzy, ryzyka i kosztu — nie do sztywnej reguły.
**NEXT** → Blok 9
---
### BLOK 9 — SECURITY VS BUSINESS
**Czas:** 1:00
**Kompetencje:** K5, K7 · **LO:** LO-09, LO-13
#### CANONICAL CONTENT
Decyzje bezpieczeństwa **mają cenę operacyjną**. Bezpieczniejsza decyzja techniczna **może** spowolnić magazyn, zablokować zlecenia, opóźnić transport albo zwiększyć chaos na zmianie.
Przykład **neutralny** (bez liczb z gry):
*Jeżeli odetniesz system magazynowy, możesz zmniejszyć ryzyko cyber — ale jednocześnie magazyn może stracić część wydajności.*
**Pytanie retoryczne** (nie odpowiadaj za gracza):
*Czy zawsze najbezpieczniejsza decyzja techniczna jest najlepszą decyzją dla całej firmy?*
SOC **rekomenduje** — Incident Commander **decyduje** o odcięciu krytycznej operacji. COO będzie bronił rampy — to **nie wróg**, to presja biznesowa.
#### TEACHER DELIVERY
> Tu łamie się schemat „bezpiecznie = dobrze”. Możecie **uratować IT** i **ukarać magazyn** — albo odwrotnie.
>
> Wyobraźcie sobie: izolujecie WMS, żeby być spokojni. Ryzyko cyber spada — ale picking spada też. Klienci dzwonią. COO pyta, czy **musiało** być tak szeroko.
>
> **Nie ma automatycznej dobrej odpowiedzi.** Gra sprawdzi, czy potraficie **ważyć** — i czy mówicie zarządowi prawdę, gdy **nie wiecie**.
>
> Zapamiętajcie jedno pytanie na całą sesję: *Czy najbezpieczniejsze technicznie jest najlepsze dla firmy?*
**VISUAL CUE:** Waga: „Bezpieczeństwo IT” vs „Rampa / klienci”. Bez procentów.
#### SELF-GUIDED DELIVERY
**Headline:** Bezpieczeństwo i biznes ciągną w różne strony.
**Punkty:**
- Izolacja systemu może chronić — i spowolnić operacje.
- SOC doradza; **Ty** decydujesz o krytycznych cięciach.
- COO / CEO reprezentują presję SLA — to część scenariusza.
- Najbezpieczniejsze ≠ zawsze najlepsze dla całej firmy.
**NEXT** → Blok 10
---
### BLOK 10 — ROLA IC + MISSION CONTROL (wstęp)
**Czas:** 0:45 (rola) — szczegóły UI w sekcji 6
**Kompetencje:** K7 · **LO:** LO-14, LO-16
#### CANONICAL CONTENT
**Incident Commander (Dowodzący incydentem)** — Ty w tej grze.
**Nie musisz:** konfigurować firewalli, analizować malware, wpisywać komend administratora.
**Musisz:** ustalać priorytety, wydawać rozkazy zespołom, ważyć informacje, zarządzać uwagą, komunikować niepewność, podejmować decyzje przy presji czasu.
To gra **strategiczna** — dowodzenie incydentem, nie „klikaj w poprawne narzędzie”.
Mission Control to kokpit. Podstawy w sekcji 6.
#### TEACHER DELIVERY
> Nie gracie pentesterów. Gracie **szefa operacji kryzysowej IT** w firmie, która musi **dowieźć towar**.
>
> Klikniecie „izoluj” — ale najpierw **decydujecie**, czy w ogóle, co, i jak szybko informujecie COO.
>
> Za chwilę — **90 sekund** — przejdziemy po ekranie gry. Na razie: **wy jesteście centrum dowodzenia**.
**VISUAL CUE:** Sylwetka IC na tle Mission Control (zblurowany UI). Lista „decydujesz / nie musisz”.
#### SELF-GUIDED DELIVERY
**Headline:** Jesteś Incident Commanderem.
**Punkty:**
- Priorytety, rozkazy, komunikacja — **Twoja** rola.
- Nie musisz być adminem firewalla ani analitykiem malware.
- Gra testuje **decyzje**, nie skróty klawiszowe.
- Dalej: 90 s po Mission Control.
**NEXT** → Sekcja 6 (Mission Control onboarding)
---
## 5. Teacher-led script — skrót prowadzenia
Pełny tekst w blokach 1–10 (TEACHER DELIVERY). Poniżej **kartka prowadzącego** — kolejność i tempo.
| # | Blok | Czas | Uwaga prowadzącego |
|---|---|---|---|
| — | Otwarcie | 0:40 | Wciągnij w rolę; bez definicji akademickich |
| 1 | Alert / incydent / atak | 1:00 | Jedno zdanie o okupie/szyfrowaniu **tutaj** |
| 2 | Niepełna informacja | 1:00 | Podkreśl koszt czekania |
| 3 | Pewność informacji | 1:30 | Rozdziel od stanu systemu — most do bloku 3b poniżej |
| 3b | **Stan systemu (wpleciony)** | *(w bloku 3 lub 6)* | 30 s w teacher-led: patrz sekcja poniżej |
| 4 | Konto / phishing / MFA | 1:30 | Bez kampanii, bez nazw kont |
| 5 | Organizacja | 1:30 | Łańcuch fizyczny 5 kroków |
| 6 | WMS / TMS / EDI | 1:30 | Trzy ikony — nie 10 węzłów |
| 7 | Tożsamość | 1:00 | Entra + AD — dwa światy |
| 8 | Containment / recovery | 1:00 | Bez „zawsze tnij wąsko” |
| 9 | Security vs business | 1:00 | Pytanie retoryczne — **nie** odpowiadaj |
| 10 | Rola IC | 0:45 | Most do UI |
| — | Mission Control | 1:30 | Sekcja 6 |
### Wpleciony fragment — STAN SYSTEMU (teacher-led, ~30 s)
W bloku 3 lub na początku bloku 6 prowadzący mówi:
> Osobna sprawa: **jak działa system** — SPRAWNY, OGRANICZONY, IZOLOWANY, NIEDOSTĘPNY, ODTWARZANY. To **stan operacyjny**, nie to samo co SIGNAL czy CONFIRMED. Możecie **wiedzieć**, że logowanie jest podejrzane, a WMS **jeszcze jedzie** — albo odwrotnie. **Nie mieszajcie osi.**
**VISUAL CUE:** Dwie osie prostopadle: „Pewność informacji” vs „Stan systemu”.
---
## 6. Self-guided script — skrót
Pełny tekst w blokach 1–10 (SELF-GUIDED DELIVERY). Każdy ekran: **headline + 2–4 punkty + NEXT**.
Dodatkowy ekran **3b — Stan systemu** (wpleciony między blok 3 a 4):
**Headline:** Pewność informacji ≠ stan systemu.
**Punkty:**
- Informacja: SIGNAL … CONFIRMED (jak wierzysz wiadomości).
- System: SPRAWNY / OGRANICZONY / IZOLOWANY / NIEDOSTĘPNY / ODTWARZANY.
- Dwie osie **niezależne**.
**NEXT** → Blok 4
Self-guided **nie** zawiera quizu końcowego. Dozwolone: „Pokaż przykład” (statyczny), bez strategicznych wyborów.
---
## 7. Mission Control onboarding (~90 s)
Wspólne po blokach 1–10. Ostatni element przed T0.
### CANONICAL CONTENT
| Element | Uczeń ma wiedzieć |
|---|---|
| **FEED** | Co **nowego** wpłynęło: alert, telefon, raport SOC. Źródło + **pewność** informacji. Ważne nie ginie w szumie. |
| **SITUATION BOARD** | Jak wygląda firma według **obecnej wiedzy** — nie ukrytej prawdy silnika. WMS, transport, tożsamość jako obszary do obserwacji. |
| **COMMAND STACK** | Co **wymaga uwagi**: Needs, In Progress, Pressure. Kolejka spraw, nie lista zadań tutoriala. |
| **COMMAND DOCK** | Narzędzia: komunikacja, dowody, działania, playbook, terminy. Tu **składasz** rozkazy — nie wszystko naraz. |
| **STATUS / CONFIDENCE** | Chip przy **informacji** — nie myl z **stanem systemu** na Boardzie. |
| **ACTION IN PROGRESS** | Rozkaz **trwa** — efekt może przyjść po czasie. |
Nie tłumacz wszystkich przycisków. Nie pokazuj ścieżki ataku.
### TEACHER DELIVERY (~90 s)
> **Feed** — ticker świata: co wpada. Czytajcie **pewność**, nie tylko nagłówek.
> **Situation Board** — mapa firmy **tak, jak ją dziś rozumiecie**. Będzie się zmieniać.
> **Command Stack** — „co pilne”. Nie musicie załatwić wszystkiego naraz.
> **Command Dock** — skrzynka narzędzi: pogadaj, zbierz dowód, wydaj rozkaz.
> **Action in progress** — ktoś **wykonuje** — magazyn nie resetuje się w sekundę.
> **Status vs confidence** — system **OGRANICZONY** to nie to samo co alert **CONFIRMED**. Dwie osie — pamiętajcie z briefingu.
**VISUAL CUE:** Zrzut Mission Control z podpisanymi 4 strefami (Feed, Board, Stack, Dock). Strzałki — bez numeracji przycisków.
### SELF-GUIDED DELIVERY (~90 s, 4 ekrany)
**Ekran MC-1 — Headline:** Feed i Board
- **Feed** — nowe informacje + pewność.
- **Board** — obraz organizacji z **Twojej** wiedzy.
**NEXT**
**Ekran MC-2 — Headline:** Stack i Dock
- **Stack** — co wymaga uwagi / decyzji.
- **Dock** — comms, dowody, działania.
**NEXT**
**Ekran MC-3 — Headline:** Czas i dwie osie
- **Action in progress** — rozkaz trwa.
- Pewność informacji ≠ stan systemu.
**NEXT**
**Ekran MC-4 — Headline:** Gotowy do T0
- Jesteś Incident Commanderem.
- Alert to nie wyrok. Decyzje mają koszt.
**START MISJI**
---
## 8. Terminology used (LEVEL 1 + LEVEL 2 z briefingu)
| Termin | PL / wyjaśnienie | Poziom |
|---|---|---|
| Alert | sygnał | L1 |
| Incydent | sytuacja wymagająca skoordynowanej reakcji | L1 |
| Cyberatak | celowe działanie przeciw IT / danym / dostępowi | L1 |
| SIGNAL / SUSPECTED / PARTIALLY VERIFIED / CONFIRMED / RETRACTED | pewność informacji | L1 |
| SPRAWNY / OGRANICZONY / IZOLOWANY / NIEDOSTĘPNY / ODTWARZANY | stan operacyjny systemu | L1 (w briefingu) |
| Phishing | wyłudzenie dostępu | L1 |
| MFA | drugi krok logowania | L1 |
| Containment | ograniczenie wpływu | L1 + EN |
| Recovery | odtwarzanie | L1 + EN |
| Incident Commander | dowodzący incydentem | L1 + EN |
| WMS | system magazynowy | L2 |
| TMS | system transportowy | L2 |
| EDI/API | automatyczna wymiana zleceń | L2 |
| Entra ID | tożsamość chmurowa (Microsoft) | L2 |
| Active Directory | tożsamość lokalna / domena | L2 |
| SOC | zewnętrzny monitoring bezpieczeństwa 24/7 | L2 (kontekst) |
| COO / CEO / DPO | role biznesowe / prawne | L2 (kontekst) |
**Nie wprowadzono w briefingu:** SIEM, EDR, vault, kill chain, NIS2, restore order, Domain Admin, 29 węzłów.
---
## 9. Spoiler audit
Dla każdego bloku: czy ujawnia W-02 / kampanię? **Wynik: PASS** (po redakcji).
| Blok | Ujawnia W-02? | Uwagi |
|---|---|---|
| Otwarcie | Nie | Ogólna sytuacja logistyczna |
| 1 Alert/incydent | Nie | Ogólne zdanie o okupie — bez zapowiedzi scenariusza |
| 2 Niepełna informacja | Nie | Meta-zasada gry |
| 3 Pewność | Nie | Statusy learner-facing tylko |
| 3b Stan systemu | Nie | Osie UI, nie timeline |
| 4 Konto/phishing | Nie | Brak initial account, kampanii, wektora |
| 5 Organizacja | Nie | COMPANY-01 publiczny z W-01 |
| 6 WMS/TMS/EDI | Nie | Brak „TMS SaaS wektor”, „WMS zostanie przejęty” |
| 7 Tożsamość | Nie | Entra/AD ogólnie; brak sync jako wektor |
| 8 Containment/recovery | Nie | Brak vault, restore order, DW12 |
| 9 Security vs business | Nie | Przykład neutralny; brak % i DW |
| 10 Rola IC | Nie | |
| Mission Control | Nie | Brak HUD ataku, hidden stage |
**Zakazane elementy — status:**
| Element | W briefingu? |
|---|---|
| Initial compromised account | ❌ |
| TMS route / WMS path | ❌ |
| ORBIT MARGIN | ❌ |
| Destructive trigger | ❌ |
| Exfil | ❌ (tylko ogólne „dane” w K8 poza briefingiem) |
| Backup/vault outcome | ❌ |
| ALT A–D | ❌ |
| Ending conditions | ❌ |
---
## 10. Training vs Exam implications
Zapis do kontraktu E-01/E-02 (zgodnie z LGD):
### TRAINING
- Pełny briefing (teacher-led lub self-guided) przed T0.
- Mission Advisor / context help: **termin**, **mechanizm**, **dlaczego istotne**, **typy ryzyka** — **nigdy** „wybierz X” / „co teraz zrobić”.
- Tooltipy i glossary: pełne definicje + kontekst organizacyjny.
- Playbook: pełniejszy — bez facitu sekwencji.
### EXAM
- **Zostaje:** definicje terminów, znaczenie statusów pewności i stanu systemu, pomoc UI (Feed, Board, Stack, Dock).
- **Usunięte:** interpretacja sytuacyjna, porada decyzyjna, „co teraz zrobić”, sugerowanie konsekwencji.
- Advisor: tylko kategorie A (termin) i B (UI) — bez strategicznego C.
Briefing **ten sam** przed EXAM — różnica zaczyna się **w trakcie** misji (pomoc), nie w treści miniwykładu.
---
## 11. Debrief — dwustopniowy (kontrakt E-01/E-02)
**STAGE 1 — PLAYER KNOWLEDGE TIMELINE** (student-facing):
„Co **wiedziałeś wtedy**?” — oś decyzji i informacji **z perspektywy gracza**, bez Ground Truth.
**STAGE 2 — TEACHER-LED GROUND TRUTH REVEAL** (teacher-only):
Dopiero po refleksji Stage 1 prowadzący **może** pokazać: co naprawdę się działo w silniku, timeline kampanii, typowe błędy przy oknach decyzyjnych.
Ground Truth **nie** jest student-facing podczas misji.
Pełny projekt debriefu — **E-06**, nie E-02.
---
## 12. Baseline visibility — wykorzystanie bez przeciążenia
Rekomendowane `baselineVisibleNodeIds` (10 węzłów z E-01) **nie są** listą do zapamiętania w briefingu.
**W briefingu explicite:**
| Priorytet narracji | Węzły / pojęcia |
|---|---|
| **Główna scena** | WMS, TMS, integration-hub (EDI/API), warehouse-automation / operacje magazynu |
| **Tożsamość** | Entra ID, Active Directory, M365 — „dwa światy logowania” |
| **Kontekst** | regional-ops (regiony), customer-portal (klient dzwoni), soc-external (skąd alerty) — **jednym zdaniem**, nie lista 10 |
Uczestnik **widzi** te obszary na Boardzie od T0 — briefing daje **sens**, nie nazwę po nazwie. Reszta grafu (klasa B) odkrywa się w grze.
---
## 13. Delivery notes
### Teacher-led
- Czytaj TEACHER DELIVERY **prawie 1:1** — naturalny język, nie monoton podręcznik.
- Pytania do grupy **opcjonalne** — nie wydłużają ponad 13 min bez kontroli.
- INTERMEDIATE: skróć bloki 5–7 o ~30 s łącznie.
- PROFESSIONAL: może pominąć bloki 4–6 definicyjnie — **nie** osobna treść V1.
### Self-guided
- Jeden ekran ≈ 45–75 s czytania.
- „Pokaż przykład” = statyczna ilustracja VISUAL CUE — bez gałęzi decyzyjnej.
- Po MC-4 → bezpośrednio T0 (bez quizu).
### Wspólne
- Po zmianie treści: `scripts/publish-cyber-review-docs.sh` → review channel.
- Treść briefingu **nie** trafia automatycznie na whitelist review (tylko 6 dokumentów E-01) — dopisanie do whitelisty = osobna decyzja LGD.
### Ransomware — lokalizacja jednego zdania
**Blok 1** (CANONICAL + TEACHER + SELF-GUIDED):
*„Niektóre incydenty mogą prowadzić do szyfrowania… okupu… nie oznacza automatycznego końca misji.”*
Bez sugestii, że V1 „na pewno” tam dojdzie.
---
## 14. Open questions (max 5 do decyzji LGD)
1. **Whitelist review:** Czy `CYBER-PRE-GAME-BRIEFING-V1.md` ma wejść na `docs.gramy.biz/cyber-review/` po akceptacji?
2. **Self-guided V1 produkt:** Czy self-guided jest **obowiązkowy** w pilotażu, czy wystarczy teacher-led + skrócony self-guided jako PDF?
3. **Ekran 3b:** Czy stan systemu zostaje **osobnym** ekranem self-guided, czy tylko wpleciony w blok 3 (obecnie: oba — teacher wpleciony, self osobny ekran)?
4. **SOC / portal na Boardzie:** Czy baseline 10 węzłów zostaje, czy E-03 registry przeniesie SOC i portal do klasy B (tooltip only)?
5. **Długość EXAM briefingu:** Czy EXAM używa **identycznego** briefingu, czy skróconej wersji samych bloków 3 + 6 + MC (tylko UI)?
---
## 15. Pięć najważniejszych zdań uczestnika
1. **Alert to sygnał — nie wyrok.**
2. **CONFIRMED dotyczy informacji — nie całego incydentu.**
3. **Pewność informacji i stan systemu to dwie osobne osie.**
4. **Containment ogranicza wpływ; recovery to osobny, trudny proces decyzyjny.**
5. **Najbezpieczniejsza decyzja techniczna nie zawsze jest najlepsza dla całej firmy.**
---
## 16. Powiązania
| Dokument | Relacja |
|---|---|
| `CYBER-CURRICULUM-MAP-V1.md` | §6 zakres 10 tematów; §10 baseline; §14 Advisor |
| `CYBER-WORLD-V1.md` | COMPANY-01, WMS/TMS/hub, role, tryby manual |
| `CYBER-MISSION-CONTROL-V1.md` | W-03 — szczegóły UI poza 90 s onboarding |
| `CYBER-INCIDENT-V1.md` | **nie** cytowany w treści — spoiler firewall |
---
*E-02 V1 — treść i struktura. Implementacja UI / slajdów / registry: kolejne karty EDU.*