第12章文档报告

专业的渗透测试要对评估结果进行追踪，所以渗透测试也要有正规的记录卷宗。把各种测试工具的输入和输出记录进行文档化管理，可保证评估结果的准确性、一致性和可再现性。渗透测试这个部分的工作，可能会涉及向客户演示评估结果的工作。应当严肃对待这个环节的工作。某些客户都会对已有漏洞进行缓解控制，然后模拟测试人员的测试过程，以验证改进措施的有效性；另一些客户可能会通过合同要求测试人员进行再次测试，以验证客户改进方案的效果。使用准确的语言把测试的各个步骤整理为有关卷宗，有助于您在这个环节中进行相同的验证性测试。

测试的卷宗应当记录下测试工作中的全部测试行为。在渗透测试的时间窗口内，万一甲方的业务受到测试以外的因素的影响，这些卷宗将能证明您的测试内容。虽然记录操作行为的这种事情乏味而枯燥，但是专业的渗透测试人员会非常注重这项工作。

要精心准备涉及核心领域的文档、汇报和现场演示，注重内容的全局性、条理性和连贯性。本章会详细介绍有关工作的要点，指导读者通盘考虑文档和报告工作的策略。本章将会涉及以下主题。

● 验证测试结果，毕竟汇报的内容应当是经过验证的测试结论。

● 渗透测试项目时常涉及客户的行政层、管理层、技术层。不同层面的人员对测试项目有着不同的关注点。本文将讨论分别满足他们需求的报告类型和报告结构。

● 演示一节将介绍如何根据听众水平准备适当的演示材料。

● 渗透报告都要有测试的后期工作、改正方法和改进建议。这部分将帮助有关部门进行整改。要提出专业的整改意见，就要从安全的角度深度分析被测单位的信息系统，这无疑是汇报人员工作中的一大难点。

本章的各个小节均能指导读者得当地准备文档、汇报和演示工作。这些工作的细微纰漏都可能引发法律问题。报告的观点必须与测试中发现的事实一致。而且，指出目标系统的潜在缺陷只是报告的基本作用，客户对报告的期待往往更高。例如，客户可能要求报告内容能够以已知的和规划规定为出发点，通过具有说服力的证据进行问题演示。此外，还要明确可用来进行攻击的犯罪手段、有关工具和技术，列举已发现的漏洞并验证利用漏洞的可行性。大体上说，文档报告的重点应当是甲方的安全脆弱性，而不是乙方挖掘漏洞的具体过程或涉及漏洞的技术现象。

12.1 文档记录与结果验证

在测试过程中可能会发现很多漏洞，但是并非每个漏洞都可被利用。要验证漏洞存在被攻击的可能性，本质上说就必须对大量的漏洞进行验证。验证漏洞是减少出错的必要手段，更是关系到信誉和诚实形象的重要工作。不少人都会直接整段复制扫描程序的扫描报告，把那些文字拼凑一下就直接向客户交付。这种做法不仅不负责任，而且缺乏对评估过程的必要控制，最终可能导致严重的后果，甚至影响测试人员的职业生涯。如果软件的扫描结果存在假阴性问题，会让用户错误地判断安全水平，甚至令他们身陷危险。因此，必须尽量排除错误，消除测试结果之中的各种矛盾，力争保证测试数据的完整性不受人为因素的影响。以下的这些工作方法，有助于测试人员进行文档管理并验证测试结果的有效性，从而帮助他们把数据转变为真正的最终报告。

● 详细记录信息收集、目标识别、服务枚举、漏洞映射、社会工程学、漏洞利用、提升权权和访问维护各阶段的具体工作步骤。

● 最好给每个将会用到的Kali 工具都草拟一份笔记模板。这种模板应当明确声明工具用途、指令选项、与评估任务的关系，并空出留白以记录相应的测试结果。在使用特定工具得出某项结论之前，要至少重复这些过程两次，以避免测试结果受不可遇见因素的影响。例如，在使用Nmap程序进行端口扫描时，测试人员应当确定笔记模板中的内容涵盖了所有必要的信息，至少包括：使用目的、目标主机、指令选项、相关简介（例如服务监测、操作系统类型、MAC 地址、开放端口、设备类型等内容），并记录下相关程序的输出结果。

