JP6903901B2

JP6903901B2 - 攻撃検知装置、攻撃検知プログラム及び攻撃検知方法

Info

Publication number: JP6903901B2
Application number: JP2016230520A
Authority: JP
Inventors: 和快古川; 武仲　正彦; 正彦武仲; 博崇小久保
Original assignee: Fujitsu Ltd
Current assignee: Fujitsu Ltd
Priority date: 2016-11-28
Filing date: 2016-11-28
Publication date: 2021-07-14
Anticipated expiration: 2036-11-28
Also published as: JP2018088094A; US20180150633A1; US10872147B2

Description

本発明は、情報処理装置における攻撃検知技術に関する。

例えばモバイルフォンに忍び込んだマルウエアは、ＯＳ（Operating System）の脆弱性を検証するためのツールを悪用することがある。当該ツールを用いれば、脆弱性を有するＯＳを使用しているモバイルフォンに対して標的型攻撃を仕掛けることができる。

一方、脆弱性を解消した修正プログラムをモバイルフォンにインストールすれば、係る攻撃を排除できる。但し、各モバイルフォンが、あらゆる脆弱性に対する修正プログラムを適用できているとは限らない。

従って、攻撃者は、様々な脆弱性に関する試行を繰り返して、攻撃の糸口を探す。

特開２０１１−１９８０２２号公報

本発明の目的は、一側面では、プログラムの脆弱性に着目した攻撃を検知し易くすることである。

一態様に係る攻撃検知装置は、（Ａ）脆弱性の対策処理が施されたプログラムにおいて当該対策処理が実行された場合に、当該対策処理の識別子を含む通知を受け付ける受付部と、（Ｂ）受け付けた上記通知に含まれる上記識別子に基づいて、攻撃の有無を判定する判定部とを有する。

一側面としては、プログラムの脆弱性に着目した攻撃を検知し易い。

図１は、端末装置のハードウエア構成例を示す図である。図２は、マルウエアによる攻撃の概要を示す図である。図３は、プログラムの処理フロー例を示す図である。図４は、マルウエアの処理フロー例を示す図である。図５は、マルウエアの処理フロー例を示す図である。図６は、従来技術における修正プログラムの処理フロー例を示す図である。図７は、本実施の形態における修正プログラムの処理フロー例を示す図である。図８Ａは、修正プログラムによる通知の概要を示す図である。図８Ｂは、監視部のモジュール構成例を示す図である。図９は、監視処理フローを示す図である。図１０は、ログテーブルの例を示す図である。図１１は、条件テーブルの例を示す図である。図１２は、警戒アクション部のモジュール構成例を示す図である。図１３は、実施の形態２における条件テーブルの例を示す図である。図１４は、実施の形態３における条件テーブルの例を示す図である。図１５は、実施の形態４における条件テーブルの例を示す図である。図１６は、実施の形態５における条件テーブルの例を示す図である。図１７は、レベルテーブルの例を示す図である。図１８は、実施の形態６における条件テーブルの例を示す図である。

［実施の形態１］
図１に、端末装置１００のハードウエア構成例を示す。端末装置１００は、プロセッサ１０１、記憶部１０３、アンテナ１１１、無線制御部１１３、オーディオ制御部１１５、スピーカ１１７、マイク１１９、ディスプレイ１２１、タッチセンサ１２３、カメラ１２５及びＧＰＳ（Global Positioning System）装置１２７を有している。

プロセッサ１０１は、モデムＣＰＵ（Central Processing Unit）とアプリケーションＣＰＵからなることもある。記憶部１０３は、例えば、ＲＯＭ（Read Only Memory）１０５とＲＡＭ（Random Access Memory）１０７とフラッシュメモリ１０９を有している。ＲＯＭ１０５は、例えば、予め設定されているデータやプログラムを格納している。ＲＡＭ１０７は、例えば、アプリケーションなどのプログラムやデータを展開する領域を含んでいる。フラッシュメモリ１０９は、例えば、ＯＳやアプリケーションなどのプログラムを格納しており、更に随時データを格納する。

タッチセンサ１２３は、例えば、ディスプレイ１２１の表示面上に配置されたパネル状のセンサであり、タッチ操作を受け付ける。ディスプレイ１２１は、例えば、アプリケーションが表示させる各種画面を表示する。具体的には、ディスプレイ１２１とタッチセンサ１２３とを一体としたタッチパネルとして用いられる。タッチセンサ１２３へのタッチ操作によって、タッチイベントが発生する。タッチセンサ１２３の他に、キーを設けるようにしてもよい。

アンテナ１１１は、例えばセルラー方式の無線データを受信する。無線制御部１１３は、無線通信の制御を行う。無線通信の制御により、電話の音声通信やデータ通信が行われる。

オーディオ制御部１１５は、音データに関するアナログ／デジタル変換とデジタル／アナログ変換を行う。スピーカ１１７は、アナログデータを音として出力する。マイク１１９は、音をアナログデータに変換する。

