k0nsult.cloud / Common-Source-of-Truth / playbooks

Playbooki incydentów

Procedury reagowania K0-CST dla sześciu klas incydentów bezpieczeństwa. Każdy playbook definiuje pierwsze 15 minut, rozpoznanie, powstrzymanie, obowiązki prawne oraz przypisanie dowodu i ownera. Żadna akcja bez ownera. Żaden zarzut bez dowodu.

No action without owner. No blame without evidence.

Playbooki K0-CST są procedurami operacyjnymi — nie zastępują audytu, certyfikacji ani porady prawnej. Każdy incydent wymaga weryfikacji triggerów regulacyjnych w Regulatory Trigger Engine.

Zasada ogólna: każdy incydent zgłoś przez /Common-Source-of-Truth/report/incident niezwłocznie po wykryciu. Nie czekaj na pełne rozpoznanie — zgłoś to co wiesz, uzupełnij później.

1. Phishing / spear-phishing

Atak socjotechniczny e-mail / SMS / chat mający na celu wyłudzenie danych uwierzytelniających, instalację złośliwego oprogramowania lub przekierowanie płatności.

Pierwsze 15 minut

Izolacja skrzynki / konta

Zawieś dostęp do konta, które kliknęło link lub podało dane. Zresetuj hasło i sesje OAuth. NIE usuwaj wiadomości.

Zebranie dowodów

Zapisz nagłówki e-mail (full headers), URL ataku, zrzuty ekranu. Przypisz evidence_id: EVD-PHI-YYYYMMDD-NNN.

Powiadomienie ownera incydentu

Wskaż jedną osobę odpowiedzialną (owner). Powiadom CISO lub osobę pełniącą tę funkcję w ciągu 30 minut od wykrycia.

Triage: zasięg i wektor

Sprawdź logi — czy inne konta kliknęły ten sam link? Czy doszło do exfiltracji danych? Oceń: incydent lokalny vs. systemowy.

Zgłoszenie wstępne

Otwórz ticket w /report/incident ze statusem TRIAGE. Dołącz evidence_id.

Rozpoznanie — sygnały i wskaźniki

Wiadomość e-mail z domeną podobną do zaufanej (homoglyph, typosquatting)
Nieoczekiwane linki do stron logowania, reset hasła, faktur
Załączniki .htm/.html otwierające fałszywą stronę logowania
Nieoczekiwana zmiana hasła lub MFA bez inicjatywy użytkownika
Alert z systemu e-mail o nowym urządzeniu / lokalizacji
Zgłoszenie użytkownika: "dostałem dziwny e-mail"

Powstrzymanie i eradykacja

Zablokuj domenę atakującą na poziomie DNS/firewall/e-mail gateway
Usuń wiadomość phishingową ze wszystkich skrzynek w organizacji (po skopiowaniu dowodów)
Wymuś reset haseł dla wszystkich kont, które otrzymały wiadomość
Sprawdź reguły przekierowania e-mail — atakujący często je ustawiają
Weryfikacja integralności kont uprzywilejowanych

Obowiązki prawne:
Jeśli w wyniku phishingu doszło do naruszenia danych osobowych (przejęcie konta z danymi klientów/pracowników):

RODO art. 33 — zgłoszenie do UODO w ciągu 72 godzin od stwierdzenia naruszenia
RODO art. 34 — powiadomienie osób fizycznych, jeśli wysokie ryzyko
NIS2 — jeśli incydent wpływa na ciągłość usług istotnych: wczesne ostrzeżenie 24h, pełne zgłoszenie 72h

Sprawdz triggery w Regulatory Trigger Engine ›

Owner + dowód:
Owner: CISO / wyznaczony Security Lead.
Archiwizuj: nagłówki e-mail, URL (nie klikaj — zaarchiwizuj), zrzuty ekranu, logi dostępu, evidence_id z tikseta incydentu.
Zamknięcie playbooka: pisemne potwierdzenie ownera po eradykacji + weryfikacji braku persystencji.

2. Ransomware

Złośliwe oprogramowanie szyfrujące dane lub systemy w celu wymuszenia okupu. Może obejmować exfiltrację danych przed szyfrowaniem (double extortion).

Pierwsze 15 minut

Natychmiastowa izolacja sieciowa

