Czy ten case study opisuje realny alert wykryty u klienta ipIII?

Nie. Alert, sygnatura, nazwa zespołu SOC oraz wszystkie znaczniki czasowe są w całości syntetyczne. Scenariusz ilustruje wyłącznie przepływ pracy w ipIII: od alertu, przez zebranie evidence, remediację, po retest — nie odnosi się do żadnej rzeczywistej organizacji ani zdarzenia.

Czy ipIII samo naprawia podatność albo wykonuje retest ofensywny?

Nie. ipIII nie wykonuje żadnych działań ofensywnych ani automatycznej naprawy w systemach produkcyjnych. Remediacja jest zadaniem właściciela systemu (dev/ops), a retest to ponowny import wyniku skanera lub potwierdzenie przez pentestera — ipIII rejestruje status i domyka dowodowo cykl closed-with-evidence.

Skąd biorą się czasy pokazane w tym case study (np. czas do evidence-package czy retestu)?

To wartości przykładowe, dobrane wyłącznie żeby zilustrować kolejność kroków przepływu SOC w ipIII. Nie pochodzą z pomiaru u żadnego klienta, nie stanowią gwarantowanego czasu reakcji ani SLA.

Czy przepływ pokazany w tym case study jest gotowy do wdrożenia w banku bez zmian?

Nie w pełni. Mechanika przepływu (import alertu, evidence-package, śledzenie remediacji, retest, coverage score) jest dziś dowodliwa (LIVE) w środowisku demo, ale integracje enterprise takie jak mTLS, wielodostępność czy formalne podpisy dokumentów pozostają na roadmapie — patrz rejestr znanych ograniczeń.

k0nsult.cloud / ai-truth / ipIII / orchestrator / case-study-soc

Case study SOC (syntetyczny): alert → evidence → remediacja → retest

Poniższy scenariusz jest w całości fikcyjny. Zespół SOC, alert, sygnatura zdarzenia i wszystkie metryki czasowe nie istnieją i nie odnoszą się do żadnego rzeczywistego podmiotu ani zdarzenia. Case study ilustruje wyłącznie przepływ pracy w ipIII — od przyjęcia alertu z konektora skanera, przez zebranie evidence i śledzenie remediacji, po retest i domknięcie z dowodem (closed-with-evidence). To nie jest referencja klienta ani opis realnego incydentu.

Dla SOC Remediacja Coverage score Response board Znane ograniczenia Case study SOC ← ipIII hub

Dlaczego to jest fikcja, a nie referencja. ipIII buduje evidence dla realnych zespołów SOC, ale nie publikujemy ich alertów, ticketów ani wyników bez zgody. Ten case study zastępuje realną referencję ilustracją tego samego przepływu na w pełni wymyślonych danych — żeby pokazać mechanikę narzędzia bankowi, audytorowi czy regulatorowi bez naruszania poufności jakiejkolwiek strony trzeciej.

Scenariusz (fikcyjny)

SOC „Zespół Wachta-3" — wymyślona nazwa zespołu operacyjnego, w scenariuszu monitoruje syntetyczne środowisko testowe. Skaner DAST (fikcyjny wynik) zgłasza alert klasy „ujawnienie nagłówka autoryzacyjnego" na testowym endpoincie API. Analityk pierwszej linii importuje wynik skanera do ipIII przez konektor — patrz Dla SOC. Alert zostaje przekształcony w incydent z przypisanym identyfikatorem, priorytetem i wstępną klasyfikacją ryzyka, widoczny na Response board.

PRZEPŁYW (ilustracyjny): alert skanera→import do ipIII→incydent + evidence→przypisanie remediacji→retest→closed-with-evidence

Krok po kroku — co dzieje się w ipIII

Krok	Co ilustruje ten krok	Artefakt dowodowy (przykładowy)	Status w ipIII
1. Alert i import	Fikcyjny wynik skanera DAST trafia do parsera i zostaje znormalizowany do wspólnego formatu incydentu — patrz Dla SOC.	Rekord incydentu z ID, timestamp, źródło	LIVE (parser + import)
2. Zebranie evidence	Wszystkie artefakty (surowy wynik skanera, kontekst endpointu, notatka analityka) są pakowane w evidence-package z sumą kontrolną i chain-of-custody.	`package_sha256` + manifest	LIVE
3. Przypisanie remediacji	Incydent jest przypisany do właściciela systemu z priorytetem i orientacyjnym terminem naprawy — śledzone jako zadanie, nie jako automatyczna naprawa. Patrz Remediacja.	Ticket remediacji ze statusem i właścicielem	LIVE (śledzenie statusu)
4. Widoczność na tablicy	Status incydentu — od „nowy" po „w remediacji" — jest widoczny dla całego zespołu SOC i przełożonych na jednej tablicy. Patrz Response board.	Wpis na tablicy statusów z historią zmian	LIVE
5. Retest	Po zgłoszeniu naprawy przez właściciela systemu, wynik ponownego skanu (lub potwierdzenie pentestera) jest importowany jako retest tego samego incydentu.	Powiązany rekord retestu + porównanie ze stanem wyjściowym	LIVE (retest linkage)
6. Closed-with-evidence	Incydent zostaje zamknięty tylko wtedy, gdy retest potwierdza naprawę — z pełnym śladem dowodowym od alertu do zamknięcia. Wkład w zagregowany wskaźnik pokrycia — patrz Coverage score.	Status „closed" + kompletny łańcuch dowodowy	LIVE

Metryki (przykładowe, ilustracyjne — nie pomiar realny)

Poniższe liczby ilustrują wyłącznie kolejność i względne proporcje kroków w demonstracyjnym scenariuszu. Nie pochodzą z żadnego wdrożenia produkcyjnego i nie stanowią obietnicy czasu reakcji ani SLA.

~8 min

alert → incydent w ipIII

wartość przykładowa scenariusza

~20 min

incydent → evidence-package

wartość przykładowa scenariusza

~4 dni

remediacja → retest (fikcyjny)

zależne od zasobów zespołu, nie od ipIII

kroków przepływu w tym scenariuszu

ilustracja, nie SLA

Co jest realne, a co ilustracyjne

Realne (LIVE, z kodem/testem/endpointem): mechanika przepływu — import parserów skanerów, budowa incydentu, evidence-package z sumą kontrolną, śledzenie statusu remediacji, powiązanie retestu z pierwotnym incydentem, zamknięcie closed-with-evidence oraz wkład do zagregowanego wskaźnika pokrycia. Te elementy działają dziś w środowisku demo na danych syntetycznych.

Ilustracyjne (nie realne): nazwa zespołu „Wachta-3", opisany alert, konkretny endpoint, wszystkie metryki czasowe i treść ticketów w tym case study. Służą wyłącznie pokazaniu, jak wygląda wynik działania narzędzia — nie są dowodem wdrożenia u klienta.

Granice i przegląd człowieka

ipIII nie działa ofensywnie i nie zastępuje SOC. Narzędzie nie wykonuje skanów, exploitacji ani „retestu" w rozumieniu ofensywnym — retest w ipIII to rejestracja i powiązanie ponownego wyniku skanera lub potwierdzenia pentestera, nie samodzielna akcja atakująca. Decyzje o priorytecie, akceptacji ryzyka rezydualnego i zamknięciu incydentu podejmuje człowiek — analityk SOC lub jego przełożony. Więcej o granicach systemu — rejestr znanych ograniczeń.

Powiązane: strona wejściowa dla zespołów SOC → /landing-soc · śledzenie remediacji → /remediation · zagregowany wskaźnik pokrycia dowodowego → /coverage-score · tablica statusów incydentów → /response-board.