特許 6104149 ログ分析装置及びログ分析方法及びログ分析プログラム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】6104149

(24)【登録日】2017年3月10日

(45)【発行日】2017年3月29日

(54)【発明の名称】ログ分析装置及びログ分析方法及びログ分析プログラム

(51)【国際特許分類】

   G06F 21/55 20130101AFI20170316BHJP

   H04L 12/70 20130101ALI20170316BHJP

   G06F 13/00 20060101ALI20170316BHJP

【ＦＩ】

   G06F21/55 320

   H04L12/70 100Z

   G06F13/00 351Z

【請求項の数】15

【全頁数】47

(21)【出願番号】特願2013-265650(P2013-265650)

(22)【出願日】2013年12月24日

(65)【公開番号】特開2015-121968(P2015-121968A)

(43)【公開日】2015年7月2日

【審査請求日】2016年1月15日

(73)【特許権者】

【識別番号】000006013

【氏名又は名称】三菱電機株式会社

(73)【特許権者】

【識別番号】394013002

【氏名又は名称】三菱電機インフォメーションシステムズ株式会社

(74)【代理人】

【識別番号】100099461

【弁理士】

【氏名又は名称】溝井 章司

(74)【代理人】

【識別番号】100176728

【弁理士】

【氏名又は名称】北村 慎吾

(72)【発明者】

【氏名】榊原 裕之

(72)【発明者】

【氏名】桜井 鐘治

(72)【発明者】

【氏名】伊串 亮二

(72)【発明者】

【氏名】酒巻 一紀

【審査官】 宮司 卓佳

(56)【参考文献】

【文献】 特開２００５−１３６５２６（ＪＰ，Ａ）

【文献】 特開２００８−１６７０９９（ＪＰ，Ａ）

【文献】 米国特許出願公開第２００７／０１６９１９４（ＵＳ，Ａ１）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｇ０６Ｆ ２１／５５

(57)【特許請求の範囲】

【請求項1】

攻撃を検知する検知装置が備えられたコンピュータシステムのログを記憶するログデータベースと、
前記コンピュータシステムを対象とする複数の攻撃と当該複数の攻撃の順番とを定義する攻撃シナリオを記憶する攻撃シナリオデータベースと、
前記攻撃シナリオデータベースに記憶された攻撃シナリオで定義されている複数の攻撃のうち、前記検知装置により未だ検知されておらず、当該攻撃シナリオで定義されている順番が前記検知装置により既に検知されている少なくとも１つの攻撃よりも前の攻撃を抽出する関連攻撃抽出部と、
前記ログデータベースに記憶されたログを分析して、前記コンピュータシステムが前記関連攻撃抽出部により抽出された攻撃を受けていたかどうかを判定し、受けていたと判定した場合に、攻撃の検知漏れが発生したと判断する攻撃判定部と
を備えることを特徴とするログ分析装置。

【請求項2】

前記検知装置に対して実施されているセキュリティ対策を示す情報を記憶するセキュリティ対策データベース
をさらに備え、
前記攻撃シナリオデータベースに記憶された攻撃シナリオでは、前記コンピュータシステムに対する複数の攻撃のそれぞれに対応するセキュリティ対策が定義され、
前記攻撃判定部は、前記セキュリティ対策データベースに記憶された情報を参照して、前記攻撃シナリオデータベースに記憶された攻撃シナリオで定義されている、前記関連攻撃抽出部により抽出された攻撃に対応するセキュリティ対策が前記検知装置に対して実施されているかどうかを判定し、実施されていると判定した場合に、前記コンピュータシステムが前記関連攻撃抽出部により抽出された攻撃を受けていたと判定した場合、前記検知装置における攻撃の検知漏れが発生したと判断することを特徴とする請求項１のログ分析装置。

【請求項3】

前記コンピュータシステムに含まれる複数のコンピュータと当該複数のコンピュータのそれぞれに対して実施されているセキュリティ対策を示す情報を記憶するインベントリデータベース
をさらに備え、
前記攻撃シナリオデータベースに記憶された攻撃シナリオでは、前記コンピュータシステムに対する複数の攻撃のそれぞれが対象とするコンピュータと当該複数の攻撃のそれぞれに対応するセキュリティ対策とが定義され、
前記攻撃判定部は、前記インベントリデータベースに記憶された情報を参照して、前記攻撃シナリオデータベースに記憶された攻撃シナリオで定義されている、前記関連攻撃抽出部により抽出された攻撃に対応するセキュリティ対策が、当該攻撃シナリオで定義されている、当該攻撃が対象とするコンピュータに対して実施されているかどうかを判定し、実施されていないと判定した場合に、前記ログデータベースに記憶されたログを分析することを特徴とする請求項１又は２のログ分析装置。

【請求項4】

前記攻撃シナリオデータベースに記憶された攻撃シナリオでは、前記コンピュータシステムに対する複数の攻撃のそれぞれが利用する脆弱性が定義され、
前記攻撃判定部は、脆弱性に関する情報を公開する外部のシステムにアクセスして、前記攻撃シナリオデータベースに記憶された攻撃シナリオで定義されている、前記関連攻撃抽出部により抽出された攻撃が利用する脆弱性に関する情報が当該外部のシステムにより公開されているかどうかを判定し、公開されていると判定した場合に、前記ログデータベースに記憶されたログを分析することを特徴とする請求項１から３のいずれかのログ分析装置。

【請求項5】

前記攻撃判定部は、前記ログデータベースに記憶されたログを分析する際に、前記攻撃シナリオデータベースに記憶された攻撃シナリオで定義されている複数の攻撃のうち、前記検知装置により既に検知されており、当該攻撃シナリオで定義されている順番が前記関連攻撃抽出部により抽出された攻撃の１つ前の攻撃を特定し、特定した攻撃を前記コンピュータシステムが受けた時刻より後の期間を対象に当該ログを分析することを特徴とする請求項１から４のいずれかのログ分析装置。

【請求項6】

前記コンピュータシステムには、前記コンピュータシステムに含まれる複数のコンピュータと外部との通信を中継する中継装置が備えられ、
前記攻撃判定部は、前記ログデータベースに記憶されたログのうち、少なくとも前記中継装置のログを分析して、前記コンピュータシステムが前記関連攻撃抽出部により抽出された攻撃を受けていたかどうかを判定することを特徴とする請求項１から５のいずれかのログ分析装置。

【請求項7】

前記攻撃判定部は、前記ログデータベースに記憶されたログのうち、少なくとも前記コンピュータシステムに含まれる少なくとも１つのコンピュータのログを分析して、前記コンピュータシステムが前記関連攻撃抽出部により抽出された攻撃を受けていたかどうかを判定することを特徴とする請求項１から６のいずれかのログ分析装置。

【請求項8】

前記攻撃シナリオデータベースに記憶された攻撃シナリオでは、前記コンピュータシステムに対する複数の攻撃のそれぞれに対して点数が設定され、
前記攻撃判定部は、前記攻撃シナリオデータベースに記憶された攻撃シナリオで定義されている複数の攻撃のうち、前記検知装置により既に検知されている全ての攻撃を特定し、当該攻撃シナリオで、特定した攻撃に対して設定されている点数の合計と閾値との比較結果に基づいて、当該攻撃シナリオが実行されたかどうかを判定することを特徴とする請求項１から７のいずれかのログ分析装置。

