SECURITY CARGO CULT – Kosztowne, ale za to nie działa

1. Cargo cult – samoloty z drewna i słomy

Podczas II wojny światowej na wyspach Melanezji i w innych częściach Oceanii powstawały amerykańskie bazy wojskowe. Lądowały samoloty, pojawiało się zaopatrzenie, technologia, infrastruktura. Po zakończeniu działań wojennych wojsko odleciało – a wraz z nim „cargo”.

Część lokalnych społeczności próbowała odtworzyć to, co widziała. Budowano z drewna i słomy pasy startowe, wieże kontroli lotów, atrapy samolotów. Odtwarzano rytuały, sygnały, układ przestrzeni. Logika była prosta: skoro wcześniej te elementy „przyciągały” samoloty z dobrami, ich ponowne zbudowanie powinno przynieść ten sam skutek. Wydaje się naiwne, ale to schemat myślenia życzeniowego, które nie rozumie przyczyny.

Z zewnątrz wszystko wyglądało znajomo. Był pas startowy. Była wieża z drewna, drewniane anteny. Był nawet „samolot” ze słomy, ale nikt z budujących nie rozumiał do czego służyły te elementy? Brakowało tylko tego, co naprawdę miało znaczenie – systemu logistycznego, łańcucha dostaw, decyzji strategicznych, całej infrastruktury, która sprawiała, że maszyny rzeczywiście lądowały. Lokalna ludność była zdziwiona. Zrobiliśmy to samo, ale nie działa – żadne samolotu u nas nie lądują.

Richard Feynman użył później określenia „cargo cult science” wobec działań, które przypominają naukę, lecz pomijają jej istotę – metodę, weryfikację, zrozumienie mechanizmu. Pojęcie używane jest także w świecie programistów na określenie kopiowania partii kodu bez jego zrozumienia. A jak to wygląda w security?

2. Działania pozorne jako koszt – RODO, NIS-2

Każde zabezpieczenie kosztuje. Czas ludzi. Budżet. Złożoność systemu. Uwagę zarządu. Koszty operacyjne i koszty hamowania biznesu…

Rok 2018. Telefon dzwoni częściej niż zwykle.

– Dzień dobry, potrzebujemy dokumentację RODO.

Pytanie o ocenę ryzyka, przegląd procesów, szkolenia – nie budzi zainteresowania. Chodzi o dokumenty. Najlepiej komplet. Do szuflady. „Żeby było”.

Gdy próbujesz tłumaczyć, że same wzory nie zmienią sposobu przetwarzania danych, pojawia się konsternacja. Dokument przecież jest. Klauzula jest. Umowa powierzenia jest. Zgoda podpisana. Temat zamknięty.

Potem przyszła fala:

• umowy powierzenia podpisywane wszędzie, niezależnie od podstawy prawnej
• zgody tam, gdzie wystarczał inny reżim prawny
• klauzule kopiowane bez zrozumienia, z czego wynikają
• doradcy budujący autorytet na strachu przed maksymalną karą weszli z impetem

Firmy zapłaciły naprawdę duże pieniądze. Widziałem to niejednokrotnie podczas audytów i wdrożeń. W wielu przypadkach powstały rozbudowane „lotniska” z papieru. Procedury trafiły do segregatorów. Ryzyko prawne i bezpieczeństwo danych pozostało tam, gdzie było. Zawiało i przeszło – często bez zrozumienia co do czego i po co? Za zanim ustalono wykładnię i nie kończącą się bitwę o interpretację biznes musiał żyć swoim życiem i nastąpiło zniechęcenie.

