規劃遷移至 Microsoft Sentinel

安全營運中心 (SOC) 團隊使用集中式的安全資訊與事件管理 (SIEM) ，以及安全協調、自動化與回應， (SOAR) 解決方案，以保護日益分散的數位資產。 雖然舊有的 SIEM 能維持良好的本地資產覆蓋，但本地架構可能無法充分覆蓋雲端資產，例如在 Azure、Microsoft 365、AWS 或 Google Cloud Platform (GCP) 。 相較之下，Microsoft Sentinel 能從本地及雲端資產中擷取資料，確保整個資產的覆蓋範圍。

本文將討論從舊有 SIEM 遷移的原因，並說明如何規劃遷移的不同階段。

了解 Microsoft Sentinel 遷移流程

在本指南中，您將學習如何將舊有的 SIEM 遷移到 Microsoft Sentinel。 透過這系列文章追蹤你的遷移過程，你將學會如何應對過程中的不同步驟。

注意事項

若欲獲得引導式遷移流程，請加入 Microsoft Sentinel 遷移與現代化計畫。 該計畫讓您能簡化並加速遷移過程，包括最佳實務指導、資源及每個階段的專家協助。 想了解更多，請聯繫你的帳戶團隊。

步驟 文章
規劃您的移轉 你來了
用工作簿追蹤遷移 用工作簿追蹤你的 Microsoft Sentinel 遷移
使用 SIEM 遷移體驗 SIEM 遷移
從 ArcSight 移轉 • 遷移偵測規則
• 移轉 SOAR 自動化
• 匯出歷史資料
從 Splunk 遷移 • 從SIEM遷移經驗開始
• 遷移偵測規則
• 移轉 SOAR 自動化
• 匯出歷史資料

如果你想遷移你的 Splunk Observability 部署，請進一步了解如何從 Splunk 遷移到 Azure 監視器 日誌。
從 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 元件時，並在轉換整個基礎架構之前，考慮是否能使用 Microsoft Sentinel 的現成內容，而非遷移所有元件。 你可以逐步開始使用Microsoft Sentinel，從最小可行產品 (MVP) 開始，適用於多種使用情境。 隨著你加入更多使用案例，你可以利用這個Microsoft Sentinel實例作為使用者驗收測試 (UAT) 環境來驗證使用案例。
投入運作 你遷移 內容與 SOC 流程 ，確保現有分析師的體驗不會被打亂。

明確你的遷移優先事項

請利用以下問題明確您的遷移優先事項：

  • 在您的企業中，哪些基礎設施元件、系統、應用程式和資料最為關鍵？
  • 你們在遷移過程中的利害關係人是誰？ SIEM 遷移很可能會觸及您業務的多個領域。
  • 是什麼驅動你的優先事項？ 例如，最大的商業風險、合規要求、業務優先事項等等。
  • 你們的遷移規模和時間表是什麼？ 哪些因素會影響你的日期和截止日期？ 你是在遷移整個舊系統嗎？
  • 你有需要的技能嗎？ 您的保全人員是否受過訓練並準備好進行遷移？
  • 你們組織裡有沒有特定的阻擋因素？ 有什麼問題會影響移民規劃和排程嗎？ 例如，像是人員配置與訓練需求、執照日期、硬性停靠、特定業務需求等問題。

在開始遷移前，先辨識目前 SIEM 中的關鍵使用案例、偵測規則、資料與自動化。 把遷移當作一個漸進的過程來看待。 要有意識且深思熟慮地決定先遷移什麼、降低優先順序，以及哪些其實不需要遷移。 你的團隊可能在目前的 SIEM 中運行著大量偵測和使用案例。 在開始遷移前，先決定哪些計畫對你的企業有實際幫助。

識別使用案例

在規劃發現階段時，請參考以下指引來辨識你的使用案例。

  • 依威脅、作業系統、產品等方式，識別並分析你目前的使用案例。
  • 範圍是什麼？ 你是想遷移所有使用案例，還是使用某些優先順序條件？
  • 找出哪些安全資產對遷移最為關鍵。
  • 哪些使用情境有效？ 一個不錯的起點是查看過去一年內哪些偵測曾產生結果（假陽性率與陽性率）。
  • 有哪些商業優先事項會影響使用案例遷移？ 對你的企業來說，最大的風險是什麼？ 哪些問題最會讓您的企業面臨風險？
  • 依使用情境特性優先排序。
    • 考慮將優先順序設低或提高。 建議您著重於能讓警示摘要達到 90% 確判為真的偵測。 導致高誤判率的使用案例，對你的企業來說可能優先度較低。
    • 選擇在業務優先權與效能方面合理化規則遷移的使用案例：
      • 檢視過去6到12個月內未觸發任何警示的規則。
      • 消除你經常忽略的低階威脅或警報。
  • 準備驗證流程。 定義測試情境並撰寫測試腳本。
  • 你能套用一套方法來優先排序使用案例嗎？ 你可以採用像 MoSCoW 這類方法，優先規劃更精簡的遷移用例。

下一步

在本文中，你學會了如何規劃和準備遷移。

用工作簿追蹤你的遷移進度

  • Last updated on