Aktualnie w wielu krajach toczą się intensywne prace mające na celu uchwalenie i wdrożenie w życie regulacji prawnych związanych z bezpieczeństwem systemów wbudowanych. Unia Europejska wspólnie z organizacjami zrzeszającymi uniwersytety i firmy technologiczne opracowała strategię bezpieczeństwa cybernetycznego.
Jednym z elementów tej strategii jest wdrożenie dyrektyw EU-RED i EU-CRA. Pierwsza z nich zacznie obowiązywać już 1 sierpnia 2025. Druga natomiast nabierze mocy prawnej za niespełna 3 lata (w marcu 2024 zaczął się okres przejściowy, który potrwa 36 miesięcy).
W artykule przybliżę, na co zwrócić uwagę, by poprawnie zaimplementować zasady bezpieczeństwa w systemach wbudowanych.
Nowe regulacje prawne
Nadchodzące regulacje prawne będą dotyczyły nie tylko podniesienia poziomu bezpieczeństwa firmy jako organizacji, ale przede wszystkim wpłyną na produkty bezpośrednio przez nie oferowane.
Nowe dyrektywy wprowadzą szereg dodatkowych obowiązków, przepisów oraz zasad. Firmy tworzące produkty zostaną zobligowane do ich wdrożenia i zaimplementowania.
Proces decyzyjny zazwyczaj wymaga czasu
W większości firm technologicznych, które projektują i/lub produkują urządzenia wbudowane, proces decyzyjny w celu wdrożenia różnych regulacji prawnych wymaga czasu. Pracując jako inżynierowie, zapewne nie zawsze potrafimy zrozumieć, dlaczego proces decyzyjny jest aż tak długi. Ale firma to zazwyczaj nie jeden projekt, a cała lista projektów, mniej lub bardziej ze sobą powiązanych.
Rozbudowane procesy biznesowe, skomplikowane procesy projektowe i produkcyjne, konieczność przeszkolenia personelu wpływają na czas realizacji przedsięwzięcia.
Krok w stronę bezpieczeństwa
Musimy mieć świadomość, że nowe regulacje prawne i standardy nie spowodują, że nasze systemy zaczną być bezpieczne. Kluczową rolę w całym procesie odegrają osoby, które będą odpowiedzialne za implementowanie i projektowanie danego produktu. Do tej grupy możemy zaliczyć inżynierów oprogramowania, testerów, architektów oraz inżynierów odpowiedzialnych za projektowanie sprzętu.
Pracując w aktualnych projektach, mamy już teraz wpływ na pewien poziom bezpieczeństwa, jaki będzie oferowany przez nasze produkty. Oczywiście – wdrożenie wszystkich wymaganych prawnie zasad bez zmiany budżetu, procesu projektowego, biznesowego, czy dodatkowych szkoleń, będzie bardzo trudne lub wręcz niemożliwe do zrealizowania.
Ale małymi krokami możemy zacząć zwiększać bezpieczeństwo naszych produktów, a jednocześnie podnosić poziom wiedzy jak i świadomości inżynierów, którzy są odpowiedzialni za projektowanie oraz implementowanie tych produktów.
Lista praktyk oraz czynności zwiększających bezpieczeństwo
Poniżej znajdziecie obszary i propozycje działań, których wdrożenie do obecnie rozwijanych projektów nie powinno znacząco wpłynąć na czas ich realizacji. Zapewne nie wszystkie z nich będą łatwe i szybkie do zaadoptowania. Zależy to od stanu projektu oraz wielu innych aspektów technicznych jak i nietechnicznych. Warto je jednak wziąć pod uwagę już dziś.
Hasła
- Nie trzymaj haseł dostępu w kodzie – hasło wpisane na stałe w kodzie prędzej czy później stanie się publicznie dostępne. Brak możliwości zmiany hasła dodatkowo komplikuje sprawę w przypadku wycieku. Dodanie mechanizmu generacji haseł w procesie produkcji urządzenia, zapisywanie ich w pamięci w postaci zakodowanej utrudni proces upublicznienia.
- Nie używaj tego samego hasła do wszystkich urządzeń – jedno hasło do wszystkich urządzeń lub jedno hasło dostępu do poszczególnych części systemu w przypadku upublicznienia spowoduje, że osoby niepowołane uzyskają dostęp do urządzeń dostępnych na rynku. W tym przypadku dobrze jest zaimplementować mechanizm generowania haseł dla poszczególnych urządzeń, np. uzależniając go od numeru seryjnego urządzenia lub numeru seryjnego mikrokontrolera. Hasła działające tylko przez określony czas mogą okazać się równie skutecznym środkiem zapobiegawczym.
Kod
- Zacznij regularnie wykonywać przeglądy kodu (ang. code review) – druga para oczu, która spojrzy na nasz kod, oceni rozwiązania, przejrzy go pod kątem bezpieczeństwa oraz wycieków pamięci, może pomóc uniknąć wielu problemów w przyszłości. Z perspektywy czasu, jaki na to musimy przeznaczyć i czasu, jaki poświęcamy na poprawki błędów, szukanie problemów może szybko się zwrócić.
- Stosuj zasady bezpiecznego programowania (ang. secure coding) – do nowo implementowanych części kodu zacznij wdrażać zasady, takie jak MISRA C czy CERT C.
Komunikacja
- Nie wysyłaj danych jawnym tekstem – systemy wbudowane często komunikują się z innymi systemami lub komunikacja odbywa się pomiędzy komponentami w ramach jednego systemu. Wysyłanie danych jawnym tekstem bez dodatkowych elementów takich jak: CRC, początek, koniec komunikatu, na pewno ułatwia analizę transmisji i wykrywanie problemów. Dane wysyłane w ten sposób mogą być łatwo odczytane lub zmienione przez osoby niepowołane. Rozwiązaniem będzie przejście na bardziej ustandaryzowane protokoły lub dodatkowe elementy szyfrujące w celu zapewnienia większej integralności ochrony przesyłanych danych.
- Wyłącz wszystkie niepotrzebne porty w komunikacji sieciowej – komunikacja sieciowa lub usługi sieciowe realizowane są z użyciem portów. Urządzenie może mieć dużo otwartych portów, z których nie korzysta. Wyłącz wszystkie niepotrzebne porty oraz usługi sieciowe w celu ograniczenia przestrzeni uzyskania dostępu do urządzenia jak i danych przez nie trzymanych oraz przetwarzanych.
- Przy komunikacji sieciowej używaj zabezpieczonych protokołów – podczas komunikacji sieciowej zawsze używaj protokołów sieciowych szyfrowanych. Uniemożliwi to jawne odczytanie i modyfikację przesyłanych danych.
- Wyłącz nieużywane porty komunikacji – urządzenia wbudowane mają często dostępne dodatkowe porty komunikacji w celu diagnostyki, programowania urządzenia, dodatkowych funkcji serwisowych. Podczas wydawania programu produkcyjnego wyłącz wszystkie dodatkowe porty oraz interfejsy komunikacyjne, które nie będą dostępne dla przyszłych użytkowników. Przez dodatkowe porty, oferujące pełną kontrolę nad urządzeniem, możemy uzyskać pełen dostęp do urządzenia.
Biblioteki
- Biblioteki i monitorowanie luk oraz zagrożeń – podczas implementowania oprogramowania często korzystamy z zewnętrznych bibliotek, które pozwalają nam szybciej zaimplementować pożądane funkcje. W Internecie znajdują się otwarte bazy danych z darmowym dostępem, gdzie inni programiści, firmy oraz organizacje odpowiedzialne za implementowanie zewnętrznych bibliotek zgłaszają wykryte luki w oprogramowaniu. Warto zacząć monitorować te bazy i sprawdzać, czy nie pojawiły się wpisy dotyczące bibliotek, których aktualnie używamy w projekcie.
- Wyłącz nieużywane funkcje w bibliotekach – jak już wspomniałem w poprzednim punkcie, niejednokrotnie biblioteki przyśpieszają nam pracę. Często jest tak, że wykorzystujemy tylko niektóre z oferowanych przez nie funkcji. Jeśli to możliwe, wyłącz w procesie kompilacji lub konfiguracji nieużywane funkcje, aby ograniczyć punkty wejściowe do urządzenia.
Świadomość
- Chroń dane prywatne i wrażliwe – nowoczesne systemy wbudowane oprócz rozbudowanej logiki gromadzą i przetwarzają duże ilości danych. Część z tych danych należy do kategorii danych prywatnych i wrażliwych, które często są głównym celem osób niepowołanych. Użyj dostępnych algorytmów kryptograficznych oraz metod szyfrowania w celu ukrycia danych i informacji, jakie ze sobą niosą.
- Zacznij zwiększać świadomość zespołu – same regulacje prawne lub standardy nie zwiększą bezpieczeństwa naszego urządzenia, jeśli inżynierowie odpowiedzialni za zaimplementowanie wymaganych funkcji, nie będą posiadać odpowiedniej wiedzy, umiejętności i świadomości. Zaimplementowanie wymaganych prawnie funkcji może wymagać dodatkowego czasu potrzebnego na doszkolenie.
Kolejny krok w stronę bezpieczeństwa
Opisane wyżej praktyki z pewnością pomogą zacząć podążać w odpowiednim kierunku związanym z bezpieczeństwem produktów, nad którymi pracujemy. Kolejny krok w stronę bezpieczeństwa będzie wymagał dużo więcej zaangażowania i skupieniu się na bardziej zaawansowanych elementach systemu.
Możemy tu wymienić:
- wymiana/instalacja/aktualizacja oprogramowania,
- bezpieczne przechowywanie danych,
- bezpieczna komunikacja,
- analiza i modelowanie systemu pod kątem wykrywania luk i zagrożeń,
- monitorowane luk wykrytych w używanych bibliotekach,
- stworzenie procesu bezpiecznego rozwoju oprogramowania.
W kolejnych artykułach skupię się na opisaniu od strony technicznej wyżej wymienionych punktów i tego, jak możemy podejść do ich realizacji i implementacji.
Podsumowanie
Poprawne zaimplementowanie zasad bezpieczeństwa w systemach wbudowanych z pewnością będzie stanowić nie lada wyzwanie dla wielu inżynierów, firm i organizacji. Proces zmiany myślenia jak i działania prawie na pewno zajmie dużo czasu i będzie się składał z wielu niezaplanowanych wcześniej czynności. Cały cykl, przez który będziemy musieli przejść, można z pewnością porównać do maratonu. Ale żeby maraton nie przerodził się w sprint, musimy zacząć działać już dziś.
Pamiętaj – Twój system będzie tak bezpieczny, jak bezpieczny jest jego najsłabszy komponent.
***
Jeśli interesuje Cię obszar embedded, zajrzyj koniecznie również do innych artykułów naszych autorów.
Zostaw komentarz