JP4732874B2

JP4732874B2 - ソフトウェア動作モデル化装置、ソフトウェア動作監視装置、ソフトウェア動作モデル化方法及びソフトウェア動作監視方法

Info

Publication number: JP4732874B2
Application number: JP2005342717A
Authority: JP
Inventors: 晃金野; 雄大中山
Original assignee: NTT Docomo Inc
Current assignee: NTT Docomo Inc
Priority date: 2005-11-28
Filing date: 2005-11-28
Publication date: 2011-07-27
Anticipated expiration: 2025-11-28
Also published as: US20070204257A1; EP1811381A3; US8015551B2; JP2007148818A; EP1811381B1; CN1975750A; CN1975750B; EP1811381A2

Description

本発明は、ソフトウェア動作モデル化装置、ソフトウェア動作監視装置、ソフトウェア動作モデル化方法及びソフトウェア動作監視方法に関する。

ＰＣやワークステーション、サーバ、ルータ、携帯電話、ＰＤＡなど、すべての計算機は外部もしくは内部からの攻撃にさらされている。代表的な攻撃は、計算機上で実行されているソフトウェアの脆弱性を踏み台にしたものである。攻撃者はソフトウェアの脆弱性を利用した悪意のあるコードを計算機に送り込み、実行中のプロセスの制御を奪い、当該プロセスの権限を利用して不正操作をおこなう。

脆弱性を利用した攻撃、特に未知の攻撃を検知するために、プログラムの正常な動作をモデル化し、プログラム実行中にモデルからの乖離の有無を判定する異常検知システムがある。システムコールは、プロセスがカーネルにシステム上重要な処理を依頼する際に行う命令であり、攻撃者は、プロセスが依頼するシステムコールを用いて、システムに任意の行動をさせる。そのため、プログラムの動作を監視する際にシステムコールの正当性を検証することが行われる。

プログラム実行中にシステムコールの正当性を検証する手法として、例えば、システムコール発行元の関数がメモリのコード領域に存在することを正常とし、プログラム（タスク）から発行されたシステムコール要求を入力し、正当性検査機能へのジャンプアドレスを出力するシステムコールテーブルと、システムコール要求発行時にOSによって特定のメモリ領域に格納されるシステムコール呼び出し元のリターン関数アドレスから、システムコール要求の正当性を判定し判定結果を出力するとともに、不正なシステムコール要求と断定した場合、そのシステムコール要求を棄却する正当性検査機能手段と、正当性検査機能手段の不正システムコール要求判定結果を入力し、対策を講ずる攻撃対策機能手段と、正当性検査機能手段の正当システムコール要求判定結果を入力して呼び出され、命令を実行するシステムコールとを備える攻撃対策装置が開示されている（例えば、特許文献１参照。）。

又、システムコールの正当性を検証するために、コールスタックの状況（スタックに詰まれたリターンアドレスの列）を利用する攻撃検知システムが開示されている（例えば、非特許文献１参照。）。このシステムでは、まずプログラムを事前に実行し、得られた結果からモデルを学習する。プログラム実行中にシステムコール発生時のコールスタックの状況を取得し、システムコール発生時のプログラムカウンタとともに記録したVirtual Stack Listを生成し、又、現在のVirtual Stack Listと一つ前のVirtual Stack Listとの差分情報、すなわち比較対象のコールスタックの状況のスタック最下位より比較検証を順次行い異なるリターンアドレスを検出してから以降のリターンアドレスの列（Virtual Path）とを生成する。生成されたVirtual Stack ListとVirtual Pathからハッシュテーブルを生成し、そのテーブルをプログラムのモデルとして利用する。プログラムを検証する際には、プログラム実行中に、Virtual Stack ListとVirtual Pathを生成し、モデルであるハッシュテーブルとのマッチングを行い、合致していればシステムコール要求に対し許可をし、合致しなければ、異常であると判定する。
特開２００４−１２６８５４号公報 H.Fengら、 "Anomaly Detection Using Call Stack Information", The proc. of IEEE Symposium on Security and Privacy 2003, pp.62.

LinuxをはじめとするOSにおいては、通常システムコールがWrapper関数を介して発行される。Wrapper関数はコード領域に存在しているため、システムコール発行元の関数は常にコード領域に存在する。又、攻撃として主流であるReturn-to-libc攻撃の場合、攻撃者はlibcへReturnをさせて任意のシステムコールを発行する。以上の状況を考えると、システムコール発行元の関数のアドレスがコード領域にあることで正当とみなしてしまう特許文献1記載の攻撃対策装置では、検知できない攻撃が存在する。又、非特許文献1記載の攻撃検知システムは、コールスタックに詰まれたリターンアドレスを用いて検証をしているため、特許文献１記載の攻撃対策装置よりも詳細なモデル化を行っているといえる。そのため、非特許文献1記載の攻撃検知システムは、特許文献１記載の攻撃対策装置よりも、攻撃の見逃しを低減しているといえる。

しかしながら、非特許文献1記載の攻撃検知システムは、検証時にはハッシュによるマッチングを行っているため、モデル化をする際、学習を十分行わないと、検証時に未学習の動作が起きた時に、たとえ正常であったとしても異常であると判断（誤り検出）せざるを得ず、誤り検出が大きくなってしまう。

又、携帯電話など処理能力の低い計算機において動作を検証するシステムを搭載するためには、限られた資源での処理の高速化、使用メモリ量の抑制が重要となる。

そこで、本発明は、上記の問題に鑑み、誤り検出を低減するとともに、限られた資源での処理の高速化、使用メモリ量の抑制を実現するソフトウェア動作モデル化装置、ソフトウェア動作監視装置、ソフトウェア動作モデル化方法及びソフトウェア動作監視方法を提供することを目的とする。

上記目的を達成するため、本発明の第１の特徴は、（ａ）ソフトウェアの実行中に、特定のイベントごとに、特定のイベント間で実行された関数コールの発行順を取得もしくは推定する、関数コール順取得手段と、（ｂ）関数コール順取得手段によって取得もしくは推定された関数コールの発行順と特定のイベントとの共起関係を統計的に把握し、把握した共起関係を当該ソフトウェアの動作モデルとして記録する、モデル生成手段とを備えるソフトウェア動作モデル化装置であることを要旨とする。

又、第１の特徴に係るソフトウェア動作モデル化装置の関数コール順取得手段は、関数コールの発行順に加えて、関数リターンの発行順もあわせて取得もしくは推定してもよい。

又、第１の特徴に係るソフトウェア動作モデル化装置の関数コール順取得手段は、特定のイベントが発生した時点でのプロセススタックに詰まれたリターンアドレスをスタックに詰まれた順がわかるように取得し、特定のイベント発生順に記録し、記録した情報を関数コールの発行順とするスタック情報取得手段を含んでもよい。

又、第１の特徴に係るソフトウェア動作モデル化装置の関数コール順取得手段は、iを自然数として、スタック情報取得手段によって取得されたi-1番目のスタック情報とi番目のスタック情報との差分情報を関数コールの発行順として生成するスタック差分情報生成手段を含んでもよい。

又、第１の特徴に係るソフトウェア動作モデル化装置のモデル生成手段は、スタック情報あるいは差分情報の一部を使用して共起関係を統計的に把握してもよい。

又、第１の特徴に係るソフトウェア動作モデル化装置のモデル生成手段は、把握した共起関係から相関規則を生成してもよい。

又、第１の特徴に係るソフトウェア動作モデル化装置のモデル生成手段は、関数コールの発行順に登録された関数コール識別子のうち、頻度の高いものを根ノードの近くに配置し、特定のイベントの識別子を葉ノードとする木構造を構築した木構造情報を生成し、木構造情報と、関数コールの発行順に登録された関数コール識別子の頻度順情報とをあわせて記録することにより、相関規則を生成してもよい。

又、第１の特徴に係るソフトウェア動作モデル化装置において、特定のイベントとは、システムコールであってもよい。

本発明の第２の特徴は、（ａ）ソフトウェアの実行中に、特定のイベントごとに、特定のイベント間で実行された関数コールの発行順を取得もしくは推定するステップと、（ｂ）関数コール順取得手段によって取得もしくは推定された関数コールの発行順と特定のイベントとの共起関係を統計的に把握し、把握した共起関係を当該ソフトウェアの動作モデルとして記録するステップとを含むソフトウェア動作モデル化方法であることを要旨とする。

