手册

跨多个地理区域的严格数据驻留要求。

→部署多个 Microsoft Sentinel 工作区，每个区域一个。使用 Azure Lighthouse 进行集中管理。

原因: 将日志数据保留在地理边界内以符合法规要求，同时允许中央 SOC 在所有工作区中进行操作。

参考↗

Sentinel 工作区每天摄取超过 100 GB 的数据。

→将 Log Analytics 工作区定价层从即用即付切换到承诺层。

原因: 与标准定价相比，承诺层为大批量、可预测的数据摄取提供了显著的成本节约。

大批量日志（例如，Windows 安全事件）正在推高 SIEM 成本。

→1. 使用数据收集规则 (DCR) 在源头筛选事件。2. 将目标表配置为基本日志。

原因: DCR 通过仅收集必要的事件来降低摄取成本。基本日志可降低不需要完整分析的详细数据的存储成本。

参考↗

合规性要求数据保留两年以上（例如，七年）。

→将工作区配置为 90 天交互式保留和 7 年总保留期（存档层）。

原因: 平衡即时可搜索性（交互式）与低成本、长期存储（存档）。通过搜索作业访问存档数据。

从本地 Windows 和 Linux 服务器收集安全事件。

→安装 Azure Arc 代理进行管理，然后通过 Arc 部署 Azure Monitor 代理 (AMA)。

原因: Arc 将 Azure 控制平面扩展到本地，从而实现使用现代 AMA 代理进行本机管理和数据收集。

从支持 Syslog 的第三方设备（例如，防火墙）摄取日志。

→部署专用的 Linux VM 作为带有 AMA 的日志转发器。使用 CEF 格式处理结构化安全数据。

原因: 集中收集无法托管代理的设备的日志。CEF 为安全事件提供了标准化、可查询的架构。

将 Microsoft Defender XDR 的事件和警报摄取到 Sentinel 中。

→启用 Microsoft Defender XDR 数据连接器及其事件创建/双向同步选项。

原因: 创建统一的事件队列，并确保 Sentinel 和 Defender 门户之间的状态更改同步。

在源头筛选特定的 Windows 事件 ID 以减少摄取量。

→配置带有 XPath 查询的数据收集规则 (DCR)，以指定要收集的事件 ID。

原因: 通过在源代理处过滤数据（在发送到工作区之前），减少摄取量和成本。

需要对关键事件进行尽可能快的检测。

→使用近实时 (NRT) 分析规则。

原因: NRT 规则每分钟运行一次，提供约 1-2 分钟的检测延迟，比计划规则的最低 5 分钟快得多。

在特定时间窗口内检测事件阈值（例如，暴力攻击）。

→使用 KQL `summarize ... by bin(TimeGenerated, 5m), ...` 创建计划分析规则。

原因: `bin()` 函数对于将事件分组到离散、不重叠的时间窗口中以进行准确的阈值检测至关重要。

检测单个警报可能遗漏的复杂多阶段攻击。

→为高级多阶段攻击检测启用 Fusion 分析规则。

原因: Fusion 使用机器学习关联多个数据源中的低置信度信号，生成高置信度事件，从而减少警报疲劳。

根据异常行为检测内部威胁或受损账户。

→启用用户和实体行为分析 (UEBA)。

原因: UEBA 为用户和实体建立行为基线，然后标记不符合特定规则逻辑的显著偏差。

为多个数据源（例如，来自不同供应商的 DNS）编写单个与源无关的分析规则。

→在 KQL 查询中使用高级安全信息模型 (ASIM) 解析器。

原因: ASIM 提供了一个标准化架构，允许查询针对统一视图（例如，`imDns`）运行，而不是多个供应商特定的表。

将 Sentinel 内容（分析规则、工作簿）作为代码进行管理并在各个环境中部署。

→使用 Microsoft Sentinel 存储库连接 GitHub 或 Azure DevOps 存储库。

原因: 实现 CI/CD 工作流、版本控制以及安全内容（Sentinel 即代码）的自动化、一致部署。

自动化基本的事件分类任务，例如分配所有者、更改状态或添加标签。

→使用在事件创建时触发的自动化规则。

原因: 自动化规则轻量且同步，非常适合简单的分类操作，而无需 Logic App 的额外开销。

自动化涉及外部系统（例如，在 Entra ID 中阻止用户，发送 Teams 消息）的复杂事件响应。

→创建 Playbook（Azure 逻辑应用）并从自动化规则触发它。

原因: Logic Apps 提供复杂、多步骤响应和集成所需的编排引擎和连接器。

通过可视化实体（用户、IP、主机）之间的关系来了解攻击范围。

→在事件详细信息页面上使用调查图。

原因: 提供交互式攻击地图，方便查看相关实体和警报之间的连接和枢轴。

标准化并加速 SOC 团队的常见调查工作流程。

→在 Microsoft Security Copilot 中创建并共享一个 Promptbook。

原因: Promptbook 将一系列自然语言提示串联起来，为常见场景创建指导性、可重复的调查流程。

集中管理所有 Microsoft Defender 产品的安全权限。

→激活 Microsoft Defender XDR 统一 RBAC 模型。

原因: 用单一、精细的权限模型取代了各个产品特定的角色，从而简化了管理。

根据警报严重性自动隔离设备或修复文件。

→为设备组配置自动调查设置，将自动化级别设置为“完全”或“半自动”。

原因: 实现对常见威胁的无人值守修复。设备组允许工作站与关键服务器使用不同的自动化级别。