【請求項9】

前記攻撃判定部は、攻撃の検知漏れが発生したと判断した場合、前記攻撃シナリオデータベースに記憶された攻撃シナリオで設定されている点数と前記閾値との少なくともいずれかを調整することを特徴とする請求項８のログ分析装置。

【請求項10】

前記攻撃判定部は、前記攻撃シナリオデータベースに記憶された攻撃シナリオが実行されたと判定した場合、当該攻撃シナリオで定義されている複数の攻撃のうち、前記検知装置により未だ検知されておらず、当該攻撃シナリオで定義されている順番が前記検知装置により最後に検知された攻撃よりも後の攻撃を抽出し、前記コンピュータシステムに対し、抽出した攻撃の経路となる通信を制限することを特徴とする請求項８又は９のログ分析装置。

【請求項11】

前記攻撃判定部は、前記攻撃シナリオデータベースに記憶された攻撃シナリオで定義されている複数の攻撃のうち、前記検知装置により未だ検知されておらず、当該攻撃シナリオで定義されている順番が前記検知装置により最後に検知された攻撃の１つ後の攻撃を抽出し、抽出した攻撃が前記検知装置により検知されない期間が閾値を超えた場合、当該攻撃シナリオが実行されなかったと判断することを特徴とする請求項１から７のいずれかのログ分析装置。

【請求項12】

前記攻撃シナリオデータベースに記憶された攻撃シナリオでは、前記コンピュータシステムに対する複数の攻撃のそれぞれに対して点数が設定され、
前記攻撃判定部は、前記攻撃シナリオデータベースに記憶された攻撃シナリオで定義されている複数の攻撃のうち、前記検知装置により既に検知されている全ての攻撃を特定し、当該攻撃シナリオで、特定した攻撃に対して設定されている点数の合計に応じて、前記閾値を調整することを特徴とする請求項１１のログ分析装置。

【請求項13】

前記攻撃シナリオデータベースに記憶された攻撃シナリオでは、前記コンピュータシステムに対する複数の攻撃のそれぞれに対して点数が設定され、
前記攻撃判定部は、前記攻撃シナリオデータベースに記憶された攻撃シナリオで、抽出した攻撃に対して設定されている点数に応じて、前記閾値を調整することを特徴とする請求項１１のログ分析装置。

【請求項14】

攻撃を検知する検知装置が備えられたコンピュータシステムのログを記憶するログデータベースと、前記コンピュータシステムを対象とする複数の攻撃と当該複数の攻撃の順番とを定義する攻撃シナリオを記憶する攻撃シナリオデータベースとを利用するログ分析方法であって、
関連攻撃抽出部が、前記攻撃シナリオデータベースに記憶された攻撃シナリオで定義されている複数の攻撃のうち、前記検知装置により未だ検知されておらず、当該攻撃シナリオで定義されている順番が前記検知装置により既に検知されている少なくとも１つの攻撃よりも前の攻撃を抽出し、
攻撃判定部が、前記ログデータベースに記憶されたログを分析して、前記コンピュータシステムが前記関連攻撃抽出部により抽出された攻撃を受けていたかどうかを判定し、受けていたと判定した場合に、攻撃の検知漏れが発生したと判断することを特徴とするログ分析方法。

【請求項15】

攻撃を検知する検知装置が備えられたコンピュータシステムのログを記憶するログデータベースと、前記コンピュータシステムを対象とする複数の攻撃と当該複数の攻撃の順番とを定義する攻撃シナリオを記憶する攻撃シナリオデータベースとを備えるコンピュータに、
前記攻撃シナリオデータベースに記憶された攻撃シナリオで定義されている複数の攻撃のうち、前記検知装置により未だ検知されておらず、当該攻撃シナリオで定義されている順番が前記検知装置により既に検知されている少なくとも１つの攻撃よりも前の攻撃を抽出する関連攻撃抽出処理と、
前記ログデータベースに記憶されたログを分析して、前記コンピュータシステムが前記関連攻撃抽出処理により抽出された攻撃を受けていたかどうかを判定し、受けていたと判定した場合に、攻撃の検知漏れが発生したと判断する攻撃判定処理と
を実行させることを特徴とするログ分析プログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、ログ分析装置及びログ分析方法及びログ分析プログラムに関するものである。本発明は、例えば、セキュリティログを分析することでサイバー攻撃の検知を行うセキュリティログ分析装置に関するものである。

【背景技術】

【0002】

近年、マルウェアが機密情報を組織外に漏洩させる事故が問題となっている。マルウェアを用いたサイバー攻撃は高度化されつつあり、例えば、非特許文献１に示されるＡＰＴ（高度かつ継続的な脅威：Ａｄｖａｎｃｅｄ・Ｐｅｒｓｉｓｔｅｎｔ・Ｔｈｒｅａｔ）と呼ばれる攻撃等がある。

【0003】

ＡＰＴでは、添付メール等で組織に侵入したマルウェアが、そのマルウェアに感染した計算機から、攻撃者が運用するインターネット上のＣ＆Ｃ（Ｃｏｍｍａｎｄ＆Ｃｏｎｔｒｏｌ）サーバと通信し、新しいマルウェアや攻撃ツールをダウンロードしたり、自身をアップデートしたりする。そして、マルウェアはＣ＆Ｃサーバから命令を受信して、組織内を偵察し、ファイルサーバを見つけ、機密ファイルをＣ＆Ｃサーバへ通信で漏洩させる。これらの各活動を、攻撃とみなした場合、各攻撃は、長時間かけて段階的に行われる。例えば、計算機に感染したマルウェアは、感染後、１ヵ月は活動せず身を潜め、１ヵ月後にＣ＆Ｃサーバと通信を開始する。このように、ＡＰＴでは、複数の攻撃が時間をおいて行われる。

【0004】

ＡＰＴの対策には、様々な方法がある。ＡＰＴ対策の製品として、メールによる侵入を防止する製品、情報漏洩を防止する製品等がある。また、ＡＰＴ対策の方法の１つとして自動的にログを分析する方法がある。自動的にログを分析する方法には、計算機、サーバ、ルータ等のネットワーク機器、ファイアウォール、侵入検知システム等のセキュリティ機器等のログを分析し、相互の相関関係を調べる、或いはログから異常な記録を見つけることでＡＰＴを検知する、或いは経過を観察する方法がある。

【0005】

ファイアウォール、或いは侵入検知システム等のセキュリティ機器のログ等の相関関係を調べることで自動的に異常を検知する製品の例として、ＳＩＥＭ（セキュリティ情報及びイベント管理：Ｓｅｃｕｒｉｔｙ・Ｉｎｆｏｒｍａｔｉｏｎ・ａｎｄ・Ｅｖｅｎｔ・Ｍａｎａｇｅｍｅｎｔ）システムがある（例えば、特許文献１参照）。統合ログ監視システム等と呼ばれることもある。

【0006】

また、各種ログを様々なキーワードでドリルダウンする、或いは時系列で状況変化を表示する等により、人間が異常を発見するログ分析システムがある。

【先行技術文献】

【特許文献】

【0007】

【特許文献1】特表２００４−５３７０７５号公報

【非特許文献】

【0008】

【非特許文献1】「新しいタイプの攻撃」の対策に向けた設計・運用ガイド、改訂第２版、ＩＰＡ、２０１１年１１月

