Cybersecurity Interface Agreement (CIA) – czym jest i dlaczego jest potrzebna

Czasy, gdy pojedyncza organizacja samodzielnie rozwijała elektroniczne jednostki sterujące (ECU) dla pojazdu, a kwestie cyberbezpieczeństwa uwzględniano dopiero na końcu projektu, należą już do przeszłości.

Współczesne architektury pojazdów są rozproszone, a odpowiedzialność za cyberbezpieczeństwo jest podzielona pomiędzy:

• producenta pojazdu (OEM, Original Equipment Manufacturer),
• dostawców Tier 1,
• dostawców Tier 2 odpowiedzialnych za sprzęt i oprogramowanie.

Norma ISO/SAE 21434 uwzględnia tę zależność, wprowadzając Cybersecurity Interface Agreement (CIA) jako formalny mechanizm definiowania odpowiedzialności, wymiany informacji i współpracy pomiędzy organizacjami zaangażowanymi w rozwój produktu.

CIA to znacznie więcej niż kolejny dokument wymagany przez normę. W praktyce jest to jeden z kluczowych elementów, który warto właściwie przygotować już na samym początku realizacji projektu zgodnie z ISO/SAE 21434. Dla dostawcy Tier 1 CIA jest jednym z najważniejszych elementów przygotowania projektu. Znajduje się on pomiędzy OEM-em, który definiuje wymagania i oczekiwania dotyczące cyberbezpieczeństwa na poziomie pojazdu, a dostawcami Tier 2 dostarczającymi komponenty, sprzęt oraz oprogramowanie.

W takiej sytuacji skuteczna koordynacja CIA pomiędzy wszystkimi stronami staje się niezbędna. Każdy uczestnik projektu ma wpływ na bezpieczeństwo końcowego produktu, dlatego już na początku warto jednoznacznie określić:

• zakres odpowiedzialności,
• oczekiwania,
• sposób współpracy.

Pozwala to uniknąć nieporozumień i znacznie ułatwia zarządzanie cyberbezpieczeństwem na kolejnych etapach rozwoju produktu.

CIA w normie ISO/SAE 21434

Cybersecurity Interface Agreement został opisany w rozdziale 7 normy ISO/SAE 21434 dotyczącym rozproszonych działań związanych z cyberbezpieczeństwem (Distributed Cybersecurity Activities). Punkt 7.4.3 określa wymagania dotyczące ustanowienia oraz utrzymywania CIA.

CIA określa zasady realizacji działań związanych z cyberbezpieczeństwem pomiędzy stronami uczestniczącymi w projekcie. Obejmuje interakcje pomiędzy klientem a dostawcą, niezależnie od poziomu współpracy (OEM↔Tier 1; Tier 1 ↔Tier 2), zarówno fazę rozwoju produktu, jak i działania realizowane po zakończeniu rozwoju, takie jak zarządzanie podatnościami, działania post-production oraz wycofanie produktu z eksploatacji (End of Life).

Norma dopuszcza także stosowanie CIA pomiędzy wewnętrznymi jednostkami organizacji, choć w praktyce rozwiązanie to spotyka się stosunkowo rzadko. Takie podejście może być szczególnie przydatne w organizacjach działających w silosach.

Każdy interfejs pomiędzy klientem a dostawcą powinien być zarządzany oddzielnie.

Praktyka

Przykładowo, jeśli projekt obejmuje jednego OEM-a, jednego dostawcę Tier 1, dwóch dostawców Tier 2, naturalną pokusą może być przygotowanie jednego dokumentu obejmującego wszystkich uczestników projektu. W praktyce warto tego unikać.

Zalecane jest utworzenie trzech niezależnych CIA:

• OEM ↔ Tier 1
• Tier 1 ↔ Tier 2A
• Tier 1 ↔ Tier 2B

Takie podejście znacząco ogranicza ryzyko nieporozumień, sporów dotyczących odpowiedzialności oraz rozbieżności interpretacyjnych. Jest to szczególnie istotne, ponieważ CIA stanowi element uzgodnień kontraktowych między konkretnymi stronami.

