Testowanie oprogramowania według Norweskiego Organu

Na stronie Norweskiego Organu Ochrony Danych znajdują się Wytyczne w sprawie rozwoju oprogramowania zgodnie z zasadami ochrony prywatności w fazie projektowania oraz domyślnej ochrony danych. Całe wytyczne, składające się z około 10 rozdziałów dostępne są w języku angielskim tutaj: https://www.datatilsynet.no/en/regulations-and-tools/guidelines/data-protection-by-design-and-by-default/. Poniżej natomiast znajduje się tłumaczenie jednego z rozdziałów dotyczącego testowania oprogramowania. Treść przetłumaczonego rozdziału w języku angielskim znajduje się tutaj: https://www.datatilsynet.no/globalassets/global/english/guidelines/privacy-by-design/checklist_testing.pdf.

Testowanie

Niniejsza lista kontrolna jest dynamiczna i regularnie uaktualniana.

Testuj czy wymogi ochrony danych oraz bezpieczeństwa, określone w części Wymagania zostały rzeczywiście prawidłowo wdrożone:

Pamiętaj, że regulacje dotyczące ochrony danych stosuje się również do środowiska rozwoju aplikacji oraz środowiska testowego.
Zapewnij pełne zrozumienie funkcjonalności oraz informacji.
Sprawdź, czy etapy określenia wymagań oraz projektowania spełniły wymogi bezpieczeństwa oraz ochrony danych. Można to np. zrobić, poprzez ustanowienie standardowych scenariuszy testowych opartych o wymogi funkcjonalne, które mogą być powtarzane w ramach działalności biznesowej.
Przygotuj listę kontrolną w celu sprawdzenia, czy zawarto wszystkie elementy potrzebne do zapewnienia zgodności. Obejmuje to również nowe komponenty, które mogły nie być uwzględnione przy pierwotnym określaniu wymogów. Przykłady:
Wszystkie ustawienia powinny być domyślnie skonfigurowane w sposób możliwie najbardziej przyjazny prywatności.
Musi być możliwy import oraz export danych osobowych osoby, której dane dotyczą (przenoszalność danych).
Czy dane są zapisywane w odpowiednim miejscu?
Czy zbierane dane są konieczne dla celu oprogramowania?
Osoba, której dane dotyczą powinna być w stanie udzielić zgody (dotyczy to również dzieci oraz osób pozostających pod opieką opiekuna).
Osoba, której dane dotyczą musi mieć możliwość odmowy lub wycofania zgody.
Czy możliwe jest zakończenie kontraktu/ umowy, zainstalowanie, odinstalowanie, aktywowanie oraz dezaktywowanie programu, usługi, komponentu czy systemu?
Kontrola dostępu.
Dostęp wyłącznie dla upoważnionych stron.
Kontrola dostępu jest przystępna dla osoby, której dane dotyczą.
Udzielenie dostępu do opcji poprawienia, zablokowania lub usunięcia danych osobowych.
Powinna istnieć możliwość przesłania zapytań oraz skarg dotyczących ochrony danych oraz bezpieczeństwa.
Osoba, której dane dotyczą może zastrzec, ze nie chce być profilowana.
Zdobądź informacje dotyczącą tego w jaki sposób podejmowane są zautomatyzowane decyzje, jakie dane są zbierane oraz przetwarzane, gdzie dane osobowe są przechowywane, przejrzystość, itp.
Przetestuj istnienie oraz działanie procedur powiadomień. Sprawdź czy powiadomienia są odbierane (np. przygotuj projekt tekstu, który może być wykorzystany w przypadku wystąpienia incydentu, obejmujący środki zapobiegające wystąpieniu podobnego incydentu w przyszłości), jak również jakie środki zostały przyjęte w celu zapobieżenia jakiemukolwiek wpływowi na osobę, której dane dotyczą.
W celu przetestowania poprawności, rzetelności, celowości, odpowiedniości, minimalizacji danych oraz odporności wykorzystuj sztuczne dane osobowe.
Korzystaj z prawdziwych danych tylko w celu zapewnienia jakości (QA), kiedy oprogramowanie zostało wdrożone do środowiska produkcyjnego, a użytkownicy będą korzystali z oprogramowania. Testy przeprowadzane na prawdziwych danych powinny być przeprowadzane przez profesjonalistów, którzy są upoważnieni do wglądu do takich danych, jak np. odpowiedni profesjonaliści zajmujący się programami dobrobytu dzieci w sektorze dobrobytu dzieci, administratorzy systemu w odniesieniu do dzienników pacjentów lub administratorzy systemu w szkołach.
Wyszukuj prawdziwe dane osobowe oraz sprawdzaj dlaczego się pojawiają. Można to zrobić np. poprzez regularne skanowanie potencjalnych wycieków krajowych numerów identyfikacyjnych.

