To jest plan operacyjny K0NSULT jako operatora ipIII — jak reagujemy, gdy incydent bezpieczeństwa dotyczy naszej własnej infrastruktury lub produktu. To NIE jest opis funkcji produktu do obsługi incydentów klienta (tę rolę pełni moduł Response Board). Poniżej: role, sześć faz, kanał zgłoszeń, powiązanie z obowiązkami notyfikacyjnymi DORA/NIS2.
Plan obejmuje pełny cykl: wykrycie → klasyfikacja → powstrzymanie → usunięcie przyczyny → odtworzenie usługi → wnioski. Kanał zgłoszeń zewnętrznych (security.txt) jest LIVE. Reszta procesu to szkielet organizacyjny wymagający przećwiczenia i podpisania przez osoby odpowiedzialne.
Szkielet ról (RACI uproszczony). Konkretne osoby/dane kontaktowe poza tą stroną publiczną — przypisanie i aktualizacja listy dyżurnej to zadanie operacyjne wymagające człowieka (lista on-call, nie kod).
| Rola | Odpowiedzialność | Kiedy angażowana | Status |
|---|---|---|---|
| Incident Commander (IC) | Właściciel incydentu end-to-end: koordynuje fazy, decyduje o eskalacji, zatwierdza zamknięcie. | Od momentu klasyfikacji jako incydent (SEV1–SEV3). | ROADMAP — rola zdefiniowana, brak formalnego wyznaczenia i zastępstwa 24/7. |
| Security Lead | Analiza techniczna, powstrzymanie, koordynacja z konektorami evidence (import findings, evidence-package). | Detect / Triage / Contain / Eradicate. | ROADMAP — proces manualny, brak dedykowanego zespołu SOC 24/7. |
| Engineering On-Call | Zmiany w kodzie/infrastrukturze, rollback, patch, potwierdzenie naprawy (retest). | Contain / Eradicate / Recover. | ROADMAP — brak formalnego harmonogramu dyżurów. |
| Comms / Legal Liaison | Komunikacja z klientami/partnerami, ocena obowiązków notyfikacyjnych (DORA/NIS2/RODO), kontakt z DPO/prawnikiem. | Triage (klasyfikacja) i każda decyzja o notyfikacji zewnętrznej. | ROADMAP — wymaga przeglądu prawnika/DPO przed każdą notyfikacją, nie automatyzujemy tej decyzji. |
| Reporter (zewnętrzny) | Osoba/podmiot zgłaszający podatność lub incydent przez kanał publiczny. | Detect (zgłoszenie zewnętrzne). | LIVE — kanał security.txt działa, patrz sekcja Kontakt. |
Źródła: zgłoszenie zewnętrzne (security.txt), alert monitoringu infrastruktury, wynik importu skanera (konektory Burp/ZAP/Nessus), zgłoszenie wewnętrzne.
ROADMAP — brak scentralizowanego SIEM/alertingu 24/7 (patrz znane ograniczenia, pozycja SIEM).
Klasyfikacja ważności (SEV1–SEV4, patrz tabela niżej), wstępna ocena wpływu (dane, dostępność, integralność) i wstępna ocena obowiązku notyfikacyjnego.
ROADMAP — kryteria SEV zdefiniowane niżej, brak automatycznego triage.
Ograniczenie zasięgu: izolacja komponentu, rotacja sekretów/kluczy, tymczasowe wyłączenie dotkniętej funkcji, blokada dostępu.
ROADMAP — proces manualny, brak automatycznego kill-switcha.
Usunięcie przyczyny źródłowej: patch, poprawka konfiguracji, unieważnienie skompromitowanych poświadczeń.
ROADMAP — brak zdefiniowanego SLA napraw per SEV.
Przywrócenie usługi, weryfikacja poprawności (retest — funkcja response-retest jest
LIVE na poziomie produktu dla incydentów klientów), monitorowanie po incydencie.
ROADMAP — dla incydentów własnej infrastruktury K0NSULT proces recovery jest dziś manualny.
Post-mortem bez obwiniania (blameless), aktualizacja rejestru znanych ograniczeń, decyzja o zmianach w planie.
ROADMAP — brak jeszcze przećwiczonego cyklu post-mortem na żywym incydencie.
Robocza klasyfikacja wewnętrzna. To nie jest formalna kwalifikacja regulacyjna „incydentu poważnego" w rozumieniu DORA ani „incydentu istotnego" w rozumieniu NIS2 — tę kwalifikację wykonuje Comms/Legal Liaison z udziałem prawnika/DPO, w oparciu o kryteria właściwe dla danego obowiązku.
| SEV | Opis | Przykład | Cel reakcji (orientacyjny) |
|---|---|---|---|
| SEV1 | Krytyczny: utrata poufności/integralności danych, pełna niedostępność usługi, potencjalne naruszenie RODO. | Wyciek danych klienta, kompromitacja poświadczeń administracyjnych. | ROADMAP — cel do ustalenia i podpisania przez IC; orientacyjnie: reakcja w godzinach. |
| SEV2 | Wysoki: częściowa niedostępność, podatność krytyczna bez potwierdzonej eksploatacji. | Krytyczne CVE w komponencie z dostępem do produkcji. | ROADMAP — orientacyjnie: reakcja w ciągu dnia roboczego. |
| SEV3 | Średni: ograniczony wpływ, brak utraty danych, funkcjonalność zdegradowana. | Błąd konfiguracji bez ekspozycji danych. | ROADMAP — orientacyjnie: reakcja w kolejnym sprincie. |
| SEV4 | Niski: obserwacja, brak wpływu na produkcję. | Zgłoszenie teoretycznego ryzyka bez wektoru ataku. | ROADMAP — do backlogu. |
security@k0nsult.cloud · plik zgodny z RFC 9116:
/.well-known/security.txt ·
polityka ujawniania: /ai-truth/ipIII/disclosure ·
LIVE
Zgłoszenie zewnętrzne (podatność, incydent, obserwacja) trafia do fazy Detect tego planu. Preferowane języki: polski, angielski. Uznania badaczy: bug-bounty. Zasady zaangażowania dla testów bezpieczeństwa: Rules of Engagement — bez pisemnej autoryzacji nie prowadzimy ani nie akceptujemy testów ofensywnych na produkcji.
K0NSULT jako dostawca ipIII może występować jako podmiot ICT trzeciej strony w rozumieniu DORA (dla klientów finansowych) oraz podlegać obowiązkom NIS2 jako dostawca usług cyfrowych/ICT. Poniżej — orientacyjny szkielet terminów zgłoszeniowych, do potwierdzenia z prawnikiem dla każdej relacji kontraktowej.
| Ramy | Etap notyfikacji | Orientacyjny termin | Status wsparcia w ipIII |
|---|---|---|---|
| DORA | Wczesne powiadomienie (initial) | Bez zbędnej zwłoki po klasyfikacji jako incydent poważny | LIVE (draft) — Legal Trigger Engine generuje draft; wysyłka i kwalifikacja wymagają decyzji człowieka (prawnik/DPO/IC), patrz Legal Engine. |
| DORA | Raport pośredni / końcowy | Zgodnie z harmonogramem regulacyjnym (nie automatyzujemy tej oceny) | ROADMAP — szkielet szablonu; treść merytoryczna zawsze do przeglądu prawnika. |
| NIS2 | Wczesne ostrzeżenie | Orientacyjnie 24h od powzięcia wiedzy o incydencie istotnym | ROADMAP — kwalifikacja „incydentu istotnego" nie jest zautomatyzowana. |
| NIS2 | Powiadomienie o incydencie | Orientacyjnie 72h od powzięcia wiedzy | ROADMAP. |
| NIS2 | Raport końcowy | Orientacyjnie 1 miesiąc od powiadomienia | ROADMAP. |
Szerszy kontekst mapowania DORA/TIBER-EU na cykl testów i dowodów: /ai-truth/ipIII/dora-tiber.
Powiązane: rejestr znanych ograniczeń → /known-limitations · polityka ujawniania podatności → /disclosure · centrum zaufania → /trust-center · moduł produktu do incydentów klienta → /response-board.