Ilustracja przepływu ipIII na jednym scenariuszu: od surowego raportu pentestu, przez pakiet dla zarządu (Board Pack), po pakiet dowodowy gotowy do przeglądu prawnego pod DORA. To materiał demonstracyjny — pokazuje mechanikę procesu, nie wynik realnego wdrożenia.
Scenariusz demonstracyjny odtwarza typową sytuację działu bezpieczeństwa dużej instytucji finansowej: zespół pentesterów zamyka testy penetracyjne, wynik trzeba przełożyć na język zrozumiały dla zarządu, a jednocześnie zachować ślad dowodowy na wypadek obowiązku zgłoszenia poważnego incydentu ICT do organu nadzoru. ipIII spina te trzy kroki w jednym łańcuchu, z hashem integralności na każdym etapie.
„Bank Przykładowy S.A." (nazwa fikcyjna, dane demonstracyjne) zleca zewnętrznemu zespołowi pentesterów test aplikacji bankowości internetowej w ramach rutynowego cyklu bezpieczeństwa. Test odbywa się w granicach pisemnych Rules of Engagement, a zakres i harmonogram ustala zespół klienta z pentesterami — ipIII nie inicjuje ani nie wykonuje żadnych czynności testowych. Rola ipIII zaczyna się w momencie, gdy zespół pentesterów dostarcza wynik.
| Parametr scenariusza | Wartość (przykładowa) |
|---|---|
| Instytucja | „Bank Przykładowy S.A." — nazwa syntetyczna, nie realny podmiot fikcyjne |
| Zakres testu | Aplikacja bankowości internetowej (środowisko testowe) przykład |
| Źródło findings | Eksport skanera (format zgodny z parserem Burp/ZAP/Nessus) przykład |
| Liczba findings (przykładowa) | 34 pozycje, w tym 3 krytyczne, 8 wysokich przykładowe liczby |
| Odbiorca Board Pack | CISO + komitet ryzyka (fikcyjne role) przykład |
Punktem wejścia jest plik eksportu ze skanera (np. Burp Suite, OWASP ZAP, Nessus) lub raport CSV od zespołu pentesterów. Konektor importu parsuje i normalizuje findings do wspólnego modelu (tytuł, dotknięty zasób, CVSS/CWE, dowód — zrzut ekranu lub payload), a każdemu rekordowi nadawany jest identyfikator i znacznik czasu importu.
Surowy raport pentestu (dziesiątki stron technicznego żargonu) rzadko trafia bezpośrednio przed zarząd lub komitet ryzyka. Pentest Report → Board Pack przekłada findings na skrót decyzyjny: ile krytycznych/wysokich, jaki jest status naprawy, jakie jest ryzyko rezydualne — w formacie czytelnym dla CISO Board Pack.
34 findings (przykładowe), w tym 3 krytyczne dot. autoryzacji API, 8 wysokich dot. konfiguracji TLS.
Agregacja wg dotkliwości, mapowanie na właścicieli (owner) po stronie klienta, oś czasu naprawy (SLA przykładowe: krytyczne 15 dni, wysokie 30 dni).
Board Pack (1-2 strony): skrót ryzyka, status naprawy, rekomendacja decyzji — z odnośnikiem do pełnego raportu źródłowego i hasha integralności.
Wszystkie liczby w tym kroku (34, 3, 8, 15 dni, 30 dni) są przykładowe — służą wyłącznie ilustracji formatu, nie są wynikiem realnego testu.
W scenariuszu jedno z krytycznych findings (przykładowo: obejście autoryzacji na endpoincie transakcyjnym) zostaje w symulacji podniesione do rangi incydentu bezpieczeństwa — bo w warunkach produkcyjnych (nie w tym środowisku testowym) mogłoby spełniać kryteria „poważnego incydentu ICT" wg DORA art.19. To wyłącznie ćwiczenie klasyfikacyjne w ramach demonstracji, nie zgłoszenie realnego zdarzenia.
Dla findingu podniesionego do rangi incydentu, ipIII generuje szkielet pakietu zgodny z przepływem
DORA Pack: oś czasu raportowania (wstępne / pośrednie / końcowe),
checklist kompletności pól oraz manifest dowodowy — z package_sha256 i chain-of-custody każdego
elementu (finding źródłowy, Board Pack, notatka klasyfikacyjna).
| Element pakietu | Zawartość (przykładowa) | Dowód integralności |
|---|---|---|
| Finding źródłowy | Rekord z importu skanera (krok 1) | sha256 pliku wejściowego |
| Board Pack | Skrót decyzyjny wygenerowany w kroku 2 | package_sha256 pakietu PDF/JSON |
| Notatka klasyfikacyjna | Uzasadnienie progu „major" (do weryfikacji prawnej) | wpis w chain-of-custody (DB) |
| Oś czasu zgłoszenia | Terminy orientacyjne wg art.19 DORA | referencja do DORA Pack |
Pakiet nie trafia automatycznie do organu nadzoru. Zgodnie z zasadą decision-support, ostatnim krokiem w scenariuszu jest przekazanie kompletu (Board Pack + evidence-package + notatka klasyfikacyjna) do przeglądu przez radcę prawnego lub dział compliance instytucji — który podejmuje ostateczną decyzję o zgłoszeniu i jego treści. ipIII przygotowuje materiał do decyzji człowieka, nie zastępuje jej.