Обеспечение безопасности промышленного Интернета вещей

Все мы слышали об Интернете вещей (IoT) и промышленном Интернете вещей (IIoT). Мы знаем, что это разные вещи:IoT обычно используется в потребительских целях, а IIoT используется в промышленных целях.

Но как такая профессиональная группа, как Industrial Internet Consortium (IIC), на самом деле определяет IIoT?

Группа рассматривает IIoT как систему, которая соединяет и интегрирует среды операционных технологий (OT), включая системы промышленного управления (ICS), с корпоративными системами, бизнес-процессами и аналитикой.

Эти системы IIoT отличаются от ICS и OT, поскольку они широко связаны с другими системами и людьми. И они отличаются от ИТ-систем тем, что в них используются датчики и исполнительные механизмы, которые взаимодействуют с физическим миром, где неконтролируемые изменения могут привести к опасным условиям.

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

Один из множества проектов В рамках программы Министерства энергетики (DoE) по сокращению киберинцидентов корпорация Intel занимается повышением безопасности периферии энергосистемы.

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

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

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

Свен Шрекер, главный архитектор решений безопасности IoT в Intel и сопредседатель рабочей группы по безопасности в IIC, сказал, что безопасность не должна быть единственным соображением при проектировании и развертывании устройств для систем IIoT, но разработчики должны думать об этом шире. пять общих ключевых факторов:

• безопасность

• надежность

• безопасность

• конфиденциальность

• устойчивость

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

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

Гайдн Пови, член правления IoT Security Foundation, генеральный директор и основатель Secure Thingz, сказал, что безопасность необходимо решать на четырех уровнях:

• Уровень CxO

• архитектор безопасности

• инженер-разработчик

• диспетчер операций

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

Четвертая часть цепочки - это когда OEM-производители участвуют в производстве продуктов для сетей IIoT или в развертывании этих продуктов. Здесь производственный или операционный менеджер должен гарантировать, что каждый электронный компонент имеет свою уникальную идентификацию и может быть надежно аутентифицирован в каждой точке цепочки поставок.

Обсуждая отсутствие цепочки доверия к аппаратному и программному обеспечению, Роберт Мартин, старший главный инженер корпорации MITER и член руководящего комитета IIC, сказал:«В связанных промышленных системах очень много разных технологических стеков».

Фактически, он предупредил:«Небольшое изменение в микропроцессоре может непреднамеренно повлиять на работающее на нем программное обеспечение. Если мы перекомпилируем программное обеспечение и запустим его в другой ОС, оно будет работать по-другому, но никто не будет нести ответственность за программные сбои, возникшие в результате изменений ».

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

Рекомендации по проектированию безопасности IIoT
Итак, с чего начать разработку безопасности для IIoT и на какие конструктивные особенности следует обратить внимание?

Существуют различные отраслевые рекомендации, например IIC's IoT Security Framework . вместе со своим производственным профилем предоставление подробных сведений о внедрении концепции на предприятии или в рамках концепции кибербезопасности Национального института стандартов и технологий .

Основная задача инженера-проектировщика - определить, как преобразовать политику безопасности или структуру безопасности в проектирование и управление жизненным циклом устройства, которое формирует всю конечную точку IIoT или ее часть.

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

«Этот процесс ничем не отличается от защиты других систем, - сказал Чет Баблалк, вице-президент Arm по решениям для устройств Интернета вещей. «Нам нужно думать о безопасности с нуля».

Он пояснил:«Первая часть - это анализ:каковы векторы угроз и что вы пытаетесь защитить?»

В прошлом году Arm представила собственную архитектуру безопасности платформы (PSA) для поддержки разработчиков устройств IoT. Бабла говорит, что PSA не зависит от устройства, потому что компания пытается побудить отрасль задуматься о безопасности.

Анализируйте, проектируйте, воплощайте
Структура PSA состоит из трех этапов - анализа, проектирования и реализации. «Анализ - это основная часть того, что мы пытаемся подчеркнуть», - сказал Бабла.

Это означает, например, проведение анализа модели угроз, и компания Arm представила три аналитических документа для распространенных случаев использования в трекерах активов, счетчиках воды и сетевых камерах. Этот анализ важен, и его поддерживают другие.

Мартин из MITER Corp. прокомментировал:«Мы должны начать говорить о потенциальных недостатках оборудования и иметь возможность имитировать шаблоны атак и создавать тестовые примеры».

Инженеры-проектировщики должны думать обо всей экосистеме, от чипа до облака, с точки зрения реализации системы, включающей неизменяемое устройство или устройство с неизменяемой идентичностью; включение доверенной загрузки; и обеспечение безопасного выполнения беспроводных (OTA) обновлений и аутентификации. «Тогда вы можете подумать о смягчении последствий в кремнии, точках доступа и облаке», - сказал Бабла.

Структура PSA от Arm побуждает дизайнеров сначала рассмотреть угрозы, а затем проанализировать дизайн и реализацию. (Источник:Arm)