Playbook N — zagrożenie wewnętrzne (insider threat)
Wykrywanie, ograniczanie i obsługa ryzyk pochodzących od pracownika, kontraktora lub konta wewnętrznego — nieumyślnych, zaniedbujących, złośliwych albo przejętych przez atakującego. Priorytet zmienny P1–P0 zależnie od zasięgu danych i statusu konta (aktywne / leaver). Metodyka decision-support, obsługa pracownicza wymaga zawsze ścieżki Legal/HR.
Pozycjonowanie — czym ten playbook NIE jest. To nie jest narzędzie inwigilacji ani automatyczny osąd winy pracownika.
Playbook opisuje sygnały, progi i procedurę reakcji na zdarzenia obejmujące konta wewnętrzne — z wymogiem ścieżki
Legal/HR przy każdym kroku dotykającym konkretnej osoby. Monitoring musi być zgodny z prawem pracy, RODO i regulaminem
pracy obowiązującym u odbiorcy. ipIII wiąże dowody (logi, sygnały, decyzje) — nie zastępuje polityki personalnej
ani orzeczenia dyscyplinarnego. Doktryna claim ≤ proof.
Insider threat to rzadko „zły pracownik" — najczęściej błąd, nadużyte uprawnienie albo przejęte konto.
Model zagrożenia obejmuje cztery typy insidera: nieumyślny (błąd), zaniedbujący (ignoruje politykę), złośliwy (celowe działanie) i przejęty (konto pracownika użyte przez atakującego zewnętrznego). Rozróżnienie typu wpływa na priorytet i ścieżkę eskalacji, ale reakcja techniczna na wczesnym etapie jest podobna: zabezpiecz dowód, ogranicz zasięg, zachowaj custody.
Model zagrożenia — typy insidera
| Typ | Przykład | Ryzyko |
|---|
| Nieumyślny | wysyła dane wrażliwe na prywatny mail lub dysk | wyciek danych bez złej woli |
| Zaniedbujący | ignoruje MFA/VPN/politykę, zapisuje hasła jawnie | kompromitacja konta |
| Złośliwy | kopiuje repozytoria lub bazy przed odejściem | kradzież własności intelektualnej |
| Przejęty | konto pracownika użyte przez zewnętrznego atakującego | lateral movement, eskalacja uprawnień |
Większość zarejestrowanych incydentów insider w branży obejmuje błędy i nadużycia uprawnień, nie z góry złą wolę PUBLIC CLAIM — dlatego reguły detekcji poniżej celują w sygnał, nie w domniemanie motywu.
Minimalna architektura kontroli
[Identity/HR] ──> [IAM/PAM] ──> [Apps/SaaS/Repo/DB]
│ │ │
│ └── logi ─────────┤
│ ▼
└──────────────> [SIEM/UEBA] <── [EDR/DLP/CASB]
│
▼
[SOAR / playbooki IR]
IAM
Logowania, MFA, zmiany ról, tokeny API.
HR
Zatrudnienie, zmiana roli, okres wypowiedzenia, odejścia (leaver).
Repozytoria
Clone, fork, export, tworzenie tokenów dostępowych.
DLP/CASB
Uploady, maile, dyski chmurowe, transfer poza organizację.
EDR
Masowe kopiowanie, archiwizacja, nośniki USB.
PAM
Sesje administratorów, komendy, dostęp do sekretów.
Sygnały wysokiego ryzyka
- Masowy eksport danych w krótkim czasie.
- Nietypowe logowanie — nowy kraj, nietypowa godzina, nowe urządzenie.
- Dostęp do danych poza zakresem roli.
- Tworzenie tokenów API krótko przed odejściem z organizacji.
- Wyłączenie logowania, agenta EDR lub innego zabezpieczenia.
- Kompresja dużych katalogów (przygotowanie do transferu).
- Upload do prywatnego cloud storage.
- Nietypowo duża liczba clone/fork repozytoriów.
- Dostęp do sekretów bez powiązanego ticketu / change requestu.
UEBA — orientacyjny scoring sygnałów SYMULACJA
Dane demonstracyjne. Poniższa formuła i progi ilustrują format panelu decision-support — wagi i progi w środowisku odbiorcy wymagają kalibracji na realnych danych bazowych.
risk_score =
30 * jest_leaverem
+ 25 * masowe_pobieranie
+ 20 * nietypowa_lokalizacja
+ 20 * dostep_do_danych_wrazliwych
+ 15 * nowy_token_api
+ 10 * aktywnosc_poza_godzinami
| Wynik | Akcja |
|---|
| 0–29 | obserwacja |
| 30–49 | alert low |
| 50–74 | alert high + review analityka |
| 75+ | containment (patrz krok 5) |
Playbook — 9 kroków reakcji
SYGNAŁ→TRIAGE→KONTEKST HR→DOWÓD→ZASIĘG→CONTAINMENT→ERADICATION→ESKALACJA LEGAL/HR→ZAMKNIĘCIE
Krok 1 — Przyjęcie sygnału i wstępny triage. Alert z SIEM/UEBA, zgłoszenie menedżera lub kanału whistleblowing. Analyst weryfikuje tożsamość użytkownika i czy sygnał jest realny (nie fałszywie dodatni). Wstępny priorytet wg scoringu UEBA.
Narzędzia: SIEM, reguły korelacyjne (masowy eksport, aktywność leavera, nietypowe logowanie), kanał zgłoszeń. Dowód w ipIII: rekord zgłoszenia + surowy alert dowiązany do incydentu.
Krok 2 — Kontekst HR i ticket. Sprawdzenie roli, zespołu, statusu zatrudnienia (aktywny / w okresie wypowiedzenia / leaver), obecności konfliktu (spór, zwolnienie dyscyplinarne w toku). Weryfikacja, czy działanie ma powiązany ticket lub change request.
Narzędzia: system HR (status zatrudnienia, daty), system ticketowy/change management. Dowód w ipIII: zapis kontekstu HR (bez zbędnych danych osobowych) powiązany z incydentem, zgodnie z zasadą minimalizacji.
Krok 3 — Zabezpieczenie dowodu (evidence preservation). Zanim nastąpi jakakolwiek blokada — snapshot logów IAM/SaaS/EDR/DLP, zachowanie aktywnych sesji, tokenów i kluczy, historii repozytoriów i uploadów. Część systemów kasuje krótkotrwałe logi po suspendzie konta, dlatego ten krok poprzedza containment.
Narzędzia: eksport logów do WORM/retencji, zrzut listy aktywnych sesji i tokenów. Dowód w ipIII: rekord custody logów (hash + timestamp + zakres) → POST /api/ip3/v1/evidence, chain-of-custody zainicjowany przed containmentem.
Krok 4 — Ocena zasięgu. Jakie dane, ile, dokąd (mail prywatny / cloud storage / USB / API zewnętrzne)? Czy konto mogło być przejęte przez stronę trzecią, a nie działać z woli użytkownika? Ustalenie listy zasobów dotkniętych zdarzeniem.
Narzędzia: logi DLP/CASB, historia eksportów, korelacja z logami sieciowymi. Dowód w ipIII: finding „zasięg" (zasoby, wolumen, kierunek transferu) dowiązany do incydentu.
Krok 5 — Containment dopasowany do ryzyka. Średnie ryzyko: wymuszenie MFA, reset aktywnych sesji. Wysokie ryzyko: blokada eksportów, odebranie dostępu do danych wrażliwych. Krytyczne ryzyko: suspend konta, rotacja dostępnych mu sekretów, izolacja hosta. Dowody z kroku 3 pozostają nietknięte.
Narzędzia: IAM (suspend/reset), PAM (rotacja sekretów), EDR (izolacja hosta). Dowód w ipIII: log decyzji containment (kto, kiedy, jaki poziom) powiązany z evidence-package.
Krok 6 — Eradication. Odebranie zbędnych ról, rotacja pozostałych sekretów dostępnych dla konta, usunięcie nieautoryzowanych tokenów API, zablokowanie reguł forwardingu poczty. Sprawdzenie mechanizmów trwałości: aplikacje OAuth, klucze SSH, tokeny PAT. Powiadomienie właścicieli dotkniętych danych.
Narzędzia: IAM/PAM (odbiór ról, rotacja), przegląd integracji OAuth/SSH/PAT. Dowód w ipIII: lista usuniętych uprawnień/tokenów jako finding eradication, powiązana z custody.
Krok 7 — Eskalacja Legal/HR i flagi prawne. Każdy incydent dotykający konkretnej osoby przechodzi przez ścieżkę Legal/HR przed jakimkolwiek działaniem dyscyplinarnym. Ocena flag RODO/NIS2/prawo pracy — patrz tabela niżej.
Narzędzia: Legal Trigger Engine ipIII, procedura HR. Dowód w ipIII: mapa obowiązków (/incidents/:id/legal-triggers), DECISION-SUPPORT — nie porada prawna ani rekomendacja kadrowa.
Krok 8 — Komunikacja. Wewnętrzna — do właścicieli systemów i, gdy zasadne, do przełożonego (przez HR, nie bezpośrednio przez SOC). Zewnętrzna — tylko jeśli aktywowana flaga regulacyjna (np. zgłoszenie do PUODO), zawsze zatwierdzona przez Legal/DPO.
Narzędzia: szablon komunikatu, akceptacja Legal/DPO. Dowód w ipIII: zapis decyzji komunikacyjnej i zatwierdzenia w evidence-package.
Krok 9 — Zamknięcie i lessons learned. Weryfikacja: brak aktywnych sesji/tokenów, dostęp odebrany w całości, custody logów kompletny, decyzja Legal/HR udokumentowana. Zgodnie z regułą
close-with-evidence — bez potwierdzonego dowodu incydent nie zostaje zamknięty. Aktualizacja reguł detekcji na podstawie wniosków.
Narzędzia: retest dostępów, procedura Response & Retest. Dowód w ipIII: evidence-package z manifestem (package_sha256) + status CONFIRMED → close.
Prewencja — minimalny zestaw kontroli
Least privilege
RBAC/ABAC, dostęp czasowy (JIT/JEA), access review co 30–90 dni, automatyczny odbiór dostępów po zmianie roli.
Separacja obowiązków
Wdrożenie kodu ≠ zatwierdzenie produkcji; admin bazy ≠ eksport danych klienta bez approvala; twórca przelewu ≠ zatwierdzający.
Ochrona danych
Klasyfikacja public/internal/confidential/restricted, DLP mail/endpoint/cloud, szyfrowanie w spoczynku i transmisji.
Proces odejścia (offboarding)
T-14/T-7 oznaczenie leaver w HR, T-7 review dostępu, T0 dezaktywacja SSO/VPN/SaaS/tokenów, T+7 analiza aktywności z ostatnich 30 dni.
Flagi prawne i eskalacja
| Warunek | Flaga | Obowiązek |
|---|
| Ujawnienie / wyciek danych osobowych | GDPR_BREACH | RODO art. 33 — zgłoszenie do PUODO w 72h; art. 34 przy wysokim ryzyku dla osób |
| Podmiot to usługa kluczowa/ważna, incydent operacyjny | NIS2_RELEVANT | Wczesne ostrzeżenie do CSIRT w 24h, zgłoszenie 72h, raport końcowy |
| Działanie dyscyplinarne wobec pracownika | HR_LEGAL | Ścieżka Legal/HR, zgodność z prawem pracy i regulaminem — poza zakresem ipIII |
| Podejrzenie przestępstwa (kradzież IP, sabotaż) | LAW_ENFORCEMENT | Zawiadomienie organów ścigania, zabezpieczenie dowodów (chain-of-custody) |
| Monitoring pracownika w toku ustalania sygnału | PRIVACY_REVIEW | Zgodność z RODO i polityką monitoringu — weryfikacja DPO przed rozszerzeniem zakresu |
Powiązanie z wyciekiem danych: gdy insider (dowolnego typu) doprowadza do ujawnienia danych osobowych, incydent N sprzęga się z
Playbookiem E (wyciek danych). Zegar 72h RODO liczony jest od momentu
stwierdzenia naruszenia — dlatego krok 4 (ocena zasięgu) jest krytyczny czasowo.
Polityki organizacyjne — minimalny zestaw
- Acceptable Use Policy.
- Data Handling Policy.
- Access Review Policy.
- Joiner-Mover-Leaver Process.
- Privileged Access Policy.
- Incident Response Policy.
- Kanał whistleblowing / zgłoszeń.
- Polityka prywatności monitoringu pracowników — zgodna z prawem pracy i RODO.
Metryki SYMULACJA
Dane demonstracyjne (demo). Poniższe wartości ilustrują format panelu, nie są rzeczywistymi pomiarami środowiska odbiorcy.
< 24h
Cel MTTD alertu insider SYMULACJA
od wygenerowania sygnału
< 4h
Cel MTTR containment (high) SYMULACJA
od potwierdzenia ryzyka
0%
Kont z dostępem po odejściu SYMULACJA
cel offboardingu
> 95%
Access review completion SYMULACJA
systemy krytyczne
Kryteria gotowości
Playbook działa jako proces operacyjny, gdy spełnione jest jednocześnie:
- każdy użytkownik ma właściciela i przypisaną rolę,
- odejście zarejestrowane w HR automatycznie odbiera dostępy,
- eksporty danych są logowane i korelowane,
- alerty łączą sygnał HR + IAM + DLP w jeden kontekst,
- zespół IR ma udokumentowaną procedurę zachowania dowodów (krok 3 przed krokiem 5),
- istnieje ścieżka Legal/HR dla każdego przypadku dotykającego konkretnej osoby.
Powiązane strony
Wyciek danych
Sprzężenie gdy insider → dane osobowe. → Playbook E
Uwaga metodyczna. Playbook opisuje sygnały, progi i kroki reakcji na zdarzenia insider — to metodyka decision-support, nie porada prawna ani rekomendacja kadrowa. Monitoring pracowników musi być zgodny z prawem pracy, RODO i regulaminem obowiązującym u odbiorcy; ipIII nie automatyzuje decyzji dyscyplinarnych. Ramki RODO/NIS2 opierają się na treści regulacji (norma). Metryki oznaczone SYMULACJA są przykładowe.