Мониторинг здоровья электрическими устройствами

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

Введение

Согласно меморандуму Федеральной торговой комиссии США [1], в 2015 г более 25 миллиардов устройств уже подключены к сети Интернет. В аналитическом докладе Cisco от октября 2014 г. [2] сказано, что это число достигнет 50 миллиардов к 2020. Там же указывается, что сам термин и идея IOT появились в Массачусетском технологическом институте в 1999 году для описания коллективно подключенных «умных устройств» к сети.

Есть веские основания полагать что новый виток развития Интернета Вещей станет мощной движущей силой для развития одной из самых важных сфер жизни - медицины. Новые умные устройства, снабженные датчиками разных типов, дали возможность собирать информацию о физическом и моральном состоянии пациента в режиме 24 на 7. Данные полученные таким образом должны обрабатываться, передаваться и храниться. Обработанные данные дают возможность проследить позитивную или негативную динамику изменения состояния пациента. Использование IoT в медицине дает возможность снизить затраты на обследование и лечение, ставить более точные диагнозы, принимая во внимание результаты обработки большего, нежели прежде, количества данных, а также персонализировать лечение, что сделает его более эффективным. Более того IoT позволяет диагностировать многие заболевания на ранних стадиях. Не смотря на ценные и важные для человека преимущества использования умных устройств в сфере медицины, сегодня в этой области всё еще много открытых проблем, связанных с сбором, передачей, хранением, обработкой и визуализацией этих данных. Описанные выше проблемы имеют свою специфику в IoT, тем не менее имеют практическое решение в том или ином виде, в то время как комплексные проблемы в области безопасности функционирования и обмена данными между сетями таких интеллектуальных устройств становятся всё более и более критичными.

Журнал INTELLIGENCE в своем ежегодном обзоре утверждал, что производители не создают устройства IoT с программным обеспечением, ориентированным на безопасность - на сегодняшний день отсутствует даже шифрование данных в процессе коммуникации [3]. Причины довольно просты: сложность и высокая себестоимость. Кроме того, было отмечено, что в среднем на устройстве IoT имеется более 20 уязвимостей в системе обеспечения безопасности.

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

Соответственно, данное исследовании должны дать ответы на следующие вопросы:

· Какие уязвимости имеются у типовых устройств IoT?

· Как эти уязвимости могут использоваться киберпреступниками?

· Каковы потенциальные риски использования устройства IoT киберпреступниками?

· Какие меры безопасности производители устройства IoT должны реализовать, чтобы сделать устройства менее уязвимыми?

· Как регулируется безопасность отрасли IoT?

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

В данном исследовании использовались теоретические методы исследования: анализ и последующий синтез основных уязвимостей, связанных с устройствами IoT, и эффектов, поставивших под угрозу устройства. В результате были предложены различные меры безопасности, которых должны придерживаться производители IoT, чтобы лучше защитить данные своих пользователей. Метод анализа так же использовался в исследование международного регулирования, которое имеет дело с безопасностью IoT. В третьей главе исследование предлагает один из примеров эффективной реализации безопасного программного решения в области мониторинга здоровья человека. Мы рассмотрели взаимодействие аппаратных устройств мобильного телефона на акселерометре и интеграцию обработки данных от него и открытых источников данных, требующихся для мониторинга параметров здоровья человека. Более того, в практической части используется устройство Io, а именно Xiaomi Mi1S. На его примере будет рассмотрены и протестированы средства обеспечения безопасности, а атак же описан пример получения данных от устройства.

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

интернет медицинский мониторинг архитектура



1. Небезопасность и ненадежность Интернета Вещей

В профессиональной литературе имеются диаметрально различные точки зрения на указанные вопросы. Первая точка зрения представлена профессором Государственного Университеты Дакоты Вэйном Паулем. Он полагает, что взлом смартфонов с целью получения доступа к умным устройствам один из наименее распространенных видов киберпреступности. Профессор объясняет свою точку зрения тем, что преступники не смогут получить финансовое вознаграждение за взлом такого рода. Тем не менее, он добавил, что не слишком сложно получить контроль над разными видами IoT устройств [4].

Говоря о необходимости обеспечения безопасности в сетях IoT устройств Матсато Матсуока из Kaspersky Lab говорит, что небезопасность в большинстве IoT устройств не несет такие же риски как небезопасность персональных компьютеров. Но это так только в случае, если речь не идет о межмашинном взаимодействии [5].

