JP5069057B2 - ログ解析支援装置 - Google Patents

Description

この発明は、情報セキュリティ技術に関連し、特に、ログファイルを解析するための技術、に関する。

企業や公共施設などの運用を支える業務情報システム、いわゆるエンタープライズシステム（Enterprise System）は、今や、大小さまざまな組織の基盤となっている。業務情報システムは、クライアント端末やデータベースから得られるデータを集計、蓄積、解析、加工した上でより付加価値の高い情報を出力することにより、複雑化する組織マネジメントを支えている。業務情報システムが取り扱う情報の中には、ＩＲ（Investor Relations）情報のように組織内外からアクセス可能な公開情報もあれば、顧客情報のように組織内においても厳重に管理すべき機密情報もある。

ところで、２００２年にアメリカで成立したＳＯＸ（Sarbanes-Oxley）法に倣って、日本でも日本版ＳＯＸ法が導入される予定である。業務情報システム運営においても日本版ＳＯＸ法への対応が急務となっている。日本版ＳＯＸ法は、上場企業およびその連結子会社に、会計監査制度の充実と企業の内部統制強化を求めている。日本版ＳＯＸ法の要請に応えるためには、情報漏洩の防止だけでなく、業務情報システムの情報セキュリティを客観的に証明できることも重要である。
特開平１０−３１２３２３号公報 特開２００３−２５６３６５号公報

通常、業務情報システムを構成するさまざまな装置は、自装置に対するアクセス履歴をログファイルに記録する。各装置のログファイルを解析すれば、不正アクセスや障害発生の有無を事後的に検証できる。業務情報システムの情報セキュリティを証明する上でログファイルは有用なツールである。

しかし、多くのサーバやルータを含む業務情報システムからは大量のログファイルが生成される。また、ログファイルの記録形式はベンダによってさまざまである。このような多種多量なログファイルを事後的に解析する作業の負荷は膨大なものとなる。更に、ログファイルから問題発生箇所を特定する判断は属人的スキルに依存しているのが現状である。

本発明は、上記課題に基づいて完成された発明であり、その主たる目的は、業務情報システムにおけるアクセス履歴を効率的に解析するための技術、を提供することにある。

本発明のある態様は、ログ解析支援装置に関する。
この装置は、サーバやゲートウェイ、ルータなどの機器についてのログを取得する。対象となる符号文の出現階層を特定し、出現階層と想定される実現率とを対応づけた実現率テーブルを参照して、各符号文の実現率を特定し、実現率が所定値以上となる符号文を抽出する。

このような態様によれば、ログにおける符号文の出現態様からその符号文により示される操作が実際に実現したものであるかを統一的なポリシにより推定しやすくなる。

なお、以上の構成要素の任意の組合せ、本発明を方法、システム、記録媒体、コンピュータプログラムにより表現したものもまた、本発明の態様として有効である。

本発明によれば、業務情報システムにおけるアクセス履歴を効率的に解析しやすくなる。

図１は、本実施例における業務情報システム２２０のハードウェア構成図である。
ここに示す業務情報システム２２０は、企業や公共施設のような組織の業務管理のために導入されるシステムである。業務情報システム２２０は、地理的に分散された複数の組織を統合するシステムとして構成されてもよい。ここでは、インターネット証券会社の業務情報システムを例として説明する。

業務情報システム２２０はインターネット２０２と接続される。外部端末２００ａや外部端末２００ｂ（以下、単に「外部端末２００」とよぶ）は顧客や従業員などにより利用される端末である。外部端末２００のユーザはインターネット２０２を介して業務情報システム２２０にアクセスできる。内部端末２１２は従業員により利用される端末である。内部端末２１２のユーザはインターネット２０２を経由することなく業務情報システム２２０内の各装置にアクセスできる。インターネット２０２を経由するアクセス、すなわち、外部端末２００からのアクセスは、ファイアウォール２０４によってアクセス可否判定される。ファイアウォール２０４により、外部端末２００から業務情報システム２２０への不正アクセスを防止している。

業務情報システム２２０は、内部端末２１２やファイアウォール２０４のほかに、外部公開サーバ２０６、内部公開サーバ２０８、限定公開サーバ２１０を含む。
外部公開サーバ２０６は、組織内のみならず組織外にも公開可能な情報（以下、「外部公開情報」とよぶ）を保持する。たとえば、投資信託の手数料や運用成績が外部公開情報に該当する。外部端末２００から外部公開サーバ２０６にアクセスする場合、ファイアウォール２０４は原則としてアクセス拒否しない。

限定公開サーバ２１０は、条件付きにて組織外に公開可能な情報（以下、「限定公開情報」とよぶ）を保持する。たとえば、顧客の口座残高が限定公開情報に該当する。パスワードなどによりユーザ認証された顧客のみが、自己の口座情報にアクセスできる。また、所定権限を有する従業員であれば、内部端末２１２から顧客の口座情報にアクセスできる。限定公開情報は慎重に管理されなければならない。本実施例においては、従業員は外部端末２００からは限定公開情報にはアクセスできないものとして説明する。

内部公開サーバ２０８は、組織内からのみアクセス可能な情報（以下、「内部公開情報」とよぶ）を保持する。たとえば、会社の人事情報や顧客リストが内部公開情報に該当する。本実施例においては社内情報と同義である。内部公開情報も慎重な管理が必要である。従業員は、あらかじめ申請しておけば、外部端末２００からでも内部公開サーバ２０８にアクセスできる。顧客から内部公開サーバ２０８へのアクセスは禁止される。ただし、内部公開情報の一部については、従業員であってもアクセスを禁止される。

ファイアウォール２０４や外部公開サーバ２０６、内部公開サーバ２０８、限定公開サーバ２１０あるいは内部端末２１２は、アクセス対象となる情報の種別とユーザの属性、申請の有無に関してあらかじめ定められているるアクセスルールに基づいて、アクセス可否を判定している。

しかし、このようなアクセスルールを設定していても、ルール設定に人為的なミスがあったり、セキュリティーホールなどのシステムの弱点の存在などにより、不正アクセスを完全防止するのは難しい。また、不正アクセスを完全防止したとしても、システムの安全運用を定期的に確認する必要がある。このような理由から、業務情報システム２２０の各装置に対するアクセス履歴を事後的に検証することにより、業務情報システム２２０の情報セキュリティを定期的に診断する必要がある。

外部公開サーバ２０６、内部公開サーバ２０８、限定公開サーバ２１０、ファイアウォール２０４は、自装置に対する、あるいは、自装置を経由するさまざまな制御コマンドに基づくアクセス履歴を「ログファイル」に記録する。たとえば、外部端末２００からＴＥＬＮＥＴプロトコルにて限定公開サーバ２１０に制御コマンドを送信する場合、限定公開サーバ２１０は外部端末２００による制御内容をログファイルに記録する。また、ファイアウォール２０４は、中継した制御コマンドを自らのログファイルに記録する。

内部公開サーバ２０８は、コマンドに対するレスポンスを返信することもある。この場合、内部公開サーバ２０８はその返信内容を自らのログファイルに記録する。ファイアウォール２０４は、レスポンスを中継し、その中継したレスポンスを自らのログファイルに記録する。

