业务安全的上岸体历（-）

在甲方做业务SDL的几年，在落地方面也做了不少努力。一是得看着业务高P的脸色，二是得假装硬气的扮猪吃老虎，一路走来可谓是一把辛酸泪。

闲话不多扯，我们团队在SDL方向，针对公司现状进行威胁建模，进行了多个维度的治理。

在本文笔者会根据过往的治理工作，在业务建设从0到1进行剖析，给大家落地经验的参考。

基础审计运营

在安全建设初期，我们会着重针对事前、事中、事后为基准，进行SDL基础能力补全优化。

在事前的维度，我们会以域名和服务Key为单位，对前后端的资产进行梳理，嵌入SOC进行运营管理，并进行安全审计流程闭环。

在项目上线前，我们会对提测前的代码进行人工Review，进行安全合规的风险评估。

对于安全检查大致包括：

• OWASP TOP 10
• OWASP API Security TOP 10
• 常见的逻辑漏洞

此外，我们还会根据研发同学的习惯，制定相关核查制度，进行重点检查，提升检察效率。

对于数据合规会重点检查：

• 数据接口是否脱敏
• 数据存储是否加密
• 传输是否加密
• 数据关联性是否解耦

还有部分没有全部例举出来，会严格的按照合规白皮书的标准来实施。

在审计完毕后，会在SOC平台进行数据留存，发工单向业务同学督促修复。

如果出现了延期，系统工单会进行逐级递进，通知其上级，直到业务方响应闭环为止。

虽然这些制度可能比较难推行，但确实是非常有必要的，这需要自上而下的认可才能完成。

只有把代码安全的指标，像代码质量考核那样，加入业务研发同学的KPI之中，才能真正引起大家对安全的重视。

在每个项目的大型迭代时，我们也会进行人工安全审计。

除了针对迭代出现的安全问题以外，主要还会检查部分误添加的线上测试数据，以及研发同学无意中进行的硬编码、弱口令配置、敏感数据打印等等。

由于当时工具比较原始，除了借助半自动化的代码审计工具（如IDE、Fortify）以外，也会读取第三方设备收集入库的日志，自行写脚本筛选核查。

当然这些工作，后面也逐步被接入CICD流水线的自动化平台所替代。

在各个系统正常运营期间，我们需要做的是借助各种安全入侵防护产品（自研or商采），譬如IDS、WAF、RASP之类的进行纵深体系检测，再借助风控与法务部门的力量，对出现的风险事件进行溯源和应急响应。

为啥这里说的是纵深检测而不是纵深防御，其实是早期在使用安全产品的时候，更多的需要去借助人工去复核，没有很好的进行产品联动。

当然大家可能觉得是因为没有采购同一家产品，造成了兼容性缺失的问题，才会导致工作量指数级别上升。

其实笔者觉得这块儿的工作，无论是厂商本身来做，还是依靠团队人工对信息流进行补齐，都是相对次要的。

更关键的点在于，是我们需要优化好安全运营规则，让更严重的事务和更优先的级别，及早的被我们感知到并进行应急处理，而不是淹没在海量告警和镭射动态展示大盘之中。

自动化能力建设

在这个阶段，我们投入了更多的精力去建设团队的安全自动化能力，以求解放人力去搞研究工作。

在此期间，我们针对性的对缺失的安全能力，对标业内互联网企业的标杆进行剖析，发现主要有几个点是亟待改善的。

我们利用线下测试环境和镜像流量，重点建设了主被动扫描器（DAST），其中包含黑盒漏扫和基线核查平台；同时，也针对交互式扫描（IAST）能力进行强化，对代码执行进行污点插桩和编号，监控系统的输出和落地执行结果，方便向源头进行追溯。

针对白盒扫描（SAST），我们接入了多个扫描引擎。除了质量CICD流水线平台自带了安全插件进行优化外，还对商业化的白盒安全产品进行了外采接入；除此之外，自研的引擎里，还加入了针对Git平台的关键词和配置、组件版本依赖检查（支持分支），保障在接入流水线后，能尽可能完整的覆盖到所有代码的检查。

针对这块儿，我们着重对数据库里存储敏感数据字段进行核查，也结合XIDS对流量里包含的敏感数据进行了监控。

同时，我们还结合DLP监管的记录，以及对明暗水印机制的设计，对数据外泄事件起到了一定的防控作用。

每个公司的技术栈是不同的，所以针对内部应用最多的技术栈代码，针对性的开发安全SDK也显得比较重要。

除了本身对研发团队提出安全编码制度以外，我们还对研发团队提供了安全SDK，也提供了IDE安全检查插件，通过微侵入式的方法，在一定程度上保障了代码的安全。

当然，这样产出的代码，可能在交付给第三方合作厂商时，会单独进行脱敏分支开发，在一定程度上会提升成本。但考虑到这方面的业务量不多，还是合算的。

风险链路治理

在SDL建设到了这个阶段，我们已经有了一定的安全自动化能力，那么如何去实现突破呢？

