前回までは、脆弱性ハンドリングで何をするべきなのか、具体的にどのように作業を進めていけばいいのかを解説しました。実際にどのように運用していけばよいのか、すでにかなりのイメージをつかんでいただけているのではないでしょうか。しかし、実際にはこれまでにご紹介したフローに乗り切らないような例もあります。今回は、その“例外”の一例として、「OpenSSL」で発生した情報漏洩の脆弱性を取り上げます。
第2回と同様に、あなたはUNIX環境を含むサーバー群を監督するシステム管理者です。今回もどのように対応したらよいかを一緒に考えながらご覧ください。

出典1脆弱性情報:OpenSSLのheartbeat拡張に情報漏えいの脆弱性
項 目 | 内容 |
---|---|
脆弱性番号 | JVNDB-2014-001920 CVE-2014-0160 |
概要 | OpenSSLのheartbeat拡張の実装には、情報漏えいの脆弱性が存在します。TLSやDTLS通信において OpenSSLのコードを実行しているプロセスのメモリ内容が通信相手に漏えいする可能性があります。 |
CVSS基本値 | 5.0 |
影響を受けるシステム | OpenSSL 1.0.1から1.0.1fまで |
対策 | 開発者が提供する情報をもとに、最新版へアップデートしてください。 |
※この情報は、説明のため一部を改変・省略しています。
今度の脆弱性のタイトルは「OpenSSLのheartbeat拡張に情報漏洩の脆弱性」です。
この脆弱性は、関連情報が公開されたと同時に、一般メディアでも「heartbleed脆弱性」として大きな話題になった点も特徴的でした。もしかすると、そのようなニュース記事がこの脆弱性を知るきっかけになったのかもしれません。
まずは、いつものように「影響を受けるシステム」を確認して、資産リストに「OpenSSL」が含まれているかを確認してみます。すると、検索結果には1件も表示されず、この脆弱性は自社の資産には含まれていないようでした。ひとまず安心ですね。
しかし、本当にインストールされていないのでしょうか?

すると、実際には多くのサーバーでOpenSSLを使用しており、影響があることが判明します。
資産リストから発見されなかったのは、実際の資産状況に資産リストが追いついていないことが原因だったのです。いったいなぜ、そうなってしまったのでしょうか。
OpenSSLのようなライブラリ系のソフトウェアの場合、“ほかのソフトウェア(Apacheなど)に依存してインストールされる”ことが多いため、管理者自身がその存在を十分に意識することが難しい側面があります。そのため、ほかのソフトウェアをインストールした際、資産リストの登録から漏れてしまい、資産リストによる脆弱性チェックでは発見できない状態になっていました。
このような資産リストの“漏れ”は、次のようにさまざまな原因で発生してしまいます。
これまで、資産管理を脆弱性対策にも反映するためには、「資産リストが正確であることが前提」だと説明してきました。このように資産リストを信用しきれないとなると、困ってしまいます。いったい、どのように立ち向かえばよいのでしょうか。

まず、当然のことながら資産リストを正しく保つ努力をするべきです。ソフトウェアの新規インストールや更新など、状態が変わるタイミングを契機として確実にリストの更新を行わなければなりません。コンピューターの運用者自身が資産リストを更新する習慣を付けるなど、漏れを減らす工夫をしていく必要があるでしょう。とはいえ、すべてのソフトウェアを常に正確にチェックし、ミスなく“完ぺきな”資産リストを維持することは、現実的には非常に困難でしょう。
そこで、一定の契機で資産リストを見直す必要がでてきます。これは周期を決めて定期的に実施してもよいのですが、脆弱性への対応を迫られる可能性がある情報の公開をトリガーとしたほうが、より効率的です。具体的には、次のようなタイミングを考えます。
これらのタイミングで資産情報の再点検を行えば、脅威に対してオンタイムで対応することができるはずです。特に、世間で騒がれるような大きな脅威が発生したような場合には、資産の再チェックも含めた確認が必須であるといえます。
攻撃可能な糸口に関する情報である「脆弱性情報」に対して、市場で実際に発生している攻撃などの情報を「脅威情報」と呼びます。脅威情報は実際に攻撃にさらされる可能性が高いほど、重要度が増してくるといえます。脅威に関する情報を入手するには、JPCERT コーディネーションセンター(JPCERT/CC)などが発報している注意喚起情報を確認するのがよいでしょう。
また、新しいソフトウェアを見つけた場合には、忘れずに資産リストへ追加しておくことも重要です。次回から、このソフトウェアの脆弱性チェックを通常フローどおりに行うためです。ソフトウェアの脆弱性は、1つが発表されると、その後、続いて発表されることが多いという傾向にあります。そのため、すぐに資産リストへ追加することが、続いて発表される脆弱性情報に素早く対応できる体制を整えておくことにつながります。セキュリティ対策を進めると同時に、資産リストをどんどん育て、完ぺきな状態に近づけていきましょう。
(図1)
図1運用を回していくことで精度を上げていくことができる
自分の資産に「OpenSSL」が含まれているはずだと気付くことができたあなたは、資産リストからOpenSSLに関連しそうな「Apache HTTP Server」などのアプリケーションを含んでいるコンピューターをリストアップし、それらがOpenSSLを使用していないかを調査しました。その結果、多くの資産がこの脆弱性の影響を受けていることがわかり、通常の手順どおりに脆弱性対応を行いました。さらに、ほかの環境でもTLS関連ライブラリを調査し、使用しているライブラリで脆弱性が報告されていないかを確認しました。
このように、1つの脆弱性対応を進めながら全体にも目を通すことで、脆弱性に対するセキュリティを強化することができました。

まとめ
今回は、OpenSSLの脆弱性を例にとりながら、資産リストの漏れとそれを防ぐ運用手順の一例について紹介しました。資産リストを完ぺきに保つ努力も重要ですが、「資産リストは完ぺきではない」という意識も持って運用することで、脆弱性による脅威を逃さずに見つけることができるでしょう。
次回は、第1回から今回までの内容を振り返ります。