通过

日志记录和威胁检测

日志记录和威胁检测使组织能够在安全事件升级为全面违规之前识别、调查和响应安全事件。 与传统的定期日志评审不同，新式云环境需要跨标识、网络、数据和应用程序层进行持续监视、行为分析和集中关联，以检测利用快速预配、临时资源和分布式体系结构的多阶段攻击。 实施全面的日志记录和威胁检测功能的组织可以实现快速事件响应和取证准备，而忽视这些控制的组织将面临长时间的攻击者停留时间、未检测到的特权升级以及无法重建违规时间线。

如果没有全面的日志记录和威胁检测功能，组织将面临长期未被检测到的威胁、导致事件重建困难的不完整取证证据，以及法规合规性差距。

下面是日志记录和威胁检测安全域的三大核心支柱。

启用检测功能： 在应对威胁之前，必须先部署智能检测系统，以持续监视已知攻击模式、异常行为和泄露指标。 本机威胁检测服务利用行为分析和威胁情报来识别传统访问控制无法阻止的可疑活动，从 SQL 注入尝试和恶意软件上传到凭据滥用和数据外泄。 在所有关键资源类型（计算、数据、身份、网络）中实施检测，以确保没有攻击面未被监控。

相关控件：

启用全面的日志记录： 在所有云层（资源日志（数据平面作）、活动日志（管理平面更改）、标识日志（身份验证和授权事件）和网络日志（流量流和防火墙决策）之间实施系统审核日志记录。 全面的日志记录提供了重建攻击时间线、范围事件爆炸半径和支持合规性要求所需的取证证据。 如果没有跨越标识、网络和数据访问的完整审核线索，事件响应者就缺乏确定访问的内容、访问者、访问者的时间和地点的可见性，从而延长了违规停留时间，并增加了监管风险。

相关控件：

集中和分析： 将所有源的日志聚合到集中式安全信息和事件管理（SIEM）平台，以实现关联、高级分析和自动响应。 集中化通过将标识、网络和数据平面上的事件关联起来，将隔离日志流转换为可作的威胁智能，以揭示单源监视无法检测到的多阶段攻击链。 建立符合合规性要求和业务需求的纪律保留策略，并确保在所有系统中实现准确的时间同步，以保持取证完整性并启用精确的事件重建。

相关控件：

LT-1：启用威胁检测功能

Azure Policy： 请参阅 Azure 内置策略定义：LT-1。

安全原则

跨计算、存储、数据库和标识服务启用威胁检测功能，以识别已知的攻击模式、异常行为和可疑活动。 使用行为分析和威胁智能来检测传统访问控制无法阻止的威胁。

待缓解风险

攻击者利用缺乏本机威胁检测的环境来执行对传统安全控制不可见的攻击。 缺少通过行为分析和威胁情报驱动的监控：

  • 未检测到的恶意软件和攻击： 上传到存储的恶意文件或针对数据库的利用尝试未检测到，因为基于签名或网络层的防御会错过复杂的有效负载。
  • 静默数据外流： 由于缺少行为基线和流量异常检测，大规模数据提取、异常查询模式或异常访问流量会逃避检测。
  • 横向运动失明： 由于跨服务的关联和威胁情报未整合，攻击者可以从存储到计算再到数据库跨资源行动，而不会触发警报。
  • SQL 注入和应用程序攻击： 通过恶意查询或应用程序层攻击的数据库利用尝试在没有实时查询分析和威胁模式匹配的情况下继续不受监视。
  • 长时间停留： 攻击者可在长时间内（数天至数月）维持持续访问，因为侦察、部署和执行阶段不会触发警报，从而延迟事件响应并加剧漏洞影响。
  • 内幕威胁不透明性： 恶意或疏忽的内部人员行为与合法流量模式混杂，缺乏针对特权访问的用户行为分析（UBA）和异常检测。

缺乏全面的威胁检测会导致平均检测时间（MTTD）从数小时延长到数周，增加漏洞成本，并使对手能够在您的云基础设施中建立深层持久性。

MITRE ATT&CK

  • 初始访问（TA0001）：利用 Web 应用程序或 API 中未检测到的漏洞利用面向公众的应用程序（T1190）来获取初始立足点。
  • 执行（TA0002）：在计算或无服务器资源中执行恶意代码的命令和脚本解释器（T1059），而无需触发行为警报。
  • 持久性（TA0003）：帐户操作（T1098）导致服务主体的修改或创建后门标识未被检测到，由于缺乏异常监控。
  • 防御逃避（TA0005）：损害防御（T1562），通过禁用日志记录、监控代理或安全服务来在盲点操作。
  • 集合（TA0009）：云存储中的数据（T1530）无提示地捕获 Blob 容器或对象存储，而无需进行卷或基于模式的检测。
  • 外泄（TA0010）：通过合法 API 终结点以流量或时间触发行为分析警报的方式，通过 Web 服务（T1567）流式传输数据。
  • 影响 （TA0040）：资源劫持（T1496）部署加密货币挖矿程序或计算滥用，但未被资源消耗异常检测发现。

LT-1.1：为云服务启用威胁检测

跨所有关键云服务部署本机威胁检测功能，通过行为分析和威胁智能识别恶意活动、异常行为和已知攻击模式。 此基础层提供针对计算、存储、数据库和密钥管理服务的威胁的第一道防御线。 实施以下步骤以建立全面的威胁检测覆盖范围：

  • 使用云原生威胁检测： 为计算、存储、数据库和标识服务部署云安全状况管理平台的威胁检测功能，提供行为分析和威胁智能驱动的监视。

  • 启用全面的服务覆盖范围： 使用 Microsoft Defender for Cloud 为所有关键 Azure 服务激活威胁检测，涵盖虚拟机、存储帐户、数据库、容器和 Key Vault 实例。

  • 查看检测功能： 使用 Microsoft Defender for Cloud 安全警报参考指南 熟悉安全团队可用的检测功能，以了解警报类型、严重级别和响应要求。

  • 解决检测差距问题： 对于没有内建威胁检测能力的服务，请收集数据平面日志并路由到 Microsoft Sentinel 进行自定义分析规则和行为检测。

  • 优化警报质量： 配置警报筛选和分析规则，以减少误报，并从日志数据中提取高质量的警报，根据工作负荷关键性和风险容忍度优化检测敏感度。

LT-1.2：启用高级威胁检测和分析

