0
会員になると、いいね!でマイページに保存できます。
5月末、グーグルが尖鋭的な見解を発表しました。製品に脆弱性が存在し、かつ攻撃を受けていることが分かった場合、修正または回避策を “7日以内” に提示すべきであるというのです。これはグーグルが自社のみならず、ソフトウェアベンダー各社に対しても行われた呼びかけです。これまで同社では脆弱性対応の猶予期間を60日としていましたが、付帯条件付きながらこれが急激に短縮した、言い換えれば脆弱性対応が加速した形となります。本稿ではこの指標の妥当性について考察します。
脆弱性情報:公開 vs 非公開
本題に入る前に少々、前提知識として脆弱性情報の公開に対する現況をご説明します。脆弱性情報とは、どのようなソフトウェアの、どのようなバージョンに、どのような脆弱性があったかを示すものです。マイクロソフトの月例セキュリティ情報などは、ご覧になったことがある方も多いのではないでしょうか。
この情報により当該ソフトウェアのユーザーは対応の要否を判断し、自身のシステム環境のリスクを把握できます。
一方で、このような情報は攻撃者によるヒントにもなってしまいます。実際、このような公開情報を基に攻撃コードが形成されていると考えられるケースは多々あります。このため、脆弱性情報を公開するべきではない、または情報の詳細は伏せて結果としてのパッチだけを提供するべきだとする議論は根強くあります(もっとも、技術に明るい者が解析すれば、パッチから逆算して脆弱性を割り出すことも可能ですが…)。
情報の公開/非公開の是非はどちらも相応の根拠があり、現況ではおよそのコンセンサスとして「情報公開はするが、なるべく攻撃のヒントにならないように配慮した形とする」という中庸的対応が一般的です。
脆弱性対応:ベンダー vs 攻撃者
さて、脆弱性情報についてもう少し話を進めます。脆弱性がベンダー自身でなく第三者によって発見されることはままあります。それが、たとえば犯罪組織の人間など悪意ある者であれば、そのまま攻撃へと悪用されることでしょう。これがいわゆる「ゼロデイ攻撃」です。ゼロデイ攻撃はその時点では対応するパッチが存在しないため、対応が後手後手に回り、甚大な影響を及ぼす傾向にあります。
一方で、発見者がセキュリティ研究者などの心ある者であれば、ベンダーに連絡を取り、パッチの作成など対応を促します。そしてパッチが公開されるまで、当該脆弱性情報は秘匿されます。なお、日本国内では調整機関としてIPA(独立行政法人 情報処理推進機構)、およびJPCERT/CC(一般社団法人JPCERTコーディネーションセンター)が存在し、発見者とベンダー間を取り持って対応支援を行っています。
ここに難しいバランスがあります。ベンダーとしては脆弱性対応は必要だと感じつつも、直接売上/利益向上につながるものではないため、対応優先度が下げざるを得ず、早々には対応できないケースがあります。
一方で、脆弱性発見者としてはあまりにベンダーの対応が遅い場合、攻撃者に先んじられるリスクがあるため、公益性の観点から止むを得ず脆弱性情報を公開するケースがあります。
冒頭にグーグルが示した “7日間” という猶予期間はこのバランスを示す指標にあたります。なお、前述のIPAのサイトにも記載のある通り、脆弱性発見者に対して脆弱性情報の秘匿を強制することはできません。
“7日間”という指標の妥当性
さて、それでは“7日間” という期間は妥当なのでしょうか。確かにグーグルの主張するとおり、ゼロデイ攻撃の猛威は看過できないレベルにあり(グーグルはかつてゼロデイ攻撃である
オーロラ攻撃を受けているだけに説得力があります)、理想としては1日でも早い対応が望まれるのはもっともです。しかし、現実的な期間でなければ絵に描いた餅で終わってしまいます。
SANS InstituteのPescatore氏が本件に関してコメントを寄せていますが、彼は猶予期間に制限を付けることには賛成としつつも、たとえば組込機器や、ICS(産業制御システム)での対応において7日間は短すぎる、30日間程度が妥当であろう、という見解を述べています。
筆者も同見解で、加えて述べれば日本で主流であるウォーターフォール型開発体制を想定するに、開発工程下流(実装工程など)で作りこまれた脆弱性ならまだしも、上流工程(設計工程など)の脆弱性が報告された場合、手戻りによる手間や、修正によるサービス/業務への影響考慮があるため比較的対応困難であり、7日間での対応はかなり厳しいと考えます。
【次ページ】ユーザー企業にも大きな課題
関連タグ