セキュリティ オペレーション センター (SOC) チームは、一元化されたセキュリティ情報イベント管理 (SIEM) とセキュリティ オーケストレーション、オートメーション、応答 (SOAR) ソリューションを使用して、ますます分散化するデジタル資産を保護します。 従来の SIEM ではオンプレミスの資産を適切にカバーできますが、オンプレミスのアーキテクチャでは、Azure、Microsoft 365、AWS、Google Cloud Platform (GCP) など、クラウド資産のカバレッジが不十分な場合があります。 これに対し、Microsoft Sentinelはオンプレミスとクラウドの両方の資産からデータを取り込むことができるため、資産全体を対象にすることができます。
この記事では、レガシ SIEM から移行する理由と、移行のさまざまなフェーズを計画する方法について説明します。
移行の手順
このガイドでは、レガシ SIEM をMicrosoft Sentinelに移行する方法について説明します。 この一連の記事を通じて移行プロセスに従います。この一連の記事では、プロセスのさまざまな手順を移動する方法について説明します。
メモ
ガイド付き移行プロセスについては、Microsoft Sentinel移行およびモダン化プログラムに参加してください。 このプログラムを使用することにより、すべての段階でベスト プラクティス ガイダンス、リソース、専門家のヘルプなど、移行を簡素化および高速化できます。 詳細については、アカウント チームにお問い合わせください。
| 手順 | 記事 |
|---|---|
| 移行を計画する | 現在はここです |
| ブックを使用して移行を追跡する | ワークブックを使用してMicrosoft Sentinelの移行を追跡します |
| SIEM 移行エクスペリエンスを使用する | SIEM の移行 |
| ArcSight から移行する | • 検出ルールを移行する • SOAR オートメーションを移行する • 履歴データのエクスポート |
| Splunk から移行する | • SIEM 移行エクスペリエンスで始める • 検出ルールを移行する • SOAR オートメーションを移行する • 履歴データのエクスポート Splunk Observability のデプロイを移行する場合は、Splunk から < Azure Monitor Logsに移行する方法の詳細を確認。 |
| QRadar から移行する | • SIEM 移行エクスペリエンスで始める • 検出ルールを移行する • SOAR オートメーションを移行する • 履歴データのエクスポート |
| 履歴データを取り込む | • エクスポートされた履歴データをホストするターゲット Azure プラットフォームを選択します • データ インジェスト ツールを選択する • ターゲット プラットフォームに履歴データを取り込む |
| ダッシュボードをブックに変換する | ダッシュボードをAzureワークブックに変換する |
| 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) と SaaS ソリューション (Microsoft Office 365 など) の両方の保護を維持できます。
この図は、一般的な移行に含まれる大まかなフェーズについて示しています。 各フェーズには、明確な目標、主要なアクティビティ、指定された結果と成果物が含まれます。
この図のフェーズは、一般的な移行手順を完了する方法のガイドラインです。 実際の移行には、一部のフェーズが含まれていない場合や、さらに多くのフェーズが含まれている場合があります。 フェーズの完全なセットを確認するのではなく、このガイドの記事Microsoft Sentinel移行に特に重要な特定のタスクと手順を確認します。
考慮事項
各フェーズでこれらの重要な考慮事項を確認します。
| フェーズ | 考慮事項 |
|---|---|
| 検出 | このフェーズの一部として、ユース ケースと移行の優先順位を特定します。 |
| 設計 | Microsoft Sentinel実装の詳細な設計とアーキテクチャを定義します。 実装フェーズを開始する前に、この情報を使用して直接の利害関係者から承認を得ます。 |
| 実装 | 設計フェーズに従ってMicrosoft Sentinelコンポーネントを実装し、インフラストラクチャ全体を変換する前に、すべてのコンポーネントを移行するのではなく、Microsoft Sentinelすぐに使用できるコンテンツを使用できるかどうかを検討します。 Microsoft Sentinelの使用は、いくつかのユース ケースで最小限の実行可能な製品 (MVP) から始めて徐々に開始できます。 ユース ケースをさらに追加すると、この Microsoft Sentinel インスタンスをユーザー受け入れテスト (UAT) 環境として使用してユース ケースを検証できます。 |
| 運用化 | 既存のアナリスト エクスペリエンスが中断されないように、コンテンツと SOC プロセスを移行します。 |
移行の優先順位を特定する
次の質問を使用して、移行の優先順位を特定します。
- ご自分のビジネスで最も重要なインフラストラクチャ コンポーネント、システム、アプリ、データは何ですか?
- 移行の利害関係者は誰ですか? SIEM の移行は、ビジネスの多くの領域に影響する可能性があります。
- 優先順位を高めるものは何ですか? たとえば、最大のビジネス リスク、コンプライアンス要件、ビジネスの優先順位などです。
- 移行の規模とタイムラインはどのようになっていますか? 日付と期限に影響を与える要因は何ですか。 レガシ システム全体を移行しますか?
- 必要なスキルはありますか? セキュリティ スタッフはトレーニングを受け、移行の準備ができていますか?
- 組織内に特定の阻害要因はありますか? 移行の計画とスケジュールに影響を与える問題はありますか? たとえば、スタッフの配置やトレーニングの要件、ライセンスの日付、終了期限、特定のビジネス ニーズなどの問題などです。
移行を開始する前に、現在の SIEM の主要なユース ケース、検出ルール、データ、自動化を特定します。 段階的なプロセスとして移行にアプローチします。 最初に移行するもの、優先順位を下げるもの、実際に移行する必要のないものについて、意図的かつ慎重に検討してください。 チームには、現在の SIEM で実行されている圧倒的な数の検出とユース ケースがある可能性があります。 移行を開始する前に、ビジネスに積極的に役立つものを決定します。
ユース ケースを特定する
検出フェーズを計画するときは、次のガイダンスを使用してユース ケースを特定します。
- 脅威、オペレーティング システム、製品などによって、現在のユース ケースを特定して分析します。
- スコープは何ですか? すべてのユース ケースを移行しますか、それとも優先順位付け基準を使用しますか?
- 移行に関して最も重要なセキュリティ資産を特定します。
- どのようなユース ケースが有効ですか? 良い出発点は、過去 1 年間に結果が生成された検出 (擬陽性と陽性率) を確認することです。
- ユース ケースの移行に影響するビジネス上の優先順位は何ですか? ご自分のビジネスにとって最大のリスクは何ですか? ご自分のビジネスを最も危険にさらす問題の種類は何ですか?
- ユース ケースの特性によって優先順位を付けます。
- 優先順位を下げるまたは上げることを検討してください。 アラート フィードに 90% の真陽性を適用する検出に焦点を当てることをお勧めします。 高い擬陽性率を引き起こすユース ケースは、ビジネスの優先度が低くなる可能性があります。
- ビジネスの優先順位と有効性の観点から、ルールの移行を正当化するユース ケースを選びます。
- 過去 6 か月から 12 か月間にアラートをトリガーしていないルールを確認します。
- 日常的に無視する低レベルの脅威やアラートを排除します。
- 検証プロセスを準備します。 テスト シナリオを定義し、テスト スクリプトを作成します。
- ユース ケースに優先順位を付ける方法を適用できますか? MoSCoW などの手法に従って、移行のためのより無駄のないユース ケースのセットに優先順位を付けることができます。
次の手順
この記事では、移行の計画と準備を行う方法について説明しました。