JP6097849B2 - 情報処理装置、不正活動判定方法および不正活動判定用プログラム、並びに、情報処理装置、活動判定方法および活動判定用プログラム - Google Patents

Description

本発明は、ネットワークに接続された端末を管理する技術に関する。

従来、トラフィックを分析する方法として、ネットワーク上のホスト間のフローに懸念指標値を割り当て、累積された懸念指標値が閾値を超えた場合にアラームを発する方法が提案されている（特許文献１および２を参照）。

また、トラフィックを分析することで、所謂ドライブバイダウンロード（Ｄｒｉｖｅ−ｂｙ Ｄｏｗｎｌｏａｄ）攻撃を検出する方法が種々提案されている（非特許文献１および２を参照）。

米国特許第７４７５４２６号明細書 米国特許第７１８５３６８号明細書

進藤 康孝、外３名、"マルウェア感染ステップのファイルタイプ遷移に基づいたＤｒｉｖｅ−ｂｙ Ｄｏｗｎｌｏａｄ攻撃検知手法"、［ｏｎｌｉｎｅ］、平成２６年１０月１５日、情報処理学会、［平成２６年１２月１５日検索］、インターネット〈ＵＲＬ：ｈｔｔｐｓ：／／ｉｐｓｊ．ｉｘｓｑ．ｎｉｉ．ａｃ．ｊｐ／ｅｊ／？ａｃｔｉｏｎ＝ｐａｇｅｓ＿ｖｉｅｗ＿ｍａｉｎ＆ａｃｔｉｖｅ＿ａｃｔｉｏｎ＝ｒｅｐｏｓｉｔｏｒｙ＿ｖｉｅｗ＿ｍａｉｎ＿ｉｔｅｍ＿ｄｅｔａｉｌ＆ｉｔｅｍ＿ｉｄ＝１０６５９８＆ｉｔｅｍ＿ｎｏ＝１＆ｐａｇｅ＿ｉｄ＝１３＆ｂｌｏｃｋ＿ｉｄ＝８〉 松中 隆志、外２名、"Ｄｒｉｖｅ−ｂｙ Ｄｏｗｎｌｏａｄ攻撃対策フレームワークにおけるＷｅｂアクセスログを用いたＷｅｂリンク構造の解析による悪性サイト検出手法の提案"、［ｏｎｌｉｎｅ］、平成２６年１０月１５日、情報処理学会、［平成２６年１２月１５日検索］、インターネット〈ＵＲＬ：ｈｔｔｐｓ：／／ｉｐｓｊ．ｉｘｓｑ．ｎｉｉ．ａｃ．ｊｐ／ｅｊ／？ａｃｔｉｏｎ＝ｐａｇｅｓ＿ｖｉｅｗ＿ｍａｉｎ＆ａｃｔｉｖｅ＿ａｃｔｉｏｎ＝ｒｅｐｏｓｉｔｏｒｙ＿ｖｉｅｗ＿ｍａｉｎ＿ｉｔｅｍ＿ｄｅｔａｉｌ＆ｉｔｅｍ＿ｉｄ＝１０６５９６＆ｉｔｅｍ＿ｎｏ＝１＆ｐａｇｅ＿ｉｄ＝１３＆ｂｌｏｃｋ＿ｉｄ＝８〉

従来、マルウェア感染の検知を行うための技術として、指標値を累積していき、累積値が閾値を超えた場合に、マルウェアに感染していると判定する方法がある。しかし、このような方法では、指標値を定期的にクリアしなければ軽微な値の蓄積によっても累積値が閾値を超えてしまい、正常な端末を、マルウェアに感染していると誤検知してしまう虞がある。また、指標値を定期的にクリアする場合にも、クリアするタイミングによってはマルウェアを見逃してしまう虞がある。

本開示は、上記した問題に鑑み、マルウェア感染の誤検知または見逃しを低減させることを課題とする。

本開示の一例は、ネットワークに接続された端末による通信と予め保持されたパターンとを比較する比較手段と、前記比較の結果に従って、前記端末が不正な活動をしていると推測される程度を示す評価値と不正な活動のフェーズとを決定する決定手段と、前記端末毎に、前記評価値の前記フェーズ毎の最大値を保持する保持手段と、前記評価値の前記フェーズ毎の最大値に基づいて、前記端末が不正な活動を行っているか否かを判定する判定手段と、を備える情報処理装置である。

本開示は、情報処理装置、システム、コンピューターによって実行される方法またはコンピューターに実行させるプログラムとして把握することが可能である。また、本開示は、そのようなプログラムをコンピューターその他の装置、機械等が読み取り可能な記録媒体に記録したものとしても把握できる。ここで、コンピューター等が読み取り可能な記録媒体とは、データやプログラム等の情報を電気的、磁気的、光学的、機械的または化学的作用によって蓄積し、コンピューター等から読み取ることができる記録媒体をいう。

本開示によれば、マルウェア感染の誤検知または見逃しを低減させることが可能となる。

実施形態に係るシステムの構成を示す概略図である。 実施形態に係るネットワーク監視装置および管理サーバーのハードウェア構成を示す図である。 実施形態に係るネットワーク監視装置の機能構成の概略を示す図である。 実施形態のマルウェアふるまい検知エンジンによって用いられる、マルウェアの活動遷移モデルを示す図である。 実施形態に係る、パケット毎の検知処理の流れの概要を示すフローチャートである。 実施形態に係る、マルウェアふるまい検知エンジンによる検知処理の流れを示すフローチャート（Ａ）である。 実施形態に係る、マルウェアふるまい検知エンジンによる検知処理の流れを示すフローチャート（Ｂ）である。 実施形態に係る、マルウェアふるまい検知エンジンによる検知処理の流れを示すフローチャート（Ｃ）である。 実施形態における第一の相関分析で監視対象とする活動遷移モデル上のフェーズとその遷移を示す図である。 実施形態における第二の相関分析で監視対象とする、探索フェーズへの遷移を示す図である。 実施形態における第二の相関分析で監視対象とする、実行ファイルのダウンロードフェーズへの遷移を示す図である。 実施形態における、侵入フェーズに係る通信と実行ファイルのダウンロードフェーズに係る通信との相関性を判定するための相関分析処理の流れを示すフローチャートである。 実施形態における第二の相関分析で監視対象とする、Ｃ＆Ｃ検索フェーズへの遷移を示す図である。 実施形態における第二の相関分析で監視対象とする、Ｃ＆Ｃ通信フェーズへの遷移を示す図である。 実施形態における第二の相関分析で監視対象とする、攻撃フェーズへの遷移を示す図である。 実施形態に係る、コンテンツリクエスト解析処理の流れを示すフローチャートである。 実施形態に係る、コンテンツレスポンス解析処理の流れを示すフローチャートである。 実施形態に係る、ＨＴＭＬコンテンツレスポンス解析処理の流れを示すフローチャートである。 実施形態に係る、実行ファイルリクエスト解析処理の流れを示すフローチャートである。 実施形態に係る、実行ファイルレスポンス解析処理の流れを示すフローチャートである。 実施形態に係るシステムの構成のバリエーションを示す概略図である。

以下、本開示に係る情報処理装置、方法およびプログラムの実施の形態を、図面に基づいて説明する。但し、以下に説明する実施の形態は、実施形態を例示するものであって、本開示に係る情報処理装置、方法およびプログラムを以下に説明する具体的構成に限定するものではない。実施にあたっては、実施形態に応じた具体的構成が適宜採用され、また、種々の改良や変形が行われてよい。

本実施形態では、本開示に係る情報処理装置、方法およびプログラムを、ネットワーク上で不正な活動を行っている端末を発見し、通信遮断やアラート通知等の対処を行うためのシステムにおいて実施した場合の実施の形態について説明する。但し、本開示に係る情報処理装置、方法およびプログラムは、ネットワーク上の不正な活動を検知するための技術について広く用いることが可能であり、本開示の適用対象は、本実施形態において示した例に限定されない。

＜システムの構成＞
図１は、本実施形態に係るシステム１の構成を示す概略図である。本実施形態に係るシステム１は、複数の情報処理端末９０（以下、「ノード９０」と称する）が接続されるネットワークセグメント２と、ノード９０に係る通信を監視するためのネットワーク監視装置２０と、を備える。更に、管理サーバー５０が、ルータ１０を介してネットワークセグメント２と通信可能に接続されている。本実施形態において、ネットワーク監視装置２０は、スイッチまたはルータ（図１に示した例では、ルータ）のモニタリングポート（ミラーポート）に接続されることで、ノード９０によって送受信されるパケットやフレーム等を取得する。この場合、ネットワーク監視装置２０は、取得したパケットを転送しないパッシブモードで動作する。

管理サーバー５０は、ネットワーク監視装置２０から情報を収集し、ネットワーク監視装置２０を管理する。なお、外部ネットワークには、更に検疫サーバーが設けられ、ネットワークセグメント２に接続されたノード９０に対して検疫サービスを提供してもよいし、業務サーバーが設けられ、ノード９０に対して業務のためのサービスを提供してもよい（図示は省略する）。

本実施形態に係るシステム１では、ノード９０から接続される各種サーバーは、インターネットや広域ネットワークを介して遠隔地において接続されたものであり、例えばＡＳＰ（Ａｐｐｌｉｃａｔｉｏｎ Ｓｅｒｖｉｃｅ Ｐｒｏｖｉｄｅｒ）によって提供されるが、これらのサーバーは、必ずしも遠隔地に接続されたものである必要はない。例えば、これらのサーバーは、ノード９０やネットワーク監視装置２０が存在するローカルネットワーク上に接続されていてもよい。

図２は、本実施形態に係るネットワーク監視装置２０および管理サーバー５０のハードウェア構成を示す図である。なお、図２においては、ネットワーク監視装置２０および管理サーバー５０以外の構成（ルータ１０、ノード９０等）については、図示を省略している。ネットワーク監視装置２０および管理サーバー５０は、それぞれ、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）１１ａ、１１ｂ、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）１３ａ、１３ｂ、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）１２ａ、１２ｂ、ＥＥＰＲＯＭ（Ｅｌｅｃｔｒｉｃａｌｌｙ Ｅｒａｓａｂｌｅ ａｎｄ Ｐｒｏｇｒａｍｍａｂｌｅ Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）やＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）等の記憶装置１４ａ、１４ｂ、ＮＩＣ（Ｎｅｔｗｏｒｋ Ｉｎｔｅｒｆａｃｅ Ｃａｒｄ）１５ａ、１５ｂ等の通信ユニット、等を備えるコンピューターである。

図３は、本実施形態に係るネットワーク監視装置２０の機能構成の概略を示す図である。なお、図３においては、ネットワーク監視装置２０以外の構成（ルータ１０、ノード９０および管理サーバー５０等）については、図示を省略している。ネットワーク監視装置２０は、記憶装置１４ａに記録されているプログラムが、ＲＡＭ１３ａに読み出され、ＣＰＵ１１ａによって実行されることで、通信取得部２１、通信遮断部２２、アプリケーション検知エンジン２３、プロトコルアノマリ検知エンジン２４およびマルウェアふるまい検知エンジン２５を備える情報処理装置として機能する。また、マルウェアふるまい検知エンジン２５は、比較部２５１、評価値取得部２５２、補正部２５３、決定部２５４、保持部２５５、合計部２５６、判定部２５７および相関分析部２５８を含む。なお、本実施形態では、ネットワーク監視装置２０の備える各機能は、汎用プロセッサであるＣＰＵ１１ａによって実行されるが、これらの機能の一部または全部は、１または複数の専用プロセッサによって実行されてもよい。また、これらの機能の一部または全部は、クラウド技術等を用いて、遠隔値に設置された装置や、分散設置された複数の装置によって実行されてもよい。

通信取得部２１は、ネットワークに接続された端末によって送受信される通信を取得する。なお、本実施形態において、ネットワーク監視装置２０による監視および検知の対象となる「端末」には、ネットワークセグメント２に接続されたノード９０の他、ノード９０とルータ１０を介して通信するその他の装置（他のネットワークに属するノードや外部サーバー等）を含む。

通信遮断部２２は、アプリケーション検知エンジン２３、プロトコルアノマリ検知エンジン２４またはマルウェアふるまい検知エンジン２５によって、端末が不正な活動を行っていると判定された場合に、当該端末による通信を遮断する。なお、本実施形態では、端末が不正な活動を行っていると判定された場合、当該端末の通信を遮断する対処が採られる例について説明しているが、端末が不正な活動を行っていると判定された場合の対処方法は、通信の遮断に限定されない。ネットワーク監視装置２０は、端末が不正な活動を行っていると判定された場合に、アラート（警告）の通知を行ってもよいし、不正な活動を行っている端末の治癒（例えば、マルウェアの除去や脆弱性の除去）を行ってもよい。

アプリケーション検知エンジン２３は、マルウェアが利用する、業務に不要なアプリケーションがネットワーク上で通信を行っていることを検知するエンジンであり、例えば、既知のＲＡＴ（Ｒｅｍｏｔｅ Ａｃｃｅｓｓ Ｔｒｏｊａｎ）、Ｐ２Ｐ（Ｐｅｅｒ ｔｏ Ｐｅｅｒ）アプリケーション、Ｔｏｒ（Ｔｈｅ Ｏｎｉｏｎ Ｒｏｕｔｅｒ）、ＵｌｔｒａＳｕｒｆ（Ｐｒｏｘｙツール）および匿名プロキシ等による通信を検知することで、ノード９０において業務に不要なアプリケーションが動作していることを検知する。

プロトコルアノマリ検知エンジン２４は、ネットワーク上における、プロトコルに沿っていない通信を検知するエンジンであり、例えば、ＨＴＴＰアノマリ検知エンジン、ＳＳＬ／ＴＬＳアノマリ検知エンジンおよびＤＮＳアノマリ検知エンジン等が含まれる。プロトコルアノマリ検知エンジン２４は、これらのプロトコルに沿っていない通信を検知することで、ネットワーク上でプロトコルを遵守していない通信を行うノード９０を検知する。

マルウェアふるまい検知エンジン２５は、マルウェアの活動遷移モデルに定義された、マルウェアによる不正な活動のフェーズごとに、ネットワーク上の通信と「マルウェア特有の通信パターン」との共通性を評価し、マルウェアの活動フェーズの遷移状況を監視することでマルウェアのふるまい（挙動）を分析し、ノード９０におけるマルウェア感染を検知するエンジンである。

図４は、本実施形態のマルウェアふるまい検知エンジン２５によって用いられる、マルウェアの活動遷移モデルを示す図である。なお、本実施形態において示されるマルウェアの活動遷移モデルにはフェーズＰ１からフェーズＰ８が定義されているが、これは本実施形態において用いられる一例であり、マルウェアの活動遷移モデルは、実施の形態に応じて、適宜変更されてよい。以下、本実施形態に係るマルウェアの活動遷移モデルにおける各フェーズについて説明する。

フェーズＰ１は、侵入フェーズ、即ち、標的型攻撃メールの添付ファイル、メールのＵＲＬのクリック、Ｗｅｂサイト（主に、ＳＮＳサイト）上のＵＲＬのクリック等を契機に、ＯＳやアプリケーションの脆弱性を利用して感染する悪性コンテンツ（悪性コード、攻撃コード、エクスプロイト等とも称される）が投下されるフェーズである。フェーズＰ１からの移行先は、ワーム等の自律型のマルウェアが侵入した場合、フェーズＰ２、フェーズＰ４またはフェーズＰ８であり、ボット系のマルウェアの場合、フェーズＰ２またはフェーズＰ４である。

フェーズＰ２は、探索フェーズ、即ち、脆弱性を持った感染端末の探索フェーズである。

フェーズＰ３は、感染・浸潤フェーズ（拡散フェーズ）、即ち、脆弱な標的に対して攻撃コードを送り込んで感染させるかまたは他の端末から攻撃コードが送り込まれて感染させられるフェーズである。感染・浸潤フェーズでは、既に感染している端末を介して攻撃コードが標的の端末に送り込まれ、攻撃コードが送り込まれた端末がマルウェアに感染する。例えば、Ｗｉｎｄｏｗｓ（登録商標） ＯＳのＭＳ−ＲＰＣやファイル共有の脆弱性を利用して拡散活動が行われる。ボット系のマルウェアの場合は、攻撃者（ハーダー）から発行される、Ｃ＆Ｃ（Ｃｏｍｍａｎｄ ａｎｄ Ｃｏｎｔｒｏｌ）サーバーを経由した指令（フェーズＰ６）に基づいて感染活動（マルウェアの拡散活動）が実行される。フェーズＰ３からの移行先は、ワーム等の自律型のマルウェアの場合、フェーズＰ４またはフェーズＰ８であり、ボット系のマルウェアの場合、フェーズＰ４である。感染・浸潤フェーズは、２つの側面を持つ。１つは、感染元端末が感染活動を実行するフェーズである。もう１つは、被害者（感染先）端末として、攻撃コードが送り込まれ感染させられるフェーズである。

