Guía del fabricante para la seguridad de Android a largo plazo

Esta guía describe las mejores prácticas recomendadas por Google para aplicar parches de seguridad evaluados por Android Compatibility Test Suite (CTS). Está destinado a fabricantes de equipos OEM compatibles con Android (fabricantes) que recibirán soporte durante más de tres años, como vehículos, televisores, decodificadores y electrodomésticos. Esta guía no está destinada a usuarios finales (por ejemplo, propietarios de vehículos).

Agradecimientos y descargos de responsabilidad

Esta guía no vincula legal ni contractualmente a Google ni a otros fabricantes y no pretende ser un conjunto de requisitos. Más bien, esta guía es una ayuda instructiva que describe las prácticas recomendadas.

Comentario

Esta guía no pretende ser exhaustiva; Se planean revisiones adicionales. Envíe sus comentarios a fabricantes-guide-android@googlegroups.com.

Glosario

Acerca del sistema operativo Android

Android es una pila de software completa de código abierto basada en Linux y diseñada para una variedad de dispositivos y factores de forma. Desde su primer lanzamiento en 2008, Android se ha convertido en el sistema operativo (SO) más popular, con más de 1.400 millones de dispositivos en todo el mundo (2016). Aproximadamente el 67 % de esos dispositivos utilizan Android 5.0 (Lollipop) o una versión más reciente en marzo de 2017 (las cifras más recientes están disponibles en el Panel de Android ). Si bien la gran mayoría de los dispositivos son teléfonos móviles y tabletas, Android está creciendo en relojes inteligentes, televisores y dispositivos de información y entretenimiento a bordo de vehículos (IVI).

La cantidad de aplicaciones de Android disponibles en Google Play Store ha alcanzado más de 2,2 millones (2016). El desarrollo de aplicaciones de Android está respaldado por el programa de compatibilidad de Android, que define un conjunto de requisitos a través del Documento de definición de compatibilidad (CDD) y proporciona herramientas de prueba a través de Compatibility Test Suite (CTS) . Los programas de compatibilidad de Android garantizan que cualquier aplicación de Android pueda ejecutarse en cualquier dispositivo compatible con Android que admita las funciones requeridas para la aplicación.

Google publica periódicamente nuevas versiones del sistema operativo, actualizaciones de seguridad del sistema operativo e información sobre vulnerabilidades descubiertas. Los fabricantes deben revisar el Boletín de seguridad de Android para determinar la aplicabilidad de estas actualizaciones a los productos compatibles con el sistema operativo Android. Para obtener una revisión de la seguridad, la compatibilidad y los sistemas de compilación de Android, consulte lo siguiente:

• Proteger un dispositivo Android
• Actualizaciones y recursos de seguridad
• Conjunto de pruebas de compatibilidad
• Nombres en clave, etiquetas y números de compilación

Acerca de los vehículos conectados (productos canónicos de larga duración)

Los vehículos comenzaron a conectarse con la introducción de la radio AM en la década de 1920. A partir de ahí, la cantidad de conexiones físicas e inalámbricas externas comenzó a crecer a medida que los reguladores y fabricantes de automóviles recurrieron a la electrónica para facilitar el diagnóstico y el servicio (por ejemplo, el puerto OBD-II), mejorar la seguridad (por ejemplo, TPMS) y cumplir los objetivos de economía de combustible. . La siguiente ola de conectividad introdujo características de conveniencia para el conductor, como entrada remota sin llave, sistemas telemáticos y funciones avanzadas de información y entretenimiento como Bluetooth, Wi-Fi y proyección de teléfonos inteligentes. Hoy en día, los sensores integrados y la conectividad (por ejemplo, GPS) respaldan los sistemas de conducción semiautónoma y de seguridad.

A medida que aumenta el número de conexiones de vehículos, también aumenta el área de la superficie potencial de ataque de vehículos. Las conexiones traen consigo una colección similar de preocupaciones de ciberseguridad que las de la electrónica de consumo. Sin embargo, si bien los reinicios, las actualizaciones diarias de parches y los comportamientos inexplicables son la norma para la electrónica de consumo, son inconsistentes para productos con sistemas críticos para la seguridad, como los vehículos.

Los fabricantes deben adoptar un enfoque proactivo para garantizar la seguridad continua de un producto en el campo. En resumen, los fabricantes deben ser conscientes de las vulnerabilidades de seguridad conocidas en el producto y adoptar un enfoque basado en el riesgo para abordarlas.