本発明の第３の特徴は、（ａ）監視対象のソフトウェアが発行した特定のイベントと、特定のイベントごとに、特定のイベント間で実行された関数コールの発行順との共起関係を統計的に把握し、把握した共起関係を示した動作モデルを取得する動作モデル取得手段と、（ｂ）ソフトウェアの実行中に、ソフトウェアが実行した関数コールの発行順を取得もしくは推定する、関数コール順取得手段と、（ｃ）関数コール順取得手段が取得した関数コールの発行順と特定のイベントとの共起関係と動作モデルとの乖離を判定する動作監視手段とを備えるソフトウェア動作監視装置であることを要旨とする。

又、第３の特徴に係るソフトウェア動作監視装置の関数コール順取得手段は、特定のイベントが発生した時点でのプロセススタックに詰まれたリターンアドレスをスタックに詰まれた順がわかるように取得し、特定のイベント発生順に記録し、記録した情報を関数コール順とするスタック情報取得手段を含んでもよい。

又、第３の特徴に係るソフトウェア動作監視装置の関数コール順取得手段は、iを自然数として、スタック情報取得手段によって取得されたi-1番目のスタック情報とi番目のスタック情報との差分情報を関数コールの発行順として生成するスタック差分情報生成手段を含んでもよい。

又、第３の特徴に係るソフトウェア動作監視装置の動作モデル取得手段が取得する動作モデルは、監視対象のソフトウェアが発行した特定のイベントと関数コール順との相関規則を示してもよい。

又、第３の特徴に係るソフトウェア動作監視装置の動作モデル取得手段が取得するモデルは、関数コールの発行順に登録された関数コール識別子のうち、頻度の高いものを根ノードの近くに配置し、特定のイベントの識別子を葉ノードとするような木構造を構築した木構造情報と、関数コールの発行順に登録された関数コール識別子の頻度順情報が記されたモデルであって、関数コール順取得手段は、取得した関数コール順を頻度順情報に従って、並べ替え、動作監視手段は、並べ替えた関数コール順が、木構造情報に存在しているかどうかを探索してもよい。

又、第３の特徴に係るソフトウェア動作監視装置の動作監視手段は、監視対象のソフトウェアが発行した特定のイベントと関数コール順との共起関係と、動作モデルが示す相関規則との乖離を監視する際、相関規則が示す信頼度をパラメータとしたスコアを計測し、スコアが、あらかじめ定めた閾値を超えた場合を検知してもよい。

又、第３の特徴に係るソフトウェア動作監視装置において、特定のイベントとは、システムコールであってもよい。

又、第３の特徴に係るソフトウェア動作監視装置は、関数コール順取得手段によって取得もしくは推定された関数コールの発行順と特定のイベントとの共起関係を統計的に把握し、把握した共起関係を当該ソフトウェアの動作モデルとして記録する、モデル生成手段を更に備えてもよい。

本発明の第４の特徴は、（ａ）監視対象のソフトウェアが発行した特定のイベントと、特定のイベントごとに、特定のイベント間で実行された関数コールの発行順との共起関係を統計的に把握し、把握した共起関係を示した動作モデルを取得するステップと、（ｂ）ソフトウェアの実行中に、ソフトウェアが実行した関数コールの発行順を取得もしくは推定するステップと、（ｃ）関数コール順取得手段が取得した関数コールの発行順と特定のイベントとの共起関係と動作モデルとの乖離を判定するステップとを含むソフトウェア動作監視方法であることを要旨とする。

本発明によると、誤り検出を低減するとともに、限られた資源での処理の高速化、使用メモリ量の抑制を実現するソフトウェア動作モデル化装置、ソフトウェア動作監視装置、ソフトウェア動作モデル化方法及びソフトウェア動作監視方法を提供することができる。

次に、図面を参照して、本発明の実施の形態を説明する。以下の図面の記載において、同一又は類似の部分には、同一又は類似の符号を付している。ただし、図面は模式的なものであることに留意すべきである。

＜第１の実施の形態＞
（ソフトウェア動作モデル化装置及びソフトウェア動作モデル化方法）
第１の実施形態に係るソフトウェア動作モデル化装置１００は、図１に示すように、ソフトウェアの特定のイベント発生（例えば、システムコール）のときに、特定のイベントの間で行われた、ソフトウェアが実行する関数コールの発行順および任意で関数リターンの発行順（以下において、「関数コール順」という。）を把握する関数コール順取得手段１０４と、関数コール順と特定のイベントの共起関係を統計量として表したものをソフトウェアの動作モデルとして生成するモデル生成手段１０３とを備える。又、ソフトウェア動作モデル化装置１００は、ソフトウェア２００の動作をモデル化し、モデル記録装置３００に、その動作モデル３０４を記録する。

関数コール順取得手段１０４は、スタック情報取得手段１０１とスタック差分情報生成手段１０２とを備える。尚、図１に示す関数コール順取得手段１０４の構成は、一例であり、スタック情報取得手段１０１はなくてもよい。スタック情報取得手段１０１がない場合は、プログラムをシングルステップで動作させ、関数コールと任意で関数リターンをフックすればよい。第１の実施の形態では、この構成をとることによって、プログラムをシングルステップで動作させることなく、特定のイベント発生時に停止させる効率のよい関数コール順の把握を採用するものとする。

又、スタック情報取得手段１０１がある場合、スタック差分情報生成手段１０２はあってもなくてもよい。スタック差分情報生成手段１０２がない場合、ソフトウェア動作モデル化装置１００は、プロセススタックの情報をもちいた関数コールの順序を把握する装置となる。スタック差分情報生成手段１０２を備えることにより、関数コールだけでなく関数リターンを含めた関数コール順を把握することができ、より詳細な動作をモデルに含めることができるので、第１の実施の形態では、この構成を採用するものとする。

スタック情報取得手段１０１は、ソフトウェアの特定のイベント発生（例えば、システムコール２０１）時に、特定のイベントの識別子（例えば、システムコール番号２０５）とプロセススタック情報２０２とを取得し、特定のイベントの識別子（例えば、システムコール番号２０５）とプロセススタック情報２０２とをソフトウェア２００の動作モデルとして、モデル記録装置３００に記録する。又、スタック情報取得手段１０１は、特定のイベントの識別子（例えば、システムコール番号２０５）と、スタック情報２０２とをスタック差分情報生成手段１０２に伝える。尚、特定のイベント識別子、スタック情報は、動作モデルとして記録されてもされなくてもよい。

ここで、システムコール２０１は、スタック情報取得手段１０１が取得する特定のイベントの例であり、システムコール以外にも、jmpやbranch命令、プロセッサ例外時などがあげられる。システムコールは、システム上重要な処理を行うための命令であるため、重要な監視ポイントである。第１の実施の形態では、システムコールすべてを特定のイベントとする。尚、監視するシステムコールをソフトウェアの特性などにあわせて選択してもよい。例えば、execve（プロセスを起動する）を実施するソフトウェアの場合、もし攻撃者にこのソフトウェアの脆弱性をつかれた場合、execveを巧みに発行され、/bin/shを立ち上げられる可能性がある。よって、execveを監視するシステムコールとして選択してもよい。又、writeは、ファイルに書き込むシステムコールであるが、悪意ある攻撃者はwriteを巧みに発行し、ファイルの改ざんに利用する。よって、writeを監視するシステムコールとして選択してもよい。限られた計算資源の中で監視するために、execveやwriteのような非常に重要な監視ポイントだけを選択して監視することは効果的であるといえる。

スタック情報２０２とは、システムコールが発生した時の、プロセスコールスタックに関数コールで詰まれたリターンアドレスの集合であり、スタックに詰まれた順序がわかる情報である。デバッグツール（Linuxのptraceなど）を用いることにより、ソフトウェアをシステムコール発生ごとに停止させることができ、かつその時点でのレジスタの値をみることができる。例えば、スタックポインタやスタックベースポインタが格納されるレジスタの値を見れば、それぞれが指し示すアドレスを取得することができる。スタックベースポインタの直後のアドレスには、リターンアドレスが詰まれているため、その値をピックアップすることで、プロセススタック情報２０２を得ることができる。

図２は、スタック情報とシステムコールを取得するスタック情報取得手段１０１の概念図である。尚、図２に示したスタック例では、スタック下位方向へ詰まれていくものとする。iを自然数とすると、状態i-1から状態iに移る際、システムコールCiが発行される。この時点でのスタック情報Siを取得し、Siの最下位にシステムコール発行時のプログラムカウンタ値Piを追加する。スタック情報取得手段１０１は、システムコールCiを識別する識別子と、スタック情報Siを例えば上述の仕組みで取得する。