Alternatywnie można utworzyć jeden dokument zawierający oddzielne sekcje dla każdej relacji, jednak nadal zaleca się zachowanie jasnego podziału odpowiedzialności pomiędzy poszczególnymi interfejsami. W praktyce OEM będzie rozliczał dostawcę Tier 1 z realizacji wymagań cyberbezpieczeństwa niezależnie od tego, czy część działań została powierzona dostawcom Tier 2.

Przykładowa zawartość szablonu CIA

W załączniku C normy ISO/SAE 21434 znajduje się przykładowy szablon CIA, który może stanowić dobry punkt wyjścia do opracowania własnych szablonów i narzędzi.

Można go z łatwością zaadaptować do arkusza kalkulacyjnego, a niektóre firmy wykorzystują nawet dedykowane narzędzia lub bazy danych do zarządzania i standaryzacji swoich CIA. Niezależnie jednak od wybranego narzędzia, najważniejsza pozostaje zawartość dokumentu. Kluczowe jest, aby wszystkie zaangażowane strony jasno uzgodniły i udokumentowały w CIA zakres odpowiedzialności (najczęściej przy użyciu macierzy RASIC), zasady wymiany informacji oraz oczekiwany poziom realizacji poszczególnych kamieni milowych.

CIA powinna również zawierać dane kontaktowe wszystkich uczestników projektu – producenta pojazdu (OEM), dostawców Tier 1 oraz Tier 2 – a także miejsce na formalne zatwierdzenie dokumentu przez każdą ze stron. Ma to szczególne znaczenie w projektach realizowanych przez wiele lat.

W praktyce CIA często staje się podstawowym dokumentem wykorzystywanym do weryfikacji, kto był odpowiedzialny za dane działanie, jakie rezultaty miały zostać dostarczone oraz na którym etapie projektu powinno to nastąpić. Dlatego wszystkie strony powinny świadomie zaakceptować i formalnie zatwierdzić zawarte w nim ustalenia.

Istotne elementy

Poniżej znajdują się elementy, które warto uwzględnić dla każdej pozycji w szablonie CIA.

• Project Phase –tap projektu, w którym realizowane jest dane działanie związane z cyberbezpieczeństwem, np. Concept, Product Development czy Production.
• Work Product – dokument, artefakt lub rezultat wymagany przez ISO/SAE 21434 (pełna lista znajduje się w załączniku A normy), który należy dostarczyć w ramach danej aktywności.
• Reference – odniesienie do odpowiedniego punktu normy i związanych z nim wymagań dotyczących danego działania.
• Supplier RASIC – zakres odpowiedzialności dostawcy za daną aktywność lub Work Product.
• Customer RASIC – zakres odpowiedzialności klienta za daną aktywność lub Work Product.

Macierz RASIC

Macierz RASIC obejmuje następujące role:

• R (Responsible) –organizacja odpowiedzialna za wykonanie zadania.
• A (Accountable) –organizacja posiadająca uprawnienia do zatwierdzenia rezultatu i ponosząca za niego odpowiedzialność.
• S (Supporting) –organizacja wspierająca realizację działania.
• I (Informed) –organizacja informowana o postępach prac i podejmowanych decyzjach.
• C (Consulted) – organizacja dostarczająca wiedzy eksperckiej lub rekomendacji, bez bezpośredniego udziału w realizacji zadania.

Level of Confidentiality

Poziom poufności uzgodniony pomiędzy stronami dla danego Work Product.

Przykładowe poziomy mogą obejmować:

• Highly Confidential – dostęp wyłącznie dla organizacji, która wytworzyła dokument.
• Confidential – dostęp dla klienta i dostawcy.
• Confidential with Third Parties – możliwość udostępnienia dokumentu stronom trzecim.
• Public – brak ograniczeń dotyczących udostępniania.

Inne elementy

