JP2017034659A - サービス志向ソフトウェア定義型セキュリティのフレームワーク - Google Patents

Abstract

【課題】サービス志向ソフトウェア定義型セキュリティフレームワークのためのコンピュータプログラムを含む、方法、システムおよび装置を提供する。
【解決手段】本システムは、セキュリティ制御デバイスと、一つ以上のアセットと、セキュリティコントローラを含む。セキュリティコントローラは、処理エンジンを含み、処理エンジンは、セキュリティ制御デバイスに対する物理−論理属性マッピングを作成し、セキュリティ制御デバイスに関連付けられたセキュリティサービスディスクリプションを生成し、セキュリティ制御デバイスを登録する。さらに、処理エンジンは、アセットの各々に対する物理−論理属性マッピングを作成し、アセットに対するセキュリティサービス要求事項を生成することによって、アセットを登録する。また、処理エンジンは、サービスに対する要求に基づいてセキュリティサービスのバインディングを生成する。
【選択図】図１

Description

関連出願の相互参照
本出願は、２０１５年６月１２日出願の米国仮出願第６２／１７４，９９０号、および２０１６年５月２６日出願の米国仮出願第６２／３４２，１２８号の利益を主張し、これら出願の双方は参照することにより本明細書に組み込まれる。

技術分野
本出願はネットワークセキュリティに関する。

企業のＩＴインフラストラクチャがより仮想化され、クラウドベースになり、急速に変化するにつれ、従来式のサイバーセキュリティは、それが静的ネットワークアイデンティティに関連付けられ、ステートフルなデバイスに依存しているのでこの傾向にうまく適応できない。一つの例に、クラウド中のＩＰベースのステートフルファイアウォールがあり、いずれかの保護された仮想マシンがクラウドオペレーションのためそのＩＰアドレスを変更すると、期待通りに機能しなくなる。

セキュリティコンフィグレーションを実施する従来式のアプローチは、手作業に大きく依存する。さらに、多くのセキュリティ制御手段がそれらのコンフィグレーションの中でアセットの物理的属性を使用しているので、アセットの物理的属性が変わると、その変化の影響を受ける他のアセットおよび制御手段を識別し、関連するコンフィグレーションを変更するために多くの手作業を必要とする。ネットワークに新規のデバイスが追加され、またはネットワークから既存のデバイスが除去される際にも、セキュリティ制御コンフィグレーションへの手作業による変更が必要となる。

本出願は、ソフトウェア定義型インフラストラクチャに対するセキュリティ制御のためのサービス志向のアプローチに関する。本アプローチは、ソフトウェア定義型セキュリティ原理を導入する。このアプローチは、セキュリティ制御をセキュリティサービスとして表現し、アセットのセキュリティポリシーをサービス要求事項として解釈する。本アプローチは、セキュリティマネジメントおよび制御に監督レベルで対応し、根本的なインフラストラクチャおよびその動的変更からこれらのマネジメントを遮蔽する。本アプローチは、異機種環境クラウドベースまたは従来式環境を横断して、一貫したセキュリティポリシーの執行を助力し、ネットワーク管理者のためにセキュリティマネジメント業務を簡明化する。本出願は、ソフトウェア定義型セキュリティへのサービス志向のアプローチを実装するプロとタイプを説明し、本アプローチに対するいくつかの実際的使用を考察する。

多くの企業は、自社の従来式のＩＴインフラストラクチャをソフトウェア定義型インフラストラクチャ（ＳＤＩ：Ｓｏｆｔｗａｒｅ−Ｄｅｆｉｎｅｄ Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ）に変換することが可能である。ＳＤＩの主要な特徴の中に、ソフトウェア定義型ネットワーク形成、ソフトウェア定義型ストレージ、サーバ仮想化、並びに自動化および制御ソフトウェアがある。これらの技術は、ＳＤＩを、ＩＴアセットおよび機能がオンデマンド方式で定義、生成、変更、およびリサイクされる高度に動的な環境に作り上げる。ＳＤＩのこの動的な性質は、専用のハードウェア機器に伝統的に依存するサイバーセキュリティオペレーションに対し困難を引き起こし得る。専用のセキュリティ機器は、固定されたネットワークトポロジおよび固定ＩＰアドレスなど静的なインフラストラクチャ設定に関連付けられ得る。静的設定への依存は、既存のセキュリティメカニズムの変更または新規メカニズムの展開を困難にする。というのは、かかる変更は、多くの場合、カスケード効果を誘発し、集約的な手動での再構成を必要とするからである。さらに、専用および専売機器の使用は、ベンダーロックインを引き起こし、事業および作業レベルの双方でより高いコストとより大きなリスクとをもたらす。ＳＤＩ環境において、よりフレキシブルで、より機動的で、自動化されたサイバーセキュリティオペレーションを達成するために、セキュリティマネジメントの静的な専用のセキュリティ機器への依存を最小化することが望ましくあり得よう。

本出願は、専売のセキュリティ機能を、包括的セキュリティサービスとして表すことによって、根本的なセキュリティ制御手段からサイバーセキュリティマネジメントを切り離すアプローチ、すなわち、サービス志向ソフトウェア定義型セキュリティ（ＳＯＳＤＳｅｃ：Ｓｅｒｖｉｃｅ−Ｏｒｉｅｎｔｅｄ Ｓｏｆｔｗａｒｅ−Ｄｅｆｉｎｅｄ Ｓｅｃｕｒｉｔｙ）を説明する。ＳＯＳＤＳｅｃは、転換（これは抽象化および／または形成化と言われることもある）、ＡＰＩ活用化、自動化、および統合化などの技法を使用する。ＳＯＳＤＳｅｃでは、セキュリティサービスは、オンデマンドで、見出され、有効化され、そして無効化され得る。ＳＯＳＤＳｅｃは、企業に、簡明化されたマネジメントおよび制御、技術およびベンダー非依存性を含むサイバーセキュリティ、インフラストラクチャダイナミクスへのサポート、並びに増進された機動性の利点を提供する。以降で説明するのは、修正されたセキュリティサービスを用いたソフトウェア定義型インフラストラクチャに対する例示のセキュリティ制御アプローチである。

ソフトウェア定義型セキュリティ（ＳＤＳｅｃ：Ｓｏｆｔｗａｒｅ−Ｄｅｆｉｎｅｄ Ｓｅｃｕｒｉｔｙ）は、ＳＤＩ環境内のセキュリティを改良するためのアークテクチャ面のアプローチである。ＳＤＳｅｃの中核原理は、転換、自動化、制御、スケーラビリティ、フレキシビリティ、可視性、およびＡＰＩ活用化を含む。ＳＤＳｅｃは、従来式の物理的セキュリティ制御手段の代わりに、セキュリティマネジメントタスクを本質的に簡明化するソフトウェアを使うセキュリティ機能を提供する。また、ハードウェアへの依存の排除は、仮想化クラウドインフラストラクチャの変更レベルと歩調を合わせて展開可能なセキュリティをも意味する。

本出願に記載された主題の革新的態様によれば、ソフトウェア定義型セキュリティシステムは、セキュリティ制御デバイスと、一つ以上のアセットと、セキュリティ制御デバイスおよび一つ以上のアセットと通信するセキュリティコントローラと、を含む。セキュリティコントローラは処理エンジンを含み、該エンジンは、セキュリティ制御デバイスに対する物理−論理属性マッピングを作成し、該セキュリティ制御デバイスに関連付けられたセキュリティサービスディスクリプションを生成することによりセキュリティ制御デバイスを登録するように構成される。また、該処理エンジンは、一つ以上のアセットの各々に対する物理−論理属性マッピングを作成し、該一つ以上のアセットの各々に対するセキュリティサービス要求事項を生成することによって、これら一つ以上のアセットを登録するように構成される。また、該処理エンジンは、サービスに対する要求に基づいてセキュリティサービスのバインディングを生成するようにも構成され、処理エンジンは、セキュリティサービスのバインディングをセキュリティ制御コマンドのセットに変換し、そのセキュリティ制御コマンドをセキュリティ制御デバイスに通信するよう動作可能である。

ソフトウェア定義型セキュリティシステムは、以下の随意的特徴の一つ以上を含んでよい。セキュリティ制御デバイスは、ファイアウォールと、侵入検知システムと、アイデンティティおよびアクセスマネジメントシステムと、のうちの一つである。一つ以上のアセットは、サーバと、ＶＰＮクライアントおよびサーバと、外部コンピューティングデバイスと、モバイルコンピューティングデバイスと、のうちの一つを含む。処理エンジンは、セキュリティイベントを識別するデータを受信し、該セキュリティイベントに対して実施するためにセキュリティコントローラに対して一つ以上のアクションを識別するプレイブックにアクセスし、セキュリティイベントに応じて一つ以上のアクションを実施するようにさらに構成されてよい。このセキュリティイベントは、侵入検知制御、ネットワークトポロジ変更、またはサーバ故障からのイベントを含み得る。セキュリティサービスのバインディングを生成するアクションは、セキュリティイベントに応じて一つ以上のアクションを実施することを含むことができる。セキュリティ制御デバイスに対する物理−論理属性マッピングは、該セキュリティ制御デバイスに対するＩＰアドレス−ホスト名マッピングを含むことが可能である。一つ以上のアセットの各々に対する物理−論理属性マッピングは、一つ以上のアセットの各々に対するＩＰアドレス−ホスト名マッピングを含むことが可能である。処理エンジンは、一つ以上のアセットの一つへの物理属性の変更を示すデータを受信するようにさらに構成することができる。一つ以上のアセットの一つへの物理属性の変更を示すデータを受信することに応じて、処理エンジンは、一つ以上のアセットの該一つに対するセキュリティサービス要求事項を識別することが可能で、処理エンジンは、一つ以上のアセットの一つに対するそのセキュリティサービス要求事項に基づいて、一つ以上のアセットの一つに対するセキュリティサービスのバインディングを生成することができる。一つ以上のアセットの一つに対するセキュリティサービスのバインディングは、一つ以上のアセットの一つへの物理属性の変更を示すデータを受信した後、ユーザの入力なしに自動的に生成することが可能である。

この態様の他の実装は、各々が前述のオペレーションを実装するように構成された、対応するシステム、装置、およびコンピュータストレージデバイスに記録されたコンピュータプログラムを含む。

本出願に記述の主題事項の別の革新的な態様によれば、方法は、セキュリティ制御デバイスおよび一つ以上のアセットと通信するセキュリティコントローラによって、セキュリティ制御デバイスに対する物理−論理属性マッピングを作成し、セキュリティ制御デバイスに関連付けられたセキュリティサービスディスクリプションを生成することにより、セキュリティ制御デバイスを登録するステップと、一つ以上のアセットの各々に対する物理−論理属性マッピングを作成し、該一つ以上のアセットの各々に対するセキュリティサービス要求事項を生成することによって、これら一つ以上のアセットを登録するステップと、サービスに対する要求に基づいて、セキュリティサービスのバインディングを生成するステップと、セキュリティサービスのバインディングをセキュリティ制御コマンドのセットに変換するステップと、そのセキュリティ制御コマンドをセキュリティ制御デバイスに伝達するステップと、のアクションを含む。