【発明の概要】

【発明が解決しようとする課題】

【0009】

ＳＩＥＭシステムでは、オンメモリでリアルタイムにイベントを監視しているので、複雑な相関分析や多発するイベントの相関分析は実質的にはできないため、ＡＰＴに対して十分な対策がとれないという課題がある。

【0010】

また、ログ分析システムにおいては、蓄積されたログを様々な角度からインタラクティブに分析可能であるが、ＡＰＴのように複数の攻撃が時間をおいて進行するような場合は、具体的にどうやってログを分析すればよいかはオペレータの知見に依存してしまい、知見のあまりないオペレータの場合は検知漏れを起こしてしまう。

【0011】

つまり、ログを分析する方法によるＡＰＴの検知においては、ＳＩＥＭシステムもログ分析システムも、運用した場合にＡＰＴを検知漏れする可能性がある。

【0012】

ここで、ログ分析システムを運用する場合に、予め定義した攻撃シナリオに従ってログを検索してＡＰＴを検知しようという試みが考えられる。この方法では、オペレータの知見に依存しないでログを分析できる利点があるが、分析対象のログを出力するセキュリティ機器によっては、検知における機能の制限により検知漏れを起こすことがあり、その場合は攻撃シナリオに従ったＡＰＴとして検知できない課題がある。

【0013】

本発明は、例えば、攻撃シナリオに沿ってログを分析し、サイバー攻撃を検知する場合において、検知漏れを減らすことを目的とする。

【課題を解決するための手段】

【0014】

本発明の一の態様に係るログ分析装置は、
攻撃を検知する検知装置が備えられたコンピュータシステムのログを記憶するログデータベースと、
前記コンピュータシステムを対象とする複数の攻撃と当該複数の攻撃の順番とを定義する攻撃シナリオを記憶する攻撃シナリオデータベースと、
前記攻撃シナリオデータベースに記憶された攻撃シナリオで定義されている複数の攻撃のうち、前記検知装置により未だ検知されておらず、当該攻撃シナリオで定義されている順番が前記検知装置により既に検知されている少なくとも１つの攻撃よりも前の攻撃を抽出する関連攻撃抽出部と、
前記ログデータベースに記憶されたログを分析して、前記コンピュータシステムが前記関連攻撃抽出部により抽出された攻撃を受けていたかどうかを判定し、受けていたと判定した場合に、攻撃の検知漏れが発生したと判断する攻撃判定部とを備える。

【発明の効果】

【0015】

本発明では、攻撃シナリオで定義されている複数の攻撃のうち、未だ検知されておらず、当該攻撃シナリオで定義されている順番が既に検知されている少なくとも１つの攻撃よりも前の攻撃を抽出する。そして、ログを分析して、抽出された攻撃があったかどうかを判定し、あったと判定した場合に、攻撃の検知漏れが発生したと判断する。このため、本発明によれば、攻撃シナリオに沿ってログを分析し、サイバー攻撃を検知する場合において、検知漏れを減らすことが可能となる。

【図面の簡単な説明】

【0016】

【図1】実施の形態１に係るセキュリティログ分析装置の構成を示すブロック図。

【図2】実施の形態１に係る検知結果の構成の一例を示す図。

【図3】実施の形態１に係る攻撃シナリオの構成の一例を示す図。

【図4】実施の形態１に係るセキュリティ対策情報の構成の一例を示す図。

【図5】実施の形態１に係るインベントリ情報の構成の一例を示す図。

【図6】実施の形態１に係る攻撃判定部の攻撃判定処理を示すフローチャート。

【図7】実施の形態１に係る攻撃判定部の攻撃判定処理を示すフローチャート。

【図8】実施の形態１に係るログ検索部のログ検索処理の一例を示すフローチャート。

【図9】実施の形態１に係るログ検索部のログ検索処理の別の例を示すフローチャート。

【図10】実施の形態１に係る攻撃判定部の判定結果を示す表。

【図11】実施の形態２に係るセキュリティログ分析装置の構成を示すブロック図。

【図12】実施の形態５に係る攻撃シナリオのスコアの一例を示す表。

【図13】実施の形態７に係るメールアドレスの信頼度の一例を示す表。

【図14】実施の形態９に係る判定結果の一例を示す表。

【図15】実施の形態１０に係る制御命令の構成の一例を示す図。

【図16】実施の形態１〜１０に係るセキュリティログ分析装置のハードウェア構成の一例を示す図。

【発明を実施するための形態】

【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】

仕事の忙しさとミスに相関があると仮定して、「仕事が忙しい」であれば信頼度を中、「仕事は忙しくない」であれば信頼度は変更しない、としてもよい。体調とミスに相関があると仮定して、「体調不良」であれば信頼度を中、「健康」であれば信頼度は変更しない、としてもよい。

【0233】

勤続年数と慎重さに相関があると仮定して、勤続年数が長ければ信頼度は高とし、勤続年数が短ければ信頼度は中、としてもよい。

【0234】

平均受信メール数が多い場合や、様々な会社とメールを送受信している場合は、様々なメールを閲覧する機会があり、危険にさらされる機会が高いとみなし、信頼度を中としてもよい。このような「受信メールが多い」、「様々な会社とメールを送受信している」といった判断は、まず閾値を定めておき、１日にその閾値を越える数のメールを受信していれば「受信メールが多い」と判定し、或いは、１日にメールを送受信した社外の会社の数がその閾値を超えた場合に、「様々な会社とメールを送受信している」と判定すればよい。

【0235】

或いは、検索されたメールの送信時間が、ビジネスアワーの場合は、信頼度は変更せず、深夜の場合は、（疲労している可能性があるとして）信頼度を中としてもよい。

【0236】

（ｂ）メールの信頼性を調べる。

【0237】

まず、メールが添付メールの場合について説明する。

【0238】

添付メールの添付ファイルが暗号化されている場合は、添付ファイルのセキュリティスキャン等、セキュリティ対策を回避している可能性があるため、信頼度を低とする。

【0239】

次に、メールが、ＵＲＬが記載されたメールの場合について説明する。

【0240】

記載されたＵＲＬを、ウェブレピュテーションを利用して、その不審さを調べる。不審と判断されれば、メールの信頼度を低とする。或いは、そのメールを受信した端末Ｘについて、そのメールの受信時間から遡りｎ時間における、端末Ｘのウェブアクセスについて、プロキシログを検索し、該当のＵＲＬにアクセスしていなければ、初めてアクセスするウェブサイトと判断して信頼度を低としてもよい。つまり、メールに記載されたＵＲＬが、ウェブレピュテーションにより不審と判断されるか、初めてアクセスするサイトであれば、信頼度を低く設定するのである。メールに記載されたＵＲＬについて、ウェブレピュテーションの変わりに、組織で保有しているＵＲＬのホワイトリストに該当しないＵＲＬである場合、信頼度を低としてもよい。組織で保有しているＵＲＬのブラックリストに該当するＵＲＬである場合、信頼度を極低としてもよい。

【0241】

次に、メールが、電子署名が付与されたメールの場合について説明する。

【0242】

