Sztab cyber-obrony — dowództwo i gotowość (symulacja)

Model metodologii, nie deklaracja zdolności: jak zespół agentów AI mógłby wspierać dowodzenie reakcją na incydent — struktura, stany gotowości, przepływ decyzji. Dowód pokazujemy tam, gdzie realnie istnieje (skille analityczne K0NSULT); reszta jest oznaczona jawnie jako model ćwiczebny.

Czym jest ten model — i czym nie jest

„Sztab cyber-obrony" to szkielet organizacyjny: sposób ułożenia ról, stanów gotowości i przepływu decyzji tak, żeby zespół ludzi wspierany przez agentów analitycznych reagował na incydent w powtarzalny, udokumentowany sposób — a nie ad hoc. To metodologia zarządzania kryzysowego zapożyczona z praktyki wojskowej i doktryny GRC (governance-risk-compliance), przełożona na warstwę cyber. Nie jest to system uzbrojony, nie wykonuje żadnych działań w cudzej infrastrukturze, nie prowadzi rozpoznania ani operacji poza własnym środowiskiem testowym. Każdy element poniżej jest oznaczony jako model (opisany, przećwiczony na danych syntetycznych) albo LIVE (istnieje jako realne narzędzie K0NSULT z kodem i testem) — bez mieszania tych dwóch kategorii.

Struktura dowodzenia

Model zakłada jedną osobę koordynującą (w ćwiczeniu opisywaną roboczo jako „pani kapitan") pełniącą funkcję orchestratora — nie dowódcy operacji bojowej, lecz koordynatora przepływu informacji i decyzji między rolami. Zadaniem koordynatora jest triage (co jest istotne teraz), przydział zadania do właściwej roli i pilnowanie, żeby żadna decyzja nie ominęła ścieżki eskalacji do człowieka tam, gdzie jest to wymagane (prawne, kadrowe, publiczne komunikaty).

Każda rola w tym modelu odpowiada realnemu narzędziu analitycznemu K0NSULT (nie broni ofensywnej): m.in. mechanizmy oceny dowodu, panel wielu niezależnych ocen oraz krytyk kompletności, opisane szerzej na roadmapie dev. To narzędzia wspierające analizę i raportowanie, nie systemy prowadzące działania w cudzych sieciach.

Stany gotowości

Trzy poziomy modelu — analogiczne do wojskowych stopni alarmowych, przełożone na pracę zespołu analitycznego. Liczby agentów w stanie oczekiwania są przykładem modelowym (dane syntetyczne z ćwiczenia), nie deklaracją rzeczywistej floty w produkcji.

Liczby powyżej to parametr modelu ćwiczebnego (rój ≠ rejestr) — ilustrują skalowanie zaangażowania, nie stan faktycznej infrastruktury bojowej.

Przepływ decyzji przy incydencie

Kluczowy element modelu: każda ścieżka kończy się decyzją człowieka tam, gdzie sprawa dotyka prawa, reputacji lub komunikacji publicznej. Agenci przygotowują dowód i rekomendację — nie podejmują autonomicznie decyzji o działaniach na zewnątrz organizacji. To rozróżnienie jest twarde i celowe: sztab wspiera, nie zastępuje odpowiedzialności decyzyjnej człowieka ani właściwych służb.

Dostępność 24/7 — model gotowości, nie deklaracja operacyjna

W modelu ćwiczebnym agenci/role pozostają w stanie oczekiwania (BASELINE) przez cały czas, każdy ze zdefiniowaną rolą i progiem aktywacji — analogicznie do warty sztabowej. To pozwala testować scenariusz „ktoś zgłasza incydent o dowolnej porze" bez utrzymywania człowieka non-stop przy każdym elemencie procesu. Ważne zastrzeżenie: to jest własność architektury programowej (procesy mogą być uruchamiane na żądanie), nie deklaracja utrzymywania gotowości bojowej ani zastępstwa dyżuru CSIRT/CERT. Dyżur ludzki, eskalacja telefoniczna do właściwych służb i zgłoszenia do organów pozostają poza zakresem tego modelu.

Sun Tzu jako rama strategiczna — nie instrukcja ataku

Model sztabu opiera się na dwóch zasadach defensywnych z tej tradycji, stosowanych tu wyłącznie jako rama organizacyjna, nie jako źródło technik ofensywnych:

• „Zwycięstwo przygotowane przed bitwą" — priorytetem jest gotowość: rejestry aktualne, role przypisane, playbooki przećwiczone zanim nadejdzie incydent, nie improwizacja w trakcie.
• „Znać siebie i przeciwnika" — „znać siebie" oznacza tu rzetelny rejestr własnych zasobów, znanych ograniczeń i pokrycia dowodowego (zob. znane ograniczenia). „Znać przeciwnika" oznacza rozumienie typowych wzorców zagrożeń z literatury (kategorie taktyk, nie instrukcje wykonania) — wyłącznie w celu rozpoznania i obrony, nigdy replikacji.

Żadna część tej strony nie zawiera i nie będzie zawierać instrukcji wykonania ataku, exploitów ani payloadów. Opisujemy co jest testowane (np. czy detekcja zadziała na dany wzorzec zdarzenia) i jaki dowód liczy się jako sukces (log, alert, evidence-package) — nigdy „jak zaatakować".

Wektory zagrożeń — model kierunków, nie oskarżenie

Na potrzeby ćwiczenia klasyfikujemy zagrożenia wyłącznie jako kierunki techniczne modelowe (np. „wektor sieciowy zewnętrzny", „wektor łańcucha dostaw", „wektor tożsamości/dostępu", „wektor aplikacyjny") — kategorie znane z ram takich jak MITRE ATT&CK, opisane na poziomie taktyki, nie konkretnego aktora. Ta strona świadomie nie przypisuje żadnego scenariusza konkretnemu państwu, grupie ani podmiotowi — atrybucja wymaga formalnego dochodzenia właściwych służb, nie modelu ćwiczebnego. Wszelkie „kierunki geograficzne" wspominane w materiałach szkoleniowych K0NSULT są uproszczeniem edukacyjnym (np. do celów warsztatu o zróżnicowaniu wzorców ruchu sieciowego), nie deklaracją polityczną ani wywiadowczą.

Co jest LIVE, co jest modelem ćwiczebnym

Powiązane: tablica ćwiczebna atak-obrona → /attack-sim · zasady zaangażowania → /engagement · rejestr znanych ograniczeń → /known-limitations.