Ochrona danych w fazie projektowania. Wymogi RODO w tworzeniu oprogramowania - podsumowanie

Urząd Ochrony Danych osobowych w dn. 21 września 2018 r. zorganizował konferencję "Ochrona danych w fazie projektowania. Wymogi RODO w tworzeniu oprogramowania". Niestety w tym czasie byłem w podróży, ale to nie powód do zmartwienia, bo konferencja była nadawana online, a później została opublikowana w serwisie YouTube pod adresem https://www.youtube.com/watch?v=6YT7Xjf9hnM.

Ściągnąłem więc ten filmik za pomocą youtube-dl i oglądałem na raty, głównie podczas lotu samolotem. Dzisiaj - 19 grudnia - po prawie trzech miesiącach - mogę napisać podsumowanie. Niezły czas. W tym czasie pojawiło się kilka innych filmików :-) więc tempo mam, że hoho.

Przede wszystkim możemy być dumni z naszego organu nadzorczego, że nadaje na żywo, że publikuje, i że organizuje takie spotkania. 2 tysiące osób obejrzało ten firm - to są dwa tysięce osób, które wiedzą więcej. Nie wszystko było idealnie, ale lepsze to niż nic.

Zacznę od podsumowania.

 
A podsumowanie zacznę od... małej krytyki. Urząd konferencję nazwał prawidłowo - chodzi o ochronę danych w fazie projektowania. A prelegenci mylili prywatność z ochroną danych. Privacy by design to nie to samo co data protection by design. Programistom można wybaczyć, ale prawnikom nie można. Nie można dlatego, że litera prawa to litera prawa, skoro w RODO nie ma ani razu słowa prywatność, to go nie ma. Zgadzam się, że historia ochrony danych "by design" wzięła swój początek od "Privacy by design - The 7 foundational principles" autorstwa Ann Cavoukian, piastującej w Kanadzie stanowisko podobne do Prezesa Urzędu Ochrony Danych Osobowych. Ale to nie zmienia faktu, że prywatność a ochrona danych osobowych to nie to samo. Prócz tego myli się ochronę danych osobowych (data protection) z ich zabezpieczeniem (security), ale to już mniej boli :-)
 
Niezwykle mało było o ocenie skutków, a przecież ocena skutków to podstawa oceny ryzyka. Niewiele o minimalizacji danych. Pseudonomizacja i tokenizacja też prawie nieobecna. Retencja danych to także część data protection by design - a było bardzo mało. Domyślne ustawienia - o tym kiedy i jak angażować inspektora lub kogo angażować, gdy go nie ma... - też by się przydało.
 
No dobra, to teraz o tym co było. Będę rzucał hasłami, aby zorientować się mniej więcej w temacie. Tu i ówdzie jakaś uwaga ode mnie. Po szczegóły odsyłam do wideo.

Maciej Gawroński - Jak zakodować RODO...

Intresujące, niekiedy nowatorskie, zagadnienia:
  • Dane osobowe w logach nie powinny się znajdować. 
  • Mikrozarządzanie danymi -- że można ustalać wartości pól na poziomie pojedynczych rekordów (sprzeciw, etc)
  • Ten, kto przygotowuje raport art. 15 będzie wiedział całkiem sporo. Dane z wielu miejsc mogą nie być spójne
  • "Dane osobowe osobiste" / "dane osobowe wieloosobowe" - ciekawe terminy
  • z RODO nie wynika obowiązek dokumentowania algorytmów decyzyjnych profilowania (art. 22)
  • szybkie odtwarzanie aplikacji -- szyfrowanie to może utrudniać
  • środki odpowiednie do ryzyka - mecenas ich dobór "zrzuca" na programistów (uważam, że oni powinni dostarczyć tyle możliwości, aby administrator sobie wybrał co mu potrzeba)
