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

W tym przewodniku opisano zalecane przez Google sprawdzone metody wdrażania poprawek zabezpieczeń, które są oceniane przez pakiet Compatibility Test Suite (CTS) na potrzeby Androida. Jest ona przeznaczona dla producentów urządzeń OEM zgodnych z Androidem, którzy będą obsługiwać je dłużej niż przez 3 lata, takich jak pojazdy, telewizory, dekodery i urządzenia domowe. Ten przewodnik nie jest przeznaczony dla użytkowników końcowych (np. właścicieli pojazdów).

Podziękowania i wyłączenia odpowiedzialności

Ten przewodnik nie wiąże Google ani innych producentów prawnie ani umownie i nie jest zbiorem wymagań. Ten przewodnik to raczej materiał pomocniczy, który opisuje zalecane metody.

Opinia

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 do zapewnienia zgodności z Androidem. Wcześniej nazywała się Umową dotyczącą zapobiegania fragmentacji Androida (AFA).
AOSP Projekt Android Open Source
ASB Biuletyn bezpieczeństwa w Androidzie
BSP Pakiet pomocy platformy
CDD Dokument definicji zgodności
CTS Compatibility Test Suite
FOTA oprogramowanie układowe bezprzewodowo.
GPS system nawigacji satelitarnej
MISRA Motor Industry Software Reliability Association
NIST Narodowy Instytut Standaryzacji i Technologii (NIST)
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 rozpoczęcie produkcji
SPL Poziom aktualizacji zabezpieczeń
TPMS system monitorowania ciśnienia w oponach,

Informacje o systemie operacyjnym Android

Android to oparty na Linuksie pakiet oprogramowania typu open source, przeznaczony do różnych urządzeń i formatów. Od czasu pierwszej premiery w 2008 r. Android stał się najpopularniejszym systemem operacyjnym, który działa na ponad 1,4 miliarda urządzeń na całym świecie (2016 r.). Na koniec marca 2017 r. około 67% tych urządzeń używało Androida 5.0 (Lollipop) lub nowszego (najnowsze dane są dostępne na panelu Androida). Chociaż zdecydowana większość urządzeń to telefony komórkowe i tablety, Android staje się coraz popularniejszy w zegarkach, telewizorach i urządzeniach do rozrywki w samochodach.

Liczba aplikacji na Androida dostępnych w Sklepie Google Play osiągnęła poziom ponad 2,2 mln (2016 r.). Program zgodności z Androidem wspiera rozwój aplikacji na Androida. Określa on zestaw wymagań w dokumentacji zdefiniowania zgodności (CDD) i zapewnia narzędzia do testowania w ramach pakietu Compatibility Test Suite (CTS). Programy zgodności z Androidem zapewniają, że każda aplikacja na Androida może działać na dowolnym urządzeniu z Androidem, które obsługuje wymagane funkcje aplikacji.

Google regularnie publikuje nowe wersje systemu operacyjnego, aktualizacje zabezpieczeń systemu i informacje o odkrytych lukach w zabezpieczeniach. Producenci powinni zapoznać się z komunikatem o zabezpieczeniach Androida, aby sprawdzić, czy te aktualizacje są odpowiednie dla obsługiwanych przez nich produktów z Androidem. Informacje o bezpieczeństwie, zgodności i systemach kompilacji Androida znajdziesz w tych materiałach:

Połączone pojazdy (kanoniczne produkty długowieczne)

Pojazdy zaczęły być połączone po wprowadzeniu radia AM w latach 20. XX wieku. Wraz z tym, jak regulatorzy i producenci samochodów zaczęli stosować elektronikę w celu ułatwienia diagnostyki i obsługi (np. port OBD-II), poprawy bezpieczeństwa (np. TPMS) i osiągnięcia celów dotyczących zużycia paliwa, zaczęła rosnąć liczba zewnętrznych połączeń fizycznych i bezprzewodowych. Kolejna fala funkcji łączności wprowadziła funkcje ułatwiające kierowcy, takie jak zdalne otwieranie bezkluczykowe, systemy telematyczne i zaawansowane funkcje infotainment, takie jak Bluetooth, Wi-Fi i rzutowanie ze smartfona. Obecnie zintegrowane czujniki i usługi łączności (np. GPS) obsługują systemy wspomagania kierowcy i systemy półautonomiczne.

