セキュリティ オペレーション センター (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 チームは、organizationの保護に重点を置く代わりに、インフラストラクチャのセットアップとメンテナンスに投資する必要があり、ストレージまたはクエリの制限に拘束されます。
- 手動による分析と応答。 SOC チームでは、大量のアラートを手動で処理するために高度なスキルを持つアナリストが必要です。 SOC チームは過剰な作業を行っており、新しいアナリストは見つけにくいです。
- 複雑で非効率的な管理。 SOC チームは通常、オーケストレーションとインフラストラクチャを監督し、SIEM とさまざまなデータ ソース間の接続を管理し、更新プログラムとパッチを実行します。 これらのタスクは、多くの場合、重要なトリアージと分析を犠牲にします。
クラウドネイティブ SIEM は、これらの課題に対処します。 Microsoft Sentinelは、データを自動的かつ大規模に収集し、未知の脅威を検出し、人工知能を使用して脅威を調査し、組み込みの自動化でインシデントに迅速に対応します。
移行の計画
計画フェーズでは、既存の SIEM コンポーネント、既存の SOC プロセスを特定し、新しいユース ケースを設計および計画します。 徹底的な計画により、クラウドベースの資産 (Microsoft Azure、AWS、GCP) と、Microsoft Office 365などの SaaS ソリューションの両方の保護を維持できます。
この図では、一般的な移行に含まれる大まかなフェーズについて説明します。 各フェーズには、明確な目標、主要なアクティビティ、指定された成果と成果物が含まれます。
この図のフェーズは、一般的な移行手順を完了する方法のガイドラインです。 実際の移行には、一部のフェーズが含まれていないか、より多くのフェーズが含まれる場合があります。 このガイドの記事では、フェーズの完全なセットを確認するのではなく、Microsoft Sentinel移行に特に重要な特定のタスクと手順を確認します。
考慮事項
各フェーズに関するこれらの重要な考慮事項を確認します。
| 段階 | 考慮事項 |
|---|---|
| 検索 | このフェーズの一環として、ユース ケースと移行の優先順位を特定します。 |
| Design | Microsoft Sentinel実装の詳細な設計とアーキテクチャを定義します。 この情報は、実装フェーズを開始する前に、関連する利害関係者から承認を得るために使用します。 |
| 実装 | 設計フェーズに従ってMicrosoft Sentinelコンポーネントを実装し、インフラストラクチャ全体を変換する前に、すべてのコンポーネントを移行する代わりに、Microsoft Sentinelすぐに使用できるかどうかを検討してください。 Microsoft Sentinelの使用は、いくつかのユース ケースで最低限実行可能な製品 (MVP) から開始して、徐々に開始できます。 ユース ケースをさらに追加すると、このMicrosoft Sentinel インスタンスをユーザー受け入れテスト (UAT) 環境として使用して、ユース ケースを検証できます。 |
| オペレーショナル化 | コンテンツと SOC プロセスを移行して、既存のアナリスト エクスペリエンスが中断されないようにします。 |
移行の優先順位を特定する
移行の優先順位をピン留めするには、次の質問を使用します。
- ビジネスで最も重要なインフラストラクチャ コンポーネント、システム、アプリ、データは何ですか?
- 移行の利害関係者は誰ですか? SIEM 移行は、ビジネスの多くの領域に触れる可能性があります。
- 優先順位を高めるものは何ですか? たとえば、最大のビジネス リスク、コンプライアンス要件、ビジネスの優先順位などです。
- 移行の規模とタイムライン 日付と期限に影響を与える要因は何ですか。 レガシ システム全体を移行していますか?
- 必要なスキルはありますか? セキュリティ スタッフはトレーニングを受け、移行の準備ができていますか?
- organizationに特定のブロックはありますか? 移行の計画とスケジュールに影響する問題はありますか? たとえば、スタッフやトレーニングの要件、ライセンスの日付、ハード ストップ、特定のビジネス ニーズなどの問題などです。
移行を開始する前に、現在の SIEM で主要なユース ケース、検出ルール、データ、自動化を特定します。 段階的なプロセスとして移行にアプローチします。 最初に移行するもの、枯渇するもの、実際に移行する必要がないことについて、意図的かつ慎重に考える。 チームは、現在の SIEM で実行されている検出とユース ケースの数が圧倒的に多い場合があります。 移行を開始する前に、ビジネスに積極的に役立つものを決定します。
ユース ケースを特定する
検出フェーズを計画するときは、次のガイダンスを使用してユース ケースを特定します。
- 脅威、オペレーティング システム、製品などによって、現在のユース ケースを特定して分析します。
- スコープは何ですか? すべてのユース ケースを移行するか、優先順位付けの基準を使用しますか?
- 移行に最も重要なセキュリティ資産を特定します。
- どのようなユース ケースが有効ですか? 良い出発点は、過去 1 年間に結果が生成された検出 (誤検知と陽性率) を確認することです。
- ユース ケースの移行に影響を与えるビジネス上の優先順位は何ですか? ビジネスにとって最大のリスクは何ですか? ビジネスを最も危険にさらす問題の種類は何ですか?
- ユース ケースの特性によって優先順位を付けます。
- 優先順位を低く、高く設定することを検討してください。 アラート フィードに 90% の真陽性を適用する検出に焦点を当てることをお勧めします。 誤検知率が高くなるユース ケースは、ビジネスの優先順位が低くなる可能性があります。
- ビジネスの優先順位と有効性の観点から、ルールの移行を正当化するユース ケースを選択します。
- 過去 6 か月から 12 か月間にアラートをトリガーしていないルールを確認します。
- 日常的に無視する低レベルの脅威やアラートを排除します。
- 検証プロセスを準備します。 テスト シナリオを定義し、テスト スクリプトを構築します。
- ユース ケースに優先順位を付ける方法を適用できますか? MoSCoW などの手法に従って、移行のためのより無駄のないユース ケースのセットに優先順位を付けることができます。
次の手順
この記事では、移行を計画して準備する方法について説明しました。