Dygresje fajne, ale jak ogląda sie wideo, które trwa 5 godzin, to zastanawiam się, czy nie lepiej z nich zrezygnować (mieszkanie z teściową, prawo dostępu do danych, że to jego wina, e nikt nie lubi DRM, że niektórzy są Linuxowcami
 
 

Dr inż. Wacław Iszkowski (PIIT) - Informatyk czyta RODO i GDPR

Prawdziwa bomba! Warto zajrzeć na www.iszkowski.eu/rodo - A. Kapczyński w swojej prezentacji podkreśla, że tam jest dużo ciekawego o absurdach. Zajrzałem - haha - rzeczywiście jest. I sporo ciekawych publikacji w samej rzeczy. Strona przypomina te z lat 90, co też nie dziwi - 50 lat w informatyce!
 
  • porusza standardy tłumaczenia aktów - bardzo ciekawe - bardzo interesujące!
  • proponuje uproszczenie terminów w RODO - prawdziwa rewelacja!
  • personal data to dana osobowa, set - to zbiór, więc nie rozumie dlaczego mówimy o zestawach danych, a filing system - jako zbiór danych to bzdura, to raczej system archiwizacji danych (chodzi mu o zbiory ewidencyjne - np. szafy z segregatorami), a jeszcze bardzie podoba mi się objaśnienie tłumaczeń "controller" i "processor"
  • kolejny fajny termin - dana osobowa wystarczająca i dana osobowa niewystarczająca - no rewelacja!
  • dla każdej danej powinna być data ważności tych danych (ma to sens, że np. przy danej informacji jest data, kiedy ta informacja została potwierdzona) - np. dzwonić na numer telefonu sprzed 10 lat nie ma sensu, wysoce prawdopodobne że numer się zmienił.

Dr inż. Adrian Kapczyński - RODO z perspektywy twórców oprogramowania

Warto odwiedzić strony http://itsssl.com/rodev oraz rodev-a i rodev-q - ale już dzisiaj te linki powygasały... 
 

Janusz Żmudziński, PTI - Potencjalne problemy związane z wdrożeniem odpowiednich środków technicznych

  • Dużo o tym, pewnie dlatego, aby twórcy oprogramowania i rozwiązań rozumieli, jakiego rodzaju szyfrowanie wybrać - ale kontekst RODO bardzo organiczony. 
  • Pada pytanie jak na szyfrowanie będzie patrzeć kontrola UODO. 
  • Zapisy RODO okiem informatyka. Szyfrowanie jest 4 razy w RODO, ale nic nie jest wyjaśnione co się przez nie rozumie - czy szyfr (kod) Cezara to szyfrowanie czy nie?
  • Jedyne wspomniane środki techniczne to pseudonimizacja i szyfrowanie. To fakt, sam też zauważyłem, że twórcy RODO mieli jakiegoś świra na punkcie szyfrowania :-)
  • Słowo o kryptologii, kryptografii, etc. Szyfrowanie implementowane przez własnych developerów i algorytmy szyfrowania ich produkcji
  • Kryptografia nie likwiduje problemu (B. Schneier) - warto o tym pamiętać. 
  • Kryptografia jest bardzo trudna (B. Schneier ponownie) - nie róbmy jej samemu, jeśli nie znamy się na tym. Żadnych własnych algorytmów, lepsze gotowe niż własnej roboty
  • Zasada Kerckhoffsa - nawet jak wszystko jest znane, poza kluczen, to szyfrowanie jest wciąż bezpieczne. Najbardziej istotne jest zabezpieczenie klucza. Nie algorytmu.
  • Poczta idzie z zaszyfrowanym załącznikiem i w tym samym pliku jest… hasło (ja tego nie widziałem, ale widziałem w postaci w jednym mailu szyfrogram, a za chwilę w drugim hasło)
  • W przypadku szyfrowania - atakować można szyfrowanie, można atakowac hasło
  • Podpis elektroniczny - z dokumentu tworzy się skrót, szyfruje się go kluczem prywatnym, a odbiorca może z kluczem publicznym podpisującego odszyfrować - no ale to wie każdy, kto zna podstawy szyfrowania
  • Bezpieczeństwo to proces a nie produkt (znowu Schneier - guru kryptografów).
  • Hackerzy też korzystają z szyfrowania - ransomware :-)
 

