Syndrom oszusta w cyberbezpieczeństwie: kiedy doświadczeni specjaliści IT/OT nie ufają własnym ostrzeżeniom

Kontekst: organizacja może mieć wiedzę, której nigdy nie usłyszy

Znowelizowana ustawa o Krajowym Systemie Cyberbezpieczeństwa, wdrażająca dyrektywę NIS2, wymaga od podmiotów kluczowych i ważnych nie tylko wdrożenia zabezpieczeń, lecz także systematycznego zarządzania ryzykiem, obsługi incydentów, oceny skuteczności zastosowanych środków oraz budowania kompetencji osób odpowiedzialnych za bezpieczeństwo. Na poziomie organizacyjnym oznacza to konieczność stałego wychwytywania słabych sygnałów: nietypowej konfiguracji, niejasnego wyjątku w dostępie, ryzykownego założenia projektowego albo zależności między systemami, której nie widać w dokumentacji.

Takie sygnały rzadko przychodzą jednak w formie gotowego raportu z jednoznacznym dowodem. Najczęściej zaczynają się od czyjejś wątpliwości: „coś w tej architekturze mi się nie zgadza”, „nie potrafię jeszcze wykazać błędu, ale ten scenariusz wygląda niebezpiecznie”, „warto sprawdzić to drugi raz”. Właśnie dlatego dojrzałość systemu bezpieczeństwa zależy nie tylko od tego, ilu ekspertów zatrudnia organizacja, ale także od tego, czy ci eksperci zabierają głos, zanim uzyskają stuprocentową pewność.

Tu pojawia się zjawisko potocznie nazywane syndromem oszusta. Doświadczony specjalista może znać środowisko lepiej niż ktokolwiek inny, a mimo to zakładać, że inni przeceniają jego kompetencje. Zamiast potraktować własną wątpliwość jako informację wymagającą weryfikacji, traktuje ją jak potencjalny dowód osobistej niewiedzy. Sprawdza po raz kolejny, łagodzi komunikat, czeka na potwierdzenie osoby z wyższym statusem albo rezygnuje z eskalacji. Organizacja formalnie ma więc kompetencję, której potrzebuje, lecz operacyjnie nie potrafi z niej skorzystać.

Ten artykuł pokazuje, dlaczego zjawisko oszusta może zwiększać ryzyko przemilczanych luk w zespołach IT i OT, czym różni się od zwykłej ostrożności eksperckiej oraz jak budować kulturę, w której zgłoszenie niepewności jest elementem profesjonalizmu, a nie zagrożeniem dla zawodowej reputacji.

Mechanizm: dlaczego kompetencja nie zawsze daje poczucie kompetencji

Choć w języku potocznym przyjęło się określenie „syndrom oszusta”, literatura naukowa częściej mówi o zjawisku oszusta (ang. impostor phenomenon). Nie jest to odrębna jednostka chorobowa ani diagnoza kliniczna. Opisuje doświadczenie, w którym osoba mająca obiektywne osiągnięcia i potwierdzone kompetencje nie potrafi ich w pełni uznać za własne, a sukces tłumaczy szczęściem, wyjątkowym wysiłkiem, pomocą innych albo tym, że otoczenie jeszcze nie dostrzegło jej rzekomych braków.

Asymetria w wyjaśnianiu sukcesów i błędów. Osoba doświadczająca zjawiska oszusta stosuje wobec siebie nierówny standard oceny. Udane wdrożenie interpretuje jako efekt dobrego zespołu, sprzyjających okoliczności lub nadmiernego przygotowania. Pomyłkę przypisuje natomiast własnej niekompetencji. W cyberbezpieczeństwie, gdzie nawet dobra analiza często zawiera element niepewności, taki sposób myślenia szczególnie łatwo prowadzi do wniosku: „skoro nie potrafię tego jeszcze udowodnić, nie powinienem zabierać głosu”.

