このところ、オープンソース・ソフトウェアで問題が発見されたり、情報流出事件が発生するたびに「脆弱性」というワードを耳にします。しかし、残念ながら実務のなかでどのように「脆弱性」へ対処すればよいのかよく知られていないのではないでしょうか。
本連載では、これまでの3回で脆弱性の存在に立ち向かう方法(脆弱性ハンドリング)について、基本的な内容から実際の運用イメージまでを紹介してきました。連載のラストとなる今回は、これまでお伝えした内容から特に押さえていただきたいポイントについて振り返ります。
「脆弱性ハンドリング」について考える前に情報セキュリティにおける「脆弱性」という言葉の意味を思い出しましょう。情報流出や改ざんといった不正な操作を許してしまうソフトウェアの欠陥のことでした。クラッカー(攻撃者)はこの脆弱性を糸口として、システムに対してさまざまな攻撃を仕掛けてきます。
システムを運用する立場としては、この脅威となり得る脆弱性が、コンピューター(資産)に対してどの程度リスクを与えているのかを正しく把握するということが重要になります。そして、そのリスクの程度から対応要否を決定していきます。この一連のフローが「脆弱性ハンドリング」です。脆弱性ハンドリングは、特に次の3点を意識して行います。
資産内の脆弱性を把握するには、実際に攻撃を試してみることも一つの手段ですが、システムがハングアップするなどの危険性もあり、日常的に実施するには少々リスクが高いと言えます。そのため、日常的な脆弱性ハンドリングにおいては、資産管理ツールのデータを活用するという方法が有効です。資産管理ツールでは“どのコンピューターに”“どのソフトウェアが”インストールされているかが管理されていますから、脆弱性のあるソフトウェア情報さえ入手できれば、資産リストを検索することで脆弱性を含んだコンピューターをリストアップすることが可能です。
では、脆弱性ハンドリングの基本的なフローを振り返ります。まずは脆弱性が含まれたソフトウェアの情報を入手する必要があります。これは情報処理推進機構(IPA)などが運営している脆弱性情報データベースで公開されており、Webページを通じて入手することができます。脆弱性の性質や深刻度など、さまざまな情報がまとめられており、新しい脆弱性が発見されれば随時更新されます。(図1)
JVN iPedia 脆弱性対策情報データベースhttp://jvndb.jvn.jp/
項 目 | 意 味 |
---|---|
脆弱性番号 | 脆弱性に与えられる共通番号 |
概要 | 脆弱性がどのようなもので、どういう影響を与えるのかの概要説明 |
CVSS基本値 | CVSS基本値を用いた基本的なリスク評価 |
影響を受けるシステム | 影響を受けるソフトウェアの名前 |
対策 | 脆弱性に対する対策方法や、パッチへのリンクなど |
参考情報(link) | この脆弱性に関する解説などの外部リンク |
次に、この「影響を受けるシステム」の情報から、資産管理ツールで資産情報を検索し、対象のソフトウェアがインストールされているコンピューターをリストアップします。これがそのまま“脆弱性のあるコンピューターの一覧”ということになりますから、このリストを参考に脆弱性のリスクを評価しましょう。脆弱性のリスク評価では、「CVSSによる深刻度」の情報が便利です。各評価軸には第1回「CVSSによる深刻度の見方」のような意味があり、情報セキュリティ分野の専門家が検討した上で付加した値です。CVSSの基本スコアだけで深刻度を検討してもよいのですが、「CVSSによる深刻度」ではベクトルごとに評価されていますので、自分の環境(ネットワークにはつながっているのかなど)を加味しながら深刻度を把握することもできます。
ここでは、「Shellshock」のCVSS基本値を例に挙げます。(図2)のベクトルでは、スコアは10.0と評価されており、すべての影響区分に対し全面的に影響を及ぼす重大な脆弱性であることがわかります。一方で、攻撃元区分が「ネットワーク」となっているため、ローカルのみで運用しているコンピューターへの影響は限定的であると判断できるでしょう。
項 目 | 評 価 |
---|---|
スコア | 10.0 |
攻撃元区分 | ネットワーク |
攻撃条件の複雑さ | 低い |
攻撃前の認証要否 | 不要 |
項 目 | 評 価 |
---|---|
機密性への影響 | 全面的 |
完全性への影響 | 全面的 |
可用性への影響 | 全面的 |
最後に、リスク評価で対応が必要と判断した脆弱性に対して、対策を行います。脆弱性情報の「対策」や「参考情報」などを参照すれば、必要なパッチやアップデート、問題の緩和策を知ることができるでしょう。例えば「Shellshock」の脆弱性では、OpenSSLの公式パッチが対策として提供されていました。このパッチ情報は「対策」でリンクされており、パッケージ管理システムでの対応などについても確認することができました。
脆弱性ハンドリングのフローを維持するためには、資産リストを正確に保つことが重要です。このために、まずは日々の管理をしっかりと進めていかなければなりません。ところが、コンピューターには使っていることを意識できないライブラリなどの小さなソフトウェアも多数含まれているため、資産リストと実際の状態が異なる事態はとても簡単に発生し得ます。そのため、日々の管理に加えて、ある契機をもって資産リストの見直しが必要になります。例えば、次のような“対応に迫られる契機”でその脅威が自分の手元に存在しないか、再確認するとよいでしょう。
ここで新しいソフトウェアを見つけた場合には、忘れずに資産リストに追加して、通常の脆弱性ハンドリングに乗せるようにしましょう。あるソフトウェアについて脆弱性が一つ発表されると、その後続けて出てくる傾向がありますから、素早く対応できる体制を整えることにつながります。セキュリティ対策を進めていくと同時に、資産リストをどんどん育て、完ぺきな状態に近づけていきましょう。
4回にわたって、脆弱性についての基本的な知識から、脆弱性ハンドリングのフローや実際の運用イメージまでをご紹介してきました。特に実用的な知識をお伝えしましたので、運用にあたって最低限・基本的な部分はご理解いただけたのではないかと思います。本稿が皆さまの情報資産を守る一助になれば幸いです。