ファイアウォール２０４のログファイルと内部公開サーバ２０８のログファイルを突き合わせることにより、どこからどのようなアクセスがどのような経路にてなされたか、また、どのような結果が生じているかを検証できる。

従来、システムの管理者は、各装置のログファイルを参照して、業務情報システム１０のアクセス履歴を解析していた。しかし、さまざまな装置が混在する業務情報システム２２０において、多くのログファイルを解析する作業は容易ではない。たとえば、ファイアウォール２０４によるログファイルのフォーマットと内部公開サーバ２０８によるログファイルのフォーマットは異なるかもしれない。

ＷＩＮＤＯＷＳ（登録商標）によるイベントログの記述方法と、ＵＮＩＸ（登録商標）によるイベントログの記述方法は異なる。また、ＵＮＩＸ（登録商標）においてディレクトリ変更を指示するためのコマンドは、「cd」と「chdir」の２種類がある。このように同じ意味でありながら複数の表記が可能な場合がある。ログ解析に際して、管理者は「cd」と「chdir」が同じ意味「ディレクトリ変更」であることを知っていなければならない。管理者はさまざまな機器のログファイルの記録形式を理解しなければ正確にシステムを診断することはできない。業務情報システム２２０の装置構成は多種多様であるため、ログ解析にともなう作業負担は膨大なものとなりかねない。

更に問題となるのは、ログファイルには制御コマンドだけが記録されるとは限らないことである。ログファイルには、ターゲットマシンに対するコマンドだけでなく、コマンドに対するターゲットマシンからのレスポンスも記録される。あるいは、ターゲットマシンの制御に直接関わらないテキストデータが記録されることもある。たとえば、ログファイルに「cd」という文字列が含まれていたとしても、この「cd」がディレクトリ変更を示すコマンドなのか、それともファイル名や、あるいは、ファイルに含まれる単なるテキスト情報を示すのかはログファイルの文脈から判断しなくてはならない。ログファイル解析時においては、コマンドを示す符号文、レスポンスを示す符号文、あるいは、それ以外の単なるテキスト情報を区別しなければならない。

本実施例においては、ログ解析支援装置１００を導入することにより、ログ解析にともなう管理者の作業負担軽減を図っている。

ログファイルを解析して不正アクセスや障害の発生している箇所、あるいは、発生している可能性が高い箇所（以下、「危険箇所」とよぶ）を特定する作業は属人的スキルに依存する部分が多い。その一方、危険箇所の特徴をある程度の類型化することは可能である。たとえば、ログイン名やパスワードを変更しながら執拗にログインを試みたりサーバのウェルノウンポート番号を探している場合、不正アクセスの可能性がある。このような危険箇所の特徴をあらかじめ類型化しておけば、ログ解析作業の一部を自動化できると考えられる。ログ解析支援装置１００は、このような考え方に基づき、ログファイルから危険箇所を自動的に抽出する機能を備える。
なお、本実施例に示すように、ログ解析支援装置１００は専用ハードウェアとして提供されてもよいが、汎用コンピュータにより実行されるソフトウェアとして提供されてもよい。

図２は、本実施例におけるログ解析の処理過程を示す模式図である。
ログ解析処理過程は、収集フェーズと診断フェーズに大別される。以下、順番に説明する。

１．収集フェーズ
各装置からログを収集し蓄積するフェーズである。承認データ２１４は、内部公開情報や限定公開情報に対するアクセス申請であって、所定の承認権限者による承認済みの内容を示すデータである。内部公開情報の一部については、従業員であってもアクセスを禁止されるが、他の一部については、従業員はあらかじめアクセス申請をすれば、内部端末２１２からアクセスできる。このアクセス申請においては、アクセス予定時間、アクセス対象となるファイルやディレクトリ名などが指定される。承認されると、承認データ２１４として承認データベース２１８に蓄積される。

ソースログ２１６は、ファイアウォール２０４や内部公開サーバ２０８といったさまざまな装置において記録されるログファイルであり、装置によってその記録形式はさまざまである。ソースログにおいて、ターゲットマシンに対するコマンドやターゲットマシンからのレスポンスを示す文のことを「原符号文」とよぶ。原符号文は、後述する抽象化処理を施され、「抽象符号文」に変換される。抽象化処理については図４（ａ）、図４（ｂ）、図４（ｃ）等に関連して後に詳述する。原符号文は、装置によって記載形式はさまざまであるが、抽象符号文は標準的な記録形式に基づく符号文であるため機種に依存する必要がない。抽象符号文によれば、アクセス履歴を標準的な記載形式に統一できる。原符号文の集合であるソースログは、抽象符号文の集合である抽象ログに変換され、ログデータベース２３０に蓄積される。

承認データベース２１８やログデータベース２３０には、たとえば、３年分程度の承認データ２１４や抽象ログが保持される。不正アクセスや障害が発生したとき、あるいは、定期診断時において、承認データ群と抽象ログ群は診断フェーズに供される。

２．診断フェーズ
診断フェーズにおいては、検査対象期間、たとえば、１日分の承認データ２１４と抽象ログが承認スナップ２３２、ログスナップ２３４として取得される。診断処理においては、承認データと抽象ログの突き合わせが行われる。先ほどの例の場合、アクセス予定時間として申請された時間内に限って内部公開情報へのアクセスがなされているか、のように、承認データ２１４に示される承認内容と、抽象ログに示される実際のアクセス内容の整合性が検証される。診断の結果は診断結果データベース２３６に格納される。抽象ログの内容と診断結果は表示処理により画面表示される。管理者は、この画面を参照して、ログの解析を行う。

一方、ログスナップ２３４の抽象ログは、実現判定処理、危険判定処理、再抽象化処理に供される。これらの処理の結果は表示処理により画面表示されてもよい。

Ａ．実現判定処理
抽象符号文に示されるコマンドがターゲットマシンにおいて実現されている可能性を判定するための処理である。たとえば、抽象符号文に先述した「cd」という文字列が含まれている場合、この「cd」はディレクトリ変更を示すコマンドであるかもしれないし、単なるテキスト情報であるかもしれない。前者であれば有効に実現されている可能性が高いが、後者であれば「ディレクトリ変更」のような操作は実行されない。また、前者の場合であっても、外部端末２００からファイアウォール２０４を経由して、内部公開サーバ２０８のディレクトリ変更を指示する場合、ファイアウォール２０４によりコマンド転送が拒否され、内部公開サーバ２０８のディレクトリ変更は実行されていないかもしれない。したがって、ファイアウォール２０４のログファイルから「cd」コマンドが検出されても、実際にターゲットとなる内部公開サーバ２０８には実現されていないかもしれない。実現判定処理については、図５や図６等に関連して後述する。

Ｂ．危険判定処理
抽象ログから危険箇所を抽出するための処理である。たとえば、ログイン名を変更しながら何度もログインに失敗している場合、不正が試みられている可能性がある。いいかえれば、このような箇所は危険箇所である可能性が高い。危険判定処理については、図８や図９等に関連して後に詳述する。

