很久没更新了，工作比较忙，稍微有点时间就宅起来看美剧和动漫了，也没怎么跳舞和聚会。下面这个帖子是前同事写的，觉得不错，给大家分享一下：
分享一下我对做IT审计工作的评价
这是我第一次在这个论坛上发言，以前一直是一个潜水员。
个人背景：职业生涯做过的公司有软件开发公司/系统集成商/IT咨询和服务商，从事过程序开发/系统集成/项目管理/市场营销和管理工作，加入Big4之前工作了8年，在某Big4工作了2年多，今年离开的。职务一直是Manager。
业绩：Peak Season要做近80家客户/110多个GAMx（我服务对象是Local Finance Industry），Audit Quarlity得到广泛认同，1年AQR抽中3个，都是No Finding，Slack Season半年完成近200万的Revenue，从build relation，Proposal，FieldWork做到最后Archive file和收钱落袋。没有一个项目是所谓Partner给的或者是从别的地方现成的Transfer过来的（倒是Transfer了两个项目给了BJ，所以在BJ IT Audit department口碑很好），其中成功撬走了另外两家Big4的银行客户的IT Advisory单子。
关于我在这家Big4的故事可以再写一本《
圈子圈套》4，用小朋友们的话就是属于传奇人物的那种，这里就按下不表。
Topic1 IT审计相对于审计来说，要轻松一些，但不会轻松很多
My Opinion：认同，IT审计项目小而多，GCR没有多少技术含量的，但是基本一个Staff一周要做2个以上的GCR（个别银行和超大型企业除外），所以小朋友的事情很多，不轻松的。07年Peak Season的时候，我们部门Staff Uti个人单个月最高的是180%左右，就是每个月OT charge 22×8×0.8=140小时，我们当时还特意了解了一下这个Staff的情况，他还真没有虚报OT。一直是一个人同时做2-3个项目。每天2-3点下班，早上9点就下Field的。结果落下腰一直不好的毛病。一般最忙的几个月平均是在120%左右，所以某人说的一个月charge 300小时OT是不靠谱的，08年开始就几乎没有什么OT可以charge了。
Topic2 IT审计价格太高
My Opinion：这里面有一些误解，举个例子，假设财审一个项目的预算是100万，成交价可能是30万，recovery rate30%，IT审计给财审的报价30万，财审会complaint说全给你，我都没有钱赚了，其实不是的，IT 审计的报价是没有乘Recovery Rate（因为IT审计没有参与和客户的Budget Negotiation，是不知道Recovery Rate）所以IT审计的实际价格应该是30×30%=9万，很多财审的Staff可能忽略了这个乘Recovery Rate的步骤。
Topic3 省IT审计成本的办法
My Opinion：作为IT审计经理，我给客户IT经理打一个电话，不用半小时，我都基本能够感觉出这个客户ITGC的evaluation的结果了。所以针对那种利润率不高，entity死多，IT水平很低，到处用用友金蝶（甚至更烂）的财务软件的非IPO项目，往年ITGC Ineffective客户不怎么改的，或者初步评估ITGC 结论很可能是Ineffective的，你就让IT审计和做个preliminary Understanding + Walkthrough，TOC完全不用做，而且做一小部分Walkthrough就能得出ITGCCatagory Ineffective的，也不用把Walkthrough做全。你们自己直接按照ITGC Ineffective来做，自己小心一下ITGC对自己的审计procedure的影响就可以了。这样可以少不少Budget。审计风险也很低（都Ineffective了还有什么风险，而且Audit Efficiency也不错，不用花一大把的IT Audit Budget再作出一个Ineffective的结论，但是要让IT Audit Manager签好字），千万不要自作聪明按照ITGC Effective来做，那样你AQR抽中了话会死的很难看的。ITGC Ineffective没有什么大不了的！只要你熟悉Audit Procedure，知道ITGC Ineffective影响那些ACR和Electronic Evidence，知道采取什么样的措施来Cover这个Risk就可以了。有些项目，你和IT审计经理签个Memo，认为经过IT Professional的Preliminary Understanding，能够得出客户的ITGC Ineffective的话，成本更低。当然，这里就看财审经理的Soft Skill了。
Topic4 IT audit出了四大没有前途
My Opinion：完全同意。其实IT Audit在四大里面也是越来越没有前途。如果一个人整天拿着一个checklist看看汽车方向盘好不好，轮胎有没有气，签字盖章。他敢说他是汽车方面的专家，要到汽车厂做总工，这个人一定是脑残了（就象某个中了北斗神拳的号称IT Audit manager出去做CIO一样）。ITGC只是“General”的东西，相对IT只能称之为“毛”，连“皮”都没有资格。一般企业找IT Audit一定要有“实践”经验的+有Audit经验的人才要。
IT Audit的职务，除了大型金融机构和Fortune100里面的部分企业外，不会有公司设立这种职务的。而且就算你在四大做IT Audit，到企业里面也不是很对路子的，因为他们很清楚ITGC是个垃圾（来自我的某个客户和后来曾经面试过的金融企业资深内部审计高管的评语），他们也要很多IT HandOn的经验和Security方面很Technical的经验，这些四大出来的大部分是不具备的。IT Audit在Big 4是附属地位，而且地位只会越来越低，所以这个时候大学一毕业来做这个真是个人职业生涯的自杀行为。当一个职务在市场上只有很狭隘的空间，还能有很好的薪水的话，大批人进来只会让它崩盘直至打回原形。
Topic5 IT Audit能做好IT Advisory
My Opinion：笑话。一个只懂得“毛”的人就敢给客户做advisory，看在公司名字的份上，客户才没一脚把你踢出门去。IT Audit的Executive很多人不直接Touch Client，因为他们超过一半的利润来自IT Audit（至于沙丁猫说的转型到以IT Advisory为主，我不认同，因为他们是不敢放弃IT audit那么好赚的钱的
——喵注：转型这个是老板说的，我冤枉）。他们还以为客户是“人傻钱多速来”的那种，人家天天IBM/HP/Accenture的顾问泡着。看到你BIG 4会热泪盈眶，以为你是来给他传授先进经验的传道士？清醒一点吧，除了个别Compliance的要求，见你们只是浪费他的时间。
很多Partner在公司里面横着走，出了大门什么都不是，还社会中高层，再中一记北斗神拳！传说中某Partner见某银行的科长，科长是脚搁到桌子上和他说话的。另一个Partner，客户的CIO直接在很多人的会议上把报告扔在地上，说这种垃圾不要放到我的会议上来讨论，还得赔笑脸。自身没什么Skill，不懂如何Handle Client。Advisory是要帮助客户解决问题的，不是你效力的公司很牛，客户见到你就叫Daddie了。你给个不痛不痒，牛头不对马嘴的report就付钱的。除了给Regulator的报告以外，BIG 4自身培养出来的力量是不可能做好Advisory的。
有时候看看我以前的一些经历，觉得就是《
大腕》里疯人院那段的现实生活版。
原帖链接：http://andersen.com.cn/cgi-bin/cgi-bin/view.cgi?forum=12&topic=15077
12月8日更新IT Advisory相关内容：
从事IT Audit部门里面的IT Advisory两年多来的体会
引言
曾经听说过一个很经典的冷笑话，说某Big4的面试问题如下：如何把一头大象塞进1个冰箱里，标准答案是Step1. 打开冰箱的门 Step2. 把大象塞进去 Step3 把冰箱门关起来。一直觉得很奇怪，这个居然是笑话？直到在某Firm里面工作了一段Advisory时间后，才深刻体会设计这个笑话的达人后面的深刻意思。
上面这个笑话反应做Advisory工作的一些潜规则：
1.一定不要理会客户的需求，尽量把它们忽悠到你自己的路子上，笑话里客户的挑战是把大象塞进冰箱（一个明显的问题就是体积的问题），用Firm的思路就是完全回避这个问题，尽量把客户忽悠到自己的路子上，变成大号ITGC或者ACR，很多客户已经被Firm光辉灿烂的名字砸晕了，我们说啥就是啥，如果你提出说客户其实想要别的东西，你会被你老板骂死的，敢说皇帝没穿衣服的人一定被老板列入黑名单（不过这种客户已经越来越少了，而且在客户付钱之前突然意识到自己被忽悠了，还款也就成为一个麻烦事情了）。
2.Deliverable一定要是Finding And Recommendation，千万不要去Implement什么东西，更加不要出具什么承担责任的东西。所以只能交付这些Step1/Step2的东西，千万不要下手真去帮客户把大象塞进冰箱里，更不能做塞进去我收多少钱，塞不进就不收钱的事情。
3.Deliverable一定要很漂亮，要很有逻辑性，PPT要让老板觉得astonishing，老板就Q这些东西。
4.Deliverable一定是放之四海皆正确的道理，除了可以借鉴的Bible上的话，千万不要有自己的观点，千万不要和客户的实际情况做任何customize的工作。
5.客户气的吐血也不要紧，骂到狗血领头也无所谓，只要钱到手，一锤子买卖也无所谓，反正还有Client Service Partner来搽屁股。
IT Advisory能干些什么？
一类是Sox/CSox/SAS70等类似项目，这类项目是IT Advisory的主流收入来源之一，工作思路很吻合IT Audit的方法，不需要特别额外的知识，一般Senior来做基本没有问题，我原来部门大部分这类项目不用自己去打客户，跟在BRS或者AABS后面就可以。我没法对这类工作做什么评价，因为我只是个别看过他们的工作内容和交付品，没有做过这种项目。我没有做这类项目的经验。
IT Security，我倒是可以说一些内容，给你们解释各类项目的内容/我的经验以及知识点。IT Security大约可以分为两个领域，Information Security management方面和Information Security Technical方面。
Information Security Management的核心是ISO27000系列（一般人喜欢称为27001，其实是有区别的。27001只是27000系列的总纲，具体的某些方面的内容有002/003……很多内容，部分还在Draft中）。27000项目的后半部分实施和IT Audit思路相似，根据前期Risk Analysis的结果，Draft RCM，所有的Control是从27002里面选，不用自己想，需要补充一个Statement（SOA， Statement of Applicable）来解释为什么不选择27002中某些Control，然后把这些Control和客户现有环境中的Control对应起来，做一个Gap Analysis和Recommendation。然后让客户把这个Management System Run起来就可以了。当然，前期还有Draft一个很High Level的ISMS文件，ISMS文件的框架和必须包括的内容在27001里面有定义的。
27000系列项目对EIC/FIC的最大挑战有两个：
1.定义范围和管理层Buy-in，这个活是前期做的，但是范围没有定义好，事后进行修改，会累死人的。好的EIC会在这里阶段很好地引导客户来做Scope和Buy-In，同样，客户往往在这个阶段来评判Vendor是不是有经验。如果业务部门没有Buy-In，想做好这件事情会很难，业务部门很多时候会想当然的，这是一个IT项目，只是IT部门的事情，这是一个理解误区。举个例子：我曾经做过的一个客户的核心信息资产之一是它的工艺流程图（PID），在服务器上了很多的Control，但是打印出来的PID却摊在总工的办工桌上，门的钥匙扫地阿姨有一份，阿姨每天提早半小时来打扫卫生，竞争对手是一墙之隔，使用同一家清洁公司。当时我们只能把范围扩大到把工厂里面可能会出现PID的部门和场所都放进来，否则单Review 服务器是没有意义的，说服他们当时还是费了一些力气的。
2.清晰描述出范围内信息资产和流程/系统/业务部门之间的关系，然后在理出原有的流程/系统/部门已有的控制手段，同时和业务部门进行Risk Rating以及Risk Analysis。这个活很费劲的，但是很涨经验值。
做好上述两点，后续的工作IT Audit小朋友就可以轻松地干活了。EIC只要在Deliverable的Quarlity上能够控制好就可以了。
常见的错误：
很多人上手把注意力放到清点信息资产（数数电脑/服务器什么的），绝对是错误的。27000保护的是信息资产而不是存放信息资产的设备(但是你必须把所有可能存放这个信息资产的设备全部罗列出来)。
从头帮客户Draft一套Information Security Management System，大部分客户有一堆的Policy，很讨厌又添加了一堆的Policy，所以在逻辑关系上要帮他整理出一套成系统的ISMS管理体系，从Policy的制定上，适当做原有Policy的调整和增补就可以了。
另：启动27000系列的项目，很多是以Security Awareness和Security Survey开始的。做这类项目的技巧在于熟悉各类企业常见的Incident，Common Weakness, 和对27000的熟悉，难点在于如何Draft和customize一些Survey的Questionary，在inquire的时候，如何能够缓解客户的心理压力，如何进行合理有效的问题询问并一步步深入和展开。因为往往A部门的线索可以引导你去问B部门一些额外的问题。往往好的Survey的结论是很Astonishing的，特别是你能够做出一些明显的统计图来。除非客户没有钱，否则他都会让你来做27000项目的。当然，里面有很多Soft Skill。
总结一下：
从事Information Security Management Advisory工作，首先熟悉ISO27000系列的内容，对客户所在行业的Industry的特点要理解，平时收集和积累一些information Security的案例，然后对一些工具使用和设计要比较熟悉（比如SOA / RCM / Risk Analysis），强调工作步骤中前后内容的一致性和逻辑性（谁么内容推导出什么结论再推到出什么方案），不需要太多的Tech方面的知识，如果为了做27000系列的服务，考CISSP是多余的。
IT Security Technical方面：
一、System Hacking
曾经有一个小朋友下field时候打电话问我，说他碰到一个麻烦事情，客户系统跑在Windows98系统上，但是公司的Knowledge库里面没有Review 98的脚本，问我怎么办？一句话，不用review，直接判定System Fail。这个有趣的问题就衍生出很多的问题了：
1.黑客是怎么攻击系统用的？
黑客攻击系统的基本原理就一条：利用系统的漏洞，拿到系统管理员权限。万变不离其宗。
2.什么是安全的操作系统，或者说不容易被黑客攻击的？或者凭什么认为某些系统天生就是不安全的？
在CC（Common Criteria）文件里面，对一定安全的操作系统的级别定义是C2级，在CC后续的一些规范里面，好像是定义成EAL4级以上才是安全的操作系统（好久没有时间读这些东东了）。C2级别的一个重要特征是操作系统具备这样的控制：当非系统管理员登录到系统，是无法获得系统管理员权限或者口令的。Window2000/XP以前的操作系统虽然微软自己说是C2级别的，但是习惯上大家都不认为它是C2级别，因为它有安全漏洞。
3.什么样的安全漏洞？
大家在登录Window XP的时候，有没有想过系统存在什么样的机制，来保护我输入对的口令可以进入，输入错的口令就不能进入？是不是有个什么地方放了我的口令文件，验证的时候拿来比对？对了，Unix和Windows系统都有一个文件是存放所有系统用户口令的，一般被成为SAM文件或者PSAM文件，一般系统提供一种加密机制（通常为Hash）来将这个文件进行加密，否则大家都能打开这个文件，岂不是没有秘密可言了？C2的操作系统，它能够提供一种控制，只有系统管理员才能读到这个加密文件，普通用户是不能读SAM的。所以小朋友仔细想想你们review System的脚本第一个Control就是读某个文件的属性，看Password有没有被加密成“******”，还要看系统是不是配置成TBC（Trust Base Computing）的，就是这个道理。Windows2000以前的操作系统，是个普通用户都能读这个加密文件SAM，所以他们被拒绝列为C2的安全级别的操作系统。
4.SAM文件在哪里？
很多人想问SAM文件在哪里？我记不住了，但是有很多脚本工具能够帮你从系统中直接导出加密的SAM文件，会Google就可以了。
5.SAM文件如何解密？
Hash算法是单向算法，理论上你拿到hash值是无法逆向导出密码明文的。但是全世界最顶级的加密算法都挡不住一种密码破解算法，就是我拿口令从00000000开始一个一个试，这种笨办法才是无敌的破解加密的算法。
6.如何使用笨办法来破解？
有很多的工具可以来破解SAM，当时开发这些工具的人员主要出于以下的目的，很多用户忘记自己的密码，这些密码和某些文件的权限有关，所以要求系统管理员帮助恢复密码。这些工具就采用了上面我说的笨办法来蛮力破解，你们要是Google一些Top100的安全工具，里面至少有5-6个，但是名称都是系统管理员密码恢复工具，不会说自己是黑客工具，这些工具非常傻瓜化了，如JtR（John the Ripper），连界面都是Windows话的。
分享一个我在Firm里做过的System Hacking的案例：
情况：客户提供一台他们IT标准配置的机器，准许我介入内部网
目标：证明给他们异地的CIO，他们的内网管理有漏洞导致我可以使用这台机器获控制CIO机器
客户的系统是Windows XP，完了，傻眼了，因为客户给我的是普通用户帐号，我是没有办法导出SAM的。但是，在2000年左右，有一个著名的黑客大会叫Back Orifice（针对MS的BackOffice）里面专门开发了一个脚本，当你用普通用户权限进去的时候，启动这个脚本去替换系统里面某一个无关紧要的进程（你只要按“Ctrl+Alt+Del”就能看到系统进程的窗口了），然后退出系统，然后再次用普通帐户的权限进去系统，你的权限能自动升级成系统管理员了。当然几乎所有的杀毒软件把这个脚本列入恶意代码的范围，但是你只要给它稍微改头换面一下就能解决问题了。我在此之前只是听说过这个脚本，后来是从Firm里面海外的某大师手里获得的。百年招牌就是百年招牌，有理由的啊！
然后就是导出SAM，Crack SAM，得到系统管理员的口令。
其实大家看看自己的笔记本，你登录的时候你都可以看到有一个Administrator的帐户，这个就是系统管理员的帐户，所有人的机器上都有，有这个帐户和密码，只要你能被连接的上，可以远程控制你的机器做任何事情。我当时的事情是放了一首立波啤酒的广告歌到CIO的桌面上并播放了一下，以纪念英年早逝的歌曲原创者，这首MP3是他送的。老外认为这首歌还挺好听的。
7.这种系统管理员密码恢复工具不是无敌了？
不是的，这种工具的工作原理就是老老实实一步一步打黑虎掏心，所以它的最大问题是效率。05年前后，国内一家加密所的朋友做过测试，长度为7，有复杂度要求的口令，用IBM RS6000破解时间约为7小时，长度为8以后时间长度是以指数级别上去的，据说要用月计算。所以想想Firm的口令复杂度和时间有效性的要求就明白了。我曾经试图破解FIRM的SA的密码，用T60算了3天就没有信心了，后来一问边上的小朋友都知道，看看了它的复杂度，估计有生之年都不行了。
二、Social Engineering
接上篇，我试图花费很长时间Crack的超长又复杂的密码其实坐在Batch上的小朋友都知道，多么荒谬啊！这在information Security领域称之为Social Engineering，这是公认的最省力最有效的Hacking。
报纸上常有报道，说某IT大亨告另外的IT大亨，说他雇人整天翻自己公司的垃圾来找有价值的文件，这也是Social Engineering Hacking。简而言之，Social Engineering是采用一些社交技巧来获得企业的商业密码。关键是：人是那么好骗的吗？
这里涉及到另外一个技巧，称之为Risk Accrue，我和一些Senior在做Security项目时，进行Risk Analysis时，通常提醒他们，Risk Accrue是一个需要重点关注的地方。很多人因为做ITGC多了，很惯性地去思维一些Risk，认为是Low Risk，轻松放过，其实不是的。一个低的Risk1+低的Risk2+低的Risk3就会Accrue成一个High Risk。而这种High Risk往往是要命的。
分享一个案例：
某公司雇佣我们做一个Social engineering的测试。它的CIO在系统里面给我们开了一个测试帐号（假设名叫AAA），不告诉我密码。整个测试只有CIO知情。
目标：要求我们无论采用任何方式，拿到这个帐户的密码。
我除了这个帐户名称/公司名称和客户的系统管理员在上海外一无所有。首先上网了解公司的背景和电话号码，我清楚地知道，我绝对不能直接打电话给客户的IT系统管理员，因为一般你打电话给系统管理员，他是要验证你的个人信息的。我很有可能露馅。而且有一点可以明确，一般管理较好的公司，系统管理员是无论如何不会告诉你，你自己设定的密码的。
我做的第一件事情是打电话到他们北京Office！！！我和前台的小姑娘聊了一下，知道他们上海的系统管理员叫BBB，北京这边相对应的人叫CCC，当然关于密码设置还是要找BBB。我打电话给北京的CCC，成功地了解到上午BBB因为病假不在办公室，下午回来以及BBB的手机号。然后我抓紧给BBB的座机打了一个电话。
到了下午，我打电话给BBB的手机，他说他在位置上，然后我打了他的座机，向他解释上午就找过他了（显然他是可以验证这点的）同时告诉他，手机号码是CCC告诉我的，而且上午他生病的信息。我是北京来上海出差，新员工忘记密码了等等，BBB毫不犹豫地就重置了我的密码并告诉我新密码。
从这个案例看出，CCC如果不那么热情告诉我一些额外的信息，我是没法让BBB快速信任我的，这是一个Low Risk，因为CCC的行为没有直接威胁到企业的信息安全。同样，BBB应该有效合理的验证我的身份，但是他以为我的身份已经被验证了，所以他就重置了我的密码。CCC的行为也是一个Low risk，因为他确认他验证了我的信息，但是忽略了这些信息不是直接信息，是间接信息，他甚至忘记了问我员工的ID号码！但是两个加起来就是一个High Risk，结果是我拿到了密码，我们成功地绕过了公司关于口令保护的严格规定。
三、Network Security
Network Security的工作已经越来越傻瓜化了，应该感谢无数的前辈以开源共享的方式为我们做了很多的铺垫工作，但是也就是因为这个特点，这个工作已经越来越没有卖点，业界的注意力都转到了App Security和SDL里面了，这两个会在后续中谈到。
1.侦查敌情
当客户允许你进行网络安全扫描时，先用一些工具扫描一下敌情，了解网络里面到底有些什么OS/Router/DB/Middleware在工作，使用那些软件/版本号多少，开放了哪些服务，整理出一个客户网络环境的大致的结构图来，这些自动化的工具随便找一篇黑客文章就可以找到。
2.网络安全分析
拿到敌情图，如何分析它的弱点呢？你必须具备以下技能：非常熟悉各种版本各种软件的常见安全漏洞，你要一个一个试探这种漏洞在每个系统中是否存在。这是真正的黑客大师才能干的事情啊，我们怎么可能具备呢？感谢那些大师，他们无偿地维护和更新一个数据库来让我们及时更新各种漏洞库：CVE。感谢那些大师，他们曾经开发了一代自动化扫描工具来帮我们自动化扫描和分析漏洞，Nessus。不过近两年来，Nessus也被商业化了 由于Nessus自动集成了CVE，所以我们所做的工作只是分配给Nessus扫描的IP域，然后启动，出去喝咖啡，回来看Nessus出的报告。
3.分析Nessus报告
凡是自动化的东西都可能会有误报，或者有些是扫描出来的缺陷是客户这个环境下必须存在或者特有的，比如客户出于开发的必要就开放了个别自定义的端口，所以需要和客户进行漏洞发现的discuss。这里自动化工具是不能帮你了，你必须根据Nessus报告的错误ID到CVE中找到这个错误的具体内容，理解后才能和客户discuss，因为客户往往会把Vendor叫来和你PK，你要是功底不深，会被客户Challenge的。
4.Review Firewall Policy
我做Network Security Assessment的时候，一般会去做Firewall Policy review的工作，这块工作也容易出finding。为什么呢？一般电子商务网站（比如说网银）的系统更新很快，上的新模块和模块功能设计更新也很多，客户会很重视开发的Version Control和Change Management, 这也是ITGC关注的重点之一。但是客户往往会忽略Firewall Policy的及时Update，Policy里面有很多Legacy是以前测试留下来的或者已经废弃的Module留下来用的，而且网络结构一变更，地址重新分配以后，很多人已经说不清楚为什么有些Policy还存在于Firewall里面了。到后来，谁都不敢去删除一些Legacy Policy，因为删除了可能就影响功能正常使用了。
基本来说Network Security已经成为一个Common Sense的东西，绝大部分客户也熟悉，所以也没有什么特别精彩的可以show出来。
补充一下：
这里提到的内容大部分是我做的IT Advisory的经验，一般IT Audit是没有什么机会接触这些项目，没有什么Knowledge可以通过Internal Resource可以学习到的，这些经验是我加入Firm之前就具备的。
千万不要有小朋友以为IT Audit很精彩，进来都能做这类项目。这些只是我利用我自己的knowledge，在Firm的平台上为客户提供的我认为“有价值”的服务。
四、应用程序安全App Security和软件开发安全SDL（Secure Software Development Lifecycle）
到现在为止，能够把App Security和SDL做成功的人真的可以是做Security做到顶点了，我曾经几乎能够摸到了这个顶点，可惜没有这个运气。
就像前面说的，Network Security已经成为一个Common Sense的东西了，客户都会自己做，而且相关风险发生的概率已经越来越小，更多的安全事件是发生在应用层的安全。这个可以看看最近几年的安全报告以及银监会的相关安全风险提示就知道了。关键是怎么做。
一个思路是类似于Nessus，用一种业界公认的工具来进行扫描，问题在哪里呢？Nessus有一个强大的CVE来支持，应用程序安全的CVE在哪里？虽然每年OWASP会公布Top Ten的报告，几乎我测试过的所有工具都宣称他们遵循OWASP Top Ten，但是谁都没有给我一个类似CVE这么强大的database，用一句Auditor的话说 Assurance不够，而且Top10 的定义还是有一些含糊的，Scope不清楚。虽然有开源的APP Security Scanner（如Paros），和卖的极贵的商业版本软件（如IBM的App Scan）和一些本土软件，我都测试过了，performance都不满意。感觉有点虚。
另一个思路，从程序开发的源头来阻止安全问题的发生。这就是进入了SDL的领域。SDL是微软的亲生儿子，在微软的开发员网站上有一堆的SDL的资料。微软关于SDL的架构和相关工具软件已经接近完美。但是微软的SDL在客户化过程中有1个难点：在SDL的测试过程中，微软的工具服务对象是它自己的开发环境：.Net和C#，微软没有解释为什么用它推荐的工具就能基本解决所有的开发领域的常见漏洞，当然它有这个足够的技术牛气能说这句话。
但是，很多客户的开发环境用的Java和其他的工具，并不完全用微软的平台，如何能够找到和微软平台类似的测试工具，这个工具还能覆盖开发过程中尽可能多的安全漏洞，这些测试软件能够完美像CVE和Nessus这样成熟。同时能够使用与微软的SDL项目管理流程中去。正是一个潜在客户提给我的挑战。
这个客户在咨询SDL项目时要的是什么？客户显然不要一个Step1/Step2的流程，因为这个微软网站上都是这个东西，客户花在这个事情的研究上的功夫不亚于我们。客户要的是“把大象真地塞进冰箱”的能力，而不是一个好看而无用的塞大象的工作手册。在整整两个月里我不停地回答客户的Q&A，做很多的Research，等到客户终于申请下来经费，准备启动这个项目时，我已经离开了，当然项目客户也不愿意有什么后续了。有点可惜，不过我现在所做的工作和这个又有一点关系，可以重新启动了。
