アラート:ベスト プラクティス

Document created by RSA Information Design and Development on Feb 15, 2017
Version 1Show Document
  • View in full screen mode
  

ベスト プラクティスは、ルールの記述と管理、ルールの導入、ESAサービスのシステム稼働状態の維持のガイドラインとなります。

Event Stream Analysisルール タイプの理解

Security Analytics Event Stream Analysis(ESA)サービスは、相関イベントや複雑なイベント処理など、詳細なストリーム解析を高スループットかつ低レーテンシーで提供します。 ESAでは、Concentratorからの大量の雑多なイベント データを処理することができます。ただし、Event Stream Analysisを使用する場合は、効率的なルールを作成するために、リソース使用率に影響する要因を理解しておく必要があります。 

ESAは、受信するすべてのイベントを個別に評価し、それがアラートをトリガーするかどうかを判断します。ルールには3つのタイプがあり、タイプによってESAエンジンが受信イベントをどのように処理するかが決まります。3つのルール タイプは、それぞれにシステム リソースの使用率に異なるインパクトを与えます。3つすべてのルール タイプは、ルール ビルダーまたは詳細EPLを使用して作成するか、RSA Liveからダウンロードすることができます。次の表に、ルール タイプとこのルールがシステム リソースに与えるインパクトをまとめています。

                       
ルール タイプ説明

シンプル フィルタ ルール

このルールは、他のイベントとの相関はありません。イベント受信時に、このルールの条件が評価され、イベントが条件を満足していればアラートが生成されます。一致する条件がない場合、エンジンがイベントをただちにリリースして、メモリを解放します。これらのルールでは、イベントを初回評価した後イベントが保持されないためメモリを占有しません。導入するシンプル フィルタ ルールの数が増えても、メモリ使用率は増加しません。ただし、フィルタ条件があまりにも一般的なものであると、過剰にアラートが生成され、アラートの保存と検索のためにシステム リソースが消費されることになります。
たとえば、HTTPネットワークのアクティビティが標準のHTTPポート以外のポートに到着したときに、アラートを生成するルールを作成した場合が考えられます。

イベント ウィンドウ ルール このルールは、一定期間内に受信したイベントのセットに対して、特定の条件を評価します。イベント受信時に、ルールの条件が評価されます。これらの条件を満たした場合、イベントは一定時間メモリに保持されます。指定された時間が経過すると、収集したイベント数がアラートをトリガーする閾値を満たしていない場合、イベントはタイム ウィンドウから削除されます。このようなルールのメモリ消費量は、イベントの受信レート(トラフィック)、イベントあたりのデータ量、イベント ウィンドウで指定された時間の長さによって、大きく異なります。一致したそれぞれのイベントは、タイム ウィンドウが経過するまでメモリに保持されます。したがってタイム ウィンドウが長くなると、そのボリュームも大きくなります。  例えば、ユーザーがシステムのログインに10分間に5回失敗した場合に、アラートを生成するルールが考えられます。

Followed Byルール

このルールは、受信イベントのチェーンを評価し、イベントのシーケンスが特定の条件に一致するかどうかを判断します。イベント受信時に、ルールの条件が評価されます。条件を満たしている場合は、次のアクションのいずれかが実行されます。

  • シーケンスの最初のイベントである場合は、新しいイベント スレッドが開始され、シーケンスの先頭に保持されます。
  • イベントが既存のイベント スレッドに属する場合は、そのシーケンスに追加されます。

どちらのケースでも、イベントはメモリに保持されます。このタイプのルールを使用する場合、リソース使用量に大きく影響します。フィルタによって多数のイベント スレッドが生成される場合は、イベントに加えて新しいスレッドによってリソースが消費されます。さらに、イベント スレッドの最後の条件が一致しない(つまり、アラートが生成されない)場合、スレッド内のイベント全体がメモリに無期限に保存されます。  たとえば、ユーザーがサーバへのログインに失敗した後でログインに成功し、新しいアカウントを作成したときに、アラートを生成するルールを作成する場合が考えられます。

 

前述したメモリの使用量以外にも、アラートが生成されるとシステム リソースが消費されます。生成されたそれぞれのアラートは参照のためにディスクに格納され、インシデント管理によって処理される必要があります。この処理により、格納のためのディスク領域が使用され、データベース メモリが消費され、クエリーを実行するCPUの使用率が上昇します。 

ルールを作成し導入するときは、これらのアクションのそれぞれがシステム リソースに「負担をかける」ということを認識する必要があります。次のセクションは、使用率を健全なレベルに維持して、システムが過負荷状態になったときに生じる問題を監視するための参考になります。 

ルール作成のベスト プラクティス

