В этом руководстве описаны рекомендации Google по применению исправлений безопасности, которые оцениваются набором тестов на совместимость Android (CTS). Он предназначен для производителей OEM-оборудования, совместимого с Android, которое будет поддерживаться более трех лет, например автомобилей, телевизоров, телеприставок и бытовой техники. Данное руководство не предназначено для конечных пользователей (например, владельцев транспортных средств).
Признания и отказ от ответственности
Это руководство не накладывает никаких юридических или договорных обязательств на Google или других производителей и не представляет собой набор требований. Скорее, это руководство представляет собой учебное пособие, описывающее рекомендуемые методы.
Обратная связь
Это руководство не претендует на полноту; планируются дополнительные изменения. Отправьте отзыв на адрес производителя-guide-android@googlegroups.com.
Глоссарий
| Срок | Определение |
|---|---|
| АСС | Обязательства по совместимости с Android. Ранее известное как Соглашение о борьбе с фрагментацией Android (AFA). |
| АОСП | Проект Android с открытым исходным кодом |
| АСБ | Бюллетень по безопасности Android |
| БСП | Пакет поддержки платы |
| CDD | Документ определения совместимости |
| КТС | Набор тестов совместимости |
| ФОТА | прошивка по воздуху |
| GPS | спутниковая система навигации |
| МИСРА | Ассоциация надежности программного обеспечения для автомобильной промышленности |
| НИСТ | Национальный институт стандартов и технологий |
| ОБД | бортовая диагностика ( OBD-II представляет собой улучшение по сравнению с OBD-I как по возможностям, так и по стандартизации ) |
| OEM | производитель оригинального оборудования |
| Операционные системы | Операционная система |
| СЭИ | Институт программной инженерии |
| SoC | система на чипе |
| СОП | начало производства |
| СПЛ | Уровень исправлений безопасности |
| TPMS | система контроля давления в шинах |
Об ОС Android
Android — это полный пакет программного обеспечения на базе Linux с открытым исходным кодом, предназначенный для различных устройств и форм-факторов. С момента своего первого выпуска в 2008 году Android стала самой популярной операционной системой (ОС), на которой установлено более 1,4 миллиарда устройств по всему миру (2016 год). По состоянию на март 2017 года примерно 67 % этих устройств используют Android 5.0 (Lollipop) или новее (более свежие данные доступны на панели управления Android ). В то время как подавляющее большинство устройств представляют собой мобильные телефоны и планшеты, Android растет в умных часах, телевизорах и автомобильных информационно-развлекательных устройствах (IVI).
Количество приложений Android, доступных в Google Play Store, достигло 2,2+ миллиона (2016 г.). Разработка приложений Android поддерживается программой совместимости Android, которая определяет набор требований с помощью документа определения совместимости (CDD) и предоставляет инструменты тестирования через набор тестов совместимости (CTS) . Программы совместимости Android гарантируют, что любое приложение Android может работать на любом Android-совместимом устройстве, поддерживающем необходимые функции приложения.
Google регулярно выпускает новые версии ОС, обновления безопасности ОС и информацию об обнаруженных уязвимостях. Производители должны проверить Бюллетень по безопасности Android на предмет применимости этих обновлений к продуктам, поддерживаемым ОС Android. Обзор безопасности, совместимости и систем сборки Android см. в следующих статьях:
- Защитите устройство Android
- Обновления безопасности и ресурсы
- Набор тестов совместимости
- Кодовые имена, теги и номера сборок
О подключенных транспортных средствах (канонические долгосрочные продукты)
Транспортные средства начали подключаться с появлением AM-радио в 1920-х годах. После этого количество внешних физических и беспроводных подключений начало расти, поскольку регулирующие органы и автопроизводители обратились к электронике для упрощения диагностики и обслуживания (например, порт OBD-II), повышения безопасности (например, TPMS) и достижения целей по экономии топлива. . Следующая волна подключений представила функции удобства водителя, такие как удаленный вход без ключа, телематические системы и расширенные информационно-развлекательные функции, такие как Bluetooth, Wi-Fi и проекция смартфона. Сегодня интегрированные датчики и возможности подключения (например, GPS) поддерживают системы безопасности и полуавтономного вождения.
По мере увеличения количества транспортных средств увеличивается и площадь потенциальной поверхности нападения транспортных средств. Соединения приносят с собой тот же набор проблем кибербезопасности, что и бытовая электроника. Однако, хотя перезагрузки, ежедневные обновления обновлений и необъяснимое поведение являются нормой для бытовой электроники, они несовместимы с продуктами с критически важными для безопасности системами, такими как транспортные средства.
Производители должны применять упреждающий подход для обеспечения постоянной безопасности и безопасности продукта на местах. Короче говоря, производители должны знать об известных уязвимостях безопасности в продукте и применять подход к их устранению, основанный на оценке рисков.
Обеспечьте долгосрочную безопасность
Подключенный автомобиль часто имеет один или несколько электронных блоков управления (ЭБУ), которые включают в себя несколько компонентов программного обеспечения, таких как ОС, библиотеки, утилиты и т. д. Производители должны отслеживать такие компоненты и выявлять известные опубликованные уязвимости с помощью упреждающего анализа, в том числе:
- Регулярная оценка продукта по базе данных общих уязвимостей и воздействий (CVE).
- Сбор информации об уязвимостях безопасности, связанных с продуктом.
- Тестирование безопасности.
- Активно анализируем бюллетени по безопасности Android.
Примеры обновлений ОС и исправлений безопасности (IVI под управлением Android):
Рисунок 1. Пример развертывания основных обновлений ОС и безопасности в течение срока службы автомобиля.
| # | Шаг | Деятельность |
|---|---|---|
① | Отдел развития | Производитель выбирает версию Android (Android X). В этом примере «Android X» становится основой того, что будет поставляться в автомобиле за два года до первоначального начала производства (SOP). |
| ② | Первоначальный запуск | За несколько месяцев до того, как Android X станет первой версией ОС, поставляемой в продукте, обновления безопасности берутся из бюллетеней безопасности Android (ASB) и, возможно, из других источников, которые производитель считает ценными. y2 = второй бюллетень по безопасности для версии X Android, примененный (перенесенный) производителем на Android X. Это обновление входит в состав продукта, и часы производства начинают отсчитываться в нулевой год с Android X.y2. В этом примере производитель принял решение не выпускать более позднюю годовую версию Android X+1. Причины для выпуска самой последней версии включают добавление новых функций, устранение новых уязвимостей безопасности и/или доставку сервисов Google или сторонних производителей, для которых требуется более новая версия Android. Причинами против поставки самой последней версии является нехватка времени, необходимого для процесса разработки и запуска транспортного средства, необходимого для интеграции, тестирования и проверки изменений, включая соответствие всем нормативным и сертификационным требованиям. |
| ③ | Полное обновление ОС | После SOP производитель выпускает обновление ОС Android X+2, которое является двумя выпусками Android после версии, использованной в исходном продукте (Android X0). Обновления безопасности ASB доступны для уровня API (на дату выпуска), поэтому обновление выходит как X+2.y0 примерно через 1,25 года после SOP. Это обновление ОС может быть совместимо или несовместимо с поставляемыми на рынок продуктами. Если да, то можно было бы разработать план обновления имеющихся транспортных средств. Если не заключено иное деловое соглашение, решение о полном обновлении ОС полностью остается на усмотрение производителя. |
| ④ | Обновление безопасности | Через два года после начала производства автомобиля производитель исправляет операционную систему Android X+2. Это решение основано на оценке рисков производителя. В качестве основы обновления производитель выбирает третье обновление безопасности ASB для выпуска X+2. Продукты, получившие обновление безопасности, теперь имеют уровень исправлений безопасности (X+2.y3) OS + Android. Хотя производители могут выбирать отдельные исправления безопасности из любого отдельного ASB, они должны исправить все необходимые проблемы в бюллетене, чтобы использовать уровень исправлений безопасности Android (SPL), связанный с бюллетенем (например, 2017-02-05). Ответственность за резервный перенос и выпуск системы безопасности для поддерживаемого продукта лежит на производителе. |
| ⑤ | Полное обновление ОС | Повтор шага 3 (Полное обновление ОС), второе полное обновление ОС переводит продукт на Android X+4, через три года после начала производства автомобиля. В настоящее время производитель балансирует требования к новому оборудованию последней версии Android с аппаратным обеспечением продукта, и пользователь получает выгоду от обновленной ОС Android. Производитель выпускает обновление без обновлений безопасности, поэтому продукт теперь находится на уровне (X+4.y0) OS + Android Security Patch Level. В этом примере из-за аппаратных ограничений X+4 является последней основной версией Android, которая будет предоставлена для этого продукта, хотя ожидаемый срок службы автомобиля более 6 лет все равно требует поддержки безопасности. |
| ⑥ | Обновление безопасности | Повтор шага 4 (Обновление безопасности). Перед производителем стоит задача взять обновления безопасности ASB из гораздо более поздней версии Android (X+6) и перенести некоторые или все эти обновления обратно на Android X+4. Производитель несет ответственность за слияние, интеграцию и выполнение обновлений (или заключает договор со сторонней организацией). Кроме того, производителю следует учитывать, что проблемы безопасности в версиях Android, которые больше не поддерживаются, не рассматриваются в ASB. |
| ⑦ | Обновление безопасности | Спустя восемь лет производственного жизненного цикла автомобиля, четыре выпуска Android с момента последнего обновления ОС на этапе 5 (полное обновление ОС) и десять лет с момента указания Android X, бремя разработки и резервного копирования исправлений безопасности полностью лежит на производителе. эти версии старше трех лет после общедоступного выпуска уровня API. |
Лучшие практики безопасности
Чтобы затруднить компрометацию безопасности, Google рекомендует и использует общепринятые передовые методы обеспечения безопасности и разработки программного обеспечения, как описано в разделе «Реализация безопасности» .
Рекомендации по безопасности
Рекомендуемые методы обеспечения безопасности включают:
- Используйте последние версии внешних библиотек и компонентов с открытым исходным кодом.
- Не включайте навязчивые функции отладки в выпускные версии ОС.
- Удалите неиспользуемую функциональность (чтобы уменьшить ненужную поверхность атаки).
- Используйте принцип наименьших привилегий и другие лучшие практики разработки приложений для Android .
Рекомендации по разработке программного обеспечения
Рекомендуемые методы безопасной разработки программного обеспечения на протяжении всего жизненного цикла системы включают:
- Выполняйте моделирование угроз, чтобы ранжировать и идентифицировать активы, угрозы и потенциальные меры по их устранению.
- Выполните анализ архитектуры/проектирования, чтобы обеспечить безопасность и надежность проекта.
- Выполняйте регулярные проверки кода, чтобы как можно скорее выявить антипаттерны и ошибки.
- Проектируйте, внедряйте и запускайте модульные тесты с высоким покрытием кода, включая:
- Функциональное тестирование (включая отрицательные тестовые случаи)
- Регулярное регрессионное тестирование (чтобы гарантировать, что исправленные ошибки не всплывут снова)
- Фазз-тестирование (как часть набора модульных тестов)
- Используйте инструменты статического анализа исходного кода (scan-build, lint и т. д.) для выявления потенциальных проблем.
- Используйте инструменты динамического анализа исходного кода, такие как AddressSanitizer, UndefineBehaviorSanitizer и FORTIFY_SOURCE (для собственных компонентов), чтобы выявлять и устранять потенциальные проблемы во время разработки системы.
- Иметь стратегию управления исходным кодом программного обеспечения и конфигурацией/версией выпуска.
- Иметь стратегию управления исправлениями для создания и развертывания исправлений программного обеспечения.
Политика поддержки безопасности
В настоящее время Google предоставляет активную поддержку резервного копирования обнаруженных и зарегистрированных уязвимостей безопасности в течение трех (3) лет с момента публичного выпуска уровня API . Активная поддержка состоит из следующего:
- Получайте и исследуйте отчеты об уязвимостях.
- Создавайте, тестируйте и выпускайте обновления безопасности.
- Предоставляйте периодические выпуски обновлений безопасности и подробную информацию о бюллетенях безопасности.
- Выполните оценку серьезности в соответствии с установленными рекомендациями.
По истечении трех лет с даты публичного выпуска уровня API Google рекомендует следующие рекомендации:
- Используйте стороннюю сторону (например, поставщика SoC или поставщика ядра) для поддержки обратного переноса обновлений безопасности ОС старше трех лет с момента выпуска API.
- Используйте стороннюю компанию для проверки кода с использованием общедоступных ASB. Хотя ASB выявляют уязвимости для поддерживаемой в данный момент версии, производитель может использовать предоставленную информацию для сравнения недавно выпущенных обновлений с предыдущими версиями. Эти данные можно использовать для анализа воздействия и потенциально создания аналогичных исправлений для версий ОС старше трех лет с момента выпуска API.
- При необходимости загрузите обновления безопасности в проект Android с открытым исходным кодом (AOSP).
- Производитель должен координировать обработку обновлений безопасности для кода конкретного поставщика (например, проприетарного кода конкретного устройства).
- Производитель должен присоединиться к группе уведомлений NDA Android Security Bulletin Partner Preview (требуется подписание юридических соглашений, таких как соглашение о неразглашении для разработчиков). Бюллетени должны включать:
- Объявления
- Сводная информация о проблемах по уровням исправлений, включая CVE и серьезность.
- Подробности об уязвимостях, где это необходимо.
Дополнительные ссылки
Инструкции по безопасному кодированию и методам разработки программного обеспечения см. в следующих разделах:
- Ассоциация по надежности программного обеспечения для автомобильной промышленности (MISRA) .
- Инструменты и методы Института программной инженерии (SEI) .
- Национальный институт стандартов и технологий (NIST).
Рекомендуемые методы работы с продуктом
Google рекомендует использовать следующие рекомендуемые методы.
Общие рекомендации по запуску
Обычно рекомендуется запускать любой подключенный продукт с последней версией ОС, и перед запуском продукта производитель должен попытаться использовать самую последнюю версию ОС. Хотя блокировка версии необходима для обеспечения стабильности перед тестированием и проверкой, производитель должен сбалансировать стабильность продукта, полученную от старых версий ОС, с новыми версиями ОС, которые имеют меньше известных уязвимостей безопасности и улучшенную защиту.
Рекомендуемые рекомендации включают:
- Из-за длительных сроков разработки, присущих процессу разработки транспортных средств, производителям может потребоваться запустить ОС версии n-2 или старше.
- Поддерживайте соответствие требованиям совместимости Android для каждой выпущенной версии ОС Android с помощью беспроводной кампании (OTA).
- Внедрите продукт с возможностью беспроводной передачи прошивки Android (FOTA) для быстрого и удобного для клиентов обновления. FOTA следует проводить с использованием передовых методов обеспечения безопасности, таких как подписание кода и соединение TLS между продуктом и бэк-офисом.
- Отправляйте независимо выявленные уязвимости безопасности Android команде безопасности Android.
Примечание. Google предусмотрел уведомления о типе устройства или конкретной отрасли в бюллетенях по безопасности Android. Однако, поскольку Google не знает ядра, драйверов или наборов микросхем для данного устройства (автомобиля, телевизора, носимого устройства, телефона и т. д.), у Google нет детерминированного способа обозначить любую конкретную проблему безопасности типом устройства. .
Рекомендации по циклу продукта
Производитель должен приложить все усилия для использования последней версии ОС или обновлений безопасности для используемой версии во время усовершенствований цикла продукта. Обновления могут выполняться во время периодических обновлений продукта или для исправлений, направленных на устранение проблем с качеством и/или других проблем. Рекомендуемые практики включают в себя:
- Создайте план по обновлению драйверов, ядра и протоколов.
- Используйте подходящий для отрасли метод предоставления обновлений развернутым транспортным средствам.
Документ определения совместимости (CDD)
Документ определения совместимости (CDD) описывает требования к устройству, которое должно считаться Android-совместимым. CDD является общедоступным и доступен каждому; Вы можете загрузить версии CDD от Android 1.6 до последней версии с сайта source.android.com .
Удовлетворение этих требований к продукту включает в себя следующие основные этапы:
- Партнер подписывает с Google Обязательство по совместимости Android (ACC). Затем консультант по техническим решениям (TSC) назначается в качестве руководства.
- Партнер завершает проверку CDD для версии ОС Android продукта.
- Партнер запускает и отправляет результаты CTS (описанные ниже) до тех пор, пока результаты не станут приемлемыми для совместимости с Android.
Набор тестов совместимости (CTS)
Инструмент тестирования Compatibility Test Suite (CTS) проверяет совместимость реализации продукта с Android и наличие последних исправлений безопасности. CTS является общедоступным продуктом с открытым исходным кодом и доступен каждому; Вы можете загрузить версии CTS от Android 1.6 до последней версии с сайта source.android.com .
Каждая общедоступная сборка программного обеспечения Android (образы заводской установки и обновления на месте) должна подтверждать совместимость Android с помощью результатов CTS. Например, если устройство работает под управлением Android 7.1, при создании и тестировании образа сборки с намерением выпуска следует ссылаться на последнюю соответствующую версию CDD 7.1 и CTS 7.1. Производителям настоятельно рекомендуется использовать CTS как можно раньше и чаще для выявления и устранения проблем.
Рабочий процесс CTS
Рабочий процесс CTS включает настройку среды тестирования, запуск тестов, интерпретацию результатов и понимание исходного кода CTS. Следующие рекомендации призваны помочь пользователям CTS (например, разработчикам, производителям) эффективно и результативно использовать CTS.
- Часто запускайте тесты . CTS спроектирован как автоматизированный инструмент, который интегрируется в вашу систему сборки. Частое выполнение CTS может помочь вам быстро и на ранней стадии обнаружить дефекты в случае ухудшения или регресса программного обеспечения.
- Загрузите и изучите исходный код CTS . Полный исходный код CTS — это программное обеспечение с открытым исходным кодом, которое каждый может загрузить и использовать (загруженный исходный код полностью готов к сборке и запуску). Если тест на устройстве не пройден, изучение соответствующего раздела исходного кода может помочь вам определить причину.
- Получите последнюю версию CTS . В новых выпусках Android CTS может содержать исправления ошибок, улучшения и новые тесты. Регулярно проверяйте загрузку CTS и при необходимости обновляйте программу CTS. Производитель и Google должны согласовать версию CTS, которая будет использоваться для запуска продукта, поскольку в какой-то момент продукт должен быть заморожен, пока CTS продолжает обновляться.
Пройти CTS
Для продуктов, совместимых с Android, Google гарантирует, что результаты испытаний CTS устройства и отчетов CTS Verifier являются приемлемыми. В принципе, все тесты должны пройти. Однако тест, который не пройден по причинам, не связанным с несоответствием устройства требованиям совместимости Android, подлежит проверке Google. Во время этого процесса:
- Производитель предоставляет Google предлагаемые исправления CTS, проверки исправлений и обоснования для доказательства своих аргументов.
- Google проверяет отправленный материал и, если он принят, обновляет соответствующие тесты CTS, чтобы устройство прошло следующую версию CTS.
Если тест CTS внезапно дает сбой после применения исправления безопасности, производитель должен изменить исправление, чтобы оно не нарушало совместимость, ИЛИ показать, что тест ошибочен, и предоставить исправление для теста (как описано выше).
CTS остается открытым для проверки тестовых исправлений. Например, Android 4.4 продолжает принимать исправления (см. https://android-review.googlesource.com/#/c/273371/ ).
Часто задаваемые вопросы (FAQ)
Вопрос: Кто отвечает за установку обновлений безопасности для конкретной реализации Android?
О: Ответственность несет производитель, непосредственно предоставивший устройство. Эта организация не является компанией Google, которая публикует обновления безопасности в AOSP, а не для конкретного устройства (например, автомобиля).
Вопрос: Как Google решает проблемы безопасности в Android?
Ответ: Google постоянно исследует проблемы и разрабатывает возможные исправления, которые Google предоставляет всем поддерживаемым уровням API в рамках регулярного процесса обновления безопасности. С августа 2015 года Google регулярно публикует бюллетени и ссылки на обновления на source.android.com ; Google также публикует обновления безопасности как часть основных выпусков ОС. См. также политику резервного копирования безопасности .
Вопрос: Если производитель интегрировал все исправления AOSP из ASB, но не интегрировал исправления от поставщика BSP, упомянутые в том же бюллетене, может ли он повысить уровень безопасности (например, применить соответствующий патч к платформе/сборке)?
О: Чтобы объявить уровень исправлений безопасности Android (SPL), производитель должен устранить все необходимые проблемы, опубликованные в Бюллетене по безопасности Android ( включая предыдущие бюллетени ) и сопоставленные с конкретным Android SPL. Например, производитель, использующий бюллетень по безопасности за март 2017 г. (2017-03-01 SPL), устранил все необходимые проблемы, описанные в бюллетене по безопасности за март 2017 г. для этого SPL и всех предыдущих обновлений, включая обновления для конкретных устройств, для всех предыдущих бюллетеней по безопасности Android, включая обновления для конкретных устройств, связанные с SPL от 2017-02-05.
Вопрос: Что происходит, если производитель не согласен с обновлениями безопасности, предоставляемыми поставщиком BSP, ИЛИ когда обновления безопасности, требуемые ASB, не предоставляются поставщиками?
Ответ: ASB описывает уязвимости безопасности (перечисленные в списке CVE) и часто предоставляет соответствующие тесты безопасности. Цель состоит в том, чтобы гарантировать, что перечисленные уязвимости больше не могут быть воспроизведены на устройстве и что устройство может пройти соответствующие тесты безопасности. Таким образом, проблема заключается не в обновлении безопасности, предоставленном Google или сторонним поставщиком, а в том, что производитель подтверждает, что устройство не уязвимо для списка CVE в ASB. Производитель может использовать предоставленные обновления безопасности или, если у него есть изменение, более подходящее для его устройства, использовать его вместо этого.
Например, рассмотрим случай, когда Google устраняет уязвимость безопасности AOSP, используя изменение кода, которое позволяет компоненту оставаться полностью функциональным и совместимым с CDD. Если производитель определяет, что компонент не требуется на устройстве или не требуется CDD (или соответствующим сертификационным тестированием), производитель может удалить компонент, чтобы уменьшить будущие потребности в обслуживании и уменьшить вероятность атаки. Хотя производитель не использовал предоставленное обновление безопасности, он гарантировал, что устройство не уязвимо для CVE, описанного в бюллетене по безопасности. Однако, отклоняясь от рекомендованного обновления безопасности, производитель рискует неправильно решить проблему, ввести новые уязвимости безопасности или иным образом снизить функциональность финальной сборки.
Хотя мы работаем со всеми партнерами SoC, чтобы обеспечить наличие исправлений для всех проблем в ASB, мы рекомендуем производителям заключить соглашение об обслуживании со своими поставщиками SoC на протяжении всего жизненного цикла устройства. SoC могут прекратить обслуживание набора микросхем раньше, чем хотелось бы, поэтому заключение соглашений до выбора набора микросхем устройства является важной частью процесса запуска устройства.
Наконец, в тех случаях, когда невозможно напрямую получить или самостоятельно создать исправление проблемы, описанной в ASB, производитель может сохранить предыдущую версию Android SPL и при этом добавить в сборку новые доступные исправления. Однако такая практика в конечном итоге приведет к проблемам с сертификацией сборки (поскольку Android гарантирует, что на сертифицированных устройствах будет доступен последний уровень исправлений безопасности). Google рекомендует заранее поработать с вашей SoC, чтобы избежать этой практики.
Вопрос: Если производитель определит, что элемент ASB неприменим к его продукту, нужно ли применять или исправлять этот элемент, чтобы он соответствовал другим требованиям Google или прошел CTS?
О: Мы не требуем принятия исправлений для объявления уровня исправлений безопасности Android (SPL); мы требуем, чтобы производитель подтвердил, что его сборка не подвержена этой проблеме.
Одним из примеров является ситуация, когда исправляемый компонент не существует в системе производителя или компонент удаляется из системы производителя для устранения проблемы. В этом случае система может соответствовать требованиям, не требуя от производителя установки исправления.
Это фундаментально отличается от того, когда производитель хочет, например, исправлять только критические исправления, не устанавливая при этом другие применимые исправления, которые могут привести к сбою теста безопасности. В этом случае предполагается, что SPL не был достигнут.