秦波：大型互联网应用安全SDL体系建设实践 – 作者:kelvin2294

如需查阅更多嘉宾分享，请关注“君哥的体历”公众号。

提示：本文有6479字，阅读大概需要20分钟。

【分享议题】大型互联网应用安全SDL体系建设实践

【分享嘉宾】秦波

【嘉宾简介】在互联网荒芜时期蹒跚前行，作为安服老兵曾实践和标准化一些服务类型：渗透、评估、应急、培训，也是国内某top安全产品（第一款 waf）的早期研究人员，留下一些教材、国标、专利、工具和技术文章。2017加入滴滴，网络安全部负责人，包括SDL、移动安全、渗透蓝军、反入侵团队，从零开始建设 SDL 体系，经历了工具化 -> 平台化 ->自动化阶段。

【活动时间】4月3日本周五晚上19:00-20:00，60分钟。

【活动形式】嘉宾通过文字形式，在“金融业企业安全建设实践”、实践二群、读者群三个微信群内就“SDL安全体系实践”话题进行同步直播分享（约四十钟），之后是互动提问和回答，约二十分钟。

请大家安排好时间，准备好问题，积极参与。

———————————————-

以下是实录：

●前言 ●

● 其实SDL方法论早在十几年前就已形成了多个流派和最佳实践，以微软和McGraw的BSI两大流派尤为著名，前者在微软落地实践了OS和Office系列取得了卓效成就，这里就不赘述了，后者也在IEEE、searchsecurity多个学术机构发表技术见解，获益良多。

● 关于“工具化->平台化->自动化”的提炼，不要理解字面意思，这个是我个人观察整个建设过程中，看重的某个点，以此来陈述个人观点，不代表业内最佳实践路线。

第一阶段 工具化 

（ 时间节点 170615 – 181115 ） 

 我刚加入第一天就约小伙伴聊目前的重点工作，大约如下：

WAF 白名单

外网 MIS 收敛

GitHub 监控

巴西国际化项目

DSRC 漏洞审核

开发项目评审

当时的环境状况是：

无感知手段，靠脸熟人工方式对接需求评审 和 代码评估

缺少标准化知识库，评估质量没有保证

DSRC 漏洞多，审核压力大，白帽子和工程师经常就漏洞等级吵架

技术栈也不统一，业务需求高于一切

事件频发，忙于救火复盘

我面临的就是这个状况，手头只有3个小伙伴，所以一上马开始全面了解现状，梳理。这个时候做不了任何决策，因为信息完全不对称。所以，开始从项目入手，复盘，一点点了解。大概两个多月时间，拿出第一版行动计划。

 

滴滴是个强指标体系的公司，我的上司只给了我一个数字，要求完成公司覆盖率85%，问题是什么是分母也没告诉我。我自己理解画了一个分三步的示意图：

 

这个阶段万事开头难，由单兵作战改成确定的3个工作流（黑白盒漏洞导向、安全设计导向、应急导向）。落地细化部门规范和基本方法，建立基本工作框架。同时对现有环境全面梳理：

• 业务架构是什么：技术栈、业务形态、研发流程、常见漏洞类型、事件复盘（有些问题是短期解决不了的，涉及到业务技术底层的改造，悬挂风险）

• 发布频率

• 代码类型分布

• 资产范围

• 修炼内功

• 知识库、方案库标准化积累

• 外部漏洞分析，提高召回率，为插件做准备

• 需要沉下心来做工具开发。

• 漏洞处理流程

• 代码安全标准

• 新项目上线安全规范

• 第三方系统安全评估规范第三方

• SAAS服务安全评估标准设计安全标准

• SDL项目分级标准与执行标准

• 公共组件使用标准

 

依照这幅简单的工作流，我们展开了行动。注意看”SDL 沉淀“，这是积累方法和知识库的阶段，修炼内功，所以这个时期最主要的就是建设能力。部门的小伙身兼数职，攻防、开发、运营全都要做，对人的要求也非常高，他们几个历练之后都成了部门骨干。这期间我也同时招聘，在安全评估和黑白盒以及后台开发、App安全方面的小伙伴陆陆续续半年内归队。

当时面临的最主要矛盾就是方法不统一，有标准和流程体系化等等。所以做事凭的个人能力和责任心，也导致产出不标准、质量也不稳定。由于缺乏标准作业系统，我们不得不被拉着线下开会评审项目，效率极低。

 