参考↗

立即在所有终结点上阻止已知恶意文件哈希、IP 地址或 URL。

→创建具有“阻止并修复”操作的入侵指标 (IoC)。

原因: 提供了一种快速、组织范围内的遏制机制，比等待 AV 签名更新更快。

通过阻止常见的攻击技术（例如，Office 创建子进程）来强化终结点。

→部署攻击面减少 (ASR) 规则，首先以“审核”模式运行以评估影响，然后再切换到“阻止”模式。

原因: ASR 规则是关键的预防性控制。审核模式对于在推出期间防止业务应用程序中断至关重要。

在实时终结点上执行深度取证调查或手动修复。

→使用实时响应功能建立远程 shell 并收集取证包。

原因: 提供对设备的直接实时访问，用于运行命令、收集文件和运行取证脚本。

重建攻击者在特定受损设备上的操作。

→分析设备时间线。

原因: 提供终结点上所有进程、网络、文件和注册表活动的详细、按时间顺序排列的事件日志。

检测凭据窃取和横向移动技术，如哈希传递/票据传递。

→在所有域控制器上部署 Microsoft Defender for Identity 传感器。

原因: Defender for Identity 直接监视本地 AD 身份验证流量，为基于身份的攻击提供高保真警报。

保护用户免受电子邮件附件中嵌入的零日恶意软件的侵害。

→配置带有动态交付选项的安全附件策略。

原因: 在沙盒中引爆附件以检查恶意行为，同时立即传递电子邮件正文，从而平衡安全性和生产力。

从用户邮箱中查找并删除所有钓鱼电子邮件实例。

→使用威胁资源管理器（或高级搜寻）搜索电子邮件并执行软删除或硬删除操作。

原因: 威胁资源管理器是一个强大的搜索和修复工具，可从整个组织的邮件系统中清除活动威胁。

通过阻止敏感文件下载到非托管（不合规）设备来防止数据泄露。

→使用条件访问应用控制配置 Defender for Cloud Apps 会话策略。

原因: 充当反向代理，在云应用会话中实时检查和控制用户活动，强制执行数据访问策略。

自动遏制像人为操作的勒索软件这样广泛的活跃攻击。

→在 Microsoft Defender XDR 中启用自动攻击中断。

原因: 利用跨域信号 (XDR) 以机器速度采取果断行动，例如禁用受损用户帐户和隔离设备。

跨所有 XDR 数据（终结点、电子邮件、身份、云应用）主动搜索威胁。

→使用 Kusto 查询语言 (KQL) 进行高级搜寻。

原因: 提供了一个强大的、基于查询的界面，可在 30 天的原始遥测数据中进行搜寻，从而发现逃避标准检测的威胁。

快速了解涉及多个警报和实体的复杂事件的完整范围。

→分析事件的攻击故事或调查图。

原因: 整合并可视化整个攻击链，显示攻击者如何从初始入口点横向移动到不同的资产。

将 Defender for Cloud 工作负载保护扩展到本地和多云服务器。

→使用 Azure Arc 载入服务器，然后启用 Defender for Servers 计划。

原因: Azure Arc 充当控制平面桥接，将非 Azure 资源映射到 Azure 中，以便它们可以由 Defender for Cloud 进行管理和保护。

快速了解复杂脚本（例如，PowerShell）的目的和潜在恶意性。

→将脚本粘贴到 Security Copilot 中，并请求分析其功能和风险。

原因: 利用生成式 AI 来反混淆和解释代码，显著加快了工件分析速度，而无需执行脚本。

立即遏制从本地 AD 同步的受损用户账户。

→在本地 Active Directory 中禁用该账户，然后触发即时 AD Connect 同步。

原因: 对于同步身份，本地 AD 是权威源。在此处禁用账户是最有效的遏制措施。

使用行业标准协议从 TIP 摄取外部威胁情报。

→在 Sentinel 中使用“威胁情报 - TAXII”数据连接器。

原因: 连接到 TAXII 2.x 服务器以自动导入 STIX 格式的指标，从而实现威胁情报的运营化。

参考↗

将已知威胁指标（IP、域、哈希）与所有已摄取日志源进行关联。

→将指标摄取到 ThreatIntelligenceIndicator 表中，并启用内置的“TI 映射...”分析规则。

原因: 这些规则可有效将威胁情报与日志中的标准化实体字段进行匹配，从而生成已知恶意活动的警报。

使用自定义指标列表（例如，业务合作伙伴的 IP、已终止的员工账户）进行警报或丰富。

→创建观察列表并将其与 KQL 查询中的数据连接。

原因: 观察列表充当自定义数据的简单键值存储，可轻松用于查询中的检测逻辑或减少误报。

成功的 KQL 搜寻查询需要保存并投入运行以进行自动检测。

→1. 将查询保存在“搜寻”边栏选项卡中。2. 将搜寻查询提升为计划分析规则。

原因: 将从临时发现（搜寻）到自动化、可重复检测（分析规则）的转变正式化。

根据 MITRE ATT&CK 框架评估检测覆盖范围并识别差距。

→在 Sentinel 中使用 MITRE ATT&CK 边栏选项卡。用相关战术/技术标记分析规则。

原因: 提供与行业标准框架映射的检测能力的视觉热图，指导检测工程。

保存搜寻期间发现的有趣结果或证据，以便后续跟进。

→从 KQL 查询结果创建搜寻书签。

原因: 捕获查询、结果和实体上下文，允许分析师保存发现，而无需立即创建完整事件。