メールに電子署名が付与されており、その電子署名の正当性が検証された場合に、メールの信頼度を高としてもよい。また、その署名を検証する際に使用した電子証明書が、メールの受信者の組織で信頼しているものである場合に、メールの信頼度を高としてもよい。或いは、その電子証明書の信頼度のランクを定義しておき、あるランク以上の場合に信頼度を高としてもよい。例えば、電子証明書を発行する認証局によって、電子証明書内に、電子証明書の発行プロセスにおいて、電子証明書の発行先の組織や人物について厳密な審査を経たうえで電子証明書を発行していることを示す識別子を含めていることがあり、その識別子を電子証明書の信頼度として使用すればよい。

【0243】

最後に、メールが、暗号化されたメールの場合について説明する。

【0244】

メールが暗号化されている場合は、セキュリティスキャン等、セキュリティ対策を回避している可能性があるため、信頼度を低とする。

【0245】

以下では、攻撃Ａ１が（３）の場合について説明する。

【0246】

攻撃判定部１０７では、攻撃Ａ２が発見された端末Ｘの識別子をプロキシログから抽出し、攻撃Ａ２の検知前、過去ｍ時間遡り、この端末ＸがアクセスしたウェブサイトのＵＲＬをプロキシログから検索する（端末Ｘの識別子でログを検索すればよい）。次に、検索されたＵＲＬをウェブレピュテーションを利用して不審さを調べる。不審と判断されればこのＵＲＬの信頼度を低とする。そうでない場合は信頼度を高としてもよい。

【0247】

以下では、攻撃Ａ１が（４）の場合について説明する。

【0248】

攻撃判定部１０７では、攻撃Ａ２が発見された端末Ｘの識別子をプロキシログから抽出し、Ａ２の検知前、過去ｍ時間遡り、この端末Ｘが外部記憶媒体を使用した場合に、この外部記憶媒体の信頼度を低とする。端末Ｘが外部記憶媒体を使用したか否かは、端末操作ログを検索することで実現し、端末操作ログにおいて、端末Ｘの識別子をキーに、Ａ２の検知前、過去ｍ時間遡り、検索し、外部記憶媒体の接続の有無を調べる。また、端末の操作を記録するソフトウェアによっては、組織で管理されている外部記憶媒体とそうでないもの（個人で所有しているもの）を、外部記憶媒体のシリアルナンバーで識別する機能がある。組織で管理されている外部記憶媒体ではない外部記憶媒体を接続していることが分かった場合は、その外部記憶媒体の信頼度を低とし、組織で管理されている外部記憶媒体の場合に信頼度を高としてもよい。

【0249】

以下では、攻撃Ａ１が（５）の場合について説明する。

【0250】

攻撃判定部１０７では、攻撃Ａ２が発見された端末Ｘの識別子をプロキシログから抽出し、攻撃Ａ２の検知前、過去ｍ時間遡り、この端末Ｘが他の端末Ｙからアクセスされたかを調べ、アクセスがあった場合はこの端末Ｙの信頼度を低とする。端末Ｘが他の端末からアクセスされたかは、端末Ｘの端末操作ログやＯＳが保持するローカルファイアウォールの機能が記録するログにおいて攻撃Ａ２の検知前、過去ｍ時間遡り、検索し、他の端末からのアクセスの有無を調べる。端末Ｙが端末Ｘの複数のポート（ＴＣＰ／ＵＤＰのポート）にアクセスしている場合に（どのポートが開いているか探っていると判断して）、端末Ｙの信頼度を低とし、そうでない場合は、信頼度を高としてもよい。また、端末Ｙが端末Ｘにアクセスした時点の、端末Ｙにおけるパッチの適用履歴を、インベントリデータベース１１３から調べ、端末Ｙがその当時の最新のパッチが適用されていない場合に、端末Ｙの信頼度を低としてもよい。また、端末Ｘについて、その当時の最新のパッチが適用されていない場合に（端末Ｙから攻撃を受けて感染した恐れがあるとして）端末Ｙの信頼度を低としてもよい。或いは、攻撃Ａ２の検知前、過去ｍ時間遡り、端末Ｘから端末Ｙ’に対してアクセスした場合、この端末Ｙ’が、複数のポートにおいてアクセスされていたり、端末Ｙ’がその当時の最新のパッチが適用されていない場合に、端末Ｙ’の信頼度を低としてもよい。

【0251】

これらの例では、攻撃Ａ２が発見された場合に、各種ログを遡り、受信したメールの信頼度、アクセスしたＵＲＬの信頼度、使用した外部記憶媒体の信頼度、アクセスされた他の端末の信頼度を決定している。そして、このような信頼度が低の場合に、攻撃Ａ１に相当する攻撃があったと判断する。例えば、攻撃Ａ２の発生から遡り、信頼度が低いメールを受信した場合に、攻撃Ａ１の発生と判断する。

【0252】

また、これらの例において、攻撃Ａ１が発生したと判断するための事象がログから発見された場合（例えば、端末Ｘが添付メールを受信したことがメールサーバログから検索された場合（攻撃Ａ１が（１）））、その時点における、端末Ｘの最新パッチの適用状況を調べ、最新パッチが適用されていた場合は、各信頼度は高としてもよい。最新のパッチが適用されている場合は、仮に添付メール等が、マルウェアであっても、感染のリスクが低いからである。

【0253】

また、セキュリティ状態が組織内で統一的に管理されており、メールの送信元が同じ組織である場合、送信元のセキュリティ状態を参照してもよい。例えば、メールの送信日時におけるパッチの適用状況が最新ではない場合は、マルウェアに感染している可能性があるため、そのメールの信頼度を低としてもよい。もし、同じ組織からのメールでなくとも、何らかの手段で、その送信者のセキュリティ情報が参照できる場合は、同様の判断を行ってもよい。

【0254】

上記の信頼度は、高、中、低、極低等としたが、１００点、５０点、２０点、０点等の点数であってもよい。その場合は、例えば、暗号化された添付メールを受信していた場合、メールアドレスの信頼度が５０点、暗号化された添付メールが付与されているので信頼度を２０点として、合計の信頼度の閾値を１００点とした場合、合計７０点であり、信頼できないと判断してもよい。その場合、この暗号化された添付メールが攻撃Ａ２のきっかけとなった攻撃Ａ１であると判断する。

【0255】

上記のように、本実施の形態では、不審なＨＴＴＰ通信をログから検知した場合、その不審なＨＴＴＰ通信はマルウェア等の攻撃により発生しているとみなし、その攻撃が発生するきっかけを、様々なログを遡って調べることで、不審なＨＴＴＰ通信の原因があったか否か判断できる効果がある。

【0256】

実施の形態８．
本実施の形態について、主に実施の形態３との差異を説明する。

【0257】

実施の形態３では、プロキシログ等を分析した結果から、不審と判断された場合に、アクセスしたウェブサイトについてレピュテーション等を利用して不審か否かを判定した。本実施の形態では、このような不審なＨＴＴＰ通信が発見された場合に該当端末である端末Ｘのセキュリティ状態から、これらの通信が不審か否か判断する。この処理は、攻撃判定部１０７で実行される。

【0258】

ログデータベース１１４には、プロキシログが保存されているものとする。ログの検索は、攻撃判定部１０７がログ検索部１０８を使用してログデータベース１１４に対して行う。攻撃判定部１０７がインベントリデータベース１１３に格納された情報を参照する場合、（図示していないが）攻撃判定部１０７はインベントリ検索部１０６を利用してインベントリデータベース１１３の情報を検索し、参照する。

