JP2019036865A - 通信解析装置、通信解析プログラム、及び通信解析方法 - Google Patents
通信解析装置、通信解析プログラム、及び通信解析方法 Download PDFInfo
- Publication number
- JP2019036865A JP2019036865A JP2017157585A JP2017157585A JP2019036865A JP 2019036865 A JP2019036865 A JP 2019036865A JP 2017157585 A JP2017157585 A JP 2017157585A JP 2017157585 A JP2017157585 A JP 2017157585A JP 2019036865 A JP2019036865 A JP 2019036865A
- Authority
- JP
- Japan
- Prior art keywords
- abnormality
- abnormality detection
- information
- network
- final determination
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Landscapes
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
【課題】 ネットワーク上の異常を検知した際に、その異常の内容についてまで判定可能とする。【解決手段】 本発明は、ネットワーク上の異常を検知する通信解析装置に関する。そして、本発明の通信解析装置は、ネットワーク上に配置されたネットワーク装置で発生した情報から異常の度合を検知する複数の異常検知手段と、ネットワーク装置で発生した情報から条件情報に該当する情報を抽出して特徴量として生成して各異常検知手段に供給する特徴量生成手段と、それぞれの異常検知手段が出力した検知結果を条件情報ごとに集計して、その集計結果を出力ベクトルとして生成する出力ベクトル生成手段と、出力ベクトルに基づきネットワークで発生した異常の内容を最終的に判定する最終判定処理を行う最終判定手段とを有することを特徴とする。【選択図】 図1
Description
この発明は、通信解析装置、通信解析プログラム、及び通信解析方法に関し、例えば、ネットワーク上に配置されたネットワーク装置のログ等を解析してネットワークの異常の検知(監視)を行う異常検知装置に適用し得る。
従来、ネットワーク上に配置されたネットワーク装置のログ等を監視して、ネットワーク上の異常(例えば、不正アクセスや攻撃的なアクセスやネットワーク障害)を検知する異常検知装置(監視装置)では、異常検知対象(監視対象)のネットワーク上に配置されたProxy(例えば、ネットワーク上に配置された端末やサーバとインターネットとの間の通信の中継に用いるProxy)のログ(以下、「Proxyログ」と呼ぶ)や、異常検知対象(監視対象)のネットワークの不正侵入を検知するIDS(Intrusion Detection System)システムのログ(以下、「IDSログ」とも呼ぶ)や、異常検知対象(監視対象)のネットワーク上に配置されたメールサーバ(例えば、SMTP(Simple Mail Transfer Protocol)、IMAP(Internet Message Access Protocol)、POP(Post Office Protocol)等に対応したメールサーバ)のログ(以下、「mailログ」とも呼ぶ)や、異常検知対象(監視対象)のネットワーク上に配置されたFW(Fire Wall)のログ(以下、「FWログ」とも呼ぶ)等のセキュリティ関連のログ(以下、「セキュリティログ」とも呼ぶ)をプールするデータプール部と、データプール部が蓄積したセキュリティログを解析してネットワーク上の異常を検知する異常検知エンジンを複数備える。
そして、従来の異常検知装置が備える異常検知エンジンは、それぞれ、セキュリティログから所定の特徴量の取得を試み、取得した特徴量の内容に基づいて異常を検知する。従来の異常検知装置では、例えば、IPアドレス単位に特徴量の取得を試み、異常を検知する。
また、従来の異常検知装置では、セキュリティログから、各異常検知エンジン部の解析で必要となる特徴量を生成(取得)する特徴量生成部を備えるものも存在する。従来の異常検知装置における特徴量生成部は、例えば、異常検知エンジン部に入力するために必要な統計値などの特徴量を生成する処理を行う。具体的には、従来の異常検知装置における特徴量生成エンジンは、例えば、外れ値検出や、閾値との比較等の統計的な処理を行い、それぞれのアルゴリズムに適したIPアドレスを、異常検知したIPアドレス(以下、「異常IP」とも呼ぶ)のリスト(以下、「異常IPリスト」と呼ぶ)として出力する。
さらに、従来の異常検知装置では、各異常検知エンジン部から出力された異常IPリストに基づいて異常IPごとの緊急度を算出する緊急度算出部を備えるものも存在する。従来の異常検知装置における緊急度算出部は、例えば、複数の異常検知エンジン部で異常IPと判断されたIPアドレスについてはより緊急度の高いIPアドレスと判断する。さらに、従来の異常検知装置における緊急度算出部は、例えば、DB(データベース)のような重要な装置が異常IPと判断された場合には緊急度を上げる判断を行う。
また、従来の異常検知方法としては特許文献1に記載された方法も存在する。特許文献1には、ゲートウェイ上で監視対象のネットワークの全通信を観測するゲートウェイセンサと、監視対象のホストにはWebサイト閲覧ソフトによる通信を観測するホストセンサを用いた異常検知(マルウェアの感染の検知)方法について記載されている。そして、特許文献1に記載された異常検知方法では、ユーザ(監視対象のホスト)のウェブブラウジングのアクセス先の多様性の影響を除外することでホワイトリスト作成の困難さを軽減し、誤検知(ユーザビリティの低下)を抑えつつ高い検知率を実現している。
しかしながら、従来の異常検知装置では、以下のような課題が存在した。
従来の異常検知装置では、特定のIPアドレスが異常性の高い通信をしているということは認識できるが、どのような理由で異常性が高いと検出されたのか不明となる。
従来の異常検知装置を利用するオペレータ(例えば、ネットワーク管理者等)は、どの異常検知エンジンから出力されたのかによって、どういう異常かを経験的に推測することはできるが、オペレータ自身による解析作業が必要となる。
以上のような問題に鑑みて、ネットワーク上の異常を検知した際に、その異常の内容についてまで判定可能な通信解析装置、通信解析プログラム、及び通信解析方法が望まれている。
第1の本発明の異常検知装置は、(1)ネットワーク上に配置されたネットワーク装置で発生した情報から、前記ネットワークの異常の度合を検知する複数の異常検知手段と、(2)それぞれの前記異常検知手段について、前記ネットワーク装置で発生した情報から、異常検知の対象となる条件情報に該当する情報を抽出し、抽出した情報に基づいて、それぞれの前記異常検知手段に供給する特徴量を生成する特徴量生成手段と、(3)それぞれの前記異常検知手段が、前記特徴量生成手段が生成した特徴量に基づいて検知した検知結果を、条件情報ごとに集計し、条件情報ごとの検知結果を含む情報をそれぞれ出力ベクトルとして生成する出力ベクトル生成手段と、(4)出力ベクトル生成手段が生成した前記出力ベクトルに基づき、前記ネットワークで発生した異常の内容を最終的に判定する最終判定処理を行う最終判定手段とを有することを特徴とする。
第2の本発明の異常検知プログラムは、コンピュータを、(1)ネットワーク上に配置されたネットワーク装置で発生した情報から、前記ネットワークの異常の度合を検知する複数の異常検知手段と、(2)それぞれの前記異常検知手段について、前記ネットワーク装置で発生した情報から、異常検知の対象となる条件情報に該当する情報を抽出し、抽出した情報に基づいて、それぞれの前記異常検知手段に供給する特徴量を生成する特徴量生成手段と、(3)それぞれの前記異常検知手段が、前記特徴量生成手段が生成した特徴量に基づいて検知した検知結果を、条件情報ごとに集計し、条件情報ごとの検知結果を含む情報をそれぞれ出力ベクトルとして生成する出力ベクトル生成手段と、(4)出力ベクトル生成手段が生成した前記出力ベクトルに基づき、前記ネットワークで発生した異常の内容を最終的に判定する最終判定処理を行う最終判定手段として機能させることを特徴とする。
(1)第3の本発明は、異常検知装置が行う異常検知方法において、(2)前記異常検知装置は、複数の異常検知手段、特徴量生成手段、出力ベクトル生成手段、及び最終判定手段を備え、(3)それぞれの前記異常検知手段は、前記ネットワークに配置されたネットワーク装置で発生した情報から、前記ネットワークの異常の度合を検知し、(4)前記特徴量生成手段は、それぞれの前記異常検知手段について、前記ネットワーク装置で発生した情報から、異常検知の対象となる条件情報に該当する情報を抽出し、抽出した情報に基づいて、それぞれの前記異常検知手段に供給する特徴量を生成し、(5)前記出力ベクトル生成手段は、それぞれの前記異常検知手段が、前記特徴量生成手段が生成した特徴量に基づいて検知した検知結果を、条件情報ごとに集計し、条件情報ごとの検知結果を含む情報をそれぞれ出力ベクトルとして生成し、(6)前記最終判定手段は、前記出力ベクトル生成手段が生成した前記出力ベクトルに基づき、前記ネットワークで発生した異常の内容を最終的に判定する最終判定処理を行うことを特徴とする。
本発明によれば、ネットワーク上の異常を検知した際に、その異常の内容についてまで判定可能な通信解析装置、通信解析プログラム、及び通信解析方法を提供することができる。
(A)主たる実施形態
以下、本発明による通信解析装置、通信解析プログラム、及び通信解析方法の一実施形態を、図面を参照しながら詳述する。以下では、本発明の通信解析装置、通信解析プログラム、及び通信解析方法を、異常検知装置に適用した例について示している。
以下、本発明による通信解析装置、通信解析プログラム、及び通信解析方法の一実施形態を、図面を参照しながら詳述する。以下では、本発明の通信解析装置、通信解析プログラム、及び通信解析方法を、異常検知装置に適用した例について示している。
(A−1)実施形態の構成
図1は、この実施形態に関係する各装置の全体構成について示したブロック図である。
図1は、この実施形態に関係する各装置の全体構成について示したブロック図である。
異常検知装置1000は、ネットワークNの異常を検知する処理等を行う装置である。
この実施形態では、異常検知対象のネットワークNには、Proxy201、IDS202、Mailサーバ203、及びFW204を含むネットワーク装置(通信装置)が配置されており、それぞれのネットワーク装置で発生するログがデータプール部10に蓄積される構成となっているものとする。ネットワークNに配置されている通信装置の数や構成については限定されないものである。
データプール部10は、ネットワークN上の各ネットワーク装置(Proxy201、IDS202、Mailサーバ203、FW204、…)で発生したログを蓄積して、蓄積したログのデータを異常検知装置1000に供給する手段である。データプール部10の具体的な構成については限定されないものであるが、例えば、ログ収集装置として機能するコンピュータ(サーバ装置)等を適用することができる。以下では、Proxy201で発生するログをProxyログL−1と表し、IDS202で発生するログをIDSログL−2と表し、Mailサーバ203で発生するログをMailログL−3と表し、FW204で発生するログをFWログL−4と表すものとする。
次に、異常検知装置1000の内部構成について説明する。
図1に示すように、異常検知装置1000は、大別すると1段目システム1と2段目システム2を有している。
この実施形態では、プロセッサやメモリ等を有するコンピュータ上に実施形態に係る通信解析プログラム(1段目システム1及び2段目システム2に相当する処理を行うプログラム)をインストールすることにより実現することができる。
1段目システム1には、特徴量生成部20と、X個(Xは2以上の整数)の異常検知エンジン部30(30−1〜30−X)が配置されている。
特徴量生成部20は、異常検知の解析対象となるログの条件が定義(1又は複数の項目の情報により定義)された情報(以下、「条件情報」と呼ぶ)が入力されると、その条件情報に基づいて、それぞれの異常検知エンジン部30の異常検知処理で必要となる情報(以下、「特徴量」とも呼ぶ)を生成(データプール部10から取得して生成)して、それぞれの異常検知エンジン部30に供給する。以下では、異常検知エンジン部30(30−1〜30−X)に供給される特徴量を特徴量F(F−1〜F−X)と表すものとする。
例えば、特徴量生成部20に各異常検知エンジン部30に対応するログ(サーバ)を設定しておき、特徴量生成部20がそれぞれの異常検知エンジン部30に対応するログで、かつ、供給された条件情報に該当するログをデータプール部10から取得することで特徴量Fを生成するようにしてもよい。具体的には、例えば、異常検知エンジン部30−1が、Proxy201から出力されるProxyログL−1を解析して異常度を判定する処理を行うものであれば、特徴量生成部20は、データプール部10のProxyログL−1から、条件情報に該当するログを抽出したものを特徴量F−1として、異常検知エンジン部30−1に供給する。
条件情報には、例えば、各ログを検索(各ログ内のレコードを検索)する際にキーとなる情報(以下、「キー情報」と呼ぶ)を含むようにしてもよい。キー情報には、例えば、IPアドレスや、FQDNや、ユーザID(例えば、認証処理に関するログに含まれるユーザIDを示す文字列)などの情報を含むようにしてもよい。キー情報に含む情報の項目の種類や数は限定されないものであるが、この実施形態の例では、キー情報にIPアドレス、FQDN、及びユーザIDの等の項目を設定可能であるものとして説明する。なお、条件情報を構成するキー情報に設定する情報の項目や種類は限定されないものである。例えば、条件情報を構成するキー情報に、IPアドレス、FQDN、及びユーザIDのうちから設定するようにしてもよい。条件情報を構成するキー情報は、1つだけ設定可能としてもよいし、複数設定可能とするようにしてもよい。また、条件情報を構成するキー情報には、同じ項目の情報を複数設定(例えば、複数のIPアドレスを設定)することが可能な構成としてもよい。特徴量生成部20は、キー情報に複数の項目が設定されている場合には、その複数の項目の両方が含まれるログ(ログを構成するレコード)を特徴量Fとして抽出するようにしてもよい。例えば、キー情報にIPアドレスとFQDNの対を設定することで、異常検知装置1000において、通信ペアの異常性判定等が可能となる。また、例えば、キー情報に、FQDNとユーザIDをキーとすることで、異常検知装置1000において、通常業務でアクセスしていない場所へのアクセス異常性判定などを行うことができる。
また、ここでは、条件情報に、データプール部10から取得するログの時間的範囲を定義した情報(以下、「ログ取得範囲情報」と呼ぶ)を設定するようにしてもよい。すなわち、特徴量生成部20は、ログ取得範囲情報に定義された期間のログから、キー情報に該当するログを取得する処理を行う。ログ取得時間情報には単純に、ログを取得する時刻の範囲の情報を設定するようにしてもよいし、繰り返しログを取得する際のパターン(以下、「繰り返しパターン」と呼ぶ)を示す情報を設定するようにしてもよい。この実施形態では、ログ取得時間情報には、繰り返しパターンが設定されるものとして説明する。具体的には、この実施形態では、ログ取得時間情報に、ログ取得の開始時間(以下、「Start−Time」とも表す)、及びログ取得の間隔(以下、「Time−Window」とも表す)が含まれるものとして説明する。したがって、キー情報を「key」と表すとすると、条件情報は、「(key,Start−Time,Time−Window)」という書式(フォーマット)で表すことができる。
以上のように、特徴量生成部20は、各異常検知エンジン部30に対して、各異常検知エンジン部30に対応するサーバのログから、供給された条件情報を構成するキー情報(key)及びログ取得範囲情報(Start−Time,Time−Window)に該当するログを抽出して、各異常検知エンジン部30に供給する特徴量Fを生成する。
例えば、条件情報のログ取得範囲情報で、Start−Timeとして時刻T、Time−WindowとしてW秒が指定された場合、特徴量生成部20は、時刻Tを起点としてW秒間隔でデータプール部10から、キー情報に該当するログを解析対象のログとして取得し、取得した解析対象のログを用いて特徴量Fを生成する。具体的には、例えば、条件情報のログ取得範囲情報で、Start−Timeとして時刻00:00:00(0時0分0秒)、Time−Windowとして60秒が指定された場合を想定する。この場合、特徴量生成部20は、時刻00:00:00〜00:00:59の期間のログから、キー情報に該当するログを1回目の解析対象のログとして取得して特徴量Fを生成する。次に、特徴量生成部20は、時刻00:01:00〜00:01:59の期間のログから、キー情報に該当するログを、2回目の解析対象のログとして取得して特徴量Fを生成する。特徴量生成部20は、以上のような処理で、特徴量Fの生成を繰り返すことになる。言い換えると、特徴量生成部20は、Start−Timeで指定された時刻から、Time−Windowで指定された間隔ごとに、直近の未処理の期間のログ(特徴量Fとして利用されていない期間のログ)からキー情報に該当するログを特徴量Fとして取得し、各異常検知エンジン部30に供給する。
一般的に、Proxyのログ(ログを構成する各レコード)には、HTTPのステータスコード(例えば、200、404等のコード)、サーバからの転送バイト数、サーバへの転送バイト数、HTTPメソッド名(例えば、GET, POSTなど)、プロトコル名(http, https, sslなど)、サーバのFQDN、サーバから取得するファイルパス、サーバに送信するQuery、リファラー、コンテンツタイプ、User Agent、サーバのIPアドレス、サーバのポート番号、ローカルのIPアドレス、ローカルポート番号、等の項目(カラム)のデータが含まれる。例えば、特徴量生成部20に供給されたキー情報としてIPアドレスと、FQDNが設定されていた場合、特徴量生成部20は、ProxyログL−1(ログ取得範囲情報で定義された期間のログ)から、キー情報のIPアドレス(文字列又は数値)及びFQDNが含まれるログ(ログを構成するレコード)を抽出し、抽出したログを特徴量F−1として異常検知エンジン部30−1に供給することになる。
次に、異常検知エンジン部30の構成について説明する。
異常検知エンジン部30は、特徴量生成部20から供給された特徴量F(例えば、ログの集合体)を分析して、異常の有無や異常の度合いを判断し、その判断結果を出力する。ここでは、各異常検知エンジン部30は、供給された特徴量Fに基づく異常の度合い(例えば、危険性や緊急性等の度合い)を示す値(以下、「異常度」と呼ぶ)を出力するものとして説明する。異常度は、大きな値ほど、異常の度合い(例えば、危険性や緊急性の度合い)が高いことを示すものとする。
異常検知エンジン部30が特徴量Fを用いて異常度を判断するアルゴリズムについては限定されないものである。異常検知エンジン部30は、例えば、特定の値(例えば、特定のイベントやエラー)の出現数や、統計的なはずれ値の出現数に応じて、異常度を判断するようにしてもよい。異常検知エンジン部30は、例えば、特徴量Fから特定のパラメータ(以下、「注目パラメータ」と呼ぶ)に対して統計的な外れ値を検出(統計的な外れ値を有するログのレコードを検出)して、検出した外れ値の数や外れ度合いに応じた値を異常度として出力するようにしてもよい。
例えば、異常検知エンジン部30−1が、ProxyログL−1(条件情報により絞り込まれたログ)に対して、「ローカルIPアドレス」毎の「サーバへの転送バイト数」という注目パラメータの外れ値に基づく異常度を検出するものとする。ここで、説明を簡易とするため、異常検知エンジン部30−1が検出する注目パラメータに関する箱ひげ図(図2参照)を想定する。ここでは、異常検知エンジン部30−1に、予め最大値max1及び最小値min1が設定されているものとする。また、異常検知エンジン部30−1において検出した任意の注目パラメータ値をVとする。
そして、ここでは、異常検知エンジン部30−1は、注目パラメータ値Vが最大値max1より大きな外れ値となる場合や、注目パラメータ値Vが最小値min1より小さい外れ値となる場合、その外れの度合い(max1又はmin1との差分)に応じた異常度を算出するものとする。具体的には、例えば、異常検知エンジン部30−1は、注目パラメータ値Vが外れ値(V>max1又はV<min1)であった場合、注目パラメータ値Vの外れ度合い(max1又はmin1との差分)に比例した値を異常度として算出(異常度に加算)するようにしてもよい。なお、異常検知エンジン部30−1は、注目パラメータ値Vが、「最大値max1よりも大きい分析最大値max2」よりもさらに大きい値だった場合は、注目パラメータ値Vを分析最大値max2(V=max2)であるものとして異常度の算出を行うものとする。また、異常検知エンジン部30−1は、注目パラメータ値Vが「最小値min1よりも小さい分析最小値min2」未満だった場合は、注目パラメータ値Vを分析最小値min2(V=min2)であるものとして異常度の算出を行うものとする。すなわち、異常検知エンジン部30−1は、分析最大値max2及び分析最小値min2を、注目パラメータ値Vの限度(外れ値の限度)として異常度の算出を行う。
そして、ここでは、異常検知エンジン部30−1は、注目パラメータ値Vが最大値max1より大きい外れ値の場合、分析最大値max2の異常度を100とし、分析最大値max2と注目パラメータ値Vの差分(V−max1)に比例した異常度Dを算出するものとする。例えば、異常検知エンジン部30−1は、注目パラメータ値Vが最大値max1より大きい場合、以下の(1)式のように注目パラメータ値Vに対応する異常度Dを算出することができる。
また、ここでは、異常検知エンジン部30−1は、注目パラメータ値Vが最小値min1より小さい外れ値の場合、分析最小値min2の異常度を100とし、分析最小値min2と注目パラメータ値Vの差分(min2−V)に比例した異常度Dを算出するものとする。例えば、異常検知エンジン部30−1は、注目パラメータ値Vが最小値min1小さい場合、以下の(2)式のように注目パラメータ値Vに対応する異常度Dを算出することができる。なお、異常検知エンジン部30−1は、注目パラメータ値Vが外れ値でない場合(最小値min1以上、最大値max1以下の場合)には、異常度を0と判定するようにしてもよい。
D={(V−max1)/(max2−max1)}・100 …(1)
D={(min1−V)/(min1−min2)}・100 …(2)
D={(V−max1)/(max2−max1)}・100 …(1)
D={(min1−V)/(min1−min2)}・100 …(2)
そして、異常検知エンジン部30−1は、特徴量生成部20から供給された特徴量F−1に含まれるログ(Proxy201のログ)において、「ローカルIPアドレス」毎の「サーバへの転送バイト数」(注目パラメータV)を集計し、各注目パラメータV(「ローカルIPアドレス」毎の「サーバへの転送バイト数」)について異常度の有無を検査し、異常度が発生した場合にはその異常度の累積値をカウントして最終的な異常度を検知結果として出力するものとする。例えば、異常検知エンジン部30−1は、特徴量生成部20から供給された特徴量F−1に含まれるログにおいて、4つの注目パラメータV(4つの「ローカルIPアドレス」の「サーバへの転送バイト数」)について異常(異常度Dが0より大きい;注目パラメータ値Vが外れ値)を検出し、その異常度の内訳が10、20、40、20だった場合、その合計値(累積値)である90を検知結果として出力することになる。
なお、以下では、異常検知エンジン部30−iが出力する検知結果を「検知結果R1−i」と表すものとする。例えば、異常検知エンジン部30−1の検知結果は、検知結果R1−1となる。
また、各異常検知エンジン部30において、最大値max1、最小値min1、分析最大値max2及び分析最小値min2については、固定値としてもよいし、オペレータ(例えば、ネットワーク管理者等)により任意の値を変更可能とするようにしてもよい。例えば、各異常検知エンジン部30には、異常が発生していない期間においてProxy201から取得したログにおける最大値及び最小値に基づいて、最大値max1及び最小値min1を設定するようにしてもよいし、異常が発生している期間においてProxy201から取得したログにおける最大値及び最小値に基づいて、分析最大値max2及び分析最小値min2を設定するようにしてもよい。
上記の例では、異常検知エンジン部30−1の注目パラメータを「ローカルIPアドレス」毎の「サーバへの転送バイト数」としたが、各異常検知エンジン部30における注目パラメータをその他のパラメータとしてもよいことは当然である。例えば、異常検知エンジン部30−1の注目パラメータを「ローカルIPアドレス」毎の「サーバへの転送バイト数」とし、異常検知エンジン部30−2の注目パラメータ「User Agent」の出現数とし、異常検知エンジン部30−2の注目パラメータを「サーバに送信するQuery」の長さとする等の組み合わせとしてもよい。
各異常検知エンジン部30は、検知結果Rとして、異常度(以下、「anomaly−degree」と呼ぶ)に、当該異常検知エンジン部30の識別子(以下、「engine−ID」と呼ぶ)、及び条件情報(key,Start−Time,Time−Window)が付加された内容を出力するものとする。以下では、異常検知エンジン部30−1〜30−XのIDをそれぞれ1〜Xと表すものとする。そうすると、異常検知エンジン部30の検知結果Rは、(key,Start−Time,Time−Window,engine−ID,anomaly−degree)という書式で表すことができる。なお、engine−IDには対応する異常検知エンジン部30のID(1〜Xのいずれか)が設定されることになる。例えば、engine−ID=1の異常検知エンジン部30−1から出力される検知結果R−1は、(key,Start−Time,Time−Window,1,anomaly−degree)と表すことができる。
次に、2段目システム2の内部構成について説明する。
2段目システム2は、出力ベクトル部40、最終判定エンジン部50、及び原因ログ出力部60を有している。
出力ベクトル部40は、異常検知エンジン部30−1〜30−Xの検知結果R1−1〜R1−X(1段目システム1の出力結果)をまとめてX次元のベクトル形式に整形したデータ(以下、「特徴量ベクトル」と呼ぶ)R2を生成する。なお、出力ベクトル部40は、特徴量ベクトルR2を対応する条件情報(キー情報)ごとに管理するため、特徴量ベクトルR2に条件情報(キー情報)を付加する。
ここでは、例として、異常検知エンジン部30が出力する検知結果Rに含まれる異常度(検知結果)を、anomaly_degree(engine−ID)と表すものとする。そうすると、異常検知エンジン部30−1が出力する検知結果R−1に含まれる異常度(検知結果)は、例えば、anomaly_degree(1)と表すことができる。この場合、特徴量ベクトルR2は、例えば、「(key,Start−Time,Time−Window,anomaly−degree(1),anomaly−degree(2),…anomaly−degree(X))」と表すことができる。
最終判定エンジン部50は、特徴量ベクトルR2を特徴量として、最終的な異常検知の判定結果(以下、「最終判定結果R3」と呼ぶ)を出力する。
具体的には、最終判定エンジン部50は、特徴量ベクトルR2に対応する具体的な異常の内容(種類)を判定し、その判定結果(以下、「result」とも表す)を最終判定結果R3として出力する。なお、最終判定エンジン部50は、最終判定結果R3として、判定結果(result)に、条件情報「key,Start−Time,Time−Window」を付加した情報を出力するものとする。具体的には、最終判定エンジン部50は、最終判定結果R3として、(key,Start−Time,Time−Window,result)という書式の情報を出力するものとする。
ここでは、説明を簡易とするため、最終判定エンジン部50は、想定される異常(例えば、既知の攻撃状態や異常状態)の種類(内容)として、3種類の異常ab(ab1、ab2、ab3)の項目が設定されており、特徴量ベクトルR2に対応する異常の種類(ab1、ab2、ab3のいずれか)を特定し、最終判定結果R3として出力するものとする。
なお、最終判定エンジン部50で判定対象となる異常abの種類や数は限定されないものである。ここでは、最終判定エンジン部50が出力する最終判定結果R3には、3種類の異常ab1、ab2、ab3に対応するコード(例えば、ab1、ab2、ab3のいずれかのコード)を出力するものとして説明するが、具体的な異常の内容を示す名称(文字列)を出力する等、他の形式としてもよい。
最終判定エンジン部50は、例えば、図3に示すような特徴量ベクトルと正解となる異常の種類の組のリストを教師データ(学習データ)として用いて、特徴量ベクトルR2に応じた異常abを判定する処理を行うようにしてもよい。
図3に示すテーブルでは、3種類の異常ab1、ab2、ab3(正解)に対応する特徴量ベクトルR2(各異常検知エンジン部30の異常度のみ)が図示されている。図3では、1段目システム1に、5つの異常検知エンジン部30−1〜30−5が含まれるとした場合(X=5とした場合)における特徴量ベクトルR2が図示されている。例えば、図3に図示された、異常ab1に対応する特徴量ベクトル(100,0,0,0,10)は、anomaly_degree(1)=100、anomaly_degree(2)=0、anomaly_degree(3)=0、anomaly_degree(4)=0、anomaly_degree(5)=10であることを示している。
最終判定エンジン部50は、例えば、図4に示すような多層のニューラルネットワーク500に相当する演算を行うことで、特徴量ベクトルR2に応じた異常の種類を判定するようにしてもよい。
ニューラルネットワーク500は、例えば図4で示すように5つの入力層のノードNI(NI−1〜NI−5)(anomaly_degree(1)〜anomaly_degree(5)の5つ)、3つの出力層のノードNO(NO−1〜NO−3)(ab1〜ab3の3つ)の構成となっている。また、ニューラルネットワーク500には、入力層と出力層との間に中間層の5ノードNM(NM−1〜NM−5)が配置されている。なお、図4に示したニューラルネットワーク500の層の数及び層に含まれるノード数は限定されないものである。また、ニューラルネットワーク500において、入力層5ノード、出力層3ノードとした場合においても、中間層のノード数は限定されないものである。
図4に示すニューラルネットワーク500では、入力層のノードNI−1〜NI−5に入力される各異常度(特徴量ベクトル)が、中間層のノードNM−1〜NM−5で処理されて、出力層のノードNO−1〜NO−3のそれぞれから各異常の種類(異常ab1〜ab3)に対応する異常を評価する値(以下、「評価値」と呼ぶ)が出力される。
最終判定エンジン部50は、ニューラルネットワーク500の出力層において、最も強く反応した出力層のノードNO(一番大きな評価値を出力する出力層のノードNO)に対応する異常の種類を最終判定結果として出力する。例えば、図4に示すニューラルネットワーク500において、出力層のノードNO−1から出力される値が最も大きい場合、最終判定エンジン部50は、最終判定結果(最終判定結果R3のresult)として、出力層のノードNO−1に対応する異常ab1を出力する。なお、最終判定エンジン部50は、最終判定した異常に対応する評価値が閾値未満だった場合には、異常無を出力するようにしてもよい。
ニューラルネットワーク500においては、中間層のノードNM−1〜NM−5では、図3に示すような教師データに基いてニューラルネットワーク500の入力と出力が対応されるように中間層がそれぞれの入出力パラメータを学習して調整し、教師データにおいて最も特徴量ベクトルR2と近い特徴量ベクトルが設定されている種類の異常(出力層のノードNO)に対して大きな評価値が出力されるように学習がなされているものとする。
すなわち、最終判定エンジン部50では、図3に示すような教師データを蓄積して図4に示すようなニューラルネットワーク500に学習させておき、学習したどの異常の種類(異常の種類に対応する特徴量ベクトル)に近いのかを判定して、判定結果を出力する処理を行う。
例えば、最終判定エンジン部50では、図3に示すような教師データを蓄積して、100、30、15、0、100)という特徴量ベクトルR2が供給されたとき、教師データで学習した異常(教師データにおいて異常に対応する特徴量ベクトル)のいずれと近いのかを判定し、結果として異常ab3を判定結果として出力する。
この実施形態では、最終判定エンジン部50はニューラルネットワークのモデルを用いて教師データを学習させた判断処理を行う例についてしめしたが、ニューラルネットワーク以外のその他の判断処理(例えば、その他の種類の人工知能処理)を適用するようにしてもよい。
以上のように、最終判定エンジン部50は、図3に示すような教師データを用いて学習し、学習内容に従って適切な最終判定結果を出力可能な学習器(例えば、図4に示すようなニューラルネットワーク500)を備えるようにしてもよい。なお、最終判定エンジン部50に適用する学習器(学習器のモデル)としては、図4に示すようなニューラルネットワーク500に限定されず、その他の処理構成(例えば、種々の人工知能(AI)の処理等)を適用することができる。
原因ログ出力部60は、最終判定エンジン部50で、所定の条件に該当する処理が行われた場合、当該所定の条件に該当する判定結果に関する情報(例えば、当該判定結果に対応する条件情報や特徴量F)を保持(記録)し、オペレータ(例えば、ネットワーク管理者等)の操作に応じて保持した情報を出力する。なお、原因ログ出力部60による出力形式は限定されないものである。原因ログ出力部60は、例えば、オペレータの操作(例えば、コマンドラインやGUIによる操作)に応じて、保持している情報をファイル(1又は複数のファイル)として所定の場所(例えば、図示しないハードディスクやネットワークドライブ上の所定のフォルダ等)に出力するようにしてもよい。
原因ログ出力部60で、最終判定エンジン部50の判定結果に関する情報を保持する条件については限定されないものであるが、例えば、判定処理の過程で、最も高い評価値が複数発生した場合、又は、最も高い評価値と差分が10%以下の差異しかない他の評価値を存在する場合等を条件としてもよい。
例えば、最終判定エンジン部50が、図3のような教師データを前提として最終判定を行う場合を想定する。この場合、最終判定エンジン部50において、異常ab1、ab2、ab3の評価値がそれぞれ「99、0、1」といった場合には、最終判定結果を異常abとすることには問題ないが、異常ab1、ab2、ab3の評価値がそれぞれ「30、28、32」となる場合には、最も高い異常ab1の評価値「30」に対して、差分が10%以下の評価値が2つ発生しているため、単純に評価値に基づいて異常ab1を最終判定結果とすることは望ましくない。したがって、原因ログ出力部60で判定結果に関する情報を保持した場合(所定の条件に該当した場合)には、最終判定エンジン部50は、その所定の条件に該当する判定結果を出力しない(例えば、異常無や判定不能等の結果を出力)するようにしてもよい。
すなわち、2段目システム2では、最終判定エンジン部50において判別の確度が低い結果に関しては出力せずに、原因ログ出力部60にプールし、後にオペレータの操作により、最終判定エンジン部50に適用する教師データ(学習データ)を追加するフィードバック処理を受け付けるようにしてもよい。
(A−2)実施形態の動作
次に、以上のような構成を有するこの実施形態の異常検知装置1000の動作(実施形態に係る通信解析方法)について説明する。
次に、以上のような構成を有するこの実施形態の異常検知装置1000の動作(実施形態に係る通信解析方法)について説明する。
図5は、異常検知装置1000の全体の動作について示したフローチャートである。
まず、特徴量生成部20に異常検知の条件情報(key,Start−Time,Time−Window)が供給されたものとする(S101)。
次に、特徴量生成部20は、条件情報に基づき、異常検知エンジン部30ごとに対応するログをデータプール部10から取得し、取得したログを特徴量Fとして生成し(S102)、生成した特徴量Fをそれぞれの異常検知エンジン部30に供給する(S103)。
それぞれの異常検知エンジン部30が、供給された特徴量Fに対応する異常度を算出し、検知結果R(key,Start−Time,Time−Window,engine−ID,anomaly−degree)を出力する(S104)。
出力ベクトル部40が、各異常検知エンジン部30の出力(1段目システム1の出力)を集計し、条件情報ごとの検知結果を整形して特徴量ベクトルR2(key,Start−Time,Time−Window,anomaly−degree(1),anomaly−degree(2),…anomaly−degree(X))を生成する(S105)。出力ベクトル部40は、全ての異常検知エンジン部30からの検知結果R1の出力がなされるか、タイムアウトとなった場合(例えば、特徴量生成部20から各異常検知エンジン部30に特徴量Fが供給されてから所定のタイムアウト時間が経過した場合)に、その時点で取得した検知結果R1を用いて特徴量ベクトルR2を生成する。
次に、最終判定エンジン部50が、特徴量ベクトルR2(条件情報等の付加情報を除いた情報)に基づき、各異常(例えば、異常ab1〜ab3)に対する評価値を算出し、算出した評価値に基づく判定結果(例えば、異常ab1〜ab3又は異常無)を最終判定結果R3として出力する(S107)。
以上のように、異常検知装置1000は、最終判定結果R3を出力する処理を行う。
次に、異常検知装置1000(最終判定エンジン部50)に新たな教師データ(学習データ)をインプットする方式(学習のバリエーション)の例について説明する。なお、異常検知装置1000(最終判定エンジン部50)に新たな教師データ(学習データ)をインプットする方式については、以下の例に限定されないものである。
例えば、特徴量生成部20では、条件情報に正解となる判定結果(result)を付加した教師データに相当する情報(以下、「学習指示条件情報」とも呼ぶ)を受け付けることで、教師データのインプットを受け付けるようにしてもよい。
この場合、学習指示条件情報は、「(Key、Start−time、Time−Window、result)」という書式で表すことができる。
特徴量生成部20は、学習指示条件情報(条件情報に判定結果(result)が付加された情報)が供給されると、異常検知の処理と同様に、各異常検知エンジン部30に対して、条件情報(学習指示条件情報に含まれる条件情報)に該当する特徴量Fを生成する。そして、特徴量生成部20は、各異常検知エンジン部30に対して、特徴量Fに条件情報及び学習指示条件情報の判定結果(result)を付加した情報(以下、「学習指示特徴量」と呼ぶ)を生成して供給する。
各異常検知エンジン部30は、学習指示特徴量(特徴量Fに条件情報及びresultが付加された情報)が供給されると、異常検知の処理と同様に異常度を算出し、異常度に判定結果(result)及び条件情報を付加した情報(以下、「学習指示検知結果」と呼ぶ)を出力ベクトル部40に供給する。
出力ベクトル部40は、学習指示検知結果(特徴量Fに条件情報及びresultが付加された情報)が供給されると、条件情報ごとの学習指示検知結果を集計した結果の情報(以下、「学習指示ベクトル」と呼ぶ)を整形して最終判定エンジン部50に供給する。学習指示ベクトルには、条件情報(Key,Start−Time,Time−Window)、判定結果(result)、及び特徴量ベクトル(anomaly−degree(1),anomaly−degree(2),…anomaly−degree(X))が含まれる。
この場合、学習指示ベクトルは、「(Key,Start−Time,Time−Window,Result,anomaly−degree(1),anomaly−degree(2),…anomaly−degree(X))」という書式で表すことができる。
最終判定エンジン部50は、学習指示ベクトル(条件情報、判定結果、及び特徴量ベクトルが含まれた情報)が供給されると、当該学習指示ベクトルに含まれる判定結果と特徴量ベクトルを対とした教師データ(学習データ)を追加して再学習する処理を行う。最終判定エンジン部50には、過去に供給された学習指示ベクトル(又は、学習指示ベクトルに基づく教師データ)を保持しておき、新たに学習指示ベクトルが供給される度に再学習する処理を行うようにしてもよい。
異常検知装置1000では、例えば、オペレータに、原因ログ出力部60で保持された情報に基づいて学習指示条件情報を編集(例えば、テキストエディタ等のエディタや専用のGUI上で編集)させ、学習指示条件情報に入力させることができる。
なお、異常検知装置1000における学習処理の方式は上記の例に限定されないものである。例えば、最終判定エンジン部50が、直接オペレータから学習指示ベクトルの入力を受け付けるようにしてもよい。
(A−3)実施形態の効果
この実施形態によれば、以下のような効果を奏することができる。
この実施形態によれば、以下のような効果を奏することができる。
この実施形態の異常検知装置1000では、1段目システム1(特徴量生成部20)に解析のキーとなる条件情報(キー情報を含む情報)に基づいて、それぞれの異常検知エンジン部30で異常検知の対象となるログを含む特徴量Fを生成している。これにより、複数の異常検知エンジン部30の検知結果R1をIPアドレス以外の数値パラメータ(例えば、異常度)で出力させることができる。
また、この実施形態の異常検知装置1000では、2段目システム2の最終判定エンジン部50で、異常検知エンジン部30の検知結果R1を集計した特徴量ベクトルR2に基づき、ネットワークN上の異常の有無だけでなく、異常の内容の(例えば、攻撃なのか障害なのか等)の判定を行うことができる。最終判定エンジン部50では、過去の実績等に基づく教師データ(学習データ)で学習させた学習器(例えば、ニューラルネットワーク)を用いることで、特徴量ベクトルR2に対応する異常の内容を特定することができる。また、最終判定エンジン部50では、学習器に学習させる教師データを増やすことによって、異常の内容のさらに詳細の判定(例えば、攻撃なのか障害なのかだけではなく、攻撃の種別までの判定)を行うことができる。
さらに、異常検知装置1000では、オペレータに原因ログ出力部60に情報が保持された情報を提示することにより、オペレータに未知の事象(例えば、攻撃・異常など)の存在を認識させることができる。これにより、異常検知装置1000では、オペレータに対して、最終判定エンジン部50に学習させる教師データの更新(新たな教師データを追加)を支援することができる。
(B)他の実施形態
本発明は、上記の実施形態に限定されるものではなく、以下に例示するような変形実施形態も挙げることができる。
本発明は、上記の実施形態に限定されるものではなく、以下に例示するような変形実施形態も挙げることができる。
(B−1)上記の実施形態では、本発明の通信解析装置を異常検知装置に適用する例について説明したが、リアルタイムに繰り返し最終判定エンジン部50による最終判定処理を行って最終判定結果R3を出力する監視装置として構成するようにしてもよい。
1000…異常検知装置、1…1段目システム、20…特徴量生成部、30、30−1〜30−X…異常検知エンジン部、2…2段目システム、40…出力ベクトル部、50…最終判定エンジン部、60…原因ログ出力部、N…ネットワーク、10…データプール部、F、F−1〜F−X…特徴量、R1、R1−1〜R1−X…検知結果、R2…特徴量ベクトル、R3…最終判定結果、NI、NI−1〜NI−5…入力層のノード、NM、NM−1〜NM−5…中間層のノード、NO、NO−1〜NO−3…出力層のノード、201…Proxy、202…IDS、203…Mailサーバ、204…FW、L−1…Proxyログ、L−2…IDSログ、L−3…Mailログ、L−4…FWログ。
Claims (10)
- ネットワーク上に配置されたネットワーク装置で発生した情報から、前記ネットワークの異常の度合を検知する複数の異常検知手段と、
それぞれの前記異常検知手段について、前記ネットワーク装置で発生した情報から、異常検知の対象となる条件情報に該当する情報を抽出し、抽出した情報に基づいて、それぞれの前記異常検知手段に供給する特徴量を生成する特徴量生成手段と、
それぞれの前記異常検知手段が、前記特徴量生成手段が生成した特徴量に基づいて検知した検知結果を、条件情報ごとに集計し、条件情報ごとの検知結果を含む情報をそれぞれ出力ベクトルとして生成する出力ベクトル生成手段と、
出力ベクトル生成手段が生成した前記出力ベクトルに基づき、前記ネットワークで発生した異常の内容を最終的に判定する最終判定処理を行う最終判定手段と
を有することを特徴とする通信解析装置。 - 前記最終判定手段は、異常の内容と当該異常に対応する前記出力ベクトルの組を複数含む教師データを利用して、前記最終判定処理を行うことを特徴とする請求項1に記載の通信解析装置。
- 前記最終判定手段は、前記教師データを用いて学習させた学習器を用いて、前記最終判定処理を行うことを特徴とする請求項2に記載の通信解析装置。
- 前記特徴量生成手段は、1以上の前記ネットワーク装置で発生したログを蓄積するデータプール手段から、それぞれの前記異常検知手段に対して、それぞれの前記異常検知手段で検知対象となる前記ネットワーク装置のログで、かつ、前記条件情報に該当するログを抽出して、それぞれの前記異常検知手段に供給する特徴量を生成することを特徴とする請求項1〜3のいずれかに記載の通信解析装置。
- 前記条件情報には、前記データプール手段で保持しているログを特定するキー情報が含まれることを特徴とする請求項4に記載の通信解析装置。
- 前記キー情報には、IPアドレス、FQDN、又はユーザIDのうち少なくとも1つが含まれていることを特徴とする請求項5に記載の通信解析装置。
- 前記条件情報には、前記データプール手段で保持しているログの時間的範囲を特定するログ取得範囲情報が含まれていることを特徴とする請求項5又は6に記載の通信解析装置。
- 前記最終判定手段で、所定の条件に該当する判定処理が行われた場合、当該判定処理に関する情報を保持して、出力することが可能な原因出力手段をさらに有することを特徴とする請求項1〜7のいずれかに記載の通信解析装置。
- コンピュータを、
ネットワーク上に配置されたネットワーク装置で発生した情報から、前記ネットワークの異常の度合を検知する複数の異常検知手段と、
それぞれの前記異常検知手段について、前記ネットワーク装置で発生した情報から、異常検知の対象となる条件情報に該当する情報を抽出し、抽出した情報に基づいて、それぞれの前記異常検知手段に供給する特徴量を生成する特徴量生成手段と、
それぞれの前記異常検知手段が、前記特徴量生成手段が生成した特徴量に基づいて検知した検知結果を、条件情報ごとに集計し、条件情報ごとの検知結果を含む情報をそれぞれ出力ベクトルとして生成する出力ベクトル生成手段と、
出力ベクトル生成手段が生成した前記出力ベクトルに基づき、前記ネットワークで発生した異常の内容を最終的に判定する最終判定処理を行う最終判定手段と
として機能させることを特徴とする異常検知プログラム。 - 通信解析装置が行う異常検知方法において、
前記通信解析装置は、複数の異常検知手段、特徴量生成手段、出力ベクトル生成手段、及び最終判定手段を備え、
それぞれの前記異常検知手段は、前記ネットワークに配置されたネットワーク装置で発生した情報から、前記ネットワークの異常の度合を検知し、
前記特徴量生成手段は、それぞれの前記異常検知手段について、前記ネットワーク装置で発生した情報から、異常検知の対象となる条件情報に該当する情報を抽出し、抽出した情報に基づいて、それぞれの前記異常検知手段に供給する特徴量を生成し、
前記出力ベクトル生成手段は、それぞれの前記異常検知手段が、前記特徴量生成手段が生成した特徴量に基づいて検知した検知結果を、条件情報ごとに集計し、条件情報ごとの検知結果を含む情報をそれぞれ出力ベクトルとして生成し、
前記最終判定手段は、前記出力ベクトル生成手段が生成した前記出力ベクトルに基づき、前記ネットワークで発生した異常の内容を最終的に判定する最終判定処理を行う
ことを特徴とする異常検知方法。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2017157585A JP2019036865A (ja) | 2017-08-17 | 2017-08-17 | 通信解析装置、通信解析プログラム、及び通信解析方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2017157585A JP2019036865A (ja) | 2017-08-17 | 2017-08-17 | 通信解析装置、通信解析プログラム、及び通信解析方法 |
Publications (1)
Publication Number | Publication Date |
---|---|
JP2019036865A true JP2019036865A (ja) | 2019-03-07 |
Family
ID=65635990
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2017157585A Pending JP2019036865A (ja) | 2017-08-17 | 2017-08-17 | 通信解析装置、通信解析プログラム、及び通信解析方法 |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP2019036865A (ja) |
Cited By (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JPWO2020195626A1 (ja) * | 2019-03-26 | 2020-10-01 | ||
JP2020170350A (ja) * | 2019-04-03 | 2020-10-15 | 沖電気工業株式会社 | 異常判定学習器、異常判定学習プログラム、異常判定学習方法、及び異常判定システム |
WO2021048902A1 (ja) * | 2019-09-09 | 2021-03-18 | 楽天株式会社 | 学習モデル適用システム、学習モデル適用方法、及びプログラム |
JP2022519868A (ja) * | 2019-03-28 | 2022-03-25 | コンティ テミック マイクロエレクトロニック ゲゼルシャフト ミット ベシュレンクテル ハフツング | 敵対的攻撃の自動認識及び分類 |
-
2017
- 2017-08-17 JP JP2017157585A patent/JP2019036865A/ja active Pending
Cited By (9)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JPWO2020195626A1 (ja) * | 2019-03-26 | 2020-10-01 | ||
WO2020195626A1 (ja) * | 2019-03-26 | 2020-10-01 | 日本電気株式会社 | 異常検知方法、異常検知装置、プログラム |
JP7248103B2 (ja) | 2019-03-26 | 2023-03-29 | 日本電気株式会社 | 異常検知方法、異常検知装置、プログラム |
JP2022519868A (ja) * | 2019-03-28 | 2022-03-25 | コンティ テミック マイクロエレクトロニック ゲゼルシャフト ミット ベシュレンクテル ハフツング | 敵対的攻撃の自動認識及び分類 |
JP7248807B2 (ja) | 2019-03-28 | 2023-03-29 | コンティ テミック マイクロエレクトロニック ゲゼルシャフト ミット ベシュレンクテル ハフツング | 敵対的攻撃の自動認識及び分類 |
JP2020170350A (ja) * | 2019-04-03 | 2020-10-15 | 沖電気工業株式会社 | 異常判定学習器、異常判定学習プログラム、異常判定学習方法、及び異常判定システム |
JP7331421B2 (ja) | 2019-04-03 | 2023-08-23 | 沖電気工業株式会社 | 異常判定学習器、異常判定学習プログラム、異常判定学習方法、及び異常判定システム |
WO2021048902A1 (ja) * | 2019-09-09 | 2021-03-18 | 楽天株式会社 | 学習モデル適用システム、学習モデル適用方法、及びプログラム |
JPWO2021048902A1 (ja) * | 2019-09-09 | 2021-09-27 | 楽天グループ株式会社 | 学習モデル適用システム、学習モデル適用方法、及びプログラム |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
Shen et al. | {ATTACK2VEC}: Leveraging temporal word embeddings to understand the evolution of cyberattacks | |
Wang et al. | Machine learning in network anomaly detection: A survey | |
US20220224716A1 (en) | User agent inference and active endpoint fingerprinting for encrypted connections | |
JP2023169334A (ja) | 機械学習モデルを用いてeメールネットワークを保護するサイバー脅威防御システム | |
Gupta et al. | Layered approach using conditional random fields for intrusion detection | |
CN111131137B (zh) | 可疑封包检测装置及其可疑封包检测方法 | |
JP2019061565A (ja) | 異常診断方法および異常診断装置 | |
JP2019036865A (ja) | 通信解析装置、通信解析プログラム、及び通信解析方法 | |
JP6557774B2 (ja) | プロセストレースを用いたグラフベースの侵入検知 | |
Ficco et al. | A generic intrusion detection and diagnoser system based on complex event processing | |
CN111510339B (zh) | 一种工业互联网数据监测方法和装置 | |
JP6280862B2 (ja) | イベント分析システムおよび方法 | |
US20240089278A1 (en) | Anomalous network behaviour identification | |
Turchin et al. | Tuning complex event processing rules using the prediction-correction paradigm | |
Fallah et al. | Android malware detection using network traffic based on sequential deep learning models | |
Alserhani | Alert correlation and aggregation techniques for reduction of security alerts and detection of multistage attack | |
Yu Beng et al. | A survey of intrusion alert correlation and its design considerations | |
JP6711452B2 (ja) | 抽出装置、抽出方法、及びプログラム | |
Kamarudin et al. | A new unified intrusion anomaly detection in identifying unseen web attacks | |
Aparicio-Navarro et al. | Addressing multi-stage attacks using expert knowledge and contextual information | |
Sallay et al. | Intrusion detection alert management for high‐speed networks: current researches and applications | |
JP7009907B2 (ja) | 通信解析装置、通信解析プログラム、及び通信解析方法 | |
Kapourniotis et al. | Scam and fraud detection in VoIP Networks: Analysis and countermeasures using user profiling | |
CN116155519A (zh) | 威胁告警信息处理方法、装置、计算机设备和存储介质 | |
Dik et al. | Web attacks detection based on patterns of sessions |