本方法は、以下の付加的特徴の一つ以上を含んでよい。セキュリティ制御デバイスは、ファイアウォールと、侵入検知システムと、アイデンティティおよびアクセスマネジメントシステムと、のうちの一つである。一つ以上のアセットは、サーバと、ＶＰＮクライアントおよびサーバと、外部コンピューティングデバイスと、モバイルコンピューティングデバイスと、のうちの一つを含む。これらのアクションは、セキュリティイベントを識別するデータを受信するステップと、該セキュリティイベントに対して実施するためにセキュリティコントローラに対して一つ以上のアクションを識別するプレイブックにアクセスするステップと、セキュリティイベントに応じて一つ以上のアクションを実施するステップと、をさらに含む。このセキュリティイベントは、侵入検知制御、ネットワークトポロジ変更、またはサーバ故障からのイベントを含み得る。セキュリティサービスのバインディングを生成するアクションは、セキュリティイベントに応じて一つ以上のアクションを実施するステップを含むことができる。セキュリティ制御デバイスに対する物理−論理属性マッピングは、当該セキュリティ制御デバイスに対するＩＰアドレス−ホスト名マッピングを含むことが可能である。一つ以上のアセットの各々に対する物理−論理属性マッピングは、一つ以上のアセットの各々に対するＩＰアドレス−ホスト名マッピングを含むことが可能である。これらアクションは、一つ以上のアセットの一つへの物理属性の変更を示すデータを受信するステップと、一つ以上のアセットの一つへの物理属性の変更を示すデータを受信することに応じて、一つ以上のアセットの一つに対するセキュリティサービス要求事項を識別するステップと、一つ以上のアセットの一つに対するそのセキュリティサービス要求事項に基づいて、一つ以上のアセットの一つに対するセキュリティサービスのバインディングを生成するステップと、をさらに含むことができる。一つ以上のアセットの一つに対するセキュリティサービスのバインディングは、一つ以上のアセットの一つへの物理属性の変更を示すデータを受信した後、ユーザの入力なしに自動的に生成することが可能である。

この態様の他の実装は、各々が本方法のオペレーションを実装するように構成された、対応するシステム、装置、およびコンピュータストレージデバイスに記録されたコンピュータプログラムを含む。

本明細書に記載の主題事項の一つ以上の実装の詳細が、添付の図面および以下の説明において述べられる。本主題事項の他の特徴、態様、および利点はこれらの説明、図面、および特許請求の範囲から明らかになろう。

アセットとセキュリティサービスプロバイダと間の例示のサービスマッチングプロセスを示す。 例示のソフトウェア定義型環境に配備された、いくつかのレイヤに分解された例示のソフトウェア定義型セキュリティモデルを示す。 サービス志向ソフトウェア定義型セキュリティコントローラおよびその機能素子の例示のアーキテクチャを示す。 セキュリティサービスの例示のクラス図を示す。 同じセキュリティグループ中にあり、相異なる仮想または物理ネットワークに属し得る例示のアセットを示す。 セキュリティサービスのバインディングのクラスおよび三つのサブクラスの例示のクラスおよびメッセージ図を示す。 外部クライアントが仮想プライベートネットワークを介して保護された内部サーバにアクセスしている例示のシステムを示す。 ＳＯＳＤＳｅｃコントローラの一例および例示のテストベッドを示す。 テストベッド中の二つの例示のサブネットを示す。 アクセス制御ルールを設定可能な信頼レベルに基づいて動的に修正する、ソフトウェア定義型ネットワーク設定の技術を使って実装された、例示の隔離サービスを示す。 サービス志向ソフトウェア定義型セキュリティに対する例示のセキュリティ制御手段の登録プロセスを示す。 サービス志向ソフトウェア定義型セキュリティに対する例示のアセット登録プロセスを示す。 サービス志向ソフトウェア定義型セキュリティに対する例示のセキュリティサービス要求プロセスを示す。 サービス志向ソフトウェア定義型セキュリティに対する例示のセキュリティ制御コマンド送信プロセスを示す。 サービス志向ソフトウェア定義型セキュリティに対するネットワーク設定またはセキュリティイベントを受信するための例示のプロセスを示す。 コンピューティングデバイスおよびモバイルコンピューティングデバイスの一例を示す。

図１は、アセットとセキュリティサービスプロバイダと間の例示のサービスマッチングプロセス１００を示す。サービスマッチングプロセス１００は、企業のＩＴインフラストラクチャ環境内で動作され、通常、セキュリティ制御手段（例えば、ファイアウォール１０５、侵入検知システム（ＩＤＳ：ｉｎｔｒｕｓｉｏｎ ｄｅｔｅｃｔｉｏｎ ｓｙｓｔｅｍ）１１０およびアイデンティティおよびアクセスマネジメント（ＩＡＭ：ｉｄｅｎｔｉｔｙ ａｎｄ ａｃｃｅｓｓ ｍａｎａｇｅｍｅｎｔ）を含む）、並びにアセット（保護された内部サーバ３１０、３１５（１１５）、ＶＰＮクライアントおよびサーバ、および外部クライアントを含む）から成る。図１に示された例において、アセット１２０は、サービスマッチングアルゴリズムを実行するＳＯＳＤＳｅｃコントローラ１２５を介し、ファイアウォール、ＩＤＳ、およびＩＡＭからの三つの異なるセキュリティサービスを要求する。

ＳＯＳＤＳｅｃコントローラ１２５は、セキュリティ制御手段のキャパシティをセキュリティサービスとして、およびアセットのセキュリティポリシー／モードをセキュリティサービス要求事項として定義することによって、サイバーセキュリティマネジメントを提供する。しかして、保護対象アセットに対するセキュリティ制御手段を構成するプロセスは、アセットのセキュリティ要求事項を、所与のネットワークドメインにおいて利用可能なセキュリティサービスにバインディング、かかるバインディングをセキュリティ制御のための実際のコマンドに変換するプロセスになる。

全てのセキュリティ制御手段は、特定のネットワーク範囲中の他の当事者によって使われる特定のセキュリティ機能を提供するサービスプロバイダとして表すことができる。例えば、ＬＡＮのファイアウォール１０５は、同じＬＡＮ中の保護対象サーバへの望ましくないトラフィックを阻止できるトラフィックフィルタリングサービスのプロバイダとして表すことが可能である。この場合、保護対象サーバは、それぞれが、どのようなトラフィックを阻止して（または受け入れて）欲しいかを表すそれ自身の固有のセキュリティ要求事項を有する、サービスコンシューマである。各サーバは、ファイアウォールから同じトラフィックフィルタリングサービスを要求するが、そのパラメータが異なり、各サーバに対し相異なるトラフィックがフィルタされる結果となる。同様に、ネットワークベース侵入検知デバイス１１０は、ネットワーク中のそれが保護する全てアセットに対し、侵入検知サービスを提供する。ホストベースの侵入検知システムは、それを実行している同じコンピュータを顧客とするサービスプロバイダである。また、セキュリティサービスは、企業の敷地の外部にいる従業員が使うモバイルデバイスなど、外部のエンティティにも提供することが可能である。この場合、それら携帯デバイスは、まず自己の本人証明をする必要があり、そのセキュリティ要求事項がユーザ情報リポジトリから読み出されることになり、次いでＳＯＳＤＳｅｃが証明済みの携帯デバイスに対して必要なサービスを探索する。これら携帯デバイスユーザへの権限付与は、これらのセキュリティサービス要求事項の適切な明細から得られる。

図１Ａは、例示のソフトウェア定義型環境に配備された、いくつかのレイヤに分解された例示のソフトウェア定義型セキュリティモデル１００ａを示す。いくつかの実装において、調整レイヤ１０５ａはＳＯＳＤＳｅｃコントローラを含む。該コントローラは、アセットのセキュリティモデルを読み取り更新する。また、コントローラは、アセットのセキュリティモデルを執行するために、セキュリティタスクを調整するためソフトウェアおよびハードウェアベースのセキュリティ制御手段、および他の仮想化機能と通信する。該コントローラは、その通信および調整サブシステムと併せ、セキュリティ自動化および統合化を達成するための素子である。ソフトウェア定義型セキュリティモデル１００ａは、インフラストラクチャレイヤ１２０ａを含み、これは物理／仮想インフラストラクチャを含む。また、ハードウェアベースのセキュリティ制御手段も、このレイヤ１２０ａに属する。論理レイヤ１１５ａは、全リソースへの論理参照（ホストアイデンティティ、アプリケーションへの参照など）など、全リソースの論理属性を維持する。いくつかの実装において、これらは、ＩＰアドレスなど一時的アイデンティティを含まなくてもよい。機能レイヤ１１０ａは、ソフトウェア定義型ネットワーク設定（ＳＤＮ：Ｓｏｆｔｗａｒｅ−Ｄｅｆｉｎｅｄ Ｎｅｔｗｏｒｋｉｎｇ）、ソフトウェア定義型ストレージ（ＳＤＳ：Ｓｏｆｔｗａｒｅ−Ｄｅｆｉｎｅｄ Ｓｔｏｒａｇｅ）、ソフトウェア定義型境界（ＳＤＰ：Ｓｏｆｔｗａｒｅ−Ｄｅｆｉｎｅｄ Ｐｅｒｉｍｅｔｅｒ）、および他のＮＦＶを含む、全ての仮想化機能を管理する。また、レイヤ１１０ａは、全てのカスタム化されたソフトウェアベースのセキュリティ制御手段も含む。モデルレイヤ１２５ａは、アセットのセキュリティポリシーおよびセキュリティモデルを管理する。アセットのセキュリティモデルは、適用されるセキュリティポリシーから導出されたルールのセットである。これらのルールは、アセットの論理属性に依存し、しかして、根本的なインフラストラクチャの変化に影響されなくてもよい。

図２は、サービス志向ソフトウェア定義型セキュリティコントローラ２００およびその機能要素の例示のアーキテクチャを示す。サービス志向ソフトウェア定義型セキュリティコントローラ２００は、ネットワーク内のアセットとセキュリティ制御手段とをインターフェース接続し、物理−論理属性マッピング、およびアセットのサービス要求を適切なセキュリティ制御にバインディングするサービスマッチングを提供する。

ＳＯＳＤＳｅｃコントローラ２００は、仮想および／またはソフトウェア定義型インフラストラクチャのセキュリティ問題を取り扱うよう設計されている。これは、セキュリティ制御手段を包括的セキュリティサービスに転換する点で、ＳＤＳｅｃと類似である。アセットは、セキュリティサービスのコンシューマになり、それら自身のセキュリティ必要性に基づいて自分のサービス要求事項を指定し、セキュリティ制御手段は、アセットに包括的なセキュリティ能力を提供するサービスプロバイダになる。ＳＯＳＤＳｅｃは、セキュリティ機器直接への代わりに、スーパーバイザーサービスレベルでセキュリティを管理するので、ＳＯＳＤＳｅｃベースのセキュリティソリューションは、技術非依存性でベンダー非依存性である。さらに、アセットの論理アイデンティティを用いることによって、ＳＯＳＤＳｅｃは、ＶＭ移動などのインフラストラクチャダイナミクスを、セキュリティマネジメント対し透過的にする。