【0259】

実施の形態３でも同様であるが、例えば、以下に該当する通信についてプロキシログから検索された場合に不審とみなす。
・端末Ｘが、ホワイトリストにないＵＲＬであるＵＲＬ＿Ｓにアクセスしている。
・端末Ｘから、定期的にこのＵＲＬ＿Ｓにアクセスが行われている。

【0260】

本実施の形態では、さらに、以下の（１）〜（３）のいずれか１つ以上に当てはまる場合に、このＨＴＴＰ通信を不審と判断する。
（１）最初のＵＲＬ＿Ｓへのアクセスにおいて、遷移元のＵＲＬであるリファラを調べた結果、リファラが存在しない場合（単独の繰り返しの通信が突然発生したとみなす）、あるいは、リファラが存在しても、それ以前に、そのリファラのＵＲＬへアクセスしていない場合
（２）ＵＲＬ＿Ｓへアクセスした後にアクセスした別のＨＴＴＰ通信のリファラを調べた結果、このリファラがＵＲＬ＿Ｓになっていない場合（ＵＲＬ＿Ｓに関係ない別の通信が発生したとみなす）
（３）以下に説明する場合

【0261】

（３）については、ＵＲＬ＿Ｓへの通信の発生からｍ日遡り、端末Ｘのパッチの状態の履歴を調べる。この期間にリリースされたある１つのパッチＰａｔｃｈ＿ｉについて、ΔＴｉ＿Ｘ＝端末ＸにおけるＰａｔｃｈ＿ｉパッチ適用日時−Ｐａｔｃｈ＿ｉのパッチリリース日時、とした場合にΔＴｉ＿ＸはＰａｔｃｈ＿ｉがリリースされてから端末Ｘに適用されるまでの時間差である。そして、ΔＴｉ＿Ｘ＞ｎ時間である場合は、Ｐａｔｃｈ＿ｉについてパッチ未適用の期間があったとみなし、不審な通信と判断する。端末Ｘのパッチ適用履歴やパッチの情報は、インベントリデータベース１１３に格納されている。また、例えば、Ｐａｔｃｈ＿ｉ（ｉ＝１〜ｋ）について、ＡｌｌΔＴ＿Ｘ＝ΣΔＴｉ＿Ｘ、ｉ＝１〜ｋとして、ＡｌｌΔＴ＿Ｘ＜ｐ時間の場合に、安全な状態であったと判断し、ＨＴＴＰ通信は不審ではないと判断してもよい。例えば、ｋ＝３、ｐ＝４であれば、Ｐａｔｃｈ＿１、Ｐａｔｃｈ＿２、Ｐａｔｃｈ＿３が、ＵＲＬ＿Ｓへの最初の通信の発生からｍ日前までにリリースされており、それぞれのリリース日時から端末Ｘに適用した日時の差分であるΔＴ１＿Ｘ、ΔＴ２＿Ｘ、ΔＴ３＿Ｘを足した値が４時間未満であるという判断になる。この場合、各パッチがリリースされてから適用までの時間を、全て足しても４時間未満であるので、「端末Ｘは安全な状態を保っていた」と判断する。したがって、攻撃を受けていないと判断し、よって、このＨＴＴＰ通信は不審ではないと判断する。

【0262】

或いは、ΔＴｉ＿Ｘ、ｉ＝１〜ｋのうち、最大のものがｐ未満であった場合に、ＨＴＴＰ通信は不審ではないと判断してもよい。

【0263】

或いは、Ｐａｔｃｈ＿ｉ（ｉ＝１〜ｋ）について、パッチが対応する脆弱性のインパクトから、判定に用いるＰａｔｃｈ＿ｉを選択してもよい。例えば、ｉ＝１のパッチで対処される脆弱性はインパクトがＤｏＳであるとする。この脆弱性が攻撃された場合、端末のＣＰＵ（Ｃｅｎｔｒａｌ・Ｐｒｏｃｅｓｓｉｎｇ・Ｕｎｉｔ）の負荷が上がるだけであり、任意のコードを実行されたり、権限が昇格したりする等、それ以上の攻撃に発展する危険性がない。したがって、Ｐａｔｃｈ＿１は、上記の判定に使うパッチから除外してもよい。

【0264】

或いは、脆弱性への攻撃の難易度が高いものについて、そのパッチについては、判定で使わないようにしてもよい。難易度の例として、その脆弱性を攻撃する攻撃コードや攻撃方法が世の中に広まっているか否かがある。

【0265】

或いは、リモートからの攻撃ができる脆弱性、逆にローカルな攻撃が必要な脆弱性に対するパッチを判定で使わないようにしてもよい。

【0266】

或いは、攻撃に認証が必要な脆弱性に対するパッチを判定で使わないようにしてもよい。

【0267】

これらの脆弱性についての情報は、インターネット上のウェブサイトに公開されていることがあり、セキュリティログ分析装置１００が定期的にこのウェブサイトにアクセスして情報を取り込むことで、参照可能となる。脆弱性の情報はインベントリデータベース１１３に保存する。

【0268】

或いは、Ｐａｔｃｈ＿ｉ（ｉ＝１〜ｋ）について、Ｐａｔｃｈ＿ｉのパッチリリース日時から、端末ＸにおけるＰａｔｃｈ＿ｉパッチ適用日時の間の期間をＮＳＴ＿ｉとする。例えば、Ｐａｔｃｈ＿ｉのパッチリリース日時が２０１３／１０／２２の００：００：００、パッチ適用日時が２０１３／１０／２３の１２：００：００の場合、ＮＳＴ＿ｉ＝２０１３／１０／２２の００：００：００〜２０１３／１０／２３の１２：００：００となる。そして、ＮＳＴ＿ｉに、端末Ｘがウェブサイトへアクセスしたか否かをプロキシログから調べる。ＮＳＴ＿ｉに、端末Ｘがウェブサイトへアクセスした場合は、そのサイトのＵＲＬの不審さから、攻撃を受けたか否かを判定する。ＵＲＬの不審さは組織が持つＵＲＬのホワイトリストにないサイトや、ＵＲＬのブラックリストに掲載されているサイトや、ウェブレピュテーションによる判定から判断する。つまり、パッチが適用されていない期間であるＮＳＴ＿ｉに、ウェブサイトへアクセスした場合は、攻撃を受けた可能性があるため、そのＵＲＬの不審さをもって、攻撃を受けた可能性の有無を判定する。このとき、ＵＲＬのホワイトリスト／ブラックリストやウェブレピュテーションは、パッチが適用されていない期間のものを参照してもよく、最も新しいものを参照してもよい。或いは、これらの両方を参照してもよく、その場合、片方で不審と判断されたことで不審と判定してもよく、両方で不審と判断されたことで不審と判定してもよい。

【0269】

また、ＮＳＴ＿ｉに、端末Ｘがウェブサイトへアクセスした回数が予め定めた閾値未満の場合に、攻撃は受けていないと判定し、閾値以上の場合は、攻撃を受けたと判定してもよい。

【0270】

また、ＮＳＴ＿ｉに、端末Ｘがメールを受信した場合に、そのメールが不審であれば、攻撃を受けたとみなしてもよい。メールの不審さの判定には、実施の形態７と同様の方法を用いてもよい。

【0271】

