すると、実際には多くのサーバーでOpenSSLを使用しており、影響があることが判明します。

資産リストから発見されなかったのは、実際の資産状況に資産リストが追いついていないことが原因だったのです。いったいなぜ、そうなってしまったのでしょうか。

OpenSSLのようなライブラリ系のソフトウェアの場合、“ほかのソフトウェア（Apacheなど）に依存してインストールされる”ことが多いため、管理者自身がその存在を十分に意識することが難しい側面があります。そのため、ほかのソフトウェアをインストールした際、資産リストの登録から漏れてしまい、資産リストによる脆弱性チェックでは発見できない状態になっていました。

このような資産リストの“漏れ”は、次のようにさまざまな原因で発生してしまいます。

これまで、資産管理を脆弱性対策にも反映するためには、「資産リストが正確であることが前提」だと説明してきました。このように資産リストを信用しきれないとなると、困ってしまいます。いったい、どのように立ち向かえばよいのでしょうか。

まず、当然のことながら資産リストを正しく保つ努力をするべきです。ソフトウェアの新規インストールや更新など、状態が変わるタイミングを契機として確実にリストの更新を行わなければなりません。コンピューターの運用者自身が資産リストを更新する習慣を付けるなど、漏れを減らす工夫をしていく必要があるでしょう。とはいえ、すべてのソフトウェアを常に正確にチェックし、ミスなく“完ぺきな”資産リストを維持することは、現実的には非常に困難でしょう。

そこで、一定の契機で資産リストを見直す必要がでてきます。これは周期を決めて定期的に実施してもよいのですが、脆弱性への対応を迫られる可能性がある情報の公開をトリガーとしたほうが、より効率的です。具体的には、次のようなタイミングを考えます。

これらのタイミングで資産情報の再点検を行えば、脅威に対してオンタイムで対応することができるはずです。特に、世間で騒がれるような大きな脅威が発生したような場合には、資産の再チェックも含めた確認が必須であるといえます。

また、新しいソフトウェアを見つけた場合には、忘れずに資産リストへ追加しておくことも重要です。次回から、このソフトウェアの脆弱性チェックを通常フローどおりに行うためです。ソフトウェアの脆弱性は、1つが発表されると、その後、続いて発表されることが多いという傾向にあります。そのため、すぐに資産リストへ追加することが、続いて発表される脆弱性情報に素早く対応できる体制を整えておくことにつながります。セキュリティ対策を進めると同時に、資産リストをどんどん育て、完ぺきな状態に近づけていきましょう。
（図１）

図１運用を回していくことで精度を上げていくことができる

自分の資産に「OpenSSL」が含まれているはずだと気付くことができたあなたは、資産リストからOpenSSLに関連しそうな「Apache HTTP Server」などのアプリケーションを含んでいるコンピューターをリストアップし、それらがOpenSSLを使用していないかを調査しました。その結果、多くの資産がこの脆弱性の影響を受けていることがわかり、通常の手順どおりに脆弱性対応を行いました。さらに、ほかの環境でもTLS関連ライブラリを調査し、使用しているライブラリで脆弱性が報告されていないかを確認しました。

このように、1つの脆弱性対応を進めながら全体にも目を通すことで、脆弱性に対するセキュリティを強化することができました。

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

次回は、第1回から今回までの内容を振り返ります。