CNCK0NSULTAI-Truthuni0naiHackatonipIII ↗k0nsult.dev ↗ dla botówDomeny osobne, spięte siecią CNC + kernelem.
K0NSULT // ai-truth/ipIII
Scenariusz: Sztab: 0 agentów Pokrycie: 0% Luki: 0 luk ↓ pełny wynik (macierz faz)
k0nsult.cloud / ai-truth / ipIII / cwiczenia / symulator-obrony

Symulator obrony — dobór agentów ↔ skille ↔ atak

Interaktywne narzędzie klient-side (jeden blok JS, bez backendu): wybierz scenariusz ataku, dobieraj agentów do sztabu klikając karty, a pasek pokrycia, macierz faz i lista luk przeliczają się na żywo. To odpowiedź na problem statycznych stron symulacyjnych w portalu — tutaj wynik zależy od Twojego wyboru, nie jest opisem jednego z góry ustalonego scenariusza.

Czym jest to narzędzie — i czym nie jest

Symulator to model doboru narzędzia obronnego do fazy ataku, zbudowany na realnych elementach portalu: 12 ról agentów odwzorowanych z sztabu obrony i koszar agentów, oraz 13 skilli/zdolności — w tym 10 skilli z zbrojowni (roj-spawn, judge-panel, dowod-albo-gap i inne, status LIVE jako narzędzia analityczne) oraz 3 zdolności platformy ipIII (evidence-package, Legal Trigger Engine, wzbogacanie CVE — również LIVE). Fazy ataku są uproszczonym, siedmiostopniowym modelem wzorowanym na MITRE ATT&CK (rekonesans → dostęp początkowy → wykonanie → utrwalenie → ruch boczny → eksfiltracja → wpływ) — kategoriami taktyk, nie instrukcjami wykonania. Mapowanie skill→faza i wskaźniki mocy 1-5 to model ćwiczebny tego narzędzia, nie zweryfikowana norma skuteczności ani wynik testu penetracyjnego.

Krok 1 — wybierz scenariusz ataku

Sześć scenariuszy, każdy z inną kombinacją faz MITRE. Kliknięcie zmienia zestaw faz ocenianych w macierzy poniżej — reszta interfejsu przelicza się automatycznie.

Krok 2 — dobierz agentów do sztabu

