— Шеф, у нас дыра в безопасности!
— Ну хоть что-то у нас в безопасности...
Привет!
В комментариях к предыдущему посту про InoThings++ высказали мнение, что в Интернете Вещей есть более важная для обсуждения область, нежели вмешательство государства — это область обеспечения безопасности устройств. Со всех точек зрения.
Поспорить я могу здесь лишь с одним — что обсуждение вопросов безопасности стоит проводить в формате круглого стола; по этой причине круглый стол оставим как есть, на тему нужности (или ненужности) национальных стандартов и вообще вмешательства государства в дела индустрии, а про безопасность поговорим отдельно.
Почему вообще обеспечение безопасности в IoT рассматривают как что-то отдельное и специфическое, непохожее на обеспечение безопасности в классических ИТ-системах?
Да в общем потому, что IoT-системы на классические похожи лишь со стороны пользователя, видящего на экране монитора красивые картинки или управляющего лампочкой со смартфона — а вот внутри, на низком уровне, они совсем, совсем другие.
И, к сожалению, мы ещё многократно хлебнёт горя с авторами продуктов, не понимающими разницы в подходе и проблемах.
«Интернет вещей» — это, в первую очередь, история про доступные, дешёвые, компактные, экономичные, и потому крайне массовые устройства с подключением к локальным или глобальным сетям передачи данных.
Что это означает на практике?
• Как правило, беспроводное подключение. In wire we trust, конечно, вот только провод — это дорого; делавшие себе проводной умный дом понимают, что это означает капитальный ремонт с прокладкой слаботочки по всем углам. А если провод проложить вообще нельзя?
Собственно, бурное развитие IoT и началось с появлением дешёвых, экономичных и дальнобойных беспроводных соединений — начиная с домашних Wi-Fi и BLE и заканчивая LoRaWAN, Sigfox, NB-IoT и так далее. Соединений, которые позволили насытить некое пространство датчиками, не заморачиваясь с их питанием и подключением.
Однако радио — это не только удобство, но и проклятие. Если для того, чтобы подключиться к проводу, соседям надо вскрыть замки на вашей двери, то ваш беспроводной дом они не просто «слышат» примерно всегда, но и могут его эффективно глушить, а то и подделывать.
• Как правило, предельно экономичные режимы работы радиоканала — устройству без постоянного питания надо беречь батарейку. Экономия на радиоканале выливается в то, что обновление прошивок устройство по воздуху либо невозможно вообще, либо бессмысленно в силу того, что один эпизод обновления выжирает десятки процентов имеющейся батарейки.
Соответственно, крайне высокое значение приобретает изначальное качество кода и протоколов — в случае обнаружения в них фатальной дыры производитель, конечно, сможет выложить на свой сайт новый файл, но толку от этого не будет никакого.
• Как правило, маломощные низкопотребляющие процессоры. Типовой IoT'шный датчик в наше время строится на процессорах класса от STM32L0 до младших STM32L4, и просто в силу ограничений по объёмам памяти и вычислительной мощности (а также и радиоканала, см. выше) может не потянуть сложные схемы авторизации, аутентификации и прочей защиты. Более того, маломощность может означать и отсутствие «лишней» памяти, необходимой для обновления прошивок по воздуху — ненадёжность радиоканала означает невозможность накатить прошивку сразу в «живой» флэш, а под сохранение её в отдельную область с последующей перезаписью рабочей прошивки памяти может и не быть.
И над всем этим расправляет крылья массовость и вездесущность — которая на практике означает отсутствие у владельца эффективного контроля над доступом к устройствам.
Когда у вас в доме было четыре Wi-Fi-устройства — роутер, ноутбук и два смартфона — проблема их утраты стояла не очень остро, потому что ни одно из них не относится к выкидываемым мимоходом.
Когда у вас в доме три-четыре десятка умных лампочек, выключателей, термодатчиков и чёрт знает чего ещё — очередную сгоревшую или просто старую лампочку вы, скорее всего, отправите в мусор, даже не задумываясь, что она продолжает надёжно хранить у себя во флэше ключ от вашей сети Wi-Fi.
Более того, если мы говорим о масштабе не квартиры, а коттеджного участка, гостиницы или завода — вы даже не контролируете доступ к IoT-устройствам. Любой желающий может выкрутить вашу лампочку, слить из неё ключи доступа и через полчаса вкрутить обратно — а вы этого даже не заметите.
Устройства можно клонировать. Из устройств можно считывать ключи и сертификаты. В устройства можно заливать модифицированные прошивки.
Вопрос здесь не в том, что всё это нельзя было проделать с Wi-Fi роутером — можно, конечно. Вопрос в переходе количества в качество: с обещаемым нам экспоненциальным ростом числа IoT-устройств подобные атаки становятся осмысленными и реализуемыми. Фактически, повторяется история с IP-камерами — пока их было мало, никто даже не задумывался, что камер с одной и той же дыркой в прошивке будет достаточно, чтобы имело смысл написать скрипт, собирающий их в гигантский ботнет, способный завалить GitHub на пару с Twitter.
Чем это кончилось — вы все знаете.
В классической ИБ считается, что если злоумышленник получил полный физический доступ к защищаемому устройству — ну, в общем, это ещё не конец, но всё плохо. В IoT в таком контексте «всё плохо» — это не результат чьих-то злонамеренных дел, а перманентное и изначальное состояние системы.
Проблема безопасности в IoT — это не проблема завтрашнего дня. Это проблема сегодняшнего дня. Если её не решать — завтра она станет не проблемой, а катастрофой.
На InoThings++ мы, помимо прочих вещей, вне всякого сомнения, хотим поговорить и об этом — причём как дать понять разработчиком, что IoT несёт с собой совершенно новые модели угроз, так и поговорить о том, что же с этим делать.
Представлю некоторые доклады.
 |
