Rozpoznawanie phishingu z pomocą AI: konfiguracja, modele i ograniczenia

Punkt wyjścia: czym naprawdę jest rozpoznawanie phishingu z pomocą AI

Phishing to nie tylko podejrzany link. To także subtelne sygnały: zmieniony nagłówek, nienaturalny ton wypowiedzi, świeżo zarejestrowana domena, obrazek zamiast tekstu czy prośba o pilny przelew. Rozpoznawanie phishingu z pomocą AI łączy analizę treści, kontekstu i metadanych z mechanizmami uczenia maszynowego i modeli językowych. Celem jest szybkie, powtarzalne i skalowalne wykrywanie zagrożeń – przy zachowaniu rozsądnego poziomu błędów fałszywych alarmów.

Zanim ruszysz, odpowiedz sobie na kilka konkretnych pytań. Pomogą wybrać właściwy wariant rozwiązania i uniknąć ślepych uliczek.

• Czy potrzebujesz decyzji w czasie rzeczywistym (kilkadziesiąt–kilkaset milisekund), czy akceptujesz opóźnienie minutowe, a może skan asynchroniczny po dostarczeniu wiadomości?
• Jakie kanały chcesz analizować: e‑mail, SMS (smishing), komunikatory, formularze WWW, zgłoszenia użytkowników, a może treści zewnętrzne (landing page, załączniki, QR-kody)?
• Jakie są ograniczenia prawne i prywatnościowe (RODO, tajemnica korespondencji, sektor regulowany)? Czy dane mogą trafić do chmury, czy wszystko musi działać on‑premise?
• Jaki jest koszt błędu? Co jest groźniejsze: przepuszczenie ataku (false negative), czy zablokowanie legalnej wiadomości (false positive)?
• Jakim budżetem i zespołem dysponujesz: inżynierowie MLOps, analitycy, SOC, czy raczej mały zespół IT?
• Czy posiadasz oznaczone dane (próbki phishingu vs. nieszkodliwe), aby trenować modele? Jeśli nie – skąd je pozyskasz i jak zadbasz o etykietowanie?

Te pytania tworzą kręgosłup decyzji architektonicznych. W kolejnych sekcjach znajdziesz warianty rozwiązań, sposoby konfiguracji, gotową checklistę i praktyczne ograniczenia, które pojawiają się w boju.

Warianty rozwiązań: od klasycznych modeli do LLM i hybryd

Wariant A: klasyczny ML (cechy + klasyfikator)

Najprostszy i wciąż skuteczny nurt: ekstrakcja cech (np. TF‑IDF z treści e‑maila, cechy leksykalne URL, dane WHOIS, liczba linków, podejrzane TLD) i klasyfikator (Logistic Regression, SVM, Random Forest, Gradient Boosting). Zalety? Szybkość, niskie koszty, pełna kontrola i łatwa interpretacja wyników. Wady: ograniczona zdolność do rozumienia kontekstu językowego i trudności z uogólnieniem na sprytne ataki obfuscacyjne.

Ten wariant dobrze się sprawdza przy dużych wolumenach, gdy liczy się niezawodna inżynieria i przewidywalne koszty. Zwykle jest pierwszym krokiem, na którym buduje się filtry w MTA/Microsoft 365/Google Workspace, a następnie eskaluje tylko trudne przypadki.

Wariant B: fine‑tuning transformerów do klasyfikacji phishingu

Modele typu BERT/roBERTa/XLM‑R potrafią lepiej „czytać” kontekst języka. Po dostrojeniu na bazie oznaczonych przykładów uzyskują wyższą skuteczność w zniuansowanych przypadkach: prośby o pilny przelew, podszycia się pod styl pisania, profesjonalnie przygotowane e‑maile. Koszty rosną (trening, GPU/CPU), podobnie wymagania operacyjne. Dodatkowo trzeba zadbać o regularny retraining z uwagi na dryf danych.

To dobry wybór, gdy masz dane, proces MLOps i potrzebujesz wyższej jakości na trudnych próbkach. Możesz trzymać model on‑prem (Hugging Face + ONNX runtime) i sterować prywatnością.

Wariant C: LLM w trybie zero‑/few‑shot jako klasyfikator

Duże modele językowe (LLM) można wykorzystać bez długiego szkolenia: podajesz treść e‑maila/URL, prompt z instrukcją i przykłady, a model zwraca klasyfikację oraz krótkie uzasadnienie. Plusem jest szybkość wdrożenia i świetne rozumienie kontekstu. Minusem – koszt zapytań, opóźnienia, ryzyko „halucynacji”, a wrażliwe dane mogą nie opuścić organizacji (co wyklucza część rozwiązań chmurowych). Warto stosować to podejście selektywnie, np. do trudnych przypadków w drugiej linii analizy.