サービス志向ソフトウェア定義型セキュリティコントローラ２００は、各アセットの一つ以上のアセットセキュリティポリシーおよびモデル２０５のデータベースを包含する。これらのモデル２０５は、アセット２７０が必要とするセキュリティ保護を要求する、セキュリティ要求事項、ポリシー、およびモデルのディスクリプションを提供する。いくつかの実装において、セキュリティポリシーおよびモデルは、手動で定義されるか、または第三者もしくはカスタムメイドのソフトウェアツールの助力を受けて定義される。また、コントローラ２００は、各セキュリティ制御手段の一つ以上のセキュリティ制御キャパシティディスクリプション２１０のデータベースを含み、該ディスクリプションは、そのセキュリティ制御手段の種類、入力、機能、出力、および制御範囲を記載する。例えば、或るＬＡＮ中のファイアウォールのキャパシティディスクリプションは、それがトラフィックフィルタリングデバイスであり、着信トラフィックを入力として取ることになり、その入力に対しフィルタリングルールを適用し、特定のトラフィックが通過することを拒否しまたは許可することになり、そのコンフィグレーションの如何によって様々な警報を出力し、その制御範囲はそれが動作するＬＡＮの範囲と同じであることを明記することになる。いくつかの実施形態では、モデルおよびディスクリプション２０５および２１０は、通常マニュアルで（例えばシステム管理者によって）前もって定義され、ネットワークがサポートするアセットおよび制御手段に対応する。また、このプロセスを自動化するために、第三者のまたはカスタムメイドのツールを使うことも可能である。全体的フレームワークは、サイバーセキュリティ管理へのサービス志向のアプローチを取り、セキュリティ制御手段はそれらのセキュリティ機能のサービスプロバイダとして表され、アセットは、それらのセキュリティサービス要求事項の観点から記述される。

コントローラ２００は、全アセットおよび制御手段の物理−論理属性マッピング２１５を備える。いくつかの実装において、各アセットおよび制御手段は、セキュリティコントローラに登録をしなければならない。この登録プロセスを介して、セキュリティコントローラは、アセットまたは制御手段の論理属性（例えばホスト名）をその物理属性（例えばＩＰアドレス）にマップする。マッピングが完了したならば、各アセットは、そのアセットのセキュリティポリシーおよびモデルから導出され、そのアセットの論理属性にマップされた、対応するセキュリティサービス要求事項を有することになる。同様に、各セキュリティ制御手段は、そのセキュリティ制御キャパシティディスクリプションから導出され、その制御手段の論理属性にマップされた、対応するセキュリティサービスディスクリプションを有することになる。いくつかの実装、例えば非ＳＯＳＤＳｅｃ実装において、ＩＰおよびドメイン名のマッピングはネットワークのＤＮＳサーバによって管理されるが、これは他のＳＤＩ／ＳＤＳｅｃコンポーネントと効率的に統合ができない。本ＳＤＳｅｃフレームワークによる中央マネジメントは、他のＳＤＩ／ＳＤＳｅｃコンポーネントへの迅速なアクセスとこれらとの容易な統合を提供する。

コントローラ２００は、セキュリティサービス要求事項２２５およびセキュリティサービスディスクリプション２３０を含むサービスマッチングエンジン２２０を含み、該要求事項およびディスクリプションはサービスマッチングアルゴリズム２３５に提供され、次いでサービスマッチングアルゴリズムは出力としてセキュリティサービスのバインディング２４０を提供する。セキュリティコントローラのサービスマッチングエンジン２２０は、アセットからのサービス要求を、セキュリティ制御デバイス（例えば、ファイアウォール、侵入検知システム、アイデンティティおよびアクセスマネジメント）によって提供されるサービスにバインディングする。マッチングエンジン２２０は、各アセットのセキュリティサービス要求事項を精査する。マッチングエンジン２２０は、サービスマッチングアルゴリズムまたはプロセスを実行し、その中で利用可能なセキュリティ制御キャパシティディスクリプションを探索する。該エンジンが、サービス要求事項（アセット）とセキュリティサービス（制御手段）との間のマッチングを見出したならば、マッチングエンジンはセキュリティサービスのバインディングを生成する。次いで、セキュリティコントローラは、このセキュリティサービスのバインディングを有効化し、一つ以上のアセットのセキュリティ要求事項を満たすため、様々なセキュリティ制御手段２４５に、適切なセキュリティ制御手段２４５へのコマンドコネクタ２５０を介して、該当するコマンドを送信する。

さらに詳しくは、セキュリティサービス要求事項２２５は、アセットのセキュリティポリシーおよびモデルから導出されたドキュメントである。各アセットは、一つの対応するセキュリティサービス要求事項ドキュメントを有することになり、これは、一つ以上のセキュリティサービスに対する該アセットの要求事項のフォーマルディスクリプションを包含する。セキュリティサービスディスクリプション２３０は、セキュリティ制御キャパシティディスクリプションから導出されたドキュメントである。各セキュリティ制御手段は、一つの対応するセキュリティサービスディスクリプションを有することになり、このディスクリプションは、他のエンティティが使うことになる一つ以上のサービスとして当該制御手段のセキュリティキャパシティを記述する。これは、関連するキャパシティおよび範囲パラメータと併せてそのセキュリティキャパシティの各々に対する公式のサービス名を定義する。サービスマッチングアルゴリズム２３５は、アセットからサービス要求事項を受信し、管理対象ＩＴインフラストラクチャ中でそれらを満たすセキュリティサービスを探索する。該アルゴリズムは、サービス名、種類、入力、および制御範囲を照合し、要求事項とサービスとがこれらの面において整合していることを確実にする。サービス要求事項とサービスとの間に整合が見出されたならば、コントローラ２００は、セキュリティサービスのバインディング２４０を生成し、いくつかの実装において、このバインディングは、サービス要求事項およびサービスディスクリプションの両方からの全ての必要な情報を有する。また、バインディング２４０は、このバインディングがどの位長く継続するか、誰が管理者かなど、さらなる情報も有してもよい。バインディング２４０は、それが生成された後、その基礎となるセキュリティモデルまたはセキュリティ制御手段のキャパシティが変化したときには変更することができる。コマンドコネクタ２５０は、それらのＡＰＩを介して、コマンドを様々な制御手段に送信するインターフェースのセットである。これらのコマンドは、セキュリティサービスのバインディングに基づいて生成される。コマンドは、通常、セキュリティ制御手段の設定を修正しそれらの動作挙動を変更する。これらのコマンドは、アセットのセキュリティ要求事項を満たす。

また、いくつかの実装において、セキュリティコントローラ２００は、ネットワーク設定およびセキュリティイベント２５５に対応することができる。これらの場合、イベントは、イベントコネクタ２６５を介して、プレイブック２６０に転送され、該ファイルは重要なイベントに対する対処計画のリストを包含する。プレイブック２６０中の計画に基づいて、マッチングエンジン２２０は、アセットのサービス要求事項、セキュリティ制御手段のサービスディスクリプションを変更し、または既存のセキュリティサービスのバインディングを修正することができる。

さらに詳しくは、イベントコネクタ２６５は、様々な外部情報源からネットワーク設定およびセキュリティイベント２５５を受信するインターフェースのセットである。イベントコネクタのインターフェースがイベントを受信すると、該インターフェースは、さらなる処理のためそのイベントをプレイブック２６０に転送する。プレイブック２６０は、セキュリティ管理者がアクションを取るべき重要なイベントに対する計画を包含する。これらのイベントは、企業のＩＴセキュリティポリシーおよびガイドラインの如何によって、侵入検知制御手段からの警報、ネットワークトポロジの変更、またはサーバ故障であり得よう。これらの計画は、アセットのサービス要求事項の変更、セキュリティ制御手段のサービスディスクリプションの変更、または現在のセキュリティサービスのバインディングの修正など、サービス関連の操作と共に規定される。

ソフトウェア定義型セキュリティコントローラ２００は、サービス志向のアプローチを取ることにより、ネットワークが仮想ＩＴインフラストラクチャにおけるサイバーセキュリティの管理に存在する欠点を克服することを可能にする。セキュリティ要求事項は利用可能なサービスに自動的にマッチされ、これは、アセットの物理属性に基づくセキュリティ制御手段の手動での設定の必要性を排除する。このことは、サイバーセキュリティシステムに対し、増進されたフレキシビリティ、マネジメントにおける複雑さの低減、ネットワークの向上された安定性など多くの利点を提供する。

例えば、一つの実装において、内部サーバ（または、その内部サーバによって提供される諸機能）などのアセット２７０は、企業のＩＴオフィスからクラウドに移行されることがある。かかる移行は、そのサーバの物理属性（例えば、アセットのＩＰアドレス）の変更をもたらすことになる。上で説明したフレームワークを用いて、アセットがセキュリティコントローラに登録されたならば、そのセキュリティコントローラが、物理−論理属性マッピングを自動的に更新することになる。さらに、ソフトウェア定義型セキュリティは論理属性を介して動作するので、物理−論理属性マッピングが更新されたならば、その移行はシームレスである。すなわち、サービスマッチングエンジン２２０が、アセットのサービス要求事項とセキュリティサービスとの間のマッチを更新し、アセットの更新された物理属性を反映するために関連するセキュリティ制御手段にコマンドを送信する。そして、アセット（または複数のアセット）が追加のセキュリティ制御手段（例えば、クラウドへの移行に伴う第二のファイアウォール）を必要とする場合、サービスマッチングエンジン２２０が、アセットの更新された物理配置に対する関連制御手段を構成するために追加のセキュリティサービスのバインディングを作成することになる。

サービス志向ソフトウェア定義型セキュリティコントローラ２００は、いくつかの有益性および利点を提供する。このフレームワークは、アセットとセキュリティ制御手段との論理属性を、それらの物理属性から切り離すだけでなく、アセットのセキュリティ要求事項をもセキュリティ制御手段のキャパシティから切り離す。このアプローチは、ソフトウェア定義型セキュリティを実装するための効果的方法であり、セキュリティマネジメントに以下のような利点をもたらすことができる。

一つの利点はデジタルアセットに対する移植可能なセキュリティである。このアプローチの有益性は、セキュリティ要求事項がセキュリティサービスから切り離されることであり、このことは、アセットが、動的にそれらの物理属性を変更しながら、そのセキュリティ要求事項およびモデルを実施することを可能にする。これは、クラウドベースのＩＴインフラストラクチャにおいて特に有利であり、同じ論理アセットを相異なるネットワークロケーションでインスタンス化することができよう。アセットが新しいロケーションに移動されたとき、セキュリティコンフィグレーションを手動でセットアップする代わりに、本アプローチは、該アセットのセキュリティ要求事項を利用可能なセキュリティサービスに自動的にマッチングすることを可能にする。マッチングが成功したならば、特定のセキュリティコンフィグレーションが対応するサービスのバインディングから得ることができ、セキュリティ制御手段に自動的に適用される。

別の利点はセキュリティマネジメントの複雑さの低減である。ＳＯＳＤＳｅｃコントローラは、セキュリティ保全の複雑さを低減する。アセットのセキュリティポリシーおよびモデルへの変更は、アセットのセキュリティサービス要求事項を調整することによって達成することができる。セキュリティ制御機能への変更は、制御手段のサービスキャパシティディスクリプションを調整することによって達成できる。ＳＯＳＤＳｅｃの使用により、管理者は、通常、時間がかかりエラーが生じがちな、セキュリティ制御手段のコンフィグレーションの直接の修正を行う必要がない。代わりに、人間の管理者がサービス要求事項またはサービスキャパシティディスクリプションを調整した後は、ＳＯＳＤＳｅｃが、影響のあるサービスのバインディングを自動的に修正し、導出されたセキュリティコンフィグレーションを、関連するセキュリティ制御手段に適用する。

