安全域：操作安全性
操作安全域确保 ISV 实施一组强大的安全缓解技术，以抵御来自威胁参与者的无数威胁。 这旨在保护操作环境和软件开发过程，以构建安全的环境。
认知培训
安全意识培训对组织非常重要，因为它有助于将人为错误产生的风险降到最低，而人为错误涉及 90% 以上的安全漏洞。 它可帮助员工了解安全措施和过程的重要性。 提供安全意识培训时，它强化了安全意识文化的重要性，在这种文化中，用户知道如何识别和响应潜在威胁。 有效的安全意识培训计划应包括涵盖用户可能面临的各种主题和威胁的内容，例如社会工程、密码管理、隐私和物理安全。
控制编号 1
请提供以下证据：
该组织为信息系统用户提供既定的安全意识培训， (包括经理、高级管理人员和承包商，) ：
作为新用户初始培训的一部分。
当信息系统需要更改时。
组织定义的意识培训频率。
记录和监视单个信息系统安全意识活动，并保留组织定义频率的单个培训记录。
意向：培训新用户
此子点侧重于建立一个强制性的安全意识培训计划，该计划专为所有员工和加入组织的新员工设计，无论其角色如何。 这包括经理、高级管理人员和承包商。 安全意识计划应包括一个全面的课程，旨在传授有关组织的信息安全协议、策略和最佳做法的基础知识，以确保组织的所有成员都与一组统一的安全标准保持一致，从而创建弹性信息安全环境。
指南：新用户培训
大多数组织将结合基于平台的安全意识培训和管理文档（如策略文档和记录）来跟踪整个组织所有员工的培训完成情况。 提供的证据必须表明员工已完成培训，并且应通过概述安全意识要求的支持策略/过程来备份培训。
示例证据：新用户培训
以下屏幕截图显示了用于跟踪新员工的加入的 Confluence 平台。 为新员工提出了 JIRA 票证，包括他们的分配、角色、部门等。通过新的初学者流程，安全意识培训已选择并分配给需要在 2023 年 2 月 28日 截止日期前完成的员工。
屏幕截图显示了在员工成功完成安全意识培训后，Knowb4 生成的完成证书。 完成日期为 2023 年 2 月 21日 ，即在分配的时间段内。
意向：信息系统更改。
此子点的目的是确保每当组织的信息系统发生重大更改时，就启动自适应安全意识培训。 由于软件更新、体系结构更改或新的法规要求，可能会发生这些修改。 更新的培训课程可确保所有员工了解新的更改以及由此产生的对安全措施的影响，使他们能够相应地调整其操作和决策。 这种主动方法对于保护组织的数字资产免受系统更改可能引发的漏洞至关重要。
指南：信息系统更改。
大多数组织将结合使用基于平台的安全意识培训以及策略文档和记录等管理文档来跟踪所有员工培训的完成情况。 提供的证据必须证明，各种员工已根据对组织系统的不同更改完成了培训。
示例证据：信息系统更改。
接下来的屏幕截图显示了向各种员工分配安全意识培训，并演示了网络钓鱼模拟的发生。
每当发生系统更改或测试失败时，平台都用于分配新的训练。
意向：意识培训的频率。
此子点的目的是为定期安全意识培训定义特定于组织的频率。 这可以按年、每半年或组织确定的不同间隔进行计划。 通过设置频率，组织可确保用户定期更新不断变化的威胁环境，以及新的保护措施和策略。 此方法有助于在所有用户中保持高级别的安全意识，并强化以前的培训组件。
指南：意识培训的频率。
大多数组织都有管理文档和/或技术解决方案来概述/实施安全意识培训的要求和过程，并定义培训的频率。 提供的证据应表明在定义的期间内完成了各种意识培训，并且组织存在定义的时间段。
示例证据：认知培训的频率。
以下屏幕截图显示了安全意识策略文档的快照，以及它存在和维护。 该策略要求组织的所有员工都接受安全意识培训，如策略的范围部分所述。 培训必须由有关部门每年分配并完成。
根据政策文件，组织的所有员工必须完成三个课程， (一次培训和两次评估，每年) ，并在分配后的20天内完成。 课程必须通过电子邮件发送，并通过 KnowBe4 分配。
提供的示例仅显示策略的快照，请注意，预期是将提交完整的策略文档。
第二个屏幕截图是策略的延续，它显示了文档中强制要求年度培训要求的部分，并演示了组织定义的意识培训频率设置为每年。
接下来的两个屏幕截图演示了成功完成前面提到的训练评估。 屏幕截图来自两个不同的员工。
意向：文档和监视。
此子点的目的是创建、维护和监视每个用户参与安全意识培训的细致记录。 这些记录应在组织定义的时间段内保留。 本文档用作符合法规和内部策略的可审核线索。 监视组件允许组织评估
培训，确定需要改进的领域并了解用户参与度。 通过在定义的时间段内保留这些记录，组织可以跟踪长期有效性和合规性。
指南：文档和监视。
可为安全意识培训提供的证据将取决于如何在组织级别实施培训。 这可以包括训练是通过平台进行的，还是基于内部过程在内部执行。 提供的证据必须表明，存在一段时间内所有用户完成的训练的历史记录以及如何跟踪这些数据。
示例证据：文档和监视。
下一个屏幕截图显示每个用户的历史训练记录，包括其加入日期、训练完成时间以及计划下一次训练的时间。 此文档的评估定期执行，每年至少执行一次，以确保每个员工的安全意识培训记录保持最新。
恶意软件保护/反恶意软件
恶意软件对组织构成重大风险，组织可能会因恶意软件特征而异对操作环境造成的安全影响。 威胁参与者已经意识到恶意软件可以成功盈利，这已通过勒索软件样式恶意软件攻击的增长来实现。 恶意软件还可用于提供入口点，使威胁参与者入侵环境以窃取敏感数据，即远程访问特洛伊木马/Rootkit。 因此，组织需要实施适当的机制来防范这些威胁。 可以使用的防御措施是防病毒 (AV) /Endpoint Detection and Response (EDR) /Endpoint Detection and Protection Response (EDPR) /Heuristic 扫描使用人工智能 (AI) 。 如果已部署其他技术来降低恶意软件的风险，请让认证分析师知道谁愿意了解这是否符合此意图。
控制编号 2
请提供证据，证明反恶意软件解决方案处于活动状态，并且已跨所有采样系统组件启用，并配置为满足以下条件：
如果启用了访问扫描的防病毒，并且签名在 1 天内处于最新状态，则为 。
用于在检测到恶意软件时自动阻止恶意软件或警报和隔离的防病毒
或如果 EDR/EDPR/NGAV：
正在执行定期扫描。
正在生成审核日志。
持续保持最新状态，并具有自学功能。
它阻止已知的恶意软件，并根据宏行为识别和阻止新的恶意软件变体，并具有完全的允许功能。
意向：按访问扫描
此子点旨在验证是否在所有采样系统组件中安装了反恶意软件，并主动执行访问时扫描。 该控件还要求反恶意软件解决方案的签名数据库在一天内处于最新状态。 最新的签名数据库对于识别和缓解最新的恶意软件威胁至关重要，从而确保系统组件受到充分保护。
准则：按访问扫描**.**
若要演示 AV 的活动实例是否在评估环境中运行，请为与分析师同意使用反恶意软件的示例集中的每个设备提供屏幕截图。 屏幕截图应显示反恶意软件正在运行，并且反恶意软件处于活动状态。 如果有用于反恶意软件的集中式管理控制台，可能会提供来自管理控制台的证据。 此外，请确保提供屏幕截图，显示采样设备已连接并正常工作。
示例证据：按访问扫描**.**
以下屏幕截图取自 Windows Server 设备，显示已为主机名“IaaS-Web-app”启用了“Microsoft Defender”。
下一个屏幕截图是从 Windows Server 设备拍摄的，其中显示Microsoft Defender 反恶意软件安全智能版本已从 Windows 事件查看器更新日志。 这演示了主机名“IaaS-Web-app”的最新签名。
此屏幕截图取自 Windows Server 设备，其中显示了Microsoft Defender 反恶意软件保护更新。 这清楚地显示了威胁定义版本、创建版本和上次更新，以证明恶意软件定义是主机名“IaaS-Web- app”的最新版本。
意向：反恶意软件块。
此子点的目的是确认反恶意软件配置为在检测到时自动阻止恶意软件或生成警报，并将检测到的恶意软件移动到安全隔离区域。 这可以确保在检测到威胁时立即采取措施，减少漏洞窗口，并维护系统的强安全态势。
指南：反恶意软件阻止。
为示例中支持使用反恶意软件的每个设备提供屏幕截图。 屏幕截图应显示反恶意软件正在运行，并且配置为自动阻止恶意软件、警报或隔离和警报。
示例证据：反恶意软件块。
下一个屏幕截图显示主机“IaaS-Web-app”配置了针对 Microsoft Defender 反恶意软件的实时保护作为 ON。 如设置所示，这会查找并阻止恶意软件在设备上安装或运行。
意向：EDR/NGAV
此子点旨在验证终结点检测和响应 (EDR) 或下一代防病毒 (NGAV) 是否正在对所有采样系统组件主动执行定期扫描;生成审核日志以跟踪扫描活动和结果;扫描解决方案会不断更新，并具有自学功能，以适应新的威胁环境。
指南：EDR/NGAV
提供 EDR/NGAV 解决方案的屏幕截图，演示来自采样系统的所有代理都在中报告，并显示其状态为活动状态。
示例证据：EDR/NGAV
OpenEDR 解决方案的下一个屏幕截图显示主机“IaaS-Web-app”的代理处于活动状态，并在其中进行报告。
OpenEDR 解决方案的下一个屏幕截图显示已启用实时扫描。
下一张屏幕截图显示，警报是基于从系统级别安装的代理实时获取的行为指标生成的。
OpenEDR 解决方案的后续屏幕截图演示了审核日志和警报的配置和生成。 第二个图像显示已启用策略，并配置了事件。
OpenEDR 解决方案的下一个屏幕截图演示了解决方案持续保持最新状态。
意向：EDR/NGAV
此子点的重点是确保 EDR/NGAV 能够自动阻止已知恶意软件，并根据宏行为识别和阻止新的恶意软件变体。 它还可确保解决方案具有完全的审批功能，允许组织允许受信任的软件，同时阻止所有其他软件，从而添加额外的安全层。
指南：EDR/NGAV
根据使用的解决方案类型，可以提供证据，显示解决方案的配置设置，以及解决方案具有机器学习/启发功能，以及配置为在检测到时阻止恶意软件。 如果默认在解决方案上实现配置，则必须通过供应商文档对此进行验证。
示例证据：EDR/NGAV
OpenEDR 解决方案的后续屏幕截图演示了安全配置文件 v7.4 配置为强制实施实时扫描、阻止恶意软件和隔离。
安全配置文件 v7.4 配置的下一个屏幕截图表明，该解决方案基于更传统的反恶意软件方法实现“实时”扫描，该方法扫描已知恶意软件签名，并将“启发式”扫描设置为中等级别。 该解决方案通过检查以可疑/意外或恶意方式运行的文件和代码来检测和删除恶意软件。
扫描程序配置为解压缩存档并扫描内部文件，以检测可能在存档下屏蔽自身的潜在恶意软件。此外，扫描程序配置为阻止Microsoft Office 文件中的微脚本。
接下来的屏幕截图演示安全配置文件 v.7.4 已分配给 Windows Server 设备“IaaS-Web-app”主机。
下一张屏幕截图取自 Windows Server 设备“IaaS-Web-app”，其中演示了 OpenEDR 代理已启用并在主机上运行。
恶意软件保护/应用程序控制
应用程序控制是一种安全做法，可阻止或限制未经授权的应用程序以将数据置于危险之中的方式执行。 应用程序控制是公司安全计划的重要组成部分，可帮助防止恶意参与者利用应用程序漏洞并降低违规风险。 通过实施应用程序控制，企业和组织可以大大降低与应用程序使用相关的风险和威胁，因为如果应用程序将网络或敏感数据置于危险之中，应用程序将无法执行。 应用程序控制为运营和安全团队提供了一种可靠、标准化和系统的方法来缓解网络风险。 它们还可以让组织更全面地了解其环境中的应用程序，从而帮助 IT 和安全组织有效地管理网络风险。
控制措施 3
请提供证据，证明：
你有一个已批准的软件/应用程序列表，其中包含业务理由：
存在并保持最新状态，并且
每个应用程序在部署之前都经过审批过程并注销。
该应用程序控制技术在记录的所有采样系统组件中处于活动状态、已启用和配置。
意向：软件列表
此子点旨在确保组织中存在已批准的软件和应用程序列表，并持续保持最新状态。 确保列表中的每个软件或应用程序都有记录的业务理由来验证其必要性。 此列表用作规范软件和应用程序部署的权威参考，从而有助于消除可能构成安全风险的未授权或冗余软件。
指南：软件列表
包含已批准软件和应用程序列表的文档（如果作为数字文档 (Word、PDF 等 ) 维护）。 如果通过平台维护已批准的软件和应用程序列表，则必须提供平台中列表的屏幕截图。
示例证据：软件列表
接下来的屏幕截图演示了在 Confluence Cloud 平台中维护已批准的软件和应用程序列表。
接下来的屏幕截图演示了已批准的软件和应用程序的列表，包括请求者、请求日期、审批者、批准日期、控制机制、JIRA 票证、系统/资产。
意向：软件审批
此子点的目的是确认每个软件/应用程序在组织内部署之前都经过正式的审批过程。 审批过程应包括技术评估和高管签核，确保已考虑运营和战略观点。 通过建立这一严格的流程，组织可确保仅部署经过审查和必要的软件，从而最大程度地减少安全漏洞并确保与业务目标保持一致。
准则
可以提供证明正在遵循审批过程的证据。 这可以通过签名文档、在更改控制系统中进行跟踪或使用 Azure DevOps/JIRA 等方法来跟踪更改请求和授权。
示例证据
接下来的屏幕截图演示了 JIRA Software 中的完整审批过程。 用户“Jane Doe”提出了“允许 Qualys 云代理”安装在“IaaS-Web-app”和“IaaS-VM-Backend”服务器上的请求。 “Andrew Smith”已审查了请求，并批准了该请求，并评论为“根据反恶意软件的业务需求批准”。 Qualys 提供的更新和修补程序。 要批准的软件。
下一个屏幕截图显示了在允许应用程序在生产服务器上运行之前，通过 Confluence 平台上引发的票证授予审批。
意向：应用控制技术
此子点侧重于验证应用程序控制技术是否处于活动状态、已启用并已跨所有采样系统组件正确配置。 确保技术按照记录的策略和过程运行，这些策略和过程是实施和维护的指南。 通过具有活动、已启用和配置良好的应用程序控制技术，组织可以帮助防止执行未经授权的或恶意软件，并增强系统的整体安全态势。
指南：应用控制技术
提供详细说明如何设置应用程序控制的文档，以及来自适用技术的证据，说明如何配置每个应用程序/进程。
示例证据：应用控制技术
接下来的屏幕截图演示 Windows 组策略 (GPO) 配置为仅强制实施批准的软件和应用程序。
下一个屏幕截图显示允许通过路径控制运行的软件/应用程序。
注意：这些示例中未使用完整屏幕截图，但所有 ISV 提交的证据屏幕截图必须是显示任何 URL、登录用户以及系统时间和日期的全屏屏幕截图。
修补程序管理/修补和风险排名
修补程序管理（通常称为修补）是任何可靠的网络安全策略的关键组件。 它涉及对软件、操作系统和应用程序进行标识、测试和应用修补程序或更新的系统过程。 修补程序管理的主要目标是缓解安全漏洞，确保系统和软件能够抵御潜在威胁。 此外，修补程序管理包括风险排名是确定修补程序优先级的重要因素。 这包括根据漏洞的严重性和对组织安全状况的潜在影响来评估漏洞。 通过将风险分数分配给漏洞，组织可以有效地分配资源，集中精力及时解决关键和高风险漏洞，同时对新出现的威胁保持主动立场。 有效的补丁管理和风险排名策略不仅增强了安全性，而且有助于 IT 基础结构的整体稳定性和性能，帮助组织在不断变化的网络安全威胁环境中保持复原能力。
为了维护安全的操作环境，必须适当地修补应用程序/加载项和支持系统。 需要管理标识 (或公开发布) 与修补之间的适当时间范围，以减少威胁参与者利用漏洞的机会窗口。 Microsoft 365 认证未规定“修补窗口”：但是，认证分析师将拒绝不合理或不符合行业最佳做法的时间范围。 此安全控制组还适用于平台即服务 (PaaS) 托管环境，因为必须基于风险排名修补应用程序/外接程序第三方软件库和代码库。
控制措施 4
提供修补程序管理策略和过程文档定义以下所有内容的证据：
适用于严重/高风险和中等风险漏洞的最小修补窗口。
解除不受支持的操作系统和软件的授权。
如何识别和分配新的安全漏洞风险评分。
意向：修补程序管理
许多安全合规性框架（例如 PCI-DSS、ISO 27001、NIST (SP) 800-53、FedRAMP 和 SOC 2）都需要修补程序管理。 良好的补丁管理的重要性不能过分强调
因为它可以纠正软件、固件中的安全和功能问题，并缓解漏洞，有助于减少利用的机会。 此控制的目的是最大程度地减少威胁参与者利用范围内环境中可能存在的漏洞的机会。
提供全面涵盖以下方面的修补程序管理策略和过程文档：
适用于严重/高风险和中等风险漏洞的最小修补窗口。
组织的修补程序管理策略和过程文档必须为分类为严重/高风险和中等风险的漏洞明确定义适当的最小修补窗口。 此类规定根据漏洞的风险级别确定在识别漏洞后必须应用修补程序的最大允许时间。 通过明确说明这些时间范围，组织标准化了修补管理方法，最大程度地降低了与未修补漏洞相关的风险。
解除不受支持的操作系统和软件的授权。
修补程序管理策略包括有关解除不受支持的操作系统和软件的授权的预配。 不再接收安全更新的操作系统和软件对组织的安全状况构成重大风险。 因此，此控制可确保按照策略文档中的定义及时识别和删除或替换此类系统。
- 概述如何识别新安全漏洞并为其分配风险评分的文档过程。
修补需要基于风险，漏洞风险越高，需要修正的越快。 识别的漏洞的风险排名是此过程不可或缺的一部分。 此控制的目的是确保遵循记录的风险排名过程，以确保根据风险适当地排名所有已识别的漏洞。 组织通常利用供应商或安全研究人员提供的常见漏洞评分系统 (CVSS) 评级。 如果组织依赖于 CVSS，建议在流程中包含重新排名机制，以允许组织根据内部风险评估更改排名。 有时，由于应用程序在环境中部署的方式，该漏洞可能不适用。 例如，可能会释放一个 Java 漏洞，这会影响组织不使用的特定库。
注意：即使在纯平台即服务“PaaS/无服务器”环境中运行，你仍有责任识别代码库中的漏洞：即第三方库。
指南：修补程序管理
提供策略文档。 必须提供管理证据，例如详细说明组织定义流程的策略和过程文档，这些流程涵盖给定控制的所有元素。
注意：逻辑证据可以作为支持证据提供，这将进一步洞察组织的漏洞管理计划 (VMP) ，但它本身不会满足此控制要求。
示例证据：修补程序管理
下一个屏幕截图显示了修补程序管理/风险排名策略的代码片段，以及不同级别的风险类别。 然后是分类和修正时间范围。 请注意：期望 ISV 共享实际的支持策略/过程文档，而不只是提供屏幕截图。
(可选) 支持策略文档的其他技术证据的示例
逻辑证据，例如漏洞跟踪电子表格、漏洞技术评估报告或通过联机管理平台引发的票证的屏幕截图，用于跟踪用于支持要提供的策略文档中概述的过程实现的漏洞的状态和进度。 下一个屏幕截图演示了 Snyk（软件组合分析 (SCA) 工具）用于扫描代码库的漏洞。 随后是通过电子邮件发送的通知。
请注意：在本示例中，未使用完整屏幕截图，但所有 ISV 提交的证据屏幕截图必须是显示任何 URL、登录用户以及系统时间和日期的完整屏幕截图。
接下来的两个屏幕截图显示了 Snyk 标记新漏洞时收到的电子邮件通知的示例。 我们可以看到电子邮件包含受影响的项目和分配的接收警报的用户。
以下屏幕截图显示了标识的漏洞。
请注意：在前面的示例中，未使用完整屏幕截图，但所有 ISV 提交的证据屏幕截图必须是显示 URL、任何登录用户和系统时间和日期的完整屏幕截图。
示例证据
接下来的屏幕截图显示了配置并启用的 GitHub 安全工具，以扫描代码库中的漏洞，并通过电子邮件发送警报。
接下来显示的电子邮件通知是确认标记的问题将通过拉取请求自动解决。
示例证据
下一个屏幕截图显示通过电子表格对漏洞进行内部技术评估和排名。
示例证据
接下来的屏幕截图显示 DevOps 中针对已发现的每个漏洞提出的票证。
在实施更改之前，由单独的员工进行评估、排名和评审。
控制措施 5
提供可证明的证据，证明：
正在修补所有采样的系统组件。
提供未使用不支持的操作系统和软件组件的证据。
意向：采样的系统组件
此子点旨在确保提供可验证的证据，以确认组织内的所有采样系统组件正在积极修补。 证据可能包括但不限于修补程序管理日志、系统审核报告或显示已应用修补程序的文档过程。 如果使用无服务器技术或平台即服务 (PaaS) ，则应扩展为包含代码库，以确认正在使用最新版本的库和依赖项。
指南：采样系统组件
提供示例和支持软件组件中每个设备的屏幕截图，显示修补程序按照记录的修补过程安装。 此外，提供演示基本代码修补的屏幕截图。
示例证据：采样的系统组件
下一张屏幕截图演示了 Linux 操作系统虚拟机“IaaS- VM-Backend”的修补。
示例证据
下一个屏幕截图演示了如何修补 Windows 操作系统虚拟机“IaaS-Web-app”。
示例证据
如果要从任何其他工具（如 Microsoft Intune、Defender for Cloud 等）维护修补，则可以从这些工具提供屏幕截图。 OpenEDR 解决方案的后续屏幕截图演示了通过 OpenEDR 门户执行的修补程序管理。
下一个屏幕截图演示了通过 OpenEDR 平台对作用域内服务器的修补程序管理。 分类和状态显示在下面，演示发生了修补。
下一个屏幕截图显示为服务器上成功安装的修补程序生成了日志。
示例证据
下一个屏幕截图演示了通过 Azure DevOps 修补代码库/第三方库依赖项。
下一张屏幕截图显示，正在将 Snyk 发现的漏洞修复提交到分支，以解决过时的库。
下一个屏幕截图演示了库已升级到受支持的版本。
示例证据
接下来的屏幕截图演示了通过 GitHub Dependabot 维护代码库修补。 已关闭的项演示了修补，并且漏洞已解决。
意向：不支持的 OS
未由供应商维护的软件在加班后将遭受未修复的已知漏洞。 因此，不得在生产环境中使用不受支持的操作系统和软件组件。 部署基础结构即服务 (IaaS) 时，此子点的要求将扩展为包括基础结构和代码库，以确保技术堆栈的每一层都符合组织关于使用受支持软件的策略。
指南：不支持的 OS
为分析师选择的示例集中的每个设备提供屏幕截图，以便收集证据，防止显示运行的 OS 版本 (在屏幕截图) 中包含设备/服务器的名称。 此外，请提供证据，证明环境中运行的软件组件正在运行受支持的软件版本。 为此，可以提供内部漏洞扫描报告的输出， (提供经过身份验证的扫描) 和/或检查第三方库（如 Snyk、Trivy 或 NPM 审核）的工具的输出。 如果在 PaaS 中运行，则只需要涵盖第三方库修补。
示例证据：不支持的 OS
Azure DevOps NPM 审核的下一个屏幕截图显示，Web 应用中没有使用不受支持的库/依赖项。
注意：在下一个示例中，未使用完整屏幕截图，但所有 ISV 提交的证据屏幕截图必须是显示 URL、任何登录用户和系统时间和日期的完整屏幕截图。
示例证据
GitHub Dependabot 的下一个屏幕截图演示了 Web 应用中未使用任何库/依赖项。
示例证据
通过 OpenEDR 从 Windows 操作系统的软件清单中获取的下一个屏幕截图表明，未找到不受支持的或过时的操作系统和软件版本。
示例证据
下一张屏幕截图来自“OS 摘要”下的 OpenEDR，其中显示了 Windows Server 2019 Datacenter (x64) 和 OS 完整版本历史记录，包括 Service Pack、内部版本等... 验证未找到不受支持的操作系统。
示例证据
Linux 操作系统服务器的下一个屏幕截图演示了所有版本详细信息，包括分发服务器 ID、说明、版本和验证未找到不受支持的 Linux 操作系统的 Codename。
示例证据：
Nessus 漏洞扫描报告的下一个屏幕截图显示，目标计算机上未找到不支持的操作系统 (操作系统) 和软件。
请注意：在前面的示例中，未使用完整屏幕截图，但所有 ISV 提交的证据屏幕截图都必须是显示 URL、任何登录用户和系统时间和日期的完整屏幕截图。
漏洞扫描
漏洞扫描会查找组织计算机系统、网络和 Web 应用程序中可能存在的弱点，以识别可能导致安全漏洞和敏感数据泄露的漏洞。 行业标准和政府法规通常要求漏洞扫描，例如 PCI DSS (支付卡行业数据安全标准) 。
安全指标的一份题为“PCI DSS 合规性 2020 年安全指标指南”的报告指出，“从组织发现攻击者入侵系统漏洞开始，平均耗时 166 天。 一旦遭到入侵，攻击者平均可以访问敏感数据 127 天，因此此控制措施旨在识别范围内环境中的潜在安全漏洞。
通过引入定期漏洞评估，组织可以检测其环境中的弱点和不安全之处，这可能为恶意参与者提供入侵环境的入口点。 漏洞扫描有助于识别环境中缺少的修补程序或错误配置。 通过定期执行这些扫描，组织可以提供适当的补救措施，以最大程度地降低由于这些漏洞扫描工具通常发现的问题而导致的泄露风险。
控制措施 6
请提供证据，证明：
每季度进行基础结构和 Web 应用程序漏洞扫描。
如果环境为 IaaS、混合或本地，则需要针对整个公共占用空间 (IP/URL) 和内部 IP 范围执行扫描。
注意：这必须包括环境的全部范围。
意向：漏洞扫描
此控制旨在确保组织每季度针对其基础结构和 Web 应用程序进行漏洞扫描。 扫描必须全面，涵盖公共占用空间（如公共 IP 和 URL）以及内部 IP 范围。 扫描范围因组织基础结构的性质而异：
如果组织实现混合、本地或基础结构即服务 (IaaS) 模型，则扫描必须同时包含外部公共 IP/URL 和内部 IP 范围。
如果组织实现平台即服务 (PaaS) ，则扫描必须仅包含外部公共 IP/URL。
此控制还要求扫描应包括环境的全部范围，因此不会使任何组件处于未选中状态。 目标是识别和评估组织技术堆栈所有部分的漏洞，以确保全面的安全性。
指南：漏洞扫描
提供过去 12 个月中每个季度的漏洞扫描 () 的完整扫描报告。 报告应明确说明目标，以验证是否包括完整的公共占用空间，以及每个内部子网（如果适用）。 提供每个季度的所有扫描报告。
示例证据：漏洞扫描
下一个屏幕截图显示网络发现和通过 Nmap 在外部基础结构上执行的端口扫描，以识别任何不安全的开放端口。
注意：Nmap 本身无法用于满足此控制要求，因为预期必须提供完整的漏洞扫描。 Nmap 端口发现是漏洞管理过程的一部分，如下所示，并辅之以针对外部基础结构的 OpenVAS 和 OWASP ZAP 扫描。
屏幕截图显示了通过 OpenVAS 针对外部基础结构的漏洞扫描，以识别任何错误配置和未解决的漏洞。
下一个屏幕截图显示了 OWASP ZAP 的漏洞扫描报告，其中演示了动态应用程序安全测试。
示例证据：漏洞扫描
以下来自 Nessus Essentials 漏洞扫描报告的屏幕截图演示了执行内部基础结构扫描。
前面的屏幕截图演示了针对主机 VM 进行季度扫描的文件夹设置。
上面和下面的屏幕截图显示了漏洞扫描报告的输出。
下一个屏幕截图显示了涵盖发现的所有问题的报表的延续。
控制措施 7
请提供重新扫描证据，证明：
- 对控制 6 中标识的所有漏洞的修正都按照策略中定义的最小修补窗口进行修补。
意向：修补
如果无法快速识别、管理和修正漏洞和错误配置，则可能会增加组织的泄露风险，从而导致潜在的数据泄露。 正确识别和修正问题对于组织的整体安全态势和环境非常重要，这符合各种安全框架（例如 ISO 27001 和 PCI DSS）的最佳做法。
此控制的目的是确保组织提供可信的重新扫描证据，证明控制措施 6 中确定的所有漏洞都已得到修正。 修正必须与组织修补程序管理策略中定义的最小修补时段保持一致。
指南：修补
提供重新扫描报告，以验证控制 6 中标识的任何漏洞是否已按照控制 4 中定义的修补窗口进行修正。
示例证据：修补
下一张屏幕截图显示本示例中名为 Thor 的单个计算机 (范围内环境的 Nessus 扫描) ，其中显示了 2023 年 8 月 2日的漏洞。
下一张屏幕截图显示问题已解决，2 天后，该问题在修补策略中定义的修补窗口中。
注意：在前面的示例中，未使用完整的屏幕截图，但已提交所有 ISV
证据屏幕截图必须是显示任何 URL、登录用户以及系统时间和日期的完整屏幕截图。
网络安全控制 (NSC)
网络安全控制是网络安全框架（如 ISO 27001、CIS 控制和 NIST 网络安全框架）的重要组成部分。 它们可帮助组织管理与网络威胁相关的风险，保护敏感数据免受未经授权的访问，遵守法规要求，及时检测和响应网络威胁，并确保业务连续性。 有效的网络安全保护组织资产免受来自组织内部或外部的各种威胁。
控制措施 8
提供可证明的证据，证明：
- 网络安全控制 (NSC) 安装在范围内环境的边界上，并在外围网络与内部网络之间安装。
如果混合、本地、IaaS 还提供证据来证明：
- 所有公共访问在外围网络终止。
意向：NSC
此控制旨在确认网络安全控制 (NSC) 安装在组织网络拓扑内的关键位置。 具体而言，必须将 NSC 放置在作用域内环境的边界以及外围网络与内部网络之间。 此控制的目的是确认这些安全机制的位置是否正确，以最大程度地提高其保护组织的数字资产的有效性。
准则：NSC
应提供证据来证明网络安全控制 (NSC) 安装在边界上并在外围网络和内部网络之间配置。 为此，可以提供来自 NSC) 网络安全控制 (配置设置的屏幕截图，以及应用于防火墙或等效技术（例如 Azure 网络安全组 (NSG) 、Azure Front Door 等）的范围。
示例证据：NSC
下一个屏幕截图来自 Web 应用“PaaS-web-app”;网络边栏选项卡演示所有入站流量都通过 Azure Front Door，而从应用程序到其他 Azure 资源的所有流量都通过 VNET 集成通过 Azure NSG 进行路由和筛选。
“访问限制”中的拒绝规则阻止除 Front Door (FD) 之外的任何入站，流量在到达应用程序之前通过 FD 进行路由。
示例证据：NSC
以下屏幕截图显示了 Azure Front Door 的默认路由，并在到达应用程序之前通过 Front Door 路由流量。 还应用了 WAF 策略。
示例证据：NSC
第一张屏幕截图显示了在 VNET 级别应用的 Azure 网络安全组，用于筛选入站和出站流量。 第二张屏幕截图演示 SQL Server 无法通过 Internet 进行路由，并且通过 VNET 和专用链接集成。
这可确保在到达 SQL 服务器之前，NSG 筛选内部流量和通信。
意向**:** 混合、本地、IaaS
对于运行混合、本地或基础结构即服务 (IaaS) 模型的组织来说，此子点至关重要。 它旨在确保所有公共访问在外围网络终止，这对于控制进入内部网络的入口点和减少潜在外部威胁风险至关重要。 合规性证据可能包括防火墙配置、网络访问控制列表或其他类似文档，这些文档可以证实公共访问不会超出外围网络的说法。
示例证据：混合、本地、IaaS
屏幕截图演示了 SQL Server 无法通过 Internet 进行路由，并且它通过 VNET 和专用链接集成。 这可确保仅允许内部流量。
示例证据：混合、本地、IaaS
接下来的屏幕截图演示了网络分段在范围内虚拟网络中已到位。 如下所示，VNET 分为三个子网，每个子网都应用了 NSG。
公共子网充当外围网络。 所有公共流量都通过此子网路由，并通过 NSG 使用特定规则进行筛选，并且仅允许显式定义的流量。 后端由没有公共访问权限的专用子网组成。 所有 VM 访问仅允许通过 Bastion 主机进行，该主机在子网级别应用了自己的 NSG。
下一张屏幕截图显示，仅允许流量从 Internet 到端口 443 上的特定 IP 地址。 此外，仅允许从 Bastion IP 范围到虚拟网络的 RDP。
下一张屏幕截图演示了后端无法通过 Internet 进行路由， (这是因为 NIC) 没有公共 IP，并且仅允许来自虚拟网络和 Bastion 的流量。
屏幕截图演示 Azure Bastion 主机用于访问虚拟机，仅用于维护目的。
控制编号 9
NSC) (所有网络安全控制都配置为删除未在规则库中显式定义的流量。
网络安全控制 (NSC) 规则评审至少每 6 个月进行一次。
意向：NSC
此子点可确保将组织中所有网络安全控制 (NSC) 配置为删除在其规则库中未显式定义的任何网络流量。 目标是在网络层强制实施最小特权原则，方法是仅允许授权流量，同时阻止所有未指定或潜在的恶意流量。
准则：NSC
为此提供的证据可能是显示入站规则以及这些规则终止位置的规则配置;通过将公共 IP 地址路由到资源，或者提供入站流量的 NAT (网络地址转换) 。
示例证据：NSC
屏幕截图显示了 NSG 配置，包括默认规则集和自定义 Deny：All 规则，用于重置所有 NSG 的默认规则并确保禁止所有流量。 在附加的自定义规则中， Deny：All 规则显式定义允许的流量。
示例证据：NSC
以下屏幕截图显示已部署 Azure Front Door，所有流量都通过 Front Door 路由。 应用“防护模式”中的 WAF 策略，该策略筛选入站流量以查找潜在的恶意有效负载并阻止它。
意向：NSC
如果没有定期评审， (NSC) 的网络安全控制可能会过时且无效，使组织容易受到网络攻击。 这可能会导致数据泄露、敏感信息被盗和其他网络安全事件。 定期 NSC 评审对于管理风险、保护敏感数据、遵守法规要求、及时检测和响应网络威胁以及确保业务连续性至关重要。 此子点要求网络安全控制 (NSC) 至少每六个月进行一次规则基础评审。 定期评审对于保持 NSC 配置的有效性和相关性至关重要，尤其是在动态变化的网络环境中。
准则：NSC
提供的任何证据都需要能够证明已召开规则评审会议。 这可以通过共享 NSC 评审的会议记录和任何其他更改控制证据来完成，这些证据显示从评审中采取的任何操作。 请确保日期存在，因为审核提交的认证分析师需要看到至少两个这些会议审查文件 (，即每六个月) 。
示例证据：NSC
这些屏幕截图演示了六个月的防火墙评审，详细信息在 Confluence Cloud 平台中维护。
下一个屏幕截图演示每个规则评审都有在 Confluence 中创建的页面。 规则评审包含已批准的规则集列表，其中概述了允许的流量、端口号、协议等以及业务理由。
示例证据：NSC
下一个屏幕截图演示了 DevOps 中维护的六个月规则评审的替代示例。
示例证据：NSC
此屏幕截图演示了在 DevOps 中执行并记录为票证的规则评审的示例。
上一个屏幕截图显示了已建立的记录规则列表以及业务理由，而下一张图像演示了实际系统中票证中规则的快照。
更改控件
建立和理解的变更控制过程对于确保所有更改都经过可重复的结构化过程至关重要。 通过确保所有更改都通过结构化过程，组织可以确保在签署之前有效地管理更改、同行评审和充分测试更改。 这不仅有助于最大程度地降低系统中断的风险，还有助于通过引入不当更改将潜在安全事件的风险降到最低。
控制编号 10
请提供证据，证明：
引入到生产环境的任何更改都是通过记录的更改请求实现的，这些请求包含：
更改的影响。
退出过程的详细信息。
要执行的测试。
由授权人员审查和批准。
意向：更改控制
此控件的目的是确保已仔细考虑和记录任何请求的更改。 这包括评估更改对系统/环境安全性的影响，记录任何回退过程以帮助在出现问题时进行恢复，并详细说明验证更改是否成功所需的测试。
必须实施禁止在没有适当授权和注销的情况下进行更改的过程。 在实施更改之前，需要对更改进行授权，并且需要在完成更改后进行签名。 这可确保已正确审查更改请求，并且授权人员已签署更改。
指南：更改控制
可以通过共享更改请求示例的屏幕截图来提供证据，这些屏幕截图显示更改的影响、回退过程、测试的详细信息保留在更改请求中。
示例证据：更改控制
下一个屏幕截图显示正在分配 (XSS) 的新跨站点脚本漏洞，以及更改请求的文档。 下面的票证演示在票证要解决的过程中已设置或添加到票证的信息。
下面的两个票证显示了更改对系统的影响，以及出现问题时可能需要的回退过程。 更改和回退过程的影响已经经历了审批过程，并已批准进行测试。
在以下屏幕截图中，更改的测试已获批准，在右侧，你会看到更改现已获得批准和测试。
在整个过程中，请注意，执行工作的人员、报告工作的人员以及批准要完成的工作的人员是不同的人。
下面的票证显示，现已批准对生产环境实施所做的更改。 右侧框显示测试成功且已成功，并且更改现已实现到 Prod 环境。
示例证据
接下来的屏幕截图显示了一个 Jira 票证示例，该票证显示更改需要经过授权，然后才能由开发人员/请求者以外的人员实施和批准。 这些更改由具有权限的人员批准。 屏幕截图的右侧显示，更改在完成后已由 DP 签名。
在票证中，更改完成后已签名，并显示作业已完成和关闭。
请注意： - 在这些示例中未使用完整屏幕截图，但所有 ISV 提交的证据屏幕截图必须是显示任何 URL、登录用户以及系统时间和日期的完整屏幕截图。
控制编号 11
请提供以下证据：
存在单独的环境，以便：
开发和测试/过渡环境强制将职责与生产环境分离。
通过访问控制强制实施职责分离。
在开发或测试/过渡环境中不使用敏感的生产数据。
意向：单独的环境
大多数组织的开发/测试环境未配置为与生产环境相同的活力，因此安全性较差。 此外，不应在生产环境中执行测试，因为这样做可能会带来安全问题，或者可能会损害客户的服务交付。 通过维护强制职责分离的独立环境，组织可以确保将更改应用于正确的环境，从而通过在用于开发/测试环境时对生产环境实施更改来降低错误风险。
应配置访问控制，以便负责开发和测试的人员对生产环境没有不必要的访问权限，反之亦然。 这可以最大程度地降低未经授权的更改或数据泄露的可能性。
在开发/测试环境中使用生产数据可能会增加泄露的风险，并使组织面临数据泄露或未经授权的访问。 该意向要求用于开发或测试的任何数据都应经过净化、匿名化或专门为此目的而生成。
指南：单独的环境
可以提供屏幕截图，演示用于开发/测试环境和生产环境的不同环境。 通常，你会有不同的人员/团队有权访问每个环境，或者如果无法执行此操作，则环境会利用不同的授权服务来确保用户不会错误地登录到错误的环境来应用更改。
示例证据：单独的环境
接下来的屏幕截图演示了开发/测试环境与生产环境分离，这是通过 Azure 中的资源组实现的，这是将资源逻辑分组到容器中的一种方法。 实现分离的其他方法可能是不同的 Azure 订阅、网络和子网等。
以下屏幕截图显示了开发环境和此资源组中的资源。
下一个屏幕截图显示生产环境和此资源组中的资源。
示例证据：
接下来的屏幕截图演示了开发/测试环境与生产环境分开。 环境充分分离是通过具有与每个环境关联的不同权限的不同用户/组来实现的。
下一个屏幕截图显示了开发环境和有权访问此资源组的用户。
下一个屏幕截图显示生产环境和用户 (不同于有权访问此资源组的开发环境) 。
指南：
可以通过对生产数据库共享同一 SQL 查询输出的屏幕截图来提供证据， (编辑) 和开发/测试数据库的任何敏感信息。 相同命令的输出应生成不同的数据集。 在存储文件的位置，在两个环境中查看文件夹的内容还应演示不同的数据集。
示例证据
屏幕截图显示提交证据 (前 3 条记录，请提供生产数据库中的前 20 条) 。
下一个屏幕截图显示了开发数据库中的相同查询，其中显示了不同的记录。
注意：在此示例中，未使用完整屏幕截图，但所有 ISV 提交的证据屏幕截图都必须是显示 URL、任何登录用户和系统时间和日期的完整屏幕截图。
保护软件开发/部署
参与软件开发活动的组织通常面临安全性与 TTM (上市时间) 压力之间的竞争优先级，但是，在整个软件开发生命周期中实施安全相关活动 (SDLC) 不仅可以节省资金，还可以节省时间。 如果事后才考虑安全性，通常仅在 (DSLC) 的测试阶段确定问题，修复这些问题通常更耗时且成本更高。 此安全部分的目的是确保遵循安全软件开发做法，以降低在开发的软件中引入编码缺陷的风险。 此外，本部分还包含一些控制措施，以帮助安全部署软件。
控制编号 12
请提供证明文档存在的证据，并保证：
支持安全软件的开发，并包括安全编码的行业标准和/或最佳做法，例如 OWASP Top 10 或 SANS Top 25 CWE。
开发人员每年接受相关的安全编码和安全软件开发培训。
意向：安全开发
组织需要尽其所能，确保软件安全开发并无漏洞。 为了实现这一目标，应建立可靠的安全软件开发生命周期 (SDLC) 和安全编码最佳做法，以在整个软件开发过程中促进安全编码技术和安全开发。 目的是减少软件中漏洞的数量和严重性。
所有编程语言都有编码最佳做法和技术，以确保安全地开发代码。 有一些外部培训课程旨在教开发人员不同类型的软件漏洞课程和可用于停止将这些漏洞引入软件的编码技术。 此控件的意图也是向所有开发人员教授这些技术，并确保这些技术不会被遗忘，或者通过每年执行此技术来学习较新的技术。
准则：安全开发
提供有文档记录的 SDLC 和/或支持文档，这些文档演示了安全开发生命周期正在使用中，并且为所有开发人员提供了该指南，以推广安全编码最佳做法。 查看 SDLC 中的 OWASP 和 OWASP 软件保障成熟度模型 (SAMM) 。
示例证据：安全开发
安全软件开发策略文档的示例如下所示。 下面是 Contoso 的安全软件开发过程摘录，其中演示了安全开发和编码做法。
注意：在前面的示例中，未使用完整屏幕截图，但所有 ISV 提交的证据屏幕截图必须是显示任何 URL、登录用户以及系统时间和日期的完整屏幕截图。
指南：安全开发培训
如果培训由外部培训公司进行，或者通过提供培训日记的屏幕截图或其他证明开发人员已参加培训的项目，则通过证书提供证据。 如果此培训是通过内部资源进行的，则还需提供培训材料的证据。
示例证据：安全开发培训
下一个屏幕截图是一封电子邮件，要求 DevOps 团队中的员工注册到 OWASP 十大培训年度培训。
下一个屏幕截图显示已请求培训，其中包含业务理由和批准。 然后，从训练中获取的屏幕截图和显示该人员已完成年度培训的完成记录。
注意：在此示例中，未使用完整屏幕截图，但所有 ISV 提交的证据屏幕截图都必须是显示 URL、任何登录用户和系统时间和日期的完整屏幕截图。
控制措施 13
请提供代码存储库安全的证据，以便：
在与主分支合并之前，所有代码更改都经过第二个审阅者的评审和审批过程。
适当的访问控制已到位。
所有访问都通过多重身份验证 (MFA) 强制实施。
在 () 的生产环境中所做的所有版本在部署之前都经过审查和批准。
意向：代码评审
此子点的意图是由另一个开发人员执行代码评审，以帮助识别任何可能引入软件漏洞的编码错误。 应建立授权，以确保进行代码评审、完成测试等。 部署之前。 授权步骤验证是否遵循了正确的流程，这支撑了控制 12 中定义的 SDLC。
目标是确保所有代码更改在合并到主分支之前，由第二个审阅者进行严格的评审和审批过程。 此双重审批流程用作质量控制措施，旨在捕获任何可能损害应用程序完整性的编码错误、安全漏洞或其他问题。
指南：代码评审
提供证据，证明代码经过了同行评审，并且必须先获得授权，然后才能将其应用于生产环境。 此证据可能通过导出更改票证，证明代码评审已进行且更改已授权，也可以通过代码评审软件（如 Crucible）
示例证据：代码评审
下面是一个票证，显示代码更改由原始开发人员以外的人员进行评审和授权过程。 它表明，受让人已请求代码评审，并将分配给其他人进行代码评审。
下一张图像显示代码评审已分配给原始开发人员以外的人员，如图像右侧突出显示的部分所示。 在左侧，代码审阅者已审阅代码，并提供了“已通过代码评审”状态。 现在，票证必须获得经理的批准，然后才能将更改放入实时生产系统。
下图显示了已批准在实时生产系统上实现评审的代码。 代码更改完成后，最终作业会注销。 请注意，在整个过程中，有三个人参与其中，即代码的原始开发人员、代码审阅者和经理进行审批和签名。 若要满足此控制条件，预期票证将遵循此过程。
注意：在此示例中，未使用完整屏幕截图，但所有 ISV 提交的证据屏幕截图都必须是显示 URL、任何登录用户和系统时间和日期的完整屏幕截图。
示例证据：代码评审
除了上述过程的管理部分外，新式代码存储库和平台还可以实施其他控制措施（如分支策略强制评审），以确保在完成此类评审之前无法进行合并。 以下示例演示了在 DevOps 中实现的这一点。
下一个屏幕截图显示已分配默认审阅者，并且自动需要审阅。
示例证据：代码评审
还可以在 Bitbucket 中实现分支策略强制评审。
在下一个屏幕截图中，设置了默认审阅者。 这可确保在将更改传播到主分支之前，任何合并都需要分配的人员进行评审。
随后的两张屏幕截图演示了正在应用的配置设置的示例。 以及已完成的拉取请求，该请求由用户 Silvester 发起，在与主分支合并之前需要默认审阅者 Andrew 的批准。
请注意，提供证据时，预期将是演示端到端过程。 注意：如果分支策略已到位 (或其他编程方法/控制) ，以及授予审批的票证/记录，则应提供屏幕截图，显示配置设置。
意向：受限访问
从前面的控件开始，应实现访问控制，以将访问权限限制为仅处理特定项目的单个用户。 通过限制访问，可以限制执行未经授权的更改的风险，从而引入不安全的代码更改。 应采取最低特权方法来保护代码存储库。
准则：受限访问
通过代码存储库的屏幕截图提供证据，证明访问权限仅限于所需的个人，包括不同的特权。
示例证据：受限访问
接下来的屏幕截图显示了已在 Azure DevOps 中实现的访问控制。 显示“CloudDemo 团队”有两个成员，每个成员具有不同的权限。
注意：接下来的屏幕截图显示了应满足此控件的证据类型和格式的示例。 这绝不是广泛的，实际情况在访问控制的实现方式上可能有所不同。
如果在组级别设置了权限，则必须提供每个组和该组的用户的证据，如 Bitbucket 的第二个示例所示。
以下屏幕截图显示了“CloudDemo 团队”的成员。
上图显示 Andrew Smith 作为项目所有者的特权明显高于下面的 Silvester。
示例证据
在下一个屏幕截图中，Bitbucket 中实现的访问控制是通过组级别设置的权限实现的。 对于存储库访问级别，有一个具有一个用户的“管理员”组和一个具有另一个用户的“开发人员”组。
接下来的屏幕截图显示，每个用户都属于不同的组，并且本质上具有不同的权限级别。 Andrew Smith 是管理员，Silvester 是开发人员组的一部分，该组仅授予他开发人员权限。
意向：MFA
如果威胁参与者可以访问和修改软件的代码库，他们可能会将漏洞、后门程序或恶意代码引入代码库，从而引入应用程序。 已经发生了几个这种情况，其中最公开的可能是 2020 年的 SolarWinds 攻击，攻击者将恶意代码注入到后来包含在 SolarWinds 的 Orion 软件更新中的文件中。 超过 18,000 个 SolarWinds 客户安装了恶意更新，恶意软件在未发现的情况下传播。
此子点的目的是验证是否通过多重身份验证 (MFA) 强制实施对代码存储库的所有访问。
指南：MFA
通过代码存储库的屏幕截图提供所有用户已启用 MFA 的证据。
示例证据：MFA
如果代码存储库在 Azure DevOps 中存储和维护，则根据在租户级别设置 MFA 的方式，可以从 AAD 提供证据，例如“按用户 MFA”。 下一张屏幕截图显示对 AAD 中的所有用户强制实施 MFA，这也适用于 Azure DevOps。
示例证据：MFA
如果组织使用 GitHub 等平台，可以通过共享来自“组织”帐户的证据来证明 2FA 已启用，如下一张屏幕截图所示。
若要查看是否在 GitHub 上为组织的所有成员强制实施 2FA，可以导航到组织的“设置”选项卡，如下一张屏幕截图所示。
导航到 GitHub 中的“人员”选项卡，可以确定为组织中的所有用户启用了“2FA”，如下一张屏幕截图所示。
意向：评论
使用此控件的意图是由另一个开发人员对开发环境中的发布执行评审，以帮助识别任何编码错误，以及可能引入漏洞的错误配置。 应建立授权，以确保进行发布评审、完成测试等。 在生产环境中部署之前。 授权。 步骤可以验证是否遵循了支持 SDLC 原则的正确流程。
准则
提供证据，证明从测试/开发环境到生产环境的所有版本都由与发起人不同的人员/开发人员审查。 如果这是通过持续集成/持续部署管道实现的，则提供的证据必须显示 (与强制执行评审 ) 的代码评审相同。
示例证据
在下一个屏幕截图中，我们可以看到在 Azure DevOps 中使用 CI/CD 管道，该管道包含两个阶段：开发和生产。 发布已触发并成功部署到开发环境中，但尚未传播到第二阶段 (生产) ，该阶段正在等待 Andrew Smith 的批准。
预期是，一旦部署到开发，安全测试将由相关团队进行，并且仅当分配有适当权限审查部署的人员已执行了辅助评审，并且满足所有条件时，才会授予批准，从而允许发布进入生产环境。
通常由分配的审阅者收到的电子邮件警报，通知已触发预部署条件，并且审阅和审批正在等待。
使用电子邮件通知，审阅者可以导航到 DevOps 中的发布管道并授予批准。 我们可以看到，下面添加了注释来证明审批的合理性。
第二张屏幕截图显示已授予批准，并且成功发布到生产环境。
接下来的两个屏幕截图显示了预期的证据示例。
证据显示历史版本和预部署条件已强制执行，并且需要审查和批准才能部署到生产环境。
下一个屏幕截图显示了版本的历史记录，包括我们可以看到在开发和生产中成功部署的最新版本。
注意：在前面的示例中，未使用完整屏幕截图，但所有 ISV 提交的证据屏幕截图必须是显示 URL、任何登录用户和系统时间和日期的完整屏幕截图。
帐户管理
安全帐户管理做法非常重要，因为用户帐户是允许访问信息系统、系统环境和数据的基础。 用户帐户需要得到适当的保护，因为用户凭据的泄露不仅可以提供进入环境的立足点和对敏感数据的访问权限，还可以在用户的凭据具有管理权限时提供对整个环境或密钥系统的管理控制。
控制编号 14
提供证据，证明：
在采样的系统组件中禁用、删除或更改默认凭据。
已制定一个流程来保护 (强化) 服务帐户，并遵循此过程。
意向：默认凭据
尽管这种情况越来越不受欢迎，但在某些情况下，威胁参与者可以利用默认且记录良好的用户凭据来破坏生产系统组件。 一个常用示例是使用 Dell iDRAC (集成的 Dell 远程访问控制器) 。 此系统可用于远程管理 Dell Server，威胁参与者可以利用该服务器来控制服务器的操作系统。 记录了 root：：calvin 的默认凭据，威胁参与者通常可以利用该凭据来访问组织使用的系统。 此控件的目的是确保禁用或删除默认凭据以增强安全性。
准则：默认凭据
有多种方法可以收集证据来支持此控制。 跨所有系统组件的已配置用户的屏幕截图会有所帮助，例如，通过命令提示符 (CMD) 和 Linux /etc/shadow 和 /etc/passwd 文件的 Windows 默认帐户的屏幕截图将有助于演示是否已禁用帐户。
示例证据：默认凭据
下一个屏幕截图显示了 /etc/shadow 文件，用于演示默认帐户具有锁定密码，并且新创建的/活动帐户具有可用密码。
请注意，通过观察密码哈希以无效字符（如“！”）开头表示密码不可用，需要 /etc/shadow 文件来证明帐户被真正禁用。 在下一张屏幕截图中，“L”表示锁定命名帐户的密码。 此选项通过将密码更改为与任何可能的加密值匹配的值来禁用密码， (它添加 ！在密码) 的开头。 “P”表示它是一个可用密码。
第二张屏幕截图显示，在 Windows 服务器上，所有默认帐户都已被禁用。 通过使用终端上的“net user”命令 (CMD) ，可以列出每个现有帐户的详细信息，并观察所有这些帐户都未处于活动状态。
通过使用 CMD 中的 net user 命令，可以显示所有帐户，并观察所有默认帐户都未处于活动状态。
意向：默认凭据
服务帐户通常成为威胁参与者的目标，因为它们通常配置为提升的权限。 这些帐户可能不遵循标准密码策略，因为服务帐户密码过期通常会中断功能。 因此，可以使用弱密码或组织内重复使用的密码来配置它们。 另一个潜在问题（特别是在 Windows 环境中）可能是操作系统缓存密码哈希。 如果出现以下任一情况，则这可能是个大问题：
服务帐户是在目录服务中配置的，因为此帐户可以跨多个系统使用访问权限，并配置了特权级别，或者
服务帐户是本地帐户，同一帐户/密码可能用于环境中的多个系统。
上述问题可能导致威胁参与者访问环境中的更多系统，并可能导致特权和/或横向移动的进一步提升。 因此，目的是确保服务帐户得到适当的强化和保护，以帮助防止它们被威胁参与者接管，或者通过限制其中一个服务帐户泄露的风险。 该控件要求为强化这些帐户制定正式过程，其中可能包括限制权限、使用复杂密码和定期凭据轮换。
准则
Internet 上有许多指南可帮助强化服务帐户。 证据可以采用屏幕截图的形式，这些屏幕截图演示了组织如何实现帐户的安全强化。 (预期使用的一些示例是，) 会使用多种技术，其中包括：
将帐户限制为 Active Directory 中的一组计算机，
将帐户设置为不允许进行交互式登录，
设置极其复杂的密码，
对于 Active Directory，请启用“帐户敏感且无法委派”标志。
示例证据
有多种方法可以强化依赖于每个环境的服务帐户。 下面是一些可能采用的机制：
下一个屏幕截图显示在服务帐户“_Prod SQL 服务帐户”上选择了“帐户敏感且连接被委派”选项。
第二个屏幕截图显示，服务帐户“_Prod SQL 服务帐户”已锁定到 SQL Server，并且只能登录该服务器。
下一个屏幕截图显示，仅允许服务帐户“_Prod SQL 服务帐户”作为服务登录。
注意：在前面的示例中，未使用完整屏幕截图，但所有 ISV 提交的证据屏幕截图必须是显示 URL、任何登录用户和系统时间和日期的完整屏幕截图。
控制编号 15
提供证据，证明：
向所有用户颁发唯一用户帐户。
环境中遵循用户最低特权原则。
强密码/密码策略或其他适当的缓解措施已到位。
已制定并至少每三个月执行一次流程，以禁用或删除 3 个月内未使用的帐户。
意向：保护服务帐户
这种控制的意图是问责。 通过向用户颁发其自己的唯一用户帐户，用户将对其操作负责，因为用户活动可以跟踪给单个用户。
准则：保护服务帐户
证据是通过显示跨范围系统组件（可能包括服务器、代码存储库、云管理平台、Active Directory、防火墙等）配置的用户帐户的屏幕截图提供。
示例证据：保护服务帐户
下一个屏幕截图显示为范围内 Azure 环境配置的用户帐户，并且所有帐户都是唯一的。
意向：特权
应仅向用户提供完成其工作职能所需的特权。 这是为了限制用户有意或无意访问他们不应或执行的数据的风险
恶意行为。通过遵循此原则，它还减少了潜在的攻击面 (即特权帐户) 可能成为恶意威胁参与者的目标。
指南：特权
大多数组织将利用组基于组织内的团队分配权限。 证据可以是显示各种特权组的屏幕截图，并且仅显示需要这些特权的团队的用户帐户。 通常，这将通过支持策略/流程进行备份，这些策略/流程定义每个定义的组以及所需的权限和业务理由，以及用于验证组成员身份是否正确配置的团队成员层次结构。
例如：在 Azure 中，“所有者”组应非常有限，因此应记录这一点，并应有有限数量的人员分配到该组。 另一个示例可能是能够进行代码更改的有限数量的员工，可能设置具有此权限的组，其成员认为需要配置此权限。 这应该记录在内，以便认证分析师可以将文档与配置的组等交叉引用。
示例证据：特权
接下来的屏幕截图演示了 Azure 环境中的最小特权原则。
下一个屏幕截图突出显示了 Azure Active Directory (AAD) /Microsoft Entra 中的各种组的使用。 观察有三个安全组：开发人员、首席工程师、安全运营。
导航到“开发人员”组，在组级别上，分配的唯一角色是“应用程序开发人员”和“目录读取者”。
下一个屏幕截图显示了“开发人员”组的成员。
最后，下一个屏幕截图显示组的所有者。
与“开发人员”组相比，“安全操作”分配了不同的角色，即“安全操作员”，这符合作业要求。
下一个屏幕截图显示，存在属于“安全操作”组的不同成员。
最后，组具有不同的所有者。
全局管理员是一个高特权角色，组织必须决定在提供此类访问权限时要接受的风险级别。 在提供的示例中，只有两个用户具有此角色。 这是为了确保减少攻击面和影响。
意向：密码策略
用户凭据通常是尝试访问组织环境的威胁参与者的攻击目标。 强密码策略的意图是尝试强制用户选择强密码，以降低威胁参与者能够暴力破解这些密码的可能性。 添加“或其他适当的缓解措施”的意图是认识到组织可以实施其他安全措施，以帮助保护基于行业发展的用户凭据，例如 NIST特别出版物 800-63B。
指南：密码策略
证明强密码策略的证据可能采用组织组策略对象或本地安全策略“帐户策略→密码策略”和“帐户策略→帐户锁定策略”设置的屏幕截图形式。 证据取决于所使用的技术，例如，对于 Linux，它可能是 /etc/pam.d/common-password 配置文件，用于管理门户内的“身份验证策略”部分的 Bitbucket [管理密码策略 |Atlassian支持等
示例证据：密码策略
以下证据显示了在范围内系统组件“CONTOSO-SRV1”的“本地安全策略”内配置的密码策略。
下一个屏幕截图显示了 WatchGuard 防火墙的帐户锁定设置。
下面是 WatchGuard 防火墙的最小密码长度示例。
请注意：在前面的示例中，未使用完整屏幕截图，但所有 ISV 提交的证据屏幕截图都必须是显示 URL、任何登录用户和系统时间和日期的完整屏幕截图。
意向：非活动帐户
非活动帐户有时可能会泄露，因为它们是暴力攻击的目标，这些攻击可能不会标记为用户不会尝试登录帐户，或者由于密码数据库泄露，其中用户的密码已重复使用并在 Internet 上的用户名/密码转储中可用。 应禁用/删除未使用的帐户，以减少威胁参与者必须执行帐户泄露活动的攻击面。 这些账户可能是由于休假程序执行不当、长期生病的工作人员或正在休产假/陪产假的工作人员。 通过实施季度流程来识别这些帐户，组织可以最大程度地减少攻击面。
此控制要求必须制定并至少每三个月遵循一个流程，以禁用或删除过去三个月内未使用的帐户，以确保定期进行帐户审查和及时停用未使用的帐户，以降低风险。
指南：非活动帐户
证据应为两倍：
首先，显示范围内环境中所有用户帐户的“上次登录”的屏幕截图或文件导出。 这可能是本地帐户以及集中式目录服务中的帐户，例如 AAD (Azure Active Directory) 。 这将表明未启用任何超过 3 个月的帐户。
其次，季度审查过程的证据，可能是 ADO (Azure DevOps) 或 JIRA 票证中完成任务的文档证据，或者通过应签署的书面记录。
示例证据：非活动帐户
下一张屏幕截图演示了已使用云平台来执行访问评审。 这是通过使用 Azure 中的标识治理功能实现的。
下一个屏幕截图演示了评审历史记录、评审周期和状态。
评审中的仪表板和指标提供了其他详细信息，例如组织所有用户的范围和评审结果，以及每季度的频率。
评估评审结果时，图像指示已提供基于预配置条件的建议操作。 此外，它还需要分配的人员手动应用评审的决策。
可以在下面看到，对于每个员工，都有一个建议和理由。 如上所述，分配的个人需要在应用评审之前决定接受或忽略该建议。 如果最终决定与建议不一样，则预期将提供证据来解释原因。
控制编号 16
验证是否为所有远程访问连接和所有非控制台管理接口（包括访问任何代码存储库和云管理接口）配置了多重身份验证 (MFA) 。
这些术语的含义
远程访问 – 这是指用于访问支持环境的技术。 例如，远程访问 IPSec VPN、SSL VPN 或 Jumpbox/Bastian 主机。
非控制台管理接口 – 这是指与系统组件的网络管理连接。 这可以通过远程桌面、SSH 或 Web 界面进行。
代码存储库 - 需要保护应用的代码库免受恶意修改的影响，这些修改可能会将恶意软件引入应用。 需要在代码存储库上配置 MFA。
云管理接口 - 其中部分或所有环境托管在云服务提供商 (CSP) 中。 此处包含用于云管理的管理界面。
意向：MFA
此控制的目的是通过实施 多重身份验证 (MFA) ，来缓解对具有安全访问环境的特权帐户的暴力攻击。 即使密码泄露，也仍应保护 MFA 机制，确保所有访问和管理操作仅由授权和受信任的员工执行。
若要增强安全性，请务必使用 MFA 为远程访问连接和非控制台管理接口添加额外的安全层。 远程访问连接特别容易受到未经授权的进入，而管理接口控制高特权功能，使得这两个关键区域都需要加强安全措施。 此外，代码存储库包含敏感的开发工作，云管理接口提供对组织的云资源的广泛访问，使其成为应使用 MFA 保护的其他关键点。
指南：MFA
需要证明 MFA 在适合上述类别的所有技术上都已启用。 这可能是通过显示系统级别启用了 MFA 的屏幕截图实现的。 根据系统级别，我们需要证明它已为所有用户启用，而不仅仅是启用了 MFA 的帐户示例。 如果技术被退到 MFA 解决方案，我们需要证据来证明它已启用和正在使用。 这意味着：如果为 Radius 身份验证设置了技术（指向 MFA 提供程序），则还需要证明它指向的 Radius Server 是 MFA 解决方案，并且帐户配置为利用它。
示例证据：MFA
接下来的屏幕截图演示了如何在 AAD/Entra 中实现 MFA 条件策略，以在整个组织中强制实施双重身份验证要求。 我们可以在下面看到策略为“打开”。
下一个屏幕截图显示 MFA 策略将应用于组织中的所有用户，并且已启用此策略。
下一个屏幕截图演示了满足 MFA 条件后授予访问权限。 在屏幕截图的右侧，我们可以看到，只有在实现 MFA 后，才会向用户授予访问权限。
示例证据：MFA
可以实施其他控制措施，例如 MFA 注册要求，该要求在注册时要求用户在向其新帐户授予访问权限之前配置 MFA。 可以在下面观察应用于所有用户的 MFA 注册策略的配置。
在上一张屏幕截图的延续中，该屏幕截图显示了在不使用排除项的情况下要应用的策略，下一个屏幕截图演示了策略中包含所有用户。
示例证据：MFA
下一个屏幕截图显示“每用户 MFA”页演示了对所有用户强制实施 MFA。
示例证据：MFA
接下来的屏幕截图显示了在 Pulse Secure 上配置的身份验证领域，该领域用于远程访问环境。 身份验证由用于 MFA 支持的 Duo SaaS 服务提供支持。
此屏幕截图演示了其他身份验证服务器，该服务器指向“Duo - Default Route”身份验证领域的“Duo-LDAP”。
此最终屏幕截图显示了 Duo-LDAP 身份验证服务器的配置，该服务器演示了它指向用于 MFA 的 Duo SaaS 服务。
注意：在前面的示例中，未使用完整屏幕截图，但所有 ISV 提交的证据屏幕截图必须是显示 URL、任何登录用户和系统时间和日期的完整屏幕截图。
安全事件日志记录、查看和警报
安全事件日志记录是组织安全计划不可或缺的一部分。 充分记录安全事件，加上经过优化的警报和审查流程，可帮助组织识别组织可用于增强安全和防御性安全策略的违规或企图的违规行为。 此外，适当的日志记录将有助于组织的事件响应能力，这些功能可以馈入其他活动，例如能够准确识别哪些和谁的数据遭到入侵、泄露的时间段、向政府机构提供详细的分析报告等。
查看安全日志是帮助组织识别可能指示安全漏洞的安全事件或可能指示即将发生的事件的安全事件的一项重要功能。 这可以通过每天手动过程来完成，也可以使用 SIEM (安全信息和事件管理) 解决方案来完成，该解决方案有助于分析审核日志，查找可标记为手动检查的关联和异常。
需要立即调查关键安全事件，以尽量减少对数据和操作环境的影响。 警报有助于立即向员工突出显示潜在的安全漏洞，以确保及时响应，以便组织能够尽快遏制安全事件。 通过确保警报有效工作，组织可以最大程度地减少安全漏洞的影响，从而减少严重违规的可能性，从而损害组织品牌，并通过罚款和声誉损害造成财务损失。
第 17 号控制措施
请提供证据，证明已跨范围内环境设置安全事件日志记录，以记录适用事件，例如：
用户对系统组件和应用程序的访问。
高特权用户执行的所有操作。
无效的逻辑访问尝试。
特权帐户创建/修改。
事件日志篡改。
禁用安全工具;例如，事件日志记录。
反恶意软件日志记录;例如，更新、恶意软件检测、扫描失败。
意向：事件日志记录
为了识别尝试的和实际的违规行为，组成环境的所有系统必须收集足够的安全事件日志。 此控件的目的是确保捕获正确类型的安全事件，然后这些事件可以馈入评审和警报过程，以帮助识别和响应这些事件。
此子点要求 ISV 设置安全事件日志记录，以捕获用户访问系统组件和应用程序的所有实例。 这对于监视谁正在访问组织中的系统组件和应用程序至关重要，并且对于安全和审核目的都至关重要。
此子点要求记录具有高级权限的用户执行的所有操作。 高特权用户可以进行可能影响组织安全状况的重大更改。 因此，保持其操作的记录至关重要。
此子点需要记录任何无效尝试，以获取对系统组件或应用程序的逻辑访问权限。 此类日志记录是检测未经授权的访问尝试和潜在安全威胁的主要方法。
此子点要求记录具有特权访问权限的帐户的任何创建或修改。 这种类型的日志记录对于跟踪对具有高级别系统访问权限且可能成为攻击者目标的帐户的更改至关重要。
此子点需要记录任何篡改事件日志的尝试。 篡改日志是隐藏未经授权的活动的一种方法，因此必须记录和处理此类操作。
此子点需要记录禁用安全工具的任何操作，包括事件日志记录本身。 禁用安全工具可能是指示攻击或内部威胁的红色标志。
此子点需要记录与反恶意软件工具相关的活动，包括更新、恶意软件检测和扫描失败。 反恶意软件工具的正常运行和更新对于组织的安全性至关重要，与这些活动相关的日志有助于监视。
指南：事件日志记录
应通过屏幕截图或配置设置在所有采样设备和任何相关的系统组件中提供证据，以演示如何配置日志记录，以确保捕获这些类型的安全事件。
示例证据
接下来的屏幕截图显示了 Azure 中不同资源生成的日志和指标的配置，这些资源随后会引入到集中式 Log Analytic 工作区中。
在第一个屏幕截图中，可以看到日志存储位置为“PaaS-web-app-log-analytics”。
在 Azure 中，可以在 Azure 资源上启用诊断设置，以便访问审核、安全和诊断日志，如下所示。 活动日志（自动可用）包括事件源、日期、用户、时间戳、源地址、目标地址和其他有用的元素。
请注意：以下示例演示了一种可用于满足此控制措施的证据类型。 这取决于组织如何跨范围内环境设置安全事件日志记录。 其他示例可能包括 Azure Sentinel、Datadog 等。
使用 Azure 应用服务上托管的 Web 应用的“诊断设置”选项，可以配置生成哪些日志以及这些日志的发送位置以供存储和分析。
在以下屏幕截图中，“访问审核日志”和“IP 安全审核日志”配置为生成并捕获到 Log Analytic 工作区。
另一个示例是 Azure Front Door，它配置为将生成的日志发送到同一集中式 Log Analytic 工作区。
与使用“诊断设置”选项之前一样，请配置生成哪些日志以及这些日志的发送位置以供存储和分析。 下一个屏幕截图演示了“访问日志”和“WAF 日志”已配置。
同样，对于 Azure SQL Server，“诊断设置”可以配置生成哪些日志以及这些日志的发送位置以供存储和分析。
以下屏幕截图演示了生成 SQL Server 的“审核”日志并将其发送到 Log Analytics 工作区。
示例证据
AAD/Entra 的以下屏幕截图演示了正在为特权角色和管理员生成审核日志。 该信息包括状态、活动、服务、目标和发起方。
以下屏幕截图显示了登录日志。 日志信息包括 IP 地址、状态、位置和日期。
示例证据
下一个示例重点介绍为计算实例（例如虚拟机 (VM) ）生成的日志。 已实现数据收集规则并捕获 Windows 事件日志，包括安全审核日志。
以下屏幕截图显示了名为“Galaxy-Compliance”的采样设备配置设置的另一个示例。 这些设置演示了在“本地安全策略”中启用的各种审核设置。
下一个屏幕截图显示了用户已从采样设备“Galaxy-Compliance”中清除事件日志的事件。
请注意：前面的示例不是全屏屏幕截图，你需要提交全屏屏幕截图，其中包含任何 URL、登录用户以及用于证据审查的时间和日期戳。 如果你是 Linux 用户，可以通过命令提示符完成此操作。
控制编号 18
提供证据，证明可以立即获得至少 30 天的安全事件日志记录数据，并保留 90 天的安全事件日志。
意向：事件日志记录
有时，泄露或安全事件与组织识别该事件之间存在时间差距。 此控制的目的是确保组织有权访问历史事件数据，以帮助完成事件响应和可能需要的任何取证调查工作。 确保组织保留至少 30 天的安全事件日志记录数据，这些数据可立即进行分析，以便快速调查和响应安全事件。 此外，总共会保留 90 天的安全事件日志，以便进行深入分析。
指南：事件日志记录
证据通常是通过显示集中式日志记录解决方案的配置设置来证明数据的保留时间。 需要立即在解决方案中提供 30 天的安全事件日志记录数据。 但是，如果数据已存档，则需要证明 90 天的价值可用。 这可以通过显示包含导出数据日期的存档文件夹来执行此操作。
示例证据：事件日志记录
按照控制措施 17 中的上一个示例，其中集中的 Log Analytic 工作区用于存储云资源生成的所有日志，可以在下面观察到日志存储在每个日志类别的单独表中。 此外，所有表的交互式保留期为 90 天。
下一张屏幕截图提供了其他证据，演示了 Log Analytic 工作区保留期的配置设置。
示例证据
以下屏幕截图演示了在 AlienVault 中提供 30 天的日志。
注意：由于这是一个面向公众的文档，防火墙序列号已经过修订，但是，ISV 将需要提交此信息，而无需进行修订，除非它包含个人身份信息 (PII) 必须披露给其分析师。
下一张屏幕截图显示日志提取可追溯到 5 个月，从而显示日志可用。
注意：由于这是一份面向公众的文档，因此公共 IP 地址已经过修订，因此 ISV 必须提交此信息，而无需进行任何修订，除非其中包含个人身份信息 (PII) 他们必须先与分析师讨论。
注意：前面的示例不是全屏屏幕截图，你将需要使用任何 URL、登录用户以及时间和日期戳提交全屏屏幕截图，以便进行证据审查。 如果你是 Linux 用户，可以通过命令提示符完成此操作。
示例证据
下一张屏幕截图显示，日志事件实时保留 30 天，在 Azure 中的冷存储中保留 90 天。
请注意：除了演示配置保留期的任何配置设置之外，还提供了 90 天期间日志示例，用于验证日志是否保留 90 天。
请注意：这些示例不是全屏屏幕截图，你将需要使用任何 URL、登录用户以及时间和日期戳提交全屏屏幕截图，以便进行证据审查。 如果你是 Linux 用户，可以通过命令提示符完成此操作。
第 19 号控制措施
请提供证据，证明：
将定期审查日志，并调查和解决审查过程中发现的任何潜在安全事件/异常。
意向：事件日志记录
此控件的目的是确保定期执行日志评审。这一点对于识别配置为提供安全事件警报的警报脚本/查询可能无法发现的任何异常非常重要。 此外，还会调查日志评审期间发现的任何异常，并执行适当的修正或操作。这通常涉及一个会审过程，以确定异常是否需要操作，然后可能需要调用事件响应过程。
指南：事件日志记录
屏幕截图将提供证据，证明正在进行日志评审。 这可以通过每天完成的表单，或者通过 JIRA 或 DevOps 票证与
正在发布相关评论，以表明这一点已执行。如果标记了任何异常，则可以记录在同一票证中，以证明对标识为日志评审一部分的异常进行跟踪，然后详细说明之后执行了哪些活动。 这可能会提示提出特定的 JIRA 票证以跟踪正在执行的所有活动，或者可能只是记录在日志评审票证中。 如果需要事件响应操作，则应将其记录为事件响应过程的一部分，并应提供证据来证明这一点。
示例证据：事件日志记录
第一个屏幕截图标识用户已添加到“域管理员”组的位置。
下一张屏幕截图标识了多次失败的登录尝试之后，成功登录的位置，这可能突出显示成功的暴力攻击。
此最终屏幕截图标识了在设置策略时发生密码策略更改的位置，因此帐户密码不会过期。
下一张屏幕截图显示，票证在 SOC 的 ServiceNow 工具中自动引发，触发上述规则。
请注意：这些示例不是全屏屏幕截图，你将需要使用任何 URL、登录用户以及时间和日期戳提交全屏屏幕截图，以便进行证据审查。 如果你是 Linux 用户，可以通过命令提示符完成此操作。
控制编号 20
请提供证据，证明：
配置警报规则，以便触发警报以调查以下安全事件（如果适用）：
特权帐户创建/修改。
特权/高风险活动或操作。
恶意软件事件。
事件日志篡改。
如果配置) ，则 IDPS/WAF 事件 (。
意向：警报
这些是某些类型的安全事件，可以突出显示已发生的安全事件，这些事件可能指向环境泄露和/或数据泄露。
此子任务是确保专门配置警报规则，以在创建或修改特权帐户时触发调查。 在创建或修改特权帐户的情况下，应生成日志，并在创建新的特权帐户或更改现有特权帐户权限时触发警报。 这有助于跟踪任何未经授权的或可疑活动。
此子点旨在设置警报规则，以便在执行特权或高风险活动或操作时通知适当的人员。 对于特权或高风险活动或操作，必须设置警报，以便在启动此类活动时通知相应的人员。 这可能包括对防火墙规则的更改、数据传输或对敏感文件的访问权限。
此子点的目的是强制配置恶意软件相关事件触发的警报规则。 恶意软件事件不仅应记录，还应立即触发警报进行调查。 这些警报应设计为包含详细信息，如恶意软件的来源、性质和受影响的系统组件，以缩短响应时间。
此子点旨在确保任何篡改事件日志都会触发立即警报进行调查。 关于事件日志篡改，应将系统配置为在检测到对日志的未经授权的访问或修改日志时触发警报。 这可确保事件日志的完整性，这些日志对于取证分析和合规性审核至关重要。
此子点旨在确保在配置入侵检测和防护系统 (IDPS) 或 Web 应用程序防火墙 (WAF) 时，它们设置为触发警报进行调查。 如果配置了入侵检测和防护系统 (IDPS) 或 Web 应用程序防火墙 (WAF) ，则还应将其设置为针对可疑活动（例如重复登录失败、SQL 注入尝试或暗示拒绝服务攻击的模式）触发警报。
指南：警报
应通过警报配置的屏幕截图和收到警报的证据来提供证据。 配置屏幕截图应显示触发警报的逻辑以及如何发送警报。 可以通过短信、电子邮件、Teams 频道、Slack 频道等发送警报...
示例证据：警报
下一个屏幕截图显示了在 Azure 中配置的警报示例。 可以在第一张屏幕截图中观察到 VM 停止和解除分配时触发了警报。 请注意，这描述了在 Azure 中配置的警报示例，预期会提供证据来证明为控制说明中指定的所有事件生成了警报。
以下屏幕截图显示了针对在 Azure 应用服务级别和 Azure 资源组级别执行的任何管理操作配置的警报。
示例证据
Contoso 利用 Contoso Security 提供的第三方安全运营中心 (SOC) 。 该示例显示，SOC 利用的 AlienVault 中的警报配置为向 Contoso Security 的 SOC 团队成员 Sally Gold 发送警报。
下一张屏幕截图显示 Sally 收到警报。
请注意：这些示例不是全屏屏幕截图，你将需要使用任何 URL、登录用户以及时间和日期戳提交全屏屏幕截图，以便进行证据审查。 如果你是 Linux 用户，可以通过命令提示符完成此操作。
信息安全风险管理
信息安全风险管理是所有组织应至少每年进行一次的重要活动。 组织必须了解其风险才能有效缓解威胁。 如果没有有效的风险管理，组织可能会在他们认为重要的领域实施安全资源，而其他威胁可能更有可能出现。 有效的风险管理将帮助组织专注于对业务构成最大威胁的风险。 这应该每年进行一次，因为安全形势不断变化，因此威胁和风险可能会随着时间推移而变化。 例如，在最近新冠肺炎（COVID-19）锁定期间，随着转向远程工作，网络钓鱼攻击大幅增加。
控制编号 21
提供证据，证明已批准正式的信息安全风险管理策略/流程已记录和建立。
意向：风险管理
可靠的信息安全风险管理流程对于帮助组织有效管理风险非常重要。 这将有助于组织规划针对环境威胁的有效缓解措施。 此控制的目的是确认组织具有正式批准的信息安全风险管理策略或流程，并已全面记录。 该策略应概述组织如何识别、评估和管理信息安全风险。 它应包括角色和职责、风险评估方法、风险接受标准以及风险缓解程序。
注意：风险评估必须侧重于信息安全风险，而不仅仅是一般业务风险。
指南：风险管理
应提供正式记录的风险评估管理流程。
示例证据：风险管理
以下证据是 Contoso 风险评估过程的一部分的屏幕截图。
注意：期望 ISV 共享实际的支持策略/过程文档，而不只是提供屏幕截图。
注意：期望 ISV 共享实际的支持策略/过程文档，而不只是提供屏幕截图。
控制编号 22
请提供证据，证明：
- 至少每年进行一次正式的全公司信息安全风险评估。
或对于目标风险分析：
将记录并执行有针对性的风险分析：
对于没有实施传统控制或行业最佳做法的每个实例，至少每 12 个月一次。
设计/技术限制造成将漏洞引入环境的风险/使用户和数据面临风险。
怀疑或确认泄露时。
意向：年度评估
安全威胁会根据环境的变化、所提供的服务的变化、外部影响、安全威胁格局的演变等而不断变化。组织需要至少每年经历一次风险评估过程。 建议在发生重大更改时也执行此过程，因为威胁可能会改变。
此控制的目的是确定组织每年至少进行一次正式的公司范围的信息安全风险评估和/或在系统更改期间或在发生事件、漏洞发现、基础结构更改等时进行有针对性的风险分析。此评估应包括所有组织资产、流程和数据，旨在识别和评估潜在的漏洞和威胁。
对于目标风险分析，此控制措施强调需要针对特定方案执行风险分析，这侧重于更窄的范围，例如资产、威胁、系统或控件。 这样做的目的是确保组织持续评估和识别因偏离安全最佳做法或系统设计限制而引入的风险。 通过在缺乏控制的情况下，至少每年执行一次有针对性的风险分析，当技术限制产生漏洞时，以及针对可疑或已确认的安全事件，组织可以查明弱点和风险。 这允许基于风险的明智决策，确定修正工作的优先级，并实施补偿控制，以最大程度地减少利用的可能性和影响。 目标是提供持续的尽职调查、指导和证据，证明已知差距正在以风险意识的方式得到解决，而不是无限期地被忽视。 执行这些有针对性的风险评估表明组织承诺随着时间的推移主动改善安全状况。
准则：年度评估
证据可以通过版本跟踪或日期证据的方式提供。 应提供证据，显示信息安全风险评估的输出和信息安全风险评估过程本身的 NOT 日期。
示例证据：年度评估
下一张屏幕截图显示每六个月安排一次风险评估会议。
接下来的两个屏幕截图显示了两个风险评估中的会议分钟数示例。 预期是提供报告/会议记录或风险评估报告。
注意：此屏幕截图显示了策略/流程文档。 期望 ISV 共享实际的支持策略/过程文档，而不仅仅是提供屏幕截图。
注意：此屏幕截图显示策略/流程文档，ISV 希望共享实际的支持策略/过程文档，而不只是提供屏幕截图。
控制编号 23
验证信息安全风险评估是否包括：
受影响的系统组件或资源。
威胁和漏洞，或等效项。
影响和可能性矩阵或等效项。
创建风险登记/风险处理计划。
意向：风险评估
其意图是，风险评估包括系统组件和资源，因为它有助于识别最关键的 IT 资产及其价值。 通过识别和分析对业务的潜在威胁，组织可以首先关注具有最大潜在影响和最高概率的风险。 通过了解对 IT 基础结构和相关成本的潜在影响，可以帮助管理层在预算、策略、过程等方面做出明智的决策。 可包含在安全风险评估中的系统组件或资源列表包括：
服务器
Databases
应用程序
网络
数据存储设备
人员
为了有效管理信息安全风险，组织应针对环境和数据的威胁以及可能存在的漏洞进行风险评估。 这将有助于组织识别可能构成重大风险的无数威胁和漏洞。 风险评估应记录影响和可能性评级，这些评级可用于识别风险值。 这可用于确定风险处理的优先级，并帮助降低整体风险值。 需要正确跟踪风险评估，以提供所应用的四种风险处理之一的记录。 这些风险处理包括：
避免/终止：企业可能会确定处理风险的成本大于服务产生的收入。 因此，企业可能会选择停止执行该服务。
转让/共享：企业可以选择通过将处理转移到第三方来将风险转移给第三方。
接受/容忍/保留：业务可能会决定风险是可接受的。 这在很大程度上取决于企业的风险偏好，并可能因组织而异。
处理/缓解/修改：业务决定实施缓解控制，以将风险降低到可接受的水平。
指南：风险评估
不仅应通过已经提供的信息安全风险评估过程提供证据，还应通过风险登记/风险处理计划 (风险评估) 的输出来证明风险评估过程正在正确进行。 风险寄存器应包括风险、漏洞、影响和可能性分级。
示例证据：风险评估
下一个屏幕截图显示了风险寄存器，其中演示了包含威胁和漏洞。 它还演示了影响和可能性。
注意：应提供完整的风险评估文档，而不是屏幕截图。 下一个屏幕截图演示了风险处理计划。
控制编号 24
请提供以下证据：
你 (ISV) 有风险管理流程来评估和管理与供应商和业务合作伙伴相关的风险。
你 (ISV) 可以识别和评估可能影响内部控制系统的更改和风险。
意向：供应商和合作伙伴
供应商风险管理是在建立业务关系之前和整个关系期间评估业务合作伙伴、供应商或第三方供应商的风险状况的做法。 通过管理供应商风险，组织可以避免对业务连续性的中断、防止财务影响、保护其声誉、遵守法规，以及识别并最大程度地减少与供应商协作相关的风险。 为了有效管理供应商风险，必须制定流程，包括尽职调查评估、与安全性相关的合同义务以及对供应商合规性的持续监视。
指南：供应商和合作伙伴
可以提供证据来证明供应商风险评估过程，例如采购和审查新供应商和承包商的既定文档、清单和问卷、执行的评估、合规性检查等。
示例证据：供应商和合作伙伴
下一个屏幕截图演示供应商加入和审核过程作为 JIRA 任务在 Confluence 中维护。 对于每个新供应商，都会进行初始风险评估，以审查合规性状况。 在采购过程中，将填写风险评估问卷，并根据提供给供应商的系统和数据的访问级别来确定总体风险。
以下屏幕截图演示了评估的结果，以及基于初始评审确定的总体风险。
意向：内部控制
此子点的重点是识别和评估可能影响组织内部控制系统的更改和风险，以确保内部控制随着时间的推移保持有效。 随着业务运营的变化，内部控制可能不再有效。 风险会随着时间推移而演变，并且可能会出现以前未考虑的新风险。 通过识别和评估这些风险，可以确保内部控制旨在解决这些问题。 这有助于防止欺诈和错误，保持业务连续性，并确保合规性。
指南：内部控制
可以提供证据，例如评审会议记录和报告，这些记录可以证明供应商风险评估过程在定义的时间段内刷新，以确保考虑和评估潜在的供应商更改。
示例证据：内部控制
以下屏幕截图演示了对已批准的供应商和承包商列表进行为期三个月的审查，以确保其合规性标准和符合性级别与加入期间的初始评估一致。
第一个屏幕截图显示了用于执行评估和风险问卷的既定准则。
以下屏幕截图显示了实际供应商批准列表及其符合性级别、执行的评估、评估者、审批者等。请注意，这只是基本供应商风险评估的一个示例，旨在提供基线方案来了解控制要求并显示预期证据的格式。 作为 ISV，应提供自己已建立的供应商风险评估（适用于你的组织）。
安全事件响应
安全事件响应对所有组织都很重要，因为这可以减少包含安全事件的组织花费的时间，并限制组织对数据外泄的暴露程度。 通过制定全面而详细的安全事件响应计划，可将此风险从识别时间减少到遏制时间。
IBM 的一份题为“2020 年数据泄露成本报告”的报告强调，遏制数据泄露所需的时间平均为 73 天。 此外，同一报告确定了遭受违规的组织的最大成本节约措施是事件响应准备，提供平均
节省 2,000,000 美元的成本。 组织应遵循行业标准框架（如 ISO 27001、NIST、SOC 2、PCI DSS 等）的安全合规性最佳做法。
控制编号 25
请提供已批准的安全事件响应计划/过程 (IRP) 概述组织如何响应事件，显示其维护方式，并包括：
事件响应团队的详细信息，包括联系信息，
事件期间的内部沟通计划，以及与相关方（例如主要利益干系人、支付品牌和收购方、监管机构 (72 小时）的外部沟通，例如 GDPR) 、监管机构、董事、客户、
事件分类、遏制、缓解、恢复和恢复正常业务运营等活动的步骤，具体取决于事件类型。
意向：IRP) (响应计划
此控制的目的是确保有一个正式记录的事件响应计划 (IRP) 到位，其中包括一个具有明确记录的角色、职责和联系信息的指定事件响应团队。 IRP 应提供结构化方法来管理从检测到解决的安全事件，包括对事件的性质进行分类、包含直接影响、缓解风险、从事件中恢复以及恢复正常的业务运营。 每个步骤都应明确定义，并制定明确的协议，以确保所采取的措施与组织的风险管理策略和合规性义务保持一致。
事件响应团队在 IRP 中的详细规范可确保每个团队成员了解他们在管理事件时所扮演的角色，从而实现协调高效的响应。 通过设置 IRP，组织可以更有效地管理安全事件响应，从而最终限制组织的数据丢失风险并降低泄露成本。
组织可能基于其 (运营的国家/地区（例如，GDPR) 一般数据保护条例）或基于 (提供的功能（例如 PCI DSS）（如果支付数据) 处理）而承担违反通知义务。 不及时通知可能会产生严重后果：因此，为确保履行通知义务，事件响应计划应包括一个通信过程，包括与所有利益干系人、媒体通信过程以及谁可以和不能与媒体交谈。
指南：内部控制
提供事件响应计划/过程的完整版本。 事件响应计划应包括一个部分，涵盖从识别到解决的事件的处理过程以及记录的通信过程。
示例证据：内部控制
下一个屏幕截图显示了 Contoso 事件响应计划的开始。
注意：作为证据提交的一部分，必须提供整个事件响应计划。
示例证据：内部控制
下一张屏幕截图显示了事件响应计划摘录，其中显示了通信过程。
控制编号 26
请提供证据，证明：
事件响应团队的所有成员都接受了年度培训，使他们能够对事件做出响应。
意向：训练
组织遏制泄露所需的时间越长，数据外泄的风险就越大，可能会导致更多的数据外泄，泄露的总体成本也就越大。 组织的事件响应团队必须能够及时响应安全事件，这一点很重要。 通过进行定期培训和进行桌面练习，团队已准备好快速高效地处理安全事件。 此培训应涵盖各种方面，例如识别潜在威胁、初始响应操作、升级过程和长期缓解策略。
建议为事件响应团队进行内部事件响应培训，并定期进行桌面练习，这应与信息安全风险挂钩
评估以识别最有可能发生的安全事件。 桌面练习应模拟真实场景，以测试和磨练团队在压力下做出反应的能力。 通过这样做，组织可以确保其员工知道如何正确处理安全漏洞或网络攻击。 团队将快速知道要采取哪些步骤来遏制和调查最有可能的安全事件。
指南：培训
应提供证据，证明培训已通过共享培训内容进行，并记录显示谁参加了 (，其中应包括所有事件响应团队) 。 或者，或者，记录显示已进行了桌面练习。所有这些必须在提交证据后的 12 个月内完成。
示例证据：训练
Contoso 使用外部安全公司执行了事件响应桌面练习。 下面是作为咨询的一部分生成的报告示例。
注意：需要共享完整的报表。 此练习也可以在内部进行，因为第三方公司没有Microsoft 365 的要求。
注意：需要共享完整的报表。 此练习也可以在内部进行，因为第三方公司没有Microsoft 365 要求。
控制编号 27
请提供以下证据：
事件响应策略和支持文档将根据以下任一情况进行评审和更新：
从桌面练习中吸取的经验教训
从响应事件中吸取的教训
组织更改
意向：计划评审
随着时间的推移，事件响应计划应根据组织变化或制定计划时学到的经验教训而发展。 对操作环境的更改可能需要更改事件响应计划，因为威胁可能会更改，或者法规要求可能会更改。 此外，随着桌面练习和实际安全事件响应的进行，这通常可以确定计划中可改进的领域。 这需要内置到计划中，并且此控件的意图是确保包含此过程。 此控制的目的是基于三个不同的触发器，强制审查和更新组织的事件响应策略和支持文档：
执行模拟练习以测试其事件响应策略的有效性后，应立即将任何确定的差距或需要改进的领域纳入现有事件响应计划。
实际事件提供了对当前响应策略的优势和劣势的宝贵见解。 如果发生事件，应进行事后评审以捕获这些教训，然后应使用这些教训来更新响应策略和过程。
组织内部的任何重大更改（例如合并、收购或关键人员变更）都应触发对事件响应策略的审查。 这些组织更改可能会引入新的风险或改变现有风险，应相应地更新事件响应计划以保持有效。
指南：计划评审
通常通过查看安全事件或桌面练习的结果来证明这一点，其中已确定经验教训，并导致事件响应计划的更新。 计划应维护更改日志，该日志还应引用根据经验教训或组织变化实施的更改。
示例证据：计划评审
接下来的屏幕截图来自提供的事件响应计划，其中包括基于学到的经验教训和/或组织更改进行更新的部分。
注意：这些示例不是全屏屏幕截图，你需要提交全屏屏幕截图，其中包含任何 URL、登录用户以及用于证据审查的时间和日期戳。 如果你是 Linux 用户，可以通过命令提示符完成此操作。
业务连续性计划和灾难恢复计划
业务连续性规划和灾难恢复规划是组织风险管理策略的两个关键组成部分。 业务连续性规划是创建计划的过程，以确保基本业务功能可以在灾难期间和灾难后继续运行，而灾难恢复规划是创建计划以从灾难中恢复并尽快恢复正常业务运营的过程。 这两个计划相互补充 - 必须同时应对灾难或意外中断带来的操作挑战。 这些计划非常重要，因为它们有助于确保组织在灾难期间能够继续运营、保护其声誉、遵守法律要求、维护客户信心、有效管理风险以及确保员工安全。
控制编号 28
请提供证据，证明：
文档存在并得到维护，其中概述了业务连续性计划，并包括：
相关人员的详细信息，包括其角色和职责
具有相关应变要求和目标的业务职能
系统和数据备份过程、配置和计划/保留
恢复优先级和时间范围目标
一个应变计划，详细说明在发生意外和计划外中断时将关键信息系统、业务功能和服务返回到运营时应遵循的操作、步骤和过程
一个已建立的过程，涵盖最终的完整系统还原并返回到原始状态
意向：业务连续性计划
此控制背后的意图是确保在业务连续性计划中包括明确定义的具有分配角色和职责的人员列表。 这些角色对于在事件期间有效激活和执行计划至关重要。
指南：业务连续性计划
请提供灾难恢复计划/过程的完整版本，其中应包括控制说明中已处理概述的部分。 如果采用数字版本，请提供实际的 PDF/WORD 文档，或者，如果通过联机平台维护该过程，请提供流程的导出或屏幕截图。
示例证据：业务连续性计划
接下来的屏幕截图显示了业务连续性计划的摘录，并且该计划存在并已维护。
注意：此屏幕截图 () 显示策略/流程文档的快照，预计 ISV 共享实际的支持策略/过程文档，而不只是提供屏幕截图。
接下来的屏幕截图显示了策略摘要，其中概述了“关键人员”部分，包括相关团队、联系人详细信息和要采取的步骤。
意向：优先级
此控件的目的是根据业务职能的重要性记录和确定其优先级。 这应同时概述在计划外中断期间维持或快速还原每个功能所需的相应应变要求。
准则：优先级
请提供灾难恢复计划/过程的完整版本，其中应包括控制说明中已处理概述的部分。 如果采用数字版本，请提供实际的 PDF/WORD 文档，或者，如果通过联机平台维护该过程，请提供流程的导出或屏幕截图。
示例证据：优先级
接下来的屏幕截图显示了业务连续性计划的摘录、业务功能及其关键性级别的概述，以及是否存在任何应变计划。
注意：此屏幕截图 () 显示策略/流程文档，ISV 希望共享实际的支持策略/过程文档，而不只是提供屏幕截图。
意向：备份
此子点的目的是维护用于备份基本系统和数据的记录过程。 文档还应指定配置设置以及备份计划和保留策略，以确保数据既是最新的，又是可检索的。
指南：备份
请提供灾难恢复计划/过程的完整版本，其中应包括控制说明中已处理概述的部分。 如果采用数字版本，请提供实际的 PDF/WORD 文档，或者，如果通过联机平台维护该过程，请提供流程的导出或屏幕截图。
示例证据：备份
接下来的屏幕截图显示了 Contoso 灾难恢复计划的摘录，以及每个系统都有记录的备份配置。 请注意，在下一张屏幕截图中还概述了备份计划，请注意，对于此示例，备份配置作为灾难恢复计划的一部分进行概述，因为业务连续性和灾难恢复计划协同工作。
注意：此屏幕截图 () 显示策略/过程文档的快照，ISV 期望共享实际的支持策略/过程文档，而不只是提供屏幕截图。
意向：时间线
此控制旨在为恢复操作建立优先顺序的时间线。 这些恢复时间目标 (RTO) 应与业务影响分析保持一致，并且必须明确定义，以便人员了解必须先还原哪些系统和功能。
指南：时间线
请提供灾难恢复计划/过程的完整版本，其中应包括控制说明中已处理概述的部分。 如果采用数字版本，请提供实际的 PDF/WORD 文档，或者，如果通过联机平台维护该过程，请提供流程的导出或屏幕截图。
示例证据：时间线
以下屏幕截图显示了业务函数的延续和关键性分类，以及已建立的恢复时间目标 (RTO) 。
注意：此屏幕截图 () 显示策略/流程文档，ISV 希望共享实际的支持策略/过程文档，而不只是提供屏幕截图。
意向：恢复
此控件旨在提供要遵循的分步过程，以便将关键信息系统、业务函数和服务返回到操作状态。 这应该足够详细，以指导在高压情况下的决策，在这些情况下，快速和有效的行动至关重要。
指南：恢复
请提供灾难恢复计划/过程的完整版本，其中应包括控制说明中已处理概述的部分。 如果采用数字版本，请提供实际的 PDF/WORD 文档，或者，如果通过联机平台维护该过程，请提供流程的导出或屏幕截图。
示例证据：恢复
接下来的屏幕截图显示了灾难恢复计划的摘录，并且每个系统和业务功能都有记录的恢复计划，请注意，对于此示例，系统恢复过程是灾难恢复计划的一部分，因为业务连续性和灾难恢复计划协同工作以实现完全恢复/还原。
注意：此屏幕截图 () 显示策略/流程文档，ISV 希望共享实际的支持策略/过程文档，而不只是提供屏幕截图。
意向：验证
此控制点旨在确保业务连续性计划包括一个结构化流程，以指导组织在危机得到管理后将系统还原到其原始状态。 这包括确保系统完全正常运行并保持其完整性的验证步骤。
准则：验证
请提供灾难恢复计划/过程的完整版本，其中应包括控制说明中已处理概述的部分。 如果采用数字版本，请提供实际的 PDF/WORD 文档，或者，如果通过联机平台维护该过程，请提供流程的导出或屏幕截图。
示例证据：验证
以下屏幕截图显示了业务连续性计划策略中概述的恢复过程以及要执行的步骤/操作。
注意：此屏幕截图 () 显示策略/过程文档的快照，ISV 期望共享实际的支持策略/过程文档，而不只是提供屏幕截图。
控制编号 29
请提供证据，证明：
文档存在并得到维护，其中概述了灾难恢复计划，并且至少包括：
相关人员的详细信息，包括其角色和职责
具有相关应变要求和目标的业务职能
系统和数据备份过程、配置和计划/保留
恢复优先级和时间范围目标
一个应变计划，详细说明在发生意外和计划外中断时将关键信息系统、业务功能和服务返回到运营时应遵循的操作、步骤和过程
一个已建立的过程，涵盖最终的完整系统还原并返回到原始状态
意向：DRP
此控制的目标是为灾难恢复团队的每个成员提供有据可查的角色和职责。 还应概述升级过程，以确保问题在灾难发生期间由适当的人员快速提升和解决。
指南：DRP
请提供灾难恢复计划/过程的完整版本，其中应包括控制说明中已处理概述的部分。 如果采用数字版本，请提供实际的 PDF/WORD 文档，或者，如果通过联机平台维护该过程，请提供流程的导出或屏幕截图。
示例证据：DRP
接下来的屏幕截图显示了灾难恢复计划的提取，以及它存在和维护。
注意：此屏幕截图 () 显示策略/流程文档，ISV 希望共享实际的支持策略/过程文档，而不只是提供屏幕截图。
下一个屏幕截图显示了策略摘录，其中概述了“应变计划”，包括相关团队、联系人详细信息和升级步骤。
意向：清单
此控制背后的意图是维护对支持业务运营至关重要的所有信息系统的最新清单列表。 此列表是了解在灾难恢复工作期间必须优先考虑哪些系统的基础。
指南：清单
请提供灾难恢复计划/过程的完整版本，其中应包括控制说明中已处理概述的部分。 如果采用数字版本，请提供实际的 PDF/WORD 文档，或者，如果通过联机平台维护该过程，请提供流程的导出或屏幕截图。
示例证据：清单
接下来的屏幕截图显示了 DRP 的提取，以及存在关键系统及其严重性级别以及系统函数的清单。
注意：此屏幕截图 () 显示策略/流程文档，ISV 希望共享实际的支持策略/过程文档，而不只是提供屏幕截图。
下一个屏幕截图显示了分类和服务关键性定义。
注意：此屏幕截图 () 显示策略/流程文档，ISV 希望共享实际的支持策略/过程文档，而不只是提供屏幕截图。
意向：备份
此控制要求为系统和数据备份制定定义完善的过程。 这些过程应概述备份的频率、配置和位置，以确保在发生故障或灾难时可以还原所有关键数据。
指南：备份
请提供灾难恢复计划/过程的完整版本，其中应包括控制说明中已处理概述的部分。 如果采用数字版本，请提供实际的 PDF/WORD 文档，或者，如果通过联机平台维护该过程，请提供流程的导出或屏幕截图。
示例证据：备份
接下来的屏幕截图显示了灾难恢复计划的提取，以及每个系统都有记录的备份配置。 请注意，下面还概述了备份计划。
注意：此屏幕截图 () 显示了策略/流程文档的快照，预期是 ISV 共享实际的支持策略/过程文档，而不只是提供屏幕截图。
意向：恢复
此控制要求制定全面的恢复计划，概述还原重要系统和数据的分步过程。 这可作为灾难恢复团队的路线图，确保所有恢复操作在还原业务运营方面都预先做好了准备并有效。
指南：恢复
请提供灾难恢复计划/过程的完整版本，其中应包括控制说明中已处理概述的部分。 如果采用数字版本，请提供实际的 PDF/WORD 文档，或者，如果通过联机平台维护该过程，请提供流程的导出或屏幕截图。
示例证据：恢复
接下来的屏幕截图显示了灾难恢复计划摘录、设备更换和系统恢复步骤和说明，以及恢复过程，其中包括恢复时间范围、还原云基础结构所要执行的操作等。
注意：此屏幕截图 () 显示了策略/流程文档的快照，预期是 ISV 共享实际的支持策略/过程文档，而不只是提供屏幕截图。
控制编号 30
请提供证据，证明：
业务连续性计划和灾难恢复计划至少每 12 个月审查一次，以确保它在不利情况下保持有效和有效，并根据以下条件进行更新：
计划的年度审查。
所有相关人员都接受有关他们在应急计划中分配的角色和职责的培训。
计划通过业务连续性或灾难恢复练习进行测试。
记录测试结果，包括从练习或组织更改中吸取的经验教训。
意向：年度审查
此控制的目的是确保每年审查业务连续性和灾难恢复计划。 审查应确认计划仍然有效、准确，并与当前业务目标和技术体系结构保持一致。
意向：年度培训
此控制要求在业务连续性和灾难恢复计划中具有指定角色的所有个人每年接受适当的培训。 目标是确保他们了解自己的责任，并在发生灾难或业务中断时能够有效地执行它们。
意向：练习
此处的目的是通过实际练习来验证业务连续性和灾难恢复计划的有效性。 这些练习应设计为模拟各种不利条件，以测试组织可以维持或恢复业务运营的方式。
意向：分析
最终控制点旨在全面记录所有测试结果，包括分析哪些测试结果效果良好，哪些无效。 应将学到的经验教训重新纳入计划，并应立即解决任何缺点，以提高组织的复原能力。
指南：评论
应提供年度业务连续性和灾难恢复计划练习的报告、会议说明和输出等证据以供审查。
示例证据：评论
接下来的屏幕截图显示了业务连续性和灾难恢复计划演练的报告输出， (练习) 其中建立了一个方案，允许团队制定业务连续性和灾难恢复计划，并演练到成功还原业务功能和系统操作的情况。
注意：这些屏幕截图显示策略/流程文档 () 快照，预期 ISV 共享实际的支持策略/过程文档，而不只是提供屏幕截图。
注意：这些屏幕截图显示策略/流程文档 () 快照，预期 ISV 共享实际的支持策略/过程文档，而不只是提供屏幕截图。