security

Cyberbezpieczeństwo IoT

 

Bezpieczeństwo Internetu Rzeczy to delikatna kwestia. Z jednej strony coraz częściej stykamy się z artykułami dotyczącymi istoty działania IoT oraz wartości dodanej, którą przynosi zbieranie danych. Z drugiej: pisanie o technologii językiem liczb albo zbyt szczegółowo, potrafi zasłonić ważny temat, jakim jest skutecznie testowanie. Mam tu na myśli testowanie rozumiane nie tyle z perspektywy funkcjonalności, co bezpieczeństwa, które zwykle jest ignorowane albo znacząco niedoszacowane.

Po 7 latach pracy w branży i współpracy ze znaczną liczbą klientów z całego świata, reprezentujących zarówno rynek prokonsumencki (medycyna, sport, rozrywka), jak i industrialny (automotive, transformacje jutra), mogę z całą stanowczością stwierdzić, że rynek wciąż nie jest świadomy, jak istotne jest zagwarantowanie klientowi bezpieczeństwa produktu.

Zagrożenia czyhające na firmy

Specyfika IoT wymaga istnienia fizycznego urządzenia, dedykowanego oprogramowania, algorytmu zbierania danych oraz sieci, która przetwarza całość. To oznacza, że skala problemów, na które możemy się natknąć znacząco rośnie w stosunku do zwyczajnej aplikacji telefonicznej lub strony internetowej. Zrozumienie skali jest o tyle ważne, że już na etapie estymacji możemy znacząco niedoszacować czas potrzebny na przetestowanie produktu pod względem funkcjonalnym i systemowym, a co dopiero bezpieczeństwa, a to potrafi zaważyć na końcowej dojrzałości produktu.

Niedoszacowanie generuje listę potencjalnych grzechów, które stały się niechlubnym standardem naszej branży, a które w 90% sprowadzają się do mentalności „zaoszczędzimy trochę czasu i środków finansowych na bezpieczeństwie bo i tak jesteśmy za małym projektem by przyciągnąć włamywaczy”.

Ta pycha to ogromny błąd, objawiający się m.in.:

  • Słabym, łatwym do odgadnięcia, hardcodowanym hasłem, które nie stanowi odrębnego algorytmu ale jest jednorazowym, przypadkowym słowem, które łatwo złamać lub odgadnąć (przykłady podobnych „cięć” poznamy w dalszej części artykułu);
  • Źle zabezpieczoną siecią, która służy za element przesyłania danych. Dane fizyczne zbierane przez sensory często wysyłane są w mało wyrafinowany i profesjonalny sposób – im wydajniejsza sieć tym wzrasta koszt projektu – co analogicznie oznacza oszczędności na chmurze obliczeniowej, brak dodanej autentykacji i autoryzacji, czy mało bezpieczne metody szyfrowania danych. Pamiętajmy: to co jest tanie lub opensourcowe powinno zapalić nam czerwoną lampkę ostrzegawczą dla naszego projektu;
  • Brakiem skutecznego mechanizmu aktualizacji hardware. Oznacza to scenariusz, w którym nie występuje walidacja oprogramowania zaszytego na urządzeniu:
    • spekulujemy nad procentem użytkowników o określonej wersji oprogramowania
    • nie posiadamy dobrej metody FOTA – file-over-the air czyli proces aktualizacji, który znamy z naszych telefonów komórkowych
    • brakuje mechanizmu roll-back – czyli możliwości cofnięcia się do starszej wersji oprogramowania w przypadku zaistnienia problemów z aktualizacją, 
    • czy w końcu brak tu wydajnego sposobu informowania o tym co uległo zmianie (zwykle jest to jedno zdanie dodane w jakimś mało widocznym miejscu, którego użytkownik jest w stanie nie dostrzec).
  • Używaniem przestarzałych komponentów, które na etapie rozpisywania projektu są znacznie opóźnione w stosunku do rynku. Mówimy tu o fizycznych niedoskonałościach, które ułatwiają przejęcie, dostanie się do wnętrza maszyny lub utrudniają dodawanie usprawnień w momencie kiedy przykładowo pamięć jest już niemal pełna. Mało kto zdaje sobie sprawę, że korzystanie z firm 3rd party, których lokalizacje znajdują się m.in. w Azji, nie zawsze świadczy o wysokiej jakości produkowanych komponentów. Pomyśl czy czasem nie warto dopłacić tych kilku centów, które, mimo kosztu i efektu skali, w dłuższej perspektywie sprawią, że będzie można spać spokojnie i nie obawiać się, że dodatkowe opcje dodane w przyszłości obciążą produkt. 