別の利点は、相異なる技術および制御手段を導入するフレキシビリティの増大である。ＳＯＳＤＳｅｃコントローラは、セキュリティ制御手段の機能をセキュリティサービスとして転換し、これらセキュリティサービスを実行技術から切り離す。これは、相異なる技術を使って実装された、または相異なる会社によって作製されたセキュリティ制御手段に対し、同じセキュリティサービスディスクリプションを使うことができる利点をもたらす。これらのセキュリティ機能が同じまたは類似である限り、管理者は、サービスディスクリプションを修正する必要なく任意のものを展開することが可能である。これは、セキュリティ管理者に、各種のセキュリティ技術および製品を使い、ベンダーロックインを回避するより大きなフレキシビリティを与える。

別の利点は、セキュリティインシデントへの対応の機動性の増大である。ＳＯＳＤＳｅｃは、自動的な要求事項−サービスマッチングを用いて、従来、手作業を必要としていた多くのセキュリティ作業を自動化することができる。これは、セキュリティインシデントへの応答時間をスピードアップし、組織のサイバー機動性を改良する。

別の利点は、変わりゆく脅威状勢に適応することである。ＳＯＳＤＳｅｃを用い、管理者は、セキュリティ制御手段のコンフィグレーションをどのように対応して変更するかを考えることなく、アセットのセキュリティ要求事項を変更することができる。ＳＯＳＤＳｅｃは、関連するセキュリティ制御手段のコンフィグレーションを迅速に且つ自動的に修正することが可能である。セキュリティ要求事項の調整を外部／内部の脅威状勢に関連付けておけば、ＳＯＳＤＳｅｃは、新しいおよび進化する脅威に対して防御するためにＩＴのサイバーセキュリティを自動的に調整することができる。

別の利点は、サイバーセキュリティの改良されたスケーラビリティである。ＳＯＳＤＳｅｃは、ソフトウェア定義型セキュリティを実装し、ほとんどのセキュリティのプロビジョニング、マネジメント、およびコンフィグレーションタスクをソフトウェアに完遂させることを可能にする。このことは、短時間での多数のセキュリティ制御手段の展開およびコンフィグレーションを可能にし、これはサイバーセキュリティのスケーラビリティを改良する。

いくつかの実装において、同じ種類のセキュリティ制御手段は、通常、類似の能力を有し、これらの機能は同一の転換サービスによって記述することができる。例えば、或るＳＯＳＤＳｅｃ実装において、ファイアウォールの第一型とファイアウォールの第二型とは、同じファイアウォールサービスとして転換し、表すことが可能である。ＳＯＳＤＳｅｃは、セキュリティ制御手段の全ての異なる型を共通のセキュリティサービスにさらに転換して表す。

図２Ａは、例示のセキュリティサービス２０５ａのクラス図２００ａを示す。このセキュリティサービスのサブクラスは、ファイアウォールサービス２１０ａ、アクセス制御サービス２１５ａ、および侵入検知サービス２２０ａを実装する。この転換セキュリティサービスクラスは、ＳｅｒｖｉｃｅＮａｍｅ、ＳｅｒｖｉｃｅＤｅｓｃｒｉｐｔｉｏｎ、ＭｏｄｕｌｅＮａｍｅ、ＣｌａｓｓＮａｍｅ、ＡｖａｉｌａｂｌｅＣｏｎｔｒｏｌｓを含むいくつかの共通の領域だけを定義している。ＭｏｄｕｌｅＮａｍｅおよびＣｌａｓｓＮａｍｅは、ＳＯＳＤＳｅｃがクラスソースコードを動的にロードするためのモジュールの名称およびクラスの名称を言う。また、第三者サービスの実装と統合するのも一つの実行可能なやり方である。ＡｖａｉｌａｂｌｅＣｏｎｔｒｏｌｓは、この種のサービスを提供する実行時の制御オブジェクトのセットである。

ＳＯＳＤＳｅｃにおいて、セキュリティサービスは、論理アイデンティティに基づく転換されたインターフェースを顕示する。セキュリティマネジメントは、転換サービスの共通のＡＰＩ上に構築される。また、ＳＯＳＤＳｅｃでは、セキュリティ管理者は、保護対象の各アセットに対するサービス要求事項リストを作成する。この要求事項リストは、既存のセキュリティモデルおよびポリシーから導出が可能である。アセットは、仮想または物理サーバ、アプリケーション、データベース、ファイルのセットなどであってもよい。各要求事項は、必要な一つのセキュリティサービスおよびそのパラメータを規定する。

アセットは、セキュリティグループに編成される。同じグループのアセットは、同じセキュリティサービス要求事項を共有する。図２Ｂは、例示の同じセキュリティグループ２２０ｂ中にあるアセット２０２ｂ〜２１６ｂが、相異なる仮想または物理ネットワーク２３０ｂまたは２４０ｂに属し得る、例示のシステム２００ｂを示す。ＳＯＳＤＳｅｃは、これらアセットの論理アイデンティティだけを使用することが可能で、これらは、ＩＰアドレスおよびネットワークロケーションなどの一切の物理属性に束縛されない。これは、ＳＯＳＤＳｅｃにおけるセキュリティ要求事項のマネジメントがアセットの物理属性の変更に影響されないことになることを意味する。例えば、例えばアセット２０４ｂなどのアセットがネットワークロケーション２３０ｂからネットワークロケーション２４０ｂに移動される場合、セキュリティ管理者は、該アセットが同じセキュリティグループ２２０ｂに留まる限り、そのセキュリティポリシーを調整する必要はなく、双方のネットワーク中のセキュリティ制御手段に手動での変更を加えなくてもよい。これは、スーパーバイザーレベルでのセキュリティマネジメントが変わらないことによる。アセットと制御手段とを一緒に束ねている関連セキュリティサービスのバインディングが、移動されるアセットのセキュリティ要求事項の充足を維持するために必要なオペレーションを実施する必要があるだけである。セキュリティサービスのバインディングについて以下に説明する。

アセットがセキュリティサービスを必要とする場合、ＳＯＳＤＳｅｃは、当該インフラストラクチャ中で、必要なサービスを提供するセキュリティ制御手段を探索する。このため、各セキュリティ制御手段は、それがどのようなセキュリティサービス提供するかを宣言する必要があり、セキュリティ管理者は、展開される各セキュリティ制御手段およびそれがサポートするサービスを、他の関連する情報と共にＳＯＳＤＳｅｃ制御手段データベースに登録する必要がある。全ての制御手段が登録されたならば、サービスマッチングは、特定の基準の下に、データベース中で必要なサービスを探索するプロセスとなる。ＳＯＳＤＳｅｃは、スキーマベースのまたはオントロジーベースのマッチングアルゴリズムなど、様々なマッチングアルゴリズムを用いることができる。或る例示の実装は、探索方法として正確名称マッチングを使用することが可能である。

ＳＯＳＤＳｅｃコントローラが、セキュリティ要求事項を適切な利用可能なセキュリティサービスにマッチさせたならば、該コントローラは、保護対象アセットを対応するセキュリティ制御手段に連結するセキュリティサービスのバインディングを作成する。サービスのバインディングは、要求される保護を提供する特定のセキュリティ制御手段に対して、かかる共通のセキュリティ要求事項を有するアセットのセットのサービス要求を向けるインターフェースである。また、セキュリティサービスのバインディングは、セキュリティ制御手段に適切なセキュリティ操作を透過的（ユーザに気付かせず）に実施することによって、インフラストラクチャダイナミクスおよびマネジメントコマンドに応答する。サービスのバインディングは、それに関連付けられたアセットのセキュリティ要求事項が、各操作の後も継続して満たされていることを確実にする。

図２Ｃは、セキュリティサービスのバインディングのクラスおよび三つのサブクラスの例示のクラスおよびメッセージ図２００ｃを示す。ＳＯＳＤＳｅｃでは、各サービスは、それ自体のサービスのバインディングクラスを定義し、該クラスは、その型のサービスのバインディングが様々なダイナミクスにどのように応答すべきかを実装している。サービスのバインディングは、ＪＳＯＮメッセージで更新を受信し、各更新に応じて適切な制御コマンドを生成する。次いで、バインディングは、制御手段の設定を修正するためそれらコマンドをセキュリティ制御手段に送信する。いくつかの実装において、ＳＯＳＤＳｅｃは、例えば、アセットの更新、グループの更新、および制御手段の更新など、インフラストラクチャまたはマネジメントの三つの型に対応する。アセットの更新は、セキュリティグループの間でアセットを追加する、削除する、または移動すること、およびネットワーク中でアセットを追加する、削除する、または移動すること、を含む。グループの更新は、セキュリティグループを追加するまたは削除することを含む。制御手段の更新は、インフラストラクチャ中で、セキュリティ制御手段を追加するまたは削除することを含む。

図２Ｃで示された例において、サービスバインディングクラス２０５ｃは、アクセス制御バインディングクラス２１０ｃ、ファイアウォールバインディングクラス２１５ｃ、ＩＤＳバインディングクラス２２０ｃなど、いくつかのサブクラスのスーパークラスである。インフラストラクチャ２２５ｃからのインフラストラクチャダイナミクス、およびセキュリティ管理組織２３０ｃからの管理コマンドに基づいて、サービスバインディングクラス２０５ｃは、例えば、ＰｒｏｃｅｓｓＡｓｓｅｔＤｙｎａｍｉｃｓ（）、ＰｒｏｃｅｓｓＧｒｏｕｐＤｙｎａｍｉｃｓ（）、またはＰｒｏｃｅｓｓＣｏｎｔｒｏｌＤｙｎａｍｉｃｓ（）などのコマンドを選択する。サービスバインディングクラス２０５ｃは、選択されたコマンドをセキュリティ制御手段２３５ｃに送信する。

図３は、外部クライアント３０５が仮想プライベートネットワークを介して保護された内部サーバ３１０および３１５にアクセスしている例示のシステム３００を示す。これらのサーバは、ファイアウォール３２０によって保護されており、外部クライアント３０５は、サーバ３１０および３１５にアクセスするためにＶＰＮ接続を使用する。

この遠隔アクセスに対しサイバーセキュリティを提供するために、ＳＯＳＤＳｅｃコントローラ３２５は、ファイアウォール３２０から登録要求を受信し、コントローラ３２５は、ファイアウォール３２０を、トラフィックフィルタリングサービスとして登録する。コントローラ３２５は、ＶＰＮサーバ３３０から登録要求を受信し、該コントローラはＶＰＮサーバ３３０を安全な通信サービスとして登録する。コントローラ３２５は、内部サーバ３１０および３１５から登録要求を受信する。コントローラ３２５は、サーバ３１０および３１５を、ＶＰＮサーバ３３０からのトラフィックだけが許可されることを指定するパラメータと共に、トラフィックフィルタリングサービスのコンシューマとして登録する。コントローラ３２５は、これらサーバの要求とファイアウォールのサービスディスクリプションとの間の一致（マッチ）を見出し、サービスバインディングを作成する。コントローラ３２５は、これらサービスバインディングをファイアウォールへのコマンドに変換し、ファイアウォール３２０の設定を変更するために、該コマンドを該ファイアウォールに送信する。クライアント３０５は登録要求をコントローラに送信し、コントローラ３２５は、クライアント３０５を安全な通信サービスのコンシューマとして登録する。コントローラ３２５は、クライアントのサービス要求とＶＰＮサーバのサービスディスクリプションとの間の一致（マッチ）を見出し、サービスバインディングを作成する。コントローラ３２５は、該サービスバインディングをＶＰＮの設定に変換し、対応するコマンドをＶＰＮサーバ３３０に送信する。いくつかの実装において、前述のステップは、クライアント３０５がインターネットを介し、いずれかのサーバへの接続を試みる前に完了される。クライアント３０５が、インターネットを介しＶＰＮサーバ３３０に接続する。ＶＰＮサーバ３３０は、該クライアントの記録をその設定中に見付け出し、クライアント３０５に対する安全な通信トンネル３３５の設置に進む。クライアントのトラフィックは、ファイアウォール３２０に到達し、ファイアウォールは、そのトラフィックをＶＰＮサーバ３３０からのトラフィックとして識別し、内部サーバ３１０および３１５に向け通過させる。