所以确定思路后我们是内部立项了7个项目，和主要的3个工作流。黑盒的自研和白盒采购是同时开展的，半年后都看到了成效。

 

总结一下这个阶段的特点：我们由原来的疲惫奔赴救火应急以及 DSRC 漏洞审核的局面，得到了极大的缓解。工作流基本 run 起来了，工具每天自动运行和闭环修复，标志点是检出率超过了 50%。

 

第二阶段 平台化

（时间节点 181115 – 191015 ）

这个阶段的标志物是SDL平台上线到基线上线阶段。

 

我们自研了SDL平台，并逐步与研发相关活动流程打通。平台最开始就为了解决两个问题：1.整合工具链；2.对接研发流程。后续我们开始在SDL 活动的数据沉淀和打通、漏洞分析统计、资产管理等方面都做了扩展，总人力应该超过 3 个人年，但是非常值得的。这个阶段对常见漏洞的讨论都比较少了，召回率和精准率都趋于稳定了。重点关注：

• 标准化与人效提升

• 自动化运营

• 数据打通与沉淀

• 知识体系

• 指标体系

补充背景：滴滴业务庞大的几个数字，每周超过3000个发布，线上十几万服务器和上千个域名、千万级 URL 、接口规模，数个 IDC分布国内外。每年的项目超过 2000+。这期间还有收购的第三方业务、第三方云、自建的滴滴云南、合作方等，导致我们的互联网生态丰富也安全挑战巨大。我们有一项非常重要的活动，就是设计阶段安全评估以及部分重要项目计划阶段的需求分析，在这个局面下无法完全覆盖，于是我考虑用更高效的方式来解决。

19年开始研究自动化基线项目并进行了实现。基线流程，意义在于我们开始在设计阶段介入了研发生命周期，同时标准化评估的输入和输出（平衡便捷、红线）

 

此阶段成熟度得到进一步提升，引用BSIMM8对比过，Level2。人效提升了6.7倍，检出率95%以上，工具链进一步成熟和扩展，1day出现能迅速排查对应的线上业务和代码仓库，推修率非常高。覆盖率大概66%（含历史存量，分母是git代码库）。对不同事业部的业态风险、漏洞类型、第三方组件、供应链、合作方、黑客攻击手法、用户隐私数据、合规需求等有了质的提升。

 

比较重要的第三方组件问题，得到了极大解决。去年爆发的几次1day，比如Fastjson，我们都比较从容及时的解决了，主要依据就是我们对线上所有的第三方组件的分布（几十万种）都对应到了代码这个级别。

 

门槛降低也是自身成熟度的一个衡量，尽管所有公开技术文章里从来没提到过这个。比如运营原来需要 12 位高阶小伙伴完成，那么门槛降低后3 位带两个实习生也能完成。重复类的工作交给机器完成，并加快了效率。SDL整个链条的活动越简单就意味着越容易运营，他不仅仅是自身考虑，还有面向RD，他如果根本理解或执行不了要求，就意味着失败了。

 

然后左移也是一个标志点，白盒由部署左移到构建阶段，黑盒有运维阶段左移到测试、预发阶段，左移意味着ROI提高，风险也更可控和收敛。

 

研发的安全技能和培训我们做得不算好，依靠视频和知识库自发式学习，毕竟几千 RD，要运营这个当时精力也不允许。所以 19 年开始自研安全SDK，直接到rd桌面上，集成开发环境里，目前还没有正式运营，产品已经出来了，在不断测试各种语言框架的适配性。

  

安全评估主要关注点：

面向用户是谁以及量级（滴滴用户、内部员工、外包员工、合作伙伴、政府部门）

数据类型和量级

认证授权实现方式

关键接口和上下游调用链

交互方式（暴露面）：web、api、socket。

项目类型是什么：运营平台、云产品、公共服务、金融业务、内部平台、运营活动H5、政府项目、对外合作。

评估方法主要引用威胁建模：

– step 1 安全评估按研发产品的需求文档和设计文档，依据具体的业务场景，识别出安全风险后梳理相应的威胁列表，针对威胁列表中的具体威胁提出缓解、转移或规避威胁的安全加固方案。

– step 2 通过阅读代码的方式检查开发编码中是否存在安全漏洞，是否引用了不安全的函数、是否使用了不合理的安全实现技术，从而降低业务代码部署到生产环境后，由于代码漏洞或不安全的技术实现被黑客或其他不法分子利用或攻击，从而给业务线或公司带来声誉、口碑或经济损失。