Wariant D: hybryda reguły + AI (ensemble)

Połączenie prostych reguł (domena z czarnej listy, znane TTPs) z klasycznym ML lub transformerm zapewnia najlepszy kompromis. Reguły zatrzymują „oczywiste” zagrożenia i obniżają koszty, a model skupia się na tym, co niejednoznaczne. Do tego mechanizm human‑in‑the‑loop dba o korekty etykiet i naukę na żywo. To najczęstsza architektura w dojrzałych zespołach SOC.

Tabela porównawcza: kiedy który wariant ma sens

Checklisty decyzji: wybór architektury i zakresu

Lista kontrolna architektury

• Decyzja o latencji: inline (brama pocztowa) czy asynchronicznie (kolejka + skan po dostarczeniu)?
• Wybór wariantu: klasyk, transformer, LLM, hybryda.
• Zakres kanałów: e‑mail, SMS, komunikatory, strony WWW, załączniki, QR‑kody.
• Prywatność: on‑prem vs chmura; szyfrowanie; pseudonimizacja treści.
• Interfejsy: API REST, webhooki, integracje z MTA/SIEM/SOAR.
• Mechanizmy feedbacku: przycisk „Zgłoś phishing”, re‑etykietowanie, active learning.

Lista kontrolna ryzyka i zgodności