図３Ａは、別の例示のテストベッド３００ａを示す。テストベッド３００ａは、ＳＤＮコントローラ３１０ａとして、オープンソースＦｌｏｏｄｌｉｇｈｔコントローラを、そしてネットワークシミュレーションサーバとして、オープンソースシミュレータＭｉｎｉｎｅｔを使用する。テストベッド３００ａは、三つのサーバ、すなわち、Ｐｙｔｈｏｎまたは類似の言語を使って実装可能で、ＣｏｕｃｈＤＢデータベース３２０ａおよびウェブインターフェース３２５ａを含むＳＯＳＤＳｅｃコントローラサーバ３１５ａと、Ｆｌｏｏｄｌｉｇｈｔを実行するＳＤＮコントローラサーバ３１０ａと、サブネットおよび例えばミニネットサーバなど数十の仮想ホストを使いＯｐｅｎＦｌｏｗネットワークをシミュレートするネットワークシミュレーションサーバ３３０ａと、から成る。

関連する移植可能なアセットセキュリティとして、多くの企業は、そのインフラストラクチャの様々な部分で異機種環境のセキュリティ技術を導入している。これらの部分の間を移動するアセットにセキュリティポリシーを一貫して実施するためには、多くの場合、管理者が、相異なる技術を使用するセキュリティ制御手段を手動で設定しなければならず、時間がかかりエラーが生じがちなプロセスなので、これは面倒事である場合もある。

図３Ｂは、例示のテストベッド３００ｂ中の二つの例示のサブネット３０５ｂおよび３１０ｂを示す。第一サブネット３０５ｂは、ＯｐｅｎＦｌｏｗ対応スイッチ３１５ｂ、３１７ｂ、および３１９ｂに接続され、Ｆｌｏｏｄｌｉｇｈｔコントローラ３２０ｂによって管理されている。第二サブネット３１０ｂは、非ＯＰｅｎＦｌｏｗスイッチ３２１ｂ、３２３ｂ、および３２５ｂに接続されたネットワークである。各サブネットはファイアウォール機能を有する。ＯＰｅｎＦｌｏｗネットワーク３０５ｂ上では、ファイアウォールのルールは、Ｆｌｏｏｄｌｉｇｈｔコントローラ３２０ｂ上で作成され、すべてのＯｐｅｎＦｌｏｗスイッチ３１５ｂ、３１７ｂ、および３１９ｂに執行される。ＳＯＳＤＳｅｃコントローラ３４０ｂは、Ｆｌｏｏｄｌｉｇｈｔコントローラのファイアウォール機能を呼び出すためＦｌｏｏｄｌｉｇｈｔファイアウォールＡＰＩを用いる。非ＯＰｅｎＦｌｏｗネットワーク３１０ｂでは、カーネル中で使用可能なファイアウォールを有するゲートウェイとして、Ｌｉｎｕｘ（登録商標）サーバが使われている。ＳＯＳＤＳｅｃは、そのファイアウォールを設定するためこのゲートウェイのｉｐｔａｂｌｅｓコマンドをリモートで呼び出す。相異なる技術によって実装されているにもかかわらず、これら二つのファイアウォール制御手段は、ＳＯＳＤＳｅｃ中の同じファイアウォールサービスに転換して表され、セキュリティポリシーおよびマネジメントは、これら二つの技術の間の区別をする必要がない。各サブネットは、Ｍｉｎｉｎｅｔによって作成されたいくつかの仮想ホストを有し、財務グループ３３０ｂと販売グループ３３５ｂとに分けられている。各グループは、それ自体のアクセス制御ポリシーを有し、これはファイアウォールサービス要求事項に変換されている。

財務グループ３３０ｂに属する仮想ホスト３４０ｂを、ＯＰｅｎＦｌｏｗネットワーク３０５ｂから従来式ネットワーク３１０ｂに移動することにより、移植可能なセキュリティについてＳＯＳＤＳｅｃ制御手段が評価される。この仮想ホストのグループは、移動の後も変わらないままである。従来式のセキュリティでは、この移動は、通常、両方のファイアウォール３２０ｂおよび３４５ｂに対するルールの手動での更新を必要とする。だがＳＯＳＤＳｅｃでは、仮想ホスト３４０ｂは、たとえそのネットワークアイデンティティ（ＩＰアドレス）が変更されたとしても、その論理アイデンティティ（ホスト名）は変わらず、そのセキュリティ要求事項も変わらないので、このプロセスは管理者に対し透過的である。背後では、セキュリティサービスのバインディング３５０ｂは、インフラストラクチャから更新を受信し、技術固有のＡＰＩを使って両方のファイアウォールに対する設定を調整している。いくつかの実装において、この仮想ホストの移動の前後において、両方のグループの同じアクセスポリシーが適正に執行される。論理アセットアイデンティティおよび転換されたセキュリティサービスを用いることによって、ＳＯＳＤＳｅｃコントローラ３４０ｂは、異機種環境を横断して技術非依存のセキュリティマネジメントをサポートする。

自律的攻撃封じ込めに関するさらに別の例示の使用のケースにおいて、より複雑なセキュリティオペレーションを制御するＳＯＳＤＳｅｃの能力を提示する。例えば、ＳＯＳＤＳｅｃは、プレイブックのルールおよび隔離サービスを用い、自律的に攻撃を封じ込める。図３Ｃは、設定変更可能な信頼レベルに基づいて、アクセス制御ルールを動的に修正するソフトウェア定義型ネットワーク設定技術を使って実装された例示の隔離サービス３００ｃを示す。このサービスは、隔離ゾーン３０５ｃを作成し、該ゾーンには、ゼロ信頼度レベルのアセット３１０ｃ、３１２ｃ、３１４ｃ、および３１６ｃが、相互におよびネットワークの他の部分から隔離されている。プレイブック３２０ｃは、特定のサイバーイベントに対応する組織の戦略を定義したワークフロールールの収集を保持する。ＳＯＳＤＳｅｃコントローラ３２５ｃによる自律的な攻撃封じ込めを展開するために、セキュリティ管理者は、１）ネットワーク中に隔離サービスを展開し、そして２）プレイブックのルールを作成する、必要があるだけでよい。以下は、プレイブックのルールの一例である。

例示のルールは、ＳＯＳＤＳｅｃコントローラ３２５がＩＤＳサービス３３０ｃからのＴｒｏｊａｎ（トロイの木馬）警報に対処すべきであると規定する。さらに、該ルールは、Ｔｒｏｊａｎ警報を掲げたいずれのアセットに対しても、ＳＯＳＤＳｅｃコントローラ３２５ｃが、隔離サービスに対し新規の要求を加えることによって、そのアセットのサービス要求事項を修正することを指定する。

ルールが設定された後、ＳＯＳＤＳｅｃコントローラ３２５ｃは、ＩＤＳサービス３３０ｃによって送信される全てＴｒｏｊａｎ警報への対応を開始する。最初に、ＩＤＳサービス３３０ｃが、Ｔｒｏｊａｎマルウェアまたはトラフィックが検知されたアセットをレポートする。ＳＯＳＤＳｅｃコントローラ３２５ｃは、プレイブックのルールに従い、感染アセットに対する隔離サービスを要求する。感染アセットと隔離サービスプロバイダ（この場合はＳＤＮコントローラ３３５ｃ）とを一緒に束ねる、隔離サービスバインディングが作成される。また、このサービスバインディングは、ＳＤＮコントローラ３３５ｃに、関連するアクセス制御ルールを変更するためのコマンドを送信する。ＳＤＮコントローラ３３５ｃは、接続されたＯＰｅｎＦｌｏｗスイッチ３４０ｃ、３４２ｃ、３４４ｃに新規のアクセス制御ルールを配信する。感染したアセット３１０ｃ、３１２ｃ、３１４ｃ、および３１６ｃは、論理隔離ゾーン３０５ｃ内に効果的に隔離される。他の複雑なセキュリティマネジメントタスクも、保護対象アセットのセキュリティ要求事項を動的に修正することによって、同様な自律的方法で実装することが可能である。

図４〜８の以下の記述は、サービス志向ソフトウェア定義型セキュリティコントローラの例示の機能を説明する。これらの機能は、セキュリティ制御手段の登録、アセットの登録、セキュリティサービス要求、セキュリティ制御コマンド、およびネットワーク設定またはセキュリティイベントの受信、を含む。

図４は、サービス志向ソフトウェア定義型セキュリティに対する例示のセキュリティ制御手段登録プロセス４００を示す。セキュリティ制御手段登録プロセス４００に従って、サービス志向ソフトウェア定義型セキュリティコントローラは、セキュリティ制御デバイスまたはソフトウェアを登録する。この機能は二つのタスクを実施する。第一のタスクは、登録されたセキュリティ制御手段に対する物理−論理属性マッピングを作成することである。第二のタスクは、セキュリティ制御手段の能力をセキュリティサービスディスクリプションに変換することである。

セキュリティ制御手段登録プロセス４００の過程で、サービス志向ソフトウェア定義型セキュリティコントローラは、セキュリティ制御手段の名称、セキュリティ制御手段の種類、セキュリティ制御手段の物理属性およびそれらに対応する論理属性、並びにセキュリティキャパシティディスクリプションを受信する。プロセス４００が開始され（４０５）、コントローラは、前もってリストされていた入力、さらに具体的にはセキュリティ制御手段の入力を受信する（４１０）。コントローラは、セキュリティ制御手段の入力の有効性を確認する（４１５）。入力が有効でない場合（４２０）、コントローラはエラーをレポートし（４２５）プロセス４００は終了する（４４０）。入力が有効な場合（４２０）、コントローラは、物理−論理属性マッピングを作成する（４３０）。コントローラは、出力としてセキュリティサービスディスクリプションを作成し（４３５）プロセス４００は終了する（４４０）。

図５は、サービス志向ソフトウェア定義型セキュリティに対する例示のアセット登録プロセス５００を示す。アセット登録プロセス５００に従って、サービス志向ソフトウェア定義型セキュリティコントローラは、デジタルアセット並びにその関連セキュリティポリシーおよびモデルをコントローラに登録する。次いでコントローラはアセットの情報に対し二つのタスクを実施する。第一のタスクは、登録されたアセットに対する物理−論理属性マッピングを作成することである。第二のタスクは、セキュリティポリシーおよびモデルを、サービス要求事項に変換することである。

アセット登録プロセス５００の過程で、サービス志向ソフトウェア定義型セキュリティコントローラは、アセットの名称、アセットの種類、アセットの物理属性、アセットの論理属性、関連付けられたセキュリティポリシー、およびセキュリティモデルを受信する。プロセス５００が開始され（５０５）、コントローラは、例えば、前もってリストされていた入力など、アセットからの入力を受信または読み取る（５１０）。コントローラは、アセットからの入力の有効性を確認する（５１５）。入力が有効でない場合（５２０）コントローラは、エラーをレポートし（５２５）プロセス５００は終了する（５４５）。入力が有効な場合、コントローラは、物理−論理属性マッピングを作成する（５３５）。コントローラは、出力としてアセットに対するセキュリティサービス要求事項を作成し（５４０）プロセス５００は終了する（５４５）。