Ｃ．再抽象化処理
抽象ログは、さまざまな記録形式の原符号文を抽象符号文に変換することにより生成される。このため、管理者は、さまざまな原符号文の文法を理解しなくても、抽象符号文の文法さえ理解していればアクセス履歴を解析可能である。たとえば、「cd」や「chdir」という原符号文を「ディレクトリ変更」という抽象符号文に割り当てておけば、「cd」や「chdir」というコマンド名を知らなくても抽象ログからアクセス履歴を読み取ることができる。再抽象化処理は、この抽象符号文を更にユーザ定義の変換規則にて、「ユーザ符号文」に変換するための処理である。再抽象化処理については、図４（ａ）、図４（ｂ）、図４（ｃ）において抽象化処理とあわせて説明する。

本実施例におけるログ解析支援装置１００は、上述した抽象化処理、実現判定処理、危険判定処理、再抽象化処理を実行することにより、ログ解析を支援するための装置である。なお、図２に示した承認データベース２１８やログデータベース２３０、承認スナップ２３２、ログスナップ２３４、診断結果データベース２３６は業務情報システム２２０に含まれる所定のデータベースにより実現されればよい。また、診断処理や表示処理はログ解析支援装置１００の機能として実現されてもよいし、他の装置の機能として実現されてもよい。

図３は、ログ解析支援装置１００の機能ブロック図である。
ここに示す各ブロックは、ハードウェア的には、コンピュータのＣＰＵをはじめとする素子や機械装置で実現でき、ソフトウェア的にはコンピュータプログラム等によって実現されるが、ここでは、それらの連携によって実現される機能ブロックを描いている。したがって、これらの機能ブロックはハードウェア、ソフトウェアの組合せによっていろいろなかたちで実現できることは、当業者には理解されるところである。
ここでは、各部の機能を中心として説明し、それらの連携、データ構造、作用については、図４以降に関連して詳述する。

ログ解析支援装置１００は、データ通信部１１０、ユーザインタフェース処理部１２０、データ処理部１３０およびデータ保持部１７０を含む。
データ通信部１１０は、ログの送受を行う。ユーザインタフェース処理部１２０は、ユーザインタフェース全般を担当する。データ処理部１３０は、データ通信部１１０やユーザインタフェース処理部１２０から取得されたデータを元にして各種のデータ処理を実行する。データ処理部１３０は、データ通信部１１０、ユーザインタフェース処理部１２０とデータ保持部１７０の間のインタフェースの役割も果たす。
データ保持部１７０は、各種データを保持するための記憶領域である。

データ通信部１１０：
データ通信部１１０は、ログ受信部１１２とログ送信部１１４を含む。ログ受信部１１２は、各種装置からソースログを受信する。ログ送信部１１４は、ログ解析支援装置１００により生成される抽象ログを外部のログデータベース２３０に送出する。あるいは、抽象ログの抽象符号文をユーザ符号文に変換することにより得られる「ユーザ定義ログ」をログスナップ２３４等に送出する。

ユーザインタフェース処理部１２０：
ユーザインタフェース処理部１２０は、入力部１２２と表示部１２４を含む。入力部１２２は管理者からの操作入力を受け付け、表示部１２４は各種情報を画面表示させる。

データ保持部１７０：
データ保持部１７０は、標準抽象規則保持部１７２、ユーザ抽象規則保持部１７４、別名保持部１７６、捨象規則保持部１７８、ログ保持部１８０、実現率テーブル保持部１８２および危険度テーブル保持部１８４を含む。標準抽象規則保持部１７２は、原符号文と抽象符号文を対応づける「標準抽象テーブル」を保持する。標準抽象テーブルにより、原符号文は抽象符号文に変換される。ユーザ抽象規則保持部１７４は、抽象符号文とユーザ符号文を対応づける「ユーザ抽象テーブル」を保持する。ユーザ抽象テーブルにより、抽象符号文はユーザ符号文に変換される。別名保持部１７６は、ソースログにおいて操作対象となるデータの別名を保持する。抽象ログの生成に際しては、ソースログのデータの一部は別名に変換される。詳細は後述する。

捨象規則保持部１７８は、抽象符号文への変換対象外となる原符号文の条件を示す「捨象規則」を保持する。捨象規則に合致する原符号文は抽象符号文に変換されない。ログ保持部１８０は、ソースログや、抽象ログ、ユーザ定義ログを一時的に保持する。実現率テーブル保持部１８２は、ログに含まれる各符号文が実際に有効に機能した可能性を判定するための「実現率テーブル」を保持する。危険度テーブル保持部１８４は、ログに含まれる各符号文の出現態様から、危険箇所を特定するための「危険度テーブル」を保持する。

データ処理部１３０：
データ処理部１３０は、抽象化部１３２、実現判定部１４０および危険判定部１６０を含む。抽象化部１３２は、符号文の抽象化を実行する。抽象化部１３２は、標準抽象化部１３４とユーザ抽象化部１３６を含む。標準抽象化部１３４は、標準抽象テーブルを参照して、原符号文を抽象符号文に変換することにより、抽象ログを生成する。すなわち、標準抽象化部１３４は、図２の抽象化処理を実行する。先に例示した「cd」や「chdir」であれば抽象符号文「ディレクトリ変更」に変換される。また、ターゲットマシンへのアクセス成功を示す原符号文は「ログオン」、「ログイン」あるいは「アクセス許可」のようにさまざまな記録形式にてソースログに記録されるかもしれない。標準抽象テーブルにおいては、これら３つの原符号文に対して「ログイン成功」という１つの抽象符号文が対応づけられている。標準抽象化部１３４は、ソースログから「ログオン」、「ログイン」あるいは「アクセス許可」のいずれの原符号文が検出されても、抽象ログには「ログイン成功」という抽象符号文として記録する。このほかにも、抽象化処理には、別名による言い換え、捨象規則による原符号文の捨象などがあるが、これらについては後述する。

ユーザ抽象化部１３６は、ユーザ抽象テーブルを参照して、抽象符号文をユーザ符号文に変換することにより、ユーザ定義ログを作成する。すなわち、ユーザ抽象化部１３６は、図２の再抽象化処理を実行する。管理者は、入力部１２２を介してユーザ抽象テーブルを任意に設定できる。たとえば、「ログイン成功」という抽象符号文に対して「システム使用開始」といった任意のユーザ符号文を対応づけてもよい。さまざまな記録形式の原符号文を、標準的な抽象符号文に変換するだけでなく、更に、管理者の理解しやすいユーザ符号文に変換してユーザ定義ログを生成できる。再抽象化処理により、管理者に対応してログファイルの可読性を高めることができる。たとえば、英語表記の抽象符号文であれば、日本語や中国語などの多言語のユーザ符号文を対応づけてもよい。ユーザ抽象テーブルにおいてこのような対応付けを行うことにより、抽象ログを簡単にローカライズできる。
なお、本実施例においては、抽象符号文からユーザ符号文を生成するとして説明するが、変形例として、原符号文から直接ユーザ符号文を生成してもよい。この場合には、ユーザ抽象テーブルにおいては、原符号文とユーザ符号文が対応づけられることになる。

実現判定部１４０は、抽象符号文により示されるコマンドがターゲットマシンに有効に機能している可能性を「実現率」として判定する。実現率の判定は、実現率判定テーブルに基づいて実行される。すなわち、実現判定部１４０は、図２の実現判定処理を実行する。実現判定部１４０は、出現階層特定部１４２、実現箇所判定部１４４、ログ要約部１４６、実現率調整部１４８および実現テーブル生成部１５０を含む。

