报告对象 记得犹太文化里有个谚语就说过:世界上最难的有两件事:一是把别人口袋里的钱拿到自己的口袋里,二是把自己脑袋里的东西塞到别人的脑袋里。这说明达到思想上的认同绝非易事。如果您不知道该报告的受众和其关注点,那么从报告人自身的角度定义一个报告的脉络or结构是非常重要的。这样才会让读者有“带入感”并随之产生共鸣。 当然,根据我的经验,至少有两种类型的人会阅读我们的测试报告:管理层和IT技术人员。而实际上管理层是不愿通篇阅读当然也是读不懂测试报告的。他们只想通过目测漏洞列表条目的数量和测试结论,来快速获悉“我们现在到底安不安全?”而IT技术人员则对会各条漏洞分析尤为重视。他们时常怀揣着一颗“既觊觎系统在测试后并无重大漏洞;又希望漏洞程度与整改建议能全面且合理”的待嫁之心。所以我们要花时间搞清楚要报告的对象,并设身处地的从他们的角度来换位思考,做到言之有物、言之凿凿。能够实现“老总看了会沉默,IT看了会流泪”那就厉害了。 封面 对没看错,我们从封面讲起,要注意什么呢?要标明整个报告的“等级标识”和“测试日期”这两个重要元素。 目录 记得小时候读书的时候,语文老师就教育我们:“拿到一本新书的时候要先看目录,以后长大了去某公司查找书籍也要如此。”同理,目录可以让阅读此报告的人对报告的整体架构有个宏观的认识,也可以快速跳跃的到其感兴趣的章节和部分。 内容摘要 怎么听上去有写论文的赶脚?对,只不过不同的是:一般论文在这里尽量体现其通篇最有技术含量的元素,以便更为方便的被检索到。但咱们的报告摘要,则应该尽量避免使用专业术语。因为真正会阅读这部分的管理层金主(非技术类管理人员)可要比技术大牛可多得多哦。当然该部分也可以方便被直接摘录到PPT里,进而在会议上分析与传阅。其实全称应该叫做执行摘要(Executive Summary),也就是汇总性的告知测试了什么、发现了什么、而且是由于什么所导致的。然后就是所发现的漏洞的一个从高到底列表。当然,这里有个小贴士给大家:虽然测试报告命中注定是汇报IT系统和人员的“缺点”,但如果能在摘要中列举出抗攻击成功和安全措施到位的地方,则会在体现测试的客观性和全面性的同时,也能给报告对象带有些许安慰或成就感。毕竟谁都不想看到自己的系统和员工是那么的一无是处。而在执行摘要的最后应该是一个结论,即明确指出是该系统是安全还是不安全。 上述这些都是报告开篇的重要部分,应当能够脉络清晰的呈现在一页A4纸上,让“读者”一目了然的知道接下来要做什么。 测试流程 在E文里,这个部分有个美丽的名字叫做“Technical Storyline”。对,就是最近热播剧《West Word》里,老戏骨们争得头破血流的storyline。我们可以画出带有各种条件判断和步骤框图的测试Flow Chart,它既可以体现咱们的专业水平,又能彰显测试思维的缜密性。另外,我们还可以在必要时阐述一下涉及到评判标准之类的方法论,以增强逻辑性。 工具列表 这里主要包括版本和功能的简要描述。其好处是:如果有人要重现您的测试,则他们可以籍此确切的找到您使用的工具,实现测试的可重复性。 报告主体 这一部分在整个报告中的技术成分含量最高,报告的正文应当包括所有检测到的漏洞细节。即:如何发现到漏洞、漏洞可以如何利用、以及其被利用的可能性有多大。并且还应该尽可能的逐条给出切实贴合的修复建议。在表述顺序上可以有如下几种“打开”方式: · 以严重等级:从高到低,例如:从SQL的注入漏洞一直罗列到源代码中留存的,尽管被注释掉的信息。 · 以网络架构:从外到内,例如:可以参考我们前面各期漫谈所递进介绍的网络拓扑结构的顺序哦。 · 以系统功能:从点散开,例如:将系统中所有涉及到侦听、嗅探的各种测试都描述到位之后,再描述所有涉及密码破解的测试结果。 哥本人喜欢用的方式是以填表的形式予以呈现,比如在每个表格里都固定包含的表项信息有:漏洞名称、等级程度、被利用的可能性、危害范围和建议等。而且要善用rich formatting(即不同颜色、字体、字号和效果等),以达到醒目和易记忆的效果。当然也可以通过软件来自动生成一些饼图或柱状图,以体现各种占比。毕竟有图有真相、图文并茂,才更有说服力。 附录 这里可以添加一些未尽之言的内容。比如:一些测试原理与依据的支撑材料,参加测试人员的资历和项目经验,以及一些必要的且包含有时间戳和系统特征信息的佐证截屏,甚至是一些术语说明列表等。 免责声明 正如《阿甘正传》里的那句:“生活就像一盒巧克力,你永远不知道下一颗是什么味道。”我们在愉快的提交了测试报告后,是无法知道它被用来做什么以及会给自己的工作带来什么的。所以如果你是作为第三方involve到这个测试中的话,最好是在最后或是扉页处撰写一个免责声明,必要时可以附上有高层签署的该渗透测试同意书。 |