図３は、スタック情報取得手段１０１の動作例を示すフローチャートである。

スタック情報取得手段１０１は、監視対象ソフトウェアの終了判定（ステップＳ１００）を経て、ソフトウェアが終了していなければ、ソフトウェアが発行するシステムコールをフックする（ステップＳ１０１）。フックするためにptraceなどを用いることができる。システムコールをフックすると、スタック情報を読み込み（ステップＳ１０２）、スタック情報を生成し（ステップＳ１０３）、スタック情報を記録する（ステップＳ１０４）。

ステップＳ１００において、ソフトウェアが終了したと判定した場合は、スタック情報取得手段１０１の動作を終了する。ここで得られたスタック情報の例を図４に示す。図４の左側の列は、システムコール番号が発行順に記録されている。図４の右側の列は、システムコール番号に対応したスタック情報が記録されている。すなわち、システムコール１２２番が最初に発行され、この時点でのスタックに詰まれたリターンアドレスは、スタックの下から0x80000001、 0x80000123、 0x80000345の順（すなわち、0x80000345から処理される）である。次に、システムコール４番が発行され、この時点でのスタックに詰まれたリターンアドレスは、スタックの下から、0x80000001、 0x80000456、 0x80000567である。次に、システムコール４番が発行され、この時点でのスタックに詰まれたリターンアドレスは、スタックの下から、0x80000001、 0x80000321、 0x80000654である。同様に、システムコールが発行されるたびに、スタック情報が記録されていく。

スタック差分情報生成手段１０２は、スタック情報２０２を取得し、スタック差分情報２０３をソフトウェア２００の動作モデルとしてモデル記録装置３００に記録する。又、スタック差分情報生成手段１０２は、システムコール番号２０５と、スタック情報２０２とをモデル生成手段１０３に伝える。尚、スタック差分情報は、動作モデルとして、記録されてもされなくてもよい。

ここで、スタック差分情報２０３とは、現在受け取ったスタック情報２０２と、それ以前に受け取ったスタック情報２０２との差分を表す情報である。図５は、スタック差分情報２０３の概念を示す図である。スタック差分情報生成手段１０２は、iを自然数として、スタック情報Si-1とスタック情報Si（それぞれ図２に示すのものと同じ）を用い、それぞれを差分比較する。すなわち、スタックの最上位から順次比較し、同一の値でない箇所までたどり着いたところ（本例では、最上位から数えて３つ目）で、それ以下を差分情報として抽出する。スタック差分情報Diは、スタック情報Si-1の最下位から「２」まで、スタック情報Siは「３」から最下位までをこの順序で並べたものである。スタック情報Si-1の最下位から「２」までの情報は、状態i-1から状態iにいたるまでに、リターンされた関数の順列であり、又、スタック情報Siの「３」から最下位までの情報は、状態i-1から状態iにいたるまでにコールされた関数の順列である。すなわち、スタック差分情報Diは、システムコールCiが発行されるまでに起こったリターンとコールの順序を推測する情報といえる。ソフトウェア動作監視において、システムコールの発生のみをモデルに加えたものには、偽装攻撃（Mimicry Attack）の脆弱性があるといわれており、その解決のために関数コールやリターンをモデルに加える提案が多数されてきた。関数コールやリターンは、システムコールと比較すると、OSからすれば他のインストラクション（movやjmpなど）と同じレベルの命令であるため、関数コールやリターンを正しく取得するためには、ソフトウェアをステップ実行するしかない。しかし、ステップ実行はソフトウェア実行速度への大きなオーバーヘッドとなり、携帯電話など計算能力が低い計算機では実用的でない。一方、スタック差分情報は、システムコール発生時に取得可能な情報なので、ソフトウェアはシステムコール発生時にとめるよう実行すればよい。これはステップ実行よりもはるかに実行速度へのオーバーヘッドを削減できる。

図６は、スタック差分情報生成手段１０２の動作例を示すフローチャートである。スタック差分情報生成手段１０２は、スタック情報終了判定（ステップＳ２００）を経て、終了していなければ、スタック情報を順次読み込み（ステップＳ２０１）、過去のスタック情報と現在のスタック情報の差分を比較し（ステップＳ２０２）、スタック差分情報を生成（ステップＳ２０３）し、スタック差分情報を記録する（ステップＳ２０４）。

ステップＳ２００で終了と判断された場合は、スタック差分情報生成手段１０２の動作を終了する。図７は、スタック差分情報生成手段１０２に、図４に示すスタック情報が入力された場合、スタック差分情報生成手段１０２によって生成されたスタック差分情報とシステムコール番号の例である。図４に示す、1行目と2行目を読み込み（図６のステップＳ２０１）、差分を比較する（図６のステップＳ２０２）。比較する際、スタックの下から順に（すなわち図４において左から）行っていく。すると、1行3列目の0x80000345と、2行3列目の0x80000456、同じく4列目の 0x80000567が異なっていることがわかる。スタック差分情報を生成する（図６のステップＳ２０３）際は、過去のスタック情報はスタックの上から（すなわち図４において右から）変化のなくなる行までをその順に並べ替えて抽出（図４の1行目の場合、0x80000345のみとなる）し、記録する（図６のステップＳ２０４）。現在のスタック情報は、スタックの下から初めて変化した箇所から、スタックの最上位までをその順で抽出（図４の2行目の場合、0x80000456、0x80000567となる）し、記録する。この記録の際、現在のシステムコール番号（図４の2行目の場合、４）を合わせて記録する。その結果、図７の2行目に表されるようなスタック差分情報が生成される。以下同様に、図４の2行目、3行目から、図７の3行目に表されるようなスタック差分情報が生成される。

モデル生成手段１０３は、スタック差分情報２０３を受け、相関情報２０６をソフトウェア２００の動作モデル２０４として、モデル記録装置３００に記録する。

ここで、相関情報２０６とは、システムコール番号２０５とスタック差分情報２０３との共起関係を表す情報であり、例えば、N-gramや、相関規則等が挙げられる。N-gramを利用して共起関係を把握する場合は、例えば、「“A New Method of N-gram Statistics for Large Number of n and Automatic Extraction of Words and Phrases from Large Text Data of Japanese”、長尾真著、In proceedings of the 15^th International Conference on Computational Linguistics(1994) pp611-615」に記載のアルゴリズムを用いることにより、実施できる。

第１の実施の形態では、相関情報２０６として、相関規則を生成するものとして説明する。相関規則とは、トランザクションセットから、あるアイテム集合Ａが起きたときのあるアイテムＢの出現確率Ｐ（すなわち、条件付確率）を求め、トランザクションセット全体でのルールとしたものである。ここで、アイテム集合Ａを前例、アイテムＢを結果、出現確率Ｐを信頼度と呼ぶ。本実施形態では、スタック差分情報２０３から前例を抽出し、システムコール番号２０５を結果とした相関規則を生成する。

図７は、上述したように、スタック差分情報２０３の例である。左側の列はシステムコール番号であり、右側の列は、システムコール番号に対応するスタック差分情報である。システムコール番号が共に4である2行目と3行目に着目すると、0x80000567はスタック差分情報としてどちらにも存在するので、0x80000567を前例とし、4を結果とした場合は、信頼度100%である。この場合、図８に示すように、相関規則のリストとして、0x80000567→4 100%と記載することとする。同様に、0x80000567と0x80000456の組み合わせは、スタック差分情報としてどちらにも存在するので、0x80000567、0x80000456の組み合わせを前例とし、4を結果とした場合は、信頼度100%であるため、0x80000567、0x80000456→4 100%と記載する。前例は、スタック差分情報上のリターンアドレスの組み合わせであり、組み合わせ数全てに対して信頼度を導出するためには、非常に多くの処理が必要となるが、AprioriやFPGrowthなどの相関規則導出アルゴリズムを用いることにより効率よく相関規則を得ることができる。

FP-Growthは、計算高速化のために、最初にデータベースを読み込み、後の計算で必要となるアイテムセットの支持度を主記憶中に保持するFP-Treeアルゴリズムを利用している。