• Deliverable – opis rezultatu, który ma zostać dostarczony, wraz z informacjami dotyczącymi jego formatu, sposobu przekazania, wymaganych przeglądów oraz działań weryfikacyjnych.
• Tailoring – uzasadnienie wszelkich uzgodnionych odstępstw lub modyfikacji standardowych działań związanych z cyberbezpieczeństwem.
• Exchange Scope – zakres udostępnianych informacji, np.: pełny dokument, wybrane dokumenty, wyłącznie przegląd na miejscu, brak przekazania dokumentu.
• Exchange Direction – kierunek przekazywania danego Work Product, np. od dostawcy do klienta lub odwrotnie.
• Milestones – kamienie milowe określające termin realizacji danego działania oraz dostarczenia wymaganego rezultatu.
• Comments – dodatkowe informacje, ustalenia lub uwagi dotyczące zakresu prac oraz uzgodnionego sposobu realizacji danej aktywności związanej z cyberbezpieczeństwem.

Kiedy przygotować CIA?

Ponieważ CIA obejmuje cały cykl życia działań związanych z cyberbezpieczeństwem – od fazy koncepcji aż po działania realizowane po zakończeniu produkcji – warto rozpocząć prace nad tym dokumentem możliwie jak najwcześniej. Najlepiej jeszcze przed startem projektu, a najpóźniej przed przeprowadzeniem analizy TARA (Threat Analysis and Risk Assessment).

Wiele działań związanych z cyberbezpieczeństwem, które zostaną ujęte w CIA, będzie wymagało wyceny ze strony dostawców Tier 1 i Tier 2. Dlatego tak istotne jest, aby odpowiedzialność za poszczególne zadania została jasno określona i uzgodniona na początku projektu. Dotyczy to również aktywności generujących dodatkowe koszty, takich jak zewnętrzne oceny bezpieczeństwa, testy penetracyjne czy specjalistyczne audyty. Jeśli zostaną uwzględnione w CIA odpowiednio wcześnie, łatwiej będzie je zaplanować w budżecie projektu.

Brak uzgodnionej CIA na początkowym etapie często prowadzi do sytuacji, w których wymagania dotyczące cyberbezpieczeństwa są identyfikowane zbyt późno albo przypisywane niewłaściwym stronom. W efekcie pojawiają się dodatkowe koszty, konieczność przeprojektowania części rozwiązań oraz opóźnienia w realizacji projektu.

W praktyce przygotowanie kompletnej CIA rzadko jest procesem szybkim. Uzgodnienie wszystkich działań, wymagań, odpowiedzialności i procesów związanych z cyberbezpieczeństwem zwykle wymaga wielu spotkań oraz szeregu iteracji między uczestnikami projektu. Warto więc uwzględnić ten nakład pracy już na etapie planowania i potraktować go jako inwestycję, która pozwoli uniknąć znacznie większych problemów w dalszej części projektu.

Threat Model – model zagrożeń

Jednym z kluczowych zagadnień wymagających ustalenia w CIA jest zakres odpowiedzialności za przeprowadzenie TARA. W większości projektów TARA wykonywana jest przez OEM na poziomie pojazdu lub systemu, a następnie wymagania dotyczące cyberbezpieczeństwa są przypisywane poszczególnym komponentom.

ISO/SAE 21434 dopuszcza jednak wykonywanie TARA również na niższych poziomach architektury, szczególnie tam, gdzie granice odpowiedzialności nie są jednoznaczne.

Dlatego CIA pomiędzy OEM-em a Tier 1 powinna jednoznacznie określać:

• kto przeprowadza TARA,
• na jakim poziomie będzie realizowana analiza,
• które wymagania zostaną przekazane dostawcom.

Dostawcy Tier 2 zazwyczaj nie odpowiadają za przeprowadzanie pełnej analizy TARA. Ich rola koncentruje się przede wszystkim na technicznej implementacji mechanizmów bezpieczeństwa w sprzęcie i oprogramowaniu na etapie rozwoju produktu. Dlatego CIA powinna jednoznacznie określać, gdzie zaczyna się i kończy jej zakres odpowiedzialności w obszarze cyberbezpieczeństwa.

