Wprowadzenie do testów penetracyjnych w systemach wbudowanych

Systemy wbudowane są wszędzie. To stwierdzenie w obecnym, globalnie połączonym świecie jest jak najbardziej prawdziwe. Każdego dnia, mniej lub bardziej świadomie, korzystamy z co najmniej kilkudziesięciu różnego rodzaju systemów wbudowanych, które wspierają nas w aktywnościach i wpływają na jakość oraz wydajność naszego życia.

Obecnie jednym z największym wyzwań jest zapewnienie odpowiedniego poziomu bezpieczeństwa i ochrony przed cyberzagrożeniami, które mogą negatywnie wpłynąć na działanie różnych systemów wbudowanych. Poza implementacją funkcji istotnych z punktu widzenia bezpieczeństwa (ang. security), bardzo istotne jest odpowiednie przetestowanie zaimplementowanych algorytmów i mechanizmów ochronnych.

Z punktu widzenia bezpieczeństwa klasyczne podejście do testowania często jest niewystarczające. W tym celu bardzo pomocna jest technika zwana testami penetracyjnymi. Odpowiednio wdrożona, może przynieść bardzo dużą wartość naszym urządzeniom, a także wpłynąć pozytywnie na oferowany przez nie poziom bezpieczeństwa.

Definicja i historia testów penetracyjnych

Koncepcja testów penetracyjnych dla urządzeń wbudowanych została stworzona, aby odpowiednio zaadresować problemy, zagrożenia i wyzwania wynikające z szybkiego wzrostu liczby urządzeń połączonych do sieci internetowej. Zdefiniowane zostały nowe, złożone zagrożenia dotyczące bezpieczeństwa, których nie można było odpowiednio rozwiązać poprzez tradycyjne podejście do testowania.

Historia testów penetracyjnych sięga lat 60. i 70. XX-wieku. Technologia rozwija się w bardzo szybkim tempie, ale niestety nie zawsze w oczekiwanym przez nas kierunku. Era szybkiego rozwoju Internetu, która, w zależności od kraju i rejonu świata, rozpoczęła się już pod koniec lat 90. i trwa do dzisiaj wymusiła opracowanie technik testów penetracyjnych w celu zweryfikowania, czy nasze urządzenia są odpowiednio przygotowane do wyzwań, jakie niesie ze sobą rozwój i popularyzacja technologii.

Testy penetracyjne możemy zdefiniować jako proces oceny bezpieczeństwa skupiający się na identyfikacji luk i słabości w urządzeniach wbudowanych. Chodzi o aktywne poszukiwanie sposobów na złamanie zabezpieczeń urządzeń istotnych pod kątem bezpieczeństwa. Głównym celem jest zapewnienie i sprawdzenie, że urządzenia są odporne na nieautoryzowany dostęp do danych, algorytmów, ustawień i innych zasobów z punktu widzenia użytkownika oraz urządzenia.

Podejście do testów penetracyjnych

Wybór odpowiedniego podejścia do testów penetracyjnych jest kluczowy dla efektywności i wartości całego procesu oceny bezpieczeństwa. Określa on poziom wiedzy testera o badanym systemie, co bezpośrednio wpływa na zakres, głębokość i realizm symulowanego ataku.

W zależności od celów organizacji, dostępnych zasobów oraz specyfiki testowanego środowiska, można wyróżnić trzy główne strategie:

• Black Box (Czarna skrzynka) – w tym podejściu tester penetracyjny ma zerową lub bardzo ograniczoną wiedzę na temat wewnętrznej struktury, architektury, kodu źródłowego czy infrastruktury testowanego systemu. Działa podobnie jak rzeczywisty zewnętrzny atakujący, który nie posiada żadnych wcześniejszych informacji o celu.
• Grey Box (Szara skrzynka) – w tym podejściu tester penetracyjny ma ograniczoną wiedzę na temat wewnętrznej struktury systemu. Zazwyczaj ma dostęp do części dokumentacji, posiada wiedzę na temat niektórych zabezpieczeń i algorytmów istotnych z punktu widzenia zabezpieczeń systemu.
• White Box (Biała skrzynka) – w tym podejściu tester penetracyjny ma pełną wiedzę na temat wewnętrznej struktury systemu, w tym dostępu do kodu źródłowego, schematów architektury, dokumentacji projektowej, a często także uprawnień administracyjnych do testowanego środowiska.

