关于信息安全工作方法论的一点猜想

　　"""

　　/*以下观点来自本人有限经验及思考，如有不对之处请指正，欢迎讨论*/

　　"""

　　首先，应当指出本人是（信息）安全从业人员，国内比较普遍的说法是网络安全，概念上有很大的交集又有所不同，Gartner认为更合适的说法是数字安全，包含了安全从业人员涉猎的诸多领域。科技在进步，我们的生活发生了翻天覆地的变化，以前从事计算机科学领域相关的人被称作IT工作人员，但随着移动互联网的发展我们进入了大数据的时代，马云提出现在已经是DT时代，我们对自己的认知也应该有所变化——不仅是概念上的变化，更是观念上的改变，如今企业掌握的数据可能恰好是最具价值的资产。

　　小议信息安全与生活中的安全工程已经很明确的指出网络安全是计算机科学、通信领域及其延伸中的一个细小分支，而在这个小小的行业里从事的不同工作又可以分为Web安全、二进制安全、移动安全、无线安全等。对于非安全研究人员的从业者来说，他们需要做的事情可能既有渗透测试、也有安全加固，还会有应急响应、代码审计、安全培训等等，但其工作的价值很多时候却不甚明显，无法靠发技术研究或漏洞分析的文章证明自己的工作——安全很多时候都是不可量化的。

　　乙方从业人员服务于客户，他们的价值可以从卖出去多少产品、服务，或者市场对工程师或公司的认可程度来评估，但也有很多模糊的界限。甲方的工程师和安全专家做的事情和乙方不同，但实质上是一样的——止损。安全工作不直接创造价值，但能减少组织受到网络攻击所引发的损失。说到这里，不得不提到一个至今尚无定论的话题：（信息）安全的本质是什么？几年前，多个业内专家认为安全的本质是信任，安全研究人员则更倾向于安全的本质是漏洞或者攻防。半年前，我自以为是的认为信任的本质存在不足：

 

　　肯·汤普森在Unix系统中留后门、未授权访问、Web领域的SQL注入/跨站脚本，甚至业务上的任意账户密码重置或者越权操作都可以归结到一个信任问题。

　　我信任他的代码，所以我使用了；我信任他的操作，只会访问自己的功能；我信任用户提交的数据，它们是无害的... 先不说把责任推给信任本身就存在问题，网站遭受DDOS而陷于瘫痪、攻击者发现系统漏洞而直接控制我的主机、数据在传输过程中被篡改和伪造，这样的案例毫无疑问是安全事件，但却无法用信任的概念来解释。软件、硬件存在漏洞，是要说厂商辜负了我的信任，因为没有生产不会被攻击的产品？遭受中间人攻击，是因为我觉得不会有人干坏事，信任这个太平社会？就这两点而言，如果硬要说安全的本质是信任问题，恐怕是搞错了信任的主体和对象了。再说DDOS案例，信息安全经典的机密性、完整性及可用性模型中，遭受DDOS便丧失了可用性，假设遭受SYN洪流攻击是信任对方主机会建立完整的三次握手，那么NTP反射攻击又当如何解释？根本上来说，是因为遭遇了自身处理范围之外的负载，为什么不说成是对潜在威胁的短视和无知呢，难道我遭受野兽袭击，也要归因于我信任大自然不会伤害我吗？

　　因此在我看来，无论是保障业务的持续可用、数据/资料的合理存储与使用、系统加固与问题排查、还是漏洞挖掘与攻防研究，既然其中的每一个元素与环境都是我们理解的安全，就无法用信任问题来解释其本质。人类文明中的所有冲突，人都是参与和执行的主体，根本无法用信任问题归纳其本质，甚至其中一个很小的子集——信息/系统/网络/数据/业务安全都不行。归根到底，安全的本质和所有问题的本质一样——人性。