通过集中安全遥测、部署统一的扩展检测和响应（XDR）平台以及使用威胁情报丰富警报来增强基本威胁检测。 此高级层支持跨多个域的威胁关联、针对特定于组织的攻击模式的自定义检测，以及加速调查和响应的上下文丰富的警报。 通过以下步骤构建此高级检测功能：

  • 集中安全遥测： 将来自云安全平台、终结点保护、标识系统和应用程序服务的警报和日志数据聚合到 Azure Monitor 或 Microsoft Sentinel 中，以便统一分析和关联。

  • 部署统一的 XDR 平台： 使 Microsoft Defender XDR 能够跨 Microsoft 365 Defender（终结点、电子邮件、协作）、Microsoft Defender for Cloud（Azure 基础结构）和Microsoft Entra ID（标识）与跨域事件分组和自动调查工作流关联威胁检测。

  • 生成自定义检测规则： 创建自定义 分析规则 ，这些规则与组织特定的威胁模式、攻击指示器和业务逻辑冲突匹配，预生成的检测无法解决。

  • 使用威胁智能进行扩充： 将 Microsoft Defender 威胁情报 与威胁参与者归属、基础结构信誉、漏洞利用智能和泄露指示器关联来丰富警报。

  • 利用威胁指标： 在 Microsoft Sentinel 中实施 威胁情报指标 ，以便针对已知的恶意基础结构和威胁参与者活动自动匹配可观测对象的（IP 地址、域、文件哈希、URL）。

实现示例

全球制造组织支持跨 300 多个 Azure 资源（跨存储帐户、SQL 数据库、Cosmos DB 实例和 IoT 生产系统）进行全面的威胁检测，以减少平均检测（MTTD）复杂攻击的时间。

挑战： 传统的安全监视依赖于隔离的服务特定警报，且跨存储、数据库、标识和电子邮件系统没有关联。 安全团队缺乏统一的可见性来检测跨网络钓鱼活动、凭据泄露和数据外泄的多阶段攻击。 检测复杂威胁的平均时间超过 30 天。

解决方案方法：

  • 全面的云威胁检测：已在超过 150 个存储帐户、40 个 SQL 数据库实例、12 个 Cosmos DB 帐户和 PostgreSQL 数据库中启用 Microsoft Defender for Cloud 服务，为数据平面的操作提供基于行为分析和威胁情报驱动的检测。
  • 统一 XDR 平台： 已部署Microsoft Defender XDR，将威胁检测关联到 Microsoft 365 Defender（终结点、电子邮件、协作）、Microsoft Defender for Cloud（Azure 基础结构）和 Microsoft Entra ID（标识）与自动化跨域事件关联。
  • 自定义分析规则： 创建了检测多阶段攻击的 Sentinel 分析规则，包括存储访问异常与 SQL 数据库架构枚举、Cosmos DB 批量提取模式以及跨服务凭据喷洒活动相吻合。
  • 威胁情报扩充： 集成Microsoft Defender 威胁情报，以使用威胁参与者归属、已知攻击基础结构和漏洞利用上下文来丰富警报。

结果： 部署后不久，Defender XDR 检测并遏制了一条从网络钓鱼到数据外泄的攻击链，威胁情报识别出与已知针对制造业知识产权的APT目标相匹配的基础设施。 自动跨域事件关联使安全团队能够快速调查和响应以前在长时间未检测到的多阶段攻击。

严重性级别

必须具有。

控件映射

  • NIST SP 800-53 Rev.5： SI-4（1）、SI-4（2）、SI-4（5）、SI-4（12）、SI-4（23）、AU-6（1）、AU-6（3）
  • PCI-DSS v4： 10.6.1、10.6.2、10.6.3、10.8.1、11.5.1
  • CIS 控件 v8.1：8.11 、13.1、13.2
  • NIST CSF v2.0： DE.CM-1、DE.CM-4、DE.CM-7
  • ISO 27001：2022： A.8.16、A.5.24
  • SOC 2： CC7.2、CC7.3

LT-2：为标识和访问管理启用威胁检测

Azure Policy： 请参阅 Azure 内置策略定义：LT-2。

安全原则

监视身份验证和授权事件，以检测凭据泄露、异常登录模式和帐户滥用行为。 确定行为异常，包括过度的身份验证失败、不可能的行程、过时账户的使用和未经授权的权限提升。

待缓解风险

基于标识的攻击仍然是云泄露的主要初始访问途径，但许多组织缺乏行为监视来检测凭据滥用和异常访问模式。 没有以身份为中心的威胁检测：

  • 凭据泄露盲点： 被盗、泄露或暴力破解的凭据在长时间（数周到数月）内使用而不被检测到，因为缺乏登录异常和风险评分。
  • 无法检测的跨地域访问： 在无法实现的时间范围内从不同地理位置成功进行身份验证，表明凭据已共享或泄露，却因为缺乏基线分析而未能被监测到。
  • 已弃用的帐户利用： 孤儿账户、前员工账户或未使用的服务主体账户提供攻击者用以规避用户行为审查的持久立足点。
  • 特权升级静默： 攻击者将自己添加到管理角色，创建新的特权标识或修改组成员身份，而不会触发审核警报或异常检测。
  • 密码喷射成功： 低慢速密码猜测攻击可以避免达到帐户锁定阈值，并可在租户中没有聚合的身份验证失败分析的情况下规避检测。
  • MFA 绕过技术： 攻击者利用旧式身份验证协议、会话重播或 MFA 疲劳攻击成功，因为未标记或阻止有风险的登录行为。
  • 内部威胁不透明度： 具有合法凭证的恶意内部人员会在没有用户行为分析的情况下与正常活动模式混合，从而泄露数据或滥用特权访问。

无法监视标识和访问异常使得攻击者可以使用有效的凭据进行操作，从而绕过网络和端点控制，同时保持低检测特征。

MITRE ATT&CK

  • 初始访问（TA0001）：有效帐户（T1078）利用泄露的凭据进行进入，表现为合法身份验证。
  • 凭据访问（TA0006）：暴力破解（T1110）对用户和服务帐户执行密码喷射或凭据填充攻击。
  • 凭据访问（TA0006）：不安全的凭据（T1552）从公共数据泄露数据库或暗网源中获取泄露的凭据。
  • 持久性（TA0003）：帐户操控（T1098）创建后门帐户、将帐户添加到特权组或修改身份验证方法。
  • 特权提升（TA0004）：有效帐户（T1078.004）滥用云帐户来提升权限或承担更高特权角色。
  • 防御逃避（TA0005）：通过利用令牌、Cookie 或会话项目这种备用身份验证手段（T1550），绕过多因素身份验证（MFA）要求。
  • 横向移动（TA0008）：使用备用身份验证材料（T1550.001）传递令牌或会话凭据来访问其他云资源。

LT-2.1：启用Microsoft Entra ID 威胁检测和监视

通过为所有标识资源启用审核日志记录和登录监视，从而全面了解标识和身份验证活动。 此基础遥测可以检测可疑的身份验证模式、对标识配置进行未经授权的更改，以及潜在的帐户泄露指示器。 配置以下监视功能：

  • 启用全面的审核日志记录： 激活 Microsoft Entra 审核日志 ，为对标识资源所做的所有更改（包括用户和组管理、角色分配、应用程序注册和策略修改）提供完整的可跟踪性。

  • 监视身份验证活动： 跟踪登录报告以捕获托管应用程序和用户帐户的所有身份验证事件，为正常访问模式建立基线并识别异常。

  • 检测有风险的登录模式： 启用对有风险登录的监视，以标记来自可疑源的身份验证尝试、不可能的旅行方案、不熟悉的位置或泄露的凭据使用情况，指示潜在的帐户泄露。

  • 确定已泄露的帐户： 监视标记为有风险的用户，以检测显示多个风险指示器的帐户，这些指标需要通过自动或手动评审工作流进行即时调查和修正。

  • 与 SIEM 平台集成： 将Microsoft Entra ID 日志路由到 Azure Monitor、 Microsoft Sentinel 或第三方 SIEM 平台，以便进行高级关联、长期保留和跨域威胁检测分析。

