Przewodnik dla producentów dotyczący długoterminowego bezpieczeństwa Androida

W tym przewodniku opisujemy sprawdzone metody zalecane przez Google w przypadku stosowania poprawek zabezpieczeń, które są oceniane przez pakiet testów zgodności Androida (CTS). Jest on przeznaczony dla producentów sprzętu OEM zgodnego z Androidem, który będzie obsługiwany dłużej niż 3 lata, np. pojazdów, telewizorów, dekoderów i sprzętu AGD. Ten przewodnik nie jest przeznaczony dla użytkowników (np. właścicieli pojazdów).

Podziękowania i wyłączenia odpowiedzialności

Ten przewodnik nie jest prawnie ani umownie wiążący dla Google ani innych producentów i nie ma charakteru zestawu wymagań. Ten przewodnik jest raczej materiałem instruktażowym, który opisuje zalecane praktyki.

Prześlij opinię

Ten przewodnik nie jest wyczerpujący. Planujemy wprowadzić w nim dodatkowe zmiany. Prześlij opinię na adres manufacturers-guide-android@googlegroups.com.

Słowniczek

Termin Definicja
ACC Zobowiązanie dotyczące zgodności z Androidem. Wcześniej znana jako umowa Android Anti-Fragmentation Agreement (AFA).
AOSP Projekt Android Open Source
ASB Biuletyn bezpieczeństwa w Androidzie
BSP Pakiet wsparcia platformy
CDD dokument definicji zgodności
CTS Compatibility Test Suite
FOTA bezprzewodowa aktualizacja oprogramowania
GPS globalny system pozycjonowania
MISRA Motor Industry Software Reliability Association
NIST Narodowy Instytut Standaryzacji i Technologii
OBD diagnostyka pokładowa (OBD-II jest ulepszoną wersją OBD-I pod względem możliwości i standaryzacji);
OEM producent oryginalnego sprzętu
System operacyjny system operacyjny
SEI Software Engineering Institute
SOC układ SOC
SOP początek produkcji,
SPL Poziom aktualizacji zabezpieczeń
TPMS system monitorowania ciśnienia w oponach,

Informacje o systemie operacyjnym Android

Android to pełny stos oprogramowania typu open source oparty na systemie Linux, przeznaczony na różne urządzenia i formaty. Od czasu pierwszej wersji w 2008 r. Android stał się najpopularniejszym systemem operacyjnym, który jest zainstalowany na ponad 1,4 mld urządzeń na całym świecie (2016 r.). Około 67% tych urządzeń korzystało w marcu 2017 r. z Androida 5.0 (Lollipop) lub nowszego (najnowsze dane są dostępne na panelu Androida). Większość urządzeń to telefony komórkowe i tablety, ale Android zyskuje popularność także na smartwatchach, telewizorach i urządzeniach IVI w samochodach.

Liczba aplikacji na Androida dostępnych w Sklepie Google Play osiągnęła ponad 2,2 miliona (2016 r.). Tworzenie aplikacji na Androida jest wspierane przez Program zgodności z Androidem, który określa zestaw wymagań w dokumencie definicji zgodności (CDD) i udostępnia narzędzia testowe w pakiecie testów zgodności (CTS). Programy zgodności z Androidem zapewniają, że każda aplikacja na Androida może działać na dowolnym urządzeniu zgodnym z Androidem, które obsługuje funkcje wymagane przez aplikację.

Google regularnie publikuje nowe wersje systemu operacyjnego, aktualizacje zabezpieczeń systemu operacyjnego i informacje o wykrytych lukach w zabezpieczeniach. Producenci powinni zapoznać się z Biuletynami bezpieczeństwa Androida, aby sprawdzić, czy te aktualizacje mają zastosowanie do obsługiwanych produktów z systemem operacyjnym Android. Informacje o zabezpieczeniach, zgodności i systemach kompilacji Androida znajdziesz w tych artykułach:

Informacje o połączonych pojazdach (kanonicznych produktach długoterminowych)

Pojazdy zaczęto łączyć z siecią wraz z wprowadzeniem radia AM w latach 20. XX wieku. Od tego momentu liczba zewnętrznych połączeń fizycznych i bezprzewodowych zaczęła rosnąć, ponieważ organy regulacyjne i producenci samochodów zaczęli wykorzystywać elektronikę, aby ułatwić diagnostykę i serwisowanie (np. port OBD-II), poprawić bezpieczeństwo (np. TPMS) i osiągnąć cele związane z oszczędnością paliwa. Kolejna fala łączności wprowadziła funkcje zwiększające wygodę kierowcy, takie jak zdalne sterowanie zamkami centralnymi, systemy telematyczne i zaawansowane funkcje informacyjno-rozrywkowe, takie jak Bluetooth, Wi-Fi i projekcja smartfona. Obecnie zintegrowane czujniki i łączność (np. GPS) obsługują systemy bezpieczeństwa i półautonomicznej jazdy.

Wraz ze wzrostem liczby połączeń z pojazdem rośnie obszar potencjalnego ataku na pojazd. Połączenia wiążą się z podobnymi problemami z cyberbezpieczeństwem jak w przypadku elektroniki użytkowej. Jednak w przypadku elektroniki użytkowej ponowne uruchamianie, codzienne aktualizacje i niewyjaśnione zachowania są normą, ale w przypadku produktów z systemami o krytycznym znaczeniu dla bezpieczeństwa, takich jak pojazdy, są one niespójne.

Producenci muszą aktywnie dbać o bezpieczeństwo i ochronę produktu w trakcie jego użytkowania. Krótko mówiąc, producenci muszą znać znane luki w zabezpieczeniach produktu i stosować podejście oparte na ocenie ryzyka, aby je eliminować.

Zapewnianie długoterminowego bezpieczeństwa

Połączony pojazd często ma co najmniej 1 elektroniczną jednostkę sterującą (ECU), która zawiera 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:

  • Regularne sprawdzanie produktu pod kątem typowych luk w zabezpieczeniach (CVE).
  • Zbieranie informacji o lukach w zabezpieczeniach związanych z produktami.
  • testy bezpieczeństwa,
  • Aktywnie analizujemy biuletyny bezpieczeństwa Androida.

Przykładowe aktualizacje systemu operacyjnego i poprawki zabezpieczeń (systemy IVI z Androidem):

Rysunek 1. Przykładowe wdrożenie głównych aktualizacji systemu operacyjnego i zabezpieczeń w okresie eksploatacji pojazdu.

# Krok Działania

①

 Gałąź Development Producent wybiera wersję Androida (Android X). W tym przykładzie „Android X” staje się podstawą tego, co zostanie dostarczone w pojeździe 2 lata przed rozpoczęciem produkcji (SOP).
② Wprowadzenie na rynek Kilka miesięcy przed tym, jak Android X stanie się pierwszą wersją systemu operacyjnego dostarczaną w produkcie, aktualizacje zabezpieczeń są pobierane z Biuletynów bezpieczeństwa Androida (ASB) i potencjalnie z innych źródeł uznanych przez producenta za wartościowe. y2 = drugi biuletyn bezpieczeństwa dla wersji X Androida, zastosowany (przeniesiony) przez producenta do Androida X. Ta aktualizacja jest dostarczana w ramach produktu, a zegar produkcji zaczyna tykać w roku 0 w przypadku Androida X.y2.