フェーズＰ４は、実行ファイルのダウンロードフェーズ、即ち、攻撃コードが送り込まれたのち、マルウェアの配布サイトや既に感染している端末から、マルウェア本体である実行ファイルをダウンロードして活性化、またはアンチウィルス製品によるマルウェアの検出の回避や新しい機能の追加等の目的で、攻撃者からの指令（Ｃ＆Ｃサーバー経由）に従って、指定されたサイトから、新しいマルウェアがダウンロードされるフェーズである。マルウェア本体のダウンロードには、主に、ＨＴＴＰ、ＦＴＰ、ＴＦＴＰが使用される。また、マルウェア独自のプロトコルを利用する場合もある。フェーズＰ４からの移行先は、ボット等の遠隔操作タイプのマルウェアの場合、フェーズＰ５またはＰ６であり、ワーム等の自律型のマルウェアの場合、通常、フェーズＰ２またはフェーズＰ８である。

フェーズＰ５は、Ｃ＆Ｃ検索フェーズ、即ち、攻撃者からの指令を受け取るためのＣ＆Ｃサーバーを検索するフェーズである。このフェーズに遷移するマルウェアは、主に、ボット等の遠隔操作タイプのマルウェアである。マルウェアには、通常、複数のＣ＆ＣサーバーのＦＱＤＮが組み込まれており、ＤＮＳクエリを使用してアドレス解決を行う。Ｐ２Ｐタイプのボットネットの場合は、Ｐ２Ｐプロトコル（汎用または独自プロトコル）を使用してＣ＆Ｃノードを検索する。ＩＰアドレスがハードコーディングされているタイプのマルウェアは、このフェーズでは活動しない。フェーズＰ５からの移行先は、フェーズＰ６である。

フェーズＰ６は、Ｃ＆Ｃ通信（含む、インターネット接続確認）フェーズ、即ち、攻撃者からの指令の受信と指令の実行結果の報告（応答）等を行うために、Ｃ＆Ｃサーバーに接続してデータの送受信を行うフェーズである。Ｃ＆Ｃサーバーに接続する前に、インターネット接続確認を行うマルウェアが存在する。Ｃ＆Ｃサーバーとの接続には、フェーズＰ５でアドレス解決が成功したＩＰアドレスの何れか、またはマルウェアにハードコーディングされたＩＰアドレスの何れかが使用される。マルウェアの活動は、Ｃ＆Ｃサーバーから指令を受信すると、攻撃者からの指令に従って、フェーズＰ６からフェーズＰ２、フェーズＰ４またはフェーズＰ８に移行する。実行結果は、Ｃ＆Ｃサーバー経由で攻撃者に通知される。一方、マルウェアは、Ｃ＆Ｃサーバーへの接続に失敗した場合、別のＩＰアドレスで接続を再試行し、それでも失敗した場合には、フェーズＰ５に戻って別のＣ＆Ｃサーバーを検索するか、活動自体を停止する。なお、接続が成功するまで延々と再接続を繰り返すマルウェアの存在も報告されている。また、Ｃ＆Ｃ通信パスに異常が発生し、リカバリできない場合、マルウェアの活動はフェーズＰ５に移行する。更に、一定期間でＣ＆Ｃサーバーを変更する動作を行うマルウェアも存在し、この場合も、マルウェアの活動はフェーズＰ５に移行する。また、フェーズＰ６は、攻撃者からの指令を待ち合わせているフェーズを含む。マルウェアは、定期的にＣ＆Ｃサーバーにアクセスして、通信パスを維持するとともに、攻撃者からの指令を待ち受ける。一定期間でＣ＆Ｃサーバーを変更する動作を行うマルウェアも存在し、この場合も、マルウェアの活動はフェーズＰ５に移行する。

フェーズＰ７は、搾取情報のアップロードフェーズ、即ち、マルウェア等が活動することによって得られた情報が、攻撃者側のサーバー等にアップロードされるフェーズである。

フェーズＰ８は、攻撃活動フェーズ、即ち、攻撃者からの指令（ボット系）やマルウェア自体に組み込まれた攻撃コード（ワーム系）に従って、各種攻撃活動を行うフェーズである。攻撃標的を見つけるために、フェーズＰ１相当の活動が行われることもある。攻撃活動には、ＤｏＳ攻撃、スパムメール攻撃、Ｗｅｂ攻撃（Ｗｅｂ改ざん）、踏み台等が含まれる。

マルウェアふるまい検知エンジン２５は、比較部２５１、評価値取得部２５２、補正部２５３、決定部２５４、保持部２５５、合計部２５６、判定部２５７および相関分析部２５８を有することで（図３を参照）、上記のように定義されたマルウェアの活動フェーズの遷移状況を監視し、ノード９０におけるマルウェア感染を検知する。以下、マルウェアふるまい検知エンジン２５が有する各機能部について説明する。

比較部２５１は、通信取得部２１によって新たに取得された通信（本実施形態では、新たに取得されて処理の対象となったパケット。以下「入力パケット」と称する）と、予め保持された通信パターンと、を比較する。通信パターンには、マルウェアの様々な活動の結果として現れる特異な通信パターンが、予め定義されている。本実施形態において、通信パターンは、マルウェアの活動遷移モデルのフェーズ毎に予め複数定義され、ネットワーク監視装置２０または管理サーバーによって保持されており、フェーズＰｎ（ここで、ｎは１から７までの整数）の通信パターンは、「Ｐｎ−ｍ」（ここで、ｍは１以上の数値）のように表される。但し、何れのフェーズにも依存しない（換言すれば、複数の異なるフェーズにおいて出現し得る）通信パターンも存在する。本実施形態において、フェーズＰ１からフェーズＰ８の何れにも依存しない通信パターンは、「Ｐ０−ｍ」で表される。

評価値取得部２５２は、比較部２５１による比較の結果、入力パケットと一致または近似した（以下、単に「対応する」と称する）通信パターンについて予め設定されているグレード（評価値）を、入力パケットのグレードとして取得する。グレード（Ｇｒ）は、個々の通信パターンに割り当てられる「端末が不正な活動（マルウェアの活動）をしていると推測される程度」を示す値である。本実施形態において、グレード（Ｇｒ）は、０ ≦ Ｇｒ ＜ １．０の範囲の値（小数点以下１桁）が設定されている。グレード（Ｇｒ）＝０は、マルウェアの活動の結果発生した通信パターンである可能性が極めて低いことを示し、１に近いグレードほどマルウェアの活動の結果発生した通信パターンである可能性が高いことを示す。グレード（Ｇｒ）は、正当なアプリケーションの通信パターンとして出現する頻度に基づいて、通信パターン毎に予め決定されている。即ち、正当なアプリケーションによる通信として現れる可能性が低い通信にはより高い値のグレードが割り当てられ、正当なアプリケーションによる通信として現れる可能性が高い通信にはより低いグレードが割り当てられる。本実施形態では、通信パターンＰｎ−ｍに予め設定されたグレードが「Ｇｒ（Ｐｎ−ｍ）」、通信パターンＰｎ−ｍに該当する通信を行った端末（ｈ）に割り当てられたグレードが「Ｇｒ（ｈ， Ｐｎ−ｍ）」で表される。

なお、同一の通信パターンであっても、条件に基づいて、異なるグレード（Ｇｒ）が割り当てられ得る。例えば、通信パターンに付随して２つの条件「Ａ：宛先がＣ＆Ｃサーバーに一致しない」、「Ｂ：宛先がＣ＆Ｃサーバーの１つに一致」が設定されている場合、以下のように条件判定され、宛先が登録済みのＣ＆Ｃサーバーに一致するか否かによって、異なるグレードが割り当てられる。
ＩＦ （Ｐｎ−ｍ ＝ ＴＲＵＥ） ＡＮＤ （Ａ） ＴＨＥＮ Ｇｒ（Ｐｎ−ｍ）＝０．１、ＡＣＴＩＯＮ＝ Ｃ＆Ｃサーバー候補リストに記録
ＩＦ （Ｐｎ−ｍ ＝ ＴＲＵＥ） ＡＮＤ （Ｂ） ＴＨＥＮ Ｇｒ（Ｐｎ−ｍ）＝０．６、ＡＣＴＩＯＮ＝Ｎｏ

更に、本実施形態において、評価値取得部２５２は、入力パケットと、入力パケットに係る端末によって入力パケットよりも前または後に送信または受信された他のパケット（以下、「先行パケット」「後続パケット」と称する）と、の相関分析の結果に従って、グレードを取得する。より具体的には、本実施形態において、評価値取得部２５２は、通信取得部２１によって取得された通信（入力パケット）に関して取得されたフェーズと、当該通信に係る端末に関して当該通信の前または後に行われた他の通信（先行パケットまたは後続パケット）に関して取得されたフェーズと、の間に連続性があるか否かを判定し、連続性があると判定された場合に、グレードを取得する。

補正部２５３は、入力パケットと先行パケットまたは後続パケットとの相関分析の結果に従って、評価値取得部２５２によって取得されたグレードを補正する。より具体的には、本実施形態において、補正部２５３は、通信取得部２１によって取得された通信（入力パケット）に関して取得されたフェーズと、当該通信に係る端末に関して当該通信の前または後に行われた他の通信（先行パケットまたは後続パケット）に関して取得されたフェーズと、の間に連続性があるか否かを判定し、連続性があると判定された場合に、評価値取得部２５２によって取得されたグレードを、連続性があると判定されなかった場合に比べてより大きく補正する。

換言すれば、本実施形態では、新たに取得された通信（入力パケット）と、当該通信に係る端末による過去または未来の通信（先行パケットまたは後続パケット）との相関分析が行われ、入力パケットと先行パケットまたは後続パケットとの間に、「マルウェア活動として推定される度合いをより高めるような連続性」が認められた場合に、過去または未来の通信（先行パケットまたは後続パケット）に対するグレードの取得や、新たに取得された通信（入力パケット）に対するグレードの補正が行われる。

決定部２５４は、入力パケットについて、当該端末に係るフェーズおよびグレードを決定する。決定部２５４は、比較部２５１による比較の結果、入力パケットに対応する通信パターンＰｎ−ｍについて予め設定されているフェーズＰｎを、当該端末に係るフェーズとして決定する。また、決定部２５４は、評価値取得部２５２によって取得されたグレードＧｒ（Ｐｎ−ｍ）をそのまま入力パケットのグレードとして決定することもあるが、補正部２５３によってグレードが補正された場合には、補正された値が、入力パケットのグレードとして決定される。

保持部２５５は、端末毎に、決定されたグレードのフェーズ毎の最大値を保持する。本実施形態では、保持部２５５は、マルウェア活動遷移モデルのフェーズＰｎ毎に、当該フェーズＰｎについて検出された通信パターンＰｎ−ｍのグレードＧｒ（Ｐｎ−ｍ）の最大値をフェーズＰｎのグレードとして保持し、「ＰＧｒ（Ｐｎ）」で表す。端末（ｈ）のフェーズＰｎのグレードは「ＰＧｒ（ｈ， Ｐｎ）」で表され、以下の式を用いて取得される。
ＰＧｒ（ｈ， Ｐｎ） ＝ ｍａｘ ｛Ｇｒ（Ｐｎ−ｍ） ｜ Ｐｎ−ｍ∈ｈ｝

本実施形態において、保持部２５５は、端末毎にフェーズ毎のグレード最大値を保持するグレード管理テーブルを用いて、端末毎、フェーズ毎のグレードを管理する（図示は省略する）。グレード管理テーブルには、ネットワーク監視装置２０が把握している端末（ｈ）毎に、各フェーズＰｎのグレードＰＧｒ（ｈ， Ｐｎ）が保持される。各フェーズＰｎのグレードＰＧｒ（ｈ， Ｐｎ）は、先述の通り、当該フェーズＰｎについて検出された通信パターンＰｎ−ｍのグレードＧｒ（Ｐｎ−ｍ）の最大値である。このため、何れかのフェーズについて新たにグレードが決定されると、新たに決定されたグレードとグレード管理テーブルに保持されているグレードＰＧｒ（ｈ， Ｐｎ）とが比較され、最大値に更新される。なお、通信パターンＰｎ−ｍ毎のグレードＧｒ（Ｐｎ−ｍ）の最大値Ｇｒ（ｈ， Ｐｎ−ｍ）についても、記憶装置１４ａに保持される。

合計部２５６は、端末毎に、フェーズＰ１からフェーズＰ８までの夫々のフェーズのグレードの最大値ＰＧｒ（ｈ， Ｐｎ）を取得し、これらを合計する。

判定部２５７は、処理対象となっている端末（ｈ）の、フェーズ毎のグレードの最大値ＰＧｒ（ｈ， Ｐｎ）に基づいて、端末が不正な活動を行っているか否かを判定する。本実施形態では、判定部２５７は、合計部２５６によって得られた合計値に基づいて、端末が不正な活動を行っているか否かを判定する。より具体的には、判定部２５７は、合計値に所定の重み付けを行うことで、「マルウェアが活動している可能性の高さを示す値」（以下、「マルウェア活動可能性」と称する）を算出し、この値が所定の閾値を超えた場合に、当該端末が不正な活動を行っていると判定する。端末（ｈ）のマルウェア活動可能性は、端末（ｈ）がマルウェアに感染している可能性の度合いを示し、「ＩＲ（ｈ）」で表される。端末（ｈ）のマルウェア活動可能性は、０（感染なし）〜１００（感染の可能性大）の値を取る。即ち、本実施形態において、端末（ｈ）のマルウェア活動可能性は、以下のように定義される。ここで、ψはマルウェア活動係数を示す。

一般に、活動遷移モデルの多くの（連続した）フェーズ上で通信パターンが検出された端末は、より少ないフェーズ上で通信パターンが検出された端末よりも、マルウェアに感染している可能性が高いと判断できるため、マルウェア活動係数ψ（本実施形態では、具体的な値として０．５が設定される）を導入する。上記のマルウェア活動可能性ＩＲ（ｈ）は、端末（ｈ）に関連する通信パターンに対応する通信パターンが検出される都度、計算および更新される。

本実施形態では、マルウェア活動可能性が、０〜４９の端末を「クリーン端末」、５０〜８９の端末を「グレー端末」、９０〜１００の端末を「ブラック端末」と定義する。管理者端末の管理画面（デバイス一覧画面）には、リアルタイムレポート情報として、端末ごとに、マルウェア活動可能性と「クリーン」、「グレー」、「ブラック」が表示される。また、詳細情報として、端末ごとに、検出された「通信パターン」の概要と検知回数のリストが表示される。なお、「クリーン」、「グレー」、「ブラック」のマルウェア活動可能性の閾値は、管理者によって設定可能であってもよい。

相関分析部２５８は、入力パケットと、入力パケットに係る端末によって入力パケットよりも前または後に送信または受信された他のパケット（先行パケットまたは後続パケット）と、の相関分析を行う。即ち、本実施形態において実施される相関分析は、２つ以上の通信間または２つ以上のフェーズ間に連続性や共通性等の相関性の有無または程度を分析するものであり、相関分析の結果は、評価値取得部２５２、補正部２５３および判定部２５７等によって用いられる。例えば、相関分析部２５８は、決定部２５４によって、侵入フェーズＰ１であると決定された第一の通信と、実行ファイルのダウンロードフェーズであると決定された第二の通信との相関分析を行うことで、第一の通信によるコンテンツのダウンロードと、第二の通信による実行ファイルのダウンロードとの間の相関性の有無または程度を判定する。その他、相関分析の具体的な手法については、後述する。

＜処理の流れ＞
次に、本実施形態に係るシステム１によって実行される処理の流れを、フローチャートを用いて説明する。なお、以下に説明するフローチャートに示された処理の具体的な内容および処理順序は、本発明を実施するための一例である。具体的な処理内容および処理順序は、本発明の実施の形態に応じて適宜選択されてよい。

ネットワーク監視装置２０は、新たなネットワークに接続されると、後述するパケット毎の検知処理を開始する前に、準備処理として、ネットワーク構成の解析／学習処理を実行する。具体的には、ネットワーク監視装置２０は、新たなネットワークに接続されると、所定時間パケットを取得して、取得されたパケットを解析することで、監視対象となるネットワークの構成を解析し、マルウェア検知に必要な情報（デバイス一覧（デバイスタイプ、ＯＳ種別、ＭＡＣ／ＩＰアドレス等）、監視対象ネットワークのアドレス体系、ＤＮＳサーバー情報、メールサーバー情報、プロキシ（ＨＴＴＰ／ＳＯＣＫＳ）情報、Ａｃｔｉｖｅ Ｄｉｒｅｃｔｏｒｙ情報等）を学習し、記憶装置１４ａ等に保存する。