Perfekcjonistyczny próg eskalacji. Ryzyko rzadko daje się ocenić z matematyczną pewnością. Ekspert pracuje na przesłankach, prawdopodobieństwie, ograniczonej widoczności i niepełnej dokumentacji. Osoba obawiająca się zdemaskowania może jednak uznać, że ma prawo zgłosić problem dopiero wtedy, gdy zebrała kompletny materiał dowodowy i potrafi odpowiedzieć na każde możliwe pytanie. W praktyce ustawia sobie próg znacznie wyższy niż organizacja rzeczywiście potrzebuje, aby rozpocząć weryfikację.

Niewidoczność cudzej niepewności. W zespołach eksperckich ludzie porównują własne zaplecze myślowe z publicznymi wypowiedziami innych. Widzą wszystkie swoje wątpliwości, luki i warianty, których nie zdążyli sprawdzić. U kolegów widzą jedynie końcowy komunikat, często podany zdecydowanym tonem. Powstaje fałszywe wrażenie, że inni „po prostu wiedzą”, podczas gdy tylko sprawniej komunikują roboczą hipotezę. Im bardziej organizacja premiuje pewność wypowiedzi, tym silniej ten mechanizm zniechęca osoby ostrożne do wnoszenia zastrzeżeń.

Zagrożenie dla tożsamości eksperta. Im dłużej ktoś pracuje w danym środowisku, tym więcej ma do stracenia wizerunkowo. Junior może powiedzieć: „nie wiem, proszę o wyjaśnienie”, bo brak wiedzy jest wpisany w jego rolę. Od seniora oczekuje się odpowiedzi. W efekcie doświadczony administrator, architekt czy automatyk może szczególnie mocno obawiać się pytania, na które nie odpowie od razu. Paradoks polega na tym, że właśnie taka osoba często dostrzega problem wcześniej, ponieważ zna historię systemu, wyjątki i nieudokumentowane zależności.

Niepewność na granicy domen. W środowiskach IT/OT wiele ryzyk pojawia się pomiędzy specjalizacjami. Automatyk widzi, że zdalny dostęp serwisowy stwarza zagrożenie, ale nie uważa się za eksperta od cyberbezpieczeństwa. Specjalista bezpieczeństwa rozpoznaje ryzykowną architekturę, lecz nie zna konsekwencji zatrzymania linii produkcyjnej. Każdy może uznać, że osoba z drugiej domeny ma większe prawo do oceny sytuacji. Właśnie w tej przestrzeni kompetencje uzupełniają się albo – jeśli ludzie milczą – powstaje luka, której formalnie nie jest właścicielem nikt.

Zjawisko oszusta bywa przedstawiane jako proste przeciwieństwo efektu Dunninga-Krugera: niekompetentni są zbyt pewni siebie, a eksperci nie wierzą we własną wiedzę. To atrakcyjny obraz, ale zbyt uproszczony. Nie każda ostrożna osoba doświadcza zjawiska oszusta, nie każda osoba z dużą pewnością siebie ma małą wiedzę, a wątpliwość eksperta może być trafną oceną złożoności problemu. Kluczowe pytanie nie brzmi więc: „kto czuje się pewnie?”, lecz: czy organizacja potrafi oddzielić ton wypowiedzi od jakości przesłanek i zweryfikować sygnał bez oceniania wartości osoby, która go zgłosiła.

W cyberbezpieczeństwie bardzo rzadko dostajemy komfort pełnej pewności przed podjęciem działania. Dobry specjalista nie zawsze mówi kategorycznie, bo widzi ograniczenia danych i kilka możliwych scenariuszy. Jeżeli organizacja słyszy tylko osoby mówiące najgłośniej, traci część swojej najlepszej wiedzy technicznej – tę, która zaczyna się od zdania: „nie mam jeszcze dowodu, ale to trzeba sprawdzić".

Kamil Ciaś, współzałożyciel betternow.group | Chief Information Security Officer | Dyrektor ds. Bezpieczeństwa Informacji / Dyrektor ds. Cyberbezpieczeństwa

Jak milczenie eksperta wygląda w codziennej pracy

Zjawisko oszusta nie musi prowadzić do całkowitego wycofania. Częściej zmienia sposób, w jaki specjalista komunikuje ryzyko. Na pierwszy rzut oka jego zachowanie może wyglądać jak sumienność, skromność albo troska o jakość. Dopiero z perspektywy całego procesu widać, że organizacja otrzymuje informację później, w słabszej formie albo wcale.