Гас Шахин, начальник информационного управления компании Flextronics обеспокоен по поводу проблем уязвимости в IoT устройствах. Он говорит, что в ближайшем будущем количество таких устройств продолжит расти и они будут контролировать почти сферы нашей жизни. Поэтому мы должны знать о возможных уязвимостях и кибер атаках и быть способными противостоять им [6].

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

Один из аргументов в пользу необходимости обратить внимание на проблему безопасности в сетях умных устройств - высокий уровень потенциального риска. Это значит, что небезопасность в данном случае может повлечь не только разглашение персональных данных или важной производственной информации - речь может пойти о человеческих жизнях. В качестве примера можно привести известную многим дистанционную хирургию. Никто не будет отрицать, что малейшая ошибка в медицине, основанной на умных устройствах и компьютерах, может привести к серьезному ущербу для здоровья. Такие системы должны быть защищены и надежны. Kaspersky lab рассказал о группе исследователей из университета Вашингтона, которые попытались получить контроль над существующей системой для дистанционной хирургии Raven II. Исследователи не только нашли возможность контролировать и нарушать работу удаленно выполняемых операций, но и смогли полностью захватить управление [7]. Кроме того, исследователи отметили, что Raven II не использует шифрование. Следовательно, он не может рассматриваться в качестве устройства с надлежащей системой защиты. Другие исследователи изучили различные проблемы, относящиеся к параметрам систем мониторинга состояния здоровья, и установили, что обеспечение безопасности в такой системе имеет "огромное значение" и должно быть реализовано и на уровне облачного хранилища и на уровне самого устройства [8].

Мы считаем, что существует много причин, чтобы производители и потребители были обеспокоены безопасностью устройства IoT.

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

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

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

В-четвертых, важность безопасности IoT состоит в том, что устройства представляют физические риски. Это актуально при поражении устройств промышленного использования, медицинских инструментов, систем управления трафиком и т.п. В технологической прессе обсуждались, например, случаи появления опасности для жизни. Обнаружены уязвимости в системах управления моделями медицинских насосов для переливания крови Hospira, в результате чего проводилось несанкционированное изменение доз вводимых препаратов злоумышленниками [9]. При управлении автомобилем Jeep Cherokee описаны случаи перехвата управления системой передач и тормозами через мультимедийную систему Uconnect используя сотовое соединение [10].

Очевидно, что практически экспоненциальный рост числа устройств IoT в медицине выводит проблемы безопасности в число критически важных.

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

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

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

В отчете Symantec описана топология домашней сети с устройствами IoT. В 2015 типичные домашние сетей имели широкополосные маршрутизаторы, которые позволяют подключенным устройствам получать доступ к Интернету и связываться с другими подключенными устройствами. Устройства IoT могут соединиться с этой сетью, используя много различных протоколов: Z-wave, ZigBee, Bluetooth 4.0, NFC и другие протоколы. Стандартизации в настоящее время не имеется. Методы защиты протоколов различны, но не являются достаточными. У устройств IoT все еще нет реализованных протоколов аппаратной безопасности самих устройств, сети устройств являются практически открытыми, половина не использует даже протокол SSL при подключении к облаку через мобильное управление [11].

В настоящее время международный альянс Open Web Application Security Project (OWASP) и общемировая общественная организация Internet Society - практически единственные фокусируются на продвижении безопасности программного обеспечения в области IoT. В одном из последних отчетов OWASP предложен набор тестов для программного обеспечения по тестированию безопасности, а также проанализированы основные системные уязвимости по производителям решений [12]. Так же в отчете от октября 2015 года Internet Society так же приводит список проблем безопасности для устройств IoT.

Небезопасный веб-интерфейс.

Это проблема касается тех пользователей, которые получают доступ к устройству, используя веб-интерфейс.

Веб-интерфейс небезопасен, если он подвержен атакам на перебор пользователей в системе, допускает слабые пароли, поддерживает ведение учетной записи с невозможностью блокировки учетной записи после определенного числа неудавшихся попыток входа в систему. Кроме того, небезопасные веб-интерфейсы могут быть восприимчивы к сценариям перекрестного сайта [13]. Такие атаки на веб-системы, заключаются во внедрении в выдаваемую веб-системой страницу вредоносного кода (который будет выполнен на компьютере пользователя при открытии им этой страницы) и взаимодействии этого кода с веб-сервером злоумышленника. Вредоносный код может использовать авторизацию пользователя в веб-системе для получения к ней расширенного доступа или для получения авторизационных данных пользователя.

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

