セキュリティの脆弱性の定義

2014 年 2 月 19 日

読了までの所要時間: 7 分

セキュリティの脆弱性とは何でしょうか。ほとんどの人は、これは簡単な質問だと思っていますが、実際にはそうではないことが分かっています。この記事では、Microsoft Security Response Center (MSRC) で日々調査されているさまざまな課題を分類するために使用されている定義について解説します。

用語の意味を議論するために数ページを割く価値がある理由は、最初は明確ではないかもしれません。究極のところ、「セキュリティ」と「脆弱性」の両方を辞書で調べれば、それが何を意味するのかを合理的に理解することが可能です。これによると、セキュリティの脆弱性とは、マルウェア、正しく設定されていないシステム、付箋紙に書かれたパスワードなどのようなものを含む、システムに対して攻撃を行うための潜在的な手段を提供しているものである、と結論付けることができるでしょう。確かに、このような問題がある場合、システムのリスクが高まるのは事実です。しかし、これはセキュリティ コミュニティ内で一般的に使われているもの、また Microsoft が MSRC 内で問題を評価する際にも使われているものよりも、やや広い意味合いになっています。

ソフトウェア セキュリティ業界や MSRC で使用されている文脈では、脆弱性とは、製品開発者が意図して導入したものではない製品の弱点に起因するセキュリティ上の暴露であり、発見された時点で修正すべきものです。これにより、この用語は MSRC にとって特別な関連性を持つようになります。MSRC の仕事は、Microsoft 製品に存在する弱点を常に発見し、それらを修正することです。定義に関するこの議論は、起こり得る可能性のある、また修正すべき問題を特定するのに役立ちます。この記事は、一般的にセキュリティ情報ではどのような種類の問題が扱われているかを理解するのに役立ちます。

定義を文脈でとらえる

重要なのは、定義とは、問題がセキュリティ情報の根拠となるかどうかについて最終的な結論を下すものではなく、始まりの言葉である、ということを理解することです。MSRC は、セキュリティ上の問題が発生する可能性があるとの報告を受けるたびに、調査を開始します。再現可能な問題であれば、セキュリティ情報が必要かどうかを判断するために、以下の 2 つの質問が尋ねられます。

問題はセキュリティの脆弱性の定義を満たしていますか?

それは、製品のセキュリティ ポリシーに違反していますか、つまり製品の「セキュリティの境界」を突破していますか?

セキュリティの脆弱性の定義は、すべての問題に適用される初期のフィルターであると考えてください。特定のセキュリティ上の問題がセキュリティの脆弱性の定義を満たしていない場合、それがセキュリティ情報の根拠となることはほとんどありません。だからといって、何もアクションが起こされないわけではありません。たとえば、調査の結果、バグはあるがセキュリティの脆弱性はないことが判明した場合、MSRC は製品チームと協力してその修正を行います。ただし、修正プログラムはセキュリティ更新プログラムやセキュリティ情報ではなく、Service Pack や将来の製品バージョンの一部として提供されることになります。

問題が脆弱性の定義を満たしている場合、次の質問は、それが製品のセキュリティ境界に違反しているかどうかです。どの製品にも、それがどのように使われるかの一連の前提条件と、適切に使用されているときに提供されるセキュリティについての一連の約束事があります。たとえば、ユーザー アクセス制御 (UAC) は Windows Vista で導入されたテクノロジで、標準的なユーザー権限とタスクを、管理者アクセスを必要とするものから分離する方法を提供しています。標準ユーザーがシステムを使用していて、そのユーザーが認可されていないアクションを実行しようとすると、Windows からのプロンプトが表示され、管理者アカウントのパスワードが求められます。管理者がシステムを使用していて、同じタスクを行おうとすると、警告のプロンプトが表示されるだけです。そのプロンプトは「同意プロンプト」と呼ばれています。これは、管理者がそのアクションに同意してからでなければ次に進めないからです。「同意プロンプト」を迂回できるような弱点はセキュリティ上の境界とはみなされないため、セキュリティの脆弱性とはみなされません。

細則

脆弱性の定義を議論する前の最後のポイントは、脆弱性の定義は法的文書として意図されたものではないということです。その策定の主な目的は、シンプルでわかりやすいものにすることでした。しかしそれによって、あいまいな部分が存在することにもなりました。その結果、いくつかの免責事項があります。

この定義は保証ではありません。MSRC がセキュリティ更新プログラムで問題に対処すべきかどうかを評価できるようにするためのツールです。最終的には、どの問題をセキュリティ情報の根拠とするかの決定は、お客様に最高の保護を提供するかどうかに基づき、Microsoft の主観的な判断において行われます。厳密には、定義外の問題のためにセキュリティ情報が作成されることもあります。同様に、特定の問題が厳密な定義を満たしていても、稀な状況下でしか発生しないことも考えられます。その場合、より広範でより影響がある他の問題にリソースを集中した方が、お客様により良いサービスを提供することができるかもしれません。

