Ocena ryzyka cyberbezpieczeństwa CRA

Rola oceny ryzyka

W celu zapewnienia zgodności z ust. 1 producenci przeprowadzają ocenę ryzyk cyberbezpieczeństwa związanych z produktem z elementami cyfrowymi i uwzględniają jej wynik podczas planowania, projektowania, rozwoju, produkcji, dostawy i utrzymania produktu, aby zminimalizować ryzyka cyberbezpieczeństwa, zapobiegać incydentom i ograniczać ich skutki, także w odniesieniu do zdrowia i bezpieczeństwa użytkowników.

Rozporządzenie (UE) 2024/2847, art. 13 ust. 2

Artykuł 13 wymaga, by ocena ryzyka obejmowała cykl życia produktu i była w razie potrzeby aktualizowana w okresie wsparcia.

Co wyjaśnia ocena

Zgodnie z art. 13 ust. 3 ocena musi uwzględniać zamierzone przeznaczenie, racjonalnie przewidywalne użytkowanie, warunki użytkowania, środowisko operacyjne, chronione zasoby oraz przewidywany okres użytkowania.

• które wymagania części I załącznika I mają zastosowanie do produktu;
• w jaki sposób wdrożono wymagania dotyczące produktu;
• w jaki sposób stosuje się ogólne, oparte na ryzyku wymaganie cyberbezpieczeństwa z pkt 1 części I załącznika I;
• w jaki sposób stosuje się wymogi obsługi podatności określone w części II załącznika I;
• dlaczego wymaganie nie ma zastosowania, jeżeli taki wniosek wyciągnął producent.

Przykład: ocena ścieżki aktualizacji oprogramowania układowego

Rozważmy fikcyjny połączony sterownik, który otrzymuje oprogramowanie układowe z usługi aktualizacji. Atakujący może próbować podmienić obraz przed instalacją. Ocena powinna ustalić, czy jest to możliwe i co mogłoby zrobić zmodyfikowane oprogramowanie układowe.

1. Ustal ścieżkę aktualizacji dla modelu sterownika i wydania oprogramowania układowego. Określ, kto może dostarczyć obraz, jak trafia on do urządzenia i jakie kontrole są wykonywane przed instalacją.
2. Opisz zagrożenie: atakujący podmienia obraz oprogramowania układowego przed instalacją. Zasobem jest integralność wykonywalnego kodu; skutki zależą od funkcji, które sterownik może zmienić.
3. Oceń istniejące zabezpieczenia: ustal, gdzie obraz jest weryfikowany, które klucze podpisujące są zaufane oraz co dzieje się po nieudanej weryfikacji. Sam opis projektu nie potwierdza zachowania wydanej wersji.
4. Powiąż środki z weryfikacją: zachowaj zatwierdzony projekt aktualizacji i testy obrazów zmodyfikowanych, nieprawidłowych podpisów oraz odzyskiwania po awarii. Zapisz, które oprogramowanie układowe i konfigurację przetestowano.
5. Wyjaśnij ryzyko rezydualne, uwzględniając warunki ataku i przewidywane skutki. Wskaż założenia wymagające potwierdzenia i potrzebne dodatkowe środki. Ponownie przeanalizuj wniosek, gdy zmieni się mechanizm aktualizacji lub zagrożenie.

Diagram przepływu danych (DFD) i STRIDE mogą pomóc w identyfikowaniu ścieżek ataku na potrzeby tej analizy. Decyzja dotycząca ryzyka nadal wymaga faktów o produkcie i wyników weryfikacji. Na przykład przed uznaniem, że sprawdzanie podpisu ogranicza ryzyko, zespół powinien potwierdzić je względem projektu i przetestowanego oprogramowania układowego.

Powiązanie z dokumentacją techniczną

Artykuł 13 ust. 4 włącza ocenę ryzyka cyberbezpieczeństwa do dokumentacji technicznej. Załącznik VII wymaga, aby dokumentacja obejmowała ocenę ryzyk cyberbezpieczeństwa, pod kątem których produkt jest projektowany, rozwijany, produkowany, dostarczany i utrzymywany.

Wsparcie ze strony norm

Projekt dokumentu prEN 40000-1-2 opisuje aktualne horyzontalne zasady zarządzania ryzykiem w zakresie cyberodporności. Może pomóc uporządkować prace, ale obowiązek prawny nadal wynika z art. 13 i załącznika I.