第二：渗透测试范围难以约束；

　　多数情况下，渗透测试是一个天马行空、需要强大想象力的工作；

　　例如：05年，在某个高保密要求研究单位做内网测试的时候，要求是侵入内网一台存储了敏感信息的服务器；我花掉了一上午去针对服务器进行常规测试，无果，午饭前我进入到内网另外一台服务器，并启动sniffer（当然，开启了过滤），午饭归来后，从结果中筛选了几台因登录该服务器泄露了口令的PC，其中一台恰巧有权限登录敏感服务器，因此我以此为跳板完成了本次内网测试。

　　这次测试过程，实际上有很多工作是属于要求范围之外的：

　　* 另外一台服务器的IP是我扫描内网后分析得来的；

　　* sniff到的多台PC客户端数据分析，本是意料之外的；

　　* 耗费掉最多时的工作则是分析其内网拓扑结果。

　　而一般来讲，计算项目工时则不会算入这些意料之外的工作所耗费的时间，这样，很多时候，可能测试人员还在外围挣扎的时候，测试时间已经过半了。

　　所以，我认为，黑盒测试需要几个比较关键的指标：

　　a、测试广度：即，测试范围，主要用于估算工作量和时间；

　　b、测试深度：为每个测试内容建立一个测试里程碑，即，提前约定好什么样的效果能说明什么样的漏洞；

　　c、测试内容：测试的具体实施项，除指导测试内容外，还主要负责说明各漏洞的危害，以此作为双方共识的前提；

　　测试广度：

　　一般来说比较容易计算，只要将关联系统数量算入其中，一般我的估算方法是：如果关联系统不超过5，估算工时多加1天；

　　测试深度 & 测试内容：

　　这两个指标关联性很强，也是我所认为的细化黑盒测试的重点，所以放到一起来说。

　　首先，我们需要明白到底测试些什么样的内容，也就是说，我们需要有一个原则性的指导内容，例如：我们可以选择OWASP TOP 10，也可以选择 fortify的coding error，都无所谓，但我个人认为OWASP TOP 10（以下简称”TOP10“）是一个较好的选择，其认同度高，尤其是PCI DSS对其的遵循更能体现其价值。

　　但如果选择了TOP10，就需要有一个拆分工作，也就是将这10项具体落实到测试项上，而测试项的具体编写自然是需要有丰富经验的人来参与的，所以这是一个专家过程，必不可少，如果此步失败了，后面都是失败的；另外一方面，这也是拉开不同厂家之间差距的一个关键点。

　　现在有了10个分类（即TOP10），10个分类下又有了测试点，那么，可以开始定义其危害并为其打分了，这里有两个层面的方法，一个是针对具体测试项，一个是针对10个分类，如果将危害和分数都打在具体测试项上的话，就存在一个问题，每个测试项的展示结果给用户的感官体验是不一样的，用户可能会为同一个分类中两个不同的测试项得到同样的分数而纠结，而且，这些测试项不是一成不变的，是随着技术有所更新的，因此我认为分数和危害应该是TOP10这10个分类的属性。

　　也正是因为将分数和危害作为分类一层的属性，所以还需要一个算法，如：一类中的三个测试项在测试过程中都得到验证，而我为这个分类的打分是5，那么，最终得分应该是三项累加得到15还是只取其一？其实我觉得各有道理，但最关键的可能还是需要引入另外一个指标，该指标与风险评估中的“可能性”类似，即，易用性。

　　为什么是易用性？其实，严格来说，我认为“可能性”这个指标应该有四个部分组成：1、暴露性；2、是否已披露；3、易用性；4、危害程度。但是，既然漏洞已经被挖掘出来，那么暴露性不用多说，而对于可利用的漏洞，那么自然是已披露的（尤其对于WEB类的漏洞，重要的是某类漏洞的利用方法而非具体漏洞细节，所以只要方法是通用的，都应视为已披露的），而“危害程度”我们要放到后面讨论，那么，这里暂时就只有“易用性”了。易用性主要从两个角度考虑，一个是利用方式简单，另外一个就是如果利用方式复杂，那么是否有自动化程度较高的工具来替代人工。

　　综合下来，我觉得可以用类似这样的原则定义“一类中三条测试项都被验证”的情况：

　　如果该分类危险分值为5，那么，三条测试项的分值也都是5，然后根据易用性为每条测试项做一个百分比计算，最终得分按加法计算，这时，得到一个“中间分数”。

　　最后一点，漏洞的“危害程度”，这也需要清晰的定义，而且这又是一个直接关系到该分类的分值的问题，所以，上面仅定义了一个“中间分数”，因为这个中间分数还需要与这里的结果做一个计算，才能相对客观的体现出一个漏洞的危害程度。