JP7200496B2 - 情報処理装置、制御方法、及びプログラム - Google Patents

Description

本発明はコンピュータシステムの監視に関する。

セキュリティの観点からコンピュータシステムを監視するシステムが開発されている。例えば特許文献１は、情報端末装置におけるファイルの実行を制御するシステムを開示している。サーバは、ウイルスチェックによってウイルスが存在しないことを確認したファイルを示すマスタファイルリストを作成する。情報端末装置は、取得したファイルがマスタファイルリストに含まれていない場合、ブラックリストに基づいてそのファイルのウイルスチェックを行う。

その他にも例えば、非特許文献１は、システムの過去の動作に基づいてシステムの正常な動作をモデル化した正常データを生成し、正常動作データとの照合によってシステムの異常を検出することで、バッファオーバーフローなどの攻撃を回避するシステムを開示している。ここで、非特許文献１のシステムは、訓練モードで動作させたアプリケーションが発行したシステムコールを利用して、システムの正常な動作を表す正常動作データを作成する。

特開２０１４－１３７６６１号公報

大山恵弘、外２名、「異常検知システムにおける正常動作データのモジュール化」、情報処理学会、情報処理学会論文誌コンピューティングシステム（ACS）、vol.44、no.10、pp.36-47、2003年7月 S. Ahmad、外３名、「Unsupervised real-time anomaly detection for streaming data」、Neurocomputing、vol. 262、pp. 134-147、2017年

コンピュータシステムの振る舞いの中には、正常なものであるか否かをすぐには判断できないものがある。特許文献１に開示されている手法は、ウイルスチェックでファイルが正常であるか否かを判断するものであるため、このように正常か否かをすぐには判断できないコンピュータシステムの振る舞いの監視に利用することは難しい。

また、コンピュータシステムの振る舞いは、コンピュータシステムの運用環境によって変化しうる。そのため、非特許文献１に開示されている手法では、運用時のシステムの環境が訓練モードにおけるシステムの環境から変化した場合に、異常を検知できなくなるおそれがある。

本発明は、上記の課題に鑑みてなされたものである。本発明の目的の一つは、コンピュータシステムの振る舞いの監視を精度よく行う技術を提供することである。

本発明の第１の情報処理装置は、１）イベントを表す監視データを取得し、イベントが警告対象であるか否かを判定する判定モデルを用いて、取得した監視データによって表されるイベントが警告対象であるか否かを判定する判定部と、２）判定モデルを用いた判定結果であってイベントが警告対象であるか否かの判定結果、および、監視データが表すイベントが所定の条件を満たすか否かの判定結果に基づいて、判定モデルの更新を行う更新部と、を有する。

本発明の第２の情報処理装置は、１）イベントを表す監視データを取得し、イベントが警告対象であるか否かを判定する判定モデルを用いて、取得した監視データによって表されるイベントが警告対象であるか否かを判定する判定部と、２）監視データを用いて判定モデルの更新を行う更新部と、３）更新部による判定モデルの更新の後、当該判定モデルを用いた判定結果であってイベントが警告対象であるか否かの判定結果、および、監視データが表すイベントが所定の条件を満たすか否かの判定の結果に基づいて、その監視データに基づいて更新された判定モデルを修正する修正部と、を有する。

本発明の第１の制御方法は、コンピュータによって実行される。当該制御方法は、１）イベントを表す監視データを取得し、イベントが警告対象であるか否かを判定する判定モデルを用いて、取得した監視データによって表されるイベントが警告対象であるか否かを判定する判定ステップと、２）判定モデルを用いた判定結果であってイベントが警告対象であるか否かの判定結果、および、監視データが表すイベントが所定の条件を満たすか否かの判定結果に基づいて、判定モデルの更新を行う更新ステップと、を有する。

本発明の第２の制御方法は、コンピュータによって実行される。当該制御方法は、１）イベントを表す監視データを取得し、イベントが警告対象であるか否かを判定する判定モデルを用いて、取得した監視データによって表されるイベントが警告対象であるか否かを判定する判定ステップと、３）監視データを用いて判定モデルの更新を行う更新ステップと、４）更新ステップによる判定モデルの更新の後、当該判定モデルを用いた判定結果であってイベントが警告対象であるか否かの判定結果、および、監視データが表すイベントが所定の条件を満たすか否かの判定の結果に基づいて、その監視データに基づいて更新された判定モデルを修正する修正ステップと、を有する。

本発明のプログラムは、本発明の制御方法が有する各ステップをコンピュータに実行させる。

本発明によれば、コンピュータシステムの振る舞いの監視を精度よく行う技術が提供される。

実施形態１の情報処理装置の動作の概要を表す図である。 実施形態１の情報処理装置の構成を例示する図である。 情報処理装置を実現するための計算機を例示する図である。 実施形態１の情報処理装置によって実行される処理の流れを例示するフローチャートである。 監視データが示す情報をテーブル形式で例示する図である。 更新方法の例１の流れを例示するフローチャートである。 更新方法の例２の流れを例示するフローチャートである。 実施形態２の情報処理装置の動作の概要を表す図である。 実施形態２の情報処理装置の機能構成を例示する図である。 実施形態２の情報処理装置が判定モデルを更新する流れを例示する図である。

以下、本発明の実施の形態について、図面を用いて説明する。尚、すべての図面において、同様な構成要素には同様の符号を付し、適宜説明を省略する。また、特に説明する場合を除き、各ブロック図において、各ブロックは、ハードウエア単位の構成ではなく、機能単位の構成を表している。

［実施形態１］
＜概要＞
図１は、実施形態１の情報処理装置の動作の概要を表す図である。図１は情報処理装置２０００の動作についての理解を容易にするための概念的な図であり、情報処理装置２０００の動作を具体的に限定するものではない。

情報処理装置２０００は、監視対象システム１０において発生したイベントが警告対象のイベントであるか否かを判定する。この判定は、判定モデル２０を用いて行われる。さらに情報処理装置２０００は、判定モデル２０の更新を行う。

ここでいう「イベント」は、監視対象システム１０の振る舞いを表す。監視対象システム１０の振る舞いには、例えば、監視対象システム１０におけるプロセスの振る舞いや、監視対象システム１０に対する外部からの入力などが含まれる。「プロセス」とは、実行中のプログラムのことである。すなわち、「プロセスの振る舞い」とは、プロセスが何らかの客体（他のプロセス、ファイル、出力デバイスなど）に対して行った活動である。例えば或るプロセスが発生させるイベントは、他のプロセスの起動、他のプロセスとの通信、ファイルへのアクセス、ネットワークインタフェースへのデータの出力（外部の装置へのデータ送信）などである。監視対象システム１０に対する外部からの入力は、例えば、キーボードを使った文字入力（例えば、シェルに対するコマンド入力）やネットワークインタフェースからのデータの入力（外部の装置からのデータの受信）などである。

警告対象のイベントとしては、種々のイベントを採用できる。例えば警告対象のイベントは、サイバー攻撃に関連する蓋然性が高いイベントなど、セキュリティ面での危険度が高いと推測されるイベントである。

監視対象システム１０は、監視対象となる１つ以上の装置で構成されるコンピュータシステムである。監視対象システム１０を構成する各装置を、監視対象装置１２と呼ぶ。監視対象システム１０におけるイベントは、監視対象装置１２で動作するプロセスの振る舞いや、監視対象装置１２に対する外部からの入力を表すとも言える。なお、監視対象装置１２は、物理マシンであってもよいし、仮想マシンであってもよい。

