安全服务反思：把渗透测试做成服务企业安全分享!

hack69  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天；
　　
　　测试深度 & 测试内容：
　　
　　这两个指标关联性很强，也是我所认为的细化黑盒测试的重点，所以放到一起来说。
　　首先，我们需要明白到底测试些什么样的内容，也就是说，我们