Fikcyjny scenariusz ćwiczebny: jak model sztabu AI-agentów mógłby reagować na hybrydowy incydent uderzający w warstwę gospodarczą i przemysłową — łańcuch dostaw, własność intelektualną, sterowanie przemysłowe (OT/ICS) i wiarygodność komunikacji korporacyjnej. Wektor jest tu kierunkiem technicznym modelu, nie oskarżeniem żadnego państwa.
Poniższy scenariusz jest w całości fikcyjny i syntetyczny — zbudowany na potrzeby ćwiczenia metodologicznego, nie na podstawie realnego zdarzenia ani konkretnego doniesienia. Celem jest sprawdzenie, czy model sztabu opisany na stronie sztab-obrony potrafi poprowadzić spójną ścieżkę reakcji: identyfikacja → izolacja → ewidencja → remediacja → ciągłość działania, gdy incydent dotyka jednocześnie kilku warstw organizacji — nie tylko IT, ale też produkcji, dostawców i komunikacji zewnętrznej. Żaden element tego ćwiczenia nie jest testem wykonanym na cudzej infrastrukturze; wszystko dzieje się na danych i systemach syntetycznych, w środowisku ćwiczebnym K0NSULT.
Na potrzeby ćwiczenia przyjmujemy roboczą nazwę „wektor zachodni" wyłącznie jako kierunek techniczny modelu zaczerpnięty z ram klasyfikacyjnych (np. MITRE ATT&CK) — nie jako wskazanie konkretnego państwa czy grupy. Scenariusz zakłada cztery równoległe wątki, typowe dla ćwiczeń hybrydowych o profilu gospodarczo-przemysłowym:
Fikcyjny komponent od zewnętrznego dostawcy zawiera modyfikację nieuwzględnioną w specyfikacji — model testuje, czy sztab wykryje rozbieżność przy odbiorze/aktualizacji, zanim trafi ona do środowiska produkcyjnego.
Symulowany nietypowy odpływ danych projektowych z repozytorium wewnętrznego — model sprawdza wykrycie anomalii dostępu i szybkość izolacji konta/zasobu.
Fikcyjna próba zakłócenia parametru w syntetycznym środowisku sterowania przemysłowego (OT/ICS) — ćwiczenie skupia się na segmentacji sieci IT/OT i procedurze bezpiecznego odcięcia, nie na technikach ingerencji.
Syntetyczny przykład spreparowanego nagrania/komunikatu podszywającego się pod przedstawiciela organizacji — model testuje procedurę weryfikacji źródła przed publiczną reakcją.
Wszystkie cztery wątki są rozgrywane równolegle w jednym ćwiczeniu, by sprawdzić, czy sztab potrafi ustalić priorytety, gdy żaden pojedynczy sygnał nie jest jeszcze „potwierdzonym incydentem", ale suma sygnałów wskazuje na skoordynowaną presję na kilka warstw organizacji naraz.
| Krok | Co robi model sztabu | Dowód / artefakt |
|---|---|---|
| Identyfikacja | Korelacja czterech sygnałów w jeden wpis rejestru; wstępna klasyfikacja wektora (kierunek techniczny, nie atrybucja podmiotu). | Wpis w rejestrze zdarzenia, znacznik czasu, źródło sygnału. |
| Izolacja | Odcięcie podejrzanego konta/zasobu (IP theft), segmentacja IT/OT (sabotaż), wstrzymanie wdrożenia komponentu (łańcuch dostaw), blokada dystrybucji nagrania do weryfikacji (deepfake). | Log działania izolującego, brak zmiany stanu poza środowiskiem ćwiczebnym. |
| Ewidencja | Zbudowanie evidence-package: hash artefaktów, chain-of-custody, powiązanie z findingami (CVSS/EPSS/KEV tam, gdzie dotyczy). | package_sha256, wpis w rejestrze dowodowym. |
| Remediacja | Rekomendacja działania naprawczego (patch, rotacja dostępu, weryfikacja dostawcy, sprostowanie komunikacyjne) — decyzję o wdrożeniu podejmuje człowiek. | Playbook + status rekomendacja, nie autonomiczne działanie. |
| Ciągłość | Ocena wpływu na ciągłość działania (BCP/DR w modelu), aktualizacja rejestru ograniczeń, zamknięcie wątku po weryfikacji panelu. | Zamknięty wpis w rejestrze + wzmianka w board-packu. |
Każdy krok w tabeli jest częścią tego samego modelu metodologicznego co na stronie sztab-obrony — tu zastosowanego do jednego, w pełni fikcyjnego scenariusza.
Role sztabu w tym ćwiczeniu odpowiadają realnym narzędziom analitycznym K0NSULT — nie systemom ofensywnym ani broni. Każdy element poniżej jest albo model (przećwiczony na danych syntetycznych), albo LIVE (istnieje jako kod z testem).
Wzbogacanie findingów, budowa evidence-package, kontrola integralności artefaktów zebranych w każdym z czterech wątków.
Sprawdza, czy dowód dla każdego wątku faktycznie pokrywa deklarację (claim ≤ proof) przed zamknięciem incydentu.
Wielogłosowa ocena wniosku — szczególnie istotna przy wątku deepfake, gdzie ryzyko fałszywie pozytywnej/negatywnej oceny jest wysokie.
Mapowanie wątków na potencjalne obowiązki (np. NIS2 dla OT/ICS, RODO przy odpływie danych) — wsparcie decyzji, nie porada prawna.
Triage czterech równoległych sygnałów, przydział priorytetów, log decyzji, obowiązkowa eskalacja do człowieka.
Board-pack łączący wszystkie wątki w jeden spójny opis dla zarządu — z jawnym rozróżnieniem co potwierdzone, co w toku.
W tym ćwiczeniu zasada „znać siebie i przeciwnika" jest stosowana wyłącznie jako rama organizacyjna, nigdy jako źródło techniki działania:
Ta strona nie zawiera i nie będzie zawierać instrukcji wykonania ataku, exploitów ani payloadów. Opisujemy wyłącznie co jest testowane w każdym z czterech wątków i jaki dowód liczy się jako sukces obrony (log izolacji, evidence-package, wpis w rejestrze) — nigdy „jak zaatakować".
Nazwa robocza „wektor zachodni" użyta w tym ćwiczeniu opisuje wyłącznie kierunek techniczny modelu na potrzeby ćwiczenia geograficznego zróżnicowania scenariuszy (analogicznie mogłaby powstać wersja „wektor wschodni" albo „wektor wewnętrzny" — to ten sam mechanizm ćwiczebny, inny punkt startowy w scenariuszu). Ta strona świadomie nie przypisuje żadnego z czterech wątków konkretnemu państwu, grupie ani podmiotowi. Atrybucja realnego zdarzenia wymaga formalnego postępowania właściwych służb — nigdy modelu ćwiczebnego. Każde podobieństwo do rzeczywistych podmiotów, dostawców czy incydentów jest przypadkowe i niezamierzone; scenariusz służy wyłącznie testowaniu procedury reakcji sztabu.
Powiązane: model sztabu i stany gotowości → /sztab-obrony · tablica ćwiczebna atak-obrona → /attack-sim · zasady zaangażowania → /engagement · rejestr znanych ograniczeń → /known-limitations.