FP-Treeアルゴリズムの詳細は、例えば、「“Mining frequent patterns without candidate generation”、Hanら著、In proceedings of SIGMOD International Conference on Management of Data, pp1-12, ACM, 2000」に記載されている。ここでは概念を説明する。FP-tree は、頻出アイテムのみで構成される木構造データである。FP-Treeをデータベースから構築するために、まず、頻出アイテムを抽出する。データベースを1回スキャンし、抽出された頻出アイテムを指示度の値により、頻度が降順になるように並び替えたリスト（このリストをF-list とする）を生成する。そして、空（null）のラベルを持つ木のルートを作る（この木をT とする）。

こうして得られた頻出アイテムとルートノードを利用して、FP-tree 構造を構築するための2 回目のスキャンが行われる。具体的には、以下の手順でFP-tree 構造を構築する。

事前にカレントノードをルートノードとしておく。

各トランザクションに対して、
（１）頻出アイテムを抽出し、アイテムをF-listに従って並べ替える（アイテムリストと呼ぶ）。このアイテムリストを用いて、Tを成長させることになる。

（２）アイテムリストから順次アイテムを取り出し、T上の「カレントノード」が、取り出したアイテムと同じ子を持っていれば、その子のカウントを1 増やし、カレントノードをその子に移す。そうでないときは、新しくカウント1 を持つ子を作り、カレントノードをその子に移す。

（３）アイテムリストの最後の要素まで、上記（２）の操作を繰り返す。最後の要素が終わったら、対象のトランザクションを変更し、全てのトランザクションにおいて処理を終えるまで（１）の操作を行う。

（４）全てのトランザクションで処理を終えたら、同じ名前を持つノードにリンクを付ける。更に、各頻出アイテムai に対して、先頭のai を指すヘッダテーブルを作成する。

以上の操作を行って構築されたFP-Treeを用いて、頻出パターンをマイニングしていく。FP-Treeの構築の例を図９に示す。

ここで、モデル生成手段１０３は、システムコール識別子を値としてもつ葉ノードを追加したFP-Treeを構築し、このFP-Treeをプログラムの動作モデルとして生成する。各ノードには、アイテムの頻度が記されているので、支持度、信頼度の計算も容易に行える。生成したモデルは、プログラムの識別子・F-listとともに記録する。

このようにモデルを構成することによって、同一の前例をまとめることができ、効率のよいモデルを生成することができる。

以上の方法は、FP-Treeアルゴリズムを採用して木構造を生成したが、ルート側に頻度の高いアイテムが配置されるようにすればよいので、他のアルゴリズムを適用してもよい。

尚、上述の方法例では、相関規則を導出する際、前例としてスタック差分情報上のリターンアドレスすべてを利用したが、ソフトウェア実行環境などを考慮し、すべてを利用しなくてもよい。例えば、処理能力の低いプロセッサ上でモデル化を行う場合、システムコールが発行する直前のN個だけを抽出することで、モデルの生成コストを削減できる。又、システムコールの種類ごとにNの値を変えることも考えられる。又、たとえば、LinuxKernel2.4以上の場合を考えると、スタック差分情報上のリターンアドレスのうち、最後のリターンアドレスは、システムコールを行うためのWrapper関数によるものであり、システムコールとの共起関係が非常に強い。このリターンアドレスを含めたまま相関規則を生成してしまうと、非常に偏ったモデル、すなわちWrapper関数とシステムコールの関係のみがモデルとして得られてしまう恐れがある。そこで、相関規則を生成する際には、最後のリターンアドレスを除外することが考えられる。又、あるアドレス空間（たとえば、ライブラリがロードされた空間）内にリターンアドレスがはいっている場合を抽出することなども考えられる。

尚、上述の相関規則は、AprioriやFPGrowthなどを利用して導出していたが、このアルゴリズムを利用すると、関数コール順の順序情報を考慮しないが、関数コール順の順番を前例に含めてもよい。例えば、図７に示すスタック差分情報の2行目と3行目に着目すると、左から2番目の0x80000456が同一の値を示しており、どちらもシステムコールが4である。そこで、2番目=0x80000456→4 100%という規則を生成できる（図１０参照）。このように順序を考慮することで、より詳細な情報をモデルとして組み入れることができる。

第１の実施の形態では、図８に示す相関規則をソフトウェアの動作モデルとしてモデル記録装置３００に記録する。

図１１は、モデル生成手段１０３の動作例を示すフローチャートである。第１の実施の形態では、相関規則を生成する。モデル生成手段１０３は、スタック差分情報を取得し、スタック差分情報の終了判定（ステップＳ３００）を経て、終了していなければ、スタック差分情報を順次読み込む（ステップＳ３０１）。ステップＳ３００で終了と判定されていれば、そこから相関規則を生成し（ステップＳ３０２）、記録する（ステップＳ３０３）。ステップＳ３０２では、各スタック差分情報と関連するシステムコール番号の組を１トランザクションとみなし、スタック差分情報から前例を抽出し、図８に示すように、システムコール番号を結果とする相関規則を生成する。

（作用及び効果）
第１の実施の形態に係るソフトウェア動作モデル化装置及びソフトウェア動作モデル化方法によると、ソフトウェアの実行中に、特定のイベントごとに、特定のイベント間で実行された関数コール順を取得もしくは推定し、取得もしくは推定された関数コール順と特定のイベントとの共起関係を統計的に把握し、把握した共起関係を当該ソフトウェアの動作モデルとして記録することができる。

このようにソフトウェア動作モデル化装置を構成する、あるいはソフトウェア動作モデル化方法をとることで、詳細レベルの監視を行い、かつ、未学習動作に対して統計的な判断を行うための統計量を、動作モデルとして出力することができる。

特に、相関規則は共起関係を小さいデータ量で表すことが可能であるため、軽量なソフトウェア動作監視システムに有効なモデルを生成することができる。携帯電話など、記憶装置の容量が限られる端末に有効である。プログラムは論理的に構成されているため、関数コールの順序（あるいは文脈）はプログラムの動作をモデル化するうえで非常に重要な要素である。しかし、一般的に相関規則は順序を考慮しない。そこで、本発明は、モデル生成手段が、共起関係を把握する際に、関数コールの順序も考慮して把握することを特徴とする。このように構成することで、順序を考慮しない相関規則よりも詳細なモデル化を行うことができる。

システムコール命令やTrap命令は、システム上重要な処理をカーネルに依頼する際におこなわれる命令であり、プログラムの動作監視上重要なイベントである。相関規則において、前例を関数コール順、特定のイベント（Trap命令、システムコール）を結果とした相関規則を生成することで、動作の監視をすべきイベントごとの特性を捕らえたモデルを出力することができる。

又、第１の実施の形態に係るソフトウェア動作モデル化装置の関数コール順取得手段は、特定のイベントが発生した時点でのプロセススタックに詰まれたリターンアドレスをスタックに詰まれた順がわかるように取得し、特定のイベント発生順に記録し、記録した情報を関数コールの発行順とするスタック情報取得手段を含む。

通常、関数コールを完全にフックし、順序をとらえようとすると、プログラムをシングルステップで動作させる必要があるが、このように構成することによって、特定のイベント発生時にのみプログラムを停止しさえすればよい。例えば、特定のイベントがシステムコールやTrap命令の場合、デバッグツール（Linuxのptraceなど）を用いると、その特定のイベント時にプログラムの動作を停止し、その時点でのレジスタの値を把握することができる。レジスタには、スタックポインタやベースポインタの値が格納されているため、その値を利用することで、リターンアドレスを詰まれた順を理解しながら取得することができる。このリターンアドレスの順は、特定のイベント発生にいたるまでにプロセスが発行した関数コールの順を示しており、この情報を利用することで、特定のイベント間での関数コール順を推定することができる。ここでいう推定とは、関数コール順の一部を把握するという意味である。特定のイベント間でAという関数がコールされ、リターンまで行われると、特定のイベント発生時のプロセススタックにはAという関数は情報としてのらない。そのため、一部を把握することになる。

又、第１の実施の形態に係るソフトウェア動作モデル化装置の関数コール順取得手段は、iを自然数として、スタック情報取得手段によって取得されたi-1番目のスタック情報とi番目のスタック情報との差分情報を関数コールの発行順として生成するスタック差分情報生成手段を含む。

このように構成することによって、関数コールだけでなく、関数リターンまでを含む関数コール順を推定することができる。関数リターンを含めることで、詳細なモデル化を行うことができる。

このように一部を使用することにより、モデルの生成コストを低減することができる。

このように相関規則を生成することにより、限られた資源での処理の高速化、使用メモリ量の抑制を実現することができる。

