Dlaczego AI zmienia sposób szkolenia zespołów bezpieczeństwa
Szkolenia cyberbezpieczeństwa przez lata wyglądały podobnie: slajdy w sali konferencyjnej, test jednokrotnego wyboru, może raz na rok ćwiczenie typu „ironing board” dla SOC. Użytkownicy uczyli się, że trzeba „nie klikać w podejrzane linki”, a zespół bezpieczeństwa, że trzeba przestrzegać procedur. Efekt był przewidywalny: wiele odhaczonych szkoleń, mało realnej zmiany zachowań.
AI wprowadza do tego porządku trzy rzeczy: tempo, skalę i personalizację. Modele językowe potrafią w kilka minut wygenerować dziesiątki wariantów maili phishingowych, SMS-ów czy scenariuszy rozmów telefonicznych. Bardziej zaawansowane platformy potrafią jeszcze dobrać poziom trudności do konkretnej osoby, zbudować progres i mierzyć nie tylko to, kto kliknął, ale też jak szybko ktoś zgłosił incydent i jak go opisał.
Różnica między szkoleniem użytkowników a treningiem zespołu bezpieczeństwa
W programach typu security awareness celem jest przede wszystkim zmiana nawyków zwykłych użytkowników. Chodzi o to, żeby księgowa, handlowiec czy pracownik magazynu umiał zauważyć podejrzaną wiadomość i skorzystać z prostego przycisku „Zgłoś phishing”. Dla zespołów cyberbezpieczeństwa poprzeczka jest dużo wyżej: liczy się jakość analizy, presja czasu, koordynacja między zespołami oraz umiejętność podejmowania nieintuicyjnych decyzji na podstawie niepełnych danych.
AI pozwala rozdzielić te dwa światy, choć korzystają z podobnych narzędzi. Dla użytkowników modele językowe mogą przygotować prostsze, edukacyjne symulacje phishingu oraz czytelne komunikaty po-klikowe. Dla SOC czy inżynierów bezpieczeństwa AI wygeneruje zaawansowane scenariusze ataków: wieloetapowe, obejmujące mail, stronę phishingową, logi systemowe i ruch sieciowy. W obu przypadkach narzędzie jest to samo, ale cele i poziom trudności kompletnie inne.
Częsty mit brzmi: „skoro AI potrafi generować tak realistyczne maile, to nie ma sensu szkolić ludzi, bo i tak się nie obronią”. Rzeczywistość jest inna: ludzie szkoleni na dobrych, realistycznych scenariuszach (także tych generowanych przez AI) uczą się rozpoznawać nie pojedyncze triki, ale całe wzorce zachowań atakujących. W efekcie rośnie nie tylko odsetek poprawnych decyzji, ale też tempo reakcji.
AI jako przyspieszacz, a nie zastępstwo trenera
Mit: „AI samo zrobi szkolenie”. Rzeczywistość: AI robi dokładnie to, o co je poprosisz, a nie to, czego naprawdę potrzebuje twoja organizacja. Model nie zna twoich polityk bezpieczeństwa, specyfiki biznesu, apetytu na ryzyko, ani doświadczeń z poprzednich incydentów. Dopóki człowiek nie zdefiniuje celów, kryteriów jakości i granic etycznych, użycie AI łatwo zamienia się w masową produkcję przypadkowych treści.
Rola lidera zespołu bezpieczeństwa przestaje polegać na tym, by „samemu wymyślić fajny phishing do testu”, a zaczyna przypominać pracę reżysera: określenie, co chcemy przećwiczyć, w jakim kontekście, przy jakim poziomie ryzyka i z jakim komunikatem końcowym. AI jest tutaj szybkim scenarzystą i kopistą, który może przygotować dziesiątki wariantów, ale to człowiek selekcjonuje i zatwierdza.
Spektrum narzędzi: od prostego LLM po zaawansowane platformy
Na jednym końcu skali są proste modele językowe dostępne w ramach czatu lub API. Można z nich korzystać, aby:
generować treści maili phishingowych na różne tematy,
tworzyć krótkie SMS-y (smishing),
projektować przystępne komunikaty edukacyjne po kliknięciu,
budować szkice planów szkoleń czy checklist dla ćwiczeń.
Na drugim końcu są platformy, które integrują AI z mechaniką wysyłania symulowanych kampanii, śledzenia kliknięć, automatycznego przypisywania kolejnych szkoleń oraz raportowania wyników. Najbardziej zaawansowane z nich tworzą całe „ścieżki” treningowe: jeśli ktoś kilkukrotnie kliknął w podobny typ przynęty, dostaje kolejne ćwiczenia i mikro-szkolenia dokładnie z tego zakresu.
Między tymi skrajnościami jest jeszcze opcja budowy własnych rozwiązań w oparciu o API modeli językowych, skryptów do wysyłki maili, integracji z LDAP/SSO i narzędziem ticketowym. To rozwiązanie wymaga więcej pracy, ale daje pełną kontrolę nad danymi i logiką kampanii.
Ustalenie celów: czego właściwie ma nauczyć AI‑wspierane szkolenie
Większość programów „security awareness” startuje od hasła „podnieść świadomość”. Problem w tym, że nie da się zmierzyć „świadomości” bez rozbicia jej na konkretne zachowania. AI potrafi świetnie pomóc w generowaniu treści, ale bez precyzyjnych celów program szkoleń zamienia się w zbiór efektownych, lecz chaotycznych akcji.
Od haseł do wskaźników: co mierzyć w szkoleniach phishingowych
Żeby trening z użyciem AI miał sens, trzeba go powiązać z mierzalnymi efektami. Przykładowe cele dla symulacji phishingu:
Odsetek poprawnie rozpoznanych phishingów – ile osób ani nie kliknęło, ani nie wpisało danych, ani nie pobrało załącznika z konkretnej kampanii.
Czas reakcji – ile minut/godzin mija od pierwszej wysyłki maila do pierwszych zgłoszeń na dedykowany kanał (SOC / helpdesk).
Jakość zgłoszenia – czy użytkownik przekazuje pełne informacje (nagłówki, zrzuty, opis), czy tylko „coś podejrzane”.
Sposób eskalacji – czy zespoły techniczne trzymają się ustalonej ścieżki, czy reagują chaotycznie.
AI może wspierać nie tylko samą symulację, ale też analizę: generować podsumowania po kampanii, wskazywać typowe błędy, proponować mikro-szkolenia dla grup ryzyka. Klucz w tym, by już na starcie ustalić, jakie wskaźniki (KPI) będą śledzone i jak często będą omawiane z zespołem.
Różne role, różne cele: SOC, inżynierowie, IT, helpdesk, użytkownicy
Jednym z najczęstszych błędów jest próba zbudowania „jednego szkolenia dla wszystkich”. Tymczasem każde z kluczowych środowisk w organizacji ma inne zadania i powinno być trenowane pod nieco innym kątem:
SOC / CSIRT – liczy się tempo wykrycia symulowanego ataku, jakość korelacji sygnałów (EDR, proxy, poczta, SIEM), właściwe nadanie priorytetu, poprawna komunikacja z biznesem. AI może tu tworzyć scenariusze, które zostawiają ślady w logach i systemach bezpieczeństwa, a następnie pomóc w ocenie jakości analizy.
Inżynierowie bezpieczeństwa – ważne są decyzje dotyczące konfiguracji, zastosowania playbooków, wdrożenia reguł blokujących, pracy z fałszywie pozytywnymi alertami. Scenariusze mogą wymuszać modyfikacje polityk pocztowych czy reguł EDR.
Zespół IT / administratorzy – celem jest poprawna reakcja operacyjna: odcięcie dostępu, reset haseł, praca z backupem, komunikacja z użytkownikiem i z SOC. Tu przydają się scenariusze „przyziemne”, ale realistyczne i czasem niewygodne organizacyjnie.
Helpdesk / Service Desk – tu testuje się przede wszystkim umiejętność rozpoznania zgłoszeń związanych z phishingiem, prawidłowe kategoryzowanie ticketów i eskalację do właściwego zespołu, a także sposób rozmowy z zestresowanym użytkownikiem.
Zwykli użytkownicy – celem jest wypracowanie odruchu: „zatrzymaj się, sprawdź, zgłoś”. Scenariusze muszą być zrozumiałe i adekwatne do ich pracy, a feedback prosty i nienapastliwy.
AI może generować różne warianty tej samej przynęty, dopasowane do ról. Przykład: ten sam motyw „aktualizacja konta” wygląda inaczej dla administratora, inaczej dla członka zarządu, a jeszcze inaczej dla pracownika obsługi klienta.
Mapowanie celów na typy scenariuszy i kanały ataku
Aby program szkoleń nie ograniczał się tylko do „kliknę/nie kliknę”, cele trzeba zmapować na typy phishingu i kanały ataku:
Spear-phishing – ukierunkowane maile do wąskiej grupy, często z wykorzystaniem szczegółów z LinkedIn lub wewnętrznego intranetu. Dobre do treningu zarządu, działu sprzedaży, zespołów z dostępem do krytycznych danych.
BEC (Business Email Compromise) – scenariusze podszywania się pod partnerów biznesowych, dział finansowy, członków zarządu (CEO fraud). To kluczowy obszar dla finansów, procurementu i wyższej kadry menedżerskiej.
Smishing – SMS-y z „pilną przesyłką”, „kurierem”, „blokadą konta”. Coraz ważniejszy kanał, szczególnie dla pracowników mobilnych.
Vishing – rozmowy telefoniczne, często wsparte wcześniejszym mailem. Można tu użyć AI do generacji skryptów rozmów dla trenerów lub nawet syntetycznego głosu w kontrolowanym środowisku.
Wewnętrzne oszustwa – np. prośby o przesłanie danych współpracowników, przelew wewnętrzny, aktualizacja danych HR. To scenariusze świetne do treningu zaufania do procesów, a nie do „maila jako takiego”.
Mit: szkolenia phishingowe są po to, by „złapać jak najwięcej klikających i ich zawstydzić”. Rzeczywistość: sensowny program używa AI i symulacji, aby bezpiecznie treningowo konfrontować ludzi z trudnymi sytuacjami i mierzyć progres, nie po to, by karać, lecz żeby kierunkować rozwój. Publiczne „tablice wstydu” zabijają zaufanie do całego programu.
Wybór narzędzi AI: od prostych modeli tekstowych do platform symulacyjnych
Skuteczność szkoleń z wykorzystaniem AI zależy nie tylko od pomysłów na scenariusze, ale też od narzędzi. Tu pojawia się dylemat: korzystać z gotowej platformy, postawić na własne rozwiązanie czy po prostu używać LLM jako pomocniczego generatora treści?
Kategorie narzędzi: jak to sensownie poukładać
W praktyce wybór sprowadza się do trzech głównych kategorii:
Modele językowe (LLM) w formie czatu lub API – uniwersalne narzędzia do generowania treści i analizy tekstu. Przydatne do tworzenia maili phishingowych, tekstów stron, komunikatów edukacyjnych, a nawet automatycznych podsumowań kampanii.
Platformy phishingowe z modułami AI – gotowe systemy do planowania, wysyłki i analizowania kampanii phishingowych, w których AI odpowiada za generowanie treści, segmentację użytkowników i często także automatyzację ścieżek szkoleniowych.
Własne rozwiązania oparte na API – skrypty i aplikacje budowane wewnętrznie, korzystające z modeli AI do treści, ale integrujące się z istniejącą pocztą, SIEM, systemem ticketowym i HR.
Im bardziej krytyczne dane chcesz przetwarzać, tym ważniejsza staje się kontrola nad infrastrukturą i konfiguracją AI. Zespół cyberbezpieczeństwa nie powinien uczyć się na narzędziu, któremu sam by nie zaufał z punktu widzenia bezpieczeństwa danych.
Na co zwracać uwagę przy wyborze narzędzia
Lista życzeń dla platformy lub rozwiązania AI używanego do symulacji phishingu i szkoleń obejmuje zwykle kilka kluczowych punktów:
Bezpieczeństwo danych – jasna odpowiedź na pytanie, gdzie są przetwarzane dane (region), czy są używane do trenowania modelu, jak wygląda logowanie i retencja.
Możliwość audytu promptów i odpowiedzi – przydaje się logowanie pełnej historii interakcji z modelem, żeby móc zweryfikować, kto i jakich treści użył.
Integracja z LDAP/SSO – wygodne zarządzanie użytkownikami, przypisywanie do grup, raportowanie per dział.
Integracje z SIEM, EDR, ticketingiem – przy bardziej zaawansowanych scenariuszach dobrze, by symulowane ataki generowały ślady widoczne w logach i systemach bezpieczeństwa.
Możliwość ręcznej kontroli treści – generowane przez AI maile czy SMS-y muszą przechodzić przez proces akceptacji, a nie iść w świat automatycznie.
W przypadku korzystania z samodzielnego LLM (np. do prototypowania) trzeba dodać warstwę procesową: wytyczne dla osób korzystających z narzędzia, zakaz wprowadzania prawdziwych danych osobowych, ograniczenia dotyczące kopiowania realnych wątków mailowych.
Przykłady zastosowań prostego LLM w programie szkoleń
Modele GPT i podobne potrafią bardzo przyspieszyć pracę przy tworzeniu treści, szczególnie na etapie szkicowania. Kilka praktycznych zastosowań:
Generowanie maili phishingowych – na podstawie opisu „pracownik działu sprzedaży, system CRM, promocja dla klienta X” można wygenerować kilka wariantów maila, a następnie je dopracować i zaadoptować do realiów firmy.
Tworzenie wariantów SMS/WhatsApp – szybkie przepisanie maila „kuriera” na krótką wiadomość tekstową, z uwzględnieniem ograniczonej liczby znaków.
Budowanie materiałów edukacyjnych i feedbacku z użyciem AI
Symulacja phishingu bez sensownego feedbacku zamienia się w grę „kliknął/nie kliknął”. AI pozwala podnieść poziom: spersonalizować informację zwrotną, dopasować treść mikro‑szkoleń i zbudować coś na kształt „trenera osobistego” dla użytkownika.
Dynamiczne ekrany po kliknięciu – po wejściu w link z kampanii użytkownik nie powinien widzieć jednego, stałego komunikatu. Model językowy może generować krótką, zrozumiałą podpowiedź dopasowaną do treści maila i roli pracownika („jako osoba z finansów, przy takich prośbach o przelew zawsze sprawdź telefonicznie nadawcę”).
Podsumowania dla „nieklikających” – osoby, które prawidłowo zignorowały lub zgłosiły phishing, też mogą dostać mini‑feedback. AI złożone z logów i zachowania użytkownika może wskazać, co zrobił dobrze i jak może dodatkowo wzmocnić swoje nawyki.
Mikro‑lekcje na żądanie – na podstawie zachowania w kampaniach (np. częste klikanie w linki zewnętrzne) AI może zaproponować krótki moduł: 5‑minutowy tekst lub wideo, które tłumaczy konkretny błąd, a nie ogólną „higienę bezpieczeństwa”.
Mit: „jak ktoś kliknął, trzeba mu zrobić długie szkolenie”. Rzeczywistość: lepiej działa kilkuminutowy, konkretny feedback natychmiast po zdarzeniu niż dwugodzinny wykład tydzień później.
Modele językowe dobrze sprawdzają się też przy tworzeniu materiałów pomocniczych dla zespołów technicznych.
Streszczenia incydentów – z logów, ticketów i notatek analityków można wygenerować krótką, zrozumiałą narrację: co się wydarzyło, jakie były punkty decyzyjne, czego zabrakło.
Checklisty powarsztatowe – po ćwiczeniu tabletop AI może ułożyć listę „do poprawy” i „do utrzymania”, podzieloną na zespoły (SOC, IT, biznes), zamiast zostawiać uczestników z chaotycznymi notatkami.
AI jako „sparring partner” dla SOC i inżynierów bezpieczeństwa
Przy pracy z zespołami technicznymi AI można wykorzystać nie tylko do generowania treści phishingowych, lecz także jako narzędzie do symulowania toku myślenia atakującego.
Analiza śladów w logach – po zasileniu modelu fragmentami z SIEM/EDR (zanonimizowanymi) można poprosić o „hipotezę ataku”: jak intruz mógł się poruszać, jakie miał cele, jakie kolejne kroki są prawdopodobne.
Ćwiczenia z korelacji alertów – AI może tworzyć zadania typu „z tych pięciu alertów wybierz te, które należą do jednego incydentu” i weryfikować uzasadnienie analityka.
Symulowane rozmowy z „atakującym” – w bezpiecznym środowisku analityk może prowadzić dialog z modelem grającym rolę intruza (np. w scenariuszach response na ransomware), ćwicząc argumentację i sposób oceny żądań.
Częsty mit: SOC „i tak wie lepiej niż AI”. Doświadczenie zespołu jest kluczowe, ale model może pomóc sprawdzić alternatywne ścieżki ataku, zaproponować nietypowe hipotezy i po prostu przyspieszyć etap burzy mózgów.
Projektowanie realistycznych scenariuszy phishingu z pomocą AI
Jak zebrać dane wejściowe do tworzenia scenariuszy
Najsłabsze kampanie phishingowe widać od razu: są oderwane od realiów firmy, brzmią jak „uniwersalny spam” i uczą jedynie rozpoznawania literówek. AI nie naprawi tego automatycznie – najpierw trzeba dostarczyć mu sensowny kontekst.
Dobrym punktem startu jest prosty „brief” scenariusza, przygotowany przez zespół bezpieczeństwa razem z przedstawicielami biznesu:
jakie procesy są kluczowe (faktury, HR, zamówienia, systemy klientów),
jakich narzędzi używa się na co dzień (CRM, system ticketowy, portal benefitowy),
jak wygląda typowy dzień pracy w danej roli,
jakie ataki faktycznie dotknęły branżę w ostatnim czasie.
Na tej podstawie można budować prompt dla modelu: opis roli (np. „specjalista ds. kadr”), sytuacji (np. „zestawienie nieodebranych urlopów”) i celu (np. „zachęcić do kliknięcia w link prowadzący do fałszywego portalu SSO”).
Iterowanie scenariusza: od „szkicu” do wysyłki
Model zwykle w pierwszym podejściu generuje zbyt oczywiste lub zbyt ogólne treści. Dlatego konieczna jest iteracja – trochę jak praca z młodszym specjalistą.
Szkic – prosisz AI o kilka wariantów maila na podstawie briefu, bez przywiązywania się do detali.
Uszczegółowienie – poprawiasz nazwy systemów, zmieniasz żargon, dopasowujesz ton (bardziej formalny dla zarządu, bardziej bezpośredni dla sprzedaży).
Dodanie „haczyków” – wskazujesz elementy, które mają być podejrzane, ale nie oczywiste: nieco inny adres nadawcy, subtelna różnica w domenie, niecodzienna prośba o termin.
Weryfikacja ryzyk – zespół etyczny lub compliance sprawdza, czy treść nie jest zbyt wrażliwa (np. nie dotyka tematów medycznych, sporów pracowniczych, sytuacji rodzinnych).
Dopiero po takim cyklu warto dopuścić scenariusz do kampanii. Automatyczne „weź co wygenerowało AI i wyślij” to prosta droga do wpadki wizerunkowej.
Dopasowanie trudności scenariuszy do dojrzałości organizacji
Skala trudności scenariuszy ma znaczenie. Jedna z częstszych porażek programów szkoleniowych: start od super‑zaawansowanych, „APT‑owych” przynęt w organizacji, która dopiero wprowadza podstawowe zasady higieny bezpieczeństwa.
Poziom podstawowy – proste, ale realistyczne maile: prośba o pilną zmianę hasła, „faktura do opłacenia”, oferta benefitów. Akcent na rozpoznawanie niespójności, niepewnych linków, nietypowych próśb.
Poziom średni – wykorzystanie wiedzy o realnych projektach i partnerach, użycie brandingu firmy, odwołanie do prawdziwych wydarzeń (np. migracja systemu, reorganizacja działu).
Poziom zaawansowany – scenariusze wieloetapowe: mail + telefon, wcześniejszy rekonesans w social media, podszywanie się pod wewnętrzne konta, smishing powiązany z kampanią mailową.
AI ułatwia „skalowanie” trudności – z jednego bazowego scenariusza można wygenerować wersję prostszą i trudniejszą, zmieniając liczbę sygnałów ostrzegawczych.
Tworzenie kampanii wielokanałowych: mail, SMS, komunikatory
Realni atakujący coraz częściej łączą kanały. AI świetnie wspiera przerabianie jednego motywu na różne formy przekazu, tak by kampania odzwierciedlała rzeczywistość.
Przykład praktyczny:
model generuje główny mail o „problemie z dostawą sprzętu”,
na jego podstawie tworzy krótki SMS „od kuriera” z linkiem śledzenia przesyłki,
następnie przygotowuje wersję komunikatu pod Teams/Slack, wysłaną niby przez „dział administracji”, proszącą o szybkie potwierdzenie adresu.
Różnica między dobrym a złym wykorzystaniem AI polega na kontroli spójności. Wszystkie te wiadomości muszą logicznie się łączyć, mieć ten sam scenariusz w tle i odpowiednią chronologię.
Symulacje vishingu i wykorzystanie głosu syntetycznego
Vishing jest dla wielu organizacji terra incognita. AI, zwłaszcza modele generujące głos, umożliwiają przeprowadzenie bardziej zaawansowanych ćwiczeń, ale wymaga to rozsądku.
Skrypty rozmów – na podstawie scenariusza (np. podszywanie się pod pracownika banku) można wygenerować zestaw pytań, możliwych odpowiedzi ofiary i sposobów przejścia do „domknięcia” ataku.
Nagrania demo – syntetyczny głos może posłużyć jako wzór rozmowy treningowej dla zespołu helpdesku czy recepcji, bez dzwonienia do realnych osób.
Kontrolowane ćwiczenia na żywo – jeśli organizacja dopuszcza dzwonienie do pracowników w celach szkoleniowych, można wspierać się AI do generowania modyfikacji skryptu „na ucho” dla trenera, aby reagował na odpowiedzi rozmówcy.
Tu pojawia się delikatna granica etyczna. Wykorzystanie syntetycznych głosów podobnych do członków zarządu czy znanych osób z firmy to proszenie się o kryzys zaufania. Lepiej z góry wprowadzić zasadę: nie klonujemy głosu pracowników, korzystamy z neutralnych, „anonimowych” lektorów.
Źródło: Pexels | Autor: cottonbro studio
Automatyzacja kampanii phishingowych: jak nie zamienić ludzi w „klikaczy”
Ustalanie częstotliwości i „dawki” szkoleń
AI kusi możliwością wysyłania dużej liczby zróżnicowanych przynęt. To, że można, nie znaczy, że trzeba. Zbyt częste kampanie powodują zmęczenie materiału – ludzie przestają rozróżniać, co jest realną komunikacją, a co testem.
Sensowny punkt odniesienia to kilka kampanii rocznie na pracownika, ale ich intensywność powinna zależeć od:
profilu ryzyka roli (finanse, zarząd vs. back‑office),
dotychczasowych wyników (częste błędy vs. stabilna poprawa),
innych działań edukacyjnych w tym samym czasie (wdrożenia, zmiany systemów).
AI może tu pomagać w segmentacji: zamiast wysyłać tę samą liczbę maili wszystkim, wyznaczasz „dawkę” na podstawie zachowania. Osoby stale reagujące poprawnie mogą mieć mniej symulacji, za to bardziej złożone; osoby z większym ryzykiem – częstsze, ale prostsze i dobrze opatrzone feedbackiem.
Personalizacja bez „profilowania karzącego”
Automatyzacja kusi, by budować „czarne listy klikających” i stale „atakować” tę samą grupę. To krótkoterminowo może poprawić statystyki, ale długoterminowo rozwala kulturę bezpieczeństwa.
Lepsze podejście to budowanie segmentów edukacyjnych, a nie „list winnych”. AI może tu działać na danych zanonimizowanych lub pseudonimizowanych:
analizuje wzorce błędów (np. częste otwieranie załączników .zip),
grupuje użytkowników o podobnych zachowaniach,
proponuje zestaw scenariuszy i mikro‑szkoleń dla danej grupy (np. krótki moduł o weryfikacji linków i domen).
Mit: „personalizacja musi oznaczać wskazywanie winnych z imienia i nazwiska”. Rzeczywistość: da się personalizować treści i ścieżki edukacyjne, nie wystawiając ludzi na publiczny ostrzał.
Ustalanie limitów automatyzacji i roli człowieka
Automatyzacja z AI powinna mieć wyraźne „bezpieczniki”. Zespół bezpieczeństwa musi mieć kontrolę nad tym, co wychodzi do organizacji i jak jest interpretowane.
Ręczna akceptacja kampanii – żaden nowy scenariusz nie powinien trafić do wysyłki bez przejrzenia przez człowieka: treść, grupa docelowa, timing.
Limity częstotliwości – system powinien móc zablokować wysyłkę do osoby, która np. w danym miesiącu już kilka razy brała udział w kampaniach, żeby uniknąć przemęczenia.
Mechanizm „pauzy” – jeśli w organizacji dzieje się coś dużego (incydent, migracja systemu, zmiany w HR), możliwość zatrzymania wszystkich kampanii jednym przyciskiem to nie luksus, lecz konieczność.
Rola AI jest wspierająca: sugeruje, podpowiada, grupuje dane. Decyzje o tonie komunikacji, poziomie „agresywności” scenariuszy i momencie ich realizacji powinny należeć do ludzi.
Łączenie automatycznych kampanii z ćwiczeniami „na żywo”
Symulacje oparte na mailach i SMS‑ach to tylko część obrazu. Prawdziwe umiejętności zespołów bezpieczeństwa testuje się w ćwiczeniach „na żywo”: tabletop, red teaming, symulowane incydenty. AI może być klejem łączącym te światy.
Przykładowy układ:
kampania phishingowa z użyciem AI generuje serię maili do wybranej grupy,
część użytkowników zgłasza podejrzane maile, część klika,
na podstawie zgłoszeń i logów AI tworzy streszczenie „incydentu”,
to streszczenie staje się punktem wyjścia do ćwiczenia tabletop dla SOC/IT („od tego momentu macie informacje X i Y – co robicie dalej?”).
Taka kombinacja pozwala szkolić jednocześnie: użytkowników końcowych (na poziomie nawyków), helpdesk (na poziomie przyjmowania zgłoszeń), SOC (na poziomie analizy) i kierownictwo (na poziomie decyzji biznesowych).
Od statystyk kliknięć do metryk dojrzałości
Automatyzacja z AI sprzyja „fetyszowi procentów”: ile osób kliknęło, ilu zgłosiło, jaki był CTR na link. Same te liczby są zbyt płytkie, by ocenić dojrzałość organizacji.
Projektowanie wskaźników, które naprawdę coś mówią
Same liczby kliknięć to za mało, by wyciągać wnioski o poziomie bezpieczeństwa. Przypominają oglądanie meczu tylko po wyniku, bez analizy gry.
Czas reakcji – ile mija od otrzymania podejrzanego maila do pierwszego zgłoszenia? Przy rosnącej dojrzałości ten czas się skraca, nawet jeśli pojedyncze osoby nadal klikają.
Ścieżka użytkownika – czy osoba, która kliknęła, zatrzymała się na stronie logowania, czy wprowadziła dane? Kliknięcie to błąd; przekazanie danych to realny incydent szkoleniowy.
Źródło zgłoszenia – ile zgłoszeń pochodzi z wbudowanego przycisku „Zgłoś phishing” w kliencie poczty, a ile z telefonów do helpdesku czy wiadomości na komunikatorach.
Jakość zgłoszeń – czy użytkownicy odróżniają SPAM marketingowy od potencjalnie niebezpiecznego phishingu, czy zgłaszają wszystko jak leci.
Mit: „spadek procenta kliknięć = organizacja jest bezpieczna”. Rzeczywistość: można mieć niskie kliknięcia dzięki temu, że ludzie po prostu ignorują maile – także te ważne. Znacznie ciekawsze są parametry zachowania: jak szybko reagują, jak opisują problem, czy angażują odpowiednie osoby.
AI pomaga przejść od surowych logów do bardziej złożonych miar. Może automatycznie łączyć dane z systemu pocztowego, SIEM i platformy szkoleń, tworząc wskaźniki typu:
„średni czas od dostarczenia maila do pierwszego zgłoszenia dla danej jednostki”,
„odsetek scenariuszy, w których SOC zareagował przed eskalacją do realnego incydentu” (w symulowanym środowisku),
„liczba poprawnych decyzji w ćwiczeniach tabletop, które zaczynały się od kampanii phishingowej”.
Takie metryki lepiej oddają dojrzałość całego ekosystemu, a nie tylko tego, kto kliknął w link.
Włączenie metryk biznesowych do oceny szkoleń
Szkolenia bezpieczeństwa często pozostają w swojej bańce: procenty, raporty, wykresy, ale bez przełożenia na język zarządu. Tu AI może odciążyć zespół w żmudnej analityce, żeby łatwiej połączyć świat techniczny z biznesowym.
Przy projektowaniu wskaźników przydatne są pytania:
jak szkolenia wpływają na czas obsługi realnych incydentów powiązanych z phishingiem,
czy maleje liczba fałszywych pozytywów zgłaszanych do SOC (czyli zgłoszeń, którymi nie trzeba się zajmować),
jak zmienia się obciążenie helpdesku w okresach kampanii (i czy nie trzeba skorygować harmonogramu).
AI może analizować logi incydentów, dane z ticketingu i z platform szkoleniowych, żeby pokazać prosty obraz: „po roku kampanii opartych na AI użytkownicy zgłaszają mniej błahych rzeczy, ale szybciej wyłapują naprawdę groźne maile”. To argument, który łatwiej uzasadnia budżet niż suchy wykres „CTR spadł o 3%”.
Mit bywa taki: „education ROI jest niemierzalny”. W praktyce problem leży nie w braku danych, ale w rozproszeniu; AI dobrze nadaje się do ich zintegrowania i przetworzenia w kilka sensownych wskaźników, które da się pokazać poza działem bezpieczeństwa.
Budowanie kultury uczenia się z incydentów przy wsparciu AI
Automatyczne „post‑mortem” z ćwiczeń i realnych zdarzeń
Każda kampania i każde realne zdarzenie to materiał szkoleniowy – pod warunkiem że ktoś go systematycznie wykorzystuje. AI ułatwia przygotowanie zjadliwych podsumowań bez tygodni ręcznej pracy.
Przykładowy przepływ może wyglądać tak:
z systemu pocztowego i SIEM eksportowane są logi dotyczące konkretnego scenariusza lub incydentu,
model AI agreguje dane: chronologia, kanały, zaangażowane zespoły, czas reakcji,
na tej podstawie generowane jest zwięzłe „story” incydentu, dostosowane do grupy odbiorców (inny poziom szczegółowości dla SOC, inny dla kierownictwa, jeszcze inny dla użytkowników końcowych).
Takie automatyczne „post‑mortem” można następnie wykorzystać jako materiał do kolejnych ćwiczeń tabletop, krótkich webinarów czy modułów e‑learningowych. Zamiast abstrakcyjnych przykładów otrzymujesz historie osadzone w realiach własnej organizacji.
Różnica między mądrze a źle użytym AI polega na tonie. Modele mogą generować język łatwo odbierany jako oskarżycielski („użytkownik X popełnił błąd”), jeśli nie dostaną odpowiednich wytycznych. Lepiej trzymać się narracji procesowej: „na tym etapie system/organizacja zadziałały tak, a nie inaczej; co możemy poprawić”.
Anonimizacja i ochrona prywatności w analizie incydentów
Wraz z rosnącą automatyzacją rośnie ryzyko, że dane o błędach konkretnych osób rozleją się po systemach analitycznych. AI może zamiast tego wspierać kulturę „bez nazwisk” przy omawianiu wpadek.
Dość proste jest wdrożenie mechanizmów, w których:
identyfikatory użytkowników są pseudonimizowane przed przekazaniem do modeli AI,
raporty syntetyczne domyślnie operują na poziomie grup (działy, profile ról), a nie jednostek,
dostęp do widoku „imiennych” danych ma bardzo wąska, jasno zdefiniowana grupa (i to niekoniecznie zespół bezpieczeństwa, a raczej HR / compliance przy poważnych naruszeniach).
Mit: „bez wskazywania winnych ludzie niczego się nie nauczą”. W praktyce groźba publicznego napiętnowania powoduje, że incydenty są ukrywane, a zgłoszenia opóźniane. Modele AI świetnie nadają się do zaciągania danych z wielu źródeł i ich odanonimizowania na potrzeby nauki – ale to człowiek musi postawić granicę, gdzie kończy się analiza, a zaczyna polowanie na jednostki.
Wykorzystanie AI jako „trenera na żądanie”
Zespoły bezpieczeństwa rzadko mają czas, żeby indywidualnie tłumaczyć każdemu użytkownikowi, dlaczego dany mail był podejrzany. Modele językowe mogą część tej pracy wziąć na siebie, tworząc spersonalizowany, ale anonimowy feedback.
Przykład praktyczny:
po każdym ćwiczeniu użytkownik, który kliknął, otrzymuje krótkie wyjaśnienie wygenerowane przez AI, odnoszące się do konkretnych elementów maila (nagłówek, domena, ton wypowiedzi),
osoba, która zgłosiła phishing, dostaje z kolei pozytywny, ale merytoryczny komentarz: „Jakie sygnały mogły cię zmylić? Co było dobrze, co da się zrobić jeszcze lepiej?”.
Kluczowe jest dobre przygotowanie promptów i szablonów, żeby komunikaty nie były sztuczne ani moralizatorskie. Modele powinny trzymać się neutralnego, rzeczowego tonu, bez „punktowania” użytkownika, raczej w duchu: „tu był trudny scenariusz, popatrzmy razem, co można z niego wyciągnąć”.
Rozwijanie kompetencji zespołu bezpieczeństwa z pomocą AI
Symulacje pracy SOC: od alertu do pełnego obrazu ataku
AI potrafi symulować nie tylko atakujących, ale także środowisko, w którym operuje SOC. Na bazie logów z poprzednich zdarzeń i publicznych scenariuszy zagrożeń można budować wirtualne „piaskownice” do ćwiczeń.
Elementy takiej symulacji to na przykład:
automatycznie generowane alerty z różnych źródeł (poczta, endpointy, firewall, proxy),
fabrykowane, ale realistyczne artefakty: próbki logów, „zrzuty” z systemów, komunikacja między atakującymi,
dynamicznie modyfikowany scenariusz w zależności od decyzji analityków (AI „dogrywa” kolejne elementy, jeśli SOC podejmie konkretną akcję).
Mit, który często się pojawia: „dobre ćwiczenie wymaga pełnego, ręcznego przygotowania przez red team”. To podejście skaluje się słabo. AI jest w stanie wygenerować wiele wariantów tego samego ataku, zmieniając tylko wektor wejścia (inny typ phishingu) czy narzędzia użyte w kolejnych fazach. Red team wtedy mniej „klepie” powtarzalne rzeczy, a bardziej projektuje logikę całego scenariusza.
Ćwiczenia tego typu pomagają zespołowi SOC nie tylko lepiej rozpoznawać ślady phishingu, ale też trenować:
priorytetyzację alertów (co analizować najpierw),
współpracę z innymi jednostkami (IT, HR, komunikacja),
decyzje o eskalacji i komunikowaniu ryzyka do biznesu.
AI jako partner do „dry‑runów” playbooków
Wiele organizacji ma playbooki reagowania na incydenty tylko na papierze. AI może posłużyć jako przeciwnik w „suchym przebiegu” procedur: odgrywa rolę środowiska technicznego i użytkowników, podczas gdy zespół bezpieczeństwa testuje swoje procesy.
Przykładowy scenariusz:
Zespół uruchamia ćwiczenie, w którym punktem wyjścia jest zgłoszenie phishingu od użytkownika.
Model AI generuje kolejne komunikaty, logi i pytania „otoczenia” (np. mail od działu prawnego, telefon z PR z pytaniem, czy to może dotknąć klientów).
Zespół reaguje według playbooka, a AI na bieżąco modyfikuje tło sytuacyjne, symulując eskalację lub wygaszenie incydentu.
Taki tryb pozwala szybko wychwycić luki: brak kontaktu do konkretnej osoby, niejasne kryteria eskalacji, rozbieżności między działami. Modele językowe dobrze nadają się do odgrywania „głosu biznesu”, który w realnych incydentach często pojawia się nagle i z mocnymi oczekiwaniami.
Indywidualny trening analityków na podstawie ich stylu pracy
Automatyczna analiza logów pracy SOC (np. jakie zapytania do SIEM są najczęściej używane, jaki jest czas między alertem a decyzją) daje zestaw danych, z których AI może wyciągnąć profile zachowań analityków.
Bez wchodzenia w sferę „oceny ludzi przez algorytm”, da się podejść do tego rozwojowo:
identyfikacja mocnych stron (np. osoba A świetnie koreluje logi sieciowe, osoba B szybko wyciąga kontekst z ticketów użytkowników),
tworzenie dedykowanych ćwiczeń – AI generuje cases, które celowo wystawiają analityka na mniej komfortowe obszary,
propozycje par mentoringowych (kto może kogo wesprzeć, patrząc na uzupełniające się style pracy).
Rzeczywistość jest taka, że wielu analityków SOC po kilku miesiącach pracy utknęło w wąskiej niszy (konkretne typy alertów, konkretne narzędzia). Modele AI, karmione danymi o ich pracy, pomagają zaproponować ćwiczenia wyciągające ich poza tę strefę, bez stygmatyzowania kogokolwiek.
Integracja AI‑wspieranych szkoleń z procesami HR i compliance
Personalizowane ścieżki rozwoju ról wysokiego ryzyka
Nie każdy użytkownik musi przechodzić to samo szkolenie. AI ułatwia automatyczne dopasowanie treści do rodzaju roli i ekspozycji na ryzyko, bez ręcznego projektowania dziesiątek ścieżek.
Przykładowe segmenty, które często wymagają odrębnego traktowania:
zarząd i osoby z dostępem do informacji poufnych,
działy finansowe, księgowość, zakupy,
działy obsługi klienta i helpdesk (częste interakcje z zewnętrznymi nadawcami),
zespoły techniczne z szerokimi uprawnieniami systemowymi.
Na podstawie profilu stanowiska oraz historii udziału w kampaniach AI może proponować:
inne scenariusze phishingu (np. dla CFO – podszywanie się pod partnerów biznesowych i prośby o przelewy, dla obsługi klienta – ataki przez zgłoszenia serwisowe),
inne formy szkoleń uzupełniających (np. krótkie wideo, interaktywne quizy, ćwiczenia tabletop),
inny język i poziom technicznych szczegółów.
Mit: „im wyżej w hierarchii, tym prostsze szkolenia, bo nie ma czasu na szczegóły”. Praktyka pokazuje, że zarząd i top management są często głównym celem ukierunkowanych kampanii, a przy tym najrzadziej szkoloną grupą. Tu AI może podsunąć krótkie, bardzo konkretne materiały, oparte na scenariuszach „jak atakują właśnie takich jak ty”.
Zgodność z regulacjami a wykorzystanie generatywnej AI
Wielu szefów bezpieczeństwa i compliance obawia się, że korzystanie z generatywnej AI w szkoleniach będzie trudne do pogodzenia z wymogami regulacyjnymi (RODO, sektorowe wytyczne, polityki grupowe). Te obawy są zrozumiałe, ale często wynikają z braku jasnych zasad.
Bezpieczny model działania zwykle obejmuje kilka elementów:
wyraźne ograniczenie danych – do modeli nie trafiają dane pozwalające na identyfikację konkretnych osób (nazwiska, adresy mailowe, ID), jeśli nie ma bardzo dobrego powodu i podstawy prawnej,
lokalne lub kontrolowane środowisko – generowanie scenariuszy i analiza wyników odbywają się w infrastrukturze pod kontrolą organizacji lub dostawcy spełniającego wymogi prawne,
Bibliografia
NIST Special Publication 800-50: Building an Information Technology Security Awareness and Training Program. National Institute of Standards and Technology (2003) – Ramy programów security awareness i szkoleń dla użytkowników
NIST Special Publication 800-61 Revision 2: Computer Security Incident Handling Guide. National Institute of Standards and Technology (2012) – Zalecenia dot. obsługi incydentów, ról SOC/CSIRT i eskalacji
ENISA Threat Landscape 2023. European Union Agency for Cybersecurity (ENISA) (2023) – Przegląd trendów ataków, w tym phishingu i socjotechniki
