海の向こうの“セキュリティ”

　5月はソニー絡みのインシデントが国際的にも注目を集めましたが、今回は脆弱性情報流通に関する新たな標準化について紹介します。

　民間の非営利団体ICASI（Industry Consortium for Advancement of Security on the Internet）は5月17日、脆弱性情報を報告・共有（レポーティング）するための標準記述形式「CVRF（Common Vulnerability Reporting Framework）」バージョン1.0を公開しました。

■URL
　The Common Vulnerability Reporting Framework（CVRF）v1.0
　http://www.icasi.org/cvrf
　ホワイトペーパー（PDF）
　http://www.icasi.org/docs/cvrf-whitepaper.pdf

　ICASIは2008年に発足した非営利団体で、世界規模でITセキュリティを推進することを目的としています。加盟している企業はCisco、Intel、IBM、Juniper、Microsoft、Nokia、Amazonです。

■URL
　ICASI
　http://www.icasi.org/

　CVRFはICASIのプロジェクトの1つで、脆弱性情報をユーザーなどにアナウンスしたり、関連企業や組織などとの間で共有したりする際の記述形式を共通化しようというもの。

　現在、脆弱性情報に関しては、識別子としてCVE（Common Vulnerabilities and Exposures）が、また、深刻度を示す値としてCVSS（Common Vulnerability Scoring System）がすでに広く使われています。しかし、脆弱性情報の内容そのものに関しては、当該ベンダーやCSIRTなどがそれぞれ独自の形式を用いて記述しています。例えば「マイクロソフト セキュリティ情報」やJPCERT/CCの「注意喚起」、US-CERTの「Technical Cyber Security Alert」などはその典型例です。そのため、脆弱性情報を必要とする側は、各々の文書を目で見て分類し、その中から自分にとって必要な情報を選別しなければならないのです。

　CVRFは、このような脆弱性情報をXMLを用いた共通の形式で記述することで機械的な処理を可能とすることを目的としたものです。もちろん無料で使えます。

　CVRFを使えば、脆弱性情報を必要とするユーザーにとって本当に必要な情報の選別や優先順位付けが（かなりの程度まで）機械的に行なえるようになるだけでなく、例えば、脆弱性を発見した人とその情報流通を調整する機関（Coordination CSIRT）および当該ベンダーとの間での情報共有が効率的に行なえるようになるわけです。

　CVRFは、インシデント情報の交換に用いられる標準記述形式IODEF（Incident Object Description Exchange Format）を基にしています。IODEFには莫大な数の項目がありましたが、CVRFは「脆弱性情報の記述」に限定されていることから（IODEFに比べれば格段に）シンプルな構造になっています。CVRF v1.0の全体像はMindMapの形になっている図1を参照してください。

図1　CVRF MindMap（拡大画像はhttp://www.icasi.org/images/CVRF-mindmap.jpeg）

　図1のうち赤字が必須項目でそれ以外の項目は任意となります。

• Document Title
• Document Type
• Document Publisher
• Document Tracking
  
  • Document ID
  • Document Version
  • Document Revision History
  • Document Initial Release Date
  • Document Current Release Date
  • Document Generator（Schemaバージョンのみ）
  • Document Status
• Issuing Authority

 
　これらは項目名でだいたいの内容が分かると思いますが、以下に簡単に紹介します（詳細はhttp://www.icasi.org/cvrf_dictionaryを参照）。
 

• Document Title
  文書のタイトルを示す文字列です。例えば、最近のマイクロソフトのセキュリティ情報MS11-036であれば「Microsoft PowerPointの脆弱性により、リモートでコードが実行される」が該当します。
  
  
• Document Type
  文書の種別を示す文字列で、例えば
  
  
  
  • Vulnerability Report
  • Security Bulletin
  • Security Notice
  
  などがあります。上述のMicrosoftの例なら「マイクロソフト セキュリティ情報」が該当すると思われます。
  
  
• Document Publisher
  文書提供者種別。以下の5つから選択。
  
  
  
  • Vendor：ベンダー
  • Discoverer：脆弱性の発見者（研究者など）
  • Coordinator：脆弱性情報の調整機関（JPCERT/CCやCERT/CCなど）
  • User：該当製品のユーザー
  • Other：その他
    
    
