规划迁移到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 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 团队不能只专注于保护组织，而是必须投入到基础结构设置和维护中，并受到存储或查询限制的约束。
• 手动分析和响应。 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，从几个用例的最低可行产品（MVP）开始。 添加更多用例时，可以将此Microsoft Sentinel实例用作用户验收测试（UAT）环境来验证用例。
可操作化	迁移内容和 SOC 流程，以确保现有分析师体验不会中断。

确定迁移优先级

使用以下问题确定迁移优先级：

• 业务中最关键的基础结构组件、系统、应用和数据是什么？
• 谁是迁移中的利益干系人？ SIEM 迁移可能会涉及业务的许多领域。
• 是什么推动了优先级？ 例如，最大的业务风险、合规性要求、业务优先级等。
• 迁移规模和时间线是多少？ 影响日期和截止时间的因素。 是否迁移整个旧版系统？
• 是否具备所需技能？ 安全人员是否已接受训练并准备好进行迁移？
• 组织中是否有特定的阻止程序？ 是否有任何问题影响迁移计划？ 例如，人员配备和训练要求、许可证日期、硬停止、特定业务需求等问题。

在开始迁移之前，请确定当前 SIEM 中的关键用例、检测规则、数据和自动化。 将迁移视为一个渐进的过程。 对于首先迁移的内容、取消优先级的内容以及实际上不需要迁移的内容，要有意识地加以考虑。 你的团队可能在当前的 SIEM 中运行着大量检测和用例。 在开始迁移之前，请确定哪些内容对业务非常有用。

确定用例

计划发现阶段时，请使用以下指南确定用例。

• 按威胁、操作系统、产品等确定和分析当前的用例。
• 范围是多少？ 是要迁移所有用例，还是使用某些优先级条件？
• 确定哪些安全资产对迁移最重要。
• 哪些用例是有效的？ 一个良好的开端是查看哪些检测在过去一年中产生了结果（假正与真正率）。
• 影响用例迁移的业务优先级有哪些？ 业务面临的最大风险是什么？ 哪些类型的问题使业务面临最大风险？
• 按用例特征确定优先级。
  • 考虑设置更低和更高的优先级。 建议专注于对警报源强制实施 90% 真正率的检测。 导致高假正率的用例可能是对业务来说优先级较低的用例。
  • 选择根据业务优先级和有效性方面证明规则迁移合理的用例：
    • 查看过去 6 到 12 个月内未触发任何警报的规则。
    • 消除你在日常中会忽略的低级别威胁或警报。
• 准备验证过程。 定义测试方案并生成测试脚本。
• 是否可以应用某种方法来确定用例的优先级？ 可以按照 MoSCoW 等方法来优先考虑一组更精简的迁移用例。

后续步骤

本文介绍了如何计划和准备迁移。

使用工作簿跟踪迁移