适用于：
- Microsoft Defender XDR
在安全运营中心 (SOC) 中部署Microsoft Defender XDR的建议方法取决于 SOC 团队的当前工具、流程和技能集。 跨平台保持网络卫生可能具有挑战性，因为来自数十个（如果不是数百个）安全源的大量数据。
安全工具是相互关联的。 在安全技术中打开一项功能或更改进程可能会反过来破坏另一项功能。 因此，Microsoft建议 SOC 团队正式确定用于定义用例和优先顺序的方法。 用例有助于定义不同团队中 SOC作的要求和测试流程。 它创建一种捕获指标的方法，以确定正确的角色和任务组合是否与具有适当技能集的合适团队保持一致。
开发和规范用例流程
SOC 应定义开发用例的高级标准和流程，这将由 SOC 监督团队监管。 SOC 监督团队应与业务、IT、法律、人力资源和其他组合作，确定最终进入 SOC 团队 Runbook 和 playbook 的 SOC 用例的优先级。 用例的优先级取决于目标，例如合规性或隐私。
与用例开发相关的 SOC 监督活动包括：
- 要求
- 人员配备或培训需求
- 软件许可证
- 供应商合同
- 管理计划
- 维护用例注册表
- 维护/更新模板
若要促进 Runbook 和 playbook 创建过程，请创建用例决策树。 此图显示了一个示例。
定义并批准高级用例标准后，下一步是创建并测试实际用例。 以下部分使用反钓鱼以及威胁和漏洞扫描方案作为示例。
用例示例 1：新的钓鱼变体
创建用例的第一步是使用故事板概述工作流。 下面是向威胁情报团队发出新的网络钓鱼攻击通知的高级故事板示例。
调用用例工作流，例如 1
故事板获得批准后，下一步是调用用例工作流。 下面是反网络钓鱼活动的示例过程。
用例示例 2：威胁和漏洞扫描
另一种用例可用于威胁和漏洞扫描。 在此示例中，SOC 要求通过包括扫描资产的已批准流程针对资产修正威胁和漏洞。
下面是资产Microsoft Defender 漏洞管理的高级情节提要示例。
调用用例工作流，例如 2
下面是威胁和漏洞扫描的示例过程。
分析用例输出和经验教训
在批准并测试用例后，应确定安全团队之间的差距，以及所涉及的人员、流程和Microsoft Defender XDR技术。 应分析Microsoft Defender XDR技术，以确定它们是否能够实现所需结果。 这些可以通过清单或矩阵进行跟踪。
例如，在反钓鱼方案示例中，SOC 团队可能已在此表中进行了发现。
| SOC 团队 | 要求 | 满足要求的人员 | 满足要求的过程 | 相关技术 | 已识别差距 | 用例更改日志 | 豁免 (Y/N) |
|---|---|---|---|---|---|---|---|
| 威胁情报和分析团队 | 数据源正在正确馈送到威胁情报引擎。 | 威胁情报分析师/工程师 | 已建立数据馈送要求，来自已批准来源的威胁情报触发器 | Microsoft Defender for Identity、Microsoft Defender for Endpoint | 威胁情报团队未使用自动化脚本将Microsoft Defender XDR API 与威胁 intel 引擎链接 | 将Microsoft Defender XDR添加为威胁引擎的数据源 更新用例运行手册 |
网络 |
| 监视团队 | 数据源正在正确馈送到监视仪表板 | 第 1、2 层 SOC 分析师 - 监视 & 警报 | 用于报告安全 & 合规中心安全功能分数的工作流 |
调查Microsoft Defender XDR中的警报 安全功能分数监视 |
SOC 分析师没有机制来报告成功的新网络钓鱼变体检测以提高安全功能分数 | 向报告工作流添加用于跟踪安全功能分数改进的过程 | 网络 |
| 工程和 SecOps 团队 | 更改控制更新是在 SOC 团队 Runbook 中进行的 | 第 2 层 SOC 工程师 | SOC 团队 Runbook 的更改控制通知过程 | 已批准对安全设备的更改 | 更改与 SOC 安全技术的Microsoft Defender XDR连接需要批准 | 将 Microsoft Defender for Cloud Apps、Defender for Identity、Defender for Endpoint、Security & Compliance Center 添加到 SOC Runbook | Y |
此外，SOC 团队本可以在下表中针对上述Defender 漏洞管理方案进行发现：
| SOC 团队 | 要求 | 满足要求的人员 | 满足要求的过程 | 相关技术 | 已识别差距 | 用例更改日志 | 豁免 (Y/N) |
|---|---|---|---|---|---|---|---|
| SOC 监督 | 已识别并分类连接到已批准的网络的所有资产 | SOC 监督、BU 所有者、应用程序所有者、IT 资产所有者等。 | 集中式资产管理系统，用于根据风险发现和列出资产类别和属性。 | ServiceNow 或其他资产。 Microsoft 365 设备清单 |
仅发现了 70% 的资产。 Microsoft Defender XDR修正跟踪仅对已知资产有效 | 成熟的资产生命周期管理服务，确保Microsoft Defender XDR 100% 覆盖 | 网络 |
| 工程 & SecOps Teams | 根据策略修正资产中的高影响和严重漏洞 | SecOps 工程师、SOC 分析师：漏洞 & 合规性、安全工程 | 定义高风险和严重漏洞分类的过程 | Microsoft Defender 漏洞管理仪表板 | Defender for Endpoint 已确定影响大、警报高的设备，没有修正计划或实施Microsoft建议的活动 | 添加工作流，以便在每个策略的 30 天内需要修正活动时通知资产所有者;实现票证系统，以通知资产所有者修正步骤。 | 网络 |
| 监视团队 | 威胁和漏洞状态通过公司 Intranet 门户报告 | 第 2 层 SOC 分析师 | 从Microsoft Defender XDR自动生成的报告，其中显示了资产的修正进度 |
调查Microsoft Defender XDR中的警报 安全功能分数监视 |
不会向资产所有者传达有关资产威胁和漏洞状态的视图或仪表板报告。 | 创建自动化脚本，以填充组织的高风险和关键资产漏洞修正状态。 | 网络 |
在这些示例用例中，测试揭示了 SOC 团队要求中的一些差距，这些要求是作为每个团队职责的基线建立的。 用例清单可以根据需要提供全面的，以确保 SOC 团队已准备好Microsoft Defender XDR与新的或现有的 SOC 要求集成。 由于这是一个迭代过程，因此用例开发过程和用例输出内容自然适用于更新和完善 SOC 的 Runbook，并吸取经验教训。
更新生产 Runbook 和 playbook
针对所有差距修正用例测试后，所学到的经验教训和收集的指标可以合并到 SOC 团队的生产 Runbook 中， (作流程) 和 playbook (事件响应和升级过程) 。
SOC 团队 Runbook 和 playbook 的维护可以通过多种方式进行组织。 每个 SOC 团队可能负责自己的工作，或者可能有一个集中版本供所有团队在中央存储库中共享。 单个组织的 Runbook 和 playbook 管理基于规模、技能集、角色和职责分离。 更新 Runbook 后，应遵循 playbook 更新过程。
使用标准框架进行升级
Playbook 是 SOC 团队在发生真实事件时需要遵循的步骤，具体取决于用例的成功集成和测试。 因此，SOC 必须遵循正式的事件响应方法，例如 NIST 事件响应Standard，它已成为事件响应的领先行业标准之一。
NIST 四步事件响应过程包括四个阶段：
- 准备
- 检测和分析
- 包含、消除和恢复
- 事件后活动
示例：跟踪准备阶段活动
升级 playbook 的核心基础之一是确保每个 SOC 团队在事件或事件之前、期间和之后应该执行的作没有什么歧义。 因此，最好是分步列出说明。
例如，“准备”阶段可以包括任务的 if/then 或 XoR 矩阵。 对于新的网络钓鱼变体示例用例，此类矩阵可能如下所示：
| 为什么需要升级？ | 后续步骤 |
|---|---|
| SOC 监视中评级为 严重 触发 >的警报 500/小时 | 转到 Playbook A 第 2 节活动 5 (，其中包含 playbook 部分的链接) |
| 电子商务报告了潜在的 DDoS 攻击 | 调用 Playbook B 部分 C，活动 19 (，并链接到 playbook 部分) |
| 高管报告可疑电子邮件为鱼叉钓鱼企图 | 转到 Playbook 5，第 2 部分，活动 5 (，其中包含 playbook 部分的链接) |
执行“准备”阶段后，组织应调用 NIST 概述的剩余阶段：
- 检测和分析
- 包含、消除和恢复
- 事件后活动
后续步骤
提示
想要了解更多信息？ 请在我们的技术社区中与 Microsoft 安全社区互动：Microsoft Defender XDR 技术社区。