Każde z nich będzie pozwalało na wykrycie innych słabości, luk i zagrożeń. Liczba znajdowanych zagrożeń będzie różna w zależności od podejścia. Najwięcej zagrożeń i podatności będziemy wykrywać w podejściu białej skrzynki. Ale nie jest tak, że powinniśmy stosować tylko tę opcję. W celu maksymalizacji wykrywania różnych podatności powinniśmy w projektach implementować wszystkie trzy w zależności od celów, jakie chcemy osiągnąć.

Niestety, nie ma prostej odpowiedzi, ile czasu i wysiłku powinniśmy spędzić w każdej z kategorii. W ramach zdobywania doświadczenia będziemy w stanie lepiej definiować czas, zakres i wysiłek.

Komponenty podlegające testowaniu

Systemy wbudowane, z ich złożoną architekturą obejmującą zarówno sprzęt, oprogramowanie niskopoziomowe, jak i różnego rodzaju interfejsy komunikacyjne, są szczególnie zagrożone, gdyż powierzchnia ataku rozciąga się na wiele wzajemnie połączonych elementów. Skuteczna ocena bezpieczeństwa wymaga więc holistycznego podejścia, które systematycznie analizuje każdy z kluczowych komponentów – od fizycznej budowy urządzenia, poprzez oprogramowanie i protokoły komunikacyjne, aż po potencjalne integracje z usługami chmurowymi.

Testowanie sprzętu jest równie istotne jak oprogramowanie. Nie możemy zakładać, że dostęp do sprzętu jest chroniony i w związku z tym nie ma konieczności jego testowania.

W przypadku testowania sprzętu powinniśmy się skupić na:

• Magistralach komunikacyjnych przewodowych i bezprzewodowych, które będą stanowić naturalne punkty wejściowe do systemu.
• Procesorach (MCU/CPU), a także na wszystkich układach scalonych, które mogą być odpowiedzialne za wykonywanie zaprogramowanej logiki.
• Pamięciach nieulotnych (flash, EEPROM), które będą odpowiedzialne za gromadzenie różnego rodzaju danych jak: dane istotne z punktu widzenia użytkownika, nastawy algorytmów, informacje diagnostyczne.
• Różnego rodzaju czujnikach, które mogą mieć bezpośredni wpływ na zmianę logiki działania urządzenia.
• Układach związanych z zasilaniem.
• Zewnętrznych komponentach, które wchodzą w skład całego ekosystemu.

W przypadku testowania oprogramowania powinniśmy się skupić na:

• Procesie instalacji, uruchamiania, aktualizacji oprogramowania.
• Procesie produkcji, utrzymywania, serwisowania oprogramowania.
• Bibliotekach wykorzystywanych do zapewnienia odpowiedniego poziomu bezpieczeństwa.
• Wszystkich innych modułach programowych, które odpowiedzialne są za gromadzenie danych i wykonywanie logiki istotnej z punktu widzenia bezpieczeństwa.

Tradycyjne podejście do testowania a testy penetracyjne

Ocena jakości i funkcjonalności systemów informatycznych jest nieodłącznym elementem cyklu życia oprogramowania. Tradycyjne podejście to oprogramowania skupia się na weryfikacji zgodności z wymaganiami, stabilności działania oraz poprawności implementacji. Testy penetracyjne aktywnie poszukują słabych punktów i podatności, które mogłyby zostać wykorzystane przez potencjalnych atakujących.

Tradycyjne podejście do testowania:

• Sprawdza zaprogramowaną funkcjonalność i oferowaną jakość.
• Sprawdza, czy system działa zgodnie z przeznaczeniem i w sposób, w jaki został zaprojektowany.
• Testy są wykonywane z perspektywy użytkownika końcowego.
• Testowanie wykrywa usterki funkcjonalne i problemy z wydajnością.
• Potwierdza, że system działa tak jak powinien.

Z kolei testy penetracyjne:

• Identyfikują słabości, potencjalne ścieżki ataku w poszukiwaniu luk w zabezpieczeniach.
• Sprawdzają system z perspektywy napastnika w celu identyfikacji luk i zagrożeń.
• Weryfikują, czy zabezpieczenia mogą zostać złamane.
• Poszukują potencjalnych ścieżek ataku.
• Sprawdzają, czy system można zmusić do zrobienia czegoś, czego nie powinien.

Dlaczego potrzebujemy testów penetracyjnych

Testy penetracyjne stają się niezbędnym elementem procesu tworzenia oprogramowania, przynosząc wymierne korzyści biznesowe i techniczne.

Powody, dla których potrzebujemy testów penetracyjnych, zostały przedstawione poniżej:

• Zgodność z regulacjami – w kontekście regulacji prawnych obecnie możemy mówić o rewolucji. Wiele krajów pracuje nad opracowaniem restrykcyjnych regulacji i standardów, które będą musiały być spełnione przez urządzenia. Dobrym przykładem jest tutaj Cyber Resilience Act (CRA), który zacznie obowiązywać w Unii Europejskiej za około dwa lata. Z kolei niektóre kraje wdrożyły już pierwsze restrykcyjne regulacje takie jak: US Cyber Trust Mark czy UK PSTI.
• Identyfikacja podatności – podstawowym celem testów penetracyjnych jest wykrycie luk i słabości w zabezpieczeniach systemu, zanim zrobią to cyberprzestępcy.
• Zarządzanie i redukcja ryzykami – każda niewykryta podatność stanowi potencjalne ryzyko dla organizacji począwszy od strat finansowych, przez utratę reputacji, aż po zagrożenie dla zdrowia i życia ludzi. Testy penetracyjne pozwalają na świadome zarządzanie tym ryzykiem. Dzięki nim organizacja zyskuje realny obraz poziomu swojego bezpieczeństwa i może podjąć adekwatne kroki w celu jego poprawy, alokując zasoby tam, gdzie są one najbardziej potrzebne.
• Ochrona wrażliwych danych – systemy wbudowane coraz częściej przetwarzają i przechowują dane wrażliwe, istotne dla użytkowników oraz algorytmów związanych z działaniem urządzenia. Wyciek takich danych może prowadzić do poważnych konsekwencji prawnych i finansowych. Testy penetracyjne weryfikują skuteczność mechanizmów ochrony danych, takich jak szyfrowanie czy kontrola dostępu, minimalizując ryzyko ich wycieku.
• Walidacja zaimplementowanych mechanizmów – zaimplementowane różnego rodzaju funkcje oraz algorytmy istotne dla bezpieczeństwa wymagają weryfikacji i sprawdzenia, czy działają zgodnie z założeniami.
• Zrozumienie realnych zagrożeń dla cyberbezpieczeństwa – teoretyczna analiza zagrożeń nie zawsze oddaje pełen obraz potencjalnych problemów. Testy penetracyjne, symulując działania prawdziwych atakujących, pozwalają zrozumieć, w jaki sposób system może zostać zaatakowany w praktyce. Ta wiedza jest bezcenna dla inżynierów, umożliwiając im budowanie bezpieczniejszych i bardziej odpornych produktów, które sprostają wyzwaniom współczesnego świata.

Problemy i wyzwania

Problemy i wyzwania stanowią naturalną barierę w trakcie wdrażania nowych procesów w naszych projektach. W kontekście wdrożenia testów penetracyjnych do systemów wbudowanych możemy je skutecznie analizować, dzieląc na dwie kluczowe perspektywy:

• ogólnofirmową (ang. company perspective) – związaną ze strategią i zasobami,
• techniczno-projektową (ang. technical project perspective) – koncentrującą się na specyfice samego produktu i procesie jego testowania.

Problemy istotne z punktu widzenia organizacji i wyzwania podczas wdrażania testów penetracyjnych przedstawiają się następująco:

• Koszty – zbudowanie procesu testów penetracyjnych wymaga znaczących inwestycji w wiedzę, zespoły, narzędzia i ciągły rozwój.
• Czas i harmonogram – zgodnie ze statystykami – wiele projektów jest opóźnionych. Testy wymagają dodatkowego czasu niezbędnego na przeprowadzenie wszystkich wymaganych czynności.
• Alokacja zasobów i brak wiedzy specjalistycznej – wykonywanie testów będzie wymagało angażowania inżynierów z wielu dziedzin. Będziemy musieli połączyć wiedzę dotyczącą sprzętu i oprogramowania.
• Integracja i naprawa wykrytych podatności, zagrożeń – zmiany niezbędne do zaimplementowania w celu naprawienia wykrytych podatności będą niejednokrotnie wpływały na podstawową funkcjonalność urządzenia.

Z perspektywy techniczno-projektowej najważniejsze wyzwania przedstawiają się następująco:

• Ustalenie punktu startowego – ograniczony czas i zasoby będą mieć wpływ na decyzję, od których komponentów powinniśmy zacząć proces testowania. Przetestowanie których elementów systemu pozwoli na uzyskanie oczekiwanych rezultatów.
• Narzędzia – testy swoim zakresem będą obejmowały warstwę fizyczno-sprzętową i programową.
• Wymagania i kwalifikacje – testowanie wielu elementów będzie wymagało połączenia wiedzy specjalistycznej z wielu dziedzin. Będzie wymagana wiedza na temat sprzętu, oprogramowania, a także szczegółów działania testowanego elementu (protokoły transmisji, budowa, przesyłanie danych).
• Środowisko testowe – wykonywane testy nie będą mogły wpływać na inne systemy działające w pobliżu. W wielu przypadkach wymagane będzie przygotowanie dedykowanych laboratoriów, które pozwolą na odizolowanie przeprowadzanych testów.
• Ocena jakości i efektywności – w przypadku zidentyfikowania podatności nigdy nie będziemy pewni, czy nie istnieją inne ścieżki ataku lub złamania systemu.

Plan działania – jak zacząć?

Przedstawiony poniżej plan działania został podzielony na 6 punktów i zakłada wdrożenie testów penetracyjnych od podstaw:

1. Budowanie wiedzy:
   • Inwestowanie w szkolenia.
   • Gromadzenie zasobów.
   • Budowanie kultury testów penetracyjnych.
2. Budowanie zespołów:
   • Identyfikacja umiejętności.
   • Określeni ról i obowiązków.
3. Budowanie środowiska testowego:
   • Wybranie narządzi sprzętowych i programowych.
   • Zbudowanie izolowanego środowiska.
   • Stworzenie procesu.
4. Identyfikacja krytycznych zasobów systemu:
   • Stworzenie modelu systemu.
   • Identyfikacja krytycznych funkcjonalności.
   • Identyfikacja potencjalnych podatności.
5. Rozpoczęcie wykonywania testów:
   • Stworzenie listy testów.
   • Automatyzacja i wielokrotne powtarzanie.
6. Ciągły rozwój i proces doskonalenia:
   • Analiza i ocena wyników.
   • Stworzenie planu rozwoju i naprawy.
   • Aktualizacja i zdobywanie nowej wiedzy.

Głównym celem przedstawionego planu powinno być jak najszybsze przejście do punktu 5, czyli rozpoczęcia praktycznej fazy wykonywania testów.

