JP6254329B2 - アイドルプロセスの発見および制約 - Google Patents

Description

関連出願情報
本出願は、２０１４年５月１５日に出願された仮出願第６１／９９３，７６２号に対する優先権を主張し、その内容は参照によって本明細書に包含される。

企業システムはますます複雑化しており、セキュリティで保護することが極めて難しくなっている。すべてのセキュリティホールを除去することは（または、それらに関して知ることさえ）、不可能になりつつある。しかし、可能性のある攻撃を防ぐために、そのようなセキュリティホールをできるだけ多く封じることは重要である。

一般に、攻撃対象領域を除去または削減するための２つの極端なアプローチが存在する。第１のアプローチでは、厳格なセキュリティルールを使用して特定の攻撃対象領域を除去する。このアプローチの有利な点は、配置と実施とが容易なことである。ただし、ルールが厳しくなりすぎて、システムのユーザが不便を感じる可能性があるという欠点がある。例えば、一部のルールは、ユーザがソフトウェアをインストールするのを防ぐために、ユーザがそうする必要がある可能性がある正当なケースが存在する場合であっても、ホストを完全にロックすることがある。

第２のアプローチは、プログラムの通常動作を特定する機械学習に適用され、基準からの逸脱を検出する。このアプローチは、一般的であるという利点があり、プログラムを未知の攻撃から保護するために使用できる。このアプローチには、一般的に多くの誤警報が発生し、システムが使用不能になる可能性があるという欠点がある。

プロセス制約のための方法は、プロセスに関するシステムコール情報を収集することを含む。システムコール情報に基づいて、プロセスがアイドル状態にあるかどうかが検出され、その後、プロセスがシステムコールを定期的に発行するかどうかを判定するために、自己相関を使用して、プロセスが反復しているかどうかが検出される。プロセスがアイドル状態にあるか、または反復している場合、プロセスによって提示される攻撃対象領域を制限するために、そのプロセスが制約される。

プロセス制約のためのシステムは、プロセスに関するシステムコール情報をメモリに格納することと、プロセスがアイドル状態かどうかを判定することとのために構成されたシステムコールモニタを含む。プロセッサは、システムコール情報に基づいて、プロセスがアイドル状態にあるかどうかを検出することと、プロセスがシステムコールを定期的に発行するかどうかを判定するために、自己相関を使用して、プロセスが反復しているかどうかを検出することとのために構成される。制約モジュールは、プロセスがアイドル状態にあるか、または反復している場合、プロセスによって提示される攻撃対象領域を制限するために、そのプロセスを制約するように構成される。

本原理に従ってプロセス制約のための方法／システムを示しているブロック図／フロー図である。 本原理に従ってアイドルプロセスを検出するための方法／システムを示しているブロック図／フロー図である。 本原理に従って反復プロセスを検出するための方法／システムを示しているブロック図／フロー図である。 本原理に従ってプロセスを制約するための方法／システムを示しているブロック図／フロー図である。 本原理に従うプロセス制約のためのシステムのブロック図である。

本原理の実施形態は、システムコールイベント（ｓｙｓｔｅｍ ｃａｌｌ ｅｖｅｎｔｓ）を使用して、完全にアイドル状態にあるか、または有用な出力を生成せずに特定の入力を繰り返しチェックしている、長時間実行中のプロセスを識別する。それらのプロセスは、制約可能であり、もしかすると、完全に除去できる可能性がある。一般的に言って、長時間実行中のプロセスは、通常はループ内で実行されており、所与の瞬間に、次の３つの状態のうちのいずれかになっている。第１の状態では、プロセスは完全にアイドル状態にあり、入力チャネルに対してブロックされている。第２の状態では、プロセスは入力を繰り返しチェックするが、実際の入力が到着しないか、または出力が生成されないか、または出力が反復される。第３の状態では、有用な入力が受信されており、有用な出力が生成される。本実施形態は、最初の２つの状態を識別し、それらの状態を制約するか、または除去し、それによって攻撃対象領域を削減する。本明細書では、最初の２つの状態は、アイドリングプロセスとして定義される。

