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.
Poniżej znajduje się tłumaczenie jednego z rozdziałów dotyczące zasad programowania zgodnego z ww. zasadami.
Programowanie
Poniższa lista kontrolna jest dynamiczna i będzie regularnie uaktualniana.
Możliwe środki bezpiecznego programowania
- utworzenie listy zatwierdzonych narzędzi oraz bibliotek;
- skanowanie zależności pod kątem znanych podatności oraz nieaktualnych wersji;
- ręczne sprawdzenie kodu;
- statyczna analiza kodu pod kątem reguł bezpieczeństwa.
Należy korzystać z zatwierdzonych narzędzi oraz ram
Należy ustalić listę:
- zatwierdzonych narzędzi wraz z funkcjonalnościami,dotyczących bezpieczeństwa, które pozwolą zautomatyzować oraz wzmocnić procedury bezpieczeństwa przy programowaniu;
- zatwierdzonych komponentów pomocniczych;
- dozwolonych komponentów oraz narzędzi programistycznych stron trzecich.
Należy ustalić listę do czego będą wykorzystywane różne narzędzia oraz komponenty pomocnicze, która obejmuje nowe analizy bezpieczeństwa, funkcjonalności oraz ochronę. Narzędzia oraz komponenty pomocnicze powinny być poddane ocenie ryzyka oraz przeanalizowane pod kątem podatności w obszarach prywatności oraz bezpieczeństwa.
Listę należy aktualizować zgodnie z wytycznymi danej organizacji. Oznacza to, że nowe narzędzia oraz wersje oprogramowania muszą być ocenione oraz tam gdzie to możliwe, wykorzystane.
Należy korzystać jedynie z zatwierdzonych narzędzi oraz komponentów pomocniczych z listy. Wszelkie wyjątki powinny być dokumentowane oraz zatwierdzone przez inspektora ds. bezpieczeństwa.
Przykłady: wzorce projektowe oraz szablony dotyczące szeroko stosowanej funkcjonalności powinny być uogólnione, sprawdzone pod kątem jakości oraz udokumentowane jako obecnie stosowane wzorce/ szablony. Przykłady obejmują określenie w jaki sposób informacje z bazy danych powinny być wywoływane oraz ustrukturyzowane.
Przykłady zatwierdzonych narzędzi oraz komponentów wspierających, które muszą znajdować się na liście:
- biblioteka kodów;
- język programowania;
- system kontroli wersji;
- narzędzia testowe;
- infrastruktura;
- narzędzia monitorujące;
- logi serwerowe;
- ramy oraz interfejsy programowania aplikacji stron trzecich.
Praktyczne przykłady:
Organizacja podjęła decyzję dotyczącą metody programowania w odniesieniu do początkowego oraz dalszego rozwoju aplikacji. W związku z tym, musi być ona stosowana zarówno do wszystkich projektów, jak i w odniesieniu do menadżerów projektów. Korzystają oni z systemów zarządzania zadaniami, takich jak Jira lub Confluence. Wszystkie zadania mają dedykowanego właściciela, który jest również odpowiedzialny za ochronę danych oraz bezpieczeństwo zadania.
Status wszystkich aktywnych zadań jest określany na porannym spotkaniu zespołu, na którym mogą być również przedyskutowane wątpliwości, np. dotyczące ochrony danych. Sprawdzeniu kodu musi być przeprowadzone przez innego programistę. Jest to ważne w celu uniknięcia zależności programu od pracowników, jak również po to aby poprawić jego jakość.
Jednakże równie ważne jest, aby dodatkowa osoba sprawdziła kod oraz upewniła się czy zapewniono należytą ochronę danych oraz bezpieczeństwo. Należy stworzyć wersje testowe aplikacji oraz ustanowić właściciela programu (w ramach procesu).
Należy unieważnić niebezpieczne funkcje oraz moduły
- Niebezpieczne funkcje oraz moduły powinny być zarządzane przez narzędzia, takie jak OWASP Dependency Check.
- Należy wyłączyć niepotrzebne śledzenie, tworzenie logów oraz zbieranie danych osobowych.
Statyczna analiza kodu oraz jego sprawdzenie
- Należy ustanowić stałe rozwiązania oraz/ lub listy kontrolne dotyczące analizy statycznej oraz sprawdzenia kodu.
- Należy regularnie analizować oraz sprawdzać kod źródłowy oraz za każdym razem, gdy jest tworzony.
- Należy sprawdzić przepływ danych, przechowywanie oraz tymczasowe przechowywanie danych.
- Analiza statyczna pod kątem ochrony danych powinna być przede wszystkim przeprowadzana ręcznie, ponieważ „automatyczne” narzędzia oceny kodu pod kątem ochrony danych są ograniczone. Zidentyfikowanie wzorców może być trudne, ponieważ pojedyncze dane niekoniecznie stanowią dane osobowe, jednakże połączenia pomiędzy różnymi rodzajami danych mogą stanowić dane osobowe.
- Ważne jest, aby osoba która wykonuje pracę (recenzent) posiadał szeroką wiedzę na temat zarówno zasad ochrony danych, praw osób, których dane dotyczą oraz wymogów ochrony danych w fazie projektowania.
- Należy stosować różne poziomy skanowania, np. dla programistów, doradców ds. bezpieczeństwa oraz dla osoby odpowiedzialnej za zarządzanie produktem.
- Należy ustanowić wytyczne dotyczące tego co oraz kiedy powinno być skanowane.
Przykłady narzędzi do statycznej analizy kodu:
- RIPS PHP Static Code Analysis Tool, OWASP LAPSE+ Static Code Analysis Tool, SonarQube, Checkmarx.
Przykłady jak przeprowadzić statyczną analizę kodu:
- Regularne (np. codzienne lub tygodniowe) skanowanie;
- Skanowanie zarówno przy użyciu programów typu Scan Master jak i Dev Brancher, oraz przeprowadzanie pełnego skanu bezpieczeństwa;
- W przypadku skanowania wewnętrznego, należy sprawdzić minimalne wymogi bezpieczeństwa za pomocą programów typu Dev Brancher lub Scan Master (np. za pomocą SQL – Injection);
- „skanowanie na żądanie” jest przeprowadzone przez zintegrowane środowisko programistyczne użytkownika i stanowi pełni skan bezpieczeństwa.
- Należy wykorzystać listę kontrolną do sprawdzenia kodu:
- Przykład A1. Proszę znaleźć wszystkie punkty dostępu do bazy danych. Czy zapytania zawierające tzw. „zanieczyszczone zmienne” (ang. dirty variables) są łączone z bazą.
- Przykład A4: W jaki sposób blokuje się dostęp użytkowników do danych innych użytkowników?
Cechy, których należy szukać wybierając narzędzie do analizy kodu:
- Powinno być zaprojektowane w celach bezpieczeństwa.
- Powinno wspierać wiele poziomów (różne języki programowania oraz platformy).
- Musi istnieć możliwość jego rozbudowy. Narzędzie musi móc być rozbudowane w celu włączenia do niego nowych technik ataku oraz obrony.
- Musi być użyteczne zarówno dla analityków bezpieczeństwa jak i programistów.
- Powinno wspierać istniejące procesy programowania.
- Powinno być wartościowe dla różnych stron, będących właścicielami procesu programowania (np. interfejsy zawierające dane wspierające decyzje dotyczące zarządzania programem, sprawdzanie kosztów w przypadku zmian oraz dostarczanie informacji potrzebnych do utrzymania programu).
Dlaczego programować w sposób bezpieczny?
- Ogólne Rozporządzenie o Ochronie Danych stosuje się na etapie planowania stworzenia oprogramowania (proszę sprawdzić Art. 25 RODO);
- Narzędzia, systemy pomocnicze oraz infrastruktura powinna być aktualna, tzn. musi to być najnowsza oraz najbardziej uaktualniona wersja technologii (proszę sprawdzić Art. 25 RODO);
- Celem zarządu powinno być korzystanie z bezpiecznych oraz powszechnych metodologii w odniesieniu do:
- programowania;
- identyfikacji oraz usuwania podatności w kodzie;
- wykorzystywania zautomatyzowanych narzędzi do analizy kodu;
- statycznej analizy kodu oraz jego sprawdzenia.