パッチ火曜日の10年間：なぜ前進すべきなのか
クリストファー・バッド著
今月初め、マイクロソフトはセキュリティアップデートの定期リリース「Patch Tuesday」の10周年を迎えました。大々的な宣伝はなかったものの、この新しい定期リリースがマイクロソフトの顧客と業界全体のセキュリティ対策をいかに向上させたかについて、多くの反響がありました。ラリー・セルツァー氏とアンドリュー・ストームズ氏は、この10年間の世界情勢と、このプログラムがもたらした恩恵について、的確に捉えています。
私は10年間、Microsoft Security Response Center (MSRC) に所属し、その在職期間は Patch Tuesday プロセスと重なります。Patch Tuesday 以前から活動を始め、その構築に尽力し、長年にわたりその一部でした。私が Trustworthy Computing Memo 10周年を迎えた時のように、人々が Patch Tuesday の功績を振り返る中、私はこの機会に未来に目を向けたいと思います。Patch Tuesday は非常に良いものでしたが、私たちはそれを超越し、より新しく、より良いもの、つまり今日の脅威環境にもっと適したものへと進化していく必要があると考えています。10年後には、Patch Tuesday は過去のものになっているはずです。
すべてはこうして始まった
私の考えを理解するには、パッチ火曜日の始まりを思い出すと分かりやすいでしょう。パッチ火曜日以前は、誰もが「準備ができたら出荷」というモデルを採用していました。つまり、セキュリティ修正が完成したら出荷するのです。時には1日に複数回出荷することもありました。また、当時はCode Red、NIMDA、Blaster、Sasserといった、広範囲に及ぶ深刻な攻撃も多発していました。セキュリティ修正と攻撃が同時に発生し、ITマネージャーが朝起きたら「受信箱に手榴弾が届いている」ような状況が生まれていました。ある同僚の言葉を借りれば、この混沌とした状況には秩序が必要でした。しかし、Microsoftが「準備ができたら出荷」というモデルから脱却し始めると、人々を必要以上に攻撃に対して脆弱な状態に放置しているという批判が相次ぎました。パッチ火曜日のプロセスの歴史を通して、この問題は存在し続けてきました。ゼロデイ攻撃が発生し、「アウトオブバンド」リリースを求める声が上がるたびに、この問題は表面化します。このような状況では、構造化されたプロセスの利点と、脆弱性が攻撃にさらされる時間が長くなるという問題が衝突します。
定期的なパッチ火曜日のスケジュールを策定した際、待機に伴うリスクは認識していました。そして、私が在籍していた間ずっと（そして今も同僚たちがそうしているように）「アウトオブバンド」オプションでそのリスクを管理してきました。しかし、修正を遅らせるリスクがあったため、私たちの中には「パッチ火曜日」を最終段階ではなく、むしろ信頼構築のステップと捉える人もいました。配信スケジュールを標準化することで、将来、人々、特に企業がテストによってパッチの展開を抑制しなくなる日が来ることを期待していました。私たちが思い描いていた最終段階は、構造化されたプロセスがもたらすメリットと、従来の「準備完了時に出荷」モデルが提供していた保護のスピードを融合させたものでした。
今日の脅威環境を考えると、時間の問題はさらに深刻化しています。ゼロデイ攻撃は過去10年間で急増し、攻撃の速度と巧妙さも増しています。また、攻撃者は「パッチ火曜日/エクスプロイト水曜日」という定着したパターンからもわかるように、パッチ火曜日の固定された位置を逆手に取っています。「エクスプロイト水曜日」は、OracleやAdobeのように定期的なリリースを行っている他のベンダーにとって問題となっています。さらに、Oracleのリリーススケジュールは月次ではなく四半期ごとであるため、時間的な遅延や固定された位置の悪用といった問題はさらに深刻化し、パッチ展開の複雑さも大幅に増大しています。
念のため申し上げておきますが、これは以前の状態に戻れということではありません。企業間の情報共有と連携に関する重要な取り組みは、体系的なパッチチューズデーのプロセスを中心に育まれてきました。このプロセスは今後も継続されるべきであり、むしろ成長し続けるべきです。しかしながら、パッチチューズデーに付随するあらゆるメリットは、「準備ができたらリリース」というモデルに対応できるよう、適応力と機敏性を高める必要があります。
新しい世界への適応
一見すると、技術の進化に身を任せておく方が簡単そうに思えるかもしれません。デスクトップやサーバー以外では、モバイルデバイスやオンラインサービス上のアプリは既に「準備ができたら出荷」モデルで提供されており、当初からそうでした。マイクロソフトでさえ、Windows ストアで入手できる Windows 8 アプリでは「準備ができたら出荷」モデルを採用しています。特に、将来に向けてより適したモデルが、私たちが未来の鍵と捉えている技術に結びついているように見える場合、今のところは2つの異なる標準を受け入れるのは非常に魅力的です。
しかし、モバイルプラットフォームとオンラインサービスにそれぞれ異なる標準を採用するのは正しい答えではありません。現状のままでは、デスクトップとサーバーは許容できないほど長期間、より大きな攻撃リスクにさらされることになります。また、アプリとオンラインサービスのサービスモデルはスピードという利点があるものの、デスクトップとサーバーのセキュリティ対応プロセスを中心に進化してきたような、広範かつ階層化されたサポートが一般的に欠けています。また、モバイルデバイスとクラウドが台頭し、デスクトップとサーバーが完全に消滅すると考えるのも非現実的です。むしろ、これら2つのセキュリティサービスモデルを統合し、将来に向けた新たな業界ベストプラクティスを構築することが、最善かつ最も現実的な解決策です。
デスクトップとサーバーのセキュリティ対策における、誰もが認めるベストプラクティスの創始者であるマイクロソフトは、次世代のベストプラクティスをリードする絶好の立場にあります。モバイルデバイスやオンラインサービスのニーズへの適応において、マイクロソフトは優れた実績を上げてきました。しかし、かつてのように業界を牽引する存在ではありません。現在の環境では、単一のベンダーやプラットフォームが業界全体を牽引することは不可能です。進化を遂げるには、顧客とユーザーが現状のセキュリティ対策を甘んじるのではなく、より優れたセキュリティ対策を要求する必要があります。具体的には、より高品質なパッチ、改善された配信方法（再起動回数の削減を含む）、そして携帯電話のアプリを更新するのと同じように、安心してサーバーアプリケーションを更新するために必要なあらゆることを要求する必要があるのです。
これらの変化が実際に起こるかどうかは分かりません。顧客はこれまでセキュリティアップデートに関しては消極的であり、ベンダーは必要な対応をするまで何もしないのが通例です。この分野には「まあまあ」という惰性が多く存在します。10年前のマイクロソフトのように、単一の大企業が深刻な問題を抱えていないため、その状況を社会全体の利益のために活用できるという、他に類を見ない可能性が失われています。しかし、私のようにセキュリティに携わる立場にある者は、必要な時に声を上げることの重要性と必要性を認識し、最終的に人々が耳を傾けてくれることを期待します。私がMSRCに在籍していた頃、より定期的なプロセスの必要性を訴え始めた際に私たちはそれを実践し、最終的に世界はそれに従いました。今、私は再び同じことをしようとしています。今こそ前進し、Patch Tuesdayを、次の10年間の課題に対応できる、より迅速な新しいプロセスに置き換える時だと主張しているのです。
