W tym przewodniku opisano zalecane przez Google najlepsze praktyki dotyczące stosowania poprawek zabezpieczeń ocenianych przez pakiet testów zgodności systemu Android (CTS). Jest przeznaczony dla producentów sprzętu OEM zgodnego z Androidem (producentów), który będzie objęty wsparciem dłużej niż trzy lata, takiego jak pojazdy, telewizory, dekodery i sprzęt gospodarstwa domowego. Ten przewodnik nie jest przeznaczony dla użytkowników końcowych (na przykład właścicieli pojazdów).
Podziękowania i zastrzeżenia
Ten przewodnik nie jest prawnie ani umownie wiążący firmy Google ani innych producentów i nie ma stanowić zbioru wymagań. Niniejszy przewodnik jest raczej pomocą instruktażową opisującą zalecane praktyki.
Informacja zwrotna
Ten przewodnik nie ma charakteru wyczerpującego; planowane są dodatkowe poprawki. Prześlij opinię na adres producencki-guide-android@googlegroups.com.
Słowniczek
| Termin | Definicja |
|---|---|
| AKC | Zobowiązanie dotyczące zgodności z Androidem. Dawniej znana jako Umowa przeciw fragmentacji Androida (AFA). |
| AOSP | Projekt Open Source dla Androida |
| ASB | Biuletyn dotyczący bezpieczeństwa Androida |
| BSP | Pakiet wsparcia zarządu |
| CDD | Dokument definicji kompatybilności |
| CTS | Zestaw testów zgodności |
| FOTA | oprogramowanie sprzętowe drogą bezprzewodową |
| GPS | Globalny System Pozycjonowania |
| MISRA | Stowarzyszenie na rzecz Niezawodności Oprogramowania Przemysłu Motoryzacyjnego |
| NIST | Narodowy Instytut Standardów i Technologii |
| Obd | diagnostyka pokładowa ( OBD-II to ulepszenie w stosunku do OBD-I zarówno pod względem możliwości, jak i standaryzacji ) |
| OEM | producent oryginalnego Wyposażenia |
| system operacyjny | system operacyjny |
| SEI | Instytut Inżynierii Oprogramowania |
| SoC | system na chipie |
| MACZANKA | rozpoczęcie produkcji |
| SPL | Poziom poprawki zabezpieczeń |
| TPMS | system monitorowania ciśnienia opon |
O systemie operacyjnym Android
Android to pełny pakiet oprogramowania typu open source, oparty na systemie Linux, przeznaczony dla różnych urządzeń i o różnych kształtach. Od swojej pierwszej wersji w 2008 roku Android stał się najpopularniejszym systemem operacyjnym (OS), obsługującym ponad 1,4 miliarda urządzeń na całym świecie (2016). Około 67% tych urządzeń korzysta z systemu Android 5.0 (Lollipop) lub nowszego według stanu na marzec 2017 r. (nowsze dane są dostępne w panelu kontrolnym Androida ). Choć zdecydowana większość urządzeń to telefony komórkowe i tablety, Android staje się coraz powszechniejszy w smartwatchach, telewizorach i samochodowych urządzeniach informacyjno-rozrywkowych (IVI).
Liczba aplikacji na Androida dostępnych w sklepie Google Play osiągnęła ponad 2,2 miliona (2016). Tworzenie aplikacji na Androida jest wspierane przez program zgodności z systemem Android, który definiuje zestaw wymagań za pośrednictwem dokumentu definicji zgodności (CDD) i udostępnia narzędzia testowe za pośrednictwem pakietu testów zgodności (CTS) . Programy zgodności z systemem Android zapewniają, że każda aplikacja na Androida może działać na dowolnym urządzeniu zgodnym z Androidem, które obsługuje wymagane funkcje aplikacji.
Google regularnie publikuje nowe wersje systemu operacyjnego, aktualizacje zabezpieczeń systemu operacyjnego oraz informacje o wykrytych lukach. Producenci powinni zapoznać się z Biuletynem zabezpieczeń systemu Android pod kątem możliwości zastosowania tych aktualizacji w produktach obsługiwanych przez system operacyjny Android. Aby zapoznać się z przeglądem zabezpieczeń, zgodności i systemów kompilacji Androida, zobacz:
- Zabezpiecz urządzenie z Androidem
- Aktualizacje i zasoby dotyczące zabezpieczeń
- Zestaw testów zgodności
- Nazwy kodowe, znaczniki i numery kompilacji
Informacje o pojazdach połączonych (kanoniczne produkty o długiej żywotności)
Pojazdy zaczęto łączyć z wprowadzeniem radia AM w latach dwudziestych XX wieku. Od tego momentu liczba zewnętrznych połączeń fizycznych i bezprzewodowych zaczęła rosnąć, gdy organy regulacyjne i producenci samochodów zwrócili się ku elektronice, aby ułatwić diagnostykę i serwis (na przykład port OBD-II), poprawić bezpieczeństwo (na przykład TPMS) i osiągnąć cele w zakresie oszczędności paliwa . Następna fala łączności wprowadziła funkcje zwiększające wygodę kierowcy, takie jak zdalny dostęp bezkluczykowy, systemy telematyczne i zaawansowane funkcje informacyjno-rozrywkowe, takie jak Bluetooth, Wi-Fi i projekcja smartfona. Obecnie zintegrowane czujniki i łączność (na przykład GPS) wspierają systemy bezpieczeństwa i półautonomicznej jazdy.
Wraz ze wzrostem liczby połączeń pojazdów zwiększa się obszar potencjalnej powierzchni ataku pojazdu. Połączenia niosą ze sobą podobny zbiór problemów związanych z cyberbezpieczeństwem, jak w przypadku elektroniki użytkowej. Jednakże, chociaż ponowne uruchamianie, codzienne aktualizacje poprawek i niewyjaśnione zachowania są normą w elektronice użytkowej, są one niespójne w przypadku produktów z systemami krytycznymi dla bezpieczeństwa, takimi jak pojazdy.
Producenci muszą przyjąć proaktywne podejście, aby zapewnić ciągłe bezpieczeństwo produktu w terenie. Krótko mówiąc, producenci muszą być świadomi znanych luk w zabezpieczeniach produktu i stosować podejście oparte na ryzyku, aby je wyeliminować.
Zapewnij długoterminowe bezpieczeństwo
Podłączony pojazd często ma jedną lub więcej elektronicznych jednostek sterujących (ECU), które zawierają wiele komponentów oprogramowania, takich jak system operacyjny, biblioteki, narzędzia itp. Producenci powinni śledzić takie komponenty i identyfikować znane opublikowane luki w zabezpieczeniach za pomocą proaktywnej analizy, w tym:
- Regularna ocena produktu pod kątem bazy danych Common Vulnerabilities and Exposures (CVE).
- Gromadzenie informacji wywiadowczych na temat luk w zabezpieczeniach związanych z produktami.
- Testowanie bezpieczeństwa.
- Aktywnie analizuję biuletyny dotyczące bezpieczeństwa Androida.
Przykładowe aktualizacje systemu operacyjnego i poprawek zabezpieczeń (IVI z systemem Android):
Rysunek 1. Przykładowe wdrażanie głównych aktualizacji systemu operacyjnego i zabezpieczeń w całym okresie eksploatacji pojazdu.
| # | Krok | Zajęcia |
|---|---|---|
① | Oddział Rozwoju | Producent wybiera wersję Androida (Android X). W tym przykładzie „Android X” stanie się podstawą tego, co będzie dostarczane w pojeździe na dwa lata przed początkowym rozpoczęciem produkcji (SOP). |
| ② | Pierwsze uruchomienie | Na kilka miesięcy przed tym, jak Android X stanie się pierwszą wersją systemu operacyjnego dostarczoną w produkcie, aktualizacje zabezpieczeń są pobierane z biuletynów zabezpieczeń systemu Android (ASB) i potencjalnie innych źródeł uznawanych przez producenta za cenne. y2 = drugi biuletyn bezpieczeństwa dla wersji X systemu Android, zastosowany (backportowany) przez producenta do systemu Android X. Ta aktualizacja jest dostarczana w produkcie, a zegar produkcyjny rozpoczyna się w roku zerowym w przypadku systemu Android X.y2. W tym przykładzie producent podjął decyzję o nie dostarczaniu nowszej rocznej wersji Androida X+1. Powody wysłania najnowszej wersji obejmują dodanie nowych funkcji, usunięcie nowych luk w zabezpieczeniach i/lub udostępnienie usług Google lub innych firm, które wymagają nowszej wersji Androida. Powodem niezastosowania się do najnowszej wersji jest brak czasu nieodłącznie związany z procesem opracowywania i wprowadzania na rynek pojazdu, wymaganym do integracji, testowania i walidacji zmian, w tym zgodności ze wszystkimi wymogami regulacyjnymi i certyfikacyjnymi. |
| ③ | Pełna aktualizacja systemu operacyjnego | Po zakończeniu procedury SOP producent udostępnia aktualizację systemu operacyjnego Android X+2, czyli dwie wersje systemu Android po wersji używanej w produkcie początkowym (Android X0). Aktualizacje zabezpieczeń ASB są dostępne dla poziomu API (od daty wydania), więc aktualizacja wychodzi jako X+2.y0 około 1,25 roku po SOP. Ta aktualizacja systemu operacyjnego może, ale nie musi, być kompatybilna z produktami dostępnymi na rynku. Jeżeli tak, można stworzyć plan aktualizacji wdrożonych pojazdów. O ile nie zawarto innych umów biznesowych, decyzja o dokonaniu pełnej aktualizacji systemu operacyjnego leży wyłącznie w gestii producenta. |
| ④ | Aktualizacja zabezpieczeń | Dwa lata po rozpoczęciu produkcji pojazdu producent łata system operacyjny Android X+2. Decyzja ta opiera się na ocenie ryzyka dokonanej przez producenta. Producent jako podstawę aktualizacji wybiera trzecią aktualizację zabezpieczeń ASB dla wersji X+2. Produkty otrzymujące aktualizację zabezpieczeń mają teraz poziom poprawek zabezpieczeń (X+2.y3) systemu operacyjnego i Androida. Chociaż producenci mogą wybierać indywidualne poprawki zabezpieczeń z dowolnego ASB, muszą naprawić wszystkie wymagane problemy w biuletynie, aby móc korzystać z poziomu poprawek zabezpieczeń systemu Android (SPL) powiązanego z biuletynem (na przykład 2017-02-05). Za udostępnienie wersji backportowej i zabezpieczeń dla obsługiwanego produktu odpowiada producent. |
| ⑤ | Pełna aktualizacja systemu operacyjnego | Powtórzenie kroku 3 (pełna aktualizacja systemu operacyjnego) i druga pełna aktualizacja systemu operacyjnego wprowadzają produkt do systemu Android X+4 po trzech latach okresu produkcyjnego pojazdu. Producent równoważy obecnie nowsze wymagania sprzętowe najnowszej wersji Androida ze sprzętem zawartym w produkcie, dzięki czemu użytkownik może korzystać ze zaktualizowanego systemu operacyjnego Android. Producent wypuszcza aktualizację bez aktualizacji zabezpieczeń, dlatego produkt jest obecnie na poziomie (X+4.y0) OS + Android Security Patch Level. W tym przykładzie, ze względu na ograniczenia sprzętowe, X+4 jest ostatnią główną wersją systemu Android dostarczoną dla tego produktu, chociaż oczekiwany okres eksploatacji pojazdu wynoszący ponad 6 lat nadal wymaga wsparcia w zakresie bezpieczeństwa. |
| ⑥ | Aktualizacja zabezpieczeń | Powtórzenie kroku 4 (Aktualizacja zabezpieczeń). Producent ma za zadanie pobrać aktualizacje zabezpieczeń ASB ze znacznie późniejszej wersji Androida (X+6) i przenieść część lub wszystkie te aktualizacje z powrotem do Androida X+4. Za łączenie, integrowanie i przeprowadzanie aktualizacji (lub zawieranie umów z stroną trzecią) odpowiada producent. Producent powinien także mieć świadomość, że problemy bezpieczeństwa w wersjach Androida, które nie są już obsługiwane, nie są objęte ASB. |
| ⑦ | Aktualizacja zabezpieczeń | Osiem lat od rozpoczęcia cyklu produkcyjnego pojazdu, cztery wydania Androida od ostatniej aktualizacji systemu operacyjnego w kroku 5 (pełna aktualizacja systemu operacyjnego) i dziesięć lat od specyfikacji Androida X, ciężar wyselekcjonowania i ponownego przenoszenia poprawek bezpieczeństwa spoczywa w całości na producencie wersje starsze niż trzy lata od publicznego wydania poziomu API. |
Najlepsze praktyki w zakresie bezpieczeństwa
Aby utrudnić narażenie bezpieczeństwa, Google zaleca i stosuje powszechnie przyjęte najlepsze praktyki w zakresie bezpieczeństwa i inżynierii oprogramowania, zgodnie z opisem w sekcji Wdrażanie zabezpieczeń .
Wytyczne dotyczące bezpieczeństwa
Zalecane praktyki dotyczące bezpieczeństwa obejmują:
- Korzystaj z najnowszych wersji bibliotek zewnętrznych i komponentów open source.
- Nie dołączaj natrętnych funkcji debugowania do wydanych wersji systemu operacyjnego.
- Usuń nieużywaną funkcjonalność (aby zmniejszyć niepotrzebną powierzchnię ataku).
- Stosuj zasadę najmniejszych uprawnień i inne sprawdzone metody tworzenia aplikacji na Androida .
Wytyczne dotyczące tworzenia oprogramowania
Zalecane praktyki bezpiecznego tworzenia oprogramowania w całym cyklu życia systemu obejmują:
- Wykonuj modelowanie zagrożeń, aby uszeregować i zidentyfikować zasoby, zagrożenia i potencjalne środki zaradcze.
- Przeprowadź przegląd architektury/projektu, aby zapewnić bezpieczny i solidny projekt.
- Wykonuj regularne przeglądy kodu, aby jak najszybciej zidentyfikować antywzorce i błędy.
- Projektuj, wdrażaj i uruchamiaj testy jednostkowe o dużym pokryciu kodu, w tym:
- Testowanie funkcjonalne (w tym negatywne przypadki testowe)
- Regularne testy regresyjne (aby mieć pewność, że naprawione błędy nie pojawią się ponownie)
- Testowanie fuzz (jako część zestawu testów jednostkowych)
- Użyj narzędzi do analizy statycznego kodu źródłowego (scan-build, lint itp.), aby zidentyfikować potencjalne problemy.
- Użyj narzędzi do dynamicznej analizy kodu źródłowego, takich jak AddressSanitizer, UndefiniBehaviorSanitizer i FORTIFY_SOURCE (dla komponentów natywnych), aby identyfikować i łagodzić potencjalne problemy podczas tworzenia systemu.
- Posiadaj strategię zarządzania kodem źródłowym oprogramowania i konfiguracją/wersją wydania.
- Posiadaj strategię zarządzania poprawkami w celu generowania i wdrażania poprawek oprogramowania.
Polityka backportów bezpieczeństwa
Obecnie Google zapewnia aktywną pomoc techniczną dotyczącą raportów dotyczących wykrytych i zgłoszonych luk w zabezpieczeniach przez trzy (3) lata od publicznego udostępnienia poziomu interfejsu API . Aktywne wsparcie polega na:
- Otrzymuj i badaj raporty o lukach w zabezpieczeniach.
- Twórz, testuj i publikuj aktualizacje zabezpieczeń.
- Zapewniaj cykliczne wydania aktualizacji zabezpieczeń i szczegóły biuletynów zabezpieczeń.
- Przeprowadź ocenę dotkliwości zgodnie z ustalonymi wytycznymi.
Po trzech latach od daty publicznego udostępnienia poziomu API Google zaleca następujące wytyczne:
- Skorzystaj z usług strony trzeciej (takiej jak dostawca SoC lub dostawca jądra), aby uzyskać wsparcie dla aktualizacji zabezpieczeń systemu operacyjnego starszych niż trzy lata od wydania interfejsu API.
- Skorzystaj z usług strony trzeciej, aby przeprowadzić przegląd kodu przy użyciu publicznie dostępnych ASB. Chociaż eksperci ASB identyfikują luki w aktualnie obsługiwanej wersji, producent może wykorzystać dostarczone informacje w celu porównania nowo wydanych aktualizacji z wersjami wcześniejszymi. Dane te można wykorzystać do przeprowadzenia analizy wpływu i potencjalnego wygenerowania podobnych poprawek dla wersji systemów operacyjnych starszych niż trzy lata od wydania interfejsu API.
- W razie potrzeby prześlij aktualizacje zabezpieczeń do projektu Android Open Source Project (AOSP).
- Producent musi koordynować obsługę aktualizacji zabezpieczeń dla kodu specyficznego dla dostawcy (na przykład zastrzeżonego kodu specyficznego dla urządzenia).
- Producent powinien dołączyć do grupy powiadomień NDA Android Security Bulletin Partner Preview (wymagane jest podpisanie umów prawnych takich jak Developer NDA). Biuletyny powinny zawierać:
- Ogłoszenia
- Podsumowanie problemów według poziomu poprawki, w tym CVE i ważności
- W stosownych przypadkach szczegóły dotyczące luk w zabezpieczeniach
Dodatkowe referencje
Instrukcje dotyczące bezpiecznego kodowania i praktyk tworzenia oprogramowania można znaleźć w poniższych artykułach:
- Stowarzyszenie na rzecz Niezawodności Oprogramowania Przemysłu Motoryzacyjnego (MISRA) .
- Narzędzia i metody Instytutu Inżynierii Oprogramowania (SEI) .
- Narodowy Instytut Standardów i Technologii (NIST).
Zalecane praktyki produktowe
Google zachęca do stosowania poniższych zalecanych praktyk.
Ogólne wytyczne dotyczące uruchamiania
Ogólnie zaleca się, aby każdy podłączony produkt był uruchamiany z najnowszą wersją systemu operacyjnego, a producent powinien spróbować użyć najnowszej wersji systemu operacyjnego przed uruchomieniem produktu. Chociaż zablokowanie wersji jest konieczne, aby zapewnić stabilność przed testowaniem i walidacją, producent musi zrównoważyć stabilność produktu uzyskaną dzięki starszym wersją systemu operacyjnego z nowszymi wersjami systemu operacyjnego, które mają mniej znanych luk w zabezpieczeniach i ulepszone zabezpieczenia.
Zalecane wytyczne obejmują:
- Ze względu na długi czas realizacji projektów nieodłącznie związany z procesem rozwoju pojazdów, producenci mogą być zobowiązani do wprowadzenia systemu operacyjnego w wersji n-2 lub starszej.
- Zachowaj zgodność ze zgodnością systemu Android dla każdej wydanej wersji systemu operacyjnego Android z kampanią bezprzewodową (OTA).
- Wdróż produkt Android Firmware z możliwością bezprzewodowej aktualizacji (FOTA), który umożliwia szybkie i przyjazne dla klienta aktualizacje. FOTA należy przeprowadzić, stosując najlepsze praktyki bezpieczeństwa, takie jak podpisywanie kodu i połączenie TLS między produktem a zapleczem IT.
- Zgłaszaj niezależnie zidentyfikowane luki w zabezpieczeniach Androida do zespołu ds. bezpieczeństwa Androida.
Uwaga: firma Google rozważyła powiadomienia dotyczące typu urządzenia lub branży w biuletynach zabezpieczeń systemu Android. Ponieważ jednak Google nie zna jądra, sterowników ani chipsetów dla danego urządzenia (pojazdu, telewizora, urządzenia do noszenia, telefonu itp.), Google nie ma deterministycznego sposobu na oznaczenie dowolnego problemu bezpieczeństwa typem urządzenia .
Wytyczne dotyczące cyklu produktu
Producent powinien dołożyć wszelkich starań, aby podczas udoskonaleń cyklu produktu zastosować najnowszą wersję systemu operacyjnego lub aktualizacje zabezpieczeń dla używanej wersji. Aktualizacje można przeprowadzać w ramach cyklicznych, okresowych aktualizacji produktu lub w przypadku poprawek mających na celu rozwiązanie problemów z jakością i/lub innych problemów. Zalecane praktyki obejmują:
- Utwórz plan dotyczący aktualizacji sterowników, jądra i protokołów.
- Skorzystaj z odpowiedniej dla branży metody dostarczania aktualizacji wdrożonych pojazdów.
Dokument definicji zgodności (CDD)
Dokument definicji zgodności (CDD) opisuje wymagania, jakie należy spełnić, aby urządzenie było zgodne z systemem Android. CDD jest publiczny i dostępny dla każdego; możesz pobrać wersje CDD z Androida 1.6 do najnowszej wersji ze source.android.com .
Spełnienie tych wymagań wobec produktu obejmuje następujące podstawowe kroki:
- Partner podpisuje z Google zobowiązanie dotyczące zgodności z systemem Android (ACC). Następnie przydzielany jest konsultant ds. rozwiązań technicznych (TSC) w charakterze przewodnika.
- Partner kończy ocenę CDD dotyczącą wersji systemu operacyjnego Android produktu.
- Partner uruchamia i przesyła wyniki CTS (opisane poniżej), dopóki wyniki nie zostaną zaakceptowane pod kątem zgodności z systemem Android.
Zestaw testów zgodności (CTS)
Narzędzie testowe Compatibility Test Suite (CTS) sprawdza, czy wdrożenie produktu jest zgodne z systemem Android i czy zawiera najnowsze poprawki zabezpieczeń. CTS jest publicznym, otwartym kodem źródłowym i dostępnym dla każdego; możesz pobrać wersje CTS od Androida 1.6 do najnowszej wersji ze source.android.com .
Każda kompilacja oprogramowania Android udostępniona publicznie (obrazy instalacji fabrycznej i aktualizacji w terenie) musi potwierdzać zgodność z Androidem za pomocą wyników CTS. Na przykład, jeśli na urządzeniu działa system Android 7.1, podczas tworzenia i testowania obrazu kompilacji przeznaczonej do wydania należy odwołać się do najnowszej odpowiedniej wersji CDD 7.1 i CTS 7.1. Zdecydowanie zachęca się producentów do wczesnego i częstego korzystania z CTS w celu identyfikowania i naprawiania problemów.
Przebieg pracy CTS
Przepływ pracy w CTS obejmuje konfigurację środowiska testowego, uruchamianie testów, interpretację wyników i zrozumienie kodu źródłowego CTS. Poniższe wytyczne mają pomóc użytkownikom CTS (na przykład programistom, producentom) w efektywnym i wydajnym korzystaniu z CTS.
- Często przeprowadzaj testy . CTS został zaprojektowany jako zautomatyzowane narzędzie, które integruje się z systemem kompilacji. Częste uruchamianie CTS może pomóc w szybkim i wczesnym znajdowaniu defektów w przypadku wystąpienia degradacji lub regresji oprogramowania.
- Pobierz i sprawdź kod źródłowy CTS . Pełny kod źródłowy CTS to oprogramowanie typu open source, które każdy może pobrać i używać (pobrany kod źródłowy można w pełni zbudować i uruchomić). Jeśli test na urządzeniu zakończy się niepowodzeniem, sprawdzenie odpowiedniej sekcji kodu źródłowego może pomóc w ustaleniu przyczyny.
- Pobierz najnowszą wersję CTS . Nowe wersje Androida mogą aktualizować CTS za pomocą poprawek błędów, ulepszeń i nowych testów. Często sprawdzaj pliki do pobrania CTS i w razie potrzeby aktualizuj swój program CTS. Producent i Google uzgodnią, że wersja CTS będzie uwzględniana podczas wprowadzenia produktu na rynek, ponieważ produkt musi w pewnym momencie zostać zamrożony, podczas gdy CTS będzie nadal odświeżany.
Zdaj CTS
W przypadku produktu zgodnego z systemem Android Google zapewnia, że wyniki testów CTS urządzenia i raportów CTS Verifier są akceptowalne. W zasadzie wszystkie testy muszą przejść pomyślnie. Jednakże test, który zakończy się niepowodzeniem z przyczyn innych niż niezgodność urządzenia z wymaganiami dotyczącymi zgodności z systemem Android, podlega kontroli Google. Podczas tego procesu:
- Producent udostępnia Google proponowane łatki CTS, walidacje poprawek i uzasadnienia na poparcie swojej tezy.
- Google sprawdza przesłany materiał i jeśli zostanie zaakceptowany, aktualizuje odpowiednie testy CTS, aby urządzenie przeszło kolejną wersję CTS.
Jeśli test CTS nagle zakończy się niepowodzeniem po zastosowaniu poprawki zabezpieczeń, producent musi zmodyfikować poprawkę tak, aby nie zakłócała kompatybilności LUB wykazać, że test jest błędny i zapewnić poprawkę do testu (jak opisano powyżej).
CTS pozostaje otwarty na recenzje poprawek testowych. Na przykład Android 4.4 nadal akceptuje poprawki (patrz https://android-review.googlesource.com/#/c/273371/ ).
Często zadawane pytania (FAQ)
P: Kto jest odpowiedzialny za stosowanie aktualizacji zabezpieczeń w konkretnej implementacji systemu Android?
Odp.: Odpowiedzialność za to ponosi producent bezpośrednio dostarczający urządzenie. Podmiotem tym nie jest firma Google, która publikuje aktualizacje zabezpieczeń w AOSP i nie dla konkretnego urządzenia (np. pojazdu).
P: Jak Google radzi sobie z problemami bezpieczeństwa w systemie Android?
Odpowiedź: Google stale bada problemy i opracowuje potencjalne poprawki, które udostępnia dla wszystkich obsługiwanych poziomów API w ramach regularnego procesu aktualizacji zabezpieczeń. Od sierpnia 2015 r. Google regularnie publikuje biuletyny i linki do aktualizacji witryny source.android.com ; Google publikuje także aktualizacje zabezpieczeń w ramach głównych wydań systemów operacyjnych. Zobacz także zasady dotyczące backportów zabezpieczeń .
P: Jeśli producent zintegrował wszystkie poprawki AOSP z ASB, ale nie zintegrował poprawek od dostawcy BSP wymienionego w tym samym biuletynie, czy nadal może podnieść poziom bezpieczeństwa (na przykład zastosować odpowiednią poprawkę do platformy/kompilacji)?
Odp.: Aby zadeklarować poziom poprawki zabezpieczeń systemu Android (SPL), producent musi rozwiązać wszystkie wymagane problemy opublikowane w Biuletynie zabezpieczeń systemu Android ( w tym wcześniejsze biuletyny ) i przypisane do konkretnego pakietu SPL systemu Android. Na przykład producent korzystający z Biuletynu zabezpieczeń z marca 2017 r. (2017-03-01 SPL) rozwiązał wszystkie wymagane problemy udokumentowane w biuletynie z marca 2017 r. dla tej SPL oraz we wszystkich wcześniejszych aktualizacjach, w tym aktualizacjach specyficznych dla urządzenia we wszystkich wcześniejszych biuletynach zabezpieczeń Androida, w tym aktualizacje specyficzne dla urządzenia powiązane z SPL 2017-02-05.
P: Co się dzieje, gdy producent nie zgadza się z aktualizacjami zabezpieczeń dostarczonymi przez dostawcę BSP LUB gdy aktualizacje zabezpieczeń wymagane przez ASB nie są dostarczane przez dostawców?
O: ASB opisuje luki w zabezpieczeniach (wymienione w formie listy CVE) i często udostępnia pasujące testy bezpieczeństwa. Celem jest zapewnienie, że wymienione luki nie będą mogły być już powielane na urządzeniu i że urządzenie przejdzie powiązane testy bezpieczeństwa. W związku z tym problem nie polega na pobraniu aktualizacji zabezpieczeń dostarczonej przez Google lub zewnętrznego dostawcę, ale na poświadczeniu przez producenta, że urządzenie nie jest podatne na listę CVE w ASB. Producent może swobodnie korzystać z dostarczonych aktualizacji zabezpieczeń lub, jeśli ma zmianę, która jest bardziej odpowiednia dla jego urządzenia, zastosować ją zamiast tego.
Rozważmy na przykład przypadek, w którym Google usuwa lukę w zabezpieczeniach AOSP, zmieniając kod, dzięki czemu komponent pozostaje w pełni funkcjonalny i zgodny z CDD. Jeśli producent uzna, że komponent nie jest potrzebny w urządzeniu lub nie jest wymagany przez CDD (lub powiązane testy certyfikacyjne), może usunąć komponent, aby zmniejszyć przyszłe potrzeby serwisowe i zmniejszyć powierzchnię ataku. Chociaż producent nie zastosował dostarczonej aktualizacji zabezpieczeń, zapewnił, że urządzenie nie jest podatne na CVE udokumentowane w biuletynie bezpieczeństwa. Jednakże odstępując od zalecanej aktualizacji zabezpieczeń, producent ryzykuje nieprawidłowe rozwiązanie problemu, wprowadzenie nowych luk w zabezpieczeniach lub w inny sposób ograniczenie funkcjonalności ostatecznej wersji.
Chociaż współpracujemy ze wszystkimi partnerami SoC, aby zapewnić poprawki dla wszystkich problemów w ASB, zalecamy, aby producenci zawarli umowę serwisową ze swoimi dostawcami SoC na cały cykl życia urządzenia. SoC mogą przestać serwisować chipset wcześniej, niż jest to pożądane, dlatego zawarcie umów przed wyborem chipsetu urządzenia jest ważną częścią procesu wprowadzenia urządzenia na rynek.
Wreszcie, w przypadkach, gdy niemożliwe jest bezpośrednie zdobycie lub samodzielne utworzenie poprawki problemu udokumentowanego w ASB, producent może zachować wcześniejszą licencję SPL systemu Android i nadal dodawać nowe dostępne poprawki do kompilacji. Jednak taka praktyka ostatecznie doprowadzi do problemów z certyfikacją kompilacji (ponieważ Android zapewnia dostępność najnowszego poziomu poprawek zabezpieczeń na certyfikowanych urządzeniach). Google zaleca wcześniejszą współpracę z SoC, aby uniknąć tej praktyki.
P: Jeśli producent ustali, że element ASB nie ma zastosowania w przypadku jego produktu, czy nadal należy go zastosować lub załatać, aby spełnić inne wymagania Google lub przejść test CTS?
O: Nie wymagamy pobierania poprawek, aby zadeklarować poziom poprawek zabezpieczeń Androida (SPL). wymagamy, aby producent zaświadczył, że jego wersja nie jest podatna na ten problem.
Jednym z przykładów jest sytuacja, gdy łatany komponent nie istnieje w systemie producenta lub komponent został usunięty z systemu producenta w celu rozwiązania problemu. W takim przypadku system może być zgodny bez konieczności stosowania łatki przez producenta.
Różni się to zasadniczo od sytuacji, w której producent chce na przykład naprawiać tylko poprawki krytyczne, a nie pobierać innych odpowiednich poprawek, które mogłyby spowodować niepowodzenie testu bezpieczeństwa. W takim przypadku przyjmuje się, że SPL nie został spełniony.