Часті питання про стан безпеки IoT
- Який поточний стан безпеки в продуктах IoT на споживчому ринку, наприклад, побутова техніка, інтелектуальні домашні системи і т. д.?
Існує безліч можливостей для поліпшення.
Смарт-годинник: недавнє дослідження HP показало проблеми безпеки і конфіденційності у всіх 10 кращих брендах смарт-годинників. До числа проблем належать відсутність транспортного шифрування, автоматичне підключення до будь-якого пристрою Bluetooth в радіусі дії і проблеми з заблокованими екранами.
Розумні домашні системи: ці системи показують багато проблем, в тому числі не шифрування даних і наявність слабких політик паролів.
Smart TV: Деякі бренди залишають дані уразливими в дорозі. Наприклад, в 2015 році дослідники виявили, що деякі смартфони Samsung відправляють незашифровані дані розпізнавання голосу і текстову інформацію.Всі ці підключені пристрої обмінюються даними з мобільними телефонами і планшетами і часто запрограмовані на автоматичне підключення до будь-якої мережі Bluetooth або Wi-Fi. І в будь-який час, коли пристрій підключено до «загальнодоступної» мережі, є ризики, наприклад крадіжка даних і саботаж. Ця функція автоматичного підключення робить ці пристрої уразливими при підключенні до будь-якої «загальнодоступної» мережі.
- Чому в продуктах IoT існує така погана практика безпеки?
Відсутність розуміння і відданість хорошим протоколам безпеки.
Інженери-розробники і розробники зазвичай більше зацікавлені в тому, щоб переконатися, що продукт працює і запускається за розкладом, а не для забезпечення безпеки цих пристроїв. Щоб конкурувати на ринку, багато з цих продуктів розроблені з упором на максимально низьку вартість. Більш жорстка реалізація безпеки не має пріоритету належним чином, оскільки вона зазвичай не знижує витрати на виробництво продукту. Багатьом пристроям IoT не вистачає обчислювальної потужності настільного або портативного комп'ютера або інших високопродуктивних пристроїв, що ускладнює реалізацію сильної безпеки. Між фахівцями InfoSec, тими, хто пов'язаний із забезпеченням безпеки зв'язку між пристроями, існує культурний розрив між собою, а також і між механічними та електричними інженерами , які пов'язані з комутаторами, двигунами і т. д., стежачи за тим, щоб пристрої працювали. InfoSec, як галузь, повинна краще працювати, щоб налагодити відносини з інженерами, краще продемонструвати цінність безпеки і подолати цей культурний розрив. - Як найкраще вирішувати технічні проблеми, що впливають на безпеку для IoT?
Індустрія безпеки може зробити це декількома способами, а починається все з розпізнавання проблем, а потім починається прийняття рішень. У більшості випадків технологія доступна і просто потребує її реалізації. Наприклад, SSL / TLS забезпечує надійне і масштабується шифрування в масштабі, який вимагає IoT. Складні, керовані системи PKI можуть здійснювати надійну перевірку справжності і забезпечувати надійне шифрування даних для всіх об'єктів і пристроїв в розгортанні IoT. Рішення PKI має бути стандартом для IoT. Індустрія безпеки повинна допомогти постачальникам зрозуміти ризики, пов'язані з поганою безпекою IoT. По-перше, нам потрібно представити інформацію з точки зору кінцевого користувача. По-друге, організації повинні бути обізнані про фінансові наслідки поганої безпеки: зниження продажів, зниження довіри до їх бренду або навіть ризики для здоров'я і безпеки, коли в розмову включені медичні пристрої, критична інфраструктура і національна оборона. Можуть бути встановлені прості заходи захисту, які повідомляють кінцевих користувачів про налаштування елементів управління через Wi-Fi і Bluetooth, дозволяючи блокувати екрани і інші основні функції безпеки. - Як може організація впровадити надійну інфраструктуру безпеки IoT?
По-перше, організації необхідно вибрати партнера в особі центру сертифікації, якому довіряють, і який може ефективно масштабуватись для задоволення своїх вимог до IoT. По-друге, виробники повинні впроваджувати особистість в пристрої під час процесу розгортання OEM. По-третє, їм необхідно використовувати регульовані атрибутивні органи. Нарешті, вони не повинні покладатися тільки на встановлені технології; вони повинні інтегрувати технології і маркери, приймати політику і процедури для цілей звітності та регулярно перевіряти відносини і обов'язки. - Що таке рішення DigiCert?
DigiCert використовує SSL / TLS сертифікати та PKI для забезпечення надійного і масштабованого шифрування для задоволення вимог безпеки IoT. Удосконалена система управління PKI DigiCert і видача сертифікатів високої доступності забезпечують надійну перевірку особистості, необхідну в поєднанні з надійним шифруванням даних на пристроях в рамках розгортання IoT. Платформа DigiCert PKI використовує раніше перевірену інформацію організації для видачі сертифікатів на вимогу на основі профілів пристроїв для видачі сертифікатів дуже швидко і у великому обсязі. - Що унікально в рішенні DigiCert?
Як провідний центр сертифікації, DigiCert розуміє поточний ландшафт безпеки SSL і фокусує увагу на майбутньому галузі. Наше рішення готове до постачання на ринок і вже розгорнуто для задоволення вимог видачі великого обсягу сертифікатів без необхідного часу. - Чому рішення DigiCert краще?
DigiCert - це центр сертифікації, спеціально призначений для підвищення безпеки SSL і спрощення управління сертифікатами SSL. Ми не пропонуємо «додаткове» програмне забезпечення безпеки або апаратне забезпечення, яке залишає нам можливість створювати вкрай необхідні рішення безпеки для ринків, що розвиваються. - Які відкриті стандарти і протоколи використовуються?
DigiCert використовує SCEP (Simple Certificate Enrollment Protocol), EST (реєстрація захищеної транспортної мережі) і RESTful API (інтерфейс передачі додатків для передачі станів). - Як створюється закритий ключ?
Під час генерації закритий ключ розміщується безпосередньо на пристрої за власною криптографічною бібліотекою або концентратора / контролера якомога ближче до пристрою. - Якщо закритий ключ генерується «на пристрої», то скільки рядків коду має бути написано розробником (приблизно)?
Скриптинг OpenSSL для створення запитів на підпис сертифіката (CSR) на основі декількох фрагментів введення може бути виконаний з менш ніж 10 рядками коду. - Якщо секретний ключ генерується «off-device», то скільки рядків коду має бути написано розробником (приблизно)?
Він може варіюватися від 50 до 1000 рядків коду на різних пристроях, яким потрібен зашифрований зв'язок. - Чи підтримує DigiCert генерацію секретного ключа «на пристрої», а також і «поза пристрою»?
Так, нам просто потрібен запит CSR / public незалежно від його походження. - Як зберігати і захищати закритий ключ?
Як правило, він зберігається на пристрої за допомогою елементів управління операційними системами - ОС або він зберігається в HSM, сумісному з FIPS. - Чи зберігається секретний ключ в обладнанні?
Так, закритий ключ може зберігатися в апаратному забезпеченні. - Може приватний ключ використовуватися поза пристроєм?
Ні, закритий ключ повинен зберігатися на пристрої. - Які мови підтримуються?
SCEP, EST, RESTful API (JSON чи XML). - Які операційні системи підтримуються?
За замовчуванням всі основні операційні системи довіряють сертифікатам DigiCert. - Як пристрій відібрано з унікальним ідентифікатором?
Пристрій відібрано під час виробництва або під час процесу прийому пристрою. - Чи підтримує DigiCert унікальний ідентифікатор клієнта?
Так, якщо UID необхідно включити в сертифікат; це залежить від формату UID і профілю сертифіката. - Чи може DigiCert надати унікальний ідентифікатор, якщо необхідно?
Так, деякі профілі сертифікатів включають генерацію GUID в поле Subject за замовчуванням. - Як постачальник IoT спочатку відбирає пристрій?
В ідеалі постачальник IoT використовує кріптовальний движок на пристрої для створення закритого ключа, переконавшись, що для створення закритого ключа використовується сильний генератор випадкових чисел. - Як постачальник IoT повторно завантажує пристрій?
Постачальник IoT використовує той же процес, який спочатку використовувався для запускання пристрою. - Як постачальник IoT анулює сертифікат?
Відгук управляється через інтерактивний інтерфейс / виклик API. Відгук повинен бути відправлений для певного серійного номера або ідентифікатора сертифіката. - Як постачальник IoT управляє системами, яким довіряють?
Консоль управління пристроєм повинна встановлювати правила доступу і елементи управління для систем, пристроїв, сертифікатів і їх з'єднань. - Як постачальник IoT безпечно оновлює список систем?
Клієнт використовує аутентіфіцированний і / або підписаний обмін повідомленнями з пристроїв на основі поточного стану довіри сертифікатів, які використовуються в цих системах. - Які варіанти тривалості закінчення терміну дії сертифіката?
Термін дії сертифіката залежить від потреб проекту. - Чи можуть сертифікати автоматично надаватися і реєструватися?
Да, сертифікати можуть автоматично випускатися і реєструватися. - Чи існує обмеження на сертифікати, які може обробляти платформа PKI DigiCert?
Система DigiCert може обробляти сотні, тисячі, мільйони або навіть мільярдні сертифікатів. Неважливо проект великий або маленький. - Приблизно, скільки рядків коду має бути написано розробником для зв'язку з платформою на основі сертифікатів?
Якщо з самого початку не підтримується підтримка криптовальної бібліотеки, DigiCert рекомендує імпортувати довірену бібліотеку. Якщо крипто-бібліотеки вже присутні, ймовірно, для більшості завдань буде досить від 50 до 250 рядків коду. - Приблизно, скільки рядків коду має бути написано розробником для забезпечення цілісності пакету програмного забезпечення?
Перевірка підпису проста, тому можливо менше 200 рядків коду (при наявності необхідних бібліотек). - Приблизно, скільки рядків коду має бути написано розробником для захищеного зв'язку між пристроями?
Це буде залежати від методу зв'язку та доступних бібліотек, але для чогось на кшталт MQTT, можливо, менш 200 рядків коду. - Чи надає DigiCert ліцензування на основі пристроїв або сертифікатів?
DigiCert пропонує гнучкі ціни, які зазвичай засновані на сертифікатах. - DigiCert стягує оплату за інші компоненти їх вирішення?
DigiCert тільки стягує оплату за сертифікати.