„Jeszcze tylko to sprawdzę”. Specjalista zauważa niepokojącą konfigurację, ale przed zgłoszeniem chce wykluczyć każdą alternatywną interpretację. Wykonuje dodatkowe analizy poza formalnym zadaniem, konsultuje dokumentację i odtwarza historię zmian. Problem polega nie na dokładności, lecz na tym, że przez cały ten czas nikt inny nie wie o sygnale i nie może zdecydować, czy wymaga on szybszej, równoległej weryfikacji.

Zastrzeżenie zostaje ukryte pod warstwą asekuracyjnego języka. Komunikat „istnieje możliwość niekontrolowanego dostępu z sieci serwisowej do segmentu produkcyjnego” zmienia się w „być może warto kiedyś jeszcze spojrzeć na konfigurację połączenia”. Treść techniczna pozostaje podobna, ale jej znaczenie decyzyjne znika. Menedżer otrzymuje sugestię optymalizacyjną zamiast informacji o potencjalnym ryzyku.

Eskalacja tylko po uzyskaniu zewnętrznego potwierdzenia. Zamiast zgłosić wątpliwość bezpośrednio, specjalista szuka najpierw kogoś, kto ją potwierdzi – kolegi, dokumentacji producenta, wątku na forum branżowym. Samo poszukiwanie potwierdzenia bywa uzasadnione merytorycznie, ale gdy staje się warunkiem koniecznym przed jakimkolwiek zgłoszeniem, wydłuża czas reakcji proporcjonalnie do tego, jak trudno dostępne jest potwierdzenie.

Unikanie spotkań, na których trzeba bronić stanowiska wobec bardziej formalnego autorytetu. Osoba dysponująca wiedzą lokalną, ale bez wysokiego statusu formalnego, może unikać bezpośredniej konfrontacji z opinią konsultanta, audytora czy przełożonego, nawet jeśli dysponuje istotnymi informacjami. Milczenie na spotkaniu bywa mylnie odczytywane jako brak zastrzeżeń.

Nadmierne kwalifikowanie własnej wypowiedzi. Komunikat obudowany jest tak wieloma zastrzeżeniami („może się mylę, to pewnie nic ważnego, ale...”), że traci siłę przebicia, zanim dotrze do właściwego odbiorcy. Odbiorca komunikatu, oceniając go po tonie, może uznać sprawę za mało istotną, mimo że treść merytoryczna wskazuje inaczej.

Jak budować kulturę, w której wątpliwość jest sygnałem, nie słabością

Oddzielenie oceny jakości sygnału od oceny osoby, która go zgłasza. Organizacja powinna jasno komunikować, że zgłoszenie niepotwierdzonej jeszcze wątpliwości jest z definicji wartościowym wkładem, niezależnie od tego, czy ostatecznie okaże się trafne. Fałszywy alarm zgłoszony w dobrej wierze i szybko zweryfikowany kosztuje organizację znacznie mniej niż przemilczany, trafny sygnał.

Łączenie wiedzy domenowej zamiast hierarchii certyfikatów. Ocena zmian obejmujących IT i OT powinna angażować co najmniej po jednej osobie z każdej domeny, z jasno zakomunikowanym prawem do zatrzymania decyzji na czas krótkiej weryfikacji. Certyfikat bezpieczeństwa nie unieważnia wiedzy osoby, która zna zachowanie konkretnej instalacji, a wieloletnie doświadczenie operacyjne nie zastępuje analizy mechanizmu ataku. Potrzebna jest wspólna ocena, nie konkurs na „prawdziwszego eksperta”.

Rejestr decyzji wraz z informacją zwrotną dla zgłaszającego. Każdy sygnał powinien zakończyć się jednym z czytelnych statusów: potwierdzony, odrzucony na podstawie określonych danych, przyjęty jako ryzyko albo skierowany do dalszej analizy. Pracownik musi wiedzieć, co stało się z jego zgłoszeniem. Brak odpowiedzi uczy, że zabieranie głosu nie ma sensu; sama liczba dostępnych kanałów tego nie zmienia.

