Este guia descreve as práticas recomendadas pelo Google para aplicar patches de segurança avaliados pelo conjunto de teste de compatibilidade (CTS) do Android. Ele é destinado a fabricantes de equipamentos OEM compatíveis com Android (fabricantes) que terão suporte por mais de três anos como veículos, TVs, conversores e eletrodomésticos. Este guia não é destinado a usuários finais (por exemplo, proprietários de veículos).
Agradecimentos e exonerações de responsabilidade
Este guia não vincula legal ou contratualmente o Google ou outros fabricantes e não se destina a ser um conjunto de requisitos. Em vez disso, este guia é um material didático que descreve práticas recomendadas.
Feedback
Este guia não é abrangente, e outras revisões estão planejadas. Envie feedback para manufacturers-guide-android@googlegroups.com.
Glossário
| Termo | Definição |
|---|---|
| ACC | Compromisso de compatibilidade com o Android. Antes conhecido como Contrato Antifragmentação do Android (AFA, na sigla em inglês). |
| AOSP | Android Open Source Project |
| ASB | Boletim de segurança do Android |
| BSP | Pacote de suporte da placa |
| CDD | Documento de definição de compatibilidade |
| CTS | Conjunto de teste de compatibilidade |
| FOTA | firmware over the air |
| GPS | sistema de posicionamento global |
| MISRA | Associação de confiabilidade de software da indústria automotiva |
| NIST | Instituto Nacional de Padrões e Tecnologia |
| OBD | diagnóstico a bordo (o OBD-II é uma melhoria em relação ao OBD-I em capacidade e padronização) |
| OEM | fabricante de equipamento original |
| SO | sistema operacional |
| SEI | Software Engineering Institute |
| SoC | system on chip |
| SOP | início da produção |
| SPL | Nível do patch de segurança |
| TPMS | sistema de monitoramento da pressão dos pneus |
Sobre o SO Android
O Android é uma pilha de software completa com base em Linux de código aberto projetada para diversos dispositivos e formatos. Desde o primeiro lançamento em 2008, o Android se tornou o sistema operacional mais popular, alimentando mais de 1,4 bilhão de dispositivos em todo o mundo (2016). Aproximadamente 67% desses dispositivos usam o Android 5.0 (Lollipop) ou mais recente desde março de 2017. Os números mais recentes estão disponíveis no painel do Android. Embora a grande maioria dos dispositivos sejam smartphones e tablets, o Android está crescendo em smartwatches, TVs e dispositivos de infoentretenimento automotivo (IVI).
O número de apps Android disponíveis na Google Play Store chegou a mais de 2,2 milhões (2016). O desenvolvimento de apps Android é respaldado pelo Programa de compatibilidade com Android, que define um conjunto de requisitos pelo Documento de definição de compatibilidade (CDD) e fornece ferramentas de teste pelo Conjunto de teste de compatibilidade (CTS). Os programas de compatibilidade do Android garantem que qualquer app Android possa ser executado em qualquer dispositivo compatível com o Android que ofereça suporte aos recursos necessários para o app.
O Google lança regularmente novas versões do SO, atualizações de segurança do SO e informações sobre vulnerabilidades descobertas. Os fabricantes precisam analisar os Boletins de segurança do Android para saber se essas atualizações são aplicáveis aos produtos compatíveis com o SO Android. Para uma análise da segurança, compatibilidade e sistemas de build do Android, consulte:
- Proteger um dispositivo Android
- Atualizações e recursos de segurança
- Conjunto de teste de compatibilidade
- Codinomes, tags e números de build
Sobre veículos conectados (produtos canônicos de longa duração)
Os veículos começaram a ser conectados com a introdução do rádio AM na década de 1920. A partir daí, o número de conexões físicas e sem fio externas começou a crescer à medida que reguladores e fabricantes de automóveis passaram a usar eletrônicos para facilitar diagnósticos e serviços (por exemplo, porta OBD-II), melhorar a segurança (por exemplo, TPMS) e atender às metas de economia de combustível. A próxima onda de conectividade introduziu recursos de conveniência para o motorista, como entrada remota sem chave, sistemas telemáticos e recursos avançados de infoentretenimento, como Bluetooth, Wi-Fi e projeção de smartphone. Hoje, sensores integrados e conectividade (por exemplo, GPS) oferecem suporte a sistemas de segurança e direção semiautônoma.
À medida que o número de conexões de veículos aumenta, também aumenta a área da possível superfície de ataque de veículos. As conexões trazem consigo uma coleção semelhante de preocupações de segurança cibernética, assim como a eletrônica de consumo. No entanto, embora reinicializações, atualizações diárias de patch e comportamentos inexplicáveis sejam a norma para eletrônicos de consumo, eles são inconsistentes para produtos com sistemas críticos de segurança, como veículos.
Os fabricantes precisam adotar uma abordagem proativa para garantir a postura contínua de segurança de um produto em campo. Em resumo, os fabricantes precisam estar cientes das vulnerabilidades de segurança conhecidas no produto e adotar uma abordagem baseada em riscos para lidar com elas.
Garantir a segurança a longo prazo
Um veículo conectado geralmente tem uma ou mais unidades de controle eletrônico (ECUs) que incluem vários componentes de software, como SO, bibliotecas, utilitários etc. Os fabricantes precisam rastrear esses componentes e identificar vulnerabilidades conhecidas publicadas com análise proativa, incluindo:
- Avaliar regularmente o produto em relação ao banco de dados de vulnerabilidades e exposições comuns (CVE).
- Coleta de informações sobre falhas de segurança relacionadas a produtos.
- Testes de segurança.
- Analisar ativamente os Boletins de segurança do Android.
Exemplo de atualizações de patches de segurança e do SO (IVIs com Android):
Figura 1. Exemplo de lançamento de atualizações importantes de SO e segurança durante a vida útil do veículo.
| # | Etapa | Atividades |
|---|---|---|
|
① |
Branch de desenvolvimento | O fabricante seleciona uma versão do Android (Android X). Neste exemplo, o "Android X" se torna a base do que será lançado no veículo dois anos antes do início da produção (SOP, na sigla em inglês). |
| ② | Lançamento inicial | Alguns meses antes de o Android X se tornar a primeira versão do SO enviada no produto, as atualizações de segurança são retiradas dos Boletins de Segurança do Android (ASBs) e de outras fontes consideradas valiosas pelo fabricante. y2 = o segundo Boletim de Segurança para a versão X do Android, aplicado (backportado) pelo fabricante ao Android X. Essa atualização é enviada no produto, e o relógio de produção começa a funcionar no Ano Zero com o Android X.y2.
Neste exemplo, o fabricante decidiu não enviar a versão anual mais recente do Android X+1. Os motivos para enviar a versão mais recente incluem a adição de novos recursos, o tratamento de novas vulnerabilidades de segurança e/ou o envio de serviços do Google ou de terceiros que exigem a versão mais recente do Android. Os motivos contra o envio com a versão mais recente são a falta de tempo inerente ao processo de desenvolvimento e lançamento do veículo necessário para integrar, testar e validar as mudanças, incluindo a conformidade com todos os requisitos regulatórios e de certificação. |
| ③ | Atualização completa do SO | Após o SOP, o fabricante lança a atualização do SO Android X+2, que é duas versões do Android
depois da versão usada para o produto inicial (Android X0). As atualizações de segurança do ASB estão disponíveis
para o nível da API (a partir da data de envio), então a atualização é lançada como X+2.y0 aproximadamente 1,25
anos após o SOP. Essa atualização do SO pode ou não ser compatível com produtos em campo. Se for, um plano poderá ser criado para atualizar os veículos implantados.
A menos que outros contratos comerciais estejam em vigor, a decisão de fazer uma atualização completa do SO é totalmente a critério do fabricante. |
| ④ | Atualização de segurança | Dois anos após o início da produção do veículo, o fabricante corrige o
Android X+2 OS. Essa decisão é baseada na avaliação de risco do fabricante. O fabricante escolhe a terceira atualização de segurança do ASB para a versão X+2 como base da atualização. Os produtos que
receberam a atualização de segurança agora estão no SO (X+2.y3) + nível do patch de segurança do Android.
Embora os fabricantes possam selecionar patches de segurança individuais de qualquer ASB, eles precisam corrigir todos os problemas necessários no boletim para usar o nível do patch de segurança do Android (SPL) associado ao boletim (por exemplo, 2017-02-05). É responsabilidade do fabricante fazer o backport e o lançamento de segurança para o produto compatível. |
| ⑤ | Atualização completa do SO | Uma repetição da etapa 3 (atualização completa do SO), a segunda atualização completa do SO leva o produto ao
Android X+4, três anos após o início da vida útil de produção do veículo. O fabricante agora está equilibrando os requisitos de hardware mais recentes de uma versão recente do Android com o hardware do produto, e o usuário se beneficia de um SO Android atualizado. O fabricante lança uma
atualização sem atualizações de segurança. Assim, o produto agora está no SO (X+4.y0) + nível do patch de segurança do Android.
Neste exemplo, devido a limitações de hardware, o X+4 é a última versão principal do Android que será fornecida para esse produto. No entanto, os mais de seis anos de vida útil esperada do veículo ainda exigem suporte de segurança. |
| ⑥ | Atualização de segurança | Repita a etapa 4 (Atualização de segurança). O fabricante tem a tarefa de pegar atualizações de segurança do ASB de uma versão muito mais recente do Android (X+6) e transferir algumas ou todas essas atualizações de volta para o Android X+4. É responsabilidade do fabricante mesclar, integrar e realizar as atualizações (ou contratar um terceiro). Além disso, o fabricante precisa saber que problemas de segurança em versões do Android que não têm mais suporte não são abordados no ASB. |
| ⑦ | Atualização de segurança | Oito anos após o início do ciclo de vida de produção do veículo, quatro versões do Android desde a última atualização do SO na etapa 5 (atualização completa do SO) e dez anos desde que o Android X foi especificado, o ônus de selecionar e fazer backport de patches de segurança é totalmente do fabricante para versões com mais de três anos desde o lançamento público do nível da API. |
Práticas recomendadas de segurança
Para dificultar ainda mais as violações de segurança, o Google recomenda e usa as práticas recomendadas comumente aceitas para segurança e engenharia de software, conforme descrito em Implementação da segurança.
Diretrizes de segurança
Práticas recomendadas de segurança:
- Use as versões mais recentes de bibliotecas externas e componentes de código aberto.
- Não inclua funcionalidades de depuração intrusivas nas versões de lançamento do SO.
- Remova funcionalidades não usadas para reduzir a superfície de ataque desnecessária.
- Use o princípio de privilégio mínimo e outras práticas recomendadas de desenvolvimento de apps Android.
Diretrizes de desenvolvimento de software
As práticas recomendadas para o desenvolvimento de software seguro durante o ciclo de vida do sistema incluem:
- Faça a modelagem de ameaças para classificar e identificar recursos, ameaças e possíveis mitigações.
- Realize uma revisão de arquitetura/design para garantir um design seguro e adequado.
- Faça revisões de código regulares para identificar antipadrões e bugs assim que possível.
- Projete, implemente e execute testes de unidade de alta cobertura de código, incluindo:
- Teste funcional (incluindo casos de teste negativos)
- Testes de regressão regulares (para garantir que bugs corrigidos não voltem a aparecer)
- Fuzzing (como parte do conjunto de testes de unidade)
- Use ferramentas de análise estática de código-fonte (scan-build, lint etc.) para identificar possíveis problemas.
- Use ferramentas de análise dinâmica de código-fonte, como AddressSanitizer, UndefinedBehaviorSanitizer e FORTIFY_SOURCE (para componentes nativos), para identificar e reduzir possíveis problemas durante o desenvolvimento do sistema.
- Ter uma estratégia de gerenciamento para o código-fonte do software e a configuração/versão de lançamento.
- Tenha uma estratégia de gerenciamento de patches para geração e implantação de patches de software.
Política de backport de segurança
No momento, o Google oferece suporte ativo para backports de segurança de vulnerabilidades descobertas e informadas por três (3) anos a partir do lançamento público do nível da API. O suporte ativo consiste no seguinte:
- Receber e investigar relatórios de vulnerabilidade.
- Criar, testar e lançar atualizações de segurança.
- Fornecer versões recorrentes de atualizações de segurança e detalhes do boletim de segurança.
- Faça uma avaliação de gravidade de acordo com as diretrizes estabelecidas.
Três anos após a data de lançamento público do nível da API, o Google recomenda as seguintes diretrizes:
- Use um terceiro (como um fornecedor de SoC ou um provedor de kernel) para oferecer suporte a backport para atualizações de segurança do SO com mais de três anos desde o lançamento da API.
- Use um terceiro para fazer revisões de código usando os ASBs fornecidos publicamente. Embora os ASBs identifiquem vulnerabilidades na versão com suporte atual, um fabricante pode usar as informações fornecidas para comparar as atualizações recém-lançadas com versões anteriores. Esses dados podem ser usados para fazer uma análise de impacto e gerar patches semelhantes para versões do SO com mais de três anos desde o lançamento da API.
- Quando apropriado, faça upload das atualizações de segurança para o Android Open Source Project (AOSP).
- O fabricante precisa coordenar o processamento de atualizações de segurança para código específico do fornecedor (por exemplo, código proprietário específico do dispositivo).
- O fabricante precisa participar do grupo de notificação de prévia para parceiros do boletim de segurança do Android com NDA (requer a assinatura de contratos legais, como o NDA do desenvolvedor). Os boletins precisam incluir:
- Anúncios
- Resumo dos problemas por nível de patch, incluindo CVE e gravidade
- Detalhes da vulnerabilidade, quando apropriado
Outras referências
Para instruções sobre práticas seguras de programação e desenvolvimento de software, consulte o seguinte:
- Associação de confiabilidade de software da indústria automotiva (MISRA).
- Ferramentas e métodos do Software Engineering Institute (SEI).
- Instituto Nacional de Padrões e Tecnologia (NIST).
Práticas recomendadas de produtos
O Google incentiva o uso das seguintes práticas recomendadas.
Diretrizes gerais de lançamento
Em geral, é recomendável que qualquer produto conectado seja lançado com a versão mais recente do SO, e um fabricante deve tentar usar a versão mais recente do SO antes de lançar o produto. Embora seja necessário bloquear a versão para garantir a estabilidade antes do teste e da validação, o fabricante precisa equilibrar a estabilidade do produto obtida com versões mais antigas do SO e versões mais recentes que têm menos vulnerabilidades de segurança conhecidas e proteções de segurança aprimoradas.
As diretrizes recomendadas incluem:
- Devido aos longos prazos de desenvolvimento inerentes ao processo de desenvolvimento de veículos, os fabricantes podem precisar lançar com a versão n-2 ou mais antiga do SO.
- Mantenha a conformidade com a compatibilidade do Android para cada versão lançada do SO Android com uma campanha over-the-air (OTA).
- Implemente o firmware over-the-air (FOTA) do produto para Android, que permite atualizações rápidas e fáceis para o cliente. A FOTA precisa ser feita usando as práticas recomendadas de segurança, como assinatura de código e conexão TLS entre o produto e o backoffice de TI.
- Envie vulnerabilidades de segurança do Android identificadas de forma independente para a equipe de segurança do Android.
Observação:o Google considerou notificações específicas do setor ou do tipo de dispositivo nos Boletins de Segurança do Android. No entanto, como o Google não conhece o kernel, os drivers ou os chipsets de um determinado dispositivo (veículo, TV, wearable, smartphone etc.), não há uma maneira determinista de rotular um problema de segurança específico com um tipo de dispositivo.
Diretrizes de ciclo de vida do produto
O fabricante deve fazer todos os esforços para usar a versão mais recente do SO ou atualizações de segurança para a versão em uso durante as melhorias do ciclo de vida do produto. As atualizações podem ser feitas durante atualizações periódicas recorrentes de produtos ou para hotfixes que resolvem problemas de qualidade e/ou outros problemas. Práticas recomendadas:
- Crie um plano para lidar com atualizações de driver, kernel e protocolo.
- Use um método adequado do setor para fornecer atualizações aos veículos implantados.
Documento de definição de compatibilidade (CDD)
O Documento de definição de compatibilidade (CDD) descreve os requisitos para que um dispositivo seja considerado compatível com o Android. O CDD é público e está disponível para todos. É possível baixar versões do CDD do Android 1.6 até a mais recente em source.android.com.
Para atender a esses requisitos, siga estas etapas básicas:
- O parceiro assina o Compromisso de Compatibilidade do Android (ACC) com o Google. Em seguida, um consultor de soluções técnicas (TSC) é designado como guia.
- O parceiro conclui a análise do CDD para a versão do SO Android do produto.
- O parceiro executa e envia os resultados do CTS (descritos abaixo) até que eles sejam aceitáveis para a compatibilidade com o Android.
Conjunto de teste de compatibilidade (CTS)
A ferramenta de teste do Compatibility Test Suite (CTS) verifica se uma implementação de produto é compatível com o Android e se os patches de segurança mais recentes estão incluídos. O CTS é público, de código aberto e disponível para todos. É possível fazer o download das versões do CTS do Android 1.6 até a mais recente em source.android.com.
Cada build de software Android lançado ao público (imagens de atualização no campo e instaladas de fábrica) precisa comprovar a compatibilidade com o Android pelos resultados do CTS. Por exemplo, se o dispositivo executar o Android 7.1, a versão mais recente correspondente do CDD 7.1 e do CTS 7.1 deverá ser referenciada quando uma imagem de build de intenção de lançamento for criada e testada. Recomendamos que os fabricantes usem o CTS com frequência e desde o início para identificar e corrigir problemas.
Fluxo de trabalho do CTS
O fluxo de trabalho do CTS envolve configurar o ambiente de teste, executar testes, interpretar resultados e entender o código-fonte do CTS. As diretrizes a seguir foram criadas para ajudar os usuários do CTS (por exemplo, desenvolvedores, fabricantes) a usar o CTS de maneira eficaz e eficiente.
- Faça testes com frequência. O CTS foi projetado como uma ferramenta automatizada que se integra ao seu sistema de build. Executar o CTS com frequência ajuda a encontrar defeitos rapidamente e no início quando ocorrem degradações ou regressões de software.
- Faça o download e examine o código-fonte do CTS. O código-fonte completo do CTS é um software de código aberto que qualquer pessoa pode baixar e usar. O código-fonte baixado pode ser totalmente criado e executado. Quando um teste falha no dispositivo, examinar a seção relevante do código-fonte pode ajudar a identificar o motivo.
- Baixe o CTS mais recente. Novas versões do Android podem atualizar o CTS com correções de bugs, melhorias e novos testes. Verifique Downloads do CTS com frequência e atualize seu programa do CTS conforme necessário. O fabricante e o Google precisam concordar com a versão do CTS para aprovação do lançamento do produto, já que ele precisa ser congelado em algum momento enquanto o CTS continua sendo atualizado.
Passar no CTS
Para um produto compatível com o Android, o Google garante que o CTS e os relatórios do CTS Verifier do dispositivo tenham resultados de teste aceitáveis. Em princípio, todos os testes precisam ser aprovados. No entanto, um teste que falha por motivos diferentes da não conformidade do dispositivo com os requisitos de compatibilidade do Android está sujeito a análise pelo Google. Durante esse processo:
- O fabricante fornece ao Google os patches do CTS propostos, as validações de patch e as justificativas para provar o argumento.
- O Google examina o material enviado e, se aceito, atualiza os testes relevantes do CTS para que o dispositivo seja aprovado na próxima revisão do CTS.
Se um teste do CTS falhar repentinamente após a aplicação de um patch de segurança, o fabricante precisará modificar o patch para que ele não quebre a compatibilidade OU mostrar que o teste está errado e fornecer uma correção para o teste (conforme descrito acima).
O CTS continua aberto para revisões de correções de teste. Por exemplo, o Android 4.4 continua aceitando correções (consulte https://android-review.googlesource.com/c/platform/cts/+/273371).
Perguntas frequentes
P: Quem é responsável por aplicar atualizações de segurança a uma implementação específica do Android?
R: A responsabilidade é do fabricante que fornece o dispositivo diretamente. Essa entidade não é o Google, que publica atualizações de segurança no AOSP e não para um dispositivo específico, como um veículo.
P: Como o Google lida com problemas de segurança no Android?
R: O Google investiga continuamente problemas e desenvolve possíveis correções, que são disponibilizadas para todos os níveis de API compatíveis como parte do processo regular de atualização de segurança. Desde agosto de 2015, o Google mantém uma cadência regular de publicação de boletins e links para atualizações em source.android.com. O Google também publica atualizações de segurança como parte dos principais lançamentos do SO. Consulte também a Política de backport de segurança.
P: Se um fabricante integrar todos os patches do AOSP de um ASB, mas não integrar patches do fornecedor de BSP mencionados no mesmo boletim, ainda será possível aumentar o nível de segurança (por exemplo, aplicar o patch correspondente a platform/build)?
R: Para declarar um nível de patch de segurança do Android (SPL, na sigla em inglês), um fabricante precisa resolver todos os problemas necessários publicados no Boletim de Segurança do Android (incluindo boletins anteriores) e mapeados para um SPL específico do Android. Por exemplo, um fabricante que usa o Boletim de segurança de março de 2017 (nível do patch de segurança de 2017-03-01) resolveu todos os problemas necessários documentados no boletim de março de 2017 para esse nível do patch de segurança e todas as atualizações anteriores, incluindo as atualizações específicas do dispositivo para todos os boletins de segurança do Android anteriores, incluindo as atualizações específicas do dispositivo associadas ao nível do patch de segurança de 2017-02-05.
P: O que acontece quando o fabricante não concorda com as atualizações de segurança fornecidas pelo fornecedor de BSP OU quando as atualizações de segurança exigidas por um ASB não são fornecidas pelos fornecedores?
R: Um ASB descreve vulnerabilidades de segurança (enumeradas por uma lista de CVEs) e geralmente fornece testes de segurança correspondentes. O objetivo é garantir que as vulnerabilidades listadas não possam mais ser reproduzidas em um dispositivo e que ele possa passar nos testes de segurança associados. Portanto, o problema não é receber uma atualização de segurança fornecida pelo Google ou por um fornecedor terceirizado, mas sim o fabricante atestar que o dispositivo não está vulnerável à lista de CVEs no ASB. O fabricante pode usar as atualizações de segurança fornecidas ou, se tiver uma mudança mais adequada ao dispositivo, usar essa mudança.
Por exemplo, considere um caso em que o Google corrige uma vulnerabilidade de segurança do AOSP usando uma mudança de código que permite que o componente permaneça totalmente funcional e em conformidade com o CDD. Se o fabricante determinar que o componente não é necessário no dispositivo ou não é exigido pelo CDD (ou testes de certificação relacionados), ele poderá remover o componente para reduzir as necessidades de manutenção futuras e a superfície de ataque. Embora o fabricante não tenha usado a atualização de segurança fornecida, ele garantiu que o dispositivo não esteja vulnerável ao CVE documentado no boletim de segurança. No entanto, ao se desviar da atualização de segurança recomendada, o fabricante corre o risco de resolver o problema incorretamente, introduzir novas vulnerabilidades de segurança ou reduzir a funcionalidade do build final.
Embora trabalhemos com todos os parceiros de SoC para garantir que haja correções para todos os problemas em um ASB, recomendamos que os fabricantes firmem um contrato de serviço com os fornecedores de SoC durante o ciclo de vida de um dispositivo. Os SoCs podem parar de atender a um chipset antes do desejado. Por isso, estabelecer acordos antes da seleção do chipset do dispositivo é uma parte importante do processo de lançamento.
Por fim, nos casos em que é impossível adquirir diretamente ou criar de forma independente uma correção para um problema documentado em um ASB, um fabricante pode manter o SPL do Android anterior e ainda adicionar as novas correções disponíveis ao build. No entanto, essa prática vai causar problemas com a certificação de build, já que o Android garante que o nível de patch de segurança mais recente esteja disponível em dispositivos certificados. O Google recomenda trabalhar com seu SoC com antecedência para evitar essa prática.
P: Se o fabricante determinar que um item de ASB não é aplicável ao produto, ele ainda precisará ser aplicado ou corrigido para atender aos outros requisitos do Google ou passar no CTS?
R: Não exigimos que os patches sejam feitos para declarar um nível de patch de segurança (SPL) do Android. No entanto, o fabricante precisa atestar que o build não está vulnerável ao problema.
Um exemplo é quando um componente que está sendo corrigido não existe no sistema do fabricante ou quando um componente é removido do sistema do fabricante para resolver um problema. Nesse caso, o sistema pode estar em conformidade sem exigir que o fabricante aplique um patch.
Isso é fundamentalmente diferente de um fabricante que quer, por exemplo, corrigir apenas patches críticos, sem aplicar outros patches relevantes que fariam um teste de segurança falhar. Nesse caso, presume-se que o SPL não foi atendido.