你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站,请访问 https://docs.azure.cn。
计划到 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 可观测性部署,请详细了解如何从 Splunk 迁移到 Azure Monitor 日志。 |
从 QRadar 迁移 | • 迁移检测规则 • 迁移 SOAR 自动化 • 导出历史数据 |
引入历史数据 | • 选择目标 Azure 平台来托管导出的历史数据 • 选择数据引入工具 • 将历史数据引入目标平台 |
将仪表板转换为工作簿 | 将仪表板转换为 Azure 工作簿 |
更新 SOC 流程 | 更新 SOC 流程 |
Microsoft Sentinel 是可缩放的云原生安全信息与事件管理 (SIEM) 和安全业务流程自动响应 (SOAR) 解决方案。 Microsoft Sentinel 跨企业提供智能安全分析和威胁情报。 Microsoft Sentinel 为攻击检测、威胁可见性、主动搜寻和威胁响应提供了单一解决方案。 详细了解 Microsoft Sentinel。
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 等方法来优先考虑一组更精简的迁移用例。
本文介绍了如何计划和准备迁移。