まず情報処理装置２０００は、監視データ３０を取得する。監視データ３０は、監視対象システム１０で発生したイベントを表すデータである。情報処理装置２０００は、監視データ３０によって表されるイベントが、警告対象のイベントであるか否かを判定する。前述したように、この判定は判定モデル２０を利用して行われる。例えば判定モデル２０は、監視データ３０を入力として取得し、その監視データ３０によって表されるイベントが警告対象であるか否かを示す情報を出力する識別器である。

さらに情報処理装置２０００は、監視データ３０、及び判定モデル２０を用いた監視データ３０についての判定の結果に基づいて、判定モデル２０を更新する。

＜作用効果＞
コンピュータシステムで発生するイベントの中には、そのイベントが一度発生しただけでは、そのイベントが正常なものであるか否かを判断することが難しいものがある。そのため、コンピュータシステムで発生するイベントを継続的に監視していくことが好適である。

そこで本実施形態の情報処理装置２０００では、監視対象システム１０で発生するイベントが警告対象であるか否かの判定する判定モデル２０を用意し、この判定モデル２０を繰り返し更新していく。このように監視対象システム１０において発生するイベントについて繰り返し学習していくことで、各イベントを警告対象とすべきかどうかを精度良く判定することができるようになる。

また、監視対象システム１０の運用環境が変わる場合（例えば、会社における組織変更など）、発生するイベントの傾向が変化するため、各イベントが正常であるかどうかについても変化することになる。本実施形態の情報処理装置２０００によれば、このように監視対象システム１０の運用環境が変化した場合であっても、その変化に応じて判定モデル２０が更新されていく。そのため、例えば会社において組織替えが行われたりしてシステムの運用環境が変わったとしても、各イベントを警告対象とすべきかどうかを精度良く判定することができる。

ここで、非特許文献２には、時系列の入力データをリアルタイムで解析して異常検知を行うシステムにおいて、システムが継続的に学習を行っていくという技術が開示されている。この点、本発明者は、情報処理装置２０００において、単に入力される監視データ３０の内容のみに基づいて判定モデル２０を継続的に更新していくだけでは、警告対象であり続けるべきイベントが警告対象でなくなってしまう恐れがあることを見出した。例えば後述するように、監視対象システム１０において発生する回数や頻度が比較的少ないイベントが警告対象であると判定するように判定モデル２０を構成すると、警告対象であり続けるべきイベント（例えば、マルウエアに関連するイベント）が繰り返し発生した場合に、そのイベントが警告対象とならなくなってしまう。

そこで本実施形態の情報処理装置２０００では、判定モデル２０の更新が、監視データ３０の内容だけでなく、監視データ３０について情報処理装置２０００が行った判定の結果（監視データ３０よって表されるイベントが警告対象であるか否か）も考慮して行われる。このように、どのようなイベントが発生したかだけでなく、そのイベントが情報処理装置２０００によってどのように判定されたかを考慮することにより、警告対象であり続けるべきイベントを警告対象にし続けることができるため、判定モデル２０の更新をより精度良く行うことができるようになる。

以下、本実施形態の情報処理装置２０００についてさらに詳細に説明する。

＜情報処理装置２０００の機能構成の例＞
図２は、実施形態１の情報処理装置２０００の構成を例示する図である。情報処理装置２０００は、判定部２０２０及び更新部２０４０を有する。判定部２０２０は、監視データ３０を取得し、判定モデル２０を用いて、監視データ３０によって表されるイベントが警告対象のイベントであるか否かを判定する。更新部２０４０は、監視データ３０及びその監視データ３０についての判定部２０２０による判定の結果に基づいて、判定モデル２０の更新を行う。

＜情報処理装置２０００のハードウエア構成＞
情報処理装置２０００の各機能構成部は、各機能構成部を実現するハードウエア（例：ハードワイヤードされた電子回路など）で実現されてもよいし、ハードウエアとソフトウエアとの組み合わせ（例：電子回路とそれを制御するプログラムの組み合わせなど）で実現されてもよい。以下、情報処理装置２０００の各機能構成部がハードウエアとソフトウエアとの組み合わせで実現される場合について、さらに説明する。

図３は、情報処理装置２０００を実現するための計算機１０００を例示する図である。計算機１０００は任意の計算機である。例えば計算機１０００は、Personal Computer（PC）、サーバマシン、タブレット端末、又はスマートフォンなどである。計算機１０００は、情報処理装置２０００を実現するために設計された専用の計算機であってもよいし、汎用の計算機であってもよい。

計算機１０００は、バス１０２０、プロセッサ１０４０、メモリ１０６０、ストレージデバイス１０８０、入出力インタフェース１１００、及びネットワークインタフェース１１２０を有する。バス１０２０は、プロセッサ１０４０、メモリ１０６０、ストレージデバイス１０８０、入出力インタフェース１１００、及びネットワークインタフェース１１２０が、相互にデータを送受信するためのデータ伝送路である。ただし、プロセッサ１０４０などを互いに接続する方法は、バス接続に限定されない。プロセッサ１０４０は、CPU（Central Processing Unit）、GPU（Graphics Processing Unit）、又は FPGA（Field-Programmable Gate Array）などのプロセッサである。メモリ１０６０は、RAM（Random Access Memory）などを用いて実現される主記憶装置である。ストレージデバイス１０８０は、ハードディスクドライブ、SSD（Solid State Drive）、メモリカード、又は ROM（Read Only Memory）などを用いて実現される補助記憶装置である。ただし、ストレージデバイス１０８０は、RAM など、主記憶装置を構成するハードウエアと同様のハードウエアで構成されてもよい。

入出力インタフェース１１００は、計算機１０００と入出力デバイスとを接続するためのインタフェースである。ネットワークインタフェース１１２０は、計算機１０００を通信網に接続するためのインタフェースである。この通信網は、例えば LAN（Local Area Network）や WAN（Wide Area Network）である。ネットワークインタフェース１１２０が通信網に接続する方法は、無線接続であってもよいし、有線接続であってもよい。

ストレージデバイス１０８０は、情報処理装置２０００の機能構成部を実現するプログラムモジュールを記憶している。プロセッサ１０４０は、これら各プログラムモジュールをメモリ１０６０に読み出して実行することで、各プログラムモジュールに対応する機能を実現する。

＜監視対象システム１０について＞
監視対象システム１０は、１つ以上のコンピュータで構成されるコンピュータシステムである。監視対象システム１０を構成するコンピュータは、PC、サーバマシン、タブレット端末、又はスマートフォンなどといった任意のコンピュータである。

＜処理の流れ＞
図４は、実施形態１の情報処理装置２０００によって実行される処理の流れを例示するフローチャートである。判定部２０２０は、監視データ３０を取得する（Ｓ１０２）。更新部２０４０は、判定モデル２０を用いて、監視データ３０によって表されるイベントが警告対象のイベントであるか否かを判定する（Ｓ１０４）。更新部２０４０は、監視データ３０及びその監視データ３０についての判定部２０２０による判定の結果に基づいて、判定モデル２０を更新する（Ｓ１０６）。