Oczywiście to tylko skromny wycinek problemów, które mogą, i zazwyczaj pojawiają się, w projekcie. Nie możemy zapomnieć o fakcie niedostatecznej ochrony wynikającej z prywatności danych. Tak, RODO w pewien sposób próbowało uformować ramy, w których powinniśmy pracować, ale nie zawsze kwestia tego co zbieramy, jak często i po co, jest uzasadniona projektowo. 

Czy choćby wracająca jak bumerang kwestia nieodpowiedniego zarządzania produkcją. Oznacza to wypuszczanie produktu, który ma zaszyte oprogramowanie, które może wymagać już w dniu premiery poprawek. Ale jak tego dokonamy? Co jeśli użytkownicy nie będą mieli dostępu do internetu? Czy monitorujemy zwroty i reagujemy na zażalenia konsumentów czy staramy się maksymalizować sprzedaż bez długofalowego planu (kolejne wersje, utrzymanie życia produktu w kolejnych latach, poszerzenie gamy współpracujących urządzeń o kolejne generacje)? 

Bezpieczeństwo to sprawa długofalowa

Czy zdajesz sobie sprawę, że twoi klienci mogą nie być tak obyci technologicznie jak ty? Domyślne hasło, które przygotowałeś, często jest ostatecznym, z którego będą korzystać, jeśli to ty nie zadbasz o ich cyfrową higienę. Cyfrowo wykluczeni (wiek, cyfrowy analfabetyzm) nie potrafią czasem zmienić tych ustawień i to na nas spoczywa obowiązek dostosowania i wczucia się w klienta, który nie zna się na nowoczesnych technologiach, a chce poczuć się zadbany i zabezpieczony. Prosty przykład błędnego targetowania i masz gwarancję problemów. Ludzie starsi preferują łatwe, szybkie w instalacji produkty, które raz włączone “działają”. Młodsi nie mają za złe jeśli mogą pobawić się takim rozwiązaniem. Obie grupy liczą, że dostosujesz to rozwiązanie aby było odporne na ataki. I nie mam tu na myśli wyłącznie cyfrowych  ataków lecz poruszam kwestię socjotechnik.

Zdziwiłbyś się jak często niedoszacowanie testów wynika także z braku pokory i zbytniej pewności siebie zespołu. Seniority, dojrzałość wpisana w kontrakt, podobieństwo do poprzednich projektów. Czego tu się obawiać? Przecież te produkty są do siebie podobne, prawda? Takie myślenie to spory błąd, który w połączeniu z niewystarczająco szerokim spojrzeniem może zatopić najlepiej zapowiadające się projekty. Wyobraź sobie, że twój klient chce aby produkt był wodoodporny. Twój zespół tworzył kiedyś zegarki odporne na deszcz. Wyceniają więc projekt szybko i bezproblemowo. Dopiero po czasie okazuje się, że definicja wodoodporności znaczy “określone ciecze którymi możesz zalać produkt”, a nie możliwość pływania z nim lub wystawienia na opad atmosferyczny. Inna skala, inna wycena, inny sposób wytwarzania. 

Nie wspomnę już o myśleniu “tu i teraz” w ramach którego nie zastanawiamy się co dalej po wypuszczeniu produktu w perspektywie najbliższych lat. Czy to będzie część większego ekosystemu? Czy jestem w stanie utrzymać aktualizacje na satysfakcjonującym poziomie? Czy zaplanowałem metodę aktualizowania dla ludzi, którzy 24/7 korzystają z produktu? Jak często chcę je robić i czy uwzględniam różnice wynikające ze stref czasowych? To niby detal, ale czasem proces aktualizacji może obejmować jedynie dedykowaną aplikację, a czasem i aplikację i urządzenie. Przygotowałeś na tę ewentualność odpowiednie ścieżki testów? Warto o tym pomyśleć zanim “zbrickujesz” komuś urządzenie (z braku aktualizacji doprowadzisz je do momentu, gdzie całkiem przestanie działać). A takie sytuacje nie są rzadkością.

Jak oni to robią?

Ulubionym tematem do pomijania dla osób zarządzających jest kwestia włamań. Często właściciela projektu nie interesuje jak robią to zawodowcy, ponieważ wychodzi on z założenia, że przecież “jesteśmy za małą firmą, by kogoś zainteresować”. A prawda jest taka, że w większości przypadków swoją ignorancją odwalasz za włamywaczy co najmniej połowę roboty.

