Scenariusze demo — skrypty pokazu orchestratora

Cztery gotowe skrypty prowadzenia pokazu Evidence & Resilience Orchestrator: od 5-minutowego „hello, hash" po 5-dniowy pilot. Każdy skrypt mówi wprost: co pokazać, które strony/endpointy uruchomić i jaki dowód zostaje po scenariuszu. Wszystko na danych syntetycznych; dane realne dopiero po pisemnych Rules of Engagement (RoE) i NDA/DPA.

Przegląd scenariuszy

Scenariusz 1 — 5-min demo na funkcjach LIVE v1

Cel: w 5 minut pokazać pętlę surowy raport pentestera → znormalizowany incydent → pobieralny pakiet dowodowy → skrót, który widz sam weryfikuje. Zero slajdów — same artefakty.

Co pokazać (skrypt, ~5 min)

1. 0:00 — otwórz /samples, pobierz import-burp-demo.xml (albo import-nessus-demo.csv). To wejście syntetyczne, jawnie oznaczone jako demo.
2. 0:30 — zaimportuj raport: POST /api/ip3/v1/imports/burp. Pokaż, że powstaje incydent z findings i evidence (sha256 + chain-of-custody). Podkreśl regułę: import = MEDIA_SIGNAL, nie dowód naprawy.
3. 2:00 — pobierz pakiet: GET /api/ip3/v1/reports/evidence-package/:id?format=pdf. Otwórz realny PDF (manifest + ślad audytowy + package_sha256).
4. 3:30 — pobierz też wersję JSON (?format=json) i przeklej ją do /verify. Przeglądarka policzy SHA-256 lokalnie (Web Crypto) i porówna z zadeklarowanym skrótem. Zielony werdykt = integralność potwierdzona bez zaufania do serwera.
5. 4:30 — puenta: „to nie jest slajd o dowodzie, to jest dowód". Reguła claim ≤ proof.

Które strony / endpointy

Scenariusz 2 — 30-min demo na funkcjach LIVE v1

Cel: dla CISO / SOC / GRC — pokazać nie tylko import, ale domknięcie cyklu z dowodem naprawy oraz warstwę decyzyjną: obowiązki prawne z zegarami, KPI pokrycia dowodowego i Board Pack dla zarządu.

Co pokazać (skrypt, ~30 min)

1. Import (jak w S1) — POST /api/ip3/v1/imports/*. Incydent w stanie otwartym.
2. Reguła close-with-evidence — spróbuj zamknąć incydent bez dowodu naprawy: POST /api/ip3/v1/incidents/:id/close zwróci 422 (brak CONFIRMED). To celowa bariera — nie da się „odhaczyć" naprawy bez dowodu (audyt F4: PATCH-bypass zamknięty).
3. Retest → CONFIRMED — dodaj dowód retestu (POST /api/ip3/v1/incidents/:id/evidence), potem close przechodzi. Pobierz evidence-package ponownie: inny package_sha256 — pakiet realnie odzwierciedla zmianę stanu.
4. Legal Trigger Engine — GET /api/ip3/v1/incidents/:id/legal-triggers: mapowanie zdarzenia na DORA art.19 / NIS2 (24h/72h) / RODO art.33-34 / AI Act art.73 z zegarami (deadline ISO liczony od created_at) i draftem powiadomienia. Doktryna DECISION-SUPPORT — wsparcie decyzji, nie porada prawna; terminy orientacyjne.
5. Coverage KPI — GET /api/ip3/v1/incidents/:id/coverage: procent pokrycia dowodowego incydentu po wymiarach. Podkreśl doktrynę zaszytą w odpowiedzi: to KPI pokrycia dowodowego, NIE ocena bezpieczeństwa ani gotowości produkcyjnej.
6. Board Pack — evidence-package PDF/JSON (manifest + package_sha256 + ślad audytowy) jako artefakt „na zarząd". Zakończ weryfikacją hasha w /verify.

Które strony / endpointy

Scenariusz 3 — 2h workshop część LIVE v1/MVP, część ROADMAP

Cel: warsztat dla zespołu red/blue + compliance. Pełny cykl z S2 rozszerzony o engagement DORA/TIBER (white-team-log → evidence-register → final-report → report-package), mapowanie MITRE ATT&CK TTP oraz import findings z reverse engineering / analizy malware (defensywnie, po RoE).

Co pokazać (skrypt, ~2h)

1. Blok A — pełny cykl (jak S2): import → close-with-evidence → legal-triggers → coverage → Board Pack. Uczestnicy robią to sami na sample packu.
2. Blok B — DORA/TIBER engagement: załóż engagement (POST /api/ip3/v1/engagements) ze scope / crown-jewels / RoE. Dokładaj wpisy white-team-log (/log) i evidence-register. Wygeneruj final-report (/final-report) — wymaga rejestru dowodów (raport końcowy ≤ rejestr; claim ≤ proof).
3. Blok C — MITRE ATT&CK: GET /api/ip3/v1/incidents/:id/ttp — mapowanie incydentu na techniki ATT&CK (biblioteka offline). Pokaż, jak finding łączy się z taktyką/techniką.
4. Blok D — reverse engineering: import findings z analizy malware/reverse: POST /api/ip3/v1/imports/re (typy: malware, ioc, yara-match, reverse-engineering, unpacked-artifact). Wyłącznie defensywnie i po RoE — zero payloadów, zero instrukcji ofensywnych. Zobacz /reverse.
5. Domknięcie: GET /api/ip3/v1/engagements/:id/report-package — raport TLPT: engagement + timeline zdarzeń + evidence-register + final-report + manifest + package_sha256 (JSON i realny PDF). Weryfikacja skrótu w /verify.

Które strony / endpointy

Scenariusz 4 — 5-day pilot wymaga RoE/NDA/DPA

Cel: dla decydenta w banku/instytucji — od dokumentów po evidence-first case na realnych, ale zanonimizowanych danych i raport feedback. To jedyny scenariusz dotykający danych klienta; warunkiem wejścia są podpisane RoE + NDA + DPA.

Przebieg (5 dni roboczych)

1. Dzień 1 — ramy prawne i zakres. Podpisanie Rules of Engagement + NDA + DPA. Ustalenie scope, crown-jewels, kanałów, ról (white-team). Bez tego pilot nie startuje. Szablon: roe-template.
2. Dzień 2 — dane. Klient dostarcza zanonimizowane raporty (Burp/ZAP/Nessus/Qualys/CSV) lub dane nieprodukcyjne zgodnie z DPA. Import przez konektory v1. Zasady danych: Trust Center.
3. Dzień 3 — evidence-first case. Pełny cykl na danych klienta: import → retest → close-with-evidence → legal-triggers (zegary) → coverage KPI → Board Pack. Opcjonalnie engagement DORA/TIBER + MITRE TTP (jak S3).
4. Dzień 4 — weryfikacja i pakiet. Generacja evidence-package / report-package, samodzielna weryfikacja skrótów przez zespół klienta w /verify. Zestawienie ze status-matrix: co LIVE, co ROADMAP dla ich kontekstu.
5. Dzień 5 — raport feedback. Podsumowanie: pokrycie dowodowe, luki (GAP), rekomendacje, lista „awansów" demo→LIVE dla środowiska klienta. Jawne rozdzielenie tego, co dostarczone, od tego, co pozostaje ROADMAP.

Które strony / endpointy

Mapowanie scenariusz → dowód (podsumowanie)