时间：2023-10-25
在纵深防御建立起来之前，是不是被动挨打呢，显然不是的。我们需要做一些基础的事情，最大化的止损，虽然有些事情看起来很简单，却往往是安全事件的根源。
第一阶段是基础安全策略的实施，这一部分看上去不那么高大上，却是ROI最高的部分。这一部分大多属于整改项，不需要太多额外的投入就可以规避80%的安全问题，即使一个企业没太多安全预算，做不到全线业务实时入侵感知，也能有一个底线的基础保障，这一阶段总体上属于“饿不死”。
第二阶段是进入系统性建设，也就是涉及各个维度的安全防御手段。入侵检测等，除了技术上，还包括流程和审计需求。这是一个相对体系化的雏形，对于不是特别大的互联网公司而言，开源软件+商业解决方案一般可以应付。在这个阶段，如果对象是大型互联网公司，则应该直接进入自研之路，同步开始研发安全产品，例如HIDS、大数据平台等，自研迟早是一个无法回避的现实需求。
第三阶段，系统化建设，安全运维和SDL成体系之后，可以选择性关注业务安全的问题。通常以账号安全为切入点，之后选择主营业务中风险最大的IT流程活动做相关的业务风险分析和业务风控体系建设。
当安全运维、产品安全（SDL）、业务安全都初步成体系之后是不是安全的整体建设就算完了呢？显然不是。有这些点和面只能说是有了骨架，顶多只能算一层厚薄不均的防御网，薄弱点仍然容易被穿透，因此接下来的工作是进入运营环节，也就是所谓的PDCA的工作，把每一个防御点打磨到极致。这一部分工作很重要，但属于非前台可见的“内功”，可能不容易受到管理者的重视，但安全的Leader自己要清楚利害关系，如何在这部分工作投入资源和量化对应的KPI产出是需要考虑的问题。
最后一个层次，当以上点和面的建设都打磨得差不多的时候，安全建设进入“自由发挥区间”，这个区间做的事往往跟平台的经营状况，业务的市场地位，业务的全球化属性有很大的关系，已经无法给这个区间的事情贴标签，但也有一些可遵循的参考物，比如对标业界领导厂商。
（1）组织
有SRC，SRC不只是一个提交漏洞给奖励反馈的平台，更是一个黑白两道关系维系的渠道，有了关系渠道，就能在第一时间有偿获知（威胁情报是一个概念，实际上就是有价值的信息），这种情报不一定是机器可读的IOC，很可能就是一句话“你们的xx系统已经被黑了，你们回去查一下”，现在SRC的模式更是玩出了人民战争的味道，要发动一切资源举报威胁信息。较成熟的SRC团队还做一件事情：漏洞根因和影响面分析，再后面的流程SRC团队基本不再干预。
3个典型职能部门是：运维、产品开发团队、安全部门中的防御体系建设小组，下面是这三个部门的工作分工：
1）运维团队负责跟系统、数据库、中间件、网络基础架构相关的补丁和配置更改的具体实施工作，例如第三方开源服务器软件Nginx、OpenSSL、MySQL的漏洞。
2）产品团队负责产品相关的代码级别的漏洞修复（如果是自己开发的产品的漏洞）。
3）安全防御体系建设小组负责在相关的入侵感知体系中update对应该漏洞的检测规则。
（2）流程
1）一般性的漏洞跟普通的bug修复流程一样，由安全部门接口转交业务线接口，之后由业务部门修复后提交新版本进行发布，遵循的就是普通DevOps发布流程，并无特殊之处。至于漏洞本身的“修复–验证–发布–监控”等PDCA的流程涵盖在DevOps之中，跟普通的版本发布是一样的。
2）对于比较严重的漏洞，通常由安全、运维、产品3个职能的Leader组织一个会议，制定专门的漏洞修补和应急计划。在这个场景下，关键角色到场的临时会议效果远大于制定一个流程，流程可以有，但不是重点。形象一点说明，上午开会制定计划，中午实施发布，晚上持续监控，可能一天就完事了，其过程主要是还是参考ITIL等做一些风险规避措施。
3）SLA——根据漏洞类型和影响程度决定，一般性的漏洞也不必连夜修复。高危漏洞，有实际攻击面的会连夜赶工，高危漏洞全网push补丁可要求在24小时内完成，总体上认为这个指标跟自动化运维能力有关，但是确认影响面和受害范围仍属于安全的职责。
4）假如短时间内无法修复，使用临时规避措施，前端设备提供“虚拟补丁”即一条针对该漏洞的阻断规则（前提是有这种能力），或者短期内关闭某些功能，添加访问控制手段作为临时规避措施。
（3）技术
1）发现得快依赖于入侵感知体系，从HIDS、RASP、WAF、SQL审计等各个维度，这是互联网安全防护体系的核心。
2）修得快则依赖于持续集成和自动化发布工具的支持，开发人员如何一键发布，属于互联网公司每天的日常活动，这个能力依赖于开发工具、运维工具建设，职责上跟安全没有直接关系却对漏洞的修复效率产生潜在的影响。
3）同样，自动化运维能力主要属于运维的职责，但也会影响漏洞修复和安全策略实施的效率。
总结一下，实际上有3件事：1）发现的快；2）修的快；3）修不了，临时规避。
