Руководство производителя по долгосрочной безопасности Android

В этом руководстве описаны рекомендуемые Google лучшие практики применения обновлений безопасности, которые оцениваются с помощью набора тестов совместимости Android (CTS). Оно предназначено для производителей совместимого с Android OEM-оборудования (производителей), поддержка которого будет продолжаться более трех лет, например, автомобилей, телевизоров, телеприставок и бытовой техники. Это руководство не предназначено для конечных пользователей (например, владельцев транспортных средств).

Благодарности и оговорки

Данное руководство не накладывает на Google или других производителей никаких юридических или договорных обязательств и не является набором требований. Скорее, это учебное пособие, описывающее рекомендуемые методы работы.

Обратная связь

Данное руководство не претендует на исчерпывающий характер; планируются дальнейшие доработки. Отзывы и предложения отправляйте по адресу manufacturers-guide-android@googlegroups.com.

Глоссарий

О системе Android

Android — это программная платформа с открытым исходным кодом, основанная на Linux и предназначенная для различных устройств и форм-факторов. С момента своего первого выпуска в 2008 году Android стал самой популярной операционной системой (ОС), используемой на более чем 1,4 миллиардах устройств по всему миру (2016 год). Примерно 67% этих устройств используют Android 5.0 (Lollipop) или более новые версии по состоянию на март 2017 года (более свежие данные доступны на панели управления 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) поддерживают системы безопасности и полуавтономного вождения.

По мере увеличения количества подключений транспортных средств увеличивается и потенциальная площадь поверхности атаки на них. Подключения порождают схожий набор проблем кибербезопасности, как и в случае с бытовой электроникой. Однако, если перезагрузки, ежедневные обновления и необъяснимое поведение являются нормой для бытовой электроники, то для продуктов с критически важными системами, таких как транспортные средства, это непостоянно.

Производители должны проявлять инициативу, чтобы обеспечить постоянную безопасность и надежность продукции в процессе эксплуатации. Короче говоря, производители должны быть осведомлены об известных уязвимостях в системе безопасности продукта и применять подход, основанный на оценке рисков, для их устранения.

Обеспечьте долгосрочную безопасность

В подключенном автомобиле часто имеется один или несколько электронных блоков управления (ЭБУ), включающих в себя множество программных компонентов, таких как операционная система, библиотеки, утилиты и т. д. Производители должны отслеживать такие компоненты и выявлять известные опубликованные уязвимости с помощью упреждающего анализа, включая:

• Регулярная проверка продукта на соответствие базе данных Common Vulnerabilities and Exposures (CVE).
• Сбор разведывательной информации о недостатках безопасности, связанных с продуктом.
• Тестирование безопасности.
• Активно анализирую бюллетени безопасности Android.

Примеры обновлений ОС и исправлений безопасности (IVI под управлением Android):

Рисунок 1. Примерный порядок развертывания основных обновлений ОС и безопасности в течение срока службы автомобиля.

лучшие практики обеспечения безопасности

Чтобы затруднить компрометацию безопасности, Google рекомендует и использует общепринятые передовые методы обеспечения безопасности и разработки программного обеспечения, как описано в разделе «Внедрение безопасности» .

Правила безопасности

Рекомендуемые методы обеспечения безопасности включают:

• Используйте последние версии внешних библиотек и компонентов с открытым исходным кодом.
• Не следует включать навязчивые функции отладки в релизные версии операционной системы.
• Удалите неиспользуемый функционал (чтобы уменьшить ненужную поверхность атаки).
• Используйте принцип минимальных привилегий и другие лучшие практики разработки приложений для Android .

рекомендации по разработке программного обеспечения

К рекомендуемым методам безопасной разработки программного обеспечения на протяжении всего жизненного цикла системы относятся:

• Проведите моделирование угроз для ранжирования и выявления активов, угроз и потенциальных мер по их смягчению.
• Проведите архитектурную/проектную экспертизу для обеспечения безопасности и надежности конструкции.
• Регулярно проводите проверку кода, чтобы как можно быстрее выявлять антипаттерны и ошибки.
• Разработка, реализация и запуск модульных тестов с высоким уровнем покрытия кода, включая:
  • Функциональное тестирование (включая негативные тестовые примеры)
  • Регулярное регрессионное тестирование (для предотвращения повторного обнаружения исправленных ошибок).
  • Фаззинг-тестирование (в рамках набора модульных тестов)
• Используйте инструменты статического анализа исходного кода (scan-build, lint и т. д.) для выявления потенциальных проблем.
• Используйте инструменты динамического анализа исходного кода, такие как AddressSanitizer, UndefinedBehaviorSanitizer и FORTIFY_SOURCE (для нативных компонентов), чтобы выявлять и устранять потенциальные проблемы в процессе разработки системы.
• Разработайте стратегию управления исходным кодом программного обеспечения и конфигурацией/версиями релизов.
• Разработайте стратегию управления обновлениями для генерации и развертывания исправлений программного обеспечения.

политика обратной связи в сфере безопасности

В настоящее время Google оказывает активную поддержку переносу обнаруженных и зарегистрированных уязвимостей безопасности в течение трех (3) лет с момента публичного выпуска API . Активная поддержка включает в себя следующее:

1. Принимать и расследовать сообщения об уязвимостях.
2. Создавайте, тестируйте и выпускайте обновления безопасности.
3. Обеспечьте регулярный выпуск обновлений безопасности и подробную информацию о бюллетенях безопасности.
4. Проведите оценку степени тяжести в соответствии с установленными рекомендациями.

Спустя три года после публичного выпуска API компания Google рекомендует следующие меры:

• Для поддержки обратной совместимости обновлений безопасности ОС, выпущенных более трех лет назад с момента выхода API, используйте стороннего разработчика (например, поставщика SoC или разработчика ядра).
• Для проведения анализа кода с использованием общедоступных ASB-файлов можно обратиться к сторонней организации. Хотя ASB-файлы выявляют уязвимости для поддерживаемых в настоящее время версий, производитель может использовать предоставленную информацию для сравнения новых обновлений с предыдущими версиями. Эти данные можно использовать для анализа влияния и потенциального создания аналогичных исправлений для версий ОС, выпущенных более трех лет назад с момента выхода API.
• При необходимости загружайте обновления безопасности в проект Android Open Source Project (AOSP).
• Производитель должен координировать обработку обновлений безопасности для кода, специфичного для конкретного поставщика (например, для проприетарного кода, специфичного для устройства).
• Производителю следует присоединиться к группе уведомлений NDA Android Security Bulletin Partner Preview (требуется подписание юридических соглашений, таких как соглашение о неразглашении информации для разработчиков). В бюллетенях должны содержаться следующие сведения:
  • Объявления
  • Сводка проблем по уровням исправлений, включая CVE и степень серьезности.
  • Подробную информацию об уязвимостях, где это уместно.

Дополнительные ссылки

Инструкции по безопасному программированию и методам разработки программного обеспечения см. в следующих источниках:

• Ассоциация по надежности программного обеспечения автомобильной промышленности (MISRA) .
• Инструменты и методы Института программной инженерии (SEI) .
• Национальный институт стандартов и технологий (NIST).

Рекомендуемые методы работы с продукцией

Google рекомендует использовать следующие методы.

Общие рекомендации по запуску

Как правило, рекомендуется выпускать любое подключенное устройство с последней версией ОС, и производитель должен стремиться использовать самую последнюю версию ОС перед выпуском продукта. Хотя ограничение версии необходимо для обеспечения стабильности перед тестированием и проверкой, производитель должен найти баланс между стабильностью продукта, достигаемой за счет более старых версий ОС, и более новыми версиями ОС, которые имеют меньше известных уязвимостей безопасности и усиленную защиту.

Рекомендуемые рекомендации включают:

• В связи с длительными сроками разработки, присущими процессу создания автомобилей, производителям может потребоваться выпускать продукцию с версией ОС n-2 или более старой.
• Обеспечьте соответствие требованиям совместимости Android для каждой выпущенной версии ОС Android с помощью кампании беспроводного обновления (OTA).
• Внедрите функцию беспроводного обновления прошивки Android (FOTA) для быстрых и удобных для пользователей обновлений. Обновление FOTA следует проводить с использованием лучших практик безопасности, таких как цифровая подпись кода и TLS-соединение между продуктом и ИТ-подразделением.
• Сообщайте о выявленных независимыми экспертами уязвимостях безопасности Android команде разработчиков Android Security.

Примечание: Google рассматривала возможность добавления уведомлений о типах устройств или отраслевой специфике в бюллетени безопасности Android. Однако, поскольку Google не знает ядро, драйверы или чипсеты для конкретного устройства (автомобиль, телевизор, носимое устройство, телефон и т. д.), у Google нет детерминированного способа присвоить любой проблеме безопасности метку типа устройства.

рекомендации по жизненному циклу продукта

Производитель должен прилагать все усилия для использования последней версии ОС или обновлений безопасности для используемой версии в процессе обновления продукта. Обновления могут выполняться в рамках периодических обновлений продукта или в качестве исправлений для устранения проблем с качеством и/или других проблем. Рекомендуемые методы включают:

• Разработайте план по обновлению драйверов, ядра и протоколов.
• Используйте соответствующий отраслевой метод для обновления программного обеспечения развернутых транспортных средств.

Документ, определяющий совместимость (CDD)

Документ определения совместимости (CDD) описывает требования к устройству, которое считается совместимым с Android. CDD является общедоступным документом; вы можете загрузить версии CDD, начиная с Android 1.6 и заканчивая последней версией, с сайта source.android.com .

Удовлетворение этих требований к продукту включает в себя следующие основные этапы:

1. Партнер подписывает с Google соглашение о совместимости с Android (Android Compatibility Commitment, ACC). После этого назначается технический консультант (Technical Solution Consultant, TSC), который будет выступать в качестве наставника.
2. Партнер завершил проверку CDD для версии ОС Android данного продукта.
3. Партнер запускает и отправляет результаты 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. В ходе этого процесса:

1. Производитель предоставляет Google предлагаемые исправления CTS, результаты проверки этих исправлений и обоснования, подтверждающие его аргумент.
2. Google рассматривает представленные материалы и, в случае принятия, обновляет соответствующие тесты CTS, чтобы устройство прошло проверку в следующей редакции CTS.

Если после применения обновления безопасности тест CTS внезапно перестает давать сбои, производитель должен изменить обновление таким образом, чтобы оно не нарушало совместимость, ИЛИ показать, что тест неверен, и предоставить исправление для теста (как описано выше).