– 风险是有业态属性的，需结合业务场景来思考，ex. 香港的士敲诈黄志安事件、虚拟电话号码泄露事件

这个阶段有意思的是开始分析外部Top事件，比如万豪酒店、Facebook 隐私泄露等，开始比对复盘自身的缺陷。

 

第三阶段 自动化 

（ 时间节点 191015 – 201215 ）

20%的人力完成 80%的日常运营，人效进一步提升，门槛进一步降低。

 

• 漏洞处理自动化闭环

• 代码审计

• 预发/测试环境

• 线上定期

• 安全评估自动化

 

剩下的80%的人：

• 攻防研究

• 业态、架构研究

• 非标准大项目的整体评估

• 工具链完善和扩展

• 流程前置和深化

• SDK和培训延伸到RD桌面

 

大致内容就这么多，我提炼得比较简洁。希望大家提问，互相启发。

---

 

提问环节

Q：想请教一个问题，就是安全评估技术面有哪些？比如代码扫描、安全测试、安全扫描这些结果怎么处理？

A：威胁建模是最主要的技术，目前全部自动化闭环，我们这块早期会人工 review 看看误报，目前来讲几乎都是全自动在运行，人只做统计方面的事。

————————————————————————-

Q：波哥好，请问下是怎么解决业务上线系统不通知安全以及不同的人做的安全评估不一致的问题的，有没有遇到过人员A评估的安全需求上线后发现有遗漏的情况，万一发现了要怎么处置呢，谢谢。

A：好问题。流程卡点是SDL成功的关键，我们介入了所有可能的环节。比如采购、域名申请、cmdb 申请、研发部署的准入准出卡点，这个尤为重要，通过平台将Git url（代码仓库地址）和commit id（版本号）发给SDL平台，SDL平台根据Git url和commit id生成扫描任务，并将该扫描任务发送给白盒扫描器，白盒扫描器按照给定任务中的Git url和commit id拉取代码进行分析，并将扫描结果返回给SDL平台，SDL平台接收到扫描结果后，将结果中的漏洞推送到安全平台，由安全平台将漏洞发送给对应的安全工程师进行漏洞修复。

————————————————————————-

Q：请教下波哥，代码审计工作跟着代码commit开展，每个开发人员一天可能好几次commit，会频繁扫描，频繁推送审计报告，针对扫描频率和频繁报告，以及报告接收人如何优化设计？谢谢。
A：之前我们只在部署阶段，所以只有 master 分支，今年开始左移到构建阶段，意味着功能分支暴涨，目前我们还没全面上线运营，你提这个肯定是大问题，还需要观察，还在白盒是自研的，所以不受 license 限制，可以扩展性能。

————————————————————————-

Q：全自动化这个东西如何降低误报率呢？

A:   需要经历不成熟阶段，直到 OK 了才正式上线，小步快跑。

————————————————————————-

Q：在漏洞修复方案里面，未看到漏洞复现方面的内容，你们会否对所有类型的漏洞提出复现要求供开发参考？

A:  我们提供了靶机、培训视频、漏洞原理（bad case）以及如何针对不同代码的修复方法。而且这个是平台自动携带相关信息推送给 rd，不需要人工干预，除非过程中不明白会联系我们指导。

————————————————————————-

Q：大波哥好，辛苦了，很想问一下在前期你是怎么说服老板的？

A:   老板只给了半年时间，没成绩就滚蛋，哈哈。

————————————————————————-

Q：波哥，”人效提升了 6.7 倍，检出率 95%以上，“这个人效是怎么计算出来的呢？检出率95%是算的哪个指标呢？

A:  人效是算的人均项目数，检出率指标src/sdl*100%。

————————————————————————-

Q：波哥好，请问下如此快速迭代情况下在哪个阶段进行威胁建模（是提前抽象分析适配还是每个系统设计针对性建模）？另外dfd是由安全团队做还是开发团队完成？谢谢。

A:   在设计阶段介入。dfd 由开发提供设计图一起完成。

————————————————————————-

Q：波哥好，请问威胁建模是怎么推动和标准化的？

A:  这个话题真的好大，也是我们创新的一个重要思路吧，抽象出业务场景的共同元素，使之按照我们的标准化进行输入。这个是代码实现之前的阶段，实现之后我们有自研白盒去review是否 OK。威胁建模的操作有张图片可以参考。

————————————————————————-

