JP6014280B2 - 情報処理装置、方法およびプログラム - Google Patents

Description

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

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

また、情報漏えいの発覚を遅らせるために、組織内で搾取した情報を組織内の代表感染端末へ集約し、外部へ送信していた攻撃手法が報告されている（非特許文献１を参照）。更に、組織内の端末にエージェントを導入し、通信内容およびプロセス情報等を取得し解析することで、当該端末がボットネットに参加しているか否かを判定し、当該端末がボットネットに参加している場合に、当該端末が該ボットネットにおいてどのような役割を持っているかを分析する研究内容が報告されている（非特許文献２を参照）。

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

独立行政法人情報処理推進機構、"標的型サイバー攻撃の事例分析と対策レポート"、［ｏｎｌｉｎｅ］、平成２４年 １月２０日、独立行政法人情報処理推進機構、［平成２６年１２月１９日検索］、インターネット〈ＵＲＬ：ｈｔｔｐ：／／ｗｗｗ．ｉｐａ．ｇｏ．ｊｐ／ｆｉｌｅｓ／００００２４５３６．ｐｄｆ〉 Ｈａｉｌｏｎｇ Ｗａｎｇ、外１名、"Ｒｏｌｅ−ｂａｓｅｄ ｃｏｌｌａｂｏｒａｔｉｖｅ ｉｎｆｏｒｍａｔｉｏｎ ｃｏｌｌｅｃｔｉｏｎ ｍｏｄｅｌ ｆｏｒ ｂｏｔｎｅｔ ｄｅｔｅｃｔｉｏｎ"、［ｏｎｌｉｎｅ］、平成２２年 ５月１７日、ＩＥＥＥ、［平成２６年１２月１９日検索］、インターネット〈ＵＲＬ：ｈｔｔｐ：／／ｉｅｅｅｘｐｌｏｒｅ．ｉｅｅｅ．ｏｒｇ／ｓｔａｍｐ／ｓｔａｍｐ．ｊｓｐ？ｔｐ＝＆ａｒｎｕｍｂｅｒ＝５４７８４７５＆ｉｓｎｕｍｂｅｒ＝５４７８４４４〉

従来、攻撃の発覚を遅らせるために、組織内部の端末に役割を持たせて協働させることで、感染端末と外部端末の通信量を少なくする攻撃手法がある。これに対して、従来、端末上で稼働するエージェント型監視ソフトウェアによって、当該端末で稼働しているソフトウェアの種類、当該端末で行われている処理内容を分析することで、マルウェアの活動を検出する技術が提案されている。しかし、従来の手法では感染端末の検知後に通信ログや通信キャプチャ情報、マルウェア検体などを解析するため、感染端末の検知からマルウェアの活動・役割の特定までに長時間を要する場合がある。

本開示は、上記した問題に鑑み、ネットワーク内において協働して活動を行っている端末を発見することを課題とする。

本開示の一例は、複数の端末による通信と予め保持されたパターンとを比較する比較手段と、前記比較の結果に従って、前記端末の活動のフェーズを決定する決定手段と、前記複数の端末に含まれる第一の端末について現在または過去において決定されたフェーズと、前記複数の端末に含まれる第二の端末について現在または過去において決定されたフェーズと、が共通する場合に、該第一の端末による通信と該第二の端末による通信との相関分析を行うことで、前記第一の端末と前記第二の端末とが協働して活動を行っているか否かを判定する相関分析手段と、を備える情報処理装置である。

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

本開示によれば、ネットワーク内において協働して活動を行っている端末を発見することが可能となる。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

また、相関分析部２５８は、通信が検出された第一の端末について現在または過去において決定されたフェーズと、第二の端末について現在または過去において決定されたフェーズと、が共通する（同一である）場合に、第一の端末による通信と第二の端末による通信との相関分析を行うことで、第一の端末と第二の端末とが協働して活動を行っているか否かを判定する。この際、相関分析部２５８は、第一の端末による通信と第二の端末による通信との連続性または関連性の有無または程度を判定することによって、第一の端末と第二の端末とが協働して活動を行っているか否かを判定する。異なる端末による通信間の相関分析の詳細については、「（３）役割推定のための相関分析」において後述する。

役割推定部２５９は、相関分析部２５８によって協働していると判定された第一の端末または第二の端末の、当該フェーズにおける活動の役割を推定する。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

