Producent urządzenia z oprogramowaniem musi od 11 grudnia 2027 r. spełnić trzy grupy wymagań CRA: przeprowadzić ocenę ryzyka i zaprojektować produkt zgodnie z wymaganiami załącznika I, prowadzić obsługę podatności przez cały okres wsparcia oraz wykazać zgodność w dokumentacji i ocenie zgodności. Poniżej przekładamy te wymagania na język firmware, sprzętu i procesu wydawania.
- Punktem wyjścia jest ocena ryzyka w cyberprzestrzeni. To ona wskazuje, które wymagania załącznika I stosują się do produktu i jak.
- Załącznik I część I zawiera 13 wymagań dla produktu (lit. a–m), m.in. bezpieczną konfigurację domyślną, aktualizacje zabezpieczeń, kontrolę dostępu i ochronę danych.
- Załącznik I część II zawiera 8 wymagań dla procesu obsługi podatności, w tym SBOM, politykę skoordynowanego ujawniania podatności i bezpłatne aktualizacje zabezpieczeń.
- Okres wsparcia wynosi co najmniej 5 lat, chyba że produkt będzie używany krócej.
- Producent odpowiada także za komponenty stron trzecich, w tym open source.
Od czego zacząć? Od oceny ryzyka
Zacznij od oceny ryzyka w cyberprzestrzeni. To ona wskazuje, które wymagania załącznika I mają zastosowanie do Twojego urządzenia i w jaki sposób je spełniasz. Bez niej nie da się uzasadnić ani wyboru zabezpieczeń, ani tego, że któreś wymaganie nie dotyczy produktu.
CRA nie jest listą funkcji, które musi mieć każde urządzenie. Producent przeprowadza ocenę ryzyka w cyberprzestrzeni i uwzględnia jej wynik w planowaniu, projektowaniu, produkcji, dostarczaniu i utrzymaniu produktu (art. 13 ust. 2). Ocena opiera się na przeznaczeniu produktu, racjonalnie przewidywalnym użyciu i warunkach pracy, na przykład środowisku i chronionych zasobach.
W ocenie wskazuje się, które wymagania z załącznika I część I pkt 2 mają zastosowanie do produktu i jak są wdrożone. Jeśli jakieś wymaganie nie ma zastosowania, producent zapisuje wyraźne uzasadnienie w dokumentacji technicznej (art. 13 ust. 4). Ocenę aktualizuje się w okresie wsparcia.
Czujnik temperatury z Bluetooth LE zasilany baterią nie przechowuje danych osobowych, nie łączy się z internetem ani siecią lokalną i komunikuje się tylko przez Bluetooth LE. Ocena ryzyka może wykazać, że szyfrowanie danych w spoczynku nie ma tu zastosowania, bo czujnik nie przechowuje danych wymagających poufności. Nadal jednak trzeba rozstrzygnąć, kto może się z nim sparować, jak chronione są polecenia konfiguracyjne i jak trafia do niego nowy firmware.
Jakie wymagania musi spełnić produkt? Załącznik I część I
Produkt musi zapewniać poziom cyberbezpieczeństwa odpowiedni do ryzyka i, na podstawie oceny ryzyka, spełniać 13 wymagań z załącznika I część I. Dotyczą m.in. braku znanych podatności, bezpiecznej konfiguracji domyślnej, aktualizacji zabezpieczeń, kontroli dostępu, ochrony danych i ograniczenia powierzchni ataku. Tabela pokazuje, co zwykle oznaczają w urządzeniu wbudowanym. Prawa kolumna to przykłady rozwiązań, a nie lista wymagana przepisami.
| Lit. | Wymaganie | Co to zwykle oznacza w urządzeniu |
|---|---|---|
| a | Brak znanych podatności możliwych do wykorzystania w chwili udostępnienia | Skan zależności i przegląd znanych CVE przed wydaniem |
| b | Bezpieczna konfiguracja domyślna i możliwość przywrócenia stanu pierwotnego | Brak wspólnych haseł fabrycznych, zbędne usługi wyłączone, reset fabryczny |
| c | Usuwanie podatności przez aktualizacje zabezpieczeń, w stosownych przypadkach automatyczne i włączone domyślnie, z możliwością rezygnacji i odroczenia | Mechanizm aktualizacji firmware (np. OTA), powiadomienie o dostępnej aktualizacji |
| d | Ochrona przed nieuprawnionym dostępem i raportowanie o możliwym nieuprawnionym dostępie | Uwierzytelnianie w panelu, API i interfejsach serwisowych, zarządzanie uprawnieniami |
| e | Poufność danych przechowywanych, przesyłanych i przetwarzanych | Szyfrowana komunikacja, ochrona kluczy i danych w pamięci |
| f | Integralność danych, poleceń, programów i konfiguracji | Podpisany firmware, weryfikacja przy starcie i przy aktualizacji |
| g | Minimalizacja danych | Urządzenie i chmura zbierają tylko dane potrzebne do działania |
| h | Dostępność podstawowych funkcji, także po incydencie, odporność na ataki odmowy usługi | Podstawowa funkcja działa bez chmury, ograniczanie liczby żądań |
| i | Ograniczanie negatywnego wpływu na inne urządzenia i sieci | Urządzenie nie zalewa sieci ruchem przy błędzie lub ataku |
| j | Ograniczenie powierzchni ataku, w tym interfejsów zewnętrznych | Zamknięte porty debugowania, wyłączone nieużywane interfejsy |
| k | Ograniczanie skutków incydentu | Rozdzielenie uprawnień procesów, mechanizmy utrudniające wykorzystanie błędów |
| l | Rejestrowanie i monitorowanie zdarzeń istotnych dla bezpieczeństwa, z możliwością rezygnacji przez użytkownika | Dziennik logowań i zmian konfiguracji |
| m | Trwałe i bezpieczne usunięcie danych i ustawień przez użytkownika | Reset, który faktycznie kasuje dane i dane dostępowe |
Jakie obowiązki ma producent przy obsłudze podatności?
Producent musi prowadzić obsługę podatności według ośmiu wymagań z załącznika I część II: od SBOM i testów, przez politykę skoordynowanego ujawniania podatności, po bezzwłoczne i bezpłatne aktualizacje zabezpieczeń. Procesy muszą działać już w chwili wprowadzenia produktu do obrotu i przez cały okres wsparcia.
- Identyfikuj komponenty i podatności. Sporządź SBOM (wykaz komponentów oprogramowania) w powszechnie używanym formacie do odczytu maszynowego, co najmniej dla zależności najwyższego poziomu.
- Usuwaj podatności bez zwłoki. Jeśli to technicznie wykonalne, aktualizacje zabezpieczeń dostarczaj oddzielnie od aktualizacji funkcji.
- Testuj regularnie. Skuteczne i regularne testy oraz przeglądy bezpieczeństwa produktu.
- Informuj o naprawionych podatnościach. Po wydaniu aktualizacji opublikuj opis podatności, jej skutki, dotkliwość i informacje, które pomogą użytkownikom ją usunąć.
- Miej politykę skoordynowanego ujawniania podatności (CVD) i stosuj ją.
- Podaj adres do zgłaszania podatności.
- Dystrybuuj aktualizacje bezpiecznie.
- Udostępniaj aktualizacje zabezpieczeń bezzwłocznie i bezpłatnie, razem z informacją, co użytkownik ma zrobić. Wyjątek można uzgodnić z klientem biznesowym dla produktu wykonanego na zamówienie.
Osobnym obowiązkiem jest zgłaszanie aktywnie wykorzystywanych podatności i poważnych incydentów w terminach 24 i 72 godzin. Opisujemy go w artykule Zgłaszanie podatności i incydentów CRA.
Jak długo trzeba wspierać produkt i udostępniać aktualizacje?
Okres wsparcia wynosi co najmniej 5 lat, chyba że produkt z założenia będzie używany krócej. Producent określa go sam, według kryteriów z art. 13 ust. 8: okres ma odpowiadać czasowi używania produktu i uwzględniać m.in. uzasadnione oczekiwania użytkowników oraz charakter i przeznaczenie produktu. Szczegóły:
- Okres wsparcia wynosi co najmniej 5 lat. Krótszy jest dopuszczalny tylko wtedy, gdy produkt z założenia będzie używany krócej.
- Każda aktualizacja zabezpieczeń pozostaje dostępna co najmniej 10 lat od wydania albo do końca okresu wsparcia, zależnie od tego, który okres jest dłuższy.
- Data końca wsparcia (co najmniej miesiąc i rok) musi być jasno podana w chwili zakupu.
- Informacje, na podstawie których ustalono okres wsparcia, trafiają do dokumentacji technicznej.
Dla producenta elektroniki oznacza to decyzje biznesowe: jak długo utrzymywać środowisko budowania firmware, co zrobić z modułami, których dostawca kończy wsparcie, i ile kosztuje utrzymanie starszych wersji sprzętu.
Kto odpowiada za komponenty dostawców i open source?
Za zgodność całego produktu odpowiada producent, także w części zbudowanej z cudzych komponentów. CRA wymaga należytej staranności przy ich integrowaniu, a po wykryciu podatności w komponencie: zgłoszenia jej podmiotowi, który go utrzymuje, i usunięcia jej we własnym produkcie.
Urządzenie rzadko powstaje od zera. Moduł radiowy, SDK producenta układu, system operacyjny czasu rzeczywistego i biblioteki open source trafiają do produktu razem ze swoimi podatnościami. CRA wymaga należytej staranności przy integrowaniu komponentów stron trzecich, tak aby nie obniżały bezpieczeństwa produktu (art. 13 ust. 5). Dotyczy to także wolnego i otwartego oprogramowania.
Po wykryciu podatności w komponencie producent zgłasza ją podmiotowi, który komponent wytwarza lub utrzymuje, i usuwa ją w swoim produkcie (art. 13 ust. 6). W praktyce warto ustalić z dostawcami, jak długo wspierają komponent, jak informują o podatnościach i czy dostarczają własny SBOM.
Jakie informacje trzeba przekazać użytkownikowi?
Do produktu trzeba dołączyć informacje i instrukcje z załącznika II: dane producenta, punkt kontaktowy do zgłaszania podatności, przeznaczenie produktu, datę końca okresu wsparcia oraz instrukcje bezpiecznego uruchomienia, aktualizacji i wycofania z użytku. Poza danymi producenta są to m.in.:
- pojedynczy punkt kontaktowy do zgłaszania podatności i miejsce publikacji polityki CVD,
- przeznaczenie produktu i informacje o zabezpieczeniach,
- okoliczności, które mogą powodować istotne ryzyko,
- rodzaj wsparcia technicznego w zakresie bezpieczeństwa i data końca okresu wsparcia,
- instrukcje bezpiecznego uruchomienia, instalowania aktualizacji i wycofania z użytku, w tym usunięcia danych.
Co powinien zrobić producent?
Producent urządzenia powinien przeprowadzić ocenę ryzyka, porównać produkt z 13 wymaganiami, sprawdzić ścieżkę aktualizacji, wdrożyć SBOM i obsługę zgłoszeń podatności oraz ustalić okres wsparcia. Zmiany w sprzęcie i firmware najlepiej wpisać do planu kolejnej wersji produktu.
- Przeprowadź ocenę ryzyka produktu i zapisz, które wymagania załącznika I mają zastosowanie.
- Porównaj produkt z 13 wymaganiami. Braki, które wymagają zmian w sprzęcie lub firmware, wpisz do planu kolejnej wersji.
- Sprawdź ścieżkę aktualizacji. Czy każde urządzenie w terenie da się zaktualizować, czy firmware jest podpisany i kto ma dostęp do kluczy.
- Zbuduj SBOM w procesie budowania i ustal, kto śledzi podatności w komponentach.
- Przygotuj politykę CVD, adres kontaktowy i procedurę obsługi zgłoszeń.
- Ustal okres wsparcia i sprawdź, czy dostawcy kluczowych komponentów wspierają je równie długo.
- Zbieraj dowody na bieżąco. Wyniki testów i decyzje projektowe trafią do dokumentacji technicznej.
Nie wiesz, których wymagań Twój produkt jeszcze nie spełnia? Analiza luk jest częścią diagnozy CRA.
Zobacz zakres diagnozy