Kalibracja oparta na faktach, nie na ogólnych pochwałach. Po ćwiczeniu, audycie, zmianie lub incydencie warto wrócić do wcześniejszych przewidywań zespołu i porównać je z wynikiem. Kto trafnie zauważył zależność? Która hipoteza okazała się błędna, ale była rozsądna na podstawie dostępnych danych? Jakiej informacji zabrakło? Taki proces pomaga pracownikom budować realistyczną ocenę własnych kompetencji znacznie skuteczniej niż komunikat „musisz bardziej w siebie wierzyć”.

Ograniczenie kultury bohatera. Jeżeli organizacja nagradza osoby, które samotnie „ratują sytuację”, pracują po nocach i przechowują kluczową wiedzę we własnej głowie, wzmacnia zachowania charakterystyczne dla kompensowania poczucia niekompetencji. Doceniane powinny być także: wczesne przekazanie niepewności, poproszenie o drugą opinię, dobra dokumentacja i oddanie zadania osobie lepiej przygotowanej do jego części.

Studium przypadku

Producent żywności zatrudniający około 240 osób przygotowywał się do spełnienia obowiązków podmiotu ważnego wynikających ze znowelizowanej ustawy o KSC. Firma modernizowała linię pakującą, a wraz z nią wdrażała nową bramę zdalnego dostępu, która miała umożliwiać serwis producentowi maszyn bez każdorazowego przyjazdu technika na miejsce. Projekt był prowadzony wspólnie przez dział IT, zewnętrzną firmę zajmującą się cyberbezpieczeństwem oraz dostawcę automatyki.

W zespole pracowała automatyczka z czternastoletnim doświadczeniem, która znała instalację od momentu jej uruchomienia. Nie posiadała certyfikatów bezpieczeństwa ani formalnej roli w zespole wdrażającym KSC. Podczas przeglądu architektury zauważyła, że projekt zakłada stałe konto serwisowe używane przez kilku techników dostawcy, a połączenie z bramy prowadzi do stacji inżynierskiej mającej szerszy dostęp do sieci linii, niż wynikało to ze schematu przedstawionego na spotkaniu.

Zgłosiła uwagę ostrożnie: powiedziała, że „być może warto jeszcze sprawdzić zakres routingu”. Konsultant odpowiedzialny za cyberbezpieczeństwo odpowiedział, że rozwiązanie jest standardem producenta, tunel jest szyfrowany, a dostęp ma być uruchamiany tylko na potrzeby serwisu. Automatyk nie podjęła sporu. Uznała, że skoro konsultant zna normy, protokoły i wymagania KSC lepiej od niej, prawdopodobnie przesadza albo nie rozumie któregoś elementu zabezpieczenia.

Przez kolejne dwa tygodnie samodzielnie analizowała konfigurację w wolnych chwilach. Odkryła, że konto serwisowe nie było przypisane do konkretnych osób, rejestrowanie sesji obejmowało jedynie moment zestawienia tunelu, a reguła sieciowa pozwalała na dostęp również do starszego komputera inżynierskiego, na którym przechowywano pliki konfiguracyjne kilku sterowników. Nie wpisała jednak problemu do rejestru ryzyka. Obawiała się, że formalne zgłoszenie zostanie potraktowane jako podważanie pracy konsultanta, a szczegółowe pytania ujawnią, że nie zna części terminologii używanej w dokumentacji bezpieczeństwa.

Luka wyszła na jaw dopiero podczas ćwiczenia typu tabletop, w którym scenariusz zakładał przejęcie danych uwierzytelniających pracownika zewnętrznego serwisu. Zespół próbował ustalić, jakie działania napastnik mógłby wykonać po zestawieniu połączenia, i wtedy automatyczka pokazała własne notatki. Okazało się, że jej obawy były zasadne: szyfrowanie tunelu chroniło transmisję, ale nie rozwiązywało problemu współdzielonej tożsamości, nadmiernego zakresu dostępu ani ograniczonej rozliczalności działań wykonywanych po stronie OT.

