Cyberbezpieczeństwo przez lata było traktowane głównie jako domena działów IT. W praktyce oznaczało to koncentrację na zabezpieczeniach technicznych: firewallach, antywirusach, aktualizacjach, systemach monitorowania, skanach podatności, kopiach zapasowych i procedurach dostępowych. Ten fundament nadal jest potrzebny. Bez niego trudno mówić o odpowiedzialnym zarządzaniu bezpieczeństwem. Problem zaczyna się wtedy, gdy organizacja uznaje, że sama lista zabezpieczeń albo raport ze skanera podatności wystarcza do oceny rzeczywistego poziomu ryzyka.
Coraz więcej organizacji zadaje dziś inne pytanie: nie tylko „czy mamy zabezpieczenia?”, lecz „czy wiemy, które cyberzagrożenia mogą zatrzymać nasz biznes?”. To zasadnicza różnica. Pierwsze pytanie dotyczy głównie technologii. Drugie dotyczy zarządzania ryzykiem, odpowiedzialności kierownictwa i odporności organizacji.
Cyberryzyko powinno być więc mierzone nie wyłącznie liczbą podatności, alertów czy incydentów, lecz wpływem na procesy biznesowe, ekspozycją finansową, zdolnością do odtworzenia działania oraz poziomem odporności całej organizacji.
Liczba podatności nie jest miarą ryzyka
Jednym z częstych błędów jest utożsamianie liczby podatności z poziomem ryzyka. Organizacja może posiadać wiele podatności w środowiskach testowych, które przy właściwej separacji, braku danych produkcyjnych i ograniczonej dostępności zewnętrznej nie muszą generować najwyższego ryzyka biznesowego. Może jednak mieć jedną pozornie „średnią” podatność w systemie ERP, Active Directory, usłudze zdalnego dostępu albo komponencie wspierającym produkcję, która w praktyce otwiera drogę do zatrzymania działalności, utraty danych lub istotnych strat finansowych.
Dlatego sam bazowy wynik CVSS nie wystarcza. Może wskazać techniczną ciężkość podatności, ale bez kontekstu biznesowego nie odpowiada na pytanie, czy dana podatność może zatrzymać proces krytyczny, naruszyć dane kluczowe, doprowadzić do niedostępności usługi albo spowodować istotną stratę finansową.
Ocena techniczna podatności mówi, jak poważna jest słabość z perspektywy systemu. Nie mówi jednak, czy dotyczy procesu generującego przychody, środowiska dostępnego z Internetu, danych objętych szczególnymi wymaganiami, usługi utrzymywanej przez dostawcę albo infrastruktury, od której zależy ciągłość operacyjna organizacji.
Ryzyko powstaje dopiero w kontekście. Ten kontekst tworzą procesy biznesowe, dane, systemy, zależności technologiczne, dostawcy, użytkownicy uprzywilejowani oraz możliwe skutki incydentu.
W praktyce często spotykamy sytuację, w której raport techniczny wskazuje kilkaset podatności, ale po powiązaniu ich z procesami biznesowymi okazuje się, że decyzji zarządczej wymagają trzy obszary: dostęp zdalny dostawcy, brak segmentacji systemu wspierającego produkcję oraz kopie zapasowe, których nikt realnie nie odtwarzał dla procesu krytycznego. Dopiero taki obraz pozwala rozmawiać o ryzyku, a nie tylko o liście zadań dla administratora.
Ryzyko trzeba zaczynać od procesu, nie od serwera
Dojrzała analiza cyberryzyka nie zaczyna się od listy serwerów. Zaczyna się od pytania: które procesy tworzą wartość dla organizacji i których przerwanie miałoby rzeczywisty wpływ na jej działalność?
Dla firmy produkcyjnej będą to na przykład realizacja zamówień, planowanie produkcji, obsługa klientów OEM, logistyka, utrzymanie ruchu, kontrola jakości i fakturowanie. Dopiero później należy wskazać, jakie systemy, dane, infrastruktura, osoby i dostawcy wspierają te procesy. Może się wtedy okazać, że kluczowe znaczenie mają system ERP, MES, Active Directory, środowisko chmurowe, operator telekomunikacyjny, integrator utrzymujący aplikację albo dostawca usług backupu.
Takie podejście zmienia priorytety. Nie chronimy systemu ERP wyłącznie dlatego, że jest ważną aplikacją. Chronimy zdolność organizacji do przyjmowania zamówień, planowania produkcji, realizacji dostaw i rozliczania sprzedaży. System ERP jest ważny, ponieważ wspiera te procesy. To subtelna, ale bardzo istotna różnica.
Właśnie dlatego cyberryzyko powinno być integrowane z zarządzaniem procesami, ciągłością działania, zarządzaniem dostawcami, bezpieczeństwem informacji oraz systemem zarządzania ryzykiem przedsiębiorstwa. W przeciwnym razie cyberbezpieczeństwo pozostaje technicznym dodatkiem, a nie elementem podejmowania decyzji zarządczych.
Ryzyko musi mieć właściciela, nie tylko administratora
Dojrzałe zarządzanie cyberryzykiem wymaga jasnego przypisania właścicieli ryzyka. Ryzyko związane z systemem ERP nie jest wyłącznie ryzykiem działu IT, jeżeli jego materializacja zatrzymuje sprzedaż, produkcję lub obsługę klienta. Ryzyko dotyczące systemu kadrowego nie jest wyłącznie problemem administratora, jeżeli skutkiem może być naruszenie danych pracowników, sankcje regulacyjne albo utrata zaufania.
IT może identyfikować podatności. Zespół bezpieczeństwa może analizować scenariusze ataku. Audytor może ocenić zgodność i skuteczność zabezpieczeń. Jednak decyzja o akceptacji, redukcji, przeniesieniu albo unikaniu ryzyka powinna należeć do właściciela procesu biznesowego i kierownictwa, przy wsparciu ekspertów bezpieczeństwa.
To ważne, ponieważ bez właściciela ryzyko staje się anonimowe. A anonimowe ryzyko ma jedną niebezpieczną cechę: zwykle wraca w najgorszym możliwym momencie, najczęściej w postaci incydentu, którego „nikt się nie spodziewał”, choć ślady ostrzegawcze były widoczne od dawna.
KPI i KRI – dwa różne języki pomiaru
Wiele organizacji monitoruje skuteczność cyberbezpieczeństwa przez wskaźniki operacyjne. To potrzebne, ale niepełne. W praktyce warto rozróżnić dwa typy wskaźników: KPI i KRI.
KPI, czyli Key Performance Indicators, pokazują sprawność działania procesów bezpieczeństwa. Mogą obejmować średni czas usuwania podatności, procent kont objętych MFA, pokrycie stacji roboczych ochroną EDR, skuteczność testów odtworzeniowych kopii zapasowych, terminowość przeglądów uprawnień albo czas reakcji na alerty bezpieczeństwa.
KRI, czyli Key Risk Indicators, pokazują natomiast, czy poziom ryzyka rośnie, czy maleje. Przykładami mogą być liczba aktywnych podatności o których wiemy, że są wykorzystywane przez atakujących, liczba ścieżek ataku prowadzących do systemów krytycznych, liczba dostawców wysokiego ryzyka, poziom ekspozycji usług dostępnych z Internetu, liczba systemów krytycznych bez pełnego pokrycia monitoringiem albo liczba procesów krytycznych bez potwierdzonych testów odtworzeniowych.
Organizacja może mieć dobre KPI i jednocześnie rosnące KRI. Może sprawnie usuwać podatności, ale równolegle zwiększać powierzchnię ataku w chmurze. Może prowadzić szkolenia, ale nadal posiadać słabo kontrolowane dostępy dostawców. Może mieć EDR na stacjach roboczych, ale nie mieć pełnej kontroli nad ścieżkami ataku do Active Directory. Może też wykonywać kopie zapasowe, ale nie mieć pewności, czy da się z nich odtworzyć proces krytyczny w wymaganym czasie.
Dlatego zarząd nie powinien otrzymywać wyłącznie raportu operacyjnego. Powinien otrzymywać informację o trendzie ryzyka, ekspozycji finansowej, przekroczeniach apetytu na ryzyko oraz decyzjach wymagających reakcji kierownictwa.
Apetyt na ryzyko musi być praktyczny
Apetyt na ryzyko nie powinien być wyłącznie deklaracją w polityce. Jeżeli pozostaje hasłem w dokumencie, nie pomaga w podejmowaniu decyzji. Powinien być przełożony na praktyczne progi decyzyjne.
W cyberbezpieczeństwie mogą to być na przykład: maksymalny akceptowalny czas niedostępności procesu, dopuszczalny poziom ekspozycji systemów krytycznych, maksymalny czas usunięcia aktywnie wykorzystywanej podatności, minimalny poziom zabezpieczeń dla dostawców wysokiego ryzyka, wymagany poziom testów kopii zapasowych albo próg ryzyka wymagający decyzji zarządu.
Dopiero wtedy można sensownie odpowiedzieć na pytanie, czy dana sytuacja mieści się w akceptowanym poziomie ryzyka, czy wymaga działania. Bez takich progów organizacja często działa reaktywnie: podejmuje decyzje dopiero wtedy, gdy presja incydentu, klienta, regulatora albo audytu staje się zbyt duża, żeby ją dalej ignorować.
Od statycznej analizy do żywego modelu ryzyka
Klasyczna analiza ryzyka wykonywana raz w roku coraz częściej przypomina zdjęcie rzeczywistości, która zdążyła się już zmienić. Środowisko zagrożeń zmienia się szybciej niż cykl audytowy. Nowe podatności, exploity, kampanie ransomware, incydenty u dostawców, zmiany w infrastrukturze i nowe usługi chmurowe mogą w ciągu kilku dni istotnie zmienić poziom ryzyka.
Dlatego nowoczesne podejście wymaga zasilania modelu ryzyka danymi Threat Intelligence. Nie chodzi jednak o reagowanie na każdą informację w trybie alarmowym. Liczy się zasadność: czy dana technologia jest używana przez organizację, czy podatność dotyczy aktywa krytycznego, czy system jest dostępny z Internetu, czy istnieje działający exploit, czy zagrożenie jest aktywnie wykorzystywane oraz czy działają zabezpieczenia kompensujące.
Jeżeli informacja Threat Intelligence dotyczy technologii używanej przez organizację, aktywa krytycznego lub podatności aktywnie wykorzystywanej, ocena ryzyka powinna zostać zaktualizowana poza standardowym cyklem przeglądu. Czekanie do kolejnej rocznej analizy ryzyka w takim przypadku jest wygodne dokumentacyjnie, ale słabe zarządczo.
Podobnie działa podejście CTEM, czyli Continuous Threat Exposure Management. Jego sens polega na tym, aby nie próbować usuwać wszystkiego naraz, lecz koncentrować się na ekspozycjach, które realnie prowadzą do aktywów i procesów krytycznych. Jeżeli skaner wykrywa 250 podatności, ale tylko 12 z nich znajduje się na ścieżce ataku do systemu ERP, a 3 są aktywnie wykorzystywane przez przestępców, to właśnie te 3 powinny otrzymać najwyższy priorytet.
To jest praktyczne zarządzanie ryzykiem. Nie chodzi o doskonałość tabeli. Chodzi o właściwe decyzje.
Kwantyfikacja finansowa bez fałszywej precyzji
Coraz częściej od cyberbezpieczeństwa oczekuje się języka finansowego. To dobry kierunek, ponieważ zarząd nie podejmuje decyzji wyłącznie na podstawie skali „niski, średni, wysoki”. Potrzebuje wiedzieć, jakie mogą być konsekwencje biznesowe: przestój, utrata przychodów, koszt odtworzenia, kary umowne, sankcje regulacyjne, koszty obsługi incydentu, utrata klientów albo wpływ na reputację.
Trzeba jednak uważać na fałszywą precyzję. Kwantyfikacja finansowa cyberryzyka nie musi oznaczać wyliczenia straty co do złotówki. W praktyce często wystarczy przedziałowa ocena scenariuszy strat, która pozwala porównać ryzyka i podjąć decyzję inwestycyjną.
Przykładowo: inaczej wygląda rozmowa o „wysokim ryzyku ransomware”, a inaczej o scenariuszu, w którym zatrzymanie systemu planowania produkcji na trzy dni oznacza opóźnienia dostaw, kary kontraktowe, koszt pracy awaryjnej, utratę marży oraz konieczność ręcznego odtwarzania danych. Pierwsza wersja brzmi jak ostrzeżenie techniczne. Druga pozwala rozmawiać o pieniądzach, priorytetach i odpowiedzialności.
Jak wdrażać dojrzałe zarządzanie cyberryzykiem?
Dojrzały model zarządzania cyberryzykiem można wdrażać etapami. Nie trzeba od razu budować rozbudowanego centrum operacyjnego ani kupować kilku platform klasy enterprise. Technologia może pomóc, ale nie zastąpi uporządkowanego sposobu myślenia.
- Pierwszym krokiem powinno być mapowanie procesów biznesowych i ich zależności od systemów IT, OT, danych, infrastruktury, osób oraz dostawców.
- Drugim etapem jest identyfikacja aktywów krytycznych – nie według wartości technicznej, lecz według wpływu na działalność organizacji.
- Trzeci krok to przypisanie właścicieli ryzyka oraz określenie zasad podejmowania decyzji: kto akceptuje ryzyko, kto finansuje jego redukcję, kto monitoruje poziom ekspozycji i kiedy sprawa trafia na poziom kierownictwa.
- Czwarty krok to wdrożenie spójnej metodyki oceny ryzyka, która obejmuje prawdopodobieństwo, wpływ, scenariusze ryzyka, zabezpieczenia istniejące, ryzyko rezydualne oraz – dla najważniejszych przypadków – kwantyfikację finansową.
- Piąty etap to integracja Threat Intelligence, czyli bieżące aktualizowanie oceny ryzyka na podstawie realnych danych o zagrożeniach, podatnościach, kampaniach ataków i incydentach u dostawców.
- Szósty krok to dashboard zarządczy, który pokazuje nie samą liczbę podatności, lecz trend ryzyka, ekspozycję finansową, przekroczenia apetytu na ryzyko i decyzje wymagające uwagi kierownictwa.
- Siódmy etap to ciągłe doskonalenie, w tym CTEM, testy odporności, ćwiczenia scenariuszowe, testy odtworzeniowe, przeglądy dostawców i regularna weryfikacja skuteczności zabezpieczeń.
Tak rozumiane zarządzanie cyberryzykiem nie jest projektem dokumentacyjnym. Jest mechanizmem zarządczym.
Pięć zasad, które warto zapamiętać
Po pierwsze, cyberbezpieczeństwo jest częścią zarządzania ryzykiem przedsiębiorstwa. Nie powinno funkcjonować jako osobny silos IT.
Po drugie, liczba podatności nie jest miarą ryzyka. Miarą ryzyka jest wpływ na procesy, ekspozycja finansowa, poziom ryzyka rezydualnego i zdolność organizacji do działania.
Po trzecie, analiza ryzyka musi być powiązana z procesami biznesowymi. To one wyznaczają priorytety ochrony, a nie sama lista systemów lub raport techniczny.
Po czwarte, ryzyko musi mieć właściciela. Administrator może utrzymywać system, ale decyzja o akceptacji lub redukcji ryzyka powinna być decyzją zarządczą.
Po piąte, Threat Intelligence i zarządzanie ekspozycją powinny stale aktualizować ocenę ryzyka. Statyczna analiza raz w roku coraz częściej nie nadąża za rzeczywistością.
Celem nie jest eliminacja wszystkich ryzyk. To niemożliwe. Celem jest cyberodporność – zdolność organizacji do kontynuowania działalności mimo incydentów, zakłóceń i niepewności.
Od cyberbezpieczeństwa do odporności biznesowej
Największa zmiana w podejściu do cyberbezpieczeństwa polega na przejściu od ochrony systemów do ochrony zdolności organizacji do działania.
W tradycyjnym modelu pytaliśmy: czy system jest zabezpieczony? Czy mamy aktualizacje? Czy wdrożyliśmy polityki? Czy audyt zakończył się pozytywnie?
Dzisiaj powinniśmy pytać inaczej: czy organizacja wie, które procesy są krytyczne? Czy zna finansowe skutki ich zatrzymania? Czy rozumie, które podatności mogą realnie doprowadzić do przerwania działalności? Czy zarząd wie, kiedy ryzyko przekracza akceptowany poziom? Czy organizacja potrafi odtworzyć kluczowe usługi po incydencie? Czy właściciele procesów rozumieją swoją odpowiedzialność za ryzyko cyfrowe?
Najlepsze organizacje nie wygrywają dlatego, że nie mają podatności. Każda organizacja je ma. Wygrywają dlatego, że wiedzą, które ryzyka są naprawdę istotne, potrafią je mierzyć, monitorować i świadomie nimi zarządzać.
Cyberbezpieczeństwo nie staje się strategiczne wtedy, gdy raport dla zarządu ma więcej wykresów. Staje się strategiczne wtedy, gdy pomaga podjąć decyzję: które ryzyko akceptujemy, które redukujemy, które przenosimy na dostawcę lub ubezpieczyciela, a którego organizacja nie może sobie pozwolić ignorować.
W ProSystema właśnie tak patrzymy na cyberbezpieczeństwo: nie jako na zbiór dokumentów i zabezpieczeń technicznych, ale jako na praktyczny system podejmowania decyzji. Dobry model zarządzania cyberryzykiem powinien pomagać zarządowi odpowiedzieć na jedno kluczowe pytanie: gdzie redukcja ryzyka przyniesie największą wartość dla organizacji?
To jest moment, w którym cyberbezpieczeństwo przestaje być kosztem technicznym, a zaczyna być elementem odporności biznesowej.