（３）役割推定のための相関分析
標的型攻撃に使用される攻撃手法では、組織内での攻撃活動の発覚を遅らせるために、組織内の感染端末から攻撃者が管理する外部端末への通信量をなるべく少なくする傾向がある。ここで、外部端末との通信量を少なくするために、外部端末との通信を行う組織内部の感染端末の数を絞り、感染端末に役割を持たせ、感染端末を管理するという手法がある。例えば、感染端末が持つ役割として下記４つがある。なお、１つの感染端末で複数の役割を持つことがある。
１．マルウェアの組織内への感染拡大を目的として探索・感染・諜報活動を行う役割
２．攻撃者が管理する外部端末から組織内へファイルをダウンロードし、自端末内に配置し、再配布を行う役割
３．攻撃者が管理する外部端末からのＣ＆Ｃ通信を中継する役割
４．組織内での諜報活動の結果情報を集約し、攻撃者が管理する外部端末へ当該情報のアップロードを行う役割

このような感染端末の挙動を調査するために、従来、端末上で稼働するエージェント型監視ソフトウェアによって、当該端末で稼働しているソフトウェアの種類、当該端末で行われている処理内容を分析することで、マルウェアの活動を検出する技術が提案されている。しかし、従来の手法では感染端末の検知後に通信ログや通信キャプチャ情報、マルウェア検体などを解析するため、感染端末の検知からマルウェアの活動・役割の特定までに長時間を要する場合がある。

上述の通り、攻撃者は攻撃の発覚を遅らせるために感染端末と外部端末の通信量を少なくしようとし、このために、組織内部に攻撃者が管理する外部端末との通信を他の感染端末に代わって行う代行感染端末を設ける場合がある。この場合、外部端末−代行感染端末間通信と代行感染端末−感染端末間通信では、同一フェーズの通信となる。

そこで、本実施形態では、異なる端末による同一フェーズの通信同士を相関分析することで、組織内部の感染端末と攻撃者が管理する外部端末との通信を代行する役割を持つ感染端末等を発見し、端末の役割を推定する。

以下に、異なる端末による通信間の相関分析の内容を説明する。なお、フェーズの遷移順序が一致しない場合や、フェーズの遷移は一致しているが途中に別のフェーズを挟んでいる場合は、分析対象外としてもよい。また、マルウェアふるまい検知エンジン２５は、マルウェアの挙動として相関性が観測されるフェーズ遷移を、相関分析の対象とする。

図１６は、本実施形態に係る、マルウェアふるまい検知エンジン２５による第三の相関分析処理の流れを示すフローチャートである。本実施形態に係る第三の相関分析処理は、ネットワーク監視装置２０によって、ネットワーク上を流れるパケット（または、複数パケットからなるデータ）が取得された後、上記説明した通信パターンの判定処理（図５のステップＳ００６、および図６のステップＳ１０１からステップＳ１０３に相当）によって、所定の通信パターンが検出された場合に実行される。

ここで、本実施形態における所定の通信パターンは、以下に例示する４種類の通信パターンである。
１．感染・浸潤行為が行われた可能性がある通信パターンＰ３−ｍ、
２．実行ファイルが送り込まれた可能性がある通信パターンＰ４−ｍ、
３．Ｃ＆Ｃ通信が行われている可能性がある通信パターンＰ６−ｍ、および
４．搾取情報がアップロードされた可能性がある通信パターンＰ７−ｍ。
なお、マルウェアによる通信は暗号化されている可能性があるが、本実施形態に係るマルウェアふるまい検知エンジンは、通信パターンに基づいて情報のアップロードのための通信を検知するため、暗号化された通信であっても、当該通信が何れのフェーズに属する通信であるか検知することが可能である。

ステップＳ２０１では、検知された通信パターンに対応する役割推定相関分析処理が実行される。マルウェアふるまい検知エンジンは、上記説明した通信パターンの判定処理（図５のステップＳ００６、および図６のステップＳ１０１からステップＳ１０３に相当）において検出された通信パターンに応じて、対応する役割推定相関分析処理を実行する。具体的には、
１．感染・浸潤行為が行われた可能性がある通信パターンＰ３−ｍが検知された場合、感染・浸潤フェーズＰ３の役割推定相関分析処理が実行され、
２．実行ファイルが送り込まれた可能性がある通信パターンＰ４−ｍが検知された場合、実行ファイルのダウンロードフェーズＰ４の役割推定相関分析処理が実行され、
３．Ｃ＆Ｃ通信が行われている可能性がある通信パターンＰ６−ｍが検知された場合、Ｃ＆Ｃ通信フェーズＰ６の役割推定相関分析処理が実行され、
４．搾取情報がアップロードされた可能性がある通信パターンＰ７−ｍが検知された場合、搾取情報のアップロードフェーズＰ７の役割推定相関分析処理が実行される。
夫々の端末間相関分析処理の詳細については後述する。その後、処理はステップＳ２０２へ進む。

