デバイスのセキュリティを最新に保つための基準

IoTデバイスは通常、低利益率と低電力仕様で構築されているため、機能は通常、必要な機能に制限されます。ただし、数年続くと予想されるデバイスの場合、セキュリティの脆弱性と修正が必要な問題が発生します（例としてMiraiボットネットを参照）。

IoTメーカーとして、暗号化アルゴリズムまたはセキュリティプロトコルのパッチ適用またはアップグレードをリモートで有効にするにはどうすればよいですか。どの基準に従うべきですか？

IoTメーカーは、暗号化アルゴリズムまたはセキュリティプロトコルのパッチ適用またはアップグレードをリモートで、または単にデバイスの安全を確保するためにどのように有効にするのですか？

多くのIoTメーカーがこれに対する簡単なソリューションを持っています：「気にしないでください」。これらは、デバイスにデフォルトの（または変更不可能な）パスワードを追加する開発者と同じ傾向があり、Miraiが最初に導入されました。

Roryの回答で述べたように、修正を設計および展開するためのメカニズムと実際の開発時間の両方を提供するには、かなりのコストがかかります。規制上の圧力（またはそうではないように思われる消費者の需要）がなければ、メーカーがセキュリティを強化するために製品の価格を引き上げるインセンティブがないと私は強く疑います。オーストラリアは、すべてのIoTデバイスに必須のセキュリティ評価システムを検討することにより、このステップを踏んでいるようです。

ほとんどのメーカーにとって、最良のアイデアは誰かにセキュリティを任せることだと思います。ほとんどのWeb開発者のような確立フレームワークを使用と同じようにジャンゴとのRuby on Railsを避けるために作っ 同じ過ちを何度も、IoTを開発者が同じことを行う必要があります。デバイスの複雑さに応じて、いくつかのオプションがあります。

• ハイエンドデバイスは、セキュリティ更新がOS開発者によって行われ、自動的にプッシュされるUbuntu IoTまたはWindows 10 IoT Coreなどのオペレーティングシステムを使用できます。これの多くはIoT固有ではありませんが、メンテナンスを受ける可能性が低いカスタムの社内オペレーティングシステムを使用する各IoTデバイスよりもはるかに望ましいです。

• ESP8266モジュールなどのローエンドデバイスは、そのような複雑なオペレーティングシステムを実行できず、そのデバイス用に特別に開発されたコードを実行する傾向があるため、おそらくさらに制限されます。無線ファームウェアのアップデートを提供するMongoose OSなどのオプションがまだあります

IoTメーカーは通常、既存のソリューションを利用できる場合はそれを利用する必要があります。Web開発者は通常、新しいWebサイトごとにWebフレームワークを再作成しないので、なぜIoTは大幅に異なる必要があるのでしょうか。Roryの答えは、IoTの優れたオペレーティングシステムによって実装する必要がある機能の優れたリストを提供します。「IoT OS」を使用するだけではすべての問題を解決できるわけではありません。このWindowsのIoTをガイドが説明して、一つは、ハードウェアとファームウェアがOS自体だけでなく、固定されていることを確認するための措置をとる必要があります。ロリーの答えのアイデアは、この点でかなり包括的です。

セキュリティのアップグレードに使用するシステムについて、私が提案したオペレーティングシステムの例をいくつか示します。

• Windows IoT：

  • インターネットに接続したときの自動機能およびセキュリティ更新
  • Azure IoT Suiteを使用すると、各デバイスには、ハブに対して認証するためのX.509証明書があります。これにより、1つのデバイスが侵害されても、他のデバイスが影響を受けないことが保証されます

• Ubuntu Core：

  • セキュリティのための無人自動更新
  • 「トランザクション無線アップデート-完全なロールバック機能付き」

Moran は、2017年10月30日にこのIETFドラフトを「モノのインターネットデバイスのファームウェアアップデートアーキテクチャ」というタイトルで投稿しました。

Bleepingコンピュータで概説されている主要な要約は

• ファームウェアバイナリがBluetooth、WiFi、UART、USB、またはその他のメディアを介して配信される場合でも、更新メカニズムは同じように機能する必要があります。
• 更新メカニズムは、ブロードキャストタイプの配信で機能し、更新が複数のユーザーに同時に到達できるようにする必要があります。
• ファームウェアイメージの検証と検証には、エンドツーエンドのセキュリティ（公開キー暗号）を使用する必要があります。
• ロールバック攻撃を防ぐ必要があります。
• デバイスが更新のインストールに関する決定を行うために必要なすべての情報は、制約のあるIoTデバイスの使用可能なRAMに収まる必要があります。これにより、フラッシュ書き込みの枯渇が防止されます。
• 更新プロセス中のいつでも停電がデバイスの障害を引き起こしてはなりません。
• ファームウェア更新メカニズムでは、既存のファームウェアファイル形式を変更する必要はありません。
• 新しいファームウェア更新メカニズムは、ほとんどのIoTデバイスに固有の小さなブートローダーで動作できる必要があります。
• 更新メカニズムは、複数の権限を考慮する必要があります。たとえば、重要なインフラストラクチャ機器のファームウェア更新は、ファームウェアの作成者と機器の所有者/オペレーターの両方が署名する必要があります。
• 新しいIoTファームウェア更新アーキテクチャは、マニフェストファイルをサポートする必要があります。

これは新しい領域なので、これは非常にドラフトです。消費者は更新やセキュリティに直接影響を与えない限り本当に気にしないので、消費者の需要よりも規制によって駆動されることが私の期待です。この領域での改善は、デバイスのコストに影響を与えます。

デバイスのファームウェアが、セキュリティで保護されたリモート更新に必要なブートローダーよりも複雑でない場合は、リモート更新を実装しないでください。

強力な公開暗号化認証、安全なロールオーバーメカニズム、おそらく基本的なネットワークスタックを備えた安全で堅牢なブートローダーを用意し、その上にRTOSを完全なIP + TLSネットワークスタックで配置することで合意が得られることを知っています。その上にあなたのアプリケーション。これは、低コストの低電力デバイスにとっては純粋な狂気です。私見、これは毎週かそこら更新される製品につながります、時々更新が間違った時に開始される、何かが失敗するか壊れるのでユーザーを悩ます傾向があります。更新も大量の電力を消費するため、ユーザーはより頻繁に充電する必要があります。また、攻撃対象領域が大きいため、セキュリティはまだ保証されていません。

デバイスは基本的な検知/作動を行っていますが、おそらくローカルトリガー/表示を行っていますが、それほど多くはありませんか？すべてスキップします。

ベアメタルコードを記述し、非常に基本的なスタックを使用し、徹底的に監査し、可能であれば正式な検証を行います。そして、あなたはあなたのデバイスが次の10年間セキュリティ問題を抱えていないことを比較的確信することができます。

ハンマーさえあれば、すべてが釘のように見えます。そしてそのため、ほとんどのコーダーは、セキュリティで保護されていない既存のコードを保護するコードを記述しようとします。少ないコードを書くことは、常に自然に起こるとは限りません。