Zebranie informacji w sieci (rekonesans) jest w dzisiejszych czasach niedorzecznie proste. Czasem są to pytania zadane przez twoich ludzi na stackoverflow (znanym na całym świecie forum dla programistów). Czasem jest to zdobycie i analiza firmware, który zazwyczaj i tak jest już wrzucony w sieć przez samych dostawców. Czasem zapomnisz o obfuskacji (zatajeniu kodu źródłowego) produktu i gwarantuję ci, że stosując Reverse mobile app lub Sniff OTA mechanism jesteś w stanie wyczytać ciekawe rzeczy na swój temat.

Kwestia testowania zabezpieczeń obrosła legendami. Szczególnie takimi, że musi być to trudne i kosztowne, a przecież to wcale nie jest prawda.

  • Chcesz rozpakować istniejące elementy na poszczególne czynniki pierwsze? Zastosuj Binwalk lub Radare
  • Pragniesz emulować istniejące oprogramowania na komputerze? Wykorzystaj do tego firmware analysis toolkit lub attifyOS VM
  • Dynamiczna analiza celem znalezienia luki/otwarcia produktu? Dystrybutor twoich tanich podzespołów samodzielnie dostarcza dokumentację, która znajduje się w sieci gotowa do skorzystania.
  • A może kwestia analizy radiowej i sprawdzenia co ty wysyłasz? Spektrum gotowych rozwiązań powala: RTL-SDR, USRP, GNURADIO/GQRX

Nie ufaj osobom, które twierdzą, że wam atak się nie przydarzy. Szukanie dziury w całym i wiercenie w projekcie, niczym w ubytku zęba, jest dla niektórych przyjemnością i z roku na rok staje się prostsze. Jeśli nadal mi nie wierzysz to sugeruję podejść w domu do stojącego na stole routera, przeczytać numer obok znaku FCC i wpisać go na stronie fcc.io. Spójrz co się wydarzy. Jak masz dwie chwile – wykonaj podobny test na stronie shodan.io. Wróć potem do lektury i zainteresuj się tym, co na temat twojego projektu mogą wiedzieć inni.

Inwestując świadomie w testy sprawiasz, że projekt jest mniej podatny na nieszczelności. Wykupując np. BlackDuck szybko i automatycznie sprawdzisz z jakich licencji korzystasz w swoim projekcie. Dzięki znajomości w/w programów możesz względnie tanio sprawdzić czy produkt który tworzycie jest w ogóle w jakikolwiek sposób gotowy do wyjścia na rynek. Funkcjonalność to nie jest wszystko!

Nadal jest Ci do śmiechu? Uwierz mi, że też mi było do momentu gdy kilka tygodni po premierze naszego produktu (opaska + dedykowana aplikacja) na rynku rosyjskim pojawiła się identycznie wyglądając aplikacja, a my zostaliśmy uznani za szpiegów. Jeden raz nie dopilnowaliśmy obfuskacji. Jeden raz pomyliliśmy wersję apki (inna na rynek azjatycki, inna na resztę świata). To wystarczyło. 

Klient nie myśli

Za dużo informacji, za dużo stymulantów, za dużo zmysłów. Information overload stało się faktem więc nie licz na to, że możesz coś przemycić bokiem licząc, że klient zapewne zrozumie albo zastosuje się. Klient nie myśli. Włącza produkt bez czytania instrukcji i ma działać. W innym przypadku zacznie się polowanie na czarownice.

Podam Ci kilka przykładów, jak firmy próbowały oszczędzić na aspekcie testowania:

  • Pewna smart lalka została zakazana na świecie – uznano ją za proste narzędzie do inwigilacji. Czytając protokół z rozprawy sądowej dowiedziałbyś się np. że developerzy zakodowali jej pytania pokroju “jak się nazywa twój tatuś, gdzie żyjesz, gdzie chodzisz do szkoły, mój ulubiony posiłek to”, które zbierały te dane dla celów? No właśnie. Nikt nie wiedział jakich ale je zbierano. Polityka prywatności wspominała o tym, że może “od czasu do czasu ulec zmianie więc ilekroć wyślesz nam swoje dane dobrze jest sprawdzić czy coś się nie zmieniło w międzyczasie”. Czy sprawdzasz politykę prywatności w przypadku swojego telefonu i usług Google? No właśnie. Co więcej zabezpieczenie dla dzieci i przed wejściem w aplikację sprowadzało się do jednego, uniwersalnego rozwiązania równania (11+16 wynosi?). Producent uznał, że jest to doskonałe rozwiązanie, a na pewno tańsze niż zaawansowane metody szyfrowania. No i ostatnia kwestia – dystrybutor stwierdził, że jeśli poprosisz o skasowanie swoich danych to “nie mamy takiego mechanizmu niemniej postaramy się zrobić wszystko co w naszej mocy aby chociaż spróbować spełnić twoją prośbę”. Pozostawię to bez komentarza;
  • Istnieją smart zabawki, do których przez niezaszyfrowanie pasma nadawania (bo i po co to testować?)można łatwo włamać się i podmienić komunikat przekazywany przez zabawkę. Mowa o przypadkach, gdzie zabawki mówią dziecku np. żeby się zabiło. W przypadku takich niedoróbek prokuratora jest bezlitosna, nawet jeśli twórcy uznali, że “oni wiedzą lepiej”;
  • Popularne opaski dla biegaczy mają zapisane w swej polityce prywatności “nie sprzedajemy twoich danych żadnej firmie”, ale już zdanie dalej “pakiet danych (informacja z twoimi mailami), zdrowie (z twoimi danymi medycznymi), lokalizacja (z twoimi danymi GPS), zachowanie (z twoim profilem konsumenta) już tak”. Szara strefa potrafi zatem wkraść się w różne obszary.