なお、ネットワーク構成の解析／学習処理は、後述する検知処理が開始された後も、ネットワーク監視装置２０によって継続的に実行される。即ち、ネットワーク監視装置２０は、取得されたパケットを解析して得られた情報と、以前の解析／学習処理によって学習され、ネットワーク監視装置２０の記憶装置１４ａに保持されている情報とを照合し、照合の結果、新たに得られた情報が保持されている情報と異なる場合、ネットワーク監視装置２０は、ネットワークセグメント２における構成が変更されたと判断し、新たに得られた情報を用いて、ネットワーク監視装置２０の記憶装置１４ａに保持されている情報を更新する。

図５は、本実施形態に係る、パケット毎の検知処理の流れの概要を示すフローチャートである。本実施形態に係る検知処理は、ネットワーク監視装置２０によって、ネットワーク上を流れるパケット（または、複数パケットからなるデータ）が取得される度に実行される。

ステップＳ００１では、パケット解析の前処理が実行される。ネットワーク監視装置２０は、通信取得部２１によって新たに通信（入力パケット）が取得されると、入力パケットの整形、分類、および有効な既存フローへの関連付けを行う。また、ネットワーク監視装置２０は、入力パケットを端末単位（送信元／宛先ＩＰアドレス（ＭＡＣアドレス）単位）、プロトコル（ＴＣＰ／ＵＤＰ、ＩＣＭＰ、ＤＮＳ、ＨＴＴＰ、ＨＴＴＰＳ、ＩＲＣ、ＦＴＰ、ＴＦＴＰ、ＳＯＣＫＳ、ＮｅｔＢＩＯＳ等）単位に分類、および既存フローとの関連付けを行う。その後、処理はステップＳ００２へ進む。

ステップＳ００２からステップＳ００５では、アプリケーション検知エンジン２３およびプロトコルアノマリ検知エンジン２４による処理が行われる。本実施形態に係るネットワーク監視装置２０は、上述した３種類の検知エンジン（検知プログラム）を用いて、ネットワークに接続された端末による不正な通信を検知するが、本実施形態において、ネットワーク監視装置２０は、パケットを取得すると、アプリケーション検知エンジン２３およびプロトコルアノマリ検知エンジン２４による検知を行った後で、マルウェアふるまい検知エンジン２５による検知を行う。即ち、本実施形態において、マルウェアふるまい検知エンジン２５は、他の検知手段（アプリケーション検知エンジン２３およびプロトコルアノマリ検知エンジン２４）によって不正な通信として検知されなかった通信に基づいて、ノード９０が不正な活動を行っているか否かを判定する。このようにすることで、本実施形態によれば、マルウェアふるまい検知エンジン２５によって処理されるパケットの数を減らし、ふるまい検知エンジンの動作によって生じる負荷を減らすことが出来る。但し、マルウェアふるまい検知エンジン２５は、単体で動作してもよいし、その他の検知エンジンと組み合わせて動作されてもよい。また、パケットが取得された際の検知エンジンの処理順序は、本実施形態に示した例に限定されない。

アプリケーション検知エンジン２３によって不要なアプリケーションが検知された場合や、プロトコルアノマリ検知エンジン２４によってプロトコルアノマリが検知された場合、処理はステップＳ０１２へ進み、遮断またはアラート発行が行われる。一方、不要なアプリケーションやプロトコルアノマリが検知されなかった場合、処理はステップＳ００６へ進む。なお、本フローチャートにおいて、ステップＳ００６からステップＳ０１１までの処理は、マルウェアふるまい検知エンジン２５による処理に相当する。

ステップＳ００６では、通信パターンの判定処理が行われる。比較部２５１は、入力パケットと予め定義された通信パターン（Ｐｎ−ｍ）とを比較することで、入力パケットと予め定義された通信パターン（Ｐｎ−ｍ）との共通性を判定する。ここで、通信パターン（Ｐｎ−ｍ）と共通性があると判定された場合、入力パケットに係る端末（ｈ）の活動遷移モデル上のフェーズはフェーズＰｎ（ｈ）に決定される。また、評価値取得部２５２は、判定の結果、一致または近似する（対応する）と判定された通信パターンのグレードＧｒ（Ｐｎ−ｍ）を、端末（ｈ）に関連づけて、入力パケットのグレードＧｒ（ｈ， Ｐｎ−ｍ）として取得する。更に、ネットワーク監視装置２０は、検出した通信パターンに基づいて、対象通信の送信元端末または宛先端末を「マルウェア配布サーバー候補リスト」、または「Ｃ＆Ｃサーバー候補リスト」に登録する。ここでは、パケットロストを考慮して、すべてのフェーズの通信パターンを対象に判定および評価が行われる。なお、既知の判定済みフローと関連付いているために、追加の判定処理が不要な入力パケットについては、判定は行われず、統計情報の更新のみが行われる。その後、処理はステップＳ００７へ進む。

ステップＳ００７では、第一の相関分析が行われる。評価値取得部２５２は、ステップＳ００６で検出できなかったＣ＆Ｃ通信をピックアップする。評価値取得部２５２は、探索フェーズＰ２、感染・浸潤フェーズＰ３、実行ファイルのダウンロードフェーズＰ４、攻撃活動フェーズＰ８に遷移する際に、そのトリガーとなった通信をピックアップし、ネットワーク監視装置２０は、対象通信の送信元端末または宛先端末Ｃ＆Ｃサーバー候補リストに登録する。なお、第一の相関分析の処理内容については、図６から図８、および図９を参照して後述する。その後、処理はステップＳ００８へ進む。

ステップＳ００８では、第二の相関分析が行われる。補正部２５３は、ステップＳ００６で判定された端末（ｈ）の活動フェーズＰｎ（ｈ）について、その直前に活動していたフェーズとの連続性や他の（感染）端末の挙動との相関性を分析する。分析の結果、マルウェアの挙動である疑いの高い通信パターンが発見された場合、補正部２５３は、ステップＳ００６で判定した端末（ｈ）の通信パターン（Ｐｎ−ｍ）のグレードＧｒ（ｈ， Ｐｎ−ｍ）を、以下の式を用いて補正し、より高いグレードを割り当てる。
Ｇｒ（ｈ， Ｐｎ−ｍ） ＝ θ・Ｇｒ（ｈ， Ｐｎ−ｍ）
但し、マルウェア挙動類似係数θの範囲は１．０から２．０。ここで１．０は「類似性なし」を意味する。なお、第二の相関分析の処理内容、およびマルウェア挙動類似係数θについては、図６から図８、および図１０から図１５を参照して後述する。その後、処理はステップＳ００９へ進む。

ステップＳ００９では、活動フェーズのグレード（ＰＧｒ）が決定される。決定部２５４は、ステップＳ００６からステップＳ００８の処理結果に基づいて、対応する端末ｈの通信パターンのグレードＧｒ（ｈ， Ｐｎ−ｍ）から、フェーズＰｎのグレードＰＧｒ（ｈ， Ｐｎ）ｉを決定する。なお、ここで、ＰＧｒ（ｈ， Ｐｎ）ｉ−１は、前回までのフェーズＰｎのグレードを示す。
ＰＧｒ（ｈ， Ｐｎ）ｉ ＝ ｍａｘ ｛ＰＧｒ（ｈ， Ｐｎ）ｉ−１ ， Ｇｒ（ｈ， Ｐｎ−ｍ）｝
その後、処理はステップＳ０１０へ進む。

ステップＳ０１０では、マルウェア活動可能性（ＩＲ（ｈ））が算出される。合計部２５６および判定部２５７は、端末ｈのマルウェア活動可能性ＩＲ（ｈ）を算出する。具体的な算出方法については、合計部２５６および判定部２５７の説明において上述した通りである。その後、処理はステップＳ０１１へ進む。

ステップＳ０１１およびステップＳ０１２では、マルウェア活動可能性ＩＲ（ｈ）が所定の閾値以上である場合に、該当端末の遮断や管理者アラート発行等の対処が行われる。判定部２５７は、ステップＳ０１０で算出された端末のマルウェア活動可能性が「ブラック」を示す所定の閾値以上であるか否かを判定する（ステップＳ０１１）。そして、マルウェア活動可能性が「ブラック」の場合、通信遮断部２２は、該当端末による通信を遮断する、または管理者にアラートを発行する等の対処を行う（ステップＳ０１２）。また、マルウェア活動可能性が「グレー」の場合にも、ネットワーク監視装置２０は、管理者にアラートを発行してよい。マルウェア活動可能性が「クリーン」の場合は、遮断やアラートの発行等の対処は行われない。その後、本フローチャートに示された処理は終了する。

図６から図８は、本実施形態に係る、マルウェアふるまい検知エンジン２５による検知処理の流れを示すフローチャートである。本フローチャートは、図５を用いて説明した検知処理のステップＳ００６からステップＳ０１２の処理をより詳細に説明するものである。より具体的には、ステップＳ１０１からステップＳ１０３は、図５のステップＳ００６で説明した通信パターン判定処理をより詳細に説明するものであり、ステップＳ１０４からステップＳ１１０は、ステップＳ００７で説明した第一の相関分析処理をより詳細に説明するものであり、ステップＳ１１１からステップＳ１１６は、ステップＳ００８で説明した第二の相関分析処理をより詳細に説明するものであり、ステップＳ１１７からステップＳ１２０は、ステップＳ００９で説明した活動フェーズのグレード決定処理をより詳細に説明するものである。また、ステップＳ１２１は、図５のステップＳ０１０に相当し、ステップＳ１２２およびステップＳ１２３は、ステップＳ０１１およびステップＳ０１２に相当する。

ステップＳ１０１およびステップＳ１０２では、取得されたパケット（入力パケット）が、予め定義された通信パターンの何れに該当するかが判定される。比較部２５１は、入力パケットと予め保持された通信パターンとを比較することで、入力パケットと予め定義された通信パターン（Ｐｎ−ｍ）との共通性を判定する。判定の結果、何れの通信パターンにも該当しないと判定された場合、当該パケットに係る処理は終了し、本フローチャートに示された処理は終了する。一方、何れかの通信パターンに該当すると判定された場合、処理はステップＳ１０３へ進む。

ステップＳ１０３では、入力パケットに係る端末に関して、該当すると判定された通信パターン（Ｐｎ−ｍ）が検出されたことが記録される。また、評価値取得部２５２は、入力パケットに対応する通信パターン（Ｐｎ−ｍ）が属するフェーズＰｎおよび通信パターン（Ｐｎ−ｍ）に予め設定されているグレードＧｒ（Ｐｎ−ｍ）を、入力パケットに係る端末（ｈ）のフェーズＰｎ（ｈ）、および当該フェーズのグレードＧｒ（ｈ， Ｐｎ−ｍ）として取得する。その後、処理はステップＳ１０４へ進む。

ステップＳ１０４およびステップＳ１０５では、入力パケットに対応する通信パターンに必須条件が設定されている場合に、必須条件に対応する通信が過去に取得されているか否かが判定される。必須条件が設定されていない場合、処理はステップＳ１０７へ進む。ここで、必須条件とは、ステップＳ１０１において入力パケットに対応すると判定された通信パターン（Ｐｎ−ｍ）に予め設定されているグレードＧｒ（Ｐｎ−ｍ）を、当該入力パケットに係る端末（ｈ）のフェーズＰｎ（ｈ）のグレードＧｒ（ｈ， Ｐｎ−ｍ）として決定してよいか否かを判定するための条件である。例えば、「Ｐ６−４： ＨＴＴＰ標準ポート（８０）を宛先ポートとしたＨＴＴＰ通信（プロキシ／非プロキシ）」の通信パターンはＨＴＴＰの一般的な通信であるが、この通信パターンは、「Ｐ０−１〜Ｐ０−１５」に定義されている「ＨＴＴＰ悪性通信パターン」の何れかが検知されていることが必須条件である。このため、これらの必須条件が満たされた場合に、当該入力パケットについて通信パターンＰ６−４のグレードＧｒ（ｈ， Ｐ６−４）が決定され、必須条件が満たされない場合は、当該入力パケットについて通信パターンＰ６−４のグレードＧｒ（ｈ， Ｐ６−４）は決定されない。

即ち、評価値取得部２５２は、入力パケットに関して取得されたフェーズと、当該通信に係る端末に関して当該通信の前に行われた他の通信（先行パケット）に関して取得されたフェーズと、の間に連続性があるか否かを、過去に取得された通信が必須条件を満たしているか否かを判定することで判定する。必須条件が満たされないと判定された場合、処理はステップＳ１０６へ進み、当該入力パケットのグレードは０（ゼロ）に設定される。一方、必須条件が満たされると判定された場合、処理はステップＳ１０７へ進む。

ステップＳ１０７では、入力パケットに係る端末のフェーズにグレードが割り当てられる。評価値取得部２５２は、入力パケットについて、該当すると判定された通信パターンＰｎ−ｍに予め定義されたグレードＧｒ（Ｐｎ−ｍ）を取得し、端末（ｈ）のフェーズＰｎ（ｈ）のグレードＧｒ（ｈ， Ｐｎ−ｍ）とする。その後、処理はステップＳ１０８へ進む。

ステップＳ１０８では、入力パケットが、過去に検知された通信パターンの必須条件に該当するか否かが判定される。換言すれば、ステップＳ１０８では、過去に取得された通信（先行パケット）から見て未来にあたる現時点において、必須条件に該当する通信（入力パケット）が検知されたか否かが判定される。評価値取得部２５２は、入力パケットの通信パターンが必須条件に設定されている通信パターンが、過去に検出されているか否かを判定する。判定の結果、入力パケットに係る通信パターンを必須条件とする通信パターンが過去に検出されていないと判定された場合、処理はステップＳ１１１へ進む。一方、判定の結果、入力パケットに係る通信パターンを必須条件とする通信パターンが過去に検出されていると判定された場合、処理はステップＳ１１０へ進む。

ステップＳ１１０では、過去に取得された通信（先行パケット）のフェーズにグレードが割り当てられる。評価値取得部２５２は、過去に検出された通信に、当該通信パターン（Ｐｎ−ｍ）に予め定義されたグレードＧｒ（Ｐｎ−ｍ）を取得し、割り当てる。その後、処理はステップＳ１１１へ進む。

ステップＳ１１１およびステップＳ１１２では、入力パケットに対応する通信パターンにグレード補正条件が設定されている場合に、グレード補正条件に該当する通信が過去に取得されているか否かが判定される。グレード補正条件が設定されていない場合、処理はステップＳ１１４へ進む。ここで、グレード補正条件とは、ステップＳ１０１において入力パケットに対応すると判定された通信パターン（Ｐｎ−ｍ）に予め設定されているグレードＧｒ（Ｐｎ−ｍ）をより大きな値に補正すべきか否かを判定するための条件である。補正部２５３は、グレード補正条件に該当する通信が、入力パケットに係る端末について過去に検知されているか否かを判定する。グレード補正条件が満たされないと判定された場合、グレードの補正は行われず、処理はステップＳ１１４へ進む。一方、必須条件が満たされると判定された場合、処理はステップＳ１１３へ進む。

ステップＳ１１３では、グレードの補正が行われる。補正部２５３は、ステップＳ１１２で満たされたと判定されたグレード補正条件について予め設定された補正値に従って、ステップＳ１０７で割り当てられたグレードＧｒ（ｈ， Ｐｎ−ｍ）を補正する。例えば、補正値が１．５である場合、グレードＧｒ（ｈ， Ｐｎ−ｍ）の値が１．５倍される。その後、処理はステップＳ１１４へ進む。

ステップＳ１１４では、入力パケットが、過去に検知された通信パターンのグレード補正条件に該当するか否かが判定される。換言すれば、ステップＳ１１４では、過去に取得された通信（先行パケット）から見て未来にあたる現時点において、グレード補正条件に該当する通信（入力パケット）が検知されたか否かが判定される。補正部２５３は、入力パケットの通信パターンがグレード補正条件に設定されている通信パターンが、過去に検出されているか否かを判定する。判定の結果、入力パケットに係る通信パターンをグレード補正条件とする通信パターンが過去に検出されていないと判定された場合、処理はステップＳ１１７へ進む。一方、判定の結果、入力パケットに係る通信パターンをグレード補正条件とする通信パターンが過去に検出されていると判定された場合、処理はステップＳ１１６へ進む。

ステップＳ１１６では、過去の通信（先行パケット）に係るグレードの補正が行われる。補正部２５３は、過去に検出された通信パターンに係る端末に割り当てられていたグレードを、当該グレード補正条件について予め定義された補正値で補正する。例えば、補正値が１．５である場合、グレードが１．５倍される。その後、処理はステップＳ１１７へ進む。