ステップＳ２０２では、役割推定相関分析の結果に応じて、該当端末の遮断や管理者アラート発行等の対処が行われる。上記した各役割推定相関分析において、何れかのノード９０が、マルウェア活動における何らかの役割を有していると推定された場合、ネットワーク監視装置２０は、マルウェア感染が検知された際の所定の対応を行う。マルウェア感染が検知された際の対応としては、例えば、通信遮断部２２による当該ノード９０の通信遮断開始や、当該ノード９０がマルウェアに感染していることのアラート（警告）の通知等が挙げられる。このような情報を管理者から把握可能とすることで、組織内ネットワーク上にどのような役割を持つ端末があるかを管理者に把握させ、マルウェアの感染拡大や攻撃活動が起きている状況を管理者に把握させ、適切な対処を促すことが出来る。上記した各役割推定相関分析において、何れのノード９０も、マルウェア活動における役割を有していると推定されなかった場合は、遮断やアラートの発行等の、マルウェア感染が検知された際の対処は行われない。なお、ネットワーク監視装置２０による通信遮断やアラート発行の具体的な方法については、ステップＳ１２３の説明等において例示した通りである。その後、本フローチャートに示された処理は終了する。

次に、夫々の役割推定相関分析処理の具体的な内容について説明する。

（３．１）感染・浸潤フェーズＰ３の役割推定相関分析処理
図１７は、本実施形態に係る、感染・浸潤フェーズＰ３の役割推定相関分析処理の流れを示すフローチャートである。本フローチャートは、感染・浸潤行為が行われた可能性がある通信パターンが検知されたために、図１６を用いて説明した第三の相関分析処理のステップＳ２０１において、感染・浸潤フェーズＰ３の役割推定相関分析処理が呼び出された場合の処理をより詳細に説明するものである。また、図１８は、本実施形態において、感染・浸潤フェーズＰ３の役割推定相関分析処理によって役割推定される端末が活動する様子を示す図である。

ステップＳ３０１では、感染元端末情報および感染先端末情報が記録される。マルウェアふるまい検知エンジン２５は、感染・浸潤行為が行われた可能性がある通信パターンが検知された場合に、当該通信に係る端末の端末情報、即ち、感染元端末情報および感染先端末情報を記憶装置１４ａに記録する。例えば、ノード９０ｂからノード９０ｃに対する感染・浸潤行為が行われた可能性がある通信パターンが検知された場合、マルウェアふるまい検知エンジン２５は、ノード９０ｂ（感染元）およびノード９０ｃ（感染先）の端末情報を記録する。ここで記録される端末情報は、例えば、端末のＩＰアドレス等である。その後、処理はステップＳ３０２へ進む。

ステップＳ３０２では、感染元端末が、過去に組織内端末から感染・浸潤を受けているか否かが判定される。相関分析部２５８は、今回検出された感染・浸潤フェーズＰ３の通信に係る感染元端末（上記した例では、ノード９０ｂ）が、過去に、他の何れかのノード９０（例えば、ノード９０ａ）と、同様の感染・浸潤行為が行われた可能性がある感染・浸潤フェーズＰ３の通信を行なっており、その際に感染先端末であったか否かを判定する。この判定は、本フローチャートに係る処理が過去に実行された際に、ステップＳ３０１において記録された情報を検索することで行われる。

即ち、相関分析部２５８は、通信が検出された感染元端末（ノード９０ｂ）について現在決定されたフェーズＰ３と、他の何れかのノード９０について過去において決定されたフェーズと、が共通している場合に、感染元端末（ノード９０ｂ）による通信と他の端末（例えば、ノード９０ａ）による通信との相関分析を行うことで、これらの端末が協働して活動を行っているか否かを判定する。感染元端末が、過去に組織内端末から感染・浸潤を受けてないと判定された場合、本フローチャートに示された処理は終了する。一方、感染元端末が、過去に組織内端末から感染・浸潤を受けていると判定された場合、処理はステップＳ３０３へ進む。

ステップＳ３０３では、今回感染・浸潤を行った端末および過去に感染・浸潤を行った端末が「感染・浸潤の役割」を持った端末であると推定され、推定結果が記録される。役割推定部２５９は、ステップＳ３０２において、感染元端末が、過去に組織内端末から感染・浸潤を受けていると判定された場合、今回の感染元端末（上記した例では、ノード９０ｂ）および過去の感染元端末（上記した例では、ノード９０ａ）が、マルウェアの「感染・浸潤の役割」を持った端末として動作していると推定し、これらの端末の端末情報を記録する。その後、本フローチャートに示された処理は終了する。