Центр тестирования CTS остается открытым для проверки исправлений в тестах. Например, Android 4.4 продолжает принимать исправления (см. https://android-review.googlesource.com/c/platform/cts/+/273371 ).

Часто задаваемые вопросы (FAQ)

В: Кто отвечает за применение обновлений безопасности к конкретной версии Android?

A: Ответственность несет производитель, непосредственно предоставляющий устройство. Это не Google, который публикует обновления безопасности в AOSP, а не для конкретного устройства (например, автомобиля).

В: Как Google решает проблемы безопасности в Android?

A: Google постоянно исследует проблемы и разрабатывает потенциальные решения, которые Google предоставляет для всех поддерживаемых уровней API в рамках регулярного процесса обновления безопасности. С августа 2015 года Google регулярно публикует бюллетени и ссылки на обновления на source.android.com ; Google также публикует обновления безопасности в рамках основных релизов ОС. См. также политику обратной совместимости в области безопасности .

В: Если производитель интегрировал все патчи AOSP из ASB, но не интегрировал патчи от поставщика BSP, упомянутые в том же бюллетене, может ли он все равно повысить уровень безопасности (например, применить соответствующий патч к платформе/сборке) ?

A: Чтобы объявить уровень исправлений безопасности Android (SPL), производитель должен устранить все необходимые проблемы, описанные в бюллетене безопасности Android ( включая предыдущие бюллетени ) и соответствующие конкретному уровню исправлений безопасности Android. Например, производитель, использующий бюллетень безопасности от марта 2017 года (SPL от 01.03.2017), устранил все необходимые проблемы, задокументированные в бюллетене от марта 2017 года для этого уровня исправлений, а также все предыдущие обновления, включая обновления для конкретных устройств, для всех предыдущих бюллетеней безопасности Android, включая обновления для конкретных устройств, связанные с уровнем исправлений безопасности от 05.02.2017.

В: Что происходит, когда производитель не согласен с обновлениями безопасности, предоставляемыми поставщиком BSP, ИЛИ когда поставщики не предоставляют обновления безопасности, предписанные ASB?

A: В ASB описываются уязвимости безопасности (перечисленные в виде списка CVE) и часто приводятся соответствующие тесты безопасности. Цель состоит в том, чтобы убедиться, что перечисленные уязвимости больше не могут быть воспроизведены на устройстве и что устройство может пройти соответствующие тесты безопасности. Таким образом, вопрос заключается не в использовании обновления безопасности, предоставленного Google или сторонним поставщиком, а в подтверждении производителем того, что устройство не уязвимо для списка CVE, указанного в ASB. Производитель может использовать предоставленные обновления безопасности или, если у него есть изменение, более подходящее для его устройства, использовать его вместо обновления.

Например, рассмотрим случай, когда Google устраняет уязвимость безопасности AOSP, изменяя код таким образом, чтобы компонент оставался полностью функциональным и соответствовал требованиям CDD. Если производитель определяет, что компонент не нужен на устройстве или не требуется в соответствии с CDD (или соответствующими сертификационными тестами), он может удалить компонент, чтобы уменьшить потребность в будущем обслуживании и снизить поверхность атаки. Хотя производитель не использовал предоставленное обновление безопасности, он гарантировал, что устройство не уязвимо для CVE, описанного в бюллетене безопасности. Однако, отклоняясь от рекомендованного обновления безопасности, производитель рискует неправильно решить проблему, создать новые уязвимости безопасности или иным образом снизить функциональность финальной сборки.

Хотя мы работаем со всеми партнерами SoC, чтобы гарантировать наличие исправлений для всех проблем в ASB, мы рекомендуем производителям заключать соглашения об обслуживании со своими поставщиками SoC на весь жизненный цикл устройства. SoC могут прекратить обслуживание чипсета раньше, чем хотелось бы, поэтому заключение соглашений до выбора чипсета устройства является важной частью процесса запуска устройства.

Наконец, в случаях, когда невозможно напрямую получить или самостоятельно создать исправление для проблемы, описанной в ASB, производитель может сохранить предыдущую версию Android SPL и при этом добавить новые доступные исправления в сборку. Однако такая практика в конечном итоге приведет к проблемам с сертификацией сборки (поскольку Android гарантирует наличие последнего уровня исправлений безопасности на сертифицированных устройствах). Google рекомендует заранее согласовать этот вопрос со своим SoC, чтобы избежать подобной практики.

В: Если производитель определяет, что элемент ASB неприменим к его продукту, нужно ли все равно применять или вносить в него исправления, чтобы соответствовать другим требованиям Google или пройти проверку CTS?

A: Для объявления уровня исправлений безопасности Android (SPL) нам не требуется установка патчей; нам необходимо, чтобы производитель подтвердил, что его сборка не уязвима для этой проблемы.

Например, бывает так, что компонент, для которого устанавливается обновление, отсутствует в системе производителя, или компонент удаляется из системы производителя для устранения проблемы. В этом случае система может соответствовать требованиям без необходимости установки обновления производителем.

Это принципиально отличается от ситуации, когда производитель, например, хочет исправить только критически важные исправления, не применяя другие применимые исправления, которые могут привести к провалу теста безопасности. В этом случае предполагается, что требование SPL не выполнено.