Cyberbezpieczeństwo w systemach wbudowanych – budowa cyfrowej fortecy

UDOSTĘPNIJ

Autor: Piotr Strzałkowski, ekspert w dziedzinie embedded

Co wspólnego mają ze sobą forteca i bezpieczeństwo systemów? W jaki sposób działają systemy zabezpieczeń i dlaczego ich rola jest kluczowa? Dlaczego przy wyborze podwykonawcy, warto wziąć pod uwagę kwestie jakości kodu w bibliotekach/modułach przez niego dostarczanych? Chcąc odpowiedzieć na te pytania, omówimy temat cybersecurity (cyberbezpieczeństwa) w systemach wbudowanych (embedded systems). Na końcu znajdziesz kilka przydatnych porad i trików, które sprawdziły się nam w jednym z projektów dla branży motoryzacyjnej.

digital_fortress

Twierdza trudna do zdobycia 

Systemy zabezpieczeń towarzyszą człowiekowi od zawsze. Ludzie wznosili fortece, aby chronić to, co dla nich cenne i ważne: skarby, broń, ale przede wszystkim – ludzkie życie. 

Koncepcja ochrony wartościowych informacji, skarbów czy kontroli dostępu do wybranych obszarów (lub ziem) sięga początków ludzkości. Przykładowo, w średniowieczu, budowle zwane fortecami służyły do ochrony ziem i miejsc o znaczeniu strategicznym. Zaprojektowanie i zbudowanie takiej konstrukcji jest jednak niezwykle trudnym zadaniem. 

Należy bowiem pamiętać o dostosowaniu budowy do otaczającego środowiska i swoich aktualnych możliwości. Musisz wziąć pod uwagę: 

  1. Materiał, którego używasz. 
  2. Kształt i rozmiar konstrukcji. 
  3. Wielkość elementów obronnych. 
  4. Wielkość i ilość elementów ofensywnych. 

System wbudowany jest jak twierdza

Zbudowanie twierdzy to nie taka łatwa sprawa. Dla lepszego zrozumienia tematu przypomnijmy sobie, jak wyglądały średniowieczne twierdze oraz w jaki sposób były budowane. Najczęściej w tego typu budowlach występowały stałe elementy: 

  • fosa otaczająca twierdzę, 
  • most zwodzony, po którym mieszkańcy mogą wejść do twierdzy, 
  • bramy obronne dodatkowo chroniące wybrane fragmenty twierdzy, 
  • mury obronne, które otaczają i chronią twierdzę, 
  • wieże obronne, w których stacjonują np. łucznicy, 
  • barbakan – czyli specjalna konstrukcja chroniąca most zwodzony przed atakami. 

Wszystkie te elementy są kluczowe i pełnią określoną rolę w systemie obronnym. Brak jednego z nich znacznie zmniejsza możliwości defensywne konstrukcji. Z oprogramowaniem jest podobnie – jeśli ma być odporne na ataki hakerów nie możesz zapomnieć o zabezpieczeniach. W systemach wbudowanych jest to szczególnie istotne.

Co, jeśli to Ty masz zbudować cyfrową twierdzę? 

Dobrym punktem wyjścia jest wybudowanie fosy, która powinna być możliwie najgłębsza i najszersza, tak aby przejście przez nią bez użycia mostu zwodzonego było niemożliwe lub przynajmniej bardzo trudne. Brzmi sensownie, prawda? 

Niemniej jednak, jak zwykle – diabeł tkwi w szczegółach. Szerokość fosy powinna być dopasowana do możliwości naszej armii, np. do zasięgu łuczników lub machin wojennych, tak, aby móc zaatakować wroga zza murów obronnych.

Dlaczego fosa jest tak ważna?  

Ponieważ to nasza pierwsza linia obrony przed bezpośrednim atakiem. Dzięki niej, atakujący twierdzę wróg nie będzie miał łatwego dostępu do murów obronnych i bram. Musiałby użyć wyszukanych maszyn wojennych, aby dostać się do nich lub je zniszczyć. Jeśli sforsował mury i bramy, łatwiej byłoby mu przeprowadzić różnego rodzaju ataki na fortecę. 

Wyobraź sobie teraz, że ta mała wyspa z częścią murów obronnych, na której zamierzamy zbudować naszą fortecę, jest w rzeczywistości naszym sprzętem (HW) na przykład mikrokontrolerem, w którym w przyszłości osadzimy oprogramowanie (firmware).