図６は、サービス志向ソフトウェア定義型セキュリティに対する例示のセキュリティサービス要求プロセス６００を示す。セキュリティサービス要求プロセス６００に従って、サービス志向ソフトウェア定義型セキュリティコントローラは、セキュリティサービスを呼び出すアセットからの要求を受信する。サービス志向ソフトウェア定義型セキュリティコントローラは、セキュリティサービスに対する要求を受信し、そのアセットの要求事項を満たすセキュリティサービスを探索する。

セキュリティサービス要求プロセス６００の過程で、サービス志向ソフトウェア定義型セキュリティコントローラは、アセットの論理アイデンティティおよび該アセットの一つ以上のセキュリティ要求事項を受信する。プロセス６００が開始され（６０５）、コントローラは、アセット、例えば論理アイデンティティに対応するアセットの有効性を確認する（６１０）。アセットが有効でない場合（６１５）、コントローラはエラーをレポートし（６２０）プロセス６００は終了する（６５０）。アセットが有効な場合（６１５）、コントローラは、次の不整合な要求事項を読み出す（６２５）。コントローラは、その不整合な要求事項を満たすセキュリティサービスを探索する（６３０）。コントローラがこれを満たせるセキュリティサービスを見出せなかった場合（６３５）、コントローラはエラーをレポートし（６２０）プロセス６００は終了する（６５０）。コントローラが満たせるセキュリティサービスを見出した場合（６３５）、コントローラは出力としてサービスバインディングを作成する（６４０）。他の不整合な要求事項がある場合（６４５）、コントローラは、戻って次の不整合な要求事項を読み出す（６２５）。他の不整合な要求事項がない場合（６４５）、プロセス６００は終了する（６５０）。

図７は、サービス志向ソフトウェア定義型セキュリティに対する例示のセキュリティ制御コマンド送信プロセス７００を示す。セキュリティ制御コマンド送信プロセス７００に従って、サービス志向ソフトウェア定義型セキュリティコントローラは、特定のセキュリティサービスのバインディングを、一つ以上のセキュリティ制御手段に対するコマンドのシーケンスに変換し、コマンドを、コマンドコネクタを介して制御手段に送信する。

セキュリティ制御コマンド送信プロセス７００の過程で、サービス志向ソフトウェア定義型セキュリティコントローラは、セキュリティサービスのバインディングを受信する。プロセス７００が開始され（７０５）、コントローラは、受信したセキュリティサービスのバインディングからセキュリティ制御手段を抽出する（７１０）。コントローラは、セキュリティサービスのバインディングを制御コマンドに変換する（７２０）。コントローラは、制御コマンドの有効性を確認する（７２０）。制御コマンドが有効でない場合（７２５）、コントローラは、エラーをレポートし（７３０）プロセス７００は終了する（７５０）。制御コマンドが有効な場合（６１５）、コントローラは、制御コマンドをセキュリティ制御手段に向け出力する（７３５）。コントローラはコマンドステータスを検証する（７４０）。制御コマンドがうまくいかなかった場合（７４５）、コントローラは、エラーをレポートし（７３０）プロセス７００は終了する（７５０）。制御コマンドが成功した場合（７４５）、プロセス７００は終了する（７５０）。

図８は、サービス志向ソフトウェア定義型セキュリティに対するネットワーク設定またはセキュリティイベントを受信するための例示のプロセス８００を示す。ネットワーク設定またはセキュリティイベントを受信するためのプロセス８００に従って、サービス志向ソフトウェア定義型セキュリティコントローラは、イベントコネクタからネットワーク設定またはセキュリティイベントを受信する。コントローラがイベントを受信した場合、コントローラはそのイベントをプレイブックの中で調べる。そのイベントがプレイブック中に定義されたトリガである場合、コントローラは、そのイベントに対するアクションのシーケンスの実行を開始する。各アクションは、セキュリティ要求事項またはサービスディスクリプションを修正する。

ネットワーク設定またはセキュリティイベントを受信するためのプロセス８００の過程で、サービス志向ソフトウェア定義型セキュリティコントローラは、セキュリティ関連のイベントについてのデータを受信する。プロセス８００が開始され（８０５）、コントローラは、入力データからイベントデータを読み出す（８１０）。コントローラは、プレイブック中でそのイベントを調査する（８１５）。コントローラが、プレイブック中にそのイベントを見付けられなかった場合（８２０）、プロセス８００は終了する（８２５）。コントローラが、プレイブック中にそのイベントを見出した場合（８２０）、コントローラは、そのイベントに対し定義されたアクションをプレイブックから抽出する（８３０）。コントローラは、次のアクションを読み出す（８３５）。コントローラは、セキュリティ要求事項またはサービスディスクリプションを修正する（８４０）。さらなるアクションがある場合（８４５）、コントローラは、戻って次のアクションを読み出す（８３５）。さるなるアクションがもうない場合、プロセス８００は終了する（８２５）。

前述の説明は、ＳＯＳＤＳｅｃ、すなわちソフトウェア定義型セキュリティを実装するサービス志向のアプローチに関する。該アプローチは、実際のセキュリティ制御手段およびインフラストラクチャの詳細から、セキュリティマネジメントを分離する。これは、クラウド環境に次世代において、企業のセキュリティをより機動的にする。

いくつかの実装において、クラウドアプリケーションのためのトポロジおよび統合化仕様（ＴＯＳＣＡ：Ｔｏｐｏｌｏｇｙ ａｎｄ Ｏｒｃｈｅｓｔｒａｔｉｏｎ Ｓｐｅｃｉｆｉｃａｔｉｏｎ ｆｏｒ Ｃｌｏｕｄ Ａｐｐｌｉｃａｔｉｏｎ）が使用可能である。ＴＯＳＣＡは、クラウドアプリケーションの移植可能で標準化されたマネジメントを可能にする。ＴＯＳＣＡは、クラウドアプリケーションの全存続期間において、これらを作成し、終結し、そして管理するために用いるプロセスモデルを定義するプランコンセプトを含む。ＴＯＳＣＡプランを、異機種環境のクラウド中のＳＯＳＤＳｅｃサービスの定義、作成、終結、およびマネジメントを標準化するために適用することが可能である。

ＳＯＳＤＳｅｃでは、セキュリティ能力は、同型のマネジメントＡＰＩを有するモジュール式セキュリティサービスに転換される。これは、ユーザにさらにカスタム化されたセキュリティ機能を提供するために、相異なるＳＯＳＤＳｅｃサービスを連鎖できる可能性をもたらす。いくつかの実装において、ＳＯＳＤＳｅｃサービスは、構成し、連鎖することができる。

図９は、本明細書に記載された技法を実装するため使用可能なコンピューティングデバイス９００およびモバイルコンピューティングデバイス９５０の一例を示す。コンピューティングデバイス９００は、ラップトップ、デスクトップ、ワークステーション、携帯情報端末、サーバ、ブレード型サーバ、メインフレーム、および他の適切なコンピュータなど、デジタルコンピュータの様々な形態を代表することが意図されている。モバイルコンピューティングデバイス９５０は、携帯情報端末、携帯電話、スマートフォン、および他の類似のコンピューティングデバイスなど、携帯デバイスの様々な形態を代表することが意図されている。本図に示されるコンポーネント、それらの接続および関係、並びにそれらの機能は、例示のためだけのものであり、限定を意味するものではない。

コンピューティングデバイス９００は、プロセッサ９０２と、メモリ９０４と、ストレージデバイス９０６と、メモリ９０４および複数の高速拡張ポート９１０に接続する高速インターフェース９０８と、低速拡張ポート９１４およびストレージデバイス９０６に接続する低速インターフェース９１２と、を含む。プロセッサ９０２、メモリ９０４、ストレージデバイス９０６、高速インターフェース９０８、高速拡張ポート９１０、および低速インターフェース９１２の各々は、様々なバスを使って相互接続され、共通のマザーボード上に、または必要に応じて他の仕方で搭載することが可能である。プロセッサ９０２は、高速インターフェース９０８に連結されたディスプレイ９１６などの外部入力／出力デバイスのＧＵＩにグラフィカル情報を表示するために、メモリ９０４またはストアデバイス９０６に格納された命令を含め、コンピューティングデバイス９００内で実行するための命令を処理することができる。他の実装において、必要に応じ、複数の種類の複数のメモリと共に、複数のプロセッサおよび／または複数のバスが使用されてもよい。また、各デバイスが必要なオペレーションの諸部分を提供するようにして（例えば、サーババンク、ブレード型サーバのグループ、またはマルチプロセッサシステムとして）複数のコンピューティングデバイスが接続されてもよい。

メモリ９０４は、コンピューティングデバイス９００内の情報を格納する。いくつかの実装において、メモリ９０４は、揮発性メモリユニットまたは複数のユニットである。一部の実装では、メモリ９０４は、不揮発性メモリユニットまたは複数のユニットである。また、メモリ９０４は、磁気または光ディスクなど、コンピュータ可読媒体の別の形態であってもよい。

ストレージデバイス９０６は、コンピューティングデバイス９００に対し大容量ストレージを提供することができる。いくつかの実装において、ストレージデバイス９０６は、フロッピーディスクデバイス、ハードディスクデバイス、光ディスクデバイス、またはテープデバイス、フラッシュメモリもしくは他の類似のソリッドメモリデバイス、あるいはデバイスのアレイなど、ストレージエリアネットワークまたは他の構成の中のデバイスを含め、コンピュータ可読媒体であってよくまたはこれらを含んでもよい。命令は、情報搬送体中に格納することが可能である。これらの命令は、一つ以上の処理デバイス（例えば、プロセッサ９０２）によって実行されたとき、上で説明した方法など一つ以上の方法を実行する。また、これらの命令は、コンピュータまたは機械可読の媒体（例えば、メモリ９０４、ストレージデバイス９０６、またはプロセッサ９０２上のメモリ）など、一つ以上のストレージデバイスによって格納することが可能である。

高速インターフェース９０８は、コンピューティングデバイス９００に対する帯域幅集約的なオペレーションを管理し、一方、低速インターフェース９１２は、より低い帯域幅集約的なオペレーションを管理する。かかる機能の割り当ては、単なる例示である。いくつかの実装において、高速インターフェース９０８は、メモリ９０４に、ディスプレイ９１６に（例えば、グラフィックスプロセッサまたはアクセラレータを介して）、および、様々な拡張カードを受け入れ可能な高速拡張ポート９１０に連結される。この実装において、低速インターフェース９１２は、ストレージデバイス９０６および低速拡張ポート９１４に連結される。様々な通信ポート（例えば、ＵＳＢ、ブルートゥース（登録商標）、イーサネット（登録商標）、ワイヤレスイーサネット（登録商標））を含むことが可能な低速拡張ポート９１４は、キーボード、ポインティングデバイス、スキャナ、または、例えばネットワークアダプタを介しスイッチもしくはルータなどのネットワーク設定デバイスなど、一つ以上の入力／出力デバイスに連結されてもよい。