Testowanie bezpieczeństwa poprzez sprawdzanie podatności w oprogramowaniu

Dynamiczne testowanie: przetestuj funkcjonalność działającego kodu poprzez zastosowanie narzędzi lub ręcznego przeglądu, w celu przeanalizowania w jaki sposób oprogramowanie zachowuje się przy zastosowaniu kont z różnym stopniem uprzywilejowania oraz w odniesieniu do krytycznych podatności w obszarze bezpieczeństwa.
Preferuj zatwierdzanie danych wejściowych w oparciu o białą listę, a nie o czarną listę (whitelist input validation).
Przeprowadź analizę podatności na poziomach aplikacji oraz sieci. Analiza powinna mierzyć skutek wdrożonych technicznych oraz organizacyjnych środków bezpieczeństwa. Korzystaj z narzędzi testowych. Np. testuj pod kątem haseł domyślnych, haseł przechowywanych w plikach, ataków polegających na wprowadzeniu kodu SQL (SQL injection), ataków polegających na wprowadzeniu kodu (script injection), ataków cross-site scripting (SSC), brakującego potwierdzenia, dostępu do logów, kopii zapasowych oraz lokalizacji tymczasowych przez osoby nieupoważnione.
Testuj kontrolę dostępu oraz faktyczny dostęp do użytkowników.
Przykłady żądań metodą GET: zaloguj użytkownika 1, przekopiuj wszystkie linki, wyloguj użytkownika, zaloguj użytkownika 2, itd. Sprawdź wszystkie linki pochodzące od jednego użytkownika, które są dostępne dla nieupoważnionych użytkowników lub innych użytkowników. Przetestuj wszystkie poziomy pozwoleń, wykorzystując przynajmniej dwóch użytkowników na każdym poziomie dostępu.
Proste testowanie przez osoby, niebędące specjalistami: wykorzystaj np., przeglądarkę internetową oraz sprawdź czy wpisanie żądania GET w przeglądarce pozwoli na dostęp do prywatnego URL.
Zaawansowane testowanie przez profesjonalistów. Wykorzystaj np. narzędzia burp suite lub burp repeater,w celu sprawdzenia żądań POST oraz sesyjnych plików cookie.
Parametry, które można powtórzyć (np. ID=42, 43, 44, etc.) powinny być powtórzone oraz sprawdzone pod kątem kontroli dostępu.
Sprawdź zarządzanie sesją oraz plikami cookie, np. w jaki sposób działa login oraz kontrola dostępu oparta na plikach cookie. (Jeżeli po zalogowaniu generowany jest nowy plik cookie, czy sesja jest usunięta po stronie serwera czy usunięta wyłącznie z wyszukiwarki użytkownika?).
Fuzzing (Fuzz Testing) – fuzzing polega na zamierzonym wywoływaniu błędów
w oprogramowaniu. Można to zrobić poprzez wykorzystanie narzędzi, które wysyłają losowe oraz zdeformowane dane (niewłaściwe dane wejściowe) do wszystkich możliwych wejść oprogramowania, czy to ręcznie czy przy zastosowaniu inteligentnych narzędzi, które analizują podatności w aplikacjach sieciowych. W przypadku gdy oprogramowanie posiada wiele interfejsów, należy przetestować każdy z nich. Korzystaj z narzędzi, które mogą analizować dane wyjściowe oraz uwzględniają bezpieczeństwo.
Testy penetracyjne/ analiza podatności: Przeprowadzaj testy penetracyjne lub analizę podatności w odniesieniu do nowo tworzonego oprogramowania, przed jego wypuszczeniem, lub w regularnych odstępach czasu, w celu odkrycia podatności. Optymalnym rozwiązaniem byłoby wykorzystywanie różnych testerów za każdym razem. Testy bezpieczeństwa, takie jak te, muszą być legalną oraz zatwierdzoną próbą znalezienia, wykorzystania oraz wykrycia podatności. Skutkiem takich testów powinno być wdrożenie środków wzmacniających bezpieczeństwo. Zauważ, że w przypadku testów penetracyjnych może zachodzić konieczność zawarcia odpowiednich umów.
Można to zrobić zarówno wewnętrznie jak i zewnętrznie. Należy ocenić co jest bardziej odpowiednie biorąc pod uwagę nową funkcjonalność usługi;
Skorzystaj z pomocy ekspertów ds. bezpieczeństwa zarówno przeprowadzając test jak i analizując jego wyniki;
Przetestuj elementy bezpieczeństwa ochrony danych w fazie projektowania. Przykładami podatności, które mogą być wykryte są: hasła, instalacja zdalnych programów kontrolujących w przeglądarkach internetowych, kliencie lub na serwerach, kopie zapasowe baz danych (database dumping), przekazywanie danych lub przechowywane dane, co obejmuje buforowanie, przerywanie, przechwytywanie sesji lub połączenia, wykorzystanie plików cookie, złamanie szyfrowania, wykorzystanie nieodpowiedniej kontroli dostępu, itd.;
Testowanie na wielu etapach;
Środowiska testowe, np. przegląd aplikacji (testowanie w celu znalezienia podatności w kodzie);
Integracja oraz środowisko testowe systemu, np. statyczny oraz dynamiczny test aplikacji;
Testowanie w środowisku użytkowym, np. fuzzing, skanowanie w poszukiwaniu podatności, oraz testy penetracyjne aplikacji oraz infrastruktury.
Wprowadź automatyczne wykonywanie testów przed wypuszczeniem aplikacji, takich jak:
testy bezpieczeństwa, które są uruchamiane za każdym razem gdy aplikacja jest budowana lub dalej rozwijana. Gdy występują błędy w trakcie produkcji:
można uniknąć podobnych błędów poprzez stworzenie automatycznego testu takiego błędu, oraz dodanie go do zestawu testowego.