また、ＮＳＴ＿ｉにおける、Ｐａｔｃｈ＿ｉが対処する脆弱性について、世の中の同脆弱性を狙った攻撃の発生数が別途定める閾値未満である場合は、攻撃を受けていないと判断し、閾値以上であれば、攻撃を受けたと判断してもよい。

【0272】

上記の例では、端末Ｘから、定期的にＵＲＬ＿Ｓにアクセスが行われていることをもって不審としたが、端末ＸからのＵＲＬ＿Ｓへのアクセスは、ランダムでもよい。ランダム性の判断は、ＵＲＬ＿Ｓへの１つのアクセスをＨＴＴＰ＿ｊとして、そのタイムスタンプをＨＴＴＰ＿ＴＳ＿ｊとして、時間的に隣り合うアクセス間の間隔を以下のΔｊで定義する。そして、Δｊがランダムか否かを調べればよい。
Δｊ＝ＨＴＴＰ＿ＴＳ＿（ｊ＋１）−ＨＴＴＰ＿ＴＳ＿ｊ（このとき、ｊ＝１〜ｈ）

【0273】

また、端末ＸからのＵＲＬ＿Ｓへのアクセスは、稀でもよい。稀かどうかを判断する方法は例えば以下である。
・ＵＲＬ＿Ｓへのアクセスが、α時間に、β回未満である。
・朝（９時〜１０時）α回、昼（１２時〜１３時）β回、夜（１７時〜１８時）γ回のように、ある期間に決まった回数アクセスする。

【0274】

また、上記の例では、端末Ｘにおけるパッチの適用状況を判断に用いたが、リリースされているパッチが端末Ｘに適用されていなくても、他のセキュリティ装置で（そのパッチが対応する）脆弱性への攻撃を防御できる場合があり、そのようなセキュリティ装置の設定履歴をセキュリティログ分析装置１００に取り込んで（例えば、インベントリデータベース１１３や攻撃判定部１０７で保存し）参照してもよい。例えば、端末Ｘにパッチ未適用の期間があり脆弱性が残存していても、このようなセキュリティ装置で防御されていた場合は、攻撃を受けていないと判断し、防御されていなかった場合は攻撃を受けていると判断してもよい。

【0275】

上記のように、本実施の形態では、不審なＨＴＴＰ通信がある端末で発見された場合に、該当端末のセキュリティ状態を過去に遡り調べることで、これらの通信が攻撃を受けたことにより発生したか否か判断できる効果がある。

【0276】

実施の形態９．
本実施の形態について、主に実施の形態８との差異を説明する。

【0277】

実施の形態８では、不審なＨＴＴＰ通信が検知された１台の端末について、このＨＴＴＰ通信が本当に不審か、セキュリティ状態を基に判断するが、本実施の形態では、複数の端末で、不審なＨＴＴＰ通信が検知された場合についての判断を行う。

【0278】

例えば、以下に該当する通信についてプロキシログから検索された場合に不審と判断する。
・端末Ｘと端末Ｙが、ホワイトリストにないＵＲＬであるＵＲＬ＿Ｓにアクセスしている。
・端末Ｘから、定期的にＵＲＬ＿Ｓにアクセスが行われている。
・端末Ｙから、定期的にＵＲＬ＿Ｓにアクセスが行われている。

【0279】

本実施の形態では、さらに、以下の（１）〜（３）のいずれか１つ以上に当てはまる場合に、このＨＴＴＰ通信を不審と判断する。
（１）端末Ｘの最初のＵＲＬ＿Ｓへのアクセスにおいて、遷移元のＵＲＬであるリファラを調べ、端末Ｙの最初のＵＲＬ＿Ｓへのアクセスにおいて、遷移元のＵＲＬであるリファラを調べた結果、端末Ｘと端末Ｙにおけるこれらのリファラが同じである場合
（２）端末Ｘにおいて、ＵＲＬ＿Ｓへアクセスした後にアクセスした別のＨＴＴＰ通信のリファラを調べ、端末Ｙにおいて、ＵＲＬ＿Ｓへアクセスした後にアクセスした別のＨＴＴＰ通信のリファラを調べた結果、これらのリファラがＵＲＬ＿Ｓになっていない場合
（３）端末ＸにおいてＵＲＬ＿Ｓへのアクセスの「前ｑ時間／後ｒ時間」にアクセスしているサイトをＵＲＬ＿Ｘとし、端末ＹにおいてＵＲＬ＿Ｓへのアクセスの「前ｑ時間／後ｒ時間」にアクセスしているサイトをＵＲＬ＿Ｙとしたとき、ＵＲＬ＿ＸとＵＲＬ＿Ｙがある一定の割合以上で一致する場合
（４）以下に説明する場合
（５）以下に説明する場合

【0280】

（４）については、端末Ｘと端末Ｙにおいて、パッチのリリース後、パッチが適用されていない期間があった場合に、その期間におけるウェブアクセスの有無を調べる。そして、このウェブアクセスが不審かウェブレピュテーションやＵＲＬホワイトリストやブラックリスト等で調べる。端末Ｘと端末Ｙにおけるこの期間におけるウェブアクセスの状態を比較することで、端末Ｘと端末Ｙが攻撃されたか否かを図１４のように判定してもよい。

【0281】

例えば、端末Ｘにおいてパッチ未適用の期間があり、かつ、不審ウェブアクセスがあった場合、端末Ｙにおいてパッチ未適用の期間があり、かつ、不審ウェブアクセスがあった場合、両端末で、安全でない期間に不審なウェブサイトにアクセスしていたので、マルウェアに感染し、その結果、後で、ＵＲＬ＿Ｓへ定期的にアクセスが発生したと判断する。

【0282】

例えば、端末Ｘにおいてパッチ未適用の期間があり、かつ、不審ウェブアクセスがなかった場合、端末Ｙにおいてパッチ未適用の期間があり、かつ、不審ウェブアクセスがあった場合、端末Ｙのみが、安全でない期間に不審なウェブサイトにアクセスしていたので、マルウェアに感染し、その結果、後で、ＵＲＬ＿Ｓへ定期的にアクセスが発生したと判断する。端末ＸにおけるＵＲＬ＿Ｓへの定期的な通信は誤検知とみなす。パッチ未適用の期間については、実施の形態８に従ってもよい。

【0283】

（５）については、パッチ未適用の期間があった場合に、その期間における不審なメールの受信の有無を調べる。そして、端末Ｘと端末Ｙにおけるこの期間における不審なメールの有無を比較することで、端末Ｘと端末Ｙが攻撃されたか否かを図１４のように判定してもよい。このとき、図１４における、「不審ウェブアクセス」を「不審メール」に置き換える。

【0284】

また、本実施の形態では、ログ分析のきっかけとする、端末Ｘと端末Ｙが行う不審なＨＴＴＰ通信先のＵＲＬについて、同じもの（ＵＲＬ＿Ｓ）としたが、別のＵＲＬでもよい（端末Ｘ：ＵＲＬ＿Ｓ、端末Ｙ：ＵＲＬ＿Ｓ’）。ただし、それらのＵＲＬはホワイトリストにないものである。

【0285】

また、本実施の形態では、パッチ未適用期間に端末ＸがアクセスしたＵＲＬは、ＵＲＬ＿Ｓであっても別のものでもよい。同様に、端末Ｙについても、パッチ未適用期間の通信についても、ＵＲＬ＿Ｓであっても別のものでもよい。