本実施形態は、監視のオーバーヘッドを少なくするために、システムコールイベントの最小限の監視を使用する。それらの実施形態は、プロセスが不必要である可能性があり、そのため直接停止できるかどうかに関して示唆することもできる。

ここで図１を参照すると、制約システムアーキテクチャに関する方法／システムのブロック図／フロー図が示されている。ブロック１０２は、システム上で実行されているプロセスに関するシステムコールを追跡し、その他のデータを実行する。ブロック１０４は、この情報を使用して、制約可能なプロセスを検出する。一般に、プロセスが長時間にわたって限定された動作のみを示している場合、そのプロセスは、完全な機能が発揮されていないため、制約できる可能性がある。実行時の監視によってプログラムの状態マシンを構築できるが、そのようなモデルでは、コールスタックおよびパラメータを含む、すべてのシステムコールに関する有意な情報を記録することが必要になる。そのようなアプローチのオーバーヘッドは、場合によっては極端に大きく、１００％〜２５０％にもなる。

本実施形態を、通常は監視のオーバーヘッドを少ししか許容できない実稼働環境において実用的かつ配置可能にするために、ブロック１０４は、監視するシステムコールのサブセットを選択し、リソースを大量に消費する可能性のあるコールスタックの監視を拒否する。制約可能なプロセスを検出することは、ブロック１０５でアイドルプロセスを検出することと、ブロック１０６で反復プロセスを検出することとを含む。アイドルプロセスは、特定の外部イベントまたは外部入力に対してブロックされているプロセスであり、反復プロセスは、ループしており、特定の条件が満たされるのを待機している（例えば、ファイルが作成されるのを待機している）プロセスである。制約可能なプロセスが識別されると、ブロック１０８はそれらのプロセスを制約し、露出された攻撃対象領域を削減する。

ここで図２を参照すると、アイドルプロセスを検出するための方法／システムのブロック図／フロー図が示されている。ブロック２０２は、システムコールの軽量な選択的監視を実行する。軽量な監視では、システムコールのサブセットのみを監視し、読み取りおよび書き込みなどの特定のシステムコールは、取得されなくてもよい。ブロック２０４は、プロセスによるＣＰＵ使用率を、プロセスがシステムコールを発行したかどうかを特定するための代替アプローチとして考慮する。ただし、ＣＰＵ使用率の粒度は粗く、プロセスが何らかのシステムコールを活発に発行している場合でも、ゼロの使用率を示す場合がある（ただし、そのような場合、システムコールの数は少ない傾向がある）。安全策として、ブロック２０２がゼロ個のシステムコールイベントを示し、ブロック２０４がゼロのＣＰＵ使用率を示した場合に、ブロック２０６はシステムコール全体の監視を実行する。

ここで図３を参照すると、反復プロセスを検出するための方法／システムのブロック図／フロー図が示されている。ブロック３０２は、システムコール全体の監視３０４を代替手段として使用して、システムコールの軽量な選択的監視を使用する。システムコールイベントは、システムコールの選択的セットのみに基づいて周期的であると判定されるが、システムコール全体のセットを考慮した場合には明らかに非周期的である可能性があるため、システムコール全体の監視が必要になる場合がある。例えば、さまざまなシステムコールを発行しているループ内の一部のプロセスは、ループの一部のインスタンスにおいて、システムコールｎａｎｏ＿ｓｌｅｅｐ（）が１回ではなく２回呼び出される場合があることを除き、正確に周期的に見えることがある。そのような省略されたシステムコールはほとんど問題にならないため、周期的であると判定されたプロセスは、実際には厳密に周期的でない場合でも、制約可能であってもよい。