ステップＳ１１７からステップＳ１２０では、フェーズ毎の最大グレードの更新処理が行われる。まず、ネットワーク監視装置２０は、入力パケットに係る端末について、検知フェーズ（Ｐ１からＰ８）毎に保持されている最大グレード（補正されているグレードについては、補正後の値）を、グレード管理テーブルから取得し（ステップＳ１１７）、ステップＳ１０１からステップＳ１１６までの処理の結果決定部２５４によって決定されたグレードと比較することで、各フェーズにおいて、最大グレードが更新されたか否かを判定する（ステップＳ１１８）。ここで、最大グレードが更新されていないと判定された場合、処理はステップＳ１２１へ進む。一方、最大グレードが更新されたと判定された場合、保持部２５５は、新たに割り当てられたグレードをもって、グレード管理テーブルに記録された最大グレードを更新し、これを保持する（ステップＳ１２０）。なお、この過程で、証跡ログが採取される（ステップＳ１１９）。その後、処理はステップＳ１２１へ進む。

ステップＳ１２１では、端末におけるマルウェア活動可能性が算出される。合計部２５６は、当該端末ｈの各フェーズで求められた最大グレードを合算し、判定部２５７は、マルウェア活動係数を乗算することで、端末ｈのマルウェア活動可能性ＩＲ（ｈ）を算出する。詳細な算出方法は、合計部２５６および判定部２５７の説明において上述した通りである。その後、処理はステップＳ１２２へ進む。

ステップＳ１２２およびステップＳ１２３では、対象ノード９０の、マルウェア感染の有無が判定される。判定部２５７は、ステップＳ１２１で算出されたマルウェア活動可能性ＩＲ（ｈ）が所定の閾値を超えているか否かを判定する（ステップＳ１２２）。ここで、マルウェア活動可能性ＩＲ（ｈ）が閾値を超えていると判定された場合、ネットワーク監視装置２０は、マルウェア感染が検知された際の所定の対応を行う。マルウェア感染が検知された際の対応としては、例えば、通信遮断部２２による当該ノード９０の通信遮断開始や、当該ノード９０がマルウェアに感染していることのアラート（警告）の通知等が挙げられる。一方、マルウェア活動可能性ＩＲ（ｈ）が閾値を超えていないと判定された場合には、通信遮断や警告等の、マルウェア感染が検知された際の対応は行われない。その後、本フローチャートに示された処理は終了する。

なお、ネットワーク監視装置２０は、例えば、Ｌ２／Ｌ３スイッチから取得された通信データを破棄する方法、Ｌ２／Ｌ３スイッチのポートを遮断する方法、ノード９０に対してＡＲＰ偽装によるパケット送信先の誘導を行う方法、ルータ１０に指示してノード９０に係る通信を破棄させる方法、またはノード９０が属するＶＬＡＮを変更して隔離する方法、等を用いて、ノード９０による通信を遮断することができる。また、ネットワーク監視装置２０がルータ１０に搭載（内包）されている場合には、ノード９０が受信または送信する通信を直接遮断することもできる。また、ネットワーク監視装置２０は、管理サーバーやノード９０、予め設定された管理者端末等に通知パケットやメール等を送信する方法や、ネットワーク監視装置２０自身に設けられた表示装置（ディスプレイやＬＥＤ等）を介して警告表示する方法等を用いて、アラートを通知することが出来る。

＜相関分析の具体例＞
以下に、相関分析の具体例を説明する。但し、相関分析は、端末による複数の通信が、マルウェアの活動に伴うフェーズの遷移の観点から相関性を有しているか否かを分析するものであればよく、本実施形態に示された例に限定されない。

（１）第一の相関分析
通信パターンの判定処理（ステップＳ００６を参照）は、予め定義された「通信パターン」に基づいている。従って、この処理のみでは、通信パターンに一致しない通信を行うマルウェアを検知できない。このため、本実施形態では、第一の相関分析（ステップＳ００７を参照）を行うこととしている。

図９は、本実施形態における第一の相関分析で監視対象とする活動遷移モデル上のフェーズとその遷移を示す図である。一般に、マルウェアは、Ｃ＆Ｃサーバーからの指令に従って、探索フェーズＰ２、感染・浸潤フェーズＰ３、実行ファイルのダウンロードフェーズＰ４、または攻撃活動フェーズＰ８に遷移する。また、Ｃ＆Ｃサーバーからの指令を受信してから、探索フェーズＰ２、感染・浸潤フェーズＰ３、実行ファイルのダウンロードフェーズＰ４、攻撃活動フェーズＰ８に遷移するまでの時間は、非常に短い（１秒以内）ことが一般的である。第一の相関分析では、この特性を利用して、端末（ｈ）が、探索フェーズＰ２、感染・浸潤フェーズＰ３、実行ファイルのダウンロードフェーズＰ４、または攻撃活動フェーズＰ８に遷移した際に、トリガーとなった通信を一旦Ｃ＆Ｃ通信と見なして、当該通信に係る端末をＣ＆Ｃサーバー候補リストに登録する。Ｃ＆Ｃサーバー候補リストに登録した後、マルウェアの感染を特定する処理は上記に示したマルウェアの検知方法に従う。

（１．１）準備（評価情報の収集）
第一の相関分析では、活動遷移モデル上の探索フェーズＰ２、感染・浸潤フェーズＰ３、実行ファイルのダウンロードフェーズＰ４または攻撃活動フェーズＰ８における活動が観測（通信パターンが検出）された際に、そのトリガーとなった通信を分析して、一定の条件を満たす場合に、そのトリガーとなった通信の送信元（端末（ｈ）から見た場合は接続先）をＣ＆Ｃサーバー候補としてリストに登録する。以下に、第一の相関分析で利用する情報の収集方法と記録内容を説明する。なお、以下の処理は、監視対象端末が送信したパケットを検出するたびに実行される。また、この準備（評価情報の収集）処理は、通信パターンの判定処理（ステップＳ００６を参照）の終了後に実行される。

（１．１．１）分析
パケットを分析して、以下の条件を満たす場合は（１．１．２）のパケット待ち合わせに進む。条件を満たさない場合は、何もせずパケットを待ち合わせる。
・パケットは、端末（ｈ）が送信したＨＴＴＰ ＧＥＴ、ＰＯＳＴ、ＰＵＴ、ＣＯＮＮＥＣＴリクエストの何れかである。且つ
・ＧＥＴリクエストは、ファイルのダウンロード要求ではない。且つ
・Ｕｓｅｒ−Ａｇｅｎｔヘッダーの値が”Ｍｏｚｉｌｌａ”で始まらない、またはＵｓｅｒ−Ａｇｅｎｔヘッダーが存在しない。

なお、上記したＵｓｅｒ−Ａｇｅｎｔの条件は、ウェブブラウザ以外のアプリケーションが送信したＨＴＴＰリクエストだけを評価対象にすることを意味する。（偽装）ウェブブラウザ通信は、通信パターンの判定処理で評価対象になっているため、第一の相関分析では、非ウェブブラウザ通信のみが対象となる。そして、上記の条件を満たされた場合、端末（ｈ）の管理テーブルには以下の情報が記録される。
・メソッド種別（ＧＥＴ， ＰＯＳＴ， ＰＵＴ， ＣＯＮＮＥＣＴの何れか）
・Ｕｓｅｒ−Ａｇｅｎｔヘッダーの値（文字列）。Ｕｓｅｒ−Ａｇｅｎｔヘッダーが存在しない場合は”ＮＵＬＬ”
・Ｈｏｓｔヘッダーの値（ＦＱＤＮまたはＩＰアドレス）

（１．１．２）パケット待ち合わせ
ここでは、後続のパケットが待ち合わせられる。パケットが受信されると、以下の処理が実行される。
・パケットが（１．１．１）の条件を満たす端末（ｈ）が送信した新しいＨＴＴＰリクエストである場合、処理は（１．１．１）の分析に戻る。なお、ＨＴＴＰリクエストおよびそのレスポンスとしては、最新のデータのタイムスタンプのみが必要だが、パケットロストが発生する可能性があるため、全てのＨＴＴＰレスポンス受信時にタイムスタンプを記録して、後続のレスポンスを受信した場合に上書きしてもよい。
・パケットが、端末（ｈ）が（１．１．１）で送信したＨＴＴＰリクエストのレスポンスであり、且つＨＴＴＰレスポンスのホディ部のサイズがゼロである場合、処理は（１．１．１）に移行する。これは、ＨＴＴＰレスポンスのホディ部のサイズがゼロの場合、Ｃ＆Ｃサーバーからの指令情報を含んでいないことを意味するためである。
・パケットは、端末（ｈ）が（１．１．１）で送信したＨＴＴＰリクエストのレスポンスである。且つＨＴＴＰレスポンスのホディ部のサイズがゼロでない場合は、以下に示す内容を記録して、処理は（１．１．３）に移行する。
・ＨＴＴＰレスポンスパケットの検出（受信）時刻（タイムスタンプ：ミリ秒）を記録する。以降、このタイムスタンプを「ＴｉｍｅＳｔａｍｐ（Ｃ）」で表す。なお、ここではＨＴＴＰレスポンスの最終データのタイムスタンプのみが必要であるが、パケットロストが発生する可能性があるため、全てのＨＴＴＰレスポンス受信時にタイムスタンプを記録して、後続のレスポンスを受信した場合に上書きすることとする。

（１．１．３）判定
ここでは、以下の判定および処理が行われる。
・（１．１．２）で処理したパケットがＨＴＴＰレスポンスの最終データではない場合、マルウェアふるまいエンジン２５は、（１．１．２）に留まって、後続のレスポンスを待ち合わせる。
・（１．１．２）で処理したパケットがＨＴＴＰレスポンスの最終データであった場合、マルウェアふるまいエンジン２５は、（１．１．１）の分析に移り、新規のＨＴＴＰリクエストを待ち合わせる。

（１．２）探索フェーズＰ２への遷移時の処理内容
マルウェアふるまい検知エンジン２５は、以下の処理を順次行い、条件を満たす場合に、「準備（評価情報の収集）」で記録したパケットに係る端末をＣ＆Ｃサーバー候補リストに登録する。
・探索フェーズＰ２上の活動と認定（「探索フェーズＰ２の通信パターン」に一致）且つ
・探索フェーズＰ２に遷移した時刻（タイムスタンプ：ＴｉｍｅＳｔａｍｐ（Ｐ２））と記録しているＴｉｍｅＳｔａｍｐ（Ｃ）が以下の条件を満たす。
ＴｉｍｅＳｔａｍｐ（Ｃ）＋５００ｍｓ ＞ ＴｉｍｅＳｔａｍｐ（Ｐ２）
マルウェアふるまい検知エンジン２５は、上記の条件を満たす「準備（評価情報の収集）」で記録した通信（入力パケット）には、グレード（Ｇｒ）＝０．３を付与する。記録しているＣ＆Ｃ通信フェーズのグレード（ＰＧｒ）と比較して、大きい値のグレードをＣ＆Ｃ通信フェーズのグレード（ＰＧｒ）として記録し直す。なお、ＴｉｍｅＳｔａｍｐ（Ｐ２）は、通信パターンの判定処理で、「探索フェーズＰ２の通信パターン」を検出した際に記録される。ＴｉｍｅＳｔａｍｐ（Ｐ２）の計測対象は、探索フェーズ上の「疑わしい接続の試み」に該当する通信パターンのみである。また、通信パターンの観測時刻は、「疑わしい接続の試み」に該当する通信パターンを検出した時刻とする。

（１．３）実行ファイルのダウンロードフェーズＰ４への遷移時の処理内容
マルウェアふるまい検知エンジン２５は、以下の処理を順次行い、条件を満たす場合に、「準備（評価情報の収集）」で記録したパケットに係る端末をＣ＆Ｃサーバー候補リストに登録する。
・実行ファイルのダウンロードフェーズＰ４上の活動と認定（「実行ファイルのダウンロードフェーズＰ４の通信パターン」に一致）且つ
・実行ファイルのダウンロードフェーズＰ４に遷移した時刻（タイムスタンプ：ＴｉｍｅＳｔａｍｐ（Ｐ４））と記録しているＴｉｍｅＳｔａｍｐ（Ｃ）が以下の条件を満たす。
ＴｉｍｅＳｔａｍｐ（Ｃ）＋５００ｍｓ ＞ ＴｉｍｅＳｔａｍｐ（Ｐ４）
マルウェアふるまい検知エンジン２５は、上記の条件を満たす「準備（評価情報の収集）」で記録した通信に、グレード（Ｇｒ）＝０．３を付与する。記録しているＣ＆Ｃ通信フェーズのグレード（ＰＧｒ）と比較して、大きい値のグレードをＣ＆Ｃ通信フェーズのグレード（ＰＧｒ）として記録し直す。なお、ＴｉｍｅＳｔａｍｐ（Ｐ４）は、通信パターンの判定処理で、「実行ファイルのダウンロードフェーズＰ４の通信パターン」を検出した際に記録される。ＴｉｍｅＳｔａｍｐ（Ｐ４）は、ＨＴＴＰ ＧＥＴリクエスト、ＦＴＰダウンロード、ＴＦＴＰダウンロードの開始時刻ではなく、ファイルのダウンロードが完了した時刻（ＨＴＴＰ ＧＥＴの場合は、レスポンスの最終パケット）とする。パケットロストが発生するため、ＨＴＴＰ ＧＥＴレスポンスの個々のパケット、ＦＴＰ／ＴＦＴＰのダウンロードパケットを検出するたびにＴｉｍｅＳｔａｍｐ（Ｐ４）を更新してもよい。

（１．４）攻撃フェーズＰ８への遷移時の処理内容
マルウェアふるまい検知エンジン２５は、以下の処理を順次行い、条件を満たす場合に、「準備（評価情報の収集）」で記録したパケットに係る端末をＣ＆Ｃサーバー候補リストに登録する。
・攻撃フェーズＰ８上の活動と認定（「攻撃フェーズＰ８の通信パターン」に一致）且つ
・攻撃フェーズＰ８に遷移した時刻（タイムスタンプ：ＴｉｍｅＳｔａｍｐ（Ｐ８））と記録しているＴｉｍｅＳｔａｍｐ（Ｃ）が以下の条件を満たす。
ＴｉｍｅＳｔａｍｐ（Ｃ）＋５００ｍｓ ＞ ＴｉｍｅＳｔａｍｐ（Ｐ８）
マルウェアふるまい検知エンジン２５は、上記の条件を満たす「準備（評価情報の収集）」で記録した通信には、グレード（Ｇｒ）＝０．３を付与する。記録しているＣ＆Ｃ通信フェーズのグレード（ＰＧｒ）と比較して、大きい値のグレードをＣ＆Ｃ通信フェーズのグレード（ＰＧｒ）として記録し直す。なお、ＴｉｍｅＳｔａｍｐ（Ｐ８）は、通信パターンの判定処理で、「攻撃フェーズＰ８の通信パターン」を検出した際に記録する。ＴｉｍｅＳｔａｍｐ（Ｐ８）は、（複数のパケットから最終的に）攻撃活動を認定した時刻ではなく、攻撃の通信パターンの最初のパケットを検出した時刻である。

（２）第二の相関分析
マルウェアは、マルウェア活動遷移モデルのフェーズを遷移しながら活動を深化させていく。従って、遷移した直後のフェーズでの活動（通信）が、一つ前のフェーズでの活動（通信）をトリガーにして発生した可能性が高い場合（換言すれば、前後のフェーズに相関性がある場合）、当該端末はマルウェアに感染している確率が高いと判断できる。このトリガーを通信パターンに含まれるデータ内容（例えば、Ｃ＆Ｃサーバーからの指令内容）から判断する方法も考えられるが、データ部を暗号化や難読化しているマルウェアも多く、リアルタイムに解析・判定することは困難である。このため、本実施形態では、フェーズの遷移に要した時間（通信パターンＰｒ−ｓを検出してから通信パターンＰｍ−ｎを検出するまでの時間）、通信先（コールバック通信）の端末（ｈ）、マルウェア感染の可能性が高い複数端末の挙動の相関性および一致性、扱ったファイルの種類等の情報に基づいて第二の相関分析（ステップＳ００８を参照）を行う。分析の結果、マルウェアの挙動の疑いが高い通信であると判定できた場合は、その通信に対応する通信パターンＰｍ−ｎのグレードＧｒ（Ｐｍ−ｎ）を補正（マルウェアの挙動類似係数θ倍）し、より高いグレードを付与する。

以下に、通信パターンの相関分析の分析内容を説明する。なお、フェーズの遷移順序が一致しない場合や、フェーズの遷移は一致しているが途中に別のフェーズを挟んでいる場合は、分析対象外として相関分析は行われない。また、マルウェアふるまい検知エンジン２５は、すべてのフェーズ遷移を相関分析の対象としない。マルウェアふるまい検知エンジン２５は、マルウェアの挙動として顕著な相関性が観測される以下のフェーズ遷移を、相関分析の対象とする。図１０から図１５において、実線矢印は分析対象であることを、破線矢印は分析対象でないことを示す。

