• 会員限定
  • 2013/06/26 掲載

加速する脆弱性対応事情、ベンダー・ユーザーの両面から妥当なスピード感を考える

連載:サイバーセキュリティ最前線

  • icon-mail
  • icon-print
  • icon-hatena
  • icon-line
  • icon-close-snsbtns
記事をお気に入りリストに登録することができます。
5月末、グーグルが尖鋭的な見解を発表しました。製品に脆弱性が存在し、かつ攻撃を受けていることが分かった場合、修正または回避策を “7日以内” に提示すべきであるというのです。これはグーグルが自社のみならず、ソフトウェアベンダー各社に対しても行われた呼びかけです。これまで同社では脆弱性対応の猶予期間を60日としていましたが、付帯条件付きながらこれが急激に短縮した、言い換えれば脆弱性対応が加速した形となります。本稿ではこの指標の妥当性について考察します。

NRIセキュアテクノロジーズ 高梨 素良

NRIセキュアテクノロジーズ 高梨 素良

早稲田大学大学院国際通信研究科卒業後、2007年に野村総合研究所に入社。NRIセキュアテクノロジーズに出向し、システムのセキュリティをチェックする「セキュリティ診断」サービスや、最新サイバーセキュリティ情報の調査・研究・情報提供を通じて数多くのプロジェクトに参画。

脆弱性情報:公開 vs 非公開

 本題に入る前に少々、前提知識として脆弱性情報の公開に対する現況をご説明します。脆弱性情報とは、どのようなソフトウェアの、どのようなバージョンに、どのような脆弱性があったかを示すものです。マイクロソフトの月例セキュリティ情報などは、ご覧になったことがある方も多いのではないでしょうか。


 この情報により当該ソフトウェアのユーザーは対応の要否を判断し、自身のシステム環境のリスクを把握できます。

 一方で、このような情報は攻撃者によるヒントにもなってしまいます。実際、このような公開情報を基に攻撃コードが形成されていると考えられるケースは多々あります。このため、脆弱性情報を公開するべきではない、または情報の詳細は伏せて結果としてのパッチだけを提供するべきだとする議論は根強くあります(もっとも、技術に明るい者が解析すれば、パッチから逆算して脆弱性を割り出すことも可能ですが…)。

 情報の公開/非公開の是非はどちらも相応の根拠があり、現況ではおよそのコンセンサスとして「情報公開はするが、なるべく攻撃のヒントにならないように配慮した形とする」という中庸的対応が一般的です。

脆弱性対応:ベンダー vs 攻撃者

 さて、脆弱性情報についてもう少し話を進めます。脆弱性がベンダー自身でなく第三者によって発見されることはままあります。それが、たとえば犯罪組織の人間など悪意ある者であれば、そのまま攻撃へと悪用されることでしょう。これがいわゆる「ゼロデイ攻撃」です。ゼロデイ攻撃はその時点では対応するパッチが存在しないため、対応が後手後手に回り、甚大な影響を及ぼす傾向にあります。

 一方で、発見者がセキュリティ研究者などの心ある者であれば、ベンダーに連絡を取り、パッチの作成など対応を促します。そしてパッチが公開されるまで、当該脆弱性情報は秘匿されます。なお、日本国内では調整機関としてIPA(独立行政法人 情報処理推進機構)、およびJPCERT/CC(一般社団法人JPCERTコーディネーションセンター)が存在し、発見者とベンダー間を取り持って対応支援を行っています。


 ここに難しいバランスがあります。ベンダーとしては脆弱性対応は必要だと感じつつも、直接売上/利益向上につながるものではないため、対応優先度が下げざるを得ず、早々には対応できないケースがあります。

 一方で、脆弱性発見者としてはあまりにベンダーの対応が遅い場合、攻撃者に先んじられるリスクがあるため、公益性の観点から止むを得ず脆弱性情報を公開するケースがあります。

 冒頭にグーグルが示した “7日間” という猶予期間はこのバランスを示す指標にあたります。なお、前述のIPAのサイトにも記載のある通り、脆弱性発見者に対して脆弱性情報の秘匿を強制することはできません。

“7日間”という指標の妥当性

 さて、それでは“7日間” という期間は妥当なのでしょうか。確かにグーグルの主張するとおり、ゼロデイ攻撃の猛威は看過できないレベルにあり(グーグルはかつてゼロデイ攻撃であるオーロラ攻撃を受けているだけに説得力があります)、理想としては1日でも早い対応が望まれるのはもっともです。しかし、現実的な期間でなければ絵に描いた餅で終わってしまいます。

 SANS InstituteのPescatore氏が本件に関してコメントを寄せていますが、彼は猶予期間に制限を付けることには賛成としつつも、たとえば組込機器や、ICS(産業制御システム)での対応において7日間は短すぎる、30日間程度が妥当であろう、という見解を述べています。

 筆者も同見解で、加えて述べれば日本で主流であるウォーターフォール型開発体制を想定するに、開発工程下流(実装工程など)で作りこまれた脆弱性ならまだしも、上流工程(設計工程など)の脆弱性が報告された場合、手戻りによる手間や、修正によるサービス/業務への影響考慮があるため比較的対応困難であり、7日間での対応はかなり厳しいと考えます。

【次ページ】ユーザー企業にも大きな課題

関連タグ

関連コンテンツ

あなたの投稿

    PR

    PR

    PR

処理に失敗しました

人気のタグ

投稿したコメントを
削除しますか?

あなたの投稿コメント編集

機能制限のお知らせ

現在、コメントの違反報告があったため一部機能が利用できなくなっています。

そのため、この機能はご利用いただけません。
詳しくはこちらにお問い合わせください。

通報

このコメントについて、
問題の詳細をお知らせください。

ビジネス+ITルール違反についてはこちらをご覧ください。

通報

報告が完了しました

コメントを投稿することにより自身の基本情報
本メディアサイトに公開されます

必要な会員情報が不足しています。

必要な会員情報をすべてご登録いただくまでは、以下のサービスがご利用いただけません。

  • 記事閲覧数の制限なし

  • [お気に入り]ボタンでの記事取り置き

  • タグフォロー

  • おすすめコンテンツの表示

詳細情報を入力して
会員限定機能を使いこなしましょう!

詳細はこちら 詳細情報の入力へ進む
報告が完了しました

」さんのブロックを解除しますか?

ブロックを解除するとお互いにフォローすることができるようになります。

ブロック

さんはあなたをフォローしたりあなたのコメントにいいねできなくなります。また、さんからの通知は表示されなくなります。

さんをブロックしますか?

ブロック

ブロックが完了しました

ブロック解除

ブロック解除が完了しました

機能制限のお知らせ

現在、コメントの違反報告があったため一部機能が利用できなくなっています。

そのため、この機能はご利用いただけません。
詳しくはこちらにお問い合わせください。

ユーザーをフォローすることにより自身の基本情報
お相手に公開されます