出現階層特定部１４２は、各符号文の出現階層を特定する。「出現階層」とは、ログファイルにおいて、判定対象となる符号文が基準となる符号文からどのくらい後に実行されているかを示す概念である。詳細は図５以降に関連して詳述する。実現率テーブルにおいては、符号文の出現階層とその実現率が対応づけられている。実現箇所判定部１４４は、実現率テーブルを参照し、符号文の出現階層から実現率を特定する。実現箇所判定部１４４は、実現率が所定の閾値以上となる符号文を「実現符号文」、所定の閾値未満となる符号文を「非実現符号文」として抽出する。ログ要約部１４６は、抽象ログから実現符号文だけを抽出することにより、抽象ログの中でも実際に実現した可能性が高い抽象符号文のみを含む要約としての抽象ログを生成する。実現率調整部１４８は、レスポンスを示す抽象符号文を検出したときに、対応コマンド符号文の実現率を調整する。実現テーブル生成部１５０は、管理者からの入力にしたがって実現率テーブルを生成する。

危険判定部１６０は、抽象符号文の出現態様から危険箇所を特定する。危険箇所の特定は、危険度テーブルに基づいて実行される。危険度テーブルにおいては、抽象符号文の出現態様と危険度が対応づけられている。すなわち、図２の危険判定処理は、危険判定部１６０により実行される。

危険判定部１６０は、危険度特定部１６２、危険箇所抽出部１６４および危険度テーブル生成部１６６を含む。危険度特定部１６２は、危険度テーブルに基づいて、抽象符号文の危険度を特定する。危険箇所抽出部１６４は、特定された危険度が所定の閾値以上となる箇所を危険箇所として特定する。危険度テーブル生成部１６６は、管理者からの入力にしたがって危険度テーブルを生成する。

図４（ａ）、図４（ｂ）、図４（ｃ）は、符号文の抽象化を説明するための模式図である。ここでは、原符号文を抽象符号文に変換する場合を例として説明するが、基本的な考え方は抽象符号文からユーザ符号文への変換についても同様である。本実施例における抽象化は、「変更」、「詳細化」、「捨象」の３つに大別される。

「変更」とは、原符号文を別の表現に置き換えることにより抽象符号文を生成することである。たとえば、「cd」や「chdir」といった原符号文を「ディレクトリ変更」といった抽象符号文に言い換えるパターンが当てはまる。原符号文と抽象符号文は、基本的に１対１、あるいは、ｍ対ｎ対応となる（ｍ≧ｎ）。

「詳細化」とは、原符号文の示す内容を複数の抽象符号文に変換することである。たとえば、ｎ個の原符号文にて示されるアクセスの内容をそれよりも多いｍ個の抽象符号文により示す場合が該当する。たとえば、「find "穴田" kokyaku.txt」という１つの原符号文は、「kokyaku.txt」というテキストファイルから、「穴田」という単語をサーチするためのコマンドを示す。この場合、「find "穴田" kokyaku.txt」という原符号文は、「テキスト検索」、「kokyaku.txtを選択」、「検索対象は"穴田"」という３つの抽象符号文を変換される。このような変換によれば、ソースログよりも抽象ログの方が処理内容を理解しやすくなる。実際に実行されるコマンドはシンプルでありながら、抽象ログにおける処理内容の可読性を高めることができる。

「捨象」とは、原符号文のうちの一部を変換対象から除外することをいう。たとえば、「find」という検索コマンドを示す原符号文の次の原符号文として「not found」のように検索失敗を示すレスポンスが記述されているときには、この検索コマンドはアクセス履歴において重要な意味を持たない。このような原符号文を変換対象から除外することにより、管理者は、抽象ログにおいて処理の流れを読み取りやすくなる。あるいは、「ファイルの中身を見るためのコマンド」や「ファイルを検索するためのコマンド」のように、システムのデータに直接影響しないコマンドを変換対象外としてもよい。捨象規則においては、このように変換対象から除外すべき原符号文の条件が設定される。

図４（ａ）は、符号文の抽象化のうち変更の一例を説明するための模式図である。
左のログは、ログイン時においてあるＯＳにより記録されたソースログを示す。このソースログの場合、「５２８」等のイベントＩＤにて識別される３つの原符号文によりログインが示されている。標準抽象テーブルにおいては、これら３つの原符号文に対してイベントＩＤ「１００」、説明文「ログイン成功」という抽象符号文が対応づけられている。このため、標準抽象化部１３４は、ソースログの３つの原符号文を「ログイン成功」という１つの抽象符号文に変換して抽象ログに記録する。３つの原符号文が１つの抽象符号文に変換されるため、ソースログよりも抽象ログの方がシンプルで読みやすくなっている。

図４（ｂ）は、符号文の抽象化のうちの変更の別例を説明するための模式図である。
左のログは、ログイン時において図４（ａ）にかかるＯＳとは別のＯＳにより記録されたソースログを示す。このソースログの場合、「９：１」等のイベントＩＤにて識別される２つの原符号文によりログインが示されている。標準抽象テーブルにおいては、これら２つの原符号文に対しても先述した抽象符号文「ログイン成功」が対応づけられている。標準抽象化部１３４は、ソースログの２つの原符号文を「ログイン成功」という１つの抽象符号文に変換して抽象ログに記録する。

図４（ａ）のソースログに示されるアクセス内容と図４（ｂ）のソースログに示されるアクセス内容は表現は異なっていても意味は全く同じである。このため、生成される抽象ログは、同一表現となっている。抽象符号文への変換により、ソフトウェアやハードウェア、プロトコルの違いに依存しないロジカルな抽象ログを生成できる。

図４（ｃ）は、符号文の抽象化のうち詳細化を説明するための模式図である。
左のログは、ＳＱＬ（Structured Query Language）文として「A-TABLE」というテーブルデータを選択するときに記録されるソースログを示す。標準抽象テーブルにおいては、この原符号文「SELECT X」に「データ管理者権限の使用」、「Xの参照」という２つの抽象符号文が対応づけられている。ここでは「Ｘ」に相当する部分が「A-TABLE」なので「Xの参照」という抽象符号文は「A-TABLEの参照」となっている。
図４（ｃ）に示す抽象化の場合、「SELECT X」という１つの原符号文によって示されるコマンドが２つの抽象符号文によって詳細化されている。このため、ソースログよりも抽象ログの方が、ターゲットマシンに対して実行されたアクセスの内容をより詳細に理解しやすくなっている。

更に、抽象ログにおいては、「SELECT」文による操作対象となるデータ「A-TABLE」を「A-TABLE（個人情報）」に表記変換している。別名保持部１７６は、「A-TABLE」の別名として「テーブルＡ（個人情報）」を対応づけて保持している。別名は、管理者により適宜設定されてもよい。このような別名への変換により、「個人情報データにかかわるＡというテーブルを参照している」というアクセス内容がいっそう理解しやすくなる。データの内容を説明するための別名を用意しておくことにより、抽象ログの可読性をいっそう高めることができる。

別例として、ユーザＩＤ「ade」に該当する正式なユーザ名が「穴寺」であるとする。原符号文において「ade login」のように「ade」がログインした旨が示されているときには、抽象符号文においては「穴寺：ログイン成功」のようにデータ「ade」を「穴寺」という別名に変換してもよい。このような別名変換によれば、誰がログインしたのかを抽象ログから読み取りやすくなる。

