GDPR CX

GDPR CX

Nowe Rozporządzenie w zakresie ochrony danych osobowych (GDPR/RODO) wymaga, aby system został zaprojektowany adekwatnie do ryzyka związanego z przetwarzaniem danych osobowych. Aby sprostać wymaganiom jednym z elementów Audytu przygotowującego do wdrożenia RODO powinna być weryfikacja posiadanych systemów w tym aplikacji w kierunku podatności mogących mieć wpływ na wyciek danych osobowych.

Trzeba również pamiętać, iż Rozporządzenie wymaga, aby środowisko było w sposób ciągły poddawane testom na podatności.
W celu wykonania analizy podatności i zagrożeń aplikacji, dla których posiadamy prawa autorskie, możemy skorzystać z rozwiązań pozwalających na wykonanie statycznej analizy kodu źródłowego. Wskażą nam one miejsca gdzie aplikacja jest napisana w sposób niezgodny ze standardami bezpieczeństwa. Rozwiązania te określą nam luki oraz zagrożenia wraz z możliwością ich poprawy. Analizę taką należy wykonywać w każdym momencie, gdy wprowadzamy zmiany do aplikacji oraz za każdym razem, gdy pojawia się nowa wersja oprogramowania, którym dokonujemy statycznej analizy kodu, ponieważ wraz z nową wersją implementowane są nowo poznane podatności.

W przypadku, gdy aplikacja jest dostarczana przez dostawcę zewnętrznego i nie posiadamy praw autorskich do kodu możemy żądać raportu ze statycznej analizy kodu źródłowego przez dostawcę. Raport taki powinien być udostępniony zarówno na etapie pierwszego audytu jak i później okresowo w trakcie użytkowania aplikacji.

W fazie wyboru aplikacji należy zadbać o to, aby software house, który ma dostarczyć dla nas aplikacje wytwarzał je w środowisku Secure-SDLC. Takie podejście gwarantować powinno zaimplementowanie wymagań GDPR związanych z privacy/secure by design po stronie software house’u i weryfikację jakości kodu aplikacji pod kątem bezpieczeństwa, właściwe zarządzanie zmianą oraz możliwość reagowania na nowo wykryte podatności.

Z jakich rozwiązań korzystać dla procesu statycznej analizy kodu ?

Na pewno powinny być to rozwiązania komercyjne, dzięki którym jesteśmy wstanie w razie nieszczęśliwego zdarzenia udowodnić, iż dopełniliśmy należytej staranności w procesie wytwarzania czy odbioru aplikacji. Rozwiązanie ma wspierać odpowiednie, uznane standardy bezpieczeństwa OWASP TOP-10, SANS-25, czy PCI-DSS dla aplikacji mających dostęp do systemów transakcyjnych. Producent powinien jak najczęściej udostępniać nowe wersje oprogramowania, biorąc pod uwagę jak często pojawiają się informacje o nowych podatnościach. Wydaje się, iż niezbędne minimum to update cztery razy do roku.

Jeżeli będziemy realizować statyczną analizę kodu źródłowego we własnym zakresie to rozwiązanie musi być dla nas jak najbardziej przyjazne, nie powinno wymagać dużego nakładu pracy na konfigurację, ma dawać możliwość szybkiego i łatwego przeglądu znalezionych podatności oraz umożliwiać testy inkrementalne tak, aby skrócić czas oczekiwania na wynik. Ponadto musimy mieć możliwość konfiguracji naszych wymagań biznesowych względem aplikacji takich jak ograniczanie liczby danych przetwarzanych w aplikacji.

Pamiętać należy, że mamy prawo umieścić odpowiednie zapisy w procesie zakupowym, tak, aby na etapie procesu zakupowego odpowiednimi zapisami w umowie zagwarantować sobie, że wykorzystywane oprogramowanie będzie pozbawione podatności i możliwość wycieku danych z aplikacji. Dostarczenie aplikacji jest swego rodzaju outsourcingiem.

Podsumowując mamy obowiązek:

  1. w architekturze IT w procesie dostarczania aplikacji uwzględnić statyczną analizę kodu źródłowego;
  2. dokonać przeglądu umów z zewnętrznymi software house’mi i umieścić w nich stosowne zapisy;
  3. testować okresowo aplikacje do których posiadamy kody źródłowe;
  4. wymagać dostarczenia stosownych raportów od zewnętrznych dostawców.

Autor

Jarek Miller