又、共起関係に加えて、スタック情報、スタック差分情報を合わせてソフトウェアの動作モデルとして記録することで、非特許文献１に記載の攻撃検知システムで利用する動作モデルを加えることができる。

又、第１の特徴に係るソフトウェア動作モデル化装置のモデル生成手段は、関数コールの発行順に登録された関数コール識別子のうち、頻度の高いものを根ノードの近くに配置し、特定のイベントの識別子を葉ノードとする木構造を構築した木構造情報を生成し、木構造情報と、関数コールの発行順に登録された関数コール識別子の頻度順情報とをあわせて記録することができる。このため、同一の前例をまとめることができるため、モデルサイズを小さくすることができる。

＜第２の実施の形態＞
（ソフトウェア動作監視装置及びソフトウェア動作監視方法）
第２の実施の形態に係るソフトウェア動作監視装置４００は、図１２に示すように、ソフトウェアの動作モデルが記録されたモデル記録装置３００と接続し、ソフトウェア２００の動作を監視し、監視結果５０４を出力する。ソフトウェア動作監視装置４００は、ソフトウェアの特定のイベント発生（例えば、システムコール）のときに、特定のイベントの間で行われた、ソフトウェアが実行する関数コール順を把握する関数コール順取得手段４０４と、ソフトウェア２００に対応した動作モデル６００をモデル記録装置３００から取得する動作モデル取得手段４０５と、動作モデル取得手段４０５によって取得された動作モデルと、システムコール番号５０１及び関数コール順５０４を受け、システムコール番号５０１と関数コール順５０４の動作モデル６００からの乖離の有無を判定し、監視結果５０４を出力する動作監視手段４０３とを備える。

関数コール順取得手段４０４は、ソフトウェア２００がシステムコールなどを発行するたびにシステムコール番号５０１とその時点のスタック情報５０２を取得し、スタック情報５０２を生成するスタック情報取得手段４０１と、システムコール番号５０１とスタック情報５０２を受け、過去と現在のスタック情報との差分を比較し、その差分を記録したスタック差分情報５０３を生成するスタック差分情報生成手段４０２とを備える。尚、図１２に示す関数コール順取得手段４０４の構成は、一例であり、スタック情報取得手段４０１はなくてもよい。スタック情報取得手段４０１がない場合は、プログラムをシングルステップで動作させ、関数コールと任意で関数リターンをフックすればよい。第２の実施の形態では、この構成をとることによって、プログラムをシングルステップで動作させることなく、特定のイベント発生時に停止させる効率のよい関数コール順の把握を採用するものとする。尚、スタック情報取得手段４０１がある場合、スタック差分情報生成手段４０２はなくてもよい。スタック差分情報生成手段４０２がない場合、ソフトウェア動作監視装置４００は、プロセススタックの情報をもちいた関数コールの順序を把握する装置となる。スタック差分情報生成手段４０２を構成に含めることで、関数コールだけでなく関数リターンを含めた関数コール順を把握することができ、より詳細な動作を監視することができるので、第２の実施の形態では、この構成を採用するものとする。又、動作モデル６００は、システムコール番号と関数コール順との共起関係を示す相関情報２０６（例えばN-gramや相関規則）であるとする。この動作モデル６００には、任意でスタック情報、スタック差分情報を含めてもよい。スタック情報、スタック差分情報を含めることで、非特許文献１の手法のように、マッチングによる監視を行うことができる。相関情報２０６は統計情報であるため、この相関情報が学習によって得られたものであるとすると、学習済みの動作に対して、異常であると判断する可能性がある。非特許文献１の手法のようにマッチングを行うことによって、学習済みの動作に対する異常判断を完全に排除することができる。一方相関情報２０６は、未学習動作の判断を推定するために用いる。

図１３は、ソフトウェア動作監視装置４００の動作例を示すフローチャートである。ソフトウェア動作監視装置は、ソフトウェアの終了判定（ステップＳ４００）を経て、ソフトウェアが終了していなければ、スタック情報取得し（ステップＳ４０１）、スタック差分情報を生成し（ステップＳ４０２）、動作監視をする（ステップＳ４０３）。監視結果判定をし（ステップＳ４０４）、Errorと判定された場合は、Errorに応じた処理（ステップＳ４０５）をし、ステップＳ４００へ戻る。ステップＳ４０４にてErrorと判定されなかった場合は、ステップＳ４００へ戻る。ここでError処理とは、例えば、ソフトウェアの動作を終了する、メモリダンプを取るなどが挙げられるが、第２の実施の形態では、単に標準出力にErrorの種類を出力し、ソフトウェアの動作を終了するものとする。

図１４は、スタック情報取得手段４０１の動作例を示すフローチャートである。スタック情報取得手段４０１は、監視対象のソフトウェアが発行するシステムコールをフックし（ステップＳ５００）、その時点でのスタックを読み込み（ステップＳ５０１）、スタック情報を生成し、記録する（ステップＳ５０２）。スタック情報とは、システムコールが発生した時の、プロセススタックに詰まれたリターンアドレスの集合であり、スタックに詰まれた順序で並べられた情報である。Linuxにはptraceというデバッグツールがあるが、このツールを用いることにより、ソフトウェアをシステムコール発生ごとにとめることができ、かつその時点でのレジスタの値をみることができる。例えば、スタックポインタやスタックベースポインタが格納されるレジスタの値を見れば、それぞれが指し示すアドレスを取得することができる。スタックベースポインタの直後のアドレスには、リターンアドレスが詰まれているため、その値をピックアップすることで、スタック情報を得ることができる。

図１５は、スタック差分情報生成手段１０２の動作例を示すフローチャートである。スタック差分情報生成手段１０２は、スタック情報を順次読み込み（ステップＳ６００）、過去のスタック情報と現在のスタック情報の差分を比較し（ステップＳ６０１）、スタック差分情報を生成する（ステップＳ６０２）。図７は、スタック差分情報生成手段４０２に図４に示すスタック情報を入力した場合、スタック差分情報生成手段４０２によって生成されたスタック差分情報とシステムコール番号の例である。図４において、1行目と2行目を読み込み（ステップＳ６００）、差分を比較する（ステップＳ６０１）。比較する際、スタックの下から順に（すなわち、図４において左から）行っていく。1行3列目の0x80000345と、2行3列目の0x80000456、同じく4列目の 0x80000567が異なっていることがわかる。スタック差分情報を生成する（ステップＳ６０２）際、過去のスタック情報はスタックの上から（すなわち、図４において右から）変化のなくなる行までをその順に並べ替えて抽出（図４の1行目の場合、0x80000345のみとなる）し、記録する。現在のスタック情報は、スタックの下から始めて変化した箇所から、スタックの最上位までをその順で抽出（図４の2行目の場合、0x80000456、0x80000567となる）し、記録する。この記録の際、現在のシステムコール番号（図４の2行目の場合4）を合わせて記録する。結果、図７の2行目に表されるようなスタック差分情報が生成される。以下同様に、図４の2行目、3行目から、図７の3行目に表されるようなスタック差分情報が生成される。

動作モデル取得手段４０５は、監視対象のソフトウェアが発行した特定のイベントと、特定のイベントごとに、特定のイベント間で実行された関数コール順との共起関係を統計的に把握し、把握した共起関係を示した動作モデルを取得する。

