(57)【要約】【課題】攻撃シナリオに沿ってログを分析し、サイバー攻撃を検知する場合において、検知漏れを減らす。【解決手段】セキュリティログ分析装置１００において、関連攻撃抽出部１０４は、攻撃シナリオ２０４で定義されている複数の攻撃のうち、コンピュータシステムに備えられた検知装置により未だ検知されておらず、当該攻撃シナリオ２０４で定義されている順番が上記検知装置により既に検知されている少なくとも１つの攻撃よりも前の攻撃を抽出する。攻撃判定部１０７は、上記コンピュータシステムのログを分析して、上記コンピュータシステムが関連攻撃抽出部１０４により抽出された攻撃を受けていたかどうかを判定し、受けていたと判定した場合に、攻撃の検知漏れが発生したと判断する。【選択図】図１
2015121968.tif 000002
【特許請求の範囲】
【請求項１】
攻撃を検知する検知装置が備えられたコンピュータシステムのログを記憶するログデータベースと、
前記コンピュータシステムを対象とする複数の攻撃と当該複数の攻撃の順番とを定義する攻撃シナリオを記憶する攻撃シナリオデータベースと、
前記攻撃シナリオデータベースに記憶された攻撃シナリオで定義されている複数の攻撃のうち、前記検知装置により未だ検知されておらず、当該攻撃シナリオで定義されている順番が前記検知装置により既に検知されている少なくとも１つの攻撃よりも前の攻撃を抽出する関連攻撃抽出部と、
前記ログデータベースに記憶されたログを分析して、前記コンピュータシステムが前記関連攻撃抽出部により抽出された攻撃を受けていたかどうかを判定し、受けていたと判定した場合に、攻撃の検知漏れが発生したと判断する攻撃判定部と
を備えることを特徴とするログ分析装置。
【請求項２】
前記検知装置に対して実施されているセキュリティ対策を示す情報を記憶するセキュリティ対策データベース
をさらに備え、
前記攻撃シナリオデータベースに記憶された攻撃シナリオでは、前記コンピュータシステムに対する複数の攻撃のそれぞれに対応するセキュリティ対策が定義され、
前記攻撃判定部は、前記セキュリティ対策データベースに記憶された情報を参照して、前記攻撃シナリオデータベースに記憶された攻撃シナリオで定義されている、前記関連攻撃抽出部により抽出された攻撃に対応するセキュリティ対策が前記検知装置に対して実施されているかどうかを判定し、実施されていると判定した場合に、前記コンピュータシステムが前記関連攻撃抽出部により抽出された攻撃を受けていたと判定した場合、前記検知装置における攻撃の検知漏れが発生したと判断することを特徴とする請求項１のログ分析装置。
【請求項３】
前記コンピュータシステムに含まれる複数のコンピュータと当該複数のコンピュータのそれぞれに対して実施されているセキュリティ対策を示す情報を記憶するインベントリデータベース
をさらに備え、
前記攻撃シナリオデータベースに記憶された攻撃シナリオでは、前記コンピュータシステムに対する複数の攻撃のそれぞれが対象とするコンピュータと当該複数の攻撃のそれぞれに対応するセキュリティ対策とが定義され、
前記攻撃判定部は、前記インベントリデータベースに記憶された情報を参照して、前記攻撃シナリオデータベースに記憶された攻撃シナリオで定義されている、前記関連攻撃抽出部により抽出された攻撃に対応するセキュリティ対策が、当該攻撃シナリオで定義されている、当該攻撃が対象とするコンピュータに対して実施されているかどうかを判定し、実施されていないと判定した場合に、前記ログデータベースに記憶されたログを分析することを特徴とする請求項１又は２のログ分析装置。
【請求項４】
前記攻撃シナリオデータベースに記憶された攻撃シナリオでは、前記コンピュータシステムに対する複数の攻撃のそれぞれが利用する脆弱性が定義され、
前記攻撃判定部は、脆弱性に関する情報を公開する外部のシステムにアクセスして、前記攻撃シナリオデータベースに記憶された攻撃シナリオで定義されている、前記関連攻撃抽出部により抽出された攻撃が利用する脆弱性に関する情報が当該外部のシステムにより公開されているかどうかを判定し、公開されていると判定した場合に、前記ログデータベースに記憶されたログを分析することを特徴とする請求項１から３のいずれかのログ分析装置。
【請求項５】
前記攻撃判定部は、前記ログデータベースに記憶されたログを分析する際に、前記攻撃シナリオデータベースに記憶された攻撃シナリオで定義されている複数の攻撃のうち、前記検知装置により既に検知されており、当該攻撃シナリオで定義されている順番が前記関連攻撃抽出部により抽出された攻撃の１つ前の攻撃を特定し、特定した攻撃を前記コンピュータシステムが受けた時刻より後の期間を対象に当該ログを分析することを特徴とする請求項１から４のいずれかのログ分析装置。
【請求項６】
前記コンピュータシステムには、前記コンピュータシステムに含まれる複数のコンピュータと外部との通信を中継する中継装置が備えられ、
前記攻撃判定部は、前記ログデータベースに記憶されたログのうち、少なくとも前記中継装置のログを分析して、前記コンピュータシステムが前記関連攻撃抽出部により抽出された攻撃を受けていたかどうかを判定することを特徴とする請求項１から５のいずれかのログ分析装置。
【請求項７】
前記攻撃判定部は、前記ログデータベースに記憶されたログのうち、少なくとも前記コンピュータシステムに含まれる少なくとも１つのコンピュータのログを分析して、前記コンピュータシステムが前記関連攻撃抽出部により抽出された攻撃を受けていたかどうかを判定することを特徴とする請求項１から６のいずれかのログ分析装置。
【請求項８】
前記攻撃シナリオデータベースに記憶された攻撃シナリオでは、前記コンピュータシステムに対する複数の攻撃のそれぞれに対して点数が設定され、
前記攻撃判定部は、前記攻撃シナリオデータベースに記憶された攻撃シナリオで定義されている複数の攻撃のうち、前記検知装置により既に検知されている全ての攻撃を特定し、当該攻撃シナリオで、特定した攻撃に対して設定されている点数の合計と閾値との比較結果に基づいて、当該攻撃シナリオが実行されたかどうかを判定することを特徴とする請求項１から７のいずれかのログ分析装置。
【請求項９】
前記攻撃判定部は、攻撃の検知漏れが発生したと判断した場合、前記攻撃シナリオデータベースに記憶された攻撃シナリオで設定されている点数と前記閾値との少なくともいずれかを調整することを特徴とする請求項８のログ分析装置。
【請求項１０】
前記攻撃判定部は、前記攻撃シナリオデータベースに記憶された攻撃シナリオが実行されたと判定した場合、当該攻撃シナリオで定義されている複数の攻撃のうち、前記検知装置により未だ検知されておらず、当該攻撃シナリオで定義されている順番が前記検知装置により最後に検知された攻撃よりも後の攻撃を抽出し、前記コンピュータシステムに対し、抽出した攻撃の経路となる通信を制限することを特徴とする請求項８又は９のログ分析装置。
【請求項１１】
前記攻撃判定部は、前記攻撃シナリオデータベースに記憶された攻撃シナリオで定義されている複数の攻撃のうち、前記検知装置により未だ検知されておらず、当該攻撃シナリオで定義されている順番が前記検知装置により最後に検知された攻撃の１つ後の攻撃を抽出し、抽出した攻撃が前記検知装置により検知されない期間が閾値を超えた場合、当該攻撃シナリオが実行されなかったと判断することを特徴とする請求項１から７のいずれかのログ分析装置。
【請求項１２】
前記攻撃シナリオデータベースに記憶された攻撃シナリオでは、前記コンピュータシステムに対する複数の攻撃のそれぞれに対して点数が設定され、
前記攻撃判定部は、前記攻撃シナリオデータベースに記憶された攻撃シナリオで定義されている複数の攻撃のうち、前記検知装置により既に検知されている全ての攻撃を特定し、当該攻撃シナリオで、特定した攻撃に対して設定されている点数の合計に応じて、前記閾値を調整することを特徴とする請求項１１のログ分析装置。
【請求項１３】
前記攻撃シナリオデータベースに記憶された攻撃シナリオでは、前記コンピュータシステムに対する複数の攻撃のそれぞれに対して点数が設定され、
前記攻撃判定部は、前記攻撃シナリオデータベースに記憶された攻撃シナリオで、抽出した攻撃に対して設定されている点数に応じて、前記閾値を調整することを特徴とする請求項１１のログ分析装置。
【請求項１４】
攻撃を検知する検知装置が備えられたコンピュータシステムのログを記憶するログデータベースと、前記コンピュータシステムを対象とする複数の攻撃と当該複数の攻撃の順番とを定義する攻撃シナリオを記憶する攻撃シナリオデータベースとを利用するログ分析方法であって、
関連攻撃抽出部が、前記攻撃シナリオデータベースに記憶された攻撃シナリオで定義されている複数の攻撃のうち、前記検知装置により未だ検知されておらず、当該攻撃シナリオで定義されている順番が前記検知装置により既に検知されている少なくとも１つの攻撃よりも前の攻撃を抽出し、
攻撃判定部が、前記ログデータベースに記憶されたログを分析して、前記コンピュータシステムが前記関連攻撃抽出部により抽出された攻撃を受けていたかどうかを判定し、受けていたと判定した場合に、攻撃の検知漏れが発生したと判断することを特徴とするログ分析方法。
【請求項１５】
攻撃を検知する検知装置が備えられたコンピュータシステムのログを記憶するログデータベースと、前記コンピュータシステムを対象とする複数の攻撃と当該複数の攻撃の順番とを定義する攻撃シナリオを記憶する攻撃シナリオデータベースとを備えるコンピュータに、
前記攻撃シナリオデータベースに記憶された攻撃シナリオで定義されている複数の攻撃のうち、前記検知装置により未だ検知されておらず、当該攻撃シナリオで定義されている順番が前記検知装置により既に検知されている少なくとも１つの攻撃よりも前の攻撃を抽出する関連攻撃抽出処理と、
前記ログデータベースに記憶されたログを分析して、前記コンピュータシステムが前記関連攻撃抽出処理により抽出された攻撃を受けていたかどうかを判定し、受けていたと判定した場合に、攻撃の検知漏れが発生したと判断する攻撃判定処理と
を実行させることを特徴とするログ分析プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ログ分析装置及びログ分析方法及びログ分析プログラムに関するものである。本発明は、例えば、セキュリティログを分析することでサイバー攻撃の検知を行うセキュリティログ分析装置に関するものである。
【背景技術】
【０００２】
近年、マルウェアが機密情報を組織外に漏洩させる事故が問題となっている。マルウェアを用いたサイバー攻撃は高度化されつつあり、例えば、非特許文献１に示されるＡＰＴ（高度かつ継続的な脅威：Ａｄｖａｎｃｅｄ・Ｐｅｒｓｉｓｔｅｎｔ・Ｔｈｒｅａｔ）と呼ばれる攻撃等がある。
【０００３】
ＡＰＴでは、添付メール等で組織に侵入したマルウェアが、そのマルウェアに感染した計算機から、攻撃者が運用するインターネット上のＣ＆Ｃ（Ｃｏｍｍａｎｄ＆Ｃｏｎｔｒｏｌ）サーバと通信し、新しいマルウェアや攻撃ツールをダウンロードしたり、自身をアップデートしたりする。そして、マルウェアはＣ＆Ｃサーバから命令を受信して、組織内を偵察し、ファイルサーバを見つけ、機密ファイルをＣ＆Ｃサーバへ通信で漏洩させる。これらの各活動を、攻撃とみなした場合、各攻撃は、長時間かけて段階的に行われる。例えば、計算機に感染したマルウェアは、感染後、１ヵ月は活動せず身を潜め、１ヵ月後にＣ＆Ｃサーバと通信を開始する。このように、ＡＰＴでは、複数の攻撃が時間をおいて行われる。
【０００４】
ＡＰＴの対策には、様々な方法がある。ＡＰＴ対策の製品として、メールによる侵入を防止する製品、情報漏洩を防止する製品等がある。また、ＡＰＴ対策の方法の１つとして自動的にログを分析する方法がある。自動的にログを分析する方法には、計算機、サーバ、ルータ等のネットワーク機器、ファイアウォール、侵入検知システム等のセキュリティ機器等のログを分析し、相互の相関関係を調べる、或いはログから異常な記録を見つけることでＡＰＴを検知する、或いは経過を観察する方法がある。
【０００５】
ファイアウォール、或いは侵入検知システム等のセキュリティ機器のログ等の相関関係を調べることで自動的に異常を検知する製品の例として、ＳＩＥＭ（セキュリティ情報及びイベント管理：Ｓｅｃｕｒｉｔｙ・Ｉｎｆｏｒｍａｔｉｏｎ・ａｎｄ・Ｅｖｅｎｔ・Ｍａｎａｇｅｍｅｎｔ）システムがある（例えば、特許文献１参照）。統合ログ監視システム等と呼ばれることもある。
【０００６】
また、各種ログを様々なキーワードでドリルダウンする、或いは時系列で状況変化を表示する等により、人間が異常を発見するログ分析システムがある。
【先行技術文献】
【特許文献】
【０００７】
【特許文献１】特表２００４−５３７０７５号公報
【非特許文献】
【０００８】
【非特許文献１】「新しいタイプの攻撃」の対策に向けた設計・運用ガイド、改訂第２版、ＩＰＡ、２０１１年１１月
【発明の概要】
【発明が解決しようとする課題】
【０００９】
ＳＩＥＭシステムでは、オンメモリでリアルタイムにイベントを監視しているので、複雑な相関分析や多発するイベントの相関分析は実質的にはできないため、ＡＰＴに対して十分な対策がとれないという課題がある。
【００１０】
また、ログ分析システムにおいては、蓄積されたログを様々な角度からインタラクティブに分析可能であるが、ＡＰＴのように複数の攻撃が時間をおいて進行するような場合は、具体的にどうやってログを分析すればよいかはオペレータの知見に依存してしまい、知見のあまりないオペレータの場合は検知漏れを起こしてしまう。
【００１１】
つまり、ログを分析する方法によるＡＰＴの検知においては、ＳＩＥＭシステムもログ分析システムも、運用した場合にＡＰＴを検知漏れする可能性がある。
【００１２】
ここで、ログ分析システムを運用する場合に、予め定義した攻撃シナリオに従ってログを検索してＡＰＴを検知しようという試みが考えられる。この方法では、オペレータの知見に依存しないでログを分析できる利点があるが、分析対象のログを出力するセキュリティ機器によっては、検知における機能の制限により検知漏れを起こすことがあり、その場合は攻撃シナリオに従ったＡＰＴとして検知できない課題がある。
【００１３】
本発明は、例えば、攻撃シナリオに沿ってログを分析し、サイバー攻撃を検知する場合において、検知漏れを減らすことを目的とする。
【課題を解決するための手段】
【００１４】
本発明の一の態様に係るログ分析装置は、
攻撃を検知する検知装置が備えられたコンピュータシステムのログを記憶するログデータベースと、
前記コンピュータシステムを対象とする複数の攻撃と当該複数の攻撃の順番とを定義する攻撃シナリオを記憶する攻撃シナリオデータベースと、
前記攻撃シナリオデータベースに記憶された攻撃シナリオで定義されている複数の攻撃のうち、前記検知装置により未だ検知されておらず、当該攻撃シナリオで定義されている順番が前記検知装置により既に検知されている少なくとも１つの攻撃よりも前の攻撃を抽出する関連攻撃抽出部と、
前記ログデータベースに記憶されたログを分析して、前記コンピュータシステムが前記関連攻撃抽出部により抽出された攻撃を受けていたかどうかを判定し、受けていたと判定した場合に、攻撃の検知漏れが発生したと判断する攻撃判定部とを備える。
【発明の効果】
【００１５】
本発明では、攻撃シナリオで定義されている複数の攻撃のうち、未だ検知されておらず、当該攻撃シナリオで定義されている順番が既に検知されている少なくとも１つの攻撃よりも前の攻撃を抽出する。そして、ログを分析して、抽出された攻撃があったかどうかを判定し、あったと判定した場合に、攻撃の検知漏れが発生したと判断する。このため、本発明によれば、攻撃シナリオに沿ってログを分析し、サイバー攻撃を検知する場合において、検知漏れを減らすことが可能となる。
【図面の簡単な説明】
【００１６】
【図１】実施の形態１に係るセキュリティログ分析装置の構成を示すブロック図。
【図２】実施の形態１に係る検知結果の構成の一例を示す図。
【図３】実施の形態１に係る攻撃シナリオの構成の一例を示す図。
【図４】実施の形態１に係るセキュリティ対策情報の構成の一例を示す図。
【図５】実施の形態１に係るインベントリ情報の構成の一例を示す図。
【図６】実施の形態１に係る攻撃判定部の攻撃判定処理を示すフローチャート。
【図７】実施の形態１に係る攻撃判定部の攻撃判定処理を示すフローチャート。
【図８】実施の形態１に係るログ検索部のログ検索処理の一例を示すフローチャート。
【図９】実施の形態１に係るログ検索部のログ検索処理の別の例を示すフローチャート。
【図１０】実施の形態１に係る攻撃判定部の判定結果を示す表。
【図１１】実施の形態２に係るセキュリティログ分析装置の構成を示すブロック図。
【図１２】実施の形態５に係る攻撃シナリオのスコアの一例を示す表。
【図１３】実施の形態７に係るメールアドレスの信頼度の一例を示す表。
【図１４】実施の形態９に係る判定結果の一例を示す表。
【図１５】実施の形態１０に係る制御命令の構成の一例を示す図。
【図１６】実施の形態１〜１０に係るセキュリティログ分析装置のハードウェア構成の一例を示す図。
【発明を実施するための形態】
【００１７】
以下、本発明の実施の形態について、図を用いて説明する。
【００１８】
実施の形態１．
図１は、本実施の形態に係るセキュリティログ分析装置１００の構成を示すブロック図である。
【００１９】
図１において、セキュリティログ分析装置１００は、ログ分析装置の一例であり、入力部１０１、解釈部１０２、攻撃シナリオ検索部１０３、関連攻撃抽出部１０４、セキュリティ対策検索部１０５、インベントリ検索部１０６、攻撃判定部１０７、ログ検索部１０８、出力部１０９を備える。また、セキュリティログ分析装置１００は、攻撃シナリオデータベース１１１（攻撃シナリオＤＢ）、セキュリティ対策データベース１１２（セキュリティ対策ＤＢ）、インベントリデータベース１１３（インベントリＤＢ）、ログデータベース１１４（ログＤＢ）を備える。
【００２０】
以下では、図１を用いて、セキュリティログ分析装置１００の動作（本実施の形態に係るログ分析方法、本実施の形態に係るログ分析プログラムの処理手順）の概要について説明する。
【００２１】
入力部１０１は、検知結果３０１を入力し、検知データ２０１を出力する。
【００２２】
解釈部１０２は、検知データ２０１を入力し、検知情報２０２とインベントリ検索情報２０８を出力する。
【００２３】
攻撃シナリオ検索部１０３は、検知情報２０２とシナリオ抽出条件３０２を入力し、攻撃識別情報２０３を出力して攻撃シナリオデータベース１１１を検索する。攻撃シナリオ検索部１０３は、検索結果である攻撃シナリオ２０４を入力する。また、攻撃シナリオ検索部１０３は、入力した攻撃シナリオ２０４を関連攻撃抽出部１０４と攻撃判定部１０７へ出力する。
【００２４】
攻撃シナリオデータベース１１１は、サイバー攻撃を実行する複数の攻撃のシーケンスを攻撃シナリオ２０４として保存する。攻撃シナリオ２０４は、監視対象のシステムに対して発生すると予測される複数の攻撃の各々を識別する複数の識別子を含むシナリオ情報である。
【００２５】
関連攻撃抽出部１０４は、関連攻撃抽出条件３０３を入力し、関連攻撃情報２０５をセキュリティ対策検索部１０５と、インベントリ検索部１０６と、攻撃判定部１０７へ出力する。
【００２６】
セキュリティ対策検索部１０５は、関連攻撃情報２０５を入力し、関連攻撃検索情報２０６を用いて、セキュリティ対策データベース１１２を検索する。そして、セキュリティ対策検索部１０５は、その検索結果である対策有無情報２０７を入力する。セキュリティ対策検索部１０５は、対策有無情報２０７を攻撃判定部１０７へ出力する。
【００２７】
セキュリティ対策データベース１１２は、侵入検知／防御装置等による攻撃への対策実施に関わる情報を保存する。
【００２８】
インベントリ検索部１０６は、インベントリ検索情報２０８と関連攻撃情報２０５を入力し、インベントリ検索情報２０８を用いてインベントリデータベース１１３を検索する。インベントリ検索部１０６は、その検索結果であるインベントリ情報２０９を入力する。
【００２９】
インベントリデータベース１１３は、ＰＣ（パーソナルコンピュータ）やサーバ等の資産ＩＤ（識別子）、ＩＰ（Ｉｎｔｅｒｎｅｔ・Ｐｒｏｔｏｃｏｌ）アドレス、使用ＯＳ（Ｏｐｅｒａｔｉｎｇ・Ｓｙｓｔｅｍ）やアプリケーション、パッチ適用状況等の情報を保存する。
【００３０】
攻撃判定部１０７は、インベントリ情報２０９と、関連攻撃情報２０５と、攻撃シナリオ２０４と、検知情報２０２と、対策有無情報２０７と、既検知結果３０４を入力し、ログ検索情報２１３をログ検索部１０８に出力する。また、攻撃判定部１０７は、ログ検索部１０８がログデータベース１１４を検索した結果である検索結果２１５を入力し、サイバー攻撃の発生を判定し、判定結果２１６を出力部１０９へ出力する。
【００３１】
ログデータベース１１４は、検索命令２１４を入力し、検索結果２１５を出力する。
【００３２】
出力部１０９は、判定結果２１６をセキュリティログ分析装置１００の外部へ判定結果３１０として出力する。
【００３３】
以下では、図１〜１０を用いて、セキュリティログ分析装置１００の動作の詳細について説明する。
【００３４】
入力部１０１は、検知結果３０１を入力する。
【００３５】
図２は、検知結果３０１の構成の一例を示す図である。
【００３６】
図２に示すように、検知結果３０１は、以下の内容がフォーマット化された情報である。
（ａ）日時：攻撃が発生した日時である。
（ｂ）攻撃ＩＤ：攻撃を識別する情報である。
（ｃ）攻撃種別：攻撃の種別（例えば、ＤｏＳ（Ｄｅｎｉａｌ・ｏｆ・Ｓｅｒｖｉｃｅ）攻撃、権限昇格等）である。
（ｄ）脆弱性ＩＤ：攻撃がソフトウェア等の脆弱性を悪用することで成り立つ場合、その識別情報（例えば、ＣＶＥ番号（脆弱性識別番号））である。
（ｅ）攻撃元情報：ソースＩＰ／ポート、資産ＩＤ等、攻撃元に関する情報である。
（ｆ）攻撃先情報：デスティネーションＩＰ／ポート、資産ＩＤ等、攻撃先に関する情報である。
【００３７】
このような情報は、例えば、ＩＰＳ（Ｉｎｔｒｕｓｉｏｎ・Ｐｒｅｖｅｎｔｉｏｎ・Ｓｙｓｔｅｍ）等のセキュリティ機器による攻撃の検知結果として通知される。
【００３８】
セキュリティログ分析装置１００は、検知結果３０１を、例えば、ＵＤＰ（Ｕｓｅｒ・Ｄａｔａｇｒａｍ・Ｐｒｏｔｏｃｏｌ）やＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ・Ｃｏｎｔｒｏｌ・Ｐｒｏｔｏｃｏｌ）パケットとして入力する。検知結果３０１は、パケットのボディ部に図２に示したような情報を格納する形でフォーマット化される。検知結果３０１は、セキュリティ機器のログファイルに記録されたログのエントリでもよい。また、検知結果３０１は、端末（以下では、「計算機」又は「コンピュータ」ということがある）の監査ログでもよい。その場合は、日時、端末ＩＤ、イベントＩＤで構成され、イベントＩＤで端末上の異常な行動（認証失敗）等が表される。検知結果３０１は、ログを分析する装置等においてプロキシログから通信の異常を分析し、その結果をログエントリにしたり、パケットで通知したりしたものでもよい。
【００３９】
入力部１０１は、（図２に示したような情報がフォーマット化されたデータである）検知結果３０１から、検知結果３０１がパケットの場合は、そのボディ部である検知データ２０１を、ログエントリの場合は、そのエントリである検知データ２０１を取り出し、解釈部１０２へ出力する。即ち、検知データ２０１とは、検知結果３０１のことである。
【００４０】
解釈部１０２は、検知結果３０１である検知データ２０１を入力する。解釈部１０２は、入力した検知データ２０１を、日時、攻撃ＩＤ、攻撃種別、脆弱性ＩＤ、攻撃元情報、攻撃先情報等の構成要素に分解する（解釈する）。解釈部１０２は、この結果を、検知情報２０２とし、攻撃シナリオ検索部１０３へ出力する。検知情報２０２の内容は、検知結果３０１の内容と同じである。
【００４１】
攻撃シナリオ検索部１０３は、検知情報２０２から、攻撃ＩＤ、攻撃種別、脆弱性ＩＤを抽出し、攻撃識別情報２０３として、攻撃シナリオデータベース１１１に出力する。このとき、攻撃シナリオ検索部１０３は、シナリオ抽出条件３０２を入力する。シナリオ抽出条件３０２とは、攻撃シナリオデータベース１１１から検索する攻撃シナリオ２０４の数を指定する条件である。シナリオ抽出条件３０２としては、例えば、１つ、複数、或いは指定された数を条件とする。ここでは、シナリオ抽出条件３０２は、攻撃シナリオデータベース１１１から検索する攻撃シナリオ２０４の数を「１つ」として指定するものとする。
【００４２】
攻撃シナリオデータベース１１１では、攻撃識別情報２０３に基づいて、攻撃ＩＤ、若しくは攻撃種別、若しくは脆弱性ＩＤが含まれる攻撃シナリオ２０４を検索する。
【００４３】
図３は、攻撃シナリオ２０４の構成の一例を示す図である。
【００４４】
図３に示すように、攻撃シナリオ２０４は、複数の攻撃シナリオ要素Ａｉのシーケンスであり、例えば、「攻撃シナリオ要素Ａ１→攻撃シナリオ要素Ａ２→攻撃シナリオ要素Ａ３→攻撃シナリオ要素Ａ４→攻撃シナリオ要素Ａ５」（ｉ＝１，２，３，４，５の場合）といった形で構成される。
【００４５】
攻撃シナリオ要素Ａｉ（ｉ＝１，２，３，４，５）は、１つ１つの攻撃の情報である。それぞれの攻撃シナリオ要素Ａｉ（ｉ＝１，２，３，４，５）は、攻撃識別情報４０１、攻撃情報４０２、対策識別情報４０３、対策情報４０４から構成される。
【００４６】
図３に示すように、攻撃識別情報４０１、攻撃情報４０２、対策識別情報４０３、対策情報４０４は、以下の情報である。
（ａ）攻撃識別情報４０１：攻撃ＩＤ、攻撃種別、脆弱性ＩＤを含む。
（ｂ）攻撃情報４０２：影響を受ける製品（製品ＩＤ、バージョン情報、パッチＩＤ）、必要とする実行権限、キーワード、その他の情報を含む。
（ｃ）対策識別情報４０３：対策ＩＤを含む。
（ｄ）対策情報４０４：パッチＩＤ、回避策ＩＤ、回避策内容、その他の情報を含む。
【００４７】
ここで、攻撃情報４０２のキーワードとは、攻撃発生において起こり得る事象を示すもので、例えば、ＯＳの設定の書き換えが発生するのであれば、キーワードは、「ＯＳ、ｃｏｎｆｉｇｕｒａｔｉｏｎ、ｍｏｄｉｆｙ」である。
【００４８】
図３に示す攻撃シナリオ２０４は、攻撃シナリオ要素Ａ１が最初に発生し、次に攻撃シナリオ要素Ａ２が発生し、次に攻撃シナリオ要素Ａ３が発生し、次に攻撃シナリオ要素Ａ４が発生し、次に攻撃シナリオ要素Ａ５が発生するというシナリオを示している。
【００４９】
過去の事例に基づき、上記のような攻撃シナリオ２０４が作成され、攻撃シナリオデータベース１１１に保存される。なお、攻撃シナリオ２０４を構成する攻撃シナリオ要素Ａｉは１つ以上であり、２つでも、３つでも、それ以上でも構わない。
【００５０】
攻撃シナリオ検索部１０３は、攻撃識別情報２０３を用いて、攻撃シナリオデータベース１１１を検索する。攻撃シナリオ検索部１０３は、例えば、攻撃識別情報２０３の構成要素である攻撃ＩＤが攻撃シナリオ要素Ａｉの攻撃識別情報４０１に含まれる攻撃シナリオ２０４を検索する。
【００５１】
攻撃シナリオ検索部１０３は、攻撃ＩＤで検索結果を得ることができなければ、脆弱性ＩＤや攻撃種別で検索する。攻撃シナリオ検索部１０３は、上記のようにして検索された結果を、攻撃シナリオ２０４として、攻撃シナリオデータベース１１１から抽出する。
【００５２】
以上のように、セキュリティログ分析装置１００は、検知結果３０１により通知された攻撃が含まれる攻撃シナリオ２０４を、攻撃シナリオデータベース１１１から抽出する。
【００５３】
攻撃シナリオ検索部１０３は、攻撃シナリオデータベース１１１から入力された攻撃シナリオ２０４を関連攻撃抽出部１０４へ出力する。
【００５４】
関連攻撃抽出部１０４は、攻撃シナリオ２０４を入力し、攻撃シナリオ２０４を分析する。関連攻撃抽出部１０４は、通知された攻撃シナリオ２０４に含まれる攻撃に関連する情報を抽出する。
【００５５】
このとき、関連攻撃抽出部１０４は、関連攻撃抽出条件３０３を入力する。関連攻撃抽出条件３０３とは、通知された攻撃以降に発生する攻撃の数としてｎ個（１〜ａｌｌ）を、又は、通知された攻撃以前に発生する攻撃の数としてｍ個（１〜ａｌｌ）を指定する条件である。
【００５６】
例えば、関連攻撃抽出条件３０３が、通知された攻撃以降に発生する攻撃の数として「１個」を指定するものである場合、通知された攻撃の次に起こる攻撃の情報のみを抽出する。「ａｌｌ」と指定された場合は、通知された攻撃の後に起こる全ての攻撃に関しての情報を抽出する。また、例えば、関連攻撃抽出条件３０３が、通知された攻撃以前に発生する攻撃の数として「１個」を指定するものである場合、通知された攻撃の前に起こる攻撃の情報のみを抽出する。「ａｌｌ」と指定された場合は、通知された攻撃の前に起こる全ての攻撃に関しての情報を抽出する。或いはこれらの組合せでもよい。或いは、攻撃シナリオ２０４の全ての情報を抽出してもよい（ｆｕｌｌ）。関連攻撃抽出部１０４により抽出される攻撃は、通知された攻撃の前後の時期において発生すると予測される分析対象攻撃の一例である。
【００５７】
ここでは、関連攻撃抽出条件３０３は、攻撃シナリオ２０４について「全ての情報を抽出する：ｆｕｌｌ」と指定されたものとする。
【００５８】
例えば、検知情報２０２に含まれる攻撃ＩＤが攻撃シナリオ要素Ａ４の攻撃ＩＤであるとする。攻撃シナリオ検索部１０３は、図３に示す攻撃シナリオ２０４を攻撃シナリオデータベース１１１から抽出する。そして、関連攻撃抽出部１０４は、関連攻撃抽出条件３０３「全ての情報を抽出する：ｆｕｌｌ」を入力し、攻撃シナリオ２０４から「攻撃シナリオ要素Ａ１→攻撃シナリオ要素Ａ２→攻撃シナリオ要素Ａ３→攻撃シナリオ要素Ａ４→攻撃シナリオ要素Ａ５」を抽出する。このように、関連攻撃抽出部１０４は、関連攻撃情報２０５を抽出する。
【００５９】
次に、関連攻撃抽出部１０４は、関連攻撃情報２０５をセキュリティ対策検索部１０５に出力する。セキュリティ対策検索部１０５は、入力した関連攻撃情報２０５を用いて、セキュリティ対策データベース１１２を検索する。具体的には、セキュリティ対策検索部１０５は、入力した関連攻撃情報２０５に含まれる「攻撃シナリオ要素Ａ１、攻撃シナリオ要素Ａ２、攻撃シナリオ要素Ａ３、攻撃シナリオ要素Ａ４、攻撃シナリオ要素Ａ５」を用いて、セキュリティ対策データベース１１２を検索する。
【００６０】
図４は、セキュリティ対策データベース１１２に格納されるセキュリティ対策情報５００の構成の一例を示す図である。
【００６１】
図４に示すように、セキュリティ対策情報５００は、攻撃識別情報５０１、攻撃情報５０２、対策識別情報５０３、対策情報５０４、対策実施情報５０５から構成される。攻撃識別情報５０１、攻撃情報５０２、対策識別情報５０３、対策情報５０４、対策実施情報５０５は、以下の情報である。
（ａ）攻撃識別情報５０１：攻撃ＩＤ、攻撃種別、脆弱性ＩＤを含む。
（ｂ）攻撃情報５０２：影響を受ける製品（製品ＩＤ、バージョン情報、パッチＩＤ）、必要とする実行権限、キーワード、その他の情報を含む。
（ｃ）対策識別情報５０３：対策ＩＤを含む。
（ｄ）対策情報５０４：シグネチャＩＤ（ＩＰＳのシグネチャ等）、ウイルスパタンファイルＩＤ、パッチＩＤ、回避策ＩＤ、回避策内容、その他の情報を含む。
（ｅ）対策実施情報５０５：対策実施の有無（現在、ＩＰＳ等で対策を実施しているか否か）を示す情報を含む。
【００６２】
セキュリティ対策検索部１０５は、入力した関連攻撃情報２０５を用いて、セキュリティ対策データベース１１２から対応するセキュリティ対策情報５００を抽出する。具体的には、セキュリティ対策検索部１０５は、入力した関連攻撃情報２０５に含まれる「攻撃シナリオ要素Ａ１、攻撃シナリオ要素Ａ２、攻撃シナリオ要素Ａ３、攻撃シナリオ要素Ａ４、攻撃シナリオ要素Ａ５」を構成する各々の攻撃識別情報４０１（つまり、攻撃シナリオ要素Ａ１の攻撃識別情報４０１、攻撃シナリオ要素Ａ２の攻撃識別情報４０１、攻撃シナリオ要素Ａ３の攻撃識別情報４０１、攻撃シナリオ要素Ａ４の攻撃識別情報４０１、攻撃シナリオ要素Ａ５の攻撃識別情報４０１）に含まれる攻撃ＩＤ或いは脆弱性ＩＤ或いは攻撃種別を含むセキュリティ対策情報５００のエントリをセキュリティ対策データベース１１２から抽出する。セキュリティ対策データベース１１２に保存されているセキュリティ対策情報５００には、攻撃識別情報５０１が含まれているが、この中に、攻撃ＩＤ、攻撃種別、脆弱性ＩＤが含まれており、上記の各攻撃シナリオ要素Ａｉの攻撃識別情報４０１に含まれる攻撃ＩＤ、若しくは攻撃種別、若しくは脆弱性ＩＤが、攻撃識別情報５０１に含まれるエントリを抽出すればよい。
【００６３】
セキュリティ対策検索部１０５は、前述のように抽出したセキュリティ対策情報５００と攻撃識別情報４０１を対にして、対策有無情報２０７を生成する。対策有無情報２０７には、攻撃シナリオ要素Ａ１の攻撃識別情報４０１とセキュリティ対策情報５００、攻撃シナリオ要素Ａ２の攻撃識別情報４０１とセキュリティ対策情報５００、攻撃シナリオ要素Ａ３の攻撃識別情報４０１とセキュリティ対策情報５００、攻撃シナリオ要素Ａ４の攻撃識別情報４０１とセキュリティ対策情報５００、攻撃シナリオ要素Ａ５の攻撃識別情報４０１とセキュリティ対策情報５００が含まれる。ここで、攻撃シナリオ要素Ａｉのセキュリティ対策情報５００とは、攻撃識別情報５０１が攻撃シナリオ要素Ａｉの攻撃識別情報４０１と一致するセキュリティ対策情報５００のことである。セキュリティ対策検索部１０５は、セキュリティ対策データベース１１２から抽出した対策有無情報２０７を攻撃判定部１０７へ出力する。
【００６４】
インベントリ検索部１０６は、解釈部１０２からインベントリ検索情報２０８を入力する。また、関連攻撃抽出部１０４から関連攻撃情報２０５を入力する。インベントリ検索情報２０８は、検知情報２０２（図２の検知結果３０１に相当）の一部の情報であり、攻撃先情報が該当する（攻撃種別によっては、攻撃元情報が該当する場合もある）。攻撃先情報は、デスティネーションＩＰ／ポート、資産ＩＤ等、攻撃先に関する情報である。この情報には複数の攻撃先（又は複数の攻撃元）の情報が含まれることがある（例えば、複数の端末への攻撃や、ネットワークへの攻撃等）。
【００６５】
インベントリ検索部１０６は、この攻撃先情報のうち、デスティネーションＩＰ（或いはＭＡＣ（Ｍｅｄｉａ・Ａｃｃｅｓｓ・Ｃｏｎｔｒｏｌ））、資産ＩＤ等、資産を特定できる情報を、検索用のインベントリ検索情報２０８とする。インベントリ検索部１０６は、同様に、入力された関連攻撃情報２０５において、資産を特定できる情報を、検索用のインベントリ検索情報２０８とする。インベントリ検索情報２０８は、複数の資産を特定できる情報となる場合がある（例えば、複数の端末への攻撃や、ネットワークへの攻撃等）。インベントリ検索部１０６は、検索用のインベントリ検索情報２０８をインベントリデータベース１１３に出力する。インベントリ検索部１０６は、インベントリ検索情報２０８（インベントリ（資産）を特定できる情報）を用いて、インベントリデータベース１１３を検索する。
【００６６】
インベントリ検索部１０６は、インベントリ検索情報２０８にマッチするエントリをインベントリデータベース１１３からインベントリ情報２０９として抽出する。
【００６７】
図５は、インベントリデータベース１１３で管理するインベントリ情報２０９の構成の一例を示す図である。
【００６８】
図５に示すように、インベントリ情報２０９は、資産識別情報６０１、資産ＯＳ情報６０２、資産アプリケーション情報６０３、資産実行情報６０４、資産セキュリティ施策情報６０５から構成される。インベントリ情報２０９を構成する、資産識別情報６０１、資産ＯＳ情報６０２、資産アプリケーション情報６０３、資産実行情報６０４、資産セキュリティ施策情報６０５は、例えば、以下の情報である。
（ａ）資産識別情報６０１：資産ＩＤ、ＩＰアドレス、ＭＡＣアドレス、ユーザＩＤを含む。
（ｂ）資産ＯＳ情報６０２：ＯＳ（製品ＩＤ、バージョン情報）、適用パッチ（パッチＩＤ）／適用回避策（回避策ＩＤ）に関する情報を含む。
（ｃ）資産アプリケーション情報６０３：アプリケーション（製品ＩＤ、バージョン情報）、適用パッチ（パッチＩＤ）／適用回避策（回避策ＩＤ）に関する情報を含む。
（ｄ）資産実行情報６０４：実行権限を示す情報を含む。
（ｅ）資産セキュリティ施策情報６０５：セキュリティ施策（セキュリティ設定、ソフトウェア等）に関する情報を含む。
【００６９】
インベントリデータベース１１３は、インベントリ検索情報２０８（攻撃先情報）のデスティネーションＩＰ（或いはＭＡＣ）／資産ＩＤが、資産識別情報６０１にマッチするエントリを、自身に保存しているエントリから検索し、インベントリ情報２０９としてインベントリ検索部１０６へ出力する。なお、攻撃種別によっては、インベントリ検索情報２０８が攻撃元情報（ソースＩＰ（或いはＭＡＣ）／資産ＩＤ）になる場合がある。
【００７０】
インベントリ検索部１０６は、インベントリデータベース１１３から入力したインベントリ情報２０９を攻撃判定部１０７へ出力する。
【００７１】
攻撃判定部１０７は、インベントリ情報２０９、関連攻撃情報２０５、攻撃シナリオ２０４、検知情報２０２、対策有無情報２０７、後に述べる既検知結果３０４を入力し、ログ検索情報２１３を出力する。攻撃判定部１０７は、攻撃判定処理を実行することにより、ログ検索情報２１３を出力する。
【００７２】
図６は、攻撃判定部１０７の攻撃判定処理を示すフローチャートである。
【００７３】
図６のＳ１１において、攻撃判定部１０７は、関連攻撃情報２０５に該当する攻撃の痕跡をログデータベース１１４から検索する。そのために、関連攻撃情報２０５からログデータベース１１４を検索するための情報であるログ検索情報２１３を生成し、ログ検索部１０８へ出力する。ログ検索部１０８は入力されたログ検索情報２１３から検索命令２１４を生成し、ログデータベース１１４へ出力する。その結果、ログデータベース１１４は、検索結果２１５をログ検索部１０８へ返す。ログ検索部１０８は、攻撃判定部１０７へ検索結果２１５を出力する。
【００７４】
図６のＳ１２において、攻撃判定部１０７は、検知情報２０２で通知された攻撃と、既に検知された攻撃を示す既検知結果３０４をタイムスタンプ（攻撃の発生に該当する日時）順にソートする。ここでは、既検知結果３０４の構成は、図２に示した検知結果３０１の構成と同じとする。
【００７５】
ここで、ある攻撃Ａ１，Ａ２の情報が既検知結果３０４として攻撃判定部１０７に与えられたとする。そして、攻撃Ａ４が検知結果３０１として入力部１０１に与えられたとする。この状況において、攻撃判定部１０７が、上記のようにソートした結果を以下とする。古いものから（左）、新しいもの（右）の順に並べて示す。
（１）攻撃Ａ１（既検知結果３０４より）、攻撃Ａ２（既検知結果３０４より）、攻撃Ａ４（検知情報２０２より）
【００７６】
図６のＳ１３において、攻撃判定部１０７は、攻撃シナリオ２０４を参照し、現在、既に検知した攻撃と照らし合わせて、検知が漏れた攻撃があるかを確認する。
【００７７】
図７は、図６のＳ１３の処理を示すフローチャートである。
【００７８】
図７のＳ２１において、攻撃判定部１０７は、攻撃シナリオ２０４の順番に攻撃が発生しているか調べる。攻撃シナリオ２０４が以下であったとする。
（２）攻撃Ａ１→攻撃Ａ２→攻撃Ａ３→攻撃Ａ４→攻撃Ａ５
【００７９】
そうすると、（１）に示された攻撃と比較して、攻撃シナリオ２０４に沿った場合、攻撃Ａ３の検知がないまま、攻撃Ａ４が検知されていることが分かる。したがって、攻撃判定部１０７は、「ＮＯ」と判定し、図７のＳ２２へ進む。「ＹＥＳ」の場合は、図７の処理を終了する。
【００８０】
図７のＳ２２において、攻撃判定部１０７は、既に検知すべき攻撃で未だ検知していない攻撃Ａｋの情報を参照する。この場合、ＡｋはＡ３である（ｋ＝３）。攻撃Ａ３の情報としては、攻撃シナリオ２０４の攻撃シナリオ要素Ａｉに含まれる情報を参照する。例えば、攻撃ＩＤである。
【００８１】
図７のＳ２３において、攻撃発生フラグＡ３＿ｏｃｃ、検知漏れ判定フラグＡ３＿ｅｖａを０に設定する（図７のＳ２２でｋ＝３としたため）。
【００８２】
図７のＳ２４において、攻撃判定部１０７は、攻撃Ａ３について監視対象のシステムのセキュリティ対策手段が対応しているか調べる。ここでは、例えば、ＩＰＳをセキュリティ対策手段として運用しているものとする。よって、ＩＰＳで対応しているかを調べる。図７のＳ２２で攻撃Ａ３に該当する攻撃ＩＤを参照しているので、対策有無情報２０７において、この攻撃ＩＤに該当するエントリがあるか調べる。対策有無情報２０７は、攻撃シナリオ要素Ａ１の攻撃識別情報４０１とセキュリティ対策情報５００、攻撃シナリオ要素Ａ２の攻撃識別情報４０１とセキュリティ対策情報５００、攻撃シナリオ要素Ａ３の攻撃識別情報４０１とセキュリティ対策情報５００、攻撃シナリオ要素Ａ４の攻撃識別情報４０１とセキュリティ対策情報５００、攻撃シナリオ要素Ａ５の攻撃識別情報４０１とセキュリティ対策情報５００である。攻撃シナリオ要素Ａ３の攻撃識別情報４０１には攻撃ＩＤが含まれており、攻撃Ａ３に該当する攻撃ＩＤが含まれている。次に、攻撃判定部１０７は、対となるセキュリティ対策情報５００を参照する。セキュリティ対策情報５００を構成する対策実施情報５０５が対策を実施していることを示していれば、ＩＰＳ等で攻撃Ａ３への対策が実施されていることになるため、攻撃判定部１０７は、「ＹＥＳ」と判定し、図７のＳ２５へ進む。対策が実施されていなければ、「ＮＯ」と判定し、図７のＳ２６へ進む。ここで、対策実施情報５０５には、対策情報５０４に示されるシグネチャＩＤやパッチＩＤや回避策ＩＤで示される対策が実施されているか否かが示されている。例えば、対策実施情報５０５は、「シグネチャＩＤ＝１２３４、対策実施＝実施済（若しくは、未実施）」、「パッチＩＤ＝５６７８、対策実施＝実施済（若しくは、未実施）」、「回避策ＩＤ＝９９９９、対策実施＝実施済（若しくは、未実施）」といった情報を含む。
【００８３】
図７のＳ２５において、攻撃判定部１０７は、Ａ３＿ｅｖａを１に設定し、図７のＳ２６へ進む。Ａ３＿ｅｖａ＝１は、ＩＰＳ等で対策を実施しているにも関わらず、検知していない（即ち、検知漏れ）という意味である。
【００８４】
図７のＳ２６において、攻撃判定部１０７は、攻撃Ａ３を受ける可能性のある計算機（端末）が存在するか調べる。そのためには、攻撃シナリオ２０４の攻撃シナリオ要素Ａ３に含まれる情報と、インベントリ情報２０９を参照する。攻撃シナリオ要素Ａ３の構成要素である攻撃情報４０２の、例えば、攻撃を受ける製品の情報が、インベントリ情報２０９において、資産ＯＳ情報６０２、及び資産アプリケーション情報６０３に該当するか調べる。該当する端末があれば、そのインベントリ情報２０９を参照する。該当する端末が複数あれば、複数の端末のインベントリ情報２０９を参照する。この場合、攻撃判定部１０７は、「ＹＥＳ」と判定し、図７のＳ２７に進む。該当するものがなければ攻撃判定部１０７は、「ＮＯ」と判定し、図７のＳ３２に進む。
【００８５】
図７のＳ２７において、攻撃判定部１０７は、攻撃Ａ３を受ける可能性のある端末において回避策があるか調べる。攻撃シナリオ要素Ａ３における対策情報４０４に回避策ＩＤが含まれるか調べる。あれば、攻撃判定部１０７は、「ＹＥＳ」と判定し、図７のＳ２８に進む。なければ、攻撃判定部１０７は、「ＮＯ」と判定し、図７のＳ２９へ進む。
【００８６】
図７のＳ２８において、攻撃判定部１０７は、回避策を実施しているか調べる。例えば、攻撃シナリオ要素Ａ３における対策情報４０４が、現在攻撃を受ける可能性がある計算機（端末）に対するインベントリ情報２０９における資産ＯＳ情報６０２、及び資産アプリケーション情報６０３における適用回避策に含まれているか否か調べる。含まれていれば、これらの端末において回避策が実施されていることになるので、攻撃判定部１０７は、「ＹＥＳ」と判定し、図７のＳ３２に進む。含まれていなければ、回避策が実施されていないことになるので、攻撃判定部１０７は、「ＮＯ」と判定し、図７のＳ２９へ進む。
【００８７】
図７のＳ２９において、攻撃判定部１０７は、ログ検索部１０８にログ検索処理を実行させることで、攻撃の痕跡を調査する。
【００８８】
図８は、図７のＳ２９のログ検索処理の一例を示すフローチャートである。
【００８９】
図８のＳ４１において、ログ検索部１０８は、変数ｐに１を設定する。
【００９０】
図８のＳ４２において、ログ検索部１０８は、ｐ≦ｎになっているか判定する。ここで、ｎは図８のＳ４３で呼び出すログ検索関数の数である。ｐ≦ｎであれば、ログ検索部１０８は、「ＹＥＳ」と判定し、図８のＳ４３へ進む。ｐ≦ｎでなければ、ログ検索部１０８は、「ＮＯ」と判定し、図８の処理を終了する。
【００９１】
図８のＳ４３において、ログ検索部１０８は、ログ検索関数ｆ＿ｐを呼び出す。このとき、関数のパラメータとして検索期間を指定するが、任意の期間を指定してもよいし、攻撃Ａ２の発生日時と攻撃Ａ４の発生日時の間の期間を指定してもよい。
【００９２】
図８のＳ４４において、ログ検索部１０８は、ログ検索関数ｆ＿ｐで攻撃の痕跡をログから抽出した場合は、「ＹＥＳ」と判定し、図８の処理を終了する。抽出しなかった場合は、「ＮＯ」と判定し、図８のＳ４５に進む。
【００９３】
図８のＳ４５において、ログ検索部１０８は、変数ｐに１を加え、図８のＳ４２に戻る。
【００９４】
このように、ログ検索部１０８は、予め用意したログ検索関数ｆ＿ｐを呼び出すことで攻撃の痕跡がログに残っているか検索する。この例では、ｎをログ検索関数ｆの数としているため、ｎ＝５であれば、ｆ＿１、ｆ＿２、ｆ＿３、ｆ＿４、ｆ＿５を呼び出すことになるが、他の方法で、ログ検索関数ｆを呼び出してもよい。
【００９５】
図９は、図７のＳ２９のログ検索処理の別の例を示すフローチャートである。
【００９６】
図９のＳ５１において、ログ検索部１０８は、ｑ＝１，３，５と指定し、変数ｐに１（ｑの最初の値）を指定する。
【００９７】
図９のＳ５２において、ログ検索部１０８は、ｐに全てのｑを指定したか判定する。全てのｑを指定していなければ、ログ検索部１０８は、「ＮＯ」と判定し、図９のＳ５３へ進む。全てのｑを指定していれば、ログ検索部１０８は、「ＹＥＳ」と判定し、図９の処理を終了する。
【００９８】
図９のＳ５３において、ログ検索部１０８は、図８のＳ４３と同様に、ログ検索関数ｆ＿ｐを呼び出す。
【００９９】
図９のＳ５４において、ログ検索部１０８は、図８のＳ４４と同様に、ログ検索関数ｆ＿ｐで攻撃の痕跡をログから抽出した場合は、「ＹＥＳ」と判定し、図９の処理を終了する。抽出しなかった場合は、「ＮＯ」と判定し、図９のＳ５５に進む。
【０１００】
図９のＳ５５において、ログ検索部１０８は、変数ｐにｑの次の値を指定し、図９のＳ５２に戻る。
【０１０１】
この例では、ｆ＿１、ｆ＿３、ｆ＿５を呼び出すことを予め決めているが、他の関数を呼び出すことを決めていてもよい。
【０１０２】
図７のＳ３０において、攻撃判定部１０７は、図７のＳ２９の処理の結果、攻撃の痕跡がログから見つかっていれば、攻撃が発生した可能性があるとして（「ＹＥＳ」と判定して）、図７のＳ３１に進む。このとき、攻撃Ａ３を識別する情報（攻撃ＩＤ等）、攻撃を受けた端末の情報（ログ検索関数ｆで検索したログエントリから得たＩＰアドレス等）、攻撃を発した計算機の情報（ログ検索関数ｆで検索したログエントリから得たＩＰアドレス等）、そして、攻撃の痕跡を見つけたログエントリの日時を検知日時として出力する。攻撃の痕跡がログから見つかっていなければ、「ＮＯ」と判定し、図７のＳ３２に進む。
【０１０３】
図７のＳ３１において、攻撃判定部１０７は、Ａ３＿ｏｃｃを１に設定する。Ａ３＿ｏｃｃ＝１は、ログの検索で攻撃が見つかったことを意味する。
【０１０４】
図７のＳ３２において、攻撃判定部１０７は、Ａ３＿ｏｃｃとＡ３＿ｅｖａの値から攻撃の発生について判断する。
【０１０５】
図１０は、Ａｋ＿ｏｃｃとＡｋ＿ｅｖａの値の組み合わせに対応する判定結果２１６を示す表である。
【０１０６】
図１０に示すように、攻撃判定部１０７は、Ｎｏ．１（Ａｋ＿ｏｃｃ＝０、Ａｋ＿ｅｖａ＝０）の場合、攻撃ＡｋにＩＰＳでは対応していないのでＩＰＳでは検知は発生せず、ログ分析でも攻撃Ａｋの痕跡を検知していないので、攻撃Ａｋは発生していないと判断する。
【０１０７】
攻撃判定部１０７は、Ｎｏ．２（Ａｋ＿ｏｃｃ＝０、Ａｋ＿ｅｖａ＝１）の場合、攻撃ＡｋにＩＰＳで対応しているがＩＰＳでは検知せず（もし攻撃Ａｋを検知している場合は、図７のＳ２１において「ＹＥＳ」になり、図７の処理を終わるため、図７のＳ２２には進まない）、ログ分析でも攻撃の痕跡を検知していないので、攻撃は発生していないと判断する。
【０１０８】
攻撃判定部１０７は、Ｎｏ．３（Ａｋ＿ｏｃｃ＝１、Ａｋ＿ｅｖａ＝０）の場合、攻撃ＡｋにＩＰＳでは対応していないので検知は発生していないが、ログ分析で攻撃の痕跡を検知しているので、攻撃Ａｋは発生したと判断する。
【０１０９】
攻撃判定部１０７は、Ｎｏ．４（Ａｋ＿ｏｃｃ＝１、Ａｋ＿ｅｖａ＝１）の場合、攻撃ＡｋにＩＰＳで対応しているがＩＰＳでは検知せず（もし攻撃Ａｋを検知している場合は、図７のＳ２１において「ＹＥＳ」になり、図７の処理を終わるため、図７のＳ２２には進まない）、ログ分析で攻撃の痕跡を検知しているので、攻撃は発生したと判断する。この場合は、本来ＩＰＳで検知すべき攻撃を検知漏れしており、ログ分析で検知漏れを回避したことになる。ＩＰＳでシグネチャ方式を採用している場合はシグネチャを回避するように攻撃が行われることがあり検知漏れが起こる。ＩＰＳで振る舞い検知を採用している場合は振る舞いの基準に満たない場合に検知漏れが起こる。
【０１１０】
以上の処理により、攻撃判定部１０７は、図６のＳ１３における結果として、図１０のＮｏ．１、Ｎｏ．２、Ｎｏ．３、Ｎｏ．４のいずれかの判定結果２１６を出力部１０９へ出力する。このとき、攻撃判定部１０７は、Ｎｏ．３、Ｎｏ．４の場合は、攻撃Ａ３を識別する情報（攻撃ＩＤ等）、攻撃を受けた端末の情報（ログ検索関数ｆで検索したログエントリから得たＩＰアドレス等）、攻撃を発した計算機の情報（ログ検索関数ｆで検索したログエントリから得たＩＰアドレス等）、そして、攻撃の痕跡を見つけたログエントリの日時を検知日時として判定結果２１６に含める。
【０１１１】
図７のＳ２９（つまり、図８又は図９）の処理において、ログ検索関数ｆは、ログデータベース１１４からログを検索する命令であるログ検索情報２１３をログ検索部１０８へ出力する。ログ検索部１０８は、ログ検索情報２１３を検索命令２１４に変換し、ログデータベース１１４へ出力する。ログデータベース１１４は、ログを検索し、その結果を検索結果２１５としてログ検索部１０８へ出力する。ログ検索部１０８は、検索結果２１５を攻撃判定部１０７へ出力する。検索命令２１４は、ログデータベース１１４に対して発行されるが、例えば、ＳＱＬクエリが該当する。検索結果２１５は、例えば、ＳＱＬレスポンスが該当する。検索条件３０５は、ログを検索する期間等のパラメータである。
【０１１２】
出力部１０９は、セキュリティログ分析装置１００の外部に、攻撃の判定結果２１６を判定結果３１０として出力する。例えば、判定結果３１０は、「攻撃情報＝Ａ３（攻撃ＩＤ＝１２３４）」、「攻撃を受けた端末＝１９２．１６８．１．１０」、「攻撃を発した端末＝１９２．１６８．１．５０」、「検知日時＝２０１３／９／２０の１２：００：００」、「検知状況＝ＩＰＳで検知していない。シグネチャは対応しているのでＩＰＳの検知漏れである。」といった情報を含む。なお、攻撃が、ある端末内の操作として検知された場合（例えば、設定を変更された等）は、攻撃を発した端末が攻撃を受けた端末と同一の場合がある。
【０１１３】
将来発生するであろう攻撃Ａ５については、例えば、その後、１０日後に検知結果３０１として通知されるかもしれない。或いは、検知結果３０１を待つのではなく、攻撃判定部１０７において、定期的にログ検索関数ｆを呼び出して、ログから攻撃の痕跡を検知することで攻撃Ａ５を検知してもよい。そして、最後の攻撃Ａ５を検知した段階で、攻撃シナリオに従ったサイバー攻撃が発生したことを、出力部１０９に出力し、出力部１０９は判定結果３１０としてセキュリティログ分析装置１００の外部へ出力してもよい。このとき、攻撃判定部１０７では、処理を行っていた検知結果３０１（検知情報２０２の元の情報）、既検知結果３０４、攻撃シナリオ２０４のセットについて、攻撃シナリオに従ったサイバー攻撃が発生したと判定した日時と、「処理済」という印（フラグ）を付与する。攻撃Ａ５を検知していない場合は、「処理中」という印（フラグ）のみを付与しておく。
【０１１４】
なお、上記の例では、既に検知した攻撃の情報を既検知結果３０４としてセキュリティログ分析装置１００の外部から与えたが、セキュリティログ分析装置１００が稼動し始めてから与えられた検知結果３０１（検知情報２０２）を攻撃判定部１０７が全て記憶していてもよく（既検知結果３０４として）、そのような運用の場合は、セキュリティログ分析装置１００の外部から既検知結果３０４を与えなくてよい。もし与えた場合は、攻撃判定部１０７は、セキュリティログ分析装置１００の外部から与えられた既検知結果３０４を破棄し、記憶している既検知結果３０４を用いてもよい。攻撃判定部１０７が記憶した検知結果３０１を（記憶した既検知結果３０４として）使用する場合の処理については、上記の説明において、既検知結果３０４を記憶した検知結果３０１に読み替えるものとする。また、攻撃判定部１０７が検知した判定結果２１６を既検知結果３０４として攻撃判定部１０７が全て記憶していてもよい。
【０１１５】
上記の例では、セキュリティ対策手段の例としてＩＰＳを用いているが、他のセキュリティ対策手段、例えば、ファイアウォール、アンチウイルスソフトウェア、セキュリティサーバ等を用いても構わない。
【０１１６】
上記の例では、攻撃シナリオ２０４の１つの攻撃（攻撃Ａ３）のみが発生していないが、攻撃シナリオ２０４の複数の攻撃が発見されていない場合は、攻撃Ａ３の痕跡を見つけるための攻撃判定部１０７の処理を、発見されていない攻撃の各々に適用すればよい。例えば、攻撃シナリオ２０４が、「攻撃Ａ１’→Ａ２’→Ａ３’→Ａ４’→Ａ５’→Ａ６’→Ａ７’」であり、セキュリティログ分析装置１００に入力された検知結果３０１に基づき、この攻撃シナリオ２０４が抽出されたとする。現在検知している攻撃が、既検知結果３０４、検知結果３０１から、攻撃Ａ１’、攻撃Ａ４’、攻撃Ａ５’、攻撃Ａ６’であるとする。このとき、攻撃Ａ２’と攻撃Ａ３’の各々に対して、上記の例で攻撃Ａ３に対して攻撃判定部１０７が行った処理と同様の処理を実施する。或いは、例えば、この攻撃シナリオ２０４において、現在検知している攻撃が、既検知結果３０４、検知結果３０１から、攻撃Ａ２’、攻撃Ａ３’、攻撃Ａ５’であるとする。このとき、攻撃Ａ１’と攻撃Ａ４’の各々に対して、上記の例で攻撃Ａ３に対して攻撃判定部１０７が行った処理と同様の処理を実施する。攻撃Ａ１’のように、過去に遡って検索する場合は、予めその検索期間（例えば、ｍ日とする）を攻撃判定部１０７に保持し、攻撃Ａ２’の発生前のｍ日について遡り検索すればよい。
【０１１７】
上記の例では、攻撃シナリオ検索部１０３は、検知結果３０１に基づいた検知情報２０２に該当する攻撃を含む攻撃シナリオ２０４を検索した。ここで、仮に、「新しくセキュリティログ分析装置１００で受け付けられた検知結果３０１の攻撃ＩＤ、攻撃種別、脆弱性ＩＤ等の攻撃を示す情報と、攻撃元情報・攻撃先情報」が同じ検知結果３０１又は既検知結果３０４が既にセキュリティログ分析装置１００に保存されているとする。さらに、これらについて、攻撃判定部１０７で「処理中」の攻撃シナリオ２０４がある場合は、既にセキュリティログ分析装置１００に通知され、攻撃シナリオ２０４に従った検知が処理されている攻撃が「繰り返し」発生していると判定して、無視してもよい。この判定は、攻撃判定部１０７において、入力された検知情報２０２（検知結果３０１を元とする情報）と、既検知結果３０４と、これらに対応する処理中の攻撃シナリオ２０４をセットで保存し、「処理中」のフラグを付与しておき、検知結果３０１が新たに与えられ、検知情報２０２として攻撃判定部１０７に入力された場合に、この保存された情報を用いて判定すればよい。
【０１１８】
なお、ログを検索する場合、ある特定の攻撃については特定のログに記録されることが予め分かっている場合は、攻撃シナリオ要素Ａｉの対策情報４０４の「その他情報」において、記録されるログの情報を含めてもよい。例えば、攻撃Ａ２については、ＩＰＳログ、プロキシログを検索するという情報を、「ＬｏｇＴｏＢｅＩｎｓｐｅｃｔｅｄ＝ＩＰＳ，Ｐｒｏｘｙ」、或いは、より具体的に、ログの記録される機器の識別番号を含めて「ＬｏｇＴｏＢｅＩｎｓｐｅｃｔｅｄ＝ＩＰＳ＿１２３４，Ｐｒｏｘｙ＿５６７８」といった形で、対策情報４０４の「その他情報」に含めてもよい。攻撃判定部１０７は、この情報をパラメータとして検索関数ｆを呼び出す。
【０１１９】
また、ログを検索する場合、ある特定の攻撃についてはどの検索関数ｆを呼び出せばよいか予め分かっている場合は、攻撃シナリオ要素Ａｉの対策情報４０４の「その他情報」において、使用する関数の情報を含めてもよい。例えば、攻撃Ａ２については、ｆ１、ｆ２を使用するという情報を、「ＵｓｅＦｕｎｃｔｉｏｎ＝ｆ１，ｆ２」といった形で、対策情報４０４の「その他情報」に含めてもよい。攻撃判定部１０７はこの情報に従い指定された関数を用いる。
【０１２０】
本実施の形態では、図７のＳ２６で「ＮＯ」、図７のＳ２８で「ＹＥＳ」の場合は、図７のＳ２９の処理を省略しているが、未検知の攻撃Ａｋがある場合は、必ず図７のＳ２９の処理を実行してログを分析するようにしてもよい。
【０１２１】
以上説明したように、本実施の形態において、ログデータベース１１４は、攻撃を検知する検知装置（例えば、ＩＰＳ）が備えられたコンピュータシステム（即ち、監視対象のコンピュータシステム）のログを記憶する。攻撃シナリオデータベース１１１は、上記コンピュータシステムを対象とする複数の攻撃と当該複数の攻撃の順番とを定義する攻撃シナリオ２０４を記憶する。関連攻撃抽出部１０４は、攻撃シナリオデータベース１１１に記憶された攻撃シナリオ２０４で定義されている複数の攻撃（例えば、攻撃Ａ１〜Ａ５）のうち、上記検知装置により未だ検知されておらず、当該攻撃シナリオ２０４で定義されている順番が上記検知装置により既に検知されている少なくとも１つの攻撃（例えば、攻撃Ａ４）よりも前の攻撃（例えば、攻撃Ａ３）を抽出する。攻撃判定部１０７は、ログデータベース１１４に記憶されたログを分析して、上記コンピュータシステムが関連攻撃抽出部１０４により抽出された攻撃を受けていたかどうかを判定し、受けていたと判定した場合に、攻撃の検知漏れが発生したと判断する。このため、本実施の形態によれば、例えば、ＩＰＳで攻撃の検知漏れが発生しても、攻撃シナリオ２０４に沿ってログを分析することで、その攻撃を検知することができるため、結果的に検知漏れを減らすことが可能となる。
【０１２２】
また、本実施の形態において、セキュリティ対策データベース１１２は、上記検知装置に対して実施されているセキュリティ対策を示す情報を記憶する。攻撃シナリオデータベース１１１に記憶された攻撃シナリオ２０４では、上記コンピュータシステムに対する複数の攻撃のそれぞれに対応するセキュリティ対策が定義される。攻撃判定部１０７は、セキュリティ対策データベース１１２に記憶された情報を参照して、攻撃シナリオデータベース１１１に記憶された攻撃シナリオ２０４で定義されている、関連攻撃抽出部１０４により抽出された攻撃に対応するセキュリティ対策が上記検知装置に対して実施されているかどうかを判定し、実施されていると判定した場合に、上記コンピュータシステムが関連攻撃抽出部１０４により抽出された攻撃を受けていたと判定した場合、上記検知装置における攻撃の検知漏れが発生したと判断する。このため、本実施の形態によれば、例えば、攻撃の検知漏れが発生した場合に、それがＩＰＳで発生したものかどうかを判断することが可能となる。
【０１２３】
また、本実施の形態において、インベントリデータベース１１３は、上記コンピュータシステムに含まれる複数のコンピュータと当該複数のコンピュータのそれぞれに対して実施されているセキュリティ対策を示す情報を記憶する。攻撃シナリオデータベース１１１に記憶された攻撃シナリオ２０４では、上記コンピュータシステムに対する複数の攻撃のそれぞれが対象とするコンピュータと当該複数の攻撃のそれぞれに対応するセキュリティ対策とが定義される。攻撃判定部１０７は、インベントリデータベース１１３に記憶された情報を参照して、攻撃シナリオデータベース１１１に記憶された攻撃シナリオ２０４で定義されている、関連攻撃抽出部１０４により抽出された攻撃に対応するセキュリティ対策が、当該攻撃シナリオ２０４で定義されている、当該攻撃が対象とするコンピュータに対して実施されているかどうかを判定し、実施されていないと判定した場合に、ログデータベース１１４に記憶されたログを分析する。このため、本実施の形態によれば、例えば、攻撃を受ける可能性がない（又は低い）場合、攻撃の検知漏れが発生していないか確認するためにログを分析する処理を省略することで、効率性を向上させることができる。
【０１２４】
また、本実施の形態において、攻撃判定部１０７は、ログデータベース１１４に記憶されたログを分析する際に、攻撃シナリオデータベース１１１に記憶された攻撃シナリオ２０４で定義されている複数の攻撃のうち、上記検知装置により既に検知されており、当該攻撃シナリオ２０４で定義されている順番が関連攻撃抽出部１０４により抽出された攻撃（例えば、攻撃Ａ３）の１つ前の攻撃（例えば、攻撃Ａ２）を特定し、特定した攻撃を上記コンピュータシステムが受けた時刻より後の期間を対象に当該ログを分析する。このため、本実施の形態によれば、ログで分析対象とする範囲を限定できるため、効率性を向上させることができる。
【０１２５】
本実施の形態では、セキュリティログ分析装置１００は、攻撃シナリオ２０４と既に検知した攻撃の情報に基づき、本来発生している可能性があるが検知されていない攻撃について、ログ分析で攻撃の発生の有無を調べ、さらに既存のセキュリティ対策による検知漏れも判定できる。セキュリティ対策を行う組織の管理者は、この判定を用いることで、本来発生している可能性があるが検知されていない攻撃について、本当に発生していないかどうか判定でき、さらに、発生していた場合は、既存のセキュリティ対策の不備について情報を得ることができ、既存のセキュリティ対策を見直すことが可能となる。
【０１２６】
実施の形態２．
本実施の形態について、主に実施の形態１との差異を説明する。
【０１２７】
実施の形態１では、セキュリティログ分析装置１００は、セキュリティ対策データベース１１２に格納している「現在適用しているセキュリティ対策手段（実施の形態１では一例としてＩＰＳ）の情報」を参照した。そして、攻撃シナリオ２０４に従えば既に発生しているはずだが未だ検知していない攻撃（実施の形態１では一例として攻撃Ａ３）について「現在適用しているセキュリティ対策」で「検知しているべき」か判定した（図７）。
【０１２８】
本実施の形態では、既に世の中に公開されている脆弱性や攻撃情報について、セキュリティ対策の機器（ＩＰＳ等）やソフトウェアが対応しているか（検知できるか）を攻撃判定部１０７で調べ、既に発生しているはずの攻撃についてセキュリティ対策の機器での対応の可否について判定し、ログ分析をより詳細に実施する。
【０１２９】
図１１は、本実施の形態に係るセキュリティログ分析装置１００の構成を示すブロック図である。
【０１３０】
図１１において、攻撃判定部１０７は、セキュリティログ分析装置１００の外部から、公開脆弱性情報３２１や攻撃情報３２２を入力する。
【０１３１】
公開脆弱性情報３２１は、ＮＩＳＴ（米国の国立標準技術研究所）のＮＶＤ（Ｎａｔｉｏｎａｌ・Ｖｕｌｎｅｒａｂｌｉｔｙ・Ｄａｔａｂａｓｅ）等で公開されている、ソフトウェアの脆弱性情報である。この脆弱性情報には、一般的に、脆弱性の識別番号が付与される。例えば、ＣＶＥ（Ｃｏｍｍｏｎ・Ｖｕｌｎｅｒａｂｉｌｉｔｉｅｓ・ａｎｄ・Ｅｘｐｏｓｕｒｅｓ）番号である。公開脆弱性情報３２１は、１種類以上の脆弱性情報（エントリ）で構成される。
【０１３２】
攻撃情報３２２は、「公開脆弱性情報３２１を悪用した攻撃で既に被害が報告されている攻撃」や、「未だ被害が報告されていないが、公開脆弱性情報３２１を悪用した攻撃として今後発生が予想される攻撃」の情報である。攻撃情報３２２は、攻撃ＩＤで識別される１種類以上の情報（エントリ）で構成される。また、攻撃情報３２２においては、攻撃に悪用される脆弱性を識別するため、一般的に、脆弱性の識別番号（例えば、ＣＶＥ番号）が付与される。攻撃情報３２２は、セキュリティ情報を公開するサービス等から提供される。
【０１３３】
また、攻撃判定部１０７は、（図示していないが）セキュリティ対策ベンダ（セキュリティ対策の機器（ＩＰＳ等）やソフトウェアのベンダ）における攻撃への対応の情報である、攻撃対応情報３２３を入力する。
【０１３４】
攻撃対応情報３２３は、ＩＰＳのシグネチャや、アンチウイルスソフトウェアのパターンファイル情報等、攻撃への対応（検知／防御）の情報である。攻撃対応情報３２３は、対応（検知／防御）する攻撃が悪用する公開脆弱性情報３２１の識別子（例えば、ＣＶＥ番号）を含む。また、対象の攻撃の攻撃ＩＤを含むこともある。攻撃対応情報３２３は、対策ＩＤで識別される１種類以上の情報で構成される。
【０１３５】
次に、攻撃判定部１０７の処理を説明する。
【０１３６】
攻撃判定部１０７は、入力された、公開脆弱性情報３２１、攻撃情報３２２、攻撃対応情報３２３から、世の中で公開されている攻撃に対して、セキュリティ対策で対応できるかを次のように判断する。
【０１３７】
攻撃判定部１０７は、公開脆弱性情報３２１若しくは攻撃情報３２２の１つのエントリを抽出し、記載されている脆弱性の識別番号（例えば、ＣＶＥ番号＝ｘｘｘ）について、攻撃対応情報３２３のエントリにおいて同番号を含むものがあるか調べる。もしこの番号を含むエントリがあればＣＶＥ番号＝ｘｘｘについてセキュリティ対策（例えば、ＩＰＳ）で防御可能と判定する。攻撃判定部１０７は、公開脆弱性情報３２１若しくは攻撃情報３２２の全てのエントリについて、含まれる脆弱性の識別番号（例えば、ＣＶＥ番号＝ｘｘｘ）が、攻撃対応情報３２３のエントリに含まれるか調べることで、全ての公開脆弱性情報３２１若しくは攻撃情報３２２について、セキュリティ対策（例えば、ＩＰＳ）で対応できるか否かを判定する。
【０１３８】
攻撃判定部１０７は、上記の処理により、公開脆弱性情報３２１や攻撃情報３２２のエントリを以下に分類する。
・セキュリティ対策対応情報（図示なし）：採用しているセキュリティ対策手段（例えば、ＩＰＳ）で対応できる、公開脆弱性情報３２１若しくは攻撃情報３２２のエントリである。
・セキュリティ対策非対応情報（図示なし）：採用しているセキュリティ対策手段（例えば、ＩＰＳ）で対応できない、公開脆弱性情報３２１若しくは攻撃情報３２２のエントリである。
【０１３９】
攻撃判定部１０７は、この分類を図７のＳ２４の処理を行う前までに実施する。
【０１４０】
次に、攻撃判定部１０７は、図６の処理を実行し、その際に図７の処理を行うが、図７のＳ２４において、まず、攻撃Ａｋがセキュリティ対策対応情報に含まれるか調べる。攻撃Ａｋについては、攻撃シナリオ要素Ａｉの攻撃識別情報４０１で脆弱性ＩＤ（例えば、ＣＶＥ番号）が含まれているので、この脆弱性ＩＤが、セキュリティ対策対応情報に含まれるかを調べればよい。もし含まれていなければ（或いは、セキュリティ対策非対応情報に同脆弱性ＩＤが含まれていれば）、そのセキュリティ対策（例えば、ＩＰＳ）ではそもそも対応できないことが判定できる。
【０１４１】
もし、攻撃Ａｋがセキュリティ対策対応情報に含まれていた場合、図７のＳ２４においては、実施の形態１の処理のように、攻撃Ａｋについて対策しているか（例えば、ＩＰＳに適用しているシグネチャで対策しているか）調べる。対策していなかった場合は、セキュリティ対策ベンダはセキュリティ対策対応情報として、攻撃Ａｋに対応しているのだから（例えば、ＩＰＳのシグネチャを提供）、セキュリティ対策の是正（例えば、ＩＰＳのシグネチャの更新）が必要と判定し、出力部１０９に対して、警告情報３２４として、攻撃Ａｋを識別する番号（例えば、攻撃ＩＤや脆弱性ＩＤ＝ＣＶＥ番号等）とセキュリティ対策の是正（例えば、ＩＰＳのシグネチャの更新）を推奨するメッセージを出力する。さらに、この状況は、セキュリティ対策（例えば、ＩＰＳ）が適切に運用されていないために（例えば、ＩＰＳのシグネチャが更新されていないために）、攻撃Ａｋを検知していないだけで、攻撃Ａｋが発生している（つまり見過ごしている）可能性が高いので、図７のＳ２９において呼び出すログ検索関数ｆの数を増やしたり、或いは、同関数に与えるパラメータをより詳しく検索したりする等により、詳しくログを調査する。
【０１４２】
ログ検索関数ｆに与えるパラメータは、予め攻撃判定部１０７の内部に設定値として保存しておけばよく、例えば、図７のＳ２４でセキュリティ対策の是正が必要と判断した場合、ログ検索関数ｆについて、規定で呼び出すｆ＿１、ｆ＿２、ｆ＿３に加えて、ｆ＿４、ｆ＿５、ｆ＿６を呼び出すと定義すればよい。或いは、ｆ＿１、ｆ＿２、ｆ＿３に渡すパラメータ、例えば、ｐ＝１０（例えば、ログ検索による攻撃の痕跡の検知の感度を指定するパラメータ）を、ｐ＝２０に上げてもよい。或いは、ｆ＿１、ｆ＿２、ｆ＿３に渡すパラメータとして検索先のログ種類を指定している場合は、検索すべきログを追加したりして範囲を広げてくまなく検索してもよい。
【０１４３】
つまり、セキュリティ対策の是正が必要な状況では、攻撃の検知漏れをしている可能性があり、その攻撃の痕跡が様々なログに残っている可能性が高いので、規定のログ検索よりも検索を強化する。
【０１４４】
反対に、攻撃Ａｋがセキュリティ対策対応情報に含まれていない場合、そのセキュリティ対策（ＩＰＳ）ではそもそも攻撃Ａｋに対応できないことが判定できる。この場合は、規定のログ検索のままにしてもよいし、上述のように、ログ検索を強化してもよい。
【０１４５】
以上説明したように、本実施の形態において、攻撃シナリオデータベース１１１に記憶された攻撃シナリオ２０４では、監視対象のコンピュータシステムに対する複数の攻撃のそれぞれが利用する脆弱性が定義される。攻撃判定部１０７は、脆弱性に関する情報を公開する外部のシステムにアクセスして、攻撃シナリオデータベース１１１に記憶された攻撃シナリオで定義されている、関連攻撃抽出部１０４により抽出された攻撃が利用する脆弱性に関する情報が当該外部のシステムにより公開されているかどうかを判定し、公開されていると判定した場合に、ログデータベース１１４に記憶されたログを分析する。
【０１４６】
本実施の形態では、公開脆弱性情報３２１や攻撃情報３２２と、攻撃対応情報３２３を比較することで、世の中に存在する攻撃が、現在使用しているセキュリティ対策で対応（検知／防御）可能かということを攻撃判定部１０７が予め調べておき、その結果、「セキュリティ対策ベンダでは攻撃に対応している」が、「セキュリティ対策の運用環境では適用していない（セキュリティ対策の是正が必要）」場合は、セキュリティ対策での検知漏れの可能性があるため、ログ検索を詳細に行う。この処理により、発生している可能性があるが検知されていない攻撃を、ログから検知する機会を増やす効果がある。また、「セキュリティ対策が対応していない」攻撃については、規定のログ検索のまま処理を進めたり、検索を詳細に行うことが可能となる効果がある。
【０１４７】
実施の形態３．
本実施の形態について、主に実施の形態１との差異を説明する。
【０１４８】
図７の処理において、攻撃Ａｋについて、通信が発生する場合は、例えばプロキシログにその通信の痕跡が残る場合がある。そこで、攻撃判定部１０７は、プロキシログの検索を以下のように行う。
【０１４９】
例えば、実施の形態１における、攻撃Ａ１、攻撃Ａ２、攻撃Ａ４が検知されている場合は、その情報から攻撃対象の端末が特定されることがある。例えば、検知したセキュリティ対策がＩＰＳであれば、検知アラート（ログ）に攻撃先の端末の識別子（例えば、ＩＰアドレス）が記録されている。
【０１５０】
また、セキュリティ対策の１つとして、プロキシログから不審な通信を分析し、攻撃を検知している場合は、不審な通信を行っている端末の識別子が特定される。
【０１５１】
セキュリティ対策の１つとして、セキュリティ設定が変更された端末を、端末の監査ログを調べて検知している場合は、攻撃の種類によっては、攻撃先ではなく攻撃元を特定することになる。例えば、ある端末にマルウェアが感染したため、その端末のセキュリティ設定が変更され、さらに、プロキシログの分析でその端末から不正な通信を行っていることを検知した場合は、その端末が攻撃元となる。
【０１５２】
これらの場合、その攻撃先（元）として特定されている端末において、初めてアクセスするウェブサイトの有無を調査する。これは、もし該当端末がマルウェア等に感染している場合、インターネット上の攻撃者が制御するウェブサイト（Ｃｏｍｍａｎｄ＆Ｃｏｎｔｒｏｌ（Ｃ＆Ｃ）サーバ）へアクセスし、命令を受け取ったり、情報を漏洩したりしていることがあるためであり、その場合、そのウェブサイトは、（必ずしもそうではないが）該当端末が今までアクセスしたことのないウェブサイトであることが多いからである。
【０１５３】
そこで、攻撃判定部１０７は、ログ検索部１０８を経由してログデータベース１１４に蓄積されたプロキシログを検索し、該当端末がある期間にアクセスしたウェブサイトのホスト名を得て、そのリストを作成する（過去アクセスホスト名リスト（図示なし））。ある期間とは、任意の期間でよいが、ここでは、Ａ３において今までアクセスしていないウェブサイトへのアクセスを調べるので、攻撃Ａ２以前の期間とするのが好ましい。そして、ログ検索関数ｆは、以下のように処理する。
・与えられるパラメータ：以下の通りである。
（１）ログの検索期間（攻撃Ａ２の発生日時からｎ時間後まで）
（２）攻撃先（元）端末の識別子（例えば、ＩＰアドレス）
（３）検索するログの情報（例えば、プロキシログの識別子）
（４）攻撃先（元）端末がある期間にアクセスしたウェブサイトのホスト名のリスト（過去アクセスホスト名リスト）
・処理：（３）で指定されたログから、（１）の期間のログについて、（２）の攻撃先（元）端末の識別子に該当するログエントリを検索し、検索されたログエントリにおけるアクセス先のウェブサーバのホスト名が、（４）のホスト名のリストにあるか否か調べる。リストにない場合は、初アクセスホスト名リスト（図示なし）に加える。
【０１５４】
このように、ログ検索関数ｆは、（２）で指定される端末が、攻撃Ａ３が発生したであろう期間に初めてアクセスしたウェブサイトのホスト名を、初アクセスホスト名リストに得ることができる。
【０１５５】
次に、この初アクセスホスト名リストをウェブレピュテーション（ウェブサイトが不審か否か判定するサービス）で不審なウェブサイトでないか調べる。ウェブレピュテーションをオンラインで提供するサービスがあり、このようなサービスを利用して初アクセスホスト名リストに記載のホスト名を１つずつ、不審か否か調査する。この調査では、ウェブレピュテーションのサービスをｕ個利用し、ｖ個以上で不審と判定したら、そのホスト名を不審と判断する。ウェブレピュテーションのサービスが判定結果をスコアで返す場合は、ｕ個のサービスの判定結果のスコアの合計がｗ以上の場合に不審と判定してもよい。また、ウェブレピュテーションのサービスが、オンライン以外に、ＣＤ（Ｃｏｍｐａｃｔ・Ｄｉｓｃ）等の媒体でレピュテーションの情報が提供されていれば、それを利用して判定してもよい。
【０１５６】
ウェブレピュテーションのサービスにおいて判定結果に併せてホスト名のホストが所在する国・地域・期間が提示されることがある。予め、ホストが所在する国・地域のブラックリストを作成しておき、ウェブレピュテーションの結果、所在がこのブラックリストに記載されていた場合に不審と判定してもよい（ホストの所在が何処にあるか、誰が管理しているか等の情報だけを調べるオンラインサービスがあり、それを利用してもよい）。或いは、ホスト名のブラックリストを作成し、これに該当する場合に不審と判定してもよい。或いは、ホスト名のホワイトリストを作成し、これに該当しない場合に不審と判定してもよい。
【０１５７】
上記の判定の結果、初アクセスホスト名リストにおけるホスト名ｘ個のうち、ｙ個以上が不審と判定された場合に、攻撃の発生と判断してもよい。
【０１５８】
上記の攻撃の判定に、次のような判定を加えてもよい。
【０１５９】
初アクセスホスト名リストにおけるホスト名１つについて、（１）のログの検索期間（或いはその期間を超えた任意の期間）において、ｑ時間の間にｒ回以上アクセスした場合に攻撃の発生と判断してもよい。また、そのアクセスの仕方がランダムの場合に攻撃発生と判断してもよく、そのアクセスの仕方が定期的であってもよい。このようなランダムや定期的といったアクセスの仕方の判断は、既知の判断方式を使ってよい。
【０１６０】
また、（４）の攻撃先（元）端末がある期間にアクセスしたウェブサイトのホスト名のリストをＮＵＬＬにすることで、関数ｆの処理で、（３）で指定されたログから、（１）の期間のログについて、（２）の攻撃先（元）端末の識別子に該当するログエントリを検索し、検索されたログエントリにおけるアクセス先のウェブサイトのホスト名は、全て、初アクセスホスト名リストに加える。このように、初アクセスのウェブサイトか否かに係らず全てのウェブサイトについて不審か否かを判定するようにしてもよい。
【０１６１】
以上説明したように、本実施の形態において、監視対象のコンピュータシステムには、そのコンピュータシステムに含まれる複数のコンピュータと外部との通信を中継する中継装置（例えば、プロキシサーバ）が備えられる。攻撃判定部１０７は、ログデータベース１１４に記憶されたログのうち、少なくとも上記中継装置のログを分析して、上記コンピュータシステムが関連攻撃抽出部１０４により抽出された攻撃を受けていたかどうかを判定する。
【０１６２】
上記のように、本実施の形態では、既に発生している攻撃の間の期間で、他の攻撃の発生が、攻撃シナリオ等により考えられる場合は、その期間においてアクセスしたウェブサイトについて、不審なアクセスでないかをウェブレピュテーションサービスを使って判定することで、既に起こった攻撃の結果、不審なサイトにアクセスしていると判断でき、そのことから、他の攻撃が発生したと判断できる効果がある。
【０１６３】
実施の形態４．
本実施の形態について、主に実施の形態３との差異を説明する。
【０１６４】
実施の形態３では、プロキシログを検索する検索関数ｆを用いたが、本実施の形態では、端末におけるログを検索する検索関数ｆを用いる。
【０１６５】
攻撃Ａ１、攻撃Ａ２、攻撃Ａ４の発生が確認された場合、例えば、攻撃先／元の端末において、攻撃Ａ１、攻撃Ａ２の発生に引き続き発生する攻撃による端末の操作が発生することがある。例えば、プロセスの操作、ファイル操作、設定の操作（検索・変更）、アカウントの操作、ログの操作が発生する。これらの挙動を監視してログに出力するソフトウェアがある。このようなソフトウェアでは、これらの挙動を全て記録したログを端末挙動ログ（図示なし）とする。
【０１６６】
攻撃判定部１０７は、ログ検索部１０８を経由してログデータベース１１４に蓄積されたログを検索し、該当端末においてある期間に観測された端末挙動ログを調べ、不審な挙動がないか調べる。そのために、以下のログ検索関数ｆを用いる。
・与えられるパラメータ：以下の通りである。
（１）ログの検索期間（攻撃Ａ２の発生日時からｎ時間後まで、或いは攻撃Ａ２の発生日時から攻撃Ａ４の発生日時まで）
（２）攻撃先（元）端末の識別子（例えば、ＩＰアドレス）
（３）検索するログの情報（例えば、端末挙動ログの識別子）
（４）不審プロセス操作判断基準、不審ファイル操作判断基準、不審設定操作判断基準、不審アカウント操作判断基準、不審ログ操作判断基準、不審アクセス判断基準
・処理：（３）で指定された端末挙動ログから、（１）で指定された検索期間について、（２）の攻撃先（元）端末の識別子に該当するエントリを検索し、検索されたログエントリ（調査対象ログエントリ）において、（４）で与える判断基準を満たすものがあるか調べる。
【０１６７】
不審プロセス操作判断基準について説明する。
【０１６８】
例えば、通常起動するプロセスをホワイトリストとして不審プロセス操作判断基準に内包しておき、調査対象ログエントリにおいて起動したプロセス名があれば、このホワイトリストに名前があるか照合する。合致がなければ、不審なプロセスの起動として判定する。或いは、不審なプロセス名を予めブラックリストとして不審プロセス操作判断基準に内包しておき、調査対象ログエントリにおいて起動したプロセス名があれば、不審なプロセスの起動として判定してもよい。
【０１６９】
不審ファイル操作判断基準について説明する。
【０１７０】
例えば、あるｕ時間以内にｖ個のファイルを「コピー」した場合に、不審と判断する判断条件を不審ファイル操作判断基準に内包しておき、調査対象ログエントリにおいてこの条件を満たすファイル操作があれば、不審なファイル操作の発生として判定する。或いは、上記の判断条件について、「コピー」の部分を「ファイルの名前の変更」や「オペレーティングシステムのシステムフォルダ下に新規にファイルが生成されたこと」等に置き換えてもよい。また、複数の判断条件のいずれかを満たした場合や、複数の判断条件のうち任意の組み合わせを満たした場合に、不審なファイル操作と判定してもよい。
【０１７１】
不審設定操作判断基準について説明する。
【０１７２】
例えば、ｗ時間以内にｘ回のオペレーティングシステム（或いはアプリケーション）における「特定の設定値の追加、削除、変更」が発生した場合に不審と判断する判断条件を不審設定操作判断基準に内包しておき、調査対象ログエントリにおいてこの条件を満たす設定操作があれば、不審な設定操作の発生として判定する。「特定の設定値の変更・追加」の例として、オペレーティングシステム起動時に自動的に起動するアプリケーションの追加・変更、信用するデジタル証明書を追加する等がある。また、ローカルファイアウォールにおいて特定の送信元を許可したり、特定のポートへのアクセスやプロトコルのアクセスを許可したりする等、許可する条件を緩めることもある。逆に、ローカルファイアウォールにおいて、アンチウイルスソフトウェアがパターンファイルのアップデートのために外部と通信することをブロックする等、特定の通信をブロックすることもある。「特定の設定値の削除」の例としてローカルファイアウォールでブロックする送信元情報の削除等がある。
【０１７３】
不審アカウント操作判断基準について説明する。
【０１７４】
例えば、不審アカウント操作判断基準として、ｑ時間以内にｒ回の「特定のアカウント操作」が発生した場合に不審と判断する判断条件を不審アカウント操作判断基準に内包しておき、調査対象ログエントリにおいてこの条件を満たすアカウント操作があれば、不審なアカウント操作の発生として判定する。「特定のアカウント操作」の例として、権限の高いアカウントの追加、既存のアカウントの権限の昇格、パスワードのロック回数を減らす、認証の失敗等がある。
【０１７５】
不審ログ操作判断基準について説明する。
【０１７６】
例えば、ｓ時間以内にｔ回の「特定のログ操作」が発生した場合に不審と判断する判断条件を不審ログ操作判断基準に内包しておき、調査対象ログエントリにおいてこの条件を満たすログ操作があれば、不審なログ操作の発生として判定する。「特定のログ操作」の例として、セキュリティ監査ログの閲覧、削除、変更等がある。
【０１７７】
不審アクセス判断基準について説明する。
【０１７８】
例えば、ａ時間以内にｂ回の「特定のアクセス」が発生した場合に不審と判断する判断条件を不審アクセス判断基準に内包しておき、調査対象ログエントリにおいてこの条件を満たすアクセスがあれば、不審なアクセスとして判定する。「特定のアクセス」の例として、ローカルファイアウォールログで、ネットワークスキャンで拒否ログが発生していたり、特定のフォルダへのアクセスが発生し拒否ログが発生していたり、認証エラーが発生している等がある。
【０１７９】
ログ検索関数ｆにおいて、不審プロセス操作判断基準、不審ファイル操作判断基準、不審設定操作判断基準、不審アカウント操作判断基準、不審ログ操作判断基準、不審アクセス判断基準について、これらの判断基準のいずれか１つだけ不審と判定された場合に攻撃の発生と判断してもよい。又は、ｚ個以上の判断基準について不審と判定された場合に攻撃の発生と判断してもよい。また、ログ検索関数ｆに与える（４）の判断基準は、これら全てでも、一部を組み合わせてもよい。
【０１８０】
また、端末挙動ログを調べる対象は、攻撃元（先）の端末だけでなく、その端末からネットワーク経由でアクセス可能な他の端末であってもよく、端末は、ＰＣやファイルサーバやデータベースサーバ等のサーバであってもよい。その場合、攻撃元（先）の端末が攻撃Ａ２の発生日時以降にアクセスした他の端末を、ネットワークログや、他の端末のログから調べて判定してもよい。例えば、ネットワークログの１種であるルータが発生するフローログにおいては、いつどの端末からどの端末へアクセスが発生したかが記録されているし、端末のローカルファイアウォールログにおいては、リモートの端末へアクセスした記録や、リモートの端末からアクセスされた記憶が残る。したがって、これらのログから、攻撃元（先）の端末だけでなく、その端末からネットワーク経由でアクセス可能な他の端末を調べればよい。
【０１８１】
また、端末挙動ログについて、挙動別に個々のログを出力する場合もあるが、その場合は、個々のログについて、該当する関数ｆを適用すればよい。
【０１８２】
以上説明したように、本実施の形態において、攻撃判定部１０７は、ログデータベース１１４に記憶されたログのうち、少なくとも監視対象のコンピュータシステムに含まれる少なくとも１つのコンピュータのログを分析して、上記コンピュータシステムが関連攻撃抽出部１０４により抽出された攻撃を受けていたかどうかを判定する。
【０１８３】
上記のように、本実施の形態では、既に発生している攻撃の間の期間で、他の攻撃の発生が、攻撃シナリオ等により考えられる場合で、その攻撃がＩＰＳ等で検知されていない場合、その期間において攻撃元（先）の端末、或いはその端末からアクセス可能な他の端末について、端末挙動ログに不審な挙動が発生していないか判定することで、既に起こった攻撃の結果、不審な挙動が発生していると判断でき、そのことから、他の攻撃が発生したと判断できる効果がある。
【０１８４】
実施の形態５．
本実施の形態について、主に実施の形態１との差異を説明する。
【０１８５】
図１２は、攻撃シナリオ２０４のスコア４０５の一例を示す表である。
【０１８６】
図１２に示すように、本実施の形態では、攻撃シナリオ２０４を構成する攻撃シナリオ要素Ａｉに、その攻撃の危険度を表すスコア４０５を付与する。攻撃判定部１０７は、検知結果３０１若しくは既検知結果３０４で与えられた攻撃について、これらに該当する攻撃シナリオ２０４を攻撃シナリオ検索部１０３経由で既に得ている。よって、攻撃判定部１０７は、攻撃シナリオ２０４から、検知結果３０１若しくは既検知結果３０４で与えられた攻撃についてのスコア４０５を得ることができる。さらに、攻撃判定部１０７は、それらのスコア４０５を足し合わせる。
【０１８７】
ここで、攻撃シナリオ２０４が「攻撃Ａ１→攻撃Ａ２→攻撃Ａ３→攻撃Ａ４→攻撃Ａ５」となっており、実施の形態１の説明で示した例のように、攻撃Ａ１、攻撃Ａ２、攻撃Ａ４が検知されたとする。このとき、スコア４０５の合計Ｓ＝３０＋１０＋１０＝５０点となる。
【０１８８】
検知したスコアの合計Ｓが、閾値ｍ＝９０点（合計Ｓの最大１００点の４／５）以上の場合にサイバー攻撃が発生したと判定する場合で、図６の処理の結果、攻撃Ａ３が検知されなかったとする。その場合、もし攻撃Ａ５が発生しても２０点が加算されるのみで、Ｓ＝７０点＜ｍとなり、５つの攻撃中４つが検知されてもサイバー攻撃の発生とみなされない。そこで、図６の処理の結果、攻撃Ａ３が検知されなかった場合に、閾値ｍを下げ、７０点とする。或いは、攻撃Ａ５のスコア４０５を５０点に変更する。或いは、現在のスコア４０５の合計Ｓである５０点に３０点を足す。このように、攻撃Ａ３がログから検知されなくても、攻撃Ａ５が検知された場合にサイバー攻撃が発生したと判定できるように動的に判定基準を変更する。
【０１８９】
また、スコア４０５の高い攻撃（例えば、攻撃Ａ３が３０点である）が検索されない場合、その発生を見落とすことは危険なので、その場合は、攻撃判定部１０７は、動的にログ検索関数ｆとして、規定の関数と異なるものを追加して呼び出したり、ログ検索関数ｆに与える規定のパラメータを変更したりして、より検知の感度が高くなるように設定を変更し、スコア４０５の高い攻撃のログによる検知を動的に強化してもよい。
【０１９０】
また、セキュリティ対策情報５００において、セキュリティ対策によって、検知漏れの発生のしやすさや誤検知の発生のしやすさが分かっている場合は、その確度を、検知漏れ確度Ｆｎ、誤検知確度Ｆｐとして対策情報５０４に追加する。例えば、ＩＰＳにおいては、シグネチャの更新が遅れた場合に検知漏れが発生するし、振る舞い検知で攻撃を検知する場合は正常な振る舞いを誤検知することがあるので、こういった情報を対策情報５０４に追加してもよい。
【０１９１】
ここで、攻撃判定部１０７に入力された対策有無情報２０７において、検知漏れ確度Ｆｎが付与されていたとする。その場合は、攻撃判定部１０７は、攻撃シナリオ２０４において、この対策で対応する攻撃のスコア４０５を動的に減らしてサイバー攻撃の判定を行う。
【０１９２】
例えば、攻撃シナリオ２０４に従った場合に検知しているはずの攻撃で未だ検知されていない攻撃Ａ３についてスコア４０５が３０点とする。そして、この攻撃Ａ３は対策有無情報２０７で検知可能と判定されている（攻撃Ａ３を識別する情報である攻撃識別情報４０１とそれに対応するセキュリティ対策情報５００による）が、実際には検知されず、対策有無情報２０７における検知漏れ確度Ｆｎ＝５０％であるとする。これは、５０％の確率で検知漏れが発生することを意味している。そこで、動的に、閾値ｍ＝９０点を、（３０点＋１０点＋３０点×５０％＋１０点＋２０点）×４／５＝６８点に減算して、サイバー攻撃を判定する。
【０１９３】
また、閾値ｍを減算する代わりに、攻撃判定部１０７は動的にログ検索関数ｆを規定の関数に対して追加して呼び出したり、ログ検索関数ｆに与える規定のパラメータを変更したりして、より検知の感度が高くなるように設定を変更し、スコア４０５の高い攻撃の、ログの検索による検知を強化してもよい。例えば、検知漏れ確度Ｆｎ＝５０％であれば、呼び出すｆの種類や数を２倍にしたり、関数ｆの感度を２倍になるようにパラメータを調整したりする。つまり、対策有無情報２０７における対策は５０％の確率で検知漏れが発生するので、ログ検索関数ｆによるＡ３の検知を動的に詳細にしてもよい。
【０１９４】
また、例えば、攻撃Ａ２が既検知結果３０４で検知されたことが攻撃判定部１０７に入力された場合に、攻撃Ａ２が何の対策により検知されたかを、攻撃判定部１０７は、セキュリティ対策検索部１０５を経由してセキュリティ対策データベース１１２から得られる対策有無情報２０７で知ることができる。例えば、既検知結果３０４に含まれる攻撃ＩＤを関連攻撃情報２０５として、セキュリティ対策検索部１０５に対して入力することで、この攻撃ＩＤへ対策可能なセキュリティ対策を検索する（セキュリティ対策情報５００には攻撃識別情報５０１が含まれ、この情報には攻撃ＩＤが含まれる）。この結果、攻撃判定部１０７は、対策有無情報２０７を得るが、この情報に、誤検知確度Ｆｐが含まれていたとする。ここで、誤検知確度Ｆｐ＝５０％とする。これは、攻撃Ａ２を検知した場合、５０％の確率で誤検知であることを意味する。その場合、攻撃判定部１０７はこの攻撃Ａ２について、ログ検索関数ｆを呼び出して、攻撃Ａ２の発生の痕跡をログから検索する。もし検索された場合は、攻撃Ａ２の検知は誤検知ではないと判定する。つまり、対策有無情報２０７で示されたＩＰＳ等の対策で攻撃Ａ２を検知した場合に、その対策が誤検知が５０％である場合、ログ検索関数ｆを呼び出して他のログから攻撃Ａ２の痕跡を探し、もし見つかれば、ＩＰＳ等の対策で検知され、他のログからも攻撃の痕跡が見つかっているので、誤検知ではないと判断する。
【０１９５】
関数ｆの呼び出し方は、例えば、誤検知確度Ｆｐ＝５０％であれば、攻撃Ａ２を検知する関数ｆについて、呼び出すｆの種類や数を２倍にしたり、関数ｆの感度を２倍になるようにパラメータを調整したりする。
【０１９６】
スコア４０５の合計値の閾値を動的に変更するルールや、検知漏れ確度Ｆｎや誤検知確度Ｆｐに対して、いくつ以上であれば、ログ検索関数ｆを呼び出してログを検索するか判断するための閾値については、セキュリティログ分析装置１００の内部に予め保存しておけばよい。
【０１９７】
以上説明したように、本実施の形態において、攻撃シナリオデータベース１１１に記憶された攻撃シナリオ２０４では、監視対象のコンピュータシステムに対する複数の攻撃のそれぞれに対して点数（即ち、スコア４０５）が設定される。攻撃判定部１０７は、攻撃シナリオデータベース１１１に記憶された攻撃シナリオ２０４で定義されている複数の攻撃のうち、上記コンピュータシステムに備えられた検知装置により既に検知されている全ての攻撃（例えば、攻撃Ａ１、攻撃Ａ２、攻撃Ａ４）を特定し、当該攻撃シナリオ２０４で、特定した攻撃に対して設定されている点数の合計と閾値との比較結果に基づいて、当該攻撃シナリオ２０４が実行されたかどうかを判定する。
【０１９８】
また、本実施の形態において、攻撃判定部１０７は、攻撃の検知漏れが発生したと判断した場合、攻撃シナリオデータベース１１１に記憶された攻撃シナリオ２０４で設定されている点数と上記閾値との少なくともいずれかを調整する。
【０１９９】
上記のように、本実施の形態では、攻撃シナリオ２０４に沿った攻撃の発生を元に、スコア４０５によりサイバー攻撃の発生を検知する場合で、攻撃シナリオ２０４の通りに攻撃が発生していない場合は、サイバー攻撃の発生を判断する閾値を動的に下げたり、付与したスコアを動的に変更したり、呼び出すログ検索関数を追加したり、攻撃を判定するパラメータの感度を変更したりすることで、攻撃シナリオ２０４の通りに発生しない攻撃があってもサイバー攻撃の検知が可能となる。また、セキュリティ対策で検知漏れや誤検知の発生確度が予め分かっている場合はその情報をセキュリティ対策の情報に追加しておき、これらの情報を用いることで、セキュリティ対策で検知が漏れている可能性のある攻撃については、ログ分析関数ｆによりログから検知を行うことで検知漏れを減らし、既に検知した攻撃に関しては、ログ分析関数ｆによりログから同攻撃を検知することで、誤検知か否かを判断できる効果がある。
【０２００】
実施の形態６．
本実施の形態について、主に実施の形態１との差異を説明する。
【０２０１】
本実施の形態では、ログを検索するタイミングについて、予め定めた検索のタイミングを攻撃の検知状況に応じて変更する。
【０２０２】
実施の形態１の説明で用いた例において、攻撃シナリオ２０４は「攻撃Ａ１→攻撃Ａ２→攻撃Ａ３→攻撃Ａ４→攻撃Ａ５」となっていた。そして、検知した攻撃は、攻撃Ａ１、攻撃Ａ２、攻撃Ａ４であり、攻撃Ａ３の発生をログを検索して検知しようとした。将来発生するであろう攻撃Ａ５については、例えば、その後、１０日後に検知結果３０１として通知されるのを待ってもよいが、検知結果３０１を待つのではなく、攻撃判定部１０７において、定期的にログ検索関数ｆを呼び出して、ログから攻撃の痕跡を検索することで攻撃を検知してもよい。また、この検索による検知は、攻撃Ａ３（攻撃シナリオ２０４に従った場合、既に発生している可能性のある攻撃）に対する攻撃判定部１０７によるログ検索による検知と、並行して実施してもよい。
【０２０３】
このとき、将来起こるかもしれない攻撃Ａ５については、いつまで検知結果３０１を待つべきか、或いは、ログ検索関数ｆによるログの検索により検知を行うべきかを、予め、セキュリティログ分析装置１００に保存しておく（攻撃判定部１０７等に保存）。例えば、攻撃シナリオ２０４のある攻撃から次の攻撃の発生を待つ期間は「３０日おき」として保存しておけば、攻撃Ａ５についての検知結果３０１を待つ期間は攻撃Ａ４の検知後３０日までとなる。また、ログを検索するタイミングは、攻撃Ａ４の検知後３０日となる（攻撃Ａ４の検知後３０日分のログを検索する）。また、攻撃Ａ５についてログから検索して探すタイミングを、「１０日おきに検索し３０日まで行う」として保存しておけば、攻撃Ａ５についてのログの検索のタイミングは、攻撃Ａ４の検知後、１０日目（前回の検索から１０日経過分を検索）、２０日目（前回の検索から１０日経過分を検索）、３０日目（前回の検索から１０日経過分を検索）となる。
【０２０４】
しかし、このように、攻撃シナリオ２０４について、将来起こるかもしれない攻撃の発生についての検知を、セキュリティログ分析装置１００に保存した期間に従って行った場合、検知結果３０１を待つ期間や、ログを検索するタイミングの「最後」を、例えば１日超えて攻撃が発生した場合には、攻撃シナリオ２０４に従った攻撃としては検索しないため、攻撃シナリオ２０４に従ったサイバー攻撃は発生していないと判断される。
【０２０５】
本実施の形態では、検知結果３０１を待つ期間や、ログを検索するタイミングについて、予め定められた日時を待っても攻撃を検知（検知結果３０１又はログ検索により）しなかった場合に、動的に、攻撃を待つ期間やログを検索するタイミングを延長する。以降、本実施の形態の説明において、「攻撃の検知」とは、検知結果３０１があること、又は、ログ検索による攻撃の検知を意味する。
【０２０６】
本実施の形態では、規定の「攻撃の検知」を待つ期間Ｔを決めておき、もしこの期間を過ぎても攻撃が検知されなかった場合のために、延長して「攻撃の検知」を待つ期間ＴＥｘｔを決めておく。また、延長回数ｎを決めておき、これらをセキュリティログ分析装置１００に保存する。例えば、Ｔ＝３０日、ＴＥｘｔ＝１０日、ｎ＝３回である。
【０２０７】
このようにすることで、攻撃Ａ５が攻撃Ａ４の発生後３０日（Ｔ＝３０日）経っても検知結果３０１で通知されず、ログ検索でも攻撃の痕跡が検索されなかった場合、その後、１０日間、同様に検知結果３０１の通知を待つ。或いは、１０日後に、前回の検索からの差分のログを検索し攻撃を検知する。
【０２０８】
それでも検知しなかった場合は、さらに１０日間、検知結果３０１の通知を待つ。或いは、１０日後に、前回の検索からの差分のログを検索し攻撃を検知する。
【０２０９】
それでも検知しなかった場合は、さらに１０日間、検知結果３０１の通知を待つ。或いは、１０日後に、前回の検索からの差分のログを検索し攻撃を検知する。
【０２１０】
その結果「攻撃の検知」が無かった場合は、攻撃シナリオ２０４に従ったサイバー攻撃は発生しなかったと判断する。
【０２１１】
また、実施の形態５のように、攻撃シナリオ２０４の攻撃シナリオ要素Ａｉにスコア４０５が付与されている場合、検知された攻撃（例えば、攻撃Ａ１、攻撃Ａ２、攻撃Ａ４）についてのスコア４０５の合計Ｓがサイバー攻撃の発生を判定する閾値Ｍよりも低い場合、つまり、未だ、サイバー攻撃の検知として判断されていない場合は、攻撃シナリオ２０４に従った攻撃の発生の可能性は低いとして、攻撃Ａ５の攻撃の検知について延長して待つ期間を短くしてもよい。
【０２１２】
例えば、Ｓ＜Ｍの場合は、保存されたＴ＝３０日、ＴＥｘｔ＝１０日、ｎ＝３回において、ＴＥｘｔ＝５日と減らしたり、或いは、ｎ＝１回と減らしたりしてもよい。逆に、Ｓ＞Ｍの場合は、既にサイバー攻撃の発生として判断する基準を満たしており、攻撃Ａ５の発生の可能性は高いとして、保存されたＴ＝３０日、ＴＥｘｔ＝１０日、ｎ＝３回において、ＴＥｘｔ＝２０日と増やしたり、或いはｎ＝６回と増やしたりしてもよい。ＴＥｘｔ及びｎは両方変更してもよい。そのルールはセキュリティログ分析装置１００に保存しておけばよい。例えば、
Ｔ＝３０日、ＴＥｘｔ＝１０日、ｎ＝３回
Ｍ＝８０
ｉｆ“Ｓ＞Ｍ”ｔｈｅｎ“ＴＥｘｔ＝２０日”
ｉｆ“Ｓ＜Ｍ”ｔｈｅｎ“ＴＥｘｔ＝５日”
と設定する。或いは、例えば、
Ｔ＝３０日、ＴＥｘｔ＝１０日、ｎ＝３回
Ｍ＝８０
ｉｆ“Ｓ＞Ｍ”ｔｈｅｎ“ｎ＝６回”
ｉｆ“Ｓ＜Ｍ”ｔｈｅｎ“ｎ＝１回”
と設定する。このように、セキュリティログ分析装置１００にルールを保存すれば、攻撃判定部１０７はこれらの値を読み取って処理を実行できる。
【０２１３】
また、上記のＳとＭの大小関係を逆にしたルールでもよい。また、上記のＳとＭの大小関係において、Ｍに係数（例えば、０．８）をかけて、Ｍの何％に対してＳの大小を比較するかを定めてもよい。
【０２１４】
或いは、攻撃Ａ５（次に起こるであろう攻撃）のスコア４０５の値（ｓ）について閾値ｍを設定し、同様のルールを記述してもよい。例えば、
Ｔ＝３０日、ＴＥｘｔ＝１０日、ｎ＝３回
ｍ＝２０
ｉｆ“ｓ＞ｍ”ｔｈｅｎ“ＴＥｘｔ＝２０日”（ｓは攻撃Ａ５のスコア４０５）
ｉｆ“ｓ＜ｍ”ｔｈｅｎ“ＴＥｘｔ＝５日”（ｓは攻撃Ａ５のスコア４０５）
と設定する。この場合、次に、検知結果３０１で通知されるかログ検索で検知される攻撃のスコア４０５が高ければ（閾値ｍより大きければ）、危険なので、延長して攻撃の検知（検知結果３０１の通知、若しくは、ログ検索による検知）を待つ期間を延長して、攻撃を捕らえる機会を増やす。逆に、同スコア４０５が低ければ、延長して攻撃の検知を待つ期間を減らす。
【０２１５】
また、攻撃Ａ５（次に起こるであろう攻撃）の「攻撃の種類」によって、これらの値を変更してもよい。例えば、攻撃Ａ５がＴｙｐｅ＝ＩｎｆｏＬｅａｋ（情報漏洩）の場合は、
Ｔ＝３０日、ＴＥｘｔ＝１０日、ｎ＝３回
ｉｆ“Ｔｙｐｅ＝ＩｎｆｏＬｅａｋ”ｔｈｅｎ“ＴＥｘｔ＝２０日”
ｉｆ“Ｔｙｐｅ＝ＦｉｌｅＤｅｌｅｔｅ”ｔｈｅｎ“ＴＥｘｔ＝５日”
とする。この場合、次に、検知結果３０１で通知されるかログ検索で検知される攻撃が、攻撃として危険な種類であれば、延長して攻撃の検知を待つ期間を延長して、攻撃を捕らえる機会を増やす。逆に、同種類がそれほど危険な種類でなければ、スコア４０５が低ければ攻撃の検知を待つ期間を減らす。
【０２１６】
なお、上記の例では、検知するはずの攻撃で検知していない攻撃が１つであるが、そのような攻撃が複数ある場合でも、その各々について、攻撃判定部１０７が動作すればよい。同様に、将来検知する攻撃が１つであるが、複数の場合でも各々について攻撃判定部１０７が動作すればよい。
【０２１７】
以上説明したように、本実施の形態において、攻撃判定部１０７は、攻撃シナリオデータベース１１１に記憶された攻撃シナリオ２０４で定義されている複数の攻撃のうち、上記コンピュータシステムに備えられた検知装置により未だ検知されておらず、当該攻撃シナリオ２０４で定義されている順番が上記検知装置により最後に検知された攻撃（例えば、攻撃Ａ４）の１つ後の攻撃（例えば、攻撃Ａ５）を抽出し、抽出した攻撃が上記検知装置により検知されない期間が閾値を超えた場合、当該攻撃シナリオ２０４が実行されなかったと判断する。
【０２１８】
また、本実施の形態において、攻撃シナリオデータベース１１１に記憶された攻撃シナリオ２０４では、上記コンピュータシステムに対する複数の攻撃のそれぞれに対して点数（即ち、スコア４０５）が設定される。攻撃判定部１０７は、攻撃シナリオデータベース１１１に記憶された攻撃シナリオ２０４で定義されている複数の攻撃のうち、上記検知装置により既に検知されている全ての攻撃（例えば、攻撃Ａ１、攻撃Ａ２、攻撃Ａ４）を特定し、当該攻撃シナリオ２０４で、特定した攻撃に対して設定されている点数の合計に応じて、上記閾値を調整する。或いは、攻撃判定部１０７は、当該攻撃シナリオ２０４で、抽出した攻撃（例えば、攻撃Ａ５）に対して設定されている点数に応じて、上記閾値を調整する。
【０２１９】
上記のように、本実施の形態では、攻撃シナリオ２０４に従い検知が発生しなかった場合に、攻撃のスコア４０５や種類等により攻撃の発生について延長して待つ期間を動的に変更するので、規定の待ち期間を僅かに超えた攻撃についても、効率的に攻撃シナリオ２０４に従ったサイバー攻撃として検知することが可能となる効果がある。
【０２２０】
実施の形態７．
本実施の形態について、主に実施の形態３との差異を説明する。
【０２２１】
実施の形態３では、プロキシログ等を分析した結果から、不審と判断された場合に、アクセスしたウェブサイトについてウェブレピュテーション等を利用して不審か否かを判定した。本実施の形態では、このような不審なＨＴＴＰ（ＨｙｐｅｒＴｅｘｔ・Ｔｒａｎｓｆｅｒ・Ｐｒｏｔｏｃｏｌ）通信が発見された場合に、その不審なＨＴＴＰ通信が発生するきっかけとなった事象を、攻撃シナリオを利用して特定する。
【０２２２】
例えば、不審なＨＴＴＰ通信が検知された場合、この不審なＨＴＴＰ通信を含む攻撃シナリオ２０４を検索したところ、攻撃Ａ１、攻撃Ａ２、攻撃Ａ３、攻撃Ａ４で構成される攻撃シナリオ２０４が検索され、攻撃Ａ２がこの不審な通信に該当したとする。その場合、攻撃Ａ２がマルウェアによる通信とした場合、攻撃Ａ１はマルウェアに感染するきっかけに該当する。そのようなきっかけは一般的に以下である。
（１）マルウェアが添付されたメール
（２）不正なウェブサイトへのリンク（ＵＲＬ（Ｕｎｉｆｏｒｍ・Ｒｅｓｏｕｒｃｅ・Ｌｏｃａｔｏｒ））が記録されたメール
（３）不正なウェブサイトへのアクセス
（４）マルウェアに感染した外部記憶媒体の参照
（５）他のマルウェアに感染した端末からネットワーク経由で感染
【０２２３】
以下に、攻撃Ａ１が（１）〜（５）のいずれかであるかを発見する方法を示す。以下の方法は、攻撃判定部１０７で処理される。ログデータベース１１４には以下で使用する、プロキシログ、メールサーバログ、端末の操作を記録するソフトウェアのログ（端末操作ログ）等の各種ログが保存されているものとする。ログの検索は、攻撃判定部１０７がログ検索部１０８を使用してログデータベース１１４に対して行う。攻撃判定部１０７がインベントリデータベース１１３に格納された情報を参照する場合、（図示していないが）攻撃判定部１０７はインベントリ検索部１０６を利用してインベントリデータベース１１３の情報を検索し、参照する。
【０２２４】
以下では、攻撃Ａ１が（１）或いは（２）の場合について説明する。
【０２２５】
攻撃判定部１０７では、攻撃Ａ２が発見された端末（不審なＨＴＴＰ通信を発している）の識別子をプロキシログから抽出し、この端末を使用しているユーザの識別子を取得する。例えば、組織では、「端末Ｘの利用者はユーザＵである」という対応表や、それに準ずる情報を保持していることがあるので、このような情報を参照することで、ユーザの識別子Ｕを取得する。
【０２２６】
さらに、組織では、「ユーザＵのメールアドレスはＭａｉｌＡｄｄｒｅｓｓＵである」という情報を管理していることが多いので、この情報を参照することで、ユーザＵのメールアドレスを取得する。
【０２２７】
次に、このメールアドレス宛に受信したメールの情報について、攻撃Ａ２の検知前、過去ｍ時間遡りメールサーバのログから検索する。
【０２２８】
次に、検索された各メールの情報について攻撃判定部１０７は以下の（ａ）及び（ｂ）判定を行う。
【０２２９】
（ａ）メールアドレスの信頼性を調べる。
【０２３０】
セキュリティログ分析装置１００は、図１３のような表を予め内包している。この表において、送信元のメールアドレスのカテゴリごとに、その信頼度が付与されている。例えば、同じ会社内で同じ部署のメールアドレスから送信されたメールであれば、そのメールの信頼度は高、違う部署であれば中と判断する。異なる会社から送信されたメールであれば、セキュリティが高い会社であることが予め分かっている場合、その情報はこの表に反映されており、そのメールの信頼度は高とし、不明な場合は中とする。フリーメールのアドレスから送信されたメールであれば、そのメールの信頼度は低とする。そして、メールについてこのような信頼度が判断された後、信頼度が高以外のメールは不審なメールの候補として扱う。
【０２３１】
さらに、同じ会社については、人事データベースからの情報として、該当するメールアドレスを使用しているユーザの人的な傾向を参照して信頼度に反映してもよい。例えば、「仕事上のミスが多い」という傾向があれば、信頼度を中、「慎重」であれば、信頼度は変更しない等である。
【０２３２】
仕事の忙しさとミスに相関があると仮定して、「仕事が忙しい」であれば信頼度を中、「仕事は忙しくない」であれば信頼度は変更しない、としてもよい。体調とミスに相関があると仮定して、「体調不良」であれば信頼度を中、「健康」であれば信頼度は変更しない、としてもよい。
【０２３３】
勤続年数と慎重さに相関があると仮定して、勤続年数が長ければ信頼度は高とし、勤続年数が短ければ信頼度は中、としてもよい。
【０２３４】
平均受信メール数が多い場合や、様々な会社とメールを送受信している場合は、様々なメールを閲覧する機会があり、危険にさらされる機会が高いとみなし、信頼度を中としてもよい。このような「受信メールが多い」、「様々な会社とメールを送受信している」といった判断は、まず閾値を定めておき、１日にその閾値を越える数のメールを受信していれば「受信メールが多い」と判定し、或いは、１日にメールを送受信した社外の会社の数がその閾値を超えた場合に、「様々な会社とメールを送受信している」と判定すればよい。
【０２３５】
或いは、検索されたメールの送信時間が、ビジネスアワーの場合は、信頼度は変更せず、深夜の場合は、（疲労している可能性があるとして）信頼度を中としてもよい。
【０２３６】
（ｂ）メールの信頼性を調べる。
【０２３７】
まず、メールが添付メールの場合について説明する。
【０２３８】
添付メールの添付ファイルが暗号化されている場合は、添付ファイルのセキュリティスキャン等、セキュリティ対策を回避している可能性があるため、信頼度を低とする。
【０２３９】
次に、メールが、ＵＲＬが記載されたメールの場合について説明する。
【０２４０】
記載されたＵＲＬを、ウェブレピュテーションを利用して、その不審さを調べる。不審と判断されれば、メールの信頼度を低とする。或いは、そのメールを受信した端末Ｘについて、そのメールの受信時間から遡りｎ時間における、端末Ｘのウェブアクセスについて、プロキシログを検索し、該当のＵＲＬにアクセスしていなければ、初めてアクセスするウェブサイトと判断して信頼度を低としてもよい。つまり、メールに記載されたＵＲＬが、ウェブレピュテーションにより不審と判断されるか、初めてアクセスするサイトであれば、信頼度を低く設定するのである。メールに記載されたＵＲＬについて、ウェブレピュテーションの変わりに、組織で保有しているＵＲＬのホワイトリストに該当しないＵＲＬである場合、信頼度を低としてもよい。組織で保有しているＵＲＬのブラックリストに該当するＵＲＬである場合、信頼度を極低としてもよい。
【０２４１】
次に、メールが、電子署名が付与されたメールの場合について説明する。
【０２４２】
メールに電子署名が付与されており、その電子署名の正当性が検証された場合に、メールの信頼度を高としてもよい。また、その署名を検証する際に使用した電子証明書が、メールの受信者の組織で信頼しているものである場合に、メールの信頼度を高としてもよい。或いは、その電子証明書の信頼度のランクを定義しておき、あるランク以上の場合に信頼度を高としてもよい。例えば、電子証明書を発行する認証局によって、電子証明書内に、電子証明書の発行プロセスにおいて、電子証明書の発行先の組織や人物について厳密な審査を経たうえで電子証明書を発行していることを示す識別子を含めていることがあり、その識別子を電子証明書の信頼度として使用すればよい。
【０２４３】
最後に、メールが、暗号化されたメールの場合について説明する。
【０２４４】
メールが暗号化されている場合は、セキュリティスキャン等、セキュリティ対策を回避している可能性があるため、信頼度を低とする。
【０２４５】
以下では、攻撃Ａ１が（３）の場合について説明する。
【０２４６】
攻撃判定部１０７では、攻撃Ａ２が発見された端末Ｘの識別子をプロキシログから抽出し、攻撃Ａ２の検知前、過去ｍ時間遡り、この端末ＸがアクセスしたウェブサイトのＵＲＬをプロキシログから検索する（端末Ｘの識別子でログを検索すればよい）。次に、検索されたＵＲＬをウェブレピュテーションを利用して不審さを調べる。不審と判断されればこのＵＲＬの信頼度を低とする。そうでない場合は信頼度を高としてもよい。
【０２４７】
以下では、攻撃Ａ１が（４）の場合について説明する。
【０２４８】
攻撃判定部１０７では、攻撃Ａ２が発見された端末Ｘの識別子をプロキシログから抽出し、Ａ２の検知前、過去ｍ時間遡り、この端末Ｘが外部記憶媒体を使用した場合に、この外部記憶媒体の信頼度を低とする。端末Ｘが外部記憶媒体を使用したか否かは、端末操作ログを検索することで実現し、端末操作ログにおいて、端末Ｘの識別子をキーに、Ａ２の検知前、過去ｍ時間遡り、検索し、外部記憶媒体の接続の有無を調べる。また、端末の操作を記録するソフトウェアによっては、組織で管理されている外部記憶媒体とそうでないもの（個人で所有しているもの）を、外部記憶媒体のシリアルナンバーで識別する機能がある。組織で管理されている外部記憶媒体ではない外部記憶媒体を接続していることが分かった場合は、その外部記憶媒体の信頼度を低とし、組織で管理されている外部記憶媒体の場合に信頼度を高としてもよい。
【０２４９】
以下では、攻撃Ａ１が（５）の場合について説明する。
【０２５０】
攻撃判定部１０７では、攻撃Ａ２が発見された端末Ｘの識別子をプロキシログから抽出し、攻撃Ａ２の検知前、過去ｍ時間遡り、この端末Ｘが他の端末Ｙからアクセスされたかを調べ、アクセスがあった場合はこの端末Ｙの信頼度を低とする。端末Ｘが他の端末からアクセスされたかは、端末Ｘの端末操作ログやＯＳが保持するローカルファイアウォールの機能が記録するログにおいて攻撃Ａ２の検知前、過去ｍ時間遡り、検索し、他の端末からのアクセスの有無を調べる。端末Ｙが端末Ｘの複数のポート（ＴＣＰ／ＵＤＰのポート）にアクセスしている場合に（どのポートが開いているか探っていると判断して）、端末Ｙの信頼度を低とし、そうでない場合は、信頼度を高としてもよい。また、端末Ｙが端末Ｘにアクセスした時点の、端末Ｙにおけるパッチの適用履歴を、インベントリデータベース１１３から調べ、端末Ｙがその当時の最新のパッチが適用されていない場合に、端末Ｙの信頼度を低としてもよい。また、端末Ｘについて、その当時の最新のパッチが適用されていない場合に（端末Ｙから攻撃を受けて感染した恐れがあるとして）端末Ｙの信頼度を低としてもよい。或いは、攻撃Ａ２の検知前、過去ｍ時間遡り、端末Ｘから端末Ｙ’に対してアクセスした場合、この端末Ｙ’が、複数のポートにおいてアクセスされていたり、端末Ｙ’がその当時の最新のパッチが適用されていない場合に、端末Ｙ’の信頼度を低としてもよい。
【０２５１】
これらの例では、攻撃Ａ２が発見された場合に、各種ログを遡り、受信したメールの信頼度、アクセスしたＵＲＬの信頼度、使用した外部記憶媒体の信頼度、アクセスされた他の端末の信頼度を決定している。そして、このような信頼度が低の場合に、攻撃Ａ１に相当する攻撃があったと判断する。例えば、攻撃Ａ２の発生から遡り、信頼度が低いメールを受信した場合に、攻撃Ａ１の発生と判断する。
【０２５２】
また、これらの例において、攻撃Ａ１が発生したと判断するための事象がログから発見された場合（例えば、端末Ｘが添付メールを受信したことがメールサーバログから検索された場合（攻撃Ａ１が（１）））、その時点における、端末Ｘの最新パッチの適用状況を調べ、最新パッチが適用されていた場合は、各信頼度は高としてもよい。最新のパッチが適用されている場合は、仮に添付メール等が、マルウェアであっても、感染のリスクが低いからである。
【０２５３】
また、セキュリティ状態が組織内で統一的に管理されており、メールの送信元が同じ組織である場合、送信元のセキュリティ状態を参照してもよい。例えば、メールの送信日時におけるパッチの適用状況が最新ではない場合は、マルウェアに感染している可能性があるため、そのメールの信頼度を低としてもよい。もし、同じ組織からのメールでなくとも、何らかの手段で、その送信者のセキュリティ情報が参照できる場合は、同様の判断を行ってもよい。
【０２５４】
上記の信頼度は、高、中、低、極低等としたが、１００点、５０点、２０点、０点等の点数であってもよい。その場合は、例えば、暗号化された添付メールを受信していた場合、メールアドレスの信頼度が５０点、暗号化された添付メールが付与されているので信頼度を２０点として、合計の信頼度の閾値を１００点とした場合、合計７０点であり、信頼できないと判断してもよい。その場合、この暗号化された添付メールが攻撃Ａ２のきっかけとなった攻撃Ａ１であると判断する。
【０２５５】
上記のように、本実施の形態では、不審なＨＴＴＰ通信をログから検知した場合、その不審なＨＴＴＰ通信はマルウェア等の攻撃により発生しているとみなし、その攻撃が発生するきっかけを、様々なログを遡って調べることで、不審なＨＴＴＰ通信の原因があったか否か判断できる効果がある。
【０２５６】
実施の形態８．
本実施の形態について、主に実施の形態３との差異を説明する。
【０２５７】
実施の形態３では、プロキシログ等を分析した結果から、不審と判断された場合に、アクセスしたウェブサイトについてレピュテーション等を利用して不審か否かを判定した。本実施の形態では、このような不審なＨＴＴＰ通信が発見された場合に該当端末である端末Ｘのセキュリティ状態から、これらの通信が不審か否か判断する。この処理は、攻撃判定部１０７で実行される。
【０２５８】
ログデータベース１１４には、プロキシログが保存されているものとする。ログの検索は、攻撃判定部１０７がログ検索部１０８を使用してログデータベース１１４に対して行う。攻撃判定部１０７がインベントリデータベース１１３に格納された情報を参照する場合、（図示していないが）攻撃判定部１０７はインベントリ検索部１０６を利用してインベントリデータベース１１３の情報を検索し、参照する。
【０２５９】
実施の形態３でも同様であるが、例えば、以下に該当する通信についてプロキシログから検索された場合に不審とみなす。
・端末Ｘが、ホワイトリストにないＵＲＬであるＵＲＬ＿Ｓにアクセスしている。
・端末Ｘから、定期的にこのＵＲＬ＿Ｓにアクセスが行われている。
【０２６０】
本実施の形態では、さらに、以下の（１）〜（３）のいずれか１つ以上に当てはまる場合に、このＨＴＴＰ通信を不審と判断する。
（１）最初のＵＲＬ＿Ｓへのアクセスにおいて、遷移元のＵＲＬであるリファラを調べた結果、リファラが存在しない場合（単独の繰り返しの通信が突然発生したとみなす）、あるいは、リファラが存在しても、それ以前に、そのリファラのＵＲＬへアクセスしていない場合
（２）ＵＲＬ＿Ｓへアクセスした後にアクセスした別のＨＴＴＰ通信のリファラを調べた結果、このリファラがＵＲＬ＿Ｓになっていない場合（ＵＲＬ＿Ｓに関係ない別の通信が発生したとみなす）
（３）以下に説明する場合
【０２６１】
（３）については、ＵＲＬ＿Ｓへの通信の発生からｍ日遡り、端末Ｘのパッチの状態の履歴を調べる。この期間にリリースされたある１つのパッチＰａｔｃｈ＿ｉについて、ΔＴｉ＿Ｘ＝端末ＸにおけるＰａｔｃｈ＿ｉパッチ適用日時−Ｐａｔｃｈ＿ｉのパッチリリース日時、とした場合にΔＴｉ＿ＸはＰａｔｃｈ＿ｉがリリースされてから端末Ｘに適用されるまでの時間差である。そして、ΔＴｉ＿Ｘ＞ｎ時間である場合は、Ｐａｔｃｈ＿ｉについてパッチ未適用の期間があったとみなし、不審な通信と判断する。端末Ｘのパッチ適用履歴やパッチの情報は、インベントリデータベース１１３に格納されている。また、例えば、Ｐａｔｃｈ＿ｉ（ｉ＝１〜ｋ）について、ＡｌｌΔＴ＿Ｘ＝ΣΔＴｉ＿Ｘ、ｉ＝１〜ｋとして、ＡｌｌΔＴ＿Ｘ＜ｐ時間の場合に、安全な状態であったと判断し、ＨＴＴＰ通信は不審ではないと判断してもよい。例えば、ｋ＝３、ｐ＝４であれば、Ｐａｔｃｈ＿１、Ｐａｔｃｈ＿２、Ｐａｔｃｈ＿３が、ＵＲＬ＿Ｓへの最初の通信の発生からｍ日前までにリリースされており、それぞれのリリース日時から端末Ｘに適用した日時の差分であるΔＴ１＿Ｘ、ΔＴ２＿Ｘ、ΔＴ３＿Ｘを足した値が４時間未満であるという判断になる。この場合、各パッチがリリースされてから適用までの時間を、全て足しても４時間未満であるので、「端末Ｘは安全な状態を保っていた」と判断する。したがって、攻撃を受けていないと判断し、よって、このＨＴＴＰ通信は不審ではないと判断する。
【０２６２】
或いは、ΔＴｉ＿Ｘ、ｉ＝１〜ｋのうち、最大のものがｐ未満であった場合に、ＨＴＴＰ通信は不審ではないと判断してもよい。
【０２６３】
或いは、Ｐａｔｃｈ＿ｉ（ｉ＝１〜ｋ）について、パッチが対応する脆弱性のインパクトから、判定に用いるＰａｔｃｈ＿ｉを選択してもよい。例えば、ｉ＝１のパッチで対処される脆弱性はインパクトがＤｏＳであるとする。この脆弱性が攻撃された場合、端末のＣＰＵ（Ｃｅｎｔｒａｌ・Ｐｒｏｃｅｓｓｉｎｇ・Ｕｎｉｔ）の負荷が上がるだけであり、任意のコードを実行されたり、権限が昇格したりする等、それ以上の攻撃に発展する危険性がない。したがって、Ｐａｔｃｈ＿１は、上記の判定に使うパッチから除外してもよい。
【０２６４】
或いは、脆弱性への攻撃の難易度が高いものについて、そのパッチについては、判定で使わないようにしてもよい。難易度の例として、その脆弱性を攻撃する攻撃コードや攻撃方法が世の中に広まっているか否かがある。
【０２６５】
或いは、リモートからの攻撃ができる脆弱性、逆にローカルな攻撃が必要な脆弱性に対するパッチを判定で使わないようにしてもよい。
【０２６６】
或いは、攻撃に認証が必要な脆弱性に対するパッチを判定で使わないようにしてもよい。
【０２６７】
これらの脆弱性についての情報は、インターネット上のウェブサイトに公開されていることがあり、セキュリティログ分析装置１００が定期的にこのウェブサイトにアクセスして情報を取り込むことで、参照可能となる。脆弱性の情報はインベントリデータベース１１３に保存する。
【０２６８】
或いは、Ｐａｔｃｈ＿ｉ（ｉ＝１〜ｋ）について、Ｐａｔｃｈ＿ｉのパッチリリース日時から、端末ＸにおけるＰａｔｃｈ＿ｉパッチ適用日時の間の期間をＮＳＴ＿ｉとする。例えば、Ｐａｔｃｈ＿ｉのパッチリリース日時が２０１３／１０／２２の００：００：００、パッチ適用日時が２０１３／１０／２３の１２：００：００の場合、ＮＳＴ＿ｉ＝２０１３／１０／２２の００：００：００〜２０１３／１０／２３の１２：００：００となる。そして、ＮＳＴ＿ｉに、端末Ｘがウェブサイトへアクセスしたか否かをプロキシログから調べる。ＮＳＴ＿ｉに、端末Ｘがウェブサイトへアクセスした場合は、そのサイトのＵＲＬの不審さから、攻撃を受けたか否かを判定する。ＵＲＬの不審さは組織が持つＵＲＬのホワイトリストにないサイトや、ＵＲＬのブラックリストに掲載されているサイトや、ウェブレピュテーションによる判定から判断する。つまり、パッチが適用されていない期間であるＮＳＴ＿ｉに、ウェブサイトへアクセスした場合は、攻撃を受けた可能性があるため、そのＵＲＬの不審さをもって、攻撃を受けた可能性の有無を判定する。このとき、ＵＲＬのホワイトリスト／ブラックリストやウェブレピュテーションは、パッチが適用されていない期間のものを参照してもよく、最も新しいものを参照してもよい。或いは、これらの両方を参照してもよく、その場合、片方で不審と判断されたことで不審と判定してもよく、両方で不審と判断されたことで不審と判定してもよい。
【０２６９】
また、ＮＳＴ＿ｉに、端末Ｘがウェブサイトへアクセスした回数が予め定めた閾値未満の場合に、攻撃は受けていないと判定し、閾値以上の場合は、攻撃を受けたと判定してもよい。
【０２７０】
また、ＮＳＴ＿ｉに、端末Ｘがメールを受信した場合に、そのメールが不審であれば、攻撃を受けたとみなしてもよい。メールの不審さの判定には、実施の形態７と同様の方法を用いてもよい。
【０２７１】
また、ＮＳＴ＿ｉにおける、Ｐａｔｃｈ＿ｉが対処する脆弱性について、世の中の同脆弱性を狙った攻撃の発生数が別途定める閾値未満である場合は、攻撃を受けていないと判断し、閾値以上であれば、攻撃を受けたと判断してもよい。
【０２７２】
上記の例では、端末Ｘから、定期的にＵＲＬ＿Ｓにアクセスが行われていることをもって不審としたが、端末ＸからのＵＲＬ＿Ｓへのアクセスは、ランダムでもよい。ランダム性の判断は、ＵＲＬ＿Ｓへの１つのアクセスをＨＴＴＰ＿ｊとして、そのタイムスタンプをＨＴＴＰ＿ＴＳ＿ｊとして、時間的に隣り合うアクセス間の間隔を以下のΔｊで定義する。そして、Δｊがランダムか否かを調べればよい。
Δｊ＝ＨＴＴＰ＿ＴＳ＿（ｊ＋１）−ＨＴＴＰ＿ＴＳ＿ｊ（このとき、ｊ＝１〜ｈ）
【０２７３】
また、端末ＸからのＵＲＬ＿Ｓへのアクセスは、稀でもよい。稀かどうかを判断する方法は例えば以下である。
・ＵＲＬ＿Ｓへのアクセスが、α時間に、β回未満である。
・朝（９時〜１０時）α回、昼（１２時〜１３時）β回、夜（１７時〜１８時）γ回のように、ある期間に決まった回数アクセスする。
【０２７４】
また、上記の例では、端末Ｘにおけるパッチの適用状況を判断に用いたが、リリースされているパッチが端末Ｘに適用されていなくても、他のセキュリティ装置で（そのパッチが対応する）脆弱性への攻撃を防御できる場合があり、そのようなセキュリティ装置の設定履歴をセキュリティログ分析装置１００に取り込んで（例えば、インベントリデータベース１１３や攻撃判定部１０７で保存し）参照してもよい。例えば、端末Ｘにパッチ未適用の期間があり脆弱性が残存していても、このようなセキュリティ装置で防御されていた場合は、攻撃を受けていないと判断し、防御されていなかった場合は攻撃を受けていると判断してもよい。
【０２７５】
上記のように、本実施の形態では、不審なＨＴＴＰ通信がある端末で発見された場合に、該当端末のセキュリティ状態を過去に遡り調べることで、これらの通信が攻撃を受けたことにより発生したか否か判断できる効果がある。
【０２７６】
実施の形態９．
本実施の形態について、主に実施の形態８との差異を説明する。
【０２７７】
実施の形態８では、不審なＨＴＴＰ通信が検知された１台の端末について、このＨＴＴＰ通信が本当に不審か、セキュリティ状態を基に判断するが、本実施の形態では、複数の端末で、不審なＨＴＴＰ通信が検知された場合についての判断を行う。
【０２７８】
例えば、以下に該当する通信についてプロキシログから検索された場合に不審と判断する。
・端末Ｘと端末Ｙが、ホワイトリストにないＵＲＬであるＵＲＬ＿Ｓにアクセスしている。
・端末Ｘから、定期的にＵＲＬ＿Ｓにアクセスが行われている。
・端末Ｙから、定期的にＵＲＬ＿Ｓにアクセスが行われている。
【０２７９】
本実施の形態では、さらに、以下の（１）〜（３）のいずれか１つ以上に当てはまる場合に、このＨＴＴＰ通信を不審と判断する。
（１）端末Ｘの最初のＵＲＬ＿Ｓへのアクセスにおいて、遷移元のＵＲＬであるリファラを調べ、端末Ｙの最初のＵＲＬ＿Ｓへのアクセスにおいて、遷移元のＵＲＬであるリファラを調べた結果、端末Ｘと端末Ｙにおけるこれらのリファラが同じである場合
（２）端末Ｘにおいて、ＵＲＬ＿Ｓへアクセスした後にアクセスした別のＨＴＴＰ通信のリファラを調べ、端末Ｙにおいて、ＵＲＬ＿Ｓへアクセスした後にアクセスした別のＨＴＴＰ通信のリファラを調べた結果、これらのリファラがＵＲＬ＿Ｓになっていない場合
（３）端末ＸにおいてＵＲＬ＿Ｓへのアクセスの「前ｑ時間／後ｒ時間」にアクセスしているサイトをＵＲＬ＿Ｘとし、端末ＹにおいてＵＲＬ＿Ｓへのアクセスの「前ｑ時間／後ｒ時間」にアクセスしているサイトをＵＲＬ＿Ｙとしたとき、ＵＲＬ＿ＸとＵＲＬ＿Ｙがある一定の割合以上で一致する場合
（４）以下に説明する場合
（５）以下に説明する場合
【０２８０】
（４）については、端末Ｘと端末Ｙにおいて、パッチのリリース後、パッチが適用されていない期間があった場合に、その期間におけるウェブアクセスの有無を調べる。そして、このウェブアクセスが不審かウェブレピュテーションやＵＲＬホワイトリストやブラックリスト等で調べる。端末Ｘと端末Ｙにおけるこの期間におけるウェブアクセスの状態を比較することで、端末Ｘと端末Ｙが攻撃されたか否かを図１４のように判定してもよい。
【０２８１】
例えば、端末Ｘにおいてパッチ未適用の期間があり、かつ、不審ウェブアクセスがあった場合、端末Ｙにおいてパッチ未適用の期間があり、かつ、不審ウェブアクセスがあった場合、両端末で、安全でない期間に不審なウェブサイトにアクセスしていたので、マルウェアに感染し、その結果、後で、ＵＲＬ＿Ｓへ定期的にアクセスが発生したと判断する。
【０２８２】
例えば、端末Ｘにおいてパッチ未適用の期間があり、かつ、不審ウェブアクセスがなかった場合、端末Ｙにおいてパッチ未適用の期間があり、かつ、不審ウェブアクセスがあった場合、端末Ｙのみが、安全でない期間に不審なウェブサイトにアクセスしていたので、マルウェアに感染し、その結果、後で、ＵＲＬ＿Ｓへ定期的にアクセスが発生したと判断する。端末ＸにおけるＵＲＬ＿Ｓへの定期的な通信は誤検知とみなす。パッチ未適用の期間については、実施の形態８に従ってもよい。
【０２８３】
（５）については、パッチ未適用の期間があった場合に、その期間における不審なメールの受信の有無を調べる。そして、端末Ｘと端末Ｙにおけるこの期間における不審なメールの有無を比較することで、端末Ｘと端末Ｙが攻撃されたか否かを図１４のように判定してもよい。このとき、図１４における、「不審ウェブアクセス」を「不審メール」に置き換える。
【０２８４】
また、本実施の形態では、ログ分析のきっかけとする、端末Ｘと端末Ｙが行う不審なＨＴＴＰ通信先のＵＲＬについて、同じもの（ＵＲＬ＿Ｓ）としたが、別のＵＲＬでもよい（端末Ｘ：ＵＲＬ＿Ｓ、端末Ｙ：ＵＲＬ＿Ｓ’）。ただし、それらのＵＲＬはホワイトリストにないものである。
【０２８５】
また、本実施の形態では、パッチ未適用期間に端末ＸがアクセスしたＵＲＬは、ＵＲＬ＿Ｓであっても別のものでもよい。同様に、端末Ｙについても、パッチ未適用期間の通信についても、ＵＲＬ＿Ｓであっても別のものでもよい。
【０２８６】
また、本実施の形態では、ＵＲＬ＿ＳやＵＲＬ＿Ｓ’はホワイトリストにないものとしたが、ブラックリストにあるものとしてもよい。また、ウェブレピュテーションでスコアが閾値以下のものであってもよい。
【０２８７】
また、上記の例では、２つの端末Ｘ，Ｙを対象としているが、さらに複数の端末を対象としてもよい。
【０２８８】
上記のように、本実施の形態では、不審なＨＴＴＰ通信が複数の端末で発見された場合に、該当端末のセキュリティ状態を過去に遡り調べ、安全ではない期間に、不審なウェブサイトにアクセスしたり、不審なメールを受信したか調べることで、これらの通信が攻撃を受けたことにより発生したか否か判断できる効果がある。
【０２８９】
本実施の形態において、セキュリティ対策を管理していない組織においては、セキュリティ対策情報５００が検索されなかった場合の処理を行えばよい。また、インベントリを管理していない組織においては、インベントリ情報２０９が検索されなかった場合の処理を行えばよい。
【０２９０】
実施の形態１０．
本実施の形態について、主に実施の形態１との差異を説明する。
【０２９１】
本実施の形態では、攻撃シナリオ２０４に従って攻撃を検知した結果、情報漏洩の攻撃が疑われる、或いは、攻撃シナリオ２０４に従えば、今後起こり得ることが分かっている場合、セキュリティログ分析装置１００がプロキシサーバと連携して、強制的にＨＴＴＰ通信を制御する。
【０２９２】
図１５は、制御命令２１７の構成の一例を示す図である。
【０２９３】
攻撃判定部１０７は、例えば、実施の形態５のように現在検知された攻撃のスコア４０５の合計が閾値を超えた時点で、将来起こり得る攻撃に情報漏洩が含まれている場合は、制御命令２１７を生成し、出力部１０９に出力する。
【０２９４】
図１５に示すように、制御命令２１７は、以下の情報で構成される。
（ａ）期間：制御を行う期間（例えば、２０１３／１０／０１の００：００：００〜２０１３／１０／３１の２３：５９：５９）である。
（ｂ）送信元情報：攻撃判定部１０７が攻撃シナリオ２０４とログ分析により攻撃されている可能性があると判断した端末の情報（例えば、ＩＰアドレス）である。
（ｃ）送信先情報：攻撃判定部１０７が攻撃シナリオ２０４とログ分析により攻撃元と判断した通信相手の情報（例えば、ウェブサーバのホスト名）である。
（ｄ）制御情報：プロキシサーバに対する制御の命令である。
【０２９５】
制御命令２１７は、送信元情報で示される端末から送信先情報で示されるサーバ等への通信に対し、期間として指定する間、制御情報で示す制御を行うことを命令するデータである。制御情報の命令の内容として、例えば、ＨＴＴＰを全て遮断、ＨＴＴＰのＧＥＴを遮断、ＨＴＴＰのＰＯＳＴを遮断、ＣＯＮＮＥＣＴを遮断、認証の強制（ＨＴＴＰリクエストの送信のために認証情報を提供する）がある。また、これらに、「ｍ回につき１回の通信を遮断」、「ランダムに遮断」等の条件を組み合わせてもよい。例えば、制御情報は、「ＤｅｎｙＨＴＴＰ＝ＯＮ，Ｍｅｔｈｏｄ＝ＰＯＳＴ，ＣＯＮＤＩＴＩＯＮ＝１：ｍ」（ＨＴＴＰ通信のＰＯＳＴメソッドをｍ回につき１回遮断せよ、という意味である）といったものになる。
【０２９６】
送信先情報として、ＡＮＹ（全ての送信先）を指定して、攻撃されている可能性のある端末については全ての通信を制御してもよい。また、送信元情報として、ＡＮＹ（全ての送信元）を指定して、攻撃元が疑われる通信相手（例えば、ウェブサーバ）については、全ての端末からの通信を制御するようにしてもよい。
【０２９７】
出力部１０９は、制御命令２１７を受け取ると、プロキシサーバに出力する。プロキシサーバは制御命令２１７を入力すると、制御命令２１７を解釈して該当する通信を制御する。プロキシサーバにおける制御命令２１７の解釈は、これらのサーバに既に備わっている機能を使うことが望ましい。よって、制御命令２１７は、これらのサーバが解釈できるフォーマットに変形しても構わない。また、出力部１０９がプロキシサーバに制御命令２１７を出力する方法としては、プロキシサーバが入力可能な方法であれば任意の方法でよい。例えば、これらのサーバがＳＮＭＰ（Ｓｉｍｐｌｅ・Ｎｅｔｗｏｒｋ・Ｍａｎａｇｅｍｅｎｔ・Ｐｒｏｔｏｃｏｌ）のトラップメッセージを受信して、制御命令２１７を解釈できるのであれば、トラップメッセージに制御命令２１７を含めて、これらのサーバにネットワークを経由して送信してもよい。
【０２９８】
制御情報は、通信の遮断だけでなく、プロキシサーバがワークフローシステムと連携しているのであれば、このワークフローシステムの使用を強制するように指定してもよい。例えば、制御情報は、「ＵｓｅＷｏｒｋＦｌｏｗ＝ＯＮ，Ｐｒｏｔｏｃｏｌ＝ＨＴＴＰ，Ｍｅｔｈｏｄ＝ＰＯＳＴ」（ＨＴＴＰ通信のＰＯＳＴメソッドには、ワークフローを強制適用せよ、という意味である）といったものになる。
【０２９９】
ここでのワークフローシステムとは、あるユーザが、ウェブサイトへファイル等のデータを送信する場合に、上長の許可を得ないと送信できないような仕組みをもったシステムであり、例えば、以下のような手順が用いられる。
（１）ユーザＡが、ウェブサイトＸへ、ＨＴＴＰのＰＯＳＴで１メガバイトのファイルを送信する（ＨＴＴＰ・ＰＯＳＴリクエスト）。このＨＴＴＰ・ＰＯＳＴリクエストはプロキシサーバへ送信される。
（２）ユーザＡからのＨＴＴＰ・ＰＯＳＴリクエストはプロキシサーバと連携するワークフローシステムへフォワードされ、保留される。
（３）ワークフローシステムは、ユーザＡの上長Ｂへ、メールにより、ユーザＡが組織外へデータを送信しようとしていることを通知する。
（４）上長Ｂはワークフローシステムへアクセスし、該当するＨＴＴＰ・ＰＯＳＴリクエストを目視で確認する。宛先や送信データ（ファイル）に問題がなければ、ワークフロー上で許可する。
（５）ワークフローシステムは、上長Ｂからの許可が下りた場合、プロキシサーバへ該当するＨＴＴＰ・ＰＯＳＴリクエストをフォワードする。
（６）プロキシサーバは、該当するＨＴＴＰ・ＰＯＳＴリクエストをウェブサイトＸへ送信する。
【０３００】
プロキシサーバは、制御命令２１７に「ＵｓｅＷｏｒｋＦｌｏｗ＝ＯＮ」が指定されていた場合は、ワークフローシステムへ該当するリクエストをフォワードし、ワークフローシステムの使用を強制する。この結果、例えば、マルウェアがＨＴＴＰのＰＯＳＴでデータを送信しようとしても、上長Ｂのチェックが入るため、不審なＰＯＳＴは防止される。
【０３０１】
プロキシサーバと検査サーバが連携しており、検査サーバにおいて、上記のような通信の制御を受け付けて、プロキシサーバを制御するのであれば、制御命令２１７を検査サーバに送信すればよく、そのフォーマットも検査サーバが解釈可能な形式にすればよい。プロキシサーバとワークフローシステムが連携しており、ワークフローシステムにおいて、上記のような通信の制御を受け付けて、プロキシサーバを制御するのであれば、制御命令２１７をワークフローシステムに送信すればよく、そのフォーマットもワークフローシステムが解釈可能な形式にすればよい。
【０３０２】
以上説明したように、本実施の形態において、攻撃判定部１０７は、攻撃シナリオデータベース１１１に記憶された攻撃シナリオ２０４が実行されたと判定した場合、当該攻撃シナリオ２０４で定義されている複数の攻撃のうち、上記コンピュータシステムに備えられた検知装置により未だ検知されておらず、当該攻撃シナリオ２０４で定義されている順番が上記検知装置により最後に検知された攻撃（例えば、攻撃Ａ４）よりも後の攻撃（例えば、攻撃Ａ５）を抽出し、上記コンピュータシステムに対し、抽出した攻撃の経路となる通信を制限する。
【０３０３】
上記のように、本実施の形態では、不審な攻撃シナリオ２０４に従い不審なＨＴＴＰ通信や今後の情報漏洩が疑われる場合、プロキシサーバや連携するワークフローシステムにＨＴＴＰ通信を制御する指示を送ることで、以後、ＨＴＴＰ通信を制御することで被害の拡大を抑制できる効果がある。
【０３０４】
図１６は、実施の形態１〜１０に係るセキュリティログ分析装置１００のハードウェア構成の一例を示す図である。
【０３０５】
図１６において、セキュリティログ分析装置１００は、コンピュータであり、出力装置９１０、入力装置９２０、記憶装置９３０、処理装置９４０といったハードウェアを備える。ハードウェアは、セキュリティログ分析装置１００の各部（本発明の実施の形態の説明において「〜部」として説明するもの）によって利用される。
【０３０６】
出力装置９１０は、例えば、ＬＣＤ（Ｌｉｑｕｉｄ・Ｃｒｙｓｔａｌ・Ｄｉｓｐｌａｙ）等の表示装置、プリンタ、通信モジュール（通信回路等）である。出力装置９１０は、各部（「〜部」）によってデータ、情報、信号の出力（送信）のために利用される。
【０３０７】
入力装置９２０は、例えば、キーボード、マウス、タッチパネル、通信モジュール（通信回路等）である。入力装置９２０は、各部（「〜部」）によってデータ、情報、信号の入力（受信）のために利用される。
【０３０８】
記憶装置９３０は、例えば、ＲＯＭ（Ｒｅａｄ・Ｏｎｌｙ・Ｍｅｍｏｒｙ）、ＲＡＭ（Ｒａｎｄｏｍ・Ａｃｃｅｓｓ・Ｍｅｍｏｒｙ）、ＨＤＤ（Ｈａｒｄ・Ｄｉｓｋ・Ｄｒｉｖｅ）、ＳＳＤ（Ｓｏｌｉｄ・Ｓｔａｔｅ・Ｄｒｉｖｅ）である。記憶装置９３０には、プログラム９３１、ファイル９３２が記憶される。プログラム９３１には、各部（「〜部」）の処理（機能）を実行するプログラムが含まれる。ファイル９３２には、各部（「〜部」）によって演算、加工、読み取り、書き込み、利用、入力、出力等が行われるデータ、情報、信号（値）等が含まれる。
【０３０９】
処理装置９４０は、例えば、ＣＰＵである。処理装置９４０は、バス等を介して他のハードウェアデバイスと接続され、それらのハードウェアデバイスを制御する。処理装置９４０は、記憶装置９３０からプログラム９３１を読み出し、プログラム９３１を実行する。処理装置９４０は、各部（「〜部」）によって演算、加工、読み取り、書き込み、利用、入力、出力等を行うために利用される。
【０３１０】
本発明の実施の形態の説明において「〜部」として説明するものは、「〜回路」、「〜装置」、「〜機器」であってもよく、また、「〜ステップ」、「〜工程」、「〜手順」、「〜処理」であってもよい。即ち、「〜部」として説明するものは、ソフトウェアのみ、ハードウェアのみ、或いは、ソフトウェアとハードウェアとの組み合わせで実現される。ソフトウェアは、プログラム９３１として、記憶装置９３０に記憶される。プログラム９３１は、本発明の実施の形態の説明で述べる「〜部」としてコンピュータを機能させるものである。或いは、プログラム９３１は、本発明の実施の形態の説明で述べる「〜部」の処理をコンピュータに実行させるものである。
【０３１１】
以上、本発明の実施の形態について説明したが、これらの実施の形態のうち、２つ以上を組み合わせて実施しても構わない。或いは、これらの実施の形態のうち、１つを部分的に実施しても構わない。或いは、これらの実施の形態のうち、２つ以上を部分的に組み合わせて実施しても構わない。例えば、これらの実施の形態の説明において「〜部」として説明するもののうち、いずれか１つのみを採用してもよいし、いずれか２つ以上の任意の組み合わせを採用してもよい。なお、本発明は、これらの実施の形態に限定されるものではなく、必要に応じて種々の変更が可能である。
【符号の説明】
【０３１２】
１００  セキュリティログ分析装置、１０１  入力部、１０２  解釈部、１０３  攻撃シナリオ検索部、１０４  関連攻撃抽出部、１０５  セキュリティ対策検索部、１０６  インベントリ検索部、１０７  攻撃判定部、１０８  ログ検索部、１０９  出力部、１１１  攻撃シナリオデータベース、１１２  セキュリティ対策データベース、１１３  インベントリデータベース、１１４  ログデータベース、２０１  検知データ、２０２  検知情報、２０３  攻撃識別情報、２０４  攻撃シナリオ、２０５  関連攻撃情報、２０６  関連攻撃検索情報、２０７  対策有無情報、２０８  インベントリ検索情報、２０９  インベントリ情報、２１３  ログ検索情報、２１４  検索命令、２１５  検索結果、２１６  判定結果、２１７  制御命令、３０１  検知結果、３０２  シナリオ抽出条件、３０３  関連攻撃抽出条件、３０４  既検知結果、３０５  検索条件、３１０  判定結果、３２１  公開脆弱性情報、３２２  攻撃情報、３２３  攻撃対応情報、３２４  警告情報、４０１  攻撃識別情報、４０２  攻撃情報、４０３  対策識別情報、４０４  対策情報、４０５  スコア、５００  セキュリティ対策情報、５０１  攻撃識別情報、５０２  攻撃情報、５０３  対策識別情報、５０４  対策情報、５０５  対策実施情報、６０１  資産識別情報、６０２  資産ＯＳ情報、６０３  資産アプリケーション情報、６０４  資産実行情報、６０５  資産セキュリティ施策情報、９１０  出力装置、９２０  入力装置、９３０  記憶装置、９３１  プログラム、９３２  ファイル、９４０  処理装置。
【図１】
2015121968.tif 000003
【図２】
2015121968.tif 000004
【図３】
2015121968.tif 000005
【図４】
2015121968.tif 000006
【図５】
2015121968.tif 000007
【図６】
2015121968.tif 000008
【図７】
2015121968.tif 000009
【図８】
2015121968.tif 000010
【図９】
2015121968.tif 000011
【図１０】
2015121968.tif 000012
【図１１】
2015121968.tif 000013
【図１２】
2015121968.tif 000014
【図１３】
2015121968.tif 000015
【図１４】
2015121968.tif 000016
【図１５】
2015121968.tif 000017
【図１６】
2015121968.tif 000018