Oczywiście skala problemu jest dużo większa ale wszystkich tych przypadków dałoby się uniknąć, gdyby tylko skupiono się na testach. Z dziennikarskiego obowiązku przypomnę jedynie, że na początku tego roku zakończyła się słynna sprawa w Middletown, w ramach której zastanawiano się czy można używać danych do konkretnych celów sądowych. Okazuje się, że można, co oznacza, że wkraczamy w czasy, w których twoje smart urządzenie może zostać prześwietlone przez organy ścigania jeśli uznają, że zebrane dane mogą pomóc w sprawie. Pomyśl zatem o tym jakie dane są magazynowane i w jakim celu bo wkrótce kto inny może zadać Ci takie pytanie.

Co dalej?

Podstawowa kwestia to nieoszczędzanie na testowaniu i traktowanie go dużo poważniej niż pobieżne sprawdzenie funkcjonalności. Jeśli zapoznasz się z oficjalnym dokumentem “Recommendation for IoT Device manufacturers: foundational activities and core device cybersecurity capability baseline” dowiesz się dokładnie, punkt po punkcie, na co zwrócić uwagę i co jest potrzebne (checklista) aby wykonać dobre testy produktu IoT.

Najczęstsze “braki” dotyczą trzech pomijanych obszarów:

  • Identyfikacji potencjalnych konsumentów – stworzenia szczegółowych profili kim są, jak się zachowują, w jakim celu będą wykorzystywać gotowe oprogramowanie oraz produkt. Czy są tech-savvy czy może nie chcą nic zmieniać kiedy raz włączą produkt? Czy są gotowi do śledzenia nowości na rynku? Czy komunikaty przekazywane w trakcie instalacji są uniwersalne?
  • Potencjalnych zagrożeń wynikających z profilu użytkowników korzystających z produktów. Czasem ponowne zdefiniowanie klienta pomaga odkryć interesujące cyberniebezpieczeństwa. 
  • Sposobu, w jaki producent informuje użytkownika, że mogą pojawić się problemy. Jak wygląda to w twoim przypadku. I  w jaki sposób wesprzesz użytkownika, gdy problem się już pojawi – czy masz przygotowany plan alternatywny na wypadek gdy wyciekną dane, gdy urządzenie zostanie złamane, gdy ktoś zacznie robić Ci czarny PR? Jak poinformujesz użytkowników o tym, że doszło do ataku? Jak powiesz im, że należy zaktualizować produkt i jakie kroki podjąłeś?

Myślisz, że Ciebie to nie dotyczy? Sądzisz, że jesteś bezpieczny bo jesteś z Polski, a oficjalnie o współpracy z klientem wiesz tylko ty i on? Jesteś w błędzie i to gigantycznym.

Wyobraź sobie jakie było moje zdziwienie gdy w zeszłym tygodniu otrzymałem poniższy komunikat:

W dniu X, spółka Y prowadząca aptekę internetową XYZ padła ofiarą ataku hakerskiego na swoje serwery w zakresie, który umożliwiał dostęp do następujących danych: nazwa podmiotu, adres podmiotu, NIP podmiotu, REGON podmiotu, Pesel, imię i nazwisko osób kontaktowych, numer telefonu, adres e-mail oraz informacje nt. transakcji.

Nie pobieraliśmy i nie archiwizowaliśmy nr kont bankowych i kart kredytowych i takowe nie znajdowały się w bazach danych osobowych, a co za tym idzie nie zostały skradzione.