Garantizar la seguridad a largo plazo

Un vehículo conectado suele tener una o más unidades de control electrónico (ECU) que incluyen múltiples componentes de software, como sistemas operativos, bibliotecas, utilidades, etc. Los fabricantes deben realizar un seguimiento de dichos componentes e identificar las vulnerabilidades publicadas conocidas con análisis proactivos, que incluyen:

• Evaluar periódicamente el producto frente a la base de datos de exposiciones y vulnerabilidades comunes (CVE).
• Recopilación de inteligencia para fallas de seguridad relacionadas con el producto.
• Pruebas de seguridad.
• Analizando activamente los Boletines de Seguridad de Android.

Ejemplos de actualizaciones de parches de seguridad y sistema operativo (IVI con Android):

Figura 1. Ejemplo de implementación de actualizaciones de seguridad y sistemas operativos importantes durante la vida útil del vehículo.

Mejores prácticas de seguridad

Para dificultar más los compromisos de seguridad, Google recomienda y emplea el uso de mejores prácticas comúnmente aceptadas para la seguridad y la ingeniería de software, como se describe en Implementación de la seguridad .

Pautas de seguridad

Las prácticas recomendadas para la seguridad incluyen:

• Utilice las últimas versiones de bibliotecas externas y componentes de código abierto.
• No incluya funciones de depuración intrusivas en las versiones de lanzamiento del sistema operativo.
• Elimine la funcionalidad no utilizada (para reducir la superficie de ataque innecesaria).
• Utilice el principio de privilegios mínimos y otras prácticas recomendadas para el desarrollo de aplicaciones de Android .

Directrices de desarrollo de software.

Las prácticas recomendadas para el desarrollo de software seguro durante el ciclo de vida del sistema incluyen:

• Realice modelos de amenazas para clasificar e identificar activos, amenazas y posibles mitigaciones.
• Realizar una revisión de arquitectura/diseño para garantizar un diseño seguro y sólido.
• Realice revisiones periódicas del código para identificar antipatrones y errores lo antes posible.
• Diseñe, implemente y ejecute pruebas unitarias de cobertura de código alto, que incluyen:
  • Pruebas funcionales (incluidos casos de prueba negativos)
  • Pruebas de regresión periódicas (para garantizar que los errores solucionados no vuelvan a aparecer)
  • Pruebas difusas (como parte del conjunto de pruebas unitarias)
• Utilice herramientas de análisis de código fuente estático (scan-build, lint, etc.) para identificar problemas potenciales.
• Utilice herramientas dinámicas de análisis de código fuente, como AddressSanitizer, UndefinedBehaviorSanitizer y FORTIFY_SOURCE (para componentes nativos) para identificar y mitigar posibles problemas durante el desarrollo del sistema.
• Contar con una estrategia de gestión del código fuente del software y de la configuración/versión del lanzamiento.
• Contar con una estrategia de gestión de parches para la generación e implementación de parches de software.

Política de respaldo de seguridad

Actualmente, Google brinda soporte activo para los backports de seguridad de las vulnerabilidades de seguridad descubiertas y reportadas durante tres (3) años a partir del lanzamiento público a nivel de API . El soporte activo consiste en lo siguiente:

1. Recibir e investigar informes de vulnerabilidad.
2. Cree, pruebe y publique actualizaciones de seguridad.
3. Proporcione publicaciones periódicas de actualizaciones de seguridad y detalles de boletines de seguridad.
4. Realizar la evaluación de la gravedad según las pautas establecidas.

Después de tres años desde la fecha de lanzamiento público del nivel API, Google recomienda las siguientes pautas:

• Utilice un tercero (como un proveedor de SoC o un proveedor de Kernel) para obtener soporte de backport para actualizaciones de seguridad del sistema operativo con más de tres años desde el lanzamiento de la API.
• Utilice un tercero para realizar revisiones de código utilizando los ASB proporcionados públicamente. Si bien los ASB identifican vulnerabilidades para la versión actualmente compatible, un fabricante puede usar la información proporcionada para comparar las actualizaciones recién lanzadas con versiones anteriores. Estos datos se pueden utilizar para realizar análisis de impacto y potencialmente generar parches similares para versiones del sistema operativo anteriores a tres años desde el lanzamiento de la API.
• Cuando corresponda, cargue actualizaciones de seguridad en el Proyecto de código abierto de Android (AOSP).
• El fabricante debe coordinar el manejo de las actualizaciones de seguridad para el código específico del proveedor (por ejemplo, código propietario específico del dispositivo).
• El fabricante debe unirse al grupo de notificación NDA Android Security Bulletin Partner Preview (requiere la firma de acuerdos legales como el NDA para desarrolladores). Los boletines deben incluir:
  • Anuncios
  • Resumen de problemas por nivel de parche, incluidos CVE y gravedad
  • Detalles de vulnerabilidad cuando corresponda

Referencias adicionales

Para obtener instrucciones sobre prácticas de desarrollo de software y codificación segura, consulte lo siguiente:

• Asociación de confiabilidad del software de la industria del motor (MISRA) .
• Herramientas y métodos del Instituto de Ingeniería de Software (SEI) .
• Instituto Nacional de Estándares y Tecnología (NIST).

Prácticas de productos recomendadas

Google recomienda el uso de las siguientes prácticas recomendadas.

Pautas generales de lanzamiento

En general, se recomienda que cualquier producto conectado se inicie con la última versión del sistema operativo, y el fabricante debe intentar utilizar la versión más reciente del sistema operativo antes de lanzar el producto. Si bien es necesario bloquear la versión para impulsar la estabilidad antes de las pruebas y la validación, el fabricante debe equilibrar la estabilidad del producto obtenida de versiones anteriores del sistema operativo con versiones más nuevas del sistema operativo que tienen menos vulnerabilidades de seguridad conocidas y protecciones de seguridad mejoradas.

Las pautas recomendadas incluyen:

• Debido a los largos plazos de desarrollo inherentes al proceso de desarrollo de vehículos, es posible que los fabricantes deban lanzar con la versión del sistema operativo n-2 o anterior.
• Mantenga el cumplimiento de la compatibilidad de Android para cada versión lanzada del sistema operativo Android con una campaña inalámbrica (OTA).
• Implemente productos con capacidad de firmware Android por aire (FOTA) para actualizaciones rápidas y fáciles de usar para el cliente. FOTA debe realizarse utilizando las mejores prácticas de seguridad, como la firma de código y la conexión TLS entre el producto y el backoffice de TI.
• Envíe las vulnerabilidades de seguridad de Android identificadas de forma independiente al equipo de seguridad de Android.

Nota: Google ha contemplado notificaciones específicas de la industria o del tipo de dispositivo en los boletines de seguridad de Android. Sin embargo, debido a que Google no conoce el kernel, los controladores o los conjuntos de chips de un dispositivo determinado (vehículo, televisor, dispositivo portátil, teléfono, etc.), Google no tiene una forma determinista de etiquetar cualquier problema de seguridad determinado con un tipo de dispositivo. .

Directrices del ciclo del producto

El fabricante debe hacer todo lo posible para utilizar la última versión del sistema operativo o las actualizaciones de seguridad para la versión en uso durante las mejoras del ciclo del producto. Las actualizaciones se pueden realizar durante las actualizaciones periódicas del producto o para revisiones que aborden la calidad y/u otros problemas. Las prácticas recomendadas incluyen:

• Cree un plan para abordar las actualizaciones de controladores, kernel y protocolos.
• Utilice un método apropiado para la industria para proporcionar actualizaciones a los vehículos desplegados.

Documento de definición de compatibilidad (CDD)

El Documento de definición de compatibilidad (CDD) describe los requisitos para que un dispositivo se considere compatible con Android. El CDD es público y está disponible para todos; Puede descargar versiones de CDD desde Android 1.6 a la última versión desde source.android.com .

Satisfacer estos requisitos para un producto implica los siguientes pasos básicos:

1. El socio firma el Compromiso de compatibilidad de Android (ACC) con Google. Luego se asigna un Consultor de Soluciones Técnicas (TSC) como guía.
2. El socio completa la revisión de CDD para la versión del sistema operativo Android del producto.
3. El socio ejecuta y envía los resultados de CTS (descritos a continuación) hasta que los resultados sean aceptables para la compatibilidad con Android.

Conjunto de pruebas de compatibilidad (CTS)