Błażej Pabiszczak, Yetiforce, OWASP - Budowanie aplikacji zgodnie z OWASP i uwzględniając najnowsze standardy

  • OWASP ASVS - application security verification standard
  • OWASP - fundacja, której celem jest edukowanie programistów, aby tworzyli bezpieczne aplikacje
  • Szyfrowanie - jedna z wielu, wielu rzeczy o których trzeba pamiętać
  • Architektura, projektowanie i modelowanie zagrożeń (ASVS 3.1 - 1)
    • 1.1 - wszystkie elementy aplikacji są konieczne - im mniej, tym lepiej, jeśli coś nie jest wykorzystywane, to jest zbędne (może tylko stwarzać niepotrzebne problemy, ryzyko)
    • 1.2 - kontrola bezpieczeństwa po stronie serwera, nie tylko po stronie aplikacji czy przeglądarki
    • 1.9 - jest mechanizm wymuszania aktualizacji
    • 1.12 - wszystkie elementy są wolne od podatności
  • Narzędzie snyk - wykonuje analizę statyczną kodu (http://snyk.io)
  • Sensio Labs Security - sprawdza czy są podatności w wykorzystywanych przez aplikację bibliotekach (ma  to sens, bo aplikacje często korzystają z rozmaitych bibliotek)
  • https://insight.sensiolabs.com - pokazuje też błędy w kodzie zarówno bezpieczeństwa jak i związane z jakością.
  • GitHube Dependency Graph / OWASP Dependency Check
  • Zdaniem prelegenta nie można powiedzieć, że niewiadomo jak tworzyć bezpieczne aplikacje - wszystko jest publicznie i za darmo dostępne.
 

Dariusz Stefański, NASK, Privacy by design – jakie aspekty uwzględnić w fazie projektowania

  • zgodnie z art.24 RODO należy uwzględnić:
    • cele przetwarzania, charakter, zakres, kontekst - dla wdrażającego najważniejszy jest kontekst
    • ryzyko naruszenia praw
    • stan wiedzy technicznej
    • koszt wdrażania
  • Powinniśmy mówić o security by design, a nie o ochronie danych by design czy privacy by design
  • Inspektor Ochrony Danych ma dostarczać wymagania - prelegent sugeruje, że to rola konsultacyjna. Powinien być włączany jak najwcześniej. 
  • Projektowanie systemu z automatu będzie tworzyć rejestr czynności przetwarzania
  • Zabezpieczenia dobierane na podstawie analizy ryzyka - prelegent wspomina metodyki, zaś mówi o ryzykach z perspektywy bezpieczeństwa danych
  • privacy by design powinien zostać udokumentowany (moim zdaniem RODO nie stawia takiego wymagania, na pewno jednak warto gdzieś napisać, co się zrobiło, że data protection by design and by default zostało zastosowane
  • definiowanie scenariuszy ataku - dobry pomysł
  • ENISA  raport z Dec 2014 r. (warto zapoznać się)
    • minimalizacja - jak najmniej danych, zgodnie z celem,
    • kontrola, przejrzystość, inne ciekawe pryncypia/terminu
  • Bezpieczeństwo repozytorium kodu (często zapomina się o tym!)
  • Bezpieczny kod (o tym już było, OWASP, etc)
  • Odwołanie do norm - w tym ISO 29100, ISO 29151. W końcu ktoś zauważył normy inne niż rodzina 27000! Dobra robota!
  • cała lista rzeczy jakie należy uwzględniac - ja bym to podsumował jako typowe i dobre praktyki bezpieczeństwa
 

Piotr Siemieniak / UW/AMW / UP Secure - Jak się uczyć na błędach innych? Błędy programistyczne, które doprowadziły do naruszeń ochrony danych

  • Naruszenia są różne, rozmaite mogą być ich skutki - ja jeszcze raz podkreślę, że chodzi o skutki przede wszystkim, prawdopodobieństwo ma poniekąd wtórne znaczenie
  • Przykłady są brytyjskie:
    • System zarządzania mandatami - modyfikując adres URL można było zmieniać parametry i odczytać cudze dane. Ujawniono dane 71 osób (hm, ciekawi mnie jak to wykryto? logowanie?). &0 tys. GBP kara, a pentesty wyniosły by znacznie mniej (prelegent założył od 2 do 15 tys. myślę, że nawet bez pentestów   by się obeszło, bo dobry i świadomy developer by to wyłapał, ba! nawet dobrze sformułowane wymagania dałyby radę. Za głupotę, a raczej niewiedzę, trzeba płacić.
    • Talk Talk (taki nasz dawny TakTak czy dzisiaj byłby to jakiś Heyah) - ta firma przejęła inną firmę, która zaś miała stary i podatny soft. ICO (brytyjski UODO). Cybebezpieczeńśtwo to nie jest problem IT, to problem Zarządu. Kara - 400 tys. GBP. A można było zainwestować ułamek tej kwoty i miec problem z głowy. Na stronie ICO czytamy:

"Today’s record fine acts as a warning to others that cyber security is not an IT issue, it is a boardroom issue. Companies must be diligent and vigilant. They must do this not only because they have a duty under law, but because they have a duty to their customers."

  • Gloucester City Council - maile wyciekły z urzędu - firma wyoutsourcowała systemy / pocztę i nie wnikała więcej. Często spotykane. Outsourcer dał ciała, ale karę dostał urząd. Nie dziwi więc, że RODO nakazuje ostrożnie dobierać dostawców.
  • Błąd "nieużywania" BCC - no ale to nie ma już zbyt wiele wspólnego z ochroną danych by design, nie mówiąc o tym, że nie jest to też błąd programistyczny. Kara 80 tys. GBP - głównie dlatego, że zagadnienie i ryzyko jest znane, a jednak przydarzyło się. Kara za głupotę - tak mozna to ocenić.
  • BA - obcy kod kradł dane
 

Adam Masiak, T-Mobile Polska, - Podejście oparte na ryzyku – czyli jak określić odpowiednie techniczne środki ochrony danych w systemie informatycznym

 
  • Podejście oparte na ryzyku - bardzo fajna definicja, cieszy wprowadzenie cykliczności i utrzymania w czasie
  • Art. 32 fajnie podzieony na konekst organizacyjny,  osoby oraz element systematycznej oceny 
  • oceniamy obecne rozwiązania (a więc szyfr cezara byłby dobry w czasach cezara, ale nie dzisiaj)
  • uwzględniamy koszt - nie strzelamy z armaty do muchy!
  • macierze typu WORM - nie pozwalają na usuwanie danych (ciekawe, do zbadania)
  • należy uwzględnić rozmaite rodzaje zagrożeń
  • szacowanie ryzyka - uwzględniać aktywa informacyjne i kontekst osoby fizycznej
  • NIST jest za darmo, nie to co ISO :-) - argument nie do pobicia!
  • Trzeba zastanowić się nad dwoma matrycami prezentującymi to samo zagrożenie / tę samą podatność ale w dwóch kontekstach - organizacji i podmiotu danych - no rewelacja! I to jeszcze kilka razy podkreślane. 
 
I tyle. Uff!