アラート:ESAのトラブルシューティング

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

このセクションでは、ESAを使用するときに発生する可能性がある一般的な問題について説明し、その問題に対する一般的な解決策を提案します。

ESAサービスのトラブルシューティング

                              
問題考えられる原因解決策

Security Analyticsダッシュボードで、ESAサービスが、オフラインであることを示す赤で表示されます。

アラート]>[構成]ページには、「サービスがオフラインであるか、アクセスできません」というメッセージが表示されます。

複数

ESAサービスがオフラインである場合、考えられる理由は多数あります。ただし、一般的なのは、作成したルールがメモリを使いすぎていて、ESAサービスで障害が発生するという問題です。この問題のトラブルシューティングについては、「メモリが原因でESAサービスがオフラインになった場合のトラブルシューティング手順」を参照してください。

他の一般的な原因として、ファイアウォールによってESAとSecurity Analyticsの間の接続がブロックされている、ESAサービス マシンがダウンしているなどがあります。  

  

ESAサービスを開始するには、次の手順を実行します。

Administration]>[サービス]で、ESAサービスのアクション アイコンActions_Icon.pngを選択し、[開始]を選択します。

ESAサービスの停止と再開が繰り返される場合は、カスタマー サポートに連絡してください。

最近のアップグレードの後、Security Analyticsダッシュボードで、ESAサービスがオフラインであることを示す赤で表示されます。

アラート]>[構成]ページには、「サービスがオフラインであるか、アクセスできません」というメッセージが表示されます。

構成の問題システムが最近アップグレードされている場合は、構成エラーが発生した可能性があります。[Administration]>[サービス]で、ESAサービスを選択し、[編集]をクリックします。[サービスの編集]フィールドで、[接続のテスト]をクリックします。 接続できない場合は、構成エラーが発生している可能性があります。構成エラーを修正した後、再度試してください。 
ESAの処理速度が遅いように見えます。構成の問題バッファ(デフォルト値は10,485,760バイト)を変更するか、TCPの設定をTCPNoDelayに変更し、TCP ACKの受信遅延を回避し、パフォーマンスを向上させることができます。これらの設定(readBufferSizeおよびTcpNoDelay)は、エクスプローラで/Workflow/Source/nextgenAggregationに移動して変更できます。

ESAデータベースに関するトラブルシューティング

                  
問題考えられる原因解決策

 My ESAダッシュボードがロードされません。 

  • データの取得中にエラーが発生します。
  • ロードにかなり時間がかかります。 
アラートが格納されているデータベースが大きくなりすぎています。

古いアラートが適時クリアされるように、アラート データベースの設定を構成しなければならない可能性があります。これらの設定の構成の詳細については、「Event Stream Analysis(ESA)構成ガイド」の「ESAストレージの構成」を参照してください。

データベースが大きくなりすぎた場合は、アラートをクリアする必要があります。クリアする場合は、カスタマー サポートにお問い合わせください。 

ESAのRSA Liveルールのトラブルシューティング

                    
問題考えられる原因解決策
RSA Liveから一連のルールをインポートした後、ESAサービスがクラッシュします。なぜですか?RSA Liveルールのパラメータを、実際の環境に合わせて構成していない可能性があります。 

RSA Liveの各ルールの説明には、構成が必要なパラメータや、実際の環境で満足すべき前提条件が記載されています。この説明を確認し、ルールが実際の環境に適しているかどうかを確認してください。

ルールを安全かつ確実に導入するには、新しいルールを評価版ルールとして構成し、実際の環境でテストします。評価版ルールは、新しいルールをテストするための保護対策です。  詳細については、次のトピックを参照してください: 評価版ルールとしてのルールの導入.

RSA Liveからルールのグループをインポートし、ルールはエラーなしで導入されましたが、後で無効になります。

すべてのRSA Liveルールが、どの環境にも適しているわけではありません。ESAに正しいメタを指定していないため、ルールを実行できない可能性があります。

[アラート]>[構成]>[サービス]に移動し、[導入されたルールの統計]で、無効になったルールを確認できます。 ルールが無効になっている場合、ルールの横に緑のアイコンは表示されません。 

 ルールが正しく導入されたのに、無効になっている場合は、ルールに関連する例外が発生していないかをログでチェックします。特に、メタがないためにルールが無効になっていないかを確認します。これを確認するには、[Administration]>[サービス]に移動し、ESAサービスを選択してから、ic-actns.png>[表示]>[ログ]を選択します。

次に、以下のようなメッセージを検索します。

"Property named ‘<meta_name>' is not valid in any stream"

たとえば、次のようなメッセージです。

Failed to validate filter expression '(medium=1 and streams=2 or medium=3...(238 chars)': Property named 'tcp_flags_seen' is not valid in any stream