（２．１）探索フェーズＰ２への遷移時の分析内容
図１０は、本実施形態における第二の相関分析で監視対象とする、探索フェーズＰ２への遷移を示す図である。マルウェアふるまい検知エンジン２５は、「マルウェアの活動フェーズ判定」処理ブロックにおいて、端末（ｈ）が探索フェーズＰ２に遷移した際に、以下の分析を行い、該当する場合、通信パターンのグレードを補正する。

（２．１．１）Ｃ＆Ｃ通信フェーズＰ６から探索フェーズＰ２へ遷移
ｉｆ ｛条件Ａ ＝ ＴＲＵＥ｝ ｔｈｅｎ ｛Ｇｒ（ｈ， Ｐ２−ｍ） ＝ θ・Ｇｒ（ｈ， Ｐ２−ｍ）｝ （θ＝１．２）
・条件Ａ：端末（ｈ）のＣ＆Ｃサーバー候補リストに登録されているＣ＆Ｃサーバーの何れかでデータ通信（Ｃ＆Ｃサーバーから何らかのデータ（指令）を受信）を観測してから、Ｎ（ａ）秒以内に、端末（ｈ）で探索フェーズの通信パターンＰ２−ｍを観測した。
なお、ここでＣ＆Ｃサーバーからデータ（指令）を受信した時刻は、以下のパケットを観測した時刻とする。
・Ｃ＆ＣがＨＴＴＰタイプである場合、ＨＴＴＰ ＧＥＴ／ＰＯＳＴ／ＰＵＴリクエストに対応する、データ長（ボディ部のサイズ）がゼロでないＨＴＴＰレスポンスの（最終）データの受信時刻
・Ｃ＆ＣがＨＴＴＰＳ（直接またはＣＯＮＮＥＣＴ）または独自プロトコルタイプである場合、該当ＴＣＰコネクション上で、端末（ｈ）が送信したデータパケットに対応する、データ長がゼロでない（最終）ＴＣＰデータの受信時刻
・Ｃ＆ＣがＩＲＣタイプである場合、Ｃ＆Ｃサーバーからデータ長がゼロでないＩＲＣメッセージの最終データの受信時刻
ここで、探索フェーズの通信パターンＰ２−ｍは、「疑わしい接続の試み」に該当する通信パターンだけを対象とする。また、通信パターンの観測時刻は、「疑わしい接続の試み」に該当する通信パターンを検出した時刻とする。

（２．２）実行ファイルのダウンロードフェーズＰ４への遷移時の分析内容
図１１は、本実施形態における第二の相関分析で監視対象とする、実行ファイルのダウンロードフェーズＰ４への遷移を示す図である。マルウェアふるまい検知エンジン２５は、「マルウェアの活動フェーズ判定」処理ブロックにおいて、端末（ｈ）が実行ファイルのダウンロードフェーズＰ４に遷移した際に、以下の分析を行い、該当する場合、通信パターンのグレードを補正する。

（２．２．１）探索フェーズＰ２から実行ファイルのダウンロードフェーズＰ４へ遷移
ｉｆ ｛条件Ａ ＝ ＴＲＵＥ｝ ｔｈｅｎ ｛Ｇｒ（ｈ， Ｐ４−ｍ） ＝ θ・Ｇｒ（ｈ， Ｐ４−ｍ）｝ （θ＝１．５）
ｉｆ ｛条件Ｂ ＝ ＴＲＵＥ｝ ｔｈｅｎ ｛Ｇｒ（ｈ， Ｐ４−ｍ） ＝ θ・Ｇｒ（ｈ， Ｐ４−ｍ）｝ （θ＝１．２）
・条件Ａ：端末（ｈ）で実行ファイルのダウンロードの通信パターンＰ４−ｍを観測、且つＰ４−ｍの接続先（宛先ＩＰ／ＦＱＤＮ）が感染元端末（ｋ）と一致した。
・条件Ｂ：端末（ｈ）で実行ファイルのダウンロードの通信パターンＰ４−ｍを観測、且つＰ４−ｍの接続先（宛先ＩＰ／ＦＱＤＮ）がマルウェア配布サーバー候補リストに登録されているサーバーの何れかと一致した。
なお、マルウェアに感染してから一定時間内に実行ファイルがダウンロードされるとは限らない場合がある（１０秒後もあれば、３日後のケースがある）ため、フェーズＰ２からフェーズＰ４への遷移では、時間に係る条件は入れない。

（２．２．２）Ｃ＆Ｃ通信フェーズＰ６から実行ファイルのダウンロードフェーズＰ４へ遷移
ｉｆ ｛条件Ｃ ＝ ＴＲＵＥ｝ ｔｈｅｎ ｛Ｇｒ（ｈ， Ｐ４−ｍ） ＝ θ・Ｇｒ（ｈ， Ｐ４−ｍ）｝ （θ＝１．２）
ｉｆ ｛条件Ｄ ＝ ＴＲＵＥ｝ ｔｈｅｎ ｛Ｇｒ（ｈ， Ｐ４−ｍ） ＝ θ・Ｇｒ（ｈ， Ｐ４−ｍ）｝ （θ＝１．５）
・条件Ｃ：端末（ｈ）のＣ＆Ｃサーバー候補リストに登録されているＣ＆Ｃサーバーの何れかでデータ通信（Ｃ＆Ｃサーバーから何らかのデータを受信）を観測してから、Ｎ（ｂ）秒以内に、端末（ｈ）で実行ファイルのダウンロードフェーズの通信パターンＰ４−ｍを観測した。
・条件Ｄ： 条件Ｃ且つＰ４−ｍの接続先（宛先ＩＰ／ＦＱＤＮ）がマルウェア配布サーバー候補リストに登録されているサーバーの何れかと一致した。
なお、Ｃ＆Ｃサーバーからデータ（指令）を受信した時刻は、「（２．１）探索フェーズＰ２への遷移時の分析内容」を参照。また、実行ファイルのダウンロードフェーズの通信パターンＰ４−ｍの観測時刻は、ＨＴＴＰ ＧＥＴリクエスト、ＦＴＰダウンロード、ＴＦＴＰダウンロードの開始時刻ではなく、ファイルのダウンロードが完了した時刻（ＨＴＴＰ ＧＥＴの場合は、レスポンスの最終パケット）とする。パケットロストが発生するため、ＨＴＴＰ ＧＥＴレスポンスの個々のパケット、ＦＴＰ／ＴＦＴＰのダウンロードパケットを検出するたびに時刻を更新してもよい。

（２．２．３）侵入フェーズＰ１から実行ファイルのダウンロードフェーズＰ４へ遷移
「マルウェアの活動フェーズ判定」処理ブロックにおいて、端末（ｈ）が実行ファイルのダウンロードフェーズＰ４に遷移した際に、以下に説明する相関分析を行い、相関性があると判定された場合、活動通信パターンのグレードが補正され、マルウェアに感染している（ドライブバイダウンロード攻撃を受けている）と判定される（図５から図８を参照）。相関性の有無は、侵入フェーズＰ１にマッピングされた通信Ｐ１−ｎと実行ファイルのダウンロードフェーズＰ４にマッピングされた通信Ｐ４−ｍの連続性および関連性に基づいて判定される。ここで、連続性は、コネクションの同一性、検出時刻の近さ、２つの通信パターンＰ１−ｎとＰ４−ｍの間に検出した他のパケットの有無等に基づいて判定され、関連性は、宛先サーバーのアドレス、宛先サーバーの情報の共通性等に基づいて判定される。

図１２は、本実施形態における、侵入フェーズＰ１に係る通信と実行ファイルのダウンロードフェーズＰ４に係る通信との相関性を判定するための相関分析処理の流れを示すフローチャートである。本フローチャートに示された処理は、図６および図７を用いて説明したマルウェアふるまい検知エンジンのステップＳ１１１からステップＳ１１６の処理に相当し、後述する図１６から図２０の処理において、侵入フェーズＰ１にマッピングされた通信および実行ファイルのダウンロードフェーズＰ４にマッピングされた通信が検出された場合に、当該端末においてドライブバイダウンロード攻撃が行われたことを検出するために実行される。

ステップＳ７０１からステップＳ７０３では、相関条件１から３を満たすか否かが判定される。相関条件１から３の何れも満たされない場合、本フローチャートに示された処理は終了する。一方、相関条件１から３の何れかが満たされた場合、処理はステップＳ７０４へ進む。相関条件１から３は、以下の通りである。

相関条件１：端末（ｈ）で通信パターンＰ１−ｍ（ｍ＝１〜５）を検出後、検出したＰ１−ｍと同一のＴＣＰコネクション上で、通信パターンＰ４−ｎ（ｎ＝１〜４）を検出した。
ｉｆ （条件 ＝ ＴＲＵＥ） ｔｈｅｎ ＰＧｒ（ｈ， Ｐ１） ＝ ０．３
ｉｆ （条件 ＝ ＴＲＵＥ） ｔｈｅｎ Ｇｒ（ｈ， Ｐ４−１〜Ｐ４−４） ＝ θ・Ｇｒ（ｈ， Ｐ４−１〜Ｐ４−４） （θ＝２．０）

相関条件２：端末（ｈ）でＰ１−ｍ（ｍ＝１〜５）を検出した直後に、検出したＰ１−ｍと同一のＦＱＤＮ／ＩＰアドレスをもつ通信パターンＰ４−ｎ（ｎ＝１〜４）を検出した。但し、Ｐ１−ｍとＰ４−ｎのＴＣＰコネクションは異なる。
ｉｆ （条件 ＝ ＴＲＵＥ） ｔｈｅｎ ＰＧｒ（ｈ， Ｐ１） ＝ ０．３
ｉｆ （条件 ＝ ＴＲＵＥ） ｔｈｅｎ Ｇｒ（ｈ， Ｐ４−１〜Ｐ４−４） ＝ θ・Ｇｒ（ｈ， Ｐ４−１〜Ｐ４−４） （θ＝２．０）

相関条件３：端末（ｈ）でＰ１−ｍ（ｍ＝１〜５）を検出した直後に、検出したＰ１−ｍと同一のＦＱＤＮ／ＩＰアドレスをもつ、ＩＥまたはＪａｖａ（登録商標）のＵｓｅｒ−Ａｇｅｎｔヘッダー値が設定された正常なＧＥＴリクエストを検出し、このＧＥＴリクエストは、唯一個のＧＥＴリクエストであり、且つ上記の正常なＧＥＴリクエスト（＆レスポンス）の直後に、検出したＰ１−ｍ（ｍ＝１〜５）と同一のＦＱＤＮ／ＩＰアドレスをもつ通信パターンＰ４−ｎ（ｎ＝１〜４）を検出した。但し、Ｐ１−ｍとＰ４−ｎのＴＣＰコネクションは異なる。
ｉｆ （条件 ＝ ＴＲＵＥ） ｔｈｅｎ ＰＧｒ（ｈ， Ｐ１） ＝ ０．３
ｉｆ （条件 ＝ ＴＲＵＥ） ｔｈｅｎ Ｇｒ（ｈ， Ｐ４−１〜Ｐ４−４） ＝ θ・Ｇｒ（ｈ， Ｐ４−１〜Ｐ４−４） （θ＝２．０）

ステップＳ７０４では、フェーズＰ１およびフェーズＰ４−ｍのグレードが補正される。補正部２５３は、例えば、フェーズＰ１のグレードを０．３に設定し、フェーズＰ４−ｍのグレードを２．０倍する、等の補正を行う。その後、本フローチャートに示された処理は終了し、最終的には閾値との比較によってマルウェア感染（ドライブバイダウンロード攻撃）の有無が判定される（図８に示す処理を参照）。

（２．３）Ｃ＆Ｃ検索フェーズＰ５への遷移時の分析内容
図１３は、本実施形態における第二の相関分析で監視対象とする、Ｃ＆Ｃ検索フェーズＰ５への遷移を示す図である。マルウェアふるまい検知エンジン２５は、「マルウェアの活動フェーズ判定」処理ブロックにおいて、端末（ｈ）がＣ＆Ｃ検索フェーズＰ５に遷移した際に、以下の分析を行い、該当する場合、通信パターンのグレードを補正する。

（２．３．１） 探索フェーズＰ２からＣ＆Ｃ検索フェーズＰ５へ遷移
ｉｆ ｛条件Ａ ＝ ＴＲＵＥ｝ ｔｈｅｎ ｛Ｇｒ（ｈ， Ｐ５−ｍ） ＝ θ・Ｇｒ（ｈ， Ｐ５−ｍ）｝ （θ＝１．２）
・条件Ａ： （感染させられた側の）端末（ｈ）で感染活動を観測（通信パターンＰ２−９またはＰ２−１０の接続先端末側）してから、Ｎ（ｃ）秒以内に、端末（ｈ）でＣ＆Ｃ検索フェーズの通信パターンＰ５−ｍを観測した。

（２．３．２）Ｃ＆Ｃ通信フェーズＰ６からＣ＆Ｃ検索フェーズＰ５へ遷移
ｉｆ ｛条件Ｂ ＝ ＴＲＵＥ｝ ｔｈｅｎ ｛Ｇｒ（ｈ， Ｐ５−ｍ） ＝ θ・Ｇｒ（ｈ， Ｐ５−ｍ）｝ （θ＝１．３）
・条件Ｂ：端末（ｈ）がＣ＆Ｃ通信フェーズＰ６から、一定の周期（時間）でＣ＆Ｃ検索フェーズＰ５に遷移（Ｃ＆Ｃ検索フェーズＰ５の通信パターンＰ５−ｍを検出）を繰り返した。
なお、本実施形態では、過去３回の遷移がほぼ同じ周期（時間）である場合に、一定の周期でＣ＆Ｃ検索フェーズＰ５への遷移を繰り返したと判断される。

（２．４）Ｃ＆Ｃ通信フェーズＰ６への遷移時の分析内容
図１４は、本実施形態における第二の相関分析で監視対象とする、Ｃ＆Ｃ通信フェーズＰ６への遷移を示す図である。マルウェアふるまい検知エンジン２５は、「マルウェアの活動フェーズ判定」処理ブロックにおいて、端末（ｈ）がＣ＆Ｃ通信フェーズＰ６に遷移した際に、以下の分析を行い、該当する場合、通信パターンのグレードを補正する。

（２．４．１） 探索フェーズＰ２からＣ＆Ｃ通信フェーズＰ６へ遷移
ｉｆ ｛条件Ａ ＝ ＴＲＵＥ｝ ｔｈｅｎ ｛Ｇｒ（ｈ， Ｐ６−ｍ） ＝ θ・Ｇｒ（ｈ， Ｐ６−ｍ）｝ （θ＝１．１）
ｉｆ ｛条件Ｂ ＝ ＴＲＵＥ｝ ｔｈｅｎ ｛Ｇｒ（ｈ， Ｐ６−ｍ） ＝ θ・Ｇｒ（ｈ， Ｐ６−ｍ）｝ （θ＝１．２）
ｉｆ ｛条件Ｃ ＝ ＴＲＵＥ｝ ｔｈｅｎ ｛Ｇｒ（ｈ， Ｐ６−ｍ） ＝ θ・Ｇｒ（ｈ， Ｐ６−ｍ）｝ （θ＝１．５）
・条件Ａ：端末（ｈ）で感染活動を観測（通信パターンＰ２−９またはＰ２−１０の感染先端末側）を観測してから、Ｎ（ｄ）秒以内に、端末（ｈ）でＣ＆Ｃ通信フェーズＰ６の通信パターンＰ６−ｍを観測した。
・条件Ｂ： 条件Ａ且つＰ６−ｍの接続先（宛先ＩＰ／ＦＱＤＮ）が（任意の監視対象端末の）Ｃ＆Ｃサーバー候補リストに登録されているＣ＆Ｃサーバーの何れかと一致した。
・条件Ｃ： 条件Ａ且つＰ６−ｍの接続先（宛先ＩＰ／ＦＱＤＮ）が感染元端末（ｋ）のＣ＆Ｃサーバー候補リストに登録されているＣ＆Ｃサーバーの何れかと一致した。