LT-2.2：实现标识保护和基于风险的控制

使用高级风险检测、自适应访问控制和 AI 支持的调查功能增强标识监视。 此高级层应用机器学习来检测复杂的标识攻击、自动执行基于风险的身份验证，并将保护扩展到跨云和本地基础结构的混合环境。 实现以下高级功能：

  • 部署标识风险检测： 启用 Microsoft Entra ID Protection ，以检测和修正标识风险，包括泄露的凭据、来自匿名 IP 地址的登录、恶意软件链接源以及使用机器学习和威胁情报的密码喷洒攻击。

  • 实现基于风险的访问控制： 配置标识保护策略以通过Microsoft Entra 条件访问强制实施自适应身份验证要求，要求 MFA 进行中等风险登录，并阻止高风险身份验证尝试，直到修正。

  • 监视云基础结构标识威胁： 启用 Microsoft Defender for Cloud 工作负荷保护 ，以检测可疑标识活动，包括已弃用的帐户使用情况、过度失败的身份验证尝试和异常服务主体行为。

扩展到混合环境： 对于具有本地 Active Directory 的组织，请部署 Microsoft Defender for Identity 来监视域控制器、检测高级威胁、识别泄露的标识，以及调查跨混合基础结构的恶意内部作。

使用 AI 加速调查： 利用 Microsoft Security Copilot ，通过自然语言查询、自动化威胁分析、引导式修正工作流以及 AI 驱动的身份信号关联来缩短跨 Microsoft Defender XDR、Sentinel 和 Entra ID Protection 的调查时间。

实现示例

拥有 8,000 名员工的金融服务组织实现了全面的标识威胁检测，以打击针对云银行应用程序和客户数据存储库的基于凭据的攻击。

挑战： 传统的身份验证监视缺少行为分析来检测基于凭据的攻击，包括不可能的旅行、密码喷射活动和休眠帐户利用。 安全团队依赖于手动日志评审，仅在欺诈事件或客户投诉后发现泄露。 检测基于标识的攻击的平均时间超过 30 天。

解决方案方法：

  • 标识风险检测和保护： 已部署Microsoft Entra ID Protection，其基于风险的条件访问策略会阻止高风险登录，要求 MFA 进行中等风险身份验证尝试，并自动强制密码重置以检测泄露凭据。
  • 高级 SIEM 分析： 创建了 Sentinel 分析规则，检测不可能的旅行模式、密码喷洒攻击（来自单个源的 10 多个帐户中的 50 多个故障）、更改窗口外的特权升级和休眠帐户重新激活。
  • 混合环境监视： 在 12 个本地域控制器上部署了 Defender for Identity，用于监视 Active Directory 信号，并与云身份验证模式相关联，以便完全可见性。
  • AI 提供支持的调查： 集成支持自然语言事件查询的 Microsoft Security Copilot，自动化威胁上下文强化、引导修正工作流，以及在标识妥协与资源访问之间进行跨域关联。

结果： 部署后不久，Identity Protection 标记了被盗账户，Sentinel 在几分钟内检测到并遏制了凭据填充攻击，Security Copilot 使得安全团队能够通过自然语言查询快速调查身份相关的威胁。 组织在检测和响应以前长时间未被检测到的基于身份的攻击方面实现了显著加快。

严重性级别

必须具有。

控件映射

  • NIST SP 800-53 Rev.5： AU-2（1），AU-6（1），AU-6（3），IA-4（4），SI-4（1），SI-4（12）
  • PCI-DSS v4： 8.2.8、10.2.1、10.2.2、10.6.1
  • CIS 控件 v8.1： 6.2、8.5、8.11
  • NIST CSF v2.0： DE.CM-1、PR.AC-4、PR.IP-8
  • ISO 27001：2022： A.5.16、A.8.15、A.8.16
  • SOC 2： CC6.1、CC7.2、CC7.3

LT-3：启用日志记录以进行安全调查

Azure Policy： 请参阅 Azure 内置策略定义：LT-3。

安全原则

启用跨数据平面操作、控制平面活动和标识事件的审核日志记录，以支持事件调查、取证分析和合规性验证。 全面的日志记录提供了重建安全事件并确定违规范围所需的证据线索。

待缓解风险

跨所有云层的综合审核日志记录为事件调查、漏洞重建和合规性验证提供了取证基础。 如果不对资源、活动和标识事件进行系统化的日志记录：

  • 法医盲点： 事件响应者无法确定在违规期间访问、修改或删除的内容，因为不会记录资源级数据平面作（密钥保管库访问、数据库查询、存储读取）。
  • 管理平面不透明度： 基础结构更改（角色分配、防火墙规则修改、资源删除）在没有审核线索的情况下继续，防止恶意或疏忽的管理行为归因。
  • 无法归因： 安全团队不能识别哪些标识执行了可疑行为、来自哪个 IP 地址、在何时或使用了哪些身份验证方法，除非有全面的 Microsoft Entra ID 日志支持。
  • 横向移动隐蔽性： 攻击者在资源之间移动（从 VM 到存储，再到数据库），不会留下可调查的痕迹，因为跨服务活动的相关性缺乏审计数据。
  • 合规性失败： 法规框架（PCI-DSS、HIPAA、SOC 2）要求针对所有数据访问和管理作提供详细的审核线索，缺少日志记录会造成明显的合规性差距和审核结果。
  • 延长停留时间： 如果没有全面的日志，安全团队仅在外部通知（客户投诉、法规披露）之后（而不是通过内部监视）发现违规行为，从而将平均停留时间从几天增加到数月。
  • 根本原因不明确： 事后评审无法确定初始访问途径、特权升级路径或横向移动序列，而无需跨标识、网络和数据平面的完整审核线索。

日志记录不足会将每个安全事件转化为长期、高成本的调查，伴随不完整的取证证据和不确定的调查范围。

MITRE ATT&CK

  • 防御规避（TA0005）：削弱防御（T1562.008），通过禁用或修改日志配置，以便在监控盲区内运行。
  • 防御逃避（TA0005）：指标清除（T1070）通过删除或篡改日志以去除恶意活动的证据。
  • 发现（TA0007）：云基础结构发现（T1580）枚举用于映射环境的资源、权限和配置。
  • 集合（TA0009）：从云存储（T1530）访问敏感数据的数据，无需数据平面日志记录即可跟踪读取、下载或传输。
  • 外泄（TA0010）：通过 Web 服务（T1567），在禁用或不完整事务日志记录的情况下，通过云 API 提取数据。