同様のメッセージが見つかった場合は、Log DecoderまたはConcentratorにカスタム メタ キーを追加する必要がある場合があります。これを行うには、「DecoderおよびLog Decoder構成ガイド」の「カスタムFeedを使用したカスタム メタ キーの作成」の手順に従います。

導入のトラブルシューティング

               
問題考えられる原因解決策
ルールを作成し、構文も確認しました。ルールに問題はないように見えます。このルールを導入しようとすると、エラーが発生しました。なぜですか?正しいメタを指定していないため、ルールを導入できない可能性があります。 メタ キー参照を確認してください。正しいメタを指定していないため、ルールを導入できない可能性があります。 

ルールのトラブルシューティング

                    
問題考えられる原因解決策
カスタム ルールを作成しましたが(ルール ビルダーまたは詳細EPLを使用)、アラートが生成されません。なぜですか?接続に問題がある可能性があります。

アラート]>[構成]>[サービス]タブで、「検出レート」統計を確認します。

検出レートがゼロの場合、ESAサービスはConcentratorからデータを受信していません。Concentratorの接続を検証してください。[Administration]>[サービス]に移動し、ESAを選択して[表示]>[構成]をクリックします。  Concentratorが有効になっていることを確認します。Concentratorをダブルクリックし、[接続のテスト]をクリックします。

検出レートがゼロでない場合は、ルールで使用されているメタ キー名とタイプが、イベントに存在するメタ キーと一致していない可能性があります。ルールで使用されているメタ キーの名前とタイプが有効かどうかを確認してください。これを行うには、[アラート]>[構成]>[設定]タブでメタ キーの名前を検索します(メタ キー参照の検索)。

 ルールに問題がある可能性があります。

特定のルールが実行されない場合は、[アラート]>[構成]>[サービス]に移動して、ルールが無効になっていないかどうかを確認します。[導入されたルールの統計]セクションで、無効になっているルールには、(緑の有効ボタンではなく)白いボタンが表示されます。

[一致イベント数]フィールドも確認できます。[アラート]>[構成]>[サービス]に移動します。一致したイベントの数を[一致イベント数]列で確認できます。

一致したイベントがない場合は、ルールのロジックにエラーがないかどうかを確認します。たとえば、構文の大文字と小文字の区別に関するエラーや、タイム ウィンドウに関するエラーを確認します。それでもアラートが生成されない場合は、ルールのロジックを簡略化し、より簡単なルールでアラートが生成されるかどうかを確認します。 

メモリが原因でESAサービスがオフラインになった場合のトラブルシューティング手順

ステップ1:ホストが稼働中かどうかの検証

トラブルシューティングの最初のステップとして、ホストが稼働していることを確認します。これを行うには、[Administration]>[ホスト]に移動します。ホストがダウンしている場合、システム パラメータは表示されず(ただし、ホスト情報の更新が遅れている可能性があります)、[サービス]列は赤で表示されます。また、[更新]列にはエラー メッセージが表示されます。 

ESA_Host_Down.png

ホストがダウンしている場合は、SA管理者に連絡して再起動してください。それ以外の場合は、ステップ2に進みます。 

ステップ2:ヘルスモニタで詳細な統計情報を表示

ESAサービスがダウンしていることを確認したら、ヘルスモニタに移動して、潜在的な問題が発生している場所を確認します。最もよくあるのは、ESAサービスがメモリ閾値を超えたことにより停止する、または障害が発生するという問題です。

  1. ヘルスモニタ]>[アラーム]に移動して、ESAによってアラームがトリガーされていないかどうかを確認します。次のアラームを探してください。

    • ESA Overall Memory Utilization > 85%
    • ESA Overall Memory Utilization > 95%
    • ESA Service Stopped
  2. ヘルスモニタ]>[システム統計ブラウザ]に移動して、各ルールのパフォーマンスのメモリ メトリックを確認します。メトリックを表示するには、フィルタに次の情報を入力します。

                   
    ホスト コンポーネントカテゴリー
    <your host>Event Stream Analysisesa-metrics

    esa_metrics.png

    各ルールのメモリが[]列に表示されます。値はバイト単位で表示されます。[履歴チャート]列には、メモリ使用量の履歴が表示されます。 

    ESA_hist_graph.png

  3. ヘルスモニタ]>[システム統計ブラウザ]に移動して、ESAのパフォーマンスの詳細を確認します。ホストを選択し、次のフィルタを指定して、次の統計情報を表示します。

                                                                               
    ホスト コンポーネントカテゴリー統計情報
    <your host>HostSystemInfoCPU Utilization1.08%
    <your host>HostSystemInfoMemory Utilization45.43%
    <your host>HostSystemInfoUsed Memory7.08 GB
    <your host>HostSystemInfoTotal Memory15.58 GB
    <your host>HostSystemInfoUptime77758、1週間、2日...
    <your host>Event Stream AnalysisProcessInfoMemory Utilization7.07 GB
    <your host>Event Stream AnalysisProcessInfoCPU Utilization0.2%
    <your host>Event Stream AnalysisJVM.MemoryallCommitted Heap Memory Usage 8.0 GB
    <your host>Event Stream AnalysisESA-MetricsTotal ESA Memory Usage %4.64%

    System_Stats_Browser_1.png

