(57)【要約】【課題】  本発明の目的は、侵入検知ポリシの設定を簡便に行える解析対象データを作成する仕組みを提案することにあり、具体的には複数のシグネチャをひとつの侵入検知ポリシとしてまとめてパターンマッチするポリシ設定ができること、および、攻撃とそれに対するレスポンスという文脈をパターンマッチするポリシ設定ができることにある。【解決手段】  本発明の通信状態遷移モニタ手法は、ネットワーク上で伝送されているパケットを取り込み、階層化されたプロトコルの通信内容を追跡して状態遷移を推測し、任意の情報通信ステーション内の通信状態をモニタするものであって、複数シグネチャの簡便な関連性設定と攻撃・レスポンスのペア化を用いた文脈設定を実現するため、複数ストリームからの解析データ取得機能とストリームペア化機能を備えるものとした。【選択図】  図２
2006211609.tif 000002
【特許請求の範囲】
【請求項１】
情報通信ステーションの間で階層化されたプロトコルにより通信を行うように構築されたネットワークにおける通信の状態遷移をモニタする方法であって、前記ネットワーク上で伝送されているパケットを取り込み、階層化されたプロトコルの通信内容を追跡して状態遷移を推測し、任意の情報通信ステーション内の通信状態をモニタすることを特徴とする通信状態遷移モニタ方法。
【請求項２】
階層化された通信内容を解析する機能部ＡＡと解析結果対応する通信処理機能部ＣＡＰＳとが完全に分離された通信状態遷移を推測するシステムにおいて、前記ＡＡから前記ＣＡＰＳへ解析対象の層や数について必要データの要求を出して複数の通信パスを１つの視点から同時に監視することを特徴とする通信状態遷移モニタ方法。
【請求項３】
前記必要データの要求はパラメータ指定により解析対象に応じて必要となる解析データであって、解析対象の層や数を限定することなく再構築アルゴリズムを可変化可能とすることを特徴とする請求項２に記載の通信状態遷移モニタ方法。
【請求項４】
前記必要データの要求に応じ、ＣＡＰＳは階層化された通信内容のシーケンス番号とアクノリッジ番号の両方を用いてストリームペアを一元的に／各一方向通信のみ再構築することが適宜可能であることを特徴とする請求項２に記載の通信状態遷移モニタ方法。
【請求項５】
シーケンス番号とアクノリッジ番号の両方を用いてストリームペアとして連続した通信となっていることを確認し、上位層へデータを転送することにより、パケット情報を要求に沿った時系列にそろえることを特徴とする請求項４に記載の通信状態遷移モニタ方法。
【請求項６】
パケット情報における各データ部の最初と最後の接続情報を書き込んだパケット構造体を、ヘッダ部を付けたまま各パケットに付加することにより、再構築データ及びパケットヘッダの両方を同時に評価することができることを特徴とする請求項２に記載の通信状態遷移モニタ方法。
【請求項７】
情報通信ステーションの間で階層化されたプロトコルにより通信を行うように構築されたネットワークにおける通信の状態遷移をモニタする装置であって、該装置は前記ネットワーク上で伝送されているパケットを取り込む手段と、階層化されたプロトコルの通信内容を追跡して状態遷移を推測する手段とを備え、任意の情報通信ステーション内の通信状態をモニタすることを特徴とする通信状態遷移モニタ装置。
【請求項８】
階層化された通信内容を解析する機能部ＡＡと解析結果対応する通信処理機能部ＣＡＰＳとが完全に分離された通信状態遷移を推測するシステムであって、前記ＡＡから前記ＣＡＰＳへ解析対象の層や数について必要データの要求を出す手段を備え、複数の通信パスを１つの視点から同時に監視することを特徴とする通信状態遷移モニタ装置。
【請求項９】
前記必要データの要求を出す手段はパラメータ指定により解析対象に応じて必要となる解析データの要求を出す手段であって、解析対象の層や数を限定することなく再構築アルゴリズムを可変化する機能を備えていることを特徴とする請求項８に記載の通信状態遷移モニタ装置。
【請求項１０】
前記必要データの要求に応じ、階層化された通信内容のシーケンス番号とアクノリッジ番号の両方を用いてストリームペアを一元的に／各一方向通信のみ再構築することが適宜可能である手段をＣＡＰＳに備えたことを特徴とする請求項８に記載の通信状態遷移モニタ装置。
【請求項１１】
パケット情報のシーケンス番号とアクノリッジ番号の両方を用いて、ストリームペアとして連続した通信となっていることを確認する手段と、該確認情報と共に上位層へデータを転送する遅延再構築機能部とを備え、転送はパケット情報を要求に沿った時系列にそろえることを特徴とする請求項１０に記載の通信状態遷移モニタ装置。
【請求項１２】
パケット情報における各データ部の最初と最後の接続情報をパケット構造体に書き込む手段と、ヘッダ部を付けたまま該パケット構造体を各パケットに付加する手段とを備え、再構築データ及びパケットヘッダの両方を同時に評価する機能を備えたことを特徴とする請求項８に記載の通信状態遷移モニタ装置。
【請求項１３】
情報通信ステーションの間で階層化されたプロトコルにより通信を行うように構築されたネットワークにおける通信の状態遷移をモニタするシステム用のものであって、前記ネットワーク上で伝送されているパケットを取り込み、階層化されたプロトコルの通信内容を追跡して状態遷移を推測し、任意の情報通信ステーション内の通信状態遷移をモニタすることを特徴とするプログラムを記録したコンピュータ読み取り可能な記録媒体。
【請求項１４】
階層化された通信内容を解析する機能部ＡＡと解析結果対応する通信処理機能部ＣＡＰＳとが完全に分離された形態の通信の状態遷移をモニタするシステム用のものであって、前記ＡＡから前記ＣＡＰＳへ解析対象の層や数について必要データの要求を出して複数の通信パスを１つの視点から同時に監視することを特徴とするプログラムを記録したコンピュータ読み取り可能な記録媒体。
【請求項１５】
前記必要データの要求プログラムは解析対象に応じて必要となる解析データをパラメータ指定により行うものであって、解析対象の層や数を限定することなく再構築アルゴリズムを可変化することを特徴とするプログラムを記録したことを特徴とする請求項１４に記載のコンピュータ読み取り可能な記録媒体。
【請求項１６】
前記必要データの要求に応じ、ＣＡＰＳにおいて階層化された通信内容のシーケンス番号とアクノリッジ番号の両方を用いてストリームペアを一元的に／各一方向通信のみ再構築することが適宜可能であることを特徴とするプログラムが記録された請求項１４に記載のコンピュータ読み取り可能な記録媒体。
【請求項１７】
シーケンス番号とアクノリッジ番号の両方を用いてストリームペアとして連続した通信となっていることを確認し、上位層へデータを転送することにより、パケット情報を要求に沿った時系列にそろえることを特徴とするプログラムが記録された請求項１６に記載のコンピュータ読み取り可能な記録媒体。
【請求項１８】
パケット情報における各データ部の最初と最後の接続情報をパケット構造体に書き込むと共に、該パケット構造体を、ヘッダ部を付けたまま各パケットに付加することにより、再構築データ及びパケットヘッダの両方を同時に評価できることを特徴とするプログラムが記録された請求項１４に記載のコンピュータ読み取り可能な記録媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワークを利用した通信システムにおける不正アクセスを検知する通信状態遷移モニタ方法及びこれを利用した通信状態遷移モニタ装置、更には通信状態遷移モニタプログラムとそのプログラムを記録したコンピュータ読み取り可能な記録媒体に関する。
【背景技術】
【０００２】
インターネット利用時のセキュリティ確保が重要な課題であるという認識は既に一般社会まで浸透している。物理的な被害を受けなくても、情報の流出、破壊は社会や組織に大きなダメージを与えることがある。計算機を接続する手段としてインターネットが一般的となった現在、インターネット経由での情報伝達あるいは情報管理に関して最大限の注意が払われるべきであろう。現在、安全性向上の一つの手段としてファイヤーウォールと共に、侵入検知システム(以下、ＩＤＳ：Intrusion Detection System)が利用されている。
【０００３】
このＩＤＳはネットワークを流れるパケットや計算機のファイルの状況をチェックすることにより、侵入やその前兆が発生していないかチェックするシステムである。一部に侵入を検知した場合、その通信を遮断する機能を持つものもあり、これをＩＰＳ，ＩＤＰ等と呼んで区別することもあるが、本明細書では、防御機能まで含めてＩＤＳと呼ぶものとする。既存のＩＤＳでは、侵入行為ではないものを侵入行為として認識してしまう誤検知や膨大なログが生成され、これがＩＤＳ利用における大きな課題となっている。侵入検知精度を高めるために、ＩＤＳにログ分析機能が付加されてきたが、その背景には、この膨大なログ生成の問題がある。本発明者は、この膨大なログ生成の原因が侵入検知ポリシの設定の難しさにあると考えている。つまり、検知したい事象を絞り込んでポリシ記述することが難しいため、ポリシの記述が部分的／断片的なものになり、その結果、本来検知したい事象を抽出する役割を、ログ分析機能に委ねているためと考えられる。
【０００４】
本発明の基本的な目的は、ポリシの記述性を向上させることにより検知したい事象を正確にポリシとして記述し、その結果、検知漏れを増加させることなくログ出力量を低減させ、侵入検知精度を高めることのできるＩＤＳシステムを実現することにある。現在、侵入検知ポリシの設定は、ＴＣＰやＩＰのＯＳＩの第４層以下(以下、下位層と呼ぶ)の知識を持つパケット解析に熟練したスキルを持つ者(以下、ネットワーク専門家と呼ぶ)が、ソフトウェアベンダ等が配布するポリシを利用したり、また、自ら記述したりして行うことが一般的である。しかし、この方法では、ネットワーク専門家等、一部の専門家のみがポリシ設定や監視を行うこととなり、セキュリティツールとしてのＩＤＳの利用者層を広げることが難しい。また、ポリシの設定内容も、下位層の監視のみならず、ＯＳＩの第５層以上(以下、上位層と呼ぶ)の上でのコマンド利用の監視を行うことで、高精度な、つまり、検知したい不正行為をより正確に定義できることになると考えられるが、ネットワーク専門家は必ずしもアプリケーションコマンドの体系やその正しい利用法を熟知しているわけではない。一方、下位層の知識は少なくても、各々のアプリケーション等上位層に対して深い解析能力を持つ者(以下、アプリケーション熟練者と呼ぶ)もいる。アプリケーション熟練者が侵入検知ポリシを記述できるようになれば、上位層でより正確なポリシ記述が可能となる。つまり、侵入検知精度を高くするには、下位層から上位層までポリシ全体を正確に記述することが必要で、そのためには、ネットワーク専門家は下位層のポリシを、アプリケーション熟練者は上位層でのポリシを、それぞれ分担して記述するという、ポリシ記述の分業を可能とする構造がＩＤＳに求められていると考える。
【０００５】
既存システムの現状に触れる前に、ＩＤＳを構成する機能について定義しておく。非特許文献１にリファレンスモデルＣＩＤＦ（Common Intrusion Detection Framework）が提案されている。これは、Event Generators, Event Analyzers, Response Units, Event DatabasesをＩＤＳ構成機能として提案している。本明細書では、このEvent Generators機能の部分を、データ収集機能とデータ作成機能に分割し、また、ログ分析機能を追加した次の６つの機能：データ収集機能(Data Collection)、データ作成機能(Data Generation)、データ解析機能(Data Analysis)、アクション機能(Action)、記録機能(Record)、ログ分析機能(Log Analysis)で構成されるモデルで話を進める(図１１参照)。なお、以下簡単化のために、不正アクセス処理システム（Cracking Analyzer）をＣＡと呼び、そのＣＡにおけるデータ収集機能とデータ作成機能をまとめてＣＡＰＳ（Cracking Analysis Protocol Stack）と、データ解析機能とアクション機能をまとめてＡＡ（Application Analyzer）と呼ぶこととする。
【０００６】
ＩＤＳの開発は、商用・フリーウェアを問わず積極的に行われ、RealSecure Network Sensor，Dragon Host Sensor, Cisco IDS, Snort（非特許文献２）やTripwire等が開発されている。前者３つは商用、後者２つはフリーウェアである。本出願人等も情報通信ステーションの間で階層化されたプロトコルにより通信を行うように構築されたネットワークにおける不正を解析する方法であって、前記ネットワーク上で伝送されているパケットを取り込むデータ収集工程と、階層化されたプロトコルに応じた階層化モジュールのパラメータを予め読み込んでおいたコンフィグレーションファイルで指定された情報に基づいて設定し、前記データ収集工程からのパケットを前記各階層化モジュールでフィルタリングして前記パケットの細分化されたデータを予め設定した階層にまで再構築することにより解析データを作成するデータ作成工程と、予め読み込んでおいたコンフィグレーションファイルで指定された内容を基に前記データ作成工程からの解析データに不正が発生しているか判定するデータ解析工程とを備えたネットワーク不正解析方法（特許文献１）を提示している。
【０００７】
既存システムは適材適所で有効に利用されているが、実用においては、いくつかの問題点が指摘されている。それらの指摘を整理すると、ＩＤＳの解決すべき課題を以下のようにまとめることができる。
（１）侵入検知ポリシの設定が難しい。(２)対応ＯＳが限定される。(３)パフォーマンスが不足している。(４)暗号通信を解析できない。(５)導入コストが高い。(６)既存アプリケーション環境を変更しなければならない。
【特許文献１】特開平１０−３１３３４１号公報  「ネットワーク不正解析方法及びこれを利用したネットワーク不正解析装置並びにネットワーク不正解析プログラムを記録したコンピュータ読み取り可能な記録媒体」  平成１０年１１月２４日公開
【非特許文献１】Internet Security Systems. Real Secure Network Sensor Policy  Guide Version7.0,http://www.isskk.co.jp/manual/RS_NetSensor_PG_7.0j_pdf,2002
【非特許文献２】B. Caswell, J. Beale, J.C. Foster, J. Posluns, R. Russell,  渡辺勝弘, 鹿田幸治, Snort 翻訳プロジェクト訳「Snort 2.0 侵入検知」  ソフトバンクパブリッシング  2004年
【発明の開示】
【発明が解決しようとする課題】
【０００８】
本発明は、上記したＩＤＳの解決すべき課題のうち指摘の多い"侵入検知ポリシの設定が難しい"ことを解決するために、侵入検知ポリシの設定を簡便に行える解析対象データを作成する仕組みを提案することにある。これは、図１１に示すＩＤＳの機能においてはデータ作成機能の改善と言える。
【０００９】
本発明の課題を明確にするために、ここではまず、侵入検知ポリシ設定に関する現状を整理しておく。検知対象例として著名な"Nimda"ワームを取り上げる。"Nimda"ワームは、ＴＣＰ２５，ＴＣＰ８０，ＴＣＰ１３９，ＴＣＰ４４５等、多数のポートを使用してワームとしての活動を行う。ここで、"Nimda"ワームからの攻撃を受けているホストを検知することを考える。図１２に著名なＩＤＳであるSnortでの検出シグネチャを示す。このシグネチャではＴＣＰ１３９番を用いたワーム活動を記述している。上記に示したポートはごく標準的に使用されるポートであるため、このポートヘの接続活動を個々に検知するだけでは、例えば正しいWindows(登録商標)ネットワーク通信もワーム活動として誤検知してしまう。ワーム活動を検知するには、上記多数のポートが関連性を持って利用されていることを確認する必要がある。この問題点の解決方法として、関連する複数のシグネチャをひとつにまとめて利用者に提供するシステム［Real Secure Network Sensor］や、個々の検知結果が出力するログの関連性を分析するツールを利用する方法などが研究されている。しかし、ソフトウエアベンダ等が提供するシグネチャ群は一般的な記述であるため、個別サイトに実際に適用する場合には修正は免れない。例えば、個別サイトの実情に合わせるため、シグネチャの中に埋め込まれているホスト情報をポリシ全体にわたってネットワーク専門家が一つ一つ変更したり、ポリシに含まれるアプリケーションの通信パターンが正しい利用状況下でも発生する場合は、アプリケーション熟練者の助言のもとでネットワーク専門家が、そのパターンを含むシグネチャを削除または修正する必要があったりする。つまり、誤検知を防ぐ目的で改善がなされているが、依然としてポリシ設定には高度な能力が必要になる状況は改善されていないことになる。
【００１０】
また、個々のシグネチャ検知時にも課題がある。例えば"Nimda"ワーム活動の特徴的な文字列である"ＧＥＴ/scripts/root.exe?/c+dir"を検知する場合を考える。ワーム活動が成功するのは、この文字列がhttpのＧＥＴコマンドとして出現し、かつ、コマンドが成功した場合であり、コマンドとして意味を持たない文脈の中でこの文字列が検知されたり、コマンドが成功しなかったりした場合は、実害は発生しないがログに記録されることになる。このログ蓄積について、有用なログと見るか誤検知と見るかは監視の目的により見解が分かれる。管理しているネットワークで日々何が起こっているのかを把握したいのであれば攻撃の試みのログは有用であり、一方、攻撃が成功したことを検知したいのであれば誤検知となる。ネットワークセキュリティの観点からは、攻撃の試みを検知することは重要な機能のひとつである一方、迅速な対応を迫られるインシデント発生時においては、実際に攻撃の被害を受けてしまったホストを特定し記録しているＩＤＳのログは、被害拡大の防止作業に役立つ。コマンドとして意味を持たない文脈の中でパターンが検知されないようにする方法として、文脈フィルターを用いるシステムがある［Real Secure Network Sensor］。しかし、この方法で保証するのは、パターンマッチ対象をhttpのＧＥＴコマンドに限定することだけで、このＧＥＴコマンドが成功したことを含めて侵入行為が発生したと検出するには至っていない。
以上より、本発明による侵入検知ポリシ設定における課題をまとめると、以下の２点になる。
(課題１)  複数シグネチャの簡便な関連性設定、すなわち、複数のシグネチャをひとつの侵入検知ポリシとしてまとめてパターンマッチするポリシ設定ができること。
(課題２)  攻撃とレスポンスのペア化による文脈設定、すなわち、攻撃とそれに対するレスポンスという文脈をパターンマッチするポリシ設定ができること。
すなわち、本発明の目的は、侵入検知ポリシの設定を簡便に行える解析対象データを作成する仕組みを提案することにあり、具体的には複数のシグネチャをひとつの侵入検知ポリシとしてまとめてパターンマッチするポリシ設定ができるようにすること、および、攻撃とそれに対するレスポンスという文脈をパターンマッチするポリシ設定ができるようにすることにある。
【課題を解決するための手段】
【００１１】
本発明は、提示した２つの課題を解決するために、以下の２つの方法を提案する。
すなわち、上記の課題１を解決する手段として、複数ストリームからの解析データ取得機能を提示する。これは複数の通信をひとつの視点から解析できるようになれば、パターン設定の困難さが軽減されるであろうという考え方に基づく機能実現である。例えば、著名なＩＤＳソフトのSnortでは、複数のシグネチャのうち少なくともひとつがマッチするパケットが観測された場合に検知したと判定する。しかし、例えば、複数あるシグネチャのうち一番目のものは、ＴＣＰ１３９番ポートに対して、特定の文字列が送信されたら検知せよというものであるが、着目しているワーム以外にもこの特定文字列を送信する通信は存在し、このシグネチャのみをもって当該ワームを検知したとすることは早計であるため、これらのシグネチャをもとに出力されたログを分析することが必要になっている。つまり、本来当該ワームのシグネチャとして記述したい内容を正確に記述できていないことになる。当該ワームの場合、ＴＣＰ１３９番ポートだけでなく、例えば、ＴＣＰ８０番を利用してワームソフトを送りつける動作をする。そこで、ＴＣＰ１３９とＴＣＰ８０番の両方を用いて特定文字列を送信する通信を検知するようにシグネチャ記述できれば、その結果検知した通信は当該ワームである確率が高くなる。そこで、本発明の不正アクセス検知システムは、図１に模式的に示したように複数ストリームからの解析データを取得できるようにすること、例えば、ＳＭＢを用いたシグネチャ１の通信と、httpを用いたシグネチャ２の通信が特定のソース（情報源）とディスティネーション（到達先）の間で観測された場合を当該ワームの検知であるとポリシ設定可能とするものである。
【００１２】
本発明の不正アクセス処理システム（ＣＡ）では、この機能を、
(１)  ＣＡソケットライブラリによるデータ収集機能とデータ作成機能を備えた通信処理機能部（ＣＡＰＳ）とデータ解析機能とアクション機能を備えた解析機能部（ＡＡ）との完全な分離構造化
(２)  ＣＡＰＳのＩＳＯ７層モデル（図１３参照）に従った完全なモジュール構造化
という２つの構造化により具体化している。
前者は、ＣＡ全体のモジュール化に関することである。複数の通信をひとつの視点から解析することを考えた場合、この複数の通信がＩＳＯ７層モデルのどの層のものであるのか、また、何種類の通信をまとめて解析するのかは、解析対象毎に異なる。従って、解析対象の層や数を限定しないために、解析機能側から通信処理機能に対して、必要な解析データの要求を出す構造が必要となる。これを実現するために、解析機能(ＡＡ)を通信処理機能(ＣＡＰＳ)とは完全に分離した構造を採用した。これにより、解析機能がどのようなデータを要求しても通信処理機能を実現するソフトウェアに変更を発生させることが無くなった。また、「ＩＤＳのような不正アクセス処理システムの基本ソフトウェアはプロトコルスタックであり、解析等を行う応用ソフトウェアとは区別すべきである」という思想のもと、基本ソフトウェア機能部(ＣＡＰＳ)と応用ソフトウェア機能部(ＡＡ)を明確に区別し、この２つの機能部をＣＡソケットライブラリで結合するというモデルを示しているものでもある。
【００１３】
後者は、ＣＡＰＳのモジュール化に関することである。ＣＡＰＳはＩＳＯ７層モデルに従った各層が独立した構造を持ち、かつ、各層のモジュール内には、それぞれフィルターモジュールと再構築モジュールが配置されており、各層それぞれがＡＡヘデータを渡すインターフェースを持っている。このＣＡＰＳの構造により、ＡＡは同時に複数の通信パスを監視できるようになっている。
【００１４】
本発明では、前記の課題２を解決するため手段としてストリームペア化機能を提示する。ＩＤＳにおけるパターンマッチの対象はパケット単位となることが多い。これに加え、ＩＰフラグメントの再結合処理や、ＴＣＰストリームの再構築処理後のデータを対象とすること（特許文献１参照）も可能になってきた。本発明のＣＡは、これに加え、図２に模式的に示すようにストリームのペア化機能を実現した。以下、パケットにおけるソース、ディスティネーションという概念と、ユニキャスト通信における２つの通信主体を明確に区別するために、２つの通信主体をクライアントとサーバと呼ぶことにするが、これは、ここでの議論に一般性を失わせるものではない。ユニキャスト通信は、クライアントとサーバの間でデータの交換が行われるが、このとき通信は、クライアントからサーバヘの通信(以下、クライアント通信と呼ぶ)と、サーバからクライアントヘの通信(以下、サーバ通信と呼ぶ)の、２つの通信が存在する。この時、非特許文献１，２に示される既存のＩＤＳでは、このクライアント通信とサーバ通信の関連性は保持されておらず、それぞれが関連性の無い通信として取り扱われている。しかし、課題２にある"攻撃とそれに対するレスポンスという文脈"をＡＡが理解するためには、ＣＡＰＳが２つの通信の関連性を確保しＡＡに伝達する必要がある。この文脈が理解できることにより、着目するワームの攻撃が成功したか失敗したかを含めての、侵入検知が可能となる。
【発明の効果】
【００１５】
本発明の通信状態遷移モニタ手法は、階層化された通信内容のシーケンス番号とアクノリッジ番号の両方を用いて、ストリームペアとして連続した通信となっていることを確認し、上位層へデータを転送するようにしているので、コマンドとレスポンスの様なストリームペアから解析データを取得する機能を備えており、確率の高い侵入検知が出来る。また、階層化された通信内容のシーケンス番号とアクノリッジ番号の両方を用いて、ストリームペアを一元的に再構築するだけでなく、各一方向通信のみの再構築が、適宜可能である。
本発明の通信状態遷移モニタシステムは、階層化された通信内容を解析する機能部ＡＡと解析結果対応する通信処理機能部ＣＡＰＳとを完全に分離されたシステムにおいて、パラメータ指定により解析対象に応じて必要となる解析データをＡＡからＣＡＰＳに対して要求するものであるから、解析対象の層や数を限定することなく再構築アルゴリズムを可変化した。
【００１６】
本発明の通信状態遷移モニタ手法は、パケット情報における各データ部の最初と最後の接続情報を書き込んだパケット構造体を、ヘッダ部を付けたまま各パケットに付加するようにしたので、再構築データ及びパケットヘッダの両方を同時に評価することができる。
本発明の通信状態遷移モニタシステムは、一つの解析データを対象に、パケット単位とセッション単位を同時に評価を行う機能を備えているので、巧妙な不正アクセスに対して多様な解析が可能であり、個々の端末に対してもその状態に応じた多様な対応が可能である。
総括すると、本発明のＣＡは、ＩＤＳにおける侵入検知精度を高めるという課題を解決するシステムであって、複数シグネチャの簡便な関連性設定と攻撃・レスポンスのペア化による文脈設定を記述できる環境を提供することにより、セキュリティツールの利用者層を広げ、上位層に対して深い解析能力を持つ者が直接不正アクセス処理に携ることができるようにし、その結果、下位層から上位層までポリシ全体を正確に記述することが可能となり、ＩＤＳログ出力量を、検知漏れを増加させることなく低減させることが出来る。
【発明を実施するための最良の形態】
【００１７】
本発明におけるＣＡの主要構成要素とその機能について説明する。まず、ＣＡの主要構成要素であり、前記課題解決を実現するＣＡＰＳを構成する２つの要素、すなわち、データ収集機能とデータ作成機能について述べる。
【００１８】
本発明のＣＡのデータ収集モジュールは、ネットワークインターフェースが１個の場合と２個の場合がある。２個の場合は、パケットのブリッジを行い、セッションのハイジャック機能を有効にすることができる。１個の場合はセッションの監視、切断等が行えるがこれは２個の場合でも可能である。図３にクライアント〜サーバ間の通信をＣＡで監視する場合の形態を示す。
【００１９】
次ぎに本発明のＣＡのデータ作成モジュールであるが、図４にＣＡの構成要素とその関係図を示す。複数ストリームからの解析データ取得機能は、データ作成モジュール(図中のデータ作成)にある。データ作成モジュールの中を完全な層構造にし、全ての層からデータ解析モジュールヘ直接データを渡せる構造としている。階層化されたプロトコルの各層は、フィルターモジュール(Layer-n Filter)と再構築モジュール(Layer-n Reassemble)で構成されている。このデータ作成部の構成は先の特許文献１にも示されているところであるが、本発明におけるＣＡＰＳは取り込むパケットの指示だけでなく、取り込んだパケットの再構築処理をどう行うかまで、ＡＡが必要とするデータの指定をＡＡから受ける機能が加えられており、このデータ指定に基づいて、各層のフィルターモジュール及び再構築モジュールの動作が決定され、ＡＡが必要とするデータ形式を作成することが可能となっている。
【００２０】
この再構築モジュールに、通常のＩＤＳには無いＣＡ特有の課題が存在する。それは以下に示すセッションペア化の問題である。ＣＡにおいて、ＴＣＰ等コネクション指向プロトコル処理における再構築処理は必須のものとなるが、これは通常のＴＣＰ処理アルゴリズムに通信端点という条件を設けないことにより実現可能である。図５にＣＡのプロトコルスタックの動作位置を示す。通常のソケットライブラリは、そのライブラリが動作しているノード(ノード２)と他のノード(ノード１)が通信することを前提に設計されているが、ＣＡのライブラリは、ライブラリが動作していないノード同士(ノード１とノード２)が通信することを前提に設計されており、自ホストが必ず通信に関与することを条件としていない。図５からも分かるように、ＣＡのプロトコルスタックはルータやスイッチ等のネットワーク機器のそれと同等な機能を果たすように設計した。これにより、任意の通信を取り扱うことができるプロトコルスタックとなった。
【００２１】
次に、ＣＡの再構築処理について考える。図６(a)のような時間順序でクライアントとサーバ間でパケットが交換されたとする。ここで、パケットＩＤの"Ｃ番号"はクライアント通信のパケット、"Ｓ番号"はサーバ通信のパケットを指す、通常のＴＣＰ再構築処理を実現することにより、パケット到着順に乱れが生じたり、再送要求等による重複パケットが発生したりしても、クライアント通信とサーバ通信はそれぞれ図６(b)のように正確に再現できる。この時、再構築にはシーケンス番号(seq)とデータ長(len)が使われる。ここで、ＣＡでの再構築処理について考える。ＣＡへのパケット到着順に関しても、クライアントやサーバと同様その順序が入れ替わることがあり得る。例えば、図６(c)に示すように、CO,C1,S1,SO,C2,S2の順でパケットが到着したとする。この時、通常のＴＣＰ再構築処理をした場合、ＣＡＰＳからＡＡへ送信されるパケットは、図６(d)に示す順番となる。上段がクライアント通信、下段がサーバ通信である。ここで(d)と(b)を比較すると、どちらもクライアント通信及びサーバ通信だけに注目すると正しい順序でパケットがＡＡへ渡される。しかし、(d)の場合、C1がＡＡに早く渡されすぎている。図６(a)にあるように、文脈からすると、C1はS1の後にＡＡに渡されなければならない。本発明のＣＡでは、この問題を遅延再構築アルゴリズムにより解決するようにしている。これは、要約すると、「シーケンス番号とアクノリッジ番号の両方を用いて、ストリームペアとして連続した通信となっているか確認しながら、上位層ヘデータを転送する。」というアルゴリズムである。
【００２２】
遅延再構築アルゴリズムでC1の上位層への転送が遅延する様子を図６，表１，及び表２を用いて説明する。
【表１】
2006211609.tif 000003
【表２】
2006211609.tif 000004
到着順である図６(c)のクライアント通信及びサーバ通信それぞれについて通常のＴＣＰ再構築処理によって並べ替えられたパケットのシーケンス番号及びアクノリッジ番号を整理すると表１及び表２になる。パケットＩＤ  CO，C1は、表１よりクライアント通信としてはシーケンス番号が連続していること、図６(c)より連続して到着していることより、連続して上位層へ送ることが可能であり、通常のＴＣＰ再構築はそのように動作する(図６(d)上段CO,C1の連続送出)。これを上位層から見た場合、COとC1が連続した文脈を持つかのように下位層からデータを渡されることになる。しかし、実際はCOに対してSO，Slという反対向きの通信が存在しているため、本発明のＣＡでは、C1を送出する前に、SO，S1を送出できるように遅延再構築アルゴリズムでデータの送出タイミングを決定している。C1を送出しようとする時、既に送出したCOのアクノリッジ番号2000とC1のアクノリッジ番号2020を比較する。ここで、両者が異なる場合、このギャップ分だけ、２つのパケットの間に反対向きの通信が発生していることになるので、その通信を上位層に送出するまで、C1の送出を遅延させる。ここで、反対向きの通信とは、表２のSO，S1になる。SO，S1の送出後は、サーバ通信のシーケンス番号が2020になっているため、C1送出のための条件であるクライアント通信のアクノリッジ番号とサーバ通信のシーケンス番号(表１，表２の下線部)が一致することになり、C1を送出できる(図６(e)上段C1)。SO，S1等サーバ通信のパケット送出時も、上記の例と全く同じ確認を行う。
これを遅延再構築と呼ぶのは、「上位層に渡そうとするパケットのアクノリッジ番号と反対向きの通信のシーケンス番号が同じになるまで待つ」ことにより、上位層へのデータ伝達が遅延することがあることに由来する。この遅延を認めることにより、パケットの到着順に乱れが生じても、クライアント通信とサーバ通信の正しい対応を保持したデータを上位層へ供給することが可能となる。この機能は転送されてきたパケット情報を情報源における時系列情報に揃えるだけでなく、要求に沿った時系列に揃えることに敷衍される。
【００２３】
今、本発明にはパケット再構築の際に、"到着済みパケット"と"新規到着パケット"の間にデータの重なり部分が存在した場合の処理方法の柔軟性が有ることを具体的に説明する。
パケット情報においてデータの重なりとは、以下の様な状況でセキュリティの脅威となる。例えば以下の条件（図７の(１)参照）の時を考える。
(a) パケットＡ(到着済みパケット)が先に、パケットＢ(新規到着パケット)が後に到着し
(b) 二つのパケット間で、データの重なり部分が存在し
(c) 更に、そのデータの重なり部分の片方(この例の場合は後着パケットの方)に不正データが埋め込まれていたとする。
通常は、データの重なり部分について、到着済みパケットか新規到着パケットかどちらか一方の重なり部分を採用しデータの再構築を行う。例えば到着済みパケットＡを採用する場合、図７の(２)のような再構築結果となり、新規到着パケットＢを採用する場合、図７の(３)のような再構築結果となる。データの重なり部分の内容が同一の場合、(２)と(３)の再構築結果は同一となるが、上述(c)の条件が存在すると、(２)と(３)の再構築結果は異なるものとなる。
【００２４】
ここで、データの重なり部分のどちらかに不正データが埋め込まれていたとすると、再構築の仕方によって不正行為が発症したり、しなかったりする。不正行為を行おうとするものは、この動作を利用する。つまり、不正行為検査時には(２)のように正常なデータとして再構築され、なおかつ、実際のノードに到着した時には(３)のように不正行為が発症するようにデータを複数のパケットに分割し重なり部分を持たせたものを攻撃対象に対して送信する。これが可能な理由は、データの重なり部分が存在する場合、不正行為検査時に到着済みパケットＡと新規到着パケットＢのどちらのデータを採用するかを攻撃対象ホストに対応して設定できないことが原因である。本発明のＣＡではこの再構築アルゴリズムを可変とすることにより、この攻撃を検知できるようにしている。
【００２５】
到着済みパケットＡと新規到着パケットＢのデータの重なり部分の重なり方も以下に例示するように種々有るところで、本発明はその形態毎に、その対応処理をとることができる。
例１:到着済みパケットの後ろ部分と新規到着バケットの前部分が重なっている場合。
例２:到着済みパケットの前部分と新規到着パケットの後ろ部分が重なっている場合。
例３:到着済みパケットの中に新規到着パケットが包含される場合のうち、新規到着パケットの最初及び最後が到着済みパケットと一致しない場合。
例４:到着済みパケットが新規到着パケットの中に包含される場合のうち、到着済みパケットの最初及び最後が新規到着パケットと一致しない場合。
例５:到着済みパケットが新規到着パケットの中に包含される場合のうち、到着済みパケットの最初だけが新規到着パケットと一致する場合。
例６:新規到着パケットが到着済みパケットの中に包含される場合のうち、新規到着パケットの最初だけが到着済みパケットと一致する場合。
例７:到着済みパケットが新規到着パケットの中に包含される場合のうち、到着済みパケットの最後だけが新規到着パケットと一致する場合。
例８:新規到着パケットが到着済みパケットの中に包含される場合のうち、新規到着パケットの最後だけが到着済みパケットと一致する場合。
例９:到着済みパケットと新規到着パケットが一致する場合。
これらの形態においても本発明では、いずれかのパケットに埋め込まれている不正データを検出することが可能となる。
【００２６】
ヘッダ部とデータ部とかならなるパケットデータは従来手法で再構築されると連続するデータ部情報が接続されてヘッダ部データは残らない。そこで次ぎに、パケットヘッダを失わない再構築処理方法に関する本発明技術について説明する。
従来手法の例として、パケットＡ，Ｂ，Ｃをこの順番で再構築する場合を図８の(１)に示している。図で示されるように、再構築後は、パケットＡ，Ｂ，Ｃに含まれていた情報のうち、データ部だけが存在し、再構築をすることによって、ヘッダ部の情報が削除されている。この状態では、再構築後のデータ部Ａ，Ｂ，Ｃに跨ったデータ解析は可能となるものの、ヘッダ部の解析をすることができなくなってしまう。
図８の(２)は本発明の技術について説明している。３つのデータ部を直接連結するのではなく、パケット構造体というものを３つのパケットに付加し、このパケット構造体の中で、例えば、「データ部Ａの最後はデータ部Ｂの最初に接続」し、また、「データ部Ｂの最後はデータ部Ｃの最初に接続」する、という再構築情報を表現するようにしている。これにより、図８を参照しつつ前述した手法で可能となった再構築後のデータ部Ａ，Ｂ，Ｃに跨ったデータ解析と共に、パケット単位のヘッダ部も含めた解析が同時に可能となる。
【実施例１】
【００２７】
図４には示していないが、本発明のＣＡにおいて、データ作成モジュールの中に、ca_muxと呼ぶモジュールを備えている実施例について説明する。muxとはマルチプレクサを指しており、関連するストリームペアをひとまとまりの解析対象として管理し、ＡＡとインターフェースを保つ機能を提供するものである。この実施例ではＡＡの取得する一つのファイル記述子に対応して一つのca_muxが割り当てられる。また、図９に示すように一つのＡＡが複数のca_muxを保持することが可能である。つまり、一つのＡＡが複数のストリームや、一つのストリーム内での複数プロトコル層の解析を行うことが可能となっている。通常のソケットライブラリは、特定のストリームのデータのみを送受信するが、本発明に係るＣＡのライブラリはストリームペアのデータを同時に送受信できる構造となっている。これは、通常のソケットライブラリインターフェースをグループ化して、メタソケットライブラリ的に動作しているが故に可能となっているものである。
以上、ＡＡが複数のca_mux を保持することが可能になっていることにより、課題１の複数のシグネチャをひとつの侵入検知ポリシとしてまとめてパターンマッチすることが可能となり、また、ca_muxによるストリームペアの管理により、課題２の攻撃とレスポンスのペア化を実現している。
【実施例２】
【００２８】
本発明のＣＡに装備されるＣＡＰＳプラットフォームの実装においては、オペレーティングシステムや、不正アクセス処理が実行される空間がカーネル空間なのかユーザ空間なのか(以下、このオペレーティングシステムと実行空間を合わせて環境と呼ぶ。)に依存したコードと、環境に依存しないコードを明確に分離したプログラム構造とした。実装は以下の５つの環境において実施した。
(1)  Windows(登録商標)カーネル空間
(2)  NetBSDカーネル空間
(3)  Linuxカーネル空間
(4)  Solarisカーネル空間
(5)  Linuxユーザ空間
参考までに、それぞれの実装における環境依存部と非依存部のコードの割合を表３に示す。行数は、プログラムのコメント部も含めてソースコードの行数をカウントしたものである。
【表３】
2006211609.tif 000005
【００２９】
ＣＡＰＳとＡＡの通信についてであるが、このＣＡＰＳとＡＡの通信は、ＣＡＰＳおよびＡＡがどの空間に実装されるかによって異なってくるので、ここではその通信インターフェースについて実施形態例を表４に示しておく。実際の通信プログラムは、環境依存コードにおいて、システムコールの実装またはソケット通信の実装を行うことになる。
【表４】
2006211609.tif 000006
【００３０】
前述した２つの課題について、本発明に係るＣＡの侵入検知ポリシの記述例に基づいて評価を行う。本発明のＣＡは、図１０に例示する侵入検知ポリシーで動作する。以下、図１０の記載内容を簡単に説明する。(01)〜(05)は、ホスト情報の定義であり、ＩＰアドレス(04)、ＩＰパケットデフラグメンテーションアルゴリズム(02)やＴＣＰ再構築アルゴリズム(03)の指定を行っている。(06)〜(09)は、アクション機能の定義であり、ログファイルヘの書き出し(07)とsyslogへの書き出し(08)をファイル名やパラメータと共に指定している。(10)〜(24)は、侵入検知ポリシの定義である。(11)と(18)はループ範囲の指定であり、ループ内の評価が真になると抜ける。ループ内は、デリミターまでの通信読み込み指示(12)、読み込んだデータがソースからディスティネーション（到達先）ヘのコマンド送信であったか(13)等をチェックしている。(14)と(17)で囲まれるループは、中にある評価式のどれかひとつでも真になれば抜けることを指示している。(15)と(16)は"Nimda"ワームのシグネチャーの一部であり、実際の記述では、この部分が全体の記述の大半を占める。(19)と(23)で囲まれる行は、(15)または(16)に対するレスポンスのチェック、(25)〜(32)はデータ解析機能の定義であり、(24)までで定義した内容などを用いて記述されている。
【００３１】
まず、課題１に対応する複数シグネチャの簡便な関連性設定であるが、(14)〜(17)の部分は、(14)の「attr＝"or"」で「(14)と(17)で囲まれたシグネチャのうちどれか１つでも発生したら検知せよ」というポリシを定義しており、複数のシグネチャをひとつのポリシとして定義しパターンマッチさせることが可能であることがわかる。シグネチャ記述の分業化という点については、シグネチャの設定部である(14)〜(17)には下位層の知識を必須とする設定内容は含まれていないことを考えると、達成できたと言える。下位層の知識が必要なシグネチャ記述は(02)〜(04)、(26)〜(28)にまとめられている。ここで重要なのは、下位層の知識を必要とするシグネチャ設定と上位層の知識を必要とするシグネチャ設定を分離して行えることである。下位層の知識が必要な設定はネットワーク専門家が、上位層の知識が必要な設定はアプリケーション熟練者が、それぞれ分担してひとつのポリシを作成することが可能である。これは、下位層から上位層までの全ての知識が無ければひとつのシグネチャの記述すら難しかった図１２のような既存のシグネチャと比較した場合、シグネチャの記述性向上に寄与していると考えられる。また、図１２では、監視対象ホストの情報を、複数あるシグネチャの先頭にそれぞれ記述せねばならず、ポリシ全体としては同じ記述を３回行わなくてはならないのに対し、図１０では、(04),(26),(27)で一度定義するだけで済んでいる。
【００３２】
次ぎに、課題２に関する攻撃とレスポンスのペア化による文脈設定であるが、(11)〜(18)が攻撃、(19)〜(23)がそれに対するレスポンスのパターンマッチをしている設定である。攻撃とレスポンスの時間的順序関係を設定の記述順で、サーバ通信とクライアント通信の区別を(13)と(21)で設定できていることがわかる。従来の方法であれば、侵入検知のシグネチャとして(15),(16)や(22)が個々に登録されていて、それぞれがログを出力し、更に、そのログを、タイムスタンプ等の付加的情報も利用しながらログ解析機能を用いて、時間的順序関係の推測や、多数の攻撃ログとレスポンスログの中からペアとなるログを探し出す等の処理が必要であったが、本発明の方法では、検知された時点でこれらの処理が完了しており、ログも攻撃とレスポンスという一連の事象についてまとめて１回出力されるのみとなる。このように、複数のシグネチャ間の関連性や、個別アプリケーションのコマンドとそのレスポンスの関係をシグネチャの中で記述できることにより、ＩＤＳから出力されるログの量を、検知漏れを増加させることなく低減することが可能となり、攻撃を受けてしまったホストの特定等、インシデント発生時の早急な対応に対してＩＤＳが効果を発揮できることになる。
また、侵入検知の質について、従来装置の図１２と本発明に係るＣＡの図１０を比較した場合、図１２はいくつかの特定のパターンがサーバに対して送信されたことを検知するに過ぎないのに対し、図１０は複数プロトコルに跨るパターンをワームソフトの送り込みの成否も含めて検知できるものである。これより、本手法はより高度な検知内容を記述可能であることがわかる。
【図面の簡単な説明】
【００３３】
【図１】複数通信の統合管理の概念を示す図である。
【図２】本発明におけるストリームペアを説明する図である。
【図３】データ収集機能の形態を概念的に示す図である。
【図４】本発明に係るＣＡの基本構成を示す図である。
【図５】本発明に係るＣＡのプロトコルスタックの動作位置を示す図である。
【図６】本発明における再構築処理を説明する図である。
【図７】パケット情報中に埋め込まれた不正データの処理を説明する図である。
【図８】本発明に係るＣＡの処理を説明する図である。
【図９】ストリームペアをひとまとまりの解析対象として管理する実施例を説明する図である。
【図１０】本発明に係るＣＡの侵入検知ポリシの記述例である。
【図１１】ＩＤＳの構成・機能とその関連を示す図である。
【図１２】Ｓnortによるワーム検出シグネチャの記述例である。
【図１３】階層化されたプロトコルの例を示す図である。
【図１】
2006211609.tif 000007
【図２】
2006211609.tif 000008
【図３】
2006211609.tif 000009
【図４】
2006211609.tif 000010
【図５】
2006211609.tif 000011
【図６】
2006211609.tif 000012
【図７】
2006211609.tif 000013
【図８】
2006211609.tif 000014
【図９】
2006211609.tif 000015
【図１０】
2006211609.tif 000016
【図１１】
2006211609.tif 000017
【図１２】
2006211609.tif 000018
【図１３】
2006211609.tif 000019