● 不要仅凭单一工具的结果就草率地作出鉴定结论。过于依赖单一工具（例如信息收集工具）的做法绝对不可取，因为那样可能会给渗透测试工作带来偏差甚至错误。所以，本书强烈建议您使用不同的工具进行相同项目的测试。这将确保测试结果的有效性，提高效率，减少假阴性和假阳性的偏差问题。换而言之，每个工具都是在特定环境下使用的具有各自专长的程序。某些实际情况下，测试人员可能要进行人工测试。总而言之，要充分利用个人知识和项目经验验证程序结果的有效性。

12.2 报告的种类

在验证过测试结果的全部细节之后，测试人员要把这些信息条理分明地组合成结构清晰的书面报告，最后还要把报告交付给利益相关者。测试报告可分为三种类型。每种类型的报告都有各自的模式，分别侧重于被测单位的不同角色人员。这三种报告分别是：

● 行政报告；

● 管理报告；

● 技术报告。

渗透测试人员要根据阅读人员的理解能力传递相应的信息。本文将详细介绍毎一种报告的行文结构和基本要素。然而，具体内容就需要测试人员根据项目目标自行斟酌了。需要注意的是，在向有关人员交付这些报告之前，应当确保这些报告向他们披露的信息与保密协议、法律规定和渗透测试协议的要求一致。

12.2.1 行政报告

在各种评估报告中，行政报告属于较为简洁的报告。这种报告应当以企业高层的角度，从业务战略的方面介绍渗透测试的作用。这种报告主要面对被测单位C开头的高管（CEO、CTO、CIO等），所以必须具备下列基本要素。

● 项目目标：有渗透测试人员和被测单位共同协商制定的评定准则。

● 漏洞与其风险等级：这部分内容要描述漏洞的风险等级（关键级、高危级、中等风险、低等风险级和信息泄露级）。风险的等级界定应能划分并突出技术安全问题的严重程度。

● 执行摘要：简明扼要地描述此次渗透测试任务采用的方法论、作用和目标，并着重介绍漏洞的数量以及可被利用的漏洞数量。

● 漏洞统计：分类介绍目标网络系统里存在的漏洞。通常，测试人员还会以饼形图或其他简明易懂的方式进行演示。

● 风险矩阵：对以识别出的漏洞进行量化分析和分类总结，推断可能会受风险影响的相关资源，以便于记忆的方式列举出此次任务的发现、参考文献和改进建议。

在草拟行政报告时，最好能够兼顾报告内容的创造力和文字的表达能力。行政报告并不是以技术角度反映评估结果的技术细节，而是要对技术评估结果进行总结，指出它们对业务的实际影响。一般来说，行政报告的篇幅应当是2～4页。

12.2.2 管理报告

管理报告通常讨论安全问题相关的法律法规和合规性问题。这种报告通常是对行政报告的必要扩充，不仅应能满足人力资源和其他管理层人士的工作需要，而且要从法定程序的角度分析问题。此类报告可能需要涉及以下方面。

● 法规问题：报告首先应当列举出已知的各种安全标准和法律法规，并指出它们与当前安全问题涉及的有关法律条款。应当重点突出已经触及的法律问题，以及企业可能在不经意间就会面临的严重的法律风险。

● 测试方法：帮助管理层人士理解渗透测试生命周期的简要介绍。

● 假设与局限性：阐述那些可能影响渗透测试人员完成特定目标的已知因素。

● 变更管理：某些人可能认为只有当被测单位进行系统改进的时候，测试人员才会涉及变更管理的工作。但是，在受控的 IT 环境中，策略管理和业务流程都涉及变更管理。测试人员在安全评估报告中提及的建议和推荐，应当与整个工作中地变化情况保持一致，以最大程度的减少意外事件给评估服务带来的负面影响。

● 配置管理：侧重于保持信息系统功能和性能的一致性。以系统安全的角度来看，每当某个变更可能影响目标环境（硬件、软件、物理属性和其他问题）的时候，有关人员就应当随后进行相应的配置管理。这种管理是对系统配置的一种监控手段，以维护系统的配置状态。