＜監視データ３０について＞
監視データ３０は、イベントを表す情報を示す。前述したように、イベントとは、監視対象システム１０の振る舞い（プロセスの振る舞いや外部からの入力）である。なお、プロセスの振る舞いについて、或るプロセスが他のプロセスを客体として活動する場合、これらのプロセスは互いに同一の OS（Operating System）上で動作するものであってもよいし、互いに異なる OS 上で動作するものであってもよい。後者の例としては、例えば、ソケットインタフェースを利用することで、或るプロセスが他の OS 上で動作する別のプロセスと通信を行うことが考えられる。ただし、他の OS 上で動作するプロセスを客体とした振る舞いは、出力デバイス（例えばネットワークインタフェース）に対する出力として表されてもよい。

例えばイベントは、主体、客体、及び活動内容という３つの要素を表す情報によって識別される。そこで監視データ３０は、イベントの主体を表す主体情報、イベントの客体を表す客体情報、及び活動内を表す内容情報の組み合わせを示すことで、イベントを表す。

主体情報は、例えば、そのイベントを発生させたプロセスや入力デバイスを識別する情報である。以下、プロセスを識別する情報をプロセス識別情報と呼び、デバイスを識別する情報をデバイス識別情報と呼ぶ。プロセス識別情報は、例えば、プロセスの名称を示す。その他にも例えば、プロセス識別情報は、プロセスに対応するプログラムの実行ファイルの名称やパス、又はプロセス ID（identifier）などである。デバイス情報は、例えば、OS がデバイスに割り当てた識別子を表す。

客体情報は、例えば、その客体の種別及び識別情報である。客体の種別は、例えば、プロセス、ファイル、出力デバイス、又は他の監視対象装置１２などである。客体がプロセスである場合、客体情報にはそのプロセスのプロセス識別情報が含まれる。

客体がファイルである場合、客体情報には、そのファイルを識別する情報（以下、ファイル識別情報）が含まれる。ファイル識別情報は、例えばそのファイルの名称やパスなどである。また、客体がファイルである場合、客体情報にはそのファイルのハッシュ値が含まれていてもよい。

客体が出力デバイスである場合、客体情報には、そのデバイスのデバイス識別情報が含まれる。

客体が他の監視対象装置１２である場合、例えば客体情報には、当該他の監視対象装置１２の識別情報が含まれる。監視対象装置１２の識別情報は、例えば、IP（Internet Protocol）や MAC（Media Access Control）アドレスなどのネットワークアドレスである。なお、客体が他の監視対象装置１２である場合、客体情報には、監視対象装置１２の識別情報と共に、又は監視対象装置１２の識別情報に代えて、客体の数（すなわち、イベントの主体であるプロセスが通信を行った他の監視対象装置１２の数）が示されてもよい。

内容情報は、例えば、種々ある活動内容に予め割り当てておいた識別子である。例えば、「プロセスを起動する」、「プロセスを停止する」、「ファイルをオープンする」、「ファイルからデータを読み込む」、「ファイルにデータを書き込む」、「ソケットをオープンする」、「ソケットからデータを読み込む」、又は「ソケットにデータを書き込む」などといった活動の内容に、互いに異なる識別子を割り当てておく。なお、ソケットに対するアクセスは、そのソケットに対応づけられた他の監視対象装置１２へのアクセスを意味する。

図５は、監視データ３０が示す情報をテーブル形式で例示する図である。図５のテーブルを、テーブル２００と呼ぶ。テーブル２００は、主体情報２０２、客体情報２０４、及び内容情報２０６を含む。主体情報２０２は、プロセス名２０８及びパス２１０が含まれている。客体情報２０４には、種別２１２及び識別情報２１４が含まれている。

監視データ３０の生成には、コンピュータで発生するイベントを記録する任意の技術を利用することができる。例えば各監視対象装置１２に、イベントが発生した際にそのイベントについて監視データ３０を生成する機能を持たせておく。例えば、監視対象装置１２は、情報処理装置２０００からもアクセス可能な記憶装置に監視データ３０を記憶したり、情報処理装置２０００に対して監視データ３０を送信したりする。

＜監視データ３０の取得：Ｓ１０２＞
判定部２０２０は監視データ３０を取得する（Ｓ１０２）。判定部２０２０が監視データ３０を取得する方法は様々である。例えば判定部２０２０は、監視データ３０が記憶されている記憶装置から、監視データ３０を取得する。この記憶装置は、情報処理装置２０００の外部に設けられていてもよいし、内部に設けられていてもよい。その他にも例えば、判定部２０２０は、他の装置（例えば監視対象装置１２）から送信される監視データ３０を受信してもよい。

＜判定モデル２０について＞
判定モデル２０について説明する。まず、発生が稀なイベントは、注目すべきイベントであると考えられる。なぜなら、頻繁に発生するイベントは正常なイベントである蓋然性が高い一方、発生が稀なイベントは異常なイベントである蓋然性が高いと言えるためである。例えば、マルウエアなどによるサイバー攻撃に関連するイベント（マルウエアによるファイルアクセスなど）は、通常のプロセスが発生させるイベントと比較し、発生が稀である。

そこで判定モデル２０は、監視対象システム１０において発生する回数や頻度が比較的少ないイベントを警告対象のイベントとし、監視対象システム１０において発生する回数や頻度が比較的多いイベントを警告対象でないイベントとする。そのために、例えば判定モデル２０を、１）各イベントの発生数又は発生頻度に基づくスコア、及び２）閾値で構成する。ここで、スコアはイベントごとに定められている。

イベントが警告対象であるか否かの判定は、そのイベントのスコアと閾値とを比較することで行われる。イベントのスコアが閾値以下である場合、判定モデル２０は、そのイベントが警告対象であると判定する。一方、イベントのスコアが閾値より大きい場合、判定モデル２０は、そのイベントが警告対象でないと判定する。

各イベントのスコアは、後述する種々の方法で判定モデル２０を更新することで変化する。なお、監視対象システム１０において初めて発生したイベントについては、初期値を設定したスコアを生成する。スコアの初期値は任意の値とすることができる。スコアの初期値は、全てのイベントで共通であってもよいし、イベントごとに異なっていてもよい。例えば、イベントの主体や客体の種類に応じて、スコアの初期値を異ならせるといったことが考えられる。

＜判定モデル２０の更新：Ｓ１０６＞
更新部２０４０は、監視データ３０、及びその監視データ３０についての判定モデル２０による判定の結果に基づいて、判定モデル２０を更新する。ここで前述したように、基本的には、判定モデル２０は、監視対象システム１０において発生する回数や頻度が比較的少ないイベントを警告対象とし、監視対象システム１０において発生する回数や頻度が比較的多いイベントを警告対象でないイベントとする。これを実現する単純な方法としては、或るイベントが発生する度にそのイベントのスコアを増加させるという方法がある。こうすることで、イベントの発生数が多いほどイベントのスコアが大きくなる。

しかしながらこの方法では、判定部２０２０によって警告対象のイベントであると判定されるイベントが何度も発生すると、そのイベントがいずれ警告対象として扱われなくなる。しかしながら、イベントによっては、たとえ何度も発生したとしても、警告対象のイベントとして扱われ続けるようにしたいものがある。このようなイベントには、例えばサイバー攻撃に関連するイベントがある。