カメラ１２５は、動画や写真画像の撮影に用いられる。ＧＰＳ装置１２７は、位置を計測する。

図２に、マルウエアによる攻撃の概要を示す。この例で、ＯＳ層は、プログラム２０１ａ乃至プログラム２０１ｚを有するものとする。そして、プログラム２０１ａは、脆弱性Ａ及び脆弱性Ｂを有するものとする。また、プログラム２０１ｃは、脆弱性Ｃを有し、プログラム２０１ｄは、脆弱性Ｄを有するものとする。プログラム２０１ｅは、脆弱性Ｅを有し、プログラム２０１ｆは、脆弱性Ｆを有するものとする。プログラム２０１ｇは、脆弱性Ｇを有し、プログラム２０１ｈは、脆弱性Ｈを有するものとする。一方、プログラム２０１ｂ、及びプログラム２０１ｉ乃至プログラム２０１ｚは、いずれも脆弱性を有していないものとする。

図３を用いて脆弱性の例について説明する。関数ｆｕｎｃ＿ａは、プログラム２０１ａに相当する。関数ｆｕｎｃ＿ａは、引数ｐｔｒ、引数ｓｉｚｅ及び引数ｎに基づいて動作する。引数ｐｔｒは、文字列データの先頭アドレスである。引数ｓｉｚｅは、文字列データの長さである。引数ｎは、動作種別を表す。

Ｓ３０１のコードは、２５６バイトのバッファｂｕｆを確保することを示している。Ｓ３０３のコードは、先頭アドレスｐｔｒから始まる、長さｓｉｚｅの文字列データを、バッファｂｕｆに書き込むことを示している。

Ｓ３０５のコードは、動作種別ｎが１であるか否かを判定することを示している。動作種別ｎが１であると判定した場合には、Ｓ３０７の処理に移る。Ｓ３０７のコードは、変数ｇｌｏｂａｌ．ａ．ｔｅｘｔに、バッファｂｕｆに格納されている文字列データを設定することを示している。Ｓ３０９のコードは、変数ｇｌｏｂａｌ．ａ．ｔｅｘｔに設定された文字列データを文字列として出力することを示している。Ｓ３１１のコードは、戻り値ｐｔｒを返すことを示している。そして、関数ｆｕｎｃ＿ａの処理を終える。

一方、Ｓ３０５において動作種別ｎが１ではないと判定した場合には、Ｓ３１３の処理に移る。Ｓ３１３のコードは、動作種別ｎが２であるか否かを判定することを示している。動作種別ｎが２であると判定した場合には、Ｓ３１５の処理に移る。Ｓ３１５のコードは、変数ｇｌｏｂａｌ．ａ．ｔｅｘｔを解放することを示している。そして、Ｓ３１１の処理に移る。

Ｓ３１３において動作種別ｎが２ではないと判定した場合には、Ｓ３１７の処理に移る。Ｓ３１７のコードは、分岐に伴う処理を終えることを示している。そして、Ｓ３１１の処理に移る。

以下、この例における脆弱性について説明する。関数ｆｕｎｃ＿ａがコールされたときの引数ｓｉｚｅが２５６を超えている場合には、バッファｂｕｆにおいてオーバーフローが生じるかも知れない。その結果ＯＳにおける動作を不安定化させる恐れがある。この例では、この問題を脆弱性Ａと呼ぶ。

また、Ｓ３１５において解放された変数ｇｌｏｂａｌ．ａ．ｔｅｘｔの内容は、その後もメモリに保持されたままとなる。従って、他の関数から上記文字列データが読み取られる恐れがある。仮にセキュリティーコードが流出すれば、攻撃者による成り済ましが起こるかも知れない。この例では、この問題を脆弱性Ｂと呼ぶ。

脆弱性の態様は、脆弱性Ａ及び脆弱性Ｂの例に限らない。また、プログラム２０１が複数の関数を含んでいることもある。

図２の説明に戻る。この例で、アプリケーション層でマルウエアが動作しているものとする。マルウエアは、脆弱性に着目してプログラム２０１に異常な動作を行わせる。そのため、マルウエアは、脆弱性の検証に用いられるツールであるエクスプロイトを用いて試行を繰り返す。この例で、試行部２０３ａは、脆弱性Ａを検証するためのエクスプロイトＡを用いて脆弱性Ａに着目した異常な処理要求を行う。同様に、試行部２０３ｂ乃至試行部２０３ｈの各々は、脆弱性Ｂ乃至脆弱性Ｈの各々を検証するためのエクスプロイトを用いて当該脆弱性に着目した異常な処理要求を行う。処理要求は、例えばシステムコールである。

ここで、図４を用いて、マルウエアの処理例について説明する。このマルウエアは、ｒｏｏｔ権限を奪取して、ＯＳの管理データを改変することを目的としているものとする。