Dokonaj przeglądu powierzchni ataku

Sprawdź czy wektory ataku odkryte podczas fazy projektowej zostały rozwiązane;
Sprawdź czy nowe wektory ataku wprowadzone w trakcie wprowadzania oprogramowania zostały zidentyfikowane oraz rozwiązane.
Dokonaj przeglądu modelu zagrożeń w kontekście nowo rozwijanego oprogramowania.
Dokonaj powtórnej oceny wpływu na ochronę danych, która została oceniona w fazie określana wymagań, ponieważ wymagania mogą się zmienić w trakcie rozwoju procesu, bez dokonania oceny.
Zwróć szczególną uwagę czy nie jest przekazywanych więcej danych niż wymaga tego oprogramowanie, oraz czy danym tym nie brakuje ochrony ani podstawy prawnej.

Po co ustanawiać wymogi sprawdzania oraz testowania?

Wymogi dotyczące ochrony danych oraz bezpieczeństwa, które zostały zawarte
w niniejszym zestawie testowym muszą być wprowadzone, i to wprowadzone poprawnie. Patrz art. 5, 7, 25, 35 oraz 11-23 RODO;
Niepoprawne wartości wejściowe nie mogą przyczynić się do naruszenia poufności, integralności lub dostępności danych. Patrz art. 32 RODO;
Powierzchnie ataku nie mogą zawierać podatności, które mogą się przyczynić do naruszenia poufności, integralności lub dostępności danych. Patrz art. 32 RODO.