W tym przykładzie producent podjął decyzję, aby nie wprowadzać na rynek nowszej wersji Androida X+1. Powody wprowadzania najnowszej wersji to dodawanie nowych funkcji, usuwanie nowych luk w zabezpieczeniach lub udostępnianie usług Google lub innych firm, które wymagają nowszej wersji Androida. Powody przeciwko wysyłce z najnowszą wersją to brak czasu związany z procesem opracowywania i wprowadzania pojazdu na rynek, który jest wymagany do zintegrowania, przetestowania i zweryfikowania zmian, w tym zgodności ze wszystkimi wymaganiami regulacyjnymi i certyfikacyjnymi.
③ Pełna aktualizacja systemu operacyjnego Po zakończeniu okresu SOP producent udostępnia aktualizację systemu operacyjnego Android X+2, czyli 2 wersje Androida po wersji użytej w przypadku początkowego produktu (Android X0). Aktualizacje zabezpieczeń ASB są dostępne dla poziomu API (od daty wprowadzenia na rynek), więc aktualizacja jest wysyłana jako X+2.y0 około 1,25 roku po rozpoczęciu produkcji. Ta aktualizacja systemu operacyjnego może być zgodna z produktami w terenie lub nie. Jeśli tak jest, można utworzyć plan aktualizacji wdrożonych pojazdów.

O ile nie obowiązują inne umowy biznesowe, decyzja o przeprowadzeniu pełnej aktualizacji systemu operacyjnego zależy wyłącznie od producenta.
④ Aktualizacja zabezpieczeń Po 2 latach od rozpoczęcia produkcji pojazdu producent wprowadza poprawkę do systemu Android X+2. Ta decyzja jest podejmowana na podstawie oceny ryzyka przeprowadzonej przez producenta. Producent wybiera trzecią aktualizację zabezpieczeń ASB dla wersji X+2 jako podstawę aktualizacji. Urządzenia, na których zainstalowano aktualizację zabezpieczeń, mają teraz system operacyjny w wersji (X+2.y3) i poziom poprawek zabezpieczeń Androida.

Producenci mogą wybierać poszczególne poprawki zabezpieczeń z dowolnego Biuletynu bezpieczeństwa w Androidzie, ale aby używać poziomu poprawek zabezpieczeń w Androidzie powiązanego z biuletynem (np. 2017-02-05), muszą rozwiązać wszystkie wymagane problemy opisane w tym biuletynie. Za wykonanie portu wstecznego i wersji zabezpieczającej dla obsługiwanego produktu odpowiada producent.
⑤ Pełna aktualizacja systemu operacyjnego Powtórzenie kroku 3 (pełna aktualizacja systemu operacyjnego). Druga pełna aktualizacja systemu operacyjnego wprowadza produkt do wersji Android X+4, czyli po 3 latach od rozpoczęcia produkcji pojazdu. Producent musi teraz zrównoważyć nowsze wymagania sprzętowe najnowszej wersji Androida z hardwarem w produkcie i korzyściami dla użytkownika wynikającymi z zaktualizowanego systemu operacyjnego Android. Producent udostępnia aktualizację bez aktualizacji zabezpieczeń, więc produkt ma teraz system operacyjny w wersji X+4.y0 i stan aktualizacji zabezpieczeń Androida.

W tym przykładzie ze względu na ograniczenia sprzętowe X+4 jest ostatnią główną wersją Androida, która będzie dostępna dla tego produktu, chociaż oczekiwany okres eksploatacji pojazdu wynoszący ponad 6 lat nadal wymaga wsparcia w zakresie bezpieczeństwa.
⑥ Aktualizacja zabezpieczeń Powtórz krok 4 (Aktualizacja zabezpieczeń). Producent musi pobrać aktualizacje zabezpieczeń ASB z znacznie nowszej wersji Androida (X+6) i przenieść niektóre lub wszystkie z nich do Androida X+4. Za scalanie, integrowanie i przeprowadzanie aktualizacji (lub zlecanie tych czynności podmiotowi zewnętrznemu) odpowiada producent. Producent powinien też pamiętać, że problemy z bezpieczeństwem w wersjach Androida, które nie są już obsługiwane, nie są uwzględniane w Biuletynie bezpieczeństwa w Androidzie.
⑦ Aktualizacja zabezpieczeń Po 8 latach od rozpoczęcia cyklu życia produkcyjnego pojazdu, 4 wersjach Androida od ostatniej aktualizacji systemu operacyjnego w kroku 5 (pełna aktualizacja systemu operacyjnego) i 10 latach od określenia specyfikacji Androida X obowiązek tworzenia i przenoszenia wstecznego poprawek zabezpieczeń spoczywa w całości na producencie w przypadku wersji starszych niż 3 lata od publicznego udostępnienia poziomu interfejsu API.