LT-3.1：启用基础结构和标识日志记录

通过捕获云环境中的所有管理平面操作和身份事件，来建立基础的审核线索。 此层提供了对基础结构变更的可见性，包括谁在进行更改、何时发生更改以及标识的使用方式——这些对于检测未经授权的修改、特权滥用和合规性违规至关重要。 启用以下核心日志记录功能：

  • 为管理平面操作启用活动日志：为所有订阅激活 Azure 活动日志，以捕获管理平面操作，包括资源创建、修改、删除（PUT、POST、DELETE操作）、角色分配、策略更改和管理操作。

  • 集中活动日志收集： 在管理组或订阅级别配置诊断设置，以将活动日志路由到集中式 Log Analytics 工作区，以便长期保留、关联分析和合规性报告。

  • 强制实施一致的日志记录覆盖范围： 部署 Azure Policy 以在所有订阅中强制实施诊断设置，确保活动日志收集一致，并防止创建新订阅时配置偏移。

  • 捕获身份验证事件： 启用 Microsoft Entra 登录日志 以捕获所有用户和服务主体身份验证事件，包括交互式登录、非交互式登录、服务主体登录和托管标识身份验证。

  • 跟踪标识更改： 启用 Microsoft Entra 审核日志 ，以跟踪对Microsoft Entra ID 所做的所有更改，包括用户/组管理、角色分配、应用程序注册、条件访问策略修改和管理单元更改。

  • 扩展标识日志保留期： 配置 Microsoft Entra 诊断设置，以将登录和审核日志路由到 Log Analytics 工作区或事件中心，以便在默认的 30 天Microsoft Entra 管理中心保留期之后延长保留期。

  • 监视混合标识基础结构： 对于混合环境，集成 Microsoft Entra Connect Health 日志以监视同步事件、身份验证失败和本地 Active Directory 集成运行状况。

  • 与网络事件相关联： 启用 LT-4（NSG 流日志、Azure 防火墙日志、VPN 网关诊断、应用程序网关日志）中所述的网络基础结构日志，以提供网络上下文，以便安全调查将标识和控制平面事件与网络流量模式相关联。

LT-3.2：启用平台和数据服务日志记录

将审核范围扩展到敏感业务数据所在的并被访问的数据平面操作。 平台服务日志捕获用于调查数据泄露、内部威胁和合规性违规（包括存储、数据库、机密管理、容器和 NoSQL 平台）所需的“访问内容”和“谁访问”详细信息。 配置以下数据平面日志记录：

  • 启用资源级数据平面日志： 激活 Azure 资源日志 ，以便在 Azure 服务中执行的数据平面作，包括跨所有平台服务的数据和配置执行读取、写入和删除作。

  • 日志存储操作： 启用 Azure 存储诊断日志，以捕获所有 Blob、文件、队列和表存储操作，包括 StorageRead、StorageWrite、StorageDelete 事件，以及调用方标识、源 IP 和操作延迟，以便进行取证调查。

  • 审核数据库活动： 配置 Azure SQL 数据库审核 以记录所有数据库查询、架构更改、权限授予、身份验证尝试和管理作-将审核日志路由到 Log Analytics 工作区或存储帐户，以便进行符合性和安全性监视。

  • 监视机密访问： 启用 Azure Key Vault 诊断日志 ，以捕获所有密钥、机密和证书访问作，包括检索、轮换、删除和权限更改，以及用于敏感资产跟踪的完整审核上下文。

  • 跟踪 NoSQL操作： 配置 Azure Cosmos DB 诊断日志 以捕获数据平面操作、查询性能、分区键访问模式和限流事件，以便进行安全和性能调查。

  • 涵盖其他数据平台： 为其他数据服务（包括 Azure Data Lake Storage、Azure Synapse Analytics、Azure Database for PostgreSQL/MySQL 和 Azure Redis 缓存）启用诊断日志记录，以捕获数据访问和管理操作。

0- 日志 Kubernetes 控制平面： 启用 Azure Kubernetes 服务（AKS）诊断 以捕获控制平面日志，包括 kube-apiserver（所有 API 请求）、kube-audit（安全审计轨迹）、kube-controller-manager、kube-scheduler 和群集自动缩放程序的日志。

  • 监视容器运行时： 配置 Container Insights 以从 AKS 群集、Azure 容器实例和已启用 Azure Arc 的 Kubernetes 群集（包括 Pod 生命周期事件和资源利用率）收集容器级指标、日志和性能数据。

  • 跟踪容器映像： 启用 Azure 容器注册表诊断 以记录映像推送/拉取作、存储库访问、身份验证事件、Webhook 调用和漏洞扫描结果。

  • 自动启用平台日志功能： 使用 Microsoft Defender for Cloud 自动为支持的 Azure 服务启用和配置资源日志，从而降低手动配置的复杂性。

  • 强制实施一致的覆盖范围： 部署 Azure Policy 以强制实施数据服务的诊断设置，确保日志收集一致、防止配置偏移以及自动修正不合规的资源。

LT-3.3：启用应用程序和工作负荷日志记录

通过捕获应用层活动、自定义工作负载操作和业务逻辑执行来完成审计覆盖率。 应用程序日志最深入地了解用户与系统交互的方式、他们访问的业务数据以及尝试的应用程序层攻击（对于检测内部威胁、应用程序滥用和绕过基础结构控制的复杂攻击至关重要）。 实现全面的应用程序日志记录：

  • 记录 Web 应用程序活动： 启用 Azure 应用服务诊断 以捕获应用程序日志、Web 服务器日志（IIS/HTTP.sys 日志）、详细的错误消息、失败的请求跟踪以及 Web 应用程序和 API 的部署日志。

  • 监视 API 网关作： 配置 Azure API 管理诊断 以记录 API 请求、响应、身份验证失败、速率限制冲突、策略执行详细信息、后端服务错误和订阅管理事件。

  • 跟踪无服务器函数执行： 通过与 Application Insights 的集成启用 Azure Functions 监视，以捕获函数执行、依赖项、异常、性能指标和自定义安全事件，包括授权决策和敏感操作审核。

  • 记录业务流程工作流： 对于 Azure 逻辑应用，启用诊断来记录工作流运行、触发事件、作结果和支持业务流程安全调查的集成失败。

  • 部署 VM 监视代理： 将 Azure Monitor 代理 部署到 Windows 和 Linux 虚拟机，以收集安全事件日志、Syslog、性能计数器和自定义日志文件。

  • 收集 Windows 安全事件： 为安全相关事件配置 Windows 事件日志收集，包括身份验证尝试（事件 ID 4624、4625）、特权提升（4672、4673）、帐户管理（4720、4726、4738）和审核策略更改（4719）。

  • 收集 Linux 系统日志： 为身份验证日志（/var/log/auth.log、/var/log/secure）、系统日志（/var/log/syslog、/var/log/messages）和特定于应用程序的安全日志配置 Linux Syslog 集合。

  • 监视终结点保护： 为 Windows 虚拟机启用 反恶意软件监视 ，以记录恶意软件检测事件、扫描结果、签名更新和策略冲突。

  • 实现结构化日志记录： 使用安全上下文（包括用户标识、源 IP 地址、请求 ID、作类型、数据分类标签、授权决策和业务事务标识符）实现结构化应用程序日志记录，以支持关联和取证分析。

  • 启用 APM 遥测： 启用 Application Insights 或等效的应用程序性能监视 （APM） 解决方案，以收集遥测、异常、自定义安全事件、微服务的分布式跟踪和依赖项跟踪。

  • 日志应用程序安全事件： 配置应用程序层安全事件日志记录，包括身份验证尝试、授权失败、输入验证失败、特权升级、敏感数据访问和业务逻辑安全冲突。

  • 监视 Web 应用程序攻击： 对于 Web 应用程序和 API，记录 HTTP 安全标头、内容安全策略冲突、CORS 策略强制执行和会话管理事件，以检测应用程序层攻击。

  • 捕获第 7 层攻击尝试： 启用 API 网关和 Web 应用程序防火墙的日志记录，以捕获第 7 层攻击，包括 SQL 注入尝试、跨站点脚本 （XSS）、远程代码执行尝试、本地文件包含、XML 外部实体 （XXE） 攻击和业务逻辑滥用模式。

  • 跟踪 API 滥用： 为支持威胁检测和事件响应而配置日志记录，涵盖速率限制执行、身份验证失败、机器人检测和 API 滥用模式。

