An elephant in the room
Wstęp
Czy znajomość zagadnień dotyczących psychologii konfliktu może być pomocna w zarządzaniu cyberbezpieczeństwem? Ja uważam, że tak. Czy cyberbezpieczeństwo organizacji to gra zespołowa? Tak powinno być, ale niestety zdarza się, że nie jest. Owszem, budowanie cyberbezpieczeństwa to gra zespołowa, tyle tylko, że w tej grze często bierze udział nie jeden, a wiele zespołów.
Czy to coś zmienia?
Niestety wiele. Kooperacja ustępuje rywalizacji, a jedyny cel, jaki widzą zespoły, to wzajemne – mniejsze lub większe – wyniszczanie. Można by wręcz powiedzieć, że jest to gra o sumie zerowej: żebym ja wygrał, ty musisz przegrać. Co by nie mówić, analogia sportowa jest tu bardzo trafna. Powstała sytuacja wzajemnej rywalizacji doprowadza do występowania różnego rodzaju napięć pomiędzy zespołami czy na poziomie całej organizacji, a co za tym idzie – do pojawienia się konfliktów.
Konflikt, czyli co?
Konfliktów się nie pozbędziemy. Tam, gdzie są ludzie i interakcje między nimi, tam z pewnością – prędzej czy później, a raczej prędzej – wystąpią konflikty. Podstawowe pytanie brzmi: „Dlaczego tak się dzieje?”. W wyjaśnieniu tego zjawiska z pomocą przychodzi definicja. Mówi ona, że konflikt pojawia się w sytuacji, w której współzależne od siebie osoby lub grupy angażują się w działania nakierowane na cele, które są – w rzeczywistości lub w ich odczuciu – niemożliwe do pogodzenia lub sprzeczne. Co to właściwie dla nas oznacza? Rozłóżmy tę definicję na elementy składowe, by lepiej ją zrozumieć.
Współzależność między osobami czy grupami
Skoro powiedzieliśmy, że cyberbezpieczeństwo to gra wielu zespołów czy indywidualności, to naturalne jest, że osoby te będą w jakiś sposób od siebie współzależne. W obszarze cyberbezpieczeństwa taka współzależność występuje praktycznie zawsze. Przykład, który często przywołuję, dotyczy relacji między zespołem bezpieczeństwa a infrastrukturą IT czy zespołami deweloperskimi w procesie zarządzania podatnościami.
Zazwyczaj odpowiedzialnością bezpieczeństwa jest wykrywanie podatności, ich rejestrowanie, raportowanie i przekazanie wytycznych celem ich usunięcia. Jednak to administratorzy infrastruktury czy deweloperzy są odpowiedzialni za samo usunięcie luki, nie zespół bezpieczeństwa. Tak więc już na tym etapie widać, że specjaliści od bezpieczeństwa nie będą w stanie wykonać postawionych przed nimi zadań bez zaangażowania drugiej strony. Z kolei inicjatywy IT wymagające formalnej zgody bezpieczeństwa mogą być skutecznie blokowane lub przynajmniej opóźniane, co potencjalnie wpływa na realizację celów biznesowych deweloperów.
Cele niemożliwe (lub wydające się niemożliwe) do pogodzenia
W kontekście wspomnianego przykładu warto zapytać: „Czy pogodzenie celów zespołów niezbędnych do zarządzania podatnościami to realna bariera, czy jedynie subiektywna trudność wewnątrz organizacji?”. A Ty, jakiego jesteś zdania?
Pytanie nie należy do łatwych, bo diabeł tkwi w szczegółach, które potrafią tu nieźle namieszać. Żeby konflikt o cele w ogóle zaistniał, muszą zostać spełnione dwa warunki.
Po pierwsze, cele muszą zostać nazwane i zakomunikowane. I tu zaczynają się schody. Czy deweloper wie, że Twoim celem jest „zero podatności krytycznych w raporcie miesięcznym”? A czy Ty wiesz, że jego celem jest „wdrożenie nowej funkcjonalności do najbliższego piątku, bo tak obiecał zarządowi”? Jeśli te cele nie są ze sobą zsynchronizowane na poziomie całej firmy, to mamy problem.
Po drugie, pojawia się kwestia subiektywnego przeświadczenia. Druga strona musi mieć poczucie – wręcz głębokie przekonanie – że realizacja Twojego celu automatycznie oznacza porażkę ich celu. To jest właśnie „gra o sumie zerowej”, o której wspomniałem na początku. Administrator myśli: „Jeśli teraz zacznę patchować serwery, to nie skończę migracji bazy danych i znowu dostanę po głowie od szefa”. Ten przypadek to nie jest „widzimisię” administratora czy zła wola dewelopera. Jeśli system nagród w firmie faworyzuje szybkość kosztem bezpieczeństwa, to subiektywne przeświadczenie pracownika („jeśli to naprawię, zawalę termin i stracę premię”) staje się obiektywną prawdą o jego sytuacji zawodowej. Bez synchronizacji celów strategicznych, zawsze będziemy mieli do czynienia z „zarządzaniem przez konflikt”, a nie „zarządzaniem ryzykiem”.
Poziomy konfliktów
Konflikty mogą przybierać różną formę. Na początku są często utajone – to tzw. konflikty potencjalne. Według badaczy takich jak Deutsch czy Pondy, jest to poziom struktury. To fundament, na którym coś dopiero może wyrosnąć, ale o tym, jak ta struktura potrafi namieszać, opowiem za chwilę.
Gdy konflikt postępuje, zaczynamy go dostrzegać i odczuwać na poziomie psychologicznym. Mimo to formalnie wciąż pozostaje on ukryty – nie widzimy jeszcze otwartych kłótni czy trzaskania drzwiami. Można by jednak powiedzieć, że „coś wisi w powietrzu”. Czujemy obecność tego słynnego słonia w pokoju, ale z jakiegoś powodu nie mamy motywacji ani chęci, żeby w ogóle zacząć o tym rozmawiać.
W końcu konflikt przybiera formę jawną. To już poziom zachowań – spór manifestuje się poprzez konkretne działania, odmowy czy złośliwości. I tu pojawia się kluczowe pytanie: co tak naprawdę jest jego źródłem?
Gdzie bije źródło?
Konflikt może wybuchnąć dosłownie o wszystko. Problem polega na tym, że nie zawsze dowiemy się, o co tak naprawdę chodzi i co jest tym pierwotnym zapalnikiem. Niebezpieczeństwo jest realne: nawet błaha sprawa, zbagatelizowana na początku, może stać się zarzewiem pożaru, który sparaliżuje funkcjonowanie całej organizacji.
Fascynujące jest jednak to, że gdy zaczniesz rozumieć dynamikę konfliktu i procesy, które go tworzą, znacznie łatwiej jest nim zarządzić. Zaczynasz po prostu widzieć schematy.
Pytanie brzmi: czy jest jedno źródło konfliktu? Oczywiście, że nie. Wiedza o tym, jakie inne siły oddziałują na zespoły, jest kluczowa, bo od rodzaju konfliktu zależy to, jakimi narzędziami spróbujemy go ugasić.
Różne wymiary konfliktu (Koło Moore’a)
Problem ze zjawiskiem konfliktu polega na tym, że jego źródło rzadko jest jednorodne. Trudno znaleźć sytuację, która byłaby „czystym” konfliktem tylko z jednej kategorii. Christopher Moore, autor modelu koła konfliktu, wymienia ich pięć rodzajów:
- Danych
- Wartości
- Relacji
- Interesów
- Strukturalny
Jeśli spojrzymy na zarządzanie podatnościami przez pryzmat jego Koła Konfliktu, zobaczymy, że rzadko kiedy chodzi o jedną rzecz. Spójrzmy, jak to wygląda w praktyce, trzymając się naszego przykładu z łataniem podatności w systemie.
Konflikt danych
To zazwyczaj pierwszy etap. Bezpieczeństwo przesyła raport z pięćdziesiątką „krytyków”. IT go otwiera i… zaczyna się festiwal znaków zapytania.
O co chodzi? Mamy inne informacje albo po prostu inaczej je interpretujemy.
Przykład: Ty mówisz: „To jest krytyczne, bo tak wynika z punktacji CVSS”. Administrator odpowiada: „Ale ten serwer stoi w odizolowanym segmencie sieci bez wyjścia na świat, więc dla nas to ryzyko jest bliskie zeru”. Brak wspólnego standardu oceny tego, co faktycznie jest groźne tu i teraz, sprawia, że obie strony czują, iż ta druga marnuje ich cenny czas.
Konflikt interesów
Tutaj wracamy do wspomnianej „sumy zerowej”. Chodzi o to, czego realnie potrzebujemy, by móc wieczorem spokojnie wyjść z biura z poczuciem dobrze wykonanej roboty.
O co chodzi? Moja wygrana wydaje się Twoją przegraną.
Przykład: Twoim interesem jako osoby od bezpieczeństwa jest „czysty raport” i brak luki w systemie. Interesem administratora jest „uptime” i stabilność. Jeśli załatanie podatności wymaga restartu krytycznej bazy danych w godzinach szczytu, wasze interesy stają się sprzeczne. Nie dlatego, że się nie lubicie, ale dlatego, że każde z Was chce dowieźć swoje KPI, a system nie pozwala zrobić tego jednocześnie.
Konflikt strukturalny
To ten, o którym pisałem przed chwilą – wynikający z „wadliwej konstrukcji” samej sytuacji, w której zostaliśmy postawieni.
O co chodzi? Brak zasobów, czasu lub nierealne procedury narzucone z góry.
Przykład: Firma oficjalnie wymaga łatania krytycznych podatności w 48 godzin, ale jednocześnie nie daje administratorom ani minuty nadprogramowego czasu na testy, czy ten patch nie „wyłoży” aplikacji. Struktura (nierealny wymóg czasowy) pcha ich wprost w objęcia konfliktu z Zespołem Bezpieczeństwa, które te 48 godzin musi przecież raportować i egzekwować.
Konflikt wartości
Tu wchodzimy głębiej – w to, w co wierzymy jako specjaliści i co stawiamy na ołtarzu priorytetów.
O co chodzi? Różne ideologie zawodowe i systemy przekonań.
Przykład: Dla bezpieczeństwa najwyższą wartością jest często Poufność (nic nie może wyciec, bezpieczeństwo przede wszystkim). Dla IT czy Deweloperów najwyższą wartością jest często Dostępność i Funkcjonalność (system musi działać i zarabiać, choćby „na zapałkach”). Kiedy te dwa światy się zderzają, przestajemy rozmawiać o technologii, a zaczynamy o tym, „kto ma rację co do misji firmy”.
Konflikt relacji
To jest ten moment, gdy słoń w pokoju staje się tak duży, że trudno przejść do kuchni po kawę.
O co chodzi? Stereotypy, silne emocje i historia poprzednich potyczek.
Przykład: Jeśli ostatnim razem przy zgłaszaniu podatności ktoś z Bezpieczeństwa był arogancki, a IT poczuło się pouczane jak dzieci, to przy kolejnym raporcie deweloper nawet go nie otworzy. Nie dlatego, że dane w raporcie są złe, ale dlatego, że „nie ma ochoty gadać z tymi z bezpieczeństwa”. Tu zaczyna się wspomniana wcześniej walka z ludźmi zamiast walki z problemem.
Dlaczego „rozlewanie się” konfliktu jest tak groźne?
Zauważ jedną ważną rzecz. Zazwyczaj zaczyna się od danych (raportu), ale jeśli szybko i mądrze tego nie wyjaśnimy, konflikt błyskawicznie zainfekuje relacje i wartości.
Im dalej w las, tym trudniej wrócić do merytoryki. Jeśli pozwolisz, by konflikt o jedną podatność stał się konfliktem relacji, to nawet jeśli następnym razem przyniesiesz idealnie przygotowane dane, zostaniesz odrzucony „dla zasady”. Mechanizm eskalacji sprawia, że z każdą godziną zaniedbania szanse na rozwiązanie maleją, a my – zamiast budować realne cyberbezpieczeństwo – tracimy całą energię na budowanie okopów i ostrzenie bagnetów.
Podsumowanie
To jak w takim razie wyjść z tego błędnego koła i przestać grać w grę o sumie zerowej? Skoro wiemy już, że psychologia konfliktu to nie „miękkie gadanie”, ale realna mechanika, która wpływa na szczelność naszych systemów, warto wyciągnąć z tego konkretne wnioski.
Zrozumienie dynamiki konfliktu zmienia wszystko. Kiedy następnym razem pójdziesz do działu IT z listą podatności i zobaczysz na ich twarzach niechęć, nie myśl o tym w kategoriach „złej woli”. Zadaj sobie pytanie: z którym obszarem koła Moore’a się właśnie zderzam? * Czy to konflikt danych (może inaczej rozumiemy ryzyko)? A może strukturalny (może po prostu nie mają fizycznie czasu na łatanie)? Samo nazwanie problemu pozwala zdjąć palec ze spustu i przestać walczyć z człowiekiem, a zacząć z problemem.
Zarządzanie cyberbezpieczeństwem w nowoczesnej organizacji to w dużej mierze zarządzanie relacjami. Możemy mieć najlepsze skanery i najdroższe systemy, ale jeśli nie będziemy potrafili dogadać się z ludźmi, którzy mają fizycznie budować bezpieczeństwo, zostaniemy z garścią kolorowych raportów, których nikt nie czyta.
Kluczem jest przejście z roli „kontrolera”, który tylko wytyka błędy, do roli „partnera”, który rozumie ograniczenia drugiej strony. Cyberbezpieczeństwo to gra zespołowa – i choć czasem na boisku jest kilka drużyn o różnych barwach, to ostatecznie gramy do jednej bramki. Przegrana jednego zespołu (np. wyciek danych przez niezałataną podatność) jest porażką całej organizacji.
Jeśli podobał Ci się ten wpis, zostaw komentarz, podziel się swoją opinią, udostępnij go innym. Zapraszam również do współpracy. Napisz do mnie na adres marcin.sikorski@ctrust.me.
Serdecznie pozdrawiam,
Marcin Sikorski
Bibliografia
Moore, C. W. (2012). Mediacje : praktyczne strategie rozwiązywania konfliktów (A. Cybulko & M. Zieliński, Tłum.; 2. wyd.). Wolters Kluwer Polska.