与项目正式启动前（测试开始前）需要进行大量准备工作类似，在我们的扫描、利用、横向移动和后渗透活动完成后，我们也必须执行许多活动（其中许多具有合同约束力）。没有两次评估是完全相同的，因此这些活动可能略有差异，但通常必须执行这些活动才能完全结束一次评估。

渗透测试流程包括：前期交互（Pre-Engagement）、信息收集（Information Gathering）、脆弱性评估（Vulnerability Assessment）、利用（Exploitation）、后渗透（Post-Exploitation）、横向移动（Lateral Movement）、概念验证（Proof-of-Concept）和后期交互（Post-Engagement）。

清理 (Cleanup)

测试完成后，我们应执行任何必要的清理工作，例如删除上传到目标系统的工具/脚本，恢复我们可能做出的任何（微小）配置更改等。我们应该拥有所有活动的详细记录，这使得任何清理活动变得简单高效。如果我们无法访问需要删除工件或需要恢复其他更改的系统，我们应提醒客户并在报告附录中列出这些问题。即使我们能够删除任何上传的文件并恢复更改（例如添加本地管理员帐户），我们也应在报告附录中记录这些更改，以防客户收到需要跟踪的警报，并确认相关活动是我们授权的测试的一部分。

文档与报告 (Documentation and Reporting)

在完成评估并断开与客户内部网络的连接或发送”停止”通知邮件以示意测试结束（意味着不再与客户主机交互）之前，我们必须确保为我们计划包含在报告中的所有发现结果备有充分的文档。这包括命令输出、截图、受影响主机列表以及任何特定于客户环境或发现项的其他内容。如果客户在其基础设施中托管了用于内部渗透测试的虚拟机，我们还应确保已检索所有扫描和日志输出，以及可能作为报告一部分或补充文档的任何其他数据。我们不应保留在整个测试过程中遇到的任何个人身份信息（PII）、可能构成罪证的信息或其他敏感数据。

我们应该已经拥有一份详细的发现项列表，这些将包含在报告中，并且拥有所有必要的细节，以便根据客户环境调整发现项。我们的报告可交付成果（将在文档与报告模块中详细介绍）应包括以下内容：

• 攻击链：在发生完全内部沦陷或从外部获取内部访问权限的情况下，详细说明实现入侵所采取的步骤。
• 强有力的执行摘要：非技术受众可以理解的内容概要。
• 针对客户环境的具体发现：包括风险等级、发现项的影响、修复建议以及与问题相关的高质量外部参考。
• 重现每个发现项的充分步骤：以便负责修复的团队能够理解并在实施修复时测试该问题。
• 针对环境的近期、中期和长期建议。
• 附录：包括诸如目标范围、开源情报（OSINT）数据（如果与评估相关）、密码破解分析（如果相关）、发现的端口/服务、被入侵的主机、被入侵的帐户、传输到客户拥有系统的文件、任何创建的帐户/进行的系统修改、Active Directory安全分析（如果相关）、相关的扫描数据/补充文档，以及任何其他为具体发现或建议进一步解释所必需的信息。

在此阶段，我们将创建一份草案报告，这是客户将收到的第一份交付物。此后，客户将能够对报告进行评论并要求任何必要的澄清/修改。

报告评审会议 (Report Review Meeting)

草案报告交付后，并且客户有机会在内部分发并进行深入审查后，通常举行一次报告评审会议，梳理评估结果。报告评审会议通常包括客户方和执行评估的公司方的相同人员。根据发现项的类型，客户可能会引入额外的技术主题专家，如果发现项与他们负责的系统或应用程序相关。通常我们不会逐字阅读整个报告，而是简要梳理每个发现项，并从我们自身的角度/经验给出解释。客户将有机会询问报告中的任何内容、要求澄清或指出需要更正的问题。通常客户会带着关于特定发现项的问题列表前来，并且不希望详细讨论每一个发现项（例如低风险项）。

可交付成果验收 (Deliverable Acceptance)