図４（ａ）、図４（ｂ）、図４（ｃ）については、標準抽象化部１３４による抽象化処理を対象として説明したが、基本的な考え方はユーザ抽象化部１３６による再抽象化処理についても同様である。ユーザ抽象化部１３６は、ユーザ抽象テーブルを参照して、抽象符号文を、変更、詳細化、捨象することにより、管理者にとって読み取りやすい形式のユーザ定義ログを生成する。

抽象化の発展例として、ユーザＩＤの統一およびファイル名の統一という観点から２例説明する。
オフィスの入退室管理装置（図示せず）からもソースログを取得可能であるとする。社員は、オフィス入退室時において、社員番号の記録されたＩＣカードを入退室管理装置のセンサにかざす。このとき、入退室管理装置は社員番号と入退室時刻を対応づけたソースログを生成する。ここでユーザ（社員）を特定する情報は「社員番号」となる。
また、このユーザは、オフィスにある所定のサーバにログインするとき、このサーバ用にユーザがあらかじめ登録しているログインＩＤを使用する。したがって、このサーバがユーザを特定する情報は「ログインＩＤ」となる。本来同一ユーザの行動でありながら、装置によって別々のＩＤによってユーザ行動が管理されることになる。
ログ解析支援装置１００は、ユーザを一意に特定するための「統一ユーザＩＤ」に対して、ログインＩＤや社員番号を対応づけて保持するユーザ管理部（図示せず）を備える。そして、ログ解析支援装置１００の名前変換部（図示せず）は、入退室管理装置やサーバから得られるソースログ中の社員番号やログインＩＤを統一ユーザＩＤに変換する。このような態様によれば、入退室管理装置とサーバという本来別々の装置から得られるソースログを突き合わせて、ユーザごとの行動を把握しやすくなる。

また、業務システムＡと業務システムＢにおいて、あるファイルＣを共用するとする。このとき、業務システムＡでは、ファイルＣを独自の命名規則にてファイル名「Ａ’」に設定して処理する。一方、業務システムＢでは、ファイルＣを独自の命名規則にてファイル名「Ｂ’」に設定して処理する。ファイル名「Ａ’」とファイル名「Ｂ’」は、共に、ファイルＣの別名として業務システムＡや業務システムＢのファイル名命名規則に基づいて設定されることになる。本来同一ファイルでありながら、装置によって別々のファイル名によって管理されることになる。
ログ解析支援装置１００は、ファイルを一意に特定するための統一ファイル名「Ｃ」に対して、業務システムＡにおけるファイル名「Ａ’」、業務システムＢにおけるファイル名「Ｂ’」とを対応づけて保持するファイル管理部（図示せず）を備える。そして、ログ解析支援装置１００の名前変換部（図示せず）は、業務システムＡや業務システムＢから得られるソースログ中のファイル名「Ａ’」やファイル名「Ｂ’」を本来の統一ファイル名「Ｃ’」に変換する。このような態様によれば、本来は同じファイルでありながら、システムの命名規則が異なる故に、別々の名前にて取り扱われる場合であっても、各システムから得られるソースログを突き合わせて、ファイル操作の流れを把握しやすくなる。

図５は、出現階層と実現率の関係を説明するための模式図である。
ここではＳＱＬに似た記法による抽象ログを例として説明する。通常、抽象ログにはさまざまなテキスト情報が含まれる。これらのテキスト情報は、ターゲットマシンに対するコマンドやターゲットマシンからのレスポンスといった操作に関わる内容を示しているかもしれない。あるいは、単なる変数名やコメントを示しているだけかもしれない。出現階層特定部１４２は、抽象符号文の出現階層を特定し、実現箇所判定部１４４は実現率テーブルを参照して、出現階層から実現率を特定する。実現率テーブルは、抽象符号文の出現階層と実現率を対応づけるテーブルである。実現率テーブルの詳細は次の図６に関連して説明する。

１行目「START」は、基準となる符号文であって、この符号文の出現階層は第０階層であり、次の符号文の出現階層は第１階層となる。したがって、２行目の「CREATE A-TABLE」の出現階層は第１階層となる。実現率テーブルにおいては、第１階層に「CREATE」文が出現するときには、次の符号文は第２階層である旨が定義されている。したがって、３行目の「ORA-00 NOT AUTHORISED」の出現階層は第２階層となる。３行目は、２行目の「CREATE A-TABLE」コマンドが失敗した旨を示すレスポンス符号文である。次の符号文の出現階層は、失敗コマンド「CREATE A-TABLE」の出現階層に戻る。したがって、４行目の符号文の出現階層は第１階層となる。

５行目は、再び基準となる符号文「START」であるため、第０階層となる。以下、同様にして、６行目は第１階層、７行目は第２階層となる。７行目の「B-TABLE SUCCESS」は、６行目の「CREATE B-TABLE」コマンドが成功した旨を示すレスポンス符号文である。次の符号文の出現階層は、成功コマンド「CREATE B-TABLE」の出現階層に戻る。したがって、８行目の符号文の出現階層は第１階層となる。出現階層特定部１４２は、後述の実現率テーブルに設定されているルールにしたがって、抽象符号文それぞれの「出現階層」を特定する。一般的には、処理が進むほど出現階層は深くなる。出現階層は、基準となる符号文から対象となる符号文までの間に実行された符号文の数に応じて変化する。ここでいう基準となる符号文は、「START」のような所定符号文であってもよいし、対象となる符号文の直前の符号文であってもよい。

実現率テーブルにおいては、符号文の出現階層と実現率が対応づけられている。たとえば、「CREATE」文の出現階層が第１階層であるとき実現率３０％として設定されている。実現箇所判定部１４４は、２行目の抽象符号文を検出すると、第１階層なので実現率３０％と特定する。

３行目には、この「CREATE」文の失敗を示すレスポンスが現れている。「CREATE」文の失敗が確定的に示されたため、実現率調整部１４８は、３行目の「CREATE」文の実現率を０％に変更する。抽象ログを２行目まで検証した段階では、「CREATE」文の出現態様によりその実現率が３０％と推定されるが、３行目まで検証したときに、この「CREATE」文が実現していないことが確定することになる。

６行目には、第１階層にて「CREATE」文が出現しているため、２行目のときと同じく実現率は３０％と推定される。７行目にはこの「CREATE」文の成功が示されている。この場合、実現率調整部１４８は、実現率を１００％に変更する。

コマンドに対するレスポンスがログファイルに残っていれば、コマンドの成否を判定できる。しかし、ネットワークの一時的な切断によりレスポンスが返ってこないこともあれば、処理速度の関係からレスポンス不要に設定される場合もある。このような場合、ログファイルに含まれる文字列がコマンドを示すのか、また、コマンドであってもターゲットマシンに対して有効に機能しているかを判定するには、ログファイル全体の文脈から判断しなければならない。

