2020 年のパンデミックにより、仕事、教育、医療などへの取り組み方が変わり、クラウドやリモート アクセス ソリューションの普及が加速しています。今日の職場では、セキュリティ境界は自宅、空港、ジムなど、どこにいても拡張されています。遅れをとらないために、組織は一元化された可視性と自動化を提供するセキュリティ ソリューションを必要としています。分散型デジタル資産全体のニーズを満たすためにスケーリングできるもの。
クラウドネイティブのセキュリティ情報およびイベント管理 (SIEM) ソリューションであるMicrosoft Azure Sentinelは、そのニーズを満たすように設計されており、今日のビジネスに必要な範囲、柔軟性、およびリアルタイム分析を提供します。このブログ シリーズでは、オンプレミスの SIEM から Azure Sentinel への移行の計画と実行について説明します。まず、クラウド ネイティブの SIEM に移行する利点と、移行を開始する前に実行する準備手順について説明します。
クラウドネイティブ SIEM に移行する理由
今日の多くの組織は、サイロ化されたパッチワークのセキュリティ ソリューションで対処しています。 Azure Sentinel は、主要なパブリック クラウドでの業界初のクラウドネイティブ SIEM および SOAR (セキュリティ オペレーションと自動応答) ソリューションとして、機械学習を使用して誤検出を劇的に減らし、セキュリティ オペレーション (SecOps) チームを解放して実際の脅威に集中させます。
クラウドへの移行により、柔軟性が向上します。時間と費用がかかるインフラストラクチャの変更を必要とせずに、必要に応じてデータの取り込みをスケールアップまたはスケールダウンできます。 Azure Sentinel はクラウドネイティブの SIEM であるため、必要なリソースに対してのみ料金が発生します。実際、 Microsoft Azure Sentinel の Forrester Total Economic Impact™ (TEI) は、Azure Sentinel が従来のオンプレミス SIEM よりも48% 安価であることを発見しました。また、Azure Sentinel の AI と自動化機能は、SecOps チームに時間を節約する利点を提供し、忠実度の低いアラートを潜在的な忠実度の高いセキュリティ インシデントに組み合わせて、ノイズとアラート疲労を軽減します。 Forrester TEI の調査によると、Azure Sentinel をデプロイすると、3 年間で誤検知が 79% 減少し、 SecOps のワークロードが削減され、220 万ドルの効率が向上しました。
では、クラウドに移行する準備ができたら、どのように始めるべきでしょうか? Azure Sentinel への移行を計画する際には、いくつかの重要な考慮事項があります。
SIEM 移行の主要な段階を理解する
Azure Sentinel にデータを取り込むには、数回クリックするだけです。ただし、SIEM を大規模に移行するには、投資を最大限に活用するための慎重な計画が必要です。移行プロセスには、次の 3 つの基本的なアーキテクチャ ステージがあります。
- オンプレミスの SIEM アーキテクチャ:分析機能とデータベース機能の両方がオンプレミスに存在するクラシック モデル。このタイプの SIEM はスケーラビリティが制限されており、通常は AI を使用して設計されていません。したがって、SecOps チームがアラートで圧倒される可能性があります。オンプレミスの SIEM は、移行前の「前」の状態と見なすことができます。
- サイド バイ サイド アーキテクチャ:この構成では、オンプレミスの SIEM と Azure Sentinel が同時に動作します。通常、オンプレミスの SIEM はローカル リソースに使用され、Azure Sentinel のクラウドベースの分析はクラウド リソースまたは新しいワークロードに使用されます。ほとんどの場合、この状態は一時的な移行期間ですが、組織によっては、2 つの SIEM を長期間または無期限に並べて実行することを選択する場合があります。これについては、次のブログで詳しく説明します。
- クラウドネイティブ アーキテクチャ (完全な Azure Sentinel デプロイ):このモデルでは、セキュリティ分析とデータ ストレージの両方でネイティブ クラウド サービスを使用します。このブログ シリーズでは、これを最終状態、つまり完全な Azure Sentinel デプロイと見なしています。
注: サイド バイ サイド フェーズは、短期的な移行フェーズまたは中期から長期の運用モデルである可能性があり、完全にクラウドでホストされた SIEM アーキテクチャにつながります。短期的なサイド バイ サイドの移行的デプロイが推奨されるアプローチですが、Azure Sentinel のクラウド ネイティブな性質により、必要に応じて従来の SIEM と簡単にサイド バイ サイドで運用できるため、ある方法で移行にアプローチする柔軟性が得られます。組織に最適です。
ユースケースを特定して優先順位を付ける
移行を開始する前に、まず「P0 要件」とも呼ばれる主要なコア機能を特定する必要があります。現在の SIEM で展開されている主なユース ケースと、新しい SIEM で有効性を維持するために不可欠な検出と機能を確認してください。
ここで重要なのは、移行を 1/1 のリフト アンド シフトとしてアプローチしないことです。どのコンテンツを最初に移行するか、どのコンテンツの優先順位を下げ、どのコンテンツを移行する必要がないかについて、意図的かつ慎重に検討してください。あなたのチームは、現在の SIEM で圧倒的な数の検出とユース ケースを実行している可能性があります。この時間を使用して、ビジネスに積極的に役立つもの (および移行する必要がないもの) を決定します。良い出発点は、過去 1 年以内にどの検出が結果をもたらしたかを調べることです (偽陽性と陽性率)。推奨事項は、アラート フィードで 90% の真陽性を強制する検出に焦点を当てることです。
SIEM を比較対照する
移行の過程で、Azure Sentinel とオンプレミスの SIEM を並べて実行しているため、2 つの SIEM を引き続き比較および評価することを計画してください。これにより、移行を完了するための条件を絞り込むことができるだけでなく、Azure Sentinel を使用してより多くの価値を引き出せる場所を知ることができます (たとえば、長期的または無期限のサイド バイ サイド デプロイを計画している場合)。実際の攻撃に関する Microsoft の経験に基づいて、評価する主要な領域のリストを作成しました。
- 攻撃検出範囲: MITRE ATT&CK または同様のフレームワークを使用して、各 SIEM があらゆる範囲の攻撃をどれだけうまく検出できるかを比較します。
- 応答性: SIEM にアラートが表示されたときと、アナリストが最初にアラートに取り組み始めたときの平均応答時間 (MTTA) を測定します。これは、どの SIEM でも同様である可能性があります。
- 平均修復時間 (MTTR):各 SIEM (同等のスキル レベルのアナリスト) によって調査されたインシデントを比較します。
- ハンティングの速度と俊敏性:仮説からデータのクエリ、各 SIEM での結果の取得まで、チームがどれだけ速くハンティングできるかを測定します。
- 容量増加の摩擦:クラウドの使用が増えるにつれて、容量を追加する際の難易度を比較します。クラウド サービスとアプリケーションは、従来のオンプレミス ワークロードよりも多くのログ データを生成する傾向があります。
- セキュリティのオーケストレーション、自動化、修復:脅威を迅速に修復するために、まとまりと統合されたツールセットを測定します。
このシリーズの次の 2 回の記事では、従来の SIEM を Azure Sentinel と並行して実行する方法について詳しく説明し、データを移行するためのベスト プラクティスと、移行を完了する際の考慮事項について説明します。
移行プロセスの完全な概要については、ホワイト ペーパーをダウンロードしてください: Azure Sentinel Migration Fundamentals .
Microsoft セキュリティ ソリューションの詳細については、 当社の Web サイト を参照してください。 セキュリティ ブログをブックマークして、セキュリティに関する専門家の記事を入手してください。また、 @MSFTSecurityをフォローして、サイバーセキュリティに関する最新ニュースと更新情報を入手してください。
Comments