そこで更新部２０４０は、或るイベントが発生したという事実だけでなく、そのイベントが判定モデル２０によってどのように判定されたかなども考慮して、判定モデル２０におけるそのイベントのスコアを更新する。以下、その方法の具体例を例示する。

＜＜更新方法の例１＞＞
更新部２０４０は、監視データ３０が表すイベントについて必ずしもスコアを増加させるのではなく、場合によってはスコアを増加させないようにする。図６は、更新方法の例１の流れを例示するフローチャートである。

監視データ３０が表すイベントが判定部２０２０によって警告対象のイベントでないと判定された場合（Ｓ２０２：ＮＯ）、更新部２０４０は、判定モデル２０におけるそのイベントのスコアを増加させる（例えば所定の値を加算する）ようにする（Ｓ２０４）。

一方、監視データ３０が表すイベントが判定部２０２０によって警告対象のイベントであると判定された場合（Ｓ２０４：ＹＥＳ）、更新部２０４０は、そのイベントが所定の条件（例えば、サイバー攻撃に関連するという条件）を満たすか否かを判定する（Ｓ２０６）。所定の条件が満たされない場合（Ｓ２０６：ＮＯ）、更新部２０４０は、判定モデル２０におけるそのイベントのスコアを増加させる（Ｓ２０４）。

一方、そのイベントが所定の条件を満たす場合（Ｓ２０６：ＹＥＳ）、更新部２０４０は、判定モデル２０におけるそのイベントのスコアを増加させない（図６の処理が終了する）。ここで、「スコアを増加させない」とは、スコアにゼロを加算するという処理を実行するという方法で実現されてもよいし、スコアを変更する処理自体を実行しないという方法で実現されてもよい。前者は、上記所定の条件を満たすイベントを表す監視データ３０がスコアを変更する処理（例えば関数）に対して入力されるもののスコアの増加量がゼロであることを意味し、後者は、上記所定の条件を満たすイベントを表す監視データ３０がスコアを変更する処理に対して入力されないことを意味する。

以上のことから、この例では、監視データ３０が表すイベントが、判定部２０２０によって警告対象のイベントであると判定され、なおかつ所定の条件を満たす場合には、判定モデル２０におけるそのイベントのスコアを増加させない。それ以外の場合には、判定モデル２０におけるそのイベントのスコアを増加させる。こうすることで、警告対象であると判定されるイベントのうち、サイバー攻撃に関連するなどといった所定の条件を満たすものについては、判定モデル２０におけるスコアが増加しないため、スコアが閾値を超えない。そのため、そのようなイベントが警告対象として扱われ続けるようにすることができる。

ここで、スコアの増加量は、全てのイベントで共通であってもよいし、イベントごとに異なっていてもよい。後者の場合、例えば、イベントの要素に重みを与えておく。また、全てのイベントに共通するデフォルトの増加量を定めておく。更新部２０４０は、デフォルトの増加量と、イベントの要素に付された重みとに基づいて、そのイベントのスコアの増加量を決定する。例えば更新部２０４０は、デフォルトの増加量と、イベントの要素に付された重みとを掛け合わせた値を、そのイベントのスコアの増加量とする。

イベントの要素に付す重みは、イベントの要素単体に付されてもよいし、要素の組み合わせに付されてもよい。例えば、ほとんど動作しないことが予め分かっているプログラムがあれば、そのプログラムを示す主体に、１より大きい重みを付しておく。ファイルアクセスをほとんど行わないことが予め分かっているプログラムがあれば、「主体がそのプログラム、活動内容がファイルアクセス」という組み合わせに対して、１より大きい重みを付しておく。

更新部２０４０がイベントの要素の重みを把握する方法は様々である。例えば、更新部２０４０は、重みに関する情報が監視データ３０に含まれているようにする。この場合、更新部２０４０は、監視データ３０を参照することで、イベントの要素に付された重みを把握できる。その他にも例えば、イベントの要素又はその組み合わせに対応づけて重みを示す情報（以下、重み情報）を記憶装置に記憶させておいてもよい。この場合、更新部２０４０は、この記憶装置にアクセスすることでイベントの要素の重みを把握する。

なお、イベントの要素に付される重みは任意のタイミングで変更されてもよい。このようにすると、同一のイベントであっても、その時々に重みに応じて、スコアの増加量が変わることになる。例えば、重みに関する情報が監視データ３０に含まれる場合、互いに異なるタイミングで取得された監視データ３０が同じイベントを示していても、イベントの要素に付された重みが異なることがある。同様に、記憶装置に記憶されている重み情報の内容が、アクセスするタイミングによって異なることとなる。

＜＜更新方法の例２＞＞
更新部２０４０は、監視データ３０が表すイベントについて、状況に応じて異なる増加量でスコアを増加させる。図７は、更新方法の例２の流れを例示するフローチャートである。

例えば、更新部２０４０は、監視データ３０が表すイベントが判定部２０２０によって警告対象でないと判定された場合（Ｓ３０２：ＮＯ）、そのイベントのスコアを d1 増加させる（Ｓ３０４）。また、更新部２０４０は、監視データ３０が表すイベントが判定部２０２０によって警告対象であると判定され（Ｓ３０２：ＹＥＳ）、なおかつそのイベントが上記所定の条件を満たさない場合（Ｓ３０６：ＮＯ）、そのイベントのスコアを d2 増加させる（Ｓ３０８）。さらに、更新部２０４０は、監視データ３０が表すイベントが判定部２０２０によって警告対象であると判定され（Ｓ３０２：ＹＥＳ）、なおかつそのイベントが上記所定の条件を満たす場合（Ｓ３０６：ＹＥＳ）、そのイベントのスコアを d3 増加させる（Ｓ３１０）。この場合、少なくとも d3 を、d1 や d2 よりも小さい値とする。すなわち、「d1>=d2>d3」が満たされるようにする。これらスコアの増加量の値は、更新部２０４０からアクセス可能な記憶装置に予め記憶させておく。

以上の方法によれば、警告対象であると判定されるイベントのうち、サイバー攻撃に関連するなどといった所定の条件を満たすものについては、その他のイベントと比較し、スコアが増加しにくくなる。そのため、そのような所定の条件を満たすイベントが、警告対象として扱われ続ける蓋然性を高くすることができる。

なお、上述の各方法でスコアを増加させる際、現状のスコアに１未満の所定値を乗算した上でスコアを増加させてもよい。こうすることで、スコアが、直近の状況を重要視したものとなる。

なお、「更新方法の例１」で説明したように、スコアの増加量は重みを考慮して決定されてもよい。この場合、スコアの増加量 d1 から d3 を、スコアの増加量のデフォルト値として利用する。更新部２０４０は、スコアのデフォルト値を d1 から d3 のうちのどの値にするかを決定した後、決定した値に前述した重みを掛け合わせることで、スコアの増加量を決定する。

＜所定の条件について＞
前述したように、警告対象であると判定され、なおかつ所定の条件を満たすイベントについては、判定モデル２０におけるそのイベントのスコアを増加させないようにしたり、スコアの増加量を比較的少なくしたりする。例えば所定の条件は、「所定のプログラムに関連するイベントである」という条件である。例えば、所定のプログラムをマルウエア等のサイバー攻撃に関連するプログラムとすることで、「サイバー攻撃に関連するイベントである」という所定の条件を作ることができる。