（３．２）実行ファイルのダウンロードフェーズＰ４の役割推定相関分析処理
図１９は、本実施形態に係る、実行ファイルのダウンロードフェーズＰ４の役割推定相関分析処理の流れを示すフローチャートである。本フローチャートは、実行ファイルが送り込まれた可能性がある通信パターンが検知されたために、図１６を用いて説明した第三の相関分析処理のステップＳ２０１において、実行ファイルのダウンロードフェーズＰ４の役割推定相関分析処理が呼び出された場合の処理をより詳細に説明するものである。また、図２０は、本実施形態において、実行ファイルのダウンロードフェーズＰ４の役割推定相関分析処理によって役割推定される端末が活動する様子を示す図である。

ステップＳ４０１では、リクエスト送信元端末およびリクエスト受信端末の検知情報が記録される。マルウェアふるまい検知エンジン２５は、実行ファイルのダウンロードが行われた可能性がある通信パターンが検知された場合に、当該通信の検知情報を記憶装置１４ａに記録する。ここで記録される検知情報には、実行ファイルをダウンロードするためのリクエストを送信したと推測される端末の端末情報（例えば、ノード９０ｃのＩＰアドレス等）、およびリクエストを受信したと推測される端末の端末情報（例えば、ノード９０ｂのＩＰアドレス等）が含まれる。その後、処理はステップＳ４０２へ進む。

ステップＳ４０２およびＳ４０３では、リクエストを受信した端末が、組織内部の端末であり、且つ、過去に組織外部の端末から実行ファイルをダウンロードしているか否かが判定される。相関分析部２５８は、今回検出された実行ファイルのダウンロードフェーズＰ４通信においてリクエストを受信した端末（上記した例では、ノード９０ｂ）が、組織内部の端末であるか否かを判定する（ステップＳ４０２）。なお、判定の具体的な手法は限定されないが、例えば、パケットに設定されたＩＰアドレス等を参照することで、リクエストを受信した端末が組織内部の端末であるか否かを判定することが出来る。リクエストを受信した端末が組織内部の端末でない場合、本フローチャートに示された処理は終了する。

一方、リクエストを受信した端末が、組織内部の端末である場合、当該端末が、過去に、組織外部の端末から実行ファイルをダウンロードした可能性がある実行ファイルのダウンロードフェーズＰ４の通信を行なっていたか否かが判定される（ステップＳ４０３）。なお、上記した例ではリクエスト受信端末はノード９０ｂであり、組織内部の端末である。この判定は、本フローチャートに係る処理が過去に実行された際に、ステップＳ４０１において記録された情報を検索することで行われる。

即ち、相関分析部２５８は、通信が検出されたリクエスト受信端末（ノード９０ｂ）について現在決定されたフェーズＰ４と、組織外部の端末について過去において決定されたフェーズと、が共通している場合に、リクエスト受信端末（ノード９０ｂ）による通信と組織外部の端末による通信との相関分析を行うことで、これらの端末が協働して活動を行っているか否かを判定する。過去に組織外部の端末から実行ファイルをダウンロードしていないと判定された場合、本フローチャートに示された処理は終了する。一方、過去に組織外部の端末から実行ファイルをダウンロードしていると判定された場合、処理はステップＳ４０４へ進む。例えば、今回のリクエスト受信端末であるノード９０ｂが、過去に組織外部の何れかの端末から実行ファイルをダウンロードしていた場合、本ステップにおける判定結果は「ＹＥＳ」となり、処理はステップＳ４０４へ進む。

ステップＳ４０４では、リクエスト受信端末に対して実行ファイルのダウンロードのリクエストを行った組織内端末が他にも存在するか否かが判定される。換言すれば、ステップＳ４０４では、リクエスト受信端末に対して実行ファイルのダウンロードのリクエストを行った組織内端末が複数存在するか否かが判定される。相関分析部２５８は、今回検出された実行ファイルのダウンロードフェーズＰ４の通信においてリクエストを受信した端末（上記した例では、ノード９０ｂ）が、今回リクエストを送信した端末（ノード９０ｃ）とは異なる組織内端末（例えば、ノード９０ｄ）から、実行ファイルのダウンロードのリクエスト（実行ファイルのダウンロードフェーズＰ４の通信）を受信していたか否かを判定する。この判定は、本フローチャートに係る処理が過去に実行された際に、ステップＳ４０１において記録された情報を検索することで行われる。

