ARISE analyticsでAIエンジニアに所属している秋元です。
今回の記事の内容は、2023年6月5日〜9日で開催された人工知能学会全国大会 (JSAI2023) でポスター発表させていただいた報告です。
JSAI2023では、ARISE analytics×KDDI総合研究所様×トヨタ自動車様の共著で通信セキュリティ領域における異常通信検知に関してポスター発表させていただきました。タイトルは 「フローデータのまとまりを考慮した新たなグラフ構成手法とGNNによる異常通信検知への適用」 です。
JSAI2023について
今年のJSAI全国大会は熊本城ホールで開催されました。とてもきれいな会場です。
熊本料理もとても美味しい。
今年のセッションの様子は昨年度と大きく変わらず、AI応用、機械学習、言語メディア処理に関する発表が多数でした。タイミング的に、JSAI2023の締め切りがChatGPTブームの直前だったということもありAIや生成系に関する発表はそれほど目立ちませんでしたが、来年は生成AIに関する発表が増加するかもしれません。
興味深いセッションとしては、生成AI特別セッションレポート「日本は生成AIを起爆剤にできるのか?」という特別セッションがありました。
各研究領域の第一人者を集めて生成AIに関する以下の質問に関して議論するコーナーでした。
- 生成AIを中心とする一連の技術革新は日本経済浮揚のための起爆剤となるか?
- OpenAIに追いつき追い越すための研究とは?
- 追い越した先にある人とAIとの関係は?
最初の質問に関してはどの登壇者の方もYESで、以降の質問に関しては例えば以下のようなコメントがありました。
- 国策として進めるべし 。特にインフラ投資、計算資源、データ。(松尾先生)
- 今回の生成AIの発展は世界規模の現象で、言語による情報流通障壁が大きく軽減される可能性がある。(鳥海先生)
- まずはすでに出ているLLMの真似をすることから始める。ChatGPTはまだショーケースのようなもので、キラーアプリは出てきていないので、技術を理解し、ある意味で「こんなものか」と舐めてかかれるようになる必要がある。そこからみんなで作る・使う・工夫するというふうに広げていくのが勝ちパターン。この技術すごい、と思っている間は先には進めない。最終的には10兆円規模の事業(医療、金融、製造など)に貢献できるかどうかが勝負になる。この構造を作らなければ継続性を保てない。技術的な課題はたくさんあるので、今後いくらでも発展し、チャンスは何回でも訪れる(松尾先生)
- データ基盤(収集、クレンジング、検索)が重要になる。現時点では、検索エンジンという基盤があって初めてLLMが成立しているように見える。社会への最適化は未踏の領域。深層学習は最適化技術なので、対象としているタスクへの過剰適合が発生しやすいが、それによってタスクと現実世界のギャップは大きくなる(相澤先生)
- 生成AIやLLMは要素技術であり、本質的には実空間情報も含めた社会システムの構築が必要(鳥海先生)
LLMの最先端で実験を実施しようとすると、現時点で既に国策レベルの投資が必要になってくるとのことで、この分野の進歩の速度は本当には速いと改めて認識させられました。
一方で、現在注目を集めている技術はまだまだショーケースのようなもので、社会に浸透していくまでにはまだまだ段階があるというのも重要な指摘だと思われます。生成AIは多くの社会課題の解決に貢献できる可能性がある技術なので、ARISE analyticsもこの分野には積極的に取り組んでいきたいと考えています。
ポスター発表の紹介
ここからは、ポスター発表の内容を紹介します。
今回のポスター発表はIoTを対象とした通信セキュリティに関する研究で、具体的にはIoTがマルウェアに感染した場合に、マルウェアによる異常な通信を検知するための方法についての新しい手法の提案です。
マルウェア通信の異常検知とは?
マルウェアによる通信といえばDoSやScanなどが挙げられます。先行研究ではこのようなマルウェア通信を検知する手法が多数提案されていますが、今回はその中でも特に検知が困難なC2通信に焦点を当てました。C2通信とは、マルウェアに感染したIoTデバイスと悪意あるサーバ (C2サーバ) との間に発生する通信のことを指し、定期的な接続確認やサーバからの攻撃指令を受け取ったりするために利用されます。
DoS攻撃やホストスキャン攻撃などが発生した場合には、通信量やパケット数が一気に増大するため、通信の統計量を監視していれば攻撃が始まったことを検知することが可能です。一方でC2通信など攻撃の事前準備などで行われる通信は、統計量としては正常通信と区別がつきにくく、従来の異常通信検知手法では検知困難でした。
そこで、発想を転換してGraph Neural Networkによる異常通信検知を提案したのが今回の研究内容です。
Graph Neural Network
グラフとは以下のようにノードの集合とエッジの集合から構成されるデータ構造を指します。多くの場合ノードやエッジには特徴量が設定されます。
通信データはIPアドレスで表される通信ホストとホスト間の通信から構成されており、グラフのデータ構造と非常に相性が良いことから、GNNを用いた異常検知手法が多数提案されてきています。
ところが、先行研究の方法でIoTデバイスの通信をグラフ化した場合、以下のようになってしまいます。
このようになる理由は、どこで通信をキャプチャするかに依存しており、今回はIoTデバイスを含むホームデバイスが接続しているルータでデータを取得したためです。この位置で通信を取得した場合IoTデバイスがルータや外部サーバなど複数のマシンとやりとりする通信はキャプチャできますが、外部サーバ間の通信は取得できないため、IoTデバイスを中心としたスター型のグラフを形成することになります。
この中にC2サーバとの通信が混ざっていたとしてもエッジが一本増えるだけなので、残念ながら先行研究によるグラフ構成手法ではC2サーバを捉えることができません。
提案手法の紹介
そこで、今回の研究では発想を転換して新しいグラフの構成手法を提案しました。
注目した点は
- IoTデバイスは一般的なPCと異なり機能の数が多くない
- 機能的に単純であるため、通信の内容にはある程度順序性があると仮定できる
という点です。
特定の機能への通信順序にはパターンがあるのではないかと考え、各デバイスがどのような機能にどの順番で通信しているか、という点に着目してグラフを構成することを考えました。今回通信データとしては通信データそのものであるパケットよりも軽量なIPFIXを用いています。IPFIXはパケットとは異なり通信データそのものではなく、通信量 (バイト数) や通信パケット数などの統計量を保持するデータ形式であり、まずはシンプルに通信先IPおよび通信先ポート番号の組み合わせ機能を表現することを考えます。したがって、各ノードはある特定のIoTデバイスから特定の機能へのアクセスを表すことになり、エッジは機能へのアクセス順を表します。グラフ全体としては、あるIoTデバイスがどの機能にどのような順番でアクセスしているかを表すためのグラフ構成手法です。理想的には以下のようなグラフとなります。
提案手法のグラフにおいては、C2サーバはIoTデバイスの通信順序と関係なく通信することになるため、部分的にスター型のトポロジーを示すことが想定されます。
よって、正常通信で学習したGNNを用いてグラフ形状に関する異常通信検知を適用することによって、異常なノード=マルウェアに感染したIoTデバイスからC2サーバへの通信を検知することが可能になります。
実験結果
提案手法について、KDDI-IoT-2019データセットを用いて検証を行いました。
デバイス | 提案手法(F1) | 従来手法(F1) |
amazon-amazon-echo-gen2 | 0.005 | 0.005 |
au-network-camera | 0.188 | 0.250 |
au-wireless-adapter | 0.476 | 0.324 |
bitfinder-aware | 0.303 | 0.455 |
candy-house-japan-sesame-wifi-access-point | 0.455 | 0.400 |
google-google-home-gen1 | 0.063 | 0.044 |
i-odata-qwatch | 0.303 | 0.706 |
irobot-japan-roomba | 0.176 | 0.188 |
line-clova-wave | 0.182 | 0.545 |
linkjapan-eremote | 0.118 | 0.174 |
mouse-computer-room-hub | 0.571 | 0.343 |
nature-nature-remo | 0.435 | 0.227 |
powerelec-wifi-plug | 0.727 | 0.381 |
qrio-qrio-hub | 0.600 | 0.286 |
sony-bravia | 0.011 | 0.004 |
xiaomi-xiaomi-mijia-led | 0.429 | 0.211 |
検証結果は必ずしも提案手法で精度が上がっているわけではない。。。という結果となりました。
個別にグラフの形状を確認していったところ、提案手法で精度が高いデバイスについては想定通りのグラフが構成されていることが分かりましたが、一方で精度が低いデバイスではノード数が1~2個と極端に少なくグラフの体をなしていないものであったり、逆にノード数が非常に多くC2通信が埋もれてしまう場合などが散見されました。
これらは、機能の単位を「通信先IP、通信先ポート番号」という単純な設定にしているために起こっているものと考えられるため、いかにして最適な機能の表現を定義するか、が次の課題となりそうです。
Reference
KDDI-IoT-2019: https://github.com/nokuik/KDDI-IoT-2019