図１６は、動作監視手段４０３の動作例を示すフローチャートである。動作監視手段４０３は、監視対象のソフトウェアに適した動作モデルをモデル記録から読み込む（ステップＳ７０１）。第２の実施の形態では、動作モデルとして、スタック差分情報から前例を抽出し、システムコール番号を結果とした相関規則をとるものとする。次に、得られた動作モデルを利用し、スタック差分情報生成手段４０２が生成したスタック差分情報が、相関規則にある前例とマッチするものがあるか否かを検証する（ステップＳ７０２）。例えばスタック差分情報上のリターンアドレスの全組み合わせに対して相関規則の前例とのマッチングを行うことでステップＳ７０２を実現できる。マッチしなければ、ER3（スタック差分エラー）を監視結果として出力する。マッチすれば、マッチした相関規則を利用して次のステップを実行する。次に、監視対象ソフトウェアが発行したシステムコールが、前例とのマッチが確認された相関規則の結果にマッチするか否かを検証する（ステップＳ７０３）。マッチする場合は、動作監視手段の処理を終了する。これは、前例と結果がマッチしたことを正常と判断するからである。ステップＳ７０３にてマッチしないと判定された場合は、前例とのマッチが確認された相関規則に記された信頼度をAnomaly Scoreに加算する（ステップＳ７０４）。信頼度の加算については、前例とのマッチが確認された相関規則に記された信頼度全てを加算することや、マッチしたリターンアドレス数が最も多かった相関規則に記された信頼度を加算することや「” The Zero-Frequency Problem: Estimating the Probabilities of Novel Events in Adaptive Text Compression”, Ian H. Wittenら著, IEEE Transactions on Information theory, vol. 37, No.4, JULY 1991」に記載のZero Frequencyを利用して新しいイベントが発生する確率の逆数を加算してもよい。Zero Frequencyは、学習時に得られた相関情報から、新しいイベントが発生する確率を推定するものであり、学習時に前例にマッチするトランザクション数nと、その前例の際におきた結果の種類数rを用い、novel event発生確率はr/nで近似できるというものである。この確率が動作モデルに含まれているとすると、もし、ステップＳ７０２、ステップＳ７０３の判定により、前例、結果にマッチしなかった場合、ステップＳ７０４において、novel event発生確率の逆n/rをAnomaly Scoreとして加算することになる。最後にこのAnomalyScoreが与えられた閾値を超えるか否かの判定を行う（ステップＳ７０５）。閾値を超えた場合は、ER4（相関規則エラー）を監視結果として出力する。閾値を超えなかった場合は、動作監視手段の処理を終了する。

図１７は、動作監視手段４０３の別の動作例を示すフローチャートである。動作監視手段４０３は、非特許文献１の手法を利用した監視手段であり、学習済みの動作を異常と判断することなく判定しながら、未学習動作の判断を統計的に推定することができる。

ステップＳ７０１で読み込む動作モデルには、システムコール番号とスタック情報とスタック差分情報と相関情報が含まれているとする。まず監視対象のソフトウェアが発行したシステムコールが、動作モデルに存在しているか否かを検証する（ステップＳ７０３）。システムコールはOSでも番号で識別されるため、その仕組みを利用して検証すればよい。存在していなければ、ER1（システムコールエラー）を監視結果として出力する。存在していれば、番号で識別されたシステムコールを発行したスタック情報の中に、監視対象のソフトウェアが発行したシステムコールの時点でのスタック情報（スタック情報取得手段４０１が取得したもの）と同一のものがあるか否かを検証する（ステップＳ７０７）。存在していなければ、ER2（スタックエラー）を監視結果として出力する。存在していれば、監視対象ソフトウェアが発行したシステムコールの時点で取得されたスタック情報から生成されたスタック差分情報（スタック差分情報生成手段が生成したもの）が、動作モデル内に存在しているか否かを検証する（ステップＳ７０８）。存在していれば、ソフトウェア動作は正常であると判断し、動作監視手段の処理を終了する。存在していなければ、ステップＳ７０２〜ステップＳ７０５を処理する。

尚、モデルが図９で示したようなFP-Tree構造で構築されており、かつ、F-Listがある場合、以下のように動作監視装置を構成してもよい。ここで、相関規則の木構造は、図１８に示すような表現がされているとする。

スタック情報取得手段４０１は、スタックにつまれたリターンアドレスを取得していく際（図１４のステップＳ５０１）に、F-Listにしたがって、各リターンアドレスにランク情報を付与する（図１９上部参照）。

スタック差分情報生成手段４０２は、スタック差分情報を生成した後に、リターンアドレスに付与したランク情報に従って、スタック差分情報上のリターンアドレスを昇順に並べ替える（図１９下部参照）。

動作監視手段４０３は、こうして得られたスタック差分情報を利用して、FP-Tree構造で構築されたモデル内をサーチする（図１６のステップＳ７０２）。FP-Tree構造は、頻度の高いアイテムがルートの近くに存在するよう構築された木であるため、スタック差分情報をF-Listに従って並べ替えることによって、幅優先探索が可能となる（図２０及び図２１参照）。又、木構造をとっているため、前例（スタック差分情報内のリターンアドレスの組み合わせ）と共起関係の強いシステムコールを効率よくサーチすることができる。又、モデルの葉の近くには頻度の小さいアイテムが配置されるため、幅優先探索を途中で省いても精度への影響が低い。又、頻度の高いアイテムがルートの近くに配置されるので、キャッシュ効率が高くなる。

（作用及び効果）
第２の実施の形態に係るソフトウェア監視装置及びソフトウェア監視方法によると、監視対象のソフトウェアが発行した特定のイベントと、特定のイベントごとに、特定のイベント間で実行された関数コールの発行順との共起関係を統計的に把握し、把握した共起関係を示した動作モデルを取得し、ソフトウェアの実行中に、ソフトウェアが実行した関数コールの発行順を取得もしくは推定し、関数コール順取得手段が取得した関数コールの発行順と特定のイベントとの共起関係と動作モデルとの乖離を判定することができる。このように構成することによって、統計的にソフトウェアの動作を検証することができるため、非特許文献１記載の攻撃検知システムではできなかった未学習動作の検証を行うことができ、誤り検出率を低減することができる。

又、第２の実施の形態に係るソフトウェア動作監視装置の関数コール順取得手段は、特定のイベントが発生した時点でのプロセススタックに詰まれたリターンアドレスをスタックに詰まれた順がわかるように取得し、特定のイベント発生順に記録し、記録した情報を関数コール順とするスタック情報取得手段を含む。

このように構成することによって、特定のイベントが発生した時点でプログラムを停止させ検証することができる。シングルステップで動作させる必要がなくなるため、検証速度があがる。

又、第２の実施の形態に係るソフトウェア動作監視装置の関数コール順取得手段は、iを自然数として、スタック情報取得手段によって取得されたi-1番目のスタック情報とi番目のスタック情報との差分情報を関数コールの発行順として生成するスタック差分情報生成手段を含む。

このように構成することによって、特定のイベントが発生した時点でプログラムを停止させるという手法の下で、関数コールの順序だけでなく、関数リターンの順序もあわせて動作検証することができる。

又、第２の実施の形態に係るソフトウェア動作監視装置の動作モデル取得手段が取得する動作モデルは、監視対象のソフトウェアが発行した特定のイベントと関数コール順との相関規則を示してもよい。

相関規則は共起関係を小さいデータ量で表すことが可能であるため、軽量なソフトウェア動作監視システムに有効なモデルを利用することができる。携帯電話など、記憶装置の容量が限られる端末に有効である。プログラムは論理的に構成されているため、関数コールの順序（あるいは文脈）はプログラムの動作をモデル化するうえで非常に重要な要素である。しかし、一般的に相関規則は順序を考慮しない。そこで、モデル生成手段が、共起関係を把握する際に、関数コールの順序（例えば、プロセススタックにリターンアドレスが詰まれた順序）を考慮して把握してもよい。このように構成することで、順序を考慮しない相関規則よりも詳細なモデルで監視を行うことができる。

又、第２の実施の形態に係るソフトウェア動作監視装置の動作モデル取得手段が取得するモデルは、関数コールの発行順に登録された関数コール識別子のうち、頻度の高いものを根ノードの近くに配置し、特定のイベントの識別子を葉ノードとするような木構造を構築した木構造情報と、関数コールの発行順に登録された関数コール識別子の頻度順情報が記されたモデルであって、関数コール順取得手段は、取得した関数コール順を頻度順情報に従って、並べ替え、動作監視手段は、並べ替えた関数コール順が、木構造情報に存在しているかどうかを探索する。

このため、前例と共起関係の強い結果（システムコールなど）を効率よくサーチすることができる。又、モデルの葉に近づくほど、頻度が小さいアイテムであるため、サーチを途中で省いたとしても精度への影響が低い。また、頻度の高いアイテムがルートの近くにあるので、キャッシュ効率が向上する。

又、第２の実施の形態に係るソフトウェア動作監視装置の動作監視手段は、監視対象のソフトウェアが発行した特定のイベントと関数コール順との共起関係と、動作モデルが示す相関規則との乖離を監視する際、相関規則が示す信頼度をパラメータとしたスコアを計測し、スコアが、あらかじめ定めた閾値を超えた場合を検知してもよい。

ここで、信頼度とは、前例がおきたときの結果がおきる確率、すなわち条件付確率である。信頼度を利用すると、例えば、相関規則に記載された前例と合致した動作が起きているにもかかわらず、同規則に記載された結果と非合致である確率を求めることができる。この非合致である確率は、異常動作が起きている確率とみなすこともできるため、異常動作を検知するスコアとして有効に働く。このように構成することによって、未学習動作の異常性を数値であらわすことができるため、閾値設定を行うことで利用シーンに適した検知精度を持つ攻撃検知システムを提供することができる。

