福利 I 企业安全项目架构实践分享

       如果在传统行业和互联网公司都工作过，会发现一个有趣的现象。一些传统行业在企业安全建设上会对外宣传他们经过了各种安全认证、使用了HTTPS证书、数据加密储存了，而安全团队也把重心放在《网络安全法》、《信息安全等级保护》、各种行业规范、各种安全测评机构的安全测试上。当了解到数据重要就把员工各种监控起来、申请权限要经过十八道审核，恨不得手机都不能带进公司，最好再搜下身。殊不知这些仅是安全建设中一个微小的点，早期优先级不那么高的点，甚至都不足以影响到常规的入侵路径，而企业觉得已经高枕无忧了。

        反观互联网行业，本就有开放基因，做事则直击要害。但安全行业不同于传统软件行业，常常会出现产品不懂技术，技术不懂架构，导致资源浪费无法集中重心。而安全架构的目的除了把握好方向、设计整体安全架构外，最重要的是知道在什么时候做什么、如何做才能发挥最大的作用，尽可能的减少和避免会遇到的坑、弯路。知道每一个项目的背景、思路、技术方案、技术难点及成果产出等。

        漏洞会以不同的形态出现在不同载体上，业务设计不合理存在漏洞、编写网站的代码中存在漏洞、存放网站代码的服务器存在漏洞、服务器连入网络可能存在漏洞等等。

       既然这么多地方存在安全问题，无法同时做好所有方向，所以需要针对企业不同资源投入、业务量级、问题情况来针对性的制定安全架构。整体可以以入侵生命流程来制定长期的安全架构，模拟攻击，做好应急，彻底防御，深入每个点、联动每个点。

       渗透测试是模拟攻击者去攻击网站，从而找到一些安全漏洞。代码审计是通过分析应用代码中的入参处理、函数调用来找出其中存在的漏洞。在业务简单、公司起步阶段可以投入一些资源进行黑白盒测试，将一些显著的安全问题挖掘出来并修复掉。

       随着业务线的扩张和公司的壮大，上线的项目越来越多、代码量也越来越大，已经没办法只通过人工的方式去挖掘漏洞了。此时需要引入自动化的黑盒漏洞扫描和白盒代码审计，实现快速的安全发现能力。

       每天都在产生新的漏洞，这类情报都需要在第一时间内获取到，并进行对应的应急响应处置。除了公开的情报，很多时候需要渗透到黑灰产的圈子中了解他们最新的动态也能更直接的应对。

       仅靠自有系统和人员无法及时发现所有漏洞，此时应当建立对外的安全应急响应中心（SRC），向外部表明开放的立场，去收取白帽子或用户发现的安全情报和漏洞，并给予礼物和现金奖励作为回报，同时也搞好和白帽子的关系。

       设立一个专门的小组来处理外部提交的漏洞的审核和内部提交的安全需求的评估，小组应当由有渗透经验的人员参与。项目规划时针对技术方案的安全建议/项目上线前的安全评估/SRC收到的漏洞评估/扫描器扫到的漏洞评估。

       当安全应急响应中心（SRC）收到外部白帽子提交的漏洞后，前期由小组一起评审确定漏洞等级和奖励，并在此过程中不断的完善的评估方法，后续对于曾经出现过的漏洞按照历史经验进行审核，新型漏洞小组一起评审。

       当收到公司内部新产品或项目的安全评估时，由一人了解业务具体情况，并反馈给小组一同评估和测试。

       当出现重大安全事故时，由安全核心人员和技术负责人、公关部门等组成的安全委员会来决定应急处置方案。

       安全应急响应中心（SRC）的漏洞都是一个一个收集的，比较容易找到责任人，也比较容易跟进修复。但黑盒漏洞扫描和白盒代码审计所发现的漏洞可能是成百上千，无法由安全团队逐一进行推进修复，此时可以先用防御手段先抵挡住以缓解因修复时间过程导致的空档期，为每一个技术部门定一个安全接口人，漏洞由各团队安全接口人认领，此后的修复状况由安全接口人跟进并同步至安全团队。

        漏洞的发现地方太多了，考虑到审核/去重/统计等问题，需要由一个统一的地方来存储管理。包括漏洞的初始化/已确认待分配/已分配修复中/已修复待上线/已上线。对于各种来源的统计/各种危害等级的统计/各种类型的统计等等。并根据这些统计数据来针对后续的项目规划做好数据基础。

       针对每一种漏洞，安全人员需要针对性的复现测试，明白其中的原理及可能绕过的方法，并一次推导出万无一失的修复方案，并将这些方案整理成方便开发人员理解和阅读的修复文档。

       文档中应包含漏洞的介绍/业务例子/代码例子/利用方式/进阶利用方式/修复方法及引用的文档规范等。

       发现漏洞后，需要由产生漏洞代码的编写者来进行修复，一是属于他的业务，二是加深其对于该漏洞的认识。但由于每一位开发人员的技术水平/安全意识各不相同，往往对于修复文档的理解不同导致修复完的代码存在被绕过的二次安全问题，所以针对经常出现的漏洞，比如XSS，应当由安全团队开发出修复组件，开发人员只需引用组件并调用相对应漏洞的修复方法即可修复。修复上线后再由安全评估组进行修复验证测试。

       运营新媒体（微信公众号、微博等）和安全应急响应中心（SRC）。

      由于非常多的安全问题往往是因为人的一个小疏忽，或者是根本不知情/无意识的操作，只要稍微了解一些就不会出现。所以针对开发人员的安全开发培训是很必要的，针对常见的安全漏洞讲解其中的例子和原因，让开发人员都了解一些过往的安全事故，避免再犯。除了已经入职的人员外，对于新人也需要设立专门的入职培训，来避免重蹈覆辙。

       参加内部和外部安全会议分享，了解前沿技术。同时也将做得好的一些地方分享出去。

        制定各类安全规范，让所有事情和流程规范起来，避免过度依赖经验。比如编码安全规范、框架/版本使用规范、各类安全策略规范、漏洞应急规范、漏洞评估规范、漏洞修复规范、应用上线规范等等。

        维护和白帽子、厂商关系，关注安全会议最新技术动向，维护媒体和政府相关部门关系。

        除了需要通过各种攻击的手法将漏洞发现出来并修复掉之外，还需要主动防御以对抗遗漏的漏洞和不断更新的漏洞。每一个层面都存在攻击，所以对抗也必须是全面的，同样也需要找准重点。

       早期的时候由于老板对于安全重视不够，人员、资金等资源投入不足，所以需要尽可能的做一些投入资源小而结果突出的项目，来避免广撒网导结果产出不理想的情况，也为了避免陷于磨灭人员斗志的困境。比如在前端安全上，内容安全策略（CSP）就是一个比较好的选择。了解清楚它的原理和规则配置，就可以在短时间内灰度/上线所有业务，结果也很直接，大多数的广告劫持都将被拦截并上报，除此之外还有很多附加产出，能够拦截常见的反射型XSS/点击劫持/iFrame劫持等等。针对XSS盗取用户身份认证造成的强大危害，可以在生成SESSION ID的Cookie时，增加HTTP Only选项，能明显降低XSS危害。

       毕竟早期资源有限，同时也只有少量项目符合投入资源小而结果突出的原则，此时应当借助外部力量。通过一些外部的资源支撑来获得最大化的结果，比如使用按结果付费的众测服务来找到自身哪方面比较薄弱，并通过这些薄弱类型来选择对应的防御措施，这些措施可以是购买外部商业化产品，也可以是选择开源项目的二次开发。

        通过对开发人员的安全培训，使其了解常见的安全漏洞利用方法和产生原因，发动所有开发工程师成为安全研究员。

       中期人员相对充足，预算也有了一些，就需要做一些资源投入大而结果同样突出的项目，来提升技术沉淀，避免让技术人员觉得成长不够。比如网络安全上，Web应用防火墙（WAF）。NGINX为主流Web服务器的今天，使用像VeryNGINX这类的开源项目，能够帮助企业快速的搭建一套常规漏洞拦截与新型漏洞防御的系统，起到立竿见影的效果。

       后期人员充足后，就可以将所有的安全项目"点"都布局好并深入，由点到面的防御工事，改变原先突围一层即可直捣中心，并做好所有项目间的联动。

       入侵者如果通过Web服务获得服务器权限，则需要经过WAF/IPS/IDS/蜜罐/服务器监控等层层把守，当突破所有限制拿到这台服务器权限后，也发现无法渗透更多服务器、造成更大的影响。