ここで、「所定のプログラムに関連するイベント」とは、例えば、主体及び客体の少なくとも一方が所定のプログラムであるイベントや、所定のプログラムによって生成されたデータを客体とするイベントなどである。その他にも例えば、１）所定のプログラムが動作していた監視対象装置１２において発生したイベント、２）所定のプログラムと通信した他の監視対象装置１２において発生したイベント、３）所定のプログラムが生成したデータを読み込んだ別のプログラムに関わるイベント、４）所定のプログラムを起動した他のプログラムに関わるイベント、又は５）所定のプログラムが動作していた時間帯やその時間帯の前後に任意の監視対象装置１２で発生したイベントなどを、「所定のプログラムに関連するイベント」として扱ってもよい。

所定のプログラムは、１つであってもよいし、複数であってもよい。所定のプログラムを定義する情報（例えばプログラムの名称や実行ファイルの名前）は、更新部２０４０からアクセス可能な記憶装置に記憶させておく。

＜警告の出力＞
監視データ３０が表すイベントが警告対象のイベントであると判定された場合、警告対象のイベントが発生したことを監視対象システム１０の管理者等が把握できるようにすることが好適である。そこで例えば、情報処理装置２０００は、監視データ３０が表すイベントが警告対象のイベントであると判定された場合に、所定の警告情報を出力する。

警告情報としては、様々なものを採用できる。例えば警告情報は、警告対象のイベントが発生したことを通知する文字列、画像、又は音声などである。なお、警告情報には、警告対象であると判定されたイベントを特定する情報（主体情報、客体情報、及び内容情報）を含めることが好適である。

警告情報の出力先としては、様々な出力先を採用できる。例えば警告情報は、監視対象システム１０の管理者等が利用するコンピュータに対して出力される。このコンピュータは、据え置き型のコンピュータ（デスクトップ PC など）であってもよいし、可搬型のコンピュータ（携帯端末など）であってもよい。また、警告情報は、監視対象システム１０の管理者等に対して送信されてもよい。この場合、例えば警告情報は、監視対象システム１０の管理者等に対してメールなどで送信される。

その他にも例えば、警告情報は、監視対象システム１０の管理者等が利用するコンピュータからアクセス可能な記憶装置に記憶されてもよい。より具体的には、この記憶装置には、警告対象のイベントが発生した場合に、そのイベントに関する情報を記憶するログファイルを用意しておく。情報処理装置２０００は、監視データ３０が表すイベントが警告対象であると判定された場合に、このログファイルに対して、そのイベントに関する情報を追記する。監視対象システム１０の管理者等が利用するコンピュータは、このログファイルを参照することで、監視対象システム１０で発生した警告対象のイベントに関する情報を取得することができる。

［実施形態２］
図８は、実施形態２の情報処理装置２０００の動作の概要を表す図である。図８は情報処理装置２０００の動作についての理解を容易にするための概念的な図であり、情報処理装置２０００の動作を具体的に限定するものではない。

実施形態２の情報処理装置２０００は、実施形態１の情報処理装置２０００と同様に、判定モデル２０を用いて、監視対象システム１０において発生したイベントが警告対象のイベントであるか否かを判定する。ただし、判定モデル２０の更新について、実施形態１の情報処理装置２０００と異なる点がある。以下、その点について説明する。

まず、実施形態２の情報処理装置２０００は、取得した監視データ３０に基づいて判定モデル２０を更新する。この更新には、監視データ３０が警告対象であるか否かについての判定の結果が利用されない。そのため、情報処理装置２０００は、監視データ３０が警告対象であるか否かの判定と非同期に、判定モデル２０の更新を行える。このようにすることで、実施形態１の情報処理装置２０００と比較し、実施形態２の情報処理装置２０００では、判定モデル２０の更新を早く完了することができる。

ただし、判定モデル２０の更新を行った後、実施形態２の情報処理装置２０００は、監視データ３０が警告対象であるか否かの判定の結果に基づき、必要に応じて、判定モデル２０の修正を行う。すなわち、情報処理装置２０００は、「ひとまず判定モデル２０の更新を行い、必要に応じて後から判定モデル２０に修正を加える」という動作をする。このように判定モデル２０を修正することにより、実施形態２の情報処理装置２０００における判定モデル２０の判定基準（すなわち、スコア）を、実施形態１の判定モデル２０と同等にすることができる。

このように後から判定モデル２０を修正するという手法は、例えば、監視対象システム１０において頻繁にイベントが発生するケースに適している。なぜなら、イベントが頻繁に発生する場合、イベントが発生する度に判定モデル２０を更新していると、判定モデル２０の更新処理が情報処理装置２０００にかける計算負荷が大きくなり、イベントが警告対象であるか否かを判定する処理に影響を及ぼしてしまう可能性があるためである。具体的には、判定処理に要する時間が長くなってしまうといった影響が考えられる。実施形態の情報処理装置２０００によれば、このような影響が生じることを防ぐことができる。

＜機能構成の例＞
図９は、実施形態２の情報処理装置２０００の機能構成を例示する図である。実施形態２の情報処理装置２０００は、判定部２０２０、第２更新部２０８０、及び修正部２０６０を有する。判定部２０２０は、監視データ３０を取得し、判定モデル２０を用いて、監視データ３０によって表されるイベントが警告対象であるか否かを判定する。第２更新部２０８０は、監視データ３０を用いて判定モデルの更新を行う。修正部２０６０は、監視データ３０についての判定部２０２０による判定の結果に基づいて、その監視データ３０に基づいて更新された判定モデル２０を修正する。

＜ハードウエア構成の例＞
実施形態２の情報処理装置２０００を実現する計算機のハードウエア構成は、実施形態１と同様に、例えば図３によって表される。ただし、本実施形態の情報処理装置２０００を実現する計算機１０００のストレージデバイス１０８０には、本実施形態の情報処理装置２０００の機能を実現するプログラムモジュールがさらに記憶される。

＜処理の流れ＞
図１０は、実施形態２の情報処理装置２０００が判定モデル２０を更新する流れを例示する図である。情報処理装置２０００は監視データ３０を取得する（Ｓ４０２）。判定部２０２０は、判定モデル２０を用いて、監視データ３０によって表されるイベントが警告対象のイベントであるか否かを判定する（Ｓ４０４）。第２更新部２０８０は、監視データ３０を用いて判定モデル２０を更新する（Ｓ４０６）。

さらに、修正部２０６０が、判定モデル２０の修正を行う。ここで、修正部２０６０が判定モデル２０の修正を行うタイミングは任意のタイミングとすることができる。例えば、修正部２０６０は、定期的に（例えば１日に１回）判定モデル２０の修正を行う。

＜判定モデル２０の更新と修正の方法について＞
判定モデル２０の更新と修正の方法の具体例を、実施形態１における判定モデル２０の更新方法と対比して説明する。

＜＜修正方法の例１＞＞
例えば実施形態１において、更新部２０４０は、判定部２０２０によって警告対象のイベントであると判定され、なおかつ所定の条件を満たすイベントについては、判定モデル２０におけるそのイベントのスコアを増加させないようにする。実施形態２の情報処理装置２０００は、判定モデル２０の修正によってこれと同様のことを実現する。そのために、例えば第２更新部２０８０と修正部２０６０は以下のように動作する。