Odłącz zainfekowany system od sieci (wyłącz Wi-Fi, odepnij kabel). NIE wyłączaj komputera — pamięć RAM może zawierać klucze deszyfrujące.

Zebranie dowodów (memory dump jeśli możliwe)

Zrzut pamięci RAM zainfekowanego hosta. Zrzuty ekranu żądania okupu. evidence_id: EVD-RNS-YYYYMMDD-NNN.

Powiadomienie ownera i zarządu

Natychmiastowe powiadomienie CISO + CEO/COO. Ransomware = incydent P0 — eskalacja bez zwłoki.

Identyfikacja zasięgu — lateral movement

Sprawdź logi sieciowe — ile systemów jest zainfekowanych? Czy backupy są dostępne i nienaruszone?

Decyzja: izolacja vs. shutdown

Owner decyduje: izolować więcej systemów, całkowite odcięcie segmentu sieci, czy shutdown? NIE płać okupu bez porady prawnej.

Rozpoznanie — sygnały i wskaźniki

Pliki z nieznanym rozszerzeniem (.locked, .encrypted, losowe sufiksy)
Plik README z instrukcją płatności na pulpicie lub w katalogach
Wysokie użycie CPU/dysku bez uzasadnienia — trwa szyfrowanie
Alert EDR / antywirus o podejrzanym procesie
Brak dostępu do współdzielonych zasobów sieciowych
Shadow copies usunięte (vssadmin delete shadows)

Powstrzymanie i eradykacja

Izoluj wszystkie zainfekowane segmenty sieci
Zidentyfikuj wektor wejścia (phishing, RDP, podatność) i zablokuj go
Weryfikuj integralność backupów — offline backup jako priorytet odtworzenia
NIE płać okupu bez pisemnej rekomendacji prawnika i analizy ryzyka
Odtworzenie z czystych obrazów po potwierdzeniu eradykacji malware
Zidentyfikuj i usuń persistence mechanisms (scheduled tasks, registry keys)

Obowiązki prawne:

NIS2 — ransomware na systemach krytycznych: wczesne ostrzeżenie 24h, zgłoszenie 72h, raport końcowy 30 dni
RODO art. 33/34 — jeśli doszło do exfiltracji danych osobowych: zgłoszenie UODO 72h
Dokumentuj decyzję w sprawie ewentualnej płatności — może mieć implikacje prawne (sankcje, AML)

Sprawdz triggery w Regulatory Trigger Engine ›

Owner + dowód:
Owner: CISO (incydent P0), wsparcie: zewnętrzny DFIR jeśli dostępny.
Archiwizuj: memory dump, żądanie okupu, logi sieci, listę zaszyfrowanych plików, log decyzji (płacić / nie płacić), dowód przywrócenia z backupu.
evidence_id z prefiksem EVD-RNS.

3. DDoS (Distributed Denial of Service)

Atak polegający na przeciążeniu infrastruktury sieciowej lub aplikacyjnej w celu uniemożliwienia dostępu do usług.

Pierwsze 15 minut

Potwierdzenie ataku — nie błąd

Sprawdź monitoring (uptime, ruch sieciowy). Potwierdź że to DDoS, nie awaria infrastruktury. evidence_id: EVD-DDS-YYYYMMDD-NNN.

Aktywacja ochrony upstream / scrubbing

Skontaktuj się z dostawcą (Cloudflare, CDN, ISP) i aktywuj tryb ochrony DDoS. Jeśli Fly.io / cloud — eskaluj do ich wsparcia.

Powiadomienie ownera i zebranie próbek ruchu

Owner: DevOps / SRE Lead. Zbierz próbki logów (IP, User-Agent, wzorzec żądań). Nie przeprowadzaj czyszczenia logów przed zebraniem dowodów.

Triage: volumetric vs. aplikacyjny

Volumetric (bandwidth saturation) vs. Layer 7 (HTTP flood, Slowloris). Różne mitygacje — ustal typ przed wdrożeniem.

Rozpoznanie — sygnały i wskaźniki

Nagły wzrost ruchu sieciowego 10×–1000× normalnego poziomu
Timeouty i błędy 503/504 dla użytkowników
Żądania z jednego lub wąskiego zakresu IP (volumetric) lub z szerokiego zakresu (botnet)
Anomalne User-Agenty lub brak User-Agenta w żądaniach HTTP
Alert z systemu monitoringu (uptime robot, Prometheus, Grafana)