Недостаточная аутентификация или авторизация.

Это проблема касается тех пользователей, которые получают доступ к устройству, используя веб-интерфейс или мобильное устройство.

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

Небезопасная сетевая служба.

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

Небезопасная сетевая служба чувствительна к атакам переполнения буфера и атакам направленными на отказ служб (DoS) [15]. Обычным эффектом является переполнение буфера, когда объем данных, переданный буферу хранения, превышает свой лимит и перетекает в другой буфер, таким образом, повреждая уже хранившие данные. Так же подобные атаки могут привести к ситуации, в которой система даст атакующему критическую информацию, например, часть программного кода. Более того, в результате такой атаки, устройство может быть недоступно для пользователя.

Отсутствие шифрования транспортировки.

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

Отсутствие транспортного шифрования позволяет просматривать данные как текст при передаче по сети [16]. Шифрование передачи защищает данные, переводя его в секретный код. Эта уязвимость имеет среднюю распространённость.

Проблемы приватности.

Неудачный подход к приватности - недостаточная защита персональных данных ведет к уязвимости устройств и сетей. Отсутствие шифрования и небезопасные протоколы сетевых служб, могут позволить атакующим просмотреть персональные данные [17]. Следует отметить, что зачастую системы собирают ненужные для своей работы персональные данные.

Небезопасный облачный интерфейс.

Облачный интерфейс небезопасен, если пользователи используют слабые учетные данные или возможно считывание учетной записи. Дополнительные уязвимости, такие как отсутствие шифрования и несоответствующая аутентификация, могут позволить получать доступ к облачному интерфейсу и средствам управления представлением или данным. Подобно веб-интерфейсам, небезопасные облачные интерфейсы могут также быть восприимчивы к сценариям перекрестного сайта или атакам с использованием кода на SQL. Небезопасный облачный интерфейс - общая уязвимость со средней степенью распространённости [18].

Небезопасный мобильный интерфейс.

Мобильные интерфейсы небезопасны, когда существует возможность прочтения учетной записи пользователей. Так же, как и в случае облачного интерфейса, атаки могут использовать другие уязвимости, чтобы получить доступ к плохо защищенным мобильным интерфейсам. Данные аутентификации могут передаваться по ненадежной сети или незашифрованными. Эта уязвимость весьма распространена, особенно в системах медицинского мониторинга при большом числе пользователей [19].

Недостаточная конфигурируемость безопасности.

Зачастую у пользователя есть лишь ограниченные возможности изменения параметров безопасности их устройств. Это приводит к отсутствию пользовательских полномочий (например, неспособность пользователя изменить пароль), следовательно, это можно использовать, для того чтобы просмотреть данные или получить управление устройством [20]. Так же невозможность поменять настройки безопасности является серьезной проблемой в случае смены владельца устройства. Новый владелец в данном случае не может быть уверен, в защите своих данных и в безопасности устройства, так как прежний хозяин имеет необходимые данные для подключения к устройству. Недостаточная конфигурируемость безопасности - общая уязвимость и весьма распространена.

Плохая физическая безопасность.

Уязвимости физической безопасности - любые действия, которые позволяют получать физический доступ к данным устройства, носителям данных или операционной системе [21]. Это включает дизассемблирование устройства или использование внешних портов, чтобы получить доступ к устройству. Плохая физическая безопасность - общая уязвимость со средней степенью угрозы.

Проблема идентичности.

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

Проблема технической поддержки.

Развертывание систем, основанных на IoT устройствах, осуществляется с учетом длительных сроков эксплуатации и иногда даже не предполагает изменение конфигурации или модернизацию устройств. Так же может случиться, что такие устройства переживут своего производителя и останутся без технической поддержки. Механизмы обеспечения безопасности работают хорошо на этапе развертывания системы и устаревают со временем. Проблема обеспечения технической поддержки в долгосрочной перспективе особенно остра [23].

Проблема обновления.

Многие устройства изначально не предполагают возможности обновления либо эта процедура слишком неудобна и непонятна для конечного пользователя. Это значит, что при обнаружении уязвимостей, у производителя и у пользователя не будет возможности устранить потенциальную угрозу [24].

Скрытое выполнение.