实现示例

医疗保健 SaaS 提供商启用了全面的三层日志记录（基础结构/标识、平台/数据服务、应用程序/工作负载），以满足 HIPAA 审核要求，并支持为 200 多个医院客户提供的电子健康记录系统的安全调查。

挑战： 在不同独立服务之间的碎片化日志记录阻止了对多阶段攻击进行相关性分析。 安全团队缺乏针对 HIPAA 合规性的完整审核线索，并且无法重建跨基础结构更改、数据访问和应用程序滥用的事件时间线。 由于 120 多个服务之间的手动日志聚合，调查事件的平均时间超过 2 周。

解决方案方法：

  • 基础结构和标识日志记录： 在管理组级别配置集中式活动日志和 Microsoft Entra ID 日志（登录、审核），涵盖 5 个订阅，捕获 150 万个每日身份验证事件和 50K 管理操作，并保留 2 年，以满足合规性要求。
  • 平台和数据服务日志记录： 为 120 多个存储帐户、12 个 SQL 数据库、15 个 Key Vault、Cosmos DB 实例和 AKS 群集（kube-audit、Container Insights）启用了诊断日志，用于捕获数据平面作、查询性能和容器安全事件，从而生成 2M+ 每日审核事件。
  • 应用程序和工作负荷日志记录： 将 Azure Monitor 代理部署到 150 个 VM，为 8 个 Web 应用程序启用了应用服务诊断，为 3 个医疗保健集成 API 配置了 API 管理日志记录，并实现了 Application Insights，以便使用结构化安全上下文日志记录实现分布式跟踪。
  • 集中式关联： 部署Microsoft Sentinel 分析规则，将事件与分层保留策略（2 年 HIPAA 监管、1 年运营、90 天性能）和 Azure RBAC 访问控制相关联。

结果： 跨层日志关联实现了对跨角色分配、Key Vault 访问和存储外泄的复杂多阶段攻击的快速检测。 组织实现了完整的 HIPAA 审核跟踪合规性，并通过跨基础结构、平台和应用程序层的集中式日志分析大幅缩短了事件调查时间。

严重性级别

必须具有。

控件映射

  • NIST SP 800-53 Rev.5： AU-2（1）、AU-3（1）、AU-6（1）、AU-6（3）、AU-12（1）、SI-4（2）
  • PCI-DSS v4： 10.2.1、10.2.2、10.3.1、10.3.2、10.3.3.3
  • CIS 控件 v8.1： 8.2、8.3、8.5、8.12
  • NIST CSF v2.0： DE.AE-3、DE.CM-1、DE.CM-6、PR.PT-1
  • ISO 27001：2022： A.8.15、A.8.16、A.8.17
  • SOC 2： CC4.1、CC7.2、CC7.3

LT-4：启用网络日志记录以进行安全调查

Azure Policy： 请参阅 Azure 内置策略定义：LT-4。

安全原则

启用网络流量日志记录，包括流日志、防火墙决策日志、Web 应用程序防火墙事件和 DNS 查询，以支持事件调查和威胁检测。 网络日志为横向移动、命令和控制通信、数据外泄和策略冲突提供取证证据。

待缓解风险

网络流量日志提供关键取证证据，用于调查横向移动、数据外泄、命令和控制通信以及应用程序层攻击。 没有全面的网络日志记录：

  • 横向运动失明： 攻击者无需留下网络流证据即可在子网之间、虚拟机之间，或从计算服务到数据服务之间移动，从而防止识别东西向流量异常。
  • 外泄路径不透明度： 如果缺少流日志和防火墙流量分析，大规模数据传输到外部目标、异常出口模式或 DNS 隧道将无法检测到。
  • 应用程序层攻击不可见： 当禁用 WAF 日志、应用程序网关日志和第 7 层检查时，SQL 注入尝试、Web shell 上传、API 滥用或协议作绕过检测。
  • C2 通信未被检测： 如果没有 DNS 查询日志和网络连接基线，命令和控制信标、回调模式或隧道协议可能会逃避检测。
  • 策略冲突不可见： 违反网络分段、访问未经授权的端口/协议或绕过防火墙规则的流量将继续不受监视、侵蚀零信任边界。
  • 合规性差距： 法规标准（PCI-DSS 10.8、NIST AU-12）规定网络活动日志记录和监视—缺少日志会产生审核发现和认证风险。
  • 事件重建失败： 违规后取证无法确定攻击者来源 IP、横向移动路径或数据外泄路由，而无需全面的网络流和防火墙决策日志。

MITRE ATT&CK

  • 命令和控制（TA0011）：使用 HTTP/HTTPS 或其他标准协议的应用程序层协议（T1071）将 C2 流量与合法通信混合。
  • 命令和控制（TA0011）：DNS（T1071.004）利用 C2 通道或数据外泄隧道的 DNS 查询。
  • 横向移动（TA0008）：远程服务（T1021）使用 RDP、SSH 或云管理协议在系统之间移动。
  • 外泄（TA0010）：通过已建立的命令和控制连接在 C2 通道（T1041）上流式传输被盗数据。
  • 外泄（TA0010）：使用非标准端口或协议通过替代协议（T1048）外泄，以逃避出口监视。
  • 防御逃避（TA0005）：通过协议隧道（T1572）将恶意流量封装在合法的协议（DNS，HTTPS）中以绕过检查。

LT-4.1：启用网络安全日志记录和监视

