Что если физическое воплощение Интернета унаследует все изъяны виртуального?
Тысячи устройств, которые достаточно скоро сформируют Интернет вещей, во многом обладают теми же слабыми местами с точки зрения безопасности, что и их старшие родственники: компьютеры, мобильные устройства, маршрутизаторы и облачные сервисы.
Многие из них работают под одним из дистрибутивов операционной системы Linux и используют те же библиотеки, что и в обычном Интернете. Таким образом, они никак не менее уязвимы.
На самом же деле многие устройства оказываются защищены еще слабее, отчасти потому что нетерпеливые разработчики либо не задумываются о безопасности, либо надеются, что «все обойдется», либо решают отложить эти вопросы «на потом». А потом хватаются за голову.
Наверняка, вы наслышаны о том, что на многих первых устройствах для Интернета вещей нельзя обновить прошивку – либо это обновление крайне неудобно для пользователя, даже если обнаружена критическая уязвимость или ошибка, не говоря уже о добавлении новых возможностей. Ситуация постепенно улучшается, но проблема в основном остается.
Хотя может показаться, что во взломе какого-нибудь умного устройства нет ничего особенно страшного, но на самом деле оно может стать для злоумышленника отличной зацепкой, с которой можно будет предпринять атаки на другие компьютеры и устройства в локальной сети, что очень плохо.
В обозримом будущем именно устройства Интернета вещей станут слабейшим звеном в безопасности домашних или даже корпоративных сетей.
Вызывают беспокойство и устройства, занимающие самый дешевый сегмент рынка. Частью продавцов этого сегмента уже используется подход «продать и забыть», при котором о какой-либо технической поддержке говорить не приходится (разве что купить следующую версию продукта). Остается только надеяться, что с усилением конкуренции такой подход сойдет на нет.
Часть энтузиастов предлагает выделять все такие устройства в отдельную или гостевую локальную сеть, тем самым упрятывая проблему на задворки.
Некоторые производители используют архитектуру, при которой все их устройства общаются между собой посредством отдельного беспроводного протокола (Zigbee, MiWi, 6LoWPAN, Z-Wavе и др.), а доступ к Интернету получают через центральный узел, сообщающийся с локальной сетью. Но и такой подход не решает проблему, а лишь сосредотачивает ее в данном центральном узле (и намечает лакомую цель – взломай его и получишь доступ ко всему).
К какому бы из подходов вы не склонялись для защиты устройства – он все равно окажется пустым звуком. В любом случае, рядовой покупатель в блаженном неведении просто подключит устройство к одной единственной своей локальной сети.
Данные подходы лишь расширят огромный зияющий пробел в системах разработки программного обеспечения – недостаток повсеместного внимания к безопасности. Да, я уже слышу ваши стенания: мы итак это все знаем, 15 лет как этой безопасностью занимаемся и не видать ей ни конца ни края. Как показывает один лишь только 2014 год, даже у крупнейших игроков на рынке до сих пор обнаруживаются поразительные промахи. Куда уж тут нам, простым смертным?
Недавно ассоциация IEEE – Институт инженеров по электротехнике и электронике – решил поддержать новый курс, ориентированный на безопасность в программном обеспечении, создав Центр безопасного проектирования и составив список из 10 распространенных ошибок в проектировании, которые приводят к уязвимостям систем. Ассоциация обещает не останавливаться на этом.
«Работа центра предполагает сдвинуть акцент в сфере безопасности с поиска конкретных ошибок на общее понимание распространенных недостатков в проектировании, в надежде, что разработчики программного обеспечения смогут учиться на ошибках других».
Список стоит того, чтобы взглянуть на него (и приводится в конце статьи). Он достаточно неплох и может стать отличной отправной точкой, если ваши представления о безопасности до сей поры ограничивались лишь скачиванием новейших версий используемых сторонних библиотек.
Даже более искушенным разработчикам, занимающимся системной архитектурой, не помешает прочитать список – вполне может случиться, что какой-нибудь из упомянутых подходов мог просочиться в систему, по каким-то причинам показавшись в свое время стоящим.
Институт инженеров по электротехнике и электронике далеко не одинок в ратовании за безопасность, так почему же такой подход не работает? Я гадаю, слышат ли, вообще, разработчики все эти новости о «плохих парнях» с их бесконечным списком уязвимостей «нулевого дня» на счету, если могут после этого сидеть за своим компьютером и беззаботно кодить очередную крутую штуку, которая изменит мир?
Как долго мы еще будем вычерпывать воду из протекающей лодки?
Каждую неделю, если еще не каждый день, новости рассказывают об очередном взломе программного обеспечения, сайта или онлайн-сервиса, утечке пользовательских учетных данных. А сколько таких взломов, когда жертвы ничего не стали сообщать или вовсе ничего не заметили? И все это сопровождается постфактум нелепым, но обязательным выпуском новых исправлений по расписанию. И сколько еще можно будет испытывать доверие пользователей к программному обеспечению и онлайн-сервисам, пока не будет достигнут предел и, к примеру, все пользователи забросят пользование банковскими услугами по Интернету?
Что тогда сможет вернуть их доверие?
Мне напомнили о Директиве ЭМС (Электромагнитной совместимости), выпущенной Евросоюзом в середине 90-х годов и устанавливающей требования к показателям радиоизлучения, защите от радиопомех, воздействия статического электричества, шума электросетей и т.д., без соответствия которым ни одно электронное изделие не могло быть допущено к продаже.
Этот набор стандартов был несколько строже, чем установленные правила Федерального агентства связи США, и был нацелен на то, чтобы стремительно растущий мир устройств смог корректно сосуществовать. До того момента нормативные акты не принимали в расчет то, что почти каждый будет ходить с прицепленным к поясу радиопередатчиком мощностью в несколько ватт, а потому многие электроприборы начинали давать сбои, когда рядом находился сотовый телефон.
Мир изменился, и нам пришлось ему соответствовать. У инженеров по электротехнике ушли годы на то, чтобы выработать под новые требования конструктивные решения, наборы инструментов, методы тестирования и новые компоненты. Понадобилось развитие независимых лабораторий для испытаний. И, наконец, понадобилась обратная связь для понимания, что может сойти с рук «по закону X в стране Y», а что не будет допущено к продаже, прежде чем инженеры смогли «на глаз» создавать соответствующие нормативам устройства.
Я полагаю, что забота о безопасности должна стать неотъемлемой частью программирования, столь же неотделимой от него, как определение типов и области видимости переменных. Это станет важнейшей вехой в становлении отрасли для того, чтобы справиться с бесконечным потоком взломов, предотвратить надвигающийся кризис доверия людей к облачным технологиям, и не допустить превращение Интернета вещей в рассадник вредоносных программ.
Как бы банально это не прозвучало, но трудно не заметить появления все новых схем сертификации и спецификации, или расширения уже существующих. Думаю, мы увидим значительное развитие и распространение продуктов и услуг по автоматизированному тестированию кода, системному тестированию, тестированию на возможность проникновения в систему. А отраслевые организации будут ставить гриф утверждения безопасности программного обеспечения.
Частью этого является и упомянутая инициатива Института инженеров по электротехнике и электронике. Я приветствую их намерения, но в одиночку они никогда не смогут стать ориентиром для разработчиков. Инициатива должна распространяться гораздо шире, и как можно скорее. Эти советы нужно дублировать всюду, где программисты могут оказаться в поиске знаний и совета – от университетов, учебников и отраслевых конференций до сайтов вопросов и ответов, встреч по интересам и хакатонов. Только в таком случае безопасность будет рассматриваться не как удел какой-то отдельной части разработчиков, а общей проблемой.
До тех пор Интернет вещей остается катастрофой, многократно увеличивая нашу уязвимость до таких масштабов, о которой злоумышленники ранее не могли и помыслить.
Список 10 самых распространенных ошибок безопасности от IEEE:
1. Никогда не исходите из допущения, что клиенту можно доверять.
2. Используйте механизмы аутентификации, которые нельзя обойти или подделать.
3. Авторизуйте пользователя после аутентификации.
4. Четко разделяйте данные и управляющие команды, никогда не обрабатывайте управляющие команды от источников, не заслуживающих доверия.
5. Убедитесь, что все данные однозначно прошли проверку.
6. Используйте криптографию правильно.
7. Определите конфиденциальные данные и порядок их обработки.
8. Всегда принимайте во внимание пользователя.
9. Разберитесь, как использование сторонних компонентов повлияет на безопасность системы в целом.
10. Проявляйте гибкость в будущих изменениях для объектов и участников.
Автор: Энтони Мэй
Перевод - Павел Корнилов
Оргинал - http://www.itnews.com.au/BlogEntry/391633,want-an-internet-of-things-fix-the-internet-first.aspx