跳過主内容

從內部部署的 SIEM 移轉至 Azure Sentinel 的相關準備

2020 年的疫情不僅徹底改變我們在工作、教育和醫療保健等領域的交流互動方式，更加快雲端和遠端存取解決方案的採用速度。在今日的職場中，安全界限已延伸涵蓋家庭、機場、健身房，以及您的所到之處。為了跟上變化的腳步，組織需要使用安全性解決方案來提供集中的可見度和自動化，而這款解決方案還要具備擴充能力，以因應去集中化的數位資產需求。 

Microsoft Azure Sentinel 是一款雲端原生的安全性資訊和事件管理 (SIEM) 解決方案，旨在滿足上述需求，並提供現行企業不可或缺的範圍、彈性和即時分析。本部落格系列將探討如何規劃和實作從地端 SIEM 移轉至 Azure Sentinel 的作業，首先會介紹移轉至雲端原生 SIEM 的各項優勢，並說明著手移轉前的初步措施。 

為什麼要移轉至雲端原生的 SIEM？ 

即使現行的網路威脅手法越見細膩且層出不窮，許多組織仍屈就於各自獨立且拼湊而成的安全性解決方案。Azure Sentinel 為業界首個位於主流公有雲上的雲端原生 SIEM 和安全性作業和自動化回應 (SOAR) 解決方案，可運用機器學習技術大幅減少誤報，以協助您的安全性作業 (SecOps) 團隊專心對付實際威脅。 

移轉至雲端能帶來更大的彈性—可視需要擴充或縮減資料擷取量，且無需進行耗時且昂貴的基礎架構變更。由於 Azure Sentinel 為雲端原生的 SIEM，因此，您只需要為所需的資源付費。Forrester 的《Microsoft Azure Sentinel 的整體經濟影響 (Total Economic Impact™)》指出：Azure Sentinel 的成本比傳統地端 SIEM 便宜 48%。Azure Sentinel 的人工智慧和自動化功能也能將多個低逼真度警示整合為潛在的高逼真度安全性事件，以降低雜訊量並減輕警示疲勞，從而協助 SecOps 節省時間。Forrester TEI 研究也顯示：使用三年後，可望減少 79% 的誤報，藉此減輕 SecOps 的工作負荷，並帶來 $220 萬美元的效率提升。 

那麼，如果您已準備好移轉至雲端，應該從何開始著手？規劃移轉至 Azure Sentinel 的旅程時，需要評估幾項重要考量。 

了解 SIEM 移轉的各個主要階段 

只要輕點幾下，就能將資料擷取至 Azure Sentinel 中。然而，大規模移轉 SIEM 需歷經審慎規劃，才能充分發揮您的投資效益。移轉程序涵蓋三個基本架構階段： 

  • 內部部署 SIEM 架構：採用傳統模式，將分析和資料庫功能存放在內部部署環境中。這類型的 SIEM 僅具備有限的擴充能力，而且通常缺乏人工智慧相關設計。因此，您的 SecOps 團隊可能會飽受警示轟炸。您可以將內部部署 SIEM 視為「移轉前」狀態。 
  • 並行架構：在這個配置中，您的內部部署 SIEM 和 Azure Sentinel 會同時運作。通常，內部部署 SIEM 會做為本機資源使用，而 Azure Sentinel 的雲端架構分析功能則會運用在雲端資源或新的工作負載上。最常見的例子，就是將此狀態做為轉換期，不過，有時組織會選擇長期或無限期並行兩種 SIEM。我們將於後續的部落格中深入探討這個部分。 
  • 雲端原生架構 (完整的 Azure Sentinel 部署)：在這個模式中，安全性分析和資料儲存都會使用雲端原生服務。從本部落格系列的觀點來看，這可視為最終狀態，亦即完整的 Azure Sentinel 部署。 

注意：並行階段可做為邁向完整雲端代管 SIEM 架構前的短期轉換階段，或是中長期作業模式。雖然我們建議採用短期的並行轉換部署方法，鑑於 Azure Sentinel 具有雲端原生特性，因此，如有需要，也可與您的傳統 SIEM 輕鬆並行，繼而協助您透過符合組織需求的方式來彈性完成移轉作業。 

識別使用案例並排定其優先順序

在著手移轉前，建議您先行識別您的主要核心功能，也就是所謂的「P0 需求」。請了解使用現行 SIEM 部署的主要使用案例，以及使用新款 SIEM 確保效率所必備的偵測項目和功能。 

此處的關鍵，就是避免進行一對一的隨即轉移。請審慎評估哪些內容應優先移轉、哪些內容不具優先性，以及哪些內容可能完全不需移轉。您的團隊或許在現行的 SIEM 中執行為數眾多的偵測項目和使用案例。您可以把握這個機會，判斷哪些內容對自身業務發揮效用 (以及哪些內容可能不需要移轉)。著手了解哪些偵測項目曾在去年產生成果 (誤報率和正確率)，是不錯的切入點。建議您著重找出警示摘要正確率高於 90% 的偵測項目。 

比較和比對您的 SIEM

在移轉期間並行執行 Azure Sentinel 和內部部署 SIEM 時，請將兩個 SIEM 加以比較，並進行評估。此舉可協助您刪除移轉完成條件，並了解運用 Azure Sentinel 的哪些特點發揮更多價值 (例如，如果您正在規劃長期或無限期的並行部署)。Microsoft 依據現實環境的攻擊經驗，歸納出多個需要評估的重要領域： 

  • 攻擊偵測涵蓋範圍：使用 MITRE ATT&CK 或類似架構，比較每個 SIEM 如何偵測完整攻擊範圍。 
  • 回應能力：評估平均認可時間 (MTTA)，也就是從 SIEM 中出現警示到分析人員著手因應的所需時間。各種 SIEM 之間的回應能力可能十分相似。 
  • 平均修復時間 (MTTR)：比較每個 SIEM 所調查的事件 (使用具備同級技能的多名分析人員)。 
  • 追捕速度和靈活度：評估團隊的追捕速度，也就是在每個 SIEM 上從假設、查詢資料到取得結果的所需時間。 
  • 容量成長衝突：比較依照雲端使用量成長來新增容量的困難度。相較於傳統地端工作負載，雲端服務和應用程式通常可產生更多記錄資料。 
  • 安全性協調、自動化和修復作業：評估在快速修復威脅上的協調性和整合式工具組。 

本系列的後續兩篇部落格將深入探討如何並行執行舊版 SIEM 和 Azure Sentinel、提供移轉資料的最佳做法，並說明完成移轉作業前的各項考量。 

如需移轉旅程的完整概觀，請下載此《Azure Sentinel 移轉的基本概念》白皮書。 

如需進一步了解 Microsoft 安全性解決方案，請前往我們的網站。歡迎將安全性部落格加入書籤中，一手掌握 Microsoft 專家所提供的安全性建議。此外，也請透過 @MSFTSecurity 關注我們，以獲得網路安全的最新消息和更新資訊。 

欲了解詳情，請至微軟官方部落格

更多故事