Analiza luk CRA
Sytance · Zaktualizowano
Analiza luk CRA porównuje aktualny stan produktu i procesów producenta z wymogami CRA mającymi zastosowanie do tego produktu. Jest to metoda wdrożeniowa, a nie odrębny obowiązek nazwany w rozporządzeniu.
Podstawa prawna porównania
Podstawą porównania powinny być wymogi CRA mające zastosowanie do danego produktu. Artykuły 6 i 13 określają obowiązki dotyczące produktu i oceny ryzyka; załączniki wskazują wymagania bezpieczeństwa i przekazywane informacje. Uwzględnij również normy lub specyfikacje techniczne, na których oparto ocenę.
- Artykuł 6 i załącznik I określają wymagania dotyczące produktu i obsługi podatności.
- Artykuł 13 wymaga oceny ryzyka cyberbezpieczeństwa i uzasadnienia okresu wsparcia.
- Załącznik II zawiera informacje i instrukcje dla użytkowników.
- Załącznik VII określa treść dokumentacji technicznej.
- Artykuł 32 określa ścieżkę oceny zgodności po sklasyfikowaniu produktu.
- Normy zharmonizowane lub inne specyfikacje techniczne mogą pomóc wykazać spełnienie wymagań, ale ich skutek prawny zależy od ich statusu.
Znaczenie luki
Luka może dotyczyć produktu, procesu producenta lub dowodów potwierdzających wniosek. Na przykład mechanizm aktualizacji może nie weryfikować podpisu albo może istnieć, lecz brak wyniku testu potwierdzającego, że odrzuca zmodyfikowany pakiet. Te ustalenia wymagają różnych działań.
Luka w spełnieniu wymogu
Produkt lub proces nie spełnia jeszcze mającego zastosowanie wymogu.
Luka dowodowa
Produkt może zawierać wymagany środek, ale dokumentacja techniczna nie opisuje go wystarczająco jasno.
Luka analityczna
Brakuje oceny ryzyka lub uzasadnienia zastosowania wymogu albo są one zbyt ogólne dla danego produktu.
Luka w wyborze ścieżki
Przyjęto założenie dotyczące norm, certyfikacji lub ścieżki oceny zgodności, lecz nie potwierdzono go statusem źródła ani kategorią produktu.
Przykład: zamknięcie luki dotyczącej bezpiecznych aktualizacji
Fikcyjny sterownik już otrzymuje podpisane aktualizacje oprogramowania układowego, ale zespół nie sprawdził, czy urządzenie odrzuca obraz podpisany niezaufanym kluczem. Początkowo jest to luka dowodowa. Jeśli test wykaże, że urządzenie przyjmuje taki obraz, powstaje również luka we wdrożeniu.
- Podstawa: powiąż właściwe wymaganie załącznika I, ocenę ryzyka i projekt bezpiecznej aktualizacji. Wskaż dokładną wersję i konfigurację produktu.
- Ustalenie: opisz brakujący test albo zaobserwowane działanie. Oddziel nieprzetestowane założenie od wykazanej awarii.
- Działanie: zleć zespołowi oprogramowania układowego wdrożenie potrzebnych zmian, a zespołowi weryfikacji — przetestowanie dotkniętych ścieżek aktualizacji. Ustal termin realizacji odpowiedni do decyzji o wydaniu produktu.
- Dowody zamknięcia: dołącz poprawiony projekt lub odnośnik do zmiany, wyniki testów właściwej kompilacji i zaktualizowaną ocenę ryzyka. Uzasadnij, jeśli wcześniejszy wynik testu nadal jest miarodajny.
- Przegląd: odpowiedzialny recenzent porównuje pierwotną lukę z nowymi dowodami. Samo ukończenie zadania lub przesłanie raportu nie wykazuje, że lukę usunięto.
Dla każdej luki wskaż wymaganie i wyjaśnij, czego brakuje. Przydziel zadanie i określ wynik, który recenzent powinien uznać za wystarczający do zaakceptowania korekty. Zapisz wynik przeglądu wraz z dowodami.
Procent ukończenia odzwierciedla pozycje na danej liście kontrolnej. Nie pokazuje wagi pozostałych luk ani nie dowodzi zgodności. Nierozwiązany problem z uwierzytelnianiem aktualizacji może mieć większe znaczenie niż kilka ukończonych zadań dokumentacyjnych.
Dane wejściowe do analizy luk
Analiza luk wymaga określonego zakresu produktu oraz uzasadnionej klasyfikacji i ścieżki oceny zgodności. W przeciwnym razie może porównać produkt z nieobowiązującymi wymaganiami albo pominąć wymagania, które mają zastosowanie.
Ocena ryzyka jest głównym źródłem informacji przy ustalaniu, które wymagania dotyczące produktu z załącznika I mają zastosowanie. Dokumentacja techniczna gromadzi wynik i dowody. Zobacz Ocena ryzyka cyberbezpieczeństwa oraz Dokumentacja techniczna.