Почему safety-critical софт становится краеугольным камнем IoT-революции

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

Safety-критические приложения опирались на софт десятилетиями. Например, программа полетов Apollo, запущенная президентом Джоном Ф. Кеннеди в 1961 году, включила бортовое полетное ПО для наведения миссий по высадке на Луну.

Пока кибербезопасность часто доминирует в заголовках, качество софта — особенно для безопасности — часто остается недоизученным. «Я думаю, софт-мир проснулся к безопасности. Я не думаю, что они еще проснулись к ограничениям безопасности», — сказала Кейт Стюарт, старший директор стратегических программ Linux Foundation и финалистка награды IoT World Leader of the Year.

[IoT World — крупнейшее в Северной Америке IoT-мероприятие, где стратеги, технологи и исполнители связываются, внедряя IoT, AI, 5G и edge в действие по отраслям. Забронируйте билет сейчас.]

В IoT конвергенция цифрового и физического миров трансформирует операции по секторам — от медицинских устройств до военной экипировки. Но эта инновация также топливает столкновение парадигм разработки, как объясняет кибербезопасность эксперт Брюс Шнайер в «Click Here to Kill Everybody: Security and Survival in a Hyper-connected World».

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

В Linux Foundation Стюарт чемпионирует Zephyr Project — реально-временную ОС, спроектированную для безопасности и безопасности на ресурсно-ограниченных устройствах.

«В Internet of Things люди фокусируют линзу на том, с чем они комфортны», — сказала Стюарт. «Я фокусируюсь на глубокой embedded стороне и сборе данных безопасно и securely». Она добавляет, что многие стандарты безопасности 20–30 лет и часто отстают от современных практик софта.

Ключевой вызов — оценка того, как обновление софта может непреднамеренно создать проблемы безопасности. «Когда вы делаете много security updates к этому софту, инвалидирует ли это ваш первоначальный анализ? Что нужно сделать, чтобы убедиться, что применяя баг или security фикс, вы не делаете вещи хуже? У нас не обязательно есть лучшие инструменты прямо сейчас для разбора этого», — объяснила Стюарт.

Закрытые стандарты безопасности добавляют еще один слой сложности. «Есть целый ряд [безопасности] стандартов прямо сейчас, на которые все смотрят, и интересный вызов с open source перспективы в том, что эти стандарты все закрыты», — отметила Стюарт. «Open source разработчики не обязательно хотят платить $3000 за взгляд на стандарты».

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