試行部２０３ａは、試行処理（Ａ）を実行する（Ｓ４０１）。試行処理（Ａ）では、脆弱性Ａに着目した異常な処理要求と通常の処理要求とを行い、ｒｏｏｔ権限の奪取を試みる。Ｓ４０３においてｒｏｏｔ権限の奪取が成功したと判定した場合には、マルウエアはＯＳの管理データを改変する（Ｓ４０５）。

一方、Ｓ４０３においてｒｏｏｔ権限の奪取が失敗したと判定した場合には、試行部２０３ｂは、試行処理（Ｂ）を実行し（Ｓ４０７）、試行部２０３ｃは、試行処理（Ｃ）を実行する（Ｓ４０９）。試行処理（Ｂ）では、脆弱性Ｂに着目した処理要求を行う。試行処理（Ｃ）では、試行処理（Ｂ）の結果を前提として、脆弱性Ｃに着目した処理要求を行い、ｒｏｏｔ権限の奪取を試みる。Ｓ４１１においてｒｏｏｔ権限の奪取が成功したと判定した場合には、マルウエアはＯＳの管理データを改変する（Ｓ４０５）。

一方、Ｓ４１１においてｒｏｏｔ権限の奪取が失敗したと判定した場合には、端子Ａを介して、図５に示したＳ５０１の処理に移る。

試行部２０３ｄは、試行処理（Ｄ）を実行し（Ｓ５０１）、試行部２０３ｅは、試行処理（Ｅ）を実行する（Ｓ５０３）。試行処理（Ｄ）では、脆弱性Ｄに着目した処理要求を行う。試行処理（Ｅ）では、脆弱性Ｅに着目した処理要求を行う。

続いて、試行部２０３ｆは、試行処理（Ｆ）を実行し（Ｓ５０５）、試行部２０３ｇは、試行処理（Ｇ）を実行する（Ｓ５０７）。試行処理（Ｆ）では、脆弱性Ｆに着目した処理要求を行う。試行処理（Ｇ）では、脆弱性Ｇに着目した処理要求を行う。

最後に、試行部２０３ｈは、試行処理（Ｈ）を実行する（Ｓ５０９）。試行処理（Ｈ）では、試行処理（Ｄ）乃至試行処理（Ｇ）の結果を前提として、脆弱性Ｈに着目した異常な処理要求を行い、ｒｏｏｔ権限の奪取を試みる。Ｓ５１１においてｒｏｏｔ権限の奪取が成功したと判定した場合には、マルウエアはＯＳの管理データを改変する（Ｓ５１３）。

一方、Ｓ５１１においてｒｏｏｔ権限の奪取が失敗したと判定した場合には、端子Ｂを介して、図４に示したＳ４０１の処理に戻って、上述した処理を繰り返す。

図４では、マルウエア自身において処理の流れを制御する例を示したが、マルウエアにおいて処理の流れを制御しない場合もある。例えば、攻撃者が操作する外部の装置からの指示によって処理の流れが制御される場合もある。

このように、マルウエアは種々の試行を繰り返すことが多い。試行を繰り返せば、残存する脆弱性を見つけ出して攻撃の糸口とすることができる。

一方、ＯＳの提供者がプログラム２０１における脆弱性を発見すると、脆弱性を解消するために修正されたプログラム（以下、修正プログラムという。）が作成される。修正プログラムは、パッチということもある。修正プログラムには、脆弱性に起因する誤動作や不正動作を防ぐための対策が施されている。

図６を用いて、従来技術における修正プログラムについて説明する。Ｓ６０１のコードは、引数ｓｉｚｅが２５６を超えているか否かを判定することを示している。引数ｓｉｚｅが２５６を超えていると判定した場合には、Ｓ６０３の処理に移る。Ｓ６０３のコードは、エラーを示す戻り値を返すことを示している。そして、関数ｆｕｎｃ＿ａの処理を終える。

このようにすれば、関数ｆｕｎｃ＿ａがコールされたときの引数ｓｉｚｅが２５６を超えている場合に、Ｓ３０１以降の処理を行わないので、バッファｂｕｆにおいてオーバーフローが生じる恐れはない。つまり、脆弱性Ａは解消される。Ｓ６０１及びＳ６０３は、脆弱性Ａに関する対策処理（以下、対策処理Ａという。）に相当する。

また、Ｓ３１５の処理の後に、Ｓ６０５の処理を行う。Ｓ６０５のコードは、変数ｇｌｏｂａｌ．ａ．ｔｅｘｔの内容をクリアすることを示している。

このようにすれば、変数ｇｌｏｂａｌ．ａ．ｔｅｘｔに設定された文字列データが他の関数から読み取られる恐れはない。つまり、脆弱性Ｂは解消される。Ｓ６０５は、脆弱性Ｂに関する対策処理（以下、対策処理Ｂという。）に相当する。

このような修正プログラムに置き換えることによって攻撃に対する防御がなされる。但し、従来技術において攻撃が仕掛けられていることを判別するようにはなっていない。

