Часто задаваемые вопросы о состоянии безопасности IoT

  1. Каково текущее состояние безопасности в продуктах IoT на потребительском рынке, например, бытовая техника, носимые, интеллектуальные домашние системы и т. д.?
    Существует множество возможностей для улучшения.
    Смарт-часы: недавнее исследование HP показало проблемы безопасности и конфиденциальности во всех 10 лучших брендах смарт-часов. К числу проблем относятся отсутствие транспортного шифрования, автоматическое подключение к любому устройству Bluetooth в радиусе действия и проблемы с заблокированными экранами.
    Умные домашние системы: эти системы показывают много проблем, в том числе не шифрование данных и наличие слабых политик паролей.
    Smart TV: Некоторые бренды оставляют данные уязвимыми в пути. Например, в 2015 году исследователи обнаружили, что некоторые смартфоны Samsung отправляют незашифрованные данные распознавания голоса и текстовую информацию.

    Все эти подключенные устройства обмениваются данными с мобильными телефонами и планшетами и часто запрограммированы на автоматическое подключение к любой сети Bluetooth или Wi-Fi. И в любое время, когда устройство подключено к «общедоступной» сети, есть риски например, кража данных и саботаж. Эта функция автоматического подключения делает эти устройства уязвимыми при подключении к любой «общедоступной» сети.

  2. Почему в продуктах IoT существует такая плохая практика безопасности?
    Отсутствие понимания и преданность хорошим протоколам безопасности.
    Инженеры-разработчики и разработчики обычно больше заинтересованы в том, чтобы убедиться, что продукт работает и запускается по расписанию, а не для обеспечения безопасности этих устройств. Чтобы конкурировать на рынке, многие из этих продуктов разработаны с упором на максимально низкую стоимость. Более жесткая реализация безопасности не имеет приоритета должным образом, поскольку она обычно не снижает затраты на производство продукта. Многим устройствам IoT не хватает вычислительной мощности настольного или портативного компьютера или других высокопроизводительных устройств, что затрудняет реализацию сильной безопасности. Между специалистами InfoSec теми, кто связан с обеспечением безопасности связи между устройствами существует культурный разрыв между собой, а также механические и электрические инженеры те, которые связаны с коммутаторами, двигателями и т. д., следя за тем, чтобы устройства работали. InfoSec, как отрасль, должна лучше работать, чтобы наладить отношения с инженерами и лучше продемонстрировать ценность безопасности более эффективно, чтобы преодолеть этот культурный разрыв.
  3. Как лучше всего решать технические проблемы, влияющие на безопасность для IoT?
    Индустрия безопасности может сделать это несколькими способами, но она начинается с распознавания проблем, а затем для лучшего понимания решений. В большинстве случаев технология доступна и просто нуждается в ее реализации. Например, SSL / TLS обеспечивает надежное и масштабируемое шифрование в масштабе, который требует IoT. Сложные, управляемые системы PKI могут обрабатывать надежную проверку подлинности и обеспечивать надежное шифрование данных для всех объектов и устройств в развертываниях IoT. Решение PKI должно быть стандартом для IoT. Индустрия безопасности должна помочь поставщикам понять риски, связанные с плохой безопасностью IoT. Во-первых, нам нужно представить информацию с точки зрения конечного пользователя. Во-вторых, организации должны быть осведомлены о финансовых последствиях плохой безопасности: снижение продаж, снижение доверия к их бренду или даже риски для здоровья и безопасности, когда в разговор включены медицинские устройства, критическая инфраструктура и национальная оборона. Могут быть установлены простые меры защиты, которые уведомляют конечных пользователей о настройке элементов управления через Wi-Fi и Bluetooth, позволяя блокировать экраны и другие основные функции безопасности.
  4. Как может организация внедрить надежную инфраструктуру безопасности IoT?
    Во-первых, организации необходимо выбрать партнера центра сертификации, которому доверяют, и может эффективно масштабироваться для удовлетворения своих требований к IoT. Во-вторых, производители должны внедрять личность в устройства во время процесса развертывания OEM. В-третьих, им необходимо использовать регулируемые атрибутивные органы. Наконец, они не должны полагаться только на установленные технологии; они должны интегрировать технологии и токены, принимать политику и процедуры для целей отчетности и регулярно проверять отношения и обязанности.
  5. Что такое решение DigiCert?
    Решение DigiCert использует SSL / TLS, сертификаты и PKI для обеспечения надежного и масштабируемого шифрования для удовлетворения требований безопасности IoT. Усовершенствованная система управления PKI DigiCert и выдача сертификатов высокой доступности обеспечивают надежную проверку личности, требуемую в сочетании с надежным шифрованием данных на устройствах в рамках развертывания IoT. Платформа DigiCert PKI использует ранее проверенную информацию организации для выдачи сертификатов по запросу на основе профилей устройств для выдачи сертификатов очень быстро и в большом объеме.
  6. Что уникально в решении DigiCert?
    Как ведущий центр сертификации, DigiCert понимает текущий ландшафт безопасности SSL и фокусирует внимание на будущем отрасли. Наше решение готово к поставке на рынок и уже развернуто для удовлетворения требований выдачи большого объема сертификатов без необходимого времени.
  7. Почему решение DigiCert лучшее?
    DigiCert - это центр сертификации, специально предназначенный для повышения безопасности SSL и упрощения управления сертификатами SSL. Мы не предлагаем «дополнительное» программное обеспечение безопасности или аппаратное обеспечение, которое оставляет нам возможность создавать крайне необходимые решения безопасности для развивающихся рынков.
  8. Какие открытые стандарты и протоколы используются?
    DigiCert использует SCEP (Simple Certificate Enrollment Protocol), EST (регистрация по защищенной транспортной сети) и RESTful API (интерфейс передачи приложений для передачи состояний).
  9. Как создается закрытый ключ?
    Во время генерации закрытый ключ размещается непосредственно на устройстве по собственной криптографической библиотеке или концентратору / контроллеру как можно ближе к устройству.
  10. Если закрытый ключ генерируется «на устройстве», то сколько строк кода должно быть написано разработчиком (приблизительно)?
    Скриптинг OpenSSL для создания запросов на подпись сертификата (CSR) на основе нескольких фрагментов ввода может быть выполнен с менее чем 10 строками кода.
  11. Если секретный ключ генерируется «off-device», то сколько строк кода должно быть написано разработчиком (приблизительно)?
    Он может варьироваться от 50 до 1000 строк кода на разных устройствах, которым требуется зашифрованная связь.
  12. Поддерживает ли DigiCert генерацию секретного ключа «на устройстве», а также и «вне устройства»?
    Да, нам просто нужен запрос CSR / public независимо от его происхождения.
  13. Как хранить и защищать закрытый ключ? Как правило, он хранится на устройстве с помощью элементов управления операционными системами - ОС или он сохраняется в HSM, совместимом с FIPS.
  14. Сохраняется ли секретный ключ в оборудовании?
    Да, закрытый ключ может храниться в аппаратном обеспечении.
  15. Может приватный коюч использоваться вне устройства?
    Нет, закрытый ключ должен храниться на устройстве.
  16. Какие языки поддерживаются?
    SCEP, EST, RESTful API (JSON or XML).
  17. Какие операционные системы поддерживаются?
    По умолчанию все основные операционные системы доверяют сертификатам DigiCert.
  18. Как устройство отобрано с уникальным идентификатором?
    устройство отобрано во время производства или во время процесса приема устройства.
  19. Поддерживает ли DigiCert уникальный идентификатор клиента?
    Да, если UID необходимо включить в сертификат; это зависит от формата UID и профиля сертификата.
  20. Может ли DigiCert предоставить уникальный идентификатор, если необходимо?
    Да, некоторые профили сертификатов включают генерацию GUID в поле Subject по умолчанию.
  21. Как поставщик IoT первоначально отбирает устройство?
    В идеале поставщик IoT использует криптовальный движок на устройстве для создания закрытого ключа, убедившись, что для создания закрытого ключа используется сильный генератор случайных чисел.
  22. Как поставщик IoT повторно загружает устройство?
    Поставщик IoT использует тот же процесс, который первоначально использовался для запускания устройства.
  23. Как поставщик IoT аннулирует сертификат? Отзыв управляется через интерактивный интерфейс / вызов API. Отзыв должен быть отправлен для определенного серийного номера или идентификатора сертификата.
  24. Как поставщик IoT управляет системами, которым доверяют?
    Консоль управления устройством должна устанавливать правила доступа и элементы управления для систем, устройств, сертификатов и их соединений.
  25. Как поставщик IoT безопасно обновляет список надежных систем?
    Клиент использует аутентифицированный и / или подписанный обмен сообщениями с и с устройств на основе текущего состояния доверия сертификатов, используемых в этих системах.
  26. Каковы варианты длительности истечения срока действия сертификата?
    Срок действия сертификата зависит от потребностей проекта.
  27. Могут ли сертификаты автоматически предоставляться и регистрироваться?
    Да, сертификаты могут автоматически выпускаться и регистрироваться.
  28. Существует ли ограничение на сертификаты, которые может обрабатывать платформа PKI DigiCert?
    Система DigiCert может обрабатывать сотни, тысячи, миллионы или даже миллиардные сертификаты. Неважно проект большой или небольшой.
  29. Примерно, сколько строк кода должно быть написано разработчиком для связи с платформой на основе сертификатов?
    Если вначале не поддерживается поддержка криптовальной библиотеки, DigiCert рекомендует импортировать доверенную библиотеку. Если крипто-библиотеки уже присутствуют, вероятно, для большинства задач будет достаточно от 50 до 250 строк кода.
  30. Примерно, сколько строк кода должно быть написано разработчиком для обеспечения целостности пакета программного обеспечения?
    Проверка подписи проста, поэтому возможно менее 200 строк кода (при наличии необходимых библиотек).
  31. Примерно, сколько строк кода должно быть написано разработчиком для защищенной связи между устройствами?
    Это будет зависеть от метода связи и доступных библиотек, но для чего-то вроде MQTT, возможно, менее 200 строк кода.
  32. Предоставляет ли DigiCert лицензирование на основе устройств или сертификатов?
    DigiCert предлагает гибкие цены, которые обычно основаны на сертификатах.
  33. DigiCert взимает оплату за другие компоненты их решения?
    DigiCert только взимает оплату за сертификаты.


Написати повідомлення

Ваш email
Ваш телефон
Тема повідомлення
Текст повідомлення
Symantec SSL  сертификаты для Украины Я люблю Україну !


Symantec SSE+ лого адграфиксCallBack
є питання: зателефонуйте +380672576220 skype: webtrust.ua
Top ^
Усі серти * Code * PDF * Email * IoT * Wi-Fi * PKI * DV * OV * EV * Новости * Help *

NO russia - мы не осблуживаем резидентов из россии Copyright © 1997-2018 adgrafics