Test phishingowy a zaufanie pracowników

TL;DR

NL Health Services w Kanadzie przeprosiło po teście phishingowym, w którym pracownikom i lekarzom obiecano dodatkowy płatny dzień wolny. Kliknięcie w przycisk nie dawało wolnego dnia, tylko oznaczało niezaliczenie ćwiczenia. The Register opisał przeprosiny organizacji, a Registered Nurses' Union Newfoundland & Labrador wskazał, że użycie takiej przynęty było szczególnie nietrafione przy zmęczeniu, brakach kadrowych i napięciach wokół wdrożenia systemu CorCare.

To nie jest argument przeciwko testom phishingowym. To argument za lepszym projektowaniem testów. Symulacja ma budować odporność, a nie podważać zaufanie do programu awareness, działu IT albo HR. Jeżeli scenariusz dotyka wynagrodzenia, urlopu, zdrowia, zatrudnienia, redukcji etatów albo realnych konfliktów w organizacji, powinien przejść dodatkowy przegląd.

Wniosek dla firm jest prosty: dobry test phishingowy mierzy decyzję użytkownika, ale nie wykorzystuje jego realnej krzywdy jako przynęty.

Co się stało w Kanadzie

Według The Register kanadyjska organizacja ochrony zdrowia NL Health Services przeprowadziła wewnętrzny test phishingowy, który fałszywie oferował pracownikom dodatkowy płatny dzień wolny. Wiadomość odwoływała się do pracy przy wdrożeniu CorCare i zapraszała do kliknięcia przycisku w celu odebrania rzekomego benefitu.

Po krytyce organizacja przeprosiła pracowników, lekarzy i przedstawicieli związkowych oraz zapowiedziała przegląd sposobu projektowania przyszłych ćwiczeń. Związek pielęgniarek zwrócił uwagę, że problemem nie była sama edukacja cyberbezpieczeństwa, lecz wybór przynęty w środowisku, w którym pracownicy od dawna mierzą się z przeciążeniem, brakiem kadr i trudnością w korzystaniu z urlopów.

To dobry przykład krótkiego, ale ważnego ryzyka: test phishingowy może być formalnie skuteczny, bo generuje kliknięcia, a jednocześnie organizacyjnie szkodliwy, bo niszczy zaufanie.

Gdzie był błąd w scenariuszu

Problemem nie była realistyczność. Prawdziwe phishingi często wykorzystują premie, benefity, kadry, nadgodziny i urlopy. Problemem było użycie przynęty, która dotyczyła realnego napięcia w organizacji.

W testach phishingowych najłatwiej wpaść w pułapkę myślenia: skoro przestępcy mogą użyć takiej przynęty, to my też powinniśmy. To zbyt proste. Symulacja musi brać pod uwagę relację między pracownikiem a pracodawcą. Atakujący nie odpowiada za kulturę organizacyjną. Firma odpowiada.

Jeżeli pracownik czuje, że wykorzystano jego zmęczenie, frustrację albo brak urlopu, to nie zapamięta dobrych praktyk. Zapamięta, że cyberbezpieczeństwo jest narzędziem karania. Taki efekt obniża skuteczność kolejnych kampanii awareness.

Polski kontekst dla firm i instytucji

W Polsce podobny błąd mógłby dotyczyć fałszywej wiadomości o premii, dodatkowym dniu wolnym, podwyżce, benefitach, medycynie pracy, badaniach profilaktycznych, redukcji etatów, grafiku dyżurów albo zaległym rozliczeniu delegacji.

Takie scenariusze są szczególnie wrażliwe w ochronie zdrowia, administracji publicznej, edukacji, produkcji, logistyce i centrach usług, gdzie napięcia organizacyjne bywają realne. Jeżeli test dotyka tematu, który już jest źródłem frustracji, musi zostać potraktowany jak ryzyko komunikacyjne, nie tylko jak ćwiczenie IT.

Nie oznacza to zakazu testowania phishingu HR. Oznacza to, że scenariusze HR powinny być zaprojektowane z wyczuciem. Inaczej ćwiczenie przestaje być nauką, a staje się przykładem złego zarządzania zaufaniem.

Jak projektować testy phishingowe z sensem

Dobry test zaczyna się od pytania: jakie zachowanie chcemy zmierzyć? Kliknięcie w link to tylko jeden wskaźnik. Często ważniejsze jest to, czy pracownik zatrzymał proces, zgłosił wiadomość, sprawdził nadawcę, zapytał właściwy dział albo nie podał danych po kliknięciu.

Scenariusz powinien mieć właściciela, cel edukacyjny i przegląd ryzyka. W przypadku tematów HR, zdrowia, pieniędzy, urlopów i zatrudnienia warto zaangażować HR, komunikację wewnętrzną i osobę odpowiedzialną za kulturę organizacyjną. Nie po to, aby osłabić test, lecz po to, aby nie uderzyć w zaufanie.

W testach phishingowych dla firm chodzi o mierzenie odporności, a nie o łapanie ludzi na błędzie. Test ma pokazać, gdzie proces jest słaby: w treści wiadomości, w zgłaszaniu, w eskalacji, w reakcji po kliknięciu albo w komunikacji między działami.

Kiedy mocna przynęta ma sens

Mocna przynęta może mieć sens, jeśli jest proporcjonalna, uzasadniona i omówiona po ćwiczeniu. Przykładem może być fałszywa faktura, prośba o zmianę rachunku, link do resetu hasła albo wiadomość o nowym dostępie do systemu. To scenariusze, które realnie dotykają procesów biznesowych i dają konkretne wnioski dla użytkownika oraz organizacji.

Inaczej jest z przynętami, które dotykają emocjonalnie bolesnych tematów: zwolnienia, choroby, śmierci, urlopu po przeciążeniu, konfliktów płacowych czy realnych kryzysów w firmie. Takie scenariusze mogą wygenerować wysoki wskaźnik kliknięć, ale niski poziom zaufania po teście.

Dlatego przed użyciem mocnej przynęty warto zadać jedno pytanie: czy po omówieniu testu pracownik uzna, że organizacja go czegoś nauczyła, czy że wykorzystała jego sytuację?

Wnioski dla IT, Security, HR i awareness

IT i Security powinny projektować testy razem z ludźmi, którzy rozumieją kontekst pracowników. HR nie powinien być tylko nadawcą fałszywej wiadomości. Powinien być uczestnikiem przeglądu scenariusza.

Dział komunikacji może pomóc ocenić, czy treść nie brzmi jak obietnica pracodawcy, której pracownik ma prawo zaufać. Dział prawny lub compliance może ocenić, czy ćwiczenie nie wchodzi w obszary szczególnie wrażliwe. SOC może przygotować plan reakcji na zgłoszenia, aby użytkownicy widzieli, że raportowanie ma sens.

Najlepsze programy awareness nie opierają się na zawstydzaniu. Opierają się na powtarzalnym ćwiczeniu decyzji, szybkim feedbacku i zrozumieniu, że błąd użytkownika jest sygnałem do poprawy procesu.

Konkretna zasada na koniec

Test phishingowy powinien być realistyczny, ale nie powinien wykorzystywać realnej krzywdy pracowników. Jeżeli scenariusz dotyka wynagrodzenia, zdrowia, urlopu albo zatrudnienia, nie wystarczy zgoda IT. Potrzebny jest przegląd HR, komunikacji i ryzyka zaufania.