Teraz już wiesz, dlaczego tematy HW są tak ważne. Oto kilka kluczowych elementów sprzętowych, o których nigdy nie wolno zapominać: 

  • Upewnij się, czy bity zabezpieczające odczyt pamięci flash są prawidłowo ustawione,
    Ten punkt może wydać się banalny, ale bardzo często popełniamy błędy w tej kwestii. Przykładem może być sytuacja, gdy ktoś zapomniał obsłużyć nowe rejestry odpowiedzialne za zabezpieczenie odczytu pamięci flash w mikrokontrolerze, gdy zmieniono go na taki sam z serii, jednak z większą pamięcią flash.
  • Sprawdź, czy mikrokontroler wymagał warstwy antysabotażowej (tamper protection) dla Twojego projektu,
    Warstwa antysabotażowa (tamper protection) w mikrokontrolerze lub w zabezpieczonych elementach nie jest kuloodporna i są sposoby na pozbycie się jej. Istnieją również różne rodzaje warstw anty-integracyjnych – prostych i trudniejszych do ominięcia. Warto podjąć mądrą decyzję, który mikrokontroler wybrać i z jakim rodzajem warstwy. 
  • Upewnij się, czy mikrokontroler posiada wysokiej jakości RNG (generator liczb losowych) i czy działa poprawnie np. w momentach jak np. po włączeniu zasilania czy zresetowaniu,
    Historia pokazuje, że takie komponenty sprzętowe (HW) miewają wady wewnętrzne, więc testowanie ich jest mądrym posunięciem. 
  • Przeczytaj erratę mikrokontrolera z punktu widzenia cyberbezpieczeństwa – sprawdzaj błędy w modułach bezpieczeństwa i wszystkie zdarzenia, które mogą powodować resetowanie wyjątków itd.
    Posiadanie nieobsługiwanych wyjątków lub innych mechanizmów resetowania w systemie może być potencjalną podatnością na atak. 

Interfejsy SW/HW 

Po wybudowaniu fosy i części murów obronnych konieczne jest stworzenie mostów zwodzonych i bram. To kolejne części twierdzy, które wymagają szczególnej uwagi, gdyż cały ruch wchodzący i wychodzący przechodzi właśnie przez nie. Z punktu widzenia przepustowości, drogi te powinny być jak najszersze i pozbawione przeszkód, jak np. kraty. Innym sposobem na utrzymanie płynnego przepływu jest zbudowanie jak największej ilości bram. 

Ponownie jednak diabeł tkwi w szczegółach. Jeśli bramy i mosty zwodzone są zbyt szerokie i niewystarczająco zabezpieczone, stanowią wielką pokusę dla wrogów. Nietrudno jest zaatakować bramy, które nie są chronione lub są tak szerokie, że niemożliwym jest kontrolowanie całego ruchu. Dlatego warto uwzględnić budowę takich konstrukcji jak barbakany i kraty, które pomogą chronić mosty zwodzone i bramy twierdzy. Przekładając to na świat cyberbezpieczeństwa: każdy niechroniony interfejs systemu wręcz sam prosi się o kłopoty. Naszym celem jest redukcja powierzchni ataku, a nie nadmierne jej rozszerzanie.

Podsumowując – nigdy nie zapominaj o: 

  • dezaktywowaniu swojego interfejsu programowania np: JTAG, 
  • jeśli to możliwe, uruchomieniu mechanizmów ochronnych dla wszystkich interfejsów sprzętowych, 
  • obsłudze wszystkich możliwych wyjątków, 
  • skoncentrowaniu się głównie na testowaniu części kodu odpowiedzialnych za obsługę interfejsów takich jak: kolejki, bufory kołowe, DMA, algorytmy kopiowania danych, algorytmy sprawdzania nagłówków, CRC. 

Jeśli masz wątpliwości, która część kodu powinna być najdogłębniej zweryfikowana, zawsze dokładnie przetestuj kod najbardziej narażony na środowisko zewnętrzne (np. obsługujący bezpośrednio ramki).  

Takie działania redukują powierzchnię ataku w poszczególnych częściach systemu. 

Współpraca z zewnętrznymi wykonawcami 

Zbudowanie tak wielkiej budowli, jaką jest forteca, nie jest możliwe dla jednej osoby. Dla osiągnięcia celu we właściwym czasie potrzebna jest pomoc z zewnątrz i jest to całkowicie normalne. Musisz jednak wziąć pod uwagę pewną ważną kwestię. 

Bez względu na to, jak duża i sławna jest firma, z którą współpracujesz, lub jak bardzo lubisz ludzi, którzy tam pracują, jeśli powiedzą Ci, że ich praca jest najwyższej jakości i że wszystkie wymagane testy zostały przeprowadzone wewnętrznie – nie wierz im. 

Ostatecznie, to Ty bierzesz odpowiedzialność za rozwiązanie. Cały dostarczony kod powinien zostać przetestowany przez nich lub przez Ciebie. Jeśli Twój partner przeprowadził testy, powinieneś uzyskać dostęp do wyników w celu ich weryfikacji i upewnienia się, że zostały wykonane zgodnie z Twoimi wymaganiami i w ustalonym zakresie. Nie akceptuj odpowiedzi, że wyniki testów są poufne. 