即ち、相関分析部２５８は、通信が検出されたリクエスト受信端末（ノード９０ｂ）について現在決定されたフェーズＰ４と、組織内端末（ノード９０ｄ）について過去において決定されたフェーズと、が共通している場合に、これらの通信についての相関分析を行うことで、これらの端末が協働して活動を行っているか否かを判定する。リクエストを行った組織内端末が他には存在しないと判定された場合、本フローチャートに示された処理は終了する。一方、リクエストを行った組織内端末が他にも存在すると判定された場合、処理はステップＳ４０５へ進む。

ステップＳ４０５では、今回リクエストを受信した端末が「実行ファイルを再配布する役割」を持った端末であると推定され、推定結果が記録される。役割推定部２５９は、ステップＳ４０４において、リクエストを行った組織内端末が他にも存在すると判定された場合、リクエスト受信端末（例えば、ノード９０ｂ）が、組織外部との通信量を抑制することで発見を遅らせるために、組織内部において実行ファイルを配布する役割を持たされた端末であると推定し、これらの端末の端末情報を記録する。その後、本フローチャートに示された処理は終了する。

（３．３）Ｃ＆Ｃ通信フェーズＰ６の役割推定相関分析処理
図２１は、本実施形態に係る、Ｃ＆Ｃ通信フェーズＰ６の役割推定相関分析処理の流れを示すフローチャートである。本フローチャートは、Ｃ＆Ｃ通信が行われている可能性がある通信パターンが検知されたために、図１６を用いて説明した第三の相関分析処理のステップＳ２０１において、Ｃ＆Ｃ通信フェーズＰ６の役割推定相関分析処理が呼び出された場合の処理をより詳細に説明するものである。また、図２２は、本実施形態において、Ｃ＆Ｃ通信フェーズＰ６の役割推定相関分析処理によって役割推定される端末が活動する様子を示す図である。

ステップＳ５０１では、コマンド送信元端末およびコマンド受信端末の検知情報が記録される。マルウェアふるまい検知エンジン２５は、Ｃ＆Ｃ通信が行われた可能性がある通信パターンが検知された場合に、当該通信の検知情報を記憶装置１４ａに記録する。ここで記録される検知情報には、Ｃ＆Ｃ通信のコマンドを送信したと推測される端末の端末情報（例えば、ノード９０ｂのＩＰアドレス等）、およびコマンドを受信したと推測される端末の端末情報（例えば、ノード９０ｃのＩＰアドレス等）が含まれる。その後、処理はステップＳ５０２へ進む。

ステップＳ５０２およびＳ５０３では、コマンド送信元端末が、組織内部の端末であり、且つ、過去に組織外部の端末とＣ＆Ｃ通信を推測される通信を行なっているか否かが判定される。相関分析部２５８は、今回検出されたＣ＆Ｃ通信フェーズＰ６の通信パターンにおいてコマンドを送信した端末（上記した例では、ノード９０ｂ）が、組織内部の端末であるか否かを判定する（ステップＳ５０２）。なお、判定の具体的な手法は限定されないが、例えば、パケットに設定されたＩＰアドレス等を参照することで、コマンド送信元端末が組織内部の端末であるか否かを判定することが出来る。コマンドを送信した端末が組織内部の端末でない場合、本フローチャートに示された処理は終了する。

一方、コマンドを送信した端末が、組織内部の端末である場合、当該端末が、過去に、組織外部の端末とＣ＆Ｃ通信の可能性があるＣ＆Ｃ通信フェーズＰ６の通信を行なっていたか否かが判定される（ステップＳ５０３）。なお、上記した例ではコマンド送信端末はノード９０ｂであり、組織内部の端末である。この判定は、本フローチャートに係る処理が過去に実行された際に、ステップＳ５０１において記録された情報を検索することで行われる。

即ち、相関分析部２５８は、通信が検出されたコマンド送信元端末（ノード９０ｂ）について現在決定されたフェーズＰ６と、組織外部の端末について過去において決定されたフェーズと、が共通している場合に、コマンド送信元端末（ノード９０ｂ）による通信と組織外部の端末による通信との相関分析を行うことで、これらの端末が協働して活動を行っているか否かを判定する。過去に組織外部の端末とＣ＆Ｃ通信の可能性がある通信を行なっていないと判定された場合、本フローチャートに示された処理は終了する。一方、過去に組織外部の端末とＣ＆Ｃ通信の可能性がある通信を行なっていたと判定された場合、処理はステップＳ５０４へ進む。例えば、今回のコマンド送信端末であるノード９０ｂが、過去に組織外部の何れかの端末とＣ＆Ｃ通信を行なっていた場合、本ステップにおける判定結果は「ＹＥＳ」となり、処理はステップＳ５０４へ進む。

