SDL.vs.入侵检测，源头和末端选哪头

在安全领域，安全开发过程SDL和入侵检测完全是两件事，似乎是两个不能拿来直接比较的东西。

之所以硬是把两个东西放在一起比较是基于以下的命题：手中资源恒定的情况下，投入在SDL上更有效，还是投入在入侵检测上回报更高。在《互联网企业安全高级指南》中提过对于安全负责人来说，整个决策都是基于投资回报的。

（注：安全负责人不等于安全管理岗位，后者跟产品经理一样只是一个岗位名称，而前者至少等价于一个公司总监或VP级的分支领域管理者）

传统的观点肯定是从源头去解决问题，即通过SDL从开发过程把漏洞率降到最低，不只是解决编码级别的漏洞，同时通过威胁建模和安全设计解决架构级别的漏洞。这种观点基于的背景是出现了漏洞早晚是要修的，与其被动救火，不如在生命周期的前端卡位，晚修不如早修。

入侵检测是运维环节的事情，是对网络基础架构、系统、容器、应用、数据在线实时状态的判断，入侵检测能做到的效果是：根据局部或大面积的入侵和被利用的状态反推漏洞的出处，最后去修补。从过程视角看，它并不覆盖研发过程，跟漏洞修补是脱节的。

回来看SDL的起源，SDL起于微软，对微软而言，过去是一家软件公司，现在转身云计算，它的生态从底层操作系统，开发工具，上层数据库和应用都是自己开发的，有漏洞也都是自己研发的产品的漏洞，所以SDL对这种模式特别有效，大部分漏洞都需要在研发环节消化掉。

但是反观互联网在线服务，云计算领域的安全，整个生态中，对大多数厂商而言自己研发的产品可能只占一部分，有相当大的漏洞比例可能是诸如Xen，Linux，PHP，Nginx，MySQL，Struts等，这些漏洞修补都变成了运维环节的事情，根本不在SDL的范围之内。即SDL做到100分也解决不了运行时系统上的那些漏洞。

你可能猜到我想说什么了，不过上面的原因还仅仅是其中一部分。更深层次的需求是：大规模互联网在线服务的安全防护需要做到一切有害行为可及时感知，一切攻击和入侵产生的破坏影响可控。具体解释一下这句话：

1.大量的踩点，有目的或无目的的扫描这些可以“不感知”，因为这里面垃圾信息太多，但对于踩进自己防御圈内的每一步都应该有感知，包括扫描时找到了有效的SQL注入点，尽管还没开始“正式利用”，但对防御体系建设者来说应该是需要知道的，之后例如上传和生成webshell或类似于killchain等每一步都必须有感知。

2.只要攻击者没拿走用户数据，即便完成了前述所有步骤，而在最后一步之前把对方压制并赶出自己的防卫圈就算安全工作60分了，因为没有造成实质伤害，但需要忙乎一阵。

3.也基于此，即使很多产品带着漏洞上线，即使漏洞被利用了能第一时间感知并立刻采取修补行动，即便Struts漏洞没有补丁在线裸奔，有人利用了被渗透了也能即时感知和阻断，这样就能做到整体风险可控。但是同样的，即便你SDL做到了100分，这些东西仍然高度不可控。

基于这种思路以上就构成了分层防御，一切可控的安全运维体系，前提是有一套强大的入侵感知系统。

现实生活中不存在SDL和入侵检测只选一头的情况，用极端状况下只选一头这个问题是帮助理解实际的安全工作思路。

写到这里，再问一遍，极端状况下，SDL和入侵检测只能选一个，你选哪个？

答案是：对于云安全，互联网服务，选入侵检测，它的不足是于当漏洞数量过多时，修补会比较吃力，尤其是架构级漏洞。

对于传统软件研发，选SDL，显然这个更有效。

末了，撇开这个问题回到现实场景中应该是两者并重，但投入比例和优先级上面已经说了。