　　即便有一天强/超人工智能发展到脱离人类的控制，可以轻易入侵到人类的数字网络，所产生问题的本质仍要追究到人性。前面谈到的信任问题，一方面类似于社交关系中的信任，另一方面源于系统设计者、实现者（或为程序员）的无知——想当然认为用户是可信任的、系统或程序是可信任的，无能——没有足够的能力和资源解决出现的问题。将程序员拉入这一评价其实不公平，因为人不是神，不可能不犯错、不可能不无知、不可能可以达成所有的期望。然而事实是遇到很多系统设计者/程序员/维护者真的是"一无所知"，应用程序太多可以被利用的缺陷，却不思修复与改善，致使主机沦陷、业务中断、用户信息被恶意使用并非天方夜谭。再说攻击者，病毒、木马、流量劫持、数据库脱裤、页面篡改等等，构成这些行为的动机是否能跳出：荣誉、憎恨、利益、政治、信仰等因素的范畴，再一次回顾到人性的优点与弱点。再退一步说，安全与不安全，评估和影响的主体是谁，哪些因素会改变或影响评估过程及结果，这些还不是与我们息息相关。
　　综上，虽然名目偏大且笼统，我认为安全的本质即是人性——懒惰、贪婪、无知、获利、信任、道德、法律...

　　

　　上文提到乙方的工作是从组织外的视角保护客户免于遭受损失——页面篡改、流量劫持、植入木马、DDOS、信息/数据泄露等，甲方的工作是从组织内的角度减少可能遭受的损失，实质上都是止损。如果这一推测符合事实，那么我们就可以很放心的说安全的本质是止损。毕竟无论信息安全、出行安全、食品安全，我们不断强调安全，为的就是避免来自内部或外部的某些因素或行为产生不利于我们当下及未来的结果，从这一点来看安全的本质是止损一方面比信任和攻防更全面和准确，另一方面也不像人性那么形而上与笼统。

　　以国内阿里云为例，除了提供云计算的基础环境及运行软件，自带的云盾提供了防御攻击、查杀木马的功能，安全能力甚至成为了一个卖点。安全能换来用户的信任与安心，他们可以因此减少在安全工作上投入的大量人力与财力，在这里云盾就是乙方。另一方面，国内目前有很多以keenteam、盘古、绿盟科技安全研究院、360独角兽团队为代表的攻防研究团队，他们的成果通常不直接作用于客户，也不作用于组织内部，在这里安全似乎更多关乎攻防。但长远来看，无论独立还是公司附属的攻防研究团队，他们的技术实力可以取得外界的认可——获得信任，也能吸引其他有志之士的加入，接下来他们会将技术应用于服务或产品交付给需要的团队或组织。所以无论云盾还是攻防团队，在其功能与行为背后，无论导致了怎样的结果——经济利益、战略优势、社会地位或名声等，根本上来说都是保护自己或外部个人及组织免受不期望看到的损失，证实了安全的本质是止损。

　　解决了安全的本质是什么的困惑，就像回答了人类是什么一样，这样才能知道自己要去往何方。但正如上文指出安全很难量化，很多工作并不像开发一个APP或写个前端页面那样，工作成果试试仔仔摆在那里。大概也是这个原因，2014年第四季度同事去一个客户那里交流时，对方上来就问你们有没有渗透测试方法论？在对方看来，根据个人（非权威）经验实施的渗透测试的工作量和效果不好评估，需要有一个理论上的依据帮助他判断做了些什么。原本理论指导实践是很好的，但"安全"虽然是个形容词，也隐含着使役动词的意思——使...安全，安全的状态和环境是不断变化的，大多数时候实践比空洞的理论有价值得多。方法论要不是实战派向理论高度进军的结果，就是不懂的外行科普高谈阔论、振振有词的有力依据。看到过这么一句话：

　　"急功近利、或者目的明确的副作用就是非常浮躁，浮躁的环境下，方法论就会大量出现。"

