進化するインターネット技術／IETFトピックス2016-17

第10回

サイバーセキュリティを“守る側”が情報連携するためのデータ構造／プロトコルたち

  • 高橋 健志（国立研究開発法人情報通信研究機構）

2017年10月13日 06:00

インターネット技術の普及に向け、IPv6、DNS、HTTPなど基本となるプロトコルを定めてきたIETF（The Internet Engineering Task Force）。今年11月には、100回目の会合（IETF 100）がシンガポールにて開催される予定である。IETFがこれまで手がけてきたインターネット技術も、技術の進歩と普及により、現在も多くの分野において議論が継続され、まだまだ目が離せない状況が続いている。本連載では、インターネットの普及と発展を目的に日ごろIETFを中心に活動を行っているISOC-JP（Internet Society Japan chapter）メンバー有志が、ここ最近のIETFでの活動状況について紹介していく。

　増大するサイバー空間での脅威に対応するには、組織間の情報連携が必要不可欠であり、さらにはそれに基づく対策の効率化・自動化が求められている。そのためには各種データ構造やプロトコルなど、インターフェースを標準化する必要があるが、それを先導して実施している機関の1つにIETFが存在する。そこで今回と次回の2回にわたり、IETFにおける本分野における検討の現状を紹介したい。

今求められるセキュリティ情報連携と対策の自動化

　IETFでの検討の現状に入る前に、サイバーセキュリティの現状を少し振り返ってみたい。

　ご存知の通り、サイバー空間での脅威は増加傾向にあり、ここ数年、その脅威は一段と増大してきている。その脅威の1つにランサムウェアが存在する。ランサムウェアとはユーザーの端末上のデータを勝手に暗号化し、その復号鍵を提供する見返りに支払いを強要するマルウェアであり、「WannaCry」という名前のランサムウェアが猛威を振るったことは記憶に新しいと思う。

　また、昨年はIoTセキュリティの脅威が目に見える形で現実のものとなった年である。マルウェア「Mirai」によってボットネット化したIoT機器が大規模なDDoS攻撃を仕掛けたことは記憶に新しい。さらには、フィンランドでは冬にビルオートメーションシステムを故障させ、暖房を利用不可能にした事件も発生した。厳しい寒さに襲われる同国では、住民の生命を脅かしかねない大事件である。重要インフラ向けの脅威では、ウクライナの首都キエフにて停電を引き起こしたマルウェア「Industroyer」などが登場している。

このように多数の脅威が存在している中、十分な対策を講じることがなぜできないのか？　さまざまな理由が存在するが、その1つが、各組織間での効率的な情報連携ができていないことが挙げられる。攻撃者が高度に連携し効率的に攻撃を仕掛けてくるのに対し、守る側も連携が必要不可欠である。また、深刻な人材不足も大きな要因である。IoT機器などの守るべきデバイス数の激増を鑑みると、人材育成だけでは対応は難しく、並行してセキュリティ対策の効率化・自動化が求められているのである。

情報連携とセキュリティ対策の自動化には技術標準が必要不可欠

それでは、どのようにその自動化を実現すべきか？　まずは各種情報を機械処理できるかたちで記述し、交換することが必要不可欠になる。そして、そういった情報を組織間で共有する際には、そのインターフェースを標準化する必要がある。

　IETFでは、セキュリティ情報連携とそれに基づく対策の自動化の重要性を認識しており、すでにWGを構築して、検討を重ねてきている。具体的には、MILE（Managed Incident Lightweight Exchange）、SACM（Security Automation and Continuous Monitoring）、DOTS（DDoS Open Threat Signaling）、I2NSF（Interface to Network Security Functions）などのワーキンググループ（WG）にて検討が進められている。

　IETFでは、スコープを具体的かつ絞り込むことがWGに求められるため、かなり検討の領域が限られているが、その分、焦点を絞った検討が効率的に実施できる。まずは、インシデント情報交換技術を検討するMILEについて、説明したい。

MILEでは、インシデント情報を組織間で共有する技術を検討

　IETFでは、2002年8月からINCH（Extended Incident Handling）WGが存在しており、そこで、CSIRT間にてインシデント情報を交換するためのデータモデルであるIODEF（Incident Object Description Exchange Format）が構築されてきた。INCH WGは2006年10月にその役目を終え解散していたが、時代背景とともに本技術検討の発展が求められ、2011年10月にINCHの後継WGとしてMILE WGが立ち上げられるに至った。

　MILE WGではインシデント情報を交換する技術を扱い、インシデント情報の表現方法、トランスポート技術、そしてガイドラインについて検討を進めている。

【MILE WGにおける技術検討トピックの一覧】
カテゴリトピック文書名
情報の表現・記述IODEF version 2RFC7970
JSON IODEFdraft-ietf-mile-jsoniodef
Enum referenceRFC7495
IODEF-SCIRFC7203
トランスポートRIDRFC6545
RID over HTTP(S)RFC6546
ROLIEdraft-ietf-mile-rolie
XMPP-griddraft-ietf-mile-xmpp-grid
ガイドラインIODEFの拡張規格作成ガイドラインRFC6684
拡張規格作成時のIANA利用ガイドラインRFC6685
IODEF文書の作成・利用に関するガイドラインdraft-ietf-mile-iodef-guidance
IODEF対応のアプリケーション実装ガイドラインRFC8134