Wraz ze wzrostem liczby połączeń pojazdów zwiększa się również obszar potencjalnego ataku. Połączenia niosą ze sobą podobne problemy z bezpieczeństwem, co w przypadku urządzeń elektronicznych. Jednak podczas gdy ponowne uruchamianie, codzienne aktualizacje poprawek i niewyjaśnione zachowania są normą w przypadku elektroniki użytkowej, w przypadku produktów z systemami bezpieczeństwa, takich jak pojazdy, są one niespójne.

Producenci muszą stosować proaktywne podejście, aby zapewnić bezpieczeństwo produktu w warunkach rzeczywistych. Krótko mówiąc, producenci muszą znać znane luki w zabezpieczeniach w produkcie i eliminować je, stosując podejście oparte na analizie ryzyka.

Zapewnienie 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:

  • regularnie sprawdzać produkt pod kątem bazy danych typowych luk w zabezpieczeniach (CVE);
  • gromadzenie informacji na temat luk w zabezpieczeniach związanych z usługą;
  • testowanie zabezpieczeń.
  • Aktywnie analizować biuletyny o zabezpieczeniach Androida.

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

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

# Krok Działania

①

 Gałąź rozwojowa Producent wybiera wersję Androida (Android X). W tym przykładzie „Android X” staje się podstawą tego, co będzie dostarczane w samochodzie 2 lata przed początkiem produkcji.
② Pierwsze uruchomienie Na kilka miesięcy przed tym, jak Android X stanie się pierwszą wersją systemu operacyjnego dostarczaną z urządzeniem, aktualizacje zabezpieczeń są pobierane z Biuletynów bezpieczeństwa Androida (ASB) i z innych źródeł uznanych przez producenta za wartościowe. y2 = drugi Biuletyn bezpieczeństwa dotyczący wersji X Androida, zastosowany (przeniesiony wstecz) przez producenta w Androidzie X. Ta aktualizacja jest dostarczana w ramach produktu, a czas na wdrożenie wersji produkcyjnej rozpoczyna się w roku zerowym w przypadku Androida X.y2.

W tym przykładzie producent podjął decyzję o niewysyłaniu najnowszej rocznej wersji Androida X+1. Powody udostępniania najnowszej wersji obejmują dodawanie nowych funkcji, rozwiązywanie nowych luk w zabezpieczeniach lub udostępnianie usług Google lub usług innych firm, które wymagają nowszej wersji Androida. Przeciwwskazaniem jest brak czasu na integrację, testowanie i weryfikowanie zmian, w tym spełnienie wszystkich wymagań regulacyjnych i certyfikacyjnych.
③ Pełna aktualizacja systemu operacyjnego Po SOP producent udostępnia aktualizację systemu operacyjnego Android X+2, która jest 2 wersjami Androida po wersji użytej w pierwotnym produkcie (Android X0). Aktualizacje zabezpieczeń ASB są dostępne dla poziomu interfejsu API (w dacie premiery), więc aktualizacja jest wysyłana jako X+2.y0 w przybliżeniu 1,25 roku po SOP. Ta aktualizacja systemu operacyjnego może być zgodna z rozmieszczonymi produktami, ale może też nie być. Jeśli tak, można utworzyć plan aktualizacji rozmieszczonych pojazdów.

O ile nie ma innych umów handlowych, decyzja o przeprowadzeniu pełnej aktualizacji systemu operacyjnego należy wyłącznie do producenta.
④ Aktualizacja zabezpieczeń Po 2 latach od rozpoczęcia produkcji producent wprowadza poprawki do systemu Android X+2. Ta decyzja jest podejmowana na podstawie oceny ryzyka przez producenta. Producent wybiera jako podstawę aktualizacji trzecią aktualizację zabezpieczeń ASB dla wersji X+2. Produkty, które otrzymują aktualizację zabezpieczeń, mają teraz system operacyjny (X+2.y3) i stan aktualizacji zabezpieczeń Androida.