本実施の形態における修正プログラムでは、対策処理が実行されたことをＯＳ層の監視部に通知する。図７に、本実施の形態における修正プログラムの処理フロー例を示す。Ｓ６０１において引数ｓｉｚｅが２５６を超えていると判定した場合に、Ｓ６０３の処理に移る前に、Ｓ７０１の処理を実行する。Ｓ７０１において、関数ｆｕｎｃ＿ａは、対策処理Ａが実行されたことを示す通知を監視部に渡す。具体的には、対策処理Ａの識別子（ｃｏｄｅ＿ａ）が、当該通知に含まれている。

また、Ｓ６０５の処理の後に、Ｓ７０３の処理を実行する。Ｓ７０３において、関数ｆｕｎｃ＿ａは、対策処理Ｂが実行されたことを示す通知を監視部に渡す。具体的には、対策処理Ｂの識別子（ｃｏｄｅ＿ｂ）が、当該通知に含まれている。

図８Ａに、修正プログラム８０１による通知の概要を示す。この例では、プログラム２０１ａが修正プログラム８０１ａに置き換えられている。また、プログラム２０１ｃが修正プログラム８０１ｃに置き換えられている。その他のプログラム２０１は、図２の場合と同様である。

上述したように、修正プログラム８０１ａが、脆弱性Ａに着目した異常な処理要求に応じて対策処理Ａを実行した場合には、対策処理Ａの識別子（ｃｏｄｅ＿ａ）を含む通知を監視部８０２に渡す。修正プログラム８０１ａが、脆弱性Ｂに着目した処理要求に応じて対策処理Ｂを実行した場合には、対策処理Ｂの識別子（ｃｏｄｅ＿ｂ）を含む通知を監視部８０２に渡す。また、修正プログラム８０１ｃが、脆弱性Ｃに着目した処理要求に応じて、対策処理Ｃを実行した場合には、脆弱性Ｃに関する対策処理（以下、対策処理Ｃという。）の識別子（ｃｏｄｅ＿ｃ）含む通知を監視部８０２に渡す。

続いて、監視部８０２について説明する。図８Ｂに、監視部８０２のモジュール構成例を示す。監視部８０２は、受付部８０３、判定部８０５、警戒アクション部８０７、ログ記憶部８１１、条件記憶部８１３及びレベル記憶部８１５を有する。監視部８０２は、マルウエアによる攻撃が疑われる挙動を監視する。受付部８０３は、対策処理の実行通知を受け付ける。判定部８０５は、警戒の要否を判定する。例えば監視部８０２において、攻撃が有ったと判断すれば警戒する。監視部８０２において、攻撃が無かったと判断すれば警戒しない。警戒アクション部８０７は、判定部８０５における判定結果に応じて警戒アクションを行う。

ログ記憶部８１１は、ログテーブルを記憶する。ログテーブルについては、図１０を用いて後述する。条件記憶部８１３は、条件テーブルを記憶する。条件テーブルについては、図１１、図１３乃至図１６及び図１８を用いて後述する。レベル記憶部８１５は、レベルテーブルを記憶する。レベルテーブルについては、図１７を用いて後述する。

上述した監視部８０２、受付部８０３、判定部８０５及び警戒アクション部８０７は、ハードウエア資源（例えば、図１）と、以下で述べる処理をプロセッサ１０１に実行させるプログラムとを用いて実現される。

上述したログ記憶部８１１、条件記憶部８１３及びレベル記憶部８１５は、ハードウエア資源（例えば、図１）を用いて実現される。

続いて、監視部８０２における処理について説明する。図９に、監視処理フローを示す。受付部８０３は、いずれかの修正プログラム８０１から対策処理の実行通知を受け付ける（Ｓ９０１）。

判定部８０５は、通知元の修正プログラム８０１に対して処理を要求したプロセスの番号を特定する（Ｓ９０３）。判定部８０５は、日時と、実行通知に含まれる対策処理の識別子と、プロセス番号とをログテーブルに記録する（Ｓ９０５）。

図１０を用いて、ログテーブルの例について説明する。この例におけるログテーブルは、対策処理の実行通知に対応するレコードを有している。ログテーブルのレコードは、日時が格納されるフィールドと、対策処理の識別子が格納されるフィールドと、プロセス番号が格納されるフィールドとを有している。日時は、対策処理を実行した時点を特定する。

例えば１番目のレコードは、日時Ｔ１において、プロセス番号Ｐ１で特定されるプロセスによる要求に応じた処理が起動されて、識別子ｃｏｄｅ＿ａで特定される対策処理が実行されたことを示している。

図９の説明に戻る。本実施の形態では、Ｓ９０７を省くようにしてもよい。従って、Ｓ９０７については後述する。

判定部８０５は、条件テーブルにおけるレコードを１つ特定する（Ｓ９０９）。図１１を用いて、条件テーブルの例について説明する。この例における条件テーブルは、警戒条件に対応するレコードを有している。条件テーブルのレコードは、警戒条件が設定されるフィールドと、警戒アクションが設定されるフィールドとを有している。