ブロック３０６における周期性の検出は、相対的に含めることができる。高いレベルで、イベントログ（タイムスタンプを含む）が、自己相関ツールによって使用可能な形式に変換される。自己相関の考え方は、ある信号と、所与の遅延でのその信号との間の類似性の尺度を提供することである。正規化自己相関係数の「１」は完全な類似性を意味し、「−１」は位相が１８０度異なる完全な類似性を意味する。周期的な信号の場合、その自己相関は、１に等しい一連のピークを持つ。シフトされた信号が元の信号に完全に類似している場合、それらのピークは遅延を示す。元の信号が周期的であるかどうかを判定するために、ピークの高さ、および連続するピークの各ペア間の距離を測定できる。

自己相関の実行における問題は、システムコールデータを自己相関形式に変換する際に時間情報が失われないことを保証することにある。これに対処するために、１つのシステムコールイベントが数値（例えば、オープンの場合は１、クローズの場合は２など）に変換される。相関は、２つの数値が正確に一致する場合にのみ強くなる必要がある。例えば、１と２の比較と、１と１００の比較との間には違いがなく、どちらの場合も相関がない。ただし、一定のアイドル時間の間、システムコールが存在しない場合、この情報は失われる。この問題は、アイドル時間の期間を、特別な信号に変換することによって解決できる。例えば、−１がミリ秒などの何らかのアイドル時間単位を表し、−２がその量の２倍を表す。

ただし、収集されたタイムスタンプには、ある程度の自然なノイズが含まれている場合がある。例えば、２つのシステムコールが連続して発生した場合、それらのタイムスタンプは、ミリ秒の精度で測定されると、正確に同じになる可能性がある。また別のときに、それらのタイムスタンプは、オペレーティングシステムのスケジューリング方式（ｓｃｈｅｄｕｌｉｎｇ ｄｙｎａｍｉｃｓ）によると、１ミリ秒異なる場合がある。そのため、このアプローチに従って変換されたデータは、非常にノイズが多い可能性がある。

解決策として、すべての時間間隔がイベントのベクトルを含むように、イベントを同じサイズの時間間隔に挿入してもよい。これによって、完全に周期的なシステムコールのシーケンスにおいて、ある間隔内のイベント数が別の間隔内よりもわずかに多いという境界問題が発生する。これは、一部のシステムコールのタイムスタンプが、間隔の境界に極めて近い場合があり、偶然にそれらのタイムスタンプが２つの連続する間隔のどちらかに含まれる可能性があるからである。したがって、このアプローチも、ノイズを発生させる可能性がある。

しかし、各システムコールからタイムスタンプを取り去ることにより、システムコール間で残される情報は、順序のみになる。時間的要因は、フィルタリング後のステップとして時間チェックを行うことによって補償される。すべてのピークが（シフトされたシーケンスが元のシーケンスと一致する場合に関して）、元のシーケンスをＩ個のデータポイントだけシフトすることによって、真のピークであるかどうかについて検証される。対応する各システムコールのペアのタイムスタンプ間の平均差が比較される。このペアの１つは元のシーケンスから取得され、もう１つはシフトされたシーケンスから取得される。ピークが真のピークである場合、平均差はゼロに近くなるはずである。そうでない場合、平均差は非常に大きくなる。ブロック３０６は、平均差としきい値とを比較して、ピークが真のピークであるかどうかを判定する。

ブロック３０６は、長期間（例えば、１または２カ月）にわたって収集されたシステムコールイベントログに対して自己相関を適用することによって、周期性を検出する。自己相関の出力は、システムコールイベントが実際に周期的であるかどうかを正確に判定するため、および周期的である場合はそれらの周期を決定するために使用される。