Q：波哥提到sdl自动化，这里想深入交流下，需求、设计、测试阶段自动化，我想安全基线比较关键，安全需求基线、安全设计基线、威胁知识库等，这些知识库需要深入梳理业务场景才能制定出来，前期梳理安全投入较大（有一定基线库后就少很多），这同时对技能要求也高。

想请教下这部分大家是如何推进开展的？

A: 威胁建模一定要简单，以暴露面为主，核心就是认证授权和数据处理等红线，千万别搞个大而全的方案无法落地。等安全平均水位覆盖到了，再腾出手来离线搞专项，金融支付什么的业务场景，业务场景不一样风险也不同，举个例子，hk的x志安事件知道吗，很奇葩的触动了归零风险。抓小放大，一个大项目就会拖垮你的团队，埋头苦干搞建设然后再救火为主。总之带团队就是过日子，苦海无边人全吓跑了，有阶段性成果刺激一下大家。风险自己把控，如果接受不了的归零，那也得优先。

————————————————————————-

Q：秦总好，我想问下贵司目前有无把被动扫描嵌入sdl的自动化里。能谈下思路吗？

A:   有的，黑盒就是被动方式，收集各个地方的流量，测试环境、线上流量都有覆盖，然后清洗入库再消费，加上 payload 重放，不过线上环境很小心，要兼顾 qps 和去ticket，避免造成生成事故。

————————————————————————-

Q：请问自己研发的SDL平台都有SDL建设各个环节对应的功能板块可以查看吗？各个板块有对接到开发，运营，测试环节？80%的自动化是平台自身定时触发邮件OA发送各事业部负责人整改的吗？也是通过手动创建或导入漏洞报表生成的闭环链吗？是否有通过自动挖掘漏洞工具导入SDL平台？

A:  1、有，覆盖所有环节了。2、是的，自动触发邮件。3、工具链是平台的一部分，每个活动都感知并记录数据。

————————————————————————-

Q：关于第三方组件，想再请教下您。1、请问是如何做到对应到代码级？2、滴滴应该也是建私服？那么更新私服里组件有什么好的自动化方案或工具吗？3、像fastjson和jackson等组件经常爆有问题，是否每次第三方组件有问题就要求各项目升级？

A:  埋进pipelines流水线，构建时把组件依赖关系记录下来，爆发时再查，对集成包的组件包和 CVE 进行比对。会要求升级，如果环境不对外开放可例外与业务分析风险是否接受。

————————————————————————-

Q: 问下波哥，如果快速落地SDL，平台、工具是自研的吗？如果没有很好的技术支撑很难形成一个自动化闭环？

A:  是的，都是自研的。我的体会是黑盒先做，这个技术是最成熟的，先落地一个工具再干别的。

 

————————————————————————-

Q:  感谢波哥，请教一下，怎么协调研发团队应用SDL，研发团队有时任务确实都比较紧 。

A:  无法协调，我们的 rd 几千人，我们是从流程接入研发过程。

 

————————————————————————-

Q: 感谢波哥，想请问下 安全评估在那么大的业务量级的情况下是怎么去推动这块工作的？而且看您评估的内容项也挺多的 。

A:  标准化自己的能力和输出，这样就能快速落地同类型的项目。

 

————————————————————————-

Q:  感谢波哥，这种需求评审标准化，就是用规则库匹配的方式对吧，我们的困惑在于如何验证这些需求？白盒的检测规则能一一对应这些需求条目？

A: 可以这样理解，输入这边需要有基线引擎和模板，根据研发的输入生成一份标准安全要求项，白盒可以代码实现后的环节去 review。

————————————————————————-

福利：

时间关系，我推荐几个 ref 吧：

+[owasp主动控制项目](http://www.owasp.org.cn/owasp-project/OWASP_Top_10_Proactive_Controls_V3v1.1.pdf)

+ SDL 成熟度框架:bsimm & OWASP samm

+ 威胁建模：McGraw SARA

+ OWASP ASVS

+ 缓解机制列表（含公共组件）参考OWASP_Cheat_Sheet_Series

+ IEEE安全设计中心（CSD）提出的Top-10-Flaws

————————————————————————-
企业安全建设，离不开“守望相助”。金融业企业安全建设微信群，入群方式：请加以下微信为好友，备注：姓名-公司-负责领域。销售从业人员暂时不邀请入群，不保证每位申请者入群，敬请谅解。

来源：freebuf.com 2020-05-03 18:17:52 by: kelvin2294