ルールを作成するための一般的なガイドラインを以下に示します。

  • アクションが必要なイベントに対してアラートを作成します。アラートの目的は、ただちに特定のアクションが必要となるイベントをユーザーに通知することです。アクションが必要でないイベントの場合、またはイベントを認識するだけで問題がない場合は、レポートを作成できます。これにより、アラートを格納するデータベースが過負荷状態に陥ることを防ぐことができます。
  • 新しいルールを評価版ルールとして構成し、実際の環境でルールの動作を観察します。新しいルールを評価版ルールとして導入した場合は、構成されたメモリ閾値を超えるとルールが無効化されます。メモリ スナップショット機能を使用して、評価版ルールが無効化されたときに使用されていたメモリ量を表示することもできます。詳細については、次のトピックを参照してください: 評価版ルールの使用.
  • ルールのテストとチューニングが完了した後で初めて、アラート通知を構成します。これにより、ルールが予想外の動作をした場合に大量のアラートが生成されることを防ぎます。 
  • リソースの使用量を制限するために、ルールは具体的なものにします。使用量を制限するには、次のガイドラインに従います。
    • ルールのフィルタで、ルールを正確に起動させるのに必要なイベント以外のものを除外します。
    • ウィンドウ(相関のタイム ウィンドウ)のサイズをできるだけ小さくします。
    • ウィンドウに含めるイベントを制限します。たとえば、IDSイベントだけを確認する場合は、タイム ウィンドウにIDSイベントだけが含まれるようにします。 
  • 管理可能なレベルのアラートを生成するようルールを調整します。大量のアラートが発生するようでは、アラートの目的と実用性は失われます。さらに、アラートを格納するデータベースが大量のアラートでいっぱいになった場合は、システムによるアラートの処理が遅延したり、処理できなくなったりします。たとえば、他の国へ向けた暗号化されたトラフィックについて知りたいとします。ここで、リストを既知のリスクがある国に限定することができます。これにより、アラートのボリュームが管理可能なレベルに制限されます。

RSA Liveルールを使用するベスト プラクティス

RSA Liveルールのガイドラインを以下に示します。

  • RSA Liveルールを小さなバッチに分けて導入します。すべてのルールがあらゆる環境に適しているわけではありません。RSA Liveルールを正常に導入するための最善の方法は、ルールを小さなバッチで導入し、実際の環境でテストすることです。小さなバッチで導入すれば、問題のあるルールを特定するのがはるかに容易になります。 
  • RSA Liveルールの説明を読みます。ESAルールは「それ1つでどんな場合にも適応できる」ものではありません。ご使用の環境ですべてのルールが機能するわけではありません。ルールの説明には、実際の環境にルールを正常に導入するためにはどのパラメータを変更する必要があるかが記載されています。
  • パラメータを設定します。 RSA Liveルールには、変更が必要なパラメータがあります。パラメータを変更しない場合は、ルールが機能しない、またはメモリを使い切ってしまう可能性があります。
  • 新しいルールを評価版ルールとして導入し、実際の環境でルールの動作を観察します。新しいルールを評価版ルールとして導入した場合は、構成されたメモリ閾値を超えるとルールが無効化されます。詳細については、次のトピックを参照してください: 評価版ルールの使用.

ルールを導入するためのベスト プラクティス

ルールを導入するための一般的なガイドラインを以下に示します。

  • ルールを小さなバッチに分けて導入し、実際の環境でルールの動作を観察します。すべての環境が同じではありません。メモリ使用量、アラートのボリューム、イベントの検出効率を元に、ルールを調整する必要があります。
  • アラート通知を構成する前にルールをテストします。ルールのテストとチューニングが完了した後で初めて、アラート通知を構成します。これにより、ルールが予想外の動作をした場合に大量のアラートが生成されることを防ぎます。
  • 導入プロセスの一部として、システムの稼働状態を監視します。ルールを導入するときは、導入プロセスの一部として、システムの稼働状態を監視します。[ヘルスモニタ]タブで、ESAでのメモリの合計使用率を表示できます。詳細については、次のトピックの「ヘルスモニタの統計の表示」を参照してください: ESAのトラブルシューティング.

システム稼働状態のベスト プラクティス

システムの稼働状態の一般的なガイドラインを以下に示します。

  • アラート データベースを構成して、アラートの正常稼働レベルを維持します。ESAはMongoDBを使用してアラートを格納します。MongoDBが大量のアラートであふれた場合は、データベースの動作が遅くなったり、停止したりします。データベースでアラートの正常稼働状態を維持するには、設定を構成してアラートを定期的にクリアするようにします。手順については、「Event Stream Analysis(ESA)構成ガイド」の「ESAストレージの構成」を参照してください。
  • 新しいルールを評価版ルールとしてセットアップします。新しいルールには、メモリの問題を引き起こす可能性があるという共通した問題があります。新しいルールを評価版ルールとしてセットアップすることで、これを防ぐことができます。構成されたメモリ閾値に達した場合、すべての評価版ルールが無効化され、システムがメモリを完全に消費するのを防ぎます。 詳細については、次のトピックを参照してください: 評価版ルールの使用.
  • ヘルスモニタ モジュールで閾値を設定し、メモリ使用量が多すぎる場合にアラートを生成します。ヘルスモニタ モジュールには、メモリ使用量を追跡するメトリックがあります。アラートと通知をセットアップして、これらの閾値を超えた場合にメールを送信するようにします。 表示できるメモリ統計の詳細については、次のトピックの「ヘルスモニタの統計の表示」を参照してください:ESAのトラブルシューティング
  • ヘルスモニタ モジュールでルールごとにメモリ メトリックを監視します。ヘルスモニタ モジュールでルールごとに推定メモリ使用量を表示できるようになりました。この情報を使用してルールで大量のメモリが使用されないようにすることができます。表示できるメモリ統計の詳細については、次のトピックの「ヘルスモニタの統計の表示」を参照してください:ESAのトラブルシューティング
You are here
Table of Contents > ESAクイック スタート ガイド > ベスト プラクティス

Attachments

    Outcomes