Największy problem „branży” RODO (w mojej ocenie) polegał na literalnie rozumianej regulacji w oderwaniu od metodyki ochrony informacji rozwijanej latami w Europie i głównie za oceanem. Tam bezpieczeństwo informacji się urodziło i nadal wyznacza trendy, ale jakoś słabo przenosiło się na pole interpretacyjne w naszym kraju. Zamiast myślenia systemowego pojawiła się koncentracja na formularzu i semantyce. Zamiast rozliczalności systemów IT (accountability) rozliczanie podmiotu danych (np. klientów) z podpisów. Wiele kancelarii prawnych (nie wszystkie) wdrażało RODO bez rozumienia jego logiki. A technika ochrony danych była ogólna jak RODO, więc do dziś czytając wymagania umowne czy ankiety np. nie wiadomo czasem o jakie szyfrowanie w pytaniu chodzi? On rest, on transit, pliku, symetryczne, asymetryczne, funkcje hash, na poziomie dysku czy pól w bazie danych? I dlaczego hasło ma mieć 8 znaków? „Ponieważ w RODO napisane jest, że musi być szyfrowanie…” Ochrona informacji -o ironio – wydawała się być bardzo redukowana, a działania mocno fasadowe, co obnażały incydenty nad którymi pracowałem w ramach współpracy z innymi doradcami.

To jest trudne i ważne, ponieważ działania pozorne generują trzy rodzaje strat:

• koszt finansowy – budżet wydany na artefakt
• koszt operacyjny – spowolnienie procesów
• koszt strategiczny – utrata zaufania do funkcji security

Dziś wchodzi NIS2. W mediach pojawiają się pierwsze sygnały znajomej paniki. Wiele organizacji zetknęło się z bezpieczeństwem właśnie przez regulacje. W efekcie w niejednej firmie powstały rozległe lotniska z drewna i papieru.

W organizacjach, które od lat rozwijają system zarządzania bezpieczeństwem i traktują go jako element strategii, NIS2 będzie naturalnym etapem ewolucji. Wymusi porządkowanie, doprecyzowanie odpowiedzialności, czasem przyspieszenie projektów, które i tak były w roadmapie.

Tam, gdzie bezpieczeństwo funkcjonowało głównie w warstwie dokumentacyjnej, regulacja może stać się momentem konfrontacji z rzeczywistością. To nie musi być zła wiadomość. Często właśnie presja regulacyjna uruchamia realne zmiany.

3. Cel i kontekst – fundament dojrzałości security

W obiegowej opinii bezpieczeństwo sprowadza się do kontroli. Hasło ma mieć odpowiednią długość. Logowanie ma być zabezpieczone. Dane mają być zaszyfrowane. Brzmi rozsądnie.

Problem zaczyna się wtedy, gdy kontrola przestaje być odpowiedzią na konkretny scenariusz ryzyka, a staje się samodzielnym bytem.

Klasyczny przykład – hasła. W dyskusjach często pojawia się wyliczanie, ile miliardów prób na sekundę jest w stanie wykonać atakujący i jak szybko „złamie” dane hasło. Powstają tabelki, symulacje, lata odporności. Dyskusje, czy lepiej 12 znaków czy 15?

Ostatnio widziałem pełen oburzenia post, jak to dlaczego aplikacja wymaga tylko 8 znaków? – Zadałem pytanie, a po co więcej? Nie chodzi oto, że deprecjonuje większą ilość znaków, ale umiej powiedzieć dlaczego? Na tym polega różnica między profesjonalnym security a cargo cultem.

Rzadziej pojawia się pytanie:

• czy system posiada blokadę konta po kilku nieudanych próbach – ochronę przed brute force?
• czy działa rate limiting?
• czy stosowane jest MFA?
• w jakim kontekście operacyjnym funkcjonuje dane konto, jak wrażliwe są tam dane lub funkcje? itd.

W oderwaniu od architektury każda kontrola może wyglądać dramatycznie słabo albo absurdalnie silnie. W kontekście całego systemu jej rola bywa zupełnie inna. To jest różnica między analizą pojedynczej kontroli a analizą threat scenario w modelu risk management. Na pliku w laboratorium 2s – jest to możliwe. Żeby jednak wykonać 1000 prób odgadnięcia hasła na sekundę w żywym systemie, potrzebna jest moc obliczeniowa hosta i wyłączenie pozostałych zabezpieczeń.

Dojrzałość doradcza polega na czymś prostym, choć wymagającym:

zanim zaproponujesz rozwiązanie, rozumiesz cel organizacji i cel zabezpieczenia i jego kontekst.

Po tym poznaje się dojrzałe doradztwo i rozumienie secuirty.

• Co dokładnie próbujemy chronić?
• Przed jakim scenariuszem?
• Jaki jest cel zabezpieczenia?
• Jakie są wady – na co zadziała, a na co nie zadziała, a może wniesie nowe problemy dla bezpieczeństwa, których łatanie będzie kosztowne?
• Czy dana kontrola zmienia prawdopodobieństwo zdarzenia, czy wpłynie na impact?
• Jaki jest jej koszt – finansowy, operacyjny, organizacyjny – czy będzie to cost-effective?

Kontrola (zabezpieczenie) ma sens dopiero wtedy, gdy wpisuje się w model defense in depth.

Profesjonalne podejście zaczyna się tam, gdzie kończy się myślenie atomistyczne. Bezpieczeństwo nie jest zbiorem niezależnych punktów do odhaczenia, a zdecydowanie architekturą zależności – która trzeba powiedzieć uczy pokory.

Bezpiecznik zderza się z materią techniczną, psychologiczną, regulacyjną, operacyjną. Z procesami, które już istnieją. Z kulturą organizacyjną. Z presją czasu. Z budżetem. Z celami biznesu, które nie zawsze czekają, aż skończymy analizę.

Tu nie ma prostych pociągnięć. Zbyt wiele elementów wpływa na siebie nawzajem.

Skupienie wyłącznie na procedurach lub pojedynczych zabezpieczeniach bywa naturalnym etapem rozwoju. Na początku kariery widać elementy. Z czasem zaczyna być widoczny system. W przestrzeni publicznej – również na LinkedIn – łatwo zauważyć powtarzalność narracji. Te same hasła. Te same ostrzeżenia. Te same uproszczenia. Znacznie rzadziej pojawia się rozmowa o zależnościach, kompromisach i odpowiedzialności decyzyjnej.

Bezpieczeństwo w dojrzałej organizacji nie polega wyłącznie na „budowaniu zabezpieczeń” i „hamulców”. Jego rolą jest umożliwienie organizacji realizowania celów w sposób świadomy ryzyka. Czasem oznacza to wzmocnienie kontroli. Czasem zmianę procesu. Czasem rezygnację z rozwiązania, które generuje więcej kosztów niż wartości, a najczęściej do zmiany do jakości procesów i unowocześniania systemów IT. Stereotyp bywa inny? Security jako hamulec – bezpiecznik awaryjny, a nie propagator rozwoju.

W profesjonalnym bezpieczeństwie chodzi o wsparcie misji organizacji – „o pchnięcie” do rozwoju i umacnianie w jej celach. To jest o wiele trudniejsze, niż stawianie wymagań operacjom biznesowym czy IT, odhaczanie checklisty audytowej i wdrażanie zabezpieczeń/kontrolek. To wymaga wiedzy i zastanowienia: po co i dlaczego coś robię – czy rekomenduję? Co chcę osiągnąć? Jaki będzie skutek? Kto może mi pomóc w wyjść z własnego błędu poznawczego? Jak komunikować zagrożenia i motywować do zmiany? To podejście wymaga pokory – jako elementu metodycznego.

Co najważniejsze funkcje security są częścią organizacji, a więc wszystkie problemy jakie dotyczą „zwykłych” procesów dotyczą także samego secuirty. Dlatego procesy bezpieczeństwa muszą nadążać za organizacją i same w sobie wnosić jakość. Tu jest pole do optymalizacji i automatyzacji.

4. Audyt i awareness jako wdrożenie security cargo cult

Do organizacji wchodzi audyt. Po kilku dniach powstaje lista rekomendacji. Dokument wygląda profesjonalnie. Długie zestawienie punktów, często bardzo szczegółowych. Problem zaczyna się przy pytaniu: z czego one wynikają i do czego dążą?

Rekomendacje:

• nie odnoszą się jasno do konkretnej normy, wymogu
• nie prezentują scenariusza ryzyka opartego w kontekście – albo jest to kontekst innej organizacji w której audytor budował doświadczenie – tak też popełniałem takie błędy 😉
• nie pokazują, jaki problem został globalnie zdiagnozowany
• wskazują gotowe rozwiązania techniczne zamiast celu do osiągnięcia
• są w praktyce kopią praktyk z innych organizacji, ale dostają etykietę: must, pilne, high.

Zamiast diagnozy – gotowa recepta na security cargo cult

W organizacjach o bardziej złożonym ISMS i rozbudowanym środowisku technicznym takie zalecenia często okazują się niewykonalne albo nieadekwatne. Nie dlatego, że firma „nie chce”, lecz dlatego, że rozwiązanie nie uwzględnia istniejącej architektury, ról, procesów i zależności.

Dojrzałe doradztwo działa inaczej. Najpierw rozumie:

• kontekst biznesowy
• poziom dojrzałości organizacji i problemy governance
• istniejące mechanizmy kontrolne
• właścicieli ryzyka i odpowiedzialności
• zależności od dostawców i wymagań innych norm i procesów.

Dopiero potem wskazuje kierunek. Nie narzuca konkretnego narzędzia, jeżeli celem jest redukcja określonego scenariusza ryzyka. Nie projektuje środowiska za organizację, lecz pomaga jej podjąć świadomą decyzję. Nawet jeżeli rekomenduje konkretne działanie lub zabezpieczenie, robi to po to, aby wyraźniej zobrazować cel do osiągnięcia, a nie po to, by wstawić kolejną „obowiązkową” kontrolę.

Audyt bezpieczeństwa powinien wspierać cele i strategię konkretnej organizacji. Inaczej staje się niezależnym bytem – zbiorem zaleceń, które żyją własnym życiem.

Podobnie wygląda temat awareness.

W niedojrzałej organizacji to pojedyncze szkolenie. Najczęściej przy okazji onboardingu albo wejścia nowej regulacji. Wiele firm szkoleniowych przyjeżdża z gotowym programem – czasem dopracowanym, atrakcyjnym, dynamicznym – cyber-show. Problem pojawia się wtedy, gdy materiał jest oderwany od realnych zagrożeń organizacji, od już wdrożonych zabezpieczeń, od poziomu kultury bezpieczeństwa i świadomości pracowników.

Efekty bywają przewidywalne:

• zmęczenie pracowników powtarzanymi banałami
• przewrażliwienie w obszarach marginalnych
• brak refleksji tam, gdzie ryzyko jest realne
• strach przed „hakerem”, brak motywacji do zmiany procesu

Profesjonalny trener zaczyna wcześniej. Pyta o cele organizacji. O KPI dla programu awareness. O ocenę ryzyka. O kontekst zagrożeń. Dopiero na tej podstawie buduje materiał i na końcu sprawdza, czy postawione cele zostały osiągnięte.

Bez tego szkolenie staje się wydarzeniem. Z tym podejściem staje się elementem systemu bezpieczeństwa.

I właśnie w tym miejscu widać różnicę między działaniem pokazowym a świadomym zarządzaniem bezpieczeństwem.

5. Dojrzałość – po czym ją realnie poznać?

Dojrzałość bezpieczeństwa nie objawia się liczbą procedur ani ilością wdrożonych narzędzi. Widać ją w sposobie podejmowania decyzji.

Pierwsze pytanie brzmi: czy istnieje plan wykraczający poza bieżący rok.

• Czy organizacja ma kilkuletnią strategię bezpieczeństwa?
• Czy IT i security wiedzą, jakie cele biznesowe będą realizowane w horyzoncie 2–3 lat?
• Czy roadmapa technologiczna jest powiązana z analizą zagrożeń?
• Czy ocena ryzyka dla bezpieczeństwa uwzględnia koszty i straty po stronie biznesu?
• Czy każdy na poziomie managementu potrafi jasno odpowiedzieć, dokąd zmierza obszar bezpieczeństwa?

Drugie pytanie dotyczy kosztów. Każda kontrola generuje koszt:

• wdrożenia
• utrzymania
• złożoności operacyjnej
• wpływu na doświadczenie użytkownika
• wpływu na tempo biznesu

W dojrzałej organizacji koszt rozumiany jako -koszt czas pracy, zasobów, obciążenia operacyjnego i finansowego jest elementem decyzji. Zabezpieczenia konkurują o zasoby z innymi inicjatywami. Jeżeli nie potrafią obronić się redukcją ryzyka, przegrywają. Nie są wdrażane, tylko dlatego, że tak doradził doradca, lub inni też takie mają.

Dojrzałość widać również w tym, że security potrafi powiedzieć „nie teraz” albo „nie w tej formie”. Nie każda kontrola musi być wdrożona natychmiast. Nie każde ryzyko wymaga maksymalnej reakcji. W niedojrzałym modelu aktywność bywa mylona z efektywnością. Powstają kolejne procedury, kolejne projekty, kolejne inicjatywy. Trudniej odpowiedzieć na pytanie, co realnie zmieniło się w poziomie ekspozycji organizacji.

Można działać intensywnie i kosztownie i czasem trudny do zrozumienia z poziomu „laika” osoby, która w tym nie siedzi, trzeba jednak wiedzieć po co? Inaczej może się okazać, że

może nie jest zbyt efektywnie, za to kosztownie.

6. Profesjonalizm zaczyna się od zrozumienia systemu

Profesjonalista nie analizuje kontroli. Profesjonalista analizuje scenariusz zagrożenia w architekturze systemowej.

Pojedyncza kontrola w oderwaniu od kontekstu prowadzi do zjawisk, które widać coraz częściej:

• single-control fixation
• decontextualized risk amplification
• security theater – budowanie wrażenia bezpieczeństwa i powtarzanie skomplikowanych praktyk zamiast redukcji ryzyka

Do bezpieczeństwa wchodzi dziś wiele osób z różnych obszarów. To naturalne. Regulacje, RODO, NIS2, compliance – dla wielu organizacji były pierwszym punktem styku z security. Sam również zaczynałem w innej roli.

Różnica nie polega na tym, skąd ktoś przyszedł. Różnica polega na tym, czy zatrzymał się na poziomie procedury i patrzy atomistycznie, czy zaczął zadawać pytanie o cel i rozumie organizację a także koncepcje bezpieczeństwa holistycznie.

W praktyce często widać podejście „betonowe” – koncentrację na zapisach, wzorach, wymaganiach. Widać też dyskusje oderwane od kontekstu organizacyjnego. Rozwiązania przenoszone między firmami jak koło z jednego pojazdu do drugiego, z przekonaniem, że skoro koło zębate jest podobne, to będzie pasować.

Doświadczenie uczy czegoś innego. Im dłużej pracujesz w bezpieczeństwie, tym mniej absolutnych sądów wydajesz. Organizacje są złożone. Zależności są wielowarstwowe. Decyzje mają konsekwencje kosztowe, operacyjne i strategiczne.

Z czasem pojawia się pokora.

Pojawia się świadomość własnych kalek poznawczych. Skłonności do przeszacowywania ryzyk, które akurat są medialne. Nadawania nadmiernej wagi temu, co jest blisko naszego doświadczenia. Profesjonalizm wymaga ciągłego korygowania tej perspektywy.

Security cargo cult nie dotyczy wyłącznie „innych”. Każdy z nas przechodzi etap fascynacji bezpieczeństwem czy zagrożeniami. Każdy z nas kiedyś widział problem tylko w jednym parametrze, a nie w systemie.

Dojrzałość zaczyna się wtedy, gdy przestajemy budować lotnisko z drewna i pytamy, czy istnieje infrastruktura, która sprawi, że samoloty rzeczywiście wylądują.

Bezpieczeństwo nie jest sztuką mnożenia zabezpieczeń. Jest umiejętnością wzmacniania organizacji w realizacji jej celów – przy świadomym zarządzaniu ryzykiem i kosztami.

I to właśnie odróżnia losową aktywność od profesjonalizmu.