Bezpieczeństwo – sprawdzone metody

Aby utrudnić naruszenie bezpieczeństwa, Google zaleca i stosuje powszechnie akceptowane sprawdzone metody dotyczące bezpieczeństwa i inżynierii oprogramowania, opisane w artykule Wdrażanie zabezpieczeń.

Wytyczne dotyczące bezpieczeństwa

Zalecane metody dotyczące bezpieczeństwa:

  • Korzystaj z najnowszych wersji bibliotek zewnętrznych i komponentów open source.
  • Nie umieszczaj w wersjach produkcyjnych systemu operacyjnego natrętnych funkcji debugowania.
  • Usuń nieużywane funkcje (aby zmniejszyć niepotrzebną powierzchnię ataku).
  • Stosuj zasadę jak najmniejszych uprawnień i inne sprawdzone metody tworzenia aplikacji na Androida.

Wskazówki dotyczące tworzenia oprogramowania

Zalecane metody bezpiecznego tworzenia oprogramowania w cyklu życia systemu obejmują:

  • Przeprowadzanie modelowania zagrożeń w celu klasyfikowania i identyfikowania zasobów, zagrożeń i potencjalnych środków zaradczych.
  • Przeprowadź weryfikację architektury lub projektu, aby zapewnić bezpieczną i solidną konstrukcję.
  • Regularnie sprawdzaj kod, aby jak najszybciej wykrywać antypatenty i błędy.
  • Projektowanie, wdrażanie i przeprowadzanie testów jednostkowych o wysokim pokryciu kodu, w tym:
    • Testy funkcjonalne (w tym negatywne przypadki testowe)
    • Regularne testy regresyjne (aby mieć pewność, że usunięte błędy nie pojawią się ponownie)
    • testowanie fuzzingowe (w ramach zestawu testów jednostkowych);
  • Używaj narzędzi do statycznej analizy kodu źródłowego (scan-build, lint itp.), aby identyfikować potencjalne problemy.
  • Używaj narzędzi do dynamicznej analizy kodu źródłowego, takich jak AddressSanitizer, UndefinedBehaviorSanitizer i FORTIFY_SOURCE (w przypadku komponentów natywnych), aby identyfikować i ograniczać potencjalne problemy podczas tworzenia systemu.
  • mieć strategię zarządzania kodem źródłowym oprogramowania oraz konfiguracją/wersją wydania;
  • Musisz mieć strategię zarządzania poprawkami, która obejmuje generowanie i wdrażanie poprawek oprogramowania.

Zasady dotyczące przenoszenia poprawek zabezpieczeń

Google obecnie aktywnie obsługuje aktualizacje zabezpieczeń dotyczące wykrytych i zgłoszonych luk w zabezpieczeniach przez 3 lata od publicznego udostępnienia poziomu interfejsu API. Aktywna pomoc obejmuje:

  1. otrzymywać i sprawdzać raporty o lukach w zabezpieczeniach;
  2. Tworzenie, testowanie i publikowanie aktualizacji zabezpieczeń.
  3. Regularne publikowanie aktualizacji zabezpieczeń i szczegółów biuletynu zabezpieczeń.
  4. Przeprowadź ocenę wagi zgodnie z ustalonymi wytycznymi.