メモリまたはCPUの利用率に問題がある場合は、ステップ3に進みます。 

ステップ3:ESAサービスの開始

  1. Administration]>[サービス]で、ESAサービスのアクション アイコンActions_Icon.pngを選択し、[開始]を選択します。 
  2. ESAサービスに戻って、どのルールによってメモリの問題が発生しているかのトラブルシューティングを行います。 

ESAサービスの停止と再開が繰り返される場合は、カスタマー サポートに連絡してください。

シャットダウンすることなくESAサービスを開始できた場合は、ステップ4に進みます。

ステップ4:アラートとイベントのボリュームの確認

ESAサービスがシャットダウンすることなく再開できたら、ルールの統計情報を調べて、どのルールがリソースを過剰に使用しているかを確認します。ルールによって生成されるアラートが多すぎる、またはルールと一致するイベントが多すぎることが原因で、ESAサービスに障害が発生する場合もあります。ESAサービスのシャットダウンの原因がメモリ使用量にあると判断した場合は、この両方の問題を調べます。 

アラート サマリーの表示

 アラートの量が多すぎるとシステムに負荷がかかり、システムがダウンしたり、再起動したりすることがあります。 アラート サマリーを表示するには、[アラート]>[サマリー]に移動します。画面の下部で、各ルールに対して生成されたアラート数を[件数]フィールドで確認できます。特定のルールについてアラート数が極端に多い場合は、そのルールを無効にし、より効率的なルールになるよう記述を変更する必要があります。

ESA_Alerts_High.png

一致イベント数の表示

ルールと一致するイベント数が多すぎるために、メモリを使い果たしてしまうことがあります。これは、通常、ルールのイベント ウィンドウが長く、アラートをトリガーしないイベントが大量に蓄積される場合に発生します。 これが問題になるのは、アラートがトリガーされるのをルールが待っている間、各イベントがメモリに格納されるからです。この問題が発生しているかどうかを確認するには、[Dashboard]>[アラート]>[サービス]に移動します。一致したイベントの数を[一致イベント数]列で確認します。特定のルールについて一致イベント数が極端に多い場合は、ルールをさらに詳しく調査して、そのルールを効率化できるかどうかを確認します。

ESA_High_Events.png

ステップ5:問題の原因になっているルールの無効化および修正

変更が必要なルールを特定したら、そのルールを無効にして、大量のアラートやイベントを生成しないよう記述を変更します。より効率的なルールを記述するポイントについては、次のトピックを参照してください: ベスト プラクティス.

ルールの無効化

  1. ルールを無効にするには、[アラート]>[サービス]に移動し、[導入されたルールの統計]セクションで、無効にするルールのチェックボックスを選択します。
  2. 無効化]を選択して、ルールを無効にします。 

ルールの編集

  1. ルールを修正するには、[アラート]>[ルール]>[ルール ライブラリ]に移動します。編集するルールを選択し、アクション アイコンをクリックします。
  2. 編集]を選択します。
  3. ルールを編集して効率的なルールに変更します。ルールの作成手順については、次のトピックを参照してください: ルール ライブラリへのルールの追加
  4. 納得できるルールになったら、それを評価版ルールとして保存し、メモリの問題が発生してもESAサービスのパフォーマンスに影響を及ぼさないようにします。これを行うには、次のトピックで説明する手順に従います: 評価版ルールの使用.

ルールの有効化

  1. ルールを有効にするには、[アラート]>[サービス]に移動し、[導入されたルールの統計]セクションで、有効にするルールのチェックボックスを選択します。
  2. 有効化]を選択して、ルールを有効にします。 

(オプション)ESAログ ファイルで詳細を確認

サービスがダウンしていること、およびシステム ダウンの潜在的な原因を検証したら、サービスの停止と再開が繰り返されるかどうかを確認します。 それには、ESAログに移動します。[Administration]>[サービス]で、ESAサービスを選択し、アクション アイコンをクリックして、[表示]>[ログ]を選択します。 

Security AnalyticsインタフェースからESAログにアクセスできない場合は、システムにSSH接続し、opt/rsa/esa/logs/esa.logを参照します。

You are here
Table of Contents > ESAクイック スタート ガイド > ESAのトラブルシューティング

Attachments

    Outcomes