（２．４．２）実行ファイルのダウンロードフェーズＰ４からＣ＆Ｃ通信フェーズＰ６へ遷移
ｉｆ ｛条件Ｄ ＝ ＴＲＵＥ｝ ｔｈｅｎ ｛Ｇｒ（ｈ， Ｐ６−ｍ） ＝ θ・Ｇｒ（ｈ， Ｐ６−ｍ）｝ （θ＝１．１）
ｉｆ ｛条件Ｅ ＝ ＴＲＵＥ｝ ｔｈｅｎ ｛Ｇｒ（ｈ， Ｐ６−ｍ） ＝ θ・Ｇｒ（ｈ， Ｐ６−ｍ）｝ （θ＝１．２）
ｉｆ ｛条件Ｆ ＝ ＴＲＵＥ｝ ｔｈｅｎ ｛Ｇｒ（ｈ， Ｐ６−ｍ） ＝ θ・Ｇｒ（ｈ， Ｐ６−ｍ）｝ （θ＝１．３）
・条件Ｄ：端末（ｈ）で実行ファイルのダウンロードの通信パターンＰ４−ｍを観測してから、Ｎ（ｅ）秒以内に、端末（ｈ）でＣ＆Ｃ通信フェーズの通信パターンＰ６−ｍを観測した。
・条件Ｅ： 条件Ｄ且つＰ６−ｍの接続先（宛先ＩＰ／ＦＱＤＮ）が（任意の監視対象端末の）Ｃ＆Ｃサーバー候補リストに登録されているＣ＆Ｃサーバーの何れかと一致した。
・条件Ｆ： 条件Ｄ且つＰ６−ｍの接続先（宛先ＩＰ／ＦＱＤＮ）が端末（ｈ）のＣ＆Ｃサーバー候補リストに既に登録済みのＣ＆Ｃサーバーの何れかと一致した。

（２．４．３） Ｃ＆Ｃ検索フェーズＰ５からＣ＆Ｃ通信フェーズＰ６へ遷移
ｉｆ ｛条件Ｇ ＝ ＴＲＵＥ｝ ｔｈｅｎ ｛Ｇｒ（ｈ， Ｐ６−ｍ） ＝ θ・Ｇｒ（ｈ， Ｐ６−ｍ）｝ （θ＝１．２）
・条件Ｇ：端末（ｈ）でＣ＆Ｃ検索フェーズの通信パターンＰ５−ｍを観測してから、Ｎ（ｆ）秒以内に、端末（ｈ）でＣ＆Ｃ通信フェーズの通信パターンＰ６−ｍを観測、且つＰ６−ｍの接続先（宛先ＩＰ／ＦＱＤＮ）が（任意の監視対象端末の）Ｃ＆Ｃサーバー候補リストに登録されているＣ＆Ｃサーバーの何れかと一致した。

（２．５）攻撃フェーズＰ８への遷移時の分析内容
図１５は、本実施形態における第二の相関分析で監視対象とする、攻撃フェーズＰ８への遷移を示す図である。マルウェアふるまい検知エンジン２５は、「マルウェアの活動フェーズ判定」処理ブロックにおいて、端末（ｈ）がＣ＆Ｃ通信フェーズＰ６に遷移した際に、以下の分析を行い、該当する場合、通信パターンのグレードを補正する。

（２．５．１）実行ファイルのダウンロードフェーズＰ４から攻撃フェーズＰ８へ遷移
ｉｆ ｛条件Ａ ＝ ＴＲＵＥ｝ ｔｈｅｎ ｛Ｇｒ（ｈ， Ｐ８−ｍ） ＝ θ・Ｇｒ（ｈ， Ｐ８−ｍ）｝ （θ＝１．２）
・条件Ａ：端末（ｈ）で実行ファイルのダウンロードの通信パターンＰ４−ｍを観測してから、Ｎ（ｇ）秒以内に、端末（ｈ）で攻撃フェーズの通信パターンＰ８−ｍを観測した。

（２．５．２） Ｃ＆Ｃ通信フェーズＰ６から攻撃フェーズＰ８へ遷移
ｉｆ ｛条件Ｂ ＝ ＴＲＵＥ｝ ｔｈｅｎ ｛Ｇｒ（ｈ， Ｐ８−ｍ） ＝ θ・Ｇｒ（ｈ， Ｐ８−ｍ）｝ （θ＝１．２）
ｉｆ ｛条件Ｃ ＝ ＴＲＵＥ｝ ｔｈｅｎ ｛Ｇｒ（ｈ， Ｐ８−ｍ） ＝ θ・Ｇｒ（ｈ， Ｐ８−ｍ）｝ （θ＝１．５）
・条件Ｂ：端末（ｈ）のＣ＆Ｃサーバー候補リストに登録されているＣ＆Ｃサーバーの何れかでデータ通信（Ｃ＆Ｃサーバーから何らかのデータ（指令）を受信）を観測してから、Ｎ（ｈ）秒以内に、端末（ｈ）で攻撃フェーズの通信パターンＰ８−ｍを観測した。
・条件Ｃ： 条件Ｂを満足する２台以上の端末を検出した。（同時に発生する必要はない）

＜ドライブバイダウンロード攻撃の検出−概要＞
ここで、上記説明した活動遷移モデルおよび相関分析を用いた、ドライブバイダウンロード攻撃の検出について説明する。

従来、組織や個人の機密情報を搾取する目的で実行される標的型攻撃等で利用される攻撃手法の一つに、所謂ドライブバイダウンロード攻撃がある。従来、ドライブバイダウンロード攻撃を検出するために、ファイル／コンテンツ自体の悪性（不正なコードや攻撃コードの有無）を解析する手法が用いられている。しかし、このような手法では、膨大なログの解析を行う必要があり、また、攻撃者が攻撃に用いるトラフィック量を抑えた場合、誤検知の可能性が高まるという問題があった。

本開示は、上記した問題に鑑み、従来の手法に比べて軽量な手法でネットワーク端末における所定の活動を検出することを課題とする。

ここで、ドライブバイダウンロード攻撃は、例えば、以下の流れで実行される。
１．準備段階
攻撃者は、標的がアクセスする正規のウェブサイトを改ざんして、攻撃サーバーへ誘導（リダイレクト）するリンクを挿入する。
２．攻撃サーバーへの誘導
標的が改ざんされたサイトにアクセスすると、標的は、サイトに埋め込まれた「攻撃サーバーへ誘導するリンク」に従って、攻撃サーバーまで誘導される。
３．悪性コンテンツのダウンロード
攻撃サーバーから、標的に対して、標的が使用するウェブブラウザや各種プラグイン・ソフトウェアの脆弱性を利用する悪性コンテンツが送り込まれる。
４．マルウェア本体のダウンロード
悪性コンテンツによる脆弱性を利用した攻撃が成功すると、標的に対してダウンロードコードが読み込まれ、ダウンロードコードにより、標的に対してマルウェア本体が自動的にダウンロードされる。

そこで、本実施形態では、ドライブバイダウンロード攻撃が、「悪性コンテンツのダウンロード」と「マルウェア本体のダウンロード」の２つの通信が連続して発生すること、および「悪性コンテンツのダウンロード」と「マルウェア本体のダウンロード」の２つの通信では、異なる種類のファイルが使用されることに着目して、マルウェアふるまい検知エンジンを用いて、各通信においてダウンロードされるファイル／コンテンツの種類、および２つの通信のフェーズ遷移に基づいて攻撃を検知することとした。

なお、本実施形態では、上述の通り、「悪性コンテンツのダウンロード」の通信パターンが侵入フェーズＰ１に、「マルウェア本体のダウンロード」の通信パターンが実行ファイルのダウンロードフェーズＰ４にマッピングされている。

以下、本実施形態に係るシステム１によって実行される処理の流れを、フローチャートを用いて説明する。なお、以下に説明するフローチャートに示された処理の具体的な内容および処理順序は、本発明を実施するための一例である。具体的な処理内容および処理順序は、本発明の実施の形態に応じて適宜選択されてよい。

＜ドライブバイダウンロード攻撃の検出−悪性コンテンツの侵入判定＞
はじめに、通信が「悪性コンテンツのダウンロード」の通信パターンに該当し、端末が侵入フェーズＰ１にあることを決定するための処理を説明する。

図１６は、本実施形態に係る、マルウェアふるまい検知エンジン２５によるコンテンツリクエスト解析処理の流れを示すフローチャートである。本フローチャートは、図５を用いて説明した検知処理のステップＳ００６の処理、換言すれば、図６を用いて説明した処理のステップＳ１０１からステップＳ１０３の処理に相当する。

ステップＳ２０１では、取得されたデータ（１または複数の入力パケットの組み合わせ）が、ＨＴＴＰのＧＥＴ／ＰＯＳＴ／ＰＵＳＨリクエストに該当するか否かが判定される。比較部２５１は、取得データと予め保持された通信パターン（ここでは、ＨＴＴＰのＧＥＴ／ＰＯＳＴ／ＰＵＳＨリクエストのデータパターン）とを比較することで、取得データと予め定義された通信パターン（Ｐ１−ｍ）との共通性を判定する。判定の結果、取得データがＨＴＴＰのＧＥＴ／ＰＯＳＴ／ＰＵＳＨリクエストではないと判定された場合、当該取得データに係る処理は終了し、本フローチャートに示された処理は終了する。一方、取得データがＨＴＴＰのＧＥＴ／ＰＯＳＴ／ＰＵＳＨリクエストであると判定された場合、処理はステップＳ２０２へ進む。

ステップＳ２０２では、取得データ（ＨＴＴＰのＧＥＴ／ＰＯＳＴ／ＰＵＳＨリクエスト）のＵＲＩパス部のファイル名が、所定の拡張子を含むか否かが判定される。比較部２５１は、取得データ（ＨＴＴＰのＧＥＴ／ＰＯＳＴ／ＰＵＳＨリクエスト）のＵＲＩパス部のファイル名の文字列と、予め保持された拡張子の文字列（例えば、“．ｊａｒ”，“．ｃｌａｓｓ”，“．ｘａｐ”，“．ｓｗｆ”，“．ｐｄｆ”の何れか）とを比較することで、取得データと予め定義された通信パターン（Ｐ１−ｍ）との共通性を判定する。判定の結果、ＵＲＩパス部のファイル名が所定の拡張子を含むと判定された場合、処理はステップＳ２０４へ進む。一方、ＵＲＩパス部のファイル名が所定の拡張子を含まないと判定された場合、処理はステップＳ２０３へ進む。

ステップＳ２０３では、取得データ（ＨＴＴＰのＧＥＴ／ＰＯＳＴ／ＰＵＳＨリクエスト）のヘッダーが、予め定義された通信パターンの何れに該当するかが判定される。比較部２５１は、取得データと予め保持された通信パターン（ここでは、リクエストされたファイルが所定の種類のファイルである場合にヘッダーに含まれ得るデータパターン）とを比較することで、取得データと予め定義された通信パターン（Ｐ１−ｍ）との共通性を判定する。これは、ステップＳ２０２において、リクエストに係るファイル名が所定の拡張子を含まない場合にも、拡張子が改ざんされている可能性があるため、攻撃者が改ざん困難である情報に基づいて、リクエストに係るファイルの種類を正確に判定するための処理である。判定の結果、取得データが悪性コンテンツのリクエストに係る特徴を含まないと判定された場合、当該取得データに係る処理は終了し、本フローチャートに示された処理は終了する。一方、取得データが悪性コンテンツのリクエストに係る特徴を含むと判定された場合、処理はステップＳ２０４へ進む。

ステップＳ２０４では、各種のコンテンツレスポンス解析処理が実行される。マルウェアふるまい検知エンジン２５は、ステップＳ２０２またはステップＳ２０３において、リクエストされたファイルの種類が所定のファイル種別であると判定された通信について、レスポンスを監視し、当該ファイル種別への該当性を判定する。コンテンツレスポンス解析処理は、ファイル種別毎に用意されてよい。本実施形態では、例えば、Ｊａｖａコンテンツレスポンス解析処理、ＰＤＦコンテンツレスポンス解析処理、Ｓｉｌｖｅｒｌｉｇｈｔコンテンツレスポンス解析処理、Ｆｌａｓｈコンテンツレスポンス解析処理およびＨＴＭＬコンテンツレスポンス解析処理が用意される。但し、コンテンツレスポンス解析処理は、当該通信が侵入フェーズＰ１の通信であるか否かを判定するために必要なファイル種別について用意されればよく、本実施形態において例示されたファイル種別に限定されない。コンテンツレスポンス解析処理が実行されると、本フローチャートに示された処理は終了する。

具体的には、ステップＳ２０２またはステップＳ２０３における判定の結果毎に、以下のコンテンツレスポンス解析処理が実行される。以下に列挙された条件は、ステップＳ２０２またはステップＳ２０３における判定用に予め定義された通信パターン（Ｐ１−ｍ）である。
Ｊａｖａコンテンツレスポンス解析処理：
・ＵＲＩパス部のファイル名が拡張子“．ｊａｒ”若しくは“．ｃｌａｓｓ”を含む、または
・ＪａｖａのＵｓｅｒ−ＡｇｅｎｔヘッダーおよびＡｃｃｅｐｔ−Ｅｎｃｏｄｉｎｇヘッダーが設定されている。
ＰＤＦコンテンツレスポンス解析処理：
・ＵＲＩパス部のファイル名が拡張子“．ｐｄｆ”を含む、または
・ブラウザのＵｓｅｒ−Ａｇｅｎｔヘッダーが設定されており、且つ
・・Ａｃｃｅｐｔ−ＬａｎｇｕａｇｅとＲｅｆｅｒｅｒヘッダーが設定されていない、または
・・ＵＲＩのパス部に任意のファイル拡張子を含まず、クエリ部が設定されている。
Ｓｉｌｖｅｒｌｉｇｈｔコンテンツレスポンス解析処理：
・ＵＲＩパス部のファイル名が拡張子“．ｘａｐ”を含む、または
・ブラウザのＵｓｅｒ−Ａｇｅｎｔヘッダーが設定されており、且つ
・・Ａｃｃｅｐｔ−ＬａｎｇｕａｇｅとＲｅｆｅｒｅｒヘッダーが設定されていない、または
・・ＵＲＩのパス部に任意のファイル拡張子を含まず、クエリ部が設定されている。
Ｆｌａｓｈコンテンツレスポンス解析処理：
・ＵＲＩパス部のファイル名が拡張子“．ｓｗｆ”を含む、または
・ブラウザのＵｓｅｒ−Ａｇｅｎｔヘッダーが設定されており、且つ
・・Ａｃｃｅｐｔ−ＬａｎｇｕａｇｅとＲｅｆｅｒｅｒヘッダーが設定されていない、
・・ｘ−ｆｌａｓｈ−ｖｅｒｓｉｏｎヘッダーが設定されている、
・・ＵＲＩのパス部にファイル拡張子“．ｐｈｐ”，“．ａｓｐ”，“．ａｓｐｘ”，“．ｃｇｉ”を含む、または
・・ＵＲＩのパス部に任意のファイル拡張子を含まず、クエリ部が設定されている。
ＨＴＭＬコンテンツレスポンス解析処理
・ブラウザのＵｓｅｒ−Ａｇｅｎｔヘッダーが設定されており、且つ
・・ＵＲＩのパス部にファイル拡張子“．ｐｈｐ”，“．ａｓｐ”，“．ａｓｐｘ”，“．ｃｇｉ”を含む、
・・ＵＲＩのパス部に任意のファイル拡張子を含まず、クエリ部が設定されている、
・・ＵＲＩにパス部が設定されておらず、クエリ部が設定されている、または
・・ＵＲＩのパス部にファイル拡張子“．ｈｔｍ”または“．ｈｔｍｌ”を含み、ＵＲＩにクエリ部が設定されていない。

図１７は、本実施形態に係る、マルウェアふるまい検知エンジン２５によるコンテンツレスポンス解析処理の流れを示すフローチャートである。本フローチャートは、図１６を用いて説明したコンテンツリクエスト解析処理のステップＳ２０４の処理をより詳細に説明するものである。そして、本フローチャートは、図５を用いて説明した検知処理のステップＳ００６の処理、換言すれば、図６を用いて説明した処理のステップＳ１０１からステップＳ１０３の処理に相当する。また、先述の通り、本実施形態では、コンテンツレスポンス解析処理は、ファイル種別毎に用意されており、上記説明した条件が満たされた場合に、各ファイル種別のためのコンテンツレスポンス解析処理が実行される。

ステップＳ３０１およびステップＳ３０２では、ＨＴＴＰリクエストに対応するレスポンスパケットが監視され、レスポンスのＣｏｎｔｅｎｔ−Ｔｙｐｅヘッダーの内容が判定される。通信取得部２１は、上記コンテンツリクエスト解析処理で所定のファイル種別のファイルがリクエストされたと判定された通信と同じセッション／コネクション（例えば、ＴＣＰコネクション）におけるレスポンスパケット（戻りパケット）を監視する（ステップＳ３０１）。レスポンスパケットが取得されると、比較部２５１は、当該レスポンスのＣｏｎｔｅｎｔ−Ｔｙｐｅヘッダーに、リクエストされたファイル種別を示すタイプ値が設定されているか否かを判定することで、取得データと予め定義された通信パターン（Ｐ１−ｍ）との共通性を判定し、当該レスポンスに、リクエストされた種類のファイルが含まれているか否かを判定する（ステップＳ３０２）。例えば、Ｊａｖａコンテンツレスポンス解析処理が呼び出されている場合、比較部２５１は、レスポンスパケットのＣｏｎｔｅｎｔ−Ｔｙｐｅヘッダーに、Ｊａｖａのタイプ値が設定されているか否かを判定する。レスポンスパケットのＣｏｎｔｅｎｔ−Ｔｙｐｅヘッダーに、リクエストされたファイル種別を示すタイプ値が設定されていると判定された場合、処理はステップＳ３０４へ進む。一方、レスポンスパケットのＣｏｎｔｅｎｔ−Ｔｙｐｅヘッダーに、リクエストされたファイル種別を示すタイプ値が設定されていないと判定された場合、処理はステップＳ３０３へ進む。