Pamiętaj, że brak testów lub pewne braki w testach nie są wynikiem złych intencji dostawcy. Temat cyberbezpieczeństwa jest w branży motoryzacyjnej dość nowy. Na razie niewiele firm właściwie radzi sobie z tym tematem. Ponadto są jeszcze inne czynniki, takie jak deadline’y i błędy ludzkie. Oczywiście, jeśli Twój partner kieruje się własnymi metodami i z jakichś powodów nie dostarcza wyników testów, to koniec końców należy przeprowadzić je we własnym zakresie. 

Warto zapamiętać: 

  • jeśli zauważysz, że Twój dostawca nie jest biegły w temacie cyberbezpieczeństwa, pomóż mu, a oboje na tym skorzystacie, 
  • wyraź swoje wątpliwości, gdy usłyszysz, że dostarczona praca jest doskonała, 
  • przeznacz odpowiednią ilość czasu na weryfikację dostarczonego kodu lub wyników testów lub na wykonanie ich we własnym zakresie – zazwyczaj jeden lub dwa tygodnie nie wystarczą, 
  • poproś właściwą osobę o umieszczenie w umowie o współpracy paragrafu o dostarczeniu testów cyberbezpieczeństwa do stworzonego kodu,
  • wady mogą pojawić się na poziomie integracji, nie tylko w dostarczonych komponentach SW/HW, 
  • przyjemność zgłoszenia błędu leży po Twojej stronie. 

Dlaczego nadzór HW i SW po wdrożeniu jest tak istotny? 

Kiedy już twierdza jest już gotowa, to wtedy zaczyna się prawdziwa przygoda. To moment, w którym założenia i wykonana praca zderzają się z realnymi zagrożeniami. Należy upewnić się, że nasze zasoby są gotowe do starcia z hakerem. Zupełnie jak w wojsku – musimy szkolić rycerzy, zbieramy potrzebną zbroję i broń, aby utrzymać stabilną ochronę twierdzy i to na wymaganym poziomie.

Musimy przygotować procedury działania, serwery, oprogramowanie, sprzęt i narzędzia. Następnie stale poszerzamy naszą wiedzę o możliwe nowe zagrożenia. Przeważnie, ta część projektu jest słabo opłacana i brakuje zasobów, takich jak ludzie, umiejętności i czas. Kiedy już pojawi się prawdziwa podatność, która może zostać wykorzystana, zdecydowanie nie jest to odpowiedni moment, aby: 

  • tworzyć procedury, które opisują co i przez kogo powinno być zrobione, 
  • wyszukiwać właściwe repozytoria kodu z całymi narzędziami do tworzenia i testowania, 
  • przeszukiwać dokumentację poziomów ASIL, interfejsów, list mechanizmów zabezpieczających i list dostawców lub sprawdzać, która część kodu jest open source, 
  • przeglądać bazy danych CVE, aby znaleźć zapomnianą lukę. 

Dlatego zawsze należy pamiętać o tym, by:  

  • okresowo przeglądać bazy CVE, 
  • przygotować wymagane procedury z wyprzedzeniem, 
  • zawczasu wyposażyć się w wymagane narzędzia SW/HW, 
  • przygotować informacje o użytych narzędziach i kodzie do każdego projektu, 
  • przeprowadzać audyty i symulacje sytuacji krytycznych. 

Podsumowanie 

Pamiętajmy, że historia pokazuje, że tylko kilka twierdz nigdy nie zostało zdobytych. 

Te, którym udało się przetrwać, miały: 

  • czasem odrobinę szczęścia, 
  • doskonałą lokalizację, 
  • były na bieżąco modernizowane. 

Ale czy warto liczyć na łut szczęścia? 

Mam nadzieję, że ten artykuł pomógł znaleźć Ci odpowiedź na pytanie jak zbudować własną cyfrową twierdzę. 

Piotr Strzałkowski, autor tego artykułu, jest ekspertem w dziedzinie embedded i pracuje w Solwicie od ponad 10 lat. Pracował przy wielu projektach dla klientów z różnych branż, ale najlepiej czuje się w systemach dla branży motoryzacyjnej. Ekspert w zakresie wdrażania rozwiązań cybersecurity w oprogramowaniu wbudowanym. Siła zespołu odpowiedzialnego za wdrażanie rozwiązań IoT.

 
Poszukujesz partnera technologicznego do wdrożenia cybersecurity do Twojego oprogramowania? Piotr z zespołem chętnie doradzą, jak powinien przebiegać proces i wesprą w jego wdrożeniu. Skontaktuj się z nami i zbuduj z nami swoje oprogramowanie embedded.

Najnowsze wpisy na blogu