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

  • [アーティクル]

* この資料は米国マイクロソフトの「Microsoft Security Response Center (MSRC)」が公開したセキュリティの脆弱性の定義に関する文書を翻訳したものです。

セキュリティの脆弱性とは何でしょうか？答この質問は簡単に思えるかも知れませんが、実際にはそうではありません。この文書では、私たちが日々調査しているさまざまな問題を分類するために、Microsoft Security Response Center (MSRC) が使用している脆弱性の定義について説明します。

セキュリティの脆弱性という言葉の意味を説明するのに、なぜ数ページも使用するのか、初めはわかりにくいかもしれません。結局のところ、辞書で「セキュリティ」および「脆弱性」という両方の言葉を辞書で調べてみると、冒頭の言葉の意味が理解できると思います。これにより、セキュリティの脆弱性とはマルウェア、不適切に構成されたシステム、付箋に書かれたパスワードなどを含む、システムに対する攻撃手段を提供するものすべてである、という結論に達するかもしれません。このような問題がシステムのリスクを増大させているのは事実です。しかしながら、今回紹介する定義というのは、MSRC 内で問題を診断する中で、セキュリティ コミュニティ内で一般に使用されるより幅広い意味合いを持ちます。

ソフトウェア セキュリティ業界、そして MSRC で使用される状況では、脆弱性とは、製品開発者が発覚させるつもりはなく、見つけ次第、すぐに修正されるべき製品の弱点が、結果としてセキュリティの危険にさらされることを意味します。このため、脆弱性という言い回しは、そのような脆弱性がマイクロソフト製品に存在した場合に、それを見つけ出し、そして修正するのが仕事である MSRC と特別な関係性が出てきます。ここで説明する定義は、修正可能且つ修正の必要がある問題を特定するのに役立ちます。この文書は、一般に、どのような種類の問題がセキュリティ情報で解決されているのか理解するのに役立ちます。

 

定義を状況に当てはめる

この定義は、問題が マイクロソフト セキュリティ情報 に掲載するのにふさわしいかどうかを最終的に判断する基準ではなく、最初の基準である、ということを理解することが重要です。セキュリティ問題の可能性があると MSRC に報告されると、調査が始まります。その問題が再現可能であれば、セキュリティ情報が必要かどうか判断を下すために、以下の 2 つの質問がされます。

  • 問題がセキュリティの脆弱性の定義を満たしているかどうか。
  • 問題が製品のセキュリティ ポリシーに違反していないかどうか。つまり、製品の「セキュリティの保証」が破られていないか。

セキュリティの脆弱性の定義が、すべての問題に適用できる最初のフィルターだと考えてみてください。特定のセキュリティの問題が、セキュリティの脆弱性の定義を満たしていない場合、その問題が、セキュリティ情報として発行される可能性はほとんどありません。ただし、これに対して何のアクションも起こさないというわけではありません。例えば、調査の結果、バグではあるがセキュリティの脆弱性ではないと分かった場合、MSRC は製品チームとそのバグを修正するために連携しますが、修正は、セキュリティ更新プログラム、およびセキュリティ情報を通じてではなく、サービスパックの一部として、または、製品の将来のバージョンに含まれます。

問題が脆弱性の定義を満たしている場合に、次に問われるのが、問題が製品のセキュリティの保証を破っていないかどうかです。どの製品にも前提とする使用方法があり、製品が適切に使用される場合には、その製品が提供するセキュリティについての保証があります。たとえば、ユーザー アクセス コントロール (UAC) は、Windows Vista で紹介された技術で、管理者のアクセスを必須とするものから、標準のユーザー特権、およびタスクを分ける方法を提供します。標準のユーザーがシステムを使用していて、ユーザーが権限のない領域でアクションを実行しようとしている場合には、Windows がプロンプトを表示して、管理者アカウントのパスワードを聞かれます。管理者がシステムを利用していて、同じタスクを実行しようと試みている場合は、警告プロンプトのみが表示されます。このプロンプトは、次の過程に進む前にアクションの同意のみを確認するので「同意プロンプト」という名前で知られています。「同意プロンプト」をバイパスする弱点は、セキュリティの限界とは考えられないため、セキュリティの脆弱性とは見なされません。

現在、各製品チームと共同で各製品のセキュリティ ポリシーに特化したドキュメントを作成しており、完成後に公開する予定です。それまでは、お客様が製品の通常の使用方法とセキュリティ機能について説明している製品のマニュアルを読み、製品のセキュリティ ポリシーを理解してください。以下の定義を読む際には、すべての議論は製品のセキュリティ ポリシーに記述されている文脈で行う必要があることに留意してください。

注意事項