実現箇所判定部１４４は、符号文の出現階層と実現率の関係を示す実現率テーブルを参照して、各符号文が実現された可能性を判定する。これは、コマンドごとに出現しやすい出現階層が異なるという経験則に基づく。たとえば、「CREATE」文は比較的深い出現階層で実行されるのが通常であるとする。この場合、実現率テーブルにおいては、「CREATE」の出現階層が深いときには浅いときに比べて高い実現率を設定すればよい。一方、浅い出現階層にて文字列「CREATE」が現れたときには、コマンドではなく単なるテキスト情報である可能性が高い。このときには、実現率が低く設定される。実現率は、コマンド的な記載内容の符号文が現実に実行されたコマンドであるか単なるテキストであるかをその出現階層から判断するための判定基準として、管理者の経験則に基づいて設定されればよい。

ログ要約部１４６は、抽象ログから、実現率が所定閾値、たとえば、６０％以上となる実現符号文のみを含む新たな抽象ログを生成してもよい。

なお、本実施例における実現判定処理は抽象ログを対象として実行されるが、変形例として、ソースログやユーザ定義ログを対象として実現判定処理を実行してもよい。

図６は、実現率テーブルのデータ構造図である。
抽出符号欄１９０は、抽象ログから抽出対象となる文字列を示す。第１実現判定欄１９２や第２実現判定欄１９４は、抽出符号欄１９０に示される文字列の出現階層、次の符号文の出現階層、実現率の関係を示す。第１実現判定欄１９２によれば、「CREATE」というテキストが第０階層に出現したときには、次の符号文の出現階層は第０階層に設定され、「CREATE」の実現率は５％として特定されることになる。第２実現判定欄１９４によれば、「CREATE」というテキストが第１階層に出現したときには、次の符号文の出現階層は第２階層に設定され、実現率は３０％として特定されることになる。

「SUCCESS」の場合、第１実現判定欄１９２によれば、第１階層で出現した場合、次の符号文の出現階層も第１階層であり、「SUCCESS」の前に実行されたコマンド符号文の実現率は５％として特定されることになる。第２実現判定欄１９４によれば、第２階層で出現した場合、次の符号文の出現階層は第１階層であり、「SUCCESS」の前に実行されたコマンド符号文の実現率は１００％として特定されることになる。「NOT AUTH」の場合、第１実現判定欄１９２によれば、第１階層で出現した場合、次の符号文の出現階層も第１階層であり、対応コマンド符号文の実現率は０％として特定される。第２実現判定欄１９４によれば、第２階層で出現した場合、次の符号文の出現階層は第１階層であり、「NOT AUTH」の前に実行されたコマンド符号文の実現率は０％として特定されることになる。すなわち、「NOT AUTH」は、コマンド失敗を示すレスポンス符号文に関わる。

実現率テーブルにおいてどのようなルールを設定するかは管理者の自由である。どのようなテキストがどのような出現階層に出現したとき、想定されるべき実現率をどのように特定し、次の符号文の出現階層をどのように特定するかは管理者のログ解析経験に基づいてルール化されればよい。このような態様によれば、ログ解析経験豊かな管理者が実現率テーブルを設定することにより、経験の浅いシステム管理者であっても注視すべき箇所、すなわち、実現している可能性が高い箇所とそうでない箇所を見極めやすくなる。

図７は、実現率テーブル設計画面２５０の画面図である。
管理者は、図６に示した抽出符号欄１９０や第１実現判定欄１９２に直接テキストや数値を記入することにより、実現率テーブルを設計してもよい。あるいは、所定の抽象ログを対象として出現階層や実現率を設定することにより、実現率テーブルを自動生成できる。実現率テーブル設計画面２５０は、テスト用の抽象ログをベースとして、実現率テーブルを生成するための入力画面である。

実現率テーブルの編集に際して、表示部１２４は、実現率テーブル設計画面２５０を表示させる。ログ保持部１８０に保持される抽象ログのうち、テスト用ログとして管理者に指定された抽象ログがログ表示領域２５２に表示される。管理者は、出現階層領域２５４に各符号文ごとの出現階層制御ルールを入力する。

同図では、１行目の「START」に対しては「＋１」が入力されている。基準となる「START」の出現階層は第０階層であるため、２行目の出現階層は第１階層となる。２行目には「＋１」が入力されているため、３行目の出現階層は第２階層となる。このような入力により、２行目の符号文のうちの選択文字列「CREATE」について、「出現階層が第１階層であるとき次の符号文の出現階層は第２階層」というルールが設定される。
なお、ここでは、出現階層領域２５４にて出現階層の変化量を設定するとして説明したが、出現階層領域２５４に変化後の出現階層そのものを設定してもよい。

このような態様によれば、テスト用の抽象ログに対して出現階層を設定していくだけで、実現テーブル生成部１５０は、各符号文についての出現階層制御ルールを自動的に実現率テーブルに反映させる。実現率についても同様である。２行目に「３０％」と設定すれば、実現テーブル生成部１５０は、第１階層における「CREATE」文字列により示されるコマンドの実現率は３０％というルールを実現率テーブルに設定する。また、第１階層の「CREATE」の実現率を３０％として設定し、別の部分で第１階層の「CREATE」の実現率を５０％として設定したとする。この場合には、その平均をとって、「第１階層の「CREATE」の実現率は４０％」というルールを設定してもよい。
また、実績に基づく確率統計処理により実現率を設定・調整してもよい。たとえば、第１階層に出現する「CREATE」文は１００箇所あり、そのうち、３０箇所が実際に実現されているという実績データが得られるときには、３０÷１００＝３０％として実現率を設定してもよい。このような設定方法によれば、実際の運用に基づく実績データが蓄積されるほど、合理的な実現率設定が可能となる。

図８は、危険度テーブルのデータ構造図である。
危険度特定部１６２は、危険度テーブルにしたがって抽象符号文ごとの危険度を特定する。そして、危険箇所抽出部１６４は、特定された危険度に基づいて抽象ログの危険箇所を特定する。抽出符号欄２６０は、抽象ログから抽出対象となる文字列を示す。条件欄２６２は、危険度制御判定のための条件を示す。危険度欄２６４は、危険度を示す。

たとえば、「abc.txt」という名前のファイルを取得する行為は、危険度「３０」として設定されている。一方、ログインに失敗するという行為は、危険度「１５」として設定される。一方、管理者権限によるログイン失敗は、より高い危険度「２５」が設定されている。

図９は、危険度判定処理を説明するための抽象ログを示す図である。
この抽象ログの１行目においては、「ログイン失敗」という抽象符号文が記述されている。危険度特定部１６２は、危険度テーブルにより、１行目の抽象符号文の危険度を「１５」と特定する。２行目においても再び「ログイン失敗」という抽象符号文が記述されている。危険度特定部１６２は、２行目の抽象符号文の危険度を１行目の危険度との累計として「３０（＝１５＋１５）」と特定する。ログインに２回連続で失敗しているため、危険度が高まっている。

３行目でログインに成功し、４行目で「T-SERVER」という名前のコンピュータにＦＴＰ接続、５行目で「abc.txt」というファイルを取得している。３行目の危険度は３０のまま、４行目の危険度は４０（＝３０＋１０）、５行目の危険度は７０（＝４０＋３０）となる。危険箇所抽出部１６４は、危険度が所定値、たとえば、５０を越える抽象符号文が「危険箇所」に該当するとしてマークをつける。ここでは、「abc.txtを取得」という抽象符号文にマークがつけられることになる。ログインに２回失敗した後にログイン成功し、内部公開サーバ２０８や限定公開サーバ２１０のような重要なサーバである「T-SERVER」にＦＴＰ接続がなされ、また、重要なファイルである「abc.txt」の取得がなされているため、不正が発生している可能性があると自動推定されることになる。