Producenci mogą wybierać poszczególne poprawki zabezpieczeń z dowolnego biuletynu, ale aby móc korzystać z poziomu poprawki zabezpieczeń Androida (SPL) związanego z biuletynami (np. 2017-02-05), muszą naprawić wszystkie wymagane problemy. Przeniesienie zmian i aktualizacji zabezpieczeń do wersji wspieranej jest obowiązkiem producenta.
5. Pełna aktualizacja systemu operacyjnego Powtórz krok 3 (Pełna aktualizacja systemu operacyjnego). Druga pełna aktualizacja systemu operacyjnego powoduje uaktualnienie produktu do Androida X+4 w trzy lata od rozpoczęcia produkcji pojazdu. Producent musi teraz dostosować nowsze wymagania sprzętowe najnowszej wersji Androida do sprzętu w produkcie, a użytkownik ma korzystać z zalet zaktualizowanego systemu operacyjnego Android. Producent wydał aktualizację bez aktualizacji zabezpieczeń, więc produkt ma teraz poziom (X+4.y0) systemu operacyjnego + 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 obsługiwana w tym produkcie, chociaż przewidywany okres użytkowania pojazdu (ponad 6 lat) nadal wymaga obsługi zabezpieczeń.
⑥ Aktualizacja zabezpieczeń Powtórz krok 4 (Aktualizacja zabezpieczeń). Producent musi pobrać aktualizacje zabezpieczeń ASB z znacznie nowszej wersji Androida (X+6) i przeportować niektóre lub wszystkie te aktualizacje z powrotem na Androida X+4. Łączenie, integracja i przeprowadzanie aktualizacji (lub zawarcie umowy z osobą trzecią) należy do obowiązków producenta. Producent powinien też wiedzieć, że problemy z bezpieczeństwem w wersjach Androida, które nie są już obsługiwane, nie są objęte ASB.
⑦ Aktualizacja zabezpieczeń Po upływie 8 lat od rozpoczęcia cyklu produkcyjnego pojazdu, 4 wersji Androida od ostatniej aktualizacji systemu operacyjnego w kroku 5 (pełna aktualizacja systemu operacyjnego) i 10 lat od specyfikacji Androida X, odpowiedzialność za tworzenie i przenoszenie poprawek zabezpieczeń spoczywa wyłącznie na producencie w przypadku wersji starszych niż 3 lata od publicznego wydania interfejsu API.

Sprawdzone metody zapewniania bezpieczeństwa

Aby utrudnić kompromisy dotyczące bezpieczeństwa, Google zaleca stosowanie powszechnie przyjętych sprawdzonych metod dotyczących bezpieczeństwa i inżynierii oprogramowania, jak opisano w artykule Wdrażanie zabezpieczeń.

Wytyczne dotyczące bezpieczeństwa

Zalecane praktyki dotyczące bezpieczeństwa:

  • Używaj najnowszych wersji bibliotek zewnętrznych i komponentów open source.
  • Nie dołączaj do wersji produkcyjnych systemu operacyjnego funkcji debugowania, które mogą być uciążliwe.
  • Usuń nieużywane funkcje (aby zmniejszyć niepotrzebną powierzchnię ataku).
  • Stosuj zasadę jak najmniejszych uprawnień i inne sprawdzone metody dotyczące tworzenia aplikacji na Androida.

Wskazówki dotyczące tworzenia oprogramowania

