Microsoft 365 认证 - 示例证据指南

概述

本指南是为 ISV 提供每个Microsoft 365 认证控制措施所需的证据类型和详细级别的示例。 本文档中共享的任何示例都不代表可用于证明控件正在得到满足的唯一证据，而仅充当所需证据类型的指南。

注意：用于满足要求的实际界面、屏幕截图和文档因产品用途、系统设置和内部流程而异。 此外，请注意，如果需要策略或过程文档，则 ISV 将要求发送实际文档，而不是如某些示例所示的屏幕截图。

认证中有两个部分需要提交：

1. 初始文档提交： 确定评估范围所需的少量高级文档。
2. 证据提交： 认证评估的每个控制范围内所需的完整证据集。

提示

试用 适用于 Microsoft 365 (ACAT) 的应用合规性自动化工具 ，通过自动化证据收集和控制验证实现Microsoft 365 认证。 详细了解 ACAT 完全自动化的控件。

结构

本文档直接映射到在合作伙伴中心认证期间将呈现的控件。 本文档中提供的指南详述如下：

• 安全域：所有控件分组到的三个安全域：应用程序安全性、操作安全性以及数据安全和隐私。
• 控制 () ：= 评估活动说明 - 这些控制 () 和关联的编号 () 直接来自 Microsoft 365 认证清单。
• 意向：= 计划中包含安全控制措施的原因及其旨在缓解的特定风险的意向。 希望这些信息将为 ISV 提供控制背后的推理，以便更好地了解需要收集的证据类型，以及 ISV 在制作证据时必须注意和了解哪些方面。
• 示例证据指南：= 给定以帮助指导 Microsoft 365 认证清单电子表格中的证据收集任务，这允许 ISV 清楚地看到认证分析师可以使用的证据类型的示例，该分析师将使用它来自信地确定控件是否已到位和维护 ，这绝不是详尽的。
• 证据示例：= 此部分提供针对 Microsoft 365 认证清单电子表格中的每个控件捕获的潜在证据的示例屏幕截图和图像，特别是针对电子表格) 中的操作安全性和数据安全和隐私安全域 (选项卡。 请注意，示例中带有红色箭头和框的任何信息都是为了进一步帮助你了解满足任何控制所需的要求。

安全域：应用程序安全性

控件 1 - 控件 16：

应用程序安全域控制可以通过过去 12 个月内发布的渗透测试报告来证明你的应用没有未解决的漏洞。 唯一需要提交的是信誉良好的独立公司的干净报告。

安全域：操作安全性/安全开发

“操作安全性/安全开发”安全域旨在确保 ISV 实施一组强大的安全缓解技术，以抵御来自活动组的无数威胁。 这旨在保护操作环境和软件开发过程，以构建安全的环境。

恶意软件防护 - 防病毒

控制 #1：提供管理防病毒做法和过程的策略文档。

• 意向：此控件的意图是评估 ISV 在考虑计算机病毒的威胁时，他们对所面对问题的理解。 通过在制定防病毒策略和流程时建立和使用行业最佳做法，ISV 提供了一种适合其组织缓解恶意软件所面临风险的能力的资源，列出了病毒检测和消除方面的最佳做法，并证明记录的策略为组织及其员工提供了建议的安全指南。 通过记录 ISV 如何部署反恶意软件的策略和过程，这可确保该技术的一致性推出和维护，以降低恶意软件对环境的风险。
• 示例证据指南：提供防病毒/反恶意软件策略的副本，详细说明基础结构中为推广防病毒/恶意软件最佳做法而实现的过程和过程。 示例证据
• 示例证据：

注意： 此屏幕截图显示了策略/流程文档，ISV 希望共享实际的支持策略/过程文档，而不只是提供屏幕截图。

控制 #2：提供证明防病毒软件正在所有采样系统组件上运行的明显证据。

• 意向：必须让防病毒 (AV) (或反恶意软件防御) 在你的环境中运行，以防范你可能意识到或可能不会意识到的网络安全风险，因为潜在的破坏性攻击在复杂程度和数量上都在增加。 将 AV 部署到支持其使用的所有系统组件，将有助于缓解环境中引入反恶意软件的一些风险。 它只需要一个终结点不受保护，就有可能为活动组提供攻击途径，从而获得进入环境的立足点。 因此，AV 应用作多个防御层之一，以防止此类威胁。
• 示例证据准则：证明 AV 的活动实例正在评估的环境中运行。 提供示例中支持使用防病毒 的每个设备的 屏幕截图，该屏幕截图显示防病毒进程正在运行、防病毒软件处于活动状态，或者如果你有一个用于防病毒的集中式管理控制台，则可以从该管理控制台进行演示。 如果使用管理控制台，请务必在屏幕截图中证明抽样设备已连接且正常工作。
• 证据示例 1：以下屏幕截图来自 Azure 安全中心：它显示已在名为“MSPGPRODAZUR01”的 VM 上部署了反恶意软件扩展。

• 证据示例 2

以下屏幕截图取自 Windows 10 设备，显示已为主机名“CLARANET-SBU-WM”打开了“实时保护”。

控制 #3：提供证明，证明防病毒签名在) 1 天内在所有环境中 (处于最新状态。

• 意向：每天识别数十万个新的恶意软件和可能不需要的应用程序 (PUA) 。 若要提供针对新发布的恶意软件的充分保护，需要定期更新 AV 签名，以考虑新发布的恶意软件。
• 存在此控件是为了确保 ISV 已考虑到环境的安全性以及过时 AV 对安全性的影响。
• 示例证据指南：提供每个采样设备的防病毒日志文件，显示每天应用更新。
• 示例证据：以下屏幕截图通过显示“Event 2000， Windows Defender”（即更新）来显示至少每天更新Microsoft Defender。 显示主机名，显示此名称取自作用域内系统“CLARANET-SBU-WM”。

注意： 提供的证据需要包括日志导出，以显示较长时间段的每日更新。 某些防病毒产品将生成更新日志文件，因此应提供这些文件或从事件查看器导出日志。

控制 #4：提供可证明的证据，证明防病毒配置为跨所有采样系统组件执行访问时扫描或定期扫描。

注意： 如果未启用按访问扫描，则至少启用每日扫描和alerting_ MUST _be。

• 意向：此控件的意图是确保快速识别恶意软件，以最大程度地降低它对环境的影响。 执行按访问扫描并自动阻止恶意软件时，这将有助于阻止防病毒软件已知的恶意软件感染。 如果由于误报导致服务中断的风险而不希望进行访问扫描，则需要实施适当的日常 (或更多) 扫描和警报机制，以确保及时响应恶意软件感染，以尽量减少损害。
• 示例证据指南：提供支持防病毒的示例中 每台设备的 屏幕截图，显示防病毒正在设备上运行，并配置为进行访问 (实时扫描) 扫描， 或者 提供屏幕截图，显示启用了定期扫描进行每日扫描、配置了警报以及示例中 每个设备的 上次扫描日期。
• 示例证据：以下屏幕截图显示了为主机“CLARANET-SBU-WM”启用了实时保护。

控制 #5：提供可证明的证据，证明防病毒配置为自动阻止恶意软件或隔离，并对所有采样的系统组件发出警报。

• 意向：恶意软件的成熟程度一直在不断演变，以及它们可能带来的不同程度的破坏。 此控件的意图是阻止恶意软件执行，从而阻止其执行其可能具有破坏性的有效负载，或者如果自动阻止不是一种选择，则通过发出警报并立即响应潜在的恶意软件感染来限制恶意软件可能造成严重破坏的时间。

• 示例证据指南：提供示例中支持防病毒 的每个设备的 屏幕截图，显示防病毒正在计算机上运行，并配置为自动阻止恶意软件、发出警报或隔离和发出警报。

• 示例证据 1：以下屏幕截图显示主机“CLARANET-SBU-WM”配置了针对 Microsoft Defender 防病毒的实时保护。 如设置所示，这会查找并阻止恶意软件在设备上安装或运行。

控制 #6：提供可证明的证据，证明在部署之前已批准应用程序。

• 意向：通过应用程序控制，组织将批准允许在操作系统上运行的每个应用程序/进程。 此控制的目的是确保已到位审批流程，以授权哪些应用程序/进程可以运行。

• 示例证据指南：可以提供证明正在遵循审批过程的证据。 这可能随已签名文档一起提供、在更改控制系统中进行跟踪，或者使用 Azure DevOps 或 JIRA 之类的内容来跟踪这些请求和授权。

• 示例证据：以下屏幕截图演示了管理层批准，即允许在环境中运行的每个应用程序都遵循审批过程。 这是 Contoso 的基于纸张的过程，但可以使用其他机制。

控制 #7：提供可证明的证据，证明存在并维护具有业务理由的已批准应用程序的完整列表。

• 意向：组织必须维护已批准的所有应用程序的列表，以及有关批准应用程序/流程的原因的信息。 这将有助于确保配置保持最新状态，并且可以根据基线进行评审，以确保未配置未经授权的应用程序/进程。

• 示例证据指南：提供已批准应用程序/流程的文档列表以及业务理由。

• 示例证据：以下屏幕截图列出了具有业务理由的已批准应用程序。

注意： 此屏幕截图显示了一个文档，预期 ISV 共享实际的支持文档，而不是提供屏幕截图。

控制 #8：提供支持文档，详细说明应用程序控制软件配置为满足特定的应用程序控制机制。

• 意向：应记录应用程序控制技术的配置以及如何维护技术的过程，即添加和删除应用程序/进程。 作为本文档的一部分，应详细说明每个应用程序/进程使用的机制类型。 这将馈入下一个控件，以确保按文档所述配置技术。

• 示例证据指南：提供支持文档，详细说明如何设置应用程序控制以及如何在技术中配置每个应用程序/进程。

• 示例证据：以下屏幕截图列出了用于实现应用程序控件的控制机制。 可在下面看到，1 个应用使用证书控件，其他应用使用文件路径。

注意： 此屏幕截图显示了一个文档，预期 ISV 共享实际的支持文档，而不是提供屏幕截图。

控制 #9：提供可证明的证据，证明应用程序控制已配置为所有采样系统组件中的文档。

• 意向：这样做的目的是根据文档验证是否在示例中配置了应用程序控制。

• 示例证据指南：提供示例中 每台设备的 屏幕截图，以显示其配置和激活了应用程序控件。 这应显示计算机名称、它们所属的组，以及应用于这些组和计算机的应用程序控制策略。

• 证据示例：以下屏幕截图显示了启用了软件限制策略的组策略对象。

下一个屏幕截图显示与上述控件一致的配置。

下一个屏幕截图显示了 Microsoft 365 环境，以及应用于此 GPO 对象“域计算机设置”的范围中包含的计算机。

此最终屏幕截图显示上述屏幕截图的 OU 中的作用域内服务器“DBServer1”。

补丁管理 - 风险排名

快速识别和修正安全漏洞有助于将活动组破坏环境或应用程序的风险降到最低。 修补程序管理分为两个部分：风险排名和修补。 这三种控制措施涵盖安全漏洞的识别，并根据它们构成的风险对其进行排名。

此安全控制组适用于平台即服务 (PaaS) 托管环境，因为应用程序/外接程序第三方软件库和代码库必须基于风险排名进行修补。

控制 #10：提供策略文档，用于控制如何识别和分配新安全漏洞并为其分配风险分数。

• 意向：此控制的目的是提供支持文档，以确保快速识别安全漏洞，以减少活动组利用这些漏洞的机会窗口。 需要建立可靠的机制，以识别涵盖组织使用的所有系统组件的漏洞：例如，操作系统 (Windows Server、Ubuntu 等 ) 、 (Tomcat、MS Exchange、SolarWinds 等 ) 的应用程序、 (AngularJS、jQuery 等 ) 的代码依赖项。 组织不仅需要确保及时识别资产中的漏洞，还需要相应地对任何漏洞进行排名，以确保根据漏洞存在的风险在适当的时间范围内进行修正。

注意 即使你在纯平台即服务环境中运行，你仍有责任识别代码库中的漏洞：即第三方库。

• 示例证据指南：提供支持文档 (而不是屏幕截图)

• 示例证据：此屏幕截图显示了风险排名策略的代码片段。

注意： 此屏幕截图显示了策略/流程文档，预期 ISV 共享实际的支持策略/过程文档，但不提供screenshot._

控制 #11：提供有关如何识别新安全漏洞的证据。

• 意向：此控件的意图是确保流程得到遵循，并且它足够可靠，可以识别整个环境中新的安全漏洞。 这可能不仅仅是操作系统;它可能包括环境中运行的应用程序和任何代码依赖项。

• 示例证据指南：可以通过以下方式提供证据：显示邮件列表的订阅，手动查看新发布的漏洞的安全源， (需要使用活动的时间戳进行充分跟踪，即使用 JIRA 或 Azure DevOps) （例如，查找过期软件库时，发现过期软件 (的工具可能是 Snyk， 或 可能是使用标识过期 software.) 的经过身份验证的扫描的 Nessus。

注意 如果使用 Nessus，则需要定期运行以快速识别漏洞。 建议至少每周一次。

• 示例证据：此屏幕截图演示了邮件组用于收到安全漏洞的通知。

控制 #12：提供证据，证明所有漏洞在识别后都分配了风险排名。

• 意向：修补需要基于风险，漏洞风险越高，需要修正的越快。 识别的漏洞的风险排名是此过程不可或缺的一部分。 此控制的目的是确保遵循记录的风险排名过程，以确保根据风险对已识别的所有漏洞进行适当排名。 组织通常利用 CVSS (常见漏洞评分系统) 供应商或安全研究人员提供的评级。 如果组织依赖于 CVSS，建议在流程中包含重新排名机制，以允许组织根据内部风险评估更改排名。 有时，由于应用程序在环境中部署的方式，漏洞可能不是应用程序。 例如，可能会释放影响组织使用的特定库的 Java 漏洞。

• 示例证据指南：通过屏幕截图或其他方式（例如 DevOps/Jira）提供证据，它表明漏洞正在经历风险排名过程，并被组织分配了适当的风险排名。

• 示例证据：此屏幕截图显示风险排名发生在 D 列内，并在 F 和 G 列中重新排名，如果组织执行风险评估并确定风险可以降级。 需要提供重新排名风险评估的证据作为支持证据

修补程序管理 - 修补

以下控件适用于修补程序管理的修补元素。 为了维护安全的操作环境，必须适当地修补应用程序/加载项和支持系统。 需要管理标识 (或公开发布) 和修补之间的适当时间范围，以减少“活动组”利用漏洞的机会窗口。 Microsoft 365 认证没有规定“修补窗口”，但认证分析师将拒绝不合理的时间范围。

此安全控制组适用于平台即服务 (PaaS) 托管环境，因为应用程序/外接程序第三方软件库和代码库必须基于风险排名进行修补。

控制 #13：提供用于修补范围内系统组件的策略文档，其中包括针对关键、高风险和中等风险漏洞的适当最小修补时间范围;和取消任何不受支持的操作系统和软件。

• 意向：许多安全合规性框架（PCI-DSS、ISO 27001、NIST (SP) 800-53）都需要修补程序管理。 良好的修补程序管理的重要性不能过分强调，因为它可以纠正软件、固件中的安全和功能问题并缓解漏洞，这有助于减少利用的机会。 此控制的目的是最大程度地减少活动组利用范围内环境中可能存在的漏洞的机会窗口。

• 示例证据指南：提供所有策略和过程的副本，详细说明修补程序管理的过程。 这应包括有关最小修补窗口的部分，并且不得在环境中使用不支持的操作系统和软件。

• 示例证据：下面是一个示例策略文档。

注意： 此屏幕截图显示了策略/流程文档，预期 ISV 共享实际的支持策略/过程文档，而不仅仅是提供screenshot._

控制 #14：提供所有采样系统组件正在修补的可证明证据。

注意： 包括任何软件/第三方库。

• 意向：修补漏洞可确保构成信息技术基础结构 (硬件、软件和服务) 的不同模块保持最新且没有已知漏洞。 需要尽快进行修补，以尽量减少在漏洞详细信息发布和修补之间发生安全事件的可能性。 当已知漏洞被利用在野外时，这一点就更关键了。

• 示例证据指南：提供示例和支持软件组件 中每台设备的 屏幕截图，其中显示修补程序的安装符合记录的修补过程。

• 示例证据：以下屏幕截图显示范围中的系统组件“CLARANET-SBU-WM”正在根据修补策略执行 Windows 更新。

注意： 修补所有范围内系统组件需要成为证据。 这包括如下内容：OS 更新、应用程序/组件更新 (i.e__、_ Apache Tomcat、OpenSSL 等 ) 、软件依赖项 (例如 JQuery、AngularJS 等 ) 等。

控制 #15：提供可证明的证据，证明环境中不使用任何不受支持的操作系统和软件组件。

• 意向：未由供应商维护的软件在加班后将遭受未修复的已知漏洞。 因此，不得在生产环境中使用不受支持的操作系统和软件组件。

• 示例证据指南：提供示例中 每个设备的 屏幕截图，其中显示运行的操作系统版本 (在屏幕截图) 中包含服务器名称。 此外，请提供在环境中运行的软件组件正在运行受支持的版本的证据。 为此，可以提供内部漏洞扫描报告的输出， (提供经过身份验证的扫描) 和/或检查第三方库（如 Snyk、 Trivy 或 NPM Audit）的工具的输出。 如果仅在 PaaS 中运行，则修补控件组只需要涵盖第三方库修补。

• 示例证据：以下证据表明，由于 Nessus 未标记任何问题，范围内系统组件 THOR 正在运行受供应商支持的软件。

注意： 完整的报告必须与认证分析师共享。

• 示例证据 2

此屏幕截图显示范围内系统组件“CLARANET-SBU-WM”在受支持的 Windows 版本上运行。

• 示例证据 3

以下屏幕截图显示了 Trivy 输出，完整报表未列出任何不受支持的应用程序。

注意： 完整的报告必须与认证分析师共享。

漏洞扫描

通过引入定期漏洞评估，组织可以检测其环境中的弱点和不安全之处，这可能为恶意参与者提供入侵环境的入口点。 漏洞扫描有助于识别环境中缺少的修补程序或错误配置。 通过定期执行这些扫描，组织可以提供适当的补救措施，以最大程度地降低由于这些漏洞扫描工具通常发现的问题而导致的泄露风险。

控制 #16：提供季度基础结构和 Web 应用程序漏洞扫描报告。 需要针对整个公共占用空间执行扫描， (IP 地址和 URL) 和内部 IP 范围。

注意： 这 必须 包括环境的全部范围。

• 意向：漏洞扫描查找组织计算机系统、网络和 Web 应用程序中可能存在的弱点，以识别可能导致安全漏洞和敏感数据泄露的漏洞。 行业标准和政府法规通常要求漏洞扫描，例如 PCI DSS (支付卡行业数据安全标准) 。

• 安全指标的一份题为“PCI DSS 合规性 2020 年安全指标指南”的报告指出，“从组织发现攻击者入侵系统漏洞开始，平均耗时 166 天。 一旦遭到入侵，攻击者平均可以访问敏感数据 127 天，因此此控制措施旨在识别范围内环境中的潜在安全漏洞。

• 示例证据指南：提供过去 12 个月中每个季度的漏洞扫描 () 的完整扫描报告。 报告应明确说明目标，以验证是否包括完整的公共占用空间，以及每个内部子网（如果适用）。 提供每个季度的所有扫描报告。

• 示例证据：示例证据是提供正在使用的扫描工具的扫描报告。 应提供每个季度的扫描报告以供审阅。 扫描需要包括整个环境系统组件， 因此：每个内部子网以及可供环境使用的每个公共 IP 地址/URL。

控制 #17：提供可证明的证据，证明在漏洞扫描期间识别的漏洞修正已按照记录的修补时间范围进行修补。

• 意向：如果无法快速识别、管理和修正漏洞和错误配置，则可能会增加组织遭到入侵的风险，从而导致潜在的数据泄露。 正确识别和修正问题对于组织的整体安全态势和环境非常重要，这符合各种安全框架的最佳做法：例如 ISO 27001 和 PCI DSS。

• 示例证据指南： (提供合适的项目，即) 屏幕截图，显示漏洞扫描中发现的漏洞示例已根据上面控制 13 中提供的修补窗口进行修正。

• 示例证据：以下屏幕截图显示本示例中名为“THOR”的单个计算机 (范围内环境的 Nessus 扫描，) 显示 2021 年 8 月 2 日漏洞。

以下屏幕截图显示问题已解决，2 天后，该问题位于修补策略中定义的修补窗口中。

注意： 对于此控制，认证分析师需要查看过去 12 个月每个季度的漏洞扫描报告和修正。

防火墙

防火墙通常在受信任的 (内部网络) 、不受信任的 (Internet) 和半受信任的 (DMZ) 环境之间提供安全边界。 这些通常是组织深层防御安全策略中的第一道防线，旨在控制入口和出口服务的流量流，并阻止不需要的流量。 必须严格控制这些设备，以确保它们有效运行，并且没有可能使环境面临风险的错误配置。

控制 #18：提供控制防火墙管理做法和过程的策略文档。

• 意向：防火墙是分层安全的重要第一道防线， (深层防御) 策略，保护环境免受不太受信任的网络区域的侵害。 防火墙通常基于 IP 地址和协议/端口控制流量流，功能更丰富的防火墙还可以通过检查应用程序流量来提供额外的“应用程序层”防御，以防止基于所访问的应用程序的误用、漏洞和威胁。 这些保护仅与防火墙的配置一样好，因此需要制定强大的防火墙策略和支持过程，以确保将其配置为提供对内部资产的充分保护。 例如，具有允许从任何源发向 ANY 目标的所有流量的规则的防火墙只是充当路由器。

• 示例证据指南：提供完整的防火墙策略/过程支持文档。 本文档应涵盖以下所有要点以及适用于你的环境的任何其他最佳做法。

• 示例证据：下面是我们需要的防火墙策略文档类型的示例， (这是一个演示，) 可能不完整。

控制 #19：提供可证明的证据，证明在安装到生产环境之前，任何默认管理凭据都已更改。

• 意向：组织需要注意供应商提供的默认管理凭据，这些凭据是在配置设备或软件期间配置的。 默认凭据通常由供应商公开提供，可以为外部活动组提供破坏环境的机会。 例如，在 Internet 上简单搜索默认 iDrac (集成 Dell 远程访问控制器) 凭据会将 root：：calvin 突出显示为默认用户名和密码。 这将允许某人远程访问远程服务器管理。 此控制的目的是确保环境不会受到设备/应用程序强化期间未更改的默认供应商凭据的攻击。

• 示例证据指南

• 这可以通过屏幕共享会话来证明，认证分析师可以在该会话中尝试使用默认凭据向范围内的设备进行身份验证。

• 示例证据

以下屏幕截图显示了认证分析师从 WatchGuard 防火墙的无效用户名/密码中看到的内容。

控制 20：提供可证明的证据，证明防火墙安装在作用域内环境的边界上，并且安装在外围网络 (也称为 DMZ、隔离区域和屏蔽子网) 与内部受信任网络之间。

• 意向：防火墙提供控制不同安全级别的不同网络区域之间的流量的功能。 由于所有环境都已连接 Internet，因此需要在边界（即 Internet 和作用域内环境之间）上安装防火墙。 此外，需要在不太受信任的外围网络 (非军事化区域) 网络和内部受信任的网络之间安装防火墙。 外围网络通常用于处理来自 Internet 的流量，因此是攻击目标。 通过实现外围网络并使用防火墙来控制流量流，外围网络遭到入侵并不一定意味着内部受信任的网络和企业/客户数据遭到入侵。 应设置适当的日志记录和警报，以帮助组织快速识别入侵，以最大程度地减少活动组进一步破坏内部受信任网络的机会。 此控件的目的是确保受信任的网络和不太受信任的网络之间有足够的控制。

• 示例证据指南：应通过防火墙配置文件或屏幕截图提供证据，以证明 DMZ 已到位。 这应与提供的体系结构关系图相匹配，这些体系结构图演示了支持环境的不同网络。 防火墙上网络接口的屏幕截图，以及作为初始文档提交的一部分提供的网络关系图应提供此证据。

• 示例证据：下面是一个 WatchGuard 防火墙的屏幕截图，其中演示了两个外围网络，一个用于入站服务 (名为 DMZ) ，另一个用于为 Jumpbox (Bastian 主机) 服务。

控制 21：提供证明所有公共访问在外围网络) 的非军事区 (终止的证据。

• 意向：可公开访问的资源受到无数攻击。 如上所述，外围网络的目的是将不太受信任的网络与可能包含敏感数据的受信任内部网络进行分段。 外围网络被认为不太受信任，因为外部活动组无法公开访问的主机存在很大风险。 公共访问应始终在这些不太受信任的网络中终止，这些网络由防火墙充分分段，以帮助保护内部资源和数据。 此控制的目的是确保这些不太受信任的外围网络中的所有公共访问都终止，就像受信任的内部网络上的资源面向公共一样，这些资源的泄露为活动组提供一个位于其中保存敏感数据的网络的立足点。

• 示例证据指南

• 为此提供的证据可能是显示入站规则以及这些规则终止位置的防火墙配置，方法是将公共 IP 地址路由到资源，或者通过提供入站流量的 NAT (网络地址转换) 。

• 示例证据

在下面的屏幕截图中，有三个传入规则，每个规则显示 10.0.3.x 和 10.0.4.x 子网的 NAT，它们是外围网络子网

控制 22：提供可证明的证据，证明允许通过防火墙的所有流量都经过审批过程。

• 意向：由于防火墙是不受信任的流量与内部资源之间以及不同信任级别网络之间的防御屏障，因此需要安全地配置防火墙，并确保仅启用业务运营所需的流量。 通过允许不必要的流量流或过于宽松的流量流，可能会在这些不同网络区域的边界内引入防御漏洞。 通过为所有防火墙更改建立可靠的审批流程，可以降低引入给环境带来重大风险的规则的风险。 Verizon 的 2020 年数据泄露调查报告 强调，“错误”（包括错误配置）是唯一持续逐年增加的操作类型。

• 示例证据指南：证据可以采用文档的形式显示正在授权的防火墙更改请求，可以是从 CAB (更改顾问委员会会议) 几分钟，或者通过跟踪所有更改的更改控制系统。

• 示例证据：以下屏幕截图显示了使用基于纸张的过程请求和授权的防火墙规则更改。 例如，可以通过 DevOps 或 Jira 等实现此目的。

控制措施 23：提供可证明的证据，证明防火墙规则库配置为删除未显式定义的流量。

• 意向：大多数防火墙将采用自上而下的方法处理规则，以尝试查找匹配的规则。 如果规则匹配，则将应用该规则的操作，并停止对规则的所有进一步处理。 如果未找到匹配的规则，则默认情况下会拒绝流量。 此控件的意图是，如果防火墙在找不到匹配规则时不默认丢弃流量，则规则库必须在 “所有 防火墙列表”的末尾包含“全部拒绝”规则。 这是为了确保防火墙在处理规则时不会默认进入默认允许状态，从而允许尚未显式定义的流量。

• 示例证据准则：可以通过防火墙配置提供证据，或者通过显示所有防火墙规则的屏幕截图来提供证据，这些规则在末尾显示“全部拒绝”规则，或者如果防火墙丢弃了默认情况下与规则不匹配的流量，则提供所有防火墙规则的屏幕截图和供应商管理指南的链接，其中突出显示了默认情况下防火墙会丢弃所有不匹配的流量。

• 示例证据：下面是 WatchGuard 防火墙规则库的屏幕截图，其中演示了未配置允许所有流量的规则。 末尾没有拒绝规则，因为 WatchGuard 将丢弃默认情况下不匹配的流量。

以下 WatchGuard 帮助中心链接： https://www.watchguard.com/help/docs/help-center/en-US/Content/en-US/Fireware/policies/policies_about_c.html 包括以下信息：

控制措施 24：提供可证明的证据，证明防火墙仅支持所有非控制台管理接口上的强加密。

• 意向：为了缓解管理流量的中间人攻击，所有非控制台管理接口应仅支持强加密。 此控件的主要目的是在设置非控制台连接时保护管理凭据。 此外，这也有助于防止窃听到连接，尝试重播管理功能以重新配置设备或作为侦察的一部分。

• 示例证据指南：提供防火墙配置，如果配置提供非控制台管理接口的加密配置 (并非所有设备都会将此作为可配置选项包含在) 。 如果这不在配置中，则可以向设备发出命令，以显示为这些连接配置的内容。 某些供应商可能会在文章中发布此信息，因此这也可能是证明此信息的一种方式。 最后，可能需要运行工具来输出支持的加密。

• 示例证据：以下屏幕截图显示针对 TCP 端口 8080 上 WatchGuard 防火墙的 Web 管理界面的 SSLScan 输出。 这显示了最低加密密码为 AES-128 位的 TLS 1.2 或更高版本。

注意：WatchGuard 防火墙还支持使用 SSH (TCP 端口 4118) 和 WatchGuard System Manager (TCP 端口 4105 & 4117) 的管理功能。 还需要提供这些非控制台管理接口的证据。

控制措施 25：提供证明证据，证明你至少每 6 个月执行一次防火墙规则评审。

• 意向：随着时间推移，系统组件在范围内环境中存在配置爬行的风险。 这通常会导致不安全或错误配置，这会增加入侵环境的风险。 引入配置爬行的原因有很多，例如，临时更改有助于故障排除，临时功能更改的临时更改，引入问题快速修复，这些问题有时由于引入快速修复的压力而过于宽松。 例如，可以引入临时防火墙规则“全部允许”来克服紧急问题。 此控件的意图是双重的：一是确定哪里存在可能导致不安全的错误配置，其次，帮助识别不再需要因此可以删除的防火墙规则，即，如果服务已停用，但防火墙规则已被抛在后面。

• 示例证据指南：证据需要能够证明评审会议已发生。 这可以通过共享防火墙评审的会议记录和任何其他更改控制证据来完成，这些证据显示从评审中采取的任何操作。 确保日期存在，因为我们至少需要看到其中两次会议 (，即每六个月)

• 示例证据：以下屏幕截图显示了 2021 年 1 月进行的防火墙评审的证据。

以下屏幕截图显示了 2021 年 7 月进行的防火墙评审的证据。

防火墙 - WAF

可以选择将 Web 应用程序防火墙 (WAF) 部署到解决方案中。 如果使用 WAF，这将计为“操作安全”安全域中评分矩阵的额外积分。 WAF 可以检查 Web 流量，以筛选和监视 Internet 与已发布 Web 应用程序之间的 Web 流量，以识别特定于 Web 应用程序的攻击。 Web 应用程序可能遭受许多特定于 Web 应用程序的攻击，例如 SQL 注入 (SQLi) 、跨站点脚本 (XSS) 、跨站点请求伪造 (CSRF/XSRF) 等，WAF 旨在防范这些类型的恶意有效负载，以帮助保护 Web 应用程序免受攻击和潜在入侵。

控制 26：提供可证明的证据，证明 Web 应用程序防火墙 (WAF) 配置为主动监视、警报和阻止恶意流量。

• 意向：此控制措施已到位，用于确认 WAF 已为所有传入的 Web 连接就位，并且它配置为阻止恶意流量或发出警报。 若要为 Web 流量提供额外的防御层，需要为所有传入的 Web 连接配置 WAF，否则外部活动组可能会绕过旨在提供这一额外保护层的 WAF。 如果未将 WAF 配置为主动阻止恶意流量，则 WAF 需要能够立即向员工提供警报，以便快速应对潜在的恶意流量，以帮助维护环境的安全性并阻止攻击。

• 示例证据指南：提供来自 WAF 的配置输出，其中突出显示了正在处理的传入 Web 连接，并且配置会主动阻止恶意流量或正在监视和发出警报。 或者，可以共享特定设置的屏幕截图，以演示组织是否满足此控制要求。

• 示例证据：以下屏幕截图显示已启用 Contoso 生产 Azure 应用程序网关 WAF 策略，并且它已配置为“防护”模式，这将主动删除恶意流量。

以下屏幕截图显示了前端 IP 配置

注意： 证据应证明环境使用的所有公共 IP，以确保涵盖所有入口点，这就是为什么还包含此屏幕截图的原因。

以下屏幕截图显示了使用此 WAF 的传入 Web 连接。

以下屏幕截图显示用于 api.contoso.com 服务的Contoso_AppGW_CoreRules。

控制 27：提供 WAF 支持 SSL 卸载的可证明证据。

• 意向：将 WAF 配置为支持 SSL 卸载的功能非常重要，否则 WAF 将无法检查 HTTPS 流量。 由于这些环境需要支持 HTTPS 流量，因此这是 WAF 的一项关键功能，可确保 HTTPS 流量中的恶意有效负载能够被识别和停止。

• 示例证据指南：通过配置导出或显示支持和配置 SSL 卸载的屏幕截图提供配置证据。

• 示例证据：在 Azure 应用程序网关中，配置启用了 SSL 侦听器的 SSL 卸载，请参阅 概述使用应用程序网关的 TLS 终止和端到端 TLS Microsoft Docs 页。 以下屏幕截图显示了为 Contoso 生产 Azure 应用程序网关配置的此配置。

控制 28：根据 OWASP 核心规则集 (3.0 或 3.1) ，提供可证明的证据证明 WAF 可防范以下部分或全部漏洞：

• 协议和编码问题，

• 标头注入、请求走私和响应拆分，

• 文件和路径遍历攻击，

• 远程文件包含 (RFI) 攻击，

• 远程代码执行攻击，

• PHP 注入攻击，

• 跨站点脚本攻击，

• SQL 注入攻击，

• 会话固定攻击。

• 意向：需要配置 WAF 以识别常见漏洞类的攻击有效负载。 此控件旨在确保通过利用 OWASP 核心规则集来涵盖漏洞类的充分检测。

• 示例证据指南：通过配置导出或屏幕截图提供配置证据，表明扫描已涵盖上述大多数漏洞类。

• 示例证据：以下屏幕截图显示，Contoso 生产 Azure 应用程序网关 WAF 策略配置为针对 OWASP 核心规则集版本 3.2 进行扫描。

更改控件

建立和理解的变更控制过程对于确保所有更改都经过可重复的结构化过程至关重要。 通过确保所有更改都通过结构化过程，组织可以确保在签署之前有效地管理更改、同行评审和充分测试更改。 这不仅有助于最大程度地降低系统中断的风险，还有助于通过引入不当更改将潜在安全事件的风险降到最低。

控制措施 29：提供控制更改控制过程的策略文档。

• 意向：为了维护安全的环境和安全的应用程序，必须建立可靠的变更控制过程，以确保所有基础结构和代码更改都通过强大的监督和定义的流程来执行。 这可确保记录更改、考虑安全隐患、考虑更改将产生哪些安全影响等。目的是确保记录更改控制过程，以确保对环境和应用程序开发实践中的所有更改采用安全一致的方法。

• 示例证据指南：记录的变更控制策略/过程应与认证分析师共享。

• 示例证据：下面显示了更改管理策略示例的开头。 请在评估过程中提供完整的策略和过程。

注意： 此屏幕截图显示了策略/流程文档，ISV 希望共享实际的支持策略/过程文档，而不只是提供屏幕截图。

控制措施 30：提供可证明的证据，证明开发和测试环境强制将职责与生产环境分离。

• 意向：大多数组织的开发/测试环境未配置为与生产环境相同的活力，因此安全性较低。 此外，不应在生产环境中执行测试，因为这样做可能会带来安全问题，或者可能会损害客户的服务交付。 通过维护强制职责分离的单独环境，组织可以确保将更改应用于正确的环境，从而通过在开发/测试环境中实施生产环境更改来降低错误风险。

• 示例证据指南：可以提供屏幕截图，其中演示了用于开发/测试环境和生产环境的不同环境。 通常，你会有不同的人员/团队有权访问每个环境，或者如果这是不可能的，这些环境会利用不同的授权服务来确保用户不会错误地登录到错误的环境来应用更改。

• 示例证据：以下屏幕截图显示了 Contoso 测试环境的 Azure 订阅。

下一个屏幕截图显示了 Contoso 的“生产”环境的单独 Azure 订阅。

控制措施 31：提供可证明的证据，证明开发或测试环境中不使用敏感生产数据。

• 意向：如上所述，组织不会以与生产环境相同的活力来实施开发/测试环境的安全措施。 因此，在这些开发/测试环境中利用敏感的生产数据会增加泄露的风险，并且必须避免在这些开发/测试环境中使用实时/敏感数据。

注意： 可以在开发/测试环境中使用实时数据，前提是开发/测试包含在评估范围内，以便可以根据Microsoft 365 认证控制措施评估安全性。

• 示例证据指南：可以通过对生产数据库共享同一 SQL 查询输出的屏幕截图来提供证据， (修订) 和开发/测试数据库的任何敏感信息。 相同命令的输出应生成不同的数据集。 在存储文件的位置，在两个环境中查看文件夹的内容还应演示不同的数据集。

• 示例证据：以下屏幕截图显示提交证据 (前 3 条记录，请提供生产数据库中的前 20 条) 。

下一个屏幕截图显示了开发数据库中的相同查询，其中显示了不同的记录。

这表明数据集是不同的。

控制措施 32：提供可证明的证据，证明记录的更改请求包含更改的影响、回退过程的详细信息以及要执行的测试的详细信息。

• 意向：此控件的意图是确保思想已进入所请求的更改中。 需要考虑更改对系统/环境安全性的影响并明确记录，任何回退过程都需要记录，以帮助在出现问题时进行恢复，最后还需要考虑和记录验证更改是否成功所需的测试详细信息。

• 示例证据指南：可以通过导出更改请求示例、提供书面更改请求或提供更改请求的屏幕截图来提供证据，其中显示了更改请求中保留的这三个详细信息。

• 示例证据：下图显示了一个新的跨站点脚本漏洞 (XSS) 分配，并记录了更改请求。

以下票证显示已设置或添加到票证的过程中要解决的信息。

下面的两个票证显示了更改对系统的影响，以及出现问题时可能需要的任何回退过程。 可以看到更改的影响，退出过程已完成审批过程，并已批准进行测试。

在屏幕左侧，可以看到测试更改已获批准，在右侧，可以看到更改现已获得批准和测试。

在整个过程中，请注意，执行工作的人员、报告工作的人员以及批准要完成的工作的人员是不同的人。

上面的票证显示，现在已批准对生产环境实施更改。 右侧框显示测试正常工作且成功，并且现已对 Prod 环境实施更改。

控制措施 33：提供可证明的证据，证明更改请求经过授权和注销过程。

• 意向：必须实现禁止在没有适当授权的情况下进行更改和注销的过程。在实施更改之前，需要对更改进行授权，并且需要在完成更改后进行签名。 这可确保已正确审查更改请求，并且授权人员已签署更改。

• 示例证据准则：可以通过导出更改请求示例、提供书面更改请求或提供更改请求的屏幕截图来提供证据，其中显示更改在实施之前已授权，并且更改在完成后已签名。

• 示例证据：以下屏幕截图显示了一个示例 Jira 票证，显示更改需要经过授权，然后才能由开发人员/请求者以外的人员实施和批准。 可以看到此处的更改已获得授权人员批准。 右侧已由 DP 在完成后签名。

在下面的票证中，可以看到更改在完成后已签名，并显示作业已完成和关闭。

保护软件开发/部署

参与软件开发活动的组织通常面临安全性与 TTM (上市时间) 压力之间的竞争优先级，但是，在整个软件开发生命周期中实施安全相关活动 (SDLC) 不仅可以节省资金，还可以节省时间。 如果事后才考虑安全性，通常仅在 (DSLC) 的测试阶段确定问题，修复这些问题通常更耗时且成本更高。 此安全部分的目的是确保遵循安全软件开发做法，以降低在开发的软件中引入编码缺陷的风险。 此外，本部分还包含一些控制措施，以帮助安全部署软件。

控制 34：提供支持安全软件开发和部署的策略和过程，包括针对常见漏洞类（例如 OWASP 前 10 或 SANS 前 25 CWE）的安全编码最佳做法指南。

• 意向：组织需要尽其所能，确保软件安全开发并无漏洞。 为了实现这一目标，应建立可靠的安全软件开发生命周期 (SDLC) 和安全编码最佳做法，以在整个软件开发过程中促进安全编码技术和安全开发。 目的是减少软件中漏洞的数量和严重性。

• 示例证据指南：提供记录的 SDLC 和/或支持文档，这些文档演示了安全开发生命周期正在使用中，并且为所有开发人员提供了该指南，以推广安全编码最佳做法。 查看 SDLC 中的 OWASP 和 OWASP 软件保障成熟度模型 (SAMM) 。

• 示例证据：以下是 Contoso 的安全软件开发过程摘录，其中演示了安全开发和编码做法。

注意： 这些屏幕截图显示安全软件开发文档，期望 ISV 共享实际支持文档，而不只是提供屏幕截图。

控制措施 35：提供证明代码更改经过第二个审阅者的评审和授权过程的证据。

• 意向：使用此控件的意图是由另一个开发人员执行代码评审，以帮助识别任何可能引入软件漏洞的编码错误。 应建立授权，以确保进行代码评审、完成测试等。 部署之前。 授权步骤可以验证是否遵循了正确的流程，这支撑了上面定义的 SDLC。

• 示例证据指南：提供代码经过同行评审的证据，并且必须先获得授权，然后才能将其应用于生产环境。 此证据可能通过导出更改票证，证明代码评审已进行且已授权更改，也可以通过代码评审软件（如 Crucible (https://www.atlassian.com/software/crucible) ）。

• 示例证据

下面是一个票证，显示代码更改由原始开发人员以外的人员进行评审和授权过程。 它表明，受让人已请求代码评审，并将分配给其他人进行代码评审。

下图显示代码评审已分配给原始开发人员以外的人员，如下图所示，突出显示部分如下图所示。 在左侧，可以看到代码审阅者已评审代码，并提供了“已通过代码审阅”状态。

现在，票证必须获得经理的批准，然后才能将更改放入实时生产系统。

上图显示已批准在实时生产系统上实施评审的代码。

代码更改完成后，最终作业将注销，如上图所示。

请注意，在整个过程中，有三个人参与，代码的原始开发人员，代码审阅者和经理给予批准和注销。为了满足此控件的条件，预期票证将遵循此过程。 至少 3 人参与代码评审的更改控制过程。

控制 36：提供开发人员每年接受安全软件开发培训的可证明证据。

• 意向：所有编程语言都存在编码最佳做法和技术，以确保安全地开发代码。 有一些外部培训课程旨在教开发人员不同类型的软件漏洞课程和可用于停止将这些漏洞引入软件的编码技术。 此控件的目的是向所有开发人员教授这些技术，并确保这些技术不会被遗忘，或者通过每年执行这些技术来学习较新的技术。

• 示例证据指南：如果由外部培训公司执行，则通过证书提供证据，或者通过提供培训日记或其他显示开发人员已参加培训的项目的屏幕截图来提供证据。 如果此培训是通过内部资源进行的，则还要提供培训材料的证据。

• 示例证据：下面是要求 DevOps 团队中员工注册到 OWASP 十大培训年度培训的电子邮件

下面显示了已请求培训并说明业务理由和批准。 然后，从训练中获取的屏幕截图和显示该人员已完成年度培训的完成记录。

控制 37：提供可证明的证据，证明代码存储库使用多重身份验证 (MFA) 进行保护。

• 意向：如果活动组可以访问和修改软件的代码库，他/她可能会将漏洞、后门或恶意代码引入代码库，从而引入应用程序。 已经发生了几个这种情况，其中最公开的可能是 NotPetya 勒索软件攻击，据报道，该攻击是通过乌克兰税务软件的入侵更新感染的，称为 M.E.Doc (请参阅 什么是Petya) 。

• 示例证据指南：通过代码存储库中 所有用户已启用 MFA 的屏幕截图提供证据。

• 示例证据：以下屏幕截图显示已对所有 8 个 GitLab 用户启用 MFA。

控制措施 38：提供证明，证明访问控制已到位，以保护代码存储库。

• 意向：从上一个控件开始，应实现访问控制，以将访问权限限制为仅处理特定项目的单个用户。 通过限制访问，可以限制执行未经授权的更改的风险，从而引入不安全的代码更改。 应采取最低特权方法来保护代码存储库。

• 示例证据准则：通过代码存储库中的屏幕截图提供证据，这些屏幕截图显示访问权限仅限于所需的个人，包括不同的权限。

• 示例证据：以下屏幕截图显示了 GitLab 中“客户”项目的成员，即 Contoso“客户门户”。 如屏幕截图所示，用户具有不同的“角色”来限制对项目的访问权限。

帐户管理

安全帐户管理做法非常重要，因为用户帐户是允许访问信息系统、系统环境和数据的基础。 用户帐户需要得到适当的保护，因为用户凭据的泄露不仅可以提供进入环境的立足点和对敏感数据的访问权限，还可以在用户的凭据具有管理权限时提供对整个环境或密钥系统的管理控制。

控制措施 39：提供控制帐户管理做法和过程的策略文档。

• 意向：用户帐户继续成为活动组的目标，并且通常是数据泄露的来源。 通过配置过度宽松的帐户，组织不仅会增加活动组可用于执行数据泄露的“特权”帐户池，而且还会增加成功利用需要特定特权才能成功利用的漏洞的风险。

• BeyondTrust 每年会生成一份“Microsoft漏洞报告”，其中分析前一年的Microsoft安全漏洞，并详细说明依赖具有管理员权限的用户帐户的这些漏洞的百分比。 在最近的博客文章“新的Microsoft漏洞报告显示漏洞 & 如何使用最低特权缓解漏洞的同比增加 48%”中，Internet Explorer 中 90% 的关键漏洞、Microsoft Edge 中 85% 的关键漏洞和 Microsoft Outlook 中 100% 的关键漏洞将通过删除管理员权限得到缓解。 为了支持安全帐户管理，组织需要确保制定并遵循促进安全最佳做法的支持策略和过程，以缓解这些威胁。

• 示例证据指南：提供涵盖帐户管理做法的有文档记录的策略和过程文档。 涵盖的主题至少应与 Microsoft 365 认证中的控制一致。

• 示例证据：以下屏幕截图显示了 Contoso 的帐户管理策略示例。

注意： 此屏幕截图显示了策略/流程文档，ISV 希望共享实际的支持策略/过程文档，而不只是提供屏幕截图。

控制措施 40：提供可证明的证据，证明已跨抽样系统组件禁用、删除或更改默认凭据。

• 意向：尽管这越来越不受欢迎，但仍有一些情况，活动组可以利用默认和记录良好的用户凭据来破坏生产系统组件。 一个常用示例是使用 Dell iDRAC (集成的 Dell 远程访问控制器) 。 此系统可用于远程管理 Dell Server，活动组可以使用该服务器来控制服务器的操作系统。 记录了 root：：calvin 的默认凭据，活动组通常可以使用该凭据来访问组织使用的系统。 此控件的目的是确保禁用或删除这些默认凭据

• 示例证据指南：可通过多种方式收集证据来支持此控制。 跨所有系统组件配置的用户的屏幕截图会有所帮助，即 Linux /etc/shadow 和 /etc/passwd 文件的屏幕截图有助于演示帐户是否已禁用。 请注意，通过观察密码哈希以无效字符（如“！”）开头表示密码不可用，需要 /etc/shadow 文件来证明帐户被真正禁用。 建议是仅禁用密码的几个字符，并编辑其余字符。 其他选项包括屏幕共享会话，其中评估程序能够手动尝试默认凭据，例如，在上述关于 Dell iDRAC 的讨论中，评估者需要尝试使用默认凭据对所有 Dell iDRAC 接口进行身份验证。

• 示例证据：以下屏幕截图显示为作用域内系统组件“CLARANET-SBU-WM”配置的用户帐户。 显示多个默认帐户;但是，管理员、DefaultAccount 和 Guest，以下屏幕截图显示这些帐户已被禁用。

下一个屏幕截图显示管理员帐户在范围内系统组件“CLARANET-SBU-WM”上被禁用。

下一个屏幕截图显示了在范围内系统组件“CLARANET-SBU-WM”上禁用了来宾帐户。

下一个屏幕截图显示，在作用域内系统组件“CLARANET-SBU-WM”上禁用了 DefaultAccount。

控制 41：提供可证明的证据，证明帐户创建、修改和删除需要经过既定的审批过程。

• 意向：目的是建立一个已建立的过程，以确保所有帐户管理活动都得到批准，确保帐户特权保持最低特权原则，并且可以正确审查和跟踪帐户管理活动。

• 示例证据指南：证据通常采用更改请求票证的形式，ITSM (IT 服务管理) 请求或文件，其中显示创建、修改或删除帐户的请求已经过审批过程。

• 示例证据：下图显示了为 DevOps 团队的新初学者创建的帐户，该团队需要基于生产环境权限拥有基于角色的访问控制设置，而无权访问开发环境，并且对其他所有内容具有标准非特权访问权限。

创建帐户并关闭票证后，帐户创建已完成审批过程和注销过程。

控制措施 42：提供可证明的证据，证明有一个流程已到位，以禁用或删除 3 个月内未使用的帐户。

• 意向：非活动帐户有时可能会泄露，因为它们是暴力攻击的目标，这些攻击可能不会标记为用户不会尝试登录帐户，或者由于密码数据库泄露而泄露，其中用户的密码已重复使用，并在 Internet 上的用户名/密码转储中可用。 应禁用/删除未使用的帐户，以减少活动组必须执行帐户泄露活动的攻击面。 这些账户可能是由于休假程序执行不当、长期生病的工作人员或正在休产假/陪产假的工作人员。 通过实施季度流程来识别这些帐户，组织可以最大程度地减少攻击面。

• 示例证据指南：证据应为两倍。 首先，显示范围内环境中所有用户帐户的“上次登录”的屏幕截图或文件导出。 这可能是本地帐户以及集中式目录服务中的帐户，例如Microsoft Entra ID。 这将表明未启用任何超过 3 个月的帐户。 其次，季度审查过程的证据，可能是 ADO (Azure DevOps) 或 JIRA 票证中完成任务的文档证据，或者通过应签署的书面记录。

• 示例证据：此第一个屏幕截图显示了脚本的输出，该脚本按季度执行一次，以查看 Microsoft Entra ID 中的用户的最后登录属性。

如上面的屏幕截图所示，两个用户显示为一段时间未登录。 以下两个屏幕截图显示这两个用户已被禁用。

控制措施 43：提供可证明的证据，证明强密码策略或其他适当的缓解措施已到位，以保护用户凭据。 应将以下内容用作最低准则：

• 最小密码长度为 8 个字符

• 尝试次数不超过 10 次的帐户锁定阈值

• 至少 5 个密码的密码历史记录

• 强制使用强密码

• 意向：如前所述，用户凭据通常是尝试访问组织环境的活动组的攻击目标。 强密码策略的意图是尝试强制用户选择强密码，以降低活动组能够暴力破解这些密码的可能性。 添加“或其他适当的缓解措施”的意图是认识到组织可以实施其他安全措施，以帮助保护基于行业发展的用户凭据，例如“NIST 特别出版物 800-63B”。

• 示例证据指南：用于演示强密码策略的证据可能采用组织组策略对象或本地安全策略“帐户策略-密码策略”和“帐户策略-帐户锁定策略”设置的屏幕截图形式。 证据取决于所使用的技术：也就是说，对于 Linux，它可以是 /etc/pam.d/common-password 配置文件，对于 BitBucket 管理门户中的“身份验证策略”部分， (https://support.atlassian.com/security-and-access-policies/docs/manage-your-password-policy/) 等。

• 示例证据：以下证据显示了在范围内系统组件“CLARANET-SBU-WM”的“本地安全策略”内配置的密码策略。

下面的屏幕截图显示了 WatchGuard 防火墙的帐户锁定设置。

下面是 WatchGaurd 防火墙的最小密码长度示例。

控制措施 44：提供向所有用户颁发唯一用户帐户的演示证据。

• 意向：此控制的意图是问责。 通过向用户颁发其自己的唯一用户帐户，用户将对其操作负责，因为用户活动可以跟踪给单个用户。

• 示例证据指南：证据将通过屏幕截图显示跨范围内系统组件配置的用户帐户，这些组件可能包括服务器、代码存储库、云管理平台、Active Directory、防火墙等。

• 示例证据：以下屏幕截图显示为作用域内系统组件“CLARANET-SBU-WM”配置的用户帐户。

下一个屏幕截图显示管理员帐户在范围内系统组件“CLARANET-SBU-WM”上被禁用。

下一个屏幕截图显示了在范围内系统组件“CLARANET-SBU-WM”上禁用了来宾帐户。

下一个屏幕截图显示，在作用域内系统组件“CLARANET-SBU-WM”上禁用了 DefaultAccount。

控制措施 45：提供在环境中遵循最低特权原则的可证明证据。

• 意向：应仅向用户提供完成其工作职能所需的权限。 这是为了限制用户有意或无意访问不应的数据或实施恶意行为的风险。通过遵循此原则，它还可减少潜在的攻击面 (即特权帐户) 可能成为恶意活动组的目标。

• 示例证据准则：大多数组织将利用组基于组织内的团队分配权限。 证据可以是显示各种特权组的屏幕截图，并且仅显示需要这些特权的团队的用户帐户。 通常，这将通过支持策略/流程进行备份，这些策略/流程定义每个定义的组以及所需的权限和业务理由，以及用于验证组成员身份是否正确配置的团队成员层次结构。

• 例如：在 Azure 中，“所有者”组应受到限制，因此应记录这一点，并且应有有限数量的人员分配到该组。 另一个示例可能是能够进行代码更改的有限数量的员工，可能设置具有此权限的组，其成员认为需要配置此权限。 这应该记录在内，以便认证分析师可以将文档与配置的组等交叉引用。

• 示例证据：以下屏幕截图显示环境配置了根据作业功能分配的组。

以下屏幕截图显示根据用户的工作职能将用户分配到组。

控制措施 46：提供可证明的证据，证明某个流程已到位来保护或强化服务帐户，并且正在遵循该过程。

• 意向：服务帐户通常成为活动组的目标，因为它们通常配置为提升的权限。 这些帐户可能不遵循标准密码策略，因为服务帐户密码过期通常会中断功能。 因此，可以使用弱密码或组织内重复使用的密码来配置它们。 另一个潜在问题（特别是在 Windows 环境中）可能是操作系统缓存密码哈希。 如果以下两种情况之一是：服务帐户是在目录服务中配置的，因为此帐户可用于跨具有配置特权级别的多个系统的访问权限，或者服务帐户是本地的，则很可能在环境中的多个系统中使用相同的帐户/密码。 上述问题可能导致活动组访问环境中的更多系统，并可能导致特权和/或横向移动的进一步提升。 因此，目的是确保服务帐户得到适当的强化和保护，以帮助防止它们被活动组接管，或者通过限制其中一个服务帐户泄露的风险。

• 示例证据指南：Internet 上有许多帮助强化服务帐户的指南。 证据可以采用屏幕截图的形式，这些屏幕截图演示了组织如何实现帐户的安全强化。 (预期使用的一些示例是，) 会使用多种技术，其中包括：

• 将帐户限制为 Active Directory 中的一组计算机，

• 将帐户设置为不允许进行交互式登录，

• 设置极其复杂的密码，

• 对于 Active Directory，请启用“帐户敏感且无法委派”标志。 以下文章“持卡人数据环境的分段和共享 Active Directory”中讨论了这些技术。

• 示例证据：有多种方法可以强化服务帐户，这些帐户将依赖于每个单独的环境。 适用于你的环境的机制将记录在帐户管理策略/过程文档的前面，这将有助于查看此证据。 下面是一些可能采用的机制：

以下屏幕截图显示了在服务帐户“_Prod SQL 服务帐户”上选择了“帐户敏感且连接已委派”选项。

下一个屏幕截图显示服务帐户“_Prod SQL 服务帐户”已锁定到 SQL Server，并且只能登录该服务器。

下一个屏幕截图显示，仅允许服务帐户“_Prod SQL 服务帐户”作为服务登录。

控制 47：提供可证明的证据，证明 MFA 已为所有远程访问连接和所有非控制台管理接口配置。

定义为：

• 远程访问 - 通常，这是指用于访问支持环境的技术。 例如，远程访问 IPSec VPN、SSL VPN 或 Jumpbox/Bastian 主机。

• 非控制台管理接口 - 通常，这是指通过网络管理连接到系统组件。 这可以通过远程桌面、SSH 或 Web 界面进行。

• 意向：此控制的目的是提供缓解措施，防止暴力强制使用特权帐户和具有安全访问环境的帐户。 通过 (MFA) 提供多重身份验证，仍应保护已泄露的密码，防止成功登录，因为仍应保护 MFA 机制。 这有助于确保所有访问和管理操作仅由授权和受信任的员工执行。

• 示例证据指南：证据需要显示在适合上述类别的所有技术上都启用了 MFA。 这可能是通过显示系统级别启用了 MFA 的屏幕截图实现的。 根据系统级别，我们需要证明它已为所有用户启用，而不仅仅是启用了 MFA 的帐户示例。 如果技术被退到 MFA 解决方案，我们需要证据来证明它已启用和正在使用中。 这意味着：如果为 Radius 身份验证设置了技术（指向 MFA 提供程序），则还需要证明它指向的 Radius Server 是 MFA 解决方案，并且帐户已配置为利用它。

• 示例证据 1：以下屏幕截图显示了在 Pulse Secure 上配置的身份验证领域，该领域用于远程访问环境。 身份验证由用于 MFA 支持的 Duo SaaS 服务提供支持。

此屏幕截图演示了其他身份验证服务器，该服务器指向“Duo - Default Route”身份验证领域的“Duo-LDAP”。

此最终屏幕截图显示了 Duo-LDAP 身份验证服务器的配置，该服务器演示了它指向用于 MFA 的 Duo SaaS 服务。

示例证据 2：以下屏幕截图显示所有 Azure 用户都启用了 MFA。

注意： 需要为所有非主机连接提供证据，以证明已为其启用 MFA。 因此，例如，如果 RDP 或 SSH 连接到服务器或其他系统组件， (即防火墙) 。

控制 48：提供可证明的证据，证明已为所有远程访问连接和所有非控制台管理接口配置强加密，包括访问任何代码存储库和云管理接口。

定义为：

• 代码存储库 - 需要保护应用的代码库免受恶意修改的影响，这些修改可能会将恶意软件引入应用。 需要在代码存储库上配置 MFA。

• 云管理接口 – 其中部分或所有环境托管在云服务提供商 (CSP) 中，此处包含云管理管理界面。

• 意向：此控制的目的是确保所有管理流量都经过适当加密，以防止中间人攻击。

• 示例证据指南：可以通过屏幕截图提供证据，其中显示了远程访问技术、RDP、SSH 和 Web 管理界面的加密设置。 对于 Web 管理员接口，Qualys SSL 实验室扫描程序 (（如果可公开访问），即可以使用云管理接口、SaaS 代码存储库或 SSL VPN 连接) 。

• 示例证据：以下证据显示了“Webserver01”上的 RDP 加密级别配置了“高级”设置。 如帮助文本所示，这是使用强 128 位加密 (这是Microsoft Windows RDP 的最高级别。

以下证据还表明，RDP 传输安全性配置为在“Webserver01” (使用 TLS 1.0，这是 Windows Server) 的最高值。

控制 49：提供可证明的证据，证明 MFA 用于保护用于管理和维护所有公共域名服务 (DNS) 记录的管理门户。

• 意向：如果恶意活动组可以访问公共 DNS 记录，则存在一种风险，即他们能够修改应用使用的 URL，或者清单文件指向引入恶意代码或将用户流量定向到执行组件控制下的终结点。 这可能会导致用户数据丢失或整个应用的用户群的恶意软件/勒索软件感染。

• 示例证据指南：提供证明公共 DNS 管理门户受 MFA 保护的证据。 即使公共 DNS 托管在作用域内环境 (即由组织) 控制和操作的服务器上，也可能在某个注册域名的位置存在管理门户，并且 DNS 记录是“托管的”，以将 DNS 服务器指向你自己的基础结构。 在这种情况下，如果域 DNS 记录可以修改，则应在域注册机构管理接口上启用 MFA。 应提供一个屏幕截图，显示系统级别为 MFA 启用了管理界面， (即所有特权帐户) 。

• 示例证据：以下屏幕截图显示 contoso.com DNS 在 Microsoft Azure for Contoso Corporation 中进行管理。

注意： IP 地址是专用 RFC 1918 地址，未公开路由。 这只是为了演示目的。

以下屏幕截图显示所有 Azure 用户都启用了 MFA。

入侵检测和防护 (可选)

网关上的入侵检测和防护系统 (IDPS) 可以提供额外的一层保护，以抵御无数基于 Internet 和内部的威胁。 这些系统有助于防止这些威胁成功，并提供重要的警报功能，提醒组织进行入侵尝试，使组织能够实施其他防御策略，以进一步保护环境免受这些活动威胁的侵害。

此部分用于额外额度，因此是可选的。 这不是一个要求，但是，如果你完成它，你的评估将更全面地显示你的环境以及你已实施的控制和标准。

控制 50：提供可证明的证据，证明入侵检测和防护系统 (IDPS) 部署在作用域内环境的外围。

• 意向：尽管一些来源将内部威胁描述为现在已超过外部活动组的威胁，但内部威胁也包括疏忽，人为错误逐年增加。 在) 范围内环境外围安装 IDPS (的意图是，由于这些类型威胁使用的性质和技术，通常可以通过 IDPS 机制检测到外部威胁。

• 示例证据指南：应提供证明 IDPS 安装在外围的证据，如果运行 NextGen 防火墙，则可以直接安装在防火墙上，也可以通过部署 IDPS 传感器（在镜像交换机端口上配置）来确保部署的传感器看到所有流量。 如果使用 IDPS 传感器，则可能需要提供其他证据来证明传感器能够查看所有外部流量流。

• 示例证据：以下屏幕截图显示了在 WatchGuard 防火墙上启用了 IDPS 功能。

下面的附加屏幕截图演示了对 WatchGuard 防火墙配置中的所有规则启用了 IDPS。

控制 51：提供可证明的证据，证明 IDPS 签名在) 24 小时内保持当前 (。

• 意向：IDPS 有多种操作模式，最常见的是使用签名来识别攻击流量。 随着攻击的演变和新漏洞的识别，IDPS 签名必须保持最新状态，以提供足够的保护。 此控件的目的是确保 IDPS 得到维护。

• 示例证据指南：证据可能带有屏幕截图，显示 IDPS 配置为至少每天更新签名，并显示上次更新。

• 示例证据：虽然此屏幕截图未显示 IDPS 签名在过去 24 小时内已更新，但它确实演示已安装最新版本，该版本是从一周前 (5 月) 18__th 收集的证据。 这与下面的屏幕截图相结合，显示签名将在 24 小时内是最新的。

控制 52：提供可证明的证据，证明 IDPS 配置为支持所有传入 Web 流量的 TLS 检查。

• 意向：由于 IDPS 依赖于签名，因此它需要能够检查所有流量流以识别攻击流量。 TLS 流量已加密，因此 IDPS 无法正确检查流量。 这对于 HTTPS 流量至关重要，因为 Web 服务存在大量常见的威胁。 此控制的目的是确保还可以检查 IDPS 的加密流量流。

• 示例证据指南：应通过屏幕截图提供证据，证明 IDPS 解决方案也正在检查加密的 TLS 流量。

• 示例证据：此屏幕截图显示防火墙上的 HTTPS 规则

下一个屏幕截图显示已对这些规则启用了 IDPS。

以下屏幕截图显示了“代理操作”应用于“Inbound_Bot_Traffic”规则，该规则用于启用内容检查。

以下屏幕截图显示已启用内容检查。

控制 53：提供可证明的证据，证明 IDPS 已配置为监视所有入站流量流。

• 意向：如前所述，所有入站流量流都由 IDPS 监视，以识别任何形式的攻击流量，这一点很重要。

• 示例证据指南：应通过屏幕截图提供证据，以证明监视所有入站流量流。 这可以使用 NextGen 防火墙，显示已为 IDPS 启用所有传入规则，也可以通过使用 IDPS 传感器并演示所有流量都配置为到达 IDPS 传感器的方式。

• 示例证据：此屏幕截图显示，IDPS 已在 WatchGuard 防火墙的所有规则 (策略) 配置。

控制 54：提供可证明的证据，证明 IDPS 已配置为监视所有出站流量流。

• 意向：如前所述，所有出站流量流都由 IDPS 监视，以识别任何形式的攻击流量，这一点很重要。 某些 IDPS 系统还可以通过监视所有出站流量来识别潜在的内部违规行为。 这可以通过标识发往“命令和控制”终结点的流量来完成。

• 示例证据指南：应通过屏幕截图提供证据，以证明监视所有出站流量流。 这可以使用 NextGen 防火墙，显示已为 IDPS 启用所有传出规则，也可以通过使用 IDPS 传感器并演示所有流量都配置为到达 IDPS 传感器的方式。

• 示例证据：此屏幕截图显示，IDPS 已在 WatchGuard 防火墙的所有规则 (策略) 配置。

• 示例证据 2：Azure 通过第三方应用提供 IDPS。 在下面的示例中，Netwatcher 数据包捕获已用于捕获数据包，并与 Suricata 一起使用，后者是一个 Open-Source IDS 工具。

结合网络观察程序提供的数据包捕获和 Suricata 等开源 IDS 工具，可以针对各种威胁执行网络入侵检测。 下图显示了 Suricata 接口。

签名用于触发警报，可以轻松安装和更新这些警报。 下图显示了一些签名的快照。

下图显示了如何使用 Sentinel SIEM/SOAR 监视 Netwatcher 和 Suricata 第三方软件的 IDPS 设置。

• 示例证据 3：下图显示了如何使用 CLI 为入侵检测添加替代入侵签名或绕过规则

下图显示了如何使用 CLI 列出所有入侵检测配置

• 示例证据 4：Azure 最近开始提供名为 Azure 防火墙高级版的 IDPS，这将允许通过策略配置 TLS、威胁情报、IDPS，但请注意，仍需要使用 Front Door 或应用程序网关对入站流量进行 SSL 卸载，因为 Azure 防火墙高级版不支持入站 SSL 连接上的 IDPS。

在下面的示例中，默认高级设置已用于配置策略规则和 TLS 检查、IDPS 模式、威胁智能以及 Vnet 保护。

安全事件日志记录

安全事件日志记录是组织安全计划不可或缺的一部分。 充分记录安全事件，加上经过优化的警报和审查流程，可帮助组织识别组织可用于增强安全和防御性安全策略的违规或企图的违规行为。 此外，适当的日志记录将有助于组织的事件响应能力，这些功能可以馈入其他活动，例如能够准确识别哪些和谁的数据遭到入侵、泄露的时间段、向政府机构提供详细的分析报告等。

控制措施 55：提供策略文档，了解管理安全事件日志记录的最佳做法和过程。

• 意向：安全事件日志记录是任何组织安全计划的一项重要功能。 必须制定策略和过程以提供清晰度和一致性，以帮助确保组织按照供应商和行业建议的做法实施日志记录控制。 这将有助于确保使用相关和详细的日志，这些日志不仅有助于识别潜在或实际的安全事件，而且还可以帮助事件响应活动识别安全漏洞的程度。

• 示例证据指南：提供组织记录的策略和过程文档，涵盖安全事件日志记录最佳做法。

• 示例证据：下面是日志记录策略/过程的摘录。

注意： 此屏幕截图显示了策略/流程文档，ISV 希望共享实际的支持策略/过程文档，而不只是提供屏幕截图。

控制 56：提供演示性证据，显示已跨所有采样系统组件设置了安全事件日志记录，以记录以下事件：

• 用户对系统组件和应用程序的访问权限

• 高特权用户执行的所有操作

• 无效的逻辑访问尝试

• 特权帐户创建或修改

• 事件日志篡改

• 禁用安全工具，例如反恶意软件或事件日志记录

• 反恶意软件日志记录，例如更新、恶意软件检测和扫描失败

• IDPS 和 WAF 事件（如果已配置）

• 意向：若要识别尝试的和实际的违规行为，组成环境的所有系统必须收集足够的安全事件日志。 此控件的目的是确保捕获正确类型的安全事件，然后这些事件可以馈入评审和警报过程，以帮助识别和响应这些事件。

• 示例证据指南：应在所有采样设备和任何相关的系统组件上通过屏幕截图或配置设置提供证据，以演示如何配置日志记录，以确保捕获这些类型的安全事件。

• 示例证据 1：以下屏幕截图显示了名为“VICTIM1-WINDOWS”的采样设备之一的配置设置。 设置显示“本地安全策略  本地策略  审核策略” 设置中启用的各种审核设置。

下一个屏幕截图显示用户已从名为“VICTIM1-WINDOWS”的采样设备之一清除事件日志的事件。

此最终屏幕截图显示集中式日志记录解决方案中的日志消息。

注意：所有采样系统组件都需要屏幕截图 ，并且必须 证明上面详述的所有安全事件。

控制 57：提供可证明的证据，证明记录的安全事件包含以下最小信息：

• 用户

• 事件类型

• 日期和时间

• 成功或失败指示器

• 标识受影响系统的标签

• 意向：记录的安全事件需要提供足够的信息，以帮助确定攻击流量是否成功、访问了哪些信息、访问了哪些级别、谁负责、来自何处等。

• 示例证据指南：证据应显示所有系统组件中的日志示例，其中显示了这些类型的安全事件。 日志应包括上面列出的所有信息。

• 示例证据：以下屏幕截图显示了 Windows 事件查看器中来自作用域内系统组件“SEGSVR02”的安全事件的信息。

注意：所有抽样系统组件都需要屏幕截图 ，并且必须 证明上述控件中详述的所有安全事件。 为上述控件收集的证据很可能也满足此控制要求，从而提供了日志记录信息的足够详细信息。

控制 58：提供所有采样系统组件的时间同步到同一主服务器和辅助服务器的证据。

• 意向：日志记录的一个关键组成部分是确保所有系统中的日志都具有同步的系统时钟。当需要进行调查以跟踪泄露和/或数据泄露时，这一点非常重要。 如果日志具有不同程度的时间戳，则通过各种系统跟踪事件几乎是不可能的，因为重要日志可能会丢失并且难以跟踪。

• 示例证据指南：理想情况下，应维护一个时间同步拓扑，该拓扑显示如何在资产中同步时间。 然后，可以通过跨采样系统组件的时间同步设置的屏幕截图提供证据。 这应该表明，所有时间同步都同步到同一个主 (或者是否就位辅助) 服务器。

• 示例证据：此图显示了正在使用的时间同步拓扑。

下一张屏幕截图显示配置为 NTP 服务器的 WatchGuard，并指向作为时间源 time.windows.com。

此最终屏幕截图显示范围内系统组件“CLARANET-SBU-WM”已配置为使 NTP 指向主服务器，该服务器是 WatchGuard 防火墙 (10.0.1.1) 。

控制 59：在使用面向公众的系统时，提供可证明的证据，证明将安全事件日志发送到不在外围网络内的集中式日志记录解决方案。

• 意向：此控件的意图是确保 DMZ 和日志记录终结点之间的逻辑或物理分离。 由于外围网络面向公众，因此会向外部活动组公开，因此比环境中其他组件面临更大的风险。 如果 DMZ 组件遭到入侵，则需要维护日志记录数据的完整性，以便不仅阻止活动组篡改日志以隐藏泄露，而且还有助于执行可能需要的任何取证调查工作。 通过登录到外围网络外部的系统，用于限制从外围网络到这些安全系统的流量的安全控制应有助于保护它们免受恶意活动和篡改尝试的影响。

• 示例证据指南：应提供屏幕截图或配置设置，证明日志配置为立即 (或接近立即) 发送到外围网络外部的集中式日志记录解决方案。 我们正在寻找几乎立即传送日志，因为将日志传送到集中式日志记录解决方案所需的时间越长，处理参与者在传送之前必须篡改本地日志的时间就越多。

• 示例证据：Contoso DMZ 系统利用 NXLog 传送日志文件。 以下屏幕截图显示了在“DESKTOP-7S65PN”DMZ jumpbox 上运行的“nxlog”服务，该服务用于管理所有 DMZ 服务器。

以下屏幕截图显示了 nxlog.conf 文件中的提取，其中显示目标是应用程序子网 10.0.1.250 中的内部日志收集器，用于寄送到 AlienVault。

NXLog (https://nxlog.co/documentation/nxlog-user-guide/modes.html) 的以下 URL 显示日志传送通过以下提取实时显示：

控制措施 60：提供可证明的证据，证明集中式日志记录解决方案受到保护，防止未经授权的日志记录数据篡改。

• 意向：尽管日志记录设备和集中式日志记录解决方案之间通常存在逻辑/物理分离，但仍存在有人试图篡改日志以隐藏其活动的风险。 此控制的目的是确保有足够的授权机制来限制可以对集中式日志记录解决方案执行管理操作的用户数。

• 示例证据指南：证据通常包含屏幕截图，其中显示了集中式日志记录解决方案的授权和身份验证配置，演示用户仅限于其工作角色/职能所需的用户。

• 示例证据：Contoso 外包 SOC 利用 AlienVault 作为集中式 SIEM 工具。 AlienVault 于 2018 年被 AT&T 收购，现在被 USM Anywhere 收购。 以下网页 (https://cybersecurity.att.com/documentation/usm-anywhere/deployment-guide/admin/usm-anywhere-data-security.htm) 讨论 USM Anywhere 如何保护数据免受未经授权的篡改。 以下链接 (https://cybersecurity.att.com/documentation/usm-appliance/raw-logs/raw-log-management.htm) 突出显示 USM Anywhere 产品如何确保存档日志的完整性。

注意： 如果 SIEM 是内部的，则需要提供证据来证明，根据用户的作业需要，对日志记录数据的访问仅限于选定数量的用户，并且平台本身受到保护，使其免受篡改 (大多数解决方案都会将此内容构建到日志记录解决方案) 的功能中。

控制措施 61：提供可证明的证据，证明至少 30 天的安全事件日志记录数据立即可用，并保留 90 天的安全事件日志。

• 意向：有时，泄露或安全事件与标识它的组织之间存在时间差异。 此控制的目的是确保组织有权访问历史事件数据，以帮助完成事件响应和可能需要的任何取证调查工作。

• 示例证据指南：证据通常与显示集中式日志记录解决方案的配置设置一起显示数据的保留时间。 需要立即在解决方案中提供价值 30 天的安全事件日志记录数据，但在存档数据的情况下，这需要证明 90 天的价值可用。 这可以通过显示包含导出数据日期的存档文件夹来执行此操作。

• 示例证据 1：以下屏幕截图显示 AlienVault 中有 30 天的日志可用。

注意：由于这是一个面向公众的文档，防火墙序列号已经过修订，但是，我们不会设想 ISV 支持任何修订后的屏幕截图，除非它包含个人身份信息。

下一张屏幕截图显示日志提取可追溯到 5 个月，从而显示日志可用。

注意：由于这是面向公众的文档，公共 IP 地址已经过修订，但是，除非 ISV 包含个人身份信息，否则我们不会设想 ISV 支持任何修订后的屏幕截图。

• 示例证据 2：以下屏幕截图显示，日志事件在 Azure 中实时保存 30 天，在冷存储中保留 90 天。

安全事件日志评审

查看安全日志是帮助组织识别可能指示安全漏洞的安全事件或可能指示即将发生的事件的安全事件的一项重要功能。 这可以通过每天的手动过程来完成，也可以使用 SIEM (安全信息和事件管理) 解决方案来完成，该解决方案有助于分析审核日志、查找可标记为手动检查的关联和异常。

控制措施 62：提供用于管理日志评审做法和过程的策略文档。

• 意向：IBM 的一份题为“数据泄露成本报告 2020 年报告”的报告强调，识别和遏制数据泄露的平均时间可能需要 280 天，而恶意活动组报告为 315 天的情况则更大。 由于报告数据泄露的平均成本为数百万美元，因此必须缩短此数据泄露生命周期，以便不仅最大程度地减少数据暴露窗口，而且还要缩短活动组必须从环境中外泄数据的时间范围。 通过减少此时段，组织可以降低数据泄露的总体成本。

• 通过实施可靠的审查和警报过程，组织可以更好地在数据泄露生命周期中更快地识别违规行为，从而最大程度地减少对组织的影响。 此外，强大的过程可能有助于识别漏洞企图，使组织能够加强安全防御机制，以缓解这种增加的威胁，从而进一步降低攻击活动入侵的可能性。

• 示例证据指南：提供组织记录的策略和过程文档，涵盖日志评审最佳做法。

• 示例证据：下面是日志评审策略/过程摘录。

注意： 此屏幕截图显示了策略/流程文档，ISV 希望共享实际的支持策略/过程文档，而不只是提供屏幕截图。

控制措施 63：提供可证明的证据，证明日志由人工或自动化工具每天审查，以识别潜在的安全事件。

• 意向：此控件的意图是确保执行每日日志评审。这一点对于识别配置为提供安全事件警报的警报脚本/查询可能无法发现的任何异常非常重要。

• 示例证据指南：通常通过屏幕截图或屏幕共享提供证据，以证明正在进行日志评审。 这可以通过每天完成的表单的方式，或者通过 JIRA 或 DevOps 票证发布相关评论来显示这是每天执行的。 例如，可以创建每周 JIRA 票证“每日日志评审 W/C 2021 年 6 月 26 日”，每天都有人发布每日日志评审的结果。 如果标记了任何异常，则可以将此异常记录在同一票证中，以在单个 JIRA 中演示下一个控件。

• 如果使用自动化工具，则可以提供屏幕截图证据来演示配置的自动化，并提供其他证据来证明自动化正在运行，并且有人正在查看自动输出。

• 示例证据：Contoso 利用第三方 SOC 提供程序 Claranet Cyber Security 进行日志关联和评审。 AlienVault 由 SOC 提供程序使用，该提供程序具有为异常日志和可能突出显示潜在安全事件的链接事件提供自动日志分析的功能。 以下三个屏幕截图显示了 AlienVault 中的关联规则。

第一个屏幕截图标识用户已添加到“域管理员”组的位置。

下一张屏幕截图标识了多次失败的登录尝试后，成功登录的位置可能会突出显示成功的暴力攻击。

此最终屏幕截图标识了在设置策略时发生密码策略更改的位置，因此帐户密码不会过期。

下一张屏幕截图显示，票证在 SOC 的 ServiceNow 工具中自动引发，并触发上述规则。

控制措施 64：提供可证明的证据，证明对潜在的安全事件和异常进行了调查和修正。

• 意向：目的是调查在每日日志评审过程中发现的任何异常情况，并执行相应的修正或操作。这通常涉及一个会审过程，以确定异常是否需要操作，然后可能需要调用事件响应过程。

• 示例证据指南：应提供证据和屏幕截图，该屏幕截图显示已标识为每日日志评审的一部分的异常情况将得到跟进。 如前所述，这可能是通过 JIRA 票证，显示异常被标记，然后详细说明之后执行的活动。 这可能会提示提出特定的 JIRA 票证以跟踪正在执行的所有活动，或者可能只是记录在每日日志评审票证中。 如果需要事件响应操作，则应将其记录为事件响应过程的一部分，并应提供证据来证明这一点。

• 示例证据：以下屏幕截图示例显示 Claranet 网络安全 MDR (托管检测和响应) SOC 在 ServiceNow 中跟踪的安全警报。

下一张屏幕截图显示已确认 David Ashton @ Contoso 已通过 ServiceNow 客户门户中的更新解决了此问题。

安全事件警报

需要立即调查关键安全事件，以尽量减少对数据和操作环境的影响。 警报有助于立即向员工突出显示潜在的安全漏洞，以确保及时响应，以便组织能够尽快遏制安全事件。 通过确保警报有效工作，组织可以最大程度地减少安全漏洞的影响，从而减少严重违规的可能性，从而损害组织品牌，并通过罚款和声誉损害造成财务损失。

控制措施 65：提供控制安全事件警报做法和过程的策略文档。

• 意向：应对需要组织立即响应的关键安全事件使用警报，因为该事件有可能指示环境泄露和/或数据泄露。 应记录有关警报过程的强过程，以确保以一致且可重复的方式执行。 这有望有助于减少“数据泄露生命周期”时间线。

• 示例证据指南：提供组织记录的策略和过程文档，涵盖安全事件警报最佳做法。

• 示例证据：下面是安全事件警报策略/过程摘录。 请提供完整的策略和过程文档来支持评估。

注意： 此屏幕截图显示了策略/流程文档，ISV 希望共享实际的支持策略/过程文档，而不只是提供屏幕截图。

控制措施 66：提供可证明的证据，证明针对以下类型的安全事件触发警报的即时会审：

• 特权帐户创建或修改

• 病毒或恶意软件事件

• 事件日志篡改

• IDPS 或 WAF 事件（如果已配置）

• 意向：上面列出了某些类型的安全事件，这些事件可以突出显示已发生的安全事件，这些事件可能指向环境泄露和/或数据泄露。

• 示例证据指南：应提供证据，并提供警报配置的屏幕截图 和 收到的警报的证据。 配置屏幕截图应显示触发警报的逻辑以及如何发送警报。 可以通过短信、电子邮件、Teams 频道、Slack 频道等发送警报。

• 示例证据：Contoso 使用 Claranet 网络安全提供的第三方 SOC。 以下示例显示，SOC 利用的 AlienVault 中的警报配置为向 Claranet 网络安全处的 SOC 团队成员 Dan Turner 发送警报。

下一张屏幕截图显示了 Dan 正在接收的警报。

控制措施 67：提供可证明的证据，证明员工始终可以全天候响应安全警报。

• 意向：请务必尽快会审安全警报，以限制环境和/或数据暴露。 如果发现违规，员工必须始终能够响应警报并提供关键调查工作。 此过程启动速度越快，可以越快地控制安全事件以保护数据或限制泄露的影响。
• 示例证据指南：应提供证据，证明员工每天 24 小时都可以响应安全警报。 这可能与待命轮回转。
• 示例证据：以下屏幕截图显示了 Contoso 2020 年 12 月的待命轮回转。 Claranet 网络安全 SOC 团队会向 Contoso 待命团队的成员发出警报。

信息安全风险管理

信息安全风险管理是所有组织应至少每年进行一次的重要活动。 组织必须了解其威胁和风险才能有效缓解这些威胁。 如果没有有效的风险管理，组织可能会在他们认为重要的领域实施安全最佳做法，从而在这些领域投入资源、时间和金钱，而其他威胁的可能性更大，因此应该得到缓解。 有效的风险管理将帮助组织专注于对业务构成最大威胁的风险。 这应该每年进行一次，因为安全形势不断变化，因此威胁和风险可能会随着时间推移而变化。 新冠肺炎（COVID-19）就是一个很好的例子，新冠肺炎（COVID-19）网络钓鱼攻击和大规模 (，并迅速) 数百或数千名工人远程工作。

控制措施 68：提供已建立正式信息安全风险管理流程的可证明证据。

• 意向：如上所述，可靠的信息安全风险管理过程对于帮助组织有效管理风险非常重要。 这将有助于组织规划针对环境威胁的有效缓解措施。

风险评估必须包括信息安全风险，而不仅仅是一般“业务”风险。

• 示例证据指南：应提供正式记录的风险评估管理流程。
• 示例证据：以下证据是 Contoso 风险评估过程部分的屏幕截图。

注意： 此屏幕截图显示了策略/流程文档，ISV 希望共享实际的支持策略/过程文档，而不只是提供屏幕截图。

控制措施 69：提供可证明的证据，证明每年至少进行一次正式风险评估。

• 意向：安全威胁会根据环境的变化、所提供的服务的变化、外部影响、安全威胁格局的演变等不断变化。组织需要至少每年完成此过程。 建议在发生重大更改时也执行此过程，因为威胁可能会更改。

• 示例证据指南：可以通过版本跟踪或日期证据来提供证据。 应提供证据，显示信息安全风险评估的输出和信息安全风险评估过程本身的 NOT 日期。

• 示例证据：此屏幕截图显示每六个月安排一次风险评估会议。

这两个屏幕截图显示了两次风险评估会议的会议记录。

控制措施 70：提供可证明的证据，证明信息安全风险评估包括威胁、漏洞或等效项。

• 意向：应对针对环境和数据的威胁以及可能存在的漏洞进行信息安全风险评估。 这将有助于组织识别可能构成重大风险的无数威胁/漏洞。
• 示例证据指南：不仅应通过已提供的信息安全风险评估过程提供证据，还应通过风险登记/风险处理计划 (风险评估的输出来提供证据，) 应包括风险和漏洞。
• 示例证据：以下屏幕截图显示了风险寄存器，其中演示了包含威胁和漏洞。

注意： 应提供完整的风险评估文档，而不是屏幕截图。

控制措施 71：提供可证明的证据，证明信息安全风险评估包括影响、可能性风险矩阵或等效项。

• 意向：信息安全风险评估应记录影响和可能性评级。 这些矩阵通常用于帮助确定风险值，组织可以使用该风险值来确定风险处理优先级，以帮助降低风险值。
• 示例证据指南：不仅应通过已提供的信息安全风险评估过程来提供证据，还应通过风险登记/风险处理计划) 风险评估 (的输出来提供证据，该计划应包括影响和可能性评级。
• 示例证据：以下屏幕截图显示了风险寄存器，其中演示了影响和可能性。

注意： 应提供完整风险assessment_ _document__ation，而不是屏幕截图。

控制措施 72：提供可证明的证据，证明信息安全风险评估包括风险登记和处理计划。

• 意向：组织需要有效地管理风险。 需要正确跟踪这一点，以提供所应用的四种风险处理之一的记录。 风险处理包括：
• 避免/终止 ：企业可能确定处理风险的成本大于服务产生的收入。 因此，企业可能会选择停止执行该服务。
• 转让/共享 ：企业可以选择通过将处理转移到第三方来将风险转移给第三方。
• 接受/容忍/保留 ：企业可能会决定风险可接受。 这在很大程度上取决于企业的风险偏好，并可能因组织而异。
• 处理/缓解/修改 ：业务决定实施缓解控制，以将风险降低到可接受的水平。
• 此控制的目的是确保组织正在执行风险评估并相应地对此采取行动。
• 示例证据指南：应提供风险处理计划/风险登记 (或类似) 的内容，以证明风险评估过程正在正确执行。
• 示例证据：下面是 Contoso 的风险寄存器。

注意： 应提供完整的风险评估文档，而不是屏幕截图。

以下屏幕截图演示了风险处理计划。

安全事件响应

安全事件响应对所有组织都很重要，因为这可以减少组织控制安全事件所花费的时间，并限制组织对数据外泄的暴露级别。 通过制定全面而详细的安全事件响应计划，可将此风险从识别时间减少到遏制时间。

IBM 的一份题为“2020 年数据泄露成本报告”的报告强调，平均而言，遏制泄露所需的时间为 73 天。 此外，同一份报告确定了遭受违规的组织的最大成本节约措施是事件响应准备，平均节省了 2,000,000 美元的成本。

组织应遵循行业标准框架（如 ISO 27001、NIST、SOC 2、PCI DSS 等）的安全合规性最佳做法。

控制 73： (IRP) 提供安全事件响应计划。

• 意向：如前所述，此控件的意图是需要正式记录的事件响应计划。 这将有助于更高效地管理安全事件响应，最终可以限制组织的数据丢失风险并降低泄露成本。
• 示例证据指南：提供事件响应计划/过程的完整版本。 这应包括下一个控件中介绍的记录通信过程。
• 示例证据：以下屏幕截图显示了 Contoso 事件响应计划的开始。 作为证据提交的一部分，必须提供整个事件响应计划。

注意： 此屏幕截图显示了策略/流程文档，ISV 希望共享实际的支持策略/过程文档，而不只是提供屏幕截图。

控制措施 74：提供可证明的证据，证明安全 IRP 包括记录的通信过程，以确保及时通知主要利益干系人，例如支付品牌和收购方、监管机构、监管机构、董事和客户。

• 意向：组织可能根据其在 (运营的国家/地区（例如《一般数据保护条例》）承担违反通知义务;GDPR) ，或者基于 (提供的功能，例如，如果支付数据) 处理 PCI DSS。 不及时通知可能会造成严重影响，因此，为确保履行通知义务，事件响应计划应包括一个通信过程，包括与所有利益干系人、媒体通信过程以及谁能够和不能与媒体交谈。
• 示例证据指南：提供事件响应计划/过程的完整版本，其中应包含一个涵盖通信过程的部分。
• 示例证据：以下屏幕截图显示了事件响应计划的摘录，其中显示了通信过程。

控制措施 75：提供可证明的证据，证明事件响应团队的所有成员都已完成年度培训或桌面练习。

• 意向：如前所述，组织遏制泄露所需的时间越长，数据外泄的风险就越大，这可能会导致更多的数据外泄，而泄露的总体成本也就越大。 组织的事件响应团队能够及时响应安全事件，这一点很重要。 通过进行定期训练和执行桌面练习，这使团队能够快速高效地处理安全事件。

• 建议对事件响应团队进行内部事件响应培训 ，并 定期进行桌面练习，这些练习应链接到信息安全风险评估，以确定最有可能发生的安全事件。 这样，团队将快速知道要采取哪些步骤来遏制和调查最有可能的安全事件。

• 示例证据指南：应提供证据，证明已通过共享培训内容进行了培训，并提供记录显示谁参加了 (应包括所有事件响应团队) 。 或者，或者，记录显示已进行了桌面练习。所有这些必须在提交证据后的 12 个月内完成。

• 示例证据：Contoso 使用名为 Claranet Cyber Security 的外部安全公司进行了事件响应桌面练习。 下面是作为咨询的一部分生成的报告示例。

注意： 需要共享完整的报告。 此练习也可以在内部进行，因为第三方公司没有Microsoft 365 要求。

控制措施 76：提供可证明的证据，以表明安全 IRP 已根据学到的经验教训或组织更改进行了更新。

• 意向：随着时间的推移，事件响应计划 (IRP) 应根据组织变化或制定 IRP 时学到的经验教训而发展。 对操作环境的更改可能需要对 IRP 进行更改，因为威胁可能会更改，或者法规要求可能会更改。 此外，随着桌面练习和实际安全事件响应的进行，这通常可以识别可以改进的 IRP 区域。 这需要内置到计划中，此控件的意图是确保此过程包含在 IRP 中。

• 示例证据指南：通常通过查看安全事件或桌面练习的结果来证明这一点，其中已确定经验教训并在 IRP 更新中得出。 IRP 应维护更改日志，该日志还应引用基于经验教训或组织更改实现的更改。

• 示例证据：以下屏幕截图来自提供的 IRP，其中包括一个部分，介绍如何根据学到的经验教训和/或组织更改更新 IRP。

IRP 更改日志显示在 2021 年 7 月进行的桌面练习的背面进行了更新。

安全域：数据处理安全和隐私

此安全域包含在内，以确保从 Microsoft 365 使用的任何数据在传输和静态中都受到充分保护。 此域还确保消费者 (数据主体) 隐私问题由 ISV 满足，这符合 GDPR (一般数据保护条例) ，该条例涉及欧盟公民的隐私。

传输中的数据

由于 Microsoft 365 个开发的应用/加载项的连接要求，通信将通过公用网络（即 Internet）进行。 因此，需要适当保护传输中的数据。 本部分介绍通过 Internet 保护数据通信。

控制 1：提供可证明的证据，证明 TLS 配置满足或超过 TLS 配置文件配置要求中的加密要求。

• 意向：此控制的目的是确保安全传输组织使用的Microsoft 365 数据。 TLS 配置文件配置定义了特定于 TLS 的要求，以帮助确保流量免受中间人攻击。

• 示例证据指南：证明这一点的最简单方法是针对所有 Web 侦听器运行 Qualys SSL 服务器测试工具，包括在非标准端口上运行的任何侦听器。

• 请记住勾选“不要在板上显示结果”选项，这会阻止将 URL 添加到网站。

• 还可以提供证据来演示 TLS 配置文件配置要求中的单独检查。 可以使用配置设置以及脚本和软件工具来帮助提供某些特定设置（即 TLS 压缩已禁用）的证据。

• 示例证据：以下屏幕截图显示了 www.clara.net:443 Web 侦听器的结果。

注意：认证分析师将评审完整输出，以确认满足 TLS 配置文件配置要求的所有要求 (请提供完整扫描输出) 的屏幕截图。 Depending_ 已经 提供了_what证据，分析师可能会进行自己的Qualys扫描。

• 示例证据 2：以下屏幕截图显示了在存储上配置了 TLS 1.2。

注意： 仅此屏幕截图无法满足此要求。

• 示例证据 3：以下屏幕截图显示仅在服务器上启用 TLS V1.3。

此示例使用注册表项通过调整值来禁用或启用协议，如下所示：

二进制：0 - off 1 - on

十六进制：0x00000000 - off 0xffffffff - on

请注意 ： - 如果你不了解此方法，请不要使用此方法，因为我们 (Microsoft) 不负责你使用或遵循此示例或其使用可能对你的系统产生的任何影响。 此处只是为了说明另一种方法来显示 TLS 是启用或禁用的。

注意：仅靠这些屏幕截图无法满足此要求。

控制 2：提供可证明的证据，证明在处理 Web 请求的所有面向公众的服务中禁用了 TLS 压缩。

• 意向：存在特定的 TLS 漏洞，即 CRIME (CVE-2012-4929) ，这会影响 TLS 压缩。 因此，行业建议关闭此功能。

• 示例证据指南：这可以通过 Qualys SSL 实验室工具提供证据。

• 示例证据：以下屏幕截图通过 Qualys SSL 实验室工具演示了这一点。

控制 3：提供可证明的证据，证明 TLS HTTP 严格传输安全性已启用，并且跨所有站点配置为 >= 15552000。

• 意向：HTTP Strict Transport Security (HSTS) 是一种安全机制，旨在通过名为“Strict-Transport-Security”的 HTTPS 响应标头字段强制 TLS 连接来保护网站免受中间人攻击。

• 示例证据指南：这可以通过 Qualys SSL 实验室工具或其他工具和 Web 浏览器加载项提供证据。

• 示例证据：以下屏幕截图通过 www.microsoft.com 网站的名为“HTTP 标头 Spy”的 Web 浏览器加载项显示这 一 点。

静态数据

当 ISV 存储从 Microsoft 365 平台使用的数据时，需要适当保护数据。 本部分介绍数据库和文件存储中存储的数据的保护要求。

控制 4：使用 AES、Blowfish、TDES 和加密密钥大小为 128 位和 256 位的加密算法，提供静态数据内联加密的证据。

• 意向：已知某些较旧的加密算法包含一些加密弱点，这增加了活动组在不知道密钥的情况下解密数据的可能性。 因此，此控制的目的是确保仅使用行业接受的加密算法来保护存储Microsoft 365 数据。

• 示例证据指南：可以通过屏幕截图提供证据，其中显示了用于保护数据库和其他存储位置中Microsoft 365 数据的加密。 证据应证明加密配置符合 Microsoft 365 认证的 加密配置文件配置要求 。

• 示例证据：以下屏幕截图显示，在 Contoso 数据库上启用了 TDE (透明数据加密) 。 第二个屏幕截图显示了Microsoft文档页“SQL 数据库、SQL 托管实例和 Azure Synapse Analytics 的透明数据加密”，其中显示了 AES 256 加密用于 Azure TDE。

• 示例证据 2：以下屏幕截图显示了为 Blob 和文件配置了加密的 Azure 存储。 以下屏幕截图显示了“Microsoft文档”页“静态数据的 Azure 存储加密”，其中显示了 Azure 存储使用 AES-256 进行加密。

控制 5：提供可证明的证据，证明哈希函数或消息身份验证 (HMAC-SHA1) 仅用于根据加密配置文件要求内联保护静态数据。

• 意向：与加密算法一样，某些哈希函数和消息身份验证算法基于具有加密弱点的算法。 此控件的目的是确保在将哈希用作数据保护机制时，使用强哈希函数保护Microsoft 365 数据。 如果环境和/或应用程序未使用此功能，则需要提供可以证实这一点的证据。

• 示例证据指南：证据可能采用屏幕截图的形式，其中显示了哈希函数正在运行的代码片段。

• 示例证据：Contoso 在其应用程序中利用哈希功能。 以下屏幕截图演示了 SHA256 用作哈希函数的一部分。

控制 6：提供所有存储数据的清单，包括用于保护数据的存储位置和加密。

• 意向：若要正确保护数据，组织需要了解其环境/系统正在使用的数据以及数据存储的位置。 完全了解和记录这一点后，组织不仅能够实施足够的数据保护，而且还能够合并数据所在的位置，以便更有效地实施保护。 此外，将数据合并到尽可能少的位置时，可以更轻松地实现适当的基于角色的访问控制 (基于角色的访问控制，) 根据需要限制对尽可能少的员工的访问。

• 示例证据指南：应通过文档或从内部系统（即 SharePoint 或 Confluence）导出来提供证据，详细说明所使用的所有数据、所有存储位置以及实现的加密级别。

• 示例证据：以下屏幕截图显示了显示数据类型的文档的外观示例。

数据保留和处置

如果 ISV 使用并存储Microsoft 365 数据，如果活动组破坏 ISV 环境，则存在数据泄露的风险。 为了最大程度地降低此风险，组织应仅保留交付服务所需的数据，而不应保留将来“可能”使用的数据。 此外，数据应仅保留一段时间，前提是需要提供捕获数据所针对的服务。 应定义数据保留并与用户通信。 数据超过定义的保留期后，必须安全地删除此保留期，以便无法重新构造或恢复数据。

控制措施 7：提供已正式确定已批准和记录的数据保留期的可证明证据。

• 意向：记录和遵循的保留策略不仅对于履行某些法律义务（例如，但不限于，欧盟 GDPR) (一般数据保护条例）和英国 DPA 2018 (数据保护法) 还限制组织风险等一些法律义务非常重要。 通过了解组织的数据要求以及企业执行其职能所需的数据时长，组织可以确保在数据有用性过期后正确处理数据。 通过减少存储的数据量，组织可以减少发生数据泄露时公开的数据量。 这将限制整体影响。

• 通常，组织存储数据只是因为“以防万一”，但是，如果组织不需要数据来执行其服务或业务功能，则不应存储数据，因为这会增加组织不必要的风险。

• 示例证据指南：提供完整的数据保留策略，其中明确详细说明数据 (必须涵盖所有数据类型) 应保留多长时间，以便企业能够执行其业务功能。

• 示例证据：以下屏幕截图显示了 Contoso 的数据保留策略。

注意： 此屏幕截图显示了策略/流程文档，ISV 希望共享实际的支持策略/过程文档，而不只是提供屏幕截图。

控制 8：提供可证明的证据，证明保留的数据与定义的保留期匹配。

• 意向：此控件的目的只是验证是否满足定义的数据保留期。 如前所述，组织可能有法律义务来达到此要求，但也需要保留数据，并在必要时保留数据，以帮助降低发生数据泄露时对组织的风险。

• 示例证据指南： (或通过屏幕共享提供屏幕截图证据，) 显示存储的数据 (在所有各种数据位置（即数据库、文件共享、存档等）) 不超过定义的数据保留策略。 示例可以是带有日期字段的数据库记录的屏幕截图、按最早的记录顺序搜索，以及/或显示保留期内时间戳的文件存储位置。

注意： 应在屏幕截图中修订任何个人/敏感客户数据。

• 示例证据：以下证据显示了一个 SQL 查询，该查询显示数据库表的内容在“DATE_TRANSACTION”字段中按升序排序，以显示数据库中最早的记录。 此数据应为两个月，不超过定义的保留期。

注意： 这是一个测试数据库，因此其中没有很多历史数据。

控制 9：提供可证明的证据，证明在数据保留期后，已设置相关流程以安全删除数据。

• 意向：此控件的目的是确保用于删除超过保留期的数据的机制是安全的。 有时可以恢复已删除的数据;因此，删除过程需要足够可靠，以确保数据在删除后无法恢复。

• 示例证据指南：如果删除过程以编程方式完成，请提供用于执行此操作的脚本的屏幕截图。 如果按计划执行，请提供显示计划的屏幕截图。 例如，可将用于删除文件共享中的文件的脚本配置为 CRON 作业，屏幕截图显示执行的计划和脚本，并提供显示所用命令的脚本。

• 示例证据 1：这是一个简单的脚本，可用于删除基于日期 -WHERE DateAdd 为 -30 天保留的所有数据记录，这将清除超过所选数据保留日期 30 天的所有保留记录。 请注意，我们需要脚本，还需要运行作业和结果的证据。

• 示例证据 2：以下内容取自控制 7 中的 Contoso 数据保留计划 – 这显示了用于数据销毁的过程。

注意： 此屏幕截图显示了策略/流程文档，ISV 希望共享实际的支持策略/过程文档，而不只是提供屏幕截图。

• 示例证据 3：在此示例中，已在 Azure 中创建 Runbook 和相应的计划，以安全地删除自数据记录保留策略到期后的 30 天内创建的结束日期的记录。 此作业设置为每月在每月最后一天运行。

下面的窗口显示已编辑 Runbook 以查找记录，并且包含与脚本一样不在视图中的删除命令。 请注意，这些屏幕截图必须显示完整的 URL 和用户名，并且 ISV 需要显示删除前记录计数的屏幕截图和删除后的记录计数的屏幕截图。 这些屏幕截图纯粹是可以采用的不同方法的示例。

数据访问管理

数据访问需要限制为所需的人数，以减少数据被恶意或意外泄露的可能性。 对数据和加密密钥的访问权限应限制为具有合法业务需要的用户才能完成其工作角色。 这应该有充分记录，并应实现一个完善的请求访问过程。 对数据和加密密钥的访问应遵循最低特权原则。

控制 10:P列出有权访问数据或加密密钥的所有人员，包括业务理由。

• 意向：组织应将数据和加密密钥的访问限制为尽可能少的员工。 此控制的目的是确保员工对数据和/或加密密钥的访问仅限于具有明确业务需要的员工进行上述访问。

• 示例证据指南：内部系统的文档或屏幕截图，其中记录了有权访问数据和/或加密密钥的所有员工，以及应提供这些人员有权访问的业务理由。 认证分析师将使用此列表对下一个控件的用户进行采样。

• 示例证据：以下文档显示了具有数据访问权限的用户的记录列表和业务理由。

控制措施 11：提供可证明的证据，证明有权访问数据或加密密钥的抽样个人已正式批准，并详细说明其工作职能所需的特权。

• 意向：授予对数据和/或加密密钥的访问权限的过程需要包括批准，以确保其工作职能需要个人的访问权限。 这可确保没有真正理由进行访问的员工不会获得不必要的访问权限。

• 示例证据指南：通常，为上一个控件提供的证据可以帮助支持此控件。 如果所提供的文档没有正式批准，则证据可能包括在 Azure DevOps 或 Jira 等工具中提出并批准访问的更改请求。

• 示例证据：这组图像显示为控制措施 10 中的上述列表创建和批准的 Jira 票证，以授予或拒绝对敏感数据和/或加密密钥的访问权限。

此图像演示了在 Jira 中创建一个请求，以在系统后端环境中获得 Sam Daily 加密密钥的批准。 这是为控制上述 10 个已获得书面授权的下一步完成的。

这表明，授予 Sam Daily 访问权限的请求已由 Jon Smith 从管理层批准，可在控制 10 中看到。 (请注意，审批必须来自有权允许更改请求的人员，它不能是其他开发人员) 。

上面显示了 Jira 中用于此过程的工作流，请注意，除非它已通过审批过程（因此无法通过自动化），否则无法将任何内容添加为“完成”。

上面的项目板现在显示，已批准 Sam Daily 访问加密密钥。 积压工作下方显示 Sam Daily 的请求审批和分配完成工作的人员。

为了满足此控件的要求，必须显示所有这些屏幕截图或类似的说明，以证明你已满足控制要求。

• 示例证据 2：在下面的示例中，已为用户请求了对生产 DB 的管理员访问权限和完全控制权限。 请求已发送以供审批，如图像右侧所示，该请求已获得批准，如左侧所示。

在上面可以看到，访问已获批准，并已完成签名。

控制措施 12：提供可证明的证据，证明有权访问数据或加密密钥的抽样个人仅具有审批中包含的权限。

• 意向：此控件的意图是确认数据和/或加密密钥访问已按照记录进行配置。

• 示例证据指南：可以通过屏幕截图提供证据，其中显示了授予采样个人的数据和/或加密密钥访问权限。 证据必须涵盖所有数据位置。

• 示例证据：此屏幕截图显示授予用户“John Smith”的权限，根据上一个控件的证据，该权限将针对同一用户的审批请求交叉引用。

控制措施 13：提供与客户共享数据的所有第三方的列表。

• 意向：如果第三方用于存储或处理Microsoft 365 数据，则这些实体可能会带来重大风险。 组织应制定良好的第三方尽职调查和管理流程，以确保这些第三方安全地存储/处理数据，并确保它们将履行任何可能承担的法律义务，例如，作为 GDPR 规定的数据处理者。

• 组织应维护与以下部分或全部共享数据的所有第三方的列表：

• ) 提供哪些服务 () (，

• 共享哪些数据，

• 共享数据的原因，

• 关键联系信息 (，即主要联系人、违规通知联系人、DPO 等 ) ，

• 合同续订/到期

• 法律/合规性义务 (，即 GDPR、HIPPA、PCI DSS、FedRamp 等 )

• 示例证据指南：提供文档，详细说明共享Microsoft 365 数据 的所有 第三方。

注意： 如果未使用第三方，则需要由高级领导团队成员以书面形式确认 (电子邮件) 。

• 示例证据 1

• 示例证据 2：此屏幕截图显示了高级领导团队成员的电子邮件示例，其中确认没有第三方用于处理Microsoft 365 数据。

控制措施 14：提供可证明的证据，证明使用客户数据的所有第三方都已制定共享协议。

• 意向：如果Microsoft 365 数据与第三方共享，请务必正确安全地处理数据。 数据共享协议必须到位，以确保第三方仅根据需要处理数据，并了解其安全义务。 组织安全性仅与最薄弱的环节一样强大。 此控制的目的是确保第三方不会成为组织的薄弱环节。

• 示例证据指南：与第三方共享数据共享协议。

• 示例证据：以下屏幕截图显示了简单的示例数据共享协议。

注意： 应共享完整协议，而不是屏幕截图。

GDPR

大多数组织都将处理可能是欧洲公民 (数据主体) 数据的数据。 在处理 任何 数据主体的数据时，组织需要满足 GDPR) (一般数据保护条例。 这适用于数据控制者 (你直接捕获上述数据) 或数据处理者， (你代表数据控制器) 处理这些数据。 虽然本节不涵盖整个法规，但它涉及 GDPR 的一些关键要素，以帮助获得组织认真对待 GDPR 的一些保证。

控制措施 15： (SAR) 流程提供记录的主题访问请求，并提供证明数据主体能够提高 SAR 的证据。

• 意向：GDPR 包括处理数据主体数据的组织必须履行的特定义务。 组织 (SCR管理主体访问请求) 的义务包含在第12条中，该条款第12.3条规定，数据控制者在收到特区一个月的响应请求。 如有必要，允许再延长两个月。 即使组织充当数据处理者，仍需要这样做来帮助客户 (数据控制者) 履行其 SAR 义务。

• 示例证据指南：提供记录的用于处理 SAR 的过程。

• 示例证据：以下示例显示了用于处理 SAR 的记录过程。

注意： 此屏幕截图显示了策略/流程文档，ISV 希望共享实际的支持策略/过程文档，而不只是提供屏幕截图。

控制措施 16：提供可证明的证据，证明在响应 SAR 时能够识别数据主体数据的所有位置。

• 意向：此控制的目的是确保组织具有可靠的机制来标识所有数据主体的数据。 这可能是一个手动过程，因为所有数据存储都记录良好，或者可以使用其他工具来确保所有数据都作为 SAR 过程的一部分进行定位。

• 示例证据指南：可以通过所有数据位置的列表和记录过程来提供证据，以搜索所有数据位置以获取数据。 这将包括搜索数据所需的任何命令，也就是说，如果包含 SQL 位置，则会详细说明特定的 SQL 语句，以确保正确找到数据。

• 示例证据：以下屏幕截图是上述 SAR 过程中的代码片段，其中显示了如何查找数据。

下面的四幅图像显示了 ISV 数据位置（查询位置），然后存储资源管理器如何向下钻取到需要从存储中删除的文件或 Blob，以符合 SAR 请求。

此查询确认正在使用的存储帐户。 可以使用 Resource Graph Explorer (Kusto) 或 PowerShell 查询和删除存储、blob 和/或文件， (请参阅以下) 。

上图显示了在客户端的 Blob 容器中找到的数据，这些数据需要删除，下面显示了删除或软删除 Blob 中信息的操作。

控制 17：提供隐私声明的链接，其中应包含所有必需的元素，如下所示：

• 公司详细信息 (名称、地址等。) 。

• 详细说明要处理的个人数据的类型。

• 详细说明处理个人数据的合法性。

• 详细信息数据主体的权利：

  • 知情权，
  • 数据主体的访问权限，
  • 擦除权，
  • 限制处理的权利，
  • 数据可移植性权限，
  • 对象权限，
  • 与自动决策（包括分析）相关的权利。

• 详细说明个人数据将保留多长时间。

• 意向：GDPR 第 13 条包括获取个人数据时必须提供给数据主体的特定信息。 此控制的目的是确保组织数据隐私声明向数据主体提供第 13 条中包含的一些关键信息。

• 示例证据指南：这通常通过提供数据隐私声明来提供。 认证分析师将对此进行审查，以确保在控制范围内提供的所有信息都包含在数据隐私声明中。

• 示例证据

以上和相邻隐私声明的图像显示了包含 GDPR 第 13 条的在线隐私策略示例。

下面是可与前面显示的隐私声明结合使用的数据保护策略。

上图显示了如何配置 Azure 以满足 GDPR 对后端环境中存储的数据的合规性要求。 ISV 可以通过 Azure 蓝图) 自定义或构建的策略 (，可以确保客户端数据正确存储，并且只有设置的指标和警报才能访问它，以确保合规性，并在合规性管理器仪表板上显示不合规的数据或用户访问权限。

书籍

Murdoch D. (2018) Blue Team 手册：事件响应版：网络安全事件响应者的精简现场指南。 第 2 版，发布者：CreateSpace Independent Publishing Platform。

参考

• 行动欺诈网络犯罪报告提供于： https://www.actionfraud.police.uk/ (于 08/02/21) 访问。
• 欧盟。 (2021) 适用于数据控制器的 GDPR 清单，请参阅： https://gdpr.eu/checklist/ (于) 01/02/21 访问。
• Microsoft. (2018) 事件日志记录 (Windows Installer) 的可用位置： 事件日志记录 (Windows Installer) (访问时间：) 23/12/20。
• 积极技术。 (2020) 如何实现安全软件开发，请参阅： https://www.ptsecurity.com/ww-en/analytics/knowledge-base/how-to-approach-secure-software-development/ (访问时间：) 21/12/20。
• ) 2016 年 4 月 27 日欧洲议会和欧盟理事会第 2016/679 号欧盟第 2016/679 号条例 (条例，关于在处理个人数据和此类数据自由移动方面保护自然人，以及废除指令 95/46/EC (2016 年 2016 年 4 月 27 日与欧洲经济区相关的一般数据保护条例) () (文本) ，请参阅： https://www.legislation.gov.uk/eur/2016/679/contents (访问时间：2021/11/01) 。
• 安全指标。 (2020) PCI DSS 合规性安全指标指南。 可用时间： https://info.securitymetrics.com/pci-guide-2020 (访问时间：) 01/06/21。
• 威廉姆斯 J. OWASP 风险排名发布时间： https://owasp.org/www-community/OWASP_Risk_Rating_Methodology (访问时间： 08/12/20) .
• 夸利斯 (2014) SSL 实验室：信任 (T) 的新级别和不匹配 (M) 问题，网址为： https://blog.qualys.com/product-tech/2014/06/17/ssl-labs-new-grades-for-trust-t-and-mismatch-m-issues (访问时间：) 29/01/21) 。
• NIST SP800-61r2：计算机安全事件处理指南，请参阅：https://csrc.nist.gov/publications/detail/sp/800-61/rev-2/final (于) 24/01/21 访问。

从Microsoft文档拍摄的图像

• https://www.sans.org/information-security-policy/ (于 18/02/21) 访问。 ) 16/02/21 访问行为 分析和异常检测 (。 在 什么是 Azure Monitor 警报？ (访问日期为 17/02/21) 。 ) 22/02/21 访问 行为分析和异常检测 (。 在 21) 24/02/02 访问 Microsoft Defender for Cloud 中的安全警报 (。 在 21) 24/02/02 访问 Microsoft Defender for Cloud 中的安全警报 (。
• https://microsoft.github.io/AzureTipsAndTricks/blog/tip272.html在“为 Azure SQL 数据库配置高级威胁防护”中的 SQL 数据库、SQL 托管实例和 Azure Synapse Analytics 的透明数据加密：在为 Azure SQL 数据库配置高级威胁防护中创建策略分配以识别不合规的资源