Share via

Microsoft Sentinel を既存の SIEM にサイド バイ サイドで配置する

  • [アーティクル]

セキュリティ オペレーション センター (SOC) チームは、一元化されたセキュリティ情報およびイベント管理 (SIEM) とセキュリティ オーケストレーション、オートメーション、および応答 (SOAR) ソリューションを使用して、ますます分散化するデジタル資産を保護します。

この記事では、既存の SIEM と共に Microsoft Sentinel をサイド バイ サイド構成で配置する方法について説明します。

サイド バイ サイドのアプローチと方法を選択する

サイド バイ サイド アーキテクチャは、組織の SIEM ニーズに応じて、完全にクラウドでホストされる SIEM につながる短期的な移行フェーズとして、または中長期の運用モデルとして使用します。

たとえば、推奨されるアーキテクチャでは、Microsoft Sentinel への移行を完了するのに十分な時間だけサイド バイ サイド アーキテクチャを使用しますが、組織は、レガシ SIEM から移行する準備ができていない場合など、サイド バイ サイド構成を長期間使用する必要がある場合があります。 通常、長期的なサイド バイ サイド構成を使用する組織では、Microsoft Sentinel を使用してクラウド データのみを分析します。

使用するアプローチを決定する際には、各アプローチの長所と短所を考慮してください。

注意

多くの組織では、コストと複雑さのために、複数のオンプレミス分析ソリューションを実行しないようにしています。

Microsoft Sentinel では従量課金制の価格と柔軟なインフラストラクチャが提供され、SOC チームは変更に適応する時間を得ることができます。 組織に最適なペースでコンテンツを展開してテストし、Microsoft Sentinel に完全に移行する方法について説明します。

短期的なアプローチ

長所 短所
• SOC スタッフに、ワークロードと分析の展開時に新しいプロセスに適応する時間を提供します。

• ハンティング シナリオのために、すべてのデータ ソース間で深い相関関係が得られます。

• SIEM 間で分析を行い、転送ルールを作成し、2 か所で調査を終了する必要がなくなります。

• SOC チームがレガシ SIEM ソリューションをすばやくダウングレードし、インフラストラクチャとライセンスのコストを排除できます。		 • SOC スタッフには急な学習曲線が必要な場合があります。

中長期的なアプローチ

長所 短所
• レガシ SIEM から完全に移行せずに、AI、ML、調査機能など、Microsoft Sentinel の主要なベネフィットを使用できます。

• Microsoft Sentinel でクラウドまたは Microsoft のデータを分析することで、レガシ SIEM と比較してコストを削減できます。		 • 異なるデータベース間で分析を分離することで、複雑さが増します。

• 複数環境のインシデントについてケース管理と調査を分割します。

• スタッフとインフラストラクチャのコストが増加します。

• SOC スタッフは、2 つの異なる SIEM ソリューションに関する知識を要求されます。

レガシ SIEM から Microsoft Sentinel にアラート (異常なアクティビティのインジケーター) を送信します。

  • Microsoft Sentinel でクラウド データを取り込んで分析する
  • レガシ SIEM を使用して、オンプレミスのデータを分析し、アラートを生成します。
  • 単一のインターフェイスを確立するために、オンプレミスの SIEM から Microsoft Sentinel にアラートを転送します。

たとえば、Logstash、API、または Syslog を使用してアラートを転送し、それらを JSON 形式で Microsoft Sentinel の Log Analytics ワークスペースに格納します。

レガシ SIEM から Microsoft Sentinel にアラートを送信することで、チームはそれらのアラートを Microsoft Sentinel で相互に関連付け、調査できます。 チームは、必要に応じて引き続きレガシ SIEM にアクセスして、より詳細な調査を行うことができます。 その間、データ ソースの配置は、移行期間を延長して続行できます。

この推奨されるサイド バイ サイドの配置方法では、Microsoft Sentinel の完全な価値と、組織に合ったペースでデータ ソースを配置する機能が提供されます。 この方法では、データ ソースの移動中にデータ ストレージとインジェストのコストが重複しないようにします。

詳細については、次を参照してください。

Microsoft Sentinel に完全に移行する場合は、完全な移行ガイドを確認してください。

アラートとエンリッチされたインシデントを Microsoft Sentinel からレガシ SIEM に送信する

Microsoft Sentinel でクラウド データなどのデータを分析し、生成されたアラートをレガシ SIEM に送信します。 "レガシ" SIEM を単一のインターフェイスとして使用して、Microsoft Sentinel で生成されたアラートと相互に関連付けます。 Microsoft Sentinel で生成されたアラートの詳細な調査のために、Microsoft Sentinel を引き続き使用できます。

この構成はコスト効率が高く、コストを重複させたり、データの料金を 2 回支払ったりせずに、クラウド データ分析を Microsoft Sentinel に移行できます。 自分のペースで自由に移行できます。 引き続きデータ ソースと検出を Microsoft Sentinel に移行すると、プライマリ インターフェイスとして Microsoft Sentinel に移行しやすくなります。 ただし、エンリッチされたインシデントをレガシ SIEM に転送するだけでは、Microsoft Sentinel の調査、ハンティング、自動化の機能から得る価値が制限されます。

詳細については、次を参照してください。

その他の方法

次の表では、推奨 "されない" サイド バイ サイド構成と、その理由の詳細について説明します。

Method 説明
Microsoft Sentinel のログをレガシ SIEM に送信する この方法では、オンプレミスの SIEM のコストとスケールの課題が引き続き残ります。

Microsoft Sentinel でのデータ インジェストに対して、レガシ SIEM のストレージ コストと共に料金を支払います。また、Microsoft Sentinel の SIEM および SOAR 検出、分析、ユーザー エンティティ行動分析 (UEBA)、AI、または調査および自動化ツールを利用できません。
レガシ SIEM から Microsoft Sentinel にログを送信する この方法では Microsoft Sentinel のすべての機能が提供されますが、組織は 2 つの異なるデータ インジェスト ソースに対して引き続き料金を支払います。 このモデルでは、アーキテクチャの複雑さが増すだけでなく、コストが高くなる可能性があります。
Microsoft Sentinel とレガシ SIEM を完全に分離された 2 つのソリューションとして使用する Microsoft Sentinel を使用してクラウド データなどの一部のデータ ソースを分析し、他のソースに対してはオンプレミスの SIEM を引き続き使用することができます。 この設定では、各ソリューションを使用する場合の境界が明確になり、コストの重複が回避されます。

ただし、相関関係が難しくなり、両方のデータ ソースにまたがる攻撃を完全には診断できなくなります。 今日の状況では、脅威はしばしば組織全体を横方向に移動しているため、このような可視性のギャップによってセキュリティ上の大きなリスクが生じる可能性があります。

自動化を使用してプロセスを効率化する

自動ワークフローを使用し、アラートを一般的なインシデントにグループ化して優先順位を付け、その優先順位を変更します。

詳細については、次を参照してください。

次のステップ

Microsoft の Microsoft Sentinel リソースを調べてスキルを伸ばし、Microsoft Sentinel を最大限に活用します。

また、統合された脅威保護のために Microsoft Defender XDR と Microsoft Defender for Cloud と共に Microsoft Sentinel を使用して、脅威保護を強化することも検討してください。 Microsoft Sentinel によって提供される幅広い可視性を活用しながら、詳細な脅威分析を深く掘り下げてください。

詳細については、次を参照してください。