Некоторые устройства IoT функционируют таким образом, что пользователь не имеет понятия об операциях, производимых устройством в данный момент. Это создает уязвимость, когда пользователь думает, что устройство производит одни операции, а на самом деле оно выполняет нежелательные действия, среди которых может быть и сбор данных, которые пользователь не желает предоставлять и отсылка этих данных другим устройствам [25].

Отсутствие функции предупреждения.

Некоторые устройства IoT помещаются в труднодоступные места или встраиваются в окружающую среду незаметно. Так же устройства не имеют возможности сигнализировать пользователю об угрозе безопасности. Поэтому такие скрытые и недоступные устройства могут сохранять уязвимость в течение длительного периода времени [26].

2. Общие технические следствия и влияния на бизнес

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

Технические влияния включают потерю данных, повреждение данных, отказ доступа и отказ в обслуживании. Очевидно, что производители должны учитывать, что таким образом может быть получен доступ или к данным клиентов компании или к данным самой компании [27].

Наблюдение.

В обзорах отмечается, что массовый характер приобретает использование сетевых веб-камер для несанкционированного наблюдения за другими людьми [28]. Аналогичные возможности имеют и другие IoT устройства: телевизоры, кухонная бытовая техника, смартфоны, системы развлечений. Особо обратим внимание на то, что системы мониторинга здоровья могут использоваться, чтобы отследить в преступных целях расположение пользователей IoT [29].

Несанкционированный доступ к персональным данным.

Использование уязвимости сетей IoT, дает возможности доступа к самим устройствам, к учетным записям пользователей или их данных. Устройства IoT в обычных сценариях собирают несколько форм персональных данных, таких как имя, дата рождения, адрес, медицинская информация и номер кредитной карточки [30]. Такая информация может стать доступной для третьих лиц. Отмечены случаи доступа к полным медицинским картам пациентов, через их носимые устройства мониторинга. Зачастую получение доступа через одно устройство IoT может инфицировать и другие.

Инфицирование.

Широкое внедрение IoT создают новую сложную проблему обеспечения сетевой безопасности, так как устройства позволяют вредоносному программному обеспечению легко обходить меры обеспечения безопасности, такие как брандмауэры и системы обнаружения проникновения. Пользователи обычно не обнаруживают вредоносные инфекции в устройствах IoT, при этом отмечены случаи установки такого обеспечения еще на до этапа продаж недобросовестными производителями [31].

Создание точек входа в сеть.

Уязвимость устройства IoT может приводить к поражению и других устройств IoT в этой сети, при использовании пораженного устройства, как черную точку входа. Наличие доступа к внутренней сети может позволить атакующему собирать данные или атаковать другие подключенные устройства. Например, атакующий может использовать уязвимое медицинское устройство в качестве точки входа в сеть больницы и атаковать систему [32].

Физический риск.

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

По прогнозам Kaspersky Lab, ожидается увеличение числа атак на медицинские устройства при переходе на электронные системы ведения медицинской документации. При этом сама отрасль (РФ) здравоохранения практически не готова к такому сценарию, отсутствует даже нормативная документация. Появление большого числа медицинских баз данных на черном рынке свидетельствует о серьезности ситуации.

Состояние системы.

Первые меры, которые производители IoT должны предпринять, связаны с комплексным тестированием в сетях IoT. Тестирование может включать аутентификацию, возможность проникновения в устройство или сеть, тест на соединение с другими технологиями, с использованием порта и с сетевым трафиком [33]. Кроме того, должны исследоваться все сетевые службы и облачные интерфейсы [34]. Такой процесс должен повторяться, а его результаты должны обеспечивать обновления системы защиты.

Обновления системы защиты.

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

Встроенная защита.

Защита устройств планируется еще на этапе проектирования и производства и должна контролироваться и совершенствоваться так же на этапе тестирования. Очевидно, что такая защита предназначена для блокирования уже известных на момент проектирования угроз [36]. В идеальном варианте такая защита должна давать пользователям возможность изменять параметры безопасности.

Изменения параметров безопасности.

Производители создают большинство устройств IoT таким образом, чтобы безопасность устройства конфигурировалась автоматически. Однако, варианты настройки пользователем также важны. Пользователь должен иметь возможность настраивать такие параметры как пароль, срок его обновления, шифрование. Так же производители устройств должны разработать защищенную процедуру восстановления пароля, в процессе которой система не запрашивает большое количество данных и не выдает критическую информацию. Например, информацию о существования такого аккаунта в системе [37].