La herramienta de prueba Compatibility Test Suite (CTS) verifica que la implementación de un producto sea compatible con Android y que se incluyan los últimos parches de seguridad. CTS es público, de código abierto y está disponible para todos; Puede descargar versiones de CTS desde Android 1.6 a la última versión desde source.android.com .

Cada versión de software de Android lanzada al público (imágenes de instalación de fábrica y de actualización de campo) debe demostrar la compatibilidad con Android a través de los resultados de CTS. Por ejemplo, si el dispositivo ejecuta Android 7.1, se debe hacer referencia a la última versión correspondiente de CDD 7.1 y CTS 7.1 cuando se crea y prueba una imagen de compilación con intención de lanzamiento. Se recomienda encarecidamente a los fabricantes que utilicen CTS de forma temprana y frecuente para identificar y solucionar problemas.

flujo de trabajo CTS

El flujo de trabajo de CTS implica configurar el entorno de prueba, ejecutar pruebas, interpretar resultados y comprender el código fuente de CTS. Las siguientes pautas están destinadas a ayudar a los usuarios de CTS (por ejemplo, desarrolladores, fabricantes) a utilizar CTS de manera eficaz y eficiente.

• Ejecute pruebas con frecuencia . CTS está diseñado como una herramienta automatizada que se integra en su sistema de construcción. La ejecución frecuente de CTS puede ayudarle a encontrar defectos de forma rápida y temprana cuando se produce una degradación o regresión del software.
• Descargue y examine el código fuente CTS . El código fuente completo de CTS es un software de código abierto que cualquiera puede descargar y utilizar (el código fuente descargado es totalmente compilable y ejecutable). Cuando una prueba falla en el dispositivo, examinar la sección correspondiente del código fuente puede ayudarle a identificar el motivo.
• Obtenga el último CTS . Las nuevas versiones de Android pueden actualizar el CTS con correcciones de errores, mejoras y nuevas pruebas. Verifique las descargas de CTS con frecuencia y actualice su programa CTS según sea necesario. El fabricante y Google acordarán qué versión CTS se utilizará para el lanzamiento del producto, ya que el producto debe congelarse en algún momento mientras el CTS continúa actualizándose.

Pasar el CTS

Para un producto compatible con Android, Google garantiza que los resultados de las pruebas de los informes CTS y Verificador CTS del dispositivo sean aceptables. En principio, todas las pruebas deben pasar. Sin embargo, una prueba que falla por motivos distintos a que el dispositivo no cumpla con los requisitos de compatibilidad de Android está sujeta a revisión por parte de Google. Durante este proceso:

1. El fabricante proporciona a Google los parches CTS propuestos, las validaciones de parches y las justificaciones para probar el argumento.
2. Google examina el material enviado y, si lo acepta, actualiza las pruebas CTS pertinentes para que el dispositivo pase la próxima revisión de CTS.

Si una prueba CTS falla repentinamente después de aplicar un parche de seguridad, el fabricante debe modificar el parche para que no rompa la compatibilidad O mostrar que la prueba es incorrecta y proporcionar una solución para la prueba (como se describe anteriormente).