捕获全面的网络流量遥测，以检测横向移动、数据外泄、命令和控制通信以及应用程序层攻击。 网络日志为攻击者在系统之间移动、他们联系的外部目标以及他们采用的攻击技术（调查复杂的多阶段违规至关重要）提供了证据线索。 启用以下网络日志记录功能：

  • 捕获网络流日志： 启用 网络安全组（NSG）流日志 以捕获流经 NSG 的 IP 流量的相关信息，包括源/目标 IP、端口、协议以及允许/拒绝决策，以便进行横向移动检测。

  • 监视防火墙活动： 启用 Azure 防火墙日志和指标 来监视防火墙活动、规则处理、威胁情报命中和 DNS 代理日志，以便进行集中式出口监视和威胁检测。

  • 日志应用程序层攻击： 启用 Web 应用程序防火墙（WAF）日志以捕获应用程序层攻击尝试，包括 SQL 注入、跨站点脚本和 OWASP 前 10 个冲突，以及请求详细信息和阻止决策。

  • 收集 DNS 查询数据： 收集 DNS 查询日志 ，以帮助关联网络数据和检测基于 DNS 的攻击，包括隧道、DGA 域和命令和控制通信。

  • 部署全面的监视： 使用 Azure Monitor 中的 Azure 网络监视解决方案 实现全面的网络可见性和集中式日志关联。

  • 启用流量分析： 将流日志发送到 Azure Monitor Log Analytics 工作区，并使用流量分析来深入了解网络流量模式、安全威胁、带宽消耗和策略冲突。

实现示例

挑战： 全球电子商务平台需要检测跨多区域基础结构的横向移动、数据外泄和应用程序层攻击，从而保护支付处理和客户数据系统。

解决方案方法： 通过跨 200 多个网络安全组部署具有流量分析的 NSG 流日志、在集中式出口点和应用程序网关上配置了 Azure 防火墙和 WAF 诊断日志、实现了 C2 检测的 DNS 分析，并将所有网络日志与 SIEM 集成，以便与标识和资源活动信号相关联。

结果： 流量分析识别了策略冲突（公开的管理端口）、检测到 WAF 日志并阻止了 SQL 注入活动，以及 DNS 分析标记的 DGA 模式，可实现快速 VM 隔离。 网络日志记录允许检测横向移动模式和数据外泄尝试，这些尝试在没有任何全面的流和防火墙日志分析的情况下保持不可见。

严重性级别

必须具有。

控件映射

  • NIST SP 800-53 Rev.5： AU-2（1）、AU-3（1）、AU-6（1）、AU-12（1）、SI-4（2）、SI-4（4）、SI-4（5）、SI-4（5）、SI-4（12）
  • PCI-DSS v4： 10.2.1、10.2.2、10.3.1、10.3.2、11.4.1、11.4.2
  • CIS 控件 v8.1： 8.2、8.5、8.6、8.11、13.6
  • NIST CSF v2.0： DE.AE-3、DE.CM-1、DE.CM-4、DE.CM-6、DE.CM-7
  • ISO 27001：2022： A.8.15、A.8.16
  • SOC 2： CC7.2

LT-5：集中管理和分析安全日志

Azure Policy： 请参阅 Azure 内置策略定义：LT-5。

安全原则

将所有云服务、标识系统和网络基础结构的安全日志集中到统一的平台进行关联和分析。 集中式聚合可以检测跨多个服务的多阶段攻击，而单独的日志源无法提供这种能力。

待缓解风险

跨不同服务和区域存储的分布式日志可防止多阶段攻击关联和延迟事件检测。 没有集中式日志聚合和 SIEM 功能：

  • 多阶段攻击隐蔽性： 跨越标识（Microsoft Entra ID）、网络（NSG 流）和数据（存储访问）的复杂攻击链未被检测到，因为隔离的日志孤岛阻碍了跨服务的关联和时间线重建。
  • 警报疲劳和噪音： 安全团队淹没在来自数十个不同服务的大量不相关警报中，关键模式被忽视——高优先级事件被埋没在数千个缺乏上下文和优先级的误报中。
  • 延迟检测： 手动日志聚合和分析将检测（MTTD）的平均时间从分钟延长到数天-攻击者完成完整的攻击周期（侦查→执行→外泄），然后防御者将证据关联起来。
  • 不完整的威胁搜寻： 当日志分散在特定于服务的接口之间时，安全分析师无法执行跨越多个服务、时间范围和攻击指示器的主动威胁搜寻查询。
  • 合规性审核失败： 法规要求要求要求集中进行安全监视和报告 - 分布式日志在安全作成熟度和审核准备方面造成了明显的差距。
  • 低效的事件响应： IR 团队浪费了宝贵的时间，在 Azure 门户、Log Analytics、特定服务日志和第三方工具之间手动周转，而非使用统一的调查流程。
  • 保留和治理丢失： 跨服务的保留策略不一致会导致调查完成前关键取证证据过期，并且缺少集中式访问控制会使敏感日志暴露给未经授权的查看。

如果没有集中式 SIEM/SOAR，组织会以分散的可见性、长时间的响应时间和无法检测协调的攻击来被动运行。

MITRE ATT&CK

  • 防御逃避（TA0005）：削弱防御机制（T1562），利用日志碎片化技术来避免跨越服务边界的基于相关性的威胁检测。
  • 发现（TA0007）：云基础结构发现（T1580）系统地枚举多个服务中的资源-模式仅通过集中分析可见。
  • 横向移动（TA0008）：使用备用身份验证材料（T1550），通过令牌或凭据在不同服务之间进行跨越移动——此移动仅能通过跨服务日志关联进行追踪。
  • 集合（TA0009）：暂存的数据（T1074.002）在外泄之前聚合来自多个源的数据-通过多服务异常分析检测到的暂存模式。
  • 导出（TA0010）：使用跨多个服务的分布式提取进行自动导出（T1020），以避免达到单个服务的流量阈值——只能结合聚合分析才能检测到。

LT-5.1：实现集中式日志聚合

通过将所有安全遥测路由到中心平台，将分散在服务中的碎片日志转换为统一的可见性。 日志聚合为跨服务关联提供了基础，可实现跨基础结构边界的攻击模式检测，从初始入侵到横向移动到数据外泄。 建立集中式日志收集：

  • 集中聚合日志： 将 Azure 活动日志集成到集中式 Log Analytics 工作区 以及来自所有服务的资源诊断日志，以实现跨资源关联和统一调查工作流。

  • 查询聚合日志： 将 Azure Monitor 与 KQL 查询配合使用，对来自 Azure 服务、终结点设备、网络资源和其他安全系统的聚合日志执行分析，以便进行模式检测和调查。

  • 配置警报： 使用从多个源聚合的日志创建警报规则，通过跨多个日志源的相关逻辑检测安全威胁和作问题。

  • 建立数据管理： 定义数据所有权、对日志实施基于角色的访问控制、指定符合性要求的存储位置，并设置保留策略，以平衡调查需求以及成本和法规义务。

LT-5.2：部署 SIEM 和 SOAR 功能

