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

問題がセキュリティの脆弱性の定義を満たしているかどうか。

問題が製品のセキュリティ ポリシーに違反していないかどうか。つまり、製品が行っている "セキュリティの保証" が破られていないか。

ここでの定義は何ら保証されるものではありません。この定義は、われわれがマイクロソフト セキュリティ情報 で処理するべきかどうかの判断を助ける道具となるものです。最終的に、マイクロソフト セキュリティ情報 にどの問題を掲載するかの判断は、当社による最善の保護をお客様に提供するという方針に基づいた "判定" が必要となります。厳密に言えば定義から外れる問題を マイクロソフト セキュリティ情報 で取り上げる場合もあります。同様に、ある問題がその定義に全面的に当てはまる場合でも、きわめてまれな条件でのみ発生するため、別のより緊急な問題に人員を割いた方が、より多くのお客様にお役に立てると判断する場合も考えられます。

この定義は、Microsoft 社の基準ではありません。これは非公式なもので、Microsoft Security Response Center に属するわれわれが、業務上の便宜から使用しているものです。ロゴの要件や、その他の企業の基準の一部でもありません。

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

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

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

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

防止不能 : セキュリティの脆弱性があると、制御不能を伴います。つまり、問題がセキュリティの脆弱性となるには、相当の防止手段にもかかわらず、攻撃者が攻撃対象を屈服させることができる可能性がなければなりません。

例 : たとえば、Web ブラウザの問題が Web サイトによって悪用され、そのサイトを訪れるユーザーのブラウザを "ハング" させる場合を考えてみます。ユーザーが、ブラウザを終了し、再起動し、さらにその後は悪意のあるユーザーの Web サイトを避けることができれば、その問題はセキュリティの脆弱性にはなりません。ただし、その問題によって、Web サイトがユーザーを強制的に呼び戻すことが可能で、ブラウザを再起動するたびに新たに攻撃を送ることができるのであれば、それはセキュリティの脆弱性になります。もちろん、個別のケースによって状況は変わります。たとえば、問題によってデータが危険にさらされる可能性がある場合、ユーザーが強制的にサイトに呼び戻されるかどうかは問題になりません。悪意のあるユーザーがブラウザの問題を悪用するには、サイトに 1 回アクセスすれば十分だからです。

適切 : どの製品にも想定している使用方法を説明したマニュアルが付属しています。さらに、推奨する使用方法には、製品の標準的な使い方が説明されています。問題がセキュリティの脆弱性となるには、想定された方法、要求された方法、あるいは正当な方法で製品が使用されている際に発生する必要があります。

例 : たとえば、Web サイトの訪問者すべてにそのサーバーに対する管理者権限が与えられている場合にのみ、セキュリティ上の問題が顕在化する Web サーバーを考えてみます。この場合の問題はセキュリティの脆弱性ではありません。それは、最善策として広く受け入れられている方法では、Web サイトの訪問者には管理者権限を与えないように注意を促しているからです。ただし、サイトの訪問者に通常の想定された権限のみを与えている場合でも問題が顕在化する場合は、セキュリティの脆弱性になります。

不正使用 :「アクセス権の昇格」の脆弱性は権限のない機能を不正に実行できる可能性を含んでいます。

例 : 管理者がファイルのアクセス権の変更を可能とする問題は、セキュリティの脆弱性とはなりません。管理者はすでにその権限を持っているためです。一方、問題によって権限のないユーザーでも同様のことが可能な場合は、セキュリティの脆弱性になります。

制限 : システムの操作を制限することは、実際にはアクセス権の不正使用の特殊なケースですが、DoS (サービス拒否) や同様の攻撃の重大性のため別に取り上げました。

例 : 攻撃者にサーバー停止を可能にさせてしまうような問題はセキュリティの脆弱性になります。攻撃者がサーバーにサービスを提供させるかどうかを制限することができるからです。攻撃者は膨大な量の正当な要求をサーバーに送信して、サーバーのリソースを独占することができますが、サーバーのオペレーターがサーバーを制御できる限り、セキュリティの脆弱性にはなりません。

損傷 : 所有者や管理者の努力にもかかわらず、データにアクセスできることは、セキュリティの脆弱性になります。場合によって、読み取り、追加、およびデータの変更を伴うことがあります。

例 : たとえば、あるオペレーティング システムではファイル単位のアクセス制御が提供されているとします。あるユーザーが、ファイルに対するアクセス権が制限されているにもかかわらず、ほかのユーザーのデータを読み取れるという問題がある場合、セキュリティの脆弱性になります。一方、新しく作成されたファイルに対する既定のアクセス権が全員に読み取りアクセスを許可したとしても、これはセキュリティの脆弱性になりません。また、オペレーティング システムでファイル単位のアクセス制御が提供されておらず、それがマニュアルにも記述されている場合は、セキュリティの脆弱性になりません。

システム上のデータ : システム上のデータと、システムについてのデータとでは、微妙ですが重要な違いがあります。システム上のデータには、主な影響として損傷されることが危険な情報が含まれます。システム上のデータの例としては、ユーザーのデータ ファイル、暗号キーのストアなどがあります。システムについてのデータには、危険になることがあるにしても、2 次的または 3 次的な影響として危険になる情報が含まれます。この例としては、ネットワーク トポロジ、ファイルの場所など、システムの論理構造に関する情報があります。

例 : Web の訪問者が読めないはずのデータを読めてしまうというサーバー内の問題は、セキュリティの脆弱性になります。ただし、ファイルの物理的な場所を開示するという問題は、セキュリティの脆弱性にはなりません。このような問題は、偵察の目的で悪用される可能性があります。攻撃者が、本当の脆弱性と一緒に使用すると、ファイルを危険にさらされる可能性もあります。この問題だけではデータを損傷することはできないので、セキュリティの脆弱性にはなりません。(しかし、マイクロソフトではこのような場合にも、修正プログラムを提供しています。)

許可されていない信頼 : 多くの製品では、信頼する個人や組織を設定できるようになっており、また設定内容に応じた動作を制限できるようになっています。ユーザーが認めないレベルの信頼関係を攻撃者が取得できる問題の場合は、セキュリティの脆弱性になります。

例 : ブラウザを使用して他人になりすまして SSL セッションを開始できる問題が Web サイトにある場合、信頼されたサイトは、セキュリティの脆弱性になります。ただし、誰かにトロイの木馬型ソフトウェアを実行するように信じこませるために IRC チャネル上で偽名を使うなど、ソーシャル エンジニアリングに基づく "なりすまし" は、セキュリティの脆弱性になりません。