ニュース
2004/03/10 11:48 更新
皆で幸せになれる？ JPCERT/CCが脆弱性情報の適切なハンドリングを強化
JPCERT/CCは、米CERT/CCと協調しながら、ソフトウェアやハードウェアに存在する脆弱性とその修正策に関する情報を適切に公開していく枠組み作りを進めていく。
JPCERTコーディネーションセンター（JPCERT/CC）は、米CERT/CCと協調しながら、ソフトウェアやハードウェアに存在する脆弱性とその修正策に関する情報を適切に公開していく枠組み作りに取り組む方針だ。3月9日に都内にて開催された「脆弱性情報ハンドリングワークショップ」の中では、その目的と具体的なプロセスが紹介された。
JPCERT/CCやCERT/CCの取り組みにおいては、製品に存在する脆弱性情報を収集するだけでなく、「必要な人に、必要なタイミングで、必要な情報を公開すること」がポイントになる。ここで最も避けるべきは、脆弱性情報やそれを悪用した攻撃コードが一人歩きし、対処策もないままにユーザーが攻撃にさらされるような事態――いわゆるゼロデイ状態での攻撃――だ。CERT/CCやJPCERT/CCはそういった事態を防ぐため、問題の発見者およびベンダーと連絡を取り合いながら、問題の回避策を用意し、適切なタイミングでそれを公開するための調整を行っていく。文字通り「コーディネーションセンター」としての役割を果たすわけだ。
無論、発見者とベンダー、あるいはベンダーどうしの間でも、「脆弱性とは何か」「その脆弱性の深刻性はどの程度か」「適切な公開タイミングとはいつか」といった考え方には差があり、議論は絶えない。そもそも取り扱う脆弱性情報自体が微妙な性格を持っている。米CERT/CCではその中で、試行錯誤を重ねながら、脆弱性情報収集・公開のための枠組み作りに取り組んできたという。
CERT/CCの脆弱性情報ハンドリング体制においては、脆弱性を発見したベンダーや研究者は、まずその情報をCERT/CCに届け出る。CERT/CCでは情報を吟味した上で、この脆弱性の影響を受けるベンダーに連絡。ベンダー側は問題について詳しく調査し、影響度のほか修正（パッチなど）法とそれによる副作用などの情報をフィードバックする。脆弱性によっては、パッチなど修正策の準備に長い時間を要することもあるが、その場合、準備が完了するまで情報公開を繰り延べるよう両者の間で調整を行う。
CERT/CCはこれまでの取り組みを通じて、脆弱性情報のやり取りを行うためのパイプを600社以上の現場担当者との間に作り上げてきた。顔を付き合わせての本人確認を行うほか、暗号メールなどを用いて、センシティブな脆弱性情報を漏えいさせない仕組みを作り上げていると言う。
このような流れにより、少なくとも「対処策がないままユーザーが危険にさらされる」事態は避けられる、というわけだ（本当に悪意ある攻撃者が、CERT/CCによる調整活動が進んでいる間に独力で脆弱性を発見し、悪用し始める場合は残念ながらその限りではないが）。
前提として、安全なコーディングなどを通じて製品そのものの安全性を高めることが重要なのはもちろんだ。しかし、「完璧なソフトウェアを作るのは現実的には困難であるという点を認識すべきだ」（米CERT/CCの脆弱性情報ハンドリングチームマネージャ、ショーン・ハナン氏）。
「ベンダーは、まるで問題が存在しないような振りをするのではなく、適切に脆弱性情報を公開し、“問題にきちんと対応できるベンダー”として振舞うべきだ。そうすることによって、ユーザーは適切に問題に対応できるようになる」（ハナン氏）。
日本でも適切な脆弱性情報ハンドリングを
JPCERT/CCは、CERT/CCが進めてきた脆弱性情報ハンドリングの仕組みの中に加わることになる。「これまでJPCERT/CCが行ってきたのは、“インシデントハンドリング”という事後の対処を進めるためのシステムと、今インターネットで何が起きているかを把握する“定点観測”。これら2つに加えて脆弱性情報のハンドリングを行うことにより、コトが起きる前の予防が可能になる」（JPCERT/CC技術統括の水越一郎氏）。
これまで、日本のベンダーが提供する製品に脆弱性が発見されたとしても、言語の壁もあって、その情報を適切な人物に届けるだけで一苦労だった。JPCERT/CCはその窓口となり、必要に応じて詳細情報の提供などを行っていたが、その取り組みを強化。CERT/CCと同様のタイミングで詳細な情報を提供し、時差のない形でフィードバックやスケジューリングなどのとりまとめを行っていく。またNISCC（UNIRAS）との間でも同様に共同歩調を取り、脆弱性検証ツールの配布、調整などに取り組む方針だ。
ちなみに米国の場合、電力、水道をはじめとする重要インフラを受け持つ企業や組織に大しては、一般公開を行う前に情報を通知しているという。JPCERT/CCでも今後、同様の枠組みを検討していく方針だ。
まずは、「国内ベンダーになるべく広く展開していくことが重要」（水越氏）。まずは、一社での多くのベンダーの連絡先を募集し、脆弱性情報の伝達、コーディネーションを行える体制を整えていくという。国内で300〜500社をカバーすることが目標だ。
これを実現するには、ベンダーの側にも相応の体制が必要になる。CERT/CCおよびJPCERT/CCでは、「品質管理部門」「製品開発者」「法務・広報担当者」「製品デリバラー」を包括した、組織内の脆弱性ハンドリングチームが必要になるとも述べている。
最も大きな問題は、セキュリティや脆弱性に対する文化の違いになるかもしれない。「日本の企業で脆弱性情報の取り扱いに慣れているところは少ない」（ショーン氏）。これを踏まえ「JPCERT/CCでは、脆弱性ハンドリングや組織内の情報共有ポリシーのすり合わせなどをフォローアップしていきたい」（水越氏）という。
「今回の取り組みを通して、日本のベンダーも脆弱性に責任を持ち、脆弱性情報ハンドリングのプロセスに参加していただきたい。CERT/CCやJPCERT/CCはそれを支援していく」（ハナン氏）。
標準そのものに存在する脆弱性
こういった取り組みをの背景には、製品個別の問題だけでなく、標準そのものに存在する脆弱性が多く発見され、数多くの製品に影響が及ぶようになったことが挙げられる。「あるベンダーが製品の脆弱性を公開したとする。しかし、別の製品にも同様の脆弱性が存在した場合、対処策がないのだからユーザーのリスクはかえって高まることになる」（ハナン氏）。それを避けるために、標準化団体も含め、業界全体が協調してことに当たることが重要という。
事実、2002年のSNMPにはじまり、S/MIMEやH.323など、複数のベンダーにまたがって影響を及ぼす脆弱性が発見された。だがたとえば「H.323の脆弱性の場合、手元にあるベンダーのリストが少なく、（コーディネーションが）不十分だった」（水越氏）。国を越えてCSIRT（コンピュータセキュリティインシデントレスポンスチーム）どうしが連携することにより、影響がおよぶ製品を速やかに特定し、情報公開のタイミングを的確にコントロールできるようになるという。
ただ、Webアプリケーションの脆弱性をどう取り扱うべきかは、まだ結論が出ていない状態だ。Webアプリケーションを動かす「製品」レベルでの脆弱性についてはCERT/CCの枠組みに含まれることになるだろうが、設定、運用に起因するものについては、「IPAを中心に研究会を行っており、今月末には方向性が出る予定」（水越氏）という。
将来的には、家電製品や携帯電話などさまざまなデバイスに存在する脆弱性についても、同じように脆弱性情報のハンドリングが行えればという。「たとえばある携帯電話端末でウイルスの発生を許す脆弱性が発見されたならば、他のキャリアの携帯端末についても検証が必要になる。そういったときの情報共有に役立つのではないか」（水越氏）。
関連リンク
JPCERT/CCCERT/CC[高橋睦美，ITmedia]
Copyright © ITmedia, Inc. All Rights Reserved.