危険度テーブルにおいてどのようなルールを設定するかは管理者の自由である。どのような符号文がどのような条件にて出現したとき、危険度がどの程度かという判断は管理者のログ解析経験に基づいてルール化されればよい。このような態様によれば、経験の浅いシステム管理者であっても注視すべき箇所、すなわち、危険箇所とそうでない箇所を見極めやすくなる。

なお、変形例として、抽象符号文が進むごとに危険度が所定値、たとえば、５ずつ低下するとしてもよい。この場合、
１行目：ログイン失敗：危険度１５
２行目：ログイン失敗：危険度２５（＝１５＋１５−５）
３行目：ログイン成功：危険度２０（＝２５＋０−５）
４行目：FTP T-SERVER：危険度２５（＝２０＋１０−５）
５行目：abc.txtを取得：危険度５５（＝２５＋３０−５）
となる。このような態様によれば、抽象ログの中でも短期間に危険度が上昇している箇所を危険箇所として特定しやすくなる。

危険度判定処理は複数の抽象ログに基づいて実行することもできる。たとえば、外部端末２００からファイアウォール２０４を経由して内部公開サーバ２０８にアクセスする場合、そのアクセス履歴はファイアウォール２０４のログファイルと内部公開サーバ２０８のログファイルの両方に記録されることになる。

たとえば、以下の運用ルールを想定する。
１．外部端末２００から業務情報システム２２０には２時間以上アクセスを継続してはならない。
２．外部端末２００から内部公開サーバ２０８には１０分以上アクセスを継続してはならない。内部端末２１２から内部公開サーバ２０８には３時間以上アクセスを継続してはならない。

ファイアウォール２０４のログファイルにおいてログイン・ログアウトが記録された時間と、内部公開サーバ２０８のログファイルにおけるログイン・ログアウトが記録された時間を比較することにより、このような運用ルールから外れるときに危険度を設定してもよい。たとえば、内部公開サーバ２０８のログイン時間が１０分以上であって、かつ、内部公開サーバ２０８へのログイン前にファイアウォール２０４においてログインアクセスが記録されている場合、所定の危険度が設定されてもよい。運用ルールがどの程度まもられているかを危険度により定量的に判定できるため、運用ルールを定めつつも柔軟な運用が可能となる。
また、危険判定部１６０は、内部公開サーバ２０８へのアクセスが発生したときに、そのアクセスがリモート・アクセスであるかローカル・アクセスであるかを、ファイアウォール２０４のログファイルと内部公開サーバ２０８のログファイルから判定してもよい。たとえば、内部公開サーバ２０８のログファイルにおいて、２００７年７月２７日の午前１０：００〜午後２：００までにおいて、「ユーザＩＤ：Ａ」というユーザのアクセス履歴が記録されているとする。このユーザＩＤ：Ａに対応するユーザは「Ｘ」であるとする。一方、ファイアウォール２０４のログファイルにおいて、同時間帯において「ユーザＩＤ：Ｂ」というユーザのアクセス履歴が記録されているとする。このユーザＩＤ：Ｂに対応するユーザも「Ｘ」であるとする。ファイアウォール２０４にて記録されるユーザＩＤ、内部公開サーバ２０８にて記録されるユーザＩＤがそれぞれ誰に対応するかを管理しておくことにより、危険判定部１６０は上記時間帯におけるユーザ「Ｘ」のアクセスは、外部端末２００からのアクセスであると判定できる。

管理者は、図８に示した抽出符号欄２６０や条件欄２６２、危険度欄２６４に直接テキストや数値を記入することにより、危険度テーブルを設計してもよい。あるいは、所定の抽象ログを対象として条件や危険度を設定することにより、危険度テーブルを自動生成できる。

そのときの入力インタフェースは図７に示した実現率テーブル設計画面２５０と同様である。危険度テーブルの編集に際して、表示部１２４は、危険度テーブル設計画面（図示せず）を画面表示させる。ログ保持部１８０に保持される抽象ログのうち、テスト用ログとして設計者に指定された抽象ログが表示され、設計者は各符号文ごとの危険度判定ルールを入力する。なお、表示部１２４は、抽象符号文と原符号文の対応関係がわかるにように、抽象符号文によるソースログと原符号文による抽象ログを併置表示してもよい。原本としての証跡そのものを示すソースログと、可読性を高めた抽象ログを同一画面にて見比べることにより、解析時においてどのような抽象符号化がなされているかをより理解しやすくなる。

たとえば、図９の抽象ログをテスト用ログとする場合、１行目の「ログイン失敗」に危険度「３０」を割り当てると、危険判定部１６０は危険度テーブルに入力内容を反映させる。このときには、「ログイン失敗」という抽象符号文が現れたときには、自動的に危険度が「３０」だけ加算されることになる。なお、このような危険度は、対象となるサーバごとに異なる値が設定されてもよい。たとえば、内部公開サーバ２０８や限定公開サーバ２１０に対する「ログイン失敗」は危険度「３０」、外部公開サーバ２０６に対する「ログイン失敗」は危険度「１０」として設定されてもよい。

なお、本実施例における危険度判定処理は抽象ログを対象として実行されるが、変形例として、ソースログやユーザ定義ログを対象として危険度判定処理を実行してもよい。

以上、ログ解析支援装置１００を実施例に基づいて説明した。
１．抽象化処理、再抽象化処理
本実施例に示した抽象化処理によれば、機種に依存してさまざまな記録形式が存在する原符号文を、機種に依存する必要のない記録形式である抽象符号文に統一できる。このため、管理者は、さまざまなソースログの記録形式に習熟しなくても、抽象ログの記録形式さえ理解していれば、ログ解析を実行できる。管理者に求められるスキルレベルやログ解析にともなう作業負荷を軽減し、ログの可読性を高めることができる。

抽象化においては、アクセス内容をより詳細に示してもよい。通常、ＵＮＩＸ（登録商標）などのコマンドは、入力にともなう負荷を考慮して、「cd」のような簡単な符号により表現される。しかし、入力の容易性と可読性は必ずしも両立しない。ＵＮＩＸ（登録商標）のコマンドを知らなければ「cd」や「chdir」が「ディレクトリ変更（change directory）」の略称であることがわからない。そこで、抽象ログにおいては、ソースログよりも平易な表現でアクセス内容を示すことにより、抽象ログの可読性をいっそう高めることができる。また、データ名をそのまま抽象ログに記録するのではなく、そのデータの意味を示す別名による置き換え、または、別名の付記により、抽象ログの可読性を更に高めることができる。更に、所定の捨象規則に合致するコマンドを抽象ログへの記録対象から除外すれば、必要な内容だけを含むコンパクトな抽象ログを生成できる。
ログ解析支援装置１００は、標準記録形式としての抽象符号文をユーザの好みにあわせたユーザ符号文に変換する再抽象化処理により、ログの可読性をいっそう高めている。

