IoTデバイスのセキュリティレベルを示す証明書はありますか?


11

これらのデバイスの提供されたセキュリティを比較するために使用できるIoTデバイスの信頼できる証明書はありますか?1

現在、IoTランドスケープには、さまざまなプロトコル、標準、独自のソリューションが完全に散在しています。一方、IoTデバイスはハエのようなボットネットに分類さます。デバイスが特定のレベルのセキュリティに準拠することを顧客が信頼できる標準はありますか?たぶん、提供されたセキュリティを保証する証明書ですか?

現在の標準がない場合、そのような標準を作成する有望な取り組みはありますか?


1:免責事項:これは、コミットメント段階でサイトにコミットしなかったと思われるユーザーからのこのArea 51の質問に基づいています。サイトの範囲を定義するのに役立つように投稿したいと思います。

回答:


10

UL(以前のUnderwriters Laboratories)は、モノのインターネットデバイスがほとんどの主要な脅威から保護されていると認定するためのサイバーセキュリティ保証プログラムを提供しています。

Ars Technicaによると、ULは認証プロセスで非常に尊敬されているようです。

さまざまなマーク(UL、ENECなど)が電気配線、洗浄製品、さらには栄養補助食品など、さまざまな分野の最小安全基準を認定している122年の歴史を持つ安全基準団体であるULは、現在、インターネットのサイバーセキュリティに取り組んでいます。新しいUL 2900認証を取得したモノ(IoT)デバイス。

ULはそれらの認証を次のように説明しています:

  • すべてのインターフェースでゼロデイ脆弱性を特定するための製品のファズテスト
  • Common Vulnerability Enumerations(CVE)スキームを使用してパッチが適用されていない製品の既知の脆弱性の評価
  • 製品上の既知のマルウェアの識別
  • Common Weakness Enumerations(CWE)によって特定されたソフトウェアの弱点の静的ソースコード分析
  • Common Weakness Enumerations(CWE)、オープンソースソフトウェア、およびサードパーティライブラリによって特定されたソフトウェアの弱点の静的バイナリ分析
  • セキュリティリスクを低減する製品で使用するために特定された特定のセキュリティコントロール[...]
  • 他のテストで特定された欠陥に基づく製品の構造化侵入テスト
  • 製品に組み込まれた製品セキュリティ緩和策のリスク評価。

ただし、ULがデバイスを精査する正確なプロセスは(Ars Technicaが指摘するように(そして批判))、(仕様の完全なセットを購入するためにお金を払わない限り)不明確です:

Arsが規格を詳しく調べるためにUL 2900文書のコピーを要求したとき、UL(以前はUnderwriters Laboratoriesと呼ばれていました)は辞退しました。セット-私たちはそうすることを歓迎しました。独立したセキュリティ研究者も、ULの小売顧客になることを歓迎します。

ULが尊重されていますが、我々は仮定することはできません、それは元の質問を満たさないものの、その認定は特に、さらに精査することなく、セキュリティの面で音されていること。

残念ながら、セキュリティのためのオープンな標準/認証を見つけることができませんでした。これは、非営利団体にとって必要なリソースが多すぎるためと考えられます。


3

既知の脅威からしか保護できないというAurora0001の回答に加えたいと思います。

最近、ハードウェアに対するSpectreおよびMeltdown攻撃が確認されています。IntelのCPUはIoTデバイスでは一般的に使用されていませんが、将来的にはIoTハードウェアにセキュリティ上の問題が見つかる可能性があります。以前、一般的なシステムクラスのバグとしてRowhammerHeartbleedが多数のシステムに影響を及ぼしているのを見てきました。IoTが成長するにつれ、そのような脆弱性を目にすることはより一般的になると思います。

だから私はセキュリティ認証に焦点を当てるのではなく、次のことについてもっと焦点を当てます:

  • オープン性。サードパーティがソフトウェアを評価できるようにするため。
  • 明記されたサポートライフタイム。製造元がセキュリティアップデートを保証します。
  • デフォルト設定としての自動アップグレードを含むアップグレード可能性。

デバイスが長期間サポートされていると述べられており、新しいリリースが発生したときにデフォルトでソフトウェアを自動更新する場合、セキュリティの問題の影響は軽減されます。認定は、製品の出荷時に既知のセキュリティバグがなかったことを通知するだけです。


Heartbleedは、システム展開の観点からはシステムクラスのバグである可能性がありますが、それでもアップグレードが必要な特定のソフトウェアのバグです。より良い例は、BEASTやCRIMEなどのプロトコル自体への攻撃です。
Gilles 'SO-悪をやめる'

ポイントは、バグがありそうもない場所(CPU)とよく知られたソフトウェア(Heartbleed)に見つかる可能性があるため、ソフトウェアのパッチと更新が必要であることです。しかし、はい-たくさんのバグから選択できます。
vidarlo 2018年

認定には、サポートのライフタイムや、ファームウェアの更新能力、さらにはオープン性が含まれることもあります。ですから、これらは非常に重要なポイントであるとおっしゃっていますが、一般的に認定と互換性がない理由はよくわかりません。
ヘルマー

2
@Helmar残念ながら、真面目な認定は本質的にかなり重いプロセスです。初期バージョンと更新プロセスの認証は1つですが、展開前に各更新を認証するとかなりのオーバーヘッドが発生するため、適切な認証プロセスを確立することが難しくなります(セキュリティ更新プログラムは、事後に認証する必要があるため、これに反します)デバイスが認定されていないバージョンを実行することを意味するため、認定の粒度。
Gilles 'SO-悪をやめる'

@ギレス私は、ソフトウェア開発またはそのようなものの品質プロセスを証明することしかできないことに同意します。すべてのソフトウェアバージョンを認定することは、実際の選択肢ではありません。
ヘルマー
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.