ステップＳ３０３では、レスポンスのボディが、予め定義されたデータパターンに該当するか否かが判定される。比較部２５１は、取得データ（レスポンス）と予め保持されたデータパターン（ここでは、レスポンスが所定の種類のファイルを含む場合にレスポンスのボディに含まれ得るデータパターン）とを比較することで、取得データと予め定義された通信パターン（Ｐ１−ｍ）との共通性を判定し、当該レスポンスに、リクエストされた種類のファイルが含まれているか否かを判定する。これは、ステップＳ３０２において、レスポンスのＣｏｎｔｅｎｔ−Ｔｙｐｅヘッダーにリクエストされたファイル種別を示すタイプ値が設定されていない場合にも、Ｃｏｎｔｅｎｔ−Ｔｙｐｅヘッダーが改ざんされている可能性があるため、攻撃者が改ざん困難である情報に基づいて、レスポンスに係るファイルの種類を正確に判定するための処理である。判定の結果、レスポンスのＣｏｎｔｅｎｔ−Ｔｙｐｅヘッダーにリクエストされたファイル種別を示すタイプ値が設定されていないと判定された場合、当該取得データに係る処理は終了し、本フローチャートに示された処理は終了する。一方、レスポンスのＣｏｎｔｅｎｔ−Ｔｙｐｅヘッダーにリクエストされたファイル種別を示すタイプ値が設定されていると判定された場合、処理はステップＳ３０４へ進む。

なお、ステップＳ３０３では、例えば、所定の種類のコンテンツであることを示すためにコンテンツ内部に設定される所定のデータパターン（シグネチャ等）が、レスポンスのボディの先頭部分または所定位置に設定されているか否かが判定されることで、レスポンスのボディが所定の種類のコンテンツであるか否かが判定される。このようなシグネチャ等のデータパターンは、当該コンテンツを端末のアプリケーションに実行させるために、攻撃者も改ざんすることが困難なデータパターンであるため、より正確な判定を行うことが出来る。

ステップＳ３０４では、当該レスポンスおよびリクエストに係る端末に関して、該当すると判定された通信パターン（Ｐ１−ｍ）、即ち、「悪性コンテンツのダウンロード」が検出されたことが記録される。具体的には、ＨＴＴＰリクエストヘッダーの種類と値、宛先ＩＰアドレス、宛先ＦＱＤＮ、ファイル（パッケージ）の名前、サイズ、および検出時刻が記録される。また、決定部２５４は、当該リクエストおよびレスポンスに係る通信を行った端末の活動フェーズを侵入フェーズＰ１に決定し、評価値取得部２５２は、入力パケットに対応する通信パターン（Ｐ１−ｍ）が属するフェーズＰ１および通信パターン（Ｐ１−ｍ）に予め設定されているグレードＧｒ（Ｐ１−ｍ）を、入力パケットに係る端末（ｈ）のフェーズＰ１（ｈ）、および当該フェーズのグレードＧｒ（ｈ， Ｐ１−ｍ）として取得する。その後、本フローチャートに示された処理は終了する。

図１７を用いて説明したコンテンツレスポンス解析処理は、上述の通りファイル種別毎に用意されるが（例えば、Ｊａｖａコンテンツレスポンス解析処理、ＰＤＦコンテンツレスポンス解析処理、Ｓｉｌｖｅｒｌｉｇｈｔコンテンツレスポンス解析処理およびＦｌａｓｈコンテンツレスポンス解析処理）、判定のための具体的なデータパターン等を除いて、処理の流れは概略同様である。但し、ＨＴＭＬコンテンツレスポンス解析処理については、他のコンテンツレスポンス解析処理とは異なる処理の流れが採用されてよい。

図１８は、本実施形態に係る、マルウェアふるまい検知エンジン２５によるＨＴＭＬコンテンツレスポンス解析処理の流れを示すフローチャートである。本フローチャートは、図１６を用いて説明したコンテンツリクエスト解析処理のステップＳ２０４において、ＨＴＭＬコンテンツレスポンス解析処理が呼び出された場合の処理をより詳細に説明するものである。そして、本フローチャートは、図５を用いて説明した検知処理のステップＳ００６の処理、換言すれば、図６を用いて説明した処理のステップＳ１０１からステップＳ１０３の処理に相当する。

ステップＳ４０１およびステップＳ４０２では、ＨＴＴＰリクエストに対応するレスポンスパケットが監視され、レスポンスのＣｏｎｔｅｎｔ−Ｔｙｐｅヘッダーの内容が判定される。通信取得部２１は、上記コンテンツリクエスト解析処理でＨＴＭＬファイルがリクエストされたと判定された通信と同じセッション／コネクションにおけるレスポンスパケットを監視する（ステップＳ４０１）。レスポンスパケットが取得されると、比較部２５１は、当該レスポンスのＣｏｎｔｅｎｔ−Ｔｙｐｅヘッダーに、ＨＴＭＬファイルのタイプ値が設定されているか否かを判定することで、取得データと予め定義された通信パターン（Ｐ１−ｍ）との共通性を判定し、当該レスポンスにＨＴＭＬファイルが含まれているか否かを判定する（ステップＳ４０２）。レスポンスパケットのＣｏｎｔｅｎｔ−ＴｙｐｅヘッダーにＨＴＭＬのタイプ値が設定されていないと判定された場合、本フローチャートに示された処理は終了する。一方、レスポンスパケットのＣｏｎｔｅｎｔ−ＴｙｐｅヘッダーにＨＴＭＬのタイプ値が設定されていると判定された場合、処理はステップＳ４０３へ進む。

ステップＳ４０３では、レスポンスのボディが、予め定義されたＨＴＭＬファイルのデータパターンに該当するか否かが判定される。比較部２５１は、取得データ（レスポンス）と、レスポンスがＨＴＭＬファイルを含む場合にレスポンスのボディに含まれ得るデータパターンとを比較することで、取得データと予め定義された通信パターン（Ｐ１−ｍ）との共通性を判定し、当該レスポンスにＨＴＭＬファイルが含まれているか否かを判定する。これは、ステップＳ４０２において、レスポンスのＣｏｎｔｅｎｔ−ＴｙｐｅヘッダーにＨＴＭＬのタイプ値が設定されている場合にも、他の種別のファイルがＨＴＭＬファイルに偽装されている可能性があるため、攻撃者が改ざん困難である情報に基づいて、レスポンスに係るファイルの種類を正確に判定するための処理である。判定の結果、レスポンスのＣｏｎｔｅｎｔ−ＴｙｐｅヘッダーにＨＴＭＬのタイプ値が設定されていないと判定された場合、当該取得データに係る処理は終了し、本フローチャートに示された処理は終了する。一方、レスポンスのＣｏｎｔｅｎｔ−ＴｙｐｅヘッダーにＨＴＭＬのタイプ値が設定されていると判定された場合、処理はステップＳ４０４へ進む。

ステップＳ４０４では、当該レスポンスおよびリクエストに係る端末に関して、該当すると判定された通信パターン（Ｐ１−ｍ）、即ち、「悪性コンテンツのダウンロード」が検出されたことが記録される。具体的には、ＨＴＴＰリクエストヘッダーの種類と値、宛先ＩＰアドレス、宛先ＦＱＤＮ、ファイル（パッケージ）の名前、サイズ、および検出時刻が記録される。また、決定部２５４は、当該リクエストおよびレスポンスに係る通信を行った端末の活動フェーズを侵入フェーズＰ１に決定し、評価値取得部２５２は、入力パケットに対応する通信パターン（Ｐ１−ｍ）が属するフェーズＰ１および通信パターン（Ｐ１−ｍ）に予め設定されているグレードＧｒ（Ｐ１−ｍ）を、入力パケットに係る端末（ｈ）のフェーズＰ１（ｈ）、および当該フェーズのグレードＧｒ（ｈ， Ｐ１−ｍ）として取得する。その後、本フローチャートに示された処理は終了する。

＜ドライブバイダウンロード攻撃の検出−マルウェア本体の侵入判定＞
次に、通信が「マルウェア本体のダウンロード」の通信パターンに該当し、端末が実行ファイルのダウンロードフェーズＰ４にあることを決定するための処理を説明する。

図１９は、本実施形態に係る、マルウェアふるまい検知エンジン２５による実行ファイルリクエスト解析処理の流れを示すフローチャートである。本フローチャートは、図５を用いて説明した検知処理のステップＳ００６の処理、換言すれば、図６を用いて説明した処理のステップＳ１０１からステップＳ１０３の処理に相当する。

ステップＳ５０１では、取得されたデータ（１または複数の入力パケットの組み合わせ）が、ＨＴＴＰのＧＥＴ／ＰＯＳＴ／ＰＵＳＨリクエストに該当するか否かが判定される。比較部２５１は、取得データと予め保持された通信パターン（ここでは、ＨＴＴＰのＧＥＴ／ＰＯＳＴ／ＰＵＳＨリクエストのデータパターン）とを比較することで、取得データと予め定義された通信パターン（Ｐ４−ｍ）との共通性を判定する。判定の結果、取得データがＨＴＴＰのＧＥＴ／ＰＯＳＴ／ＰＵＳＨリクエストではないと判定された場合、当該取得データに係る処理は終了し、本フローチャートに示された処理は終了する。一方、取得データがＨＴＴＰのＧＥＴ／ＰＯＳＴ／ＰＵＳＨリクエストであると判定された場合、処理はステップＳ５０２へ進む。

ステップＳ５０２では、取得データ（ＨＴＴＰのＧＥＴ／ＰＯＳＴ／ＰＵＳＨリクエスト）が、予め定義された通信パターンの何れに該当するかが判定される。比較部２５１は、取得データと予め保持された通信パターン（ここでは、リクエストされたファイルが実行ファイルである場合にリクエストに含まれ得るデータパターン）とを比較することで、取得データと予め定義された通信パターン（Ｐ４−ｍ）との共通性を判定する。これは、攻撃者が改ざん困難である情報に基づいて、リクエストに係るファイルの種類が実行ファイルであるか否かを正確に判定するための処理である。判定の結果、取得データが実行ファイルのリクエストに係る特徴を含まないと判定された場合、当該取得データに係る処理は終了し、本フローチャートに示された処理は終了する。一方、取得データが実行ファイルのリクエストに係る特徴を含むと判定された場合、処理はステップＳ５０３へ進む。

具体的には、以下に列挙する何れかの条件を満たす場合、比較部２５１は、取得データが実行ファイルのリクエストに係る特徴を含むと判定する。但し、以下に列挙する条件は一例であり、判定のための条件は本実施形態における例示に限定されない。
・ＨＴＴＰリクエストヘッダーにＪａｖａのＵｓｅｒ−Ａｇｅｎｔかつ、Ａｃｃｅｐｔ−Ｅｎｃｏｄｉｎｇヘッダーが設定されていない。
・ＨＴＴＰリクエストが疑わしいＨＴＴＰ通信パターンに一致する。
・ＨＴＴＰリクエストヘッダーにＨｏｓｔまたは、ＨｏｓｔとＣｏｎｎｅｃｔｉｏｎヘッダーが設定されており、Ｕｓｅｒ−Ａｇｅｎｔ、Ａｃｃｅｐｔ系のヘッダーが設定されていない。
・ブラウザのＵｓｅｒ−Ａｇｅｎｔが設定されており、かつ、ブラウザの通常のリクエストヘッダーと異なる構成のリクエストヘッダーである（「ブラウザの通常のリクエストヘッダーとは異なるヘッダーの構成」とは、通常設定されているヘッダーが設定されていないケースを示す）。
・Ｕｓｅｒ−Ａｇｅｎｔが設定されていない、またはＣｏｎｎｅｃｔｉｏｎが設定されていない。
・Ｈｏｓｔヘッダーの値がＩＰアドレスまたはＨＴＴＰ非標準のポート番号が設定されている。
・ＵＲＩパス部のファイル拡張子が、“．ｐｈｐ”，“．ａｓｐ”，“．ａｓｐｘ”，“．ｃｇｉ”を含む、かつ、Ｒｅｆｅｒｅｒまたは、Ｃｏｏｋｉｅヘッダーが設定されていない。

ステップＳ５０３では、実行ファイルレスポンス解析処理が実行される。マルウェアふるまい検知エンジン２５は、ステップＳ５０２において、リクエストされたファイルが実行ファイルであると判定された通信について、レスポンスを監視し、レスポンスに係るファイルが実行ファイルであるか否かを判定する。実行ファイルレスポンス解析処理が実行されると、本フローチャートに示された処理は終了する。

図２０は、本実施形態に係る、マルウェアふるまい検知エンジン２５による実行ファイルレスポンス解析処理の流れを示すフローチャートである。本フローチャートは、図１９を用いて説明した実行ファイルレスポンス解析処理のステップＳ５０３の処理をより詳細に説明するものである。そして、本フローチャートは、図５を用いて説明した検知処理のステップＳ００６の処理、換言すれば、図６を用いて説明した処理のステップＳ１０１からステップＳ１０３の処理に相当する。

ステップＳ６０１およびステップＳ６０２では、ＨＴＴＰリクエストに対応するレスポンスパケットが監視され、レスポンスのＣｏｎｔｅｎｔ−Ｔｙｐｅヘッダーの内容が判定される。通信取得部２１は、上記実行ファイルリクエスト解析処理で実行ファイルがリクエストされたと判定された通信と同じセッション／コネクションにおけるレスポンスパケットを監視する（ステップＳ６０１）。レスポンスパケットが取得されると、比較部２５１は、当該レスポンスのＣｏｎｔｅｎｔ−Ｔｙｐｅヘッダーに実行ファイルのタイプ値が設定されているか否かを判定することで、取得データと予め定義された通信パターン（Ｐ４−ｍ）との共通性を判定し、当該レスポンスに実行ファイルが含まれているか否かを判定する（ステップＳ６０２）。レスポンスパケットのＣｏｎｔｅｎｔ−Ｔｙｐｅヘッダーに、実行ファイルを示すタイプ値が設定されていると判定された場合、処理はステップＳ６０４へ進む。一方、レスポンスパケットのＣｏｎｔｅｎｔ−Ｔｙｐｅヘッダーに、実行ファイルを示すタイプ値が設定されていないと判定された場合、処理はステップＳ６０３へ進む。

ステップＳ６０３では、レスポンスのヘッダーまたはボディが、予め定義されたデータパターンに該当するか否かが判定される。比較部２５１は、取得データ（レスポンス）と予め保持されたデータパターン（ここでは、レスポンスが実行ファイルを含む場合にレスポンスのヘッダーまたはボディに含まれ得るデータパターン）とを比較することで、取得データと予め定義された通信パターン（Ｐ４−ｍ）との共通性を判定し、当該レスポンスに実行ファイルが含まれているか否かを判定する。これは、ステップＳ６０２において、レスポンスのＣｏｎｔｅｎｔ−Ｔｙｐｅヘッダーに実行ファイルを示すタイプ値が設定されていない場合にも、Ｃｏｎｔｅｎｔ−Ｔｙｐｅヘッダーが改ざんされている可能性があるため、攻撃者が改ざん困難である情報に基づいて、レスポンスに係るファイルの種類を正確に判定するための処理である。判定の結果、レスポンスのヘッダーまたはボディに実行ファイルを示す値が設定されていないと判定された場合、当該取得データに係る処理は終了し、本フローチャートに示された処理は終了する。一方、レスポンスのヘッダーまたはボディに実行ファイルを示す値が設定されていると判定された場合、処理はステップＳ６０４へ進む。

なお、ステップＳ６０３では、例えば、所定のアプリケーションで実行可能な実行ファイルであることを示すためにファイル内部に設定される所定のデータパターン（シグネチャ等）が、レスポンスのボディの先頭部分または所定位置に設定されているか否かが判定されることで、レスポンスのボディが実行ファイルであるか否かが判定される。このようなシグネチャ等のデータパターンは、当該実行ファイルを端末のアプリケーションに実行させるために、攻撃者も改ざんすることが困難なデータパターンであるため、より正確な判定を行うことが出来る。