通过部署具有自动响应功能的安全信息和事件管理（SIEM），将日志聚合提升为主动安全作。 SIEM 通过相关规则、威胁分析和自动化事件工作流将原始日志转换为可作的智能，使安全团队能够以计算机速度检测和响应威胁，而不是手动调查速度。 生成 SIEM/SOAR 平台：

  • 部署 SIEM 平台：载入 Microsoft Sentinel 以提供安全信息事件管理（SIEM）和安全业务流程自动响应（SOAR）功能，用于集中的安全分析和事件响应。

  • 连接数据源： 将数据源连接到 Microsoft Sentinel，包括 Azure 服务、Microsoft 365、第三方安全解决方案和本地系统，以建立全面的安全可见性。

  • 配置分析规则： 在 Sentinel 中创建检测规则，以识别威胁，并根据跨多个日志源和时间段的相关安全事件自动创建事件。

  • 自动化响应动作： 使用 Logic Apps 实施自动化响应应急预案，以协调事件响应动作，包括隔离、通知和整改工作流。

  • 启用监视仪表板： 部署 Sentinel 工作簿和仪表板，以便进行安全监视、威胁搜寻、合规性报告和执行级别的安全状况可见性。

  • 集成 AI 驱动的分析：启用 Microsoft 安全 Copilot 与 Sentinel 的集成，在集中式安全日志中使用自然语言查询，提供基于 AI 的事件调查、威胁搜索和引导式响应建议。

实现示例

挑战： 一家跨国保险公司需要跨 12 个 Azure 订阅、500 多个资源以及 4 个地理区域提供统一的威胁检测和调查功能，用于处理策略持有人个人信息和索赔数据。

解决方案方法： 部署了集中式 Log Analytics 工作区，其中管理组级诊断设置路由所有 Azure 活动日志、标识遥测和关键资源日志（存储、SQL、Key Vault、防火墙）。 已启用Microsoft Sentinel SIEM，其中包含 Defender for Cloud、Entra ID Protection、Microsoft 365 Defender 和 Defender 威胁智能的数据连接器。 为保险特定威胁（批量索赔导出、特权访问异常、多阶段攻击）配置分析规则，配置用于包含工作流的自动响应剧本，并集成了安全 Copilot 以实现自然语言调查能力。 已建立符合性工作簿，用于将 HIPAA、PCI-DSS 和 SOC 2 的要求映射到 Sentinel 系统的遥测数据。

结果： Sentinel 通过跨订阅关联检测到凭据填充活动，并在几分钟内确定跨地理区域的横向移动。 安全 Copilot 使第 1 层分析师能够使用自然语言查询执行复杂的调查，而无需高级查询语言专业知识。 集中 SIEM 大幅缩短了在整个全球基础结构中检测和调查安全事件的平均时间。

严重性级别

必须具有。

控件映射

  • NIST SP 800-53 Rev.5： AU-2（1），AU-3（1），AU-6（1），AU-6（3），AU-6（5），AU-7（1），AU-12（1），SI-4（1），SI-4（2），SI-4（5），SI-4（12）
  • PCI-DSS v4： 10.4.1、10.4.2、10.4.3、10.7.1、10.7.2、10.7.3
  • CIS 控件 v8.1： 8.9、8.11、13.1、13.3、13.4、17.1
  • NIST CSF v2.0： DE.AE-2、DE.AE-3、DE.CM-1、DE.CM-4、DE.CM-6、DE.CM-7、RS.AN-1
  • ISO 27001：2022： A.8.15、A.8.16、A.5.25
  • SOC 2： CC7.2、CC7.3

LT-6：配置日志存储保留期

Azure Policy： 请参阅 Azure 内置策略定义：LT-6。

安全原则

配置符合法规要求、合规性授权和调查时间线的日志保留期。 通过分层保留策略平衡取证证据保留要求与存储成本。

待缓解风险

调查完成并造成合规性差距之前，日志保留策略不足或不一致会破坏取证证据。 没有与法规和操作要求相符的有纪律的保留：

  • 证据过期： 关键取证数据（身份验证日志、访问模式、网络流）在安全团队发现违规之前过期，平均停留时间为 200 天，这意味着日志必须持续足够长的时间才能调查历史泄露。
  • 合规性违规： 法规授权（PCI-DSS 10.7：1 年，GDPR：因司法管辖区而异，HIPAA：6 年）需要特定的保留期-保留期不足会导致审核发现、认证失败和监管处罚。
  • 未完成的事件重建： 当日志过早过期时，跨延长的入侵时间线的指标的历史关联就变得不可能—阻碍完整攻击链分析和根本原因确定。
  • 法律发现差距： 诉讼、法规调查和内部审核需要生产历史安全日志，缺少日志会产生法律风险和无法保护组织做法。
  • 模式分析盲点：机器学习模型和行为基线需要历史训练数据，由于数据的短期保留，难以检测到缓慢演化的攻击、季节性模式或长期趋势分析。
  • 成本超支： 缺少存储保留分层策略（热存储和冷存储）导致长期存档需求采用成本高昂的 Log Analytics 保留，而 Azure 存储可以更好地满足，这不必要地增加了运营成本。
  • 保留策略偏移： 跨服务保留不一致（活动日志的保留期为 90 天，资源日志为 30 天，某些服务无限期）会产生调查盲点和不可预知的取证覆盖。

保留期不足将长期违规转换为无法调查的事件，同时产生监管和法律风险。

MITRE ATT&CK

  • 防御逃避（TA0005）：攻击者利用短保留时间的指示器删除（T1070）以确保证据自然过期，从而无需主动删除日志。
  • 持久性（TA0003）：帐户操作（T1098），通过建立长期后门访问，相信在被检测到之前，初始入侵的证据会消失。

LT-6.1：实施日志保留策略

通过实施符合法规授权和调查时间线的分层保留策略，平衡取证保留需求与存储成本。 不同的日志类型需要不同的保留期（用于主动调查的热存储、最近历史记录的热存储，以及长期合规性的冷存档），从而优化调查能力和运营成本。 配置以下保留策略：

  • 将日志路由到适当的存储： 根据保留要求、合规性授权和调查时间线平衡热存储成本，创建诊断设置，将 Azure 活动日志和其他资源日志路由到适当的存储位置。

  • 配置短期到中期保留期： 使用 Azure Monitor Log Analytics 工作区 进行长达 1-2 年的日志保留，以使用 KQL 查询功能进行主动调查、威胁搜寻和作分析。

  • 实现长期存档存储： 使用 Azure 存储、数据资源管理器或 Data Lake 进行超过 1-2 年 的长期存档存储 ，以满足合规性要求（PCI-DSS、SEC 17a-4、HIPAA），并通过冷/存档层大幅降低成本。

  • 在外部转发日志： 如果需要多云可见性或旧集成，请使用 Azure 事件中心将日志转发到 Azure 外部的外部 SIEM、Data Lake 或第三方安全系统。

  • 配置存储帐户保留： 根据合规性要求 为 Azure 存储帐户日志配置保留策略 ，实现自动层转换和删除的生命周期管理。

  • 计划 Sentinel 日志保留期： 为 Microsoft Sentinel 日志实施长期存储策略，因为 Sentinel 使用 Log Analytics 工作区作为其后端，因此需要显式存档配置以超出工作区限制的扩展保留期。

  • 存档安全警报：配置Microsoft Defender for Cloud警报和建议的连续导出，以满足数据保留要求，因为 Defender for Cloud 数据在本机门户中的保留期有限。