ステップＳ５０４では、コマンド送信端末とＣ＆Ｃ通信を行った組織内端末が他にも存在するか否かが判定される。換言すれば、ステップＳ５０４では、コマンド送信端末とＣ＆Ｃ通信を行った組織内端末が複数存在するか否かが判定される。相関分析部２５８は、今回検出されたＣ＆Ｃ通信フェーズＰ６の通信においてコマンドを送信した端末（上記した例では、ノード９０ｂ）が、今回Ｃ＆Ｃ通信の相手方となった端末（ノード９０ｃ）とは異なる組織内端末（例えば、ノード９０ｄ）と、Ｃ＆Ｃ通信の可能性がある通信（Ｃ＆Ｃ通信フェーズＰ６の通信）を行なっていたか否かを判定する。この判定は、本フローチャートに係る処理が過去に実行された際に、ステップＳ５０１において記録された情報を検索することで行われる。

即ち、相関分析部２５８は、通信が検出されたコマンド送信端末（ノード９０ｂ）について現在決定されたフェーズＰ６と、組織内端末（ノード９０ｄ）について過去において決定されたフェーズと、が共通している場合に、これらの通信についての相関分析を行うことで、これらの端末が協働して活動を行っているか否かを判定する。Ｃ＆Ｃ通信を行った組織内端末が他には存在しないと判定された場合、本フローチャートに示された処理は終了する。一方、Ｃ＆Ｃ通信を行った組織内端末が他にも存在すると判定された場合、処理はステップＳ５０５へ進む。

ステップＳ５０５では、今回コマンドを送信した端末が「Ｃ＆Ｃ通信を中継する役割」を持った端末であると推定され、推定結果が記録される。役割推定部２５９は、ステップＳ５０４において、Ｃ＆Ｃ通信を行った組織内端末が他にも存在すると判定された場合、コマンド送信端末（例えば、ノード９０ｂ）が、組織外のＣ＆ＣサーバーからのＣ＆Ｃ通信を中継する役割を持たされた端末であると推定し、これらの端末の端末情報を記録する。その後、本フローチャートに示された処理は終了する。

（３．４）搾取情報のアップロードフェーズＰ７の役割推定相関分析処理
図２３は、本実施形態に係る、搾取情報のアップロードフェーズＰ７の役割推定相関分析処理の流れを示すフローチャートである。本フローチャートは、搾取情報がアップロードされた可能性がある通信パターンが検知されたために、図１６を用いて説明した第三の相関分析処理のステップＳ２０１において、搾取情報のアップロードフェーズＰ７の役割推定相関分析処理が呼び出された場合の処理をより詳細に説明するものである。また、図２４は、本実施形態において、搾取情報のアップロードフェーズＰ７の役割推定相関分析処理によって役割推定される端末が活動する様子を示す図である。

ステップＳ６０１では、情報のアップロード元端末およびアップロード先端末の検知情報が記録される。マルウェアふるまい検知エンジン２５は、搾取情報のアップロードが行われた可能性がある通信パターンが検知された場合に、当該通信の検知情報を記憶装置１４ａに記録する。ここで記録される検知情報には、搾取情報をアップロードしたと推測される端末の端末情報（例えば、ノード９０ｂのＩＰアドレス等）、および搾取情報のアップロードを受けたと推測される端末の端末情報（例えば、組織外部のサーバーのＩＰアドレス等）が含まれる。その後、処理はステップＳ６０２へ進む。

ステップＳ６０２では、アップロード先端末が、組織外部の端末であるか否かが判定される。相関分析部２５８は、今回検出された通信パターンにおいて情報のアップロードを受けた端末（上記した例では、組織外部のサーバー）が、組織外部の端末であるか否かを判定する。なお、判定の具体的な手法は限定されないが、例えば、パケットに設定されたＩＰアドレス等を参照することで、情報のアップロードを受けた端末が組織外部の端末であるか否かを判定することが出来る。情報のアップロードを受けた端末が組織外部の端末でない場合、本フローチャートに示された処理は終了する。一方、情報のアップロードを受けた端末が、組織外部の端末である場合、処理はステップＳ６０３へ進む。なお、上記した例では、アップロード先端末は組織外部のサーバー（端末）である。