Spółka cały czas bada, czy pozostałe dane nie zostały zaatakowane. Spółka podejmuje wszelkie starania mające na celu zminimalizowanie skutków zdarzenia (zawiadomił organy ścigania oraz poinformowano UODO) i ryzyka wystąpienia podobnych zdarzeń w przyszłości, jak też przywrócenia normalnego funkcjonowania przedsiębiorstwa, w tym możliwości realizacji zamówień.

Najzabawniejsze, że sekcja dotycząca środków podjętych w celu zaradzenia naruszeniu ochrony danych osobowych składała się z takich kwiatków jak:

  • dostęp do każdego z naszych programów jest zabezpieczony silnym hasłem,
  • w Spółce stosowany jest firewall,
  • wdrożono system blokad połączeń z adresów IP występujących na czarnych listach TOR i Banned IP,
  • wdrożono połączenia szyfrowane VPN dla zaplecza aplikacji
  • kopia zapasowa danych wykonywana jest codziennie,
  • naruszenie ochrony danych zgłosiliśmy Prezesowi UODO,

Oczywiście potem nastąpiła długa terada, żeby nie klikać w nic co do nas trafi, nie odbierać SMSów, nie akceptować maili i załączników, a najlepiej na własny koszt założyć na BIK konto i sprawdzić czy już ktoś nie bierze na mnie kredytu. Myślisz, że wrócę do tej apteki kiedykolwiek w przyszłości? Absolutnie nigdy. Nie interesuje mnie co mają na swoich komputerach. Stracili moje zaufanie i nie chce mieć z nimi nic wspólnego. 

Teraz w równaniu IoT, oprócz strony i danych, dołóż produkt, aplikację i chmurę i masz kompletnie inną skalę i perspektywę problemu, z którym musisz się liczyć.

Jeśli wierzyć raportom pokroju “Consumer Attitude Toward IoT Security” wydanym przez firmę Karamba Security, w którym pytano użytkowników o kwestie bezpieczeństwa IoT:

  • Czy oczekujesz, że twoje urządzenia IoT będą zabezpieczone przez producenta? 74% odpowiedziało tak;
  • Czy uznajesz urządzenie za bezpiecznie mimo, że potrzebuje ono aktualizacji? 42% stwierdziło, że nie;
  • Czy sądzisz, że odpowiedzialność za włamania spoczywa na twórcy i że to on ma dopilnować, aby produkt był bezpieczny? 87% bez wahania odpowiedziało tak.

Innymi słowy to na tobie polega odpowiedzialność i to ty będziesz miał problem w przypadku gdy nie dopilnujesz tego zagadnienia lub uznasz, że można “oszczędzić” w kilku miejscach. Co więcej, nawet jak zaktualizujesz swój produkt po ataku, dla połowy klientów przestaniesz się liczyć. Pomyśl o tym.

Co przyniesie jutro?

Debata na temat bezpieczeństwa jest ważna z jeszcze jednego powodu. Obecnie trwają wzmożone dyskusje (na arenie międzynarodowej), aby w przyszłości tworzyć i dostarczać specjalne naklejki umieszczane na produktach IoT, mówiące m.in. o tym:

  • Jaki jest mechanizm zabezpieczenia, do kiedy będzie on wspierany, czy jest to tryb automatyczny czy ręczny, jaki jest mechanizm kontroli (hasło, możliwość zmiany przez użytkownika, czy może współistnieć wiele kont) etc.;
  • Jakie dane są zbierane (wizualne, audio, fizyczne, lokalizacyjne) oraz w jaki sposób tj. kamera lub mikrofon, w jakim celu (lepsza kalibracja urządzenia), czy dane na urządzeniu są zaszyfrowane, czy dane są wysyłane do chmury i możesz je skasować po czasie, z kim dzielimy się twoimi danymi, czy są w jakiś sposób sprzedawane;
  • Gdzie może przeczytać aktualną politykę prywatności i kiedy ona powstała po raz pierwszy.
  • Jak również QR kod “Więcej instrukcji” dotyczący skasowania danych, informacji o użytkowniku, a wszystko to w prostej postaci piktogramów i w myśl zasady contract by design.

Innymi słowy kwestia bezpieczeństwa staje się coraz mniej abstrakcyjnym pojęciem, a raczej ważnym tematem, który należy śledzić i na bieżąco reagować. Pamiętaj, że zaufanie jest trudne do zdefiniowania, ale wiemy kiedy je tracimy. Konsument nie chce półproduktu. Nie chce czuć się oszukany. IoT jest już i tak dostatecznie skomplikowane. Zadbajmy zatem o jego bezpieczeństwo za sprawą skutecznych testów. 

Rate the article:


16.10.2020