工作范围（Scope of Work）应明确定义任何项目可交付成果的验收标准。在渗透测试评估中，我们通常交付一份标记为”草案”的报告，并给客户一个审查和评论的机会。一旦客户通过电子邮件或（理想情况下）在报告评审会议期间提交了反馈（即管理层的回应、澄清/修改请求、额外证据等），我们就可以向他们发布一份标记为”最终版”的新版本报告。一些客户可能需向其负责的审计公司可能不接受标记为”草案”的渗透测试报告。其他公司可能不在意，但最好对所有客户保持统一的方法。

修复后测试 (Post-Remediation Testing)

大多数评估将修复后测试作为项目总成本的一部分包含在内。在此阶段，我们将审查客户提供的任何显示修复证据的文件，或者仅仅是一个已修复发现项的列表。我们需要重新访问目标环境并测试每个问题，以确保其得到适当修复。我们将发布一份修复后报告，清楚显示修复后测试前后环境的状态。例如，我们可能包含如下表格：

#	发现项严重程度	发现项标题	状态
1	高	SQL注入	已修复
2	高	身份验证破坏	已修复
3	高	无限制文件上传	已修复
4	高	Web和出口过滤不足	未修复
5	中	未启用SMB签名	未修复
6	低	启用目录列表	未修复

对于每个发现项（在可能的情况下），我们希望通过扫描输出或证明原始利用技术失败的方式，展示证据表明该问题在环境中不再存在。

渗透测试人员在修复中的角色 (Role of the Pentester in Remediation)

由于渗透测试本质上是一种审计，我们必须保持公正的第三方立场，不对我们的发现项执行修复（例如修复代码、给系统打补丁或在Active Directory中进行配置更改）。我们必须保持一定程度的独立性，可以通过就特定问题如何修复提供一般性修复建议来担任受信任的顾问，或者可以进一步解释/演示某个发现项，以便分配给修复工作的团队能更好地理解。我们不应自己实施更改，甚至不应提供精确的修复建议（例如，对于SQL注入，我们可能会说”对用户输入进行清理”，但不会给客户重写后的代码）。这将有助于保持评估的完整性，并且不会在此过程中引入任何潜在的利益冲突。

数据保留 (Data Retention)

渗透测试结束后，我们将拥有大量客户特定数据，例如扫描结果、日志输出、凭据、截图等。数据保留和销毁要求可能因国家/地区以及公司而异，并且应在工作范围和参与规则的合同条款中明确规定每个程序的相关程序。根据PCI数据安全标准（PCI DSS）的渗透测试指南：

“虽然目前没有关于渗透测试人员收集的证据保留的PCI DSS要求，但建议测试人员在考虑任何地方、区域或公司必须遵守的证据保留法律的前提下，将此类证据保留一段时间。该证据应应目标实体或参与规则中定义的其他授权实体的要求提供。”

我们应在渗透测试结束后将证据保留一段时间，以防出现关于特定发现项的问题，或者在客户执行修复活动后协助重新测试”已关闭”的发现项。评估后保留的任何数据应存储在公司拥有和控制的安全位置，并进行静态加密。评估结束时，所有数据应从测试人员系统中清除。对于任何修复后测试或与客户询问相关的发现项调查，应创建一个特定于该客户的新虚拟机。

收尾 (Close Out)

一旦我们交付了最终报告，协助客户解决了关于修复的问题，并执行了修复后测试/发布了新报告，我们最终可以结束这个项目。在此阶段，我们应确保任何用于连接客户系统或处理数据的系统已被擦除或销毁，并且根据公司政策以及我们对客户的合同义务，任何从评估中残留的工件都被安全地（加密）存储。最后的步骤是向客户开具发票并收取服务费用。最后，最好在评估后进行客户满意度调查跟进，以便团队特别是管理层能够了解在评估期间哪些方面进展顺利，以及从公司流程和分配给项目的个别顾问的角度来看，哪些方面可以改进。如果客户对我们的工作和日常互动感到满意，可能会在几周或几个月后提出后续工作的讨论。

当我们持续增长技术技能时，应始终寻找方法提升我们的软技能，成为更全面的专业顾问。最终，客户通常会记得评估期间的互动、沟通以及他们被所聘用的公司对待/重视的方式，而不是渗透测试人员为实现入侵而使用的复杂漏洞利用链。花点时间自我反思，并在作为专业渗透测试人员角色的所有方面致力于持续改进。

问题

在向客户首次提交报告供其审阅和评论时，我们通常会给报告一个什么名称？（一个词）