定義は Microsoft の会社の標準ではありません。これは、MSRC が作業の優先順位を決めるために使用する非公式な定義です。ロゴの要件でもなければ、他の会社標準の一部でもありません。

定義

セキュリティの脆弱性とは、攻撃者が製品の整合性、可用性、機密性を侵害することを可能にする製品内の弱点のことです。

では、その定義が意味することを正確に紐解いてみましょう。この後の議論では、定義から重要な語句や単語を列挙し、正確に定義し、そして定義を実際の事例にどのように適用できるかを例示しながら説明していきます。

... 製品の弱点...

弱点: セキュリティの脆弱性には、不注意な弱点が含まれています。設計上の弱点が製品で発生することもありますが、これはセキュリティの脆弱性ではありません。

例:40 ビット暗号を製品内に実装するという選択は、それによって提供される保護が一部の目的に対しては不十分であったとしても、セキュリティの脆弱性を構成するものではありません。これに対して、実装エラーにより意図せずに 256 ビット暗号によりキーの半分のビットが破棄されてしまった場合は、セキュリティの脆弱性となります。

製品:セキュリティの脆弱性は、製品に問題がある場合に発生します。不完全ではあるが広く受け入れられている基準に準拠した結果生じる問題は、セキュリティの脆弱性ではありません。

例:FTP の仕様ではプレーンテキストのセッションを呼び出すため、FTP サイトに接続する際にプレーンテキストでセッションを実行するブラウザーについては、セキュリティの脆弱性があるとは考えられません。しかし、ブラウザーがプレーンテキストで SSL セッションを実行した場合、SSL の仕様では暗号化されたセッションが呼び出されるため、これはセキュリティの脆弱性となります。

... 攻撃者により整合性が侵害される可能性がある...

整合性: 整合性とは、リソースの信頼性を意味します。製品の弱点を突いて、無認可で音もなく製品を改変する攻撃者は、その製品の整合性を侵害しています。

例:管理者がシステム上の任意のファイルのアクセス許可を変更できるようになる弱点は、管理者がすでにこの機能を持っているため、セキュリティの脆弱性にはなりません。これに対して、特権を持たないユーザーが同じことをできるようになる弱点は、セキュリティの脆弱性を構成することになります。

...可用性...

可用性:可用性とは、リソースにアクセスできる可能性のことです。製品の弱点を突いて、適切なユーザーのアクセスを拒否する攻撃者は、その製品の可用性を侵害していることになります。

例:攻撃者がサーバーに障害を起こせるようにする弱点は、サーバーがサービスを提供しているかどうかを攻撃者が制御することができるため、セキュリティ上の脆弱性となります。しかし、攻撃者が大量の正当な要求をサーバーに送り、そのリソースを独占することができるという事実は、サーバーの運用者が引き続きコンピューターを制御できる限り、セキュリティの脆弱性を構成するものではありません。

...機密性…

機密性: 機密性とは、リソース上の情報へのアクセスを、許可された人々に制限することを意味します。製品の弱点を突いて非公開情報にアクセスする攻撃者は、その製品の機密性を侵害しています。

例:閲覧者が読んではいけないファイルを読むことができる Web サイトの弱点は、セキュリティの脆弱性を構成します。しかし、ファイルの物理的な位置を明らかにする弱点は脆弱性を構成しません。そのような弱点は偵察の目的に役立ち、また善良な脆弱性と組み合わせてファイルを侵害するのに使用することができますが、それ自体により攻撃者がデータを侵害できるようになるわけではないため、セキュリティの脆弱性を構成しません。(とはいえ、Microsoft は時折、このような場合にパッチを開発していることは念頭においてください)。

ご覧のように、整合性、可用性、機密性はセキュリティの 3 つの主要な目標です。この 3 つの要素のうち 1 つでも欠けている場合は、セキュリティの脆弱性があります。1 つのセキュリティの脆弱性が、これらの要素の 1 つまたはすべてを同時に侵害する可能性があります。たとえば、情報漏えいの脆弱性は製品の機密性を侵害し、一方でリモート コード実行の脆弱性は製品の整合性、可用性、機密性を侵害します。

実践での定義

お気づきのように、定義の判断にはかなりの幅があります。一般常識やお客様を守りたいという気持ちに加えて、Microsoft は長年の実践的なセキュリティの判断力で潜在的な脆弱性を評価していますが、セキュリティ情報の一覧をざっと見てみると、かなり広範な解釈が適用されていることがわかります。Microsoft 製品にセキュリティの脆弱性を発見したかもしれないと思われる場合は、Microsoft Security Response Center に報告し、ただちに調査を受けてください。お客様は、セキュリティ上の脆弱性の定義を満たしているかどうかの回答を受け取ります。