Jak przełożyć wyniki testów penetracyjnych na ryzyka w ocenie skutków dla ochrony danych

Raport z testów penetracyjnych dostarcza szczegółowych informacji o technicznych podatnościach systemów informatycznych. Dokument ten nie kończy jednak pracy nad firmową dokumentacją ochrony danych osobowych. Stanowi on raczej punkt wyjścia i wskazuje konkretne obszary wymagające wnikliwej analizy. Zgodnie z unijnymi przepisami administrator musi regularnie weryfikować, czy zidentyfikowane luki wpływają na ogólne bezpieczeństwo informacji. Wyniki z takich technicznych weryfikacji pomagają obiektywnie ocenić sytuację organizacji. Proces ten staje się kluczowy, gdy przetwarzanie niesie wysokie ryzyko naruszenia praw osób fizycznych. To właśnie w tym momencie twarde ustalenia audytorów są podstawą do dalszych działań prawno-organizacyjnych. Zespół odpowiedzialny za zgodność musi przełożyć język techniczny na konkretne ryzyka dla prywatności.

Podatność techniczna a ryzyko prywatności w organizacji

Otwarty port usługowy lub nieaktualna wersja oprogramowania to typowe przykłady podatności technicznych infrastruktury. Pozostają one wyłącznie problemem operacyjnym działu IT, dopóki nie umożliwiają bezpośredniego dostępu do chronionych informacji. Ryzyko prywatności pojawia się dopiero w momencie, gdy zidentyfikowana luka pozwala na nieuprawnioną ingerencję w system. Dzieje się tak chociażby wtedy, gdy błąd aplikacji webowej otwiera drogę do pobrania numerów PESEL klientów.

Właściwie przeprowadzona analiza powinna wyraźnie oddzielać usterki infrastrukturalne od realnego zagrożenia dla podmiotów danych. Techniczna luka nabiera krytycznego znaczenia z perspektywy przepisów, gdy łączy się z przetwarzaniem informacji wrażliwych na dużą skalę. Zwiększa ona wówczas potencjalny zasięg naruszenia i wymaga natychmiastowych działań ograniczających skutki incydentu. Audytorzy oceniający środowisko informatyczne muszą ustalić najpierw rzeczywisty wektor potencjalnego ataku. Sprawdzają oni w praktyce, czy dany błąd konfiguracyjny faktycznie eksponuje dane, czy dotyczy jedynie odizolowanego środowiska testowego.

Brak odpowiedniej izolacji sieciowej między strefą publiczną a serwerami bazodanowymi to kolejny powszechny problem. Z perspektywy inżyniera sieciowego to błąd w architekturze wewnętrznego środowiska wirtualnego. Z punktu widzenia inspektora ochrony danych to z kolei ogromne ryzyko masowego wycieku informacji. Dlatego każda znaleziona w systemach usterka musi przejść przez rygorystyczny filtr szerszego kontekstu biznesowego.

Przekładanie wyników testu na rejestr ryzyk i zabezpieczenia

Z raportu powłamaniowego tworzy się precyzyjny wpis do dokumentacji analitycznej całej organizacji. Należy na początku jasno określić zasób narażony na zagrożenie, taki jak główna baza klientów w chmurze. Następnie opisuje się szczegółowy scenariusz potencjalnego ataku, bazując na łańcuchu exploitów. Warto przy tym uwzględnić kilka fundamentalnych elementów technicznych:

• zidentyfikowany przez testerów wektor początkowego ataku sieciowego,
• rodzaj przełamanych mechanizmów uwierzytelniających w systemie,
• maksymalny stopień uzyskanego dostępu do chronionych rekordów,
• możliwość utrzymania nieautoryzowanego połączenia przez dłuższy czas.

Klasycznym przykładem zidentyfikowanego błędu może być wstrzyknięcie złośliwego kodu. Prowadzi ono najczęściej do nieautoryzowanego zrzutu dużej tabeli. Możliwy skutek takiego incydentu to całkowita utrata poufności danych.

Aby rzetelnie przygotować dokumentację zgodności, konieczne jest umieszczenie ustaleń z testu w odpowiednich ramach formalnych. Gdy w firmie przeprowadzana jest zintegrowana ocena skutków dpia, techniczne detale stają się niezwykle przydatnymi dowodami. Ślady po symulowanym ataku oraz udowodniony dostęp uprzywilejowany bezpośrednio uzasadniają wdrożenie kosztownych środków ochrony. Raporty wskazujące na ekspozycję usług bez uwierzytelnienia pomagają w budowaniu argumentacji dla zarządu. Prawdopodobieństwo wystąpienia prawdziwego incydentu szacuje się często na podstawie globalnych wskaźników podatności CVSS.

Eksperci ISO-LEX SYLWIA KOCHMAN podczas realizacji projektów dla jednostek samorządu terytorialnego dokładnie mapują techniczne luki na język prawny. Zidentyfikowanie groźnych mechanizmów utrzymania dostępu w systemie wymusza niekiedy podjęcie decyzji o natychmiastowej segmentacji sieci. Każdy zidentyfikowany problem trafia do dedykowanej sekcji szacowania ryzyka. Tam specjaliści przypisują mu określoną wagę punktową i planują harmonogram wdrażania konkretnych zabezpieczeń naprawczych.

Aktualizacja dokumentacji i monitorowanie ryzyka resztkowego

Nie każdy nowy raport z weryfikacji bezpieczeństwa wymusza pisanie obszernej dokumentacji analitycznej od samego początku. Wewnętrzna procedura wymaga aktualizacji przede wszystkim wtedy, gdy wyniki wskazują na istotną zmianę poziomu zagrożenia. Dzieje się tak najczęściej po wykryciu zupełnie nowej luki w głównym systemie finansowo-księgowym instytucji. Wówczas organizacja dodaje kolejny wpis i określa akceptowalny poziom ryzyka resztkowego po zaaplikowaniu poprawek.

Jeśli wykryta usterka ma stosunkowo niski wpływ na prywatność, cały proces wygląda nieco inaczej. Administratorzy po prostu dopisują nowy środek zaradczy do istniejących rejestrów i regularnie monitorują jego działanie. Izolowana luka bez fizycznego lub logicznego dostępu do wrażliwych zbiorów nie wymaga pełnej rewizji procesu analitycznego. Trzeba jednak bezwzględnie pamiętać, że każda bardzo rozległa zmiana technologiczna powinna pociągać za sobą ponowne szacowanie ryzyka.

Znaczenie próbnych włamań w kontekście analizy prywatności polega na twardym weryfikowaniu założeń teoretycznych. Ustalenia analityków przekładają się bezpośrednio na racjonalne decyzje dotyczące budżetu na cyberbezpieczeństwo. Zamiast opierać się na branżowych domysłach, administrator zyskuje empiryczne dane o faktycznej skuteczności już wdrożonych mechanizmów kontrolnych. Zapewnia to możliwość ciągłego doskonalenia środowiska teleinformatycznego i utrzymanie pełnej zgodności z obowiązującymi przepisami prawa.