インシデント情報を構造的に記述するIODEF

　MILEではIODEFをベース技術としている。IODEFは、インシデント発生時に組織間にて交換すべき情報、すなわちインシデント情報のデータ構造と、そのXMLスキーマを定義している。2007年にIODEFがRFC化されてから数年が経過していたため、昨今のサイバーセキュリティ脅威に対応すべく、MILEでは2016年にIODEF version 2（以下、IODEF v2）を発行した。2007年当時はCSIRT間での情報交換が主目的であったが、2016年のIODEF v2検討時には、各種組織間、そして組織内の各種部署間の連携も含めたさまざまな情報連携が必要不可欠であるという前提に立ち、その視点で効率的に情報交換できるデータ構造が定義された。また、機器間での情報交換を効率化・自動化することも視野に入れて本規格の検討はなされたのである。

　その結果、IODEF v2では60を超えるクラスが定義されており、情報をかなり細かく、構造的に記述できるため、機械処理できる情報の範囲が大幅に拡大している。本規格は“maximum flexibility（最大限の自由度の担保）”の設計思想の下で構築されたため、詳細かつ非常に広範囲の情報が記載できるが、それらをすべて記載する必要はなく、必要な要素だけ記述することが可能である。その際にはIODEF文書も簡潔なものになる。

　IODEF v2はデータ構造を定義した規格であるものの、XMLを強く意識した規格である。XMLはほかの記述方式に比べて冗長であり、かつmaximum flexibilityという設計思想の下で構築されたIODEF v2は冗長度が高いといわれることがある。それはその通りである。しかしながら、そのXMLデータをそのまま人間が読解することは想定しておらず、何らかのparser等のアプリを通じて、各組織の中で使いやすいかたちでデータは表示されていることを想定しており、その際には、なるべく細かい情報をXMLに記録して残しておきたいというのが考え方の根底にある。

　とはいえ、環境によってはXMLを用いた情報交換がそぐわないケースも多い。IODEF v2はXMLスキーマを想定して作成されているが、JSON形式でIODEF文書を表現する規格も現在検討されている。

IODEFの拡張を定義する規格群

　IODEFは拡張性に優れた規格であり、ユーザーが自由に拡張して活用することができる。また、RFC7495とRFC7203では、外部の規格をIODEFに効率的に埋め込み可能にしている。例えばRFC7203では、CVE識別子やOVAL（Open Vulnerability and Assessment Language）スクリプトなど、各種識別子やXML文書を埋め込む際の共通インターフェースが定義されており、機械処理可能情報をさらに増大することが可能である。なお、MILEではなくINCHの成果ではあるが、そのほかにもフィッシングを報告するためのIODEF拡張もRFC5901にて定義されている。

さまざまなトランスポート技術を準備

　インシデント情報を効果的かつ効率的に共有するための技術の1つに、RFC6545のRID（Real-time Inter-network Defense）がある。RIDでは、IODEFなどのインシデント情報を交換する際に、そのセキュリティ、ポリシー、プライバシー機能を提供する。RIDはさまざまなトランスポートプロトコルを利用可能であるものの、HTTP/TLSを用いた伝送については、RFC6546に定義されている。

　そのほか、ATOMを用いた配信技術として、ROLIE（Resource-Oriented Lightweight Information Exchange）が提案されている。これにより、情報発信者はセキュリティ関連情報をWeb-addressableなリソースとして効率的に発行することができ、ユーザーは必要に応じて必要な情報を効率的に取得することができる。同様に、インスタントメッセージサービスのコア技術であるXMPPを用いた手法“XMPP-grid”も定義されている。なお、XMPP-gridとROLIEは、どちらもIODEFに特化せず、セキュリティ関連情報全般を交換できる点に注意されたい。また、RIDはRPCベースであるが、XMPP-gridとROLIEはどちらもRESTfulな構造となっている。

IODEFの理解を深め、利用を促進する各種ガイドラインも存在

　MILEでは、上述のとおりの各種技術規格を構築するのと同時に、これらの理解・利活用を促進するためのさまざまなガイドラインが定義されている。詳細は割愛するが、例えばIODEF文書の作成、利用に関するガイドラインが用意されており、これによりIODEFへの参入障壁を最小化しようとしている。また、IODEF文書を処理するアプリケーション実装に関するガイドラインが用意されている。

　以上、本記事ではMILE WGにて検討されているインシデント情報のデータ構造ならびに情報交換プロトコル、そして各種ガイドラインについて紹介した。とはいえ、セキュリティ対策を効果的かつ効率的に実施するためには、交換すべき情報はインシデント情報に限らない。そのため、MILE WG以外の場所でも、サイバーセキュリティに関するさまざまな情報交換技術の検討がなされている。これらの技術を有効に活用することで、少しでも効率的にセキュリティ対策を実施していただければ幸いである。