＜第３の実施の形態＞
（ソフトウェア動作監視装置及びソフトウェア動作監視方法）
第３の実施の形態に係るソフトウェア動作監視装置１０００は、図２２に示すように、第２の実施の形態に係るソフトウェア動作監視装置４００に加え、モデル生成手段１０４０を備える。

モデル生成手段１０４０は、関数コール順と特定のイベントの共起関係を統計量として表したものをソフトウェアの動作モデル２０４として生成する。

関数コール順取得手段１０１０、動作監視手段１０５０、動作モデル取得手段１０６０について、第２の実施の形態と同様である機能については、ここでは説明を省略する。

ソフトウェア動作監視装置１０００は、ソフトウェア２００の動作を学習し、モデルを生成するモデル化状態と、モデルを利用してソフトウェアの動作を監視する監視状態に、その動作を分けることができる。モデル化状態時には、関数コール順取得手段１０１０と、モデル生成手段１０４０を動作させ、監視状態時には、関数コール順取得手段１０１０と動作監視手段１０５０を動作させる。又、関数コール順取得手段１０１０も、モデル化状態と監視状態がある。

関数コール順取得手段１０１０は、ソフトウェア２００がシステムコールなどを発行するたびに特定のイベント識別子（システムコールの場合、システムコール番号５０１）とその時点のスタック情報５０２を取得し、スタック情報５０２を生成するスタック情報取得手段１０２０と、システムコール番号５０１とスタック情報５０２を受け、過去と現在のスタック情報との差分を比較し、その差分を記録したスタック差分情報503を生成するスタック差分情報生成手段１０２０とで構成される。尚、関数コール順取得手段１０１０の構成は、一例であり、スタック情報取得手段１０２０はなくてもよい。関数コール順取得手段１０１０がない場合は、プログラムをシングルステップで動作させ、関数コールと任意で関数リターンをフックすればよい。第３の実施の形態では、この構成をとることによって、プログラムをシングルステップで動作させることなく、特定のイベント発生時に停止させる効率のよい関数コール順の把握を採用するものとする。尚、スタック情報取得手段１０２０がある場合、スタック差分情報生成手段１０２０はなくてもよい。スタック差分情報生成手段１０２０がない場合、ソフトウェア動作監視装置はプロセススタックの情報をもちいた関数コールの順序を把握する装置となる。スタック差分情報生成手段１０２０を構成に含めることで、関数コールだけでなく関数リターンを含めた関数コール順を把握することができ、より詳細な動作を監視することができるので、第３の実施の形態では、この構成を採用するものとする。

ここで、システムコール２０１は、スタック情報取得手段１０２０が取得する特定のイベントの例であり、システムコール以外にも、jmpやbranch命令、プロセッサ例外時などがあげられる。システムコールは、システム上重要な処理を行うための命令であるため、重要な監視ポイントである。本実施形態では、システムコールを特定のイベントとする。

モデル化状態時のスタック情報取得手段の動作例は、図３において説明した動作と同様である。又、モデル化状態時のスタック差分情報生成手段の動作例は、図６において説明した動作と同様である。又、監視状態時のソフトウェア動作監視装置の動作例は、図１３において説明した動作と同様である。又、監視状態時のスタック情報取得手段の動作例は、図１４において説明した動作と同様である。又、監視状態時のスタック差分情報生成手段の動作例は、図１５において説明した動作と同様である。

モデル生成手段１０４０は、モデル化状態時にのみ実行され、スタック差分情報５０３を受け、相関情報２０６をソフトウェア２００の動作モデル２０４としてモデル記録装置３００に記録する。

動作モデル２０４は、システムコール番号と関数コール順との共起関係を示す相関情報２０６（例えばN-gramや相関規則）であるとする。この動作モデル２０４には、任意でスタック情報、スタック差分情報を含めてもよい。スタック情報、スタック差分情報を含めることで、非特許文献１の手法のように、マッチングによる監視を行うことができる。相関情報２０６は統計情報であるため、この相関情報が学習によって得られたものであるとすると、学習済みの動作に対して、異常であると判断する可能性がある。非特許文献１の手法のようにマッチングを行うことによって、学習済みの動作に対する異常判断を完全に排除することができる。一方、相関情報２０６は未学習動作の判断を推定するために用いる。

モデル生成手段の動作例は、図１１において説明した動作と同様である。を示すフローチャートである。

動作監視手段１０５０は、監視状態時にのみ実行され、特定のイベントと、関数コール順を受け、ソフトウェア２００に対応した動作モデル２０４をモデル記録装置３００から更に受け、特定のイベントと関数コール順との共起関係と動作モデル２０４との乖離の有無を判定し、監視結果５０４を出力する。

動作監視手段の動作例は、図１６及び図１７において説明した動作と同様である。

（作用及び効果）
又、第３の実施の形態に係るソフトウェア動作監視装置は、関数コール順取得手段によって取得もしくは推定された関数コールの発行順と特定のイベントとの共起関係を統計的に把握し、把握した共起関係を当該ソフトウェアの動作モデルとして記録する、モデル生成手段を更に備える。

通常、プログラムの動作は動作環境に応じて異なる。例えば、LinuxやWindows（登録商標）のようなOS環境の違い、IA-32やARMのようなCPUの違いである。そこで、第３の実施の形態に係るソフトウェア動作監視装置のように装置を構成することによって、同一の動作環境でモデル化と監視を行うことができる。

第１の実施の形態に係るソフトウェア動作モデル化装置の構成ブロック図である。第１の実施の形態に係るスタック情報を説明する概念図である。第１の実施の形態に係るスタック情報取得手段の動作を示すフローチャートである。第１の実施の形態に係るスタック情報の一例である。第１の実施の形態に係るスタック差分情報を説明する概念図である。第１の実施の形態に係るスタック差分情報生成手段の動作を示すフローチャートである。第１の実施の形態に係るスタック差分情報の一例である。第１の実施の形態に係る相関規則のリストの一例である（その１）。第１及び第２の実施の形態に係るF-List及びFP-Tree構造の一例である。第１の実施の形態に係る相関規則のリストの一例である（その２）。第１の実施の形態に係るモデル生成手段の動作を示すフローチャートである。第２の実施の形態に係るソフトウェア動作監視装置の構成ブロック図である。第２の実施の形態に係るソフトウェア動作監視装置の動作を示すフローチャートである。第２の実施の形態に係るスタック情報取得手段の動作を示すフローチャートである。第２の実施の形態に係るスタック差分情報生成手段の動作を示すフローチャートである。第２の実施の形態に係る動作監視手段の動作を示すフローチャートである（その１）。第２の実施の形態に係る動作監視手段の動作を示すフローチャートである（その２）。第２の実施の形態に係る相関規則の木構造の一例である。第２の実施の形態に係るスタック情報及びスタック差分情報の一例である。第２の実施の形態に係るFP-Tree構造で構築されたモデル内のサーチ方法を説明する図である（その１）。第２の実施の形態に係るFP-Tree構造で構築されたモデル内のサーチ方法を説明する図である（その２）。第３の実施の形態に係るソフトウェア動作監視装置の構成ブロック図である。

符号の説明

１００…ソフトウェア動作モデル化装置
１０１…スタック情報取得手段
１０２…スタック差分情報生成手段
１０３…モデル生成手段
１０４…関数コール順取得手段
２００…ソフトウェア
２０１…システムコール
２０２…スタック情報
２０３…スタック差分情報
２０４…動作モデル
２０５…システムコール番号
２０６…相関情報
３００…モデル記録装置
３０４…動作モデル
４００…ソフトウェア動作監視装置
４０１…スタック情報取得手段
４０２…スタック差分情報生成手段
４０３…動作監視手段
４０４…関数コール順取得手段
４０５…動作モデル取得手段
５０１…システムコール番号
５０２…スタック情報
５０３…スタック差分情報
５０４…関数コール順
６００…動作モデル
１０００…ソフトウェア動作監視装置
１０１０…関数コール順取得手段
１０２０…スタック情報取得手段
１０３０…スタック差分情報生成手段
１０４０…モデル生成手段
１０５０…動作監視手段
１０６０…動作モデル取得手段

Claims