Szczególną uwagę warto zwrócić na działania związane z produkcją, fazą post-production, zarządzaniem podatnościami (Vulnerability Management) oraz obsługą incydentów bezpieczeństwa (Incident Response). Obszary te często bywają pomijane, ponieważ wykraczają poza sam proces projektowania i implementacji produktu, a jednocześnie stanowią istotny element zapewnienia jego bezpieczeństwa w całym cyklu życia.

Wszystkie te kwestie powinny zostać jasno określone i udokumentowane w CIA. Pozwoli to uniknąć nieporozumień oraz zapewni, że każda ze stron będzie miała jednoznacznie określony zakres odpowiedzialności za poszczególne działania związane z cyberbezpieczeństwem.

Zarządzanie podatnościami i reagowanie na incydenty (Vulnerability Management i Incident Response)

Dwa obszary, które powinny zostać uwzględnione w CIA, a jednocześnie często schodzą na dalszy plan, to zarządzanie podatnościami oraz obsługa incydentów bezpieczeństwa. Ponieważ nie są one bezpośrednio związane z podstawowymi działaniami realizowanymi podczas rozwoju produktu, łatwo je przeoczyć na etapie planowania projektu.

W praktyce wykrycie podatności lub incydentu może nastąpić na różnych etapach cyklu życia produktu i zwykle wymaga ścisłej współpracy między producentem pojazdu (OEM) a dostawcami. Aby uniknąć późniejszych sporów dotyczących odpowiedzialności, już na etapie przygotowywania CIA warto jasno określić sposób postępowania w takich sytuacjach.

Szczególną uwagę należy zwrócić na takie kwestie jak:

• zakres informacji, które będą wymieniane pomiędzy stronami,
• poziomy poufności przekazywanych danych,
• terminy zgłaszania wykrytych podatności,
• oczekiwane czasy reakcji na zgłoszenia i zapytania,
• terminy dostarczania poprawek oraz aktualizacji,
• osoby kontaktowe odpowiedzialne za cyberbezpieczeństwo po stronie wszystkich uczestników projektu,
• ścieżki eskalacji incydentów,
• podział ról i odpowiedzialności związanych z zarządzaniem podatnościami oraz incydentami.

Warto przy tym pamiętać, że osoby odpowiedzialne za obsługę incydentów często nie są tymi samymi osobami, które uczestniczą w codziennych pracach rozwojowych nad produktem. Dlatego odpowiednio zdefiniowane kanały komunikacji i punkty kontaktowe mają kluczowe znaczenie dla sprawnego reagowania na pojawiające się problemy.

Dobrze przygotowana CIA sprawia, że działania związane z reagowaniem na incydenty nie są podejmowane pod presją czasu w sposób improwizowany, lecz realizowane zgodnie z wcześniej uzgodnionymi zasadami. Zasady te powinny uwzględniać zarówno strategię reagowania na incydenty przyjętą przez OEM na poziomie całego pojazdu jak i rzeczywiste możliwości techniczne dostawców uczestniczących w projekcie.

Sztuczna inteligencja a Cybersecurity Interface Agreement

Nie sposób dziś mówić o cyberbezpieczeństwie bez odniesienia do sztucznej inteligencji. AI może wspierać wiele działań związanych z cyberbezpieczeństwem – od modelowania zagrożeń i identyfikowania potencjalnych ścieżek ataku po analizę podatności czy wykrywanie niepożądanych zdarzeń.

Jednocześnie nie należy tracić z pola widzenia podstawowej roli CIA. Jest to przede wszystkim porozumienie określające zasady współpracy pomiędzy organizacjami oraz odpowiedzialność za realizację działań związanych z cyberbezpieczeństwem. Nawet jeśli poszczególne zadania są wspierane przez narzędzia wykorzystujące AI, nadal wymagają nadzoru, oceny i zatwierdzenia przez człowieka. Sztuczna inteligencja może wspomagać proces, ale nie daje gwarancji bezpieczeństwa produktu.