Analiza po ćwiczeniu nie wykazała braku wiedzy technicznej. Wykazała błąd w sposobie wykorzystania wiedzy dostępnej w organizacji. Osoba, która najlepiej znała rzeczywiste zależności instalacji, uznała swoją perspektywę za mniej wartościową od formalnego statusu zewnętrznego eksperta. Z kolei proces przeglądu architektury nie zawierał żadnego mechanizmu, który wymagałby zapisania i rozstrzygnięcia zdania odrębnego.

Firma wprowadziła trzy zmiany. Każdy przegląd rozwiązania łączącego IT i OT kończył się odtąd obowiązkowym zapisem otwartych wątpliwości, nawet jeśli nie były jeszcze potwierdzonymi lukami. Każdy taki sygnał otrzymywał właściciela oraz termin weryfikacji. Dodatkowo decyzje o zdalnym dostępie wymagały wspólnej akceptacji przedstawiciela bezpieczeństwa i osoby odpowiedzialnej za daną instalację. Samo ćwiczenie wykorzystano nie do wskazania, kto „przeoczył” problem, lecz do pokazania zespołowi, że wiedza o ryzyku może być rozproszona między różnymi specjalizacjami i musi zostać połączona przed podjęciem decyzji.

Najgroźniejsze nie jest to, że ekspert czasem ma wątpliwości. Najgroźniejsze jest środowisko, w którym uważa, że przed zabraniem głosu musi najpierw udowodnić swoją nieomylność. Organizacja nie potrzebuje ludzi pewnych każdej odpowiedzi. Potrzebuje procesu, który potrafi bezpiecznie przyjąć zdanie: „mogę się mylić, ale widzę ryzyko" – i zamienić je w rzetelną weryfikację.

Edyta Müller-Ciaś, współzałożycielka betternow.group | Chief Change & Culture Officer | dyrektorka ds. rozwoju organizacji | ekspertka ds. zarządzania zmianą i psychologii biznesu

Wnioski praktyczne

• Zjawisko oszusta nie oznacza braku kompetencji. Polega na trudności w uznaniu własnych osiągnięć i trafnym oszacowaniu wartości własnej wiedzy mimo obiektywnych przesłanek, że jest ona realna.
• W cyberbezpieczeństwie szczególnie ryzykowny jest perfekcjonistyczny próg eskalacji: oczekiwanie pełnego dowodu przed zgłoszeniem wątpliwości sprawia, że organizacja traci możliwość wczesnej, równoległej weryfikacji słabego sygnału.
• Zjawisko oszusta nie jest prostym przeciwieństwem efektu Dunninga-Krugera. Poziom pewności wypowiedzi nie powinien zastępować oceny jakości danych, doświadczenia domenowego i przyjętych założeń.
• Kultura no-blame nie jest literalnym, samodzielnym wymogiem NIS2 ani ISO/IEC 27001, ale środowisko karzące za uczciwe zgłaszanie niepewności osłabia procesy zarządzania ryzykiem, raportowania zdarzeń i uczenia się, których te ramy wymagają.
• Organizacja powinna zapewnić kanał do zgłaszania „sygnałów ryzyka”, które nie są jeszcze potwierdzoną luką, oraz obowiązek ich udokumentowanego rozstrzygnięcia i przekazania informacji zwrotnej zgłaszającemu.
• Najskuteczniejsze interwencje nie polegają na nakłanianiu ekspertów, by „bardziej w siebie wierzyli”, lecz na projektowaniu spotkań, rejestrów i decyzji tak, aby wątpliwość mogła zostać sprawdzona bez narażania zawodowej reputacji osoby, która ją zgłasza.
• W środowiskach IT/OT szczególne znaczenie ma równy status wiedzy technicznej i wiedzy lokalnej. Ryzyko często powstaje na granicy domen, dlatego żadna z nich nie powinna samodzielnie unieważniać perspektywy drugiej.

Czy w Twojej organizacji specjalista może zgłosić niepotwierdzoną jeszcze wątpliwość bez obawy, że zostanie rozliczony z samego faktu jej podniesienia? BetterNow.Group łączy wiedzę techniczną z zakresu cyberbezpieczeństwa z doświadczeniem w projektowaniu kultury organizacyjnej i procesów decyzyjnych, które pozwalają wychwytywać ryzyko, zanim zamieni się w incydent. Skontaktuj się z nami.