Сергей Парьев Ростелеком-Солар «Необходимость реализации встроенных механизмов защиты информации в IIoT устройствах» |
Вводный доклад о проблематике защиты IoT-устройств и новых угрозах, характерных именно для IoT, с анализом как российского законодательства, так и уже успевших выйти рекомендациях — пока ещё не требованиях — зарубежных организаций, включая NIST, ENISA и другие (ссылки под названиями не просто так ссылки, а на соответствующие документы — очень, очень рекомендую ознакомиться с ними, если вы имеете какое-либо отношение к разработке IoT-устройств).
Этот доклад — просто must have для интеграторов и разработчиков, недавно пришедших на рынок IoT-устройств и ещё не осознавших в полной мере возможных последствий этого. Выбора здесь нет — это вещи, не знать о существовании которых просто нельзя, и если вы не понимаете этого сегодня, завтра это может кончиться для вас и вашего бизнеса катастрофой, к которой у вас просто не будет времени подготовиться.
 |
Кирилл Митягин Newsky IP Law «Правовой вакуум интернета вещей — какие изменения в законы нужны для IoT?» |
Совершенно не технический, но тоже важный доклад — о том, что сейчас мы живём в блаженное время, когда каждый производитель может навертеть в своих девайсах что его душе угодно, и ему за это ничего не будет.
Точнее, про то, что это время скоро кончится — необходимость в изменениях в законодательстве, связанных с IoT и умными устройствами вообще, назрела, и свой GDPR индустрия здесь ещё получит.
 |
Филипп Хандельянц PVS Studio «Статический анализ и написание качественного кода на C/C++ для встраиваемых систем» |
Первый (необходимый, но не достаточный) шаг к безопасности IoT-систем — это написание надёжного кода. Одним из способов повысить его надёжность является соблюдение стандартов, разработанных в отраслях, которые старше IoT на десятилетия — например, «автомобильного» стандарта качества кода MISRA C.
Само по себе соблюдение MISRA C и использование статических анализаторов кода, разумеется, не гарантирует вам абсолютную надёжность — однако может уберечь от довольно большого числа ошибок, начиная с банальной невнимательности, «копипаста» и опечаток. К сожалению, среди программистов встраиваемых систем пока что практики написания надёжного кода распространены крайне слабо — и я надеюсь, что Филипп вдохновит хотя бы часть посетителей конференции на то, чтобы попробовать эти практики в своей работе внедрить.
| Евгений Пономарёв «Rust вместо Си для программирования ARM Cortex-M» |
Другой способ повысить надёжность кода — это вместо поощряющих стрельбу по собственным ногам и прочий естественный отбор языков типа C переходить на языки, изначально задуманные как более надёжные и не дающие совершить массу ошибок (это я сейчас пишу со всей ответственностью, как человек, вчера в два часа ночи ловивший событие переполнения стека, возникавшее в случайные моменты, иногда через десятки минут активной работы прошивки).
Однако сколь светлы перспективы, столь же туманно и настоящее подобных языков — так, Rust, главный кандидат на роль будущего стандарта в области встраиваемого ПО, для большинства практикующих программистов относится к категории «слышал, прикольно, но нафига оно мне сейчас?». Особенно этому способствует традиционная кривая хайпа, по которой Rust путешествует — на её вершину он взобрался, будучи откровенно неготовым к серьёзному практическому применению, после чего многие разработчики попросту перестали следить за его дальнейшей судьбой.
Так вот, собственно, в докладе Евгений и расскажет, какова текущая судьба Rust, почему его уже можно рассматривать в качестве пригодного для работы языка и скольких километров нервных окончаний вам будет стоить его использование здесь и сейчас.
 |
Евгений Богер Wiren Board «Аутентификация устройств на Linux по аппаратному ключу в системах верхнего уровня» |
И, наконец, чисто практический доклад — о том, чего стоит обеспечение доверия к вашим устройствам, если вы установили их уже довольно много сотен штук, и при этом совершенно точно знаете, что в любой момент как минимум несколько десятков из них находятся в шкафах, которые забыли запереть и в которые в любой момент может влезть любой желающий, слить прошивку и залить её на вроде бы такое же устройство, только уже не ваше, а его.
Более того, мало эти устройства контролировать — их сначала надо ещё развернуть, что тоже с точки зрения аутентификации может являться задачей довольно нетривиальной.
InoThings++ 2019
Итак, все эти доклады — а также множество других — можно будет услышать на конференции InoThings++, и что особенно ценно — не просто услышать, а по окончании выступления взять под локоток их авторов и увести в кулуары для продолжения беседы. Собственно, именно этим и ценно живое посещение технологических конференций — просматривая спустя полгода одним глазом запись выступления или альбом на слайдшере, вы уже не сможете встать и попросить пояснить подробнее воооон тот момент, отвести докладчика на чашку кофе, чтобы поговорить поподробнее про его проекты, и так далее, и тому подобное.
Поэтому — приходите. Билеты на данный момент стоят 15 тысяч рублей, и поверьте мне, за конференцию такого уровня и с такими докладчиками — это весьма скромно.
Автор: olartamonov
