Есть ли сертификат для указания уровня безопасности устройств IoT?


11

Есть ли надежный сертификат для устройств IoT, который можно использовать для сравнения обеспечиваемой безопасности этих устройств? 1

В настоящее время среда IoT полностью разбросана по различным протоколам, стандартам и собственным решениям. С другой стороны, устройства IoT попадают в бот-сети как мухи . Существует ли какой-либо стандарт, которому клиенты могут доверять, чтобы устройство соответствовало определенному уровню безопасности? Может быть, даже сертификат ручается за предоставленную безопасность?

Если нет действующего стандарта, есть ли многообещающие инициативы по созданию такого стандарта?


1: Отказ от ответственности: это основано на этом вопросе Зоны 51 от пользователя, который, по-видимому, не связался с сайтом в стадии обязательства. Я хочу опубликовать его, чтобы помочь определить область сайта.

Ответы:


10

UL (ранее Underwriters Laboratories) предоставляет Программу обеспечения кибербезопасности для подтверждения того, что устройство Интернета вещей, по их мнению, защищено от большинства основных угроз.

По мнению Ars Technica, UL пользуется большим уважением в своих процессах сертификации :

UL, 122-летняя организация по стандартам безопасности, чьи различные марки (UL, ENEC и т. Д.) Сертифицируют минимальные стандарты безопасности в таких разных областях, как электропроводка, чистящие средства и даже пищевые добавки, в настоящее время занимается кибербезопасностью Интернета. Устройства Things (IoT) с новой сертификацией UL 2900.

UL описывают свою сертификацию как включающую:

  • Fuzz-тестирование продуктов для выявления уязвимостей нулевого дня по всем интерфейсам
  • Оценка известных уязвимостей в продуктах, которые не были исправлены с использованием схемы Common Enulnerability Enumerations (CVE)
  • Идентификация известных вредоносных программ по продуктам
  • Статический анализ исходного кода на наличие слабых сторон программного обеспечения, выявленных с помощью Common Weakness Enumerations (CWE)
  • Статический двоичный анализ на наличие слабых сторон программного обеспечения, выявленных с помощью Common Weakness Enumerations (CWE), программного обеспечения с открытым исходным кодом и сторонних библиотек
  • Определенные меры безопасности, определенные для использования в продуктах, которые уменьшают риск безопасности [...]
  • Тестирование структурированного проникновения продуктов на основе недостатков, выявленных в других тестах
  • Оценка риска снижения безопасности продукта, предназначенного для продуктов.

Тем не менее, точный процесс, в котором UL тщательно исследует устройства, неясен (если только вы не заплатите, чтобы купить полный набор спецификаций), как отмечает Ars Technica (и критикует):

Когда Арс попросил копию документов UL 2900, чтобы поближе познакомиться со стандартом, UL (ранее известная как Underwriters Laboratories) отказалась, указав, что если мы хотим приобрести копию - розничная цена, около 600 фунтов / 800 долларов за полную установить - мы могли это сделать. Надо полагать, что независимые исследователи в области безопасности также могут стать розничными клиентами UL.

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

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


3

Я хочу добавить к ответу Aurora0001, что мы можем защитить только от известных угроз.

Недавно мы видели атаки Spectre и Meltdown на оборудование . Хотя процессоры Intel обычно не используются в устройствах IoT, мы, вероятно, обнаружим проблемы с безопасностью оборудования IoT в будущем. Ранее мы рассматривали Rowhammer и Heartbleed как общие ошибки системного класса, затрагивающие огромное количество систем. По мере роста IoT, я считаю, что такие уязвимости станут более распространенным явлением.

Поэтому я бы сосредоточился не столько на сертификации безопасности, сколько на:

  • Открытость, так что третьи лица могут оценить программное обеспечение.
  • Заявленные сроки поддержки, где производитель гарантирует обновления безопасности
  • Возможность обновления, включая автоматическое обновление в качестве настройки по умолчанию.

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


Heartbleed может быть ошибкой системного класса с точки зрения развертывания системы, но это все еще ошибка в определенной части программного обеспечения, которую просто нужно обновить. Лучшими примерами будут атаки на сам протокол, такие как BEAST и CRIME.
Жиль "ТАК - перестань быть злым"

Дело в том, что ошибки могут быть обнаружены в самых неожиданных местах (ЦП) и в хорошо известном программном обеспечении (Heartbleed), поэтому нам необходимо исправление и обновление программного обеспечения. Но да - есть множество ошибок на выбор.
Видарло

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

2
@Helmar К сожалению, серьезные сертификаты в значительной степени тяжелый процесс. Сертификация начальной версии и процесса обновления - это одно, но сертификация каждого обновления перед его развертыванием добавляет значительные накладные расходы, что затрудняет создание хорошего процесса сертификации (где обновления безопасности должны быть сертифицированы после факта, что противоречит действительности). зерно сертификации, так как это означает, что на устройстве будут работать несертифицированные версии).
Жиль "ТАК - перестань быть злым"

@ Жиль Я согласен, что можно сертифицировать только качественные процессы разработки программного обеспечения или что-то в этом роде. Сертификация каждой версии программного обеспечения на самом деле не вариант.
Хельмар
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.