警戒条件は、警戒すべき状況であることを判別するための条件である。本実施の形態における警戒条件は、１つの対策処理の識別子である。警戒アクションは、攻撃に対する警戒のために行われるアクションである。警戒条件を満たす場合に、当該警戒条件に対応する警戒アクションが行われる。

例えば１番目のレコードは、受け付けた対策処理の実行通知に含まれる対策処理の識別子がｃｏｄｅ＿ａである場合に、端末装置１００の電源をＯＦＦすることを示している。

同じく図示した２番目のレコードは、受け付けた対策処理の実行通知に含まれる対策処理の識別子がｃｏｄｅ＿ｂである場合に、当該対策処理が実行された際の処理要求元であるプロセスを削除することを示している。

同じく図示した３番目のレコードは、受け付けた対策処理の実行通知に含まれる対策処理の識別子がｃｏｄｅ＿ｃである場合に、当該対策処理が実行された際の処理要求元であるプロセスのソフトウエアをアンインストールすることを示している。

同じく図示した４番目のレコードは、受け付けた対策処理の実行通知に含まれる対策処理の識別子がｃｏｄｅ＿ｄである場合に、警告メッセージを表示することを示している。尚、条件テーブルの内容は、事前に設定されているものとする。

図９の説明に戻る。判定部８０５は、警戒条件に該当するか否かを判定する（Ｓ９１１）。本実施の形態では、Ｓ９０１において受け付けた対策処理の実行通知に含まれる対策処理の識別子がＳ９０９で特定されたレコードにおける警戒条件として設定されている対策処理の識別子と一致する場合に、判定部８０５は警戒条件に該当すると判定する。

警戒条件に該当すると判定した場合には、判定部８０５は、Ｓ９０９で特定されたレコードに設定されている警戒アクションを特定する（Ｓ９１３）。そして、警戒アクション部８０７は、当該警戒アクションを実行する（Ｓ９１５）。

ここで、警戒アクションについて説明する。図１２に、警戒アクション部８０７のモジュール構成例を示す。警戒アクション部８０７は、指示部１２０１及びソフトウェア特定部１２０３を有する。

例えば警戒アクションが「警告メッセージの表示」である場合には、指示部１２０１は、表示制御部１２１１へ警告メッセージの表示を指示する。表示制御部１２１１は、指示に従って、ディスプレイ１２１に警告メッセージを表示させる。

例えば警戒アクションが「電源ＯＦＦ」である場合には、指示部１２０１は、電源制御部１２１３へ電源のＯＦＦを指示する。電源制御部１２１３は、指示に従って電源を切る。

例えば警戒アクションが「プロセス削除」である場合には、指示部１２０１は、プロセス管理部１２１５へプロセス番号で特定されるプロセスの削除を指示する。プロセス管理部１２１５は、指示に従って、プロセス番号で特定されるプロセスを削除する。

例えば警戒アクションが「アンインストール」である場合には、ソフトウェア特定部１２０３は、プロセス番号に対応するソフトウエアを特定し、指示部１２０１は、ソフトウェア管理部１２１７へ当該ソフトウエアのアンインストールを指示する。ソフトウェア管理部１２１７は、指示に従って、ソフトウエアをアンインストールする。

上述した指示部１２０１、ソフトウェア特定部１２０３、表示制御部１２１１、電源制御部１２１３、プロセス管理部１２１５及びソフトウェア管理部１２１７は、ハードウエア資源（例えば、図１）と、以下で述べる処理をプロセッサ１０１に実行させるプログラムとを用いて実現される。

図９の説明に戻る。一方、Ｓ９１１において警戒条件に該当しないと判定した場合には、そのままＳ９１７の処理に移る。

判定部８０５は、未特定のレコードがあるか否かを判定する（Ｓ９１７）。未特定のレコードがあると判定した場合には、Ｓ９０９の処理に戻って、上述した処理を繰り返す。一方、未特定のレコードがないと判定した場合には、Ｓ９０１の処理に戻って、上述した処理を繰り返す。

本実施の形態によれば、プログラムの脆弱性に着目した攻撃を検知し易い。

［実施の形態２］
本実施の形態では、対策処理の識別子の組み合わせに基づいて、攻撃の有無を判定する例について説明する。

図１３に、実施の形態２における条件テーブルの例を示す。本実施の形態における警戒条件は、対策処理の識別子を複数含んでいる。これらの識別子で特定される対策処理が実行された場合には、警戒すべき状況であることを意味する。但し、対策処理が実行される順番は任意である。

例えば１番目のレコードは、最新の対策処理の実行通知に含まれる対策処理の識別子がｃｏｄｅ＿ｂ又はｃｏｄｅ＿ｃのいずれかであって、他方の識別子が過去の対策処理の実行通知に含まれている場合に、端末装置１００の電源をＯＦＦすることを示している。つまり、先にｃｏｄｅ＿ｂを含む通知を受け、その後にｃｏｄｅ＿ｃを含む通知を受けた場合に警戒条件が成立する。更に、先にｃｏｄｅ＿ｃを含む通知を受け、その後にｃｏｄｅ＿ｂを含む通知を受けた場合にも警戒条件が成立する。