Po 3 latach od daty publicznego udostępnienia poziomu API Google zaleca stosowanie tych wytycznych:

  • korzystać z usług firmy zewnętrznej (np. dostawcy układu SOC lub dostawcy jądra) w zakresie obsługi przenoszenia wstecznego aktualizacji zabezpieczeń systemu operacyjnego starszych niż 3 lata od daty udostępnienia interfejsu API;
  • Korzystanie z usług firmy zewnętrznej do przeprowadzania weryfikacji kodu za pomocą publicznie udostępnionych specyfikacji ASB. Chociaż ASB identyfikują luki w zabezpieczeniach w przypadku obecnie obsługiwanej wersji, producent może wykorzystać podane informacje do porównania nowo wydanych aktualizacji z poprzednimi wersjami. Te dane mogą być używane do przeprowadzania analizy wpływu i potencjalnego generowania podobnych poprawek w przypadku wersji systemu operacyjnego starszych niż 3 lata od daty udostępnienia interfejsu API.
  • W odpowiednich przypadkach przesyłaj aktualizacje zabezpieczeń do Projektu Android Open Source (AOSP).
  • Producent musi koordynować obsługę aktualizacji zabezpieczeń kodu specyficznego dla dostawcy (np. zastrzeżonego kodu specyficznego dla urządzenia).
  • Producent powinien dołączyć do grupy powiadomień o wersji zapoznawczej biuletynu Android Security Bulletin (wymaga to podpisania umów prawnych, np. umowy NDA dla deweloperów). Biuletyny powinny zawierać:
    • Ogłoszenia
    • Podsumowanie problemów według poziomu aktualizacji, w tym CVE i poziomu ważności
    • Szczegóły luki w zabezpieczeniach (w odpowiednich przypadkach)

Dodatkowe odniesienia

Instrukcje dotyczące bezpiecznego kodowania i programowania znajdziesz w tych materiałach:

Google zachęca do stosowania tych sprawdzonych metod.

Zaleca się, aby każde połączone urządzenie było wprowadzane na rynek z najnowszą wersją systemu operacyjnego, a producent powinien przed wprowadzeniem produktu na rynek spróbować użyć najnowszej wersji systemu operacyjnego. Zablokowanie wersji jest konieczne, aby zapewnić stabilność przed testowaniem i weryfikacją, ale producent musi zrównoważyć stabilność produktu uzyskaną dzięki starszym wersjom systemu operacyjnego z nowszymi wersjami, które mają mniej znanych luk w zabezpieczeniach i lepsze zabezpieczenia.

Zalecane wytyczne:

  • Ze względu na długi czas realizacji procesu rozwoju pojazdów producenci mogą wprowadzać na rynek urządzenia z wersją systemu operacyjnego n-2 lub starszą.
  • Zachowaj zgodność z Androidem w przypadku każdej wydanej wersji systemu operacyjnego Android w ramach kampanii aktualizacji bezprzewodowej (OTA).
  • Wdrażaj oprogramowanie sprzętowe produktu na Androida z możliwością aktualizacji bezprzewodowej (FOTA), aby zapewnić szybkie i wygodne dla klientów aktualizacje. Aktualizacja FOTA powinna być przeprowadzana zgodnie z najlepszymi praktykami w zakresie bezpieczeństwa, takimi jak podpisywanie kodu i połączenie TLS między produktem a zapleczem IT.
  • Przesyłanie niezależnie wykrytych luk w zabezpieczeniach Androida do zespołu ds. bezpieczeństwa Androida.

Uwaga: w biuletynach bezpieczeństwa Androida Google rozważa powiadomienia dotyczące konkretnych typów urządzeń lub branż. Google nie zna jednak jądra, sterowników ani chipsetów danego urządzenia (pojazdu, telewizora, urządzenia do noszenia, telefonu itp.), dlatego nie ma deterministycznego sposobu na przypisanie konkretnego problemu z bezpieczeństwem do typu urządzenia.

