Ten artykuł należy do cyklu o akcie o cyberodporności (CRA); kontekst znajdziesz we wprowadzeniu do CRA. CRA nie kończy się na momencie wprowadzenia produktu do obrotu — wymaga obsługi podatności przez cały okres wsparcia. To tu rozporządzenie najbardziej zmienia codzienną pracę zespołów produktowych.
Czego dotyczy Załącznik I część II CRA?
Załącznik I część II określa wymagania dotyczące postępowania producenta w przypadku wykrycia podatności produktu z elementami cyfrowymi.
O ile część I dotyczy cech samego produktu (zob. Zasadnicze wymagania w zakresie cyberbezpieczeństwa), o tyle część II reguluje procesy: identyfikowanie, dokumentowanie i usuwanie podatności w czasie. Zgodnie z art. 13 producent zapewnia skuteczne — i zgodne z wymaganiami Załącznika I część II — postępowanie z podatnościami przez cały okres wsparcia produktu. Czym jest ten okres i jak długo trwa, wyjaśniamy w artykule Obowiązki producentów i okres wsparcia (art. 13).
Co to jest SBOM i czy CRA go wymaga?
SBOM (software bill of materials) to zestawienie podstawowych materiałów do produkcji oprogramowania — wykaz komponentów i zależności wchodzących w skład produktu.
CRA posługuje się pojęciem zestawienia podstawowych materiałów do produkcji oprogramowania. SBOM służy identyfikowaniu i dokumentowaniu komponentów produktu, co jest warunkiem skutecznego zarządzania podatnościami — nie da się usunąć podatności w bibliotece, o której istnieniu się nie wie. Rozporządzenie odnosi się też do udostępniania informacji o tym, gdzie można uzyskać dostęp do takiego zestawienia. SBOM nabiera szczególnego znaczenia przy komponentach open source wbudowanych w produkt komercyjny — producent odpowiada za podatności w całym łańcuchu zależności.
Czym jest skoordynowane ujawnianie podatności?
Skoordynowane ujawnianie podatności to uporządkowany proces przyjmowania i obsługi zgłoszeń o podatnościach, tak aby zostały usunięte, zanim informacja o nich stanie się publiczna.
Zgodnie z art. 13 ust. 8 producent musi posiadać odpowiednią politykę i procedury, w tym politykę regulującą skoordynowane ujawnianie podatności, o której mowa w Załączniku I część II pkt 5 — do celów przetwarzania i eliminowania potencjalnych podatności zgłaszanych przez źródła wewnętrzne lub zewnętrzne. W praktyce oznacza to m.in. udostępnienie kanału zgłoszeń (np. polityki bezpieczeństwa, adresu kontaktowego dla badaczy).
Jakie procesy obejmuje postępowanie z podatnościami?
Postępowanie z podatnościami obejmuje ich identyfikację i dokumentowanie, usuwanie przez aktualizacje zabezpieczeń oraz informowanie o usuniętych podatnościach.
W szczególności obejmuje to następujące obszary:
- Identyfikacja i dokumentowanie
- Identyfikowanie i dokumentowanie podatności i komponentów produktu, w tym sporządzenie zestawienia podstawowych materiałów do produkcji oprogramowania (SBOM).
- Usuwanie bez zbędnej zwłoki
- Eliminowanie podatności bez zbędnej zwłoki, w tym przez dostarczanie aktualizacji zabezpieczeń.
- Testowanie i przeglądy
- Regularne testy i przeglądy bezpieczeństwa produktu.
- Informowanie i ujawnianie
- Publiczne udostępnianie informacji o usuniętych podatnościach oraz polityka skoordynowanego ujawniania podatności (część II pkt 5).
- Bezpieczna dystrybucja aktualizacji
- Bezpieczne rozpowszechnianie aktualizacji w celu terminowego usuwania podatności.
Jak postępowanie z podatnościami łączy się z obowiązkiem zgłaszania?
Obsługa podatności łączy się z odrębnym obowiązkiem sprawozdawczym: zgłaszaniem aktywnie wykorzystywanych podatności i poważnych incydentów.
To dwa powiązane, lecz odrębne reżimy. Postępowanie z podatnościami (Załącznik I część II) to proces wewnętrzny; zgłaszanie aktywnie wykorzystywanych podatności i poważnych incydentów (art. 14) to obowiązek wobec organów, z własnymi terminami (24 godziny / 72 godziny). Ten drugi omawiamy w artykule Zgłaszanie aktywnie wykorzystywanych podatności i poważnych incydentów. Warto zestawić to z analogicznym obowiązkiem wynikającym z KSC — terminy 24h, 72h i 1 miesiąc obowiązujące podmioty kluczowe i ważne są zbliżone, lecz mają inną podstawę prawną i adresata zgłoszenia.
Jak możemy Ci pomóc?
W Legal Geek pomagamy zaprojektować politykę postępowania z podatnościami i skoordynowanego ujawniania podatności zgodną z CRA, ustawić proces SBOM oraz powiązać go z obowiązkiem raportowania z art. 14. Dzięki temu zespół ma jeden, spójny obieg od zgłoszenia po aktualizację i — gdy trzeba — zawiadomienie organu.
Co dalej w cyklu?
- Akt o cyberodporności (CRA) — wprowadzenie
- Zasadnicze wymagania w zakresie cyberbezpieczeństwa — Załącznik I część I
- Zgłaszanie aktywnie wykorzystywanych podatności i poważnych incydentów
- Obowiązki producentów i okres wsparcia
- Wolne i otwarte oprogramowanie a CRA