【0286】

また、本実施の形態では、ＵＲＬ＿ＳやＵＲＬ＿Ｓ’はホワイトリストにないものとしたが、ブラックリストにあるものとしてもよい。また、ウェブレピュテーションでスコアが閾値以下のものであってもよい。

【0287】

また、上記の例では、２つの端末Ｘ，Ｙを対象としているが、さらに複数の端末を対象としてもよい。

【0288】

上記のように、本実施の形態では、不審なＨＴＴＰ通信が複数の端末で発見された場合に、該当端末のセキュリティ状態を過去に遡り調べ、安全ではない期間に、不審なウェブサイトにアクセスしたり、不審なメールを受信したか調べることで、これらの通信が攻撃を受けたことにより発生したか否か判断できる効果がある。

【0289】

本実施の形態において、セキュリティ対策を管理していない組織においては、セキュリティ対策情報５００が検索されなかった場合の処理を行えばよい。また、インベントリを管理していない組織においては、インベントリ情報２０９が検索されなかった場合の処理を行えばよい。

【0290】

実施の形態１０．
本実施の形態について、主に実施の形態１との差異を説明する。

【0291】

本実施の形態では、攻撃シナリオ２０４に従って攻撃を検知した結果、情報漏洩の攻撃が疑われる、或いは、攻撃シナリオ２０４に従えば、今後起こり得ることが分かっている場合、セキュリティログ分析装置１００がプロキシサーバと連携して、強制的にＨＴＴＰ通信を制御する。

【0292】

図１５は、制御命令２１７の構成の一例を示す図である。

【0293】

攻撃判定部１０７は、例えば、実施の形態５のように現在検知された攻撃のスコア４０５の合計が閾値を超えた時点で、将来起こり得る攻撃に情報漏洩が含まれている場合は、制御命令２１７を生成し、出力部１０９に出力する。

【0294】

図１５に示すように、制御命令２１７は、以下の情報で構成される。
（ａ）期間：制御を行う期間（例えば、２０１３／１０／０１の００：００：００〜２０１３／１０／３１の２３：５９：５９）である。
（ｂ）送信元情報：攻撃判定部１０７が攻撃シナリオ２０４とログ分析により攻撃されている可能性があると判断した端末の情報（例えば、ＩＰアドレス）である。
（ｃ）送信先情報：攻撃判定部１０７が攻撃シナリオ２０４とログ分析により攻撃元と判断した通信相手の情報（例えば、ウェブサーバのホスト名）である。
（ｄ）制御情報：プロキシサーバに対する制御の命令である。

【0295】

制御命令２１７は、送信元情報で示される端末から送信先情報で示されるサーバ等への通信に対し、期間として指定する間、制御情報で示す制御を行うことを命令するデータである。制御情報の命令の内容として、例えば、ＨＴＴＰを全て遮断、ＨＴＴＰのＧＥＴを遮断、ＨＴＴＰのＰＯＳＴを遮断、ＣＯＮＮＥＣＴを遮断、認証の強制（ＨＴＴＰリクエストの送信のために認証情報を提供する）がある。また、これらに、「ｍ回につき１回の通信を遮断」、「ランダムに遮断」等の条件を組み合わせてもよい。例えば、制御情報は、「ＤｅｎｙＨＴＴＰ＝ＯＮ，Ｍｅｔｈｏｄ＝ＰＯＳＴ，ＣＯＮＤＩＴＩＯＮ＝１：ｍ」（ＨＴＴＰ通信のＰＯＳＴメソッドをｍ回につき１回遮断せよ、という意味である）といったものになる。

【0296】

送信先情報として、ＡＮＹ（全ての送信先）を指定して、攻撃されている可能性のある端末については全ての通信を制御してもよい。また、送信元情報として、ＡＮＹ（全ての送信元）を指定して、攻撃元が疑われる通信相手（例えば、ウェブサーバ）については、全ての端末からの通信を制御するようにしてもよい。

【0297】

出力部１０９は、制御命令２１７を受け取ると、プロキシサーバに出力する。プロキシサーバは制御命令２１７を入力すると、制御命令２１７を解釈して該当する通信を制御する。プロキシサーバにおける制御命令２１７の解釈は、これらのサーバに既に備わっている機能を使うことが望ましい。よって、制御命令２１７は、これらのサーバが解釈できるフォーマットに変形しても構わない。また、出力部１０９がプロキシサーバに制御命令２１７を出力する方法としては、プロキシサーバが入力可能な方法であれば任意の方法でよい。例えば、これらのサーバがＳＮＭＰ（Ｓｉｍｐｌｅ・Ｎｅｔｗｏｒｋ・Ｍａｎａｇｅｍｅｎｔ・Ｐｒｏｔｏｃｏｌ）のトラップメッセージを受信して、制御命令２１７を解釈できるのであれば、トラップメッセージに制御命令２１７を含めて、これらのサーバにネットワークを経由して送信してもよい。

【0298】

制御情報は、通信の遮断だけでなく、プロキシサーバがワークフローシステムと連携しているのであれば、このワークフローシステムの使用を強制するように指定してもよい。例えば、制御情報は、「ＵｓｅＷｏｒｋＦｌｏｗ＝ＯＮ，Ｐｒｏｔｏｃｏｌ＝ＨＴＴＰ，Ｍｅｔｈｏｄ＝ＰＯＳＴ」（ＨＴＴＰ通信のＰＯＳＴメソッドには、ワークフローを強制適用せよ、という意味である）といったものになる。

【0299】

ここでのワークフローシステムとは、あるユーザが、ウェブサイトへファイル等のデータを送信する場合に、上長の許可を得ないと送信できないような仕組みをもったシステムであり、例えば、以下のような手順が用いられる。
（１）ユーザＡが、ウェブサイトＸへ、ＨＴＴＰのＰＯＳＴで１メガバイトのファイルを送信する（ＨＴＴＰ・ＰＯＳＴリクエスト）。このＨＴＴＰ・ＰＯＳＴリクエストはプロキシサーバへ送信される。
（２）ユーザＡからのＨＴＴＰ・ＰＯＳＴリクエストはプロキシサーバと連携するワークフローシステムへフォワードされ、保留される。
（３）ワークフローシステムは、ユーザＡの上長Ｂへ、メールにより、ユーザＡが組織外へデータを送信しようとしていることを通知する。
（４）上長Ｂはワークフローシステムへアクセスし、該当するＨＴＴＰ・ＰＯＳＴリクエストを目視で確認する。宛先や送信データ（ファイル）に問題がなければ、ワークフロー上で許可する。
（５）ワークフローシステムは、上長Ｂからの許可が下りた場合、プロキシサーバへ該当するＨＴＴＰ・ＰＯＳＴリクエストをフォワードする。
（６）プロキシサーバは、該当するＨＴＴＰ・ＰＯＳＴリクエストをウェブサイトＸへ送信する。

【0300】

プロキシサーバは、制御命令２１７に「ＵｓｅＷｏｒｋＦｌｏｗ＝ＯＮ」が指定されていた場合は、ワークフローシステムへ該当するリクエストをフォワードし、ワークフローシステムの使用を強制する。この結果、例えば、マルウェアがＨＴＴＰのＰＯＳＴでデータを送信しようとしても、上長Ｂのチェックが入るため、不審なＰＯＳＴは防止される。

