セキュリティ管理 ‐ 2005 年 5 月
オペレーションのセキュリティ : 第 3 回 （全 4 回）数時間で利用可能となる修正
私はマイクロソフトでの業務のうち、OS のセキュリティ、お客様からのフィードバック、対策の評価指標およびこれらを交えた部分の分析に多くの時間を費やしてきました。私が感じていることの一つに、セキュリティの理論上の考えとお客様の実際のセキュリティ上の懸念には非常に大きなギャップが存在する、ということがあります。このコラムは、4 回シリーズの第 3 回目です。私は、このシリーズを通じて、このようなお客様が懸念されている内容を考察し、マイクロソフトの Windowsオペレーティング システムもしくは Linux ベースのオペレーティング システムのいずれかを導入することに関して、検討いただくための問題を提起します。
先月、Steven Suehring 氏のコラムである “An Approach That Works:Comparing Open and Closed Source Security.” を読んでいました。コラム全体の流れには少々強引さがありましたが、そのまま読み続けました。それは、次の文章に目を引かれたからです。
セキュリティ更新プログラムが提供される2つのタイミングを見ると、ぞれぞれのモデルがどのようにセキュリティに取り組んでいるか、その違いがよく分かる。オープンソースのセキュリティのひとつの側面は透過性である。−事実上、理論的または実用的なセキュリティの問題が報告されるとすぐに一般に公開されるので、ソフトウェアのユーザーはセキュリティの問題の影響を軽減するために対策をとることができる。すべての人気のあるオープンソースソフトウェアパッケージですぐに更新プログラムが提供される。もし、更新プログラムが数時間内に利用できなければ、コミュニティは中間更新プログラムを発表しようと試みることがよくあり、問題を軽減するために手助けをしようとする。
まずはじめに、セキュリティ更新プログラムの提供方法を 2 つのモデルに分けて考えると興味深い、という Steven の意見に賛成です。しかし、彼は重要な 2 点に言及しています。ひとつは黙示的に、ひとつは明示的に言及しています。この 2 点は少しばかり注意深く検証されなければなりません。
1. | 「更新プログラムがすぐに提供される…」。「すぐ」に対して時間的境界が設定されていません。しかし文脈からすると、オープン ソース モデルの更新プログラムの方がマイクロソフト （クローズド ソース） より早く利用できることを意味しているのは確かです。 |
2. | 「もし更新プログラムが数時間内に利用できなければ、コミュニティは…」。つまり、更新プログラムが迅速に配布されなければ、コミュニティによる更新プログラムをユーザーが利用できるだろうということです。 |
私は質問したがる性質なのです。Linux ディストリビューションは、本当に更新プログラムをクローズド ソースより迅速に作成しているのでしょうか?1 つの例は挙げられると思いますが、概して更新プログラム全体にそうだと言えるのでしょうか?もしそうでなければ、コミュニティが私のために更新プログラムを作成してくれるのでしょうか?昨年、いくつ作成されたのでしょうか?どこから入手できるのでしょうか?それは私のコンピュータに悪影響を与えるのでしょうか?これらの問いかけは気まぐれで言っているのではありません。このような質問は、更新プログラムの提供元がベンダーの場合であれ、ベンダー以外の場合であれ、システムの管理者が問いかけであろう質問です。
公開された脆弱性に対する最速の更新プログラム
私は、Linux ディストリビューションが更新プログラムをより早く提供するという、暗にオープンソースの方がクローズドソースよりも対応が早いという最初の発言に関して、長く時間を費やすつもりはありません。これをより深く検証した確固たる研究結果があります。その研究によれば、一般的な認識に反してマイクロソフト セキュリティ レスポンス センター (MSRC) は、公開された問題に対する更新プログラムを主要な Linux のディストリビューションよりも早くユーザーに提供しているということです。
2004 年 3 月、Forrester が、マイクロソフトと主要な Linux のディストリビューションについて、単独かつスポンサー無しで研究を行い、結果を発表しました。(ここからダウンロードできます) 一年に及ぶ全脆弱性の分析結果は、マイクロソフトが平均 25 日で更新プログラムを提供するのに対し、次点の Linux のディストリビューション、Red Hatは、平均 57 日で更新プログラムを作成していました。謝辞に示されているように、このデータは各ベンダーによって確認済みです。 「今回の調査に当たり、Debian のノア・マイアハンス氏、MandrakeSoft のビンセント・ダネン氏、Microsoft のアレン・ジョーンズ氏、Red Hat のマーク・コックス氏、SUSE のローマン・ドラトミューラー氏には、貴重な時間を割いて惜しみない協力を賜った。フォレスターを代表して感謝の意を表したい。」
2005年 3 月、Security Innovation LLC は追跡調査を行いました。(ここからダウンロードできます) その調査では、フル装備の Windows Server 2003 コンポーネント一式と、Red Hat Enterprise Linux 3 Advanced Server を使用した最小の LAMP Web サーバーの比較を行いました。これは、2004 年の脆弱性に関する調査であり、製品とコンポーネントの更新プログラムの提供に関して、Linux のディストリビューションが平均で 2 倍の時間がかかっていることが再び確認されました。
では、コミュニティが提供する「数時間内の更新プログラム」はどうなのか?
過去を振り返って情報収集してみますと、マスコミやニュースに多く問題が取り上げられると、コミュニティ更新プログラムが開発され公開される結果になるようです。公開された問題に対しては、Linux のディストリビューション ベンダーが最速で更新プログラムを提供する傾向があり、コミュニティ更新プログラムが有益であるかどうかは疑問であると思われます。この点を念頭において、具体的な問題を見てみましょう。
ディストリビューションの更新プログラム提供の遅れおよび見落としの問題
もし、Linux ディストリビューションが脆弱性を迅速に修正するならば、コミュニティの更新プログラムはそれほど必要にはなりません。それならば、ディストリビューションが修正するのに時間がかかる脆弱性についてはどうなのでしょうか?
Red Hat の Mark Cox 氏が自身のブログで Red Hat Enerprise Linux 3 (rhel3as) で修正された脆弱性に関するデータを提供しています。http://people.redhat.com/mjc/
(英語情報) で利用可能です。このデータによると、修正に最長時間を要した脆弱性は、リモートからでも悪用することが可能であり、ICAT によって最も高い深刻度が付けられたものです。(詳細についてはこちらをご覧ください。)CAN-2002-1363, CAN-2004-0409, CAN-2004-0836, および CAN-2004-0419 – (英語情報) 少なくともこの 4 つは公開されてから Red Hat が更新プログラムをリリースするまでに 138 日間を要しています｡
CAN-2002-1363 は、rhel3as が出荷される前の 2002 年に公開されました。Debian や他のディストリビューションに含まれるによる libpng のに存在する問題脆弱性を修正するのための修正プログラム更新プログラムでした。このため、新しく rhel3as をセットアップしようとした場合、この問題が修正されたと見なすことができるでしょうか?rhel3as が出される前に公開されたすべての問題を調べ、それらの問題がすべて修正されているかソース コードを検証するのでしょうか？コミュニティ更新プログラムは利用可能でしたが、どのようにしてそれが必要だとわかるのでしょうか?
CAN-2004-0409 について。 もし、2004 年 4 月 4 日の xchat のディスカッションのエイリアスを購読していたならば、脆弱性があり、xchat.org Web site からソースの更新プログラムが利用できると通知を受けることができたでしょう。さもなければ、Debian からのアドバイザリを 4 月 21 日に見た時、もしくは Bugtraq のメーリング リストをモニターすることでこの問題を最初に知ったでしょう。もし、そのどちらも購読していなかったら、10 月に Red Hat からの更新プログラムに関するセキュリティ アドバイザリを受け取ったでしょう。
CAN-2004-0836. この mysql の問題は 6 月 4 日に公開されました。もし、mysql のメーリング リストを購読していたら、ソース コードの修正の通知を 6 月 17 日に受けていたでしょう。もしそうでなければ、Red Hat アドバイザリの、この問題に関する更新プログラムの報告を10 月に受け取っていたでしょう。
CAN-2004-0419. 5 月 19 日、この問題は修正コードと共に XFree86 のバグデータベースに公開されました。修正は簡単で、ソースツリーに関わっていたと見られます。もし、XFree86 のバグのデータベースを念入りに確認しなかったら、10 月の Red Hatの様に、ベンダーのアドバイザリから見つけていたでしょう。
この ４ つの問題のすべてが深刻度が高く、リモートでから悪用できるものでしたが、この問題が発見された時には、問題に関するの報道はされておらず、を主要なディストリビューションによって修正された時にしか問題は報道されませんでした｡以外に、どこにも見つけることができませんでした。これは次の質問へとつながります。
どのように管理者は、それを解明するか?
上で見た例をとっても、主要なベンダーがアドバイザリをリリースするまでは、IT 管理者は Bugtraq 上でさえ簡単にソフトウェアの脆弱性に気がつくことはなかったでしょう。コミュニティの更新プログラムがあったとしても、管理者がそれを知らず適用しなかったとしたら、何の利点があるのでしょうか?
攻撃者は、悪用できる可能性のある脆弱性を見つけるまで、いくつかの重大なコンポーネントを選択し、bugzilla や、ソースの変更および多岐に渡るソースをモニターします。公開された問題のほとんどに精通することは、問題の確認作業を日常の仕事として行っているか熱烈な趣味としているのなら、理論的には可能なことでしょう。しかし、システムを守る責任のある多くの IT の専門家にとっては現実的なこととは思えません。
その代わりに、IT の専門家が問題を認識するのは、Bugtraq、SecurityFocus、あるいはベンダーのアドバイザリからの通知によってであり、コミュニティ更新プログラムが必要ないと思われる段階のものさえあります。
ここでは、ディストリビューションの更新プログラムが提供される前に、コミュニティが開発した更新プログラムが利用可能となっていると仮定し、管理者がそれを知り、展開したいと想定してみましょう。
すべてのサーバーへどのように更新プログラムを展開するか?
Linux の企業顧客の多くは Red Hat あるいは SUSE のどちらかを使用していることが多いと考え、up2date あるいは yast を使用すると思われます。これらのツールの予想される使用方法は、ベンダーのサイトから許可された更新プログラムを取得し、コンピュータに展開することです。しかし、パッケージ ツールは管理者でも使用可能です。そのため、以下の操作を行うことが可能です:
1. | コミュニティ更新プログラムを適切なコードに適用して再コンパイルする。 |
2. | ソースから新規の RPM パッケージを作成し、ローカルの更新リポジトリに置く。 |
3. | 更新 / RPM の管理ツールを使用し、パッケージを削除する。 |
このような作業は、大企業の管理者としてはす頻繁に行いたいと思わないものですが、実行することは可能です。ただ、実現の可能性を示しはしましたが、依然としていくつかの管理者が考慮せざるをえない問題があります。1 つめはテストです。
品質およびテスト – このソースは信頼できるか?
もし、テストを無視してコミュニティの更新プログラムのロール アウトのみを行ったらどうなるでしょうか? マイク ハワード氏はコミュニティ更新プログラムのリスクに関する良い例をこのエントリー (英語情報) の彼のブログにあげています。 概要の中で、Apache 1.3 のバッファ オーバーフローは Bugtraq に公開され、コミュニティの更新プログラムは、使用する人のために直ちに掲載されました。 コミュニティの更新プログラムはバッファ オーバーフローを修正しました。しかしマイクはそれが新しいバッファ オーバーフローを生み出すことを発見したのです。
コミュニティの更新プログラムを運用環境で安全に使用するために、私たちは特別な責任とテストのリソースを持たなければならないようです。 この「コミュニティの更新プログラムによる利点」は、平均的な企業の管理者にとっては厄介なものになりそうです。 もし、企業が必要とする品質を確保するため、コードの先祖返りや互換性を発見するテストを行うための管理者のリソース、あるいは時間が足りないのであれば、ベンダーの更新プログラムを待つのが良いかもしれません。
だれが、コミュニティの更新プログラムをサポートするか?
Red Hatや SUSE のような業務用の Linux のエンタープライズ ディストリビューションは、すべてのコンポーネントのスナップショットをとり、数年間そのサポートを継続します。 Red Hat の諸条件は、これらのほとんどのコンポーネントのソースの変更を考慮しているようです。
しかし、実質的にはその変更がコードに反映され、ソースツリーが分岐された場合、ベンダーによりリリースされた「公式」な変更と競合しないと誰が保証してくれるのでしょうか?
カーネルの脆弱性 CAN-2004-1234 (英語情報) が悪用されるシナリオを見てみましょう。この問題は、修正のための変更案とともに、2004 年 4 月 8 日に公開されました。 仮に、Red Hat Enterprise Linux 3 Advance Server の管理者が変更を確認して、自分自身のコンピュータに適用することを決定したとします。管理者は必要なことを行います。カーネルを再コンパイルして、配布し、そして再起動します。 すばらしい! コミュニティの更新プログラムは、より改善されたセキュリティの助けになります。 しかし、その後何が起こり得るのでしょう?
2004 年 4 月 8 日から 12 月 23 日 (Red Hat が CAN-2004-1234 の修正をリリースした日) の間、Red Hat が発行したセキュリティ アドバイザリは、up2date とRed Hat Network の機能を介して提供され、28 件のカーネルの脆弱性を修正するものでした。 それぞれのアドバイザリのリリース時に、管理者は以下の判断をしなければなりませんでした。
| • | 最新の Red Hat のカーネル ソースをダウンロードして、それに更新プログラムを移し、手動ですべてをロールアウトするか? |
| • | up2date からの新しいバイナリの更新プログラムを使用して、CAN-2004-1234 を修正するために行った処理をすべてロール バックするか? |
このような例は、カーネルに関してだけでも、ほかにたくさんあります。 それは難しい決断ですが、実際には、ほとんどの管理者が最終的に、セキュリティと運用コストを考えた結果、一番のトレードオフとして「ベンダーが許可した」更新プログラムを取るのではないかと思います。
マイクロソフトが、テストを行っていない更新プログラムをリリースしたとしたら?
「数時間で利用可能となる修正」の利点を検証する別の方法は、マイクロソフトが同様のことを行ったらと想像してみることです。 開発者は、連絡を受けた脆弱性に対応した更新プログラムを完成させます。 更新プログラムがテスターに渡されるとすぐに、マイクロソフト セキュリティ レスポンス センター (MSRC) は、セキュリティ情報とともに、お客様のためにそれをダウンロードセンターなどに掲載します。そしてそれは個人の責任で使用することができます。セキュリティ情報は、その更新プログラムが先祖返り、あるいは互換性の試験をまだ行っていない段階であることをお客様に通知します。
理論的には、マイクロソフトにとっては、ほとんどのお客様が本当にこれを望み、リスクをとることを厭わないと思うのであれば、これは実現する事は可能です。 心に留めていただきたいのは、更新プログラムをともなうセキュリティ情報は、非常に幅広く提供されるものです。ですから、誰でも無試験の更新プログラムを展開する事は望んでいないでしょう。
これが、多くのお客様が切望しているプロセスのように思えるでしょうか? 経験上言えることは、お客様が望んでいることはこれとは正反対であるということです。
結論
ベンダーおよび製品を比較する場合に、価値と利益はあまりにも単純に「数時間内の更新プログラム」のような一言で捉えられることがよくあります。 サポートおよびライフサイクルの契約とともに企業に製品を提供しているすべての者にとって、セキュリティの更新プログラムの提供は初歩的な要件です。
しかしその先には、運用環境での展開において、企業が必要とする信頼できるソフトウェアの更新プログラムから生まれたセキュリティのリスクに対する実質的な意味があるのです。 オープン ソースのモデルを、ベンダーの許可した更新プログラムと配布のメカニズムが交わった「コミュニティの更新プログラム」の可用性という点で考えた場合に、その状況はセキュリティ リスク管理に対する真の挑戦と難しい選択を提示します。
このような相対的なセキュリティについてのディスカッションで、私は皆さま自身でこのトピックを検証し、皆さま自身の結論を導かれることをお勧めします。 皆さまの理解のために、いくつか参考事例をご紹介し、ソフトウェア ベンダーと話し合いを望まれる場合に備えて、考えられるケースをいくつか提供しました。
次回、このシリーズでは運用環境のために考えるべき実際のセキュリティ問題に関して説明しますのでご期待ください。
Best regards,
Jeffrey R. Jones
Director, Microsoft Security Business and Technology Unit
この記事は、マイクロソフト セキュリティ ニュースレターで配信しました。