　　方法论为量化安全工作提供了部分指导依据，但并没有就此解决这个问题。花费的人日可以作为判断工作量的依据，但除非时时刻刻盯着，难以判断有效工作量。系统被入侵了，敏感数据被窃取了，该怎么判断安全工作是否有价值？控制一年内被入侵主机不超过多少台，或者补掉多少个高危漏洞都可以作为衡量工作效果的有效指标，但方法论无法帮你计算出这个具体的阈值，还是需要根据实际经验和业务进行判断。过于重视方法论也容易导致做技术的不如写文档的受重视，毕竟结果是工作成果的最好证明，而文档则是一个有效展示结果的媒介。关于如何让安全量化，笔者不做过多推测，那无异于纸上谈兵，倒是可以谈一谈实际工作中遇到的责任的划分问题。

　　国内网络安全行业的发展，可以追溯到上世纪90年代，知名安全专家yuange1975、flashsky等人从1995年左右开始接触攻防相关的技术，2001年中美黑客大战后，这个行业才慢慢变得广为人知。当时（及在此之前）对黑客的认知与现在有所不同，如今大众口中的黑客更倾向于骇客，而最初的黑客实际大致相当于今天的极客。从肯·汤普森在Unix系统中留后门，到1988年莫里斯蠕虫、2010年的震网病毒、再到现在各种各样的APT攻击，黑客应该是一个很善于编程的群体，或者说他们原本就是厉害的程序员，"黑客技术"都不过是副产物罢了。

　　顶级的黑客往往是顶级的程序员，虽然很多安全技术很好的人并不十分擅长编程，但反过来程序员不懂安全的例子却比比皆是。我认为造成这一现象的原因跟程序员水平参差不齐有较大关系，也和人们的观念及所处环境有关——大家都仅仅关注自己那狭小的领域。举个例子：前文所说的渗透测试，无论出于什么目的、使用什么手段，都是测试的一个分支，其他常见的测试还包括功能测试、压力测试、兼容性测试等。渗透测试是安全测试，后者根据实际情况要求的技术从简单到困难不等，一些简单的安全测试完全可以由开发人员或者功能测试方面的人完成。笔者遇到的很多情况是，岗位职责划分太细（有形或无形），每个人就管着自己一点点小事，然后就出现了下面这种情况：

测试人员：发现了XXX越权漏洞，详情发给你了，麻烦赶紧修复。
...过了一段时间...
开发人员： 问题已修复，请复测一下。
测试人员：数据／环境有问题，没法验证，麻烦提供下数据／环境。
开发人员： 在切换环境，稍等。
...过了一段时间...
测试人员： 问题没修复啊。
...过了一段时间...
开发人员：已修复，请复测最新版本。
......

 　　在找到了漏洞/缺陷后，很多简单的问题本可以由开发人员自己复测的，他们知道环境、数据什么时候可用，又知道缺陷详情，处理这个问题效率应该是最高的。而测试人员则等待数据和环境进行复测，期间不便做其他事情，结果浪费了大量的时间。上面的例子只是假设性举例说明，请勿对号入座。

　　我理解甲方的同学要协调内部各项资源完善安全体系、修补漏洞，与外部白帽子沟通缺陷情况，这种情况下安全从业人员做的不再是纯技术的事儿。对于没有独立安全部门/团队、或很多项目依赖于第三方厂商的组织，他们往往有很强的需求，而且总是在年初就制定计划、排出预算，此时第三方就是资源，而这个资源利用率往往并不高。频繁出现等待、重复简单工作的情况，本身是对资源的巨大浪费，而且外部资源需要申请，如果不用完，下一年度的预算就会削减，即便有更强的需求也只能等到下一年度才能申请足够的资源，这就导致了申请很多的资源但没有合适的利用渠道，再次导致浪费。

　　涉及到安全测试，理想的情况是如2015年Geekpwm大会的演讲嘉宾Dmitry Vyukov那样，Vyukov大神拥有Intel黑带开发者头衔，在Google负责测试并开发了工具对内核进行Fuzzing等测试，典型的集顶级开发人员、安全研究人员与安全测试人员于一身。或许这样对很多安全从业者来说才是比较好的选择，各大公司SRC的很多人也在走着类似的路线，说实在的，作为技术人员我也愿意走这样的路线。