Устройства должны получать минимально необходимую информацию о пользователе. Важно эту часть информации хранить и защищать отдельно от остальных данных в устройстве или сети устройств [38]. Особенно важно предусмотреть возможности шифрования.

Устройства и сети IoT не должны допускать использование слабых, коротких паролей, должны иметь требования по изменению имен пользователя и пароли по умолчанию, которые при первом запуске системы должны быть изменены пользователем. Очевидно, что административные пароли должны быть предметом особого контроля, желательно с двухфакторной аутентификацией для доступа в облачные хранилища через мобильные интерфейсы. Наконец, устройства должны быть в состоянии запретить доступ после определенного числа попыток входа в систему, чтобы уменьшить риск атак «грубой силой» - т.е. подбор мошенником пароля, посредствам многократных попыток [39].

Удаление ненужных приложений.

Сетевая реализация IoT должна предусматривать политику удаления приложений, не используемых устройствами сети [40]. Обычной практикой является блокировка любых приложений, кроме тех, что входят в «белый список», необходимых для работы сети.

Автономная опция.

Автономная работа дает пользователям возможность использовать их устройства, не соединяя их с Интернетом или облачным хранилищем постоянно или вообще никогда. Облачные интерфейсы могут поставить под угрозу устройства IoT.

Проверка запускаемого кода.

Важным аспектом также является безопасная цепочка начальной загрузки, которая позволяет устройству проверять статус своего программного обеспечения [41]. Известное устройство, которое использует безопасную цепочку начальной загрузки, является iPhone Apple. Согласно отчету iOS 9.0 безопасности Apple, его безопасная цепочка начальной загрузки проверяет каждый шаг процесса запуска устройства, удостоверяясь, что каждый компонент криптографически подписан Apple. Если устройство не может проверить часть процесса, оно входит в режим восстановления, и пользователь должен сбросить его к заводским настройкам. Поэтому, устройства Apple никогда не будут в состоянии работать, если все их компоненты программного обеспечения не будут проверены.

Удаление открытых портов.

Согласно PubNub у устройств не должно быть доступных каналов передачи, т.е. открытых портов. Устройства должны быть в состоянии делать только исходящие соединения [42]. Сетевые протоколы: MQTT, CoAP, WebSockets и HTTP 2.0 позволяют IoT устройству связываться, не имея открытых портов, эти протоколы упрощают и подписывают соединение, не зная идентификационных данных.

Шифрование соединения.

Практика использования алгоритмов шифрования также часто используется: AES в дополнение к SSL/TLS. Так как SSL/TLS только защищает передачу данных верхнего уровня, то шифрование AES дополняет сквозное шифрование поэтому и только устройства с корректными ключами будут в состоянии дешифровать и зашифровать данные [43]. Важно также, чтобы существовали средства управления доступом к определенным потокам данных от различных групп устройств.

Возможность уведомления об угрозе безопасности.

Во многих устройствах IoT нужно реализовать функцию уведомления пользователя об угрозе безопасности. Так как при возникновении таких угроз необходимо вмешательство со стороны пользователя при первой возможности. А длительное бездействие может привести к ухудшению ситуации, в частности захвате полного контроля над устройством или целой сетью устройств, хищению или повреждению данных [44].

3. Система регулирования безопасности Интернета вещей IoT

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

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

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

Несколько более развитая ситуация, например, в США, где существуют два основных акта, регулирующих данную отрасль в части медицинской индустрии: Health Insurance Portability and Accountability Act (HIPAA) и Health Information Technology for Economic and Clinical Health (HITECH) Act.

У HIPAA есть ряд инструкций, который описывает медицинскую информационную безопасность, в частности при использовании данных и электронной медицинской В частности используются два подхода к защите частных данных:

· Вводятся ряд национальных стандартов, которые защищают индивидуально идентифицируемую медицинскую информацию (PHI), определяя условия, в которых могут использоваться данные PHI;

· Вводятся ряд национальных стандартов, которые требуют, чтобы организации реализовали технические и нетехнические меры защиты для всех электронный PHI.

В тоже время не все данные IoT подпадают по действие данных регуляторов (например, данные от трекеров здоровья) и соответственно они не защищены законом.

Приведенный нами обзор позволяет сделать следующие выводы:

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

· Поставщики решений для IoT должны считать обеспечение безопасности сетей IoT и предотвращение несанкционированного доступа к частным данным одной собственных приоритетных задач