【0301】

プロキシサーバと検査サーバが連携しており、検査サーバにおいて、上記のような通信の制御を受け付けて、プロキシサーバを制御するのであれば、制御命令２１７を検査サーバに送信すればよく、そのフォーマットも検査サーバが解釈可能な形式にすればよい。プロキシサーバとワークフローシステムが連携しており、ワークフローシステムにおいて、上記のような通信の制御を受け付けて、プロキシサーバを制御するのであれば、制御命令２１７をワークフローシステムに送信すればよく、そのフォーマットもワークフローシステムが解釈可能な形式にすればよい。

【0302】

以上説明したように、本実施の形態において、攻撃判定部１０７は、攻撃シナリオデータベース１１１に記憶された攻撃シナリオ２０４が実行されたと判定した場合、当該攻撃シナリオ２０４で定義されている複数の攻撃のうち、上記コンピュータシステムに備えられた検知装置により未だ検知されておらず、当該攻撃シナリオ２０４で定義されている順番が上記検知装置により最後に検知された攻撃（例えば、攻撃Ａ４）よりも後の攻撃（例えば、攻撃Ａ５）を抽出し、上記コンピュータシステムに対し、抽出した攻撃の経路となる通信を制限する。

【0303】

上記のように、本実施の形態では、不審な攻撃シナリオ２０４に従い不審なＨＴＴＰ通信や今後の情報漏洩が疑われる場合、プロキシサーバや連携するワークフローシステムにＨＴＴＰ通信を制御する指示を送ることで、以後、ＨＴＴＰ通信を制御することで被害の拡大を抑制できる効果がある。

【0304】

図１６は、実施の形態１〜１０に係るセキュリティログ分析装置１００のハードウェア構成の一例を示す図である。

【0305】

図１６において、セキュリティログ分析装置１００は、コンピュータであり、出力装置９１０、入力装置９２０、記憶装置９３０、処理装置９４０といったハードウェアを備える。ハードウェアは、セキュリティログ分析装置１００の各部（本発明の実施の形態の説明において「〜部」として説明するもの）によって利用される。

【0306】

出力装置９１０は、例えば、ＬＣＤ（Ｌｉｑｕｉｄ・Ｃｒｙｓｔａｌ・Ｄｉｓｐｌａｙ）等の表示装置、プリンタ、通信モジュール（通信回路等）である。出力装置９１０は、各部（「〜部」）によってデータ、情報、信号の出力（送信）のために利用される。

【0307】

入力装置９２０は、例えば、キーボード、マウス、タッチパネル、通信モジュール（通信回路等）である。入力装置９２０は、各部（「〜部」）によってデータ、情報、信号の入力（受信）のために利用される。

【0308】

記憶装置９３０は、例えば、ＲＯＭ（Ｒｅａｄ・Ｏｎｌｙ・Ｍｅｍｏｒｙ）、ＲＡＭ（Ｒａｎｄｏｍ・Ａｃｃｅｓｓ・Ｍｅｍｏｒｙ）、ＨＤＤ（Ｈａｒｄ・Ｄｉｓｋ・Ｄｒｉｖｅ）、ＳＳＤ（Ｓｏｌｉｄ・Ｓｔａｔｅ・Ｄｒｉｖｅ）である。記憶装置９３０には、プログラム９３１、ファイル９３２が記憶される。プログラム９３１には、各部（「〜部」）の処理（機能）を実行するプログラムが含まれる。ファイル９３２には、各部（「〜部」）によって演算、加工、読み取り、書き込み、利用、入力、出力等が行われるデータ、情報、信号（値）等が含まれる。

【0309】

処理装置９４０は、例えば、ＣＰＵである。処理装置９４０は、バス等を介して他のハードウェアデバイスと接続され、それらのハードウェアデバイスを制御する。処理装置９４０は、記憶装置９３０からプログラム９３１を読み出し、プログラム９３１を実行する。処理装置９４０は、各部（「〜部」）によって演算、加工、読み取り、書き込み、利用、入力、出力等を行うために利用される。

【0310】

本発明の実施の形態の説明において「〜部」として説明するものは、「〜回路」、「〜装置」、「〜機器」であってもよく、また、「〜ステップ」、「〜工程」、「〜手順」、「〜処理」であってもよい。即ち、「〜部」として説明するものは、ソフトウェアのみ、ハードウェアのみ、或いは、ソフトウェアとハードウェアとの組み合わせで実現される。ソフトウェアは、プログラム９３１として、記憶装置９３０に記憶される。プログラム９３１は、本発明の実施の形態の説明で述べる「〜部」としてコンピュータを機能させるものである。或いは、プログラム９３１は、本発明の実施の形態の説明で述べる「〜部」の処理をコンピュータに実行させるものである。

【0311】

以上、本発明の実施の形態について説明したが、これらの実施の形態のうち、２つ以上を組み合わせて実施しても構わない。或いは、これらの実施の形態のうち、１つを部分的に実施しても構わない。或いは、これらの実施の形態のうち、２つ以上を部分的に組み合わせて実施しても構わない。例えば、これらの実施の形態の説明において「〜部」として説明するもののうち、いずれか１つのみを採用してもよいし、いずれか２つ以上の任意の組み合わせを採用してもよい。なお、本発明は、これらの実施の形態に限定されるものではなく、必要に応じて種々の変更が可能である。

【符号の説明】

【0312】

１００ セキュリティログ分析装置、１０１ 入力部、１０２ 解釈部、１０３ 攻撃シナリオ検索部、１０４ 関連攻撃抽出部、１０５ セキュリティ対策検索部、１０６ インベントリ検索部、１０７ 攻撃判定部、１０８ ログ検索部、１０９ 出力部、１１１ 攻撃シナリオデータベース、１１２ セキュリティ対策データベース、１１３ インベントリデータベース、１１４ ログデータベース、２０１ 検知データ、２０２ 検知情報、２０３ 攻撃識別情報、２０４ 攻撃シナリオ、２０５ 関連攻撃情報、２０６ 関連攻撃検索情報、２０７ 対策有無情報、２０８ インベントリ検索情報、２０９ インベントリ情報、２１３ ログ検索情報、２１４ 検索命令、２１５ 検索結果、２１６ 判定結果、２１７ 制御命令、３０１ 検知結果、３０２ シナリオ抽出条件、３０３ 関連攻撃抽出条件、３０４ 既検知結果、３０５ 検索条件、３１０ 判定結果、３２１ 公開脆弱性情報、３２２ 攻撃情報、３２３ 攻撃対応情報、３２４ 警告情報、４０１ 攻撃識別情報、４０２ 攻撃情報、４０３ 対策識別情報、４０４ 対策情報、４０５ スコア、５００ セキュリティ対策情報、５０１ 攻撃識別情報、５０２ 攻撃情報、５０３ 対策識別情報、５０４ 対策情報、５０５ 対策実施情報、６０１ 資産識別情報、６０２ 資産ＯＳ情報、６０３ 資産アプリケーション情報、６０４ 資産実行情報、６０５ 資産セキュリティ施策情報、９１０ 出力装置、９２０ 入力装置、９３０ 記憶装置、９３１ プログラム、９３２ ファイル、９４０ 処理装置。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】