Firma może posiadać nowoczesne narzędzia bezpieczeństwa, doświadczonych specjalistów i szczegółowe procedury, a mimo to mieć trudności z podejmowaniem właściwych decyzji dotyczących cyberbezpieczeństwa.
Często dzieje się tak dlatego, że poszczególne elementy środowiska bezpieczeństwa działają niezależnie od siebie. Skaner podatności wykrywa słabości. System obsługi zgłoszeń zarządza zadaniami. Rejestr zasobów zawiera informacje o urządzeniach. Rejestr ryzyka jest prowadzony w arkuszu kalkulacyjnym. Dział zakupów przechowuje informacje o dostawcach w innym systemie. Ustalenia audytowe są dokumentowane oddzielnie, a plany ciągłości działania znajdują się w jeszcze innym miejscu.
Każdy zespół posiada informacje, ale nikt nie ma pełnego obrazu sytuacji.
Problemem niekoniecznie jest brak technologii lub danych. Problem polega na tym, że systemy, zespoły i procesy decyzyjne nie są ze sobą połączone. W takiej sytuacji nawet zaawansowane technicznie środowisko bezpieczeństwa może prowadzić do opóźnionych reakcji, niejasnych zakresów odpowiedzialności i decyzji podejmowanych na podstawie niepełnych informacji.
Więcej narzędzi nie zawsze oznacza lepsze bezpieczeństwo
Organizacje często reagują na nowe wymagania bezpieczeństwa, kupując kolejne narzędzie. Jedna platforma zostaje wdrożona do skanowania podatności, inna do monitorowania urządzeń końcowych, kolejna do zarządzania tożsamością, a jeszcze inna do zarządzania ryzykiem stron trzecich.
Każda z tych inwestycji może rozwiązywać konkretny problem. Z czasem organizacja może jednak dysponować wieloma narzędziami, które nie wymieniają informacji w użyteczny sposób.
Jeden system wie, że serwer zawiera krytyczną podatność. Inny system wie, że serwer obsługuje aplikację produkcyjną. Trzeci system zawiera nazwisko właściciela aplikacji. Plan ciągłości działania wskazuje, że aplikacja jest niezbędna dla funkcjonowania firmy, ale informacja ta znajduje się w oddzielnym dokumencie.
W raporcie technicznym podatność może być oznaczona jako krytyczna. Osoby analizujące problem nie mogą jednak łatwo ustalić:
- który proces biznesowy zależy od systemu,
- jakie informacje są przetwarzane przez aplikację,
- czy serwer jest dostępny z Internetu,
- jakie środki bezpieczeństwa zostały już wdrożone,
- czy zewnętrzny dostawca wspiera system,
- kto odpowiada za akceptację lub ograniczenie ryzyka,
- jakie konsekwencje miałaby przerwa spowodowana usuwaniem podatności.
Bez takiego kontekstu organizacja może podjąć niewłaściwą decyzję. Może poświęcić kilka dni na usunięcie podatności w mało istotnym systemie testowym, podczas gdy podatność o niższym poziomie technicznej krytyczności pozostanie nierozwiązana w systemie wspierającym ważny proces produkcyjny.
Rozłączone dane prowadzą do rozłączonych decyzji
Decyzje dotyczące cyberbezpieczeństwa wymagają kontekstu.
Ocena techniczna może wskazać, jak poważna jest podatność, ale sama nie przedstawia pełnego ryzyka biznesowego. Lista incydentów bezpieczeństwa może pokazać liczbę zdarzeń, ale nie musi wyjaśniać, które usługi biznesowe zostały dotknięte. Ocena dostawcy może wskazać słabości umowne, ale nie musi pokazywać, czy dostawca ma dostęp do danych wrażliwych albo czy wspiera proces o krytycznym znaczeniu.
Jeżeli informacje znajdują się w oddzielnych systemach, każda decyzja jest podejmowana na podstawie tylko części dostępnych danych.
Prowadzi to do kilku typowych problemów.
Priorytety opierają się wyłącznie na technicznym poziomie krytyczności
Zespoły bezpieczeństwa często mają więcej ustaleń, niż są w stanie natychmiast obsłużyć. Muszą więc zdecydować, które problemy należy rozwiązać w pierwszej kolejności.
Jeżeli dostępne informacje ograniczają się do technicznego poziomu krytyczności, zespół w naturalny sposób koncentruje się na najwyższych ocenach. Takie podejście może wydawać się obiektywne, ale może pomijać krytyczność zasobu, poziom ekspozycji, dostępne zabezpieczenia kompensacyjne oraz możliwe skutki przerwy w działaniu systemu.
Lepsza decyzja wymaga zarówno informacji technicznych, jak i biznesowych.
Zakresy odpowiedzialności pozostają niejasne
Podatność może zostać przypisana administratorowi IT. Administrator może jednak nie posiadać uprawnień do zatwierdzenia przerwy w działaniu systemu ani zaakceptowania pozostałego ryzyka.
Problem dotyczący dostawcy może zostać skierowany do działu zakupów, chociaż usługa, której dotyczy, należy do innego działu. Ustalenie audytowe może pozostawać otwarte, ponieważ uczestniczy w nim kilka zespołów i żadna osoba nie została wyznaczona jako odpowiedzialny właściciel.
Gdy systemy są rozłączone, odpowiedzialność jest często przenoszona pomiędzy zespołami. Zgłoszenie zmienia właściciela, ale ryzyko pozostaje.
Eskalacja następuje zbyt późno
Wiele organizacji posiada procedury eskalacji, ale są one uzależnione od kompletnych i aktualnych informacji.
Działanie krytyczne może stać się zaległe bez wiedzy kierownictwa. Podatność może przekroczyć termin usunięcia bez uruchomienia skutecznego procesu obsługi wyjątku. Środek bezpieczeństwa może przestać działać prawidłowo, a jego status nadal będzie raportowany jako wdrożony, ponieważ nie powiązano z nim aktualnych dowodów.
Zanim problem dotrze do kierownictwa, pierwotny termin może już dawno minąć.
Ukryty wpływ na poziom realizacji SLA
Rozłączone systemy mają bezpośredni wpływ na realizację umów o gwarantowanym poziomie świadczenia usług, czyli SLA, w obszarze cyberbezpieczeństwa.
Po zidentyfikowaniu problemu bezpieczeństwa często trzeba wykonać kilka czynności, zanim rozpocznie się jego usuwanie:
- Ustalenie musi zostać zweryfikowane.
- Należy zidentyfikować zasób, którego dotyczy problem.
- Trzeba odnaleźć właściciela technicznego.
- Należy skonsultować się z właścicielem biznesowym.
- Trzeba ocenić wpływ operacyjny.
- Plan działań naprawczych musi zostać zatwierdzony.
- Konieczne może być zaplanowanie okna serwisowego.
- Zmiana musi zostać wdrożona i przetestowana.
- Ustalenie musi zostać zamknięte wraz z odpowiednimi dowodami.
Jeżeli informacje o zasobie, właścicielu, procesie biznesowym i istniejących zabezpieczeniach są przechowywane w różnych miejscach, znaczna część dostępnego czasu reakcji jest przeznaczana na szukanie danych i kontaktowanie się z właściwymi osobami.
Prace techniczne mogą zająć tylko kilka godzin. Cały proces może jednak trwać kilka tygodni.
Jest to jeden z powodów, dla których zespoły bezpieczeństwa nie dotrzymują terminów, mimo że pracują bez przerwy. Opóźnienie nie zawsze powstaje na etapie technicznego usuwania problemu. Często pojawia się wcześniej, zanim ktokolwiek będzie w stanie podjąć jednoznaczną decyzję.
Ręczne raportowanie ukrywa rzeczywisty problem
Rozłączone środowiska są zwykle silnie uzależnione od arkuszy kalkulacyjnych i ręcznie przygotowywanych raportów.
Arkusze kalkulacyjne są przydatne i elastyczne, ale ich utrzymywanie staje się trudne, gdy różne zespoły używają innych nazw, kategorii i dat raportowania. Ta sama aplikacja może występować pod kilkoma nazwami. Usunięta podatność może być nadal prezentowana jako otwarta w raporcie dla kierownictwa. Ocena ryzyka może zostać zaktualizowana bez odpowiedniej zmiany planu postępowania z ryzykiem.
Przygotowanie raportu staje się wówczas procesem gromadzenia, porównywania i poprawiania informacji.
Powoduje to dwa główne zagrożenia.
Po pierwsze, specjaliści ds. bezpieczeństwa poświęcają czas na przygotowywanie raportów zamiast na ograniczanie ryzyka. Po drugie, kierownictwo otrzymuje dokument przedstawiający sytuację w konkretnym dniu raportowym, a nie aktualny obraz poziomu bezpieczeństwa.
Nawet starannie przygotowany raport może wprowadzać w błąd, jeżeli dane, na których się opiera, są niepełne lub nieaktualne.
Pulpity zarządcze nie tworzą automatycznie integracji
Organizacje czasami próbują rozwiązać problem przez wdrożenie nowego pulpitu zarządczego.
Pulpit może ułatwić odczytywanie informacji, ale nie poprawi słabych relacji pomiędzy danymi źródłowymi. Jeżeli brakuje właściciela zasobu, pulpit nie może wiarygodnie wskazać osoby odpowiedzialnej. Jeżeli systemy stosują różne nazwy dla tego samego zasobu, pulpit może policzyć jeden system kilka razy. Jeżeli nie została określona krytyczność biznesowa, pulpit nie utworzy tego kontekstu samodzielnie.
Celem nie powinno być umieszczanie większej liczby wykresów na jednym ekranie. Należy zapewnić wiarygodne powiązania pomiędzy:
- procesami biznesowymi,
- informacjami,
- aplikacjami,
- infrastrukturą,
- tożsamościami,
- dostawcami,
- podatnościami,
- zagrożeniami,
- środkami bezpieczeństwa,
- ryzykami,
- incydentami,
- ustaleniami audytowymi,
- działaniami,
- właścicielami,
- dowodami.
Jakość decyzji zależy od jakości tych powiązań.
Jak wygląda połączony model cyberbezpieczeństwa
Połączony model cyberbezpieczeństwa nie wymaga zastąpienia wszystkich używanych narzędzi.
Specjalistyczne rozwiązania mogą nadal wykonywać zadania, do których zostały przeznaczone. Skanery podatności mogą identyfikować techniczne słabości. Systemy ochrony urządzeń końcowych mogą wykrywać podejrzaną aktywność. Platformy tożsamości mogą zarządzać dostępem. Narzędzia do zarządzania usługami mogą koordynować prace operacyjne.
Najważniejszą zmianą jest stworzenie wspólnej struktury, która połączy informacje wytwarzane przez te narzędzia.
Rozważmy podatność dotyczącą aplikacji dostępnej z zewnątrz. W połączonym modelu zespół bezpieczeństwa powinien mieć dostęp do następujących informacji:
- zasobu technicznego, którego dotyczy problem,
- aplikacji działającej na tym zasobie,
- usługi biznesowej wspieranej przez aplikację,
- klasyfikacji przetwarzanych informacji,
- właścicieli technicznych i biznesowych,
- powiązanych dostawców,
- istniejących środków bezpieczeństwa,
- znanych incydentów lub wcześniejszych ustaleń,
- obowiązującego terminu usunięcia problemu,
- aktualnego działania naprawczego i jego terminu.
Pozwala to organizacji ocenić problem zgodnie z jego rzeczywistym kontekstem, zamiast opierać decyzję na pojedynczym wyniku.
Odpowiedzialność musi podążać za decyzją
Samo połączenie systemów nie jest wystarczające. Jasno określony musi być również proces decyzyjny.
Za różne elementy tego samego problemu mogą odpowiadać różne osoby:
- Analityk bezpieczeństwa weryfikuje ustalenie.
- Administrator systemu definiuje rozwiązanie techniczne.
- Właściciel aplikacji ocenia wpływ na dostępność usługi.
- Właściciel procesu biznesowego ocenia konsekwencje operacyjne.
- Właściciel ryzyka akceptuje lub odrzuca pozostały poziom narażenia.
- Kierownictwo zatwierdza wyjątki przekraczające zaakceptowany poziom ryzyka.
Ról tych nie należy ze sobą mylić.
Osoba, której przypisano zgłoszenie techniczne, nie staje się automatycznie osobą upoważnioną do zaakceptowania ryzyka biznesowego. Zespół bezpieczeństwa może zalecić określone działanie, ale nie powinien akceptować ryzyka operacyjnego w imieniu innego działu.
Połączony proces powinien wskazywać zarówno osobę odpowiedzialną za wdrożenie działania, jak i właściciela odpowiedzialnego za podjęcie decyzji.
Jak rozpocząć łączenie środowiska
Pierwszym krokiem nie powinien być zakup kolejnej platformy. Należy rozpocząć od sprawdzenia, w jaki sposób obecnie podejmowane są decyzje.
Praktyczny przegląd może opierać się na następujących pytaniach:
- Jakie informacje są potrzebne do podjęcia decyzji dotyczącej cyberbezpieczeństwa?
- Gdzie przechowywane są te informacje?
- Kto je utrzymuje?
- W jaki sposób zasób jest powiązany z procesem biznesowym?
- Jak ustalenia techniczne są łączone z ryzykami?
- Kto decyduje, czy działanie naprawcze może zostać odroczone?
- W jaki sposób eskalowane są zaległe działania?
- Jakie dowody są wymagane przed zamknięciem problemu?
- Które raporty są przygotowywane ręcznie?
- Które dane są wielokrotnie kopiowane między systemami?
Odpowiedzi pokażą, gdzie proces decyzyjny ulega przerwaniu.
Organizacja może następnie zdefiniować wspólny sposób opisywania zasobów, ryzyk, zabezpieczeń, działań i odpowiedzialności. Może wskazać minimalny zakres informacji wymaganych do podejmowania istotnych decyzji i ustalić reguły ich aktualizacji.
Integracja powinna wynikać z potrzeb decyzyjnych, a nie odwrotnie.
Lepsze powiązania prowadzą do lepszych decyzji inwestycyjnych
Rozłączone systemy utrudniają również określenie, gdzie inwestycje w bezpieczeństwo przyniosą największą wartość.
Jeden dział może wnioskować o kolejne narzędzie bezpieczeństwa, ponieważ obserwuje dużą liczbę alertów. Inny może domagać się dodatkowego personelu, ponieważ usuwanie problemów trwa zbyt długo. Kierownictwo może zaakceptować oba wnioski, nie wiedząc, że podstawowym problemem są niepełne informacje o zasobach, niejasna odpowiedzialność lub powielone procesy.
Połączony widok może pokazać, czy organizacji rzeczywiście brakuje konkretnej zdolności bezpieczeństwa, czy też istniejąca zdolność jest wykorzystywana nieefektywnie.
Może również ujawnić sytuacje, w których kilka środków bezpieczeństwa ogranicza to samo ryzyko, podczas gdy inne ważne ryzyko pozostaje niewystarczająco zabezpieczone.
Nie oznacza to, że każda decyzja stanie się prosta. Oznacza to, że decyzje będą opierały się na widocznych powiązaniach i aktualnych dowodach, a nie na założeniach.
Celem nie są idealne dane
Organizacje czasami opóźniają integrację, ponieważ ich dane są niekompletne.
Idealne dane nie są jednak realistycznym punktem wyjścia. Rejestry zasobów zmieniają się. Pracownicy obejmują nowe role. Dostawcy wprowadzają nowe usługi. Aplikacje są zastępowane. Ryzyka ewoluują.
Praktycznym celem jest określenie, które informacje są konieczne do podejmowania ważnych decyzji, a następnie stopniowe podnoszenie ich jakości.
Połączony model może również ujawniać braki danych. Jeżeli krytyczna aplikacja nie ma właściciela biznesowego, brakujące powiązanie staje się widoczne. Jeżeli środek bezpieczeństwa nie posiada aktualnych dowodów, można zakwestionować jego status. Jeżeli dostawca wspiera krytyczną usługę, ale nie został oceniony, taką lukę można przypisać do właściciela i monitorować jej zamknięcie.
Niekompletne informacje stają się możliwe do zarządzania, gdy organizacja widzi, gdzie dokładnie występują braki.
Od rozłączonych narzędzi do połączonej odpowiedzialności
Największa korzyść wynikająca z połączenia informacji dotyczących cyberbezpieczeństwa nie ma charakteru technologicznego. Jest nią poprawa sposobu funkcjonowania organizacji.
Zespoły rozumieją, dlaczego dany problem jest istotny. Właściciele wiedzą, jakich decyzji się od nich oczekuje. Kierownictwo widzi, które ryzyka wymagają uwagi. Specjaliści techniczni otrzymują priorytety uwzględniające znaczenie biznesowe. Audytorzy mogą prześledzić powiązanie między wymaganiem, środkiem bezpieczeństwa, jego właścicielem i dowodami potwierdzającymi działanie.
Pomaga to odejść od oddzielnych raportów i okresowych działań związanych jedynie ze zgodnością. Cyberbezpieczeństwo staje się częścią codziennego zarządzania operacyjnego i biznesowego.
Ukryte ryzyko cyberbezpieczeństwa nie polega wyłącznie na tym, że systemy nie wymieniają danych. Polega ono na tym, że rozproszone informacje prowadzą do rozproszonej odpowiedzialności, powolnych decyzji i nieskutecznych działań.
Połączenie systemów jest zatem tylko początkiem. Rzeczywistym celem jest połączenie informacji z kontekstem, kontekstu z odpowiedzialnością, a odpowiedzialności z konkretnym działaniem.