Powstrzymanie i eradykacja

Rate limiting na poziomie edge / CDN — agresywny threshold podczas ataku
Blokada atakujących ASN lub regionów geograficznych (geo-blocking) tymczasowo
CAPTCHA challenge dla ruchu HTTP jeśli atak aplikacyjny
Failover na mirror/backup infrastruktury jeśli dostępny
Po ustaniu ataku: analiza wzorca i aktualizacja reguł WAF

Obowiązki prawne:

NIS2 — jeśli atak wpłynął na dostępność usług istotnych lub ważnych: wczesne ostrzeżenie 24h, zgłoszenie 72h
Zawiadom CERT Polska (cert.pl) — DDoS na polską infrastrukturę warto zgłaszać niezależnie od NIS2
Zachowaj logi ruchu jako dowody (mogą być potrzebne do zgłoszenia na Policję / CSIRT)

Sprawdz triggery w Regulatory Trigger Engine ›

Owner + dowód:
Owner: SRE / DevOps Lead.
Archiwizuj: logi ruchu (próbki reprezentatywne), zrzuty z dashboardu monitoring, komunikację z dostawcą CDN/ISP, timeline mitygacji.
evidence_id z prefiksem EVD-DDS.

4. Wyciek danych osobowych / poufnych

Nieautoryzowane ujawnienie, utrata lub dostęp do danych osobowych lub poufnych informacji K0NSULT lub klientów.

Pierwsze 15 minut

Zamknięcie wycieku — natychmiastowe

Zablokuj nieautoryzowany dostęp (endpoint, konto, podatność). Nie daj atakującemu więcej czasu. evidence_id: EVD-BRH-YYYYMMDD-NNN.

Zebranie dowodów przed zamknięciem

Screenshot, log dostępów, lista wyciekłych rekordów jeśli możliwa do ustalenia. NIE modyfikuj logów — muszą być nienaruszone.

Powiadomienie IOD (Inspektora Ochrony Danych)

Natychmiastowe powiadomienie IOD lub osoby pełniącej tę funkcję. Zegar 72h RODO zaczyna biec od momentu stwierdzenia naruszenia.

Triage: zakres i kategorie danych

Jakie dane wyciekły (kategorie RODO: zwykłe / szczególne)? Ile osób? Czy dane są publicznie dostępne? Czy naruszenie jest poważne?

Decyzja o zgłoszeniu do UODO

IOD lub administrator danych decyduje czy naruszenie wymaga zgłoszenia do UODO (art. 33 RODO). Domyślnie: zgłaszamy jeśli mamy wątpliwości.

Rozpoznanie — sygnały i wskaźniki

Alert systemu DLP o transferze danych poza organizację
Dane K0NSULT / klientów opublikowane na pastebin, dark web, forum
Nieautoryzowane zapytania do bazy danych (SQL injection, API abuse)
Zgłoszenie klienta / pracownika o otrzymaniu cudzych danych
Błędna konfiguracja S3/GCS bucket (public access)
Zgubiony lub skradziony nośnik z danymi

Powstrzymanie i eradykacja

Zamknij wektor wycieku (patch, revoke token, zamknij publiczny bucket)
Ustal kompletną listę wyciekłych rekordów — jeśli niemożliwe, przyjmij worst case
Jeśli dane są na zewnątrz — rozważ żądanie usunięcia (w ograniczonym zakresie skuteczne)
Wzmocnij kontrolę dostępu do baz danych
Audyt pozostałych zasobów danych — czy to był izolowany incydent?

Obowiązki prawne:

RODO art. 33 — zgłoszenie naruszenia do UODO w ciągu 72 godzin od stwierdzenia (chyba że naruszenie nie stanowi ryzyka dla osób fizycznych)
RODO art. 34 — powiadomienie osób, których dotyczy naruszenie, jeśli wysokie ryzyko dla ich praw i wolności
RODO art. 30 — wpis do rejestru naruszeń (obowiązkowy nawet gdy nie zgłaszamy do UODO)
NIS2 — jeśli naruszenie dotyczy systemu kluczowego: triggery 24h/72h
Kara UODO: do 4% globalnego obrotu lub 20 mln EUR (wyższa z kwot)

Sprawdz triggery w Regulatory Trigger Engine ›