ステップＳ６０３では、アップロード元端末に対して情報のアップロードを行った組織内端末が複数存在するか否かが判定される。相関分析部２５８は、今回検出された搾取情報のアップロードフェーズＰ７の通信において情報のアップロードを行った端末（上記した例では、ノード９０ｂ）が、過去に、複数の組織内端末（例えば、ノード９０ａ、９０ｃ、９０ｄ）から、情報のアップロード（搾取情報のアップロードフェーズＰ７の通信）を受信していたか否かを判定する。この判定は、本フローチャートに係る処理が過去に実行された際に、ステップＳ６０１において記録された情報を検索することで行われる。

即ち、相関分析部２５８は、通信が検出されたアップロード元端末（ノード９０ｂ）について現在決定されたフェーズＰ７と、複数の組織内端末（例えば、ノード９０ａ、９０ｃ、９０ｄ）について過去において決定されたフェーズと、が共通している場合に、これらの通信についての相関分析を行うことで、これらの端末が協働して活動を行っているか否かを判定する。情報のアップロードを行った組織内端末が複数存在しないと判定された場合、本フローチャートに示された処理は終了する。一方、情報のアップロードを行った組織内端末が複数存在すると判定された場合、処理はステップＳ６０４へ進む。

ステップＳ６０４では、今回アップロードを行った端末が「搾取情報を集約し、アップロードする役割」を持った端末であると推定され、推定結果が記録される。役割推定部２５９は、ステップＳ６０３において、アップロード元端末に対して情報のアップロードを行った組織内端末が複数存在すると判定された場合、アップロード元端末（例えば、ノード９０ｂ）が、組織外部との通信量を抑制することで発見を遅らせるために、組織内部から情報を集めて、組織外部のサーバーへ送信する役割を持たされた端末であると推定し、この端末の端末情報を記録する。その後、本フローチャートに示された処理は終了する。

上記説明した、役割推定のための相関分析によれば、組織内の通信を監視することで、マルウェアに感染した端末の組織内での「役割」を推定することが可能となり、更に、推定された「役割」に応じた通信制御を行うことが可能となる。例えば、情報をアップロードする役割を持つ可能性がある端末に対しては、マルウェア活動可能性が低い段階であっても通信遮断する等の対応を選択することができる。また、感染端末を複数検知した場合に、感染端末の「役割」の脅威度合いが大きい端末を優先して解析を行うなど、セキュリティインシデント対応時の判断材料とすることも可能である。

＜通信の遮断＞
通信遮断部２２は、上述の通り、不正な活動を行っていると判定された端末による通信を遮断する。ここで、通信遮断部２２は、更に、組織内の端末について、マルウェアふるまい検知エンジンによって、マルウェアに感染したことが検出されたか、または、端末の組織内での役割が推定された場合、当該端末の不正な活動に関わる通信先を、マルウェア検出に至った通信パターンの組み合わせから特定し、組織内端末から当該通信先への通信を遮断してもよい。ここで、端末の不正活動に関わる通信先とは、例えば、マルウェアのダウンロード元、マルウェアへ指令を送るＣ＆Ｃサーバー、諜報活動結果を送付するアップロードサーバー等である。また、組織内端末からの当該通信先への通信を遮断する場合には、当該組織内端末がマルウェアに感染していると判定されているか否かに拘らず、通信を遮断することとしてもよい。具体的には、通信遮断部２２は、マルウェア感染の判定または役割の推定がなされた場合、マルウェアが通信していた宛先（プロトコル、ポート番号、ＵＲＩ等）に対する、組織内端末（マルウェア感染していない端末も含む）からの通信をアクセス制御（遮断や、廃棄、または宛先変更）する。

遮断の対象となる通信先は、役割が推定された端末に対して当該役割を果たすためのマルウェアや悪性コンテンツ等を送信した端末、または役割が推定された端末が当該役割を果たすために通信する外部サーバー等である。例えば、
１．侵入フェーズＰ１系の通信パターンが検知された場合、組織内部端末からの接続先は、攻撃者が用意した感染のきっかけとなる細工の施されたサイトである可能性があり、
２．実行ファイルのダウンロードフェーズＰ４系の通信パターンが検知された場合、組織内部端末からの接続先は、マルウェアが格納されているデバイスである可能性があり、
３．Ｃ＆Ｃサーバー検索フェーズＰ５またはＣ＆Ｃサーバー通信フェーズＰ６系の通信パターンが検知された場合、組織内部端末からの接続先は、組織内端末において動作するマルウェアに対して指令を行うデバイスである可能性があり、
４．搾取情報のアップロードフェーズＰ７系の通信パターンが検知された場合、組織内部端末からの接続先は、マルウェアが搾取情報を格納しているデバイスである可能性がある。
このため、通信遮断部２２は、これらの接続先に対する通信を遮断する。