ここでは、警戒条件が対策処理の識別子を２つ含む例を示したが、警戒条件が対策処理の識別子を３つ以上含むようにしてもよい。また、上述の実施の形態における警戒条件と本実施の形態における警戒条件とを併用するようにしてもよい。

本実施の形態において、図９に示したフローに沿って監視処理が実行される。但し、Ｓ９０５の処理に続いて、判定部８０５は、ログテーブルに基づいて過去の対策処理の識別子を特定する（Ｓ９０７）。判定部８０５は、Ｓ９０１で受け付けた通知に含まれる最新の対策処理の識別子から遡って過去の対策処理の識別子を特定する。判定部８０５は、例えば現在から所定時間遡った時点以降に実行された対策処理の識別子を特定する。判定部８０５は、端末装置１００が起動された以降に実行された対策処理の識別子を特定するようにしてもよい。判定部８０５は、最新の対策処理の識別子に係るプロセス番号と同じプロセス番号に対応する過去の対策処理の識別子を抽出するようにしてもよい。

Ｓ９１１において、判定部８０５は、最新の対策処理の識別子が警戒条件に含まれ、且つ警戒条件における当該識別子以外の識別子が、Ｓ９０７において特定された過去の対策処理の識別子のいずれかと一致する場合に、警戒条件に該当すると判定する。他の処理は、実施の形態１の場合と同様である。

本実施の形態によれば、複数の脆弱性に関する試行を組み合わせた攻撃を検知し易い。

［実施の形態３］
上述した実施の形態では、警戒条件において組み合わされる識別子の順序が任意である例について説明したが、本実施の形態では、識別子の順序が限定される例について説明する。

図１４に、実施の形態３における条件テーブルの例を示す。本実施の形態における警戒条件は、対策処理の識別子を複数含んでいる。設定されている順番通りに各対策処理が実行された場合には、警戒すべき状況であることを意味する。

例えば１番目のレコードは、最新の対策処理の実行通知に含まれる対策処理の識別子がｃｏｄｅ＿ｃであって、識別子ｃｏｄｅ＿ｂが過去の対策処理の実行通知に含まれている場合に、端末装置１００の電源をＯＦＦすることを示している。つまり、先にｃｏｄｅ＿ｂを含む通知を受け、その後にｃｏｄｅ＿ｃを含む通知を受けた場合に警戒条件が成立する。先にｃｏｄｅ＿ｃを含む通知を受け、その後にｃｏｄｅ＿ｂを含む通知を受けた場合には警戒条件が成立しない。

本実施の形態において、図９に示したフローに沿って監視処理が実行される。Ｓ９０７の処理は、実施の形態２の場合と同様である。

Ｓ９１１において、判定部８０５は、最新の対策処理の識別子が警戒条件に設定されている最後の識別子と一致し、且つ警戒条件における当該識別子以外の識別子が、その順番の通りに過去の対策処理の識別子に含まれる場合に、警戒条件に該当すると判定する。他の処理は、実施の形態１の場合と同様である。

本実施の形態によれば、脆弱性に関する試行の手順が想定される攻撃を検知し易い。

［実施の形態４］
本実施の形態では、対策処理の実行通知の数に基づいて、攻撃の有無を判定する例について説明する。

図１５に、実施の形態４における条件テーブルの例を示す。本実施の形態における警戒条件は、対策処理の実行通知の総数（以下、通知総数という。）に関する。通知総数が所定閾値を超える場合には、警戒すべき状況であることを意味する。

例えば１番目のレコードは、通知総数が１０以上である場合には、警戒アクションとしてアンインストールが行われることを示している。

例えば２番目のレコードは、通知総数が５以上且つ１０未満である場合には、警戒アクションとしてプロセス削除が行われることを示している。

例えば３番目のレコードは、通知総数が１以上且つ５未満である場合には、警戒アクションとして警告メッセージの表示が行われることを示している。

尚、上述の実施の形態における警戒条件と本実施の形態における警戒条件とを併用するようにしてもよい。

Ｓ９１１において、判定部８０５は、最新の対策処理の識別子と、Ｓ９０７で特定された過去の対策処理の識別子との延べ数を求める。この延べ数が通知総数に相当する。そして、通知総数が警戒条件に設定されている範囲に含まれる場合に、警戒条件に該当すると判定する。

本実施の形態によれば、脆弱性に関する試行の多寡に応じて警戒できる。

［実施の形態５］
本実施の形態では、同じプロセスからの要求を契機とした対策処理に関する実行通知の数（以下、同一プロセスに係る通知数という。）に基づく監視条件の例について説明する。

図１６に、実施の形態５における条件テーブルの例を示す。本実施の形態における警戒条件は、同一プロセスに係る通知数に関する。同一プロセスに係る通知数が所定閾値を超える場合には、警戒すべき状況であることを意味する。