Owner + dowód:
Owner: IOD / Administrator Danych Osobowych.
Archiwizuj: lista wyciekłych rekordów (lub oszacowanie), logi dostępu, timeline incydentu, treść zgłoszenia do UODO (kopia), decyzja o powiadomieniu osób, dowód zamknięcia wektora.
evidence_id z prefiksem EVD-BRH (breach).

5. Supply chain (atak na łańcuch dostaw)

Kompromitacja poprzez zaufanego dostawcę, bibliotekę open source, pipeline CI/CD lub integrację zewnętrzną (SolarWinds, XZ Utils, typosquatting npm/PyPI).

Pierwsze 15 minut

Identyfikacja skompromitowanego komponentu

Która biblioteka / dostawca / pipeline? Zidentyfikuj wersję i zakresy użycia w K0NSULT. evidence_id: EVD-SCH-YYYYMMDD-NNN.

Izolacja / pin wersji / rollback

Zablokuj aktualizację do skompromitowanej wersji. Pinuj poprzednią bezpieczną wersję w lock file. Nie deployuj do czasu wyjaśnienia.

Powiadomienie ownera — Dev Lead / CTO

Eskaluj do osoby odpowiedzialnej za dependency management. Jeśli pipeline CI/CD — zatrzymaj wszystkie buildy.

Triage: czy skompromitowany komponent był uruchomiony na prod?

Sprawdź historię deployów. Jeśli tak — oceń co mógł zrobić (exfiltracja, backdoor, crypto miner). Worst-case assumption.

Rozpoznanie — sygnały i wskaźniki

Publiczne CVE / advisory dla używanej biblioteki lub narzędzia
Powiadomienie CERT / GitHub Security Advisory
Anomalny ruch sieciowy z procesu aplikacyjnego (callback do zewnętrznego IP)
Nieoczekiwana zmiana kodu w upstream repo (modyfikacja bez PR / review)
Skasowanie konta maintainera i nowy publish nieznanej osoby
Alert SAST/SCA w pipeline CI/CD o podejrzanym pakiecie

Powstrzymanie i eradykacja

Zastąp skompromitowany komponent bezpieczną alternatywą lub pinowaną poprzednią wersją
Audyt wszystkich systemów, na których komponent był uruchomiony
Zmień wszystkie sekrety / tokeny dostępne dla skompromitowanego procesu
Wdróż SCA (Software Composition Analysis) do pipeline CI/CD — prewencja
Przegląd polityki pinowania zależności i lock files

Obowiązki prawne:

NIS2 / KSC — jeśli incydent wpłynął na ciągłość usług istotnych: triggery 24h/72h
AI Act art. 9 — jeśli skompromitowany komponent był częścią systemu AI wysokiego ryzyka: wymagane zgłoszenie do organu nadzoru
RODO — jeśli backdoor umożliwił dostęp do danych osobowych: triggery naruszenia RODO
Przegląd umów z dostawcami — klauzule SLA i odpowiedzialności za incydenty supply chain

Sprawdz triggery w Regulatory Trigger Engine ›

Owner + dowód:
Owner: Dev Lead / CTO.
Archiwizuj: lista dotkniętych komponentów i wersji, historia deployów (kiedy skompromitowana wersja była na prod), log zmian w lock files, dowód rollbacku / zastąpienia, komunikacja z dostawcą / maintainerem.
evidence_id z prefiksem EVD-SCH.

6. Prompt injection / atak na system AI

Atak polegający na manipulacji modelem językowym poprzez złośliwe instrukcje w danych wejściowych (direct injection) lub treści zewnętrznej (indirect injection), w celu ominięcia guardrails, wycieku danych lub wykonania nieautoryzowanych akcji.

Pierwsze 15 minut

Zebranie dowodów — prompt i response

Zachowaj pełny prompt (input), odpowiedź modelu, kontekst systemowy. NIE czyść logów. evidence_id: EVD-PRI-YYYYMMDD-NNN.

Ocena skutków — co model zrobił?

Czy ujawnił dane systemowe / inne użytkowniki? Czy wykonał nieautoryzowane akcje (tool calls, API calls)? Oceń zakres szkody.

Powiadomienie ownera systemu AI

Owner: AI Product Lead / CTO. Jeśli system AI przetwarza dane osobowe — powiadom też IOD.

Tymczasowe wyłączenie lub ograniczenie funkcji

Jeśli wektor jest aktywny i exploitowalny — rozważ wyłączenie dotkniętej funkcji AI do czasu wdrożenia patcha.