Musimy mieć świadomość, że bez odpowiedniego przygotowania, polegającego na zbudowaniu bazy wiedzy, testowaniu różnych narzędzi, zbudowaniu środowiska testowego oraz zespołu odpowiedzialnego za przeprowadzenie testów penetracyjnych, realizacja praktycznej części przedstawionego planu może być bardzo trudna.

Odpowiednio zaplanowany rozwój i proces doskonalenia poprzez analizę i ocenę wyników w istotny sposób może przyśpieszyć zdobywanie doświadczenia i praktycznej wiedzy. W tym przypadku ocena wykonywanej pracy często będzie miała wymiar subiektywny, a nie obiektywny. Oznacza to, że bez szczegółowej analizy nie będziemy w stanie zidentyfikować obszarów do poprawy i dalszego rozwoju.

Bardzo istotnym punktem w całym procesie jest też identyfikacja krytycznych zasobów systemu (ang. Identify critical assets). Obecnie systemy są bardzo skomplikowane i testowanie wszystkich ich elementów ze względu na ograniczony czas i koszty nie zawsze ma sens. W celu optymalizacji procesu testowania zaleca się wybranie tylko tych zasobów, które są istotne z punktu widzenia bezpieczeństwa systemów.

W tym celu bardzo pomocny będzie proces modelowania zagrożeń (ang. Threat modeling), który pozwoli na identyfikację potencjalnych słabości systemu, potencjalnych ścieżek ataku oraz wskaże najistotniejsze elementy systemu, które musimy odpowiednio przetestować (dodatkowe informacje znajdziecie w artykule: Modelowanie zagrożeń dot. cyberbezpieczeństwa w embedded).

Narzędzia i środowisko testowe

Testy penetracyjne swoim zasięgiem obejmują zarówno warstwę programową oraz fizyczno-sprzętową poprzez testowanie różnego rodzaju magistral komunikacyjnych i różnego rodzaju układów scalonych. Oznacza to, że w zależności od obszaru testowania będziemy musieli zbudować dedykowane zestawy testowe.

Listę przykładowych narzędzie w zależności od obszarów przedstawię poniżej:

• WiFi, Ethernet – Nmap, Wireshark, Zenmap, Hydra, Legion, zewnętrzne karty sieciowe i WiFi.
• Bluetooth, NFC, RFID – BlueZ, Bettercap, nRF connect, Proxmark.
• Magistrale przewodowe – DsLogic, Sigrok, FT232H.
• Pamięci, układy scalone, mikrokontrolery – Binwalk, IDA Pro, CH341A, ChipWhisper.

Zbudowanie skutecznego warsztatu będzie złożonym, wieloetapowym procesem polegającym na ciągłym rozwoju oraz rozbudowie o nowe narzędzia i metody, aby sprostać coraz nowszym zagrożeniom.

Podsumowanie

W erze Internetu Rzeczy (ang. IoT, Internet of Things), gdzie systemy wbudowane sterują kluczowymi procesami od infrastruktury krytycznej po urządzenia medyczne i domowe, ich bezpieczeństwo przestało być opcją, a stało się absolutną koniecznością.

Testy penetracyjne pozwalają spojrzeć na system z perspektywy napastnika, zidentyfikować podatności i zagrożenia. Pozwalają na wykrywanie błędów, których identyfikacja byłaby niemożliwa w przypadku zastosowania tradycyjnego podejścia do testowania.

Obecny rozwój technologiczny, napędzany przez sztuczną inteligencję, a także restrykcyjne regulacje prawne pokazują nam, że testy penetracyjne nie powinny być traktowane jako dodatkowy koszt. Powinniśmy traktować je jako strategiczną inwestycję, która pozwoli ochronić nasze produkty, dane, technologie przed różnymi cyberzagrożeniami.

Historia już wielokrotnie pokazała, że koszty związane z usuwaniem skutków ataków bardzo często wielokrotnie przekraczają koszty związane ze stworzeniem odpowiedniego procesu testowania i zabezpieczania urządzeń.