同时，我们会在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、最后唠叨几句

　　还有很多可能是我没有考虑清楚的，但大体思路就是围绕业务展开，而所有挖掘出来的脆弱性最终用攻击路径的手法体现，并使用渗透测试的方式进行验证，所有的验证结果不再仅关注于某某服务器如何如何，而是真正的告诉用户，该攻击路径会影响什么样的业务，而影响的程度和结果又是如何，这就是渗透测试服务的真正精髓所在！！！