Эта страница переведена с помощью Cloud Translation API.

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

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

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

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

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

Это руководство не претендует на полноту; планируются дополнительные доработки. Отправьте отзыв по адресу Manufacturers-guide-android@googlegroups.com.

Глоссарий

Срок	Определение
АКК	Обязательство совместимости с Android. Ранее известное как Android Anti-Fragmentation Agreement (AFA).
АОСП	Android-проект с открытым исходным кодом
АСБ	Бюллетень по безопасности Android
БСП	Пакет поддержки платы
CDD	Документ определения совместимости
КТС	Набор тестов совместимости
ФОТА	Прошивка по воздуху
GPS	спутниковая система навигации
МИСРА	Ассоциация надежности программного обеспечения для автомобильной промышленности
НИСТ	Национальный институт стандартов и технологий
БД	Бортовая диагностика ( OBD-II является улучшением по сравнению с OBD-I как по возможностям, так и по стандартизации )
ОЕМ	Производитель оригинального оборудования
Операционные системы	Операционная система
СЭИ	Институт программной инженерии
SOC	Система на чипе
СОП	Начало производства
уровень звукового давления	Уровень исправления безопасности
СКДП	Система контроля давления в шинах

Об ОС Android

Android — это полный программный стек на базе Linux с открытым исходным кодом, предназначенный для различных устройств и форм-факторов. С момента своего первого выпуска в 2008 году Android стала самой популярной операционной системой («ОС»), на которой работает более 1,4 миллиарда устройств по всему миру (2016 год). Приблизительно 67% этих устройств используют Android 5.0 (Lollipop) или новее по состоянию на март 2017 года (более свежие данные доступны на панели инструментов Android ). В то время как подавляющее большинство устройств — это мобильные телефоны и планшеты, Android растет в смарт-часах, телевизорах и автомобильных информационно-развлекательных устройствах (IVI).

Количество приложений для Android, доступных в магазине Google Play, достигло 2,2+ миллиона (2016 г.). Разработка приложений для Android поддерживается программой совместимости с Android, которая определяет набор требований с помощью документа определения совместимости (CDD) и предоставляет инструменты тестирования с помощью набора тестов совместимости (CTS) . Программы совместимости с Android гарантируют, что любое приложение Android может работать на любом совместимом с Android устройстве, которое поддерживает необходимые для приложения функции.

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

О подключенных транспортных средствах (долгоживущий продукт Canon)

Транспортные средства начали подключаться с появлением 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 Security Patch. Хотя производители могут выбирать отдельные исправления безопасности из любого отдельного ASB, они должны исправить все необходимые проблемы в бюллетене, чтобы использовать уровень исправлений безопасности Android (SPL), связанный с бюллетенем (например, 2017-02-05). Производитель несет ответственность за выполнение обратной версии и выпуска безопасности для поддерживаемого продукта.
⑤	Полное обновление ОС	Повторение шага 3 (Полное обновление ОС), второе полное обновление ОС приводит продукт к Android X+4, через три года после начала срока службы автомобиля. В настоящее время производитель уравновешивает новые аппаратные требования последней версии Android с аппаратным обеспечением в продукте, и пользователь получает выгоду от обновленной ОС Android. Производитель выпускает обновление без обновлений безопасности, поэтому продукт теперь находится на уровне (X+4.y0) OS + Android Security Patch. В этом примере из-за аппаратных ограничений X+4 является последней основной версией Android, которая будет предоставлена для этого продукта, хотя ожидаемый срок службы автомобиля более 6 лет требует поддержки безопасности.
⑥	Обновление безопасности	Повторение шага 4 (Обновление безопасности). Перед производителем стоит задача взять обновления безопасности ASB из гораздо более поздней версии Android (X+6) и перенести некоторые или все эти обновления обратно в Android X+4. Производитель несет ответственность за слияние, интеграцию и выполнение обновлений (или заключение контрактов со сторонними организациями). Кроме того, производитель должен знать, что вопросы безопасности в версиях Android, которые больше не поддерживаются, не будут рассматриваться в ASB.
⑦	Обновление безопасности	Восемь лет производственного жизненного цикла автомобиля, четыре выпуска Android с момента последнего обновления ОС на шаге 5 (полное обновление ОС) и десять лет с момента спецификации Android X — бремя курирования и резервного копирования исправлений безопасности полностью лежит на производителе. те версии, которые старше трех лет после общедоступного выпуска уровня API.

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

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

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

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

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

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

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

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

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

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

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

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

Рабочий процесс CTS

Рабочий процесс CTS включает настройку среды тестирования, выполнение тестов, интерпретацию результатов и понимание исходного кода CTS. Следующие рекомендации призваны помочь пользователям CTS (например, разработчикам, производителям) эффективно и результативно использовать CTS.

Часто запускайте тесты . CTS разработан как автоматизированный инструмент, который интегрируется в вашу систему сборки. Частый запуск CTS может помочь вам быстро и на раннем этапе обнаружить дефекты, когда происходит деградация или регрессия программного обеспечения.
Загрузите и изучите исходный код CTS . Полный исходный код CTS представляет собой программное обеспечение с открытым исходным кодом, которое любой может загрузить и использовать (загруженный исходный код полностью готов к сборке и запуску). Когда тест на устройстве завершается сбоем, изучение соответствующего раздела исходного кода может помочь вам определить причину.
Получите последнюю версию CTS . Новые выпуски Android могут обновлять CTS исправлениями ошибок, улучшениями и новыми тестами. Часто проверяйте загрузку CTS и при необходимости обновляйте программу CTS. Производитель и Google должны согласовать версию 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, не предоставляются поставщиками?

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

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

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

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

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

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

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

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