• Polityka przetwarzania treści: podstawa prawna, cele, retencja.
• Minimalizacja danych: pseudonimizacja/redakcja treści przed wysyłką do modeli; filtrowanie PII/sekretów (hasła, token
  • Minimalizacja danych: pseudonimizacja/redakcja treści przed wysyłką do modeli; filtrowanie PII/sekretów (hasła, tokeny, numery kart) i elementów objętych tajemnicą zawodową.
  • Ocena skutków (DPIA) i rejestr czynności przetwarzania, jeśli obrabiasz treść korespondencji pracowników/klientów.
  • Polityka retencji logów i treści: co przechowujesz, jak długo, gdzie i w jakiej postaci (hash/skrót vs pełna treść).
  • Kontrola dostępu i podział ról: kto może zobaczyć surowe treści, kto tylko metryki, kto może zmieniać reguły i progi.
  • Umowy powierzenia z dostawcami (DPA), lokalizacja danych (EEA), tryb no‑train dla zewnętrznych modeli.
  • Testy bezpieczeństwa modeli: prompt injection, exfiltracja danych przez LLM, jailbreaky, nadużycia API.
  • Mechanizmy odwołania i audytu decyzji: możliwość „odblokowania” wiadomości, ścieżka wyjaśnienia decyzji.
  • Monitorowanie dryfu danych i jakości: alarmy, gdy rośnie odsetek odwołań użytkowników lub zmienia się rozkład cech.

  Konfiguracje referencyjne: trzy ścieżki wdrożenia

  Konfiguracja 1: filtr klasyczny inline + eskalacja

  Prosty, szybki tor decyzyjny w bramie pocztowej lub MTA. Cechy + klasyfikator wracają decyzję w milisekundach. Próbki „szare” trafiają do kolejki asynchronicznej na dogłębną analizę.

  • Składniki: ekstraktor cech (treść, nagłówki, URL), klasyfikator (LR/SVM/GBM), reguły, kolejka (np. Kafka/SQS), zapisy do SIEM.
  • Plusy: bardzo niska latencja i przewidywalne koszty. Dobra interpretowalność dla SOC.
  • Minusy: ograniczone rozumienie kontekstu językowego; wymaga ręcznego utrzymania cech.
  • Dla kogo: wysoki wolumen, potrzeba decyzji inline, mały zespół.

  Konfiguracja 2: transformer on‑prem po dostarczeniu

  Wiadomości są akceptowane, ale natychmiast trafiają do skanera asynchronicznego. Jeśli wynik przekroczy próg ryzyka, SOAR oznacza i przenosi wiadomość do kwarantanny lub wysyła ostrzeżenie.

  • Składniki: model BERT/roBERTa/XLM‑R (ONNX/TVM), OCR dla obrazków, resolver URL (w tym przekierowania), sandbox do headless renderowania stron.
  • Plusy: lepsza skuteczność na zniuansowanych treściach, kontrola prywatności.
  • Minusy: większa złożoność operacyjna, potrzeba GPU/CPU i retrainingu.
  • Dla kogo: średnie/duże organizacje, dojrzały MLOps, kanały wielojęzyczne.

  Konfiguracja 3: hybryda z LLM w drugiej linii

  Reguły i klasyczny ML odsiewają „pewniaki”. Przypadki graniczne trafiają do LLM w trybie few‑shot z redakcją treści. Model zwraca klasę, uzasadnienie i proponowaną akcję, a SOC potwierdza tylko część przypadków.

  • Składniki: warstwa redakcji (maskowanie PII), cache promptów, kontrola kosztów, schema‑based output (JSON), polityki guardrail.
  • Plusy: świetne rozumienie kontekstu, szybki czas do wartości bez własnego treningu.
  • Minusy: koszt zapytań i latencja; konieczność twardych ograniczeń prywatności.
  • Dla kogo: zespoły, które potrzebują jakości na trudnych próbkach, ale nie mają dużego korpusu do treningu.

  Metryki jakości i budżet błędów

  Nie ma jednej „magicznej” metryki. Źle ustawiony próg potrafi zrobić większą krzywdę niż przeciętny model. Dwa kroki, które ratują projekt:

  1. Ustal koszt błędu: co jest droższe – przepuszczenie ataku czy fałszywy alarm? Z tego wynika preferencja na recall lub precision.
  2. Kalibruj progi per kanał i per grupa użytkowników (np. finanse vs newslettery). Ten sam model, dwa różne progi.
  • Precision/Recall/F1: podstawa oceny. Gdy baza zdarzeń jest rzadka, śledź krzywą Precision‑Recall zamiast ROC.
  • Cost‑sensitive thresholding: zamiast maksymalizować F1, minimalizuj ważony koszt FP/FN.
  • Walidacja czasowa: podział danych po dacie. Phishing się zmienia – unikaj „wycieku” między zbiorem train/test.
  • Kalibracja prawdopodobieństw (Platt/Isotonic): pozwala ustawić progi biznesowe (np. kwarantanna powyżej 0.9).
  • Monitorowanie w produkcji: odsetek odwołań, czas obsługi, dystrybucja cech/score, alerty na dryf.

  Praktyczny przykład: dział finansów – agresywniejszy próg i dodatkowe potwierdzenie wypłat; dział marketingu – łagodniejszy próg, ale automatyczna adnotacja ostrzegawcza w treści.

  Dane i etykietowanie: skąd wziąć „paliwo”

  Bez danych nie ma jakości. Gdy ich brakuje, działaj warstwowo:

  

  • Źródła: skrzynka abuse/zgłoszeń, symulacje phishingowe, feedy IOC/URL, próbki od dostawców, publiczne listy domen/URL podejrzanych.
  • Etykietowanie: playbooki dla analityków, podwójna adnotacja przy sporach, szybka ścieżka „niepewne”.
  • Dedup i normalizacja: usuń powielone wątki, znormalizuj URL (bez parametrów śledzących), rozwiń skracacze.
  • Split czasowy i per‑domena: nie mieszaj wiadomości z tej samej kampanii między train/test.
  • Weak supervision: reguły heurystyczne i listy IOC jako etykiety wstępne, potem doszlifowanie ręczne na próbkach granicznych.
  • Augmentacje z umiarem: parafrazy/perturbacje URL pomagają na obfuscację, ale nie zastąpią realnych kampanii.

  Promptowanie i guardraile dla LLM

  LLM potrafi pomóc, ale musi dostać właściwe szyny. Krótki szkielet, który sprawdza się w praktyce:

  • Redakcja wstępna: maskuj PII, numery kont, sygnatury. Zostaw kontekst biznesowy i strukturę nagłówków.
  • Instrukcja z ograniczeniami: rola („jesteś analizatorem phishingu”), kryteria oceny (np. spoofing domeny, ton, prośby o pilność), zakaz „wymyślania” dowodów.
  • Few‑shot z kontrprzykładami: 2–3 przykłady prawdziwego ataku i 2–3 legalnych, ale podobnych próśb (np. o fakturę).
  • Format wyjścia: wymuś JSON z polami: klasa, pewność, sygnały, rekomendowana akcja, elementy do ukrycia.
  • Parametry: niska temperatura, limity kontekstu i tokenów, cache wyników, retry z krótkim timeoutem.
  • Guardraile: filtr treści wrażliwej, wykrywanie prompt injection (np. „zignoruj wcześniejsze instrukcje”), sandbox dla URL.

  Krótka historia z SOC: model świetnie uzasadniał „czemu to phishing”, ale raz „kupił” instrukcję z treści załącznika, by zignorować własne reguły. Prosty detektor fraz typu „ignore previous” i whitelistowanie źródeł od razu to uciął.

  Operacje: od wdrożenia do codziennej pracy

  • Tryb cieniowy (shadow): najpierw równoległe działanie bez wpływu na produkcję, porównanie decyzji z obecnym filtrem.
  • Canary i stopniowe podnoszenie progu: zaczynasz od adnotacji w treści („to może być phishing”), dopiero potem kwarantanna.
  • Model registry i wersjonowanie: każda zmiana modelu/progu ma ID, changelog i plan rollbacku.
  • Human‑in‑the‑loop: przycisk „Zgłoś phishing”, kolejka rewizji, zwrot etykiet do treningu co sprint.
  • Playbooki SOAR: tagowanie, izolacja, powiadomienie użytkownika, otwarcie incydentu, zamknięcie z decyzją końcową.
  • Budżet kosztów: cap na zapytania do LLM, batchowanie asynchroniczne, lokalna inferencja dla najczęstszych przypadków.

  Ograniczenia i pułapki, które wychodzą w boju

  • Base‑rate fallacy: przy niskiej bazie ataków nawet wysoka skuteczność może dać sporo FP. Pomaga segmentacja i różne progi.
  • Obrazki zamiast tekstu i QR‑phishing: włącz OCR i walidację linków zakodowanych w obrazach; to podnosi koszt i latencję.
  • Obfuscacja URL i łańcuchy przekierowań: bez headless przeglądarki i analizy JS łatwo pominąć złośliwy landing.

  Wybór wariantu: które podejście pasuje do Twojego kontekstu

  Te trzy ścieżki można rozłożyć na kilka osi. Gdy odpowiesz na te pytania, decyzja zwykle „klika”. Jakie masz limity latencji? Ile kosztu na wiadomość akceptujesz? Jak wrażliwe są dane? Ile masz danych do treningu i czy zespół MLOps jest na pokładzie?

  • Latencja i deterministyczność: klasyczny ML wygrywa inline; transformer jest dobry asynchronicznie; LLM to druga linia, nie front.
  • Prywatność i kontrola: transformer on‑prem daje największą kontrolę; LLM wymaga redakcji i ścisłych guardrailów.
  • Koszt operacyjny: klasyk jest przewidywalny i najtańszy; transformer to inwestycja w infrastrukturę; LLM to zmienny koszt zapytań.
  • Dostępność danych: bez większego korpusu – hybryda z LLM; z dobrym zbiorem – transformer błyszczy; z małą próbą – klasyk + reguły.
  • Interpretowalność: klasyczny ML i reguły łatwiej uzasadnić; transformer wymaga dodatkowych narzędzi SHAP/attention; LLM potrafi uzasadnić, ale bywa „zbyt pewny”.
  • Wielojęzyczność: LLM i XLM‑R radzą sobie lepiej z mieszanką języków; klasyk wymaga starannych cech per język.

  Plusy i minusy w skrócie

  • Wariant: klasyczny ML + reguły
    • Plusy: najszybszy, tani, stabilny, prosty w utrzymaniu.
    • Minusy: słabszy na zniuansowanych treściach i nowych taktykach obfuscacji.
    • Kiedy: wysoki wolumen, twarde SLA, ograniczony budżet i zespół.
  • Wariant: transformer on‑prem
    • Plusy: lepsze rozumienie kontekstu, kontrola danych, możliwość doszkolenia domenowego.
    • Minusy: złożoność operacyjna, retraining, potrzeba GPU/CPU.
    • Kiedy: dojrzały MLOps, kanały wielojęzyczne, wrażliwe dane (poczta zarządu, finanse).
  • Wariant: hybryda z LLM w drugiej linii
    • Plusy: świetna jakość na trudnych próbkach bez własnego treningu, dobre uzasadnienia decyzji.
    • Minusy: koszty i latencja, ryzyka prompt injection, konieczność redakcji PII.
    • Kiedy: mało danych treningowych, ale duża różnorodność ataków; chcesz „odciążyć” SOC na granicznych sprawach.

  Checklisty wyboru i parametry startowe

  Krótka lista decyzji, która układa projekt na starcie:

  1. Latencja krytyczna? Jeśli tak, decyzje „blokuj/oznacz” muszą powstawać inline – front robi klasyk, reszta idzie asynchronicznie.
  2. Budżet na błąd: jeśli przepuszczenie ataku jest droższe niż fałszywy alarm, ustaw wyższe progi kwarantanny i osobny próg dla VIP/finansów.
  3. Prywatność: PII „nie opuszcza murów”? Wybierz transformer on‑prem i redakcję również w logach.
  4. Wolumen i profil treści: dużo szablonowych kampanii – klasyk z IOC i URL‑resolverem wystarczy; dużo „sztuki” socjotechnicznej – włącz LLM w drugiej linii.
  5. Dane treningowe: brak korpusu? Startuj od hybrydy i zbieraj dane do treningu transformera.
  6. Zespół i narzędzia: brak MLOps – korzystaj z gotowych embedderów i inference servera; jest MLOps – pipeline do cyklicznego treningu i walidacji czasowej.
  7. Integracje: czy SOAR/ITSM potrafi przyjąć uzasadnienie i ścieżkę odwołań? Jeśli nie, zacznij od adnotacji i ręcznego review.

  Mini‑przykład: prośba „pilne, potwierdź przelew dziś” do księgowej. Klasyk wykryje podejrzany URL i domenę‑sobowtóra; transformer rozpozna niespójność tonu i szablonu; LLM z few‑shotem wyjaśni, że „nagły termin + prośba o poufność” to sygnały ataku – i zaproponuje kwarantannę.

  Ścieżki ewolucji rozwiązania

  • Etap 1: reguły + klasyczny ML inline, logowanie cech i decyzji, tryb cieniowy dla toru asynchronicznego.
  • Etap 2: dołóż transformer on‑prem do kolejki „szarych” próbek, kalibracja progów per dział.
  • Etap 3: uruchom LLM w drugiej linii z redakcją PII i schema‑based output, ogranicz wywołania cache’em i budżetem.
  • Etap 4: retraining transformera na własnych danych z odwołań i incydentów; LLM zostaje jako konsultant dla outlierów.

  Po co ta ewolucja? Jak z narzędziami w warsztacie: młotek załatwia 80% spraw, ale do precyzji sięgasz po wkrętarkę; dopiero na rzadkie, skomplikowane zadania wyciągasz multitoola.

  Sytuacje graniczne i wyjątki

  • Brak zgody na przetwarzanie treści w chmurze: LLM tylko lokalnie lub w ogóle; wzmocnij transformer i reguły kontekstowe.
  • Ataki obrazkowe i QR‑kody w materiałach drukowanych: włącz OCR i dekoder QR w torze asynchronicznym, ale na front wstaw ostrzeżenie dla użytkownika.
  • Kanały chat/CRM z krótkimi wiadomościami: przewagę mają embeddery i małe transformery; LLM bywa nadmiarowy.
  • Sezonowe kampanie (np. „PIT”, „Black Friday”): tymczasowo podnieś czułość na konkretne frazy/domeny i uruchom reguły z limitem czasu.

  Rekomendacja końcowa: wybór na dziś

  • Wybierz klasyczny ML + reguły, jeśli liczy się przewidywalny koszt i decyzja w milisekundach, a treści są w dużej mierze szablonowe.
  • Wybierz transformer on‑prem, jeśli operujesz na wrażliwych danych, masz zespół MLOps i chcesz lepszej jakości bez wysyłania treści na zewnątrz.
  • Wybierz hybrydę z LLM w drugiej linii, jeśli brakuje Ci danych do treningu, ale chcesz podnieść skuteczność na trudnych przypadkach i akceptujesz wyższy koszt jednostkowy dla mniejszego odsetka wiadomości.

  Najlepiej sprawdza się model mieszany: szybka pierwsza linia (reguły + klasyk), mocniejsza analiza asynchroniczna (transformer) i LLM jako ekspert od rzadkich, kosztownych błędów. Dzięki temu budujesz system, który nie tylko dziś blokuje kampanie, ale jutro szybciej uczy się nowych sztuczek przestępców.

  Punkt wpięcia w infrastrukturę pocztową: cztery scenariusze

  Gdzie wpiąć detekcję? To jak ustawienie bramki na stadionie: możesz stać przy wejściu, na korytarzu albo pod samą lożą VIP. Każde miejsce daje inną kontrolę i inne koszty pomyłki.

  • Brama SMTP/MTA inline
    • Plusy: pełna kontrola przed dostarczeniem, jednolite polityki, jasne SLA.
    • Minusy: presja na latencję i deterministykę, ryzyko spadków przepustowości przy błędnej konfiguracji.
    • Kiedy: duży wolumen, rygorystyczne compliance, potrzeba twardego „blokuj przed skrzynką”.
    • Uwagi: na froncie trzymaj reguły + klasyczny ML; transformery/LLM tylko w torze asynchronicznym lub jako druga linia.
  • Post‑delivery przez API (np. Graph/EWS/Gmail)
    • Plusy: bezpieczny rollout (nic nie psuje SMTP), brak presji milisekund, łatwe A/B i shadow.
    • Minusy: krótki „okienkowy” czas ekspozycji, wymaga odpowiednich uprawnień i throttlingu API.
    • Kiedy: etap wdrożenia, środowiska o zmiennym ruchu, gdy priorytetem jest obserwacja zanim zacznie się blokować.
    • Uwagi: świetny kanał na transformer/LLM i akcje typu „cofnij/kwarantanna/oznacz”.
  • Secure Email Gateway / integracja u dostawcy
    • Plusy: gotowe konektory, reguły polityczne, mniej customowej operacji.
    • Minusy: mniejsza elastyczność modeli, vendor lock‑in, ograniczone możliwości fine‑tune i telemetry.
    • Kiedy: mały zespół, szybkie uruchomienie, chęć korzystania z wbudowanych przepływów.
    • Uwagi: hybryda ma sens – progi/zasady w SEG, a trudne przypadki wypychane do własnego toru analitycznego.
  • Wtyczka/klient końcowy (add‑in) + „Zgłoś phishing”
    • Plusy: „człowiek w pętli”, kontekst użytkownika, bardzo dobry kanał zwrotny do treningu.
    • Minusy: brak twardego bloku na wejściu, rozbieżności między urządzeniami/wersjami.
    • Kiedy: organizacje o rozproszonej flocie, nacisk na edukację i feedback, kanały krótkich wiadomości (chat/CRM).
    • Uwagi: potraktuj jako warstwę wsparcia – nie zastąpi bramy, ale znacząco obniża ryzyko „missów”.

  Jeśli zaczynasz: analityka post‑delivery przez API + cieniem na bramie. Gdy krzywe się ustabilizują – przenieś twarde decyzje na MTA, zostawiając tor asynchroniczny na przypadki sporne.

  Polityki reakcji i próg zaufania: warianty i kompromisy

  Decyzja „co zrobić z podejrzaną wiadomością” bywa trudniejsza niż sama klasyfikacja. Dobrze działa drabinka reakcji – od najłagodniejszej do najsurowszej – powiązana z progiem zaufania modelu.

  • Adnotacja + szkolny „żółty kartonik”
    • Co to: baner ostrzegawczy, tag w temacie, lekki rewrite linku.
    • Plusy: zero ryzyka utraty ważnej korespondencji, świetne na start i dla VIP.
    • Minusy: użytkownicy czasem ignorują banery; brak natychmiastowej izolacji.
    • Kiedy: niski próg pewności, okres canary, działy wrażliwe na FP (sprzedaż, PR).
  • Miękka kwarantanna z odwołaniem
    • Co to: przeniesienie do folderu „Podejrzane” z przyciskiem „To bezpieczne”.
    • Plusy: odzyskiwanie FP bez ticketu do SOC, nauka na odwołaniach.
    • Minusy: lekka zwłoka w komunikacji, wymaga jasnych komunikatów dla użytkownika.
    • Kiedy: średni próg pewności, działy back‑office, gdzie opóźnienie nie boli.
  • Twarda kwarantanna z eskalacją
    • Co to: izolacja i automatyczna ścieżka rewizji/incident w SOAR.
    • Plusy: wysoka ochrona, dobry materiał do retrainingu.
    • Minusy: koszt operacyjny, potrzebny dyżur/rotacja do przeglądu.
    • Kiedy: wysoki próg pewności, działy finansowe i dostęp do systemów płatniczych.
  • Blokada na wejściu
    • Co to: odrzut/554 na SMTP lub drop na bramie.
    • Plusy: brak ekspozycji użytkownika.
    • Minusy: ewentualne utraty krytycznych maili przy złej kalibracji.
    • Kiedy: sygnatury pewne (znane kampanie, złośliwe ładunki), skorelowane IOC/URL.

  Mikro‑przykład: prośba o dane kadrowe przychodzi do HR o 16:55 w piątek. Baner ostrzegawczy nie wystarczył – użytkownik prawie kliknął. Po podniesieniu drabinki HR dostaje „miękką kwarantannę”, a finanse – „twardą”. Liczba incydentów spada, a SOC widzi mniej zgłoszeń „na ostatnią chwilę”.

  Metryki, które naprawdę prowadzą do wyboru

  Wydajność modelu to jedno, spokój operacyjny – drugie. Dopiero zestawienie metryk modelowych z operacyjnymi i biznesowymi pokazuje, który wariant wygra.

  • Metryki detekcyjne (dla zespołu modeli)
    • Krzywe PR zamiast samych accuracy; odczyt przy docelowym FPR na milion wiadomości.
    • Stabilność w czasie: walidacja z podziałem czasowym i na sezonowe kampanie.
    • Jakość na trudnych klasach: osobne eval dla BEC, QR‑phishingu i obrazków z tekstem.
  • Metryki operacyjne (dla właściciela procesu)
    • Lead‑time do izolacji: od pierwszego SMTP do kwarantanny/banera.
    • MTTR dla odwołań: ile trwa „odzyskanie” FP i ile z tego wraca do treningu.
    • Latencja p95/p99 w torze inline vs asynchronicznym; stabilność pod szczytem (np. kampanie sezonowe).
  • Metryki biznesowe (dla sponsorów)
    • Redukcja kliknięć w złośliwe linki vs okres bazowy (proxy/EDR podaje sygnał zwrotny).
    • Odsetek „user‑reported phish” pokrywających się z realnymi incydentami.
    • Koszt jednostkowy obsługi incydentu vs koszt zapytania do modelu – czy drabinka reakcji się bilansuje.

  

  Walidacja porównawcza bez ryzyka dla użytkownika

  • Złóż zestaw testowy z podziałem czasowym i „adversarial” (obfuskacja URL, obrazy, mieszanka języków).
  • Uruchom shadow‑mode na realnym ruchu: model liczy wynik, ale nie wpływa na decyzję. Porównuj z aktualną polityką i rejestruj różnice „co by było, gdyby”.

  <

  Walidacja porównawcza bez ryzyka dla użytkownika – dokończenie

  • Uruchom shadow‑mode na realnym ruchu: model liczy wynik, ale nie wpływa na decyzję. Porównuj z aktualną polityką i rejestruj różnice „co by było, gdyby”.
  • Przetestuj polityki reakcji w A/B: ten sam model, różne drabinki (baner vs miękka kwarantanna) i obserwacja wpływu na FP/FN oraz liczbę odwołań.
  • Włącz „stop‑loss” na rollout: jeśli FP lub latencja przekroczą próg – automatyczny powrót do poprzedniej wersji i zgłoszenie do zespołu.
  • Kalibruj progi osobno dla kanałów: osobny próg dla VIP/finansów, inny dla zespołów back‑office. To często prostsze niż jeden „złoty” próg.
  • Zamknij pętlę feedbacku: odwołania użytkowników, kliknięcia z proxy/EDR, IOC z SOAR – wszystkie trafiają do kolejki retrainingu z priorytetem.

  Zasilanie modeli w sygnały: trzy ścieżki wzbogacania (enrichment)

  Sam tekst wiadomości to za mało. Różne typy sygnałów budują przewagę – pytanie brzmi: jak głęboko wejść w enrichment i gdzie są koszty?

  • Lekki enrichment (szybki tor)
    • Co dorzucasz: deobfuskacja URL (IDN, punycode, homoglify), reputacja domen/IP, SPF/DKIM/DMARC, histogram znaków, entropia tematu.
    • Plusy: milisekundy, niski koszt, idealny na MTA.
    • Minusy: nie zobaczysz złośliwych przekierowań po JS ani treści za skracaczami.
    • Kiedy: front inline, duży wolumen, szybkie odcięcie kampanii „na wierzchu”.
  • Ciężki enrichment (rendering + sandbox)
    • Co dorzucasz: headless browser, DOM‑diff, screenshot + OCR, rozwijanie łańcuchów przekierowań, detonacja załączników w piaskownicy.
    • Plusy: wykrywa ukryte CTA, cloaking i techniki „po kliknięciu”.
    • Minusy: sekundy zamiast milisekund, limity równoległości, większy koszt.
    • Kiedy: tor asynchroniczny, post‑delivery przez API, analiza przypadków spornych.
  • Korelacyjny enrichment (sygnały behawioralne)
    • Co dorzucasz: wzorce nadawcy w czasie (pory, język, historia wątku), zgodność z książką adresową/org‑chart, anomalia w stylu pisania.
    • Plusy: mocny na BEC i „bezlinkowych” oszustwach (prośby o przelew, faktury).
    • Minusy: wymaga magazynu cech i dbałości o prywatność; łatwo o dryf danych.
    • Kiedy: dojrzałe wdrożenia, gdzie proste sygnały już są „wyciśnięte”.

  Krótki przykład: „pilna prośba” z aliasu CFO, bez linków i załączników, trafia do finansów o nietypowej godzinie. Lekki tor przepuści. Korelacja z godzinami wysyłki i słowami kluczowymi + odchylenie stylu często wyłapie BEC zanim pojawi się przelew.

  Prywatność i LLM: trzy warianty przetwarzania treści

  Możesz chcieć mocy LLM bez wynoszenia wrażliwych danych. Jak to pogodzić? Trzy podejścia różnią się kompromisem między jakością a ekspozycją.

  • LLM on‑prem / self‑host
    • Co trafia na zewnątrz: nic (pełna izolacja).
    • Plusy: zgodność z ostrym compliance, możliwość fine‑tune na własnych danych.
    • Minusy: koszt infrastruktury i MLOps, konieczność aktualizacji i hardeningu.
    • Dla kogo: sektor finansowy/publiczny, dane kadrowe i prawne.
  • Pseudonimizacja przed SaaS LLM
    • Co trafia na zewnątrz: tekst po maskowaniu PII/sekretów (regex, NER, hashing), z zachowaniem struktury językowej.
    • Plusy: dobry balans jakości i prywatności, relatywnie szybkie wdrożenie.
    • Minusy: ryzyko „przecieków” przez kontekst (unikalne frazy), spadek jakości na przykładach wymagających nazw/identyfikatorów.
    • Dla kogo: firmy z polityką „cloud‑allowed” i kontrolowaną ekspozycją.
  • Redukcja do cech/wniosków (LLM dostaje wyłącznie ekstrakty)
    • Co trafia na zewnątrz: streszczenia, intencje, role nadawca‑odbiorca, listy encji bez surowych wartości.
    • Plusy: minimalna powierzchnia danych, mniejsze ryzyko rekonstrukcji.
    • Minusy: LLM „widzi” tylko to, co wyciągnąłeś wcześniej – ryzyko utraty niuansów.
    • Dla kogo: środowiska o bardzo wysokich wymaganiach prywatności i audytu.

  Czy maskowanie złamie kontekst? Przy prośbach typu „zaktualizuj konto dostawcy ACME” zanonimizuj wrażliwe identyfikatory, ale zostaw typ bytu („dostawca”) i intencję („zmiana konta bankowego”). Dzięki temu LLM wciąż oceni ryzyko schematu BEC.

  Etykietowanie i retraining: trzy drogi do działających danych

  Bez porządnych etykiet modele tracą ostrość. W praktyce sprawdzają się trzy komplementarne ścieżki.

  • Ręczne triage SOC
    • Plusy: najwyższa precyzja etykiet, kontekst incydentowy, szybkie wychwytywanie nowych taktyk.
    • Minusy: koszt czasu analityka, ryzyko niespójności między osobami.
    • Kiedy: budowa zestawu „gold”, walidacja zmian przed wdrożeniem.
  • Półautomatyczne etykietowanie (weak supervision)
    • Plusy: skala – reguły/heurystyki/IOC nadają „słabe” etykiety, które potem porządkujesz agregatorem.
    • Minusy: szum; wymaga regularnej kalibracji i odcinania zestarzałych reguł.
    • Kiedy: bieżące dosypywanie świeżych przykładów, szybkie reagowanie na kampanie.
  • Synteza i augmentacja danych
    • Plusy: zwiększa różnorodność (języki, obfuskacje, warianty CTA), uczy odporności na drobne zmiany.
    • Minusy: ryzyko „uczenia na własnych wyobrażeniach”; bez realnych danych łatwo o nadoptymalizację.
    • Kiedy: niedobór trudnych przypadków (BEC bez linków, QR‑phish), trening robustności.

  Praktyka: trzymaj mały zestaw „gold” do ostatecznej walidacji, większy „silver” z weak supervision do treningu bazowego i strumień „bronze” do eksploracji – transformery lubią tę hierarchię jakości.

  Ograniczenia i zabezpieczenia modeli: na co realnie się przygotować

  Atakujący nie muszą łamać kryptografii – wystarczy, że złamią Twoje założenia. Trzy klasy problemów pojawiają się najczęściej.

  • Evasion przez obfuskację i warstwowanie
    • Objawy: linki za skracaczami, przekierowania JS, obrazy z tekstem, mieszanki językowe.
    • Kontr‑ruch: headless rendering + OCR w torze asynchronicznym, rozwijanie łańcuchów URL, detektory IDN/homoglifów w torze szybkim.
  • Dryf danych (sezonowość i nowe taktyki)
    • Objawy: spadek precision w określonych tygodniach, nagła fala FP na legalne kampanie marketingowe.
    • Kontr‑ruch: walidacja czasowa, sezonowe „profile” progów, krótkoterminowe reguły z TTL, ciągła ocena na strumieniu.

  Najczęściej zadawane pytania (FAQ)

  Który model AI do wykrywania phishingu wybrać: klasyczny ML, transformer czy LLM?

  Dobór podejścia zależy od czterech osi: latencja (inline czy po dostarczeniu), koszt (sprzęt vs. zapytania), prywatność (on‑prem vs. chmura) i dojrzałość zespołu (MLOps/SOC). To trochę jak wybór pojazdu: rower dowiezie szybko i tanio, ale nie przewiezie palety.

  • Klasyczny ML (cechy + LR/SVM/GBM) – gdy potrzebujesz bardzo szybkiej decyzji i przewidywalnych kosztów; duży wolumen, mały zespół, wysoka interpretowalność.
  • Transformery po fine‑tuning’u – gdy masz oznaczone dane i chcesz lepszej jakości na „sprytnych” atakach; akceptujesz wyższy koszt i retraining; możliwe on‑prem.
  • LLM zero-/few‑shot – gdy chcesz szybko ruszyć z trudnymi przypadkami i cenisz rozumienie kontekstu; używaj selektywnie (druga linia), bo latencja i koszt zapytań rosną.