２．実現判定処理
本実施例に示した実現判定処理によれば、ログに含まれるさまざまなテキストの中から実際にターゲットマシンに対してなんらかの影響を及ぼしている符号文を抽出しやすくなる。実現率テーブルにおいて出現階層と実現率の対応関係を設定することにより、ある程度、ノイズ情報を排除できる。将来的には、出現階層以外の変数に基づいて実現率を特定することも考えられる。また、抽象ログから非実現符号文を排除することにより、有効に実行された可能性が高い符号文だけを含む抽象ログへの要約も可能である。更に、図７に示した実現率テーブル設計画面２５０に対する入力によれば、テスト用ログを対象とした直感的な入力インタフェースにより、自動的に実現率テーブルを生成できるため、設計利便性も向上する。

３．危険度判定処理
本実施例に示した危険度判定処理によれば、危険度テーブルにおいて、条件と危険度の対応関係を設定することにより、典型的な危険箇所のパターンにあてはまる危険箇所を自動的に特定できる。また、テスト用ログを対象とした直感的な入力インタフェースにより、自動的に危険度テーブルを生成できるため、設計利便性も向上する。更に、複数の装置から生成される複数のログから危険度を特定することもできる。たとえば、内部端末２１２から内部公開サーバ２０８へは許可されるが、外部端末２００から内部公開サーバ２０８へのアクセスはルール違反とされる運用の場合を想定する。この場合、ファイアウォール２０４のログと内部公開サーバ２０８のログを突き合わせることにより、このような運用ルールが守られているかを自動的に判断できる。

先述したように、業務情報システムにとって情報セキュリティを客観的に証明できることが重要である。本実施例に示したログ解析支援装置１００によれば、抽象符号文という統一的記録形式にて、あらかじめ定められた実現率や危険度を判定するためのルールにしたがってログを解析できるため、客観的に情報セキュリティ・レベルを証明しやすくなる。

以上、本発明を実施例をもとに説明した。実施の形態は例示であり、それらの各構成要素や各処理プロセスの組合せにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。

本実施例においては、ＵＮＩＸ（登録商標）やＷＩＮＤＯＷＳ（登録商標）などのコマンドや、ＦＴＰコマンド、ＳＱＬなどを例としてログの解析方法を説明したが、ログ解析支援装置１００の応用範囲はこれらに限られない。たとえば、電子計測器を制御するためのＳＣＰＩ（Standard Commands for Programmable Instrumentation）言語によるソースコードについても、抽象化により可読性を高めることが可能である。

本実施例における業務情報システムのハードウェア構成図である。 本実施例におけるログ解析の処理過程を示す模式図である。 ログ解析支援装置の機能ブロック図である。 （ａ）符号文の抽象化のうち変更の一例を説明するための模式図である。（ｂ）符号文の抽象化のうち変更の別例を説明するための模式図である。（ｃ）符号文の抽象化のうち詳細化の一例を説明するための模式図である。 出現階層と実現率の関係を説明するための模式図である。 実現率テーブルのデータ構造図である。 実現率テーブル設計画面の画面図である。 危険度テーブルのデータ構造図である。 危険度判定処理を説明するための抽象ログを示す図である。

符号の説明

１００ ログ解析支援装置、 １１０ データ通信部、 １１２ ログ受信部、 １１４ ログ送信部、 １２０ ユーザインタフェース処理部、 １２２ 入力部、 １２４ 表示部、 １３０ データ処理部、 １３２ 抽象化部、 １３４ 標準抽象化部、 １３６ ユーザ抽象化部、 １４０ 実現判定部、 １４２ 出現階層特定部、 １４４ 実現箇所判定部、 １４６ ログ要約部、 １４８ 実現率調整部、 １５０ 実現テーブル生成部、 １６０ 危険判定部、 １６２ 危険度特定部、 １６４ 危険箇所抽出部、 １６６ 危険度テーブル生成部、 １７０ データ保持部、 １７２ 標準抽象規則保持部、 １７４ ユーザ抽象規則保持部、 １７６ 別名保持部、 １７８ 捨象規則保持部、 １８０ ログ保持部、 １８２ 実現率テーブル保持部、 １８４ 危険度テーブル保持部、 １９０ 抽出符号欄、 １９２ 第１実現判定欄、 １９４ 第２実現判定欄、 ２００ 外部端末、 ２０２ インターネット、 ２０４ ファイアウォール、 ２０６ 外部公開サーバ、 ２０８ 内部公開サーバ、 ２１０ 限定公開サーバ、 ２１２ 内部端末、 ２１４ 承認データ、 ２１６ ソースログ、 ２１８ 承認データベース、 ２２０ 業務情報システム、 ２３０ ログデータベース、 ２３２ 承認スナップ、 ２３４ ログスナップ、 ２３６ 診断結果データベース、 ２５０ 実現率テーブル設計画面、 ２５２ ログ表示領域、 ２５４ 出現階層領域、 ２６０ 抽出符号欄、 ２６２ 条件欄、 ２６４ 危険度欄。

Claims (6)

1. 所定機器に対するユーザの操作の内容が所定形式の符号文により記録されることにより、前記所定機器に対するユーザの操作履歴を符号文の集合として示すログを取得するログ取得部と、
   前記ログにおいて、基準となる符号文に基づく所定規則にしたがって、対象となる符号文の出現階層を特定する出現階層特定部と、
   符号文ごとに、出現階層と想定される実現率とを対応づけた実現率テーブルを参照して、前記ログに含まれる各符号文の実現率を特定し、前記特定した実現率が所定値以上となる符号文を抽出する符号文抽出部と、
   を備えることを特徴とするログ解析支援装置。
2. 前記ログから、前記抽出された符号文の集合として、前記所定機器に対する操作のうち有効に実行された可能性が高い操作の履歴を示す新たなログを生成するログ要約部、を更に備えることを特徴とする請求項１に記載のログ解析支援装置。
3. 前記対象となる符号文の示す操作の実現成否を示す符号文が前記ログに含まれているとき、前記対象となる符号文の実現率を調整する実現率調整部、を更に備えることを特徴とする請求項１に記載のログ解析支援装置。
4. 前記出現階層特定部は、前記対象となる符号文の示す操作の失敗を示す符号文が前記ログに含まれているときには、前記対象となる符号文に続く符号文の出現階層を変更することを特徴とする請求項１に記載のログ解析支援装置。
5. テスト用のログに含まれる符号文に対して、出現階層と実現率を指定するためのユーザによる入力を受け付ける条件設定部と、
   各符号文について付与された出現階層と実現率を参照して、前記実現率テーブルを生成する実現テーブル生成部と、
   を更に備えることを特徴とする請求項１に記載のログ解析支援装置。
6. 所定機器に対するユーザの操作の内容が所定形式の符号文により記録されることにより、前記所定機器に対するユーザの操作履歴を符号文の集合として示すログを取得する機能と、
   前記ログにおいて、基準となる符号文に基づく所定規則にしたがって、対象となる符号文の出現階層を特定する機能と、
   符号文ごとに、出現階層と想定される実現率とを対応づけた実現率テーブルを参照して、前記ログに含まれる各符号文の実現率を特定し、前記特定した実現率が所定値以上となる符号文を抽出する機能と、
   をコンピュータに発揮させることを特徴とするログ解析支援プログラム。

Images