ここで図４を参照すると、プロセスを制約するための方法／システムのブロック図／フロー図が示されている。ブロック４０２では、プロセスの基準動作／通常動作は、ブロック３０６によって決定された周期性に基づく期間Ｔにわたって学習される。この学習は、例えば１つまたは複数のプログラム状態マシン、システムコールの順序、およびコールスタックを伴うシステムコールを含む任意の適切なプロセスによって実行できる。ブロック４０４は、トレーニングの完了後にプロセスを制約する。ブロック４０４は、プログラムの通常動作からの逸脱を引き起こすシステムコールを簡単に識別することができる。その後、ブロック４０６は、そのような逸脱が発生した場合に、警報を生成する。この警報は、トレーニング中に現れなかった機能を発揮するために、何らかの形でプロセスが起動されたことを示すか、またはプロセスが攻撃を受けた結果として、予期しない処理を実行していることを示してもよい。

ブロック４０４は、トレースユーティリティを使用してプロセスの動作を制約してもよい。これによって、ブロック４０４は、対象となるプロセスを観察し、そのプロセスの実行状態を調べるためにプロセスの実行をいつでも停止すること、およびプロセスの実行を再開することができる。プロセスの動作が期待される動作から逸脱している場合、そのプロセスの実行が停止され、ユーザまたは管理者の裁量で対策が講じられる。そのような対策は、実行を再開すること、さらに調査を要求すること、またはプロセスを終了することを含んでもよい。

本明細書に記載された実施形態は、すべてハードウェアであっても、すべてソフトウェアであっても、またはハードウェアとソフトウェアの両方の要素を含んでもよいことを理解されたい。望ましい実施形態において、本発明は、ハードウェア、およびファームウェア、常駐ソフトウェア、マイクロコードなどを含むがこれらに限定されないソフトウェアにおいて実装される。

実施形態は、コンピュータまたは任意の命令実行システムによって、またはこれらに接続して使用するためのプログラムコードを提供するコンピュータ使用可能媒体またはコンピュータ可読媒体からアクセスできるコンピュータプログラム製品を含んでもよい。コンピュータ使用可能媒体またはコンピュータ可読媒体は、命令実行システム、命令実行装置、または命令実行デバイスによって、またはこれらに接続して使用するためのプログラムを格納、伝達、伝搬、または転送する任意の装置を含んでもよい。この媒体は、磁気システム、光システム、電子システム、電磁気システム、赤外線システム、または半導体システム（または装置またはデバイス）、あるいは伝搬媒体とすることができる。この媒体は、半導体メモリまたは固体メモリ、磁気テープ、取り外し式コンピュータディスケット、ランダムアクセスメモリ（ＲＡＭ：ｒａｎｄｏｍ ａｃｃｅｓｓ ｍｅｍｏｒｙ）、読み取り専用メモリ（ＲＯＭ：ｒｅａｄ−ｏｎｌｙ ｍｅｍｏｒｙ）、剛体磁気ディスク、および光ディスクなどのコンピュータ可読記憶媒体を含んでもよい。

プログラムコードの格納かつ／または実行を行うのに適したデータ処理システムは、システムバスを介して直接的または間接的にメモリ素子に結合された少なくとも１つのプロセッサを含んでもよい。これらのメモリ素子は、プログラムコードの実際の実行時に使用されるローカルメモリ、バルクストレージ、および、実行時にバルクストレージからコードが取得される回数を減らすために少なくとも一部のプログラムコードの一時記憶を提供するキャッシュメモリを含むことができる。入力／出力デバイスまたはＩ／Ｏデバイス（キーボード、ディスプレイ、ポインティングデバイスなどを含むが、これらに限定されない）は、直接的に、または介在するＩ／Ｏコントローラを通じて、システムに結合されてもよい。

ネットワークアダプタもシステムに結合され、介在するプライベートネットワークまたはパブリックネットワークを通じて、データ処理システムを、他のデータ処理システムまたはリモートプリンタまたはストレージデバイスに結合できるようにしてもよい。モデム、ケーブルモデム、およびイーサネットカードは、現在使用可能な種類のネットワークアダプタのうちの、ごく少数の種類にすぎない。

