Промышленное производство
Промышленный Интернет вещей | Промышленные материалы | Техническое обслуживание и ремонт оборудования | Промышленное программирование |
home  MfgRobots >> Промышленное производство >  >> Industrial Internet of Things >> Интернет вещей

Привет, Чарли Миллер! Поговорим об обеспечении безопасности автономных транспортных средств

В недавней статье Wired о Чарли Миллере (печально известном своим удаленным взломом и управлением Jeep) утверждается, что «открытый диалог и сотрудничество между компаниями» являются необходимыми предпосылками для создания безопасных автономных транспортных средств. Это кажется довольно надуманным, когда так много компаний стремятся доминировать в будущем когда-то почти мертвой, но недавно возрожденной (помните «Большую тройку»?) Автомобильной промышленности. Как ни наивно звучит эта часть статьи, что действительно поразило меня, так это предположение, что ответ на изменение дизайна безопасности лежит исключительно в сфере автономных транспортных средств.

Концепция безопасности не ограничивается автономными транспортными средствами. так что нет никакой пользы в том, чтобы притворяться, что это так. Каждая отрасль IIoT пытается решить аналогичные проблемы и на удивление открыта для того, чтобы поделиться своими выводами. Я не говорю, что Миллеру необходимо пройти путь просвещения через все другие отрасли, чтобы создать идеальное решение для обеспечения безопасности. Я говорю, что это уже было сделано для нас, комплимент Industrial Internet Consortium (IIC).

IIC состоит из 250+ компаний из нескольких отраслей, включая поставщиков автомобилей, таких как Bosch, Denso и TTTech, с одной и той же фундаментальной проблемой баланса безопасности, безопасности, производительности и, конечно же, затрат на свои подключенные системы. Если проводной и Миллер стремятся к открытому разговору - это происходит в IIC. IIC опубликовал эталонную архитектуру промышленного Интернета, которая доступна всем бесплатно - как в «бесплатном пиве», особенно если за вас управляет машина! Дополнениями к этому документу являются Industrial Internet Connectivity Framework (IICF) и Industrial Internet Security Framework (IISF). Эти документы содержат руководство с точки зрения бизнеса вплоть до реализации, и IISF особенно применим, поскольку он касается Wired краткие упоминания о защите конечных точек подключения и данных, которые передаются между ними.

Прокатитесь со мной и посмотрите, как мы можем изменить архитектуру подключенного автомобиля, чтобы защитить его от потенциальных противников. Поскольку у нас нет известных злонамеренных атак на автомобили, мы можем начать со взлома Miller’s Jeep. Благодаря бэкдору в головном устройстве Harmon Kardon, Миллер мог довольно легко выполнять незащищенные удаленные команды. С помощью этого первоначального эксплойта он смог перепрограммировать микросхему, подключенную к CAN-шине. Оттуда он почти полностью контролировал машину. Вы думаете:«Просто удалите этот незащищенный интерфейс», верно?

Миллер не стал бы останавливаться на достигнутом, так что мы тоже. Если предположить, что мы все же сможем найти эксплойт, который предоставил нам доступ для перепрограммирования чипа ARM, тогда Wired's В статье справедливо предлагается создать приложение с аутентификацией - возможно, начать с безопасной загрузки для базового ядра, использовать зону доверия ARM для следующего этапа критически важного программного обеспечения и реализовать своего рода аутентификацию для процессов ОС и приложений более высокого уровня. Конечная точка вашего устройства может начать выглядеть как стек доверенных приложений (рисунок 1 ниже). Я могу только догадываться, сколько сейчас стоит это головное устройство, но, честно говоря, это веские соображения для запуска надежного приложения. Проблема сейчас в том, что мы фактически ни к чему не подключились, не говоря уже о безопасном подключении. Не волнуйтесь, я не оставлю вас на обочине дороги.

Рис. 1. Стек надежных приложений

Многие из этих доверенных приложений подключаются напрямую к шине CAN, что, возможно, расширяет поверхность атаки до управления транспортным средством. Данные, передаваемые между этими приложениями, не защищены от неавторизованных писателей и читателей. В случае автономных такси, как Wired указывает на то, что потенциальные хакеры теперь имеют физический доступ к своей цели, что увеличивает их шанс захватить приложение или внедрить самозванца. Теперь возникает вопрос:могут ли приложения доверять друг другу и данным на шине CAN? Насколько комбинация приборов доверяет данным о внешней температуре? Неужели это нужно? Может и нет, и это нормально. Однако я почти уверен, что система управления транспортным средством должна доверять LIDAR, Radar, камерам и так далее. Последнее, о чем кто-то захочет беспокоиться, - это хакер, удаленно управляющий автомобилем для прогулки.