· Регулирование IoT требует подготовки соответствующей нормативной базы. Актуальность этого для систем медицинского назначения не вызывает сомнений.

· Уязвимости и риски. Выше мы указали на наличие очевидных системных проблем в обеспечении безопасности IoT, а также указали на следствия, к которым они могут привести.

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

· Правовое обеспечение и регулирование IoT должно явиться предметом отдельной профессиональной работы.

4. Постановка задачи

В настоящей главе мы сузим наше дальнейшее исследование на область систем мониторинга здоровья человека.

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

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

4. Специфика медицинских систем мониторинга в сетях IoT

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

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

· Интернет вещей. Область проникновения практически необозрима и связана фактически с полным пересмотром систем поддержки пациентов и диагностирования. Аппаратные возможности сенсоров позволяют переходить к концепции постоянного мониторинга и поддержки уровня здоровья людей.

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

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

· Кибербезопасность. Вопросы безопасности ИТ систем, обзор которых мы привели в Главе 1 и которые связаны медицинскими темами имеют критически важное значение. Безопасность, заложенная в разработку систем медицинского назначения должна стать составной частью любого проекта в этой области.

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

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

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

Это означает, что система мониторинга должна уметь:

o Получать аппаратные данные

o Хранить/извлекать их из систем хранения

o Получать данные из открытых источников

o Обрабатывать данные совместно

o Анализировать результаты обработки

· Выявление риска развития контролируемых заболеваний.

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

· Организация экстренного реагирования при критическом ухудшении жизненных показателей.

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

Требуется разработать:

1. Мобильное приложение (на основе Android), которое является прототипом системы мониторинга здоровья человека. Мобильное приложение должно решать следующие функциональные задачи:

Иметь возможность считывать аппаратные данные с устройства класса IoT.

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

Использовать фитнес браслет Xiaomi Mi1S

Рассмотреть в архитектурном решении две ситуации: прямое аппаратное считывание данных с устройства и/или алгоритмическое моделирование датчика шагов.

Мобильное приложение должно иметь возможность получать поток открытых данных (сеть Интернет: погодные данные, геомагнитная информация и т.п.)

Мобильное приложение должно иметь возможность сохранять получаемые аппаратные данные в нескольких вариантах: на диске смартфона и передавать данные для записи в одно из хранилищ данных.

Архитектурное решение приложения должно предусматривать возможность интеграции приложения в общую систему: мобильное приложение - портал - хранилище данных.

При этом содержанием нашей работы будет являться только разработка указанного выше мобильного приложения.

a. Приложение должно продемонстрировать возможности совместной аналитической обработки аппаратных данных от устройства и внешних потоков данных.

2. Мобильное приложение должно дополнительно в своей архитектуре учитывать:

a. Требования к сформулированным выше системам мониторинга здоровья человека.

b. Требования к сформулированным выше критериям безопасности программно-аппаратных комплексов, относимым к системам IoT.



5. Реализация и архитектура системы

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

Проект структурно представляет собой программное решение, состоящее из трех компонентов:

· объектное хранилище данных (OpenStack/CEPH), осуществляющее персонализированное безопасное сохранение медицинских документов пользователя в желаемом для него формате (текст, картинка, видео). Хранилище реализовано как облачное, объекты хранения для пользователя по размеру не ограничены (или почти не ограничены).

· портальное решение (как промежуточное выше хранилища) с функционалом регистрации пользователя в хранилище и безопасной закачки файлов в хранилище.

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

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

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

Данная разработка предназначена для демонстрации и отработки взаимодействия с аппаратной частью смартфона - акселерометром, как типовым устройством IoT для подсчета шагов владельца. Так же в данной работе будет рассмотрено взаимодействие смартфона и фитнес трекера Xiaomi Mi1S, с целью тестирования средств безопасности устройства и получения собираемых им данных.

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

Важной новой и составной частью нашего приложения является совместная обработка данных, получаемых от устройства и информации от внешних открытых источников (мы рассматриваем данные о атмосферном давлении, магнитных бурях и температуре воздуха). Мы проводим совместную аналитическую обработку внутренних аппаратных данных и внешних данных, получаемых из открытой сети Интернет для отыскания возможного влияния на измеряемые медицинские параметры, а также для поиска таких неочевидных зависимостей. Нахождение зависимостей является неотъемлемой составной частью парадигмы персонализированной медицины и соответствует требованиям, предъявляемым к системам мониторинга здоровья человека.

