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
Załącznik I wymaga, aby producent identyfikował i dokumentował podatności oraz komponenty, w tym sporządzał SBOM obejmujący co najmniej zależności najwyższego poziomu.
Rejestry powinny pokazywać, jak oceniono podatności, jak na nie zareagowano i jak je usunięto oraz jak w razie potrzeby rozpowszechniono poprawki za pomocą aktualizacji zabezpieczeń.
Załącznik I wymaga polityki skoordynowanego ujawniania podatności. Załącznik VII wymaga tej polityki oraz dowodu istnienia adresu kontaktowego do zgłaszania podatności.
Załącznik I wymaga skutecznych i regularnych testów oraz przeglądów bezpieczeństwa produktu. Załącznik VII wymaga raportów z testów przeprowadzonych w celu weryfikacji zgodności produktu i procesó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.
- 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.
- 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ść.
- 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ą.
- 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.
- 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.
- 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.