ステップＳ６０４では、当該レスポンスおよびリクエストに係る端末に関して、該当すると判定された通信パターン（Ｐ４−ｍ）、即ち、「実行ファイルのダウンロード」が検出されたことが記録される。また、決定部２５４は、当該リクエストおよびレスポンスに係る通信を行った端末の活動フェーズを実行ファイルのダウンロードフェーズＰ４に決定し、評価値取得部２５２は、入力パケットに対応する通信パターン（Ｐ４−ｍ）が属するフェーズＰ４および通信パターン（Ｐ４−ｍ）に予め設定されているグレードＧｒ（Ｐ４−ｍ）を、入力パケットに係る端末（ｈ）のフェーズＰ４（ｈ）、および当該フェーズのグレードＧｒ（ｈ， Ｐ４−ｍ）として取得する。その後、本フローチャートに示された処理は終了する。

即ち、上記説明したコンテンツリクエスト解析処理、コンテンツレスポンス解析処理、実行ファイルリクエスト解析処理および実行ファイルレスポンス解析処理によれば、ＨＴＴＰのトラフィックにおいて、特定の条件を満たすリクエストとこれに対応するレスポンスが監視および解析されることで、「悪性コンテンツのダウンロード」または「マルウェア本体のダウンロード」の可能性があるＨＴＴＰ通信パターンが抽出される。そして、抽出された通信は、「端末が不正な活動（マルウェアの活動）をしていると推測される程度」を示すグレードが付与された上で、侵入フェーズＰ１、または実行ファイルのダウンロードフェーズＰ４にマッピングされる。また、フェーズにマッピングされた通信ごとに、宛先（＝攻撃サーバー）ＦＱＤＮ／ＩＰアドレス、ＨＴＴＰリクエストのヘッダー情報（メソッド種別、ＵＲＩパス情報、Ｈｏｓｔヘッダー、Ｕｓｅｒ−Ａｇｅｎｔヘッダー等）、ダウンロードしたファイル種別、ファイルサイズ、検出時刻等の情報が記録される。

＜ドライブバイダウンロード攻撃の検出−相関分析＞
上述の処理によって、実行ファイルのダウンロードフェーズＰ４に該当する通信パターンが検出されると、本実施形態では、侵入フェーズＰ１にマッピングされた通信と実行ファイルのダウンロードフェーズＰ４にマッピングされた通信の相関分析が実行される（図１２を参照）。図１２に示された相関分析処理において相関性有りと判定された場合、所定のルールに基づいてグレードの補正が行われ、最終的にマルウェア感染（ドライブバイダウンロード攻撃）の有無が判定される（図８に示す処理を参照）。

従来、「悪性コンテンツのダウンロード」の通信パターンや「マルウェア本体のダウンロード」の通信パターンを検出する場合には、ネットワーク上を流れるすべてのトラフィックを検査してファイルの有無を判定する必要があったが、本実施形態において上記に説明した処理によれば、大量に流れるＨＴＴＰパケットの中から「特定の条件を満たすＨＴＴＰリクエストおよびレスポンス」を抽出して相関分析することで、従来に比べて小さな計算コストで、リアルタイムにドライブバイダウンロード攻撃を検出することが出来る。

＜バリエーション＞
上記実施形態では、ネットワーク監視装置２０が、スイッチまたはルータのモニタリングポート（ミラーポート）に接続されることでノード９０によって送受信されるパケットやフレーム等を取得し、取得したパケットを転送しないパッシブモードで動作する例について説明した（図１を参照）。但し、上記実施形態に示したネットワーク構成は、本開示を実施するための一例であり、実施にあたってはその他のネットワーク構成が採用されてもよい。

例えば、ネットワーク監視装置２０は、モニタリングポート（ミラーポート）に接続されず、単にネットワークセグメント２に接続されている場合であっても、ネットワークセグメント２を流れるフレームを、自身のＭＡＣアドレス宛でないものも含めて全て取得することで、ノード９０によって送受信されるパケットやフレーム等を取得することが出来る。この場合も、ネットワーク監視装置２０は、パッシブモードで動作する。また、例えば、ネットワーク監視装置２０は、ネットワークセグメント２のスイッチまたはルータと、その上位にある他のスイッチまたはルータと、の間に接続されることで、通過するパケットやフレーム等を取得してもよい（図２１を参照）。この場合、ネットワーク監視装置２０は、取得したパケットのうち、遮断しなくてもよいパケットについては転送するインラインモードで動作する。また、ネットワーク監視装置２０は、ルータまたはスイッチに内包されてもよい。

なお、本実施形態では、ネットワークを流れるパケットを取得して、上記した各種の検知エンジンによりリアルタイムで検知を行う実施形態について説明したが、本開示の適用範囲は、リアルタイム検知に限定されない。例えば、ネットワークを流れる通信に係るデータを蓄積しておいて、蓄積されたデータに対して上記した各種の検知エンジンによる処理を行うこととしてもよい。

１ システム
２０ ネットワーク監視装置
５０ 管理サーバー
９０ ノード

Claims (38)

1. ネットワークに接続された端末による通信と予め保持されたパターンとを比較する比較手段と、
   前記比較の結果に従って、前記端末が不正な活動をしていると推測される程度を示す評価値と不正な活動のフェーズとを決定する決定手段と、
   前記端末毎に、前記評価値の前記フェーズ毎の最大値を保持する保持手段と、
   前記評価値の前記フェーズ毎の最大値に基づいて、前記端末が不正な活動を行っているか否かを判定する判定手段と、
   を備える情報処理装置。
2. 前記比較の結果、前記通信と一致または近似したパターンについて予め設定されている値を、前記評価値として取得する評価値取得手段と、
   取得された前記評価値を補正する補正手段と、を更に備え、
   前記決定手段は、前記補正手段によって補正された値を、前記評価値として決定する、
   請求項１に記載の情報処理装置。
3. 前記フェーズは、前記端末による不正な活動の遷移の状態を示し、
   前記決定手段は、前記比較の結果、前記通信と一致または近似したパターンについて予め設定されているフェーズを、前記通信に係るフェーズとして決定する、
   請求項２に記載の情報処理装置。
4. 前記評価値取得手段は、前記通信と、前記端末によって該通信よりも前または後に行われた他の通信との相関分析の結果に従って、前記評価値を取得する、
   請求項３に記載の情報処理装置。
5. 前記評価値取得手段は、前記相関分析によって、前記通信に関して取得されたフェーズと、前記端末に関して該通信の前または後に行われた他の通信に関して取得されたフェーズと、の間に連続性があると判定された場合に、前記評価値を取得する、
   請求項４に記載の情報処理装置。
6. 前記補正手段は、前記通信と、前記端末によって該通信よりも前または後に行われた他
   の通信との相関分析の結果に従って、前記評価値を補正する、
   請求項３に記載の情報処理装置。
7. 前記補正手段は、前記相関分析によって、前記通信に関して取得されたフェーズと、前記端末に関して該通信の前または後に行われた他の通信に関して取得されたフェーズと、の間に連続性があると判定された場合に、前記評価値を、連続性があると判定されなかった場合に比べてより大きく補正する、
   請求項６に記載の情報処理装置。
8. 前記端末毎に、前記フェーズ毎の前記評価値の最大値を合計する合計手段を更に備え、
   前記判定手段は、前記合計手段によって得られた合計値に基づいて、前記端末が不正な活動を行っているか否かを判定する、
   請求項１から７の何れか一項に記載の情報処理装置。
9. 前記判定手段は、前記合計値または前記合計値に基づく値が所定の閾値を超えた場合に、前記端末が不正な活動を行っていると判定する、
   請求項８に記載の情報処理装置。
10. 前記判定手段は、前記合計値に所定の重み付けを行うことで得られた値が所定の閾値を超えた場合に、前記端末が不正な活動を行っていると判定する、
    請求項８に記載の情報処理装置。
11. 前記ネットワークに接続された端末による通信を取得する通信取得手段を更に備え、
    前記比較手段は、取得された前記通信と予め保持されたパターンとを比較する、
    請求項１から１０の何れか一項に記載の情報処理装置。
12. 前記端末が不正な活動を行っていると判定された場合に該端末による通信を遮断する通信遮断手段を更に備える、
    請求項１から１１の何れか一項に記載の情報処理装置。
13. ネットワークに接続された端末による不正な通信を検知する、１または複数の検知手段を更に備え、
    前記判定手段は、前記検知手段によって不正な通信として検知されなかった通信に基づいて、前記端末が不正な活動を行っているか否かを判定する、
    請求項１から１２の何れか一項に記載の情報処理装置。
14. コンピューターが、
    ネットワークに接続された端末による通信と予め保持されたパターンとを比較する比較ステップと、
    前記比較の結果に従って、前記端末が不正な活動をしていると推測される程度を示す評価値と不正な活動のフェーズとを決定する決定ステップと、
    前記端末毎に、前記評価値の前記フェーズ毎の最大値を保持する保持ステップと、
    前記評価値の前記フェーズ毎の最大値に基づいて、前記端末が不正な活動を行っているか否かを判定する判定ステップと、
    を実行する不正活動判定方法。
15. コンピューターを、
    ネットワークに接続された端末による通信と予め保持されたパターンとを比較する比較手段と、
    前記比較の結果に従って、前記端末が不正な活動をしていると推測される程度を示す評
    価値と不正な活動のフェーズとを決定する決定手段と、
    前記端末毎に、前記評価値の前記フェーズ毎の最大値を保持する保持手段と、
    前記評価値の前記フェーズ毎の最大値に基づいて、前記端末が不正な活動を行っているか否かを判定する判定手段と、
    として機能させる、不正活動判定用プログラム。
16. ネットワークに接続された端末による通信と予め保持されたパターンとを比較する比較手段と、
    前記比較の結果に従って、前記端末の活動のフェーズを決定する決定手段と、
    前記決定手段によって、前記端末にコンテンツをダウンロードさせるフェーズであると決定された第一の通信と、前記決定手段によって、該端末に実行ファイルをダウンロードさせるフェーズであると決定された第二の通信との相関分析を行うことで、該第一の通信によるコンテンツのダウンロードと、該第二の通信による実行ファイルのダウンロードとの間の相関性の有無または程度を判定する相関分析手段と、
    前記相関分析の結果に基づいて、前記端末が所定の活動を行っているか否かを判定する判定手段と、
    を備える情報処理装置。
17. 前記決定手段は、前記通信によってダウンロードされるデータのファイル種別に基づいて、該通信に係る前記端末の活動のフェーズを決定する、
    請求項１６に記載の情報処理装置。
18. 前記決定手段は、前記通信がコンテンツまたは実行ファイルのリクエストを含む場合、該リクエストに含まれる情報に基づいて前記コンテンツまたは実行ファイルのファイル種別を推測し、推測されたファイル種別に基づいて該通信に係る前記端末の活動のフェーズを決定する、
    請求項１７に記載の情報処理装置。
19. 前記ファイル種別は、前記リクエストに含まれる拡張子またはリクエストヘッダーの特徴に基づいて推測される、
    請求項１８に記載の情報処理装置。
20. 前記決定手段は、前記通信がコンテンツまたは実行ファイルのリクエストに対するレスポンスを含む場合、該レスポンスに含まれる情報に基づいて前記コンテンツまたは実行ファイルのファイル種別を推測し、推測されたファイル種別に基づいて該通信に係る前記端末の活動のフェーズを決定する、
    請求項１７から１９の何れか一項に記載の情報処理装置。
21. 前記ファイル種別は、前記レスポンスにおける所定の位置のデータと予め定義されたデータパターンとを比較することで推測される、
    請求項２０に記載の情報処理装置。
22. 前記決定手段は、前記比較の結果に従って、前記端末が所定の活動をしていると推測される程度を示す評価値を更に決定する、
    請求項１６から２１の何れか一項に記載の情報処理装置。
23. 前記比較の結果、前記通信と一致または近似したパターンについて予め設定されている値を、前記評価値として取得する評価値取得手段と、
    取得された前記評価値を補正する補正手段と、を更に備え、
    前記決定手段は、前記補正手段によって補正された値を、前記評価値として決定する、
    請求項２２に記載の情報処理装置。
24. 前記フェーズは、前記端末による所定の活動の遷移の状態を示し、
    前記決定手段は、前記比較の結果、前記通信と一致または近似したパターンについて予め設定されているフェーズを、前記通信に係るフェーズとして決定する、
    請求項２３に記載の情報処理装置。
25. 前記評価値取得手段は、前記通信と、前記端末によって該通信よりも前または後に行われた他の通信との相関分析の結果に従って、前記評価値を取得する、
    請求項２４に記載の情報処理装置。
26. 前記評価値取得手段は、前記相関分析によって、前記通信に関して取得されたフェーズと、前記端末に関して該通信の前または後に行われた他の通信に関して取得されたフェーズと、の間に連続性があると判定された場合に、前記評価値を取得する、
    請求項２５に記載の情報処理装置。
27. 前記補正手段は、前記通信と、前記端末によって該通信よりも前または後に行われた他の通信との相関分析の結果に従って、前記評価値を補正する、
    請求項２４に記載の情報処理装置。
28. 前記補正手段は、前記第一の通信と、前記第二の通信との相関分析の結果に従って、前記評価値を補正する、
    請求項２４に記載の情報処理装置。
29. 前記補正手段は、前記相関分析によって、前記通信に関して取得されたフェーズと、前記端末に関して該通信の前または後に行われた他の通信に関して取得されたフェーズと、の間に連続性があると判定された場合に、前記評価値を、連続性があると判定されなかった場合に比べてより大きく補正する、
    請求項２７または２８に記載の情報処理装置。
30. 前記端末毎に、前記評価値の前記フェーズ毎の最大値を保持する保持手段と、
    前記評価値の前記フェーズ毎の最大値に基づいて、前記端末が所定の活動を行っているか否かを判定する判定手段と、を更に備える、
    請求項２２から２９の何れか一項に記載の情報処理装置。
31. 前記端末毎に、前記フェーズ毎の前記評価値の最大値を合計する合計手段を更に備え、
    前記判定手段は、前記合計手段によって得られた合計値に基づいて、前記端末が所定の活動を行っているか否かを判定する、
    請求項３０に記載の情報処理装置。
32. 前記判定手段は、前記合計値または前記合計値に基づく値が所定の閾値を超えた場合に、前記端末が所定の活動を行っていると判定する、
    請求項３１に記載の情報処理装置。
33. 前記判定手段は、前記合計値に所定の重み付けを行うことで得られた値が所定の閾値を超えた場合に、前記端末が所定の活動を行っていると判定する、
    請求項３１に記載の情報処理装置。
34. 前記ネットワークに接続された端末による通信を取得する通信取得手段を更に備え、
    前記比較手段は、取得された前記通信と予め保持されたパターンとを比較する、
    請求項１６から３３の何れか一項に記載の情報処理装置。
35. 前記端末が所定の活動を行っていると判定された場合に該端末による通信を遮断する通信遮断手段を更に備える、
    請求項１６から３４の何れか一項に記載の情報処理装置。
36. ネットワークに接続された端末による所定の通信を検知する、１または複数の検知手段を更に備え、
    前記判定手段は、前記検知手段によって所定の通信として検知されなかった通信に基づいて、前記端末が所定の活動を行っているか否かを判定する、
    請求項１６から３５の何れか一項に記載の情報処理装置。
37. コンピューターが、
    ネットワークに接続された端末による通信と予め保持されたパターンとを比較する比較ステップと、
    前記比較の結果に従って、前記端末の活動のフェーズを決定する決定ステップと、
    前記決定ステップにおいて、前記端末にコンテンツをダウンロードさせるフェーズであると決定された第一の通信と、前記決定ステップにおいて、該端末に実行ファイルをダウンロードさせるフェーズであると決定された第二の通信との相関分析を行うことで、該第一の通信によるコンテンツのダウンロードと、該第二の通信による実行ファイルのダウンロードとの間の相関性の有無または程度を判定する相関分析ステップと、
    前記相関分析の結果に基づいて、前記端末が所定の活動を行っているか否かを判定する判定ステップと、
    を実行する活動判定方法。
38. コンピューターを、
    ネットワークに接続された端末による通信と予め保持されたパターンとを比較する比較手段と、
    前記比較の結果に従って、前記端末の活動のフェーズを決定する決定手段と、
    前記決定手段によって、前記端末にコンテンツをダウンロードさせるフェーズであると決定された第一の通信と、前記決定手段によって、該端末に実行ファイルをダウンロードさせるフェーズであると決定された第二の通信との相関分析を行うことで、該第一の通信によるコンテンツのダウンロードと、該第二の通信による実行ファイルのダウンロードとの間の相関性の有無または程度を判定する相関分析手段と、
    前記相関分析の結果に基づいて、前記端末が所定の活動を行っているか否かを判定する判定手段と、
    として機能させる、活動判定用プログラム。

Images