CRA wymaga, żeby podatności w produkcie dało się usuwać aktualizacjami zabezpieczeń, a producent dostarczał je bezzwłocznie, bezpłatnie i bezpiecznym kanałem przez cały okres wsparcia. W stosownych przypadkach aktualizacje mają instalować się automatycznie, z możliwością rezygnacji. Jeśli to technicznie wykonalne, aktualizacje zabezpieczeń dostarcza się oddzielnie od aktualizacji funkcji. Sposób realizacji, na przykład OTA, wybiera producent.
- Produkt ma umożliwiać usuwanie podatności przez aktualizacje zabezpieczeń (załącznik I część I pkt 2 lit. c).
- Aktualizacje zabezpieczeń udostępnia się bezzwłocznie i bezpłatnie, z informacją dla użytkownika, co ma zrobić.
- Dystrybucja musi być bezpieczna, a integralność oprogramowania chroniona przed nieuprawnioną modyfikacją.
- Każda aktualizacja zabezpieczeń pozostaje dostępna co najmniej 10 lat od wydania albo do końca okresu wsparcia, jeśli trwa on dłużej.
- Aktualizacja zabezpieczeń, która nie zmienia przeznaczenia produktu, nie jest istotną modyfikacją.
Czego CRA wymaga od aktualizacji?
CRA stawia wymagania w dwóch miejscach załącznika I. Część I dotyczy produktu: ma umożliwiać usuwanie podatności przez aktualizacje zabezpieczeń i chronić integralność oprogramowania. Część II dotyczy producenta: ma usuwać podatności bez zwłoki, bezpiecznie dystrybuować aktualizacje, udostępniać je bezpłatnie i informować użytkowników.
| Wymaganie | Przepis | Co zwykle oznacza w urządzeniu |
|---|---|---|
| Podatności można usuwać aktualizacjami zabezpieczeń, w stosownych przypadkach automatycznymi i włączonymi domyślnie | Zał. I cz. I pkt 2 lit. c | Mechanizm zdalnej aktualizacji firmware, ustawienia aktualizacji dostępne dla użytkownika |
| Ochrona integralności programów i konfiguracji przed nieuprawnioną modyfikacją | Zał. I cz. I pkt 2 lit. f | Podpis cyfrowy firmware i jego weryfikacja przed instalacją i przy starcie |
| Bezzwłoczne usuwanie podatności, w miarę możliwości oddzielnie od aktualizacji funkcji | Zał. I cz. II pkt 2 | Osobna gałąź poprawek bezpieczeństwa, wydania poza cyklem funkcjonalnym |
| Bezpieczna dystrybucja aktualizacji | Zał. I cz. II pkt 7 | Szyfrowany i uwierzytelniony kanał, kontrola dostępu do serwera aktualizacji i kluczy |
| Aktualizacje bezzwłocznie i bezpłatnie, z komunikatem doradczym | Zał. I cz. II pkt 8 | Informacja o wydaniu z opisem, co użytkownik ma zrobić |
| Informacja o naprawionych podatnościach po wydaniu aktualizacji | Zał. I cz. II pkt 4 | Biuletyn bezpieczeństwa z opisem podatności, skutków i dotkliwości |
Czy aktualizacje muszą być automatyczne?
W stosownych przypadkach tak. Automatyczne aktualizacje zabezpieczeń mają być wtedy włączone domyślnie, z jasnym i łatwym mechanizmem rezygnacji, powiadomieniem o dostępnej aktualizacji i możliwością tymczasowego odroczenia instalacji. O tym, czy przypadek jest „stosowny”, decyduje ocena ryzyka i charakter produktu, a wybór trzeba uzasadnić w dokumentacji.
Motyw 56 podaje wskazówki. Automatyczne powiadamianie, pobieranie i instalacja są oczekiwane zwłaszcza w towarach konsumenckich. Wymóg nie dotyczy produktów, które mają przede wszystkim stanowić komponenty innych produktów, ani produktów, w których użytkownicy z zasady nie spodziewają się automatycznych aktualizacji, w tym przeznaczonych do profesjonalnych sieci ICT oraz środowisk krytycznych i przemysłowych. Tam nieplanowany restart sterownika może być większym ryzykiem niż opóźniona poprawka.
Dlaczego aktualizacje zabezpieczeń mają być oddzielone od funkcji?
Żeby użytkownik nie musiał instalować nowych funkcji tylko po to, by dostać poprawkę bezpieczeństwa (motyw 57). Wymóg obowiązuje, jeśli jest to technicznie wykonalne. W praktyce oznacza to utrzymywanie gałęzi poprawek dla wspieranych wersji i możliwość wydania samej poprawki bez czekania na kolejną wersję funkcjonalną.
Jak długo aktualizacje mają być dostępne?
Producent dostarcza aktualizacje zabezpieczeń przez okres wsparcia, który wynosi co najmniej 5 lat, chyba że produkt z założenia będzie używany krócej. Każda wydana 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 (art. 13 ust. 9).
Jeżeli producent wprowadził do obrotu kolejne, istotnie zmodyfikowane wersje oprogramowania, może dostarczać poprawki tylko do najnowszej z nich, pod warunkiem że użytkownicy starszych wersji mają do niej bezpłatny dostęp i nie ponoszą dodatkowych kosztów dostosowania sprzętu lub oprogramowania (art. 13 ust. 10).
Czy aktualizacja jest istotną modyfikacją?
Aktualizacja zabezpieczeń, która ma zmniejszyć ryzyko i nie zmienia przeznaczenia produktu, nie jest istotną modyfikacją. Istotną modyfikacją jest zmiana, która wpływa na zgodność z wymaganiami załącznika I część I albo zmienia przeznaczenie, dla którego produkt oceniono. Wtedy trzeba sprawdzić zgodność zmodyfikowanego produktu i w stosownych przypadkach przeprowadzić nową ocenę zgodności (motyw 41).
Motyw 39 podaje przykłady. Drobne aktualizacje funkcjonalności, takie jak ulepszenia wizualne czy nowe języki interfejsu, zasadniczo nie są istotną modyfikacją. Dodanie funkcji, która zmienia pierwotnie zamierzone funkcje produktu i poszerza płaszczyznę ataku, może nią być. Nie ma znaczenia, czy taką zmianę dostarczono osobno, czy razem z aktualizacją zabezpieczeń.
Producent kamer wydaje wersję 2.3.1, która usuwa błąd w obsłudze logowania. Przeznaczenie kamery się nie zmienia, więc to aktualizacja zabezpieczeń, a nie istotna modyfikacja. Producent aktualizuje SBOM i dokumentację dla nowej wersji.
W wersji 3.0 dodaje zdalny dostęp przez chmurę, którego wcześniej nie było. Pojawia się nowy interfejs zewnętrzny i nowe ryzyko. Producent musi sprawdzić, czy to istotna modyfikacja, zaktualizować ocenę ryzyka i w razie potrzeby powtórzyć ocenę zgodności.
Na co uważać przy projektowaniu ścieżki aktualizacji?
Ścieżka aktualizacji jest jednocześnie zabezpieczeniem i celem ataku. Przejęcie serwera aktualizacji albo klucza do podpisywania firmware pozwala wprowadzić złośliwy kod do wszystkich urządzeń i może być poważnym incydentem w rozumieniu art. 14 ust. 5 (motyw 68). Wtedy producent wysyła wczesne ostrzeżenie w 24 godziny i zgłoszenie w 72 godziny. Poniższe punkty to praktyka inżynierska, a nie wymóg wyrażony wprost w przepisach.
- Podpis i weryfikacja. Urządzenie instaluje tylko firmware podpisany przez producenta.
- Ochrona kluczy. Klucz do podpisywania jest przechowywany poza serwerem budowania, z ograniczonym dostępem.
- Ochrona przed cofnięciem wersji. Atakujący nie może wgrać starszej, podatnej wersji.
- Odporność na przerwanie. Utrata zasilania w trakcie aktualizacji nie unieruchamia urządzenia.
- Zasięg. Wiadomo, które urządzenia w terenie mają którą wersję i ile z nich aktualizację faktycznie zainstalowało.
- Urządzenia bez łączności. Dla nich potrzebna jest opisana procedura aktualizacji lokalnej.
Co powinien zrobić producent?
Producent powinien sprawdzić, czy każde urządzenie w okresie wsparcia da się zaktualizować, zabezpieczyć kanał i klucze, rozdzielić wydania bezpieczeństwa od funkcjonalnych oraz spisać zasady: kto decyduje o wydaniu poprawki, w jakim czasie i jak informuje się użytkowników. Decyzję o automatycznych aktualizacjach trzeba uzasadnić w ocenie ryzyka.
- Zrób przegląd ścieżki aktualizacji każdego modelu: mechanizm, podpis, kanał, zachowanie przy błędzie.
- Zdecyduj o trybie automatycznym na podstawie oceny ryzyka i zapisz uzasadnienie.
- Zapewnij możliwość wydania samej poprawki dla każdej wspieranej wersji.
- Spisz zasady wydawania aktualizacji zabezpieczeń: role, terminy, testy, komunikat dla użytkowników.
- Opisz w instrukcji, jak instalować aktualizacje i jak wyłączyć automatyczną instalację (załącznik II).
- Zaplanuj archiwum aktualizacji na co najmniej 10 lat i utrzymanie środowiska budowania przez okres wsparcia.
Aktualizacje są jednym z elementów obsługi podatności, którą opisuje artykuł Zarządzanie podatnościami w CRA. Pozostałe wymagania wobec urządzenia znajdziesz w artykule CRA dla producentów IoT i elektroniki.