本実施形態に開示されたシステムによれば、このようにして、予め役割別に定められた遮断ポリシーに従い、マルウェア活動と判定された通信に関わった役割別に、対象デバイスへの通信を、マルウェア感染していないデバイスからの通信も含めて遮断することで、危険な通信を遮断して被害の拡大を未然に防止し、内部に侵入しているマルウェアの活動を早期に沈静化することが出来る。

また、ネットワーク監視装置２０は、上記処理で特定された、不正活動に関わる通信先（例えば、マルウェアのダウンロード元、マルウェアへ指令を送るＣ＆Ｃサーバー、諜報活動結果を送付するアップロードサーバー等）を、管理者に通知してもよい。

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

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

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

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

Claims (10)

1. 複数の端末による通信と予め保持されたパターンとを比較する比較手段と、
   前記比較の結果に従って、前記端末の活動のフェーズを決定する決定手段と、
   前記複数の端末に含まれる第一の端末について現在または過去において決定されたフェーズと、前記複数の端末に含まれる第二の端末について現在または過去において決定されたフェーズと、が共通する場合に、該第一の端末による通信と該第二の端末による通信との相関分析を行うことで、前記第一の端末と前記第二の端末とが協働して活動を行っているか否かを判定する相関分析手段と、
   を備える情報処理装置。
2. 前記相関分析手段は、前記第一の端末による通信と前記第二の端末による通信との連続性または関連性の有無または程度を判定することによって、該第一の端末と該第二の端末とが協働して活動を行っているか否かを判定する、
   請求項１に記載の情報処理装置。
3. 前記相関分析手段によって協働していると判定された前記第一の端末または前記第二の端末の、前記フェーズにおける活動の役割を推定する役割推定手段を更に備える、
   請求項１または２に記載の情報処理装置。
4. 前記端末の役割が推定された場合に、該端末に係る通信を遮断する通信遮断手段を更に備える、
   請求項３に記載の情報処理装置。
5. 前記通信遮断手段は、前記端末の役割が推定された場合に、該端末の役割に関連する所定の端末への通信を、該所定の端末への通信元がマルウェアに感染しているか否かに拘らず遮断する、
   請求項４に記載の情報処理装置。
6. 前記所定の端末は、前記役割が推定された端末に対して該役割を果たすためのソフトウェアを送信した端末、または前記役割が推定された端末が該役割を果たすために通信する端末である、
   請求項５に記載の情報処理装置。
7. 前記フェーズは、前記端末による所定の活動の遷移の状態を示し、
   前記決定手段は、前記比較の結果、前記通信と一致または近似したパターンについて予め設定されているフェーズを、前記通信に係るフェーズとして決定する、
   請求項１から６の何れか一項に記載の情報処理装置。
8. 前記ネットワークに接続された端末による通信を取得する通信取得手段を更に備え、
   前記比較手段は、取得された前記通信と予め保持されたパターンとを比較する、
   請求項１から７の何れか一項に記載の情報処理装置。
9. コンピューターが、
   複数の端末による通信と予め保持されたパターンとを比較する比較ステップと、
   前記比較の結果に従って、前記端末の活動のフェーズを決定する決定ステップと、
   前記複数の端末に含まれる第一の端末について現在または過去において決定されたフェーズと、前記複数の端末に含まれる第二の端末について現在または過去において決定されたフェーズと、が共通する場合に、該第一の端末による通信と該第二の端末による通信との相関分析を行うことで、前記第一の端末と前記第二の端末とが協働して活動を行っているか否かを判定する相関分析ステップと、
   を実行する方法。
10. コンピューターを、
    複数の端末による通信と予め保持されたパターンとを比較する比較手段と、
    前記比較の結果に従って、前記端末の活動のフェーズを決定する決定手段と、
    前記複数の端末に含まれる第一の端末について現在または過去において決定されたフェーズと、前記複数の端末に含まれる第二の端末について現在または過去において決定されたフェーズと、が共通する場合に、該第一の端末による通信と該第二の端末による通信との相関分析を行うことで、前記第一の端末と前記第二の端末とが協働して活動を行っているか否かを判定する相関分析手段と、
    として機能させるためのプログラム。

Images