Составной частью нашего решения является также учет всех требований к безопасности систем в рамках IoT.

6. Высокоуровневая архитектура системы Medicus

Ниже на рисунке 1 приведен эскиз архитектурного решения информационной системы, основанной на OpenStack CEPH хранилище данных разработки компании INTRAFAB (Singapore).

Хранилище данных INTRAFAB, в отличие от стандартных объектных хранилищ имеет значительные отличия. Они связаны с наличием интеллектуального шлюза на входе. Таким образом, решается несколько связанных задач:

· проводится интеллектуальный разбор входящей информации по типам (медицинский формат DICOM, текст, видео стрим, изображение, данные от сенсоров IoT и т.п.);

· при необходимости проводится парсинг (для семантического анализа и отделения информации различного типа);

· нарезка и криптографирование для безопасного хранения и т.п.

Рис. 1. Общий архитектурный дизайн решения по хранилищу

На следующем Рисунке 1 приведен аппаратный эскиз ИТ инфраструктуры хранилища.

Данное аппаратное решение обеспечивает функционирование хранилища, резервирование записей. Особенностью CEPH является трёхкратное резервирование на бюджетных дисковых решениях, вместо использования подхода RAID с дорогими устройствами хранения.

На данной инфраструктуре размещается и вторая часть решения INTAFAB - WEB портал системы Medicus, который осуществляется функции регистрации пользователей, хранения их оперативных данных и сложную аналитику над данными из хранилища.

Рис. 2. Эскиз аппаратного ИТ ландшафта.

7. Архитектура мобильного решения Medicus

Мобильное приложение Medicus состоит из нескольких частей. А именно:

· Компонент графического представления - все экраны и элементы управления на них, который видит пользователь)

· Сервисы - объекты, выполняющие обработку разного рода задач, не имеющие связи с графическим представлением. Примером такого сервиса и является шагомер, внутри которого реализован аппаратный и программный счетчик шагов. Аппаратный шагомер - считывает данные с аппаратного устройства в телефоне, который на уровне операционной системы по данным акселерометра определяет шаги. Аппаратный шагомер поддерживается не в каждом телефоне и поддерживается преимущественно с android выше 4.4.

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

· База данных - локальное хранилище данных пользователя. В данном проекте используется NoSql решение, а именно хранилище «ключ-значение». В таком хранилище по уникальному ключу хранится список объектов или один объект, предварительно сериализованный. Данный подход выбран главным образом из-за скорости доступа к базе, которая в некоторых случаях может превышать скорость доступа к SqLite в 10 раз.

· Инструменты для сетевого обмена информацией. В данном случае это набор библиотек и классов, позволяющих получить простой, понятный и легко масштабируемый инструмент для коммуникации по сети. Для приложения Medicus данный компонент является неотъемлемой частью, так как с помощью него обеспечивается доступ в аккаунт пользователя, сохранение и восстановление всех его данных, а также доступ в хранилище. Связь с порталом inmedicus.ru организована только посредством зашифрованного соединения https. Высокоуровневая архитектура Medicus представлена на рисунке 3.

Структурно и логически в приложении Medicus выделены 4 раздела: Хранилище, Календари, Рекомендации, Аккаунт.

· Хранилище - инструмент, позволяющий просто и понятно управлять своим хранилищем. данном разделе пользователь может загружать, просматривать, скачивать и удалять свои файлы, агрегировать их в папки и управлять папками. Так же реализована возможность получать ссылку на загрузку и выгрузку файлов из хранилища.

· Календари - набор тематических календарей.

· Аккаунт - данные о пользователе, которые используются приложением главным образом для генерации персонализированных рекомендаций.

· Рекомендации - советы, интересные факты и напоминания, которые показываются пользователю исходя из выбранных им календарей, созданных событий и введенных данных аккаунта.

Рис. 3. Высокоуровневая архитектура мобильного приложения Medicus

Для единообразной, понятной и легко масштабируемой архитектуры в модуле календарей была разработана универсальная структура данных. Такая структура данных позволяет хранить информацию о самом календаре (название, описание, версия), а также хранить список событий, в каждом из которых есть набор параметров разной длины. Параметры могут принимать любой простой тип. Кроме создания простой и масштабируемой архитектуры, другими преимуществами данной структуры данных являются удобство обработки на сервере, возможность одинаковой для всех календарей синхронизации. Структура данных реализована в классе CalendarInfo. На рисунке 4 представлены классы, составляющие структуру данных календарей.