Rozpoznanie — sygnały i wskaźniki

Odpowiedź modelu zawiera dane systemowego promptu (system prompt leakage)
Model wykonał działanie spoza zakresu autoryzowanego (nieautoryzowany tool call)
Użytkownik zgłosił że model "zachowuje się inaczej" / wykonuje dziwne polecenia
Log tool calls zawiera nieoczekiwane wywołania zewnętrznych API lub funkcji
Dane innego użytkownika pojawiły się w odpowiedzi (cross-user contamination)
Model ignoruje instrukcje systemowe po wprowadzeniu specyficznego inputu

Powstrzymanie i eradykacja

Wdróż input sanitization — filtrowanie instrukcji w danych wejściowych
Wzmocnij system prompt — explicit guardrails, privilege separation
Ogranicz tool calls — zasada least privilege dla agentów AI
Wdróż output filtering — wykrywanie wycieku danych w odpowiedziach modelu
Przegląd RAG / kontekstu zewnętrznego pod kątem indirect injection
Audyt logów — czy atak był izolowany czy kampania?

Obowiązki prawne:

AI Act art. 9 — systemy AI wysokiego ryzyka: obowiązek zarządzania ryzykiem i logowania incydentów; incydenty poważne zgłaszane do organu nadzoru (art. 73)
AI Act art. 62 — dostawcy modeli ogólnego przeznaczenia (GPAI): obowiązek zgłoszenia poważnych incydentów Komisji Europejskiej
RODO — jeśli prompt injection spowodował wyciek danych osobowych: triggery art. 33/34 (72h UODO)
NIS2 — jeśli system AI jest częścią infrastruktury krytycznej: standardowe triggery NIS2
Dokumentuj jako incydent bezpieczeństwa AI — wymagane przez AI Act do rejestru zdarzeń

Sprawdz triggery w Regulatory Trigger Engine ›

Owner + dowód:
Owner: AI Product Lead / CTO, wsparcie IOD jeśli dotknięte dane osobowe.
Archiwizuj: pełny prompt (input), odpowiedź modelu, logi tool calls, system prompt (redacted jeśli poufny — ale zachowaj oryginal), timeline incydentu, dowód wdrożenia mitygacji.
evidence_id z prefiksem EVD-PRI.

Zgłoszenie incydentu: każdy incydent zgłoś przez /Common-Source-of-Truth/report/incident niezwłocznie po wykryciu. Nie czekaj na pełne rozpoznanie ani na zamknięcie incydentu. Zgłoszenie wstępne (status TRIAGE) jest wystarczające — uzupełniaj w miarę postępu.

Reguła K0-CST: No action without owner. No blame without evidence.
Każda akcja podjęta w ramach playbooka musi mieć wskazanego ownera i musi być udokumentowana w tiksecie incydentu z przypisanym evidence_id. Działania bez dokumentacji nie są uznawane za podjęte w procedurze K0-CST.

Tabela przeglądowa — triggery regulacyjne

Playbook	RODO (72h UODO)	NIS2 (24h/72h)	AI Act	evidence_id prefix
Phishing	Jeśli wyciek danych osobowych	Jeśli usługi istotne	—	`EVD-PHI`
Ransomware	Jeśli exfiltracja danych	Tak (systemy krytyczne)	—	`EVD-RNS`
DDoS	Rzadko	Jeśli wpływ na dostępność	—	`EVD-DDS`
Wyciek danych	Tak — zawsze ocenić	Jeśli systemy krytyczne	—	`EVD-BRH`
Supply chain	Jeśli dostęp do danych	Jeśli ciągłość usług	Art. 9 (sys. AI HR)	`EVD-SCH`
Prompt injection	Jeśli wyciek danych osobowych	Jeśli infrastruktura krytyczna	Art. 9, 62, 73	`EVD-PRI`

Zastrzeżenie. Playbooki K0-CST mają charakter operacyjno-procedurowy i informacyjny. Nie stanowią certyfikacji, nie są opinią jednostki notyfikowanej ani konkluzją prawną (not a certification · not a notified body · not a legal conclusion). Obowiązki prawne należy każdorazowo weryfikować z prawnikiem i w Regulatory Trigger Engine. Wersje playbooków podlegają aktualizacji — zawsze stosuj bieżącą wersję.