定義の説明を始める前に、注意していただきたいのは、この文書は法的拘束力を持つ文書ではないという点です。第一の目的として、複雑さをなくしてわかりやすくするようにしました。それでも、あいまいな部分は多少残ります。したがって、次の点に注意していただく必要があります。

  • ここでの定義は何ら保証されるものではありません。この定義は、MSRC がセキュリティ更新プログラムを通じて問題を解決すべきどうかの判断を支援するツールとなるものです。最終的に、マイクロソフト セキュリティ情報 にどの問題を掲載するかの判断は、当社による最善の保護をお客様に提供するという方針に基づいた "判定" が必要となります。厳密に言えば定義から外れる問題を マイクロソフト セキュリティ情報 で取り上げる場合もあります。同様に、ある問題がその定義に全面的に当てはまる場合でも、きわめてまれな条件でのみ発生するため、別のより緊急な問題に人員を割いた方が、より多くのお客様にお役に立てると判断する場合も考えられます。
  • この定義は、Microsoft 社の基準ではありません。これは非公式なもので、MSRC が業務の優先順位付けをするために使用しているものです。ロゴの要件や、その他の企業の基準の一部でもありません。

定義

以下がセキュリティの定義です。

セキュリティの脆弱性とは、攻撃者が製品の完全性、可用性、または機密性を侵害する可能性のある製品の弱点です。

ここから、定義が何を意味するのか詳細に説明していきます。以下の説明では、定義で使用されている重要なフレーズや単語を取り上げ、それぞれの言葉が意味するところを正確に説明し、具体的な定義の適用方法を例示します。

製品の弱点

  • 弱点: セキュリティの脆弱性に含まれる弱点には、不慮によるものがあります。製品には、仕様上の弱点を伴うことがありますが、このような弱点はセキュリティの脆弱性でありません。

    例: 40 ビットの暗号を製品に実装することを選択することは、そのセキュリティの強度が場合によっては不十分だとしても、セキュリティの脆弱性にはなりません。逆に、256 ビットの暗号が、キーにあるビットの半分を失うような実装エラーは、セキュリティの脆弱性となります。

     

  • 製品: セキュリティの脆弱性は、製品にある問題の結果です。製品の不完全さによって問題があったとしても、広く受け入れられている標準であれば、セキュリティの脆弱性ではありません。

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

攻撃者が完全性を侵害する可能性がある

  • 完全性: 完全性はリソースの信頼性を指します。権限なく、黙って変更を行うために製品に存在する弱点を悪用する攻撃者は、その製品の完全性を侵害しています。

    例: 管理者がシステム上のあらゆるファイルの権限を変更できるという弱点は、管理者には既にこの機能があるため、セキュリティの脆弱性にはあたりません。逆に、特権のないユーザーに同様の変更ができるという弱点は、セキュリティの脆弱性となります。

可用性

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

    例: 攻撃者がサーバーの障害を起こすことができる弱点は、攻撃者が、サーバーが提供するサービスであるか否かを操作できるので、セキュリティの脆弱性となります。しかし、攻撃者がサーバーに大量に正規のリクエストを送信し、リソースを独占する可能性があるという事実は、サーバーの管理者が引き続きコンピューターの操作ができるうちは、セキュリティの脆弱性ではありません。

機密性

  • 機密性: 機密性は、許可されている人たちのリソース上の情報へのアクセス制限を指します。一般に公開されていない情報にアクセスするために、製品に存在する弱点を悪用する攻撃者は、その製品の機密性を侵害しています。

    例: サイトの訪問者が読むべきではないファイルを読めるようにする Web サイトの弱点は、セキュリティの脆弱性となります。しかし、あるファイルの実際の場所を明らかにする弱点は、脆弱性ではありません。そのような弱点は調査目的に役立てられる可能性もありますし、ファイルを侵害するために実際の脆弱性と併せて利用される可能性があるものの、それ自体が攻撃者のデータ侵害を許すわけではないため、セキュリティの脆弱性ではありません。(マイクロソフトは場合により、このようなケースでもパッチを開発することに決めました。)

ご覧いただいた通り、完全性、可用性、および機密性はセキュリティが目指す 3 つの主要な目標です。これら 3 つの主要目標が 1 つ以上欠けている場合にセキュリティの脆弱性が存在します。1 つのセキュリティの脆弱性は、1 つ、あるいはこれら3 要素のすべてを、同時に侵害できます。例えば、情報漏えいの脆弱性が、ある製品の機密性を侵害する一方で、リモートコード実行の脆弱性は、その完全性、可用性、および機密性を侵害するのです。

 

実践中の定義

お気づきのように、この定義の結論を出すには、まだ議論の余地があります。一般常識、そして私たちのお客様を保護したいという願いに加えて、数年に渡る、実際のセキュリティ決定を活用して、今後起こりうる脆弱性を判断しており、セキュリティ情報の一覧をご覧いただければ、定義を拡大適用している場合がかなりあることがおわかりになると思います。マイクロソフト製品に存在するセキュリティの脆弱性を見つけたと思われる方は、すぐに調査できるように、Microsoft Security Response Center にご連絡ください。その問題がセキュリティの脆弱性の定義を満たすかどうかお知らせいたします。