一个负责的专业渗透测试人员，在渗透测试步入任何环节之前都会向管理团队阐明情况。这种沟通工作不仅涉及一对一的面谈，而且要明确界定特定测试的评估标准。即，测试人员要和被测单位探讨评估时涉及合规化要求、评估采用的标准框架，确定特定测试的实际限制，判断改进建议是否对目标系统切实可行，了解配置变更对当前系统状态的影响等。所有这些因素都与目标环境的安全状态有着千丝万缕的联系，决定着技术安全评估人员应当给予什么建议和意见。

12.2.3 技术报告

被评估单位主要参照技术报告解决渗透测试时发现的安全问题。这类报告主要面向技术人员，帮助他们理解目标系统的核心安全问题。技术报告详细介绍各种漏洞、利用漏洞的具体方法、安全问题给业务带来的负面影响，以及针对这些威胁的补救建议。它得是全面保护网络系统的安全防护指南。前文介绍了行政报告和管理报告的基本要素。技术报告要对这两种报告进行补充说明，满足被评估单位技术团队的各种需求。有些情况下，技术报告也要包含前两种报告中的项目目标、漏洞及其风险等级、风险矩阵、漏洞统计、测试方法和假设与局限性内容。不过，技术报告的至少要涵盖以下内容。

● 安全问题：技术报告应当详细描述在渗透过程中发现的安全问题和针对这些漏洞的攻击方法。它应该使用列表详尽描述受影响的资源范围、攻击后果、测试时的请求和响应数据、模拟攻击所使用的请求和响应数据、向改善团队提供外部的参考文献、列举出可帮助被评估单位解决相关漏洞的针对性的专业建议。

● 漏洞映射：技术报告还应当详细列举出每个漏洞的具体位置，通过标识信息的映射（即参照信息）帮助技术人员找到漏洞所在。例如，IP 地址和相应主机的对应关系就是一种标识信息的映射。

● 利用程序映射：技术报告应当列举出测试人员核对并验证过的漏洞利用程序（exploit），并且要指明有关的漏洞利用程序是在网络里可以找到的公开程序，还是不公开的自测程序。如果能够指出漏洞利用程序的下载地址并说明它的公开日期，那么这份报告就更有说服力。

● 最佳实践：最佳实践可指导有关人员改进在设计、实施和运营方面的安全机制。例如，大型企业的 IT 环境通常部署边界级别的保护设施，以降低外部入侵的几率。最佳实践的各种案例都非常灵活，不需要干预生产系统也不需要改动原有程序。

一般来说，技术报告是向被测单位有关人员如实反映实际情况的技术文件。技术报告在风险管理中的作用重大，多数情况下都会被用于指导安全系统的改进工作。

12.3 渗透测试报告（样文）

以网络为测试目标的渗透测试报告，其正文部分应当由以下内容组成。

● 法律声明（Legal notice）

● 渗透测试协议（Penetration testing agreement）

● 简介（Introduction）

● 项目目标（Project objective）

● 假定和限制（Assumptions and imitations）

● 漏洞的影响（Vulnerability risk scale）

● 执行摘要（Executive summary）

● 风险矩阵（Risk matrix）

● 测试方法（Testing methodology）

● 安全威胁（Security threats）

● 改进建议（Recommendations）

● 漏洞映射（Vulnerabilities map）

● 利用方法（Exploits map）

● 合规性评估（Compliance assessment）

● 变更管理（Change management）

● 最佳实践（Best Practices）

● 附录（Annexes）

换而言之，报告撰写人员要使用明确的行文结构，把各种类型的报告中的所有信息整理为一份单独的完整报告。报告中的这些章又可再度细化，分为各种节，以更为详尽地介绍各种细节。例如，附录章节可在不同小节里分别列举技术细节、分析测试过程、操作日志、各种安全工具的原始数据、研究的详情、网络资源的引用以及术语表。用户会根据需要选择他们要看的报告类型，而测试人员要根据这种需求判断自己的定位和作用，然后再开始进行渗透测试。

12.4 准备演示的资料

