8.5 报告格式
不管是什么类型的项目,有些内容一定要加到服务的交付文档中。所有文档都应该说明它们的目的,并对品牌做一定推广,说明涉及的各方,列出进行过的操作,并以期望结果结尾。本节将会提供一些指导和例子,来说明如何非常专业地满足格式要求。
8.5.1 封面页
封面页至少要提供报告名、版本、日期、作者、服务提供商名称以及目标群体。封面页也可以列出其他项,比如文档安全归类,或是突出其他节的结果。
8.5.2 保密声明
大多数渗透测试中获得的都是比较敏感的信息。所以通过制定安全等级来保护执行过程中收集到的信息至关重要,说明允许谁查看这类数据也很重要。这里我们可能需要一些特殊等级的批准,对数据做特殊处理或是将其存放到做过安全加固的地方,比如将分类材料存储到敏感信息隔离设施(SCIF,Sensitive Compartmented Information Facility) 中。泄漏数据可能会造成财务上、品牌上和法律上的不良后果。
保密声明应该说明给予文档什么等级的安全保护、谁可以查看这些资料、哪些内容是允许复制的、哪些是不允许复制的、分发的权限以及其他法律文案。我们建议最好请一位有法律背景的人士来帮你制定标准的保密声明。
示例一:保密声明
本文档包含来自服务提供商 的涉密和特权信息。这类信息仅供客户 独家使用,用于评估企业内部当前的信息安全状况。接受此文档,说明客户 同意将本文档的内容保密,并且不会复制、泄漏或是分发给第三方,除了将来按照文档的推荐直接为客户 提供服务和(或)产品的企业。他们不需要向服务提供商 发出书面请求或书面确认。如果你不是目标接收人,请注意泄漏、复制或分发本文档或其中内容都是不被允许的。
示例二:保密声明
本保密信息是作为服务提供商 咨询活动的交付结果,提供给客户 的。此文档的唯一目的是向客户 提供本次测试的结果和建议。各个参与人都同意根据咨询代理和服务提供商之间的协议,严格遵守分发限制。
8.5.3 文档控制
列出当前是什么版本以及做过哪些修改对于交付目标很重要。很多情况下,文档是由许多具备各种技能的人来审定的。标出修改发生的日期和修改类型可以帮助阅读对象找到最新版本。
文档修订记录 | |||
---|---|---|---|
版本 | 日期 | 作者 | 备注 |
1 | 5/1/13 | Josh Wink | 创建 |
2 | 5/10/13 | Mark Farina | 修订 |
3 | 5/24/13 | Jeff Mills | 修订 |
8.5.4 时间表
时间表为项目的各个环节提供了一个预估的时间。时间表应该包括环节名称、要完成的任务、以及该环节预期持续的时间。通常,持续时间会以可计费时间来显示,所以客户可以评估该项目各个环节的成本。我们建议你在文案中标明哪些环节是必须要有的,以免在项目启动后删掉了关键环节。
下面是一份预期的时间表以及整体的实施方案。
服务提供商 会在收到工作说明书 (SOW,Statement of Work )之后的两周内开始启动测试活动,并由客户来支付跟资源可用性相关的采购。如果客户 要求提前测试活动开始的日期,那这必须跟服务提供商 、项目管理团队 和财务团队 一起议定。
项目启动环节和修复演示环节对于所有其他环节来说都是标准环节。
参与环节 | 任务(宏观) | 预期持续时间 |
---|---|---|
项目启动会 |
审定工作说明书
可交付配置 业务和技术文档,边界评审 先决条件 |
8小时 |
网络评估 |
工具准备和安装
网络踪迹分析、 策略审定、映射 |
16小时 |
扫描设备
评审已有网络架构 |
32小时 | |
渗透测试 | 找出能被漏洞利用的系统并在目标系统上执行渗透测试 | 32小时 |
报告分析、推荐和演示 | 16小时 | |
修复演示 | 演示发现的结果和安全影响分析,包括修复 | 6小时 |
项目结束 | 2小时 |
8.5.5 执行总结
执行报告的目的是给为什么要执行渗透测试服务提供一个宏观的上下文。执行总结应该包括导致已有问题的原因、问题的严重程度分析以及能达到期望结果的修复建议。执行报告不需要包含技术细节,应该面向领导而不是技术员工。
示例1:执行总结
背景:
客户 雇用服务提供商 为自己完成系统漏洞评估和渗透测试。这一过程主要目的是利用服务提供商 经过验证的测试方法论找出客户 网络和系统中的潜在安全漏洞,从而评估客户 网络和系统的安全性。本项目是由来自服务提供商 的专家于雇用日期 在客户 内网中的若干系统上完成的。
本项目包括对9台内部主机进行的渗透测试。在测试方面,服务提供商 主要关注以下内容:
所有测试都是围绕着这些系统承载的实际业务流程以及潜在威胁展开的。因此,这项评估的结果反映了对于线上联网黑客来说,系统暴露程度的实景图。
本文档包含该评估的结果。
项目信息:
本评估的主要目的是针对客户 网络和系统中存在的安全漏洞进行分析。本评估的过程主要是找出潜在漏洞并给出修复漏洞的可行的建议,以便为环境提供更高层级的安全。
服务提供商
用其经过考验的渗透测试方法来评估系统的安全并找出潜在安全漏洞。
示例2:执行总结
客户 雇用服务提供商 来在网络中一定数量的系统上进行网络渗透测试。这些系统可以通过主机IP地址192.168.1.X、10.1.1.X以及172.16.1.X来标识。本次雇用关系的目的是找出指定系统中的安全漏洞,并对其进行优先级设定。雇用关系于开始日期 开始,包含4天的测试、分析和文档记录。
8.5.6 方法论
我们建议你提供一个你是如何交付服务的全景图。可着重说明你在约定的各个阶段的进度、使用的工具以及你如何应对发现的安全威胁。通常我们会制作一些图表来演示进程流和支撑本节内容结构的资源。
认证可以帮助服务提供商来证明自己具备提供高质服务的能力。有些证书可以用来突出公司遵循特定方法来设定业务流程的能力,比如国际标准化组织(ISO)的各种认证(如ISO 9001或ISO 14001)。其他认证可以主要特定技术,比如让工程师获得要部署的技术的认证。常见的渗透测试认证有道德黑客资格认证 (CEH,Certified Ethical Hacker)和GIAC渗透测试员认证 (GPEN,GIAC Penetration Tester),它们能够帮客户确认正在签约阶段的服务提供商是否具备资质。
举个例子:方法论
服务提供商 会从黑客的角度,基于自定制及公开的工具来观察当前的网络安全状态。这些方法可以帮客户 理解威胁信息安全的风险,以及当前这些保护重要系统的安全控制措施的优势和不足。这些结果可以通过使用公开信息来对客户 的内部网络进行性能数据分析、映射网络结构图、找出主机和服务、枚举网络和系统层漏洞、检测局域网内的异常主机以及消除扫描过程中出现的假阳性。
8.5.7 详细测试流程
本节将介绍服务约定的细节。目标受众通常为技术员工。这份文档的目的是围绕找出有问题的地方提供尽可能多的信息。客户可能会去针对某个突出的问题进行验证,重复执行文档中用来验证漏洞的步骤,也就是说他们想知道这些问题是怎么被发现、被访问以致被利用的。这些数据还能证明在工作范围中所有标记过要求的网络领域都已经测试过了。
通常测试流程应该包括目标检测、映射、漏洞评估、架构分析、漏洞利用和报告。服务提供商就某项工作执行到什么程度取决于工作说明书中定义的工作重点是什么。
举个例子。
服务提供商 能够用MS SQL的默认系统管理员登录凭据访问旧有的EMR主机。这种访问权限可以让我们创建管理员账户,查看系统进程、用户账户、数据库文件,并支持文件传送和执行。拿到这种级别访问权限的攻击者具备中断依赖该主机的所有业务进程的能力。
服务提供商 还能用服务器消息区块(SMB,Server Message Block)的Null用户账户来从域名服务器(DNS,Domain Name Server)上枚举用户账户名及群组。攻击者可以用这些信息来对客户 的雇员进行有针对性的钓鱼攻击,或是进行账户密码的暴力破解攻击。成功获得管理员登录凭据的攻击者可以创建其他用户账户,然后给这些账户分配目标业务角色,这样就能利用用户群组的权限完成某些操作。
整体来看,找出的对系统构成威胁的结果都可以通过简单的设备或软件配置设定加上支持政策来降低危害。
漏洞评估和渗透测试总结:
客户 向服务提供商 提供了8个IP地址,如下表中所列。我们对其进行了以下范围的端口扫描,以便找出开放的端口和相关主机上运行的服务。
IP地址 | 主机名 | TCP端口 |
---|---|---|
192.168.10.20 | SERV001 | 42,53,88,135,139,445,464,53,636,1025,1 071,1075,1145 |
192.168.10.23 | SERV542 | 135,139,445,1433,3300 |
192.168.10.154 | SERV239 | 135,139,445,1433,3389 |
192.168.10.204 | SERV777 | 80,135,139,445,1443 |
172.18.10.100 | SERVSQL123 | 135,139,445,1433,1434,3372,3389,5022, 8400,8402 |
172.18.10.101 | SERVSQL124 | 135,139,445,1433,1434,3372,3389,5022, 8400,8402 |
172.18.10.105 | database.intern.com | 80,443 |
172.18.10.200 | corp.com | 80 |
8.5.8 调查结果总结
调查结果总结是支撑提案的干货。这部分通常含有对服务中调查结果的解释,包括已找到的条目可能会如何影响业务。如何格式化展示这些结果将会对客户的反应产生决定性影响,所以不仅要知道该提哪些内容,还要考虑好如何展示这部分数据。
最佳实践是提供一个风险排名来帮助客户理解如何针对找到的结果进行响应。常见的排名特征包括可能性、风险评估、图表、色彩对比等。我们推荐同时提供一个总结图表和一个列出所有调查结果的详细部分。要支持你的调查结果,最佳实践是引用公开来源说明找出的资产为什么有问题,以此来进一步验证总结。公开来源可以是违背惯例、不符合强制标准或是来自信誉度较高消息源的已知漏洞说明。
举个例子。
由于在被测系统中发现的最高风险等级是危急,所以被测系统的当前风险等级为危急。具体调查结果为1个危急 漏洞,2个危险 漏洞,2个低危 漏洞,如下表所示:
漏洞 | 危害度 |
---|---|
漏洞A | 危急 |
漏洞B | 危险 |
漏洞C | 危险 |
漏洞D | 低危 |
漏洞E | 低危 |
评估调查结果总结表 | |
扫描类型 | 总数 |
主机 | 9 |
端口 | TCP、UDP、1~65535 |
漏洞危害度 | 总数 |
危急 | 1(去重后:1) |
危险 | 2(去重后:2) |
低危 | 2(去重后:2) |
“去重” 是指找到同一风险等级中漏洞后其中不同漏洞的数目。举个例子,如果我们找到了五个高危漏洞,但去重后只有三个,有些漏洞可能不止在一个系统中存在。
8.5.9 漏洞
在描述已发现的漏洞时,应该尽可能地详尽清晰,至少应该指出导致漏洞出现的缘由、漏洞对业务运营的影响以及被利用的可能性。报告还应该指出漏洞是如何被找出来的,以及它是否可验证,也就是说,漏洞可被利用还是只是在扫描中发现的可能的漏洞。在描述客户的服务架构中存在的漏洞时,还应该用抓取的流量数据制成一张图表,以便进一步说明问题,这样客户才可以验证修复方案是否有效。
在交付的报告中,还可以加入一些细节,具体描述已发现的漏洞,如下所列:
除了说明系统存在的漏洞以外,这里还有一些通用调查结果,你可能需要添加到要交付的报告中,借此来提升报告的附加值。举个例子,所有美国联邦机构都要有能够支持IPv6的设备是个强制要求。虽然没有这类设备不算是漏洞,不过,美国联邦机构客户可能会希望知道这一点。另一个例子是支持一些未来技术,比如支持VoIP (Voice over IP)技术和视频技术。
下面是一个应该包含到渗透测试服务中提高附加值的调查结果的推荐列表:
8.5.10 网络考虑的因素及建议
本节将会针对在服务中发现的漏洞提供一些修复建议。这些建议既包括整体建议,比如“给系统打个补丁”,也包括关闭漏洞的一些详细步骤。有些修复步骤可能会影响其他服务,比如关闭端口来防御特定类型的攻击,这可能会影响其他使用该通道进行通讯的系统。此外,还有一些事情也很重要,例如,提醒客户可能存在的负面影响,建议他们修复漏洞,并且要事先告知客户,即使按照修复步骤进行操作,一些问题也无法百分之百得到解决,一些系统也仍然无法满足特定的规定。否则,你可能就要面对自己最不愿意看到的一件事情,那就是服务结束后,如果客户被攻击了,他们会指责你没有提供正确的修复步骤来修复已发现的漏洞。
在交付报告中说明你所提供的服务包含哪些保证或涵盖哪些内容,这一点非常重要。因为,如果你没有说明自己提供的服务有哪些,也没有说明并不能保证一定符合特定标准或要求的话,当客户未成功通过审计时,他们可能会认为这是由于你前面的服务不到位。举个例子,在服务中包含一份PCI报告,跟实际和一个PCI专家签约来审核与客户网络相关的规定的方方面面非常不同。后者跟审计人员采取的方式更像。
修复也会分成很多等级。有时业务架构中的网络会暴露出一些不足,但有时这仅是政策上或配置上没有覆盖全,或是缺一个补丁。建议中应包括的要素有:调查结果总结、整体的和详细的修复建议和要求内容之外的其他有用数据——如支持IPv6的能力、网络设计的变化、对硬件、软件和补丁的建议,以及标准吻合度总结。
举个例子。
我们建议客户 通过订购我们的服务来积极地管理技术风险和网络安全。鉴于本次渗透测试中未覆盖的地方对整个企业的影响,我们建议客户 安排合适的资源来保证修复工作及时完成。尽管给出要部署的服务的完整列表已经超出了本次合同的范围,我们还是要指出一些很重要的整体建议。
包括关键系统和网络的高可用性 在评估过程中,我们发现了至关重要的系统上出现了单点失败。最佳实践是准备一些网络错误事件中的故障恢复备选方案。这里有个改进过的连接到核心数据中心的流量方案的例子,我们为数据中心网络添加了冗余备份系统,如下图所示。
8.5.11 附录
附录中要列出所有跟交付报告相关的其他信息,通常跟主要调查结果没太大关系。这部分内容通常是用作参考,可以包含扫描的结果、抓取的截图和其他信息。
示例:
附录001 - Nessus漏洞扫描报告
<抓取的Nessus报告打印件>
8.5.12 术语表
术语表用于定义提案中术语的含义。术语可能是针对技术定义、指出所参考的规范的术语背后的需求、或是需要进一步说明的其他领域。