例えば１番目のレコードは、同一プロセスに係る通知数が１０以上である場合には、警戒アクションとしてアンインストールが行われることを示している。

例えば２番目のレコードは、同一プロセスに係る通知数が５以上且つ１０未満である場合には、警戒アクションとしてプロセス削除が行われることを示している。

例えば３番目のレコードは、同一プロセスに係る通知数が１以上且つ５未満である場合には、警戒アクションとして警告メッセージの表示が行われることを示している。

Ｓ９１１において、判定部８０５は、Ｓ９０７で特定された過去の対策処理の識別子のうち、最新の対策処理の識別子と同じプロセス番号に対応付けられている識別子を数える。そして、その数に１を加えて、同一プロセスに係る通知数を求める。同一プロセスに係る通知数が警戒条件に設定されている範囲に含まれる場合に、警戒条件に該当すると判定する。

本実施の形態によれば、一つのプロセスにより複数の試行が行われる攻撃を判別し易い。

［実施の形態６］
本実施の形態では、対策処理に割り当てられている警戒レベルに基づいて警戒の要否を判定する例について説明する。

本実施の形態では、各対策処理に対して予め警戒レベルが設定されているものとする。図１７に、レベルテーブルの例を示す。この例におけるレベルテーブルは、対策処理に対応するレコードを有している。レベルテーブルのレコードは、対策処理の識別子が設定されるフィールドと、警戒レベルが格納されるフィールドとを有している。

例えば１番目のレコードは、識別子ｃｏｄｅ＿ａで特定される対策処理の実行に係る警戒のレベルが高いことを示している。例えば４番目のレコードは、識別子ｃｏｄｅ＿ｄで特定される対策処理の実行に係る警戒のレベルが低いことを示している。警戒のレベルは、３段階以上であってもよい。

図１８に、実施の形態６における条件テーブルの例を示す。本実施の形態における警戒条件は、同じ警戒レベルの対策処理の実行に関する通知数に関する。同じ警戒レベルの通知数が所定閾値を超える場合には、警戒すべき状況であることを意味する。

例えば１番目のレコードは、警戒レベルが高い通知の数が３以上である場合には、警戒アクションとして電源ＯＦＦが行われることを示している。

例えば２番目のレコードは、警戒レベルが低い通知の数が１０以上である場合には、警戒アクションとして警告メッセージの表示が行われることを示している。

Ｓ９１１において、判定部８０５は、Ｓ９０７で特定された過去の対策処理の識別子のうち、最新の対策処理と同じ警戒レベルに該当する過去の対策処理の識別子を数える。そして、その数に１を加えて、当該警戒レベルに係る通知数を算出する。判定部８０５は、警戒条件が当該警戒レベルの通知数に関し、且つ算出された通知数が警戒条件に設定されている範囲に含まれる場合に、当該警戒条件に該当すると判定する。

本実施の形態によれば、例えば過剰な警戒を避けられる。

以上本発明の実施の形態を説明したが、本発明はこれに限定されるものではない。例えば、上述の機能ブロック構成はプログラムモジュール構成に一致しない場合もある。

また、上で説明した各記憶領域の構成は一例であって、上記のような構成でなければならないわけではない。さらに、処理フローにおいても、処理結果が変わらなければ、処理の順番を入れ替えることや複数の処理を並列に実行させるようにしても良い。

以上述べた本発明の実施の形態をまとめると、以下のようになる。

本実施の形態に係る攻撃検知装置は、（Ａ）脆弱性の対策処理が施されたプログラムにおいて当該対策処理が実行された場合に、当該対策処理の識別子を含む通知を受け付ける受付部と、（Ｂ）受け付けた上記通知に含まれる上記識別子に基づいて、攻撃の有無を判定する判定部とを有する。

このようにすれば、プログラムの脆弱性に着目した攻撃を検知し易い。

更に、上記判定部は、上記識別子の組み合わせに基づいて、攻撃の有無を判定するようにしてもよい。

このようにすれば、複数の脆弱性に関する試行を組み合わせた攻撃を検知し易い。

更に、上記判定部は、順序付けされた上記識別子に基づいて、攻撃の有無を判定するようにしてもよい。

このようにすれば、脆弱性に関する試行の手順が想定される攻撃を検知し易い。

更に、上記判定部は、上記通知の数に基づいて、攻撃の有無を判定するようにしてもよい。

このようにすれば、脆弱性に関する試行の多寡に応じて警戒できる。

更に、上記判定部は、上記識別子に対応する警戒レベルに基づいて、攻撃の有無を判定するようにしてもよい。

このようにすれば、例えば過剰な警戒を避けられる。

更に、上記判定部は、同じプロセスの契機によって実行された対策処理の識別子を選別するようにしてもよい。

このようにすれば、一つのプロセスによる攻撃を判別し易い。