Producent powinien dokładać wszelkich starań, aby w trakcie ulepszania produktu korzystać z najnowszej wersji systemu operacyjnego lub aktualizacji zabezpieczeń dla używanej wersji. Aktualizacje mogą być przeprowadzane podczas okresowych aktualizacji produktów lub w przypadku poprawek, które rozwiązują problemy z jakością lub inne. Zalecane metody to:

  • Utwórz plan dotyczący aktualizacji sterowników, jądra i protokołów.
  • Używaj odpowiedniej dla branży metody dostarczania aktualizacji do wdrożonych pojazdów.

Dokument definicji zgodności (CDD)

Dokument definicji zgodności (CDD) opisuje wymagania, które musi spełniać urządzenie, aby można je było uznać za zgodne z Androidem. Dokument CDD jest publiczny i dostępny dla wszystkich. Możesz pobrać wersje CDD od Androida 1.6 do najnowszej wersji ze strony source.android.com.

Spełnienie tych wymagań w przypadku produktu obejmuje te podstawowe kroki:

  1. Partner podpisuje z Google zobowiązanie dotyczące zgodności z Androidem (ACC). Następnie przydzielany jest konsultant ds. rozwiązań technicznych.
  2. Partner przeprowadza weryfikację CDD dla wersji systemu operacyjnego Android na urządzeniu.
  3. Partner przeprowadza i przesyła wyniki CTS (opisane poniżej), dopóki nie będą one akceptowalne pod względem zgodności z Androidem.

Compatibility Test Suite (CTS)

Narzędzie testowe Compatibility Test Suite (CTS) sprawdza, czy implementacja produktu jest zgodna z Androidem i czy zawiera najnowsze poprawki zabezpieczeń. CTS jest publiczny, ma otwarty kod źródłowy i jest dostępny dla wszystkich. Wersje CTS od Androida 1.6 do najnowszej wersji możesz pobrać ze strony source.android.com.

Każda wersja oprogramowania Android udostępniana publicznie (obrazy do instalacji fabrycznej i aktualizacji w terenie) musi wykazać zgodność z Androidem na podstawie wyników testu CTS. Jeśli na przykład urządzenie działa pod kontrolą Androida 7.1, podczas tworzenia i testowania obrazu kompilacji przeznaczonej do udostępnienia należy odwoływać się do najnowszej odpowiedniej wersji dokumentu CDD 7.1 i zestawu CTS 7.1. Zachęcamy producentów do wczesnego i częstego korzystania z CTS, aby wykrywać i rozwiązywać problemy.

UWAGA: partnerzy, którzy podpisują inne umowy, np. Usługi mobilne Google (GMS), mogą musieć spełniać inne wymagania.

Przepływ pracy w CTS

Przepływ pracy CTS obejmuje konfigurowanie środowiska testowego, przeprowadzanie testów, interpretowanie wyników i poznawanie kodu źródłowego CTS. Poniższe wytyczne mają pomóc użytkownikom CTS (np. deweloperom i producentom) w efektywnym i wydajnym korzystaniu z tego narzędzia.

  • Często przeprowadzaj testy. CTS to zautomatyzowane narzędzie, które można zintegrować z systemem kompilacji. Częste uruchamianie CTS może pomóc w szybkim wykrywaniu defektów na wczesnym etapie, gdy wystąpią regresje lub pogorszenie jakości oprogramowania.
  • Pobierz i przeanalizuj 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 skompilować 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ę pakietu CTS Nowe wersje Androida mogą aktualizować CTS, dodając poprawki błędów, ulepszenia i nowe testy. Często sprawdzaj pobieranie CTS i w razie potrzeby aktualizuj program CTS. Producent i Google muszą uzgodnić wersję CTS, która będzie wymagana do wprowadzenia produktu na rynek, ponieważ w pewnym momencie produkt musi zostać zamrożony, a CTS będzie nadal aktualizowany.

