Kara PUODO dla Morele.net okiem specjalisty IT – część I

  • 25.09.2019

  • Autor: Angelika Niezgoda i Marcin Jastrzębski

  • RODO w IT

Decyzja Prezesa Urzędu Ochrony Danych Osobowych dotycząca ukarania spółki Morele.net administracyjną sankcją pieniężną w wysokości 2 830 410 zł (co stanowi równowartość 660 000 EUR), wzbudziła w ostatnim tygodniu wiele emocji. Wiemy, że doszło do naruszenia integralności i poufności  danych osobowych ponad 2 milionów klientów ukaranej spółki. Wiemy, że przyczyny tego naruszenia Prezes Urzędu dopatrzył się w lukach dotyczących zabezpieczeń po stronie IT, w stosowanych przez administratora systemach. Spróbujmy przeanalizować, czy faktycznie proponowane przez Urząd działania mogłyby uchronić spółkę przed przykrymi konsekwencjami?

 

Analiza ryzyka

Jednym z obowiązków administratorów danych jest cykliczne przeprowadzanie analiz ryzyka pod kątem naruszenia praw i wolności podmiotów danych, których dane osobowe administrator przetwarza. Z decyzji dowiadujemy się, że spółka dokonywała doraźnych analiz ryzyka dla poszczególnych procesów przetwarzania danych w sposób niesformalizowany. Sposób ten faktycznie może budzić wątpliwości co do poprawności działania, ze względu na brak powtarzalności oraz możliwości weryfikacji i nadzoru zastosowanych w wyniku takiej analizy ryzyka zabezpieczeń i ich skuteczności.

Co niemniej istotne, z przedstawionych w decyzji informacji wynika, że spółka nie sprawdzała w ramach analizy ryzyka potencjalnych ryzyk dla przetwarzanych danych, ale jedynie badała podatności znane już dla wykorzystywanych w procesie przetwarzania komponentów IT. Bazowanie jedynie na zidentyfikowanych już podatnościach aktywów oraz weryfikowanie skuteczności zastosowanych w celu wyeliminowania tych podatności zabezpieczeń, nie wyczerpuje zakresu analizy ryzyka, którą administratorzy danych zobowiązani są przeprowadzać. Takie podejście mogłoby ograniczać się jedynie do ciągłej weryfikacji, czy podmiot posiada oprogramowanie w wersji aktualnej, co ma wykluczać obciążenie znanymi podatnościami, do których nie dostosowano zabezpieczeń. Do sprawdzania aktualności wersji stosuje się dedykowane skanery, czyli zewnętrzne narzędzia bezpieczeństwa, które służą do wykonania testów bezpieczeństwa – ale to podstawowy element stosowany w ramach testów bezpieczeństwa – i jak powszechnie wiadomo, niewystarczający.

Poza tym, że ograniczanie się do weryfikacji aktualności oprogramowania, jest niewystarczające ze względu na obowiązujące przepisy, należy też pamiętać, że nie dla każdego rodzaju komponentu IT będziemy mogli z łatwości wgrać aktualizację. Zdarza się, że ze względu np. na potrzeby ciągłości działania organizacji, nie jesteśmy w stanie wyłączyć z użycia np. serwera, na którym zapisane jest oprogramowanie, dla którego planujemy aktualizację, gdyż to mogłoby zaburzyć w sposób istotny funkcjonowanie całej spółki. Ten problem można rozwiązać stosując co najmniej kilka warstw zabezpieczających. Przykładowo serwery backend’owe mogą zostać oddzielone od frontend’u za pomocą rozwiązań typu reverse proxy, czyli mechanizmów pośredniczących w ruchu pomiędzy nimi. Dzięki temu podatności wykryte w warstwie backend’owej nie są bezpośrednio narażane na wykorzystanie.

Co jednak z pożądanym zakresem analizy ryzyka? Powinien on poza znanymi podatnościami obejmować także podatności potencjalne, czyli takie, dla których nie mamy już wdrożonych czy zaplanowanych zabezpieczeń, ale w stosunku do których powinniśmy dobierać środki zabezpieczające. Zasadą powinno być opieranie systemu zabezpieczeń na więcej niż jednym mechanizmie  bezpieczeństwa, z uwagi na brak istnienia niezawodnego mechanizmu, zapewniającego bezpieczeństwo w 100%.

 

Zwiększony ruch na bramie sieciowej

Kolejną kwestią podniesioną przez Urząd, jest niestwierdzenie przez spółkę zwiększonego ruchu na bramie sieciowej w czasie, gdy dochodziło do pobierania bazy danych klientów, pomimo iż spółka deklarowała nieprzerwane monitorowanie ruchu sieciowego w trybie 24/7.

Czy faktycznie za pomocą stosowanego monitoringu ruchu sieciowego można byłoby wykryć włamanie do bazy i zapobiec jego skutkom? Z prostego ćwiczenia (które każdy z nas może przeprowadzić) wynika, że plik tekstowy zawierający 2 miliony rekordów danych logowania zajmuje kilkadziesiąt MB. Przepływ takiego pliku z punktu widzenia monitorowania ruchu sieciowego nawet małej organizacji jest nieistotny. Plik z danymi klientów, wygenerowany w odpowiedzi na zapytanie włamującego i wysłany do niego, powoduje ruch sieciowy zbliżony do tego, jaki generuje kilku użytkowników. Zatem z punktu widzenia monitorowania sieci, trudno byłoby zauważyć coś niepokojącego.

Inaczej zdecydowanie sytuacja przedstawia się z punktu widzenia monitorowania bazy danych. Jedno duże zapytanie, które w odpowiedzi zwróciło jednemu zewnętrznemu użytkownikowi kilka milionów rekordów, powinno zostać zauważone i sprawdzone. Potencjalnym zagrożeniem dla danych osobowych jest możliwość włamania się do bazy z zewnątrz. Włamanie takie może być skutkiem np. odpowiednio zdefiniowanego zapytania w języku SQL, wykorzystującego podatność typu SQL injection. Znane są jednak powszechnie narzędzia służące do wykrywania tego typy ataków, jak również narzędzia do monitorowania zapytań do baz danych. Korzystanie z takich narzędzi, adekwatnych do przetwarzanych danych oraz stosowanych rozwiązań IT, pozwala ograniczyć ryzyko nieuprawnionego dostępu do bazy, a w konsekwencji wycieku danych.

Autor

Angelika Niezgoda i Marcin Jastrzębski

Angelika Niezgoda - 0d kilku lat zajmuje się tematyką ochrony danych osobowych i bezpieczeństwa informacji. Jako certyfikowany Inspektor Ochrony Danych prowadzi audyty bezpieczeństwa danych i czuwa nad projektowaniem i wdrażaniem procedur ochrony danych osobowych zgodnych z wymogami RODO.

Marcin Jastrzębski - audytor i specjalista ds. systemów informatycznych. Realizuje projekty audytorsko-analityczne związane m.in. z ochroną i zabezpieczeniem danych osobowych w systemach IT, oceną zaawansowania wdrożonych w organizacji środków zabezpieczeń technicznych i organizacyjnych oraz analizami ryzyka.