コンピューティングデバイス９００は、図に示すようにいくつかの異なる形態に実装することができる。例えば、これは、標準的なサーバ９２０として、またはかかるサーバのグループ中に多重に実装することが可能である。さらに、ラップトップコンピュータ９２２などパーソナルコンピュータ中に実装してもよい。また、ラックサーバシステム９２４の一部として実装してもよい。あるいは、コンピューティングデバイス９００からのコンポーネントを、モバイルコンピューティングデバイス９５０などのモバイルデバイス中の他のコンポーネントと組み合わせることも可能である。かかるデバイスの各々が、コンピューティングデバイス９００およびモバイルコンピューティングデバイス９５０の一つ以上を包含することが可能で、全体のシステムを、相互に通信する複数のコンピューティングデバイスで構成することができる。

モバイルコンピューティングデバイス９５０は、プロセッサ９５２と、メモリ９６４と、ディスプレイ９５４などの入力／出力デバイスと、通信インターフェース９６６と、トランシーバ９６８とを他のコンポーネントと併せ含む。また、モバイルコンピューティングデバイス９５０には、追加のストレージを備えるために、マイクロドライブまたは他のデバイスなどのストレージデバイスを設けてもよい。プロセッサ９５２、メモリ９６４、ディスプレイ９５４、通信インターフェース９６６、トランシーバ９６８の各々は、様々なバスを使って相互接続され、これらコンポーネントのいくつかは、共通のマザーボード上に、または必要に応じて他の仕方で搭載することが可能である。

プロセッサ９５２は、メモリ９６４に格納されている命令を含め、モバイルコンピューティングデバイス９５０内の命令を実行することができる。プロセッサ９５２は、別々の複数のアナログおよびデジタルプロセッサを含むチップのチップセットとして実装することも可能である。プロセッサ９５２は、例えば、ユーザインターフェースの制御、モバイルコンピューティングデバイス９５０によるアプリケーションの実行、モバイルコンピューティングデバイス９５０によるワイヤレス通信など、モバイルコンピューティングデバイス９５０の他のコンポーネントの調整を提供することができる。

プロセッサ９５２は、ディスプレイ９５４に連結された制御インターフェース９５８およびディスプレイインターフェース９５６を介してユーザと交信することが可能である。ディスプレイ９５４は、例えば、ＴＦＴ（Ｔｈｉｎ−Ｆｉｌｍ−Ｔｒａｎｓｉｓｔｏｒ Ｌｉｑｕｉｄ Ｃｒｙｓｔａｌ Ｄｉｓｐｌａｙ（薄膜トランジスタ液晶ディスプレイ））またはＯＬＥＤ（Ｏｒｇａｎｉｃ Ｌｉｇｈｔ Ｅｍｉｔｔｉｎｇ Ｄｉｏｄｅ（有機発光ダイオード））ディスプレイ、または他の適切なディスプレイ技術とすればよい。ディスプレイインターフェース９５６には、グラフィカルおよび他の情報をユーザに提示するために、ディスプレイ９５４を駆動するための適切な回路を含めることが可能である。制御インターフェース９５８は、ユーザからコマンドを受信し、プロセッサ９５２への付託のためそれらコマンドを変換することができる。さらに、外部インターフェース９６２は、モバイルコンピューティングデバイス９５０が他のデバイスとの近距離通信できるように、プロセッサ９５２に通信手段を提供することが可能である。外部インターフェース９６２は、例えば、いくつかの実装においては有線通信手段を、他の実装ではワイヤレス通信手段を提供することが可能であり、また複数のインターフェースの使用も可能である。

メモリ９６４は、モバイルコンピューティングデバイス９５０内の情報を格納する。メモリ９６４は、コンピュータ可読媒体または複数のコンピュータ可読媒体、揮発性メモリユニットまたは複数のユニット、または不揮発性メモリユニットまたは複数のユニットの一つ以上として実装することができる。また、拡張メモリ９７４を設け、拡張インターフェース９７２を介しモバイルコンピューティングデバイス９５０に接続することも可能で、これには、例えば、ＳＩＭＭ（Ｓｉｎｇｌｅ Ｉｎ Ｌｉｎｅ Ｍｅｍｏｒｙ Ｍｏｄｕｌｅ（シングルインラインメモリモジュール））カードインターフェースを含めるとよい。拡張メモリ９７４は、モバイルコンピューティングデバイス９５０に追加のストレージスペースを提供でき、また、モバイルコンピューティングデバイス９５０のために、アプリケーションまたは他の情報を格納することも可能である。特に、拡張メモリ９７４は、上で説明したプロセスを遂行するまたは補完する命令を含むことが可能で、また、重要な情報を含んでもよい。しかして、例えば、拡張メモリ９７４は、モバイルコンピューティングデバイス９５０のためのセキュリティモジュールとして設けてもよく、モバイルコンピューティングデバイス９５０の安全な使用を可能にする命令をプログラムすることもできよう。さらに、ＳＩＭＭカードを使って、安全なアプリケーションを、ハック困難な方法でＳＩＭＭカード上に識別情報を配置するなど、追加の情報と共に備えることができる。

本メモリは、例えば、後記で説明するように、フラッシュメモリおよび／またはＮＶＲＡＭメモリ（ｎｏｎ−ｖｏｌａｔｉｌｅ ｒａｎｄｏｍ ａｃｃｅｓｓ ｍｅｍｏｒｙ（不揮発性ランダムアクセスメモリ））を含んでもよい。いくつかの実装において、命令は情報搬送体中に格納される。これらの命令は、一つ以上の処理デバイス（例えば、プロセッサ９５２）によって実行されたとき、前述の方法など一つ以上の方法を実施する。また、これらの命令は、一つ以上のコンピュータまたは機械可読の媒体（例えば、メモリ９６４、拡張メモリ９７４、またはプロセッサ９５２上のメモリ）など一つ以上のストレージデバイスに格納することが可能である。いくつかの実装において、これらの命令は、例えば、トランシーバ９６８または外部インターフェース９６２を介して、伝播信号で受信することができる。

モバイルコンピューティングデバイス９５０は、通信インターフェース９６６を介してワイヤレスに通信することができ、必要に応じ、該インターフェースにはデジタル信号処理回路を含めればよい。通信インターフェース９６６は、とりわけ、ＧＳＭ（登録商標）音声電話（Ｇｌｏｂａｌ Ｓｙｓｔｅｍ ｆｏｒ Ｍｏｂｉｌｅ ｃｏｍｍｕｎｉｃａｔｉｏｎｓ（汎欧州デジタル移動電話方式））、ＳＭＳ（Ｓｈｏｒｔ Ｍｅｓｓａｇｅ Ｓｅｒｖｉｃｅ（ショートメッセージサービス））、ＥＭＳ（Ｅｎｈａｎｃｅｄ Ｍｅｓｓａｇｉｎｇ Ｓｅｒｖｉｃｅ（強化メッセージサービス））、またはＭＭＳメッセージング（Ｍｕｌｔｉｍｅｄｉａ Ｍｅｓｓａｇｉｎｇ Ｓｅｒｖｉｃｅ（マルチメディアメッセージングサービス））、ＣＤＭＡ（ｃｏｄｅ ｄｉｖｉｓｉｏｎ ｍｕｌｔｉｐｌｅ ａｃｃｅｓｓ（符号分割多重アクセス））、ＴＤＭＡ（ｔｉｍｅ ｄｉｖｉｓｉｏｎ ｍｕｌｔｉｐｌｅ ａｃｃｅｓｓ（時分割多重アクセス））、ＰＤＣ（Ｐｅｒｓｏｎａｌ Ｄｉｇｉｔａｌ Ｃｅｌｌｕｌａｒ（パーソナルデジタルセルラ））、ＷＣＤＭＡ（Ｗｉｄｅｂａｎｄ Ｃｏｄｅ Ｄｉｖｉｓｉｏｎ Ｍｕｌｔｉｐｌｅ Ａｃｃｅｓｓ（広帯域符号分割多重アクセス））、ＣＤＭＡ２０００、またはＧＰＲＳ（Ｇｅｎｅｒａｌ Ｐａｃｋｅｔ Ｒａｄｉｏ Ｓｅｒｖｉｃｅ（汎用パケット無線サービス））など、様々なモードまたはプロトコルの下での通信手段を提供することが可能である。かかる通信は、例えば、無線周波数を用いるトランシーバ９６８を介して行うことができる。さらに、短距離通信は、ブルートゥース（登録商標）、ＷｉＦｉ、または他のこのようなトランシーバを使って行えばよい。加えて、ＧＰＳ（Ｇｌｏｂａｌ Ｐｏｓｉｔｉｏｎｉｎｇ Ｓｙｓｔｅｍ（全地球測位システム））レシーバモジュール９７０は、モバイルコンピューティングデバイス９５０に、さらなるナビゲーションおよび位置関連のワイヤレスデータを提供することができ、これらのデータは、必要に応じ、モバイルコンピューティングデバイス９５０上で実行されるアプリケーションによる使用が可能である。

また、モバイルコンピューティングデバイス９５０は、音声コーデック９６０を用いて音声で通信することも可能で、該コーデックは、ユーザからの音声情報を受信しそれを使用可能なデジタル情報に変換することができる。音声コーデック９６０は、同様に、例えばモバイルコンピューティングデバイス９５０のハンドセット中のスピーカなどを介して、ユーザに向け聴取可能な音声を生成することが可能である。かかる音声は、音声電話からの音声を含んでもよく、録音された音声（例えば、音声メッセージ、音楽ファイルなど）を含んでもよく、また、モバイルコンピューティングデバイス９５０上で作動しているアプリケーションによって生成された音声を含んでもよい。

モバイルコンピューティングデバイス９５０は、図に示されるように、多くの異なる形態で実装することができる。例えば、携帯電話９８０として実装されてもよい。また、スマートフォン９８２、携帯情報端末、または他の類似のモバイルデバイスの部分として実装されてもよい。

本明細書で説明したシステムおよび技法の様々な実装は、デジタル電子回路、集積回路、特別に設計されたＡＳＩＣ（ａｐｐｌｉｃａｔｉｏｎ ｓｐｅｃｉｆｉｃ ｉｎｔｅｇｒａｔｅｄ ｃｉｒｃｕｉｔ（特定用途向け集積回路））、コンピュータハードウェア、ファームウエア、ソフトウェア、および／またはこれらの組み合わせで実現することができる。これらの様々な実装には、少なくとも一つのプログラム可能なプロセッサを含むプログラム可能システム上で、実行可能および／または解釈可能な一つ以上コンピュータプログラム中への実装を含めることができ、前記のプロセッサは、特定用途向けでもまたは汎用向けでもよく、ストレージシステムと、少なくとも一つの入力デバイスと、少なくとも一つの出力デバイスとからデータおよび命令を受信し、これらデバイスにデータおよび命令を送信するように連結することが可能である。

これらのコンピュータプログラム（プログラム、ソフトウェア、ソフトウェアアプリケーション、またはコードとしても知られる）は、プログラム可能なプロセッサに対する機械命令を含み、高レベルの手続き型および／またはオブジェクト指向プログラミング言語、および／またはアセンブリ／機械言語で実装が可能である。本明細書で使用する用語、機械可読媒体およびコンピュータ可読媒体とは、機械命令を機械可読信号として受信する機械可読媒体を含め、プログラム可能プロセッサに機械命令および／またはデータを提供するため使われる任意のコンピュータプログラム製品、装置、および／またはデバイス（例えば、磁気ディスク、光ディスク、メモリ、プログラム可能論理デバイス（ＰＬＤ：Ｐｒｏｇｒａｍｍａｂｌｅ Ｌｏｇｉｃ Ｄｅｖｉｃｅ））を言う。用語、機械可読信号とは、機械命令および／またはデータを、プログラム可能プロセッサに提供するために使われる任意の信号を言う。

