知財求人 - 知財ポータルサイト「IP Force」
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2024118424
(43)【公開日】2024-08-30
(54)【発明の名称】通信分析装置、通信分析プログラム及び通信分析方法
(51)【国際特許分類】
H04L 69/22 20220101AFI20240823BHJP
【ＦＩ】
H04L69/22
【審査請求】未請求
【請求項の数】13
【出願形態】ＯＬ
(21)【出願番号】P 2023221466
(22)【出願日】2023-12-27
(31)【優先権主張番号】P 2023024558
(32)【優先日】2023-02-20
(33)【優先権主張国・地域又は機関】JP
(71)【出願人】
【識別番号】000000295
【氏名又は名称】沖電気工業株式会社
(74)【代理人】
【識別番号】100180275
【弁理士】
【氏名又は名称】吉田 倫太郎
(74)【代理人】
【識別番号】100161861
【弁理士】
【氏名又は名称】若林 裕介
(72)【発明者】
【氏名】土江 康太
(72)【発明者】
【氏名】中村 信之
(57)【要約】
【課題】 通信トラフィックのデータからサービスポートを判別する際の精度を向上させる。
【解決手段】 本発明は、通信分析装置に関する。そして本発明の通信分析装置は、分析対象のネットワーク上を流れる通信トラフィックデータを通信フローごとに分類し、通信フローごとにパケットのヘッダ情報に基づくフロー情報を用いてサービスポートを判定し、ＩＰアドレスごとにサービスポートの一覧であるサービスポートリストを管理し、フロー情報だけでサービスポートが特定できない通信フローに対してサービスポートリストを用いてサービスポートを推定し、フロー情報だけでサービスポートが特定できない通信フローについてはサービスポート推定処理の結果をサービスポート判定処理の結果とすることを特徴とする。
【選択図】 図１
【解決手段】 本発明は、通信分析装置に関する。そして本発明の通信分析装置は、分析対象のネットワーク上を流れる通信トラフィックデータを通信フローごとに分類し、通信フローごとにパケットのヘッダ情報に基づくフロー情報を用いてサービスポートを判定し、ＩＰアドレスごとにサービスポートの一覧であるサービスポートリストを管理し、フロー情報だけでサービスポートが特定できない通信フローに対してサービスポートリストを用いてサービスポートを推定し、フロー情報だけでサービスポートが特定できない通信フローについてはサービスポート推定処理の結果をサービスポート判定処理の結果とすることを特徴とする。
【選択図】 図１
【特許請求の範囲】
【請求項1】
分析対象のネットワーク上を流れる通信トラフィックデータを通信フローごとに分類する通信フロー処理手段と、
前記通信フローごとに、前記通信フローを構成するパケットのヘッダ情報に基づくフロー情報を用いてサービスポートを判定するサービスポート判定処理を行うサービスポート判定手段と、
前記ネットワーク上で分析対象となるＩＰアドレスごとに、サービスポートの一覧であるサービスポートリストを管理するサービスポートリスト管理手段と、
フロー情報だけでサービスポートが特定できない前記通信フローに対して、前記サービスポートリスト管理手段が管理する前記サービスポートリストを用いてサービスポートを推定するサービスポート推定処理を行うサービスポート推定手段とを備え、
前記サービスポート判定手段は、フロー情報だけでサービスポートが特定できない前記通信フローについては前記サービスポート推定手段による前記サービスポート推定処理の結果を前記サービスポート判定処理の結果とする
ことを特徴とする通信分析装置。
前記通信フローごとに、前記通信フローを構成するパケットのヘッダ情報に基づくフロー情報を用いてサービスポートを判定するサービスポート判定処理を行うサービスポート判定手段と、
前記ネットワーク上で分析対象となるＩＰアドレスごとに、サービスポートの一覧であるサービスポートリストを管理するサービスポートリスト管理手段と、
フロー情報だけでサービスポートが特定できない前記通信フローに対して、前記サービスポートリスト管理手段が管理する前記サービスポートリストを用いてサービスポートを推定するサービスポート推定処理を行うサービスポート推定手段とを備え、
前記サービスポート判定手段は、フロー情報だけでサービスポートが特定できない前記通信フローについては前記サービスポート推定手段による前記サービスポート推定処理の結果を前記サービスポート判定処理の結果とする
ことを特徴とする通信分析装置。
【請求項2】
前記サービスポートリスト管理手段は、前記サービスポート判定手段による前記サービスポート判定処理の結果に基づいて、前記サービスポート判定処理の対象となる前記通信フローに係る前記ＩＰアドレスの前記サービスポートリストのサービスポートを追加することを特徴とする請求項１に記載の通信分析装置。
【請求項3】
前記サービスポートリスト管理手段が保持する前記サービスポートリストには、前記ＩＰアドレスがクライアントとしてアクセスするポートのリストである第１のサブリストと、前記ＩＰアドレスがサーバとしてアクセスされるポートのリストである第２のサブリストが含まれていることを特徴とする請求項２に記載の通信分析装置。
【請求項4】
前記サービスポートリスト管理手段が保持する前記サービスポートリストには、プロトコルごとの前記第１のサブリスト及び前記第２のサブリストが含まれることを特徴とする請求項３に記載の通信分析装置。
【請求項5】
前記サービスポート推定手段は、前記通信フローの送信元アドレスに対応する前記サービスポートリスト及び前記通信フローの宛先アドレスに対応する前記サービスポートリストと、前記通信フローの送信元通信ポート及び前記通信フローの宛先通信ポートとを比較することにより前記サービスポート推定処理を行うことを特徴とする請求項４に記載の通信分析装置。
【請求項6】
前記サービスポートリスト管理手段が管理する前記サービスポートリストを構成するサービスポートごとに、前記通信フローの特徴量に基づいて一致又は不一致を判定する通信パターン分析モデルを構築する通信パターン学習手段をさらに備え、
前記サービスポートリスト管理手段は、前記通信パターン学習手段が構築した前記通信パターン分析モデルを保持し、
前記サービスポート推定手段は、前記サービスポートリスト管理手段が保持する前記通信パターン分析モデルも用いて、前記サービスポート推定処理を行う
ことを特徴とする請求項１に記載の通信分析装置。
前記サービスポートリスト管理手段は、前記通信パターン学習手段が構築した前記通信パターン分析モデルを保持し、
前記サービスポート推定手段は、前記サービスポートリスト管理手段が保持する前記通信パターン分析モデルも用いて、前記サービスポート推定処理を行う
ことを特徴とする請求項１に記載の通信分析装置。
【請求項7】
前記サービスポートリスト管理手段は、プロトコルごとに前記サービスポートリストを保持し、
プロトコルがＵＤＰの前記サービスポートリストを作成するために、ＵＤＰの通信フローの履歴情報として、通信フローの宛先ポート番号ごとに、通信フローの発生数、通信フローの送信元ポート番号を管理する、ＵＤＰポート履歴情報管理手段をさらに備え、
前記サービスポートリスト管理手段は、前記ＵＤＰの通信フローの履歴情報に含まれる宛先ポート番号ごとに、通信フローの発生数と、通信フローの送信元ポート番号を宛先ポートとしてみたときの通信フローの発生数を比較し、いずれかの送信元ポート番号との比較で前記宛先ポート番号の発生数の方が多い場合に、前記宛先ポート番号をＵＤＰのサービスポートリストに追加する
ことを特徴とする請求項２に記載の通信分析装置。
プロトコルがＵＤＰの前記サービスポートリストを作成するために、ＵＤＰの通信フローの履歴情報として、通信フローの宛先ポート番号ごとに、通信フローの発生数、通信フローの送信元ポート番号を管理する、ＵＤＰポート履歴情報管理手段をさらに備え、
前記サービスポートリスト管理手段は、前記ＵＤＰの通信フローの履歴情報に含まれる宛先ポート番号ごとに、通信フローの発生数と、通信フローの送信元ポート番号を宛先ポートとしてみたときの通信フローの発生数を比較し、いずれかの送信元ポート番号との比較で前記宛先ポート番号の発生数の方が多い場合に、前記宛先ポート番号をＵＤＰのサービスポートリストに追加する
ことを特徴とする請求項２に記載の通信分析装置。
【請求項8】
前記ＵＤＰポート履歴情報管理手段は、前記ＵＤＰの通信フローの履歴情報として、通信フローの宛先ポート番号ごとに、通信フローの発生日数をさらに管理し、
前記サービスポートリスト管理手段は、前記ＵＤＰの通信フローの履歴情報に含まれる宛先ポートについて、通信フローの発生日数が予め決められた閾値を満たない場合は、前記ＵＤＰのサービスポートリストに追加しない
ことを特徴とする請求項７に記載の通信分析装置。
前記サービスポートリスト管理手段は、前記ＵＤＰの通信フローの履歴情報に含まれる宛先ポートについて、通信フローの発生日数が予め決められた閾値を満たない場合は、前記ＵＤＰのサービスポートリストに追加しない
ことを特徴とする請求項７に記載の通信分析装置。
【請求項9】
前記ＵＤＰポート履歴情報管理手段は、
前記ＵＤＰの通信フローの履歴情報として、端末ごとに同じ送信元ポート番号が何回使われたかの情報をさらに管理し、
前記通信フローの発生日数の閾値について、予め決められた初期値から、前記送信元ポート番号の使用回数の増加に合わせて増加させていく
ことを特徴とする請求項８に記載の通信分析装置。
前記ＵＤＰの通信フローの履歴情報として、端末ごとに同じ送信元ポート番号が何回使われたかの情報をさらに管理し、
前記通信フローの発生日数の閾値について、予め決められた初期値から、前記送信元ポート番号の使用回数の増加に合わせて増加させていく
ことを特徴とする請求項８に記載の通信分析装置。
【請求項10】
前記サービスポートリスト管理手段は、前記通信フローの発生日数の閾値の他に、前記ＵＤＰの通信フローの履歴情報に含まれる宛先ポートごとに、通信フローの送信元ポート番号の種類数、あるいは前記宛先ポートの通信フローの送信元ＩＰアドレス種類数が予め決められた閾値以上であることを、サービスポートと判定するかの条件にさらに設定することを特徴とする請求項８に記載の通信分析装置。
【請求項11】
前記サービスポートリスト管理手段は、前記ＵＤＰのサービスポートリストの作成において、前記通信フローの発生日数の条件で、サービスポート判定すると判断された宛先ポートについて、さらに前記宛先ポートの１日当りの利用送信元ＩＰアドレス数が予め決められた閾値より小さい場合に、前記ＵＤＰのサービスポートリストに追加しないことを特徴とする請求項８に記載の通信分析装置。
【請求項12】
コンピュータを、
分析対象のネットワーク上を流れる通信トラフィックデータを通信フローごとに分類する通信フロー処理手段と、
前記通信フローごとに、前記通信フローを構成するパケットのヘッダ情報に基づくフロー情報を用いてサービスポートを判定するサービスポート判定処理を行うサービスポート判定手段と、
前記ネットワーク上で分析対象となるＩＰアドレスごとに、サービスポートの一覧であるサービスポートリストを管理するサービスポートリスト管理手段と、
フロー情報だけでサービスポートが特定できない前記通信フローに対して、前記サービスポートリスト管理手段が管理する前記サービスポートリストを用いてサービスポートを推定するサービスポート推定処理を行うサービスポート推定手段として機能させ、
前記サービスポート判定手段は、フロー情報だけでサービスポートが特定できない前記通信フローについては前記サービスポート推定手段による前記サービスポート推定処理の結果を前記サービスポート判定処理の結果とする
ことを特徴とする通信分析プログラム。
分析対象のネットワーク上を流れる通信トラフィックデータを通信フローごとに分類する通信フロー処理手段と、
前記通信フローごとに、前記通信フローを構成するパケットのヘッダ情報に基づくフロー情報を用いてサービスポートを判定するサービスポート判定処理を行うサービスポート判定手段と、
前記ネットワーク上で分析対象となるＩＰアドレスごとに、サービスポートの一覧であるサービスポートリストを管理するサービスポートリスト管理手段と、
フロー情報だけでサービスポートが特定できない前記通信フローに対して、前記サービスポートリスト管理手段が管理する前記サービスポートリストを用いてサービスポートを推定するサービスポート推定処理を行うサービスポート推定手段として機能させ、
前記サービスポート判定手段は、フロー情報だけでサービスポートが特定できない前記通信フローについては前記サービスポート推定手段による前記サービスポート推定処理の結果を前記サービスポート判定処理の結果とする
ことを特徴とする通信分析プログラム。
【請求項13】
通信分析装置が行う通信分析方法において、
前記通信分析装置は、通信フロー処理手段、サービスポート判定手段、サービスポートリスト管理手段及びサービスポート推定手段を備え、
前記通信フロー処理手段は、分析対象のネットワーク上を流れる通信トラフィックデータを通信フローごとに分類し、
前記サービスポート判定手段は、前記通信フローごとに、前記通信フローを構成するパケットのヘッダ情報に基づくフロー情報を用いてサービスポートを判定するサービスポート判定処理を行い、
前記サービスポートリスト管理手段は、前記ネットワーク上で分析対象となるＩＰアドレスごとに、サービスポートの一覧であるサービスポートリストを管理し、
前記サービスポート推定手段は、フロー情報だけでサービスポートが特定できない前記通信フローに対して、前記サービスポートリスト管理手段が管理する前記サービスポートリストを用いてサービスポートを推定するサービスポート推定処理を行い、
前記サービスポート判定手段は、フロー情報だけでサービスポートが特定できない前記通信フローについては前記サービスポート推定手段による前記サービスポート推定処理の結果を前記サービスポート判定処理の結果とする
ことを特徴とする通信分析方法。
前記通信分析装置は、通信フロー処理手段、サービスポート判定手段、サービスポートリスト管理手段及びサービスポート推定手段を備え、
前記通信フロー処理手段は、分析対象のネットワーク上を流れる通信トラフィックデータを通信フローごとに分類し、
前記サービスポート判定手段は、前記通信フローごとに、前記通信フローを構成するパケットのヘッダ情報に基づくフロー情報を用いてサービスポートを判定するサービスポート判定処理を行い、
前記サービスポートリスト管理手段は、前記ネットワーク上で分析対象となるＩＰアドレスごとに、サービスポートの一覧であるサービスポートリストを管理し、
前記サービスポート推定手段は、フロー情報だけでサービスポートが特定できない前記通信フローに対して、前記サービスポートリスト管理手段が管理する前記サービスポートリストを用いてサービスポートを推定するサービスポート推定処理を行い、
前記サービスポート判定手段は、フロー情報だけでサービスポートが特定できない前記通信フローについては前記サービスポート推定手段による前記サービスポート推定処理の結果を前記サービスポート判定処理の結果とする
ことを特徴とする通信分析方法。
【発明の詳細な説明】
【技術分野】
【0001】
この発明は、通信分析装置、通信分析プログラム及び通信分析方法に関し、例えば、通信トラフィックデータに基づいて通信セキュリティに関する分析を行う装置に適用し得る。
【背景技術】
【0002】
現在、ＩｏＴ機器の利活用拡大により、組織ネットワークにおいて従業員のＰＣやＩｏＴ機器が接続される末端のネットワーク（エッジネットワークと呼ぶ）の監視の需要が高まっている。例えば、オフィスや工場などのエッジネットワークにＩｏＴ機器が多数接続されるようになり、ＩＴ管理者がエッジネットワークにどのような機器が接続されているか、各機器がどこと通信しているか、マルウェア感染等によるセキュリティ脅威が発生していないか、といった情報を収集し管理することが困難になってきている。そのため、現在、こういった情報を自動的に収集し管理するエッジネットワーク監視の実現が求められている。
【0003】
従来、エッジネットワーク監視を実現するために、通信トラフィックログ分析を用いる方法がある。従来の通信トラフィックログ分析では、監視対象ネットワークの機器が収容されるネットワークスイッチのミラーポートに通信分析装置を接続し、ネットワークを流れるトラフィックをキャプチャし分析することで、リアルタイムに通信状況を可視化しセキュリティリスクやセキュリティ脅威の発生を検出する。通信状況の可視化情報として、どの機器から他のどの機器に対して通信が発生したかを示したい場合がある。また、セキュリティリスクを把握するため、ネットワーク内に存在するサーバが待ち受けるサービスを把握し、意図しないポートが空いていないか確認したい場合がある。さらに、セキュリティ脅威を検出するため、ある機器が普段と異なるサーバのサービスにアクセスしていないか確認したい場合がある。従来の通信トラフィックログ分析において、これらを実現する場合、通信フロー（送信元ＩＰアドレス、送信元ポート番号、宛先ＩＰアドレス、宛先ポート番号、プロトコル番号の組で識別されるトラフィックの流れ）において、サーバが待ち受ける側のポート番号（以下、「サービスポート」と呼ぶ）の識別が必要である。
【0004】
ところで、従来の通信トラフィックログ分析では、サービスポートの識別方法として、ウェルノウンポートとして定義されているポート番号に代表されるように、番号の若いものがサービスポートとして使われる場合が多いことから、送信元ポート番号と宛先ポート番号の小さい方のポート番号をサービスポートとして識別する方法がある。しかしながら実トラフィックを観測すると、必ずしもポート番号の小さい方がサービスポートとして利用されないことが分かっている。
【0005】
サービスポートの別の識別方法として、一般に通信はクライアントからサーバに対して発生する特徴を利用し、通信フローの先頭パケットを観測し、当該パケットの宛先ポート番号をサービスポートとして識別する方法が考えられる。しかしながら、この方法では、少なくとも以下３つのケースでサービスポートを誤判別する事象が発生してしまう。
［第１のケース］ミラーするスイッチの特性により、最初に送られたパケットより後に送られたパケットが先にミラーポートに入ってくる場合がある。この場合、後続パケットをフロー先頭パケットとして受信処理することになるため誤判別が生じる
［第２のケース］運用中のネットワークに、トラフィック分析装置を後付けする形でトラフィックミラーリングを開始する場合、設置前に始まっていた通信フローは先頭パケットを観測できないため、サービスポートを誤判別する可能性がある
［第３のケース］ある一種のブロードキャスト通信として、ある機器がブロードキャストでネットワーク全体にリクエストを発信し、それを受信した機器がリクエストに対する応答パケットを送信するような通信を考える。このような通信では、ブロードキャストリクエストパケットは、送信元アドレスがリクエスト発信元のＩＰアドレス、宛先アドレスがネットワークセグメントのブロードキャストＩＰアドレスとなる。一方応答パケットは、送信元アドレスが応答パケット発信元のＩＰアドレス、宛先アドレスがリクエスト送信元のＩＰアドレスとなり、リクエストパケットと応答パケットでＩＰアドレスの組が異なるため別の通信フロー扱いになる。このとき、応答パケットの送信元ポート番号および宛先ポート番号はリクエストパケットのポート番号を反転させたものとなる場合が多いため、応答パケットの通信フローのサービスポートはリクエストパケットの送信元ポート番号と一致する。一般にクライアント側のポート番号はフローが発生する度に異なる値が設定されるため、応答パケットのサービスポートは通信フロー発生の度に異なるポート番号とみなされてしまう。これにより、例えば普段と異なるサービスにアクセスした通信を異常検出する場合に、このようなブロードキャスト通信が発生する度に異常検出し、誤検出が多発することになる。そのため応答パケットのサービスポート番号は、送信元ポート番号（つまりリクエストパケットの宛先ポート番号）とみなした方が適切な場合が多いと考えられる。またこのようなブロードキャストリクエストパケットとその応答パケットはひとまとまりの通信として扱うことが望ましい場合もあると考えられる。上記一番目と二番目の誤判別ケースは、ＴＣＰ通信の場合、ＴＣＰ制御フラグのＳＹＮフラグの情報によってサービスポートを識別することが可能だが、誤判別二番目のケースでＳＹＮフラグを取り逃した場合は識別できない。またＵＤＰ通信の場合は、ＴＣＰ通信のように制御フラグがないため、フローの先頭パケットを確実に把握する方法がない。また上記三番目のブロードキャスト通信のケースで示されるように、通信フロー単位でのサービスポート識別にも課題がある。
［第１のケース］ミラーするスイッチの特性により、最初に送られたパケットより後に送られたパケットが先にミラーポートに入ってくる場合がある。この場合、後続パケットをフロー先頭パケットとして受信処理することになるため誤判別が生じる
［第２のケース］運用中のネットワークに、トラフィック分析装置を後付けする形でトラフィックミラーリングを開始する場合、設置前に始まっていた通信フローは先頭パケットを観測できないため、サービスポートを誤判別する可能性がある
［第３のケース］ある一種のブロードキャスト通信として、ある機器がブロードキャストでネットワーク全体にリクエストを発信し、それを受信した機器がリクエストに対する応答パケットを送信するような通信を考える。このような通信では、ブロードキャストリクエストパケットは、送信元アドレスがリクエスト発信元のＩＰアドレス、宛先アドレスがネットワークセグメントのブロードキャストＩＰアドレスとなる。一方応答パケットは、送信元アドレスが応答パケット発信元のＩＰアドレス、宛先アドレスがリクエスト送信元のＩＰアドレスとなり、リクエストパケットと応答パケットでＩＰアドレスの組が異なるため別の通信フロー扱いになる。このとき、応答パケットの送信元ポート番号および宛先ポート番号はリクエストパケットのポート番号を反転させたものとなる場合が多いため、応答パケットの通信フローのサービスポートはリクエストパケットの送信元ポート番号と一致する。一般にクライアント側のポート番号はフローが発生する度に異なる値が設定されるため、応答パケットのサービスポートは通信フロー発生の度に異なるポート番号とみなされてしまう。これにより、例えば普段と異なるサービスにアクセスした通信を異常検出する場合に、このようなブロードキャスト通信が発生する度に異常検出し、誤検出が多発することになる。そのため応答パケットのサービスポート番号は、送信元ポート番号（つまりリクエストパケットの宛先ポート番号）とみなした方が適切な場合が多いと考えられる。またこのようなブロードキャストリクエストパケットとその応答パケットはひとまとまりの通信として扱うことが望ましい場合もあると考えられる。上記一番目と二番目の誤判別ケースは、ＴＣＰ通信の場合、ＴＣＰ制御フラグのＳＹＮフラグの情報によってサービスポートを識別することが可能だが、誤判別二番目のケースでＳＹＮフラグを取り逃した場合は識別できない。またＵＤＰ通信の場合は、ＴＣＰ通信のように制御フラグがないため、フローの先頭パケットを確実に把握する方法がない。また上記三番目のブロードキャスト通信のケースで示されるように、通信フロー単位でのサービスポート識別にも課題がある。
【0006】
以上のように、通信トラフィックログ分析では、サービスポートの誤判別を低減し判別精度を向上させる仕組みが求められているが、このような課題に対しては、従来特許文献１、２の記載技術が存在する。
【0007】
特許文献１では、トラフィックミラーリングで取得されるパケットの到着順序が変わって受信してしまう課題に対して、ＴＣＰヘッダやＩＰヘッダに含まれるシーケンス番号を用いて、パケット到着順序を整える方法について言及されている。また、特許文献２では、制御ネットワークの異常検知のために、トラフィックミラーリングで取得される通信トラフィックをフロー単位に分析して異常検知する方法について言及されている。
【先行技術文献】
【特許文献】
【0008】
【特許文献1】特開２０１４－１８３４８３号公報
【特許文献2】特開２０２０－６１６６７号公報
【発明の概要】
【発明が解決しようとする課題】
【0009】
特許文献１の記載技術では、通信プロトコルとしてコネクション指向のプロトコルが利用される必要があり、ＵＤＰのサービスポート誤判別のケースには対応できない。また、特許文献１の記載技術では、前述の第２と第３のケースに対処することができない。さらに、特許文献２の記載技術では、サービスポートの判定に送信元ポート番号と宛先ポート番号の小さい方の値を用いており、サービスポート誤判別の課題について考慮されていない。
【0010】
以上のような従来技術における問題に鑑みて、通信トラフィックのデータからサービスポートを判別する際の精度を向上させることができる通信分析装置、通信分析プログラム及び通信分析方法が望まれている。
【課題を解決するための手段】
【0011】
第１の本発明の通信分析装置は、分析対象のネットワーク上を流れる通信トラフィックデータを通信フローごとに分類する通信フロー処理手段と、前記通信フローごとに、前記通信フローを構成するパケットのヘッダ情報に基づくフロー情報を用いてサービスポートを判定するサービスポート判定処理を行うサービスポート判定手段と、前記ネットワーク上で分析対象となるＩＰアドレスごとに、サービスポートの一覧であるサービスポートリストを管理するサービスポートリスト管理手段と、フロー情報だけでサービスポートが特定できない前記通信フローに対して、前記サービスポートリスト管理手段が管理する前記サービスポートリストを用いてサービスポートを推定するサービスポート推定処理を行うサービスポート推定手段とを備え、前記サービスポート判定手段は、フロー情報だけでサービスポートが特定できない前記通信フローについては前記サービスポート推定手段による前記サービスポート推定処理の結果を前記サービスポート判定処理の結果とすることを特徴とする。
【0012】
第２の本発明の通信分析プログラムは、コンピュータを、分析対象のネットワーク上を流れる通信トラフィックデータを通信フローごとに分類する通信フロー処理手段と、前記通信フローごとに、前記通信フローを構成するパケットのヘッダ情報に基づくフロー情報を用いてサービスポートを判定するサービスポート判定処理を行うサービスポート判定手段と、前記ネットワーク上で分析対象となるＩＰアドレスごとに、サービスポートの一覧であるサービスポートリストを管理するサービスポートリスト管理手段と、フロー情報だけでサービスポートが特定できない前記通信フローに対して、前記サービスポートリスト管理手段が管理する前記サービスポートリストを用いてサービスポートを推定するサービスポート推定処理を行うサービスポート推定手段として機能させ、前記サービスポート判定手段は、フロー情報だけでサービスポートが特定できない前記通信フローについては前記サービスポート推定手段による前記サービスポート推定処理の結果を前記サービスポート判定処理の結果とすることを特徴とする。
【0013】
第３の本発明は、通信分析装置が行う通信分析方法において、前記通信分析装置は、通信フロー処理手段、サービスポート判定手段、サービスポートリスト管理手段及びサービスポート推定手段を備え、前記通信フロー処理手段は、分析対象のネットワーク上を流れる通信トラフィックデータを通信フローごとに分類し、前記サービスポート判定手段は、前記通信フローごとに、前記通信フローを構成するパケットのヘッダ情報に基づくフロー情報を用いてサービスポートを判定するサービスポート判定処理を行い、前記サービスポートリスト管理手段は、前記ネットワーク上で分析対象となるＩＰアドレスごとに、サービスポートの一覧であるサービスポートリストを管理し、前記サービスポート推定手段は、フロー情報だけでサービスポートが特定できない前記通信フローに対して、前記サービスポートリスト管理手段が管理する前記サービスポートリストを用いてサービスポートを推定するサービスポート推定処理を行い、前記サービスポート判定手段は、フロー情報だけでサービスポートが特定できない前記通信フローについては前記サービスポート推定手段による前記サービスポート推定処理の結果を前記サービスポート判定処理の結果とすることを特徴とする。
【発明の効果】
【0014】
本発明によれば、通信トラフィックのデータからサービスポートを判別する際の精度を向上させることができる。
【図面の簡単な説明】
【0015】
【図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】第３の実施形態の変形実施例に係るサービスポートリスト管理部が、注目ポートについてサービスポート判定処理への移行判定処理を行う際の流れについて示したフローチャート（その２）である。
【発明を実施するための形態】
【0016】
（Ａ）第１の実施形態
以下、本発明による通信分析装置、通信分析プログラム及び通信分析方法の第１の実施形態を、図面を参照しながら詳述する。
以下、本発明による通信分析装置、通信分析プログラム及び通信分析方法の第１の実施形態を、図面を参照しながら詳述する。
【0017】
（Ａ－１）第１の実施形態の構成
図２は、第１の実施形態に関係する各装置の接続関係について示したブロック図である。
図２は、第１の実施形態に関係する各装置の接続関係について示したブロック図である。
【0018】
ここでは、通信分析装置１０は、監視対象（分析対象）となる監視対象ネットワークＮ１に接続された通信装置（ノード）としての監視対象機器３０（３０ー１、３０－２、・・・）から発生するトラフィックを分析する処理を行うものであるものとする。図２の構成例では、監視対象ネットワークＮ１には、ネットワーク機器として、ネットワークスイッチ２０（レイヤ２スイッチ）とゲートウェイ４０（例えば、ファイアウォールの機能に対応するゲートウェイ）が配置されているものとする。なお、監視対象ネットワークＮ１に接続される監視対象機器３０の種類（用途や機能）は限定されないものであり、ＩｏＴ機器に限定されず種々の装置とするようにしてもよい。
【0019】
図２の構成例では、各監視対象機器３０が、ネットワークスイッチ２０（少なくともレイヤ２スイッチの機能を備えるスイッチ）に接続されており、ネットワークスイッチ２０とインターネットＮ２との間にはゲートウェイ４０が接続されている。したがって、図２の例では、各監視対象機器３０は、ネットワークスイッチ２０とゲートウェイ４０を経由してインターネットＮ２と通信可能な状態になっている。また、ネットワークスイッチ２０では、接続される監視対象機器３０等の数は限定されないものであり、運用中に増減する場合もあるものとして説明する。
【0020】
この実施形態では、監視対象ネットワークＮ１は、１又は複数の監視対象となるセグメント（以下、「監視ネットワークセグメント」と呼ぶ）で構成されているものとする。ここでは、１つのセグメントは、１つのネットワークアドレス（例えば、ｘｘｘ．ｙｙｙ．ｚｚｚ．０／２４）で示される１つのブロードキャストドメインを指すものとする。例えば、ｘｘｘ．ｙｙｙ．ｚｚｚ．３／２４は、ｘｘｘ．ｙｙｙ．ｚｚｚ．０／２４のセグメントに所属するＩＰアドレスとなる。そして、この実施形態では、監視ネットワークセグメントは、監視対象ネットワークＮ１を構成するセグメントであるものとして説明する。言い換えると、各監視対象機器３０は、いずれかの監視ネットワークセグメントに接続していることになる。また、この実施形態では、各監視対象機器３０は、いずれかの監視ネットワークセグメント上のＩＰアドレスが付与されており、他のノードとＩＰ通信を行うものとする。
【0021】
図２の例では、通信分析装置１０は、ネットワークスイッチ２０に接続されているものとする。ここでは、ネットワークスイッチ２０において、ゲートウェイ４０と接続するＬＡＮポート（イーサネット（登録商標）ポート）で送受信されるパケット（イーサネットフレーム）が、通信分析装置１０が接続するポートにミラーリングされる設定（いわゆるポートミラー接続）となっているものとする。これにより、通信分析装置１０では、ネットワークスイッチ２０の配下の接続端末（監視対象機器３０）とインターネットＮ２との間を流れるトラフィック（パケット）を収集することができる。この実施形態では、ネットワークスイッチ２０のポートミラー設定により、通信分析装置１０に監視対象機器３０が送受信する通信トラフィックに基づくデータ（以下、単に「通信トラフィックデータ」とも呼ぶ）を供給する構成となっているが、通信分析装置１０に通信トラフィックデータを供給する具体的な構成については限定されないものである。なお、図１に示す監視対象ネットワークＮ１の構成は一例であり、通信分析装置１０に通信トラフィックデータを供給可能な構成であれば種々の構成とするようにしてもよい。
【0022】
次に、通信分析装置１０の内部構成について説明する。
【0023】
図１は、通信分析装置１０の機能的構成について示したブロック図である。
【0024】
この実施形態における通信分析装置１０は、トラフィックキャプチャ部１１、制御部１２、サービスポート判定部１３、ブロードキャスト処理部１４、サービスポート推定部１５、サービスポートリスト管理部１６、通信パターン学習部１７、記憶部１８及びタイマ部１９を有している。
【0025】
通信分析装置１０は、全てハードウェア（例えば、専用チップ等）により構成するようにしてもよいし一部又は全部についてソフトウェア（プログラム）として構成するようにしてもよい。通信分析装置１０は、例えば、プロセッサ及びメモリを有するコンピュータにプログラム（この実施形態の通信分析プログラムを含む）をインストールすることにより構成するようにしてもよい。
【0026】
トラフィックキャプチャ部１１は、外部（例えば、ネットワークスイッチやルータのミラーポート；この実施形態では、ネットワークスイッチ２０）から通信トラフィックを構成するパケット（ＩＰパケット）を受信する機能を担っている。トラフィックキャプチャ部１１は、受信したパケットを制御部１２に通知する。
【0027】
制御部１２は、通信分析装置１０による全体の処理を制御する機能を担っている。
【0028】
制御部１２は受信したパケットを、通信フロー単位に管理（分類）して管理する処理を行う。通信フローは、送信元ＩＰアドレス、送信元ポート番号、宛先ＩＰアドレス、宛先ポート番号、プロトコル（ＴＣＰまたはＵＤＰ）の５－ｔｕｐｌｅｓの組で識別される。制御部１２は、５－ｔｕｐｌｅｓが一致するパケット、および送信元のＩＰアドレスおよびポート番号と宛先のＩＰアドレスおよびポート番号を入れ替えた５－ｔｕｐｌｅｓが一致するパケットが同一の通信フローと判断する。制御部１２は、一連の通信フローの各パケットのパケットサイズ、パケットの通信方向（送信元ＩＰから宛先ＩＰへの通信か、宛先ＩＰから送信元ＩＰへの通信かの情報）を保持する。またＴＣＰの通信フローの場合、各パケットのＴＣＰ制御フラグ（例えば、ＦＩＮ、ＳＹＮ、ＲＳＴ、ＰＳＨ、ＡＣＫ、ＵＲＧ等）も保持する。なお、以下では、通信分析装置１０において、処理対象（処理中）の通信フローについて「注目通信フロー」とも呼ぶものとする。
【0029】
制御部１２は、通信フローごとのサービスポートの情報を保持（管理）する処理も行う。制御部１２は通信フローごとのサービスポートの情報を得るために、サービスポート判定部１３に通信フローの情報（５－ｔｕｐｌｅｓ、パケットサイズ、パケットの通信方向、ＴＣＰの場合はＴＣＰ制御フラグ）を通知し、サービスポート判定を要求し、その応答としてサービスポート番号を受信する。制御部１２は、サービスポート判定部１３からサービスポートの情報を受ける際に、通信フローがブロードキャスト通信に係るものであった場合、ブロードキャスト通信の進行度情報を代わりに受信する。ブロードキャスト通信の進行度情報の詳細については、後述のブロードキャスト処理部１４の説明においてで詳述するが、ブロードキャスト要求、ブロードキャスト応答、ユニキャストアクセスの３段階からなる。
【0030】
制御部１２は、サービスポート判定部１３から、通信フローごとのサービスポート番号を受けると、通信フローの情報（５－ｔｕｐｌｅｓ、サービスポート番号）をサービスポートリスト管理部１６に通知する。
【0031】
制御部１２は、通信フロー毎にタイムアウト時間を設け、当該通信フローのパケットを最後に受信した時刻からタイムアウトまでの間、当該通信フローのパケットを受信しなかった場合、通信フローが終了したと判断する。制御部１２はパケットを受信すると、受信したパケットの通信フローに関するタイムアウト時間を再設定し、タイマ部１９にタイマのセットを要求する。制御部１２は、通信フローがタイムアウトした場合、当該通信フローについてサービスポート判定部１３にサービスポートの判定を要求する。このとき、サービスポート判定部１３にはタイムアウトされたフローであるという情報が合わせて通知される。
【0032】
制御部１２は、通信フローがタイムアウトした場合またはＴＣＰで通信フローが終了したと判断できる（ＴＣＰ制御フラグでＦＩＮがＯＮのパケットとＦＩＮ／ＡＣＫがＯＮのパケットが観測された）場合と、通信フローの受信パケット数が予め定めた閾値以上に達した場合に、記憶部１８に、通信フローの５－ｔｕｐｌｅｓ、パケットサイズのリスト、通信方向のリスト、サービスポート（サービスポートが未判定の場合は空であることを示すデータ（例えば、ＮＵＬＬ等の空を示すコード）が入る）、及びブロードキャスト進行度情報（ブロードキャスト関連の通信フローでない場合は空文字が入る）を含む情報を、「通信フロー履歴情報」として保存する。そして、制御部１２は、通信フロー履歴情報の保存後、保持している当該通信フローに関する情報を削除する。
【0033】
サービスポート判定部１３は、通信フローの情報（以下、「通信フロー情報」とも呼ぶ）として、５－ｔｕｐｌｅｓ、パケットサイズ、パケットの通信方向、ＴＣＰ制御フラグ及びタイムアウト情報（タイムアウトしているか否かを示す情報）を含む情報を受信すると、受信した通信フロー情報を使用して通信フローのサービスポートを判定する機能を担っている。
【0034】
サービスポート判定部１３は、受信した注目通信フローがＴＣＰの場合、まずＴＣＰ制御フラグからサービスポートの判定を試みる。具体的には、ＴＣＰ制御フラグでＳＹＮフラグのみがＯＮのパケットが含まれる場合、当該パケットはクライアントからサーバへの接続要求と判断できるため、サービスポート判定部１３は、当該パケットの通信方向情報から宛先側のポート番号を求めサービスポートと判定する。またＴＣＰ制御フラグにＳＹＮとＡＣＫのフラグがＯＮのパケットが含まれる場合、当該パケットはサーバからクライアントへのＳＹＮパケットに対する応答パケットと判断できるため、サービスポート判定部１３は、当該パケットの通信方向情報から送信側のポート番号を求め、注目通信フローのサービスポートと判定する。上記いずれの条件にも合致するパケットが無い場合、サービスポート判定部１３は、注目通信フローの通信パターンからサービスポートの推定を試みる。そのために、サービスポート判定部１３は、通信フローのパケット数が閾値以上、または注目通信フローがタイムアウトされたものである時に、サービスポート推定部１５に、５－ｔｕｐｌｅｓ、パケットサイズ及び通信方向を通知し、サービスポートの推定を要求する。サービスポート推定部１５からサービスポートの推定結果が通知されると、当該ポートを注目通信フローのサービスポートと判定する。注目通信フローのパケット数が閾値未満かつタイムアウト情報が無い場合、またサービスポート推定部１５から判定不能を通知された場合、サービスポート判定部１３は、注目通信フローについて判定不能（サービスポートの判定不能）と判定する。
【0035】
サービスポート判定部１３は、受信した注目通信フローがＵＤＰの場合、５－ｔｕｐｌｅｓの情報をブロードキャスト処理部１４に通知し、ブロードキャスト関連パケットか否かの判定を要求する。サービスポート判定部１３は、ブロードキャスト処理部１４からブロードキャストの進行度情報が通知された場合、注目通信フローをブロードキャスト関連の通信フローと判断する。また、サービスポート判定部１３は、ブロードキャスト処理部１４からブロードキャスト通信関連でないと通知を受けた場合、サービスポート判定部１３は、注目通信フローの通信パターンから注目通信フローのサービスポートの推定を試みる。そこで、この実施形態の例において、サービスポート判定部１３は、通信フローのパケット数が閾値以上、または注目通信フローがタイムアウトされたものである時に、サービスポート推定部１５に、５－ｔｕｐｌｅｓ、パケットサイズ、通信方向を通知し、注目通信フローのサービスポートの推定を要求する。サービスポート推定部１５からサービスポートが通知されると、当該ポートを注目通信フローのサービスポートと判定する。通信フローのパケット数が閾値未満かつタイムアウト情報が無い場合、またサービスポート推定部１５から判定不能を通知された場合は、サービスポート判定部１３は、注目通信フローについて判定不能（サービスポートの判定不能）と判定する。
【0036】
サービスポート判定部１３は、サービスポートが判定できた場合（判定結果が判定不能でない場合）はサービスポート番号を、ＵＤＰでブロードキャスト関連と判定した場合はブロードキャスト進行度情報を、それ以外の場合は判定不能を制御部１２に通知する。
【0037】
ブロードキャスト処理部１４は、ブロードキャスト通信の通信フローを管理する機能を担っている。
【0038】
図３は、ブロードキャスト通信の通信フローを管理する処理（実施形態に係るブロードキャスト管理方法）の例について示した図である。
【0039】
図３（ａ）～（ｃ）は、それぞれブロードキャスト通信の段階ごとの手順（通信）について示している。以下では、図３（ａ）～（ｃ）に示す通信の手順を、それぞれ第１～第３の手順と呼ぶものとする。ここで、想定するブロードキャスト通信の通信フローは、図３に示すような２段階（第１の手順と第２の手順））または３段階（第１の手順から第３の手順）の通信によって構成されるものとして説明する。
【0040】
第１手順の通信は、ブロードキャスト要求通信であり、図３（ａ）では、ある監視対象機器３０（ｘｘｘ．ｙｙｙ．ｚｚｚ．２／２４）から、所属するネットワークセグメントのブロードキャストＩＰアドレス（ｘｘｘ．ｙｙｙ．ｚｚｚ．２５５）宛に送出されるパケットを表している。
【0041】
ブロードキャスト処理部１４は、ブロードキャスト要求か否かの判定について、宛先ＩＰアドレスがブロードキャストＩＰアドレスに該当するか否かで行い、ブロードキャスト要求と判定した場合、進行度情報として「ブロードキャスト要求」を設定し、送信元ＩＰアドレスと宛先ポート番号の組をリスト（以下、「ブロードキャスト応答待ちリスト」と呼ぶ）として保持する。ブロードキャスト処理部１４は、ブロードキャスト応答待ちリストに登録された組（送信元ＩＰアドレスと宛先ポート番号の組）について、登録された要素（送信元ＩＰアドレスと宛先ポート番号の組）に対するタイムアウト時間の設定を、タイマ部１９に要求する。ブロードキャスト処理部１４は、タイマ部１９からタイムアウトの通知を受信すると、対応する組（送信元ＩＰアドレスと宛先ポート番号の組）をブロードキャスト応答待ちリストから削除する。
【0042】
第２段階の通信は、ブロードキャスト応答通信であり、図３（ｂ）では、ブロードキャスト要求パケットを受信した監視対象機器３０がブロードキャスト要求の送信元機器宛に送出するパケットを表している。
【0043】
図３（ｂ）では「ｘｘｘ．ｙｙｙ．ｚｚｚ．３」と「ｘｘｘ．ｙｙｙ．ｚｚｚ．５」の二つの監視対象機器３０からブロードキャスト応答が送出される様子を表している。ブロードキャスト処理部１４は、ブロードキャスト応答か否かの判定について、宛先ＩＰアドレスと送信元ポート番号の組がブロードキャスト応答待ちリストに含まれるか否かで行い、ブロードキャスト応答と判定された場合、進行度情報として「ブロードキャスト応答」を設定し、宛先ＩＰアドレスと送信元ＩＰアドレスの組をリスト（以下、このリストを「ユニキャストアクセス待ちリスト」と呼ぶ）として保持する。ユニキャストアクセス待ちリストに登録された場合、登録された要素（宛先ＩＰアドレスと送信元ＩＰアドレスの組）に対するタイムアウト時間の設定を、タイマ部１９に要求する。ブロードキャスト処理部１４は、タイマ部１９から、ユニキャストアクセス待ちリストに登録された組に対応するタイマアウトの通知を受信すると、タイムアウトに対応する組をユニキャストアクセス待ちリストから削除する。
【0044】
第３段階の通信は、ユニキャストアクセス通信であり、図３（ｃ）では、ブロードキャスト要求の送信元機器からブロードキャスト応答を送信した監視対象機器３０に対してユニキャストで送出されるパケットを表している。ブロードキャスト処理部１４は、ユニキャストアクセスか否かの判定について、送信元ＩＰアドレスと宛先ＩＰアドレスの組がユニキャストアクセス待ちリストに含まれるか否かで行う。ブロードキャスト処理部１４は、ユニキャストアクセスと判定された組に対応する進行度情報として「ユニキャストアクセス」を設定し、ユニキャストアクセス待ちリストから当該組を削除する。
【0045】
ブロードキャスト処理部１４は、上記３段階の判定でいずれかの進行度情報が設定された場合、設定された進行度情報をサービスポート判定部１３に通知する。また進行度情報が設定されなかった場合「ブロードキャスト通信関連でない」という情報（若しくは空であることを示すデータ（例えば、ＮＵＬＬ等の空を示すコード））をサービスポート判定部１３に通知する。
【0046】
サービスポート推定部１５は、監視対象機器３０毎のサービスポートリストおよび各サービスポートに対応する通信パターン分析モデルを用いて、受信した通信フローのサービスポートを推定する機能を担っている。サービスポートリストは、後述するサービスポートリスト管理部１６によって作成され、監視対象機器３０毎に当該監視対象機器３０がクライアントとしてアクセスするサービスポートのリストと、当該監視対象機器３０がサーバとしてアクセスされるサービスポートのリストがＴＣＰとＵＤＰそれぞれに存在する。つまり、サービスポート推定部１５では、監視対象機器３０毎に４種類のサービスポートリストを保持しているものとする。通信パターン分析モデルは、後述の通信パターン学習部１７でサービスポートの通信の振舞いを機械学習した学習モデルである。サービスポート推定部１５は、サービスポートリストの要素（ポート番号）毎に一つの学習モデルを保持しているものとする。
【0047】
以下では、サービスポートリストを構成する上記の４種類のサービスポートリストを「サブリスト」とも呼ぶものとする。言い換えると、サービスポートリストは、４つのサブリストにより構成されているものとする。つまり、サービスポートリストには、サーバとしてアクセスされるサービスポートのリストである第１のサブリストと、クライアントとしてアクセスするサービスポートのリストである第２のサブリストが含まれている。そして、サービスポートリストには、プロトコルごと（ＴＣＰとＵＤＰのそれぞれ）の第１のサブリスト及び第２のサブリスト（つまり計４つのサブリスト）が含まれていることになる。
【0048】
サービスポート推定部１５は、受信した通信フローの送信元ＩＰアドレスおよび宛先ＩＰアドレスがいずれかの監視ネットワークセグメントに所属するものであるか否かを判定する。
【0049】
この実施形態では、予め記憶部１８に、監視ネットワークセグメントの情報（例えば、監視対象ネットワークＮ１を構成する各セグメントに対応するネットワークアドレスのリスト）が保持されているものとし、サービスポート推定部１５は、記憶部１８に保持された情報に基づいて監視ネットワークセグメントを把握するものとする。サービスポート推定部１５は、注目通信フローの送信元ＩＰアドレスが監視ネットワークセグメントのものである場合、記憶部１８から当該ＩＰアドレスのサービスポートリストを取得する。また、サービスポート推定部１５は、宛先ＩＰアドレスが監視ネットワークセグメントのものである場合、記憶部１８から当該ＩＰアドレスサービスポートリストを取得する。さらに、サービスポート推定部１５は、注目通信フローのＩＰアドレス（送信元ＩＰアドレス又は宛先ＩＰアドレス）が監視ネットワークセグメント外である場合は、当該ＩＰアドレスに対して空のサービスポートリストを付与するものとする。
【0050】
サービスポート推定部１５は、注目通信フローの送信元ポート番号がサービスポートか否かの推定を行う。まず、サービスポート推定部１５は、注目通信フローの送信元ＩＰアドレスのサーバとしてアクセスされるサービスポートリストに当該ポート番号（注目通信フローの送信元ポート番号）が含まれるか確認する。サービスポート推定部１５は、当該ポート番号が含まれる場合、記憶部１８から対応する分析モデル（通信フローに基づく特徴量を入力することで「一致又は不一致」を判定するとともに「一致度合の数値」を出力する判定器；以下、「通信パターン分析モデル」と呼ぶ）を取得する。次に、サービスポート推定部１５は、注目通信フローのパケットサイズおよび通信方向の情報を使って通信パターン分析モデルに適用するための特徴量に変換する。通信パターン分析モデルとしては、例えば、種々のＡＩで用いられる学習器で得られる学習モデルを適用することができる。
【0051】
図４は、通信フローを示す特徴量の例について示した図である。
【0052】
ここでは、サービスポート推定部１５は、通信フローについて図４に示すような特徴量（例えば、ＤＮＮ（Ｄｅｅｐ Ｎｅｕｒａｌ Ｎｅｔｗｏｒｋ）等のニューラルネットワークで処理可能なベクトル形式のデータ）に変換して処理するものとする。図４では、通信フローを、総パケット数（送受信したパケットの総数）、総パケットバイト数（送受信したパケットのデータ量を合計したバイト数）、送信パケット数、送信パケット総バイト数、送信パケット平均バイト数、受信パケット数、受信パケット総バイト数及び受信パケット平均バイト数のパラメータで構成される特徴量（ベクトル）として表している。なお、上記の特徴量の構成については図４に示すパラメータの組み合わせに限定されないものである。例えば、図４に示すパラメータの一部を除外した組み合わせを上記の特徴量とするようにしてもよいし、その他のパラメータを上記の特徴量に追加するようにしてもよい。
【0053】
サービスポート推定部１５は、注目通信フローについて図４に示すような形式に変換した特徴量を取得した通信パターン分析モデルに適用（判定器として適用）し、結果として、「一致」若しくは「不一致」の２値情報と一致度合（０～１の範囲で表される数値）を得る。なお、サービスポート推定部１５は、一致度合については判定結果が一致の場合のみ得るものとする。
【0054】
一方、当該ポート番号（注目通信フローの送信元ポート番号）がサービスポートリスト（サーバとしてアクセスされるサービスポートリスト）に含まれない場合、サービスポート推定部１５は、当該ポートに対する判定結果として「リスト外ポート」という情報を得るものとする。
【0055】
同様に、サービスポート推定部１５は、注目通信フローの宛先ＩＰアドレスについて、当該ＩＰアドレスのクライアントとしてのサービスポートリストに当該ポート番号が含まれるかを確認し、前述と同様の手順で、当該ポート番号について、「一致」（一致の場合は一致度合）若しくは「不一致」若しくは「リスト外ポート」という情報を得る。具体的には、サービスポート推定部１５は、注目通信フローの宛先ＩＰアドレスのクライアントとしてアクセスするサービスポートリストに当該ポート番号（注目通信フローの宛先ポート番号）が含まれるか確認する。サービスポート推定部１５は、当該ポート番号が含まれる場合、記憶部１８から対応する通信パターン分析モデルを取得する。次に、サービスポート推定部１５は、注目通信フローのパケットサイズおよび通信方向の情報を使って通信パターン分析モデルに適用するための特徴量に変換して、取得した通信パターン分析モデルに適用し、「一致」（一致の場合は一致度合）若しくは「不一致」の情報を得る。一方、当該ポート番号（注目通信フローの宛先ポート番号）がサービスポートリスト（クライアントとしてアクセスするサービスポートリスト）に含まれない場合、サービスポート推定部１５は、当該ポート番号に対する判定結果として「リスト外ポート」という情報を得る。
【0056】
サービスポート推定部１５は、以上の結果を用い、注目フローの送信元通信ポートについて、以下の３つの条件（第１～第３の条件）のいずれかに合致する場合、最終的な送信元ポート番号のサービスポート推定結果として「一致」を出力し、以下の３つのいずれの条件にも合致しない場合は最終的な送信元ポート番号のサービスポート推定結果として「不一致」を出力するものとする。
［第１の条件］送信元ＩＰアドレスが監視ネットワークセグメントであり、且つ、送信元ＩＰアドレスに対応する送信元通信ポートの推定結果が「一致」、且つ、宛先ＩＰアドレスが監視ネットワークセグメントであり、且つ、宛先ＩＰアドレスに対応する送信元通信ポートの推定結果が「一致」
［第２の条件］送信元ＩＰアドレスが監視ネットワークセグメントであり、且つ、送信元ＩＰアドレスに対応する送信元通信ポートの推定結果が「一致」、且つ、宛先ＩＰアドレスが監視ネットワークセグメント外
［第３の条件］送信元ＩＰアドレスが監視ネットワークセグメント外、且つ、宛先ＩＰアドレスが監視ネットワークセグメントであり、且つ、宛先ＩＰアドレスに対応する送信元通信ポートの推定結果が「一致」
［第１の条件］送信元ＩＰアドレスが監視ネットワークセグメントであり、且つ、送信元ＩＰアドレスに対応する送信元通信ポートの推定結果が「一致」、且つ、宛先ＩＰアドレスが監視ネットワークセグメントであり、且つ、宛先ＩＰアドレスに対応する送信元通信ポートの推定結果が「一致」
［第２の条件］送信元ＩＰアドレスが監視ネットワークセグメントであり、且つ、送信元ＩＰアドレスに対応する送信元通信ポートの推定結果が「一致」、且つ、宛先ＩＰアドレスが監視ネットワークセグメント外
［第３の条件］送信元ＩＰアドレスが監視ネットワークセグメント外、且つ、宛先ＩＰアドレスが監視ネットワークセグメントであり、且つ、宛先ＩＰアドレスに対応する送信元通信ポートの推定結果が「一致」
【0057】
送信元ポートの推定結果が「一致」の場合で、送信元ＩＰアドレスの推定結果も宛先ＩＰアドレスの推定結果も一致（つまり、上記の第１の条件に合致）の場合、サービスポート推定部１５は、それぞれの一致度合を比較し小さい方の値を送信元ポート番号に対する一致度合とするようにしてもよい。
【0058】
サービスポート推定部１５は、宛先ポート番号についても同様に、宛先ポート番号がサービスポートか否かの推定を行う。つまり、サービスポート推定部１５は、送信元ＩＰアドレスの「クライアントとしてアクセスするサービスポートリスト」、及び宛先ＩＰアドレスの「サーバとしてアクセスされるサービスポートリスト」を使用して、前述の送信元ポート番号に対する処理と同様のサービスポート推定処理を行い、結果として宛先ポート番号に対するサービスポート推定結果（「一致」（一致の場合は一致度合を含む）若しくは「不一致」）を得る。
【0059】
サービスポート推定部１５は、送信元ポート番号の推定結果と宛先ポート番号の推定結果を用いて、注目通信フローに対するサービスポート推定を行う。具体的には、サービスポート推定部１５は、送信元ポート番号に対するサービスポート推定結果が「一致」、且つ、宛先ポート番号に対するサービスポート推定結果が「不一致」の場合、送信元ポート番号を注目通信フローのサービスポートの推定結果とする。また、サービスポート推定部１５は、送信元ポート番号に対するサービスポート推定結果が「不一致」、且つ、宛先ポート番号に対するサービスポート推定結果が「一致」の場合、宛先ポート番号を注目通信フローのサービスポートの推定結果とする。さらに、サービスポート推定部１５は、送信元ポート番号に対するサービスポート推定結果が「不一致」、且つ、宛先ポート番号に対するサービスポート推定結果も「不一致」の場合、「判定不能」を注目通信フローのサービスポートに対する推定結果とする。さらにまた、サービスポート推定部１５は、送信元ポート番号に対するサービスポート推定結果が「一致」、且つ、宛先ポート番号に対するサービスポート推定結果も「一致」の場合、送信元ポート番号に対する推定結果の一致度合（類似度合）と、宛先ポート番号に対する推定結果の一致度合（類似度合）を比較し大きい方のポート番号を、注目通信フローのサービスポートの推定結果とし、一致度合（類似度合）も一致した場合「判定不能」を推定結果とする。そして、サービスポート推定部１５は、注目通信フローのサービスポートの推定結果をサービスポート判定部に通知する。
【0060】
以上のように、サービスポート推定部１５は、送信元ポート番号の推定結果と宛先ポート番号の推定結果を取得する。そして、サービスポート推定部１５は、以上のような処理により得た注目通信フローのサービスポートの推定結果をサービスポート判定部１３に通知する。
【0061】
サービスポートリスト管理部１６は、監視対象機器３０毎に、クライアントとしてアクセスするサービスポートリスト、サーバとしてアクセスされるサービスポートリストをＴＣＰおよびＵＤＰそれぞれに対して作成（つまりプロトコルごとに作成）し、管理する機能を担っている。サービスポートリスト管理部１６は、制御部１２から通信フロー情報（５－ｔｕｐｌｅｓ、サービスポート（サービスポートが未判定の場合は空））を受信すると、注目通信フローのプロトコルがＴＣＰとＵＤＰそれぞれの場合に応じてサービスポートリストの更新処理を行う。
【0062】
サービスポートリスト管理部１６は、注目通信フローのプロトコルがＴＣＰの場合、サービスポート番号が送信元ポート番号と宛先ポート番号のどちらに一致するかを確認する。サービスポートリスト管理部１６は、送信元ポート番号に一致する場合で、且つ、送信元ＩＰアドレスが監視ネットワークセグメント下の場合、送信元ＩＰアドレスのＴＣＰのサーバとしてアクセスされるサービスポートリストに当該ポート番号が含まれなければ追加する。サービスポートリスト管理部１６は、これを宛先ＩＰアドレスのクライアントとしてアクセスするサービスポートリストに対しても同様に行う。サービスポートリスト管理部１６は、サービスポート番号が宛先ポート番号に一致する場合、送信元ＩＰアドレスのＴＣＰのクライアントとしてアクセスするサービスポートリストに当該ポート番号が含まれなければ追加する。サービスポートリスト管理部１６は、これを宛先ＩＰアドレスのサーバとしてアクセスされるサービスポートリストに対しても同様に行う。以上の処理の結果、サービスポートリストに変更が加えられた場合、最新のサービスポートリストを記憶部１８に保存する。
【0063】
サービスポートリスト管理部１６は、注目通信フローのプロトコルがＵＤＰの場合、監視対象機器３０毎にクライアントとしてアクセスするサービスポートの候補リストと、サーバとしてアクセスされるサービスポートの候補リストをサービスポートリストとは別に保持する。
【0064】
サービスポートリスト管理部１６は、サービスポート情報を確認しサービスポートが設定されている場合、当該ポート番号が送信元ポート番号と宛先ポート番号のどちらのポートに一致するかを確認する。サービスポートリスト管理部１６は、送信元ポート番号に一致する場合で、且つ、送信元ＩＰアドレスが監視ネットワークセグメント下の場合、送信元ＩＰアドレスのサーバとしてアクセスされるサービスポートの候補リストに当該ポート番号を追加する。サービスポートリスト管理部１６は、これを宛先ＩＰアドレスのクライアントとしてアクセスするサービスポートの候補リストに対しても同様に行う。サービスポート番号が宛先ポート番号に一致する場合、サービスポートリスト管理部１６は、送信元ＩＰアドレスのクライアントとしてアクセスするサービスポート候補リストに当該ポート番号を追加し、これを宛先ＩＰアドレスのクライアントとしてアクセスするサービスポート候補リストに対しても同様に行う。サービスポートリスト管理部１６は、サービスポートが設定されていない場合は、宛先ポート番号に対して前述のサービスポートの候補リストへの追加処理を行う。ＵＤＰだけこのような例外処理を行うのは、サービスポート判定部１３でのサービスポート判定処理において、ＴＣＰの場合はＴＣＰ制御フラグの情報を使ってサービスポートを判定する手段があるが、ＵＤＰの場合は通信パターン分析による推定以外の判定手段が無いため、サービスポートリストに要素が存在しない状態だとサービスポートが判定されない問題が生じる。そのためサービスポートリスト管理部１６では、サービスポートの候補リストを使用したサービスポートリスト作成手段を有する。サービスポートリスト作成方法は、例えば、サービスポート候補リストに含まれる各ポート番号について、候補リスト内での出現頻度を集計し、出現頻度が他のポート番号に比べて多いポート番号をサービスポートとして抽出するようにしてもよい。サービスポートの抽出方法として、例えば外れ値検出アルゴリズムによって、外れ値と判定された出現頻度に対応するポート番号をサービスポートリストとする方法が考えられる。外れ値検出のアルゴリズムとして、例えば、Ｓｍｉｒｎｏｖ－Ｇｒｕｂｂｓ検定が利用できる。サービスポートリスト管理部１６は、サービスポートリストが変更された場合、最新のサービスポートリストを記憶部１８に保存する。
【0065】
サービスポートリスト管理部１６は、上述のサービスポートリストの作成・更新処理の結果、「サービスポートリストに受信したサービスポート番号が含まれる場合」、または「ＵＤＰでサービスポートの情報が無い場合で、宛先ポート番号がサービスポートリストに含まれる場合」、通信パターン学習部１７に通信フロー情報とサービスポート番号（ＵＤＰでサービスポートの情報が無い場合は宛先ポート番号）を通知する。また、サービスポートリスト管理部１６は、上述のサービスポートリストの作成・更新処理の結果、「サービスポートリストに受信したサービスポート番号が含まれる場合」、または「ＵＤＰでサービスポートの情報が無い場合で、宛先ポート番号がサービスポートリストに含まれる場合」、通信パターン学習部１７に通信フロー情報とサービスポート番号（ＵＤＰでサービスポートの情報が無い場合は宛先ポート番号）を通知する。
【0066】
以上のように、サービスポートリスト管理部１６は、ＩＰアドレスごと（監視対象機器３０ごと）のサービスポートリストを管理する。
【0067】
通信パターン学習部１７は、サービスポートリストに含まれる各サービスポートについて、当該サービスポートの通信フローの通信パターンを機械学習し、入力された注目通信フローが当該サービスポートの通信挙動と一致するか否かを出力する通信パターン分析モデルを構築する機能を担っている。
【0068】
通信パターン学習部１７は、サービスポートリスト管理部１６から通信フロー情報およびサービスポート情報を受信すると、受信したサービスポートと同じサービスポートが設定されているフロー情報（ＵＤＰでサービスポート情報が無い場合は受信した宛先ポート番号と同じ宛先ポート番号のフロー情報）を記憶部１８から取得する。次に、通信パターン学習部１７は、取得したフロー情報から送信元ＩＰアドレスに係るフロー情報を抽出する。つまり、通信パターン学習部１７は、受信したフロー情報の送信元ＩＰアドレスについて、サービスポートが送信元ポート番号と一致する場合、記憶部１８から取得したフロー情報のうち、送信元ＩＰアドレスと送信元ポート番号の組および宛先ＩＰアドレスと宛先ポート番号の組が、受信したフロー情報の送信元ＩＰアドレスと送信元ポート番号の組に一致するものを抽出する。通信パターン学習部１７は、受信したフロー情報の送信元ＩＰアドレスについて、サービスポートが宛先ポート番号と一致する場合、記憶部１８から取得したフロー情報のうち、送信元ＩＰアドレスと宛先ポート番号の組および宛先ＩＰアドレスと送信元ポート番号の組が、受信したフロー情報の送信元ＩＰアドレスと宛先ポート番号の組に一致するものを抽出する。通信パターン学習部１７は、抽出されたフロー情報の件数が閾値（学習に必要な所定のデータ数）以上の場合、送信元ＩＰの当該サービスポート番号に対応する通信パターン分析モデルを構築する。通信パターン学習部１７は、通信パターン分析モデル構築のため、抽出した各フロー情報を図４のような特徴量データに変換する。通信パターン学習部１７は、各フローの特徴量データを学習データとして機械学習器に適用し当該ポート番号の通信挙動を学習する。通信パターン学習部１７に適用する機械学習器（ＡＩのプラットフォーム）については限定されないものであり、種々の学習器を用いることができる。通信パターン学習部１７は、機械学習器として、例えばＯｎｅ Ｃｌａｓｓ ＳＶ Ｍを使用し、学習に使用した特徴量データに近い特徴を持つ特徴量データを正常と判定し、特徴が異なる特徴量データを異常と判定するモデルを構築するようにしてもよい。通信パターン学習部１７は、構築した通信パターン分析モデルを、送信元ＩＰアドレスのサービスポートリストのサービスポートに対応する通信パターン分析モデルとして記憶部１８に保存する。通信パターン学習部１７は、以上の処理を、宛先ＩＰアドレスに対しても同様に実施する。
【0069】
記憶部１８は、サービスポート識別に係る種々の情報を保持する機能を担っている。具体的には、フロー情報、ＩＰアドレス毎にクライアントとしてアクセスするサービスポートリストとサーバとしてアクセスされるサービスポートリスト、サービスポートリストに含まれる各ポート番号に対応する通信パターン分析モデル、監視ネットワークセグメント情報を保持する。
【0070】
タイマ部１９は、制御部１２およびブロードキャスト処理部１４からの要求を受けて、要求された設定値でタイマをセットし、タイムアウトを制御部１２またはブロードキャスト処理部１４に通知する機能を担っている。
【0071】
（Ａ－２）第１の実施形態の動作
次に、第１の実施形態の通信分析装置１０の動作（実施形態に係る通信分析方法）について説明する。
次に、第１の実施形態の通信分析装置１０の動作（実施形態に係る通信分析方法）について説明する。
【0072】
以下では、通信分析装置１０の動作例として、パケットを受信し、通信フローのサービスポートを判定するまでの一連の動作（ステップＳ１００）、ＵＤＰ通信フローにおけるブロードキャスト通信判定動作（ステップＳ２００）、サービスポート推定処理動作（ステップＳ３００）、サービスポートリストの作成・更新動作（ステップＳ４００）、及びサービスポートの通信パターン分析モデルの構築動作（ステップＳ５００）をそれぞれ説明する。
【0073】
【0074】
まず、通信分析装置１０におけるステップＳ１００の動作（パケット受信から通信フローのサービスポート判定までの一連の動作）について図５のフローチャートを用いて説明する。
【0075】
トラフィックキャプチャ部１１は、ミラーポートからパケットを受信すると、受信したパケットを制御部１２に通知する（Ｓ１０１）。
【0076】
次に、制御部１２は、受信したパケットから５－ｔｕｐｌｅｓの情報を抽出し、継続する通信フローのパケットかを確認する。制御部１２が保持する通信フロー情報の中に、受信パケットの５－ｔｕｐｌｅｓと一致する通信フローまたは送信元のＩＰアドレスおよびポート番号と宛先のＩＰアドレスおよびポート番号を入れ替えた５－ｔｕｐｌｅｓが一致する通信フローがあると、継続する通信フローと判断し、一致する通信フローが無い場合は新規の通信フローと判断する。制御部１２は、新規の通信フローと判断した場合は、５－ｔｕｐｌｅｓの情報と、受信パケットのパケットサイズ、通信方向（送信元ＩＰアドレスから宛先ＩＰアドレスへの通信か、宛先ＩＰアドレスから送信元ＩＰアドレスへの通信かの情報）、ＴＣＰの場合はＴＣＰ制御フラグの値、サービスポート（値は空）を管理する通信フロー情報として保持する。また、制御部１２は、当該通信フローが一定期間パケットを受信しなかった時に当該通信フローを破棄するのに使用するタイムアウト時間をタイマ部１９に設定する。さらに、制御部１２は、継続する通信フローと判断した場合は通信フロー情報を更新する（Ｓ１０２）。具体的には、制御部１２は、受信パケットのパケットサイズ、通信方向、プロトコルがＴＣＰの場合はＴＣＰ制御フラグの値を通信フロー情報に追加する。また、制御部１２は、当該通信フローに設定されていたタイムアウト時間を再設定しタイマ部１９に新しいタイムアウト時間を設定する。
【0077】
次に、制御部１２は、受信パケットに対応する注目通信フローの通信フロー情報を参照して、サービスポートの値を確認し（Ｓ１０３）、注目通信フローのサービスポートの値が空（未設定）の場合後述するステップＳ１０７に移行してサービスポート判定部１３に注目通信フローのサービスポート判定を実行させ、当該サービスポートの値が設定済である場合には後述するステップＳ１０４に移行して後述の通信フロー保存条件の判定に進む。
【0078】
上述のステップＳ１０３で注目通信フローのサービスポートの値が空（未設定）の場合、サービスポート判定部１３は、まず、注目通信フローのプロトコルがＴＣＰかＵＤＰかを確認し（Ｓ１０７）、プロトコルがＴＣＰの場合は後述するステップＳ１０８の処理に移行し、そうでない場合には後述するステップＳ２００の処理に移行する。
【0079】
上述のステップＳ１０７で、注目通信フローのプロトコルがＴＣＰだった場合、サービスポート判定部１３は、注目通信フローのＴＣＰ制御フラグの情報からサービスポート判定を試み（Ｓ１０８）、判定成功した場合は後述するステップＳ１０９の処理に移行し、そうでない場合は後述するステップＳ１１１の処理に移行する。具体的には、サービスポート判定部１３は、これまでに受信したパケット（注目通信フローのパケット）の制御フラグの中でＳＹＮフラグのみがＯＮのパケットが含まれる場合、当該パケットはクライアントからサーバへの接続要求と判断できるため、当該パケットの通信方向情報から宛先側のポート番号（送信元ＩＰアドレスから宛先ＩＰアドレスへの通信ならば宛先ポート番号、逆向きの通信ならば送信元ポート番号）を求めサービスポートと判定する。また、制御フラグにＳＹＮとＡＣＫのフラグがＯＮのパケットが含まれる場合、当該パケットはサーバからクライアントへのＳＹＮパケットに対する応答パケットと判断できるため、当該パケットの通信方向情報から送信側のポート番号を求めサービスポートと判定する。
【0080】
上述のステップＳ１０８において、注目通信フローのＴＣＰ制御フラグの情報からサービスポート判定が成功した場合、サービスポート判定部１３は、当該サービスポートを注目通信フローに対する判定結果として決定し、制御部１２に通知する（Ｓ１０９）。
【0081】
上述のステップＳ１０８において、注目通信フローのＴＣＰ制御フラグの情報からサービスポート判定ができなかった場合、サービスポート判定部１３は、後述するステップＳ１１１の処理に移行して、サービスポート推定処理に進む。
【0082】
上述のステップＳ１０７で、注目通信フローのプロトコルがＵＤＰと確認された場合、サービスポート判定部１３は、ブロードキャスト処理部１４に対して、注目通信フローがブロードキャスト通信に係るものであるか否かをブロードキャスト処理部１４に要求する。ブロードキャスト処理部１４は、サービスポート判定部１３の要求に応じて、注目通信フローがブロードキャスト通信であるか否かを判定し（Ｓ２００）、注目通信フローがブロードキャスト通信である場合後述するステップＳ１１３から動作する。
【0083】
ステップＳ２００において、注目通信フローがブロードキャスト通信であると判定された場合、ブロードキャスト処理部１４は、サービスポート判定部１３に対してその旨と共にブロードキャスト進行度情報を通知する。サービスポート判定部１３は、ブロードキャスト処理部１４から注目通信フローがブロードキャスト通信であるとの判定結果を取得すると、ブロードキャスト処理部１４から通知されたブロードキャスト進行度情報を制御部１２への応答とする。この場合、制御部１２は、注目通信フローについて、ブロードキャスト通信であると認識すると共に、ブロードキャスト進行度を認識（決定）する（Ｓ１１３）。
【0084】
一方、ステップＳ２００において、注目通信フローがブロードキャスト通信でないと判定された場合、ブロードキャスト処理部１４は、その旨をサービスポート判定部１３に通知する。サービスポート判定部１３は、注目通信フローがブロードキャスト通信でないという通知を受けた場合、後述するステップＳ１１１の処理に移行して、注目通信フローのサービスポート推定処理に進む。
【0085】
サービスポート判定部１３は、「注目通信フローについてＴＣＰで制御フラグでのサービスポート判定ができなかった場合」、又は「ＵＤＰでブロードキャスト通信と判定されなかった場合」、注目通信フローについてサービスポート推定処理によりサービスポートの判定を行うと判断する。このとき、サービスポート判定部１３は、注目通信フローについてこれまでに受信したパケットがサービスポート推定実施に必要な所定の条件を満たすか否かを判定し（Ｓ１１１）、上記所定の条件を満たすと判定した場合後述するステップＳ３００に移行し、そうでないと判断した場合は後述するステップＳ１１２に移行する。具体的には、サービスポート判定部１３は、注目通信フローのこれまでに受信したパケット数が閾値以上、または一定時間パケットの受信が無くタイムアウトした通信フローの場合に、上記の所定（ステップＳ１１１の条件）の条件を満たすと判定するようにしてもよい。
【0086】
上述のステップＳ１１１で、注目通信フローについてこれまでに受信したパケットが上記の所定の条件を満たす場合、サービスポート判定部１３は、サービスポート推定部１５に注目通信フローのサービスポート推定処理の実行を指示して、その結果を取得する。そして、サービスポート推定部１５は、注目通信フローに対するサービスポート推定処理を行い（Ｓ３００）、結果としてサービスポートが推定できた場合（判定不能でない場合）は、サービスポート判定部１３にサービスポートを通知する。このとき、サービスポート判定部１３は、ステップＳ１０９に移行して受信したポート番号を注目通信フローのサービスポートと決定し、その決定内容を制御部１２に通知する。ステップＳ３００の処理の詳細については後述する。
【0087】
一方、「上述のステップＳ１１１で注目通信フローについてこれまでに受信したパケットが上記の所定の条件を満たさない場合」、又は「上述のステップＳ３００で注目通信フローに対するサービスポート推定処理ができなかった場合」、サービスポート判定部１３は、注目通信フローについてサービスポートが判定不能と決定して、制御部１２にその決定内容（判定結果）を通知する（Ｓ１１２）。
【0088】
以上のように、サービスポート判定部１３は、サービスポート判定結果として、サービスポートが判定できた場合は判定したサービスポート番号、判定できなかった場合は判定不能、ブロードキャスト通信と判定した場合はブロードキャスト進行度情報を制御部１２にそれぞれ通知する。そして、制御部１２は、サービスポート判定部１３からの結果を受けて、注目通信フローが所定の条件を満たすか否か判定し（Ｓ１１０）、所定の条件を満たす場合のみ後述するステップＳ４００の処理を実行し、その後、上述のステップＳ１０４の処理に移行する。制御部１２は、例えば、注目通信フローのプロトコルがＵＤＰの場合、または通信フローのプロトコルがＴＣＰでありかつサービスポート判定部１３からサービスポート番号が通知された場合に上記の所定の条件（ステップＳ１１０の条件）を満たすと判定するようにしてもよい。
【0089】
ステップＳ１１０において上記の所定の条件を満たすと判定された場合、制御部１２は、通信フローの５－ｔｕｐｌｅｓの情報とサービスポート（判定不能の場合は空）の情報をサービスポートリスト管理部１６に通知して、サービスポートリストの作成・更新を実行させる（Ｓ４００）。なお、ステップＳ４００の処理の詳細については後述する。
【0090】
制御部１２は、サービスポートの判定処理が完了すると、注目通信フローについてこれまで受信したパケットの数（量）が所定の条件を満たすか否かを判定し（Ｓ１０４）、所定の条件を満たす場合のみ、５－ｔｕｐｌｅｓの情報、パケットサイズ、通信方向、サービスポート（サービスポートが未判定の場合は空文字）、及びブロードキャスト進行度情報（ブロードキャスト関連の通信フローでない場合は空文字）を含む情報を、記憶部１８に通信フロー履歴情報として保存し（Ｓ１０５）、その後ステップＳ１０６に移行する。なお、制御部１２は、フロー履歴情報保存後、保持している当該通信フローに関する情報を削除する。
【0091】
制御部１２は、例えば、注目通信フローについて、これまでに受信したパケット数が閾値以上、または注目通信フローが終了したと判断できる（ＴＣＰ制御フラグでＦＩＮがＯＮのパケットとＦＩＮ／ＡＣＫがＯＮのパケットが観測された）場合、または注目通信フローがタイムアウトした通信フローである場合に、上記の所定の条件（ステップＳ１０４の条件）を満たすと判断するようにしてもよい。
【0092】
制御部１２は、受信パケットに対応する注目通信フローに対する処理が完了すると、管理する通信フローのうち、タイマ部１９からタイムアウト通知を受けた通信フローが無いかを確認し（Ｓ１０６）、タイムアウトした通信フローがあった場合は、当該通信フローを次の注目通信フローとし、上述のステップＳ１０３に戻って動作する。上述のステップＳ１０６の判定で、タイムアウトした通信フローが無かった場合、制御部１２は、次のパケット受信まで待機し、次のパケット受信があった場合上述のステップＳ１０１から動作することになる。
【0093】
以上のように、通信分析装置１０は、パケット受信に伴う動作を行う。
【0094】
次に、通信分析装置１０におけるステップＳ２００の動作（ブロードキャスト通信判定動作）の詳細について図６のフローチャートを用いて説明する。
【0095】
ここでは、まず、ブロードキャスト処理部１４は、サービスポート判定部１３からＵＤＰの注目通信フローの５－ｔｕｐｌｅｓ情報を受信したものとする（Ｓ２０１）。
【0096】
次に、ブロードキャスト処理部１４は、受信したＵＤＰパケットがブロードキャスト要求か否かの判定を行い（Ｓ２０２）、ブロードキャスト要求である場合は後述するステップＳ２０３の処理から動作し、そうでない場合は後述するステップＳ２０５の処理から動作する。ブロードキャスト処理部１４は、例えば、受信したＵＤＰパケットの宛先ＩＰアドレスが監視ネットワークセグメントのブロードキャストＩＰアドレスである場合（例えば、ＩＰアドレスの末尾が２５５である場合）、注目通信フローについてはブロードキャスト要求と判断するようにしてもよい。
【0097】
ステップＳ２０２において、受信したＵＤＰパケットがブロードキャスト要求であると判断された場合、ブロードキャスト処理部１４は、ブロードキャスト応答待ちリストに、注目通信フローの送信元ＩＰアドレスと宛先ポート番号の組を保存し、当該組に対するタイムアウトタイマーをタイマ部１９でセットする（Ｓ２０３）。そして、ブロードキャスト処理部１４は、受信したＵＤＰパケットに対応する組（注目通信フローの送信元ＩＰアドレスと宛先ポート番号の組）のブロードキャスト進行度として「ブロードキャスト要求」のステータスを設定し（Ｓ２０４）、後述するステップＳ２１２の処理に移行する。
【0098】
ステップＳ２０２において、受信したＵＤＰパケットがブロードキャスト要求でないと判断された場合、ブロードキャスト処理部１４は、受信したＵＤＰパケットがブロードキャスト応答であるか否かの判定を行い（Ｓ２０５）、ブロードキャスト応答であると判断した場合は後述するステップ２０６の処理に移行し、そうでない場合は後述するステップＳ２０８の処理に移行する。ブロードキャスト処理部１４は、受信したＵＤＰパケットの宛先ＩＰアドレスと送信元ポート番号の組がブロードキャスト応答待ちリストに含まれている場合、当該ＵＤＰパケットをブロードキャスト応答と判断するようにしてもよい。
【0099】
ステップＳ２０５において、受信したＵＤＰパケットがブロードキャスト応答であると判断された場合、ブロードキャスト処理部１４は、ユニキャストアクセス待ちリストに受信したＵＤＰパケットの宛先ＩＰアドレスと送信元ＩＰアドレスの組を保存し、当該組に対するタイムアウトタイマーをタイマ部１９でセットする（Ｓ２０６）。そして、ブロードキャスト処理部１４は、受信したＵＤＰパケットに対応する組（注目通信フローの送信元ＩＰアドレスと宛先ポート番号の組）のブロードキャスト進行度として「ブロードキャスト応答」のステータスを設定し（Ｓ２０７）、後述するステップＳ２１２の処理に移行する。
【0100】
ステップＳ２０５において、受信したＵＤＰパケットがブロードキャスト応答でないと判断された場合、ブロードキャスト処理部１４は、受信したＵＤＰパケット（注目通信フロー）がユニキャストアクセスか否かの判定を行い（Ｓ２０８）、ユニキャストアクセスであると判断された場合は後述するステップＳ２０９の処理から動作し、そうでない場合は後述するステップＳ２１１の処理から動作する。ブロードキャスト処理部１４は、受信したＵＤＰパケット（注目通信フロー）の送信元ＩＰアドレスと宛先ＩＰアドレスの組がユニキャストアクセス待ちリストに含まれている場合、当該受信したＵＤＰパケット（注目通信フロー）をユニキャストアクセスと判断するようにしてもよい。
【0101】
ステップＳ２０８において、受信したＵＤＰパケット（注目通信フロー）がユニキャストアクセスであると判断された場合、ブロードキャスト処理部１４は、受信したＵＤＰパケット（注目通信フロー）に対応する組（送信元ＩＰアドレスと宛先ＩＰアドレスの組）をユニキャストアクセス待ちリストから削除する（Ｓ２０９）。そして、ブロードキャスト処理部１４は、受信したＵＤＰパケット（注目通信フロー）に対応する組（注目通信フローの送信元ＩＰアドレスと宛先ポート番号の組）のブロードキャスト進行度として「ユニキャストアクセス」のステータスを設定し（Ｓ２１０）、後述するステップＳ２１２の処理に移行する。
【0102】
一方、ステップＳ２０８において、受信したＵＤＰパケット（注目通信フロー）がユニキャストアクセスでないと判断された場合、ブロードキャスト処理部１４は、受信したＵＤＰパケット（注目通信フロー）に対応する組（送信元ＩＰアドレスと宛先ＩＰアドレスの組）のブロードキャスト進行度として「ブロードキャスト通信関連でない」のステータスを設定し（Ｓ２１１）、後述するステップＳ２１２の処理に移行する。このとき、ブロードキャスト進行度として明示的に「ブロードキャスト通信関連でない」のステータスを設定するのではなく何も設定しない（空の状態）とするようにしてもよい。
【0103】
ステップＳ２０４、Ｓ２０７、Ｓ２１０、Ｓ２１１のいずれかの処理により、受信したＵＤＰパケット（注目通信フロー）の組（送信元ＩＰアドレスと宛先ＩＰアドレスの組）に対するブロードキャスト進行度情報が設定されると、ブロードキャスト処理部１４は、各種リストのメンテナンスを行う（Ｓ２１２、Ｓ２１３）。具体的には、ブロードキャスト処理部１４は、ブロードキャスト応答待ちリストのうち、タイマ部１９からタイムアウトの通知を受けた要素（組）をリストから削除する。また、ブロードキャスト処理部１４は、ユニキャストアクセス待ちリストのうち、タイマ部１９からタイムアウトの通知を受けた要素（組）をリストから削除する。
【0104】
次に、ブロードキャスト処理部１４は、設定したブロードキャスト進行度情報をサービスポート判定部１３に通知する。また、サービスポート判定部１３は、通知されたブロードキャスト進行度情報が、ブロードキャスト要求、ブロードキャスト応答、ユニキャストアクセスのいずれかの場合、制御部１２に当該ブロードキャスト進行度情報を通知する（Ｓ２１４）。
【0105】
制御部１２は、ブロードキャスト進行度情報を受信すると、受信したブロードキャスト進行度情報から用途に応じて当該通信フローにサービスポートを設定してもよい（Ｓ２１５）。例えば、制御部１２は、監視対象機器３０が普段アクセスしないサービスへの通信を異常検知する機能の場合では、ブロードキャスト進行度情報がブロードキャスト要求である場合、宛先ポート番号をサービスポートと設定するようにしてもよい。また、制御部１２は、ブロードキャスト進行度情報がブロードキャスト応答である場合、ブロードキャスト要求のサービスポートである、送信元ポート番号をサービスポートと設定するようにしてもよい。さらに、制御部１２は、ブロードキャスト進行度情報がユニキャストアクセスである場合、宛先ポート番号をサービスポートと設定するようにしてもよい。
【0106】
図１０～図１２は、通信分析装置１０が、図５に示すフローチャートの処理を実行した場合における各リスト（ブロードキャスト応答待ちリストとユニキャストアクセス待ちリスト）の遷移の具体例について示した図である。図１０～図１２は、それぞれブロードキャスト要求があった場合の例、ブロードキャスト応答があった場合の例及びユニキャストアクセスがあった場合の例についてそれぞれ示している。
【0107】
図１０では、ｘｘｘ．ｙｙｙ．ｚｚｚ．２の監視対象機器３０からｘｘｘ．ｙｙｙ．ｚｚｚ．２５５に宛先ポート番号Ｂで通信（パケット）が発生している例について示している。宛先ＩＰアドレスのｘｘｘ．ｙｙｙ．ｚｚｚ．２５５は監視ネットワークセグメントのブロードキャストＩＰアドレスであり、ブロードキャスト処理部１４によりブロードキャスト要求と判断されることになる。また、図１０では、上記のブロードキャスト要求に基づいて、ブロードキャスト応答待ちリストに、送信元ＩＰアドレスと宛先ポート番号の組を示す情報として「ｘｘｘ．ｙｙｙ．ｚｚｚ．２，Ｂ」が保存されている。
【0108】
図１１では、ｘｘｘ．ｙｙｙ．ｚｚｚ．３の監視対象機器３０とｘｘｘ．ｙｙｙ．ｚｚｚ．５の監視対象機器３０からｘｘｘ．ｙｙｙ．ｚｚｚ．２の監視対象機器３０に対し送信元ポート番号Ｂで通信（パケット）が発生している例について示している。図１１の例では、宛先ＩＰアドレスと送信元ポート番号の組であるｘｘｘ．ｙｙｙ．ｚｚｚ．２，Ｂが、ブロードキャスト応答待ちリストに含まれているため、ブロードキャスト処理部１４において当該２つの通信フローはブロードキャスト応答と判断されることになる。したがって、図１１の例では、ブロードキャスト処理部１４により、「ｘｘｘ．ｙｙｙ．ｚｚｚ．２，ｘｘｘ．ｙｙｙ．ｚｚｚ．３」と「ｘｘｘ．ｙｙｙ．ｚｚｚ．２，ｘｘｘ．ｙｙｙ．ｚｚｚ．５」の２つの組（要素）がユニキャストアクセス待ちリストに追加されることになる。
【0109】
図１２では、ｘｘｘ．ｙｙｙ．ｚｚｚ．２からｘｘｘ．ｙｙｙ．ｚｚｚ．５に対して通信（パケット）が発生している例について示している。図１２の例では、「ｘｘｘ．ｙｙｙ．ｚｚｚ．２，ｘｘｘ．ｙｙｙ．ｚｚｚ．５」の組（要素）がユニキャストアクセス待ちリストに含まれているため、ブロードキャスト処理部１４により、上記の通信（パケット）はユニキャストアクセスと判断されることになる。したがって、図１２の例では、ブロードキャスト処理部１４により、ユニキャストアクセス待ちリストから、「ｘｘｘ．ｙｙｙ．ｚｚｚ．２，ｘｘｘ．ｙｙｙ．ｚｚｚ．５」の組（要素）が削除されている。
【0110】
以上のように、ブロードキャスト処理部１４では、各リスト（ブロードキャスト応答待ちリストとユニキャストアクセス待ちリスト）を用いて、ブロードキャスト通信を構成する各プロセスのパケットが認識される。
【0111】
次に、通信分析装置１０におけるステップＳ３００の動作（サービスポート推定部１５における、通信フローのサービスポート推定処理動作）について図７のフローチャートを用いて説明する。
【0112】
サービスポート推定部１５は、サービスポート推定部１５からサービスポート推定対象となる注目通信フローの情報（５－ｔｕｐｌｅｓ、パケットサイズ、通信方向）を受けると（Ｓ３０１）、注目通信フローの送信元ＩＰアドレスのサービスポートリストと、宛先ＩＰアドレスのサービスポートリストとを記憶部１８から取得する（Ｓ３０２）。
【0113】
次に、サービスポート推定部１５は、注目通信フローの送信元ポート番号がサービスポートか否かを推定し（Ｓ３０３）、さらに、注目通信フローの宛先ポート番号がサービスポートか否かを推定する（Ｓ３０４）。
【0114】
次に、サービスポート推定部１５は、送信元ポート番号に対するサービスポート推定結果と、宛先ポート番号に対するサービスポート推定結果から、注目通信フローに対するサービスポート番号の推定を行う（Ｓ３０５）。サービスポート推定部１５は、いずれか片方のポート番号の推定結果のみが一致の場合は当該ポート番号をサービスポートと推定し、両方のポート番号で推定結果が一致だった場合は一致度合の大きいポート番号をサービスポートと推定する。また、サービスポート推定部１５は、どちらのポート番号も推定結果が不一致の場合は判定できなかったとして判定不能（判定ＮＧ）と推定する。
【0115】
注目通信フローに対するサービスポート番号の推定が成功（判定ＯＫ）だった場合、サービスポート推定部１５は、推定したサービスポートを注目通信フローのサービスポートに設定する（Ｓ３０６）。
【0116】
サービスポート推定部１５はサービスポート判定部１３に推定結果を通知し、推定処理を終了する（Ｓ３０７）。
【0117】
次に、上述のステップＳ３０３における注目通信フローに対する送信元ポート番号がサービスポートか否かを推定する処理の詳細について説明する。
【0118】
まず、送信元ＩＰアドレスのサービスポートリストのうち、送信元ポートがサービスポートの場合、送信元ＩＰアドレスはサーバとなるため、サービスポート推定部１５は、注目通信フローのプロトコル（ＴＣＰ又はＵＤＰ）に対応する「サーバとしてアクセスされるサービスポートリスト」に注目通信フローの送信元ポート番号が含まれているかを確認する。注目通信フローの送信元ポート番号が含まれない場合、サービスポート推定部１５は、送信元ポート番号に対する送信元ＩＰアドレスのサービスポート判定結果を「リスト外ポート」と判断する。また、注目通信フローの送信元ポート番号が含まれている場合、サービスポート推定部１５は、ポート番号に対応する通信パターン分析モデルを記憶部１８から取得し、通信パターンの一致判定を行う。そして、サービスポート推定部１５は、通信パターン分析モデルに適用するために、注目通信フローのパケットサイズと通信方向の情報を特徴量（例えば、図４に示すような特徴量）に変換する。サービスポート推定部１５は、変換した特徴量を取得した通信パターン分析モデルに適用し、分析モデルから一致または不一致の結果を得る。結果が一致の場合、サービスポート推定部１５は、通信パターン分析モデルから一致度合（０～１の範囲の値）も取得する。
【0119】
サービスポート推定部１５は、宛先ＩＰアドレスに対しても同様に送信元ポート番号に対するサービスポート推定を行う。宛先ＩＰアドレスの場合は、宛先ＩＰアドレスのサービスポートリストのうち、「クライアントとしてアクセスするサービスポートリスト」が推定の対象となる。サービスポート推定部１５は、宛先ＩＰアドレスの推定結果としても、一致、不一致、リスト外ポートのいずれかが得られる。
【0120】
次に、サービスポート推定部１５は、以上の結果を用いて送信元ポート番号がサービスポートか否かの推定を行う。具体的には、サービスポート推定部１５は、上記の第１～第３の条件のうち、いずれかの条件を満たすとき、注目通信フローの送信元通信ポートについてサービスポートであると推定する。ここで、送信元ポート番号がサービスポートであると推定された場合、サービスポート推定部１５は、一致度合の値を求める。ここでは、サービスポート推定部１５は、上記の第１の条件を満たす場合、各ＩＰアドレスでの推定結果の一致度合を比較し小さい方の値を採用するものとする。それ以外の条件を満たす場合は、推定結果が一致となったＩＰアドレスでの一致度合を採用するものとする。
【0121】
次に、上述のステップＳ３０４における注目通信フローに対する宛先ポート番号がサービスポートか否かを推定する処理の詳細について説明する。
【0122】
サービスポート推定部１５は、宛先ポート番号についてもサービスポートか否かを推定する。まず、サービスポート推定部１５は、送信元ＩＰアドレスのサービスポートリストのうち、宛先ポートがサービスポートの場合、送信元ＩＰアドレスはクライアントとなるため、通信フローのプロトコルの「クライアントとしてアクセスするサービスポートリスト」を対象に、送信元ポート番号の時と同様の手順でサービスポートか否かの推定を行う。そして、サービスポート推定部１５は、宛先ＩＰアドレスに対しても同様に宛先ポート番号に対するサービスポート推定を行う。宛先ＩＰアドレスの場合は、宛先ＩＰアドレスのサービスポートリストのうち、「サーバとしてアクセスされるサービスポートリスト」が推定の対象となる。宛先ＩＰアドレスの推定結果としても、一致、不一致、リスト外ポートのいずれかが得られる。最後に、サービスポート推定部１５は、送信元ポート番号の時と同様に、以上の結果を用いて宛先ポート番号がサービスポートか否かの推定を行う。サービスポートと推定する条件は、送信元ポート番号の時と同じである。
【0123】
次に、サービスポート推定部１５によるサービスポート推定処理の具体例について説明する。
【0124】
図１３は、注目通信フローとそれに対応するサービスポートリストの例について示した図である。
【0125】
【0126】
図１３の例では、推定対象の注目通信フローのプロトコルがＴＣＰ、送信元ＩＰアドレスがｘｘｘ．ｙｙｙ．ｚｚｚ．２、送信元ポートが６１１１１、宛先ＩＰアドレスがｘｘｘ．ｙｙｙ．ｚｚｚ．３、宛先ポートが８０である。また、図１３の例では、監視ネットワークセグメントはｘｘｘ．ｙｙｙ．ｚｚｚ／２４となっている。さらに、図１３の例では、ＩＰアドレスがｘｘｘ．ｙｙｙ．ｚｚｚ．２の監視対象機器３０を機器Ａとし、ＩＰアドレスがｘｘｘ．ｙｙｙ．ｚｚｚ．３の監視対象機器３０を機器Ｂとしている。
【0127】
次に、図１３の例におけるステップＳ３０２の動作について説明する。このとき、サービスポート推定部１５は、送信元ＩＰアドレスがｘｘｘ．ｙｙｙ．ｚｚｚ．２である機器Ａのサービスポートリスト（機器Ａの吹き出し部分）を取得する。また、このとき、サービスポート推定部１５は、宛先ＩＰアドレスがｘｘｘ．ｙｙｙ．ｚｚｚ．３である機器Ｂのサービスポートリスト（機器Ｂの吹き出し部分）も取得する。
【0128】
次に、図１３の例におけるステップＳ３０３の動作について説明する。このとき、機器Ａが送信元ＩＰアドレスであり、通信フローがＴＣＰであるため、サービスポート推定部１５では、ＴＣＰのサーバとしてアクセスされるサービスポートリストの要素（２２番のみ）と、通信フローの送信元ポート番号である６１１１１が比較され、６１１１１がリストに含まれないため推定結果はリスト外ポートとなる。このとき、機器Ｂが宛先ＩＰアドレスであり、サービスポート推定部１５では、機器ＢのＴＣＰのクライアントとしてアクセスするサービスポートの要素（空）と通信フローの送信元ポート番号６１１１１が比較され、リストに含まれないため推定結果はリスト外ポートなる。したがって、図１３の例では、送信元ＩＰアドレスの推定結果も宛先ＩＰアドレスの推定結果もリスト外ポートであるため、サービスポート推定部１５は、送信元ポート番号はサービスポートではないと推定することになる。
【0129】
次に、図１３の例におけるステップＳ３０４の動作について説明する。このとき、サービスポート推定部１５では、機器ＡのＴＣＰのクライアントとしてアクセスするサービスポートリストの要素（２２番と８０番）と通信フローの宛先ポート番号である８０番が比較される。８０番がリストに含まれるため、サービスポート推定部１５は、８０番に対応する通信パターン分析モデルを取得し、通信フローの特徴量をモデルに適用し、一致若しくは不一致の結果を得る。また、このとき、機器ＢのＴＣＰのサーバとしてアクセスされるサービスポートリストの要素（２２番と８０番）が対象となり、通信フローの宛先ポート番号の８０がリストに含まれるため、サービスポート推定部１５は、通信フローの特徴量を通信パターン分析モデルに適用し、推定結果として一致若しくは不一致を得る。したがって、図１３の例では、送信元ＩＰアドレスと宛先ＩＰアドレスそれぞれの通信パターン分析モデルでの推定結果によって、注目通信フローの宛先ポート番号がサービスポートとなるか否かが決まる。つまり、サービスポート推定部１５では、いずれかの推定結果が不一致だった場合は、宛先ポート番号はサービスポートでないと推定され、どちらの推定結果も一致だった場合は宛先ポート番号がサービスポートであると推定されることになる。
【0130】
次に、図１３の例におけるステップＳ３０５の動作について説明する。このとき、送信元ポート番号に対するサービスポート推定結果は不一致であるため、サービスポート推定部１５は、宛先ポート番号の推定結果が一致の場合は宛先ポート番号の８０番をサービスポートと推定し、推定結果が不一致の場合は判定不能と推定することになる。
【0131】
次に、通信分析装置１０におけるステップＳ４００の動作（サービスポートリスト管理部１６による、サービスポートリストの作成および更新処理動作）を図８を用いて説明する。
【0132】
ここでは、まず、サービスポートリスト管理部１６は、制御部１２から注目通信フローの通信フロー情報として５－ｔｕｐｌｅｓ、及びサービスポート番号（サービスポート判定部１３により判定されたサービスポート番号；サービスポートが判定不能だった場合は空）を受信したものとする（Ｓ４０１）。
【0133】
次に、サービスポートリスト管理部１６は、注目通信フローのプロトコルがＴＣＰかＵＤＰかを確認し（Ｓ４０２）、ＴＣＰだった場合は後述するステップＳ４０３から動作し、ＵＤＰだった場合は後述するステップＳ４０６から動作する。
【0134】
注目通信フローのプロトコルがＴＣＰの場合、サービスポートリスト管理部１６は、注目通信フローに対応するサービスポートリストを取得する（Ｓ４０３）。まず、サービスポートリスト管理部１６は、受信したサービスポート番号が通信フローの送信元ポート番号と宛先ポート番号のどちらに一致するか確認する。送信元ポート番号と一致する場合、サービスポートリスト管理部１６は、記憶部１８から送信元ＩＰアドレスのＴＣＰのサーバとしてアクセスされるサービスポートリストを取得し、さらに、記憶部１８から宛先ＩＰアドレスのＴＣＰのクライアントとしてアクセスするサービスポートリストを取得する。宛先ポート番号と一致する場合、サービスポートリスト管理部１６は、記憶部１８から送信元ＩＰアドレスのＴＣＰのクライアントとしてアクセスするサービスポートリストを取得し、さらに、記憶部１８から宛先ＩＰアドレスのＴＣＰのサーバとしてアクセスされるサービスポートリストを取得する。
【0135】
次に、サービスポートリスト管理部１６は、取得したサービスポートリストに、受信したサービスポート番号が含まれるかを確認し、リストに含まれない場合、サービスポートリストに当該サービスポート番号を追加し、記憶部１８に更新したサービスポートリストを保存する（Ｓ４０４、Ｓ４０５）。その後、サービスポートリスト管理部１６は、後述するステップＳ４１３に移行する。
【0136】
一方、上述のステップＳ４０２において、注目通信フローのプロトコルがＵＤＰの場合、サービスポートリスト管理部１６は、注目通信フローに対応するサービスポート候補リストを取得する（Ｓ４０６）。サービスポートリスト管理部１６は、受信したサービスポートに値が設定されている場合は、当該サービスポート番号が通信フローの送信元ポート番号と宛先ポート番号のどちらに一致するかを確認する。送信元ポート番号と一致する場合、サービスポートリスト管理部１６は、送信元ＩＰアドレスのサーバとしてアクセスされるサービスポート候補リストを取得し、宛先ＩＰアドレスのクライアントとしてアクセスするサービスポート候補リストを取得する。
【0137】
次に、サービスポートリスト管理部１６は、宛先ポート番号と一致する場合とサービスポートに値が設定されているか否かを確認し（Ｓ４０７）、値が設定されている場合は後述するステップＳ４０８の処理に移行し、そうでない場合は後述するステップＳ４０９の処理に移行する。
【0138】
ステップＳ４０７において、宛先ポート番号と一致する場合とサービスポートに値が設定されていない場合、サービスポートリスト管理部１６は、送信元ＩＰアドレスのクライアントとしてアクセスするサービスポート候補リストを取得し、宛先ＩＰアドレスのサーバとしてアクセスされるサービスポート候補リストを取得する。そして、サービスポートリスト管理部１６は、取得したサービスポート候補リストに、宛先ポート番号を追加して更新する（Ｓ４０９）。
【0139】
一方、ステップＳ４０７において、宛先ポート番号と一致する場合とサービスポートに値が設定されている場合、サービスポートリスト管理部１６は、取得したサービスポート候補リストに、サービスポート番号を追加する更新を行う（Ｓ４０８）。
【0140】
サービスポート候補リストを更新すると、サービスポートリスト管理部１６は、ＵＤＰのサービスポートリストの作成処理を実施する（Ｓ４１０）。サービスポートリスト管理部１６は、サービスポートリスト候補リストに含まれるポート番号の出現頻度を集計する。その後、サービスポートリスト管理部１６は、後述するステップＳ４１３に移行する。
【0141】
図１４は、サービスポート候補リストに含まれるポート番号毎に出現頻度を集計し、出現頻度でヒストグラムを作成した結果の例を示した図である。
【0142】
サービスポートリスト管理部１６は、集計したポート番号毎の出現頻度を用いて、サービスポートリストを作成する。具体的には、統計的な外れ値検出方法により、外れ値扱いとなる出現頻度に対応するポート番号をサービスポートリストとして抽出する。例えば、外れ値検出方法として、Ｓｍｉｒｎｏｖ－Ｇｒｕｂｂｓ検定を利用できる。図１４の例では、外れ値扱いとなる出現頻度の範囲を左右矢印で示しており、この範囲に含まれる出現頻度に対応するポート番号をサービスポート番号としたサービスポートリストが作成されることを示している。図１４では、横軸を出現頻度とし、縦軸を度数（ポート番号の種類の数）としている。一般的に、ＩＰ通信を行う機器のトラフィックデータからポート番号毎の出現頻度を集計すると、サービスポートのポート番号よりもそうでないポート番号の方が種類は多いが、出現頻度はサービスポートの方が著しく高くなる傾向にある。そのため、図１４のように出現頻度が外れ値となるポート番号はサービスポートである可能性が高いことになる。例えば、注目通信フローの送信元ポート番号と宛先ポート番号の出現頻度を参照して、一方のポート番号の出現頻度だけが上記の外れ値に該当する場合、当該ポート番号がサービスポートに該当する可能性が高いことになる。
【0143】
次に、サービスポートリスト管理部１６は、作成されたサービスポートリストと記憶部１８に保存されているサービスポートリストを比較し、リストに含まれる要素に変化があった場合は、新しいサービスポートリストを記憶部１８に保存する（Ｓ４１１、Ｓ４１２）。
【0144】
その後、サービスポートリスト管理部１６は、更新されたサービスポートリストに、受信した通信フローのサービスポート番号（ＵＤＰの場合でサービスポートが空の場合は宛先ポート番号）が含まれるか否かを確認し（Ｓ４１３）、含まれると確認された場合は通信パターン学習部１７に通信フローの５－ｔｕｐｌｅｓ情報とサービスポート番号（ＵＤＰの場合でサービスポートが空の場合は宛先ポート番号）を通知して通信パターン分析モデルを構築させ（Ｓ５００）、処理を終了する。通信パターン学習部１７による当該ポート番号の通信パターン分析モデルを構築する処理の詳細については後述する。
【0145】
次に、通信分析装置１０におけるステップＳ５００の動作（通信パターン学習部１７における、サービスポートに対する通信パターン分析モデルの構築動作）について図９のフローチャートを用いて説明する。
【0146】
まず、通信パターン学習部１７が、サービスポートリスト管理部１６から通信フロー情報として、通信フローの５－ｔｕｐｌｅｓの情報とサービスポート番号（プロトコルがＵＤＰでサービスポートが空の場合は宛先ポート番号）を受信したものとする（Ｓ５０１）。
【0147】
通信パターン学習部１７は、サービスポート番号に値が設定されている場合、記憶部１８から受信したサービスポート番号と同じサービスポート番号が設定された通信フロー履歴情報（５－ｔｕｐｌｅｓの情報、通信フローの各パケットのパケットサイズおよび通信方向）を取得する（Ｓ５０２）。なお、このときサービスポート番号の値が空の場合、通信パターン学習部１７は、記憶部１８から受信した通信フローの宛先ポート番号と同じ宛先ポート番号の通信フロー履歴情報を取得する。
【0148】
次に、通信パターン学習部１７は、取得した通信フロー履歴情報から、送信元ＩＰアドレスに係る通信フローを抽出する（Ｓ５０３）。具体的には、通信パターン学習部１７は、受信したサービスポート番号が受信した通信フローの送信元ポート番号と一致する場合、「送信元ＩＰアドレスと送信元ポート番号の組が通信フロー履歴情報の送信元ＩＰアドレスと送信元ポート番号の組と一致するもの」、又は「送信元ＩＰアドレスと送信元ポート番号の組が通信フロー履歴情報の宛先ＩＰアドレスと宛先ポート番号の組と一致するもの」を抽出する。受信したサービスポート番号が受信した通信フローの宛先ポート番号と一致する場合、通信パターン学習部１７は、「送信元ＩＰアドレスと宛先ポート番号の組が通信フロー履歴情報の送信元ＩＰアドレスと宛先ポート番号の組と一致するもの」、又は「送信元ＩＰアドレスと宛先ポート番号の組が宛先ＩＰアドレスと送信元ポート番号の組と一致するもの」を抽出する。
【0149】
次に、通信パターン学習部１７は、抽出（蓄積）した通信フロー履歴情報の件数が通信パターン分析モデル構築に必要となる所定件数以上であるか否か確認し（Ｓ５０４）、所定件数以上蓄積されている場合は後述するステップＳ５０５の処理に移行し、そうでない場合は通信パターン分析モデルの構築処理を終了する。
【0150】
通信フロー履歴情報の件数が所定件数以上抽出（蓄積）されている場合、通信パターン学習部１７は、各通信フロー履歴情報を機械学習器に適用するための特徴量に変換する（Ｓ５０５）。ここでは、通信パターン学習部１７は、図４に示す特徴量に変換するものとする。
【0151】
次に、通信パターン学習部１７は、変換した各通信フロー履歴情報の特徴量を学習データとして、通信パターン分析モデルを構築する（Ｓ５０６）。通信パターン分析モデルを構築するためのプラットフォームについては限定されないものであり、種々のＡＩ用のプラットフォーム等を適用することができる。ここでは、通信パターン学習部１７は、Ｏｎｅ Ｃｌａｓｓ ＳＶＭにより、学習データに近い特徴量を持つ通信フローを正常（当該サービスポート番号の通信パターンである）と判定し、学習データの特徴量と大きく異なる通信フローを異常（当該サービスポート番号の通信パターンではない）と判定するような通信パターン分析モデルを構築するものとする。
【0152】
次に、通信パターン学習部１７は、構築した通信パターン分析モデルを、送信元ＩＰアドレスのサービスポートリストに存在するサービスポート番号に対応するモデルとして記憶部１８に保存して（Ｓ５０７）、通信パターン分析モデルの構築処理を終了する。つまり、サービスポート番号が送信元ポート番号と一致する場合、通信パターン学習部１７は、送信元ＩＰアドレスのＴＣＰまたはＵＤＰ（通信フローのプロトコルに依る）のサーバとしてアクセスされるサービスポートリストに含まれる当該サービスポート番号に対応する通信パターン分析モデルとして保存する。サービスポート番号が宛先ポート番号と一致する場合、通信パターン学習部１７は、送信元ＩＰアドレスのＴＣＰまたはＵＤＰのクライアントとしてアクセスするサービスポートリストに含まれる当該サービスポート番号に対応する通信パターン分析モデルとして保存する。
【0153】
通信パターン学習部１７は、以上の処理を宛先ＩＰアドレスに対しても実施する。
【0154】
（Ａ－３）第１の実施形態の効果
第１の実施形態によれば、以下のような効果を奏することができる。
第１の実施形態によれば、以下のような効果を奏することができる。
【0155】
第１の実施形態では、管理下の監視対象機器３０毎に、当該監視対象機器３０がクライアントとしてアクセスするサービスポートとサーバとしてアクセスされるサービスポートを、過去に発生した通信フローの情報から作成・蓄積し、リストとして保持し、サービスポート判定に利用する。これにより、第１の実施形態では、ミラーポートでパケットの到着順序が変わって受信した通信フローや、ミラーリング前に開始された通信フローやＵＤＰの通信フローのように単一の通信フローの情報からではサービスポートを特定できない通信フローのサービスポートの判定精度を向上させることができる。ここで、監視対象機器３０毎に２種（クライアントとしてアクセスするサービスポートリスト、サーバとしてアクセスされるサービスポートリスト）のサービスポートリストを保有することは、監視対象機器３０毎にクライアント・サーバ区別せずに一つのサービスポートリストを保有する場合に比べて、サービスポートの識別可能性を高めることができる。例えば、機器Ａのクライアントとしてアクセスするサービスポートリストに６００００番と１４３３番のポート番号が含まれ、機器Ｂのサーバとしてアクセスされるサービスポートリストに６００００番と１４３３番が含まれる場合を考える。この時、送信元機器がＡで送信元ポート番号が１４３３、宛先機器がＢで宛先ポート番号が６００００の通信フローが発生すると、機器Ａのクライアントとしてアクセスするサービスポートリストに６００００番、機器Ｂのサーバとしてアクセスされるサービスポートリストにも６００００番が含まれるため、当該通信フローのサービスポートは６００００と判別できる。一方、監視対象機器３０毎にクライアント・サーバ区別せずに一つのサービスポートリストを保有するような場合では、当該通信フローの送信元ポート番号と宛先ポート番号の両方が機器Ａと機器Ｂのサービスポートリストに含まれることになるため、サービスポートを識別することができない。
【0156】
第１の実施形態では、監視対象機器３０のサービスポートリストに含まれるポート番号毎に当該ポート番号で通信した時の通信パターンを機械学習した通信パターン分析モデルを使用し、サービスポート判定の際に、通信パターン分析モデルを用いて通信パターンが一致するか判定している。これにより、第１の実施形態では、上記２種のサービスポートリストを用いる場合でもサービスポート判別ができないケースでのサービスポート識別可能性を高めることができる。例えば、機器Ａのクライアントとしてアクセスするサービスポートリストに６００００番と１４３３番のポート番号、サーバとしてアクセスされるサービスポートリストに１４３３番のポート番号が含まれ、機器Ｂのクライアントとしてアクセスするサービスポートリストに１４３３番のポート番号、サーバとしてアクセスされるサービスポートリストに６００００番と１４３３番が含まれる場合を考える。この時、送信元機器がＡで送信元ポート番号が１４３３、宛先機器がＢで宛先ポート番号が６００００の通信フローが発生すると、送信元ポート番号の１４３３番は機器Ａのサーバとしてアクセスされるサービスポート番号に含まれ、機器Ｂのクライアントとしてアクセスするサービスポート番号にも含まれる。また宛先ポート番号の６００００は機器Ａのクライアントとしてアクセスされるサービスポート番号に含まれ、機器Ｂのサーバとしてアクセスされるサービスポート番号にも含まれる。このような場合、送信元ポート番号も宛先ポート番号もサービスポートとみなせるため、サービスポートの判別ができない。第１の実施形態では、通信パターン分析モデルを用いることでこのような通信フローのサービスポートも判別することができるようになる。
【0157】
第１の実施形態の通信分析装置１０では、ブロードキャスト通信の一連の処理に進行度情報を設け、ブロードキャスト通信に係る通信フローのサービスポート判定を別に行う。これにより、例えばブロードキャスト応答を単一のユニキャストの通信フローとして処理してしまった場合のサービスポート誤判別を解消しサービスポート判定精度を向上させることができる。
【0158】
以上のように、第１の実施形態の通信分析装置１０では、ＵＤＰのようなコネクションレス型の通信フロー、先頭パケットを採り逃した通信フロー、ブロードキャスト通信のように複数の通信フローを加味する必要がある通信のサービスポートを識別することができる。言い換えると、第１の実施形態の通信分析装置１０では、通信トラフィックのデータからサービスポートを判別する際の精度を向上させることができる。
【0159】
（Ｂ）第２の実施形態
以下、本発明による通信分析装置、通信分析プログラム及び通信分析方法の第２の実施形態を、図面を参照しながら詳述する。
以下、本発明による通信分析装置、通信分析プログラム及び通信分析方法の第２の実施形態を、図面を参照しながら詳述する。
【0160】
図１５は、第２の実施形態に係る通信分析装置１０Ａの機能的構成について示したブロック図である。
【0161】
第１の実施形態では、サービスポート推定部１５でのサービスポート推定のために、通信パターン分析モデルを用いて通信パターンが一致するかの判定を行っていたが、第２の実施形態の通信分析装置１０Ａでは通信パターン分析モデルを用いない推定方法を適用している。
【0162】
通信分析装置１０Ａでは、通信パターン学習部１７が除外され、サービスポート推定部１５がサービスポート推定部１５Ａに置き換わっている点で第１の実施形態と異なっている。
【0163】
サービスポート推定部１５Ａは、推定対象のポート番号がサービスポートリストに含まれるか否かの情報だけで、サービスポートを推定するものとする。このように、通信分析装置１０Ａ（サービスポート推定部１５Ａ）では、通信パターン分析モデルを用いない方法をとることで、サービスポート推定にかかる時間を短縮し、処理負荷を低減させることができる。
【0164】
（Ｃ）第３の実施形態
以下、本発明による通信分析装置、通信分析プログラム及び通信分析方法の第３の実施形態を、図面を参照しながら詳述する。
以下、本発明による通信分析装置、通信分析プログラム及び通信分析方法の第３の実施形態を、図面を参照しながら詳述する。
【0165】
【0166】
第１及び第２の実施形態の通信分析装置１０、１０Ａでは、ＵＤＰのサービスポートリストを作成する部分で、宛先ポート番号の発生頻度を分析し外れ値検出手法を用いて、発生頻度が外れ値（大きい方の値）とみなされた宛先ポート番号をサービスポートとして登録していた。しかしながら、通信分析装置１０、１０Ａでは、外れ値検出手法を採用する場合、外れ値となる閾値を設定する必要があるが、宛先ポート番号の発生頻度分布は環境によって異なる場合が多く、最終的に人手によるチューニングが必要となるケースも少なくない。そこで、第３の実施形態の通信分析装置１０Ｂでは、環境非依存で人手によるチューニングが必要ない、ＵＤＰポートのサービスポートリスト作成を実現するように構成されている。
【0167】
以下では、第３の実施形態の通信分析装置１０Ｂについて、第１及び第２の実施形態との差異を中心に説明する。
【0168】
第３の実施形態の通信分析装置１０Ｂは、ＵＤＰポート履歴情報管理部５０が追加されている点で第１の実施形態と異なっている。また、第３の実施形態の通信分析装置１０Ｂでは、サービスポートリスト管理部１６がサービスポートリスト管理部１６Ｂに置き換わっている点で第１の実施形態と異なっている。
【0169】
ＵＤＰポート履歴情報管理部５０では、第１の実施形態におけるＵＤＰのサービスポートの候補リストに相当する情報をサービスポートリスト管理部１６Ｂの代わりに管理する。第３の実施形態の通信分析装置１０Ｂでは、ＵＤＰのサービスポートの候補リストで保持する内容と構成が大きく異なるため、この実施形態において、ＵＤＰポート履歴情報管理部５０が管理する情報を上記の通り「ＵＤＰポート利用履歴管理情報」と呼ぶものとする。
【0170】
図１７は、ＵＤＰポート履歴情報管理部５０が保持するＵＤＰポート利用履歴管理情報の構成例について示した図である。
【0171】
図１７に示すように、ＵＤＰポート利用履歴管理情報は、端末３０（ＩＰアドレス）単位に管理される情報であり、当該端末３０が送信元となった通信フローの宛先ポート毎に、当該宛先ポートの発生数、当該宛先ポートのフローで使用された送信元ポート番号のリスト（重複を除いたユニークな値のみを管理）、発生日情報を１日単位でリストを分けて管理する（以後、１日単位のリストのことを「サブリスト」と呼ぶ）。
【0172】
図１７では、第１の端末３０－１（ＩＰアドレス：ＸＸＸ．ＹＹＹ．ＺＺＺ．Ａ）についてのＵＤＰポート利用履歴管理情報の一例を表している。図１７では、第１の端末３０－１（ＸＸＸ．ＹＹＹ．ＺＺＺ．Ａ）を送信元とする過去のＵＤＰフローの宛先ポートとして１９００番と４４３番のポートの二つがあることを表している。また、１９００番ポートのサブリストは３つあり、過去３日間の通信実績があることを表している。さらに、リストの一つ目では２０２３年９月２９日に２つの通信フローが発生し送信元ポート番号として２００１０番と２００１１番が使われたことを表している。ここで、ＵＤＰポート利用履歴管理情報についても、第１の実施形態でのサービスポートの候補リストのように、端末３０ごとにクライアントとしてアクセスするＵＤＰポート利用履歴管理情報（これは上記記述のリスト）と、サーバとしてアクセスされるＵＤＰポート利用履歴管理情報（上記記述のリストを当該端末が宛先となった場合でのリストとして管理する）の２種類を管理する構成も考えられるが、この実施形態では説明を簡単にするために上述の端末３０ごとに当該端末３０が送信元となるフローのみについてのＵＤＰポート利用履歴管理情報を管理するものとする。
【0173】
ＵＤＰポート履歴情報管理部５０は、サービスポートリスト管理部１６ＢからＵＤＰの通信フロー情報を受けると、ＵＤＰポート利用履歴管理情報の内容を更新する。ＵＤＰポート履歴情報管理部５０は、まず、当該ＵＤＰフローの送信元ＩＰアドレスに関するＵＤＰポート利用履歴管理情報が存在するかを確認し、存在しない場合は、当該送信元ＩＰアドレスのＵＤＰポート利用履歴管理情報を作成する。つまり、ＵＤＰポート履歴情報管理部５０は、当該送信元ＩＰアドレスのＵＤＰポート利用履歴管理情報を作成し、当該ＵＤＰポート利用履歴管理情報に当該ＵＤＰの通信フローの宛先ポートの情報として、発生数に１、送信元ポートリストに当該ＵＤＰフローの送信元ポート番号の値、発生日に当日の日付をそれぞれ設定したサブリストを追加する。一方、当該ＵＤＰフローの送信元ＩＰアドレスに関するＵＤＰポート利用履歴管理情報が存在する場合、ＵＤＰポート履歴情報管理部５０は、当該送信元ＩＰアドレスのＵＤＰポート利用履歴管理情報を更新する。ＵＤＰポート履歴情報管理部５０は、まず、当該送信元ＩＰアドレスのＵＤＰポート利用履歴管理情報から、当該宛先ポート番号のサブリストを取得する。次に、ＵＤＰポート履歴情報管理部５０は、取得したサブリストのうち発生日が最も新しいサブリストを取得する。ＵＤＰポート履歴情報管理部５０は、取得したサブリストの発生日が当日と同じ場合、当該サブリストの要素を更新する。つまり、ＵＤＰポート履歴情報管理部５０は、当該サブリストの発生数をインクリメントし、送信元ポートのリストに当該フローの送信元ポートを追加（リストの要素で重複するポートがある場合は追加しない）する。取得したサブリストの発生日が当日と異なる場合、ＵＤＰポート履歴情報管理部５０は、新しいサブリスト（当日のサブリスト）を追加する。つまり、ＵＤＰポート履歴情報管理部５０は、発生数に１、送信元ポートリストに当該通信フローの送信元ポート番号の値、発生日に当日の日付を設定したサブリストを当該宛先ポートのリストに追加する。
【0174】
また、ＵＤＰポート履歴情報管理部５０は、後述する再利用判定用ポートリスト、再利用フラグ及び発生日数閾値を管理し、受信したＵＤＰフロー情報をもとに、これらの情報を更新する処理も行う。
【0175】
そして、ＵＤＰポート履歴情報管理部５０は、更新したＵＤＰポート利用履歴管理情報、発生日数閾値をサービスポートリスト管理部１６Ｂに通知する。
【0176】
サービスポートリスト管理部１６Ｂは、第１の実施形態の処理に加え、制御部１２からＵＤＰの通信フローを受信すると、受信したフロー情報をＵＤＰポート履歴情報管理部に通知し、更新されたＵＤＰポート履歴管理情報、および後述する発生日数閾値を受信し、ＵＤＰサービスポートリストを作成する処理を行う。
【0177】
図１８は、サービスポートリスト管理部１６ＢによるＵＤＰサービスポートリストの作成方法について示した説明図である。
【0178】
図１８は、第２の端末３０－２（ＩＰアドレス：ＸＸＸ．ＹＹＹ．ＺＺＺ．Ｂ）のＵＤＰポート履歴管理情報を表しており、宛先ポートとしては、１９００番と１２０１０番のリストが存在する。ＵＤＰサービスポートリストの作成では、ＵＤＰポート履歴管理情報に含まれる各宛先ポートについてＵＤＰサービスポートリストに登録するかどうかを判定する処理（以下、「サービスポート判定処理」と呼ぶ）を行う。このサービスポートに登録するか判断するための条件は、任意の宛先ポートＰＸの発生数（サブリストが複数ある場合は、全てのサブリストの合算値；以下「ポート発生数Ｃ１」と呼ぶ）と、当該宛先ポートＰＸの送信元ポートリストに含まれる各ポート番号について、当該ポート番号を宛先ポートとしてみたときの発生数（以下、「ポート発生数Ｃ２」と呼ぶ）を比較し、Ｃ１＞Ｃ２がいずれかの送信元ポート番号について成り立つとき、当該宛先ポートＰＸをサービスポートとしてＵＤＰのサービスポートリストに登録する。なお、送信元ポートがＵＤＰポート履歴管理情報の宛先ポートに存在しない場合は、当該送信元ポートの発生数は０とするものとする。
【0179】
ＵＤＰポート利用履歴管理情報が図１８のような内容であった場合、サービスポートリスト管理部１６Ｂは、まず宛先ポート１９００番についてＵＤＰサービスポートリストに登録するかを判定するサービスポート判定処理（１９００を宛先ポートＰＸとするサービスポート判定処理）を行う。図１８に示すように、１９００番ポートのポート発生数Ｃ１は４（３つのサブリストの合算値）であり、送信元ポートリストには、２００１０，２００１１，２０１００，２０３００が含まれる。
【0180】
次に、サービスポートリスト管理部１６Ｂは、送信元ポートリストの各ポート番号について、当該ポート番号を宛先ポートとしてみたときのポート発生数Ｃ２を参照する。図１８ではいずれの送信元ポート番号も宛先ポート番号に含まれないため、ポート発生数Ｃ２は０となる。最後に宛先ポート番号（発生数は４）と各送信元ポート番号を宛先ポートとしてみたときの発生数Ｃ２（いずれのポートも発生数は０）で条件比較し、この場合いずれのポートと比較しても１９００番ポート（宛先ポートＰＸ）の発生数Ｃ１の方が大きいため、１９００番ポートが、ＵＤＰサービスポートリストに登録されることになる。
【0181】
次に、サービスポートリスト管理部１６Ｂは、同じ手順で１２０１０番ポートを宛先ポートＰＸとしてサービスポート判定処理（ＵＤＰサービスポートリストに登録するか判定する処理）を行う。図１８では、１２０１０番のポート発生数Ｃ１は１であり、送信元ポートリストに含まれるポートは１９００番のただ一つである。１９００番ポートを宛先ポートとしてみたときのポート発生数Ｃ２は４であり、１２０１０番の発生数Ｃ１より多いため、１２０１０番ポートはサービスポートリストに登録しないという結果となる。一般に通信フローはクライアント端末からサーバに対して張られる（つまり宛先ポート番号がサービスポートである）ため、ＵＤＰポート履歴管理情報の宛先ポートにはほとんどの場合、正しいサービスポート番号が記録される。一方で通信フローの１パケットを取り逃した場合などで最初に受信したパケットがサーバからクライアントへのものだった場合、クライアント側のポート番号が宛先ポートに誤記録される。しかしこの場合、間違った宛先ポート番号の対向ポート（送信元ポート）はサービスポートであり、当該対向ポートが定常的に使われるサービスポートの場合、ほとんどのケースで当該サービスポートの通信フローの１パケット目を正しく受信するため、当該サービスポートを宛先ポートとしてみたときの発生数は間違った宛先ポート番号の発生数よりも多いはずである。このことから、サービスポートリスト管理部１６Ｂのサービスポート判定処理について、上述の判定条件を適用することにより、間違った宛先ポート番号がサービスポートとしてみなされる可能性を排除し、正しいサービスポートだけをサービスポートリストとして登録することができる。
【0182】
ここで、上述のサービスポート判定処理における判定条件で、ＵＤＰサービスポートリストを作成する場合、ＵＤＰポート履歴管理情報に登録されて日の浅い宛先ポートはサービスポート判定で誤判定の恐れがある。例えば、通信トラフィックのキャプチャを開始した直後は、キャプチャ前に開始していた通信フローのサーバからクライアントに対するパケットを最初に受信しクライアント側のポートがＵＤＰポート履歴管理情報の宛先ポートに登録され、かつ正しいサービスポートの情報がＵＤＰポート履歴管理情報に登録されていない（つまり正しいサービスポート番号を宛先ポートとしたフローの発生数がゼロである）可能性があり、この場合クライアント側のポートがサービスポートとして登録されてしまう。また同様に、新しく使われ始めたばかりのサービスについても、当該サービスのサービスポートの通信フローの１パケットを取り逃した場合には、クライアント側のポートがサービスポートに登録される可能性がある。
【0183】
以上のようなサービスポート誤判定のケースを排除するために、ＵＤＰポート履歴情報管理部５０では、ＵＤＰポート履歴管理情報のうち発生日数の少ない宛先ポートをサービスポート判定対象から除外する条件を設定するものとする。具体的には、ＵＤＰポート履歴情報管理部５０では、ＵＤＰポート履歴管理情報が管理される端末３０毎に宛先ポートの発生日数に閾値を設け、閾値より少ない発生日数の宛先ポートをサービスポート判定から除外する。閾値の決め方として、ここではクライアントポートが再利用されたことを契機に閾値をインクリメントする方法をとる。一般に機器がクライアントとして使用するポート番号の範囲は、ＯＳや機器の設定によって決まっており、ポート番号の範囲を一通り使用すると以前に使用したポート番号を再利用するような使い方がされる場合が多い。ここで、ＵＤＰポート履歴情報管理部５０において、ポート番号が再利用されると、ＵＤＰポート履歴管理情報の宛先ポートに間違って登録されたクライアント側のポートの発生日数が増える可能性がある。例えば、ＵＤＰポート履歴情報管理部５０において、クライアント側のポート番号が５００００番の通信フローについて１パケット目を取り逃した等の理由で送信元と宛先が逆転しＵＤＰポート履歴管理情報の宛先ポートにクライアント側の５００００番ポートが登録されたとする。その後、ＵＤＰポート履歴情報管理部５０において、クライアントポートが再利用され再度５００００番のポートの通信フローが発生し、ここでもまた送信元と宛先が逆転しＵＤＰポート履歴管理情報の宛先ポートに５００００番が登録されると、５００００番のサブリストが追加され発生日数が２日になる。
【0184】
そのため、ＵＤＰポート履歴情報管理部５０は、ポート番号再利用を検出したタイミングで発生日数の閾値をインクリメントすることで、クライアントポートをサービスポートと判定する確率を低減できる。クライアントポート番号再利用検知方法は、端末３０のＵＤＰポート履歴管理情報の各宛先ポートに含まれる送信元ポート番号のリストのうち、いずれかのポート番号と同じポート番号を送信元ポート番号に持つ通信フローを受信した時、またはこれを複数回検知したときに再利用検知とする。ＵＤＰポート履歴情報管理部５０は、端末３０ごとにクライアントポートの再利用を検知したときの送信元ポート番号を再利用判定用ポートリスト（複数回検知した場合に再利用検知する場合は複数のポート番号が入る）として管理する。ＵＤＰポート履歴情報管理部５０は、再利用判定用ポートリストの要素数があらかじめ決められた閾値に達した時、クライアントポートが再利用されたと判断し発生数の閾値をインクリメントする。ＵＤＰポート履歴情報管理部５０は、一度再利用判定用ポートリストの作成が完了すると、２回目以降の再利用検知では既存の再利用判定用ポートリストを利用して再利用判定する。具体的には、ＵＤＰポート履歴情報管理部５０は、再利用判定用ポートリストのポート毎に再利用フラグを管理し、いずれかのポートの再利用を検知すると、当該ポートの再利用フラグを立てる。ＵＤＰポート履歴情報管理部５０は、再利用判定用ポートリストの全てのポートに再利用フラグが立つと、クライアントポートが再利用されたと判断し、発生数の閾値をインクリメントするとともに、全てのポートの再利用フラグをリセットする。
【0185】
【0186】
図１９は、ＵＤＰポート履歴情報管理部５０が、ある端末３０（以下、「注目端末」と呼ぶ）について初回のクライアントポート再利用検知を行う際の処理の流れについて示した説明図である。
【0187】
図１９（ａ）～図１９（ｄ）では、時系列ごとの注目端末が送信元となる通信フローの送信元ポート番号（つまりクライアントポート）のリスト（以下、「クライアントポート利用リスト）ＰＬ１と、再利用判定用ポートリストＰＬ２を図示している。
【0188】
図１９（ａ）では、初期状態において、クライアントポート利用リストＰＬ１として５００００番から５００５０番までが連番で存在し、再利用判定ポートリストＰＬ２は空の状態となっている。なお、注目端末では、再利用と判断する再利用判定用ポートリストの要素数の閾値は２であり、発生日数閾値（サービスポート判定条件に進むかどうか判断するための閾値）も２であるものとする。
【0189】
その後、通信分析装置１０Ｂ（ＵＤＰポート履歴情報管理部５０）が、注目端末が送信元となるＵＤＰフローを受信し、その送信元ポートが５００５１番だったとすると、注目端末の注目端末のＵＤＰポート履歴情報管理部５０では、クライアントポート利用リストＰＬ１に５００５１番のポートが含まれているか確認され、この例では含まれないため、図１９（ｂ）に示すように、クライアントポート利用リストＰＬ１に５００５１番が追加される。
【0190】
そして、その後、通信分析装置１０Ｂ（ＵＤＰポート履歴情報管理部５０）が、次に受信した注目端末を送信元とするＵＤＰフローの送信元ポートが５００００番だったとする。この場合、５００００番はクライアントポート利用リストＰＬ１に含まれるため、図１９（ｃ）に示すように、再利用判定用ポートリストＰＬ２に追加されることになる。
【0191】
この時点で、ＵＤＰポート履歴情報管理部５０では、再利用判断閾値と現在の再利用判定用ポートリストの要素数が比較され、再利用と判断する閾値に達していないため、クライアントポート再利用とは判断されない。
【0192】
次に、通信分析装置１０Ｂ（ＵＤＰポート履歴情報管理部５０）が受信した注目端末を送信元とするＵＤＰフローの送信元ポートが５０００２番だったとする。この場合、５０００２番はクライアントポート利用リストＰＬ１に含まれるため、図１９（ｄ）に示すように、ＵＤＰポート履歴情報管理部５０は、再利用判定用ポートリストＰＬ２に追加する。
【0193】
このとき、ＵＤＰポート履歴情報管理部５０は、この時点で、再利用判断閾値と再利用判定用ポートリストの要素数を比較し、再利用判断閾値に達しているため、クライアントポート再利用があったと判断し、発生日数閾値をインクリメントし、発生日数閾値を３とする。ＵＤＰポート履歴情報管理部５０では、この時点で注目端末についての再利用判定用ポートリストの作成は完了となり、以下は２回目以降の再利用検知のアルゴリズムで判断が行われるようになる。
【0194】
図２０は、ＵＤＰポート履歴情報管理部５０が、注目端末について２回目以降のクライアントポート再利用検知を行う際の処理の流れを示した図である。
【0195】
図２０（ａ）～図２０（ｅ）では、時系列ごとの注目端末に関する再利用判定用ポートリストをＰＬ２と、再利用判定用ポートリストをＰＬ２の各ポートに対応する再利用フラグのリスト（以下、「再利用フラグリスト」と呼ぶ）ＦＬを図示している。
【0196】
図２０（ａ）では、初期状態において、再利用判定用ポートリストＰＬ２に５００００番と５０００２番が含まれ、再利用フラグリストＦＬは「Ｆａｌｓｅ、Ｆａｌｓｅ」（つまり、５００００番及び５０００２番の再利用フラグはいずれもＦａｌｓｅ）となっている。
【0197】
その後、通信分析装置１０Ｂ（ＵＤＰポート履歴情報管理部５０）が、注目端末が送信元となるＵＤＰフローを受信し、その送信元ポート番号が５００００番であったものとする。この場合、ＵＤＰポート履歴情報管理部５０は、５００００番が再利用判定用ポートリストに含まれるか確認し、この場合含まれるため、図２０（ｂ）に示すように再利用フラグリストＦＬにおいて５００００番に対応する再利用フラグをＴｒｕｅに変更する。
【0198】
次に、通信分析装置１０Ｂ（ＵＤＰポート履歴情報管理部５０）が受信した注目端末を送信元とするＵＤＰフローの送信元ポートが５００１０番だったものとする。この場合、ＵＤＰポート履歴情報管理部５０は、５００１０番が再利用判定用ポートリストＰＬ２に含まれないため、図２０（ｃ）に示すように再利用フラグリストＦＬは操作しない。
【0199】
次に、通信分析装置１０Ｂ（ＵＤＰポート履歴情報管理部５０）が受信した注目端末を送信元とするＵＤＰフローの送信元ポートが５０００２番だったものとする。この場合、５０００２番は再利用判定用ポートリストに含まれるため、図２０（ｄ）に示すように、ＵＤＰポート履歴情報管理部５０は、再利用フラグリストＦＬにおいて５０００２番に対応する再利用フラグをＴｒｕｅに変更する。この時、再利用フラグリストＦＬを構成する再利用フラグが全てＴｒｕｅになるため、ＵＤＰポート履歴情報管理部５０は、クライアントポート再利用と判断し、発生日数閾値をインクリメントし、発生日数閾値を４とする。
【0200】
最後に、ＵＤＰポート履歴情報管理部５０は、図２０（ｅ）に示すように、再利用フラグリストＦＬの再利用フラグの値を全てＦａｌｓｅに戻し（リセットし）、次の再利用検知に備える。
【0201】
サービスポートリスト管理部１６Ｂは、ＵＤＰポート履歴情報管理部５０から発生日数閾値（発生日数閾値の更新）を受けると、サービスポート判定では、注目端末の各宛先ポート番号について、発生日数閾値を超える宛先ポートのみを上述のサービスポート判定処理にかけることになる。
【0202】
（Ｃ－２）第３の実施形態の動作
次に、第３の実施形態の通信分析装置１０Ｂの動作（実施形態に係る通信分析方法）について、第１及び第２の実施形態との差異を中心に説明する。
次に、第３の実施形態の通信分析装置１０Ｂの動作（実施形態に係る通信分析方法）について、第１及び第２の実施形態との差異を中心に説明する。
【0203】
【0204】
通信分析装置１０Ｂが、ＵＤＰの通信フローを受信してから、ＵＤＰのサービスポートリストが更新されるまでの一連の処理（Ｓ６００）について、図２１を用いて説明する。
【0205】
まず、サービスポートリスト管理部１６Ｂは、制御部１２から通信フローの情報（５－ｔｕｐｌｅｓの情報とサービスポート番号）を受信し、受信した通信フローがＵＤＰの場合、ＵＤＰポート履歴情報管理部５０に５－ｔｕｐｌｅｓの情報を通知し、ＵＤＰポート利用履歴管理情報と発生日数閾値の更新を要求する（Ｓ６０１）。
【0206】
次に、ＵＤＰポート履歴情報管理部５０は、受信した通信フローの送信元ＩＰアドレスの端末（以後、注目端末）の発生日数閾値を更新する（Ｓ７００）。
【0207】
次に、ＵＤＰポート履歴情報管理部５０は、注目端末のＵＤＰポート履歴管理情報を更新（Ｓ８００）し、更新した情報をサービスポートリスト管理部１６Ｂに通知する。
【0208】
次に、サービスポートリスト管理部１６Ｂは、受信した注目端末の発生日数閾値およびＵＤＰポート履歴管理情報をもとに、注目端末のＵＤＰポート履歴管理情報に含まれる宛先ポート番号のうち、サービスポート判定にかけるポート番号を抽出し、抽出した各宛先ポート番号について、注目端末のＵＤＰのサービスポートリストに登録するか否かを判定する。そして、サービスポートリスト管理部１６Ｂは、判定の結果サービスポートとして登録された宛先ポート番号のリストを注目端末のＵＤＰのサービスポートリストとして出力する（Ｓ９００）。
【0209】
次に、ＵＤＰポート履歴情報管理部５０が、発生日数閾値の更新処理（ステップＳ７００の処理）の詳細について、図２２を用いて説明する。
【0210】
まず、ＵＤＰポート履歴情報管理部５０は、サービスポートリスト管理部１６Ｂから受信した５－ｔｕｐｌｅｓのフロー情報の送信元ＩＰアドレス（注目端末情報）から、注目端末の再利用判定用ポートリスト（クライアントポートが再利用されたときに当該ポート番号を格納しておくリスト）を取得する。そして、ＵＤＰポート履歴情報管理部５０は、取得した再利用判定用ポートリストにクライアントポートが再利用されたと判断するだけの要素が含まれているか（ポート番号の種類数が再利用検知閾値以上あるか）を確認する（Ｓ７０１）。ＵＤＰポート履歴情報管理部５０は、要素数が再利用検知閾値に満たない場合は初回の再利用検知処理（後述するステップＳ７０２）に移行し、要素数が再利用検知閾値に達している場合は２回目以降の再利用検知処理（後述するステップＳ７０７）に移行する。
【0211】
ＵＤＰポート履歴情報管理部５０は、ステップＳ７０２に移行すると、初回の再利用検知処理では、まず注目端末のＵＤＰ履歴管理情報から過去に利用された送信元ポート番号のリストを取得する（Ｓ７０２）。つまり、ＵＤＰポート履歴情報管理部５０は、注目端末のＵＤＰ履歴管理情報の各宛先ポートのサブリストに含まれる送信元ポート番号のリストを、重複を除いて一つのリストにまとめたものを用意し、注目端末のＵＤＰ履歴管理情報が存在しない場合は、空のリストとして扱う。
【0212】
次に、ＵＤＰポート履歴情報管理部５０は、受信フローの送信元ポート番号を取得し、注目端末の送信元ポート番号の中に同じポート番号が含まれているか確認する（Ｓ７０３）。ＵＤＰポート履歴情報管理部５０は、同じポート番号が含まれない場合は更新処理を終了し、同じポート番号が含まれる場合は、注目端末の再利用判定用ポートリストに当該ポート番号を追加する（Ｓ７０４）。このとき、ＵＤＰポート履歴情報管理部５０は、もし再利用判定用ポートリストに既に当該ポート番号が登録されている場合は追加しない。
【0213】
次に、ＵＤＰポート履歴情報管理部５０は、注目端末の再利用判定用ポートリストの要素数が、再利用検知閾値に達しているかを確認する（Ｓ７０５）。そして、ＵＤＰポート履歴情報管理部５０は、再利用検知閾値に達していない場合は更新処理を終了し、再利用検知閾値に達した場合は、注目端末のクライアントポート再利用と判断し、注目端末の発生日数閾値をインクリメント（Ｓ７０６）してから更新処理を終了する。
【0214】
ＵＤＰポート履歴情報管理部５０は、上述のステップＳ７０１から２回目以降の再利用検知処理に移行すると、まず、受信フローの送信元ポート番号を取得し、注目端末の再利用判定用ポートリストに当該ポート番号が含まれているかを確認する（Ｓ７０７）。ＵＤＰポート履歴情報管理部５０は、当該ポート番号がリストに含まれない場合、更新処理を終了し、当該ポート番号がリストに含まれる場合、再利用判定用ポートリストの当該ポート番号に対応する再利用フラグをＴｒｕｅにセットする（Ｓ７０８）。
【0215】
次に、ＵＤＰポート履歴情報管理部５０は、再利用判定用ポートリストに含まれる全てのポート番号に対応するフラグがＴｒｕｅにセットされているか確認する（Ｓ７０９）。いずれかのフラグがＦａｌｓｅにセットされている場合、ＵＤＰポート履歴情報管理部５０は、更新処理を終了する。一方、すべてのフラグがＴｒｕｅにセットされている場合、ＵＤＰポート履歴情報管理部５０は、注目端末のクライアントポート再利用と判断してフラグを全てＦａｌｓｅにリセット（Ｓ７１０）し、注目端末の発生日数閾値をインクリメント（Ｓ７０６）してから、更新処理を終了する。
【0216】
次に、ＵＤＰポート履歴情報管理部５０がＵＤＰポート履歴管理情報の更新処理を行う際の動作（上述のステップＳ８００の動作）について図２３を用いて説明する。
【0217】
まず、ＵＤＰポート履歴情報管理部５０は、注目端末のＵＤＰポート履歴管理情報が存在するか確認し（Ｓ８０１）、ＵＤＰポート履歴管理情報が存在する場合後述するステップＳ８０３に移行し、そうでない場合には後述するステップＳ８０２に移行する。
【0218】
上述のステップＳ８０１で、ＵＤＰポート履歴管理情報が存在しない場合、ＵＤＰポート履歴情報管理部５０は、注目端末のＵＤＰポート履歴情報を新規作成し（Ｓ８０２）、後述するステップＳ８０４に移行する。
【0219】
一方、上述のステップＳ８０１でＵＤＰポート履歴管理情報が存在する場合、ＵＤＰポート履歴情報管理部５０は、フロー情報から宛先ポート番号を取得し、注目端末のＵＤＰポート履歴情報に当該ポート番号のリストが存在するか確認し（Ｓ８０３）、リストが存在する場合後述するステップＳ８０５に移行し、そうでない場合には、後述するステップＳ８０４に移行する。
【0220】
上述のステップＳ８０３でリストが存在しない場合又は上述のステップＳ８０２の処理後、ＵＤＰポート履歴情報管理部５０は、注目端末のＵＤＰポート履歴情報に当該ポート番号のリストを新規作成し（Ｓ８０４）、後述するステップＳ８０６に移行する。
【0221】
一方、上述のステップＳ８０３でリストが存在する場合、ＵＤＰポート履歴情報管理部５０は、注目端末のＵＤＰポート履歴情報の当該ポート番号のリスト内の最新の日付のサブリスト（発生数、送信元ポート番号のリスト、発生日）を取得して、現在の日付と比較し（Ｓ８０５）、最新の日付のサブリストと現在の日付が同じである場合後述するステップＳ８０７に移行し、最新の日付のサブリストと現在の日付が同じでない場合（最新の日付と現在の日付を比較し現在の日付の方が新しい場合）後述するステップＳ８０６に移行する。
【0222】
上述のステップＳ８０５で最新の日付のサブリストと現在の日付が同じでない場合又は上述のステップＳ８０４の処理後に、ＵＤＰポート履歴情報管理部５０は、当該ポート番号のサブリストとして、発生数に１、送信元ポート番号のリストにフロー情報の送信元ポート番号の値、現在の日付を要素に持つサブリストを追加し（Ｓ８０６）、処理を終了する。
【0223】
一方、上述のステップＳ８０５で、最新の日付のサブリストと現在の日付が同じである場合、ＵＤＰポート履歴情報管理部５０は、最新の日付のサブリストの要素を更新し（Ｓ８０７）、処理を終了する。つまり、ＵＤＰポート履歴情報管理部５０は、発生数をインクリメントし、送信元ポート番号のリストにフロー情報の送信元ポート番号を追加する。
【0224】
ＵＤＰポート履歴情報管理部５０は、以上で注目端末のＵＤＰポート履歴管理情報の更新を終了し、上述の図２２のフローチャートの処理で更新した発生日数閾値の値とＵＤＰポート履歴管理情報とを、サービスポートリスト管理部１６Ｂに通知する。
【0225】
次に、サービスポートリスト管理部１６Ｂでの、ＵＤＰサービスポートリスト更新処理（上述のステップＳ９００の処理）について、図２４を用いて説明する。
【0226】
サービスポートリスト管理部１６Ｂは、ＵＤＰポート履歴情報管理部５０から注目端末の発生日数閾値とＵＤＰポート履歴管理情報を受信すると、注目端末のＵＤＰポート履歴管理情報に含まれる各宛先ポートについて、注目端末のＵＤＰサービスポートリストに登録するかを判断していく。そして、サービスポートリスト管理部１６Ｂは、注目端末のＵＤＰポート履歴管理情報からまだサービスポート判定処理していない宛先ポートの情報（宛先ポートの値と当該ポートのサブリスト）取得を試み（Ｓ９０１）、取得できた場合は後述するステップＳ９０２に移行し、そうでない場合には後述するステップＳ９０６に移行する。
【0227】
上述のステップＳ９０１でサービスポート判定処理していない宛先ポートが取得できた場合、サービスポートリスト管理部１６Ｂは、取得した宛先ポートのサブリストの数（つまり発生日数）を数え、サブリスト数が発生日数閾値より多いか確認し（Ｓ９０２）、発生日数閾値に満たない場合は、当該宛先ポートのサービスポート判定処理を終了して上述のステップＳ９０１に戻り、次の宛先ポートのサービスポート判定処理に移行する。
【0228】
一方、上述のステップＳ９０２で、サブリスト数が発生日数閾値以上となった場合、サービスポートリスト管理部１６Ｂは、取得した宛先ポートについて、送信元ポートリストのうち未チェックのポート（後述するステップＳ９０４のチェックが行われていないポート）が残っているか否かを確認し（Ｓ９０３）、残っている場合には後述するステップＳ９０４に移行し、そうでない場合には、当該宛先ポートのサービスポート判定処理を終了して上述のステップＳ９０１に戻り、次の宛先ポートのサービスポート判定処理に移行する。
【0229】
上述のステップＳ９０３の判定で未チェックのポートが残っている場合、サービスポートリスト管理部１６Ｂは、各サブリストの送信元ポート番号のリストからひとつずつ送信元ポート番号を取り出し、取り出した送信元ポート番号を宛先ポートとしたときの発生数（注目端末のＵＤＰポート履歴管理情報に含まれる宛先ポートで、取り出した送信元ポート番号と一致する宛先ポートのサブリストに含まれる発生数を合算した値）を計算する。そして、サービスポートリスト管理部１６Ｂは、判定対象の宛先ポートの発生数（ポート発生数Ｃ１）と、取り出した送信元ポート番号を宛先ポートとしたときの発生数（ポート発生数Ｃ２）を比較し（Ｓ９０４）、判定対象の宛先ポートの発生数の方が多い場合（Ｃ１＞Ｃ２の場合）後述するステップＳ９０５に移行し、そうでない場合は上述のステップＳ９０３に戻って動作する。
【0230】
上述のステップＳ９０４で、判定対象の宛先ポートの発生数の方が多い場合（Ｃ１＞Ｃ２の場合）、サービスポートリスト管理部１６Ｂは、当該ポートをサービスポートリストに追加し（Ｓ９０５）、上述のステップＳ９０１に戻って動作する。
【0231】
ステップＳ９０１において、サービスポート判定処理していない宛先ポートが残っていない場合、サービスポートリスト管理部１６Ｂは、注目端末のＵＤＰポート履歴管理情報に含まれる全ての宛先ポートについてサービスポート判定処理を完了し、その時点のサービスポートリストを、注目端末のＵＤＰサービスポートリストとして出力し（Ｓ９０６）、処理を終了する。
【0232】
（Ｃ－３）第３の実施形態の効果
第３の実施形態によれば、第1及び第２の実施形態と比較して以下のような効果を奏することができる。
第３の実施形態によれば、第1及び第２の実施形態と比較して以下のような効果を奏することができる。
【0233】
第３の実施形態（通信分析装置１０Ｂ）では、ＵＤＰのサービスポートリストの作成方法として、端末３０ごとに当該端末３０が送信元となる過去のＵＤＰ通信フロー情報（宛先ポート毎に、発生数、当該宛先ポートのフローにおける送信元ポート番号の種類、発生日を１日単位のサブリストで保持）をＵＤＰポート利用履歴管理情報として管理し、各宛先ポートの発生数と当該宛先ポートのリストに含まれる送信元ポート番号を宛先ポートとしてみたときの発生数を比較し、宛先ポートの発生数の方が多い場合にサービスポートとみなす。第３の実施形態（通信分析装置１０Ｂ）では、このような単純な大小比較の条件をサービスポート判定に用いることで、人手での閾値設定が必要なく、完全自動でサービスポートを作成できる。
【0234】
また、第３の実施形態（通信分析装置１０Ｂ）では、トラフィックのキャプチャを始めて間もない期間や新しいＵＤＰサービスが使われ始めた段階で、クライアント側のポートがサービスポートに誤って登録されてしまうのを防ぐために、宛先ポートの発生日数を条件に、発生日数が少ないものはサービスポート判定処理にかけない。さらに、第３の実施形態（通信分析装置１０Ｂ）では、サービスポート判定処理にかけるかの判断に使用する発生日数の閾値は、クライアントポートの再利用判定により動的に変化（増加）させる。第３の実施形態（通信分析装置１０Ｂ）では、このような追加の条件の設定により、サービスポートを誤判定してしまう確率を運用期間全体に渡って安定して低減させることができる。
【0235】
（Ｄ）他の実施形態
本発明は、上記の各実施形態に限定されるものではなく、以下に例示するような変形実施形態も挙げることができる。
本発明は、上記の各実施形態に限定されるものではなく、以下に例示するような変形実施形態も挙げることができる。
【0236】
（Ｄ－１）第１の実施形態における通信パターン学習部１７では、通信フロー履歴情報のパケットサイズや通信方向の情報を全て使用し特徴量に変換して通信パターン分析モデルを構築していたが、これに限定されない。例えばトラフィックキャプチャ以前に開始された通信フローのように、通信フローの先頭パケットが通信フロー情報に含まれない通信フローをサービスポート推定部１５で分析する可能性を考慮し、通信パターン学習部１７での学習データにバリエーションを持たせるようにしてもよい。例えば、通信パターン学習部１７は、学習に使用される通信フロー履歴情報の先頭１パケット目の情報（パケットサイズと通信方向）を除いて特徴量に変換するようにしてもよい。同様に、通信パターン学習部１７は、先頭２パケット目までの情報を除いて特徴量に変換するようにしてもよい。通信パターン学習部１７は、これを最大先頭ｍパケット目分まで実施する。このように学習データにバリエーションを持たせることで、先頭パケットが含まれない通信フローのサービスポートを推定する場合にも、サービスポートを判定できる確率を高めることができる。
【0237】
（Ｄ－２）第１の実施形態では、通信パターン分析モデルをＩＰ毎のサービスポートリストの各ポート番号に対応させる形で構築していたが、これに限定されない。例えば、ポート番号毎に唯一つの通信パターン分析モデルを構築し、サービスポート推定ではＩＰに依らず共通の通信パターン分析モデルとして使用する方法が考えられる。ＩＰ毎にサービスポート番号に対応する通信パターン分析モデルを構築する場合に比べ、構築するモデルの数を削減できるため、通信パターン学習部１７での処理負荷を低減し、記憶部１８でモデル保持用に確保する保存容量を削減することができる。
【0238】
（Ｄ－３）上記の各実施形態では、サービスポートリスト管理部１６で、ＵＤＰのサービスポートリストの更新処理を、通信フロー情報受信の度に更新していたが、更新間隔を定めて更新間隔毎にサービスポートリストを更新してもよい。例えば、更新間隔として時間情報を用い、例えば２４時間に１回の頻度で各ＩＰのサービスポート候補リストからサービスポートリストを作成・更新する処理を実行する方法が考えられる。このように更新間隔を設定することで、通信フロー受信処理に係る時間を短縮することができる。同様に、通信パターン学習部１７でのモデル構築も更新間隔を設けて、更新間隔毎に通信パターン分析モデルを構築するようにしてもよい。
【0239】
（Ｄ－４）第１の実施形態において、サービスポートリスト管理部１６で管理される各種サービスポートリストは、受信した通信トラフィックを受けて、作成・更新されていくような運用方法になっていたが、これに限定されず、監視対象ネットワークＮ１で利用されていることが把握できている通信ＩＰペアと当該ペア間で通信されるサービスポートを管理者などが予め手動で追加しておくようにしてもよい。また、上記の実施形態において、通信分析装置１０の運用中に、管理者等によりサービスポートリスト管理部１６で管理されるサービスポートリストの内容を編集可能とするようにしてもよい。例えば、通信分析装置１０の運用中に、判明した通信ＩＰペアと当該ペア間で通信されるサービスポートの追加を受け入れたり、サービスポートリスト管理部１６で作成された各種サービスポートリストのなかで誤って登録されたサービスポートの修正を受け入れる等の処理が挙げられる。例えば、ＦＴＰ（Ｆｉｌｅ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）のアクティブモードではサーバから通信フローが開始され、サービスポートは送信元ポート番号（サーバ側のポート）が使用されるため（以下の参考文献１参照）、第１の実施形態の通信分析装置１０のように、ＴＣＰの通信についてＳＹＮフラグをみてサービスポートを判定する方式ではサービスポートリスト管理部１６に誤ったサービスポートリストが設定されることになる。しかしながら、サービスポートリスト管理部１６で管理されるサービスポートリストの内容を管理者等により編集可能とすることで、上記のＦＴＰのような特殊なケースでも、サービスポートリスト管理部１６のサービスポートリストを修正し、サービスポートの誤識別を低減させることができる。
【0240】
参考文献１：FTPにおけるアクティブモードとパッシブモードの違い CentOSサーバー構築入門，[Online]，INTERNET，[２０２３年１月１３日検索]，<URL:http://cos.linux-dvr.biz/archives/131>
【0241】
（Ｄ－５）第１及び第３の実施形態（通信分析装置１０、１０Ｂ）では、ＵＤＰのサービスポートリスト作成にあたり、通信フローはクライアントからサーバに向かって張られ、サービスポートは宛先ポート側の番号である、という前提を置いていた。しかし一部のサービスにおいては、サーバからクライアントに張られるＵＤＰの通信フローが存在する。例えば、Ｍｉｃｒｏｓｏｆｔ社のＲＤＰ（ＲｅｍｏｔｅＤｅｓｋｔｏｐＰｒｏｔｏｃｏｌ）では、最初にクライアントからサーバに対してＴＣＰでセッションを張った後に、データ転送では、サーバからクライアントにＵＤＰのフローが張られる場合がある（以下の、参考文献２参照）。この場合、サーバ側のポート番号（つまり送信元ポート番号）がサービスポートであり、宛先ポートをサービスポートの前提とする考え方ではこれらのサービスポートを正しく判定することができない。
【0242】
参考文献２：“Messages and Intersection with Other Protocols”，[Online]，INTERNET，[２０２３年１２月１７日検索]，<https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-rdpemt/02d833db-5c7c-4c15-a18e-179df6d8a34d>
このようなサーバから張られるＵＤＰの通信フローについて、送信元ポート番号をサービスポートと判定できるようにするために、送信元ポート番号についても発生頻度分析を行い、発生頻度の多いものをサービスポートとみなすような方法が考えられる。
このようなサーバから張られるＵＤＰの通信フローについて、送信元ポート番号をサービスポートと判定できるようにするために、送信元ポート番号についても発生頻度分析を行い、発生頻度の多いものをサービスポートとみなすような方法が考えられる。
【0243】
例えば、第１の実施形態（通信分析装置１０）のＵＤＰサービスポート判定方法では、ＵＤＰの宛先ポートの発生頻度を分析し、大きい方の外れ値として判断されたポートをサービスポートとみなしていたが、ＵＤＰの送信元ポートについても行うようにしてもよい。つまり、第１の実施形態（通信分析装置１０）において、ＵＤＰの通信フローの送信元ポート番号についても発生頻度を記録しておき、発生頻度の外れ値検出で、大きい方の外れ値として判断された送信元ポート番号をサービスポートとみなすようにしてもよい。
【0244】
また、第３の実施形態（通信分析装置１０Ｂ）のＵＤＰサービスポート判定方法では、端末３０ごとにＵＤＰポート利用履歴管理情報として宛先ポート毎の発生数、送信元ポート番号、発生日数を管理していたが、送信元ポートについても行うようにしてもよい。つまり、第３の実施形態（通信分析装置１０Ｂ）において、端末３０ごとにＵＤＰポート利用履歴管理情報に追加で送信元ポート毎の発生数、宛先ポート番号の種類、発生日数を管理するようにしてもよい。そして、第３の実施形態（通信分析装置１０Ｂ）において、宛先ポートでのサービスポート判定と同じ方法で送信元ポートのＵＤＰポート利用履歴管理情報からサービスポートとなるポート番号を抽出し、サービスポートリストに追加するようにしてもよい。以上のように、第１及び第３の実施形態（通信分析装置１０、１０Ｂ）において、宛先ポートだけでなく送信元ポートについても宛先ポートと同様の管理方法および条件判定方法により、送信元ポート番号をサービスポートとするポートも取り逃すことなく抽出することができる。
【0245】
（Ｄ―６）第２の実施形態（通信分析装置１０Ａ）では、通信パターン分析モデルを用いず、推定対象のポートがサービスポートリストに含まれるか否かのみでサービスポートを推定していた。この推定方法では、送信元ポートと宛先ポートの両方がサービスポートリストに含まれる場合に、どちらのポートの方がサービスポートらしいかの判断ができず、判定不能となるケースが増加してしまう。そこで、第２の実施形態（通信分析装置１０Ａ）において、通信パターン分析モデルを用いず別の手段でサービスポートの確からしさを判断する方法を適用するようにしてもよい。例えば、第２の実施形態（通信分析装置１０Ａ）において、サービスポートリストに含まれるポート毎に発生頻度を記録しておき、サービスポートの推定では、送信元ポートと宛先ポートの両方がサービスポートリストに含まれる場合に、発生頻度の多いポートの方をサービスポートに設定するようにしてもよい。これにより、第２の実施形態（通信分析装置１０Ａ）において、サービスポートリスト内で管理する情報にポート番号以外の情報を追加し、サービスポート推定に利用することで、サービスポート判定不能となる事象を低減することができる。
【0246】
（Ｄ－７）第３の実施形態（通信分析装置１０Ｂ）では、ＵＤＰポート利用履歴管理情報の宛先ポートの発生日数を閾値に、発生日数が少ないものはサービスポートと判定しない条件を設定していた。つまり、第３の実施形態（通信分析装置１０Ｂ）では、発生日数閾値の初期値は２であるため、少なくとも宛先ポートが使われ始めて丸一日経たないとサービスポートリストに登録されない。また、第３の実施形態（通信分析装置１０Ｂ）では、運用中に新しく使われ始めたサービスポートは、その時点の発生日数閾値によっては２日よりもさらに長く経たないとサービスポートに登録されないことになる。
【0247】
そこで、第３の実施形態（通信分析装置１０Ｂ）で、あるポート（以下、「注目ポート」という）についてサービスポート判定処理に進むか否かを決定する処理（以下、「移行判定処理」という）において、発生日数が短くてもサービスポートリストに登録されるようにするために、通信実績に基づきサービスポート判定処理に進むか否かを決定する処理（以下、「通信実績判定処理」という）を追加する方法を適用するようにしてもよい。以下では、通信実績判定処理に適用する条件を、「通信実績判定条件」と呼ぶものとする。
【0248】
ここでの通信実績判定条件とは、サービスポートと判定するのに十分な通信実績があるものとし、例えば、当該宛先ポートの送信元ポートリストに含まれるポート番号の種類（以下、「送信元ポート種類数」という）が一定以上（例えば、３０以上）であったり、当該宛先ポートがＵＤＰポート利用履歴管理情報に登録されている端末数（以下、「ポート利用端末数」という）が一定以上（例えば、監視対象となる全端末数の１０％）であるといった条件を設定し得る。以下では、送信元ポート種類数に対応する閾値をＸとし、ポート利用端末数に対応する閾値をＹとする。これは、送信元ポートの種類数が多い宛先ポートは送信元ポートがクライアントポートとして使われている可能性が高いことを示し、利用端末数が多い宛先ポートはネットワーク内で一般に利用されるサービスポートである可能性が高いことを示すと考えられることからきている。ここで、これらの条件ではいずれも閾値を設定する必要があり、閾値が小さいほどより多くの宛先ポートが早期にサービスポートに登録されるが誤検知（クライアント側のポートがサービスポートとして登録される）の確率は高い。一方、閾値を大きくするほど、誤検知の確率は低くなるが、早期にサービスポートに登録されるのは、よりメジャーなサービスポートに限られる。そのため、通信実績判定条件において、誤検知数を重視（確度を重視）するか、早期の適用（適用スピード）を重視するかで、プリセットとしてこれらの閾値のパラメータ（Ｘ、Ｙ）の組み合わせをいくつか用意しておく方法が考えられる。
【0249】
図２５は、通信実績判定条件のプリセットの例について示した図である。
【0250】
図２５では、通信実績判定条件に、適用スピード重視（適用スピードを重視した設定）、確度重視（確度重視した設定）、バランス（適用スピード及び角度の両方を考慮した設定）の３種類のプリセットについて設定する例について示しているが、プリセットの数や組み合わせはこれに限定されない。図２５では、「適用スピード重視」のプリセットとして、送信元ポート種類数Ｘ＝３０と、ポート利用端末数Ｙ＝（全端末数×０．１）を設定している。また、図２５では、「バランス」のプリセットとして、送信元ポート種類数Ｘ＝１００と、ポート利用端末数Ｙ＝（全端末数×０．２）を設定している。さらに、図２５では、「確度重視」として、条件（送信元ポート種類数Ｘ、ポート利用端末数Ｙ）を設定しない（つまり、つまり発生日数の条件のみでサービスポート判定に進むかの判断を行う）という設定をしている。
【0251】
第３の実施形態（通信分析装置１０Ｂ）において、上記のような複数のプリセットを設定可能とすることで、ネットワークの運用者の方針などによって、最初に適当なプリセットを設定（例えば、上記の３つのプリセットのいずれかを設定）し動作させることができる。なお、ここでは、サービスポートリスト管理部１６Ｂが移行判定処理を行うものとする。
【0252】
図２６は、第３の実施形態の変形実施例に係る通信分析装置１０Ｂ（サービスポートリスト管理部１６Ｂ）が、あるポート（以下、「注目ポート」と呼ぶ）についてサービスポート判定処理への移行判定処理を行う際の流れについて示したフローチャート（その１）である。
【0253】
ここでは、前提として、サービスポートリスト管理部１６Ｂにおいて、通信実績判定条件（例えば、図２５に示すいずれかのプリセット）が予め設定されているものとする。
【0254】
サービスポートリスト管理部１６Ｂは、注目ポートについて移行判定処理を開始すると、まず、注目ポートをサービスポートした場合における通信実績判定処理を行う（Ｓ１００１）。具体的には、サービスポートリスト管理部１６Ｂは、予め設定したプリセットの閾値（Ｘ，Ｙ）を使用し、送信元ポート種類数が閾値Ｘを超える、またはポート利用端末数が閾値Ｙを超える場合、注目ポートについてサービスポートしての通信実績が十分あると判断し、注目ポートについてサービスポート判定処理（ステップＳ１００３）に進む。
【0255】
一方ステップＳ１００１の通信実績判定処理で、サービスポートしての通信実績が十分でないと判定された場合、サービスポートリスト管理部１６Ｂは、注目ポートについて、発生日数や後述する一日あたりの利用端末数による条件でサービスポート判定処理に進むか判断し（Ｓ１１０２）、サービスポート判定処理（ステップＳ１００３）又はサービスポートと判定しないことの決定（Ｓ１００４）のいずれかに移行することになる。
【0256】
（Ｄ－８）第３の実施形態（通信分析装置１０Ｂ）では、ＵＤＰポート利用履歴管理情報の宛先ポート（注目ポート）の発生日数を閾値にサービスポート判定処理に進むか判断していた。また、この発生日数閾値の決め方は端末３０のクライアントポート再利用検知と連動してインクリメントされていく方法であった。ここで、通信サービスによっては、特定のサービスポートを使うのではなく、サービスポートの値を何らかの規則（例えば通信する度にサービスポートをインクリメントする）に従ってダイナミックに変更しながら通信するものがある。この場合、各ダイナミックに変化するサービスポートのフローは、フロー単位でみればサービスポートは宛先ポートで間違いないと考えられるが、これらのサービスポートは一般にハイポート（ウェルノウンポートより大きい値のポート番号）を用い、クライアント側で使われるポートと重複することも多いため、サービスポート判定で送信元ポートも宛先ポートもサービスポートリストに含まれ判定不能と判断される可能性があり、サービスポートリストに登録されるのは好ましくない。ダイナミックに変化するサービスポートの場合、クライアントポートの再利用とは異なるタイミング（より早いタイミング）で、利用されるサービスポートの範囲を一通り使用し、発生日数がより早くインクリメントされてしまう可能性がある。つまり、発生日数のみの条件ではダイナミックに変化するサービスポートがサービスポートリストに登録されてしまう可能性がある。
【0257】
そこで、ダイナミックに変化するサービスポートがサービスポートリストに登録されないようにするために、任意の宛先ポート（注目ポート）の移行判定処理において、発生日数以外に追加の判定条件を設けることが好ましい。ここでは、ＵＤＰポート利用履歴管理情報に含まれる宛先ポート毎に、「１日当りの利用端末数」（ＵＤＰポート利用履歴管理情報の各端末の宛先ポートとその発生日を取り出して、他の端末で宛先ポートと発生日が一致するものをカウントし、これを全ての発生日に対して計算し、その合計値をトータルの発生日数で除算した値）が一定値（例えば、２）より小さい宛先ポートはサービスポート判定処理から除外するものとする。これは、複数の端末がダイナミックに変化するサービスポートを使うサービスを利用する場合であっても、使われるサービスポートは端末ごとに異なる（サービスポートの範囲は同じかもしれないが、同じ日に同じサービスポートを使うことはほとんどない）と考えられるため、このようなポートの一日単位での利用端末数は２より小さい値になる可能性が高いと考えられることからきている。一方で、移行判定処理にこの条件を加えた場合、ネットワークで一つの端末でしか使われていないサービスポートがサービスポートリストに登録されなくなってしまうが、先述の通信実績ベースでのサービスポート判定条件と組み合わせることで回避できると考えられる。
【0258】
図２７は、第３の実施形態の変形実施例に係る通信分析装置１０Ｂ（サービスポートリスト管理部１６Ｂ）が、注目ポートについてサービスポート判定処理への移行判定処理を行う際の流れについて示したフローチャート（その２）である。
【0259】
図２７では、サービスポートリスト管理部１６Ｂが、移行判定処理に際して、発生日数に加えてダイナミックに変化するサービスポート（１日当りの利用端末数を考慮）を考慮する流れになっている。図２７では、図２６のフローチャートにステップＳ１００５（１日当りの利用端末数を考慮する処理）が追加されている点で異なっている。
【0260】
図２７のフローチャートにおいて、サービスポートリスト管理部１６Ｂは、ステップＳ１００２で、注目ポートの発生日数が発生日数閾値より大きい場合に、１日当りの利用端末数と一定値（２）を比較し（Ｓ１００５）、一日あたり利用端末数が２以上の場合にサービスポート判定処理（ステップＳ１００３）に移行し、そうでない場合にはサービスポートと判定しないことの決定（Ｓ１００４）に移行する。これにより、第３の実施形態の変形実施例に係る通信分析装置１０Ｂでは、ダイナミックに変化するサービスポートが発生日数条件をすり抜けてサービスポート判定に進むケースを抑制し、より信頼のできるサービスポートリストを作成することができるようになる。
【0261】
（Ｄ－９）第３の実施形態（通信分析装置１０Ｂ）では、端末３０ごとにＵＤＰポート利用履歴管理情報を管理していたが、これに限定されず、ネットワークで唯一のＵＤＰポート利用履歴管理情報を持つような管理方法を適用してもよい。端末３０ごとにＵＤＰポート利用履歴管理情報を持つ場合、端末数が多くなるほどＵＤＰポート利用履歴管理情報のファイルサイズが増大し、特に計算資源の限られた小型な装置上での管理が現実的でない場合がある。そのため、第３の実施形態（通信分析装置１０Ｂ）において、ネットワークで一つのＵＤＰポート利用履歴管理情報のみを持つことにより計算資源の大小に依らず様々な装置上で本実施例を適用することができる。
【符号の説明】
【0262】
１０…通信分析装置、１１…トラフィックキャプチャ部、１２…制御部、１３…サービスポート判定部、１４…ブロードキャスト処理部、１５…サービスポート推定部、１６…サービスポートリスト管理部、１７…通信パターン学習部、１８…記憶部、１９…タイマ部、３０…監視対象機器、Ｎ１…監視対象ネットワーク。
【図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】