ソフトウェアの動作をモデル化するソフトウェア動作モデル化装置であって、
前記ソフトウェア動作モデル化装置は、
前記ソフトウェアの実行中に、特定のイベントごとに、特定のイベント間で実行されたシステムコールのシステムコール番号及びスタック情報を取得する関数コール順取得手段と、
前記関数コール順取得手段によって取得された前記システムコール番号、及び現在受け取ったスタック情報と、以前に受け取ったスタック情報との差分を表す情報であるスタック差分情報の共起関係を表す相関情報を当該ソフトウェアの動作モデルとして記録するモデル生成手段と
を備え、
前記相関情報は、トランザクションセットから、アイテム集合Ａが起きたときのアイテムＢの出現確率を求め、前記トランザクションセット全体でのルールとしたものであり、
前記モデル生成手段は、前記アイテム集合Ａを前例、前記アイテムＢを結果、前記出現確率を信頼度とし、前記スタック差分情報及び前記スタック差分情報に関連するシステムコール番号の組をトランザクションと見なし、前記スタック差分情報からシステムコールが発行する直前のN個の情報を抽出するとともに、最後のリターンアドレスを除外することにより、前例を抽出し、前記システムコール番号を結果とした相関規則を前記相関情報として生成することを特徴とするソフトウェア動作モデル化装置。
前記関数コール順取得手段は、関数コールだけでなく関数リターンを含めた関数コールの発行順もあわせて取得することを特徴とする請求項１に記載のソフトウェア動作モデル化装置。
前記関数コール順取得手段は、特定のイベントが発生した時点でのプロセススタックに詰まれたリターンアドレスをスタックに詰まれた順がわかるように取得し、特定のイベント発生順に記録し、記録した情報を前記関数コールの発行順とするスタック情報取得手段を含むことを特徴とする請求項１に記載のソフトウェア動作モデル化装置。
前記関数コール順取得手段は、iを自然数として、前記スタック情報取得手段によって取得されたi-1番目のスタック情報とi番目のスタック情報との差分情報を前記システムコールの発行順として生成するスタック差分情報生成手段を含むことを特徴とする請求項３に記載のソフトウェア動作モデル化装置。
前記モデル生成手段は、前記スタック情報あるいは前記差分情報の一部を使用して前記共起関係を取得することを特徴とする請求項３又は４に記載のソフトウェア動作モデル化装置。
前記モデル生成手段は、前記システムコールの発行順に登録されたシステムコール識別子のうち、頻度の高いものを根ノードの近くに配置し、特定のイベントの識別子を葉ノードとする木構造を構築した木構造情報を生成し、
前記木構造情報と、前記システムコールの発行順に登録されたシステムコール識別子の頻度順情報とをあわせて記録することにより、前記相関規則を生成することを特徴とする請求項１に記載のソフトウェア動作モデル化装置。
ソフトウェア動作モデル化装置が、ソフトウェアの実行中に、特定のイベントごとに、特定のイベント間で実行されたシステムコール番号と、スタック情報を取得するステップと、
前記ソフトウェア動作モデル化装置が、前記関数コール順取得手段によって取得された前記システムコール番号、及び現在受け取ったスタック情報と、以前に受け取ったスタック情報との差分を表す情報であるスタック差分情報の共起関係を表す相関情報を当該ソフトウェアの動作モデルとして記録するステップと
を備え、
前記相関情報は、トランザクションセットから、アイテム集合Ａが起きたときのアイテムＢの出現確率を求め、前記トランザクションセット全体でのルールとしたものであり、
前記記録するステップでは、前記アイテム集合Ａを前例、前記アイテムＢを結果、前記出現確率を信頼度とし、前記スタック差分情報及び前記スタック差分情報に関連するシステムコール番号の組をトランザクションと見なし、前記スタック差分情報からシステムコールが発行する直前のN個の情報を抽出するとともに、最後のリターンアドレスを除外することにより、前例を抽出し、前記システムコール番号を結果とした相関規則を前記相関情報として生成することを特徴とするソフトウェア動作モデル化方法。
ソフトウェアの動作を監視するソフトウェア動作監視装置であって、
前記ソフトウェア動作監視装置は、
監視対象のソフトウェアが発行した特定のイベントと、特定のイベントごとに、特定のイベント間で実行されたシステムコールのシステムコール番号、及び現在受け取ったスタック情報と、以前に受け取ったスタック情報との差分を表す情報であるスタック差分情報の共起関係を表す相関情報を当該ソフトウェアの動作モデルとして取得する動作モデル取得手段と、
前記ソフトウェアの実行中に、特定のイベントごとに、特定のイベント間で実行された前記システムコール番号及び前記スタック情報を取得し、取得した前記スタック情報に基づいて前記スタック差分情報を生成するスタック差分情報生成手段を含む関数コール順取得手段と、
生成された前記スタック差分情報が、相関規則にある前例とマッチするものがあるか否かを検証することによって、前記共起関係と前記動作モデルとの乖離を判定する動作監視手段と
を備え、
前記前例は、前記スタック差分情報からシステムコールが発行する直前のN個の情報を抽出するとともに、最後のリターンアドレスを除外したものであることを特徴とするソフトウェア動作監視装置。
前記関数コール順取得手段は、特定のイベントが発生した時点でのプロセススタックに詰まれたリターンアドレスをスタックに詰まれた順がわかるように取得し、特定のイベント発生順に記録し、記録した情報を前記システムコールの発行順とするスタック情報取得手段を含むことを特徴とする請求項８に記載のソフトウェア動作監視装置。
前記関数コール順取得手段は、iを自然数として、前記スタック情報取得手段によって取得されたi-1番目のスタック情報とi番目のスタック情報との差分情報を前記システムコールの発行順として生成するスタック差分情報生成手段を含むことを特徴とする請求項９に記載のソフトウェア動作監視装置。
前記動作モデル取得手段が取得する動作モデルは、監視対象のソフトウェアが発行した特定のイベントと前記システムコールの発行順との相関規則を示すことを特徴とする請求項８〜１０のいずれか１項に記載のソフトウェア動作監視装置。
前記動作モデル取得手段が取得するモデルは、前記システムコールの発行順に登録されたシステムコール識別子のうち、頻度の高いものを根ノードの近くに配置し、特定のイベントの識別子を葉ノードとするような木構造を構築した木構造情報と、前記システムコールの発行順に登録されたシステムコール識別子の頻度順情報が記されたモデルであって、
前記関数コール順取得手段は、取得したシステムコールの発行順を前記頻度順情報に従って並べ替え、
前記動作監視手段は、並べ替えた前記システムコール順が、木構造情報に存在しているかどうかを探索することを特徴とする請求項１１に記載のソフトウェア動作監視装置。
前記動作監視手段は、監視対象のソフトウェアが発行した特定のイベントと前記システムコールの発行順との共起関係と、前記動作モデルが示す相関規則との乖離を監視する際、
相関規則が示す信頼度をパラメータとしたスコアを計測し、
前記スコアが、あらかじめ定めた閾値を超えた場合を検知することを特徴とする請求項８〜１２のいずれか１項に記載のソフトウェア動作監視装置。
前記関数コール順取得手段によって取得された前記システムコール番号と、前記スタック情報とのスタック差分情報との共起関係を表す相関情報を当該ソフトウェアの動作モデルとして記録するモデル生成手段を更に備えることを特徴とする請求項８〜１３のいずれか１項に記載のソフトウェア動作監視装置。
ソフトウェア動作監視装置が、監視対象のソフトウェアが発行した特定のイベントと、特定のイベントごとに、特定のイベント間で実行されたシステムコール番号、及び現在受け取ったスタック情報と、以前に受け取ったスタック情報との差分を表す情報であるスタック差分情報の共起関係を表す相関情報を当該ソフトウェアの動作モデルとして取得するステップと、
前記ソフトウェア動作監視装置が、前記ソフトウェアの実行中に、特定のイベントごとに、特定のイベント間で実行された前記システムコール番号及び前記スタック情報を取得し、取得した前記スタック情報に基づいて前記スタック差分情報を生成するステップと、
前記ソフトウェア動作監視装置が、生成された前記スタック差分情報が、相関規則にある前例とマッチするものがあるか否かを検証することによって、前記共起関係と前記動作モデルとの乖離を判定するステップと
を含み、
前記前例は、前記スタック差分情報からシステムコールが発行する直前のN個の情報を抽出するとともに、最後のリターンアドレスを除外したものであることを特徴とするソフトウェア動作監視方法。