El CTS permanece abierto a revisiones de correcciones de prueba. Por ejemplo, Android 4.4 sigue aceptando correcciones (consulte https://android-review.googlesource.com/#/c/273371/ ).

Preguntas frecuentes (FAQ)

P: ¿Quién es responsable de aplicar actualizaciones de seguridad a una implementación específica de Android?

R: El fabricante que proporciona directamente el dispositivo es responsable. Esta entidad no es Google, que publica actualizaciones de seguridad en AOSP y no para un dispositivo específico (como un vehículo).

P: ¿Cómo maneja Google los problemas de seguridad en Android?

R: Google investiga continuamente los problemas y desarrolla posibles soluciones, que Google pone a disposición de todos los niveles de API admitidos como parte del proceso regular de actualización de seguridad. Desde agosto de 2015, Google ha mantenido una cadencia regular de publicación de boletines y enlaces a actualizaciones de source.android.com ; Google también publica actualizaciones de seguridad como parte de las principales versiones del sistema operativo. Consulte también la política de backport de seguridad .

P: Si un fabricante integró todos los parches AOSP de un ASB pero no integró los parches del proveedor BSP mencionado en el mismo boletín, ¿puede aun así elevar el nivel de seguridad (por ejemplo, aplicar el parche correspondiente a la plataforma/compilación) ?

R: Para declarar un nivel de parche de seguridad (SPL) de Android, el fabricante debe abordar todos los problemas requeridos publicados en el Boletín de seguridad de Android ( incluidos los boletines anteriores ) y asignados a un SPL de Android en particular. Por ejemplo, un fabricante que utiliza el Boletín de seguridad de marzo de 2017 (2017-03-01 SPL) ha abordado todos los problemas requeridos documentados en el boletín de marzo de 2017 para ese SPL y todas las actualizaciones anteriores, incluidas las actualizaciones específicas del dispositivo para todos los boletines de seguridad de Android anteriores, incluidos las actualizaciones específicas del dispositivo asociadas al SPL 2017-02-05.

P: ¿Qué sucede cuando el fabricante no está de acuerdo con las actualizaciones de seguridad proporcionadas por el proveedor de BSP O cuando los proveedores no proporcionan las actualizaciones de seguridad exigidas por un ASB?

R: Un ASB describe las vulnerabilidades de seguridad (enumeradas mediante una lista de CVE) y, a menudo, proporciona pruebas de seguridad coincidentes. El objetivo es garantizar que las vulnerabilidades enumeradas ya no puedan reproducirse en un dispositivo y que el dispositivo pueda pasar las pruebas de seguridad asociadas. Como tal, el problema no es recibir una actualización de seguridad proporcionada por Google o un proveedor externo, sino que el fabricante acredite que el dispositivo no es vulnerable a la lista de CVE en el ASB. El fabricante es libre de utilizar las actualizaciones de seguridad proporcionadas o, si tiene un cambio que sea más apropiado para su dispositivo, utilizar ese cambio en su lugar.

Por ejemplo, considere un caso en el que Google aborda una vulnerabilidad de seguridad de AOSP mediante un cambio de código que permite que el componente siga siendo completamente funcional y compatible con el CDD. Si el fabricante determina que el componente no es necesario en el dispositivo o que no lo exige la CDD (o las pruebas de certificación relacionadas), el fabricante puede eliminar el componente para reducir las necesidades de servicio futuras y reducir la superficie de ataque. Aunque el fabricante no utilizó la actualización de seguridad proporcionada, sí se aseguró de que el dispositivo no fuera vulnerable al CVE documentado en el boletín de seguridad. Sin embargo, al desviarse de la actualización de seguridad recomendada, el fabricante corre el riesgo de abordar incorrectamente el problema, introducir nuevas vulnerabilidades de seguridad o reducir de otro modo la funcionalidad de la versión final.

Si bien trabajamos con todos los socios de SoC para garantizar que existan soluciones para todos los problemas en un ASB, recomendamos que los fabricantes obtengan un acuerdo de servicio con sus proveedores de SoC durante el ciclo de vida de un dispositivo. Los SoC pueden dejar de prestar servicio a un conjunto de chips antes de lo deseado, por lo que establecer acuerdos antes de la selección del conjunto de chips del dispositivo es una parte importante del proceso de lanzamiento del dispositivo.

Finalmente, en los casos en los que sea imposible adquirir directamente o crear de forma independiente una solución para un problema documentado en un ASB, un fabricante podría mantener el SPL de Android anterior y aun así agregar las nuevas correcciones disponibles a la compilación. Sin embargo, esta práctica eventualmente generará problemas con la certificación de compilación (ya que Android garantiza que el último nivel de parche de seguridad esté disponible en los dispositivos certificados). Google recomienda trabajar con su SoC con antelación para evitar esta práctica.

P: Si el fabricante determina que un elemento ASB no es aplicable a su producto, ¿aún es necesario aplicar o parchear el elemento para cumplir con los demás requisitos de Google o aprobar CTS?

R: No requerimos que se implementen parches para declarar un nivel de parche de seguridad (SPL) de Android; Requerimos que el fabricante certifique que su construcción no es vulnerable al problema.

Un ejemplo es cuando un componente que se está parcheando no existe en el sistema del fabricante, o cuando un componente se elimina del sistema del fabricante para solucionar un problema. En ese caso, el sistema puede ser compatible sin necesidad de que el fabricante aplique un parche.

Esto es fundamentalmente diferente de un fabricante que quiere, por ejemplo, arreglar sólo parches críticos, sin tomar otros parches aplicables que harían que una prueba de seguridad fallara. En este caso se supone que no se ha cumplido el SPL.