Zaznacz dowolną liczbę agentów (checkbox) — każdy niesie 1-3 skille. Pokrycie faz poniżej liczy się z sumy zaznaczonych agentów, biorąc dla każdej fazy najwyższą moc spośród ich skilli (model „najlepszy z wybranych", nie suma mocy — dodanie kolejnego agenta z tym samym skillem nie mnoży wskaźnika).

Zaznaczonych agentów: 0 / 12.

Wynik — pokrycie obrony (model)

Pasek i macierz poniżej to przeliczenie modelu, nie pomiar rzeczywistej odporności. Jeśli faza jest czerwona/bez pokrycia — to luka w wybranym sztabie, nie dowód na to, że atak danego typu faktycznie by się powiódł.

0% faz scenariusza z choćby minimalnym pokryciem (model)
Scenariusz: —
Faza ataku (model MITRE)W tym scenariuszu?Moc pokrycia (1-5, model)Pokrywają (agent · skill)

Luki (fazy bez pokrycia w wybranym sztabie)

Rekomendacja — kogo dodać, żeby domknąć lukę

Jak czytać wskaźnik mocy (1-5) — ta sama skala co w matcherze

Skala jest identyczna z modelem opisanym na matcherze incydent→agenci/skille: 1 = skill ledwie dotyka fazy, potrzeba szerszej orkiestracji; 5 = pełne pokrycie proceduralne kroku (triage→dowód→decyzja) dla tej fazy. Liczba nie mierzy prawdopodobieństwa powstrzymania ataku i nie zastępuje oceny ryzyka przez zespół bezpieczeństwa — to parametr modelu ćwiczebnego, wpisany ręcznie na podstawie tego, do czego dany skill/zdolność jest faktycznie zaprojektowany (patrz zbrojownia).

Scenariusze — źródło i uzasadnienie faz

ScenariuszFazy (model)Powiązana strona źródłowa
Ransomware (podwójna ekstorcja)7/7 — pełny łańcuch, bo dziś ransomware zwykle łączy szyfrowanie z groźbą publikacji danych (eksfiltracja przed impactem) matcher-incydent (wiersz „Ransomware")
DDoS4/7 — recon, dostęp początkowy, wykonanie, wpływ; bez utrwalenia/ruchu bocznego/eksfiltracji, bo cel to utrata dostępności, nie trwały dostęp matcher-incydent (wiersz „DDoS")
APT / wektor wschodni (hybryda)7/7 — pattern czterowątkowy (szyfrowanie + DDoS + dezinformacja + anomalia łańcucha dostaw) symulacja-pl-wschod
Supply-chain / wektor zachodni (hybryda gospodarcza)7/7 — łańcuch dostaw + IP theft + sabotaż OT/ICS + deepfake korporacyjny symulacja-pl-zachod
Atak wielowektorowy / multi (masowy)7/7 — cztery równoległe strumienie (cyber + AI + dezinformacja + łańcuch dostaw) naraz, model triage masowego symulacja-pl-multi
Phishing → ruch boczny5/7 — recon, dostęp początkowy, wykonanie, ruch boczny, eksfiltracja; bez formalnego utrwalenia i osobnej fazy wpływu w tym uproszczonym wariancie matcher-incydent (wiersz „Phishing")

Kierunki „wschód"/„zachód" to wyłącznie etykiety modelowo-geograficzne z ćwiczeń źródłowych (kierunek techniczny ruchu w scenariuszu syntetycznym) — nie przypisanie winy żadnemu państwu, grupie ani podmiotowi. Atrybucja realnego incydentu wymaga formalnego dochodzenia właściwych służb, nie tego symulatora.

Skąd wzięliśmy roster — źródła w repozytorium

Żaden agent ani skill w tym symulatorze nie jest zmyślony od zera — każdy odwzorowuje realny element opisany gdzie indziej w portalu:

12 ról agentów

Zbudowane z 6 ról sztabu obrony (koordynator, analiza dowodowa, ocena zgodności, komunikacja/raport, krytyk kompletności, panel weryfikujący) rozszerzonych o 6 dodatkowych ról operacyjnych nazwanych wprost skillami z zbrojowni (operator roju, analityk 4D, brama ACK, konwergencja masowa, pamięć/threat-intel, klasyfikator PQC).

13 skilli/zdolności

10 skilli z zbrojowni (status LIVE jako narzędzia analityczne uruchamiane w sesji) + 3 zdolności platformy ipIII opisane na roadmapie dev: evidence-package (chain-of-custody), Legal Trigger Engine (decision-support) i wzbogacanie CVE (CVSS/EPSS/KEV, offline).

Mapowanie skill→faza

Logika i skala mocy 1-5 są przeniesione z modelu matcher-incydent (typ incydentu→skille), tu rozbite na granularniejsze fazy MITRE zamiast całych typów incydentu.

Scenariusze

Ransomware/DDoS/phishing z tabel matchera; hybrydy „wschód", „zachód" i „multi" z osobnych stron symulacja-pl-wschod, symulacja-pl-zachod, symulacja-pl-multi.

Uwaga o tożsamości: 12 ról agentów w tym symulatorze to nazwy funkcyjne modelu ćwiczebnego (np. „Koordynator", „Operator roju"), nie nowe wpisy w rejestrze DID (did:k0nsult:agent:*) systemu — ten rejestr ma dziś 4 agentów LLM (Badacz/Inżynier/Triage/ Syntetyk) opisanych osobno w kodzie orkiestratora. Role symulatora i wpisy DID to dwie różne, nie mieszane ze sobą kategorie.

Co jest LIVE, co jest modelem ćwiczebnym

LIVE (realne narzędzia analityczne K0NSULT): 10 skilli zbrojowni + evidence-package/chain-of-custody + Legal Trigger Engine (decision-support) + wzbogacanie CVE — wszystkie opisane z kodem i testem na roadmapie dev. Sam mechanizm strony (przeliczenie w przeglądarce bez backendu) też jest LIVE — to zwykły, statyczny JS działający na danych wbudowanych w plik.
Model ćwiczebny (ta strona): 12 ról agentów, mapowanie skill→faza, wskaźniki mocy 1-5, sześć scenariuszy i rekomendacje domknięcia luk — to szkielet metodologiczny testowany na scenariuszach syntetycznych, nie wdrożona zdolność obronna ani automatyczny system reagowania na incydenty w produkcji.
„100%"/pełne pokrycie u nas znaczy pokrycie proceduralne, nie nieprzenikalność. Zielony pasek przy 5/5 dla danej fazy oznacza, że model przypisuje tej fazie skill zaprojektowany dokładnie do tego kroku — nie że żaden atak tej fazy nie może się powieść. Rój agentów w tym symulatorze to metoda pracy analitycznej, nie oficjalny rejestr zdolności (rój ≠ rejestr).
Granica etyczna, prawna i instytucjonalna. Ten symulator nie zastępuje CSIRT, CERT, wojska ani służb państwowych i nie jest z nimi formalnie powiązany. Nie stanowi deklaracji gotowości militarnej ani zdolności obronnej państwa. Wszystkie scenariusze, role, skille i wskaźniki mocy są syntetyczne i służą wyłącznie demonstracji metodologii doboru narzędzia obronnego do fazy ataku. Realny incydent zawsze należy zgłaszać właściwym instytucjom (CSIRT NASK, CERT Polska, właściwe służby) — nie temu narzędziu. Wszelkie działania opisane wyżej i w powiązanych materiałach K0NSULT prowadzone są wyłącznie po pisemnych Rules of Engagement, defensywnie, na danych syntetycznych, zero payloadów i instrukcji wykonania ataku.

Powiązane: model dopasowania typ-incydentu→skille → /matcher-incydent · katalog skilli → /zbrojownia-skilli · baza agentów → /koszary-agentow · model sztabu i gotowości → /sztab-obrony · zasady zaangażowania → /engagement · rejestr znanych ograniczeń → /known-limitations.