Рис. 4 Классы структуры данных календарей

Шагомер так же использует описанную выше структуру данных.

Что касается непосредственных деталей реализации шагомера, то схему работы шагомера можно представить следующим образом:

1. Определение версии андроида и наличия аппаратного шагомера. В зависимости от чего будет выбрана одна из реализаций шагомера: аппаратная или программная.

2. В зависимости от выбора инстанциируется класс наследник BaseStepDetector, в котором имплементируется методы интерфейса SensorEventListener и имеется список слушателей, реагирующих на появление шага.

3. В методе onSensor Changed (SensorEvent var1) происходит определение шага. В программном шагомере определение шага происходит по определенному алгоритму. В аппаратном шагомере на вход в фукцию onSensorChanged подается уже определенное количество шагов.

4. После определения шага происходит осведомление всех слушателей, имеющихся в списке.

5. Каждый слушатель - экземпляр класса, который наследуется от абстрактного класса BaseNotifier. Главная задача этих объектов - отреагировать на появление шага и провести свою собственную обработку этого события: это может быть подсчет калорий, пути, скорости и т.д. Каждый такой объект так же имеет список «слушателей», каждый из которых имплементирует BaseListener и добавляет свой собственный метод обработки. После обработки шага каждый слушатель, наследованный от BaseNotifier осведомит своих слушателей и передаст управление в методы обработки каждого из них.

6. После того, как слушатель-осведомитель проведет свою собственную обработку, он вызовет метод своего слушателя. Такой слушатель имплементирует интерфейс Listener, содержащийся внутри каждого слушателя-осведомителя. Это значит, что второй слушатель будет создан в том месте, где понадобится делать обновление UI или отправлять сообщение об обновлении, если речь идет о сервисе, как в нашем случае

7. Попадая в метод слушателя, сервис создает и отправляет сообщение, которое отправляется в активности и обновляет IU

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



8. Детали реализации обработки внешних данных

В качестве внешних данных, которые могут быть интересны в контексте мониторинга здоровья человека можно использовать данные о погоде. Известно влияние атмосферного давления, температуры воздуха, влажности, а также состояния магнитного поля на самочувствие человека. Это значит, что, собирая данные о погоде можно решить сразу две задачи:

1. Информирование пользователей о неблагоприятных погодных явлениях

2. Анализ с целью выявления зависимостей между погодными явлениями и показателями здоровья и самочувствия пользователя.

Для решения первой задачи необходимо:

1. Получить информацию о прогнозе погоды и магнитных бурь из надежного источника

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

3. Основываясь на этих показателях, выработать лаконичные и понятные для пользователя предупреждения о неблагоприятных погодных условиях.

Рассмотри каждый погодный показатель отдельно.

Определение опасных температур. При определении опасных температур будем опираться на следующие интервалы:

выше +54 °C -- чрезвычайно опасно+42 -- +54 °C -- опасно+33 -- +41 °C -- предельно осторожно+27 -- +32 °C -- осторожно-24 -- +26 °C -- температуры, не считающиеся опасными-35 -- -25 °C -- сильный мороз-60 -- -36 °C -- опасность обмороженияниже -60 °C -- большая опасность обморожения

Определение некомфортной влажности. При определении некомфортной влажности будем опираться на следующие интервалы:

91 - 100 - очень высокая влажность71 - 90 высокая31 - 70 нормальная11 - 30 низкая

Определение ненормального давления.

Для определения интервала, в котором атмосферное давление можно считать нормальным, в первую очередь необходимо определить нормальное давление для конкретной местности. Сделать это можно только в том случае, если известна высота местности над уровнем моря. 760 мм.рт.ст принято считать нормальным атмосферным давлением, но ошибочно считать 760 мм рт ст давлением, которое благоприятно воспринимается организмом любого человека. Для человека, проживающего в местности, находящейся выше уровня моря на 100 м нормальное атмосферное давление составляет - 751 мм рт ст, для местности 200 м выше уровня моря - 742 мм рт ст. Это происходит потому, что организм человека адаптируется к тем условиям, в которых живет, и воспринимает их как нормальные. Отклонение от нормального в сторону больше чем на 5 мм рт ст будем считать значительным отклонением, а больше 10 мм рт ст - высоким отклонением.

В получаемых от сервера данных есть поля

float sea_level;

float grnd_level;

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