Поиск универсального стандарта безопасности IoT

«Почему нет универсального стандарта безопасности для Интернета вещей?» Это довольно распространенный вопрос, который наша группа по решениям для Интернета вещей часто слышит от разработчиков Интернета вещей, лиц, принимающих решения, и экспертов-исследователей, независимо от уровня их знаний в этой области. И это справедливо, в конце концов, существуют стандарты практически для любой технологической среды, так почему бы не IoT?

Легкий ответ заключается в том, что Интернет вещей слишком разнообразен, чтобы иметь установленный стандарт. Хотя это правда, это не дает адекватного объяснения темы с требуемым уровнем тонких деталей. Мы обнаружили, что существует как минимум три фактора, влияющих на универсальные стандарты Интернета вещей:неоднородность устройств, конкретные вертикальные стандарты и новые архитектурные концепции. Давайте посмотрим на каждый.

Гетерогенный характер устройств Интернета вещей

IoT-устройства разнообразны. Хотя большинство людей думают об устройстве Интернета вещей как о чем-то, что они могут видеть, касаться и взаимодействовать, например, о смартфоне, на самом деле это гораздо больше. Часто они вообще не имеют человеческого взаимодействия. Это датчики, которые взаимодействуют с окружающей средой, чтобы сообщать о температуре в контролируемой среде, сообщать, когда дверь открыта или закрыта на удаленном объекте, или сообщать о состоянии включения / выключения переключателя света в интеллектуальном здании. Это шлюзы, которые защищают каналы связи, передающие данные от конечной точки в облако, или исполнительные механизмы, которые выключают эти индикаторы, когда никого нет. Они также являются критически важными объектами инфраструктуры, обеспечивающими энергоснабжение, поддержание производственной среды или обслуживание телекоммуникационных узлов.

Существует бесчисленное множество типов устройств IoT, и то, как каждый из них используется в своей среде - его вариант использования - также уникален. Каждый из них имеет разные технические возможности и потенциально может быть интегрирован с рядом платформ Интернета вещей. Среды и устройства Интернета вещей иногда имеют ограниченную полосу пропускания или ограниченную емкость устройства (аккумулятор, хранилище, вычислительные ресурсы). Платформы устройств Интернета вещей также имеют огромное разнообразие программных платформ по сравнению с настольными компьютерами. В настольных компьютерах вы говорите только о нескольких операционных системах (ОС), тогда как на стороне устройства количество встроенных систем намного больше, учитывая индивидуальный характер многих платформ.

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

Лидеры отрасли, придерживающиеся специфических стандартов

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

Иногда эти стандарты со временем развиваются. Мы можем увидеть эту эволюцию, если посмотрим на развертывание на основе PKI в IoT и сравним его с тем, как PKI была стандартизирована в мире веб-PKI сегодня. В веб-PKI у нас есть общедоступные центры сертификации (CA), форум центра сертификации / браузера (CA / B) и сами веб-браузеры. Существует устоявшийся и традиционный способ защиты веб-серверов. Это общепризнанный стандарт и стандартный вариант использования PKI, который определяется базовыми требованиями CA / B Forum. Потребность в стандарте для браузеров обусловлена ​​открытой экосистемой клиентов в среде - все веб-браузеры и пользователи должны подключаться к открытому и широкому набору серверов.

Когда мы рассматриваем PKI для экосистем IoT, некоторые из них меняются. В то время как веб-PKI использует в основном общедоступные модели доверия, PKI для IoT, как правило, использует более закрытые частные экосистемы. В настоящее время в экосистемах Интернета вещей модели доверия во многих из этих экосистем гораздо более закрыты, поскольку они все еще находятся на ранней стадии развертывания. Как правило, OEM предоставляет весь стек от устройства до облака. Они собираются запустить облако или, что более вероятно, сотрудничать с кем-то, кто будет управлять облаком, например, Microsoft или Amazon. Эти модели доверия экосистемы в настоящее время закрыты и изолированы.

Эта конфигурация все еще разрабатывается. Мы наблюдаем эволюцию стандартов идентификации и стандартов идентификации IoT в более вертикальных конкретных экосистемах. Например, мы видим, что стандарты появляются вместе с группами, членами которых мы являемся, такими как Wi-SUN Alliance, организация, которая способствует внедрению Interoperable Smart Ubiquitous Networks, и LXI Consortium (LAN eXtensions for Instrumentation), группа ведущих международных тестов. и измерительные компании, сотрудничающие для разработки и управления стандартом связи для контрольно-измерительной аппаратуры.

Есть много других примеров этих отраслевых сценариев использования, которые обеспечивают согласованность в их собственных областях, например, в автомобильной или потребительской сфере. Это то, что мы предсказывали, и что мы обдумывали, когда начинали проникать в пространство Интернета вещей. Мы знали, что увидим первоначальное отклонение от того, где сегодня в сети развертываются модели идентификации. Что он переместится в закрытые экосистемы, а затем начнет расти в получастные или полуобщественные экосистемы и в конечном итоге превратится во что-то более широкое и более эквивалентное в качестве общего стандарта аутентификации или идентификации для этих экосистем. Отраслевые вертикали помогают установить базовые стандарты, которые, вероятно, станут более широкими по мере развития Интернета вещей.

Новые архитектурные концепции

Каждая вертикаль IoT и вариант использования имеют разные архитектурные шаблоны. Однако мы видим, что и здесь появляется некоторая общность, которая материализовалась из спецификации IEEE 802.1 AR и находит признание в экосистемах IoT. Это касается общих концептуальных компонентов IDevID и LDevID. Они применяются в архитектурных концепциях, которые немного более независимы от сценариев использования или вертикальных.

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

Это один из наиболее вертикально-независимых шаблонов архитектурной идентичности, который мы использовали с некоторыми из наших существующих клиентов. Для реализации требуется тщательное рассмотрение вашей цепочки поставок. Во-первых, мы рассматриваем, где и как IDevID безопасно вводятся в это устройство, компонент или набор микросхем - на любом уровне платформы устройства, на котором вы хотите его создать, а также на каком этапе производственного процесса. Затем мы рассмотрим, как потенциально использовать некоторые из тех атрибутов доверия IDevID, которые в идеале были безопасно предоставлены во время производства, в локально значимый рабочий LDevID, который можно использовать для подключения устройства и его работы в экосистеме IoT. Эти LDevID обычно чаще меняются в течение жизненного цикла устройства.

Этот шаблон IDevID / LDevID является одним из тех проектов архитектурной идентичности, на которые PKI начинает опираться в IoT, и мы используем некоторые из этих концепций для защиты устройств и цепочек поставок от возникающих угроз.

Итак, ответ на вопрос «Почему нет универсального стандарта безопасности для Интернета вещей?» немного туманный и заслуживает более чем однострочного ответа. Интернет вещей не только слишком разнообразен, чтобы иметь единый стандарт, хотя это одно из законных объяснений, но он также все еще появляется, растет и находит общие черты, которые в конечном итоге могут привести к чему-то более однородному.