Microsoft Sentinel への移行を計画する

セキュリティ オペレーション センター (SOC) チームは、一元化されたセキュリティ情報イベント管理 (SIEM) とセキュリティ オーケストレーション、オートメーション、応答 (SOAR) ソリューションを使用して、ますます分散化するデジタル資産を保護します。 レガシ SIEM はオンプレミスの資産のカバレッジを適切に維持できますが、オンプレミスのアーキテクチャでは、Azure、Microsoft 365、AWS、Google Cloud Platform (GCP) などのクラウド資産のカバレッジが不十分な場合があります。 これに対し、Microsoft Sentinel では、オンプレミスとクラウドの両方の資産からデータを取り込み、資産全体のカバレッジを確保できます。

この記事では、レガシ SIEM から移行する理由と、移行のさまざまなフェーズを計画する方法について説明します。

移行の手順

このガイドでは、レガシ SIEM を Microsoft Sentinel に移行する方法について説明します。 この一連の記事を通じて移行プロセスに従います。この一連の記事では、プロセスのさまざまな手順を移動する方法について説明します。

Note

ガイド付き移行プロセスについては、Microsoft Sentinel の移行および最新化プログラムに参加してください。 このプログラムを使用することにより、すべての段階でベスト プラクティス ガイダンス、リソース、専門家のヘルプなど、移行を簡素化および高速化できます。 詳細については、アカウント チームにお問い合わせください。

手順	[アーティクル]
移行を計画する	現在はここです
ブックを使用して移行を追跡する	ブックを使用して Microsoft Sentinel の移行を追跡する
SIEM 移行エクスペリエンスを使用する	SIEM 移行 (プレビュー)
ArcSight から移行する	• 検出ルールを移行する • SOAR オートメーションを移行する • 履歴データのエクスポート
Splunk から移行する	• 検出ルールを移行する • SOAR オートメーションを移行する • 履歴データのエクスポート Splunk Observability のデプロイを移行する場合は、Splunk から Azure Monitor ログに移行する方法の詳細を確認してください。
QRadar から移行する	• 検出ルールを移行する • SOAR オートメーションを移行する • 履歴データのエクスポート
履歴データを取り込む	• エクスポートされた履歴データをホストするターゲット Azure プラットフォームを選択する • データ インジェスト ツールを選択する • ターゲット プラットフォームに履歴データを取り込む
ダッシュボードをブックに変換する	ダッシュボードを Azure Workbooks に変換する
SOC プロセスを更新する	SOC プロセスを更新する

Microsoft Sentinel とは

Microsoft Sentinel は、スケーラブルでクラウドネイティブのセキュリティ情報イベント管理 (SIEM) およびセキュリティ オーケストレーション自動応答 (SOAR) ソリューションです。 Microsoft Sentinel は、インテリジェントなセキュリティ分析と脅威インテリジェンスを企業全体に提供します。 Microsoft Sentinel は、攻撃の検出、脅威の可視化、予防的ハンティング、脅威への対応のための単一ソリューションを提供します。 Microsoft Sentinel の詳細情報。

レガシ SIEM から移行する理由

SOC チームは、従来の SIEM を管理する際に一連の課題に直面します。

• 脅威に対する応答が遅い。 レガシ SIEM では相関ルールが使用されています。これは、維持するのが難しく、新たな脅威を特定するには効果がありません。 さらに、SOC アナリストは大量の誤検知、多くの異なるセキュリティ コンポーネントからのアラート、ますます増加するログの量に直面しています。 このデータを分析すると、SOC チームが環境内の重大な脅威に対応するための取り組みが遅くなります。
• スケーリングの課題。 データ インジェスト率の増加に伴い、SOC チームは SIEM のスケーリングに挑戦しています。 SOC チームは、組織の保護に重点を置く代わりに、インフラストラクチャのセットアップとメンテナンスに投資する必要があり、ストレージまたはクエリの制限に制約されます。
• 手動分析と応答。 SOC チームには、大量のアラートを手動で処理するための高度なスキルを持つアナリストが必要です。 SOC チームは過剰な作業を行っており、新しいアナリストを見つけるのは困難です。
• 複雑で非効率的な管理。 SOC チームは通常、オーケストレーションとインフラストラクチャを監督し、SIEM とさまざまなデータ ソース間の接続を管理し、更新プログラムとパッチを実行します。 これらのタスクは、多くの場合、重要なトリアージと分析を犠牲にしています。

クラウドネイティブの SIEM は、これらの課題に対処します。 Microsoft Sentinel は、データを自動的かつ大規模に収集し、不明な脅威を検出し、人工知能を使用して脅威を調査し、組み込みの自動化でインシデントに迅速に対応します。

移行を計画する

計画フェーズでは、既存の SIEM コンポーネント、既存の SOC プロセスを特定し、新しいユース ケースを設計および計画します。 綿密な計画により、クラウドベースの資産 (Microsoft Azure、AWS、または GCP) と、Microsoft Office 365 などの SaaS ソリューションの両方の保護を維持できます。