在现场演示之前，演示人员应当实现了解听众的技术水平和关注要点。一次成功的现场演示，离不开针对听众的需求精心准备。若演讲内容与听众需求脱节，演示活动将会招致听众的反感。现场演示主要为了让听众理解测试人员在测试环节中发现的潜在风险因素。例如，行政级别的经理可能没有心思关注社会工程学攻击问题，但是他们可能需要理解安全的现状，想指导采用什么措施可以改善系统的安全性。

虽然在准备演示资料和演示方法方面没有统一的正规流程，但是演讲人员还是应当尽量让听众中的技术人员和非技术人员都能有所收获。估测听众的技能水平与了解被测信息系统一样，都是测试人员的工作。在现场演示中，要让听众像了解他们的关键资产那样了解演讲人员的技术实力。

只有客观地指出当前安全问题中存在的缺陷，才能保证现场演示不失专业水准。一次成功的现场演示应当以事实和现象为依据，由技术论证得出相应结论，并要给甲方负责改进的团队提供相应的意见。演示是一种面对面的交流活动，演讲人员应当事先准备好支持论点的事实和数据。

12.5 测试的后期流程

提供补救措施、改正步骤和整改建议都是渗透测试后期阶段的工作。在这些工作里，渗透测试人员要担当被测单位的改进顾问。因为要和大量的技术人员打交道，所以此时沟通能力和网络技术能力就显得尤为重要。

此外，除非专门进行培训，否则目标人群不可能掌握被测单位IT系统的全部知识。这种条件下渗透测试人员的工作很难做，他们就需要与有关技术的专家配合，才能知道如何修补各个缺陷。本文提出几个通用准则，以帮助读者向客户提供关键的改进建议。

● 测试报告要从网络设计入手，并且指出可能利用漏洞的各种必备条件。

● 侧重分析安全边界或数据中心的保护方案，力图在安全威胁后台服务器或工作站之前降低它们的数量。

● 客户端攻击和社会工程学攻击几乎无法避免。但是对员工进行针对性的最新对策和安全意识培训，至少可以降低这些攻击的危害。

● 渗透测试人员在提出每项建议之前，应当进行额外的调查，以确保他们的建议不会影响目标系统的功能。

● 在有必要部署第三方解决方案（IDS/IPS、防火墙、内容保护系统、杀毒软件、IAM技术等）的时候，应当验证这些方案的有效性和可靠性，还要对软件运行机制进行安全和效率方面的优化。

● 要区别对待不安全的（或面向公共提供网络服务的）网域和安全的网域，实施分而治之的保护策略。

● 提高研发团队的安全水准，通过安全的应用程序提高目标 IT 系统的安全性。应用程序的安全评估、源代码审计都可以给整个企业带来很高的回报。

● 采用物理安全措施。可通过安全环境设计、机械与电子门禁、入侵警报系统、闭路电视监控系统和个人身份识别系统，进行多层次的入场控制。

● 定期更新所有重要的安全系统，力求保证其保密性、完整性和可用性。

● 检测并验证所有文件中推荐的安全方案，消除入侵或漏洞利用的可能性。

12.6 本章总结

本章阐述了撰写渗透测试报告所必需的基本步骤，讨论了向客户进行现场演示的核心环节。本章开头便介绍了从某个工具中提取分析结果的具体方法，并强调了最终的汇报不能单纯依赖单一工具的检测结果。在最终定稿之前，测试人员必须使用自身经验和有关知识验证测试结果。也就是说，测试人员应当能人工验证测试结果。本章还介绍了不同类型的报告格式，集中讨论了从行政、管理和技术的方面撰写安全审计报告的方法。此外，本文还提供了一份以网络为对象的渗透测试报告模板，读者可在撰写报告的时候参考我们的模板。接下来，本文阐述了现场演示的价值和验证技术现象的方法，并介绍了向不同职业背景的听众进行演示的有关要点。

最后，本章还提供了在渗透测试后期通用的工作流程。读者在向用户提供有关补救措施或者改进建议的时候，可能需要参考这部分内容。这一节详细阐述了测试人员以对方技术团队顾问的身份，或者以改进负责人的身份向被测试单位提供整治意见的方法。