安全建设从0到1
你好，我是何为舟。
在专栏中，我们聚焦于深入剖析安全领域的各种概念和技术细节。但只要你真正从事过安全工作，就一定会感受到，安全其实是一个非常重“管理”的工作。
如果只是单纯对某一项技术了解非常透彻，对于公司整体的安全来说，其实意义不大。这就如同 “木桶原理” 所揭示的道理：多个60分的安全产品形成的纵深防御效果，要远大于一个90分的安全产品。
因此，在这一篇加餐中，我想尝试从更宏观的视角出发，为你详细描述该怎么规划和设计一个公司的安全能力全景架构。
安全发展阶段
我会将安全建设分为三个阶段：救火阶段、产品化阶段、业务化阶段。下面，我们一一来说。
救火阶段
通常来说，一个公司的安全投入是远滞后于业务发展的。当业务处于早期的时候，服务规模不大，即使出现了一些安全问题，工程师们也基本能够自行处理掉。但是，当业务发展到一定程度之后，随着服务规模扩大，问题的频次和复杂度开始上升（比如天天被爆出来漏洞、被“种上”了挖矿木马、甚至被勒索攻击），普通工程师就很难应付了。这个时候，安全问题已经成为了阻碍业务发展的主要矛盾之一，老板才意识到需要找一个专业的安全人员了。
那么如果你在这个时候被选中，应该做些什么呢？
悲观一点来说，你其实没得选，只能立即去处理各种各样的线上安全事件，也就是所谓的“救火”。但是，你必须意识到，哪怕你为了处理安全事件天天加班加点，老板也不会给你好绩效，因为老板的预期是不出事。
因此，你的工作目标其实是一边尽力救火，一边想办法降低安全事件出现的频次。实现这个目标的核心要点在于“以点带面，举一反三”。简单来说，就是在处理安全事件的同时，顺便去解决一类问题。
比如，当业务出现了某个Web漏洞被利用的事件时，处理过程基本上就是分析漏洞原理，然后指导业务修复。但你同时可以考虑以下几个方案：
- 在Nginx上做一个简易的过滤器，拒绝带恶意payload的请求，形成WAF的雏形。
- 引入一个开源扫描器，帮业务把同类型漏洞扫出来，一次性修复掉。
- 采集Web日志，通过关键词检测其中的攻击特征，更早发现利用痕迹。
- 联合业务开发应急工具，一键封禁掉恶意的IP来源，更快止损。
此外，其他救火过程你觉得难受、低效的地方，都可以尝试去拓展一下，尤其是当某一类安全事件重复发生的时候。
随着各种各样小安全工具的积累，不但我们救火的效率会越来越高，安全事件出现的频次也会快速收敛，你就有更多时间精力去打磨工具，进一步提效，形成一个正向的循环反馈。老板也会惊喜地发现，随着你的工作展开，业务发展逐渐不再受安全事件所困扰，自然会在功劳簿上给你记上一笔。
值得一提的是，很多小规模的安全团队（甚至是一个人的安全团队）往往会遇到过多的线上安全事件，“救火”任务把资源池打满，没有富余精力去做安全工具沉淀的事情。这个时候，就应该果断跟老板汇报，争取更多的安全资源投入。
产品化阶段
通过救火阶段的安全工具沉淀，你已经将安全事件压制在了一个较低的频次。但是，当你想要将安全事件进一步清零的时候，你会发现你临时开发的安全工具，总会遇到各种各样的问题，难以应付复杂的业务场景。这个时候，你就需要考虑进入“产品化阶段”了。
产品和工具的最大区别，在于其稳定性和兼容性。通过充分的需求调研、功能设计、技术架构等工作，使安全产品能够高效覆盖公司的大部分业务场景，起到四两拨千斤的效果。因此，产品化阶段的关键词是“设计”。
安全行业的一个特点是，它的成本投入往往只占业务的5%以内，却需要管理业务所有的安全风险。如果你去搜索安全行业技术分析报告，会发现有上百种不同的概念和技术，每一个细分领域都有着自己独特的赛道玩法。所谓“设计”，就是需要在这些技术中，选取真正能解决问题的东西，然后合理分配有限资源，最终拼凑成一个高效的安全防御体系。
既然是“设计”，意味着没有标准答案，需要你根据公司特点和行业经验来进行深度思考。但以下几个原则大抵是通用的。
第一，定义主要矛盾。虽然说安全讲究木桶原理，需要面面俱到，但实际上面临的外部威胁压力并不是均匀分布的，而是会根据公司业务特性产生差异。
比如，几个头部的互联网公司最突出的安全能力就会有所差异。Google在Web安全和软件安全上做得最好，因为其主营业务是搜索、邮箱等Web服务；Microsoft则在系统安全和办公安全上做得最好，因为其主营业务是操作系统为核心的企业办公服务；而Apple则在产品安全层面做得最好，因为其主营业务是iPhone、iPod等硬件产品。
因此，设计的第一步，是了解公司业务特性，定义主要矛盾。判断在哪些地方面临着首要威胁，需要集中精力建设，哪些地方威胁相对较轻，可以先忍忍，依靠救火来兜底。
第二，纵深防御。有了相对明确的方向后，就是在对应方向上设计纵深防御体系。
纵深防御的中心思想来源于概率论，假设4个相互独立的安全产品，针对同一起攻击事件的生效概率是60%，那么至少有一个安全产品能够生效的概率就超过了97%。这也是在攻防对抗中，防守方所占据的最大优势。
然而，纵深防御并不是一味堆砌重复的安全产品，概率论成立的前提条件是“相互独立”，这也是设计过程中需要时刻关注的点。通常来说，我们会将安全威胁描述成一种路径，并拆分成不同的阶段，并在每个阶段部署相应的防御措施，以起到相互独立的效果。
比如，Web安全的路径是“业务开发了有漏洞的代码，攻击者通过扫描等方式，比安全团队先一步发现了漏洞，并利用相关漏洞产生实际的影响”。从纵深防御视角，我们可以通过提供安全开发规范来避免业务生产漏洞；通过WAF来阻断攻击者的扫描行为；通过黑白盒扫描器先于攻击者发现漏洞；通过IDS来检测漏洞被利用的情况。
第三，外挂优先。所谓外挂，是指通过低耦合的方式，在尽量不让业务做改动的情况下，去解决安全风险。常见的安全产品基本都属于这个范畴，如防火墙、WAF、IDS、EDR等。这些产品在基础架构层面部署，通过插桩的方式截取应用行为日志，并加以分析、检测和拦截等。外挂的低耦合特性，可以大幅度降低安全产品落地的阻碍，毕竟不需要业务投入额外精力进行配合，省去了沟通协作的成本。这是安全建设初期，快速取得成果的捷径。
第四，可运营性。任何一个安全产品最终都需要依靠持续的运营才能够真正发挥效果。比如IDS和EDR均属于旁路系统，最终的产出其实是一条条的告警，依靠人为研判才能实际发现风险。哪怕是最基础的防火墙和WAF等，也需要持续维护规则，才能适应业务的持续迭代。因此，你在设计安全体系时，必须把这部分工作也考虑在其中。每新增一个安全产品，都意味着你会在后续的工作中花费一定的精力去运营它。如果安全产品过多，导致运营精力将资源池打满，那这些安全产品反而变成了一种累赘。
业务化阶段
通过产品化阶段的设计和能力落地，你基本已经拥有了一个还算成熟的安全防御体系了，能够从容应对常规的安全威胁。你当然可以停留于这个阶段，持续性地打磨安全产品和机制，通过流程化、自动化、AI等不断提升效率。
如果你还想让安全团队进一步发展壮大，可以尝试探索一下业务化的安全场景。比如，HR、财务等系统具备更高的安全要求，需要设计单独隔离和加密机制；业务场景下会出现各种各样的逻辑漏洞，如支付场景下的0元购，以及现在比较火热的越权风险等。
之所以会有这个阶段，是因为随着和业务合作的加深，有大量的细分场景是无法通过所谓的通用安全能力满足的。就好像过去互联网喜欢聊“中台”，但随着公司规模扩展，“去中台”成为更主流的趋势。安全也同样如此，目前头部的互联网公司，基本都为每个细分业务线配备了单独的安全团队，来更好地满足业务发展诉求。
因此，不拘泥于传统的安全技术技能，专注于解决各类业务定制化诉求，是目前我关注到的安全发展终态。
总结
今天，我将安全建设阶段拆分为救火、产品化、业务化三个不同的阶段，整体描述了一个企业安全从0到1的过程。
整体来说，救火阶段需要关注“以点带面，举一反三”，尽快摆脱层出不穷的安全事件干扰；产品化阶段需要关注“顶层设计”，避免走弯路；业务化阶段需要关注业务需求，不要自嗨。
通过了解这个发展路径，希望你可以找到安全在每个阶段应当关注的重点，避免瞎忙一场，得不偿失。需要强调的是，安全并没有标准答案，结合公司的业务特性、资源投入的水位、外部风险的高低等各种因素，去合理规划安全建设路径，才是你最大的价值贡献。
如果有新的想法，欢迎在留言区一起分享和交流，我们下一节见。