(57)【要約】      （修正有）【課題】仮想インフラストラクチャを用いた情報技術リスク管理を提供する。【解決手段】組織に対する情報技術リスクは、複数の仮想マシン（ＶＭ）１０３ａ、１０３ｂと関連しており、リスクオーケストレータ１０６は脅威表示メッセージ（ＴＩＭ）を脅威インジケータ８０、８１から受信する。各ＴＩＭは、ホストが脆弱性を有する脅威の状態を表示する。脅威から生じるダウンタイム確率（ＤＴＰ）および各ホストに対する全体のホストＤＴＰが計算される。各ＶＭに関しては、ＶＭに関連するリスク値が、ＶＭに対するホストＤＴＰおよびＶＭに対する影響の関数として計算され、影響は組織にとってＶＭの相対的重要性を反映する値である。リスク軽減を必要とする各ＶＭは、方針に従って識別され優先順位が付けられ、設定された軽減制御処置がリスク軽減を必要とする各ＶＭに対して実行される可能性がある。【選択図】図１
2011008780.tif 000002
【特許請求の範囲】
【請求項１】
複数の仮想マシン（ＶＭ）の各々に関連する組織に対するリスクを管理する方法であって、前記複数のＶＭの各々は複数のホストの一つで動作し、各ホストは一つ以上のネットワークに接続され、前記方法を実行するリスクオーケストレータと通信する物理的なコンピュータシステムであり、前記リスクオーケストレータは前記複数のホストおよび脅威インジケータと通信するアプリケーションであり、前記方法は、
前記リスクオーケストレータにおいて、前記脅威インジケータから脅威表示メッセージを受信することであって、前記脅威表示メッセージは、脅威グループ内の複数のホストが脆弱性を有する脅威の状態を表示するものである、前記受信すること、
前記脅威から生じるダウンタイム確率を計算すること、
各ホストに関するホストダウンタイム確率を計算することであって、前記ホストダウンタイム確率は、前記ホストが脆弱性を有するすべての脅威からのすべての前記ダウンタイム確率の関数である、前記ホストダウンタイム確率を計算すること、
各リスク管理されたＶＭに対して、前記ＶＭに関連するリスク値を計算することであって、前記リスク値は、前記ＶＭが動作しているホストの前記ホストダウンタイム確率と、前記ＶＭに関する影響値との関数であり、前記影響値は前記組織に対する前記ＶＭの相対的重要性を反映する値である、前記ＶＭに関連するリスク値を計算すること、
リスク軽減を必要とする各リスク管理されたＶＭを方針に従って識別し、最高の関連リスクを有する前記リスク管理されたＶＭの一つで始まる順序で、リスク軽減を必要とする前記リスク管理されたＶＭに優先順位を付けること、
リスク軽減を必要とする前記リスク管理されたＶＭの各々に対して設定された軽減制御処置を前記優先順位の順序で実施すること
を備える方法。
【請求項２】
前記ホストダインタイム確率を計算することは、ＤＴＰＨＯＳＴ＝１−Πｉ＝１．．．ｎ（１−ＤＴＰＴＩＮＤｉ）を解くことをさらに含み、ＤＴＰＨＯＳＴは前記ホストダウンタイム確率であり、ｉは１からｎの整数であり、ｎは脅威の数であり、ＴＩＮＤｉは脅威ｉに関する前記脅威インジケータであり、ＤＴＰＴＩＮＤｉは脅威ｉから生じる前記ダウンタイム確率である、請求項１に記載の方法。
【請求項３】
すべての前記ＶＭに関するすべてのＶＭリスクの和としてシステムリスクを計算すること、
前記システムリスクが残存システムリスク閾値を超える場合にシステム緩和処置を実施すること
をさらに備える、請求項１に記載の方法。
【請求項４】
前記システムリスク閾値は、すべての前記ＶＭに関するすべての最大ＶＭリスクの和に等しいものである最大システムリスクの所定のパーセンテージとして設定される、請求項３に記載の方法。
【請求項５】
前記システム緩和処置は、最小ホストダウンタイム確率を有するホストにすべてのＶＭを移動すること、ＶＭのスナップショットを撮ること、すべてのＶＭの電源を遮断すること、すべてのホストを終了すること、前記ＶＭ内のゲスト・オペレーティング・システム（ＧＯＳ）を終了すること、災害回復工程を起動することによってＶＭを異なるサイトに切り換えることからなる群から選択される一つまたは複数の処置を含む、請求項３に記載の方法。
【請求項６】
前記方針は、最小の混乱または費用で十分なリスク軽減を提供することであり、リスク軽減を必要とする前記リスク管理されたＶＭを識別することは、リスク管理されたＶＭに関連する前記リスク値の各々を閾値と比較すること、ＶＭに対する前記リスク値が前記閾値を超える場合に、前記リスク管理されたＶＭがリスク軽減を必要としているとみなすことを含む、請求項１に記載の方法。
【請求項７】
前記方針は、進行中のリスクバランシングを実施することであり、リスク軽減を必要とする前記リスク管理されたＶＭを識別することは、リスク軽減が必要であるのにリスク軽減が最近試行されていない、最高の関連リスクを有するリスク管理されたＶＭを識別することを含む、請求項１に記載の方法。
【請求項８】
前記設定された軽減制御処置を実施することは、前記ＶＭを現在のホストから選択されたターゲットホストにマイグレーションすることを含み、前記選択されたターゲットホストは、マイグレーションされる前記ＶＭが前記方針に従ったリスク軽減をもはや必要としないように十分に低いダウンタイム確率を有する、請求項１に記載の方法。
【請求項９】
前記方針は、最小の混乱または費用で十分なリスク軽減を提供することであり、前記ターゲットホストの選択は、マイグレーション時にマイグレーションされる前記ＶＭが閾値以下の関連リスク値を有するようにターゲットホストを選択することを含み、前記関連リスクが前記閾値以下である場合に、前記ＶＭはリスク軽減を必要とするとみなされない、請求項８に記載の方法。
【請求項１０】
前記方針は、リスクを最小値に低減することであり、前記ターゲットホストの選択は、最低のホストダウンタイム確率を有するターゲットホストを選択することを含む、請求項８に記載の方法。
【請求項１１】
リスク軽減を必要とする前記リスク管理されたＶＭに対する前記設定された軽減制御処置は、前記ＶＭのスナップショットを撮ること、前記ＶＭをマイグレーションまたはライブマイグレーションすること、前記ＶＭをサスペンドすること、前記ＶＭの電源を遮断すること、フェイルオーバーの可能性に備えてシャドウＶＭを実装すること、前記ＶＭを既存のシャドウＶＭにフェイルオーバーすること、前記ＶＭを再起動すること、前記ＶＭを終了することからなる群から選択される一つまたは複数の処置を含む、請求項１に記載の方法。
【請求項１２】
リスクオーケストレータに対してコンピュータコードを具体化するマシン可読記憶媒体であって、前記リスクオーケストレータは複数の仮想マシン（ＶＭ）の各々に関連する組織に対するリスクを管理し、各ＶＭは複数のホストの一つで動作し、各ホストは一つまたは複数のネットワークに接続され、前記リスクオーケストレータと通信する物理的なコンピュータシステムであり、前記リスクオーケストレータは前記複数のホストおよび少なくとも一つの脅威インジケータと通信するアプリケーションであり、前記リスクオーケストレータはコンピュータシステムに方法を実行せしめ、前記方法は、
前記リスクオーケストレータにおいて、前記脅威表示インジケータの一つから脅威表示メッセージを受信することであって、前記脅威表示メッセージは、脅威グループ内の複数のホストが脆弱性を有する脅威の状態を表示するものである、前記受信すること、
前記脅威から生じるダウンタイム確率を計算すること、
各ホストに対するホストダウンタイム確率を計算することであって、前記ホストダウンタイム確率は、前記ホストが脆弱性を有するすべての脅威からのすべての前記ダウンタイム確率の関数である、前記ホストダウンタイム確率を計算すること、
各リスク管理されたＶＭに対して、前記ＶＭに関連するリスク値を計算することであって、前記リスク値は、ＶＭが動作している前記ホストに対する前記ホストダウンタイム確率と、前記ＶＭに対する影響値との関数であり、前記影響値は、前記組織に対する前記ＶＭの相対的重要性を反映する値である、前記ＶＭに関連するリスク値を計算すること、
リスク軽減を必要とする各リスク管理されたＶＭを方針に従って識別し、最高の関連リスクを有する前記リスク管理されたＶＭの一つで始まる順序で、リスク軽減を必要とする前記リスク管理されたＶＭの優先順位を付けること、
リスク軽減を必要とする前記リスク管理されたＶＭの各々に関して設定された軽減制御処置を、前記優先順位の順序で実施すること
を含む、マシン可読記憶媒体。
【請求項１３】
前記ホストダウンタイム確率を計算することは、ＤＴＰＨＯＳＴ＝１−Πｉ＝１．．．ｎ（１−ＤＴＰＴＩＮＤｉ）を解くことをさらに含み、ＤＴＰＨＯＳＴは前記ホストダウンタイム確率であり、ｉは１からｎの整数であり、ｎは脅威の数であり、ＴＩＮＤｉは脅威ｉに対する前記脅威インジケータであり、ＤＴＰＴＩＮＤｉは脅威ｉから生じる前記ダウンタイム確率である、請求項１２に記載のマシン可読記憶媒体。
【請求項１４】
前記方法は、
システムリスクをすべての前記ＶＭに対するすべての前記ＶＭリスクの和として計算すること、
前記システムリスクが残存システムリスク閾値を超えるときシステム緩和処置を実施すること
をさらに備える、請求項１２に記載のマシン可読記憶媒体。
【請求項１５】
前記システムリスク閾値は、すべての前記ＶＭに対するすべての最大ＶＭリスクの和に等しいものである最大システムリスクの所定のパーセンテージとして設定される、請求項１４に記載のマシン可読記憶媒体。
【請求項１６】
前記システム緩和処置は、最小ホストダウンタイム確率を有するホストにすべてのＶＭを移動すること、ＶＭのスナップショットを撮ること、すべてのＶＭの電源を遮断すること、すべてのホストを終了すること、前記ＶＭ内のゲスト・オペレーティング・システム（ＧＯＳ）を終了すること、災害回復工程を起動することによってＶＭを異なるサイトに切り換えることからなる群から選択される一つまたは複数の処置を含む、請求項１４に記載のマシン可読記憶媒体。
【請求項１７】
前記方針は、最小の混乱または費用で十分なリスク軽減を提供することであり、リスク軽減を必要とする前記リスク管理されたＶＭを前記識別することは、リスク管理されたＶＭに関連する前記リスク値の各々を閾値と比較すること、ＶＭに対する前記リスク値が前記閾値を超える場合に、前記リスク管理されたＶＭがリスク軽減を必要としているとみなすことを含む、請求項１２に記載のマシン可読記憶媒体。
【請求項１８】
前記方針は、進行中のリスクバランシングを実施することであり、リスク軽減を必要とする前記リスク管理されたＶＭを前記識別することは、リスク軽減が必要であるのにリスク軽減が最近試行されていない、最高の関連リスクを有するリスク管理されたＶＭを識別することを含む、請求項１２に記載のマシン可読記憶媒体。
【請求項１９】
前記設定された軽減制御処置を実施することは、前記ＶＭを現在のホストから選択されたターゲットホストにマイグレーションすることを含み、前記選択されたターゲットホストは、マイグレーションされる前記ＶＭが前記方針に従ったリスク軽減をもはや必要としないように十分に低いダウンタイム確率を有する、請求項１２に記載のマシン可読記憶媒体。
【請求項２０】
前記方針は、最小の混乱または費用で十分なリスク軽減を提供することであり、前記ターゲットホストの選択は、マイグレーション時にマイグレーションされる前記ＶＭが閾値以下の関連リスク値を有するようにターゲットホストを選択することを含み、前記関連リスクが前記閾値以下である場合に、前記ＶＭはリスク軽減を必要とするとみなされない、請求項１９に記載のマシン可読記憶媒体。
【請求項２１】
前記方針は、リスクを最小値に低減することであり、前記ターゲットホストの選択は、最低のホストダウンタイム確率を有するターゲットホストを選択することを含む、請求項１９に記載のマシン可読記憶媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、概して、仮想インフラストラクチャを用いた情報技術リスク管理に関し、より詳細には、各々が複数のホストの一つで動作する複数の仮想マシン（ＶＭ）の各々に関連する組織に対するリスク管理に関する。
【背景技術】
【０００２】
いかなる組織においても、リスクは、金融市場、プロジェクト失敗、法的責任、信用リスク、事故、自然の原因および災害ならびに敵対者による意図的犯行における不確実性に由来する。リスク管理は、（１）リスクの識別、評価、および優先順位付け、（２）不運な事象の確率および影響の少なくとも一方を最小化し、監視し、管理するための組織的かつ経済的な資源の活用の二つの要素を必要とする。
【０００３】
情報技術（ＩＴ）は多くの事業にとって進行中の業務の重要な要素になっているので、情報技術（ＩＴ）リスク管理は企業のリスク戦略の重要な要素になっている。ＩＴシステムと活用の失敗は最大で時間当たり数百万ドルの企業損失を招くおそれがある。リスクの影響度を最小限に抑えるために、リスクを軽減するための複雑な解決法を実施する企業もあるが、多くのＩＴリスク管理解決策は、システム内で変化するリスクに反応するように策定されるのではなく、システムをリスクから切り離すかあるいは大惨事から回復するように策定される。
【０００４】
企業コンピュータシステムにおける多くの進歩の中には、コンピュータ資源の仮想化がある。コンピュータ資源の仮想化は、一般に、一つ以上の仮想マシンに対して基盤となるコンピュータ・システム・ハードウェアのソフトウェア抽象化および出力先変更を含む。仮想マシンは、オペレーティングシステムとアプリケーションを基盤となるハードウェアから分離し、さらに互いを分離する。したがって、ハードウェアは、各々が対応するオペレーティングシステムを有する複数の仮想マシンの中で共有されうる。
【０００５】
各仮想マシン（ｖｉｒｔｕａｌ  ｍａｃｈｉｎｅ：ＶＭ）は完全な実行環境であり、ユーザ入力およびユーザ出力がユーザとＶＭの間で通信されるように、サーバはネットワーク接続経由でユーザインターフェースを提供する。完全なコンピュータシステムのソフトウェア抽象化として、仮想マシンはハードウェア使用率の増大に加えてユーザに多くの便益をもたらす。たとえば、仮想マシンが動いている間であっても、仮想マシンは一つの物理的コンピュータシステムから別の物理的コンピュータシステムに移動、すなわち「マイグレーション」されてもよい。一つの物理的コンピュータシステムから別の物理的コンピュータシステムへの仮想マシンの有意な中断なしでのマイグレーションは、本明細書において「ライブマイグレーション（ｌｉｖｅ  ｍｉｇｒａｔｉｏｎ）」と呼ばれる。ライブマイグレーションでは、ホストの動的な負荷平衡（ｌｏａｄ  ｂａｌａｎｃｉｎｇ）が可能となる。ライブマイグレーションの例は、ＶＭｗａｒｅ（登録商標）ＶＭｏｔｉｏｎ（商標）技術によって提供される。仮想化によって、自動保守、電源管理、記憶装置管理など、他の便益が可能になる。
【先行技術文献】
【非特許文献】
【０００６】
【非特許文献１】ストーンバーナ（Ｓｔｏｎｅｂｕｒｎｅｒ）他、「情報技術システムのためのリスクマネジメントガイド（Ｒｉｓｋ  Ｍａｎａｇｅｍｅｎｔ  Ｇｕｉｄｅ  ｆｏｒ  Ｉｎｆｏｒｍａｔｉｏｎ  Ｔｅｃｈｎｏｌｏｇｙ  Ｓｙｓｔｅｍｓ）、国立標準技術研究所提言（Ｒｅｃｏｍｍｅｎｄａｔｉｏｎｓ  ｏｆ  ｔｈｅ  Ｎａｔｉｏｎａｌ  Ｉｎｓｔｉｔｕｔｅ  ｏｆ  Ｓｔａｎｄａｒｄｓ  ａｎｄ  Ｔｅｃｈｎｏｌｏｇｙ）」、国立標準技術研究所（Ｎａｔｉｏｎａｌ  Ｉｎｓｔｉｔｕｔｅ  ｏｆ  Ｓｔａｎｄａｒｄｓ  ａｎｄ  Ｔｅｃｈｎｏｌｏｇｙ）特別出版物（Ｓｐｅｃｉａｌ  Ｐｕｂｌｉｃａｔｉｏｎ）８００−３０、ｐ．１−２５
【非特許文献２】ボーエン（Ｂｏｗｅｎ）他、「情報セキュリティハンドブック（Ｉｎｆｏｒｍａｔｉｏｎ  Ｓｅｃｕｒｉｔｙ）：経営者のためのガイド（Ａ  Ｇｕｉｄｅ  ｆｏｒ  Ｍａｎａｇｅｒｓ）」、国立標準技術研究所提言（Ｒｅｃｏｍｍｅｎｄａｔｉｏｎｓ  ｏｆ  ｔｈｅ  Ｎａｔｉｏｎａｌ  Ｉｎｓｔｉｔｕｔｅ  ｏｆ  Ｓｔａｎｄａｒｄｓ  ａｎｄ  Ｔｅｃｈｎｏｌｏｇｙ）」、国立標準技術研究所（Ｎａｔｉｏｎａｌ  Ｉｎｓｔｉｔｕｔｅ  ｏｆ  Ｓｔａｎｄａｒｄｓ  ａｎｄ  Ｔｅｃｈｎｏｌｏｇｙ）特別出版物（Ｓｐｅｃｉａｌ  Ｐｕｂｌｉｃａｔｉｏｎ）８００−１００、ｐ．１−１７８
【非特許文献３】「資本測定と資本基準の国際的収束（Ｉｎｔｅｒｎａｔｉｏｎａｌ  Ｃｏｎｖｅｒｇｅｎｃｅ  ｏｆ  Ｃａｐｉｔａｌ  Ｍｅａｓｕｒｅｍｅｎｔ  ａｎｄ  Ｃａｐｉｔａｌ  Ｓｔａｎｄａｒｄｓ）」、バーセル銀行監督委員会（Ｂａｓｅｌ  Ｃｏｍｍｉｔｔｅｅ  ｏｎ  Ｂａｎｋｉｎｇ  Ｓｕｐｅｒｖｉｓｉｏｎ）、国際決済銀行（Ｂａｎｋ  ｆｏｒ  Ｉｎｔｅｒｎａｔｉｏｎａｌ  Ｓｅｔｔｌｅｍｅｎｔｓ）、バーセル、スイス国、２００４年６月、第５節、業務リスク（Ｏｐｅｒａｔｉｏｎａｌ  Ｒｉｓｋ）
【非特許文献４】「第１０７回アメリカ合衆国議会第２セッション（Ｏｎｅ  Ｈｕｎｄｒｅｄ  Ｓｅｖｅｎｔｈ  Ｃｏｎｇｒｅｓｓ  ｏｆ  ｔｈｅ  Ｕｎｉｔｅｄ  Ｓｔａｔｅｓ  ｏｆ  Ａｍｅｒｉｃａ  ａｔ  ｔｈｅ  Ｓｅｃｏｎｄ  Ｓｅｓｓｉｏｎ）」、ワシントン市、２００２年１月２３日、２００２年サーベンス・オクスリー法（Ｓａｒｂａｎｅｓ−Ｏｘｌｅｙ  Ａｃｔ）、第３０２条、第４０４条、第４０９条、ｐ．３３−３４、４５、４７
【発明の概要】
【課題を解決するための手段】
【０００７】
組織に対するリスクは、複数の仮想マシン（ＶＭ）の各々と関連し、複数のＶＭの各々は、複数のホストの一つで動作し、各ホストは、一つ以上のネットワークに接続され、リスクオーケストレータ（ｒｉｓｋ  ｏｒｃｈｅｓｔｒａｔｏｒ）と通信する物理的コンピュータシステムである。リスクオーケストレータは、脅威インジケータから脅威表示メッセージ（ｔｈｒｅａｔ  ｉｎｄｉｃａｔｉｏｎ  ｍｅｓｓａｇｅ：ＴＩＭ）を受信する。各ＴＩＭは、脅威グループ内の複数のホストおよびＶＭの少なくとも一方が脅威に対して脆弱な状態にあることを表示する。リスクオーケストレータは、脅威から生じるダウンタイム確率および各ホストに対するホストダウンタイム確率を計算し、ホストダウンタイム確率はホストが脆弱性を有するすべての脅威から生じる全ダウンタイム確率の関数である。各ＶＭでは、ＶＭに関連するリスク値が計算され、リスク値はＶＭが動作しているホストに関するホストダウンタイム確率の関数であるとともにＶＭに対する影響値であり、影響値は組織にとってのＶＭの相対的重要性を反映する値である。リスク軽減を必要とする各ＶＭは、方針に従って識別されて優先順位が付けられ、設定された軽減制御処置がリスク軽減を必要とする各ＶＭに対して実行される可能性がある。
【０００８】
本発明の他の態様は、本発明の原理を例として示す添付図を併用して行なわれる以下の詳細説明から明らかになるであろう。
【図面の簡単な説明】
【０００９】
【図１】ＩＴリスク管理を実施するように構成された例示的なコンピュータ・ネットワーク・システムの物理的配置の略図である。
【図２】図１に示されたコンピュータネットワークの論理的表現の図である。
【図３】図１および２を参照した、上記のコンピュータネットワークを用いた組織におけるリスクおよび軽減戦略を評価する手順を例として示すフローチャートを示す図である。
【図４Ａ】システムのリスク管理された構成要素に対する脅威を識別し、リスクを緩和するためにリスクオーケストレータによって実施される可能性のある手順を例として示す図である。
【図４Ｂ】システムのリスク管理された構成要素に対する脅威を識別し、リスクを緩和するためにリスクオーケストレータによって実施される可能性のある手順を例として示す図である。
【図４Ｃ】システムのリスク管理された構成要素に対する脅威を識別し、リスクを緩和するためにリスクオーケストレータによって実施される可能性のある手順を例として示す図である。
【図５Ａ】例示的な脅威表示メッセージを示す図である。
【図５Ｂ】例示的な脅威表示メッセージを示す図である。
【図６Ａ】複数の部屋間に展開するコンピュータ・ネットワーク・システムとそのリスク軽減工程を例として図式的に示す図である。
【図６Ｂ】複数の部屋間に展開するコンピュータ・ネットワーク・システムとそのリスク軽減工程を例として図式的に示す図である。
【図６Ｃ】複数の部屋間に展開するコンピュータ・ネットワーク・システムとそのリスク軽減工程を例として図式的に示す図である。
【図６Ｄ】複数の部屋間に展開するコンピュータ・ネットワーク・システムとそのリスク軽減工程を例として図式的に示す図である。
【発明を実施するための形態】
【００１０】
本発明は、添付図を併用し以下の説明を参照することによって最もよく理解されるであろう。
組織のリスク管理プロセスの主要目的は、脅威に直面したときに組織の使命を果たす能力を保護することである。リスク管理は、情報技術（ＩＴ）を背景とした固有の特性を有する。ＩＴシステム管理者の目的は、平均故障間隔が最大化されてシステムダウンタイムが回避されるように、ＩＴインフラストラクチャに関するリスクを管理することである。ダウンタイムは、情報の可用性、機密性、および完全性のうちの少なくとも一つの喪失または低下である。ダウンタイムが回避されえないとき、システムの平均修復時間を可能な最小時間まで下げることによってリスクが軽減されうる。
【００１１】
図１は、ホスト１０２ａ、１０２ｂを含むコンピュータ・ネットワーク・システム１００を例として示す。ホスト１０２ａ、１０２ｂは、各々が複数の仮想マシンを実行する企業サーバであってもよい。各サーバは、プロセッサ、データバス、メモリ、および入力／出力（Ｉ／Ｏ）ポートなど、典型的なコンピュータ構成要素を有する汎用コンピュータシステムであってもよい。たとえば、ホスト１０２ａは、ｎ個の仮想マシン（ＶＭ）１０４を含み、ホスト１０２ｂは同様に複数のＶＭ１０７を動作させる。ＶＭは、仮想化ソフトウェア１０３ａ、１０３ｂによって部分的に実装される物理的コンピュータシステムの抽象概念である。ホスト上で動作する一つ以上のＶＭを有するホストは「ＶＭホスト」と呼ばれる場合がある。
【００１２】
各ネットワーク１１４ａ、１１４ｂは、各々が単一のホストを有するものとして示されるが、任意の数のホストが各ネットワークに常駐してもよいことを理解されたい。したがって、ホストは同じネットワークおよび同じサイトに常駐してもよく、あるいは種々のネットワークの中および位置に分配されてもよい。
【００１３】
各ホスト１０２ａ、１０２ｂは、ホスト内で動作する仮想マシンの実行をサポートする仮想化ソフトウェア１０３ａ、１０３ｂの対応する実装を有する。一実施形態において、仮想化ソフトウェア１０３ａ、１０３ｂは、各々カリフォルニア州、パロアルト（Ｐａｌｏ  Ａｌｔｏ）のＶＭｗａｒｅ，Ｉｎｃ．から市販されているＶＭｗａｒｅ（登録商標）ＥＳＸ  Ｓｅｒｖｅｒの事例であってもよい。各ＶＭ１０４、１０７は、ゲスト・オペレーティング・システム（ｏｐｅｒａｔｉｎｇ  ｓｙｓｔｅｍ：「ＯＳ」）および一つ以上のアプリケーション（ａｐｐｌｉｃａｔｉｏｎ：「Ａｐｐ」）のインストールを含む。
【００１４】
ホスト１０５、１０９は、図示のような企業サーバ（すなわち、物理的コンピュータシステム）またはホスト１０２ａ、１０２ｂ（描写せず）の一つ、または異なるホスト（図示せず）で動作する仮想マシンであってもよい。ホスト１０５は、リスクマネジャとも呼ばれるオーケストレータ１０６を動作させる。リスクオーケストレータ１０６は、システム内のリスクを監視してＩＴリスク方針によって決定される処置を開始するソフトウェアアプリケーションである。データベース９０は、様々なデータを格納するリスクオーケストレータ１０６にアクセス可能な場所である。データベース９０は、ホスト１０５のメモリ内にあってもよく、単層ファイル、階層データ構造、データオブジェクトなどの任意のデータ構造を用いて格納されてもよい。データベース９０は、ローカルまたは外部記憶装置に含まれてもよく、構造化問合せ言語（ｓｔｒｕｃｔｕｒｅｄ  ｑｕｅｒｙ  ｌａｎｇｕａｇｅ：ＳＱＬ）データベースソフトウェアなどを用いて直接アクセスされるネットワーク記憶装置またはシステムに含まれてもよい。
【００１５】
ホスト１０９は、システム１００内のホストおよびＶＭを管理する仮想インフラストラクチャマネジャ１１０を動作させる。ＶＭ管理活動は、ＶＭをプロビジョニングする（ｐｒｏｖｉｓｉｏｎｉｎｇ）こと、ＶＭを設定する（ｃｏｎｆｉｇｕｒｉｎｇ）こと、ＶＭを起動および停止すること、ＶＭをマイグレーションすることなどを含みうる。一実施形態において、仮想インフラストラクチャマネジャ１１０は、カリフォルニア州、パロアルトのＶＭｗａｒｅ，Ｉｎｃ．から市販されているＶＭｗａｒｅ（登録商標）ｖＳｐｈｅｒｅ（商標）の実装である。
【００１６】
図２は、図１に示されるコンピュータ・ネットワーク・システム１００の論理的概要を示すもので、コンピュータ・ネットワーク・システム１００の構成要素間の通信を例として示す。脅威インジケータ（ｔｈｒｅａｔ  ｉｎｄｉｃａｔｏｒ：ＴＩＮＤ）８０は、ホスト１０２ａ、１０２ｂまたはＶＭ１０４、１０７の一つまたは複数に関する脅威を感知または検出するセンサ、デバイス、ソフトウェアモジュールなどである。各ＴＩＮＤは、明確な通信チャネル、プロトコル、およびメッセージフォーマットで脅威表示メッセージ（ＴＩＭ）によってリスクオーケストレータ１０６と通信する。ＴＩＭは、リスクオーケストレータ１０６によって処理されて、対応する脅威グループのメンバの関連ダウンタイム確率に変換され、脅威グループの各々は以下でさらに説明されるように仮想マシンとホストの集合である。
【００１７】
脅威は、識別または測定可能なものであればいかなる種類のものであってもよい。環境上の脅威は、すべてのデータセンタに共通しており、温度および湿度、電源喪失、煙（火災）、水、振動などの脅威を含む。セキュリティ脅威によって代表される人間の脅威は、意図的でない行為（不注意なデータ入力）であるか意図的な行為（ネットワークベースの攻撃、悪意のあるソフトウェアアップロード、機密情報への不正アクセスなど）であるかを問わず、人間によって可能にされるかあるいは引き起こされる事象として定義される。自然の脅威は、極端な気象条件（ハリケーン、津波、洪水など）または地震など、自然現象によって引き起こされ、極度の損害を与える可能性がある。ハードウェアの機能不良脅威は、ハードウェアまたはネットワーク構成要素の機能不良に対するシステムホストの脆弱性によって引き起こされる。これらの脅威の源およびその他の源は、個別に、または組み合わされてホストおよびＶＭのダウンタイムをもたらす可能性がある。
【００１８】
ＴＩＮＤの性質、これらの種々の技術的実装、インストールの種類、および通信手段に起因して、すべてのＴＩＮＤがリスクオーケストレータ１０６によって必要とされる形式のメッセージをフォーマットできるとは限らず、これらのすべてが要求されるプロトコルおよびネットワークを介してこのようなメッセージを送信する手段を有するわけではない。一部のＴＩＮＤはメカニズムにメッセージを送信できないかもしれないが、ＴＩＮＤの値についてはむしろ周期的にポーリングされる必要があろう。ＴＩＭコンバータ８５は、ＴＩＮＤ８１〜８６とリスクオーケストレータ１０６の間にインテグレーション層を設けることによってこの問題を解決する。ＴＩＭコンバータ８５は、ＴＩＮＤ８１〜８６から受信した入力に対応するＴＩＭ対応入力を発生する。したがって、ＴＩＭコンバータ８５によって、リスクオーケストレータ１０６のＡＰＩの要件と一致するＴＩＭを発生するように構成されない既製のセンサおよびモジュールを使用することができる。ＴＩＭコンバータ８５は、種々の形式のＴＩＮＤメッセージまたは信号を処理してもよく、ＴＩＮＤメッセージまたは信号を反映するＴＩＭを発生する。受信した値またはポーリングされた値は、たとえば、図５Ａ、５Ｂを参照して以下に記述されるように、適切にフォーマットされたＴＩＭメッセージにフォーマットされる。この後、ＴＩＭはリスクオーケストレータ１０６に送られる。一実施形態において、ＴＩＭコンバータ８５は、図２に示されるように、外部デバイスまたはシステムである。しかし、ＴＩＭコンバータ８５をリスクオーケストレータ１０６と一体化させることも可能である。さらに、ＴＩＭコンバータ８５は、外部デバイスとして、受信したＴＩＭをリスクオーケストレータ１０６に送るための代用品としての機能を果たしてもよい。
【００１９】
リスクが管理された各ホスト１０２は、一つ以上の脆弱性を有する。各脆弱性について、一つ以上の脅威インジケータ（ＴＩＮＤ）８０は、リスク管理されたホストが属する脅威グループが脆弱性に起因して危険にさらされているかどうか、すなわち、脆弱性が作用しているかどうかを表示する。これらの表示は、ＴＩＮＤ８１〜８７から直接的に、またはＴＩＭコンバータ８５を介してリスクオーケストレータが受信したＴＩＭに反映される。
【００２０】
説明を目的として、複数の種類の脅威インジケータが示される。ＴＩＮＤ８１は、管理されたネットワーク上で検出される可能性のあるネットワーク状態情報または様々な障害を提供する簡単なネットワーク管理プロトコル（ｓｉｍｐｌｅ  ｎｅｔｗｏｒｋ  ｍａｎａｇｅｍｅｎｔ  ｐｒｏｔｏｃｏｌ：ＳＮＭＰ）エージェントであってもよい。ＴＩＮＤ８２は、共通情報モデル（ｃｏｍｍｏｎ  ｉｎｆｏｒｍａｔｉｏｎ  ｍｏｄｅｌ：ＣＩＭ）またはＳＯＡＰプロトコルメッセージを発生する物理的な侵入検知システム（たとえば、行動探知器または盗難警報器）であってもよい。ＴＩＮＤ８３は、型−長さ−値（ｔｙｐｅ−ｌｅｎｇｔｈ−ｖａｌｕｅ：ＴＬＶ）符号化データを送るバックアップバッテリ残量を示す電源システムの構成要素であってもよい。ＴＩＮＤ８４は、ＸＭＬ形式の国立気象局データにアクセスするソフトウェアモジュールであってもよい。一実施形態において、ＴＩＮＤ８４は、ＴＩＭコンバータ８５からクエリを受信して、たとえばＣＩＭ／ＳＯＡＰプロトコルを用いて求められる情報で応答するサーバである。このように、ＴＩＮＤ８４は、脅威状態に関する情報を周期的にポーリングされる必要がある。ＴＩＮＤ８６は、現在の温度および湿度に対応する電圧信号を脅威表示メッセージ（ＴＩＭ）コンバータ８５に常に送信する温度／湿度センサであってもよい。ＴＩＮＤ８７は、適切にフォーマットされた脅威表示メッセージ（ＴＩＭ）を発生して送信し、これらをリスクオーケストレータ１０６に直接伝えるように構成される水位センサであってもよい。
【００２１】
リスクオーケストレータ１０６は、ＴＩＭを受信し、受信したＴＩＭに基づいて脅威に対して脆弱な各ホストのダウンタイム確率を計算する。ダウンタイム確率は、データベース９０で維持される可能性のあるダウンタイム確率（ｄｏｗｎｔｉｍｅ  ｐｒｏｂａｂｉｌｉｔｙ：ＤＴＰ）表に入力される。リスクは、各ＶＭに対して、対応するホストに関するダウンタイム確率の関数およびネットワーク管理者によってまたは方針に従って割り当てられた影響値（ｉｍｐａｃｔ  ｖａｌｕｅ）として計算される。影響値は、特定のＶＭの不具合またはセキュリティ過失から生じる経済的またはその他の影響（評判の喪失、機密（プライバシー）の漏洩、完全性、契約違反など）とある関係を有するかもしれない。たとえば、すべての管理されたＶＭに対するリスクの和など、全体としてのシステム１００に関連するリスクが計算されてもよい。特にリスク管理されたＶＭに対して言及されるが、他のリスク管理された構成要素がリスクオーケストレータ１０６を用いてさらに管理されてもよいことを認識されたい。
【００２２】
特定のサービスが複数のＶＭに広げられ、やがてシステムの単一構成要素としてリスク管理されてもよい。この場合、サービスは、システムリスクと同様の方法に依存するＶＭの和であるリスクを有する可能性がある。
【００２３】
一実施形態において、リスクオーケストレータ１０６は、各リスク管理された構成要素（たとえば、ＶＭ）に関連するリスクを継続的または周期的に精査し、最高の関連リスクを有するリスク管理された構成要素に関連するリスクを軽減するとともにシステムに対する全リスクを管理するために「一定バランシング（ｃｏｎｓｔａｎｔ  ｂａｌａｎｃｉｎｇ）」を実施する。最高のリスクにおけるＶＭの場合、有効で設定済みの軽減制御処置（ｍｉｔｉｇａｔｉｏｎ  ｃｏｎｔｒｏｌ  ａｃｔｉｏｎ：ＭＣＡ）が評価され、ＭＣＡがリスクを軽減する場合、ＭＣＡが実行されてもよい。リスクオーケストレータ１０６は、ユーザに包括的な見解を提供して（たとえば、ネットワーク１１２上のウェブブラウザによってアクセスされるグラフィカル・ユーザ・インターフェースを介して）各脅威グループ、各リスク管理された仮想マシンおよび全体としてのシステムに対する現在のリスク、ならびに実行済みまたは実行中である現在または最新のＭＣＡを示す。
【００２４】
一実施形態において、リスク管理された各ＶＭに関連するリスクは管理者によってまたは方針に従って選択される可能性のある大域的閾値と比較される。ＶＭが閾値を超える関連リスクを有する場合、有効で設定済みのＭＣＡはリスクが軽減されうるかを判断する必要がある。リスクが軽減されうる場合、「最良の」ＭＣＡが実行される。一部のＭＣＡは仮想インフラストラクチャマネジャ１１０の支援を必要とする場合があり、その場合、リスクオーケストレータ１０６は要求を仮想インフラストラクチャマネジャ１１０に送り、この後、仮想インフラストラクチャマネジャ１１０はホスト１０２の関係のある一つ（複数）に指示を出すことによってＭＣＡを実行する。
【００２５】
ＭＣＡの例は、（１）現在のホストからターゲットホストへのＶＭのマイグレーションまたはライブマイグレーション、（２）ＶＭのスナップショットの保存、（３）ＶＭのサスペンド、（４）ＶＭの電源遮断、（５）ホストの再起動、（６）高い可用性（ａｖａｉｌａｂｉｌｉｔｙ）の実現、（７）災害回復保護の実施、および（８）障害迂回保護を提供するためのシャドウＶＭの実装を含むがこれらに限定されない。
【００２６】
例示的なＭＣＡに関して、リスク管理された構成要素に関連するリスクが許容されえないときリスク回避が合理的戦略であることを理解されたい。たとえば、リスク管理された特定の構成要素は、急に利用できなくなってはならない重要なサービスに関与している可能性がある。しかし、マシンが順序付けられた既定の方法で停止されうる場合、ダウンタイムが許容される可能性がある。このような場合、ＶＭをマイグレーションすることによってＶＭのリスクが軽減されえない場合、システム管理者はＶＭを停止すべきであると判断してもよい。この場合、管理者はこれらの状況でリスクは許容されるべきであるというよりも回避されるべきであると判断している。
【００２７】
ＶＭをマイグレーションすることは、ＶＭを現在のホストからターゲットホストに移動することを意味する。ライブマイグレーションは、稼働中に有意なダウンタイム、すなわち中断なしでＶＭを移動することを意味する。マイグレーションまたはライブマイグレーションの場合、ターゲットホストが現在のホストよりも低いＤＴＰを有する場合、そのＶＭに関連するリスクはこのようなマイグレーションによって軽減されうる。
【００２８】
ＶＭのスナップショットの保存はＶＭのチェックポインティングを含み、したがって、そのディスク状態およびシステム状態（メモリ、プロセッサ状態など）が同じホストまたは異なるホストで復元されてＶＭの実行時に現在の点から再起動されうる。ＶＭのサスペンドはＶＭの簡単なスケジューリング解除（ｄｅ−ｓｃｈｅｄｕｌｉｎｇ）を含む。ＶＭのサスペンドは、他のＭＣＡと関連して選択されるとき実用に適ったＭＣＡである可能性がある。たとえば、ＶＭのスナップショットを保存してＶＭをサスペンドし、その後ホストを再起動して保存されたチェックポイントから、しばらく経って、たとえば、脅威が弱まったときに、ＶＭを復元して再起動したい場合がある。
【００２９】
ＶＭの電源遮断は、ゲスト・オペレーティング・システム内での電源遮断手順の開始を必要とする。ＶＭは物理的な電源を有していないので、ＶＭに関連する用語「電源遮断（ｐｏｗｅｒｉｎｇ  ｄｏｗｎ）」はゲスト・オペレーティング・システムの電源遮断手順の実行およびその後のＶＭの電源遮断動作のシミュレーション、すなわち、ホスト上で動作する他のＶＭへの物理資源（すなわち、メモリなど）の解放を必要とする。最新のオペレーティングシステムは、データの喪失を防止するためにスレッドを閉じてバッファリングされたデータをディスクなどに書き込む順序付けられたシャットダウン手順を有する。ホストの電源遮断および再起動は、ＶＭのサスペンドまたは電源遮断およびその後のホスト・コンピュータ・システムの物理的な再起動を必要とする。
【００３０】
高い可用性は、ホスト空き容量の提供、ＶＭの周期的なチェックポインティング、および機能していることを確認するためのホストの監視を含み得る。ホストがハートビート（ｈｅａｒｔｂｅａｔ）を提供しないか、またはオフラインにすることが決定される場合、ＶＭはホスト空き容量の最新のチェックポイントから最小ダウンタイムで再起動される。災害回復は、遠隔地における仮想インフラストラクチャを再現することによって自動的に（または手動で）遠隔地におけるデータセンタ全体（またはその一部）を再起動する。ＶＭｗａｒｅ，Ｉｎｃ．からのＶＭｗａｒｅ（登録商標）フォールト・トレランス（Ｆａｕｌｔ  Ｔｏｌｅｒａｎｃｅ）を用いてシャドウＶＭが実現されてもよく、その場合、一つ以上のＶＭの一次ホスト上での実行は第２の物理ホスト上でシャドウされうるので、一次ホストが機能しなくなると、第２の物理ホスト上で実行するシャドウＶＭが顕著または有意なダウンタイムなしで肩代わりする。
【００３１】
一実施形態において、ホストは脅威グループとして構成される。各脅威グループは、特定の脅威に関して脅威グループ内のホストが同様に脆弱であるように、同様の状況にあるホストを含む。脅威グループは重複してもよく、したがって、各ホストは、その物理的位置または構成に応じて複数の脅威グループに属してもよい。たとえば、特定室内の最下ラックのすべてのホストは、水に対して脆弱である（たとえば、破裂パイプや機能不良の空調システムによって生じる可能性がある）ので、ひとつの脅威グループに割り当てられてもよい。同じホストは室内のすべての他のホストとともに、室内の温度変動に対して脆弱であるので異なる脅威グループに属してもよい。
【００３２】
すべての既知の脅威およびこれらの影響は、一つの意思決定プロセスに基づいて組み合わされてもよい。ホストのダウンタイム確率は、同時に多数の脅威を考慮しながら比較されうる。たとえば、ホストが一部のファンの故障を表示しているとしよう。総合的な障害迂回解決策（たとえば、ＶＭｗａｒｅ（登録商標）フォールト・トレランス（Ｆａｕｌｔ  Ｔｏｌｅｒａｎｃｅ））はＶＭを異なるホストに迂回しようとするかもしれないが、その異なるホストはより高いダウンタイム確率を有しているかもしれない。第２のホストが許容し難い湿度レベルに直面する室内にある場合、ＩＴリスク管理解決策は、各ホストのＤＴＰを比較して迂回がリスクを下げるどころかリスクを高めるであろうと判断するので、切り換えようとする迂回の決断を無効にするかもしれない。
【００３３】
システム内の他の構成要素と比べた構成要素の重要性を識別するために、影響値がリスク管理された各構成要素に割り当てられる。影響値を用いると、システム、一組のサービス、または個々のＶＭの相対的重要性は、任意尺度の事業目標に照らし合わせて評価されうる。一実施形態において、影響は、リスク管理された構成要素（ＶＭ、サービス、またはシステム）がダウンタイムに直面するときに、財政被害、データインテグリティ、評判など、組織に対して生じる相対的な潜在的損害を表す任意の値である。影響によって、アプリケーション所有者からＩＴ管理者に至るすべての関係者が、同じ測定基準を用いて個々のリスク管理されたＶＭの内容を知らなくても通信することができる。脅威が生じたときの優先処理を設定するためには、リスク管理された構成要素の相対的重要性について一致を見れば十分である。影響は、任意に、すなわち、管理者の知識と経験に基づいて、またはある管理方針に従って（たとえば、ユーザグループ、機能、アクセス頻度などに基づいて）、個別に設定されうる。
【００３４】
図３は、図１および２を参照して前述したシステムを用いて組織のリスクを管理するリスク評価手順を例として示すフローチャート３００を示す。リスク評価の出力は、図４Ａ〜４Ｃを参照して以下で記述されるリスク・マイグレーション・プロセス（ｒｉｓｋ  ｍｉｇｒａｔｉｏｎ  ｐｒｏｃｅｓｓ）中のリスクを軽減または排除する適切な制御を特定し適用するのに役立つ。リスク評価手順は本明細書では必然的に特定の順序で示されるが、ステップは任意の実用に適った順序で実施されてもよいことを当業者は理解するであろう。
【００３５】
リスク評価手順は、開始ブロック３０１に示されるように始まり、工程３０２に進み、そこでシステムが特徴付けられる。具体的には、システムを構成する資源および情報とともにシステムの境界が識別される。この工程において、リスクを定義する必須情報のみならずリスク評価プロセスの範囲が定義される。一実施形態において、方法によって管理者はサービス、対応する仮想マシン、およびＩＴシステムを構成する対応ホストまたはリスク管理されるホストの一部を識別することができる。
【００３６】
工程３０４において、すべての既知の脅威源が識別される。脅威とは、ホストまたはＶＭに脆弱性を発現させる脅威源の能力によってホストまたはＶＭにダウンタイムをもたらす脅威源の潜在力である。例は、コンピュータ装置を有する部屋を通る送水管であってもよい。送水管は破裂して部屋の床の近くや部屋に沿ったすべてのコンピュータをオフラインにする可能性がある。送水管は近くのコンピュータシステムに水を吹き付けて部屋を水浸しにする可能性があり、かつコンピュータシステムは湿気に対して脆弱であるので、送水管は湿気に対する脆弱性をコンピュータに発現させることができ、したがって、コンピュータに脅威を与える。このため、脅威は、偶然にまたは意図的に利用されうる具体的な弱点（脆弱性）をうまく発現させるための具体的な脅威源の潜在力である。
【００３７】
工程３０６において、工程３０２において特徴付けられるシステムに対する脆弱性が識別される。脆弱性は、脅威源に対する弱点または影響の受け易さである。コンピュータ（ホストなど）は極端な温度、湿度、物理的損傷、ハッカー、ネットワーク接続性の不具合、電源変動または停電などに対して脆弱であることが一般に知られ理解されている。解明可能なすべての脆弱性を識別するために解析される可能性のあるホストの物理的環境に基づいて新たな脆弱性が見つかる可能性がある。一実施形態において、方法によって、管理者はリスクオーケストレータの進行しているリスク評価の一環として追跡され、表示によって識別される任意数の脅威源を含めることができる。
【００３８】
一実施形態において、同じ脅威源によって影響を受ける可能性のあるシステム構成要素を集約する脅威グループが定義されてもよい。特定の脅威がダウンタイムをもたらす可能性およびその他の検討事項は、工程３１０を参照して以下に記述されるように、脅威源の値と脆弱な構成要素のダウンタイム確率との間の変換に組み入れられてもよい。変換は、特定脅威の状態から脅威に関連する脅威グループ内のホストの対応するダウンタイム確率へのマッピングであると考えられてもよい。
【００３９】
工程３０８において、工程４０６において識別される脆弱性を脅威が発現させる可能性を最小化または排除するために、適切または有効な軽減制御処置（ＭＣＡ）が識別される。一実施形態において、管理者はリスクオーケストレータ１０６がその後のリスクマイグレーション段階において選定しうるＭＣＡの選択肢を事前に定義する。リスクを軽減するための処置に関する一組のルールまたは勧告が設定される。ルールは、各脅威グループ、または個々のリスク管理された構成要素に対して大域的に実施されてもよい。ルールは、たとえば、最大リスク軽減に対して有効かつ設定済みのＭＣＡを優先的に実施してもよく、または十分なリスク軽減のためにシステムに対して最小の費用または擾乱（ｄｉｓｔｕｒｂａｎｃｅ）で実施されてもよい。
【００４０】
工程３１０において、確率尺度が定義され、さらに特定脅威状態から確率尺度上の位置への変換が定義される。一実施形態において、確率尺度は、ダウンタイム（またはデータの妥協）の可能性がないことを表すゼロからシステムダウンタイム（またはデータの妥協）の強い可能性を示す１まで伸びる。可能性の決定では、識別された脅威、システムの脆弱性の性質、ならびに現在の制御の存在および有効性を考慮する。可能性を導く一般的な方法は、イベントツリー解析（Ｅｖｅｎｔ  Ｔｒｅｅ  Ａｎａｌｙｓｉｓ：ＥＴＡ）、フォルトツリー解析（Ｆａｕｌｔ  Ｔｒｅｅ  Ａｎａｌｙｓｉｓ：ＦＴＡ）、および故障モード影響解析（Ｆａｉｌｕｒｅ  Ｍｏｄｅｓ  ａｎｄ  Ｅｆｆｅｃｔｓ  Ａｎａｌｙｓｉｓ：ＦＭＥＡ）を含むがこれらに限定されない。これらの解析法は、リスク管理の分野でよく理解されている。
【００４１】
工程３１２において、定性値または定量値を用いて悪影響マグニチュードスケールが定義される。また、リスク管理された構成要素の各々に対する悪影響値が決定される。前述のように、影響は、構成要素が故障する、または何らかの方法で妥協される場合に生じる組織への損害の観点から見た構成要素（ホスト、ＶＭ、サービス、またはシステム）の重要性の尺度である。一実施形態において、管理者は、尺度の単位、最小値および最大値、ならびにその尺度のレベルを定義する。
【００４２】
上記の工程が実施されると、脅威源インジケータ出力をダウンタイム確率、リスク管理された構成要素に対応する影響値、リスク閾値またはターゲットリスク、軽減制御処置ルールなどに変換する方法を含む得られる情報がリスクオーケストレータ１０６に入力され、リスクオーケストレータ１０６はそれに応じて以下に記載されるような確立されたＩＴリスク管理戦略を実施する。この後、手順は完了ブロック３１４によって示されるように終了する。
【００４３】
図４Ａ、４Ｂ、４Ｃは、システム１００のリスク管理された構成要素に対するリスクを軽減する、リスクオーケストレータ１０６（図１、２）によって実施され得る手順を例として示す。
【００４４】
図４Ａは、ホストのダウンタイム確率（ＤＴＰ）を計算する事例的方法を示す。手順は、開始ブロック４０２によって示されるように始まり、工程４０４に進み、そこで脅威表示メッセージを受信する。一実施形態において、脅威表示メッセージはウェブ・サービス・インターフェースを用いてＨＴＴＰまたはＨＴＴＰＳ上で受信するフォーマットされたＸＭＬメッセージである。図５Ａおよび５Ｂは、ＸＭＬでフォーマットされた例示的な脅威表示メッセージ５１０、５２０である。各脅威表示メッセージは、固有の識別子または特定脅威に対する記述的ラベルを含む。図５Ａにおいて、たとえば、脅威インジケータは「ＴＩＮＤ＿Ｔ＿Ｌ１」とラベルが付けられ、これは、たとえば、部屋（「ＬＡＢ１」）内の温度センサ（「Ｔ」）を指している場合である。さらに、脅威表示メッセージは値を提供する。図５Ａで表されるＴＩＭの場合、値は７８であり、これは華氏で温度を識別する（摂氏２６°Ｃに等しい）。ある期間にわたって処理されるＴＩＭの量を制限するために、ダンプニング（ｄａｍｐｅｎｉｎｇ）およびフィルタロジックが使用されうる。ダンプニングは、比較的短期間にわたり同じ脅威源に関する大量のＴＩＭすべての処理を防止する。影響を与えてはならない特異でかつ一時的な値（スパイク）が報告されるのを防止するためにフィルタ処理が採用されてもよい。
【００４５】
図４Ａを参照すると、工程４０４の後、手順は工程４０６に進み、そこで脅威グループと変換方法を識別するために脅威グループ表にアクセスする。脅威グループ表は、データベース９０に蓄積してもよい（図１、２）。一実施形態において、各ＴＩＮＤは、単一の対応する脅威グループに割り当てられる。さらに、たとえば、冗長な脅威インジケータを提供しそれに応じてＴＩＮＤの信頼性を向上するために、特定脅威に対して複数のＴＩＮＤが割り当てられうる。表１は、複数部屋内のホストと種々のセンサに対する脅威グループ表を例として示す。表１は、以下で図６を参照してさらに詳しく議論される。
【００４６】
工程４０６の後、工程４０８に従って、脅威グループ表から検索された変換法が工程４０４で受信したＴＩＭに適用されて脅威グループ内のホストに適用されるダウンタイム確率を得る。ダウンタイム確率（ＤＴＰ）は、所与のホストが所与の脅威の結果として機能しなくなる可能性を表す値である。ＤＴＰ変換法は、リスクオーケストレータで受信したＴＩＮＤ値をリスクオーケストレータの確率尺度に従ってダウンタイム確率値に変換する方法である。各脅威グループは、その関連するＴＩＮＤの各々に対してダウンタイム変換法を有する。変換法は、スクリプトまたは他の符号化方式を用いて符号化された任意のアルゴリズムであってもよい。変換法は、システム管理者によって創出または変更されてもよく、システム全体およびその個々の部分がダウンタイムに直面する可能性のある時期と理由についてシステム管理者が有する知識を実現する論理およびルールの少なくとも一方として実施されてもよい。特定の脅威状態に対応するＤＴＰを確立するために実験的証拠が追加的に採用されてもよい。一実施形態において、各変換法は、システム管理者によって書かれリスクオーケストレータ１０６に「プラグイン」されてもよい。管理者／ユーザが特定の脅威インジケータ／脅威グループに対する適切な変換法を簡単に選択できる変換法のライブラリが創出または提供されてもよい。
【００４７】
特定の脅威表示（すなわち、対応する脅威グループ内のホスト）によって影響を受ける各ホストに対するダウンタイム確率を取得した後、手順は工程４１０に進む。工程４１０において、ホストＤＩＰ表は工程４０８で得られたＤＴＰで更新される。
【００４８】
いかなる脅威源もホストのダウンタイムを招く可能性のあるホストの脆弱性を独立に発現させる。しかし、各ホストは複数の脅威を受ける可能性があり、工程４０８で決定されるダウンタイム確率は工程４０４で受信したＴＩＭで識別される一つの脅威から得られるダウンタイム確率にすぎない。工程４１２において、各ホストでは、「ホストＤＴＰ」がそのホストに対するホストＤＴＰ表に入力された個々のＤＴＰから計算される。一実施形態において、適用される式は式１で示される。
【００４９】
ＤＴＰＨＯＳＴ＝１−Πｉ＝１…ｎ（１−ＤＴＰＴＩＮＤｉ）    （式１）
式１において、ＤＴＰＨＯＳＴはホストのダウンタイム確率であり、ＤＴＰＴＩＮＤｉは脅威インジケータｉから得られるダウンタイム確率である。式１は次式に拡大されてもよい。
【００５０】
ＤＴＰＨＯＳＴ＝１−（１−ＤＴＰＴＩＮＤ１）（１−ＤＴＰＴＩＮＤ２）…（１−ＤＴＰＴＩＮＤｎ）    （式２）
各ホストに対するすべての脅威から得られるホストＤＴＰでＤＴＰ表を更新した後、手順は工程４１４に示されるように終了する。図から分かるように、各脅威は脅威に対応する脅威グループの各ホストに対して対応するＤＴＰをもたらす。脅威グループ内のホストは異なる脅威グループに属してもよく、したがって、各ホストはそのホストに対するすべてのＤＴＰの組合せである固有のホストＤＴＰを有しうる。フローチャート４００に示される方法は、ＤＴＰに着信する到着脅威表示メッセージを決定し、この後、ＤＴＰは各ホストのＤＴＰと組み合わせられてホストＤＴＰを得て、データベース９０内のＤＴＰ表に蓄積される（図１、２）。
【００５１】
図４Ｂは、各リスク管理された構成要素に対するリスクを識別する手順を例として示すフローチャート４３０を示す。本例では管理された構成要素が仮想マシンであるが、サービス（これは、複数の仮想マシンまたは仮想マシンと他の構成要素の組合せに依存する場合がある）、ホストなどの他の構成要素に関するリスクは同様に計算されてもよいことに留意されたい。手順は、開始ブロック４３２によって示されるように始まり、工程４３４に進み、そこでリスク管理された第１のＶＭが識別され、これに対して工程４３６〜４４０が実行される。
【００５２】
工程４３６において、現在のＶＭに対するホストＤＴＰ（すなわち、現在のＶＭが動作しているホストに関連するホストＤＴＰ）がＤＴＰ表から検索される。この後、工程４３８において、現在のＶＭに関連する影響がデータベース９０から検索される。図３を参照して前述したように、各ＶＭの影響は、組織に対するＶＭの相対的重要性の表示であり、方針に従って、またはシステム管理者によって手作業で設定される。この後、手順は工程４４０に進み、そこで各ＶＭに対するリスクがホストＤＴＰと影響との関数として計算される。一実施形態において、リスクは式３で示されるように単にホストＤＴＰと影響の積であるが、結果は当業者が気付くように様々な方法で正規化または拡大縮小されてもよい。
【００５３】
リスクＶＭ＝ホストＤＴＰ×影響ＶＭ    （式３）
工程４４０の後、手順は工程４４４に進み、そこで関連するリスクがまだ計算されていない残りのリスク管理されたＶＭがあるかどうかを判断する。残りのリスク管理されたＶＭがあれば、手順は工程４４２に進み、そこで次のリスク管理されたＶＭを選択し、手順は工程４３６に戻る。すべてのリスクのリスク管理されたＶＭでそれらの対応する関連リスクが計算されると、手順は工程４４６に進む。
【００５４】
工程４４６において、システムリスクが計算される。一実施形態において、システムリスクは、式４に示されるようにリスク管理されたＶＭの各々に関連するリスクの和である。
【００５５】
リスクＳＹＳ＝Σｉ＝１…ｎ（リスクＶＭｉ）    （式４）
用語「システムリスク」はすべての脅威に関してその現状のＩＴシステムがもたらす組織へのリスクを指すものと理解されたい。システムリスク（リスクＳＹＳ）が計算された後、手順は完了ブロック４４８で示されるように終了する。サービスに関連するＶＭのサブセットのみが計算に含まれることを除いて、複数のＶＭに依存するサービスに関連するリスク値はシステムリスクと同様に計算されてもよい。この後、ＭＣＡは各サービスに対して独立に設定されてもよい。ホストＤＴＰは上記の方法で計算されるが、ホストＤＴＰに関する式（式１）を上記の式３に代入して次式を直接得ることももちろん可能である。
【００５６】
リスクＶＭ＝影響ＶＭ（１−Πｉ＝１…ｎ（１−ＤＴＰＴＩＮＤｉ））    （式５）
図４Ｃは、図４Ｂに関して前述したようにリスクが計算された時点で、リスク管理された構成要素に対するリスクを軽減する方法を例として示すフローチャート４６０を示す。無リスクのＩＴシステムはなく、さらにすべての実施済み制御が、対処しようとするリスクを完全に排除しうるわけではないことを当業者は理解するであろう。残存リスクは、ＩＴリスク管理プロセスにおける重要な測定基準である。残存リスクは、組織における適切な利害関係者によって合意されてもよい。ＩＴシステムが機能するようになる前に残存価値への合意に対して責任が取られる。可能であれば、リスクレベルが合意された残存レベル以下に低下するまで軽減処置は続くべきである。
【００５７】
前述のように、軽減制御処置（ＭＣＡ）は、リスク管理された構成要素に関連するリスクを軽減しようとして、仮想マシン、仮想マシンのグループ（仮想サービス）、ホスト、またはシステムに適用されうる処置である。リスクオーケストレータ１０６（図１、２）は、構成要素のリスクを軽減しようとして実行する可能性のあるＭＣＡの大域的リストを維持してもよい。このリストは、所定のＭＣＡからなってもよく、管理者によって創出され追加された付加的なカスタムＭＣＡからなってもよい。管理者は、リスク軽減戦略に基づいてＭＣＡを選定し、仮想マシン、ホスト、またはシステム全体に適用する。図４で以下に示される構成例は、図５Ａ〜５Ｄを参照して以下で議論される。
【００５８】
一実施形態において、自動、手動、および半自動の三種類の軽減モードが可能である。自動軽減では、管理者が事前に設定したＭＣＡがリスクを許容レベルまで軽減しようとする。手動軽減では、リスクオーケストレータが軽減を提案し、管理者がＭＣＡを続けるために必要とされる処置を決定する。半自動軽減では、方法は設定可能な所定期間中手動で操作する。この期間後に管理者による決定がなければ、システムは自動モードに切り換わる。
【００５９】
自動モードにある間、方法は、処置に関して識別された仮想マシンにＭＣＡを適用する試みとしてシリアルおよびパラレルの二つのオプションを有する。シリアルオプションにある間、所定のＭＣＡが最高のリスクのＶＭに適用され、この後、ＭＣＡがうまく適用されている場合またはすべてのＭＣＡが機能していない場合にのみ、方法は次のＶＭに進む。リスクオーケストレータは、各ＭＣＡが取られた後にリスク評価を再計算しうる。パラレルオプションを採用するとき、リスク軽減に必要と判断される複数の所定のＭＣＡが開始され同時に実行される。
【００６０】
さらに、一実施形態において、閾値ベースおよび一定バランシングの二つの基本的な軽減戦略があってもよい。閾値ベース軽減において、所定のリスク閾値が交差しているときＭＣＡが取られてもよい（可能な場合）。一定バランシング軽減を用いるとき、リスクは常に平衡していていずれかの時点で仮想マシンおよびシステムにとって最小限のリスクを実現する。
【００６１】
図４Ｃに示される手順は、開始ブロック４６２によって示されるように始まり、工程４６８に進み、そこで前述のような適切な方針がシステムのリスク管理された構成要素に適用される。たとえば、閾値ベースのアプローチは、いずれかのＶＭ（または他のリスク管理された構成部品）が閾値リスクを超える関連リスクを有するかどうかを識別する。管理された各構成要素に関連するリスク値はリスク管理された構成要素の不具合に起因する異なる悪影響を既に考慮に入れているので、閾値リスクは大域的閾値であってもよい。方針が一定バランスリスクであれば、システムは最高の関連リスク値を有する管理された構成要素を識別してリスク軽減をその構成要素に適用するだけでよい。
【００６２】
工程４７０において、工程４６８で適用された方針に従っていずれかのＶＭがリスク軽減を必要とするかどうかが判断される。必要としなければ、手順は、工程４７２に進み、システムの残存リスク（ＲＩＳＫＳＹＳ）がシステムリスク閾値と交差しているかどうかを判断する。システムリスクは、先に説明したように式４を用いて計算されてもよい。肯定であれば、方法は工程４７４に進み、さもなければ手順は工程４６８に戻る。
【００６３】
工程４７４において、試行される有効なシステムＭＣＡがあるかどうかが判断される。有効なシステムＭＣＡは、全体としてシステムに関連するリスクを軽減するためにあらかじめ設定されて、まだ試行されておらず成功する見込みがあり、成功すればシステムに対するリスク、すなわち、ダウンタイムの大きさを軽減することになるＭＣＡであってもよい。有効なＭＣＡが存在すれば、手順は工程４７６に進み、そこで方法は最高の関連優先順位を有する有効なＭＣＡを試行して、そのＭＣＡに試行されたものとしてマークを付ける。この後、手順は工程４７８に進み、そこで工程４７６において試行されたＭＣＡが成功したかどうかが判断される。ＭＣＡが成功していなければ、手順は工程４７４に戻り、そこで別のＭＣＡが有効であるかどうかが判断される。ＭＣＡが成功裡に終了すると、手順は工程４８０に進み、そこでホスト、ＶＭ、および脅威グループに関係する測定値を含むリスク測定値がリフレッシュまたは再計算される。工程４８０の後、手順は工程４６８に戻る。
【００６４】
ここで図４Ｃの右側を参照すると、ＭＣＡを必要とするＶＭがあるとき、手順は工程４７０から工程４８２に進み、そこで最大関連リスクを有するＶＭが識別されて選択される。この後、手順は工程４８４に進み、そこで試行すべき有効なＶＭ  ＭＣＡがあるかどうかが判断され、有効なＶＭ  ＭＣＡがある場合に方法は工程４８６に進む。有効なＭＣＡがなければ、手順は工程４７０または４７２に戻る。現在のＶＭに対する有効なＭＣＡは、まだ試行されておらずＶＭの関連リスクを軽減することになり成功する見込みのあるＭＣＡである。たとえば、ＭＣＡがＶＭをターゲットホストにマイグレーションしている場合、より低いＤＴＰを有する有効なターゲットホストがなければＭＣＡは有効でない。工程４８６において、システムは、最高優先順位のＭＣＡを試行し、試行されたものとしてＭＣＡにマークを付ける。
【００６５】
どのＭＣＡを実施すべきか、または特定のＭＣＡをどのように実行すべきか（たとえば、どのターゲットにＶＭを送るべきか）に関する選択は、様々な方法で行なわれてもよい。一実施形態において、費用便益分析が実施される。たとえば、特定のＭＣＡを特定の方法で実施する際に伴う費用や擾乱が識別されうる。費用は、ネットワーク帯域幅、記憶装置の影響、およびプロセッサ負荷などに関して定量化されうる。高いＣＰＵ使用率およびその容量に近い記憶装置使用率を有する遠く離れたホストに対してよりも、低いＣＰＵ使用率と多くの予備記憶装置を有する近くのホストに対してＶＭをマイグレーションする方が「費用がかからない」かもしれない。同様に、より十分に利用されているホストか、または動作中のより多くのＶＭを有するホストにＶＭをライブマイグレーションする方が、より少ない動作中のＶＭを有する別のホストにＶＭをライブマイグレーションするよりもＶＭに擾乱を引き起こす可能性がある。
【００６６】
ＶＭをマイグレーションすることの便益には、その関連リスクを軽減することが含まれる。しかし、費用便益分析を実施するときに他の便益が式の一部として考慮されてもよい。たとえば、特定のＶＭがデータサーバまたは記憶装置などの特定資源に頻繁にアクセスする場合、特定のＶＭを資源の近く（すなわち、資源まで最短のネットワーク経路を有するホストに）に保ちまたは移動して、待ち時間とルーターおよびスイッチへの負荷とを抑制することに対する便益があるかもしれない。
【００６７】
したがって、工程４８６において、どのＭＣＡを実施すべきかおよびそれがどのように実行されるべきかに多くの方針を考慮することが役立つかもしれない。管理者はリスク軽減を強調するための選定をしてもよく、その場合、最大のリスク軽減を有するＭＣＡが選択されることになる。したがって、ＶＭをマイグレーションするターゲットホストを選択するとき、最低のダウンタイム確率を有するホストが選択されるかもしれない。しかし、好ましい一実施形態において、十分に低いダウンタイム確率を有するすべてのホストを識別してＶＭに関連するリスクを閾値以下にし、さらにこれらのホストの中からシステムに対して最低の費用または擾乱を有するホストを選択することも可能である。
【００６８】
選択されたＭＣＡが工程４８６において実行された後、手順は工程４８８に進み、そこで工程４８６において試行されたＭＣＡが成功裡に終了したかどうかが判断される。成功裡に終了していれば、手順は工程４９０に進む。さもなければ、手順は工程４８４に戻る。工程４９０において、ホスト、ＶＭ、および脅威グループに関係するリスク測定値を含む、リスク測定値がリフレッシュまたは再計算される。この後、手順は工程４７０、または４６８に戻る。
【００６９】
図５Ａおよび５Ｂは、例示的な脅威表示メッセージ（ＴＩＭ）５１０、５２０を示す。一実施形態において、ＴＩＭは拡張マークアップ言語（ｅｘｔｅｎｓｉｂｌｅ  ｍａｒｋｕｐ  ｌａｎｇｕａｇｅ：ＸＭＬ）を用いてフォーマットされ対応する脅威に関する有用な情報を提供するが、伝達されうる情報に制限はない。ＴＩＭが発生した時点で、ＴＩＭはネットワーク接続によって、図２を参照して前述されたようにＨＴＴＰ／Ｓプロトコルを用いて伝送されうる。
【００７０】
リスクオーケストレータ１０６（図１、２）は特定のＴＩＮＤを認識するように設定されてもよく、他の脅威源から送られる値を処理しない。ＴＩＭで送られている脅威値は、図２を参照して前述され表１に例として示される脅威グループのＤＴＰ変換法によって理解可能な単位で送られる。図５Ａを参照すると、各ＴＩＭは、機構がＴＩＮＤ、脅威表示値５１３、送られている値の種類５１４、値を表す単位の記述５１６、ならびにＴＩＮＤそのもの、すなわち、メッセージをトリガした事象およびメッセージの内容に関する追加データ５１８を一意的に識別できる固有の識別子５１２を含んでもよい。
例
この例は、特定組織内の異種のグループまたは個人によって事前に別々かつ独立に管理される、情報技術に関係のない様々な脅威がデータの有効性、データセキュリティ、およびデータ完全性を向上させるために意思決定プロセスの下でどのように結合されるかを明らかにする。
【００７１】
図６Ａは、建物６１０（「建物１」とラベルが付けられた）および建物６３０（「建物２」とラベルが付けられた）に設置され、それぞれ「ＬＡＢ１」、「ＬＡＢ２」、および「ＬＡＢ３」とラベルが付けられた複数の部屋６０２、６２０、６３２間に展開するシステム６００を例として図式的に示す。部屋６０２はホスト６０４およびブレードエンクロージャ６０６を収容し、これはさらにホスト６０８、６１０、６１２を包含する。部屋６２０はホスト６２２、６２４、６２５を含む。建物６３０はホスト６３４を包含する部屋６３２（「ＬＡＢ３」）を含む。各ホストは、対応するＴＩＮＤおよび以下に記載される「変換法」とともに表１に示される一つ以上の脅威グループに属する。ホストは、各々がやはり表１に示される固有の記述的ラベルによって識別される。
【００７２】
【表１】
2011008780.tif 000003
種々のＶＭがｖｍ４１、ｖｍ１２、ｖｍ６２、ｖｍ８２などの種々のサーバ上で実行されている。リスク管理されていないＶＭは、図６において斜線で示されている。図６のホストはネットワーク（図示せず）を介して相互接続されており、したがってＶＭは必要に応じて異なるホストにマイグレーションされうる。表２は、初期におけるコンピュータ・ネットワーク・システム６００および関連するホスト内のリスク管理されたＶＭを示す。図６に示されるすべてのＶＭがリスク管理されているとは限らないが、ＶＭが故障するリスクはないということにはならないことに留意されたい。簡単に言うと、管理者は（理由が何であれ）これらの構成要素をリスク管理しないことに決めている。
【００７３】
【表２】
2011008780.tif 000004
各ホストは脆弱性を示す原因となりしやすい任意数の脅威を有していてもよいが、簡単にするために、この例では以下の脅威を検討するに留める。すなわち、部屋６０２内のすべてのホストは、ＴＩＮＤ６１６によって表示されるその部屋内の温度に対して脆弱である。部屋６２０内のすべてのホストは、ＴＩＮＤ６１０によって表示されるその部屋内の温度に対して脆弱である。ブレードエンクロージャ６０６内のすべてのホストは、ＴＩＮＤ６１４によって表示されるポート機能不良に対して脆弱である。ホスト６２４、６２５は、部屋６２０内の最下ラックに設置され、ＴＩＮＤ６２６によって表示されるその部屋内の水に対して脆弱である。そして最後に、建物６３０内のすべてのホストは無線周波数識別子（ＲＦＩＤ）リーダおよび動きセンサＴＩＮＤ６３４の少なくとも一方によって表示される不正アクセスに対して脆弱である。表１を参照すると、各脅威インジケータは一つ以上のホストが属する対応する脅威グループを有することが分かる。
【００７４】
表３は、管理者によって、または方針に従って各リスク管理されたＶＭに割り当てられた影響値を掲げるＶＭ影響表である。仮想マシン影響尺度は、影響値またはレベルを管理されているシステム内の仮想マシンに割り当てるために、管理者によって使用される様々な範囲に分割されてもよい合意尺度である。一実施形態において、ＶＭ影響尺度は、尺度内に設定可能な最小影響値、設定可能な最大影響値、設定可能な単位型および単位間隔、および設定可能な非重複レベル（範囲）を有する影響値の連続範囲尺度を含む。一実施形態において、影響尺度は、ゼロ（０）から１００までであり、０〜１０が「低」であり、１１〜５０が「中」であり、５１〜１００が「高」である。範囲の低、中、および高は、時間に対して複数のユーザ（管理者）によって適切な影響値をＶＭに常に割り当てられるように、たとえば、スライディングスケール上にカラーコーディングを用いて図で表示されてもよい。
【００７５】
【表３】
2011008780.tif 000005
表４は、システム６００において各リスク管理されたＶＭに対して設定されるＭＣＡ処置を示す表を示す。この例において、すべてのＶＭは、５０の大域的閾値と比較され、したがって、ＶＭのいずれかがその値を超えるリスクを有する場合、対応する設定された処置はそのＶＭに対して実行されうる。各ＶＭを指定された閾値に対して比較することも可能である（ＶＭは既にＶＭの相対的重要性の差を調整する固有の影響値を割り当てられているのでこれは一般に必要でないが）ことに留意する。リスクおよび影響は式３に関して前述のように互いに関係している。ホストＤＴＰは０〜１の値として表されるので、最小および最大リスクが選択された影響尺度の最小および最大影響と一致するように、リスクおよび影響尺度は一致する。しかし、０〜１以外の範囲のダウンタイム確率を表すことは可能であることも認識されたい。この場合、最小リスクは、最小ＤＴＰと最小影響の積になり、最大リスクは最大ＤＴＰと最大影響の積になる。
【００７６】
０〜１のＤＴＰ範囲では、最大リスクで各ホストＤＴＰは「１」に等しくなるので最大限のシステムリスクは影響値の和である。本例において、システムリスク閾値は７０％に設定され、したがって、管理された構成要素のリスクの和がシステムの最大限のリスクの７０％を超える場合、システムに対して設定されたＭＣＡが実行または試行されることになる。表３を参照すると、すべての設定された影響の和は４４４であり、したがって、システム閾値は４４４の７０％、すなわち、３１１になる。
【００７７】
【表４】
2011008780.tif 000006
ＭＣＡの実行順序は表４で優先順位が定められる。すべてのＭＣＡがすべてのリスク管理された構成要素にいつも適用可能であるとは限らないことに留意されたい。表４に示される例において、すべてのＶＭは（１）ＶＭｏｔｉｏｎ（ＶＭマイグレーション）を実施すること、および（２）ＶＭのスナップショットを撮ること、の二つの可能な処置を有する。本明細書には図示されていないが、ＶＭに対して種々のＭＣＡを設定することが可能である。
【００７８】
本例は、表５に示される一連の不運な事象を含む。
【００７９】
【表５】
2011008780.tif 000007
事象１：Ｌａｂ１温度が上昇する 
事象１において、ＴＩＮＤ６１６（図６Ａ）は８５°Ｆの温度を記録し、この情報を直接またはＴＩＭコンバータ８５を介してリスクオーケストレータ１０６に伝送する（図１、２）。ＴＩＭは、図５Ａに示されたものと類似していてもよいが、７８°Ｆではなく８５°Ｆ（２６℃ではなく２９℃）を示している。リスクオーケストレータ１０６は、脅威グループ表（表１）にアクセスし、８５は６５〜１０５の設定範囲のちょうど中間であり、ＴＩＮＤ６１６に関して表１に示されるように範囲は直線性を有するように設定されるので、温度８５°Ｆを０．５のダウンタイム確率に変換する。
【００８０】
表６は、ＤＴＰ表を示しており、これはＴＩＮＤ６１６に関連する脅威グループに属する各ホストに対して新たなＤＴＰ＝０．５を反映するように更新される。得られるホストＤＴＰは、式１を用いて計算され、さらに表６に示される。
【００８１】
【表６】
2011008780.tif 000008
各ホストのホストＤＴＰを決定した後、個々のＶＭに関連するリスクはコンピュータ・ネットワーク・システム６００のリスク表である表７に示されるように決定されてもよい。ＶＭはいずれも表４で設定された閾値を超える関連リスクを有していないので、リスクは許容レベルにあると考えられ、この時点でＭＣＡが取られる必要はない。
【００８２】
【表７】
2011008780.tif 000009
事象２：ブレード・エンクロージャ・アップリンク・ポート不具合
表５に示されるように、事象２において、ＴＩＮＤ６１４は、六つのアップリンクポートのうちの五つが故障していると報告している。リスクオーケストレータは、脅威グループ表（表１）にアクセスして、脅威グループ表が提供するアルゴリズムに従ってこのＴＩＭに対応する関連ダウンタイム確率を発生する。この場合、アルゴリズムは、唯一のアップリンクポートが機能しているときはＤＴＰが「１」に等しいと判断する。表８は、ホストの各々でこの事象の結果的なダウンタイム確率を含む更新されたＤＴＰ表を示しており、ここで、ホストＤＴＰ値は式１を用いて計算され、表９は新たなホストＤＴＰ値に基づく更新されたリスク表を示す。
【００８３】
【表８】
2011008780.tif 000010
【００８４】
【表９】
2011008780.tif 000011
表９にアクセスして最高の関連リスク値を有するリスク管理された構成要素を識別し、関連リスク値を表４で設定された閾値に対して比較する。リスク管理されたｖｍ１１およびｖｍ１３は閾値を超える関連リスクを有し、したがって、表４で設定されたＭＣＡはこれらのリスク管理された構成要素に対して実行されることになる。図６Ｂは、増大した脅威に対するシステムの応答を示す。特に、リスクオーケストレータは、アップリンク誤差に応じてホスト６０８からｖｍ１１およびｖｍ１３をマイグレーションする。
【００８５】
リスクオーケストレータは、まず、最高のリスクを有するリスク管理された構成要素を識別し、その構成要素に対して第１の設定されたＭＣＡを実施する。表９を参照すると、ｖｍ１１は最高のリスクを有しており、表４は第１のＭＣＡがライブマイグレーションであることを示すことは明らかである。したがって、第１の処置はｖｍ１１をブレードエンクロージャ６０６からライブマイグレーションすることである。この例において、方針は、システムに対して最小の混乱または費用でリスクを十分に軽減することである。したがって、リスクオーケストレータ１０６は、潜在的なターゲットを識別し費用／便益分析を実施してライブマイグレーションに対する最も適切なターゲットを決定する。この場合、ｖｍ１１をホスト６０４（「ＨＯＳＴ＿Ｌ１＿４」）に移動すると、ｖｍ１１のリスクがＶＭリスク閾値の値以下に下がるうえに、ターゲットホスト６０４は同じ部屋にあるためにホスト６０４はマイグレーションに要する費用が最少であること（すなわち、最短ネットワーク経路要件など）を表すので、十分なリスク軽減が提供される。ライブマイグレーションはＶＭ１１のリスクを閾値以下にうまく下げることができるので、ライブマイグレーションに対して定義される他のすべてのＭＣＡは試行されないことになる。
【００８６】
ｖｍ１１がマイグレーションされた後、２番目に大きい関連リスクを有するリスク管理された構成要素はｖｍ１３である。ライブマイグレーションは表４でｖｍ１３に対して定義された第１のＭＣＡであるうえに、ライブマイグレーションは構成要素のリスクを設定された閾値（やはり、表４で設定された）の値以下に軽減するので、システムはｖｍ１３を「ＬＡＢ２」内のホスト６２５にライブマイグレーションすることを決定する。このとき、ｖｍ１１は現在のところホスト６０４で動作しており影響を受けるはずはなく、ホスト６２５はそこで実行する仮想マシンを有してしていないので、費用便益分析はｖｍ１３のライブマイグレーションのためのターゲットとしてホスト６２５を選択することがシステム６００への擾乱を最少にするものと判断する。第１のＭＣＡは有効であり成功しているので、表４に示された第２のＭＣＡ、「ＶＭのスナップショットを撮る」は実施されない。
【００８７】
ｖｍ１１に関連するリスクは十分に軽減されて閾値以下に下げられたので、リスク管理された構成要素ｖｍ１１は比較的高い温度にさらされていることにはなるものの「ＬＡＢ  １」から外に移動されなかった。これは、最適なマイグレーションというよりもむしろ十分なマイグレーションの好例である。さらに、方法は、ｖｍ１１を実験室の外に移動しｖｍ１３を同じ実験室に入れておくことによってシステムリスクをさらに軽減することができた。これは、ＶＭリスクを閾値以下に下げたいという要求を実現したことになり、全体として比較的低いシステムリスクを実現したことになる。しかし、方針は、潜在的なマイグレーションターゲットの費用便益を考慮に入れて十分な軽減を実現することであり、最大リスクをまず処理するというガイドラインに従う。これによって、方法は、割合早くより大きなリスクに関係する問題に遭遇することになる。リスク管理された構成要素ｖｍ２１およびｖｍ３２はブレード・エンクロージャ・ポートの不具合の影響を受けるけれども、それらのリスクは管理者の定義と構成要素が組織にもたらす影響に従って軽減を必要としない。一方、システムが一定バランシング戦略に従った場合、システムはこれらのＶＭに関連するリスクも軽減しようとしたであろう。
【００８８】
事後のマイグレーションリスク評価では、ｖｍ１１に関連するリスクが１００から５０に軽減されており、ｖｍ１３に関連するリスクが５４から０に軽減されており、最終的にシステムリスクが２５９から１５４に軽減されている（すなわち、潜在的なシステムリスクの３４％）ものと考えており、これは７０％の閾値の値よりも小さい。
事象３：建物２への不正アクセス探知
表５に示されるように、事象３において、建物６３０（「ＢＵＩＬＤＩＮＧ２」）内の無線周波数識別子（ＲＦＩＤ）リーダおよび行動探知器を備えるＴＩＮＤ６３４は不正アクセスを識別し、ＴＩＭを（直接的または間接的に）リスクオーケストレータ１０６に送る。リスクオーケストレータ１０６は、脅威グループ表（表１）にアクセスし、脅威グループ表によって提供されるアルゴリズムに従ってＴＩＮＤ６３４から受信したＴＩＭに対応する関連ダウンタイム確率を発生する。この場合、アルゴリズムは、脅威グループ内のホストの１００％ダウンタイム確率に対してＴＩＮＤ６３４からの「真の」値を評価する。表１０は、ホストの各々に関するこの（および過去の）事象の結果的なＤＴＰ表と式１を用いて計算されたホストＤＴＰとを示す。表１１は、表８におけるホストＤＴＰと表３から設定された影響値に基づいてリスク管理された構成要素に関する更新されたリスク表を示す。
【００８９】
【表１０】
2011008780.tif 000012
【００９０】
【表１１】
2011008780.tif 000013
表１１から分かるように、ｖｍ８２はここでは５０の閾値よりも高い１００のリスクを有しており、その結果、ｖｍ８２に対して軽減が必要である。さらに、そのシステムリスクは、表４で設定されたシステム閾値、すなわち、３１１と交差しておらず、したがって、システムに関係する軽減は必要でない。最大の関連リスクを有するリスク管理された構成要素はｖｍ８２である。ライブマイグレーションは、表４において設定されたＭＣＡ優先順位に従ってｖｍ８２に対して試行される。十分に軽減されたリスクがもたらされることになるターゲットホストは、部屋６２０（「ＬＡＢ２」）内のすべてのホストと部屋６０２（「ＬＡＢ１」）内のホスト６０４である。最小の擾乱を有するターゲットはホスト６２２であるが、このターゲットはリスク管理された構成要素を有していないためである。したがって、ｖｍ８２は、図６Ｃに示されるようにホスト６２２にライブマイグレーションされる。
【００９１】
ｖｍ８２をホスト６０４にマイグレーションするとリスクが十分軽減されて５０になるが、ホスト６０４にマイグレーションすると、現在重要なＶＭをホスティングしていない（ＩＴリスク管理に関する限り）ホスト６２２にマイグレーションする場合よりもシステムに大きい影響を与えることになる。事後のマイグレーションリスク評価では、ｖｍ８２のリスクが１００から０に軽減されており、システムリスクが２５５から１５５に軽減されている（すなわち、潜在的なシステムリスクの３４％）ものと考えられており、これは７０％の閾値の値よりも小さい。
事象４：部屋６２０内の水を検出
表５に示されるように、事象４において、部屋６２０（「建物１」の「ＬＡＢ２」）内に水センサを備えるＴＩＮＤ６２６は水の存在を感知してＴＩＭをリスクオーケストレータ１０６に送って水を検出したことを示す。リスクオーケストレータ１０６は、脅威グループ表（表１）にアクセスして、脅威グループ表が提供するアルゴリズムに従ってＴＩＮＤ６２６からＴＩＭに対応する関連ダウンタイム確率を発生する。この場合、アルゴリズムは、脅威グループ内のホストの１００％ダウンタイム確率に対してＴＩＮＤ６２６の値を評価する。表１２は、この（または過去の）事象に対する更新されたＤＴＰ表を示すもので、ここでは、ホストＤＴＰが式１を用いて計算される。表１３は、表１２においてホストＤＴＰに基づいてリスク管理された構成要素に関する更新されたリスク表と、表３から設定された影響値を示す。
【００９２】
【表１２】
2011008780.tif 000014
【００９３】
【表１３】
2011008780.tif 000015
表１３にアクセスして、最高の関連リスクを有するリスク管理された構成要素を識別する。ｖｍ１３に関連するリスクは、５０の閾値よりも高い５４に増大されている。その結果、ｖｍ１３に対して軽減が必要である。システム・リスク・パラメータは２４４の現在値を有しており、これはまだシステムリスク閾値の値を超えていない。リスクオーケストレータ１０６は、潜在的なターゲットホストをｖｍ１３のライブマイグレーションに関して識別し評価する。この場合、リスクを十分に軽減することになるターゲットホストは、部屋６３０（「ＬＡＢ２」）内の上部ラックにあるホスト６２２および部屋６０２（「ＬＡＢ１」）内のホスト６０４である。さらに、最小費用と最小擾乱を生じるターゲットはホスト６２２となり、これは同じ部屋内でｖｍ１３を移動すればよいからである。したがって、ｖｍ１３は、図６Ｄに示されるようにホスト６２２に移動される。リスク管理された構成要素ｖｍ６１およびｖｍ６２は、これらの対応する影響についての管理者定義に従って水の脅威源に対して脆弱なままである。一定のリスクバランシング（ｒｉｓｋ  ｂａｌａｎｃｉｎｇ）方針が整っていた場合、これらのＶＭはやはり部屋内の下部ラックから恐らく遠ざけられるであろう。
【００９４】
事後の軽減リスク評価では、ｖｍ１３に関連するリスクが５４から０に軽減されており、システムリスクが２４４から１９０に軽減されている（すなわち、潜在的なシステムリスクの４２％）ものと考えており、これは７０％の閾値の値よりもやはり小さい。
【００９５】
システムリスク閾値を超えると、システムＭＡＣが実行される可能性がある。システムリスクに対する閾値は個々のＶＭへのリスクに対する閾値、またはサービスなどの他のリスク管理された構成要素へのリスクに対する閾値と独立に設定されてもよいことを理解されたい。リスクはそれらの閾値を超えてもリスク管理された構成要素に関連するリスクがさらに軽減されえない場合、システムリスクを超える可能性がある。しかし、リスク管理された構成要素のどれもあるいはごく少数しかそれらの閾値を超えなくても、システムリスクを超える可能性がある。本例において、リスク管理された構成要素に対するリスク閾値が６０に設定され、さらにシステムリスクが５０％に設定される場合、たとえすべてのリスク管理された構成要素がそれらの６０の閾値以下であっても、システムリスクはやはり５０％のシステムリスク閾値を超えている可能性がある。
【００９６】
一実施形態において、システムリスクがシステムリスク閾値を超えるとき、個々のリスク管理された構成要素へのＭＣＡ処置を実行することによってシステムリスクを閾値以下に軽減できるかどうかがまず判断される。これらのＶＭ  ＭＣＡがシステムリスクをシステムリスク閾値以下に軽減する可能性を有する場合、ＶＭ  ＭＡＣが実行され、システムリスクが再評価される。ＶＭ  ＭＣＡがリスクを十分に軽減できない場合、たとえば、表４で指定されるように、一つ以上のシステムＭＣＡが実行される可能性がある。
【００９７】
ＭＣＡは、条件付きまたは無条件で、パラレルまたはシリアルに実行されるように設定されうる。たとえば、ＭＣＡは、過去のＭＣＡが失敗した場合にのみ、あるいは過去のＭＣＡの失敗に関係なく実行されてもよい。複数のＭＣＡが同時に実行されてもよく、あるいは、過去のＭＣＡがあれば各ＭＣＡはそれが終了するのを待ってもよい。図３に示される例において、システムＭＣＡは、過去のＭＣＡが失敗したか否かに関係なく順々に実行される。第１のシステムＭＣＡは、すべてのリスク管理されたＶＭのスナップショットを撮ることである。これは、仮想インフラストラクチャの現在の状態のバックアップを提供する。第２のシステムＭＣＡは、第１のシステムＭＣＡが成功したか失敗したかに関わらず実行されるように設定される。この場合、第２のシステムＭＣＡは、災害回復工程を実施することである。災害回復工程は、遠隔サイトで仮想インフラストラクチャのコピーを開始することであってもよい。一実施形態において、災害回復工程を実施するために、ＶＭｗａｒｅ，Ｉｎｃ．からのＶＭｗａｒｅ（登録商標）Ｓｉｔｅ  Ｒｅｃｏｖｅｒｙ  Ｍａｎａｇｅｒ（商標）が採用されてもよい。最新のデータセンタは、データセンタが、万が一、たとえば、竜巻、停電、またはその他の災害によって徹底的に破壊された場合に備えた災害回復計画を有する。仮想化された資源を用いた災害回復の実施は、全面的または部分的に自動化されうる。一実施形態において、災害回復計画は、所定の閾値を超えるリスクに応じたＭＣＡとしてトリガされてもよい。つぎに、第２のシステムＭＣＡ実施の成否とは関係なく、すべてのホストの停止である第３および最終システムＭＣＡが実行される。
【００９８】
本例は様々なＶＭまたはシステムＭＣＡをトリガする単一の閾値を示すが、種々のリスク閾値用に設定された異なるＭＣＡとともに、複数の閾値が存在するさらに精巧なロジックを有することが可能であることを認識されたい。たとえば、リスクが中レベルに達している場合に実行する一つのＭＣＡと、システム全体のダウンタイムが目前に迫っているような高レベルにリスクがある場合に実行する独特のさらに思い切ったＭＣＡとを想像することができる。
【００９９】
さらに、リスクレベルは動的で常に変化しているので、脅威の厳しさの増減に基づいて適応アプローチが実施されてもよい。たとえば、データセンタの温度が１００°Ｆ（３８℃）であって上昇している場合、関連するダウンタイム確率は温度が１００°Ｆであって低下している場合よりも大きいかもしれない。変化する脅威値を管理するロジックは、前述のように、ＤＴＰ変換アルゴリズムまたはＤＴＰ変換スクリプトを用いて組み込まれうる。
【０１００】
上記の実施形態は主として外的脅威または環境上の脅威を対象としているが、仮想マシンはゲスト・オペレーティング・システムから生じる脅威やＶＭ内から実行するアプリケーションに対してやはり脆弱でありうると理解するべきである。ＩＴリスク管理に関する限り、これらの内的脅威に対応するためにメカニズムの構成要素および工程のどれも変化させる必要がない。したがって、動作環境に関係したリスクに加えて、ＶＭ内から生じるリスクを管理することが可能である。たとえば、重大なデータベースアプリケーションを含む特定ＶＭ内のゲスト・オペレーティング・システムにおいてウイルスが検出されるものと仮定しよう。ウイルスの存在は、ゲスト・オペレーティング・システムのセキュリティが無許可のユーザによって重要データまたはインフラストラクチャ要素にアクセスされうる危険性にさらされていることを示す可能性がある。脅威インジケータは、ウイルスなどのマルウェアがゲスト・オペレーティング・システムに侵入して仮想マシンに関連するリスクを閾値以上のレベルに高めた場合にＴＩＭを発生するように設定されてもよい。ＶＭがダウンタイムに遭遇していなくても、ＩＴリスク管理は、実装された脅威インジケータからダウンタイムの表示を得ることになり、たとえば、ＶＭｗａｒｅ（登録商標）Ｕｐｄａｔｅ  Ｍａｎａｇｅｒを用いてゲスト・オペレーティング・システムにパッチを当てる選定をすることができる。
【０１０１】
リスク管理は、性能の低下を脅威としてとらえることができるのでシステム性能を改善するという副効用を有しうる。たとえば、ＶＭｗａｒｅ（登録商標）フォールト・トレランス（Ｆａｕｌｔ  Ｔｏｌｅｒａｎｃｅ：ＦＴ）は可用性の喪失を解決するように設計される。前述のように、ＦＴにおいて、一次ホスト上で動作する一次ＶＭは、二次ホスト上で動作するシャドウＶＭによって横並び（ｌｏｃｋ−ｓｔｅｐ）で動作される。一次ホストがクラッシュすると、二次ホスト上で動作しているシャドウＶＭは可用性を殆んどまたは全く失うことなく一次ＶＭの機能を直ちに肩代わりする。ＩＴリスク管理に関する限り、ダウンタイムは可用性の低下も対象にするので、ＦＴは種々の一連の問題を解決するためにトリガされうる。一実施形態において、フォールト・トレランスを用いてシャドウＶＭによってバックアップされるＶＭの影響値は、万一、一次ＶＭがシャドウＶＭによって課せられた冗長性に起因してダウンタイムに遭遇した場合に、組織に対する影響（したがって、リスク）の軽減を反映すように調整されてもよい。したがって、この場合、フォールト・トレランスは、ＶＭのダウンタイム確率を軽減することによるよりもむしろＶＭの影響を軽減することによってリスクを軽減するＭＣＡである。別の実施形態において、一次ＶＭのリスクは、一次ホストおよび二次ホストのいずれか低い方のＤＴＰを有するホストのＤＴＰを用いて計算される。
【０１０２】
前述のＩＴリスク管理システムを採用すると、自動化された是正処置を取るとき（または取らないとき）より合理的な判断をすることができる。たとえば、ホストが障害のあるネットワークスイッチにリンクされる場合、これはホスト上で動作する仮想マシンにとってネットワークの遅さとなる。仮想マシンがＦＴペアにおける一次ＶＭである場合、二次仮想マシンが異なるスイッチの背後にあるホスト上で動作していると、たとえ一次ＶＭが可用性の喪失に遭遇していなくてもＩＴリスク管理は動作を二次ＶＭに切り換えてもよい。これは、ホストを脅威グループ内のネットワークスイッチ背後に設置し、性能低下を識別するためにネットワークスイッチをポーリングし、このような性能低下を脅威表示メッセージに変換し、ＦＴ迂回（またはＦＴが有効でなければライブマイグレーション）を設定されたＭＣＡとしてトリガするだけで、すべて前述のメカニズムを用いて行なわれうる。
【０１０３】
本発明の実施形態は携帯端末、マイクロプロセッサシステム、マイクロプロセッサベースまたはプログラマブル家電製品、ミニコンピュータ、メインフレームコンピュータなどを含む様々なコンピュータシステム構成で実施されてもよい。また、本発明は、タスクがネットワークを介してリンクされる遠隔処理装置によって実施される分散コンピューティング環境で実施されうる。
【０１０４】
上記の実施形態を念頭に置いて、本発明はコンピュータシステムに格納されたデータを必要とする様々なコンピュータ実行操作を採用しうることを理解されたい。これらの操作は、物理量の物理的処置を必要とする操作である。本発明の一部を形成する、本明細書に記述される操作のいずれも有用なマシン操作である。また、本発明は、これらの操作を実施するデバイスまたは装置に関する。装置は、専用コンピュータなど、要求される目的に合わせて特別に構築されてもよい。また、専用コンピュータとして定義されるコンピュータは、特殊目的の一部でない他の処理、他のプログラム実行、または他のルーチンを実施することができるが、それでも特殊目的で動作させることができる。あるいは、操作は、コンピュータメモリ、キャッシュに格納された一つ以上のコンピュータプログラムによって選択的に起動または設定される汎用コンピュータによって処理されてもよく、あるいはネットワークを介して得られてもよい。ネットワークを介して得られるデータは、ネットワーク上の他のコンピュータ、たとえば、多数のコンピューティング資源によって処理されてもよい。
【０１０５】
また、本発明の実施形態は、データをある状態から別の状態に変換するマシンとして定義されうる。変換されたデータは、記憶装置に保存され、その後、プロセッサによって操作されうる。プロセッサは、このようにしてデータをあるものから別のものに変換する。さらに、方法は、ネットワーク上で接続されうる一つ以上のマシンまたはプロセッサによって処理されうる。また、マシンは、物理的アクセスを記憶装置に提供し、処理能力を一つ以上のユーザ、サーバ、またはクライアントに提供するために仮想化されうる。したがって、仮想化されたシステムは、一つ以上の汎用マシンとして動作しうるマシンであると考えられるべきであり、さもなければ専用マシンとして構成されるべきである。各マシン、すなわち、マシンの仮想表現は、データをある状態またはあるものから別の状態または別のものに変換することができ、また、データの処理、データの記憶装置への保存、結果の表示、または結果の別のマシンへの伝達を行なうこともできる。
【０１０６】
また、本発明は、コンピュータ可読媒体上のコンピュータ可読コードとして具体化されうる。コンピュータ可読媒体は、データを保存することができ、その後コンピュータシステムによって読み取られうる任意のデータ記憶装置である。コンピュータ可読媒体の例として、ハードドライブ、ネットワーク接続ストレージ（ＮＡＳ）、読取り専用メモリ、ランダム・アクセス・メモリ、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＣＤ−ＲＷ、磁気テープ、およびその他の光および非光データ記憶装置が挙げられる。コンピュータ可読媒体は、コンピュータ可読コードが格納されて分散方式で実行されるようにネットワーク結合コンピュータシステム上に分散されたコンピュータ可読有形的表現媒体を含みうる。
【０１０７】
方法の工程は特定の順序で記述されたが、他のハウスキーピング操作が中間工程で実施されてもよく、あるいは工程がわずかに異なる時間に行なわれるように調整されてもよく、またはオーバーレイ工程の処理が所望の方法で実施される限り処理工程を処理に関連する様々な間隔で行なえるシステムの中で分散されてもよいことを理解されたい。
【０１０８】
前述の発明は理解のし易さを目的として多少詳しく記述されているが、添付の特許請求の範囲内で一定の変更および修正が実施されうることは明らかであろう。したがって、本実施形態は、事例的であって制限的ではないと考えられるべきであり、本発明は本明細書に記載された詳細内容に限定されるものではなく、添付の特許請求の範囲内および均等物内で修正されてもよい。
【符号の説明】
【０１０９】
８０  脅威インジケータ（ＴＩＮＤ）
８１〜８７、６１０、６１４、６１６、６２６、６３４  ＴＩＮＤ
８５  ＴＩＭコンバータ
９０  データベース
１００、６００  コンピュータ・ネットワーク・システム
コンピュータ・ネットワーク・システム
１０２ａ、１０２ｂ、１０５、１０９  ホスト
１０３ａ、１０３ｂ  仮想化ソフトウェア
１０４  仮想マシン（ＶＭ）
１０７  ＶＭ
１０６  リスクオーケストレータ
１１０  仮想インフラストラクチャマネジャ
１１２、１１４ａ、１１４ｂ  ネットワーク
５１０、５１２、５２０  脅威表示メッセージ
５１３  脅威表示値
５１４  値の種類
５１６  単位の記述
５１８  追加データ
６０２、６２０、６３２  部屋
６０４、６０８、６１０、６１２、６２２、６２４、６２５、６３４  ホスト
６０６  ブレードエンクロージャ
６１０、６３０  建物
【図１】
2011008780.tif 000016
【図２】
2011008780.tif 000017
【図３】
2011008780.tif 000018
【図４Ａ】
2011008780.tif 000019
【図４Ｂ】
2011008780.tif 000020
【図４Ｃ】
2011008780.tif 000021
【図５Ａ】
2011008780.tif 000022
【図５Ｂ】
2011008780.tif 000023
【図６Ａ】
2011008780.tif 000024
【図６Ｂ】
2011008780.tif 000025
【図６Ｃ】
2011008780.tif 000026
【図６Ｄ】
2011008780.tif 000027