まず第２更新部２０８０は、監視データ３０によって表されるイベントについて、判定モデル２０におけるそのイベントのスコアを増加させる。ここでは、判定部２０２０による判定の結果を考慮しない。そのため、実施形態１のケースとは異なり、「判定部２０２０によって警告対象のイベントであると判定され、なおかつ所定の条件を満たすイベント」についてのスコアも増加することになる。

ただしその後、修正部２０６０は、「判定部２０２０によって警告対象のイベントであると判定され、なおかつ所定の条件を満たすイベント」についてのスコアの増加を打ち消すように、判定モデル２０を修正する。例えば修正部２０６０は、前回判定モデル２０の修正をした時点以降に行われた各更新に利用された監視データ３０のうち、監視データ３０によって表されるイベントが警告対象であると判定されたものを抽出する。さらに修正部２０６０は、抽出した各監視データ３０について、イベントが所定の条件（実施形態１参照）を満たすか否かを判定する。修正部２０６０は、イベントが所定の条件を満たす場合、そのイベントのスコアを減少させることで、判定モデル２０を修正する。例えば第２更新部２０８０がそのイベントのスコアを d 増加させていた場合、修正部２０６０は、そのイベントのスコアを d 減少させる。

＜＜修正方法の例２＞＞
例えば実施形態１において、更新部２０４０は、監視データ３０が表すイベントについて、状況に応じて異なる増加量でスコアを増加させる。実施形態２の情報処理装置２０００は、判定モデル２０の修正によってこれと同様のことを実現する。そのために、例えば第２更新部２０８０と修正部２０６０は以下のように動作する。なお、スコアの増加量は、図７で説明した通り、d1、d2、又は d3 であるとする。

まず第２更新部２０８０は、監視データ３０によって表されるイベントについて、判定モデル２０におけるそのイベントのスコアを d1 増加させる。ここでは、判定部２０２０による判定の結果などは考慮しないため、スコアの増加量が d1 に固定されている。