Zalecane metody bezpiecznego tworzenia oprogramowania na potrzeby cyklu życia systemu:

  • Modelowanie zagrożeń w celu ich sklasyfikowania i identyfikacji zasobów, zagrożeń i potencjalnych sposobów ich zminimalizowania.
  • Przeprowadź analizę architektury i projektu, aby zapewnić bezpieczny i solidny projekt.
  • Regularnie sprawdzaj kod, aby jak najszybciej wykrywać nieprawidłowe wzorce i błędy.
  • Projektowanie, wdrażanie i wykonywanie testów jednostkowych o wysokim pokryciu kodu, w tym:
    • testy funkcjonalne (w tym przypadki testów negatywnych);
    • regularne testy regresji (aby mieć pewność, że naprawione błędy nie powrócą);
    • testy fuzzingowe (jako część zestawu testów jednostkowych);
  • Użyj statycznych narzędzi do analizy kodu źródłowego (np. scan-build, lint), aby zidentyfikować potencjalne problemy.
  • Używaj dynamicznych narzędzi do analizy kodu źródłowego, takich jak AddressSanitizer, UndefinedBehaviorSanitizer i FORTIFY_SOURCE (w przypadku komponentów natywnych, aby wykrywać i łagodzić potencjalne problemy podczas rozwoju systemu.
  • mieć strategię zarządzania kodem źródłowym oprogramowania i konfiguracją/wersją wydania;
  • mieć strategię zarządzania poprawkami dotyczącą generowania i wdrażania poprawek oprogramowania;

Zasady dotyczące przenoszenia zabezpieczeń

Obecnie Google zapewnia aktywne wsparcie w zakresie wstecznego przenoszenia poprawek zabezpieczeń w przypadku odkrytych i zgłaszanych luk w zabezpieczeniach przez 3 lata od publicznego wydania poziomu interfejsu API. Aktywna pomoc obejmuje:

  1. otrzymywać i przeprowadzać analizę raportów o lukach w zabezpieczeniach;
  2. Tworzenie, testowanie i publikowanie aktualizacji zabezpieczeń.
  3. regularnie publikować aktualizacje zabezpieczeń i informacje o aktualizacjach zabezpieczeń;
  4. Przeprowadzić ocenę wagi zgodnie z ustalonymi wytycznymi.

Po upływie 3 lat od daty publicznego wydania poziomu interfejsu API zalecamy przestrzeganie tych wskazówek:

  • Korzystanie z usług zewnętrznych (np. dostawcy SoC lub dostawcy jądra) w celu uzyskania wsparcia dla aktualizacji zabezpieczeń systemu operacyjnego starszych niż 3 lata od wydania interfejsu API.
  • Korzystanie z usług firmy zewnętrznej do sprawdzania kodu za pomocą udostępnionych publicznie usług ASB. Podczas gdy ASBs identyfikują luki w zabezpieczeniach w obecnie obsługiwanej wersji, producent może użyć podanych informacji do porównania nowo opublikowanych aktualizacji z poprzednimi wersjami. Te dane mogą służyć do analizy wpływu i generowania podobnych poprawek w przypadku wersji systemu operacyjnego starszych niż 3 lata od wydania interfejsu API.
  • W odpowiednich przypadkach przesyłaj aktualizacje zabezpieczeń do Projektu Android Open Source (AOSP).
  • Producent musi koordynować obsługę aktualizacji zabezpieczeń w przypadku kodu związanego z konkretnym dostawcą (np. zastrzeżonego kodu dla konkretnego urządzenia).
  • Producent powinien dołączyć do grupy odbiorców powiadomień o wersji beta Androida w ramach umowy NDA (wymaga podpisania umów prawnych, takich jak umowa NDA dewelopera). Komunikaty powinny zawierać:
    • Ogłoszenia
    • Podsumowanie problemów według poziomu poprawek, w tym CVE i powagi
    • w stosownych przypadkach informacje o lukach w zabezpieczeniach;

Dodatkowe odniesienia

Instrukcje dotyczące bezpiecznego kodowania i sprawdzonych metod tworzenia oprogramowania znajdziesz w tych dokumentach:

Google zachęca do stosowania tych sprawdzonych metod.

Zazwyczaj zaleca się, aby każdy produkt podłączony do sieci był uruchamiany z najnowszą wersją systemu operacyjnego. Przed wprowadzeniem produktu na rynek producent powinien użyć najnowszej wersji systemu operacyjnego. Zamknięcie wersji jest konieczne, aby zapewnić stabilność przed testowaniem i weryfikacją, ale producent musi znaleźć równowagę między stabilnością produktu w starszych wersjach systemu operacyjnego a nowszymi wersjami, które mają mniej znanych luk w zabezpieczeniach i ulepszone zabezpieczenia.

Zalecane wytyczne:

  • Ze względu na długi czas rozwoju, który jest nieodłącznym elementem procesu rozwoju pojazdu, producenci mogą potrzebować wersji n-2 lub starszej.
  • Utrzymanie zgodności z Androidem w przypadku każdej opublikowanej wersji systemu operacyjnego Android za pomocą kampanii OTA.
  • Wdrożenie funkcji Android Firmware-over-the-air (FOTA) w produktach w celu szybkiego i przyjaznego dla klienta aktualizowania. FOTA powinna być przeprowadzana z użyciem sprawdzonych metod zabezpieczeń, takich jak podpisywanie kodu i połączenie TLS między produktem a backofficem IT.
  • Prześlij niezależnie zidentyfikowane luki w zabezpieczeniach Androida do zespołu ds. zabezpieczeń Androida.

Uwaga: w komunikatach dotyczących bezpieczeństwa Androida uwzględniamy powiadomienia dotyczące typu urządzenia lub branży. Ponieważ jednak Google nie zna jądra, sterowników ani układów scalonych danego urządzenia (samochodu, telewizora, urządzenia do noszenia, telefonu itp.), Google nie ma możliwości określenia typu urządzenia na podstawie danego problemu z bezpieczeństwem.

Producent powinien dołożyć wszelkich starań, aby używać najnowszej wersji systemu operacyjnego lub aktualizacji zabezpieczeń dla wersji używanej podczas ulepszania cyklu życia produktu. Aktualizacje mogą być przeprowadzane podczas okresowych aktualizacji produktów lub w ramach poprawek, które mają na celu rozwiązanie problemów z jakością lub innych problemów. Zalecane metody:

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

Dokument definicji zgodności (CDD)

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

Aby spełnić te wymagania w przypadku produktu, wykonaj te podstawowe czynności:

  1. Partner podpisuje z Google zobowiązanie dotyczące zgodności z Androidem (ACC). Następnie do rozwiązania problemu zostanie przypisany konsultant ds. rozwiązań technicznych (TSC).
  2. Partner przeprowadza kontrolę danych docelowych w przypadku wersji systemu operacyjnego Androida.
  3. Partner wykonuje i przesyła wyniki CTS (opisane poniżej) do momentu, gdy będą one akceptowalne pod kątem zgodności z Androidem.

Compatibility Test Suite (CTS)

Narzędzie do testowania Compatibility Test Suite (CTS) sprawdza, czy implementacja produktu jest zgodna z Androidem i czy zawiera najnowsze poprawki zabezpieczeń. Pakiet CTS jest publiczny, open source i dostępny dla wszystkich. Wersje pakietu CTS od Androida 1.6 do najnowszej wersji można pobrać ze strony source.android.com.

Każda wersja oprogramowania Android udostępniona publicznie (obrazu do instalacji fabrycznej i obrazu do aktualizacji w polu) musi potwierdzać zgodność z Androidem na podstawie wyników testów CTS. Jeśli na przykład urządzenie działa pod kontrolą Androida 7.1, podczas tworzenia i testowania obrazu kompilacji przeznaczonego do wydania należy odwoływać się do najnowszej wersji CDD 7.1 oraz CTS 7.1. Producentów zdecydowanie zachęcamy do częstego korzystania z CTS w celu wczesnego wykrywania i eliminowania problemów.

UWAGA: partnerzy, którzy podpisują inne umowy, np. Usługi mobilne Google (GMS), mogą być zobowiązani do spełnienia innych wymagań.

Proces CTS

Procedura 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 skutecznym i wydajnym korzystaniu z CTS.

  • Częste przeprowadzanie testów. CTS to zautomatyzowane narzędzie, które integruje się z systemem kompilacji. Często uruchamianie CTS może pomóc w szybkim wykrywaniu błędów na wczesnym etapie, gdy wystąpi degradacja oprogramowania lub regresja.
  • Pobierz i przejrzyj 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ć (pobrane źródło można w pełni skompilować i uruchomić). Jeśli test na urządzeniu nie powiedzie się, możesz sprawdzić odpowiednią sekcję kodu źródłowego, aby dowiedzieć się, dlaczego.
  • Pobierz najnowszą wersję pakietu CTS Nowe wersje Androida mogą aktualizować CTS, dodając poprawki błędów, ulepszenia i nowe testy. Często sprawdzaj pliki do pobrania z pakietu CTS i w razie potrzeby aktualizuj program CTS. Producent i Google muszą uzgodnić wersję CTS, która zostanie przekazana do wprowadzenia produktu na rynek, ponieważ w pewnym momencie produkt musi zostać zamrożony, a CTS będzie nadal aktualizowany.

Zdolność do przejścia testu CTS

W przypadku produktu zgodnego z Androidem Google zapewnia, że wyniki testów CTS i raportów weryfikatora CTS są akceptowalne. Zasadniczo wszystkie testy muszą zostać zaliczone. Jednak test, który nie powiedzie się z powodów innych niż niezgodność urządzenia z wymaganiami zgodności z Androidem, podlega sprawdzeniu przez Google. Podczas tego procesu:

  1. Producent przesyła do Google proponowane poprawki CTS, ich weryfikacje i uzasadnienia, które mają udowodnić twierdzenie.
  2. Google sprawdza przesłane materiały i w razie zaakceptowania aktualizuje odpowiednie testy CTS, aby urządzenie przeszło następną wersję CTS.

Jeśli po zastosowaniu poprawki zabezpieczeń test CTS nagle zacznie się nie powieść, producent musi zmodyfikować tę poprawkę, aby nie zakłócała zgodności, LUB poinformować o błędach w tym teście i zaproponować jego poprawkę (jak opisano powyżej).

CTS pozostaje otwarty na potrzeby sprawdzania poprawek testowych. Na przykład Android 4.4 nadal akceptuje poprawki (patrz https://android-review.googlesource.com/#/c/273371/).

Najczęstsze pytania

Pytanie: kto jest odpowiedzialny za stosowanie aktualizacji zabezpieczeń do konkretnej implementacji Androida?

Odp.: za to odpowiada producent, który bezpośrednio dostarcza urządzenie. Ten podmiot nie to Google, który publikuje aktualizacje zabezpieczeń w AOSP, a nie dla konkretnego urządzenia (np. pojazdu).

Pytanie: jak Google radzi sobie z problemami z bezpieczeństwem na Androidzie?

Odp.: Google nieustannie bada problemy i opracowuje potencjalne poprawki, które udostępnia dla wszystkich obsługiwanych poziomów 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 aktualizacji zabezpieczeń.

Pyt.: 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 zwiększyć poziom zabezpieczeń (np. zastosować odpowiednią poprawkę do platformy lub kompilacji)?

Odp.: Aby zadeklarować poziom aktualizacji zabezpieczeń Androida (SPL), producent musi rozwiązać wszystkie wymagane problemy opublikowane w biuletynie o bezpieczeństwie Androida (w tym w poprzednich biuletynach) i zmapowane do konkretnego poziomu SPL Androida. Na przykład producent korzystający z biuletynu bezpieczeństwa z marca 2017 r. (SPL z 2017-03-01) rozwiązał wszystkie wymagane problemy udokumentowane w biuletynie z marca 2017 r. dla tego SPL oraz wszystkie wcześniejsze aktualizacje, w tym aktualizacje dla poszczególnych urządzeń dla wszystkich wcześniejszych biuletynów bezpieczeństwa w Androidzie, w tym aktualizacje dla poszczególnych urządzeń powiązane z SPL z 2017-02-05.

P: Co się dzieje, gdy producent nie zgadza się na aktualizacje zabezpieczeń udostępniane przez dostawcę BSP LUB gdy aktualizacje zabezpieczeń wymagane przez dostawcę nie są udostępniane przez dostawców?

Odp.: ASB opisuje luki w zabezpieczeniach (wyliczone na liście CVE) i często zawiera odpowiednie testy zabezpieczeń. Celem jest zapewnienie, że wymienione luki w zabezpieczeniach nie mogą już być odtwarzane na urządzeniu i że urządzenie może przejść powiązane testy zabezpieczeń. Problem nie dotyczy aktualizacji zabezpieczeń dostarczanej przez Google lub zewnętrznego dostawcę, ale producenta, który potwierdza, że urządzenie nie jest podatne na luki w zabezpieczeniach z listy CVE w ASB. Producent może korzystać z dostarczonych aktualizacji zabezpieczeń lub, jeśli wprowadzi zmianę, która lepiej pasuje do jego urządzenia, może z niej skorzystać.

Rozważmy na przykład przypadek, w którym Google naprawia lukę w zabezpieczeniach AOSP za pomocą zmiany kodu, która pozwala komponentowi zachować pełną funkcjonalność i zgodność z CDD. Jeśli producent stwierdzi, że dany komponent nie jest potrzebny w urządzeniu lub nie jest wymagany przez CDD (lub powiązane testy certyfikacyjne), może go usunąć, aby zmniejszyć potrzebę serwisowania w przyszłości i zredukować powierzchnię ataku. Producent nie zastosował dostarczonej aktualizacji zabezpieczeń, ale zadbał o to, aby urządzenie nie było podatne na podatność CVE opisaną w powiadomieniu o zabezpieczeniach. Jednak odstępstwo od zalecanej aktualizacji zabezpieczeń może spowodować, że producent nie rozwiąże problemu w sposób prawidłowy, wprowadzi nowe luki w zabezpieczeniach lub w inny sposób ograniczy funkcjonalność końcowej wersji.

Chociaż współpracujemy ze wszystkimi partnerami w zakresie procesorów SoC, aby zapewnić poprawki dla wszystkich problemów w ramach ASB, zalecamy, aby producenci zawierali umowy serwisowe z dostawcami procesorów SoC na cały okres eksploatacji urządzenia. Producenci układów SoC mogą przestać obsługiwać dany układ wcześniej niż to planowane, dlatego zawarcie umów przed wyborem układu jest ważną częścią procesu wprowadzania urządzenia na rynek.

W przypadku, gdy nie można bezpośrednio pobrać lub samodzielnie utworzyć poprawki dla problemu udokumentowanego w ASB, producent może zachować poprzednią wersję Androida SPL i dodać do niej nowe dostępne poprawki. Jednak takie działanie może w końcu spowodować problemy z certyfikacją kompilacji (ponieważ Android zapewnia, że na certyfikowanych urządzeniach jest dostępna najnowsza aktualizacja zabezpieczeń). Aby uniknąć takich praktyk, Google zaleca wcześniejsze skontaktowanie się z zespołem obsługi klienta.

Pyt.: jeśli producent stwierdzi, że dany element ASB nie jest odpowiedni dla jego produktu, czy element ten nadal musi być zastosowany lub zaktualizowany, aby spełnić inne wymagania Google lub przejść CTS?

Odp.: nie wymagamy stosowania poprawek w celu zadeklarowania poziomu aktualizacji zabezpieczeń Androida (SPL). Wymagamy jednak, aby producent zaświadczył, że jego wersja nie jest podatna na dany problem.

Przykładem może być sytuacja, w której w systemie producenta nie ma komponentu, który ma być zaktualizowany, lub gdy komponent został usunięty z systemu producenta w celu rozwiązania problemu. W takim przypadku system może być zgodny bez konieczności wprowadzania poprawek przez producenta.

Jest to zasadniczo inne niż sytuacja, gdy producent chce wprowadzić tylko poprawki krytyczne, pomijając inne odpowiednie poprawki, które spowodowałyby niepowodzenie testu bezpieczeństwa. W takim przypadku zakłada się, że SPL nie zostało osiągnięte.