Wyobraźmy sobie dostawcę sterowników do systemów multimedialnych, który dostaje od producenta samochodów nowe zapytanie ofertowe. Obok wymagań funkcjonalnych pojawia się w nim pakiet pytań o cyberbezpieczeństwo: jak firma identyfikuje zagrożenia dla komponentu, kto zatwierdza ocenę ryzyka, jak zgłasza podatności po starcie produkcji i jak zabezpiecza aktualizacje oprogramowania. To scenariusz hipotetyczny, ale dobrze oddaje sytuację firm z łańcucha dostaw motoryzacji — pytania o ISO/SAE 21434 przestały być domeną działów badawczo-rozwojowych i trafiły do działów sprzedaży.
Ten artykuł porządkuje temat z perspektywy producenta pojazdów i jego dostawców. Wyjaśniamy, co faktycznie mówi zakres normy, dlaczego jej status prawny bywa źle rozumiany, czego wymagają regulaminy ONZ nr 155 i nr 156 oraz jak zaplanować wdrożenie tak, by przygotowanie do homologacji typu nie zaczynało się od chaosu w dokumentacji. Szersze tło zagrożeń dla pojazdów połączonych z siecią opisujemy w artykule o bezpieczeństwie connected cars i ISO 21434.
Czym jest ISO/SAE 21434 i jaki zakres obejmuje?
ISO/SAE 21434:2021 „Road vehicles — Cybersecurity engineering” to wspólna norma ISO i SAE poświęcona inżynierii cyberbezpieczeństwa pojazdów drogowych. Zgodnie z opisem zakresu, opublikowanym m.in. w katalogu estońskiej jednostki normalizacyjnej EVS, dokument określa wymagania inżynierskie dla zarządzania ryzykiem cyberbezpieczeństwa w odniesieniu do koncepcji, rozwoju produktu, produkcji, eksploatacji, utrzymania i wycofania z użytku systemów elektrycznych i elektronicznych (E/E) pojazdów drogowych, łącznie z ich komponentami i interfejsami.
Norma definiuje ramy obejmujące wymagania dla procesów cyberbezpieczeństwa oraz wspólny język do komunikowania ryzyka i zarządzania nim. Producent pojazdu, dostawca modułu i dostawca oprogramowania muszą opisywać zagrożenia, cele i środki ochrony w porównywalny sposób, inaczej wymiana dokumentacji w łańcuchu dostaw zamienia się w tłumaczenie między różnymi metodykami.
Ważne są też dwa ograniczenia zapisane w zakresie. Po pierwsze, norma dotyczy systemów E/E pojazdów produkowanych seryjnie, których rozwój lub modyfikacja rozpoczęły się po jej publikacji. Po drugie, nie narzuca konkretnych technologii ani rozwiązań — nie mówi, jakiego szyfrowania, jakiej bramki sieciowej czy jakiego modułu bezpieczeństwa sprzętowego użyć. Oczekuje natomiast, że wybór środków ochrony będzie wynikał z zarządzania ryzykiem.
W praktyce oznacza to, że ISO/SAE 21434 jest przede wszystkim normą procesową. Ocenia się nie to, czy w sterowniku jest konkretny mechanizm, ale czy organizacja potrafi wykazać, dlaczego go zastosowała, kto podjął decyzję i jak ryzyko będzie kontrolowane przez cały cykl życia produktu.
Czy ISO/SAE 21434 jest obowiązkowa dla producentów pojazdów?
Krótka odpowiedź brzmi: sama norma nie jest wprost wymagana, obowiązkowe są natomiast wymagania regulaminu ONZ nr 155, który norma pomaga spełnić. To rozróżnienie warto znać, bo w materiałach rynkowych często pada uproszczenie „ISO 21434 jest wymagana przez UNECE”. Tekst regulaminu ONZ nr 155 opublikowany w Dzienniku Urzędowym UE wymienia ISO/SAE 21434 w przypisie — jako przykład normy, obok ISO 26262-2018 i ISO/PAS 21448, w kontekście kompetencji personelu organów udzielających homologacji.
Obowiązek w Unii Europejskiej wynika z prawa homologacyjnego. Rozporządzenie (UE) 2019/2144 w wersji skonsolidowanej wymienia w załączniku II wymóg „D4 Ochrona pojazdu przed cyberatakami”, odsyła w nim do regulaminu ONZ nr 155 i przypisuje mu daty z grupy B. Dla tej grupy przepisy wskazują odmowę udzielenia homologacji typu UE od 6 lipca 2022 r. oraz zakaz rejestracji pojazdów od 7 lipca 2024 r.
Już w motywach pierwotnego tekstu rozporządzenia (UE) 2019/2144 prawodawca zapisał, że regulaminy ONZ lub inne akty regulacyjne dotyczące cyberbezpieczeństwa powinny być obowiązkowo stosowane jak najszybciej po ich wejściu w życie. Uzasadnieniem była łączność i automatyzacja pojazdów, które zwiększają możliwość nieupoważnionego, zdalnego dostępu do danych pokładowych.
Dlaczego więc producenci i tak oczekują od dostawców ISO/SAE 21434? Bo regulamin nr 155 mówi, co trzeba wykazać, ale nie opisuje szczegółowo, jak zorganizować pracę inżynierską. Norma wypełnia tę lukę i daje wspólny punkt odniesienia dla audytów dostawców. Decyzja o formalnym wdrożeniu należy jednak do organizacji i jej klientów, dlatego warto zapisać ją wprost w umowach i specyfikacjach.
Czego regulamin ONZ nr 155 wymaga od producenta pojazdów?
Regulamin ONZ nr 155 ma zastosowanie do pojazdów kategorii M i N w odniesieniu do cyberbezpieczeństwa, a także do pojazdów kategorii O, gdy są one wyposażone w co najmniej jeden elektroniczny moduł sterujący. Jego sercem jest system zarządzania cyberbezpieczeństwem (CSMS), czyli systematyczne, oparte na analizie ryzyka podejście, w ramach którego definiuje się procesy organizacyjne, obowiązki i zarządzanie.
Producent musi wykazać, że CSMS obejmuje etap rozwoju, etap produkcji i etap poprodukcyjny. Ten ostatni trwa do czasu wycofania z użytku wszystkich pojazdów danego typu, czyli długo po zakończeniu produkcji. Procesy CSMS mają obejmować m.in. identyfikację czynników ryzyka dla typów pojazdu, ich ocenę i kategoryzację, testowanie cyberbezpieczeństwa, utrzymywanie aktualności oceny ryzyka oraz monitorowanie i wykrywanie cyberataków, a także reagowanie na nie.
Monitorowanie nie kończy się w fabryce. Regulamin wymaga objęcia monitorowaniem pojazdów po pierwszej rejestracji, a producent zgłasza organowi udzielającemu homologacji co najmniej raz w roku rezultat działań monitorujących, łącznie z istotnymi informacjami na temat nowych cyberataków. Za skuteczność CSMS odpowiada więc organizacja, która przez lata utrzymuje zdolność analizy danych z eksploatowanych pojazdów.
Formalnym potwierdzeniem jest świadectwo zgodności dla systemu zarządzania cyberbezpieczeństwem, które pozostaje ważne przez maksymalnie trzy lata od dnia wydania, chyba że zostanie cofnięte. Osobno udziela się homologacji typu pojazdu, a jej warunkiem jest ważne świadectwo zgodności właściwe dla danego typu.
Jak w praktyce wygląda ocena zagrożeń i ryzyka (TARA)?
Ocena zagrożeń i ryzyka, w skrócie TARA (threat analysis and risk assessment), to moment, w którym ogólne zasady zamieniają się w decyzje projektowe. Regulamin ONZ nr 155 definiuje ocenę ryzyka jako ogólny proces wyszukiwania, rozpoznawania i opisywania ryzyka, określenia jego poziomu oraz porównywania wyników analizy z kryteriami ryzyka, aby określić, czy ryzyko jest dopuszczalne lub tolerowane.
Wymagania wobec typu pojazdu są konkretne. Producent określa kluczowe elementy typu pojazdu i przeprowadza wyczerpującą ocenę ryzyka, która uwzględnia poszczególne elementy, interakcje między nimi oraz interakcje z ewentualnymi systemami zewnętrznymi. Załącznik 5 regulaminu zawiera wykaz zagrożeń i odpowiadających im środków ograniczających. Brak wyczerpującej oceny ryzyka jest jedną z wymienionych w regulaminie podstaw odmowy udzielenia homologacji.
W dobrze prowadzonej TARA każdy zidentyfikowany scenariusz ataku ma właściciela, ocenę wpływu i wykonalności, decyzję o postępowaniu z ryzykiem i powiązanie z wymaganiami dla zespołów projektowych. Największym błędem jest traktowanie TARA jako jednorazowego dokumentu do homologacji. Regulamin wymaga procesów, które utrzymują aktualność oceny ryzyka, więc nowa podatność w bibliotece komunikacyjnej czy nowy interfejs diagnostyczny powinny uruchamiać jej przegląd.
Dla wielu organizacji dobrym punktem startu jest zewnętrzny przegląd metodyki oceny ryzyka, zanim zostanie ona powielona w kolejnych projektach. nFlo prowadzi przeglądy, audyty i doradztwo w obszarze analizy ryzyka, które pomagają sprawdzić spójność kryteriów i kompletność dokumentacji.
Jakie obowiązki wobec aktualizacji oprogramowania wprowadza regulamin ONZ nr 156?
Regulamin ONZ nr 156 uzupełnia regulamin nr 155 o proces aktualizacji oprogramowania. Ma zastosowanie do pojazdów kategorii M, N, O, R, S i T, które umożliwiają aktualizację oprogramowania. Jego odpowiednikiem CSMS jest system zarządzania aktualizacjami oprogramowania (SUMS), czyli systemowe podejście określające procesy i procedury organizacyjne, które mają zapewnić zgodność z wymaganiami dotyczącymi aktualizacji.
Regulamin wprowadza identyfikator RXSWIN, czyli określony przez producenta numer identyfikacyjny oprogramowania istotnego dla homologacji typu. Dzięki niemu da się udokumentować, jakie wersje oprogramowania były w pojeździe przed aktualizacją i po niej. Autentyczność i prawidłowość aktualizacji oprogramowania musi być chroniona, aby w racjonalny sposób zapobiec ich naruszeniu i nieważnym aktualizacjom.
Przy aktualizacjach bezprzewodowych (OTA) dochodzą wymagania funkcjonalne. Pojazd musi umieć przywrócić systemy do poprzedniej wersji albo przejść do stanu bezpiecznego po awarii lub przerwaniu aktualizacji. Aktualizację wolno wykonać tylko wtedy, gdy pojazd ma moc wystarczającą do zakończenia procesu, a producent musi wykazać, że użytkownik pojazdu jest w stanie uzyskać informacje o aktualizacji przed jej wykonaniem.
Z perspektywy ISO/SAE 21434 kanał aktualizacji to jeden z kluczowych zasobów do objęcia oceną ryzyka. Podpisywanie pakietów, ochrona kluczy kryptograficznych i separacja środowisk budowania oprogramowania to obszary, w których błędy projektowe przekładają się bezpośrednio na trudności z wykazaniem zgodności z regulaminem nr 156.
Co ISO/SAE 21434 i regulamin nr 155 oznaczają dla dostawców komponentów?
Regulamin ONZ nr 155 adresuje producenta pojazdu, ale jego wymagania szybko przechodzą w dół łańcucha dostaw. Producent musi wykazać, w jaki sposób jego CSMS umożliwi zarządzanie zależnościami z dostawcami lub usługodawcami, z którymi zawarł umowę. Musi też określać czynniki ryzyka związane z dostawcą i zarządzać nimi, a organ udzielający homologacji sprawdza, czy informacje zebrano i zweryfikowano w całym łańcuchu dostaw.
Dla dostawcy oznacza to konkretne oczekiwania: opisany proces cyberbezpieczeństwa dla komponentu, podział odpowiedzialności z klientem, zdolność do przekazania wyników analizy ryzyka i testów oraz proces obsługi podatności po rozpoczęciu produkcji. ISO/SAE 21434 daje na to wspólny słownik, dzięki któremu dostawca i producent mogą uzgodnić zakres pracy bez sporów o terminologię.
W relacjach handlowych warto z wyprzedzeniem ustalić trzy rzeczy: kto przeprowadza ocenę ryzyka dla komponentu i na jakim poziomie szczegółowości, jak długo dostawca wspiera produkt w etapie poprodukcyjnym oraz w jakim trybie przekazuje informacje o nowych podatnościach. Brak tych ustaleń wychodzi zwykle dopiero przy przygotowaniu dokumentacji do homologacji, kiedy czasu na zmiany jest najmniej.
Osobną kwestią jest ochrona informacji przekazywanych w projekcie. Regulamin przewiduje, że informacje objęte prawami własności intelektualnej producenta lub jego dostawców traktuje się w sposób poufny, ale to po stronie firm leży zabezpieczenie samej wymiany dokumentów projektowych.
Czym ISO/SAE 21434 różni się od TISAX?
TISAX i ISO/SAE 21434 często pojawiają się w tych samych wymaganiach zakupowych, ale odpowiadają na inne pytania. Według ENX Association, która zarządza TISAX, TISAX powstał, aby stworzyć ustandaryzowane i skalowalne podejście do bezpieczeństwa informacji w branży motoryzacyjnej, i opiera się na katalogu Information Security Assessment (ISA). Ochroną obejmuje się w nim m.in. dane projektowe, informacje produkcyjne, informacje o klientach, prototypy i własność intelektualną.
ISO/SAE 21434 dotyczy natomiast inżynierii cyberbezpieczeństwa samego produktu, czyli systemów E/E pojazdu, ich komponentów i interfejsów w całym cyklu życia. Upraszczając: TISAX odpowiada na pytanie, czy organizacja bezpiecznie obchodzi się z informacjami klienta, a ISO/SAE 21434 — czy produkt jest projektowany i utrzymywany z kontrolą ryzyka cyberbezpieczeństwa.
Różni się też forma wyniku. Rezultaty oceny TISAX są wydawane jako etykiety, które według ENX są ważne przez trzy lata, a firma udostępnia je wybranym partnerom przez portal ENX. W przypadku ISO/SAE 21434 warto uzgodnić z klientem już na etapie oferty, jakie dowody zgodności będą przekazywane w projekcie i w jakiej formie.
Obie ramy dobrze się uzupełniają. Szczegóły przygotowania do oceny TISAX opisujemy w artykule Co to jest TISAX i jak się przygotować, a nFlo wspiera ten proces w ramach przeglądów i doradztwa TISAX dla branży motoryzacyjnej.
Jak przygotować organizację do wdrożenia ISO/SAE 21434?
Wdrożenie zaczyna się od decyzji o zakresie, nie od narzędzi. Trzeba ustalić, których produktów i projektów dotyczy, jaka jest rola organizacji (producent pojazdu, dostawca systemu, dostawca oprogramowania) i jakie wymagania już przyszły od klientów. Na tej podstawie powstaje polityka cyberbezpieczeństwa produktu i przypisanie odpowiedzialności — z osobą, która ma realny wpływ na decyzje projektowe.
Drugi krok to analiza luk wobec obecnych procesów inżynierskich. Firmy z dojrzałym procesem bezpieczeństwa funkcjonalnego mają zwykle gotowe elementy: zarządzanie wymaganiami, przeglądy i zarządzanie konfiguracją. ISO/SAE 21434 dokłada do nich warstwę ryzyka cyberbezpieczeństwa. Przy okazji warto sprawdzić kryptografię, bo regulamin nr 155 wymaga, by moduły kryptograficzne były zgodne z normami wynikającymi z konsensusu, a jeśli nie są, producent musi uzasadnić ich zastosowanie.
Trzeci krok to pilotaż na jednym projekcie. Lepiej przejść pełny cykl — od oceny ryzyka, przez wymagania i testy, po plan monitorowania — na jednym komponencie, niż równolegle produkować dokumenty dla całego portfela. Pilotaż pokazuje, które szablony działają, ile pracy wymaga analiza i gdzie brakuje kompetencji.
Czwarty krok to zdolność operacyjna po starcie produkcji: monitoring źródeł informacji o podatnościach, ocena ich wpływu na wyprodukowane pojazdy i ścieżka dostarczenia poprawek. Regulamin nr 155 wymaga, by zagrożenia i podatności, które wymagają reakcji producenta, były łagodzone w rozsądnych ramach czasowych.
Jaką rolę odgrywają testy penetracyjne ECU i oprogramowania wbudowanego?
Testy są wymaganiem, a nie dodatkiem. Regulamin ONZ nr 155 stanowi, że przed udzieleniem homologacji typu producent pojazdów przeprowadza odpowiednie i wystarczające testy w celu sprawdzenia skuteczności wdrożonych środków bezpieczeństwa. Organ udzielający homologacji lub placówka techniczna dodatkowo weryfikuje za pomocą badania pojazdu, czy producent wdrożył udokumentowane środki cyberbezpieczeństwa.
W praktyce testy weryfikują założenia z oceny ryzyka. Jeżeli analiza zakłada, że interfejs diagnostyczny wymaga uwierzytelnienia, test sprawdza, czy rzeczywiście tak jest i czy da się to obejść. Jeżeli zabezpieczeniem aktualizacji jest podpis cyfrowy, test sprawdza obsługę błędnych pakietów i odporność na przywrócenie starszej, podatnej wersji oprogramowania.
Zakres testów obejmuje zwykle oprogramowanie układowe sterowników, interfejsy komunikacyjne, aplikacje towarzyszące i usługi backendowe, z którymi pojazd się łączy. nFlo realizuje testy penetracyjne oprogramowania wbudowanego, a dla usług sieciowych i aplikacji — testy penetracyjne infrastruktury i aplikacji. Związek testów z wymaganiami łańcucha dostaw omawiamy też w artykule o TISAX i testach penetracyjnych w motoryzacji.
Wyniki testów warto od razu wiązać z dokumentacją. Znalezisko powinno wracać do oceny ryzyka jako nowy lub zaktualizowany scenariusz, a jego obsługa — do planu działań. Wtedy raport z testu staje się dowodem dla organu udzielającego homologacji, a nie odrębnym dokumentem.
Jakie dokumenty trzeba przygotować do homologacji typu?
Wniosek o homologację typu w zakresie cyberbezpieczeństwa zawiera m.in. świadectwo zgodności dla systemu zarządzania cyberbezpieczeństwem. Załącznik 1 regulaminu ONZ nr 155 wymienia dokumenty dla typu pojazdu: rezultat oceny ryzyka i zidentyfikowane zagrożenia, opis wdrożonych środków ograniczających i tego, jak łagodzą one ryzyko, opis zabezpieczenia specjalnych środowisk dla oprogramowania i danych rynku wtórnego, opis testów wraz z ich wynikami oraz opis uwzględnienia łańcucha dostaw.
Dokumentacja ma dwie części: pakiet formalny przekazywany przy wniosku i materiały dodatkowe udostępniane do kontroli. Materiały udostępnione do kontroli producent musi utrzymywać dostępne przez okres co najmniej 10 lat od chwili ostatecznego zaprzestania produkcji danego typu pojazdu. To argument za tym, by repozytorium dowodów zaprojektować od początku z myślą o długim przechowywaniu.
Dobrą praktyką jest prowadzenie jednej macierzy powiązań: zagrożenie, ocena ryzyka, wymaganie, środek ograniczający, test i wynik. Taka macierz ułatwia odpowiedź na pytania organu i klienta oraz pokazuje luki, zanim zrobi to audytor.
Jak zaplanować wdrożenie krok po kroku?
Poniższa mapa drogowa łączy wymagania normy i regulaminów z produktami pracy, które warto mieć na każdym etapie. Kolejność jest ważniejsza od tempa: każdy etap korzysta z wyników poprzedniego.
| Etap | Cel | Produkt pracy | Punkt odniesienia |
|---|---|---|---|
| Zakres i odpowiedzialność | Ustalić produkty, rolę organizacji i właściciela tematu | Polityka cyberbezpieczeństwa produktu, macierz ról | ISO/SAE 21434 — ramy procesów |
| Analiza luk | Porównać obecne procesy inżynierskie z wymaganiami | Lista luk z planem działań | ISO/SAE 21434, regulamin ONZ nr 155 (CSMS) |
| Ocena ryzyka (TARA) w pilotażu | Przejść pełny cykl na jednym komponencie | Ocena ryzyka z decyzjami i właścicielami | Regulamin ONZ nr 155 — wyczerpująca ocena ryzyka |
| Wymagania i projekt | Przełożyć ryzyka na środki ograniczające | Wymagania bezpieczeństwa i architektura | Regulamin ONZ nr 155 — załącznik 5 |
| Testy | Sprawdzić skuteczność środków przed homologacją | Raport z testów powiązany z oceną ryzyka | Regulamin ONZ nr 155 — testy przed homologacją typu |
| Aktualizacje oprogramowania | Zabezpieczyć kanał aktualizacji i ewidencję wersji | Proces SUMS, ewidencja RXSWIN | Regulamin ONZ nr 156 |
| Monitorowanie i reagowanie | Utrzymać kontrolę ryzyka po pierwszej rejestracji | Proces obsługi podatności, sprawozdanie co najmniej raz w roku | Regulamin ONZ nr 155 — monitorowanie ciągłe |
Kluczowe wnioski
- ISO/SAE 21434 to norma procesowa: określa wymagania inżynierskie dla zarządzania ryzykiem cyberbezpieczeństwa w całym cyklu życia systemów E/E i nie narzuca konkretnych technologii.
- W UE obowiązkowy jest regulamin ONZ nr 155 (przez rozporządzenie (UE) 2019/2144), a nie sama norma; regulamin wymienia ISO/SAE 21434 jako przykład.
- CSMS obejmuje etap rozwoju, produkcji i etap poprodukcyjny, a monitorowanie obejmuje pojazdy po pierwszej rejestracji.
- Regulamin ONZ nr 156 dokłada wymagania dla aktualizacji oprogramowania: SUMS, RXSWIN i bezpieczne aktualizacje OTA.
- Dostawcy komponentów odczuwają wymagania przez umowy z producentem, dlatego zakres oceny ryzyka i obsługi podatności warto ustalić przed startem projektu.
Cyberbezpieczeństwo w Twojej branży
Dowiedz się więcej o cyberbezpieczeństwie w Twojej branży:
Tematy powiązane
Zobacz również:
Powiązane terminy
Sprawdź nasze usługi
- Audyt bezpieczeństwa systemów OT/ICS - cyberbezpieczeństwo w motoryzacji
- Audyty bezpieczeństwa - zgodność z ISO 21434
Najczęściej zadawane pytania
Czy norma ISO/SAE 21434 jest obowiązkowa dla producentów pojazdów?
Nie wprost. Regulamin ONZ nr 155 wymaga systemu zarządzania cyberbezpieczeństwem i oceny ryzyka dla typu pojazdu, a ISO/SAE 21434 wymienia w przypisie jako przykład normy. Obowiązek stosowania regulaminu nr 155 w UE wynika z rozporządzenia (UE) 2019/2144.
Czy ISO/SAE 21434 wskazuje konkretne technologie zabezpieczeń?
Nie. Zgodnie z opisem zakresu norma nie narzuca konkretnych technologii ani rozwiązań. Wymaga, by środki ochrony wynikały z udokumentowanego zarządzania ryzykiem cyberbezpieczeństwa.
Jak długo jest ważne świadectwo zgodności dla systemu zarządzania cyberbezpieczeństwem?
Zgodnie z regulaminem ONZ nr 155 świadectwo pozostaje ważne przez maksymalnie trzy lata od dnia wydania, chyba że zostanie cofnięte.