この図は、一般的な移行に含まれる大まかなフェーズについて示しています。 各フェーズには、明確な目標、主要なアクティビティ、指定された結果と成果物が含まれます。

この図のフェーズは、一般的な移行手順を完了する方法のガイドラインです。 実際の移行には、一部のフェーズが含まれていない場合や、さらに多くのフェーズが含まれている場合があります。 このガイドの記事では、フェーズの完全なセットを確認するのではなく、Microsoft Sentinel の移行にとって特に重要な特定のタスクと手順を確認します。

考慮事項

各フェーズでこれらの重要な考慮事項を確認します。

フェーズ	考慮事項
発見	このフェーズの一部として、ユース ケースと移行の優先順位を特定します。
デザイン	Microsoft Sentinel 実装の詳細な設計とアーキテクチャを定義します。 実装フェーズを開始する前に、この情報を使用して直接の利害関係者から承認を得ます。
実装	設計フェーズに従って Microsoft Sentinel コンポーネントを実装するとき、およびインフラストラクチャ全体を変換する前に、すべてのコンポーネントを移行する代わりに Microsoft Sentinel のすぐに使えるコンテンツを使用できるかどうかを検討します。 Microsoft Sentinel の使用は、いくつかのユース ケースで実用最小限の製品 (MVP) から始めて徐々に開始できます。 ユース ケースをさらに追加すると、この Microsoft Sentinel インスタンスをユーザー受け入れテスト (UAT) 環境として使用して、ユース ケースを検証できます。
運用化	既存のアナリスト エクスペリエンスが中断されないように、コンテンツと SOC プロセスを移行します。

移行の優先順位を特定する

次の質問を使用して、移行の優先順位を特定します。

• ご自分のビジネスで最も重要なインフラストラクチャ コンポーネント、システム、アプリ、データは何ですか?
• 移行の利害関係者は誰ですか? SIEM の移行は、ビジネスの多くの領域に影響する可能性があります。
• 優先順位を高めるものは何ですか? たとえば、最大のビジネス リスク、コンプライアンス要件、ビジネスの優先順位などです。
• 移行の規模とタイムラインはどのようになっていますか? 日付と期限に影響を与える要因は何ですか。 レガシ システム全体を移行しますか?
• 必要なスキルはありますか? セキュリティ スタッフはトレーニングを受け、移行の準備ができていますか?
• 組織内に特定の阻害要因はありますか? 移行の計画とスケジュールに影響を与える問題はありますか? たとえば、スタッフの配置やトレーニングの要件、ライセンスの日付、終了期限、特定のビジネス ニーズなどの問題などです。

移行を開始する前に、現在の SIEM の主要なユース ケース、検出ルール、データ、自動化を特定します。 段階的なプロセスとして移行にアプローチします。 最初に移行するもの、優先順位を下げるもの、実際に移行する必要のないものについて、意図的かつ慎重に検討してください。 チームには、現在の SIEM で実行されている圧倒的な数の検出とユース ケースがある可能性があります。 移行を開始する前に、ビジネスに積極的に役立つものを決定します。

ユース ケースを特定する

検出フェーズを計画するときは、次のガイダンスを使用してユース ケースを特定します。

• 脅威、オペレーティング システム、製品などによって、現在のユース ケースを特定して分析します。
• スコープは何ですか? すべてのユース ケースを移行しますか、それとも優先順位付け基準を使用しますか?
• 移行に関して最も重要なセキュリティ資産を特定します。
• どのようなユース ケースが有効ですか? 良い出発点は、過去 1 年間に結果が生成された検出 (擬陽性と陽性率) を確認することです。
• ユース ケースの移行に影響するビジネス上の優先順位は何ですか? ご自分のビジネスにとって最大のリスクは何ですか? ご自分のビジネスを最も危険にさらす問題の種類は何ですか?
• ユース ケースの特性によって優先順位を付けます。
  • 優先順位を下げるまたは上げることを検討してください。 アラート フィードに 90% の真陽性を適用する検出に焦点を当てることをお勧めします。 高い擬陽性率を引き起こすユース ケースは、ビジネスの優先度が低くなる可能性があります。
  • ビジネスの優先順位と有効性の観点から、ルールの移行を正当化するユース ケースを選びます。
    • 過去 6 か月から 12 か月間にアラートをトリガーしていないルールを確認します。
    • 日常的に無視する低レベルの脅威やアラートを排除します。
• 検証プロセスを準備します。 テスト シナリオを定義し、テスト スクリプトを作成します。
• ユース ケースに優先順位を付ける方法を適用できますか? MoSCoW などの手法に従って、移行のためのより無駄のないユース ケースのセットに優先順位を付けることができます。

次のステップ

この記事では、移行の計画と準備を行う方法について説明しました。

ブックを使用して移行を追跡する