ユーザとのやり取りを提供するために、本明細書に記載のシステムおよび技法は、ユーザに情報を表示するためのディスプレイデバイス（例えば、ＣＲＴ（ｃａｔｈｏｄｅ ｒａｙ ｔｕｂｅ（ブラウン管））またはＬＣＤ（ｌｉｑｕｉｄ ｃｒｙｓｔａｌ ｄｉｓｐｌａｙ（液晶ディスプレイ））モニタ）、並びにユーザがコンピュータに入力を供給することを可能にするキーボードおよびポインティングデバイス（例えば、マウスまたはトラックボール）を有するコンピュータ上に実装するとよい。ユーザとのやり取りを提供するために、他の種類のデバイスも同様に用いることができ、例えば、ユーザに提供されるフィードバックは、感覚フィードバックの任意の形態（例えば、視覚フィードバック、音声フィードバック、または触覚フィードバック）とすることが可能で、また、ユーザからの入力は、音響、発話、または接触入力を含め、任意の形態で受信することが可能である。

本明細書に記載のシステムおよび技法は、バックエンドコンポーネント（例えば、データサーバとして）を含む、またはミドルウェアコンポーネント（例えば、アプリケーションサーバ）を含む、またはフロントエンドコンポーネント（例えば、ユーザが、それを介して本明細書に記載のシステムおよび技法の実装とやり取りできる、グラフィカルユーザインターフェース、またはウェブブラウザを有するクライアントコンピュータ）、またはかかるバックエンド、ミドルウェア、またはフロンドエンドコンポーネントに任意の組み合せを含む、コンピューティングシステム中に実装するのがよい。システムのこれらコンポーネントは、デジタルデータ通信（例えば、通信ネットワーク）の任意の形態または媒体によって相互接続することが可能である。通信ネットワークの例には、ローカルエリアネットワーク（ＬＡＮ：ｌｏｃａｌ ａｒｅａ ｎｅｔｗｏｒｋ）、広域ネットワーク（ＷＡＮ：ｗｉｄｅ ａｒｅａ ｎｅｔｗｏｒｋ）およびインターネットが含まれる。

コンピューティングシステムはクライアントとサーバとを含み得る。クライアントとサーバとは、一般に相互に離間しており、通常、通信ネットワークを介してやり取りをする。クライアントとサーバとの関係は、それぞれのコンピュータ上で実行されているコンピュータプログラムおよび相互にクライアント−サーバ関係を有することに基づいて成立する。

上でいくつかの実装について詳細を説明してきたが、他の変更案も可能である。例えば、或るクライアントアプリケーションが、デリゲートにアクセスするとして説明されているが、他の実装では、一つ以上のサーバ上で実行されるアプリケーションなど、一つ以上のプロセッサによって実装される他のアプリケーションよってそのデリゲートが用いられてもよい。さらに、図面に表された論理フローは、必要な結果を達成するために、示された特定の順序またはシーケンシャルな順序を必要としない。加えて、表されたフローに他のアクションを加えることが可能で、またはフローからアクションを排除することが可能であり、記載されシステムに他のコンポーネントを加えることまたはシステムからコンポーネントを削除することも可能である。したがって、他の実装も添付の特許請求の範囲内である。

Claims (20)

1. セキュリティ制御デバイスと、
   一つ以上のアセットと、
   前記セキュリティ制御デバイスおよび前記一つ以上のアセットと通信するセキュリティコントローラであって、前記セキュリティコントローラは、処理エンジンを含み、前記処理エンジンは、
   前記セキュリティ制御デバイスに対する物理−論理属性マッピングを作成し、前記セキュリティ制御デバイスに関連付けられたセキュリティサービスディスクリプションを生成することにより、前記セキュリティ制御デバイスを登録し、
   前記一つ以上のアセットの各々に対する物理−論理属性マッピングを作成し、前記一つ以上のアセットの各々に対するセキュリティサービス要求事項を生成することによって、前記一つ以上のアセットを登録し、
   サービスに対する要求に基づいてセキュリティサービスのバインディングを生成し、前記処理エンジンは前記セキュリティサービスのバインディングをセキュリティ制御コマンドのセットに変換し、前記セキュリティ制御コマンドを前記セキュリティ制御デバイスに通信するように動作可能に構成される、
   ソフトウェア定義型セキュリティシステム。
2. 前記セキュリティ制御デバイスは、ファイアウォールと、侵入検知システムと、アイデンティティおよびアクセスマネジメントシステムと、のうちの一つである、請求項１に記載のシステム。
3. 前記一つ以上のアセットは、サーバと、ＶＰＮクライアントおよびサーバと、外部コンピューティングデバイスと、モバイルコンピューティングデバイスと、のうちの一つを含む、請求項１に記載のシステム。
4. 前記処理エンジンは、
   セキュリティイベントを識別するデータを受信し、
   前記セキュリティイベントに対して実施するために前記セキュリティコントローラに対する一つ以上のアクションを識別するプレイブックにアクセスし、
   前記セキュリティイベントに応じて前記一つ以上のアクションを実施する、
   ようにさらに構成される、請求項１に記載のシステム。
5. 前記セキュリティイベントは、侵入検知制御、ネットワークトポロジ変更、またはサーバ故障からのイベントを含む、請求項４に記載のシステム。
6. 前記セキュリティサービスのバインディングを生成することは、前記セキュリティイベントに応じて前記一つ以上のアクションを実施することを含む、請求項４に記載のシステム。
7. 前記セキュリティ制御デバイスに対する前記物理−論理属性マッピングは、前記セキュリティ制御デバイスに対するＩＰアドレス−ホスト名マッピングを含み、
   前記一つ以上のアセットの各々に対する前記物理−論理属性マッピングは、前記一つ以上のアセットの各々に対するＩＰアドレス−ホスト名マッピングを含む、
   請求項１に記載のシステム。
8. 前記処理エンジンは、
   前記一つ以上のアセットの一つへの物理属性の変更を示すデータを受信し、
   前記一つ以上のアセットの一つへの前記物理属性の変更を示す前記データを受信することに応じて、前記一つ以上のアセットの前記一つに対するセキュリティサービス要求事項を識別し、
   前記一つ以上のアセットの一つに対する前記セキュリティサービス要求事項に基づいて、前記一つ以上のアセットの一つに対するセキュリティサービスのバインディングを生成する、
   ようにさらに構成される、請求項１に記載のシステム。
9. 前記一つ以上のアセットの一つに対する前記セキュリティサービスのバインディングは、前記一つ以上のアセットの一つへの前記物理属性の前記変更を示す前記データを受信した後、ユーザの入力なしに自動的に生成される、請求項８に記載のシステム。
10. セキュリティ制御デバイスおよび一つ以上のアセットと通信するセキュリティコントローラによって、前記セキュリティ制御デバイスに対する物理−論理属性マッピングを作成し、前記セキュリティ制御デバイスに関連付けられたセキュリティサービスディスクリプションを生成することにより、前記セキュリティ制御デバイスを登録するステップと、
    前記一つ以上のアセットの各々に対する物理−論理属性マッピングを作成し、前記一つ以上のアセットの各々に対するセキュリティサービス要求事項を生成することによって、前記一つ以上のアセットを登録するステップと、
    サービスに対する要求に基づいて、セキュリティサービスのバインディングを生成するステップと、
    前記セキュリティサービスのバインディングをセキュリティ制御コマンドのセットに変換するステップと、
    前記セキュリティ制御コマンドを前記セキュリティ制御デバイスに通信するステップと、
    を含むコンピュータ実装の方法。
11. 前記セキュリティ制御デバイスは、ファイアウォールと、侵入検知システムと、アイデンティティおよびアクセスマネジメントシステムと、のうちの一つである、請求項１０に記載の方法。
12. 前記一つ以上のアセットは、サーバと、ＶＰＮクライアントおよびサーバと、外部コンピューティングデバイスと、モバイルコンピューティングデバイスと、のうちの一つを含む、請求項１０に記載の方法。
13. セキュリティイベントを識別するデータを受信するステップと、
    前記セキュリティイベントに対して実施するために前記セキュリティコントローラに対して一つ以上のアクションを識別するプレイブックにアクセスするステップと、
    前記セキュリティイベントに応じて前記一つ以上のアクションを実施するステップと、
    を含む、請求項１０に記載の方法。
14. 前記セキュリティイベントは、侵入検知制御、ネットワークトポロジ変更、またはサーバ故障からのイベントを含む、請求項１３に記載の方法。
15. 前記セキュリティサービスのバインディングを生成するステップは、前記セキュリティイベントに応じて前記一つ以上のアクションを実施するステップを含む、請求項１３に記載の方法。
16. 前記セキュリティ制御デバイスに対する前記物理−論理属性マッピングは、前記セキュリティ制御デバイスに対するＩＰアドレス−ホスト名マッピングを含み、
    前記一つ以上のアセットの各々に対する前記物理−論理属性マッピングは、前記一つ以上のアセットの各々に対するＩＰアドレス−ホスト名マッピングを含む、
    請求項１０に記載の方法。
17. 前記一つ以上のアセットの一つへの物理属性の変更を示すデータを受信するステップと、
    前記一つ以上のアセットの一つへの前記物理属性の変更を示す前記データを受信することに応じて、前記一つ以上のアセットの一つに対するセキュリティサービス要求事項を識別するステップと、
    前記一つ以上のアセットの一つに対する前記セキュリティサービス要求事項に基づいて、前記一つ以上のアセットの一つに対するセキュリティサービスのバインディングを生成するステップと、
    を含む、請求項１０に記載の方法。
18. 前記一つ以上のアセットの一つに対する前記セキュリティサービスのバインディングは、前記一つ以上のアセットの一つへの前記物理属性の変更を示す前記データを受信した後、ユーザの入力なしに自動的に生成される、請求項１７に記載の方法。
19. 一つ以上のコンピュータによって実行可能な命令を含むソフトウェアを格納している非一時的なコンピュータ可読媒体であって、実行すると、前記一つ以上のコンピュータに、
    セキュリティ制御デバイスおよび一つ以上のアセットと通信するセキュリティコントローラによって、前記セキュリティ制御デバイスに対する物理−論理属性マッピングを作成し、前記セキュリティ制御デバイスに関連付けられたセキュリティサービスディスクリプションを生成することにより、前記セキュリティ制御デバイスを登録するステップと、
    前記一つ以上のアセットの各々に対する物理−論理属性マッピングを作成し、前記一つ以上のアセットの各々に対するセキュリティサービス要求事項を生成することによって、前記一つ以上のアセットを登録するステップと、
    サービスに対する要求に基づいて、セキュリティサービスのバインディングを生成するステップと、
    前記セキュリティサービスのバインディングをセキュリティ制御コマンドのセットに変換するステップと、
    前記セキュリティ制御コマンドを前記セキュリティ制御デバイスに伝達するステップと、
    を含むオペレーションを実施させる、
    媒体。
20. 前記セキュリティ制御デバイスは、ファイアウォールと、侵入検知システムと、アイデンティティおよびアクセスマネジメントシステムと、のうちの一つである、請求項１９に記載の媒体。