ただしその後、修正部２０６０は、判定部２０２０によって警告対象のイベントであると判定されたイベントについて、スコアを修正する。例えば修正部２０６０は、前回判定モデル２０の修正をした時点以降に行われた各更新に利用された監視データ３０のうち、監視データ３０によって表されるイベントが警告対象であると判定されたものを抽出する。さらに修正部２０６０は、抽出した各監視データ３０について、イベントが所定の条件（実施形態１参照）を満たすか否かを判定する。修正部２０６０は、イベントが所定の条件を満たす場合、そのイベントのスコアを (d1-d3） 減少させる。一方、イベントが所定の条件を満たさない場合、修正部２０６０は、そのイベントのスコアを (d1-d2） 減少させる。なお、d1=d2 である場合、後者の修正は不要である。

＜判定モデル２０のその他の修正方法＞
判定モデル２０の修正方法は、上述のようなスコアの値を変更する方法に限定されない。例えば修正部２０６０は、判定モデル２０の修正が必要な場合、判定モデル２０の更新の少なくとも一部をキャンセルし、実施形態１の更新部２０４０に判定モデル２０の更新をやり直させてもよい。この場合、実施形態２の情報処理装置２０００は、第２更新部２０８０に加え、更新部２０４０を有する。

以下、さらに具体的に説明する。修正部２０６０は、前回判定モデル２０の修正を行った時点以降に取得され、なおかつ判定部２０２０によって警告対象のイベントであると判定されたもののうち、最も早い時点に取得された監視データ３０を特定する。ここで、この時点以前の判定モデル２０に対する更新については、修正の必要がないと言える。

そこでまず、修正部２０６０は、現状の判定モデル２０を、上記特定した時点における判定モデル２０に変更する。さらに修正部２０６０は、更新部２０４０に、上記特定した時点以降に取得した各監視データ３０及び、それら各監視データ３０についての判定部２０２０による判定の結果に基づいて、判定モデル２０の更新を行わせる。こうすることで、上記特定した時点以降に第２更新部２０８０が行った判定モデル２０の更新がキャンセルされ、代わりに更新部２０４０による更新が適用されることになる。

なお、この方法を実現するためには、判定モデル２０の変更履歴を記憶装置に記憶させておく必要がある。例えば、第２更新部２０８０は、判定モデル２０を更新する前に、変更前の判定モデル２０を記憶装置に記憶させておく。

ただし、判定モデル２０の変更履歴の全てではなく、その一部のみを記憶させるようにしてもよい。例えば、所定時間おきにその時点における判定モデル２０を記憶装置に記憶させるようにする。この場合、修正部２０６０は、記憶装置に記憶されている判定モデル２０の履歴のうち、修正の必要がない最も新しい判定モデル２０で、現状の判定モデル２０を置き換える。そして、更新部２０４０が、その判定モデル２０が記憶された時点以降に取得された各監視データ３０、及びそれら各監視データ３０についての判定部２０２０による判定の結果に基づいて、判定モデル２０の更新を行う。

このように更新部２０４０に更新をやり直させるという修正方法は、例えば、イベントの要素にスコアの増加量についての重みが付されており、その重みが変化する場合において有用である。このケースでは、第２更新部２０８０が判定モデル２０の更新を行った時に変化したスコアが、その時にイベントに付されていた重みに依存する。そのため、「修正方法の例１」や「修正方法の例２」に示した方法でスコアの値を修正するよりも、再度学習をやり直した方が、処理が容易になる。

以上、図面を参照して本発明の実施形態について述べたが、これらは本発明の例示であり、上記各実施形態の組み合わせ、又は上記以外の様々な構成を採用することもできる。

上記の実施形態の一部又は全部は、以下の付記のようにも記載されうるが、以下には限られない。

以下、参考形態の例を付記する。
１． イベントを表す監視データを取得し、イベントが警告対象であるか否かを判定する判定モデルを用いて、前記取得した監視データによって表されるイベントが警告対象であるか否かを判定する判定部と、
前記監視データ及び前記判定部によるその監視データについての判定結果に基づいて、前記判定モデルの更新を行う更新部と、を有する情報処理装置。
２． 前記判定モデルは、各イベントについてのスコアを保持しており、前記監視データが表すイベントのスコアが閾値以下である場合に、そのイベントが警告対象であると判定し、
前記更新部は、前記監視データが表すイベントが警告対象であると判定された場合に、そのイベントが所定の条件を満たすか否かを判定し、
前記更新部は、
前記監視データが表すイベントが警告対象でないと判定された場合と、前記監視データが表すイベントが前記所定の条件を満たさないと判定された場合とにおいて、前記判定モデルにおけるそのイベントのスコアを増加させ、
前記監視データが表すイベントが前記所定の条件を満たすと判定された場合において、前記判定モデルにおけるそのイベントのスコアを増加させない、１．に記載の情報処理装置。
３． 前記判定モデルは、各イベントについてのスコアを保持しており、前記監視データが表すイベントのスコアが閾値以下である場合に、そのイベントが警告対象であると判定し、
前記更新部は、前記監視データが表すイベントについて、前記判定モデルが示すそのイベントのスコアを増加させ、
前記更新部は、前記監視データが表すイベントが警告対象であると判定された場合、そのイベントが所定の条件を満たすか否かを判定し、そのイベントが所定の条件を満たす場合、そのイベントが所定の条件を満たさない場合よりも小さい増加量で、そのイベントのスコアを増加させる、１．に記載の情報処理装置。
４． 前記所定の条件は、サイバー攻撃に関連するイベントであるという条件である、２．又は３．に記載の情報処理装置。

５． イベントを表す監視データを取得し、イベントが警告対象であるか否かを判定する判定モデルを用いて、前記取得した監視データによって表されるイベントが警告対象であるか否かを判定する判定部と、
前記監視データを用いて前記判定モデルの更新を行う更新部と、
前記監視データについての判定部による判定の結果に基づいて、その監視データに基づいて更新された前記判定モデルを修正する修正部と、を有する情報処理装置。
６． 前記修正部は、定期的に前記判定モデルの修正を行う、５．に記載の情報処理装置。
７． 前記判定モデルは、各イベントについてのスコアを保持しており、前記監視データが表すイベントのスコアが閾値以下である場合に、そのイベントが警告対象であると判定し、
前記更新部は、前記監視データが表すイベントのスコアを増加させることで前記判定モデルを更新し、
前記修正部は、前記監視データが表すイベントが警告対象であると判定された場合に、そのイベントが所定の条件を満たすか否かを判定し、そのイベントが所定の条件を満たす場合、その監視データに基づく更新によって増加した分だけそのイベントのスコアを小さくするように、そのイベントのスコアを変更する、５．又は６．に記載の情報処理装置。
８． 前記修正部は、
前回前記判定モデルを修正した時点以降に取得した前記監視データであり、なおかつ前記判定部によって警告対象であると判定された前記監視データのうち、取得した時点が最も早い前記監視データを特定し、
前記特定した監視データを取得した時点における前記判定モデルで現在の前記判定モデルを置き換え、
前記特定した監視データを取得した時点以降に取得された前記監視データ、及びその監視データについて前記判定部が行った判定の結果に基づいて、前記判定モデルを更新する、５．又は６．に記載の情報処理装置。

９． コンピュータによって実行させる制御方法であって、
イベントを表す監視データを取得し、イベントが警告対象であるか否かを判定する判定モデルを用いて、前記取得した監視データによって表されるイベントが警告対象であるか否かを判定する判定ステップと、
前記監視データ及び前記判定ステップによるその監視データについての判定結果に基づいて、前記判定モデルの更新を行う更新ステップと、を有する制御方法。
１０． 前記判定モデルは、各イベントについてのスコアを保持しており、前記監視データが表すイベントのスコアが閾値以下である場合に、そのイベントが警告対象であると判定し、
前記更新ステップにおいて、前記監視データが表すイベントが警告対象であると判定された場合に、そのイベントが所定の条件を満たすか否かを判定し、
前記更新ステップにおいて、
前記監視データが表すイベントが警告対象でないと判定された場合と、前記監視データが表すイベントが前記所定の条件を満たさないと判定された場合とにおいて、前記判定モデルにおけるそのイベントのスコアを増加させ、
前記監視データが表すイベントが前記所定の条件を満たすと判定された場合において、前記判定モデルにおけるそのイベントのスコアを増加させない、９．に記載の制御方法。
１１． 前記判定モデルは、各イベントについてのスコアを保持しており、前記監視データが表すイベントのスコアが閾値以下である場合に、そのイベントが警告対象であると判定し、
前記更新ステップにおいて、前記監視データが表すイベントについて、前記判定モデルが示すそのイベントのスコアを増加させ、
前記更新ステップにおいて、前記監視データが表すイベントが警告対象であると判定された場合、そのイベントが所定の条件を満たすか否かを判定し、そのイベントが所定の条件を満たす場合、そのイベントが所定の条件を満たさない場合よりも小さい増加量で、そのイベントのスコアを増加させる、９．に記載の制御方法。
１２． 前記所定の条件は、サイバー攻撃に関連するイベントであるという条件である、１０．又は１１．に記載の制御方法。

１３． コンピュータによって実行させる制御方法であって、
イベントを表す監視データを取得し、イベントが警告対象であるか否かを判定する判定モデルを用いて、前記取得した監視データによって表されるイベントが警告対象であるか否かを判定する判定ステップと、
前記監視データを用いて前記判定モデルの更新を行う更新ステップと、
前記監視データについての判定ステップによる判定の結果に基づいて、その監視データに基づいて更新された前記判定モデルを修正する修正ステップと、を有する制御方法。
１４． 前記修正ステップにおいて、定期的に前記判定モデルの修正を行う、１３．に記載の制御方法。
１５． 前記判定モデルは、各イベントについてのスコアを保持しており、前記監視データが表すイベントのスコアが閾値以下である場合に、そのイベントが警告対象であると判定し、
前記更新ステップにおいて、前記監視データが表すイベントのスコアを増加させることで前記判定モデルを更新し、
前記修正ステップにおいて、前記監視データが表すイベントが警告対象であると判定された場合に、そのイベントが所定の条件を満たすか否かを判定し、そのイベントが所定の条件を満たす場合、その監視データに基づく更新によって増加した分だけそのイベントのスコアを小さくするように、そのイベントのスコアを変更する、１３．又は１４．に記載の制御方法。
１６． 前記修正ステップにおいて、
前回前記判定モデルを修正した時点以降に取得した前記監視データであり、なおかつ前記判定ステップによって警告対象であると判定された前記監視データのうち、取得した時点が最も早い前記監視データを特定し、
前記特定した監視データを取得した時点における前記判定モデルで現在の前記判定モデルを置き換え、
前記特定した監視データを取得した時点以降に取得された前記監視データ、及びその監視データについて前記判定ステップが行った判定の結果に基づいて、前記判定モデルを更新する、１３．又は１４．に記載の制御方法。

１７． ９．乃至１６．いずれか一つに記載の制御方法の各ステップをコンピュータに実行させるプログラム。

１０ 監視対象システム
１２ 監視対象装置
２０ 判定モデル
３０ 監視データ
２００ テーブル
２０２ 主体情報
２０４ 客体情報
２０６ 内容情報
２０８ プロセス名
２１０ パス
２１２ 種別
２１４ 識別情報
１０００ 計算機
１０２０ バス
１０４０ プロセッサ
１０６０ メモリ
１０８０ ストレージデバイス
１１００ 入出力インタフェース
１１２０ ネットワークインタフェース
２０００ 情報処理装置
２０２０ 判定部
２０４０ 更新部
２０６０ 第２更新部
２０８０ 修正部

Claims (11)

1. イベントを表す監視データを取得し、イベントが警告対象であるか否かを判定する判定モデルを用いて、前記取得した監視データによって表されるイベントが警告対象であるか否かを判定する判定部と、
   前記判定モデルを用いた判定結果であって前記イベントが警告対象であるか否かの判定結果、および、前記監視データが表す前記イベントが所定の条件を満たすか否かの判定結果に基づいて、前記判定モデルの更新を行う更新部と、を有し、
   前記判定モデルは、各イベントについてのスコアを保持しており、前記監視データが表すイベントのスコアが閾値以下である場合に、そのイベントが警告対象であると判定し、
   前記更新部は、前記監視データが表すイベントが警告対象であると判定された場合に、そのイベントが前記所定の条件を満たすか否かを判定し、
   前記更新部は、
   前記監視データが表すイベントが警告対象でないと判定された場合と、前記監視データが表すイベントが前記所定の条件を満たさないと判定された場合とにおいて、前記判定モデルにおけるそのイベントのスコアを増加させ、
   前記監視データが表すイベントが前記所定の条件を満たすと判定された場合において、前記判定モデルにおけるそのイベントのスコアを増加させない、情報処理装置。
2. イベントを表す監視データを取得し、イベントが警告対象であるか否かを判定する判定モデルを用いて、前記取得した監視データによって表されるイベントが警告対象であるか否かを判定する判定部と、
   前記判定モデルを用いた判定結果であって前記イベントが警告対象であるか否かの判定結果、および、前記監視データが表す前記イベントが所定の条件を満たすか否かの判定結果に基づいて、前記判定モデルの更新を行う更新部と、を有し、
   前記判定モデルは、各イベントについてのスコアを保持しており、前記監視データが表すイベントのスコアが閾値以下である場合に、そのイベントが警告対象であると判定し、
   前記更新部は、前記監視データが表すイベントについて、前記判定モデルが示すそのイベントのスコアを増加させ、
   前記更新部は、前記監視データが表すイベントが警告対象であると判定された場合、そのイベントが前記所定の条件を満たすか否かを判定し、そのイベントが前記所定の条件を満たす場合、そのイベントが前記所定の条件を満たさない場合よりも小さい増加量で、そのイベントのスコアを増加させる、情報処理装置。
3. イベントを表す監視データを取得し、イベントが警告対象であるか否かを判定する判定モデルを用いて、前記取得した監視データによって表されるイベントが警告対象であるか否かを判定する判定部と、
   前記監視データを用いて前記判定モデルの更新を行う更新部と、
   前記更新部による前記判定モデルの更新の後、当該判定モデルを用いた判定結果であって前記イベントが警告対象であるか否かの判定結果、および、前記監視データが表す前記イベントが所定の条件を満たすか否かの判定の結果に基づいて、その監視データに基づいて更新された前記判定モデルを修正する修正部と、を有し、
   前記判定モデルは、各イベントについてのスコアを保持しており、前記監視データが表すイベントのスコアが閾値以下である場合に、そのイベントが警告対象であると判定し、
   前記更新部は、前記監視データが表すイベントのスコアを増加させることで前記判定モデルを更新し、
   前記修正部は、前記監視データが表すイベントが警告対象であると判定された場合に、そのイベントが所定の条件を満たすか否かを判定し、そのイベントが所定の条件を満たす場合、その監視データに基づく更新によって増加した分だけそのイベントのスコアを小さくするように、そのイベントのスコアを変更する、情報処理装置。
4. 前記修正部は、定期的に前記判定モデルの修正を行う、請求項３に記載の情報処理装置。
5. 前記修正部は、
   前回前記判定モデルを修正した時点以降に取得した前記監視データであり、なおかつ前記判定部によって警告対象であると判定された前記監視データのうち、取得した時点が最も早い前記監視データを特定し、
   前記特定した監視データを取得した時点における前記判定モデルで現在の前記判定モデルを置き換え、
   前記特定した監視データを取得した時点以降に取得された前記監視データ、及びその監視データについて前記判定部が行った判定の結果に基づいて、前記判定モデルを更新する、請求項３又は４に記載の情報処理装置。
6. 前記所定の条件は、所定のプログラムに関連するイベントであるという条件を含む、請求項１から５のいずれか一項に記載の情報処理装置。
7. 前記所定の条件は、サイバー攻撃に関連するイベントであるという条件を含む、請求項６に記載の情報処理装置。
8. コンピュータによって実行される制御方法であって、
   イベントを表す監視データを取得し、イベントが警告対象であるか否かを判定する判定モデルを用いて、前記取得した監視データによって表されるイベントが警告対象であるか否かを判定する判定ステップと、
   前記判定モデルを用いた判定結果であって前記イベントが警告対象であるか否かの判定結果、および、前記監視データが表す前記イベントが所定の条件を満たすか否かの判定結果に基づいて、前記判定モデルの更新を行う更新ステップと、を有し、
   前記判定モデルは、各イベントについてのスコアを保持しており、前記監視データが表すイベントのスコアが閾値以下である場合に、そのイベントが警告対象であると判定し、
   前記更新ステップにおいて、前記監視データが表すイベントが警告対象であると判定された場合に、そのイベントが前記所定の条件を満たすか否かを判定し、
   前記更新において、
   前記監視データが表すイベントが警告対象でないと判定された場合と、前記監視データが表すイベントが前記所定の条件を満たさないと判定された場合とにおいて、前記判定モデルにおけるそのイベントのスコアを増加させ、
   前記監視データが表すイベントが前記所定の条件を満たすと判定された場合において、前記判定モデルにおけるそのイベントのスコアを増加させない、制御方法。
9. コンピュータによって実行される制御方法であって、
   イベントを表す監視データを取得し、イベントが警告対象であるか否かを判定する判定モデルを用いて、前記取得した監視データによって表されるイベントが警告対象であるか否かを判定する判定ステップと、
   前記判定モデルを用いた判定結果であって前記イベントが警告対象であるか否かの判定結果、および、前記監視データが表す前記イベントが所定の条件を満たすか否かの判定結果に基づいて、前記判定モデルの更新を行う更新ステップと、を有し、
   前記判定モデルは、各イベントについてのスコアを保持しており、前記監視データが表すイベントのスコアが閾値以下である場合に、そのイベントが警告対象であると判定し、
   前記更新ステップにおいて、前記監視データが表すイベントについて、前記判定モデルが示すそのイベントのスコアを増加させ、
   前記更新ステップにおいて、前記監視データが表すイベントが警告対象であると判定された場合、そのイベントが前記所定の条件を満たすか否かを判定し、そのイベントが前記所定の条件を満たす場合、そのイベントが前記所定の条件を満たさない場合よりも小さい増加量で、そのイベントのスコアを増加させる、制御方法。
10. コンピュータによって実行される制御方法であって、
    イベントを表す監視データを取得し、イベントが警告対象であるか否かを判定する判定モデルを用いて、前記取得した監視データによって表されるイベントが警告対象であるか否かを判定する判定ステップと、
    前記監視データを用いて前記判定モデルの更新を行う更新ステップと、
    前記更新ステップによる前記判定モデルの更新の後、当該判定モデルを用いた判定結果であって前記イベントが警告対象であるか否かの判定結果、および、前記監視データが表す前記イベントが所定の条件を満たすか否かの判定の結果に基づいて、その監視データに基づいて更新された前記判定モデルを修正する修正ステップと、を有し、
    前記判定モデルは、各イベントについてのスコアを保持しており、前記監視データが表すイベントのスコアが閾値以下である場合に、そのイベントが警告対象であると判定し、
    前記更新ステップにおいて、前記監視データが表すイベントのスコアを増加させることで前記判定モデルを更新し、
    前記修正ステップにおいて、前記監視データが表すイベントが警告対象であると判定された場合に、そのイベントが所定の条件を満たすか否かを判定し、そのイベントが所定の条件を満たす場合、その監視データに基づく更新によって増加した分だけそのイベントのスコアを小さくするように、そのイベントのスコアを変更する、制御方法。
11. 請求項８から１０のいずれか一項に記載の制御方法の各ステップをコンピュータに実行させるプログラム。

Images