共用方式為

規劃移轉到 Microsoft Sentinel

  • 發行項

安全性作業中心 (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 監視器記錄。
從 QRadar 移轉 • 移轉偵測規則
• 移轉 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 現成內容，而不是移轉所有元件。 您可以逐漸開始使用 Microsoft Sentinel，從數個使用案例的最簡可行產品 (MVP) 開始。 新增更多使用案例後，可以使用此 Microsoft Sentinel 執行個體做為使用者接受度測試 (UAT) 環境來驗證使用案例。
操作化 您可以移轉內容和 SOC 流程，確保現有的分析師體驗不會中斷。

識別您的移轉優先順序

使用這些問題來釘選您的移轉優先順序：

  • 您企業中最重要的基礎結構元件、系統、應用程式和資料為何？
  • 移轉中的專案關係人是誰？ SIEM 移轉可能觸及您企業的許多領域。
  • 什麼因素排定您的優先順序？ 例如，最大商務風險、合規性需求、商務優先順序等等。
  • 您的移轉規模和時間表為何？ 哪些因素會影響您的日期和期限。 您要移轉整個舊版系統嗎？
  • 您有所需的技能嗎？ 您的安全性人員是否已經過訓練，並準備好進行移轉？
  • 組織中是否有任何特定的封鎖程式？ 是否有任何會影響移轉規劃和排程的問題？ 例如，員工和訓練需求、授權日期、強制停止、特定商務需求等問題。

開始移轉之前，請先識別目前 SIEM 中的主要使用案例、偵測規則、資料和自動化。 以漸進式流程處理您的移轉。 先專特、仔細地了解您要移轉的內容、哪些項目可以取消優先順序，以及其實不需要移轉的項目。 您的小組在目前的 SIEM 中可能有極為大量的偵測和使用案例正在執行。 開始移轉之前，請決定哪些案例對您的企業有幫助。

識別使用案例

規劃探索階段時，請使用下列指引識別您的使用案例。

  • 依威脅、作業系統、產品等，識別並分析您目前的使用案例。
  • 範圍為何？ 您是否想移轉所有使用案例，或使用一些優先順序準則？
  • 識別移轉最重要的安全性資產。
  • 哪些使用案例具有效益？ 您不妨了解一下過去一年內哪些偵測已產生結果 (誤判為真和真實率)。
  • 影響使用案例移轉的商業優先順序為何？ 您企業的最大風險為何？ 哪種問題型別讓您的企業面臨最大的風險？
  • 依使用案例特性排定優先順序。
    • 請考慮設定較低的優先順序和較高的優先順序。 我們建議您著重在偵測上，在警示摘要上強制執行 90% 的確判為真。 造成高誤判為真率的使用案例，可能屬於您企業優先順序較低的部分。
    • 在業務優先順序和效率方面，選取能證明規則移轉的使用案例：
      • 檢閱過去 6 到 12 個月內未觸發任何警示的規則。
      • 消除您定期忽略的低階威脅或警示。
  • 準備驗證流程。 定義測試情節並組建測試指令碼。
  • 您可以套用方法來設定使用案例的優先順序嗎？ 您可以遵循 MoSCoW 之類的方法，優先處理一組更精簡的使用案例以進行移轉。

後續步驟

在本文中，您學到如何規劃和準備移轉。

使用活頁簿追蹤移轉