なお、上記方法による処理をプロセッサに行わせるためのプログラムを作成することができ、当該プログラムは、例えばフレキシブルディスク、ＣＤ−ＲＯＭ、光磁気ディスク、半導体メモリ、ハードディスク等のコンピュータ読み取り可能な記憶媒体又は記憶装置に格納されるようにしてもよい。尚、中間的な処理結果は、一般的にメインメモリ等の記憶装置に一時保管される。

以上の実施例を含む実施形態に関し、さらに以下の付記を開示する。

（付記１）
脆弱性の対策処理が施されたプログラムにおいて当該対策処理が実行された場合に、当該対策処理の識別子を含む通知を受け付ける受付部と、
受け付けた前記通知に含まれる前記識別子に基づいて、攻撃の有無を判定する判定部と
を有する攻撃検知装置。

（付記２）
前記判定部は、前記識別子の組み合わせに基づいて、前記攻撃の有無を判定する
付記１記載の攻撃検知装置。

（付記３）
前記判定部は、順序付けされた前記識別子に基づいて、前記攻撃の有無を判定する
付記１記載の攻撃検知装置。

（付記４）
前記判定部は、前記通知の数に基づいて、前記攻撃の有無を判定する
付記１記載の攻撃検知装置。

（付記５）
前記判定部は、前記識別子に対応する警戒レベルに基づいて、前記攻撃の有無を判定する
付記１記載の攻撃検知装置。

（付記６）
前記判定部は、同じプロセスの契機によって実行された前記対策処理の前記識別子を選別する
付記１乃至５のいずれか１つ記載の攻撃検知装置。

（付記７）
脆弱性の対策処理が施されたプログラムにおいて当該対策処理が実行された場合に、当該対策処理の識別子を含む通知を受け付け、
受け付けた前記通知に含まれる前記識別子に基づいて、攻撃の有無を判定する
処理をコンピュータに実行させる攻撃検知プログラム。

（付記８）
脆弱性の対策処理が施されたプログラムにおいて当該対策処理が実行された場合に、当該対策処理の識別子を含む通知を受け付け、
受け付けた前記通知に含まれる前記識別子に基づいて、攻撃の有無を判定する
処理を含み、コンピュータにより実行される攻撃検知方法。

１００端末装置２０１プログラム
２０３試行部８０１修正プログラム
８０２監視部８０３受付部
８０５判定部８０７警戒アクション部
８１１ログ記憶部８１３条件記憶部
８１５レベル記憶部１２０１指示部
１２０３ソフトウェア特定部１２１１表示制御部
１２１３電源制御部１２１５プロセス管理部
１２１７ソフトウェア管理部

Claims

内部で実行中のプロセスによる攻撃を検知する攻撃検知装置であって、
脆弱性の対策処理と当該対策処理が実行される場合に当該対策処理の識別子を含む通知を出力する出力処理とを実行するプログラムから、当該対策処理の識別子を含む通知を受け付ける受付部と、
前記通知に応じて、前記プログラムの実行を要求した、前記攻撃検知装置内部で実行中のプロセスを特定する特定部と、
受け付けた前記通知に含まれる前記識別子に基づいて、特定された前記プロセスによる攻撃の有無を判定する判定部と
を有する攻撃検知装置。
前記判定部は、前記識別子の組み合わせに基づいて、前記攻撃の有無を判定する
請求項１記載の攻撃検知装置。
前記判定部は、順序付けされた前記識別子に基づいて、前記攻撃の有無を判定する
請求項１記載の攻撃検知装置。
前記判定部は、前記通知の数に基づいて、前記攻撃の有無を判定する
請求項１記載の攻撃検知装置。
前記判定部は、前記識別子に対応する警戒レベルに基づいて、前記攻撃の有無を判定する
請求項１記載の攻撃検知装置。
前記判定部は、同じプロセスの契機によって実行された前記対策処理の前記識別子を選別する
請求項１乃至５のいずれか１つ記載の攻撃検知装置。
コンピュータ内部で実行中のプロセスによる攻撃を検知する攻撃検知プログラムであって、
脆弱性の対策処理と当該対策処理が実行される場合に当該対策処理の識別子を含む通知を出力する出力処理とを実行するプログラムから、当該対策処理の識別子を含む通知を受け付け、
前記通知に応じて、前記プログラムの実行を要求した、前記コンピュータ内部で実行中のプロセスを特定し、
受け付けた前記通知に含まれる前記識別子に基づいて、特定された前記プロセスによる攻撃の有無を判定する
処理をコンピュータに実行させる攻撃検知プログラム。
コンピュータ内部で実行中のプロセスによる攻撃を検知する攻撃検知方法であって、
脆弱性の対策処理と当該対策処理が実行される場合に当該対策処理の識別子を含む通知を出力する出力処理とを実行するプログラムから、当該対策処理の識別子を含む通知を受け付け、
前記通知に応じて、前記プログラムの実行を要求した、前記コンピュータ内部で実行中のプロセスを特定し、
受け付けた前記通知に含まれる前記識別子に基づいて、特定された前記プロセスによる攻撃の有無を判定する
処理を含み、コンピュータにより実行される攻撃検知方法。