ここで図５を参照すると、制約システムアーキテクチャに関するシステム５００のブロック図が示されている。システム５００は、プロセッサ５０２およびメモリ５０４を含む。本実施形態を、例えば特定用途向け集積チップまたは機能部品用のフィールドプログラマブルゲートアレイを使用してハードウェアのみとして実装してもよく、または汎用ハードウェアプロセッサ上で実行されるソフトウェアとして実装してもよいということを強調する必要がある。図に示された機能部品は、個別に実装してもよく、あるいは共有された構造に結合されてもよい。システムコールモニタ５０６は、対象となるプロセスによって発行されたシステムコールを確認し、システムコール情報をメモリ５０４に格納する。モニタ５０６は、システムコールのすべてまたはサブセットのみを追跡してもよい。この情報は、プロセスがアイドル状態にあるかどうかを判定するために使用されてもよい。

周期性モジュール５０８は、プロセッサ５０２を使用して、記録されたシステムコールを分析し、非アイドルプロセスがその動作を周期的に繰り返しているかどうかを判定する。学習モジュール５１０は、アイドルプロセスおよび反復プロセスの通常動作に関する情報を特定する。その後、制約モジュール５１２は、学習モジュール５１０によって特定された情報を使用して、例えばプロセスの通常動作から逸脱しているシステムコールをブロックし、アラートを生成することによってプロセスを制約する。

以上の記述は、すべての点において、制限ではなく説明および例示であると理解されるべきであり、本明細書で開示された本発明の範囲は、発明を実施するための形態から決定されるのではなく、特許法によって許可された全範囲に従って解釈された特許請求の範囲から決定されるべきである。追加情報が、本出願の付録Ａで提供されている。本明細書に示され、記載された実施形態は、単に本発明の原理の説明であり、当業者が本発明の範囲と精神を逸脱することなくさまざまな変更を行うことができることを理解されたい。当業者は、本発明の範囲と精神を逸脱することなく、さまざまなその他の機能の組み合わせを実装できる。

Claims (7)

1. プロセスに関するシステムコール情報をメモリに格納することと、前記プロセスがアイドル状態にあるかどうかを判定することとのために構成されたシステムコールモニタと、
   前記システムコール情報に基づいて、前記プロセスがアイドル状態にあるかどうかを検出することと、前記プロセスがシステムコールを定期的に発行するかどうかを判定するために、自己相関を使用して、前記プロセスが反復しているかどうかを検出することとのために構成されたプロセッサと、
   前記プロセスがアイドル状態にあるか、または反復している場合に、前記プロセスによって提示される攻撃対象領域を制限するために、前記プロセスを制約するように構成された制約モジュールと
   を備えるプロセス制約のためのシステム。
2. 前記システムコールモニタが、コールスタックを含んでいないシステムコール情報の限定されたサブセットを収集するように構成された、請求項１に記載のシステム。
3. 前記プロセッサが、前記プロセスがアイドル状態にあるかどうかを検出するために、プロセッサの活動を監視するようにさらに構成された、請求項１に記載のシステム。
4. 前記プロセッサが、前記プロセスが反復しているかどうかを検出するために、前記システムコール情報からタイムスタンプ情報を削除するようにさらに構成された、請求項１に記載のシステム。
5. 前記プロセッサが、前記プロセスが反復しているかどうかを検出するために、相関するシーケンスに一致するように元のシーケンスをシフトし、対応するペアのタイムスタンプ間の平均差を比較することによって時間チェックを実行するようにさらに構成された、請求項４に記載のシステム。
6. 前記プロセッサが、前記プロセスが反復しているかどうかを検出するために、前記平均差としきい値を比較して、前記相関するシーケンスが真であるかどうかを判定するようにさらに構成された、請求項５に記載のシステム。
7. 前記制約モジュールが、前記プロセスの通常動作を学習し、前記通常動作から逸脱するシステムコールを識別するようにさらに構成された、請求項１に記載のシステム。

Images