• Document Tracking
  文書を、更新を含めて識別する項目群であり、以下の項目を含みます。
  
  
  
  • Document ID
    識別番号。先ほどのマイクロソフトの例なら「MS11-036」が該当します。
    
    
  • Document Version
    バージョンを示す数字、またはドットで区切られた数字の並び。正規表現として (0|[1-9][0-9]*)(\.(0|[1-9][0-9]*)){0,3} でマッチングされるもの。
    
    
  • Document Revision History
    改訂履歴。1つ以上の「Document Revision」で構成されます。また各「Document Revision」は「Revision Number」「Revision Date」「Revision Description」の3つからなり、例えば以下のような内容になります。

    　　　　1.0.0.1, 2005-10-25, 対象製品の一覧を更新

    なお、最新の「Revision Number」は常に「Document Version」と一致していなくてはいけません。

  • Document Initial Release Date
    文書が最初にリリース(公開または発表)された日付（時刻は任意）。
    
    
  • Document Current Release Date
    現在のバージョンがリリース（公開または発表）された日付（時刻は任意）。
    
    
  • Document Generator
    文書を生成したツールなどに関する情報。ただし必須なのはCVRFのバージョンのみ。
    
    
  • Document Status
    文書の「状態（Status）」を示すもので以下の3つから選択。
    
    
    
    • Draft：リリース前の原稿（草稿）
      
    • Interim：暫定版（文書発行側でまだ変更される可能性があると考えられているもの）
      
    • Final：最終版（文書発行側では変更されると考えられていないが、必ずしも更新されないとは限らない）
      
      
• Issuing Authority
  文書の発行者に関する情報。この文書に関する問い合せ先や何の権限でこの文書を発行しているのか(文書の正当性)を示す文言など。

　図1を見ると、CVEやCWE（Common Weakness Enumeration）といった脆弱性を識別するものが項目として含まれていますが必須項目ではありません。しかし、上記の必須項目が示しているように、CVRF v1.0では当該文書そのものを、更新を含めて識別するために必要な最低限の項目が必須になっていることが分かります。一方、脆弱性情報そのものについては、詳細情報はもちろん要約も必須項目ではありません。

　また、必須項目ではないですが、以下の項目にも注目する必要があります。

• Document Summary
  文書の簡潔な要約。理想的には読み手が以下のうちのどちらか一方のアクションが取れるような内容が望ましいとされています。
  
  
  
  • これ以上の対応が不要であると結論付けられる、または結論付ける前に詳細情報まで読む必要があるかを判断できる。
    
    
  • 詳細情報をスキップして対策情報（ベンダによる修正、軽減策、回避策）に進む。
    
    
• Document Distribution
  文書の再配布、共有、複製などに関する制約条件。

　ところで、脆弱性情報のXMLベースの記述形式としてセキュリティ検査言語OVAL（Open Vulnerability and Assessment Language）というものがすでに存在しています。

　OVALとは、システムにソフトウェアの脆弱性や設定上の問題が存在しているかどうかを検査するツールが参照する脆弱性情報データを記述するための言語です。実際にOVALを用いた検査ツールとしては、IPAが提供している「MyJVNバージョンチェッカ」があります。

■URL
　MyJVN バージョンチェッカ
　http://jvndb.jvn.jp/apis/myjvn/index.html#VCCHECK
　脆弱性やセキュリティ設定をチェックする「OVAL（Open Vulnerability and Assessment Language）」～MyJVNバージョンチェッカの裏側～（PDF）
　http://www.ipa.go.jp/security/vuln/documents/201008_scap_04.pdf

　このようにOVALとCVRFは脆弱性情報を記述するという点で共通する部分がありますが、OVALはあくまで脆弱性検査ツールが参照する定義データを記述するための言語であり、セキュリティアドバイザリのような文書を作成することを目的としてはいません。ここが、主に文書を作成することを目的としているCVRFとの根本的な違いです。

　一方、現在のCVRF v1.0はOVALをサポートしていませんが、CVRF文書は任意の外部データを参照できるのでOVALで記述された定義データが参照可能な状態であれば結び付けることは可能です。

　しかし、CVRF文書からOVAL定義データを自動的に生成するのは（現時点では）難しいと思われます。CVRF v1.0では脆弱性のあるバージョンや修正済みバージョンに関する記述が自由形式であるため、そこからOVAL定義データを生成するには人が目で見て判断する必要があるからです。ただ、CVRFは将来的にOVALをサポートする計画があるそうなので、そうなればCVRF文書からOVAL定義ファイルを自動生成することも可能になると期待されます。

　さて、実際にセキュリティアドバイザリなどを某CSIRTで書いていた経験のある者としての意見を述べさせていただきますと、今回発表されたCVRF v1.0は「なかなか良い」と感じました。

　IODEFをベースにしていると聞いたときは、その出来に甚だ疑問を感じていたのですが、実際に出来上がったものを見ると、予想以上にシンプルで分かりやすいものになっていて感心したくらいです。少なくとも（当然ですが）致命的に「足りない」ものはありません。複数の脆弱性を単一の文書で紹介することもできますし、ほとんどの脆弱性情報はこの形式で十分に記述できると思います。特に各ベンダーが公開する自社製品の脆弱性情報であればまず問題はないでしょう。

　しかし、やはり実際にCVRFで記述した例を見てみないことには正確な評価はできません。まず、CiscoやMicrosoftなどのICASIのメンバー企業には今後公開する脆弱性情報をこれまで通りの形式に加えて（一部で良いので）CVRFでも公開して欲しいです。

　CVRFについては今後も注目して行きたいと思います。