实现示例

挑战： 一个受监管的金融服务组织需要满足多个保留要求（PCI-DSS：1 年，SEC 17a-4：7 年），同时以经济高效方式管理 80 TB 的年度安全日志数据。

解决方案方法：通过配置 Log Analytics 工作区，将默认日志保留策略设定为 1 年，并提供表级替代选项（标识日志：2 年、网络流：90 天），将所有日志导出到具有生命周期管理策略的 Azure 存储账户（热→冷在 90 天，冷→归档在 1 年），并在符合合规性要求的关键账户上配置不可变存储（WORM）。 已部署 Azure Policy，强制实施诊断设置和保留配置的一致性，创建了 Log Analytics 查询包，用于自动合规报告，并在发生事件期间建立了取证数据保留的法律保留流程。

结果： 实现了针对 PCI-DSS 和 SEC 17a-4 要求的完整审核跟踪合规性，同时通过分层存储策略大幅降低日志存储成本。 使用存档日志（超出以前的保留功能）成功调查历史安全事件，并通过自动证据收集和保留验证查询简化季度合规性审核。

严重性级别

应该有。

控件映射

  • NIST SP 800-53 Rev.5： AU-11（1），SI-12
  • PCI-DSS v4： 10.5.1、10.7.1、10.7.2、10.7.3
  • CIS 控件 v8.1： 8.3、8.10
  • NIST CSF v2.0： PR.PT-1、DE.CM-1
  • ISO 27001：2022： A.8.15
  • SOC 2： CC7.2

LT-7：使用批准的时间同步源

安全原则

将所有系统同步到权威时间源，以跨安全日志维护准确的时间戳。 一致的时间同步可实现可靠的日志关联、事件时间线重建和取证分析。

待缓解风险

在所有系统中准确同步的时间是记录相关性、取证分析和事件时间线重建的基础。 没有一致的时间同步：

  • 取证时间线损坏： 当来自不同源的日志显示冲突时间戳时，事件重建变得不可能，调查人员无法确定攻击序列或关联系统的事件（显示凌晨 10：00 攻击的 VM 日志，防火墙日志在上午 9：45 显示相同事件）。
  • SIEM 关联失败： 当时间偏移导致事件无序到达时，安全分析和关联规则会失败，因为规则逻辑需要按时间顺序排列的检测。
  • 身份验证绕过机会： 当时钟倾斜启用重播攻击或扩展令牌有效性窗口时，基于时间的身份验证机制（Kerberos 票证、JWT 令牌、OTP 代码）会变得可利用。
  • 合规性审核失败： 监管框架（PCI-DSS 10.4、SOC 2、HIPAA）强制实现审核跟踪完整性的准确时间同步- 时间偏移会创建审核结果和问题证据可靠性。
  • 误报/负警报： 当时间偏移导致正常活动出现在预期时间窗口之外或可疑模式显示为良性时，异常情况检测和行为分析将生成不正确的警报。
  • 证书验证错误： 当系统时钟在证书 NotBefore/NotAfter 窗口外部偏移时，SSL/TLS 证书有效性检查失败或错误地成功，这会导致服务中断或安全绕过。
  • 日志保留错误： 基于时间戳评估的保留策略（例如删除超过 365 天的日志）由于时间偏差而错误执行，可能导致提前删除证据或保留超过策略限制的日志。

时间同步失败会破坏所有安全日志记录和监视的证据完整性，导致法医分析结果无法得出结论和不可靠。

MITRE ATT&CK

  • 防御逃避（TA0005）：指示器删除（T1070）通过篡改时间戳来在合法时间窗口内隐藏恶意活动，或使证据出现在调查范围之外。

LT-7.1：配置安全时间同步

确保所有系统中的时间戳准确一致，以实现可靠的日志关联和事件时间线重建。 时间同步是取证完整性的基础 -- 即使是较小的时钟偏移也会损坏调查时间线，导致 SIEM 相关故障，并创建合规性审核结果。 将所有系统配置为使用受信任的时间源并持续监视偏移。 实现这些时间同步做法：

  • 配置 Windows 时间同步： 使用Microsoft默认 NTP 服务器在 Azure Windows 计算资源上利用 Azure 主机时间源通过虚拟化集成服务进行时间同步，除非具体要求另有规定。

  • 配置 Linux 时间同步： 使用 chrony 或 ntpd 与 Azure 提供的 NTP 源或适当的外部 NTP 服务器配置 Azure Linux 计算资源的时间同步 。

  • 保护自定义 NTP 服务器： 如果部署自定义网络时间协议 （NTP） 服务器， 请保护 UDP 服务端口 123 ，并实现访问控制，仅将时间服务查询限制为已授权客户端。

  • 验证时间戳格式：确认 Azure 资源生成的所有日志是否默认包括带时区信息（最好是 UTC）的时间戳，以实现全球部署中的明确时间线重建。

  • 监视时间偏移： 跨系统持续监视时间偏移，并为可能影响日志相关性、取证分析和基于时间的身份验证机制的重大同步问题（>5 秒）配置警报。

实现示例

挑战： 全球零售组织需要跨混合基础结构（本地销售点系统、Azure 云 POS 后端、付款处理）的取证时间线完整性，跨 2,500 家商店进行 PCI-DSS 合规性和欺诈调查。

解决方案方法： 通过验证 Azure PaaS 服务的自动 NTP 同步、配置 Azure VM（Windows/Linux）以使用 Azure 主机时间源并实现 Azure Monitor 警报，实现时间偏移 >5 秒的综合时间同步。 部署的 Log Analytics 查询检测相关日志源的时间戳异常情况，以及自动修正 Runbook 强制在受影响的 VM 上重新同步时间。 设立季度时间同步审核，以验证 NTP 配置和时间戳在应用程序、身份识别和网络日志中的一致性。

结果： 实现了与 PCI-DSS 时间同步要求相容性，并在混合日志源之间成功关联欺诈调查，且时间戳准确性一致，可实现精确的事件重建。 自动时间偏移监视和修正消除了由无序事件引起的误报安全警报，并确保跨全球分布式基础结构的取证时间线完整性。

严重性级别

应该有。

控件映射

  • NIST SP 800-53 Rev.5： AU-8（1），AU-8（2）
  • PCI-DSS v4： 10.6.1、10.6.2、10.6.3
  • CIS 控件 v8.1： 8.4
  • NIST CSF v2.0： DE.CM-1、PR.PT-1
  • ISO 27001：2022： A.8.15
  • SOC 2： CC7.2
  • Last updated on