Przejdź test CTS

W przypadku produktu zgodnego z Androidem Google sprawdza, czy wyniki testów CTS i CTS Verifier są akceptowalne. Z zasady wszystkie testy muszą zostać zaliczone. Test, który zakończy się niepowodzeniem z innych powodów niż niezgodność urządzenia z wymaganiami dotyczącymi zgodności z Androidem, podlega weryfikacji przez Google. Podczas tego procesu:

  1. Producent przekazuje Google proponowane poprawki CTS, ich weryfikacje i uzasadnienia, aby udowodnić swoje argumenty.
  2. Google sprawdza przesłane materiały i w razie potrzeby aktualizuje odpowiednie testy CTS, aby urządzenie przeszło je w kolejnej wersji CTS.

Jeśli po zastosowaniu poprawki zabezpieczeń test CTS nagle zakończy się niepowodzeniem, producent musi zmodyfikować poprawkę, aby nie powodowała utraty zgodności, LUB wykazać, że test jest nieprawidłowy, i dostarczyć poprawkę do testu (jak opisano powyżej).

CTS pozostaje otwarty na opinie dotyczące poprawek testów. Na przykład Android 4.4 nadal akceptuje poprawki (zobacz https://android-review.googlesource.com/c/platform/cts/+/273371).

Najczęstsze pytania

Pytanie: Kto jest odpowiedzialny za stosowanie aktualizacji zabezpieczeń w konkretnej implementacji Androida?

O: Odpowiedzialność ponosi producent, który bezpośrednio dostarcza urządzenie. Ten podmiot nie jest Google, która publikuje aktualizacje zabezpieczeń w AOSP, a nie na konkretne urządzenie (np. pojazd).

P: Jak Google radzi sobie z problemami dotyczącymi bezpieczeństwa Androida?

O: Google stale bada problemy i opracowuje potencjalne rozwiązania, które udostępnia na wszystkich obsługiwanych poziomach interfejsu API w ramach regularnego procesu aktualizacji zabezpieczeń. Od sierpnia 2015 r. Google regularnie publikuje biuletyny i linki do aktualizacji na stronie source.android.com. Google publikuje też aktualizacje zabezpieczeń w ramach głównych wersji systemu operacyjnego. Zapoznaj się też z  zasadami dotyczącymi przenoszenia poprawek zabezpieczeń.

P: Jeśli producent zintegrował wszystkie poprawki AOSP z ASB, ale nie zintegrował poprawek od dostawcy BSP wymienionych w tym samym biuletynie, czy może podnieść poziom bezpieczeństwa (np. zastosować odpowiednią poprawkę do platformy lub kompilacji)?

O: Aby zadeklarować poziom aktualizacji zabezpieczeń Androida (SPL), producent musi rozwiązać wszystkie wymagane problemy opublikowane w Biuletynie bezpieczeństwa Androida (w tym wcześniejsze biuletyny) i przypisane do konkretnego poziomu SPL Androida. Na przykład producent korzystający z Biuletynu bezpieczeństwa z marca 2017 r. (poziom poprawek zabezpieczeń z 1 marca 2017 r.) rozwiązał wszystkie wymagane problemy udokumentowane w biuletynie z marca 2017 r. dla tego poziomu poprawek zabezpieczeń i wszystkie wcześniejsze aktualizacje, w tym aktualizacje specyficzne dla urządzenia dla wszystkich wcześniejszych Biuletynów bezpieczeństwa w Androidzie, w tym aktualizacje specyficzne dla urządzenia powiązane z poziomem poprawek zabezpieczeń z 5 lutego 2017 r.

P: Co się stanie, gdy producent nie zgodzi się z aktualizacjami zabezpieczeń dostarczonymi przez dostawcę BSP LUB gdy dostawcy nie dostarczą aktualizacji zabezpieczeń wymaganych przez ASB?

O: ASB opisuje luki w zabezpieczeniach (wymienione na liście CVE) i często zawiera pasujące testy bezpieczeństwa. Celem jest zapewnienie, że wymienione luki w zabezpieczeniach nie będą już możliwe do odtworzenia na urządzeniu i że urządzenie przejdzie powiązane testy bezpieczeństwa. Problem nie polega na pobraniu aktualizacji zabezpieczeń dostarczonej przez Google lub zewnętrznego dostawcę, ale na potwierdzeniu przez producenta, że urządzenie nie jest podatne na zagrożenia wymienione na liście CVE w ASB. Producent może użyć dostarczonych aktualizacji zabezpieczeń lub, jeśli ma zmianę, która lepiej pasuje do jego urządzenia, użyć jej zamiast tego.

Rozważmy na przykład sytuację, w której Google usuwa lukę w zabezpieczeniach AOSP za pomocą zmiany kodu, która pozwala komponentowi zachować pełną funkcjonalność i zgodność z CDD. Jeśli producent uzna, że komponent nie jest potrzebny na urządzeniu lub nie jest wymagany przez CDD (ani powiązane testy certyfikacyjne), może go usunąć, aby zmniejszyć przyszłe potrzeby serwisowe i powierzchnię ataku. Chociaż producent nie użył dostarczonej aktualizacji zabezpieczeń, zadbał o to, aby urządzenie nie było podatne na zagrożenia opisane w biuletynie bezpieczeństwa. Jednak w przypadku odstąpienia od zalecanej aktualizacji zabezpieczeń producent podejmuje ryzyko nieprawidłowego rozwiązania problemu, wprowadzenia nowych luk w zabezpieczeniach lub innego ograniczenia funkcjonalności ostatecznej kompilacji.

Współpracujemy ze wszystkimi partnerami w zakresie układów SOC, aby zapewnić poprawki wszystkich problemów w ASB. Zalecamy jednak, aby producenci zawarli z dostawcami układów SOC umowę serwisową na cały okres eksploatacji urządzenia. Producenci układów SoC mogą wcześniej niż oczekiwano zaprzestać obsługi chipsetu, dlatego zawarcie umów przed wyborem chipsetu urządzenia jest ważną częścią procesu wprowadzania urządzenia na rynek.

W przypadku gdy nie można bezpośrednio uzyskać ani samodzielnie utworzyć poprawki problemu opisanego w ASB, producent może zachować poprzedni poziom SPL Androida i dodać do kompilacji nowe dostępne poprawki. Jednak takie postępowanie ostatecznie doprowadzi do problemów z certyfikacją kompilacji (ponieważ Android zapewnia, że na certyfikowanych urządzeniach dostępny jest najnowszy poziom aktualizacji zabezpieczeń). Aby uniknąć takich sytuacji, Google zaleca wcześniejsze skontaktowanie się z dostawcą układu SoC.

P: Jeśli producent uzna, że element ASB nie ma zastosowania do jego produktu, czy nadal musi go zastosować lub wprowadzić poprawkę, aby spełnić inne wymagania Google lub przejść test CTS?

O: Nie wymagamy stosowania poprawek, aby zadeklarować poziom aktualizacji zabezpieczeń Androida (SPL). Wymagamy jednak, aby producent potwierdził, że jego kompilacja nie jest podatna na dany problem.

Przykładem może być sytuacja, w której komponent, który ma zostać załatany, nie istnieje w systemie producenta lub komponent jest usuwany z systemu producenta w celu rozwiązania problemu. W takim przypadku system może być zgodny bez konieczności stosowania przez producenta poprawki.

Różni się to zasadniczo od sytuacji, w której producent chce na przykład naprawić tylko krytyczne poprawki, ale nie stosuje innych odpowiednich poprawek, które spowodowałyby niepowodzenie testu bezpieczeństwa. W takim przypadku zakłada się, że SPL nie został spełniony.