Rejestry obsługi podatności CRA

Sytance · Zaktualizowano

Rejestry obsługi podatności pokazują, jak producent wykrywa, dokumentuje, ocenia, usuwa, ujawnia i komunikuje podatności w okresie wsparcia.

Obowiązek dotyczący procesu

W chwili wprowadzenia produktu z elementami cyfrowymi do obrotu i przez cały okres wsparcia producenci zapewniają skuteczną obsługę podatności tego produktu, w tym jego komponentów, zgodnie z zasadniczymi wymogami cyberbezpieczeństwa określonymi w części II załącznika I.

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

Obowiązek rozpoczyna się w chwili wprowadzenia produktu do obrotu i trwa przez okres wsparcia. Dotyczy produktu i jego komponentów.

Główne rodzaje rejestrów

Przykład: od alertu dotyczącego komponentu do zamknięcia sprawy

Rozważmy fikcyjną podatność parsera w wydaniu oprogramowania układowego sterownika. Poniższych sześć rejestrów tworzy przykładową historię przypadku. Pokazują one, jak zespół może powiązać przyjęcie zgłoszenia, wpływ na produkt i usunięcie podatności; nie jest to formularz wymagany przez CRA.

  1. Przyjęcie: zapisz datę otrzymania zgłoszenia, jego źródło, komponent i identyfikator podatności oraz informacje dostępne w danym momencie. Zachowaj oryginalne zgłoszenie.
  2. Wpływ na produkt: wykorzystaj SBOM i rejestry kompilacji do zidentyfikowania potencjalnie dotkniętych wydań. Dla każdej wspieranej konfiguracji sprawdź, czy atakujący może dotrzeć do podatnego parsera; zapisz zarówno dowody, jak i pozostałą niepewność.
  3. Decyzja dotycząca zgłoszenia: niezwłocznie oceń obowiązki z art. 14, jeśli istnieją dowody aktywnego wykorzystania podatności lub poważnego incydentu dotyczącego bezpieczeństwa produktu. Zapisz czas uzyskania wiedzy i złóż wymagane zgłoszenia w odpowiednich terminach, kontynuując analizę techniczną.
  4. Postępowanie: oceń ryzyko dla produktu, przydziel zadanie opracowania poprawki lub środka ograniczającego skutki i — w stosownych przypadkach — skoordynuj działania z opiekunem komponentu. Zachowaj wybrane działanie i jego uzasadnienie.
  5. Weryfikacja i wydanie: przetestuj poprawiony parser i powiązane funkcje produktu, zachowaj informacje o przetestowanej kompilacji oraz dołącz odnośniki do aktualizacji zabezpieczeń, dowodów dystrybucji i instrukcji dla użytkownika.
  6. Zamknięcie i dalsze działania: zapisz zweryfikowany wynik, zaktualizowany wykaz komponentów, komunikację z użytkownikami i ujawnienie podatności. Każdą nadal wspieraną wersję, której dotyczy problem i dla której brak skutecznego środka zaradczego, pozostaw otwartą do dalszych działań.

Rejestr przypadku powinien odróżniać zakończenie wewnętrznych prac nad poprawką, złożenie wymaganego zgłoszenia oraz dostarczenie lub zainstalowanie aktualizacji. Na przykład poprawka może być już opublikowana, choć część użytkowników, których dotyczy problem, nadal musi ją zainstalować i wymaga dalszych działań.

Powiązanie z załącznikiem VII

Załącznik VII wymaga, aby dokumentacja techniczna obejmowała niezbędne informacje i specyfikacje procesów obsługi podatności, w tym SBOM, politykę skoordynowanego ujawniania, kontaktowy adres zgłoszeń i bezpieczną dystrybucję aktualizacji.

  • rejestry wspierające historię podatności produktu;
  • rejestry wyjaśniające sposób wstępnej oceny i usuwania podatności;
  • rejestry potwierdzające dystrybucję aktualizacji i komunikację z użytkownikami;
  • raporty z testów i przeglądów wspierające ocenę zgodności.

Projekt prEN 40000-1-3 dokładniej opisuje aktualny projekt normy dotyczącej obsługi podatności.

Rejestry nie uruchamiają obowiązku zgłoszenia

Rejestry te wspierają obsługę podatności. Zgłaszanie na podstawie art. 14 jest odrębnym obowiązkiem uruchamianym przez aktywnie wykorzystywane podatności i poważne incydenty dotyczące bezpieczeństwa produktu.

Źródła