(57)【要約】【課題】  性能低下や開発負担を招くことなく、リアルタイムで不正アクセスを検知して適切な防衛対策を実施可能とする。【解決手段】  イベント監視部４は、設定ファイルＫに従って、不正アクセスの兆候を常時監視し、兆候が発生した場合、後述するソフトウェア制御部６に通知する。ソフトウェア制御部６は、上記イベント監視部４からの通知を受けると、設定ファイルＡに従って、動的にスケジューリングして定期実行型ソフトウェア７を実行させる。定期実行型ソフトウェア７は、ソフトウェア制御部６の制御に従って、計算量の多い詳細処理に基づいて不正アクセス検知を行う。対策実施部８は、ソフトウェア制御部６からの依頼に従って、検知された不正アクセスに対する防御対策を実行する。【選択図】    図１
2006065835.tif 000002
【特許請求の範囲】
【請求項１】
ＯＳ空間であるカーネル空間とアプリケーション空間であるＡＰ空間からなるコンピュータシステムにおける不正アクセス対策制御装置であって、
前記カーネル空間において、
不正アクセスの兆候となるイベントを定義した監視イベント定義テーブルに基づいて、ＯＳで実行されるイベントを監視し、不正アクセスの兆候となるイベントが発生した場合に、ＡＰ空間に対し通知を行うイベント監視部を備え、
前記ＡＰ空間において、
不正アクセス検知を行う不正アクセス検知手段と、
前記イベント監視部からの通知を受け、前記不正アクセス検知手段を実行するソフトウェア制御部と、
を備えることを特徴とする不正アクセス対策制御装置。
【請求項２】
前記ＡＰ空間において、
不正アクセスに対する対策を行う対策実施手段を備え、
前記ソフトウェア制御部は、前記不正アクセス検知手段による不正アクセス検知の結果を取得し、前記不正アクセス検知の結果に基づいて対策を特定し、前記対策実施手段に前記対策を通知することを特徴とする請求項１に記載の不正アクセス対策制御装置。
【請求項３】
前記ＡＰ空間において、
不正アクセスに対する防御対策を実行する対策実行手段を備え、
前記対策実施手段は、通知された前記対策に基づいて、前記対策実行手段を実行させることを特徴とする請求項２に記載の不正アクセス対策制御装置。
【請求項４】
前記ＡＰ空間において、
不正アクセスの履歴に基づいて防御対策の変更の有無を決定する変更決定手段と、
前記変更決定手段による防御対策の変更に基づいて不正アクセスに対して実行する対策実行手段を動的に変更する動的設定変更手段とを備え、
前記対策実施手段は、前記動的設定変更手段による変更に基づいて、前記対策実行手段を実行させることを特徴とする請求項３記載の不正アクセス対策制御装置。
【請求項５】
ＯＳ空間であるカーネル空間とアプリケーション空間であるＡＰ空間からなるコンピュータシステムにおける不正アクセス対策を行わせるプログラムであって、
前記カーネル空間において、
不正アクセスの兆候となるイベントを定義した監視イベント定義テーブルに基づいて、ＯＳで実行されるイベントを監視し、不正アクセスの兆候となるイベントが発生した場合に、ＡＰ空間に対し通知を行うステップと、
前記ＡＰ空間において、
前記ＯＳ空間からの通知を受け、前記不正アクセス検知処理を実行するステップとをコンピュータに実行させることを特徴とする不正アクセス対策制御プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、不正アクセス対策制御装置および不正アクセス対策制御プログラムに関する。
【背景技術】
【０００２】
不正アクセスには、攻撃者が端末内部から攻撃を行う場合（以下、内部攻撃という）と、端末外部から攻撃を行う場合（以下、外部攻撃という）とがある。従来、内部攻撃への対策として、管理者またはＯＳに標準装備される特定のアプリケーションソフトウェアが定期的にそのソフトウェアを実行することによって、不正アクセスの発生を検査する形式のソフトウェアが多く用いられてきた。一部のウィルス対策ソフトウェア、ファイル改竄検知ソフトウェア、セキュリティポリシ監視ソフトウェア等、主に端末内部で発生する不正アクセス検知を対象としたソフトウェアが知られている。以下、このようなソフトウェアを定期実行型ソフトウェアという。
【０００３】
定期実行型ソフトウェアは、不正アクセスが発生してから一定の時刻を経過した後に検査を実行するため、不正アクセスの発見が遅い。したがって、不正アクセスを行う攻撃者は、不正アクセスが検出され、管理者が対応策を実施するまで、システムに対して被害を与え続けることが可能であり、被害が拡大するという問題がある。
【０００４】
このため、求められる技術要件は、以下の通りである。
要件１  リアルタイムに内部攻撃を検知できること。
要件２  検知だけでなく、攻撃に対する防御対策も自動で実施できること。
【０００５】
上記要件１、要件２を満たす内部攻撃への既存対応策としては、例えば、特定のファイルへのアクセスを、ＯＳ内で検知して自動的にアクセス制御ルールを変更する技術がある（例えば特許文献１参照）。
【０００６】
また、従来技術として、不正アクセスを検知した後、システムを防御する技術が提案されている（例えば技術文献２参照）。これらシステムを防御する機能を対策実行機能と呼ぶ。この対策実行機能は、上述した不正アクセスを検知する定期実行型ソフトウェアが生成する警告内から、防御を行うために必要な情報を抽出して防御を実行する。また、これらの対策実行機能は、不正アクセス検知ソフトウェアの警告を入力するため、ソフトウェア毎に開発されている。
【０００７】
また、従来、対策実行機能を使用する上での設定は、不正アクセスを検知する定期実行型ソフトウェアが生成する警告毎に、実施する対策を設定する形式であり、事前に設定した内容がＮ回発生した場合に、警告を出力する技術が提案されている（例えば特許文献３参照）。
【特許文献１】特開２００４−１２６６３４号公報
【特許文献２】特開２００１−５７５５４号公報
【特許文献３】特開２００３−２３３５２１号公報
【発明の開示】
【発明が解決しようとする課題】
【０００８】
しかしながら、特許文献１の従来技術では、以下の問題がある。
ＯＳ内で不正アクセスを検知する上で、計算量の多い検知方式を導入すると、大きな性能低下につながるため、簡易な検知方式に頼らざるを得ない。したがって、ＯＳ内における技術であるゆえにリアルタイムに不正アクセス検知は可能であるが、検知可能な攻撃種類について問題が生じる。また、新しい不正アクセスが発生したときに、検知するためには、「不正アクセスの兆候（以下、シグネチャという）を導入しなければならないが、シグネチャは、独自開発しなければならず、開発コストがかかるという問題がある。
【０００９】
そこで、さらに求められる要件として以下のものが加わる。
要件３  複雑な検知アルゴリズムを導入できること。
要件４  シグネチャを独自開発しなくてもよいこと。
また、特許文献２の従来技術では、対策実行機能を開発するコストがかかるという問題がある。さらに、特許文献３の従来技術では、防御に関する設定を全て事前に行う必要があるため、攻撃発生時の状況（過去の攻撃履歴や、攻撃発生時のシステム状況等）を踏まえて防御ができないという問題がある。したがって、常に一定の防御しか行わず、効果的な防御ができていない。
【００１０】
本発明は、上記問題を解決すべくなされたもので、その目的は、性能低下や開発負担を招くことなく、リアルタイムで不正アクセスを検知することができ、また、不正アクセスに対して適切な防衛対策を実施することができる不正アクセス対策制御装置および不正アクセス対策制御プログラムを提供することにある。
【課題を解決するための手段】
【００１１】
上述した課題を解決するために、本発明は、ＯＳ空間であるカーネル空間とアプリケーション空間であるＡＰ空間からなるコンピュータシステムにおける不正アクセス対策制御装置であって、前記カーネル空間において、不正アクセスの兆候となるイベントを定義した監視イベント定義テーブルに基づいて、ＯＳで実行されるイベントを監視し、不正アクセスの兆候となるイベントが発生した場合に、ＡＰ空間に対し通知を行うイベント監視部を備え、前記ＡＰ空間において、不正アクセス検知を行う不正アクセス検知手段と、前記イベント監視部からの通知を受け、前記不正アクセス検知手段を実行するソフトウェア制御部と、を備えることを特徴とする不正アクセス対策制御装置である。
【００１２】
本発明は、上記の発明において、前記ＡＰ空間において、不正アクセスに対する対策を行う対策実施手段を備え、前記ソフトウェア制御部は、前記不正アクセス検知手段による不正アクセス検知の結果を取得し、前記不正アクセス検知の結果に基づいて、対策を特定し、前記対策実施手段に前記対策を通知することを特徴とする。
【００１３】
本発明は、上記の発明において、前記ＡＰ空間において、不正アクセスに対する防御対策を実行する対策実行手段を備え、前記対策実施手段は、通知された前記対策に基づいて、前記対策実行手段を実行させることを特徴とする。
【００１４】
本発明は、上記の発明において、前記ＡＰ空間において、不正アクセスの履歴に基づいて防御対策の変更の有無を決定する変更決定手段と、前記変更決定手段による防御対策の変更に基づいて不正アクセスに対して実行する対策実行手段を動的に変更する動的設定変更手段とを備え、前記対策実施手段は、前記動的設定変更手段による変更に基づいて、前記対策実行手段を実行させることを特徴とする。
【００１５】
また、本発明は、ＯＳ空間であるカーネル空間とアプリケーション空間であるＡＰ空間からなるコンピュータシステムにおける不正アクセス対策を行わせるプログラムであって、前記カーネル空間において、不正アクセスの兆候となるイベントを定義した監視イベント定義テーブルに基づいて、ＯＳで実行されるイベントを監視し、不正アクセスの兆候となるイベントが発生した場合に、ＡＰ空間に対し通知を行うステップと、前記ＡＰ空間において、前記ＯＳ空間からの通知を受け、前記不正アクセス検知処理を実行するステップとをコンピュータに実行させることを特徴とする不正アクセス対策制御プログラムである。
【発明の効果】
【００１６】
この発明によれば、カーネル空間において、イベント監視部により、不正アクセスの兆候となるイベントを定義した監視イベント定義テーブルに基づいて、ＯＳで実行されるイベントを監視し、不正アクセスの兆候となるイベントが発生した場合に、ＡＰ空間に対し通知を行い、ＡＰ空間において、ソフトウェア制御部により、イベント監視部からの通知を受け、前記不正アクセス検知を行う不正アクセス検知手段を実行する構成となっている。したがって、性能低下や開発負担を招くことなく、リアルタイムで不正アクセスを検知することができるという利点が得られる。
【００１７】
また、本発明によれば、ＡＰ空間において、不正アクセスに対する対策を行う対策実施手段を備えており、ソフトウェア制御部は、不正アクセス検知手段による不正アクセス検知の結果を取得し、不正アクセス検知の結果に基づいて、対策を特定し、対策実施手段に対策を通知する構成となっている。したがって、不正アクセスに対して適切な防御対策を実施することができるという利点が得られる。
【００１８】
また、本発明によれば、ＡＰ空間において、不正アクセスに対する防御対策を実行する対策実行手段を備えており、対策実施手段は、通知された前記対策に基づいて、対策実行手段を実行させる構成となっている。したがって、既存の対策実行機能を再利用することが可能となり、対策実行機能を開発するコストの削減を実現することができるという利点が得られる。
【００１９】
また、本発明によれば、ＡＰ空間において、不正アクセスの履歴に基づいて防御対策の変更の有無を決定する変更決定手段と、変更決定手段による防御対策の変更に基づいて不正アクセスに対して実行する対策実行手段を動的に変更する動的設定変更手段とを備えており、対策実施手段は、動的設定変更手段による変更に基づいて、対策実行手段を実行させる構成となっている。したがって、不正アクセス発生時の状況にあわせて、実施する防御が動的に変更することができ、事前に全て設定する場合と比較して効果的な防御を実現することができるという利点が得られる。
【発明を実施するための最良の形態】
【００２０】
以下、本発明の一実施形態による不正アクセス対策制御装置を、図面を参照して説明する。
【００２１】
Ａ．実施形態の構成
図１は、本実施形態による不正アクセス対策制御装置を適用したコンピュータシステムの構成を示す概略ブロック図である。図において、コンピュータシステム１は、ＯＳであるカーネル空間２とアプリケーションであるＡＰ空間３とからなる。カーネル空間２には、イベント監視部４およびイベント処理部５を含む。イベント監視部４は、設定ファイルＫに従って、システムに対するイベント発生を監視する。特に、本実施形態では、不正アクセスの兆候を常時監視し、兆候が発生した場合、後述するソフトウェア制御部６に通知する。イベント処理部５は、イベント監視部４により検知された（通常）イベントに対応する処理を実行する。は、イベント監視部４により検知された（通常）イベントに対応する処理を実行する。
【００２２】
ＡＰ空間３は、ソフトウェア制御部６、定期実行型ソフトウェア７および対策実施部８を含む。ソフトウェア制御部６は、上記イベント監視部４からの通知を受けると、設定ファイルＡに従って、動的にスケジューリングして定期実行型ソフトウェア７を実行させて、結果を回収し、該結果に従って、対策実施部８に対して防御対策実行を依頼する。定期実行型ソフトウェア７は、不正アクセス検知を行う手段であって、ソフトウェア制御部６による動的スケジュールに従って、計算量の多い詳細処理に基づいて不正アクセス検知を行う。ここでは定期実行型を想定しているが、必ずしも定期実行型でなくてもよい。対策実施部８は、ソフトウェア制御部６からの依頼に従って防御対策を実行する。防御対策としては、例えば、ファイアウォールのフィルタリングルール変更による通信遮断、セッション遮断、ｆｏｒｅｎｓｉｃｓ機能（不正アクセスを行ったプロセスの詳細なログを取得）、攻撃用プロセスの起動を阻止（事前に定義したプロセス以外のプロセス起動を禁止）、アカウントのロックアウト、攻撃者への警告機能（攻撃者に警告を送ることで、攻撃を止めさせることを目的とする機能）、ユーザ任意のコマンド実行などがある。また、９−１〜９−ｎは、外部デバイスである。
【００２３】
ここで、上記不正アクセスの兆候とは、以下を想定している。
（ａ）ＯＳやサーバプログラムの、プログラムおよび設定ファイルへの書込み・消去
（ｂ）ＯＳの起動時に、実行されるプログラム以外のプログラムの起動
（ｃ）ＯＳの起動時に、実行されるデーモンプログラムの停止
（ｄ）ユーザ毎に割り当てられる設定ファイル
（ｅ）その他、管理者が定義したファイルの書き込み・消去
（ｆ）その他、管理者が定義したプログラムの実行・停止
【００２４】
次に、上述した設定ファイルＫについて説明する。該設定ファイルＫは、監視イベント情報テーブル（ＥＩＴ）、監視イベントテーブル（ＥＴ）、例外イベントテーブル（ＥＥＴ）および禁止イベントテーブル（ＰＥＴ）を含む。
【００２５】
ここで、図２（ａ）は、監視イベント情報テーブル（ＥＩＴ）を示し、図２（ｂ）は、監視イベントテーブル（ＥＴ）を示す概念図である。監視イベント情報テーブル（ＥＩＴ）は、監視するイベントの種類を管理するための情報であり、イベント毎に固有に割り当てられたイベントＩＤと、それぞれのイベント名と、イベントに対応する監視対象処理（システムコール）へのアドレスとからなる。監視イベントテーブル（ＥＴ）は、監視するイベントのパラメータを管理するための情報であり、イベントＩＤと、それぞれの監視対象名とからなる。イベントの種類とパラメータとを１組として監視イベントを構成している。
【００２６】
また、図３（ａ）は、例外イベントテーブル（ＥＥＴ）を示し、図３（ｂ）は、禁止イベントテーブル（ＰＥＴ）を示す概念図である。例外イベントテーブル（ＥＥＴ）は、監視対象の例外となるものを管理するための情報であり、イベントＩＤと、それぞれの例外対象名と、例外条件とからなる。例えば、ＥＴのイベント名にディレクトリが指定された場合、ディレクトリ以下のファイルで監視対象外としたいものを記述する。禁止イベントテーブル（ＰＥＴ）は、イベント実行を禁止にするものを指定するための情報であり、イベントＩＤと、それぞれの禁止対象名と、禁止条件とからなる。例えば、定期実行型ツールへの書き込み、消去などを記述している。
【００２７】
次に、上述した設定ファイルＡについて説明する。該設定ファイルＡは、共通設定（ＣＣ）、監視イベント情報テーブル（ＥＩＴ’）、防御処理情報テーブル（ＤＩＴ）および防御処理テーブル（ＤＴ）を含む。
【００２８】
ここで、図４（ａ）は、共通設定（ＣＣ）を示し、図４（ｂ）は、監視イベント情報テーブル（ＥＩＴ’）を示す概念図である。共通設定（ＣＣ）は、定期実行型ソフトウェアに関する情報を管理するための情報であり、定期実行ソフトウェア名、定期実行ソフトウェアへのパス名、定期実行ソフトウェアを実行する際に必要なオプション、定期実行ソフトウェアの実行結果から不正アクセスと判定するための基準（正規表現で記述）からなる。監視イベント情報テーブル（ＥＩＴ’）は、イベントＩＤと、それぞれのイベント名とからなる。
【００２９】
次に、図５（ａ）は、防御処理情報テーブル（ＤＩＴ）を示し、図５（ｂ）は、防御処理テーブル（ＤＴ）を示す概念図である。防御処理情報テーブル（ＤＩＴ）は、防御処理に関する情報を管理するための情報であり、防御対策ＩＤと、それぞれの防御対策名と、防御対策処理へのアドレスと、パラメータ種類とからなる。防御処理テーブル（ＤＴ）は、イベントＩＤと、それぞれの監視対象名と、防御対策ＩＤとからなる。
【００３０】
Ｂ．実施形態の動作
次に、上述した実施形態の動作について説明する。ここで、図６は、本実施形態の動作を説明するためのデータフローを示すブロック図である。イベント監視部４は、設定ファイルＫに従って、システムに対するイベント発生を監視し、不正アクセスの兆候が発生した場合、ソフトウェア制御部６に通知する（Ｓ１）。ソフトウェア制御部６は、イベントに応じて、定期実行型ソフトウェア７を実行させる（Ｓ２）。定期実行型ソフトウェア７は、ソフトウェア制御部６による動的スケジュールに従って、計算量の多い詳細処理に基づいて不正アクセス検知を行う。ソフトウェア制御部６は、結果を回収し（Ｓ３）、該結果に従って、対策実施部８に対して防御対策実行を依頼する（Ｓ４）。対策実施部８は、ソフトウェア制御部６からの依頼に従って防御対策を実行する（Ｓ５）。
【００３１】
次に、上述した動作を詳細に説明する。ここで、図７および図８は、イベント監視部４の動作を説明するためのフローチャートである。イベント監視部４において、ＡＰ空間３におけるプログラムがシステムコールを呼び出した（リクエストが発行された）ときに、イベント監視部４には、ＯＳで実行されるイベントＥ、該イベントを実行するために必要なパラメータＰが入力される。イベント監視部４では、まず、イベントＥが図２（ａ）に示す監視イベント情報テーブル（ＥＩＴ）のイベント名にマッチするか否かを判断する（Ｓａ１）。そして、マッチするものがない場合には、当該処理を終了する。
【００３２】
一方、マッチするものがあった場合には、マッチしたエントリのイベントＩＤ（．Ｅ）を処理ルーチンへ渡し、マッチしたエントリの「監視対象処理へのアドレス」に記載される処理を実行する（Ｓａ２）。なお、該ステップＳａ２の詳細な処理については後述する。
【００３３】
そして、上記ステップＳａ２で、通知しないという結果が得られた場合には、当該処理を終了する。一方、通知するという結果が得られた場合には、ソフトウェア制御部６に例えば、「監視対象名：ｐｉｄ＝１２３：ｕｉｄ＝１２：イベントＩＤ」という形式をとる第１の形式で通知する（Ｓａ３）。そして、当該処理を終了する。
【００３４】
次に、上記ステップＳａ２の処理について説明する。まず、パラメータＰが、図２（ｂ）に示す監視イベントテーブル（ＥＴ）の監視対象名の形式と異なる場合、ＯＳ内の情報を参照し、パラメータＰを変換する（Ｓｂ１）。例えば、パラメータＰがプロセスＩＤであるが、監視対象名がプロセス名を示す場合に変換する。
【００３５】
次に、図３（ｂ）に示す禁止イベントテーブル（ＰＥＴ）を参照し、禁止イベントテーブル（ＰＥＴ）のイベントＩＤ＝＝Ｅと、禁止対象名＝＝Ｐとが成立するエントリがあるかチェックする（Ｓｂ２）。そして、上記条件が成立するエントリがある場合には、実行禁止イベントと判断し、ＡＰ空間にＥ、Ｐで示されるイベントが失敗したことを示す値を返し（Ｓｂ５）、通知なしとして当該処理を終了する。一方、上記条件が成立するエントリがない場合には、図２（ｂ）に示す監視イベントテーブル（ＥＴ）を参照し、監視イベントテーブル（ＥＴ）のイベントＩＤ＝＝Ｅと、Ｐ＝＝監視イベントテーブル（ＥＴ）の監視対象名とが成立するエントリがあるかチェックする（Ｓｂ３）。そして、上記条件が成立するエントリがない場合には、通知なしとして当該処理を終了する。
【００３６】
一方、上記条件が成立するエントリがあった場合には、図３（ａ）に示す例外イベントテーブル（ＥＥＴ）を参照し、例外イベントテーブル（ＥＥＴ）のイベントＩＤ＝＝Ｅと、Ｐ＝＝例外イベントテーブル（ＥＥＴ）の例外対象名とが成立するエントリがあるかチェックする（Ｓｂ４）。そして、上記条件が成立するエントリがある場合には、通知なしとして当該処理を終了する。なお、いずれの場合においても、監視イベント情報テーブル（ＥＩＴ）のイベントＩＤ＝＝Ｅの監視対象処理へのアドレスで示される処理を実行し、ＡＰ空間に結果を返す（Ｓｂ６）。
【００３７】
次に、ソフトウェア制御部６の動作について説明する。ここで、図９は、ソフトウェア制御部６の動作を説明するためのフローチャートである。ソフトウェア制御部６には、イベント監視部からの通知が入力される。ソフトウェア制御部６では、まず、図４（ａ）に示す共通設定（ＣＣ）の情報を用いて定期実行型ソフトウェアを実行する（Ｓｃ１）。次に、定期実行型ソフトウェアの実行結果を回収し（Ｓｃ２）、回収した結果が共通設定（ＣＣ）の不正アクセス判定基準にマッチするか判定する（Ｓｃ３）。そして、不正アクセス判定基準にマッチしない場合、すなわち不正アクセスでない場合には、当該処理を終了する。
【００３８】
一方、不正アクセス判定基準にマッチした場合、すなわち不正アクセスである場合には、図４（ｂ）に示す監視イベント情報テーブル（ＥＩＴ’）と図５（ｂ）に示す防御処理テーブル（ＤＴ）とを参照し、監視イベント情報テーブル（ＥＩＴ’）のイベントＩＤ＝＝Ｅと、防御処理テーブル（ＤＴ）の監視対象名＝＝Ｐとが成立するエントリがあるかチェックする（Ｓｃ４）。そして、上記条件が成立するエントリがない場合には、当該処理を終了する。一方、上記条件が成立するエントリがある場合には、対策実施部８に、例えば、「監視対象名：ｐｉｄ＝１２３：ｕｉｄ＝１２：防御対策ＩＤ」という形式をとる第２の形式で通知する（Ｓｃ５）。そして、当該処理を終了する。
【００３９】
次に、対策実施部８の動作について説明する。ここで、図１０は、対策実施部８の動作を説明するためのフローチャートである。対策実施部８には、ソフトウェア制御部６からの通知が入力される。対策実施部８では、マッチした防御処理テーブル（ＤＴ）の防御対策ＩＤ＝＝図５（ａ）に示す防御処理情報テーブル（ＤＩＴ）の防御対策ＩＤとなる箇所を探し（Ｓｄ１）、マッチした箇所の「防御対策処理へのアドレス」にある処理を実行する（Ｓｄ２）。そして、当該処理を終了する。
【００４０】
Ｃ．実施例
ユーザＩＤ（ｕｉｄ）が３のユーザがプロセスＩＤ（ｐｉｄ）＝＝２１００のプロセスで攻撃を実施する場合について説明する。
【００４１】
攻撃者の行為は、／ｂｉｎ／ｓｕに対して、正常動作させないような書込みを行い、ファイルを閉じる（書込み実行のためにＯＳに向け、リクエスト（イベント）、つまり、「ｃｌｏｓｅ  閉じるファイル番号」が発行される）。
【００４２】
また、イベント監視部４の処理は、次のようになる。上記書込みに対して、イベント監視部４がイベントを受ける。次に、ｃｌｏｓｅが監視イベント情報テーブル（ＥＩＴ）のイベント名にあるかチェックする（イベントＩＤ＝＝２の箇所にある）（Ｓａ１）。監視イベントテーブル（ＥＴ）のイベントｃｌｏｓｅに対するパラメータは、「ファイル番号（ｆｉｌｅ  ｄｅｓｃｒｉｐｔｏｒ）」であり、ファイル名ではない。そこで、ＯＳ内の情報を用いて、／ｂｉｎ／ｓｕが閉じられるファイルであることを判断する（Ｓａ２：Ｓｂ１）。
【００４３】
そして、禁止イベントテーブル（ＰＥＴ）のイベントＩＤ＝＝２となる箇所であり、かつ禁止イベントテーブル（ＰＥＴ）の監視対象名＝＝／ｂｉｎ／ｓｕである箇所を探す（この場合、発見できない）（Ｓｂ２）。次に、監視イベントテーブル（ＥＴ）のイベントＩＤ＝＝２となる箇所であり、かつ監視イベントテーブル（ＥＴ）の監視対象名＝＝／ｂｉｎ／ｓｕである箇所を探す（一番上のエントリにある）（Ｓｂ３）。また、例外イベントテーブル（ＥＥＴ）のイベントＩＤ＝＝２となる箇所であり、かつ例外イベントテーブル（ＥＥＴ）の監視対象名＝＝／ｂｉｎ／ｓｕである箇所を探す（この場合、発見できない）（Ｓｂ４）。その後、監視イベント情報テーブル（ＥＩＴ）のイベントＩＤ＝＝２の監視対象処理へのアドレスで示される処理（０ｘＣ０１１９９２２）を実行し、結果をＡＰ空間に返す（Ｓｂ６）。そして、第１の形式で、すなわち、「／ｂｉｎ／ｓｕ：ｐｉｄ＝２１００：ｕｉｄ＝３：２」となる形式で監視イベントの発生をソフトウェア制御部６に通知する（Ｓａ３）。
【００４４】
また、ソフトウェア制御部６の処理は、次のようになる。イベント監視部４からの通知を受け取り、共通設定（ＣＣ）の情報を用いて、定期実行ソフトウェアを実行し（Ｓｃ１）、結果を回収する（Ｓｃ２）。図１１は、定期実行ソフトウェアを実行したときの結果の一例を示す図である。この例において、不正アクセスと判定するための基準は、”＊［ＢＡＤ］である。図１１においては、／ｂｉｎ／ｓｕにおいて［ＢＡＤ］となっているので、ここが不正ア屈す判定基準にマッチすることになる（Ｓｃ３）。次に、イベント監視部４からの通知に含まれるイベントＩＤ（＝＝２）が監視イベント情報テーブル（ＥＩＴ’）にあるかチェックする（この場合、３番目のエントリにある）。次に、防御処理テーブル（ＤＴ）を参照し、イベントＩＤが２であり、かつ監視対象名が／ｂｉｎ／ｓｕの箇所を探し、防御対策ＩＤを得る（０ｘ０００００００１）（Ｓｃ４）。そして、対策実施部８に、第２の形式で、すなわち、「／ｂｉｎ／ｓｕ：ｐｉｄ＝２１００：ｕｉｄ＝３：０ｘ０００００００１」となる形式で通知する（Ｓｃ５）。
【００４５】
そして、対策実施部８では、防御処理情報テーブル（ＤＩＴ）を参照し（Ｓｄ１）、防御対策ＩＤが０ｘ０００００００１となる箇所の、防御対策処理へのアドレスを実行する（Ｓｄ２）。
【００４６】
Ｄ．応用例１
次に、図１２は、上述した実施形態の応用例１を示すブロック図である。該応用例１では、複数の定期実行型ソフトウェア７−１〜７−ｎを制御することを特徴としている。この応用例１は、類似する目的の複数のソフトウェア（例えば、異なる検知方式を持つ複数のウィルス検知ソフトウェア）を用意して、（ａ）イベント監視部４がソフトウェア制御部６にイベントを通知し、（ｂ）定期監視ソフトウェア７−１〜７−ｎを実行することが可能である。あるいは、異なる目的の複数のソフトウェア（例えば、ウィルス検知ソフトウェアとセキュリティポリシ監視ソフトウェアなど）を用意して、イベントの種類に応じて、定期実行型ソフトウェア７−１〜７−ｎのいずれかを実行することで、異なる種類の不正アクセスに同時に対応することが可能となる。さらには、定期実行型ソフトウェア７−１の実行結果が不正アクセスを判定するものであれば、定期実行型ソフトウェア７−２を起動して、さらに詳細検査を行うことで、検知能力を強化することが可能となる。
【００４７】
Ｅ．応用例２
次に、図１３は、上述した実施形態の応用例２を示すブロック図である。該応用例２では、複数の定期実行型ソフトウェア７−１〜７-ｎを制御することに加え、既存の対策実行ソフトウェア９−１〜９−ｎも制御することを特徴としている。この応用例２では、定期実行型ソフトウェア７−１〜７-ｎが、既存の対策実行ソフトウェア９−１〜９−ｎを実行し、不正アクセスなどの攻撃を防止する機能を得ることを可能とする。
【００４８】
なお、対策実行ソフトウェア９−１〜９−ｎとは、前述した要件２で述べた攻撃に対する防御手段、すなわち「検知だけでなく、攻撃に対する防御対策も自動で実施できること。」をプログラムとしたものである。侵入行為検知時に、検知だけでなく侵入行為に対する防御も実施することで、侵入行為に対する被害を縮小させるために使用される。このような防御の例としては、ファイアウォールのフィルタリングルール変更や、攻撃者の強制ログアウト等がある。
【００４９】
対策実行ソフトウェア９−１〜９−ｎは、通常不正アクセスを検知するソフトウェア（以降、ＩＤＳ（Intrusion Detection System）という）からの出力を入力として、自身に必要な情報を抽出して、攻撃に対する防止手段を実施する機能を持つ。また、警告を入力とせずとも、自身に必要な情報さえ入力として与えられればよいこともある。この場合、別途警告から、対策実行プログラムに必要な情報を抽出するプログラムが必要である。
【００５０】
対策実行ソフトウェア９−１〜９−ｎは、ＩＤＳの出力の形式と内容とに依存するため、不正アクセスを検知するソフトウェア毎に、独自に作られている。そのため、あるＩＤＳ用に作られた対策実行ソフトウェアは、他のＩＤＳで用いることができない。従って、ＩＤＳ毎に対策実行ソフトウェアを開発する必要があり、コストがかかる。
【００５１】
特に、ＩＤＳであり、かつ定期実行型ソフトウェア（以降、定期実行型ＩＤＳ）であるものは、侵入行為発生時に検知を行わないため、侵入行為発生時に防御を行う目的で開発される対策実行プログラムには適していない。そのため、定期実行ＩＤＳ向けの対策実行プログラムは少ない。そこで、各定期実行型ＩＤＳ向けの対策実行プログラムを開発することなく、既存の対策実行プログラムを使用したい。そこで、以下の要件が生まれてくる。
要件ａ：任意の定期実行型ＩＤＳが既存の対策実行プログラムを実行できること。
【００５２】
また、定期実行型ＩＤＳは、ホスト内部の侵入検知を目的とすることが多いため、例えばネットワーク経由で攻撃が行われた場合、攻撃元ホストのＩＰアドレス等は、定期実行型ＩＤＳの警告に含まれない。このように、対策実行プログラムが必要としている情報が、定期実行型ＩＤＳの警告にない場合が考えられる。そこで、以下の要件も生まれてくる。
要件ｂ：定期実行型ＩＤＳの警告にない情報が侵入防止機能の入力として必要である場合、自動的に補完ができること。
【００５３】
すなわち、当該応用例２では、定期実行型ＩＤＳを用いてリアルタイムで侵入を検知するだけでなく、既存の対策実行プログラムを利用して、不正アクセスに対して適切な防衛対策を実施することにある。
【００５４】
該応用例２では、ソフトウェア制御部６は、図１４〜図２１に示す設定情報、及びテーブル（ＤＩＴ’）を保持する。以下に、これらの設定情報、及びテーブルについて説明する。各テーブルは、ユーザが事前に設定した内容をソフトウェア制御部６が内部構造として保持する際に用いる。
【００５５】
図１４および図１５（ａ）、（ｂ）に示す共通設定（ＣＣ’−１、ＣＣ’−２）は、該応用例２を実現するための共通の設定である。該応用例２では、複数の定期実行型ＩＤＳを用いるため、図４（ａ）で示す共通設定（ＣＣ）が定期実行型ＩＤＳの数だけ必要となる。そのため、ユーザは、図１４に示すように、共通設定（ＣＣ’−１）を１つと、図１５（ａ）、（ｂ）に示す共通設定（ＣＣ’−２）を定期実行型ＩＤＳの数だけ用意する。
【００５６】
図１４に示す共通設定（ＣＣ’−１）では、イベント監視部４からの通知を受けたときに実行する定期実行型ＩＤＳを指定する。図１５（ａ）、（ｂ）は、ユーザが定期実行型ＩＤＳの警告の差異情報を定義する共通設定（ＣＣ’−２、Alert Format Definition：ＡＦＤ）であり、図１６は、ソフトウェア制御部６が設定内容を内部構造として保持するために用いる警告形式定義テーブル（Alert Format Definition Table：ＡＦＤＴ）である。
【００５７】
定期実行型ＩＤＳの警告に含まれる情報の種別と、情報を抽出するための正規表現とを「”（ダブルクォーテーション）」で囲んだ形式で記述する。情報種別と正規表現とのペアは、最大３つまで「｜（パイプ）」で区切ることで記述できる。このペアを複数記述した場合には、前の正規表現のマッチング結果に対して、さらにマッチングを行うことになる。なお、情報種別には攻撃元／攻撃先ＩＰアドレス、攻撃元／攻撃先ポート番号、攻撃元／攻撃先ＭＡＣアドレス、攻撃者のユーザＩＤ、攻撃が行われた時間等を記述可能である。
【００５８】
次に、図１７〜図２０は、防御設定テーブル（ＤＴ’−１、ＤＴ’−２）について示す概念図である。共通設定と同様に、この例では複数の定期実行型ＩＤＳを用いることから、防御設定についても定期実行型ＩＤＳ毎に異なることが考えられるため、図５（ｂ）に示す防御設定テーブルも複数となる。そのため、ユーザは、図１７に示す防御処理テーブル（ＤＴ’−１）と図２０に示す侵入防止機能に関する定義（ＤＴ’−３、Response Execution Rule：ＲＥＲ）を各々１つ、図１８（ａ）、（ｂ）に示す、イベント監視部４からの通知を受けた場合に実行する侵入防止機能の設定情報（ＤＴ’−２、Response Decision Rule：ＲＤＲ、Exception Rule：ＥＸＲ）を定期実行型ＩＤＳの数だけ用意する。
【００５９】
図１７に示す防御処理テーブル（ＤＴ’−１）では、イベント監視部４からの通知を受けたときに実行する定期実行型ＩＤＳを指定する。図１８（ａ）、（ｂ）に示すＲＤＲ（Response Decision Rules）、ＥＸＲ（Exception Rules）では、定期実行型ＩＤＳ毎に警告を生成したときに実行する侵入防止機能を指定する。
【００６０】
図１９（ａ）、（ｂ）は、ソフトウェア制御部６がこれらの設定を内部構造として保持する際に用いるテーブルを示す概念図である。この設定は２つあり、実行する侵入防止機能を決定するＲＤＴ（Response Decision Table）と、その例外を指定するＥＸＴ（Exception Table）とである。ユーザは、ＲＤＲにおいて、実行する対策実行プログラムを「−＞」の後で指定する。この番号は、図１９のＲｅｓｐｏｎｓｅ  ＩＤであり、対策実行プログラム毎に割振られる数値である。また、ＥＸＲでは、ＲＤＲの例外を「−＞」の後に指定する。例えば［３］とすれば、ＲＤＲの２番目までのルールはスキップされ、マッチングの対象外となる。なお、これら２つのルールでは、「“＊”−＞［１］」のようにアスタリスクが記述可能である。この場合、全ての場合がマッチする意味となり、デフォルトルールとして用いることができる。また、図２０は、侵入防止機能に関する定義情報（ＲＥＲ：Response Execution Rule）を示す概念図である。
【００６１】
次に、図２１は、対策実行プログラム毎の設定である、防御処理情報テーブル（ＤＩＴ’）を示す概念図である。当該応用例２では、既存の対策実行プログラムを使用するため、図５（ｂ）に示すＤＩＴが図２１に示すようになる。防御処理情報テーブルＤＩＴ’には、各侵入防止機能にはＩＤ、実行後停止することが必要か否か、実行するために必要な入力形式を記載する。図２１は、ソフトウェア制御部６が設定内容を内部構造として保持するために用いるテーブルＲＥＴ（Response Execution Table）である。
【００６２】
次に、図２２は、情報補完テーブル（ＳＩＴ：Supplement Information Table）と情報補完機能（ＳＦ：Supplement Functions）とを示す概念図である。図２２に示す構造は、ソフトウェア制御部６が、ＥＸＴ、ＲＤＴにあるルールと定期実行型ＩＤＳの警告のマッチングを行う際に、ＥＸＴ、ＲＤＴで要求される情報種別とが定期実行型ＩＤＳの警告内にない場合に、自動的に補完するための構造である。
【００６３】
図２２に示す情報補完テーブル（ＳＩＴ）は、縦軸に補完する情報種類を示し、横軸は補完のために必要な情報種類を示す。情報補完機能（ＳＦ）とは、補完を行う機能を果たすものであり、ＰＩＤ＿ＳＩＰのように情報補完テーブル（ＳＩＴ）の縦軸と横軸をアンダーバーでつないだ名称のプログラムのセットである。ソフトウェア制御部６は、情報補完テーブル（ＳＩＴ）を参照し、●／×（補完可能／不可能）を逐次閲覧することで、ある情報を補完するために必要な情報は何か把握することができる。また、図１６に示す警告形式定義テーブル（ＡＦＤＴ）を参照すれば警告内にある情報がわかるため、情報補完テーブルＳＩＴと突合せ、警告内の情報を用いて、補完が可能か判定することが可能である。また、「ＳＩＰ＿ＰＩＤ」のように「補完したい情報名＿補完に必要な情報名」の情報補完機能ＳＦを実行することで、補完をすることが可能である。
【００６４】
次に、当該応用例２の動作について、前述した図１４、図１６、図１７、図１９、図２１、図２２と、前述したＣ．実施例で記述した例を元に説明する。イベント監視部４の動作は、前述したＣ．実施例と同様である。そこで、ソフトウェア制御部６が、イベント監視部４からの通知を受けたところ（図７のＳａ３）から説明する。図２３は、当該応用例２の動作を説明するためのフローチャートである。
【００６５】
ソフトウェア制御部６は、イベントＩＤを元に図１７に示す防御処理テーブル（ＤＴ’−１）を参照する。ここではイベントＩＤ＝２であるため、一行目が該当する。一行目では、実行する定期実行型ＩＤＳのＩＤが「２」となっているため、この値を元に図１４に示す共通設定（ＣＣ’−１）を見ると、／ｕｓｒ／ｓｂｉｎ／ｒｋｈｕｎｔｅｒを実行すればよいことがわかる（Ｓｅ１）。
【００６６】
次に、／ｕｓｒ／ｓｂｉｎ／ｒｋｈｕｎｔｅｒを実行し、結果を回収する（Ｓｅ２）。次に、図１６に示す警告形式定義テーブル（ＡＦＤＴ）、図１９（ａ）に示すＲＤＴ、図１９（ｂ）に示すＥＸＴを用いて、回収した結果が不正アクセスであるか判定し（Ｓｅ３）、不正アクセスでない場合には、当該処理を終了する。一方、不正アクセスである場合には、対策実施部８に通知する（Ｓｅ４）。
【００６７】
次に、図２４は、上記ステップＳｅ４における、実行する防御対策プログラムを決定するための動作を説明するためのフローチャートである。防御対策プログラムの決定は、初めにＥＸＴを参照して、その後、参照するＲＤＴの参照開始ポイントを決定し（Ｓｆ１）、次に、ＲＤＴを参照して実行する防御対策プログラム（のＩＤ）を決定する（Ｓｆ２）流れとなる。
【００６８】
次に、図２５は、上記ＥＸＴ、ＲＤＴを参照する際の動作を説明するためのフローチャートである。ソフトウェア制御部６は、ＥＸＴ、ＲＤＴの各ルールを参照する際に、各ルールに記載される情報種別を、逐次ＡＦＤＴを参照することで、ルール内に含まれる情報を警告内から探す（Ｓｇ１）。そして、ルールに記載される情報種別が警告内に存在しない場合には、図２２に示す情報補完テーブル（ＳＩＴ）を参照して情報補完が可能であるか判定する（Ｓｇ２）。ここで、情報補完が不可能であれば、当該処理を終了する。一方、情報補完が不可能であれば、情報を逐次補完する。
【００６９】
一方、ルールに記載される情報種別が警告内に存在する場合、あるいは補完可能であれば、各ルールに記載される条件とマッチングを行う（Ｓｆ３）。そして、マッチするルールがなければ処理を終了する。これに対して、マッチするルールがある場合には、「監視対象名：ｐｉｄ＝攻撃者のプロセスＩＤ：ｕｉｄ＝攻撃者のユーザＩＤ：防御対策ＩＤ：ＣＣ’−１に示す定期実行型ＩＤＳのＩＤ：ＩＤＳの警告」という形式を取る第３の形式で、対策実施部８に通知する。
【００７０】
この例では、まず、図１９（ｂ）に示すＥＸＴの一行目を参照するが、ＳＩＰは、定期実行型ＩＤＳの警告である図１１にも、イベント監視部４からの通知（図７のＳａ３に示した通知）にも含まれていない。そこで、図２２に示す情報補完テーブル（ＳＩＴ）を参照すると、ＳＩＰを補完するためには、ＰＩＤがあればよいことが分かる。そこで、ＳＩＰ＿ＰＩＤのプログラムを実行して、ＳＩＰを得る。図２６は、ＳＩＰ＿ＰＩＤの例である。その後、得られたＳＩＰと、ルールで定義されている１９２．１６８．０．［０−９］｛１，３｝のマッチング処理を行う。マッチングした場合、当該ルールでは、ＲＤＴの参照開始ポイントが４とされている（図１９（ｂ）参照）。この場合、ＲＤＴに４行目はないため、処理を終了する。マッチングしない場合には、ＲＤＴの一行目から参照することになる。ここでは、マッチングしなかったものとして説明を続ける。
【００７１】
次に、ソフトウェア制御部６は、図１９（ａ）に示すＲＤＴの一行目を参照する。ＲＤＴの一行目に記載されているＦＩＬＥＮＡＭＥは、図７のＳａ３にに示す通知に含まれている。より厳密には、図１６に示す警告形式定義テーブル（ＡＦＤＴ）のＦＩＬＥＮＡＭＥの定義とマッチングを行い、／ｂｉｎ／ｓｕを得る。／ｂｉｎ／ｓｕは、ＲＤＴの一行目に記載されているため、ソフトウェア制御部６は、ＲＤＴの一行目と定期実行型ＩＤＳの警告とがマッチングしたものとみなすことができる。そこで、マッチしたルールに記載される防御対策ＩＤ＝１を実行することが決定する。そこで、「／ｂｉｎ／ｓｕ：ｐｉｄ＝１２３：ｕｉｄ＝１２：１：２：図１１に示す警告」という形式を取る第３の形式で、対策実行部に防御対策実施要求を送る。
【００７２】
対策実行部８では、通知を受けると、通知に含まれる防御対策ＩＤを元に防御処理情報テーブル（ＤＩＴ’）を参照する。ここでは、防御対策ＩＤ＝１となるため、ＲＥＣＯＶＥＲ＿ＦＩＬＥを実行することになる。
【００７３】
対策実行部８は、防御対策ＩＤ＝１の欄にあるコマンドの列を参照する。＄が先頭についたものは変数とみなされるため、図１６の警告形式定義テーブル（ＡＦＤＴ）を参照しながら、受け取った通知内から抽出することが可能である。ここでは、ＦＩＬＥＮＡＭＥが該当するため、／ｂｉｎ／ｓｕが＄ＦＩＬＥＮＡＭＥとして適用されることになり、防御対策プログラムを実施することが可能である。
【００７４】
なお、図１３に示すように、該応用例２は、複数の定期実行型ＩＤＳを前提として説明したが、必ずしも定期実行型ＩＤＳばかりでなくともよい。常時監視型ＩＤＳを用いた場合には、図２３に示すステップＳｅ２から処理を開始すればよい。また、その際、ソフトウェア制御部６では、ソケット、パイプやファイルモニタをＩＤＳ毎に警告受信用として割当て、これらの警告受信用のリソースと、ＩＤＳ毎に設定された情報をペアにして使い分けることになる。
【００７５】
Ｆ．応用例３
次に、図２７は、上述した実施形態の応用例３を示すブロック図である。当該応用例３では、複数の定期実行型／常時監視型のＩＤＳと既存の対策実行プログラムとを制御することに加え、新たに、警告に対して実施する防御手段を動的に変更する機能を有することを特徴としている。
【００７６】
警告に対して実施する防御手段を動的に変更するとは、ここでは、以下の４点を想定するが、必ずしも４点に限るものではない。
（１）侵入防止機能切替え  −  ＲＤＲ（Response Decision Rule）で指定した侵入防止機能を切替える。例えば、ＴＣＰの攻撃は、コネクション遮断する設定をしたが、数多く攻撃するＩＰアドレスに対して重いペナルティを課すために、ファイアウォールの設定変更を行い、一日、アクセスを拒否する機能を実行するようにすることである。
【００７７】
（２）侵入防止機能追加  −  ＲＤＲで指定した侵入防止機能を実行する際に、他の侵入防止機能も合わせて実行する。例えば、ローカルユーザが何度もシステムの設定ファイルの改ざんを行う場合、設定ファイルを復旧するのみとしていたが、さらに攻撃者の強制ログアウトも行う場合である。
【００７８】
（３）実行期間延長  −  インタフェースは、ある侵入防止機能を実行する際に、図５のＥＸＰＩＲＥＤ＿ＴＩＭＥで示す時間を経過すると停止も行うが、その時間を延長する。例えば、アカウントをロックアウトする期間を延長する場合に使用する。
【００７９】
（４）時間制約付実行  −ある時刻から、一定時刻が経過するまで、ある侵入防止機能を実行する処理を繰り返し実行する処理である。例えば、午前０時から６時まで、あるＩＰアドレスから来るアクセスを拒否するため、ファイアウォールを閉じる処理を、日毎に繰返すことである。
【００８０】
前述した従来技術（特許文献２）のように、常時監視型のＩＤＳを用いて、侵入検知後に防御手段を実施する技術があった。このような技術を使用する上で、ユーザは、「ある警告に対して、特定の機能をもって防御を行う」設定をシステム起動前に行う。これに対して人手による対策では、ＩＤＳの警告を見ると、保護対象のシステムの状況や、過去に発生した侵入行為等の事項を考慮して対処を行う。保護対象のシステム状況の例としては、「ＩＤＳの警告には、あるＯＳのＷＷＷサーバに対して攻撃Ａが行われたと示されているが、攻撃Ａは、別のＯＳのＷＷＷサーバに対して行われるものであるため、この警告は無視してよい」等が挙げられる。
【００８１】
また、過去に発生した侵入行為に関する例としては、「３．３．３．３／８  のＩＰアドレスは、頻繁に攻撃を仕掛けてくるため、通常は攻撃があったときのみ対処を行うが、このアドレスに対しては、一週間アクセス拒否にする」等である。このように、従来の技術では、人手による対処では考慮されない事項がある。そのため、従来の技術では、効果的な防御が行えていない。そこで、以下の要件が発生する。
要件Ａ：警告に対して実施する防御手段を動的に変更する機能を備えること。
【００８２】
このような技術の例としては、特開２０００−１７０７２７において、保護対象のホストが提供しているサービスを自動検出し、提供サービスに関する攻撃ルールのみをＩＤＳに組み込むことで、ＩＤＳの設定を変更し、ＩＤＳが発生させる警告量を減らすものがある。また、特開２００３−６６０４５では、ファイアウォールが開いているポートに関する攻撃ルールのみをＩＤＳに組み込むことで、ＩＤＳの設定を変更し、ＩＤＳが発生させる警告量を減らすものがある。これらの技術は、ＩＤＳの検知内容を設定するものであり、防御内容を設定するものではない。
【００８３】
また、これらの技術は、特定の設定変更基準に頼っているため、拡張性にかける。設定変更基準とは、分析手法を適用するものから、上述する管理者の知見レベルのものまで多種多様であるため、異なる設定変更基準が生じたときに対応ができない。そこで、以下の要件も生まれる。
要件Ｂ：ユーザ任意の設定変更基準を複数付替え可能とすること。
【００８４】
さらに、これらの技術は、ＩＤＳに読み込ませる攻撃ルールを変更させるものである。それぞれのＩＤＳは、通常独自に開発されるため、ＩＤＳの攻撃ルール形式は、ＩＤＳ毎に異なる。したがって、これらの既存技術は特定のＩＤＳに依存した形式で実現されるものである。
【００８５】
１つのＩＤＳで全ての侵入行為を検出するなら、特定のＩＤＳに依存することは問題ではない。だが、例えば、通信を監視するＩＤＳは、暗号化通信を監視できないように、通常、１つのＩＤＳで全ての侵入行為を監視できない。そのため、複数のＩＤＳを組合わせて侵入を検出することが通常の運用形態である。そのために、任意のＩＤＳを用いて実現可能であることが重要であり、特定のＩＤＳに依存することは問題である。また、人手による対処であれば、あるＩＤＳが検知した侵入行為から得られる知見は、他のＩＤＳにも適用するであろう。そのために、任意のＩＤＳを用いて実現可能であるだけでなく、任意のＩＤＳを組合わせた形式でも実現可能であることが重要であり、既存技術では問題がある。そのため、以下の要件も生じる。
要件Ｃ：実現する動的設定変更機能は、任意のＩＤＳを組合わせて使用する場合でも適用可能であること。
【００８６】
これらの要件を元に動的設定変更機能を実現すると、ユーザが初期に行った設定を書き換えることになる（これまでに述べた方法において該当する設定とは、図１８に示すＲＤＴとＥＸＴである）。これらを書き換えることは、ユーザが行う初期設定の変更となり、後々ユーザに混乱を招くことが想定される。そこで、以下の要件も生じる。
要件Ｄ：ユーザが行う初期設定の記述自体に変更を加えないこと。
【００８７】
当該応用例３は、定期実行型ＩＤＳを用いてリアルタイムで侵入を検知し、既存の対策実行プログラムを利用して、不正アクセスに対して適切な防衛対策を実施できるだけでなく、任意のＩＤＳを組合わせた形式でも動的設定変更を可能とする。
【００８８】
上述した課題を解決するために、当該応用例３は、図２７で示す構成で実現される。応用例２の構成を示す図１３と比較すれば、設定を変更する判断基準となる、複数の変更決定部１０−１、１０−２、…、１０−ｎを有する。変更決定部１０−１、１０−２、…、１０−ｎは、ユーザ任意の処理でよい。また、動的設定変更部１０は、これらの変更判定部１０−１、１０−２、…、１０−ｎを管理する。また、当該応用例３は、動的設定変更機能として、図２８に示す防御履歴振分けテーブル（ＤＨＤＴ：Defense History Distribution Table）と、図２９に示す設定変更遷移図とを有する。
【００８９】
まず、対策実施部８は、ソフトウェア制御部６からの防御対策実施要求を受け、対策を実行する。実行後に、「ＴＩＭＥ：ＳＩＰ：ＤＩＰ：ＵＩＤ：ＰＩＤ：…．」のように、対策実行に使用した情報と、補完可能な全ての情報とを「：（コロン）」で連結した形式を取る第４の形式で、動的設定変更部１０に送る。以降、この第４の形式を防御履歴と呼ぶ。動的設定変更部１０は、図２８に示す防御履歴振分けテーブル（ＤＨＤＴ）を参照し、テーブルに記載される変更決定部のＩＤにしたがって、受け取った防御履歴を変更決定部１０−１〜１０−ｎに振分ける。
【００９０】
防御履歴を受け取った変更決定部１０−１〜１０−ｎは、任意の判定基準に基づき、設定変更の必要性の有無を判断する。変更判定の必要が生じた場合には、例えば「ＵＩＤ＝１２：ＲＥＣＯＶＥＲ＿ＦＩＬＥ」のように、「変更対象名：変更前の防御対策」の形式を取る第５の形式で、動的設定変更部１０に設定変更要求を出す。これは、「ＵＩＤ＝１２に対してＲＥＣＯＶＥＲ＿ＦＩＬＥを行う場合には、設定変更を行う」意味となる。設定変更後の処理の決定は、動的設定変更部１０が行う。
【００９１】
設定変更要求を受け取った動的設定変更部１０は、図２９に示す遷移図に基づき、設定変更する内容を決定する。該当する変更決定部は複数となることが想定されるため、各変更決定部１０−１〜１０−ｎが相反する設定変更を行い、変更内容に矛盾が生じないように、動的設定変更部１０で管理する形式となっている。上述した例ではＵＩＤ＝１２を変更対象としたが、この場合、遷移図を検索し、ＵＩＤ＝１２が既に遷移図に現れていれば、遷移図に沿って設定変更内容を決定する。ＵＩＤ＝１２が遷移図に現れていなければ、変更前の防御対策は、ＲＥＣＯＶＥＲ＿ＦＩＬＥとなっているため、ＲＥＣＯＶＥＲ＿ＦＩＬＥの欄にＵＩＤ＝１２を登場させ、遷移させることで設定変更内容を決定する。
【００９２】
設定変更内容を決定後に、動的設定変更部１０は、「ＵＩＤ＝１２：ＲＥＣＯＶＥＲ＿ＦＩＬＥ：ＲＥＣＯＶＥＲ＿ＦＩＬＥ，  ＬＯＧＯＵＴ＿ＦＯＲＣＥＬＹ」のように「変更対象名：変更前の防御対策：変更後の防御対策」の形式を取る第６の形式で、対策実施部８に対して設定変更要求を行う。設定変更要求を受け取った対策実施部８は、ソフトウェア制御部６から防御対策実施要求を受け取る度に、これらの設定変更要求を見て、実施する防御の変更必要性を判定し、必要がある場合には変更を行った後に、防御を実施する。
【００９３】
なお、図２８に示す防御履歴振分けテーブル（ＤＨＤＴ）と、図２９に示す遷移図は、システム起動前にユーザが設定内容として記述するものである。
【００９４】
次に、当該応用例３の具体的な実施例について説明する。本実施例では、次のような攻撃者を想定する。
（１）あるホストの管理者権限（ｒｏｏｔ）のパスワードがホスト名と同一であり、攻撃者にパスワードを推測され、攻撃者に管理者権限でのログインを許してしまった。
【００９５】
（２）攻撃者は、ＷＷＷサーバの設定ファイル（ｈｔｔｐｄ．ｃｏｎｆ）を書き換え、ＷＷＷサーバが公開するホームページをすり返ることを試みる。しかしながら、ＷＷＷサーバの設定内容変更は、システムの運用ポリシによって指定された時間にしかできないことになっている。したがって、ここで述べる技術によって、指定時間外の内容変更は改ざんとみなされ、自動復旧される。そのため、攻撃者による設定内容変更は失敗する。
【００９６】
（３）何度かＷＷＷサーバの設定ファイル変更を試した攻撃者は、変更が失敗したことに気付くと、後日改めて攻撃を行うことにした。そこで今回は、ｒｏｏｔのパスワードが変更されることを恐れて、バックドアを仕掛けることを試みる。
【００９７】
このような攻撃に対して、「一定時間内に同じユーザによって攻撃が行われた場合には、実施する防御機能を強化する」要求を出す変更決定部１０−ｉ（ｉ：１〜ｎ）を適用し、攻撃を防ぐ例を示す。そのときの変更判定テーブルは図２８であり、遷移図は図２９を用いる。なお、フローを示す上で、ソフトウェア制御部６〜対策実施部８の処理は既に述べたため、省略する。
【００９８】
実際のフローは、以下のようになる。ここで、図３０は、当該応用例３の動作を説明するためのフローチャートである。まず、攻撃者がｈｔｔｐｄ．ｃｏｎｆに対して改ざん行為を行うと、前述した図２３、図２４に示すフローチャートに従い、ｔｒｉｐｗｉｒｅが図３１および図３２に示す警告を発することで検知する。また、対策実施部８が改ざんされたファイルを復旧する。このとき、対策実施部８は、「Ｔｈｕ  Ｍａｙ  １２  ００：３０：１１  ２００５：ｔｒｉｐｗｉｒｅ：ＲＥＣＯＶＥＲ＿ＦＩＬＥ：／ｕｓｒ／ｌｏｃａｌ／ａｐａｃｈｅ／ｃｏｎｆ／ｈｔｔｐｄ．ｃｏｎｆ：０：１１２３４……」の形式を取る防御履歴を、動的設定変更部に対して送る（Ｓｈ１）。なお、「０」はユーザＩＤ、「１１２３４」はＰＩＤを想定している。
【００９９】
動的設定変更部１０では、防御履歴振分けテーブルを参照し、防止履歴を振分ける。上述した防御履歴例では、テーブル内の一行目が該当するため、変更履歴部１に防御履歴を送る（Ｓｈ２）。次に、変更決定部１０−１〜１０−ｎが、設定変更の必要性有無を判定する（Ｓｈ３）。この場合、まだ一度しか攻撃は行われていないため、設定変更を行う必要はないとして、処理を終了する。
【０１００】
一方、攻撃者が一定時間内に何度もｈｔｔｐｄ．ｃｏｎｆの改ざんを行ううちに、防御履歴が変更決定部１０−１〜１０−ｎに蓄積されるため、その際、変更決定部１０−ｉは、設定変更の必要があるとして、動的設定変更部１０に対して、「ＵＩＤ＝０：ＲＥＣＯＶＥＲ＿ＦＩＬＥ」の形式で、設定変更要求を通知する（Ｓｈ４）。
【０１０１】
通知を受け取った動的設定変更部１０では、ＵＩＤ＝０が遷移図に存在するか検索する（Ｓｈ５）。この場合、ＵＩＤ＝０が存在しないので、ＵＩＤ＝０の属性を持つオブジェクトを遷移図に登録する（Ｓｈ６）。その後、遷移図に沿って設定変更を行う。この場合、遷移図では、ＲＥＣＯＶＥＲ＿ＦＩＬＥだけでなく、ＦＯＲＣＥ＿ＬＯＧＯＵＴも実施することになる。そこで、動的設定変更部１０は、「ＵＩＤ＝０：ＲＥＣＯＶＥＲ＿ＦＩＬＥ：ＲＥＣＯＶＥＲ＿ＦＩＬＥ、ＬＯＧＯＵＴ＿ＦＯＲＣＥＬＹ」の形式で対策実施部８に対して通知する（Ｓｈ７）。
【０１０２】
次に、何度も改ざんが失敗している攻撃者は、今回はバックドアのみ設置して、後日再度攻撃を行うことを考える。作成するバックドアは、新規ユーザｍａｌｉｃｉｏｕｓを作成し、／ｅｔｃ／ｐａｓｓｗｄにある「ｍａｌｉｃｉｏｕｓ  ：  ｘ  ：  ＵｓｅｒＩＤ  ：  ＧｒｏｕｐＩＤ…」の記述を「ｍａｌｉｃｉｏｕｓ  ：  ｘ  ：  ０  ：  ０…」とすることで、ｍａｌｉｃｉｏｕｓのユーザＩＤ、グループＩＤを「０」にするものである。すなわち、ユーザ「ｍａｌｉｃｉｏｕｓ」は、ｒｏｏｔの権限を持つことになり、ｒｏｏｔのパスワードが変更されたとしても、ユーザ「ｍａｌｉｃｏｕｓ」がｒｏｏｔの権限を持つため、自由に攻撃ができる。
【０１０３】
この攻撃に対しては、ｔｒｉｐｗｉｒｅのようにファイルの変更のみを監視する定期実行型ＩＤＳでは検知できない。そこで、用途が限定されているが、／ｅｔｃ／ｐａｓｓｗｄの変更内容も加味して攻撃があったことを判定するｒｋｈｕｎｔｅｒが検知する。そして、前述した図２３、図２４に示すフローチャートに従い、検知した結果として出力する警告を図３３および図３４に示す。
【０１０４】
対策実施部８では、／ｅｔｃ／ｐａｓｓｗｄの改ざんがあったため、ファイルを復旧する（ＲＥＣＯＶＥＲ＿ＦＩＬＥ）ことを試みる。しかし、動的設定変更部１０からは、上述の設定変更要求が届いているため、ＲＥＣＯＶＥＲ＿ＦＩＬＥだけでなく、ＬＯＧＯＵＴ＿ＦＯＲＣＥＬＹ（攻撃者の強制ログアウト）も実施されることになる。
【０１０５】
以上、該応用例３の実施例について述べたが、実施内容に関しては上述した事項に限ることではない。想定されるその他の実施内容について、下記に説明する。
（１）該応用例３では、動的設定変更部１０が、防御履歴を受ける度に変更決定部１０−１〜１０−ｎに振分けたが、振分け方法は特にこれに限るものではない。例えば一定数蓄積してから振り分けてもよい。
【０１０６】
（２）実施例では、設定変更対象が単数（ＵＩＤ＝０）であったが、１９２．１６８．２．１／２４等範囲指定してもよい。また、ＵＩＤ＝０  ｏｒ  ＵＩＤ＝１０のように複数まとめて指定してもよい。
【０１０７】
（３）実施例では、変更決定部１０−１〜１０−ｎは、動的設定変更部１０のみと情報の送受信を行っているが、例えば、ソフトウェア制御部６が対策実施部８に送る防御実施要求（第３の形式）を、変更決定部１０−１〜１０−ｎが対策実施部８に直接送ってもよい。これにより、例えば、対策実施部８において、防御対策を実施せずに、防御履歴のみを動的設定変更部１０経由で変更決定部１０−１〜１０−ｎに送り、変更決定部１０−１〜１０−ｎにおいて、攻撃の影響を確認した後で初めて防御を実施する等の防御ができるようになる。
【０１０８】
（４）該応用例３では、動的設定変更部１０の処理として、設定変更対象を遷移図に沿って進めることを述べたが、例えば一定時間経過後に、遷移図に沿って進めた設定変更対象を、遷移図に沿って戻す等のことを行ってもよい。
【０１０９】
上述した実施形態によれば、一定時間経過後にのみ検出された不正アクセスを、リアルタイムに検出させることが可能であり、防御対策を実施可能である。詳細な不正アクセス検知処理は、ＯＳとユーザ以外の第三者アプリケーションが実施するため、複雑な検知手段を適用しても著しい性能劣化とならない。また、既存の定期監視型ソフトウェアを用いることが可能であるため、シグネチャの独自開発が必要ない。その他、任意の定期監視型ソフトウェアに適用することが可能であるため、汎用性がある。また、既存の対策実行機能を再利用することが可能となり、対策実行機能を開発するコストの削減が可能である。さらに、不正アクセス発生時の状況にあわせて、実施する防御が動的に変更可能であり、事前に全て設定する場合と比較して効果的な防御が可能となる。
【０１１０】
上述のイベント監視部４、ソフトウェア制御部６、定期実行型ソフトウェア７、対策実施部８は、プログラムの形式でコンピュータ読み取り可能な記録媒体に記憶されており、このプログラムをコンピュータが読み出して実行することによって、上記処理が行われる。ここでコンピュータ読み取り可能な記録媒体とは、磁気ディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭ、半導体メモリ等をいう。また、このコンピュータプログラムを通信回線によってコンピュータに配信し、この配信を受けたコンピュータが当該プログラムを実行するようにしても良い。
【図面の簡単な説明】
【０１１１】
【図１】本実施形態による不正アクセス対策制御装置を適用したコンピュータシステムの構成を示す概略ブロック図である。
【図２】同実施形態における監視イベント情報テーブル（ＥＩＴ）、監視イベントテーブル（ＥＴ）を示す概念図である。
【図３】同実施形態における例外イベントテーブル（ＥＥＴ）、禁止イベントテーブル（ＰＥＴ）を示す概念図である。
【図４】同実施形態における共通設定（ＣＣ）、監視イベント情報テーブル（ＥＩＴ’）を示す概念図である。
【図５】同実施形態における防御処理情報テーブル（ＤＩＴ）、防御処理テーブル（ＤＴ）を示す概念図である。
【図６】本実施形態による動作を説明するためのデータフローを示すブロック図である。
【図７】イベント監視部４の動作を説明するためのフローチャートである。・
【図８】イベント監視部４の動作を説明するためのフローチャートである。
【図９】ソフトウェア制御部６の動作を説明するためのフローチャートである。
【図１０】防御対策実施部８の動作を説明するためのフローチャートである。
【図１１】定期実行ソフトウェアとして「ｒｏｏｔｋｉｔｈｕｎｔｅｒ」を用いた場合の実行結果の一例を示す図である。
【図１２】上述した実施形態の応用例１を示すブロック図である。
【図１３】上述した実施形態の応用例２を示すブロック図である。
【図１４】共通設定（ＣＣ’−１）を示す概念図である。
【図１５】共通設定（ＣＣ’−２）を示す概念図である。
【図１６】警告形式定義テーブル（ＡＦＤＴ）を示す概念図である。
【図１７】防御処理テーブル（ＤＴ’−１）を示す概念図である。
【図１８】侵入防止機能の設定情報（ＤＴ’−２）を示す概念図である。
【図１９】ＲＤＴ，ＥＸＴを示す概念図である。
【図２０】侵入防止機能に関する定義情報（ＲＥＲ）を示す概念図である。
【図２１】防御処理情報テーブル（ＤＩＴ’）を示す概念図である。
【図２２】情報補完テーブル（ＳＩＴ）と情報補完機能（ＳＦ）とを示す概念図である。
【図２３】応用例２の動作を説明するためのフローチャートである。
【図２４】ステップＳｅ４における、実行する防御対策プログラムを決定するための動作を説明するためのフローチャートである。
【図２５】ＥＸＴ、ＲＤＴを参照する際の動作を説明するためのフローチャートである。
【図２６】自動情報補完機能の一例を示す概念図である。
【図２７】上述した実施形態の応用例３を示すブロック図である。
【図２８】防御履歴振分けテーブル（ＤＨＤＴ）を示す概念図である。
【図２９】設定変更遷移図を示す概念図である。
【図３０】当該応用例３の動作を説明するためのフローチャートである。
【図３１】ｔｒｉｐｗｉｒｅによる警告の一例を示す概念図である。
【図３２】ｔｒｉｐｗｉｒｅによる警告の一例を示す概念図である。
【図３３】ｒｋｈｕｎｔｅｒによる警告の一例を示す概念図である。
【図３４】ｒｋｈｕｎｔｅｒによる警告の一例を示す概念図である。
【符号の説明】
【０１１２】
４  イベント監視部（イベント監視手段）
５  イベント処理部
６  ソフトウェア制御部（ソフトウェア制御手段）
７，７−１〜７−ｎ  定期実行型ソフトウェア（不正アクセス検知手段、複数の不正アクセス検知手段）
８  対策実施部（対策実施手段）
９−１〜９−ｎ  対策実行ソフトウェア（対策実行手段）
１０  動的設定変更部（動的設定変更手段）
１０−１〜１０−ｎ  変更決定部（変更決定手段）
Ｋ  設定ファイル（監視イベント定義テーブル）
【図１】
2006065835.tif 000003
【図２】
2006065835.tif 000004
【図３】
2006065835.tif 000005
【図４】
2006065835.tif 000006
【図５】
2006065835.tif 000007
【図６】
2006065835.tif 000008
【図７】
2006065835.tif 000009
【図８】
2006065835.tif 000010
【図９】
2006065835.tif 000011
【図１０】
2006065835.tif 000012
【図１１】
2006065835.tif 000013
【図１２】
2006065835.tif 000014
【図１３】
2006065835.tif 000015
【図１４】
2006065835.tif 000016
【図１５】
2006065835.tif 000017
【図１６】
2006065835.tif 000018
【図１７】
2006065835.tif 000019
【図１８】
2006065835.tif 000020
【図１９】
2006065835.tif 000021
【図２０】
2006065835.tif 000022
【図２１】
2006065835.tif 000023
【図２２】
2006065835.tif 000024
【図２３】
2006065835.tif 000025
【図２４】
2006065835.tif 000026
【図２５】
2006065835.tif 000027
【図２６】
2006065835.tif 000028
【図２７】
2006065835.tif 000029
【図２８】
2006065835.tif 000030
【図２９】
2006065835.tif 000031
【図３０】
2006065835.tif 000032
【図３１】
2006065835.tif 000033
【図３２】
2006065835.tif 000034
【図３３】
2006065835.tif 000035
【図３４】
2006065835.tif 000036