# SoK: Beyond IoT MUD Deployments - Challenges and Future Directions

###### tags: `論文メモ-IoT-MUD`

## アブストラクト
IoTデバイスがサイバー攻撃に関与するケースが増えており、重要なインフラや企業、市民に与えるリスクについて社会的な関心が高まっています。このようなリスクを低減するために、IETFは、IoTベンダーに対して、IoTデバイスの意図された目的について、MUD（Manufacturer Usage Description）の形で正式な仕様を策定するよう働きかけています。これにより、あらゆる動作環境におけるIoTデバイスのネットワーク動作をロックダウンし、厳密に検証することができます。

私たちは、任意のIoTデバイスのトラフィック・トレースを入力とし、そのデバイスのMUDプロファイルを自動的に生成するツールを開発しました。我々が分析した28台のコンシューマー向けIoTデバイスのMUDプロファイルを生成しました。以下では、我々のデータとツールを公開します。

## 本文の要約

### 1章 導入
大体はいつも通りのやつ(IoTデバイスが普及しているが、セキュリティ面に問題があるうんぬん)

- 1p目左側の第2段落
`IoTデバイスの動作を詳細に説明する責任をメーカーに与えることは、これまでにも検討されており[1]、IETF（RFC 8520）による仕様の正式化に向けた取り組みも行われています[2]。本研究では、この方向性における現在の研究の概要を示し、今後の調査を必要とする多くの研究課題を特定しました。さらに、これらの課題を解決するために、メーカーが提供するMUDとユーザー定義のポリシーをCOTSデバイスに展開することに焦点を当てたソリューションを紹介します。`
:arrow_down:
COTSデバイスって何？
[商用オフザシェルフ](https://e-words.jp/w/COTS.html)(要するに市販の既製品のことらしい)

- 1p目:貢献(Contributions)より
`本論文では、最新のMUD展開シナリオを分析し、各アプローチの課題と欠点を議論します。我々は、ネットワーク管理者とエンドユーザに、ユーザーフレンドリーなインターフェイスを介してMUDコンポーネントと対話する機会を提供するUser Policy Server (UPS)を紹介します。しかし、提供された概念実証は、本稿で分析された新しい課題を提示しています。`

### 2章 MUDの概観
MUDは、主に以下の3要素から成り立つらしい。

`MUDの導入は、3つのアーキテクチャ・ビルディング・ブロックで構成される必要があります。`

1. MUD（Manufacturer User Description）ファイル：機器メーカーが作成し、機器とその予想されるネットワーク上の動作を記述したもの。
2. ユニフォーム・リソース・ロケータ（URL）：家庭や中小企業のネットワークにデバイスが追加されたときに、メーカーのサーバーからMUDファイルを取得するために使用されます。
3. ローカルネットワーク管理システムが説明文を取得するためのメカニズム。

`(ここまで本文)`

図を用いて動作をまとめると以下の通りになる。


`ここから引用`
1. ネットワークに新規デバイスが接続されると、X.509証明書付きのMUD-URLを送信するか、DHCPまたはLLDPを送信する。
2. ローカル・ルーター（ネットワーク・アクセス・デバイス（NAD）として）が、リクエストの認証のために MUD-URL を AAA サーバーに送信します。
3. AAA サーバーが、認証された MUD-URL を MUD マネージャに送信します。MUDマネージャーは、X.509認証の場合、署名とリクエストを検証しする。
4. メーカーのファイルサーバーからMUDファイルを取得する。
5. MUDファイルは、YANGベースのJSONファイル（IETF RFC 7951）[3]に、機器メーカーの公開鍵署名を施したものです。MUDマネージャーは、MUDファイルの検証と処理を行い、その証明書が有効になるまでファイルをローカルに保存し、アクセスコントロールリスト（ACL）を生成します。
6. MUD マネージャはACLをNAD(Network Access Device、ここではルータのことらしい) に送信する。NAD は、MUD マネージャから受け取った ACL 規則を、NAD を通過するすべてのトラフィックに適用します。

`引用ここまで`

[LLDPとは？](https://beginners-network.com/lldp.html)
[AAAサーバー？](https://www.internetacademy.jp/it/management/security/authentication-mechanism-aaa.html)

ようするに、メーカー等が制作したMUDプロファイルをもとにACLを構成するようだ。実装に関しては3つの組織(Cisco,NIST,MasterPeace Solution開発のOpenSource MUD)によるものが紹介されている。

A,B,Cは細かい各組織の実装の違いを記載している。(一時省略)

### 3章 発見:制限とセキュリティ問題
前章の3実装に関して、実験環境で調査を行った結果をまとめている。

#### A.Cisco MUD
`概念実証として、この展開の主な制限は MUD マネージャの設定に関するものです。実際には、MUD マネージャを開始する前に、DNS 解決サービスの設定を人間のオペレータが手動で行っており、新しい設定を行った場合には MUD マネージャのプロセスを再起動する必要があります。このような静的な設定では、DNS解決サービスの設定が手動で行われるため、スケーラビリティの問題や、新しい設定を行うためにMUDマネージャを再起動する必要があるため、可用性の問題が発生します。このように、Ciscoの導入は実際の環境では実用的ではありません。`

`また、実装そのものに関わる静的な制限として、ACLの管理があります。特に、イングレス・トラフィック（外部からネットワークに受信され、ローカルのIoTデバイスに向けられたトラフィック）を含むすべてのルールは固定されています。そのため、MUDに準拠したIoTデバイスであっても、デバイスのMUDファイルにそのドメインからのトラフィックを受信する権限がないことが明記されているにもかかわらず、外部ドメインからの攻撃にさらされてしまいます。それでも、イグレス・トラフィック（IoTデバイスから外部ドメインに送信されるトラフィック）を含む動的なルールがサポートされています[7]。このため、攻撃者は外部ドメインからデバイスとのTCP接続を確立することができません。`

#### B.NIST MUD
`Ranganathanら[5]が提供したSDNベースのPoCでは、パケット処理にいくつかの問題があります。テーブルパイプライン（セクションII-B）に従うと、スイッチの接続時にインストールされるMACアドレス（最初のテーブル）の分類ステージの最初のルールは、パケットをコントローラに送ることはできても、次のテーブルに送ることはできません。そのため、パケットが分類されるまでテーブルパイプラインを進まない可能性があります。これは、新たに接続されたデバイスからのパケットが、ルールがインストールされるまで第1テーブルを通過できないため、スイッチの故障などのパフォーマンス上の影響を意味します。厳密なACLが必要な場合、このような動作が必要になることがあります。しかし、Ranganathanら[5]は、このような状況に対処するために、ACEの定義を緩めた「リラックス」モードを提案しています。このモードでは、分類フロー規則がインストールされている間、パケットがパイプラインを進行することができる。これは、システムが最終的にMUD ACEsに準拠するようになるという条件で、MUD ACEsの違反につながる可能性がある。このようなパケットは、スイッチに分類ルールがインストールされる前に通過してしまう可能性があります。`

#### C.Open Source MUD
`この実装の限界は、展開の要件にあります。MUDマネージャーをホストするためには、特定のバージョンのdnsmasqを使用しているOpenWRT準拠のルーターのみがこの展開に採用できます。MUDマネージャをOpenWRTの外で実行するためにosMUD開発者が提供した貴重なソリューションは、C環境でコンパイルすることです。これは、互換性のあるファイアウォールと、MUD対応デバイス用のDHCPヘッダパケットからMUD-URLを抽出できるDHCPサーバを使用する必要があるからです。このように、OpenWRTは、大多数の汎用ルータで利用可能であり[10]、MUDマネージャの展開を容易にするという点で、最もユーザフレンドリな選択肢であると言えます。最後に、現在の実装では、横方向に移動するためのMUDファイルのルールがありません。そのため、攻撃者はネットワーク内を徐々に移動し、標的となる重要なデータや資産を探すことができます。`

### 4章 セキュリティの挑戦
上記の3実装の問題点について。
1. どの実装もDHCPやLLDPを用いている([X.509証明書](https://atmarkit.itmedia.co.jp/ait/articles/0401/01/news098.html#:~:text=X.509%E8%A8%BC%E6%98%8E%E6%9B%B8%EF%BC%88X,%E9%9B%BB%E5%AD%90%E7%BD%B2%E5%90%8D%E3%81%A8%E3%81%97%E3%81%A6%E6%A9%9F%E8%83%BD%E3%81%99%E3%82%8B%E3%80%82)を不使用)
つまり、URLの詐称の可能性がある。
2. MUDの仕様自体に関連しているが、IoTデバイス自体に固有のセキュリティ保護を提供していない。デバイスのMUDファイルが、悪意のあるドメインからの通信の受信をIoTデバイスに許可している場合、そのドメインからのトラフィックを利用してIoTデバイスを攻撃することができる。

(1)ローカル環境において、侵害されたIoTデバイスのローカル攻撃をどのように防ぐか。(2) MUDファイルがローカルにデプロイされ機能している状態で、MUDの署名証明書が期限切れになった場合、MUDマネージャーは、IoTデバイスの可用性と機能性を妨げることなく、新たな署名付きファイルを取得し、ルールを更新する必要があります。(3)MUDの強制ルールでは十分なきめ細かさの制御ができない。個々のユーザーは、それぞれの環境に応じて追加のルールを必要とする可能性があります。そのため、ユーザーポリシーを組み込んでトラフィックをフィルタリングし、より細かい制御を行う仕組みが必要です。(4)Threat Signalling Serverからのアップデートをどのように組み込むか。この方向でのさらなる質問と調査は、MUDファイルを介してアップデートを行うべきか、すべてのIoTデバイスのための一般的な共通サーバーのアップデート（およびフィルタ）を介してアップデートを行うべきかということです。

### 5章 MUD利用可能ネットワークにおけるユーザーポリシーサーバ


本稿での改善点を踏まえた概観が図5らしい。図1のそれとの相違点と比べた差は主に3点ある。

1. osMUD(open source MUD)Managerが動作しているOpenWRTルータ
2. リモートで動作しているメーカー製MUDファイルサー
3. ローカルで動作しているローカルサーバ上のユーザポリシーサーバ(UPS)

`ユーザポリシーサーバは、ExpressフレームワークをベースにしたWebサーバで、アーキテクチャはManufacturer MUD File Server（MFS）と似ています。このエンティティを導入することで、内部ネットワークの管理者やエンドユーザは、MUDが導入されているネットワークに適したルールを含む新しいMUDファイル（以下、UPSファイルと呼ぶ）を保存することができます。このようにして、ネットワーク管理者は、MUDのすべてのコンポーネントを、ユーザーフレンドリーなインターフェースを使って操作することができるようになりました。`

cf.[OpenWRT](https://ja.wikipedia.org/wiki/OpenWrt)

では、MUDプロファイルにユーザ側のポリシーを反映させるUPSとは何なのか？

※Manufacturer MUD File Server

`UPSは、同じYANG準拠のJSONファイルとMFS※上インタラクションを使用することで、osMUDアーキテクチャ全体の変更を伴わないことに留意する必要があります。特に、osMUDの実装は、以下のワークフローを組み込むために、我々によって拡張されています(図 5)。(1)MUDマネージャが製造元のMUDファイルサーバからMUDファイルを取得する(2)MUDマネージャがファイルの検証と解析を行い、ACLを生成してNetgearルータにACLを挿入する(3)MUDマネージャがUPSにデバイス用の別のUPSファイルがあるかどうかを尋ねる(4)Yesの場合、MUDマネージャがファイルを取得し、ファイルの検証と解析を行い、ACLを生成してNetgearルータにACLを挿入する。`

この直後読むと、UPSの仕組みによって、管理者の思う通りのACLが構成可能とか書いてある。(基本的にACLはメーカーの想定するACL+ユーザーによるオプションで成り立ち、前者がない場合もACLを構成可能になるとしてある。)

その次の段には、MUDファイルの記述とUPS由来のACLの間で齟齬が出る場合にどうにか解決しなければ、みたいなことが書いてある。(下)

`しかし、ルールの統合によって、冗長性（限られたストレージ）やルールの衝突（パケットフィルタリングのパフォーマンス[11]）といった新たな課題が生じる可能性があります。前者は、IPテーブルのルールを挿入するルールなど、マッチング技術を使用することで簡単に管理できます。後者は、解決しなければならない重要な問題を誘発します。例えば、メーカールール(MUDファイル)ではAとBの2つの外部ホストとの通信が許可されているが、管理者ルール(UPSファイル)ではAとCのみが許可されているとします。これらの問題は、本研究の目的から外れているが、将来のUPSバージョンでは検討されるであろう。このように、MUD ルールの削除や変更ができることを考えると、UPS の使用には十分な検討が必要である。`

また、そのあとにはpcapからMUDプロファイルを生成する[ツール(参考文献12)](https://github.com/ayyoob/mudgee)やUPSファイルによる追加指定要素に関する内容を記載してある。

#### A.評価
実際にosUMD+考案されたUPSで実験環境を構築、パフォーマンスを確認してみたらしい。ここでいうパフォーマンスとは、MUDファイルによるACLが展開されるまでの時間を指している。実験ではルータのブートが終わる前に全デバイスがonの状態を"最悪の状態"としていた。
(あとは多少の評価が書いてあるがそこまで参考にならず)

### 6章 関連研究
`IoTデバイスから生成されるトラフィックを制限するための分離ベースの防御メカニズムとしてのMUDの使用は、まだ初期段階にあります。そのため、いくつかの導入シナリオや概念実証（PoC）の実装しか存在していません。Andalibiら[14]は、MUDの機能を拡張して、メッセージサイズ、ピークレート、期間内の最大メッセージ送信数などのトラフィックパターンを含めることを提案し、それらのフィルタリングをフォグネットワークのファイアウォールに実装することを提案しています。しかし、この論文では実装はされていません。また、これらのトラフィック制御リストをフォグネットワークでどのように実施するか、このソリューションを大規模な組織でどのようにスケーラブルにするかについても、詳細は示されていません。Yadavら[15]は、ユーザー制御ポリシーとMUDを組み合わせて、IoTデータのきめ細かい制御を行うシナリオを提案しています。この作品は、外部サービスと直接交換されるメッセージを制御するために、MUDでユーザーベースのポリシーを使用する方法を提供するのに欠けています。Ranganathanら[5]は、OpenFlow対応のSoftware Defined Networkingスイッチ上でのMUD規格のスケーラブルな実装を発表し、Hamzaら[16]、[17]は、MUD準拠のトラフィックからIoTデバイスに対するDoS、反射型TCP/UDP/ICMPフラッディング、ARPスプーフィングなどのボリューメトリック攻撃を検出する機械学習手法を開発しました。Feraudoら[13]は、MUD準拠のエッジネットワークにおけるFederated Learningの発表と評価を行い、User Policy Server(UPS)のユースケースを示しました。Graciaら[18]は、産業用IoT環境において、SDNを活用したセキュリティ・アーキテクチャにより、IoTデバイスの安全で自動化されたデプロイメントを管理するプロアクティブ・セキュリティ・アプローチを発表しました。Matheuら[19]は、データ・プライバシー、チャネル保護、リソース認証などの追加的な側面を表現するために、柔軟なポリシー言語を用いた拡張MUDモデルを発表しました。Afekら[20]は、ISP内にデプロイされたVNFを通じてIoTセキュリティを提供するために、MUD仕様に基づいて構築されたシステムを発表しました。`

### 7章 結論
`MUDの仕様は、セキュリティやアーキテクチャの観点から、いくつかの制限があります。MUDに完全に準拠したコンポーネントを使用している場合でも、ローカル・ポリシーによってのみ定義される動作があります。製造者によって提供されたデフォルト・ポリシーが、ネットワーク・スタンダードに対して十分でないか、または制限が強すぎる場合、ユーザーは、異なる望ましいポリシーに従ってデバイスを設定する必要があります。このように、本研究では、既存のMUDの実装を調査し、一般ユーザにとって最も便利な展開を見つけようとしています。さらに、この作品では、必要に応じてMUDコンポーネントのデフォルト設定を変更するために、MUDコンポーネントと対話するために必要なユーザー・フレンドリーなインターフェースを提供するUPSウェブ・サーバを実装しています。定義された動作により、MUDが配備されているネットワークに適したホワイトリスト・ルールを構築することができます。今後の方向性としては、より高いレベルのセキュリティを保証するために、ユーザ・ポリシー・サーバの機能を拡張し、実装上の不整合の問題を解決することに重点を置く予定です。本論文で発表した内容は、有用な知見を提供するものであり、研究開発コミュニティがこの内容から恩恵を受けることを期待しています。さらに、この研究は、これらのソリューションを実際の展開シナリオに採用する前に、より多くの議論を可能にするものです。`