在梳理业务链路中的风险后，我们开始针对威胁进行建模，从体系架构上自上而下进行治理。

其中，我们重点关注了IPDRR和STRIDE模型，并辅以DREAD模型进行威胁评级，针对原有安全能力的缺失进行优化联动，也对现有的安全风险点进行收敛治理。

从不同的业务场景，以及不同的数据流程，分别对风险定制了削减措施，分配人力形成项目组，推进治理优化工作。

具体的风险链路大盘，这里由于内容敏感不方便直接发出来，我们就简单谈谈重点项目的建设工作。

在原先的工作中，我们自己的资产库更多的会去依赖于运维部门的注册信息，然后我们内部通过扫描器进行的资产补充。

后来发现这样做有个问题，我们在针对细粒度的资产标签，譬如新增端口、机器所属域、服务类型列表、迭代接口等等，无法及时的掌控，这样对我们的纵深体系的监测是不利的。

所以在我们着重进行了这方面能力的补充，通过被动监控流量，以及主动对代码AST树进行梳理的方式，对复杂的调用进行网状关系绘制，以及对标签关联的资产进行聚类。

这样，在出现问题后，我们也能很快的进行阻断和溯源定位。

针对内部的一些通用型漏洞，由于信息关联度问题，我们在原来的工作中没有很好的进行横向打通。

在不断加强内部对于0day、1day的识别能力后，我们能更好的去识别入侵事件。

在后面的SOC运营平台的建设工作中，会针对漏洞元素进行细粒度的手动标签，也支持了自动化识别，加强了针对资产的测试环境和边界环境，及时进行横向巡检，将风险扼杀于摇篮之中。

在针对诸多风险进行治理时，必不可少的需要考虑到对边界安全进行收敛。

在这方面的工作中，我们可以考虑做以下的工作：

• 针对出入的流量进行重点核查
• 对开放的外网服务进行一键式深度防护
• 启用备份机制，随时对出现漏洞升级故障的边界服务进行替换
• 对边界资产进行即时扫描防控
• 自动化核查应该把边界的优先级提升到最高

我们前面对于资产库的优化工作，也是能为边界安全的治理提供效能的。

我们原来的业务方接口人，都是资产定位到项目组为止。

这样的话，很难在具体风险发生时，最快速度联系到个体接洽解决，在推进修复的过程中也很容易扯皮。

所以后来我们采用了业务方接口注册制度，让业务方主动去做项目归属个体和人员backup的填写，并且结合内部的人力资源存留的注册信息，定期向业务方确认项目变动情况。

总之，我们需要保障在项目存活的安全生命周期中，实现人员响应可控、权限周期可控、人员备用可控。

在第三方合作体系的建设过程中，我们也参照业内的情况，做了不少工作。

在这方面的治理上，虽然有不少标准可以参考，但并没有统一的方案。

其中需要治理的内容有：

• 第三方合作商的业务
• 第三方SDK的引入核查
• 第三方流量接入时的监控前置
• 第三方账号监控的核查

这些东西太多，只能稍微例举几项。真正想要做好，需要对各业务线的情况进行深入了解，结合企业自身的情况进行定制。

同时，这也是外部审计公司很难在短时间内给出完整方案的，需要内部的安全人员去做更多的探索。

后面的话，针对这块儿可能会单独提出来跟大家聊聊，讨论下有哪些通用的解决方案。

指标订立和回归

在针对SDL实现流程化管理，对治理成果进行验收时，我们需要重点注意的是，得对前期订立的指标做验证回归。

这些无论是在安全工作的KPI中体现，还是向业务方进行成果透明化展示，都是有意义的。

这里举例几个方面，给大家参考下指标订立的原则：

我们针对需要重要防控的项目，在风险收敛比例和收敛耗时方面，是需要订立一定的指标的。

如果在这期间发生了安全风险引起的资损事件，会侧重考核我们是否做出了合适的应对措施，针对资损事件进行弥补和挽回。

对于漏洞指标订立，我们会针对高危漏洞的数量、漏洞类型趋势进行统计。

其中，会区分外部SRC提交和内部发现情况，从不同维度进行趋势计算。

同时，我们针对黑白盒自动化漏扫的召回率和精确率，也会做同期的月度、季度、年度对比。

最终，我们也会添加插件数、服务数、接口数等作为变量，从综合层面去判定成果，避免在判定权重方面发生缺失。

这个有点类似于QA的质量考核指标，如果一个服务经常出现代码风险，经常出现漏洞，通常这个服务的健康评分会比较低。

这个是针对业务方的，也是对我们治理结果的的反馈之一。

对于服务安全，我们订立了几个指标，譬如漏洞修复率、安全产品接入率、漏洞反复率、风险发生率、鉴权接入率等等。

最后，通过单个服务乃至业务线作为基准元素，我们也会反过来对比考核各个业务线安全的质量，从而在更高的维度评价业务安全的产出。

结语

上面的一些总结，是从业务安全早期治理内容来讲的，涉及的内容相对简单。

后面的续篇，会继续对单方向的重点进一步剖析，以及针对具体实施细节进行描述。