На самом деле мы говорим о подлинности данных и контроле доступа:двух положениях, которые еще больше снизили бы риск взлома Миллера. Защита унаследованных приложений - хороший шаг, но давайте рассмотрим сценарий, когда в систему вводится неавторизованный производитель данных. Этот нарушитель может вводить команды по шине CAN - сообщения, управляющие рулевым управлением и торможением. Шина CAN не предотвращает неавторизованную публикацию данных и не гарантирует, что данные поступают от аутентифицированного производителя. Я не утверждаю, что замена CAN-шины - это путь вперед, хотя я не против идеи замены ее более ориентированным на данные решением. На самом деле, с такой структурой, как Data Distribution Services (DDS), мы можем создать многоуровневую архитектуру в соответствии с IISF (рисунок 2 ниже). Шина CAN и критически важные компоненты привода представляют собой устаревшие системы, для которых риск безопасности может быть снижен путем создания барьера для шины данных DDS. Затем новые компоненты могут быть надежно интегрированы с помощью DDS без дальнейшего ухудшения управления вашим автомобилем. Так что же такое DDS? И как это помогает обезопасить мой автомобиль? Рад, что вы спросили.

Рис. 2. Структура промышленной безопасности в Интернете, защищающая устаревшие конечные точки

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

Давайте вернемся немного назад и вернемся к нашему разговору о IICF, который предоставляет руководство по подключению для промышленных систем управления. IICF идентифицирует существующие открытые стандарты и кратко связывает их с конкретными функциями промышленной системы IoT. По своей сути, автономное транспортное средство, как бы круто это ни звучало, представляет собой всего лишь промышленную систему Интернета вещей в гладком аэродинамическом корпусе с дополнительными кожаными сиденьями. Итак, что предлагает IICF для интеграции программного обеспечения для промышленной системы IoT или, более конкретно, автономных систем? Ты угадал! DDS:открытый набор стандартов, разработанный и задокументированный в ходе открытых обсуждений в Object Management Group (OMG). Идеальное автомобильное решение, использующее DDS, позволяет системным приложениям публиковать и подписываться только на те сообщения, которые им нужны (см. Рисунок 3 ниже, где представлен наш взгляд на автономную архитектуру). С помощью этого подхода, ориентированного на данные, мы можем архитектурно разбивать сообщения на основе критичности для безопасности или потребности в целостности данных.

Рис. 3. Архитектура автономного транспортного средства, ориентированная на данные

И теперь, когда мы создали решение для подключения к нашему автономному транспортному средству, мы можем вернуться к разговору о безопасности и нашей альтернативе TLS:ориентированном на данные решении безопасности для ориентированной на данные среды обмена сообщениями. С помощью DDS Security разработчики систем Industrial IoT могут использовать плагины безопасности для точной настройки компромиссов безопасности и производительности - необходимая возможность, не предлагаемая TLS (рисунок 4 ниже). Аутентифицировать только избранные темы данных, но не более? Проверять. Шифровать только конфиденциальную информацию, но не более того? Проверять. Собственно, это еще не все. Помимо централизованных брокеров, DDS Security предлагает механизмы распределенного контроля доступа, определяющие, что участники могут публиковать или подписываться на определенные темы без единой точки уязвимости. Это означает, что неавторизованному приложению Миллера будет отказано в разрешении на публикацию команд для управления торможением или рулевым управлением. Или, если Миллер скомпрометировал данные в движении, подписчик данных мог криптографически аутентифицировать сообщение и отбросить все, что не соответствует установленным политикам. Можно ли сказать, что наш автономный автомобиль теперь полностью защищен? Нет, потому что, как совершенно ясно дал понять Миллер, нам вс

[1] [2] 下一页

Интернет вещей

  1. Будущее технического обслуживания:что цифры говорят о тенденциях технического обслуживания
  2. Автономные транспортные средства:развлечение пассажиров может быть большой возможностью для операторов свя…
  3. Технологии голосового управления в промышленности - о чем все говорят?
  4. Почему промышленники должны хотя бы немного подумать об ИИ
  5. Меняют ли периферийные вычисления и IIoT наше представление о данных?
  6. Обнаружение «слепых зон» в ИИ для повышения безопасности беспилотных транспортных средств
  7. Как поговорить со своими партнерами о безопасности цепочки поставок
  8. Автомобилестроение на грани
  9. Исследование предполагает, что инвестиции в IoT превзойдут облако
  10. Умная фабрика в Индустрии 4.0 — это все об этих данных