Z perspektywy CIA istotne jest więc jednoznaczne określenie, w których obszarach projektu planowane jest wykorzystanie narzędzi opartych na AI. Dzięki temu obie strony wiedzą, gdzie są wykorzystywane narzędzia AI, mogą ocenić ich przydatność oraz uzgodnić, kto ponosi odpowiedzialność za rezultaty pracy wykonanej z ich wsparciem. Z tego względu warto już na etapie przygotowywania CIA wskazać obszary, w których planowane jest wykorzystanie AI, tak aby obie strony miały świadomość jej zastosowania i mogły ocenić skuteczność takiego podejścia oraz jednoznacznie określić odpowiedzialność za wyniki działań realizowanych przy wsparciu AI.

Rekomendacje dla dostawców Tier 1

Na podstawie doświadczeń z projektów realizowanych zgodnie z ISO/SAE 21434 można wskazać kilka dobrych praktyk:

1. Rozpocznij prace nad CIA jeszcze przed finalizacją TARA.
2. Utrzymuj oddzielne CIA dla poszczególnych relacji, zapewniając jednocześnie spójność pomiędzy nimi.

OEM ↔ Tier 1 i Tier 1 ↔ Tier 2 powinny być osobne, ale spójne.

3. Dokumentuj wszystkie założenia i uzgodnienia.
4. Weryfikuj dostępność wymaganych Work Products od dostawców Tier 2 na możliwie wczesnym etapie, szczególnie tych, które będą potrzebne do budowy i uzasadnienia Cybersecurity Case.
5. Powiąż przeglądy CIA z procesem zarządzania zmianą, aby każda zmiana architektury lub dostawcy skutkowała ponowną oceną dokumentu.

Cybersecurity

Chronimy Twoje dane i środowisko IT dzięki nowoczesnym rozwiązaniom i usługom – audytom, testom penetracyjnym, ciągłemu monitorowaniu i reagowaniu na incydenty.

Oferta Cybersecurity

Podsumowanie

Dla dostawcy Tier 1 działającego w wymagającym środowisku cyberbezpieczeństwa motoryzacyjnego i projektów realizowanych zgodnie z normą ISO/SAE 21434, CIA nie jest jedynie formalnym wymogiem ani kolejnym dokumentem do wypełnienia. To jeden z kluczowych elementów, który pomaga uporządkować współpracę pomiędzy wszystkimi stronami zaangażowanymi w rozwój produktu i skutecznie zarządzać odpowiedzialnością za cyberbezpieczeństwo.

Przygotowanie jasno zdefiniowanych CIA zarówno z producentem pojazdu (OEM), jak i dostawcami Tier 2 już na początku projektu pozwala ograniczyć niejasności, skuteczniej zarządzać ryzykiem oraz uniknąć kosztownych zmian i poprawek na późniejszych etapach cyklu życia produktu. Takie podejście pokazuje również, że organizacja traktuje cyberbezpieczeństwo w sposób dojrzały i jest wiarygodnym partnerem zdolnym do realizacji swoich zobowiązań w tym obszarze.

Choć opracowanie CIA wymaga czasu i zaangażowania, jest to inwestycja, która zwykle się zwraca wielokrotnie. Problemy związane z cyberbezpieczeństwem mogą prowadzić do opóźnień produkcyjnych, kosztownych działań serwisowych, a nawet negatywnie wpłynąć na reputację firmy.

Nie da się przewidzieć wszystkich zagrożeń, które mogą pojawić się w trakcie życia produktu. Dobrze przygotowana CIA nie rozwiąże każdego problemu, ale może skutecznie pomóc uniknąć wielu kosztownych błędów i nieporozumień w trakcie całego cyklu życia produktu.