Что необходимо знать каждому руководителю об архитектуре безопасности IoT | iot.ru Новости Интернета вещей
92.26 € 99.71

Что необходимо знать каждому руководителю об архитектуре безопасности IoT

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

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

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

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

Начало: моделирование угроз

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

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

Подход STRIDE

Для оценки угроз безопасности IoT можно использовать подход STRIDE. STRIDE – аббревиатура из следующих категорий угроз:

  • Spoofing (спуфинг). Злоумышленник совершает действия, маскирующие его под какое-либо лицо или программу. Атакующий может сымитировать исполнение команды, пройдя авторизацию в центральной ИТ-системе, чтобы ускорить, например, работу насосов для нефтяных скважин до опасного значения.

  • Tampering (взлом, вмешательство). Злоумышленник изменяет передаваемые данные о состоянии насосов. Исправные устройства будут отображаться как «сломанные», а службы сервисного обслуживания отправят специалиста с дорогостоящим оборудованием для замены агрегатов и ремонта установок.

  • Repudiation (Отказ). Вредоносные действия совершаются, однако злоумышленник утверждает, что непричастен к ним. В таких ситуациях, когда приложение или система не используют элементы управления для правильного отслеживания и регистрации действий пользователей, можно говорить об атаке отказа (Repudiation attack). Это позволяет злоумышленникам манипулировать или подделывать идентификацию новых действий. Подобная атака может использоваться для изменения «авторской» информации о действиях, выполняемых хакером, чтобы отражать неверные данные в файлах журнала или удалять их. Если такая атака была выявлена, то данные, хранящиеся в файлах журнала, могут считаться недействительными или не заслуживающими доверия.

  • Information disclosure (Раскрытие информации). Злоумышленники видят информацию компании, передаваемую по определенным каналам. Например, если они поймут, что все доступные насосы были переключены на работу на полную скорость, то могут предпринять попытку саботажа транспортировки по трубопроводу между нефтяной скважиной и нефтеперерабатывающим заводом.

  • Denial of service (Отказ в обслуживании). Атакующий не позволяет системе работать надлежащим образом или вовсе выводит ее из строя. Злоумышленник наводняет линию коммуникации достаточным количеством трафика, чтобы подавить локальную систему управления насосами.

  • Elevation of privilege (Повышение привилегий). Злоумышленник, не имея соответствующего доступа, расширяет свой базовый уровень привилегий в ИТ-системе до более высокого. Например, сотрудник компании, чья учетная запись в ИТ-системе скомпрометирована, может обладать правами мониторинга за состоянием рабочего оборудования. Незаконно он или хакер получают возможность нелегально расширить свои полномочия до управления скоростью и работой насосов.

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

В дополнение к STRIDE следует использовать другую полезную модель под названием DREAD.

DREAD расшифровывается как:

  • Damage (урон, степень вреда);

  • Reproducibility (Воспроизводимость; то, как легко можно воспроизвести атаку);

  • Exploitability (Эксплуатирование, то, как легко запустить вредоносное ПО);

  • Affected People (Затронутые пользователи; количество пострадавших пользователей);

  • Discoverability (Раскрываемость; насколько легко может быть обнаружена угроза).

Существуют и другие методологии.

Составление плана компонентов и зон для угроз

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

  • Хранилища данных. Файлы и базы данных в любой области хранения, локальные или удаленные, относятся к информации об IoT-устройствах и управлению ими. Как правило, они подвержены угрозам типа TID и, возможно, R, из категорий STRIDE.

  • Потоки данных. Данные, перемещаемые между устройствами и системами. Как правило, они подвержены угрозам типа TID.

  • Практическое использование. Программные приложения, прошивки и аппаратно-реализуемые программы подвержены всем угрозам STRIDE.

  • Внешние объекты, например, пользователи. Следует учитывать угрозы SRD.

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

  • Насосы для нефтяных скважин.

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

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

  • Любое программное обеспечение, взаимодействующее с устройствами через пограничный и/или облачный шлюз.

Архитектуры защиты IoT

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

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

Подписаться на новости Обсудить

Назад

Комментарии

Текст сообщения*
Защита от автоматических сообщений