安全服务反思：把渗透测试做成服务
原文：http://www.room702.cn/index.php/archives/527
http://www.room702.cn/index.php/archives/529
http://www.room702.cn/index.php/archives/531
0、也许都是瞎扯！
首先，我这个标题自然就是认为，现在国内的渗透测试已经做的不像服务了，可谓乱象丛生，一个高端的技术服务最后成了白菜，真是可悲。所以，才有此文。
当然，一切都只是根据我的经验所得，纯属个人行为和个人观点，也许你看完之后发现，这都是瞎扯淡！
1、前言：这可能吗？
08年，我萌生了这样的一个想法，在一次为其期近两周的渗透测试中细化了黑盒测试方法和流程（但迫于现状后期未能推广，仅个人使用）；
09年的一个项目中，在业务梳理数据支持下完成的业务层逻辑安全测试让我从理论层面验证业务白盒测试的方法；
10年时，在一次某集团的全国培训中讲解了方法论及实施流程等细节，得到认同，多家市公司在随后邀请以此立项，但我走了；
所以，我认为，这是可能的。
2、白菜价的pen-test：渗透测试国内现状
根据有记录的项目资料来看，我参与的渗透测试项目超过40个，其中作为主要测试人员的项目数量超过60%，而至少有50%的项目是在前期或后期与客户进行过现场交流，所以我觉得我可以为以下所描述的现状负责。
目前国内渗透测试的现状呈现以下几个特点：
a、风险评估项目中，项目经理或客户期望来自渗透测试的收益能占据技术部分50%甚至更多；
b、将渗透测试作为一个实例展现的手段；
c、靠渗透测试来卖产品；
d、单一依靠渗透测试的手段来完成某部分甚至全部网络的技术评估工作；
e、很多测试人员在进行渗透测试时对工具的依赖性太强；
f、尤其在WEB类测试中，渗透测试的深度和广度基本上是不清晰、不明确的（即，缺乏技术上的度量衡）。
以上几点，第一点（即，特点a）应该是有点争议的，因为每个人对风险评估的理解深角度不同，难免有差异，所以不多阐述，此文主要针对解决b至f的一些问题来的，但难免也会设计到风险评估，希望能仁者见仁、智者见智。
3、尴尬：渗透测试有什么价值？
从传统思路来讲，如果有危险，首先人们考虑到的就是如何防护的问题，所以安全是防护产品先于测试类产品。
而随着思想的进步，防护产品的严防死守，缺乏安全感的专家们需要一种能够检测自家防盗门的工具 —— 于是测试类产品和服务孕育而生，但每家的防盗门品牌又不同，所以有一些标准化的东西来指导测试类服务的方向，而具体的实现依靠每个安全专家自己的认识。
但就是在这其中，有那么一个非常吸引人们眼球的玩意 —— 渗透测试 —— 这个东西就是让具有良好素质的人来模拟小偷的行为来对你的防盗门进行各种破除工作，从而确定你的防盗门是否能防御小偷的侵袭。
但这里存在着一些问题。
多数情况下，要尝试破除哪扇门是客户确定的，也就是说，如果你的家中有三扇门，而你只认为其中一扇存在隐患而仅对这一扇门进行测试的话，那么无形中你就已经忽略了另外两个潜在的风险点。
换一种情况来看，如果仅仅存在一扇门，而且你也要求对这仅存的一扇门进行测试的话，看似没有问题，但还有一类小偷是飞檐走壁的，怎么就没考虑进去呢？对于非专业或是不了解盗窃行业的你来说，可能是无法想象的，所以，非专业人员制定的范围又出错了。
当然，可能有人会说，非专业人员制定范围失误，那评估小组不是要先查找整个房间的弱点吗？然后才把弱点递交给测试人员进行渗透测试啊。这其实就是另外一个问题，很多时候，渗透测试在风险评估中是与传统技术类工作和管理类工作并行开始的，因此就丧失了这个机会；而且，渗透测试人员从敏锐度上来说是高于管理调研和传统技术类工作的人员的，换言之，非测试人员在进行传统技术测试和管理调研等工作过程中，可能无法真正挖掘出能输出给渗透测试人员的中间结果，他们甚至无法将获得的结果整理成建议的模式输出给渗透测试人员 —— 也就是说，很多风险评估的内部工作并行、人员相互独立（尤其是对相互的工作了解不清晰）导致几拨人在工作中各自为战，所以经常能见到风险评估工作在收尾的时候，几拨人的输出结果难以平稳的拼接在一起，最终只得按照通用模板来生搬硬凑，然后算个风险值交给客户了事。
最后一种情况是渗透测试人员最为尴尬的情况。部分销售或售前为销售产品，或是由于客户自身对安全相关知识的不理解，导致最终产生类似这样的订单：针对XX系统进行渗透测试，测试需发现该系统的A层面、B层面、C层面的漏洞。
也就是上面提到的一种情况，将渗透测试作为一种全面的评估手段，期望通过渗透测试来挖掘出全部的漏洞，但凡是有过入侵经验的人都清楚，谁能拍着胸脯说他可以挖干净一套系统的全部漏洞？
所以说，我认为，渗透测试不过是在验证风险评估的一种结果；
或是说的更精确一点：风险评估其目标是评估风险出现的可能性，而渗透测试则是通过模拟入侵的手法来验证众多可能性中的一种或几种，而非全部可能性。因为，风险中的很多系数是在随时变化的，根本不是一个永恒不变的定数。
4、对传统黑盒渗透测试的思考
首先我需要根据我的理解来定义黑盒渗透测试（以下简称“黑盒测试”）。
我所接触的多数渗透测试都为黑盒渗透测试，黑盒渗透测试对前期工作要求难度不高，销售和售前的多数对于黑盒测试的把握也相对比较容易 —— 我见过多个厂家的数销售和售前对黑盒测试的前期工作都来自于一份内容有限的售前文档。
而这样的传统方式的黑盒测试项目实际上是有很多弊端的，包括前面说过的：
* 单一依靠渗透测试的手段来完成某部分甚至全部网络的技术评估工作；
* 尤其在WEB类测试中，渗透测试的深度和广度基本上是不清晰、不明确的（即，缺乏技术上的度量衡）；
而由这些问题引申出来一个更为严重的问题，那就是 —— “渗透测试的达成要求不清晰”。
也就是说，什么样才算是渗透测试完成？一般合同里很难清晰的界定，所以多数情况下以“客户满意”作为目标。
每当我和一些售前工作的人员提到这样的问题时，多数人也会挠头，因为他们实在是不知道应该如何在售前文档和合同中写入渗透测试的一个达成标准，很显然 —— 产品和传统服务都有一个终结点，而渗透测试本身具备以下特点：
* 第一个特点就是刚才我总结出来的：渗透测试只是验证众多风险的可能性中的一种或几种；
* 第二点也是上面提到的：渗透测试范围难以完全约束住；
这两个特点和无法确认渗透测试服务的“终结点”或是说无法明确约定“达成目标”有什么关系？我一个一个拆开来说。
第一：渗透测试只是验证众多风险的可能性中的一种或几种；
渗透测试为什么只能验证其中的一种或几种？而为什么风险评估从“某种程度”上来讲就能相对覆盖全面？
其实，各种风险评估方法也是无法保证完整覆盖所有风险的，所以我才说“某种程度上相对覆盖全面”。但是，风险评估的各种方法在其后端都有一个强大的体系甚至法规为其做后盾，虽然说具体的风险识别的时候还是离不开人，但有如此坚强的后盾作为支撑，其结果自然也就差不了太多。
而作为黑盒测试来说，又有什么样的体系来为我们做支撑呢？正是因为没有这样一个东西作为其理论基础，所以，作为一项服务也好、作为一个产品也罢，自然就出现了没有边界的情况。
这就好像防盗门的制作厂商和小偷一样：防盗门厂商制作防盗门有理论上的要求，比如：用什么样的工具，在多数分钟内无法割出一个多大的洞就算是合格；而小偷则不是如此，如果某位老大交给他的小弟一个任务：你去某某房间盗窃物品，那么，小偷到这里尝试开锁的话，就要依靠自己的经验和力量，如果没有打开，回去和老大报告，老大问到细节之处，他无非是将自己使用的方法和工具一一列举出来，而不像是防盗门厂商一样 —— 只需告诉检测者我们通过了XX认证测试。
第二：渗透测试范围难以约束；
多数情况下，渗透测试是一个天马行空、需要强大想象力的工作；
例如：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，然后根据易用性为每条测试项做一个百分比计算，最终得分按加法计算，这时，得到一个“中间分数”。
最后一点，漏洞的“危害程度”，这也需要清晰的定义，而且这又是一个直接关系到该分类的分值的问题，所以，上面仅定义了一个“中间分数”，因为这个中间分数还需要与这里的结果做一个计算，才能相对客观的体现出一个漏洞的危害程度。
我们可以拿最简的XSS来做举例，可以分以下几种情况讨论：
* 仅仅能实现弹窗，也就是说，也许是某些限制的原则，仅能alert，那么，归结为过滤不严格且是其中最低危害等级的；
* 非存储型，在URL里构造大量内容才能造成一定危害，这种情况相对来说易暴露，危害等级虽然高，但相对难实施，所以综合下来等级也只能达到中；
* 存储型，直接POST了javascript到某个页面，访问者可直接被盗取敏感数据，此时应该是XSS里得分相对最高的一个级别。
以上几个级别和对应的分数，我把他们定义为“实施等级”，实施等级的得分再与上面的“中间分数”进行二次计算，才是最终得分，这样，大概有这么一个表单：
注：以上只是一个示例说明，具体算法和权重、分数等，需根据划分的测试项和大分类自身的定义来做细化
当然，这只是一个简易表格，还可继续完善，例如：测试项对应的检测工具、对应的参考资料、CVE链接等等，都可以做入其中，这样，测试人员只需一张表格便可有完整的测试指导，而对于用户来说，只要表格中的一些测试项、易用性、实施等级等资料，即可了解测试工作包括了什么，测试的内容危害是什么，最终的分数是怎么计算的等他所关心的问题。
BTW：如果有条件的话，最好能在表单中或是表单外，针对每个测试项附加一个用例库，而用例库除了初次添加外，还应在每次测试完毕后根据具体项目情况来完善现有用例库，当用例库达到一定程度的时候，根据每次的项目目标，即可对用例库进行行业分类，到那个时候，渗透测试的行业化方向，在用例库中就能清晰的看出来了。
5、基于业务的白盒渗透测试
其实，我最终想说的重点，应该都在该部分，在黑盒测试部分，无论从技术层面做的如何细致，都是难以完全贴近用户真实业务情况的，而其结果也不过是一个纯粹的技术数字而已，仅仅对技术层起到一个“通用性”的指导作用，很难拔得一定的高度，所以，我认为，细化现有渗透测试的技术流程和技术层面虽然是必要的一个过程，但也仅仅是一个中间过程，在目前的“可改进范围之内”，基于业务的白盒渗透测试才应该是最终渗透测试的一个必然方向。
那么，怎么样进行“基于业务的白盒渗透测试”（以下简称“白盒测试”）呢？
第一步：了解业务特性、熟悉业务流程
在此需要做以下的工作：a、梳理业务流；b、梳理业务逻辑；c、确认业务节点；d、利用业务流和业务逻辑串联业务节点。
其实，这就是之前我所写的《技术乱谈：从客户端到业务系统》文章中后半部分关于业务系统评估及防护方法的前几步，也就是说，如果基于业务进行过类似的评估工作的话，那么，实际上那些输出已经可以作为此步的输入了。
第二步：导入管理风险
管理调研这部分，每个人做法不一样，因此很难有一个通用表单或工具来做集中导入。
但是，对于有风险评估经验的人来说，做一个case-by-case的东西却不太困难，我的大概思路如下：
* 串联业务流上的节点脆弱性，将节点与业务流串联完成之后（以下内容可先参考《技术乱谈：从客户端到业务系统》），节点上的脆弱性也可以按照类似的方法进行串联，简单举例来说，如，业务流与节点的串联关系为：A — B（TCP 80） — C（TCP 1521），也就是说，从A发起访问，到B的TCP 80 作为一个技术指标，然后在从B跳转至C节点的TCP 1521，这样一个业务流程完成，当然，还有反向的，就不再列举。
同时，我们会在 A、B、C三个节点上分别做脆弱性的挖掘工作（与传统技术评估类似），而依照A-B-C现有流程，结合挖掘出来的脆弱性，就可以将一条攻击路径勾画出来，例如：利用A的某漏洞，可跳转至B，然后再如何如何跳转至C，甚至通过破坏现有业务逻辑的情况下来完成攻击也是可以的。
* 串联管理上的脆弱性，至此为止，所有的“可能性”都是基于技术层面的，于是，还需要加入管理层面的“可能性”，例如：传统意义上，我们认为针对节点A的侵入都是通过远程的方式，但如果A上存在一个IE漏洞，而安全操作手册里又未对节点A的本地操作做类似“不能使用该服务器访问WEB页面”的限制的话，那么，实际上节点A就存在了“通过利用钓鱼方式来侵入节点A”的一个可能性，实际上这就是一个导入管理风险的过程。
类似这样的管理风险还会有很多，例如：允许测试机接入Internet，这样就出现了测试机暴露的风险 等等。
但这个过程类似风险识别的过程，有一定难度，所以初期需要专家接入，而且多以case-by-case的方式进行分析，不过，一旦这些case积累数量达到要求，就能总结出类似最佳实践的指南性文档，甚至可依据行业特性来进行总结。
而我个人是偏向于行业特性的最佳实践的，就如之前《技术乱谈：从客户端到业务系统》中提到的那样，如：某行业的某业务系统的某台服务器的口令规律为 X+Y+Z（其中Y、Z是指两个个可变但又易猜解的变量，而X则不变），实际上这也是管理制度上的关于口令管理的一部分缺失，而一旦该行业的case- by-case的案例积累充足，就可以直接将其作为一个管理风险条目导入到所有流程中去。
第三步：制定业务白盒渗透测试评估表单
表格中的数据是我随意写的，所以不用拘泥于其中的具体数值。
大概意思是：我已经将所有脆弱性挖掘出来（包括技术和管理两个层面），据此，我就可以从理论上推算出“攻击路径”，并且从理论上来为这条攻击路径的可用性进行各项评分计算（具体评分算法可根据自家情况而定）。
当然，可能有人会有疑问，这里攻击路径和之前梳理的业务逻辑和业务流程什么样的关系？
其实，表面从名称甚至从节点串联上看，关系不大，但只有在梳理出所有业务流之后，我们才能确定哪些是业务系统中必要的节点，哪些是不必要的，而所有的攻击路径串联也应该是针对这些必要节点进行的，也就是说，业务流的梳理出了熟悉业务外，还有确定范围的作用，另外还有一个重要作用，也就是清晰“业务逻辑”，因为很多时候攻击路径本身是基于业务逻辑的，也就是说，攻击本身可能不想我们想象中那样要获取什么样的权限，但可能仅仅通过篡改几个参数或是颠倒顺序就导致业务逻辑出现错乱，甚至破坏业务数据，这都属于攻击路径的范畴，而这一部分又是必须了解业务逻辑和业务流程之后才能勾画出来的。
现在，做完以上工作，就应该形成一张大表格，表格中记录了所有理论上可行的攻击路径及其分数，那么，下一步要做的就是验证工作了。
第四步：渗透测试 —— 验证攻击路径
最终，我们所谓的渗透测试实际上就是验证这些攻击路径，通过验证，我们会对“是否可用”和难易程度甚至危害等得分进行微调，从而形成一张真正的攻击路径表格。
至此，工作完成了80%。
现在，我们需要根据之前勾画出来的业务流来定义业务威胁类型，也就是说，不同的攻击，对于不同的业务造成的伤害程度是什么样的，而这里的伤害对象是以业务流为对象的，也就是说，我们不关心入侵是否作用和如何作用到某个节点，而我们仅关心这样一次入侵是否能进一步破坏整体的业务流程，所以，通过定义不同的业务伤害程度，将这种伤害程度再附加到上表的每条攻击路径之后，为其给出相应的分数，那么，工作就算是真正的完成了。
因为以上所有的渗透测试工作，除了包含传统的技术脆弱性外，还包括了管理脆弱性，而最重要的就是因为需要业务逻辑和业务流程作为部分输入，而同时攻击路径的输出又影响到业务流本身的安全性，所以，称之为“业务白盒渗透测试”。
6、最后唠叨几句
还有很多可能是我没有考虑清楚的，但大体思路就是围绕业务展开，而所有挖掘出来的脆弱性最终用攻击路径的手法体现，并使用渗透测试的方式进行验证，所有的验证结果不再仅关注于某某服务器如何如何，而是真正的告诉用户，该攻击路径会影响什么样的业务，而影响的程度和结果又是如何，这就是渗透测试服务的真正精髓所在！！！
http://www.room702.cn/index.php/archives/529
http://www.room702.cn/index.php/archives/531
0、也许都是瞎扯！
首先，我这个标题自然就是认为，现在国内的渗透测试已经做的不像服务了，可谓乱象丛生，一个高端的技术服务最后成了白菜，真是可悲。所以，才有此文。
当然，一切都只是根据我的经验所得，纯属个人行为和个人观点，也许你看完之后发现，这都是瞎扯淡！
1、前言：这可能吗？
08年，我萌生了这样的一个想法，在一次为其期近两周的渗透测试中细化了黑盒测试方法和流程（但迫于现状后期未能推广，仅个人使用）；
09年的一个项目中，在业务梳理数据支持下完成的业务层逻辑安全测试让我从理论层面验证业务白盒测试的方法；
10年时，在一次某集团的全国培训中讲解了方法论及实施流程等细节，得到认同，多家市公司在随后邀请以此立项，但我走了；
所以，我认为，这是可能的。
2、白菜价的pen-test：渗透测试国内现状
根据有记录的项目资料来看，我参与的渗透测试项目超过40个，其中作为主要测试人员的项目数量超过60%，而至少有50%的项目是在前期或后期与客户进行过现场交流，所以我觉得我可以为以下所描述的现状负责。
目前国内渗透测试的现状呈现以下几个特点：
a、风险评估项目中，项目经理或客户期望来自渗透测试的收益能占据技术部分50%甚至更多；
b、将渗透测试作为一个实例展现的手段；
c、靠渗透测试来卖产品；
d、单一依靠渗透测试的手段来完成某部分甚至全部网络的技术评估工作；
e、很多测试人员在进行渗透测试时对工具的依赖性太强；
f、尤其在WEB类测试中，渗透测试的深度和广度基本上是不清晰、不明确的（即，缺乏技术上的度量衡）。
以上几点，第一点（即，特点a）应该是有点争议的，因为每个人对风险评估的理解深角度不同，难免有差异，所以不多阐述，此文主要针对解决b至f的一些问题来的，但难免也会设计到风险评估，希望能仁者见仁、智者见智。
3、尴尬：渗透测试有什么价值？
从传统思路来讲，如果有危险，首先人们考虑到的就是如何防护的问题，所以安全是防护产品先于测试类产品。
而随着思想的进步，防护产品的严防死守，缺乏安全感的专家们需要一种能够检测自家防盗门的工具 —— 于是测试类产品和服务孕育而生，但每家的防盗门品牌又不同，所以有一些标准化的东西来指导测试类服务的方向，而具体的实现依靠每个安全专家自己的认识。
但就是在这其中，有那么一个非常吸引人们眼球的玩意 —— 渗透测试 —— 这个东西就是让具有良好素质的人来模拟小偷的行为来对你的防盗门进行各种破除工作，从而确定你的防盗门是否能防御小偷的侵袭。
但这里存在着一些问题。
多数情况下，要尝试破除哪扇门是客户确定的，也就是说，如果你的家中有三扇门，而你只认为其中一扇存在隐患而仅对这一扇门进行测试的话，那么无形中你就已经忽略了另外两个潜在的风险点。
换一种情况来看，如果仅仅存在一扇门，而且你也要求对这仅存的一扇门进行测试的话，看似没有问题，但还有一类小偷是飞檐走壁的，怎么就没考虑进去呢？对于非专业或是不了解盗窃行业的你来说，可能是无法想象的，所以，非专业人员制定的范围又出错了。
当然，可能有人会说，非专业人员制定范围失误，那评估小组不是要先查找整个房间的弱点吗？然后才把弱点递交给测试人员进行渗透测试啊。这其实就是另外一个问题，很多时候，渗透测试在风险评估中是与传统技术类工作和管理类工作并行开始的，因此就丧失了这个机会；而且，渗透测试人员从敏锐度上来说是高于管理调研和传统技术类工作的人员的，换言之，非测试人员在进行传统技术测试和管理调研等工作过程中，可能无法真正挖掘出能输出给渗透测试人员的中间结果，他们甚至无法将获得的结果整理成建议的模式输出给渗透测试人员 —— 也就是说，很多风险评估的内部工作并行、人员相互独立（尤其是对相互的工作了解不清晰）导致几拨人在工作中各自为战，所以经常能见到风险评估工作在收尾的时候，几拨人的输出结果难以平稳的拼接在一起，最终只得按照通用模板来生搬硬凑，然后算个风险值交给客户了事。
最后一种情况是渗透测试人员最为尴尬的情况。部分销售或售前为销售产品，或是由于客户自身对安全相关知识的不理解，导致最终产生类似这样的订单：针对XX系统进行渗透测试，测试需发现该系统的A层面、B层面、C层面的漏洞。
也就是上面提到的一种情况，将渗透测试作为一种全面的评估手段，期望通过渗透测试来挖掘出全部的漏洞，但凡是有过入侵经验的人都清楚，谁能拍着胸脯说他可以挖干净一套系统的全部漏洞？
所以说，我认为，渗透测试不过是在验证风险评估的一种结果；
或是说的更精确一点：风险评估其目标是评估风险出现的可能性，而渗透测试则是通过模拟入侵的手法来验证众多可能性中的一种或几种，而非全部可能性。因为，风险中的很多系数是在随时变化的，根本不是一个永恒不变的定数。
4、对传统黑盒渗透测试的思考
首先我需要根据我的理解来定义黑盒渗透测试（以下简称“黑盒测试”）。
我所接触的多数渗透测试都为黑盒渗透测试，黑盒渗透测试对前期工作要求难度不高，销售和售前的多数对于黑盒测试的把握也相对比较容易 —— 我见过多个厂家的数销售和售前对黑盒测试的前期工作都来自于一份内容有限的售前文档。
而这样的传统方式的黑盒测试项目实际上是有很多弊端的，包括前面说过的：
* 单一依靠渗透测试的手段来完成某部分甚至全部网络的技术评估工作；
* 尤其在WEB类测试中，渗透测试的深度和广度基本上是不清晰、不明确的（即，缺乏技术上的度量衡）；
而由这些问题引申出来一个更为严重的问题，那就是 —— “渗透测试的达成要求不清晰”。
也就是说，什么样才算是渗透测试完成？一般合同里很难清晰的界定，所以多数情况下以“客户满意”作为目标。
每当我和一些售前工作的人员提到这样的问题时，多数人也会挠头，因为他们实在是不知道应该如何在售前文档和合同中写入渗透测试的一个达成标准，很显然 —— 产品和传统服务都有一个终结点，而渗透测试本身具备以下特点：
* 第一个特点就是刚才我总结出来的：渗透测试只是验证众多风险的可能性中的一种或几种；
* 第二点也是上面提到的：渗透测试范围难以完全约束住；
这两个特点和无法确认渗透测试服务的“终结点”或是说无法明确约定“达成目标”有什么关系？我一个一个拆开来说。
第一：渗透测试只是验证众多风险的可能性中的一种或几种；
渗透测试为什么只能验证其中的一种或几种？而为什么风险评估从“某种程度”上来讲就能相对覆盖全面？
其实，各种风险评估方法也是无法保证完整覆盖所有风险的，所以我才说“某种程度上相对覆盖全面”。但是，风险评估的各种方法在其后端都有一个强大的体系甚至法规为其做后盾，虽然说具体的风险识别的时候还是离不开人，但有如此坚强的后盾作为支撑，其结果自然也就差不了太多。
而作为黑盒测试来说，又有什么样的体系来为我们做支撑呢？正是因为没有这样一个东西作为其理论基础，所以，作为一项服务也好、作为一个产品也罢，自然就出现了没有边界的情况。
这就好像防盗门的制作厂商和小偷一样：防盗门厂商制作防盗门有理论上的要求，比如：用什么样的工具，在多数分钟内无法割出一个多大的洞就算是合格；而小偷则不是如此，如果某位老大交给他的小弟一个任务：你去某某房间盗窃物品，那么，小偷到这里尝试开锁的话，就要依靠自己的经验和力量，如果没有打开，回去和老大报告，老大问到细节之处，他无非是将自己使用的方法和工具一一列举出来，而不像是防盗门厂商一样 —— 只需告诉检测者我们通过了XX认证测试。
第二：渗透测试范围难以约束；
多数情况下，渗透测试是一个天马行空、需要强大想象力的工作；
例如：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，然后根据易用性为每条测试项做一个百分比计算，最终得分按加法计算，这时，得到一个“中间分数”。
最后一点，漏洞的“危害程度”，这也需要清晰的定义，而且这又是一个直接关系到该分类的分值的问题，所以，上面仅定义了一个“中间分数”，因为这个中间分数还需要与这里的结果做一个计算，才能相对客观的体现出一个漏洞的危害程度。
我们可以拿最简的XSS来做举例，可以分以下几种情况讨论：
* 仅仅能实现弹窗，也就是说，也许是某些限制的原则，仅能alert，那么，归结为过滤不严格且是其中最低危害等级的；
* 非存储型，在URL里构造大量内容才能造成一定危害，这种情况相对来说易暴露，危害等级虽然高，但相对难实施，所以综合下来等级也只能达到中；
* 存储型，直接POST了javascript到某个页面，访问者可直接被盗取敏感数据，此时应该是XSS里得分相对最高的一个级别。
以上几个级别和对应的分数，我把他们定义为“实施等级”，实施等级的得分再与上面的“中间分数”进行二次计算，才是最终得分，这样，大概有这么一个表单：
注：以上只是一个示例说明，具体算法和权重、分数等，需根据划分的测试项和大分类自身的定义来做细化
当然，这只是一个简易表格，还可继续完善，例如：测试项对应的检测工具、对应的参考资料、CVE链接等等，都可以做入其中，这样，测试人员只需一张表格便可有完整的测试指导，而对于用户来说，只要表格中的一些测试项、易用性、实施等级等资料，即可了解测试工作包括了什么，测试的内容危害是什么，最终的分数是怎么计算的等他所关心的问题。
BTW：如果有条件的话，最好能在表单中或是表单外，针对每个测试项附加一个用例库，而用例库除了初次添加外，还应在每次测试完毕后根据具体项目情况来完善现有用例库，当用例库达到一定程度的时候，根据每次的项目目标，即可对用例库进行行业分类，到那个时候，渗透测试的行业化方向，在用例库中就能清晰的看出来了。
5、基于业务的白盒渗透测试
其实，我最终想说的重点，应该都在该部分，在黑盒测试部分，无论从技术层面做的如何细致，都是难以完全贴近用户真实业务情况的，而其结果也不过是一个纯粹的技术数字而已，仅仅对技术层起到一个“通用性”的指导作用，很难拔得一定的高度，所以，我认为，细化现有渗透测试的技术流程和技术层面虽然是必要的一个过程，但也仅仅是一个中间过程，在目前的“可改进范围之内”，基于业务的白盒渗透测试才应该是最终渗透测试的一个必然方向。
那么，怎么样进行“基于业务的白盒渗透测试”（以下简称“白盒测试”）呢？
第一步：了解业务特性、熟悉业务流程
在此需要做以下的工作：a、梳理业务流；b、梳理业务逻辑；c、确认业务节点；d、利用业务流和业务逻辑串联业务节点。
其实，这就是之前我所写的《技术乱谈：从客户端到业务系统》文章中后半部分关于业务系统评估及防护方法的前几步，也就是说，如果基于业务进行过类似的评估工作的话，那么，实际上那些输出已经可以作为此步的输入了。
第二步：导入管理风险
管理调研这部分，每个人做法不一样，因此很难有一个通用表单或工具来做集中导入。
但是，对于有风险评估经验的人来说，做一个case-by-case的东西却不太困难，我的大概思路如下：
* 串联业务流上的节点脆弱性，将节点与业务流串联完成之后（以下内容可先参考《技术乱谈：从客户端到业务系统》），节点上的脆弱性也可以按照类似的方法进行串联，简单举例来说，如，业务流与节点的串联关系为：A — B（TCP 80） — C（TCP 1521），也就是说，从A发起访问，到B的TCP 80 作为一个技术指标，然后在从B跳转至C节点的TCP 1521，这样一个业务流程完成，当然，还有反向的，就不再列举。
同时，我们会在 A、B、C三个节点上分别做脆弱性的挖掘工作（与传统技术评估类似），而依照A-B-C现有流程，结合挖掘出来的脆弱性，就可以将一条攻击路径勾画出来，例如：利用A的某漏洞，可跳转至B，然后再如何如何跳转至C，甚至通过破坏现有业务逻辑的情况下来完成攻击也是可以的。
* 串联管理上的脆弱性，至此为止，所有的“可能性”都是基于技术层面的，于是，还需要加入管理层面的“可能性”，例如：传统意义上，我们认为针对节点A的侵入都是通过远程的方式，但如果A上存在一个IE漏洞，而安全操作手册里又未对节点A的本地操作做类似“不能使用该服务器访问WEB页面”的限制的话，那么，实际上节点A就存在了“通过利用钓鱼方式来侵入节点A”的一个可能性，实际上这就是一个导入管理风险的过程。
类似这样的管理风险还会有很多，例如：允许测试机接入Internet，这样就出现了测试机暴露的风险 等等。
但这个过程类似风险识别的过程，有一定难度，所以初期需要专家接入，而且多以case-by-case的方式进行分析，不过，一旦这些case积累数量达到要求，就能总结出类似最佳实践的指南性文档，甚至可依据行业特性来进行总结。
而我个人是偏向于行业特性的最佳实践的，就如之前《技术乱谈：从客户端到业务系统》中提到的那样，如：某行业的某业务系统的某台服务器的口令规律为 X+Y+Z（其中Y、Z是指两个个可变但又易猜解的变量，而X则不变），实际上这也是管理制度上的关于口令管理的一部分缺失，而一旦该行业的case- by-case的案例积累充足，就可以直接将其作为一个管理风险条目导入到所有流程中去。
第三步：制定业务白盒渗透测试评估表单
表格中的数据是我随意写的，所以不用拘泥于其中的具体数值。
大概意思是：我已经将所有脆弱性挖掘出来（包括技术和管理两个层面），据此，我就可以从理论上推算出“攻击路径”，并且从理论上来为这条攻击路径的可用性进行各项评分计算（具体评分算法可根据自家情况而定）。
当然，可能有人会有疑问，这里攻击路径和之前梳理的业务逻辑和业务流程什么样的关系？
其实，表面从名称甚至从节点串联上看，关系不大，但只有在梳理出所有业务流之后，我们才能确定哪些是业务系统中必要的节点，哪些是不必要的，而所有的攻击路径串联也应该是针对这些必要节点进行的，也就是说，业务流的梳理出了熟悉业务外，还有确定范围的作用，另外还有一个重要作用，也就是清晰“业务逻辑”，因为很多时候攻击路径本身是基于业务逻辑的，也就是说，攻击本身可能不想我们想象中那样要获取什么样的权限，但可能仅仅通过篡改几个参数或是颠倒顺序就导致业务逻辑出现错乱，甚至破坏业务数据，这都属于攻击路径的范畴，而这一部分又是必须了解业务逻辑和业务流程之后才能勾画出来的。
现在，做完以上工作，就应该形成一张大表格，表格中记录了所有理论上可行的攻击路径及其分数，那么，下一步要做的就是验证工作了。
第四步：渗透测试 —— 验证攻击路径
最终，我们所谓的渗透测试实际上就是验证这些攻击路径，通过验证，我们会对“是否可用”和难易程度甚至危害等得分进行微调，从而形成一张真正的攻击路径表格。
至此，工作完成了80%。
现在，我们需要根据之前勾画出来的业务流来定义业务威胁类型，也就是说，不同的攻击，对于不同的业务造成的伤害程度是什么样的，而这里的伤害对象是以业务流为对象的，也就是说，我们不关心入侵是否作用和如何作用到某个节点，而我们仅关心这样一次入侵是否能进一步破坏整体的业务流程，所以，通过定义不同的业务伤害程度，将这种伤害程度再附加到上表的每条攻击路径之后，为其给出相应的分数，那么，工作就算是真正的完成了。
因为以上所有的渗透测试工作，除了包含传统的技术脆弱性外，还包括了管理脆弱性，而最重要的就是因为需要业务逻辑和业务流程作为部分输入，而同时攻击路径的输出又影响到业务流本身的安全性，所以，称之为“业务白盒渗透测试”。
6、最后唠叨几句
还有很多可能是我没有考虑清楚的，但大体思路就是围绕业务展开，而所有挖掘出来的脆弱性最终用攻击路径的手法体现，并使用渗透测试的方式进行验证，所有的验证结果不再仅关注于某某服务器如何如何，而是真正的告诉用户，该攻击路径会影响什么样的业务，而影响的程度和结果又是如何，这就是渗透测试服务的真正精髓所在！！！